Power side-channel attack on AES-CMAC

Pretty image of some power traces

AES-CMAC is a popular message authentication code in the automotive world. Although I have been working in automotive electronics for 25 years, I don’t know the actual reason why. But my surmise is that this stems from the fact that the first cryptographic accelerators used in automotive met the “Secure Hardware Extensions” (SHE) specification, which only provided an AES cryptography accelerator (and the secure storage of some keys). SHE provides no hashing functionality, which means that HMAC is not available. It is also implemented as is a state-machine, not a microcontroller plus software, so is completely inextensible.

Modern automotive processors provide more capability in the form of a hardware security module, which is a microcontroller with user-defined code alongside it’s secure storage and cryptography accelerators. However, history dictates that CMAC is still widely used.

For example, to provide a more secure challenge-response protocol for unlocking the diagnostics features, you could do worse than have the ECU present a challenge in the form of large random number (say 256-bits) to the mechanic’s tester box, and have that tester box reply with the AES-CMAC of that challenge. If that CMAC is correct, the ECU can authorise the activity requested.

Being a shared-key system, this now creates the problem that the CMAC key is in the attackers hands (within the mechanic’s tester) which will allow them to extract the key from the tester. To mitigate this, we can store the key in an IT-grade HSM, within our own infrastucture. Then we require the mechanic to log in and interface the tester with our infrastructure. The challenge is then passed (over the internet, mediated by the tester) to our HSM and it performs the CMAC operation and returns the answer the tester which then sends it onwards to the ECU. The ECU contains the same key and can still use it to check the CMAC is correct.

The ECU will defend this key inside its own HSM, so extracting it (even with powerful access such as an unlocked debug port) is not straightforward.

I’m going to attempt to extract the key by measuring the power consumption of the microcontroller while it performs the CMAC calculation in order to check the value received.

Martin | Parallelpoints Some power spikes… such as we hope to take advantage of

More to follow…

Leave a comment

Your email address will not be published. Required fields are marked *