Grapeboard by Scalys — new word in IoT security



The «Internet Of Things» is an ever expanding concept with more and more devices connected to the Internet. For a lot of these devices security is a secondary concern, resulting in vast amounts of «things» which are insecure. These insecure «things» become the target for large scale brute force attacks to crack login credentials. If a remote connection is established a virus can be downloaded to the device which enables it to be used for DDoS attacks.

The company from Netherlands named Scalys [1] aims to secure these «things» with their new product — Grapeboard [2]. Grapeboard is a System-on-Chip (in further SoC) module that features a layer of hardware security. This hardware security consists of Secure Boot, Trusted Execution Environments, Cryptographic accelerators and more. Since this hardware security layer is not designed by Scalys itself, enabling these functions required some work.

This article consists of an explanation of how the different security modules work. And a manual is written about how to enable the different features. Enabling these hardware security layers ensures a high level of security, unmatched by other SoCs.

1. Introduction to Secure Boot

Secure boot in short is booting only software images that are verified to be from a trusted source. This means that even during boot, before any antivirus software or similar programs are running, the device has protection to malicious attacks. Secure boot uses a chain of trust where each node (piece of software) is validated by the previous node. The first node is called the root of trust and cannot be verified by a previous node, therefore this node has to be trusted.

With secure boot the first node is a small piece of software, which is hard coded on a ROM on the SoC and is called the Internal Secure Boot Code (ISBC). This software is programmed by NXP [3] inside the SoC and is unchangeable.

The process of performing a secure boot and the preparation steps are explained below.

This article focuses on secure boot using U-Boot [4] and Linux [5] since that is originally supported by the Grapeboard user guide. Other combinations are possible as well.

Secure boot is the process of booting an image only if the authenticity can be verified. This means, that only images uploaded by the owner of the device are booted and no malicious software is able to run.

Secure boot uses a chain of trust to start from a small piece of software in a ROM to eventually validate the linux kernel which is used during run time. Validating the nodes in the chain of trust is done with a public/private key pair, where the software images are signed with the private key. Validating the signatures is done with the public key which has to be bound to the device. If the public key is not bound to the device, attackers can simply provide another key and boot their own images. On the LS1012 [6] processor this bounding is done by permanently burning fuses inside the SoC thereby storing a hash of the public key. These fuses are located in the Security Fuse Processor (SFP) and are represented by the Fuse Box in Figure 2. A hash is stored instead of the key itself to save space.

All the images that are booted need to be signed, how signing an image works is explained in section 2. It is also graphically explained in the left part of Figure 2.

In Figure 1 the state machine of the Security Monitor (SecMon) can be seen. The SecMon is part of the security engine which implements more security features such as block encryption algorithms, stream cipher algorithms, hashing algorithms, public key algorithms, run-time integrity checking, and a hardware random number generator.

After successful completion of secure boot, the SecMon state machine is in the Trusted state. From this state a software call can be made which switches the processor to the Secure State. If secure boot fails, the processor is either in the Fail state or in the Non-secure state as can be seen in Figure 1.1.

Fig. 1. The Security Monitor state machine

Fig. 2. Secure boot process

2. Signing an image

Signing an image is done to verify the authenticity and integrity of that image. When an image is signed, a header is created of which the structure can be seen in Figure 1.3 and the process is visualized in the left part of Figure 1.2.

The most important part of this process is the calculation of a hash over the image to be signed. This hash ensures the integrity of the system image, since a small alteration to the image leads to a totally different hash. This hash is then encrypted with the private key. Since something that is encrypted with the private key can only be decrypted with the corresponding public key authenticity is guaranteed because the encrypting instance must be the holder of the private key.

The signature (encrypted hash), public key and some administration of what is where is stored in a header which is used by the secure boot process. The public key is stored in the header as the actual key is not present in the SFP.

3. Secure Boot Process

Fig. 3. Structure of header image appended

The boot process consists of multiple phases. At first the U-Boot image is verified in the ISBC phase. After that the Primary Protected Application (PPA) header is parsed and the image verified. After that further images such as the kernel and device tree can be verified by calls to esbc_validate. The boot flow when secure boot is enabled is described here.

3.1 Pre-Boot phase

The processor is not booted yet and all the actions are performed by the Pre-Boot Loader (PBL). The capabilities of the PBL are limited.

The Intent To Secure (ITS) bit determines if secure boot is attempted or not, so this bit is checked first. This bit can either be set in the Reset Configuration Word (RCW) when in the developing phase or burned in the SFP if the device is to be deployed in the field. A set ITS bit disables interfaces and changes memory permissions until secure software is booted.

The PBL reads the RCW and configures registers accordingly. Then a command file is read, of which the location is determined by the RCW. This command file contains (among others) a command to store a pointer to the External Secure Boot Code (ESBC) header in the ESBC Pointer Register in the SoC. In this case this points to a header belonging to the U-Boot image.

After the PBL has completed its operations specified in the command file the PBL is disabled and the next phase begins.

3.2 ISBC phase

In this phase, CPU0 actually begins booting. This is done by executing instructions from a hardwired location within the internal ROM. These instructions are code developed by NXP and are known as the ISBC. This code is not changeable, and the only input is the value in the ESBC Pointer Register, assuming the Super Root Key Hash (SRKH) and ITS are burned in the SFP. This phase consists of a few actions of which the relevant actions are summarized:

1. ESBC pointer read CPU0 reads the contents of the word indicated by the ESBC pointer register. This is the first word of the Command Sequence File (CSF) Header and should be a barker code.
2. CSF Header parsing and public key check. The CSF Header is parsed to find the public key associated with the image and the address of the image itself, see Figure 1.3. The hash of the key associated with the image is calculated and compared with the hash stored in the SFP to verify that a valid key is used.
3. Signature validation. The validated public key is used to decrypt the signature associated with the image which results in the hash calculated when signing the image. The hash of the system image is also calculated in the crypto hardware on the SoC and compared to the decrypted hash.
4. Continue to ESBC phase. If the hashes are the same, the image is booted and booting continues to the ESBC phase, if not the CPU halts.

3.3 ESBC phase

After the ISBC is done verifying the U-Boot image it is booted.

If the U-Boot binary is built with the secure boot flag enabled, again some images are verified. At first the PPA header is loaded and parsed to validate the PPA image. The location of the header is adjustable in the U-Boot configuration menu before building.

After that the kernel and device tree are booted, the steps are given below:

1. Load image. Load the image to be verified to the RAM, this can be from the flash or from the SD card.
2. Load Header. Load the header of the image to the RAM, this too can be from flash or SD card.
3. Validate image. A call to esbc_validate with the header address as argument. This parses the header to find the image address and validates the image, the same as in section 1.3.2. This means that the image must be loaded at the memory address specified in the header.
4. Continue. Either continue in case of successful validation of the image or a call to esbc_halt if the verification fails. A call to esbc_halt places the core in a spin loop, preventing it from booting any further.

References:

1. Scalys. Home page. URL https://scalys.com.
2. Grapeboard. URL https://grapeboard.com.
3. NXP semiconductors website. URL https://nxp.com.
4. U-boot bootloader. URL https://en.wikipedia.org/wiki/Das_U-Boot.
5. Linux. URL https://github.com/torvalds/linux
6. NXP. Qoriq ls1012a reference manual, January 2018. URL https://www.nxp.com/docs/en/ reference-manual/LS1012ARM.pdf.