diff --git a/crypto-asset-custody-threat-modeling.md b/crypto-asset-custody-threat-modeling.md new file mode 100644 index 0000000..5075b20 --- /dev/null +++ b/crypto-asset-custody-threat-modeling.md @@ -0,0 +1,184 @@ +# Crypto-Asset Custody Threat Modeling + +## Summary + +This document seeks to outline a broad set of threat models and risk mitigation +suggestions 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 +