From 44a935ebcc2e7e82c4df7d5830d92abbf3d029c4 Mon Sep 17 00:00:00 2001 From: Thomas Altenbach Date: Tue, 30 Apr 2024 17:19:55 +0200 Subject: [PATCH] docs: Update documentation regarding encrypted scratch area When using swap using scratch, the decryption now happens when copying from the scratch area to the primary slot, which means the image is stored encrypted in the scratch area. This commit updates the documentation accordingly. Signed-off-by: Thomas Altenbach --- docs/encrypted_images.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/docs/encrypted_images.md b/docs/encrypted_images.md index 834428f3..85d26d8e 100644 --- a/docs/encrypted_images.md +++ b/docs/encrypted_images.md @@ -120,12 +120,14 @@ start the validation process, decrypting the blocks before check. A good image being determined, the upgrade consists in reading the blocks from the `secondary slot`, decrypting and writing to the `primary slot`. -If swap is used for the upgrade process, the encryption happens when -copying the sectors of the `secondary slot` to the scratch area. - -The `scratch` area is not encrypted, so it must reside in the internal -flash of the MCU to avoid attacks that could interrupt the upgrade and -dump the data. +If swap using scratch is used for the upgrade process, the decryption happens +when copying the content of the scratch area to the `primary slot`, which means +the scratch area does not contain the image unencrypted. However, unless +`MCUBOOT_SWAP_SAVE_ENCTLV` is enabled, the decryption keys are stored in +plaintext in the scratch area. Therefore, `MCUBOOT_SWAP_SAVE_ENCTLV` must be +enabled if the scratch area does not reside in the internal flash memory of the +MCU, to avoid attacks that could interrupt the upgrade and read the plaintext +decryption keys from external flash memory. Also when swap is used, the image in the `primary slot` is checked for presence of the `ENCRYPTED` flag and the key TLV. If those are present the