• Roots
• Class1ResignProcedure

Code and documentation is also available here: https://github.com/CAcertOrg/cacert-procedures/tree/master/rootResignSHA256. The actual step-by-step implementation by the Critical Administrator Team can be found at: https://svn.cacert.org/CAcert/SystemAdministration/signer/re-sign-2016/implementation.txt.

Involved Parties

• Software Developement
  • Felix Dörre (Program Author)
• Software Assessment
  • Bernhard Fröhlich (Software Review)
  • Benny Baumann (Software Review, Process Organisation)
• Audit
  • Benedikt Heintel (Internal Auditor)
• Board
  • CAcert Inc. (Oversight)
• Critical Administrators
  • Wytze (Execution, Trial Run)
  • Mendel Mobach (Execution, Live Run)

  • Martin Simons (Execution, Trial & Live Run)

• Access Engineers
  • Bas van den Dikkenberg (Logging, Control, Oversight, ...)

Abstract

The root certificate of CAcert is currently signed with MD5. This is deprecated and should be replaced by a newer signature. To allow interop with existing certificates no new key material is created, but a new signature on the old proto-certificate (TBSCertificate structure) is created.

Rationale

The Class 1 Root certificate is chained based on its Public Key Fingerprint rather than its certificate fingerprint. Thus changing the certificate while keeping the identifying information intact should keep existing chains valid.

Preparation

Perform a dry-run of the actual process on a test server and verify everything works as required.

Process

A re-sign tool will look for the Class 1 Root certificate ("root.crt") and its private key ("root.key"), re-sign the certificate with SHA256 and output the new certificate ("root_256.crt"). Additionally a set of information required for proper chaining with the Class 3 Intermediate certificate ("class3.crt") are updated by re-signing a slightly modified version of the Class 3 Intermediate certificate. The Process should therefore be executed like this:

Input artifacts

• The productive signer machine, containing:
  • The Class 1 Root certificate (root.crt)
  • The Class 1 Root private key (root.key)
  • The Class 3 Intermediate certificate (class3.crt)
    • NB: The Class 3 Intermediate private key is not used as all signatures are done using the Class 1 Root private key (the Root certificate signs the Intermediate certificate, not the other way around).
• A verified live system CD
• A blank, fresh USB thumb drive
• A separate machine (for the preparation part)
• The source code of the tool (main.c)
• The execution script for the compilation (execute.sh)
• The Debian packages
  • libssl-dev:i386
  • libssl1.0.0:i386
  • zlib1g-dev:i386
• The checksums of the execution script and package files (on paper)
• Some pen and paper (for noting fingerprints)

Preparation on a separate box

• Remove any hard drive or other storage media from the computer used for the preparations
• Reconnect only:
  • A blank, fresh USB thumb drive
  • A CD-ROM drive to read the live system CD
• Boot a Debian live CD system based on the same version as the signer OS.
• Format the USB thumb drive (mke2fs) and cold reboot the live CD system to clear all traces from memory
• Create a log of the following steps:
  • Copy libssl1.0.1, libssl1.0.1-dev, zlib1g-dev to "/ramdisk"
  • Copy "main.c" to "/ramdisk/compilation"
  • Copy "execute.sh" to /ramdisk
  • Verify the sha256-checksum of the "execute.sh" to be as expected (This checksum should be prepared on paper beforehand and is to be included with the protocol for the re-signing procedure)
  • Execute "execute.sh"
    • The script performs:
      • Generate a temporary public/private key pair K in temporary (ramfs or tmpfs) memory.

        • openssl genrsa 2048 > k.key

        • openssl -in k.key -pubout k.pub
      • The Access Engineers and the Critical Administrators independently note down the public key fingerprint of the created key (SHA256, SHA512, Whirlpool) on paper.
        • openssl rsa -pubin -in pub.key -noout -fingerprint -sha256
      • Verify the source code, that it has the correct fingerprints (SHA256).
      • Compile the source code in a way that the following files are produced in the process
        • The executable binary
          • Linking of OpenSSL 1.0.1 SHOULD by static
        • All intermediate object files
        • Create signatures by K on a listing of the checksums (SHA256) of all the above files
        • Store the following information on the USB thumb drive
          • The executable binary
          • All intermediate object files
          • The signatures of K on the listing of checksums
          • The Public Key part of K
      End of script execution
