docs: add some context and clean things up
This commit is contained in:
parent
0df2c9ce08
commit
c771604817
|
@ -1,62 +1,45 @@
|
|||
# Ceremony Log Template
|
||||
## Ceremony Log Template
|
||||
|
||||
This template is to be used during the ceremony in order to keep track of events
|
||||
that take place during the Key Derivation Ceremony.
|
||||
|
||||
Capture as much information as possible - more data is always better than less,
|
||||
this means being specific about the exact location, full names of participants,
|
||||
exact models of equipment used etc.
|
||||
|
||||
## Date
|
||||
|
||||
```
|
||||
2024-08-03
|
||||
```
|
||||
|
||||
## Individuals Present
|
||||
Individuals may be Operators or Witnesses. Include the individual's full legal
|
||||
name
|
||||
|
||||
```
|
||||
Max Rockatansky - Witness
|
||||
Paul Atreides - Operator
|
||||
```
|
||||
|
||||
## Location
|
||||
Specify exact location, including details such as the floor, room etc.
|
||||
|
||||
```
|
||||
12 Grimmauld Place, Islington, London
|
||||
2nd floor, first room on the left when coming up the stairs
|
||||
```
|
||||
|
||||
## Equipment
|
||||
|
||||
### Type of Laptop Used
|
||||
|
||||
```
|
||||
Purism Librem 14
|
||||
```
|
||||
|
||||
### Type of SD Card Used
|
||||
|
||||
```
|
||||
SD Card: Kingston SDCIT2/8GBSP
|
||||
```
|
||||
|
||||
## Software
|
||||
Specify the exact version / commit
|
||||
|
||||
```
|
||||
AirgapOS: https://git.distrust.co/public/airgap/commit/df223e6deb2833a8160c836f435ee01f7b776e87
|
||||
```
|
||||
|
||||
## Chronological Timeline
|
||||
Ensure to capture as much details as possible, even if it seems trivial.
|
||||
|
||||
* 2024-01-01:0900: The team assembles at the airport and selects the location
|
||||
from a pre-made list of potential locations
|
||||
* 2024-01-01:1030: The team arrives at location and inspects the premises for
|
||||
cameras and ensures that the location criteria are adhered to
|
||||
* 2024-01-01:1440: The hardware is set up and the software and firmware are
|
||||
verified
|
||||
```yml
|
||||
usage: Location Key
|
||||
officiant: Anton Livaja
|
||||
location: Private Home (Address Redacted)
|
||||
witnesses: N/A
|
||||
hardware: Dell XPS 13 9630
|
||||
firmware: BIOS 2.13.0
|
||||
laptop_modifications:
|
||||
- Removed WLAN Card
|
||||
- Removed speakers
|
||||
- Removed microphone
|
||||
- Removed all drives
|
||||
boot_media: Kingston Type 2 SD Card 1GB
|
||||
backup_media: TeamGroup High Endurance Micro SDXC 128GB
|
||||
smart_cards: Yubikey 5 NFC
|
||||
software:
|
||||
- name: Airgap OS
|
||||
repo: https://git.distrust.co/public/airgap
|
||||
ref: main
|
||||
hash: 485fc58bfb1b4dc75a81138d93948385cc5bf600
|
||||
playbooks:
|
||||
- name: some/path/to/location_key_generation.md
|
||||
repo: https://git.distrust.co/public/docs
|
||||
ref: some-git-ref-here
|
||||
notes: used once for each Location Key
|
||||
- name: some/path/to/hybrid_quroum_key_generation.md
|
||||
repo: https://git.distrust.co/public/docs
|
||||
ref: some-git-ref-here
|
||||
notes: used once to generate Root Entropy and Disaster Recovery Key
|
||||
outputs:
|
||||
- cert: ./cert
|
||||
- shardfile: ./shardfile
|
||||
Location (Test) Public Key Fingerprints:
|
||||
- 0609D5C2634DB5D75226AD9A7A8A6F24873977E4
|
||||
- 5F827701822425E8BB0D2EAB43EC881D8C80DE41
|
||||
- 6E18E082945BC43411C3B490E43B49017440605D
|
||||
Cold Quorum Key (Test) Fingerprint:
|
||||
- 8BA0304345D05775C303E292D9BDBC00D3E85E87
|
||||
log:
|
||||
- 2024-08-05:1723: Selected a room in residence which has no electronics in it
|
||||
and closed window and window blinds.
|
||||
general_notes: N/A
|
||||
```
|
|
@ -1,44 +1,59 @@
|
|||
# Glossary
|
||||
|
||||
## Ciphertext
|
||||
|
||||
In cryptography, ciphertext is the result of encryption performed on plaintext
|
||||
using an algorithm, called a cipher.
|
||||
|
||||
## Entropy
|
||||
|
||||
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 (QKM)
|
||||
|
||||
A set of highly specified processes and tooling used for setting up a highly
|
||||
resilient quorum-based key management system.
|
||||
|
||||
## Operator
|
||||
|
||||
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 QKM system.
|
||||
|
||||
## Operator Key
|
||||
|
||||
An asymmetric key used for protecting the passphrase of a Location key
|
||||
|
||||
## Quorum
|
||||
|
||||
The chosen M of N threshold used to achieve "quorum", which is a type of
|
||||
agreement or consensus between a group of individuals. In the context of
|
||||
Shamir's Secret Sharing, it refers to the minimum number of shards required to
|
||||
reassemble the [Root Entropy](#root-entripy-re).
|
||||
|
||||
#### Wrench Factor
|
||||
### Wrench Factor
|
||||
|
||||
How many people are required to be put under duress (via smacking them with a
|
||||
wrench repeatedly or otherwise to get access to their Shard) before the Disaster
|
||||
Recover Key is compromised.
|
||||
|
||||
#### Bus Factor
|
||||
### Bus Factor
|
||||
|
||||
How many members of the Quorum can meet an untimely demise without irretrievably
|
||||
locking access to the Distrust Quroum system.
|
||||
|
||||
## Root Entropy (RE)
|
||||
The main entropy/randomness which is used for hierarchical deterministic key
|
||||
derivation of a variety of cryptographic algorithms.
|
||||
|
||||
The main [entropy](#entropy)/randomness which is used for hierarchical
|
||||
deterministic key derivation of a variety of cryptographic algorithms.
|
||||
|
||||
## Shard
|
||||
Crytpographic shard created using Shamir's Secret Sharing algorithm.
|
||||
|
||||
Cryptographic shard created using Shamir's Secret Sharing algorithm.
|
||||
|
||||
## Shamir's Secret Sharing (SSS)
|
||||
|
||||
An algorithm used to split cryptographic material into shards which can be
|
||||
used to reassemble a secret. The shards can be combined according to a threshold
|
||||
which is set at the time of initial sharding, expressed as M of N, or in other
|
||||
|
@ -46,19 +61,24 @@ words M shards of the total N shards in existence are required to reveal the
|
|||
secret.
|
||||
|
||||
## Workstation
|
||||
|
||||
Highly secure computer which is used for sensitive operations, typically in the
|
||||
context of [Production Engineering](TODO).
|
||||
|
||||
#### Minimum
|
||||
In order to set up a Workstation, as part of a [Production Engineering](TODO) setup,
|
||||
a separate computer only used for carrying out sensitive operations should be used.
|
||||
|
||||
In order to set up a Workstation, as part of a [Production Engineering](TODO)
|
||||
setup, a separate computer only used for carrying out sensitive operations
|
||||
should be used.
|
||||
|
||||
#### Recommended
|
||||
|
||||
Setting up a computer with QubesOS is recommended as it makes it easy to create
|
||||
purpose built environments with minimal surface area for attacks, on the OS, and
|
||||
networking level.
|
||||
|
||||
## Air-Gapped
|
||||
|
||||
Hardware which has no access to radio frequency or cable based networking
|
||||
capabilities in order to reduce area for surface attacks. Typically Air-Gapped
|
||||
computers are laptops which are never connected to the internet or any other
|
||||
|
@ -66,6 +86,7 @@ networks, and have had their radio frequency hardware permanently disabled or
|
|||
ideally removed.
|
||||
|
||||
## Key Derivation Ceremony
|
||||
|
||||
Highly specified process which is used to secure derivation of cryptographic
|
||||
material, with a focus on ensuring no single party has access to the Disaster
|
||||
Recovery Key. The ceremony includes witnesses who can help attest to the fact
|
||||
|
@ -74,6 +95,7 @@ software and location that should be used. Each step of the ceremony is
|
|||
carefully planned, and executed accordingly.
|
||||
|
||||
## Location Key
|
||||
|
||||
Is a asymmetric key pair which is used for encrypting shards which are used to
|
||||
re-assemble the Root Entropy. Location Keys are stored in [Locations](locations.md)
|
||||
which adhere to a strict set of criteria to maximize their security. The location
|
||||
|
@ -81,10 +103,13 @@ smart card passphrase is encrypted to a Operator Key in order to secure access
|
|||
to it.
|
||||
|
||||
## M of N
|
||||
M is the minimum number of shards required to reassemble the secret, and N is the
|
||||
total number of shards that exist. The minimum recommended threshold is 2-of-3.
|
||||
|
||||
M is the minimum number of shards required to reassemble the secret, and N is
|
||||
the total number of shards that exist. The minimum recommended threshold is
|
||||
2-of-3.
|
||||
|
||||
## Organization
|
||||
|
||||
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
|
||||
|
@ -92,11 +117,13 @@ ciphertext blobs associated with the system are redundantly stored and
|
|||
protected.
|
||||
|
||||
## Witness
|
||||
|
||||
An individual who attests the ceremony was performed according to specification
|
||||
in order to have additional assurances the cryptographic material, most
|
||||
importantly the Root Entropy was never exposed.
|
||||
|
||||
## Warehouse
|
||||
|
||||
* Online storage for encrypted data replicated across multiple providers
|
||||
* All data in DR Warehouse can only be decrypted by the DR Key
|
||||
* Tolerate loss of any single provider by duplicating data to all of them
|
||||
|
|
|
@ -13,7 +13,10 @@ microscopy to read data from storage drives which have not been completely
|
|||
destroyed.
|
||||
|
||||
Drilling through the storage drive, a common hardware destruction method, is not
|
||||
considered to be secure.
|
||||
considered to be secure. In fact it's best to remove drive from the device and
|
||||
only use in memory storage.
|
||||
|
||||
Ensuring that all chips are completely physically destroyed is essential.
|
||||
|
||||
In the best case scenario, the hardware should be melted in a foundry, as this
|
||||
makes it impossible to retrieve any data by any means.
|
|
@ -48,7 +48,7 @@ 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 two primary requirements for smart cards:
|
||||
There are three primary requirements for smart cards:
|
||||
|
||||
* FIPS 140-2
|
||||
|
||||
|
@ -58,8 +58,7 @@ There are two primary requirements for smart cards:
|
|||
|
||||
Some options include:
|
||||
|
||||
* NitroKey 3 - because of its open source approach which helps improve the
|
||||
overall security of the products
|
||||
* NitroKey 3 - because of its open source approach which allows for verification
|
||||
|
||||
* YubiKey 5 - because of the widespread use and battle-tested reliability
|
||||
|
||||
|
@ -67,10 +66,11 @@ overall security of the products
|
|||
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 a Air-Gapped Computer is the [Librem 14](https://puri.sm/products/librem-14/), manufactured by [Purism](puri.sm). Purism specializes in reducing hardware and
|
||||
[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.
|
||||
|
@ -78,14 +78,15 @@ required for.
|
|||
#### Alternative
|
||||
|
||||
An alternative approach is to use an off-the-shelf computer that is randomly
|
||||
selected right before the ceremony, removing the radio cards from it, using it
|
||||
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 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".
|
||||
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
|
||||
|
@ -94,5 +95,7 @@ be used, and the remaining debris should be spread out across multiple disposal
|
|||
locations.
|
||||
|
||||
## Storage Device
|
||||
Can be an SD Card or USB Drive but should be procured from a vendor with
|
||||
a good reputation, and ideally hardware of industrial grade should be prioritized.
|
||||
|
||||
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.
|
||||
|
|
|
@ -2,8 +2,8 @@
|
|||
|
||||
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 the
|
||||
machine has not been tampered with between uses.
|
||||
of the `.iso` image which is being booted, as well to ensure that firmware of
|
||||
the machine has not been tampered between uses.
|
||||
|
||||
This guide assumes the use of a Purism machine, with a Librem Key.
|
||||
|
||||
|
|
|
@ -2,22 +2,24 @@
|
|||
|
||||
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](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 the following sponsors: TODO.
|
||||
[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 the following
|
||||
sponsors: TODO.
|
||||
|
||||
The basic premise of QKM is that primary cryptographic material akin to a root
|
||||
certificate, called Root Entropy, is derived 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.
|
||||
The system was designed with extensibility in mind.
|
||||
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. The system was designed with extensibility
|
||||
in mind.
|
||||
|
||||
The Root Entropy is sharded using [Shamir's Secret Sharing](glossary.md#shamirs-secret-sharing-sss) to a [Quorum](glossary.md#quorum) in order to
|
||||
protect it from single points of failure, requiring cooperation of multiple
|
||||
individuals - a quorum, and use of cryptographic material stored in separate
|
||||
physical locations with significant access controls in order to reconstruct the
|
||||
secret material, namely the Root Entropy.
|
||||
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
|
||||
failure, requiring cooperation of multiple individuals - a quorum, and use of
|
||||
cryptographic material stored in separate physical locations with significant
|
||||
access controls in order to reconstruct the secret material, namely the RE.
|
||||
|
||||
## Use Cases
|
||||
|
||||
|
@ -42,28 +44,23 @@ a cold signing setup.
|
|||
|
||||
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 in the ceremony in order to ensure that the system is well
|
||||
understood by all in order to ensure that the integrity of the process is
|
||||
preserved and enforced by all participants.
|
||||
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.
|
||||
|
||||
## Directives
|
||||
|
||||
The documentation provides directives in order to specify the importance of
|
||||
adhering to parts of the specification as follows to achieve high levels of
|
||||
security:
|
||||
The documentation uses directives in order to specify the importance of
|
||||
adhering to parts of the specification according to [RFC2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC8174](https://www.rfc-editor.org/rfc/rfc8174).
|
||||
|
||||
* **MUST** - not adhering to this will result in significant deterioration of
|
||||
security properties of the system
|
||||
|
||||
* **SHOULD** - is recommended and may impact the security of the system
|
||||
depending on the context
|
||||
|
||||
* **MAY** - is typically a design decision with no significant impact to the
|
||||
overall security of the system
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
|
||||
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when,
|
||||
and only when, they appear in all capitals, as shown here.
|
||||
|
||||
## Method
|
||||
|
||||
The reader is encouraged to read through the entire body of documents which
|
||||
should not take more than 30 minutes. If any parts are unclear, they may contact
|
||||
Distrust for clarification, which is welcomed as it will aid improving the
|
||||
should take approximately 30 minutes. If any parts are unclear, they may contact
|
||||
Distrust for clarification, which is welcomed as it will aid in improving the
|
||||
documentation.
|
|
@ -14,16 +14,18 @@ command with a desired threshold:
|
|||
```
|
||||
#!/bin/sh
|
||||
|
||||
script_dir="$(dirname "$(realpath "$0")")"
|
||||
read -p "Generate hardware interrupt entropy by typing randomly on keyboard" entropy
|
||||
|
||||
read -p "Provide the absoute path to PGP certificates which will be used for the ceremony: " directory_path
|
||||
mount
|
||||
|
||||
if [ ! -d "$directory_path" ]; then
|
||||
echo "Directory does not exist. Please enter a valid directory path."
|
||||
exit 1
|
||||
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 "$directory_path"/*; do
|
||||
for file in "$absolute_path"/keys/*; do
|
||||
if [ -f "$file" ]; then
|
||||
echo "Processing file: $file"
|
||||
gpg --import --import-options import-show $file
|
||||
|
@ -32,12 +34,12 @@ command with a desired threshold:
|
|||
|
||||
read -p "Do the PGP key IDs match what you expect? (y/n): " matches_expectation
|
||||
|
||||
if [ $matches_expectation != "y" ]; then
|
||||
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 /media/cert --output-shardfile /media/shardfile --user-id "Distrust Key Ceremony" public-certificates/
|
||||
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
|
||||
|
|
|
@ -14,6 +14,11 @@ instead the AirgapOS `.iso` image is flashed to an SD card, locked using
|
|||
|
||||
* `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`
|
||||
|
|
|
@ -4,8 +4,8 @@
|
|||
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 not
|
||||
specifically targeting the specific quorum group.
|
||||
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.
|
||||
|
@ -13,20 +13,20 @@ 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 built in; if this is not possible, you will
|
||||
also need to purchase a USB SD card reader.
|
||||
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 consensu of at
|
||||
* 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 Quroum team
|
||||
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
|
||||
|
|
|
@ -1,14 +1,15 @@
|
|||
# Selecting Locations
|
||||
|
||||
Secure a location that is randomly selected 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 not near any human made buildings. 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.
|
||||
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
|
||||
|
|
|
@ -0,0 +1,7 @@
|
|||
# Q & A
|
||||
|
||||
## Is there a risk associated with deriving for different cryptographic algorithms from the same source of entropy?
|
||||
|
||||
This is avoided by using hardened hierarchical deterministic derivation which
|
||||
is designed to ensure that each node in the derivation tree is isolated.
|
||||
|
|
@ -3,12 +3,12 @@
|
|||
There are 3 primary types of [Root Entropy](glossary.md#root-entropy-re)
|
||||
derivation ceremonies:
|
||||
|
||||
* "Local": where all cryptographic material, including the Operator Keys,
|
||||
* **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
|
||||
* **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
|
||||
* **Remote**: where all cryptographic material is generated in a decentralized
|
||||
manner, remotely.
|
||||
|
|
|
@ -1,5 +1,8 @@
|
|||
# Secure Boot Sequence
|
||||
|
||||
Steps 1-12 can be skipped if the media drive with `airgap` has been verified in
|
||||
advance.
|
||||
|
||||
1. Plug in the [PureBoot Smart Card](initialize-pureboot-smart-card.md)
|
||||
|
||||
2. Plug in [AirgapOS Storage Device](repeat-use-airgapos.md)
|
||||
|
|
|
@ -1,11 +1,11 @@
|
|||
# Selecting a Quorum
|
||||
|
||||
The backbone of the Distrust Quroum system 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 Members of a Quorum there are in total, and
|
||||
the Quorum, which is how Members are required to reach consensus.
|
||||
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
|
||||
Members of a Quorum there are in total, and the Quorum, which is how Members are
|
||||
required to reach consensus.
|
||||
|
||||
The following is a simple Quorum example. Let's assume there are 3 trusted
|
||||
individuals who will be part of Quorum and at least 2 of the Members of the
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Setting Smart Card Pins
|
||||
|
||||
In order to protect unauthorized use of smart cards, we can leverage PINs.
|
||||
In order to protect unauthorized use of smart cards, PINs are leveraged.
|
||||
|
||||
There are two pins with different levels of authorization for making changes
|
||||
to the smart card:
|
||||
|
@ -15,9 +15,15 @@ characters long.
|
|||
For Operator Keys it is recommended to use the default PINs, while for Location
|
||||
Keys, PINs are generated by the `keyfork` utility and have high entropy.
|
||||
|
||||
**WARNING** Different smart cards have different failure thresholds, but typically after
|
||||
entering the PIN incorrectly 3-10 times, the smart card is permanently locked
|
||||
and can no longer be used.
|
||||
|
||||
## Guide
|
||||
|
||||
To set the smart card pins you may use the `gpg` utility.
|
||||
To set the smart card pins you may use the `gpg` utility. This guide should be
|
||||
completed in a trusted environment, such as on a airgapped machine running
|
||||
AirgapOS.
|
||||
|
||||
1. Plug the smart card into a computer which has the `gpg` utility intalled
|
||||
2. Use the command `gpg --edit-card` to enter edit mode
|
||||
|
@ -34,5 +40,3 @@ To set the smart card pins you may use the `gpg` utility.
|
|||
|
||||
8. For the Admin PIN, the steps are the same, except in step 4, input "3", then
|
||||
press Enter.
|
||||
|
||||
9. Once done, shut down the computer
|
||||
|
|
|
@ -1,13 +1,19 @@
|
|||
# Software
|
||||
This page outlines the software used for setting up a QKM. All software used in
|
||||
the setup is open source and audited by security firms in order to ensure their
|
||||
security. Furthermore, all software is built in a deterministic manner and
|
||||
reproduced by multiple individuals on diverse hardware to minimize the risks
|
||||
associated with supply chain attacks.
|
||||
This page outlines the software used for setting up QKM.
|
||||
|
||||
## [[Stageˣ]](https://codeberg.org/stagex/stagex)
|
||||
|
||||
All software is built in a deterministic manner and reproduced by multiple
|
||||
individuals on diverse hardware to minimize the risks associated with supply
|
||||
chain attacks.
|
||||
|
||||
To achieve this, [Stageˣ] is used - a toolchain for building software using a
|
||||
fully bootstrapped compiler, which itself is built deterministically, and
|
||||
multi-reproduced.
|
||||
|
||||
[Stageˣ] was designed and developed by Distrust, with generous sponsorship from
|
||||
Keyternal and Mysten Labs.
|
||||
|
||||
To achieve this, [StageX](https://codeberg.org/stagex/stagex)
|
||||
is used - a toolchain for building software using a fully bootstrapped compiler,
|
||||
which itself is built deterministically, and multi-reproduced.
|
||||
## [AirgapOS](https://git.distrust.co/public/airgap)
|
||||
|
||||
AirgapOS is an operating system built for those that want to be -really- sure
|
||||
|
|
|
@ -8,7 +8,7 @@ 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 hardware, firmware and software used,
|
||||
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
|
||||
|
@ -21,7 +21,7 @@ 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
|
||||
of their security properties
|
||||
|
||||
* Creating custom purpose specific tooling which eliminates dependencies in
|
||||
order to reduce supply chain attacks, and adds desirable security properties
|
||||
|
@ -38,7 +38,7 @@ which had radio networking cards (bluetooth, wifi etc.) removed
|
|||
|
||||
* Leveraging sharding in order to physically separate cryptographic material
|
||||
|
||||
* Leveraging tamper evident controls to protect hardware
|
||||
* Leveraging tamper evident controls for components related to the system
|
||||
|
||||
## General Threat Model Assumptions
|
||||
|
||||
|
@ -54,7 +54,7 @@ Some additional assumptions are made to help contextualize the threat model:
|
|||
|
||||
* 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 member of the Production Team is always compromised
|
||||
|
||||
* At least one maintainer of third party used in the system is compromised
|
||||
|
||||
|
|
Loading…
Reference in New Issue