Building firmware update: The devil is in the details Atsushi Haruta, IoT Services Group, Arm Arm Tech Symposia Japan 2017
Arm Mbed: Secure device management Application Cloud Mbed Cloud Secure, scalable, efficient device management services CoAP, HTTP, REST Key technologies Thread BLE Mbed OS Unparalleled powerefficiency and security for new IoT devices Mbed Enabled products Tested interoperability for IoT that can be trusted Mbed Clients End to end security Connect Global IoT connectivity and management Provision Secure management of device assets Update Cost-effective device support and maintenance 6LoWPAN / NB-IoT WiFi Mbed for other Operating System Supporting more technology choices 2
New features and repairs are expected Repairs Features IoT device lifetime 2016 2026 2036 3
Remote update Replace Remote update In-field remote secure update is crucial for IoT success 4
Firmware update Endusers rarely update their devices Businesses don t want the overhead of updating their devices This presents 5 types of challenges: Selection of which devices to update Management of the authority to update devices Device resilience to power failure, network loss etc. Privacy of the updates Status monitoring of devices targeted by an update 5
Firmware update: The ideal The model of firmware update is simple: Devices go through a series of steps: receive a new firmware image from a trusted source install the new firmware image boot into the new image the new image works completely The real The reality of firmware update is not so simple. Devices lose network connection or power receive firmware from untrusted sources receive firmware that doesn t work suffer flash memory failures on installation fail to boot the new firmware 6
Firmware update: Resilience
Firmware update: resilience Resilience decides how we ensure that a device always works. To ensure that updates cannot fail, there must be a piece of code that cannot be updated. We call this code the bootloader. It ensures that only a valid image is loaded. Devices need to keep at least two bootable images so that one always works. 8
Firmware resilience: what kind of bootloader? Bootloaders have one key differentiating feature. Networked Non-networked (or, static)? Boot App 1 Boot??? App App 2 Static Bootloader Networked Bootloader 9
Bootloaders: networked, or static? Each has its own complexities. There is no clear-cut answer. These approaches are not mutually exclusive: 2-stage boot Stage-1 static bootloader Stage-2 networked bootloaders Recovery image Static bootloader selects the regular image, or a recovery image that contains only the update client 10
Firmware resilience: firmware storage Where should a new image be stored? On-chip, in the existing flash Off-chip, on an external storage device Boot? Active App Boot? Active App? Candidate App? Candidate App On Chip Storage Device Off-chip storage 11
Firmware update: Authority
Firmware update: authority Authority in firmware update answers several questions: Who gets to write firmware? Who decides if it s going to work on this network Who gets to install it? Who chooses when to install it? There are two immediate options: Use TLS with a trusted server Use code signing Device 13
Firmware update over TLS: The ideal Developers authenticate with the TLS server to start firmware updates. The real A centralized trust system creates a centralized point of failure. Each device trusts the update server completely. The update server manages access control. The developer logs in to the update server and uploads a firmware. The update server decides whether or not to send the update, based on the developer s permissions Devices only need to trust one set of credentials. 14
Firmware update with code signing Devices verify the firmware, not the connection. The device still trusts a certificate The certificate identifies a firmware author 15
Firmware update with code signing: The ideal An author can sign the firmware image before it is distributed. The device verifies the signature of the firmware image before installing it. The author can perform signing on a very secure machine, such as a Hardware Security Module, which further reduces risk The real Devices must perform public key operations for each update. Devices are exposed to increased risk from old firmware. Devices must download the whole image before they can check the signature. 16
Firmware update: transport security and code signing? Code signing has significant benefits for security Widely accepted practice in software, driver distribution. Signed metadata takes this one step further, offering early validation. Transport security offloads the burden of access control 17
Firmware update: Privacy
Firmware update privacy To avoid exposing the firmware to a third party, it should be encrypted. Encrypt the firmware image for each device Encrypt the firmware image for all devices 19 Device
Firmware update: which kind of privacy? Single image encryption has a lot of benefits. Each option requires some amount of key management. Single image encryption is the most scalable. Exposure of payload contents is of equal risk for each of these solutions. 20
Firmware update: Monitoring
Firmware update monitoring Devices need to report: Their current firmware version The status of the last update Progress of the current download The types of payloads accepted Each device reports its invariant information when it connects to the monitoring server. Devices report variant information when it changes. 22
Building firmware Update
Building firmware update It seems like it should be easy There are many subtle ways that things can go wrong in five areas: Selection of which devices to update Device resilience to power failure, network loss, etc. Management of the authority to update devices Privacy of the updates Status monitoring of devices targeted by an update Each of these issues requires careful considerations and tradeoffs 24
Mbed Cloud: Secure software update at IoT scale Developer Publish Firmware Mbed Cloud Update Service Device Client Applies Updates Code Development Prepare Update Package Publish Package Setup Campaign Distribute Package Verify Package Apply Recover Developer Publishes Firmware Account Admin Manages Campaigns Software Developer Device Admin/ Service Manager 25
Mbed security architecture Mbed Cloud Client: strong security Cloud application platforms Lifecycle security Data Flow Management Deployment Management Mbed TLS Connectivity Service Provisioning Service Update Service Communication security Mbed TLS Connectivity Client Provisioning Client Update Client Mbed Cloud service Mbed OS Device security Crypto TL Mbed uvisor Conn TL Prov TL Device Hardware Update TL 26
Trusted Device Services Enable Data Analytics Device Onboarding Easy intuitive self-install and registration Device Configuration Match configurations to service subscriptions Device Monitoring Real-time visibility into the status of all connected devices Monitoring Device behavior analytics Remote Connectivity Apps with secure, real-time remote access Firmware Updates Policy driven firmware manager 27
Mbed Cloud A Platform for Secure Device Management Enables customers to quickly build large-scale, secure and future-proof IoT solutions 28
Thank You! Danke! Merci! 谢谢! ありがとう! Gracias! Kiitos! 29