VouchDB

A distributed trust database, using heuristics and verifiable cryptography to publish and discover assertions.

💡 Note: This project is currently in the research phase.

Use Cases

Federated Identity & SSO

I want to be an identity provider, allowing others to verify tokens I have issued.

I want to enable my users to sign in using any number of identity providers.

Existing solutions in this space include:

• SAML: Hefty XML-based protocol for security assertions between an identity provider and a content provider -- synonymous with SSO in most enterprise SaaS products.
• JWKS: Format for publishing JWT signing keys for discoverability.
• JWT: Format for signed claims used for authentication.
• OAuth 2.0: Authorization protocol between a resource owner, a resource server, a client, and an authorization server.

Code Signing

I am installing a software package, and I want to know whether I can trust the code signing key.

I trust a particular code signing key for one package, but do not trust it to sign other packages.

Existing solutions in this space include:

• OpenPGP/GnuPG: Protocol and format for public-key infrastructure (PKI) -- publishing, signing, and verifying cryptographic keys.

The apt Way

1. Add the vendor's code signing key, granting that vendor the ability to sign all software installed by apt.
2. Add the vendor's package repository, granting that vendor the ability to distribute all software installed by apt.

The OSS Way

1. Download the software package from the vendor. (e.g: kitchen-0.1.2.tar.gz)
2. Download the software package's cryptographic hash from the vendor. (e.g: SHA256SUMS)
3. Download the signature of the cryptographic hash. (e.g: SHA256SUMS.asc)
4. Verify the authenticity of the signature by locating and evaluating the signing key. (e.g: gpg --verify SHA256SUMS.asc, then gpg --receive-keys <KeyId> for the signing key, and manual research to determine whether that key is legitimately authorized to sign this package)
5. Verify the integrity of the software package by comparing its hash against the signed hash. (e.g: typically a manual comparison of openssl dgst -sha256 kitchen-0.1.2.tar.gz and grep kitchen-0.1.2.tar.gz SHA256SUMS)

Some OSS projects publish their code signing key on their website, making step 4 much more convenient.

The Enterprise Way

Defer authenticity and integrity verification to a centralized authority and/or proprietary software for receiving software packages.

• Android apps on the Google Play Store are signed with the developer's code signing key, which must have continuity throughout the lifetime of the app and be used to sign all its release versions.

• iOS apps on the Apple App Store are signed with the developer's code signing key, which must be associated with a certificate issued by a certificate authority trusted by Apple (i.e: the Apple Developer program).

Limitations of existing solutions

PGP key servers provide a theoretical trust graph by allowing keys to publish signed trust statements about each other. In practice, however, this is easily exploited and is rarely used.

PGP key servers have notoriously poor availability, performance, and usability. Symantec's official PGP Global Directory requires a CAPTCHA in order to perform a simple search. MIT's key server regularly times out on even the most basic requests, such as rendering the form to perform a search. The search form on PGP key servers is far from the simple text box most people are used to.

Enterprise code signing certificates place universal trust in a centralized authority for all software packages. While convenient, this authority becomes a bottleneck for all software the organization's users may want to use. While this is desirable in some environments such as large organizations with dedicated I/T teams to manage software installations for all devices within the organization, it is harmful in environments where the authority is controlled by a third-party such as a government, vendor, or business.

OSS projects diverge in how their software packages are signed and verified, if signatures and hashes are even provided at all. OpenSSL and Hashicorp provide both hashes and signatures, but Elastic.co and Redis only provide hashes, whereas PostgreSQL and MongoDB provide neither hashes nor signatures.

Language-specific package repositories, such as RubyGems and npm, tend to provide hashes but rely on trust in the repository itself (via TLS alone) for authenticity. RubyGems does support code signing, but this is not widely used.

Official Linux package repositories (e.g: Debian's apt repositories) tend to lag and contain only a subset of software packages needed or used on workstations, servers, and personal devices. The rest either have to be downloaded directly, or the developers themselves need to provide a compatible package repository for each supported Linux distribution.

In short, there is no standard or widely adopted practice for code signing right now. Some projects are solving for this, but it's being done in an ad-hoc way that requires manual integration and verification, and/or has other significant usability woes that hinder adoption.

Transport Layer Security (TLS)

I am visiting a website, and I want to know whether the content I am seeing is genuine.

Existing solutions in this space include:

• X.509: Public-key infrastructure (PKI) anchored with universally trusted root certificates.
• TLS: Protocol for establishing a secure network connection between a client and server.

Secure Messaging

I want to send an encrypted message to a key's owner.

I want to be able to receive encrypted messages.

Existing solutions in this space include:

• Signal: An end-to-end secure messaging service using phone numbers as identifiers.
• Keybase: An end-to-end secure messaging service using federated cryptographic proofs.
• OTR: An end-to-end secure messaging protocol agnostic of transport or addressing.

Heuristic Trust

I have made an effort to verify a key and want others to benefit from the work I have done.

Existing solutions in this space include:

• OpenPGP/GnuPG: Protocol and format for public-key infrastructure (PKI) -- publishing, signing, and verifying cryptographic keys.