Encryption key distribution method in mobile broadcasting system and system for the same

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to a mobile broadcasting system, and more particularly to a traffic encryption key distribution method for a mobile broadcast service, which is applied to an OMA BCAST Service Protection and Content Protection architecture in Digital Rights Management (hereinafter "DRM profile"), in an Open Mobile Alliance Broadcast (OMA BCAST) service system, and a system for the same.

2. Description of the Related Art

In the mobile communication market there is constant demand for producing a new service through the re-combination or integration of existing technology. Today developing communication and broadcast technologyin conventional broadcasting systems or mobile communication systems is at the stage of providing a broadcast service through a mobile terminal (hereinafter "terminal"), such as a mobile phone, a Personal Digital Assistant (PDA), and the like. The merger of mobile communication services and Internet Protocol (IP) is at the forefront of development of next generation mobile communication technology, combined potential and actual market demand as described above, rapidly increasing user requirements for a multimedia service, service provider strategy intending to provide a new service, such as a broadcast service, in addition to an existing voice service, and interests of Information Technology (IT) companies that can meet the market demand and strengthen their mobile communication businesses.

Meanwhile, the Open Mobile Alliance (OMA), a standardization group for applications of terminals, has been conducting research on standards for interlocking between individual mobile solutions. The main role of OMA is determining various application standards for games for mobile communication, Internet services, and the like. Particularly, an OMA Browser and Content Mobile Broadcast Sub Working Group (OMA BCAST), one of the working groups of OMA, is conducting research on technology for providing a broadcast service by using a terminal. Hereinafter, a broadcasting system (hereinafter "mobile broadcasting system") discussed by the OMA BCAST working group will be briefly described.

<figref idref="f0001">FIG. 1</figref> is a block diagram illustrating the network architecture of a general mobile broadcasting system.

In <figref idref="f0001">FIG. 1</figref>, a Content Creator (CC) 10 is a BCAST service content provider, wherein the BCAST service may include the conventional audio/video broadcast service, file download service (e.g. music file or data file download service), and the like. A BCAST Service Application unit (BSA) 20 has a function of receiving data from the Content Creator 10, handling the received data in the form appropriate for a BCAST network shown in <figref idref="f0001">FIG. 1</figref>, and generating BCAST service data. In addition, the BCAST Service Application unit 20 has a function of generating standardized metadata necessary for a portable broadcast guide.

In <figref idref="f0001">FIG. 1</figref>, a BCAST Service Distribution/Adaptation unit (BSD/A) 30 has a function of setting up a bearer to be used for transmitting the BCAST service data provided from the BSA 20, a function of determining a transmission schedule for the BCAST service, and a function of generating a portable broadcast guide. A BCAST Subscription Management unit (BSM) 40 manages subscriber subscription information for reception of BCAST service, information on provision of the BCAST service, and device information on a terminal for receiving the BCAST service.

A terminal 50, which is capable of receiving BCAST service, has a function of being able to access a cellular network according to the capability thereof. A Broadcast network 60 is a network for transmitting BCAST service, such as a Digital Video Broadcasting - Handheld (DVB-H), a Third Generation Partnership Project Multimedia Broadcast and Multicast Service (3GPP MBMS), Third Generation Partnership Project 2 Broadcast and Multicast Service (3GPP2 BCMCS), and the like. An Interaction Network 70 transmits BCAST service on a one-to-one basis, or interactively exchanges control information and additional information related to the reception of the BCAST service, and may be, for example, an existing cellular network.

BCAST-1 to BCAST-8 are interfaces among entities.

Generally, in BCAST service, when a broadcast service managing server transmits encrypted service data, a plurality of terminals receive the encrypted service data. In this case, each of the plurality of terminals decrypts (i.e. deciphers) the encrypted service data, which has been provided from the server, through use of a pre-acquired encryption key (e.g. cryptographic key), thereby being able to use a corresponding service.

In connection with this, methods for encrypting broadcast content and service are roughly classified into two categories, i.e. service protection and content protection. Service protection relates to protection of a transmission channel between the BSD/A 30 and the terminal 50, and content protection relates to end-to-end protection between the BSA 20 and terminal 50.

Meanwhile, an OMA BCAST SPCP DRM profile implements a key management scheme for mobile broadcast services. Two types of keys, i.e. Long-Term Keys (LTKs) and Short-Term Keys (STKs), are defined for access and provisioning of service and content. The LTKs are used for setting up (i.e. conditioning) access criteria for STKs according to a service subscription policy for users, by encrypting the STKs through use of the LTKs. The STKs are used to actually encrypt traffic. The LTKs and STKs must be periodically updated, wherein the lifetime of the LTKs are much longer than that of the STKs. The LTKs and STKs are provided to the user by a Rights Issuer (RI).

Hereinafter, description on key management in a DRM profile will be given in detail.

<figref idref="f0002">FIG. 2</figref> is a diagram illustrating a key hierarchy defined in a general DRM profile.

