Skip to content

Secure Boot Overview

The secure boot mechanism verifies the authenticity of programs before they run. In other words, only programs authorized by a legitimate entity are allowed to run.

The secure boot mechanism ensures that:

  • accidental or malicious modifications of embedded programs cannot run.
  • a machine cannot be reused by an unauthorized entity for other purposes.

Bootloader Authentication

The secure boot mechanism first relies on the ability of hardware components to authenticate the bootloader before handing over control to it.

This is hardware specific. Please refer to our supported machines:

Machine-Generic Authentication with SWK1

The bootloader holds the public part of an asymetric key pair (called SWK1). This public key is authenticated at runtime, as part of the bootloader.

SWK1 algorithm: RSA-4096

SWK1 is used:

  • by the bootloader to authenticate the kernel FIT image (BOOT)
  • by BOOT to authenticate SYSRO and APPRO (dm-verity)

Single key SWK1

  • swk1.pub: public part of SWK1
  • conf-1.sig: signature of the kernel FIT image
  • verity-hash.sig: signature of dm-verity root hash

swk1.pub is passed by U-Boot to the Linux kernel through the command line, with this syntax: 

rsa_exponent:0x10001;rsa_modulus:0xBD56D74BA850BDCD75B.....

The initramfs script rebuilds the public key and makes it available for userspace programs to authenticate SYSRO and APPRO. 

/run/swk/swk1.pub
/run/swk/swk.pub -> swk1.pub

Key Delegation with SWK2

Alternatively, it is possible for SWK1 to delegate the authentication of SYSRO and APPRO to another key held in the ramdisk: SWK2.

Secure update SWK2

  • swk2.pub: public part of SWK2

The keys available for userspace programs are: 

/run/swk/swk1.pub
/run/swk/swk2.crt
/run/swk/swk2.pub
/run/swk/swk.pub -> swk2.pub

Notes:

  • SWK2 can be of any algorithm supported by openssl.
  • By default, Welma does not use SWK2 for secure boot.
  • If both SWK1 and SWK2 were present, the latter would take precedence in userspace.

BOOT Authentication

U-Boot is in charge of authenticating the kernel FIT image located in the BOOT partition (file fitImage).

The secure boot sequence in U-Boot is as follows:

  • Load fitImage in RAM
  • Select a configuration to boot (the kernel FIT image may contain several configurations, but only one of them is selected for booting)
  • Authenticate the selected configuration with SWK1
  • Check the integrity of all images referenced by this configuration (SHA256)

SYSRO & APPRO Authentification

This authentication is essentially based on dm-verity, which is a linux kernel feature.

When WELMA_SECURE_BOOT is activated, the partitions with the verity flag in the split file are protected by this mechanism (APPRO & SYSRO in the default Layout). This allows the kernel to check the completeness of these partitions after each reboot and before mounting them.

Protected partitions have a header containing information identifying the partition. In addition, the block hash tree is contained just after the file system blocks.

The built partitions has the .verity extension and is structured as follows:

+----------+--------------+--------------+------------------+ --------
|  MAGIC   |   VERSION    | TOTAL LENGTH | HASH TREE OFFSET |     ^
+----------+--------------+--------------+------------------+     |
|     ROOT HASH SIZE      |          ROOT HASH              |     |
+-------------------------+---------------------------------+     |
|   ROOT HASH SIG SIZE    |      ROOT HASH SIGNATURE        |     | Welma Header (4K)
+-------------------------+---------------------------------+     |
|    CERTIFICATE SIZE*    |         CERTIFICATE*            |     |
+-------------------------+---------------------------------+     |
|                      Padding                              |     v
+-----------------------------------------------------------+ --------
|                                                           |     ^
|                                                           |     |
|                                                           |     |
|                                                           |     |
|                  EXT4 data partition                      |     | APPRO/SYSRO
|                                                           |     |
|                                                           |     |
|                                                           |     |
|                                                           |     v
+-----------------------------------------------------------+ --------
|                                                           |
|                    Hash Tree block                        |
|                                                           |
+-----------------------------------------------------------+
* Not used in the current version, filled with 0-bytes.

The secure boot stages in initramfs are:

  • Authenticate the ROOT HASH of SYSRO with /run/swk/swk.pub
  • Mount SYSRO with dm-verity: the kernel checks that the ROOT HASH matches the EXT4 data partition
  • Authenticate the ROOT HASH of APPRO with /run/swk/swk.pub
  • Mount APPRO with dm-verity: the kernel checks that the ROOT HASH matches the EXT4 data partition

Yocto configuration

You need to set in your local.conf: 

WELMA_SECURE_BOOT = "1"

This will build:

  • Embedded code for secure boot
  • Images signed and provisioned with development keys: WELMA_KEY_SWK1_PUB, WELMA_KEY_SWK1_PRIV, WELMA_KEY_SWK2_PUB, WELMA_KEY_SWK2_PRIV

Environment Development vs Production

Welma provides tools to enable a clear separation of secure boot keys between production and development environments.

Block diagram for ARM architecture:

Environment Development vs Production

  • ① Source code, Yocto recipes and development keys
  • ② Artifacts produced by the Yocto build process, with test keys and signatures
  • ③ Extra artifacts packaged for developers
  • ④ Production keys on customer premises
  • ⑤ Welma signing tools, that may use key files or (upcoming) more industrial Public Key Infrastructure (PKI) & Hardware Security Module (HSM) via PKCS#11 interface and dedicated openssl engines
  • ⑥ Artifacts provisioned and signed for production (boot may contain swk2, not shown on the diagram)
  • ⑦ Production-specific procedures & tools that provision end products with software and keys (either on the factory production line, or remotely)