Secure Crypto Asset Custody Requirements

secure_crypto_asset_custody.md

Secure Crypto-Asset Custody

Summary

This document seeks to outline a broad set of requirements for crypto-asset custodians based on lessons learned from historical failures to understand and remove attack surface.

It will also assume that not everyone has equal resources or equal risk and as such four incrementally harder security levels to that effect, depending on your budget and the expected sophistication of your worst case threat.

Level 1

Threat Model

• Adversary is as low skilled individual targeting users of many custodians.
• Adversary can:
  • Use phishing to steal text from a random set of custodian users
  • Inject malware into the systems of a random set of custodian users

Requirements

• Large withdraw permissions MUST require hardware anchored login
• Large withdraw requests MUST be require hardware anchored signature
• Large withdraw requests MUST be verified on transaction signing system

Reference Design

• Ensure all users wishing to withdraw significant value short period are using FIDO2 or PGP capable smartcard.
  • E.G. Webauthn: Android 7.0+, iOS 14+, MacOS 10.15+, Win10 1809+, ChromeOS, Yubikey 5, Nitrokey, Ledger, Trezor
  • Consider software-based WebAuthn/U2F as a backup
• Ensure backend systems will only approve large withdrawls if signed by known hardware token.
• Ensure all transacton approval keys are stored in a tamper evident append only database.
• Ensure all key additions are authenticated with old key
• Consider allowing quorum of support engineer keys to enroll a new key to handle lost keys
• Use hash of transaction signing request as challenge in to be signed by smartcard
• Blockchain signature only issued after verification a given request is signed by authorized user smartcard(s)

Level 2

Threat Model

• Adversary is a skilled and resourceful individual targeting one custodian.
• Adversary can:
  • Compromise one production engineer.
  • Inject code into any OSS library without well funded maintainers
  • Exploit any vulnerability within 24h of public knowledge

Requirements

• All production access:
  • MUST NOT be possible by any single engineer
    • Consider a bastion that can enforce m-of-n access over SSH or similar
  • MUST be via dedicated tamper evident operating sytems
    • Consider: https://github.com/hashbang/book/blob/master/content/docs/security/Production_Engineering.md
  • MUST be anchored to keys in dedicated HSMs held by each administrator
    • Consider GnuPG or PKSC#11 devices that support touch-approval for ssh
• Any code in the transaction signing trust supply chain:
  • MUST build deterministically
  • MUST have extensive and frequent review.
    • Example: The Linux kernel has well funded distributed review.
  • MUST be signed in version control systems by well known author keys
  • MUST be signed by separate subject matter expert after security review
    • If third party code: it MUST be hash-pinned at known reviewed versions
  • MUST be at version with all known related security patches
  • SHOULD be latest versions if security disclosures lag behind releases
    • Example: The Linux kernel
  • MUST be built and signed by multiple parties with no management overlay
    • Example: One build by IT, another by Infrastructure team managed CI/CD
  • MUST be signed by well known keys signed by a common CA
    • Example: PGP Smartcards signed under OpenPGP-CA.
  • All private keys involved:
    • MUST NOT ever come in contact with network accessible memory
  • All execution environments MUST be able to attest what binary they run
    • Examples:
      • Custom Secure Boot verifies minimum signatures against CA
      • Cloud enclave that can remotely attest it uses a multi-signed image
        • AWS Nitro Enclave, Google Sheilded VMs, etc.
      • App phone stores already anchor to developer held signing keys

Reference Design

• Extend reference design from Level 1
• Create offline CA key(s)
  • Consider OpenGPG key generated on airgap, backed up, and copies transmitted to a smartcards such as a Yubikey
• CA key smartards are stored in dual-access tamper evident locations
• User key management secure enclave is created
  • Enclave is immutable with no ingress internet access
  • Enclave has random ephemeral key
  • Remotely attested on bootup againest multi-signed and known determinisically built system image
    • Possible on many PCR based measured boot solutions like Heads, AWS Nitro Enclaves, or GCP Shielded VMs
  • Ephemeral enclave key is signed with offline CA key(s) on verification.
  • Enclave has ability to validate append only database of keys
  • Enclave will sign new key additions/removals with ephemeral key if:
    • User has no prior keys
    • Key was signed with an existing key
    • Key was signed with 2+ known support enginneer keys
• Signing key generation
  • M-of-N keyholder quorum is selected
    • Should ideally be on different teams
    • Should ideally live geographically separated
    • Should have their own OpenPGP smartcard with pin and keys only they control.
  • Shard keys generated
    • Should be an additional OpenPGP smartcard separate from holders personal key
    • Should have random pin, encrypted to a backup shard holder
    • Should be stored in a neutral location only the primary and backup shardholder can access
  • Done in person on airgap laptop that has been in dual witnessed custody since procurement
    • Has hardware anchor that can make all parties confient the OS image it is running is expected (Heads, etc)
    • Has two hardware sources of entropy
    • Runs known deterministic and immutable OS image compiled by multiple parties
  • Key is generated and stored
    • Split to m-of-n shamirs secret sharing shards
      • Each shard is encrypted to dedicated shard OpenPGP Smartcard
      • Shard smartcard pin is generated randomly
      • Shard smartcard pin is encypted to personal smartcards of primary and backup holders
• Signing enclave is created
  • Is immutable with no ingress internet access
  • Has random ephemeral key
  • Remotely attested on bootup against multi-signed and known determinisically built system image
  • Will accept shamirs secret sharing shards encrypted to it
  • Will restore signing key to memory when sufficient shards are submitted
  • Will only sign transactions if accompanied by signed request by authorized user
    • Is able to validate signing request via CA key authorized user key management enclave signature
  • Will only sign transactions that meet predefined size and rate limits by company policy and insurance levels.

