Update (May 28, 2016): We've discontinued this project and incorporated its security wins into CMS Airship.

Original Blog Post Follows

The problem of secure code delivery has plagued software developers since the advent of networked computers. It was only last year that a formal definition for a theoretical secure code delivery system was proposed by computer science student and security expert, Taylor Hornby.

On top of this pervasive problem, the technology industry has adopted and actively encouraged incredibly dangerous habits over the past few years: Downloading unvalidated and untrustworthy data from the network, and immediately executing it. Typically it's in the form of a "clever one-liner" that looks something like this:

curl -sS https://appsec.solutions/installer | sh

We call this piping to your shell, and it is a very bad idea.

The Road to Secure Code Delivery

Since early 2014, members of our team have been trying to improve the ecosystem of existing package managers, and to help them adopt a more secure infrastructure. As their efforts to improve existing solutions dovetailed closer to futility, it became apparent that the only way to ensure a secure code delivery service existed would be to build one from scratch.

The Triangle of Secure Code Delivery

I'm convinced that code delivery is the biggest challenge, with the most practical consequences, that we're facing today. Let's give it the attention it deserves. With these three principles, we can see a way forward.

After extensive research and threat analysis, we agreed with Taylor Hornby's model of secure code delivery. That is to say, a code delivery system is secure if and only if it satisfies these three properties:

1. Deterministic builds. Given the source code from the project, it should be possible to produce the same deliverable (binary, PHP archive, etc.) that is made available on the download page.
2. Userbase Consistency Verification. Everyone gets the same thing. This makes targeted attacks prohibitively difficult.
3. Packages are signed with an asymmetric cryptographic protocol. This allows end users to verify that the code they downloaded is as trustworthy as the producers of the code.

We compiled a wish list of implementation details to tack onto Hornby's Triangle:

1. Ed25519 signatures (not ECDSA).
2. A verifiable, append-only data structure, like Certificate Transparency or the blockchain used by crypto-currencies, based on the BLAKE2b hash function.
3. The ability to quickly and easily encrypt data so only one recipient can decrypt it, for private packages.
4. A system designed to allow anyone to operate a notary server that verifies blockchain consistency.
5. A simple command line interface to minimize cognitive load.
6. Sanity checks to prevent replay attacks of valid but old package:signature pairs.

The first three items on our wish list were satisfied by building atop libsodium. Libsodium, which is maintained by Frank Denis, was forked of a cryptography library called NaCl by Daniel Bernstein, Tanja Lange, and Peter Schwabe, three of the world's top experts in elliptic curve cryptography. Libsodium offers better portability and a lot of useful utilities (safe memory allocation, memory wiping, and cache-timing-safe encoding functions).

With the dangerous part of our project taken care of, thanks to an open source library vetted by industry experts, we pressed on. We can't thank the NaCl or libsodium teams enough. Implementing your own cryptographic primitives does not mix well with production systems, nor with customers.

Next, we designed our blockchain protocol. As far as we know, no one else to date has built a blockchain on the BLAKE2 hash function, nor used EdDSA for the public key signature protocol. Zooko Wilcox-O'hearn of Least Authority was kind enough to point us towards a well-documented Python implementation of Merkle trees in their Tahoe-LAFS code base.

Thanks to the cryptography engineering community, we had everything we needed to build the package manager of tomorrow.

ASGard

ASGard is a subscription service with some free packages available. The software is free and open source and available at Github. We have multiple subscriptions available; the benefits of the higher tiers include private package tracking in our distributed ledger. Private packages are encrypted such that only a client in possession of the correct license key can decrypt it.

When you use ASGard to install a package, it doesn't just download a file and blindly run it. Instead, it follows a more secure process:

1. Synchronize the distributed ledger with all of your peers.
2. Download the file from its usual place.
3. Verify the Ed25519 signature on the appropriate block.
4. (Private packages only.) Use your license key to decrypt the package information.
5. Check all of the supplied checksums for the file, based on the package information that Paragon Initiative Enterprises signed with our Ed25519 private key and your peer notaries verified independently.

This past weekend, our Chief Development Officer gave a talk about Application Security Beyond Compliance at the third annual Security B-Sides Orlando and introduced ASGard as a solution to the secure code delivery problem (which most developers are not even aware of).

This week, we will be publishing our Genesis Block to the distributed ledger. Any packages that we consider signing will be investigated by our security researchers. If you are a professional software developer interested in never having to pipe to your shell again, or a project manager looking out for the safety and security of your team, get ASGard today.