Post on 05-Jun-2020
Security of Embedded IoT DevicesSome Lessons Learned
Dr. Johann Heyszl, Head of Hardware Security DepartmentFraunhofer-Institute for Applied and Integrated Security - AISEC
5th December 2017
IoT HW-Security | Heyszl | 5th December 2017 | 1
© Fraunhofer
IoT / Embedded Systems / Cyber-Physical Systems
� Industrie 4.0
� Automotive sector
� Critical infrastructures
� Defense
� Medical appliances, building security, smart home, ...
Security issues are very similar
IoT HW-Security | Heyszl | 5th December 2017 | 2
© Fraunhofer
IoT / Embedded Systems / Cyber-Physical Systems
� Off-the-shelf hardware:
� Powerful SoC Chips from high-volume domains (e.g. phones)� Energy-efficient µ-Controller plattforms
� Open-source software:
� E.g. OS, cryptography� High quality; in-sourcing infeasible (huge development efforts)
� Efficient wireless connectivity:
� Cellular modems easily available and energy-efficient
IoT HW-Security | Heyszl | 5th December 2017 | 3
© Fraunhofer
IoT / Embedded Systems / Cyber-Physical SystemsKey Similarities
� Communication channels to backend (wireless)
� Remote control� Access to backend ressources� Acquisation of big data� Connectivity always means more attack surface
� Physical access
� Many devices are deployed in field - attackers have physical access� Attackers may take one for practice - impact many more
IoT HW-Security | Heyszl | 5th December 2017 | 4
© Fraunhofer
IoT / Embedded Systems / Cyber-Physical SystemsKey Similarities
� Communication channels to backend (wireless)
� Remote control� Access to backend ressources� Acquisation of big data� Connectivity always means more attack surface
� Physical access
� Many devices are deployed in field - attackers have physical access� Attackers may take one for practice - impact many more
IoT HW-Security | Heyszl | 5th December 2017 | 4
© Fraunhofer
Why is device security important?
� Is one device worth the effort? - Sometimes ...
� Steal one car and extract secret to forge keys� Replace firmware of e-Bike to remove speed limit?� ...
� Question is whether attacking a single device helps to impact many!
� Black-out of electricity grid (critical infrastructure; cyber war?)� Manipulation of industrial plants (IP theft, sabotage)� Car safety at large scale� Medical appliances ...
� What to do:
1. Reduce value of single devices2. Build secure IoT Devices :) → Know about attacks ...
IoT HW-Security | Heyszl | 5th December 2017 | 5
© Fraunhofer
Why is device security important?
� Is one device worth the effort? - Sometimes ...
� Steal one car and extract secret to forge keys� Replace firmware of e-Bike to remove speed limit?� ...
� Question is whether attacking a single device helps to impact many!
� Black-out of electricity grid (critical infrastructure; cyber war?)� Manipulation of industrial plants (IP theft, sabotage)� Car safety at large scale� Medical appliances ...
� What to do:
1. Reduce value of single devices2. Build secure IoT Devices :) → Know about attacks ...
IoT HW-Security | Heyszl | 5th December 2017 | 5
© Fraunhofer
Why is device security important?
� Is one device worth the effort? - Sometimes ...
� Steal one car and extract secret to forge keys� Replace firmware of e-Bike to remove speed limit?� ...
� Question is whether attacking a single device helps to impact many!
� Black-out of electricity grid (critical infrastructure; cyber war?)� Manipulation of industrial plants (IP theft, sabotage)� Car safety at large scale� Medical appliances ...
� What to do:
1. Reduce value of single devices2. Build secure IoT Devices :) → Know about attacks ...
IoT HW-Security | Heyszl | 5th December 2017 | 5
© Fraunhofer
Classical Attacker
Hacker operates remotely over network
� Target remote machines (e.g. IoT backend) to gain something
IoT HW-Security | Heyszl | 5th December 2017 | 6
© Fraunhofer
Attacker Today
IoT devices are in the field and physically accessible
� ’There are dishonest and possibly illegal methods used to breach the codeprotection feature. All of these methods [...] require using the [...] products in amanner outside the operating specifications [...]. Most likely, the person doingso is engaged in theft of intellectual property.’ - Datasheet of a current Cortex A5 MPU a
ahttp://ww1.microchip.com/downloads/en/DeviceDoc/DS60001476B.pdf, p. 2613
IoT HW-Security | Heyszl | 5th December 2017 | 7
© Fraunhofer
Attacker Today
IoT devices are in the field and physically accessible
� Glitching, SCA, connecting to busses, reading out memories ...
IoT HW-Security | Heyszl | 5th December 2017 | 7
© Fraunhofer
Real Threats for IoT
Hardware attacks on single devices ...
... plus attacks on connected IoT devices
IoT HW-Security | Heyszl | 5th December 2017 | 8
© Fraunhofer
Example of a Hacked IoT Device
� Miller & Valasek’s Jeep Hack 2015:
� Full remote-control of critical CAN bus (stop engine / de-activate breaking)� High effort for reverse engineering infotainment unit (incl. cell connection)� D-Bus (OS IPC service) accessible on TCP/IP port over (cellular) internet!� Dowload SSH Key to start SSH server; re-flash CAN controller per serial wire from
infotainment domain; CAN controller now forwards malicious control messages
IoT HW-Security | Heyszl | 5th December 2017 | 9
© Fraunhofer
Information Security for IoT Devices
� The combination ofsensitive applications, internet connectivity, and physical accessibilitymakes information security extremely important in embedded devices!
� Information security requires
1. Cryptographic algorithms� Nowadays highly secure (e.g. AES, SHA-3, ECC)� Formerly poor (e.g. ENIGMA, but also Keeloq etc.)
2. Secure implementations and devices!� IT security for software (SW vulnerabilities/exploits)� Secure storage of secret keys → Insight today� Implementation security of cryptography → Insight today
IoT HW-Security | Heyszl | 5th December 2017 | 10
© Fraunhofer
Information Security for IoT Devices
� The combination ofsensitive applications, internet connectivity, and physical accessibilitymakes information security extremely important in embedded devices!
� Information security requires
1. Cryptographic algorithms� Nowadays highly secure (e.g. AES, SHA-3, ECC)� Formerly poor (e.g. ENIGMA, but also Keeloq etc.)
2. Secure implementations and devices!� IT security for software (SW vulnerabilities/exploits)� Secure storage of secret keys → Insight today� Implementation security of cryptography → Insight today
IoT HW-Security | Heyszl | 5th December 2017 | 10
© Fraunhofer
Information Security for IoT Devices
� The combination ofsensitive applications, internet connectivity, and physical accessibilitymakes information security extremely important in embedded devices!
� Information security requires
1. Cryptographic algorithms� Nowadays highly secure (e.g. AES, SHA-3, ECC)� Formerly poor (e.g. ENIGMA, but also Keeloq etc.)
2. Secure implementations and devices!� IT security for software (SW vulnerabilities/exploits)� Secure storage of secret keys → Insight today� Implementation security of cryptography → Insight today
IoT HW-Security | Heyszl | 5th December 2017 | 10
© Fraunhofer
Stealing keys with physical access
IoT HW-Security | Heyszl | 5th December 2017 | 11
© Fraunhofer
Extracting Contents from Memory Chips
� IoT devices often contain flash/EEPROM storage chips for SW
� Often: secret credentials (crypto keys, user+password) contained!
� Attackers simply read them out!
� E.g. de-solder BGA flash from embedded system PCB, re-ball, put in BGA socket� Connect to quick-fixed FPGA / µC to read-out keys
IoT HW-Security | Heyszl | 5th December 2017 | 12
© Fraunhofer
Reverse-Engineering Memory Contents
� Memory images can be disassembled for analysis ...
� Find cryptographic algorithm implementations (e.g. find AES lookup table values)� Go from there to find hard-coded keys (or use entropy of mem regions is indicator)� This is done in practice!
� Keys or proprietary algorithms are not secure in regular memory
IoT HW-Security | Heyszl | 5th December 2017 | 13
© Fraunhofer
Glitching Attacks to Circumvent Locking Mechanisms
� Many SoCs and µCs provide locking mechanisms to protect secrets inside
� Glitching attacks! (fault attack)
� Supply chips (SoCs / µCs) with malformed clock or short VDD outage� Example setup - Successful circumvention of read-protection; read-out over JTAG
� Skip/override instructions (PW checks, locking configuration, cryptographicimplementations, ...)
IoT HW-Security | Heyszl | 5th December 2017 | 14
© Fraunhofer
Other Attacks on Protected On-Chip MemoryObermaier, Tatschner, 2017
� Researchers extract protected flash of STM32 (F0, ARM ofCortex M0) a
� Features read protection and debug disable through different locking levels� Best attack: Custom debugger accesses single flash word before lock-down after
power-up. Repeat to retrieve entire flash.
� Also: Circumvent flash read-locking through debugger-allowed SRAM access(extract flash bytes from CRC calculation results in SRAM during startup)
� Also: Fallback from locked debugger by erasing lock bits using UV light
aObermaier, Tatschner, ’Shedding too much Light on a Microcontroller’s Firmware Protection’, WOOT 2017 after responsible disclosure
IoT HW-Security | Heyszl | 5th December 2017 | 15
© Fraunhofer
Laser-Based Fault Injection
� Best-case measurement setup for worst-case high-security evaluation
� Realistic setup in smartcard / high security (IoT device value should be lower than this ...)
IoT HW-Security | Heyszl | 5th December 2017 | 16
© Fraunhofer
Breaking crypto with physical access
IoT HW-Security | Heyszl | 5th December 2017 | 17
© Fraunhofer
Implementation Attacks against Cryptography
� Cryptographic algorithms are highly secure (AES, ECC, RSA, SHA-256, SHA-3)(if secret keys are also stored securely ...)
� Cryptographic implementations are not always secure
� Implementation attacks
1. Side-Channel Attacks (Power, EM, Cache-based, ... )2. Fault Attacks
� Target intermediate values during computation
� Record (power / EM) measurement during cryptographic computation� Intermediate values are less secure (e.g. not ’fully mixed with secret’)
IoT HW-Security | Heyszl | 5th December 2017 | 18
© Fraunhofer
Real-World Example - Smart Home AutomationRonen, O’Flynn, Shamir, Weingarten, 2016
a
� Radio-networked smart lightning / IoT light bulb (Philips Hue) (small system)
� Side-channel attack against one device
� Successful extraction of AES encryption key - master key (!)
� Whole device family affected!a
Ronen, O’Flynn, Shamir, Weingarten, IoT Goes Nuclear: Creating a ZigBee Chain Reaction, 2016
IoT HW-Security | Heyszl | 5th December 2017 | 19
© Fraunhofer
Simple Measurement Setup for Side-Channel Attacks
IoT HW-Security | Heyszl | 5th December 2017 | 20
© Fraunhofer
Side-Channel Attack against Typical Embedded System
� Typical embedded system (BeagleBone)
� Recover Linux filesystem encryption key (AES; 100k measurements)
� Even if ’a lot of noise’ is present (from 500 MHz CPU, SoC and Linux OS)
IoT HW-Security | Heyszl | 5th December 2017 | 21
© Fraunhofer
Some Attacks Require Invasive Preparation
IoT HW-Security | Heyszl | 5th December 2017 | 22
© Fraunhofer
High-Precision Side-Channel Evaluation
� Best-case measurement setup for worst-case high-security evaluation
� Realistic setup in smartcard / high security (IoT device value should be lower than this ...)
IoT HW-Security | Heyszl | 5th December 2017 | 23
© Fraunhofer
How to achieve secure IoT devices?
IoT HW-Security | Heyszl | 5th December 2017 | 24
© Fraunhofer
Secure IoT Devices
� Secure embedded IoT devices require comprehensive security concepts
� Hardware attacks require hardware security
� Most important: Security of cryptographic keys
� Most of IoT authentication and communication security depends on keys� Key distribution and management is critical� Limit scope of keys!
� Time budget of attackers high ...
� Specialized security engineers with security mindset needed
� Rotate specialists through development teams to ensure high impact(while building up ressources)
� Get security consulting early
IoT HW-Security | Heyszl | 5th December 2017 | 25
© Fraunhofer
Secure IoT Devices
� Secure embedded IoT devices require comprehensive security concepts
� Hardware attacks require hardware security
� Most important: Security of cryptographic keys
� Most of IoT authentication and communication security depends on keys� Key distribution and management is critical� Limit scope of keys!
� Time budget of attackers high ...
� Specialized security engineers with security mindset needed
� Rotate specialists through development teams to ensure high impact(while building up ressources)
� Get security consulting early
IoT HW-Security | Heyszl | 5th December 2017 | 25
© Fraunhofer
Secure IoT Devices
� Secure embedded IoT devices require comprehensive security concepts
� Hardware attacks require hardware security
� Most important: Security of cryptographic keys
� Most of IoT authentication and communication security depends on keys� Key distribution and management is critical� Limit scope of keys!
� Time budget of attackers high ...
� Specialized security engineers with security mindset needed
� Rotate specialists through development teams to ensure high impact(while building up ressources)
� Get security consulting early
IoT HW-Security | Heyszl | 5th December 2017 | 25
© Fraunhofer
Secure IoT Devices
� Security concept may contain:
� Effective read protection and debug locking on chosen SoCs / µCs� No accessible debug :)� HW-protected/secure key-memory (e.g. SE)� Isolation of sensitive memory regions during runtime� Hardware-firewalls for SW compartmentalization (MPU, MMU, TEE, HSMs, SEs)� Secure Boot (requires root-of-trust as hardwired ROM code)� Protected cryptographic HW engines
� → Until here impossible to retrofit - Decided early by choice of chips!
� Secure updates in the field� Layered / compartmentalized SW approach� Remote attestion of device integrity� Protected cryptographic SW implementations
� Choice and composition depends on case� → Careful decisions through security expert
IoT HW-Security | Heyszl | 5th December 2017 | 26
© Fraunhofer
Secure IoT Devices
� Security concept may contain:
� Effective read protection and debug locking on chosen SoCs / µCs� No accessible debug :)� HW-protected/secure key-memory (e.g. SE)� Isolation of sensitive memory regions during runtime� Hardware-firewalls for SW compartmentalization (MPU, MMU, TEE, HSMs, SEs)� Secure Boot (requires root-of-trust as hardwired ROM code)� Protected cryptographic HW engines
� → Until here impossible to retrofit - Decided early by choice of chips!
� Secure updates in the field� Layered / compartmentalized SW approach� Remote attestion of device integrity� Protected cryptographic SW implementations
� Choice and composition depends on case� → Careful decisions through security expert
IoT HW-Security | Heyszl | 5th December 2017 | 26
© Fraunhofer
Example: Integrating Secure Elements (SE)
� Take critical part of system(secret keys, certificates, passwords, other critical functionality ..)and put into secure element
010011100010101002011001 … 1101010101010101 …
010011100010101002011001 …
Main CPU
010011100010101002011001 … 1101010101010101 … SE
� Highly secure memory - Extraction nearly impossible, even with highly invasive methods
� Hardened cryptographic libraries and hardware accelerators
� We currently develop SE toolbox for embedded systems in BMBF-funded projekt IUNO
� Depends on case - not helpful in all cases
IoT HW-Security | Heyszl | 5th December 2017 | 27
© Fraunhofer
Conclusion
� Information security for IoT devices (also don’t forget cloud / edge security)
1. Reduce attacker value of single devices (as much as possible)2. Build secure IoT devices (to mitigate remaining threats)
� Many embedded systems will require more hardware/embedded security
� IoT device security investment may not be effective USP in the short term
� Will pay off in the longterm (users will value devices from manufacturers they trust)
IoT HW-Security | Heyszl | 5th December 2017 | 28
© Fraunhofer
Conclusion
� Information security for IoT devices (also don’t forget cloud / edge security)
1. Reduce attacker value of single devices (as much as possible)2. Build secure IoT devices (to mitigate remaining threats)
� Many embedded systems will require more hardware/embedded security
� IoT device security investment may not be effective USP in the short term
� Will pay off in the longterm (users will value devices from manufacturers they trust)
IoT HW-Security | Heyszl | 5th December 2017 | 28
© Fraunhofer
Contact Information
Dr.-Ing. Johann Heyszl
Hardware Security Department
Fraunhofer-Institute forApplied and Integrated Security (AISEC)
Address: Parkring 485748 Garching (near Munich)Germany
Internet: http://www.aisec.fraunhofer.de
Phone: +49 89 3229986-172Fax: +49 89 3229986-299E-Mail: johann.heyszl@aisec.fraunhofer.de
IoT HW-Security | Heyszl | 5th December 2017 | 29
© Fraunhofer
Side-Channels inside Embedded CPUs
� Software-isolation important security feature (hypervisor, VMM, OS, TrustZone, ..)
� Cache attacks (microarchitectural attacks) against cryptographic implementations(e.g. AES, RSA, etc.)
� Victim and attacker (spy) on same system� Cloud, mobile, mixed-criticality in embedded systems
IoT HW-Security | Heyszl | 5th December 2017 | 30
© Fraunhofer
Auto-Detection of Leaks in RSA SW ImplementationsIssues with RSA Exponentiations
be mod n
e = 1 1 0 1 0 ... 0 0 0 1 1eL-1 eL-2 ... ... e1 e0
Binary algorithms
� Square-and-multiply
� Square-and-multiply-always
� Montgomery ladder
2k-ary algorithms
� Fixed-window exp. (FWE)
� Sliding-window exp. (SWE)
� invisible
IoT HW-Security | Heyszl | 5th December 2017 | 31
© Fraunhofer
Auto-Detection of Leaks in RSA SW ImplementationsAISEC Tool
1. Leakage test for instr. cache leaks
� Simple and effective� Fully automatic� Based on binary (instrumentation)� Execute on target architecture (e.g. ARM v7)
2. Evaluation framework
� Instruction granularity (outputs code lines)� Easy integration into design flow� Currently supports RSA
(will be extended to ECC and include similarattacks)
� A. Zankl, J. Heyszl, G. Sigl, ’Automated Detection ofInstruction Cache Leaks in Modular ExponentiationSoftware’, CARDIS 2016
IoT HW-Security | Heyszl | 5th December 2017 | 32
© Fraunhofer
Auto-Detection of Leaks in RSA SW ImplementationsBug Reports and Fixes
� wolfSSL
� Fixed in v3.10.2 (Feb. 10th 2017)� Documented under CVE-2017-6076
� MatrixSSL
� Acknowledged the problem of SWE� Switched to FWE in v3.9.0 (Mar. 10th 2017)
� mbed TLS and libgcrypt
� Leaks reported and acknowledged� Switch to other implementation pending
IoT HW-Security | Heyszl | 5th December 2017 | 33
© Fraunhofer
Auto-Detection of Leaks in RSA SW ImplementationsLeakage-Resilience - The Good and the Bad
� Leakage-resiliency (DPA-security by construction) isextremely interesing for embedded systems!
Figure: S-box 0 left, S-box 1 right
� High SNRs for individual S-boxes allow breaking assumption of one class of resilient (PRF)constructions on FPGAs (Xilinx Spartan-6 45 nm)→ Improvements on the way :)
� F. Unterstein, J. Heyszl, F. De Santis, R. Specht, ’Dissecting Leakage Resilient PRFs with MultivariateLocalized EM Attacks’, COSADE 2017
IoT HW-Security | Heyszl | 5th December 2017 | 34
© Fraunhofer
Auto-Detection of Leaks in RSA SW ImplementationsPrecision against 45 nm FPGAs
-4.0 -3.0 -2.0 -1.0 0.0 1.0 2.0 3.0 4.0x in µm
-4.0
-3.0
-2.0
-1.0
0.0
1.0
2.0
3.0
4.0
y in
µm
Address = 0, Bit = 0
set
set + other bit(s)
rst
rst + other bit(s)
toggle
toggle + other bit(s)
other bit(s)
no faults
� Manipulates single bits (set to 0 or 1) in BRAM of 45 nm Xilinx Spartan-6� B. Selmke, S. Brummer, J. Heyszl, G. Sigl, ’Precise laser fault injections into 90 nm and 45 nm
SRAM-cells’, CARDIS 2015
IoT HW-Security | Heyszl | 5th December 2017 | 35
© Fraunhofer
Auto-Detection of Leaks in RSA SW ImplementationsDual Laser against Duplication Countermeasures
-30.0 -25.0 -20.0 -15.0 -10.0 -5.0 0.0 5.0 10.0 15.0 20.0 25.0 30.0x [µm]
-15.0
-10.0
-5.0
0.0
5.0
10.0
15.0y
[µm
]
no faults
logic error
set
rst
flip
� Simultaneously manipulate AES-state (in round 7) in two FF-based designs on 45 nmXilinx Spartan-6 by precisely positioning two focused laser beams to perform DFA.Single successful FI is sufficient (time to success: ≈ 5min)
� B. Selmke, J. Heyszl, G. Sigl, ’Attack on a DFA Protected AES by Simultaneous Laser Fault Injections’,FDTC 2016
IoT HW-Security | Heyszl | 5th December 2017 | 36
© Fraunhofer
System-on-Chips with FPGAs - Platforms for the Future
IoT HW-Security | Heyszl | 5th December 2017 | 37
© Fraunhofer
System-on-Chips with FPGAs
Application Processor
2x
USB
2X
CAN
2x
SPI
2X
I2C
AMBA Bus System
On-chip
Mem.
2x
UART
FPGA Fabric
HW
Acc. 2
HW
Acc. 3
Mem.
Ctrl.Cortex
A9
L1 I/D
cache
2X
GigE
MMU
DSP/
FPU
I/O
MU
X
2X
SDIO
Cortex
A9
L1 I/D
cacheMMU
DSP/
FPU
L2 Cache Timer DMA SCU
Crypto
Cores
HW
Acc. 1
� New popular platform for embedded systems
� CPU for high performance and regular embedded SW
� E.g. Cortex-A9 dual-core with reconfigurable hardware FPGA in Xilinx Zynq-7020
� FPGA for flexibility
� E.g. for future Post-Quantum cryptography, interfacing, signal processing
� Both, hardware and software can be updated during the life-time of the IC
IoT HW-Security | Heyszl | 5th December 2017 | 38
© Fraunhofer
System-on-Chips with FPGAsNew Hardware Threats
� Hardware design is complex and time-consuming
� Designers often use third party IP cores
� IP cores may not always come from trusted sources
� Hard to be sure that there is no unwanted functionality
� Malicious IP cores may open new vulnerabilities for FPGA SoCs
� May exploit shared resourcese.g., corrupt shared memory
� Modification or transmission of sensitive data
IoT HW-Security | Heyszl | 5th December 2017 | 39
© Fraunhofer
System-on-Chips with FPGAsHardware Threat Example
FPGA Fabric
Bus System
Processor System
Malicious
ServerUpdate | Signature
HW
Acc.
RAM
� N. Jacob, C. Rolfes, A. Zankl, J. Heyszl, G. Sigl, ’Compromising FPGA SoCs using malicious hardwareblocks’, DATE 2017
IoT HW-Security | Heyszl | 5th December 2017 | 40
© Fraunhofer
System-on-Chips with FPGAsHardware Threat Example
FPGA Fabric
Bus System
Processor System
Update
Malicious
ServerUpdate | Signature
Hash
Function
� N. Jacob, C. Rolfes, A. Zankl, J. Heyszl, G. Sigl, ’Compromising FPGA SoCs using malicious hardwareblocks’, DATE 2017
IoT HW-Security | Heyszl | 5th December 2017 | 41
© Fraunhofer
System-on-Chips with FPGAsPrevention
� IOMMU/SMMU� Memory management for master peripherals� Available only in newer high-end FPGA SoCs (e.g. Xilinx Ultrascale)
� Security-enhanced AXI wrapper (DATE 2017)� Monitors the addresses the IP core accesses from first activation� Easy to review and can be reused
IP Core in FPGA Fabric
RAM
AXI Master
CPU Memory
Interface
AXI Slave
Core Function
Bus System
IoT HW-Security | Heyszl | 5th December 2017 | 42
© Fraunhofer
Embedded Security OverviewSoftware Security
� Software-isolation / virtualisation
� Hypervisor-based� Virtual Machine Manager� Container-level virtualisation
� Hardware-based isolation
� Secure runtime environments (ARM TrustZone, Intel SGX)� Separate HSM controllers on-chip
� Secure Updates
� Engineering (e.g. Software) is never perfect� Update e.g. cryptographic libraries to fix exploits
IoT HW-Security | Heyszl | 5th December 2017 | 43
© Fraunhofer
Real-World Case - iPhone Unlock at U.S. FBI in 2016
� Challenge:� 4-digit passcode with error counter� Only 6 attemmpts before long time-out� Brute-force impossible
� Successful attack (likely used by contractor for FBI):� Read-out flash image� Re-programm initial image after every 6th attempt to avoid time-outs� Brute-force possible
IoT HW-Security | Heyszl | 5th December 2017 | 44
© Fraunhofer
Real-World Case - iPhone Unlock at U.S. FBI in 2016Solution Example - Building Access System
� Challenge
� Access tokens and locks with symmetric keys (partly wide-scope)� Microcontroller-based plattform, no secure memory� Hackers read-out firmware after clearing fuses using UV light for
reverse-engineering� Hackers performed side-channel attacks to recover keys in field
� Solution
� Integrate security controller with custom C-firmware� Legacy authentication and cryptography included for backwards-compatibility� State-of-the-Art cryptography and authentication added� Symmetric keys stored in highly-secure memory
IoT HW-Security | Heyszl | 5th December 2017 | 45
© Fraunhofer
Real-World Case - iPhone Unlock at U.S. FBI in 2016Solution Example - Building Access System
� Challenge
� Access tokens and locks with symmetric keys (partly wide-scope)� Microcontroller-based plattform, no secure memory� Hackers read-out firmware after clearing fuses using UV light for
reverse-engineering� Hackers performed side-channel attacks to recover keys in field
� Solution
� Integrate security controller with custom C-firmware� Legacy authentication and cryptography included for backwards-compatibility� State-of-the-Art cryptography and authentication added� Symmetric keys stored in highly-secure memory
IoT HW-Security | Heyszl | 5th December 2017 | 45
© Fraunhofer
Real-World Case - iPhone Unlock at U.S. FBI in 2016Solution Example - Building Access System
IoT HW-Security | Heyszl | 5th December 2017 | 46
© Fraunhofer
Side-Channel Attack - Simple Example
a
� Recover secret scalar (exponent) from sequence of doubles and adds in elliptic curvecryptography
� Very powerful: Differential Power Analysis (DPA) against AESa
Wu et al., 1999
IoT HW-Security | Heyszl | 5th December 2017 | 47
© Fraunhofer
Low-Cost Side-Channel Measurement
a
� Attackers do not need expensive laboratory equipment (≤ 500 EUR are often enough)
aDe Mulder et al., 2007
IoT HW-Security | Heyszl | 5th December 2017 | 48
© Fraunhofer
Low-Cost Side-Channel Attack Tooling
� Colin O’Flynn’s ChipWhisperera projekt
� E.g. open-source diff probe and acquisition setup for current measurements
a
� Elisabeth Oswald’s OpenSCAb Matlab toolbox for DPA
ahttps://events.ccc.de/congress/2013/wiki/Projects:ChipWhisperer
bhttp://sourceforge.net/projects/opensca/
IoT HW-Security | Heyszl | 5th December 2017 | 49
© Fraunhofer
Example: Smartmeter
� ARM CPU, Linux OS
IoT HW-Security | Heyszl | 5th December 2017 | 50
© Fraunhofer
Example: Smartmeter
� U-Boot bootloader configuration on external I2C EEPROM
� Read-out EEPROM through sniffing during boot
IoT HW-Security | Heyszl | 5th December 2017 | 51
© Fraunhofer
Example: Smartmeter
� Modify boot parameters on-the-fly to set ’enabletty’ to true
� Then, bootloader always starts with serial prompt
� Boot Linux kernel with custom arguments: init=/bin/sh to get root shell
� Full control over system (e.g. change / recover passwords for web-access)
� Secure boot should also include boot parameters
IoT HW-Security | Heyszl | 5th December 2017 | 52
© Fraunhofer
Information security needs cryptography
Cryptography needs secret keys
Both need protection
IoT HW-Security | Heyszl | 5th December 2017 | 53
© Fraunhofer
Cryptography and Secret Keys
� Two main questions for embedded security:
1. How to store secrets?2. How to implement cryptography?
IoT HW-Security | Heyszl | 5th December 2017 | 54
© Fraunhofer
Secret Keys
� Best choice: Device-individual keys
� Reduces impact of successful attack� Natural in case of public key cryptography / asymmetric cryptography
� E.g. electronic signatures� Every device / person has their own key pair
� Also possible with symmetric keys (e.g. AES algorithm)
� Sometimes, master keys (symmetric) cannot be avoided (not good)
� Master sounds good, but really is the opposite� For compatibility to legacy functionality� Because system design leaves no choice
� At least store as secure as possible!� Do not store in field devices (example at Usenix 2016 in automotive domain)
IoT HW-Security | Heyszl | 5th December 2017 | 55
© Fraunhofer
Secret Keys
� How to (not) store keys in embedded devices?
� Use OTP memory?� Hard-code into software source code?� Load into on-board flash / EEPROM chip?� Use System-on-chip / CPU storage resources?
IoT HW-Security | Heyszl | 5th December 2017 | 56
© Fraunhofer
Extracting Secrets
� More ways
� Find and use debug interfaces� Sniff bus lines on live system� Circumvent read protections� Clear fuses using UV light� Invasive attacks� ...
IoT HW-Security | Heyszl | 5th December 2017 | 57
© Fraunhofer
Secret Keys Storage - Best Practices
� Use proper (!) read protection
� Use SoCs with secure memory
� Use dedicated security chip
� Offer very high protection level against physical attacks� Approved and tested in highly critical applications like passports and credit cards
IoT HW-Security | Heyszl | 5th December 2017 | 58
© Fraunhofer
Secret Keys Storage - Best Practices
� Permanently disable all debug before shipping
� Only removing connectors does not help ;)
� Use password protection for debug interfaces
� Select chips which provide such features!
IoT HW-Security | Heyszl | 5th December 2017 | 59
© Fraunhofer
Solution Example - Gambling Machine
IoT HW-Security | Heyszl | 5th December 2017 | 60
© Fraunhofer
Solution Example - Gambling MachineChallenge
� Gambling machines are complex embedded systems
� Need electronic signatures for fiscal data to protect against manipulation
� Requiring electronic signature means:
� One individual secret key per machine→ How to store securely?� Cryptographic (ECDSA) signature implementation→ Side-channel attacks?
IoT HW-Security | Heyszl | 5th December 2017 | 61
© Fraunhofer
Solution Example - Gambling MachineChallenge
� We analyzed circumstances and possible solutions ...
� Why not use main CPU / SoC?
� No security features� No protected memory available� Highly complex implementation (cryptography)� Cryptographic signatures computationally expensive (without HW acceleration)� Licenses required for protection against side-channel attacks
� Eventually enables cloning of system and large-scale forging of signed data
IoT HW-Security | Heyszl | 5th December 2017 | 62
© Fraunhofer
Solution Example - Gambling MachineSolution
� Integrate Infineon SLE security controller
� ’Outsource’ critical parts to security controller for minimal modifications� One-stop-solution through customized firmware
� Use protected cryptographic library and hardware acceleration for ECDSA signatures
� Store signature key in highly secure memory
� FAT filesystem driver / file handling in security controller
IoT HW-Security | Heyszl | 5th December 2017 | 63
© Fraunhofer
Secret Keys
� Best choice: Device-individual keys
� Reduces impact of successful attack� Natural in case of public key cryptography / asymmetric cryptography
� E.g. electronic signatures� Every device / person has their own key pair
� Also possible with symmetric keys (e.g. AES algorithm)(requires key management/distribution)
� Sometimes, master keys (symmetric) cannot be avoided (not good)
� Master sounds good, but really is the opposite� Compatibility to legacy functionality� Or: Application design leaves no choice
� At least store as secure as possible!� Do not store in field devices (example at Usenix 2016 in automotive domain)
IoT HW-Security | Heyszl | 5th December 2017 | 64
© Fraunhofer
Implementing Cryptography - Best Practices
� Use well-analyzed implementations / libraries
� But most libraries do not include side-channel protection
� Use dedicated security chip
� Offer very high protection level against side-channel attacks� Development of countermeasures against ever-improving attacks for years ...
IoT HW-Security | Heyszl | 5th December 2017 | 65
© Fraunhofer
Broader Perspective
� Secure elements are often helpful
� Not all security issues are solved by secure elements
� Key distribution and management must be addressed� Secure boot to protect entire running software� Secure software updates� Isolation mechanisms for Software / OS like TrustZone, Virtualization, ..� Tamper protection for entire embedded system
IoT HW-Security | Heyszl | 5th December 2017 | 66
© Fraunhofer
Software Exploits
� Software is never flawless
� Attackers may find exploits (e.g. source code review)� Remote attacks (e.g. heartbleed bug in OpenSSL crypto lib)
� How to protect?
A Code review (even of open-source libraries)
B Isolation (e.g. isolate critical part from non-critical)
� If one part is compromised, isolation prevents outbreak
� Hypervisor-based isolation of multiple operating systems� Secure runtime environments with restricted API in Secure Elements (SE) /
Hardware Security Modules (HSM)
C Update mechanisms
IoT HW-Security | Heyszl | 5th December 2017 | 67
© Fraunhofer
Software Exploits
� Software is never flawless
� Attackers may find exploits (e.g. source code review)� Remote attacks (e.g. heartbleed bug in OpenSSL crypto lib)
� How to protect?
A Code review (even of open-source libraries)
B Isolation (e.g. isolate critical part from non-critical)
� If one part is compromised, isolation prevents outbreak
� Hypervisor-based isolation of multiple operating systems� Secure runtime environments with restricted API in Secure Elements (SE) /
Hardware Security Modules (HSM)
C Update mechanisms
IoT HW-Security | Heyszl | 5th December 2017 | 67
© Fraunhofer
Software Exploits
� Software is never flawless
� Attackers may find exploits (e.g. source code review)� Remote attacks (e.g. heartbleed bug in OpenSSL crypto lib)
� How to protect?
A Code review (even of open-source libraries)
B Isolation (e.g. isolate critical part from non-critical)
� If one part is compromised, isolation prevents outbreak
� Hypervisor-based isolation of multiple operating systems� Secure runtime environments with restricted API in Secure Elements (SE) /
Hardware Security Modules (HSM)
C Update mechanisms
IoT HW-Security | Heyszl | 5th December 2017 | 67
© Fraunhofer
Software Exploits
� Software is never flawless
� Attackers may find exploits (e.g. source code review)� Remote attacks (e.g. heartbleed bug in OpenSSL crypto lib)
� How to protect?
A Code review (even of open-source libraries)
B Isolation (e.g. isolate critical part from non-critical)
� If one part is compromised, isolation prevents outbreak
� Hypervisor-based isolation of multiple operating systems� Secure runtime environments with restricted API in Secure Elements (SE) /
Hardware Security Modules (HSM)
C Update mechanisms
IoT HW-Security | Heyszl | 5th December 2017 | 67
© Fraunhofer
Software Integrity from Start
� Replacing / manipulating software is common attack goal
� Trusted boot does not help against HW attackers (TPM 1.2)� TPM is connected using LPC / I2C / SPI� Attackers can eavesdrop and replay values on these busses
� Secure boot is needed� Every stage verifies signature of next stage before execution� CPU / SoC needs built-in ROM code as root of trust
and one-time-writable on-chip memory (fuses) for verification keySelect chips accordingly!
IoT HW-Security | Heyszl | 5th December 2017 | 68
© Fraunhofer
Software Integrity from Start
� Replacing / manipulating software is common attack goal
� Trusted boot does not help against HW attackers (TPM 1.2)� TPM is connected using LPC / I2C / SPI� Attackers can eavesdrop and replay values on these busses
� Secure boot is needed� Every stage verifies signature of next stage before execution� CPU / SoC needs built-in ROM code as root of trust
and one-time-writable on-chip memory (fuses) for verification keySelect chips accordingly!
IoT HW-Security | Heyszl | 5th December 2017 | 68
© Fraunhofer
Software Integrity from Start
� Replacing / manipulating software is common attack goal
� Trusted boot does not help against HW attackers (TPM 1.2)� TPM is connected using LPC / I2C / SPI� Attackers can eavesdrop and replay values on these busses
� Secure boot is needed� Every stage verifies signature of next stage before execution� CPU / SoC needs built-in ROM code as root of trust
and one-time-writable on-chip memory (fuses) for verification keySelect chips accordingly!
IoT HW-Security | Heyszl | 5th December 2017 | 68
© Fraunhofer
Secure Boot for FPGAs
� FPGAs are important platforms for embedded systems
� Xilinx Zynq
Application Processor
2x
USB
2X
CAN
2x
SPI
2X
I2C
AMBA Bus System
On-chip
Mem.
2x
UART
FPGA Fabric
HW
Acc. 2
HW
Acc. 3
Mem.
Ctrl.Cortex
A9
L1 I/D
cache
2X
GigE
MMU
DSP/
FPU
I/O
MU
X
2X
SDIO
Cortex
A9
L1 I/D
cacheMMU
DSP/
FPU
L2 Cache Timer DMA SCU
Crypto
Cores
HW
Acc. 1
� Provides secure boot for software and hardware based on keys in protected storage(master keys)
IoT HW-Security | Heyszl | 5th December 2017 | 69
© Fraunhofer
Secure Boot for FPGAs
� Secure boot based on devices-specific keys (Physical Unclonable Functions - PUFs)
© Fraunhofer
BootROM
First Stage Boot Loader
Bitstream (PUF, User Crypto)
U-Boot
Operating System
Unencrypted Partition
Verified by Xilinx Boot Process
Verified by U-boot using the PUF and User Crypto
Verify
Verify
Verify
Verify
PUF based Secure Boot
IoT HW-Security | Heyszl | 5th December 2017 | 70
© Fraunhofer
Secure Boot for FPGAs
� Secure boot of operating system using PUFs
1. BootROM verifies and loads the first stage bootloader2. First stage bootloader verifies and loads bitstream
containing PUF and user crypto3. First stage bootloader verifies U-boot and handsoff control4. U-boot verifies the OS using the PUF and user crypto core on the FPGA5. Upon successfully verification, OS is booted
IoT HW-Security | Heyszl | 5th December 2017 | 71
© Fraunhofer
PUF-based Secure Credential Storage for FPGAsSIBASE Demonstrator - WindTurbine Controller
Source: BMBF-Projekt SIBASE
IoT HW-Security | Heyszl | 5th December 2017 | 72
© Fraunhofer
PUF-based Secure Credential Storage for FPGAsSIBASE Demonstrator - WindTurbine Controller
� Turbine Controller (represented Xilinx Zynq board) provides a secure credential storagerealized by PUFs
1. Operational X.509 credentials are bootstrapped to the turbine controller by theCertification Authority
2. Turbine controller is authenticated by the PUF3. X.509 credentials are stored on turbine controller in the PUF credential store4. Turbine controller continuously collects sensor data from wind turbine5. Remote accesses to the turbine controller by HTTPS and X.509 credentials
protected by the PUF credential storage
IoT HW-Security | Heyszl | 5th December 2017 | 73
© Fraunhofer