Memory Security Management for FPGA-based Embedded system
description
Transcript of 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
Russell Tessier, Deepak Unnikrishnan
Reconfigurable Computing Group, UMass
Amherst, USA
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
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 3
OUTLINE
OTP core overview Security memory management Experimental approach Experimental results Conclusion & future work
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 4
OUTLINE
OTP core overview Security memory management Experimental approach Experimental results Conclusion & future work
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 5
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
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 6
OTP core overview (2/4)
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
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 7
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
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 8
OTP core overview (4/4)
Externalmemory
TRUSTED ZONE UNTRUSTED ZONE
@ 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
Time Stampcomputation
Cle
ar
cach
e
lin
e
Cip
here
d c
ach
e
lin
e
CRCgenerator
CRCmemory
validation
= ?
Original OTP core Extended OTP core
OTP core architecture – Read request
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 9
OUTLINE
OTP core overview Security memory management Experimental approach Experimental results Conclusion & future work
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 10
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
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 11
Security memory management (2/4)
Externalmemory
TRUSTED ZONE UNTRUSTED ZONE
@ 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
Time Stampcomputation
Cle
ar
cach
e
lin
e
Cip
here
d c
ach
e
lin
e
CRCgenerator
CRCmemory
validation
= ?
Original OTP core Extended OTP core
Address filtering
Data filtering
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 12
Security memory management (3/4)
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
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
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 13
Security memory management (4/4)
Externalmemory
TRUSTED ZONE UNTRUSTED ZONE
@ ofCache line
Processorcore
OTP CORE : Read request of a cache line
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
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 14
OUTLINE
OTP core overview Security memory management Experimental approach Experimental results Conclusion & future work
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 15
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
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 16
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
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 17
OUTLINE
OTP core overview Security memory management Experimental approach Experimental results Conclusion & future work
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 18
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
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 19
20.5 % 13.75 %
Experimental result (2/5)
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%
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 20
Experimental result (3/5)
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
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 21
Experimental result (4/5)
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%
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 22
Experimental result (5/5)
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
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 23
OUTLINE
OTP core overview Security memory management Experimental approach Experimental results Conclusion & future work
LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 24
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