Lines Matching refs:image
188 For signing with a crypto key and guarantee the authenticity of the image being booted, see the
189 section [MCUboot image signature verification](#mcuboot-image-signature-verification) below.*
208 MCUboot will then verify and compare the new image version number with the current one before
211 Version number is added to the image when signing it with `imgtool` (`-v` parameter, e.g.
216 It is also possible to rely on a security counter, also added to the image when signing with
217 `imgtool` (`-s` parameter), apart from version number. This allows image downgrade at some extent,
225 E.g.: if the current image was signed using `-s 1` parameter, an eventual update image must have
232 MCUboot design the image in Primary Slot, from where the image is executed, is stored plaintext.
233 Espressif chips have off-chip flash memory, so to ensure a security chain along with MCUboot image
237 ## [MCUboot image signature verification](#mcuboot-image-signature-verification)
239 The image that MCUboot is booting can be signed with 4 types of keys: RSA-2048, RSA-3072, EC256 and
280 # Use Mbed TLS lib for RSA image signing
289 ### [Signing the image](#signing-the-image)
291 Now you need to sign the **image binary**, use the `imgtool` with `-k` parameter:
297 If signing a Zephyr image, the `--pad-header` is not needed, as it already have the padding for
377 Once the **bootloader image** is built, the resulting binary file is required to be signed with
386 Then sign the bootloader image:
410 Secure boot uses a signature block appended to the bootloader image in order to verify the
411 authenticity. The signature block contains the RSA-3072 signature of that image and the RSA-3072
417 1. On startup, since it is the first boot, the ROM bootloader will not verify the bootloader image
423 5. Bootloader proceeds to load the Primary image.
426 will verify the MCUboot bootloader image. The process of an usual boot:
432 3. ROM bootloader verifies the bootloader image, interrupt boot if any step fails:
435 2. Generate the application image digest and match it with the image digest in the signature
437 3. Use the public key to verify the signature of the bootloader image, using RSA-PSS with the
438 image digest calculated from previous step for comparison.
439 4. ROM bootloader executes the bootloader image.
441 6. Proceeds to boot the Primary image.
499 Encryption, encrypt the flash content including bootloader and image slots, burn the eFuses that no
525 ### [Signing the image when working with Flash Encryption](#signing-the-image-when-working-with-fla…
527 When enabling flash encryption, it is required to signed the image using 32-byte alignment:
538 First ensure that the application image is able to perform encrypted read and write operations to
552 2. Encrypt flash in-place including bootloader, image primary/secondary slot and scratch.
558 First ensure that the application image is able to perform encrypted read and write operations to
610 1. Encrypt flash in-place including bootloader, image primary/secondary slot and scratch using the
637 For updating with an image encrypted on the host, flash it through serial using `esptool.py` as
651 2. MCUboot bootloader validates the image using the chosen algorithm EC256/RSA/ED25519. It also
652 validates an upcoming image when updating.
659 MCUboot image signing. The issue <https://github.com/mcu-tools/mcuboot/issues/1262> was created to
662 ## [Multi image](#multi-image)
664 The multi image feature (currently limited to 2 images) allows the images to be updated separately
669 ### [Host OS boots second image](#host-os-boots-second-image) argument
671 Host OS from the *first image* is responsible for booting the *second image*, therefore the
672 bootloader is aware of the second image regions and can update it, however it does not load
681 # Enables multi image, if it is not defined, its assumed
682 # only one updatable image
685 # Example of values to be used when multi image is enabled
700 different CPUs, firstly the *second image* on the APP CPU and then the *first image* on the PRO
717 # Enables multi image, if it is not defined, its assumed
718 # only one updatable image
721 # Enables multi image boot on independent processors
722 # (main host OS is not responsible for booting the second image)
726 # Example of values to be used when multi image is enabled
738 ### [Image version dependency](#image-version-dependency) argument
741 allows a version assigment when signing an image, it is also possible to add the version
748 - `<VERSION>` defines the version of the image being signed.
749 - `"(<IMAGE_INDEX>, <VERSION_DEPENDENCY>)"` defines the minimum version and from which image is
759 Supposing that the image 0 is being signed, its version is 1.0.0 and it depends on image 1 with
817 # Use sector erasing (recommended) instead of entire image size
838 ### [MCUMGR image upload example](#mcumgr-image-upload-example)
847 Upload the image (the process may take some time):
849 mcumgr -c esp image upload <IMAGE_BIN>
860 *Serial recovery mode uploads the image to the PRIMARY_SLOT, therefore if the upload process gets
861 interrupted the image may be corrupted and unable to boot*