Content Protection

Canvas Content Protection for Online Video Content

1. Purpose

Further to the BBC Trust approval of Canvas and as requested by a number of key stakeholders in their submissions to the BBC Trust approval process, this paper outlines the content protection strategy being proposed by Project Canvas for online video content. This strategy has been developed to take into account the differing needs of all participants within the connected television ecosystem: content owners, content distributors, consumer electronics manufacturers, ISPs and consumers. We welcome comments with regard to our specific DRM choice in the context of the overall strategy, no later than 20th July (Please email comment to [email protected]), clearly marked content protection in the subject header). Specific decisions related to the other content protection options outlined will be detailed in subsequent documents. We continue to engage with the DTG’s Connected TV Security Group as part of establishing areas of common agreement via the Connected TV process and plan to contribute an “IP Content Delivery: Content Protection” technical document to that group on 19th August. A summary of requirements considered is provided in section 2. In seeking to address these requirements as fully as possible, Canvas will support a range of content protection technologies. This approach will ensure that Canvas can enable the delivery of a broad range of content, from user generated to premium, in the most cost-effective manner. The range of solutions is outlined in section 3. Within the range of content protection options Canvas will support a DRM solution, to meet the needs of providers of premium content or those requiring a download model. Aware of the complexity of delivering DRM and hence the importance of identifying a solution as soon as possible, this paper provides specific information about the approach to a DRM solution and the specific solution Canvas proposes supporting at launch (see section 4). Whilst not strictly related to content protection for online video content, for completeness this paper also clarifies the position that Project Canvas intends to take with respect to content protection for broadcast video content (see section 5). By providing the industry with clarity on the content protection solutions Canvas will support, manufacturers will be in the best position to agree commercial terms and pricing and be able to test, develop and incorporate these solutions into their products.

2. Needs of the Industry

In developing its content protection strategy Project Canvas has attempted to take into account the differing needs of all participants within the connected television ecosystem: content owners, content distributors, consumer electronics manufacturers, ISPs and consumers. A summary of the requirements considered is as follows:

For content distributors…

Support key content delivery use cases
- On-demand, download and live
- Protect once, deploy everywhere: Enable encoding and protection of content so that it can be played on mobile, web, Canvas and any new propositions that come along in due course.

Minimise backend infrastructure and operational costs
- Support the most cost effective and appropriate levels of protection
- Minimise DRM license server and IPR licensing costs
- Maximise potential for re-use of existing content encoding systems, DRM systems,payment gateway systems, etc., for both PC and/or mobile distribution
- Easily plug into 3rd party payment gateways enabling flexible subscription and billing models
Minimise distribution costs
- Leverage existing distribution infrastructure where possible
- Enable use of commodity distribution infrastructure, including HTTP
- Enable caching of content – cacheability – for ISPs and even in the home
- Enable any given file to be streamed or downloaded
Minimise timescales for getting content approved for Canvas
- Meet the requirements of major rights holders allowing access to premium content with a minimum of content security debates
- Where possible provide a content protection system that will allow content providers to make their content available on Canvas straightaway, i.e. within existing rights agreements

For rights and content owners…

Ensure content is robustly protected Both in distribution and once on the consumer device

Provide a simple content security regime programme for all licensors Enable the use of a standard content protection template that can be added to existing rights agreements with content distribution partners.

Ensure that breaches can be dealt with Provide a content protection system that gives a good set of options and mitigation strategies if and when security breaches occur, and a clear line of responsibility for fixing the breaches in the code.

For ISPs…

Enable protected content to be cached in the network Adopt technology choices that allow content to be cached in the network .
Allow the same file to be streamed or downloaded Enable usage of single files that can be streamed or downloaded to reduce backhaul traffic
Support industry-standard HTTP delivery Enable use of Apache HTTP servers.

For consumer electronics manufacturers…

Minimise IPR licensing costs The solution should be easy to license whilst adding minimal cost to the overall unit.
Minimise development required Help manufacturers to ship a quality product, on time
Enable a modular design Allowing re-use of the Canvas software stack in other territories, where differentcontent protection technologies may be required
Minimise breach mitigation costs

For consumers…

Content protection must allow a seamless user experience
Content protection must not impact the interoperability of Canvas devices from different manufacturers
Enable simple mechanisms for payment signup and billing

For Canvas…

