Security
Every component of Vault++, including services, infrastructure, clients, and business processes, is designed with security as a fundamental principle. This document outlines Vault++'s security design and principles.
Key concepts
Data encryption
Data encryption transforms (encrypt) information into an alternative form (cipher text) so that only authorized entities can read (decrypt) the original data. Typically, symmetric key cryptography is used, where a secret key serves as input for both encryption and decryption.
Asymmetric key cryptography
Asymmetric key cryptography, also known as public key cryptography, employs a pair of keys: a public key (not secret) and a corresponding private key (secret). In this system, a public key encrypts plaintext, and only the corresponding private key can decrypt the resulting cipher text, as shown below.
Unlike symmetric key cryptography, any party with access to someone's public key can send encrypted messages without knowing the private key. This feature is advantageous when distributing a symmetric encryption key freely is impractical.
For example, when customers send their credit card information to complete online orders, they encrypt the data using the merchant's public key. This ensures that only the merchant, who holds the private key, can decrypt the data, preventing intermediaries from accessing sensitive information.
Digital Signatures
Another application of asymmetric key cryptography is in creating and verifying digital signatures. Here, a private key signs data, producing a digital signature. This signature, distributed alongside the original data, can be verified using the public key to confirm data integrity and authenticity. Since the private key is confidential, only the key holder can produce valid signatures, as depicted below.
Hybrid Approach
Asymmetric key cryptography operations are computationally intensive, limiting the size of data they can process efficiently. Therefore, a hybrid approach is often used:
- Encrypt the data with symmetric key encryption.
- Encrypt the symmetric key with asymmetric key cryptography.
- Transmit both the encrypted data and the encrypted symmetric key.
For digital signatures, a cryptographic hash of the input data is signed instead of the data itself, achieving the desired result with greater computational efficiency.
Key derivation function
Symmetric key encryption requires a fixed-length key, such as 256 bits, with high randomness (entropy) for security. Human-friendly passwords typically lack sufficient entropy, making them vulnerable to brute-force attacks.
Key derivation functions (KDFs) enhance security by performing key stretching, which increases the computational effort needed for an attack. This enables the use of user-friendly passwords in scenarios requiring offline encryption, such as encrypting hard drives with login passwords or securing private key files with passphrases.
Oblivious pseudorandom function
An Oblivious Pseudorandom Function (OPRF) allows two parties to compute a pseudorandom function securely without revealing useful information to each other. Typically, in a client-server setup, the client knows the input, and the server knows a secret. Through OPRF, the client obtains the output without learning the server's secret, and the server remains unaware of the client's input or the output.
The client uses cryptographic blinding to mask the input before sending it to the server. The server performs computations using its secret and returns a blinded output. The client then decodes this to obtain the true output, as illustrated below.
OPRFs can strengthen password-based KDFs by preventing offline brute-force attacks, as server involvement is required. This setup also allows for controls like rate-limiting, further mitigating attack risks.
Mutual TLS (mTLS)
In standard TLS client-server communication, the server presents a certificate containing its public key, which the client trusts if signed by a recognized certificate authority (CA). Secure communication is then established based on this trust.
Mutual TLS (mTLS) enhances this by requiring both server and client to present certificates with their respective public keys. The server validates the client's certificate to perform authentication and authorization, while the client validates the server's certificate. This mutual validation establishes secure communication based on both parties' public keys.
Cryptography
Zero knowledge encryption
All secrets stored in Vault++ are end-to-end encrypted. Vault++ is designed to perform its functions, such as secret detection and rotation, without accessing your sensitive data. Since we do not possess the encryption keys, only you can decrypt and view your data.
Encrypting secrets
Vault++ uses asymmetric key encryption with the RSA-2048-OAEP-SHA-256 algorithm. When a user signs up, logs in, or creates a service account, Vault++ generates a pair of 2048-bit RSA keys on the client side. The public key is uploaded to Vault++ and associated with the user or service account (actor), while the private key is encrypted with a password and stored on the client side.
To add a new secret, the client generates a new symmetric encryption key and encrypts the secret using AES-256-GCM. The client retrieves the Access Control List (ACL) from the server, which contains public keys of actors authorized to access the secret. The symmetric key is then encrypted with each public key, creating an encrypted symmetric key for each actor. The client uploads the encrypted secret and keys to the server and discards the unencrypted symmetric key. This process is illustrated below.
Decrypting secrets
To decrypt a secret, the client fetches the encrypted secret and the corresponding encrypted symmetric key. It decrypts the symmetric key using its private key, then decrypts the secret using the symmetric key. This process is only possible if the corresponding encrypted symmetric key exists, indicating that the actor has the necessary access rights to the secret. This ensures that only authorized actors can decrypt and access the secret.
Merge and Reveal Requests
Merge and Reveal requests involve encryption and decryption processes similar to those outlined in the previous section.
In a Reveal Request, an Environment Admin with access to a specific secret decrypts the secret value using their private key. A new symmetric key is then generated on the client side and used to encrypt the secret. This symmetric key is subsequently encrypted with the target user's public key. Both the encrypted secret and the encrypted key are uploaded to the server, allowing the target user to decrypt them later using their private key.
In Merge Requests, an actor encrypts the changes (diff) with a new symmetric key generated on the client. This symmetric key is then encrypted using each Environment Admin's public key. The encrypted secret, encrypted keys, and the title of the Merge Request are uploaded to the server. An Environment Admin can decrypt the changes using their private key and re-encrypt them to approve and apply the modifications.
Secret Rotations
During Secret Rotations, new credentials are generated and encrypted on the client side using the vpp CLI. This process follows the same encryption and decryption procedures as previously described.
Secret Signature
When storing a new secret, the Vault++ client hashes your secret using SHA-256 with a salt; the resulting hash is referred to as the secret signature. This secret signature is sent, along with the encrypted secret, to the Vault++ server.
During secret scanning, the Vault++ client sends signatures of potential secrets to the Vault++ server. The server compares these signatures against known secret signatures. If a match is found, it notifies the client. Known secret signatures are not transmitted to the client; all verifications occur on the server. The following diagram illustrates the secret presence check in Vault++:
Signature-based authentication
Instead of using passwords or access tokens, Vault++ employs digital signature-based authentication utilizing ECDSA P-384 SHA-256. When a user signs up, logs in, or when a service account is created, Vault++ generates a pair of 384-bit ECDSA keys. The public key is sent to the server (along with the RSA public key) and associated with the actor. We refer to the ECDSA key as the signing key and the RSA key as the encryption key. The following Private Key section section provides more details on the private key structure.
Non-repudiation and Tamper-proof
When an actor makes an API request, they sign the request using their signing key. The resulting digital signature is valid only for that particular request; altering the request (e.g., its body) renders it invalid. The signature can be used only within 60 seconds after being signed and is technically single-use. Consequently, each request requires a unique signature value. This ensures the non-repudiation of the request, as only the actor can create a valid signature (not even Vault++). Vault++ records this signature in the audit logs, making all operations traceable and verifiable cryptographically.
SSO or SAML
Enterprise customers who have enabled SSO or SAML have an additional layer of authentication on top of the signature-based authentication described above. For SSO-enabled customers, the SSO access token is included in requests and validated by the Vault++ server.
Private key
Dual RSA-ECDSA key
A Vault++ private key file comprises two components:
- An encrypted component containing RSA and ECDSA private keys.
- An unencrypted component containing a 256-bit password hardening salt, a 96-bit AES initialization vector, and a 8-bit key metadata.
While it is technically possible to use a single RSA private key for both encryption (using the RSA-OAEP scheme) and signing (using the RSASSA-PKCS1 v1.5 scheme), this practice is not recommended. It violates cryptographic best practices and the guidelines set forth in FIPS.186-5. Therefore, Vault++ employs a dual-key approach.
Password hardening
Vault++ private key files are protected using AES-256 symmetric key encryption. The 256-bit AES key is derived from a user-provided password through the PBKDF2 key derivation function, configured with 777,777 iterations.
Although Vault++ enforces strong password requirements, user-provided passwords are often more susceptible to offline brute-force attacks compared to a 256-bit AES key. To enhance password security, the PBKDF2 key derivation process incorporates an Oblivious Pseudorandom Function (OPRF) calculation involving the Vault++ server. A 256-bit password hardening salt serves as an identifier for the corresponding private key, enabling the Vault++ server to enforce rate limiting policies.
In-memory policy
The vpp CLI ensures that unencrypted private keys are never stored outside of memory; they are never persisted to disk under any circumstances.
In browsers, private keys are also maintained in memory and safeguarded using JavaScript Closures. This approach restricts access by external entities, such as browser extensions, and provides protection against XSS attacks.
Access control
Access control in Vault++ is enforced through a combination of cryptographic measures and application logic. If an actor lacks access to a specific secret, they will not possess the necessary encrypted symmetric key corresponding to their public key, rendering them unable to decrypt the secret. Additionally, Vault++'s application logic prevents actors from accessing data to which they do not have authorized access.
Cloud Security
Availability
Vault++ employs a redundant architecture to ensure high availability of its services. The primary services are deployed on an AWS Elastic Container Service (ECS) cluster spanning 3 to 6 Availability Zones, enhancing fault tolerance and resilience. Additionally, Vault++ utilizes AWS Aurora database clusters and AWS ElastiCache clusters, each distributed across 3 Availability Zones, to maintain data availability and reliability. Audit logs are stored in BigQuery, a fully managed Online Analytical Processing (OLAP) platform, which offers a 99.99% uptime Service Level Agreement (SLA).
Zero trust policy
Vault++ implements a Zero Trust security model, requiring authentication for all interactions, including those within its internal network. Communications between services, databases, caches, and other components necessitate valid authentication, treating internal communications with the same security rigor as external, untrusted networks.
Data Durability
Vault++ leverages AWS Aurora's managed backup system to perform regular data snapshots. This approach ensures that data can be restored promptly in any region when necessary, providing robust data durability and disaster recovery capabilities.
Network Security
Vault++ Cloud utilizes Cloudflare as its CDN to defend against DDoS attacks. The network communication from Cloudflare to AWS is secured using mTLS, and the connection from AWS to Google Cloud Platform (GCP) is protected through Cloud IAM, a managed authentication method at the gateway level provided by GCP's Cloud Run service.
Employee Data Access
Vault++ employees typically do not have access to production data and infrastructure. In exceptional cases, senior management may grant an employee scoped temporary access to production environments. Even with such access, employees cannot decrypt secrets stored in our databases due to the implementation of end-to-end encryption.
Web Security
Vault++ enforces access via HTTPS by implementing HTTP Strict Transport Security (HSTS) policies. It also applies a strict Content Security Policy (CSP) to mitigate XSS attacks. Additionally, Vault++ enables Domain Name System Security Extensions (DNSSEC) to prevent DNS query forgery.