system level design methods for secure embedded...

Schaumont, CRASH 2005, 9/6/05

System Level Design Methodsfor Secure Embedded Systems

Patrick SchaumontCenter for Embedded Systems in Critical Applications

2Schaumont, CRASH 2005, 9/6/05

Secure Embedded Systems

MobileBiometrics

Access Control

MobileIdentification

MobileAuthentication

RFID

ElectronicTicketing

Tagging

Keys InventorySecure embedded systems face specific risks. They are1. more accessible2. more resource-constrained

Smart CardVehicle ID

Driver License

ElectronicPurse Health Care

e-Passport


More accessible = more vulnerable

Protocol

Algorithm

Crypto-Heaven

Architecture

Micro-Architecture

Circuit

Security Attacks Based On

Data Timing Energy

Channel

Stack/Memory

BusPower Analysis

EMI Analysis

DeviceExecution

(Intrusive or Passive)

(SW)

(HW)


More accessible = more vulnerable

Protocol

Algorithm

Crypto-Heaven

Architecture

Micro-Architecture

Circuit

Security Attacks Based On

Data Timing Energy

Channel

Stack/Memory

BusPower AnalysisEMI Analysis

DeviceExecution

(Intrusive or Passive)

Design methods for secureembedded systems aim to providesystematic protection against data-,

timing-, or energy-based SCAwhile considering design cost, performance and form factor.


Secure Embedded Technologies

• A low end RFID today:• 128-bit ROM, control circuit, RF & power circuit

• A high end smartcard today:• Pipelined 32-bit RISC• Memory management & protection hardware• 240 Kbyte ROM, 16Kbyte RAM, 912Kbyte EEPROM• Coprocessors for Public Key (RSA, ECC), DES, RNG• Timer, Sensors for hi/lo Voltage/Freq, Temp, Light

• Technologies are extremely diverse• Being part of a security chain, they can become ‘weakest links’• Therefore, embedding security means getting involved in a wide

range of technologies (software, hardware, circuits, layout, ..)

[Hitachi]

[Infineon]


Design Methods for Embedded Security

• Partitioning for Security• Protect Root of Trust

–Root of Trust = A component that must behave as expected, because misbehavior cannot be detected (Trusted Computing Group)

–Root of Trust = The part of the design that can hurt you ! (D. Gollmann)

• Example to discuss - Secure biometrics in ThumbPod (UCLA)

• Secure Codesign• Interface Refinement in a Security-partitioned system


The ThumbPod Project (UCLA)

bankThumbPod

fingerprint sensorembeddedelectronics

authenticatedcommunications

http://www.thumbpod.com


ThumbPod Operation

1. Enrollment

2. Normal Use

minutiaextraction

template(~30 minutia)

rand

User matchesstored template ?

send rand

reply token'E

template

token= ?


Partitioning the ThumbPod

MinutiaeExtraction

MatchingAlgorithm

Template

LoadBogus

LoadMaster

MasterKey

Accept Reject

Session Key Sk

rand

Crypto

Server(considered secure)

(insecure) ThumbPod-2 Client

keyplain

payloadcryptCrypto

Crypto

MasterKey

plain

Cryptopayload

Root-of-Trust


Partitioning the ThumbPod

MinutiaeExtraction

Template

LoadBogus

LoadMaster

MasterKey

Accept Reject

Session Key Sk

rand

Crypto

Server

ThumbPod-2 Client

keyplain

payloadcryptCrypto

Crypto

MasterKey

plain

Cryptopayload

MatchingAlgorithm

Architecture-LevelSecure Partition


ThumbPod-2 Client Microarchitecture

AMBALEON-2

ProcessorIn

Port

OutPort

ChipCommandInterface

Crypto Module

Oracle

Secure Circuit StyleBr

idge

RAM/FLASH Template

Master Key

to server UART to sensor

UART

MatchingAlgorithm


Oracle

QueryResponse

Untrusted Software

Secure matching of Minutiae

for each input minutia pair I:for each template minutia pair T:

if (I ~ T) matching_count++;

if (matching_count > N) then match = true;else match = false;

oknot ok

Input Template(secure)


HW/SW Partitions for secure matching

secure_initialize( );

for each input minutia pair I:for each template pair T

secure_compare( I );

if (secure_match( ))then match = true;else match = false;

secure_initialize( ) {matching_count = 0;

}secure_compare( I ) {

if (I == T)matching_count++;

}secure_match( ) {if (matching_count > N)

then return true;else return false;

}

oraclemain

extract I

Template

C

hardwareoracle

softwaredriver

secure_initialize( )secure_compare( )secure_match( )

secureinstruction

set

Template

secureinterface


System-level Security Partitioning

ServerClient

root-of-trust

Protocol/Algorithm-levelvalidation

Noncriticalsoftware

Matching &Crypto

SW

Architecture-levelvalidation

Architecture-levelattacks

Matching &Crypto

