Fault injections & Defensive Coding

1. Erik Poll Digital Security, Radboud University Nijmegen Fault injections &Defensive Coding

2. Recap: attack characteristics Recall different characteristics of attacks: • logical vs physical • passive vs active • invasive vs non-invasive

3. Classification of attacks • Logical • Physical • Mixture of logical and physical using a side channel during execution • passively – side channel attacks • eg. timing, power, SPA, DPA, ... • actively – fault injections Mess with environmental conditions to induce fault in execution (clock frequency, voltage, temperature....) May require depackaging, but is not always tamper-evident (eg glitching)

4. Fault injections • Card Tears • Physical • putting a 0 or 1 on a databus line • Glitching (late 1990s) • dipping voltage of power supply • affects EEPROM & ROM • manipulates read to result in 00 or FF; but after descrambling this can result in arbitrary data • difficult to do nowadays; but skipping instructions on a Java Card VM seems possible... • Light manipulations (early 2000s) • light flash on chip surface affects its behaviour

5. laser attacks laser mounted on microscope with x-y table to move the card and equipment to trigger timing

6. Fault injections: practical complications Many parameters for the attacker to play with • when to do a card tear • when glitch, for how long • when & where (x and y dimension) to shoot a laser, for how long, how strong, and which colour? • Multiple faults? Multiple glitches are possible, multiple laser attacks harder This can make fault attacks a hit-and-miss process for the attacker (and security evaluator).

7. Fault injections: targets • Attacks can be on data or on code • including data and functionality of the CPU, eg the program counter (PC) • Code manipulation may • turn instruction into nop • skip instructions • skip(conditional) jumps • Data manipulation may result in • special values:0x00 or 0xFF • just random values

8. Fault injections: targets Fault attacks can target • crypto some crypto-algorithms are sensitive to bit flips; the classic example is RSA • any other functionality any security-sensitive part of the code or data can be targetted Passive side channel analysis typically targets the crypto Active fault injections can target any functionality The smartcard platform (hardware, libraries, and VM) can takes care of some of this, but every programmer my have to ensure this for each program separately

9. Light manipulation Targets: • memory • targetting RAM: change content or decoding logic to change read out • targetting EEPROM: difficult & not tried • glue logic & CPU • unpredictable results • countermeasures • to disable them

10. Countermeasures? Physical countermeasures • Prevention – make it hard to attack a card • Detection: include a detector that can notice an attack • eg a detector for light or dips in power supply This starts another arms race: attackers use another fault attack on such detectors Popular example: glitch a card and simultaneously use a laser to disable the glitch detector! Logical countermeasures • program defensively to not leak info or resist faults • for JavaCard, this can be at the platform or applet level

11. Example sensitive code class OwnerPIN{ boolean validated = false; short tryCounter = 3; byte[] pin; boolean check (byte[] guess) { validated = false; if (tryCounter != 0) { if arrayCompare(pin, 0, guess, 0, 4) { validated = true; tryCounter = 3;} else {tryCounter--; ISOException.throwIt(WRONG_PIN); } else ISOException.throwIt(PIN_BLOCKED); }

12. Defensive coding for OwnerPIN • checking & resetting PIN try counter in a safe order • to defeat card tear attacks • validated should be a transient boolean array • ensuring automatic reset to false • does timing of arraycompareleak how many digits of the PIN code we got right? • read the JavaDocs for arraycompare !

13. Getting more paranoid • checking for illegal values of tryCounter • eg negative values or greater than 3 • redundancy in data type representation • eg record tryCounter*13 or use an error-detecting/correcting code • changing order of tests • thinking of how this looks in bytecode • keeping two copies of tryCounter • even better?: keep one of these copies in RAM • initialised on applet selection attacker must attack both RAM & EEPROM synchronously • doing security sensitive checks twice

14. if (pinOK) { // allow acces ... } else { // error handling ... }

15. Better if (!pinOK) { // error handling ... } else { // allow access ... } Better to branch (conditionally jump) to the "good" (ie "dangerous") case if faults can get the card to skip instructions

16. Even more paranoid if (!pinOK) { // error handling ... } else { if (pinOK) { ... } else { // We are under attack! // Start erasing keys .... }

17. Defensive coding tricks • avoiding use of special values such as 00 and FF • don't use JavaCard booleans! • use restricted domains and check against them • ideally, domains that exclude 00 and FF, and elements with equal Hamming weights • introduce redundancy • when storing data and/or performing computations • forcing attacker to synchronise attacks or combine different attacks (eg on EEPROM and RAM) • jump to good (ie dangerous) cases • make sure code executes in constant time

18. Defensive coding tricks • additional integrity checks on execution trace • doing the same computation twice & checking results • for asymmetric crypto: use the cheap operation to check validity of the expensive one • check control flow integrity • add ad-hoc trip-wires & flags in the code to confirm integrity of the run eg set bits of a boolean at various points in the code, and check in the end if all are set People have proposed beginSensitive() and endSensitive() API call to turn on VM countermeasures

19. Defensive coding tricks • store sensitive data asjavacard.security.Keys • presumable the (native) implementation of this class uses (hardware-specific?) measures to protect integrity & confidentiality of these objects • a Key can also be read or written as byte array, so we can store a byte array as a Key More generally: API implementation must be tuned to hardware vulnerabilities

20. Coding trick to remove timing sensitivity • Instead of if (b) then { x = e} else {x = e';} do a[0]= e; a[1]= e'; x = b ? a[0] : a[1]; to remove timing sensitivity • at expense of efficiency, obviously..

21. When/What to code defensively • first step: decide • which data • which parts of the execution are sensitive and should be protected

22. Code reviewing? • How do do a code analysis – with automated tool or manual code review - to check the resistance against fault attacks? • look for security critical operations and branches, to see if eg no dangerous instructions can be reached by attacking a single branch ?

23. Performance Optimalisation

24. JavaCard performance optimalisation tricks • reuse pre-allocated object • as done for Exceptions • don't access EEPROM several times • store result in RAM variable • inline methods • trading program size for speed • it's a stack machine – use the stack! • use local variables to cache values • operate on the first (4) local variables when possible • in general, switch is faster & uses less memory than if-then else • obviously, defensive coding conflicts with performance

25. Conclusion

26. Conclusion: side channels • Any physical device has side channels • which leak info and can be use to introduce faults • We not just have to implement the right security, but we also have to implement the right security securely and even implement all functionality securely Implementations that are functionally indistinguishable, may be very different when it comes to security against passive or active side channels. • Technology for fault attacks improving: • eg when will two synchronised laser faults be feasible? In same or different spots? • Countermeasures may be at the level of hardware, the platform & APIs, and the application code

27. Security by Obscurity rules! • Knowing the code of an implementation, or the layout of data in memory, really helps an attacker with fault attack Obscurity makes the life of the attacker harder! Keep your code secret! • DPA has been used to leak the code of a Java Card, • the power signal betrays which bytecode is instructed; a single bytecode instruction takes many machine instructions

28. Your project code • For your projects, you do not have to do any defensively programming to withstand faults • except that you have to resist card tears • You do not have to add your own checks for integrity of important data; here we can simply trust the card