LiveTV Ka Content DistributionDeals/Non... · Web viewExamples of assets are an audio/video file...

Content Distribution

Of the LiveTV

Ka Connectivity System

April 3rd, 2014

LiveTV, 700 South Babcock Street Melbourne, FL 32901 USA

Phone: (321) 308-3900, FAX: (321) 308-3939

Email: [email protected]

Copyright 2013 LiveTV™

All rights reserved.

The information contained in this document is confidential and proprietary to LiveTV™. No part of this publication may be reproduced, copied, or the information contained herein disclosed without the expressed permission of LiveTV.

mailto:[email protected]

LiveTV Content Distribution for Ka Connectivity Project April 3rd,2013

Revision History

Date Revision Author – Comments

09Jul2013 IR B. Still – Initial Revision

16Jul2013 1.0 B. Still – Incorporate comments from LiveTV and JetBlue

03Apr2014 1.1 B. Still – Remove Cash N’ Carry capabilities

LiveTV™ - Proprietary & Confidential of 33


Acronyms

Acronym Definition

AAC Advanced Audio Coding

ABS Aircraft Base Station

AES Advanced Encryption Standard

ASU Airborne Server Unit

ATSC Advanced Television Standards Committee

AVC Advanced Video Coding

CDN Content Distribution Network

CMS Content Management System

CPS Content Packaging Service

CRU Control & Routing Unit

CWIP Certified WideVine Integration Partner

DRM Digital Rights Management

DSS Data Security Standard

DVB Digital Video Broadcasting

DVD Digital Versitale/Video Disc

DVR Digital Video Recorder

FAA Federal Aviation Administration

HLS HTTP Live Streaming

HTTP HyperText Transport Protocol

HTTPS HyperText Transport Protocol Secure

ISDB Integrated Services Digital Broadcasting

ISO International Organization Standard

IT Information Technology

ITIL Information Technology Information Library

KAMU Ka Modem Unit



KCS Ka Connectivity System

LCD

LED Light Emitting Diode

LTV LiveTV

LTV1 LiveTV Product Line #1



MAC Media Access Control

MLKS Master License Key Server

MPAA Motion Picture Association of America

MPEG Moving Pictures Expert Group

MPEG2-PS Moving Pictures Expert Group – Program Stream

MSS Media Support Services

OS Operating System

PCI Payment Card Industry

PED Passenger Electronic Device

PFW Portal FrameWork

RAM Random Accessible Memory

RTMP Real-Time Messaging Protocol

SELinux Security Enabled Linux

sFTP Secure File Transport Protocol

SSID Service Set Identification

STB Set Top Box

TV Television

URL Uniform Resource Locator

US

VLAN Virtual Local Area Network



VPN Virtual Private Network

WADL Wireless Aircraft Data Link

WAP Wireless Access Point

WDU Wireless Data Unit

WLLS WideVine Local License Server

WVM WideVine Media



Table of Contents

Revision History.............................................................................................................................. 2

Acronyms........................................................................................................................................ 3

Table of Contents............................................................................................................................ 6

Table of Figures.............................................................................................................................. 9

1. Scope..................................................................................................................................... 10

1.1 Purpose..........................................................................................................................10

1.2 Definitions....................................................................................................................... 10

1.2.1 Asset........................................................................................................................10

1.2.2 Content....................................................................................................................10

2. Overview................................................................................................................................ 11

2.1 System Capabilities........................................................................................................11

2.2 System Architecture.......................................................................................................11

2.2.1 Studios/Labs............................................................................................................11

2.2.2 Ground Segment.....................................................................................................12

2.2.2.1 Asset Repository..............................................................................................12

2.2.2.2 Content Management System (CMS)...............................................................12

2.2.2.3 Content Packaging Server (CPS).....................................................................13

2.2.2.4 Master License Key Server (MLKS).................................................................13

2.2.2.5 Content Release Area......................................................................................13

2.2.2.6 Airport Base Station (ABS)...............................................................................13

2.2.3 Aircraft Segment......................................................................................................13

2.2.3.1 Ka Modem Unit (KAMU)...................................................................................14

2.2.3.2 Wireless Data Unit (WDU)................................................................................14

2.2.3.3 Control & Routing Unit (CRU)...........................................................................14

2.2.3.3.1 Local License Key Server.............................................................................15

2.2.3.4 Airborne Server Unit (ASU)..............................................................................15

2.2.3.4.1 ASU Portal....................................................................................................15LiveTV™ - Proprietary & Confidential of 33


2.2.3.4.2 ASU Server...................................................................................................16

2.2.3.5 Wireless Access Point (WAP)..........................................................................16

2.2.4 PEDs....................................................................................................................... 16

2.3 Security Overview...........................................................................................................16

2.3.1 WideVine Technology..............................................................................................16

2.3.2 Content Always Encrypted.......................................................................................17

2.3.3 Restrict Access to Content......................................................................................17

3. Content Lifecycle...................................................................................................................18

3.1 LiveTV Credentials.........................................................................................................18

3.2 Studio/Lab Selection and Authorization..........................................................................18

3.3 Studio/Labs to Asset Repository.....................................................................................18

3.4 Content Management System........................................................................................19

3.5 CMS Publish................................................................................................................... 19

3.6 WideVine DRM Packaging.............................................................................................19

3.7 Distribution to Aircraft.....................................................................................................20

3.7.1 Ka Satellite Distribution............................................................................................20

3.7.2 Cellular Backhaul.....................................................................................................20

