Hardware Mechanisms for Secured Memory/Configuration Transactions for Embedded Systems

Hardware Mechanisms for Secured Memory/Configuration Transactions

for Embedded Systems

Lionel Torres, P. Benoit,G. Sassatelli, P. Maurine

Contributeurs : R. Elbaz, B. Badrignans, F. Devic, L. Barthe, F. Poucheret, V. Lomne, A. Dehbaoui

2

Hardware Mechanisms for Secured Processor- Memory Transactions

Most embedded systems use off-chip memories: Data and instructions are exchanged in clear over the processor-memory bus. FPGA configuration

Address bus

Data bus

SoC/FPGA (Trusted)

ExternalMemory

Objectives: Ensure the confidentiality and the integrity of data stored in off-chip memories and transferred on SoC/FPGA memory interfaces.

Threats: Unauthorized data reads Code injection or data alteration Memory tampering Software, SCA attacks not

considered

Trusted Area

Introduction Cryptography & Threat Model

Contribution 1 PE-ICE & Trees ConclusionContribution 2

FPGAState of the art

3

o Introduction

o Threat Model

o State of the art

o Contribution 1: PE-ICE & PRV Tree Parallelized Encryption and Integrity Checking Engine

o Contribution 2: FPGA configuration SARFUM protocol

o Conclusion, Future Works

Introduction


Cryptography & Threat Model



4

COMP

Cryptographic Tools: Integrity Checking

H(M)Message M

Tag T

Alice

Bob

Unsecured channel

(M; T)

(M; T)M

TIntegrity Flag

K

K

Principle:

Meeting at 7h00 am in …

Meeting at 7h00 am in …

Hash functions: Compression function One-way function gives a compact representative image of the input

MAC(*) functions: take a secret key as additional input to authenticate the source of the message.

(*) Message Authentication Code

H(M)

Hashfunctionhi-1

Message Mimessage digest

hi = f(Mi, hi-1)MAC

function

K

Introduction

T’Tag reference




5

Passive Attacks

Address bus

Data bus

SoC (Trusted)

ExternalMemory

Bus probing – eavesdropping [1]

01010001000100000111001001

Add Data / Instruction

01010001000100000111001001

01110101010100010111001001

0x00000010

01110101010100010111001001

0x080ff0fa

[1] M. G. Kuhn, “Cipher Instruction Search Attack on the Bus-Encryption Security Microcontroller DS5002FP” IEEE Trans. Comput., vol. 47, pp. 1153–1157, October. 1998.




6

Passive Attacks

Attacker motivation: Off-line analysis:

• Key recovery • Message recovery

Raw materials for active attacks…

Address bus

Data bus

SoC (Trusted)

ExternalMemory

01010001000100000111001001

Add Data / Instruction

01110101010100010111001001

0x00000010 0x080ff0fa

0x00000014 0x0ab820ff

0x000000180x0000001C0x00000020

0x080112f40x102bcd0f

0x11ff11ab

Bus probing – eavesdropping [1]

[1] M. G. Kuhn, “Cipher Instruction Search Attack on the Bus-Encryption Security Microcontroller DS5002FP” IEEE Trans. Comput., vol. 47, pp. 1153–1157, October. 1998.




7

Active Attacks

Address bus

Data busSoC

(Trusted)

Spoofing: Random data injection Memory

Code and data injection

ExternalMemory

MaliciousMemory

Three kinds of active attacks are defined depending on the choice made by the adversary on the data to insert:




8

Active Attacks


Spoofing: Random data injection Splicing: Spatial permutation

Memory

Data(@2)Data(@3)Data(@4)Data(@5)Data(@6)Data(@7)Data(@8)Data(@7)

Data(@7)

SoC (Trusted)


Address bus

Data bus

Data(@1)

Introduction

ExternalMemory

MaliciousMemory




9

Data(@7, t1)

Active Attacks


Address bus

Data busSoC

(Trusted)


Spoofing: Random data injection Splicing: Spatial permutation Replay: Temporal permutation

