STM32H573 OTFDEC Images: Bind Ciphertext to the Physical Address and Region ID

An encrypted external-flash image can stop decrypting correctly after relocation even though its key and nonce have not changed. On STM32H573, the physical read address and selected OTFDEC region are also inputs to the keystream. Moving ciphertext is therefore a cryptographic deployment change, not merely a storage-layout edit.

This analysis pins RM0481 Rev 5, chapter 42, including Figure 402 on page 1659. The chapter applies only to STM32H533/73xx; this article selects H573. It must not be generalized to H563 or every H5 device. The symbolic examples concern standard AES-CTR operation, not the additional execute-only enhanced mode.

Record the image’s complete deployment context

For one encrypted region, record the target device, standard operating mode, key identifier, nonce, firmware-version field, region ID, physical AHB placement and enabled region bounds. Keep actual secret key material out of this review record. An identifier can link to the approved provisioning process without exposing the key.

The manual describes four encrypted regions, each with its own key, nonce and version. Region definitions have 4096-byte granularity, and overlapping regions are invalid programming even though the hardware does not prevent them. When used with OCTOSPI, the flash must be accessed through its memory-mapped mode.

Those bounds determine whether a read is treated as encrypted. They do not replace the read address in the cryptographic input. Extending or moving a region’s bounds changes which reads qualify; it does not rewrite the ciphertext stored at those addresses.

Distinguish region coverage from the block address

For each 128-bit block, the documented initialization vector combines the nonce, fixed zero fields, firmware version, encoded region identity and ReadAddress[31:4]. The region number is x from one through four, with x - 1 encoded in its two-bit field.

The address contribution is the AHB read address of the encrypted block, with the low four address bits omitted. It is not simply the block’s offset from the programmed region start. Reusing the same offset inside a different physical region can therefore change the input to AES.

The standard-mode reasoning can be written symbolically:

S_A = AES(K, IV(N, V, R, A[31:4]))
C_A = P_A XOR S_A
P_read = C_A XOR AES(K, IV(N, V, R, ReadAddress[31:4]))

Here P_A is a hypothetical plaintext block, C_A its ciphertext, and R identifies the selected region. These equations describe the mechanism; no key, ciphertext or plaintext test artifact was generated.

Change address and region identity independently

In the baseline paper configuration, the packaging context and hardware context agree on every input. Reading the ciphertext through the intended physical route reproduces the keystream used when that block was encrypted.

For the relocation case, choose another qualified physical block address B whose address contribution differs from A[31:4]. Copying C_A to B while leaving the key, nonce and version unchanged selects a different initialization vector. The old ciphertext is not a correctly encrypted representation of the intended plaintext at that new address.

Now keep the physical address fixed but assign the encrypted content to a different OTFDEC region ID. That changes another IV field. Reprogramming the new region with the old key and nonce is still insufficient to preserve the original keystream.

These are two independent rows in one compatibility matrix, not separate encryption features. An image package should reject either unexplained mismatch before deployment. Matching only the key identifier leaves both defects undetected.

Trace aliases to the address OTFDEC actually sees

A CPU code alias, linked execution address and physical AHB read address are not automatically the same value. Freeze the actual memory-controller and remapping route used by the product, then identify the address presented to OTFDEC.

Changing an alias while preserving the same underlying physical address is a different case from relocating ciphertext physically. Do not substitute the linker address into the encryption tool merely because it is where the program counter will appear. Conversely, a valid cache alias does not prove the packaging tool used the correct physical cryptographic address.

This review does not provide cache initialization or arbitrary relocation instructions. The required artifact is an address correspondence that both the image packager and target configuration interpret identically.

Re-encrypt updates under the required new context

RM0481 requires the entire encrypted region to be re-encrypted with a different cryptographic context when its contents change. It identifies the key or initialization vector as the changing context, and lists key, nonce and firmware version among the per-region inputs that must change appropriately for a new encryption.

Do not patch changed plaintext using a reused CTR context, or copy old ciphertext to a new placement and call the operation re-encryption. Establish a new approved context and regenerate the complete region’s encrypted representation for the intended placement and region identity.

Finally, correct decryption is not image authentication. Preserve the product’s independent authenticity policy without treating an OTFDEC read as a signature check. No device programming or decryption test occurred here. The acceptance worksheet compares the packaging tuple with the configured tuple, explicitly rejects address and region mismatches, and leaves actual target qualification to a controlled later test.