3.7.3 Wireless Aircraft Data Link (WADL).........................................................................21

3.8 Content Installation/Activation........................................................................................21

3.9 Distribution to Passenger................................................................................................21

3.10 Passenger Electronic Device..........................................................................................22

3.10.1 Laptops.................................................................................................................... 22

The browser client plugin integrates into a Flash player via the addition of a small amount of ActionScript in the flow that will be used to deliver video on the content website..........................................22

3.10.2 Android.................................................................................................................... 23

3.10.3 iOS Devices.............................................................................................................24

3.11 Destruction of Content....................................................................................................25

3.11.1 CMS......................................................................................................................... 25

3.11.2 Content Release Area.............................................................................................25



3.11.3 Aircraft..................................................................................................................... 26

3.11.4 PED......................................................................................................................... 26

3.12 Aircraft Maintenance.......................................................................................................26

3.12.1 ASU Installation.......................................................................................................26

3.12.2 ASU Failure.............................................................................................................26

4. Content Format & Specifications...........................................................................................27

4.1 Movie File Format...........................................................................................................27

4.2 Encrypted Asset.............................................................................................................27

4.3 WideVine Media Content................................................................................................27

5. Deployment Schedule............................................................................................................29

5.1 Schedule......................................................................................................................... 29

5.2 Roadmap........................................................................................................................29



Table of Figures

Figure 1 System Architecture........................................................................................................13

Figure 2 Ground Segment.............................................................................................................14

Figure 3 Aircraft Segment.............................................................................................................16

Figure 4 Airborne Server Unit.......................................................................................................17

Figure 5 Laptop DRM Solution......................................................................................................24

Figure 6 Android DRM Solution....................................................................................................25

Figure 7 Android Sequence..........................................................................................................25

Figure 8 iOS DRM Solution...........................................................................................................26

Figure 9 iOS Sequence................................................................................................................. 27

Figure 10 WideVine Architecture..................................................................................................31

Figure 11 DRM Roadmap.............................................................................................................32



1. ScopeThis section describes the scope of this document, including its purpose, overview and common definitions used throughout this document.

1.1 PurposeThe purpose of this document is to communicate the basic concepts for LiveTV’s design for receiving, processing and distributing DVD Ready content through its Ka Connectivity system. Its intent is to provide details regarding the protections used throughout the system to protect the content from unlawful access and/or copying (i.e., piracy).

This document is intended to be shared with commercial airlines that are seeking to utilize LiveTV’s Ka Connectivity System (KCS) to distribute Late Window (also known as DVD ready) content obtained from major studios to their in-flight passengers. In order to accomplish this, the airlines, in conjunction with LiveTV and its partners, must obtain necessary approvals from the content providers (namely, major studios or their agents). This whitepaper is intended to provide the necessary information and details regarding the security aspects throughout the KCS system.

1.2 DefinitionsThroughout this whitepaper, the following definitions are used. Within this domain, there are several terms that are often misused. This section provides clear definitions as used within this document.

1.2.1 AssetAn asset is a physical instance (typically a file) that contains the data that is to be rendered. Often, there are variations of an asset, such as resolution or language options. Each variant is a different asset instance, unless it is bundled with other variations. Examples of assets are an audio/video file (i.e., movie, TV show), audio (i.e., song or podcast) or digital formatted data (e-book etc.).

1.2.2 ContentContent is the high level accumulation of one or more assets that when bundled together, corresponds to a deliverable user experience. This often consists of assets along with metadata (such as thumbnails, descriptions and authors of an asset). For a movie, content typically consists of the actual audio/video file, textual descriptions regarding the movie (synopsis/description, release date, actors/directors, MPAA rating etc.) and thumbnail images used to represent the move (i.e., move “poster”).



2. OverviewThis section describes a system overview, describing key aspects of the overall KCS system, with primary focus on content and content delivery. From there, system block diagrams and key functional aspects of the system will be described.

2.1 System CapabilitiesThe KCS system was developed primarily to provide high speed “At Home in the Air” experience for passengers flying on commercial aircraft. However, as is common with all satellite service providers, the aircraft is not always flying over an area that is covered by the satellite. Airlines that frequently fly over areas where coverage is weak or non-existent would like to provide locally stored premium content to their passengers where they can continue to use their Personal Electronic Device (PED). In order to do so, it is necessary for content to be provided over a public WiFi network on-board the aircraft.

Since content is distributed over this public network, it is necessary to prevent distribution of this content beyond the intended recipient. Furthermore, once the content has been viewed by a passenger, it should not be possible to record, copy and/or distribute this content to others.

Another aspect of the system is that most airline flights average about 2 hours, which is slightly longer in duration than most content. Since the content is distributed over Wi-Fi and it is against FAA regulations to use electronic devices below 10,000 feet, the average actual “view time” may be closer to 1 to 1 ½ hours, which would render most passengers unable to watch the ending of a movie.

The following sections describe the technical details of how the system provides these capabilities while maintaining high levels of security and protection of the content throughout the system.

2.2 System ArchitectureFigure 1 shows a top level system architectural view of the KCS system. It consists primarily of four components that will each be discussed in detail throughout the rest of this document.

Figure 1 System Architecture

2.2.1 Studios/LabsThe studio/labs are entities that format and distribute the studio’s content to the airlines in a format specific to their use. In the KCS, the studios are selected and have arrangements with the airline. However, LiveTV acts as a service provider for managing and deploying that content to their aircraft. This is accomplished through LiveTV’s KCS system that includes both ground segment and Aircraft segment components used to distribute this content to passengers’ PEDs.



