Protecting cryptography code from timing vulnerabilities
summary
Shows a concrete string-compare leak exploited by measuring tiny timing differences across many requests and even from co‑resident EC2 VMs, demonstrates attacks that recover API keys byte‑by‑byte, and quantifies which microarchitectural channels matter (cache, memory bandwidth, scheduler effects). Presents a coding style that enforces constant‑time control flow and avoids secret-dependent memory accesses, warns that a compiler reintroduces branch optimizations, and points to AddressTimingShield as a practical mitigation.
AI-written summary · about
chapters (18)
- 0:00Start
- 0:39Can you see the vulnerability?
- 3:00Exploitation
- 4:06Can timing differences be measured?
- 5:01sleep(random_int)
- 5:32Modern computers multitask
- 6:52Causes of interference patterns
- 7:57Will this get fixed in hardware?
- 8:43Identify secret values
- 9:26no secret control flow
- 9:59no secret memory locations
- 10:14avoid variable-time ops
- 10:39An example (before)
- 11:09An example (after)
- 11:33But sadly, compilers.
- 12:12How do we fix this?
- 12:59rust-timing-shield
- 13:24Summary
related talks
50mTime Trial: Racing Towards Practical Timing Attacks
35mShowTime: CPU Timing Attacks With the Human Eye
01h 01mTutorial: Side-Channel Attacks and Transient Execution Vulnerab...
30mAll in the timing: How side channel attacks work
41mHand Me Your SECRET, MCU! Microarchitectural Timing Attacks on Microcontrollers are Practical
01h 02mCryptographic Side-Channels on Embedded Devices
14mCollapsing Towers for Side-Channel Security
13mExposing Cache Timing Side-Channel Leaks through Out-of-Order Symbolic Execution