Memory

Data(@2, t1)Data(@3, t1)Data(@4, t1)Data(@5, t1)Data(@6, t1)

Data(@8, t1)

Data(@1, t1)

Data(@4, t1)

Data(@1, t4)

Data(@3, t8)Data(@4, t7)


Data(@2, t9)


Introduction

ExternalMemory

MaliciousMemory




10

Active Attacks


Address bus

Data busSoC

(Trusted)


Spoofing: Random data injection Splicing: Spatial permutation Replay: Temporal permutation

Attacker motivation: Hijack the software execution Reduce the search space for key recovery or message recovery

Introduction

ExternalMemory

MaliciousMemory




11

General Principles

Cac

heSoC: Trusted area

CPU core

Mem

ory

Con

trol

ler

External Memory

Ciphered memory block

Untrusted area

Trusted areaEDU: Encryption Decryption Unit

ICE: Integrity Checking Engine

Memory block Tag

EDU

Cac

he

SoC: Trusted area

CPU core

Mem

ory

Con

trol

ler

ICE

External Memory

Data Confidentiality: symmetric encryption

Data Integrity: append a MAC generated digest ( tag)

MAC: Message Authentication Code




12

2 passes over the data and usually 2 algorithms used (one for each security primitives: Encryption and Integrity checking)

Ciphertext Tag

Encryption

KeMAC

KmEncryption

Ke

MAC

Km

Ciphertext Tag

Plaintext

Payload

Plaintext

Payload

Encrypt-then-MAC:

Encrypt-and-MAC:

Payload Tag Encryption

KeMAC

Km

Payload Plaintext

MAC-then-Encrypt: Ciphertext E(T)

E(T): Encrypted tagWrite and Read operations:

Not parallelizable

Write operations: Not parallelizable

Read operations: Not parallelizable

General PrinciplesIntroduction Cryptography

& Threat ModelContribution 1 PE-ICE & Trees ConclusionContribution 2


13

State of the Art: SummaryIntroduction

Objectives Countermeasures / Techniques Drawbacks

Ensure ConfidentialityThwart Spoofing Attacks

Generic composition scheme:Encryption + MAC (Data)

Non ParallelizableHardware Expensive

Prevent Splicing Attacks Generic composition scheme:Encryption + MAC (Data, @)

N/A

Prevent Replay Attacks

Generic composition scheme:On-chip memory

expensiveEncryption +

MAC (Data, @, RV)

Encryption + Hash (stored

on-chip)

On-chip Memory Optimization NONE Hash Trees Non Parallelizable




14

o Introduction

o Threat Model

o State of the art




Introduction





15

PE-ICE Principles

PE-ICE: Parallelized Encryption & Integrity Checking Engine Only 1 pass over the data to provide both data confidentiality and integrity. Tag are not computed over the data

Confidentiality is ensured by block encryption Rijndael (J.Daemen, V.Rijmen) – AES (NIST(*) standard)

Data integrity checking relies on the diffusion property of block encryption:

P TBlock

Encryption (Ek)

Ciphered (P;T)

AREA (Added Redundancy Explicit Authentication) applied at the block levelRedundancy is inserted in each plaintext block before encryptionRedundancy is checked after each block decryption

Introduction

(*) NIST: National Institute of Standard and Technology AES: Advanced Encryption Standard




16

PE-ICE for Read Only Data

SoC: Trusted areaM

emor

yC

ontr

olle

rExternal Memory

CPU

Cac

he

Address bus

PE-ICE Ciphered memory block

SoC: Trusted area

Mem

ory

Con

trol

ler

External Memory

CPU

Cac

he

Address bus

PE-ICECiphered

memory blockBlock

Encryption

Block Decryption

COMP

OK?

Write operations: The redundancy is added in each plaintext block

Read operations: The redundancy is checked after decryption

C = Ek (PL || ADD)

PL || ADD = Dk(C)

Introduction

T’ = ADD’

T = ADDT’ = T ?




17