2.2.2 Ground SegmentThe ground segment is primarily responsible for receiving, processing, protecting and managing content prior to being distributed to the aircraft. Figure 2 shows the top level architecture of the ground segment.

Figure 2 Ground Segment

2.2.2.1 Asset RepositoryThe asset repository holds asset files that have been delivered by the studio/labs. These files, while in the asset repository are encrypted using Secret agent encryption. Files are delivered by the studios using secure file transport protocols (sFTP). Once delivered to this location, the content is not accessible to the labs or to airline users.

2.2.2.2 Content Management System (CMS)The Content Management System is the primary interface tools to airline personnel and to LiveTV media support specialists. This tool allows the creation of user interface setting in association with the content, such as pricing, defining time at which content will be available to passengers and miscellaneous data associated with the content.



As part of defining content, the metadata must ultimately be associated with the asset data. In doing this, the CMS users are provided a listing of assets, but are not provided direct access to the content. To easily support this, the LiveTV content specifications specify strict naming conventions to easily select assets based on the file name.

2.2.2.3 Content Packaging Server (CPS)The Content Packaging Server is responsible for taking an encrypted asset file and applying DRM policies as well as additional security aspects to the content. This process is an automated process that is initiated when the CMS is directed to “publish” a release of content.

During this process, the encryption that is on the asset is removed and the DRM encryption is applied. During this process, the decrypted asset is never stored on a physical storage device, preventing any party from having access to any part of the asset.

The CPS requires keys from the Master License Key Server (MLKS), as well as policies that were previously defined and associated with the content. When all assets within the release have been packaged, the MLKS is queried for its “exportable” dataset that is associated with all the content for subsequent transfer to the aircraft.

Portions of the CPS are components that are provided by WideVine’s DRM solution, specifically the packaging components and are integrally tied in with the Master License Key Server. Details of these interactions are proprietary to WideVine. LiveTV does not modify these components in any way.

LiveTV has subcontracted Morega Systems (in Toronto, Canada) as its partner to integrate the WideVine components into the LiveTV system. Morega is a Certified WideVine Integration Partner (CWIP) by Google.

2.2.2.4 Master License Key Server (MLKS)The Master License Key Server is provided by Google and is used in accordance with their specifications. The primary interfaces to the MLKS are the ability of LiveTV to manage DRM policies on behalf of the studios and the airlines. These policies, once defined, are not expected to change frequently.

2.2.2.5 Content Release AreaThe Content Release area is used as the final destination for “published” content. This location is accessible by aircraft through Ka Satellite and Cellular methods (content access by WADL is by ABS, as discussed in 2.2.2.6). This storage area is protected by firewalls preventing unauthorized access, even though the content in this area is strongly encrypted through the DRM process.

2.2.2.6 Airport Base Station (ABS)In order to deploy the encrypted content to the aircraft efficiently and cost effectively, the content is replicated from the content release area to local storage areas (i.e., Airport Base Station servers) at various airports. These servers are in highly secure areas of the airports and have dedicated communications paths to LiveTV. Access to these servers is available only through Wi-Fi access and the internal LiveTV private network is used by aircraft to access the content that should be loaded.

This process and the ABS functionality is the same process that is being used on other LiveTV products that are hosting early window content. This process is shown in Appendix C.

2.2.3 Aircraft SegmentThe aircraft segment contains all the equipment that LiveTV provides to the airlines for providing access to the internet, as well as providing local storage and streaming capabilities to the passenger devices. Figure 3 shows a top level architecture of the aircraft segment components of the system.LiveTV™ - Proprietary & Confidential of 33


Figure 3 Aircraft Segment

2.2.3.1 Ka Modem Unit (KAMU)The Ka Modem is the primary communications interface to the internet via the Ka band satellite. This element is not involved in the processing of content other than it provides some firewall protections, as externally generated internet requests are not allowed to the aircraft.

The CRU server ultimately manages all communications through the KAMU. Passenger traffic, when provided access to the internet, is routed through the KAMU.

2.2.3.2 Wireless Data Unit (WDU)The Wireless Data Unit is the primary communications interface to the internet over cellular networks. This element is not involved in the processing of content other than it provides some firewall protections, as externally generated internet requests are not allowed to the aircraft.

The CRU server ultimately manages all communications through the WDU. Passenger access to the internet is not allowed through the WDU.

2.2.3.3 Control & Routing Unit (CRU)The CRU is the primary management and control center for the aircraft. It manages the internal aircraft network, enabling and disabling network routes as conditions dictate. The CRU provides only minimal support for the distribution of content.

The CRU’s primary function as it relates to content is primarily administrative in nature. As passengers are authorized to receive content, the CRU maintains that information for several reasons. First, the CRU logs which user was authorized for which piece of content for logging and auditing purposes. Second, in the event that the



system is rebooted (due to power loss or manual override during flight), the system can restore passengers to their previously authorized content.

When a passenger is provided access to view a movie, the local WideVine license server (located on the aircraft) is queried by the WideVine component on the client application on the PED using WideVine’s proprietary protocols and security measures. In this role, the CRU only contributes by providing a secure environment and hosting the local license server.

2.2.3.3.1Local License Key ServerThe Local License Key Server is provided by Google/WideVine as part of our agreements. This application simply provides the local keys for content.

