23. 01. 2025
DevOps
22. 01. 2025
Alessandro Mizzaro
Development, DevOps
Sign Like a Pro: A Simple Guide to GPG and Web of Trust for Commits
Some time ago, one of my colleagues wrote about git commits and why we should sign them (you should read this). But how can we actually do that? The Web of Trust of GPG comes to our aid. Let’s see how.
OpenPGP is the open-source variant of PGP (Pretty Good Privacy), a protocol and software used for encrypting, decrypting, signing, and verifying text and files.
What is GPG?
GPG is a public/private key (asymmetric) cryptography standard. You can use GPG to authenticate, sign, or encrypt/decrypt data. It manages revocation lists and distribution over a keyserver and certification.
How a GPG key is constructed
A GPG key contains:
- Key pair: public and private
- Key ID (proper to share your key)
- Expiration
- Subkeys (see next section)
- UIDs (Identities associated with the key)
- Validity level
- Trust level
What are Subkeys?
A subkey is a key/pair associated with the main key. GPG allows you to create subkeys linked to the primary key. These subkeys can be used for specific purposes, like encryption or signing, allowing for more flexibility and security. For example, you might use a subkey for encryption while keeping the primary key for signing purposes.
Every subkey is signed with the primary key, so if you want, you can rotate the subkey while the association can be attested by verifying the digital signature using the main public key
What is a Web of Trust?
GPG doesn’t have a certificate authority, so how can we assume that a key (and UIDs) should be trusted?
In the OpenPGP standard, the authentication of certificates relies on a distributed trust model called the web of trust. OpenPGP allows anyone to sign anyone else’s certificates. The validity of a certificate basically comes down to whether it’s signed by a person you trust (a.k.a trusted key).
So, how does it all work in an Enterprise scenario?
First, we need someone who acts like a Certificate Authority (for example, a Team Leader). The CA generates a key called a “Master Key” and keeps it offline and secured. This is a Trusted key across systems. In GPG, you can edit a key and set a trust level with the trust command.
When a new employee (let’s call her Alice) is onboarded, she will generate her own key, and the CA then signs it. (Remember to create a revocation certificate, so that if an employee loses their private key, then as the CA you can simply upload the revocation to the keyserver.)
What happens next?
If I trust the CA public key, then Alice’s key is valid for me, but none of the keys signed by Alice will be valid for me because I haven’t trust Alice’s key. That’s the big difference between the concepts of trust and validity.
Let’s look at a “complex” example:
What’s the difference between trust levels:
- Ultimate: All keys signed with this key are fully valid – it’s an entry in the Web of Trust
- Fully: All keys signed with this key are valid if and only if the key is valid itself (If there’s a path to an ultimate key, or it’s validated manually)
- Marginal: A key signed with this key is valid if it is signed by two other marginally trusted keys
- No trust/Unknown: We don’t know, or the key is not trusted
But what does key signing mean? When we sign a key with the CA, we sign the public key and all UIDs (so the mail in the UID could be used if it’s signed). If the user adds or edits the key, all edits must be re-signed with the CA key.
How can we distribute keys across the system?
As I said above, GPG keys can be distributed across servers with a keyserver. We can choose a public keyserver (like https://keyserver.ubuntu.com) or a self-hosted one https://github.com/hockeypuck/hockeypuck (it’s the same software).
This server can then receive public keys, revocation, and signed keys. You cannot edit a key after the upload (unless you are the server admin).
Top three advantages of using a key server:
- You can set GPG to auto-download a key if it’s not in the local keyring. So you can just import the CA key and trust it, and then other employees’ keys will be automatically downloaded from the server.
- You can search keys by keywords and send encrypted/signed messages to other people.
- With a revocation list you can upload a revocation certificate, and it will be downloaded with the key when GPG tries to verify it.
How does CI work now?
Within CI you can check whether all commits are signed with a trusted key. If not, just drop the pipeline and don’t release anything.
Future work
How can you validate commits after revocation? (Remember that the timestamp on the signing is not trusted because it’s calculated using the local time). Stay tuned for the ultimate solution with trusted timestamps.
These Solutions are Engineered by Humans
Did you find this article interesting? Are you an “under the hood” kind of person? We’re really big on automation and we’re always looking for people in a similar vein to fill roles like this one as well as other roles here at Würth Phoenix.
Alessandro Mizzaro
Security Software Engineer at Wuerth Phoenix
Author
Latest posts by Alessandro Mizzaro
22. 02. 2025
Uncategorized
NetEye 4 – Security Advisory
30. 04. 2024
Bug Fixes
NetEye 4 – Security Advisory