public
/
docs
5
0
Fork 0
Code Issues 21 Pull Requests 2 Packages Projects Releases Wiki Activity

refactor and clean up threat model doc

This commit is contained in:
Anton Livaja 2024-12-05 15:46:29 -05:00
parent 1e9d21dcdd
commit 36a64ca6f3
Signed by: anton
GPG Key ID: 44A86CFF1FDF0E85
2 changed files with 84 additions and 84 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
quorum-key-management/src/side-channel-attacks.md Normal file
View File

@ -0,0 +1,18 @@
# Side Channel Attacks
* Acoustic (DiskFiltration, Fansmitter, Acoustic Cryptanalysis, sonic cavity resonators, etc.)
* Optical (VisiSploit, xLED, eavesdropping via vibration analysis etc.)
* Thermal (BitWhisper)
* Electrical (Simple Power Analysis (SPA), Differential Power Analysis)
* Magnetic (ODINI)
* Electromagnetic (USBee)
* Exfiltrating data via induction of power lines, water pipes, telephone lines, coaxial cable used for televisions and internet etc.
* Radio (NFCDrip, Vapor Trail, RFID, FM, Wifi, Bluetooth, GSM, SATA cable eavesdropping etc)
* Steganography

114
quorum-key-management/src/threat-model.md
View File

