• Roots
• EscrowAndRecovery
• MultiMemberEscrow

Overview

This method gives multiple community members possession of the encrypted form of the root key with other members having the unlocking mechanism.

Principles

• The root key is encrypted by multiple public keys (Guardian Keys) to form the root key collection
• The root key is held in encrypted form by a number of community members called Key Holders
• The private keys related to the public keys that encrypted the root are held by community members called Key Guardians who are independent of the Key Holders
• Key Holders and Key Guardians are under direction of the board to undertake activities requiring escrow/recovery
• The process is managed by a board nominated Coordinator who is not a Key Holder

Notes:

• The selection of the Key Holders is particularly important. There will be enough for redundancy however the loss of their media containing root keys incurs an accumulated risk to CAcert.
• Key Holder could be Organisation Assured community members who have a long term interest in the safety of our root key.
• The Key Guardians are to be independent of the Key Holders. Unauthorised collaboration is a root compromise.
• A large number of key guardians is desirable. Individual compromises of key guardians will reduce the set of available decryption keys as they are deleted by the Key Holder.
• Key Holder identities could be kept as a board secret protecting their physical location, though an escrow would reveal it.

Key Holder Agreement

I, XXX, as a key holder for CAcert agree that:

• Actions that I perform with the root key that I control will be under direction of the CAcert board.
• The encrypted root key in my possession will remain on media dedicated for the purpose of storing the key and I will not use it for any other purpose.
• I will store the encrypted copies of the root key collection not connected to a computing system in a physically secure location under my control.
• I will never have more than three copies of the root key collection in my possession.
• I will destroy media contents as directed by the Coordinator.
• The transport key I provide to the Coordinator will be not generated and used while network connected.
• Should I engage in any substantial relationship (beyond acquaintance) with a Key Holder I will notify the board.
• Should the root key media in my possession be lost, destroyed or stolen I will notify the board.
• Should I suspect that the root key media in my possession has been accessed by another party I will notify the board.
• I will try to be available for a root escrow meeting whenever called upon by the board.
• The actions I undertake will be in conformance with the Security Policy and Security Manual.

Key Guardian Agreement

I, XXX, as a key guardian for CAcert agree that:

• Actions that I perform with the root key that I control will be under direction of the CAcert board.
• The Guardian Key in my possession will remain on media dedicated for the purpose of storing the key and I will not use it for any other purpose.
• I will store the Guardian Key offline in a physical secure location under my control.
• I will never have more than three copies of a Guardian Key in my possession.
• The Guardian Key in my possession will be stored by the most complex password that I can remember. If I decide to store this pass-phrase it will be on separate media dedicated to this purpose stored in a physically different location under my control.
• I will destroy the Guardian Key media contents as directed by the Coordinator.
• Should I engage in any substantial relationship (beyond acquaintance) with a Key Guardian I will notify the board.
• Should the Guardian Key media in my possession be lost, destroyed or stolen I will notify the board.
• Should I suspect that the Guardian Key media in my possession has been accessed by another party I will notify the board.
• I will try to be available to deliver the Guardian Key whenever called upon by the board.
• The actions I undertake will be in conformance with the Security Policy and Security Manual.

Procedures

Escrow Meeting (aka Root Ceremony)

1. The board decides an escrow meeting is needed.
2. Nominated board members advise all Key Holders, Key Guardians and potential Coordinators and determine who is available.
3. The board will select a Key Holder and Coordinator in the same geographic area to conduct the Escrow meeting.
4. The board will advise the community of the choice of Coordinator.
5. The board will ask the community to send new Guardian Keys (public keys) and their contact information to the Coordinator.
6. The board will ask all Key Holders to send a Transport public key to the Coordinator.
7. If a recovery operation is underway, the board will ask the current Key Guardians to send their Guardian Keys (private keys) to the Coordinator.
8. The Coordinator prepares media containing new and old Guardian Keys and the Transport Keys.
9. The Coordinator organises hardware and compatible freely available operating system software to be present at meeting.
10. The Coordinator arranges a time and place with the Key Holder.
11. The Coordinator advises the board of the time and place and seeks community witnesses to the event.
12. The Coordinator and Key Holder meet with witnesses for the escrow meeting.
13. The Coordinator, Key Holder and witnesses verify that the software at the meeting matched the publicly available version.
14. The software is booted on the hardware (not networked).
15. If a recovery operation is underway, the encrypted root key and Guardian Keys are loaded. The root key is decrypted on to non-volatile memory with the first Guardian Key that works. Second decryption is possible to cross-check.
16. (insert purpose-specific sub-procedure here; see below for details)
17. The root key is encrypted individually with all the new public Guardian Keys.
18. The collection of encrypted root and OCSP keys is copied on to a number of blank media, verified given to Key Holders present.
19. The collection of encrypted root and OCSP keys is zipped up and individually encrypted with all the Transport Keys of Key Holders. This is placed onto media for the Coordinator to distribute.
20. The Coordinator wipes the media containing the original Guardian Keys.
21. The Coordinator sanitises the RAM used on the hardware (to mitigate Cold Boot attacks).
22. The meeting disbands.
23. The Coordinator gives the Key Holders the newly encrypted root key (transport encrypted as well).
24. The Key Holders will store their encrypted roots offline, optionally removing transport encryption.
25. The Key Holders wipe previously held encrypted root keys, if any.
26. The Key Guardians wipe the old Guardian Keys, if any.
27. The witnesses, Coordinator and Key Holders report to the board/community on their progress
28. The Coordinator updates the Key Guardians contact list.

