October 4, 2016

Santa Clara Convention Center

Mission City Ballroom

Lifecycle Management

and Security

Joe Pilozzi

Recap

The Modern World 3

Connected Devices are Being Attacked• Good Practices

• To truly understand the value of Assets

• Threats and Risk Analysis

• The role cryptography plays

• Tips to aid in the design of resilient

products

• Important Characteristics

• Confidentiality

• Availability

• Integrity

• Most attacks today are software based

Source: Engadget

STM32 Security Features

• Security Features

• Unique Identifier

• Hardware Cryptographic Accelerators

• True Random Number Generator

• Memory Protection Unit

• Firewall

• Debug Port Access Control

• Tamper Detection

• Cryptographic Libraries

• Secure Boot

• Secure Firmware Upgrade

4

STSAFE-A100 Product Summary 5

Authentication, wrap/unwrap

Signature verification

Secure channel with server (TLS)

Secure data storage, 6Kbytes (configurable as counter)

Features

Personalization

STSAFE-A100

Personalization service available

Certification CC EAL5+ HW (Jan. 16)

Crypto AES-128,256; ECC-256, 384 (Brainpool or NIST)

Package SO8N, DFN2*3

Communication I²C

Securing Assets

Securing Assets 7

Cryptographic keys required to:

Authenticate firmware update signature

Encrypt end-user / end-node data

Authenticate device to network / service

Authenticate service / network to device

Securing Assets 8

Keys must be protected to some defined ‘level’

• Interface layerCloud Service

• Example AppsApplication Layers

• Drivers

• Libraries

Software Layers

• Embedded Code/ Firmware

Hardware

Tru

st

External (Flash) Memory

Secure partition

Internal Secure Memory

SRAM

Secure Hardware

Register Fuse

Securing Assets 9

• Impacts cost

• Impacts supply chain decisions

• Impacts debug availability

• Impacts Failure Analysis

Factors affecting where / how to initialize keys

ConsumerProduct

Personalization

Product

Manufacture

Code

Keys / Certs

Threats and Levels

Security Process 11

Security functions:

- Technical requirements

- Security level

Per Sector / application perform:

Security requirements

Implementation

checked against

requirements

Architecture model

Policies and procedures

Risk assessment

Privacy Impact assessment

Security Threat Levels 12

CasualViolation

Means

Resources

Skills

Motivation

Level 0 Level 1 Level 2 Level 3

Safety Security

Security Threat Levels 13

Low

Generic

Low

IntentionalCasual

Simple

Violation

Means

Resources

Skills

Motivation

Level 0 Level 1 Level 2 Level 3

Safety Security

Security Threat Levels 14

Sophisticated

Low Moderate

Generic

Low

IntentionalCasual

Simple

Specific

Moderate

Violation

Means

Resources

Skills

Motivation

Level 0 Level 1 Level 2 Level 3

Safety Security

Security Threat Levels 15

Low Moderate Extended

Generic

Low

IntentionalCasual

Simple

Specific

Moderate High

Violation

Means

Resources

Skills

Motivation

Level 0 Level 1 Level 2 Level 3

Safety Security

Sophisticated

Changing Threat Levels 16

ConsumerSoC ManufacturingSales /

Distribution

Manufacturing Phase

PackagePersonalizationProduct

Personalization

Certified Secure Facilities

In-field

Updates

Product

Manufacture

Code

Keys / Certs

Threat Level

Basic Functional Compliance 17

• Device operates within a defined boundary

• Normal ‘electrical’ use of the device / service

• Misbehavior of the device is difficult to detect

Level 0

ZERO

Basic Functional Compliance 18

• Examples:

• Physical removal of device from location (e.g. doorbell, remote sensor)

• Cost / Attackers’ level of sophistication

• Cost: none

• Sophistication: No specific skills or resources needed

Level 0

LOW

Software and Device Attack Resistance 19

• Expected and unexpected input / commands are used in a way which

gains unauthorized access / use without breach of the device’s outer

case:

• Normal / abnormal ‘electrical’ use of the device / service

• And / Or device has been removed from end-use location, or stolen before end-use

deployment and subjected to indefinite command / environmental attack

• Can be mounted by a legitimate owner or system adversary and may yield secrets which

can compromise the system

Level 1

Software and Device Attack Resistance 20

• Examples:

• Flood attacks, buffer attacks, triggering an error while using known software

upgrade commands

• BotNet, Bricking, for open MPU systems

• Cost / Attackers’ level of sophistication

• Cost: Low in terms of equipment

• Sophistication: Low – hackers with only software skills exploit poor security,

and errors in firmware to gain secrets / control

Level 1

LOW

LOW

Invasive Device Attack Resistance

• Outer case is removed (or not present during assembly /

manufacturing) to access component pins to mount attacks which:-

