e-Smart, day 1. The title of the talk by ST’s Christophe Tremlet was very appealing [Tre06]; the talk was interesting, but a bit under my expectations (the problem is not completely solved). Nevertheless, Christophe gave a very nice and interesting presentation of fault induction attacks, showing the different parameters that can be acted upon at the different stages:
- Source. The protection at this level is to use sensors, which are always limited in their accuracy.
- Silicon fault. Apparently, this is inherent to silicon, so we’ll have to deal with that as long as we use silicon
- Functional fault. The consequence of the silicon fault is that the chip gets in to an unexpected faulty state, which can in some cases trigger a functional fault: the chip does not behave as expected.
- Fault exploitation. This is the last part of the attack. Not all faults are exploitable, but in some cases, a test result will be flipped, a value will be modified. If it is predictible, it can be exploited.
The issue is of course to design countermeasures. At the source level, sensors have been around for a long time, but they can only detect a finite number of perturbations, which leaves a lot of room for attackers.
In fact, the typical countermeasure against perturbations is redundancy. We have been recommending it for a long time at the software level, for instance integrity checks. The main idea in this presentation is to introduce redundancy at the hardware level. It can be applied by doubling critical logic and checking consistency, by implementing a state machine that verifies that only appropriate transitions are allowed, or by adding integrity checks on memory operations. It is even possible to check sequences of code.
According to Christophe Tremlet, these countermeasure have a cost, but they are efficient, in particular if they are combined with software countermeasures. Hopefully, these hardware techniques will make their way in production chips soon, and they will ease the pressure on software developers.
No Comments