signify: Securing OpenBSD From Us To You

Introduction

I'm going to talk today about signify, a tool I wrote for the OpenBSD project that cryptographically signs and verifies. This allows us to ensure that the releases we ship arrive on your computer in their original, intended form, without tampering.

Alternatives

OpenBSD had already been publishing checksums, but although a SHA256 checksum is ctyptographically secure, the checksums themselves were not being communicated to users in a secure manner, and were only useful for detecting accidental damage.

One idea that floated around (outside the project) was to use HTTPS. I don't think this was ever seriously considered internally, but whenever some people hear HTTP is insecure, they just assume the answer is HTTPS. Some reasons this wasn't going to fly. Violation of end to end argument. We want to make sure that the artifact we build is the artifact you receive; ensuring that the artifact your local mirror sends you is the artifact you receive is not nearly equivalent. First, many mirrors are run by friendly people, but not the project. We don't actually control them, nor do we want to. Second, this puts all those mirrors inside the circle of trust. That's simply too much surface to confidently declare secure. Third, this proposal often implicitly included buying in to the CA model. We would prefer not to delegate final authority over what constitutes authentic OpenBSD releases to several hundred people we've never met. And if not CAs, then why use TLS? It takes more code for a TLS client just to negotiate hello than in all of signify.

The first most likely option we might consider is PGP or GPG. I hear other operating systems do so. The concerns I had using an existing tool were complexity, quality, and complexity.

There was a PGP usability study conducted a few years ago where a group of technical people were placed in a room with a computer and asked to set up PGP. Two hours later, they were never seen or heard from again. Even though the end user is actually shielded in most cases from ever directly interacting with signify, I felt it was important that users be able to quickly understand how everything worked.

We wanted to ensure all the code involved in signing met our quality standards. Without digressing too much, we have much more control over the quality of code that's developed in tree versus code developed elsewhere and imported.

The complexity of the code is also a factor. All those complex features require lots of complex code, which balloons the size of the import and makes auditing nearly impossible. Even if a perfect PGP codebase existed, how would we be able to identify it? Or as Prof. Green put it, "Can someone who built GnuPG 2.1.1 on Debian/Ubuntu give me a hint on which libgpg-error you used?" If he doesn't which libgpg-error to use, I doubt I'm going to pick the right one.

Start From Scratch

So screw all that. Let's write our own tool, from scratch. How hard can it be?

Well, we have some decisions to make, but in many cases we can reduce our implementation effort. Most importantly, if our choices are A, B, C, or D, we will never pick E) all of the above.

First up, we need a crypto algorithm (and implementation). Fortunately, some Ed25519 code had recently been imported into ssh. This reduced the candidate search set down to a single choice which only needed to be vetted to make sure it was a match for our requirements.

Next, the plumbing. What metadata to include in keys and signatures. What metadata not to include.

The interface. We need to sign things. We need to verify things. How many command line arguments could you possibly need for that?

Ed25519

Although the Ed25519 algorithm is at the core of signify, it's not what this talk is about. Nevertheless, it's important to cover the highlights. Ed25519 is a variation of the Curve25519 elliptic curve used for Diffie-Hellman key exchange. Elliptic curve cryptography requires a much smaller key size than RSA or DSA for equivalent security. This particular curve was designed by DJB to facilitate efficient, secure implementations. And whereas traditional DSA or ECDSA requires a random nonce, Ed25519 uses a hash of the message for the nonce. Insufficient random nonces have led to some catastrophic failures in other signature schemes. Basically, take all the received wisdom about what you need to very carefully not screw up, then make it impossible to screw those things up. Pretty slick.

The only likely complaint is that the security margin of 128 bits is on the small side compared to some other curves. It's only heat death of the universe secure and not heat death of all the universes secure. Now, even if you are super paranoid about this, the good news is that signify keys don't need to last forever. I'll cover key rotation in a bit, but being able to forge signatures for past releases of OpenBSD is of very limited value. This is quite unlike breaking an encryption key, which may let you read old secret data. If in five years time, the TILT-A-CURVE exploit renders Ed25519 useless, we move on to something better.

Files

Let's look at a signify key.

Feel free to take a picture if you like. That's the public key for the current 5.7 release. Technically, a key will more likely and more conveniently exist in text form, but if you are concerned about how to authenticate that the key on the website hasn't been tampered with, and the CD in the mail wasn't interdicted, you can always come to a BSD conference and take a picture. Assuming you're foolish enough to trust your camera's image sensor firmware.

The text is probably a little more interesting. Here's the /etc/signify/openbsd-57-base.pub file from my system.

untrusted comment: openbsd 5.7 base public key
RWSvUZXnw9gUb70PdeSNnpSmodCyIPJEGN1wWr+6Time1eP7KiWJ5eAM

