---- [[Roots/EscrowAndRecovery/CZ|česky]] | '''english''' ---- Part of the [[Roots/NewRootsTaskForce|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. <> == Preamble == A secure way to escrow and recover the root key is typically seen from come from one or more of these ideas: * A FIPS Level 3 hardware platform or equivalent such as Common Criteria. This approach describes how the device resists an open-access attack to the hardware. * A cryptographic key-sharing scheme that splits the key across multiple stores. * A governance structure that selects people, and organises the many people to come together (or at least agree) and reconstruct the key, and ensures that this act is done according to design not interference. Different folks take different pokes. A focus on one and only one of the above likely leads to [[http://xkcd.com/538/|a blindspot which is easily exploited]]. {{http://imgs.xkcd.com/comics/security.png}} 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. || z.1 || The Board is in control of the roots. || ''implied by'' [[https://svn.cacert.org/CAcert/CAcert_Inc/Agreements/ManagementAssertion.html|MA]] || Actions are under the Board's instructions. || || z.2 || A single top-level root signs (a) sub-roots for certificate issuance, and (b) CRLs over its sub-roots, only. || [[https://community.cacert.org/board/motions.php?motion=m20100117.3|m20100117.3]] [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2]] [[https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_end_entity_certificates_directly_from_roots|m/CA/PP]] [[https://wiki.mozilla.org/CA:Recommendations_for_Roots|m/CA/RfR]] || One top-level root for this escrow project. || || z.3 || The (top-level) root is offline. || [[https://community.cacert.org/board/motions.php?motion=m20100117.3|m20100117.3]] [[https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_end_entity_certificates_directly_from_roots|m/CA/PP]] [[https://wiki.mozilla.org/CA:Recommendations_for_Roots|m/CA/RfR]] || This is a popular implication of z.2, and an expectation of some security observers. || || z.4 || The Board must be able to recover the root independently of the critical team. || [[https://lists.cacert.org/wws/arc/cacert-root/2010-02/msg00007.html||root mailinglist]] || The CA needs to deal with the implications of the entire critical team / systems wipe out. || || z.5 || The method must be reliable. || implicit || Avoid sexy cryptography. || || z.6 || Cost effectiveness || [[https://lists.cacert.org/wws/arc/cacert-root/2010-02/msg00004.html||root mailinglist]] || CAcert doesn't have a lot of money. Having expensive Root escrow criteria is not desirable || || z.7 || Speedy recovery || [[https://lists.cacert.org/wws/arc/cacert-root/2010-02/msg00004.html||root mailinglist]] || If we do need to enact this procedure, chances are that it needs to be carried out quickly || || z.8 || There must be a very low risk of loosing key confidentiality || [[https://lists.cacert.org/wws/arc/cacert-root/2010-02/msg00004.html||root mailinglist]] || Don't break the CA to meet the escrow requirements. || === Policies === <> Security Policy/Manual authorises procedures under [[SecurityManual#RootKeyManagement|SM9.2]]. SP lays down several stipulations effecting the escrow / backup situation: || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#SP9.2.1|SP9.2.1]] || Root keys are generated only on instruction from the Board. || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2-a]] || Root keys must be kept (backup, copy of) on reliable removable media used for that purpose only. || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2-b]] || Private Keys must be encrypted and should be dual-encrypted. || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2-c]] || Passphrase must be strong and must be separately escrowed from media. || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2-d]] || Dual control must be maintained. || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2-e]] || The top-level root must be escrowed under Board control. || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2-f]] || Subroots may be escrowed by either Board or Systems Administration Team. || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.3|SP9.2.3]] || Recovery must only be conducted under Arbitrator authority. || Also see other keys escrowed by sysadm team at [[SecurityManual]]4.3.7. The [[http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html|Security Policy]] is in DRAFT. The [[SecurityManual|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 * [[http://audit.cacert.org/drc/browser.php]] (the comments and verifications related to terminated (FAIL) 2009 review). This presentation is published. You can click on the roots selection to see more. * [[http://rossde.com/CA_review/|David Ross's primary document]] * For CAcert client-certificate holders only: [[https://fiddle.it/app/crowdit/search/cat/roots|CrowdIt]] is an emerging disclosure tool (based on the old browser). == 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 [[https://svn.cacert.org/CAcert/CAcert_Inc/Agreements/ManagementAssertion.html|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: * A computer is installed in the rack, but is not powered up. * A computer is in another facility (room?) and CRLs are sneaker-netted across on USB sticks. * A computer is powered up, but the only capability it has is to produce CRLs. E.g., the receive line is cut, it can only broadcast. For more points, it uses radio, and has no receiver. * An encrypted USB (or [[Roots/EscrowAndRecovery/RandomHardware|similar]]) stick sits in a safe, locked to the rack, chained to an Assurer's wrist. Every X days: a. the CRL server is unplugged from webserver, the USD stick is inserted, passphrased entered, a. the CRLs are signed, a. the USB is unplugged, memory scrubbed, CRL server plugged back in. 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 a. simplicity, a. the use of tools that are available in the future, and a. 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/Notary]] * [[Roots/NewRootsTaskForce/USB]] * [[Roots/EscrowAndRecovery/MultiMemberEscrow]] * [[Roots/EscrowAndRecovery/ActorPassword]] * [[Roots/EscrowAndRecovery/PassSigningServer]] * [[Roots/EscrowAndRecovery/EnvelopeBankNotaryEscrow]] * [[Roots/EscrowAndRecovery/SSSS]] * [[Roots/EscrowAndRecovery/RedundantServers]] * [[Roots/EscrowAndRecovery/RandomHardware]] ---- . CategoryAudit . [[CategoryNRE|CategoryNRE]] . CategoryNewRootsTaskForce