SoC: Trusted area

Mem

ory

Con

trol

ler

External Memory

CPU

Cac

he PE-ICE

Memory

Block Encryption

RV Generator

PE-ICE for Read Write Data

C: Ciphered memory block


RV’

Introduction

C = Ek (PL || RV)

RV’ RV




18

SoC: Trusted areaM

emor

yC

ontr

olle

rExternal Memory

CPU

Cac

he PE-ICECiphered

memory block

Memory

SoC: Trusted area

Mem

ory

Con

trol

ler

External Memory

CPU

Cac

he PE-ICE

Memory

Block Encryption

RV Generator

PE-ICE for Read Write Data

C: Ciphered memory block

Block Decryption

COMP

OK?


Read operations: The redundancy is checked after decryption

RV’

RV’

Introduction

C = Ek (PL || RV)

PL || RV = Dk(C)

T’ = RV’

T = RVT’ = T ?

RV’ RV




19

PE-ICE: Simulation Results (2/2)

0,8

0,82

0,84

0,86

0,88

0,9

0,92

0,94

0,96

0,98

1

(a) 4KB

Nor

mal

ized

(to

AES

) IPC

0,8

0,82

0,84

0,86

0,88

0,9

0,92

0,94

0,96

0,98

1

(b) 128KB

Nor

mal

ized

(to

AES

) IPC

PE-ICE GC (CBC-MAC)

18%5%

Performance overhead of the integrity checking mechanisms




PE-ICE Vs Encrypt-then-MAC

AES GC (AES + CBC-MAC) PE-ICE

Hardware cost 80kgates 144Kgates +80% 80Kgates ~ 0%

Latencies - +54,5% +13%

Run-time slowdown

4KB - +13,7% +3,4%

128KB - +7,8% +1,7%

Off-chip Memory consumption - +12,5% +25%

Introduction

Summary:




PE-ICE - Properties






N/A




MAC (Data, @, RV)


on-chip)


Introduction

PE-ICE is parallelizable on read and write operations with hardware area optimization.




22

PE-ICE On-Chip Memory Overhead

SoC: Trusted area

Mem

ory

Con

trol

lerCPU

Cac

he

PE-ICEBlock

Encryption

External Memory

PMRRV

GeneratorRV’1RV’2RV’3RV’4RV’5RV’6RV’7RV’8

Memory

Ek(M1 || M2 || RV1)Ek(M3 || M4 || RV2)Ek(M5 || M6 || RV3)Ek(M7 || M8 || RV4)


Introduction

On-chip storage of the Reference Random Values (RV’):Drawbacks: high on-chip memory overhead

PMR: Protected Memory Region

Cryptography & Threat Model ConclusionContribution 2

FPGAState of the art Contribution 1 PE-ICE & Trees

23

PRV-Trees

SoC: Trusted area

Mem

ory

Con

trol

lerCPU

Cac

he

PE-ICEBlock

Encryption

External Memory

PMRRV

GeneratorRV’1RV’2RV’3RV’4RV’5RV’6RV’7RV’8

Memory

Ek(RV’1 || RV’2 || RV11)Ek(RV’3 || RV’4 || RV12)Ek(RV’5 || RV’6 || RV13)Ek(RV’7 || RV’8 || RV14)

RV’11RV’12RV’13RV’14



PRV-Trees: scheme relying on PE-ICE allowing to securely store Reference Values (RV’) off-chip

Introduction




24

PRV-Trees

SoC: Trusted area

Mem

ory

Con

trol

lerCPU

Cac

he

PE-ICEBlock

Encryption

External Memory

PMRRV

Generator

Memory

RV’11RV’12RV’13RV’14

Ek(RV’11 || RV’12 ||RV21)Ek(RV’13 || RV’14 ||RV22)

Ek(RV’1 || RV’2 || RV11)Ek(RV’3 || RV’4 || RV12)Ek(RV’5 || RV’6 || RV13)Ek(RV’7 || RV’8 || RV14)



RV’21RV’22RV’r