HW

Softwaredriver

Microarchitecture-levelvalidation

Microarchitecture-levelattacks

DPA-resistantHW

Circuit-levelattacks

Side-channel free circuit


System-level Security Partitioning

ServerClient

root-of-trust

Protocol/Algorithm-levelvalidation

Noncriticalsoftware

Matching &Crypto

SW

Architecture-levelvalidation

Architecture-levelattacks

Matching &Crypto

HW

Softwaredriver

Microarchitecture-levelvalidation

Microarchitecture-levelattacks

DPA-resistantHW

Circuit-levelattacks

Side-channel free circuit

GEZEL:Tool supportfor codesign


GEZEL

• Cycle-true Hardware Description Language• Deterministic and Implementation-oriented• Easy to learn and use (11-page LRM)

• Hardware Simulation Kernel• Open-source (C++) with co-simulation backend• Library block concept• Toggle/Operation Profiler

• VHDL/Testvector Backend


Example of a GEZEL codesign

Data

Addr

aes_decoder

128

128

128

Key

Plaintext

Crypttext

µPCore

aes_top(AES/ECB)

data_in(0x800000008)

instructions(0x800000000)

data_out(0x800000004)

ldrstdone

FSMD model of hardware HW/SW InterfacesLibrary Blocks

GEZEL Model

EmbeddedSoftware

Driver

SW Simulation(Instruction-Set

Simulation)Power Profile Cycle PerformanceVHDL


An FSMD in GEZEL

dp updown(out a : ns(4)) {reg c : ns(4);sfg inc { c = c + 1;

a = c; }sfg dec { c = c – 1;

a = c; }}

fsm ctl_updown(updown) {initial s0;state s1;@s0 if (c < 10) then (inc) -> s0;

else (dec) -> s1;@s1 if (c > 0) then (dec) -> s1;

else (inc) -> s0;}

+1 -1

c

a

s0

s1

<10 >0


DatapathFSM

Equivalent SystemC modelconst int counter_do_io = 1;const int counter_do_up = 2;const int counter_do_dn = 4;SC_MODULE(dp_counter) {sc_in <bool> clk;sc_in <sc_uint<3> > ins_counter;sc_in <sc_uint<2> > ud;sc_out<sc_uint<3> > a;sc_out<sc_uint<2> > flags_counter;sc_signal<sc_uint<3> > c, c_next;sc_signal<sc_uint<2> > u, u_next;sc_signal<sc_uint<3> > nc;void eval_logic();void update_regs();SC_CTOR(dp_counter) {SC_METHOD(eval_logic);sensitive << c << nc << ud;SC_METHOD(update_regs);sensitive_pos(clk);c = c_next = 0; u = u_next = 0;

}};void dp_counter::eval_logic() {sc_uint<3> sfg = ins_counter.read();if (sfg & counter_do_io) {u_next = ud.read(); a.write(nc);flags_counter.write(u);

}if (sfg & counter_do_up) {nc = c.read() + 1; c_next = nc;

}if (sfg & counter_do_dn) {nc = c.read() - 1; c_next = nc;

}}void dp_counter::update_regs() {u = u_next; c = c_next;}

SC_MODULE(fsm_counter) {sc_in <bool> clk;sc_in <sc_uint<2> > flags_counter;sc_out<sc_uint<3> > ins_counter;sc_signal<int> state, state_next;void eval_logic();void update_regs();SC_CTOR(fsm_counter) {SC_METHOD(eval_logic);sensitive << flags_counter << state;SC_METHOD(update_regs);sensitive_pos(clk);state = state_next = 0;

}};void fsm_counter::eval_logic() {sc_uint<3> flags = flags_counter.read();switch(state) {case 0:if (flags[0]) {state_next = 1;ins_counter.write(c_do_dn | c_do_io);} else {state_next = 0;ins_counter.write(c_do_up | c_do_io);}break;

case 1:if (flags[1]) {state_next = 0;ins_counter.write(c_do_up | c_do_io);} else {state_next = 1;ins_counter.write(c_do_dn | c_do_io);}break;

}}void fsm_counter::update_regs() {state = state_next;

}


FSMD networks

FSMD F1 FSMD F2

(Closed) FSMD networkswire

FSMD F1 FSMD F2

GEZEL models Extended FSMD networks

LibraryBlock

Library Block:- Interface in GEZEL- Body in C++- IO, Cosimulation, IP


Platform Simulators with GEZEL

parser

VHDLcodegen

executableobject

hierarchyuser-definedipblock impl.

GEZEL

RTcodegen

GEZEL Kernel(C++ Library)

EmSW

Instruction-SetSimulator

Cycle-trueSystem Scheduler

CommunicationChannel

Platform Simulator (by tool builder)

Application(by designer)


GEZEL Platform Simulator Examples

Single-Processor

µP coproc

Multi-Processor

µP

networkor

coproc

µP

Hybrid

µP

networkor

