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