Securing RPM signing keys

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

RPM Package Manager is the common method for deploying software packages to Red Hat Enterprise Linux, Fedora Project, and their derivative Linux operating systems. These packages are generally signed using an OpenPGP key, implementing a cryptographic integrity check, enabling the recipient the ability to verify that no modifications occurred after the package was signed (assuming the recipient has a copy of the sender’s public key). This model assumes that the signer has secured the RPM signing private keys and they will not be accessible to a powerful adversary.

Before looking into possible solutions to the problem of securing RPM-signing keys, its worth mentioning that signing RPMs is not a complete solution. When using yum repositories, transport security (HTTPS) needs to be enabled to ensure that RPM packages, and the associated metadata (which contains pkg checksums, timestamps, dependency information etc), are transmitted securely. Lastly, sysadmins should always ensure that packages are installed from trusted repositories.

How RPM signing works

The rpm file format is a binary format and broadly consists of 4 sections:
- the legacy lead is a 96 byte header which contains "magic numbers" (used to identify file type) and other data;
- an optional signature section;
- a header which is an index containing information about the RPM package file; and
- the cpio archive of the actual files to be written to the filesystem.

During the signing process, GnuPG calculates a signature from the header and the cpio section using the private key. This OpenPGP signature is stored in the optional signature section of the RPM file. During verfication, GnuPG uses the public key to verify the integrity of both these sections.

The above is normally referred to as RPM v3 signatures. RPM version 4 and above introduce v4 signatures which are calculated on the header alone. The file contents are hashed and those hashes are protected by the header-only signature, so the payload can be validated without actually having a signature on it.

How to sign rpms

The RPM binary internally uses OpenPGP, which has been traditionally used for signing emails. The process involves creating a key pair using OpenPGP and then using the private key to sign the RPMs while the public key is published securely to enable users to verify the integrity of the binary RPMs after downloading them.

Currently there is no way to directly sign RPMS using x509 certificates. If you really want to use x509 certificates you can sign RPMs like any other files by signing the entire RPM file using openssl, nss, or any other x509 tool and appending distributing the signature and the certificate you want to verify against with the RPM file.

Using a Hardware Security Module

A Hardware Security Module (HSM) is a physical computing device which can manage and safeguard digital keys. They also provide cryptographic processing like key generation, signing, encryption, and decryption. Various HSM devices are available in the market which have varying features and costs. Several HSM devices are now available as USB sticks that, once plugged in, the GPG tool should be able to recognize and generate new keys, sign and verify files using the on-device private keys.

Typically, keys are generated inside the HSM where they are then stored. The HSM is then installed on specially configured systems which are used for signing RPMs. These systems may be disconnected from the Internet to ensure additional security. Even if the HSM is stolen, it may not be possible to extract the private key from the HSM.

With time HSM devices have become cheaper and more easily available.

Securely publishing public keys

While the conventional method of publishing OpenPGP public keys on HTTPS protected websites exists, DNSSEC (or DNS for that matter) provides an elegant solution for further securing the integrity of the published public keys.

PKA is a simple way of storing the look up information for your public key in a DNS TXT record. DNSSEC can store the fingerprint of the public key, as well as their storage location. DNS records can further be signed to provide additional security.

All RPMs released by Red Hat are signed, and the public keys are distributed with the products and also published online.