iOS DRM: Secure iOS Video Delivery and Playback

This post is also available in: Russian

HTTP Live Streaming (HTTP LS) is a protocol strongly recommended and actively promoted by Apple as the best solution for online video delivery to mobile devices. But neither the protocol itself, nor its tools offered by the iOS API, implement a full-fledged DRM support. The new version of Adobe Access 4.0 adds this missing functionality to the iOS-devices.

Content Encryption Using HTTP Live Streaming

HTTP LS offers the capability to encrypt the content and enables secure user authentication to obtain a decryption key over HTTPS. For some developers, such capabilities may be quite sufficient.

Apple provides free tools for video transcoding into the HTTP LS format and its encryption. A single key might be used for all content or separate keys may be applied to each of the multi-bitrate streams. It is also possible to encrypt the content with multiple keys to alternate them within the same stream. In addition, the keys are protected by an "initialization vector" which can change during content playback.

At the moment, the AES-128 encryption protocol is supported. Links to the decryption keys are specified in the playlist containing video chunks. Each key encountered by the client in the playlist is loaded via HTTP or HTTPS and used for decryption. On the server side, you can implement your application-specific logic to restrict issuance of keys only to authorized users.

New Adobe Access Version with iOS Support

Today, the DRM system called Adobe’s Flash Access is almost the only solution enabling secure delivery of professional video with the largest coverage of Web audience. It has achieved this thanks to integration with the Flash Player plug-in, that has been installed by Adobe’s statistics, on 99% of Web-connected personal computers. However in recent years, there are two strong Web trends that are not playing the game of Flash Access. The first trend is the growing number and percentage of users that go online from their mobile devices where the use of Flash is complicated and often even impossible, by several reasons. The second trend is the growing interest among developers who are increasingly shifting from proprietary technologies, such as Flash and HTTP Dynamic Streaming, to open standards such as HTML5 and HTTP Live Streaming. Following the common trend, Adobe has released an update of its DRM system which is now called Adobe Access version 4.0.

Encryption features of HTTP LS served as the basis for implementing of features of the new, HTTP LS-enabled, Adobe Access version focused primarily on the iOS devices. Support for iOS is the most important and most anticipated feature of the new version. Adobe has announced support for iOS 4.3 and above, as well as the following models of iOS devices: iPhone 4 or iPhone 4S; iPad, iPad 2, or a new iPad; 4th gen iPod Touch.

In addition to updating the list of supported devices, Adobe Access has included the following features:

A common DRM for a wide variety of devices: Windows-based PCs, Linux and Mac OS X, mobile devices and Android media centers.
Content access filtering by devices, their types, operating systems, screen sizes, and hardware capabilities.
Easy scalability of a DRM system as the load grows.
Rotation of access keys.

Principles of Interacting with the DRM Server

To protect content from unauthorized viewing and distribution, the copyright holder creates a license for each piece of content. Before you start viewing, an application requests a license from the DRM server and, if necessary, authenticates the user. From the license data, the application gets copyright holder’s rules and restrictions to be met by the client side, and a content decryption key.

Running Adobe Access on iOS

Adobe Access comes with an SDK to support the DRM system and a sample AccessPlayer application based on this SDK. The SDK is a drmNativeInterface framework for Xcode that connects to a native application. To run the framework, you have to link the Security framework and the libstdc++ library. The API of the iOS framework copies the API functionality available for Flash-applications written in ActionScript, but with the method names and syntax refined to match the conventions adopted by the iOS developer community. Moreover, the iOS API makes an extensive use of the "block" syntax used in iOS to set callbacks for asynchronous methods. This way, you can write a more structured code, and at no additional effort associate the DRM-server responses with a specific session, unlike ActionScript where the callbacks are assigned using the event mechanism.

When the user application tries to play back protected content, the application has to access DRM using APIs provided by the SDK. The access involves multiple steps:

The application receives a DRM metadata file corresponding to the played back content. This file contains the information necessary to the application to get a license to view the content.
The application checks whether the required license has been previously loaded and saved to the device. If so, then the application starts decoding and playing back the content.
The application checks whether authentication is required to obtain a license.
If authentication is required, the application prompts the user for a username and password and sends the credentials to the license server.
If a domain registration is needed, the application performs it. By registering in a domain, you can use the same license on multiple devices logged into the domain.
After the authentication is successful, the application loads the license, caches it on the device and starts decoding and playing back the content. The cached license can be reused in the next viewing session.

In the simplest case, the code required for playback of protected video can look as follows:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
-(void) openPlaylist:(NSURL*)m3u8 

{ 

    DRMOperationError defError = 

        ^(NSUInteger major, NSUInteger minor, NSError * platformError) 

        { NSLog(@&quot;error&quot;); }; 

    DRMManager * manager = [DRMManager sharedManager]; 

    if ([manager isSupportedPlaylist:m3u8]) { 

        [manager getUpdatedPlaylist url:m3u8 

        error:defError

        updated:^(NSURL * newPlaylist, DRMMetadata * newMetadata) { 

            m_session = [manager createDRMSession metadata:newMetadata

            playlist:newPlaylist error:defError complete:^() { 

                self.playerItem = [AVPlayerItem playerItemWithURL:playlist]; 

                self.player = [AVPlayer playerWithPlayerItem:playerItem]; 

                [playerView setPlayer:player]; 

                [player play]; 

            }]; 

        }]; 

    } 

}

At the onset of content playback, some time is needed to initialize communication with the DRM server. To reduce the time needed, you can run initialization in advance.

When working with the SDK, please keep in mind that it has been purposely built so as to hamper debugging. The rationale behind this was to additionally protect the algorithms used by the framework.

Theoretically, by caching the license on the client side, secure offline viewing can be enabled, but in practice the iOS does not support built-in tools to save HTTP LS content to the disk, so you’d have to implement this yourself.

* * *

For more information on the Adobe Access features, please read our previous posts on the topic:

In preparing this article, we used the following sources:

Documentation available on the Adobe Access Web site.

PS
You still may be interested in other DRM vendors like Microsoft PlayReady, Widevine and others. In order to make a final decision you should conduct evaluation of some kind. In case of Adobe Access one of the biggest advantages is the single DRM solution for web (Windows, MacOS) via Flash (most common tool for premium video playback) and smartphones & tablets (iOS, Android).

DENIVIP Media

Video apps and services, technologies and business