how to build a secure iot a developer’s · we also need a trusted part of the device’s firmware...

1Copyright © 2019 Arm TechCon, All rights reserved.Copyright © 2019 Arm TechCon, All rights reserved.

#ArmTechCon

Clive WattsProduct ManagerSecure Thingz Ltd., UK

How to build a secure IoT device – a developer’s perspective

+

2Copyright © 2019 Arm TechCon, All rights reserved.

Agenda▪ Why should I care about securing my devices?

▪ End to End Security

▪ Attack Vectors

▪ Security Tools

▪ Security Architectures

▪ Critical Services work flow required

▪ Root of Trust

▪ Chain of Trust

▪ Signed & encrypted application software

▪ Secure lifecycle management process

▪ Summary


Why should I care about securing my devices?

IoT security matters

✓ Preserve brand capital

✓ Protect against software/IP theft

✓ Inhibit over-production and cloning

✓ Alignment with evolving regulatory compliance

✓ Protection against malware injection

✓ Enable high-value services & integrity

Secure IoT supply chain matters

✓ Security capabilities and testing integrated into product development

✓ Secured end-to-end supply chain ensures:

– Product authenticity

– Protected distribution & outsourcing

– Secure critical IP & software

– Trustworthy lifecycle management

– Secured critical update capability

– Management of secure services


Product Supply Chains are ComplexMany locations, multiple transfers

enterprise iot insights, 2017

All the news is about attacks here i.e.

IoT devices in service

But attacks can also occur here …

… and here

https://enterpriseiotinsights.com/20171201/security/iiot-security-supply-chain-of-trust-tag40-tag99


IoT Supply Chain is Complex and Global Many players, multiple attack opportunities

SoftwareApplicationDeveloper

IoTDeviceOEM

End User

Contract Manufacturer

SiliconPlatformVendor

ProvisioningCentre

ProgrammingCentre


Security issues

▪ Security is the leading barrier for IoT adoption (Bain 2018 IoT customer survey)

▪ Customers would pay more and buy more devices if security was better (Bain 2018 IoT customer survey)

▪ Less than 4% of new IoT devices with embedded security today (ABI Research 2018)

– By 2022 secure devices will be almost 20% of new IoT devices

Global IoT marketplace facts:

27 billion IoT

connections in 2025

$3 trillion total IoT

revenue opportunity

Over 2 zettabytesof data just by consumer devices


Security Considerations


Government Legislation

UK Department of Digital (DCMS) – June 2018– “Secure by Design: Improving the Cyber Security of Consumer IoT”

– Best Practices expected to have legislated enforcement within 5 years

California passes IoT Security law – September 2018– Starting on January 1, 2020,

– Any manufacturer of a device that connects “directly or indirectly” to the internet must equip it with “reasonable” security features, designed to prevent unauthorized access, modification, or information disclosure

US Government mulling cyber security act– Minimal cybersecurity operational standards for Internet-connected devices purchased by

Federal agencies, and for other purposes:

– Certification that the device has no known security vulnerabilities

– Notification mechanism for vulnerabilities; Update & patching mechanism

– Continuity of service (how & when updates released, EOL)

ENISA (EU Agency For Network And Information Security)– “The goal of this report is to elaborate baseline cybersecurity recommendations for IoT with

a focus on Critical Information Infrastructures, which encompass facilities, networks, services and physical and information technology equipment


Legislation – IoT Codes of Practice

• 13 outcome-focused, high-level guidelines. Top 3 are prioritised

• Brings together what is widely considered good practice.

• Focuses on what matters most. Not a silver bullet to all problems.

• Primary audience: device manufacturers

• Helps ensure GDPR compliance.

• Published in 8 languages.


Threat modelling


Attack Vectors


Attack Vector Types

• Man in the Middle

• Hack Attack

• Eavesdropping

• Shack Attack

• Lab Attack

• Denial of Service


Mirai botnet attack - 2016


Every Connected Device Affected


Critical Services for End to End

Security


Root of Trust is fundamental

The Security of an IoT device starts by having a secure “Root of Trust” (RoT)

The RoT typically consists of four key items:

• Unique identity

• Unique product asymmetric key pair

• Immutable boot path

• Authentication path - PKI Certificate