coproc

µP

32-bit

8-bit

SH3ARMLEON28051AVR

m-ARM m-ARM + n-8051SystemCJava (JNI)

port-mappedmemory-mappedcoprocessor-interface-mappedshared-memory buffer

GEZELGEZEL GEZEL


The codesign process

Caes(int *in,

int *key,int *out) {

// ..}

int main() {..aes(i, k, o);..

}

GEZELdp aes(in di: ns(128);

in k: ns(128);out do: ns(128)) {

...}

partitioning

HW/SWinterface

• Execution Model: How the coprocessor operates• Data Transfer Model: How data is exchanged with it


Execution and Data Transfer Models

ExecutionModel

Data TransferModel

High-level concerns(things to think of first)

Low-level concerns(things to think of next)

Concurrency ModelCo-processing Model Instruction-set Design

Parameters & ArgumentsAPI Model

Interface Design

Cost-effective embedded systems do not have to be fastest; they have to be efficient

# bitsgates . cyclesMAX


Execution Model - Concurrency

in

out

op

in-buffer

out-buffer

Concurrency Model

in

in-buffer

op out

out-buffer

pipe-buffer pipe-buffer

Block-pipelined

For single bus, should have Top ~ (Tin + Tout)


Data Transfer Model: Parms and Args

• Shared-memory model of C is forgiving. Any memory location will work as argument or as a parameter.

• e.g. int aes(int *din, int *key, int *out);

• In a coprocessor, difference is crucial• Parameter needs to be set once, enhances the operation• Argument needs to be set/retrieved every operation• Wrong partitioning results in a communications bottleneck.

in-argument parameter out-argumentfor ECB:


AES HW Performance - at JAVA level

log10(Cycles)

0

1

2

3

4

5

AES inJAVA

AES inHW

(but called from JAVA)

5.28

3.25

109Xperformance

gain

160Xintegrationoverhead

aes(din, key, dout)

log10(Cycles)

0

1

2

3

4

5

AES inJAVA

AES inHW

(but called from JAVA)

5.28

3.16 130Xintegrationoverhead

aes(din, dout)

134Xperformance

gain

• Compared to SW, HW is so fast, that API (and data copying) gets a key impact on resulting performance.

Execution stack: JAVA -> KVM -> LEON2 32-bit RISC -> AES HW


HW

Data Transfer Model: API Model• Crypto hardware needs

encapsulation• Register set, Shared storage• Address mapping• Interrupts

• Coprocessor design is constrained by many interfaces

• Driver API• Bus Interface

• Not just HW/SW interface design!• design usage model top-down

(from the programmer's viewpoint)• 'Firmware-friendly design', David

Fechser (EETimes series)

128128 Crypto

SW

Application

regfile

decode

control

standardbus

Adr Datainterrupt

irq( )

read( )write( )

open( )close( ) ioctl( )

polling( )

DriverAPI

async IO sync IO


The security dimension of coprocessors

• Need to consider security next to performance• Execution Model

• Execution is a (time+energy) side-channel.• Balance execution with constant-time/constant-

power implementation techniques.• Data Transfer Model

• API's are a (data) sidechannel [Bond, Anderson]. • Parameters vs Arguments: Parameters may

become side-channels [Chan].


Power/Operation profiles

0500

10001500200025003000350040004500

0 200 400 600 800 1000

GEZEL

$option "profile_toggle_alledge_operations"

Type Evalsdpinput 154924dpoutput 47000

reg 26077sig 56187

assign_op 129264ior_op 19769xor_op 140922and_op 2000shr_op 50769add_op 771sub_op 845not_op 2000sel_op 64592eq_op 6671

$option "profile_toggle_alledge_toggles"

1000 cycles of AES encryption for random data


Challenges for secure system design• System level:

• Trusted computing aims to support protected capabilities, integrity measurement, integrity reporting. http://www.trustedcomputinggroup.org

• 'Trusted computing' covers only the general case, application-specific solutions are still needed

• Tool support (for Thumbpod-type of designs)– Make security and trust 'measurable' as a quality of

individual bits & operations on these bits (modeling issue)– Partition algorithms in secure/non-secure parts: measure

information spread in the algorithm– Transform secure part for minimal complexity– Validate & verify security protocol and protocol faults


Challenges for secure system design

• Embedded Security is a big opportunity for hardware and logic

• Hardware offers qualities that software has lost (viruses etc)

• Besides performance, offers assured and constant-time behavior• Recent attack on hyper-threaded processors clarifies the issue for

software

• But for Big Time Secure Hardware• need modeling & design support for the complete security pyramid

(protocol, algorithm, ..., circuit)• need to recognize the weakest link principle:

look at the complete system and at multiple abstraction levels

Schaumont, CRASH 2005, 9/6/05

Thank You !

GEZEL Homepage:http://www.ee.ucla.edu/~schaum/gezel

system level design methods for secure embedded...

Documents