The untrusted comment at the top is a little weird, I'll admit. Especially since it's the closest thing to a user servicable part here. Everything else is hidden inside a base64 encoded blob. So this is telling us that this is the public key for 5.7, which we could infer from the filename as well, but maybe the name has been truncated to openbs~1.pub. But at the same time, it's telling us not to trust it. It's a messy solution to a messy problem. The human factor will always remain one of the weakest points in a secure system. Despite efforts to make signify verification just work, invisibly, one of my biggest fears is that users get tricked into trusting a fake key. If you do a little research into what people find trustful, it's usually not what they hear but what they see. You won't believe a stranger who tells you a key is legit, but if you look at yourself, you're more likely to believe it. So here's a little hint that maybe you shouldn't.

Inside the base64 data are the fun bits. Decoded, there are 2 bytes which say "Ed" in case we ever need to change algorithms, 8 random bytes used to detect accidental key signature mismatches and give friendlier error messages, and then the 32 bytes of actual key. A signature is exactly the same format, but 64 bytes long instead.

In the interest of promoting inter-BSD cooperation, I figured I'd also show you the FreeBSD security officer key in case you'd like to take a picture of that as well.

Hope you brought a zoom lens.

Command Line

The signify tool is really just an interface to the cryptographic routines. After some initial debate, all arguments are specified with command line flags. There are no positional arguments, such as the source and destination arguments for cp or mv. I value explicit verbosity over implicit mistakes. For starters, most signify usage is going to be embedded in scripts. Typing a few extra characters won't kill you. Even for casual use, it can save you a trip to the man page. Is the order sign the message with the key, or use the key to sign the message? I still can't use ln without reading the man page every time. Somebody explained it, but then I still got it backwards in my head.

Artifacts

Before we go into how signing and verifying work in progress, I'm going to digress to define the term artifact. Artifacts are what we ultimately wish to verify. This includes the built releases and packages. It also includes the errata, since they are like an addendum to the release. But it doesn't include miscellaneous communications or announcements or the web site. I introduce this term because in crypto speak we usually talk about signing and verifying messages, which is exactly what signify does, but that's not to say we use it for messages in general.

Usage

If you've installed OpenBSD recently, you've probably noticed the installer splits the download and untar operations into two phases, which allows it to verify the integrity and authenticity of the sets before installation. As before, the sets are actually verified by SHA256 checksum, and it is the SHA256 file that is signed. Assuming SHA256 checksums cannot be forged, this then creates a chain of trust. If the signature matches, then these checksums are the same checksums that were on the signing machine. If the checksums match, then these are the same files that were on the signing machine. From us, to you.

The only component that you need to verify manually is the installer. I'm not thrilled about this, because once you have OpenBSD installed, you have all the parts needed to verify the next upgrade. I would like for it to be possible to run a simple command, that can download and verify a new installer for you, using the existing running system. pkg_add essentially does this for package upgrades already, we're just missing a tiny piece to close the loop in base.

pkg_add also uses signify behind the scenes to verify every package. Unless something goes wrong, this is even more transparent to the user. The signature scheme is similar. Packages already contained SHA256 checksums for integrity checking, so again, it's those checksums that are signed. However, the signature is not available separately. It's contained entirely within each package. The packages data contains too much data to atomically sign all the packages. Anybody attempting to update during an rsync would see too many failures.

Key Rotation

After each release of OpenBSD, we generate a new key pair for the release after next. That's plus two. For example, after 5.6 was released, keys for 5.8 were generated. This way, the 5.8 keys are then included in the 5.7 release. So, if you upgrade every release, you will have an unbroken chain of keys back to your initial installation. We don't directly sign keys with keys, however, but the next key is implicity signed by its inclusion in a signed release. Each key is tied to a release and only used for artifacts relating to that release.

We do this for a couple reasons. First, if you don't have a key rotation plan in place in case of emergency, your emergency will end poorly. Trying to actually recover from a compromised key is more or less impossible in my opinion. Revocation is probably a cure worse than the disease. Without any great effort, however, our key rotation schedule will automatically cycle out the bad key. Even if we do nothing, or never notice the compromised key, its utility to an adversary is limited. The tried and true solution to many problems: ignore it until it goes away.

Additionally, we have an automatic upgrade path established if we need to switch to a different algorithm.

Key Infrastructure

I've covered how signify helps get OpenBSD from us to you. But that's assuming you have a trusted signify public key. That's an egg. As also mentioned, if you are already running OpenBSD (i.e., the chicken), that includes the next key. If you have either the chicken or the egg, you're all set. But what about people with neither?

There are no key servers for signify. No web of trust. Just keys. The good news is the keys are pretty small. As demonstrated. We can stick them just about everywhere, and we do. They're on the web site, they're on twitter, they're on the top side of CD. 56 base64 characters. You can read it out loud over the phone in under a minute. Wide dispersion makes it harder and harder to intercept all the ways you may get the key and increases the risk of detection should anybody try some funny business.

References

signify - sign and verify

signify(1) manual

signing policy