GB2486718A

GB2486718A - Digital Rights Management with DRM-specific link layer encryption

Info

Publication number: GB2486718A
Application number: GB1021901.2A
Authority: GB
Inventors: Georgios Kalogridis
Original assignee: Toshiba Research Europe Ltd
Current assignee: Toshiba Europe Ltd
Priority date: 2010-12-22
Filing date: 2010-12-22
Publication date: 2012-06-27
Also published as: GB201021901D0

Abstract

A content receiver 106 â perhaps combined with set top box 103 or Gateway 102 â and a content output device â perhaps television 104, 105 â use a cryptographic key to establish a secure connection. The receiver uses the key for DRM-specific link layer encrypting of received content. The encrypted content is transmitted to the output device, which uses the key to decrypt the content. Content may be transmitted to the output device via a WiFi connection with link layer encryption according to the IEEE 802.11i standard, or via a Femtocell base station (Home Node B or HNB) with link layer encryption according to the 3GPP standard. The system may be an IPTV (Internet Protocol Television) or DRM system. The key may be requested, perhaps securely from a key distribution centre (KDC) 107, following receipt of content that needs to be link layer encrypted. The content may be subject to other DRM processing prior to the link layer encrypting. In an embodiment, the content receiver transmits a request for the key to a KDC when the content output apparatus requests the key. The content receiver may also be an IPTV gateway, a computing or mobile device or a Femtocell or Picocell base station.

Description

t V.' INTELLECTUAL ..* PROPERTY OFFICE Application No. GB 1021901.2 RTM Date:30 March 2011 The following terms are registered trademarks and should be read as such wherever they occur in this document: 3GPP Intellectual Properly Office is an operating name of the Patent Office www.ipo.gov.uk Digital Rights Management System and Method

FIELD

Embodiments described herein relate generally to methods and apparatus for digital rights management.

BACKGROUND

Digital rights management" (DRM) is a generic term that refers to access control technologies that can be used by hardware manufacturers, publishers, copyright holders and individuals to try to impose limitations on the usage of digital content and devices. The term is used to describe any technology which inhibits uses (legitimate or otherwise) of digital content that were not desired or foreseen by the content provider.

DRM functionality can involve complex access control procedures and on the fly encryption/decryption and can therefore be cornputationally expensive. DRM-enhanced digital content can only be supported by DRM-enabled devices. In large devices such as TVs, ORM could be implemented with hardware and firmware. In smaller devices DRM could become a bottleneck for performance and power consumption. Even if some of the DRM authorisation and licence acquisition functionality is transferred to a gateway (gateway centric approach, as opposed to a terminal centric approach in which the terminal provides the majority or all of the DRM functionality) the end terminals are still required to perform DRM specified encryption/decryption. In residential digital networks, providers provide subscribers with digital content such as video, TV, music, etc. It is important to note that ORM encryption/decryption typically refers to a DRM cryptographic function that is applied by the DRM system on DRM related content or applications. Such a high layer cryptographic function does not preclude other cryptographic functions used in lower layers such as link layer. For example if DRM- protected content is transferred over a WPA-protected WLAN network, then DRM-encrypted content will be further encrypted by the WPA protocol.

Almost all ORM solutions fall within the terminal-centric or the gateway-centric general categories as described.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will be described in the following by way of example only and with reference to the accompanying drawings, in which: Figure 1 shows the system architecture of an IPTV system according to an embodiment; Figure 2 shows the structure of a Link Layer DRM Gateway and a Link Layer DRM TV according to an embodiment of the present invention; Figure 3 shows a known terminal-centric DRM system; Figure 4 shows a known gateway-centric DRM system; Figure 5 shows a terminal-centric DRM system with LLDG add-on; Figure 6 shows a gateway-centric DRM system with LLDG add-on; Figure 7 shows a DRM system combining the functionality of the systems shown in Figures 5 and 6; Figure 8 shows LLD-TV session management operations; and Figure 9 shows System LLD initialisation and session management operations.

DETAILED DESCRIPTION

