Roots/CreationCeremony

Intro

In the project to project to create new roots for CAcert we need some form of ceremony for creation of the root.

Creating a new root is a big deal; it should be quite visible and involve many people. There is no way that this will work by simply telling someone to go off and do it. We need to generate a visible and clear signal that the process involved a lot of people, and all of those people would have to stuff up big time for it to have been bad.

Security Manual / Policy

See the SM and Security Policy for binding controls.

Other Dcumentation

Roots/TechScript has technical things.

A Ceremony for Creation

Here is some ideas for a generic root (either a top level one or a signed/low level one). It should be noted that this script was not followed in recent creation of root.

Preparations

The Board
1. prepare the decision by board instructing the creation of the root.
  - choice of top level root or subroot dictates how many people N is, see below
2. prepare the Roots/Contents as far as possible
3. designate the 1 or 2 Board members to be in attendance (part of N)
  - these 1,2 members should be given full authority to act for the Board on the day so as to not slow down late changes
4. designate the team leader
  - experienced in technical and governance issues
  - probably one of N
Team Leader
1. designate the system administrators (part of N, to total N with addition of Board member(s))
2. assist Board to finish off the Roots/Contents
  - advise board and sysadm of final contents
  - this is a negotiation with board; not a formal approval process
  - there is no need to wait for "approval" as changes can be negotiated on the day with Board members
  - Board retains authority to burn the entire root any time....
3. designate the precise OS + OpenSSL distros needed
  - advise all of N of the precise version and software so that they can create their CDs.
  - e.g., Knoppix, or as approved by SecurityManual
4. prepare the hardware components needed
  - ensure that the hardware used has the support of the OS chosen.
5. designate the sneakerware transmission medium
  - no wired or wireless networks permitted
  - E.g, USB memory sticks.
6. designate the escrow media (e.g., another N USB memory sticks)
7. purchase N+x sets
  - x== extras for reliability
  - with one other person to ensure no sneaky units
  - from ordinary retail store, randomly chosen, not online
8. bring tools and power
  - UPS would be useful
9. designate documentation method
  - video camera to record the progress
  - photo camera
Each attendee:
1. prepare a random source generator
2. bring own laptop for reading distro CDs.

The Ceremony

N people meet at offline location with:
1. offline location must be acceptable to all (not a pre-planned location)
2. each brings a source of random numbers
3. each brings CD download of approved OS + OpenSSL
4. each with one part to build one machine?
5. handful of small usb memsticks for escrow?
6. documentation tools.
7. each brings own laptop
each of N confirms:
1. the CD installs as being the same thing (using own laptops to sha1 them)
2. all network access is down/off
3. electronic devices are unpowered
4. each machine component is simple, basic, clean
the machine to create the root is created:
1. build one-off machine from basic, isolated parts
  - drives may be pre-used-CAcert as long as approved clean/destruction method followed
  - all to inspect, approve and choose the parts
  - leave out all networking hardware and software except that essential for sneakerware (e.g., USB)
2. installed from scratch CD
generate the random feed
1. inspect and approve random mixing code/method
2. each of N provides a random block e.g., by using their laptop and putting their block onto the USB memory stick
3. all random blocks mixed into OpenSSL's random generator
root is generated.
create certificate: either of
- 1) for low-level root
  1. conduct de-escrow ceremony with top-level root,
  2. sign new root with top-level root,
  3. securely destroy copy of top-level root,
  2) for top-level root
  1. self-sign the new top-level root
generate the escrow copies of the root
1. method is according to Roots/EscrowAndRecovery
2. encrypt to escrow list (board, sysadms, backups, etc)
3. store escrow copies on memsticks?
4. store passwords on paper?
5. both into separate safe places, each member
clean the hardware
1. scrub the memories (of machine and USB sticks) according to SecurityManual.
2. destroy any key parts: disks, memory, bios, etc
install new root
1. travel in group form to machine location
2. sysadm grants access to each escrow member
3. escrow member copies in part
4. method is according to Roots/EscrowAndRecovery
5. sysadm combines and prepares and secures.
each submits signed/attested paper documentation
1. "I supervised each step."
2. "To best knowledge, each step followed faithfully."
3. "My supplied parts and randoms were clean."
4. "Result is a good root."
5. "Root was securely installed on signing machine."
followup:
1. attestations collected, scanned, uploaded
2. other documentation collected and cut for posterity (e.g., video, photos)
3. follow the process at Roots/RolloutProcedure

Assumptions for type of root

The process has to be done at least twice, once for the top-level root, and once each for the subroots.

issue	top level root	subroot or intermediate
N	5	3	for any root, 3 is minimum
board	2	1	always need one board member to oversee and report
sysadm	2	1	always need at least one sysadm to drive the software
others	1	1	could be additional independent observer, such as a senior Assurer, or another Board or sysadm

There is no issue if there are more people than required. The above numbers are minimums.

Random Notes:

To figure out:

Roots/Structure says a top-level root needs to sign subroot.
The entire ceremony could be taped for prosperity and used during the post-audit ceremonies.
- This would be good for openness and transparency and for those of us who can't/won't be there; usually this ritual is carried out behind closed doors.
- However: neither video nor presence of auditor are audit requirements, notwithstanding comments made in EV Guidelines.
Why use hard-disks in those machines at all?
- Would be smart not to, easier to destroy memory sticks.
- one answer: if the machine generates its own randomness it might need access to rotating entropy generation. But this is a bad idea anyway, IMO the machine should not be relied upon to generate its own random source.

CategoryProcedures

CategoryNewRootsTaskForce