Skip to content

Instantly share code, notes, and snippets.

@lrvick

lrvick/webauthn-custody.md

Created August 31, 2022 20:39
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save lrvick/afc91d73b77187855f6f8c8a2d807ab3 to your computer and use it in GitHub Desktop.
Save lrvick/afc91d73b77187855f6f8c8a2d807ab3 to your computer and use it in GitHub Desktop.
Download ZIP
Webauthn Custody
Raw
webauthn-custody.md

Webauthn Strategy

Goal

  • Tolerate a compromise of any single internet connected computer
    • Production engineering laptops
    • Client laptops
    • Servers
  • Tolerate a compromise of any single employee
  • Require a quorum of user devices or employees to cause value movement
    • Exceptions may be tolerated for ease of use if well covered by insurance.

Approach

Most users today have WebAuthn devices, though most do not yet realize it.

Apple TouchId, Chromebook touch, Yubikeys, Ledgers, Trezors, etc are all examples.

These devices allow users to login without a password, but also allow them to sign any individual operation, proving the origin of that request was from a device controlled by the user.

This document describes an infrastructure where every decision to move or limit the movement of assets is cryptographically signed on the system of the decision maker in a way that is easy and transparent for users.

This seeks to allow off-chain multisig for all sensitive actions in a custodial digital asset stack. If implemented, it should result in a system that makes it highly evident when any operations in a system are manipulated by any entity other than the original decision makers for that operation.

Infrastructure

Queue

  • AMPQ or similar

Policy node

Function

  • Contains "Policy key"
  • Contains knowledge of latest version of all policies
  • Validaties policies
    • One of:
      • signed by itself (initial policies)
      • signed by m-of-n owners defined in initial policy
  • Validates operations
    • Verifies operation meets signed policies
    • Signs with "Policy key"
  • Approve Webauthn keys
    • Blindly approve keys for a new group/wallet
    • Require m-of-n policy

Implementation

  • Nitro enclave w/ REST proxy
  • Memory safe language such as Rust recommended
  • Only use dependencies it is practical to fully review.

Deployment

  • Generates ephemeral RSA key at boot
  • M-of-N parties
    • Remotely attest Nitro enclave is running expected deterministic image
    • Decrypt shamirs secret shares with personal HSMs on airgapped machines
    • Encrypt respective shamirs secret shares to ephemeral key
    • Submit encrypted shares to Policy enclave
  • Policy enclave comes online and can begin evaluations

Signing node

Function

  • Contains "Quorum Key"
  • All individual user keys are encrypted to Quorum Key
  • Validaties signing requests are signed by policy enclave
  • Issues blockchain-valid signatures
  • Returns signed bundle to Queue

Implementation

  • Nitro enclave w/ REST proxy
  • Memory safe language such as Rust recommended
  • Only use dependencies it is practical to fully review

Deployment

  • Generates ephemeral RSA key at boot
  • M-of-N parties
    • Remotely attest Nitro enclave is running expected deterministic image
    • Decrypt shamirs secret shares with personal HSMs on airgapped machines
    • Encrypt respective shamirs secret shares to ephemeral key
    • Submit encrypted shares to Policy enclave
  • Policy enclave comes online and can begin evaluations

Workflows

Verify UX Integrity

  • Service worker is registered in browser on first visit
  • Service worker configured to proxy all future server interactions
  • Service worker contains update() function that only accepts signed code
  • Service worker verifies all new js/css/html from server is multi-signet

See: https://arxiv.org/pdf/2105.05551.pdf

Add user

  • User initiates WebAuthn registration in web UI
  • WebAuthn Public key and UserID is submitted to Policy Node
  • Policy Node verifies key has never been seen before
  • Policy Node signs key/UserID pair and submits to user database

Add device

  • User performs WebAuthn login with existing device
  • User selects "Add Device" option after login
  • User is presented with one time short url and QR code to add second device
  • User opens url on new device and performs WebAuthn registration
  • Both devices show user-friendly hash (emoji or similar) of new device key
  • User confirms hashes match, and old device signs key of new device
  • Signature of new key is submitted to Policy Node
  • Policy Node verifies old device signature and signs new key/UserID pair

Add/Change policy

  • User performs WebAuthn login with existing device
  • User selects "Add Policy" option for a wallet after login
  • User chooses m-of-n or whitelist policy options
  • User signs policy by interacting with WebAuthn device
  • Existing m-of-n group (if any) signs policy change with WebAuthn devices
  • Policy is submitted to Policy Node and remembered as latest policy.

See: https://developers.yubico.com/WebAuthn/Concepts/Using_WebAuthn_for_Signing.html

Recover account

  • User signals they wish to recover account via "forgot device" form
  • User provides identifying account information
    • Could include a signed an automatically WebRTC recorded video clip
  • User uses a new WebAuthn device to approve/sign the support request
  • Two customer support representatives verify and sign replacement device
  • Policy Node verifies replacement key was signed by two "support" role keys
  • Policy Node signs key/UserID pair and submits to user database
  • User can now use new device to login

Rollout

  1. Enable WebAuthn as 2FA option, augmenting existing login flows
  2. Mandate WebAuthn 2FA for all employees
  3. Mandate WebAuthn 2FA for all high value users
  4. Mandate WebAuthn 2FA for all new users
  5. Flag accounts as "at risk" that only have a single registered device
  6. Disable all 2FA methods but WebAuthn (force migration on login)
  7. Drop password requirments and migrate to pure FIDO2/WebAuthn login
  8. Begin signing all policy change, user additions, withdrawal requests, etc.
  9. Begin enforcing all policies and keys in TEE or HSM (e.g. Nitro enclave)

Short term mitigations

Until measures like those above are in place, it must be understood that any member with administrative account access, or production access, in effect have complete personal custody of all user assets.

During this high risk period, some very strict and reasonably low cost controls are recommended for immediate implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment