2

Fault injections on smartcards or other hardware seem to be an issue for low risk tolerant environments. What are possible countermeasures to fault injections?

From my research, it all depends on what attacker can do. Assuming they can do everything possible on the market, what would be the best measures to counter such attacks?

My ideas are that one could integrate hardware sensors which detect voltage glitches or electromagnetic radiation and for example reset or brick the hardware when attacked.

But what if you cannot modify the hardware?

Software countermeasures I came up with could be that one has to create such "sensors" in the code, which are constantly checking the values if they deliver expected results. Also, the code itself should be without any logical flaws that, in case of a fault, will deliver unexpected results.

What other countermeasures are there?

Molo4
  • 31
  • 1

2 Answers2

1

There are several countermeasures for fault injection. Talking at a general level, as the scope of your question is quite general, and beyond sensors, but the typical countermeasures is duplication.

It can be spatial (duplicating the HW) or temporal (executing two times). Then the results are checked to be consistent before the "output" is released. There are several variants of this approach, for example lockstep.

Another mitigation would be random delays. For fault attacks to work the attacker often needs to know when to fault in order to generate meaningful results for him. Introducing random delays in the computation makes this attack harder.

Of course an attacker who can fault anything in any way he wants would always be able to overcome any countermeasures, but the goal with all countermeasures is to raise the bar above a certain threshold.

Ruggero
  • 7,339
  • 33
  • 42
0

Fault attacks are virtually impossible to stop in commodity hardware because commodity hardware is designed to be cheap. Most non-commodity hardware is often robust to attacks of all sorts, which is why it's relegated to applications without pricing pressure. As a semiconductor engineer, the question is never what is best, but what is the most inexpensive to get the job done because most specifications are designed around the minimally viable VLSI implementation at the time of writing the specification. Detecting voltage glitches, adding sensors, etc, cost money. You could design the LDO in the IC (if it's present, such as NFC/RFID applications) to detect a "brown out" but generally specifications don't include a method on the protocol to report this.

The best thing that can generally be done is to have a consensus of software results through a series of queries with temporal jitter. I know this is one of the things that is done to determine if there's an active attacker on NFC cards because you see if the card responds faster than possible. This could be countered, of course, but putting in a response delay, but until the application or industry decides to throw a few more pennies at the problem, I see this as a cat and mouse game.

b degnan
  • 5,110
  • 1
  • 27
  • 49