 Hello, and welcome to this presentation of the OTF Deck, which is included in STM32-H7B microcontrollers. The original purpose of OTF Deck is to protect the confidentiality of read-only firmware libraries stored in external SPI NOR flash devices. The OTF Deck performs on-the-fly decryption during Octo-SPI memory mapped read operation. Any read-access size down to the byte is supported. Two OTF Deck instances are located between the AXI bus matrix and one Octo-SPI peripheral that controls the access to an external serial flash. Advanced encryption standard, or AES, 128-bit algorithm in counter mode is implemented to achieve the lowest possible latency. As a consequence, each time the content of one encrypted region is changed, the entire region must be re-encrypted with a different cryptographic context, key or initialization vector. Up to eight independent encrypted regions, four per OTF Deck, can be defined, each with their own 128-bit key and initialization vector information, 64-bit application nonce and 16-bit encrypted library version. A write-locking mechanism prevents any further reconfiguration of region parameters. The purpose of the OTF Deck peripheral is to protect the user code and or data that are stored in the external serial flash memory. If the image is stored unencrypted, it is easy to read it by either de-soldering the flash device, then re-soldering it on another board, or by spying the traffic on the SPI bus by using a logic analyzer or an oscilloscope. Consequently, the image stored in the flash memory should be encrypted, then decrypted on the fly during runtime reads. The latency caused by the decryption should be minimized. The OTF Deck has been designed to tackle these objectives. The OTF Deck is a peripheral implemented in the STM32-H7B line, able to decrypt with low latency code and or data stored within an external flash. It also supports an encryption mode. The encryption process must follow the sequence described in the reference manual. When the encryption mode is selected, on-the-fly decryption for all regions is deactivated. Since the decryption is done internally by the microcontroller, the data transferred over the OCTO SPI bus is encrypted. This is a countermeasure against flash unsodering and bus spying. The OTF Deck is a companion IP of the OCTO SPI peripheral. It intercepts any data read and instruction fetch that targets the external flash. Decryption is transparent to the Cortex-A7 core. Data and or instructions that the processor receives have been decrypted in hardware by the OTF Deck unit. The OTF Deck protects the confidentiality of external read-only code, read-only data, or read-only code plus data areas. They are decrypted on the fly. Four independent and non-overlapping encrypted regions can be defined. The AES 128-bit cipher in counter mode is used to achieve the lowest possible latency. Access minimum granularity is 8 bits. Each region is defined by a 128-bit secret key and its public 8-bit CRC. Initialization vector of each region is built by the OTF Deck unit using a 64-bit application information and a 16-bit library version. The user can define this information as public diversification data. The OTF Deck unit has an AHB slave interface used to access control and status registers. For each region, the operating mode has to be selected. More specifically, if the region contains both code and data, the mode field of the region configuration register has to be set to binary value 1-0. If the region contains only data, the mode field of the region configuration register has to be set to binary value 0-1. If the region contains only code that can be encrypted externally, the mode field of the region configuration register has to be set to binary value 0-0. For those three modes, standard AES encryption algorithm is used. Hence, the encryption process can be embedded in code generation tools or application firmware for runtime encryption. If the region only contains instruction, the mode field of the region configuration register could be set to binary value 1-1. In this case, an additional layer of protection is added on top of the standard AES encryption algorithm. Hence, the encryption process cannot be embedded in software tools. OTF Deck must be used to perform the encryption using dedicated RSS function. The configuration of each region can be independently locked to prevent any further modification. Both the 128-bit key and the configuration parameters can be locked. All key registers are right only and are automatically erased in case of intrusion detected by tampers, readout protection or RDP regression or mode field change. The principle of OTF Deck is to analyze all AXI read transfers on the associated AXI bus. If the read request is within one of the four regions programmed in OTF Deck, the control logic triggers a key stream computation based on the AES algorithm in counter mode. This key stream is then used to on-the-fly decrypt the data present in the read transfer from the OctoSPI AXI master, tying low the R-ready signal of this master while the key stream information is being computed. This takes up to 11 cycles. Any access outside the encrypted OTF Deck regions belongs to a non-encrypted region. As OTF Deck is used in conjunction with OctoSPI, it is mandatory to access the flash memory using the memory map mode of the flash controller. In the region configuration register, the mode bits define the OTF Deck operating mode, standard or enhanced encryption. The RSS can use OTF Deck for encrypting data using either the standard AES algorithm or the enhanced encryption algorithm. A tamper detection, an RDP regression or a mode bits change automatically erases the keys. The OTF Deck can assert and interrupt to the NVIC for three possible causes, security error, key error and execute only or execute while encryption error. Each of these causes has a dedicated flag and interrupt enable bit. RSS reset an encrypt service to application, ST or user, encrypts code located in the dedicated SRAM area. Depending on the size of the code to encrypt, several calls to this service can be requested. User firmware is responsible for external flash programming. Note the RSS service reset and encrypt always triggers a system reset. The user firmware is in charge of the following initializations during the boot sequence. Loading keys within OTF Deck key registers for each OTF Deck region. Loading nonce, version, address start and address end information for each OTF Deck region. Set reg EN bits, locking OTF Deck configuration above, recommended. Then on the fly decryption is ready. Secure firmware install or SFI is a global solution for the STM32H7B series of microcontrollers, allowing secure and counted installation of OEM firmware in untrusted production environment, such as OEM contract manufacturer. OEM firmware protected by SFI can be stored in the device's embedded flash or encrypted in external flash connected via OctoSPI. When external flash memory is targeted by SFI, OEM firmware code must be encrypted with an external firmware and data AES key. This key can be common to all devices. In this case tools could perform the encryption if OTF Deck mode equals 1-0, or unique per device. In this case firmware is encrypted inside the device, mandatory if OTF Deck mode equals 1-1. On chip encryption using OTF Deck is illustrated in the next slide. For more information please refer to application note AN4992 for secure firmware install or SFI solutions. This slide represents the sequence where the STM32 secure bootloader handles both internal firmware installation and external firmware installation with an AES key for the global external flash memory and the help of an external flash memory loader. The numerical steps are represented on the schematic. 1. Create an SFI image using STM32 Trusted Package Creator or TPC with A internal firmware and data including external flash memory drivers, B the AES key for the external firmware and data, and C external firmware and data. 2. Internal flash memory programming as described in the STM32 H7B RSS training. 3. External firmware and data AES key programming in OTF Deck peripheral. Alternatively to what is drawn on the slide this key can be managed locally to the device not globally in the flashing tools. 4. External flash memory chunk encryption. 5. External flash memory programming by the user's firmware. Afterward during each boot the secure internal firmware in RSS first copies the AES firmware and data keys in write-only OTF Deck key registers then activates the OTF Deck region tied to those keys. At this point the CPU can seamlessly read, fetch data or code from external flash memory encrypted or not once the Octo SPI driver has been initialized. The OTF Deck has three interrupt sources. The security error is raised when an attempt to read key registers is detected or when an attempt to write keys while the key lock bit is set or when an attempt to reconfigure a region when the config lock bit is set. When execute only mode, mode equals 00 or enhanced encryption mode, mode equals 11 is selected the execute only error is raised when a read access is attempted to this protected region. When data only mode, mode equals 01 is selected the execute never error is raised when an execute access is attempted to this protected region. The key error is raised when a read request is attempted to a region whose key registers are null or not properly programmed keys CRC equals 0x0. Key error can happen due to an incorrect key register writing sequence. It can also occur in case of intrusion detected by tempers, read out protection or RDP regression or mode field change. The OTF Deck is active in D run mode. In D stop or D stop to mode the OTF Deck is frozen and its registers content is maintained. In standby or shutdown mode the OTF Deck is powered down and it must be re-initialized afterward. The OTF Deck module has relationships with the following other modules to SPI interface nested vector interrupt controller, secure firmware install or SFI and root security services with SFI information. For more details on SFI please refer to application note AN4992 about overview of secure firmware install or SFI. For more details and code example of the usage of OTF Deck in encryption and decryption please refer to application note AN5281.