A practical approach to securing embedded and io t platforms

Title 44pt Title Case

Affiliations 24pt sentence case

20pt sentence case

© ARM 2016

A practical approach to securing embedded & IoT platforms

Rob Coombs

Security Marketing Director

14/03/16

Embedded World

© ARM 2016 2


Bullets 24pt sentence case

bullets 20pt sentence case

What can we learn from mobile security and apply to IoT?

Building on proven security principles & Secure Partitioning Manager

What can be done to make the IoT developer’s job easier?

Summary

Agenda

© ARM 2016 3




October 21 ‘16 – IoTBotnet attack

“….100,000 malicious endpoints. We are able to confirm that a significant volume of

attack traffic originated from Mirai-based botnets.” (Dyn, Attack analysis)

DVR

© ARM 2016 4

Text 54pt sentence case Thanks for reading

For more information about security on ARM visit arm.com

Sign-up for the latest news and information from ARM

http://www.arm.com/products/security-on-arm/trustzone?utm_source=slideshare&utm_campaign=ew17

http://pages.arm.com/EW-Newsletter-sign-up.html?utm_source=slideshare&utm_campaign=ew17

© ARM 2016 5




How can we make IoT security as robust as mobile?

How do we design-in robust end-to-end security?

http://www.flickr.com/photos/jurvetson

/7408464122/in/photostream/

© ARM 2016 6




How much security to fit your needs?

SW & HW Attacks• Physical access to device

– JTAG, Bus, IO Pins,

•Time, money & equipment.

Software Attacks & lightweight hardware attacks• Buffer overflows

• Interrupts

• Malware

Communication Attacks•Man In The Middle

•Weak RNG

•Code vulnerabilities

Cost/effort

to attack

Cost/effort to secure

TLS/SSL

Security Subsystem

Hardware isolated TEE/SPM*

Secure Element

*Trusted Execution Environment

/ Secure Partitioning Manager

© ARM 2016 7




What can we learn from mobile & apply to IoT?

Device Security

Communications Security

Lifecycle Security

trusted software

Crypto

Root of Trust

non-trusted

trusted

trusted hardwaresecure

system

secure

storage

© ARM 2016 8




Keep it agile - enable OTA updates

All code contains bugs and vulnerabilities

Vulnerabilities need to be patched before they are exploited

IoT needs to take the Mobile platform approach & push out regular updates

that fix security vulnerabilities as well as improve functionality

For microcontroller based systems standards such as LWM2M can provide a

common protocol

For management of security domains and trusted code, standards such as

GlobalPlatform TMF and IETF’s Open Trust Protocol (OTrP) are emerging

© ARM 2016 9




Security is best with layers of hardware isolation

Security Subsystem

TrustZone

Normal World

IoT developer writes Apps

On top of his/her chosen RTOS

Secure World

= Trusted code (mostly libs)

Provided by MDK, IoT platform or ISV

+ Trusted hardware

Security subsystem

Highly evaluated code developed

by security specialists & built in by

silicon vendor

(TCB)

© ARM 2016 10




Platform security = TEE + Security subsystem

Applications

Trusted Execution Environment isolation

RNG

Cryptography

Persistent trusted storage

Data protection

(off-line, runtime)

Rollback

protectionSW

updates

validation

Lifecycle

management

Debug

authentication

Code

encryption

Loaded SW

validation

Security subsystem

provides HW based

security “toolbox”

ARM TrustZone provides

isolation between normal

world code and the Trusted

Code Base

© ARM 2016 12




Building on proven security practices

Mobile security architecture has evolved to provide robust protection against

common attacks

Uses principles of hardware ”Compartmentalization” and “Least privilege”

Use a hardware root of trust & trusted boot

Ensure system is updatable

IoT architecture can re-use proven security practices

However, ease of use (of security functions) is much more important for IoT

© ARM 2016 13




ARM TrustZone based TEE on mobile systems

GlobalPlatform

standardization

Initial RoT &

security subsystem

TrustZone-based

TEE

Common foundation

Hardware Interfaces

Normal world code Trusted software

ARM

trusted

firmwareTrusted boot

Payload dispatcherSMCCC PSCI

EL1

EL2

Secure device drivers

