1. Proportional security to meet the business needs of IoT
Nick Zhou / Senior Field Application Engineer / ARM
Our motivation is generating IoT business
Trust is a key. In the past several multi-billion dollar industries, such as e-commerce, have been built on this foundation of trust between cloud, desktop and mobile systems.
An IoT Big Data provider needs to trust the device, its identity, the accuracy of its data etc.
In the Internet of Things we need trust to establish secure relationships and communication across large device deployments, supply chains and the cloud. 
When we establish trust securely and reliably, we enable many additional benefits including data protection, new business models and lifecycle management all the way from chip production to device deployment in the field. 
Our goal here is to embed this trust into the security systems of IoT providing the foundation of new multi-billion dollar industries which will be built on the IoT.
mbed Connect Asia / Shenzhen, China
Dec 5, 2016

2. Invest in IoT security according to business needs
Protection/ authentication of transmitted information
Protection of device from software vulnerabilities
Protection from physical intervention
Local asset value requirements
Deployment integrity requirements
Communication trust/privacy requirements
Deploying security technology has an NRE cost (and failing to deploy appropriate technology may have a large lifecycle/business cost). The correct choices need to be made up front when creating the IoT based service/application/deployment.
Business needs should determine trust requirements
Trust requirements (or threat models) determine where investment in security technology will be most effective for the business

3. Diversity
IoT applications are incredibly diverse. This is not a “one size fits all” problem.
You can not only implement the “lowest common denominator solution”. IoT needs a flexible security framework that can be configured according to each businesses needs. The requirements are vastly different across devices, applications and markets.
Later we will show more details on how security capabilities vary for these example devices.

4. End node device and deployment conditions
Connected to a network
May have a long lifetime
May be physically inaccessible for manual updates
Must be able to be managed remotely
May be physically accessible to third parties
Must protect against physical access
Deployed in enormous numbers
Represents a significant investment to protect/maintain
(may have) a long lifetime
(may be) physically inaccessible
If you want to be able to handle IoT devices generically you DO need to be able to cope with the case where devices are physically inaccessible. In particular the device generally has no physical UI (for config) or a button to trigger device reset. If you want to power cycle the thing you can't go find it and pull the battery out. If it gets infected with malware then you can't take the HDD our and reformat it. etc. etc
Even if a device is physically accessible then you don't want users to have to do that sort of thing and you don't want to pay field/installation engineers to go to each IoT end node and do these things.
remote management is a must & remotely updatable/recoverable too

5. Learn from internet security best practices
Internet security evolving for decades
Leverage this heritage for IoT end nodes
Low cost, long battery life nodes are capable
Think about agility post deployment – security is not a fixed thing
Security is about the weakest link
Look for flaws in protocol and security architecture
Avoid deployment mistakes and mismanagement
Learning applicable to both IP and non-IP IoT communication
Find ways to work with existing deployments/technology
Drive the future direction of relevant standards
Internet Security has been constantly evolving for decades
Opportunity to leverage this heritage for IoT end nodes
Key security mechanisms that must be used
Don’t underestimate the capabilities of low cost, long battery life end nodes
Not a good idea to reinvent the wheel (non-IP) for end nodes – easy to repeat past mistakes
Security is about the weakest link
Flaws in protocol and security architecture
Deployment mistakes and mismanagement

6. Bluetooth headset linked to cloud service via Smartphone App
IoT use cases
Bluetooth headset linked to cloud service via Smartphone App
Building Automation System OEM covers many client buildings using a diverse set of device types with live connectivity to a cloud service

7. A few security technology choices
Protection/authentication of transmitted information
Use standard BLE relationship between Smartphone and headset to pair devices and setup link security
Protection of device from software vulnerabilities
Device is not directly addressable on the internet
Direct attack unlikely if paired device runs trusted SW
Protection from (local) physical intervention
Limited local threats
Limited device asset value
Treat network as untrusted and use DTLS to establish secure connections based on certified device identities
Strong security to establish/authenticate DTLS sessions (ECC) limits device access
Additional device partitioning can vastly reduce local SW attack surface
Device identity and (device unique) service keys must be protected
Need security in supply chain to prevent installation of cloned devices

8. Security profiles Minimum cost/effort to attack
Where possible devices should not store valuable secrets
Local attacks must not enable network attacks on other devices
Minimum
cost/effort
to attack
Lab attacks
Local attack on an end node device
Some applications require tamper resistant devices
ARM SecurCore and related technology
Network attacks
Remote attacks across the network
May scale to many devices; accounts; services
Explain "network attack" vs "lab attack”
Introduce the idea that in some applications it is not necessary to store valuable secrets on an end node (and in fact it is desirable to avoid it in these cases) then a successful lab attack on one device should gain nothing and not enable general attacks on other devices
[Another aspect to highlight: The benefit that the secret brings should be smaller than the effort to get hold of that secret]
The mbed offering (e.g. the SW itself) is focused on security related to network attacks
Some apps will need to store valuable secrets on a device
In these cases we need to deploy tamper resistant techniques in the Si and technology such as ARM SecureCore enables this.
Further notes:
If you have a
private key stored on a device then that private key really should be
specific to that device. So if an attacker gets hold of that private key
then they can only pretend to be that device. The attacker gains no
information that would enable it to hack the entire network of all of the
devices (keys or access control info etc).
Also refer to "other secrets" e.g. your bank account
details, your credit card numbers and the PIN for your card etc.
Clearly some apps need to hold "valuable secrets" on a device (in which
case tamper resistant techniques should be employed). However, the
security architecture should be designed such that the "value" of the
secrets that need to be stored on the device should be minimized (ideally
to the point where there is really no point spending extra $$$ to
implement tamper resistance of the device [for some applications]).
Per-device HW cost/effort
to secure