Referring to <figref idref="f0002">FIG. 2</figref>, an Inferred Encryption Key (IEK) 120 related to Registration Keys 100 and a Public/private key pair 110 are used to encrypt long-term keys which are called a Service Encryption Key (SEK) 130 and a Program Encryption Key (PEK) 140. SEKs and PEKs are transmitted to each terminal through Generalized Rights Objects (GROs). Also, the Generalized Rights Objects include permissions linked to content and other attributes. The SEKs and PEKs function to protect each subscription and program, which can be purchased in one unit. The service corresponds to one program channel, a part of a channel, or a group of program channels.

The SEK 130 is provided to a subscribed user having subscribed for the whole service, that is, a user who continuously receives content and regularly updated SEKs even without a separate request as authentication is successfully achieved. Such a scenario is called "subscription-based access."

The PEK 140 is provided to a user who is restricted to accessing a service only within a predetermined time interval, or a user who is restricted to using a program by the unit service. In order to obtain access to the next program or a consequent time interval, a corresponding user must make an additional purchase request. That is, one program and a certain time interval may be associated with one or more PEKs. Such a scenario may be called "Pay-Per-View (PPV)-based access."

The SEK is an intermediate key, and does not directly encrypt content, but encrypts a Traffic Encryption Key (TEK) 150 or PEK when necessary. The PEK is used to encrypt TEKs.

A terminal may receive a Service Authentication Seed (SAS) and a Program Authentication Seed (PAS), respectively, which are used to authenticate messages delivering TEKs, together with an SEK and a PEK. The SEK and the SAS are inclusively designated as a "Service Encryption and Authentication Key material (SEAK)." The PEK and the PAS are inclusively designated as a "Program Encryption and Authentication Key material (PEAK)."

The TEK 150 is an STK. The TEK 150 is included in a Short Term Key Message (STKM) and is then transferred, and is encrypted by an SEK or PEK when necessary. The TEK must be frequently updated for security. Such a frequent update requires the consumption of a large amount of bandwidth, which is a serious disadvantage of the key management system. That is, in order to ensure successful delivery of a TEK and simultaneously, to avoid interruption of service, STKM messages must be more frequently transmitted.

<figref idref="f0003">FIGs. 3</figref> and <figref idref="f0004">4</figref> are diagrams showing examples of the aforementioned key distribution. First, <figref idref="f0003">FIG. 3</figref> is a diagram illustrating a key distribution flow of an SEK and a TEK, which are provided in a general subscription-based access environment.

Referring to <figref idref="f0003">FIG. 3</figref>, in the subscription-based access environment, an SEK lifetime (SEK LT) is calculated to be "n" multiplied by a TEK lifetime (TEK LT). Before the current service encryption key "SEKy-₁" expires, an RI has to generate and transmit a new service encryption key "SEK_y" to a service subscriber in a GRO in step 210. The SEK_y is encrypted by one of registration keys. Then, after the current service encryption key "SEKy_-1" has expired, PEKs delivered together with TEK_x+1, TEK_x+2,..., TEK_x+n through an STKM are encrypted by the SEK_y. Also, before the SEK_y expires, the RI generates and transmits a new service encryption key "SEK_y+1" to the service subscriber in step 220.

<figref idref="f0004">FIG. 4</figref> is a diagram illustrating a supply flow of an SEK and a TEK in a general PPV-based access environment.

Referring to <figref idref="f0004">FIG. 4</figref>, in the PPV-based access environment, a PEK lifetime (PEK LT) is calculated to be "m" multiplied by a TEK lifetime (TEK LT). Here, m≤n.

For example, when it is assumed that PEK LT = 0.5 * SEK LT, the PEK must be updated two times more frequently than the SEK. For example, it is assumed that the user makes two purchase requests for two consequent time intervals associated with PEK_z and PEK_z+1. In this case, before a TEK_x+1 (which is a first TEK related to the PEK_z) is used, an RI transmits a new GRO including the PEK_z to the user in step 310. The PEK_z is encrypted by an SMK₁ shared only between the corresponding user and the RI. Before a TEK_x+m+1 (which is a first TEK related to the PEK_z+1) is used, the RI transmits a new GRO including the PEK_z+1 to the user in step 320.

However, when the user does not issue a further purchase request until a TEK_x+n+1 has been used, the RI does not transmit a PEK for the TEK_x+n+1 to the user, so that the user cannot decrypt TEKs beginning from the TEK_x+n+1. Accordingly, there is a problem in that the user cannot use a service or service content requested by the user.

SUMMARY OF THE INVENTION

The present invention has been made to address at least the above-mentioned problems and/or disadvantages, and to provide at least the advantages described below. Accordingly, an aspect of the present invention provides a method for distributing traffic encryption keys in a mobile broadcasting system, and a system for the same.

The prevent invention provides a method for newly generating a message including traffic encryption keys, and distributing and receiving the traffic encryption keys through the message in a mobile broadcasting system, and a system for the same.

In accordance with an aspect of the present invention, there is provided an encryption key distribution method for protecting a broadcast service provided to a terminal in a mobile broadcasting system, which includes generating, by a network, a first encryption key when the broadcast service is first provided to the terminal, and transmitting a generalized rights object message, which includes identification information for identifying the generated first encryption key, to the terminal; and generating, by the network, a second encryption key before a lifetime of the first encryption key expires, and transmitting the generalized rights object message, which includes identification information for identifying the generated second encryption key, to the terminal.

