Encrypted image as only input at startup

[Olstyle]

I have build a two slot setup where the secondary slot should hold an encrypted image. Now I thought that this image will also be decrypted and copied over to the primary slot if the primary slot is empty (=erased flash = 0xFF for my controller).
But it looks like mcuboot (1.8.0) tries to read the header of the primary image to do this, failing in the process because there is no valid TLV there.
The following will crash into a failed assert on return:

Is there something I have setup wrong, is this a bug or is this not possible by design?

Also if I first flash an unencrypted image to the primary slot and then do the update by writing an encrypted image to the secondary slot, according to enrypted_images.md it will not be encrypted on the swap operation since its header never head any encryption settings set:

When upgrading the
image from the secondary slot to the primary slot it is automatically
decrypted (after validation). If swap upgrades are enabled, the image
located in the primary slot, also having the ENCRYPTED flag set and the
TLV present, is re-encrypted while swapping to the secondary slot.

But how do I even make it have a correct TLV to be encrypted?

So all in all I am missing a way in the moment to actually always have an encrypted secondary slot. Either I start with a primary image, than that will be swapped as plain data to the secondary slot once I start an upgrade via writing an encrpyted image to the secondary slot (and that update DOES work), or I start without an primary image and the swap/install of the secondary image crashes.

[utzig]

You have to enable MCUBOOT_BOOTSTRAP to enable an "upgrade" to an empty primary slot. Check the proper configuration of your port to get that symbol enabled, eg CONFIG_BOOT_BOOTSTRAP=y for Zephyr.

[Olstyle]

Ok, defining that (I can' t find any notion of this define in the documentation or templates by the way) seems to make the "upgrade from empty" possible (though it does again go to an assert after the install, but then is actually runnable after a reset -> that might also be a problem with my own code).

This still leaves the question how a primary image might be marked as "to encrypt on swap" but not actually encrypt it. I guess this can be somehow (how?) done with imgtool?

[utzig]

Ok, defining that (I can' t find any notion of this define in the documentation or templates by the way)

Are you working on a supported port? I'm not sure it is in a template or something like that, but we welcome a PR fixing this.

seems to make the "upgrade from empty" possible (though it does again go to an assert after the install, but then is actually runnable after a reset -> that might also be a problem with my own code).

Yes, that's what it does.

This still leaves the question how a primary image might be marked as "to encrypt on swap" but not actually encrypt it. I guess this can be somehow (how?) done with imgtool?

Encrypted is a flag on the image header. If it is set, then an image is decrypted when swapping from secondary to primary and encrypted when swapped from primary to secondary. I don't think you are able to create an image that has an encrypted flag set without also having its payload encrypted in imgtool (I don't remember for sure).

[Olstyle]

Are you working on a supported port? I'm not sure it is in a template or something like that, but we welcome a PR fixing this.

I am going bare metal, so I started off with samples\mcuboot_config\mcuboot_config.template.h which is not really extensive. It looks like boot\mbed\mbed_lib.json is pretty much the most complete description of configuration options to date (just found it by looking for some descriptions again).

Yes, that's what it does.

Is this considered useful in some way? I don't see why I shouldn't want to just boot through right afterwards.

Encrypted is a flag on the image header. If it is set, then an image is decrypted when swapping from secondary to primary and encrypted when swapped from primary to secondary. I don't think you are able to create an image that has an encrypted flag set without also having its payload encrypted in imgtool (I don't remember for sure).

The way I imagine of setting up an MCU product with the encrypted image option would be to start by flashing bootloader+primary image during production. Then later there will be an update OTA which writes the secondary image, maybe to an external memory. Now when the first OTA update is installed, of course the original image should not be in plaintext on the external flash as a result of the swap.
Which to me sounds like the perfectly normal use case for anyone using the encryption option, so I am kind of surprised building an appropriate header for the primary image is no (documented) option, since actually it should be very much encouraged.

Thanks for the lightning fast response time by the way 👍

[utzig]

The way I imagine of setting up an MCU product with the encrypted image option would be to start by flashing bootloader+primary image during production.

With bootstrap enabled what you do is to flash both the bootloader and an encrypted image in the secondary (but nothing in the primary). On first boot it will copy and decrypt the image in the secondary to the primary. From that point onwards you have a working device that never exposes decrypted data in the secondary.

[Olstyle]

The way I imagine of setting up an MCU product with the encrypted image option would be to start by flashing bootloader+primary image during production.

With bootstrap enabled what you do is to flash both the bootloader and an encrypted image in the secondary (but nothing in the primary). On first boot it will copy and decrypt the image in the secondary to the primary. From that point onwards you have a working device that never exposes decrypted data in the secondary.

Yes, that can be done. But for me in the moment the bootstrap option is actually just a workaround considering writing the external flash with an encrypted image and then waiting for the bootstrap to take place adds unnecessary production steps (and time) I can get rid of if I can just get the primary image to encrypt on upgrade.