Skip to main content

Accessing Encrypted PII

Only authorized VASPs and designated data consumers can access encrypted identity payloads in CRYMBO Oracle. This section explains how access is controlled, how data is decrypted, and how privacy is preserved.

Who Can Access?​

  • Receiving VASPs: Must match receiver address on the original identity request
  • Regulators (optional): Must receive scoped access via audit tokens

Decryption Flow​

  1. Oracle Relays Encrypted Payload

    • Triggered by requestPIIForTransaction
    • Oracle forwards encrypted key, data, and metadata

  2. Receiver Retrieves and Decrypts

    • Uses their private X25519 key to decrypt the AES key
    • Uses AES key + nonce to decrypt PII locally

  3. Compliance Logging

    • System logs access metadata but never stores decrypted PII

Payload Format​

{
  "encryptedKey": "<base64-encoded AES key>",
  "encryptedData": "<ciphertext>",
  "nonce": "<AES-GCM nonce>",
  "version": "1.0"
}

Requirements​

  • Receiver must have a registered public key in the CRYMBO registry
  • Valid request must exist on-chain and include receiver's address
  • Timestamps and nonces must pass replay protection checks

Privacy & Security​

  • Only the receiving party can decrypt — no oracle/intermediary access
  • CRYMBO does not store any decrypted data
  • Regulators may inspect metadata and validation proofs, not payloads

📌 Next Step: Understand Regulator Access Controls