Author: Giancarlo Parodi, Principal Product Marketing Engineer, Renesas Electronics
Translation: Samantha Navarro
Today, the memory requirements of embedded systems are constantly increasing due to increasing connectivity functionality and application-level complexity. Many microcontrollers on the market offer a storage density in the range of a few megabytes, which only a decade ago would have been considered more than sufficient and future-proof for the average application. On the other hand, the integration of even more non-volatile memory requires a fairly large silicon area, which significantly affects the cost of the product. A suitable alternative solution is to use external memory, which can be purchased in large quantities at comparatively lower prices and with various density options, typically ranging from a few to tens of megabytes.
The external storage solution is suitable not only for storing application data but also application code, thus eliminating any concerns about the vendor's roadmap to be able to meet future needs. On the other hand, there are some additional aspects to consider, such as the performance of code running from external storage and how to protect application code from cloning or modification.
For the first problem, the solution is to use memory with a wide interface that increases the physical performance of the serial lines. Memories with an octal interface offer one of the best options in terms of balance between the number of I/O connections and the 2x performance improvement achievable compared to the legacy quad-spi interface. Typically, these modern memories also support slightly higher operating frequencies, so the performance improvement is even more significant.
Protecting memory contents requires the use of cryptography techniques to encrypt the code, as otherwise it would be easy for an attacker to connect to the memory and read the stored information with little effort. To avoid latencies in the decryption process, it is necessary to use design solutions that are fast and run inline with the instruction fetch process, i.e. transparent from the CPU perspective. Renesas’ latest MCUs, such as the RA8x1 series, implement an architecture called “decoding on the fly” (DOTF) that serves exactly this purpose. A conceptual representation of the solution can be seen in Figure 1.
Figure 1. DOTF architecture
The principle is quite simple and is based on the AES encryption/decryption standard, using the counter (CTR) mode as specified in NIST SP800-38A. The working principle of the CTR mode is shown in Figure 2.
Figure 2. CTR mode (source: NIST SP800-38A)
In CTR mode, a set of counters is used as input to a block cipher function, to generate a secret output which is then combined with the plaintext (or ciphertext) to encrypt (or decrypt) the message data. The sequence of counters must be chosen such that each input block in the set is different and unique. This requirement holds for all "messages" (i.e. data items) that are encrypted using the same key.
An interesting property of CTR mode is that the encryption functions associated with the counter can be performed in advance independently of each other and do not need to wait for the data block to become available. This helps reduce latency while reading encrypted data from octal memory as the output block generation can be performed in parallel. Also, a plaintext block can be retrieved independently of any other block, which is convenient for fetching program data as depending on the program flow, the processor may request to read code at non-sequential address locations.
The parameters used to define the counters must be carefully chosen to ensure their uniqueness. An AES block is 16 bytes (128 bits) in size; therefore, the counter must also be 128 bits wide. Each encrypted block in memory is also 16-byte aligned, and a concatenation of a seed value and the memory address can be used to create a unique counter.
The initial value is essentially a “nonce” (a unique random number used once) and the address of the encrypted block being read has all 4 LSBs masked, to create the counter value according to the following scheme: counter[127:0] = InitialValue[127:28] || (MemoryAddress[31:4] >> 4).
The implementation includes a couple of additional interesting features that go a long way in making it a flexible and easy-to-use solution. First, the application can define an address boundary for which on-the-fly decryption will be used or otherwise bypassed, as shown in Figure 3.
Figure 3. DOTF limits
This is very convenient if the application wants to split the contents of the flash memory between code and other data, where the code is decrypted on the fly and the data is simply read without decryption. The latter also allows the application to use another encryption key or mode for the data and avoids sharing the application code encryption/decryption key for multiple purposes.
As for DOTF area alignment, although the AES encryption standard implies a minimum alignment of 16 bytes, given the typical organization of a flash memory, the boundary will be placed at a sector or block size (the minimum size of the flash drive that can be erased during programming). In implementation, the DOTF boundary can be set to 4 KB address alignment; in fact, the application will avoid having a memory block storing both DOTF and non-DOTF data anyway, which would unnecessarily complicate field upgrades and factory programming. The flash memory device is linearly mapped to the MCU's addressable space, and the Octa IP takes care of issuing the appropriate read commands; this is typically referred to as XiP (Execution in Place) mode of operation. For the encrypted area, any access to the requested 16-byte blocks can be efficiently performed by issuing the required address once and then reading the data continuously, thus minimizing the OctaSPI protocol overhead.
Another important aspect is how the decryption key is handled and loaded. In devices supporting DOTF, there is a dedicated AES engine implemented within the IP, but the key for the decryption process is loaded via a private bus connection to the Renesas Secure IP – this prevents leakage of the key value via the MCU’s internal bus interconnect. Furthermore, keys handled by the Renesas Secure IP are encrypted, so they can be securely stored in memory without confidentiality and integrity issues. The DOTF engine supports 128-, 192-, and 256-bit key sizes for maximum flexibility and future-proof options, and there is no limit to the number of different keys that can be used to decrypt a specific image. The latter implies that any firmware update can use a different key if desired, and there is no need to share the same key between different MCUs. Preparation of the new image can be conveniently performed offline on a secure host, before either sending the image update to a device in the field or sending the encrypted image to a contract manufacturer for programming. The initial decryption key, or a “key update key” (to update the decryption key in the field) can be securely injected into the MCU during production. Injected keys, whether in the field or at the production stage, are always tied to the specific MCU, so that cloning is prevented.
Additionally, the IP provides countermeasures to protect against side-channel attacks.
The entire runtime operation is performed transparently by the hardware, and the provided software drivers take care of initializing and loading the parameters for the DOTF (initial value, bounds) operation and the key, before the operation can begin.
All MCUs requiring memory expandability and complex application requirements will benefit from this type of solution, which ensures that the MCU developer will enjoy a solid application roadmap while protecting the software investment. For more information on the RA MCU family, please visit www.renesas.com/ra.
