Introduction

Quorum Vaulting System (QVS) 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. The system was designed and developed by Distrust, with the generous support of sponsors.

The basic premise of QVS is that primary cryptographic material akin to a root certificate, called 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.

The RE is sharded using Shamir's Secret Sharing (SSS) to a 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

QVS 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 box" - for example a company can back up keys for their digital asset wallets by encrypting them to the public key and storing the encrypted ciphertext blobs on multiple cloud storage platforms, or on offline hard drives for redundancy.
Deriving PGP keys for multiple individual users in a deterministic manner.
Deriving wallets for digital assets using BIP-0032 style derivation as part of a cold signing setup.
Decrypting data in a secure, quorum protected, air-gapped environment.
Generating digital certificates

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 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 uses directives in order to specify the importance of adhering to parts of the specification according to RFC2119 and RFC8174.

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 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.

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 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

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 PKCS#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 OpenPGP key generated on airgap using keyfork, backed up, and copies transmitted to a smart cards such as a Yubikey
CA key smart cards are stored in dual-access tamper evident locations

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 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 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 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.

Selecting a Quorum

The backbone of QVS 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 Quorum should be required to reach consensus. In that case the chosen Quorum would be "2 of 3" - in other words, 2 of the total of 3 are required to achieve consensus. These numbers may be adjusted in order to optimize risk tolerance along two axis:

Tolerating loss of X members aka "Bus Factor"
Tolerating duress of Y members aka "Wrench Factor"

In a "2 of 3" Quorum, the Bus Factor is 1 as we can only afford to lose 1 member of the Quorum before the ability to reach consensus is lost permanently. For that same Quorum, the Wrench Factor is 2, as an adversary has to use their wrench on two different Quorum Members to force them to give them access to their shards before the system is compromised (this is an over-simplification as there are additional security controls in place such as the physical locations which hold Location Keys, and as such the Wrench Factor is hardened).

It is recommended to use a "2 of 3" Threshold at a minimum, but many organizations may choose to go with more resilient Threshold such as "3 of 5", "2 of 6", or "5 of 7", depending on considerations pertaining to:

Availability requirements
Bus Factor requirements
Wrench Factor requirements

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.

To better understand why the different roles are required, refer to the selecting a quorum and threat model 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

Procurer

Responsible for tasks such as procuring a location, tamper proofing equipment, hardware, and maintaining inventory.

Provisioner

Responsible for more technical aspects of preparing equipment for ceremonies such as creating air-gapped machines by removing radio cards, and tamper proofing them along with SD cards which are loaded with AirgapOS etc.

Proposer

This is an individual who is a business owner or stakeholder, or a financial controller. Their role is to make fiduciary decisions which protect the financial interest of the organization and its clients. Their role is specifically to propose the movement of funds, specifying the amount, origin and destination.

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 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 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 make ideal witnesses as their familiarity with the QVS system allows them to detect any deviation from the security-critical processes. While it is not required that a Witness be a trained Operator, it is highly preferred.

PGP 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.

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

Software

This page outlines the software used for setting up QVS.

[Stageˣ]

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.

AirgapOS

AirgapOS is an operating system built for those that want to be -really- sure that sensitive cryptographic material is managed in a clean environment with an "air gap" between the machine and the internet with high integrity on the supply chain of the firmware and OS used. This OS is hardened and specifically designed as an appliance for working with cryptographic material.

The software was developed by Distrust and has undergone an audit by Cure53 with no significant vulnerabilities found and has since then undergone additional hardening.

The AirgapOS Setup guides the user through verifying and setting up AirgapOS on a bootable disk to use as part of the Key Derivation Ceremony

Keyfork

Keyfork is an opinionated and modular toolchain for generating and managing a wide range of cryptographic keys offline and on Smart Cards from a shared 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 and is included with AirgapOS and has been audited by two firms, NCC and Cure53 with no significant vulnerabilities found.

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.

Locations

Locations refer to physical points in space which are used for storing cryptographic material or performing actions using the cryptographic material and adhere to a set of criteria which focus on achieving a high level of security - specifically with respect to:

Protecting access to devices which store cryptographic material
Mitigating the risk stemming from natural disaster and other black swan events such as civil unrest or war.
Reducing the risk of exposing cryptographic material, for example via side-channel attacks

There are three sub-types of Locations, one which is used for performing any actions related to the management of the cryptographic material life-cycle and is referred to as the Management Location, one for long term secure storage of cryptographic material such as Smart Cards which are used to decrypt Shards, referred to as a Storage Location, and a location for Ceremonies, known as the Ceremony Location.

Level 1

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

MUST have physical access restrictions which require identification
MUST have the ability to require more than 1 person to gain access
- This control can be both physical, for example in vaults which require 2 keys for access AND/OR process level, where the personnel of the facility may verify the identity of one or more individuals
SHOULD have anti-fire systems
SHOULD have anti-flood systems
SHOULD be in facilities controlled by organizations which are ideally immune to being legally subpoenaed

