LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 2008 Memory Security Management for FPGA-based Embedded system Romain Vaslin, Guy Gogniat, Jean-Philippe Diguet Lab-STICC CRNS UMR 3192 – UBS Lorient, France Russell Tessier, Deepak Unnikrishnan Reconfigurable Computing Group, UMass Amherst, USA

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 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 OUTLINE OTP core overview Security memory management Experimental approach Experimental results Conclusion & future work

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI OUTLINE OTP core overview Security memory management Experimental approach Experimental results Conclusion & future work

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 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 OTP core principle

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 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 xorcrc xor crc xorcrc xorcrc xorcrc xorcrc xorcrc Data request (c) Memory answer OTP generation (AES) xorcrcxorcrc Data 5-8 d2 d3 d4 d5 d6 d7 d8 crc d1 Data 1-4 OTP core latency

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI OTP core overview (3/4) OTP core architecture – Write request TRUSTED ZONEUNTRUSTED ZONE OTP CORE : Write request of a cache line AES core Data cache Instruction cache Processor core External memory Time Stamp computation Time Stamp memory Padding value AES key AES inputAES output of Cache line AES core Ciphered cache line Clear cache line CRC generator CRC memory Original OTP coreExtended OTP core

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI OTP core overview (4/4) External memory TRUSTED ZONEUNTRUSTED of Cache line Processor core OTP CORE : Read request of a cache line Instruction cache Data cache Time Stamp memory Padding value AES key AES input AES output AES core XOR Time Stamp computation Clear cache line Ciphered cache line CRC generator CRC memory validation = ? Original OTP coreExtended OTP core OTP core architecture – Read request

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI OUTLINE OTP core overview Security memory management Experimental approach Experimental results Conclusion & future work

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 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 Security memory management (2/4) External memory TRUSTED ZONEUNTRUSTED of Cache line Processor core OTP CORE : Read request of a cache line Instruction cache Data cache Time Stamp memory Padding value AES key AES inputAES output AES core XOR Time Stamp computation Clear cache line Ciphered cache line CRC generator CRC memory validation = ? Original OTP coreExtended OTP core Address filtering Data filtering

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI Security memory management (3/4) TRUSTED ZONEUNTRUSTED ZONE OTP CORE : Write request of a cache line AES core Data cache Instruction cache Processor core External memory Time Stamp computation Time Stamp memory Task ID AES key AES inputAES of Cache line AES core Ciphered cache line Clear cache line CRC generator CRC memory XOR = ? validation Core control Security Memory Mapping Architecture – Write request

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI Security memory management (4/4) External memory TRUSTED ZONEUNTRUSTED of Cache line Processor core OTP CORE : Read request of a cache line Instruction cache Data cache Time Stamp memory Task ID AES key AES inputAES output AES core Time Stamp computation Clear cache line Ciphered cache line CRC generator CRC memory validation = ? Core control Security Memory Mapping = ? Core control validation XOR Architecture – Read request

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI OUTLINE OTP core overview Security memory management Experimental approach Experimental results Conclusion & future work

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 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 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.TasksMem Segs. Total mem (kB) Code / Data Image VOD Comm Hash Applications partitioning Confidentiality & integrityConfidentialityNo protection Appcodedatacodedatacodedata kBTS TS TS TS TS TS Image VOD Comm Hash

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI OUTLINE OTP core overview Security memory management Experimental approach Experimental results Conclusion & future work

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI Experimental result (1/5) Programmable security applied has a direct impact on the size of the design Area overhead Uniform protectionProgrammable protection NIOS II + HSCHSCNIOS II + HSCHSC ALUTsFFsALUTsFFsALUTsFFsALUTsFFs Image VOD Comm Hash ~65 % for UP, ~70% for PP ~50 % for UP, ~45% for PP Area overhead

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI %13.75 % Experimental result (2/5) Software performances losses compared with NP Performances No Protection Uniform ProtectionProgrammable Protection (ms) Image % % Image 2k % % VOD % % VOD 2k % % Comm % % Comm 2k %24.6-8% Hash %5.3-15% Hash 2k %3.7-14% %8.75%

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 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) % VOD (kB) % Comm (kB) % Hash (kB) % TS data CRC data CRC code kbytes 43.2

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI Experimental result (4/5) Energy consumption 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 Experimental result (5/5) 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 OUTLINE OTP core overview Security memory management Experimental approach Experimental results Conclusion & future work

LAB-STICC CNRS UMR 3192 – UBS – ROMAIN VASLIN – CRYPTARCHI 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