2

I know that there are previous questions on the subject e.g. here, however I would like to ask it for my particular (simple) case.

I have an application firmware that is downloaded to a microprocessor through a bootloader firmware that is taking care of decryption and signature verification.

The signature is implemented through RSA. The bootloader has only one public key to authenticate the application firmware, so there is only one entity that can sign the application firmware with the private key. No other signature is accepted.

The application firmware is also encrypted with AES (AES-128-CTR), the key and iv being stored securely in the device.

In the past, I have always signed and then encrypted. However, in the implementation that I am working on now, it would be easier for the bootloader to verify the signature first and then decrypt it. So I would prefer to encrypt and then sign the application firmware to be downloaded.

In this situation, what is better? Sign-then-encrypt or encrypt-then-sign?

Rohit Gupta
  • 489
  • 2
  • 5
  • 10
Fabius Wiesner
  • 137
  • 5

1 Answers1

3

summary: Just do what is best for your hardware, which seems to be encrypt then sign.

From the standpoint of someone who makes hardware, and formerly made a lot of firmware, we generally sign the encrypted code because I would also have the hash of the non-encrypted code as well. Without knowing more about your target, memory, etc, it's difficult to get a definitive answer because the threat models are different in hardware. For instance, most common software threat models don't mean much when I have access to the hardware as I can just use JTAG to dump the memory. From the comments, it seems that your threat model is more software-based than hardware-based, and I agree that encrypt then sign is a better approach based on the fact that you have the external memory.

I generally would split things into two parts. I would have my encrypted, then signed binary. This took a lot of time to get into the firmware due to the time it takes FLASH a large file combined with the decryption. I would then have a Blake hash of the decrypted code that was signed that I used for the check of the FLASH, which is really fast.

b degnan
  • 5,110
  • 1
  • 27
  • 49