Side-Channel Attack Pitfalls

2. Side-Channel Attack Pitfalls Kris Tiri

3. Side-Channels • Information leakage from implementation • Example: safecracker feels tumblers impactingand opens lock without trying each combination • Similarly: hacker observes time/power and cracks cipher without trying each key • Device in normal operation, no physical harm • Covert channel without conspiracy/consent

4. unknown secret key device measurement analysis input 7 2 0 8 4 0 2 7 2 3 3 6 7 1 2 8 7 53 1 8 2 6 5 5 2 3 model estimation P = S-1(KGC)E = HmW(P) key fragment guess Side-Channel Attacks in a Nutshell e.g. estimated power =number of changing bitscan be lousy model AES: 128-bit secret keybrute force impossible P = S-1(KGC) E = HmW(P) compare both and choose key guess with best match e.g. guess 8 bitsbrute force easy

5. Power Analysis Example • Unprotected ASIC AESwith 128-bit datapath, key scheduling • Measurement: Ipeakin round 11 • Estimation: HamDistance of 8 internal bits • Comparison: correlation • Key bits easily found despite algorithmic noise • 128-bit key under 3 min. ‘start encryption’-signal clock cycle of interest supply current

6. New Design Dimension • Mitigations conflict with common design goals • Resistance analysis, precise mitigation cost not always well understood • Design trade-offs difficult to make power performance area side-channelmitigation

7. Side-Channel Pitfalls • Resource sharing • Reduces HW to implement certain functionality • Results in interaction and competition • Create + facilitate observation side-channel info • Optimization features • Improves a system’s performance/cost • Typical case optimized, corner case leaks info • Create side-channel info • Increased visibility/functionality • Provides more information or introduces new interactions • Facilitate observation side-channel info

8. Example using Cache Attacks • Resource sharing Cache accesses observed by spy process evicting cached data of crypto • Optimization features Cache implemented to overcome latency penalty • Increased visibility Performance counters provide accurate picture CPU Fast Slow MEMORY CACHE

9. Side-Channel Classification • Simple attacks • e.g. textbook square-and-multiply RSA algorithm • Number of measurements, not simplicity attack • Requires precise knowledge of implementation and effect on measurement sample • Relatively easy to protect from • Differential attacks • Many observations • Statistical techniques • Leakage channel • Timing, power / EMA

10. Mitigation Strategies • Timing attacks • Typically target variable instruction flow main focus on public key ciphers • Exponent and base blinding prevent multiple measurements of same operation on different data • Power Attacks / EMA • Typically target data dependent power variations main focus on symmetric key ciphers • Randomize / equalize power consumption to increase the number of measurements

11. Randomize ( noise!) Decorrelate power from state signal=statemask Algorithmic masking, logic level Problems: glitches, early propagation, higher order attack, templates Equalize Same power for every transition Dual rail precharge logic Problems: early propagation, capacitance mismatch Main Challenge: Power Analysis

12. Same experiment Automated design flow WDDL: single switching event per clock cycle Differential routing:constant load capacitance Security is not for free mitigatedcore clock cycle of interest Equalizing Mitigation Example ‘start encryption’-signal supply current

13. Opportunities (Pitfalls?) for Research • Mitigations do not come cheap • Randomization: factor 1.5 • Equalization: factor 3 • (Mitigations)2 push envelop • Improvements: partitioning, custom logic • Optimize current state-of-the-art, develop breakthrough mitigation? • Communicate full cost • e.g. mask distribution, random mask generator

14. Visual inspection, standard deviation no figure of merit for mitigation strength Easily distinguish quality of implementation from adversary strength? Expression based on design parameters (activity factor, power profile, etc…)? New Mitigations?

15. Design Time Resistance Assessment • Resistance cannot be added as afterthought • Few automatic design flows proposed • Quality only as good as power simulation • Glitches, early propagation enable attacks • Control arrival times on 20K+ signals? • Proper simulation model to correctly (yet quickly) evaluate design? • Minor differences have a big influence • Process variations in deep submicron technology?

16. Balanced Interconnect capacitances • Crucial for ALL dual rail circuit mitigations to succeed • e.g. differential routing • Cross-coupling? • Process variations in deep submicron technology?

17. Conclusions • Mathematical complexity circumvented with information leaking from HW/SW • Pitfalls that create, facilitate observation • Mitigations generally challenging and costly • Opportunities for future research