4
$\begingroup$

In Secure Boot (here defined as data is encrypted and authenticated), we can encrypt the data with AES-128 and authenticate it with a RSA signature, computed over the data's hash, afterwards.

On boot, the device first calculates the hash of the encrypted data, verifies it with the given signature, decrypts the data, and starts executing. However, calculating the hash and verifying the signature is kind of expensive in case of time and resources, especially for embedded devices.

Proposal: My idea is to replace AES and RSA signature with AES-GCM to speedup the overall boot time. Using AES-GCM, we achieve the same security goals confidentiality and authenticity. The used AES key is stored securely on the device in a HSM (Hardware Security Module).

Drawback: I am aware of the fact that I loose the advantage of not having the private key on the device to generate a valid signature. In case of key compromise an attacker can read the data but cannot authenticate new data. Using AES-GCM a key compromise means that the attacker can not only read the stored data, but also authenticate it meaning he is able to execute his own data and fully take over the device.

Question: So besides the discusses drawback, would you consider this a valid approach? Or is there any reason for not using AES-GCM that I overlook?

Edit: Added more details to the description.

Just to clarify this. I am not talking about updating the data to be executed. In the described situation the data is already on the device (how the data is put initially onto the device is not relevant here).

Improve this question
$\endgroup$
2
  • $\begingroup$ There seems to be some confusion in "I loose the advantage of not having the private key on the device to generate a valid signature". What's lost is the he advantage of not having the private key on the many devices that verify the signature, at each boot. $\endgroup$
    – fgrieu ♦
    Feb 23, 2017 at 10:13
  • 1
    $\begingroup$ Also: RSA signature verification is actually very fast, and requires surprisingly little code (difficult one, but nothing comparable to signature generation, which requires side-channel protection). For all but tiny executables, the slowest is the hashing, and modern 32-bit CPUs do SHA-256 at many megabytes per second. I would recommend performing code validation after deciphering by the HSM (or other device holding the deciphering key), because that plugs the hole of altering the deciphered code on its way back from the deciphering device. $\endgroup$
    – fgrieu ♦
    Feb 23, 2017 at 10:25

1 Answer 1

Reset to default
4
$\begingroup$

Yes, if you already have a shared symmetric key then this would be something to consider.

Note the following:

  • you do not need to store a private key in the embedded systems in your previous scheme;
  • the security of the key generating the signature is probably more important than the key providing confidentiality of the update (updates are often not encrypted - at least for many software packages out there);
  • related with the previous topic, keeping a private key secure at a central location is more secure than distributing the symmetric key (even if it is placed in a HSM);
  • the access to the HSM is paramount in this scheme, if the software contains all the data to use the key in a HSM, then one hacked embedded device is still enough to compromise the security - you probably need to encrypt / "sign" for each device with separate keys if you use just AES-GCM.

That's just out of the top of my head - there are very likely more points to consider.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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