TRC Signing Ceremony Phases - Base TRC

This documents outlines the steps each participant must go through when participating in a TRC Signing Ceremony for establishing a new base TRC.

This document is organized by role. Please only refer to the section pertaining to your role.

This document assumes that the basic devices required by the ceremony are present:

• Formatted USB Flash Drive (FAT)

• Ceremony administrator’s device

• Voting representative’s device

The script for each role is described in the following sections:

• Ceremony administrator role

• Voting AS representative role

• Witness role

Prior to the start, the ceremony administrator assigns a short identifier to each voting representative. This identifier will later be used in the naming of certain files. For the purpose of this document, the names are assumed to be zürich, bern, and geneva. Also for the purpose of this document, bern is assumed to be a Certificate Authority for the ISD.

Ceremony administrator role

The ceremony administrator brings their own ceremony representative’s device to the ceremony. For readability, in this section we refer to this device simply as the device.

Phase 1 - Exchange of Certificates

As the first step, the ceremony administrator announces the TRCID that is used for the rest of the signing ceremony. Because a base TRC is signed in this ceremony, the value should be chosen to be ISD<isd-id>-B1-S1, where <isd-id> is replaced with the ISD identifier.

The ceremony administrator shares the USB flash drive with each voting representative, and waits for each voting representative to copy the needed certificates.

The ceremony administrator reminds participants that they need to copy all certificates needed for the role of the entity they represent. For those who are only voters, this means the CP sensitive voting certificate and the CP regular voting certificate. For those who are also Certificate Authorities in the ISD, the list of certificates includes the CP root certificate.

When the ceremony administrator gets the back the USB flash drive, they connect it to their device. They must first check that all required certificates are contained on the drive.

For each certificate, the ceremony administrator displays the validity period and checks that they cover the previously agreed upon TRC validity.

