1.3 Vault Cryptography, Encryption Keys & Master User Recovery

1.3 Vault Cryptography, Encryption Keys & Master User Recovery

Quick Answer: The CyberArk Digital Vault secures privileged assets through a multi-tiered envelope encryption hierarchy. Every stored credential or secret file is encrypted with a unique Object Encryption Key (OEK). In turn, OEKs are encrypted by their respective Safe Key, and all Safe Keys are encrypted by the master Server Key (Server.key). For enterprise hardening, the Server Key is protected inside a Hardware Security Module (HSM) via PKCS#11. In disaster recovery or break-glass scenarios where the Server Key is lost, data is recovered using the asymmetric Recovery Private Key (recprv.key) and the built-in Master user credentials, stored offline on the Master CD.

---

The Hierarchical Envelope Encryption Model

CyberArk implements a hierarchical cryptographic architecture based on envelope encryption (key wrapping) using AES-256 (Advanced Encryption Standard with 256-bit keys). This design cryptographically isolates assets and enables rapid key rotation without requiring bulk re-encryption of underlying storage volumes.

The cryptographic hierarchy comprises three principal layers:

1. Object Level (Object Encryption Key - OEK): Every individual credential object (password, SSH key, or secret file) stored within a Safe is encrypted with its own unique symmetric 256-bit OEK. The encrypted payload is written to the Safe directory on disk as an encrypted file, ensuring independent protection.
2. Safe Level (Safe Key): Each Safe represents an isolated cryptographic domain protected by an individual Safe Key. The Safe Key encrypts and decrypts the Object Encryption Keys of all objects in that Safe. Compromising one Safe does not expose others.
3. Server Level (Master Server Key - Server.key): The top-level master symmetric key of the Digital Vault. The Server Key encrypts all Safe Keys and internal database tables. When the PrivateArk Server service starts up, it reads Server.key, decrypts the Safe Keys into volatile memory, and uses them for real-time access. When the service stops, keys are purged from memory.

---

Server Key Protection & Hardware Security Modules (HSMs)

Because the Server Key (Server.key) unlocks all Safe Keys in the Vault, its safeguarding dictates the security posture of the PAM deployment.

CyberArk provides two deployment options for the Server Key:

1. File-Based Storage

In standard deployments, the Server Key is stored as Server.key:

• Startup Loading: Defined in DBParm.ini via ServerKey=<Path>\Server.key.
• Storage Medium: Historically mounted on removable media during boot; in modern virtualized environments, it resides on a dedicated, restricted NTFS partition granting access only to the local Windows SYSTEM account.
• Operator Key: In environments requiring manual intervention to start the Vault, an Operator Key is maintained on removable media, requiring administrative insertion at startup.

2. Hardware Security Module (HSM) Integration

For environments requiring FIPS 140-2 Level 3 compliance, storing the Server Key on host file systems is prohibited. CyberArk integrates with dedicated Hardware Security Modules (HSMs):

• PKCS#11 Standard: The Vault interfaces with the HSM using the standard PKCS#11 API (Thales, Gemalto, Utimaco, AWS CloudHSM).
• Hardware Boundary: The Server Key is generated directly inside the tamper-resistant hardware boundary of the HSM and marked non-exportable. It never exists in plaintext on host storage or OS memory.
• Cryptographic Operations: Safe Keys are transmitted over PKCS#11 to the HSM, which executes symmetric operations internally, returning wrapped/unwrapped Safe Keys to Vault memory.

---

The Asymmetric Recovery Pair & The Master CD

CyberArk incorporates an asymmetric cryptographic recovery pair based on RSA public-key cryptography (2048-bit or 4096-bit), ensuring encrypted assets remain recoverable if the Server Key is lost or damaged.

1. The Public Recovery Key (recpub.key)

Generated during initial installation:

• Placed permanently on the Vault server: %ProgramFiles(x86)%\PrivateArk\Server\Conf\recpub.key.
• Whenever a Safe is created, a secondary copy of the Safe Key is encrypted using recpub.key and stored in the database. As a public key, extracting recpub.key provides no capability to decrypt data objects.

2. The Private Recovery Key (recprv.key) & The Master CD

The Recovery Private Key (recprv.key) is the ultimate break-glass asset:

• Physical Isolation: Written to the Master CD during installation and NEVER stored on the Vault hard drive.
• Break-Glass Authority: Possession of recprv.key allows an administrator to decrypt emergency copies of Safe Keys, bypassing the Server Key.
• Dual-Custody Governance: The Master CD must be stored in a tamper-evident envelope in a safe deposit box under a strict two-person rule (dual control). Access requires authorization from independent corporate custodians.

---

Emergency Recovery & Break-Glass Procedures

When standard access fails or database corruption occurs, CyberArk provides dedicated disaster recovery mechanisms.

The Built-In Master User

During installation, two built-in administrative accounts are created: Administrator and Master:

• The Administrator Account: The daily administrative identity used to manage Safes and policies through PVWA or PrivateArk Client.
• The Master User: The emergency break-glass identity. The Master user cannot log in via PVWA; authentication is permitted exclusively through the desktop PrivateArk Client directly to the Vault server IP.
• Emergency Password Reset: If the primary Administrator password is lost or locked, an administrator attaches the Master CD containing recprv.key and logs in as Master to reset credentials or reassign Safe ownership.

Emergency Safe Decryption with PARestore

If total OS destruction or database loss occurs without an operational secondary Vault, Safe contents can be extracted from backups:

1. Retrieve raw encrypted Safe files (.enc) from backup storage.
2. On an isolated workstation, run the recovery utility PARestore.exe.
3. Mount the Master CD containing recprv.key.
4. PARestore uses recprv.key to decrypt Safe Key envelopes, decrypts Object Encryption Keys, and outputs raw plaintext credentials.

---

Key Rotation & Component Credential Lifecycle

Maintaining the cryptographic integrity of the PAS deployment involves regular rotation of operational keys and component authentication secrets:

Component Credential Files (.cred)

Components authenticate to the Vault using credential files generated by CreateCredFile.exe, binding secrets to local machine entropy:

• Current Windows User Security Identifier (SID)
• Host Machine Name and IP Address
• Windows Data Protection API (DPAPI) master keys
• Absolute Application Executable File Path

If an attacker steals a .cred file, environment checks fail on any other system and the Vault rejects authentication, preventing lateral credential harvesting.