What provisioning establishes
Widely deployed DRM systems give the device a credential before it can receive content keys, and Widevine does this through a provisioning exchange with a Google-operated service. The result is a device certificate and the key material associated with it, stored by the content decryption module on the device. From then on the CDM can produce a key request that identifies itself, and a licence server can decide whether that identity is allowed to receive the keys it asks for.
The practical consequence is a gate. Until provisioning has succeeded, a licence request cannot carry a valid identity, so an app on a fresh install, a factory reset device or a newly created emulator may show a provisioning call before it can play anything protected. Once it has succeeded, the certificate persists outside the app's data, so a reinstall does not normally require it again.
Provisioning sits at the start of the chain. The app asks its own backend for entitlement, reads the manifest, obtains a licence, and plays. Provisioning happens underneath all of that, before the first useful licence request, and it belongs to the platform component rather than to the application.
Why the device certificate matters
The certificate is the device's claim to be a genuine implementation of the DRM client. A licence server configured to enforce it checks the identity presented in the key request, and a request without a recognised certificate is refused whatever the account is entitled to. That refusal is about the client rather than about the user.
The same mechanism supports revocation. A certificate can be invalidated, and once it is, that device stops being able to obtain keys for content from servers that honour the revocation list. This is why a software-only client is fragile: it depends on an identity the operator can withdraw.
Hardware backing is a separate question from provisioning. A device can complete provisioning and still run with a software CDM in configurations where the platform allows it, and a device with a hardware-backed CDM can be provisioned in the same way as any other. Provisioning establishes who the client is. The secure execution environment decides what the client can be trusted to do with the keys afterwards.
How it appears in a capture
- It goes to the DRM vendor rather than the app's host. A small HTTPS exchange with a service the streaming operator does not run is the usual signature, and it may appear once per device rather than once per session.
- It is proportional to first playback. The exchange typically accompanies install or the first protected start, and it does not repeat for each title the way a licence request does.
- The body is produced inside the CDM. The application hands the platform API nothing more than a request to prepare a device, so the bytes in either direction are opaque to the app and to anything reading its code.
- The result is stored by the CDM. The certificate and its private key live in storage the platform component manages, which is why an app update or reinstall usually leaves provisioning intact.
The boundary it draws for reconstruction
Work on a protected playback flow reconstructs the server-side API specification the application drives: entitlement calls, manifest handling, token placement, licence request framing and session state. Those are the parts the application implements, and they are the parts a rebuilt client has to reproduce.
Provisioning is not part of that work. It is performed by the platform CDM against a service the operator does not control, and it produces key material that stays inside the component that generated it. A reconstructed client that needs to obtain keys uses a device that has already provisioned, and the work concentrates on everything the app layers around the licence exchange.
That boundary is also the reason an emulator or a test device matters to a project. Testing on an unprovisioned instance produces failures that belong to the DRM service rather than to the app's logic, and the first hour of an investigation can be spent on a problem that has nothing to do with the request being studied. Confirming that a device can play a known protected stream is a cheap way to remove that variable before any capture starts. An emulator also often identifies itself differently to the licence server, which changes the response even when the app is the same build as the one running on a phone.
When the sequence is written down, the deliverable mirrors what the application actually does: a client that obtains entitlement, reads the manifest, posts the licence request with the right identifiers and follows the session to the end, plus documentation of each step. Provisioning stays where it belongs, in the platform, and the analysis stays on the code the operator is able to change.
Related work
Reviewed 28 September 2026 · SReverse research desk