3
$\begingroup$

I'm developing a bootloader for an embedded device, with which it should be possible for customers (i.e. device owners) to update the device's firmware. It is required that:

  1. the firmware is distributed encrypted
  2. the firmware's integrity is protected
  3. the firmware is authentic, meaning that it was released by us (the manufacturer).

Based on my limited knowledge about cryptographic schemes, I came up with the following potential solution (see below for explanation):

Potential firmware update process

  • For enryption and data integrity the firmware would be encrypted using AES256 in EAX mode using a key, which is shared between the manufacturer and the bootloader on the device, in addition to a nonce (i.e. initialization vector), which is encrypted (signed) using a private RSA key
  • The AES encrypted firmware and the RSA encrypted nonce are then distributed to the customer
  • The bootloader on the customer's device would then decrypt the nonce with the "public" RSA key (to ensure authenticity), and decrypt the firmware using the AES key and the nonce

Does this constitute a valid scheme for a secure bootloader (in terms of data privacy, integrity and authenticity)?

I am aware that using AES in EAX mode already provides data authenticity, however I would like to make sure that authenticity is still ensured in case the AES key is compromised.

$\endgroup$
1
$\begingroup$

First, if you mean to sign something, you should use a signature algorithm, rather than "RSA encryption" with private key, which on its own may be very weak.

Now the main issue here is that the RSA part is only authenticating the nonce. Anyone who knows the AES key can just encrypt an arbitrary firmware image with a nonce they've already seen. This allows them to reuse the earlier signature. So there's no guarantee of authenticity if the AES key is compromised.

To fix this you could sign the whole encrypted image – nonce, authentication tag and all. With a strong signature algorithm (e.g. RSASSA-PSS) using a strong hash function, there is no way even knowing the AES key to encrypt another image with the same signature.

$\endgroup$
  • $\begingroup$ not sure if Encrypt-Then-Sign is actually a good idea here or if Sign-Then-Encrypt is better as you'd then sign the actual firmware and there are no hidden keys that would yield a valid tag and some mean unwanted firmware. $\endgroup$ – SEJPM Sep 7 '15 at 19:25
  • $\begingroup$ @SEJPM, that's an equally valid idea. However, it means you have to decrypt the whole firmware before authenticating it. If you sign the ciphertext, you can authenticate it, and only decrypt the parts you need as you need them. It also means no one without the AES key can verify the authenticity, which might be desirable (e.g. check a downloaded firmware before loading on the device). $\endgroup$ – otus Sep 7 '15 at 19:52
  • $\begingroup$ thanks for the answer. If I use EAX mode for firmware encryption, would it already be sufficient to sign the authentication tag generated by that mode? or alternatively, would encryption using AES in CBC or CTR mode and subsequent hashing (of the encrypted firmware) and then signing (of the hash) be a valid scheme? I'm asking because EAX mode with subsequent hashing and signing seems to be redundant in terms of hash generation. $\endgroup$ – skasys Sep 8 '15 at 10:27
  • $\begingroup$ @skasys, I'm fairly sure signing the tag wouldn't be. As I recall, EAX uses OMAC which allows the key owner to create MAC collisions at will (unlike e.g. HMAC). A non-authenticating mode + signing would be enough. You probably shouldn't add a hash yourself, but rely on the signature algorithm doing the hashing. $\endgroup$ – otus Sep 8 '15 at 10:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.