More Related Content
What's hot (20)
Viewers also liked (20)
Similar to mbed Connect Asia 2016 Securing IoT with the ARM mbed ecosystem (20)
Recently uploaded (20)
mbed Connect Asia 2016 Securing IoT with the ARM mbed ecosystem
- 1. ©ARM 2016 Securing IoT with the ARM mbed ecosystem Xiao Sun / Senior Applications Engineer / ARM ARM mbed Connect / Shenzhen, China December 5, 2016
- 2. ©ARM 20162 Lots of interest in IoT security Researchers are looking into security of IoT systems Vulnerabilities are recognized in deployed IoT systems Fixes are deployed where possible IoT security is evolving in a positive way as a consequence
- 3. ©ARM 20163 You can’t do big data unless you trust the little data IoT will not scale without trust and security Even simple sensors With large deployments you must secure all devices Enabling trust and security in IoT devices is an opportunity to create value
- 4. ©ARM 20164 IoT projects need a platform OS Historically, embedded microcontroller design has had little code or design commonality between systems that enables widespread re-use The communication, device management and security demands of IoT devices are a disruptive jump in complexity that drives the need to use a platform OS Bespoke middleware integration and application RTOS ApplicationPlatform OS and modular component middleware Development time Development time
- 5. ©ARM 20165 mbed OS security Covers three main types of threat Security of system, including ability to provision, manage and update devices (e.g. security fix) Security of communications between device and cloud services Security and integrity of device itself from untrusted or malicious code mbed Client Lifecycle security mbed TLS Communication security mbed uVisor Device security mbed OS security
- 6. ©ARM 20166 Proportional security Threat-models should be informed by business requirements Technology applied and cost expended varies according to application needs For Example Risk environment of application Value of assets to be protected Trust and control over firmware Supply chain structure Lifetime of the device Application Security Disposable mbed TLS + mbed Connect Long life node + mbed uVisor + active lifecycle management Critical infrastructure + Anti-tamper hardware (ARM SecurCore)
- 8. ©ARM 20168 mbed TLS mbed TLS enables cryptographic and SSL/TLS capabilities for use in embedded software mbed TLS is tightly integrated into mbed OS Combined with the mbed uVisor, this provides comprehensive device and communication security for IoT products
- 9. ©ARM 20169 mbed TLS – Code quality
- 10. ©ARM 201610 mbed TLS – Code testing Protocol interoperability tests Behavioural RFC tests Vulnerability tracking and fixes
- 11. ©ARM 201611 mbed uVisor (pronounced “embed microVisor”)
- 12. ©ARM 201612 mbed uVisor A tiny, hypervisor/microkernel-like security kernel Creates and enforces secure isolation boundaries within the OS, between different parts of the system Enables secrets to be strongly protected against software and network-bourn attackers Efficient hardware enforcement through the memory protection unit (MPU) and ARM TrustZone for v8-M
- 13. ©ARM 201613 The device security problem Even simple IoT products have complex components Secure server communication over complex protocols Secure firmware updates over the air Secure device identities Cryptography APIs and random number generation Existing IoT solutions use flat address spaces with little privilege separation Especially on microcontrollers Application protocol TLS library Diagnostic s Secure storage Crypto keys Secure ID Crypto API WiFi stack BLE stack Device managemen t Firmware update Server PRNG
- 14. ©ARM 201614 The device security problem - Attacker view Application protocol TLS library Diagnostic s Secure storage Crypto keys Secure ID Crypto API WiFi stack BLE stack Device managemen t Firmware update Server Attacker PRNG Flat security models allow attackers to break device security by breaking any system component Common attack entry points: Complex protocols like TLS, Wi-Fi or USB device configuration Firmware update functions (USB, network, CAN…) Impossible to recover from attacks as firmware update functions can be compromised by the attacker
- 15. ©ARM 201615 Split security domains into: Public uncritical code Protected critical code Protect key material and system integrity Use ARMv7-M MPU or TrustZone for v8-M Keep footprint of critical code small Public code operates on cryptographic secrets via defined private API No access to raw keys The device security problem - Mitigation strategies Exposed Critical Secure storage Crypto keys Secure ID Firmware update Crypto API PRNG Application protocol TLS library Diagnose WiFi stack BLE stack Device manageme nt
- 16. ©ARM 201616 The device security problem – Mitigation benefits Server Attacke r Exposed Critical x x x x x Secure storage Crypto keys Secure ID Firmware update Crypto API PRNG Application protocol TLS library Diagnose WiFi stack BLE stack Device manageme nt Attackers can compromise the exposed side without affecting critical code Cryptographic hashes can be used to verify the integrity of the exposed side Triggered on server request Protected security watchdog allows remote control Protected side can reliably reset exposed side to a clean state The device attack surface is massively reduced as a result
- 17. ©ARM 201617 Pulling it together
- 18. ©ARM 201618 mbed OS mbed uVisor is part of mbed OS, but is optionally enabled depending on the underlying hardware support If present, mbed uVisor boots the mbed OS image, and configures secure boxes using the provided access control lists • TLS stack
- 19. ©ARM 201619 mbed TLS mbed OS security Connectivity client Provisioning client Update client Connectivity service Provisioning service Update service Cloud applications platforms Management security Communication security Device security Device hardware uVisor or TEE mbed TLS KeysCrypto StorageIdentity Deployment managementData flow management
- 20. ©ARM 201620 IoT deployments will not scale without trust Very few developers have strong security experience mbed IoT Device Platform provides a comprehensive security foundation Device security Communications security Lifecycle security Summary
- 21. The trademarks featured in this presentation are registered and/or unregistered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. All other marks featured may be trademarks of their respective owners. Copyright © 2016 ARM Limited ©ARM 2016
Editor's Notes
- #4: IoT deployments will not scale without trust Low priority and dynamic Very few developers have strong security experience Even if there is no secure data/privacy issues and must not be made an option Updates become the malware infection vector DDOS flatten battery In the wall This is not the PC world, no reset, no reinstall
- #5: History of engineering closed systems Somewhat secure thanks to isolation (SW, communication and physical) and obscurity (low volume) Very little code reuse and design commonality between systems These “Embedded” norms can’t survive in a successful connected IoT world When you add networking everything changes Exposed systems connected to the internet Managing high complexity in networking stacks requires code reuse and modern dev approach MCUs need to become accessible to a larger audience of developers Few developers have security experience mbed IoT Device Platform is the best starting point
- #7: Security is not a black and white thing. It is not either on or off. It must be deployed in proportion to the need for security. Before security thread-models are defined it is important to have a holistic view of business requirements. Then appropriate security choices can be made (the cost and effort to be expended on a security solution is a factor here). Even the most basic application which has static service session information determined at the time of manufacture (e.g. a fixed symmetric key) need fairly sophisticated security functionality. Communication security (as implemented by mbed TLS) enables the device to have basic authentication, confidentiality and integrity for data sent to and from it over the internet. The mbed Cloud Connect service is also provides the security required to use a specific device with a particular cloud application. Many IoT platforms don’t provide much more security than this but at this level it is impossible to securely provision new keys/certificates onto the device or update its firmware. This severely limits the useful lifetime of the device (or risks relying on a device deployment investment with little security protection). Also this limited device security means that valuable secrets can’t safely be stored on the device. As a result this level of security is best suited to disposable devices where the value of device deployment does not need to be maintained and the secrets on the device are low value. Many applications will demand a larger investment in security. Adding mbed OS uVisor capability enables greater protection of secrets scored on the device and provides greater trust for device identity, integrity. This in combination with mbed Cloud Provision and mbed Cloud Update allows deployed device to flexibly connect to new services and form new secure relationships over its lifetime while keeping pace with changes to security standards and newly discovered protocol vulnrabilites. This protects business investment in large device deployments. At this stage the device can be trusted to implement most common IoT applications and to store important secrets with adequate protection. Beyond this some specialist applications may require higher levels of security such as resistance to LAB attacks while storing very valluable secrets. This would required the addition of more expensive hardware counter measures and anti-tamper features. This can be supported alongside mbed OS security features.
- #11: Mention mbed TLS website with list of vulnerabilities
- #15: Third party stacks
- #20: The future mbed roadmap will deliver pervasive security across all of our device services (mbed Cloud) and device software (mbed OS; mbed TLS; mbed for X). This security covers many different aspects and exists in may different layers of our mbed IoT Device Platform. Broadly speaking we can categorize all these security aspects into three distinct areas: Device Security: This comprises of all security aspects implemented in mbed Device Sofware running on IoT end nodes. Our roadmap for this includes SW functionality to implement security related to connectivity, provisioning and device update. These higher level rich protocol/functionality modules will be supported by basic security components that include secure boot; secure storage primitives; low level key management; device identity and cryptographic libraries supporting both full SW implementations and secure interfaces to hardware crypto accelerators. These basic security components can, optionally, reside within and be protected by Trusted Execution Environments (TEE) or secure supervisory kernels such as the mbed OS uVisor when this is supported by the device hardware. This adds additional protection by providing secure isolation of system resources for each software component. Communication Security: Based on widely deployed and most thoroughly tested security available for internet communication today. mbed Communication Security is implemented by the mbed TLS library which provides all the functionality required to implement the full TLS and DTLS protocols. The mbed TLS library is use in the device software and within the mbed Cloud services. This provide end-to-end communication security from each end node into mbed Cloud across the internet. Management Security: Implemented within our mbed Cloud services this enables secure lifecycle management for large deployments of end nodes. This will encompass secure device connectivity; secure device provisioning and secure device update services. This is vital to enable IoT deployments to scale. Critically our update service will enable agile security to be implemented across the entire mbed IoT Device Platform. This protects investment in large deployments and enables our IoT security to evolve alongside state of the art internet security. It will also provide secure links into Cloud Application Platforms so that entire IoT applications can be fully secured.