• End of log
• Store the log on the thumb drive
• Ensure the destruction of K's private key by shutting down the system and performing a full run of the memtest86+

Actual Execution on the signer

• Create a log of the following steps:
  • Create a new directory on the signer in ramfs [or tmpfs if ramfs is not available] (henceforth called working directory (WD) )
    • IMPORTANT: Make sure no other running activity on the signer is able to access the contents inside this directory.
  • Copy the binary onto the signer into the WD
  • Copy the CAcert Class 1 Root certificate to WD/root.crt
  • Copy the CAcert Class 3 Intermediate certificate to WD/class3.crt
  • Decrypt the Private Key of the CAcert Class 1 Root Certificate to "WD/root.key"
  • Execute the re-signing tool
  • Copy WD/root_256.crt to the USB thumb drive as root_256.crt
    • Note the fingerprint of root_256.crt
    • openssl x509 -in root_256.crt -outform der | openssl dgst -sha256
  • Copy WD/class3_256.crt to the USB thumb drive as class3_256.crt
    • Note the fingerprint of class3_256.crt
    • openssl x509 -in class3_256.crt -outform der | openssl dgst -sha256
  • Wipe the WD and all it's contents
• End of log
• Ensure no passwords or sensitive data is in the logfile BEFORE storage on the thumb drive
• Store the log on the thumb drive
• Perform the tests described below on the WebDB system

Resulting artifacts from the process

• On the USB thumb drive:
  • The re-signed alternate Class 1 Root certificate file root_256.crt
  • The updated Class 3 Intermediate certificate file class3_256.crt
  • Compilation artifacts (see above)
  • The signatures of K on the listing of checksums
  • Public key of K
  • Both log files (live system and signer)
  • Test report
• Fingerprint of the key K (on paper) once per person.

Post-execution steps

• Validate the signatures of the files on the USB thumb drive
  • NB: Validation can be done using OpenSSL on the command line:
    • Regenerate file with the hash that was signed:

      • openssl dgst -sha256 THEFILE > THEFILE.verifyhash

    • Decrypt the contents of the signature:

      • openssl rsautl -verify -keyform PEM -inkey K.pub -pubin -in THEFILE.sig > THEFILE.verifysig

    • Verify signed and verified contents are equal:
      • cat THEFILE.verifyhash THEFILE.verifysig # Display cmp THEFILE.verifyhash THEFILE.verifysig # Compare
      • Produces no output on success or location of first difference otherwise
• Access Engineers and Critical Administrator Team members independently hand the Fingerprint of the key K by unencrypted, signed mail to Audit
• Hand the checksums of all files on the USB thumb drive to Audit in unencrypted, signed mail.
• Hand the contents of the USB thumb drive to Audit in encrypted and signed mail or other means as necessary (within 24h hours after execution)
• Hand the physical USB thumb drive to Audit ASAP for safe-keeping (not time-critical, but within one month appreciated)
• Transfer all documentation of the process to Audit for verification
• Audit verifies all provided documentation for completeness and performs own tests of the re-signed root certificate as deemed appropriate
• On audit approval forward all necessary data (multiple signed Fingerprints of K as attached mail, the signed checksums of all files and the files themselves) as attached mails to Software for verification and for inclusion of the alternative root certificate file into the software
• Software requests Critical Administrators to create a new signature for verification of the certificates according to bug 1254 which includes the re-signed Class 1 Root and Class 3 Intermediate certificates file additionally to the existing class 1 and class 3 fingerprints
• All emails (including signatures) and all resulting files (objects, assemblies, logs, ...) should be made available to the public (e.g. in the wiki).

Test requirements

Test of included data

• Compare the contents of the certificates ("openssl x509 -noout -text -in <file>.crt" and "openssl asn1parse -in <file>.crt").

  • The only differences for the Class 1 Root certificate SHOULD include:
    • Signature method (SHA256withRSAEncryption)
    • Updated serial number (0x0F)
    • Updated extensions:
      • CRL Distribution Points
      • Authority Information Access (OCSP)
      • Authority Key Identifier (Removal of DirName/serial)
    • Resulting signature value
  • The only differences for the Class 3 Intermediate certificate SHOULD include:
    • Signature method (SHA256withRSAEncryption)
    • Updated serial number (0x0E)
    • Updated extensions:
      • Authority Key Identifier (Removal of DirName/serial)
    • Resulting signature value
