Skip to main content

Security Model

This page describes the security properties, threat model, and recommended mitigations for AiHint implementations.

Security Properties​

AiHint provides two core security guarantees through its use of RSA-SHA256 signatures:

  1. Authenticity — A verified AiHint document was created by the entity that controls the private key corresponding to the public key at public_key_url.
  2. Integrity — A verified AiHint document has not been modified since it was signed.

AiHint does not provide:

  • Confidentiality — AiHint files are public by design.
  • Authorization — AiHint does not control who can issue hints; trust is established out-of-band (see Trust Model).
  • Availability — AiHint does not guarantee that a hint will always be accessible.

Threat Model​

Attacker Goals​

An attacker may attempt to:

  1. Forge a hint — Create a fake AiHint file that appears to be signed by a legitimate issuer.
  2. Modify a hint — Alter the trust score or other fields in a legitimate hint.
  3. Replay an expired hint — Serve an old hint that has expired.
  4. Impersonate an issuer — Claim to be a trusted issuer by publishing a fake public key.
  5. Suppress a hint — Prevent AI systems from discovering a legitimate hint.

Mitigations​

ThreatMitigation
Forged hintRSA-SHA256 signature verification. Without the issuer's private key, a valid signature cannot be produced.
Modified hintAny modification invalidates the signature. Verifiers will reject tampered documents.
Expired hint replayThe expires_at field allows consumers to reject stale hints. Always check expiration before trusting.
Issuer impersonationPublic keys must be served over HTTPS from the issuer's domain. AI systems should maintain a list of trusted issuer public keys or domains.
Hint suppressionNot mitigated by the protocol. A compromised or malicious server can simply not serve the file.

Cryptographic Considerations​

Algorithm Choice​

AiHint uses RSA with SHA-256 and PKCS#1 v1.5 padding. This combination is:

  • Widely supported across all platforms and languages
  • Well-studied and considered secure for current use
  • Compatible with standard tooling (OpenSSL, Web Crypto API, etc.)

Key Size​

  • Minimum: 2048 bits
  • Recommended: 4096 bits
  • Keys smaller than 2048 bits MUST be rejected by verifiers.

Key Management​

  • Private keys MUST be stored securely and never exposed.
  • Public keys MUST be served over HTTPS.
  • Key rotation should be performed periodically (annually recommended).
  • After rotation, old public keys should remain accessible until all hints signed with them have expired.

Network Security​

HTTPS Requirements​

  • The AiHint file at /.well-known/aihint.json MUST be served over HTTPS.
  • The public key at public_key_url MUST be served over HTTPS.
  • The target and issuer fields SHOULD use HTTPS URLs.

Without HTTPS, man-in-the-middle attackers could substitute both the hint and the public key, defeating signature verification entirely.

DNS Considerations​

AiHint relies on DNS for domain resolution. DNS spoofing could redirect requests to a malicious server. Implementations SHOULD use DNSSEC-aware resolvers where possible.

Implementation Guidelines​

For Verifiers (AI Systems)​

  1. Always verify signatures before using any data from an AiHint file.
  2. Always check expiration — reject hints where expires_at is in the past.
  3. Fetch public keys over HTTPS — reject non-HTTPS public_key_url values.
  4. Validate the key size — reject keys smaller than 2048 bits.
  5. Set timeouts — don't hang indefinitely when fetching hints or public keys.
  6. Cache carefully — cache verified hints, but always re-verify after the cache expires.

For Issuers​

  1. Protect private keys — use hardware security modules (HSMs) or secure key stores in production.
  2. Set reasonable expiration — hints should expire within a reasonable period (90 days to 1 year).
  3. Monitor public key availability — ensure your public key URL remains accessible.
  4. Use strong keys — 4096-bit RSA keys are recommended.

For Website Owners​

  1. Serve over HTTPS — both the hint file and your site.
  2. Keep hints fresh — re-sign before expiration.
  3. Protect your private key — if compromised, all hints signed with it become untrustworthy.

Known Limitations​

  • No revocation mechanism — There is currently no way to revoke a hint before its expiration. If a private key is compromised, the only mitigation is to wait for existing hints to expire and publish new ones with a new key.
  • No issuer discovery — The protocol does not define a way to discover trusted issuers. This is left to the consuming AI system.
  • Single signature — A hint is signed by a single issuer. There is no built-in support for multi-party or threshold signatures.

Next Steps​