PGP with secrets in the cloud

Home > Blog > PGP with secrets in the cloud

What if we could secure our PGP keys using cloud services?

OpenPGP is an open standard that aims to secure data in transit by enabling end-to-end encrypted communication, widely used to secure e-mail services and many other types of applications. OpenPGP currently supports modern cryptography and is constantly vetted by renowned security experts.

Identity management is a central component of OpenPGP. In simple terms, your identity is divided into a pair of public and private PGP keys. The private key must remain a secret and is stored in your device’s keyring.

The public key can be shared with your correspondents who can send encrypted files to you that can only be decrypted using your private key. In this setup, unfortunately, an attacker who gains control over your private PGP keys can silently impersonate you, accessing your encrypted traffic and creating valid signatures.

While you want to secure these private keys and monitor their usage, applications still need to access them for certain PGP operations. Despite device and operating system protection mechanisms, some settings simply cannot be trusted since it only takes a single bug or a missed software update to penetrate your device.

Furthermore, storing your PGP keys locally is not very flexible, as you may need to access them from other devices – and keep those devices secure too.

Instead of handling PGP keys locally, you can step up to the next security level by securing your PGP keys inside Fortanix™ Data Security Manager.

Sequoia-PGP: A cool OpenPGP implementation

In 2017, the PEP foundation announced a new modern OpenPGP implementation written in Rust. Since then, the project has been under nimble development by a team of experts who also contribute to the PGP ecosystem in general. Particularly remarkable is the OpenPGP interoperability test suite, where an effort is made to detect bugs and check if different PGP implementations (or versions thereof) can really exchange messages between them.

Sequoia-PGP is presented in the form of several Rust crates. In particular, the sq crate provides a command-line interface (CLI) similar to e.g., gpg but with comfortable git-like commands and subcommands:

Creation and management of PGP keys (key, keyring, certify)
Consumption/production of cryptographic material (encrypt, decrypt, sign, verify)
Low level manipulation, interaction with Web Key Directories (packet, inspect, wkd).

This CLI is a great tool for users with varying levels of PGP expertise – ordinary users would verify a signature with sq verify --signer-cert=alice.pgp signed-message.pgp and more advanced users would dissect and analyze a troublesome key with sq packet dump alice.pgp.

A crypto refresh for OpenPGP

The OpenPGP Working Group of the Internet Engineering Task Force (IETF) is currently updating the OpenPGP specification in the “crypto refresh” RFC draft. Among several editorial improvements over the last RFC, this update includes deprecation of insecure algorithms (e.g., MD5, IDEA), protection against known vulnerabilities, increased support for elliptic curves, and the addition of authenticated encryption modes with additional data (i.e. AEAD modes). Well-known implementations already conform to this draft, ensuring that the PGP ecosystem is up to modern cryptography standards.

There are several advantages to using Sequoia-PGP, aside from being on par with the updated specification. As it is implemented in Rust, it inherits all of Rust’s memory safety features – similar to Fortanix DSM. It is also open-source, platform-agnostic, and allows specifying custom cryptographic policies.

The best of two worlds

Building on top of Sequoia’s open-source code, we present sq-dsm. This is an extension of sq that does not assume that secrets are stored in the device, and moreover knows how to communicate with Fortanix DSM via the DSM REST API. This way, in the course of a PGP operation, every time the OpenPGP standard requires Sequoia-PGP to perform a sensitive operation (namely, generate a private key, sign a hash, or decrypt a session key), sq-dsm utilizes DSM to perform the cryptographic operations with the secrets protected within and waits for the response. In Rust terminology, the sq-dsm extension offers a new implementation of Sequoia’s Signer and Decryptor traits.

Let’s take a closer look at key generation. The following command creates a new PGP key with secrets in DSM. It sets a sensitive default ciphersuite for this PGP key (X25519, Ed25519, SHA512 and AES256) and creates the necessary security objects in DSM.

sq-dsm key generate --dsm-key="alice" --userid="Alice <alice@fortanix.com>"

Note that there is no output - secrets are stored in DSM and will never leave its premises (unless you really want them to, by using the --dsm-exportable flag). Now, if we navigate to the DSM dashboard, we can see that two security objects were created – one for signatures (primary key) and one for encryption (encryption subkey). Moreover, inspecting the audit logs, we see that the primary key has already been used for signatures! This happens because, in PGP, the primary key needs to sign itself, sign subkeys, and sign other packet data, in order to prevent attackers from simply replacing critical parts of keys.

The following command fetches the corresponding public key for distribution among your correspondents:

sq-dsm key extract-cert --dsm-key="alice"

This outputs the public key (“-----BEGIN PUBLIC KEY BLOCK-----…”), and that’s it!

For other operations, there are similar encrypt, decrypt, sign, verify commands. As usual, Fortanix DSM isolates your secrets and carries out cryptographic operations with state-of-the-art implementations in secure enclaves, applying further policies, managing access and logging usage.

With sq-dsm, Sequoia-PGP ensures robustness and flexibility at the client, and Fortanix DSM protects your secrets in the cloud, with Rust all along the way.