Compare commits
1 Commits
main
...
feat/tampe
| Author | SHA1 | Date |
|---|---|---|
 Spencer Judd
|
5bae471906
|
|
|
@ -1,6 +1,6 @@
|
|||
# Quorum Key Management (QVS)
|
||||
# Quorum Key Management (QKM)
|
||||
|
||||
Quorum Key Management (QVS) is an open source system of playbooks and tooling which
|
||||
Quorum Key Management (QKM) is an open source system of playbooks and tooling which
|
||||
facilitates the creation and maintenance of highly resilient Quorum-based Key
|
||||
Management Systems based on a strict threat model which can be used for a
|
||||
variety of different cryptographic algorithms.
|
||||
|
|
|
|||
|
|
@ -1,8 +0,0 @@
|
|||
#!/bin/bash
|
||||
|
||||
COMMIT_HASH=$(git rev-parse --short HEAD)
|
||||
|
||||
echo "Commit Hash: $COMMIT_HASH" > src/commit_hash.md
|
||||
|
||||
# Build the mdBook
|
||||
mdbook build
|
||||
|
|
@ -4,42 +4,71 @@
|
|||
* [Selecting a Quorum](selecting-quorum.md)
|
||||
* [System Roles](system-roles.md)
|
||||
* [Software](software.md)
|
||||
* [Location](locations.md)
|
||||
* [Hardware](hardware.md)
|
||||
* [Glossary](glossary.md)
|
||||
|
||||
* [Preparations]()
|
||||
* [Verifying Signatures](verifying-signatures.md)
|
||||
* [Tamper Evidence Methods](tamper-evidence-methods.md)
|
||||
* [Online Machine](online-machine-provisioning.md)
|
||||
|
||||
* [Fixed Location Reusable Laptop]()
|
||||
* [Location](locations.md)
|
||||
* [Procure Hardware](fixed-location-reusable-hardware-procurement.md)
|
||||
* [PureBoot]()
|
||||
* [Flash PureBoot to Librem](flash-pureboot-firmware.md)
|
||||
* [Initialize PureBoot Smart Card](initialize-pureboot-smart-card.md)
|
||||
* [Change Smart Card PINs](setting-smart-card-pins.md)
|
||||
* [PureBoot Restricted Boot](enable-pure-boot-restricted-boot.md)
|
||||
* [PureBoot Boot Sequence](secure-boot-sequence.md)
|
||||
|
||||
* [AirgapOS Setup]()
|
||||
* [AirgapOS Setup](repeat-use-airgapos.md)
|
||||
* [`autorun.sh` Setup](autorun-sh-setup.md)
|
||||
|
||||
* [One Time Use / Portable Use]()
|
||||
* [Location](one-time-use-locations.md)
|
||||
* [Procure Hardware](hardware-procurement-and-chain-of-custody.md)
|
||||
* [AirgapOS Setup](one-time-use-airgapos.md)
|
||||
* [Repository Setup](one-time-repository-setup.md)
|
||||
* [Selecting Locations](one-time-use-locations.md)
|
||||
|
||||
* [Root Entropy Ceremonies]()
|
||||
* [Ceremony Log Template](ceremony-log-template.md)
|
||||
* [Root Entropy Ceremonies](root-entropy-ceremonies.md)
|
||||
* [Local Key Provisioning](local-key-provisioning.md)
|
||||
* [Hybrid Key Provisioning](hybrid-key-provisioning.md)
|
||||
* [Remote Key Provisioning](remote-key-provisioning.md)
|
||||
|
||||
* [Additional Key Ceremonies]()
|
||||
* [Operator Key Provisioning](operator-key-provisioning.md)
|
||||
* [Location Key Provisioning](location-key-provisioning.md)
|
||||
|
||||
* [Post Ceremony]()
|
||||
* [Online Artifact Storage](public-ceremony-artifact-storage.md)
|
||||
* [Physical Artifact Storage](physical-artifact-storage.md)
|
||||
|
||||
* [Ceremonies]()
|
||||
* [One Time Use Laptop Ceremony](one-time-use-laptop-coin-ceremony.md)
|
||||
* [Portable Reusable Laptop Ceremony](portable-reusable-laptop-ceremony.md)
|
||||
* [Fixed Location Reusable Laptop Ceremony](fixed-location-reusable-laptop-ceremony.md)
|
||||
|
||||
* [Lifecycle Management]()
|
||||
* [Destroying Hardware](hardware-destruction.md)
|
||||
* [Storage Device Management](storage-device-management.md)
|
||||
|
||||
* [Generated Documents]()
|
||||
* [Level 1]()
|
||||
* [Level 2]()
|
||||
* [Fixed-Location]()
|
||||
* [Provisioner](generated-documents/level-2/fixed-location/provisioner/index.md)
|
||||
* [PGP Key Bootstrapping](generated-documents/level-2/fixed-location/provisioner/pgp-key-bootstrapping.md)
|
||||
* [Provision Computer](generated-documents/level-2/fixed-location/provisioner/provision-computer.md)
|
||||
* [Provision Ceremony Repository](generated-documents/level-2/fixed-location/provisioner/provision-ceremonies-repository.md)
|
||||
* [Provision SD Card](generated-documents/level-2/fixed-location/provisioner/provision-sd-card.md)
|
||||
* [Provision Tamper Proofing Equipment](generated-documents/level-2/fixed-location/provisioner/provision-tamper-proofing-equipment.md)
|
||||
* [Provision AirgapOS](generated-documents/level-2/fixed-location/provisioner/provision-airgapos.md)
|
||||
* [Provision Facility](generated-documents/level-2/fixed-location/provisioner/provision-facility.md)
|
||||
* [Provision Airgapped Bundle](generated-documents/level-2/fixed-location/provisioner/provision-air-gapped-bundle.md)
|
||||
* [Copy Shardfile SD Card](generated-documents/level-2/fixed-location/provisioner/copy-shardfile-sd-card.md)
|
||||
* [Provisioner](system-roles.md)
|
||||
* [Hardware](generated-documents/level-2/fixed-location/provisioner/procure-hardware.md)
|
||||
* [Location]()
|
||||
* [Proposer](system-roles.md)
|
||||
* [Propose Transaction](generated-documents/level-2/fixed-location/proposer/create-transaction-payload.md)
|
||||
* [Approver](system-roles.md)
|
||||
* [Transaction Approval](generated-documents/level-2/fixed-location/approver/approve-transaction.md)
|
||||
* [Operator](system-roles.md)
|
||||
* [PGP Key Provisioning](generated-documents/level-2/fixed-location/operator/pgp-key-provisioning.md)
|
||||
* [Root Entropy Generation](generated-documents/level-2/fixed-location/operator/root-entropy-generation.md)
|
||||
* [PYTH-SLN - Sign Transaction](generated-documents/level-2/fixed-location/operator/coins/pyth-spl/sign-transaction.md)
|
||||
* [Document Components]()
|
||||
* [Ceremony Repository](./component-documents/ceremony-repository.md)
|
||||
* [Keychain Repository](./component-documents/keychain-repository.md)
|
||||
* [Git Commit Signing](./component-documents/git-commit-signing.md)
|
||||
* [OpenPGP Setup](./component-documents/openpgp-setup.md)
|
||||
* [Verifying Signatures](./component-documents/verifying-signatures.md)
|
||||
* [Tamper Evidence Methods](./component-documents/tamper-evidence-methods.md)
|
||||
* [Change Smart Card PINs](./component-documents/setting-smart-card-pins.md)
|
||||
* [Online Machine Provisioning](./component-documents/online-machine-provisioning.md)
|
||||
* [Hardware Destruction](./component-documents/hardware-destruction.md)
|
||||
* [Storage Device Management](./component-documents/storage-device-management.md)
|
||||
* [Procurement & Chain of Custody](./component-documents/hardware-procurement-and-chain-of-custody.md)
|
||||
* [Online Artifact Storage](./component-documents/public-ceremony-artifact-storage.md)
|
||||
* [Physical Artifact Storage](./component-documents/physical-artifact-storage.md)
|
||||
* [`autorun.sh` Setup](./component-documents/autorun-sh-setup.md)
|
||||
* [Hardware Models](./component-documents/hardware-models.md)
|
||||
* [Level 3]()
|
||||
* [Level 4]()
|
||||
|
|
@ -1,28 +1,29 @@
|
|||
# `autorun.sh` Setup
|
||||
|
||||
This document describes how `autorun.sh`, a file that AirgapOS automatically boots and runs should be set up.
|
||||
This document describes how `autorun.sh`, a file that AirgapOS automatically
|
||||
boots and runs should be set up.
|
||||
|
||||
This setup can be done on any machine.
|
||||
|
||||
1. Create a file called `autorun.sh`
|
||||
1. Create a file called `autorun.sh` that has the following contents:
|
||||
|
||||
* In your Terminal use this command: `vi autorun.sh`
|
||||
You may accomplish this by doing the following:
|
||||
|
||||
* In your Terminal use this command:
|
||||
`vi autorun.sh`
|
||||
* Once you are in the editor press "i" to enter "insert mode"
|
||||
|
||||
* Type in the contents, replacing <N> and <M> with your chosen threshold numbers according to your [Quorum](selecting-quorum.md):
|
||||
|
||||
* Type in the contents, replacing <N> and <M> with your chosen threshold
|
||||
numbers according to your [Quorum](selecting-quorum.md):
|
||||
```sh
|
||||
#!/bin/sh
|
||||
keyfork wizard generate-shard-secret --threshold <M> --max <N> --output shards.pgp
|
||||
```
|
||||
|
||||
* Press "esc"
|
||||
* Press ":"
|
||||
* Press "x"
|
||||
* Press Enter
|
||||
|
||||
1. Hash the file
|
||||
2. Hash the file
|
||||
The file should be hashed by using the following command:
|
||||
|
||||
```sh
|
||||
|
|
@ -30,12 +31,14 @@ This setup can be done on any machine.
|
|||
```
|
||||
Make note of the hash on a piece of paper
|
||||
|
||||
1. Copy the file to the Storage Device which contains AirgapOS.
|
||||
3. Copy the file to the Storage Device which contains AirgapOS.
|
||||
|
||||
a. If you don't have a Storage Device set up with AirgapOS use [this guide](repeat-use-airgapos.md) to do so.
|
||||
a. If you don't have a Storage Device set up with AirgapOS use [this guide](repeat-use-airgapos.md)
|
||||
to do so.
|
||||
|
||||
b. Mount the AirgapOS Storage Device using [this guide](storage-device-management.md#mounting-a-storage-device)
|
||||
|
||||
c. Copy the `autorun.sh` file to the Storage Device
|
||||
|
||||
1. Make note of this hash on a piece of paper or print it as you will need it to verify the file during Ceremonies.
|
||||
4. Make note of this hash on a piece of paper or print it as you will need it to
|
||||
verify the file during Ceremonies.
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Ceremony Repository
|
||||
|
||||
// ANCHOR: content
|
||||
This repository holds data pertaining to ceremonies. The primary data consists of:
|
||||
|
||||
* Transaction proposals
|
||||
|
||||
* Transaction approvals
|
||||
|
||||
* Tamper proofing evidence
|
||||
|
||||
* Policies (such as spending rules)
|
||||
|
||||
* Participants
|
||||
|
||||
## Directives
|
||||
|
||||
* MUST be a private repository
|
||||
|
||||
* MUST be write protected, requiring approval from at least 1 individual other than one who opened the PR for merging
|
||||
|
||||
* MUST require signed commits
|
||||
|
||||
## Repository Structure
|
||||
|
||||
```
|
||||
ceremonies/
|
||||
<date>/
|
||||
log.txt
|
||||
- [ ] TODO: write a layout for the log
|
||||
tamper_evidence/
|
||||
<photo_name>.jpeg
|
||||
<photo_name>.jpeg
|
||||
transactions/
|
||||
<tx_name>.tx.json
|
||||
policies/
|
||||
spending-policy.json
|
||||
keychain/
|
||||
<key_id>/
|
||||
sig_1.asc
|
||||
sig_2.asc
|
||||
```
|
||||
|
||||
## Procedure: Setting up Repository
|
||||
|
||||
{{ #include ./git-repository-initialization.md:procedure}}
|
||||
// ANCHOR_END: content
|
||||
/* ANCHOR_END: all */
|
||||
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Git Commit Signing
|
||||
// ANCHOR: steps
|
||||
1. Retrieve the value of your PGP key ID by using:
|
||||
|
||||
`gpg --list-keys`
|
||||
|
||||
1. Set up local `.gitconfig` file with desired PGP key:
|
||||
```
|
||||
[user]
|
||||
name = <name>
|
||||
email = <email>
|
||||
signingKey = <pgp_key_id>
|
||||
|
||||
[commit]
|
||||
gpgsign = true
|
||||
merge = true
|
||||
[core]
|
||||
editor = "code --wait"
|
||||
```
|
||||
|
||||
1. Set up environment variables for using smart cards
|
||||
|
||||
Open the `~/.bashrc` file and add the following content at the end:
|
||||
|
||||
```bash
|
||||
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
|
||||
export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
|
||||
fi
|
||||
|
||||
GPG_TTY=$(tty)
|
||||
export GPG_TTY
|
||||
```
|
||||
// ANCHOR_END: steps
|
||||
/* ANCHOR: all */
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Git Repository Initialization
|
||||
|
||||
This document explains how a git repository should be set up in order to guarantee authenticity and non-repudiation of data.
|
||||
|
||||
Git is used because it permits cryptographic singing of commits using PGP, as well as historical changes to a set of data.
|
||||
|
||||
## Procedure: Setting up Repository
|
||||
// ANCHOR: procedure
|
||||
1. Create a git repository using a git system such as Forjego, GitLab, GitHub etc.
|
||||
|
||||
1. Set appropriate permissions to limit who can write to the repository.
|
||||
|
||||
* `main` branch should be write protected so that merges to that branch can only be done if at least 2 approvals are present
|
||||
|
||||
* The organization may choose to require more approvals based on risk tolerance and operational capacity
|
||||
|
||||
* The merges should be done via CLI signed commits
|
||||
|
||||
* 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.
|
||||
// ANCHOR_END: procedure
|
||||
/* ANCHOR_END: all */
|
||||
|
||||
|
|
@ -1,58 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Committing Using Git Graphical User Interface
|
||||
|
||||
The GitKraken tool can be used to produce commits with data.
|
||||
|
||||
- [ ] TODO deterministic build of GitKraken / custom tool for this
|
||||
- [ ] TODO maybe it's better to train the team to use `git` in the terminal for now until we have a better tool because GitKraken introduces a lot of surface area for attacks
|
||||
|
||||
# GitKraken Guide: Create a File, Edit in VS Code, and Commit
|
||||
// ANCHOR: steps
|
||||
1. Clone the Repository
|
||||
* Launch the GitKraken application.
|
||||
* Clone the ceremony repository:
|
||||
* Click on the **"Clone"** button on the left sidebar.
|
||||
* Enter the repository URL you want to clone.
|
||||
* Choose a local directory where you want to save the repository.
|
||||
* Click **"Clone the repo"**.
|
||||
|
||||
1. Create a new file
|
||||
* **Navigate to the repository**: Make sure you are in the cloned repository in GitKraken.
|
||||
* **Create a new file**:
|
||||
* Right-click on the folder where you want to create the file in the left sidebar.
|
||||
* Select **"New File"**.
|
||||
* Name your file (e.g., `<file_name>`).
|
||||
|
||||
1. Open the File in Visual Studio Code
|
||||
* **Open Visual Studio Code**:
|
||||
* Right-click on the newly created file
|
||||
* Select **"Open in External Editor"** (this should open the file in Visual Studio Code)
|
||||
|
||||
1. Add content to the file
|
||||
* In Visual Studio Code, type a simple JSON blob. For example:
|
||||
```json
|
||||
{
|
||||
"name": "Sample",
|
||||
"version": "1.0.0",
|
||||
"description": "This is a sample JSON blob."
|
||||
}
|
||||
```
|
||||
* Save the file: Press `Ctrl + S` (or `Cmd + S` on Mac) to save the changes.
|
||||
|
||||
1. Stage the changes
|
||||
* **Return to GitKraken**: Go back to GitKraken.
|
||||
* **Stage the File**:
|
||||
* In the left sidebar, you will see the file you just created under the **"Unstaged Files"** section.
|
||||
* Click the checkbox next to `<file_name>` to stage the file.
|
||||
|
||||
1. Commit the Changes
|
||||
* **Commit the Changes**:
|
||||
* In the commit message box at the bottom, type a commit message (e.g., "Add <file_name> with sample JSON blob").
|
||||
* Click the **"Commit changes"** button.
|
||||
|
||||
1. Push the Changes (if needed)
|
||||
* Push to remote repository:
|
||||
* If you want to push your changes to the remote repository, click the **"Push"** button in the top toolbar.
|
||||
// ANCHOR_END: steps
|
||||
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,80 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Hardware Models
|
||||
|
||||
## Computers
|
||||
|
||||
* Laptops with chargers over ports which don't allow data transfer is preferred (non USB etc.)
|
||||
|
||||
// ANCHOR: computer-models
|
||||
|
||||
* HP 13" Intel Celeron - 4GB Memory - 64GB eMMC, HP 14-dq0052dx, SKU: 6499749, UPC: 196548430192, DCS: 6.768.5321, ~USD $179.99
|
||||
* [Illustrated Parts Catalog](https://h10032.www1.hp.com/ctg/Manual/c04501162.pdf#%5B%7B%22num%22%3A3160%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2Cnull%2C732%2Cnull%5D)
|
||||
|
||||
* Lenovo 14" Flex 5i FHD Touchscreen 2-in-1 Laptop - Intel Core i3-1215U - 8GB Memory - Intel UHD Graphics, SKU: 6571565, ~USD $379.99
|
||||
|
||||
* Purism Librem 14
|
||||
// ANCHOR_END: computer-models
|
||||
|
||||
## SD Cards
|
||||
// ANCHOR: sd-models
|
||||
|
||||
* [Kingston Industrial 8GB SD Memory Card](https://www.kingston.com/en/memory-cards/industrial-grade-sd-uhs-i-u3?capacity=8gb)
|
||||
|
||||
* [Kingston Indsutrial 8GB microSD Memory Card](https://shop.kingston.com/products/industrial-microsd-card-memory-card?variant=40558543405248)
|
||||
|
||||
* microSD to SD adapter
|
||||
|
||||
* [64GB Kingston Canvas Select Plus Class 10 MicroSDXC Memory Card with SD Adapter (SDCS2/64GB)](https://bulkmemorycards.com/shop/microsd-cards/microsd-64gb/microsd-64gb-class-10/microsd-64gb-class-10-w-sd-adapter/64gb-kingston-canvas-select-class-10-microsdxc-memory-card-with-sd-adapter-sdcs-64gb/?_gl=1*1r3cz3m*_up*MQ..*_gs*MQ..&gclid=Cj0KCQiAvvO7BhC-ARIsAGFyToVLF285A59zXpHQEDA0sc7NML5JQohdIOPnS1o-6IfjqClWWZdMruUaAupkEALw_wcB)
|
||||
|
||||
* SD Card USB Adapters
|
||||
|
||||
* SD card reader: https://www.kingston.com/en/memory-card-readers/mobilelite-plus-sd-reader
|
||||
|
||||
* microSD card reader: https://www.kingston.com/en/memory-card-readers/mobilelite-plus-microsd-reader
|
||||
|
||||
* Workflow station hub (may prove helpful with workflows): https://www.kingston.com/en/memory-card-readers/workflow-station-hub
|
||||
|
||||
// ANCHOR_END: sd-models
|
||||
|
||||
## Smart Cards
|
||||
|
||||
Smart Cards are primarily used for storing OpenPGP cryptographic keys which are
|
||||
used as a building block for security controls. These smart cards hold OpenPGP
|
||||
keys which are derived in secure environments.
|
||||
|
||||
There are three primary requirements for smart cards:
|
||||
|
||||
* FIPS 140-2
|
||||
|
||||
* Support for Ed25519 OpenPGP
|
||||
|
||||
* Touch for enacting operations
|
||||
|
||||
### Notes
|
||||
|
||||
* Librem smartcards are not recommended because they don't have touch capabilities
|
||||
|
||||
* NitroKey and SoloKey are favored due to their fully open nature and therefore verifiability
|
||||
|
||||
* YubiKey has the advantage of being the most battle tested but is not verifiable and has had issues in the past (Infineon bug)
|
||||
|
||||
Some options include:
|
||||
// ANCHOR: smart-cards
|
||||
|
||||
* NitroKey 3
|
||||
|
||||
* Solo Key
|
||||
|
||||
* YubiKey 5
|
||||
|
||||
* Librem Key
|
||||
|
||||
// ANCHOR_END: smart-cards
|
||||
|
||||
## Tamper Proofing
|
||||
|
||||
// ANCHOR: sealable-plastic-bags
|
||||
[Alert Security bag](https://shop.alertsecurityproducts.com/clear-alert-bank-deposit-bag-15-x-20-250cs?affiliate=ppc12&gad_source=1&gclid=CjwKCAiAgoq7BhBxEiwAVcW0LJoCVUqYI1s4RGoctHxMwtmNlwenDhgP_0x4gjB9W2e4f_7tzdJ_rxoCOwMQAvD_BwE)
|
||||
// ANCHOR_END: sealable-plastic-bags
|
||||
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Procurement & Chain of Custody
|
||||
|
||||
## Provisioning Chain of Custody
|
||||
|
||||
Materials and devices which are used in the context of a high assurance system need to be monitored carefully from the moment they are purchased to ensure there are no single points of failure. Going back to the assumption that participants in the system are subject to [MICE](./glossary.md#MICE) and as such may pose a threat to the system, special care has to be taken that multiple individuals are involved in the whole lifecycle of provisioning a piece of equipment.
|
||||
|
||||
All steps of the provisioning process need to be completed under the supervision of at least 2 individuals, but benefit from having even more individuals present to increase the number of witnesses and allow individuals to take washroom breaks, eat etc.
|
||||
|
||||
The following steps must all be completed under the continued supervision and with the involvement of all parties present. It is instrumental that there is not a single moment where the device is left unsupervised, or under the supervision of only 1 individual.
|
||||
|
||||
## Provisioning Equipment
|
||||
// ANCHOR: steps
|
||||
|
||||
1. Selecting a Purchase Location
|
||||
|
||||
* Select at least 4 stores which carry the type of equipment being purchased, then randomly select one using the roll of a die, or other random method. This is done in order to reduce the likelihood that a threat actor is able to plant a compromised computer in a store ahead of time.
|
||||
|
||||
* Each participant should choose 2 of the stores.
|
||||
|
||||
2. Within the store, identify available adequate device
|
||||
|
||||
3. Purchase the device and place it in a see-through plastic bag which will be used to transport it to a "processing location", which is ideally just a access controlled space. The bag MUST be a sealable see-through tamper evident bag. It may be necessary to remove the device from it's original packaging to fit it into the sealable bag.
|
||||
|
||||
4. If the equipment does not have to be tamper proofed, simply deliver it to its storage location, and update the inventory repository with the serial number of the device.
|
||||
|
||||
5. If the equipment does require tamper proofing, apply the appropriate level of tamper proofing for the security level you are performing the procurement for.
|
||||
// ANCHOR_END:steps
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,65 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Keychain Repository
|
||||
// ANCHOR: content
|
||||
This repository contains the trusted keys for the organization.
|
||||
|
||||
## Directives
|
||||
|
||||
* MUST be a private repository
|
||||
|
||||
* MUST require signed commits
|
||||
|
||||
## Repository Structure
|
||||
```
|
||||
trusted-keys/
|
||||
proposers/
|
||||
<key_id>/
|
||||
pub.asc
|
||||
sig_1.asc
|
||||
sig_2.asc
|
||||
approvers/
|
||||
operators/
|
||||
```
|
||||
|
||||
## Procedure: Setting up Repository
|
||||
|
||||
{{ #include ./git-repository-initialization.md:procedure }}
|
||||
|
||||
## Procedure: Adding OpenPGP Keys
|
||||
|
||||
1. Designate the role of the key - it should be placed into the corresponding role directory
|
||||
|
||||
1. Open a PR submitting the key to the repository
|
||||
|
||||
* MUST be via commit signed by the PGP key being submitted to the repository
|
||||
|
||||
1. Two other authorized individuals (TODO define how they are authorized) must provide detached PGP signatures of the key being submitted
|
||||
|
||||
1. The PR should be merged using a signed commit via the git CLI
|
||||
|
||||
### Procedure: Ceremony "Keychain SD Card"
|
||||
|
||||
This procedure requires 2 individuals in order to witness the process and verify that the data being burned to the card is correct.
|
||||
|
||||
The Keychain SD Card once provisioned will be used in creating the [tamper proofed airgap bundle](#air-gapped-bundle)
|
||||
|
||||
1. Get a freshly formatted SD card
|
||||
|
||||
1. Plug it into a computer
|
||||
|
||||
1. Navigate the the official Keychain repository of your organization
|
||||
|
||||
1. Select provisioner and approver keys from the Keychain repository
|
||||
|
||||
1. Download the desired keys along with detached signatures
|
||||
|
||||
1. Copy the `.asc` and signature files to the SD card
|
||||
|
||||
1. Use the `sdtool` to lock the card
|
||||
|
||||
{{ #include ../sdtool-instructions.md:steps }}
|
||||
|
||||
1. Label the card "Keychain <date>"
|
||||
|
||||
// ANCHOR_END: content
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Set up AirgapOS
|
||||
|
||||
Because without a Librem 14 there is no easy way to have a secure boot sequence,
|
||||
instead the AirgapOS `.iso` image is flashed to an SD card, locked using
|
||||
`sdtool` and then verified using any machine.
|
||||
|
||||
## Setup Steps
|
||||
// ANCHOR: steps
|
||||
1. Build the software according to the [readme](https://git.distrust.co/public/airgap) in the repository. Use the `make reproduce` command.
|
||||
|
||||
1. Verify the software according to [this](../../../../component-documents/verifying-signatures.md) guide
|
||||
|
||||
1. Flash `airgap.iso` to an SD Card:
|
||||
|
||||
* `dd if=out/airgap.iso of=/dev/<your_device> bs=4M status=progress conv=fsync`
|
||||
|
||||
### Use the `sdtool` to lock the SD Card:
|
||||
|
||||
{{ #include ../sdtool-instructions.md:steps }}
|
||||
|
||||
1. Label the SD card "AirgapOS - <version>"
|
||||
|
||||
1. Verify that the hash of `airgap.iso` matches what's flashed on the SD card:
|
||||
|
||||
* `head -c $(stat -c '%s' out/airgap.iso) /dev/sdb | sha256sum`
|
||||
|
||||
* `sha256sum out/airgap.iso`
|
||||
|
||||
1. Commit the hash of airgap to a git repo, ensuring the commit is signed
|
||||
|
||||
// ANCHOR_END: steps
|
||||
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,135 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# OpenPGP Setup
|
||||
|
||||
Setting up a PGP key pair is necessary for a number of different aspects of 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` and `openpgp-card-tools`
|
||||
// ANCHOR: steps-keyfork
|
||||
1. Generate a mnemonic:
|
||||
|
||||
* `keyfork mnemonic generate --size 256 > mnemonic.txt`
|
||||
|
||||
1. Write the mnemonic on a small piece of paper as you will need to enter the words in the next step. After entering the words, set the piece of paper on fire (that's why it should be small enough - to make burning it easy)
|
||||
|
||||
1. In a new terminal window start `keyfork` daemon with the mnemonic:
|
||||
|
||||
* `export KEYFORKD_SOCKET_PATH=/tmp/keyforkd.socket`
|
||||
|
||||
* `keyfork recover mnemonic`
|
||||
|
||||
* Enter the mnemonic as prompted
|
||||
|
||||
* ctrl + z
|
||||
|
||||
* `bg`
|
||||
|
||||
1. Derive PGP keypair:
|
||||
|
||||
* `keyfork derive openpgp "full_name (alias) <email>" > priv.asc`
|
||||
|
||||
* e.g `keyfork derive openpgp "Ryan Heywood (RyanSquared) <ryan@distrust.co>" > priv.asc`
|
||||
|
||||
1. Provision at least two smart cards for redundancy:
|
||||
|
||||
* Get the `smart_card_id`:
|
||||
|
||||
* `oct list`
|
||||
|
||||
* Seed the smart card with the private OpenPGP key:
|
||||
|
||||
* `oct admin --card <smart_card_id> import priv.asc`
|
||||
|
||||
* Set the admin and user PINs for the card
|
||||
|
||||
* Use the following command to generate the two PINs (they should be different):
|
||||
|
||||
* `keyfork mnemonic generate --size 256 | awk '{ print $1, $2, $3, $4, $5 }' > smart-card-pin.txt`
|
||||
|
||||
* `oct pin --card <smart_card_id> set-user`
|
||||
|
||||
* Enter the <user_smart_card_pin>
|
||||
|
||||
* `oct pin --card <smart_card_id> set-admin`
|
||||
|
||||
* Enter the <admin_smart_card_pin>
|
||||
|
||||
1. Import PGP key into keyring
|
||||
|
||||
* `gpg --import priv.asc`
|
||||
|
||||
1. Use the `gpg --list-keys` command to list GPG keys in the local keychain. Identify your key and take note of the key ID.
|
||||
|
||||
* Example printout of the command, where `F4BF5C81EC78A5DD341C91EEDC4B7D1F52E0BA4D` is the key ID.
|
||||
```
|
||||
/home/user/.gnupg/pubring.kbx
|
||||
-----------------------------
|
||||
pub rsa4096 2022-03-26 [C] [expires: 2026-03-27]
|
||||
F4BF5C81EC78A5DD341C91EEDC4B7D1F52E0BA4D
|
||||
uid [ unknown] Anton Livaja <anton@livaja.me>
|
||||
uid [ unknown] Anton Livaja (Work) <anton@distrust.co>
|
||||
sub rsa4096 2022-03-26 [S] [expires: 2026-03-27]
|
||||
sub rsa4096 2022-03-26 [E] [expires: 2026-03-27]
|
||||
sub rsa4096 2022-03-26 [A] [expires: 2026-03-27]
|
||||
```
|
||||
|
||||
1. Bundle all data and encrypt it
|
||||
|
||||
* `mkdir backup_bundle/`
|
||||
|
||||
* `mv pub.asc priv.asc smart-card-pin.txt backup_bundle/`
|
||||
|
||||
* `tar -cvf backup_bundle.tar backup_bundle/`
|
||||
|
||||
* `gpg --armor -er <pgp_key_id> backup_bundle.tar`
|
||||
|
||||
1. Copy the encrypted bundle, `backup_bundle.tar.gpg` to an SD card. Repeat the process as many times as desired. Minimum of 3 SD Card backups is recommended.
|
||||
|
||||
* `lsblk`
|
||||
|
||||
* `sudo mount /dev/<your_device> media/`
|
||||
|
||||
* `cp backup_bundle.tar.gpg /media`
|
||||
|
||||
1. For posterity, delete all the generated assets before shutting down
|
||||
computer;
|
||||
|
||||
* `rm -rf *`
|
||||
// ANCHOR_END: steps-keyfork
|
||||
|
||||
## Generating Keys on Smartcard
|
||||
// ANCHOR: steps-on-key-gen
|
||||
|
||||
1. Insert the smartcard 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: 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.
|
||||
|
||||
* Note: This is a shim backup of the private key, not a full backup, and cannot be used to restore to a new smartcard.
|
||||
|
||||
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 smartcard 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
|
||||
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
# SD Formatting
|
||||
// ANCHOR: steps
|
||||
1. Insert a fresh SD card into the SD card slot or connect it via a USB card reader to your computer
|
||||
|
||||
* microSD or standard SD card can be used
|
||||
|
||||
2. Launch a terminal
|
||||
|
||||
3. List all block devices, including your SD card:
|
||||
|
||||
* `lsblk`
|
||||
|
||||
4. Look for your SD card in the output of the `lsblk` command. It will typically be listed as `/dev/sdX`, 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`)
|
||||
|
||||
5. Before formatting, you need to unmount the SD card. Replace `/dev/sdX1` with the actual partition name you identified in the previous step:
|
||||
|
||||
* `sudo umount /dev/sdX1`
|
||||
|
||||
6. Use the mkfs command to format the SD card. You can choose the file system type (e.g., vfat for FAT32, ext4, etc.). Replace /dev/sdX with the actual device name (without the partition number):
|
||||
|
||||
* `sudo mkfs.vfat /dev/sdX`
|
||||
|
||||
7. You can verify that the SD card has been formatted by running lsblk again or by checking the file system type:
|
||||
|
||||
* `lsblk -f`
|
||||
|
||||
8. Once formatting is complete, you can safely remove physically or eject the SD card:
|
||||
|
||||
* `sudo eject /dev/sdX`
|
||||
//ANCHOR_END:steps
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Purism Procurement Procedure (Anti-Interdiction)
|
||||
# Procure Hardware
|
||||
|
||||
1. Select a librem 14 laptop from https://puri.sm, and ensure:
|
||||
|
||||
|
|
@ -16,6 +16,8 @@
|
|||
|
||||
* Warranty: 1 Year
|
||||
|
||||
* Privacy Screen: Privacy Screen for Librem 14
|
||||
|
||||
* USB Flash Drive: No USB Flash Drive
|
||||
|
||||
2. Purism will reach out via email and establish secure communications using PGP, so ensure that the individual who is in charge of procurement has a PGP key that's been set up securely. Purism will:
|
||||
|
|
@ -24,16 +26,20 @@
|
|||
|
||||
* Seal the screws on the bottom of the laptop using glitter of chosen color
|
||||
|
||||
* TODO: Add detail around using glitter with larger pieces and layering several types, per this discussion: https://git.distrust.co/public/docs/pulls/10#issuecomment-996
|
||||
|
||||
* Take photographs of the inside of the laptop, then of the outside after it's sealed
|
||||
|
||||
* The photographs will be signed by Purism and encrypted to the PGP key used for communications to protect the integrity of the images
|
||||
|
||||
* TODO: Add information about verifying the authenticity of the Purism signing key, per this discussion: https://git.distrust.co/public/docs/pulls/10#issuecomment-961
|
||||
|
||||
* The firmware verification hardware token can be sent to a separate location from the laptop, and will be tamper sealed using tamper proofing tape
|
||||
|
||||
* TODO: find out if we can have vacuum sealing with filler as a tamper proofing method be provided by Purism
|
||||
|
||||
* The laptop will be sealed in a box using tamper proofing tape
|
||||
|
||||
3. Once the laptop is received, it should not be opened until at least 2 parties are present and principles of [chain of custody](./hardware-procurement-and-chain-of-custody.md) can be upheld. The images of tamper proofing provided by Purism should be used to ensure that the hardware had not been tampered, and the hardware token to verify firmware is in tact.
|
||||
3. Once the laptop is received, it should not be opened until at least 2 parties are present and principles of [chain of custody](hardware-procurement-and-chain-of-custody.md) can be upheld. The images of tamper proofing provided by Purism should be used to ensure that the hardware had not been tampered, and the hardware token to verify firmware is in tact.
|
||||
|
||||
4. Once the hardware is properly verified to not have been tampered in transit, a [tamper evidence method](../tamper-evidence-methods.md) should be applied to the laptop before it's stored.
|
||||
4. Once the hardware is properly verified to not have been tampered in transit, a [tamper evidence method](tamper-evidence-methods.md) should be applied to the laptop before it's stored.
|
||||
|
|
@ -24,7 +24,7 @@ The primary tamper proofing methods for the fixed location device are:
|
|||
|
||||
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
|
||||
* 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)
|
||||
|
||||
|
|
@ -34,6 +34,8 @@ The primary tamper proofing methods for the fixed location device are:
|
|||
|
||||
* Approximate time of entry
|
||||
|
||||
* TODO: Document how this access log is implemented.
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,21 +1,21 @@
|
|||
# Flash ISO Image to a Storage Device
|
||||
4. Flash ISO Image to a Storage Device
|
||||
|
||||
1. Select a new Storage Device which can be overwritten entirely
|
||||
a. Select a new Storage Device which can be overwritten entirely
|
||||
|
||||
1. Find the name of the Storage Device using [this guide](storage-device-management.md#finding-a-storage-device-name)
|
||||
b. Find the name of the Storage Device using [this guide](storage-device-management.md#finding-a-storage-device-name)
|
||||
|
||||
1. Use the `dd` utility in the Terminal to flash AirgapOS to it. You will need
|
||||
to replace `<your_storage_device>` with the name of your device.
|
||||
d. Use the `dd` utility in the Terminal to flash AirgapOS to it. You will need
|
||||
to replace `<your_storage_device>` with the name of your device.
|
||||
|
||||
```bash
|
||||
sudo dd bs=4M if=~/airgap/dist/airgap.iso of=/dev/<your_thumb_drive> status=progress
|
||||
```
|
||||
```bash
|
||||
sudo dd bs=4M if=~/airgap/dist/airgap.iso of=/dev/<your_thumb_drive> status=progress
|
||||
```
|
||||
|
||||
In the example, the name of the device is `sda` so the complete command would look like this:
|
||||
In the example, the name of the device is `sda` so the complete command would look like this:
|
||||
|
||||
```bash
|
||||
sudo dd bs=4M if=~/airgap/dist/airgap.iso of=/dev/sda status=progress
|
||||
```
|
||||
```bash
|
||||
sudo dd bs=4M if=~/airgap/dist/airgap.iso of=/dev/sda status=progress
|
||||
```
|
||||
|
||||
Once this step is complete, you have successfully set up a Storage Device
|
||||
with AirgapOS.
|
||||
Once this step is complete, you have successfully set up a Storage Device
|
||||
with AirgapOS.
|
||||
|
|
@ -2,36 +2,22 @@
|
|||
|
||||
The approver is responsible for verifying a transaction proposed by a [proposer](../../../../system-roles.md).
|
||||
|
||||
## Requirements
|
||||
## Responsibilities
|
||||
|
||||
* If necessary, provision a PGP key pair to a smart card using the guide in the [Appendix: Generating PGP Keypair & Provisioning Smart Card](#generating-pgp-keypair--provisioning-smart-card)
|
||||
* MUST verify the proposer data out of band (over a secure channel)
|
||||
|
||||
* Ensure that the computer is configured to sign commits with the desired key. Refer to the [Appendix: Git Commit Signing Configuration](#git-commit-signing-configuration)
|
||||
* Proposer data is primarily their PGP key
|
||||
|
||||
* Clone the [Ceremonies Repository](../provisioner/provision-ceremonies-repository.md) for your organization to the machine
|
||||
* MUST verify the PGP signature of the data according to a policy
|
||||
|
||||
## Procedure
|
||||
* TODO: specify how the policy works
|
||||
|
||||
1. Pull the latest changes from the `ceremonies` repository
|
||||
* MUST add their own well known PGP key signature to the data if the data is verified to be valid.
|
||||
|
||||
1. Verify the PGP key of the Proposer is valid
|
||||
* NOTE: all transaction values must be signed as part of a single message
|
||||
|
||||
1. Verify that the commit with the tx data is properly signed by the key that was verified in the previous step
|
||||
To sign the transaction payload and produce a detached signature use:
|
||||
|
||||
1. Verify that the transaction is according to the defined policy, for the time being ensuring it's signed by safe-listed PGP keys (TODO: update this with a proper policy post-MVP)
|
||||
`gpg --armor --output <approver.sig> --detach-sig <filename>`
|
||||
|
||||
1. To sign the transaction payload and produce a detached signature use:
|
||||
|
||||
* `gpg --armor --output <approver.sig> --detach-sig <filename>`
|
||||
|
||||
1. Commit the detached signature alongside the tx
|
||||
|
||||
## Appendix
|
||||
|
||||
### Git Commit Signing Configuration
|
||||
|
||||
{{ #include ../../../../component-documents/git-commit-signing.md:steps }}
|
||||
|
||||
### Generating PGP Keypair & Provisioning Smart Card
|
||||
|
||||
{{ #include ../../../../component-documents/openpgp-setup.md:steps-keyfork }}
|
||||
Transmit the `proposer.asc` and `approver.sig` to the operator.
|
||||
|
|
@ -1,71 +1,101 @@
|
|||
# NOT PRODUCTION READY
|
||||
|
||||
# Operator - Sign PYTH-SPL Transaction
|
||||
|
||||
## Requirements
|
||||
|
||||
* Ensure both primary operators have their [Operator Keys](../../pgp-key-provisioning.md)
|
||||
* TODO: Move this into the "provisioner" document, per this discussion: https://git.distrust.co/public/docs/pulls/10#issuecomment-1002
|
||||
|
||||
* Both operators should print photographic evidence from digital cameras which is stored in a PGP signed repository. The photographs should be of the top and underside of the vacuum sealed object.
|
||||
* 2 primary operators will be operating the offline machine and online machine
|
||||
|
||||
* The operators should verify the commit signatures of the photographs they are printing against a list of permitted PGP keys
|
||||
* Ensure both primary operators have their [Operator Keys](../../../../../../glossary.md#operator-key)
|
||||
|
||||
- [ ] TODO: where do we refer to permitted PGP keys
|
||||
* Photographic tamper proofing evidence
|
||||
|
||||
* Each operator should hash the `keychain` repository
|
||||
- [ ] TODO define keychain repository setup
|
||||
* Both operators should print photographic evidence from digital cameras which is stored in a PGP signed repository. The photographs should be of the top and underside of the vacuum sealed object.
|
||||
|
||||
* `sha256sum keychain/`
|
||||
* The operators should verify the commit signatures of the photographs they are printing against a list of permitted PGP keys
|
||||
|
||||
* Write it down on a piece of paper as it will be used during the ceremony
|
||||
* TODO: where do we refer to permitted PGP keys
|
||||
|
||||
* Ensure location has [tamper proofing tools](../../../../../../tamper-evidence-methods.md#vacuum-sealed-bags-with-filler)
|
||||
|
||||
* Vacuum sealer
|
||||
|
||||
* Vacuum roll
|
||||
|
||||
* Colored beads
|
||||
|
||||
* PureBoot smart card (TODO)
|
||||
|
||||
* 5 SD cards (2 fresh, formatted as ext4, and 3 cards with prepared data)
|
||||
|
||||
* 1 SD card for transferring transaction data from online to air-gapped machine
|
||||
|
||||
* 1 SD card for storing tamper proofing evidence produced at the end of the ceremony
|
||||
|
||||
* 1 SD card which has the shardfile, labelled "Shardile"
|
||||
|
||||
* This should be write-locked and stored in tamper proofing along with air-gapped machine
|
||||
|
||||
* 1 SD card with "trusted keys" for proposers and approvers, both signed by each operator using their operator key (TODO)
|
||||
|
||||
* This should be write-locked and stored in tamper proofing along with air-gapped machine
|
||||
|
||||
* 1 SD card with AirgapOS
|
||||
|
||||
* This should be write-locked and stored in tamper proofing along with air-gapped machine
|
||||
|
||||
* Digital camera (TODO selection)
|
||||
|
||||
* [Online machine](../../../../../../online-machine-provisioning.md) used for fetching transaction data
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Verify all transactions for the ceremony in the `ceremonies` repository, ensuring that all the transactions are properly signed by the proposer and the approver.
|
||||
1. Enter the designated location with the 3 operators and all required equipment
|
||||
|
||||
- [ ] TODO guide on how to do this
|
||||
2. Lock access to the location - there should be no inflow or outflow of people during the ceremony
|
||||
|
||||
1. Enter the designated location with the 2 operators and all required equipment
|
||||
|
||||
1. Lock access to the location - there should be no inflow or outflow of people during the ceremony
|
||||
|
||||
1. Retrieve sealed laptop and polaroid from locked storage
|
||||
3. Retrieve sealed laptop and polaroid from locked storage
|
||||
|
||||
### Unsealing Tamper Proofing
|
||||
{{ #include ../../../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
{{ #include ../../../../../../tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
### Secure Boot Procedure
|
||||
1. Plug PureBoot smart card into air-gapped machine
|
||||
0. Plug PureBoot smart card into air-gapped machine
|
||||
|
||||
1. Plug in SD card labelled "AirgapOS"
|
||||
|
||||
1. Boot the computer and verify the hash of the version of AirgapOS that's booted
|
||||
{{ #include ../../../../../../secure-boot-sequence.md:prepared}}
|
||||
|
||||
1. Plug in SD card labelled "Keychain"
|
||||
0. Plug in SD card labelled "Trusted Keys"
|
||||
|
||||
* Load well known PGP keys of proposer and approver along with detached signatures of the keys (NOT IMPLEMENTED)
|
||||
* Load well known PGP keys of proposer and approver, and sign them using operator keys (TODO: NOT IMPLEMENTED)
|
||||
|
||||
* `gpg --import <keyfile_name>`
|
||||
|
||||
1. Insert SD card labelled "shardfile"
|
||||
|
||||
1. `keyfork recover shard --daemon`
|
||||
2. `keyfork recover shard --daemon`
|
||||
|
||||
* Follow on screen prompts
|
||||
|
||||
1. As a last step, run the `icepick` command which is awaiting the transaction payload
|
||||
3. As a last step, run the `icepick` command which is awaiting the transaction payload
|
||||
|
||||
* `icepick workflow sol-transfer`
|
||||
|
||||
* Follow on screen prompts
|
||||
|
||||
|
||||
### Obtain Transaction Request
|
||||
|
||||
1. Turn on online machine
|
||||
|
||||
1. Get transaction request(s)
|
||||
2. Get transaction request(s)
|
||||
|
||||
* TODO define means (could just be email?)
|
||||
|
||||
1. Run `icepick workflow sol-broadcast` command
|
||||
3. Run `icepick workflow sol-broadcast` command
|
||||
|
||||
* Wait for prompt and plug in fresh SD card
|
||||
|
||||
|
|
@ -73,41 +103,43 @@
|
|||
|
||||
* This command will set the computer into "awaiting mode", which will broadcast the signed transaction from the SD card once it's plugged back in
|
||||
|
||||
1. Unplug the SD card and pass it to the air-gapped machine operators
|
||||
5. Unplug the SD card and pass it to the air-gapped machine operators
|
||||
|
||||
### Sign Transaction
|
||||
|
||||
1. Plug in SD card with transaction payload
|
||||
|
||||
1. Wait for the screen to display the transaction information. (NOT IMPLEMENTED)
|
||||
2. Wait for the screen to display the transaction information. (TODO: NOT IMPLEMENTED)
|
||||
|
||||
* In the background:
|
||||
|
||||
* The transaction is constructed
|
||||
|
||||
* Signatures of tx data are verified against well known keys which were loaded by operators into local GPG keychain and signed by operators (NOT IMPLEMENTED)
|
||||
* Signatures of tx data are verified against well known keys which were loaded by operators into local GPG keychain and signed by operators (TODO: NOT IMPLEMENTED)
|
||||
|
||||
1. If any issues are detected with data you will be prompted and should initiate [incident response (todo)](todo)
|
||||
3. If any issues are detected with data you will be prompted and should initiate [incident response (todo)](todo)
|
||||
|
||||
1. Wait for the "completed" message
|
||||
4. Wait for the "completed" message
|
||||
|
||||
1. Unplug and give the SD card back to the online machine operator
|
||||
5. Unplug and give the SD card back to the online machine operator
|
||||
|
||||
### Broadcast Transaction
|
||||
|
||||
1. Online machine operator takes the SD card to online machine and plugs it in
|
||||
* Online machine operator takes the SD card to online machine and plugs it in
|
||||
|
||||
1. The still running process from running the command to create the transaction in [Obtain Transaction Request](#obtain-transaction-request) will broadcast the transaction automatically
|
||||
* The still running process from running the command to create the transaction in [Obtain Transaction Request](#obtain-transaction-request) will broadcast the transaction automatically
|
||||
|
||||
1. Await the "completed" message
|
||||
* Await the "completed" message
|
||||
|
||||
### Finalization
|
||||
|
||||
1. Shut down online machine
|
||||
* Shut down online machine
|
||||
|
||||
1. Shut down the air gapped machine
|
||||
* Shut down the air gapped machine
|
||||
|
||||
* TODO: Add information about material disposal, per this discussion: https://git.distrust.co/public/docs/pulls/10#issuecomment-1004
|
||||
|
||||
#### Sealing
|
||||
|
||||
{{ #include ../../../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
{{ #include ../../../../../../tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,21 +0,0 @@
|
|||
# PGP Key Provisioning
|
||||
|
||||
## Requirements
|
||||
|
||||
* For each new key to be provisioned:
|
||||
|
||||
* New smart card
|
||||
|
||||
* 2 new SD cards
|
||||
|
||||
* Tamper proofing evidence photographs
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Enter the facility with all personnel and required equipment
|
||||
|
||||
1. Lock access to the facility for the duration of the ceremony
|
||||
|
||||
1. Unseal the tamper proofed bundle consisting of a air-gapped laptop, "AirgapOS" SD card and "Keychain" SD card
|
||||
|
||||
{{ #include ../../../../component-documents/openpgp-setup.md:steps-keyfork}}
|
||||
|
|
@ -1,53 +0,0 @@
|
|||
# Root Entropy Generation
|
||||
|
||||
This is a ceremony for generating root entropy.
|
||||
|
||||
## Requirements
|
||||
|
||||
* Ensure both primary operators have their [Operator Keys](../../pgp-key-provisioning.md)
|
||||
|
||||
* Both operators should print photographic evidence from digital cameras which is stored in a PGP signed repository. The photographs should be of the top and underside of the vacuum sealed object.
|
||||
|
||||
* The operators should verify the commit signatures of the photographs they are printing against a list of permitted PGP keys
|
||||
|
||||
- [ ] TODO: where do we refer to permitted PGP keys
|
||||
|
||||
* Each operator should hash the `keychain` repository
|
||||
- [ ] TODO define keychain repository setup
|
||||
|
||||
* `sha256sum keychain/`
|
||||
|
||||
* Write it down on a piece of paper as it will be used during the ceremony
|
||||
|
||||
* Each member needs to bring their:
|
||||
|
||||
* Ceremony Notes
|
||||
|
||||
* Ceremony SD Card
|
||||
- [ ] TODO explain what this is
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Enter the designated location with the 2 operators and all required equipment
|
||||
|
||||
1. Lock access to the location - there should be no inflow or outflow of people during the ceremony
|
||||
|
||||
1. Retrieve sealed laptop and polaroid from locked storage
|
||||
|
||||
### Unsealing Tamper Proofing
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
### Generating Entropy
|
||||
1. Boot AirgapOS on the airgapped machine
|
||||
|
||||
1. Verify the hash of the AirgapOS version once it's booted
|
||||
|
||||
1. Run `ceremony.sh`
|
||||
|
||||
1. Button mash to ensure adequate entropy on the OS
|
||||
|
||||
1. Back up the `shardfile`, and `pub.asc` to at least 2 separate SD cards
|
||||
|
||||
### Finalizing Ceremony
|
||||
|
||||
1. Seal the airgapped bundle (TODO)
|
||||
|
|
@ -4,7 +4,7 @@ The proposer is a fiduciary whose responsibility is to make sound financial deci
|
|||
|
||||
The proposer MUST clearly define, at a minimum:
|
||||
|
||||
* Token Name (SOL, PYTH-SPL, ETH, ETH-PYTH, BTC etc.)
|
||||
* Token Name (SOL, PYTH-SPL, ETH, BTC etc.)
|
||||
|
||||
* FROM address
|
||||
|
||||
|
|
@ -12,58 +12,17 @@ The proposer MUST clearly define, at a minimum:
|
|||
|
||||
* Amount
|
||||
|
||||
* Date + Time
|
||||
|
||||
The proposer must combine these values into a single message, which can be a simple JSON file, and sign it using a well known PGP key.
|
||||
|
||||
## Requirements
|
||||
```json
|
||||
{
|
||||
"from-address": "<address>",
|
||||
"to-address": "<address>",
|
||||
"token-name": "<name>",
|
||||
"token-amount": "<amount>"
|
||||
}
|
||||
```
|
||||
|
||||
* If necessary, provision a PGP key pair to a smart card using the guide in the [Appendix: Generating PGP Keypair & Provisioning Smart Card](#generating-pgp-keypair--provisioning-smart-card)
|
||||
To sign use the command:
|
||||
|
||||
* Ensure that the computer is configured to sign commits with the desired key. Refer to the [Appendix: Git Commit Signing Configuration](#git-commit-signing-configuration)
|
||||
|
||||
* Clone the [Ceremonies Repository](../provisioner/provision-ceremonies-repository.md) for your organization to the machine
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Define a new file "<date:time>-<currency>.tx.json", for example "16:40-PYTH-SPL.tx.json"
|
||||
|
||||
1. Create a new directory in the `ceremonies` repository for the date on which the ceremony for the transaction will take place if it doesn't already exist, for example `2024-01-01/`
|
||||
|
||||
1. Collect data for the transaction being sent, and structure it according to the template below, replacing values with valid ones. The values have to come from a organization approved list of values, for each field, except for `datetime` which is just the current date and time.
|
||||
```json
|
||||
{
|
||||
"token-name": "<name>",
|
||||
"token-amount": "<amount>",
|
||||
"from-address": "<address>",
|
||||
"to-address": "<address>",
|
||||
"datetime": "<date:time>"
|
||||
}
|
||||
```
|
||||
|
||||
Example data object:
|
||||
```json
|
||||
{
|
||||
"token-name": "PYTH-SLN",
|
||||
"token-amount": "42",
|
||||
"from_address": "2Z72E62atYfpatQeqPvHZMaabmuz664xq5MRWv9xM5NX",
|
||||
"to_address": "BNQr6T2UAuEPux1fuiygM6chrT5GkHKaMWeTTaRLmR7g",
|
||||
"datetime": "<date:time>"
|
||||
}
|
||||
```
|
||||
|
||||
1. Sign the data in the CLI using `gpg` or another OpenPGP implementation:
|
||||
|
||||
* `gpg --clearsign <file>`
|
||||
|
||||
1. Notify relevant individuals that there are new transactions queued up, and that a ceremony should be scheduled. This can be automated in the future so that when a commit is made or PR opened, others are notified, for example using a incident management tool(TODO).
|
||||
|
||||
## Appendix
|
||||
|
||||
### Git Commit Signing Configuration
|
||||
|
||||
{{ #include ../../../../component-documents/git-commit-signing.md:steps }}
|
||||
|
||||
### Generating PGP Keypair & Provisioning Smart Card
|
||||
|
||||
{{ #include ../../../../component-documents/openpgp-setup.md:steps-keyfork }}
|
||||
`gpg --clearsign <filename>`
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
# Copy Shardfile SD Card
|
||||
|
||||
There should be multiple SD cards containing the shardfile data. Shardfile data is produced during a [Root Entropy](../operator/hybrid-key-provisioning.md) derivation ceremony.
|
||||
|
||||
Label the SD card: "Shardfile <date>"
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
# Provisioner
|
||||
|
||||
The provisioner is responsible for:
|
||||
|
||||
* Procuring equipment
|
||||
|
||||
* Setting up the [Facility](#facility)
|
||||
|
||||
* Maintaining stock of supplies in the [Facility](#facility)
|
||||
|
||||
* Minimizing hardware supply chain security risks
|
||||
|
||||
## Directives
|
||||
|
||||
* MUST maintain chain of custody for all hardware until after it's properly stored or where necessary tamper-proofed
|
||||
|
||||
The different procedures are ordered in chronological preference, to improve the efficiency of setting up the system.
|
||||
|
||||
## Procedures
|
||||
|
||||
The first task is to bootstrap the operator keys as they are an essential part of building a chain of trust. To achieve this, a bootstrapping ceremony can be used in order to procure hardware and generate keys in one continuous session. This ensures that the chain of custody is maintained for the hardware, and then that hardware is used to generate and seed PGP keys to smart cards, which can then be committed to the keychain repository, and used to sign tamper proofing evidence.
|
||||
|
||||
[Initial Bootstrapping Ceremony](./pgp-key-bootstrapping.md)
|
||||
|
||||
### Procedures Without Prerequisites
|
||||
* [Provision Facility](./provision-facility.md)
|
||||
* [Provision Keychain Repository](./provision-keychain-repository.md)
|
||||
* [Provision SD Card](./provision-sd-card.md)
|
||||
* [Provision Tamper Proofing Equipment](./provision-tamper-proofing-equipment.md)
|
||||
* [Provision Ceremonies Repository](./provision-ceremonies-repository.md)
|
||||
* [Provision AirgapOS](./provision-airgapos.md)
|
||||
|
||||
### Procedures With Prerequisites
|
||||
* [Procure Computer](./procure-computer.md)
|
||||
* Requires tamper proofing equipment to be available
|
||||
* [Provision Air Gapped Bundle](./provision-air-gapped-bundle.md)
|
||||
* Requires operators to have PGP smart cards, tamper proofing equipment, AirgapOS SD card
|
||||
* [Copy Shardfile SD Card](./copy-shardfile-sd-card.md)
|
||||
* Requires Root Entropy ceremony to be completed in order to have "Shardfile" SD cards available for copying
|
||||
|
|
@ -1,61 +0,0 @@
|
|||
# Operator - Provisioning PGP Keypair
|
||||
|
||||
## Requirements
|
||||
|
||||
The initial set up requires the provisioner and operator to do all of these in a continuous session ensuring dual custody. Ensure that all participants are familiar with the sub-processes so that the ceremony can be completed in one working day.
|
||||
|
||||
* 3 individuals in order to have the flexibility for washroom breaks, fetching food and drinks etc.
|
||||
|
||||
* [AirgapOS SD Card](./provision-airgapos.md)
|
||||
|
||||
* [Tamper Proofing Equipment](./provision-tamper-proofing-equipment.md)
|
||||
|
||||
* [Smart Cards](../../../../component-documents/hardware-models.md#smart-cards)
|
||||
|
||||
* 2 per PGP keypair
|
||||
|
||||
* SD Cards: [Provisioning Guide](./provision-sd-card.md)
|
||||
|
||||
* 3 per PGP keypair (for backups)
|
||||
|
||||
* Designated [facility](./provision-facility.md)
|
||||
|
||||
* Sealable plastic bag: {{ #include ../../../../component-documents/hardware-models.md:sealable-plastic-bags }}
|
||||
|
||||
## Procedure
|
||||
|
||||
### Procure Hardware
|
||||
|
||||
{{ #include ../../../../component-documents/hardware-procurement-and-chain-of-custody.md:steps }}
|
||||
|
||||
### Ceremony
|
||||
|
||||
1. Enter the designated facility with an operator and individual keys are being generated for and all required equipment
|
||||
|
||||
1. Lock access to the facility - there should be no inflow or outflow of people during the ceremony if avoidable. During a long ceremony as this one this may be unavoidable.
|
||||
|
||||
1. Gut the laptop before using it: radio cards, speakers, microphones, storage drive
|
||||
|
||||
1. Boot AirgapOS from verified SD card
|
||||
|
||||
1. Check AirgapOS hashes when it's booted
|
||||
|
||||
### Generating PGP Keys and Seeding Cards
|
||||
|
||||
{{ #include ../../../../component-documents/openpgp-setup.md:steps-keyfork}}
|
||||
|
||||
### Tamper Proofed Bundle
|
||||
|
||||
The following objects should be in the bundle:
|
||||
|
||||
* AirgapOS SD Cards
|
||||
|
||||
* Airgapped computer
|
||||
|
||||
#### Procedure
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
|
||||
1. Create tamper proofed bundle (airgapos, laptop)
|
||||
|
||||
1. Submit evidence to ceremonies repo
|
||||
|
|
@ -0,0 +1,56 @@
|
|||
# Provisioner - Procure Hardware
|
||||
|
||||
The provisioner is responsible for procuring equipment. Their main focus is:
|
||||
|
||||
* Minimizing hardware supply chain security risks
|
||||
|
||||
* Ensuring availability of necessary equipment
|
||||
|
||||
## Laptops
|
||||
|
||||
### Air-Gapped Machine
|
||||
|
||||
1. Procure a [Purism Librem 14](../../../../hardware.md#air-gapped-computer)
|
||||
|
||||
2. Provision AirgapOS using [this guide](../../../../one-time-use-airgapos.md)
|
||||
|
||||
3. Apply [vacuum sealing + filler tamper proofing](../../../../tamper-evidence-methods.md#vacuum-sealed-bags-with-filler) to the laptop and the SD card
|
||||
|
||||
4. Store the sealed package in a secure location
|
||||
|
||||
### Online Machine
|
||||
|
||||
Procure either a ChromeBook or a computer capable of running QubesOS according to [this guide](../../../../online-machine-provisioning.md)
|
||||
|
||||
## Tamper Proofing Equipment
|
||||
|
||||
This guide contains specific equipment models: [guide](../../../../tamper-evidence-methods.md#vacuum-sealed-bags-with-filler)
|
||||
|
||||
* Vacuum Sealer
|
||||
|
||||
* Vacuum sealer roll
|
||||
|
||||
* Colored beads
|
||||
|
||||
* Digital camera
|
||||
|
||||
* Polaroid camera
|
||||
|
||||
## Other Equipment
|
||||
|
||||
* SD cards
|
||||
|
||||
* TODO: Add clarification around formatting and labeling SD cards, per this discussion: https://git.distrust.co/public/docs/pulls/10#issuecomment-1004
|
||||
|
||||
* [Kingston Industrial 8GB SD Memory Card](https://www.kingston.com/en/memory-cards/industrial-grade-sd-uhs-i-u3?capacity=8gb)
|
||||
|
||||
* [Kingston Indsutrial 8GB microSD Memory Card](https://shop.kingston.com/products/industrial-microsd-card-memory-card?variant=40558543405248)
|
||||
|
||||
* SD Card USB Adapter
|
||||
|
||||
* SD card reader: https://www.kingston.com/en/memory-card-readers/mobilelite-plus-sd-reader
|
||||
|
||||
* microSD card reader: https://www.kingston.com/en/memory-card-readers/mobilelite-plus-microsd-reader
|
||||
|
||||
* Workflow station hub (may prove helpful with workflows): https://www.kingston.com/en/memory-card-readers/workflow-station-hub
|
||||
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
## Provision Air-gapped Bundle
|
||||
|
||||
* Tamper proof together the following objects:
|
||||
|
||||
* [Air-gapped machine](./provision-computer.md)
|
||||
|
||||
* [AirgapOS SD card](./provision-airgapos.md)
|
||||
|
||||
* [Shardfile SD card](../operator/root-entropy-generation.md)
|
||||
|
||||
### Procedure
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing }}
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
## AirgapOS (SD Card)
|
||||
|
||||
An SD card with AirgapOS written to it will be required to run ceremonies.
|
||||
|
||||
The AirgapOS SD Card once provisioned will be used in creating the [tamper proofed airgap bundle](#air-gapped-bundle)
|
||||
|
||||
{{ #include ../../../../component-documents/one-time-use-airgapos.md:steps }}
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
# Provision Ceremony Repository
|
||||
|
||||
{{ #include ../../../../component-documents/ceremony-repository.md:content }}
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
# Provision Computer
|
||||
|
||||
For [Level 2](../../../../threat-model.md#level-2) security, air-gapped computers which are used for cryptographic material management and operations are required.
|
||||
|
||||
Sealable plastic bag is required for this procedure:
|
||||
|
||||
{{ #include ../../../../component-documents/hardware-models.md:sealable-plastic-bags }}
|
||||
|
||||
### Models
|
||||
|
||||
{{ #include ../../hardware.md:computer-models }}
|
||||
|
||||
### Procedure
|
||||
|
||||
{{ #include ../../../../component-documents/hardware-procurement-and-chain-of-custody.md:steps}}
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
# Provision Facility
|
||||
|
||||
1. Identify a location which is suitable for Level 2 ceremonies:
|
||||
|
||||
* SHOULD be lockable to prevent inflow and outflow of persons during ceremonies
|
||||
|
||||
1. Procure an enclosure for locking equipment. A simple lockbox or a safe can be used. It should be at least large enough to fit several laptops, with some extra room.
|
||||
|
||||
1. Designate the location as the facility for conducting ceremonies and update documentation and policies to reflect this
|
||||
|
||||
## Maintenance
|
||||
|
||||
* The facility should always be well stocked with freshly formatted SD cards
|
||||
|
||||
* There should be at least 20 microSD and 20 SD cards available for use
|
||||
|
||||
* Both microSD and regular SD cards should be available
|
||||
|
||||
* They should be formatted to `fat32` format
|
||||
|
||||
* Usage of these SD cards:
|
||||
|
||||
* Transferring transaction data from online to air-gapped machine
|
||||
|
||||
* Storing tamper proofing evidence produced at the end of the ceremony
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
## Preparing SD Cards
|
||||
|
||||
SD cards don't require special chain of custody, but ideally should be purchased from a reputable supplier.
|
||||
|
||||
### SD Card Models
|
||||
|
||||
{{ #include ../../../../component-documents/hardware-models.md:sd-models }}
|
||||
|
||||
### Procedure: formatting SD Card to `fat32`
|
||||
|
||||
{{ #include ../../../../component-documents/sd-formatting.md:steps }}
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
# Provision Tamper Proofing Equipment
|
||||
|
||||
### Vacuum Sealer and roll
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-equipment}}
|
||||
|
||||
### Colored beads
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-filler}}
|
||||
|
||||
### Digital camera
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:digital-cameras}}
|
||||
|
||||
### Polaroid camera
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:polaroid-cameras}}
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Hardware for Level 2 Threat Model
|
||||
|
||||
## Computers
|
||||
|
||||
* Computers for this use are are appropriate as long as they are compatible with AirgapOS. At this level, the essential aspect of hardware procurement is to ensure dual custody at all times. Outside of that any additional protections are welcome but not necessary.
|
||||
|
||||
* Laptops with chargers over ports which don't allow data transfer is preferred (non USB etc.)
|
||||
|
||||
// ANCHOR: computer-models
|
||||
|
||||
* HP 13" Intel Celeron - 4GB Memory - 64GB eMMC, HP 14-dq0052dx, SKU: 6499749, UPC: 196548430192, DCS: 6.768.5321, ~USD $179.99
|
||||
* [Illustrated Parts Catalog](https://h10032.www1.hp.com/ctg/Manual/c04501162.pdf#%5B%7B%22num%22%3A3160%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2Cnull%2C732%2Cnull%5D)
|
||||
|
||||
* Lenovo 14" Flex 5i FHD Touchscreen 2-in-1 Laptop - Intel Core i3-1215U - 8GB Memory - Intel UHD Graphics, SKU: 6571565, ~USD $379.99
|
||||
|
||||
* Purism Librem 14
|
||||
|
||||
* Nova Custom (Untested)
|
||||
|
||||
* Computers which are compatible which can be verified via [this guide](https://git.distrust.co/public/airgap#hardware-compatibility)
|
||||
|
||||
// ANCHOR_END: computer-models
|
||||
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -10,7 +10,7 @@ using an algorithm, called a cipher.
|
|||
Entropy in cryptography refers to the measure of randomness or unpredictability
|
||||
in data used for generating cryptographic keys and other security elements.
|
||||
|
||||
## Quorum Key Management (QVS)
|
||||
## Quorum Key Management (QKM)
|
||||
|
||||
A set of highly specified processes and tooling used for setting up a highly
|
||||
resilient quorum-based key management system.
|
||||
|
|
@ -19,7 +19,7 @@ resilient quorum-based key management system.
|
|||
|
||||
An individual who manages an [Operator Key](#operator-key) which is used for
|
||||
protecting the passphrase of a Location key and participates in different
|
||||
aspects of the lifecycle management of the QVS system.
|
||||
aspects of the lifecycle management of the QKM system.
|
||||
|
||||
## Operator Key
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ the total number of shards that exist. The minimum recommended threshold is
|
|||
|
||||
## Organization
|
||||
|
||||
An organization which owns the QVS and is responsible for funding the setup and
|
||||
An organization which owns the QKM and is responsible for funding the setup and
|
||||
maintenance. The organization is also responsible for ensuring that the
|
||||
[Warehouse](#warehouse) is properly maintained in order to ensure that the
|
||||
ciphertext blobs associated with the system are redundantly stored and
|
||||
|
|
|
|||
|
|
@ -8,8 +8,6 @@ Destroying hardware should be done by using a combination of:
|
|||
|
||||
* Shredding
|
||||
|
||||
* Pulverizing
|
||||
|
||||
All three methods should be used because of the efficacy of using electron
|
||||
microscopy to read data from storage drives which have not been completely
|
||||
destroyed.
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
# Procurement & Chain of Custody
|
||||
|
||||
## Provisioning Chain of Custody
|
||||
|
||||
Materials and devices which are used in the context of a high assurance system need to be monitored carefully from the moment they are purchased to ensure there are no single points of failure. Going back to the assumption that participants in the system are subject to [MICE](./glossary.md#MICE) and as such may pose a threat to the system, special care has to be taken that multiple individuals are involved in the whole lifecycle of provisioning a piece of equipment.
|
||||
|
||||
All steps of the provisioning process need to be completed under the supervision of at least 2 individuals, but benefit from having even more individuals present to increase the number of witnesses and allow individuals to take washroom breaks, purchase food and take breaks.
|
||||
|
||||
The following steps must all be completed under the continued supervision and with the involvement of all parties present. It is instrumental that there is not a single moment where the device is left unsupervised, or under the supervision of only 1 individual.
|
||||
|
||||
## Provisioning Hardware
|
||||
|
||||
1. Selecting a Purchase Location
|
||||
|
||||
Select at least 3 stores which carry the type of equipment being purchased, then randomly select one using the roll of a die, or other random method.
|
||||
|
||||
This is done in order to reduce the likelihood that a threat actor is able to plant a compromised computer in a store.
|
||||
|
||||
2. Within the store, identify available adequate laptops from the list of [tested hardware](#tested-hardware-airgapos-compatibility). Alternatively bring an SD card with AirgapOS, and test booting to it on the device on the store floor before purchasing it.
|
||||
|
||||
3. Purchase the device and place it in a see-through plastic bag which will be used to transport it to a "processing location", which is ideally just a access controlled space. The bag MUST be a sealable see-through tamper evident bag.
|
||||
|
||||
* TODO: Add sources for suitable tamper evidence bags, per this discussion: https://git.distrust.co/public/docs/pulls/10#issuecomment-897
|
||||
|
||||
4. At the processing location, one of the individuals is responsible for observing while the other opens the back of the laptop and removes:
|
||||
|
||||
* Radio cards (wifi, bluetooth)
|
||||
|
||||
* Storage drive
|
||||
|
||||
* Speakers
|
||||
|
||||
* Microphone
|
||||
|
||||
Each laptop model is laid out slightly differently so use an online reference and/or read the names of the components which are found in the laptop to determine which parts to remove.
|
||||
|
||||
* TODO: Add example online reference, per this discussion: https://git.distrust.co/public/docs/pulls/10#issuecomment-898
|
||||
|
||||
5. Apply a [tamper proofing](./tamper-evidence-methods.md) method to the device depending on the [device designation](TODO)
|
||||
|
||||
## Tested Hardware (AirgapOS Compatibility)
|
||||
|
||||
* HP 13" Intel Celeron - 4GB Memory - 64GB eMMC, HP 14-dq0052dx, SKU: 6499749, UPC: 196548430192, DCS: 6.768.5321, ~USD $179.99
|
||||
* [Illustrated Parts Catalog](https://h10032.www1.hp.com/ctg/Manual/c04501162.pdf#%5B%7B%22num%22%3A3160%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2Cnull%2C732%2Cnull%5D)
|
||||
|
||||
* Lenovo 14" Flex 5i FHD Touchscreen 2-in-1 Laptop - Intel Core i3-1215U - 8GB Memory - Intel UHD Graphics, SKU: 6571565, ~USD $379.99
|
||||
|
||||
To ensure that hardware is compatible, it can be tested by bringing an SD card with AirgapOS loaded on it, and testing booting to a floor model in the store.
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
# Hardware
|
||||
|
||||
This page describes different equipment which is required, and makes opinionated
|
||||
recommendations as well as alternatives. One may improve the overall security
|
||||
of their system by using a variety of hardware in order to benefit from their
|
||||
diversity, by reducing the likelihood that all hardware has suffered the same
|
||||
kind of hardware supply chain compromise, has the same vulnerability present, or
|
||||
has the same type of hardware failure issue.
|
||||
|
||||
Based on the decided upon [Quorum](selecting-quorum.md), the amount of equipment
|
||||
required to set up a [QKM](glossary.md#quroum-kms-QKM) will
|
||||
vary. In order to figure out what equipment is required, decide on a Quorum,
|
||||
which is expressed as "N of M". Once you know your M, the required equipment list
|
||||
is the following:
|
||||
|
||||
* M x 4 Smart Cards
|
||||
|
||||
* It is recommended to use two Smart Cards for storing each key pair
|
||||
|
||||
* Ideally two different types of hardware are used in order to reduce the
|
||||
risk of simultaneous failure
|
||||
|
||||
* At least 1 Smart Card is required for each Operator Key and 1 Smart Card
|
||||
for each Location Key
|
||||
|
||||
* The number of Operator Keys is M, and the number of Location Keys is also
|
||||
M, hence the minimum of 2 x M Smart Cards, with the recommendation of using
|
||||
two smart cards for each, resulting in 4 x M Smart Cards
|
||||
|
||||
* 2 + X Storage Devices
|
||||
|
||||
* 1 Storage Device for [AirgapOS](repeat-use-airgapos.md)
|
||||
|
||||
* 1 Storage Device for storing [Public Ceremony Artifacts](public-ceremony-artifact-storage.md)
|
||||
|
||||
* X, or *any* number of additional Storage Devices to duplicate the data, a
|
||||
good measure would be to have at least 3 Storage Devices for the ceremony
|
||||
|
||||
* Librem 14 Laptop
|
||||
|
||||
* Get as many laptops as desired to satisfy your operational needs
|
||||
|
||||
* For each Librem 14, get a Librem Smart Card used for [PureBoot](initialize-pureboot-smart-card.md)
|
||||
|
||||
## Smart Cards
|
||||
|
||||
Smart Cards are primarily used for storing OpenPGP cryptographic keys which are
|
||||
used as a building block for security controls. These smart cards hold OpenPGP
|
||||
keys which are derived in secure environments.
|
||||
|
||||
There are three primary requirements for smart cards:
|
||||
|
||||
* FIPS 140-2
|
||||
|
||||
* Support for Ed25519 OpenPGP
|
||||
|
||||
* Touch for enacting operations
|
||||
|
||||
Some options include:
|
||||
|
||||
* NitroKey 3 - because of its open source approach which allows for verification
|
||||
|
||||
* YubiKey 5 - because of the widespread use and battle-tested reliability
|
||||
|
||||
* Librem Key - because of the manufacturer's approach to hardware supply chain
|
||||
security and verifiable software
|
||||
|
||||
## Air-Gapped Computer
|
||||
|
||||
[Air-Gapped](glossary.md#Air-Gapped) computers are used for the lifecycle
|
||||
management of cryptographic material that is part of QKM.
|
||||
|
||||
The primary hardware recommendation for an Air-Gapped Computer is the [Librem 14](https://puri.sm/products/librem-14/), manufactured by [Purism](puri.sm). Purism specializes in reducing hardware and
|
||||
firmware security risks, especially via their [Anti-Interdiction Service](https://puri.sm/posts/anti-interdiction-services/) and [PureBoot](https://docs.puri.sm/PureBoot.html)
|
||||
and as such is an excellent choice for hardware which high integrity assurance is
|
||||
required for.
|
||||
|
||||
#### Alternative
|
||||
|
||||
An alternative approach is to use an off-the-shelf computer that is randomly
|
||||
selected right before the ceremony, removing the storage drive(s), radio cards,
|
||||
microphone(s) and speakers from it to reduce side channel attack risks, using it
|
||||
to conduct a Ceremony, and then destroying the laptop using sufficiently
|
||||
adequate method to ensure that no data forensics can be used to recover the data
|
||||
from the drive, or memory. This can be achieved by using a combination of
|
||||
incineration, degaussing, shredding, smashing and drilling. Special care should
|
||||
be taken to completely destroy all components of the computer that are able to
|
||||
store data, even if it's only in ephemeral form as some forensic methods all
|
||||
extraction of data from components with "temporary memory".
|
||||
|
||||
Three letter agencies are known to collect and exploit physical destroyed drives,
|
||||
as data can still be extracted from them using methods such as electron
|
||||
microscopy, therefore a combination of degaussing, shredding and burning should
|
||||
be used, and the remaining debris should be spread out across multiple disposal
|
||||
locations.
|
||||
|
||||
## Storage Device
|
||||
|
||||
Can be an SD Card (preferred due to smaller attack surface) or USB Drive but
|
||||
should be procured from a vendor with a good reputation, and ideally hardware of
|
||||
industrial grade should be prioritized for durability.
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
# Hybrid Key Provisioning
|
||||
|
||||
This document contains instructions on how Operators collaborate to set up
|
||||
QKM where the Operator Keys and Location Keys were generated before this
|
||||
ceremony and only the PGP Public Certificates of the Location keys are brought
|
||||
to the ceremony which are used to shard the Root Entropy. This is useful
|
||||
when conducting the ceremony in a lower trust environment, and where not all
|
||||
aspects of the ceremony can be controlled to the desired degree.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Prior to the ceremony, set up a git repository with relevant artifacts in it,
|
||||
and create Ceremony Notes according to [this](one-time-repository-setup.md)
|
||||
guide.
|
||||
|
||||
2. Ensure there are additional witnesses for the ceremony, outside of the
|
||||
operators to assist in monitoring and verifying the integrity of the process.
|
||||
|
||||
* Designate at least 1 individual to keep notes on the ceremony based
|
||||
on the [Ceremony Log Template](ceremony-log-template.md)
|
||||
|
||||
3. Ensure that no participants have brought digital devices other than ones
|
||||
necessary for the ceremony. A faraday bag may be used to hold any such devices
|
||||
for the duration of the ceremony.
|
||||
|
||||
4. Procure a laptop and SD cards (3) from a randomly selected store and
|
||||
ensure at least 2 people are in line of sight of all the hardware until the
|
||||
ceremony is executed. It may be worthwhile to try booting from the SD card at
|
||||
the store. Dell laptops tend to support booting from SD cards while Lenovo
|
||||
don't. More notes on selecting hardware can be found [here](one-time-use-hardware-procurement.md)
|
||||
|
||||
5. Secure a [Location](one-time-use-locations.md)
|
||||
|
||||
6. Each member needs to bring their:
|
||||
|
||||
* Ceremony Notes
|
||||
|
||||
* Ceremony SD Card
|
||||
|
||||
* Airgap SD Card (only 1 member needs to bring this - set up according to
|
||||
[One Time Use / AirgapOS Setup](one-time-use-airgapos.md)).
|
||||
|
||||
7. Verify the SD card by either:
|
||||
|
||||
* Booting a separate AirgapOS to the machine used for the ceremony in order
|
||||
to verify the SD card is not writeable and the hash matches using the steps
|
||||
from the [One Time Use/ AirgapOS Setup](one-time-use-airgapos.md) guide.
|
||||
|
||||
OR
|
||||
|
||||
* Mounting the SD card to a separate machine and verifying it's not
|
||||
writeable and verify the hash matches using steps from the [One Time Use/AirgapOS Setup](one-time-use-airgapos.md) guide.
|
||||
|
||||
* NOTE: It is essential that the SD card remain in line of sight from the
|
||||
moment it is verified to the moment is is used.
|
||||
|
||||
8. Plug in and boot from Airgap SD card:
|
||||
|
||||
* Boot from internal SD card reader or USB device reader
|
||||
|
||||
* Verify the `sha256sum ceremony.sh` hash matches each of the Operator's
|
||||
"Ceremony Notes"
|
||||
|
||||
9. Button mash to ensure adequate entropy on the OS
|
||||
|
||||
10. Set the system time as it has to be after the PGP
|
||||
public certificates were created, and before they expire:
|
||||
|
||||
* `date -s "YYYY-MM-DD HH:MM:SS"`
|
||||
|
||||
10. Run `ceremony.sh`
|
||||
|
||||
11. Back up the `shardfile`, and `pub.asc` to 3 separate SD cards,
|
||||
one for each operator
|
||||
|
||||
12. Destroy the computer according to [Hardware Destruction](hardware-destruction.md)
|
||||
guide.
|
||||
|
|
@ -1,9 +1,5 @@
|
|||
# PureBoot Setup
|
||||
|
||||
- [ ] TODO: fix this doc to use a different smart card for pureboot as the librem key, as the librem key doesn't have a physical switch
|
||||
|
||||
- [ ] TODO update this to be hardware agnostic and use Heads / PureBoot
|
||||
|
||||
This guide walks the user through setting up a machine which relies on
|
||||
[PureBoot](https://source.puri.sm/firmware/pureboot) to verify the authenticity
|
||||
of the `.iso` image which is being booted, as well to ensure that firmware of
|
||||
|
|
@ -15,7 +11,7 @@ This guide assumes the use of a Purism machine, with a Librem Key.
|
|||
|
||||
* 1 Storage Device
|
||||
|
||||
* 1 Smart Card
|
||||
* 1 Librem Smart Card
|
||||
|
||||
* 1 Librem 14 Computer with [PureBoot firmware installed](flash-pureboot-firmware.md).
|
||||
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Introduction
|
||||
|
||||
Quorum Vaulting System (QVS) is an open source system of playbooks and
|
||||
Quorum Vaulting System (QVM) is an open source system of playbooks and
|
||||
tooling which facilitates the creation and maintenance of highly resilient
|
||||
[quorum](glossary.md#quorum)-based key management systems based on a strict
|
||||
[threat model](threat-model.md) which can be used for a variety of different
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Local Key Provisioning
|
||||
|
||||
This document contains instructions on how Operators collaborate to set up
|
||||
QVS which requires an N-of-M quorum to be reconstituted. The encrypted shards
|
||||
QKM which requires an N-of-M quorum to be reconstituted. The encrypted shards
|
||||
which result from this ceremony are stored in separate physical
|
||||
[Locations](locations.md) which contain [Location Keys](glossary.md#location-key)
|
||||
to which shards are encrypted, and whose passphrases are protected using
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
## Description
|
||||
This ceremony is for generating Location Keys. Location Keys are typically
|
||||
stored in vaults as prescribed in the [Secure Storage Guidelines](secure-storage-guidelines.md).
|
||||
Location Keys are keypairs to which the Root Entropy of a QVS is sharded. The
|
||||
Location Keys are keypairs to which the Root Entropy of a QKM is sharded. The
|
||||
keypairs are stored exclusively on Smart Cards, and the PINs which protect the
|
||||
Smart Cards are encrypted to Operator Keys.
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ would like for backing up [Public Ceremony Artifacts](public-ceremony-artifact-s
|
|||
established [Location](locations.md)
|
||||
|
||||
2. Boot your Ceremony Machine using [Secure Boot Sequence](secure-boot-sequence.md)
|
||||
or the [One Time Use Airgap-OS](TODO)
|
||||
or the [One Time Use Airgap-OS](one-time-use-airgapos.md)
|
||||
|
||||
3. Provision new key in the selected secure environment
|
||||
|
||||
|
|
@ -65,6 +65,8 @@ or the [One Time Use Airgap-OS](TODO)
|
|||
|
||||
* `keyfork mnemonic generate --size 256 | awk '{ print $1, $2, $3, $4, $5 }' > smart-card-pin.txt`
|
||||
|
||||
* `cat smart-card-pin.txt`
|
||||
|
||||
* `oct pin --card <smart_card_id> set-user`
|
||||
|
||||
* Enter the <smart_card_pin>
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ This level of defenses is focused on insider threats and as such requires a cons
|
|||
locations simultaneously
|
||||
|
||||
* SHOULD be facilities owned by different organizations to reduce the risk of
|
||||
collusion unless the organization who owns the QVS system has their own facility such
|
||||
collusion unless the organization who owns the QKM system has their own facility such
|
||||
as a [SCIF](glossary.md#secure-compartmentalized-information-facility-scif).
|
||||
|
||||
## Level 4 (SCIF)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,56 @@
|
|||
# Repository Setup
|
||||
|
||||
Before the one time ceremony, a git repository should be set up which contains
|
||||
several items which will be relevant to the ceremony. Namely the following:
|
||||
|
||||
* PGP public certificates of the Location Keys which will be used for the
|
||||
ceremony. The key ids of these certificates will be verified during the
|
||||
ceremony.
|
||||
|
||||
* `ceremony.sh` a script which imports the PGP public certificates of the
|
||||
location keys, and displays their ids so that Operators can verify that they are
|
||||
the correct ones. This script will also execute the appropriate `keyfork`
|
||||
command with a desired threshold:
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
read -p "Generate hardware interrupt entropy by typing randomly on keyboard" entropy
|
||||
|
||||
mount
|
||||
|
||||
read -p "Provide the path to PGP certificates which will be used for the ceremony: " absolute_path
|
||||
|
||||
if [ ! -d "$absolute_path" ]; then
|
||||
echo "Directory does not exist. Please enter a valid absolute path."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
for file in "$absolute_path"/keys/*; do
|
||||
if [ -f "$file" ]; then
|
||||
echo "Processing file: $file"
|
||||
gpg --import --import-options import-show $file
|
||||
fi
|
||||
done
|
||||
|
||||
read -p "Do the PGP key IDs match what you expect? (y/n): " matches_expectation
|
||||
|
||||
if [ "$matches_expectation" != "y" ]; then
|
||||
echo "Ceasing ceremony as PGP key IDs don't match"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
keyfork wizard bottoms-up --threshold 2 --output-cert "$absolute_path"/cert --output-shardfile "$absolute_path"/shardfile --user-id "QKM Ceremony" "$absolute_path"/keys
|
||||
```
|
||||
|
||||
* The `airgap.iso` which is to be used during the ceremony
|
||||
|
||||
* Each operator should produce Ceremony Notes which contain:
|
||||
|
||||
* `sha256sum` of `airgap.iso`
|
||||
|
||||
* The AirgapOS commit and date for the version that was used
|
||||
|
||||
* `sha256sum` of `ceremony.sh`
|
||||
|
||||
* Key ID of each PGP Public Certificate located in `public-certificates`
|
||||
in the ceremony repository
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Set up AirgapOS
|
||||
|
||||
Because without a Librem 14 there is no easy way to have a secure boot sequence,
|
||||
instead the AirgapOS `.iso` image is flashed to an SD card, locked using
|
||||
`sdtool` and then verified using any machine.
|
||||
|
||||
## Setup Steps
|
||||
|
||||
* Build the software according to the [readme](https://git.distrust.co/public/airgap) in the repository. Use the `make reproduce` command.
|
||||
|
||||
* Verify the software according to [this](verifying-signatures.md) guide
|
||||
|
||||
* Flash `airgap.iso` to an SD Card:
|
||||
|
||||
* `dd if=out/airgap.iso of=/dev/<your_device> bs=4M status=progress oflag=direct`
|
||||
|
||||
* Use the `sdtool` to lock the SD Card:
|
||||
|
||||
* TODO: update this to use stagex binary
|
||||
|
||||
* `git clone git@github.com:BertoldVdb/sdtool.git`
|
||||
|
||||
* `cd sdtool`
|
||||
|
||||
* `make`
|
||||
|
||||
* `./sdtool /dev/mmcblk permlock`
|
||||
|
||||
* Test that the card can't be written to:
|
||||
|
||||
* `dd if=out/airgap.iso of=/dev/sdb bs=1M conv=sync status=progress`
|
||||
|
||||
* Verify that the hash of `airgap.iso` matches what's flashed on the SD card:
|
||||
|
||||
* `head -c $(stat -c '%s' out/airgap.iso) /dev/sdb | sha256sum`
|
||||
|
||||
* `sha256sum out/airgap.iso`
|
||||
|
||||
* Commit the hash of airgap to a git repo, ensuring the commit is signed
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
# Selecting Locations
|
||||
|
||||
* MUST be selected at random right before the ceremony
|
||||
|
||||
* MUST have physical access control to prevent inflow and outflow of personnel during ceremony
|
||||
|
||||
* SHOULD NOT have electronics in it as they can be used for side channel attacks
|
||||
|
||||
* SHOULD NOT have windows to prevent exfiltration of data via light or observation of screen
|
||||
|
||||
## Location Examples
|
||||
|
||||
* A hotel room although it is relatively common to find spying devices in them so they are not a great choice
|
||||
|
||||
* A moving vehicle such as car, bus, train, ferris wheel given that the operator is able to secure a space which can be locked and has no strangers in it
|
||||
|
||||
* Open space with nobody around such as a forest, desert, large parking lot etc.
|
||||
|
||||
|
||||
Despite all these measures, the location may be compromised anyways, as a malicious actor may have done so with another target in mind, or a more broad campaign, for example in the case for three letter agencies may plant cameras and microphones in hotels for intel gathering. For this reason it is always highly preferred to perform cryptographic actions in a properly secured facility such as a SCIF.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Physical Artifact Storage
|
||||
|
||||
QVS requires that some of the hardware containing cryptographic material be
|
||||
QKM requires that some of the hardware containing cryptographic material be
|
||||
securely stored in physical locations. The two primary cases where physical
|
||||
storage is necessary are the storage of Location Key Smart Cards, and Operator
|
||||
Key Smart Cards. These Smart Cards are necessary to successfully execute a
|
||||
|
|
@ -0,0 +1,72 @@
|
|||
# Portable Reusable Laptop Ceremony
|
||||
|
||||
## Security Level
|
||||
|
||||
This process offers a Level 2 security mitigation, focusing on defending against remote adversaries and insider threats.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Roles
|
||||
|
||||
This setup does require the support of all [system roles](system-roles.md).
|
||||
|
||||
* MUST use at least 1 [Proposer](system-roles.md#proposer)
|
||||
|
||||
* MUST use at least 1 [Approver](system-roles.md#approver) different from Proposer
|
||||
|
||||
* MUST have at least 2 [Witnesses](system-roles.md#witness)
|
||||
|
||||
* MUST have at least 1 [Operator](system-roles.md#operator)
|
||||
|
||||
### Location
|
||||
|
||||
To conform to [Level 2](threat-model.md#level-2) security properties a location must be used according to the [Locations](locations.md) specification.
|
||||
|
||||
### Equipment
|
||||
|
||||
* Laptop procured according to [Hardware Procurement](hardware-procurement-and-chain-of-custody.md) guide
|
||||
|
||||
* Polaroid camera + pack of polaroid film
|
||||
- [] TODO update tamper rpoofing doc with polaroid camera models and film
|
||||
|
||||
* Digital camera
|
||||
- [ ] TODO add recommendations
|
||||
|
||||
* 10 SD cards
|
||||
- [ ] TODO add which
|
||||
|
||||
* [Vacuum sealer](tamper-evidence-methods.md#vacuum-sealers)
|
||||
|
||||
* [Vacuum sealer roll](tamper-evidence-methods.md#vacuum-sealers)
|
||||
|
||||
* Tamper evidence photographs:
|
||||
|
||||
* Printed digital photos
|
||||
|
||||
* Polaroid photos
|
||||
|
||||
## Procedure
|
||||
|
||||
1. The laptop and all hardware used SHOULD be kept on the person at all times
|
||||
|
||||
* MAY leave the laptop in a safe
|
||||
|
||||
* MAY (but not recommended) leave the laptop with full time supervision (such as bellhop)
|
||||
|
||||
2. Once in a secure location - control access to the location. It is highly preferred that no individuals enter or leave the facility during the ceremony.
|
||||
|
||||
3. Before starting the ceremony ensure that at least 1 Operator and 1 Witness are present
|
||||
|
||||
4. Verify that the request from the Proposer is properly approved by an Approver
|
||||
|
||||
### Unsealing
|
||||
{{ #include tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
### Perform Operations
|
||||
|
||||
Follow a [playbook](TODO)
|
||||
|
||||
|
||||
### Sealing
|
||||
{{ #include tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
# Redundant Storage of Ceremony Artifacts
|
||||
|
||||
Ceremony Artifacts consist of data which is not sensitive in nature, but
|
||||
essential to ongoing operation of a QVS.
|
||||
essential to ongoing operation of a QKM.
|
||||
|
||||
The primary artifacts which are produced during the ceremony are:
|
||||
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
# Quorum Team
|
||||
|
||||
The Quorum Team is a team of individuals who are selected to perform different
|
||||
roles related to a QVS. Some of the Quorum Team members have ongoing roles,
|
||||
roles related to a QKM. Some of the Quorum Team members have ongoing roles,
|
||||
while others may participate in a partial manner.
|
||||
|
||||
Depending on the type of actions performed, some or all of the members of the
|
||||
|
|
@ -28,7 +28,7 @@ Controllers may be used to protect access to physical locations - according to
|
|||
risk appetite.
|
||||
|
||||
## Witness
|
||||
Witnesses are individuals who are familiar with the QVS specification, and can
|
||||
Witnesses are individuals who are familiar with the QKM specification, and can
|
||||
ensure that the different aspects of the system are set up correctly, and
|
||||
processes carried out as they should be. The main objective of the witnesses is
|
||||
to monitor and attest that processes such as the ceremonies are done according
|
||||
|
|
|
|||
|
|
@ -0,0 +1,3 @@
|
|||
# Remote Key Provisioning
|
||||
|
||||
TODO
|
||||
|
|
@ -1,16 +1,13 @@
|
|||
/* ANCHOR: all */
|
||||
# PureBoot Hash Verifying .iso Setup
|
||||
|
||||
If the SD card with AirgapOS is stored as part of a tamper proofed bundle, then doing this secure boot sequence is only necessary the first time. Of course, it doesn't hurt to use this method as an additional precaution, reducing the risk that one of the operators can swap out the SD card for a different one during a ceremony.
|
||||
# AirgapOS Setup
|
||||
|
||||
This section can be completed on any machine.
|
||||
|
||||
AirgapOS has `keyfork` and `icepick` built into it for cryptographic operations such as key derivation and signing
|
||||
AirgapOS has `keyfork` and `icepick` built into it for cryptographic operations such as key
|
||||
derivation and signing
|
||||
|
||||
// ANCHOR: steps
|
||||
1. Build the software according to the [readme](https://git.distrust.co/public/airgap) in the repository.Use the `make reproduce` command.
|
||||
|
||||
2. Verify the software according to [this guide](./component-documents/verifying-signatures.md)
|
||||
2. Verify the software according to [this guide](verifying-signatures.md)
|
||||
|
||||
3. Place signed .iso on a storage device
|
||||
|
||||
|
|
@ -45,13 +42,10 @@ AirgapOS has `keyfork` and `icepick` built into it for cryptographic operations
|
|||
|
||||
5. Lock the SD card using `sdtool`
|
||||
|
||||
6. Make sure to note the `sha256sum` hash of the `airgap.iso` and write it
|
||||
5. Make sure to note the `sha256sum` hash of the `airgap.iso` and write it
|
||||
down on a piece of paper.
|
||||
|
||||
7. Multiple members of your team should build the `airgap.iso` image
|
||||
6. Multiple members of your team should build the `airgap.iso` image
|
||||
independently and use `sha256sum airgap.iso` in order to hash it, then record
|
||||
the value for later use. This value will be checked during Ceremonies before
|
||||
booting the ISO image to ensure it can be trusted.
|
||||
|
||||
// ANCHOR_END: steps
|
||||
/* ANCHOR_END: all */
|
||||
booting the ISO image to ensure it can be trusted.
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
# Root Entropy Ceremonies
|
||||
|
||||
There are 3 primary types of [Root Entropy](glossary.md#root-entropy-re)
|
||||
derivation ceremonies:
|
||||
|
||||
* **Local**: where all cryptographic material, including the Operator Keys,
|
||||
Location Keys, and the Root Entropy are all generated during a single in-person
|
||||
ceremony
|
||||
|
||||
* **Hybrid**: where the Operator Keys and Location Keys are generated separately
|
||||
prior to the in-person ceremony where the Root Entropy is generated
|
||||
|
||||
* **Remote**: where all cryptographic material is generated in a decentralized
|
||||
manner, remotely.
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# sdtool Usage Guide
|
||||
|
||||
[`sdtool`](https://github.com/BertoldVdb/sdtool) is a tool for locking the contents of a SD card by means of burning a physical fuse.
|
||||
|
||||
> It is relatively unknown that SD/MMC cards also have an electronic write protection system. Every card has two programmable flags, one for temporary write protection and one to lock the card forever. Writing these flags is not supported by most SD host devices. To remedy this, this page presents a program that allows a Linux host to configure the protection register.
|
||||
|
||||
This tool is also available via [stagex](https://registry.hub.docker.com/r/stagex/sdtool). The binary can be exported from the image by doing the following:
|
||||
|
||||
// ANCHOR: steps
|
||||
1. Get deterministically built binary of `sdtool` from StageX:
|
||||
* `docker pull stagex/sdtool`
|
||||
|
||||
1. Extracting binary:
|
||||
* Run docker container: `docker create -p 4000:80 --name sdtool stagex/sdtool`
|
||||
* Copy image to tar: `docker export <container_id> -o sdtool.tar`
|
||||
* Extract binary from tar: `mkdir -p sdtool-dir | tar -xvf sdtool.tar -C sdtool-dir | cp sdtool-dir/usr/bin/sdtool ./sdtool`
|
||||
* You can verify the container hash:
|
||||
* To get container hash: `docker inspect --format='{{json .RepoDigests}}' stagex/sdtool`
|
||||
* Check the [signatures dir](https://codeberg.org/stagex/stagex/src/branch/main/signatures/stagex) in stagex project for latest signed hashes
|
||||
|
||||
1. `./sdtool /dev/mmcblk permlock`
|
||||
|
||||
1. Test that the card can't be written to:
|
||||
|
||||
* `dd if=out/airgap.iso of=/dev/sdb bs=1M conv=sync status=progress`
|
||||
|
||||
// ANCHOR_END: steps
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Selecting a Quorum
|
||||
|
||||
The backbone of QVS is a Quorum which is used to reconstitute or re-assemble
|
||||
The backbone of QKM is a Quorum which is used to reconstitute or re-assemble
|
||||
cryptographic material, and approve actions. Quorum is a general term referring
|
||||
to a system which requires the collaboration of multiple individuals in order to
|
||||
achieve something, and it is based on a Threshold which determines how many
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
# Software
|
||||
This page outlines the software used for setting up QVS.
|
||||
This page outlines the software used for setting up QKM.
|
||||
|
||||
## [[Stageˣ]](https://codeberg.org/stagex/stagex)
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ BIP-0039 mnemonic phrase. BIP-0039 phrases are used to calculate a BIP-0032
|
|||
seed, which is used for hierarchical deterministic key derivation.
|
||||
|
||||
This software is the backbone for all cryptographic actions performed as part
|
||||
of QVS. It was developed by [Distrust](https://distrust.co) and is included
|
||||
of QKM. It was developed by [Distrust](https://distrust.co) and is included
|
||||
with AirgapOS and has been audited by two firms, NCC and Cure53 with no
|
||||
significant vulnerabilities found.
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ This is an administrative role which participates in the decision making capacit
|
|||
|
||||
## Operator
|
||||
|
||||
Trained on how the QVS system operates, with intimate knowledge of the processes which are required to maintain the integrity, confidentiality and availability (CIA triad) of the system.
|
||||
Trained on how the QVS(todo) system operates, with intimate knowledge of the processes which are required to maintain the integrity, confidentiality and availability (CIA triad) of the system.
|
||||
|
||||
Operators conduct ceremonies and ensure that the controls around QVS are in tact. They verify instructions from [Approvers](#approver) and perform different actions which are part of the QVS system, ranging across hardware procurement, accessing SCIFs, preparing field kits, performing ceremonies and more.
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ This level of threat actors has a more extensive range of attacks which may incl
|
|||
|
||||
* MUST combine [glitter on screws](#glitter-on-screws), [pureboot/heads](#pureboot--heads), and [vacuum sealing with filler](#vacuum-sealed-bags-with-filler)
|
||||
|
||||
* MUST maintain 2 person [chain of custody](./hardware-procurement-and-chain-of-custody.md)
|
||||
* MUST maintain 2 person [chain of custody](hardware-procurement-and-chain-of-custody.md)
|
||||
|
||||
#### Level 4
|
||||
|
||||
|
|
@ -72,10 +72,8 @@ The reason this method is effective is because unlike with many other methods th
|
|||
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.
|
||||
|
||||
Examples of filler:
|
||||
// ANCHOR:vsbwf-filler
|
||||
* [B100B5LB – 5 Lb Mixed Craft Bead Bonanza Case](https://www.thebeadery.com/product/b100b5lb-5-lb-mixed-craft-bead-bonanza-case/)
|
||||
* [Plastic Beads - Multi Color & Size - 700ml](https://www.stockade.ca/Plastic-Beads--Multi-Colour-Size--700ml_p_8402.html)
|
||||
// ANCHOR_END:vsbwf-filler
|
||||
|
||||
### Vacuum Sealers
|
||||
|
||||
|
|
@ -102,29 +100,25 @@ Sealing bags of standard size objects which need to be protected can fit in. The
|
|||
// ANCHOR: vsbwf-procedure
|
||||
|
||||
#### Requirements
|
||||
// ANCHOR: vsbwf-equipment
|
||||
|
||||
* [Vacuum sealer](tamper-evidence-methods.md#vacuum-sealers)
|
||||
|
||||
* [Vacuum plastic roll](tamper-evidence-methods.md#vacuum-sealers)
|
||||
|
||||
* [Filler](tamper-evidence-methods.md#adequate-filler)
|
||||
// ANCHOR_END: vsbwf-equipment
|
||||
|
||||
#### Sealing
|
||||
// ANCHOR: vsbwf-procedure-sealing
|
||||
|
||||
1. Insert object into plastic bag
|
||||
|
||||
1. Fill bag with enough plastic beads that all of the object is surrounded
|
||||
2. Fill bag with enough plastic beads that all of the object is surrounded
|
||||
|
||||
1. Use vacuum sealer to remove air from the bag until the beads are no longer able to move
|
||||
3. Use vacuum sealer to remove air from the bag until the beads are no longer able to move
|
||||
|
||||
1. Take photographs of both sides of the sealed object using both the digital and polaroid camera
|
||||
|
||||
1. Date and sign the polaroid photographs and store them in a local lock box
|
||||
|
||||
1. Take the SD card to an online connected device and commit the photographs to a repository, ensuring the commit is signed
|
||||
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 photographs to a repository, ensuring the commit is signed
|
||||
// ANCHOR_END: vsbwf-procedure-sealing
|
||||
|
||||
#### Unsealing
|
||||
|
|
@ -132,11 +126,11 @@ Sealing bags of standard size objects which need to be protected can fit in. The
|
|||
|
||||
1. Retrieve photographs of the top and the bottom of the object which were taken of the sealed object
|
||||
|
||||
1. Compare polaroid and printed photographs of digital record to the current state of the sealed object
|
||||
3. Compare polaroid and printed photographs of digital record to the current state of the sealed object
|
||||
|
||||
1. Compare polaroid to printed photographs of digital record
|
||||
4. Compare polaroid to printed photographs of digital record
|
||||
|
||||
1. If there is no noticeable difference, proceed with unsealing the object, otherwise initiate an [incident response process (todo)](TODO).
|
||||
2. If there is no noticeable difference, proceed with unsealing the object, otherwise initiate an [incident response process (todo)](TODO).
|
||||
|
||||
// ANCHOR_END: vsbwf-procedure-unsealing
|
||||
|
||||
|
|
@ -157,15 +151,15 @@ Glitter can be used as an additional control to provide tamper evidence on speci
|
|||
|
||||
1. Clean the surface the glitter will be applied to
|
||||
|
||||
1. Apply a thin layer of the first type of glitter
|
||||
2. Apply a thin layer of the first type of glitter
|
||||
|
||||
1. Wait for it to dry
|
||||
3. Wait for it to dry
|
||||
|
||||
1. Repeat steps 2, 3 with the different types of glitter being used
|
||||
4. Repeat steps 2, 3 with the different types of glitter being used
|
||||
|
||||
1. Take a photograph of the laptop, preferably using the [tamper proofing station](tamper-evidence-methods#tamper-proofing-station)
|
||||
5. Take a photograph of the laptop, preferably using the [tamper proofing station](tamper-evidence-methods#tamper-proofing-station)
|
||||
|
||||
1. Ensure the SD card is in dual custody until it's uploaded to a repository, and signed by both parties (one creates a PR, the other creates a signed merge using the `git` CLI)
|
||||
6. Ensure the SD card is in dual custody until it's uploaded to a repository, and signed by both parties (one creates a PR, the other creates a signed merge using the `git` CLI)
|
||||
|
||||
#### Verification
|
||||
|
||||
|
|
@ -193,33 +187,29 @@ To construct an appropriate Tamper Proofing Station, the simplest setup consists
|
|||
|
||||
* Powerful LED light which can be attached to the mounting rig
|
||||
|
||||
## Digital Camera
|
||||
*
|
||||
|
||||
* MUST have >10MP
|
||||
- [ ] TODO these cameras are specifically for level 2. this should be moved into a different section. perhaps each level can have its own hardware document
|
||||
- [ ] TODO amazon links are not ideal, more reliable and vetted hardware providers should be established
|
||||
### Models
|
||||
// ANCHOR:digital-cameras
|
||||
* Camera which does not have radio cards in it and
|
||||
|
||||
* Modern phone cameras
|
||||
* Has >10MP
|
||||
|
||||
* [Kodak PIXPRO Friendly Zoom FZ43-BK 16MP Digital Camera with 4X Optical Zoom and 2.7" LCD Screen](https://www.amazon.com/Kodak-Friendly-FZ43-BK-Digital-Optical/dp/B01CG62D00)
|
||||
|
||||
* [Kodak PIXPRO Friendly Zoom FZ43-BK 16MP Digital Camera with 4X Optical Zoom and 2.7" LCD Screen](https://www.amazon.com/KODAK-Friendly-FZ45-BK-Digital-Optical/dp/B0B8PDHRWY)
|
||||
* Uses SD cards for storing photographs
|
||||
|
||||
* [Sony Cyber-Shot DSC-W800](https://www.amazon.com/Sony-DSCW800-Digital-Camera-Black/dp/B00I8BIBCW)
|
||||
// ANCHOR_END:digital-cameras
|
||||
* Example models:
|
||||
|
||||
## Polaroid camera
|
||||
* Kodak PIXPRO Friendly Zoom FZ43-BK 16MP Digital Camera with 4X Optical Zoom and 2.7" LCD Screen
|
||||
|
||||
* Can be attached to mounting rig
|
||||
* Sony Cyber-Shot DSC-W800
|
||||
|
||||
### Models
|
||||
// ANCHOR: polaroid-cameras
|
||||
* [Polaroid Now+](https://www.amazon.com/Polaroid-Generation-Bluetooth-Connected-Controlled/dp/B0BVNJHMVQ)
|
||||
* Polaroid camera which can be attached to the mounting rig
|
||||
|
||||
* Preferred film: [Color I-Type Film](https://www.amazon.com/Polaroid-Originals-Instant-Color-I-Type/dp/B084GXXLM7)
|
||||
// ANCHOR_END: polaroid-cameras
|
||||
* Example models:
|
||||
|
||||
* Polaroid Now+
|
||||
|
||||
* Polaroid I-2
|
||||
|
||||
* Preferred film: Color I-Type Film
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -70,12 +70,6 @@ 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.
|
||||
|
||||
* [Level 1](#level-1)
|
||||
* [Level 2](#level-2)
|
||||
* [Level 3](#level-3)
|
||||
* [Level 4](#level-4)
|
||||
|
||||
|
||||
## Level 1
|
||||
|
||||
### Threat Model
|
||||
|
|
@ -248,7 +242,7 @@ This level focuses on defending against insider threats.
|
|||
|
||||
* 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](./component-documents/hardware-procurement-and-chain-of-custody.md) since procurement
|
||||
* 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)
|
||||
|
||||
|
|
@ -370,6 +364,7 @@ This level focuses on defending against adversaries who are nation states.
|
|||
* 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
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue