Executive Summary
This claim is filed as a dependent of Claim 8, narrowing the independent claim to the specific key-proof and token-issuance mechanism used for its final gate. At provisioning time, each validator node is issued five distinct key types under one node identity - an API key, an SSH keypair, a protected Ed25519 signing key, a consensus Ed25519 key, and a shared HMAC key - each stored and tracked independently by the fleet controller.
Before a bounded-lifetime authorization token is minted, the controller issues the node a fresh, single-use random challenge and requires the node to sign that exact challenge with each of its currently-active signing-capable keys; the controller independently verifies each returned signature against its own stored copy of the corresponding public key before reporting a pass. Only after this proof-of-possession step succeeds, together with the node's other bootstrap gates, does the controller mint a 24-hour bearer token.
Problem Statement
Bearer tokens and API keys prove that a requester knows a secret value, not that the requester controls the cryptographic keys a validator actually needs to participate in consensus. A leaked static token can be replayed indefinitely by an attacker who never possessed the validator's signing keys at all. Systems that issue long-lived or non-expiring authorization compound the exposure window of any single credential leak.
Why Static Credentials Are Insufficient for Consensus Authorization
- Possession is not verified: A stolen API key authenticates a requester's knowledge of a secret, not their control of the validator's actual signing keys.
- No forced re-proof: Without an expiry, a single successful authorization persists as standing trust even if the node's operational posture later changes.
- Single-key verification is fragile: Proving possession of only one key type leaves other key material (e.g. a protected signing key used for a different purpose) unverified and potentially silently compromised.
Technical Architecture
Five-Key-Type Node Identity
| Key Type | Purpose | Included in Challenge-Response Today |
|---|---|---|
| API key | Bearer credential for fleet-controller API calls | No (used as request auth, not signature proof) |
| SSH keypair | Provisioning-time remote access to the node | No |
| HSM signing key (Ed25519) | Hardware-backed operational signing | Yes |
| Consensus key (Ed25519) | The validator's consensus-layer signing identity | Yes |
| Shared HMAC key | Symmetric authentication of bootstrap messages | No (used for message-integrity binding, not challenge-response) |
All five key types are generated and registered together at node-provisioning time under a single node identity, giving the fleet controller one consolidated record of everything that node is cryptographically entitled to use. The controller's challenge-response step is scoped, per request, to whichever subset of these keys is currently active and signing-capable for that node - live production use exercises this over the two Ed25519-family keys (HSM signing key and consensus key), leaving room for the challenge set to extend to additional key types as they come into signing-relevant use.
Challenge-Response Sequence
- The controller generates a fresh random challenge and records it with a short validity window, keyed to the requesting node.
- It returns the challenge together with the list of key types it expects a signature for.
- The node signs the exact challenge bytes with each requested key and returns one signature per key type.
- The controller verifies each signature against its own stored public key for that node and key type, and reports which key types passed or failed - a challenge is single-use and is discarded once verified, whether it passed or failed.
Token Issuance and Per-Command HMAC Binding
Only when key verification (together with the other bootstrap gates) reports a full pass does the controller mint a bearer authorization token, valid for a fixed 24-hour window, replacing any prior token for that node. Separately, individual bootstrap messages exchanged between node and controller carry an HMAC computed over the specific message's identifier, node identity, message type, and timestamp - binding message authenticity to those exact parameters so a captured message cannot be replayed against a different request context.
Prior Art Differentiation
Standard OAuth-style bearer tokens and static API keys authenticate a secret, not cryptographic possession of an asymmetric keypair, and typically carry no built-in requirement to re-prove key possession on a fixed cycle. Hardware-attestation schemes (e.g. TPM quote-based attestation) prove possession of a platform key but are not typically composed with a consolidated multi-key-type registry spanning both operational and consensus-signing keys under one node identity with challenge-response proof folded into a broader multi-gate bootstrap. JIL Sovereign's design is distinguished by combining a five-key-type node identity, single-use random-challenge proof of possession, and a fixed 24-hour re-authorization cycle into one token-issuance decision.