Skip to content

Core Concepts: Key Types and Operations

Keys are central to the Cryptera Keyserver.
All signing, certificate issuance, and approval workflows ultimately operate on cryptographic keys stored inside a Hardware Security Module (HSM).

This section describes the types of keys the Keyserver manages, how they are used, and how signing operations are controlled.

Key Types

The Keyserver supports three categories of keys.
Each type plays a distinct role in secure software distribution or device provisioning.

1. ROOT Keys

A ROOT key represents the top of a certificate hierarchy.
There is typically only one ROOT key per Keyserver instance.

ROOT keys:

  • Are used to issue certificates for intermediate CA keys
  • Anchor trust for device certificate chains
  • Are long-lived and rarely used
  • Must be heavily protected and require strict approval policies

2. CA Keys (Certificate Authority Keys)

CA (intermediate) keys are used to sign device certificates during manufacturing or provisioning.

CA keys:

  • Sit below the ROOT key in the certificate chain
  • Sign CSRs from devices
  • Validity periods
  • Various EC- and RSA-configurations
  • May require one or more approvers before being used

CA keys enable the Keyserver to operate as a device provisioning authority without exposing private key material to the factory floor.

3. Firmware Signing Keys (FW Keys)

Firmware Signing keys are used to sign:

  • Firmware images
  • Software binaries
  • Hashes generated by CI systems
  • Release artifacts

FW keys:

  • Are used frequently
  • Are usually scoped to individual products or product families
  • Support multi-approver workflows using operation
  • Can enforce usage limits per operation

Each FW key is configured with:

  • Algorithm (RSA, ECDSA)
  • Hash function (SHA-256, SHA-384, SHA-512)
  • Required approvers
  • Certificate validity

Separating FW keys per project reduces blast radius in case a key must be revoked.

Key Algorithms

The Keyserver supports modern cryptographic algorithms:

ECDSA

  • Curves: typically prime256v1, secp384r1, secp521r1
  • Efficient for embedded systems
  • Compact signatures (especially in P1363 format)

RSA

  • Common sizes: 2048,3072 or 4096 bits
  • Required for Authenticode (Windows executable signing)

Hash Functions

Hash algorithms are paired with keys and include:

  • SHA-256
  • SHA-384
  • SHA-512

The Keyserver enforces the correct hash algorithm during signing.

Operations

An operation represents a "ticket" on which to use one or more keys.

Operations control:

  • Which key(s) may be used
  • How many times each key may be used
  • How long the operation remains valid
  • Whether approvals are required - inherited by the approval configuration of the associated keys
  • What is being signed (via sign orders or device certificate creation)

Operations are created by orderers (usually CI/CD clients).
Approvers authorize them before signing occurs.

Operation Lifecycle

An operation passes through the following phases:

1. Creation

A client requests a new operation via the REST API:

  • Specifies one or more keys
  • Provides maxusagecount per key
  • Sets a validity period (validms)
  • Includes a human-readable description to enable approvers to understand the context

The operation is now pending, awaiting approval.

2. Approval

Approvers review the operation via the UI:

  • Who requested it
  • Which keys are involved
  • How many times the keys may be used
  • Who has already approved (if more than one approver is required)
  • The provided description

If the key requires approvers (e.g., FW production keys), the operation must be approved before signing.

The number of required approvers is defined per key and may be different persons. For example, If the operations includes 3 keys each requiring different approvers, the operation will need 3 distinct approvers to approve.

The operation is visible until the last approver has approved so only unapproved or partially approved operations are visible in UI.

3. Sign Orders

Once approved, the client may issue sign orders against the operation.

A sign order specifies:

  • The operation ID
  • The key ID
  • The data to sign (usually a hex-encoded hash)
  • The signature format (ASN.1 for RSA, P1363 for ECDSA)
  • An description for audit logging

Each sign order consumes 1 usage from that key’s remaining usage count.

If the usage count for a key reaches zero, no further sign orders are allowed. If the usage count not more than strictly necessary, this protects against someone sneaking an unauthorized signing in.

4. Completion or Expiration

An operation ends when:

  • All permitted key usages are consumed
  • The validms window expires
  • The client revokes the operation
  • An administrator revokes it

Expired or completed operations cannot be reused and are fully logged.

Usage Restrictions

Operation usage policies help control risk:

Max Usage Count

Limits the number of signatures per key during a single operation.

Example:

{
  "keyid": "key4",
  "maxusagecount": 1
}

Validity Period

Operations time out automatically, preventing unattended signing.

"validms": 60000   // 60 seconds

Per-Key Approval Requirements

Keys define how many human approvers must authorize operations that use them.

This ensures high-risk keys (e.g., production firmware keys) are protected.

Summary

  • The Keyserver manages three classes of keys: ROOT, CA, and FW.
  • Keys never leave the HSM and may enforce algorithm, hash, and approval requirements.
  • Operations define temporary, limited-scope permission to use keys.
  • Approvers must authorize operations before signing is allowed.
  • Sign orders consume usage counts and produce signatures.

These abstractions form the foundation for secure firmware signing and device certificate issuance.