2.2.3.4 Airborne Server Unit (ASU)The ASU has two primary functions on the aircraft. The first function is that it provides the user interface for the system in the form of a portal. The second component provides basic functions in which the portal can securely interface with other parts of the system, primarily the CRU. These functions are discussed in the sections below. Figure 4 shows an overview of the ASU.

Figure 4 Airborne Server Unit

2.2.3.4.1ASU PortalThe portal is executed in a virtual environment separated from the rest of the system, primarily for security reasons. The portal interacts with the rest of the systems through a set of web services that are collectively



called the Portal Framework (PFW). The PFW communicates to the CRU over a proprietary protocol over a dedicated VPN making it impossible for unauthorized devices from communicating with core functions. Passenger devices do not have direct access to this the PFW, and as such do not have access to services that control the authorization of content or to the local license key server on the CRU.

2.2.3.4.2ASU ServerThe ASU server provides basic functions for managing the ASU “subsystem”, including aspects such as initialization, establishing network security measures and providing the bulk storage for all content. The ASU runs under SELinux (a secure version of standard Linux) with strict permissions.

The ASU hosts the content in a “content partition”, which is not accessible directly by passengers. Instead, this area must be “given” access, as a request by the portal after the content has been purchased. This content is “enabled” for each specific user, even though the content is stored in the WideVine DRM encrypted format.

Another key function is that it hosts the WideVine Local License Server (WLLS). This server receives the various asset encryption keys from the Master License Key Server (see 2.2.2.4), and provides them to the WLLS so that the content ultimately be decrypted at the appropriate time.

2.2.3.5 Wireless Access Point (WAP)The WAP is a simple access point controller that is configured to provide SSIDs for various user groups, one of which is a PASSENGER group. By associating SSIDs to VLANs, the CRU router can prevent unauthorized routing and/or access to the CRU and/or the ASU.

While content flows through the WAP, the content is still in WideVine DRM encrypted format. Even though the WideVine keys are communicated to the PED via the WAPs, those keys are encrypted utilizing WideVine specific encryption. As such, a man in the middle does not have the capability to intercept the content and/or keys and decode the content.

2.2.4 PEDsThe PEDs are personal mobile devices that are brought onto the aircraft by passengers. These devices are used to access both local networking services as well as the internet through the components provided within the aircraft segment.

These PED devices are loaded with “client” application(s) that contain WideVine components that provide the decryption of content just prior to being displayed on the PED’s display. This application is developed by Morega Systems (a WideVine Certified Integration Partner). This client side application provides the user interface components (i.e., ability to pause/resume, fast forward/rewind and seek).

The PED performs two actions with the system. First, the client application (actually the WideVine component embedded in the application) must retrieve the necessary DRM encryption keys from the local license server. Second, the application must retrieve the actual content file (which is DRM encrypted) through a standard HTTP streaming server application located on the ASU. Once it has these two components, the WideVine component of the application decrypts the content as it distributes to the native devices internal player.

2.3 Security OverviewThroughout this document, security is paramount to the handling and processing of content. The KCS system implements several security measures that provide not only protection of the content, but protection to the content, even though it is encrypted. Several goals are used in the security model of this system, and are described below.



2.3.1 WideVine TechnologyLiveTV has selected WideVine as the core technology used to provide DRM protection to content that is entrusted to the KCS system. WideVine has industry wide acceptance of all major studios, and numerous supported platforms in the mobile, desktop, set-top box and semi-conductor industries. A list of these can be found in Appendix A.

As part of the WideVine Certified WideVine Integration Partner (CWIP) program, partners are required to demonstrate adequate knowledge of both the WideVine products, but security of information as well. As part of their agreements, CWIP partners are required to insure the security and integrity of systems that utilize their technology.

The key aspects of WideVine are that they provide the key components of DRM technology (Master and Local license key servers) as well as the DRM library/components that exist on the client devices. They have secured the technology with hardened components, such that their products can be integrated into systems with minimal effort, but retains a high level of security.

2.3.2 Content Always EncryptedThroughout the entire lifecycle process, the original content is encrypted at distribution labs and is never stored in a decrypted format. When the content is decrypted from this original format into DRM format, it is performed in memory on secure/protected systems…never stored on disk while unencrypted.

It is not until the content is actually viewed on the PED’s display device is it decrypted. However, because it is within an application within the PED and requires both the DRM decryption module and the associated asset’s license key for use, it cannot be intercepted in an unencrypted format.

2.3.3 Restrict Access to ContentEven though the content is encrypted at every stage of the process, preventing access to the content further prevents unauthorized use and/or piracy. Several measures are provided to prevent unauthorized access both physically and through network connections to the content, and will be discussed in the lifecycle process.



3. Content LifecycleThis section describes in detail the content as it is processed through the KCS system.

3.1 LiveTV CredentialsLiveTV currently securely processes “early window” content on approximately 500 aircraft today on three product lines, namely LTV1, LTV2 and LTV3. LiveTV has successfully and securely transferred thousands of movies without incident for almost 10 years.

LiveTV is routinely audited by the Motion Picture Association of America (MPAA), most recently on November 13th, 2012.

3.2 Studio/Lab Selection and AuthorizationPrior to processing and/or receiving any protected content, a lab that is approved by the studios and meets MPAA requirements for handling of content is selected by the airlines. As part of this process, LiveTV provides documentation specifying the format and delivery options of the content. This includes specifications regarding file naming conventions, resolution of content and encoding standards, and other general file format information.

As part of this process, LiveTV generates a public encryption key that the labs will use to encrypt the content prior to delivering it to LiveTV. This encryption key is produced by a utility called “Secret Agent”(see section 4.2), which is based on AES encryption technology.

