Caution Secret Unlocking Strategy
Out of band: Client runs caution apps verify --save-pcrs so Locksmith can use those PCRs for attestation
Existing Flow: OpenPGP
- Client: Generate a nonce
- Client: Get attestation from enclave, verify with nonce, receive enclave's public key
- Client: Generate an X25519 private+public keypair
- Client: Uses Keyfork to decrypt the shard, encrypt to aes256gcm(hkdf(x25519_dh(server_pubkey, client_privkey)))
- Client: Sign { encrypted_payload, public_key: our_public_key }
- Client: Send signed, encrypted, request. Check status.
Proposed Flow: WebAuthn + Caution Share Storage
Note: 'Caution' in this instance is the enclave that stores the shares,
'enclave' refers to the customer's enclave that is receiving shards
- Client: Generate att_nonce, get attestation from Caution, receive caution_verifying_key, caution_public_key (x25519) from Caution
- Client: Receives transport_nonce from Caution
- Client: Sends nonce to enclave, gets attestation, verify with Caution nonce, receive enclave's public key
- Client: Generate WebAuthn signed bundle: { enclave_public_key, enclave_attestation, enclave_pcrs }
- Client: Send WebAuthn signed bundle to Caution
- Caution: verify WebAuthn bundle, generate X25519 public+private keypair
- Caution: Use internal secret decryption to decrypt the shard matching client's WebAuthn key, encrypt to above algo
- Caution: Sign { encrypted_payload, public_key: cautions_public_key } with caution_verifying_key private counterpart
- Caution: Send signed, encrypted request.
- Client: Receive signed, encrypted request, verify signature using caution_verifying_key
- Client: Sign { encrypted_payload, public_key: caution_public_key } with WebAuthn
- Client: Send signed, encrypted, request. Check status.
Use Cases:
- Locksmith vault decryption.
- that's it! :)
Threats:
- Attacker controls Caution domain endpoints and deploys their enclave in the same spot as ours
- Solution: Embed PCRs of the Caution enclave, or signing keys to verify signed PCR files, relating to the Caution team
- Attacker controls database: only use it as value storage, encrypt everything to Caution controlled quorum
- Potential issue 1: Can attackers get the shards? No. We only store encrypted values, can be decrypted by the Caution enclave, locked by a Caution OpenPGP quorum
- Potential issue 2: Can attackers invalidate the relationship between shares and WebAuthn keys? No. It's hardcoded in the shard.
- Solutions involve append-only databases
- Authoritative hash
- Timestamp based
- Retain last-known valid point (signed by enclave?)
- Chain of signatures that modify the org, including existing state of the org
- Adding a new key requires >= 1 signature from an existing key
- Local policy engine for the org determines whether or not new changes get added to the quorum
- a la Icepick. :(.
- SoonTM. 4 years from NOW().
- Attacker replaces the bundle in the source code of the enclave with a different bundle
- Bundle contains a separate secret and results in a new, distinct decryption key
- May also result in the same key but different values being decrypted, if instead secrets are replaced
- Instead, place signatures in the bundle, and allow for users to verify the signatures using their local WebAuthn key
- Don't use
#[serde(deny_unknown_fields)]or even better: add a dummy slot just to hold the signatures
# Caution Secret Unlocking Strategy
Out of band: Client runs `caution apps verify --save-pcrs` so Locksmith can use those PCRs for attestation
## Existing Flow: OpenPGP
- Client: Generate a nonce
- Client: Get attestation from enclave, verify with nonce, receive enclave's public key
- Client: Generate an X25519 private+public keypair
- Client: Uses Keyfork to decrypt the shard, encrypt to aes256gcm(hkdf(x25519_dh(server_pubkey, client_privkey)))
- Client: Sign { encrypted_payload, public_key: our_public_key }
- Client: Send signed, encrypted, request. Check status.
# Proposed Flow: WebAuthn + Caution Share Storage
Note: 'Caution' in this instance is the enclave that stores the shares,
'enclave' refers to the customer's enclave that is receiving shards
- Client: Generate att_nonce, get attestation from Caution, receive caution_verifying_key, caution_public_key (x25519) from Caution
- Client: Receives transport_nonce from Caution
- Client: Sends nonce to enclave, gets attestation, verify with Caution nonce, receive enclave's public key
- Client: Generate WebAuthn signed bundle: { enclave_public_key, enclave_attestation, enclave_pcrs }
- Client: Send WebAuthn signed bundle to Caution
- Caution: verify WebAuthn bundle, generate X25519 public+private keypair
- Caution: Use internal secret decryption to decrypt the shard matching client's WebAuthn key, encrypt to above algo
- Caution: Sign { encrypted_payload, public_key: cautions_public_key } with caution_verifying_key private counterpart
- Caution: Send signed, encrypted request.
- Client: Receive signed, encrypted request, verify signature using caution_verifying_key
- Client: Sign { encrypted_payload, public_key: caution_public_key } with WebAuthn
- Client: Send signed, encrypted, request. Check status.
---
Use Cases:
- Locksmith vault decryption.
- that's it! :)
Threats:
- Attacker controls Caution domain endpoints and deploys their enclave in the same spot as ours
- Solution: Embed PCRs of the Caution enclave, or signing keys to verify signed PCR files, relating to the Caution team
- Attacker controls database: only use it as value storage, encrypt everything to Caution controlled quorum
- Potential issue 1: Can attackers get the shards? No. We only store encrypted values, can be decrypted by the Caution enclave, locked by a Caution OpenPGP quorum
- Potential issue 2: Can attackers invalidate the relationship between shares and WebAuthn keys? No. It's hardcoded in the shard.
- Solutions involve append-only databases
- Authoritative hash
- Timestamp based
- Retain last-known valid point (signed by enclave?)
- Chain of signatures that modify the org, including existing state of the org
- Adding a new key requires >= 1 signature from an existing key
- Local policy engine for the org determines whether or not new changes get added to the quorum
- a la Icepick. :(.
- SoonTM. 4 years from NOW().
- Attacker replaces the bundle in the source code of the enclave with a different bundle
- Bundle contains a separate secret and results in a new, distinct decryption key
- May also result in the same key but different values being decrypted, if instead secrets are replaced
- Instead, place signatures in the bundle, and allow for users to verify the signatures using their local WebAuthn key
- Don't use `#[serde(deny_unknown_fields)]` or even better: add a dummy slot just to hold the signatures