Understanding the Risks and Privacy Challenges in the Internet of Things
The Internet of Things (IoT) presents vast opportunities for interconnected devices, but also introduces significant risks to security and privacy. With billions of connected devices expected by 2020, the IoT landscape is expanding rapidly, leading to concerns such as insecure interfaces, authentication issues, lack of encryption, and privacy risks related to data collection and disclosure. Enterprises and individuals must be vigilant in addressing these challenges to ensure data protection and mitigate potential threats in the evolving IoT ecosystem.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
CERIAS Data Security and Privacy in the Internet of Things Elisa Bertino CS Department, Cyber Center and CERIAS bertino@cs.purdue.edu
The IoT Wikipedia The Internet of Things (IoT) is the network of physical objects or "things" embedded with electronics, software, sensors, and network connectivity, which enables these objects to collect and exchange data. Applications Media Environmental Monitoring Infrastructure Management Energy Management Medical and Healthcare Systems Building and Home Automation Transportation The IoT allows objects to be sensed and controlled remotely across existing network infrastructure,creating opportunities for more direct integration between the physical world and computer-based systems. When IoT is augmented with sensors and actuators, the technology becomes an instance of the class of cyber-physical systems, which also encompasses technologies such as smart grids, smart homes, intelligent transportation and smart cities.
IoT Diffusion - Forecast 50 billion connected devices by 2020 More than 6 connected devices per person $1.7 trillion in value added to the global economy in 2019 By 2020 IoT will be more than double the size of the smartphone, PC, tablet, connected car, and the wearable market combined Technologies and services generated global revenues of $4.8 trillion in 2012 and will reach $8.9 trillion by 2020, growing at a compound annual rate (CAGR) of 7.9%
IoT - Risks IoT dramatically expands the attack surface IoT systems do not have well defined perimeters IoT systems are highly dynamic and continuously evolve because of mobility IoT are highly heterogeneous with respect to: Communication Platform Devices IoT systems may include physically unprotected portions IoT systems are highly autonomous and control other autonomous systems IoT systems may include objects not designed to be connected to the Internet
IoT - Risks The OWASP Internet of Things Top 10 - 2014 1. Insecure Web Interface 2. Insufficient Authentication/Authorization 3. Insecure Network Services 4. Lack of Transport Encryption 5. Privacy Concerns 6. Insecure Cloud Interfaces 7. Insecure Mobile Interfaces 8. Insufficient Security Configurability 9. Insecure Software/Firmware 10.Poor Physical Security
IoT Privacy Risks Individuals as sources of multiple data sets Wearable devices collect huge amounts of personal data as well data about the user environment Major privacy concerns arise for health-related data from the use of medical devices and fitness applications Privacy-sensitive information can be easily disclosed to third parties Threats arise for enterprise perimeters
A Holistic Approach is Required All elements need to be considered The IoT Devices The Cloud The Mobile Applications The Network Interfaces The Software Use of Encryption Physical Security USB Ports
Question: We have a lot of data security techniques Can we apply them to the IoT?
A Sample of Research Projects
Efficient key management Encryption Protocols schemes for IoT and mobile devices A. Seo, J. Won, E. Bertino
Existing Approaches Symmetric key cryptography based technique Not scalable Not resilient against node compromises Traditional asymmetric key cryptography based (PKI) based technique Good for Mobility support Computationally expensive Traditional certificate based PKI certificate management problem Id-based PKC key escrow problem, expensive pairing operation Certificateless PKI (CL-PKI) based technique Pairing based CL-PKI schemes (expensive) Pairingfree CL-PKI (Not Using Pairing Operation faster than pairing based schemes)
pCLSC-TKEM pCLSC-TKEM is a Pairing-free Certicateless Signcryption-tag Key Encapsulation Mechanism for securing IoT communications It addresses all security requirements (authentication, confidentiality, integrity) It maximizes energy efficiency of IoT devices Small packet size for key establishment IEEE 802.15.4 max. payload: 114bytes Fast key establishment to minimize the energy consumption of sensors It is a combination of SC-TKEM (signcryption tag-KEM) and CL-PKC (Certificateless Public Key Cryptography) without using pairing operation It supports both key encapsulation and digital signatures into one efficient algorithm by using SC-TKEM. So, it can guarantee the integrity of the tag. A tag can be a random string used to refresh a key or a ciphertext It eliminates the certificate management overhead and key escrow problem by using CL-PKC technique It has better performance than previous approaches because it uses a pairingfree technique
Scenario and examples IoT reference communication scenario: Three entities Key generation center (KGC) Mobile User (MU) smart phone, wearable device, car, drone, etc Smart Object (SO) Embedded device. Any authorized MUs can communicate with the SOs. Approach: Certificate-less encryption without pairing operations Examples: Smart building: MU (officer) SO (door lock, computer, lights, CCTV, etc.) EV charging infra.: MU (EV car) SO (EV charging device.) Hospital: MU (doctor) SO (patient s health monitoring device)
Experimental Results Our scheme (pCLSC-TKEM) Lippold et al., Li et al., Selvi et al.: pairing-based CLSC-TKEM schemes PC (2048-bit RSA security level) Android smart phone (2048-bit RSA security level)
Experimental Comparison TelosB 1024-bit RSA 250? Lippold? et? al.? 206.12? Fagen? Li? et? al.? 186.52? 200? Our? scheme? 150? sec? 114.14? 98.11? 100? 61.21? 51.68? 40.96? 40.29? 50? 27.20? 19.47? 13.15? 8.35? 0? Setup? Encap? Decap? Total?
Secure Communication for Drone-based Applications Mobility Command Sensed data Constrained resources
Challenges: Security and Efficiency Sensors (smart objects) and drones are battery- powered The drones cannot be equipped with high capacity battery due to their weight. Sensor s battery is usually not replaced during their life time. Sensors do Low Power Listening (LPL) for energy saving Drone may wait until sensor wakes up. Asynchronous computing power The sensors have very low computing power (TelosB: 4MHz) The drones have PC or smartphone-like computing power (> 1GHz) The drone must wait until the sensor completes key establishment in order to receive an encrypted message from the sensor
The solution Pairing-free Certificateless Signcryption Tag Key Encapsulation Mechanism (pCLSC-TKEM) satisfies all security requirements minimizes computational overhead on sensor (w ECC and w/o pairing, small number of EC point multiplications) Dual channel strategy The drone has two radios Wake-up channel: continuously sends wake-up signals including drone s public key Data channel: used only for data exchange allows multiple sensors to concurrently execute pCLSC-TKEM
USB D+ USB Ground USB D- USB Vcc +5V Wake-up radio Data radio Altitude: 10m Comm. range: 30m
Hardware Accelerated Authentication Protocols Authentication for Vehicular Networks Anand Mudgerikar, Ankush Singla, Attila Yavuz, Ioannis Papapanagiotu, Elisa Beritno
Vehicular Networks Modern vehicles are equipped with advanced sensing and communication technologies The key requirements: High Security Low Latency Scalability Advanced features possible: Autonomous driving Collision avoidance Route planning
Project goals Develop a new suite of fast, scalable and compact authentication methods Leverage the processing capabilities of Graphical Processing Units(GPU) in System-On-Chips(SoC) Perform experiments in a fleet of R/C cars to validate the approach followed by evaluation on actual vehicles Develop a suite of open-source crypto libraries and educational tools for proposed methods
System on Chips (SoC) A system on a chip (SoC) is an integrated circuit (IC) that integrates all components of a computer into a single chip Embedded SoCs are used by major car manufacturers (e.g., Audi, BMW, Ford, Mercedes and Tesla) for their infotainment and communication systems A source of high performance computing in vehicles They come with high- bandwidth peripherals, sensors, and network interfaces They include embedded GPUs
Solution: Hardware Accelerated Authentication Hardware-Accelerated Authentication (HAA) Leverages system properties to perform broadcast authentication. Based on Rapid Authentication (RA), which is suitable for time-critical authentication Exploits existing structures in the vehicular communication messages to enable pre-computation for signature schemes like RSA online/offline signature scheme We implement the rapid authentication framework on GPUs using hardware acceleration and optimization techniques to accelerate the protocol Protocol End-to-End Crypto Delay (msec) 4 RSA 2048 ECDSA 256 1.18 RA 2048 0.69 HAA 2048 (GPU) 0.21 RA 2048 SoC 7.1 HAA 2048 (GPU on SoC) 2.6 HAA offers significant performance improvements over standard signatures (e.g., ECDSA,RSA) for high throughput applications.
Future Work After implementing HAA using factorization based authentication schemes (RSA), we intend to incorporate other cryptographic schemes Lattice Based Crypto (NTRU) Elliptic-Curve Based Crypto (BLS) Explore the potential of HAA in other application domains having similar delay- aware authentication needs such as smart- grid and drone swarms
Protecting the IoT from Network Security Heimdall DDoS attacks J. Habibi, D. Midi, E.Bertino
A whole greater than the sum of its parts 26 bln IoT devices by 2020, but 25 vulnerabilities per device on avg Easy to exploit massive numbers of small devices for DDoS attacks IoT: IDEAL FOR BOTNETS Devices are small but powerful No diurnal dynamics, always-up behavior AND SUITABLE FOR DEFENSE No general purpose, but well-defined behaviors Routers are strategic placement for defense Heimdall: analysis and defense technique evaluates attack throughput of off-the-shelf IoT hardware to understand power and scope of IoT-based botnets and DDoS attacks, and design, prototype and evaluate a centralized lightweight defense for routers. APPLICATIONS: wide consumer market, offices and factories, storage/distribution facilities,
Attack analysis and defense design 0.0000135% of IoT devices is dangerous enough Just 353K IoT devices are as powerful as 100K traditional x86 machines Defense: Learning phase + Blocking phase Smart whitelist-based approach, tailored to IoT behavior and using IoT routers Prototype implementation on OpenWRT with IPTables Evaluation with Nest Thermostat, August SmartLock, and more FUTURE DIRECTIONS Build full IoT botnet for complete attack and defense evaluation Investigation on adaptive learning period, new devices interaction with network,
Fine-grained diagnosis of FGA for WSNs packet losses in WSNs D. Midi, E. Bertino
Node or link? packet losses in embedded systems Packet losses: very relevant class of adverse events in WSNs IDSes are typically only able to detect the event, but not its causes NODE-RELATED CAUSES Selective forwarding, Blackhole, LINK-RELATED CAUSES Interference/Jamming Fine-Grained Analysis for WSNs uses existing link parameters(RSSI, LQI, ) to investigate the cause of packet losses (node- or link-related) and accurately locate interference sources. APPLICATIONS: Forensics, Real-time response systems,
Design, architecture and future work Asynchronous and event-driven No additional hardware Lightweight operation Multiple simultaneous investigations Low communication overhead Stealthy investigation Fully distributed algorithm FUTURE DIRECTIONS Application of FGA to consumer/enterprise IoT devices, MANETs/VANETs, automotive, Fine-grained analysis framework for IoT to enable automated response
Investigation accuracy CORRECT DIAGNOSES ~90% selective forwarding ~95% low interference ~100% strong interference
How to Reason about Security and Privacy Based on Jeff Voas Primitives and Elements of Internet-of-Things (Iot) Trustworthiness Draft NIST IR 8063 http://csrc.nist.gov/publications/PubsDrafts.html#NIST-IR-8063\ Slides of ACM CODASPY 2016 Keynote Talk by Jeff Voas
Primitives 1. Sensor A sensor is an electronic utility that digitally measures physical properties such as temperature, acceleration, weight, sound, etc. 2. Aggregator An aggregator is a software implementation based on mathematical function(s) that transforms groups of raw data into intermediate data. 3. Communication channel A communication channel is a medium by which data is transmitted (e.g., physical via USB, wireless, wired, verbal, etc.). 4. eUtility A eUtility (external utility) is a software or hardware product or service. 5. Decision trigger A decision trigger creates the final result(s) needed to satisfy the purpose, specification, and requirements of a specific NoT.
Sensor 1. Sensors are physical. 2. Sensors may have little or no software functionality and computing power; more advanced sensors may have software functionality and computing power. 3. Sensors will likely be heterogeneous, from different manufacturers, and collect data, with varying levels of data integrity. 4. Sensors will have operating geographic locations that may change. 5. Sensors may provide surveillance. Cameras and microphones are sensors. 6. Sensors may have an owner(s) who will have control of the data their sensors collect, who is allowed to access it, and when. 7. Sensors will have pedigree geographic locations of origin and manufacturers. Pedigree may be unknown and suspicious. 8. Sensors may fail continuously or fail intermittently. 9. Sensors may be cheap, disposable, and susceptible to wear-out over time; here, building security into a specific sensor will rarely be cost effective. However there will differentials in security, safety, and reliability between consumer grade, military grade, industrial grade, etc.
Sensor 10.Sensors may return no data, totally flawed data, partially flawed data, or correct/acceptable data. 11.Sensors are expected to return data in certain ranges, e.g., [1 100]. When ranges are violated, rules may be needed on whether to turn control over to a human or machine when ignoring out-of-bounds data is inappropriate. 12.Sensor repair is likely handled by replacement. 13.Sensors may be acquired off-the-shelf. 14.Sensors release data that is event-driven, driven by manual input, or released at pre-defined times. 15.Sensors may have a level of data integrity ascribed (Weights). 16.Sensors may have their data encrypted to void some security concerns Sensor data may be leased to multiple IoT systems. A sensor may have multiple recipients of its data. 17.The frequency with which sensors release data impacts the data s currency and relevance. Sensors may return valid data at an incorrect rate/speed. 18.Sensor data may be at rest for long periods of time; sensor data may become stale. 19.A sensor s resolution may determine how much information is provided. 20.Security is a concern for sensors if they or their data is tampered with or stolen.
Aggregator 1. Aggregators are likely virtual due the benefit of changing implementations quickly and increased malleability. A situation may exist where aggregators are physically manufactured. 2. Aggregators are assumed to lack computing horsepower, however this assumption can be relaxed by changing the definition and assumption of virtual to physical, e.g. firmware, microcontroller or microprocessor. Aggregators will likely use weights to compute intermediate data. 3. Aggregators have two actors that make them ideal for consolidating large volumes of data into lesser amounts: Clusters, and Weights. Aggregator is the big dataprocessor within IoT. 4. Intermediate data may suffer from some level of information loss. 5. For each cluster there should be an aggregator or set of potential aggregators. 6. Aggregators are executed at a specific time and for a fixed time interval. 7. Aggregators may be acquired off-the-shelf. 8. Security is a concern for aggregators (malware or general defects) and for the sensitivity of their aggregated data. 9. Reliability is a concern for aggregators (general defects).
eUtility 1. eUtilities execute processes or feed data into the overall dataflow of an IoT system. eUtilities may be acquired off-the-shelf. eUtilities include databases, mobile devices, misc. software or hardware systems, clouds, computers, CPUs, actuators, etc. The eUtility primitive can be subdivided. eUtilities, such as clouds, provide computing power that aggregators may not have. A human may be viewed as a eUtility. Data supplied by a eUtility may be weighted. An eUtility may be counterfeit. Non-human eUtilities may have Device_IDs; Device_IDs may be crucial for authentication. Security and reliability are concerns for eUtilities. 2. 3. 4. 5. 6. 7. 8. 9. 43
Decision trigger 1. A decision trigger is a pre-condition that must be TRUE before a NoT takes action. A decision trigger should have a corresponding virtual implementation. A decision trigger may have a unique owner. Decision triggers may be acquired off-the-shelf or homegrown. Decision triggers are executed at specific times and may occur continuously as new data becomes available. Decision trigger results may be predictions. Decision trigger results may control actuators or other transactions. If a decision trigger feeds data signals into an actuator, then the actuator should be considered as a eUtility if the actuator feeds data back into the IoT system. 2. 3. 4. 5. 6. 7. 8. 44
Research Directions - summary IoT device management Identify and locate devices Authenticate devices Maintain device hw/sw Data management in IoT Confidentiality Availability Integrity Privacy in IoT Controlled data acquisition Anonymity Design, test, configure and monitor IoT systems
Thank you!! Any question?