The public keys are provided to the lab(s) through secure means and are instructed to encrypt all content using the provided key. These keys are rotated every 2 years or earlier if there are any indications that the keys have been compromised.

3.3 Studio/Labs to Asset RepositoryUnlike the existing LTV based systems, the KCS system hosts many of its ground based servers in a cloud environment. As such, delivery of content on physical media is not feasible. Instead, the encrypted content is securely transferred from the lab to a content storage repository that is owned and managed by LiveTV personnel, but collocated in a cloud hosted environment. This is accomplished by using secure File Transfer Protocol (sFTP) from the lab to this environment.

The content repository is not accessible other than by authorized LiveTV personnel. This is accomplished through two means: physical and network.

The physical location of the content repository physically resides at the cloud hosting facility in Culpepper, Virginia. LiveTV utilizes the Verizon Terramark cloud based services, which is also used to host various government agencies. LiveTV has provided a physical high-capacity storage server and installed it at their facility for the express use of content storage. This facility is highly secure and unauthorized access to this server is extremely difficult. Even if physical access to this storage is possible, content is never stored on this device in an unencrypted format. For further information, see Appendix D for more information on Terramark cloud services.

As part of the sFTP transfer of content to this repository, only write access and directory listings are allowed. This is enforced by server permissions and sFTP configurations. Even if access to the actual content is compromised, it is still stored in a format encrypted by SecretAgent, and the private keys required to decrypt it are not stored on that server.



3.4 Content Management SystemLiveTV provides a Content Management System (CMS) that airline and/or LiveTV personnel use to manage various passenger facing aspects of the system. One of the key activities is the management of content that will be available to passengers on-board the aircraft. This includes activities such as specifying the content description, ratings, duration of movie and flight routes and associated pricing. None of these tasks require access to the actual content that is stored in the content repository, and is often performed prior to actually receiving of the asset.

However, at some point, this “metadata” must be associated with one or more asset files. In order to do this, only the name of the file (not the actual file) is required. The CMS provides a “file chooser” type of dialog that lists the available asset files to be associated with the defined content, but does not provide access to the actual asset file.

The CMS system is hosted in the cloud environment (physically close to the content repository) and is only accessible by authorized personnel, typically identified by the airline. Login credentials are required, and audit logs are generated. At no point in time is a user of the system allowed access to the encrypted asset files.

3.5 CMS PublishWhen content has been created and is ready to be deployed to the aircraft, the CMS system requires the content to be “published”. This process aggregates the content and its associated metadata, along with other required support files (like thumbnails, closed captioning text, subtitles etc.).

This automated process does not require human intervention, once the process has been initiated. The process examines the CMS provided data and identifies the asset files that are required for this content release. For each of the required assets, the CMS system performs a DRM packaging step that further protects the content for distribution to aircraft.

3.6 WideVine DRM PackagingPrior to packaging an asset, LiveTV personnel program the Master License Key Server with defined policies that are required. These policies are then associated with each content file by the CMS, and enforced by the WideVine DRM applications and/or libraries. Some of the basic policy attributes that are available are:

Distribution Window

Purchase Window

Clear Limits

Actions to take on license expiration (delete, retain etc.)

Number of times or duration of time to watch content

When the CMS “publishes” a release of content, each piece of content in the release must be converted to a secure format, with its DRM policies incorporated into it. In order to do this, the encryption that was placed on the assets by the labs must first be removed.

This is accomplished by applications that are coded with the LiveTV private “secret agent” key. This application exists on a cloud hosted server (separate from content serve) that has read access to the asset files in the content repository. This application decrypts the content into RAM, and the WideVine DRM packager then applies associated DRM policies to the content and then encrypts them both with its proprietary encryption. A



side effect of this is that the asset is assigned a unique “asset_id”, and the Master License Key Server internally assigns a key associated with that asset, and stores it in its database (in encrypted form).

Once the DRM packaging has completed, the DRM encrypted content is stored into a staging area, along with other metadata that is required. This process is repeated for each piece of content that is published for this release.

Once all the assets have been processed, the Master License Key Server is queried for its asset data. This data is provided in an encrypted format that the WideVine Local License Key Server can decrypt and update its data structures accordingly. This data is placed in a file and is loaded into the staging area. It’s important to note that each airline is associated as a different “distributor”, so that it is impossible for content to be inadvertently used across airlines, nor do one airline’s aircraft servers have the DRM keys to other airlines content.

These applications are tightly controlled through formal configuration controls and deployed to the hosting server only through LiveTV IT policies. At no time is the decrypted content “stored” on any storage device within the system.

3.7 Distribution to AircraftDistribution to the aircraft is very similar to existing LTV product distribution channels, but due to additional interfaces on the aircraft, additional methods are introduced in the KCS. Each airline’s aircraft configuration may have one or more of these interfaces, and configurations may or may not utilize all of these interfaces for transfer of content. These interface capabilities are:

Wireless Aircraft Data Link (WADL)

Cellular Backhaul

Ka Satellite

In order to deploy the content to aircraft, a deployment tool is used to analyze the content staging area and generate a manifest file that includes all files, their timestamps and an md5 checksum. This set of data is associated with a tracking identifier called a “campaign number”. This campaign’s deployment is then tracked across an airline’s fleet.

As part of the data movement from the ground system to the aircraft, each file has an md5 checksum computed and that value recorded in a manifest file. This checksum is subsequently verified on the aircraft once the transfer has completed to insure that the complete and correct file was transferred, and that no modification or corruption was made to it in transit.

