Cryptographic Signatures in Fedora

Daniel Milnes

Cryptographic signatures are used throughout the Fedora ecosystem to ensure the integrity and authenticity of distributed artefacts. By verifying a signature, users can confirm that an artefact was produced by the Fedora Project and has not been tampered with since it was signed.

Cryptographic signatures also simplify the use of mirrors within the Fedora Project. As the artefacts are signed with a key that is distributed out-of-band, it’s possible to establish trust even if the download did not come directly from Fedora infrastructure.

Fedora currently signs the following artefacts:

  • Installation Media and Disk Images

  • RPM Packages

  • Secure-Boot PE Executables

  • OSTree Composes

An authoritative list of Fedora’s GPG keys can be found on the Fedora website here and in the fedora-gpg-keys package.

Verifying Signatures

Whenever possible, tooling will automatically verify the signatures for Fedora’s artefacts. It can still be useful to manually check the signatures in some situations though, which this section will explain the process for.

Installation Media

As the entrypoint to the Fedora ecosystem, installation media is signed as a means of authenticating all subsequent steps in the installation process. These signatures are provided in -CHECKSUM files, distributed alongside the downloads for the installation media.

  1. Download the file you want to verify and the checksum file from the Fedora website.

  2. Download the Fedora’s GPG keyring from the website or use the version supplied in fedora-gpg-keys.

    $ curl -O https://fedoraproject.org/fedora.pgp

  3. Verify the contents of the checksum file matches the signing key and the downloaded file

    $ gpgv --keyring ./fedora.pgp --output - Fedora-Workstation-43-1.6-x86_64-CHECKSUM | sha256sum -c --ignore-missing

    The filename and OK should be logged. If the checksum does not match, do not use the download and report the issue to Fedora.

RPM Packages

When installing an RPM package using dnf, the package signature will be automatically verified against the GPG key configured for the repository it was downloaded from. You can also manually verify the signature of any downloaded package against the system keyring.

$ dnf download bash
$ rpmkeys --verbose --checksig bash-5.3.0-2.fc43.x86_64.rpm
bash-5.3.0-2.fc43.x86_64.rpm:
    Header OpenPGP V4 RSA/SHA256 signature, key fingerprint: c6e7f081cf80e13146676e88829b606631645531: OK
    Header SHA256 digest: OK
    Payload SHA256 digest: OK

Additional information on RPM signing can be found here.

PE Executables

To allow for booting with Secure Boot enabled, Fedora produces a signed version of the grub bootloader and kernel images. Systems booting with Secure Boot enabled will automatically verify the signature, but you can also manually verify it using the sbverify command.

$ sudo sbverify --list /boot/efi/EFI/fedora/grubx64.efi
signature 1
image signature issuers:
 - /CN=Fedora Secure Boot CA
image signature certificates:
 - subject: /CN=Fedora Secure Boot Signer
   issuer:  /CN=Fedora Secure Boot CA
signature 2
image signature issuers:
 - /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot CA 20200709/CN=fedoraca
image signature certificates:
 - subject: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot Signer/OU=bkernel01 grub2/CN=grub2-signer
   issuer:  /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot CA 20200709/CN=fedoraca

Given Secure Boot’s chained certificates, there are multiple steps to verifying the boot process.

  1. Download Microsoft’s Secure Boot Root CA.

    $ curl -LO https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt

  2. Convert the download to PEM format.

    openssl x509 -in MicCorUEFCA2011_2011-06-27.crt -inform DER -out MicCorUEFCA2011.pem -outform PEM

  3. Check that shim has been signed with Microsoft’s key.

    $ sudo sbverify --cert MicCorUEFCA2011.pem /boot/efi/EFI/fedora/shimx64.efi
Signature verification OK

  4. Download the package containing Fedora’s signing key.

    $ dnf download --source shim-unsigned-x64

  5. Extract the signing key from the package.

    $ rpm2archive shim-unsigned-x64-15.8-2.src.rpm
