Security & Trust

An attestation receipt is only as trustworthy as the key that signed it. This page documents how AIAuth's signing keys are managed, rotated, and backed up, and how the verification chain is engineered to remain intact for the full life of the record.

Signing key infrastructure

Algorithm. Ed25519 (RFC 8032). Chosen because the public key (32 bytes) and signature (64 bytes) are small enough to embed in a receipt without hurting portability, verification is fast enough to run in a browser, and no side-channel attacks of concern are known against constant-time implementations.
Generation. Keys are generated on the signing server using cryptography.hazmat.primitives.asymmetric.ed25519 — the Python cryptography package's bindings to libsodium.
Storage. The active private key lives in an encrypted volume attached to the signing host. The volume is unlocked at boot from a passphrase stored only in operator memory. The key file itself is 0600, owned by a non-login service user.
Backup. The active private key is mirrored to an offline encrypted backup held by the operator. No cloud KMS or HSM is used for the free tier (enterprise self-hosted deployments can use their own HSM or cloud KMS).
Public-key publication. The current and all retired public keys are published at /v1/public-key and at the well-known discovery location /.well-known/aiauth-public-key.

Key rotation

Scheduled annually (every 365 days) or immediately on any suspected compromise.
The prior key is retired with valid_until set to the rotation timestamp; receipts signed under the retired key continue to verify indefinitely using that key's entry in the key manifest.
The rotation event is documented in the key manifest's updated_at field, visible at /v1/public-key.
The full rotation procedure is documented in docs/ENTERPRISE_ADMIN_GUIDE.md. It is reproducible by any self-hosted customer on their own infrastructure.

Key manifest versioning

The public key endpoint returns a manifest containing every key AIAuth has ever used, each with a validity window:

{
  "keys": [
    { "key_id": "key_001", "algorithm": "Ed25519",
      "public_key_pem": "...", "status": "active",
      "valid_from": "2026-04-01T00:00:00Z",
      "valid_until": null, "current_signing_key": true },
    { "key_id": "key_000", "algorithm": "Ed25519",
      "public_key_pem": "...", "status": "retired",
      "valid_from": "2025-04-01T00:00:00Z",
      "valid_until": "2026-04-01T00:00:00Z",
      "current_signing_key": false }
  ],
  "manifest_version": 1,
  "updated_at": "2026-04-01T00:00:00Z"
}

When verifying a receipt, select the key whose key_id matches the receipt's key_id field. If the receipt has no key_id (legacy), fall back to trying each key in the manifest.

Continuity and long-term verifiability

The AIAuth architecture is engineered so that no single service is a point of failure for verification. A receipt issued today remains cryptographically verifiable indefinitely, independent of the operational status of the signing service:

Public key survivability. The current and all retired public keys are published on GitHub alongside the source code. Any copy of the repository, including mirrors and archival services such as the Wayback Machine, preserves them.
Stateless verification. Receipt verification requires only the receipt, the public key matching the receipt's key_id, and an Ed25519 library. It does not require any AIAuth-operated server to be reachable.
Open-source client. The Chrome extension and receipt format are open-source at github.com/chasehfinch-cpu/AIAuth under Apache 2.0, independently buildable and deployable.
Self-hosted deployments are customer-owned. Enterprise customers run AIAuth on their own infrastructure with their own keys. Enterprise operations are fully self-contained and do not depend on any Finch Business Services LLC service.
90-day shutdown notice. Per the Terms of Service, any planned permanent shutdown of the free tier is announced at least 90 days in advance, and a final archive of the public key and hash registry is published to a public location before takedown.

Reporting a vulnerability

The responsible-disclosure process, component scope, and contact addresses are documented in SECURITY.md. Reporters are acknowledged in the security advisory when a fix ships.

Current program status

Transparency on what is and isn't in place today: