HLS Encryption: AES-128, SAMPLE-AES, Keys & DRM | Callaba
More live video workflow notes and product updates.
HLS encryption is not one checkbox at the packager. The player must discover which key applies, obtain it through an authorized path, decrypt the intended segment or media samples, and continue when the key changes. If the playlist, key service, cache policy, player, and entitlement service do not agree, playback fails even while every media object returns HTTP 200.
The protected playback path has four contracts
Where Callaba fits—and where HLS encryption remains separate
In Callaba, Web Player is the browser-delivery module: it publishes a supported media input as HLS or DASH and applies documented open, password, group, or pay-per-view access. That gives the team a real viewer URL and process statistics to test. Callaba does not currently document a Widevine, FairPlay, or PlayReady license service, a key-management system, or a general HLS AES-128/SAMPLE-AES packager. Select and prove those components separately.
| Need | Callaba role | Separate responsibility |
|---|---|---|
| Publish browser media | Create and test a Web Player from a supported input | Confirm whether the chosen encryption mode and packaging are supported end to end |
| Control viewer entry | Use documented password, group, or pay-per-view access | Key authorization and DRM license policy are not implied by page access |
| Observe media process | Inspect Web Player input bitrate and cadence, then open the real viewer URL | Probe playlist, encrypted segments, key/license request, and client decryption independently |
Before connecting protected content to any player, use a known-good test asset from the selected encryption or DRM provider. Acceptance requires a successful authorized session and a deliberate denial test. “The manifest loads” proves neither key delivery nor policy enforcement.
AES-128 and SAMPLE-AES protect different media units
RFC 8216 defines EXT-X-KEY methods including AES-128 and SAMPLE-AES. AES-128 applies AES-CBC encryption to complete segments. SAMPLE-AES encrypts media samples according to their encoding and container; for fragmented MP4, the RFC points to the cbcs Common Encryption scheme.
| Decision | AES-128 | SAMPLE-AES / DRM-oriented packaging |
|---|---|---|
| Encrypted unit | Complete media segment | Selected bytes within audio or video samples |
| Playlist signal | EXT-X-KEY with method, key URI, and optional IV | EXT-X-KEY plus the required key format and format-specific signaling |
| Client workflow | Fetch an authorized key and decrypt segments | Use the applicable key system, CDM, and license exchange where DRM is present |
| Policy strength | Depends heavily on key authorization and application controls | Can carry provider-specific license rules and device enforcement |
Do not use “AES” and “DRM” as synonyms. Encryption makes media unreadable without a key. DRM coordinates packaging, license issuance, client decryption, policy, and supported device behavior. The DRM guide owns that broader definition.
The playlist tells the player when a key applies
An EXT-X-KEY tag applies to the following segments until another tag with the same key format changes the rule or the playlist ends. Unencrypted segments following encrypted ones need an explicit METHOD=NONE. Initialization sections also need compatible key signaling. These details make playlist history part of incident evidence.
For AES-128, the key file contains 16 octets when the key format is identity. The IV may be stated in the tag; otherwise the media sequence number is used as defined by RFC 8216. A mismatched IV produces media that was downloaded successfully but cannot be decoded correctly.
Key delivery is an authorization service
Serve playlists, segments, and keys over HTTPS, but do not rely on TLS alone. The key endpoint needs a defined viewer identity, entitlement decision, token lifetime, origin policy, rate limit, audit trail, and failure response. Avoid exposing a reusable key through a long-lived public URL, page source, analytics event, or client log.
CDN behavior deserves its own decision. Media segments benefit from caching; a personalized key or license response often needs a much narrower cache policy. Forward only the headers and cookies required by the authorization model. Test a cold request, a repeated request, a revoked entitlement, and requests from two different users.
Rotation limits the blast radius but creates coordination work
Key rotation changes the applicable key at a deliberate media boundary. The playlist update, encrypted media, key availability, CDN propagation, and player must agree on the transition. Rotating faster is not automatically safer if players frequently miss or cannot authorize the new key.
Write the rotation interval from content risk, entitlement policy, event duration, offline behavior, and operational capacity. Retain key identifiers and transition timestamps in protected logs; never retain plaintext keys in ordinary incident notes. A rollback plan should restore coherent playlist and key-service behavior, not publish the old key indefinitely.
Example: playback stops for some viewers at a rotation boundary
The playlist advances and new segments return 200, but affected sessions fail immediately after a new EXT-X-KEY appears. The first comparison is the old and new key request: URI, authorization context, status, cache headers, key identifier, and client error. If unaffected viewers obtain the new key, the root cause is likely in entitlement, token propagation, or cache variation—not the encoder. That evidence keeps the incident at the key-delivery boundary.
DRM begins where license and device policy matter
The W3C Encrypted Media Extensions give browser code a common way to discover and interact with a key system. EME is not itself a DRM product; the application still mediates license messages and authorization. Browser, OS, device, codec, encryption scheme, output protection, and persistent-license requirements shape the real compatibility matrix.
Apple's FairPlay Streaming documentation describes protected HLS delivery on Apple platforms. Widevine and PlayReady have their own client and license ecosystems. If premium-content rights require one or more of those systems, move to a multi-DRM design instead of presenting basic AES key retrieval as equivalent protection.
Commission protection with positive and negative tests
- Freeze a compatibility matrix. List browsers, devices, apps, codecs, packaging, encryption scheme, and key system.
- Use one known-good protected asset. Separate integration faults from live packager faults.
- Trace one authorized session. Correlate viewer authorization, playlist, segment, key or license request, and first decoded frame.
- Deny one unauthorized session. Confirm that the key or license fails closed without leaking media or sensitive detail.
- Cross a rotation boundary. Keep playback running before, during, and after the transition.
- Revoke and recover. Verify the documented behavior for expired tokens, removed entitlement, and service recovery.
Monitoring needs protected-path evidence
A synthetic monitor should fetch the playlist, follow an encrypted segment, authorize a test key or license, and decode on a representative client path. Keep the credential narrow and rotate it. Real-player telemetry should distinguish manifest, segment, EME/CDM, license, output-protection, and decode failures instead of collapsing them into “video error.”
Use HLS stream monitoring for playlist and segment health, then add the protected client step. The viewer authorization guide covers page access; it does not replace key or license authorization.
HLS encryption FAQ
Is HLS AES-128 the same as DRM?
No. AES-128 encrypts complete HLS segments and relies on secure key delivery. DRM additionally provides a key-system license workflow, client content-decryption module, policy enforcement, and a device-specific trust model.
How often should an HLS key rotate?
There is no universal interval. Choose it from rights policy, event length, threat model, player behavior, and the proven ability of the key service and CDN path to carry transitions safely.
Can the encryption key be cached?
RFC 8216 permits a key response to carry an expiry time, but the production policy must match authorization and revocation needs. Never let a shared cache ignore user or entitlement variation.
Why does a segment return 200 but still fail?
The player may have the wrong key or IV, lack an applicable license, receive incompatible signaling, or fail to decrypt or decode the protected samples. Preserve the playlist and client error around the first bad segment.