IoT Security and Privacy Considerations
2 likes1,053 views
The document discusses several IoT security and privacy considerations, including using privacy by design principles to embed privacy into systems from the start, establishing accountability standards and open technology standards to build trust, and addressing common problems like lack of developer security experience, insecure communication protocols, and ensuring secure firmware updates throughout the lifecycle of IoT devices.
IoT Security and Privacy Considerations
- 1. IoT Security & Privacy Considerations 2016 Taiwan IGF Kenny Huang, Ph.D. 黃勝雄博⼠ Executive Council Member, APNIC huangksh@gmail.com 2016.06.17
- 2. 2 source : The Economist source : BBC “Every step you take will be the threat to privacy”The Economist
- 3. 3 “Personal data is the new oil of the Internet and the new currency of the digital world” Meglena Kuneva, European Consumer Commissioner User actions/ behavior Software Vulnerabilities Hardward Vunlerabilities sourcesofrisk “Target CEO out as Data Breach” - USA Today May 2014 “Hackers' Next Target : Your Health Insurance Company” - FOXBusiness, May 2014 Privacy and Security What Are The Risks
- 4. Policy and Process 4 Privacy by Design Methodology Fair Information Practice Principles Accountability Standards Open Technology Standards
- 5. Privacy By Design • Taking privacy into account throughout the whole engineering process • 7 principles – Proactive not reactive – Privacy as the default • purpose specification; collection limitation; data minimization; use, retention and disclosure limitation – Privacy embeded into design – Full functionality – End-to-end security - full lifecycle protection • ensure confidentiality; integrity and availabiliity – Visibility and transparency - keep it open • accountability; openness; compliance – Respect for user privacy - user centric • consent; accuracy; access; compliance 5
- 6. Fair Information Practice Principles • Notice/awareness – Consumers should be given notice of an entity's information practices before any personal information is collected from them • Choice/consent – giving consumers options to control how their data is used • Access/participation – consumer's ability to view the data collected, and to verify and contest its accuracy • Integrity/Security – ensure that the data they collect is accurate and secure • Enforcement/Redress – enforcement measures : by the information collectors; to sue violators; criminal penalties 6
- 7. 7 Accountability standards serve as a framework for building trusting, productive relationships among stakeholders Accountability standards create benchmarks and a common ground for stakeholders For digital data operator collected, operator need to tell people how they use it Accountability Standards Need a large community that is interested in developing open technology standards. People can identify weakness before it become an issue Making sure we have public scrutiny on the things we going to use and to keep our data private Open Technology Standards
- 8. IoT Security is Critical • Security is the top issue for IoT – Deployments will not scale without trust • With large deployments – must limit attack surface of each device • Applies to even simple sensors – Even if there is no secure data issues • Security must be architected from the beginning and must not be made an option 8
- 9. Bring Security to Traditional Embeded Systems 9 Embeded OS Software Stack and Application Traditional closed systems Secure OS Application Very few developers have strong experience in creating secure systems Need a platform with built-in security and strong guidance on best practices
- 10. Security Design Challenges • Too easy to declare developers of compromised products as incompetent – as product security can't be reliably measured, security suffers first on tight product schedules – massively parallelized security researchers vs. limited product development budgets and time frames • The security of a system is dynamic over its lifttime – the likehood of an attack often wrongly assessed or undervalued in the chain • New Denial-of-Service power attacks a problem for battery/scavenging devices – structural sensors often inaccessible and battery replacement is expensive • If your product is successful, it will be hacked. – often the deployment costs of firmware udpates surpass the costs of a new device – as a result even know-broken systems are kept in use – this is not the PC world, no reset, no reinstall • The assumption of being hacked at some point requires solid mitigation strategy – developers must ensure secure, reliable and affortable firmware updates 10
- 11. System Architecture - Security Perspective 11 Directory & Subscription Security Admin & Multi-tenancy Data Flow Management - RESTful and Publish/Subscribe Device Management - Lightweight M2M Interface - Open Web Standards Application Protocols - CoAP, HTTP IoT Server Device Management - Lightweight M2M Cryptography ? IoT Device OS WiFi Bluetooth 3G/4G IPv6, 6LoWPAN IPv4 Lifecycle Security Communication Security IoT Device Security Open Standards ? Open Source
- 12. IoT Interoperability 12 Participants : IETF, W3C, OMA, AllSeen Alliance, OCF, NIST, CableLabs, ZigBee, and ETSI, etc.
- 13. WiFi Stack Traditional MCU Flat Security Model 13 Server Application Protocol SSL Library Secure Storage Crypto Key Device Managemen Secure ID Crypto API Firmware Update Diagnose BLE Stack Random No Generator IoT devices include significant software complexity Secure and privacy enabled server communication Unclonable device identity Cryptography and random number generation Protection of keys/certificates and server API tokens Secure firmware update over the air Flat security all code/data lives in a shared address space Large attack surface makes hard to verify devide security Bugs in any code can lead to a security flaw Code based is too large for exhaustive validation If malicious code updates Flash it may become impossible to remotely recover a device
- 14. Device Security : Secure Partitioning for MCUs 14 BLE Stack WiFi Stack Application Protocol SSL Library Device Managemen Diagnose Server Firmware Update Secure Storage Crypto Keys Crypto API Secure ID Random No Generator Public Private Split memory into private critical and public uncritical Small private footprint enables exhausive verification Public code operates on cryptographic secrets using defined API's but never allow access to raw keys Vulnerabilities on public side can't affect private side public code can't wirte code directly to Flash Private side can reliably recover device to clean state private side can verify integrity of the public side image
- 15. Enable Fast Innovation 15 BLE Stack WiFi Stack Application Protocol SSL Library Device Managemen Diagnose Firmware Update Secure Storage Crypto Keys Crypto API Secure ID Random No Generator Public Private Fast Slow Private modules build with strong security and rarely change software is never finished new features, bug fixes, patching vulnerabilities and tracking standards Code in the public state is developed rapidly fast time to market quick innovation cycles for public side still a secure product When bugs are discovered after deployment a firmware update can be reliably enforced
- 16. Driverless Car : Secure But is it Safe 16 360 View Front Camera Interor Camera Long-range Radar Mid-range Radar Ultrasonic Sensors Automative Today, IoT Tomorrow ASIL B or ASIL D support IEC 61508 ISO 26262 Development process Fault detection and control features Failure node and effects analysis FMEA Compiler qualification & Maintenance
- 17. Levels of Vehicle Automation 17 Level 1 - Function-specific automation one or more control functions such as breaking and lane keeping are automated but driver has control Level 2 - Combined function automation Two or more control functions automated. eg. ACC with lane centering. Hand off the steering wheel and foot pedal but still responsible to monitoring and expected to control the vehicle Level 3 - Limited self- driving automation Vehicle takes control of all safety critical functions mostly. Driver is expected to be available for occasional control without constant monitoring Level 4 - Full self-driving automation Vehicles takes control all safety critical driving function and monitor roadway all the time. Driver is not expected to be available for control it any time
- 18. Internet Protocol to The Edge 18 REST APIs CoAP|HTTP TCP REST APIs UDP IoT Application Device management WiFi Bluetooth 3G/4G Non-standard approaches are a risk Don't repeat past mistakes Use Internet security widely deplyed and proven firewalls and local routers 32-bit MCUs can handle IP stacks < $1 trust Moore's law
- 19. Lifecycle Security and LWM2M 19
- 20. Common Problems We Need to Solve 20 IoT deployments will not scale without trust very few developers have strong security experience Flat security model remote code execution allows full access and key extraction Compromised communications protocols Man in the moddle attacks and compromised devices Flawed proprietary algorithms Insecure firmware updates updates become the malware infection issue compromised through ineffective or no use of cryptograph Poor random number generation Negates strong cryptograph Lifecycle Security Communication Security IoT Device Security
- 21. 21