We’re preparing to ship the next generation of our compute sled [1] (called cosmo). Per our RoT code signing PKI policy [2] this requires dedicated PKIs for each of the 4 trust anchors supported by the RoT. We’re also preparing to deploy custom manufacturing hardware [363] (called minibar) to support a streamlined programming flow for costmo. Though we don’t yet have a use-case defined for the RoT on this platform, it still needs to be locked and production signed. These platforms will not be participating in a rack trust quorum which implies that we need a dedicated platform identity PKI for test equipment. Bootstrapping these two PKIs and signing intermediates from permslip [11] is the primary function of this ceremony.
We’re constantly looking for ways to improve our ceremonies and in our last one [3] it became clear that our call and response method for transcribing output digest values was far too cumbersome and prone to human error. As a stretch goal this ceremony will work to deploy a new, lower friction method using a label printer.
Determinations
An OKS ceremony will be held during the first week of September 2025 to:
create / provision new code signing PKI roots for the cosmo platform
certify an intermediate signer held by permslip for each of these new code signing PKIs
sign a collection of debug credentials [4] stored in permslip for each new code signing PKI
create / provision a new platform identity PKI root for the minibar platform
certify an intermediate signer held by permslip with this new platform identity PKI
This ceremony will be conducted only after the same script is executed successfully using the staging OKS instance. If we’re unable to execute the script against staging in the week prior to the production ceremony we will postpone the ceremony till the week after OxCon2025.
New Hardware
In this ceremony we will deploy a new label printer for the purposes of minimizing the transcription of values during the ceremony. This label printer will be used to:
export digest values previously transcribed by hand
generate labels placed on tamper evident packaging
Size and Storage
Though we do not intend for secrets to pass through this printer in this particular ceremony we recognize that useful tools often find multiple uses. We’ve migrated away from printing secrets as a way to reduce the burden on the various custodians that they’re entrusted to. Using write-once CD / DVD media alleviates the need to manually enter long strings of random characters, but the additional complexity in the technology makes for new failure modes like corrupted or damaged media. Having a printed copy of each secret written would provide us with a valuable fallback mechanism and so we assume that sensitive data like the HSM password and keyshares will eventually pass through it.
This implies that the label printer must be small enough to fit in our secure storage until it’s decommissioned. The size of our secure storage is approximately 21 inches in length, by 9 width and 10 height as determined in a previous ceremony [14]. Any label printer considered must be able to fit in our staging storage box alongside all other materials stored.
Wireless Technology
Label printers, like many hardware peripherals, are increasingly packed with wireless technologies like Bluetooth and / or WiFi. This has an obvious benefit for many use-cases but it complicates our own. Like the laptop configuration described in [5] whatever label printer we use must either have no integrated wireless devices (USB only) or we must remove or disable such devices to our best ability. Given the complexity and risk associated with removing or disabling hardware components within a larger device we prefer to just buy a label printers without wireless.
Label Printer Selection
Of the (very limited) available label printers that meet our size and connectivity requirements the Brother QL-600 [7] and Dymo LabelWriter 550 [8] were the most viable options. The Dymo LabelWriter is the smaller of the two available though support for Linux has been spotty and Dymo has been adding mechanisms to lock their users into using "genuine" Dymo labels. The DRM lock in is limited to the newer 550 models and some users have been able to bypass the DRM by configuring the 550 as though it were the older 450 model. Manufacturers that resort to such tactics are generally to be avoided, but the additional technology required to enforce such restrictions (RFID / NFC reader that communicates with a tag on the label roll) likely disqualify the Dymo LW 550.
The Brother QL-600, though slightly larger, is a far better fit for our needs.
The generic 62mm label rolls used in testing work as expected. The PPD files
available in most linux distros work out of the box and, after proper
configuration, we’re able to print a 32 byte digest through the lp program
as expected:
sha256sum file \
| awk '{gsub(/.{2}/,"& ")}1' \
| sed 's/ /\n/8;P;D' \
| head -n -1
| lp -o PageSize=62x29mm > /dev/nullThis label printer was used successfully in our staging ceremony and the same configuration will be used in production.
Ceremony Location
REDACTED
Key Id
Each new key created in the HSM requires a keyspec file. This file defines
the various properties of the key created by the HSM. The id field from the
specification must be selected to prevent a conflict with the existing keys.
Space Constraints
The YubiHSM [12] has limited storage. Before we attempt to create new
keys in our production OKS instance we must ensure that there is sufficient
space to store whatever objects we intend to create. The Object ID used by the
YubiHSM to uniquely identify keys is a u16 and has a range of 0-65535. In
practice however the YubiHSM can only store 256 objects (§30.11). Objects /
keys stored in the YubiHSM share a common storage medium with a total size of
126KB (§30.1).
Evidence room [13] is where we store the metadata required to
operate both the production and staging OKS instances. This includes KeySpec
files that describe all keys stored in the relevant YubiHSMs. The staging and
production instances contain the same number and type of keys and so their
storage requirements will be the same.
Though not a strict requirement, each of the keys in our OKS instances is the root of a certificate authority. The following table maps their names to the key types and storage requirements:
| Name | Key Type | Key Size |
|---|---|---|
gimlet-rot-dev-a | RSA 4k | 4Kb |
gimlet-rot-dev-b | RSA 4k | 4Kb |
gimlet-rot-rel-a | RSA 4k | 4Kb |
gimlet-rot-rel-b | RSA 4k | 4Kb |
psc-rot-dev-a | RSA 4k | 4Kb |
psc-rot-dev-b | RSA 4k | 4Kb |
psc-rot-rel-a | RSA 4k | 4Kb |
psc-rot-rel-b | RSA 4k | 4Kb |
sidecar-rot-dev-a | RSA 4k | 4Kb |
sidecar-rot-dev-b | RSA 4k | 4Kb |
sidecar-rot-rel-a | RSA 4k | 4Kb |
sidecar-rot-rel-b | RSA 4k | 4Kb |
platform-identity-root-a | ECP384 | 384b |
total | 6192B |
Based on the table above our OKS instances should have approximately ~6KB of the available 126 currently used. This ceremony will add an additional 4 RSA 4K keys, one for each of the trust anchors supported by the RoT on the cosmo platform. We will also be creating a single ECP 384 key for the minibar / manufacturing platform identity PKI. These additional keys will take another 2432B of storage to bring us up to ~9KB used. This is more than sufficient space for the needs of this ceremony and leaves plenty of room for whatever overhead my be added by encoding done within the YubiHSM.
Open Questions
We’re planning for this ceremony to take place in the first week of September. This deadline is tied to delivering the Cosmo platform and so any tasks that cannot be completed by this time will have to be abandoned. The good news is that all of the required key management and PKI operations have been exercised previously so the offline-keystore [5] software [6] is already capable of performing the required tasks. The bad news is that we’re attempting to deploy an additional ceremony optimization in the form of a label printer which is new work and cannot block cosmo.
Security Considerations
In this ceremony we propose replacing ceremony steps that require the transcription of a digest value with one printed on an adhesive label. This label will then be adhered directly to the ceremony script in a designated location. Testing must ensure that we can handle these labels in a way that doesn’t cause smudging or any loss of data. This label maker is a new piece of hardware that will be connected to the ceremony laptop via USB while the HSM is connected. Any device connected to the laptop, even if it doesn’t handle secrets directly, could be a vector for side channel / power analysis and so this printer will have to be stored securely.
REDACTED
There is still valuable work to be done in reducing the risks posed by the physical space used for ceremonies and the ambient technology within. This work must consider the proximity of any new space to the location where we store the related hardware and the methods used for transport between the two locations.
Ceremony Script
The ceremony script is formatted for printing. It begins on the following page:
REDACTED