I’m very very new to the idea of SCA and diff power anaylsis… So please forigve my ignorance here!
From everything I’ve seen so far, this works really well on AES because of a simple XOR op before the known and standard lookup table.
What if I don’t know the algorithm I want to attack? How would I begin correlating input data to differential power samples!?
If someone just (foolishly usually) changed the lookup table, how would anyone using power analysis ever figure that out?
Even for challenge and response, if I don’t know the algorithm used (assume it’s some arbitrary “security through obscurity”) I can only see when my data was put into the bus, and eventually the result. I feel like I’m missing some important detail here.
For something like a secure bootloader, if I’m trying to leave the bootloader in place, add my own application - it seems the input could be any amount of the total flash I’m trying to replace - So in that case, I don’t have a single byte input - I have an entire file. Seems useless in this scenario but I figured I’d ask.
Any help would be appreciated. Browsing over the tutorials now just to see if I can answer any of these myself.
This can involve a few things… one thing is just to guess, for example if you’re running on a piece of HW with an AES accelerator it’s probably using AES. This might not help you know knowing what mode to run, but you might be able to make some assumptions there too. You should only get high correlation peaks for the correct algorithm.
Often the algorithm is documented somewhere (as it’s good marketing). Failing that you might need to see if you can get access to part of the firmware image somehow.
There’s versions of the algorithm that use “secret” s-box tables. You can try searching for papers with “unknown” or “secret” s-box. I remember coming across an example of breaking one, but can’t seem to find it now.
All of the DPA stuff works well as you don’t need to know specific times. You can perform the DPA attack at every point between the input & output, and if you’re using a correct guess should see a high correlation peak.
You can see the AES-256 tutorial - in this case I only use the first block of the AES attack, and reset the system. All you care about is that file is fed into the AES engine/software 16-bytes at a time. Once you’ve got the key you could decrypt the firmware update file and see what sort of structure might be hidden inside it.
I’m also investigating a device that has uses and unknown encryption.
Its possible a 1024 byte, one time pad (I’m not sure if One Time Pad is the best description in this case as the same pad is used for all firmwares ) , which is XORed across the entire firmware e.g.
out = in[x] XOR pad[x%1024]
However in firmware’s I seen which use this, the telltale is that some bytes in the encrypted firmware are always the same, because the MCU’s vector table is often at the start of the firmware image, and generally people don’t deliberately make minor changes to the vector address, or simply can’t do that because the code could not be made to work.
Likewise if the firmware contains pre-compile libs, which are often linked at the same place.
To counteract the discovery that its a one time pad, I have seen firmware files where they are send in reverse order, so the beginning of the file always appears to be different.
However you just have to look at the end of the file and see the same data for the first 8 bytes etc.
I would think that for a 1024 byte (or whatever size), One Time Pad, it should be reasonably easy to spot this by just sending zeros, as the power consumption pattern would replicate every 1024 bytes.
Then once it was established how long the “pad” was, data could be crafted to exercise each array element in the pad, to determine the value in each element in the pad
(Though I will need to have a think about what data would need to be sent) perhaps walking ones or walking zeros