Introduction and security model

Vault Disaster Recovery (DR) is an enterprise feature that gives you control over your data vaulted with Footprint in an emergency, without loosening the security around it or raising your day-to-day risk.

With it enabled, Footprint continuously writes encrypted backups of vaulted data to cloud storage you own, such as Amazon S3. In normal operation your risk stays low, because access to the vaulted data remains protected and audited by Footprint. In a catastrophe, when you need to "break glass" and reach your data without Footprint's services, Footprint or an escrow discloses a payload that decrypts the backups.

Vault Disaster Recovery uses the age encryption format, which supports multiple pluggable recipients and seekable streaming encryption, and a key structure that lets you test recovery on individual records without weakening the long-term confidentiality of the data.

No system or person can decrypt Vault Disaster Recovery backups on its own:

• Footprint cannot decrypt, or even read, the vaulted data written to your cloud storage.
• You can decrypt individual Vault DR records to test recovery, through an audited and access-controlled API like the standard vault decryption API.
• You cannot decrypt Vault DR records outside Footprint until Footprint or an escrow discloses a "recovery payload."

Three kinds of cryptographic keys make this possible.

You generate one or more org-scoped key pairs during onboarding. They live on YubiKeys and use P-256 elliptic curve cryptography. Footprint encrypts other private keys to (or "wraps" them with) the org public keys, so it can store those private keys and transfer them to you without keeping unused long-term access to them. You hold the org private keys and use them, together with Footprint or an escrow, to recover data from the cloud storage bucket.

Each record in the cloud storage bucket is encrypted with its own record key pair. Footprint encrypts the record private key to the org public key, stores the wrapped record key internally, and discards the record private key at once. It then encrypts the vaulted data to the record public key and writes the result to cloud storage.

To test decryption of one record, you request its encrypted record key through a Footprint API; the request is audited and controlled like a standard vault decryption. Only you can unwrap the record key, with the org private key, and that record key decrypts only that single record.

With age's multi-recipient hybrid encryption, Footprint also encrypts each file in the cloud storage bucket to a recovery public key. Footprint generates the X25519 recovery key pair during onboarding, encrypts the recovery private key to the org public key, and discards the recovery private key at once. You choose who holds the wrapped recovery private key, known as the "recovery payload":

1. Footprint stores it, and works with you to trigger disaster recovery, or
2. A third-party escrow stores it, so you can trigger disaster recovery without Footprint.

You never store the recovery payload yourself, so no single person or system can hold both the recovery private key and the data encrypted to it.

Each of the three decryption flows needs a different set of components:

The Test Recovery flow does not relax the protection of Footprint's enclave: it is audited in the same ways as the standard online vault decryption APIs and requires the same level of API key access. Before a Full Recovery, neither Footprint nor you holds the components needed to decrypt data offline through the Full Recovery flow.

Spreading the components for Full Recovery across several parties limits what an adversary gains from any one of them. It also raises the cost and complexity of an attack, since more than one organization has to be compromised to decrypt data offline.

• Onboarding enrolls your organization: the CLI, the S3 bucket, the IAM role, and org keys on YubiKeys.
• Operations checks backup status and runs a test or full recovery.