Skip to content
The world does revolve around you.

Security technical specification#

This page holds the deep technical detail behind the security architecture on the main site: the exact cryptographic construction, and the honest line-by-line status of every security subsystem in the current build.

The specification#

Authentication#

Passkey (WebAuthn Level 2) registered against Apple’s platform authenticator via ASAuthorizationPlatformPublicKeyCredentialProvider, using the PRF extension. Requires macOS 15+ / iOS 17.4+. The PRF output is a pseudorandom value bound to the authenticator, the credential, and the relying-party identifier – non-exportable from the Secure Enclave.

Helper architecture#

A small Swift helper binary owns every WebAuthn call and talks to the Python side via one-shot JSON-RPC. Pure AuthenticationServices + Security.framework, no third-party Swift packages.

Relying party#

rp_id = creativemachines.ai. Tied to the company domain, not the product name, so a future product rename cannot invalidate existing users’ credentials.

Key derivation#

HKDF-SHA256. Domain-separated info strings use the creativemachines/ namespace for the same rebrand-safety reason. No PBKDF2 anywhere in the primary path – the PRF output is already a full-entropy key.

Key wrapping#

AES Key Wrap, RFC 3394 unpadded variant. A 32-byte DEK wrapped under a 32-byte KEK produces a 40-byte blob with a built-in integrity check. A wrong KEK fails to unwrap – it does not return garbage plaintext.

Recovery#

12-word phrase from the same publicly audited 2048-word English list as BIP39, 128 bits of native entropy plus a checksum word. The 16-byte entropy feeds HKDF-SHA256 with the same shared salt, under a distinct info string, to derive an independent recovery KEK. No PBKDF2 mnemonic-to-seed step – a second KDF over already-full-entropy input adds no security in this threat model. We borrow the wordlist; we do not claim BIP39 wallet compatibility.

At-rest encryption#

SQLCipher (AES-256) for the Ostler databases on the Mac Hub. Realm (AES-256) for the iOS app. Keychain items scoped AccessibleWhenUnlockedThisDeviceOnly, Synchronizable = false – wrapped DEKs never travel in Time Machine or Migration Assistant.

Memory handling#

Long-lived session key held as a mutable bytearray and zeroised via ctypes.memset on lock or timeout. Short-lived immutable copies in Python are honestly documented as best-effort only, not claimed as guaranteed scrubbed.

Transport#

TLS with a self-signed Ed25519 server certificate generated at install. Public-key pinned by the iOS app at first pair. No unpinned HTTP. No application-layer fallback channel.

The full cross-platform cryptographic contract between the Mac Hub and the iOS app, including every constant, test vector, and wire-format byte, will be available for independent review.

Current build status#

Transparency means admitting exactly where each piece stands today, with a specific blocker named for anything not yet live.

Transparency means admitting exactly where each piece stands today, with a specific blocker named for anything not yet live:

    - **FileVault check** – **Live** · Installer verifies FileVault status and warns if disabled.

    - **Passkey helper (Swift binary)** – **Live in code** · Real `ASAuthorizationPlatformPublicKeyCredentialProvider` + PRF extension via macOS 15 AuthenticationServices. Builds and runs. Keychain operations smoke-tested against real `Security.framework` on 2026-04-23.

    - **Python auth orchestrator** – **Live in code** · HKDF-SHA256 key derivation, AES-KW wrap / unwrap, recovery-phrase generation and validation against the public 2048-word wordlist, setup wizard, recovery CLI, all wired through to SQLCipher. Test suite passing at 299 tests.

    - **SQLCipher encryption** – **Live in code** · PRAGMA-injection-guarded connection factory and migration tool. Consumed by the conversation pipeline and the API layer. Ships with the installer, with the per-store rollout in review; whole-disk FileVault protects everything in the meantime.

    - **Recovery phrase** – **Live in code** · 12-word phrase from a public 2048-word English wordlist (the same list popularised by BIP39, used here for its auditability), 128-bit entropy, checksum-validated. Setup wizard displays once with paper-only guidance; recovery CLI re-binds to a new passkey on the new device.

    - **Auto-lock** – **Live in code** · Configurable timeout with a 5-minute minimum, `ctypes.memset` scrub on lock, typed-exception re-unlock callback.

    - **Local audit log** – **Live in code** · SQLCipher-encrypted, symlink-TOCTOU-hardened, event-type whitelist, concurrent-writer lock, query-limit clamping. Per-entry HMAC integrity chain is the planned upgrade – audit-log writes are already covered by the DB-level encryption.

    - **Hardened inter-service TLS** – **Live in code** · Ed25519 self-signed CA + server + client certificates generated by installer; the installer registers signed LaunchAgents under `~/Library/LaunchAgents/` with path-injection guards on all certificate paths.

    - **Developer ID code-signing of the passkey helper** – *Planned for launch* · Apple’s AuthenticationServices refuses ad-hoc signed binaries for real `register` / `assert` operations – the call silently never completes. The Creative Machines Developer ID certificate is now in place and notarises the assistant binary; the remaining work is signing the passkey helper itself, wiring its entitlements file, and serving the `apple-app-site-association` document from `creativemachines.ai`.

    - **iOS app passkey integration** – *In development* · Cross-platform spec signed off 2026-04-23 by both implementers; the iOS-side WebAuthn client, pairing UI, and Realm-key derivation from the shared passkey are the next iOS workstream. The iOS secure-store Realm is already encrypted today; moving its key onto the passkey-PRF path is what this workstream completes.

    - **Encrypted APFS volume for Qdrant and Oxigraph** – *Specified* · Design signed off for scripted APFS volume creation with installer-managed mount points under `~/.ostler/`. Scheduled after the SQLCipher hardening and passkey work, which came first because they protect the larger data surface.

    - **Independent security audit** – *Scoped* · Senior advisors engaged; scoping calls held. Engagement with the audit firm not yet signed.

    - **Audit-log HMAC integrity chain** – *Planned* · Append-only SQLCipher storage is the current protection; per-entry HMAC linking is the hardening step on the post-audit list.