3.7.1 Ka Satellite DistributionIt is possible to distribute content via Ka satellite, but it’s use is not highly anticipated due to the bandwidth and cost constraints of doing so. Content is typically released and loaded by the aircraft prior to it being activated on the aircraft. However, it is possible to prioritize content to be loaded to the aircraft, and the Ka Satellite distribution process is the fastest means available.

In this case, an sFTP connection is established back to the cloud hosted environment which contains the content staging area. The credentials associated with this sFTP are provisioned within the aircraft software. Once the manifest is read, the on-board content is examined and only those files that are different are retrieved by the aircraft and stored in a content storage partition. This partition is not directly accessible by passengers.



3.7.2 Cellular BackhaulSome KCS equipped aircraft have a cellular modem that is capable of reaching the internet and retrieving content. When configured to retrieve content via cellular interface, the same sFTP process used in the Ka Satellite distribution (see 3.7.1) is utilized.

In this scenario, the content is (previously) DRM encrypted and is distributed over a secure link to the aircraft, stored in a partition not directly accessible to passengers.

3.7.3 Wireless Aircraft Data Link (WADL)The WADL approach is slightly different from the Ka Satellite and Cellular backhaul approaches discussed in the previous sections. Instead, the content is distributed to one or more Airport Base Stations (ABS). These servers are located on airport property and are tightly controlled from both a physical and network access viewpoint.

The aircraft, when using the WADL for content retrieval, must first associate its wireless interface to a passphrase protected access point, and then establish a VPN tunnel to the ABS in order to begin accessing the content to load.

Even in the airport environment where numerous threats may be in proximity, a triple layer of content protection is in effect, keeping the content secure. This is significantly more secure than existing procedures used on existing LiveTV products.

3.8 Content Installation/ActivationOnce content has been physically transferred to the content partition on the ASU via one of the methods discussed above, the content must still be activated into the system. This is accomplished in two stages: license key installation and content installation.

During license key installation, the DRM license keys for the assets generated by the Master License Key Server in the ground segment are installed into the Local License Key server. This data set originates from a file created by the MLKS and is encrypted so that only the local license key server is capable of decrypting it.

The second step is to make the content available to the portal software so that the complete content (i.e., asset file, thumbnails, and other metadata) is available for the portal to make available to passengers. This is necessary since multiple files may be required to produce a single piece of content. In the KCS, the content is made available to the passengers on the next flight following the successful completion of all its associated files. Typical installations only retrieve content while on the ground (when no passengers are using the system). This is accomplished simply by making the content available to the portal in the content partition area, where the portal scans during initial flight processing.

3.9 Distribution to PassengerWhen a passenger would like to view a movie or other related content, they navigate the portal to select the content that they would like to see. Each airline has various user experiences to select and/or purchase this content, which is unrelated to the content itself.

Prior to viewing protected content, the passengers must have installed an application from either the portal or from a “store”, depending on their device. iOS devices are restricted to obtaining applications from the iTunes store. Android and Microsoft Windows devices can install applications directly from the portal. In these cases, the applications are digitally signed.



Once the passenger is authorized to view the content (i.e., paid for it), the portal requests authorization from the CRU for the specified user to view the content. Several actions occur during this authorization. First, the portal and underlying authorization services identify the requested PED for the user. This includes information specified by the user (i.e., user ID), PED IP address and PED MAC address. The CRU, in conjunction with the ASU, set up network security settings (i.e., firewalls and port forwarding) to allow access by the PED to the content through an HTTP streaming server in the ASU. Furthermore, a URL is provided to the PED indicating a URL that (indirectly) identifies the authorization credentials for the content.

Second, the CRU records the authorization as a second phase of authorization will subsequently come from the client device application. Once the application starts the “viewer” part of the application, a request is made to retrieve the DRM license keys associated with the content to be played. This is intercepted within the client application and an authorization verification transaction is made to the authorization service. Assuming the user is authorized, the original WideVine authorization is forwarded to the Local License Key server in which the secure keys are provided. It is important to note that neither the application nor any intermediate component can intercept the actual content keys, as they are secure within WideVine’s environment.

At this point, the DRM encrypted content is streamed from the ASU’s content partition to the passenger’s PED.

3.10 Passenger Electronic DeviceOnce the content has been authorized to be viewed, the content is delivered to the client device application that is running on the PED. The WideVine components ultimately perform the DRM decryption at the latest possible part of the process flow so that interception of the decrypted content is not possible.

In the initial launch of the product, there are essentially three classes of PED devices, namely: Laptops (which includes Windows based laptops), iOS devices (including iPad, iPod, iPhone etc.) and Android devices. Due to the different security aspects and the underlying operating systems, a slight different approach is required for each device type. These are discussed in the following sections.

3.10.1 Laptops

The browser client plugin integrates into a Flash player via the addition of a small amount of ActionScript in the flow that will be used to deliver video on the content website.

The WideVine plugin accepts an RTMP connection from the Flash player as well as makes an HTTP connection to the content server to request the video. The content is sent to the flash player over the RTMP connection, as shown in

Figure 5 Laptop DRM Solution



3.10.2 AndroidIn the Android scenario, a java based application provides access to the license and content servers. However, the WideVine DRM component decrypts the content as it goes into the native media player on the device. This is shown in Figure 6 and Figure 7 below.

Figure 6 Android DRM Solution

