memory security management for fpga-based embedded system

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008

Memory Security Management for FPGA-based Embedded

systemRomain Vaslin, Guy Gogniat, Jean-

Philippe Diguet

Lab-STICC CRNS UMR 3192 – UBSLorient, France

[email protected]

Russell Tessier, Deepak Unnikrishnan

Reconfigurable Computing Group, UMass

Amherst, USA

[email protected]

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 2

INTRODUCTION

Cost of security: Memory Performance Energy

No architectural trick to solve these issues

New way of building application relying on specific security hardware


OUTLINE

OTP core overview Security memory management Experimental approach Experimental results Conclusion & future work


OUTLINE



OTP core overview (1/4)

Main idea: use the memory acces time to overlap the security computation (OTP generation and integrity checking) OTP generation: AES core Integrity checking: CRC

Processorcore

Memory

HSCSecured zone

SMM

Cache memories

OTPunit

Lo

gic

co

ntr

ol

OTPmem

CRCunit

CRCmem

OTP core principle



Data request

OTP generation (AES)xor

(a)

(b)

crc

Memory answer

Data request

Memory answer

OTP generation (AES)

Sending data to core

xor crc

xor

xor crcxor crc

xor crcxor crc

xor crcxor crc

Data request

(c)

Memory answer

OTP generation (AES) xor crc xor crc

Data 5-8

d2d3

d4d5

d6d7

d8

crc d1

Data 1-4

OTP core latency


OTP core overview (3/4)OTP core architecture – Write request

TRUSTED ZONE UNTRUSTED ZONE

OTP CORE : Write request of a cache line

AES core

Data

cach

eIn

str

ucti

on

cach

e

Processorcore

Externalmemory

Time Stampcomputation

TimeStamp

memory

Paddingvalue

AES key

AES

in

pu

t

AES

ou

tpu

t

XOR

@ ofCache line

AES core

Cip

here

d c

ach

e

lin

eCle

ar

cach

e

lin

e

CRCgenerator

CRCmemory

Original OTP core Extended OTP core



Externalmemory


@ ofCache line

Processorcore

OTP CORE : Read request of a cache line

Instr

ucti

on

cach

eD

ata

cach

e

TimeStamp

memory

Paddingvalue

AES key

AES

in

pu

t

AES

ou

tpu

t

AES core

XOR


Cle

ar

cach

e

lin

e

Cip

here

d c

ach

e

lin

e

CRCgenerator

CRCmemory

validation

= ?


OTP core architecture – Read request


OUTLINE



Security memory management (1/4)

Security management based on memory mapping of the code & data

Adapted for application running with an Operating System

Task 1 code

Task 2 code

Task n code

OS code

R/W data

OS data

Task 1 stack

Task 2 stack

Task n stack

Non protected

Confidentiality

Confidentiality / Integrity

Uniform protection Advantages:

Reduction of security memory overhead Reduction of software execution losses Reduction of power consumption due to

security

Principle



Externalmemory


@ ofCache line

Processorcore


Instr

ucti

on

cach

eD

ata

cach

e

TimeStamp

memory

Paddingvalue

AES key

AES

in

pu

t

AES

ou

tpu

t

AES core

XOR


Cle

ar

cach

e

lin

e

Cip

here

d c

ach

e

lin

e

CRCgenerator

CRCmemory

validation

= ?


Address filtering

Data filtering




OTP CORE : Write request of a cache line

AES core

Data

cach

eIn

str

ucti

on

cach

e

Processorcore

Externalmemory


TimeStamp

memory

Task IDAES key

AES

in

pu

t

AES

ou

tpu

t

@ ofCache line

AES core

Cip

here

d c

ach

e

lin

eCle

ar

cach

e

lin

e

CRCgenerator

CRCmemory

XOR= ?

validation

Core control

Core controlSecurityMemoryMapping

Architecture – Write request



Externalmemory


@ ofCache line

Processorcore


Instr

ucti

on

cach

eD

ata

cach

e

TimeStamp

memory

Task IDAES key

AES

in

pu

t

AES

ou

tpu

t

AES coreTime Stampcomputation

Cle

ar

cach

e

lin

e

Cip

here

d c

ach

e

lin

e

CRCgenerator

CRCmemory

validation

= ?

Core controlSecurityMemoryMapping

= ? Core control

validation

XOR

Architecture – Read request


OUTLINE



Experimental approach (1/2)

Global view of the architecture: NIOS 2 High resolution timer Flash bridge DDR sdram bridge JTAG

