All client's should implement this and handle the 400 response safely. Under normal circumstances, with good client code, the 400 responses should not happen.
This is necessary to support different Cdm devices per-user. E.g., without this change if you do /open/a_device, you will only ever be able to use `a_device` until the next server restart. Even if you do /open/b_device, it will still use `a_device`, without error or warning.
This is because it stores the device with the Cdm in the previous change from storing the session ids to storing the Cdms instead.
With this change we can now have the user specify which device they are using, which allows us to map that to a Cdm that was initialized with the respective device.
Arguably we could remove the /{device} prefix and instead do a brute check on the app["cdms"] until we find a Cdm with a matching session, but this seems like a more semantic less hacky method to the madness.
(especially since /open already used {device}, but as a postfix)
The Cdm is now stored per-secret due to the Cdm object's session limit. This is so one user (by secret key) cannot overload the server with too many sessions.
But this also fixes it so that the serve API will work for more than just 50 sessions for all users. Otherwise the user pool will eventually overload the Cdm with 50 sessions, even if they close it, it will eventually happen. Think of it like the server being overloaded prematurely.
We may need the signature for external verification, and most APIs require it to be in a SignedMessage to be accepted, even though the SignedMessage is pretty much empty (not even actually signed lol).
This stops users from loading the license twice, which wouldn't do anything wrong, but without doing this context deletion we could possibly end up with a ton of memory that would likely go unused if the same Cdm session is used a lot for a long time.
I've moved the majority of Cdm initialization from /challenge to /open, this is pretty much necessary to have a proper session setup like Cdm now has.
A session setup is required for an API like this to know what cdm to associate user's calls with. The session ID it uses is now the same session ID it actually uses in the Cdm but it's returned to the user as hex. The user is expected to provide it in hex as well.
There's a few benefits to this but the main one being storage for each "request". We can now change Service Certificate per-session for example rather than for the entire Cdm object. In a multi-threaded scenario this can be a necessity more than anything.
The device is the only bit of data left that does not get stored in a session. This is mostly due to myself not seeing it being switched out often and setting it per-session would likely be cumbersome.
Some other small improvements are all around. There's a ton of doc-string improvements, typing improvements, verification of types, and there's now custom Exceptions.
In terms of bug fixes there isn't any I fixed explicitly but a possible issue in decrypt() relating the Key Labels may now be fixed.
I've moved the Keys from the return of parse_license() to the session data, with decrypt() now loading them from the session data instead. This keeps the decryption keys out of the view of the caller but it is by no way impossible to get those keys. It is incredibly trivial to access the session and get the keys from the Cdm manually.
A session limit of 50 is still set by the Cdm.
There's no need for the user to get back the verified DrmCertificate as they could easily get it themselves. Instead return the provider ID which may be more useful to get.
This is to signal what the Cdm really uses. Asking for a PSSH may sound like it uses a full PSSH when in reality all it cares for is the underlying init data (Widevine Cenc Header/WidevinePsshData).
The Cdm no longer requires you to specify if it's raw or not thanks to changes in PSSH.get_as_box() now supporting both dynamically.
It will parse the data and if its not a box, it will use the provided data in a newly crafted box.
This improves Cdm security and prevents a trivial exploit on Privacy Mode allowing an attacker to bypass Privacy Mode by controlling their own Public/Private Key Pair on Service Certificates.
The attack is simple in which you create your own RSA-2048 key pair, replace the public key of a service certificate with your own, and now you have the corresponding private key to be able to decrypt Encrypted Client IDs. This trivial attack is often used on CDM re-implementations, proxies, and APIs to obtain sensitive Device Client ID information.
With this commit this attack is prevented on this Cdm implementation, making it more secure from attacks. A signed DRM Certificate must be provided now as the ability to provide a direct DrmCertificate has been removed.
The root certificate added alongside this commit has no private key and cannot be used to re-sign an altered DrmCertificate.
Some service's might provide the Service Certificate as a SignedDrmCertificate instead of a SignedMessage so I added support for supplying such format certificates. I also added support for supplying a DrmCertificate directly, though it's unlikely for a service to provide it raw without a signature like that.
The Service Certificate is now also stored as just the DrmCertificate internally, as it will not be using the signature.
rlaphoenix