Upload
stworld
View
413
Download
0
Embed Size (px)
Citation preview
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