In accordance with another aspect of the present invention, there is provided a method for receiving, by a terminal, an encryption key distributed for protection of a broadcast service in a mobile broadcasting system, which includes verifying a generalized rights object message by means of a subscriber management key when receiving the generalized rights object message from a network; checking identification information for identifying an encryption key included in the generalized rights object message, by means of a security function; and identifying an access value pair for the encryption key through the identification information, and storing the identified access value pair.

In accordance with still another aspect of the present invention, there is provided an encryption key distribution system for protecting a broadcast service provided to a terminal in a mobile broadcasting system, the encryption key distribution system including a network for generating a first encryption key when the broadcast service is first provided to the terminal, transmitting a generalized rights object message which includes identification information for identifying the generated first encryption key, generating a second encryption key before a lifetime of the first encryption key expires, and transmitting the generalized rights object message, which includes identification information for identifying the generated second encryption key, to the terminal; and the terminal for receiving the generalized rights object message from the network, checking identification information for identifying the first and second encryption keys included in the generalized rights object message, and identifying and storing an access value pair for an encryption key through the checked identification information.

Advantageous Effects

Effects of the present invention, especially the effects obtained by the above-mentioned embodiments, will now be described.

The present invention provides a new key hierarchy. Also, according to the newly provided key hierarchy, the present invention provides a method for generating and acquiring a traffic encryption key (TEK) for contents and programs for broadcast service. In addition, the present invention newly defines a message which can identify the lifetime of the key and the range of an encryption key, even without loads by messages frequently transmitted in connection with the conventional lifetime of the key, and also provides the format and transmission method of the newly defined message.

Therefore, there is an advantage in that broadcast service contents can be more efficiently protected and decrypted. In addition, since the protection and decryption are performed, without any change in the existing broadcast service access scenario, the method and system according to the present invention have high compatibility with the existing mobile broadcasting system.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features and advantages of the present invention will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings in which: <ul id="ul0001" list-style="none" compact="compact"><li><figref idref="f0001">FIG. 1</figref> is a block diagram illustrating a network architecture of a mobile broadcasting system, to which the present invention is applied;</li><li><figref idref="f0002">FIG. 2</figref> is a diagram illustrating the key hierarchy of a general DRM profile;</li><li><figref idref="f0003">FIG. 3</figref> is a flow diagram illustrating a procedure for providing SEK/TEK to a general service subscriber;</li><li><figref idref="f0004">FIG. 4</figref> is a flow diagram illustrating a procedure for providing SEK/TEK to a general PPV user;</li><li><figref idref="f0005">FIG. 5</figref> is a diagram illustrating a key hierarchy of a DRM profile according to an embodiment of the present invention;</li><li><figref idref="f0006">FIG. 6</figref> is a flow diagram illustrating a procedure for providing an AVP to a service subscriber according to an embodiment of the present invention;</li><li><figref idref="f0007">FIG. 7</figref> is a flow diagram illustrating a procedure for providing an AVP to a PPV user according to an embodiment of the present invention; and</li><li><figref idref="f0008">FIG. 8</figref> is a flowchart illustrating a procedure of processing a generalized rights object message in a terminal according to an embodiment of the present invention.</li></ul>

DETAILED DESCRIPTION OF EMBODIMENTS OF THE PRESENT INVENTION

Embodiments of the present invention are described in detail with reference to the accompanying drawings. It should be noted that the same elements are designated by the same reference numerals although they are shown in different drawings. Also, in the below description, many particular items are shown, but these are given only for providing the general understanding of the present invention. It will be understood by those skilled in the art that various changes in form and detail may be made within the scope of the present invention. Further, in the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

The present invention provides a method of using Access Value Pairs (AVP) for management of traffic encryption keys (TEKs) for broadcast service, which is applied to an OMA BCAST Service Protection and Content Protection Architecture (i.e. DRM profile).

The present invention includes generation, distribution, and maintenance of an encryption key between an authorized user or user group (i.e. terminal group) and a server. The encryption key is used to protect (i.e. encrypt) a service content, which is distributed to a content/service user by a content/service provider. In connection with this, according to the present invention, service, i.e. existing access scenarios are maintained without any change, and a service encryption key (SEK) and a program encryption key (PEK) are replaced by AVP. Especially, the AVP is calculated using a random value pair, which is called a key seed pair (KSP), randomly generated by a Rights Issuer (RI). Next, the AVP is used to derive a plurality of traffic encryption keys (TEKs).

Accordingly, the present invention updates a key hierarchy, changes a TEK identification method, and prevents frequent transmission of short-term key messages (STKMs), which has occurred in the existing method. Also, a Generalized Rights Object (GRO) message newly proposed according to the present invention includes a TEK identifier (ID), access criteria, information, which has been carried through an STKM in the existing method, and an AVP. Also, the present invention provides a method of processing a GRO message in a terminal.

<figref idref="f0005">FIG. 5</figref> is a diagram illustrating a key hierarchy according to an embodiment of the present invention.

