What stops pirates from extracting the key from the CKC?

Since the source code for the KSM is open and the spec explains exactly the structure of the CKC, what's stopping pirates from hacking FairPlay by parsing the CKC and extracting the content key? Is there a shared secret that they would need (that secret would have to somehow be shared between the device and the KSM).


The FairPlay certificate, being a public key, is also public knowledge; depending on the setup, it's usually shared on an Internet-facing server or as a resource in the app.

Replies

The guide says, under "Identifying Your FPS App with an Application Certificate":


Every playback app that uses FPS must find the media’s key server and establish communication with that server. When messages can be exchanged between the iOS device and the key server, the app must send the server an FPS-created SPC message. This message contains a hash of the Application Certificate identifying your private key.

...

Verify that the hash value in bytes 152-171 of the SPC correctly identifies the private key of the developer from which the module expects to receive SPC messages.

...

In the code sample shown in the iOS FPS Client sample (included in the SDK), kTestAppCert contains the Application Certificate.


Who's private key does it refer? The certificate we pass to iOS when creating an SPC is the one issued by Apple specifically for FPS purposes (its CN attribute begins with "FairPlay Streaming"). The application doesn't have the private key for this certificate, only the KSM has it.

Which certificate is the Application Certificate -- that "FairPlay Streaming" certificate or the one used to sign the app for AppStore distribution?

I don't see kTestAppCert anywhere in the code sample.

You need or your customer needs to apply the deployment package for FPS deployment, then you will have your private key and your certificate.

Apple sample provides a development certificate but it can't be used for real playback.

This private key is known only to the server, not the app. And it can't be used to authenticate the app to the server.

Yes, the privae key is known only to the server. This is like the HTTPS, the public key in the certificate encrypt the content then server use private key to decrypt the content. Inside the content there is temporary key for further communication. Unless you hack the Apple system you can't parse the contentKey inside the CKC.

That part I understand. What I don't understand is how the KSM authenticates the app, if at all.

The guide says that it has to check that the hash matches, but what should it be compared to?

while it's the common verification of the certificate and private key i think? even the KSM seems just ignore this part... anyway if they are not match you can't decrypt the SPC correctly.

Well, my fear is someone (a subscriber) finds the URLs (for the content and the license server, custom data passed, etc) from the network and then creates an SPC, sends it to my DRM server, gets a CKC and extracts the key from it.


Like I originally wrote, anyone can create an SPC. Since the spec is open, you don't even need an iDevice, you can use a Python script for example.


So the server must have a way to authenticate (validate) the app before it sends a CKC.

Ok, I understand now, I suppose as the certificate is signed by Apple Root certificate you can't use Python to generate the SPC but only iOS/tvOS can(with the specific API). Anyway you can try:)

Hi,


If you look at the original WWDC video from when FairPlay Streaming was announced, it is quite explicit that further layers of authentication and authorisation of the app and/or user is the responsibility of the implementation.