Trustworthiness for embedded nodes is a critical point when involved devices are resources-constrained and remotely installed. In particular, the software execution environment is jeopardized by physical attacks aimed to extract secrets:

• Key generation and storage have to be guaranteed in a trusted manner;

• Source of keys has to be unpredictable and random.

Physically Unclonable Functions are physical entities that maps a set of challenges to a set of response forming a set of challenge-response pairs (CPRs). A PUF exploits random imperfections introduced indirectly into the device during its manufacturing process. Its feature can be exploited to generate response that are:

• Unique for each device where the PUF is implemented,
• Unclonable,
• Unpredictable,
• Tamper-evident.

For this reasons, PUFs represent a breakthrough for silicon devices as they can be exploited as secure primitive.  Silicon PUF term indicates PUF characterized by a behavior physically imprinted into integrated circuits (ICs) in which PUFs are embedded. 

In this work, using a specific Silicon PUF available into most 

In this paper we illustrate a

pragmatic key extraction and management methodology using a specific Silicon PUF available on modern microcontroller architectures, with a real application on the STM32F7 microcontroller family, in which extracted keys are involved for remote update of ciphered software images.

Static Random Access Memory (SRAM) PUF

One of the most investigating PUF in the literature is the Static Random Access Memory (SRAM) PUF, as many ICs inherently embed them. SRAM PUF exploits the pattern generated by SRAM cells each time when the IC is powered-up, since by design they are not initialized with the same state. In particular, the SRAM cell keeps the unstable state only when it is powered-up. Therefore the SRAM PUF is based on the extraction of a bit-sequence stored into a SRAM, which has been powered-up without any writing operations on it. This extracted bit-sequence has attractive properties for secure purposes. SRAM PUF is strong against modelling attacks but its main security drawback is its level access: specific areas of SRAM must be shielded during common-purpose operations.

SRAM PUF response main property is its noisy nature: bit-sequence extracted from memory cells changes by a certain percentage at each power-up. For this reason post-processing techniques can be introduced in order to produce a PUF-generated key or hard-reliable key material for security applications. 

Key Extraction from Microcontrollers

In information theory, entropy is the measure of uncertainty associated with a random variable. In terms of Cryptography, entropy must be supplied by the cipher for injection into the plaintext of a message so as to neutralise the amount of structure that is present in the unsecure plaintext message. Therefore, in order to use SRAM bits as key material, their entropy should be as high as possible. We estimate SRAM bit entropy evaluating an upper bound that represents the worst-case measure of uncertainty for a random variable.  In order to address this aim, a good choice is the adoption of a fuzzy extraction algorithm as post-processing technique. The aim of fuzzy extractor is to give back a reliable key material. 

Fuzzy extractor is mainly composed of two primitives, namely information reconciliation and privacy amplification. Both rely on helper data W generated during an enrollment phase, shown into figure above on the right. It involves a generation procedure, which takes as input a reference PUF response R  and it outputs a helper data W  and a key K. Enrollment phase must be carried out into a trusted environment.

Helper Data is required during the key reconstruction phase, shown into figure above on the left. During this phase key K is rebuilt using on a noisy PUF response R'.  K is a key useful for cryptographic applications generated from R the extracted R with a privacy amplification technique. An example of privacy amplification primitive is employed by means of a cryptographic hash function. This procedure takes blocks of bits as input, and produces a digest output used as the key K .

The Encode and Decode blocks illustrated into figures above are related to an error correction code. It should be noted that the helper data W does not have to be stored secretly, but it can be exchanged publicly. 

Microcontrollers contain a processor core, programmable input/output peripherals, storage memory and, typically, a limited amount of volatile memory. Most microcontrollers adopt SRAM as volatile memory, which can be exploited as source bits for PUF responses, hence conguring the microcontroller to work in security related applications. However, microcontrollers are resource constrained devices, thus the key extraction mechanism from SRAM must cope with the few available resources. In particular, typical resource constraints refer to processor performance, storage space, and memory availability.

Processor performance is crucial for applications characterized by execution time constraints. Indeed, most microcontrollers cannot benefit from the ultimate processor architectural improvements, such as caching mechanisms, out-of-order execution, higher clock frequencies, and so on, since they determine higher chip area, power consumption and cost per unit. With regard to the storage space, it is typically intended as the non-volatile memory from which the processor fetches the instructions that have to be executed. Typically, the storage space is realized adopting flash memories. In order to keep low the cost per unit, the embedded flash memory is designed with a limited capability.
Since the key extraction procedure has to be executed in a context which may be not completely isolated, a further challenge is to avoid the alteration of PUF SRAM bits exploited as key material. Indeed, a portion of the available SRAM has to be reserved, i.e. to be protected by potential overwrites. The fullment of this constraint is mandatory, and it lowers the remaining available SRAM resource. The design of key extractor follows the logic structure shown above. 

 It is important to note that the key is generated on demand and only at the device start-up. Indeed, when the device is powered-off, it is not possible to extract any information related to the key. Moreover, physical attacks aimed to obtain the key are expensive and may alter the PUF response itself, due to the PUF anti tampering property.

A case of Study: Secure Remote Software Updates

Basing on the concepts previously presented we illustrate the components required to build a chain of trust on microcontrollers, by means of secure boot procedure. Indeed, such procedure may be considered as the root of trust, which allows the formation of a chain of trust that can be used to implement security applications, such as remote secure software updates (RSSU).

In order to build a secure boot procedure, a boot loader that extracts a key that can be used in security applications is required. In particular, the boot procedure has to be stored in a protected non-volatile memory, as it must be not possible to alter or bypass the boot instructions. Moreover, during the execution, the boot procedure can only operate with temporary data residing into SRAM, hence it must not save any data into the non-volatile memory, as it can leak some critical information regarding the key extraction. Based on the same motivation, once the boot procedure has been executed, the SRAM has to be cleaned. 

Once the boot loader has been configured as root of trust, it can be used to implement an RSSU scheme. The boot loader is configured to securely reads an external software from a configuration interface, and to store it into the volatile or non-volatile memory. However, the RSSU scheme requires read protection of the source code of the software. Therefore, external accesses (write/read) to both volatile and non-volatile memory have to be forbidden.

We implement the RSSU scheme using an STM32F7 Microcontroller. The crucial requirement is to configurethe boot loader as root of trust. To this aim, STM32F7 microcontrollers offer some features that allows to build a secure perimeter, in which the content can not be externally altered or accessed. In particular, the  flash memory is split in sectors of different sizes, and the content of each sector can be protected by enabling a read protection. However, SRAM, and in particular flash sectors, can be still updated under the control of the user code itself. Furthermore, by enabling read protection, the microcontroller is forced to boot only from thefirst address of the  flash, hence from the programmed boot loader. Using these protections, we configure an inaccessible perimeter as shown into the figure below. 

We use such scheme to design a secure boot loader that includes 3 phases, shown into next figure. During the first phase, the key is extracted by means of the fuzzy extractor. In the second phase, the boot loader reads an encrypted user software application from a configuration interface, and on-the-fly deciphers and verifies its content using the key extracted in the first step. Once the software has been deciphered, the boot loader programs it into the flash or into the SRAM. It is important to note that the software code is stored as plain-text, but it can not be read since it resides in the secure perimeter (previous figure).

Then in the third phase, the boot loader cleans the SRAM content, and prepares the hardware to load the user software, such as the relocation the the exception table to the memory address used by the user code, and so on. At the end, a jump to the entry point of the user code is performed. In this scheme, the second phase can be skipped if the user code has been already programmed inside the  flash. To this aim, the boot loader may store some information inside the  flash in order to store and then retrieve the boot configuration.

We implemented the RSSU scheme using a 128-bits key, extracted by a fuzzy extractor that adopts Reed-Muller [128, 8, 63] as error correction code and Spongent as hash function for privacy amplification.

The user code that has to be deciphered is provided in either Intel HEX or ELF format, and, once decrypted, is properly interpreted by the boot loader, and then programmed into the flash or the SRAM. In this regard, during compilation time, the software application has to be mapped into microcontroller memory such thatit does not use the first  flash sectors reserved to the boot loader or the SRAM locations where the PUF response resides.