Notes:

• Transport is deliberately vague here. It could be email or registered post. Either way it is protected by an offline transport key.
• Many actions of decryption and re-encryption are to be scripted in advance.
• Witnesses will have an extensive list of requirements/procedures to observe.

New subroot sub-procedure

In the meeting procedure above the specific procedure is:

1. Subroots are generated.
2. OCSP keys/certificates are generated for each subroot.

3. A series of CRLs is generated (omit? - pending policy decision).

4. Subroot and OCSP private keys are stored in the same manner as the root private key in possession of the Key Holders.
5. The OCSP keys, CRLs and Subroots are encrypted using a transport key. This transport key has a private key is under dual control of the critical system administrators.
6. The Coordinator transports the encrypted subroots (and CRLs, if any) to a critical system administrator.
7. After delivery confirmation the Coordinator deletes their current copy of these files.

New root sub-procedure

In the meeting procedure above the specific procedure is:

1. The new root key is generated (Roots/CreationCeremony)

2. The OCSP key/certificate for the subroot is generated
3. The Procedure for issuing subroots above is carried out

A Key Guardian leaves the community

(This also applies if their key is stolen, destroyed or otherwise lost.)

1. Each Key Holder is instructed to overwrite the encrypted root key corresponding to the Key Guardian public key.

Key Holder leaves community

On Board direction the Key Holder will:

1. Ask for the Key Holder's media to be transferred to another nominated Key Holder; or
2. Ask any Key Holder to transfer their contents to another nominated Key Holder and destroy the media in some recorded way.

Key Holder loses key/media or leaves community without notice

1. A loss assessment is undertaken by the board and whoever has knowledge of the events.
2. With the accumulated risks caused by losses reach an unacceptable threshold the board will issue new roots.

Extra Key Holder(s) needed

1. The board decides who the extra Key Holder(s) will be.
2. The board instructs an existing Key Holder to encrypt the root key collect with a transport key and transport it to the extra key holder(s).

Media degradation / obsolescence

1. Board asks key holders to verify media yearly. Failed media is destroyed and the Extra Key Holders Needed procedures is undertaken with the existing Key Holders as the recipients.
2. If the current stored media is obsolete Key Holders can transfer the encrypted contents on to the current new media type and destroy the old one.

Variants

Double Encryption

Some more info behind the rationale for double encryption requirements came to light on the policy list.

As an alternative where Key Guardians send in two keys - PGP and X.509 for encryption purposes. The root key is then encrypted with the PGP key followed by the X.509 of all other parties. This effectively gains three person control (key holder, key guardian (PGP) and key guardian (X.509)).

Funding

This method of escrow was designed around limited funds and high redundancy for key availability.

Key Storage

The root key is stored at the premises under the control of the key holder. Physical security requirements are reduced due to the strength of encryption applied to the key. The cost of media ($AU 0-20) is borne by the key holder, as is any physical security that they apply.

Key Escrow

The Escrow Meeting (aka Root Ceremony) occurs locally within the area of the coordinator and the key holder. The Coordinator will be under a lot of pressure to conduct this operation quickly and smoothly according to the defined procedure. While it is not expected that they will need to travel more than across a city/district travel costs of $AU 50 could be reasonable.

Expenses involved in gathering hardware required to perform the procedure could be up to $AU 500. It is anticipated that standard commodity hardware could be used to perform there ceremony with non-volatile storage (e.g. disk) removed/disabled.

Given the stress and inconvenience to the coordinators life by imposing a high priority task of key escrow requiring many hours of time I propose a bursary of $AU 140 for the work performed.

Assessment against Requirements

• Roots/EscrowAndRecovery#Requirements for Escrow/Recovery

Author Assessment