The RoT is realised in a Secure Boot Manager

The RoT must be securely provisioned into the product


Secure Update

A Secure Boot Manager should facilitate secure software updates

The Secure Update features to look for are:

• Verification of image via cryptographic hashing algorithm

– Ensures that image has not been modified during transport

• Image signature verification

– Ensure image has been provided by an approved source

• Decryption of encrypted image

– Ensures IP protection – image unwrapped inside device

• Management of signer certificates and revocation

• Device Certificate readout for chain of trust verification


What do we need?

We need an unforgeable way to authenticate:

• Is the device the OEM is talking to one that the OEM made?

• Is the device running legitimate firmware?

• How does the device know that it’s talking to the OEM?

• How does the device know a firmware upgrade came from the OEM?


How do we get this authentication?

Authentication requires a unique way to identify each device

Fortunately, cryptography gives us ways to accomplish this

• Use randomly generated cryptographic keys to provide uniqueness

• Cryptographic techniques are well proven and understood.

However, crypto isn’t enough


What else do we need?

We also need a trusted part of the device’s firmware to be immutable:

• Usually a bootloader

• May be coupled with a secondary bootloader

• Must have a silicon device that has a protected area of flash that gives us this immutable capability

• Must also be tamper-hardened

Boot


Hardware Option Examples

MCU

Flash

CryptoUnit

SRAMPUF

MCU

Flash

MCU

Flash

SecureArea

CryptoUnit

DeviceID

Standard MCUFully integratedSecure MCU

MCU plusSecure Element

Increasing level of MCU security features


Unique Identity

Need to create unique cryptographic identities for EVERY device provisioned.

Application DevelopmentProduction

Programming

Security Appliance

Export EncryptedProduction Package

Generate UniqueIdentity & Certificate

Secure Manufacturing System

Secure App Development


Provisioning a device

• Unique IDs and private keys (secrets) are programmed into the device together with the Secure Boot Manager (SBM)

• Provisioning must be carried out at a secure facility

• If a hardware security module (HSM) is used, functions for signing and mastering are executed within the HSM


Immutable Boot Path

An immutable boot path typically comprises:

• A micro-controller that includes:

– Capability to secure an area of memory (e.g.TrustZone, Flash Access Window)

➢ Secure storage of cryptographic keys

– A ROM based level one bootloader (typically programmed at the silicon level)

➢ Capability to authenticate a software image prior to execution

– Capability to disable unauthorised access via debug/JTAG ports

Secure Boot Manager configures the target microcontroller hardware to implement an immutable boot path


Chain of Trust


Digital Certificates

Root CA

(OEM)

Intermediate CA

(Product Line)

Device Certificate

(Product)

Certificates are used to authenticate an entity and provide a formal method of presenting a cryptographic Public key.

A chain begins with the entity itself and each certificate in the chain is signed by the entity in the next certificate in the chain.

The chain terminates with the root Certificate Authority.

All the signatures in the chain must be verified to create a Chain of Trust.

This system is commonly know as a Public Key Infrastructure (PKI).


Certificate Hierarchy Management

• Methodology for developing certificate hierarchy for IoT

– Graphical development environment

– Certificates & keys generated dynamically

– PC or HSM based

– Seamless transition from Development Certificates to Production

– Supported within production provisioning process

• Traditional certificate structure designed for IT

– X.509, CRL, CSR, etc.

– 3rd party CA reliance

▪ DigiCert, GlobalSign, etc.)


Signed & Encrypted

Application Software


Traditional Software Development flow

Developapplication

Test Release ManageManufacture

Build and debug the applicationDesign and develop the application code

010101111011101010

101010010101110101

010100000110101010

101010101010101001

010101010100101111

110000011010111101

001111010100100010

111101001111011011

001011110100100101

11100101110011100

1111100100101010101

0101001010011001010

1010101010101010001

0101111100101011101

0111100101010101010

0100101000011110100

1111010100100010111

1010011110011110101

0010111100

110101001010101111

001001110010100000

100100101100001010

00101000101001011

001011110100111101

001011110000001110

101100001010101111

Release image to

manufacturing

Find and investigate runtime errorsReview issues using static code analysis


Deploy ManageManufacture

DevelopSecurityContext

