Compare commits
3 Commits
main
...
coding-sta
| Author | SHA1 | Date |
|---|---|---|
 Lance Vick
|
2b47b7c703
|
|
|
Lance Vick
|
a02a1c8db6
|
|
|
Lance Vick
|
a70fdaed9f
|
|
|
@ -10,8 +10,8 @@ indent_style = tab
|
|||
indent_size = 2
|
||||
|
||||
[*.md]
|
||||
indent_style = tab
|
||||
indent_size = 4
|
||||
indent_style = space
|
||||
indent_size = 2
|
||||
|
||||
[*]
|
||||
end_of_line = lf
|
||||
|
|
|
|||
|
|
@ -2,12 +2,12 @@
|
|||
|
||||
FROM scratch AS base
|
||||
|
||||
COPY quorum-vault-system /quorum-vault-system
|
||||
COPY quorum-key-management /quorum-key-management
|
||||
|
||||
FROM base AS build
|
||||
COPY --from=stagex/mdbook . /
|
||||
|
||||
WORKDIR /quorum-vault-system
|
||||
WORKDIR /quorum-key-management
|
||||
RUN ["/usr/bin/mdbook", "build"]
|
||||
|
||||
FROM stagex/filesystem AS install
|
||||
|
|
@ -17,7 +17,7 @@ COPY --from=stagex/musl . /
|
|||
COPY --from=stagex/zlib . /
|
||||
|
||||
ADD index.html /var/www/html/
|
||||
COPY --from=build /quorum-vault-system/book /var/www/html
|
||||
COPY --from=build /quorum-key-management/book /var/www/html/qkm
|
||||
|
||||
WORKDIR /var/www/html
|
||||
|
||||
24
Makefile
24
Makefile
|
|
@ -1,24 +1,22 @@
|
|||
PORT := 8080
|
||||
.PHONY: default
|
||||
default: build-qvs
|
||||
default: build
|
||||
|
||||
out:
|
||||
mkdir -p out
|
||||
|
||||
.PHONY: build-qvs
|
||||
build-qvs: out/qvs/index.json
|
||||
out/qvs/index.json: out Containerfile.qvs $(shell find quorum-vault-system -type f)
|
||||
mkdir -p out/qvs
|
||||
.PHONY: build
|
||||
build: out/index.json
|
||||
out/index.json: out Containerfile
|
||||
docker \
|
||||
build \
|
||||
-f Containerfile.qvs \
|
||||
--output type=oci,rewrite-timestamp=true,force-compression=true,name=git.distrust.co/public/docs-qvs,tar=true,dest=- \
|
||||
-f Containerfile \
|
||||
--output type=oci,rewrite-timestamp=true,force-compression=true,name=distrust/docs,tar=true,dest=- \
|
||||
. \
|
||||
| tar -C out/qvs -mx
|
||||
| tar -C out/ -mx
|
||||
|
||||
.PHONY: serve-qvs
|
||||
serve-qvs: build-qvs
|
||||
tar -C out/qvs -cf - . | docker load
|
||||
docker run -p $(PORT):8080 git.distrust.co/public/docs-qvs
|
||||
.PHONY: serve
|
||||
serve: build
|
||||
tar -C out/ -cf - . | docker load
|
||||
docker run -p $(PORT):8080 distrust/docs
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,192 @@
|
|||
# Engineering Standards
|
||||
|
||||
These are our opinionated engineering standards we use internally at Distrust,
|
||||
and expect from all contractors and vendors.
|
||||
|
||||
## Summary
|
||||
|
||||
This process is recommended for any binaries, that if compromised, could result
|
||||
in a loss of funds exceeding $1,000,000, which is the rough level where
|
||||
incidents of violent coercion or deployments of expensive ($200k+ per Zerodium)
|
||||
"zero-day" exploits have been seen in our industry.
|
||||
|
||||
It is reasonable to expect any privileged general-purpose OS kernels, tools,
|
||||
or binaries may, in some use cases, have access to memory that holds a high value
|
||||
secrets. This makes such binaries and those that maintain them significant
|
||||
targets for supply chain attacks by malicious adversaries, be it covert via a
|
||||
0day of overt via violence.
|
||||
|
||||
It is also reasonable to expect that a binary that runs on multiple engineer
|
||||
workstations could have the power to deploy to production.
|
||||
|
||||
This document seeks to largely mitigate all classes of supply chain attacks we
|
||||
have seen deployed in the wild with high accountability build and release
|
||||
processes and maintain a high standard of code quality and security.
|
||||
|
||||
## Motivation
|
||||
|
||||
80% of software bugs are memory safety issues, which speaks to poor coding
|
||||
standards, and failure to use memory safe languages where possible.
|
||||
|
||||
Also adversaries are demonstrating an increased willingness to resort to
|
||||
supply chain attacks to gain value from software systems.
|
||||
|
||||
Examples:
|
||||
* [CI/CD system compromised by covert and sophisticated rootkit](https://igor-blue.github.io/2021/03/24/apt1.html)
|
||||
* [NPM supply chain attack on CoPay wallets](https://medium.com/@hkparker/analysis-of-a-supply-chain-attack-2bd8fa8286ac)
|
||||
* [Web analytics supply chain attack deployed on Gate.io exchange](https://www.welivesecurity.com/2018/11/06/supply-chain-attack-cryptocurrency-exchange-gate-io/)
|
||||
* [0day in Firefox used to attack Coinbase](https://www.zdnet.com/article/firefox-zero-day-was-used-in-attack-against-coinbase-employees-not-its-users/)
|
||||
* [Ruby Gem Supply chain attack to facilitate cryptoasset theft via clipboards](https://www.bleepingcomputer.com/news/security/malicious-rubygems-packages-used-in-cryptocurrency-supply-chain-attack/)
|
||||
|
||||
Worse even than this, when such vectors are not readily viable, some are even
|
||||
willing to resort to physical violence just to get a signature from a
|
||||
the private key that can directly or indirectly control significant value.
|
||||
|
||||
Examples:
|
||||
* [Physical Bitcoin Attacks](https://github.com/jlopp/physical-bitcoin-attacks/blob/master/README.md)
|
||||
* [Violent datacenter robbery with hostages](https://www.computerworld.com/article/2538534/data-center-robbery-leads-to-new-thinking-on-security.html)
|
||||
* [History of datacenter break-ins](https://www.hostdime.com/blog/server-room-security-colocation/)
|
||||
|
||||
Given this, we should expect that humans in control of any single point of
|
||||
failure in a software ecosystem that controls a significant amount of
|
||||
value are placing themselves at substantial personal risk.
|
||||
|
||||
To address this, we must avoid trusting any single human or any system they
|
||||
control by design in order to protect those individuals and downstream users.
|
||||
|
||||
## Threat Model
|
||||
|
||||
* Every human will make coding mistakes
|
||||
* Any single human or computer involved in the supply chain is compromised
|
||||
* All systems managed by a single party (IT, third parties) are compromised
|
||||
* Any code or binaries controlled by one system or party are compromised
|
||||
* All memory of all internet-connected computers is visible to an adversary
|
||||
* Any logging or backups that are not signed are tampered with
|
||||
* Adversary wields a "zero-click" "Zero-Day" exploit for any system
|
||||
|
||||
## Requirements
|
||||
|
||||
The following only applies if code is bound for production, and these can be
|
||||
met in any order or cadence desired.
|
||||
|
||||
* Third-party code:
|
||||
* MUST have extensive and frequent reviews.
|
||||
* Example: The Linux kernel has well funded distributed review.
|
||||
* MUST be hash-pinned at known reviewed versions
|
||||
* MUST be at version with all known related security patches
|
||||
* SHOULD be latest versions if security disclosures lag behind releases
|
||||
* Example: The Linux kernel
|
||||
* First-party code:
|
||||
* MUST be signed in version control systems by well-known author keys
|
||||
* MUST be signed by a separate subject matter expert after a security review
|
||||
* All code MUST build deterministically
|
||||
* All binaries:
|
||||
* MUST be built and signed by multiple parties with no management overlay
|
||||
* Example: One build by IT, another by Infrastructure team managed CI/CD
|
||||
* MUST be signed by well-known keys signed by a common CA
|
||||
* Example: PGP Smartcards signed under OpenPGP-CA.
|
||||
* All signing keys:
|
||||
* MUST be stored in approved PERSONAL HSMs
|
||||
* MUST NOT ever come in contact with network-accessible memory
|
||||
* All execution environments SHOULD be able to verify m-of-n binary signatures
|
||||
* Example: Custom Secure Boot verifies minimum signatures against CA
|
||||
* Only code required for sensitive operation SHOULD be present
|
||||
* Example: A server has no need for sound card drivers
|
||||
|
||||
|
||||
## Workflows
|
||||
|
||||
## Design
|
||||
|
||||
Many implementations are possible under the above requirements and threat model
|
||||
however, the following opinionated workflows can be used as a reference when in
|
||||
doubt.
|
||||
|
||||
### Engineer Workflow
|
||||
|
||||
Will vary significantly by project, but at a minimum:
|
||||
|
||||
1. Engineer makes source code change
|
||||
2. Engineer builds and tests changes locally
|
||||
3. Engineer makes commit signed with PERSONAL HSM and pushes
|
||||
4. Submits code for peer review if multiple engineers are active in codebase
|
||||
|
||||
### Continuous Integration
|
||||
|
||||
This is ideal, though not always present for all projects.
|
||||
|
||||
1. Pulls code
|
||||
2. Verifies commit signature by key signed with hardcoded CA key
|
||||
3. Builds binaries
|
||||
4. Verifies binary hashes match hashes in signed commit
|
||||
5. Runs test suite
|
||||
6. Signs binary with a well-known key (ideally held in HSM)
|
||||
7. Publishes binary and signature to artifact storage
|
||||
8. Continuous Integration notifies project team of success/error of above steps
|
||||
|
||||
### Security Reviewer
|
||||
|
||||
1. Reviews all code changes between release candidate and last commit
|
||||
2. Reviews all third-party changes and evidence they are appropriate
|
||||
3. Appends tag signed with PERSONAL HSM to release candidate commit reviewed
|
||||
|
||||
### Release Engineer
|
||||
|
||||
1. Release engineer verifies:
|
||||
* Commit signature and security reviewer signature on commit are valid
|
||||
* The artifact corresponding to this commit is signed by the CI key
|
||||
* The artifact hash is in the release candidate commit
|
||||
2. Release engineer generates detached artifact signature with PERSONAL HSM
|
||||
3. Release engineer publishes detached signature to artifact store
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Boilerplate
|
||||
|
||||
All projects should have:
|
||||
- A README.md containing goals, requirements, and build/usage instructions
|
||||
- A Makefile configured such that 'make' will build the project
|
||||
- A Stagex Containerfile responsible for the building project deterministically
|
||||
|
||||
### Dependency Choices
|
||||
|
||||
Use the following rationale guidelines to help decide when and how to use third party dependencies
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Can it be done with the standard Library in under ~10k easily readable lines?]
|
||||
A --> D{No} --> E
|
||||
A --> B{Yes} --> C
|
||||
|
||||
E[Can it be done with a library used in the official interpreter or compiler?]
|
||||
E --> F{Yes} --> X
|
||||
E --> G{No} --> I
|
||||
|
||||
I[Does a widely used, well vetted, well reviewed, and well maintained library with exist?]
|
||||
I --> J{Yes} --> X
|
||||
I --> K{No} --> L
|
||||
|
||||
L[Is this a cryptography or security sensitive use case?]
|
||||
L --> M{No} --> O
|
||||
L --> N{Yes} --> P[Review by yourself and pay for reputable external security audit] --> X
|
||||
|
||||
O[Does -any- suitible library exist small enough for you to review yourself?]
|
||||
O --> Q{No} --> C
|
||||
O --> R{Yes} --> S[Review by yourself and by a peer] --> X
|
||||
|
||||
C[Write it yourself]
|
||||
|
||||
X[Document rationale and use library at specific version we have reason to trust]
|
||||
```
|
||||
|
||||
## Language Guidelines
|
||||
|
||||
### Rust
|
||||
|
||||
TBD
|
||||
|
||||
## Glossary
|
||||
|
||||
### MUST, MUST NOT, SHOULD, SHOULD NOT, MAY
|
||||
|
||||
These keywords correspond to their IETF definitions per RFC2119
|
||||
|
|
@ -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.
|
||||
|
|
@ -3,4 +3,4 @@ authors = ["Anton Livaja", "Lance R. Vick", "Ryan Heywood"]
|
|||
language = "en"
|
||||
multilingual = false
|
||||
src = "src"
|
||||
title = "Quorum Vault System (QVS)"
|
||||
title = "Quorum Key Management (QKM)"
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
# Summary
|
||||
* [Introduction](intro.md)
|
||||
* [Threat Model](threat-model.md)
|
||||
* [Selecting a Quorum](selecting-quorum.md)
|
||||
* [Software](software.md)
|
||||
* [Hardware](hardware.md)
|
||||
* [Glossary](glossary.md)
|
||||
|
||||
* [Preparations]()
|
||||
* [Repeat Use]()
|
||||
* [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)
|
||||
* [AirgapOS Setup](repeat-use-airgapos.md)
|
||||
* [`autorun.sh` Setup](autorun-sh-setup.md)
|
||||
* [Secure Boot Sequence](secure-boot-sequence.md)
|
||||
* [Selecting Locations](locations.md)
|
||||
|
||||
* [One Time Use]()
|
||||
* [Procure Hardware](one-time-use-hardware-procurement.md)
|
||||
* [AirgapOS Setup](one-time-use-airgapos.md)
|
||||
* [Repository Setup](one-time-repository-setup.md)
|
||||
* [Selecting Locations](one-time-use-locations.md)
|
||||
|
||||
* [Key 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)
|
||||
|
||||
* [Lifecycle Management]()
|
||||
* [Destroying Hardware](hardware-destruction.md)
|
||||
* [Storage Device Management](storage-device-management.md)
|
||||
|
|
@ -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.
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
4. Flash ISO Image to a Storage Device
|
||||
|
||||
a. Select a new Storage Device which can be overwritten entirely
|
||||
|
||||
b. Find the name of the Storage Device using [this guide](storage-device-management.md#finding-a-storage-device-name)
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
Once this step is complete, you have successfully set up a Storage Device
|
||||
with AirgapOS.
|
||||
|
|
@ -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
|
||||
|
||||
|
|
@ -60,12 +60,6 @@ which is set at the time of initial sharding, expressed as M of N, or in other
|
|||
words M shards of the total N shards in existence are required to reveal the
|
||||
secret.
|
||||
|
||||
## Secure Compartmentalized Information Facility (SCIF)
|
||||
|
||||
## [RFC2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC8174](https://www.rfc-editor.org/rfc/rfc8174)
|
||||
|
||||
Specifications for keywords such as MUST, MUST NOT, SHOULD, SHOULD NOT, MAY etc.
|
||||
|
||||
## Workstation
|
||||
|
||||
Highly secure computer which is used for sensitive operations, typically in the
|
||||
|
|
@ -116,7 +110,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
|
||||
|
|
@ -139,6 +133,3 @@ importantly the Root Entropy was never exposed.
|
|||
* [Version Control Systems](software.md#version-control-system-vcs):
|
||||
* We tolerate a loss of all but one DR storage backend
|
||||
* A minimum of three storage backends should be maintained
|
||||
|
||||
## MICE
|
||||
A mnemonic device used in counterintelligence training to remind trainees of the four general motivations that could lead someone to commit treason, become an insider threat, or collaborate with a hostile agency or organization. It stands for Money, Ideology, Compromise, and Ego.
|
||||
|
|
@ -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,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.
|
||||
|
Before Width: | Height: | Size: 85 KiB After Width: | Height: | Size: 85 KiB |
|
|
@ -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,19 +1,19 @@
|
|||
# Introduction
|
||||
|
||||
Quorum Vaulting System (QVS) is an open source system of playbooks and
|
||||
Quorum Key Management (QKM) 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
|
||||
cryptographic algorithms. The system was designed and developed by
|
||||
[Distrust](https://distrust.co), with the generous support of sponsors.
|
||||
[Distrust](https://distrust.co), with the generous support of the following
|
||||
sponsors: TODO.
|
||||
|
||||
The basic premise of QVS is that primary cryptographic material akin to a root
|
||||
The basic premise of QKM is that primary cryptographic material akin to a root
|
||||
certificate, called [Root Entropy (RE)](glossary.md#root-entropy-re), is generated
|
||||
during a secure key derivation ceremony, and then used to derive chosen
|
||||
cryptographic material via different algorithms such as PGP keys, digital asset
|
||||
wallets, web certificates and more.
|
||||
|
||||
Currently there is a set of an opinionated set of playbooks for working with OpenPGP and blockchains is in development, and will be extended to digital certificates, FIDO secrets and more in the future.
|
||||
wallets, web certificates and more. The system was designed with extensibility
|
||||
in mind.
|
||||
|
||||
The RE is sharded using [Shamir's Secret Sharing (SSS)](glossary.md#shamirs-secret-sharing-sss)
|
||||
to a [Quorum](glossary.md#quorum) in order to protect it from single points of
|
||||
|
|
@ -23,7 +23,7 @@ access controls in order to reconstruct the secret material, namely the RE.
|
|||
|
||||
## Use Cases
|
||||
|
||||
QVS can be used for a wide range of use-cases which span but are not limited
|
||||
QKM can be used for a wide range of use-cases which span but are not limited
|
||||
to:
|
||||
|
||||
* Deriving a PGP key pair whose public key can be used as a "one-way deposit
|
||||
|
|
@ -42,8 +42,8 @@ a cold signing setup.
|
|||
|
||||
## Playbooks
|
||||
|
||||
QVS can be set up by using a set of highly opinionated playbooks which outline
|
||||
the process. The base documentation should be read in its entirety by all
|
||||
QKM can be set up by using a set of highly opinionated playbooks which outline
|
||||
the process. The documentation should be read in its entirety by all
|
||||
participants of the ceremony in order to ensure that the system is well
|
||||
understood by all to ensure that the integrity of the process is preserved and
|
||||
enforced.
|
||||
|
|
@ -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>
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
# Locations
|
||||
# Location
|
||||
|
||||
Locations refer to physical points in space which are used for storing
|
||||
cryptographic material or performing actions using the cryptographic material and
|
||||
cryptographic material or performing actions related to the DRK lifecycle and
|
||||
adhere to a set of criteria which focus on achieving a high level of security -
|
||||
specifically with respect to:
|
||||
|
||||
|
|
@ -20,39 +20,11 @@ storage of cryptographic material such as Smart Cards which are used to decrypt
|
|||
[Shards](glossary.md#shard), referred to as a Storage Location, and a location
|
||||
for Ceremonies, known as the Ceremony Location.
|
||||
|
||||
## Level 1
|
||||
The Storage Location has a shorter list of requirements while the Management
|
||||
and Ceremony locations have a number of additional requirements. The Management
|
||||
and Ceremony Location may be one and the same.
|
||||
|
||||
This level of defenses is largely focused on remote attacks, and as such does not have strict requirements about the location.
|
||||
|
||||
### Examples
|
||||
|
||||
* Personal domicile
|
||||
|
||||
* Co-working space
|
||||
|
||||
* Regular office (non specific to QVS)
|
||||
|
||||
### Reference Design
|
||||
|
||||
* SHOULD have ability to control physical access to room
|
||||
|
||||
* SHOULD be a space that's randomly selected to minimize the likelihood of an adversary deploying equipment into the location before it's used
|
||||
|
||||
## Level 2
|
||||
|
||||
This level of defenses is focused on insider threats and as such requires a considerably higher standard as it needs to mitigate threats which stem from individuals who have privileged access.
|
||||
|
||||
### Examples
|
||||
|
||||
* Purpose specific facility for QVS
|
||||
|
||||
* Short term rental
|
||||
|
||||
* Hotel room
|
||||
|
||||
* Moving vehicle
|
||||
|
||||
### Reference Design
|
||||
## All Locations
|
||||
|
||||
* MUST have physical access restrictions which require identification
|
||||
|
||||
|
|
@ -66,9 +38,21 @@ This level of defenses is focused on insider threats and as such requires a cons
|
|||
|
||||
* SHOULD have anti-flood systems
|
||||
|
||||
* SHOULD be in facilities controlled by organizations which are ideally immune to being legally subpoenaed
|
||||
|
||||
## Level 3
|
||||
## Management & Ceremony Locations
|
||||
|
||||
* MUST not have cameras installed
|
||||
|
||||
* MUST not have windows with direct line of sight to monitors
|
||||
|
||||
* MUST have all walls protected with EM shielding which adheres to the TEMPEST
|
||||
standard NATO SDIP-27 Level A
|
||||
|
||||
* SHOULD be organizations which are ideally immune to being legally subpoenaed
|
||||
|
||||
* SHOULD NOT be susceptible to being subpoenaed
|
||||
|
||||
## Storage Location
|
||||
|
||||
* MUST have anti-fire systems
|
||||
|
||||
|
|
@ -82,16 +66,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
|
||||
as a [SCIF](glossary.md#secure-compartmentalized-information-facility-scif).
|
||||
collusion unless the organization who owns the DRK has their own facility such
|
||||
as a SCIF (Secure Compartmentalized Information Facility)
|
||||
|
||||
## Level 4 (SCIF)
|
||||
|
||||
* MUST not have cameras installed inside of the room
|
||||
|
||||
* MUST not have windows with direct line of sight to monitors
|
||||
|
||||
* MUST have all walls protected with EM shielding which adheres to the TEMPEST
|
||||
standard NATO SDIP-27 Level A
|
||||
|
||||
* SHOULD have seismic detectors
|
||||
* SHOULD have seismic detectors
|
||||
|
|
@ -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,43 @@
|
|||
# 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
|
||||
|
||||
* Clone the latest AirgapOS version:
|
||||
|
||||
* `git clone git@distrust.co:public/airgap.git`
|
||||
|
||||
* Build the image:
|
||||
|
||||
* `cd airgap && make`
|
||||
|
||||
* Verify `sha256sum` of airgap matches hashes in `/dist`
|
||||
|
||||
* Verify signatures on the hashes in `/dist`. The maintainer pgp keys can be found on the [Distrust contact page](https://distrust.co/contact.html) page.
|
||||
|
||||
|
||||
* 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:
|
||||
|
||||
* `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`
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
# Procure Hardware
|
||||
|
||||
* Procure a laptop, and SD cards from a randomly selected store. A randomly
|
||||
selected store is used in order to reduce the possibility of a malicious actor
|
||||
having time to plant compromised hardware at the store, and/or make arrangements
|
||||
by coercing store staff to sell compromised hardware to the quroum team. Of
|
||||
course, there still may be hardware that's compromised being sold, but is less
|
||||
likely to specifically target the quorum group.
|
||||
|
||||
* Ensure at least 2 people are in line of sight of access to all of the
|
||||
equipment, for example a bag carried in hand, until the ceremony is executed.
|
||||
This is done in order to eliminate the possibility of the equipment being
|
||||
swapped for compromised hardware.
|
||||
|
||||
* The laptop should ideally support booting from an SD card and have a built in
|
||||
micro or standard SD card reader; if this is not possible, USB SD card reader
|
||||
should be purchased.
|
||||
|
||||
* Dell laptops tend to have support for booting from SD cards so they are a
|
||||
good option.
|
||||
|
||||
* The store and laptop model should be selected on the spot via consensus of at
|
||||
least 2 members of the Quorum. This is done for several reasons:
|
||||
|
||||
* To ensure that no time is given to a malicious actor to deploy
|
||||
compromised hardware to the store
|
||||
|
||||
* To reduce likelihood that arrangements can be made by a malicious actor
|
||||
for the store to sell compromised hardware to the Quorum team
|
||||
|
||||
* Note that a secondary computer, or secondary SD card with bootable OS will be
|
||||
required in order to be able to verify the flashed AirgapOS SD card right before
|
||||
the ceremony.
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
# Selecting Locations
|
||||
|
||||
Secure a randomly selected location that has a private space with EM shielding,
|
||||
or no electronics in at least a 10 m radius. A moving vehicle (eg. car, bus,
|
||||
train, ferris wheel) is also a viable alternative. Additionally, the ceremony
|
||||
may be conducted in an open outdoor space, such as a forest, or a desert, at a
|
||||
location that is an open space not near any objects and ideally on a hard surface
|
||||
such as rock to prevent hidden devices in the ground. The point of narrowing the
|
||||
location selection to these spaces is that it makes it hard for a malicious
|
||||
actor to prepare for the ceremony and deploy equipment for side-channel attacks
|
||||
- with the intent of stealing the cryptographic material which is produced or
|
||||
managed during key ceremonies.
|
||||
|
||||
The location should be selected immediately before the ceremony in order to
|
||||
eliminate the possibility of a malicious actor having time to infiltrate and
|
||||
compromise the space ahead of the ceremony. 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.
|
||||
|
|
@ -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
|
||||
|
|
@ -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,26 @@
|
|||
/* ANCHOR: all */
|
||||
# PureBoot Hash Verifying .iso Setup
|
||||
|
||||
If the SD card with AirgapOS is stored as part of a Air-Gapped 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` built into it for cryptographic operations such as key
|
||||
derivation.
|
||||
|
||||
// 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. Clone the `AirgapOS` repository locally or download it as a zip
|
||||
|
||||
2. Verify the software according to [this guide](./component-documents/verifying-signatures.md)
|
||||
To clone use the following command in the terminal:
|
||||
```
|
||||
cd ~
|
||||
git clone git@distrust.co:public/airgap.git
|
||||
```
|
||||
|
||||
To download as a ZIP from https://git.distrust.co/public/airgap:
|
||||
|
||||
|
||||
2. Navigate into the `airgap` repository locally, and build the iso image.
|
||||
```
|
||||
cd ~/airgap
|
||||
make reproduce
|
||||
```
|
||||
The resulting iso will be located in `airgap/out/`
|
||||
|
||||
3. Place signed .iso on a storage device
|
||||
|
||||
|
|
@ -33,7 +43,6 @@ AirgapOS has `keyfork` and `icepick` built into it for cryptographic operations
|
|||
```
|
||||
|
||||
4. Copy `airgap.iso` and detached signature to a storage device
|
||||
|
||||
a. Select a new Storage Device which has no other files on it and plug it
|
||||
into the machine that has the `airgap.iso` file and the detached GPG signature.
|
||||
|
||||
|
|
@ -43,15 +52,10 @@ AirgapOS has `keyfork` and `icepick` built into it for cryptographic operations
|
|||
|
||||
e. Copy both the `airgap.iso` and detached signature to the drive.
|
||||
|
||||
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,7 +1,5 @@
|
|||
/* ANCHOR: all */
|
||||
# Secure Boot Sequence
|
||||
|
||||
// ANCHOR: content
|
||||
Steps 1-12 can be skipped if the media drive with `airgap` has been verified in
|
||||
advance.
|
||||
|
||||
|
|
@ -30,7 +28,7 @@ binary they built on their own system according to the [AirgapOS Setup Playbook]
|
|||
|
||||
12. Once everyone is satisfied that the hash matches, the computer should be
|
||||
be restarted.
|
||||
// ANCHOR: prepared
|
||||
|
||||
13. Press space when the message "Automatic boot in 5 seconds unless interrupted by keypress..."
|
||||
|
||||
14. Once in the PureBoot Boot Menu, navigate to "Options -->" and press Enter
|
||||
|
|
@ -42,8 +40,4 @@ be restarted.
|
|||
17. Ensure that `/media/airgap.iso` is selected and press Enter
|
||||
|
||||
18. Once booted, verify the version of the software matches the AirgapOS Hash
|
||||
which was noted during the [AirgapOS Setup](repeat-use-airgapos.md).
|
||||
// ANCHOR_END: prepared
|
||||
// ANCHOR_END: content
|
||||
|
||||
/* ANCHOR_END: all */
|
||||
which was noted during the [AirgapOS Setup](repeat-use-airgapos.md).
|
||||
|
|
@ -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,11 +39,6 @@ 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.
|
||||
|
||||
|
||||
## [Icepick](https://git.distrust.co/public/icepick)
|
||||
|
||||
Icepick is a framework for rapidly developing applications to perform transfer and staking cryptocurrency operations. It works synergistically with `keyfork` which derives keys which are then used by `icepick`.
|
||||
|
|
@ -9,7 +9,8 @@ USB devices are assigned names when they are connected to a Linux operating
|
|||
system. The first storage device is assigned the name `sda` (storage device a),
|
||||
the second `sdb`, the third `sdc` and so on.
|
||||
|
||||
One may use the `lsblk` to list the detected storage devices for a system, which will output something like this:
|
||||
One may use the `lsblk` to list the detected storage devices for a system, which
|
||||
will output something like this:
|
||||
```
|
||||
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
|
||||
xvda 202:0 1 50G 0 disk
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
# Threat Model
|
||||
|
||||
QKM is designed according to a high-assurance threat model which ers on the
|
||||
side of making exaggerated, rather than conservative assumptions in order to
|
||||
build a resilient system.
|
||||
|
||||
The assumption is made that attackers who target QKM are extremely
|
||||
sophisticated, well funded and patient attackers, and as such, the full arsenal
|
||||
of attacks is on the table. This means that the attacker can purchase and
|
||||
weaponize multiple 0day vulnerabilities, execute physical attacks or deploy
|
||||
moles, target different supply chains of software, firmware and hardware used,
|
||||
and generally attack the system using an array of known and unknown attacks.
|
||||
|
||||
One of the guiding principles in the design is the elimination of Single Points
|
||||
of Failure (SPOFs), and relies on a number of different control mechanisms which
|
||||
help reduce risk of any one individual being able to compromise the system,
|
||||
whether it's maintainers of software used in the system, the firmware that's
|
||||
used, or the individuals or locations that hold secret material which is the
|
||||
backbone of the system.
|
||||
|
||||
To achieve this, the QKM focuses on reducing the risk by:
|
||||
|
||||
* Only using fully open source software and firmware to allow full verification
|
||||
of their security properties
|
||||
|
||||
* Creating custom purpose specific tooling which eliminates dependencies in
|
||||
order to reduce supply chain attacks, and adds desirable security properties
|
||||
|
||||
* Using a fully bootstrapped and deterministically built compiler for building
|
||||
all software that's used
|
||||
|
||||
* Building all of the software and firmware deterministically
|
||||
|
||||
* Using computers which either have a hard switch for disabling networking or
|
||||
which had radio networking cards (bluetooth, wifi etc.) removed
|
||||
|
||||
* Leveraging smart cards (personal HSMs) to protect cryptographic material
|
||||
|
||||
* Leveraging sharding in order to physically separate cryptographic material
|
||||
|
||||
* Leveraging tamper evident controls for components related to the system
|
||||
|
||||
## General Threat Model Assumptions
|
||||
|
||||
Some additional assumptions are made to help contextualize the threat model:
|
||||
|
||||
* All screens are visible to an adversary
|
||||
|
||||
* All keyboards are logging to an adversary
|
||||
|
||||
* Any firmware/boot-loaders not verified on every boot are compromised
|
||||
|
||||
* Any host OS with network access is compromised
|
||||
|
||||
* Any guest OS used for any purpose other than prod access is compromised
|
||||
|
||||
* At least one member of the Production Team is always compromised
|
||||
|
||||
* At least one maintainer of third party used in the system is compromised
|
||||
|
||||
* Physical attacks are viable and likely
|
||||
|
||||
|
||||
## Additional Threat Model Notes
|
||||
|
||||
### Smart Cards
|
||||
|
||||
The Operator Smart Card uses the default PIN because it is meant to be something
|
||||
a user "has", rather than "knows". On the other hand, the Location Smart Card
|
||||
is protected by a complex PIN, which can only be decrypted using the PGP keys
|
||||
stored on the Operator Smart Card. This is done in order to protect the access
|
||||
to the Location key by anyone except the Operator, but also to allow for adding
|
||||
controls which require more than one individual to access a Location Smart Card.
|
||||
In this way, there is an additional "quorum" which needs to be achieved to
|
||||
access the Location key - more on this in the [Location](locations.md) section.
|
||||
|
||||
The Smart Cards are used as they are an HSM (Hardware Security Module) which
|
||||
provides excellent protection for the cryptographic material stored on it, and
|
||||
they are portable, which makes them suitable for creating systems where the
|
||||
cards are in separate physical locations, and need to be brought together in
|
||||
order to re-assemble secret material.
|
||||
|
|
@ -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
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
# Summary
|
||||
* [Introduction](intro.md)
|
||||
* [Threat Model](threat-model.md)
|
||||
* [Selecting a Quorum](selecting-quorum.md)
|
||||
* [System Roles](system-roles.md)
|
||||
* [Key Types](key-types.md)
|
||||
* [Software](software.md)
|
||||
* [Location](locations.md)
|
||||
* [Glossary](glossary.md)
|
||||
* [Generated Documents]()
|
||||
* [All Levels]()
|
||||
* [Create Vaults Repository](generated-documents/all-levels/create-vaults-repository.md)
|
||||
* [Personal PGP Key Provisioning](generated-documents/all-levels/pgp-key-provisioning.md)
|
||||
* [Level 2]()
|
||||
* [Fixed-Location]()
|
||||
* [Procurer](generated-documents/level-2/fixed-location/procurer/index.md)
|
||||
* [Procure Facility](generated-documents/level-2/fixed-location/procurer/procure-facility.md)
|
||||
* [Create Inventory Repository](generated-documents/level-2/fixed-location/procurer/create-inventory-repository.md)
|
||||
* [Procure Tamper Proofing Equipment](generated-documents/level-2/fixed-location/procurer/procure-tamper-proofing-equipment.md)
|
||||
* [Procure SD Card Pack](generated-documents/level-2/fixed-location/procurer/procure-sd-card-pack.md)
|
||||
* [Procure Hardware](generated-documents/level-2/fixed-location/procurer/procure-hardware.md)
|
||||
* [Provisioner](generated-documents/level-2/fixed-location/provisioner/index.md)
|
||||
* [Provision Computer](generated-documents/level-2/fixed-location/provisioner/provision-computer.md)
|
||||
* [Provision AirgapOS](generated-documents/level-2/fixed-location/provisioner/provision-airgapos.md)
|
||||
* [Provision Air-Gapped Bundle](generated-documents/level-2/fixed-location/provisioner/air-gapped-bundle.md)
|
||||
* [Proposer]()
|
||||
* [Propose Transaction](generated-documents/level-2/fixed-location/proposer/create-transaction-payload.md)
|
||||
* [Approver]()
|
||||
* [Transaction Approval](generated-documents/level-2/fixed-location/approver/approve-transaction.md)
|
||||
* [Operator](generated-documents/level-2/fixed-location/operator/index.md)
|
||||
* [Quorum Entropy Ceremony](generated-documents/level-2/fixed-location/operator/quorum-entropy-ceremony.md)
|
||||
* [Ceremony SD Card Provisioning](generated-documents/level-2/fixed-location/operator/ceremony-sd-card-provisioning.md)
|
||||
* [Namespace Operations]()
|
||||
* [Namespace Entropy Ceremony](generated-documents/level-2/fixed-location/operator/namespace-entropy-ceremony.md)
|
||||
* [Decrypt Namespace Secret](generated-documents/level-2/fixed-location/operator/decrypt-namespace-secret.md)
|
||||
* [Encrypt Wallet To Namespace PGP Key](generated-documents/level-2/fixed-location/operator/encrypt-wallet-to-namespace-key.md)
|
||||
* [Export Namespace Mnemonic](generated-documents/level-2/fixed-location/operator/export-namespace-mnemonic.md)
|
||||
* [Coins - SOL]()
|
||||
* [SOL - Generate Address](generated-documents/level-2/fixed-location/operator/coins/sol/generate-address.md)
|
||||
* [SOL - Transfer Token](generated-documents/level-2/fixed-location/operator/coins/sol/transfer-token.md)
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
// ANCHOR: content
|
||||
Look for your SD card device name (`<device_name>`) in the output of the `lsblk` command. It will typically be listed as `/dev/sdX` or `/dev/mmcblk<num>`, where X is a letter (e.g., `/dev/sdb`, `/dev/sdc`). You can identify it by its size or by checking if it has a partition (like `/dev/sdX1`)
|
||||
* You may mount the device using: `sudo mount /dev/<your_device> /media`
|
||||
// ANCHOR_END: content
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
// ANCHOR: content
|
||||
1. Connect SD card to online machine
|
||||
|
||||
1. {{ #include finding-device-name.md:content }}
|
||||
|
||||
1. If the `~/vaults/` repository already exists, ensure it doesn't have any changes that haven't been committed, then remove it using `sudo rm -rf ~/vaults` before re-running the previous step
|
||||
|
||||
1. Copy the repository with updated files to an online machine, sign, commit and push to the `vaults` repository:
|
||||
```
|
||||
$ cp -r /media/vaults ~/vaults/
|
||||
$ cd ~/vaults
|
||||
$ git add .
|
||||
$ git commit -m -S "<message>"
|
||||
$ git push origin HEAD
|
||||
```
|
||||
// ANCHOR_END: content
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Git Commit Signing
|
||||
// ANCHOR: steps
|
||||
1. Retrieve the value of your PGP key ID from smartcard
|
||||
|
||||
```
|
||||
gpg --card-status
|
||||
```
|
||||
|
||||
1. Configure git to sign commits with smartcard
|
||||
```
|
||||
$ git config --global user.name <name>
|
||||
$ git config --global user.email <email>
|
||||
$ git config --global user.signingKey <pgp_key_id>
|
||||
$ git config --global commit.gpgsign = true
|
||||
$ git config --global commit.merge = true
|
||||
```
|
||||
|
||||
1. Configure ssh to authenticate with smartcard
|
||||
|
||||
```
|
||||
$ echo 'export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"' > ~/.bashrc
|
||||
$ source ~/.bashrc
|
||||
```
|
||||
Note: If you use another shell such as zsh, adjust acccordingly
|
||||
// ANCHOR_END: steps
|
||||
/* ANCHOR: all */
|
||||
|
|
@ -1,19 +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.
|
||||
|
||||
* 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,76 +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
|
||||
|
||||
* YubiKey 5
|
||||
|
||||
// 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 multiple 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 an insider threat is able to plant a compromised computer in a store ahead of time.
|
||||
|
||||
1. Within the store, identify available adequate device
|
||||
|
||||
1. Purchase the device and place it in a see-through plastic bag which will be used to transport it to a "processing location", which SHOULD be an 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.
|
||||
|
||||
1. 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.
|
||||
|
||||
1. 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,31 +0,0 @@
|
|||
|
||||
/* ANCHOR: all */
|
||||
# Inventory Repository
|
||||
// ANCHOR: content
|
||||
|
||||
This repository is used to keep track of available inventory and tamper proofing evidence
|
||||
|
||||
## Repository Structure
|
||||
|
||||
```
|
||||
computers/
|
||||
<num>/
|
||||
description.txt
|
||||
tamper_evidence_front.jpeg
|
||||
tamper_evidence_back.jpeg
|
||||
bundles/
|
||||
<num>/
|
||||
description.txt
|
||||
tamper_evidence_front.jpeg
|
||||
tamper_evidence_back.jpeg
|
||||
sd_cards/
|
||||
<num>
|
||||
...
|
||||
```
|
||||
|
||||
## Procedure: Setting up Repository
|
||||
|
||||
{{ #include ./git-repository-initialization.md:procedure}}
|
||||
|
||||
// ANCHOR_END: content
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Linux Workstation (Online Machine)
|
||||
// ANCHOR: content
|
||||
* Linux Workstation (online machine)
|
||||
* Any internet connected computer with a Linux shell will suffice
|
||||
// ANCHOR_END: content
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
# Online Machine Provisioning
|
||||
|
||||
## QubesOS
|
||||
|
||||
QubesOS is a preferred operating system for use in high security assurance scenarios as it uses hardware based virtualization leveraging the Xen hypervisor, which gives strong isolation guarantees. This makes it trivial to create purpose specific environments, which have minimal software footprints, as well as restricted networking in order to limit ingress and egress.
|
||||
|
||||
* [Hardware Compability](https://www.qubes-os.org/hcl/)
|
||||
|
||||
* It is highly preferred to use a Purism machine due to additional hardware supply chain security features such as anti-interdiction
|
||||
|
||||
* Commonly used alternative makes include: ThinkPads, Framework and Dell
|
||||
|
||||
* [Installation](https://www.qubes-os.org/downloads/)
|
||||
|
||||
* MUST follow "verifying signatures" guide
|
||||
|
||||
## "Power-Washed" Chromebook with ChromeOS
|
||||
|
||||
In order to reduce surface area for attacks, we can reset a Chromebook to its factory settings, effectively wiping any malicious software that may have made its way onto the system during previous use.
|
||||
|
||||
### "Power-Washing"
|
||||
|
||||
1. Press and hold the Ctrl + Alt + Shift + R keys on your keyboard.
|
||||
|
||||
2. Select the Restart option.
|
||||
|
||||
3. A screen will appear asking you to confirm that you want to reset the device. Click Powerwash and Reset, then Continue.
|
||||
|
||||
|
||||
|
|
@ -1,81 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# OpenPGP Setup
|
||||
|
||||
Setting up a personal PGP key pair is necessary for a number of different
|
||||
aspects while bootstrapping QVS. The keys are a fundamental building block, and
|
||||
as such need to be set up in a manner that minimizes exposure risks.
|
||||
|
||||
## Generating Keys using `keyfork`
|
||||
// ANCHOR: steps-keyfork
|
||||
|
||||
1. Insert an SD card into the system
|
||||
|
||||
1. Change working directory to SD card mount location
|
||||
```
|
||||
$ cd /media/TRANSFER
|
||||
```
|
||||
|
||||
1. Insert all smartcards to be provisioned into the system.
|
||||
|
||||
1. Set expiry time via environment variable - you can update 2y to desired value:
|
||||
|
||||
```
|
||||
$ export KEYFORK_OPENPGP_EXPIRE=2y
|
||||
```
|
||||
|
||||
1. Generate a mnemonic, encrypting to a newly-generated key:
|
||||
|
||||
Ensure the User ID is your name and your email.
|
||||
|
||||
```
|
||||
$ keyfork mnemonic generate --encrypt-to-self output=encrypted.asc --provision openpgp-card,userid="Your Name <your@email.co>"
|
||||
```
|
||||
|
||||
The `count=` variable can be provided to `provision` to ensure the correct
|
||||
amount of smartcards is provisioned - the program will error if the amount
|
||||
of smartcards available is not equal to the count requested.
|
||||
|
||||
Note: The PIN can't use sequential numbers, characters or repeated patterns.
|
||||
|
||||
// ANCHOR_END: steps-keyfork
|
||||
|
||||
## Generating Keys on Smartcard
|
||||
// ANCHOR: steps-on-key-gen
|
||||
|
||||
1. Insert the smart card into the USB port if it is not already plugged in.
|
||||
|
||||
1. Open Command Prompt (Windows) or Terminal (macOS / Linux).
|
||||
|
||||
1. Enter the GPG command:
|
||||
|
||||
* `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 the key.
|
||||
|
||||
1. Specify how long the key should be valid for (specify the number in days, weeks, months, or years).
|
||||
|
||||
1. Confirm the expiration day.
|
||||
|
||||
1. When prompted, enter your name.
|
||||
|
||||
1. Enter your email address.
|
||||
|
||||
1. If needed, enter a comment.
|
||||
|
||||
1. Review the name and email, and accept or make changes.
|
||||
|
||||
1. Enter the default admin PIN again. The green light on the smart card will flash while the keys are being written.
|
||||
|
||||
1. Enter a Passphrase as the key will not allow you to pass without having a passphrase. If you do not enter a Passphrase generation will fail.
|
||||
|
||||
// ANCHOR_END: steps-on-key-gen
|
||||
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
# Purism Procurement Procedure (Anti-Interdiction)
|
||||
|
||||
1. Select a librem 14 laptop from https://puri.sm, and ensure:
|
||||
|
||||
* Memory: 8GB
|
||||
|
||||
* Storage: 250GB
|
||||
|
||||
* Power Adapter Plug: US
|
||||
|
||||
* Wireless: No wireless
|
||||
|
||||
* Firmware: PureBoot Bundle Anti-Interdiction (PureBoot Bundle Plus + Anti-interdiction services)
|
||||
|
||||
* Operating System: PureOS
|
||||
|
||||
* Warranty: 1 Year
|
||||
|
||||
* 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:
|
||||
|
||||
* Modify the laptop as per order specifications, in this case removing radio cards.
|
||||
|
||||
* Seal the screws on the bottom of the laptop using glitter of chosen color
|
||||
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
|
||||
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.
|
||||
|
|
@ -1,26 +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
|
||||
|
||||
1. Launch a terminal
|
||||
|
||||
1. {{ #include finding-device-name.md: content }}
|
||||
|
||||
1. 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`
|
||||
|
||||
1. 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`
|
||||
|
||||
1. You can verify that the SD card has been formatted by running lsblk again or by checking the file system type:
|
||||
|
||||
* `lsblk -f`
|
||||
|
||||
1. Once formatting is complete, you can safely remove physically or eject the SD card:
|
||||
|
||||
* `sudo eject /dev/sdX`
|
||||
//ANCHOR_END:steps
|
||||
|
|
@ -1,235 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
|
||||
// ANCHOR: entire-doc
|
||||
# Tamper Evidence Methods
|
||||
|
||||
There are different methods which can be used to ensure that objects have not been tampered between uses. This is especially relevant for equipment such as laptops. Each method comes with tradeoffs, and in the context of high assurance security it is instrumental to understand the tradeoffs in order to achieve an adequate level of confidence that supplies such as computers used for high risk operations retain their integrity.
|
||||
|
||||
There are a number of common methods which appear to provide a reasonable level of tamper evidence, but in fact do not. It is worth noting a few examples of these such as using tamper evident tape, or even glitter if done improperly. This document will focus on illustrating adequate methods, rather than enumerating ones that are inadequate.
|
||||
|
||||
## Properties
|
||||
|
||||
Tamper evident methods need to be:
|
||||
|
||||
* Difficult to circumvent
|
||||
|
||||
* Simple to set up
|
||||
|
||||
* Simple to verify
|
||||
|
||||
There are three reasonably secure methods which have been identified and are explored in this document that can be used in different contexts:
|
||||
|
||||
* Vacuum sealing objects surrounded by colored filler
|
||||
|
||||
* Glitter on screws
|
||||
|
||||
* Heads / Pureboot for secure boot
|
||||
|
||||
|
||||
#### Level 1 + 2
|
||||
|
||||
This threat level assumes fairly unsophisticated attackers, and as such, basic tamper proofing methods can be effective. These attackers would have a difficult time pursuing physical attacks such as evil maiden attacks, or covertly stealing and replacing hardware.
|
||||
|
||||
As such one of the following combinations of tamper proofing methods MUST be used:
|
||||
|
||||
* [Glitter on screw](#glitter-on-screws) + [pureboot/heads](#pureboot--heads)
|
||||
|
||||
* [Vacuum sealing with filler](#vacuum-sealed-bags-with-filler)
|
||||
|
||||
#### Level 3
|
||||
|
||||
This level of threat actors has a more extensive range of attacks which may include physical attacks. As such additional counter measures are required to ensure that the integrity and confidentiality of information is retained. The threat modelling document contains more information about this [level](threat-model.md#level-3)
|
||||
|
||||
* 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)
|
||||
|
||||
#### Level 4
|
||||
|
||||
This is the highest threat level and as such requires additional controls which protect hardware. More details around the capabilities of threat actors at this level are available in the [threat modeling document](threat-model.md#level-4)
|
||||
|
||||
* MUST use high grade tamper evident safes
|
||||
|
||||
* MUST use physical access controls
|
||||
|
||||
* MUST have continued surveillance of the storage location
|
||||
|
||||
## Vacuum Sealed Bags With Filler
|
||||
// ANCHOR: vsbwf-whole
|
||||
|
||||
One of the most reliable methods for ensuring tamper evidence relies on the randomness and difficulty of placing small objects henceforth referred to as "filler" (colored rice, lentils, confetti) in a transparent bag to encase an object which is then vacuum sealed. By placing an object in a transparent, vacuum sealable bag and surrounding it with filler, an arrangement of the filler around the object in the bag can be achieved which is difficult to reproduce. Upon sealing the object in this manner, photos can be taken to use as a reference once the object is accessed again - allowing one to verify that the arrangement of the filler has not changed.
|
||||
|
||||
### Threat Model
|
||||
|
||||
There are no known attacks for this type of tamper proofing method when executed properly. The main sources of risk stem from consistent and repeatable photography and comparison of photographs to ensure that any changes can be detected.
|
||||
|
||||
If photographs are not cryptographically signed, they can also be manipulated and/or replaced which could result in the compromise of the system as well.
|
||||
|
||||
The reason this method is effective is because unlike with many other methods that tamper proof a specific part of an object, such as applying glitter to screws which leaves device ports exposed, or using cryptographic signing to verify the hardware has not been modified, still leaving the door to physical modifications, vacuum sealing with colored filler encases the entire object in a tamper evident manner.
|
||||
|
||||
### Adequate Filler
|
||||
|
||||
To achieve the best level of randomness and difficulty of reproducing the arrangement of filler in a vacuum sealed bag, a variety of beads of different sizes and color should be used. They may be made of different materials as well but plastic is excellent because it doesn't change form when vacuum sealed - which can make it easier to reproduce patterns. Materials such as confetti and packing beans may be used, but because they can be flattened and retain the shape, arranging them in a given pattern is much easier. Other options like beans or lentils have less variety in color and shapes which makes it harder to detect differences.
|
||||
|
||||
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
|
||||
|
||||
Vacuum sealer needs to be able to seal bags of sufficient size to fit a 13" laptop
|
||||
|
||||
* [Nesco Deluxe Vacuum Sealer – VS-12P](https://www.nesco.com/product/deluxe-vacuum-sealer/)
|
||||
|
||||
* [Anova Precision Vacuum Sealer Pro](https://anovaculinary.com/en-ca/products/anova-precision-vacuum-sealer-pro)
|
||||
|
||||
|
||||
Sealing bags of standard size objects which need to be protected can fit in. The bags should be perfectly see through, rather than with writing or any irregularities in the plastic which can obfuscate the view of the inside of the bag. 11" width is recommended.
|
||||
|
||||
* [Anova Precision Vacuum Sealer Rolls (11" x 19.60')](https://anovaculinary.com/en-ca/products/anova-precision-vacuum-sealer-rolls)
|
||||
|
||||
* [2 Vacuum Sealer Rolls (11.0" x 19.70')](https://www.nesco.com/product/2-vacuum-sealer-rolls-11-0-x-19-70/)
|
||||
|
||||
### Additional Considerations
|
||||
|
||||
* This strategy may be layered, for example if one chooses to apply it to a hardware token, the sealed hardware token can be placed inside of a bigger bag, along with a laptop.
|
||||
|
||||
* A similar method can be used but with a bin filled with filler that the object is placed into. The main disadvantage here is that this type of tamper proofing is not resistant to seismic activity, air movement, or other sourced of vibration which could shift filler around.
|
||||
|
||||
### Procedure
|
||||
// ANCHOR: vsbwf-procedure
|
||||
|
||||
#### Requirements
|
||||
// ANCHOR: vsbwf-equipment
|
||||
* [Vacuum sealer](tamper-evidence-methods.md#vacuum-sealers)
|
||||
|
||||
* [Vacuum plastic roll](tamper-evidence-methods.md#vacuum-sealers)
|
||||
|
||||
{{ #include tamper-evidence-methods.md:vsbwf-filler }}
|
||||
|
||||
// ANCHOR_END: vsbwf-equipment
|
||||
|
||||
#### Sealing
|
||||
// ANCHOR: vsbwf-procedure-sealing
|
||||
|
||||
1. Insert object(s) into plastic bag
|
||||
|
||||
1. Fill bag with enough plastic beads that most of the object is surrounded
|
||||
|
||||
1. 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, ensuring continued dual custody, and commit the tamper evidence photographs to a repository. If two individuals are present, have one create a PR with a signed commit, and the other do a signed merge commit.
|
||||
|
||||
// ANCHOR_END: vsbwf-procedure-sealing
|
||||
|
||||
#### Unsealing
|
||||
// ANCHOR: vsbwf-procedure-unsealing
|
||||
|
||||
a. Retrieve digital/physical photographs of both sides of sealed bundle
|
||||
|
||||
b. Compare all photographs to object for differences
|
||||
|
||||
c. Proceed with unsealing the object if no differences are detected
|
||||
|
||||
// ANCHOR_END: vsbwf-procedure-unsealing
|
||||
|
||||
// ANCHOR_END: vsbwf-procedure
|
||||
// ANCHOR_END: vsbwf-whole
|
||||
|
||||
## Glitter on Screws
|
||||
|
||||
Glitter can be used as an additional control to provide tamper evidence on specific parts of hardware such as laptop screws - in case an adversary attempts to open the laptop and introduce a malicious chip, antenna or otherwise. While glitter allows to detect physical tampering of the hardware, it does not provide tamper evidence of the firmware and software that runs on the computer, and as such is not sufficient for adequate tamper proofing of laptops on its own.
|
||||
|
||||
### Procedure
|
||||
|
||||
#### Requirements
|
||||
|
||||
* 2 or 3 different types of glitter, ideally with small and large pieces of glitter of different colors
|
||||
|
||||
#### Sealing
|
||||
|
||||
1. Clean the surface the glitter will be applied to
|
||||
|
||||
1. Apply a thin layer of the first type of glitter
|
||||
|
||||
1. Wait for it to dry
|
||||
|
||||
1. 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)
|
||||
|
||||
1. Ensure the SD card is in dual custody until its contents are uploaded to a repository, and signed by both parties (one creates a PR, the other creates a signed merge using the `git` CLI)
|
||||
|
||||
#### Verification
|
||||
|
||||
There is no "unsealing" procedure as the glitter used on screws, or in other similar contexts is meant as a more permanent control. As such the primary action that's performed is the verification of the integrity of the tamper proofing seal.
|
||||
|
||||
To verify that the seal has not been tampered, compare the glitter arrangement to a photograph which had been previously signed and stored. Both operators should have a copy of the picture and use it to verify the integrity of the seal.
|
||||
|
||||
## PureBoot / Heads
|
||||
|
||||
This tamper proofing method is designed to protect the secure boot process of a computer. It does not protect the computer from physical tampering which can be used to ad
|
||||
|
||||
### Procedure
|
||||
|
||||
Refer to the [PureBoot Setup](./enable-pure-boot-restricted-boot.md) document
|
||||
|
||||
## Tamper Proofing Station
|
||||
|
||||
The Tamper Proofing Station is a simple structure used to make it easy to take photographs which have consistent lightning, consistent angle, and consistent distance from the object being photograph. In this manner, photographs can be taken which ensure that any differences in the sealed object can be easily detected.
|
||||
|
||||
### Instructions
|
||||
|
||||
To construct an appropriate Tamper Proofing Station, the simplest setup consists of:
|
||||
|
||||
* Overhead camera mounting rig
|
||||
|
||||
* Powerful LED light which can be attached to the mounting rig
|
||||
|
||||
## Polaroid camera
|
||||
|
||||
* Can be attached to mounting rig
|
||||
|
||||
### Models
|
||||
// ANCHOR: polaroid-cameras
|
||||
* [Polaroid Now+](https://www.amazon.com/Polaroid-Generation-Bluetooth-Connected-Controlled/dp/B0BVNJHMVQ)
|
||||
|
||||
* Preferred film: [Color I-Type Film](https://www.amazon.com/Polaroid-Originals-Instant-Color-I-Type/dp/B084GXXLM7)
|
||||
// ANCHOR_END: polaroid-cameras
|
||||
|
||||
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.
|
||||
|
||||
## High Visibility Storage
|
||||
|
||||
The purpose of high visibility storage is to provide a way to keep items which are used during a ceremony from risk of being swapped by one of the participants in the ceremony. As such, a high visibility storage should be a plastic container which is sealed, and which is only opened under the close supervision of a quorum of individuals.
|
||||
|
||||
Some examples include:
|
||||
|
||||
* Large glass jar
|
||||
|
||||
* Plastic bag
|
||||
|
||||
## Safe
|
||||
|
||||
Placing objects into a safe helps improve the security of objects, and introduces an additional layer of tamper evidence.
|
||||
|
||||
## References
|
||||
|
||||
* [Blog About Tamper Evident Protection Methods](http://web.archive.org/web/20241130002204/https://dys2p.com/en/2021-12-tamper-evident-protection.html)
|
||||
|
||||
* [BitBoxTep - tamper-evident packaging](http://web.archive.org/web/20240519013739/https://medium.com/shiftcrypto/an-introduction-to-bitboxtep-our-new-tamper-evident-packaging-8fa06d983c32)
|
||||
|
||||
* [Mullvad - glitter tamper proofing](http://web.archive.org/web/20240317004315/https://mullvad.net/en/blog/how-tamper-protect-laptop-nail-polish)
|
||||
|
||||
* [Purism anti-interdiction](http://web.archive.org/web/20241121233006/https://puri.sm/posts/anti-interdiction-services/)
|
||||
|
||||
* [Purism Liberty phone anti-interdiction](http://web.archive.org/web/20240903104700/https://puri.sm/posts/anti-interdiction-on-the-librem-5-usa/)
|
||||
// ANCHOR_END: entire-doc
|
||||
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,56 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Vaults Repository
|
||||
|
||||
// ANCHOR: content
|
||||
This repository holds data pertaining to vaults. The primary data consists of:
|
||||
|
||||
* Operation proposals
|
||||
|
||||
* Operation approvals
|
||||
|
||||
* Payloads
|
||||
|
||||
* Trusted PGP keyring
|
||||
|
||||
* Shardfiles
|
||||
|
||||
* Blockchain metadata
|
||||
|
||||
* Policies (such as spending rules)
|
||||
|
||||
* Ceremony logs
|
||||
|
||||
## Directives
|
||||
|
||||
* MUST be a private repository
|
||||
|
||||
* MUST require signed commits
|
||||
|
||||
## Repository Structure
|
||||
|
||||
```
|
||||
keys/
|
||||
all/
|
||||
fingerprint.asc
|
||||
<namespace>/
|
||||
ceremonies/
|
||||
<date>/
|
||||
log.txt
|
||||
payloads/
|
||||
payload_<num>.json
|
||||
payload_<num>.json.sig
|
||||
blockchain_metadata/
|
||||
sol_nonce_address.txt
|
||||
policies/
|
||||
spending-policy.json [NOT IMPLEMENTED]
|
||||
keyring.asc
|
||||
shardfile.asc
|
||||
```
|
||||
|
||||
## Procedure: Setting up Repository
|
||||
|
||||
{{ #include ./git-repository-initialization.md:procedure}}
|
||||
|
||||
// ANCHOR_END: content
|
||||
/* ANCHOR_END: all */
|
||||
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
# Verifying Signatures
|
||||
|
||||
When building and downloading software it is essential to verify signatures to ensure its integrity. It is also important to verify that the latest commit, and ideally that all commits that are being used to build from are verified to have signatures from trusted keys. This can be done using `git verify-commit HEAD` or similar. A script like below can be modified to check for trusted keys for all commits:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
mapfile -t trusted_keys < trusted_keys.txt
|
||||
|
||||
is_trusted_key() {
|
||||
local key="$1"
|
||||
for trusted_key in "${trusted_keys[@]}"; do
|
||||
if [[ "$key" == "$trusted_key" ]]; then
|
||||
return 0
|
||||
fi
|
||||
done
|
||||
return 1
|
||||
}
|
||||
|
||||
git rev-list --all | while read commit; do
|
||||
if git verify-commit "$commit" > /dev/null 2>&1; then
|
||||
key_id=$(git show "$commit" | grep 'gpgsig' | awk '{print $NF}')
|
||||
|
||||
if ! is_trusted_key "$key_id"; then
|
||||
echo "$commit: Signed but NOT by a trusted key ($key_id)"
|
||||
fi
|
||||
else
|
||||
echo "$commit: Not signed"
|
||||
fi
|
||||
done
|
||||
```
|
||||
|
||||
Verification of software depends on two primary aspects:
|
||||
|
||||
* Ensuring that the hash of a binary matches some point of reference, for example the same binary previously built by a trusted team member, or a hash hosted alongside the software in the download location.
|
||||
|
||||
* Ensuring that signatures alongside hashes are from trusted asymmetric keys (e.g PGP keys)
|
||||
|
||||
In order to achieve this, one must establish that specific keys are "well known" and can be trusted - that is, that they belong to a given individual. To achieve this, the best method is to exchange keys in person, but a combination of the following methods gives even higher confidence thresholds:
|
||||
|
||||
* Verifying the key in person
|
||||
|
||||
* Finding a reference to a public key on the individual's personal website
|
||||
|
||||
* Finding a reference to a public key on the individual's social media platforms
|
||||
|
||||
* Finding a keyoxide profile for a given public key
|
||||
|
||||
* Finding a reference to a public key on a company website
|
||||
|
||||
* Looking up popular key servers to see if a given individual is associated with it
|
||||
|
||||
Each point of reference allows us to build confidence that the key is indeed owned by an individual.
|
||||
|
||||
One other consideration is how the key is protected. If possible, find out how the individual manages their key. If the key is stored on a local machine, the trust level for that key should be low. If the individual always manages their keys in airgapped environments, and on HSMs, then a higher level of trust can be ascribed - although ultimately in most cases it's impossible to verify that the individual followed a given policy around key management.
|
||||
|
||||
One favorable method for ensuring that a key never got exposed is using built in cryptographic attestation that a key never left a TPM, such as the one offered by YubiKey. While this type of key setup has the downside of not being able to back it up, one could use a master key to sign such a key, authorizing it for use, while giving the flexibility to rotate if the hardware token is damaged or lost.
|
||||
|
|
@ -1,67 +0,0 @@
|
|||
# Fixed Location Reusable Laptop Ceremony
|
||||
|
||||
This device is intended for use in a secure facility such as a [SCIF](TODO) which has the added assurances of protecting the environment from a wide range of side-channel attacks, as well as protection from physical attacks, and more comprehensive tamper proofing controls.
|
||||
|
||||
The fixed location should include a work-station which makes it easy to perform the [tamper proofing](tamper-evidence-methods.md#tamper-proofing-station) procedure. This station may consist of a simple frame which holds a LED light, for consistent lightning, as well as a camera stand above it which can be used to take pictures. The camera should have an SD card that easily slides out of it so that the device doesn't leave and re-enter the room, only the SD card does.
|
||||
|
||||
* TODO: this is actually not necessary for the fixed location device, but it's good to have this setup in the same facility maybe for processing/setting up the one time use laptops
|
||||
|
||||
The primary tamper proofing methods for the fixed location device are:
|
||||
|
||||
* Heads firmware protection (TODO link to document which explains how to set up Purism)
|
||||
|
||||
* Glitter to prevent physical access to hardware (TODO link to how to properly use glitter for tamper proofing)
|
||||
|
||||
* On-premises audio and visual monitoring (TODO select appropriate equipment)
|
||||
|
||||
* Physical vault (TODO find adequate vaults)
|
||||
|
||||
## Procedure
|
||||
|
||||
### Unsealing
|
||||
|
||||
1. Select at least two authorized operators who will be participating in the ceremony
|
||||
|
||||
2. Print photographs of tamper proofing of the laptop which will be used for the ceremony
|
||||
|
||||
* Both photos of vacuum sealed bag with filler and glitter on the bottom screws of laptop are required
|
||||
|
||||
3. Make an entry into the access log, specifying the:
|
||||
|
||||
* Individuals involved
|
||||
|
||||
* Approximate time of entry
|
||||
|
||||
4. Enter the SCIF, ensuring to lock the door behind you from the inside. The room should not be accessible from the outside during a ceremony.
|
||||
|
||||
* Ensure that no individual is bringing in any electronic devices. A hand-held or gate metal detector can be used for this.
|
||||
|
||||
5. Access the laptop safe, and move the laptop, its hardware token, and polaroid to the Tamper Proofing Workstation
|
||||
|
||||
* Compare the polaroid and digital photographs for any differences
|
||||
|
||||
* Then compare the photographs to the actual object
|
||||
|
||||
* Check the glitter on the bottom screws of the laptop ensuring there are no scratch marks, and compare the screws to photos
|
||||
|
||||
* If there are any issues detected, initiate incident response
|
||||
|
||||
6. Initiate the [Secure Boot Sequence](secure-boot-sequence.md)
|
||||
|
||||
{{ #include secure-boot-sequence.md }}
|
||||
|
||||
7. Use one of the [Playbooks](todo) to carry out a task
|
||||
|
||||
#### Sealing
|
||||
|
||||
{{ #include tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
|
||||
2. Remove the SD card from the camera and use chain of custody principles to ensure the integrity of the data
|
||||
|
||||
3. Place the sealed laptop and signed polaroids, as well as the hardware token back in the safe
|
||||
|
||||
4. Exit the SCIF and lock it
|
||||
|
||||
5. Update the log with the exit time
|
||||
|
||||
6. Upload the photos to a git repository, ensuring the commit is signed using PGP
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
# Flash ISO Image to a Storage Device
|
||||
|
||||
1. 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)
|
||||
|
||||
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.
|
||||
|
||||
```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:
|
||||
|
||||
```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.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
# Create Ceremony Repository
|
||||
|
||||
{{ #include ../../component-documents/vaults-repository.md:content }}
|
||||
|
|
@ -1,81 +0,0 @@
|
|||
# Personal PGP Key Provisioning
|
||||
|
||||
## Requirements
|
||||
|
||||
* [AirgapOS SD card](../level-2/fixed-location/provisioner/provision-airgapos.md)
|
||||
* Provided by [AirGapped Bundle](../level-2/fixed-location/provisioner/air-gapped-bundle.md)
|
||||
* Alternative: Create your own from documentation in [AirgapOS Repository](https://git.distrust.co/public/airgap)
|
||||
|
||||
* AirgapOS Laptop
|
||||
* Provided by [AirGapped Bundle](../level-2/fixed-location/provisioner/air-gapped-bundle.md)
|
||||
* Alternative: Computer that can load AirgapOS ([compatibility reference](https://git.distrust.co/public/airgap#tested-models))
|
||||
|
||||
{{ #include ../../component-documents/linux-workstation.md:content }}
|
||||
|
||||
* 1+ Smart Card
|
||||
* At least 1 primary smart card
|
||||
* Any number of backup smart cards
|
||||
|
||||
* 1 Transfer SD card
|
||||
* Document will assume the card is labelled as "TRANSFER"
|
||||
|
||||
## Process
|
||||
|
||||
**Note: Most steps will simplified to a single command in a future iteration**
|
||||
|
||||
**See: [keyfork#73](https://git.distrust.co/public/keyfork/issues/73), [keyfork#74](https://git.distrust.co/public/keyfork/issues/74), [keyfork#77](https://git.distrust.co/public/keyfork/issues/77)**
|
||||
|
||||
1. If using pre-sealed Cold Bundle unseal as follows:
|
||||
|
||||
{{ #include ../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing }}
|
||||
|
||||
1. Boot AirgapOS Laptop
|
||||
|
||||
{{ #include ../../component-documents/openpgp-setup.md:steps-keyfork}}
|
||||
|
||||
1. Power down AirgapOS Laptop
|
||||
|
||||
1. Switch to Linux Workstation
|
||||
|
||||
1. Attach SD card from AirgapOS machine
|
||||
|
||||
1. Attach smartcard provisioned with AirgapOS machine
|
||||
|
||||
1. Import newly generated public key into local keychain
|
||||
|
||||
```
|
||||
$ gpg --import /media/transport/*.pub.asc
|
||||
```
|
||||
|
||||
{{ #include ../../component-documents/git-commit-signing.md:steps }}
|
||||
|
||||
1. Push new key material to Vaults repository
|
||||
|
||||
a. Clone repository (if not done previously)
|
||||
```
|
||||
$ git clone <vaults_repository_url> ~/vaults
|
||||
```
|
||||
b. Checkout main branch
|
||||
```
|
||||
$ cd ~/vaults
|
||||
$ git checkout main
|
||||
$ git pull origin main
|
||||
```
|
||||
b. Commit and push modifications
|
||||
```
|
||||
$ cp /media/TRANSFER/*.asc keys/all
|
||||
$ git add .
|
||||
$ git commit -S -m "add <name> pgp key"
|
||||
$ git push origin main
|
||||
```
|
||||
|
||||
1. Communicate your new key fingerprint to all other participants:
|
||||
|
||||
* Preferred: In person
|
||||
|
||||
* Fallback: via two logically distinct online communications methods (e.g. encrypted chat, and video call)
|
||||
|
||||
1. Get confirmation they have imported your key to their keychains
|
||||
|
||||
* e.g. `gpg --import <your_key_id>.asc`
|
||||
* Confirm this is done for keyrings on workstations used to interact with the Vaults repository
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Basic Requirements
|
||||
|
||||
## For Quorum Based Operations
|
||||
// ANCHOR: requirements
|
||||
|
||||
* 2 individuals with appropriate role
|
||||
|
||||
* Each needs a [Personal PGP key pair](/generated-documents/all-levels/pgp-key-provisioning.html)
|
||||
|
||||
* [Tamper-proofing equipment](/generated-documents/level-2/fixed-location/procurer/procure-tamper-proofing-equipment.html)
|
||||
|
||||
// ANCHOR_END: requirements
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,85 +0,0 @@
|
|||
# Approver - Approve Transaction
|
||||
|
||||
The approver is responsible for verifying a transaction proposed by a [proposer](../../../../system-roles.md).
|
||||
|
||||
## Requirements
|
||||
|
||||
* [Quorum PGP Key](../operator/quorum-entropy-ceremony.md)
|
||||
|
||||
* [Online Machine](TODO)
|
||||
|
||||
* [SD Card Pack](../provisioner/provision-sd-card.md)
|
||||
|
||||
* [Air-Gapped Bundle](../provisioner/air-gapped-bundle.md)
|
||||
|
||||
* The approver 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 approver should verify the commit signatures of the photographs they are printing against a list of permitted PGP keys found in the `vaults` repo
|
||||
|
||||
* Clone the [Vaults Repository](../../../all-levels/create-vaults-repository.md) for your organization to the machine
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Turn on online machine
|
||||
|
||||
1. Pull the latest changes from the `vaults` repository
|
||||
|
||||
1. Unseal the SD Card Pack
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
1. Plug a fresh SD card into the online machine
|
||||
|
||||
1. Save the `vaults` repository to the SD card, referred to as the Ceremony SD card
|
||||
|
||||
1. Unplug the Ceremony SD card
|
||||
|
||||
1. Unseal the tamper proofed bundle
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
1. Insert the AirgapOS SD card into the airgapped machine and turn it on
|
||||
|
||||
1. Once booted, unplug the AirgapOS SD card
|
||||
|
||||
1. Plug in the Ceremony SD card
|
||||
|
||||
1. {{ #include ../../../../component-documents/finding-device-name.md:content }}
|
||||
|
||||
1. Copy the git repo locally from the Ceremony SD card and change into it
|
||||
```
|
||||
$ cp -r /media/vaults /root/vaults
|
||||
$ cd /root/vaults
|
||||
```
|
||||
1. Plug in the Operator smart card
|
||||
|
||||
1. Verify the existing signatures and add your own signature:
|
||||
|
||||
* `icepick workflow --add-signature-to-quorum <namespace>/ceremonies/<date>/payload_<num>.json --shardfile <shardfile>.asc`
|
||||
|
||||
1. {{ #include ../../../../component-documents/finding-device-name.md:content }}
|
||||
|
||||
1. Copy the updated vaults repo to the SD card
|
||||
|
||||
* `cp -r /root/vaults /media`
|
||||
|
||||
1. Unplug the SD card from the air-gapped machine
|
||||
|
||||
1. Plug in the SD card into the online machine
|
||||
|
||||
1. {{ #include ../../../../component-documents/finding-device-name.md:content }}
|
||||
|
||||
1. Copy the updated repository locally and change into it:
|
||||
```
|
||||
$ cp -r /media/vaults ~/
|
||||
$ cd ~/vaults
|
||||
```
|
||||
1. Stage, sign, commit and push changes to the ceremonies repository:
|
||||
```
|
||||
$ git add <namespace>/ceremonies/<date>/payloads/*
|
||||
$ git commit -S -m "add payload signature for payload_<num>.json"
|
||||
$ git push origin main
|
||||
```
|
||||
1. Tamper proof the AirgapOS and Air-gapped laptop
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
# Ceremony SD Card Provisioning
|
||||
|
||||
## Requirements
|
||||
|
||||
* [SD Card Pack](../procurer/procure-sd-card-pack.md)
|
||||
|
||||
* [Personal PGP Keys](/key-types.html#personal-pgp-keypair)
|
||||
|
||||
{{ #include ../../../../component-documents/linux-workstation.md:content }}
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Turn on the computer
|
||||
|
||||
1. Open the SD Card Pack
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing }}
|
||||
|
||||
1. Plug in a fresh SD card into computer
|
||||
|
||||
1. Navigate to the ceremony repository for the ceremony being executed
|
||||
|
||||
* {{ #include ../../../../component-documents/finding-device-name.md:content }}
|
||||
|
||||
1. Write the ceremony repo data to the SD card:
|
||||
|
||||
`sudo cp -r vaults/ /media`
|
||||
|
||||
1. Unplug the SD card
|
||||
|
||||
1. Turn off the computer
|
||||
|
|
@ -1,174 +0,0 @@
|
|||
# SOL - Generate Address
|
||||
|
||||
## Requirements
|
||||
|
||||
{{ #include ../../../../operator-requirements.md:requirements }}
|
||||
|
||||
{{ #include ../../../../../../component-documents/linux-workstation.md:content }}
|
||||
|
||||
* [High Visibility Storage](TODO): plastic container or bag that's used to keep items while not in use in a visible location like the middle of a desk.
|
||||
|
||||
* [Quorum PGP key pairs](../../key-types.md#quorum-pgp-keypair)
|
||||
|
||||
* [Ceremony SD card](../../ceremony-sd-card-provisioning.md)
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Enter the designated location with the quorum of operators and all required equipment
|
||||
|
||||
1. Lock access to the location - there should be no inflow or outflow of people during the ceremony
|
||||
|
||||
1. Place Ceremony SD card in High Visibility Storage
|
||||
|
||||
1. Retrieve sealed Air-Gapped bundle, polaroid of tamper evidence, and online laptop from locked storage
|
||||
|
||||
{{ #include ../../../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
1. Place all contents except for the laptop into High Visibility Storage
|
||||
|
||||
### Offline Machine: Generate Address
|
||||
|
||||
1. Retrieve AirgapOS SD card and plug it into the air-gapped machine
|
||||
|
||||
1. Turn on air-gapped machine
|
||||
|
||||
1. Unplug the AirgapOS SD card and place it in High Visibility Storage
|
||||
|
||||
1. Retrieve Ceremony SD card from High Visibility Storage and plug it into the air-gapped machine
|
||||
|
||||
1. Copy the `vaults` repository to the machine and switch to it
|
||||
```
|
||||
$ cp -r /media/vaults /root/
|
||||
$ cd /root/vaults
|
||||
```
|
||||
|
||||
1. Start Keyfork using the relevant Shardfile:
|
||||
|
||||
1. `keyfork recover shard --daemon <namespace>/shardfile.asc`
|
||||
|
||||
1. Follow on screen prompts
|
||||
|
||||
1. If the desired `<coin>` directory doesn't exist for the namespace, create it:
|
||||
|
||||
* `mkdir -p <namespace>/<coin>`
|
||||
|
||||
* e.g `mkdir -p vault_1/sol/`
|
||||
|
||||
1. Connect to the appropriate coin directory:
|
||||
|
||||
* `cd <namespace>/<coin>/`
|
||||
|
||||
1. Check what the latest address account is:
|
||||
|
||||
* `ls -la .`
|
||||
|
||||
1. Find what the latest number for the address is, and add 1 to it. This will be the new address account.
|
||||
|
||||
* For example if the latest address file is 42, the new account_id would be 43. The addresses should start at `0`
|
||||
|
||||
* Set an environment variable with the new account_id:
|
||||
|
||||
* `account_id=<num>`, e.g `account_id=43`
|
||||
|
||||
1. Generate a new address:
|
||||
|
||||
* `icepick workflow sol generate-address --account $account_id | jq -r .pubkey > $account_id.txt`
|
||||
* [38 removes need to use jq](https://git.distrust.co/public/icepick/issues/38)
|
||||
|
||||
1. Sign the file using:
|
||||
|
||||
* Import OpenPGP keys:
|
||||
|
||||
* `gpg --import /media/<device_name>/vaults/keys/all/*.asc`
|
||||
|
||||
* `gpg --detach-sign $account_id.txt`
|
||||
|
||||
1. You may repeat the previous steps, starting at the step where the `account_id` is set.
|
||||
|
||||
1. Once finished, copy the updated repository back to the Ceremony SD card:
|
||||
|
||||
* `cp -rf /root/vaults /media/`
|
||||
|
||||
1. Shut down the air gapped machine
|
||||
|
||||
1. Unplug the Ceremony SD card and place it into High Visibility Storage
|
||||
|
||||
### Online Machine: Generate Nonce Account
|
||||
|
||||
1. Turn on online machine
|
||||
|
||||
1. Make sure `jq` is installed:
|
||||
|
||||
* `sudo apt install jq`
|
||||
|
||||
1. Retrieve the Ceremony SD card from High Visibility Storage and plug it into the computer
|
||||
|
||||
1. {{ #include ../../../../../../component-documents/finding-device-name.md:content }}
|
||||
|
||||
1. Copy the `vaults` repository from the Ceremony SD card:
|
||||
|
||||
* `cp -r /media/vaults ~/`
|
||||
|
||||
* If the `~/vaults/` repository already exists, ensure it doesn't have any changes that haven't been committed, then remove it using `sudo rm -rf ~/vaults` before re-running the previous step
|
||||
|
||||
1. Ensure `keyfork` is available on the system:
|
||||
|
||||
* Follow steps from [installation guide](https://git.distrust.co/public/keyfork#install)
|
||||
|
||||
1. Ensure `icepick` is available on system
|
||||
|
||||
* Follow steps from [installation guide](TODO)
|
||||
|
||||
1. Set unsafe `keyfork` usage variable:
|
||||
|
||||
* `export SHOOT_SELF_IN_FOOT=1`
|
||||
|
||||
1. Generate throwaway mnemonic to generate address which will be used for funding the creation of nonce account:
|
||||
|
||||
* `keyfork mnemonic generate | KEYFORK_PROMPT_TYPE=headless keyfork recover mnemonic --daemon`
|
||||
|
||||
1. Change directory into the desired \<namespace>/\<coin> directory:
|
||||
|
||||
* `cd ~/vaults/<namespace>/<coin>`
|
||||
|
||||
1. Select which account you are creating the delegate address by viewing the appropriate \<namespace>/\<coin>/ directory:
|
||||
|
||||
* `ls -la .`
|
||||
|
||||
1. Once you have selected the appropriate account, set the account_id variable:
|
||||
|
||||
* `account_id=<num>`
|
||||
|
||||
1. Use `icepick` to generate nonce account:
|
||||
|
||||
* The following command will need to be updated to use the appropriate \<cluster>, which can be `devnet`, `testnet` or `mainnet-beta`
|
||||
|
||||
* Set `icepick` config file:
|
||||
|
||||
* `export ICEPICK_CONFIG_FILE=<path_to_icepick_repositry>/icepick.toml`
|
||||
|
||||
* `icepick workflow sol generate-nonce-account --authorization-address "$(cat $account_id.txt)" | jq -r .nonce_account > $account_id-na.txt`
|
||||
* [38 removes he need to use jq and cat](https://git.distrust.co/public/icepick/issues/38)
|
||||
|
||||
* Repeat command if returned message is "The transaction was possibly not received by the cluster."
|
||||
|
||||
1. Airdrop the wallet displayed on-screen with 0.01 SOL
|
||||
|
||||
* Once the airdrop is done, nonce account will be created
|
||||
|
||||
1. Stage, commit, sign and push the changes:
|
||||
```
|
||||
$ git add .
|
||||
$ git commit -m -S "<message>"
|
||||
$ git push origin HEAD
|
||||
```
|
||||
### Sealing
|
||||
|
||||
1. Gather all the original items that were in the air-gapped bundle:
|
||||
|
||||
* Air-gapped computer
|
||||
|
||||
* AirgapOS SD card
|
||||
|
||||
{{ #include ../../../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
|
||||
|
|
@ -1,125 +0,0 @@
|
|||
# Operator - SPL Token Transfer
|
||||
|
||||
## Requirements
|
||||
|
||||
{{ #include ../../../../operator-requirements.md:requirements }}
|
||||
|
||||
* Online machine
|
||||
|
||||
* [High Visibility Storage](TODO): plastic container or bag that's used to keep items while not in use in a visible location like the middle of a desk.
|
||||
|
||||
* [Quorum PGP key pairs](../../key-types.md#quorum-pgp-keypair)
|
||||
|
||||
* [Ceremony SD card](../../ceremony-sd-card-provisioning.md)
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Enter the designated location with the quorum of operators and all required equipment
|
||||
|
||||
1. Lock access to the location - there should be no inflow or outflow of people during the ceremony
|
||||
|
||||
1. Place Ceremony SD card in High Visibility Storage
|
||||
|
||||
1. Retrieve sealed Air-Gapped bundle, polaroid of tamper evidence, and online laptop from locked storage
|
||||
|
||||
{{ #include ../../../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
1. Place all contents except for the laptop into High Visibility Storage
|
||||
|
||||
### Online Machine: Acquire Nonce
|
||||
|
||||
1. Turn on online machine
|
||||
|
||||
1. Retrieve the Ceremony SD card from High Visibility Storage and plug it into the computer
|
||||
|
||||
1. Get the nonce address for the address you are sending from by checking the appropriate \<namespace>/\<coin>/ directory.
|
||||
|
||||
* e.g `vaults/<namespace>/<coin>/0-na.txt`
|
||||
|
||||
* Set the nonce address variable:
|
||||
|
||||
* `nonce_address="$(cat vaults/<namespace>/<coin>/<account_id>-na.txt)"`
|
||||
|
||||
1. Set `ICEPICK_DATA_DIRECTORY`:
|
||||
|
||||
{{ #include ../../../../../../component-documents/finding-device-name.md:content }}
|
||||
|
||||
* `export ICEPICK_DATA_DIRECTORY=/media/external/`
|
||||
|
||||
1. set `ICEPICK_CONFIG_FILE`
|
||||
|
||||
* `export ICEPICK_CONFIG_FILE=<path_to_icepick_repo>/icepick.toml`
|
||||
|
||||
1. Run the command: `icepick workflow sol broadcast --nonce-address=$nonce_address`
|
||||
|
||||
* Await completion message before removing Ceremony SD card
|
||||
|
||||
* 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 after the workflow payloads are signed on the offline machine
|
||||
|
||||
### Offline Machine: Create and Sign Transaction
|
||||
|
||||
1. Retrieve AirgapOS SD card and plug it into the air-gapped machine
|
||||
|
||||
1. Boot the computer
|
||||
|
||||
1. Unplug the AirgapOS SD card and place it in High Visibility Storage
|
||||
|
||||
1. Retrieve Ceremony SD card from High Visibility Storage and plug it into the air-gapped machine
|
||||
|
||||
1. {{ #include ../../../../../../component-documents/finding-device-name.md:content }}
|
||||
|
||||
1. Start Keyfork using the relevant Shardfile:
|
||||
|
||||
* `keyfork recover shard --daemon /media/<device_name>/vaults/<namespace>/shardfile.asc`
|
||||
|
||||
* The Shardfile may be named something else. Use `find /media/<device_name>/vaults -type f -name '*shardfile*.asc'` to list all files.
|
||||
|
||||
1. Follow on screen prompts
|
||||
|
||||
1. Set `ICEPICK_DATA_DIRECTORY`:
|
||||
|
||||
* `export ICEPICK_DATA_DIRECTORY=/media/<device_name>`
|
||||
|
||||
1. Run the `icepick` command with the transaction payload
|
||||
|
||||
* `icepick workflow --run-quorum <payload>.json --shardfile /media/<device_name>/vaults/<namespace>/shardfile.asc`
|
||||
|
||||
* Follow on screen prompts
|
||||
|
||||
1. Unplug the Ceremony SD card and place it in High Visibility Storage
|
||||
|
||||
### Broadcast Transaction: Online Machine
|
||||
|
||||
1. Retrieve Ceremony SD from High Visibility Storage and plug it into online machine
|
||||
|
||||
1. The still running broadcast command on the online machine will broadcast the transaction automatically
|
||||
|
||||
1. The url that's found in the response after a successful broadcast should be reviewed and committed to the ceremony repository
|
||||
|
||||
1. Remove the transaction files in `ICEPICK_DATA_DIRECTORY`
|
||||
|
||||
* `rm $ICEPICK_DATA_DIRECTORY/transaction.json`
|
||||
|
||||
* `rm $ICEPICK_DATA_DIRECTORY/nonce.json`
|
||||
|
||||
1. Unplug the Ceremony SD card and place it in High Visibility Storage
|
||||
|
||||
### Repeat
|
||||
|
||||
1. You may repeat previous steps as many times as necessary to process all workflow payloads
|
||||
|
||||
## Finalization
|
||||
|
||||
1. Shut down online machine
|
||||
|
||||
1. Shut down the air gapped machine
|
||||
|
||||
### Sealing
|
||||
|
||||
1. Gather all the original items that were in the air-gapped bundle:
|
||||
|
||||
* Air-gapped computer
|
||||
|
||||
* AirgapOS SD card
|
||||
|
||||
{{ #include ../../../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
# Decrypt Namespace Secret
|
||||
|
||||
## Requirements
|
||||
|
||||
{{ #include ../../operator-requirements.md:requirements }}
|
||||
|
||||
* [Ceremony SD Card](../operator/ceremony-sd-card-provisioning.md)
|
||||
|
||||
* [High Visibility Storage](TODO): plastic container or bag that's used to keep items while not in use in a visible location like the middle of a desk.
|
||||
|
||||
## Procedure
|
||||
|
||||
{{ #include template-ceremony-setup.md:content }}
|
||||
|
||||
1. Retrieve Ceremony SD Card from High Visibility Storage and plug it into the machine
|
||||
|
||||
1. Copy the Ceremony SD Card contents to machine
|
||||
|
||||
* `cp -r /media/vaults /root/`
|
||||
|
||||
1. Start `keyfork` using the relevant Shardfile:
|
||||
|
||||
* `keyfork recover shard --daemon /root/vaults/<namespace>/shardfile.asc`
|
||||
|
||||
* Follow on screen prompts
|
||||
|
||||
1. Derive the OpenPGP root certificate:
|
||||
|
||||
* `keyfork derive openpgp > secret_key.asc`
|
||||
|
||||
1. Decrypt the secret material:
|
||||
|
||||
* `sq decrypt --recipient-file secret_key.asc < encrypted.asc --output decrypted`
|
||||
|
||||
1. Proceed to transfer the secret (`decrypted`) to desired location such as hardware wallet, power washed chromebook (via SD card) etc.
|
||||
|
||||
1. Shut down the air gapped machine
|
||||
|
||||
1. Gather all the original items that were in the air-gapped bundle:
|
||||
|
||||
* Air-gapped computer
|
||||
|
||||
* AirgapOS SD card
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
# Encrypt Wallet to Namespace Key
|
||||
|
||||
Procedure for importing an arbitrary secret (raw key, mnemonic, state secrets) into a Namespace.
|
||||
|
||||
## Requirements
|
||||
|
||||
* [Namespace OpenPGP Certificate]()
|
||||
|
||||
* It can be on an SD card or accessed online
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Access machine which has the secret that should be encrypted available
|
||||
|
||||
* If not on a computer, but a hardware wallet or otherwise, perform the steps on a air-gapped machine
|
||||
|
||||
1. Encrypt the secret to certificate:
|
||||
|
||||
* `sq encrypt --for-file <certificate> <file_to_encrypt> --output encrypted.asc`
|
||||
|
||||
1. Once encrypted, name the file appropriately and add it to an `artifacts/` directory in the appropriate namespace subdirectory in the `vaults` repository
|
||||
|
||||
{{ #include ../../../../component-documents/git-basics.md:content }}
|
||||
|
||||
|
|
@ -1,59 +0,0 @@
|
|||
# Export Namespace Mnemonic
|
||||
|
||||
## Requirements
|
||||
|
||||
{{ #include ../../operator-requirements.md:requirements }}
|
||||
|
||||
* [SD Card Pack](../procurer/procure-sd-card-pack.md)
|
||||
|
||||
* [Ceremony SD Card](../operator/ceremony-sd-card-provisioning.md)
|
||||
|
||||
* [High Visibility Storage](TODO): plastic container or bag that's used to keep items while not in use in a visible location like the middle of a desk.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Enter the designated location with the quorum of operators and all required equipment
|
||||
|
||||
1. Lock access to the location - there should be no inflow or outflow of people during the ceremony
|
||||
|
||||
1. Place Ceremony SD card in High Visibility Storage
|
||||
|
||||
1. Retrieve sealed Air-Gapped bundle, polaroid of tamper evidence, and online laptop from locked storage
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
1. Place all contents except for the laptop into High Visibility Storage
|
||||
|
||||
1. Retrieve AirgapOS SD card and plug it into the air-gapped machine
|
||||
|
||||
1. Boot the computer
|
||||
|
||||
1. Unplug the AirgapOS SD card and place it in High Visibility Storage
|
||||
|
||||
1. Retrieve Ceremony SD card from High Visibility Storage and plug it into the air-gapped machine
|
||||
|
||||
1. Recover the mnemonic from an existing shardfile
|
||||
|
||||
* `keyfork shard combine /media/vaults/<namespace>/shardfile.asc | keyfork-mnemonic-from-seed > mnemonic.txt`
|
||||
|
||||
1. Follow on screen prompts
|
||||
|
||||
1. Unplug the Ceremony SD card and place it in High Visibility Storage
|
||||
|
||||
1. Unseal the SD Card Pack
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
1. Put the mnemonic on an SD card for transport or use `cat` command to output it in the terminal for entry into a hardware wallet or otherwise
|
||||
|
||||
* WARNING: if displaying on screen, ensure nothing else can see the mnemonic. It is recommended to cover the operator and the machine with a blanket to obstruct the view of the screen.
|
||||
|
||||
1. Shut down the air gapped machine
|
||||
|
||||
1. Gather all the original items that were in the air-gapped bundle:
|
||||
|
||||
* Air-gapped computer
|
||||
|
||||
* AirgapOS SD card
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
# Operator
|
||||
|
||||
## Responsibilities
|
||||
|
||||
* Executing ceremonies
|
||||
|
||||
* Managing Shard-bearer PGP keys
|
||||
|
||||
* In addition to signing material, these keys are used for decrypting shards
|
||||
|
||||
|
||||
|
|
@ -1,66 +0,0 @@
|
|||
# Namespace Entropy Ceremony
|
||||
|
||||
This is a ceremony for generating and sharding entropy to a set of existing Quorum Keys.
|
||||
|
||||
## Requirements
|
||||
|
||||
{{ #include ../../operator-requirements.md:requirements }}
|
||||
|
||||
* [SD Card Pack](../procurer/procure-sd-card-pack.md)
|
||||
|
||||
* [Ceremony SD Card](../operator/ceremony-sd-card-provisioning.md)
|
||||
|
||||
* [High Visibility Storage](TODO): plastic container or bag that's used to keep items while not in use in a visible location like the middle of a desk.
|
||||
|
||||
## Procedure
|
||||
|
||||
{{ #include template-ceremony-setup.md:content }}
|
||||
|
||||
1. Plug the Ceremony SD card into the machine
|
||||
|
||||
1. Run the command to generate new entropy and shard it to quorum of public certificates of the input shardfile:
|
||||
|
||||
* Replace the values: <path_to_input_shard>
|
||||
|
||||
* `keyfork mnemonic generate --shard-to <path_to_input_shard>,output=shardfile.asc --encrypto-to-self encryption_certificate.asc,userid=<namespace>`
|
||||
|
||||
1. Unseal an SD card pack
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
1. Place all unsealed SD cards into High Visibility Storage
|
||||
|
||||
1. Plug in the Ceremony SD card
|
||||
|
||||
1. Back up the files
|
||||
```
|
||||
$ cp shardfile.asc /media/vaults/<namespace>/
|
||||
TODO (NOT IMPLEMENTED): $ cp encryption_certificate.asc /media/vaults/<namespace>/
|
||||
$ cp -r /media/vaults /root/
|
||||
```
|
||||
1. To create additional backups of the updated `vaults` repository, plug in SD cards one at a time and use following steps to back up ceremony artifacts
|
||||
|
||||
1. Plug in fresh SD card
|
||||
|
||||
1. `cp -r /root/vaults /media/`
|
||||
|
||||
1. Unplug the SD card
|
||||
|
||||
1. Label the SD card "Ceremony [date]"
|
||||
|
||||
1. Place the SD caard in High Visibility Storage
|
||||
|
||||
1. Power down the air-gapped machine
|
||||
|
||||
1. Transfer the ceremony artifacts to an online machine using one of the SD cards and commit the changes made to the `vaults` repository that's on the Ceremony SD card
|
||||
|
||||
{{ #include ../../../../component-documents/git-basics.md:content }}
|
||||
|
||||
1. Gather all the original items that were in the air-gapped bundle:
|
||||
|
||||
* Air-gapped computer
|
||||
|
||||
* AirgapOS SD card
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
# Quorum Entropy Ceremony
|
||||
|
||||
This is a ceremony for generating entropy which is used to derive Quorum PGP keys, load them into smart cards and shard entropy to them.
|
||||
|
||||
## Requirements
|
||||
|
||||
{{ #include ../../operator-requirements.md:requirements }}
|
||||
|
||||
* [Ceremony SD Card](./ceremony-sd-card-provisioning.md)
|
||||
|
||||
* [SD Card Pack](../procurer/procure-sd-card-pack.md)
|
||||
|
||||
* `N` Smart Cards in the chosen `M of N` quorum
|
||||
|
||||
* High Visibility Storage: plastic container or bag that's used to keep items while not in use in a visible location like the middle of a desk.
|
||||
|
||||
## Procedure
|
||||
|
||||
{{ #include template-ceremony-setup.md:content }}
|
||||
|
||||
1. Run the relevant keyfork wizard to perform the ceremony:
|
||||
|
||||
* Replace the following values: \<M>, \<N>, <number_of_smart_cards_per_operator>, <pgp_cert_id> with appropriate values
|
||||
|
||||
* `keyfork wizard generate-shard-secret --threshold <M> --max <N> --keys-per-shard=<number_of_smartcards_per_operator> --output shardfile.asc --cert-output keyring.asc`
|
||||
|
||||
* TODO - NOT IMPLEMENTED:
|
||||
`--derive-openpgp-cert encryption_cert.asc,userid=<pgp_cert_id>`
|
||||
|
||||
1. Unseal an SD card pack by following tamper proofing steps:
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
1. Place all unsealed SD cards into High Visibility Storage
|
||||
|
||||
1. Plug in the Ceremony SD card
|
||||
|
||||
1. Back up the files
|
||||
```
|
||||
$ cp shardfile.asc /media/vaults/<namespace>/
|
||||
$ cp keyring.asc /media/vaults/<namespace>/
|
||||
TODO (NOT IMPLEMENTED): $ cp encryption_cert.asc /media/vaults/<namespace>/
|
||||
$ cp -r /media/vaults /root/
|
||||
```
|
||||
|
||||
1. To create additional backups of the updated `vaults` repository, plug in SD cards one at a time and use following steps to back up ceremony artifacts
|
||||
|
||||
1. Plug in fresh SD card
|
||||
|
||||
1. `cp -r /root/vaults /media/`
|
||||
|
||||
1. Unplug the SD card
|
||||
|
||||
1. Label the SD card "Ceremony [date]"
|
||||
|
||||
1. Place the SD card in High Visibility Storage
|
||||
|
||||
1. Power down the air-gapped machine
|
||||
|
||||
1. Transfer the ceremony artifacts to an online machine using one of the SD cards and commit the changes made to the `vaults` repository that's on the Ceremony SD card
|
||||
|
||||
{{ #include ../../../../component-documents/git-basics.md:content }}
|
||||
|
||||
1. Gather all the original items that were in the air-gapped bundle:
|
||||
|
||||
* Air-gapped computer
|
||||
|
||||
* AirgapOS SD card
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
// ANCHOR: content
|
||||
1. Enter the designated location with required personnel and equipment
|
||||
|
||||
1. Lock access to the location - there should be no inflow or outflow of people during the ceremony
|
||||
|
||||
1. Retrieve Air-Gapped Bundle and polaroid tamper evidence from locked storage
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
1. Place all materials except for the laptop into High Visibility Storage
|
||||
|
||||
1. Retrieve AirgapOS SD card from High Visibility Storage and plug it into air-gapped laptop
|
||||
|
||||
1. Turn on the machine
|
||||
|
||||
1. Once booted, remove the AirgapOS SD card and place it into High Visibility Storage
|
||||
// ANCHOR_END: content
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
# Create Inventory Repository
|
||||
|
||||
{{ #include ../../../../component-documents/inventory-repository.md:content }}
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
# Procurer
|
||||
|
||||
The procurer is responsible for:
|
||||
|
||||
* Procuring equipment
|
||||
|
||||
* [Tamper proofing equipment](procure-tamper-proofing-equipment.md)
|
||||
|
||||
* [Hardware](procure-hardware.md) (computers, sd cards, sd card adapters, smart cards, cameras etc.)
|
||||
|
||||
* Creating and maintaining the [Inventory](create-inventory-repository.md)
|
||||
|
||||
* Ensuring equipment is properly tamper proofed
|
||||
|
||||
* Minimizing hardware supply chain security risks
|
||||
|
||||
## Order of Operations
|
||||
|
||||
1. Provisioning [Personal PGP Keys](../../../all-levels/pgp-key-provisioning.md)
|
||||
|
||||
1. Procuring a [facility](./procure-facility.md)
|
||||
|
||||
1. Creating a [Inventory repository](create-inventory-repository.md)
|
||||
|
||||
1. Procuring [tamper proofing equipment](./procure-tamper-proofing-equipment.md)
|
||||
|
||||
1. Procuring [hardware](./procure-hardware.md)
|
||||
|
||||
* Laptops
|
||||
|
||||
* SD cards
|
||||
|
||||
* SD card USB adapters
|
||||
|
||||
* Smart cards
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
# Procure 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
|
||||
|
|
@ -1,55 +0,0 @@
|
|||
# Hardware Procurement
|
||||
|
||||
## Requirements
|
||||
|
||||
{{ #include ../../basic-requirements.md:requirements }}
|
||||
|
||||
* Sealable plastic bag is required for this procedure:
|
||||
|
||||
* {{ #include ../../../../component-documents/hardware-models.md:sealable-plastic-bags }}
|
||||
|
||||
## Procedure: Local Procurement
|
||||
|
||||
{{ #include ../../../../component-documents/hardware-procurement-and-chain-of-custody.md:steps}}
|
||||
|
||||
## Procedure: Online Procurement
|
||||
|
||||
1. Select a well known and reputable supplier. Establishing a relationship with a hardware supplier that has a reputation for privacy, supply chain security is preferred.
|
||||
|
||||
2. Order the supplies to a registered mailbox, to prevent exposing your organization's location
|
||||
|
||||
## Tamper Proofing
|
||||
|
||||
All hardware:
|
||||
|
||||
* MUST be procured using dual custody methods
|
||||
|
||||
* MUST be tamper proofed using vacuum sealing / stored in tamper evident vault
|
||||
|
||||
* MUST be properly labelled
|
||||
|
||||
* MUST be added to cryptographically signed inventory
|
||||
|
||||
### Procedure
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing }}
|
||||
|
||||
## Equipment Models
|
||||
|
||||
### Computers Models
|
||||
|
||||
For [Level 2](../../../../threat-model.md#level-2) security, air-gapped computers which are used for cryptographic material management and operations are required.
|
||||
|
||||
{{ #include ../../hardware.md:computer-models }}
|
||||
|
||||
### SD Cards & Adapters
|
||||
|
||||
SD cards can be tamper proofed in packs of 4 to reduce the amount of tamper proofing that needs to be done.
|
||||
|
||||
Any high quality SD equipment can be used but below are some recommended products:
|
||||
|
||||
{{ #include ../../../../component-documents/hardware-models.md:sd-models }}
|
||||
|
||||
### Smart Cards
|
||||
|
||||
{{ #include ../../../../component-documents/hardware-models.md:smart-cards }}
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
# Procure SD Card Pack
|
||||
|
||||
## Requirements
|
||||
|
||||
{{ #include ../../basic-requirements.md:requirements }}
|
||||
|
||||
* 5 Fresh SD card(s) per booster pack
|
||||
|
||||
* High Visibility Storage
|
||||
|
||||
* Sealable plastic bag is required for this procedure:
|
||||
|
||||
* {{ #include ../../../../component-documents/hardware-models.md:sealable-plastic-bags }}
|
||||
|
||||
|
||||
## Procedure
|
||||
|
||||
{{ #include ../../../../component-documents/hardware-procurement-and-chain-of-custody.md:steps}}
|
||||
|
||||
1. Remove packaging from each SD card, and place them into High Visibility Storage
|
||||
|
||||
1. Select 5 SD cards to be tamper proofed from High Visibility Storage
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing }}
|
||||
|
||||
1. Label the tamper proofed package "SD Card Pack [date]"
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
# Procure Tamper Proofing Equipment
|
||||
|
||||
The facility will require tamper proofing equipment which will be used to tamper proof items before they are stored in inventory.
|
||||
|
||||
These items don't require dual custody and can be purchased at any location.
|
||||
|
||||
### Vacuum Sealer, plastic roll, filler
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-equipment}}
|
||||
|
||||
### Digital camera
|
||||
|
||||
{{ #include ../../hardware.md:camera-models}}
|
||||
|
||||
### Polaroid camera
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:polaroid-cameras}}
|
||||
|
||||
### Label Printer
|
||||
|
||||
There are two options:
|
||||
|
||||
* Hand-held label printer with a built in keyboard
|
||||
|
||||
* Non-standalone label printer that needs a computer to send it the file to print
|
||||
|
||||
#### Examples
|
||||
|
||||
* [Brother P-Touch PT- D610BT Business Professional Connected Label Maker ](https://www.amazon.com/Brother-Business-Professional-Connected-Bluetooth%C2%AE/dp/B0B1KZJXPG/ref=sr_1_4)
|
||||
|
||||
* [Bluetooth Thermal Label Printer](https://www.amazon.com/LabelRange-Bluetooth-Wireless-Shipping-Packages/dp/B0DFC9GB5D/ref=sr_1_1_sspa)
|
||||
|
|
@ -1,117 +0,0 @@
|
|||
# Proposer - Create Transaction Payload
|
||||
|
||||
The proposer is a fiduciary whose responsibility is to make sound financial decisions on behalf of a business and determine where funds are moving from, where to and in which amount. The reasons for sending funds may range across settlement, exchanging, staking and more.
|
||||
|
||||
The proposer MUST include the workflow type and all arguments required by a workflow, such as `from_address`, `to_address`, `asset_name`, etc., as well as a UTC datetime representing the time when the transaction is proposed.
|
||||
|
||||
The proposer must combine these values into a JSON file, such as:
|
||||
|
||||
```json
|
||||
{
|
||||
"workflow": ["cosmos", "withdraw"],
|
||||
"values": {
|
||||
"delegate_address": "kyve1q9w3nar74up6mxnwd428wpr5nffcw3360tkxer",
|
||||
"validator_address": "kyvevaloper1ghpmzfuggm7vcruyhfzrczl4aczy8gas8guslh",
|
||||
"asset_name": "KYVE",
|
||||
"asset_amount": "0.4",
|
||||
"chain_name": "korellia"
|
||||
},
|
||||
"proposal_datetime": "2025-01-28T18:18:00"
|
||||
}
|
||||
```
|
||||
|
||||
## Requirements
|
||||
|
||||
* [Quorum PGP Key](../operator/quorum-entropy-ceremony.md)
|
||||
|
||||
* [Air-Gapped Bundle](../provisioner/air-gapped-bundle.md)
|
||||
|
||||
* The proposer 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 proposer should verify the commit signatures of the photographs they are printing against a list of permitted PGP keys found in the `vaults` repo
|
||||
|
||||
{{ #include ../../../../component-documents/linux-workstation.md:content }}
|
||||
|
||||
* Clone the [Vaults Repository](../../../all-levels/create-vaults-repository.md) for your organization to the machine
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Turn on online machine
|
||||
|
||||
1. Clone the `vaults` repository if it's not available locally and get the latest changes:
|
||||
```
|
||||
$ git clone <repository_git_url>
|
||||
$ git pull origin main
|
||||
```
|
||||
1. Unseal the SD Card Pack
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
1. Plug a fresh SD card into the online machine
|
||||
|
||||
1. {{ #include ../../../../component-documents/finding-device-name.md:content }}
|
||||
|
||||
1. Save the `vaults` repo to the SD card, referred to as the Ceremony SD card
|
||||
|
||||
* `cp -r ~/vaults/ /media`
|
||||
|
||||
1. Unplug the Ceremony SD card
|
||||
|
||||
1. Unseal the tamper proofed bundle
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing}}
|
||||
|
||||
1. Insert the AirgapOS SD card into the airgapped machine and turn it on
|
||||
|
||||
1. Once booted, unplug the AirgapOS SD card and place it in High Visibility Storage
|
||||
|
||||
1. Plug in the Ceremony SD card
|
||||
|
||||
1. Copy the git repo locally from the Ceremony SD card and change to it
|
||||
```
|
||||
$ cp -r /media/vaults /root
|
||||
$ cd /root/vaults
|
||||
```
|
||||
1. Create a new payloads directory in the `vaults` repository for the date on which the ceremony for the transaction will take place if it doesn't already exist
|
||||
|
||||
* `mkdir -p <namespace>/ceremonies/<date>/payloads`
|
||||
|
||||
* e.g `mkdir -p solana-01/ceremonies/2025-01-01/payloads`
|
||||
|
||||
1. Use `icepick workflow --help` to list the available workflows and options
|
||||
|
||||
1. Plug in the Operator smart card
|
||||
|
||||
1. Use icepick to generate and sign the payload:
|
||||
|
||||
* `icepick workflow <chain> <workflow> <--option value> <--option value> --export-for-quorum --sign > <output_file>`
|
||||
|
||||
* e.g `icepick workflow cosmos withdraw-rewards --delegate-address kyve1q9w3nar74up6mxnwd428wpr5nffcw3360tkxer --validator-address kyvevaloper1ghpmzfuggm7vcruyhfzrczl4aczy8gas8guslh --chain-name korellia --export-for-quorum --sign > <namespace>/ceremonies/<date>/payloads/payload_<num>.json`
|
||||
|
||||
* e.g `icepick workflow sol transfer --from-address "$(cat <namespace>/<coin>/0.txt)" --to-address "$(cat to_address.txt)" --amount <amount> --export-for-quorum --sign > <namespace>/ceremonies/<date>/payloads/payload_<num>.json`
|
||||
|
||||
1. Copy the updated ceremonies repo to the SD card
|
||||
|
||||
* `cp -r /root/vaults /media`
|
||||
|
||||
1. Transfer the SD card from the air-gapped machine to the online machine
|
||||
|
||||
1. {{ #include ../../../../component-documents/finding-device-name.md:content }}
|
||||
|
||||
1. Copy the updated repository locally and switch to it:
|
||||
```
|
||||
$ cp -r /media/vaults ~/
|
||||
$ cd ~/vaults
|
||||
```
|
||||
1. Stage, sign, commit and push the changes to the ceremonies repository:
|
||||
```
|
||||
$ git add <namespace>/ceremonies/<date>/payloads/*
|
||||
$ git commit -S -m "add payload signature for payload_<num>.json"
|
||||
$ git push origin main
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
1. Tamper proof the AirgapOS and Air-gapped laptop
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
# Air-Gapped Bundle
|
||||
|
||||
## Requirements
|
||||
|
||||
{{ #include ../../basic-requirements.md:basic }}
|
||||
|
||||
* AirgapOS SD Card
|
||||
|
||||
* Air-gapped computer
|
||||
|
||||
## Procedure
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing}}
|
||||
|
||||
1. Label the tamper proofed package as "Air-Gapped Bundle [num]", for example "Air-Gapped Bundle 2" if one already exists
|
||||
|
||||
1. Update inventory to indicate a new air-gapped bundle is available
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
# Provisioner
|
||||
|
||||
The provisioner is responsible for:
|
||||
|
||||
* Provisioning hardware
|
||||
|
||||
* Provisioning SD Cards (AirapOS, Ceremony etc.)
|
||||
|
||||
* Provisioning bundles (e.g Air-Gapped bundle)
|
||||
|
||||
## Procedures
|
||||
|
||||
* [Provision AirgapOS](./provision-airgapos.md)
|
||||
* [Provision Computer](./procure-computer.md)
|
||||
* Requires tamper proofing equipment to be available
|
||||
* [Provision Air Gapped Bundle](./provision-air-gapped-bundle.md)
|
||||
* Requires operators to have smart cards with PGP keys, tamper proofing equipment, AirgapOS SD card
|
||||
|
|
@ -1,61 +0,0 @@
|
|||
# AirgapOS
|
||||
|
||||
## Requirements
|
||||
|
||||
{{ #include ../../basic-requirements.md:requirements }}
|
||||
|
||||
* Tamper proofing evidence (photographs)
|
||||
|
||||
* [SD Card Pack(s)](../procurer/procure-sd-card-pack.md)
|
||||
|
||||
* High Visibility Storage
|
||||
|
||||
* 2 Computers
|
||||
|
||||
* 1 computer should be able to boot AirgapOS ([compatibility reference](https://git.distrust.co/public/airgap#tested-models))
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Turn on one of the computers - this one will be used for writing the SD cards
|
||||
|
||||
1. Build the software according to the [readme](https://git.distrust.co/public/airgap) in the repository.
|
||||
|
||||
1. Use the `make reproduce` command
|
||||
|
||||
1. Unseal the SD Card Pack
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing }}
|
||||
|
||||
1. Label each SD card that will be used "AirgapOS [date]"
|
||||
|
||||
1. Place all the SD cards into High Visibility Storage
|
||||
|
||||
1. Retrieve a labelled SD card from High Visibility Storage, and plug it into the computer where AirgapOS will be built
|
||||
|
||||
1. {{ #include ../../../../component-documents/finding-device-name.md:content }}
|
||||
|
||||
1. Flash `airgap.iso` to an SD Card:
|
||||
|
||||
* `dd if=out/airgap.iso of=/dev/<device_name> bs=4M status=progress conv=fsync`
|
||||
|
||||
1. Reset the computer, and boot the SD card
|
||||
|
||||
1. Once booted, the card needs to be locked using `sdtool` which is available in `AirgapOS`:
|
||||
|
||||
* Note: the device will not mount as a proper block device on QubesOS so a different OS has to be used where the device appears as /dev/mmcblk<num>
|
||||
|
||||
1. `./sdtool /dev/<device_name> permlock`
|
||||
|
||||
1. Once burned, unplug the SD card
|
||||
|
||||
1. Plug the SD card into a different computer from the one that was used to write the SD card
|
||||
|
||||
1. Boot the computer
|
||||
|
||||
1. Open a terminal
|
||||
|
||||
1. Verify the card can't be written to:
|
||||
|
||||
* `echo "42" | dd of=/dev/<device_name>`
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing }}
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
# Provision Ceremony Repository
|
||||
|
||||
{{ #include ../../../../component-documents/vaults-repository.md:content }}
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
# Provision Computer
|
||||
|
||||
## Requirements
|
||||
|
||||
{{ #include ../../basic-requirements.md:requirements }}
|
||||
|
||||
* Tamper proofing evidence (photographs)
|
||||
|
||||
* Non-provisioned computer
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Unseal a tamper proofed laptop
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-unsealing }}
|
||||
|
||||
1. Remove all radio cards, storage drive, speakers, and microphone using standard industry laptop repair tactics
|
||||
|
||||
{{ #include ../../../../component-documents/tamper-evidence-methods.md:vsbwf-procedure-sealing }}
|
||||
|
||||
1. Apply a new label which indicates the laptop has been provisioned (include date, and any other desired metadata such as a unique ID (e.g Laptop #4))
|
||||
|
||||
1. Place the provisioned laptop in inventory
|
||||
|
||||
1. Update inventory to reflect that this hardware has been provisioned, and including the metadata in the `description.txt` for that item according to the [inventory repository structure](../procurer/create-inventory-repository.md)
|
||||
|
|
@ -1,47 +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
|
||||
* [Disassembly Manual](https://www.insidemylaptop.com/how-to-disassemble-lenovo-ideapad-flex-5-1470-model-81c9/)
|
||||
|
||||
* [Purism Librem 14](https://puri.sm/products/librem-14/)
|
||||
|
||||
* [Nova Custom](https://novacustom.com/de/) (Untested)
|
||||
|
||||
* [NitroPad](https://shop.nitrokey.com/shop?&search=nitropad) (Untested)
|
||||
|
||||
* Computers which are compatible which can be verified via [this guide](https://git.distrust.co/public/airgap#hardware-compatibility)
|
||||
|
||||
// ANCHOR_END: computer-models
|
||||
|
||||
## Digital Camera
|
||||
// ANCHOR: camera-models
|
||||
|
||||
* MUST have >10MP
|
||||
|
||||
// ANCHOR_END: camera-models
|
||||
|
||||
### Models
|
||||
// ANCHOR:digital-cameras
|
||||
|
||||
* Modern phone cameras
|
||||
|
||||
* [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)
|
||||
|
||||
* [Sony Cyber-Shot DSC-W800](https://www.amazon.com/Sony-DSCW800-Digital-Camera-Black/dp/B00I8BIBCW)
|
||||
|
||||
// ANCHOR_END:digital-cameras
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
/* ANCHOR: all */
|
||||
# Base Requirements
|
||||
|
||||
## For Quorum Based Operations
|
||||
// ANCHOR: requirements
|
||||
|
||||
* For ALL tamper proofed hardware used in the ceremony, both operators MUST 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 found in the "ceremonies" repo
|
||||
|
||||
* [AirgapOS SD card](/generated-documents/level-2/fixed-location/provisioner/provision-airgapos.md)
|
||||
* Provided by [AirGapped Bundle](/generated-documents/level-2/fixed-location/provisioner/air-gapped-bundle.md)
|
||||
* Alternative: Create your own from documentation in [AirgapOS Repository](https://git.distrust.co/public/airgap)
|
||||
|
||||
* AirgapOS Laptop
|
||||
* Provided by [AirGapped Bundle](/generated-documents/level-2/fixed-location/provisioner/air-gapped-bundle.md)
|
||||
* Alternative: Computer that can load AirgapOS ([compatibility reference](https://git.distrust.co/public/airgap#tested-models))
|
||||
|
||||
* Minimum of 1 [Operator](/system-roles.md#operator) and 1 [Witness](/system-roles.md#witness)
|
||||
|
||||
* [Personal PGP key pair](/key-types.md#personal-pgp-keypair) for each operator
|
||||
|
||||
* Tamper-proofing equipment
|
||||
|
||||
// ANCHOR_END: requirements
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
# Key Types
|
||||
|
||||
## Personal PGP Keypair
|
||||
|
||||
Used for day to day operations such as signing keys being added to keychain, signing tamper evidence, signing transaction requests and approvals etc.
|
||||
|
||||
When bootstrapping a system, the initial PGP keys can be generated using [this guide](./generated-documents/all-levels/pgp-key-provisioning.md).
|
||||
|
||||
### Requirements
|
||||
|
||||
* MUST not be transferred
|
||||
|
||||
* MUST be generated offline
|
||||
|
||||
* MUST have the root key offline
|
||||
|
||||
* MUST have subkeys maintained on a smartcard
|
||||
|
||||
## Quorum PGP Keypair
|
||||
|
||||
Only used in ceremonies for decrypting shardfile material.
|
||||
|
||||
### Requirements
|
||||
|
||||
* MUST use smart-card within air-gapped ceremonies
|
||||
|
||||
* MUST not have PII attached to them
|
||||
|
||||
* MUST be generated in a witnessed ceremony
|
||||
|
||||
* MUST only be backed up to a quorum
|
||||
|
||||
* MUST not be transferred in level 4
|
||||
|
||||
* MAY be transferred in levels 1-3
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
# One Time Use Laptop Ceremony
|
||||
|
||||
## Threat Model
|
||||
|
||||
One time use laptops are specially prepared for using in field operation but can also be used inside of a secure facility. The primary objective of this setup is that the laptop is provisioned ahead of time, and is considered to be secure for use, but is to be destroyed afterwards.
|
||||
|
||||
This flow is the same as [portable reusable laptop ceremony](portable-reusable-laptop-ceremony.md) except instead of tamper proofing the hardware at the end of the ceremony, it is destroyed.
|
||||
|
|
@ -1,39 +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. {{ #include finding-device-name.md:content }}
|
||||
|
||||
* Note: the device will not mount as a proper block device on QubesOS so a different OS has to be used where the device appears as /dev/mmcblk<num>
|
||||
|
||||
1. `./sdtool /dev/<device_name> permlock`
|
||||
|
||||
1. Test that the card can't be written to:
|
||||
|
||||
* Create a test file:
|
||||
|
||||
* `echo "test" > test.txt`
|
||||
|
||||
* Try writing the file to the SD card
|
||||
|
||||
* `dd if=./test.txt of=/dev/<device_name> bs=1M conv=sync status=progress`
|
||||
|
||||
// ANCHOR_END: steps
|
||||
/* ANCHOR_END: all */
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
# Side Channel Attacks
|
||||
|
||||
* Acoustic (DiskFiltration, Fansmitter, Acoustic Cryptanalysis, sonic cavity resonators, etc.)
|
||||
|
||||
* Optical (VisiSploit, xLED, eavesdropping via vibration analysis etc.)
|
||||
|
||||
* Thermal (BitWhisper)
|
||||
|
||||
* Electrical (Simple Power Analysis (SPA), Differential Power Analysis)
|
||||
|
||||
* Magnetic (ODINI)
|
||||
|
||||
* Electromagnetic (USBee)
|
||||
* Exfiltrating data via induction of power lines, water pipes, telephone lines, coaxial cable used for televisions and internet etc.
|
||||
|
||||
* Radio (NFCDrip, Vapor Trail, RFID, FM, Wifi, Bluetooth, GSM, SATA cable eavesdropping etc)
|
||||
|
||||
* Steganography
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
# System Roles
|
||||
|
||||
There are several roles which are required to properly operate the QVS system. While it is possible to have an individual perform multiple roles, typically they should only perform one role at a time. It is also recommended to have at least 2 individuals, or ideally the full quorum be used to make decisions pertaining to QVS. At least 2 individuals are required for [level 2](threat-model.md#adversary-1).
|
||||
|
||||
To better understand why the different roles are required, refer to the [selecting a quorum](selecting-quorum.md) and [threat model](threat-model.md) sections which enumerate a number of assumptions around pertinent threats to the system as well as the use of a quorum.
|
||||
|
||||
## General Requirements
|
||||
|
||||
Individuals who are selected for the roles:
|
||||
|
||||
* MUST have background checks conducted
|
||||
|
||||
* MUST have a clearly defined set of responsibilities
|
||||
|
||||
* MUST be reinvestigated once a year to ensure they meet necessary standards to access restricted information
|
||||
|
||||
## Provisioner
|
||||
|
||||
Responsible for more technical aspects of preparing equipment for ceremonies such as creating air-gapped machines by removing radio cards, and tamper proofing them along with SD cards which are loaded with AirgapOS etc.
|
||||
|
||||
## Procurer
|
||||
|
||||
Responsible for tasks such as procuring a location, tamper proofing equipment, hardware, and maintaining inventory.
|
||||
|
||||
## Proposer
|
||||
|
||||
This is an individual who is a business owner or stakeholder, or a financial controller. Their role is to make fiduciary decisions which protect the financial interest of the organization and its clients. Their role is specifically to propose the movement of funds, specifying the amount, origin and destination.
|
||||
|
||||
## Approver
|
||||
|
||||
This is an administrative role which participates in the decision making capacity, typically as part of a quorum. Additional policies which are not for the QVS system but related decision making may be under the purview of an Approver. While there is 1 proposer per transaction, there may be an arbitrary number of Approvers, and they are required to sign proposed transactions according to a [policy](todo) which should be well defined.
|
||||
|
||||
## 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.
|
||||
|
||||
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.
|
||||
|
||||
As a QVS grows, it may be prudent to create more highly specialized roles whose responsibilities are limited to a more narrow range, creating more isolation across the system, thus enforcing the principle of least privilege and separation of concerns.
|
||||
|
||||
## Witness
|
||||
|
||||
QVS relies of having individuals present to witness that processes which uphold the security of the system are properly followed. [Operators](#operator) make ideal witnesses as their familiarity with the QVS system allows them to detect any deviation from the processes which uphold the security of the system. While it is not required that a Witness be a trained Operator, it is highly preferred.
|
||||
|
|
@ -1,405 +0,0 @@
|
|||
# Threat Model
|
||||
|
||||
QVS is designed according to a high-assurance threat model which ers on the
|
||||
side of making exaggerated, rather than conservative assumptions in order to
|
||||
build a resilient system.
|
||||
|
||||
The assumption is made that attackers who target QVS are extremely
|
||||
sophisticated, well funded and patient attackers, and as such, the full arsenal
|
||||
of attacks is on the table. This means that the attacker can purchase and
|
||||
weaponize multiple 0day vulnerabilities, execute physical attacks or deploy
|
||||
moles, target different supply chains of software, firmware and hardware used,
|
||||
and generally attack the system using an array of known and unknown attacks.
|
||||
|
||||
One of the guiding principles in the design is the elimination of Single Points
|
||||
of Failure (SPOFs), and relies on a number of different control mechanisms which
|
||||
help reduce risk of any one individual being able to compromise the system,
|
||||
whether it's maintainers of software used in the system, the firmware that's
|
||||
used, or the individuals or locations that hold secret material which is the
|
||||
backbone of the system.
|
||||
|
||||
To achieve this, the QVS focuses on reducing the risk by:
|
||||
|
||||
* Only using fully open source software and firmware to allow full verification
|
||||
of their security properties
|
||||
|
||||
* Creating custom purpose specific tooling which eliminates dependencies in
|
||||
order to reduce supply chain attacks, and adds desirable security properties
|
||||
|
||||
* Building as much of the software and firmware deterministically as possible - aiming for 100%
|
||||
|
||||
* The [StageX](https://codeberg.org/stagex/stagex) project is the effort towards this end
|
||||
|
||||
* Using computers which either have a hard switch for disabling networking or which had radio networking cards (bluetooth, wifi etc.) removed
|
||||
|
||||
* Leveraging smart cards (personal HSMs) to protect cryptographic material
|
||||
|
||||
* Leveraging cryptographic sharding in order to decentralize risk and physically separate cryptographic material
|
||||
|
||||
* Leveraging tamper evident controls for equipment
|
||||
|
||||
* Leveraging frequency blocking methods such as TEMPEST (Telecommunications Electronics Materials Protected from Emanating Spurious Transmissions) and soundproofing
|
||||
|
||||
## General Threat Model Assumptions
|
||||
|
||||
Some additional assumptions are made to help contextualize the threat model:
|
||||
|
||||
* All screens are visible to an adversary
|
||||
|
||||
* All keyboards are logging to an adversary
|
||||
|
||||
* Any firmware/boot-loaders not verified on every boot are compromised
|
||||
|
||||
* Any host OS with network access is compromised
|
||||
|
||||
* Any guest OS used for any purpose other than prod access is compromised
|
||||
|
||||
* At least one member of the Production Team is always compromised
|
||||
|
||||
* At least one maintainer of third party used in the system is compromised
|
||||
|
||||
* Physical attacks are viable and likely
|
||||
|
||||
* Side-channel attacks are viable and likely
|
||||
|
||||
## Threat Model Levels
|
||||
|
||||
Different threat model levels allow an organization to start benefiting from the security properties of the QVS system immediately, with a clear path to upgrading over time as resources and time become available.
|
||||
|
||||
Each subsequent level assumes all threats and mitigations from the previous level, and introduces more sophisticated attacks and mitigations. As such, the levels should for the most part be adhered to one at a time, to ensure comprehensive defenses for all viable threats enumerated herein.
|
||||
|
||||
* [Level 1](#level-1)
|
||||
* [Level 2](#level-2)
|
||||
* [Level 3](#level-3)
|
||||
* [Level 4](#level-4)
|
||||
|
||||
|
||||
## Level 1
|
||||
|
||||
### Threat Model
|
||||
|
||||
#### Adversary
|
||||
|
||||
Low skilled individual targeting many organizations. This implies the adversary is not highly focused on compromising a specific organization, and relies on less sophisticated strategies.
|
||||
|
||||
This level focuses on defending against remote adversaries.
|
||||
|
||||
#### Attacks
|
||||
|
||||
* Using phishing to steal data from a random set of custodian end users
|
||||
|
||||
* Injecting malware into the system of a random set of custodian end users
|
||||
|
||||
#### Requirements
|
||||
|
||||
* MUST require hardware anchored login for large withdrawals
|
||||
|
||||
* MUST require hardware anchored signature for large withdrawal requests
|
||||
|
||||
* MUST verify withdrawal requests according to a threshold based policy
|
||||
|
||||
#### Reference Design
|
||||
|
||||
* Ensure all users withdrawing large sums over a short period of time are using FIDO2 or PGP capable smart cards for logging in and authorizing transactions:
|
||||
|
||||
* Hardware based WebAuthN/Passkey/U2F
|
||||
|
||||
* Android 7.0+, iOS 14+, MacOS 10.15+, Win10 1809+, ChromeOS, Yubikey 5, Nitrokey, Ledger, Trezor
|
||||
|
||||
* Consider software-based WebAuthN/Passkey/U2F as backup
|
||||
|
||||
* Ensure backend systems will only approve large withdrawals if signed by known smart card.
|
||||
|
||||
* Ensure all transaction approval keys are stored in a tamper evident append only database.
|
||||
|
||||
* To achieve this storage systems such as AmazonQLDB, git, Datomic etc. can be used
|
||||
|
||||
* Ensure all key additions are authenticated with a quorum of existing keys
|
||||
|
||||
* Consider allowing quorum of support engineer keys to enroll a new key to handle lost keys
|
||||
|
||||
* Use hash of transaction signing request as challenge to be signed by smart-card
|
||||
|
||||
* Blockchain signature only issued after verification a given request is signed by authorized user smart-card(s)
|
||||
|
||||
## Level 2
|
||||
|
||||
### Threat Model
|
||||
|
||||
#### Adversary
|
||||
|
||||
Adversary is a skilled and resourceful individual targeting one organization. This type of attacker uses a combination of widely used cyber weapons, OSINT, social engineering (spear phishing), exploiting vulnerabilities, MitM attacks.
|
||||
|
||||
This level focuses on defending against insider threats.
|
||||
|
||||
#### Attacks
|
||||
|
||||
* Compromise one team member with privileged access
|
||||
|
||||
* Inject code into any OSS library
|
||||
|
||||
* Exploit any vulnerability within 24h of public knowledge
|
||||
|
||||
### Requirements
|
||||
|
||||
* All production access:
|
||||
|
||||
* MUST NOT be possible by any single engineer
|
||||
|
||||
* Consider a bastion that can enforce m-of-n access over ssh
|
||||
|
||||
* Consider hardened deployment pipeline which requires m-of-n cryptographic signatures to perform action
|
||||
|
||||
* MUST be via dedicated tamper evident workstation
|
||||
|
||||
* Consider: https://github.com/hashbang/book/blob/master/content/docs/security/Production_Engineering.md
|
||||
|
||||
* MUST be anchored to keys in dedicated HSMs held by each administrator
|
||||
|
||||
* Consider OpenPGP or PKSC#11 smart cards that support touch-approval for ssh
|
||||
|
||||
* Any code in the transaction signing trust supply chain:
|
||||
|
||||
* MUST build deterministically
|
||||
|
||||
* MUST have extensive and frequent review
|
||||
|
||||
* MUST be signed in version control systems by well known author keys
|
||||
|
||||
* MUST be signed by separate subject matter expert after security review
|
||||
|
||||
* MUST hash-pin third party code at known reviewed versions
|
||||
|
||||
* MUST be at version with all known related security patches
|
||||
|
||||
* SHOULD be latest versions if security disclosures lag behind releases otherwise N-2
|
||||
|
||||
* MUST be built and signed (and hashes compared) by multiple parties with no management overlay
|
||||
|
||||
* Example: One build by IT, another by Infrastructure team managed CI/CD
|
||||
|
||||
* MUST be signed by well known keys signed by a common CA
|
||||
|
||||
* Example: OpenPGP smart cards signed under OpenPGP-CA.
|
||||
|
||||
* All private keys involved:
|
||||
|
||||
* MUST NOT ever come in contact with network accessible memory
|
||||
|
||||
* All execution environments MUST be able to attest what binary they run
|
||||
|
||||
* Examples:
|
||||
|
||||
* Custom Secure Boot verifies minimum signatures against CA
|
||||
|
||||
* Cloud enclave that can remotely attest it uses a multi-signed image
|
||||
|
||||
* TPM2, AWS Nitro Enclave, Google Shielded VMs etc.
|
||||
|
||||
* App phone stores already anchor to developer held signing keys
|
||||
|
||||
### Reference Design
|
||||
|
||||
* Create offline CA key(s)
|
||||
|
||||
* Consider OpenGPG key generated on airgap using keyfork, backed up, and copies transmitted to a smart cards such as a Yubikey
|
||||
|
||||
* CA key smart cards are stored in dual-access tamper evident locations
|
||||
|
||||
#### User Key Management System
|
||||
|
||||
* Enclave is created which is immutable with no ingress internet access
|
||||
|
||||
* Enclave has random ephemeral key
|
||||
|
||||
* Remotely attested on boot-up against multi-signed and known deterministically built system image
|
||||
|
||||
* Possible on many PCR based measured boot solutions based on TPM2 and Heads, AWS Nitro Enclaves, or GCP Shielded VMs
|
||||
|
||||
* Ephemeral enclave key is signed with offline CA key(s) on verification.
|
||||
|
||||
* Enclave has ability to validate append only database of keys
|
||||
|
||||
* Enclave will sign new key additions/removals with ephemeral key if:
|
||||
|
||||
* User has no prior keys
|
||||
|
||||
* Key was signed with an existing key
|
||||
|
||||
* Key was signed with 2+ known support engineer keys
|
||||
|
||||
#### Signing Key Generation
|
||||
|
||||
* M-of-N key holder quorum is selected
|
||||
|
||||
* SHOULD be on different teams
|
||||
|
||||
* SHOULD live in different geographical zones to mitigate natural disaster, and war related risks
|
||||
|
||||
* SHOULD have their own OpenPGP smart card with pin and keys only they control
|
||||
|
||||
* Shard keys
|
||||
|
||||
* SHOULD be an additional OpenPGP smart card separate from holder's personal key
|
||||
|
||||
* SHOULD have random PIN, encrypted to a backup shard holder
|
||||
|
||||
* SHOULD 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
|
||||
|
||||
* Has hardware anchor that can make all parties confident the OS image it is running is expected (Heads, etc)
|
||||
|
||||
* Has two hardware sources of entropy
|
||||
|
||||
* There are devices that can provide an additional source of entropy such as:
|
||||
|
||||
* Computer with another architecture such as RISC-V
|
||||
|
||||
* HSM which can export entropy
|
||||
|
||||
* Quantis QRNG USB
|
||||
|
||||
* TrueRNG
|
||||
|
||||
* Runs known deterministic and immutable OS image compiled by multiple parties
|
||||
|
||||
* Key is generated and stored
|
||||
|
||||
* Split to m-of-n Shamir's Secret Sharing shards
|
||||
|
||||
* Each shard is encrypted to dedicated shard OpenPGP smart card
|
||||
|
||||
* Shard smart card PIN is generated randomly
|
||||
|
||||
* Shard smart card PIN is encrypted to personal smart cards of primary and backup holders
|
||||
|
||||
#### Signing System
|
||||
|
||||
* Uses an enclave which is immutable with no ingress internet access
|
||||
|
||||
* Has enclave bound ephemeral key
|
||||
|
||||
* Remotely attested on boot-up against multi-signed and known deterministically built system image
|
||||
|
||||
* Will accept Shamir's Secret Sharing shards encrypted to enclave bound ephemeral key
|
||||
|
||||
* Will restore signing key to memory when sufficient shards are submitted
|
||||
|
||||
* Will only sign transactions if accompanied by signed request by authorized user according to a quorum specified by a policy
|
||||
|
||||
* Is able to validate signing request via CA key authorized user key management enclave signature
|
||||
|
||||
* Will only sign transactions that meet predefined size and rate limits by company policy and insurance levels
|
||||
|
||||
## Level 3
|
||||
|
||||
### Threat Model
|
||||
|
||||
#### Adversary
|
||||
Adversary is an organized group with significant funding. These groups consist of individuals with different skill sets and often have access to significant funds, drastically expanding their attack capabilities.
|
||||
|
||||
This level focuses on defending against adversaries who succeeded in local compromise.
|
||||
|
||||
#### Attacks
|
||||
|
||||
* Compromise one data center engineer into tampering with a target system
|
||||
|
||||
* Use a sophisticated 0 day vulnerability to compromise any one internet connected system
|
||||
|
||||
### Requirements
|
||||
|
||||
* MUST sign all transactions of significant value by multiple keys in separate geographical locations
|
||||
|
||||
* Consider well vetted open source multi signature, MPC or on-chain threshold signing software
|
||||
|
||||
* MUST use locations separated by hours of travel
|
||||
|
||||
* MUST have independent staff for separate locations
|
||||
|
||||
* Signing locations MUST NOT trust other locations
|
||||
|
||||
* Each location MUST do their own reproducible build validation
|
||||
|
||||
* Each location MUST do their own verifications on all large transactions
|
||||
|
||||
## Level 4
|
||||
|
||||
### Threat Model
|
||||
|
||||
#### Adversary
|
||||
|
||||
Adversary is a state actor. State actors are the best funded and most sophisticated attackers. They are the highest known threat and have the ability to execute all known attacks. Their well funded operations allow them to pursue goals over long periods of time, relying on subversion, false flags, insider threats via planting moles, compromise of hardware supply and software supply chains, the use of advanced non-commercially available cyber-warfare tools, combining many 0day vulnerabilities to construct highly effective exploit chain. This level of adversary demands the highest known standards of security, which is typically upheld only by the most sophisticated companies and the military.
|
||||
|
||||
This level focuses on defending against adversaries who are nation states.
|
||||
|
||||
#### Attacks
|
||||
|
||||
* Tamper with the supply chain of any single hardware/firmware component
|
||||
|
||||
* Quickly and covertly relocate any device to a lab environment, complete attacks within a short time period, and return the device to its original location
|
||||
|
||||
* Use sophisticated [side channel attacks](side-channel-attacks.md) for exfiltrating data, cryptographic material being a high risk target
|
||||
|
||||
* Non-deterministic encryption/signatures/data
|
||||
|
||||
* Differential Fault Analysis (DFA)
|
||||
|
||||
* Data remanence
|
||||
|
||||
### Requirements
|
||||
|
||||
* All signing systems:
|
||||
|
||||
* MUST have dual implementations of all policy enforcement and signing logic
|
||||
|
||||
* MUST use two or more unrelated hardware supply chains for generating cryptographic material
|
||||
|
||||
* Example: Rust on RISC-V Linux on an FPGA vs C on PPC Gemalto enclave
|
||||
|
||||
* MUST return deterministic results
|
||||
|
||||
* Results are only exported for chain broadcast if identical
|
||||
|
||||
* MUST be stored in near zero emissions vaults a single user can't open
|
||||
|
||||
* See: NSA TEMPEST
|
||||
|
||||
* MUST ensure that individuals are scanned for devices before entering the vault
|
||||
|
||||
* MUST only communicate with outside world via fiber optic serial terminal
|
||||
|
||||
* MUST be housed in Class III bank vault or better
|
||||
|
||||
* MUST have constant environment deviation monitoring
|
||||
|
||||
* Thermal, Acoustic, Air quality, Optical
|
||||
|
||||
* MUST destroy key material on significant environment deviations
|
||||
|
||||
* TODO: methods for doing this
|
||||
|
||||
* MUST be accessible physically with cooperative physical access
|
||||
|
||||
* MAY use FF-L-2740B or better locks with dual pin enforcement
|
||||
|
||||
* MAY use dual biometric enforcement to get near area and disarm security
|
||||
|
||||
## Additional Threat Model Notes
|
||||
|
||||
### Smart Cards
|
||||
|
||||
The Operator Smart Card uses the default PIN because it is meant to be something
|
||||
a user "has", rather than "knows". On the other hand, the Location Smart Card
|
||||
is protected by a complex PIN, which can only be decrypted using the PGP keys
|
||||
stored on the Operator Smart Card. This is done in order to protect the access
|
||||
to the Location key by anyone except the Operator, but also to allow for adding
|
||||
controls which require more than one individual to access a Location Smart Card.
|
||||
In this way, there is an additional "quorum" which needs to be achieved to
|
||||
access the Location key - more on this in the [Location](locations.md) section.
|
||||
|
||||
The Smart Cards are used as they are an HSM (Hardware Security Module) which
|
||||
provides excellent protection for the cryptographic material stored on it, and
|
||||
they are portable, which makes them suitable for creating systems where the
|
||||
cards are in separate physical locations, and need to be brought together in
|
||||
order to re-assemble secret material.
|
||||
Loading…
Reference in New Issue