Level 3

MUST have anti-fire systems
MUST have anti-flood systems
MUST have 24/7 security monitoring
MUST be in different geographic locations
- This ensures that natural disasters are not likely to impact multiple 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.

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

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 (QVS)

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 which is used for protecting the passphrase of a Location key and participates in different aspects of the lifecycle management of the QVS 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.

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

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.

Shard

Cryptographic shard created using Shamir's Secret Sharing algorithm.

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 words M shards of the total N shards in existence are required to reveal the secret.

Secure Compartmentalized Information Facility (SCIF)

RFC2119 and 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 context of Production Engineering.

Minimum

In order to set up a Workstation, as part of a Production Engineering setup, a separate computer only used for carrying out sensitive operations should be used.

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 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 that the ceremony was executed properly, as well as instructions on hardware, 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 which adhere to a strict set of criteria to maximize their security. The location 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.

Organization

An organization which owns the QVS and is responsible for funding the setup and maintenance. The organization is also responsible for ensuring that the Warehouse is properly maintained in order to ensure that the 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
Storage backends can be any combination of the following:
- S3 Compatible object stores:
  - AWS, Google Cloud, DigitalOcean, Azure, etc.
Version Control Systems:
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.

Create Ceremony Repository

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

Create a git repository using a git system such as Forgejo, GitLab, GitHub etc.
Set appropriate permissions to limit who can write to the repository.
- Require that all commits are signed using well known PGP keys
Optionally set up a cron job that periodically pulls the data from the repository as a backup.

Personal PGP Key Provisioning

Requirements

AirgapOS SD card
- Provided by Air-Gapped Bundle
- Alternative: Create your own from documentation in AirgapOS Repository
AirgapOS Laptop
- Provided by Air-Gapped Bundle
- Alternative: Computer that can load AirgapOS (compatibility reference)
Linux Workstation (online machine)
- Any internet connected computer with a Linux shell will suffice
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

If using pre-sealed Cold Bundle unseal as follows:

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
Boot AirgapOS Laptop
Insert an SD card into the system
Change working directory to SD card mount location
```
$ cd /media/TRANSFER
```
Insert all smartcards to be provisioned into the system.
Set expiry time via environment variable - you can update 2y to desired value:
```
$ export KEYFORK_OPENPGP_EXPIRE=2y
```
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 encrypted.asc --provision openpgp-card --derive='openpgp --public "Your Name <your@email.co>"'
```
The --provision-count option can be provided 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.
Power down AirgapOS Laptop
Switch to Linux Workstation
Attach SD card from AirgapOS machine
Attach smartcard provisioned with AirgapOS machine
Import newly generated public key into local keychain
```
$ gpg --import /media/TRANSFER/*.pub.asc
```
Retrieve the value of your PGP key ID from smartcard
```
gpg --card-status
```

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

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

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

c. Commit and push modifications

$ cp /media/TRANSFER/*.asc keys/all
$ git add .
$ git commit -S -m "add <name> pgp key"
$ git push origin main

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)
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

Procurer

The procurer is responsible for:

Procuring equipment
- Tamper proofing equipment
- Hardware (computers, sd cards, sd card adapters, smart cards, cameras etc.)
Creating and maintaining the Inventory
Ensuring equipment is properly tamper proofed
Minimizing hardware supply chain security risks

Order of Operations

Provisioning Personal PGP Keys
Procuring a facility
Creating a Inventory repository
Procuring tamper proofing equipment
Procuring hardware
- Laptops
- SD cards
- SD card USB adapters
- Smart cards

Procure Facility

Identify a location which is suitable for Level 2 ceremonies:
- SHOULD be lockable to prevent inflow and outflow of persons during ceremonies
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.
Designate the location as the facility for conducting ceremonies and update documentation and policies to reflect this

Create Inventory Repository

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

Create a git repository using a git system such as Forgejo, GitLab, GitHub etc.
Set appropriate permissions to limit who can write to the repository.
- Require that all commits are signed using well known PGP keys
Optionally set up a cron job that periodically pulls the data from the repository as a backup.

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

Digital camera

MUST have >10MP

Polaroid camera

Polaroid Now+
Preferred film: Color I-Type Film

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

Procure SD Card Pack

Requirements

2 individuals with appropriate role
- Each needs a Personal PGP key pair
Tamper-proofing equipment
5 Fresh SD card(s) per booster pack
High Visibility Storage
Sealable plastic bag is required for this procedure:
- Alert Security bag

Chain Name	Chain	Asset
Seda	seda	SEDA
Seda Devnet	seda-devnet	SEDA
Kyve	kyve	KYVE
Kyve Testnet	kaon	KYVE
Kyve Devnet	korellia	KYVE

Quorum Vault System (QVS)

RFC2119 and RFC8174