According to an embodiment there is provided a system comprising a content receiver and a content output device. The content receiver and a content output device are arranged to use a cryptographic key for establishing a secure connection between the content receiver and the content output device. The content receiver is arranged to use the key for non shared link layer encrypting to received content and to transmit the link layer encrypted content to the content output device. The content output device is arranged to use the key to decrypt the content. The content output device may further be arranged to output the decrypted content. The cryptographic key may be a shared key. The link layer encryption may be specific to applications operating on the content output device.

The received content may be DRM protected by a DRM scheme chosen by a content provider (such as an application layer DRM scheme). The content receiver may be arranged to decrypt and/or decode received content in accordance with the DRM scheme. The content receiver may thus act as an application DRM to link layer DRM converter. a

The decrypted content can be output using an application running on the content output device. The outputting of the content may not use any further decryption of the decrypted content, at least not any further decryption associated with a DRM protocol. The content output device may thus be arranged to not apply any decryption in protocol layers above the link layer.

The content receiver may comprise means for encoding the content prior to encrypting it. The encoding may be such as to enforce requirements of a DRM policy that may have been defined by an original provider or an owner of the content. The content output device may comprise a decoder arranged to decode the decrypted received content prior to the outputting of the content.

The content receiver and/or the content output device may obtain the key by sending a message or messages to a key issuing authority, which may provide the requested key, if it is determined that the content output device and the content receiver are entitled to receive such a key. The key issuing authority may be the content provider or a trusted third party that has been authorised by the content provider to bind DRM content with a session key.

The link layer encrypted content can be transmitted to the content output device via a wireless link, such as a WiFi link. Wireless communication links can employ link layer encryption such as the IEEE 802.1 Ii security protocol for WiFi. In another example, the link layer encrypted content can be transmitted to the content output device via a Femtocell base station and the link layer encryption can be according to the 3GPP standard. It will, however, be appreciated that the data content can be transmitted from the content receiver and the content output device over any possible wireless communication link employing link layer security.

The system can further comprise a content provider arranged to send the content to the content receiver. The content receiver may send the message requesting the key following receipt of the content. The message may be a message requesting a key specifically for the received content, so that a secure connection for transmission of the content to the content output device can be established. It will be appreciated, however, that a request for a key, even for a content specific key, can be made before the content has been received. It is, for example, envisaged that the key can be requested in the absence of received content, for example following an receipt of an indication that receipt of the content is desired. If, for example, a user provides an indication at the content output device that specific content is to be acquired from a content provider, then the content output device may forward the request to the content receiver for further forwarding to a content provider. The content output device may then base a message requesting a key on the information received from the content output device.

The key may either be issued by the content provider or by a third party that is trusted by the content provider and/or certified by the content provider as an entity entitled to issue requested keys and send any such keys to requesting content receivers.

The keys may be transmitted to the content receiver and/or to the content output device in a known secure manner, so as to prevent interception of the key by third parties and subsequent man in the middle attacks on the transmission of the link layer encrypted content between the content receiver to the content output device.

The system may be an lP\/T system.

The content receiver may be considered to be a Link Layer DRM Gateway (LLDG) logical entity. This entity may be a software component / add-on within an existing Gateway / Set Top Box (STB) or it could be a standalone hardware/firmware/software device.

According to another embodiment there is provided an apparatus comprising a receiver for receiving data content. The apparatus is arranged to use a key for link layer encryption of received content. The apparatus may further comprise a transmitter arranged to transmit a message requesting the key and be arranged to use a received key only for encryption of content for which the key has been requested.

The apparatus may further be arranged to decrypt received content in accordance with digital rights management requirement defined by a provider of the contents prior to link layer encrypting the content. The apparatus therefore allows the decrypting of the received contents using the decryption method/algorithm prescribed by the content provider. These requirements may be computationally expensive. The thus decrypted content is then re-encrypted at the link layer level using the key. The apparatus/system and the method operated within it may thus be considered a cross layer digital rights management apparatus/system/method.

The apparatus may be a television set top box, a digital rights management gateway, a laptop, an IPTV system, a Femtocell, or a stand alone unit suitable or arranged for connection to any of the aforementioned devices.

