General clarifications

[baptiste-cartier]

Hello,

We are looking into using MCUboot for several of our projects, and there are a few architectural questions that I would like to clarify.

A quick overview of our memory layout would be :

with the red section immutable and the orange section updatable by the bootloader (after hardware security is enabled) or factory tools (before hardware security is enabled).

First, does MCUboot support fixed address keys ? We need to be able to compile the bootloader only once, and then inject its keys in factory at a later date. (The Keys section will contain the signature public key, the encryption key and a password, at least)

Second, we would like to use AES-GCM instead of AES-CTR for firmware encryption, do you think this change would require a lot of adaptation ? A recent security advisor told us that AES-CTR is too vulnerable, AES-GCM has better results, any thoughts ?

Thirdly, we are going for bare metal application on most of our products, any known caveats to avoid/existing guide to read while porting MCUboot ? Or the good old "compile and fix until everything links" method is the way to go?

Lastly, just to confirm, if we need to add an UART boot menu, deep sleep mode, ..., that would be in the boot application (like for Zephyr boot in mcuboot-main\boot\zephyr\main.c) right ?

Thanks in advance for your answers !

[utzig]

Just for the encryption thought, I will read the other question later today...

Second, we would like to use AES-GCM instead of AES-CTR for firmware encryption, do you think this change would require a lot of adaptation ? A recent security advisor told us that AES-CTR is too vulnerable, AES-GCM has better results, any thoughts ?

There's a few problem that arrive with authenticated encryption in a flash device, one being that it consumes more space than just the size of the image itself, so it's not just reading the header and TLVs, although it would be possible to calculate, of course, but still all the authentication would have to be removed in one direction and re-added in another. I believe this would complicate a lot doing the swap upgrades. Is there a reason for using it if you already have a signature to ensure the validity of an image?

A recent security advisor told us that AES-CTR is too vulnerable

Do you mind sharing the papers or exploits? Or is it just his/her opinion?

any thoughts ?

I think both are good options, but one is way more complicated (GCM!).

[baptiste-cartier]

Is there a reason for using it if you already have a signature to ensure the validity of an image?

The idea was that we want to be able to upload a new binary through FOTA (the application will have the task to retrieve the new firmware) and also upload a new image through an UART menu in the bootloader. We thought that we needed an additional authentication on the UART, thus the GCM. To simplify the bootloader, we would like to treat the UART channel and the external Flash as basically the same thing, so the same data (encrypted and authenticated firmware with all the necessary security headers) is sent through UART and FOTA. Maybe this is overkill ?

Do you mind sharing the papers or exploits? Or is it just his/her opinion?

I do not have any papers about this, just his opinion on the UART use case.

Thanks for the answer

[d3zd3z]

First, does MCUboot support fixed address keys?

Not without modification, however I would not expect this to be difficult to implement. The keys are currently compiled into the bootloader, as variables containing a sequence of bytes. It wouldn't be difficult to enhance this so that the keys could be placed at specific fixed addresses. Patches to add this to the tree would, of course, be appreciated, as well.

Thirdly, we are going for bare metal application on most of our products, any known caveats to avoid/existing guide to read while porting MCUboot ? Or the good old "compile and fix until everything links" method is the way to go?

There are two existing bare-metal ports in the tree, so those might be good places to start. Generally, a bare metal port will start with an SDK for the SoC you are using.

Second, we would like to use AES-GCM instead of AES-CTR for firmware encryption, do you think this change would require a lot of adaptation ? A recent security advisor told us that AES-CTR is too vulnerable, AES-GCM has better results, any thoughts ?

This is the harder question to answer. I guess the first question that one needs to ask is what kind of security and thread model are you working toward. Without encryption, the integrity of images in MCUboot is maintained through use of a straightforward digital signature. The SHA256 of the plaintext is given to the signature algorithm, and this signature is verified. This does not change with encryption--the signature is still made over the plaintext.

The thing is, the decryption operation on the image is only performed once, when the image is installed into the internal flash. Using an authenticated encryption operation would be, at best, redundant to this, but largely not provide additional protection simply because the operation is not performed any more.

Aside from the authenticated aspect of AES-GCM, AES-CTR is idential (encryption in GCM is done in CTR mode). Implementing it would require storing additional data (more key information for the authentication, and we would have to store the authentication information. Because the encryption and decryption is done piecemeal (in blocks), this would likely require having storage of authentication information per-block, which would take significantly more space.

The use of encryption and authentication in MCUboot is fairly specific to the needs of this constrained environment. Adding GCM would add a lot of complexity, and I'm not seeing the security gain from it.

Let me know if you or this security advisor would like to discuss this further.

Lastly, just to confirm, if we need to add an UART boot menu, deep sleep mode, ..., that would be in the boot application (like for Zephyr boot in mcuboot-main\boot\zephyr\main.c) right ?

Yes. Zephyr is probably a good example to copy this from.

[baptiste-cartier]

Not without modification, however I would not expect this to be difficult to implement.

Ok that what I thought, I'll see what modification are needed. And create a PR if I do this in a clean way of course

There are two existing bare-metal ports in the tree, so those might be good places to start

Thanks, I'll look into it

I guess the first question that one needs to ask is what kind of security and thread model are you working toward.

As answered to @utzig above, this is to allow the same encrypted binary management on UART and FOTA.

Implementing it would require storing additional data

Based on our binary size, this would increase the encrypted binary size by around 7%, we decided that this was an acceptable cost (16 bytes of header for 256 bytes of data).

Adding GCM would add a lot of complexity, and I'm not seeing the security gain from it.

We'll look into this again on our side, maybe this is indeed to much complexity for nothing.

Yes. Zephyr is probably a good example to copy this from.

Perfect, thanks !