# How would a side channel attack be carried out in a real life situation?

How would a timing attack against AES be carried out in a real situation? You could not guess the key from the processor's power usage after the plaintext is encrypted, right? And what would you need for this scenario? How long would it take? And if side channel leakage is really such a big deal, why is AES still used for the encryption of classified data?

In hardware, most of the implementations for AES are constant time. My experience is that the current is generally too far into the noise floor to get any real data out; however, I've attacked my AES implementation and a commercial hardware implementation as well with success. In any software implementation of AES (or ones that I know), I can HALT the system, and dump the core via JTAG and get the keys.

To do a power attack on system, it helps if you know something about the system, but the math you are looking at on a per transistor basis is

$$I_{f,r} =I_{thn}\ln^2 \left[1+ e^{\left[{\left(\kappa \left(V_g-V_{thn}\right)\right)- \left(V_{s,d}\right)}\right]/\left({2 U_{T}}\right)} \right]$$

$$I_{f,r} =I_{thp}\ln^2 \left[1+ e^{\left[{\left(\kappa \left(V_b -V_g+V_{thp}\right)\right)- \left(V_{b}-V_{s,d}\right)}\right]/\left({2 U_{T}}\right)} \right]$$

for the N and P FETs respectively. This model is called the compact EKV model, and if you push through the Taylor expansion, you'll get the subvt and abovevt currents. Generally, you will see the nFETs to be stronger than the pFETs, which lets you get a feel for what the bit states of the system are. Having said that, on 14nm SOI (this process is wonderful), my pFETs and nFETs are identical, except for a difference in threshold mismatch. If you drive the voltage down to get the systems running in subthreshold and control the clock, you can get a really good picture of the circuits. Once you know the circuits, you can then get the keys.

I use a Keithley 2000 DMM and Keithley 6485 picoammeter that are controlled through MATLAB and I can pretty much get anything I want out of the little black boxes. (I also have a copper box to isolate noise)

Well, for example you could have 'encrypted' data normally being sent from a client to a server and the server had a list of known 'pre-shared-keys' for all its clients. Then one day someone comes along and sends it a random buffer. The server goes through its list of keys attempting to decrypt the random buffer to no avail. Based on the time it took to decrypt, you could determine how many clients the server had been serving. Decryption is a computationally expensive task, and there's all kind of things you can do with just how much time it took.

Edit: For example, AES-256 takes 14 rounds. Multiply that by 36 pre-shared keys and an adversary can very accurately detect what you are doing.

Another recent vulnerability was a web app that was using strcmp() to compare a password from a user-supplied buffer... The way strcmp() works is it compares characters one at a time until there's a mismatch in a character. So the attackers timed the response over many millions of attempts and character-by-character determined the password. The solution here would be to hash the password and compare the hash.

• This question seems to be about AES - the block cipher. What you're referring to is the used scheme of encryption and protocol, which both are quite independent from AES - the block cipher. – Maarten Bodewes Mar 18 '17 at 16:10