for cert in {bern,geneva,zürich}/*.crt; do
    echo $cert
    openssl x509 -in $cert -noout -dates
    echo ""
done

Further, checks that the signature algorithms are correct:

for cert in {bern,geneva,zürich}/*.crt; do
    echo $cert
    openssl x509 -in $cert -noout -text | grep "Signature Algorithm" | cat
    echo ""
done

And finally, checks that the certificates are of valid type:

for cert in {bern,geneva,zürich}/*.crt; do
    scion-pki certs validate --type $(basename $cert .crt) $cert
done

If the results of these checks are as expected, the ceremony administrator computes the SHA256 sum for each certificate:

for cert in {bern,geneva,zürich}/*.crt; do
    sha256sum $cert
done

Disconnect the USB flash drive, and give it back to the voting representatives. Wait for each voting representative to download the certificates of the other voting representatives.

Finally, show the SHA256 sums on the screen for the voting representatives to see, and wait for them to confirm that the SHA256 sum is correct for every certificate.

After every voting representative has confirmed that the SHA256 sums are correct, announce that Phase 1 has concluded. If there is a mismatch in any of the sums, Phase 1 needs to be repeated.

Phase 2 - Creation of TRC Payload

Once all the certificates have been accounted for, the ceremony administrator must create a TRC payload.

First, ask the voting representatives for the ISD number of the new ISD. The value will be used to fill in the {{.ISD}} variable below.

Second, ask the voting representatives for the description of the TRC. This will be used to fill in the {{.Description}} variable below.

Third, ask the voting representatives for the AS numbers of the ASes that will be core (these will be used to populate the {{.CoreASes}} variable in the file below), and the AS numbers of the ASes that will be authoritative (these will be used to populate the {{.AuthoritativeASes}} variable in the file below).

Fourth, ask the voting representatives for the voting quorum of the next TRC update. The value will be used to fill in the {{.VotingQuorum}} variable below.

Last, ask the voting representatives for the validity period of the new TRC. The value will be used to fill in the {{.NotBefore}} and {{.Validity}} variable below. The {{.NotBefore}} variable is represented as a UNIX timestamp (seconds since Epoch January 1st, 1970 UTC, e.g. 1593000000 equals June 24th, 2020 UTC at noon).

To highlight variable types, we include some examples. The format must include the part after the = sign exactly as it is written (i.e., with the exact same quoting, parentheses, etc.).

{{.ISD}}               = 1
{{.Description}}       = "Test ISD"
{{.VotingQuorum}}      = 2
{{.CoreASes}}          = ["ff00:0:110", "ff00:0:111"]
{{.AuthoritativeASes}} = ["ff00:0:110", "ff00:0:111"]
{{.NotBefore}}         = 1593000000  # Seconds since UNIX Epoch
{{.Validity}}          = "365d"
{{.CertFiles}} = [
    "bern/sensitive-voting.crt",
    "bern/regular-voting.crt",
    "bern/cp-root.crt",
    "geneva/sensitive-voting.crt",
    "geneva/regular-voting.crt",
    "zürich/sensitive-voting.crt",
    "zürich/regular-voting.crt",
]

Note

The UNIX timestamp can be displayed in human readable form using the date command:

date -d @1593000000 --utc

To compute the UNIX timestamp for a given date in UTC, use:

date -d 'YYYY-MM-DD HH:MM:SSZ' +"%s"

Create the TRC payload configuration:

cat << EOF > $TRCID.toml
isd                = {{.ISD}}
description        = {{.Description}}
serial_version     = 1
base_version       = 1
voting_quorum      = {{.VotingQuorum}}
core_ases          = {{.CoreASes}}
authoritative_ases = {{.AuthoritativeASes}}
cert_files         = {{.CertFiles}}
no_trust_reset     = false

[validity]
not_before = {{.NotBefore}}
validity   = {{.Validity}}
EOF

Display the payload template file with the variables filled-in on the device monitor. The voting representatives should compare the contents of the file with their answers to the previous questions, to ensure that all the data is correct.

Once the data has been verified, compute the DER encoding of the TRC data:

scion-pki trcs payload -t $TRCID.toml -o $TRCID.pld.der

Compute the SHA256 sum of the TRC payload file using:

sha256sum $TRCID.pld.der

Connect the USB flash drive to your device, and copy the TRC payload file to the root directory, then disconnect the USB flash drive. Hand out the USB flash drive to the voting representatives.

The voting representatives proceed to check the contents of the TRC payload file by computing the SHA256 sum. Over the duration of the checks, keep the SHA256 sum of the file available on the monitor for inspection.

This phase concludes once every voting representative confirms that the contents of the TRC payload are correct. Once that happens, announce that Phase 2 has successfully concluded.

Phase 3 - Signing of the TRC Payload

This phase consists of the voting representatives casting votes on the TRC payload file. The phase concludes after all voting representatives have cast their votes and copied the signatures onto the USB flash drive.

As part of this phase, the voting representatives inspect the TRC payload. Display the TRC payload using:

openssl asn1parse -i -in $TRCID.pld.der -inform der

# The asn1parse command is a diagnostic utility that can parse ASN.1 structures.
#
# -i:      indent the output according to the depth in the structure.
# -in:     the input file.
# -inform: the input format. We have an ASN.1 DER encoded structure.

Walk the voting representatives through the output and describe the meaning and implications of each part.

Once every voting representative has finished the signing process, announce that Phase 3 has successfully concluded.

Phase 4 - Assembly of the TRC

This phase consists of assembling the final TRC by aggregating the payload data with the votes (signatures) cast by the voting representatives.

Connect the USB flash drive to the device. Given the example data, the votes should be available at the following locations on the USB flash drive:

• /bern/isd.sensitive.trc

• /bern/isd.regular.trc

• /geneva/isd.sensitive.trc

• /geneva/isd.regular.trc

• /zürich/isd.sensitive.trc

• /zürich/isd.regular.trc

To assemble the final TRC in a file, run the following command:

scion-pki trcs combine -p $TRCID.pld.der \
    bern/$TRCID.sensitive.trc \
    bern/$TRCID.regular.trc \
    geneva/$TRCID.sensitive.trc \
    geneva/$TRCID.regular.trc \
    zürich/$TRCID.sensitive.trc \
    zürich/$TRCID.regular.trc \
    -o $TRCID.trc

To check that the resulting TRC is correct, run:

scion-pki trcs verify --anchor $TRCID.trc $TRCID.trc

cat */*voting.crt >> bundle.crt

openssl cms -verify -in $TRCID.trc -inform der \
    -certfile bundle.crt -CAfile bundle.crt \
    -purpose any -no_check_time -partial_chain \
    > /tmp/$TRCID.pld.extracted