• Manipulate its environment then observe it closely while it is operating in or out of its

intended ecosystem (network)

• Manipulate electrical topology of device components / schematic

21

Level 2

Invasive Device Attack Resistance

• Examples:

• JTAG pin on MCU exercised to readout memory (code, keys, personal data)

• Manipulate Crystal (clock) input, power or temperature to operate MCU outside of

intended range

• Side channel attacks: spy product to get secrets (power supply, electromagnetic

radiation)

• Cost / Attackers’ level of sophistication: Moderate

• Cost: Moderate - Requires possession of device, and tools to manipulate hardware

• Sophistication – Moderate - requires both electrical and software hacking skills

22

Level 2

MED

MED

Invasive IC Destructive Attack Resistance

• MCUs are removed from their packages to probe internal busses while

operating and/or reverse engineer the IC

23

Level 3

Invasive IC Destructive Attack Resistance

• Examples:

• Internal fault injection after de-capsulation (Force nodes by probing, Laser beam)

• Reverse engineering (code / data extraction)

• Circuit modification (fib,…)

• Cost / Attackers’ level of sophistication: ‘High’

• Equipment and expertise required is very high

24

Level 3

HIGH

HIGH

Lifecycles and Security

Lifecycle 26

Development

Supply Chain/Distribution

Manufacturing

Installation / End-use

Commissioning/Re-commissioning

Lifecycle 27

• “Simple Devices”: typically have limited functionality and are

managed/accessed via internet

• Secure boot and firmware update integrates conditional access coding to maximize

security

• Make use of MPUs, Firewalls, Read Protection, JTAG / test disable

• Battery-backed tamper prevention supported by STM32 should be used for devices with

available battery

• Integrate security co-processor (like STSAFE-A100) to handle crypto for secure boot and

conditional access

• Normal best practices to attain near 100% error handling

• Prevents disclosure of sensitive Intellectual Property and/or user’s personal data

• Similarly for security of keys; additional checks on crypto to be sure standard attacks are

mitigated

Development

Lifecycle 28

• “Complex Devices”: Usually running a specialized operating system or

virtualized environment designed to run software / applications other

than OEM’s

• Java VMs running silo’ed applications

• Make use of separate execution areas to restrict access to data between unrelated processes

• In addition / with preceding: Secure Zone

• Where available, use of dedicated hardware security subsystem to protect authentication

mechanisms, execution of cryptographic services and prevent unauthorized access to key

material, and other assets like DRM

• Using tamper resistant device to personalize keys, and independently harden crypto again

simplifies the process

• Includes Gateway-like devices (aggregating / controlling data from simple devices)

• Needs to allow services to run within well-defined boundaries

Development

Lifecycle 29

• Which supplier programs Firmware into devices?

• Key material for application access, Firmware update

• Hand-off keys (changed at device personalization)

• Public key crypto simplifies

• Flash readout in place sufficient for security model?

• Distributor programs?

• Stored/shipped devices at risk?

• Product must be protected from theft;

• compromised keys could be used for an attack

• Causing damage brand / end-user safety or privacy

Supply Chain

Lifecycle 30

• OEM-owned manufacturing vs Contract (CM)

• OEM: Can initialize keys using HSM they develop / implement on controlled line

• Line can be secured (rejects/WIP controlled for security)

• Employees known and can be controlled to not be operating for other interests

• CM: Above possible but pre-initialized units required

• Lines probably not secured

• Security model requires control of finished goods

• Are there keys at rest in finished units which represent a significant threat?

• These can be at risk from identified adversaries

• Can unit be stolen, keys harvested and used to create a compromised/cloned unit

• Understand how this could be useful for adversaries’ purposes?

Manufacturing

• Is theft (and / or re-attach) of device easily detected?

• Doorbell versus thermostat

• Units located in areas easily accessible by adversary, where modification may go unnoticed

• Is connection to a WiFi network constant or does the device re-initialize

to reduce power consumption?

• Separation of Keys for data security from protocol layer

• Prevents credentials leaked to allow simply connecting to same WiFi network

Lifecycle 31Installation / End-use

• Disposed / returned device capable of unauthorized use?

• Consider how a user’s data is stored and how it should be removed from a device at

end-of-life.

• Not just a hacker perspective, but also a new (genuine) user – e.g. returned (and sold as

refurbished) goods

• Reliability/Quality requires access to Firmware?

• Returned devices need to be debugged somehow

Lifecycle 32Commissioning/Re-commissioning

Examples

Streetlight Example 34

• Device security assets (keys) must be

protected when / if:

• Keys are in NVM (no battery backed-RAM which

can be zeroed on tamper)

• Distributor initializes FW and keys

• Contract manufacturer is used to make product

• Limited function device without OS (only runs

updated FW images, and no software)

Option 1 35

Standard Microcontroller (STM32)

Sensors

