# Introduction and Security Model ## Overview Vault Disaster Recovery (DR) is an enterprise feature that provides organizations with increased control over their data vaulted with Footprint in case of an emergency while maintaining high security and low risk. With Vault Disaster Recovery enabled, Footprint continuously backs up vaulted data to customer-owned cloud storage (like Amazon S3) in an encrypted format. During normal operation, the organization maintains low risk, as access to the vaulted data is protected and audited by the Footprint platform. However, in a catastrophic situation, if the customer wishes to "break glass" and gain access to their data without using Footprint services, Footprint or an escrow will securely disclose a payload that can be used to decrypt the cloud storage backups. ## How it Works Vault Disaster Recovery is based on the [age](https://age-encryption.org/) encryption format and a cryptographic key structure that enables targeted testing of the recovery mechanism without compromising the long-term confidentiality of the data. age is a modern file encryption format with multiple pluggable recipients, and seekable streaming encryption. No system or person has the ability to unilaterally decrypt Vault Disaster Recovery backups. In particular: * Footprint itself cannot decrypt, or even read, vaulted data written to the customer’s cloud storage. * The customer can decrypt individual Vault DR records to test recovery functionality via an audited and access-controlled API, similar to Footprint Vault’s standard decryption API. * The customer cannot decrypt Vault DR records outside the Footprint platform until Footprint or an escrow discloses a "recovery payload." These properties are made possible through a simple protocol using three different kinds of cryptographic keys. ### 1. Org Keys The customer generates one or more org-scoped key pairs during the onboarding process. These keys are stored on YubiKeys using P-256 elliptic curve cryptography. Other private keys are encrypted to (or "wrapped" by) the org public keys, which enables Footprint to securely store and transfer those private keys to the customer without maintaining unused long-term access to them. The customer maintains access to the org private keys, which can be used in cooperation with Footprint or an escrow to recover data from the cloud storage bucket. ### 2. Record Keys Records in the cloud storage bucket are each encrypted with a record-specific record key pair. Footprint encrypts the record private key to the org public key, stores the wrapped record key internally, and immediately discards the record private key. Then, Footprint encrypts the vaulted data to the record public key and writes the result to cloud storage. The customer can test decryption of individual records by using a Footprint API to securely request access to the encrypted record key for a given record. This action is audited and controlled similar to a standard Footprint Vault decryption request. Only the customer can use the org private key to unwrap the record key, which can in turn decrypt the single record. ### 3. Recovery Key Pair Using age’s multi-recipient hybrid encryption, Footprint also encrypts each file in the cloud storage bucket to the recovery public key. The X25519 recovery key pair is generated by Footprint during the onboarding process. Footprint encrypts the recovery private key to the org public key and immediately discards the recovery private key. Depending on the customer’s wishes, either 1. Footprint stores the wrapped recovery private key (known as the "recovery payload") so Footprint can work with the customer to trigger Disaster Recovery, or 2. A third-party escrow stores the recovery payload so the customer can trigger Disaster Recovery without the involvement of Footprint. In either case, the customer does not store the recovery payload themselves to avoid the risk of any single person or system having the ability to have access to both the recovery private key and data encrypted to this key. ## Security Model The table below outlines the different conditions or capabilities necessary for vault decryption in the three possible flows: Online Decrypt API Test Recovery Full Recovery Footprint API is online Required Required Footprint API key with decryption scopes Required Required Read access to backup S3 bucket Required Required Org private key Required Required Wrapped record keys(fetched via audited testing API) Required Recovery payload(held by Footprint or an escrow) Required Critically, the Test Recovery flow does not relax the security provided by [Footprint’s Enclave](https://onefootprint.com/blog/inside-the-enclave-part-1), since the decryption flow is audited in the same ways as the standard online Vault decryption APIs, and requires the same level of API key access. Prior to a Full Recovery, neither Footprint nor the customer has the required components to gain offline access to decrypted data via the Full Recovery flow. Spreading the components required for Full Recovery across multiple parties reduces the impact of an adversary gaining access to any given component. It also significantly increases the cost and complexity of an attack, as multiple organizations would need to be compromised to decrypt data offline.