# The cms command allows verifying payloads according to the Cryptographic
# Message Syntax defined in RFC5652.  The main purpose of the cms command is
# interacting with S/MIME messages, but we can use it to verify any CMS
# signed message with the appropriate flags.
#
# -verify:        verify the CMS signed message and extract the payload.
# -in:            the signed CMS structure.
# -inform:        the format of the signed CMS structure.
#                 We have an ASN.1 DER encoded structure.
# -certfile:      specify the certificates that can be used to verify the payload.
# -CAFile:        specify the certificates that can verify the certificates in
#                 -certfile. This is needed because the certificates are self-signed.
# -purpose any:   ignore the certificate purpose required by S/MIME.
# -no_check_time: do not check if certificates are valid at the current time.
#                 This is necessary if any of the certificates have notbefore
#                 time in the future.
#
# In case any of the voting certificates have the same common name. The
# verification can fail with the following error: 'Verify error:self signed
# certificate' This is due to how openssl builds the verification path. To
# suppress that error, set the -partial_chain flag.

openssl asn1parse -i -in /tmp/$TRCID.pld.extracted -inform der

# The asn1parse command is a diagnostic utility that can parse ASN.1 structures.
#
# -i:      indent the output according to the depth in the structure.
# -in:     the input file.
# -inform: the input format. We have an ASN.1 DER encoded structure.

Copy the signed TRC to the USB flash drive in the root directory. Disconnect the USB flash drive.

Finally, compute the SHA256 sum of the final TRC:

sha256sum $TRCID.trc

and keep it for reference on the monitor of the device.

Each voting representative now checks that the final TRC contains the correct data, and that it can be verified. Wait for each voting representative to confirm that verification has finished successfully. If any verification fails, Phase 3 and Phase 4 need to be repeated.

Furthermore, the voting representatives inspect that all signatures are present. Display the signed TRC with this command:

openssl pkcs7 -in $TRCID.trc -inform der -print -noout

# The pkcs7 command is a diagnostic utility that can inspect PKCS#7
# structures.  Our CMS signed payload is compatible with PKCS#7.
#
# -in:     the input file.
# -inform: the input format. We have an ASN.1 DER encoded structure.
# -print:  display the full parsed structure.
# -noout:  do not display the encoded structure.

Walk the voting representatives through the output and describe the meaning and implications of each part.

If each voting representative confirms they have successfully verified the TRC, announce that Phase 4 has finished successfully. Then, announce that the key signing ceremony has concluded successfully.

Voting AS representative role

Each voting representative brings their own voting representative’s device to the ceremony. Each voting representative performs actions only on their own device. For readability, in this section we refer to this device simply as the device.

Preparation

To follow the commands described in the following sections, three environment variables need to be set up:

# Dir that holds the certificates.
export PUBDIR="path/to/public"
# Dir that holds the secret keys.
export KEYDIR="path/to/keys"
# The TRC ID of the TRC that is created in the ceremony.
export TRCID="ISD<isd-id>-B1-S1"

The TRCID variable that is used is announced by the ceremony administrator in the beginning of the signing ceremony.

Furthermore, everything that is copied from the USB Flash Drive should be put in the current working directory.

Important

It is required that the machine used to execute the commands has openssl version 1.1.1d or higher installed.

Phase 1 - Exchange of Certificates

Phase 1 consists of sharing the self-signed voting and root certificates.

Plug the USB Flash Drive into the device.

Create a new folder; use the identifier you received from the ceremony administrator as the name of the folder (e.g., if the identifier is zürich, the folder will have the same name).

Copy the CP Sensitive Voting Certificate and the CP Regular Voting Certificate onto the USB Flash Drive into the newly created folder. The sensitive voting certificate should be named sensitive-voting.crt, and the regular voting certificate should be named regular-voting.crt.

Warning

Note that only the certificates must be shared during the step, not the private keys. Copying a private key by mistake invalidates the security of the ceremony.

If the entity you represent will also act as a CA in the new ISD, also copy the CP Root Certificate to the USB flash drive. The file should be named cp-root.crt.

Disconnect the USB flash drive from the device, and pass it to the next voting representative or, if certificate copying has concluded, to the ceremony administrator.

Wait for the ceremony administrator to pass back the USB flash drive. Connect the USB flash drive to the device, and copy the folders with the certificates of the other voting representatives. Disconnect the USB flash drive.

Wait for the ceremony administrator to announce the SHA256 sums for each certificate. For each certificate, check carefully that the SHA256 sum announced by the administrator matches the value computed on your copy of the certificate.

To compute the SHA256 on a Linux host, run the following commands from the folder that contains the copied files.

