D‑Cine Player · 4.2.32 release
EAR-Tech encrypted media
EAR‑Tech wraps MOV, MP4, M4V and MKV sources in authenticated AES‑256‑GCM encryption without transcoding. Distribute encrypted packages and authorise a specific player for a defined KDM window.
For media that arrives outside a DCP
Pre-release trailers, adverts, review clips and alternative content often use ordinary media containers. EAR‑Tech gives those files a cinema-oriented encrypted delivery and playback workflow while retaining their source encoding.
Use it as the file-encryption control within your production security plan. MPA Content Security Best Practices—often called MPAA security requirements—cover the surrounding systems and organisation as well as the media file. The detailed deployment mapping below separates player capabilities from site responsibilities.
Three linked protections
256-bit authenticated encryption
Each new package has two independently random 128-bit components, joined in the defined order as one 256-bit AES media key. AES‑256‑GCM encrypts and authenticates the private manifest and each media chunk.
Composition and asset binding
Header, descriptor, composition/asset/key IDs, length and encrypted-asset SHA‑256 are checked. A failed authentication tag or mismatched package prevents normal decryption; the player reports the failure.
Recipient and time-limited access
A matching, currently valid KDM addressed to the player must supply both components. The private profile uses two conventional 128-bit KDM key packets to deliver the AES‑256 media key; external KDM-tool compatibility is qualified per product/version.
Read only what playback needs
The player authenticates random-access chunks and feeds clear bytes to FFmpeg in memory. Normal playback creates no complete clear temporary MOV/MP4/MKV file, and seeking uses the same authenticated reader.
Public package descriptors identify the composition and selected picture/audio metadata, including audio codec, channels/layout and sample rate for newly mastered packages. Original source paths and audio track titles remain private. Protect any clear source masters, recovery material, process memory, swap and crash dumps under the site's own policy.
How to use EAR‑Tech in an MPA/TPN production workflow
The current MPA Best Practices includes AES‑256 requirements for stored content and protected transfers in TS‑3.0, plus separate key-management practices in TS‑3.2. Use this implementation mapping to prepare evidence for your particular deployment. Official control workbook.
On smaller screens, scroll the table horizontally to compare all three columns.
| Security objective | EAR‑Tech / player capability | Complete it in production |
|---|---|---|
| Content at rest · TS‑3.0 | AES‑256‑GCM protects the packaged media payload and private manifest; chunk authentication detects alteration. | Keep the public package encrypted across staging, storage and backups. Separately protect source masters, public metadata, logs, swap and recovery material with approved storage controls. |
| Content in motion · TS‑3.0 | Copying the EAR package preserves payload encryption. | Use an approved AES‑256 TLS 1.2-or-later or VPN transfer configuration. Protect credentials and metadata too. Standard FTP compatibility requires a separately protected network path. |
| Key handling · TS‑3.2 | Fresh package key material and player-specific KDMs provide generation and controlled delivery primitives. | Deliver key material through a separate controlled channel; restrict and separate key-management duties. Document key lifecycle, compromise response and recovery, and qualify certificate/key strength against the content owner's policy. Keep private mastering material off distribution media. |
| Authorised playback | Account permissions, licence checks, trusted time, KDM recipient/validity checks and authenticated media reads gate playback. | Qualify the player certificate and KDM chain, manage operator access and test missing, expired, wrong-recipient and tampered-content failures. |
| Display and host protection | Default EAR encrypted-media policy requires authenticated HDCP output; the player reports protection failures. | Qualify the complete display chain, OS and administrator access. Record the permitted output path with the content owner; SDI support alone does not satisfy EAR's HDCP policy. |
| Operational evidence | Content identity, readiness, KDM dates, playback status and diagnostics support a traceable operating record. | Retain approved delivery, authorisation and playback evidence. Set access-review, retention, backup and secure-destruction procedures for the whole site. |
TPN provides assessments against the MPA Best Practices; it does not issue facility certifications. Content owners make their own approval decisions using that evidence. EAR‑Tech supplies a technical control within that assessment scope. TPN assessment and certification FAQ.
Master, deliver, authorise, play
Master
Use cine-ear create with a supported source. Re-encryption produces fresh composition, asset and key IDs. Secure the original and private recovery material.
Deliver
Transfer the public package directory through the approved path. EAR-specific ASSETMAP_EAR.xml and VOLINDEX_EAR.xml identify it separately from DCP discovery.
Issue KDM
Use the qualified distribution/KDM chain to issue both matching components for the intended player certificate and a window covering the complete show.
Ingest
Select an EAR ingest source. Verify composition identity, asset integrity and available audio metadata. Legacy packages without audio metadata need remastering to add it.
Preflight
Check certificate, trusted time, key coverage and authenticated HDCP output. A successfully imported KDM can still be expired or not yet valid.
Play and retain evidence
Play through authenticated memory reads. Record the release, recipient, validity, output configuration and required operational evidence.
Qualify the exact production chain
The implemented EAR profile is version 0, a private D‑Cine interoperability format. Record the mastering tool, player build, external KDM manager/version, certificates, codecs and display hardware tested together. Confirm normal playback and seeking, then test altered ciphertext, wrong/missing components, invalid time windows and loss of output protection.
Written by James Gardiner · Documentation updated 2026-10-31. For more information visit tools.d-cine.net. Check procedures against the installed release and venue policy.
