{{{#!rst ======== New Root ======== :Authors: Benedikt Heintel, Marcus Mängel, Martin Gummi :Version: 1.5.1 of 2014-09-11 .. contents:: Introduction ============ | After the audit over the CAcert root certs failed in 2008, a *New Roots Task Force*\ [1]_ was created and generated several requirements and tasks for Roots generation [2]_, Roots Structure [3]_ and Escrow Procedures [4]_. Over several years, the output of the Task Force was somewhat low. | In 2012 the new elected board stepped in to take the first decisions on Escrow. | In 2012, Apple decided to disallow Certificates using the MD5 hash algorithm in iOS 5 and later [5]_. To prevent the CAcert community from further shortfalls with this issue, a new *New Root Initiative* was build with the authors of this document. | This short document is the Initiative’s proposal how to solve the further exclusion of iOS users, to be compliant to the future standards, and to be audit ready with the root certificates. Prerequisites ============= | To successfully roll out new roots, that are most likely compliant to the audit criteria, following tasks should be performed. It is recommended to nominate a project manager, generating a project planning and supervise the tasks to ensure timely and quality delivery. | Tasks are listed in Table [tab:tasklist]. +----------+-----------------------------------------------------------------+-----------------------------------------------+ | **No** | **Task** | **Responsibility** | +==========+=================================================================+===============================================+ | 1 | Decide on Escrow and Recovery (see Section [cap:escrow]) | CAcert Committee | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 2 | Decide on Roots Structure (see Section [cap:subroots]) | Policy Group | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 3 | Decide on Roots Content (see Section [cap:content]) | Policy Group | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 4 | Check, Correct, and Vote Security Policy (SP) to Policy | Policy Group | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 5 | Check and Correct Security Manual | Critical Systems Administration Team Leader | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 6 | Create Certificate Policy (CP) | Policy Group | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 7 | Create Certificate Practice Statement (CPS) for each Sub Root | Policy Group | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 8 | Assess Software Changes needed | Software Assessment Team Leader | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 9 | Define Processes (see Section [cap:processes]) | Policy Group | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 10 | Test Root Creation and Storage Process | Critical Team Leader | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 11 | Create New Roots | Critical Team Leader | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 12 | Test New Roots | Critical Team Leader | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 13 | Early Root Distribution | Critical Team Leader | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 14 | New Root Deployment | Critical Team Leader | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 15 | Communications (Press Release, Blog Posts) | PR Officer | +----------+-----------------------------------------------------------------+-----------------------------------------------+ | 16 | Decommission Old Roots | Critical Team Leader | +----------+-----------------------------------------------------------------+-----------------------------------------------+ Table: New Roots Task List [tab:tasklist] Root & Sub Roots creation ========================= | Root and Sub Roots creation is the core of the solution to heal the occurred issue within iOS. | Key creation is compliant with the Requirements the *New Roots Task Force* identified [6]_. The Task force numbering scheme is also applied here. All actions described hereafter are triggered by the Committee (z.1, SP9.2.1). Hardware & Software requirements -------------------------------- - Stand-alone fresh installed Linux OS - Tripwire (logging tool for audit) - entropy generator (e.g. Perl script) :: perl -e '$|++;(1 x$_)!~/^1?$|^(11+?)\1+$/&&print"$_ "while ++$_' - CD writer / smart card writer - Optional: Hardware crypto device (approx EUR 1000 each) The OS Setup needs to be done with 4 eye principle or run from a Linux live disk. After use, the configuration files need to be saved and - if installed - the laptop wiped. Root Key -------- Only a single Root certificate exists (z.2) which is kept offline (z.3). For the Root certificate (r) following applies: :math:`r := r - 1`. Tool for root creation: ~~~~~~~~~~~~~~~~~~~~~~~ openssl (parameter definition) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - parameter: - flags - key-strength - organisation info - validation - signature algorithm - hash algorithm Script ~~~~~~ - script should be used for creation; script need to test - Root :math:`ID=ID+1` Sub Roots --------- :math:`r` recursively identically generated as :math:`r-1`, signed with :math:`r-1`. Root Structure ~~~~~~~~~~~~~~ - root [offline]_ [root certificate] - unassured [intermediate certificate] - Client (SSO) - SSL - personal [offline]_ [intermediate certificate] - Client (SSO) - Encrypt - Sign (+ Code Signing) - SSL - entity [offline]_ (e.g. organisation) [intermediate certificate] - Client (SSO) - Encrypt - Sign (+ Code Signing) - SSL - new features [offline]_ [intermediate certificate] - objects [offline]_ [intermediate certificate] - Objects - NIST4 [offline]_ [intermediate certificate] each certificate needs a CPS, containing specifications to CP. Tools sub roots ~~~~~~~~~~~~~~~ See section [cap:hwsw]. Content of Roots ---------------- Regarding the content of Root Certs we follow the *New Roots Task Force*\ ’s recommendations [8]_ with following deviations: - PK Type: SHA-256 - Certificate Policies: Link to CP Party members ------------- - Critical System Administrators - System Administrators - Observer nominated by board shortly in advance to ceremony - Open to public The duty of the observer is to watch and document the process. There can be different observer at different sites. In any case, each action need to be performed by at least two people (SP9.2.2-d). Escrow ====== To secure: Private Key, Secret (Password) Private Key ----------- | create hash value | burn hash value and key two times on two different CD-ROM quality media / smart card (SP9.2.2-a/-b,C.3.c) Secret ------ | create hash value | burn hash value and secret two times on two different CD-ROM quality media / smart card (SP9.2.2-a/-b/-c) Storage ------- We identified two possible ways for storage of keys and secret: I) with bank vault only or II) with members and bank vault. - Two bank vaults (z.6, z.7) with each a set of key and secret, where each CD is stored in a separate sealed envelop. For each bank vaults nominate at least four people with access rights (z.4, z.5). Two persons are needed to get access to the vault (C.3.d). The vault needs to be physical located with a minimum distance of 100 km and at two different banks and in two different countries. - Two bank vaults (z.6, z.7) with each a key and a group of members holding each the Secret (z.6, z.7). Access and location as in I). Save storage needs to be verified at least every two years (z.8). Check needs to be done by two access persons and one observer. Transport --------- | The medium is placed in the sealed envelop at the escrow site. This is documented by the observer. | The transport needs to be done by at least 1 ABC’d person best on the same day of the root creation. | At the bank site the seals are checked by the 2 persons who have vault access and an observer. The check needs to be documented by the observer. Define Processes ================ Create Processes and Check Lists for - (Sub) Root creation - Bank vaults access (in/out/check) - (Sub) Root revocation - Disaster Recovery if vault/media gets destroyed Initial Risk Analysis ===================== Pros for bank vaults - Fire security - cheap (approx 35 EUR p.a. for 25 x 250 x 350 mm) - minimum rental 12 month - tamper proof and around the clock monitored safes - logged access - access models (dual control) possible **Why only two - instead of four - bank vaults?** - Short Time to Recover (one pickup location for both key and secret) - Cost (two are cheaper than four) **Why not two vaults in each bank?** - Additional Cost - No enhanced security against theft or disasters General Risks of Escrow ----------------------- #. | Bank opening hours: On Weekends not possible to recover keys | Likelihood: high | Severity: medium | Action: Avoid #. Find vaults with 24/7 access with dual control and upfront registration #. press release #. offer a root deactivation tool for Roots and Sub roots #. | Fire or natural disaster outbreak | Likelihood: low | Severity: low | Action: Accept #. | Unauthorised access to information where the vaults are located | Likelihood: medium | Severity: low | Action: Avoid | Classify information and restrict access to vault No., access list, and exact location #. | Poorly maintained access lists | Likelihood: medium | Severity: medium | Action: Avoid | During office hand-over, the old Committee commits a list of new board members and access personal to the strongroom #. | Maintenance work in both strongrooms | Likelihood: low | Severity: high | Action: Accept Risks of Escrow with vaults only ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #. | Burglary into one bank’s vault compromises the keys | Likelihood: low | Severity: very high | Action: Mitigation | Destruction of data (how to?) #. | Unauthorized access by bank employers or accredited access holders | Likelihood: medium | Severity: very high | Action: Mitigation #. access only to checked, trustworthy personnel #. access only after presenting authorisation letter issued by committee or upfront registration by committee (bank need to be able to handle this) Risks of Escrow with vaults and group of members ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #. | Group of members unavailable in total | Likelihood: medium | Severity: very high | Action: Mitigation | Board to tightly monitor status active group members; initialisation of secret hand over if one member leaves, deceases, or vanishes need to be established in timely manner #. | Loss of secret | Likelihood: high | Severity: very high | Action: Avoid | Policy to be implemented on how secrets need to be stored, handled, and destroyed; Policy to be monitored in regular time intervals #. | Extort secret from group member | Likelihood: low | Severity: high | Action: Accept #. | Conflict of interest, if critical admins are part of the group of members: live system and recovery plan | Likelihood: medium | Severity: medium | Action: Avoid | Avoid use critical system admins for Escrow Group Key Performance Indicators for Recovery ======================================= - Recovery in less than x hours (x to be defined) - Access to vaults by at least two accredited person in 100% of all cases - Access to data in 100% of all cases .. [1] https://wiki.cacert.org/Roots/NewRootsTaskForce .. [2] https://wiki.cacert.org/Roots/Contents .. [3] https://wiki.cacert.org/Roots/Structure .. [4] https://wiki.cacert.org/Roots/EscrowAndRecovery .. [5] cf. https://support.apple.com/kb/TS4133 .. [6] cf. https://wiki.cacert.org/Roots/EscrowAndRecovery .. [offline] offline: not connected to the internet .. [8] https://wiki.cacert.org/Roots/Contents }}}