9. Proportional security
Threat-models should be informed by business requirements
Technology applied and cost expended varies according to application needs
For example
Risk environment of application
Value of assets to be protected
Trust and control over firmware
Supply chain structure
Lifetime of the device
Application
Security
Short life node
mbed TLS + Connect
Long life node
+ uVisor + Provision
+ Update
High value asset protection
+ Anti-tamper hardware (ARM SecurCore)
Security is not a black and white thing. It is not either on or off. It must be deployed in proportion to the need for security.
Before security thread-models are defined it is important to have a holistic view of business requirements.
Then appropriate security choices can be made (the cost and effort to be expended on a security solution is a factor here).
Even the most basic application which has static service session information determined at the time of manufacture (e.g. a fixed symmetric key) need fairly sophisticated security functionality. Communication security (as implemented by mbed TLS) enables the device to have basic authentication, confidentiality and integrity for data sent to and from it over the internet. The mbed Cloud Connect service is also provides the security required to use a specific device with a particular cloud application. Many IoT platforms don’t provide much more security than this but at this level it is impossible to securely provision new keys/certificates onto the device or update its firmware. This severely limits the useful lifetime of the device (or risks relying on a device deployment investment with little security protection). Also this limited device security means that valuable secrets can’t safely be stored on the device. As a result this level of security is best suited to disposable devices where the value of device deployment does not need to be maintained and the secrets on the device are low value.
Many applications will demand a larger investment in security. Adding mbed OS uVisor capability enables greater protection of secrets scored on the device and provides greater trust for device identity, integrity. This in combination with mbed Cloud Provision and mbed Cloud Update allows deployed device to flexibly connect to new services and form new secure relationships over its lifetime while keeping pace with changes to security standards and newly discovered protocol vulnrabilites. This protects business investment in large device deployments. At this stage the device can be trusted to implement most common IoT applications and to store important secrets with adequate protection.
Beyond this some specialist applications may require higher levels of security such as resistance to LAB attacks while storing very valluable secrets. This would required the addition of more expensive hardware counter measures and anti-tamper features. This can be supported alongside mbed OS security features.

10. Device SW capabilities Device HW resources
Ultra-constrained
Constrained
Mainstream IOT
BBC micro:bit
BT Smart beacon
Rich BT Smart
Thread node
Low BW WiFi node
Border router
BT Smart
Device SW capabilities
IP + TLS
uVisor
Lifecycle Security
Firmware over-the-air
Architecture
Acceleration
ARMv6-M
ARMv8-M Baseline
TRNG + Crypto
Device HW resources
ARMv8-M Mainline or ARMv7-M with MPU
Unconstrained
High BW WiFi node
Gateway
A-Class
TRNG + Crypto +
GPU + VPU
OP-TEE
Rich UI/Multimedia
mbed OS
A-Class + mbed Client

11. mbed security architecture
Cloud application platforms
mbed TLS
Connectivity Client
Provisioning Client
Update Client
Connectivity
Service
Provisioning
Update
Device Hardware
mbed uVisor
Prov TL
Crypto TL
Update TL
Conn TL
Deployment Management
Data Flow Management
Lifecycle
security
mbed Cloud Service
Communication security
mbed OS
The future mbed roadmap will deliver pervasive security across all of our device services (mbed Cloud) and device software (mbed OS; mbed TLS; mbed for X). This security covers many different aspects and exists in may different layers of our mbed IoT Device Platform. Broadly speaking we can categorize all these security aspects into three distinct areas:
Device Security: This comprises of all security aspects implemented in mbed Device Sofware running on IoT end nodes. Our roadmap for this includes SW functionality to implement security related to connectivity, provisioning and device update. These higher level rich protocol/functionality modules will be supported by basic security components that include secure boot; secure storage primitives; low level key management; device identity and cryptographic libraries supporting both full SW implementations and secure interfaces to hardware crypto accelerators. These basic security components can, optionally, reside within and be protected by Trusted Execution Environments (TEE) or secure supervisory kernels such as the mbed OS uVisor when this is supported by the device hardware. This adds additional protection by providing secure isolation of system resources for each software component.
Communication Security: Based on widely deployed and most thoroughly tested security available for internet communication today. mbed Communication Security is implemented by the mbed TLS library which provides all the functionality required to implement the full TLS and DTLS protocols. The mbed TLS library is use in the device software and within the mbed Cloud services. This provide end-to-end communication security from each end node into mbed Cloud across the internet.
Management Security: Implemented within our mbed Cloud services this enables secure lifecycle management for large deployments of end nodes. This will encompass secure device connectivity; secure device provisioning and secure device update services. This is vital to enable IoT deployments to scale. Critically our update service will enable agile security to be implemented across the entire mbed IoT Device Platform. This protects investment in large deployments and enables our IoT security to evolve alongside state of the art internet security. It will also provide secure links into Cloud Application Platforms so that entire IoT applications can be fully secured.
Device security

12. Call to action: Better security value proposition
Avoid selling via FUD
Generally unquantifiable: What is value of security investment? What is the ROI?
Enable reasoning: What security is for, the value it brings
Understand threats to business and what key assets are?
Measure complete deployment lifecycle value not just BOM cost
Do not treat Security Technology as a “One Size Fits All”
Deploy technology according to business needs
Proportional security response according to defined threats/value
Factor in agility to cope with evolving security context
Deliver scalable security choices for IoT driven by clear need/value
FUD: Fear, Uncertainty, Doubt