WinPath + WanStaX + TPM = Secure + Trusted Boot

How to Create a Secure and Trusted Environment

In today’s world, cyber attacks are more common than most people think, ranging from Denial of Service (DoS) attacks, malware spying on individuals and money extortion via ransomware to taking control of embedded Internet of Things (IoT) devices.

Preventing these is an ongoing battle, with the perpetrators using all means to ensure their malware is hard to remove, including updating firmware on motherboards and IoT devices. By taking control of the firmware, malware has control of the device from the instant it is turned on and it is a lot more difficult to detect and remove.

Telecommunications Original Equipment Manufacturers (OEMs) need to know their products cannot be tampered with in the network since having one of their devices compromised in the core or edge of the network could have disastrous results.

On power up of a device, the initial software to run (boot) is read from a flash device on the board. This is the first piece of software to run on the board and it sets up the hardware for the follow-on software, either a second stage bootloader or an operating system like Linux®. Ensuring the authenticity of the firmware that is loaded is key to the integrity of the system.

One solution is to use secure boot. The following will show how a Microchip WinPath Network Processor + WanStaX + a Trusted Platform Module (TPM) can provide a secure and trusted boot environment.

Secure Boot

Secure boot requires some small changes in the hardware design to ensure that the first stage firmware image that is loaded into the device at the factory cannot be changed. These images must be stored on a write protected Flash device or Read-Only Memory (ROM). The WinPath family of devices has the ability to boot from NOR flash or via I²C, and both of these technologies can be write protected so they cannot be updated via software.

Hardware write-protected sectors in NOR Flash, write-protected I²C devices, ROMs or one-time programmable I²C devices all prevent updating the firmware or tampering with it while it is installed in the network.

Signing an Image

Using standard cryptography tools, a public/private 2048-bit RSA key pair is generated. The private key (which the OEM must ensure it is kept secret) is used with a SHA-512 hash to sign all images that will be loaded and executed on the device (see Figure 1). The generated signature for the image is appended to the original image so it is easy to detect and compare. The public key can be freely shared with anyone and published if required because it can only be used to verify that an image is valid for running.

Figure 1: Signing an Image

WanStaX is currently built to produce a small (<64k) first-stage bootloader which is loaded into an I²C device with hardware write protect. The WinPath is configured in hardware to boot from this I²C device. This image also includes the public key and is used to validate every second stage bootloader image it loads before it will execute it.

Figure 2: Validating an Image

Validating an Image

The first stage bootloader will attempt to boot the second stage bootloader by checking the signature of each in turn (see Figure 2); failing to provide a valid signature on this or the backup images will ensure the recovery mechanism is invoked to download the image over the local management console port, again validating any signature before executing. Thus, it is not possible to load any image on the hardware other than OEM-signed images.

Boot Process

Secure boot can be enhanced with the addition of a Trusted Platform Module (TPM). This module can provide a cryptographic assertation as to the root of trust of the boot process. See Figure 3.

The TPM provides, among other features, a bank of Platform Configuration Registers (PCRs)—these are a set of one-way hashes (i.e., hashes that can be added to, but cannot be cleared). Each hash is known as a measurement. Using this building block, the WanStaX boot loaders can measure the variable aspects of the system (e.g., FLASH variables, Kernel parameters, images) to produce a signature trail of the boot process.

As WanStaX initializes the TPM module (this can only be done once after power-on of the TPM) as part of the first-stage bootloader, the TPM is known to be secure and its measurements can be trusted. Immediately after initialization, the first-stage loader measures itself and puts its hash into the first PCR register, thus providing the first cryptographic marker of the boot process.

Figure 3: Boot Process

When the second-stage image is loaded and its signature validated, a measurement will be made of the image and added to a second PCR register. As a result, before the second stage loader has started, WanStaX will have measured both the first and second stage loaders and stored these in the TPM module.

Once the WanStaX second stage loader has started, it will check the signature on the active/backup kernel images, and if valid, will:

• Measure the kernel parameters that will be passed to the kernel image
• Measure the environment variables that are stored in flash
• Measure the kernel image to be booted
• Execute the kernel image

At this point, all the variable aspects of the system (anything that can be changed by a user of the system) have been measured and, when combined with the WanStaX kernel with its inbuilt root filesystem, ensure that the booting kernel can validate if anything has changed. Using this assertation, the kernel can use the TPM module to “wrap/unwrap” keys/data. This data could be used to store the key for a secure area of flash that is mounted with cryptoFS.

TPM wrapping/unwrapping uses the TPM module to encrypt/decrypt a blob of data using a combination of selected internal PCR registers and its internal (unique per TPM device) master wrapping key (storage root key). Once encrypted using the TPM module, the blob of encrypted data can only be decrypted on the platform that encrypted it. The blob, if small enough, can be stored in the TPM module itself or on a Flash disk for use on the next boot.

Any change to images, or even a single character change in an environment variable, will render the encrypted blob unwrapable.

Conclusion

Using some minor changes to schematic design and the addition of a TPM, all WinPath designs, with WanStaX as the glue, can provide both a secure and trusted platform when running in a telecommunications network. Taurus’ XS-3500 PCI Mezzanine Card is an example of “WinPath + WanStaX + TPM” implementation of networking acceleration card for use in the Smart Grid environment.

You can find more information about WanStaX on the WanStaX overview page, Facebook or Civica's website.