RSE image encryption

Overview of RSE image encryption and decryption

This page provides an overview of RSE firmware image encryption and decryption. It explains the encryption keys hierarchy, image encryption flow and the boot-time decryption flow.

The RSE component loads multiple firmware images. These images include Trusted Firmware-M BL2, the Trusted Firmware-M runtime image, Safety Island images, and the Trusted Firmware-A BL2 image. The build system signs and encrypts all images to ensure authentication, confidentiality, and integrity.

The encryption and decryption process uses the AES-128 (Advanced Encryption Standard) in Counter (CTR) mode. CTR mode enables random access to blocks without processing earlier blocks. CTR mode supports robust resume during swap interruptions.

For more information, see MCUboot encrypted images documentation.

Encryption approach

MCUboot provides image encryption support and uses a symmetric-key flow:

  • The signing process encrypts each image with a unique AES-128 data encryption key.

  • The system wraps the data encryption key by using AES-KW.

  • The build process appends the wrapped data encryption key to the MCUboot TLV area as an ENCKW entry with TLV type 0x31.

  • The build process signs the image and appends standard MCUboot TLVs, such as the hash, public key, signature, and protected TLVs.

The following figure summarizes the encryption flow and key wrapping process.

Flow showing RSE image encryption and key wrapping

Fig. 32 RSE image encryption procedure

Note

The development GUK (dummy_guk.bin) used in Arm Zena CSS is for test purposes only. Never use it for production.

Keys and key hierarchy

Key sources and usage

AES-128 Data Encryption Key (DEK)

Generated during signing and used to encrypt the image payload. The build system generates a separate key for each image.

AES-KW key encryption key

Derived from the group unique key and used to wrap data encryption keys. A single key encryption key can wrap multiple per-image data encryption keys.

Group unique key (GUK)

Stored in one-time programmable memory and shared by a group of chips with identical security properties.

Key hierarchy

The hierarchy keeps long-lived secrets in hardware and uses short-lived keys for each image:

  • The group unique key is provisioned in one-time programmable memory and is never exported. It acts as the root secret for a group of devices.

  • The system derives the key encryption key from the group unique key. For example, it can use a platform key derivation flow. The system uses it only to wrap or unwrap data encryption keys. The image never stores the key encryption key itself.

  • The data encryption key is generated per image during signing. It encrypts the payload by using AES-128-CTR. The system then wraps it with the key encryption key by using AES-KW and stores it in the ENCKW TLV.

At boot time, BL2 retrieves the key encryption key from the key management unit by using an opaque key handle. BL2 unwraps the Data Encryption Key and decrypts the payload. This approach limits exposure of long-lived secrets and supports per-image key rotation without changing the device root key.

The key hierarchy is:

GUK (OTP) -> KEK (AES-KW) -> DEK (per image) -> encrypted firmware

Encrypted image format example

The following example shows the high-level structure and logical layout of an encrypted image.

┌─────────────────────────────────────────────────────────┐
│ MCUboot header (0x400 bytes)                            │
│  - magic: 0x96f3b83d                                    │
│  - flags: ENCRYPTED_AES128 (0x4) | RAM_LOAD (0x20)      │
│  - version: 2.2.1+0                                     │
│  - load_addr: 0x31000000                                │
├─────────────────────────────────────────────────────────┤
│ Encrypted payload (0x2ae40 bytes)                       │
│  - Firmware code encrypted with the data encryption key │
│  - AES-128-CTR mode                                     │
├─────────────────────────────────────────────────────────┤
│ Protected TLV area (0x1c bytes)                         │
│  - SEC_CNT: Security counter for anti-rollback          │
│  - DEPENDENCY: Image dependencies                       │
├─────────────────────────────────────────────────────────┤
│ TLV area (0xee bytes)                                   │
│  - SHA256: Hash of header, payload, and protected TLVs  │
│  - PUBKEY: Public key for signature verification        │
│  - ECDSASIG: ECDSA signature                            │
│  - ENCKW (0x31): Wrapped data encryption key (24 bytes) │
├─────────────────────────────────────────────────────────┤
│ Image padding (0xff)                                    │
├─────────────────────────────────────────────────────────┤
│ Image trailer                                           │
└─────────────────────────────────────────────────────────┘

Boot-time decryption

During boot, BL2 checks each image header for the IMAGE_F_ENCRYPTED_AES128 flag. When the flag is set, BL2 retrieves the AES-KW key from the KMU slot and reads the ENCKW TLV to unwrap the Data Encryption Key. Then decrypts the payload with the DEK and verifies the image signature before loading the firmware.