Key Management

This article discusses some high-level ideas for how to manage your signing keys. For an introduction and motivation, see the overview.

What is key management?

Key management is a process. It is the process of creating, using, and backing up cryptographic keying material (in this guide: signing keys). It involves real humans, real hardware, real PINs.

When designing a process for managing keys, many questions arise: Who has access to your signing keys? Which contributors? Which computers? Do GitHub Actions or GitLab CI (hosted on US cloud providers) have access to your signing keys? What if your developer laptop gets hacked? What if a maintainer leaves? What if your house burns down? Where do you store the hardware (computers and security keys)? Where do you store the passwords PINs used for accessing the hardware?

Example: DNSSEC root keys

DNSSEC is a protocol for signing DNS records to authenticate them. It has a hierarchy, where the parent DNS zone signs its children, thereby establishing a chain of trust. For example, the root zone signs the .com/.org/.de zones, and the .org zone signs the fmd-foss.org zone.

But who signs the root zone? The root zone is self-signed, and acts as the root of trust. To establish transparency and trust into this fundamental internet infrastructure, there is a whole Root Signing Ceremony that involves meticulous paper work, physical safes, tamper-evident bags, security cameras, and a lot of people. All of this is public, including the documents and video recordings.

In such a high-stakes environment, such ceremonies are an integral part of key management. For a small hobby project this is too much. In particular, your project is likely limited by:

1. Not having the amount of people required to properly separate all the roles.
2. Not having the physical infrastructure (like safes, security cameras, etc.).
3. Not having the time and money to spend on an 8 hour long ceremony.

Nevertheless, professional key management like the one for the DNSSEC root zone can serve as inspiration for how to build your own process, and where the bar could be.

As an additional example, see F-Droid's key backup ceremony.

Plan ahead

When it comes to managing private keys, it is critical to plan ahead. You want to get the setup right from the start, because changing things later can be difficult. Possible, but with hurdles.

Therefore, start by reading around and doing research. Try to understand the tradeoffs and security implications of your decisions. Carefully plan your setup, and test it in a dry-run with separate hardware. You need to find a balance between security and availability of your signing keys. Your key management process must fit your project's maturity level and organizational structure.

Where to store the keys

File-based keystores 👎

Most Android developers use a file-based Java Keystore to keep their APK signing keys. Often, the keystore is at least protected with a password that is stored in a password manager.

With file-based keystores, you have very little control over where your keys go. Files can be copied around, accidentally or maliciously. You don't know who has taken your key, or how many copies exist. The only protection you have is one single password.

For example, in December 2025, it was discovered that the "LineageOS for MicroG" Custom ROM had their file-based signing keys exposed in a public git repository since January 2025.

Hardware tokens 👍

Instead, you should store your private keys in a hardware token. Advantages include:

• Limited API interface.
  • All private key operations happen directly on the token. The private key never leaves the token.
  • Hardware tokens only support a small set of operations (generate, sign, decrypt, list).
  • Attackers cannot execute any other commands. There is no full shell access.
• Tamper-protection.
  • Hardware tokens are supposed to have tamper detection or even tamper resistance.
  • Even if someone tries to physically open up the device, measure its power usage, introduce voltage glitches, or otherwise tamper with it, the token should rather destroy the secret keys than let someone get access.
• Keys cannot be copied outside of the token.
  • By design, hardware tokens guarantee that the secrets cannot be extracted in plaintext.
  • (Exception: you can manually opt in by marking them as extractable=true during key generation.)
• Support for encrypted backups.
  • Hardware tokens can be backed up, but usually so that the backup can only be restored to another hardware token.

Hardware tokens come with different names (security key, smart card, Hardware Security Module (HSM)), in different form factors (smart card, USB token, PCIe card, network appliance), and with different storage sizes (from 1 key pair to millions of key pairs).

Among small projects and hobby developers, the Nitrokey HSM is popular because it is:

• Affordable (~100 €).
• Spacious: can store ± 30 key pairs. Personal hardware tokens (e.g. for e-mail encryption) can often only hold 1 or 2 key pairs.
• Has professional key management features (like a DKEK that supports sharding).

Generally, anything with the name "HSM" is suitable for "professional" use cases (for example, Nitrokey HSM or YubiHSM). Hardware tokens such as "FIDO keys" are usually intended for personal use (such as login, e-mail encryption).

Of course, there is no 100% security. Hardware tokens can have bugs, like anything made by humans. However, for the reasons above we strongly believe that hardware token provide better security than file-based keystores.

Which computer to use

Using the hardware token should be done from a hardened computer that is dedicated to this single task. The computer should be as locked down as possible.

For more details, see the airgapped computer article.

Next steps

At this point you should have:

• A hardware token to securely store your signing keys in hardware.
• A hardened computer for the key management and signing tasks.

Proceed to the next step, which is initialising the hardware token.