<--- larley.dev 1755635072
----------------------------------------------------
Client authentication
---------------------
PlayReady devices consist of two files. The 'bgroupcert.dat' file,
which is a certificate chain issued by Microsoft for a specific
device and the 'zgpriv.dat', a 32-byte long ECC private key point
(curve secp256r1).
The group certificate isn't directly usable as-is, but has to first
be fitted with an encryption and signing key, which can just
be generated.
To integrate them into the existing certificate chain, we firstly
create a new certificate, containing the respective public keys
of the encryption / signing keys and then sign all of that with
the group private key. The signature will also include the group
public key, so the server will be able to verify the signature.
The created (provisioned) certificate - as a file - is called
the 'bdevcert.dat'.
PSSH
----
A PlayReady PSSH (box) contains one or more WRMHEADERs, either
directly (wrapped in a PlayReady Object/Header) and UTF-16-LE
encoded or in the data section of a PSSH box with the PlayReady
SystemID '9a04f079-9840-4286-ab92-e65be0885f95'.
A PlayReady WRMHEADER example of version 4.3.0.0 is located below:
<WRMHEADER xmlns="..." version="4.3.0.0">
<DATA>
<PROTECTINFO>
<KIDS>
<KID ALGID="AESCTR" VALUE="B64 KeyID"></KID>
<KID ALGID="AESCBC" VALUE="B64 KeyID"></KID>
</KIDS>
</PROTECTINFO>
<LA_URL>http://rm.contoso.com/rightsmanager.asmx</LA_URL>
</DATA>
</WRMHEADER>
License Request
---------------
Communication between the client server only takes place
using XML where the WRM Header is placed in the
'ContentHeader' section of the license request.
To ensure that messages can only be read by the server and noone
else, we use the WMRMServer public key to encrypt our keys.
First, we generate a new temporary ECC key (called XmlKey), take
its X coordinate, convert that to bytes and then split it into
two halves. These two halves create a temporary AES IV and key
to encrypt data later on.
The aforementioned X coordinate in combination with its Y
coordinate is now encrypted with the WMRM Server public key, using
an ECC encryption algorithm called 'ElGamal'.
This will produce two points, which are converted to bytes and
then concatenated into a single 128-byte value (p1.x + p1.y +
p2.x + p2.y). This is our 'EncryptedKey' value in the challenge.
The temporary AES key and IV are now used to encrypt the
provisioned group certificate, and the IV is prepended to the
encrypted ciphertext, forming the main cipher data in the
challenge.
The digest (SHA-256) below the encrypted data is derived from the
'LA' section of the challenge (indents removed) and then placed
inside the 'SignedInfo' element of the XML.
The digest is used to create a raw ECDSA signature (r||s)
with the temporary encryption key, resulting in the 'SignatureValue'.
The signing public key is also placed in the challenge, to give
the server a way to verify the signature.
License
-------
The License, internally also known as XMR License, contains the
ElGamal encrypted content keys.
It's made up of containers, each with a flag, a tag and length.
A type value of 10 corresponds to a ContentKey Object and can
contain multiple encrypted content keys.
Each encrypted key is 128 bytes long and consists of two ECC Points,
each with a 32-byte X and Y coordinate.
We can use the encryption key we generated beforehand to decrypt
the two points, which will result in a single point.
Now, convert the point's X coordinate to bytes and take the latter
16 bytes of the 32 bytes to get the content key.