Referring to <figref idref="f0005">FIG. 5</figref>, an Inferred Encryption Key (IEK) 420 related to Registration Keys (i.e. registration-level keys) 400 or a Device Public Key 410 is used to encrypt Access Value Pairs (AVP) 430. AVP (hereinafter "SAVP") for service represents Key Seed Pair KSP) values, and AVP (hereinafter "PAVP") 430 for a program represents a subset of hash values for a given service key seed pair. The AVP is transmitted to each terminal through a GRO message, and functions to protect a single subscription service or program every usage scenario (e.g. subscription-based, PPV, and the like.). The AVP is used to derive one set of Traffic Encryption Keys (TEKs) 440.

According to the present invention, TEKs are not transferred through existing Short-Term Key Messages (STKMs) any more, but are transferred through a GRO message. Accordingly, while an SAS and a PAS require an additional key material, the present invention does not require an additional key material. Here, a procedure of deriving the TEK and AVP is as follows.

Meanwhile, a KSP is a pair of {KS₁, KS₂}, wherein the KS₁ and KS₂ are randomly generated by an RI. When the total number of TEKs which can be generated by a KSP is "n," the AVP may be calculated in two manners as below: <ol id="ol0001" compact="compact" ol-style=""><li>1. When the user is allowed to generate n number of TEKs: <maths id="math0001" num=""><math display="block"><mi>AVP</mi><mo>=</mo><mi>KSP</mi><mo>=</mo><mfenced open="{" close="}"><msub><mi>KS</mi><mn>1</mn></msub><msub><mi>KS</mi><mn>2</mn></msub></mfenced></math><img file="EP2288071A2_D0001.tif" /></maths></li><li>2. When the user is allowed to generate m number of TEKs (wherein m&lt;n): <ol id="ol0002" compact="compact" ol-style=""><li>a) A hash function is applied to the KS₁ n iterations, as described above, and a sequence of hash values {S_i} is stored. <maths id="math0002" num=""><math display="block"><mtable columnalign="left"><mtr><mtd><mspace width="3em" /><msub><mi mathvariant="normal">S</mi><mn mathvariant="normal">1</mn></msub><mo mathvariant="normal">=</mo><mi>hash</mi><mspace width="1em" /><mfenced><msub><mi>KS</mi><mn mathvariant="normal">1</mn></msub></mfenced><mo mathvariant="normal">,</mo><msub><mi mathvariant="normal">S</mi><mn mathvariant="normal">2</mn></msub><mo mathvariant="normal">=</mo><mi>hash</mi><mspace width="1em" /><mfenced><msub><mi mathvariant="normal">S</mi><mn mathvariant="normal">1</mn></msub></mfenced><mo mathvariant="normal">,</mo><mo mathvariant="normal">…</mo><mspace width="1em" /><msub><mi mathvariant="normal">S</mi><mrow><mi mathvariant="normal">n</mi><mo mathvariant="normal">-</mo><mn mathvariant="normal">1</mn></mrow></msub><mo mathvariant="normal">=</mo><mi>hash</mi><mspace width="1em" /><mfenced><msub><mi mathvariant="normal">S</mi><mrow><mi mathvariant="normal">n</mi><mo mathvariant="normal">-</mo><mn mathvariant="normal">2</mn></mrow></msub></mfenced><mo mathvariant="normal">,</mo></mtd></mtr><mtr><mtd><msub><mi mathvariant="normal">S</mi><mi mathvariant="normal">n</mi></msub><mo mathvariant="normal">=</mo><mi>hash</mi><mspace width="1em" /><mfenced><msub><mi mathvariant="normal">S</mi><mrow><mi mathvariant="normal">n</mi><mo mathvariant="normal">-</mo><mn mathvariant="normal">1</mn></mrow></msub></mfenced></mtd></mtr></mtable></math><img file="EP2288071A2_D0002.tif" /></maths> The hash sequence as described above is called a forward hash sequence.</li><li>b) A hash function is applied to the KS₂ n iterations, as described above, and a sequence of hash values {M_i} is stored, beginning at the last hash value. <maths id="math0003" num=""><math display="block"><mtable columnalign="left"><mtr><mtd><mspace width="3em" /><msub><mi mathvariant="normal">M</mi><mn mathvariant="normal">1</mn></msub><mo mathvariant="normal">=</mo><mi>hash</mi><mspace width="1em" /><mfenced><msub><mi mathvariant="normal">M</mi><mn mathvariant="normal">2</mn></msub></mfenced><mo mathvariant="normal">,</mo><msub><mi mathvariant="normal">M</mi><mn mathvariant="normal">2</mn></msub><mo mathvariant="normal">=</mo><mi>hash</mi><mspace width="1em" /><mfenced><msub><mi mathvariant="normal">M</mi><mn mathvariant="normal">3</mn></msub></mfenced><mo mathvariant="normal">,</mo><mo mathvariant="normal">…</mo><mspace width="1em" /><msub><mi mathvariant="normal">M</mi><mrow><mi mathvariant="normal">n</mi><mo mathvariant="normal">-</mo><mn mathvariant="normal">1</mn></mrow></msub><mo mathvariant="normal">=</mo><mspace width="1em" /><mi>hash</mi><mspace width="1em" /><mfenced><msub><mi mathvariant="normal">M</mi><mi mathvariant="normal">n</mi></msub></mfenced><mo mathvariant="normal">,</mo></mtd></mtr><mtr><mtd><msub><mi mathvariant="normal">M</mi><mi mathvariant="normal">n</mi></msub><mspace width="1em" /><mo mathvariant="normal">=</mo><mi>hash</mi><mspace width="1em" /><mfenced><msub><mi>KS</mi><mn mathvariant="normal">2</mn></msub></mfenced></mtd></mtr></mtable></math><img file="EP2288071A2_D0003.tif" /></maths> That is, M₁ represents an n^th hash value of the KS₂, and M₂ represents an (n-1)^th hash value of the KS₂. Such a hash sequence is called a backward hash sequence.</li><li>c) AVP = {S_i, M_j}</li></ol></li></ol>