4 applications running with MicroC/OS-II: Image processing (morphological image

processing) Video On Demand (RS, AES, MPEG-2) Communication (RSd, AES,RSc) Multi hash (MD5, SHA-1, SHA-2 )

Architecture & Applications


Experimental approach (2/2)

3 security levels: No protection Uniform protection (Confidentiality

& integrity or confidentiality only for the whole memory)

Programmable protection (memory segment & policy decided by the software designer)

App. Tasks MemSegs.

Total mem (kB)Code / Data

Image 5 12 80 59

VOD 7 10 152 431

Comm 6 4 71 68

Hash 5 2 92 55

Applications partitioning

Confidentiality & integrity Confidentiality No protection

App code data code data code data

kB T S kB T S kB T S kB T S kB T S kB T S

Image 25 2 5 33 2 3 7 2 1 10 2 1 38 1 1 16 1 1

VOD 26 5 3 113

6 4 58 1 1 0 0 0 68 1 1 318

1 1

Comm

71 6 1 28 0 2 0 0 0 40 6 1 0 0 0 0 0 0

Hash 0 0 0 0 0 0 92 5 1 0 0 0 0 0 0 55 5 1


OUTLINE



Experimental result (1/5)

Programmable security applied has a direct impact on the size of the design

Area overhead

Uniform protection Programmable protection

NIOS II + HSC HSC NIOS II + HSC HSC

ALUTs FFs ALUTs FFs ALUTs FFs ALUTs FFs

Image 8147 4662 3325 1113 8342 4714 3505 1159

VOD 8301 4674 3441 1126 8335 4703 3489 1153

Comm.

8150 4670 3316 1116 8289 4677 3450 1135

Hash 7326 4405 2553 854 7086 4397 2295 848

~65 % for UP, ~70% for PP ~50 % for UP, ~45% for PP

Area overhead


20.5 % 13.75 %


Software performances losses compared with NP

Performances

No Protection

Uniform Protection Programmable Protection

(ms) (ms) (ms)

Image 512 79.8 103.8 -23% 92.9 -14%

Image 2k 56.0 68.7 -18% 62.8 -11%

VOD 512 6997.0 8810.0 -21% 8039.0 -13%

VOD 2k 4589.0 5459.0 -14% 5194.0 -12%

Comm 512 36.6 45.4 -20% 42.0 -13%

Comm 2k 22.6 25.2 -10% 24.6 -8%

Hash 512 4.5 5.5 -18% 5.3 -15%

Hash 2k 3.3 3.8 -15% 3.7 -14%

14.25 % 8.75%



Memory overhead is fully dependant of the designer choice for security policy

Memory has a double cost (space & energy)

Memory overhead

Uniform Protection

Programmable Protection

Image (kB)

42.2 20 52%

VOD (kB)

199.6 48.8 75%

Comm (kB)

43.2 33.2 23%

Hash (kB)

6.8 0 100% 20.0

6.3

38.0

6.517.8 17.8

0.0

14.8

8.3

107.8

28.317.0

7.0

0.0

7.4

5.4

53.8

14.1 8.5

8.5

0.06.80

20

40

60

80

100

120

140

160

180

200

imageprocessing UP

imageprocessing PP

VOD UP VOD PP communicationnode UP

communicationnode PP

multi hash UP multi hash PP

42.2

20

199.6

48.8

6.8

33.2

TS data

CRC data

CRC code

kbytes

43.2



Energy consumption

72

52

107

72

96

66

0

20

40

60

80

100

120

image processing512 bytes

image processing2 Kbytes

6.0

4.2

10.6

6.6

5.4

8.3

0

2

4

6

8

10

12

VOD 512 bytes VOD 2 Kbytes

Programmable protectionUniform protectionNo protection

33%

26%

~15% saved compared with UP ~30% saved compared with UP

38%

28%



4.0

3.0

6.0

4.2

5.7

4.0

0

1

2

3

4

5

6

7

multi hash 512bytes

multi hash 2 Kbytes

19

50

28

46

2729

0

10

20

30

40

50

60

communicationnode 512 bytes

communicationnode 2 Kbytes

Programmable protectionUniform protectionNo protection

58%

42%

~14% saved compared with UP ~8% saved compared with UP

33%

42%

Energy consumption


OUTLINE



Conclusion & future work

Security mapping can help to make some save (area, performance, memory, energy)

Fully done in hardware, no OS modification

Dynamic addition of new secured zone Download of new tasks Application update/patch

Important difficulties : identification of the entity which is writing in the hardware security core

memory security management for fpga-based embedded system

Documents