Ek(RV’21 || RV’22 || RVr)

PRV-Tree: scheme relying on PE-ICE allowing to securely store Reference Values (RV’) off-chip

Introduction




25

Tree Structure & Initialization

RV’21 RV’22 Non Trusted stored off-chip

Trusted stored on-chip

M1 M2RV1

M3 M4RV2

M5 M6RV3

M7 M8RV4

M9 M10RV5

M15 M16RV8

M13 M14RV7

M11 M12RV6

RV11 RV12 RV13 RV14RV’1 RV’2 RV’3 RV’4 RV’5 RV’6 RV’7 RV’8

RV’11 RV’12 RV’13 RV’14

RV’r

RV21 RV22

RVr

Introduction Cryptography & Threat Model ConclusionContribution 2


26

Read Operations – Integrity Checking

RV’21 RV’22

M1 M2RV1

M3 M4RV2

M5 M6RV3

M7 M8RV4

M9 M10RV5

M15 M16RV8

M13 M14RV7

M11 M12RV6


RV’11 RV’12 RV’13 RV’14

RV’r

RV21 RV22

RVr

Introduction


Non Trusted stored off-chipRead Operations

Integrity Checking



27

Ek(RV’11||RV’12 ||RV21)

Ek(RV’21||RV’22 || RV’r)

Ek(RV’3||RV’4||RV12)

Ek(M5 || M6 || RV3)


RV’21 RV’22

M1 M2RV1

M3 M4RV2

M5 M6RV3

M7 M8RV4

M9 M10RV5

M15 M16RV8

M13 M14RV7

M11 M12RV6


RV’11 RV’12 RV’13 RV’14

RV’r

RV21 RV22

RVr

Ek(M5 || M6 || RV3)


Ek(RV’11||RV’12 ||RV21)

Ek(RV’21||RV’22 || RVr)

RV’r

Decryption Decryption DecryptionDecryption

RV’r

Introduction


Non Trusted stored off-chip



28


RV’21 RV’22

M1 M2RV1

M3 M4RV2

M5 M6RV3

M7 M8RV4

M9 M10RV5

M15 M16RV8

M13 M14RV7

M11 M12RV6


RV’11 RV’12 RV’13 RV’14

RV’r

RV11 RV12

RVr


M5 M6 RV3 RV’3 RV’4 RV12 RV’12 RV’11 RV21 RV’21 RV’22 RVr

RV’r

Introduction



Integrity Checking



29


RV’21 RV’22

M1 M2RV1

M3 M4RV2

M5 M6RV3

M7 M8RV4

M9 M10RV5

M15 M16RV8

M13 M14RV7

M11 M12RV6


RV’11 RV’12 RV’13 RV’14

RV’r

RV11 RV12

RVr

OK?



RV’r

Introduction



Integrity Checking



30

Write Operations – Tree Update

RV’21 RV’22

M1 M2RV1

M3 M4RV2

M5 M6RV3

M7 M8RV4

M9 M10RV5

M15 M16RV8

M13 M14RV7

M11 M12RV6


RV’11 RV’12 RV’13 RV’14

RV’r

RV21 RV22

RVr

M5b

Introduction


Non Trusted stored off-chipWrite

Operations

Tree Update



31

Ek(M5 || M6 || RV3)


Ek(RV’11||RV’12 ||RV21)

Ek(RV’21||RV’22 || RV’r)


RV’21 RV’22

M1 M2RV1

M3 M4RV2

M5 M6RV3

M7 M8RV4

M9 M10RV5

M15 M16RV8

M13 M14RV7

M11 M12RV6


RV’11 RV’12 RV’13 RV’14

RV’r

RV21 RV22

RVr

Decryption Decryption Decryption Decryption

Encryption Encryption Encryption Encryption

Ek(M5 || M6 || RV3)


Ek(RV’11||RV’12 ||RV21)

Ek(RV’21||RV’22 || RVr)


M5b

RV3b

RV12b

RV21b

RVrb

Introduction



