Title of Invention

A METHOD OF FACILITATING ACCESS BY A USER TERMINAL TO BROADCAST AND/OR MULICAST DATA

Abstract

A method of facilitating access by a user terminal to broadcast and/or multicast data which is encrypted and sent to the user terminal from a communication network, the method comprising: sending an encrypted service key from an access server of the communication network to the user terminal, and passing the encrypted service key to a secure module of the user terminal, the secure module having access to a decryption key for decrypting the encrypted service key but this decryption key being inaccessible to other functions of the user terminal; generating an acknowledgement of receipt of the service key at said secure module, and sending the acknowledgement from the user equipment to the access server; authenticating the receipt at the access server and sending a return acknowledgement from the access server to the user terminal, and passing the return acknowledgement to the secure module; and authenticating the return acknowledgement at the secure module, and subsequently making the decrypted service key available to the user terminal, the service key making possible directly or indirectly the decryption of broadcast and/or multicast data

Full Text

Field of the Invention The present invention relates to a key delivery method and apparatus in a communications system, and more particularly to a method and apparatus for delivering service keys associated with a multimedia broadcast/multicast system. Background to the Invention Today, there are many applications in which data is broadcast or multicast to a group of individual receivers via some communication channel. Terrestrial and satellite television and radio transmissions are obvious examples. In the Internet, streaming video and audio signals can be broadcast or multicast to individual Internet terminals using the Internet Protocol (IP). In the very near future, technologies such as those defined by 3GPP will allow the broadcasting/multicasting of streaming IP data to mobile handsets. Subscribers will be able to listen to music and watch concerts and football games via their mobile handsets. For a number of reasons, it is often necessary to be able to send multicast signals (it will be appreciated that reference here to "multicast" is only by way of example and that the following discussion applies equally to broadcast signals) in such a way that only authorised receivers can make use of the signals. The nature of the material may make this necessary, for example to prevent children from viewing adult content. In the case of a subscription service, it may be necessary to prevent receivers who have not paid for a service from using a received signal. 3GPP is currently developing a multicast system called MBMS (Multimedia Broadcast/Multicast System) in which a service key (MSK) is distributed from a BM-SC (Broadcast/Multicast Service Center) to UEs (User Equipments) that have joined a specific service. The MUK is a key shared between the BM-SC and a specific UICC, i.e., each UICC has its own MUK. The UEs use this service key to access the multicast data by decrypting subsequently sent traffic encryption keys (MTK) encrypted with the MSK. The MBMS system requires that the UE has a trusted module (i.e. trusted by the BM-SC) where the MSK is stored. The communication between the trusted module (here called Universal 1C Card or UICC) and the BM-SC is protected with a key called MUK (MBMS User Key). The mobile equipment (ME) does not know the MUK nor the MSK, but is provided with the MTK following receipt and decryption by the UICC. One of the charging models for 3GPP is that the users will be charged for provision of this MSK. In order to provide accurate and fair charging it is important that the service key is delivered reliably to the UE (i.e. the UE needs to acknowledge the reception of the MSK), otherwise it could happen that a UE might be out of coverage at the time of service key delivery and would not get the service key, yet would be charged for the service. MBMS therefore allows for the possibility that the UICC return a service key reception acknowledgement to the BM-SC upon successful receipt by the UICC of the MSK. It is however possible for a malicious UE implementation to refrain from sending the service key reception acknowledgement to the BM-SC in order to avoid being charged. Not even the protected nature of communications between the UICC and BM-SC (achieved using the MUK) guarantees that the reception acknowledgement gets through to the BM-SC since the acknowledgement must travel via the ME that could be malicious and drop it. Statement of the Invention It is proposed here to solve this potential problem by preventing use of the MSK by the UE until a further, protected, release message has been received by the UICC from the network. This release message is only sent after the network has received the key acknowledgement message from the UE. This provides a three-way handshake. According to a first aspect of the present invention there is provided a method of facilitating access by a user terminal to broadcast and/or multicast data which is encrypted and sent to the user terminal from a communication network, the method comprising: sending an encrypted service key from an access server of the communication network to the user terminal, and passing the encrypted service key to a secure module of the user terminal, the secure module having access to a decryption key for decrypting the encrypted service key but this decryption key being inaccessible to other functions of the user terminal; generating an acknowledgement of receipt of the service key at said secure module, and sending the acknowledgement from the user equipment to the access server; authenticating the receipt at the access server and sending a return acknowledgement from the access server to the user terminal, and passing the return acknowledgement to the secure module; and authenticating the return acknowledgement at the secure module, and subsequently making the decrypted service key available to the user terminal, the service key making possible directly or indirectly the decryption of broadcast and/or multicast data. The decrypted service key may be made available to the user terminal directly, or by allowing the secure module to process actions requiring use of the decrypted key, on behalf of the user terminal. ^ In certain embodiments of the present invention, the service key sent from the access server to the user terminal is encrypted with a symmetric encryption/decryption key known to the secure module and the access server. The acknowledgement of receipt and the return receipt may be signed with the shared symmetric key. In other embodiments of the invention, the service key is encrypted with a public key of a public-private key pair, the private key being held by said secure module. In certain embodiments of the invention, receipt and authentication of the acknowledgement of receipt at the access server triggers a charging of the user terminal or associated user for access to the service. The service key may be made available to the user equipment immediately following receipt and authentication of the return acknowledgement. Alternatively, the service key may be made available at a later time, e.g. upon receipt by the user terminal of a traffic encryption key protected using the session key. According to a second aspect of the present invention there is provided a user terminal comprising: a secure module having access to a decryption key, the decryption key being inaccessible to other functions of the user terminal; means for receiving an encrypted service key from an access server of the communication network, and for passing the encrypted service key to the secure module; means within said secure module for generating an acknowledgement of receipt of the service key; means for sending the acknowledgement from the user equipment to the access server; means for receiving a return acknowledgement from the access server, and for passing the return acknowledgement to the secure module; and means within the secure module for authenticating the return acknowledgement, and for making the decrypted service key available to the user terminal. According to a third aspect of the present invention there is provided a Universal 1C card for use with a user terminal, the Universal 1C card comprising: a memory for storing a decryption key, the decryption key being inaccessible to other functions of the user terminal; means for receiving an encrypted service key from an access server of a communication network; means for generating an acknowledgement of receipt of the service key; means passing the receipt to the user terminal for sending to the access server; means for receiving a return acknowledgement from the access server; and means for authenticating the return acknowledgement, and for making the decrypted service key available to the user terminal. According to a fourth aspect of the present invention there is provided an access server for facilitating access by a user terminal to broadcast and/or multicast data which is encrypted and sent to the user terminal from a communication network, the method comprising: means for sending an encrypted service key to the user terminal; means for receiving an acknowledgement of receipt of the service key, from the user terminal; and means for authenticating the receipt and for sending a return acknowledgement to the user terminal. Brief Description of the Drawings Figure 1 illustrates a signalling exchange between a UICC, a mobile node, and a BM-SC associated with a secure service key delivery procedure; and Figure 1 illustrates a a high-level system architecture of a communications network according to an embodiment of the invention. Detailed Description of a Preferred Embodiment This innovation described here is based on the 3GPP MBMS standard TS 33.246 (v6.1.0). That standard specifies the use of particular protocols, e.g., Multimedia Internet Keying (MIKEY), for key management messages, but the solution presented here is not limited to only those protocols. The system includes three relevant components. The ME (which is not trusted by the BM-SC), the UICC (trusted by BM-SC) and the BM-SC. The UICC typically resides inside the ME, but could be external to the ME. Although the terminology is not yet standardised, the UICC may implement the functionality currently referred to as MBMS key generation and validation function (MGV-F) and MBMS key generation and validation storage (MGV-S). The procedure has the following steps, as illustrated in Figure 1: 1) The UICC and BM-SC have established a shared secret MUK (MBMS User Key), e.g., using GBA (Generic Bootstrapping Architecture) procedures. The MUK is not known to the ME. 2) The BM-SC sends a MIKEY message to the ME which relays this message to the UICC. The MIKEY message is protected with the MUK, and includes a MBMS Service Key (MSK) with relevant identifiers and a valid lifetime for the MSK. Note that the ME cannot access the MSK key in the message since it does not possess the MUK. 3) The UICC receives the MIKEY message and checks it's authenticity using the MUK. If the check is successful, the UICC decrypts the message and stores the MSK. The UICC prepares an MSK verification message, protects it with the MUK, and sends the message to the BM-SC via ME. The UICC sets the state of the MSK to "INACTIVE" until it has received a response from BM- SC. 4) The BM-SC receives the MIKEY MSK verification message (protected with the MUK) from the UICC, and verifies it using the MUK. (The BM-SC potentially generates a charging record for this ME.) The BM-SC then prepares an acknowledgement response message, protects it with MUK, and sends it to the UICC. 5) When the UICC receives the MIKEY acknowledgement response, it checks the authenticity of the message with the MUK, and if the check is successful, the state of the MSK is set to "ACTIVE". 6) Later the ME receives a Traffic Key (MTK) message (encrypted with the MSK) from multicast transmission. The ME needs this MTK key to decrypt multicast data. The ME requests the UICC to decrypt the MTK with MSK. 7) The UICC checks if the MSK is in active state (i.e. the UE has been charged for the MSK) and if the lifetime has not yet expired. If the checks are successful, the UICC gives the decrypted MTK key to the ME. Otherwise the UICC responds with an error. If the BM-SC does not receive the message in step 4) within a reasonable time frame, it can return to step 2) and resend the message. This loop can be repeated a suitable number of times to add additional reliability to the protocol. It is generally true to say that if two messages have been successfully exchanged between the Mobile Equipment and the BM-SC, it is probable that the third messages will also be successfully delivered. (Typically, a point-to-point radio link will deliver packets reliably (albeit at a lower bit-rate) even if the radio conditions are bad.) Thus, the additionally third message in the handshake procedure introduced here is unlikely to detract from the reliability of the procedure to any significant extent, from the point of view of the Mobile Equipment. Of course, from the point of view of the service provider, reliability in terms of ensuring that the key has indeed been made available to the Mobile Equipment and that the subscriber should be charged, is greatly increased. Figure 2 illustrates a high-level system architecture of a communications network according to an embodiment of the invention. Shown in the Figure 2 is a plurality of user terminal 100 and at least one access server 300. The user terminal 100 may have a secure module 102. The secure module 102 may have the access to a decryption key that is being inaccessible to other functions of the user terminal. The user terminal 100 may have means 104 for receiving an encrypted service key from the access server 300, and passing the encrypted service key to the secure module 102. The secure module 102 may have means 106 for generating an acknowledgement of receipt of the service key. According to an embodiment, the user terminal 100 may further have means 108 for sending the acknowledgement to the access server 300 and means 110 for receiving a return acknowledgement from the access server 300. The received return acknowledgement is forwarded to the secure module 102. The secure module 102 may further have means 112 for authenticating the return acknowledgement, and for making the decrypted service key available to the user terminal. According to another embodiment, the secure module 102 may be a Universal IC Card. The Universal IC Card 102 may have a memory 202 for storing the decryption key and means 204 for receiving an encrypted service key from the access server 300. The Universal IC Card 102 may further have means 106 for generating an acknowledgement of receipt of the service key and passing the receipt to the user terminal 100 for sending to the access server 300. The Universal IC Card 102 may further have means 206 for receiving a return acknowledgement from the access server 300 and means 112 for authenticating the return acknowledgement so as to make the decrypted service key available to the user terminal 100. According to yet another embodiment the access server 300 may have means 302 for sending an encrypted service key to the user terminal 100 and means 304 for receiving an acknowledgement of receipt of the service key, from the user terminal 100. The access server 300 may further have means 306 for authenticating the receipt and sending a return acknowledgement to the user terminal 100. The description above illustrates the invention in the context of 3GPP MBMS. The invention could be generalized to other multicast systems that have a trusted module in the client and where it is necessary to ensure that the network receives the reception acknowledgement of the delivered key. For example, other possible applicable multicast systems might be 3GPP2 BCMCS, DVB-H IP DC and OMA BCAST. Note that the solution may require standardization efforts in the standardization bodies. We claim: 1. A method of facilitating access by a user terminal to broadcast and/or multicast data which is encrypted and sent to the user terminal from a communication network, the method comprising: sending an encrypted service key from an access server of the communication network to the user terminal, and passing the encrypted service key to a secure module of the user terminal, the secure module having access to a decryption key for decrypting the encrypted service key but this decryption key being inaccessible to other functions of the user terminal; characterized by generating an acknowledgement of receipt of the service key at said secure module, and sending the acknowledgement from the user equipment to the access server; authenticating the receipt at the access server and sending a return acknowledgement from the access server to the user terminal, and passing the return acknowledgement to the secure module; and authenticating the return acknowledgement at the secure module, and subsequently making the decrypted service key available to the user terminal, the service key making possible directly or indirectly the decryption of broadcast and/or multicast data. 2. A method as claimed in claim 1, the service key sent from the access server to the user terminal being encrypted with a symmetric encryption/decryption key known to the secure module and the access server, the acknowledgement of receipt and the return receipt being authenticated using the shared symmetric key. 3. A method as claimed in claim 1 or 2, wherein receipt and authentication of the acknowledgement of receipt at the access server triggers a charging of the user terminal or associated user for access to the service. 4. A method as claimed in any one of the preceding claims, wherein the service key is made available to the user equipment immediately following receipt and authentication of the return acknowledgement, or at a later time. 5. A user terminal (100) comprising: a secure module (102) having access to a decryption key, the decryption key being inaccessible to other functions of the user terminal (100); means (104) for receiving an encrypted service key from an access server (300) of the communication network, and for passing the encrypted service key to the secure module (102);. means (106) within said secure module (102) for generating an acknowledgement of receipt of the service key; means (108) for sending the acknowledgement from the user equipment to the access server (300); means (110) for receiving a return acknowledgement from the access server (300), and for passing the return acknowledgement to the secure module (102); and means (112) within the secure module (102) for authenticating the return acknowledgement, and for making the decrypted service key available to the user terminal. 6. A Universal IC Card (102) for use with a user terminal (100), the Universal IC card comprising: a memory (202) for storing a decryption key, the decryption key being inaccessible to other functions of the user terminal 100; means (204) for receiving an encrypted service key from an access server (300) of a communication network; means (106) for generating an acknowledgement of receipt of the service key and passing the receipt to the user terminal for sending to the access server (300); means (206) for receiving a return acknowledgement from the access server; and means (112) for authenticating the return acknowledgement, and for making the decrypted service key available to the user terminal. 7. An access server (300) for facilitating access by a user terminal to broadcast and/or multicast data which is encrypted and sent to the user terminal (100) from a communication network, the method comprising: means (302) for sending an encrypted service key to the user terminal (100); means (304) for receiving an acknowledgement of receipt of the service key, from the user terminal (100); and means (306) for authenticating the receipt and for sending a return acknowledgement to the user terminal (100).

