New Root

Authors: Benedikt Heintel
Marcus Mängel
Martin Gummi
Version: 1.5.1 of 2014-09-11

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: 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 ID = ID + 1

Sub Roots

r recursively identically generated as r − 1, signed with 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

  1. Bank opening hours: On Weekends not possible to recover keys
    Likelihood: high
    Severity: medium
    Action: Avoid
    1. Find vaults with 24/7 access with dual control and upfront registration
    2. press release
    3. offer a root deactivation tool for Roots and Sub roots
  2. Fire or natural disaster outbreak
    Likelihood: low
    Severity: low
    Action: Accept
  3. 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
  4. 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
  5. Maintenance work in both strongrooms
    Likelihood: low
    Severity: high
    Action: Accept
Risks of Escrow with vaults only
  1. Burglary into one bank’s vault compromises the keys
    Likelihood: low
    Severity: very high
    Action: Mitigation
    Destruction of data (how to?)
  2. Unauthorized access by bank employers or accredited access holders
    Likelihood: medium
    Severity: very high
    Action: Mitigation
    1. access only to checked, trustworthy personnel
    2. 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
  1. 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
  2. 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
  3. Extort secret from group member
    Likelihood: low
    Severity: high
    Action: Accept
  4. 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

Roots/EscrowAndRecovery/NewRootCertificatesForCAcert (last edited 2014-09-12 00:09:25 by MartinGummi)