AES-128 Encryption

How encrypted HLS works on Ansdev — and what’s different on the API.

AES-128 Encryption

For an extra credit at upload time you can opt into AES-128 HLS encryption. Each video gets a unique 16-byte key, every .ts chunk is encrypted at rest, and the key is delivered just-in-time over an authenticated endpoint.

What the player sees

A standard EXT-X-KEY tag points at our key-delivery endpoint:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-KEY:METHOD=AES-128,URI="…"
#EXT-X-PLAYLIST-TYPE:VOD
#EXTINF:6.0,
chunk_0000.ts
…

hls.js fetches the key, decrypts each chunk in the browser, and feeds the decrypted segments to <video>. No plaintext ever lands on disk.

Two key-delivery modes

Auth context	Endpoint	Used by
Cookie	GET /video/key/:jobId	Dashboard player
Playback JWT	GET /v1/video/playback/key/:token/:jobId	Player SDK

The Player SDK rewrites the EXT-X-KEY URI on the fly to the JWT-authed variant — your token’s claim is checked against the requested jobId (anti-confused-deputy), and the response is the raw 16 binary bytes (never JSON-wrapped), with Cache-Control: no-store everywhere.

Threat model

Threat	Outcome
Someone scrapes a .ts chunk URL.	Encrypted bytes. Useless without the key.
Someone steals a playback token.	Has 5 minutes to use it for that one video. Cannot scope-creep.
Someone steals an API key.	Can mint more tokens — until you revoke it from the dashboard.
Someone snoops master.m3u8 over HTTPS.	TLS protects it in transit; key URL inside is JWT-gated anyway.

Cost

+0.5 credits / minute at upload time, on top of the base quality charge. The key live-delivery itself is free — no per-request charge.

Encryption is opt-in per video, not per account. Toggle it on the Encryption card in the Smart Stream Console before you upload. Once a job is COMPLETED, encryption is sealed in — you can’t toggle it without re-uploading.