(WIP) Ceremony #11
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,16 @@ | ||||||
| # Ceremony | ||||||
|
|
||||||
| An out-of-band provisioning of cryptographic keys is required to bootstrap cryptographic security among participants of re-vault. Countermeasures should be in place to minimize the risks associated with physical, network, and social engineering attacks that aim to compromise this process. Ideally this ceremony would not be too cumbersome for the humans involved and the scope for human error should be minimized. | ||||||
|
|
||||||
| ## Objectives | ||||||
|
|
||||||
| Prior to the ceremony, it is assumed that the architectural configuration has been specified, the devices and machines have been aquired and the appropriate software has been installed (including blockchain download for all full nodes). | ||||||
|
|
||||||
| 1. Each non-manager gets the hidden service details (.onion) for the set of co-signing servers that are each operated by a manager. | ||||||
|
There was a problem hiding this comment. This is the other way around 😅 There was a problem hiding this comment. I thought: managers generate .onion details prior to ceremony. During the ceremony these are shared with non-managers? There was a problem hiding this comment. Yeah, that's what i said:
Suggested change
There was a problem hiding this comment. I think I didn't state it clearly but I think we agree. Just to clarify: Managers generate .onion details when they set up the co-signing server. They will manage this machine and restrict physical access to it. During the ceremony the .onion address is shared with non-managers. Non-managers communicate with the co-signing servers but don't know where they are and cannot physically access them. |
||||||
|
|
||||||
| 2. Participants generate master (public, private) key pairs for their wallets. These must be backed up for disaster recovery processes. | ||||||
|
There was a problem hiding this comment. Hmm one could argue that the backup need to be done prior to exchanging the keys.. This makes me wonder if we won't end up with both a private and shared ceremony. There was a problem hiding this comment. Yes, each participant will need to set up their infrastructure before the ceremony, and we should specify that clearly. Both ceremonies are 'private' so maybe individual and group ceremony? There was a problem hiding this comment. That's the words I was looking for ! |
||||||
| > Securing back-ups will likely occur outside of the ceremony since each participant will do this independently. (Unless a variant of social recovery is employed among participants (as with [tatoshi wallet](https://tatoshi.io/)). | ||||||
|
There was a problem hiding this comment. Yeah, but I think it's outside the scope of this doc There was a problem hiding this comment. To be more precise: I think we shoudl document what should be done, not how it should be done. |
||||||
| 3. Participants exchange master public keys. | ||||||
|
|
||||||
| 4. Participants generate (public, private) key pairs for (authenticated and encrypted) communication for distributed signing processes, as defined by BOLT8. | ||||||
|
There was a problem hiding this comment. How do they exchange them ? If 256 bits keys i hardly imagine all of them being able to copy 64 hex characters There was a problem hiding this comment. We need to figure out where they are generated and stored. But I agree, some out-of-band communication like QR code could work. |
||||||
|
|
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: acquired
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What precisely need to be installed prior to the ceremony ? On the top of my head i'd say that since they will have to configure xpubs and onions, they'll need a Revault wallet. So they'll need a synced
bitcoind(i'm assuming this but since they don't need no balance nor transaction i'm not even sure it's required).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose it should be specified according to the role of the machine.
Sync Server: sync server app, tor
Co-signers: bitcoind (fully synced), co-signer app, tor
Watchtowers: bitcoind (fully synced), watchtower app, tor
Manager PC: bitcoind (fully synced), revault wallet
Non-manager PC: bitcoind (fully synced), revault wallet
Hardware Security Module: wallet functionality (including PSBT, and secure PST storage)
What is missing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tor for the wallets too, otherwise looks good.