Download Release

View On Github

General

GyroidOS Secure Boot


CML secure and measured boot GyroidOS

To protect the code integrity, GyroidOS performs a conventional Secure Boot procedure. The secure boot of GyroidOS is based directly on it’s own keys and the Linux kernel is directly started from the UEFI-BIOS without any intermediate bootloader such as shim or grub2. This reduces the complexity of the boot procedure, and it is not necessary to sign and use another bootloader which would in turn verify and start the Linux kernel. For this reason, all types of keys (see UEFI keys) are replaced and CertBOOT is stored in sdb, to get full control over the platform.

The upper part of the Figure above shows the secure boot procedure. With every start of the system, trustworthy ROM code, the UEFI firmware is executed. The included public key of CertBOOT is used as root of trust for the GyroidOS Secure Boot. Note that UEFI directly uses the Public key and does not validate the certificate nor is it possible to provide certificate chains here. This key is used to verify the next layer of software by it’s hash value when it is being loaded. In our case the Linux kernel. The Linux kernel is built as an EFI binary so that it can be started directly by the UEFI-BIOS without another bootloader. The kernel itself also includes the CertBOOT to verify its modules before loading a module. The cmld (Container Manager Daemon) as part of the initramfs is already verified by the initial verification process of the UEFI. The cmld starts the next stage a container, and thus verifies the container rootfs image before execution of the corresponding container.

In principal a TPM is not necessary for Secure Boot. The lower part of the figure shows a “Measured Boot” procedure which is described in Measured Boot.

In a nutshell to enable secure boot, during build the following steps are performed:

  • Translating the Kernel to EFI (from ELF)
  • Integrating the initial ramdisk (initramfs) into the kernel-binary
  • Use efitools to generate KEK, PK and “Signature Database Keys”
  • Signing of the Kernel with the private key PrKBOOT, and storing the corresponding public key in form of a certificate CertBOOT as a “Signature Database Key” (sbsign)
  • Signing the kernel modules with the same private key PrKBOOT
  • Integrating CertBOOT into the kernel-binary to verify the modules
  • Lock-Down with efitools for the rollout of the efivars keys

The signing process is described in PKI.

At the system start, no UEFI-password is set. It would however be possible to set a UEFI-password, to protect the UEFI-configuration. This means to stop an attacker from modifying the UEFI-configuration by entering the UEFI-menu at the start of the system. With this the attacker could only disrupt the availability of the system. The changing of the UEFI parameters causes the Secure Boot to fail, which means the system will not start. If the attacker disables Secure Boot, the availability is also prevented, because the key for the persistent storage encryption is bound to PCR 7 in the TPM as described in Storage Encryption. PCR 7 stores wether or not Secure Boot is active. Only if PCR 7 receives the correct values, the TPM will release the key to the persistent storage encryption, and only then the system can be started.

During first boot of the system, GyroidOS is started in a so called provisioning mode. This mode is a base installation which is used to configure the system and only contains the core container core0. The user has access to core0 and can use it to load a signed GuestOS and a signed container configuration file onto the device. Further during provisioning it is allowed to deploy CA certificates for own GuestOS images. To conduct these steps, core0 offers a control interface with an extended command scope. As soon as the provisioning is completed, the provisioning mode is exited through an irreversible command and the scope of the command interface is reduced permanently, e.g., no further certifictaes for GuestOS image verification can be registered.

UEFI keys

Three types of keys exist in the context of the UEFI specification:

  • Platform Key (PK). The PK shall be under the control of the “Platform Owner”, meaning the buyer/owner of the hardware. Setting the PK shifts the platform to the secure “User/Secure Mode”. UEFI-BIOS usually offers the possibility to switch to “Setup-Mode”. The OS can activate “Secure Mode” at the first boot after the key has been updated

  • Key-Exchange Key (KEK). KEKs represent publice and private key pairs, which are standardly controlled by the OS vendor, since it owns the private keys. The “Platform Owner” however can determine which public key they install in their system.

  • Signature Database. Hashes, signatures or public signature keys for the verification of software components can be stored in the “Signature Database”. Corresponding private keys are used to sign binaries. All binaries that are signed with a “Signature Database” key can also be started in “Secure Mode”.

  • Forbidden Signature Database. By storing forbidden hashes in the “Forbidden Signature Database” downgrade and replay attacks can be prevented.