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
Title 40pt Title Case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
© ARM 2016 5
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
© ARM 2016 18
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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
Title 40pt Title Case
Bullets 24pt sentence case
bullets 20pt sentence case
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