Secure Design Methodology and The Tree of Trust · 4 7 What drives secure partitioning? •...

1

Secure Design MethodologyandThe Tree of Trust

Patrick Schaumont

Secure Embedded Systems Group

ECE Department

Virginia Tech

2

The new Cool: Reverse Engineering ...

Microsoft Zune (http://bunniestudios.com) Under the Hood (http://www.techonline.com)

Patrick Schaumont DATE 07 Friday Workshop on Secure Embedded Implementations

2

3

... in a complete curriculum.

Learn hacking tricks .. (http://www.blackhat.com)

.. and write papers on it

(http://www.ssddfj.org)


4

It's fun to break things ..• but this presentation is about making things.

• How to handle 'secrets' in a design?

• Systematic side-channel-resistant design?

• Jumping forward, we will conclude:

• Secure design of embedded systems needs a methodology. Ad-hoc security is doomed to fail.

• Perfect security does not exist (zero-power design doesn't exist either)

• Low-risk security does exist (low-power design does exist)


3

5

The starting point: Root of Trust• A secret in a box by itself is useless

(useless like a key without a matching door-lock)

• So a secure system contains at least two parts:

secure

embedded

system

distrusted

environment

root-of-trustsecurity policy

• authentication

• integrity

• confidentiality

• non-repudiation

• availability


The part that always

works as expected

(or so you think!)

6

Design Step: Secure partitioning

secureembedded

system

distrustedenvironment

secureembeddedsubsystem

distrustedembeddedsubsystem


4

7

What drives secure partitioning?

• Minimize footprint of the root-of-trust

• Reduce the physical size of the root-of-trust

• Make the root-of-trust dynamic and short-lived

• Minimize the risk for side-channel-attacks

• A side-channel-attack is an interface into the root-of-trust around the security policy

side-channel-attack

secureembedded

system

distrustedenvironment


8

Side Channel Attaxonomy

Abstraction

Level

Attacker

ProximityCountermeasure Example

Math

Interpreter

Time

Power

EM

Implementation

Off-line Algorithm Cryptanalysis

Connected

Close-range

Physical

Protected Partition

Constant-time

Constant-powerMasked-power

Aluminium foil

Shielding

Software Tampering [vanOorschot]

Faults [Joye]

Cache [Osvik]

Branch Prediction [Aciimez]

DPA [Oswald/Mangard]

+ Higher-order

Semi-Invasive [Skorobogatov]

DPA [De Mulder]


5

9

Example 1: Cache timing attack

addroundkey

mixcolumns

shiftrows

sbox

CACHE(1 cycle/acces)

MEMORY(20 cycle/acces) round keysdata in

(last round)

• Execution time dependency due to cache conflicts

• Software Solution: constant-time crypto (hard)

data out


10

Example 1: Cache timing attack

addroundkey

mixcolumns

shiftrows

sbox

CACHE(1 cycle/acces)

MEMORY(20 cycle/acces) round keysdata in

(last round)

• Execution time dependency due to cache conflicts

• Software Solution: constant-time crypto (hard)

Root-of-Trust

Timing Side-Channel

data out

Top-levelPolicy


6

11

Moving Sbox into Hardware

sbox

(AES32)ALU

RAM

DCACHE

ICACHE

register

file

instructionfetch/

decodeSBOX regs

(16 byte +

4 byte rkey)

128 32

128

32

32

Hardware Sboxwith ASIP interface

AESdrivercode

CPU


12

Moving Sbox into Hardware

sbox

(AES32)ALU

RAM

DCACHE

ICACHE

SBOX regs

(16 byte +

4 byte rkey)

128 32

128

32

32

CPU

Hardware Sboxwith ASIP interface

Constant Execution Timing

AESdrivercode

Software Sbox:159 Dcache138 Icache

Hardware Sbox0 Dcache

52 Icache

Cache miss rateper encryption

• Timing Side-channel fixed, but others remain ..

StrongARM arch

1K I, 1K D cache,

16 byte/line direct

instructionfetch/

decoderegister

file


7

13

The Tree of Trust

secure

embedded

system

distrusted

environment

crypto

softwarenon-critical software

crypto

hardware

crypto

circuit

non-critical

hardware/

software

non-critical

circuit

Interpreter Side-channels

Timing Side-channels

Power Side-channels

PhysicalTamper-resistance


14

Where does it end? A hacker's view

http://bunniestudios.com


8

15

Where does it end? A designer's view

• It doesn't - the tree of trust solves a turtle problem

• Deploy countermeasures systematically and analyze vulnerabilities at each level

• Software-only is insufficient(eg. Fairplay iTunes)

• Hardware-only is insufficient(eg. Hardware keys in DVD, Xbox, HDCP)

• Working in our favor are:

• Moore's law

• Distribution of trust across the tree


16

The Tree of Trust

secure

embedded

system

distrusted

environment

crypto

softwarenon-critical software

crypto

hardware

crypto

circuit

non-critical

hardware/

software

non-critical

circuit

Deploy

Countermeasures

Distributed,

dynamic

secrets


9

17

Example #2: Chain-of-trust

Decode

D/A &Amplify

Decrypt(DRM)

FlashMemory

Side-channel:Probe and extract

DRM-freehigh-quality

music

Downloadcopy-righted multimedia

into player


18

Chain-of-trust for Video Messaging

ProgramMemory

PPC

SAMTrivium

Stream

CipherVGA

key

Display SW

Trivium Key

Message

CF-card

FPGA-uniqueencryption

FPGA

correct authenticationcomplete

chain-of-trust

incorrect authenticationincomplete

chain-of-trust


[Simpson, Yu, Schaumont]

10

19


ProgramMemory

PPC

SAMTrivium

Stream

CipherVGA

key

Display SW

Trivium Key

Message

CF-card


FPGA


20


PPC

Baseline

Config

CompactFlash Data

ProgramMemory

PPC

SAMTrivium

Stream

CipherVGA

key

Display SW

Trivium Key

Message

CF-card


FPGA

FPGAbitstreamdecryption

(keys)


11

21


PPC

Baseline

Config

CompactFlash Data

ProgramMemory

PPC

SAMTrivium

Stream

CipherVGA

key

Display SW

Trivium Key

Message

CF-card


FPGA

SAMdecryption

(PUF)Configure

VGA Display

Secure SW

& Data Download


22


PPC

Baseline

Config

CompactFlash Data

ProgramMemory

PPC

SAMTrivium

Stream

CipherVGA

key

Display SW

Trivium Key

Message

CF-card


FPGA TriviumStream Cipher

(key)

Configure

VGA Display

Secure SW

& Data Download

Display

VideoMessage

LoadEncrypted

Message


12

23

Conclusions• Secure design of embedded systems needs a

methodology. Ad-hoc security is doomed to fail.

• The Tree-of-Trust advocates stepwise partitioning of an embedded system to achieve trustworthy operation

• Perfect security does not exist (zero-power design doesn't exist either)

• Low-risk security does exist (low-power design does exist)


Secure Design Methodology and The Tree of Trust · 4 7 What drives secure partitioning? •...

Documents

Transcript of Secure Design Methodology and The Tree of Trust · 4 7 What drives secure partitioning? •...