Cracking the code: Apple’s DRM Technology (Part-1)
Introduction to Fairplay DRM
“Fairplay DRM” is basically Apple’s Digital rights management technology. Fairplay is also known as Fairplay Streaming (FPS), whose main role is securely delivering the encrypted contents through HTTP Live Streaming Protocol. It prevents video download as well as ensures screen recording protection when protected content is streaming.
In other words, Fairplay is used to stream the content securely on the iOS app, macOS app, and tvOS app. Fairplay DRM supports Apple’s wireless content delivery protocol, “Airplay.”
The content can be played on Apple devices and Operating Systems using Airplay without any additional encoding or decryption. This content maintains an equivalent level of security to that experienced when played on its original devices, like iPhones.
FairPlay DRM History
Fairplay DRM was originally developed by Veridisc. It was later adopted by Apple. And now known as Fairplay DRM.
Initially, Fairplay was used by Apple for audio file protection in iTunes. But later on, Fairplay was started to protect audio and video files.
What is FairPlay Streaming Server(FPS)
FPS is integrated into the device operating system, which supports Apple mobile devices(iPhone/iPad) and AppleTv. Safari on Mac OS enables Fair Play Streaming using EME interface support.
FPS’s main role is to deliver the keys to Apple mobile devices, AppleTV, and Safari on OS, which enables playback of encrypted video content.
Fairplay Compatibility with different Apple devices OS
Mobile-
- iOS Native App: iOS 9.0 or later
- iOS Safari browser: 11.2 or later
- iPad OS: 13.1 or later
AppleTV-
- tvOS: 10.0 or later
PC-
- macOS afari browser: 10.10 or later
Apple Watch-
- Watch OS : 7 or later
Features of Fairplay DRM
- Audio & Video Protection
- Offline Playback
- Apple Airplay Support
Working Of FairPlay DRM
1. The Client app notifies the device Operating System’s AVFoundation framework to play FPS content.
2. AVFoundation framework downloads the Manifest file m3u8 from the content server. and parse it internally.
3. AVFoundation parses it internally and searches for “EXT-X-KEY” or “#EXT-X-SESSION-KEY:METHOD=” tag to see whether the content is encrypted or not. if its value is “SAMPLE-AES” then this content is encrypted.
Note:
METHOD attribute tells the player which encryption method is being used to encrypt this content. If the content is not encrypted then the value would be METHOD=NONE, For AES-128 encryption, the value would be “METHOD=AES-128”.
4. If the content is protected, then AVFoundation/OS requests for FPS Key to the client application
5. In this phase, the Application provides the contentId and DRM-Certificate data to AVFoundation/OS to prepare the Server Playback Context (SPC).
6. In This phase, the OS creates a server playback context (SPC). FPS protects the Server Playback Context (SPC) with the content provider’s RSA public key. A number of verifications are performed by FPS to check the content provider’s certificate before exchanging encrypted media.
7. In this phase, the application sends an SPC message to the Key Server to prepare the CKC (Content Key Context).
8. Key server modules read the SPC (Server Playback Context) message from the CKC and revert back it to the app. Generally, in this phase, KSM (Key Server Module) wraps the content key and the initialization vector according to the FPS specification. Next, the server creates a Content key context in response to the application that contains the content key and the initialization vector.
9. The client application then provides CKC to the device OS to request a play context. AVFoundation/OS decrypts and plays content securely using keys contained in CKC data.
Stay tuned for the next part of this blog series with the Code snippets.
