This post is also available in: Russian

Development of professional video applications for iOS devices (iPhone/iPad) is often associated with implementing reliable tools for content protection. Otherwise, the copyright holders would scarcely entrust their professional video content to your application. In this post, we will brief you on the technicalities of implementing DRM for video services run by iOS devices.

The basics of DRM. Most DRM solutions share a common architecture. First of all, the content is processed by the DRM encryption module (with AES-128 usually applied), and the license control module provides users with keys to view the content (this module is usually built on Java Application Server). With such implementation, you can more effectively separate the stages of content processing, content delivery and viewing permission management. The figure below shows a typical architecture of DRM solutions.

Such architecture is specific to Adobe Flash Access solutions (Java Tomcat + Flash Player / AIR), Microsoft PlayReady (IIS + Silverlight), Widevine DRM. In case of Adobe Flash Access, the backend is based on the Apache Tomcat Java Application Server.

In case of iOS content protection, Apple video player only decodes video data received over HTTP Live Streaming using a preset decryption key and a standard AES-128 algorithm. In this case, the developer of video service for iOS devices needs to implement a server-side storage mechanism for encryption keys to provide for their careful issuing, while ensuring robust reception of the keys on the client side at a minimal risk of interception (for instance, by implementing jailbreak detection inside the application). The flow chart of content protection on iOS devices is shown below.

Let us now consider in more detail DRM implementation in the iOS devices.

HTTP Live Streaming. First of all, let’s consider the principles of delivering video content using HTTP Live Streaming. HTTP Live Streaming (HLS) has triple architecture: video server part, content delivery part, and client software.

• Video server part is responsible for receiving and encoding (or transcoding) video content, packing video into a suitable format for further delivery and preparation for distribution.
• The system of content delivery for HTTP Live Streaming consists of standard Web servers (caching HTTP Proxies).
• The client software is responsible for requesting the media content needed, downloading of supplementary resources and their presentation to the user. The client software is included into iOS since version 3.0 and into Safari installations since version 4.

In a standard configuration, the hardware encoder receives audio and video input, compresses video with H.264 codec and audio with AAC codec, and provides results as MPEG-2 Transport Stream. This stream is further split into a sequence of small files (chunks) using the Stream Segmenter software. Also, the Segmenter creates an index file containing a list of chunks. All these files are put to a Web server. The client software reads the index file and then requests chunks in correct sequence to enable continuous viewing.

Content protection in iOS browser. Delivery technology. The player (client software) first downloads the index file by the URL identifying the multimedia stream. The index file determines the location of available multimedia content, decryption keys and alternative flows. For the selected stream, the player loads sequentially all available media files (each file contains relevant video segments). Once sufficient media data is loaded, the player starts playing back the combined multimedia stream.

The player is responsible for pre-loading of decryption keys, authentication (or presenting of authentication GUI) and decryption of media content, if necessary.

This process continues until the #EXT-X-ENDLIST tag is found in the index file. If the #EXT-X-ENDLIST tag is not found, the index file is part of current online broadcast. During online broadcasts, the player loads the updated index file periodically, checks for new media files and decryption keys, and adds them to the playback queue.

To ensure protection, multimedia files can be encoded separately from stream segments. In case of encoding, references to the relevant decryption keys are saved to the index file so that the client can obtain them to decrypt the content. Currently, HTTP Live Streaming supports AES-128 encryption with 16-byte keys. The Apple Media Stream Segmenter supports three encryption modes.

• In the first case, stream is encrypted with a key previously stored on a local disk (all media files of the stream are encrypted with a single key). This mode is implemented in Adobe Flash Media Server.
• In the second mode, the Segmenter generates a random key in advance and stores it to the hard disk. After that, this key is used similarly to the first mode.
• In the third case, the Segmenter generates a random key every n segments, saves them to the disk and registers references in the index file. This mode is often referred to as decryption key rotation.

Operations with keys. Apple suggests using HTTPS to protect keys delivered to the browser video player. There also remains a risk of key interception when the device has been hacked (Jailbreak) or has been emulated on a PC in some way. To substantially reduce this risk, you have to introduce additional checks by writing your own applications. We are going to discuss this further.

Content protection in an iOS application. Content delivery and protection technology is identical to DRM implementation in the browser player, although here we have similar and enhanced features involving decryption keys.

Operations with keys. In addition to HTTPS key delivery, when writing your own application you can provide for the installation of your own certificate, thus ensuring that the content is delivered to your application only. At installing the application, you can inspect the device for Jailbreak. As a rule, such approach is required by the copyright holders. Also, as a rule they easily approve of using video players from Authentec / SecureMedia / Discretix / Irdeto (DRM mechanisms of these players have been endorsed), but no one prevents you from implementing these mechanisms yourself.

Materials. Here is the list of materials used to prepare this post: Apple’s official documentation, a new release of Adobe Flash Media Server 4.5 with support for HTTP Live Streaming and documentation on it (in our projects, we often use FMS 4.5 for streaming to iOS devices, although sometimes we have made alternative configurations; and NGINX as edge caching proxy) .

In the near future, we will publish a series of posts on developing video players for iOS devices, taking a closer look at adding of video content to applications and iOS Web pages. Besides, our iOS developers are always eager to answer your questions 🙂

Wishing an immense popularity to your video service!