Security
Security & threat model.
A precise statement of what BlueHash defends against, what assumptions it relies on, where those assumptions break, and how we behave when they do. Public, versioned, and reviewable.
01 · Trust model
Trust model
BlueHash is not a custodian. The customer holds every key, every ciphertext, and every trust root. Compromising BlueHash — the company, our infrastructure, or our personnel — does not produce access to customer plaintext, nor the ability to mint authority on a customer’s sigchain.
Trust roots are pinned by the customer at deployment and are rotatable on chain. Vendor-neutrality is enforced by giving the customer the explicit list of EK certificate authorities, enclave platform certificates, IdP issuers, and release signing keys their environment will accept.
02 · Threat model
Threat model
We model state-aligned and financially motivated adversaries with credential-replay capability — including infostealer-driven mass campaigns, IT-helpdesk vishing operators, and Storm-0558-class signing-key thieves. The table below is the canonical list of adversary classes the protocol intends to defeat or to mitigate, with explicit notes on where mitigation is partial or out of scope.
Adversary class
Examples
Detail
Coverage
Infostealer-driven mass campaigns
RedLine · Vidar · Lumma · Raccoon
Stolen browser cookies, password vaults, and OAuth tokens replayed at scale from rented infrastructure.
Eliminated
Vishing → IT helpdesk
Scattered Spider · 0ktapus
Operators impersonate employees, persuade helpdesk to reset MFA, replay reset SSO sessions.
Eliminated
Forged SSO tokens
Storm-0558 · Midnight Blizzard
Stolen or minted IdP signing keys used to forge tokens that target tenants accept as legitimate.
Eliminated (attestation binds the consumer, not the issuer)
Insufficient-MFA SaaS replay
Snowflake customers · Citrix portals
Customer credentials replayed against tenants where MFA was optional or unenforced.
Eliminated
Stolen API tokens / service accounts
T-Mobile API · Okta support
Long-lived service tokens leaked to attacker tooling, replayed for months without detection.
Eliminated (every call carries a fresh quote)
Live-session abuse during TTL
Browser-in-the-middle · proxy phishing
Adversary uses a real-time relay to hijack an active session before the device-bound TTL expires.
Reduced (TTL ≤ 5 min) — not eliminated
Application-layer compromise
Server RCE · supply-chain code injection
An attacker who controls the application server can read plaintext while it is in memory there.
Out of scope — defense in depth still required
Endorsement-key vendor compromise
TPM vendor signing-key theft
Adversary forges EK certificates accepted by the customer’s pinned trust roots.
Out of scope — customer rotates pinned vendor set
03 · In scope & out of scope
In scope & out of scope
Everything BlueHash claims is bounded. The two columns below are the authoritative statement: anything not in the left column is not promised, even by implication.
In scope
7 items
What we eliminate.
- 01Replay of phished or stolen credentials from a non-attested machine.
- 02OAuth and SSO token theft via session-cookie exfiltration.
- 03Long-lived API and service-account tokens used outside their issued device.
- 04Ciphertext exposure in misconfigured object storage (S3, Drive, SharePoint).
- 05Unilateral admin compromise via single-key authority.
- 06Silent equivocation: showing different membership state to different members.
- 07Backdoor key escrow by a vendor or internal operator.
Out of scope
7 items
What we don’t solve.
- 01The phishing call itself. Humans get fooled.
- 02Live-session compromise during the active TTL window (≤ 5 min by default).
- 03Application-layer zero-days in the customer’s own software.
- 04Insider misuse within authorized scope — abuse of legitimate access.
- 05Endpoint-firmware compromise of customer-pinned hardware-vendor signing keys.
- 06Side-channel attacks against confidential-compute enclaves not yet covered by vendor mitigations.
- 07Cryptanalytic breaks of standardised primitives (Ed25519, AES-256-GCM, etc.).
We eliminate the credential-replay step. Other defenses still required.
04 · Cryptographic assumptions
Cryptographic assumptions
Every primitive in the suite has a security assumption and a documented fallback if that assumption breaks. The fallbacks are not theoretical — they describe the concrete protocol response, including version cut-over and on-chain coordination.
Primitive
Assumption
If broken
Ed25519 / X25519
Discrete log on Curve25519 is hard. SUF-CMA security against adaptive chosen-message adversaries.
Hybrid PQ signatures gated for v2.0 cut-over.
AES-256-GCM
AEAD security against IND-CCA2 with random 96-bit nonces and < 2³² messages per key.
Per-file content keys cap nonce reuse risk; ChaCha20-Poly1305 alternative available.
BLAKE3
Collision and second-preimage resistance at 128-bit security.
Sigchain entries can be re-anchored under SHA3-256 if a structural weakness emerges.
Hardware attestation roots
TPM EK certs, Apple Secure Enclave roots, and confidential-compute platform certs are not silently signed-over by the vendor.
Customer pins the acceptable vendor set; rotation policy is observable on chain.
Public transparency log
Sigstore Rekor (or customer-pinned alternative) does not collude to hide entries.
Multi-anchor mode writes to N independent logs; verifiers require all to agree.
05 · Failure modes
Failure modes
What happens when something breaks: device lost, share leaked, vendor flaw, transparency-log outage, customer key loss. The protocol’s usefulness is partly measured by whether these failures are recoverable, observable, and survivable.
Device loss
Reported lost device triggers a sigchain revoke entry. Subsequent attestation quotes from that device are rejected by every peer that sees the revoke.
Threshold share compromise
Single FROST share is insufficient to act. Detected share compromise triggers a key-resharing operation, recorded on chain.
TPM firmware vulnerability
Vendor-disclosed flaw triggers EK certificate-chain rotation. Quotes from devices on the unpatched chain are rejected at the verifier.
Transparency log outage
Anchor unavailability stops new admin operations; read access to existing data is unaffected.
Customer key loss
Recovery is via the offline FROST share (paper-printable). BlueHash cannot recover keys — this is a feature, not a defect.
06 · Compliance mapping
Compliance mapping
The protocol is designed to slot under the existing access-control and cryptography controls of common compliance frameworks. We publish concrete mappings rather than blanket claims of coverage.
Framework
Relevant controls
Status
SOC 2 Type II
CC6, CC7
In scope · target Q1
ISO/IEC 27001:2022
A.5, A.8, A.10
In scope · target Q2
NIST 800-53 Rev. 5
AC, IA, SC controls
Mappings published
FedRAMP Moderate
Agent + verifier path
Roadmap
GDPR / DPA
Customer holds plaintext
Sub-processor scope minimal
HIPAA / PHI
BAAs available
Adapter-level guidance published
07 · Coordinated disclosure
Coordinated disclosure
Security researchers are partners. We respond fast, credit reporters by default, and run a paid bounty for in-scope findings. Coordinated disclosure with reasonable fix windows is preferred to public-then-fix.
Reach security@bluehash.com. Encrypt with the PGP key linked from /.well-known/security.txt.
Subject: [BH-Disclosure] <one-line summary>
PGP key: https://bluehash.com/.well-known/security-pgp.asc
Required:
- Affected component (agent / SDK / verifier / adapter)
- Reproduction or proof-of-concept
- Impact assessment, including blast radius
- Reporter contact + handle preference (credit / anonymous)
Response:
- Acknowledgement within 24h.
- Initial triage within 72h.
- Coordinated disclosure window: 90 days
(extendable by mutual agreement; reduced for in-the-wild exploitation).
Bounty:
- In-scope findings: USD 500 – 50,000 by severity.
- See /.well-known/security.txt for current scope and out-of-scope list.