Understanding the authentication with ATSHA204A

Question

Since there are many Chinese companies that can easily reverse engineer the PCB design and extract the .hex file out of the microcontrollers (even from the secure flash), embedded developers have to add some more protection to their products. In my case I'm using a STM32F103 and I want to add the crypto IC ATSHA204A on my PCB to protect my IP. By doing this, I'm hoping even if they can get the .hex out of the MCU and clone the board, the hex file will refuse to work if it cannot recognize crypto chip on the PCB.

This crypto IC has a unique serial number that was written while being manufactured, and it can always be read. It also has some features such as a secure area to keep some secret data, ability to generate random numbers and send it to the host via I2C or one-wire, ability to calculate SHA-256 hash of some given string and so on.

Now I am trying to understand how I should work with it as I am kind of a noob on the authentication subject. From what I have understood from reading the datasheet is, the workflow will be like this:

Personalization of the crypto IC:

1. The secure area in the crypto chip will be filled by the host (STM32F103 in my case) with some random secret key for each product, only once.

2. The secret key will also be present in the hosts flash memory.

Authentication of the board (My understanding, which is probably wrong):

1. The host requests a random number from the crypto-IC. Then the host generates some concatenated string with the secret key and the random number (nonce?), and calculate the SHA-256 hash of it.

2. Now the host should send the random key back to the crypto-IC and expect from it to generate the same string with the secret key inside of the crypto-IC and calculate the SHA-256 hash of it.

3. Crypto-IC sends the calculated hash back to the host and the host compares the hashes.

4. If the hashes match, validate. If they don't, the host refuses to work.

The workflow is probably wrong, but the main idea should be something close to it. Can anybody explain this?

Answer 1

The workflow is probably wrong, but the main idea should be something close to it.

Nope, this is basically useless. This would be fine if you'd use your crypto IC for example to validate the authenticity of an addon device (say, a printer verifying the cartridge was made by the same company).

It doesn't help you, because "refuses to work" won't fly if someone has your firmware's machine code: finding the check in the disassembled machine code is usually not that hard. Then, it's as much as replacing a "jump to 'stop and do nothing'" with a "jump to 'start of useful functionality'"; typically, that involves changing a byte.

You need to encrypt the interesting part of your firmware in the permanent storage (typically, the MCU's built-in flash). Only a bootloader that uses the crypto chip to decrypt the main firmware would stay unencrypted. At boot, the bootloader decrypts the firmware into RAM.

Small problem there: You'd need to be pretty clever, hardware-wise, so that one couldn't just attach a logic analyzer between your MCU and the crypto IC and sniff the decrypted bytes.

There's workarounds that obfuscate things by wildly jumping around in memory while decrypting stuff etc. Problem is that there's nothing secret about that, it's just a bit more work to understand how the jumping around is done from machine code. (And if you manage to insert a single piece of machine code on that bus that makes the MCU stream out its entire RAM via some pin, then it's game over, too; it doesn't really matter to you whether you know where that piece of code ends up in RAM, you'll find it later in the dump, it's only important that it gets executed at some point.)

In other words, if you really think your firmware is that commercially interesting (people wildly overestimate that! For things that aren't mainly firmware, such as for about any consumer device and any industrial control it's usually hard to source all the parts and build the same/similar device cheaper than the original, and completely rewriting the firmware is often easy compared to that), then your only chance is to integrate secret keeping, encrypted storage and secure execution (so that RAM dumping is impossible).

There's microcontrollers that do that. They're usually a bit more expensive. But, as you can guess, if you're, for example, in a defense environment where you need to certify the firmware can't be tampered with, well, that's your way to go.

Nintendo makes devices where the financial incentive to not let anyone read their firmware or even modify it is strong:
The inability of users to run software that wasn't licensed by Nintendo on their consoles is critical to their business model. Therefore, being unable to circumvent checking of game's signatures is paramount, and that's why a Nintendo Switch goes all-out with multiple layers of protection. As you can guess, that's no guarantee – there were simply hobbyists (not even people with a criminal/commercial interest!) that found a way around that.

But you'll notice one thing: Just because it's hard to make perfect doesn't mean it's not worth it making it harder to clone your device. In my humble experience, cloners typically capitulate as soon as you'll need understanding of how a device works to copy it – otherwise, they'd be in the position of having engineers that could do your work, more or less, and those engineers typically work in your sector, not in some counterfeit lab. A good deterrent hence is putting the firmware encrypted into flash. It's not perfect, but the moment they'd have to get out the logic analyzer and spend weeks on reverse-engineering your into-RAM decryption protocol, just to get something that they might be able to copy, could be enough that they consider the financial risk too high and go for something else.