Challenge: Analysis for fault induction

One of the most common attacks used on cards these days is fault induction, in which some kind of external means is used to trigger a fault in the execution of an application.

One of the effects that can be obtained is to modify the value that is read by an EEPROM access. For instance, it is possible to make the application believe that a value read from EEPROM is 0. A basic use can be to disable some kind of issue counter:

if (issueCounter>MAX_ISSUES)
  terminateCard();
issueCounter++ ;


There are here two potential attacks, if we consider that issueCounter is a field, because the field is read twice (once for the test, once for the increment). By attacking the test, it is possible to use the application although the counter has gone past the counter. By attacking the second, it is possible to reset the counter to 0, and then to get MAX_ISSUES more tries.

There are many ways to defend against these attacks. The easy way is to make sure that 0 is an invalid value, which will immediately trigger a countermeasure. Another way is include a control value and verify the integrity of the value. This technique is classical, but remains difficult to implement in practice. Here is a basic implementation:

checkIssueCounter() ;
if (issueCounter>MAX_ISSUES)
  terminateCard();
incrementIssueCounter();

This implementation makes the second attack more difficult: in order to modify the written value, there are two write operations to attack, which is more difficult. However, it does nothing about the attack on the test: since the value of the issueCounter field is read again from memory, an attacker can allow the check to work, and then attack the read operation that is performed during the test.

Here, the vulnerability may be quite obvious to a trained eye. However, there are cases in which similar vulnerabilities are very difficult to spot. It would therefore be interesting to have a static analysis that is able to detect the fact that an attack may go undetected. More precisely, the analysis could verify that replacing a sensitive value by 0 systematically triggers an exception. I have looked into it for a little while. The real issue is to analyze the integrity checks, especially when 0 is a valid domain value.

If anybody is interested by this topic or knows about a possible solution, please contact me.

No Comments

Leave a Reply

Your email is never shared.Required fields are marked *