Nykyään sulautettujen järjestelmien muistivaatimukset kasvavat jatkuvasti lisääntyvän yhdistettävyystoiminnallisuuden ja sovellustason monimutkaisuuden vuoksi. Monet markkinoilla olevat mikro-ohjaimet tarjoavat tallennuskapasiteettia muutamien megatavujen verran, mikä olisi vielä vuosikymmen sitten katsottu enemmän kuin riittäväksi ja tulevaisuuden kannalta varmaksi ratkaisuksi tavallisiin sovelluksiin. Toisaalta vielä suuremman haihtumattoman muistin integrointi vaatii huomattavan suuren piipinta-alan, mikä vaikuttaa merkittävästi tuotteen hintaan.

Sopiva vaihtoehtoinen ratkaisu on käyttää ulkoista muistia, jota voidaan hankkia suuremmissa määrissä selvästi edullisempaan hintaan ja useilla eri kapasiteettivaihtoehdoilla – yleensä muutamasta megatavusta satoihin megatavuihin.

Ulkoisen muistin käyttö soveltuu paitsi sovellusdatan tallentamiseen, myös sovelluskoodin säilyttämiseen, jolloin ei tarvitse huolehtia valmistajan tuotekehityssuunnitelmista tai siitä, pystyykö se vastaamaan tuleviin tarpeisiin. Tämä tuo mukanaan joitakin lisähuomioita, kuten ulkoisesta muistista suoritettavan koodin suorituskyvyn sekä sovelluskoodin suojaamisen kopioinnilta tai muokkaukselta.

Ensimmäiseen ongelmaan ratkaisu on käyttää laajaväyläistä muistia, joka kasvattaa sarjaviestilinjojen fyysistä tiedonsiirtokapasiteettia. Nämä ratkaisut tarjoavat yhden parhaista vaihtoehdoista kompromissina IO-yhteyksien määrän ja saavutettavan suorituskyvyn välillä, tarjoten jopa kaksinkertaisen suorituskyvyn verrattuna perinteiseen Quad-SPI-väylään. Yleensä tällaiset modernit muistit tukevat myös hieman korkeampia käyttökellotaajuuksia, mikä parantaa suorituskykyä entisestään.

Muistin sisällön suojaaminen edellyttää kryptografisten tekniikoiden käyttöä koodin salaamiseksi, sillä muuten hyökkääjän olisi helppo yhdistää muistipiiriin ja lukea tallennettu sisältö pienellä vaivalla. Jotta salauksen purku ei aiheuttaisi viiveitä, on käytettävä suunnitteluratkaisuja, jotka toimivat nopeasti ja suoraan ohjeiden hakuprosessin yhteydessä – toisin sanoen täysin läpinäkyvästi suorittimen näkökulmasta.

Artikkeli löytyy uusimmasta ETNdigi-lehdestä täältä. Alla se on kokonaisuudessaan.

PROTECT YOUR IP WITH EXTERNAL MEMORY

Giancarlo Parodi, Renesas Electronics

Many microcontrollers on the market provide storage density in the range of few Megabytes, which does impact the cost of the product significantly. A suitable alternative solution is using external memory, which can be purchased in volumes at comparably lower prices and with several densities’ options, typically starting from few to hundreds of Megabytes.

Nowadays, embedded systems are constantly growing their memory requirements because of increasing connectivity functionality and application-level complexity. Many microcontrollers on the market provide storage density in the range of a few Megabytes, which only a decade ago would have been regarded as more than sufficient and future-proof for the average application. On the other hand, integrating even more non-volatile memory requires quite a large silicon area, impacting the cost of the product significantly. A suitable alternative solution is using external memory, which can be purchased in volumes at comparably lower prices and with several density options, typically starting from few to hundreds of Megabytes.

The external memory solution is suitable not only for holding application data but also for storing application code, therefore removing any concern about the supplier roadmap to be able to fulfill future needs. On the other hand, some additional aspects must be taken into consideration like the performance of the code executing from the external memory, and how to protect the application code from cloning or modification.

For the first problem, the solution is to use a memory with a wide interface which increases the physical throughput for the serial lines. Memories with an octal interface provide one of the best choices in terms of tradeoff between the number of IO connections and the achievable 2x throughput improvement compared to the legacy Quad-SPI interface. Normally such modern memories also support slightly higher operating frequencies so that the performance improvement is even more significant.