for cert in {bern,geneva,zürich}/*.crt; do
    sha256sum $cert
done

Furthermore, check that the certificate that is on the USB flash drive does not differ from your own. For example, for identifier bern, the command that should be executed in the same folder as above is:

diff bern/sensitive-voting.crt $PUBDIR/sensitive-voting.crt
diff bern/regular-voting.crt $PUBDIR/regular-voting.crt

Phase 1 concludes once every participant confirms that the ceremony administrator has the correct version of each certificate (that is, every SHA256 sum matches).

Phase 2 - Creation of TRC Payload

In this phase, please answer the following questions asked by the ceremony administrator:

• What is the ISD number?

• What text description should the TRC contain? (e.g., “Swiss Medical ISD”)

• Who will be the core ASes of the new ISD?

• Who will be the authoritative ASes of the new ISD?

If the answers from all voting representatives do not exactly match, discussions are allowed to reach a common answer. If consensus cannot be reached for a question, the ceremony is voided and no TRC is created.

After the ceremony administrator has collected all answers, they will produce a file detailing TRC contents. Inspect the contents of the file carefully on the ceremony administrator’s monitor, and point out any mistakes. If this verification succeeds, the ceremony administrator will hand out the USB flash drive, which now contains the TRC data.

Plug the USB flash drive into your device, copy the TRC file (it should be in the root directory, called $TRCID.pld.der) to your device, and disconnect the USB flash drive. Compute the SHA256 sum on the file by executing the following command from the folder that contains the copied file:

sha256sum $TRCID.pld.der

Compare the result of the command with the SHA256 sum displayed on the monitor of the ceremony administrator. If there are any differences, this phase needs to be restarted.

This phase concludes once all voting representatives confirm that the $TRCID.pld.der file has the correct digest.

Phase 3 - Signing of the TRC Payload

This phase consists of signing the TRC file. Two signatures need to be computed, one using the regular voting certificate and one using the sensitive voting certificate.

Before signing, check that the TRC payload is sound:

openssl asn1parse -i -in $TRCID.pld.der -inform der

# The asn1parse command is a diagnostic utility that can parse ASN.1 structures.
#
# -i:      indent the output according to the depth in the structure.
# -in:     the input file.
# -inform: the input format. We have an ASN.1 DER encoded structure.

To compute the signatures, run:

openssl cms -sign -in $TRCID.pld.der -inform der \
    -signer $PUBDIR/regular-voting.crt \
    -inkey $KEYDIR/regular-voting.key \
    -nodetach -nocerts -nosmimecap -binary -outform der \
    > $TRCID.regular.trc

openssl cms -sign -in $TRCID.pld.der -inform der \
    -signer $PUBDIR/sensitive-voting.crt \
    -inkey $KEYDIR/sensitive-voting.key \
    -nodetach -nocerts -nosmimecap -binary -outform der \
    > $TRCID.sensitive.trc

# The cms command allows signing payloads according to the Cryptographic Message
# Syntax defined in RFC5652.  The main purpose of the cms command is interacting
# with S/MIME messages, but we can use it to create any CMS signed message with
# the appropriate flags.
#
# -sign:       create a signature on the payload.
# -in:         payload to be signed.
# -inform:     the payload format. We have an ASN.1 DER encoded payload.
# -signer:     signing certificate.
# -inkey:      private key used to sign authenticated by the certificate in -signer.
# -nodetach:   include the payload in the resulting signed CMS structure.
# -nocerts:    do not include the signing certificate.
# -nosmimecap: do not include smime capabilites.
# -outform:    the output format of the resulting signed CMS structure.
#              We use ASN.1 DER.

Warning

The above operation requires access to the private key. If this key gets leaked, it may compromise the security of the ISD. Make sure no other operations read this key.

To sanity check that the signatures were created correctly, run:

openssl cms -verify -in $TRCID.sensitive.trc -inform der \
    -certfile $PUBDIR/sensitive-voting.crt \
    -CAfile $PUBDIR/sensitive-voting.crt \
    -purpose any -no_check_time \
    > /dev/null

openssl cms -verify -in $TRCID.regular.trc -inform der \
    -certfile $PUBDIR/regular-voting.crt \
    -CAfile $PUBDIR/regular-voting.crt \
    -purpose any -no_check_time \
    > /dev/null

# The cms command allows verifying payloads according to the Cryptographic
# Message Syntax defined in RFC5652.  The main purpose of the cms command is
# interacting with S/MIME messages, but we can use it to verify any CMS
# signed message with the appropriate flags.
#
# -verify:        verify the CMS signed message and extract the payload.
# -in:            the signed CMS structure.
# -inform:        the format of the signed CMS structure.
#                 We have an ASN.1 DER encoded structure.
# -certfile:      specify the certificates that can be used to verify the payload.
# -CAFile:        specify the certificates that can verify the certificates in
#                 -certfile. This is needed because the certificates are self-signed.
# -purpose any:   ignore the certificate purpose required by S/MIME.
# -no_check_time: do not check if certificates are valid at the current time.
#                 This is necessary if any of the certificates have notbefore
#                 time in the future.

Connect the USB flash drive to the device, and copy $TRCID.regular.trc and $TRCID.sensitive.trc to the folder named after your identifier.

Disconnect the USB flash drive, and hand it to the other voting representatives.

Phase 4 - Assembly of the TRC

This phase starts with the ceremony administrator aggregating the TRC payload and the votes.

Once the aggregation is finished, the USB flash drive will contain the final TRC.

Connect the USB flash drive to the device, and copy the $TRCID.trc file located in the root of the USB flash drive.

Compute the SHA256 sum by navigating to the folder that contains the TRC file and executing the following command:

sha256sum $TRCID.trc

Compare the result with what is displayed on the monitor of the ceremony administrator. If the sum differs, then Phase 3 and Phase 4 need to be repeated.

Next, check that all the fields are consistent with earlier choices. To print the fields that are present in the TRC, run:

cat */*voting.crt >> bundle.crt