Operations

Tree Update



32


RV’21 RV’22

M1 M2RV1

M3 M4RV2

M5 M6RV3

M7 M8RV4

M9 M10RV5

M15 M16RV8

M13 M14RV7

M11 M12RV6


RV’11 RV’12 RV’13 RV’14

RV’r

RV21 RV22

RVr




M5b

RV3b

RV12b

RV21b

RVrb

Introduction



Operations

Tree Update



33

RV’rb

RV’3


RV’3b

RV’21 RV’22

M1 M2RV1

M3 M4RV2

M5 M6RV3

M7 M8RV4

M9 M10RV5

M15 M16RV8

M13 M14RV7

M11 M12RV6


RV’11 RV’12 RV’13 RV’14

RV’r

RV21 RV22

RVr



M5 M6 RV3 RV’4 RV12 RV’12 RV’11 RV21 RV’21 RV’22 RVr

M5b

RV3b

RVrb

M5b RV3b RV12b RV’21b RVrbRV’12b RV’3b RV’12bRV12b RV21b

RV’21bRV21b

Introduction



Operations

Tree Update



34


RV’21 RV’22

M1 M2RV1

M3 M4RV2

M5 M6RV3

M7 M8RV4

M9 M10RV5

M15 M16RV8

M13 M14RV7

M11 M12RV6


RV’11 RV’12 RV’13 RV’14

RV’r

RV21 RV22

RVr



RVrbRV’rb

RV’3M5 M6 RV3 RV’4 RV12 RV’12 RV’11 RV21 RV’21 RV’22 RVrM5b RV3b RV12b RV’21b RVrbRV’3b RV21bRV’12b

Ek(M5b || M6 || RV3b)

Ek(RV’3b||RV’4 ||RV12b)

Ek(RV’11||RV’12b ||RV21b)

Ek(RV’21b||RV’22 || RVbr)

Introduction



Operations

Tree Update



35


RV’21 RV’22

M1 M2RV1

M3 M4RV2

M5 M6RV3

M7 M8RV4

M9 M10RV5

M15 M16RV8

M13 M14RV7

M11 M12RV6


RV’11 RV’12 RV’13 RV’14

RV’r

RV21 RV22

RVr



RV’rbEk(M5b || M6 ||

RV3b)Ek(RV’3b||RV’4 ||

RV12b)Ek(RV’11||RV’12b

||RV21b)Ek(RV’21b||RV’22

|| RVbr)

RV3bM5b

RV12bRV’3b

RV21bRV’12b

RV’21bRV’rb

RV’rb

Introduction



Operations

Tree Update



PE-ICE & PRV-Trees - Properties






N/A




MAC (Data, @, RV)


on-chip)


PRV-Trees: Optimized the on-chip memory overhead- Parallelizable on read and write operations- Can be applied to the 1st replay attack countermeasure

PRV-Trees



37

Conclusion & Perspectives

PE-ICE: Parallelized way to provide data confidentiality and integrity Optimized Hardware resources required

ImplementationAdd a compression technique

PRV-Trees: Reduce the on-chip memory overhead to the storage of a single

Reference Values (RV’) Parallelizable on read and write operations Easily adaptable to MAC based replay countermeasures Partial authentication

Mathematical proofEvaluation



38

o Introduction

o Threat Model

o State of the art




Introduction





Untrusted medium

System owner (untrusted)

FPGA (trusted)User logic

System designer

BitstreamConfiguration

Module

Non Volatile Memory for bitstream

(untrusted)

FPGA Vendor Trusted

FPGA Chip Trusted

System Designer Trusted

NVM Untrusted

System owner Untrusted



FPGA Bitstream configuration protection

Untrusted medium



System designer

Bitstream

Key(s)

Crypto ConfigurationModule

Key(s)

Crypto


(untrusted)

Provided by FPGA vendors






System designer

Bitstream

Key(s)


Key(s)

Crypto


(untrusted)

Untrusted medium

Encrypted Bitstream

Design

Bitstream




