VUDU on iPad: An Overview
April 20, 2011
Highly Confidential
Introduction
VUDU provides instant, on-‐demand access to a large selection of movies and TV shows
through a variety of internet-‐enabled, living-‐room devices such as Smart TVs, Blu-‐ray
Players and set-‐top boxes. VUDU also provides instant access to these movies through
the VUDU web site utilizing Adobe’s Flash Access DRM for content protection.
One constraint imposed by the use of Flash Access is that content is not playable for
users accessing the VUDU web site on Apple’s iOS devices, since Apple does not
currently – nor does it intend to – support Flash Player on its devices.
This document describes VUDU’s solution for enabling customers to view their
rented/purchased movies on the Apple iPad via the VUDU web site. ( The solution also
applies to other iOS devices such as iPhone and iPod Touch, although our initial product
launch is focused on the iPad and iPad 2.) The same solution may be extended to
operate as part of a VUDU app that is published via Apple’s App Store.
It is to be noted, however, that VUDU’s current plan is to offer its service through its
web site – optimized specifically for touch-‐based navigation on the iPad’s built-‐in Safari
browser – rather than through a native application.
Overall Service Architecture for the iPad
The overall service architecture for delivering movies to customers viewing on an iPad is
largely similar to the architecture for Web customers, except that a Flash-‐based media
player is replaced by a HTML5-‐based media player that streams media using Apple’s
HTTP Live Streaming protocol.
We depict a picture below showing the video encoding and encryption flow in the
overall system as it pertains to the iPad.
1. Content is encoded in digital form in-‐house or at a secure studio-‐approved,
partner encoding facility.
2. Content is encrypted at the Encryption Station in VUDU’s facility.
3. Encrypted content is then distributed among VUDU content servers. Note that
the content servers do not possess any content keys.
4. Prior to a client iOS device ordering a title, the user is first required to log into
the VUDU by means of providing a user name and password over HTTPS. This
login process results in a non-‐persistent, time-‐limited login session represented
by an authentication “cookie” on the client.
Encryption
Station
Key Server
Content
Server
Edge Server
iOS
Client
Internet
Keys
Encrypted
Content
License
File over
HTTPS
Encrypted
Video
5. When the user orders a title (over HTTPS), the authentication token is used to
validate the user’s identity and charge the user’s credit card as required. The
client is then provided with a unique, personalized HTTP URL from which to
stream the movie.
6. This URL is passed on to the Safari browser for initiating playback of encrypted
content through HTTP Live Streaming.
7. The video itself is encrypted. When the Safari browser parses the video
metadata file and detects that the video is encrypted, it sends a request to the
key server URL (specified in the metadata file) over HTTPS. This HTTPS request
includes the user’s authentication token.
8. The key server validates the user identity by means of the session cookie,
ensures that the user has the rights to play the video in question, ensures that
the user is not logged in on a different device (and if logged in on other devices,
forces the termination of streaming sessions on those devices), and then
provides the key in question to the iOS device.
9. Keys are requested only by the Safari browser over HTTPS, thus preventing
either unauthorized snoopers on the network or malicious software on the client
from gaining access to the keys.
10. The browser decrypts video on the fly and plays it back without storing any clear
data on any persistent storage medium.
Security Architecture
Overview
The security of the above architecture fundamentally stems from the following
properties:
• Content is encrypted using AES-‐128 in CBC mode, a secure cipher.
• Content is stored encrypted at all points along the chain. Clear content is never
persistently stored on any server.
• Content decryption keys are only delivered to authenticated users’ devices, after
validating that the user has already paid for the content.
• Content keys are always transmitted securely over HTTPS, preventing any man-‐
in-‐the-‐middle attacks.
• Apple’s Safari browser is responsible for securely decrypting, decoding and
playing back video. Since this functionality is built into iOS and protected by
Apple’s security mechanisms, it is not possible for any iOS application to snoop
on, intercept or modify the data along the way.
The following sections describe the security features in greater detail.
Content Encryption
A/V content is encoded as H.264 video and AAC audio encapsulated in an MPEG2
Transport Stream container. The content is fragmented into many small multi-‐second
“chunks”, so as to allow for adaptive streaming (enabling the client device to select a
different encoding bitrate for each chunk based on the available bandwidth at that point
in time).
Each chunk is encrypted using AES 128-‐bit encryption with Cipher Block Chaining.
More details about the specification for content encryption may be found at:
http://tools.ietf.org/html/draft-‐pantos-‐http-‐live-‐streaming-‐06#section-‐6.2.3
Purchase Process
When the user desires to play a movie, the following steps happen:
1. A secure connection is established between the device and the head-‐end using
HTTPS. The authentication is a two-‐way authentication:
a. The client validates the VUDU server using certificates.
b. The server validates the user by means of a username and password.
c. The above ensures that the device cannot spoof the user’s identity to the
server, nor can the device be tricked into talking to a server different
from the VUDU server.
2. A purchase request is sent from the device to the server for the specified movie
at the specified price.
3. The server forwards the request to the back-‐office system for validation that the
offer being requested is legitimate, that the user’s account is in good standing,
and that the user has not been revoked.
4. Once the backoffice system approves the request, the user’s account is charged,
and the user is notified of a successful transaction.
Protecting Video Streams and Keys
1. Once the client has been notified of a successful purchase, it may request a URL
to play back the movie.
2. The URL for streaming encrypted video is further protected by means of the
following techniques:
a. Time-‐windowing: The URL is only valid for a limited duration of time,
capped by the rental expiration time, or 24 hours, whichever is smaller.
b. Device-‐limited: Accessing the URL requires a unique (user and login-‐
specific) authentication token that is provided only to the client device at
the time of user login.
c. IP address limited: The URL is also limited to be accessible only from the
IP address of the client device, so that it is impossible to have multiple
clients in different networks attempting to stream the video.
3. The URL for the video streams is provided to the iOS Safari browser, which
proceeds to download metadata information about the movie (See
http://tools.ietf.org/html/draft-‐pantos-‐http-‐live-‐streaming-‐06#section-‐6.3
) .
4. Once the browser recognizes that the video is encrypted, it attempts to fetch the
content decryption keys on demand from the HTTPS URL specificed in the
metadata.
5. When the key server receives a HTTPS request for content keys, it verifies the
authentication tokens attached to the request to ensure the identity of the user.
It also verifies that the user is permitted to stream the movie at that time (i.e.,
that they own or have rented the movie, that their rental window has not
expired, that the user has not been revoked and their account suspended, that
the user is not streaming the video from any other device at that time). After
such validation, the decryption key is provided over HTTPS.
6. The Safari browser fetches video chunks as necessary for streaming, decrypts
them with the key it has fetched, and plays back the video.
Content and Key Protection on the client
Neither the clear content, nor the keys are ever exposed to 3
rd
party client applications
or to code running within the browser. Only the built-‐in web browser on iOS – which is
protected from modification by Apple’s security mechanism – handles keys or clear
content.
Also, all content is streamed and therefore there is no persistent storage of either
encrypted or clear video.
Revocability and Renewability
Since the entire system is a two-‐way system, the process of revoking a specific client –
for example, when it is determined that a particular user’s device has been
compromised – is extremely easy. The VUDU server maintains a list of revoked user
credentials, and immediately cuts off all access to content for those users.
Dostları ilə paylaş: |