Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Demystifying Security Root of Trust Approaches for IoT/Embedded - SFO17-304

699 views

Published on

Session ID: SFO17-304
Session Name: Demystifying Security Root of Trust Approaches for IoT/Embedded
- SFO17-304
Speaker: Suresh Marisetty
Track: LHG,LITE,Security


★ Session Summary ★
The current trend of IoT market segment is expected to enable and deploy about 50 billion connected devices by year 2020. IoT devices will be deployed across the board to cater to multiple use cases like Home/building Automation, Automotive, a highly fragmented embedded segment: gateways, set top boxes, security cameras, industrial automation, digital signage, healthcare, etc. This trend will bring about a great challenge of securing the connected end point IoT devices from a myriad of physical and remote attacks ex: DDOS Mirai botnet launched through IoT devices like digital cameras and DVR players

Problem Statement: Each use cases has its own IoT device constraints like: Cost, Power, Performance, memory footprint, security objectives, etc. The fundamental basis for any secure IoT and Embedded solution is the Root of Trust (RoT), which provides assurance of the integrity of the system software from: boot and runtime firmware, to OS loader, to the Kernel, to the user Applications. This poses a serious issue and challenges the one-size fits all RoT solution model.

ARM has taken on this challenge head on to come up with a microcontroller security architecture solution that caters to the various IoT devices constraints, by offering ARM Cortex-M family of processors. ARM’s flexible and scalable architecture solution will allow an OEM or Silicon partner to adapt the base security architecture and to extend it in a seamless way. This caters to the requirements of different market segments through add-on hardware, firmware and software security enhancements.

The session will present the ARM’s base security system and software architecture based on the upcoming Cortex V8M solution that will provide a hardware and firmware assisted Trust Zone based Security RoT aka TBSA-M for a range of markets, to include the highly constrained IoT devices. Furthermore, the session will discuss about how the base RoT capability can be extended in a seamless way with additional hardware assisted mechanisms to offer high levels of functionality and/or robustness for less constrained IoT devises with options like TBSA-M+, TBSA-HSM and platform level security software abstraction framework to decouple the chosen RoT capability for various OSes and the Cloud security frameworks.
---------------------------------------------------
★ Resources ★
Event Page: http://connect.linaro.org/resource/sfo17/sfo17-304/
Presentation:
Video: https://www.youtube.com/watch?v=aIwmRXFOshs
---------------------------------------------------

★ Event Details ★
Linaro Connect San Francisco 2017 (SFO17)
25-29 September 2017
Hyatt Regency San Francisco Airport

Published in: Technology
  • Be the first to comment

