Roots/EscrowAndRecovery/SSSS

Overview

SSSS enables recovery by a number of people in a set.

Principles

1.- We encrypt the root key to an OpenPGP key created for escrow purposes. We store the encrypted root key into an USB flashdrive, and the drive inside Envelope 1.

2.- The same person that created the passphrase used to protect the secret key, enters it in SSSS and creates several shares of it, in an m/n scheme. He clear signs each share (including a descriptive title) with that key, storing each signed share in a plain text file (that way, we can check the shares have not been altered).

3.- The shares are distributed to the board members (carrying them in USB flash drives, or by other way).

4.- The private OpenPGP key is stored (protected by the passphrase, of course) in a USB flash drive, and the drive is put inside Envelope 2. The only person that can't keep Envelope 2 is the one that created the passphrase (but unless that person also gets Envelope 1, there is no risk involved).

Advantages:

Independence from banks or notaries.
Low cost: we need the USB flashdrives, and nothing more.
We can set any threshold we want. It can be a 3/5 for board members, or even 35/35 for all associated members (the idea is always have some spare shares in case somebody cross the street without looking first).
We can copy Envelopes 1 and 2, to have redundancy. Each copied set can have its own set of shares (at this point we should consider buying USB flash drives in bulk).
Celerity: as long as we can communicate with the share holders, they can provide their shares very fast, by encrypted mail, etc. As long as there is 1 trusted person to receive the shares and operate the software in case of need, there would not be problems. (But would this be considered secure enough?

Disadvantages:

In a handover, how can we be sure the former board members destroy their copies of the share?(CARS?) And how do we know the persons having Envelopes 1 and 2 are not making copies? If we have enough handovers, maybe we will reach a time when there are enough copies of the envelopes and the shares to make feasible to gather enough people to be able to find m different shares. (but if we are creating increasing amounts of people angry enough to do that, maybe we would have bigger problems than certificate escrow).
If there is not handover, we can lose the secret (unless we have some kind of backup, like another set of shares in hands of other people)
If there is not handover, we may recover the passphrase using the secondary scheme (like 20/35 association members), but, how will we recover the USB drives?

Discussion on N-of-M

Bernd: I dont think it is a good idea to create the secret key on any media as a whole. The creation process should end in a proper N-of-M split secret. Ideally of course you use chip cards who support this process in hardware. -- BerndEckenfels
iang: are you talking about creation or about escrow? We have to distinguish because they are both very different security questions with different ramifications. Then, we have to identify a working practical method of it. The notion of N-of-M is just a paper suggestion from the cryptography world, it is not necessarily a practical solution. Here we need solutions that are practical, not elegant on paper.
Bernd: Both situations. I don't see the need to ever store the secret key as a whole on any media. There are some fancy secret splitting algorithms, but I guess you can get pretty well along with a simple 3-of-5 by using XORs. My idea is, that the generation process results in escrow artifacts (i.e. 5 USB dongles, maybe passphrases).
iang: OK, for creation it is hard. There are papers that suggest how, and there are even a few implementations. But these require quite serious work and analysis and confidence. Tough, so basically I think CAcert thinks it has more important problems. It is easy enough to use one hardware and then destroy it afterwards.
- Bernd: Well, I was not expecting to do a RSA Key generation with split secret. I was just imagine a live-cd system (with no harddisk) and creating the keys in ramdisk. Then you can use shellscripts to process them.
iang: escrow (a): right this is where it gets much more interesting, because a single key is now sitting there and becomes a target. In effect however this is what was envisaged. But it was not done by cryptographic key-splitting algorithms, rather by simple encryption techniques. E.g., to achieve 2 of M, we simply encrypt the full key, and give one half the passwords and one half the encrypted key. We can also do multiple encryptions, so that each person holds a password and an encrypted key. If we wanted to do 3 of M, it can be also done, but gets more complex.
iang: escrow (b): However, by far the biggest concern is not the crypto but how we guarantee that the N of M are in fact available and ready when we need them. If there is any chance of this not working out when we need it, it isn't an N-of-M scheme but a D-o-S scheme. It is for this reason CAcert actually took the easier path in November, and _even that caused problems_.
iang: so where do we go from here? Well, first we map out which people need to be present to present to unlock the root key. 1 director or 2? 1 sysadm or 2? 1 outsider or 2? arbitrators? etc etc. Then we have to design an encryption scheme that best matches that. And then we poke that to see where it fails.
- Bernd: yes policy is more important. Personally I think a 3-of-5 scheme looks good. It might be possible to actually make it 3-of-7 whjereas the baord members each have 2 parts (so board+admin or admin+admin+arbitrator will be enough).

Chokhani et al

Answer these issues from Chokhani et al 4.6.2:

Private key (n out of m) multi-person control
Private key escrow
Private key backup
- Private root keys are backed up off-site in encrypted form.
Private key archival
Private key transfer into or from a cryptographic module
- Private Key generation and transfer off the signing machine is done according to the Security Manual. .... actually
Private key storage on cryptographic module
- The key is stored on an encrypted partition. The signing server can only be started with direct systems administration access.
Method of activating (new) private key
Method of deactivating (old) private key
Procedures for destroying private key

Note that Chokhani is a guideline for a CPS, and is not a criteria or binding document. CAcert has followed the headings layout in its CPS, but differs in its outsourcing to AP, SP, etc.

Procedures

Alternatives

Funding

Key Storage

Key Escrow

Assessment against Requirements

Roots/EscrowAndRecovery#Requirements for Escrow/Recovery

Author Assessment

This is the assessment by the non-author - feel free to fix/adjust:

Implicit requirements

z.1	board posession is defined by #3
z.2	subroot/crl policy isn't addressed here.
z.3	top root is offline in pieces according to the MxN rules
z.4	board control independance of admin team defined by z.1
z.5	costing not done - board members need to meet for escrow??
z.6	reliability needs attention
z.7	speedy recover - as quickly as N members can get together.
z.8	loosing key confidentiality - careful management over destruction/handover at board changes

Security Policy Requirements

SP9.2.1	major of board control(possession) implies permission
SP9.2.2-a	backups are defined (loosely)
SP9.2.2-b	no - single passphrase only
SP9.2.2-c	yes - password is shared
SP9.2.2-d	dual control maintained though NxM split
SP9.2.2-e	root control is in board hands.
SP9.2.2-f	subroot control (not defined - assuming sysadmin team)
SP9.2.3	arbitrator control for recovery

DRC Requirements

C.3.c	The root certificate private key is stored secure from electronic and physical compromise.

C.3.d	The root certificate private key is stored by the CA and not by any outside party.

C.3.e	The root certificate private key pass-phrase (i.e. password) is not stored electronically or physically.

C.3.f	The root certificate private key pass-phrase (or parts thereof) is known only to CA personnel

C.3.g	Provision is made to prevent loss of the root certificate through a single-point of failure of electronic equipment (including physical destruction of such equipment).

C.3.h	Provision is made to prevent loss of use of the root certificate resulting from the loss of one key person.

C.3.i	Use of the root certificate private key requires cooperative action by at least two CA personnel.

Community Member Assessment

You, the community member are encourages to assess this procedures also. Please fill out the table below with a 1-10 rating with 1 being strongly meets criteria and 10 being fails criteria.

SP9.2.1

SP9.2.2-a

SP9.2.2-b

SP9.2.2-c

SP9.2.2-d

SP9.2.2-e

SP9.2.2-f

SP9.2.3

C.3.c

C.3.d

C.3.e

C.3.f

C.3.g

C.3.h

C.3.i

DRC

Comments: (as you wish)

Community Member Assessment by Daniel Black