June 15, 2010
new attacks on AES
Last year, a spate of attacks on AES caused the shine to come off. Vincent Rijmen, one of the designers, has now announced an attack on AES that reduces the key strength from 128 bits to 32 bits.
Ouch! But there's a catch:
This attack clearly endangers all practical applications where an attacker can halt the computer in the middle of the execution of an encryption routine , apply the specific difference δ to the state, and roll back the interrupted encryption and obtain the modified plaintext p*.
Which is to say, the attacker must have something else. He must be able to stop the encryption, inject some different values, and then restart it.
Is this a worry? Well, no. If the attacker has that ability -- stop, inject, restart -- then the attacker probably has lots of other powers too. Yes, in that the result seems to again undermine the strength of the algorithm. As they say in cryptoland, the attacks only get better.
In sum, I wouldn't be too worried. If this attack breaks you, then you've got another problem: can't be too careful about those environmental factors! But we might start to think about the replacement of AES somewhat sooner than expected (e.g., last year, Bruce Schneier suggested simply increasing the rounds of AES128 from 10 to 16) and whether we need to incorporate specific environmental defences in the next design competition.
As more information comes in, especially analysis by real cryptographers rather than cryptography realists, I'll update the post. Hat tip to Alfonso De Gregorio who spotted it and added his own variant.
Posted by iang at June 15, 2010 01:33 AM
One of the acceptance criteria for an AES candidate cipher was that it would be efficient enough for use in "small computers", i.e. smart cards.
And smart cards are in principle vulnerable to these kind of attacks, like perturbation attacks and differential fault analysis.
As payment card technology is moving away from the passive magstripe to active smart cards, this is a relevant development to say the least.
But, experienced smart card developers do have a bag of very effective tricks to counter aforementioned types of attack. And smart card developers know now which kind of trick they have to use when implementing rijmdael on a smart card.
Right, I guess the smart card people are different, because they are keen enough to dig deeply, and do not use AES just because NIST said it was good. Typically, smart card designers design their own protocols, and choose their own algorithms. And often they are really tweaking things for performance.
And, as you said, they've been doing things like environmental probing for a long time, far longer than anyone else.
The "catch" is usually called a fault attack, isn't it ?
The problem with the general perception of "fault injection attacks" is that you need to have direct access at the hardware to inject the fault, you don't.
Back in the 1980's I was showing not only that you could inject a fault without contact via RF carrier but you could also use it to read information out of a target device to look for "signitures" by which you could time your injection point.
Here we are a quater of a century later and the accademic community is just starting to pick up on it...
Some bods over at the CambLabsUK showed how they reduced the number of bits of entropy from a True Random Number Generator (TRNG) from 32bits to ~8bits with no dificulty.
This was with an unmodulated RF carrier as I pointed out to them you can not only modulate the carrier with your fault injection signiture, but by using different RF carrier frequencies you can to a certain extent be selective about what point you inject the fault (via resonance / antiresonance).
The equipment needed to do this can usually be picked up for peanuts at Amateur Radio Conventions (which is where I got the bits to build my rig).
However it is not just for "injecting" faults, by being able to reduce the carrier power to a low level a strange effect happens to the unmodulted carrier as it passess through the active circuitry, due to the process of cross modulation the electronics modulate the carrier with information that can be used in many ways. One of which is to identify the point of execution of the target CPU code to actualy inject a none random fault...
Oh and don't assume metal shielding will help you can usually find a frequency that gets through any ventalation slots etc (10GHz being one of my favorites.
So yes I suspect that some systems will be vulnerable to RF Fault Injection...