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
  • 451
  • 2
  • 4
  • 10
Fabius Wiesner
  • 137
  • 5
  • What is your threat model? Does the possibility of a corrupted firmware being loaded and bricking the device worry you? Do you employ proper padding in your message to be signed? Is your public RSA exponent 3 or 65537, or something longer/more complex? – swineone Feb 24 '23 at 15:36
  • 1
    Also, how does the firmware react if signature verification fails? Do you send a message back saying "Invalid signature" or something to that tone? In that case, is your code to check the signature constant-time (always take the same time to reply "invalid signature" regardless of whether the first or last bit/byte/word of the signature verification failed the check)? – swineone Feb 24 '23 at 15:42
  • Regarding the corrupted bricking firmware I will make a backup copy of a good application to revert to, when the signature check fails on the downloaded software. Due to the hardware making decryption from an external memory on the bus, it is easier to encrypt then sign, because I can verify the signature before copying the software to its right position. The message is padded properly. RSA 4096 will be used. – Fabius Wiesner Feb 24 '23 at 16:25
  • I don't know about the time regarding checking the signature, I am using LibTomCrypt for that. I don't know if it can vary. If the signature fails, no message is shown, just the old good application will be started. Someone can check the times though, I think, e.g. by seeing when the LCD lights up. – Fabius Wiesner Feb 24 '23 at 16:27
  • Rethinking about it, I think the time needed to verify the signature is fixed because it is computed over an hash of the firmware. So first the hash is computed, then the hash is signed. – Fabius Wiesner Feb 24 '23 at 16:52

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
  • 4,810
  • 1
  • 24
  • 48
  • Unsure what platforms you're used to (as well as the architecture of the OP's hardware, i.e. is code encrypted at all times in external memory?) but I'm familiar with certain MCUs with internal memory, and with the right configurations you can't dump the code memory. A physical attack is required to recover the code. – swineone Feb 25 '23 at 15:05