Figure 7 Android Sequence



3.10.3 iOS DevicesIn the case for iOS devices, the client application must instantiate a local loopback type server that converts the decrypted media into an HLS (HTTP Live Streaming) stream prior to going into the media player. The content is protected by the application (which must be signed and approved by Apple) not leaving the actual application space.

HLS includes a standard encryption mechanism using AES and a method of secure key distribution using HTTPS. This combination of security measures insure that the decrypted content inside the iOS device cannot be intercepted in its decrypted format.

Figure 8 and Figure 9 show the architectural solution and the sequence of events.

Figure 8 iOS DRM Solution


http://en.wikipedia.org/wiki/Advanced_Encryption_Standard


Figure 9 iOS Sequence

3.11 Destruction of ContentUltimately, content will expire and no longer be needed on the aircraft or on other servers, and will need to be destroyed. This section describes how and when this content is destroyed.

3.11.1 CMSWhen content is no longer referenced in the CMS system as part of the publishing process, there is no longer a need for the original assets to remain in the asset repository. In this case, once content is no longer referenced, it is removed from the file system by the publishing process.

3.11.2 Content Release AreaAfter a new version of content is released through the publishing process, previous versions are no longer needed and are therefore deleted from the file system. As part of the replication process, the ABS is also synchronized to this directory, which leads to removal at the ABS.



3.11.3 AircraftOnce a new release of content becomes active on the aircraft (through the campaign process), content that is no longer referenced is automatically deleted from the system. This occurs when additional space is required for new content, as it is common for content to be “revived” in a subsequent release, especially if it is popular. Due to the high costs to load content, it is preserved until space is needed for new content.

Since the KCS is not restricted to physical channels, as is the case with legacy LiveTV products, it is envisioned that content will remain over a much longer time period and will be automatically be replaced as soon as it is no longer needed, making room for fresher content.

3.11.4 PEDSince the PED does not physically store the content locally (i.e., on its local storage), no destruction of content is necessary.

3.12 Aircraft MaintenanceFrom time to time, hardware failures and/or new aircraft installations are required to be performed on the ASU, which contains the DRM encrypted content. This section discusses some of the aspects of content that require special considerations.

3.12.1 ASU InstallationAs part of ASU installation, there is no content initially loaded onto the ASU, so there are no concerns on the ASU’s and custody of content on them as they are stored in stock rooms and/or shipping from manufacturing to depot facilities.

Upon installation, the ASU’s begin loading content as described in this document, retrieving the license keys first, so that content is available as soon as it is loaded. The system continues to load content as it is able to during the remainder of the installation time, such that it has significant content loaded prior to passenger service.

3.12.2 ASU FailureWhen an ASU fails on the aircraft, LiveTV line maintenance will wipe the content partition where the encrypted content is stored. However, there are no guarantees that the ASU is in a state in which content can be destroyed by maintenance personnel, prior to going to the repair facility. This often occurs if a power supply or similar failure occurs.

After the unit is removed, it has very stringent handling and chain of custody requirements that are dictated by the FAA. It is important to note that even in this case, the asset files are in the DRM encrypted format, and are protected. As part of the repair process, the ASU disk is reformatted, erasing all traces of the content and keys prior to re-entering service.



4. Content Format & SpecificationsThis section describes the digital format and format specifications for content that is used throughout for locally stored (i.e., on-board aircraft) content. The format of protected content is has various formats as it progresses through the content distribution lifecycle.

4.1 Movie File FormatThe movie file format is the original rendering of content that includes both video and one or more audio tracks. This format is based on MPEG-4 based format that includes H.264 video encoding and Advanced Audio Coding (AAC).

H.264 (also known as Advanced Video Coding or AVC) is a standard for video compression. This format is perhaps one of the most commonly used formats for recording, compression and distribution of high definition video. It was jointly developed by the ITU-T Video Coding Experts Group (VCEG) and the ISO/IEC JTC1 Moving Picture Experts Group (MPEG). This joint partnership is often known as the Joint Video Team (JVT).

H.264 is a video codec that is perhaps best known as being one of the standards for Blu-Ray disc. It is also commonly used for streaming audio across the internet by several major video providers (such as YouTube, Adobe Flash Player and iTunes), as well as major cable and satellite providers as DVB, ISDB and ATSC.

AAC has been incorporated into standards by ISO and IEC as part of the MPEG-2 and MPEG-4 specifications. It is the default audio format standard for most mobile devices including iPhone/iPad/iPod, Android and Windows based devices. These devices are capable of decoding this format as part of their standard capabilities.

4.2 Encrypted AssetWhen an asset file (such as a movie) is encrypted with a public/private key, it is said to be encrypted. In the LiveTV KCS system (as well as existing TV systems), the labs that produce the assets to LiveTV specifications will encrypt the asset prior to delivering it to LiveTV.

The encryption process used by these labs is based on the world’s leading file encryption and digital signature utility called “SecretAgent” (often referred to as sa5). It is developed by Information Security Corporation. This utility is interoperable across several platforms and operating systems, including Windows and Linux. This algorithm is widely accepted in the industry and adds a means to use a Public/Private Key set.

LiveTV provides authorized labs with the public “encryption” key, generated from the sa5 algorithm. They use this key to encrypt assets for transport to LiveTV. Once encrypted, any intruder that intercepts the asset will be unable to decrypt it, especially since they will not have the public or private key associated with the content.

The private key is securely controlled by LiveTV’s Media Support Services (MSS) group. This group provides the public key to the authorized labs as well as maintains the private key in physically secured location, with tightly restricted access.