Demystifying Security Root of Trust Approaches for IoT/Embedded - SFO17-304

  1. 1. © 2017 Arm Limited© 2017 Arm Limited Demystifying Security Root of Trust Suresh Marisetty Security Solutions Architecture IoT Device Security Summit
  2. 2. © 2017 Arm Limited22 Agenda • The Landscape • Problem Statement • What’s RoT? • RoT Models • Beyond RoT • IoT Offerings • Conclusion
  3. 3. © 2017 Arm Limited33 Connected IoT Devices – Everywhere And more … Security camera
  4. 4. © 2017 Arm Limited Problem Statement
  5. 5. © 2017 Arm Limited55 Robustness Against Malicious Attacks  The three fundamental elements of security  Confidentiality  Integrity  Availability  Others  Non-Repudiation  Authentication
  6. 6. © 2017 Arm Limited66 Security: Threats, Attacks and Defenses Communication Attacks  Man In The Middle  Weak RNG  Code vulnerabilities Software Attacks  Buffer overflows  Interrupts  Malware Physical Attacks  Fault injection: clock or power glitch, alpha ray  Side channel analysis  Probing, FIB Life Cycle Attacks  Code downgrade  Integrity vulnerabilities  Factory Oversupply Defences Threat Focus: Hardware enforced Defences: • Scalable Software Attacks • Low Cost Hardware tampering • Economically Viable Attacks
  7. 7. © 2017 Arm Limited Hardware Enforced Root of Trust (RoT)
  8. 8. © 2017 Arm Limited88 Generic IoT Security Requirements Automotive •Unique device identity provisioning •Secure boot •FOTA update •Secure debug •IP config/feature provisioning •IP protection/secure firmware validation •Data integrity •IP protection and anti-counterfeiting •Right to repair •User data confidentiality •DRM Healthcare •Unique device identity provisioning •Secure boot •FOTA update •Secure debug •Secure HW key storage •IP protection and anti-counterfeiting •IP config/feature provisioning •Data integrity •Data Privacy (HIPPA) •Functional safety (actuators) Industrial •Unique device identity provisioning •Secure boot •FOTA update •Secure debug •Facility ops •Secure video monitoring •Telematics/fleet management •Data Integrity •IP protection and anti-counterfeiting •IP config/feature provisioning •Functional safety Wearables •Unique device identity provisioning •Secure boot •FOTA update •Secure debug •User data confidentiality •Data integrity •IP protection and anti-counterfeiting Home •Unique device identity provisioning •Secure boot •FOTA update •Secure debug •Privacy and data confidentiality •Data integrity •IP protection and anti-counterfeiting •IP config/feature provisioning ?
  9. 9. © 2017 Arm Limited99 Initial Root of Trust & Chain of Trust Provisioned keys/certs Initial Root of Trust: Dependable Security functions Extended Root of Trust e.g. TrustZone based TEE Trusted Apps/Libs RTOS Apps OS/RTOS Trusted Software TrustZone Extended Root of Trust iROT TrustZone CryptoCell Keys
  10. 10. © 2017 Arm Limited1010 Basic Security Requirement – Root of Trust  Embedded Boot ROM with the initial code needed to perform a Secure system boot in a secure environment – Initial boot block (aka IBB)  IBB executed by a trusted hardware engine by design  Execution environment fully contained to prevent altering of the boot flow  Crux of the Problem - One size does not fit all… • Different market segments with various constraints: Cost, Power, Latency, Performance, etc. • IoT end point device constraints dictate the packaged solution
  11. 11. © 2017 Arm Limited1111 Secure Boot – Assured Software Integrity FLOW:  Chain of trust starts with initial boot block (IBB) that is immutable  IBB is a trusted entity owned by Si Vendor and/or OEM  All software images beyond IBB are digitally signed  X.509 certificate is industry standard based on PKI (RSA or ECC)  IBB hash-verifies the first image that is loaded  Each subsequent image is hash verified by the prior to establish a chain of trust .. 1 2 3
  12. 12. © 2017 Arm Limited1212 Primer - Trusted Platform Module (TPM) Overview  Standard defined by the Trusted Computing Group  Availability  Hardware chip currently in 100+M laptops  HP, Dell, Sony, Lenovo, Toshiba,…  HP alone ships 1M TPM-enabled laptops each month  Core functionality  Secure storage  Platform integrity reporting  context for this discussion….  Platform authentication
  13. 13. © 2017 Arm Limited1313 Measured Boot – Software Integrity Measurement FLOW:  Chain of trust starts with IBB that is immutable  All software images beyond IBB is dynamically measured at boot time  SHA-1 or SHA-2 Computation/Measurement recorded in TPM PCR  Each subsequent image is measured to produce a combined hash chain value  Changes in the executing code can be detected by comparing measurement of executing code against golden recorded value  The measurements themselves must be protected from undetected manipulation .. 1 2 3
  14. 14. © 2017 Arm Limited1414 Secure vs. Measured Boot – Same End Goal Attribute Secure Boot Measured Boot Software Integrity Assured Assured Static Root of Trust for measurement Applies Applies Digitally Signed Software/Firmware Images Yes No HW RoT in SoC Required Required Core Root of Trust Immutable boot code in ROM Immutable boot code in ROM TPM Required No Yes
  15. 15. © 2017 Arm Limited RoT Models
  16. 16. © 2017 Arm Limited1616 Wide Applications Constrained Applications Secure Smart lock Ultra efficient Smart bandage Safe Medical Nanorobot Ubiquitous Asset tracking A M J A M J Engine Control Airbag Actuator Power Steering (EPS) Transmission Stability Control (ESC) Sensor Cluster GatewayIVI/Head Unit (V2X) Body EVITA FULLEVITA MediumEVITA Light HSM Security Level Diverse IoT Endpoints – No One Size HW RoT Fits All Within IoT Device – Diverse Function Endpoints Diverse Security Requirements
  17. 17. © 2017 Arm Limited1717 RoT – Myriad of Options Key Options • No Explicit RoT • TrustZone RoT • SE RoT • SE w/ TrustZone RoT More Robust Less Robust Higher Cost Lower Cost PE, No SE or TrustZone (1)** Single PE with TrustZone (2) Non- TrustZone PE + Non- TrustZone SE (2) TrustZone PE + TrustZone SE (4) TZ PE + Non- TrustZone SE (3) Non- TrustZone PE + TrustZone SE (3) Security Enclave RoT Standard RoT Enhanced SE RoT Enhanced App CPU + Enhanced SE RoT Enhanced App CPU + standard SE RoT (x) no. layers of security No Explicit RoT ** Hardware state-machine or CPU microcode extensions
  18. 18. © 2017 Arm Limited1818 What’s New? – TrustZone Extended to MCU-Family Increased Root of Trust Robustness non-trusted trusted  Confidentiality of SiP SW IP  Confidentiality of 3rd parties SW IP trusted drivers trusted hardware valuable firmware  Sandboxing trusted drivers trusted hardware certified OS / functionality trusted drivers trusted hardware trusted software crypto TRNG trusted hardware secure system secure storage Motivation – Address IoT Device Robustness Requirement
  19. 19. © 2017 Arm Limited Foundation - RoT
  20. 20. © 2017 Arm Limited2020 Beyond RoT – Basis for Secure/Protected Partitions RoT Secure Partition Isolation Dependency No Explicit Memory Management MPU and MMU - Hypervisor TrustZone Hardware Enforced Secure and Non-Secure Worlds with multiple protected partitions Security Enclave (SE) Secure Container with Secure Monitor or RTOS TrustZone PE and Security Enclave Two mechanism co-exist, more flexibility, more complexity Security Enclave with TrustZone Highest level of robustness with multiple secure partitions
  21. 21. © 2017 Arm Limited2121 Security by Separation  Protect sensitive assets (keys, credentials and firmware) by separation from the application firmware and hardware  Define a Secure Processing Environment (SPE) for this data, the code that manages it and its trusted hardware resources  The Non-secure Processing Environment (NSPE) runs the application firmware  Use a secure boot process so only authentic trusted firmware runs in the SPE  Install the initial keys and firmware securely during manufacture Platform hardware Secure partition manager Device management Application Non-secure processing environment (NSPE) Secure processing environment (SPE) Secure boot Root of Trust keys RTOS
  22. 22. © 2017 Arm Limited IoT Offerings
  23. 23. © 2017 Arm Limited2323 Cortex-M33: Security for Diverse IoT Usages Security foundation  System-wide security with TrustZone technology Extensible compute  Co-processor interface for tightly-coupled acceleration Enhanced memory protection  Easy to program  Dedicated protection for both secure and non-secure states 32-bit processor of choice  Optimal balance between performance and power  20% greater performance than Cortex-M4  With TrustZone, same energy efficiency as Cortex-M4 Enhanced & secure debug  Security aware debug  Simplified firmware development Digital signal control  Bring DSP to all developers  FPU offering up to 10x performance over software
  24. 24. © 2017 Arm Limited2424 Cortex-M23: Security for Ultra Low-Power IoT Enhanced capability  Increased performance  Multi-core system support  240 interrupts  Hardware stack checking Security foundation  System wide security with TrustZone technology Ultra-high efficiency  Flexible sleep modes  Extensive clock gating  Optional state retention Enhanced & secure debug  Security aware debug  Simplified firmware development  Includes embedded trace macrocell Enhanced memory protection  Easy to program  Dedicated protection for both secure and non-secure states Smallest area, lowest power  With TrustZone, same energy efficiency as Cortex-M0+
  25. 25. © 2017 Arm Limited2525 Example RoT Models – ARM SoC Solutions RoT - SE  +Dedicated secure CPU  + RoT within an isolated subsystem  No Reliance on TrustZone for SE RoT  RoT- TrustZone {Client,M}  Reliant on TrustZone for RoT  Other
  26. 26. © 2017 Arm Limited Summary
  27. 27. © 2017 Arm Limited2727 Take Away – Executive Summary  Hardware RoT is a fundamental requirement for any type of secure device  Extend RoT functionality for isolated and secure partitions to assure robustness against attacks  Security Enclave (aka HSM) option can be implemented to increase robustness against attacks  Many end point connected devices exist with inherent constraints  High to low cost – enterprise servers to disposable devices  High to low power consumption – wall plugged to harvested power devices  One size does not fit all – one RoT Model insufficient  Use case, device protection profile, cost and power constraints will dictate the chosen model  M-Class TrustZone assist now allows flexible RoT solution choices across IoT  Full range of solutions with preferred security robustness is possible  Address global/national security issue of IoT robustness with enhanced RoT option – Ex: Mirai botnet
  28. 28. © 2017 Arm Limited2828 Q & A

×