Compare commits

...

11 Commits

98 changed files with 749 additions and 151 deletions

View File

@ -1,24 +1,24 @@
PORT := 8080
.PHONY: default
default: build-qvs
default: build-trove
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-trove
build-trove: out/trove/index.json
out/trove/index.json: out Containerfile.trove $(shell find quorum-vault-system -type f)
mkdir -p out/trove
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.trove \
--output type=oci,rewrite-timestamp=true,force-compression=true,name=git.distrust.co/public/docs-trove,tar=true,dest=- \
. \
| tar -C out/qvs -mx
| tar -C out/trove -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-trove
serve-trove: build-trove
tar -C out/trove -cf - . | docker load
docker run -p $(PORT):8080 git.distrust.co/public/docs-trove

View File

@ -1,27 +0,0 @@
# Cosmos: Create Transaction Payload
{{ #include template-create-tx-0.md:content }}
1. Use icepick to generate and sign the payload by running one of the following available workflows:
#### Stake
Stake coins on the provided chain.
`$ icepick workflow cosmos stake --delegate-address <delegate-address> --validator-address <validator-address> --chain-name <chain-name> --asset-name <asset-name> --asset-amount <asset-amount> --gas-factor <gas-factor> --export-for-quorum --sign`
#### Transfer
Transfer coins on the cosmos blockchain.
`$ icepick workflow cosmos transfer --from-address <from-address> --to-address <to-address> --asset-name <asset-name> --asset-amount <asset-amount> --export-for-quorum --sign`
#### Withdraw
Withdraw staked coins from a validator. Staked coins may be held for an unbonding period, depending on the chain upon which they are staked.
`$ icepick workflow cosmos withdraw --delegate-address <delegate-address> --validator-address <validator-address> --asset-name <asset-name> --gas-factor <gas-factor> --export-for-quorum-sign`
#### Withdraw Rewards
Withdraw rewards gained from staking to a validator.
`$ icepick workflow cosmos withdraw-rewards --delegate-address <delegate-address> --validator-address <validator-address> --gas-factor <gas-factor> --export-for-quorum-sign`
{{ #include template-create-tx-1.md:content }}

View File

@ -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
## 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](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 security-critical processes. While it is not required that a Witness be a trained Operator, it is highly preferred.

View File

@ -1,6 +1,6 @@
# Quorum Key Management (QVS)
# Trove
Quorum Key Management (QVS) is an open source system of playbooks and tooling which
Trove 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.

View File

@ -3,4 +3,4 @@ authors = ["Anton Livaja", "Lance R. Vick", "Ryan Heywood"]
language = "en"
multilingual = false
src = "src"
title = "Quorum Vault System (QVS)"
title = "Trove"

View File

@ -25,7 +25,10 @@
* [Provision Air-Gapped Bundle](generated-documents/level-2/fixed-location/provisioner/air-gapped-bundle.md)
* [Proposer]()
* [Solana: Create Transaction Payload](generated-documents/level-2/fixed-location/proposer/sol-create-transaction-payload.md)
* [Pyth: Create Transaction Payload](generated-documents/level-2/fixed-location/proposer/pyth-create-transaction-payload.md)
* [Cosmos: Create Transaction Payload](generated-documents/level-2/fixed-location/proposer/cosmos-create-transaction-payload.md)
* [Kyve: Create Transaction Payload](generated-documents/level-2/fixed-location/proposer/kyve-create-transaction-payload.md)
* [Seda: Create Transaction Payload](generated-documents/level-2/fixed-location/proposer/seda-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)
@ -40,6 +43,15 @@
* [Solana]()
* [Generate Address](generated-documents/level-2/fixed-location/operator/coins/sol/generate-address.md)
* [Sign and Broadcast Transaction](generated-documents/level-2/fixed-location/operator/coins/sol/sign-and-broadcast-transaction.md)
* [Cosmos]()
* [Pyth]()
* [Generate Address](generated-documents/level-2/fixed-location/operator/coins/pyth/generate-address.md)
* [Sign and Broadcast Transaction](generated-documents/level-2/fixed-location/operator/coins/pyth/sign-and-broadcast-transaction.md)
* [Cosmos - General]()
* [Generate Address](generated-documents/level-2/fixed-location/operator/coins/cosmos/generate-address.md)
* [Sign and Broadcast Transaction](generated-documents/level-2/fixed-location/operator/coins/cosmos/sign-and-broadcast-transaction.md)
* [Kyve]()
* [Generate Address](generated-documents/level-2/fixed-location/operator/coins/kyve/generate-address.md)
* [Sign and Broadcast Transaction](generated-documents/level-2/fixed-location/operator/coins/kyve/sign-and-broadcast-transaction.md)
* [Seda]()
* [Generate Address](generated-documents/level-2/fixed-location/operator/coins/seda/generate-address.md)
* [Sign and Broadcast Transaction](generated-documents/level-2/fixed-location/operator/coins/seda/sign-and-broadcast-transaction.md)

View File

@ -11,7 +11,7 @@
$ cp -r /media/vaults ~/vaults/
$ cd ~/vaults
$ git add .
$ git commit -m -S "<message>"
$ git commit -S -m "<message>"
$ git push origin HEAD
```
// ANCHOR_END: content

View File

@ -12,8 +12,8 @@
$ 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
$ git config --global commit.gpgsign true
$ git config --global commit.merge true
```
1. Configure ssh to authenticate with smartcard

View File

@ -1,6 +1,6 @@
# Physical Artifact Storage
QVS requires that some of the hardware containing cryptographic material be
Trove 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

View File

@ -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 Trove.
The primary artifacts which are produced during the ceremony are:

View File

@ -32,7 +32,7 @@
1. Generate a new address:
* `icepick workflow cosmos generate-address --account $account_id > $account_id.json`
* `icepick workflow cosmos generate-address --chain-name <chain-name> --account $account_id > $account_id.json`
{{ #include ../template-gen-address-1.md:content }}

View File

@ -26,6 +26,39 @@
1. Place all contents except for the laptop into High Visibility Storage
### Online Machine: Acquire Nonce
1. Turn on online linux workstation
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 cosmos broadcast --chain-name <chain-name> --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
@ -62,22 +95,18 @@
### Broadcast Transaction: Online Machine
1. Power on linux workstation
1. Retrieve Ceremony SD from High Visibility Storage and plug it into online machine
1. Retrieve Ceremony SD from High Visibility Storage and plug it into linux workstation
1. Run the broadcast command:
```
$ keyfork workflow cosmos broadcast --input-file <payload.json> --nonce-address=<nonce_address>
```
* The `<nonce_address>` is the principal or primary address
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/account_info.json
```
1. Unplug the Ceremony SD card and place it in High Visibility Storage
### Repeat

View File

@ -0,0 +1,45 @@
# Kyve: 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
{{ #include ../template-gen-address-0.md:content }}
1. Generate a new address:
* `icepick workflow cosmos generate-address --chain-name kyve --account $account_id > $account_id.json`
The option `--chain-name` can use `kyve`, `kaon` (testnet), and `korellia` (devnet)
{{ #include ../template-gen-address-1.md:content }}
### Online Machine: Updating Vaults Repository
1. Turn on online linux workstation
{{ #include ../../../../../../component-documents/git-basics.md:content }}

View File

@ -0,0 +1,132 @@
# Kyve: Sign and Broadcast Transaction
## 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
### Online Machine: Acquire Nonce
1. Turn on online linux workstation
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 cosmos broadcast --chain-name kyve --nonce-address=$nonce_address
```
The option `--chain-name` can use `kyve`, `kaon` (testnet), and `korellia` (devnet)
* 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
* The payload is located in the appropriate vault location (e.g /media/<device_name>/vaults/<namespace>/ceremonies/<date>...)
```
$ 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/account_info.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 linux workstation
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}}

View File

@ -0,0 +1,102 @@
# Pyth: 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
{{ #include ../template-gen-address-0.md:content }}
1. Generate a new address:
```
$ icepick workflow sol generate-address --account $account_id > $account_id.json
```
{{ #include ../template-gen-address-1.md:content }}
### Online Machine: Generate Nonce Account
1. Turn on online machine
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 `icepick` is available on system
* Follow steps from [installation guide](TODO)
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:
* If using a non-`mainnet-beta` cluster, be sure to provide the `--cluster` argument
* Set `icepick` config file:
```
$ export ICEPICK_CONFIG_FILE=<path_to_icepick_repositry>/icepick.toml`
```
```
$ icepick workflow sol generate-nonce-account --input-file $account_id.json > $account_id-na.json
```
* Repeat command if returned message is "The transaction was possibly not received by the cluster."
1. Fund the wallet displayed on-screen with 0.01 SOL
* Once the funding is done, the 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}}

View File

@ -0,0 +1 @@
# Sign and Broadcast Transaction

View File

@ -0,0 +1,45 @@
# Seda: 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
{{ #include ../template-gen-address-0.md:content }}
1. Generate a new address:
* `icepick workflow cosmos generate-address --chain-name seda --account $account_id > $account_id.json`
The option `--chain-name` can use `seda` or `seda-devnet`.
{{ #include ../template-gen-address-1.md:content }}
### Online Machine: Updating Vaults Repository
1. Turn on online linux workstation
{{ #include ../../../../../../component-documents/git-basics.md:content }}

View File

@ -0,0 +1,132 @@
# Seda: Sign and Broadcast Transaction
## 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
### Online Machine: Acquire Nonce
1. Turn on online linux workstation
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 cosmos broadcast --chain-name seda --nonce-address=$nonce_address
```
The option `--chain-name` can use `seda` or `seda-devnet`.
* 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
* The payload is located in the appropriate vault location (e.g /media/<device_name>/vaults/<namespace>/ceremonies/<date>...)
```
$ 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/account_info.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 linux workstation
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}}

View File

@ -51,23 +51,10 @@
```
* 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 INSECURE_HARDWARE_ALLOWED=1
```
* [Bug: user shouldn't have to set this insecure config. Issue #34 fixes this.](https://git.distrust.co/public/icepick/issues/34)
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>
@ -82,20 +69,20 @@
```
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`
* If using a non-`mainnet-beta` cluster, be sure to provide the `--cluster` argument
* 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)" --input-file $account_id.json > $account_id-na.json
$ icepick workflow sol generate-nonce-account --input-file $account_id.json > $account_id-na.json
```
* 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
1. Fund the wallet displayed on-screen with 0.01 SOL
* Once the airdrop is done, nonce account will be created
* Once the funding is done, the nonce account will be created
1. Stage, commit, sign and push the changes:
```

View File

@ -5,9 +5,9 @@
* Import OpenPGP keys:
* `gpg --import /media/<device_name>/vaults/keys/all/*.asc`
* `gpg --import /media/vaults/keys/all/*.asc`
* `gpg --detach-sign $account_id.txt`
* `gpg --detach-sign $account_id.json`
1. You may repeat the previous steps, starting at the step where the `account_id` is set.

View File

@ -16,7 +16,7 @@ Procedure for importing an arbitrary secret (raw key, mnemonic, state secrets) i
1. Encrypt the secret to certificate:
* `sq encrypt --for-file <certificate> <file_to_encrypt> --output encrypted.asc`
* `sq encrypt --without-signature --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

View File

@ -22,7 +22,7 @@ This is a ceremony for generating and sharding entropy to a set of existing Quor
* Replace the values: <path_to_input_shard>, <pgp_user_id>
```
$ keyfork mnemonic generate --shard-to <path_to_input_shard>,output=shardfile.asc --derive=openpgp --public "<pgp_user_id>" --output certificate.asc
$ keyfork mnemonic generate --shard-to <path_to_input_shard>,output=shardfile.asc --derive='openpgp --public "Your Name <your@email.co>" --output certificate.asc'
```
1. Unseal an SD card pack

View File

@ -22,7 +22,7 @@ This is a ceremony for generating entropy which is used to derive Quorum PGP key
* Replace the following values: \<M>, \<N>, <number_of_smart_cards_per_operator>, <pgp_user_id> with appropriate values
```
$ keyfork mnemonic generate --shard-to-self shardfile.asc,threshold=<M>,max=<N>,cards_per_shard=<number_of_smartcards_per_operator>,cert_output=keyring.asc --derive=openpgp --public "<pgp_user_id>" --output certificate.asc
$ keyfork mnemonic generate --shard-to-self shardfile.asc,threshold=<M>,max=<N>,cards_per_shard=<number_of_smartcards_per_operator>,cert_output=keyring.asc --derive='openpgp --public "Your Name <your@email.co>" --output certificate.asc'
```
1. Unseal an SD card pack by following tamper proofing steps:

View File

@ -0,0 +1,50 @@
# Cosmos: Create Transaction Payload
{{ #include template-create-tx-0.md:content }}
1. Use icepick to generate and sign the payload by running one of the following available workflows:
All commands in the following sections take `--chain-name` and (with the
exception of `withdraw-rewards`) `--asset-name`. These are the "Chain" and
"Asset" fields from the table below. For example, Kyve Mainnet tokens would
be `--chain-name kyve --asset-name KYVE`. Seda Mainnet tokens would be
`--chain-name seda --asset-name SEDA`. The table below documents all
currently-supported combinations of chain and primary asset.
| Chain Name | Chain | Asset |
| ---------- | ----- | ----- |
| Seda | seda | SEDA |
| Seda Devnet | seda-devnet | SEDA |
| Kyve | kyve | KYVE |
| Kyve Testnet | kaon | KYVE |
| Kyve Devnet | korellia | KYVE |
Additionally, there may be some difficulty broadcasting a transaction due
to the amount of gas consumed, as each Cosmos chain may have different
computation power available. The option `--gas-factor` may be set to a
number to multiply the gas by, such as `1.2`, to increase the amount of gas
for a transaction. The default value is `1`, and may be omitted if desired.
A value lower than 1 is not recommended.
#### Stake
Stake coins on the provided chain towards a validator operator's address.
`$ icepick workflow cosmos stake --delegate-address <delegate-address> --validator-address <validator-address> --chain-name <chain-name> --asset-name <asset-name> --asset-amount <asset-amount> --gas-factor <gas-factor> --export-for-quorum --sign`
#### Transfer
Transfer coins on the cosmos blockchain.
`$ icepick workflow cosmos transfer --from-address <from-address> --to-address <to-address> --chain-name <chain-name> --asset-name <asset-name> --asset-amount <asset-amount> --export-for-quorum --sign`
#### Withdraw
Withdraw staked coins from a validator. Staked coins may be held for an unbonding period, depending on the chain upon which they are staked.
`$ icepick workflow cosmos withdraw --delegate-address <delegate-address> --validator-address <validator-address> --chain-name <chain-name> --asset-name <asset-name> --gas-factor <gas-factor> --export-for-quorum-sign`
#### Withdraw Rewards
Withdraw rewards gained from staking to a validator.
`$ icepick workflow cosmos withdraw-rewards --delegate-address <delegate-address> --validator-address <validator-address> --chain-name <chain-name> --gas-factor <gas-factor> --export-for-quorum-sign`
{{ #include template-create-tx-1.md:content }}

View File

@ -0,0 +1,37 @@
# Kyve: Create Transaction Payload
{{ #include template-create-tx-0.md:content }}
1. Use icepick to generate and sign the payload by running one of the following available workflows:
There may be some difficulty broadcasting a transaction due
to the amount of gas consumed, as each Cosmos chain may have different
computation power available. The option `--gas-factor` may be set to a
number to multiply the gas by, such as `1.2`, to increase the amount of gas
for a transaction. The default value is `1`, and may be omitted if desired.
A value lower than 1 is not recommended.
The option `--chain-name` can use `kyve`, `kaon` (testnet), and `korellia` (devnet)
#### Stake
Stake coins on the provided chain towards a validator operator's address.
`$ icepick workflow cosmos stake --delegate-address <delegate-address> --validator-address <validator-address> --chain-name kyve --asset-name KYVE --asset-amount <asset-amount> --gas-factor <gas-factor> --export-for-quorum --sign`
#### Transfer
Transfer coins on the cosmos blockchain.
`$ icepick workflow cosmos transfer --from-address <from-address> --to-address <to-address> --chain-name kyve --asset-name <asset-name> --asset-amount <asset-amount> --export-for-quorum --sign`
#### Withdraw
Withdraw staked coins from a validator. Staked coins may be held for an unbonding period, depending on the chain upon which they are staked.
`$ icepick workflow cosmos withdraw --delegate-address <delegate-address> --validator-address <validator-address> --chain-name kyve --asset-name KYVE --gas-factor <gas-factor> --export-for-quorum-sign`
#### Withdraw Rewards
Withdraw rewards gained from staking to a validator.
`$ icepick workflow cosmos withdraw-rewards --delegate-address <delegate-address> --validator-address <validator-address> --chain-name kyve --gas-factor <gas-factor> --export-for-quorum-sign`
{{ #include template-create-tx-1.md:content }}

View File

@ -0,0 +1,12 @@
# Solana: Create Transaction Payload
{{ #include template-create-tx-0.md:content }}
1. Use icepick to generate and sign the payload by running one of the following available workflows:
#### Transfer Token
Transfer Pyth on Solana blockchain.
`$ icepick workflow sol transfer-token --from-address <from-address> --to-address <to-address> --token-name PYTH --token-amount <token-amount> --export-for-quorum --sign`
{{ #include template-create-tx-1.md:content }}

View File

@ -0,0 +1,37 @@
# Seda: Create Transaction Payload
{{ #include template-create-tx-0.md:content }}
1. Use icepick to generate and sign the payload by running one of the following available workflows:
There may be some difficulty broadcasting a transaction due
to the amount of gas consumed, as each Cosmos chain may have different
computation power available. The option `--gas-factor` may be set to a
number to multiply the gas by, such as `1.2`, to increase the amount of gas
for a transaction. The default value is `1`, and may be omitted if desired.
A value lower than 1 is not recommended.
The option `--chain-name` can use `seda` or `seda-devnet`.
#### Stake
Stake coins on the provided chain towards a validator operator's address.
`$ icepick workflow cosmos stake --delegate-address <delegate-address> --validator-address <validator-address> --chain-name seda --asset-name SEDA --asset-amount <asset-amount> --gas-factor <gas-factor> --export-for-quorum --sign`
#### Transfer
Transfer coins on the cosmos blockchain.
`$ icepick workflow cosmos transfer --from-address <from-address> --to-address <to-address> --chain-name seda --asset-name <asset-name> --asset-amount <asset-amount> --export-for-quorum --sign`
#### Withdraw
Withdraw staked coins from a validator. Staked coins may be held for an unbonding period, depending on the chain upon which they are staked.
`$ icepick workflow cosmos withdraw --delegate-address <delegate-address> --validator-address <validator-address> --chain-name seda --asset-name SEDA --gas-factor <gas-factor> --export-for-quorum-sign`
#### Withdraw Rewards
Withdraw rewards gained from staking to a validator.
`$ icepick workflow cosmos withdraw-rewards --delegate-address <delegate-address> --validator-address <validator-address> --chain-name seda --gas-factor <gas-factor> --export-for-quorum-sign`
{{ #include template-create-tx-1.md:content }}

View File

@ -11,6 +11,10 @@
#### Transfer Token
Transfer SPL tokens on Solana blockchain.
The following SPL tokens, provided to `--token-name`, are supported:
* [PYTH](https://www.pyth.network/)
`$ icepick workflow sol transfer-token --from-address <from-address> --to-address <to-address> --token-name <token-name> --token-amount <token-amount> --export-for-quorum --sign`
{{ #include template-create-tx-1.md:content }}

View File

@ -36,7 +36,7 @@
1. Flash `airgap.iso` to an SD Card:
* `dd if=out/airgap.iso of=/dev/<device_name> bs=4M status=progress conv=fsync`
* `dd if=out/airgap.iso of=/dev/<device_name> bs=4M conv=fsync`
1. Reset the computer, and boot the SD card

View File

@ -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)
## Trove
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 Trove system.
## Operator Key
@ -116,7 +116,7 @@ the total number of shards that exist. The minimum recommended threshold is
## Organization
An organization which owns the QVS and is responsible for funding the setup and
An organization which owns the Trove 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

View File

Before

Width:  |  Height:  |  Size: 85 KiB

After

Width:  |  Height:  |  Size: 85 KiB

View File

@ -1,13 +1,13 @@
# Introduction
Quorum Vaulting System (QVS) is an open source system of playbooks and
Trove 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.
The basic premise of QVS is that primary cryptographic material akin to a root
The basic premise of Trove 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
@ -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
Trove 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,7 +42,7 @@ a cold signing setup.
## Playbooks
QVS can be set up by using a set of highly opinionated playbooks which outline
Trove 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

View File

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

View File

@ -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 Trove is sharded. The
keypairs are stored exclusively on Smart Cards, and the PINs which protect the
Smart Cards are encrypted to Operator Keys.

View File

@ -30,7 +30,7 @@ This level of defenses is largely focused on remote attacks, and as such does no
* Co-working space
* Regular office (non specific to QVS)
* Regular office (non specific to Trove)
### Reference Design
@ -44,7 +44,7 @@ This level of defenses is focused on insider threats and as such requires a cons
### Examples
* Purpose specific facility for QVS
* Purpose specific facility for Trove
* Short term rental
@ -82,7 +82,7 @@ This level of defenses is focused on insider threats and as such requires a cons
locations simultaneously
* SHOULD be facilities owned by different organizations to reduce the risk of
collusion unless the organization who owns the QVS system has their own facility such
collusion unless the organization who owns the Trove system has their own facility such
as a [SCIF](glossary.md#secure-compartmentalized-information-facility-scif).
## Level 4 (SCIF)

View File

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

View File

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

View File

@ -1,5 +1,5 @@
# Software
This page outlines the software used for setting up QVS.
This page outlines the software used for setting up Trove.
## [[Stageˣ]](https://codeberg.org/stagex/stagex)
@ -39,7 +39,7 @@ BIP-0039 mnemonic phrase. BIP-0039 phrases are used to calculate a BIP-0032
seed, which is used for hierarchical deterministic key derivation.
This software is the backbone for all cryptographic actions performed as part
of QVS. It was developed by [Distrust](https://distrust.co) and is included
of Trove. 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.

43
trove/src/system-roles.md Normal file
View File

@ -0,0 +1,43 @@
# System Roles
There are several roles which are required to properly operate the Trove 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 Trove. 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
## 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 Trove 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 Trove 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 Trove are in tact. They verify instructions from [Approvers](#approver) and perform different actions which are part of the Trove system, ranging across hardware procurement, accessing SCIFs, preparing field kits, performing ceremonies and more.
As a Trove 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
Trove 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 Trove 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.

View File

@ -1,10 +1,10 @@
# Threat Model
QVS is designed according to a high-assurance threat model which ers on the
Trove 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
The assumption is made that attackers who target Trove 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
@ -18,7 +18,7 @@ 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:
To achieve this, the Trove focuses on reducing the risk by:
* Only using fully open source software and firmware to allow full verification
of their security properties
@ -64,7 +64,7 @@ Some additional assumptions are made to help contextualize the threat model:
## 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.
Different threat model levels allow an organization to start benefiting from the security properties of the Trove 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.