Ensure easy access to necessary content protection technology for all participants on a fair, reasonable and non-discriminatory basis
Minimise IPR licensing costs across the eco-system
Use industry standard solutions where applicable
Allow the same content protection technology to be used with different presentation technologies
Minimise development time across the eco-system
Content protection solution must provide appropriate breach mitigation strategies

3. Content protection for online video – more than DRM

A successful content protection strategy for online video content must meet the variedneeds of participants in the content creation, distribution and consumption value chain. In seeking to meet this challenge as fully as possible Canvas will support a range of content protection technologies. This will give content providers choice over the type of content protection they adopt in any given circumstance. Providing a choice is good in that it will increase the likelihood that, for a given content provider, Canvas supports content protection technology already being used. And making this choice a range is even better as it offers content providers the ability to optimise the cost of providing content protection against the requirements of the content rights holder, e.g. only use a high-end DRM solution when this type of content protection is really needed. The result should be time and cost savings for content providers in joining the platform, including development and ongoing running costs. To minimise the impact of providing such choice on consumer device manufacturers the content protection mechanism supported will as far as possible be based on a common set of core enabling technology. In fact the lighter weight content protection mechanisms that Project Canvas aims to offer are sub-profiles of fuller (but more complex) content protection technologies that will need to be supported anyway if content providers are to satisfy the demands of the more stringent rights holders. For the purposes of this paper, the content protection technologies that Project Canvas aims to support can be characterised as follows:

No Protection

Whilst No Protection may not seem relevant to a content protection strategy, this is a model employed by many current mainstream online video providers, the best known of which is probably YouTube. Clearly this will not be suitable distribution for all content but it will be viable in many cases, such as short clips & previews, help & FAQ videos, in-video ads and non-copyright or creative commons content.

Device Authentication

The next step up from No Protection is Device Authentication, where the content provider is able to verify that the device that’s requesting content is a trusted device – in this case a Canvas device – and not a device pretending to be one. Device Authentication is typically based on exploitation of a secret within the device. The most common example of this is the use of a client certificate, such as an X.509 certificate for an HTTPS connection. Secure code modules are an alternative approach. In the simplest case Device Authentication is used in conjunction with delivery of unencrypted content over HTTP. When coupled with the use of server-side techniques, such as transient URLs, this offers a sufficiently viable approach for some content providers. Therefore Project Canvas aims to ensure that Device Authentication can be used in this manner. However, some rights holders, such as US movie studios are increasingly looking for Device Authentication to be coupled with the delivery of content in a more secure manner – either by encrypting the channel in which the content is delivered (Transport Encryption) or by encrypting the content itself (Content Encryption). These are described in the following sections.

Transport Encryption

Today most premium content on the internet is streamed over an encrypted channel. Currently the most common means for achieving this is through the use of Adobe’s RTMPE technology, as used by for example 4OD, ITV, Hulu and YouTube (for premium content). There is also increasing use of HTTPS based streaming. In both cases the use of an encrypted channel is coupled with Device Authentication to deliver an effective content protection solution. The use of such Transport Encryption mechanisms has proved very attractive to content providers. In particular there is no requirement to integrate a content encryption process into the content production workflow – content providers can simply push the content out to a content delivery network (CDN) whose servers set up the encrypted channel with the client device. This has greatly reduced the barrier to entry for content providers wishing to bring web-video propositions to market. Project Canvas believes that the same will be true for connected television and that support for transport encryption mechanisms will allow existing web-video content providers to get onto the platform as quickly and cheaply as possible. Therefore Project Canvas aims to provide a Transport Encryption option within the range of supported content protection technologies.

Content Encryption

While Transport Encryption is currently the most widely adopted distribution means for rights sensitive content, it has the following issues:

Content delivered in this manner usually isn’t stored in encrypted form on content provider or CDN edge servers. This creates a potential point of attack, which may be a concern for some rights holders.
Content delivered in this manner requires on-the-fly encryption processing for each requested stream, which represents a server-side overhead.
Content delivered in this manner cannot be cached, which can prevent ISPs building and taking advantage of more efficient caching systems located at the edge of the network.

To address these challenges there is considerable industry momentum towards an approach of encrypting the content itself, which can then be delivered using commodity HTTP serving infrastructure. Whilst such a Content Encryption approach requires the addition of a content encryption process into the content production workflow it addresses the issues relating to Transport Encryption:

Content delivered in this manner can be secured at the point of leaving the content provider and will remain secured – regardless of the distribution path – through to a valid client device.
Once an item of content has been encrypted, the encrypted version can be stored for distribution to multiple client devices. Furthermore, for non-live content, encryption can take place in advance. These represent server-side efficiencies.
Content delivered in this manner can be split up into small file fragments, which can be individually encrypted as part of the content encoding process. As such files can be delivered over an unencrypted HTTP channel they can potentially be cached along the distribution path, increasing overall distribution efficiency. Note: Further benefits of this fragmented approach are that (i) it is a key enabler for adaptive bitrate techniques and (ii) it allows the same asset to be used for both streaming and download.

Project Canvas believes that Content Encryption is a key enabler for a sustainable, scalable distribution strategy for online video. Therefore Project Canvas aims to provide a Content Encryption option within the range of supported content protection technologies. In one incarnation of this option, Content Encryption will be coupled with Device Authentication, to provide a lightweight option that will support most – but not all – use cases. In a second incarnation of this option, Content Encryption will form part of a fuller DRM solution that will support more complex use cases – this is described in the following section.

DRM

Content protection is often equated with DRM. But such a robust and complex solution is only required for specific types of content , and much simpler solutions such as those described above will meet most, if not all, of many content providers’ needs. There are instances, however where a full DRM system will be required. This is true for providers of premium content such as the latest movie releases, HD content or those requiring a download model. Consider a scenario where a consumer is able to stream a file for 30 days, after which they can choose to buy the file for a nominal sum. In this instance:

the content provider only wants to encode the file once,
the content provider ideally wants to offer the same file for both streaming and download,
the consumer ideally doesn’t want to have to download a file again if it’s already cached on their hard drive as part of, say, it having been streamed recently.

The most effective solution to support this kind of scenario is to offer a full DRM solution, which is present in all devices. Therefore Project Canvas aims to provide a DRM option within the range of supported content protection technologies. However, as described in the previous section, this will be based on a Content Encryption approach that is common with other supported content protection mechanisms.

4. DRM support

Defining a DRM solution is a challenging task under any circumstances. It is about more than just a technology specification and indeed it is frequently the case that core DRM technology will need to be adapted to fit the particular environment of each particular platform. An effective DRM solution needs to address commercial and operational considerations such as: managing the concept of “trust” that underpins the system; definition of “compliance and robustness rules” that need to be observed by elements in the content protection chain, including consumer devices; and operational management of the DRM system including certificate/key generation and renewal, breach mitigation and in the most extreme case device revocation. It is also well-documented that DRM represents a complex IPR landscape, which also needs to be managed. An effective DRM solution also needs to address viewer considerations and be consistent with the delivery of a seamless user experience. It should be noted that the use of a DRM solution does not interfere with viewers’ rights under the Copyright Patents & Designs Act. Project Canvas has followed a robust process so as to be able to include a DRM solution within the range of supported content protection technologies. This has been informed by industry engagement, technical and commercial analysis and practical evaluation. The first part of this process commenced in 2009, focusing on 3 key objectives:

To investigate the potential for supporting more than one DRM technology
To review the DRM marketplace, identify DRM solutions compatible with the Canvas architecture and vision, and to undertake practical evaluation of the most promising technical options
To establish best commercial terms for the most promising technical options

These are described in the following sections.

Support for Multiple DRM technologies and DRM Interoperability

Having reached the conclusion that Canvas needs to provide a DRM option within the range of supported content protection technologies, the question became how many. The analysis therefore pointed towards three potential options for supporting more than one DRM system. Option 1: The first scenario considered was to replicate the current online-video landscape and allow content providers free choice over which DRM technology to use. This would allow them to re-use existing investments in DRM infrastructure, allowing them to get onto the platform as quickly and cheaply as possible. However, given that content providers are certain to make different choices this would effectively require all Canvas devices to support multiple (and probably many) DRM technologies. This would pose a number of challenges:

The need for extra hardware resources to support multiple systems.
Increased risk sharing execution/secure storage resources between systems make each system more vulnerable to an attack via the other co-located system
The hardware and software architecture for compliance with each DRM solution may be in conflict preventing multiple solutions co-existing on a device
Multiple intellectual property licensing, operational compliance and certificate provisioning costs for device manufacturers

Option 2: The second scenario considered was to allow manufacturers to implement a DRM solution of their choice. This would allow them re-use existing investments in DRM integration from other deployment activities, allowing them to get onto the platform as quickly and cheaply as possible. However, given that device manufacturers are certain to make different choices this would effectively require all Canvas content providers to support multiple (and probably many) DRM technologies. This too would pose a number of challenges:

