Dual-Signed Fail-Closed Runtime License Token

Executive Summary

For software deployed into a customer's own cloud tenant — rather than a JIL-hosted service — a live phone-home authorization check on every request is unacceptable: it turns the deployment into a network dependency and a potential data-exfiltration path out of a regulated environment. Instead, a license-token issuer mints a compact, canonically serialized entitlement token binding a plan identifier, deployment identifier, product, authorized scopes, and an account-standing indicator to a short expiration timestamp, then signs it with a classical Ed25519 key and, when available, additionally signs it with a post-quantum ML-DSA-65 key — a hybrid signature that verifies under either scheme during a migration window.

The deployed software verifies the token's signature and expiry entirely locally, with no external call required. Because the token's own short TTL is the sole gate, simply withholding a renewal — automatically triggered by the account falling out of good standing — causes the deployment's authorized functionality to lapse at the next expiry boundary, without JIL ever needing to reach into the customer's environment to revoke access.

Problem Statement

Licensing software that runs inside a third party's own infrastructure has always forced a tradeoff between enforceability and intrusiveness: static license keys never expire and cannot be revoked once distributed, while phone-home schemes require exactly the kind of outbound network dependency that a security-conscious or regulated customer environment is built to avoid.

Why Existing Solutions Are Insufficient

• Static license-key files: no expiry, no way to revoke once distributed — a compromised or lapsed customer keeps working access indefinitely.
• Phone-home licensing: requires the deployment to reach an external server on every check, unacceptable inside a customer's regulated or air-gapped tenant.
• Classical-only signed tokens: no forward migration path once large-scale quantum computers threaten elliptic-curve signatures.
• Hard revocation lists: require the verifier to fetch an up-to-date revocation list, reintroducing the same phone-home dependency the token model was meant to avoid.

Technical Architecture

Canonical Hybrid Signing

The token header and payload are serialized as key-sorted, canonical JSON, base64url-encoded, and joined for signing. An Ed25519 signature over that signing input is always present; when the post-quantum signer has successfully initialized, an ML-DSA-65 (FIPS 204, Dilithium-III class) signature is appended as well. If the post-quantum signer is unavailable, the system gracefully degrades to issuing an Ed25519-only token rather than failing issuance outright.

Key Material Provenance

The signing key is loaded, in priority order, from a mounted PEM file (the production path), a base64-encoded environment variable (development/compose path), or, as a last resort, a freshly generated in-memory keypair — logged loudly as never appropriate for production, since tokens minted under it would be invalidated on the next restart.

Fail-Closed Kill Switch by Non-Renewal

Because the token's own expiry is the sole gate — no external revocation call is consulted — simply not minting a renewal causes the deployed software's authorized functionality to lapse automatically at the next TTL boundary. A renewal is withheld automatically when the account-standing indicator falls out of good standing, giving the issuer a remote kill switch with zero additional revocation infrastructure and zero live connection into the customer's environment.

Prior Art Differentiation

Patent Claim