Download as PDF, PPTX
Uploaded byRiscure
Why are we still vulnerable to Side Channel Attacks?
The document discusses the ongoing vulnerabilities to side channel attacks, particularly focusing on RSA cryptography and the methods attackers use to exploit these vulnerabilities through differential fault analysis and power analysis. It highlights various countermeasures that have been developed to combat these attacks, while also acknowledging that advancements in attack techniques continue to evolve. The document underscores the persistent threat posed by side channel attacks, despite efforts to enhance cryptographic security.
More Related Content
Similar to Why are we still vulnerable to Side Channel Attacks?
![Eloi Sanfelix - Hardware security: Side Channel Attacks [RootedCON 2011]](https://cdn.slidesharecdn.com/ss_thumbnails/esanfelix-sidechannelattacks-110307125844-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]](https://cdn.slidesharecdn.com/ss_thumbnails/codedagentsdeck-251215155422-5497c599-thumbnail.jpg?width=640&height=640&fit=bounds)
Why are we still vulnerable to Side Channel Attacks?
- 1. 1 Why are we still Vulnerable to SideChannel Attacks? Marc Witteman 11 February 2010
- 2. Perspectives on theside channel issue Cost Restricted 2 Applications Technology Maturity
- 3. Perspectives on theside channel issue Cost Restricted 3 Applications Technology Maturity
- 4. Cost • Time-to-market • Knowledge •Resource usage (memory, energy) • Performance Example attack performs simple power analysis on RSA Restricted 4
- 5. RSA recap • RSAis based on exponentiation (C = Mk) • Binary exponentiation: – C := 1 – For each key bit ki do: • C := C * C • If ki = 1, then C := M*C • Number operations performed by numerical co-processor (multi-bit) • Algorithm execution is sequence of square and/or multiply operations, e.g. S M S S S M S M S S M ≈ 1 0 0 1 1 0 1
- 6. Time-Power attack onRSA 11 00 00 00 00 00 0011 11 11 Key bits revealed !
- 7. Problem analysis • Problemdiscovered in a card produced in 2004 • Basic countermeasure would do square and always multiply: – C := 1 – For each key bit ki do: • C := C * C • D := M*C • if ki = 1, then C := D • else D := C // dummy statement executed in same time • Algorithm execution is sequence of square and multiply operations: S M S M S M S M S M ≈ ? ? ? ? ? • But that costs time and memory Restricted 7
- 8. Perspectives on theside channel issue Cost Restricted 8 Applications Technology Maturity
- 9. Maturity • Players comeand go – Developers new people re-introduce old errors… – Manufacturers Emerging countries face same challenges… • Countermeasures – ‘Defenders’ solve vulnerabilities – ‘Attackers’ extend and improve exploits • Example: DFA on RSA-CRT, an ongoing battle Restricted 9
- 10. Fault injection mechanisms Theaim of the manipulations is to change a value read from memory to another value •Voltage glitching •Clock glitching •Optical glitching 10
- 11. Differential Fault Analysis •Force computational error in few cryptographic operations • Monitor correct and faulty encryption results • Extract secret key by analysis and comparison of correct and faulty results • Notorious example: RSA in CRT mode: only one faulty message is enough! Input message RSA- CRT signing Corrupt signature Private key Public key Fault injected Mathematical analysis Private key 11
- 12. CRT implementation ofRSA Efficient signing implementation splits exponentiation precompute dp = d mod (p-1) dq = d mod (q-1) K = p-1 mod q exponentiation Sp = M dp mod p Sq = M dq mod q recombination S = ( ( (Sq - Sp)*K ) mod q ) * p + Sp 12
- 13. Bellcore attack: DFAon CRT Inject a fault during CRT that corrupts Sq: S’q is a corrupted result of Sq computation S’ = ( ( (S’q - Sp)*K ) mod q ) * p + Sp Subtract S’ from S : S - S’ = (((Sq - Sp)*K) mod q)*p - (((S’q - Sp)*K) mod q)*p = (x1-x2)*p mod N = x*p mod N compute Gcd( S-S’, n ) = Gcd( x*p, p*q ) = p compute q = n / p RSA-CRT broken when primes known 13
- 14. First defense againstDFA on RSA-CRT • DFA generally requires multiple encryptions of the same text • Crypto-protocols have been (re)designed such that messages are padded with random data before signing • Randomness results in ‘unique’ input for each encryption, and DFA no longer possible • Until a new attack was developed… Restricted 14
- 15. DFA on CRTimprovement • Original BellCore attack requires one good and one faulty signature • Improved single signature attack needs only a faulty signature S - S’ = x*p mod N M = Se mod N = (S’+x*p)e mod N = M - S’e = p*x*k Gcd( M - S’e , n ) = Gcd( p*x*k, p*q ) = p Only message, faulty signature and public key is enough! Single signature DFA attack breaks RSA-CRT again ( ) ( ) ( ) nxpksnxps i e xpsnxps i e eiie e i eiie e i mod'mod''mod' 1 10 += += −− = − = ∑∑ 15
- 16. Second defense againstDFA on RSA-CRT • Single signature DFA on RSA-CRT requires knowledge of plaintext • Crypto-protocols improved by keeping random padding secret • Unknown plaintext renders single signature DFA impossible • Until a new attack is developed… Restricted 16
- 17. Partial input recovery •Lattice is mathematical structure describing relations between sets of vectors • Lattices can be used to find partially unknown data in vector set by solving the Closest Vector Problem • Multiple different partially unknown messages are modeled as a lattice • It is now possible to solve these for limited ‘gaps’ 17
- 18. DFA on RSA-CRTmade possible again? • ‘Bellcore’ attack countered twice by including secret random data in the signature – Message is unique – Message is partially unknown – Key should be protected even when fault injection successful • Partial input recovery can already determine secret data up to 6 bytes • Attack may break many crypto applications without hardware protection against fault injection 18
- 19. Perspectives on theside channel issue Cost Restricted 19 Applications Technology Maturity
- 20. Applications Financial Mobile Communication Identification Access control Secure storage Public transport Smart metering 20 Conditional Access New applications bring •new crypto algorithms • new crypto protocols • new business risks • and… new attacks
- 21. Which algorithms, whichprotocols? Algorithms • DES • 3DES • RSA • AES • DSA • ECDSA • ECNR • HMAC • SEED • COMP128 • … Confidential 21 Protocols • EMV • A3A8 • Milenage • OTA • BAC, EAC • PKCS* • PSS • OAEP • DSS • Proprietary • … DPA attack possible
- 22. ECDSA • private keyd and a public key Q (where Q = d*G) • To sign a message m: • Calculate z = left most bits of HASH(m) • Select a random integer k • Calculate r = x-coordinate of kG • Calculate s = k − 1(z + r*d)(mod n) • The signature is the pair (r,s) Restricted 22 Attack with DPA
- 23. Big Number multiplication Bignumbers multiplication of r and d is split in smaller parts Bytes of r r2 r1 r0 Bytes of d d2 d1 d0 ------------------------------------------------------------------------- * Intermediates r2 * d0 r1 * d0 r0 * d0 Intermediates r2 * d1 r1 * d1 r0 * d1 Intermediates r2 * d2 r1 * d2 r0 * d2 ------------------------------------------------------------------------- + • Parts of private key d are multiplied with known parts of r • Hypothetical values of di can be tested by correlating traces Restricted 23
- 24. 24 Differential Power Analysis •Differential trace proves difference due to processing different data • S/N ratio can be improved by: • Averaging multiple traces before subtraction • Compute correlation with Hamming weight rather than bit value
- 25. Correlation for intermediatevalues • Peaks of correlation traces are sorted for hypothetical di values • Highest peak reveals correct di value • Repeat for all key parts • Key revealed! Restricted 25
- 26. Perspectives on theside channel issue Cost Restricted 26 Applications Technology Maturity
- 27. Technology New inventions mayhelp defenders and/or attackers Example: fast improvement of fault injection tools Restricted 27
- 28. Fault injection opportunitiesin PIN check short pin_check(byte* buffer) { if(pin_ctr > 0) { pin_ctr--; if(array_compare(pin,buffer,4) == 0) { auth = TRUE; // PIN ok pin_ctr = MAX_PIN_CTR; // reset PIN counter return 0x9000; } else { auth = FALSE; // wrong PIN return 0x6985; } } else { auth = FALSE; // no attempts left return 0x6987; }} Change condition Manipulate function Skip instruction Modify assignment Change condition 28
- 29. Countermeasures Protect PIN verificationroutine with • Random delays • Double checking • Traps 29
- 30. PIN check protection Shortpin_check(byte* buffer) { if(pin_ctr > 0) { random_delay(); if(pin_ctr <= 0) suicide(); pin_ctr--; if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check random_delay(); if(array_compare(pin,buffer,4) != 0) suicide(); else { … } // PIN ok } else { … } // PIN not ok at first check Prevent timed glitch 30
- 31. PIN check protection Shortpin_check(byte* buffer) { if(pin_ctr > 0) { random_delay(); if(pin_ctr <= 0) suicide(); pin_ctr--; if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check random_delay(); if(array_compare(pin,buffer,4) != 0) suicide(); else { … } // PIN ok } else { … } // PIN not ok at first check 31 Double check
- 32. PIN check protection Shortpin_check(byte* buffer) { if(pin_ctr > 0) { random_delay(); if(pin_ctr <= 0) suicide(); pin_ctr--; if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check random_delay(); if(array_compare(pin,buffer,4) != 0) suicide(); else { … } // PIN ok } else { … } // PIN not ok at first check trap 32
- 33. PIN check protection Shortpin_check(byte* buffer) { if(pin_ctr > 0) { random_delay(); if(pin_ctr <= 0) suicide(); pin_ctr--; if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check random_delay(); if(array_compare(pin,buffer,4) != 0) suicide(); else { … } // PIN ok } else { … } // PIN not ok at first check Prevent timed glitch 33
- 34. PIN check protection Shortpin_check(byte* buffer) { if(pin_ctr > 0) { random_delay(); if(pin_ctr <= 0) suicide(); pin_ctr--; if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check random_delay(); if(array_compare(pin,buffer,4) != 0) suicide(); else { … } // PIN ok } else { … } // PIN not ok at first check Double check 34
- 35. PIN check protection Shortpin_check(byte* buffer) { if(pin_ctr > 0) { random_delay(); if(pin_ctr <= 0) suicide(); pin_ctr--; if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check random_delay(); if(array_compare(pin,buffer,4) != 0) suicide(); else { … } // PIN ok } else { … } // PIN not ok at first check trap 35
- 36. New fault injectiontools • Dedicated hardware for glitch control precise, fast, repetitive, adaptive • Smart triggering start glitch at pattern recognition • Powerful diode lasers 36
- 37. Glitch control hardware FPGAtechnology used for • arbitrary signal generation • real time interaction with I/O and external triggers • 2 ns precision • drives multiple channels ControlUSB Trigger in LaserContact smart card LCD Display Trigger out Smart card RST Smart card I/O Smart card VCC Smart card CLK Glitch circuit with smart card Glitch generatorCPU+ memory Switch Power monitor mode CLK VCC vcc/clk/laser 37
- 38. Signal behaviour withvariable delays Variable delays stop time based glitch triggers Instruction to hit 38
- 39. Smart triggering, asolution Use signal pattern as trigger source 39
- 40. Smart triggering result Triggermoment is now fixed to device behavior Instruction to hit 40
- 41.
- 42. Glitch speed Diode laserscan switch at high frequency 42
- 43. Real time multiglitching process Short pin_check(byte* buffer) { if(pin_ctr > 0) { random_delay(); if(pin_ctr <= 0) suicide(); pin_ctr--; if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check random_delay(); if(array_compare(pin,buffer,4) != 0) suicide(); else { … } // PIN ok } else { … } // PIN not ok at first check Find end with smart triggering 43
- 44. Real time multiglitching process Short pin_check(byte* buffer) { if(pin_ctr > 0) { random_delay(); if(pin_ctr <= 0) suicide(); pin_ctr--; if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check random_delay(); if(array_compare(pin,buffer,4) != 0) suicide(); else { … } // PIN ok } else { … } // PIN not ok at first check Glitch condition 44
- 45. Real time multiglitching process Short pin_check(byte* buffer) { if(pin_ctr > 0) { random_delay(); if(pin_ctr <= 0) suicide(); pin_ctr--; if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check random_delay(); if(array_compare(pin,buffer,4) != 0) suicide(); else { … } // PIN ok } else { … } // PIN not ok at first check Find begin with smart triggering and force power down 45
- 46. Real time multiglitching process Short pin_check(byte* buffer) { if(pin_ctr > 0) { random_delay(); if(pin_ctr <= 0) suicide(); pin_ctr--; if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check random_delay(); if(array_compare(pin,buffer,4) != 0) suicide(); else { … } // PIN ok } else { … } // PIN not ok at first check Glitch condition 46
- 47. Real time multiglitching process Short pin_check(byte* buffer) { if(pin_ctr > 0) { random_delay(); if(pin_ctr <= 0) suicide(); pin_ctr--; if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check random_delay(); if(array_compare(pin,buffer,4) != 0) suicide(); else { … } // PIN ok } else { … } // PIN not ok at first check Find end with smart triggering 47
- 48. Real time multiglitching process Short pin_check(byte* buffer) { if(pin_ctr > 0) { random_delay(); if(pin_ctr <= 0) suicide(); pin_ctr--; if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check random_delay(); if(array_compare(pin,buffer,4) != 0) suicide(); else { … } // PIN ok } else { … } // PIN not ok at first check Glitch condition 48
- 49. Real time multiglitching process Short pin_check(byte* buffer) { if(pin_ctr > 0) { random_delay(); if(pin_ctr <= 0) suicide(); pin_ctr--; if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check random_delay(); if(array_compare(pin,buffer,4) != 0) suicide(); else { … } // PIN ok } else { … } // PIN not ok at first check Find begin with smart triggering and force power down 49
- 50.
- 51. Conclusion • Side Channelattacks exist for more than a decade • Analysed developments for four perspectives – Cost – Maturity – Applications – Technology • All perspectives show that threat remains • Attacks have become mainstream 51
- 52. 52 Questions & Discussion MarcWitteman witteman@riscure.com Riscure B.V. Frontier Building Delftechpark 49 2628 XJ Delft The Netherlands Phone: +31 (0)15 251 4090 www.riscure.com Thank you