Here, "i" represents the index (i.e. sequence number) of the first TEK which is usable by the user among a sequence of n TEKs, and "j" represents the index (i.e. sequence number) of the last TEK which is usable by the user among a sequence of n TEKs.

The description below is provided on the scenario where key materials are mapped. Meanwhile, when key materials are mapped, an SEK may be mapped to "a single SAVP = KSP" (i.e. KSP LT = SEK LT: n TEKs are derived from a KSP), or may be mapped to a plurality of SAVPs (SAVP₁ = KSP₁, SAVP₂ = KSP₂,...). Also, a PEK may be mapped to a single PAVP derived from a related SAVP, or may be mapped to a plurality of PAVPs derived from one or more related SAVPs, respectively.

Also, a BSM may generate n TEKs from forward and/or backward hash sequences, as below. <maths id="math0004" num=""><math display="block"><msub><mi>TEK</mi><mi mathvariant="normal">i</mi></msub><mo mathvariant="normal">=</mo><msub><mi mathvariant="normal">S</mi><mi mathvariant="normal">i</mi></msub><mspace width="1em" /><mi>XOR</mi><mspace width="1em" /><msub><mi mathvariant="normal">M</mi><mi mathvariant="normal">j</mi></msub></math><img file="EP2288071A2_D0004.tif" /></maths>

Here, the XOR represents a bit-wise exclusive OR operation.

In a terminal, m TEKs in {S_i, M_j} are calculated as follows. That is, m number of S_i+x values are calculated with respect to all x in an interval of [1,m], and m number of M_j-_x values are calculated with respect to all x in the interval of [1,m]. Finally, "TEK_x = S_x XOR M_x" is calculated with respect to all x in an interval of [i,i+m].

Generally, in order to satisfy the demands for various security protocols, different types of hash functions may be used for TEK derivation, or a hash function may be truncated and output.

<figref idref="f0006">FIGs. 6</figref> and <figref idref="f0007">7</figref> are diagrams showing an example of key distribution according to an embodiment of the present invention. Conditions in <figref idref="f0006">FIGs. 6</figref> and <figref idref="f0007">7</figref> are the same as those in <figref idref="f0003">FIGs. 3</figref> and <figref idref="f0004">4</figref>.

<figref idref="f0006">FIG. 6</figref> is a diagram illustrating an SAVP provision flow in a subscription-based access condition according to an embodiment of the present invention.

In a subscription-based access condition according to an embodiment of the present invention, the lifetime of an SAVP is calculated to be n times that of a TEK. That is, n number of TEKs can be generated from an SAVP. When service provision starts, an RI generates and transmits a new SAVP₁ to a service subscriber through a GRO message in step 510. The SAVP₁ is encrypted by an ERK₁, which is shared only between the user and the RI. Also, before the SAVP₁ has expired, the RI newly generates and transmits an SAVP₂ to the service subscriber through a GRO message in step 520. The SAVP₂ also is encrypted by an ERK₁, which is shared only between the user and the RI.

<figref idref="f0007">FIG. 7</figref> is a diagram illustrating a PAVP provision flow in a PPV-based access condition according to an embodiment of the present invention.

In a PPV-based access condition according to an embodiment of the present invention, the lifetime (PAVP LT) of a PAVP is calculated to be m times that of a TEK, wherein m≤n. Although <figref idref="f0007">FIG. 7</figref> shows an example where two PAVPs (PAVP₁, PAVP₂) are derived from an SAVP₁, there may be three or more PAVPs derived from the SAVP₁. The user has to issue a separate purchase request for every PAVP.

When the user performs a first purchase before starting an access to content, an RI transmits a PAVP₁ to the user through a GRO message in step 610. Also, before the PAVP₁ has expired, the user issues a second purchase request. When the purchase has been successfully completed, the RI transmits a PAVP₂ to the user through a GRO message in step 620. When the user does not issue a further purchase request before the PAVP₂ has expired, the RI does not transmit any PAVP, so that the user cannot access content any more.

In the following description, a key identification method according to an embodiment of the present invention will be described.