Untrusted medium



System designer

Bitstream

Key(s)


Key(s)

Crypto


(untrusted)

Our Objectives :- Ensure confidentiality

- Ensure integrity- Avoid system downgrade




1 SRAM : SRAM based FPGAs (Xilinx, Altera, Lattice)

Issue Impact on FPGA design

Generic Solution

FPGA Vendors Solution

SRAM1 ACTEL

Confidentiality Cloning / IP Theft Encryption AES (128/256)

Tampering / Spoofing

Design Modification Integrity Check CBC2 +

CRC3

AES based MAC4

Old Bitstream Replays

System Downgrade

Unique time-stamp / Non Volatile State

None

Security Model




Generic Solution


SRAM1 ACTEL


Integrity Design Modification Integrity Check CBC2 +

CRC3

AES based MAC4

Old Bitstream Replays

System Downgrade


None

1 SRAM : SRAM based FPGAs (Xilinx, Altera, Lattice)2 CBC : Cipher Block Chaining : block cipher mode of operation

3 CRC : Cyclic Redundancy Check4 MAC : Message Authentication Code

Security Model


Generic Solution


SRAM1 ACTEL


Integrity Design Modification Integrity Check CBC2 +

CRC3

AES based MAC4

Replay attack System Downgrade


None

1 SRAM : SRAM based FPGAs (Xilinx, Altera, Lattice)2 CBC : Cipher Block Chaining : block cipher mode of operation

3 CRC : Cyclic Redundancy Check4 MAC : Message Authentication Code



Security Model

Encryption for confidentiality

Configuration Module

KENC

Decryption

engine

Untrusted medium

User LogicFPGA

Encrypted

Bitstream (EB)

Bitstream

Design

EB : Encrypted Bitstream



Encryption and Message Authentication Code For confidentiality and integrity

Configuration Module

KENC

Decryption

and MAC

engine

Untrusted medium

User LogicFPGA

EB || MAC (EB)

KMAC

Bitstream

Design

VALID ?

EB : Encrypted BitstreamMAC : Message Authentication Code|| : concatenation

Proposed by :- Actel : Actel Application Note : Fusion security

- Saar Drimer, University of Cambridge : Authentication of FPGA Bitstreams : Why and How ?



Replay attack

FPGA (trusted)User logicSystem designer

Bitstream

(version i)Key(s)

Crypto

ConfigurationModule

Key(s)

Crypto

Version i

Version i+n

FPGA (trusted)User logicSystem designer

Bitstream

(version i+n)

Key(s)

Crypto

ConfigurationModule

Key(s)

Crypto

HACKER

EB (Version i)

Untrusted medium

Untrusted medium

EB (Version i)EB (Version i)

EB (Version i+n)

Design

(Vi)

Design

(Vi)



Secure Update Mechanism, Principle

Alice (System Designer) Bob (FPGA)

KMAC

Non volatile

TAG Alice = 0

KENC KMAC

Non volatile

TAG Bob = 0

KENC

Encrypted Message || MAC (Message || 0)MAC validation using

(Message || 0 )

Message decryption using KENC

TAGALICE TAGBOB




KMAC

Non volatile

TAG Alice = 0

KENC KMAC

Non volatile

TAG Bob = 0

KENC

CmdTAG+1 || MAC (CmdTAG+1 || 0)MAC validation using

(CmdTAG+1 || 0)

TAG+1

TAG+1

Message || MAC (Message || 1)MAC validation using

(Message || 1)

Non volatile

TAG Alice = 1Non volatile

TAG Bob = 1





KMAC

Non volatile

TAG Alice = 2

KENC KMAC

Non volatile

TAG Bob = 2

KENC

TAG + 1

Message

TAG + 1

Message...




Architecture preventing system downgrade

SUM

KENC

Decryption

and MAC

engine

Untrusted medium

User LogicFPGA

KMAC

Update Logic TAGSUM

SUM : Secure Update Module

VALID ?



Remote TAG increment process

SUM