Level 3

Threat Model

• Adversary is an organized group with significant funding.
• Adversary can:
  • Compromise one datacenter engineer into tampering with a target system
  • Use a sophisticated 0day to compromise any one internet connected system

Requirements

• All transactions MUST be signed by multiple locations to be valid on chain
• Consider open source and well vetted MPC or on-chain threshold signing
• Locations MUST be separated by hours of travel
• Locations MUST not have any staff overlap
• Signing locations SHOULD distrust other locations
  • Each location SHOULD do their own reproducible build validation
  • Each location SHOULD do their own verifications on all large transactions

Level 4

Threat Model

• Adversary is a state actor.
• Adversary can:
  • Tamper with the supply chain of any single hardware/firmware component
  • Quickly relocate any device to a lab environment
  • Use sophisticated key exfiltration tactics
    • Acoustic (DiskFiltration, Fansmitter, Acoustic Cryptanalysis)
    • Optical (VisiSploit, xLED)
    • Thermal (BitWhisper)
    • Electrical (Differential Power Analysis, Power usage monitoring)
    • Magnetic (ODINI)
    • Electromagnetic (USBee)
    • Radio (NFCDrip, Vapor Trail, RFID, FM, Wifi, Bluetooth, GSM, etc)
    • Steganography
    • Non-deterministic encryption/signatures/data
    • Differential fault analysis
    • Data remanence

Requirements

• All signing systems:
  • MUST have dual implementations of all policy enforcement and signing logic
  • MUST use two or more unrelated hardware supply chains
    • Example: Rust on RISC-V Linux on an FPGA vs C on PPC Gemalto enclave
  • MUST return deterministic results
    • Results are only exported for chain broadcast if identical
  • MUST be stored in near zero emissions vaults a single user can't open
    • See: NSA TEMPEST
  • MUST only communicate with outside world via fiber optic serial terminal
  • MUST be housed in Class III bank vault or better
  • MUST have constant environment deviation monitoring
    • Thermal, Acoustic, Air quality, Optical
  • MUST destroy key material on significant environment deviations.
  • MUST be accessible physically with cooperative physical access
    • Consider FF-L-2740B or better locks with dual pin enforcement
    • Consider dual biometric enforcement to get near area and disarm security

Nice Doc! 👁️ 🚀 📑

Nation State Thoughts 🗺️ 😟

Regarding this section:
https://gist.github.com/lrvick/373a42da700e33c39e30dbc2b65d880f#level-4
I think the "Adversary can:" for state-sponsored actor(s) is worth enumerating extensively.
There are tons of things nation states can do (they are limited only by their creativity, audacity, and cunning). Money is no problem for them...they can just print more am-i-right? 🤑 💸 💰 💵 :brrrrrrrr:
I wonder how much budget nation states put into implanting moles into various companies/universities/etc

Thoughts on References 📚

One thing I think that is missing from this document is historical context of attacks (e.g. references).
Everything you are saying is legit, and perhaps this doc doesn't need to have an extensive bibliography. But I think it makes it easier to digest for new people. Each reference is a link down another rabbit hole of security that perhaps they have never been down before. The threats in this space are as varied and creative as our human minds can make them. I like composing this doc in sections of 'effort'.

For recent state-sponsored attacks, I think Alexey Navalny's Evil Housekeeper Underwear Poisoning Attack (Bellingcat Published Article, 2020).

For software supply-chain attacks, there is starting to be larger and larger collection of attacks.
Specifically with crypto-custodians, the most famous might be npm's event-stream collaborator/maintainer takeover--NPM's blog post on the attack (2018).

There's also a lot of context from historical documents you've manifested (i.e, Talos's Software Supply-Chain Security RFC, production engineering, early software supply chain work, etc).
These documents add a lot of color to how you derived some of these specifications/requirements.
Throw this up on book.hashbang.sh and we can crowdsource a bibliography or something 📖

---

All, in all, thanks for creating this :)
I owe you a beer 🍻

Also, this is a thing that's worth taking a look at too: https://cryptoconsortium.github.io/CCSS/

CCSS covers a list of 10 security aspects of an information system that stores, transacts with, or accepts cryptocurrencies. An information system is a collection of technologies (hardware and/or software), personnel, policies and procedures that work together to provide a secure environment. A security aspect is a discrete technique of securing one piece of an information system. The minimum value of all 10 aspects determines an information system’s overall score within three (3) levels of increasing security: Level I is the lowest and offers strong security measures, while Level III is the highest and offers the most comprehensive security.

Consider dual biometric enforcement to get near area and disarm security

I'm assuming you may also put this on top of some sort of pin/passphrase based entry? Since almost all biometric devices have been proven beatable. Then you get all the benefits of something you: have, know and are

The addition of duress codes would probably also be good for triggering silence alarms and shredding any private key material from running offline systems

Maybe this is out of scope right now but it feels like having a separate enclave dedicated to derivation, only containing xpub would be useful and welcome in a complete reference implementation. Something like:

Address derivation enclave is created
* Is immutable with no ingress internet access
* Has random ephemeral key
* Remotely attested on boot-up against multi-signed and known deterministically built system image
* Will accept shamir’s secret sharing shards (only for xpub) encrypted to it
* Will restore xpub to memory when sufficient shards are submitted
* Signs all derived bundles 
* Follows a standard derivation schema for the appropriate currency (BIP32 for BTC)

Essentially it's a clone of the signing enclave, but only contains a xpub and derives addresses. Additionally, we'd describe steps and requirements around preparing the xpub key.