security practices: are yours good, better or best?...–best: strong key pairs and execution...
TRANSCRIPT
1
Security Practices:Are Yours
Good, Better or Best?
Steve Pancoast
COO, Secure Thingz
Embedded World 2019
2
Agenda
Security Practices: Are Yours Good, Better, Best?
Trust & Security: Standing in the way of IoT
Key aspects of IoT security
Security Concepts – Identity, RoT, Secure Boot, Secure Update
Available MCU & SE Components
IoT System Practices – Good, Better, Best
Security across the product lifecycle
Embedded Trust
3
Trusting IoT Devices…
www.redalertlabs.com
4
Security Issues are Inhibiting IoT Adoption
Security issues is one of the leading barriers of IoT adoption!
Customers would pay more & implement more devices if security was better
Less than 4% of new IoT devices have significant embedded security (2018)
By 2022, secure devices will be only 20% of new IoT devices(Sources: Bain 2018 IoT customer survey, ABI Research 2018)
(Sources: Bain - IoT Cybersecurity Infographic Oct 2018)
5
Key Aspects of Security for IoT Products
Understanding the legal requirements and codes of practice for your market
Understanding the attack vectors for your IoT product
Understanding your unique security requirements for your IoT device
What HW components are available that can help meet your requirements?
What SW & Security tools are available to help with the security development of your IoT device?
6
Security Concepts - Identity
Device Identity – Unique identify for each device / product
– Good: Unique Immutable ID– Unique identifier that is not easily predictable and is immutable– Ex: UUID, Random Device Serial Number, etc– Issues: Cannot verify device identity, can be easily cloned / copied
– Better: Verify the ID– Certificate based identity helps to verify device ID– Ex: OEM signed cert containing device serial number– Issues: Certificates can still be copied / cloned
– Best: Verify ID and Authenticate ID– Device contains a unique asymmetric key pair (Device key pair)– Plus an OEM signed certificate that contains device public key– Device can be authenticated that it owns the private key – Issues: Device private key must be kept secret
Public
7
Security Concepts – Root of Trust
Root of Trust – Trusted anchor point for various services
– Good: Device ID Only– Strong Device ID key pair– Issues: Common key pair used for multiple services
– Better: Device ID and SW Update Key Pairs– Separate key pair for Device ID / Authentication– Separate key pairs for SW updates (signed SW updates), etc.– MCU contains MCU provider certificate to validate genuine silicon– Issues: How to revoke key pairs when compromised
– Best: Strong Key Pairs and Execution Protection– Execution isolation / protection via TZM or a Secure Enclave– Secure Enclave supports PKI methods for key management
8
Security Concepts – Secure Boot
Secure Boot – A way to ensure / verify the booting process
– Good: Locked Boot Image– Boot image is programmed into memory & locked (write protected)– Boot image verifies the application (hash) before executing– Boot process is immutable - MCU debug is disabled / locked– Issues: No verification of booting SW image, storage of hash values
– Better: Verified Boot Image– Boot image is hash verified by MCU ROM or HW prior to execution– Trusted hash values are stored in a secure storage – Issues: Application can access / read boot image, integrity of trusted hashes
– Best: Signed Images and Platform Integrity– Boot execution / image protected by TZM or other HW protection– SW image signatures are used along with trusted signer certificate– Secure Enclave that manages image verification and PKI for trusted signatures
Boot
9
Security Concepts – Secure Update
Secure Update – A way to ensure / verify SW updates beforehand
– Good: Signed SW update images– Update image is signed (hash is signed by verifiable trusted private key)– Certificate of approved signer is kept in secure storage– Issues: Update image is not encrypted and can be applied to any
device
– Better: Encrypted SW update images– Device certificate is readout and verified by system performing update– Signed update image is encrypted for the specific device – Encrypted image decoded inside the MCU and SW IP is protected– Issues: Management of signing certificates and revocation
– Best: Platform Integrity– Secure Enclave running firmware for Secure SW update protocol– Secure Enclave that manages PKI for trusted signatures
10
Available MCU & SE Components
MCU plusSecure Element
MCU and separateSecure Element
Multi-coreSecure MCU
Security subsystemas part of multi-core
processor
SecureEnclave
Good Better Best
Standard MCUFully integrated
Secure MCU
MCU includes hardwarecrypto unit and memory
protection features
11
Good Practices for Secure IoT Systems
OEM Application3
OEM Identity2
Secure Boot Loader1
System Flash
Secure Device Config Regs
MCU IntfProgrammingSystem
RAM Area
System RAM
A good system (HW & SW) should provide the following:
(3) OEM’s Application code. Main application code is signed and verified prior to execution . Must be updated only by Secure Boot Loader.
Using Traditional MCU. OEM develops Secure Boot Loader and Application code. Protection of keys during programming can be a concern and OEM developers must be trusted.
(1) Secure Boot Loader. Verify signatures and applies ALL SW updates and verifies Application signature before running.
(2) OEM’s identity. (signed certificates & keys). Enables product identification, authentication and secure SW updates. This identity & key block should be unique per product. Keys not protected via secure key store in this class if MCU.
Armv7-M
(Minimal)
12
Better Practices for Secure IoT Systems
OEM Application
Non-Secure5
RoT Keys& Certs1
OEM Keys& Certs3
App Keys
OEM Secure Code (TZM)4
Secure Loader2
SBM
Secure Key Storage
System Flash
Secure Device Config Regs
Armv8-M TrustZoneMCU IntfProgrammingSystem
Non-Secure
Secure Area
System RAM
A better system (HW & SW) should provide the following:
(5) OEM’s Application code. Main application code is signed and verified prior to execution . Can be securely updated. Should run in non-secure mode.
(1) Secure MCU with a HW RoT. Authenticates genuine MCU, enables secure provisioning, establish OEM’s RoT
(2) Secure Boot Loader / Manger. Ensures secure boot and enables secure Application loading & updates.
(3) The OEM’s Secure identity (signed certificates & keys). Enables product identification, authentication and secure SW updates. Uses HW Secure Key Storage
(4) OEM’s Secure Code. Software that needs to be secure and protected at Run-Time. Can be securely updated.
v8M Call Gate
13
Best Practices for Secure IoT Systems
OEM Application
Non-Secure4
RoT Keys& Certs1
OEM Keys& Certs2
Isolated MCU& memories
OEM Secure Code (TZM)3
Secure Enclave
System Flash
Secure Device Config Regs
Armv7 or v8-MMCUs IntfProgramming
System
Non-Secure
Secure Area
System RAM
Best system practices (HW & SW) should provide the following:
(4) OEM’s Application code. Main application code is signed and verified prior to execution. Can be securely updated
(1) Secure MCU with Secure Enclave & RoT. Isolated Security Enclave that provides secure key storage, secure boot, secure provisioning & SW updates and PKI support
(2) The OEM’s Secure identity (signed certificates & keys). Enables product identification, authentication and secure SW updates with OEM’s own keys
(3) OEM’s Secure Code. Software that needs to be secure and protected at Run-Time via TZM. Can be securely updated
Via Mailbox, etc
15
Secure Development Tools
Integrates identity and certificate management
Implements a Secure Boot Manager
Protects your IP by inhibiting unauthorized manufacturing
Provides secure deployment with integrated manufacturing mastering
Enables release management with versioning and update infrastructure
Embedded Trust™ Security Development Environment
Adding security functions to IAR Embedded Workbench
Enables secure mastering
C-Trust for IAR Embedded Workbench
16
Secure Thingz
17
Thank you
For more information please visit
securethingz.com