4.3 WideVine Media ContentThe WideVine Media format (WVM), often specified as “.wvm” format, is a format that was developed by WideVine which was later acquired by Google in 2012. This format is an extended form of MPEG2-PS which is modified by WideVine to allow multiple bitrates and DRM capabilities.


http://www.infoseccorp.com/

http://www.infoseccorp.com/products/secretagent

http://en.wikipedia.org/wiki/Moving_Picture_Experts_Group

http://en.wikipedia.org/wiki/Moving_Picture_Experts_Group

http://en.wikipedia.org/wiki/ISO/IEC_JTC1

http://en.wikipedia.org/wiki/Video_Coding_Experts_Group

http://en.wikipedia.org/wiki/ITU-T


Incorporated within WVM format is business policies as well as one or more encryption keys that are protected by content key (KC). This content key is generated by a WideVine Cipher Encryption Server (which we call the Master License Key Server) as part of incorporating it’s DRM policies, and is used to securely encrypt the content. The KC key is then securely managed by the WideVine master server. The actual content, after going through this process, is securely encrypted using WideVine encryption technology, even if direct access to the file is possible.

In order to retrieve the content in a decrypted fashion, it is necessary to retrieve the KC from the master server. In the aircraft environment, the master server is not always accessible. To solve this problem, WideVine provides a “local license server”, which acts as a “proxy” to the master server. During times of connectivity, the local license server is updated with content keys from the master server. During the transfer of the required keys and policies, the actual keys are protected by encryption keys known only to WideVine, as they are transferred between their master and local license servers. All on-board license key requests are handled by this local license key server.

Figure 10 WideVine Architecture



5. Deployment ScheduleThis section describes the current deployment plan, schedules and roadmaps that LiveTV is pursuing.

5.1 ScheduleThe planned completion date for development of the DRM solution is September 30th, 2013. The goal is to have gained studio approval prior to this date in order to deploy the solution to KCS equipped aircraft by the beginning of October. The primary features we are planning to support for launch of the product are:

Support for iOS, Android, and Windows (web) devices DVD Release Content

5.2 RoadmapAs our install base grows, the consumer market expands, and new devices are introduced, we plan to improve upon the introductory product solution by offering additional features that support the airline, LiveTV, and the studio. The roadmap below provides a high level view of some anticipated features we are looking to introduce to the DRM product.

Figure 11 DRM Roadmap



Appendix A - WideVine Platforms

Living Room

Cello TVs Dynex Blu-ray players EchoStar Sling Loaded DVRs and Sling Monitor Funai Blu-ray players and TVs GoogleTV Haier Blu-ray players Hisense TVs Insignia Blu-ray players LG Blu-ray players, TVs and home theaters Magnavox Blu-ray players Memorex Blu-ray players Nintendo Wii Onkyo Blu-ray players Onyx STB DPS1000 Oppo Blu-ray players Panasonic Blu-ray players and TVs Philips Blu-ray players and TVs Samsung Blu-ray players, home theaters, LCD

TVs, LED TVs and plasma TVs Sharp Blu-ray players and TVs Sony PlayStation 3 Sylvania Blu-ray players Telefonica Media Box Toshiba Blu-ray players and TVs Vizio Blu-ray players and TVs Yamaha Blu-ray players

Mobile

Acer tablets Amazon Kindle Fire Android platforms Apple iPhone, iPod touch and iPad Archos platforms Asus tablets Barnes & Noble Nook HTC tablets

LG tablets Motorola tablets Samsung tablets Toshiba tablets

Desktop

Apple Mac platforms Microsoft Windows platforms Chrome OS

Chipset Vendors

AllWinner Technology Amlogic Analog Devices Broadcom Conexant Freescale Infineon Intel LGE Magnum Semiconductor Marvell MediaTek Micron NVIDIA Novatek NXP Panasonic Qualcomm Realtek Rockchip S3 Graphics Samsung Sigma Designs ST Micro Toshiba LSI Texas Instruments



Appendix B – SecretAgent Architecture



Appendix C LTV1, 2 & 3 Content Process Flow



Appendix D - Terramark Credentials

Compliance Highlights: SSAE 16 (SOC 1) Type II Audited: Audited annually. All Terremark US

Locations, Brazil, Colombia, Turkey and Amsterdam (NAP of Amsterdam and AMS 5) are in scope for either Colocation or Managed Services.

PCI Compliant Level 1 Service Provider: All Terremark North America underlying infrastructure and facilities servicing Managed Hosting and Enterprise Cloud environments are in scope.

Safe Harbor Certified: Complies with Safe Harbor Privacy Principles necessary for communication with the European Union.

ISO 27001 Certified: Terremark Europe, Brazil, and Turkey run ISO 27001 Certified Information Security Management Systems. Implementation underway for US.

FISMA and DIACAP Compliant Federal Cloud: Operating Federal cloud environments for Agencies meeting FISMA - Low and Moderate, DIACAP –MAC Level 3.

ITIL v3 based best practices: Terremark uses ITIL as the primary operating framework for service delivery.

Security Highlights and Capabilities: Top Secret Facility Clearance: (as assigned by DSS) for Terremark

Federal Group - NCR and NAPMIA


LiveTV Ka Content DistributionDeals/Non... · Web viewExamples of assets are an audio/video file...

Documents

Transcript of LiveTV Ka Content DistributionDeals/Non... · Web viewExamples of assets are an audio/video file...