Securing a device with a trusted substrate (2023)

introduction

One of the big challenges in deploying devices at the edge is security. On such devices, we must ensure that the running software has not been tampered with, and we must also assume that malicious physical access to the device is always possible. Is it possible to protect edge devices from such threats with existing software and hardware?

In this blog, we discuss how to secure a device embedded with Trusted Substrate, a BIOS that offers standards-based secure boot and OTA (over-the-air) updates.

Why do we have to trust a device?

The first thing we need to ensure is that the device software (firmware or operating system) cannot be modified without permission. For firmware in the ARM world, this can be done with a "Trusted Root Public Key" or ROTPK and a Level 1 (BL1) bootloader stored in a trusted ROM. With Arm Trusted Firmware for Cortex-A (TF-A), each stage of the bootloader checks the next before executing.

• BL1 is responsible for authenticating BL2
• BL2 is responsible for authenticating all subsequent stages of BL3x until finally execution is handed over to BL33.

On SystemReady devices, BL33 is an EFI boot loader, so EFI can henceforth handle the authentication of the loaded kernel. If you also need to authenticate the filesystem, there are tools someone can use (e.g. dm-verity). At this point we have everything cryptographically verified, so it should be difficult for an attacker to tamper with our system. However, there are still some issues that we need to address. Protection against physical manipulation

The device tree we are using cannot be trusted when loaded externally. We also cannot trust the initramfs we use to load our operating system. You could say that we can solve these problems. For initramfs we can chain it to our kernel and verify it as part of the secure EFI boot process, while for DTB we can provide it as part of the bootloader that is cryptographically verified by BL2.

The biggest problem remains the physical access to the devices. An attacker with direct access to the hardware could completely replace or compromise the flash that contains the secure database used for our EFI keys. In this scenario, you can sign and release a completely different binary and everything appears to be authenticated.

So how do you prevent this from happening?

Protecting your device with Trusted Substrate

Soportes U-BootEFI TCG2-Protocol. Its purpose is to define APIs and provide information e.g. such as whether a Trusted Platform Module (TPM) is present, which PCR (Platform Configuration Record) banks are active, obtaining the Trusted Computing Group (TCG) boot record and hashes, extending PCR, adding events to the TCG boot log, etc .

we made oneIntroduction to TPM in a previous articleHowever, the most interesting features for us are platform configuration recording (PCR) and key sealing.

Large enough to hold cryptographic hashes, PCRs start from zero while being reset only on a system reboot. These can be extended by writing a Secure Hash Algorithm (SHA) hash (typically SHA-1/256/384/512 for TPMv2) to the PCR. The TPM concatenates the new hash with the existing PCR value and another SHA is calculated and now stored in the PCR. This gives us the ability to measure different stages of the boot process. As a result, all measurements are interdependent and changing any (measured) component during the bootstrap flow results in a completely different PCR value.

If the device has internet access, we can perform a "remote certification". In this case, the TPM can send a digital signature of the PCR values ​​to a remote server along with an event log. The remote server can then examine the event log, replay it and verify its validity against the provided PCRs and compare them to a known state of the system configuration stored in the local database to detect tampering.

If internet access is not available, we can encrypt our file system and seal the key securely in the TPM. If any of the measured components change, the TPM never releases the key it can use to decrypt your file system.

Trusted Meta-Substrate is a security-oriented OE layer. It is based on a variety of open source projects, has an upstream first mentality and offers aCompatible with SystemReady IRFirmware with UEFI Secure Boot and Measured Boot enabled by default for all supported hardware. Their goal is to ensure that your device is running the software it was designed to run from the time you turn on your device until you start your operating system.

So how do you get started with Trusted Substrate?

Below is a step-by-step guide to configure UEFI Measured Boot in Socionext DeveloperBox with trusted meta substrate.

Some time ago we explained how to store EFI variables in a RPMB partition of aeMMCplays. There are basically three requirements:

• ON-TEE support
• A working eMMC on U-Boot and Linux
• Upstream submarine compatibility

With an available eMMC, we can also install Microsoft's TPM firmware (orfTPM) and enable metered boot even if your hardware doesn't have a separate TPM. There are many firmware components that need to be compiled for this to work. Just for reference you need

SCP-Firmware TF-A OP-TEE U-Boot EDK2 StandAloneMM the platforms edk2fTPM

You will also need complex instructions on how to create and assemble the picture. Using a trusted metasubstrate makes the whole process trivial. You can create a firmware with:

Git-Clone https://git.codelinaro.org/linaro/dependable-boot/meta-ts.gitcd meta-tskas build ci/synquacer.yml

Update firmware

You can find detailed instructionshere. The tl;dr version is to flip DSW2-7 to activate the serial flasher, open your minicom and use xmodem to send and update the files.

All needed files are in build/tmp/deploy/images/synquacer/

flash escribir cm3 -> Control-A S -> enviar scp_romramfw_release.binflash escribir arm-tf -> Control-A S -> enviar fip_all_arm_tf_optee.binflash rawwrite 0x500000 0x100000 -> Control-A S -> enviar optee/tee-pager_v2.binflash rawwrite 0x200000 0x100000 -> Control-A S -> enviar u-boot.bin

install a distribution

I'm using Fedora in the example here, but since U-Boot versions have supported SystemReady-IR since 2021.04, any COTS distribution should work.

sudo dd if=Fedora-Server-netinst-aarch64-35-1.2.iso of=/dev/sdX bs=128M estado=progreso

Plug your USB stick into a port and power on the board. In the U-Boot console, do the following:

usb reinicar cargar usb 0 $kernel_addr_r efi/boot/BOOTAA64.EFI && bootefi $kernel_addr_r

Since I am using the box in headless mode (has GPU supportknown problems), installing via VNC is a good option to avoid the hassle of the console.

Start the installer and enable VNC

Be sure to encrypt the filesystem with a password, as we'll need it later:

Note that since U-Boot does not support SetVariable at runtime, you will get an error while the installer tries to update the EFI Boot#### variables. This is far from fatal, you can continue with the installation and fix the boot options later.

Once the installation is complete, you will have three partitions: EFI, Boot, and the LUKS-encrypted root.

Reboot your board and stop U-Boot on your console.

nvme scanefidebug boot add -b 0 Fedora nvme 0 EFI/fedora/shimaa64.efiefidebug orden de arranque 0bootefi bootmgr

That should establish itselfLIMEas your first boot option.

fTPM activation

The kernel modules required for Microsoft fTPM are included in the Fedora35 kernel. However, since it relies on OP-TEE to provide RPMB access, you must start the OP-TEE supplicant before injecting the module.

Compiling Optee_client On the target system, get a copy of optee_client, compile and install it. The default installation will end up in /usr/local/sbin (future versions of Fedora will include an optee-client package).

git clone https://github.com/OP-TEE/optee_client.gitcd optee_client && mkdir build && cd buildcmake ../ -DRPMB_EMU=0make -j$(nproc)sudo make install

Enable fTPM on systemd Create /etc/systemd/system/tee-supplicant.service with the following content

[Unit]Description=tee supplicant[Service]User=rootExecStart=tee-supplicantRestart=always[Install]WantedBy=sysinit.target

and activate the service

sudo systemctl habilitar tee-bitter

If you reboot your system now, your TPM firmware should be up and running. You can check the logs with

sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements

seal key

Do you remember when you installed an encrypted file system? Now that the TPM is operational, you can automate the decryption of your root file system and bind the keys to specific PCRs.

Fedora features Clevis, an automated encryption framework that can make your life easier when it comes to key sealing and decrypting. Make sure you install the required packages before you begin

sudo dnf install clevis clevis-luks clevis-dracut clevis-udisks2 clevis-systemdsudo clevis luks bind -d /dev/nvme0n1p3 tpm2 '{"pcr_ids":"7"}'

The use of PCR is describedhere

• PCR0: SRTM, BIOS, host platform extensions, embedded option ROMs and PI controllers
• PCR1: Host platform configuration
• PCR2: UEFI driver and application code
• PCR3: UEFI driver and application data and settings
• PCR4: UEFI boot manager code (usually the MBR) and boot attempts
• PCR5: Boot manager code data and configuration (to use the boot manager code) and partition table/GPT
• PCR6: Manufacturer-specific for the host platform
• PCR7: Secure Boot Policy
• PCR8-15: Defined for use by the static operating system
• PCR16: Troubleshooting
• PCR23: Application support

You can use any PCR that you think is appropriate for your device's security, but the most scalable for us is PCR7, which contains the EFI keys and UEFI SecureBoot status. Such a measurement would render physical attacks on EFI variable storage useless: changing the keys would return a different value for PCR7. We can also use the TPM to measure the initramfs and DTBs we load onto the device and provide the guarantees we need for those files.

Agregar tee-supplicant a su initramfs

As I mentioned, fTPM relies on supplicant op-tee for RPMB access. So the missing piece of the puzzle to access your TPM, open its key and decrypt the filesystem is to create an initramfs with the necessary modules and the tee-supplicant.

Create the directory /usr/lib/dracut/modules.d/60tee-supplicant/, copy the previously created /etc/systemd/system/tee-supplicant.service and add a module-setup.sh file with the add the following content:

#!/usr/bin/bashtest() {require_binaries /usr/local/sbin/tee-bitter|| hand back1hand back0}it depends() { hand back0}install on pc() {inst /usr/local/sbin/te-bitter /sbin/tee-bitter inst"$moddir/tee-supplicant.service" "$systemdsystemunitdir/tee-supplicant.service" $SISTEMACTL -q --Root "is $initial"add-quiere cryptsetup.target tee-supplicant.service}Installer-Kernel() { only hosts=''Instagram-Mods=driver/char/tpm instmodsTeedecided}Now you can rebuild your initramfs withsudoDracut--addFork Pin-tpm2--addyou supplicant--Force

If everything is set up correctly, you should see something similar on your screen

Welcome to Fedora Linux 35 (Server Edition) dracut-055-6.fc35 (Initramfs)!<snip>\[ OK ] Target base system reached. Starting cryptography Setu…8ff0-43f6-9484-b4f16ff43093...\[ OK ] Started tee supplicant. Enter the Samsung SSD 960 EVO 250GB drive passphrase (luks-5fe9fed9-8ff0-43f6-9484-b4f16ff43093): but this time you don't need to enter a password!

Future work

The distributions use an intermediate boot loader called SHIM before loading GRUB and eventually your operating system. SHIM exists primarily to bridge the signing authority gap between commercial firmware implementation: Microsoft Keys and distributions. SHIM is responsible for verifying GRUB, which in turn is responsible for verifying your operating system kernel. This is useful for large servers and commercial hardware with different hardware combinations.

However, this adds unnecessary complexity and a larger attack surface on small, purpose-built devices. In a follow-up post, we examine directly booting the kernel and enabling UEFI Secure Boot with Trusted Substrate and theLEDGE-Referenzplattform.

To learn more about Trusted Substrate and how you can get involved, visitour project page.