The system may be based on an originally terminal centric system in which the content receiver of the embodiment directly receives the content from a content provider via a transmission medium, such as a network/the internet. In this case the content receiver may be arranged to decrypt the received content in accordance with the decryption requirements of the DRM system chosen/mandated by the content provider. The link layer re-encrypted content can then be transmitted onwards to the content output device via the secure connection created by the use of the key.

The system may be based on an originally gateway centric system comprising a gateway arranged to receive DRM protected content and to perform DRM processing of the DRM content before the content is transmitted further. In this case the gateway may provided DRM processing mandated by the content provider and transmit the content on to the content receiver in a form intended, in known gateway centric systems, to be more suitable for decryption by a known content output device. The content receiver may then perform decryption and decoding of the content format received from the gateway and subsequent re-encoding at link layer level.

According to another embodiment there is provided a content output apparatus arranged to send a message requesting a key and to use a key received following the sending of the request for link layer encryption of received content.

The content output apparatus may not use any further decryption method/algorithm in protocol layers above the link layer. The apparatus may use an application for outputting the received content.

According to another embodiment there is provided a method of digital rights management. The method comprises receiving at a content receiver a digital content that is subject to a digital right management requirement and link layer encoding the digital content using a key. The link layer encoded content is then transmitted to a content output device.

The method may further comprise sending a request for the key and receiving the key following the request at the content receiver and at the output device and using the key to link layer decrypt the link layer encrypted content. The link layer encrypted content may then be output by the content output device. The method may apply no further decryption (e.g. in protocol layers above the link layer) following the link layer decryption.

Figure 1 shows the architecture of a standard home/entertainment/internet protocol television (IPTV) system with the addition of a Linked Layer DRM Gateway (LLDG) logical component 106. This architecture consists of a Content Provider 101, delivering content to either the second TV 105 through gateway 102, or to a first TV 104 through the Gateway 102 and through a set top box 103.

DRM solutions in known architectures (excluding the LLDG 106 shown in Figure 1) can either be implemented exclusively within the first and/or second televisions 104 and 105 (terminal-centric approach) or can be implemented partially within the first and/or second televisions 104 and 105 and partially within the Gateway 102 or set top box 103 (gateway-centric approach). In the terminal-centric approach the Gateway/set top box acts as a standard router that routes (signal paths 114 and 118 in Figure 1 respectively) control/DRM initialisation messages exchanged between the first and/or second televisions 104 and 105 and the content provider 101 and then routes DRM-protected content received from the content provider 101 via signal path 111 to the first and second televisions 104 and 105 respectively. In a known gateway-centric approach the Gateway 102/set top box 103 has a more active role in that it is responsible for initialising the DRM session with the content provider 101 and managing the protected content received from the content provider via signal path 111 before forwarding it to the first and second televisions 104 and 105 respectively. In this case, the gateway 102/set top box 104 needs to decrypt and re-encrypt the DRM-protected content. In contrast to the embodiment the re-encrypting is performed in a layer that is higher in the protocol stack than the link layer, requiring computationally expensive decrypting in the television in a layer that is again above the link layer.

* The LLDG 106 can be either a separate device, or collocated with the set top box 103 and/or the gateway 102. The function of the LLDG 106 is to convert standard DRM-protected content to Link Layer DRM (LLD)-protected content, thereby enabling forwarding of DRM material from the LLDG to a television that supports linked layer DRM. The structural and operational specification of LLD and the advantages of converting DRM to LLD will become evident in the following. A television of this type avoids the overheads associated with having to decrypt standard DRM protected content.

To enable the LLDG 106 to securely communicate with the first 104 and/or the second 105 television, the LLDG 106 needs to setup a protected link with the first 104 and/or the second 105 television. Such a link can either be set up directly (as indicated by signal paths 128/129 and 1231124) or through the Gateway 102 and/or set to box 102 (as indicated by signal paths 125/126, 121/122).

In order to setup a protected LLD-session between the first 104 and/or the second 105 televisions and the LLDG 106, the first 104 and second 105 televisions as well as the LLDG 106 communicate (through the gateway 102) with a Key Distribution Centre (KDC) 107. The KDC 107 should then be able to get authorisation from the contents provider 101 (indicated by signal paths 131/132) in order to send a secure LLD session key back to the LLDG 106 and to the first 104 and/or second 105 televisions. The secure LLD session key enables the LLDG 106 to securely forward LLD-protected content to the first 104 and/or second 105 televisions.