• Ensure the re-signed certificates neither includes MORE nor LESS details than the original old one,
  • except as noted on expected differences above.
• Ensure the validity period of both files matches to the second!

Test of functionality

• Verify the re-signed Class 1 Root certificate validates for itself
• Verify the re-signed Class 1 Root certificate validates the re-signed Class 3 Intermediate certificate
• Verify the re-signed Class 1 Root certificate validates a random existing class 1 certificate, which is valid on the old one
• Verify the re-signed Class 1 Root certificate validates a random existing class 3 certificate, which is valid on the old one, provided the re-signed Class 3 Intermediate is provided
• Verify no existing certificate is valid on the new one which is not also valid on the old one
• Verify no existing certificate is invalid on the new one which is valid on the old one
  • Known exception: If the old Class 3 Intermediate is provided, the re-signed Class 1 Root certificate cannot be used to validate the chain.
    • This stems from the Authority Key Information extension which for both Class 1 Root and Class 3 Intermediate contained an additional DirInfo/serial spec forcing serial number 00 as the root anchor.

Audit Considerations

• The update of the signature on the root certificate REQUIRES a defined process. This document aims to define this process for review by others and guidance for execution.

Security Considerations

• This process requires access to the root keys to be performed. To protect the root keys a set of precautions need to be made to allow an audit of the executed code after the fact. For this the binaries executed on the signer as well as all temporary object files used for creation MUST be made available to Software AND Audit.
• The access to the private key requires special oversight by Audit. Thus all steps of the process MUST be documented in their entirety to allow Audit a proper assessment of all accesses performed.
• Due to the nature of the used program it MUST be ensured that no other task running on the signer can gain access to the private key.
• Decrypting the private key outside of the tool instead of e.g. making the tool prompt for a password for the encrypted key is preferred for this situation, because the implementation/complexity necessary for implementing this feature would be more error prone and thus more risky. This holds especially as the API of OpenSSL makes doing this correctly much more complex than the current program was to begin with. Using mount -t ramfs for temporary storage of the decrypted key ensures the key is not stored to any physical storage, but only kept in RAM. Having the key in RAM decrypted a second time (tmpfs/ramfs) is less critical, than having to implement the password prompt (may introduce unnecessary causes for errors).
• The creation of a second version of the root certificate is a significant operational step which requires authorisation by Board beforehand.
• The creation of a second version of the root certificate furthermore requires extensive interoperability tests being performed to ensure proper, identical behaviour given
  • Only the old root is available
  • Only the new root is available
  • Both the old AND new root is available

Log

• 2014-12-23 Private discussion of Software (BenBE) with NRE (Magu) on this idea
• 2015-01-08 Creation of the tool implementing the signature creation by Felix (on request by Software / BenBE)
• 2015-01-10 Several Questions from Software (BenBE) to Audit (Benedikt) on requirements for this process
  • No presence of Audit requested
  • Requirement for Code Review before Execution
  • Control/Inspection by independent personnel (e.g. Access Engineer suggested by Audit)
  • Check/Validation of the resulting certificate file (Approval by Audit)
• 2015-01-17 Creation of this Process Documentation
• 2015-08-23 Trial execution of this procedure at FrOSCon (using the test server roots)
• 2015-10-25 Results from audit session 2015.4 regarding the trial run
  • This included some recommendations that have been incorperated into the accompanying scripts
  • Further testing based on those roots showed compatibility issues in various browsers (e.g. FF and Chrome). Those were resolved by a set of additional information being updated in the process as documented above.
• 2015-12-06 Approval of implementation of the test run results for implementation on test server
• 2015-12-13 Minor editorial changes and updates based on the test run, suggested changes by audit and the software changes implemented
• 2016-03-08 Revamp of the documentation for the re-signing procedure
• 2016-03-12 Live execution of the procedure