clean up multiple docs
This commit is contained in:
parent
07eb55d673
commit
cae61ec25f
|
@ -3,7 +3,7 @@
|
|||
* [Threat Model](threat-model.md)
|
||||
* [Selecting a Quorum](selecting-quorum.md)
|
||||
* [System Roles](system-roles.md)
|
||||
* [Key Types](key-types.md)
|
||||
* [PGP Key Types](key-types.md)
|
||||
* [Software](software.md)
|
||||
* [Location](locations.md)
|
||||
* [Glossary](glossary.md)
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
/* ANCHOR: all */
|
||||
// ANCHOR: content
|
||||
Look for your SD card device name (`<device_name>`) in the output of the `lsblk` command. It will typically be listed as `/dev/sdX` or `/dev/mmcblk<num>`, where X is a letter (e.g., `/dev/sdb`, `/dev/sdc`). You can identify it by its size or by checking if it has a partition (like `/dev/sdX1`)
|
||||
* You may mount the device using: `sudo mount /dev/<your_device> /media`
|
||||
* Mount the device using: `sudo mount /dev/<your_device> /media`
|
||||
// ANCHOR_END: content
|
||||
/* ANCHOR_END: all */
|
||||
/* ANCHOR_END: all */
|
||||
|
|
|
@ -7,13 +7,13 @@ Git is used because it permits cryptographic singing of commits using PGP, as we
|
|||
|
||||
## Procedure: Setting up Repository
|
||||
// ANCHOR: procedure
|
||||
1. Create a git repository using a git system such as Forjego, GitLab, GitHub etc.
|
||||
1. Create a git repository using a git system such as Forgejo, GitLab, GitHub etc.
|
||||
|
||||
1. Set appropriate permissions to limit who can write to the repository.
|
||||
|
||||
* Require that all commits are signed using well known PGP keys
|
||||
* Require that all commits are signed using well known PGP keys
|
||||
|
||||
1. Optionally set up a chron job that periodically pulls the data from the repository as a backup.
|
||||
1. Optionally set up a cron job that periodically pulls the data from the repository as a backup.
|
||||
// ANCHOR_END: procedure
|
||||
/* ANCHOR_END: all */
|
||||
|
||||
|
|
|
@ -1,10 +1,6 @@
|
|||
/* ANCHOR: all */
|
||||
# OpenPGP Setup
|
||||
|
||||
Setting up a personal PGP key pair is necessary for a number of different
|
||||
aspects while bootstrapping QVS. The keys are a fundamental building block, and
|
||||
as such need to be set up in a manner that minimizes exposure risks.
|
||||
|
||||
## Generating Keys using `keyfork`
|
||||
// ANCHOR: steps-keyfork
|
||||
|
||||
|
@ -39,41 +35,41 @@ as such need to be set up in a manner that minimizes exposure risks.
|
|||
|
||||
// ANCHOR_END: steps-keyfork
|
||||
|
||||
## Generating Keys on Smartcard
|
||||
## Generating Keys on Smartcard
|
||||
// ANCHOR: steps-on-key-gen
|
||||
|
||||
1. Insert the smart card into the USB port if it is not already plugged in.
|
||||
|
||||
1. Open Command Prompt (Windows) or Terminal (macOS / Linux).
|
||||
|
||||
1. Enter the GPG command:
|
||||
1. Enter the GPG command:
|
||||
|
||||
* `gpg --card-edit`
|
||||
|
||||
1. At the gpg/card> prompt, enter the command: admin
|
||||
|
||||
|
||||
1. If you want to use keys larger than 2048 bits, run: key-attr
|
||||
|
||||
1. Enter the command: generate
|
||||
|
||||
1. When prompted, specify if you want to make an off-card backup of your encryption key.
|
||||
|
||||
|
||||
1. When prompted, specify if you want to make an off-card backup of your encryption key.
|
||||
|
||||
* Note: This is a shim backup of the private key, not a full backup, and cannot be used to restore the key.
|
||||
|
||||
|
||||
1. Specify how long the key should be valid for (specify the number in days, weeks, months, or years).
|
||||
|
||||
|
||||
1. Confirm the expiration day.
|
||||
|
||||
|
||||
1. When prompted, enter your name.
|
||||
|
||||
1. Enter your email address.
|
||||
|
||||
|
||||
1. If needed, enter a comment.
|
||||
|
||||
|
||||
1. Review the name and email, and accept or make changes.
|
||||
|
||||
|
||||
1. Enter the default admin PIN again. The green light on the smart card will flash while the keys are being written.
|
||||
|
||||
|
||||
1. Enter a Passphrase as the key will not allow you to pass without having a passphrase. If you do not enter a Passphrase generation will fail.
|
||||
|
||||
// ANCHOR_END: steps-on-key-gen
|
||||
|
|
|
@ -1,67 +0,0 @@
|
|||
# Fixed Location Reusable Laptop Ceremony
|
||||
|
||||
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](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:
|
||||
|
||||
* Heads firmware protection (TODO link to document which explains how to set up Purism)
|
||||
|
||||
* Glitter to prevent physical access to hardware (TODO link to how to properly use glitter for tamper proofing)
|
||||
|
||||
* On-premises audio and visual monitoring (TODO select appropriate equipment)
|
||||
|
||||
* Physical vault (TODO find adequate vaults)
|
||||
|
||||
## Procedure
|
||||
|
||||
### Unsealing
|
||||
|
||||
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
|
||||
|
||||
* Both photos of vacuum sealed bag with filler and glitter on the bottom screws of laptop are required
|
||||
|
||||
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
|
|
@ -3,11 +3,11 @@
|
|||
## Requirements
|
||||
|
||||
* [AirgapOS SD card](../level-2/fixed-location/provisioner/provision-airgapos.md)
|
||||
* Provided by [AirGapped Bundle](../level-2/fixed-location/provisioner/air-gapped-bundle.md)
|
||||
* Provided by [Air-Gapped Bundle](../level-2/fixed-location/provisioner/air-gapped-bundle.md)
|
||||
* Alternative: Create your own from documentation in [AirgapOS Repository](https://git.distrust.co/public/airgap)
|
||||
|
||||
* AirgapOS Laptop
|
||||
* Provided by [AirGapped Bundle](../level-2/fixed-location/provisioner/air-gapped-bundle.md)
|
||||
* Provided by [Air-Gapped Bundle](../level-2/fixed-location/provisioner/air-gapped-bundle.md)
|
||||
* Alternative: Computer that can load AirgapOS ([compatibility reference](https://git.distrust.co/public/airgap#tested-models))
|
||||
|
||||
{{ #include ../../component-documents/linux-workstation.md:content }}
|
||||
|
@ -40,7 +40,7 @@
|
|||
1. Import newly generated public key into local keychain
|
||||
|
||||
```
|
||||
$ gpg --import /media/transport/*.pub.asc
|
||||
$ gpg --import /media/TRANSFER/*.pub.asc
|
||||
```
|
||||
|
||||
{{ #include ../../component-documents/git-commit-signing.md:steps }}
|
||||
|
@ -57,7 +57,7 @@
|
|||
$ git checkout main
|
||||
$ git pull origin main
|
||||
```
|
||||
b. Commit and push modifications
|
||||
c. Commit and push modifications
|
||||
```
|
||||
$ cp /media/TRANSFER/*.asc keys/all
|
||||
$ git add .
|
||||
|
@ -67,11 +67,11 @@
|
|||
|
||||
1. Communicate your new key fingerprint to all other participants:
|
||||
|
||||
* Preferred: In person
|
||||
|
||||
* Preferred: In person
|
||||
|
||||
* Fallback: via two logically distinct online communications methods (e.g. encrypted chat, and video call)
|
||||
|
||||
1. Get confirmation they have imported your key to their keychains
|
||||
|
||||
* e.g. `gpg --import <your_key_id>.asc`
|
||||
* e.g. `gpg --import <your_key_id>.asc`
|
||||
* Confirm this is done for keyrings on workstations used to interact with the Vaults repository
|
||||
|
|
|
@ -9,11 +9,11 @@
|
|||
* The operators should verify the commit signatures of the photographs they are printing against a list of permitted PGP keys found in the "ceremonies" repo
|
||||
|
||||
* [AirgapOS SD card](/generated-documents/level-2/fixed-location/provisioner/provision-airgapos.md)
|
||||
* Provided by [AirGapped Bundle](/generated-documents/level-2/fixed-location/provisioner/air-gapped-bundle.md)
|
||||
* Provided by [Air-Gapped Bundle](/generated-documents/level-2/fixed-location/provisioner/air-gapped-bundle.md)
|
||||
* Alternative: Create your own from documentation in [AirgapOS Repository](https://git.distrust.co/public/airgap)
|
||||
|
||||
* AirgapOS Laptop
|
||||
* Provided by [AirGapped Bundle](/generated-documents/level-2/fixed-location/provisioner/air-gapped-bundle.md)
|
||||
* Provided by [Air-Gapped Bundle](/generated-documents/level-2/fixed-location/provisioner/air-gapped-bundle.md)
|
||||
* Alternative: Computer that can load AirgapOS ([compatibility reference](https://git.distrust.co/public/airgap#tested-models))
|
||||
|
||||
* Minimum of 1 [Operator](/system-roles.md#operator) and 1 [Witness](/system-roles.md#witness)
|
||||
|
@ -23,4 +23,4 @@
|
|||
* Tamper-proofing equipment
|
||||
|
||||
// ANCHOR_END: requirements
|
||||
/* ANCHOR_END: all */
|
||||
/* ANCHOR_END: all */
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
# Key Types
|
||||
# PGP Key Types
|
||||
|
||||
## Personal PGP Keypair
|
||||
|
||||
|
@ -8,7 +8,7 @@ When bootstrapping a system, the initial PGP keys can be generated using [this g
|
|||
|
||||
### Requirements
|
||||
|
||||
* MUST not be transferred
|
||||
* MUST not be transferred
|
||||
|
||||
* MUST be generated offline
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
There are several roles which are required to properly operate the QVS system. While it is possible to have an individual perform multiple roles, typically they should only perform one role at a time. It is also recommended to have at least 2 individuals, or ideally the full quorum be used to make decisions pertaining to QVS. At least 2 individuals are required for [level 2](threat-model.md#adversary-1).
|
||||
|
||||
To better understand why the different roles are required, refer to the [selecting a quorum](selecting-quorum.md) and [threat model](threat-model.md) sections which enumerate a number of assumptions around pertinent threats to the system as well as the use of a quorum.
|
||||
To better understand why the different roles are required, refer to the [selecting a quorum](selecting-quorum.md) and [threat model](threat-model.md) sections which enumerate a number of assumptions around pertinent threats to the system as well as the use of a quorum.
|
||||
|
||||
## General Requirements
|
||||
|
||||
|
@ -14,14 +14,14 @@ Individuals who are selected for the roles:
|
|||
|
||||
* MUST be reinvestigated once a year to ensure they meet necessary standards to access restricted information
|
||||
|
||||
## Provisioner
|
||||
|
||||
Responsible for more technical aspects of preparing equipment for ceremonies such as creating air-gapped machines by removing radio cards, and tamper proofing them along with SD cards which are loaded with AirgapOS etc.
|
||||
|
||||
## Procurer
|
||||
|
||||
Responsible for tasks such as procuring a location, tamper proofing equipment, hardware, and maintaining inventory.
|
||||
|
||||
## Provisioner
|
||||
|
||||
Responsible for more technical aspects of preparing equipment for ceremonies such as creating air-gapped machines by removing radio cards, and tamper proofing them along with SD cards which are loaded with AirgapOS etc.
|
||||
|
||||
## Proposer
|
||||
|
||||
This is an individual who is a business owner or stakeholder, or a financial controller. Their role is to make fiduciary decisions which protect the financial interest of the organization and its clients. Their role is specifically to propose the movement of funds, specifying the amount, origin and destination.
|
||||
|
@ -40,4 +40,4 @@ As a QVS grows, it may be prudent to create more highly specialized roles whose
|
|||
|
||||
## Witness
|
||||
|
||||
QVS relies of having individuals present to witness that processes which uphold the security of the system are properly followed. [Operators](#operator) make ideal witnesses as their familiarity with the QVS system allows them to detect any deviation from the processes which uphold the security of the system. While it is not required that a Witness be a trained Operator, it is highly preferred.
|
||||
QVS relies of having individuals present to witness that processes which uphold the security of the system are properly followed. [Operators](#operator) make ideal witnesses as their familiarity with the QVS system allows them to detect any deviation from the security-critical processes. While it is not required that a Witness be a trained Operator, it is highly preferred.
|
||||
|
|
|
@ -26,7 +26,7 @@ of their security properties
|
|||
* Creating custom purpose specific tooling which eliminates dependencies in
|
||||
order to reduce supply chain attacks, and adds desirable security properties
|
||||
|
||||
* Building as much of the software and firmware deterministically as possible - aiming for 100%
|
||||
* Building as much of the software and firmware deterministically as possible - aiming for 100%
|
||||
|
||||
* The [StageX](https://codeberg.org/stagex/stagex) project is the effort towards this end
|
||||
|
||||
|
@ -140,7 +140,7 @@ This level focuses on defending against insider threats.
|
|||
|
||||
* Exploit any vulnerability within 24h of public knowledge
|
||||
|
||||
### Requirements
|
||||
#### Requirements
|
||||
|
||||
* All production access:
|
||||
|
||||
|
@ -156,7 +156,7 @@ This level focuses on defending against insider threats.
|
|||
|
||||
* MUST be anchored to keys in dedicated HSMs held by each administrator
|
||||
|
||||
* Consider OpenPGP or PKSC#11 smart cards that support touch-approval for ssh
|
||||
* Consider OpenPGP or PKCS#11 smart cards that support touch-approval for ssh
|
||||
|
||||
* Any code in the transaction signing trust supply chain:
|
||||
|
||||
|
@ -198,11 +198,11 @@ This level focuses on defending against insider threats.
|
|||
|
||||
* App phone stores already anchor to developer held signing keys
|
||||
|
||||
### Reference Design
|
||||
#### 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
|
||||
* Consider OpenPGP 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
|
||||
|
||||
|
|
Loading…
Reference in New Issue