Figure 2 shows an architecture of the LLDG 106 and of the LLD components (indicated by the label LLD-TV) of a LLD television. LLDG consists of a Terminal-centric DRM client 201 (also labelled T-DRM in Figure 2), which communicates directly with the content provider 101 in order to setup (of behalf of the TV) a DRM-protected session. The DRM content that arrives at the (properly licensed and authorised) LLDG is managed by the T-DRM 201, which then deciphers the DRM-protected content. In order to send the deciphered content to the TV using LLD, LLDG acquires a secure LLD Session Key (LLD-SK) from the key distribution centre 107. This is controlled by the LLD Key Management entity 202. The LLD Key Management entity 202 is responsible for binding the DRM-protected session with a LLD session key request that is sent to key distribution centre 107. Before sending back the LLD session key the key distribution centre obtains authorisation from the contents provider.

Similarly to the LLDG, the LLD television also needs to implement a LLD key management component 212, as the LLD television needs to separately communicate with the key distribution centre and securely acquire the same LLD session key. Using the LLD session key, the LLDG can then setup a secure link with the LLD television.

The deciphered content can then be encoded and encrypted by the LLDG with the use of an LLD Encoding/Encryption component 203. During the encoding, LLD restrictions can be added to the content, as allowed by the content provider and the original DRM-protected content. The encoded content is then encrypted using standard Link Layer Security components with the LLD session key.

The LLD Encoding/Encryption component 203 can, for example, use the standard 802.11 i encryption if the television and LLDG communicate over a WiFi link, or a standard 3GPP encryption if the television and LLDG are communicating within a Femto-CelI. It is also envisaged that standard transport layer security or secure socket layer encryption can be used for DRM session specific encoding. The LLD-protected content is decrypted at the television by the LLD decryption component 213 using the same encryption/decryption standard used by the LLD Encoding/Encryption component 2O3oftheLL.DG.

A LLD Access Control component 211 (LLD-AC) is provided to enable the television to decode the LLD content, implementing any restrictions that may have been mandated by the content provider.

It will be appreciated that, on account of the presence of the terminal centric DRM client 201, the LLDG 106 is most suitable for use in a terminal centric DRM system. A gateway centric LLDG comprises a gateway centric DRM client (G.DRM) instead of the T.DRM 201 shown in Figure 2. Alternatively, a LLDG could be configured to comprise both terminal centric and gateway centric DRM clients, for universal use in either terminal centric or gateway centric IPTV systems.

Figures 3 and 4 show known DRM terminal centric and gateway centric DRM systems. Figure 3 depicts a terminal-centric DRM system. In this system all DRM session setup management and decipherment functionality takes place within the T-DRM Client component of the television.

Figure 4 depicts a gateway-centric DRM solution in which DRM session setup and management functionality takes place in the T-DRM client of the Gateway on behalf of the television. The gateway is responsible for continuously protecting the content to prevent unauthorised access to content transmitted from the gateway to the television. The gateway implements the required level of protection using the shown G-DRM server component. The television has to decipher the information received from the gateway using a matching G-DRM client.

Figures 5 and 6 show embodiments providing a terminal-centric and a gateway-centric DRM solution including a link layer DRM arrangement using a LLDG.

In the terminal centric approach shown in Figure 5, the LLDG (in this case referred to as T-LLDG, given that the embodiment is based on a terminal centric architecture) implement a T-DRM Client that is arranged to setup and manage a DRM session with the contents provider. The T-DRM client also decrypts the DRM content.

The T-LLDG also comprises a link layer DRM server (LLD) that can encode and encrypt the content in a manner that meets the requirements of the content provider and using the LLD session key discussed above. A corresponding link layer DRM client LLD is provided in the television for decrypting and decoding the content provided by the T-LLDG. The LLDG thus implements a cross-layer DRM system that converts content protected by an application layer DRM scheme into secure link layer encrypted transmission.