Table 1 below shows a mapping relation between key identifiers according to an embodiment of the present invention and key identifiers of a DRM profile. <tables id="tabl0001" num="0001"><table frame="all"><title>Table 1.</title><tgroup cols="4"><colspec colnum="1" colname="col1" colwidth="31mm" /><colspec colnum="2" colname="col2" colwidth="46mm" /><colspec colnum="3" colname="col3" colwidth="44mm" /><colspec colnum="4" colname="col4" colwidth="46mm" /><thead><row><entry namest="col1" nameend="col2" align="center" valign="middle">DRM Profile</entry><entry namest="col3" nameend="col4" align="center" valign="middle">Key Mapping according to embodiment of the present invention</entry></row><row><entry align="center" valign="top">Key</entry><entry align="center" valign="top">Identification means</entry><entry align="center" valign="top">Key</entry><entry align="center" valign="top">Identification Means</entry></row></thead><tbody><row><entry align="center"><i>None</i></entry><entry align="center" /><entry align="center"><i>KSP</i></entry><entry align="center">CID_extension (32 bits) This is a random value for identifying service/program key materials.</entry></row><row><entry align="center"><i>SEK</i></entry><entry align="center">service_CID_extension (32 bits) This is a random value for identifying a service key material.</entry><entry align="center"><i>SAVP</i></entry><entry align="center">CID_extension + TEK ID_LOW + TEK ID_HIGH Here, TEK ID_LOW represents the sequence number of first TEK to be derived from SAVP, and TEK ID_HIGH represents the sequence number of last TEK to be derived from PAVP.</entry></row><row><entry align="center"><i>PEK</i></entry><entry align="center">program_CID_extension (32 bits) This is a random value for identifying a program key material.</entry><entry align="center"><i>PAVP</i></entry><entry align="center">CID_extension + TEK ID_LOW + TEK ID_HIGH Here, TEK ID_LOW represents the sequence number of first TEK to be derived from PAVP, and TEK ID_HIGH represents the sequence number of last TEK to be derived from PAVP.</entry></row><row><entry align="center"><i>TEK for IPsec</i></entry><entry align="center">SPI (32 bits)</entry><entry align="center"><i>TEK for IPsec</i></entry><entry align="center">SPI (32 bits) = SAID (16 bits) D TEK ID (16 bits) Here, SAID is random value, and TEK ID represents the sequence number of TEK.</entry></row><row><entry align="center"><i>TEK for SRTP</i></entry><entry align="center">MKI (8*master_key_index _length bit) This is a master key index (MKI) which is the same as that defined in SRTP, and master_key_index_length represents length of MKI.</entry><entry align="center"><i>TEK for SRTP</i></entry><entry align="center">MKI = TEK ID (&gt;=2 bytes) (for SRTP)</entry></row><row><entry align="center"><i>TEK for ISMACryp</i></entry><entry align="center">key_indicator (8*key_indicator_length bit) This is identifier of TEK, which is the same as that defined in ISMACryp, and key_indicator_length represents length of key indicator.</entry><entry align="center"><i>TEK for ISMACryp</i></entry><entry align="center">key_indicator = TEK ID (&gt;=2 bytes)</entry></row><row><entry align="center"><i>TEK for DCF</i></entry><entry align="center">key_identifier (8*key_identifier_length bit) This is identifier of TEK, which is the same as that defined in DCF, and key_identifier_length represents length of key indicator.</entry><entry align="center"><i>TEK for DCF</i></entry><entry align="center">key_indicator = TEK ID (&gt;=2 bytes)</entry></row></tbody></tgroup></table></tables>

The following description will be given on a GRO format according to an embodiment of the present invention. First, according to embodiments of the present invention, two formats may be applied for the GRO format.

One applicable format is an OMA DRM 2.0 Rights Object (RO) format. In the DRM 2.0, an RO can be included in a Protected Rights Object of a GRO message, which is transmitted from an RI to a terminal, and then the RO can be transmitted. The Protected Rights Object includes a Rights Object Payload. Therefore, an RO including new materials and attributes according to the present invention is inserted into a Rights Object Payload, and is then transmitted to a terminal through a GRO message. Here, the newly defined materials and attributes may be expressed in an XML format before they are inserted into the Rights Object Payload.

The other applicable format is a Broadcast Rights Object (BCRO) format. This is a format used when a GRO message is transmitted through a broadcast channel. The Broadcast Rights Object (BCRO) includes an "OMADRMAsset()" object, which contains a service encryption/authentication key or program encryption/authentication key. This object is simply replaced by a TEX management extension proposed in the present invention, as shown in Table 2 below. AVP and "Master Salt" values can be encrypted in the same rule as that defined for service encryption/authentication key and program encryption/authentication key.

According to an embodiment of the present invention, configuration elements (i.e. materials) for TEKs are transmitted through a GRO message, so that the existing short-term key STKMs delivering TEKs are not required any more, except for STKM management data. Meanwhile, a GRO message includes access criteria and other attributes linked to encrypted content in connection with STKM management data. In other words, according to an embodiment of the present invention, an SEK and a PEK are replaced by an SAVP and a PAVP, respectively, the permission and attributes thereof are also replaced in the form of rights object (RO) having the format of a newly defined traffic encryption key management extension, and then a TEK is transmitted.

