Part of the task to create new roots is deciding how to recover them in an emergency. This was one of the big flaws from the 2008 project. Now we fix it.

Contents

  1. Preamble
  2. Requirements
    1. General
    2. Policies
    3. Audit Criteria (Obsolete)
  3. Discussion
    1. z.1 Control
    2. z.2 Single Root
    3. z.3 Offline
    4. z.4 Recovery
    5. z.5. Reliability
    6. z.6 Cost-Effective
    7. z.7. Speedy recovery
    8. z.8 Secrecy of Root Risk
  4. Proposals

Preamble

A secure way to escrow and recover the root key is typically seen from come from one or more of these ideas:

Different folks take different pokes. A focus on one and only one of the above likely leads to a blindspot which is easily exploited.

One component alone is unlikely to do it. We need an integrated scheme that chooses elements and combines them into a holistic scheme providing good security for low cost. Which also means we need a team of people with strengths in the different areas -- This is a rather difficult project and will not be solved by a maillist post!

With that caveat, onwards!

Requirements

The Roots Escrow project is driven by many requirements drawn from the following sources:

General

Some requirements are not explicitly written down in clear form, so the following is an attempt to put them in the same form as the others. See below for expanded commentary.

Policies

Security Policy/Manual authorises procedures under SM9.2. SP lays down several stipulations effecting the escrow / backup situation:

SP9.2.1

Root keys are generated only on instruction from the Board.

SP9.2.2-a

Root keys must be kept (backup, copy of) on reliable removable media used for that purpose only.

SP9.2.2-b

Private Keys must be encrypted and should be dual-encrypted.

SP9.2.2-c

Passphrase must be strong and must be separately escrowed from media.

SP9.2.2-d

Dual control must be maintained.

SP9.2.2-e

The top-level root must be escrowed under Board control.

SP9.2.2-f

Subroots may be escrowed by either Board or Systems Administration Team.

SP9.2.3

Recovery must only be conducted under Arbitrator authority.

Also see other keys escrowed by sysadm team at SecurityManual4.3.7.

The Security Policy is in DRAFT. The Security Manual specifies the details of the Security Policy.

Audit Criteria (Obsolete)

This chapter is obsolete, since the David Ross Criteria (DRC) are not longer maintained and common industrial standards should be followed.

Here are the criteria from Audit that are applicable:

Number

Criteria

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.

See the full criteria at

Discussion

Feel free to add your commentary, but leave room for the debate (don't delete people's comments, add your name and an alternate).

z.1 Control

The implication that is widely drawn is that the management of the CA is in control. This is not expressed directly in criteria, but is implied by the audit process's Management Assertion and similar. For CAcert, this typically would be taken to mean that the Board is in control.

The board being in control is primarily about subroots. It might be tested thusly:

x.1

the board can issue its subroots when and how it desires, and

x.2

others cannot issue subroots when and how they desire.

Note that this does not mean that there is no root located in others' hands, just that they have controls over them that back up to the Board. It also doesn't mean that the root is located in the Board's hands, but that the Board can instruct and thus control the issuances of subroots.

z.2 Single Root

Sources are varied. Mozilla finds multiple roots unpopular.

It is difficult to nail the security logic behind this requirement down, and there are often good reasons why this is not a hard criteria. But for now it is the consensus of CAcert and others.

It may be that the team recommends a second backup set of roots, however this may be pointless if the risks to the private keys remain more or less the same, the switchover cost is high, and the cost of creating a new set is lower than the switchover cost (e.g., easily included in the recovery cost).

z.3 Offline

The root should be offline. But offline is undefined. At a minimum, offline means it is not accessible via "the line" typically being the net these days. At a maximum it might be treated as being powered-down, disconnected and physically secured. Where this becomes difficult is the production of CRLs. Consider these thought experiments:

Etc, etc. The thing here is to invent a design that meets the requirements above, is reliable, and feels good.

z.4 Recovery

For Disaster Recovery, we need redundancy of some form or other. See also sp.9.2.2-e above.

z.5. Reliability

The method must be reliable. This is basically a limitation over sexy cryptographic theory designs. E.g., Secret Sharing will likely not work if the board has to swap shares (every year) more times than it recovers (in 5 years), or if it requires exotic software. Systems with complications do not survive over time.

The procedure defined here should be usable for the next 30 years. This implies

  1. simplicity,
  2. the use of tools that are available in the future, and
  3. storage that survives personnel changes.

Note also that the above implies the Board will not be doing the work, because the Board changes frequently, and has a lot of difficulty in handover. It could be an entirely separate team, as long as there is sufficient lack of correlation between the two teams at hand (critical and "recovery").

z.6 Cost-Effective

Think of this as: every year we can run an exercise, and cost does not become an issue. Also note the CRL problem.

z.7. Speedy recovery

Disaster Recovery planning suggests we need to be able to issue CRLs within 24 hours.

z.8 Secrecy of Root Risk

Though implied by all the criteria, it is worth stating again here as it is often lost in the discussion. Also, this restatement allows us to assess the system as a whole.

Logic: Each additional copy of the key increases the risk of breaching its secrecy, absolutely. This risk should be very low. If it rises to some unacceptable watermark, it breaks the rest of the CA. The PKI single-root design is well known for this brittleness.

Proposals

Roots/EscrowAndRecovery (last edited 2015-12-10 19:36:51 by AlesKastner)