Figure 6 show a gateway centric architecture implementing link layer ORM management. The gateway in the Figure 6 embodiment is the same as the known gateway shown in Figure 4 and comprises a (gateway) G-DRM server. Instead of requiring the television to process the signal generated by the G-DRM server, the Figure 6 architecture provides a G-DRM client as part of the LLDG (referred to as C-LLDG in Figure 6, as the Figure 6 architecture relates to a gateway centric approach).

The G-DRM Client is arranged to receive and decrypt ORM content from the G-DRM Server of the Gateway. The G-LLDG moreover comprises a linked layer DRM component LLD. This component LLD re-protects the DRM content that is to be transmitted to the television, as previously described and shown in Figure 2.

It will be appreciated that Figure 5 and 6 related to architectures that added a separate LLDG to known architectures. Figure 7 shows an embodiment in which the components of the LLDG and of the gateway are combined in one device Turning now to Figure 8, the operation following receipt of a signal at the television is illustrated. The signal is initially received, for example wirelessly, and the LLD component of the television determines if the received content has been encrypted using a (previously acquired) link layer DRM session key that is bound to specific DRM content or a standard encryption key. Such a standard encryption key may, for example, be an encryption key a user may use within a WiFi home network. This is implemented with a proprietary mechanism that determines if a block of data has been encrypted with a particular key. This proprietary mechanism may be implemented with a simple test-failure procedure. For example, if a block of data is decrypted successfully with a standard encryption key, then it has been encrypted by one, as so on. If no session key match is found, the TV ignores the signal. If LLD-TV establishes that the Signal contains LLD-protected content it will then decrypt it and send it to LLD application client of the television.

