About a month ago, I started a discussion on freebsd-hackers and freebsd-security about a system for signed executables, with a focus on signed kernels and kernel modules. This is part of a larger agenda of mine to equip FreeBSD with OS-level tamper resistance features.
While the initial use of this is for signing the kernel and its modules, and checking signatures during the loader process as well as at runtime when kernel modules are loaded. However, it is desirable to build a system that is capable of growing in likely directions, such as executable and library signing.
This article details the current state of the design of this system.
I originally outlined a number of goals for this system:
- Be able to check for a correct cryptographic signature for any kernel or modules loaded at boot time for some platforms (EFI at a minimum)
- Be able to check for a correct cryptographic signature for any kernel module loaded during normal operations (whether or not to do this could be controlled by a sysctl, securelevel, or some similar mechanism)
- Work with what’s in the base system already and minimize new additions (ideally, just a small utility to sign executables)
- Minimize administrative overhead and ideally, require no changes at all to maintain signed kernel/modules
- Have a clear path for supporting signed executables/libraries.
- The design must support the case where a system builds locally and uses its own key(s) for signing kernels and modules (and anything else) and must allow the administrator complete control over which key(s) are valid for a given system (ie. no “master keys” controlled by central organizations)
- The design must allow for the adoption of new ciphers (there is an inevitable shift to post-quantum ciphers coming in the near future)
I also specified a number of non-goals:
- Hardware/firmware-based attacks are considered out-of-scope (there is no viable method for defending against them at the OS level)
- Boot platforms that don’t provide their own signature-checking framework up to loader/kernel can’t be properly secured, and are considered out-of-scope
- Boot platforms that impose size restrictions prohibiting incorporation of RSA and ED25519 crypto code (ex. i386 BIOS) are considered out-of-scope
- GRUB support is desirable, however it is not necessary to support GRUB out-of-the-box (meaning a design requiring reasonable modifications to GRUB is acceptable
There are several considerations that should weigh in on the design.
FreeBSD Base System
Unlike linux, FreeBSD has a base operating system which contains a number of tools and libraries which provide a set of operating system utilities. Most notably, the base system contains the OpenSSL (or in some cases, LibreSSL) crypto suite. This includes an encryption library as well as tools capable of creating and managing key-pairs and other cryptographic data in a variety of formats.
Additionally, the FreeBSD base system contains libelf, which is a library that provides mechanisms for manipulating ELF binaries. Additionally, the base system provides the binutils suite, including objcopy, which are command-line tools capable of manipulating ELF binaries.
Note that only some of these components (namely the signelf tool) exist at the present; the rest of the components exist only as man pages that describe them at present.
The FreeBSD kernel does not currently incorporate code for public-key cryptography, and direct incorporation of OpenSSL into the kernel has proven infeasible. Additionally, parsing code needs to be incorporated into the kernel for any formats that are used. Options here include incorporation of code from the NaCl library, which provides a very lightweight implementation of both RSA 4096 and Ed25519, as well as creating a minimal library out of code harvested from OpenSSL or LibreSSL.
A note on elliptic curve cryptography: the state of support for safe elliptic curves is sad. In my drafts of the man pages, I have mandated that the only acceptable curves are those that satisfy the security properties described by the SafeCurves project. At this time, these include M-221, E-222, Curve1174, Curve25519, E-382, M-383, Curve383187, Curve41417, Goldilocks-448, M-511, and E-521. Unfortunately, none of these is supported by OpenSSL at this time, though Curve25519 support is supposedly coming soon. However, I would prefer to write specs that mandate the right curves (and thus put pressure on crypto libraries) than cave to using bad ones.
Modifications to GRUB
GRUB provides the best option for FreeBSD coreboot support at this time. It also provides an existing mechanism for signing binaries. However, this mechanism is deficient in two ways. First, it relies on external signatures, which would complicate administration and require modification of virtually all installer programs, as well as run the risk of stale signatures. Second, it relies on the gnupg toolset, which is not part of the FreeBSD base system. Thus, it is inevitable that GRUB will need to be patched to support the signed executables proposed by this design. However, we should make efforts to keep the necessary changes as minimal as possible.
Signing and Trust System Design
The signing and trust system consists of a number of components, some of which are standards, some of which are interfaces, and some of which are tools. The core feature, of course, is the signed ELF convention. The signelf tool provides a one-stop tool for signing large numbers of executables. The trust system provides a system-level mechanism for registering and maintaining verification keys that are used to check signatures on kernel modules. Finally, the portable verification library provides a self-contained code package that can be dropped into the kernel, the loader, or a third-party codebase like GRUB.
Note that this design is not yet implemented, so it may be subject to change. Also, it has not yet undergone review on the FreeBSD lists, so it should be considered more of a proposal.
Signed ELF Binaries
The ELF format is very flexible, and provides a generic mechanism for storing metadata. The signed ELF convention utilizes this to store signatures in a special section within the binary itself. A signed ELF binary contains a section named .sign, which contains a detached PKCS#7 signature in DER encoding for the file. This signature is computed (and checked) on the entire file, with the .sign section itself being replaced by zero data of equal size and position.
Signing an ELF binary is somewhat involved, as it requires determining the size of a signature, creating a new section (along with its name), recomputing the ELF layout, computing the signature, and writing it into the section. Checking a signature is considerably simpler: it involves merely copying the signature, overwriting the .sign section with zeros, and then checking the signature against the entire file.
The PKCS#7 format was chosen because it is an established standard which supports detached signatures as well as many other kinds of data. The signatures generated for signed ELF files are minimal and do not contain certificates, attributes, or other data (a signature for RSA-4096 is under 800 bytes); however, the format is extensible enough to embed other data, allowing for future extensions.
The signelf Tool
Signed ELF binaries can be created and checked by adroit usage of the objcopy and openssl command-line tools. This is quite tedious, however. Moreover, there are certain use cases that are desirable, like signing a batch of executables using an ephemeral key, discarding the key, and generating a certificate for verification. The signelf tool is designed to be a simplified mechanism for signing batches of executables which provides this additional functionality. It is a fairly straightforward use of libelf and OpenSSL, and should be able to handle the binaries produced by normal compilation. Additionally, the signelf tool can verify signed ELF files. The signelf code is currently complete, and works on a kernel as well as modules.
The Trust System
In order to check signatures on kernel modules (and anything else), it is necessary to establish and maintain a set of trusted verification keys in the kernel (as well as in the boot loader). In order for this system to be truly secure, at least one trust root key must be built into the kernel and/or the boot loader, which can then be used to verify other keys. The trust system refers to the combination of kernel interfaces, standard file locations, and conventions that manage this.
System Trust Keys and Signing Keys
The (public) verification keys used to check signatures as well as the (private) signing keys used to generate signatures are kept in the /etc/trust/ directory. Verification keys are stored in /etc/trust/certs, in the X509 certificate format, and private keys are stored in /etc/trust/keys in the private key format. Both are stored in the PEM encoding (as is standard with many OpenSSL applications).
There is no requirement as to the number, identity, or composition of verification or signing keys. Specifically, there is not and will never be any kind of mandate for any kind of verification key not controlled by the owner of the machine. The trust system is designed to be flexible enough to accommodate a wide variety of uses, from machines that only trust executables built locally, to ones that trust executables built on an in-house machine only, to those that trust executables built by a third party (such as the FreeBSD foundation), or any combination thereof.
The preferred convention, however, is to maintain a single, per-machine keypair which is then used to sign any additional verification keys. This keypair should be generated locally for each machine, and never exported from the machine.
Trust Keys Library
Keys under /etc/trust/certs will be converted into C code constants and subsequently compiled into a static library providing the raw binary data for the keys during the buildworld process. This provides the mechanism for building keys into the kernel, loader, and other components. These keys are known as trust root keys, as they provide the root set for all trusted keys.
Kernel Trust Interface
The kernel trust interface provides access to the set of verification keys trusted by the kernel. This consists of an in-kernel interface as well as a user-facing device interface. The in-kernel interface looks like an ordinary key management system (KMS) interface. The device interface provides two primary mechanisms: access to the current set of trusted keys and the ability to register new keys or revoke existing ones.
Access to the existing database is accomplished through a read-only device node which simply outputs all of the existing trusted keys in PEM-encoded X509 format. This formatting allows many OpenSSL applications to use the device node itself as a CA root file. Updating the key database is accomplished by writing to a second device node. Writing an X509 certificate signed by one of the existing trusted keys to this device node will cause the key contained in the certificate to be added to the trusted key set. Writing a certificate revocation list (CRL) signed by a trusted key to the device node will revoke the keys in the revocation list as well as any keys whose signature chains depend on them. Trust root keys cannot be revoked, however.
This maintains the trusted key set in a state where any trusted key has a signature chain back to a trust root key.
Portable Verification Library
The final piece of the system is the portable verification library. This library should resemble a minimal OpenSSL-like API that performs parsing/encoding of the necessary formats (PKCS#7, X509, CRL), or a reduced subset thereof and public-key signature verification. I have not yet decided whether to create this from harvesting code from OpenSSL/LibreSSL or write it from scratch (with code from NaCl), but I’m leaning toward harvesting code from LibreSSL.
The trust system performs two significant roles in the system as planned, and can be expanded to do more things in the future. First, it ensures that loader only loads kernels and modules that are signed. Second, it can serve as a kind of system-wide keyring (hence the device node that looks like a typical PEM-encoded CAroot file for OpenSSL applications). The following is an overview of how it would operate in practice.
Signature Checking in the loader
In an EFI environment, boot1.efi and loader.efi have a chain of custody provided by the EFI secure boot framework. This is maintained from boot1.efi to loader.efi, because of the use of the EFI loaded image interface. The continuation of the chain of custody must be enforced directly by loader.efi. To accomplish this, loader will link against the trust key library at build time to establish root keys. These in turn can either be used to check the kernel and modules directly, or they can be used to check a per-kernel key (the second method is recommended; see below).
Per-Kernel Ephemeral Keys
The signelf utility was designed with the typical kernel build process in mind. The kernel and all of its modules reside in a single directory; it’s a simple enough thing to run signelf on all of them as the final build step. Additionally, signelf can generate an ephemeral key for signing and write out the verification certificate after it finishes.
This gives rise to a use pattern where every kernel is signed with an ephemeral key, and a verification certificate is written into the kernel directory. This certificate is in turn signed by the local trust root key (signelf does this as part of the ephemeral key procedure). In this case, the loader first attempts to load the verification certificate for a kernel, then it loads the kernel and all modules.
Signed Configuration Files
The FreeBSD loader relies on several files such as loader.4th, loader.conf, loader.menu, and others that control its behavior in significant ways. Additionally, one can foresee applications of this system that rely on non-ELF configuration files. For loader, the simplest solution is to store these files as non-detached PKCS#7 messages (meaning, the message and file contents are stored together). Thus, loader would look for loader.conf.pk7, loader.4th.pk7, and so on. A loader built for secure boot would look specifically for the .pk7 files, and would require signature verification in order to load them.
The keybuf Interface
The kernel keybuf interface was added in a patch I contributed in late March 2017. It is used by GELI boot support to pass keys from the boot phases to the kernel. However, it was designed to support up to 64 distinct 4096-bit keys without modification; thus it can be used with RSA-4096. An alternative to linking the trust key library directly into the kernel is to have it receive the trusted root key as a keybuf entry.
This approach has advantages and disadvantages. The advantage is it allows a generic kernel to be deployed to a large number of machines without rebuilding for each machine. Specifically, this would allow the FreeBSD foundation to publish a kernel which can make use of local trust root keys. The primary disadvantage is that the trust root keys are not part of the kernel and thus not guaranteed by the signature checking. The likely solution will be to support both possibilities as build options.
The preferred scheme for trust root keys is to have a local keypair generated on each machine, with the local verification certificate serving as the sole trust root key. Any vendor keys that might be used would be signed by this keypair and loaded as intermediate keys. Every kernel build would produce an ephemeral key which would be signed by the local keypair. Kernel builds originating from an organization would also be signed by an ephemeral key, whose certificate is signed by the organization’s keypair. For example, the FreeBSD foundation might maintain a signing key, which it uses to sign the ephemeral keys of all kernel builds it publishes. An internal IT organization might do the same.
It would be up to the owner of a machine whether or not to trust the vendor keys originating from a given organization. If the keys are trusted, then they are signed by the local keypair. However, it is always an option to forego all vendor keys and only trust locally-built kernels.
An alternate use might be to have no local signing key, and only use an organizational trust root key. This pattern is suitable for large IT organizations that produce lots of identical machines off of a standard image.
This design for the trust system and kernel/module signing is a comprehensive system-wide public-key trust management system for FreeBSD. Its initial purpose is managing a set of keys that are used to verify kernels and kernel modules. However, the system is designed to address the issues associated with trusted key management in a comprehensive and thorough way, and to leave the door open to many possible uses in the future.