Cache-Timing Attacks Matteo BOCCHI System Research & - PowerPoint PPT Presentation

Cache-Timing Attacks Matteo BOCCHI System Research & Applications STMicroelectronics S.r.l. 2018/12/06

Agenda 2 • STM32 • Nucleo Boards • STM32 Firewall • Cache-Timing Attack • Evict&Time vs. MbedTLS AES on STM32 • Flush+Reload vs. OpenSSL AES on PC

TM STM32: 32-bit Cortex -M MCUs 3 High-performance • Low-power Mainstream • Cost sensitive • Advanced peripherals Ultra-low-power • Software libraries • Rich choice of tools Wireless Cortex-M0 Cortex-M4 Cortex-M3 Cortex-M7 Cortex-M0+ Note : Cortex-M0+ Radio Co-processor

STM32 Nucleo Development Board 4 Flexible board power supply • Based on STM32 through USB or external source microprocessors Integrated Debugging and programming probe • A Boards with 1 MCU and hardware to Arduino UNO extension connectors easy access to add- program/debug ons (*) STM32 Microcontroller • Two connectors to Morpho extension headers: connect to companion Direct access to all STM32 I/Os chips boards • For all STM32 families complete product range from ultra-low power to high-performance (*) thanks to the electrical compatibility it can be used as a shield for Arduino UNO R3 or similar

6 STM32 Firewall

Firewall Overview 8 • HW peripheral that protects code and sensitive data, monitoring each access from the AHB masters to the Flash memory or SRAM1 AHB slaves CORTEX- DMA M4 • Code in Flash memory or SRAM1 • Constant data in Flash memory • Volatile data in SRAM1 AHB BUS MATRIX Application benefits FIREWALL • Protects the intellectual property of embedded software interacting with OEM code. • Prevents attacks designed to dump/execute Flash protected code outside of a protected area. SRAM1 memory • Protects access to sensitive data from non-protected user code execution.

Firewall: Run Time Protection 9 Unprotected Code Example Code Execution Call Gate TRUSTED Entry EXECUTION Protected Code FIREWALL FIREWALL FIREWALL FIREWALL Execution IDLE CLOSED OPEN CLOSED NO CALL GATE EXIT GATE Execution Complete? YES Clear Intermediate Variables and CPU registers Closed Open Call Gate Exit Unprotected Idle Code

Secure Computations with Firewall 11 • With the firewall, we can build secure computation elements • They compute encryptions/decryptions using secrets not accessible to other entities • They expose API to perform cryptographic/security services • They get inputs and return outputs, without leaking any secret information • For example: • Trusted Execution Environment services • Secure Boot / Secure Firmware Update • Secure transmission protocols

12 Evict&Time vs. MbedTLS AES on STM32

AES 13 • This cipher is abstractly defined by algebraic operations: it could be implemented using just logical and arithmetic operations • Performance-oriented software implementations typically have precomputed lookup tables (hardcoded) or compute them during system initialization • Thus, during each round, only XOR and memory table lookup are computed:

Attack core idea 14 • At the beginning of the AES computation, the variable-index array lookup 𝑈[𝑙 𝑘 ⊕ 𝑜 𝑘 ] is done ( 𝑙  key, 𝑜  plaintext) • The attacker: watches the time taken by the victim to handle many 𝑜 's • totals the AES timings for each possible 𝑜 𝑗 , for each 𝑗 • For each 𝑗 , collects values of 𝑜 𝑗 for which the timing is maximum (e.g. for 𝑗 = 13 , the encryption is • slower when 𝑜 13 = 147) • The attacker observes, by carrying out experiments with known keys 𝑙 on an identical machine, that the overall AES time is maximum when 𝑙 13 ⊕ 𝑜 13 = 8 • The attacker concludes that: 𝑙 13 ⊕ 𝑜 13 ⊕ 𝑜 13 = 8 ⊕ 𝑜 13 𝑙 13 ⊕ 𝑜 13 ⊕ 𝑜 13 = 8 ⊕ 147 𝑙 13 = 8 ⊕ 147 𝑙 13 = 155

Demo 15 NUCLEO-L476RG SERIAL PORT TERMINAL 115.200 bit/s 8-N-1

16 Flush+Reload vs. OpenSSL AES on PC

Flush+Reload (1/2) 17 • There is an attacker who wants to steal secret information of the victim • The attacker runs a spy process on the same physical machine of the victim Last-Level-Cache: The attacker: 1. Clears (flush) a specific cache section Launches/observes victim’s process 2. 3. Checks new cache status, measuring time to access those memory addresses

Flush+Reload (2/2) 18 • Allow attack’s & victim’s processes to be on different cores • They share the LLC (Last-Level-Cache) • The spy process can be executed simultaneously to get cache-information step-by- step (if the victim’s process is long and complex) • Needs an accurate (but feasible) work of synchronization between the two processes and some observations more • Several cross-VM attacks exploit this mechanism

Flush+Reload vs. OpenSSL AES 19 1. Empty the cache (flush) Launch victim’s process 2. Victim’s OpenSSL - based “secure” service • AES-128-ECB 3. Check new cache status • Unknown key Attacker’s code flush (probe[ i ]); 1 • 4x1024 (ENC) + 4x1024 (DEC) service_encrypt(plaintext, ciphertext, Bytes Look-Up Tables Sbox 2 service_ctx); size_t time = rdtsc (); maccess (probe[ i ]); size_t delta = rdtsc () - time; 3 if (delta > MIN_CACHE_MISS_CYCLES) { /* cache miss */ }

Exercise 20 flush_reload_RELEASE.tar.gz • attack/ /* attacker’s and victim’s source code */ • openssl-1.1.0f.tar.gz /* OpenSSL source code */ • README.md /* Step-by-step HowTo */

Why the attack (hopefully) works? 21 • main():92 – The attacker’s process maps in his memory the crypto library (public) used by the victim • main():122(146,168,190) – For each of the 4 Sbox encryption tables, it performs Flush+Reload attacks flushing the portion of cache used by a certain table • Usually unknown  before the Flush+Reload, perform a Prime+Probe attack on the whole cache in order to identify them • main():220 – it selects the most probable key bytes candidates by selecting bytes values who caused shorter timings • Probably, they are values loaded in cache by the victim’s process • main():224 – it starts an algorithm to recover the AES master key from the “guessed” AES last-round key

Countermeasures 22 • Avoiding memory access, e.g. bitslice implementations • Avoid cache miss • Lookup tables masking • HW AES Instructions

The END 23 Thanks! Any questions? Contact: matteo.bocchi@st.com