openssl cms -verify -in $TRCID.trc -inform der \
    -certfile bundle.crt -CAfile bundle.crt \
    -purpose any -no_check_time -partial_chain \
    > /tmp/$TRCID.pld.extracted

# The cms command allows verifying payloads according to the Cryptographic
# Message Syntax defined in RFC5652.  The main purpose of the cms command is
# interacting with S/MIME messages, but we can use it to verify any CMS
# signed message with the appropriate flags.
#
# -verify:        verify the CMS signed message and extract the payload.
# -in:            the signed CMS structure.
# -inform:        the format of the signed CMS structure.
#                 We have an ASN.1 DER encoded structure.
# -certfile:      specify the certificates that can be used to verify the payload.
# -CAFile:        specify the certificates that can verify the certificates in
#                 -certfile. This is needed because the certificates are self-signed.
# -purpose any:   ignore the certificate purpose required by S/MIME.
# -no_check_time: do not check if certificates are valid at the current time.
#                 This is necessary if any of the certificates have notbefore
#                 time in the future.
#
# In case any of the voting certificates have the same common name. The
# verification can fail with the following error: 'Verify error:self signed
# certificate' This is due to how openssl builds the verification path. To
# suppress that error, set the -partial_chain flag.

openssl asn1parse -i -in /tmp/$TRCID.pld.extracted -inform der

# The asn1parse command is a diagnostic utility that can parse ASN.1 structures.
#
# -i:      indent the output according to the depth in the structure.
# -in:     the input file.
# -inform: the input format. We have an ASN.1 DER encoded structure.

If there is a mismatch between any of the fields and the desired policy, then Phase 3 and Phase 4 need to be repeated.

Note

The -no_check_time flag is needed when the validity time of the TRC is in the future.

As a final check, run:

openssl pkcs7 -in $TRCID.trc -inform der -print -noout

# The pkcs7 command is a diagnostic utility that can inspect PKCS#7
# structures.  Our CMS signed payload is compatible with PKCS#7.
#
# -in:     the input file.
# -inform: the input format. We have an ASN.1 DER encoded structure.
# -print:  display the full parsed structure.
# -noout:  do not display the encoded structure.

and check that the signature information of each signature is present; there should be 2 signatures for each voting representative. If a signature is missing, then Phase 3 and Phase 4 need to be repeated.

Inform the ceremony administrator of the outcome of the verification.

Tip

To make the TRC file more ergonomic to work with, you can change it to PEM format instead of the raw ASN.1 DER encoding. You can do so by running the following command:

scion-pki trc format --format pem $TRCID.trc

Witness role

The role of the witness is to examine that the rules in this document are followed by the participants. While not strictly required, it is useful if a witness is familiar with the steps that both the ceremony administrator and voting representatives must perform.

The witness has no active role in any of the steps of the ceremony, but can stop the process and inquire for more information if they feel the integrity of the process might have been compromised.

The witness should also be aware of what phase the ceremony is in, and take notes on which phases completed successfully.