Hypervisor

Apps

ARMv8A /

Cortex-A

SoC

subsystem

Graphics

Video

Subsystem

Secure store

Physical IP

Trusted

appsPayment

DRM

Rich OS

Device drivers

Trusted OS

A reminder of the architecture

Trusted

SW/HW

Key

© ARM 2016 14




Privileged

Hardware Interfaces

Normal World Code Trusted Software

Device Drivers

Unprivileged

RTOS

MCU architecture becoming similar to mobile

Platform Code

ARM Cortex-M

v8-MMicrocontroller

TRNG

Unique ID

Subsystem

Secure Storage

Physical IP

Secure Partitioning Manager

Trusted

Libs

Crypto

Attestation

TrustZone based

Partitioning Manager

Comms Stack

Apps/User TLS/Crypto Libs

Initial ROT &

Security subsystem

CMSIS API

TrustZone enabled MCU

© ARM 2016 15




IoT security needs to be easy / designed in

Most IoT developers are not security experts

Little to no knowledge of hardware

Prior experience in mobile app development

Time to market & functionality beat security

Ease of use requirements on tools & IoT platform providers

Hide complexity of hardware based security

Provide built-in security functions

Use standard methods and building blocks

Situation

Strategy

© ARM 2016 16




Dev tools need to hide security complexity

Trusted software can be provided as libs

IoT developer just needs to make function calls to secure world

Development can start on models

© ARM 2016 17




Function calls to trusted code can be standardized

RTOS running in Non-Secure state: RTOS

functionality available to Non-Secure and

Secure software

Full-featured RTOS for Non-Secure Application

Supports function calls to Secure state

Callback events from Secure state

CMSIS* provides common API

Secure state provides data and firmware

protection

Non-secure state Secure state

Application Library Functions

System Monitor

*Cortex Microcontroller System Interface Standard

https://github.com/ARM-software/CMSIS_5

https://github.com/ARM-software/CMSIS_5

© ARM 2016 18




ARM is creating a SPM as a new Open Source Software project

to provide partitions for critical code

A framework for multiple vendors to work within

Available as a common piece of middleware for the industry

ARM mbed uVisor is an example implementation of SPM

SPM works with a system’s available HW capabilities to provide

mutual separation of security functions

Exposed code never sees critical keys/secrets

Vulnerabilities on exposed side can’t affect critical side

Critical side can reliably recover device to clean state

A security foundation: Secure Partitioning Manager (SPM)

Application

Protocol

SSL Library

Diagnose

WiFi Stack

BLE Stack

Device Management

Secure

Storage

Crypto

Keys

Secure ID

Crypto API

Firmware

Update

RN

G

Public

Public Private

Firmware

Update

Secure

Storage

& Crypto

Keys

Crypto

API

Secure ID

WiFI/BLE

Stack

Application

TLS Library

Device

Management

RTOS

Exposed Critical

Firmware

Update

Secure

Storage

& Crypto

Keys

Crypto

API

Secure ID

WiFi/BLE

Stack

Application

TLS Library

Device

Management

Scheduler

SPM isolation of critical code

© ARM 2016 19




Consider using an IoT platform

If you want to develop an IoT product but are not a security specialist then an

IoT platform that comes with OTA updates, trusted libs & support of TrustZone

hardware security features is a sensible option

© ARM 2016 20




Questions to ask your dev team

1. Are OTA updates enabled?

2. Do we have a threat model/ risk assessment?

3. How do we protect data in flight?

4. How are keys provisioned and protected?

5. Do we use a HW-ROT?

6. Do we use any shared private keys or credentials?

7. Who is doing the security evaluation/ penetration testing?

8. How do we handle reported security vulnerabilities?

© ARM 2016 21




Summary

By careful selection of IoT platform and chip the developer can make use of a

proven mobile security architecture

IoT needs to be made easier for IoT developers who are not security experts

The dev tools must be easy to use

Trusted code should be supplied by the IoT platform, tools vendor or ISV

ARM is working on open source enablement software such as Secure

Partitioning Manager, ARM Trusted Firmware & standardised function calls

(CMSIS) that the industry can adopt to have some common architecture and

methods

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

Technology

A practical approach to securing embedded and io t platforms