Skip to content
bluehash

Protocol

Cryptographic specification.

BlueHash defines a small set of well-understood primitives composed into three layers: an attestation envelope per device, an append-only sigchain anchored in public transparency, and per-file AEAD over customer-held storage. Everything below is the public-facing draft of how those layers fit together.

01 · Overview

Overview

The protocol takes a single design stance: every cryptographic operation that touches sensitive data must be witnessed by hardware-rooted attestation, and every authority decision must be witnessed by a transparent log. Everything else — storage layout, key rotation cadence, agent topology — is implementation detail.

There is no central key authority, no vendor-operated KMS, and no service that ever holds plaintext. The customer holds all keys, all storage, and all trust roots. The protocol’s job is to keep them honest with each other and with the hardware.

02 · Cryptographic primitives

Cryptographic primitives

The suite is intentionally short. Every primitive has a long deployment history, interoperable open implementations, and is straightforward to constant-time. We do not invent cryptography.

Ed25519

Identity & device signing

Per-device signing keypair. Public key registered in the sigchain at enrolment.

X25519

Session key agreement

Forward-secret ECDH for content keys and short-lived session tokens.

AES-256-GCM

Content encryption (AEAD)

Per-file content keys. Random 96-bit nonce, 128-bit tag, AAD binds metadata.

ChaCha20-Poly1305

AEAD alternative

Streaming-friendly AEAD. Equivalent security profile to AES-256-GCM.

HKDF-SHA-512

Key derivation

Derives content keys, transport keys, and rotation epochs from root secrets.

BLAKE3

Hashing & content addressing

Sigchain Merkle tree, content-addressable blobs, fast incremental verification.

Argon2id

Password-based key wrapping

User passphrase → wrapping key. m=64MiB, t=3, p=1 parameters by default.

FROST(Ed25519)

Threshold admin signatures

t-of-n signing, e.g. 2-of-3. No single-key admin authority anywhere.

03 · Attestation envelope

Attestation envelope

Every operation submitted to the sigchain — enrolment, key rotation, share, revoke — carries an attestation quote produced by the originating device’s hardware root. Quotes are bound to a fresh nonce that incorporates the previous sigchain head, so a stolen quote cannot be replayed against a different chain state.

Verifiers consume quotes deterministically. The customer pins the set of acceptable trust roots; we ship the parsing and verification code as open source.

  • TPM 2.0

    TCG TPM2_Quote

    EK certificate chain → AK certified by EK → PCR digest signed by AK.

  • Apple Secure Enclave

    DCAppAttest assertion

    Apple-rooted attestation; key non-extractable; bound to bundle ID and team ID.

  • AMD SEV-SNP

    AttestationReport

    Hardware-rooted VCEK; measurement of guest firmware + kernel chain.

  • Intel TDX

    TD_REPORT → TD_QUOTE

    TDX module measurement plus runtime MRTD/RTMR registers.

  • AWS Nitro Enclaves

    Attestation document

    AWS-signed; PCR0/1/2 measure image, kernel, and instance identity.

04 · Sigchain semantics

Sigchain semantics

The sigchain is an append-only log of state-changing operations: device enrolments, key rotations, policy changes, share grants, revocations. Each entry references the BLAKE3 digest of the prior entry, producing a tamper-evident chain whose head is anchored periodically to a public transparency log (Sigstore Rekor by default; customers may pin additional anchors).

Equivocation — different chain heads being shown to different members — is detectable in two ways: every member periodically checks the public anchor, and any peer can cross-witness another’s claimed head.

Sigchain entry — example device enrolmentJSON
{
  "version":     "0.4.0",
  "chain_id":    "blake3:7f9c…a31b",
  "prev":        "blake3:42c1…0e88",
  "epoch":       1486,
  "operation":   "device.enrol",
  "subject": {
    "device_id":   "device:7c12…f9ad",
    "tpm_ek":      "ek-cert:RSA-2048:DigiCert-Vendor-Q3",
    "ak_pubkey":   "ed25519:6c…2f"
  },
  "attestation": {
    "platform":  "tpm2",
    "quote":     "base64:…",
    "pcrs":      ["0:8b…a2", "7:1d…c4", "11:00…00"],
    "nonce":     "blake3:e2…3a",
    "issued_at": "2026-04-12T09:14:00Z"
  },
  "signatures": [
    { "kid": "device:7c12…f9ad", "alg": "Ed25519", "sig": "ed25519:…" },
    { "kid": "admin:frost-2-of-3", "alg": "FROST-Ed25519", "sig": "frost:…" }
  ],
  "anchored_at": {
    "log":      "rekor",
    "log_index": 18443122,
    "tree_size": 18443200
  }
}