Known protocols or solutions can be used for securely distributing and managing LLD sessions keys between LLDG and LLD television. Trusted Platform Modules (TPM; see for example http://www.trustedcomputinggroup.org/resources/tpm_main.....specificatiOn) can, for example, be used to establish secure end to end communications between a hardware component (such as the LLDG and LLD television) and the key distribution centre KDC, ensuring confidentiality, integrity and mutual authentication. Operational segments from known DRM protocols can be used for the same purpose, as used already for key management purposes in T-DRM Client and T-DRM Server components (e.g. within the Gateway and the CP). For example consider the key management of the Marlin DRM scheme (http://www.marlin-cornmunity.corn/technology).

Other known security protocols can also be used for securely binding an LLD-session key request to specific DRM-protected content provided by the content provider and following the secure exchange of messages between the key distribution centre and the content provider logical entities.

Turning now to Figure 9, this figure depicts the message flow in an embodiment. The session starts with the television 905 sending a secure content request to content provider 901 through the gateway 903. The content provider 901 performs standard TV/GW/LLDG terminal, licence and subscription authentication and authorises (if applicable) the content for sending to the television 905. The content provider 901 protects the content with a known DRM technique before forwarding it to the gateway 903. In a known system the T-DRM content (or the G-DRM equivalent in a gateway-centric deployment) would be sent to the television. Using the LLD system of the embodiment, T-DRM (or G-DRM) is converted to LLD. The T-DRM content arriving at the gateway 903 is then handled by the LLDG 904 that implements a full T-DRM client. LLDG request the television 905 to request the issue of a LLD session key, or its renewal if applicable. Both the LLDG and the television send a secure LLD session key request message to the key distributions centre 902 though the gateway 903.

LLDG binds the request with a unique content provider content ID. The request is thus bound to particular DRM content. The key distribution centre 902 authenticates the origin of the messages and further sends a LLD request to the content provider 901 that will allow the key distribution centre to issue an authorised LLD session key for the DRM-protected content. After this authorisation, if applicable, the key distribution centre issues the LLD session key and securely sends it to LLDG 904 and the television 905 through the gateway 903. The LLDG 904 can now convert DRM to LLD and securely send it, using the LLD session key to the LLD television 905.

A link layer decryption is computationally less expensive than application layer decryption end terminal complexity is reduced considerably. The embodiment is thus particularly suited for contents output devices that do not comprise large amounts of computational power, such as devices in residential/home networks. The embodiment is moreover suitable for small hand held/battery operated devices.

It will be appreciated from the above that the embodiment merges DRM with link layer encryption. The embodiment thus provides a secure end to end connection between a contents provider and the contents output apparatus. Transmission of data to the content receiver is hereby secured by the DRM system chosen by the content provider. Data transmission from the content receiver to the content output device is secured by the link layer encryption method of the embodiment.

On a similar note, operational details of LLD application client functionality may use a variety of known DRM techniques. For example, a simple DRM header encoding operational restrictions and permissions could suffice for enforcing digitally managed rights within a compliant LLD application client.

From the above it will be clear to the person skilled in the art that the embodiment can fulfil the following DRM security requirements: * Confidentiality of the Link Layer DRM Session: The decrypted DRM content should only be available within the TV. The LLD decryption key is only shared between LLDG and TV, in the same way the ORM decryption key should only be shared between the CP and the Gateway/STB or TV. The user or other equipment should never have access to any of these keys.

* Authorisation of LLD Terminal: The DRM access control restrictions / permissions are maintained.

* Integrity of conversion: The use of a confidential LLD key is bound with a certain DRM content and is securely issued by a trusted party in collaboration with the content provider * LLD Terminal and Licence Authentication: The TV and LLDG need to be authenticated by the trusted party that issues LLD keys, the same way the TV and Gateway need to be authenticated by the CP in a DRM system. Techniques for such authentication are known to the person skilled in the art.

It will be appreciated that, while the above embodiments relate to the transfer of contents to a television or to televisions, the embodiments are not limited to transfer of contents suitable for output using a television. It will be appreciated that the embodiments instead encompass the transfer of any type of content that may be protected by digital rights management systems and apparatus and devices for transferring such content to an output device, White certain embodiments have been described, the embodiments have been presented by way of example only, an area not intended to limit the scope of the inventions. Indeed, the novel methods! apparatus and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the inventions.

Claims

CLAIMS: 1. A system comprising a content receiver and a content output device, the content receiver and a content output device arranged to use cryptographic keys for establishing a secure connection between the content receiver and the content output device, wherein the content receiver is arranged to use the key for DRM specific link layer encrypting received content and to transmit the link layer encrypted content to the content output device and wherein the content output device is arranged to use the key to decrypt the content.
2. A system according to claim 1, wherein the link layer encrypted content is transmitted to the content output device via a WiFi link and wherein the link layer encryption is according to IEEE 802.lli.
3. A system according to claim 1, wherein the link layer encrypted content is transmitted to the content output device via a Femtocell base station and wherein the link layer encryption is according to the 3GPP standard.
4. A system according to claim 1, 2 or 3, wherein the system is an 1PTV system or a DRM system.
5. An apparatus comprising a receiver for receiving data content and a transmitter for transmitting a message requesting a key, the apparatus arranged to use a key received following a request for link layer encryption of received content.
6. An apparatus according to Claim 5, further arranged to use a received key only for encryption of content for which the key has been requested.
7. An apparatus according to Claim 4 or 5, further arranged to decrypt received content in accordance with digital rights management requirement defined by a provider of the contents prior to the said link layer encrypting of the content.
8. An apparatus according to any of claims 4 to 6, wherein the apparatus is a set top box, an IPTV gateway, a laptop, a PC, a mobile device or a Femtocell or Picocell base station.
9. A content output apparatus arranged to send a message requesting a key and to use a key received following the sending of the request for link layer encryption of received content.
10. An apparatus according to claim 9, wherein the apparatus is a television.
11. An apparatus according to claim 9 or 10, further arranged to distinguish signals that have been link layer encrypted using a predetermined link layer encryption key from other signals and to apply link layer decryption only to link layer encrypted signals.
12. A method of digital rights management comprising: receiving at a content receiver a digital content that is subject to a digital right management requirement; link layer encrypting the content using a key; and transmitting the link layer encoded content to an output device.
13. A method according to claim 12, further comprising sending a request for the key and receiving the key following the request at the content receiver and at the output device and using the key to link layer decrypt the link layer encrypted content in the output device.
14. A method according to claim 8 or 9, further comprising DRM processing of the received digital content prior to the link layer encrypting.
15. A method to claim 13 or 14, further comprising securely transmitting the key from a key distributor to the content receiver and/or to the content output device.