I’m looking into performing a CPA attack on a device that only transmits data. I’m completely unable to control the plaintext. The data encrypted however (using AES128 in ECB) includes a 4 byte serial number + 3 byte counter + 9 hard coded bytes. So only 3 bytes will ever change.
I’m assuming that this will allow me to only recover 3 bytes of the key (at least with the default leakage model), matching the offset of the counter bytes? Is that assumption correct? Are there any other leakage models that would allow more than these three bytes to be recovered?
I think you’re confusing the ciphertext with the encryption key. A CPA attack on AES recovers the encryption key. Byte X of the AES plaintext is processed by all bytes of the encryption key, and affects all bytes of the ciphertext.
If you’re totally new to AES, I recommend some background reading; our courses are a good starting point. There are lots more resources online; the wikipedia AES page is pretty good; Serious Cryptography is a very good and approachable whirlwind tour of modern cryptography.
Back to your question-- different attacks have different requirements; some require knowledge of the plaintext (or ciphertext), others require control of the plaintext. Going through our courses will give you a better handle on this.
I am trying to recover the key. I’ve done the 2 SCA courses. My issue is only 3 bytes in the plaintext on the device I’m researching ever change, so I’d only have hamming weight swings on those 3 bytes. Looks like CPA (and DPA) in this case won’t work to recover the entire key.
I was looking into other methods and came across template attacks. Seems like that has a shot to work, since I have a copy of the AES implementation used and I can attempt to profile it on a second testing target using the same chip but with my firmware. Once I build the profile, I can try recovering the key on a real device. Do this sound feasible?
I’m sorry, I forgot how that the leakage model in our CPA attack notebook uses the first round sbox output! This is why you see a direct link between which plaintext bytes are variable and which key bytes can be retrieved.
In theory, any leakage model which uses anything later in the AES encryption cycle, where the input plaintext bytes start affecting every byte of the result, should work, but how well a particular leakage model works will depend on the target implementation. I will run a couple of quick experiments…
For a template attack to work, the target used to build the template and the actual target need to be as close as possible, and this applies to both the hardware and the firmware running on it.