Table 2 below shows a traffic encryption key management extension of a Generalized Rights Object (GRO) according to an embodiment of the present invention. <tables id="tabl0002" num="0002"><table frame="all"><title>Table 2.</title><tgroup cols="2"><colspec colnum="1" colname="col1" colwidth="85mm" /><colspec colnum="2" colname="col2" colwidth="54mm" /><thead><row><entry align="center" valign="top">SYNTAX</entry><entry align="center" valign="top">LENGTH (unit: bit)</entry></row></thead><tbody><row><entry>protocol_version</entry><entry>4</entry></row><row><entry>CID extension</entry><entry>32</entry></row><row><entry>number_of_traffic_keys</entry><entry>16</entry></row><row><entry>encrypted_access_value_length</entry><entry>8</entry></row><row><entry>encrypted_first_acccess_value</entry><entry>8*encrypted_access_value_length</entry></row><row><entry>encrypted_second_access_value</entry><entry>8*encrypted_access_value_length</entry></row><row><entry>number_of_tek_descriptors</entry><entry>16</entry></row><row><entry>tek_descriptor_loop()</entry>&lt;entry /&gt;</row><row><entry>traffic_protection_protocol</entry><entry>3</entry></row><row><entry>traffic_authentication_flag</entry><entry>1</entry></row><row><entry>if (traffic_protection_protocol == TKM_ALGO_IPSEC)</entry>&lt;entry /&gt;</row><row><entry>security_parameter_index</entry><entry>16</entry></row><row><entry>number_of_traffic_keys</entry><entry>16</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;</row><row><entry>if (traffic_protection_protocol ==</entry>&lt;entry /&gt;</row><row><entry>TKM_ALGO_SRTP)</entry>&lt;entry /&gt;</row><row><entry>master_key_index_length</entry><entry>8</entry></row><row><entry>master_key_index</entry><entry>8*master_key_index_length (≥16)</entry></row><row><entry>number_of_traffic_keys</entry><entry>16</entry></row><row><entry>master_salt_flag</entry><entry>1</entry></row><row><entry>if (master_salt_flag == TKM_FLAG_TRUE)</entry>&lt;entry /&gt;</row><row><entry>master_salt_seed_low</entry><entry>112</entry></row><row><entry>master_salt_seed_high</entry><entry>112</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;</row><row>&lt;entry /&gt;&lt;entry /&gt;</row><row><entry>if (traffic_protection_protocol == TKM_ALGO ISMACRYP)</entry>&lt;entry /&gt;</row><row><entry>key_indicator_length</entry><entry>8</entry></row><row><entry>key_indicator</entry><entry>8*key_identifier_length (≥16)</entry></row><row><entry>number_of_traffic_keys</entry><entry>16</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;</row><row><entry>if (traffic_protection_protocol == TKM_ALGO_DCF)</entry>&lt;entry /&gt;</row><row><entry>key_identifier_length</entry><entry>8</entry></row><row><entry>key_identifier</entry><entry>8*key_identifier_length (≥16)</entry></row><row><entry>number_of_traffic_keys</entry><entry>16</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;</row><row><entry>protection_after_reception</entry><entry>2</entry></row><row><entry>reserved_for_future_use</entry><entry>1</entry></row><row><entry>access_criteria_flag</entry><entry>1</entry></row><row><entry>program_flag</entry><entry>1</entry></row><row><entry>reserved_for_future_use</entry><entry>4</entry></row><row><entry>traffic_key_lifetime</entry><entry>4</entry></row><row><entry>if (access_criteria_flag == TKM_FLAG_TRUE)</entry>&lt;entry /&gt;</row><row><entry>reserved_for_future_use</entry><entry>8</entry></row><row><entry>number_of_access_criteria_descriptors</entry><entry>8</entry></row><row><entry>access_criteria_descriptor_loop()</entry>&lt;entry /&gt;</row><row><entry>access_criteria_descriptor()</entry>&lt;entry /&gt;</row><row>&lt;entry /&gt;&lt;entry /&gt;</row><row>&lt;entry /&gt;&lt;entry /&gt;</row><row><entry>if (program_flag == TKM_FLAG_TRUE)</entry>&lt;entry /&gt;</row><row><entry>program_selectors_and_flags</entry>&lt;entry /&gt;</row><row><entry>reserved_for_future_use</entry><entry>7</entry></row><row><entry>permissions_flag</entry><entry>1</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;</row><row><entry>if (permissions_flag == TKM_FLAG_TRUE)</entry>&lt;entry /&gt;</row><row><entry>permissions_category</entry><entry>8</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;</row><row>&lt;entry /&gt;&lt;entry /&gt;</row><row>&lt;entry /&gt;&lt;entry /&gt;</row></tbody></tgroup></table></tables>

Referring to Table 2, fields described below are fields which are inherited from an existing STKM and defined. The protocol_version field indicates a protocol version. The protection_after_reception field indicates whether or not traffic must be encrypted and stored after the traffic is received. The access_criteria_flag field indicates whether or not access criteria can be used for a given traffic encryption key. The traffic_protection_protocol field, a traffic protection protocol is specified. The traffic_authentication_flag field indicates, for example, whether or not traffic authentication is required for IP security protocol (IPsec).