@ -70,13 +70,14 @@ Different threat model levels allow an organization to start benefiting from the
Each subsequent level assumes all threats and mitigations from the previous level, and introduces more sophisticated attacks and mitigations. As such, the levels should for the most part be adhered to one at a time, to ensure comprehensive defenses for all viable threats enumerated herein. Each subsequent level assumes all threats and mitigations from the previous level, and introduces more sophisticated attacks and mitigations. As such, the levels should for the most part be adhered to one at a time, to ensure comprehensive defenses for all viable threats enumerated herein.
### Level 1 ## Level 1
#### Threat Model ### Threat Model
* Adversary is a low skilled individual targeting many custodians. This implies the adversary is not highly focused on compromising a specific custodian, but often relying on more scattered/shotgun strategies. #### Adversary
Low skilled individual targeting many organizations. This implies the adversary is not highly focused on compromising a specific organization, and relies on less sophisticated strategies.
* Adversary is capable of: #### Attacks
* Using phishing to steal data from a random set of custodian end users * Using phishing to steal data from a random set of custodian end users
@ -88,9 +89,7 @@ Each subsequent level assumes all threats and mitigations from the previous leve
* MUST require hardware anchored signature for large withdrawal requests * MUST require hardware anchored signature for large withdrawal requests
* MUST verify withdrawal requests * MUST verify withdrawal requests according to a threshold based policy
Refer to [threshold based policies](TODO) for defining "large withdrawals" and related policies.
#### Reference Design #### Reference Design
@ -120,9 +119,11 @@ Refer to [threshold based policies](TODO) for defining "large withdrawals" and r
### Threat Model ### Threat Model
* Adversary is a skilled and resourceful individual targeting one custodian #### Adversary
* Adversary can: Adversary is a skilled and resourceful individual targeting one organization. This type of attacker uses a combination of widely used cyber weapons, OSINT, social engineering (spear phishing), exploiting vulnerabilities, MitM attacks.
#### Attacks
* Compromise one team member with privileged access * Compromise one team member with privileged access
@ -136,7 +137,9 @@ Refer to [threshold based policies](TODO) for defining "large withdrawals" and r
* MUST NOT be possible by any single engineer * MUST NOT be possible by any single engineer
* Consider a bastion that can enforce m-of-n access over SSH or similar * Consider a bastion that can enforce m-of-n access over ssh
* Consider hardened deployment pipeline which requires m-of-n cryptographic signatures to perform action
* MUST be via dedicated tamper evident workstation * MUST be via dedicated tamper evident workstation
@ -144,7 +147,7 @@ Refer to [threshold based policies](TODO) for defining "large withdrawals" and r
* MUST be anchored to keys in dedicated HSMs held by each administrator * MUST be anchored to keys in dedicated HSMs held by each administrator
* Consider GnuPG or PKSC#11 smart cards that support touch-approval for ssh * Consider OpenPGP or PKSC#11 smart cards that support touch-approval for ssh
* Any code in the transaction signing trust supply chain: * Any code in the transaction signing trust supply chain:
@ -152,29 +155,23 @@ Refer to [threshold based policies](TODO) for defining "large withdrawals" and r
* MUST have extensive and frequent review * 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 in version control systems by well known author keys
* Example: OpenPGP signed git commits
* MUST be signed by separate subject matter expert after security review * 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 hash-pin third party code at known reviewed versions
* MUST be at version with all known related security patches * MUST be at version with all known related security patches
* SHOULD be latest versions if security disclosures lag behind releases otherwise N-2 * SHOULD be latest versions if security disclosures lag behind releases otherwise N-2
* Example: The Linux kernel * MUST be built and signed (and hashes compared) by multiple parties with no management overlay
* MUST be built and signed by multiple parties with no management overlay
* Example: One build by IT, another by Infrastructure team managed CI/CD * Example: One build by IT, another by Infrastructure team managed CI/CD
* MUST be signed by well known keys signed by a common CA * MUST be signed by well known keys signed by a common CA
* Example: PGP Smartcards signed under OpenPGP-CA. * Example: OpenPGP smart cards signed under OpenPGP-CA.
* All private keys involved: * All private keys involved:
@ -188,14 +185,12 @@ Refer to [threshold based policies](TODO) for defining "large withdrawals" and r
* Cloud enclave that can remotely attest it uses a multi-signed image * Cloud enclave that can remotely attest it uses a multi-signed image
* AWS Nitro Enclave, Google Shielded VMs, etc. * TPM2, AWS Nitro Enclave, Google Shielded VMs etc.
* App phone stores already anchor to developer held signing keys * App phone stores already anchor to developer held signing keys
### Reference Design ### Reference Design
* Extend reference design from Level 1
* Create offline CA key(s) * Create offline CA key(s)
* Consider OpenGPG key generated on airgap using keyfork, backed up, and copies transmitted to a smart cards such as a Yubikey * Consider OpenGPG key generated on airgap using keyfork, backed up, and copies transmitted to a smart cards such as a Yubikey
@ -210,7 +205,7 @@ Refer to [threshold based policies](TODO) for defining "large withdrawals" and r
* Remotely attested on boot-up against multi-signed and known deterministically built system image * Remotely attested on boot-up against multi-signed and known deterministically built system image
* Possible on many PCR based measured boot solutions like Heads, AWS Nitro Enclaves, or GCP Shielded VMs * Possible on many PCR based measured boot solutions based on TPM2 and Heads, AWS Nitro Enclaves, or GCP Shielded VMs
* Ephemeral enclave key is signed with offline CA key(s) on verification. * Ephemeral enclave key is signed with offline CA key(s) on verification.
@ -228,17 +223,17 @@ Refer to [threshold based policies](TODO) for defining "large withdrawals" and r
* M-of-N key holder quorum is selected * M-of-N key holder quorum is selected
* SHOULD ideally be on different teams * SHOULD be on different teams
* SHOULD ideally live in different geographical zones to mitigate natural disaster, and war risk * SHOULD live in different geographical zones to mitigate natural disaster, and war related risks
* SHOULD have their own OpenPGP smart card with pin and keys only they control * SHOULD have their own OpenPGP smart card with pin and keys only they control
* Shard keys generated * Shard keys
* SHOULD be an additional OpenPGP smart card separate from holders personal key * SHOULD be an additional OpenPGP smart card separate from holder's personal key
* SHOULD have random pin, encrypted to a backup shard holder * SHOULD have random PIN, encrypted to a backup shard holder
* SHOULD be stored in a neutral location only the primary and backup shard holder can access * SHOULD be stored in a neutral location only the primary and backup shard holder can access
@ -252,6 +247,10 @@ Refer to [threshold based policies](TODO) for defining "large withdrawals" and r
* There are devices that can provide an additional source of entropy such as: * There are devices that can provide an additional source of entropy such as:
* Computer with another architecture such as RISC-V
* HSM which can export entropy
* Quantis QRNG USB * Quantis QRNG USB
* TrueRNG * TrueRNG
@ -264,35 +263,36 @@ Refer to [threshold based policies](TODO) for defining "large withdrawals" and r
* Each shard is encrypted to dedicated shard OpenPGP smart card * Each shard is encrypted to dedicated shard OpenPGP smart card
* Shard smart card pin is generated randomly * Shard smart card PIN is generated randomly
* Shard smart card pin is encrypted to personal smart cards of primary and backup holders * Shard smart card PIN is encrypted to personal smart cards of primary and backup holders
#### Signing System #### Signing System
* Uses an enclave which is immutable with no ingress internet access * Uses an enclave which is immutable with no ingress internet access
* Has random ephemeral key * Has enclave bound ephemeral key
* Remotely attested on boot-up against multi-signed and known deterministically built system image * Remotely attested on boot-up against multi-signed and known deterministically built system image
* Will accept Shamir's Secret Sharing shards encrypted to random ephemeral key * Will accept Shamir's Secret Sharing shards encrypted to enclave bound ephemeral key
* Will restore signing key to memory when sufficient shards are submitted * Will restore signing key to memory when sufficient shards are submitted
* Will only sign transactions if accompanied by signed request by authorized user * Will only sign transactions if accompanied by signed request by authorized user according to a quorum specified by a policy
* Is able to validate signing request via CA key authorized user key management enclave signature * 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. * Will only sign transactions that meet predefined size and rate limits by company policy and insurance levels
## Level 3 ## Level 3
### Threat Model ### Threat Model
* Adversary is an organized group with significant funding #### Adversary
Adversary is an organized group with significant funding. These groups consist of individuals with different skill sets and often have access to significant funds, drastically expanding their attack capabilities.
* Adversary can: #### Attacks
* Compromise one data center engineer into tampering with a target system * Compromise one data center engineer into tampering with a target system
@ -304,47 +304,31 @@ Refer to [threshold based policies](TODO) for defining "large withdrawals" and r
* Consider well vetted open source multi signature, MPC or on-chain threshold signing software * Consider well vetted open source multi signature, MPC or on-chain threshold signing software
* Locations MUST be separated by hours of travel * MUST use locations separated by hours of travel
* Locations MUST not have any staff overlap * MUST have independent staff for separate locations
* Signing locations SHOULD distrust other locations * Signing locations MUST NOT trust other locations
* Each location SHOULD do their own reproducible build validation * Each location MUST do their own reproducible build validation
* Each location SHOULD do their own verifications on all large transactions * Each location MUST do their own verifications on all large transactions
## Level 4 ## Level 4
### Threat Model ### Threat Model
* Adversary is a state actor #### Adversary
* Adversary can: Adversary is a state actor. State actors are the best funded and most sophisticated attackers. They are the highest known threat and have the ability to execute all known attacks. Their well funded operations allow them to pursue goals over long periods of time, relying on subversion, false flags, insider threats via planting moles, compromise of hardware supply and software supply chains, the use of advanced non-commercially available cyber-warfare tools, combining many 0day vulnerabilities to construct highly effective exploit chain. This level of adversary demands the highest known standards of security, which is typically upheld only by the most sophisticated companies and the military.
#### Attacks
* Tamper with the supply chain of any single hardware/firmware component * Tamper with the supply chain of any single hardware/firmware component
* Quickly and covertly relocate any device to a lab environment, complete attacks within a short time period, and return the device to its original location * Quickly and covertly relocate any device to a lab environment, complete attacks within a short time period, and return the device to its original location
* Use sophisticated side channel attacks for exfiltrating data, cryptographic material being a high risk target * Use sophisticated [side channel attacks](side-channel-attacks.md) for exfiltrating data, cryptographic material being a high risk target
* Acoustic (DiskFiltration, Fansmitter, Acoustic Cryptanalysis, sonic cavity resonators, etc.)
* Optical (VisiSploit, xLED, eavesdropping via vibration analysis etc.)
* Thermal (BitWhisper)
* Electrical (Simple Power Analysis (SPA), Differential Power Analysis)
* Magnetic (ODINI)
* Electromagnetic (USBee)
* Radio (NFCDrip, Vapor Trail, RFID, FM, Wifi, Bluetooth, GSM, SATA cable eavesdropping etc)
* Steganography
* Use other sophisticated attack types such as:
* Non-deterministic encryption/signatures/data * Non-deterministic encryption/signatures/data
@ -352,15 +336,13 @@ Refer to [threshold based policies](TODO) for defining "large withdrawals" and r
* Data remanence * Data remanence
* Exfiltrating data via induction of power lines, water pipes, telephone lines, coaxial cable used for televisions and internet etc.
### Requirements ### Requirements
* All signing systems: * All signing systems:
* MUST have dual implementations of all policy enforcement and signing logic * MUST have dual implementations of all policy enforcement and signing logic
* MUST use two or more unrelated hardware supply chains * MUST use two or more unrelated hardware supply chains for generating cryptographic material
* Example: Rust on RISC-V Linux on an FPGA vs C on PPC Gemalto enclave * Example: Rust on RISC-V Linux on an FPGA vs C on PPC Gemalto enclave