The document discusses enhancing IoT security by applying principles from mobile security, focusing on ease of use for developers who are not security experts. It emphasizes the importance of secure design practices, OTA updates, and using standardized tools and components like Secure Partitioning Manager and ARM TrustZone. Key considerations for developers include threat assessments, data protection, and the integration of trusted software to ensure robust security in IoT platforms.

1. ©ARM 2016
A practical approach to securing
embedded & IoT platforms
Rob Coombs
Security Marketing Director
14/03/16
EmbeddedWorld

2. ©ARM 20162
 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

3. ©ARM 20163
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

4. ©ARM 20164
Thanks for reading
For more information about security on ARM visit arm.com
Sign-up for the latest news and information from ARM

5. ©ARM 20165
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/

6. ©ARM 20166
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 isolatedTEE/SPM*
Secure Element
*Trusted Execution Environment
/ Secure Partitioning Manager

7. ©ARM 20167
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 hardware
secure
system
secure
storage

8. ©ARM 20168
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 OpenTrust Protocol (OTrP) are emerging

9. ©ARM 20169
Security is best with layers of hardware isolation
Security Subsystem
TrustZone
NormalWorld
IoT developer writes Apps
On top of his/her chosen RTOS
SecureWorld
= 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)

10. ©ARM 201610
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

11. ©ARM 201612
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

12. ©ARM 201613
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
firmware
Trusted boot
Payload dispatcherSMCCC PSCI
EL1
EL2
Secure device drivers
Hypervisor
Apps
ARMv8A /
Cortex-A
SoC
subsystem
Graphics
Video
Subsystem
Secure store
Physical IP
Trusted
apps
Payment
DRM
Rich OS
Device drivers
Trusted OS
A reminder of the architecture
Trusted
SW/HW
Key

13. ©ARM 201614
Privileged
Hardware Interfaces
NormalWorld Code Trusted Software
Device Drivers
Unprivileged
RTOS
MCU architecture becoming similar to mobile
Platform Code
ARM Cortex-M
v8-M
Microcontroller
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

14. ©ARM 201615
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

15. ©ARM 201616
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

16. ©ARM 201617
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

17. ©ARM 201618
 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
RNG
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

18. ©ARM 201619
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

19. ©ARM 201620
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?

20. ©ARM 201621
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,ARMTrusted Firmware & standardised function calls
(CMSIS) that the industry can adopt to have some common architecture and
methods

21. 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