$ tar xvf shim-unsigned-x64-15.8-2.src.rpm.tgz

  6. Convert the certificate to PEM format.

    openssl x509 -in fedora-ca-20200709.cer -inform DER -out fedora-ca-20200709.pem -outform PEM

  7. Check the signature of the grub binary.

    $ sudo sbverify --cert fedora-ca-20200709.pem /boot/efi/EFI/fedora/grubx64.efi
Signature verification OK

  8. Check the signature of the vmlinuz kernel binary.

    $ sudo sbverify --cert fedora-ca-20200709.pem /boot/vmlinuz-6.19.10-200.fc43.x86_64
Signature verification OK

OSTree

Fedora Atomic utilises OSTree to distribute immutable systems images, which can be updated in place. OSTree commits are signed with GPG signatures that are automatically verified during updates. You can use the below commands to manually inspect these signatures.

  1. Print the imported keys and confirm they contain the trusted GPG keys from the Fedora website.

    $ ostree remote gpg-list-keys fedora

  2. Check the ostree commit has been signed by one of the trusted keys.

    $ rpm-ostree status
State: idle
Deployments:
● fedora:fedora/40/x86_64/silverblue
                  Version: 40.20240521.0 (2024-05-21T00:39:46Z)
               BaseCommit: 95103d53d4e65f509d36693e3fdd252e36128beb0de6e1c01fd59a5728c172c0
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC

Generating Signatures

Fedora automatically generates all the signatures discussed above within the CI infrastructure. This is performed using several pieces of custom software, which are documented below along with links to their source code.

Robosignatory

Signing of artifacts is initiated by Robosignatory, which watches on Fedora Messaging for relevant CI jobs completing. When it detects a new artifact to sign (for example, from the Koji buildsystem), it downloads it, signs it using Sigul, and uploads it back to the original source.

Robosignatory authenticates to the Fedora CI infrastructure as the autopen user and runs on the autosign01.mgmt.rdu3.fedoraproject.org host.

Additional documentation for Robosignatory can be found on Pagure.

Sigul

Cryptographic operations within the Fedora infrastructure are performed by Sigul. Sigul allows authorised signers (Robosignatory and a small pool of trusted operators) to issue signing jobs to the Bridge server, which forwards it over a Mutual TLS connection to a pool of signing servers. The signing servers are then able to sign the payload using a PKCS#11 device and return the signed version to the client.

The Sigul bridge is deployed on sign-bridge01.rdu3.fedoraproject.org and signing on sign-vault0{1,2}.rdu3.fedoraproject.org. Access to these servers is more restricted than standard Fedora infrastructure.

Additional documentation for Sigul can be found on Pagure.

Siguldry

Written in Rust, Siguldry is the next generation of Fedora’s signing infrastructure. Its architecture is heavily based on Sigul, taking advantage of modern features like systemd-credentials for the mTLS connections between components.

Siguldry is not currently deployed within the Fedora infrastructure, but is intended to eventually replace Sigul as the primary signing tool. Parts of the code base are already used for signing PE Executables for Secure Boot (using sigul-pesign-bridge), however this is still currently pointing at the existing Sigul infrastructure.

Siguldry Architecture

Additional documentation for Siguldry can be found on GitHub and its documentation site.

Key Management

Each Fedora and EPEL release has a standalone GPG keypair which is generated by Sigul at the start of the release cycle. More information on the key generation process can be found here.

Encrypted versions of the keys are stored in Sigul’s database, protected by a password and PKCS#11 devices (currently YubiKeys). When a signing job is submitted, the PKCS#11 device is used to decrypt the key material, then a separate PKCS#11 device is used for the actual signing. The servers hosting this key material are only accessible by a small pool of operators and are isolated from most of the Fedora infrastructure on the network, ensuring key material never leaves the trust boundary.

Since Fedora Linux 11, Fedora has used the rsa4096 signature algorithm for GPG signing. This is expected to change as part of the ongoing transition to post-quantum cryptography.

Upstream Signatures

If signatures are provided by upstream projects, Fedora verifies the signatures of package sources before building them. More information about this can be found on Fedora Packaging Guidelines.

Want to help? Learn how to contribute to Fedora Docs ›