The master_key_index_length field specifies the length of a master key index (MKI) in a secure real-time transport protocol (SRTP). The master salt flag field indicates whether or not a master salt is present. The key_indicator_length field specifies the length of a key indicator in an ISMACryp.

The key_identifier _length field specifies the length of a key indicator in a DCF. The traffic key lifetime field specifies the lifetime of a single traffic encryption key.

The number_of_access_criteria_descriptors field specifies the number of access criteria descriptors. The program_flag field indicates whether or not program permissions are present.

The access_criteria_descriptor() field specifies access criteria. The permissions_flag field specifies program permission. The permissions category field specifies a program permission category. The reserved for future use field is specified on all occasions.

In contrast, the following fields are fields newly introduced for supporting the traffic encryption key management method according to the present invention.

The CID_extension field is the extension of the service_CID and the program_CID, which are content identifiers defined in a DRM profile, and allows to identify a service access value pair/a program access value pair for one service/program, together with TEK ID_LOW and TEK ID_HIGH. The CID_extension is substituted for the service_CID_extension and program_CID_extension, which are currently used in a DRM profile of an OMA BCAST.

The number of traffic keys field indicates the number of TEKs derived from a given AVP.

The encrypted_access_value_length field indicates the length of AVPs.

The encrypted_first acccess_value field encrypts a first material of AVP (S_i). Here, the materials of the AVP may be encrypted in the same manner as that defined for key encryption in a DRM profile.

The encrypted_second_access_value field encrypts a second material of AVP (M_j).

The number of tek_descriptors field indicates the number of TEK descriptors in management data. Here, a management extension includes at least one TEK descriptor. Also, available TEK descriptors may thoroughly describe permissions and attributes linked to content, and a given AVP. That is, it may be given to all TEKs.

The security_parameter_index field is inherited from an STKM and is modified. The security_parameter_index provides a link to a first IPsec ESP header, which is related to content protected by a first TEK derived from an AVP.

The number_of_traffic_key field indicates a range of TEKs in which the current tek_descriptor is available, and begins at a TEK-ID-part value in an IPsec, an SRTP, a security_parameter_index of an ISMACryp or DCF, a master_key_index, a key_indicator, or a key_identifier.

The master key_index field is inherited from an STKM and is modified. The master_key_index provides a link to an SRTP header, which is related to content protected by a first TEK derived from an AVP.

The master salt seed low field is a first random value of a second AVP used to derive the required number of salt values (wherein, at least one salt value can be set for every traffic encryption key). A terminal performs the same procedure as that defined to derive salt values when generating a TEK. Also, the terminal may truncate the derived values to 112 bits.

The master_salt_seed_high field is a second random value of a KSP used to derive salt values.

The key_indicator field is inherited from an STKM and is modified. The key_indicator provides a link to a first TEK used to decrypt AUs.

The key_identifier field is inherited from an STKM and is modified. The key_identifier provides a link to a first TEK which is used to decrypt DCF-encrypted files.

<figref idref="f0008">FIG. 8</figref> is a flowchart illustrating a procedure of processing a TEK management extension in a terminal according to an embodiment of the present invention.

Referring to <figref idref="f0008">FIG. 8</figref>, a terminal receives a GRO message, and searches for and stores a CID_extension in step 701. In step 703, the terminal derives an AVP, and checks the length (e.g. an available lifetime of the AVP) of the given AVP, and the number of TEKs which can be derived from the AVP.

In step 703, the terminal may search for an encrypted_first_access_value, an encrypted_second_access_value, the number_of_traffic_keys, and encrypted_access_value_length, in the GRO message. Then, the terminal calculates a set of TEKs based on the searched values in step 705.

In step 707, the terminal checks the number of TEK descriptors. This can be achieved through the number_of tek_descriptors. The TEK descriptors include description about the given AVP, and contain descriptions about attributes and permissions linked to content. In step 709, the terminal searches for protocol attributes. For example, the terminal checks the protocol_version, and checks the traffic_protection_protocol and the traffic_authentication_flag. In step 711, based on the selected traffic protection protocol, that is, through the use of the number of_traffic_keys and protocol-specific indexing, a range of a TEK ID, to which the current TEK descriptor is applied, is searched for and a link related to content is stored. When it is determined that authentication of the traffic is required in step 713, the procedure proceeds to step 715, where a traffic authentication material (e.g. salts) is derived. In step 717, a TEK lifetime is stored every current range of TEKs from the traffic_key_lifetime.

When it is determined that access criteria are available in step 719, the procedure proceeds to step 721, where access criteria every current range of TEKs are processed and stored for the current order and the next order. When it is determined that program permissions are available in step 723, the procedure proceeds to step 725, where the program permissions (i.e. permissions_category) are processed and stored.

Although several embodiments of the present invention have been described for illustrative purposes, those skilled in the art will appreciate that various modifications, additions and substitutions are possible, without departing from the scope and spirit of the invention as disclosed in the accompanying claims.