KENC

Decryption

and MAC

engine

Untrusted

medium

User LogicFPGA

KMAC

Update Logic TAGSUM

System Designer

TAGSDKMAC

MAC

engine

CmdTAG+1

Design

CmdTAG+1 ||

MAC (CmdTAG+1 || TAG SD)

VALID ?

TAG + 1Introduction Cryptography

& Threat Model ConclusionContribution 2 FPGAState of the art Contribution 1

PE-ICE & Trees

Bitstream validation

SUM

KENC

Decryption

and MAC

engine

Untrusted

medium

User LogicFPGA

KMAC

Update Logic TAGSUM

System Designer

TAGSDKMAC

Encryption

and MAC

engine

Bitstream Bitstream

Design

VALID ?

KENC

EB || MAC (EB ||TAGSD)



Acknowledgement


KMAC

Non volatile

TAG Alice = 0

KENC KMAC

Non volatile

TAG Bob = 0

KENC

CmdTAG+1 || MAC (CmdTAG+1 || 0)MAC validation using

(CmdTAG+1 || 0)

TAG+1

TAG+1

Ack || MAC (Ack || 1)

Ack = Acknowledgement



Performances / Overhead

Area Crypto engine Throughput

Max. configuration

speed

No security 0 - 3.2Gb/s [1]

Confidentiality(AES-CBC)

~15k Gates [2] 1000 Mb/s [2] 580 Mb/s [1]

Confidentiality and integrity

(AES-CCM)57 kGates [2] 430 Mb/s [2] 430 Mb/s [2]

SUM (With AES-CCM)

~ 58 kGates 430 Mb/s 430 Mb/s

[1] XILINX, 2008, Virtex-5 FPGA Configuration User Guide

[2] Parelkar, M.M.: Authenticated encryption in hardware. Master’s thesis, George Mason University, Fairfax, VA, USA (2005)




Max. configuration

speed



~ 15 kGates [2] 1000 Mb/s [2] 580 Mb/s [1]


(AES-CCM)~ 23 kGates [2] 430 Mb/s [2] 430 Mb/s [2]

SUM (With AES-CCM)









Max. configuration

speed



~15 kGates [2] 1000 Mb/s [2] 580 Mb/s [1]


(AES-CCM)~ 23 kGates [2] 430 Mb/s [2] 430 Mb/s [2]

SUM (With AES-CCM)






60

o Introduction

o Threat Model

o State of the art




Introduction





61

Futur works : Flexible security

Threat model evolution : SCA are consideredHW security at the architectural level

Ideas based on self adaptive architectures- (1) Configurations mouvantes

• grain fin, grain épais (HW), grain logiciel- (2) Processeur Généraliste Sécurisé

Side Channel Attacks



62

« Fuzzy » Configuration (1)

Fine Grain- DES « Fuzzy configuration »

• Principle: Generic SBOX+ random shift• DEMA Results: efficiency limited

Travail réalisé avec F. Poucheret, P. Maurine



63


Coarse Grain- Principle

• Random moving on all the HW blocks• DEMA results: to be done



64


Software grain- Principle, task migration

• MPSOC Architectures• Data Instructions Randon moving• Attacks on processor



65

Attacks on processor

MicroBlaze (Xilinx)- RISC 5 étages



66

Secure processor (native)

• Why?• Heart of security (co-processors aren’t alone!)

• Specifications (SCA)• Masking• Non-determinism • Random Execution Order (REO)

• State of Art• Few-architectural design for SCA (asynchronous processors)

• Ideas• Temporal jitter could be done with “elastic-pipeline” • Pseudo-REO could be implemented with a special hardware architecture with

priority instruction strategies (static & dynamic methods)• Special “masked registers” • Load/Store instructions are critical => bus masking strategies• Cache is also a weak point • These features could be combined with others secure techniques in order to

provide a secure processor against all kind of attacks (FA, Spoofing...)



Hardware Mechanisms for Secured Memory/Configuration Transactions for Embedded Systems

Documents