Protecting the content of the memory requires the use of cryptographic techniques to encrypt the code, since otherwise it would be easy for an attacker to connect to the memory and read out the stored information with small effort. To avoid latencies for the decryption process it is necessary to use design solutions that are fast and executed in line with the instruction fetching process—in other words, transparent from the CPU perspective.

The latest Renesas MCUs like the RA8x1 series implement a so-called ‘decryption on the fly’ (DOTF) architecture which serves exactly this purpose. A conceptual representation of the solution can be seen in Figure 1.

The principle is quite simple and based on the AES encryption/decryption standard, using counter mode (CTR) as specified in NIST SP800-38A. The principle of CTR mode operation is shown in Figure 2.

In CTR mode, a set of counters are used as input to a block cipher function, to generate a secret output which is then exclusive-ORed with the plaintext (or ciphertext) to encrypt (or decrypt) the message data. The sequence of counters must be chosen so that every input block in the set is unique. This requirement is valid for all ‘messages’ (i.e. data items) which are encrypted using the same key.

One nice property of CTR mode is that the cipher functions associated with the counter can be performed upfront independently from each other, and do not need to wait for the data block to be available. This helps to reduce latency while reading out the encrypted data from the octa memory, since the generation of the output block can be done in parallel. Also, a certain plaintext block can be recovered independently from any other block, which is convenient for fetching program data, since depending on the program flow the processor might request to read code at non-sequential address locations.

Figure 1. DOTF architecture.

The parameters used to define the counters need to be chosen carefully to ensure their uniqueness. An AES block is 16 bytes (128 bits) in size; therefore, the counter must be also 128 bits wide. Every encrypted block in memory is aligned to 16 bytes too, and to create a unique counter a concatenation of an initial value and the memory address can be used.

Figure 2 - CTR mode (source: NIST SP800-38A).

The initial value is essentially a nonce (unique, random number used once) and the address of the encrypted block being read has the 4 LSBs masked, to create the counter value according to the following scheme: counter [127:0] = InitialValue [127:28] || (MemoryAddress [31:4] >> 4).

There are a couple of further interesting features in the implementation which are very useful to make it a flexible and user-friendly solution. First, the application can define an address boundary for which the decryption on the fly will be used, or otherwise bypassed, as shown in Figure 3.

This makes it very convenient if the application wants to partition the flash contents between code and other data, where the code gets decrypted on the fly and the data gets simply read without decrypting. The latter also allows the application to use another key or encryption mode for the data and avoids sharing the application code encryption/decryption key for multiple purposes.

As for the alignment of the DOTF area, even though the AES encryption standard implies a minimum alignment of 16 bytes. Given the typical organization of a flash memory, the boundary should rather be placed on a sector or block size (the minimum flash unit size which can be erased while programming). In the implementation, the DOTF boundary is configurable to 4KB address alignment; in fact the application shall anyway avoid having a memory block storing both DOTF and non-DOTF data, which would make in-field-updates and factory programming unnecessarily complicated.

The flash memory device is mapped linearly into the addressable space of the MCU, and the Octa IP takes care of issuing the appropriate read commands, this is typically called XiP (execute-in-place) operation mode. For the encrypted area any access to the requested 16-byte blocks can be done efficiently by issuing one time the required address, and then reading the data continuously, thereby reducing the OctaSPI protocol overhead to a minimum. 

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 gets loaded over a private bus connection to the Renesas secure IP; this avoids leaking the key value over the internal MCU bus interconnect. Additionally, the keys handled by the Renesas secure IP are themselves encrypted, so these can be stored safely in memory without confidentiality and integrity concerns.

Figure 3 - DOTF boundaries.

The DOTF engine supports 128-, 192- and 256-bit size keys for maximum flexibility and future-proof choices, and there is no limit on the number of different keys which 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. Preparing the new image can be conveniently done offline on a secure host, before 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” (for updating the decryption key in the field) can be injected securely in the MCU during production. Injected keys, whether in the field or at production stage, are always bound to the specific MCU, so that cloning is prevented.

Furthermore, the IP provides countermeasures to protect against side channel attacks. All runtime operation is performed transparently by the hardware, and the provided software drivers take care to initialize and load the parameters for the DOTF operation (initial value, boundaries) and the key, before operation can start.

All MCUs which require memory expandability and complex application requirements will benefit from such kind of solution, which ensures that the MCU developer will benefit from a solid application roadmap while also protecting the software investment.

For more information on the RA MCU family, please visit www.renesas.com/ra.