• This is the assessment by the proposal author:

  Implicit requirements

  z.1	The board is in control by its direction and selection of trustworthy Key Holders and Coordinators
  z.2	There is a subroot and CRLs generates as part of the Key Escrow Meeting
  z.3	The root key is offline with each Key Holder
  z.4	No part of the system depends on critical administrators - only a destination or the generated keys/roots/subroots as directed by the board.
  z.5	A number of independently encrypted copies root key of the root key are on each media. A number independent copies of this collection is maintained.
  z.6	The escrow can be completed at any Key Holder location around the world. Transport of subroots/crls back to the critical system location is by any transport - encrypted email if needed. As such the only cost the time and transport of the coordinator and Key Holder. Only volatile media is used to store unencrypted root keys avoid hardware destruction costs. Encrypted root keys with Key Holders are PKI encrypted rather than simple password protection and don't need as much sanitisation
  z.7	The number of key holders and the process to select them ensures that the recover with the most available key holders can occur.
  z.8	The confidentiality relies on the Key Holder and Key Guardian's loyalty and of their protection of media

  Security Policy Requirements

  SP9.2.1	Board instruction required to start any escrow procedure. The board selects trustworthy Key Holders and ensures independence of Key Guardians
  SP9.2.2-a	The Key Holders are required to put the key on specific purpose media. The redundancy is achieved with multiple keyholders or multiple media if the Key Holder decides.
  SP9.2.2-b	The root keys is encrypted using PKI. The PKI private key is password protected by the Key Guardians
  SP9.2.2-c	The passphrase is as strong as each guardian decides to make it. The strength of the scheme is the physical and logical separation between Guardian Keys and the encrypted root keys. Compromise/loss of guardian keys can be cleaned up by removing that encrypted item by the Key Holder
  SP9.2.2-d	The independence of the Key Holder and Key Guardian ensures the dual control. The encryption scheme enforces the dual control. The only unencrypted root key occurs in the middle of the root ceremony with the Coordinator and the Key Holder excising dual control under the supervision of witnesses
  SP9.2.2-e	The board defines the Key Holders and instructs the Coordinator to escrow the key to them.
  SP9.2.2-f	Subroots are generated on root instruction and are passed to the critical systems administration team for deployment. Dual control over sub-roots is maintained with the dual control of a transport key.
  SP9.2.3	A decision to perform any recovery procedure that is not listed here will be done by arbitrators direction. Key Holders and Key Guardians agree to the their scope of action.

  DRC Requirements

  C.3.c	The root certificate private key is stored secure from electronic and physical compromise.
  Electronic compromise protected by not having the key holder in possession of a private key to decrypt the media.
  Physical compromise. key holders agree to some minimum physical security standard but otherwise the cryptography also protects against physical compromise.
  C.3.d	The root certificate private key is stored by the CA and not by any outside party.
  Key Holders and Key Guardians are community members of CAcert
  C.3.e	The root certificate private key pass-phrase (i.e. password) is not stored electronically or physically.
  The root key is not directly protected by passphrase. Each Key Guardian agrees to place controls over their passphrase as per security policy 9.2.2-f
  C.3.f	The root certificate private key pass-phrase (or parts thereof) is known only to CA personnel
  There is no root key passphrase. The passphrases are stored by the Key Guardians will be revoked by the destruction of the associated encrypted root key in accordance to the "A Key Guardian leaves the community" procedure above and their agreement.
  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).
  Multiple Key Holder and many more Key Guardians protect against a single point of failure.
  C.3.h	Provision is made to prevent loss of use of the root certificate resulting from the loss of one key person.
  The entire cryptographic regime, separation of roles and procedures ensures dual control.
  C.3.i	Use of the root certificate private key requires cooperative action by at least two CA personnel.
  Key Holder and Guardians are independent. Their combined actions are required to have a root key unprotected.

Community Member Assessment

• You, the community member are encouraged to assess these procedures also. Please fill out the table below with a 1-10 rating, with 1 meaning "strongly meets criteria" and 10 meaning "fails criteria".

  Z1

  Z2

  Z3

  Z4

  Z5

  Z6

  Z7

  Z8

  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

  Z

  SP

  DRC

  Comments: (as you wish)

Community Member Assessment by Daniel Black

• Z1	Z2	Z3	Z4	Z5	Z6	Z7	Z8	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
  3	1	1	1	4	2	1	3	SP2	2	1	3	1	2	2	2	DRC2	1	3	1	1	1	1

Comments:

• (Note this is the author's assessment - beware of bias)
• SP9.2.2-b dual encryption - just seems to be an avenue for dual control. This proposal exercises physical possession as one control and encryption by different party as the other. In my assessment I've used the password as the defined second encryption mechanism, which is technically is underneath, however maybe not what the SP intends.

Community Member Assessment by XXXXX

---

• CategoryAudit

• CategoryNewRootsTaskForce