Security model

What SuperFile protects, how each secret is held at rest and in use, where the trust boundaries lie, and what "hardware secured" honestly means on the client. Certifications and the audited reports are on Trust & Security; this page is the engineering view.

#Zero Trust File Encryption

A SuperFile is the original file wrapped in AES-256 encryption under a key that is split: one half stays with the owner's side, one half with SuperFile. No single half opens the file, so:

SuperFile cannot read your documents;
a stolen copy — from a laptop, a phone, an external drive, a backup — is ciphertext;
every open requires both halves to agree now, which is what makes unsharing work after the file has left.

On Institutional deployments the owner's half lives in the customer's KMS or HSM.

#Assets and controls (the licence server)

Asset	Compromise means	At rest	In use	Who can read it
Content keys (16 bytes, one per file or page)	one asset in the clear	AES-256-GCM under the KEK, AAD = `tenant:content_id` (a row cannot be re-pointed at another tenant or id)	opened per licence, 5-minute in-memory cache, never logged	the licence process only
KEK	every key	`local`: 0600 file; `pkcs11`: non-extractable object in the HSM; `aws-kms`: never leaves KMS	the HSM or KMS performs the AES-GCM; the process never holds the KEK in hardware modes	nobody, in hardware tiers
Widevine signing key / IV	anyone can mint licences as you	sealed JSON under the KEK	opened per request, cached 10 min	licence process
FairPlay private keys + provisioning data	same, for Apple devices	on the KSM host only, never in the database	inside the KSM (enclave in hardened tiers)	the KSM
Tenant token secrets	licences for that tenant	sealed under the KEK	opened per verify (cached)	licence process; shown once at creation or rotation
API keys	same	SHA-256 only	compared by hash	nobody after creation
The meter	billing and forensic integrity	append-only tables; the admin API is read-only on them	—	operators

#Trust boundaries

Player ↔ SuperDRM: a short-lived HS256 token or the tenant's server-side relay. CORS open on licence routes only. No cookies.
SuperDRM ↔ Google: request signing (AES-CBC over SHA-1 per the Widevine service contract) over TLS.
SuperDRM ↔ KSM: loopback, or enclave vsock / HTTP with a bearer in hardened tiers.
Operators ↔ admin API: a single operator token, rotated by restart; the console never exposes it to browsers; put the console behind your own gateway.
Portal users ↔ portal: scrypt passwords, 30-day secure HTTP-only cookies hashed server-side, single-use hashed email tokens, per-address rate limits, CSRF by header plus SameSite=Lax.

#Hardware-secure playback

"Hardware secured" on the client means the CDM decrypts inside a trusted execution environment and frames travel a secure output path: screen capture shows black and HDCP is enforced on external displays. SuperDRM enforces it in policy:

Widevine: hw:true refuses licences to L3 (software) clients; wv_track:"HD" additionally makes Google require L1 at the key level. The response header X-SuperDRM-Security: L1|L3 and the meter row record what was actually granted.
FairPlay: policy hdcp: type0|type1 is passed to the KSM; Apple devices always decrypt in the Secure Enclave path.
Clear Key: software only, refused unless a token explicitly says hw:false.
Attested devices: for fleets without a hardware CDM, a TPM-backed boot attestation gates key release instead — see Attested devices.

What no DRM does: blank a camera pointed at the screen, or an HDMI capture device on an HDCP-stripped path. The trail still records the open.

#Key ceremony

Create the KEK in the HSM or KMS; never import a software key.
Record kek_id; two custodians hold the backup material.
Rotate by creating KEK-2, starting the api with it, re-sealing, verifying, and retiring KEK-1 after the backup window.
Every step lands in the audit log. Full procedure: Hardware key vault.

#Application security on superfile.com

Every page carries a per-request Content-Security-Policy nonce; account surfaces are never indexed.
The register enforces its rules in the database (row-level security and triggers), not only in the API, so a request that bypasses the site cannot claim a second free name or keep an unconfirmed hold.
The audit trail is append-only and never stores a referrer query string.
Sign-in tokens never reach the page; device lists show masked IP addresses.
A daily canary proves the admin console and the customer path still work; a heartbeat gates every production deploy.

#Certifications and documentation

SOC 2 Type 1 and Type 2, ISO/IEC 27001:2022, GDPR and HIPAA controls, regular third-party penetration testing, and a FedRAMP 20x authorization in process. Reports are shared with customers and prospects under NDA from Trust & Security. Personal data handling: Privacy Policy and Data & Subprocessors. To report a vulnerability, email go@superfile.com with "Security" in the subject line.

Updated September 2026