Securing a device with a trusted substrate (2023)


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.

(Video) LVC21-300K2 Trusted Substrate Panel

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 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
(Video) Finfloor's Good to Great Series // Glue Down Substrates

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

Securing a device with a trusted substrate (1)

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

Securing a device with a trusted substrate (2)

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.

Securing a device with a trusted substrate (3)

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.

(Video) Network security for Substrate | Substrate Seminar

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 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]

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
(Video) Reinstall Mobile Substrate & Substrate Safe mode to Fix iOS 7 Tweaks - iPhone Hacks

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 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 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!
(Video) Reinstall Mobile Substrate to make tweaks and apps work on iOS 7

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.


What is UEFI secure boot? ›

UEFI Secure Boot is a feature specified in UEFI, which provides verification about the state of the boot chain. It is designed to ensure that only cryptographically verified UEFI binaries are executed after the self-initialization of the firmware.

What are secure boot keys? ›

As an industry standard, Secure Boot defines how platform firmware manages certificates, authenticates firmware, and how the operating system interfaces with this process. Secure Boot is based on the Public Key Infrastructure (PKI) process to authenticate modules before they are allowed to execute.

Should I use BIOS or UEFI? ›

In general, install Windows using the newer UEFI mode, as it includes more security features than the legacy BIOS mode. If you're booting from a network that only supports BIOS, you'll need to boot to legacy BIOS mode. After Windows is installed, the device boots automatically using the same mode it was installed with.

Which is more secure UEFI or BIOS? ›

The primary purpose of creating UEFI was to overcome the limitations of BIOS and shorten system boot time. UEFI uses the GPT partitioning scheme and supports much greater drive sizes. In addition, UEFI provides better security with the Secure Boot feature, preventing unauthorized apps from booting.

Can Secure Boot be hacked? ›

A security feature bypass vulnerability has been uncovered in three signed third-party Unified Extensible Firmware Interface (UEFI) boot loaders that allow bypass of the UEFI Secure Boot feature.

Is Secure Boot the same as TPM? ›

Secure Boot does not encrypt the storage on your device and does not require a TPM. When Secure Boot is enabled, the operating system and any other boot media must be compatible with Secure Boot.

How do I setup a Secure Boot key? ›

Enabling or disabling Secure Boot
  1. From the System Utilities screen, select System Configuration > BIOS/Platform Configuration (RBSU) > Server Security > Secure Boot Settings > Secure Boot Enforcement and press Enter.
  2. Select a setting and press Enter: Enabled — Enables Secure Boot. Disabled — Disables Secure Boot.

Should UEFI Secure Boot be enabled? ›

Secure Boot must be enabled before an operating system is installed. If an operating system was installed while Secure Boot was disabled, it will not support Secure Boot and a new installation is required. Secure Boot requires a recent version of UEFI.

Should I use UEFI Secure Boot? ›

Why You Should Use Secure Boot. Secure Boot is a valuable security feature that can help to protect your system from malware. By only allowing signed software to run, you can ensure that the software you are running is from a trusted source and has not been tampered with.

Do you need Secure Boot for UEFI? ›

When you add UEFI drivers, you'll also need to make sure these are signed and included in the Secure Boot database. For information on how the secure boot process works included Trusted Boot and Measured Boot, see Secure the Windows 10 boot process.

What does Disabling UEFI Secure Boot do? ›

For security reasons, UEFI, which is enabled by default, only runs signed bootloaders. Therefore, it is not possible to start the computer from a CD or USB drive, unless the option is disabled. Due to the fact that the existing GPT partitions require mandatory UEFI, Windows x64 may not boot after disabling secure boot.


1. Composably secure device-independent encryption with certified deletion
(Centre for Quantum Technologies)
2. Docker Secure Substrate for Container Apps
3. Mobile Substrate (Cydia Substrate) updated for all devices, including the iPhone 5s!
4. how to safely downgrade to substrate compatibitly layer - from Saurik's Substrate
(Pwned4ever _)
5. Genshiro launch party! How to run a stand alone DeFi substrate safely (Kusama Demo Day|Sep 2, 2021)
6. How to Use a Roof Safety Harness | Fall Protection
(Integrity Roofing and Painting)
Top Articles
Latest Posts
Article information

Author: Patricia Veum II

Last Updated: 03/08/2023

Views: 6018

Rating: 4.3 / 5 (44 voted)

Reviews: 83% of readers found this page helpful

Author information

Name: Patricia Veum II

Birthday: 1994-12-16

Address: 2064 Little Summit, Goldieton, MS 97651-0862

Phone: +6873952696715

Job: Principal Officer

Hobby: Rafting, Cabaret, Candle making, Jigsaw puzzles, Inline skating, Magic, Graffiti

Introduction: My name is Patricia Veum II, I am a vast, combative, smiling, famous, inexpensive, zealous, sparkling person who loves writing and wants to share my knowledge and understanding with you.