Documents:

4266-DELNP-2007-Abstract-(03-04-2012).pdf

4266-delnp-2007-abstract.pdf

4266-DELNP-2007-Claims-(03-04-2012).pdf

4266-delnp-2007-Claims-(22-07-2013).pdf

4266-delnp-2007-claims.pdf

4266-DELNP-2007-Correspondence Others-(03-04-2012)..pdf

4266-DELNP-2007-Correspondence Others-(03-04-2012).pdf

4266-delnp-2007-Correspondence Others-(05-07-2012).pdf

4266-delnp-2007-Correspondence Others-(16-07-2012).pdf

4266-delnp-2007-correspondence others.pdf

4266-delnp-2007-correspondence-others 1.pdf

4266-delnp-2007-Correspondence-Others-(22-07-2013).pdf

4266-DELNP-2007-Description (Complete)-(03-04-2012).pdf

4266-delnp-2007-description (complete).pdf

4266-DELNP-2007-Drawings-(03-04-2012).pdf

4266-delnp-2007-drawings.pdf

4266-DELNP-2007-Form-1-(03-04-2012).pdf

4266-delnp-2007-form-1.pdf

4266-DELNP-2007-Form-13-(03-04-2012).pdf

4266-delnp-2007-form-18.pdf

4266-DELNP-2007-Form-2-(03-04-2012).pdf

4266-delnp-2007-form-2.pdf

4266-delnp-2007-form-26.pdf

4266-DELNP-2007-Form-3-(03-04-2012).pdf

4266-delnp-2007-Form-3-(05-07-2012).pdf

4266-delnp-2007-Form-3-(16-07-2012).pdf

4266-delnp-2007-form-3.pdf

4266-delnp-2007-form-5.pdf

4266-DELNP-2007-GPA-(03-04-2012).pdf

4266-delnp-2007-GPA-(22-07-2013).pdf

4266-delnp-2007-pct-210.pdf

4266-delnp-2007-pct-304.pdf

4266-delnp-2007-pct-409.pdf

4266-delnp-2007-pct-416.pdf

abstract.jpg