I’m pretty new on DPA analysis but I’m trying to learn what I can.
I would like to execute a DPA over a chip which execute a SHA256 over some known + unknown data.
In my case the chip is used to execute a sort of authentication based on the result of SHA256(challenge + shared key). From my understaning of the SHA256 algorithm the DPA should be possibile to get the shared key.
I would like to implement that attack on a chipwisper light (with the xmega target) to get it working on a know environment before then execute the attack on the real hardware.
Do you know if this kind of work has been already done by someone on others hashing algorithms? I did a search but I found only some accademic paper (which confirmed me that the attack is feasible) but nothing more.
From what I recall of looking at this a while ago - it’s somewhat annoying to implement. Unlike the “nice” attacks of AES/DES/etc, there is no non-linear S-Box or similar that makes finding locations very easy. In addition there is some various dependency on how it’s used - that is where the ‘varying data’ and ‘secret’ data are placed (assuming they aren’t using a standard HMAC that defines this, in which case you just need to check it would be possible).
How I would approach it: build the SHA2 firmware (the avr-crypto-lib in CW repo has SHA2). Start targeting the internal functions with a very small block, for example it looks like sha2_small_common_nextBlock should get called at the lowest layer, and has the actual XORs and similar you could target.
Modify the SHA2 code itself to make your life easier - cut out larger stuff & add triggers right at the areas of interest. Once you get things working in the easiest possible setting, slowly start building outward.
If you haven’t done DPA before I’d definitely start with some of the AES tutorials (especially the AES256 which uses DPA on the XOR).
The paper that you linked was the one accademic that I found already.
My code is SHA256( CHALLENGE + UID + KEY ) where:
challenge = sent via I2C (16 byte)
uid = internal chip ID (16 byte) which is known
key = stored in the chip (16 byte) but can be changed via I2C commands
I was thinking, I’m pretty sure that some code before the SHA256 will execute a concatenation of the challenge + uid + key. It’s not more simple to attack this part of the code? Theoretically I should be able to calculate at least the Hamming weight of the key for each byte or I misunderstood something?
Before implement all the sha256 attacks, I would like to verify if in the chip there is some countermeasures to limit power analysis, my idea was to generate some traces with different input and see if the power traces are different or not. It’s the right approach or there is some other way?
I don’t have any direct answers unfortunately, but I have some suggestions that may or may not lead you somewhere useful:
First, it strikes me that doing SHA256(message + key) is a somewhat creative use of SHA256. The accepted way of doing this is to use a keyed hash function instead (for example HMAC). So there may be some way of breaking this at the protocol level. A good reference for this sort of stuff is Jean-Philippe Aumasson’s “Serious Cryptography” book. It’s a good overview of the underlying theory and rationale, along with examples of how crypto can fail when it’s misused. For example have a look at the length extension attack. If the code is actually doing SHA256(key || message), (instead of SHA256(message || key) ), it might be vulnerable to this
Second, you could use TVLA testing to get some insight on where side-channel leakage exists. TVLA can’t prove or disprove that there is leakage but it can give you an idea. We have a TVLA tutorial for AES that you can use as a starting point.
So the main issue there is that on DPA/CPA attacks the requirement is you have “key XOR data”, where data is something you know/control. The reason being you basically run through many iterations of ‘data’ with a fixed key and see how the power changes at the output of the combination. The changing data gives you the ‘differential’ - otherwise it’s just a fixed value.
One issue with attacking SHA256 from a DPA standpoint is the ‘combination’ of data & key normally gets messy quick, unlike with AES/DES where it’s a simple XOR of the two and you can easily attack that output.
Directly doing a measurement of the power to derive the key is mostly used with ‘template attacks’ - but this may work in your case! You need an ability to template a device where you closely control the key for this attack (may be possible depending on your device).