Posts Tagged ‘AES’

Bringing Access-Based Cache Attacks on AES to Practice

Thursday, November 25th, 2010

Personal computers are mostly used by a single person or shared between a group of users that trust each other, in cloud computing users usually do not trust each other: the owner of one process may have a great interest in the encryption keys used by a process owned by another user. Since the OS provides separate address space for each process, it may seem that the attacker has no way to steal the key. Turns out the attack may be practical.

To understand how the attack works we need to recall how memory is accessed by a program: Before requesting data from a memory chip, processor checks whether the data was recently accessed and saved in the cache. If the data is in the local cache, it can be accessed hundred times faster than otherwise. To make the implementation easier, the cache is designed in such a way that each memory location is allowed to be cached only in few places: to check that a memory location is cached, only these few places need to be checked.

Software implementations of the AES cipher commonly employ a look-up table. Which places in this table are accessed depends on which data is encrypted and which key is used. If an attacker, by accessing memory in his address space and checking how long it takes, can deduce what parts of the look-up table were accessed, he may deduce the key.

Cache-based side-channel attacks (SCA) against AES are known for a long time, what is new is the practicality of the attack:

[Our] spy process neither needs to learn the plain- or ciphertexts involved, nor their probability distributions in order [to] recover the secret key.

We describe how besides the key also the plaintext can be recovered without knowing the ciphertexts at all

We have a fully working implementation of our attack techniques against the 128-bit AES implementation of OpenSSL 0.9.8n on Linux. It is highly efficient and is able to recover keys in realtime. More precisely, it consists of two phases: in an [observation] phase, which lasts about 2.8 seconds on our test machine, about 100 encryptions have to be monitored. Then, an offline analysis phase, lasting about 3 minutes recovers the key.

Usually, implementing a counter-measure for SCA makes implementation slower, fortunately, the new processors give us a good way to prevent the attack and improve the performance simultaneously: AES Instruction Set (an extension to the x86 instruction set architecture for microprocessors from Intel and AMD) is already used by many software packages.

No Comments

Attacks always get better; they never get worse – National Security Agency (NSA)

Monday, May 17th, 2010

In this note the authors present the first attack with feasible complexity on the 13-round AES-256. The attack runs in the related-subkey scenario with four related keys, in 2^{76} time, data, and memory.

It is still far from a really practical attack on the full cipher, but once again shows that proper cryptographic hygiene should be used, that is the keys must be derived with a proper key derivation function (KDF) and not by “xoring with a constant”.

While speaking about cryptographic hygiene, let me remind everyone that the CBC mode of operation requires random IV (and random does not mean the previous one plus 1).

No Comments

Low Voltage Fault Attacks to AES and RSA on General Purpose Processors

Tuesday, March 9th, 2010

It is well known that if a secret processed by a device can be correlated with side-effects of the calculation, then the secret can be deduced by measuring these side-effects. Such attacks were used back in time of mechanical rotary encryption machines.

Modern electronic cryptographic devices in addition to the acoustic side-channel of their mechanical predecessors, leak information by means of variation of their power consumption and electro-magnetic radiation. Aside from passively analyzing side-effects of cryptographic computations, an attacker can also actively subvert the environment to introduce faults into the computation. This approach is known as a “fault attack”.

Although the side-channel attacks on a general purpose CPU (especially, timing attacks) were known for a long time, the fault attacks were limited to very small devices, primarily, smart cards.

Recently, a team of researchers from Italy http://eprint.iacr.org/2010/130 presented a fault injection attack against cryptographic software run on an ARM9 general purpose CPU.

Fault injection attacks have proven in recent times a powerful tool to exploit implementative weaknesses of robust cryptographic algorithms. A number of different techniques aimed at disturbing the computation of a cryptographic primitive have been devised, and have been successfully employed to leak secret information inferring it from the erroneous results. In particular, many of these techniques involve directly tampering with the computing device to alter the content of the embedded memory, e.g. through irradiating it with laser beams.

In this contribution we present a low-cost, non-invasive and effective technique to inject faults in an ARM9 general purpose CPU through lowering its feeding voltage. This is the first result available in fault attacks literature to attack a software implementation of a cryptosystem running on a full fledged CPU with a complete operating system. The platform under consideration (an ARM9 CPU running a full Linux 2.6 kernel) is widely used in mobile computing devices such as smartphones, gaming platforms and network appliances.

At first, we validate the effectiveness of the proposed fault model to lead practical attacks to implementations of RSA and AES cryptosystems, using techniques known in open literature. Then we devised two new attack techniques, one for each cryptosystem. The attack to AES is able to retrieve all the round keys regardless both their derivation strategy and the number of rounds. A known ciphertext attack to RSA encryption has been devised: the plaintext is retrieved knowing the result of a correct and a faulty encryption of the same plaintext, and assuming the fault corrupts the public key exponent. Through experimental validation, we show that we can break any AES with roughly 4 kb of ciphertext, RSA encryption with 3 to 5 faults and RSA signature with 1 to 2 faults.

No Comments