Lifecycle Management and Security - STMicroelectronics · Lifecycle Management and Security Joe...

December 7th , 2016

San Jose Convention Center

Embedded SystemsConference

Lifecycle Management

and Security

Joe Pilozzi


Fortifying an IoT Device


Example Of A Simple IoT Device 3

Sensor MCU

Communications

Device

STM32

Communication Device

Sensor

MCU Secure

Element

STSAFE

Secure Element


An IoT Device’s Security Needs 4

Prevent device misusePrevent device or server counterfeiting

Resistance against

hacking, cloning

Authentication• Device to device

• Device to server

Service and network access corruption

Prevent device

misuse

Integrity and Availability• Secure Boot

• Secure firmware upgrade

• Trusted processing

Data privacy

Prevent data collection or corruption

Confidentiality• Data / identity protection

• Secure communications

• Secure storage

UpgradabilitySecure Communications• Secure firmware upgrade

Prevent device misuse

Need Solution


Product Integrity and Cryptography 5

• Cryptographic methods are used to :-• Protect the Confidentially and Integrity of data / information

• Ensure a chain of trust through Authentication

• Product integrity, availability and resistance against attacks• Uses cryptography and stateful processes to ensure correct operation

• Uses hardware to enforce rules and countermeasures

• Uses tamper proof methods to mitigate attacks


Secret Key

Cryptography

(Symmetric)

CryptographyOne Key or Two ?

6

Data File Data FileData File

Clear Text Clear Text

Cipher Text

Encryption Decryption

Sender ReceiverCommunications

Channel

Public Key

Cryptography

(Asymmetric)

Data File Data FileData File

Clear Text Clear Text

Cipher Text

Encryption Decryption

PrivatePublic


CryptographySize Matters

• recommended key sizes

7

AES RSA ECC

56 512 112

80 1024 160

112 2048 224

128 3072 256

192 7680 384

256 15360 521

• Bigger is better - stronger

• ECC uses a smaller key for the same strength as RSA

Str

en

gth

STRONG

AsymmetricSymmetric


Securing Assets 8

Cryptographic keys required to:

Authenticate firmware update signature

Encrypt end-user / end-node data

Authenticate device to network / service

Authenticate service/network to device

• The key to success is to protect your keys


Securing Assets 9

Keys and assets must be protected with isolated between processes

• Interface layerCloud Service

• Example AppsApplication Layers

• Drivers

• Libraries

Software Layers

• Embedded Code/ Firmware

Hardware

Tru

st

Internal (Flash) Memory

Secure partition

Internal Secure Memory

SRAM

Secure Hardware

Register Fuse


Threats and Levels


It’s All About Risk Management 11

• Understand the value of the Assets you are going

to protect, taking into account all stake holders

• Understand your Threats and Vulnerabilities

• Develop a security strategy to reduce Risk, using

right level of security for the value of the Assets

being protected

• Make use of the integrity and cryptographic tools

available

Fortified Solutions


Security Value 12

Brand

Data

Subscription

or

Service

Device

Assets

Product Tampering

Data Theft

Customer Privacy violation

IP Theft

Product Cloning

Denial of Service

Theft of Service

Damage to property / Injury / Death

Blackmail / Ransom

Threats


2) Invasive Product AttacksWith the case opened / removed

• Test / debug port access

• Inter device bus and IO probing

• Reset, clock attacks

• Power analysis

• Temperature / electrical attacks

1) Non Invasive AttacksMisuse of network protocols

• Exploit communication protocol errors

• Flaws in software design / implementation

3) Invasive Silicon AttacksDevice de-packaged

• Circuit analysis and probing

• Fault injection

Three Basic Levels / Class of Threats 13

Box InternetThe

Cloud

BOX


Product Life Cycle 14

Definition

Design

Development

Prototype / Test

Decommissioning

Product Launch

Maintenance

• Define the product and identify the

Assets you plan to protect

• Design the product based on the

correct level of security

• Develop methods and processes

to protect those Assets over the

entire life-cycle

• Develop secure processes to

handle firmware throughout the

products life-cycle

• Product security should be factored

in from day-one


STM32 Security Features

• Security Features

• Cryptographic Libraries

• Secure Boot

• Secure Firmware Upgrade

• Firewall

• Memory Protection Unit

• Unique Identifier

• Hardware Cryptographic Accelerators

• True Random Number Generator

• Debug port Access Control

• Tamper Detection

15


STSAFE-A100 Product Summary 16

Authentication, wrap/unwrap

Signature verification

Secure channel with server (TLS)

Secure data storage, 6Kbytes (configurable as counter)

Features

Personalization 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


Development of Security Architecture


Development (1) 18

• “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 H/W UIDs, MPUs, Firewalls, Read Protection, JTAG / test disable

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

available battery

• Integrate security using crypto F/W which must be validated, and hardened depending upon

security level or;

• use 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 (use of random number, fixed time processes, velocity checks)


Development (2) 19

• “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 (3) 20

• Factors impacting architecture / cost

• How much code / RAM space does crypto required?

• Public key architecture may take 20K-30K firmware and 8K-16K of RAM

• Does security level necessary require DPA / SPA hardening?

• Harder to implement in standard microcontrollers

• Does security level require keys in firmware from being read?

• Does security level require micro controllers JTAG be permanently disabled?


Changing Threat Levels 21

ConsumerSoC ManufacturingSales /

Distribution

Manufacturing Phase

PackagePersonalizationProduct

Personalization

Certified Secure Facilities

In-field

Updates

Product

Manufacture

Code

Keys / Certs

Threat Level


Where / How To Initialize Keys 22

• 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


Examples Showing Concepts


Street Light Example 24

• 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 firmware and keys

• Contract manufacturer is used to make product

• Limited function device without OS (only runs

updated F/W images, and no software)


Option 1 25

Standard Microcontroller (STM32)

Sensor MCU

Communications

Device

STM32


Sensor

MCU

SecurityApplication


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…

26


Option 1: Threats to Manage 27

• 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



• 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?






• Power analysis







• Fault injection

Option 1: Max Security Achievable 29

Box InternetThe

Cloud

BOX


Option 2 30

IoT Platform Fortified with STSAFE-A

Sensor MCU

Communications

Device

STM32


Sensor

MCU

SecurityApplication

Secure

Micro

STSAFE

Secure Micro


Option 2 31

• Crypto keys programmed by ST in STSAFE-A100

• Validated to be tamper resistant to Common Criteria EAL5+

• Main crypto functionality fulfilled by STSAFE-A100

• Reduced STM32 Firmware / RAM required

• Less development, validation required

• Hardened against DPA / SPA

• Microcontroller configuration requirements

• Secure Boot / Secure firmware update and crypto (conditional access) code protected

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

to Secure Micro



• 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 Micro






• Power analysis





Option 2: Max Security Achievable 33

Box InternetThe

Cloud

BOX



• Fault injection


Demos


ST Solutions for Security in IoT 35

Smart City Solution

for IoT Node


Conclusions / Recommendations 36

• Security is based on threats which impact development, product cost,

supply chain 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


37


38

Date post:	12-Jul-2020
Category:	Documents
Upload:	others
View:	6 times
Download:	0 times

Lifecycle Management and Security - STMicroelectronics · Lifecycle Management and Security Joe...

Documents