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

start anchor refactor

This commit is contained in:
Anton Livaja 2024-12-09 16:32:25 -05:00
parent b119b0f742
commit fd16079f88
Signed by: anton
GPG Key ID: 44A86CFF1FDF0E85
3 changed files with 167 additions and 158 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

116
quorum-key-management/src/fixed-location-reusable-laptop-ceremony.md
View File

@ -1,58 +1,9 @@
# Fixed Location Reusable Laptop Ceremony
1. Select at least two authorized operators who will be participating in the ceremony
2. Print photographs of tamper proofing of the laptop which will be used for the ceremony
3. Make an entry into the access log, specifying the:
* Individuals involved
* Approximate time of entry
4. Enter the SCIF, ensuring to lock the door behind you from the inside. The room should not be accessible from the outside during a ceremony.
5. Access the laptop safe, and move the laptop, its hardware token, and polaroid to the Tamper Proofing Workstation
* Compare the polaroid and digital photographs for any differences
* Then compare the photographs to the actual object
* If there are any issues detected, initiate incident response
6. Initiate the [Secure Boot Sequence](secure-boot-sequence.md)
7. Use one of the [Coin Playbooks]() to perform actions for a given coin
* TODO...
8. Once the ceremony is completed, use the [Sealing Procedure](tamper-evidence-methods.md#procedure) to reseal and photograph the laptop
* Use a new SD card for taking photographs of the sealed laptop
9. Remove the SD card from the camera and use chain of custody principles to ensure the integrity of the data
10. Place the sealed laptop and signed polaroids, as well as the hardware token back in the safe
11. Exit the SCIF and lock it
12. Update the log with the exit time
13. Upload the photos to a git repository, ensuring the commit is signed using PGP
* TODO: add more details around how the storage of images should work
* TODO: ensure there is a pgp doc that can be linked to (for setup and use)
---
TODO: integrate this
### Fixed Location Device
This device is intended for use in a secure facility such as a [SCIF](TODO) which has the added assurances of protecting the environment from a wide range of side-channel attacks, as well as protection from physical attacks, and more comprehensive tamper proofing controls.
The fixed location should include a work-station which makes it easy to perform the [tamper proofing](todo) procedure. This station may consist of a simple frame which holds a LED light, for consistent lightning, as well as a camera stand above it which can be used to take pictures. The camera should have an SD card that easily slides out of it so that the device doesn't leave and re-enter the room, only the SD card does.
The fixed location should include a work-station which makes it easy to perform the [tamper proofing](tamper-evidence-methods.md#tamper-proofing-station) procedure. This station may consist of a simple frame which holds a LED light, for consistent lightning, as well as a camera stand above it which can be used to take pictures. The camera should have an SD card that easily slides out of it so that the device doesn't leave and re-enter the room, only the SD card does.
* TODO: this is actually not necessary for the fixed location device, but it's good to have this setup in the same facility maybe for processing/setting up the one time use laptops
The primary tamper proofing methods for the fixed location device are:
@ -65,21 +16,54 @@ The primary tamper proofing methods for the fixed location device are:
* Physical vault (TODO find adequate vaults)
#### Procedure
## Procedure
If at any moment one of the individual has to leave, the Sealing procedure should be performed and both parties should exit the room. For prolonged sessions consider having 3 operators present in order to be able to have 1 individual leave while still having 2 witnesses present in the operating room.
### Unsealing
##### Unsealing
* TODO (before entering room review monitoring video / audio to see if there was intrusion)
1. Ensure that there are at least 2 individuals present who are authorized present before entering the facility
2. Ensure that nobody is carrying any type of electrical device on them. To achieve this a metal detection gate or a hand-held metal detector may be used
3. Gain access to the safe, and take out a laptop which will be used for performing cryptographic actions
4. Check the screws on the bottom of the laptop to ensure that they have not been removed
4. Use the hardware token set up for that laptop in order to verify that the laptop firmware has not been tampered
5. Proceed with [booting sequence](TODO) depending on the type of action being performed
1. Select at least two authorized operators who will be participating in the ceremony
##### Sealing
1. Shut down machine
2. Remove and store the hardware token in it's appropriate location
3. Place the laptop in the safe and lock it
4. Exit the facility.
2. Print photographs of tamper proofing of the laptop which will be used for the ceremony
* Both photos of vacuum sealed bar with filler and glitter on the bottom screws of laptop are required
- [ ] TODO how is hardware token stored (for pureboot/heads)
3. Make an entry into the access log, specifying the:
* Individuals involved
* Approximate time of entry
4. Enter the SCIF, ensuring to lock the door behind you from the inside. The room should not be accessible from the outside during a ceremony.
* Ensure that no individual is bringing in any electronic devices. A hand-held or gate metal detector can be used for this.
5. Access the laptop safe, and move the laptop, its hardware token, and polaroid to the Tamper Proofing Workstation
* Compare the polaroid and digital photographs for any differences
* Then compare the photographs to the actual object
* Check the glitter on the bottom screws of the laptop ensuring there are no scratch marks, and compare the screws to photos
* If there are any issues detected, initiate incident response
6. Initiate the [Secure Boot Sequence](secure-boot-sequence.md)
{{ #include secure-boot-sequence.md }}
7. Use one of the [Playbooks](todo) to carry out a task
#### Sealing
{{ #include tamper-evidence-methods.md:vsbwf-procedure-sealing}}
2. Remove the SD card from the camera and use chain of custody principles to ensure the integrity of the data
3. Place the sealed laptop and signed polaroids, as well as the hardware token back in the safe
4. Exit the SCIF and lock it
5. Update the log with the exit time
6. Upload the photos to a git repository, ensuring the commit is signed using PGP

65
quorum-key-management/src/tamper-evidence-methods.md
View File

@ -1,3 +1,6 @@
/* ANCHOR: all */
// ANCHOR: entire-doc
# Tamper Evidence Methods
There are different methods which can be used to ensure that objects have not been tampered between uses. This is especially relevant for equipment such as laptops. Each method comes with tradeoffs, and in the context of high assurance security it is instrumental to understand the tradeoffs in order to achieve an adequate level of confidence that supplies such as computers used for high risk operations retain their integrity.
@ -22,17 +25,6 @@ There are three reasonably secure methods which have been identified and are exp
* Heads / Pureboot for secure boot
## Vacuum Sealed Bags With Filler
One of the most reliable methods for ensuring tamper evidence relies on the randomness and difficulty of placing small objects henceforth referred to as "filler" (colored rice, lentils, confetti) in a transparent bag to encase an object which is then vacuum sealed. By placing an object in a transparent, vacuum sealable bag and surrounding it with filler, an arrangement of the filler around the object in the bag can be achieved which is difficult to reproduce. Upon sealing the object in this manner, photos can be taken to use as a reference once the object is accessed again - allowing one to verify that the arrangement of the filler has not changed.
### Threat Model
There are no known attacks for this type of tamper proofing method when executed properly. The main sources of risk stem from consistent and repeatable photography and comparison of photographs to ensure that any changes can be detected.
If photographs are not cryptographically signed, they can also be manipulated and/or replaced which could result in the compromise of the system as well.
The reason this method is effective is because unlike with many other methods that tamper proof a specific part of an object, such as applying glitter to screws which leaves device ports exposed, or using cryptographic signing to verify the hardware has not been modified, still leaving the door to physical modifications, vacuum sealing with colored filler encases the entire object in a tamper evident manner.
#### Level 1 + 2
@ -62,6 +54,19 @@ This is the highest threat level and as such requires additional controls which
* MUST have continued surveillance of the storage location
## Vacuum Sealed Bags With Filler
// ANCHOR: vsbwf-whole
One of the most reliable methods for ensuring tamper evidence relies on the randomness and difficulty of placing small objects henceforth referred to as "filler" (colored rice, lentils, confetti) in a transparent bag to encase an object which is then vacuum sealed. By placing an object in a transparent, vacuum sealable bag and surrounding it with filler, an arrangement of the filler around the object in the bag can be achieved which is difficult to reproduce. Upon sealing the object in this manner, photos can be taken to use as a reference once the object is accessed again - allowing one to verify that the arrangement of the filler has not changed.
### Threat Model
There are no known attacks for this type of tamper proofing method when executed properly. The main sources of risk stem from consistent and repeatable photography and comparison of photographs to ensure that any changes can be detected.
If photographs are not cryptographically signed, they can also be manipulated and/or replaced which could result in the compromise of the system as well.
The reason this method is effective is because unlike with many other methods that tamper proof a specific part of an object, such as applying glitter to screws which leaves device ports exposed, or using cryptographic signing to verify the hardware has not been modified, still leaving the door to physical modifications, vacuum sealing with colored filler encases the entire object in a tamper evident manner.
### Adequate Filler
To achieve the best level of randomness and difficulty of reproducing the arrangement of filler in a vacuum sealed bag, a variety of beads of different sizes and color should be used. They may be made of different materials as well but plastic is excellent because it doesn't change form when vacuum sealed - which can make it easier to reproduce patterns. Materials such as confetti and packing beans may be used, but because they can be flattened and retain the shape, arranging them in a given pattern is much easier. Other options like beans or lentils have less variety in color and shapes which makes it harder to detect differences.
@ -92,27 +97,42 @@ Sealing bags of standard size objects which need to be protected can fit in. The
* A similar method can be used but with a bin filled with filler that the object is placed into. The main disadvantage here is that this type of tamper proofing is not resistant to seismic activity, air movement, or other sourced of vibration which could shift filler around.
### Procedure
// ANCHOR: vsbwf-procedure
#### Requirements
* [Vacuum sealer](#vacuum-sealers)
* [Vacuum sealer](tamper-evidence-methods.md#vacuum-sealers)
* [Vacuum plastic roll](#vacuum-sealers)
* [Vacuum plastic roll](tamper-evidence-methods.md#vacuum-sealers)
* [Filler](#adequate-filler)
* [Filler](tamper-evidence-methods.md#adequate-filler)
#### Sealing
// ANCHOR: vsbwf-procedure-sealing
1. Insert object into plastic bag
2. Fill bag with enough plastic beads that all of the object is surrounded
3. Use vacuum sealer to remove air from the bag until the beads are no longer able to move
4. Use the [Tamper Proofing Station](#tamper-proofing-station) to take a photograph of both sides of the sealed object using both the digital and polaroid camera
5. Take the SD card to an online connected device and commit the photograph to a repository, ensuring the commit is signed
2. Fill bag with enough plastic beads that all of the object is surrounded
3. Use vacuum sealer to remove air from the bag until the beads are no longer able to move
4. Use the [Tamper Proofing Station](tamper-evidence-methods#tamper-proofing-station) to take a photograph of both sides of the sealed object using both the digital and polaroid camera
5. Take the SD card to an online connected device and commit the photograph to a repository, ensuring the commit is signed
// ANCHOR_END: vsbwf-procedure-sealing
// ANCHOR: vsbwf-procedure-unsealing
#### Unsealing
1. Retrieve photographs which were taken of the sealed object and print them out, one copy for each operator
2. Use the photographs and compare them to the sealed object, ensuring the arrangement of the filler in the sealed bag is the same on both sides of the object
3. If there is no noticeable difference, proceed with unsealing the object, otherwise initiate an incident response process.
// ANCHOR_END: vsbwf-procedure-unsealing
// ANCHOR_END: vsbwf-procedure
// ANCHOR_END: vsbwf-whole
## Glitter on Screws
@ -134,7 +154,7 @@ Glitter can be used as an additional control to provide tamper evidence on speci
4. Repeat steps 2, 3 with the different types of glitter being used
5. Take a photograph of the laptop, preferably using the [tamper proofing station](#tamper-proofing-station)
5. Take a photograph of the laptop, preferably using the [tamper proofing station](tamper-evidence-methods#tamper-proofing-station)
#### Verification
@ -172,6 +192,10 @@ To construct an appropriate Tamper Proofing Station, the simplest setup consists
Pick a location for the station, and attach the LED light and the camera to the overhead camera mounting rig. Set up the camera so that when it's turned on, a 14" laptop is perfectly framed without having to zoom in or out if possible.
## Safe
Placing objects into a safe helps improve the security of objects, and introduces an additional layer of tamper evidence.
## References
* [Blog About Tamper Evident Protection Methods](http://web.archive.org/web/20241130002204/https://dys2p.com/en/2021-12-tamper-evident-protection.html)
@ -183,3 +207,6 @@ Pick a location for the station, and attach the LED light and the camera to the
* [Purism anti-interdiction](http://web.archive.org/web/20241121233006/https://puri.sm/posts/anti-interdiction-services/)
* [Purism Liberty phone anti-interdiction](http://web.archive.org/web/20240903104700/https://puri.sm/posts/anti-interdiction-on-the-librem-5-usa/)
// ANCHOR_END: entire-doc
/* ANCHOR_END: all */

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

@ -68,7 +68,7 @@ Some additional assumptions are made to help contextualize the threat model:
Different threat model levels allow an organization to start benefiting from the security properties of the QKM system immediately, with a clear path to upgrading over time as resources and time become available.
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
@ -85,7 +85,7 @@ Low skilled individual targeting many organizations. This implies the adversary
#### Requirements
* MUST require hardware anchored login for large withdrawals
* MUST require hardware anchored login for large withdrawals
* MUST require hardware anchored signature for large withdrawal requests
@ -99,7 +99,7 @@ Low skilled individual targeting many organizations. This implies the adversary
* Android 7.0+, iOS 14+, MacOS 10.15+, Win10 1809+, ChromeOS, Yubikey 5, Nitrokey, Ledger, Trezor
* Consider software-based WebAuthN/Passkey/U2F as backup
* Consider software-based WebAuthN/Passkey/U2F as backup
* Ensure backend systems will only approve large withdrawals if signed by known smart card.
@ -141,8 +141,8 @@ Adversary is a skilled and resourceful individual targeting one organization. Th
* 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
* 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
@ -150,61 +150,61 @@ Adversary is a skilled and resourceful individual targeting one organization. Th
* Consider OpenPGP or PKSC#11 smart cards that support touch-approval for ssh
* Any code in the transaction signing trust supply chain:
* MUST build deterministically
* MUST have extensive and frequent review
* MUST be signed in version control systems by well known author keys
* MUST be signed by separate subject matter expert after security review
* MUST hash-pin third party code at known reviewed versions
* MUST be at version with all known related security patches
* SHOULD be latest versions if security disclosures lag behind releases otherwise N-2
* MUST be built and signed (and hashes compared) 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: OpenPGP smart cards 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
* TPM2, AWS Nitro Enclave, Google Shielded VMs etc.
* App phone stores already anchor to developer held signing keys
### Reference Design
* 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
* CA key smart cards are stored in dual-access tamper evident locations
#### User Key Management System
#### User Key Management System
* Enclave is created which is immutable with no ingress internet access
* Enclave has random ephemeral key
* Remotely attested on boot-up against multi-signed and known deterministically built system image
* 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.
@ -212,45 +212,43 @@ Adversary is a skilled and resourceful individual targeting one organization. Th
* 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 engineer keys
#### Signing Key Generation
* M-of-N key holder quorum is selected
* SHOULD be on different teams
* 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
* Shard keys
* 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
* Done in person on air-gapped laptop that has been in dual witnessed custody since procurement
* TODO link to tamper chain of custody doc
* Done in person on air-gapped laptop that has been in [dual witnessed custody](hardware-procurement-and-chain-of-custody.md) since procurement
* Has hardware anchor that can make all parties confident the OS image it is running is expected (Heads, etc)
* Has two hardware sources of entropy
* 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
* TrueRNG
@ -258,17 +256,17 @@ Adversary is a skilled and resourceful individual targeting one organization. Th
* Runs known deterministic and immutable OS image compiled by multiple parties
* Key is generated and stored
* Split to m-of-n Shamir's Secret Sharing shards
* Each shard is encrypted to dedicated shard OpenPGP smart card
* Shard smart card PIN is generated randomly
* Shard smart card PIN is encrypted to personal smart cards of primary and backup holders
#### Signing System
* Uses an enclave which is immutable with no ingress internet access
* Has enclave bound ephemeral key
@ -280,7 +278,7 @@ Adversary is a skilled and resourceful individual targeting one organization. Th
* Will restore signing key to memory when sufficient shards are submitted
* 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
* Will only sign transactions that meet predefined size and rate limits by company policy and insurance levels
@ -293,7 +291,7 @@ Adversary is a skilled and resourceful individual targeting one organization. Th
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.
#### Attacks
* Compromise one data center engineer into tampering with a target system
* Use a sophisticated 0 day vulnerability to compromise any one internet connected system
@ -303,15 +301,15 @@ Adversary is an organized group with significant funding. These groups consist o
* MUST sign all transactions of significant value by multiple keys in separate geographical locations
* Consider well vetted open source multi signature, MPC or on-chain threshold signing software
* MUST use locations separated by hours of travel
* MUST have independent staff for separate locations
* Signing locations MUST NOT trust other locations
* Each location MUST do their own reproducible build validation
* Each location MUST do their own verifications on all large transactions
## Level 4
@ -323,7 +321,7 @@ Adversary is an organized group with significant funding. These groups consist o
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
* 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
@ -331,9 +329,9 @@ Adversary is a state actor. State actors are the best funded and most sophistica
* Use sophisticated [side channel attacks](side-channel-attacks.md) for exfiltrating data, cryptographic material being a high risk target
* Non-deterministic encryption/signatures/data
* Differential Fault Analysis (DFA)
* Data remanence
### Requirements
@ -341,38 +339,38 @@ Adversary is a state actor. State actors are the best funded and most sophistica
* All signing systems:
* MUST have dual implementations of all policy enforcement and signing logic
* 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
* 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 ensure that individuals are scanned for devices before entering the vault
* MUST only communicate with outside world via fiber optic serial terminal
- [ ] TODO do we even want this in the facility?
* 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
* TODO: methods for doing this
* MUST be accessible physically with cooperative physical access
* MAY use FF-L-2740B or better locks with dual pin enforcement
* MAY use dual biometric enforcement to get near area and disarm security
## Additional Threat Model Notes