Build SBM, Provision device

TestDevelop

application

Security SW development flow

Create your Security Context, Build the

Secure Boot Manager and Provision the

device

001011110100111101010010001011110

100111111010110101010001111010101

101010110110110101010010100100100

101101010010100100011101000100101

1

001011110100000111100101101001010

10101

100101001110111100 0101101001011

0010111011010100100010101

0010111001011110111110100

1111001010101001101011000

010111100

Develop and Test the application

using development keysBuild using production keys,

then Deploy to Manufacturing

0010111101

0011110101

0010001011

1101001111

0101001011

0010111101

0011110101

0010111100

0101001011

0010111101

0011110101

0010111100

SBM

0010111101

0011110101

0010001011

1101001111

0101001011

0010111101

0011110101

0010111100

Mastered

Application


Mastering process

Prior to the deployment of any application software into the field, the completed application is Mastered.

The Mastering process includes the following:

• Exchanges all cryptographic keys used during development with production keys

• Exchanges all certificates used during development with production certificates

• Adds headers to the software image in order to provide the Secure Boot Manager with information that will help reduce power in the authentication/verification process.

• Encrypt the software image such that only a correctly provisioned Secure Boot Manager can decrypt

• Sign the software image using the private key of the approved authority


Mastering the application

• The signed and encrypted mastered application can be copied to unsecured memory in the target device (typical Over-the-Air (OTA) process)

• The target device is reset and the SBM manages the newly delivered data and flashes the new application to memory

<application>.srec

Signature

Encrypt

FW Encryption

SoftwareUpdateBlock

<application>.mastered.srec


Version Management


Product Lifecycle Management

Software strategy should presume obsolescence & system compromises

Implementation of a remedial framework is critical

• Active patching and versioning leveraging Root of Trust

• Patches should be signed and encrypted (where possible)

• Development environment must ensure version control & anti-rollbackfunctionality Root of Trust

TrustAnchors

Boot Services

App Security Services

Application

App Module 1 (v1.01)

App Module 2 (v2.0)

App Module 3 (v2.1)

Exec

uti

on

Do

mai

nB

oo

t D

om

ain


Version Management

A Secure Boot Manager should include version management.

Options include:

• No Checking

• Greater than or equal to current

• Greater than current

Prevents bad actors rolling back update to older versions that may have contained vulnerabilities


End to End Security Solutions


Secure System Development challenge

• Rapidly evolving IoT systems demands

• Semiconductor vendors reacting with ever increasing device complexity

• Tools must evolve to encompass security across the entire development flow– Leveraging security anchors (internal or external Secure Element)

– Automated development frameworks

– Certificate and Key Hierarchies

– Testability and first article creation

– Secure provisioning and update management


Delivering End to End IoT Security

LegislationSecure App

DevelopmentSecurity Key

ManagementSecure

Updates

DesignRequirements

Development and Test Manufacturing Lifecycle

Codes ofPractice

IP TheftPrevention

CloningPrevention

Secure Thingz Security Platform

Develop Manufacture Manage

Embedded Trust

Identity and CertificatesSecure Boot Manager

Secure Deploy Platform

Secure Provisioning Secure Programming

Device Management

Secure UpdateSecure Lifecycle Management

Threat Model

Protect against Malware


How do I get this security ?

Service Benefit Productivity Tool

Secure Manufacturing

System

Creation of Unique IdentityProvides authentication, secure communications and integrity

Creation of an immutable boot process Creates a Root of Trust

Provide Secure Update serviceResolve vulnerabilities, add services, life-cycle management

Generation of a Chain of Trust Implement PKI, certificate generation

IP Protection Secure application through encryption

Version management Prevents rollback (vulnerability exploit)

Secure ProgrammingPrevents unauthorised production (cloning/overproduction)


Secure Deployment

Secure Thingz enables a holistic approach to security which encompasses many disciplines


Questions ?


Trademark and copyright statementThe trademarks featured in this presentation are registered and/or unregistered trademarks IAR Systems AB and Secure Thingz Ltd. (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. All other marks featured may be trademarks of their respective owners.

Copyright © 2019

Thank You!

#ArmTechCon

how to build a secure iot a developer’s · we also need a trusted part of the device’s firmware...

Documents