Potential fragmentation of the overall content offer on different Canvas devices, whereby each service provider may not necessarily support all DRM technologies in the field.
Multiple intellectual property licensing, license serving and backend integration and operational compliance costs for device manufacturers

Option 3: The third scenario considered was to identify a single DRM solution for launch, as this would both reduce the overall cost to the Canvas eco-system and ensure the universality of the content proposition. Based on the above analysis and as indicated in published BBC submissions to the BBC Trust and the Trust final conclusions, Project Canvas bases its recommendation on ‘Option 3’, making an informed selection of a single DRM solution for launch, but in deploying the selected DRM solution will seek to leave open the potential for additional DRM solutions to be introduced in an interoperable manner in the future should this become necessary. In practical terms this means:

Standardising on a common media packaging and encryption format
Separating media packaging and encryption from licence serving
Not making the DRM trust chain the root of all trust on the Canvas device

As stated in Option 1, there are potentially significant technical challenges that need to be met so as to achieve support for more than one DRM solution in a single device. Whilst it may be possible to upgrade software post launch to implement additional DRM solutions, this can not be guaranteed and to a good degree will depend on the implementation requirements of any additional DRM solution that may be considered.

Technology evaluation

Candidate DRM technologies from a number of vendors and technologies in the market were initially evaluated in respect to a number of criteria including:

General architectural suitability
Deployment status: either deployed or near-market ready
Ability for Project Canvas and other parties to access the technology for the next stage of evaluation
Alignment with open platform principles

After consideration against the criteria indicated, the list was reduced to a shortlist of three – Microsoft PlayReady, Widevine Cypher and Marlin (developed by Intertrust, Panasonic, Philips, Samsung and Sony), all of which are DECE compatible. These were then assessed – via both analysis and practical evaluation – against a more detailed set of criteria as follows:

Fit with the Canvas eco-system
- Federated licence serving
- Separation of media packaging and encryption from licence serving
Support for key use cases
- HTTP-based unicast delivery of MPEG2-TS
- HTTP-based unicast delivery of fragmented MP4
- IP multicast delivery of MPEG2-TS / H.264 / AAC for linear channels
- Licence acquisition use cases
- Content licence use cases
Deployment readiness
- Completeness of solution
- Ability for all participants in the Canvas eco-system to easily access the technology
- Availability of suitable client porting SDK
- Extent of hardware integration with SoC vendors
- Availability of backend tools

Commercial terms

Canvas will not seek to manage the commercial terms with any DRM provider, but as part of the evaluation process, looked at the candidate providers to ascertain their most favourable terms in respect of:

Their ability to publish a standard rate card balanced across the proposed Canvas ecosystem (i.e. not biased towards Content Providers or Manufacturers)
Assurances on Intellectual Property and Warranties
Agreement on the processes they will undertake in the event of a security incident;
Liability and the perpetuity of licences in utilising their technologies
Timescales for infringement/revocation/rights issues
Jurisdiction location and the potential for UK-based contractual engagement
Fair, reasonable and non-discriminatory engagement with all Canvas partners, including localised support arrangements
Their ability to ensure that the Canvas ecosystem can be viewed by rights holders as far as possible as a single secure and approved ecosystem to assist as many potential participants as possible.

Outcome

Having assessed the output from the activities described above Project Canvas has identified Marlin as the most appropriate DRM solution for launch – both from a technical perspective including its alignment with the Canvas eco-system and because it offers the most favourable standard commercial terms to the industry. We also note that the Marlin standard is referenced by the Open IPTV Forum in its specifications. This offers the potential for the widespread adoption of a common technology and corresponds with the general principles of Canvas in taking a standardised approach to technology wherever possible.

5. Content protection for broadcast video

Project Canvas aims to build on the successful free-to-air broadcast platforms already present in the UK. Whilst these platforms don’t require content to be protected during delivery they do require a compliant receiving device to observe rules about how the received content may be used, e.g. use of copy protection mechanisms on digital outputs. Project Canvas will observe relevant rules. Project Canvas also anticipates that third parties may wish to develop a Canvas consumer device that includes Conditional Access technology, allowing it to support broadcast pay services. Canvas does not plan to offer CA functionality as part of a standard Canvas product. . However, Canvas will provide a framework for how broadcast pay services can be presented and managed within the Canvas-managed Top-Level UI.