STM32

General

Purpose MCU

Communication

General Purpose

MCU

Communication

Device

SecurityApplication

Sensor

Option 1

• Keys Stored and used in a Standard Microcontroller

• Microcontroller configuration requirements

• Secure boot / Secure Firmware Update and crypto (conditional access) code protected

using Memory Protection Unit / Firewall / PCROP (STM32 standard features)

• Keys stored in read protected Flash, and JTAG disabled…

36

Option 1: Threats to Manage 37

• Development: HSM, or production key initialization system must be

developed, tested and deployed into supply chain

• Test keys used for development of personalization infrastructure for planned value-chain

• Root crypto should be tested / validated according to security target required

• Supply Chain: Distributor must use HSM (Hardware Security Module)

to initialize keys

• Distributor’s programming facility should be audited

• Require additional security controls on authorized ship locations, and destruction of

rejects to programming process

• Not possible to fully control

Impact on Lifecycle

Option 1: Threats to Manage 38

• Manufacturing and finished device distribution

• Uninstalled microcontroller and opened devices (WIP) should be managed to maximize

security; ready to attack, and manipulate power supply and other factors

• Installation and end use

• Setup of connection to Wi-Fi should be separated from conditional access point

• Requires check / binding upon separation to prevent devices from being misused

• Message device has been removed

• System monitors IP location data to prevent operation after being moved without check

• Revocation of potential clones necessary?

Impact on Lifecycle

Option 1: Threats to Manage 39

• Decommissioning / Recommissioning

• Personal data erased, access keys e.g. for associated cloud services

• Process to re-assign device after return then sell / assign to new owner without leaving

access to old owner’s location enabled (similar to preceding)

• Can absence from network with ability to hack keys out through destructive means a

threat to users / brand?

Impact on Lifecycle

Option 1: Max Security Achievable 40

Low Moderate Extended

Generic

Low

IntentionalCasual

Simple

Specific

Moderate High

Violation

Means

Resources

Skills

Motivation

Level 0 Level 1 Level 2 Level 3

Safety Security

Sophisticated

Option 2 41

IoT Platform Fortified with STSAFE-A

Sensors

STM32

General

Purpose MCU

Communication

General Purpose

MCU

Communication

Device

SecurityApplication

Sensor

Security

STSAFE-A

Secure Element

Secure

ElementSensor

Option 2 42

• Crypto keys programmed by ST in STSAFE-A100

• Validated to be tamper resistant to Common Criteria EAL5+

• Microcontroller configuration requirements

• Secure boot/Secure FW update and crypto (conditional access) code protected using

Memory Protection Unit / Firewall / PCROP (STM32 standard features): as binding to

secure micro

Option 2: Threats to Manage 43

• Development:

• Crypto basis of security requires minimal crypto validation (can concentrate on

application rather than security)

• Supply Chain: ST initializes keys on their secure line, which are highly

resistant to threats thereafter

• Supply of ICs only shipped to valid / authorized distributors

• Manufacturing and finished device distribution

• Cryptographic binding of application processor (STM32) with Secure Element

Impact on Lifecycle

44

• Installation and end use

• Application / access should be separated from conditional access and no access to keys

in Secure Element (more secure)

• Setup of connection to WiFi should be separated from conditional access point

• Requires check / binding upon separation to prevent devices from being misused

• Message device has been removed

• System monitors IP location data to prevent operation after being moved without check

• Revocation of potential clones necessary?

Option 2: Threats to ManageImpact on Lifecycle

45

• Decommissioning / Recommissioning

• Process to re-assign device after return then sell / assign to new owner without leaving

access to old owner’s location enabled (similar to preceding)

• Can absence from network with ability to hack keys out through destructive means a

threat to users / brand?

Option 2: Threats to ManageImpact on Lifecycle

Option 2: Max Security Achievable 46

Low Moderate Extended

Generic

Low

IntentionalCasual

Simple

Specific

Moderate High

Violation

Means

Resources

Skills

Motivation

Level 0 Level 1 Level 2 Level 3

Safety Security

Sophisticated

Conclusions and Recommendations

47

Conclusions / Recommendations 48

• Security is based on threats which change during component sourcing

and manufacturing

• Tamper prevention implementable on finished product to achieve Level 2 security not active

until assembly is completed

• Keys can be securely initialized in a secure micro by the IC manufacturer (or distributor) without

worry thereafter

• Keys can be securely initialized on a trusted / secured line during manufacturing using an HSM

• Level 1 security for a finished product can be compromised by insecure key initialization at

manufacturing, or supply chain leaking an undiversified key or not using PKC

• Using STSAFE-A100 to securely initialize and protect keys simplifies and adds security

Work with ST, your experienced partner

Demos

ST Solutions for Security in IoT 50

Smart City Solution

for IoT Node

51

Thank You