Security of Embedded IoT Devices Some Lessons Learnedmakesinformation security extremely important...

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


© 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


© 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


© 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


© 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 ...


© Fraunhofer






� What to do:



© Fraunhofer






� What to do:



© Fraunhofer

Classical Attacker

Hacker operates remotely over network

� Target remote machines (e.g. IoT backend) to gain something


© 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


© Fraunhofer

http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001476B.pdf

Attacker Today

IoT devices are in the field and physically accessible

� Glitching, SCA, connecting to busses, reading out memories ...


© Fraunhofer

Real Threats for IoT

Hardware attacks on single devices ...

... plus attacks on connected IoT devices


© 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


© 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


© Fraunhofer







© Fraunhofer







© Fraunhofer

Stealing keys with physical access


© 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


© 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


© 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, ...)


© 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


© 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 ...)


© Fraunhofer

Breaking crypto with physical access


© 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’)


© 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


© Fraunhofer

Simple Measurement Setup for Side-Channel Attacks


© 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)


© Fraunhofer

Some Attacks Require Invasive Preparation


© 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 ...)


© Fraunhofer

How to achieve secure IoT devices?


© 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


© Fraunhofer

Secure IoT Devices










© Fraunhofer

Secure IoT Devices










© 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


© 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


© 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


© 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)


© 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)


© 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: [email protected]


© 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


© 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


© 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


© 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


© 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


© 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


© 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


© Fraunhofer

System-on-Chips with FPGAs - Platforms for the Future


© 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


© 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


© 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


© 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


© 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


© 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


© 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


© 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


© Fraunhofer


� 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


© Fraunhofer



© 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


© Fraunhofer

Low-Cost Side-Channel Measurement

a

� Attackers do not need expensive laboratory equipment (≤ 500 EUR are often enough)

aDe Mulder et al., 2007


© 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/


© Fraunhofer

https://events.ccc.de/congress/2013/wiki/Projects:ChipWhisperer

http://sourceforge.net/projects/opensca/

Example: Smartmeter

� ARM CPU, Linux OS


© Fraunhofer

Example: Smartmeter

� U-Boot bootloader configuration on external I2C EEPROM

� Read-out EEPROM through sniffing during boot


© 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


© Fraunhofer

Information security needs cryptography

Cryptography needs secret keys

Both need protection


© Fraunhofer

Cryptography and Secret Keys

� Two main questions for embedded security:

1. How to store secrets?2. How to implement cryptography?


© 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)


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


© 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� ...


© 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


© 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!


© Fraunhofer

Solution Example - Gambling Machine


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


© 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


© 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


© 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)


© 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 ...


© 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


© 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


© Fraunhofer

Software Exploits



� How to protect?






C Update mechanisms


© Fraunhofer

Software Exploits



� How to protect?






C Update mechanisms


© Fraunhofer

Software Exploits



� How to protect?






C Update mechanisms


© 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!


© Fraunhofer







© Fraunhofer







© 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)


© Fraunhofer


� 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


© Fraunhofer


� 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


© Fraunhofer

PUF-based Secure Credential Storage for FPGAsSIBASE Demonstrator - WindTurbine Controller

Source: BMBF-Projekt SIBASE


© 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


© Fraunhofer

Date post:	05-Jun-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Security of Embedded IoT Devices Some Lessons Learnedmakesinformation security extremely important...

Documents