This document discusses hardware security and side channel attacks. It introduces side channel analysis techniques like differential power analysis and fault injection attacks. It explains how an attacker can use power traces or faults to deduce secret keys by forming hypotheses about intermediate values. Countermeasures are discussed like random delays, double checking results, and protecting code flow integrity. Developers are advised to get their systems tested since side channel vulnerabilities can be subtle.
9. A different threat model But we also need to Beware of leakage Protect run-time integrity Common paradigm Do not trust input Preserve confidentiality and integrity in output Local: at input / output Pervasive: throughout code Code Code ▼
10. Side channel attacks Passive (SCA): Read ‘hidden’ signals timing power consumption electromagnetic emission Active (FI): Signal injection power glitches electromagnetic pulses 10
46. Fault Injection Chip/Hardware operating conditions Temperature Frequency Power supply (input voltage) Localized energy increase (Laser, EM, others?) Fault injection modifies operating conditions Bring chip outside normal situation to make it fail
51. Differential Fault Analysis Correct result Correct result Correct result Correct result DFA Faulty result Faulty result Faulty result Faulty result
52. RSA and RSA-CRT RSA works with modular exponentiations RSA-CRT splits big exponentiation in two smaller ones S = Md(mod n) dp = d mod (p-1) dq = d mod (q-1) K = p-1 mod q Sp = Mdp mod p Sq = Mdq mod q S = ( ( (Sq - Sp)*K ) mod q ) * p + Sp
53. Bellcore attack on RSA-CRT Suppose single fault into one exponentiation Now, subtract S’ from S Now take gcd(s-s’,n) gcd(x*p,p*q) = p Compute q=n/p and you’re done! An attack variant exists that only requires S’ and M S’ = ( ( (S’q - Sp)*K ) mod q ) * p + Sp S - S’ = (((Sq - Sp)*K) mod q)*p - (((S’q - Sp)*K) mod q)*p = (x1-x2)*p mod N
55. Agenda Protecting your device Tips for developers Side Channel Analysis Conclusion Perturbation Attacks Introduction: Secure hardware and attacks
56. SCA Countermeasures Application level NEVER brew your own crypto Introduce random delays between critical functions Avoid branches related to secret data See helpful patterns in reference [1] Operating System level Masking and hiding countermeasures. See e.g. [2],[3] Have your systems tested Side channel vulnerabilities can be very subtle!
57. Fault Injection countermeasures Double check critical results Encrypt-Decrypt-Compare Two comparisons in authentication checks Add a random wait between the two checks Protect code flow integrity Introduce ‘shadow program counters’ Never output wrong results Most DFA attacks are based on this! See more at [1]
58. Protecting your device Tips for developers Side Channel Analysis Perturbation Attacks Introduction: Secure hardware and attacks Conclusion Agenda
59. Conclusion Devices under attacker’s control Physical threats need to be considered Complete protection very difficult Countermeasures based on increasing attack effort Side channel problems are difficult to spot Compiler and hardware behavior could break your code! Impossible to know without testing
61. References [1] Secure Application Programming in the Presence of Side Channel Attacks – Download link [2] Power Analysis Attacks – http://www.dpabook.org [3] Cryptography Research Inc. – DPA Countermeasures [4] Riscure – Publications [5] E. Bhiam, A.Shamir – Differential Fault Analysis of Secret Key Cryptosystems