05 · Threshold authority

Threshold authority

Administrative authority — adding or removing a device, rotating a master key, changing a policy — is held by a FROST(Ed25519) threshold key. A typical deployment uses 2-of-3 between the IT lead, security lead, and a fireproof recovery share.

FROST is a Schnorr-style threshold scheme producing a single Ed25519 signature indistinguishable from a non-threshold one. Verifiers see only an Ed25519 signature attached to the operation; they do not need any threshold-aware code.

Default deployment

Scheme
FROST(Ed25519), draft-irtf-cfrg-frost
Threshold
t = 2, n = 3
Distribution
DKG over short-lived TLS-bound channel
Storage
Per-share Argon2id-wrapped, hardware-bound
Recovery
Offline share, paper-printable key gem

06 · Session binding (DBSC)

Session binding (DBSC)

For browser-issued session tokens the protocol implements Device-Bound Session Credentials. The browser proves possession of a hardware key on every refresh by signing a server-issued challenge with a quote attached. A cookie copied to a different machine produces no valid signature, and the attached quote is bound to a different EK certificate — the server rejects on either.

Bindings are TLS-exporter-anchored: the signature input includes theEXPORTER-BH-DBSC-v1label so the same signature is meaningless across a different TLS connection.

BH-DBSC session token, replayed = rejectedHTTP
Authorization: BH-DBSC v1
  device=7c12…f9ad
  epoch=1486
  quote-hash=blake3:e2…3a
  binding=tls-exporter:EXPORTER-BH-DBSC-v1
  ttl=300
  sig=ed25519:9a…c7

07 · Storage adapters

Storage adapters

Adapters wrap each native storage system as a transparent ciphertext layer. The native sharing UI (a Google Drive share button, a Slack file upload) is preserved; the adapter substitutes attested keys for the recipient resolution step.

Object storage

S3 · R2 · GCS · Azure Blob

Per-file AEAD ciphertext. Object metadata stores sigchain pointer + key epoch.

Drive / SharePoint

Google Drive · Microsoft 365 · Dropbox

Adapter wraps native APIs. Native sharing UI preserved; recipients resolved to attested keys.

Messaging

Slack · Teams · Discord

Per-channel content keys. Attached files encrypted client-side before upload.

Mail / calendar

Exchange Online · Gmail · iCal

S/MIME + DKIM-bound attestation. Recipient must present a fresh attestation to decrypt.

08 · Versioning & compatibility

Versioning & compatibility

The protocol uses semver for the wire format. Major-version transitions are not silent: sigchains carry an explicit version in every entry, and any verifier seeing an unknown version refuses to validate downstream entries until the new version is reviewed and opted into.

Cryptographic suite negotiation is intentionally absent. There is one suite at a time. Replacing a primitive — for example, the eventual move to a post-quantum signature — requires a major version, parallel sigchain operation during the transition, and a cut-over recorded in the chain.

v0.x — Draft

current

Wire format and cryptographic suite stabilising. Reference implementation under continuous breaking change.

v1.0 — RFC

next

Public RFC publication, formal review window, hardware-vendor attestation interop tests.

v1.x — Stable

future

Backwards-compatible extensions only. Breaking changes require a new major version and parallel chain anchoring.

09 · Reference implementation

Reference implementation

The reference agent is implemented in Rust with thin platform shims for Windows (TBSI), macOS (Endpoint Security + Secure Enclave), and Linux (TPM2-TSS). The agent, SDK, storage adapters, and verifier libraries are released under Apache-2.0 with reproducibly-built binaries signed via Sigstore.

The wire format and primitives are frozen across each minor release. Test vectors ship alongside the protocol document; new vendor adapters are expected to pass them before being published in the registry.

Request early-access agentRead the security model

Components

bh-agent
Endpoint daemon (Rust)
bh-sdk
TS / Go / Rust client libs
bh-verify
Stateless attestation verifier
bh-adapters
Storage & messaging adapters
bh-frost
Threshold signing CLI
bh-rekor
Transparency anchor adapter