[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

US9800358B2 - Method and system for protecting broadcast service/content in a mobile broadcast system, and method for generating short term key message threfor - Google Patents

Method and system for protecting broadcast service/content in a mobile broadcast system, and method for generating short term key message threfor Download PDF

Info

Publication number
US9800358B2
US9800358B2 US13/422,760 US201213422760A US9800358B2 US 9800358 B2 US9800358 B2 US 9800358B2 US 201213422760 A US201213422760 A US 201213422760A US 9800358 B2 US9800358 B2 US 9800358B2
Authority
US
United States
Prior art keywords
stkm
service
bsd
message
broadcast
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US13/422,760
Other versions
US20120170747A1 (en
Inventor
Byung-Rae Lee
Sung-Oh Hwang
Kook-Heui Lee
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020060063652A external-priority patent/KR100975386B1/en
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Priority to US13/422,760 priority Critical patent/US9800358B2/en
Publication of US20120170747A1 publication Critical patent/US20120170747A1/en
Application granted granted Critical
Publication of US9800358B2 publication Critical patent/US9800358B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/14—Arrangements for conditional access to broadcast information or to broadcast-related services
    • H04H60/23—Arrangements for conditional access to broadcast information or to broadcast-related services using cryptography, e.g. encryption, authentication, key distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
    • H04H60/81—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself
    • H04H60/90—Wireless transmission systems
    • H04H60/91—Mobile communication networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H04L2209/601—Broadcast encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the present invention relates generally to a broadcast service method in a mobile broadcast system and a system thereof, and in particular, to a method and system for protecting broadcast service/content between network entities constituting a broadcast system and a method for generating encryption keys and messages using the same.
  • IP Internet Protocol
  • OMA Open Mobile Alliance
  • BAC OMA Browser And Content
  • BCAST Mobile Broadcast Sub Working Group
  • FIG. 1 is a block diagram illustrating network architecture of a conventional mobile broadcast system.
  • a Content Creation (CC) 10 is a broadcast service (hereinafter BCAST service) provider, and the BCAST service can include the conventional audio/video broadcast service and file (music or data file) download service.
  • a BCAST Service Application (BSA) 20 generates BCAST service data by processing BCAST service data provided from the CC 10 into the form suitable for the BCAST network of FIG. 1 , and also generates standardized metadata necessary for a mobile broadcast guide.
  • a BCAST Service Distribution/Adaptation (BSD/A) 30 sets up a bearer over which it will transmit the BCAST service data provided from the BSA 20 , determines transmission schedules of the BCAST services, and generates a mobile broadcast guide.
  • a BCAST Subscription Management (BSM) 40 manages subscription information and BCAST service provisioning information for receipt of the BCAST service, and device information for a mobile terminal receiving the BCAST service.
  • a Terminal 50 is capable of receiving the BCAST service, and has a function capable of connecting with a cellular network according to terminal capability.
  • the Terminal 50 is assumed to be connectable with the cellular network.
  • a Broadcast Network 60 is for transmitting the BCAST service, and can be for Digital Video Broadcasting—Handheld (DVB-H), 3GPP Multimedia Broadcast and Multicast Services (MBMS) and 3GPP2 Broadcast and Multicast Services (BCMCS), for example.
  • An Interaction Network 70 is for transmitting the BCAST service on a point-to-point basis, or interactively exchanging control information and additional information related to the receipt of the BCAST service, and can be, for example, the existing cellular network.
  • a plurality of mobile terminals receive encrypted service data transmitted by a server for managing broadcast services.
  • the mobile terminals can use the corresponding service by deciphering the encrypted service data provided from the server using an encryption key previous stored therein.
  • a method for encrypting broadcast content/service is roughly divided into service protection and content protection.
  • Service protection indicates protection of a transmission channel between the BCAST Service Distribution/Adaptation (BSD/A) 30 and the Terminal 50
  • content protection indicates end-to-end protection between the BSA 20 and the Terminal 50 .
  • An aspect of the present invention is to address at least the problems and/or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the present invention is to provide a method for protecting broadcast service and/or content in a mobile broadcast system, and a system thereof.
  • Another aspect of the present invention is to provide a method for generating encryption keys and messages for protecting broadcast service and/or content in a mobile broadcast system, and a system thereof.
  • a further aspect of the present invention is to provide a method for generating a Traffic Encryption Key (TEK) for protecting broadcast service and/or content, and a Short Term Key Message (STKM) in a mobile broadcast system, and a system thereof.
  • TKI Traffic Encryption Key
  • STKM Short Term Key Message
  • An additional aspect of the present invention is to provide a method for generating and transmitting encryption keys and messages between the entities constituting a broadcast system to protect broadcast service and/or content in a mobile broadcast system, and a system thereof.
  • Still another aspect of the present invention is to provide a method for configuring a broadcast system, and generating and transmitting messages between components thereof to protect broadcast service and/or content in a mobile broadcast system, and a system thereof.
  • a method for generating an STKM for protection of a broadcast service being broadcasted to a terminal in a mobile broadcast system includes transmitting, by a BSD/A for transmitting the broadcast service to the terminal, a partially created STKM before Message Authentication Code (MAC) processing, to a BSM for managing subscription information, inserting, by the BSM, a TEK for deciphering of the broadcast service into the partially created STKM, and performing, by the BSM, MAC processing on the TEK-inserted STKM, thereby generating a completed STKM.
  • MAC Authentication Code
  • a method for generating an STKM for protection of a broadcast service being broadcasted to a terminal in a mobile broadcast system includes transmitting, by a BSM for managing subscription information, at least one key information for authentication of the broadcast service to a BSD/A for transmitting the broadcast service, generating, by the BSD/A, a TEK for deciphering the broadcast service in the terminal and inserting the TEK into a partially created STKM, and performing, by the BSD/A, MAC processing on the TEK-inserted STKM using the at least one key information, thereby generating a completed STKM.
  • a mobile broadcast system for transmitting an STKM for reception of a broadcast service to a terminal.
  • the system includes a BSD/A for generating a partially created STKM before MAC processing, encrypting the broadcast service using a TEK, and broadcasting the encrypted broadcast service; and a BSM for managing subscription information of the terminal, inserting the TEK into the partially created STKM received from the BSD/A, generating a completed STKM by performing MAC processing on the TEK-inserted STKM, and transmitting the completed STKM to the BSD/A.
  • a mobile broadcast system for transmitting a STKM for reception of a broadcast service to a terminal.
  • the system includes a BSD/A for inserting a TEK of the broadcast service into a partially created STKM before MAC processing, and generating a completed STKM using at least one key information including authentication key; and a BSM for managing subscription information of the terminal, and transmitting the at least one key information to the BSD/A.
  • FIG. 1 illustrates network architecture of a conventional mobile broadcast system
  • FIG. 2 illustrates a BSM-based method for generating an encryption key and a short term key message according to a first embodiment of the present invention
  • FIG. 3 illustrates a BSM-based method for generating a plurality of encryption keys and short term key messages according to a second embodiment of the present invention
  • FIG. 4 illustrates a BSD/A-based method for generating an encryption key and a short term key message according to a third embodiment of the present invention
  • FIG. 5 illustrates a BCAST service protection method using the first or second embodiment of the present invention
  • FIG. 6 illustrates a BCAST service protection method using the third embodiment of the present invention
  • FIG. 7 illustrates a process performed during operation of a BCAST DRM profile in the broadcast service protection architecture presented in FIGS. 2 and 3 ;
  • FIG. 8 illustrates a process performed during operation of a BCAST smartcard profile in the broadcast service protection architecture presented in FIGS. 2 and 3 ;
  • FIG. 9 illustrates a process performed during operation of a BCAST DRM profile in the broadcast content protection architecture presented in FIGS. 2 and 3 ;
  • FIG. 10 illustrates a process performed during operation of a BCAST smartcard profile in the broadcast content protection architecture presented in FIGS. 2 and 3 ;
  • FIG. 11 illustrates a process in which the methods described in FIGS. 2 and 3 interwork with an STKM generation method in the broadcast service and content protection architecture
  • FIG. 12 illustrates a process in which the method described in FIG. 4 interworks with broadcast service and content protection architecture.
  • FIG. 1 The basic architecture of the mobile broadcast system, to which the present invention is applicable, is shown in FIG. 1 , and the present invention will disclose service and content protection schemes therefor.
  • the content provided from a CC 10 for content protection is encrypted in a BSA 20 or a BSD/A 30 , and then broadcasted to a Terminal 50 .
  • the BSD/A 30 for service protection performs encryption on a transmission channel over which the BCAST service is provided.
  • a BSM 40 performs subscription management of a Terminal 50 for service protection and/or content protection.
  • Information related to encryption keys used for service protection and/or content protection and a method of using the same are as follows.
  • the Terminal 50 subscribes to the BSM 40 as a service subscriber, and then receives a Registration Key Material (RKM). Thereafter, the Terminal 50 can acquire a Long-Term Key Message (LKM) upon its subscription to the service, and then acquire a Short-Term Key Message (STKM) used for deciphering the encrypted service/content.
  • LLM Long-Term Key Message
  • STKM Short-Term Key Message
  • the Terminal 50 can decipher the LKM using the RKM, and acquires a Service Encryption Key (SEK) and a Service Authentication Key (SAK) as a result of the deciphering.
  • SEK Service Encryption Key
  • SAK Service Authentication Key
  • SEK and SAK are included in the LKM in the merged form called a Service Encryption Authentication Key (SEAK), and then delivered to the Terminal 50 .
  • SEK Service Encryption Key
  • SAK Service Authentication Key
  • the STKM includes a TEK, and in order to protect the TEK, the STKM is encrypted by the SEAK and then a MAC function is applied thereto. Using the TEK deciphered by the SEAK, the Terminal 50 can decipher the encrypted service/content.
  • the service protected through the encryption keys is transmitted from the BSD/A 30 to the Terminal 50 as shown in FIG. 1 , and the content protected by the encryption keys is transmitted from the BSA 20 to the Terminal 50 .
  • Table 1 provides a definition of BCAST interfaces (BCAST-1 to BCAST-8) 100 to 160 shown in FIG. 1 .
  • BCAST-1 Content is delivered from CC to BSA.
  • BCAST-2 Content/Service are delivered from BSA to BSD/A.
  • BCAST-3 TEK for encrypting Content is delivered from BSM to BSA.
  • BCAST-4 TEK, RKM, LKM, STKM, etc. are delivered from BSM to BSD/A.
  • SG Data Request Message and its Response Message are exchanged between BSD/A and BSM.
  • BCAST-5 Encrypted Service and Encrypted RKM, LKM, etc. are delivered to Terminal BCAST-7 RKM, LKM are transmitted from BSM to Terminal over Interaction Channel.
  • ‘Name’ indicates names of elements and attributes constituting the corresponding message.
  • ‘Type’ indicates a type (Element or Attribute) of the corresponding name.
  • the elements have values E 1 , E 2 , E 3 and E 4 , wherein E 1 indicates an upper element for the entire message, E 2 indicates a sub-element of E 1 , E 3 indicates a sub-element of E 2 , and E 4 indicates a sub-element of E 3 .
  • An attribute is denoted by A, and A indicates an attribute of the corresponding element. For example, A under E 1 indicates an attribute of E 1 .
  • Category is used for determining whether the corresponding element or attribute is mandatory or optional, and has an M value for the mandatory element or attribute, and an O value for the optional element or attribute.
  • Cardinality indicates a relationship between elements, and has values 0, 0 . . . 1, 1, 0 . . . n, 1 . . . n.
  • 0 indicates an optional relationship
  • 1 indicates a mandatory relationship
  • n indicates that a plurality of values can be used.
  • 0 . . . n indicates that the corresponding message may have no element, or n elements.
  • ‘Description’ indicates meaning of the corresponding element or attribute
  • Data Type indicates a data type for the corresponding element or attribute.
  • Table 2 to Table 7 show field formats of the messages defined in the present invention, and a description of each field of the messages is given in the corresponding table.
  • Table 8 shows the possible situations to which the messages can be applied.
  • An encryption key and a message used herein for encryption of service/content will be referred to as a TEK and an STKM, respectively.
  • Table 2 provides a definition of a Request Message Format Req- 1 .
  • Table 3 provides a definition of a Response Message Format Res- 1 .
  • Table 4 provides a definition of a Response Message Format Res- 2 .
  • Table 5 provides a definition of a Delivery Message Format Tra- 1 .
  • Table 6 provides a definition of a Confirm Message Format Con- 1 .
  • Table 7 provides a definition of a Confirm Message Format Con- 2 .
  • Table 8 shows message types identified using ‘Tag’ defined in the message formats of Table 2 to Table 7.
  • the ‘Tag’ values defined below are not always fixed, but simply indicate the message types, and they are subject to change according to circumstances.
  • an ‘Option’ field is used for indicating whether a single STKM is requested or multiple STKMs are requested.
  • Table 8 shows message types and applied message types according to ‘Tag’ value, and the messages can obtain performance improvement with use of the shortened message Res- 2 or Con- 2 with a message ID, shown in ‘Applied Message Type’.
  • FIG. 2 is a signaling diagram illustrating a BSM-based method for generating an encryption key and a short term key message according to a first embodiment of the present invention, wherein a TEK is generated as the encryption key and an STKM is generated as the short term key message.
  • the STKM is a message generated in a BSM 40 so that a subscriber may acquire an LKM through subscription to the service and then acquire a TEK with which it can decipher broadcast service and/or content.
  • the BSM 40 directly generates the TEK and the STKM, but a BSD/A 30 also partially participates in the STKM generation process.
  • the BSD/A 30 does not create a TEK part, and a MAC part of the STKM.
  • the BSD/A 30 delivers a partially created STKM, i.e. STKM without TEK and MAC, to the BSM 40 .
  • the BSM 40 can send the Req- 1 of Table 2 to the BSD/A 30 as an STKM Request Message.
  • the BSD/A 30 can send the Res- 1 of Table 3 or the Res- 2 of Table 4 as a STKM Request Response Message to the BSM 40 that transmitted the partially created STKM.
  • the BSD/A 30 can directly send the partially created STKM using the Tra- 1 defined in Table 5 as an STKM Delivery Message without a request of the BSM 40 .
  • the BSM 40 upon receipt of the STKM Delivery Message, the BSM 40 sends the Con- 1 defined in Table 6 or Con- 2 defined in Table 7 as an STKM Delivery Confirm Message indicating receipt of the STKM, to the BSD/A 30 in response thereto.
  • the BSM 40 In step 203 , the BSM 40 generates a TEK after receiving the partially created STKM. In addition, the BSM 40 encrypts the generated TEK with an SEK and inserts it into the STKM, and also performs MAC function processing on the STKM using an SAK and generates a completed STKM by inserting the processing result value into the STKM. The completed STKM is sent from the BSM 40 to the B SD/A 30 .
  • FIG. 3 illustrates a BSM-based method for generating a plurality of encryption keys and short term key messages according to a second embodiment of the present invention, wherein a plurality of TEKs and STKMs are generated for one content (program)/service.
  • a BSD/A 30 sends a plurality of partially created STKMs for one content (program) or one service to a BSM 40 .
  • the BSM 40 delivers a plurality of STKMs completed for one content (program) or one service to the BSD/A 30 . Therefore, in the method of FIG. 3 , although it is similar to the method disclosed in FIG. 2 , the BSM 40 sends a plurality of STKMs generated for one content (program) or one service, instead of sending one completed STKM.
  • a value of an Option field should be ‘1’ or ‘2’ indicating transmission of a plurality of STKMs.
  • a value of its Option field should be designated as ‘1’ or ‘2’ indicating transmission of a plurality of STKMs.
  • the BSM 40 generates the TEK in the embodiments of FIGS. 2 and 3
  • the BSD/A 30 rather than the BSM 40 can generate the TEK, insert it into the partially created STKM together with partial information, and deliver it to the BSM 40 .
  • the BSM 40 encrypts the TEK with a SEK, inserts it back into the STKM without a MAC, received from the BSD/A 30 , performs MAC function processing thereon with a SAK and resends the completed STKM to the B SD/A 30 .
  • the BSD/A 30 can send the partially created STKM with a TEK to the BSM 40 .
  • the BSM 40 can generate an STKM by extracting the associated information including the TEK from the corresponding message.
  • FIG. 4 illustrates a BSD/A-based method for generating an encryption key and a short term key message according to a third embodiment of the present invention, wherein a TEK is generated as the encryption key and an STKM is generated as the short term key message.
  • a BSD/A 30 exclusively generates the TEK and the STKM.
  • a BSM 40 delivers an SEK and an SAK for service encryption and authentication to the BSD/A 30 so that the BSD/A 30 can perform MAC processing on the STKM.
  • the B SD/A 30 encrypts in step 403 the TEK using the SEK, inserts it into the partially created STKM, and performs MAC function processing on the TEK-inserted STKM with a SAK, thereby generating a completed STKM.
  • the B SD/A 30 transmits the generated STKM to a Terminal 50 .
  • the BSD/A 30 can send the Req- 1 defined in Table 2 as an SEAK Request Message for requesting transmission of the SEK and the SAK to the BSM 40 .
  • the BSM 40 can send the Res- 1 defined Table 3 or the Res- 2 defined in Table 4 as an.
  • SEAK Response Message to the BSD/A 30 in response thereto.
  • the BSM 40 can directly transmit the SEK and the SAK by sending the Tra- 1 defined in Table 5 as a SEAK Delivery Message to the BSD/A 30 even when there is no transmission request for SEK and SAK from the BSD/A 30 .
  • the BSD/A 30 can send the Con- 1 defined in Table 6 or the Con- 2 defined in Table 7 as a Delivery Confirm Message to the BSM 40 .
  • the merged SEAK of the SEK and the SAK can be exchanged between the BSM 40 and the BSD/A 30 in the method disclosed in FIG. 4 , the SEK and the SAK can also be transmitted separately.
  • the message formats of Table 2 to Table 6 disclosed in the present invention can also be defined as message formats shown in Table 9 to Table 12.
  • Table 9 provides a definition of a Request Message Format Req- 1 ′, which is another message format of Table 2.
  • Type SKeyReq E Specifies the Key Request message. Contains the following attributes: KeyReqid EntityAddress Tag Version Time Contains the following elements: GlobalServiceID SKeyReqid A M 1 Identifier of Key Request Message unsignedInt(32 bits) EntityAddress A M 1 Network Entity Address to receive the anyURI response of this message. Tag A O 0 . . . 1 Identifier for the message type defined in unsignedByte section x.x Version A O 0 . . . 1 BCAST enabler version supported by this String message. Time A O 0 . . . 1 The time when this message is sent. NTP Integer time format SHALL be used for this field. GlobalServiceID E1 M 1 . . . N Identifier of the service to be encrypted anyURI
  • Table 10 provides a definition of a Response Message Format Res- 1 ′, which is another message format of Table 3.
  • Type SKRRes E Specifies the Response message of Key Request message. Contains the following attributes: Tag Version Time Contains the following elements: KeyReqid Tag A O 0 . . . 1 Identifier for the message type defined in unsignedByte section x.x Version A O 0 . . . 1 BCAST enabler version supported by this String message. Time A O 0 . . . 1 The time when this message is sent. NTP Integer time format SHALL be used for this field. SKeyReqid E1 M 1 . . .
  • Table 11 provides a definition of a Delivery Message Format Tra- 1 ′, which is another message format of Table 5.
  • Table 12 provides a definition of a Confirm Message Format Con- 1 ′, which is another message format of Table 6.
  • FIG. 5 is a signaling diagram illustrating a BCAST service protection method using the first or the second embodiment of the present invention. This shows a procedure for transmitting an encrypted service using the embodiment of FIG. 2 or FIG. 3 , wherein a content encryption process for content protection is optional. Therefore, a description of the content encryption will be omitted herein.
  • a Terminal 50 accesses, via an Interaction Network 70 , a BSM 40 that manages subscription information and BCAST service provisioning information of a subscriber for receipt of a BCAST service, and performs a registration procedure for BCAST service subscription and reception.
  • the Terminal 50 acquires in step 503 an LTKM including therein an SEK (or Program Encryption Key (PEK) and an SAK (or Program Authentication Key (PAK), from the BSM 40 .
  • the LTKM is used in a process where the Terminal 50 deciphers the encrypted broadcast service.
  • the SEK/SAK are keys used for encryption/digital signature for a service
  • the PEK/PAK are keys used for encryption/digital signature for a program.
  • the service can be considered as a set of contents
  • the program can be considered as one content.
  • a BSD/A 30 In step 505 , a BSD/A 30 generates a TEK used when the Terminal 50 deciphers the encrypted service.
  • the BSD/A 30 sends the generated TEK to the BSM 40 .
  • the BSM 40 directly generates the TEK, the TEK generation procedure can be omitted.
  • the BSD/A 30 when it directly generates the TEK, transmits a partially created STKM including the TEK but not including a MAC, to the BSM 40 .
  • the partially created STKM includes other information necessary for generation of the STKM.
  • the BSM 40 encrypts the TEK with its SEK/PEK, and generates a completed STKM by performing digital signature processing on the partially created STKM with the TEK using the SAK/PAK.
  • a public/private key scheme as RSA, or MAC function processing can be used as the digital signature processing.
  • the BSD/A 30 and the BSM 40 can exchange an STKM Delivery Message or an STKM Request Message, for an exchange of the partially created STKM.
  • the completed STKM is delivered to the BSD/A 30 .
  • the B SD/A 30 can transmit the partially created STKM with the TEK to the BSM 40 .
  • the BSD/A 30 sends the information necessary for STKM generation, like the TEK, using several fields of the message, the BSM 40 can generate the STKM using the associated information including the TEK.
  • step 509 the BSD/A 30 transmits the completed STKM to the Terminal 50 .
  • a CC 10 delivers the content being broadcasted to the subscriber, to the BSD/A 30 , and upon receipt of the content, the B SD/A 30 encrypts the service being provided to the Terminal 50 using the TEK in step 513 , and transmits the encrypted service to the Terminal 50 via a Broadcast Network 60 in step 515 .
  • the Terminal 50 can obtain the TEK used for deciphering the broadcast service by deciphering the STKM acquired in step 509 using the SEK/PEK and the SAK/PAK acquired through the registration and LTKM reception procedures of steps 501 and 503 , and can decipher the encrypted service using the TEK, thereby reproducing the service.
  • the foregoing procedure as described in the embodiment of FIG. 3 , can also be applied to a procedure for transmitting a plurality of STKMs for one program/service.
  • FIG. 6 illustrates a BCAST service protection method using the third embodiment of the present invention. This shows a procedure for transmitting an encrypted service using the embodiment of FIG. 4 .
  • a BSD/A 30 exclusively generates the TEK, and delivers SEK/PEK and SAK/PAK for service encryption and authentication to a BSD/A 30 so that the BSD/A 30 can perform MAC processing on the STKM.
  • steps 601 and 603 in which a Terminal 50 accesses a BSM 40 , performs a registration procedure for service subscription and reception, and receives an LTKM with SEK/PEK and SAK/PAK is to the same as the operation of steps 501 and 503 of FIG. 5 , so a detailed description thereof will be omitted.
  • step 605 the BSM 40 delivers its own SEK/PEK and SAK/PAK to the BSD/A 30 .
  • step 607 the BSD/A 30 generates a partially created STKM using its generated TEK and other information, and finally performs digital signature processing thereon with the SAK/PAK, thereby generating a completed STKM.
  • a public/private key scheme as RSA, or MAC function processing can be used as the digital signature processing.
  • steps 607 to 613 in which the BSD/A 30 sends the completed STKM to the Terminal 50 and broadcasts the service encrypted with the TEK is to the same as the operation of steps 509 to 515 of FIG. 5 .
  • the Terminal 50 can acquire the TEK through the STKM, and decipher the encrypted service using the TEK, thereby reproducing the service.
  • the foregoing procedure, as described in the embodiment of FIG. 3 can also be applied to a procedure for transmitting a plurality of STKMs for one program/service.
  • FIGS. 7 to 10 a description will now be made of a message-handling scheme between components constituting the entities in the broadcast architecture based on FIGS. 5 and 6 .
  • the description of FIGS. 7 to 10 will be made with reference to an example to which the methods presented in FIGS. 2 and 3 are applied. However, it would be obvious to those skilled in the art that the following description of FIGS. 7 to 10 is not limited to FIGS. 2 and 3 , and can also be applied to the method presented in FIG. 4 .
  • a registration process and an LTKM reception process are performed in a network supporting interaction channels in FIGS. 7 to 10 , they can also be applied to a network supporting broadcast channels.
  • the broadcast architecture can be divided into broadcast service protection architecture and broadcast content protection architecture, and a difference between them is as follows.
  • the broadcast content protection architecture can support right management for the transmission content.
  • the broadcast service protection architecture has no right management function.
  • FIG. 7 illustrates a process performed during operation of a BCAST Digital Radio MusiceTM (DRMTM) profile in the broadcast service protection architecture presented in FIGS. 2 and 3 .
  • DRMTM Digital Radio MusiceTM
  • the DRMTM profile is a broadcast DRMTM standard made for the broadcast environment in which the DRMTM v2.0 standard defined in the OMA working group can be used.
  • a Terminal 50 accesses, via an Interaction Network 70 , an Service Protection-Management (SP-M) component 41 in a BSM 40 that manages subscription information of a subscriber for receipt of a BCAST service, and performs a registration procedure for subscription to and reception of the BCAST service.
  • SP-M Service Protection-Management
  • the Terminal 50 acquires in step 703 an LTKM including therein SEK/SAK or PEK/PAK, from a Content Protection-Management (CP-M) component 42 in the BSM 40 .
  • SEK/SAK are keys used for encryption/digital signature for a service
  • PEK/PAK are keys used for encryption/digital signature for a program.
  • the service can be considered as a set of contents
  • the program can be considered as one content.
  • An Service Protection-Key Distribution (SP-KD) component 33 in a BSD/A 30 generates in step 705 a TEK used when the Terminal 50 deciphers an encrypted service. Thereafter, the SP-KD component 33 in the BSD/A 30 sends in step 707 the generated TEK along with other parameters necessary for STKM generation (e.g. encryption method, information related to the encryption method, protocol version and time information), to the SP-M component 41 in the BSM 40 .
  • other parameters necessary for STKM generation e.g. encryption method, information related to the encryption method, protocol version and time information
  • the SP-M component 41 in the BSM 40 encrypts the TEK with its own SEK and PEK, and performs digital signature processing on the STKM created with the other parameters including the encrypted TEK using the SAK and the PAK, thereby generating a completed STKM.
  • a public/private key scheme as RSA, or MAC function processing can be used as the digital signature processing.
  • the BSD/A 30 and the BSM 40 can exchange an STKM Delivery Message or an STKM Request Message, for an exchange of the TEK and several parameters necessary for STKM generation. A description of this process has been made above.
  • the SP-M component 41 in the BSM 40 delivers the STKM completed through the above process, to an File Distribution/Stream Distribution (FD/SD) component 32 in the BSD/A 30 .
  • FD/SD File Distribution/Stream Distribution
  • step 711 the SP-KD component 33 in the BSD/A 30 sends the generated TEK to an Service Protection-Encryption (SP-E) component 31 in the BSD/A 30 .
  • SP-E Service Protection-Encryption
  • the SP-E component 31 controls encrypting the received service, which corresponds to step 717 of FIG. 7 .
  • a CC 10 delivers the content to an File Application /Stream Application (FA/SA) component 21 in a BSA 20 .
  • FA/SA File Application /Stream Application
  • the FA/SA component 21 in the BSA 20 converts in step 715 the received content into a service and delivers it to the SP-E component 31 in the BSD/A 30 .
  • the SP-E component 31 in the BSD/A 30 performs the foregoing encryption, and then delivers in step 719 the encrypted service to the FD/SD component 32 in the BSD/A 30 .
  • step 721 the FD/SD component 32 sends the completed STKM to the Terminal 50 , and then in step 723 , delivers the encrypted service up to the Terminal 50 . In this manner, it is possible to provide the encrypted service to the terminal.
  • FIG. 8 illustrates a process performed during operation of a BCAST smartcard profile in the broadcast service protection architecture presented in FIGS. 2 and 3 .
  • FIG. 8 The process of FIG. 8 is almost similar to the process of FIG. 7 . Therefore, references will be made to their associated processes, and only the different processes will be described below.
  • a registration process in step 801 is the same as the process of FIG. 7 .
  • an entity for receiving an LTKM is a smartcard 51 included in a Terminal 50 , unlike that in FIG. 7 .
  • the other steps 805 to 819 are to the same as steps 705 to 719 described in FIG. 7 .
  • an STKM is delivered in step 821 to the smartcard 51 in the Terminal 50 and a TEK is delivered to the Terminal 50 and then used for deciphering, in order to decipher the encrypted service.
  • a process of transmitting the encrypted service in step 823 is to the same as the process of step 723 . Therefore, the smartcard 51 included in the Terminal 50 can receive and process the encrypted service in the manner described in FIG. 8 .
  • FIG. 9 illustrates a process performed during operation of a BCAST DRM profile in the broadcast content protection architecture presented in FIGS. 2 and 3 .
  • FIG. 9 is also similar to the process of FIG. 7 .
  • FIG. 9 is different from FIG. 7 in that it operates based on the broadcast content protection architecture.
  • Components in the content protection architecture are the same in function to components in the service protection architecture, but a CP-M component 42 in a BSM 40 can generate a Rights Object that can be used for performing right management. That is, in FIG. 9 , unlike in FIG. 7 , an SP-M component 41 in a BSM 40 is replaced with a CP-M component 42 , and the CP-M component 42 can generate a Rights Object that can be used for performing right management.
  • FIG. 10 illustrates a process performed during operation of a BCAST smartcard profile in the broadcast content protection architecture presented in FIGS. 2 and 3 .
  • FIG. 10 The process of FIG. 10 is similar to the process of FIG. 8 except that FIG. 10 operates based on the content protection architecture, like FIG. 9 . Therefore, a difference between FIGS. 10 and 8 is to the same as the difference between FIGS. 7 and 9 . That is, components in the content protection architecture are similar in function to components in the service protection architecture, but a CP-M component 42 in a BSM 40 can generate a Rights Object that can be used for performing right management. That is, in FIG. 10 , unlike in FIG. 8 , an SP-M component 41 in the BSM 40 is replaced with the CP-M component 42 which can generate a Rights Object that can be used for performing right management.
  • FIG. 11 illustrates a process in which the methods described in FIGS. 2 and 3 interwork with broadcast service and content protection methods.
  • an FD/SD component 32 in a BSD/A 30 is used in a process of transmitting an STKM in the embodiment of FIG. 7
  • the FD/SD component 32 is not used in the embodiment of FIG. 11 .
  • a Terminal 50 performs a registration procedure for subscription to and reception of a BCAST service with an SP-M component 41 in a BSM 40 , and performs an operation of receiving an LTKM including therein SEK/SAK or PEK/PAK from the SP-M component 41 , and the SP-KD component 33 in the BSD/A 30 performs an operation of generating a TEK and then transmitting the generated TEK and other parameters necessary for STKM generation (e.g. encryption method, information related to the encryption method, protocol version and time information), to the SP-M component 41 in the BSM 40 .
  • parameters necessary for STKM generation e.g. encryption method, information related to the encryption method, protocol version and time information
  • the SP-M component 41 in the BSM 40 generates in step 1109 a completed STKM by performing digital signature processing on the STKM using the service/program authentication keys SAK/PAK, and transmits the generated STKM to the SP-KD component 33 in the BSD/A 30 .
  • a public/private key scheme as RSA, or MAC function processing can be used as the digital signature processing.
  • the SP-KD component 33 in the BSD/A 30 transmits the TEK generated in step 1105 to the SP-E component 31 in the BSD/A 30 .
  • the SP-E component 31 controls encryption of the received service.
  • steps 1113 to 1117 An operation in steps 1113 to 1117 is the same as the operation in steps 713 to 717 of FIG. 7 .
  • a CC 10 delivers content to an FA/SA component 21 in a BSA 20
  • the FA/SA component 21 converts the received content into a service and delivers the service to the SP-E component 31 in the BSD/A 30
  • the SP-E component 31 encrypts the service. If the service encryption is completed in this manner, the SP-KD component 33 in the BSD/A 30 sends in step 1119 an STKM including the TEK used for deciphering the encrypted service/content, received from the SP-M component 41 in step 1109 , to the Terminal 50 .
  • the SP-E component 31 in the BSD/A 30 delivers the encrypted service to the Terminal 50 which deciphers the encrypted service using the STKM received in step 1119 .
  • the Terminal 50 receives the encrypted service in the embodiment of FIG. 11 , it can also receive encrypted content.
  • FIG. 12 illustrates a process in which the method described in FIG. 4 interworks with broadcast service and content protection methods.
  • An embodiment of FIG. 12 is to the same as the embodiment of FIG. 11 except for the process of generating an STKM.
  • an SP-M component 41 in a BSM 40 sends in step 1207 an SEAK including therein SEK and SAK as keys used for encryption/digital signature for a service and/or a PEAK including therein PEK and PAK as keys used for encryption/digital signature for a program, to an SP-KD component 33 in a BSD/A 30 .
  • the SP-KD component 33 generates a completed STKM by performing digital signature processing thereon using service/program authentication keys SAK/PAK, and delivers in step 1219 the generated STKM to the Terminal 50 .
  • operations in steps 1201 to 1205 and steps 1211 to 1221 are to the same as the operations in steps 1101 to 1105 and steps 1111 to 1121 of FIG. 11 , so a detailed description thereof will be omitted.
  • FIGS. 11 and 12 operations of components in the service protection architecture can also be performed in the same manner.
  • the process of performing service registration on the Terminal 50 and receiving an LTKM can be achieved between the smartcard 51 and the SP-M component 41 or the CP-M component 42 , and the STKM can be delivered to the smartcard 51 where the TEK can be acquired from the received STKM.
  • the STKM delivery methods presented in FIGS. 2 and 3 can also be applied to the embodiments of FIGS. 11 and 12 .
  • the present invention provides a detailed TEK/STKM generation method and a detailed BCAST service protection method for transmitting/receiving encrypted service, between network entities in a mobile broadcast system, thereby enabling safe delivery of the broadcast service/content.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

A system and method are provided for generating a Short Term Key Message (STKM) for protection of a broadcast service being broadcasted to a terminal in a mobile broadcast system. The method includes transmitting, by a Broadcast Service Subscription Management (BSM) for managing subscription information, at least one key information for authentication of the broadcast service to a Broadcast Service Distribution/Adaptation (BSD/A) for transmitting the broadcast service, generating, by the BSD/A, a Traffic Encryption Key (TEK) for deciphering of the broadcast service in the terminal and inserting the TEK into a partially created STKM, and performing, by the BSD/A, Message Authentication Code (MAC) processing on the TEK-inserted STKM using the at least one key information, thereby generating a completed STKM.

Description

PRIORITY
This application is a Continuation Application of U.S. application Ser. No. 11/711,499 filed in the U.S. Patent and Trademark Office on Feb. 27, 2007 and claims priority to applications filed in the Korean Intellectual Property Office on Feb. 27, 2006 and assigned Serial No. 2006-18849, on May 29, 2006 and assigned Serial No. 2006-48168, on Jul. 6, 2006 and assigned Serial No. 2006-63652, and on Mar. 24, 2006 and assigned Serial No. 2006-27184, the content of each of which is incorporated herein by reference.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to a broadcast service method in a mobile broadcast system and a system thereof, and in particular, to a method and system for protecting broadcast service/content between network entities constituting a broadcast system and a method for generating encryption keys and messages using the same.
2. Description of the Related Art
The mobile communication market constantly incurs the need for new services by combining or integrating the existing technologies. Today, the conventional mobile communication system has been developed to provide broadcast services through portable terminals (or mobile terminals) such as a mobile phone and Personal Digital Assistant (PDA). Convergence of mobile communication service and Internet Protocol (IP) technology is now the mainstream of the next generation mobile communication technology due to market needs, the increasing user demand for multimedia services, the strategy of the service providers for providing new services such as broadcast service in addition to the existing voice service, and the interests of Information Technology (IT) companies that are reinforcing their mobile communication business to meet the user demands.
Open Mobile Alliance (OMA), which is a group for studying the standard for interworking between individual mobile solutions, establishes various application standards for features such as mobile games and Internet service. In particular, OMA Browser And Content (BAC) Mobile Broadcast (BCAST) Sub Working Group, one of the OMA working groups, is studying the technology for providing broadcast services using mobile terminals. A brief description will now be made of a mobile broadcast system being discussed in OMA BCAST Working Group.
FIG. 1 is a block diagram illustrating network architecture of a conventional mobile broadcast system.
Referring to FIG. 1, a Content Creation (CC) 10 is a broadcast service (hereinafter BCAST service) provider, and the BCAST service can include the conventional audio/video broadcast service and file (music or data file) download service. A BCAST Service Application (BSA) 20 generates BCAST service data by processing BCAST service data provided from the CC 10 into the form suitable for the BCAST network of FIG. 1, and also generates standardized metadata necessary for a mobile broadcast guide.
A BCAST Service Distribution/Adaptation (BSD/A) 30 sets up a bearer over which it will transmit the BCAST service data provided from the BSA 20, determines transmission schedules of the BCAST services, and generates a mobile broadcast guide. A BCAST Subscription Management (BSM) 40 manages subscription information and BCAST service provisioning information for receipt of the BCAST service, and device information for a mobile terminal receiving the BCAST service.
A Terminal 50 is capable of receiving the BCAST service, and has a function capable of connecting with a cellular network according to terminal capability. Herein, the Terminal 50 is assumed to be connectable with the cellular network. A Broadcast Network 60 is for transmitting the BCAST service, and can be for Digital Video Broadcasting—Handheld (DVB-H), 3GPP Multimedia Broadcast and Multicast Services (MBMS) and 3GPP2 Broadcast and Multicast Services (BCMCS), for example. An Interaction Network 70 is for transmitting the BCAST service on a point-to-point basis, or interactively exchanging control information and additional information related to the receipt of the BCAST service, and can be, for example, the existing cellular network.
In BCAST service, a plurality of mobile terminals receive encrypted service data transmitted by a server for managing broadcast services. The mobile terminals can use the corresponding service by deciphering the encrypted service data provided from the server using an encryption key previous stored therein. In this context, a method for encrypting broadcast content/service is roughly divided into service protection and content protection. Service protection indicates protection of a transmission channel between the BCAST Service Distribution/Adaptation (BSD/A) 30 and the Terminal 50, and content protection indicates end-to-end protection between the BSA 20 and the Terminal 50.
However, in the current mobile broadcast system, there is no detailed proposed scheme such as a method and procedure for generating and transmitting encryption keys and messages for encryption of broadcast service and/or content between the entities constituting a broadcast system, for the safe transmission of broadcast service and/or content. Therefore, a need exists for introduction of such a scheme.
SUMMARY OF THE INVENTION
An aspect of the present invention is to address at least the problems and/or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the present invention is to provide a method for protecting broadcast service and/or content in a mobile broadcast system, and a system thereof.
Another aspect of the present invention is to provide a method for generating encryption keys and messages for protecting broadcast service and/or content in a mobile broadcast system, and a system thereof.
A further aspect of the present invention is to provide a method for generating a Traffic Encryption Key (TEK) for protecting broadcast service and/or content, and a Short Term Key Message (STKM) in a mobile broadcast system, and a system thereof.
An additional aspect of the present invention is to provide a method for generating and transmitting encryption keys and messages between the entities constituting a broadcast system to protect broadcast service and/or content in a mobile broadcast system, and a system thereof.
Still another aspect of the present invention is to provide a method for configuring a broadcast system, and generating and transmitting messages between components thereof to protect broadcast service and/or content in a mobile broadcast system, and a system thereof.
According to the present invention, there is provided a method for generating an STKM for protection of a broadcast service being broadcasted to a terminal in a mobile broadcast system. The method includes transmitting, by a BSD/A for transmitting the broadcast service to the terminal, a partially created STKM before Message Authentication Code (MAC) processing, to a BSM for managing subscription information, inserting, by the BSM, a TEK for deciphering of the broadcast service into the partially created STKM, and performing, by the BSM, MAC processing on the TEK-inserted STKM, thereby generating a completed STKM.
According to the present invention, there is provided a method for generating an STKM for protection of a broadcast service being broadcasted to a terminal in a mobile broadcast system. The method includes transmitting, by a BSM for managing subscription information, at least one key information for authentication of the broadcast service to a BSD/A for transmitting the broadcast service, generating, by the BSD/A, a TEK for deciphering the broadcast service in the terminal and inserting the TEK into a partially created STKM, and performing, by the BSD/A, MAC processing on the TEK-inserted STKM using the at least one key information, thereby generating a completed STKM.
According to the present invention, there is provided a mobile broadcast system for transmitting an STKM for reception of a broadcast service to a terminal. The system includes a BSD/A for generating a partially created STKM before MAC processing, encrypting the broadcast service using a TEK, and broadcasting the encrypted broadcast service; and a BSM for managing subscription information of the terminal, inserting the TEK into the partially created STKM received from the BSD/A, generating a completed STKM by performing MAC processing on the TEK-inserted STKM, and transmitting the completed STKM to the BSD/A.
According to the present invention, there is provided a mobile broadcast system for transmitting a STKM for reception of a broadcast service to a terminal. The system includes a BSD/A for inserting a TEK of the broadcast service into a partially created STKM before MAC processing, and generating a completed STKM using at least one key information including authentication key; and a BSM for managing subscription information of the terminal, and transmitting the at least one key information to the BSD/A.
BRIEF DESCRIPTION OF THE DRAWINGS
The above 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:
FIG. 1 illustrates network architecture of a conventional mobile broadcast system;
FIG. 2 illustrates a BSM-based method for generating an encryption key and a short term key message according to a first embodiment of the present invention;
FIG. 3 illustrates a BSM-based method for generating a plurality of encryption keys and short term key messages according to a second embodiment of the present invention;
FIG. 4 illustrates a BSD/A-based method for generating an encryption key and a short term key message according to a third embodiment of the present invention;
FIG. 5 illustrates a BCAST service protection method using the first or second embodiment of the present invention;
FIG. 6 illustrates a BCAST service protection method using the third embodiment of the present invention;
FIG. 7 illustrates a process performed during operation of a BCAST DRM profile in the broadcast service protection architecture presented in FIGS. 2 and 3;
FIG. 8 illustrates a process performed during operation of a BCAST smartcard profile in the broadcast service protection architecture presented in FIGS. 2 and 3;
FIG. 9 illustrates a process performed during operation of a BCAST DRM profile in the broadcast content protection architecture presented in FIGS. 2 and 3;
FIG. 10 illustrates a process performed during operation of a BCAST smartcard profile in the broadcast content protection architecture presented in FIGS. 2 and 3;
FIG. 11 illustrates a process in which the methods described in FIGS. 2 and 3 interwork with an STKM generation method in the broadcast service and content protection architecture; and
FIG. 12 illustrates a process in which the method described in FIG. 4 interworks with broadcast service and content protection architecture.
 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Preferred embodiments of the present invention will now be described in detail with reference to the annexed drawings. In the drawings, the same or similar elements are denoted by the same reference numerals even though they are depicted in different drawings. In the following description, a detailed description of known functions and configurations incorporated herein has been omitted for the sake of clarity and conciseness.
For convenience, a description of the present invention will be made herein using the names of the entities defined in the 3rd Generation Partnership Project (3GPP), which is the asynchronous mobile communication standard, or defined in the BCAST of the aforementioned OMA. However, the stated standards and entity names thereof are not intended to limit the scope of the present invention, and the present invention can be applied to any system having similar technical background.
A brief description will first be made of a basic method for performing service protection and content protection in a mobile broadcast system according to the present invention. The basic architecture of the mobile broadcast system, to which the present invention is applicable, is shown in FIG. 1, and the present invention will disclose service and content protection schemes therefor.
The content provided from a CC 10 for content protection is encrypted in a BSA 20 or a BSD/A 30, and then broadcasted to a Terminal 50. Unlike content protection, the BSD/A 30 for service protection performs encryption on a transmission channel over which the BCAST service is provided. A BSM 40 performs subscription management of a Terminal 50 for service protection and/or content protection.
Information related to encryption keys used for service protection and/or content protection and a method of using the same are as follows. In order to use the broadcast service/content provided from the broadcast system of FIG. 1, the Terminal 50 subscribes to the BSM 40 as a service subscriber, and then receives a Registration Key Material (RKM). Thereafter, the Terminal 50 can acquire a Long-Term Key Message (LKM) upon its subscription to the service, and then acquire a Short-Term Key Message (STKM) used for deciphering the encrypted service/content.
In addition, the Terminal 50 can decipher the LKM using the RKM, and acquires a Service Encryption Key (SEK) and a Service Authentication Key (SAK) as a result of the deciphering. The SEK and SAK are included in the LKM in the merged form called a Service Encryption Authentication Key (SEAK), and then delivered to the Terminal 50.
The STKM includes a TEK, and in order to protect the TEK, the STKM is encrypted by the SEAK and then a MAC function is applied thereto. Using the TEK deciphered by the SEAK, the Terminal 50 can decipher the encrypted service/content.
The service protected through the encryption keys is transmitted from the BSD/A 30 to the Terminal 50 as shown in FIG. 1, and the content protected by the encryption keys is transmitted from the BSA 20 to the Terminal 50.
Table 1 provides a definition of BCAST interfaces (BCAST-1 to BCAST-8) 100 to 160 shown in FIG. 1.
TABLE 1
Inter-
faces Function
BCAST-1 Content is delivered from CC to BSA.
BCAST-2 Content/Service are delivered from BSA to BSD/A.
BCAST-3 TEK for encrypting Content is delivered from BSM
to BSA.
BCAST-4 TEK, RKM, LKM, STKM, etc. are delivered from BSM
to BSD/A.
SG Data Request Message and its Response Message
are exchanged between BSD/A and BSM.
BCAST-5 Encrypted Service and Encrypted RKM, LKM, etc. are
delivered to Terminal
BCAST-7 RKM, LKM are transmitted from BSM to Terminal over
Interaction Channel.
BCAST-8 Out-of-Band Channel between Terminal and BSM
In Table 2 to Table 7, ‘Name’ indicates names of elements and attributes constituting the corresponding message. ‘Type’ indicates a type (Element or Attribute) of the corresponding name. The elements have values E1, E2, E3 and E4, wherein E1 indicates an upper element for the entire message, E2 indicates a sub-element of E1, E3 indicates a sub-element of E2, and E4 indicates a sub-element of E3. An attribute is denoted by A, and A indicates an attribute of the corresponding element. For example, A under E1 indicates an attribute of E1. ‘Category’ is used for determining whether the corresponding element or attribute is mandatory or optional, and has an M value for the mandatory element or attribute, and an O value for the optional element or attribute. ‘Cardinality’ indicates a relationship between elements, and has values 0, 0 . . . 1, 1, 0 . . . n, 1 . . . n. Herein, 0 indicates an optional relationship, 1 indicates a mandatory relationship, and n indicates that a plurality of values can be used. For example, 0 . . . n indicates that the corresponding message may have no element, or n elements. ‘Description’ indicates meaning of the corresponding element or attribute, and ‘Data Type’ indicates a data type for the corresponding element or attribute.
Table 2 to Table 7 show field formats of the messages defined in the present invention, and a description of each field of the messages is given in the corresponding table. In addition, Table 8 shows the possible situations to which the messages can be applied. An encryption key and a message used herein for encryption of service/content will be referred to as a TEK and an STKM, respectively.
Table 2 provides a definition of a Request Message Format Req-1.
TABLE 2
Name Type Category Cardinality Description Data Type
Tag E M 1 Type of Message Integer
Version E O 1 Version of Standard Technology Integer
Supported by this Message
Message ID E M 1 ID of this Message String
Destination E M 1 Message Destination ID String
Source E M 1 Message Source ID String
Service/Content E M 1 Related Information such as String
Info. corresponding Service/Content ID
Option E O 1 Designation of Single STKM or Integer
multiple STKMs
Time E O 1 Message transmitted Time String
Table 3 provides a definition of a Response Message Format Res-1.
TABLE 3
Name Type Category Cardinality Description Data Type
Tag E M 1 Type of Message Integer
Version E O 1 Version of Standard Technology Integer
Supported by this Message
Message ID E M 1 ID of Request Message String
Destination E M 1 Message Destination ID String
Source E M 1 Message Source ID String
Service/Content E O 1 Related Information such as String
Info. corresponding Service/Content ID
Status E M 1 Response Result of Message Integer
Data E O 1 Desired Information to be delivered to Binary
Destination
Time E O 1 Message transmitted Time String
Table 4 provides a definition of a Response Message Format Res-2.
TABLE 4
Name Type Category Cardinality Description Data Type
Tag E M 1 Type of Message Integer
Message ID E M 1 ID of Request Message String
Status E M 1 Response Result of Message Integer
Data E O 1 Desired Information to be delivered to Binary
Destination
Table 5 provides a definition of a Delivery Message Format Tra-1.
TABLE 5
Name Type Category Cardinality Description Data Type
Tag E M 1 Type of Message Integer
Version E O 1 Version of Standard Technology Integer
Supported by this Message
Message ID E M 1 ID of this Message String
Destination E M 1 Message Destination ID String
Source E M 1 Message Source ID String
Service/Content E M 1 Related Information such as String
Info. corresponding Service/Content ID
Data E M 1 Desired Information to be delivered to Binary
Destination
Option E O 1 Designation of Single STKM or Integer
multiple STKMs
Time E O 1 Message transmitted Time String
Table 6 provides a definition of a Confirm Message Format Con-1.
TABLE 6
Name Type Category Cardinality Description Data Type
Tag E M 1 Type of Message Integer
Version E O 1 Version of Standard Technology Integer
Supported by this Message
Message ID E M 1 ID of Delivery Message String
Destination E M 1 Message Destination ID String
Source E M 1 Message Source ID String
Service/Content E O 1 Related Information such as String
Info. corresponding Service/Content ID
Status E M 1 Confirmation Result of Message Integer
Time E O 1 Message transmitted Time String
Table 7 provides a definition of a Confirm Message Format Con-2.
TABLE 7
Name Type Category Cardinality Description Data Type
Tag E M 1 Type of Message Integer
Message ID E M 1 ID of Delivery Message String
Status E M 1 Confirmation Result of Message Integer
Table 8 shows message types identified using ‘Tag’ defined in the message formats of Table 2 to Table 7. The ‘Tag’ values defined below are not always fixed, but simply indicate the message types, and they are subject to change according to circumstances. Generally, in the Response Message and the Confirm Message, Status=‘0’ indicates that a corresponding entity has successfully received the request and delivery messages and has performed the associated event, and Status=‘1’ indicates that the corresponding entity has failed in receiving the request and delivery messages and thus has failed in performing the associated event.
In Table 2 to Table 7, an ‘Option’ field is used for indicating whether a single STKM is requested or multiple STKMs are requested. Herein, Option=‘0’ indicates that a single STKM is requested, and Option=‘1’ indicates that multiple STKMs, i.e. all STKMs for the corresponding content (program), are requested. In addition, Option=‘2’ indicates that all STKMs for one service are requested.
In addition, Table 8 shows message types and applied message types according to ‘Tag’ value, and the messages can obtain performance improvement with use of the shortened message Res-2 or Con-2 with a message ID, shown in ‘Applied Message Type’.
TABLE 8
Deliv-
Applied ered In-
Tag Message Type Message Type formation
5 STKM Request Message Req-1 STKM
6 STKM Request Response Message Res-1 or Res-2
7 STKM Delivery Message Tra-1
8 STKM Delivery Confirm Message Con-1 or Con -2
17 SEAK Request Message Req-1 SEAK
18 SEAK Request Response Message Res-1 or Res-2
19 SEAK Delivery Message Tra-1
20 SEAK Delivery Confirm Message Con-1 or Con -2
FIG. 2 is a signaling diagram illustrating a BSM-based method for generating an encryption key and a short term key message according to a first embodiment of the present invention, wherein a TEK is generated as the encryption key and an STKM is generated as the short term key message. The STKM is a message generated in a BSM 40 so that a subscriber may acquire an LKM through subscription to the service and then acquire a TEK with which it can decipher broadcast service and/or content.
In the TEK and STKM generation method presented in the first embodiment of the present invention, the BSM 40 directly generates the TEK and the STKM, but a BSD/A 30 also partially participates in the STKM generation process. In generating the STKM, the BSD/A 30 does not create a TEK part, and a MAC part of the STKM.
Referring to FIG. 2, in step 201, the BSD/A 30 delivers a partially created STKM, i.e. STKM without TEK and MAC, to the BSM 40. To this end, though not shown in FIG. 2, the BSM 40 can send the Req-1 of Table 2 to the BSD/A 30 as an STKM Request Message. Upon receipt of the STKM Request Message, the BSD/A 30 can send the Res-1 of Table 3 or the Res-2 of Table 4 as a STKM Request Response Message to the BSM 40 that transmitted the partially created STKM.
As another example, the BSD/A 30 can directly send the partially created STKM using the Tra-1 defined in Table 5 as an STKM Delivery Message without a request of the BSM 40. In this case, upon receipt of the STKM Delivery Message, the BSM 40 sends the Con-1 defined in Table 6 or Con-2 defined in Table 7 as an STKM Delivery Confirm Message indicating receipt of the STKM, to the BSD/A 30 in response thereto.
In step 203, the BSM 40 generates a TEK after receiving the partially created STKM. In addition, the BSM 40 encrypts the generated TEK with an SEK and inserts it into the STKM, and also performs MAC function processing on the STKM using an SAK and generates a completed STKM by inserting the processing result value into the STKM. The completed STKM is sent from the BSM 40 to the B SD/A 30.
FIG. 3 illustrates a BSM-based method for generating a plurality of encryption keys and short term key messages according to a second embodiment of the present invention, wherein a plurality of TEKs and STKMs are generated for one content (program)/service.
Referring to FIG. 3, in step 301, a BSD/A 30 sends a plurality of partially created STKMs for one content (program) or one service to a BSM 40. In step 303, the BSM 40 delivers a plurality of STKMs completed for one content (program) or one service to the BSD/A 30. Therefore, in the method of FIG. 3, although it is similar to the method disclosed in FIG. 2, the BSM 40 sends a plurality of STKMs generated for one content (program) or one service, instead of sending one completed STKM. In this case, in the Req-1 defined in Table 2 as an STKM Request Message, a value of an Option field should be ‘1’ or ‘2’ indicating transmission of a plurality of STKMs. In addition, as described in another example of FIG. 2, even when the BSD/A 30 directly sends the partially created STKM using the Tra-1 defined in Table 5 as an STKM Delivery Message to the BSM 40, a value of its Option field should be designated as ‘1’ or ‘2’ indicating transmission of a plurality of STKMs.
Although the BSM 40 generates the TEK in the embodiments of FIGS. 2 and 3, the BSD/A 30 rather than the BSM 40 can generate the TEK, insert it into the partially created STKM together with partial information, and deliver it to the BSM 40. In this case, the BSM 40 encrypts the TEK with a SEK, inserts it back into the STKM without a MAC, received from the BSD/A 30, performs MAC function processing thereon with a SAK and resends the completed STKM to the B SD/A 30.
In addition, the BSD/A 30 can send the partially created STKM with a TEK to the BSM 40. In an alternative method, however, if the BSD/A 30 sends information necessary for STKM generation, like the TEK, using several fields of the message, then the BSM 40 can generate an STKM by extracting the associated information including the TEK from the corresponding message.
FIG. 4 illustrates a BSD/A-based method for generating an encryption key and a short term key message according to a third embodiment of the present invention, wherein a TEK is generated as the encryption key and an STKM is generated as the short term key message.
In FIG. 4, a BSD/A 30 exclusively generates the TEK and the STKM. To this end, in step 401, a BSM 40 delivers an SEK and an SAK for service encryption and authentication to the BSD/A 30 so that the BSD/A 30 can perform MAC processing on the STKM. Upon receipt of the SEK and the SAK, the B SD/A 30 encrypts in step 403 the TEK using the SEK, inserts it into the partially created STKM, and performs MAC function processing on the TEK-inserted STKM with a SAK, thereby generating a completed STKM. In addition, the B SD/A 30 transmits the generated STKM to a Terminal 50.
The BSD/A 30, although not shown in FIG. 4, can send the Req-1 defined in Table 2 as an SEAK Request Message for requesting transmission of the SEK and the SAK to the BSM 40. Upon receipt of the SEK and the SAK, the BSM 40 can send the Res-1 defined Table 3 or the Res-2 defined in Table 4 as an. SEAK Response Message to the BSD/A 30 in response thereto.
As another example, the BSM 40 can directly transmit the SEK and the SAK by sending the Tra-1 defined in Table 5 as a SEAK Delivery Message to the BSD/A 30 even when there is no transmission request for SEK and SAK from the BSD/A 30. Upon receipt of the SEAK Delivery Message, the BSD/A 30 can send the Con-1 defined in Table 6 or the Con-2 defined in Table 7 as a Delivery Confirm Message to the BSM 40. Although the merged SEAK of the SEK and the SAK can be exchanged between the BSM 40 and the BSD/A 30 in the method disclosed in FIG. 4, the SEK and the SAK can also be transmitted separately.
The message formats of Table 2 to Table 6 disclosed in the present invention can also be defined as message formats shown in Table 9 to Table 12.
Table 9 provides a definition of a Request Message Format Req-1′, which is another message format of Table 2.
TABLE 9
Name Type Category Cardinality Description Data Type
SKeyReq E Specifies the Key Request message.
Contains the following attributes:
KeyReqid
EntityAddress
Tag
Version
Time
Contains the following elements:
GlobalServiceID
SKeyReqid A M 1 Identifier of Key Request Message unsignedInt(32
bits)
EntityAddress A M 1 Network Entity Address to receive the anyURI
response of this message.
Tag A O 0 . . . 1 Identifier for the message type defined in unsignedByte
section x.x
Version A O 0 . . . 1 BCAST enabler version supported by this String
message.
Time A O 0 . . . 1 The time when this message is sent. NTP Integer
time format SHALL be used for this field.
GlobalServiceID E1 M 1 . . . N Identifier of the service to be encrypted anyURI
Table 10 provides a definition of a Response Message Format Res-1′, which is another message format of Table 3.
TABLE 10
Name Type Category Cardinality Description Data Type
SKRRes E Specifies the Response message of Key
Request message.
Contains the following attributes:
Tag
Version
Time
Contains the following elements:
KeyReqid
Tag A O 0 . . . 1 Identifier for the message type defined in unsignedByte
section x.x
Version A O 0 . . . 1 BCAST enabler version supported by this String
message.
Time A O 0 . . . 1 The time when this message is sent. NTP Integer
time format SHALL be used for this field.
SKeyReqid E1 M 1 . . . N Identifier of Key Request Message unsignedInt(32
Contains the following attributes: bits)
StatusCode
StatusCode A M 1 The overall outcome of the request, unsignedByte
according to the Global Status Codes
defined in Appendix D.
GlobalServiceID E2 O 0 . . . N Identifier of the service to be encrypted anyURI
Contains the following attributes:
Data
Data A M 1 TEK related to GlobalServiceID String
Table 11 provides a definition of a Delivery Message Format Tra-1′, which is another message format of Table 5.
TABLE 11
Name Type Category Cardinality Description Data Type
SKeyDelivery E Specifies the Key Delivery message.
Contains the following attributes:
KeyDelivery
EntityAddress
Tag
Version
Time
Contains the following elements:
GlobalServiceID
SKeyDeliveryid A M 1 Identifier of Key Request Message unsignedInt(32
bits)
EntityAddress A M 1 Network Entity Address to receive the anyURI
response of this message.
Tag A O 0 . . . 1 Identifier for the message type defined in unsignedByte
section x.x
Version A O 0 . . . 1 BCAST enabler version supported by this String
message.
Time A O 0 . . . 1 The time when this message is sent. NTP Integer
time format SHALL be used for this field.
GlobalServiceID E2 M 1 . . . N Identifier of the service to be encrypted anyURI
Contains the following attributes:
Data
Data A M 1 TEK related to GlobalServiceID String
Table 12 provides a definition of a Confirm Message Format Con-1′, which is another message format of Table 6.
TABLE 12
Name Type Category Cardinality Description Data Type
SKDRes E Specifies the Confirmation message of Key
Delivery message.
Contains the following attributes:
Tag
Version
Time
Contains the following elements:
KeyDeliveryid
Tag A O 0 . . . 1 Identifier for the message type defined in unsignedByte
section x.x
Version A O 0 . . . 1 BCAST enabler version supported by this String
message.
Time A O 0 . . . 1 The time when this message is sent. NTP Integer
time format SHALL be used for this field.
SKeyDeliveryid E1 M 1 . . . N Identifier of Key Delivery Message UnsignedInt
Contains the following attributes: (32 bits)
StatusCode
StatusCode A M 1 The overall outcome of the request, unsignedByte
according to the Global Status Codes defined
in Appendix D.
With reference to FIGS. 5 and 6, a description will now be made of an example in which the disclosed STKM generation methods described in FIGS. 2 to 4 are applied to a BCAST service protection method.
FIG. 5 is a signaling diagram illustrating a BCAST service protection method using the first or the second embodiment of the present invention. This shows a procedure for transmitting an encrypted service using the embodiment of FIG. 2 or FIG. 3, wherein a content encryption process for content protection is optional. Therefore, a description of the content encryption will be omitted herein.
Referring to FIG. 5, in step 501, a Terminal 50 accesses, via an Interaction Network 70, a BSM 40 that manages subscription information and BCAST service provisioning information of a subscriber for receipt of a BCAST service, and performs a registration procedure for BCAST service subscription and reception. After performing the registration procedure, the Terminal 50 acquires in step 503 an LTKM including therein an SEK (or Program Encryption Key (PEK) and an SAK (or Program Authentication Key (PAK), from the BSM 40. The LTKM is used in a process where the Terminal 50 deciphers the encrypted broadcast service. Herein, the SEK/SAK are keys used for encryption/digital signature for a service, and the PEK/PAK are keys used for encryption/digital signature for a program. The service can be considered as a set of contents, and the program can be considered as one content.
In step 505, a BSD/A 30 generates a TEK used when the Terminal 50 deciphers the encrypted service. The BSD/A 30 sends the generated TEK to the BSM 40. When the BSM 40 directly generates the TEK, the TEK generation procedure can be omitted.
In step 507, the BSD/A 30, when it directly generates the TEK, transmits a partially created STKM including the TEK but not including a MAC, to the BSM 40. The partially created STKM includes other information necessary for generation of the STKM. Upon receipt of the partially created STKM, the BSM 40 encrypts the TEK with its SEK/PEK, and generates a completed STKM by performing digital signature processing on the partially created STKM with the TEK using the SAK/PAK. Herein, a public/private key scheme as RSA, or MAC function processing can be used as the digital signature processing. In step 507, the BSD/A 30 and the BSM 40 can exchange an STKM Delivery Message or an STKM Request Message, for an exchange of the partially created STKM. The completed STKM is delivered to the BSD/A 30.
In addition, the B SD/A 30 can transmit the partially created STKM with the TEK to the BSM 40. In an alternative method, however, if the BSD/A 30 sends the information necessary for STKM generation, like the TEK, using several fields of the message, the BSM 40 can generate the STKM using the associated information including the TEK.
In step 509, the BSD/A 30 transmits the completed STKM to the Terminal 50. In step 511, a CC 10 delivers the content being broadcasted to the subscriber, to the BSD/A 30, and upon receipt of the content, the B SD/A 30 encrypts the service being provided to the Terminal 50 using the TEK in step 513, and transmits the encrypted service to the Terminal 50 via a Broadcast Network 60 in step 515.
Thereafter, the Terminal 50 can obtain the TEK used for deciphering the broadcast service by deciphering the STKM acquired in step 509 using the SEK/PEK and the SAK/PAK acquired through the registration and LTKM reception procedures of steps 501 and 503, and can decipher the encrypted service using the TEK, thereby reproducing the service. The foregoing procedure, as described in the embodiment of FIG. 3, can also be applied to a procedure for transmitting a plurality of STKMs for one program/service.
FIG. 6 illustrates a BCAST service protection method using the third embodiment of the present invention. This shows a procedure for transmitting an encrypted service using the embodiment of FIG. 4. In this embodiment, a BSD/A 30 exclusively generates the TEK, and delivers SEK/PEK and SAK/PAK for service encryption and authentication to a BSD/A 30 so that the BSD/A 30 can perform MAC processing on the STKM.
An operation of steps 601 and 603 in which a Terminal 50 accesses a BSM 40, performs a registration procedure for service subscription and reception, and receives an LTKM with SEK/PEK and SAK/PAK is to the same as the operation of steps 501 and 503 of FIG. 5, so a detailed description thereof will be omitted.
In step 605, the BSM 40 delivers its own SEK/PEK and SAK/PAK to the BSD/A 30. In step 607, the BSD/A 30 generates a partially created STKM using its generated TEK and other information, and finally performs digital signature processing thereon with the SAK/PAK, thereby generating a completed STKM. Herein, a public/private key scheme as RSA, or MAC function processing can be used as the digital signature processing. Thereafter, an operation of steps 607 to 613 in which the BSD/A 30 sends the completed STKM to the Terminal 50 and broadcasts the service encrypted with the TEK is to the same as the operation of steps 509 to 515 of FIG. 5.
Therefore, even in the embodiment of FIG. 6, the Terminal 50 can acquire the TEK through the STKM, and decipher the encrypted service using the TEK, thereby reproducing the service. The foregoing procedure, as described in the embodiment of FIG. 3, can also be applied to a procedure for transmitting a plurality of STKMs for one program/service.
With reference to FIGS. 7 to 10, a description will now be made of a message-handling scheme between components constituting the entities in the broadcast architecture based on FIGS. 5 and 6. The description of FIGS. 7 to 10 will be made with reference to an example to which the methods presented in FIGS. 2 and 3 are applied. However, it would be obvious to those skilled in the art that the following description of FIGS. 7 to 10 is not limited to FIGS. 2 and 3, and can also be applied to the method presented in FIG. 4. Although a registration process and an LTKM reception process are performed in a network supporting interaction channels in FIGS. 7 to 10, they can also be applied to a network supporting broadcast channels.
As described above, the broadcast architecture can be divided into broadcast service protection architecture and broadcast content protection architecture, and a difference between them is as follows. The broadcast content protection architecture can support right management for the transmission content. However, the broadcast service protection architecture has no right management function.
FIG. 7 illustrates a process performed during operation of a BCAST Digital Radio Mondiale™ (DRM™) profile in the broadcast service protection architecture presented in FIGS. 2 and 3.
The DRM™ profile is a broadcast DRM™ standard made for the broadcast environment in which the DRM™ v2.0 standard defined in the OMA working group can be used.
Referring to FIG. 7, in step 701, a Terminal 50 accesses, via an Interaction Network 70, an Service Protection-Management (SP-M) component 41 in a BSM 40 that manages subscription information of a subscriber for receipt of a BCAST service, and performs a registration procedure for subscription to and reception of the BCAST service. The registration procedure has been described above.
After performing the registration procedure, the Terminal 50 acquires in step 703 an LTKM including therein SEK/SAK or PEK/PAK, from a Content Protection-Management (CP-M) component 42 in the BSM 40. Herein, the SEK/SAK are keys used for encryption/digital signature for a service, and the PEK/PAK are keys used for encryption/digital signature for a program. The service can be considered as a set of contents, and the program can be considered as one content.
An Service Protection-Key Distribution (SP-KD) component 33 in a BSD/A 30 generates in step 705 a TEK used when the Terminal 50 deciphers an encrypted service. Thereafter, the SP-KD component 33 in the BSD/A 30 sends in step 707 the generated TEK along with other parameters necessary for STKM generation (e.g. encryption method, information related to the encryption method, protocol version and time information), to the SP-M component 41 in the BSM 40.
Thereafter, upon receipt of the TEK and several parameters necessary for STKM generation, the SP-M component 41 in the BSM 40 encrypts the TEK with its own SEK and PEK, and performs digital signature processing on the STKM created with the other parameters including the encrypted TEK using the SAK and the PAK, thereby generating a completed STKM. Herein, a public/private key scheme as RSA, or MAC function processing can be used as the digital signature processing. The BSD/A 30 and the BSM 40 can exchange an STKM Delivery Message or an STKM Request Message, for an exchange of the TEK and several parameters necessary for STKM generation. A description of this process has been made above. In step 709, the SP-M component 41 in the BSM 40 delivers the STKM completed through the above process, to an File Distribution/Stream Distribution (FD/SD) component 32 in the BSD/A 30.
In step 711, the SP-KD component 33 in the BSD/A 30 sends the generated TEK to an Service Protection-Encryption (SP-E) component 31 in the BSD/A 30. The SP-E component 31 controls encrypting the received service, which corresponds to step 717 of FIG. 7.
A CC 10 delivers the content to an File Application /Stream Application (FA/SA) component 21 in a BSA 20. If the content is received, the FA/SA component 21 in the BSA 20 converts in step 715 the received content into a service and delivers it to the SP-E component 31 in the BSD/A 30. In step 717, the SP-E component 31 in the BSD/A 30 performs the foregoing encryption, and then delivers in step 719 the encrypted service to the FD/SD component 32 in the BSD/A 30.
In step 721, the FD/SD component 32 sends the completed STKM to the Terminal 50, and then in step 723, delivers the encrypted service up to the Terminal 50. In this manner, it is possible to provide the encrypted service to the terminal.
FIG. 8 illustrates a process performed during operation of a BCAST smartcard profile in the broadcast service protection architecture presented in FIGS. 2 and 3.
The process of FIG. 8 is almost similar to the process of FIG. 7. Therefore, references will be made to their associated processes, and only the different processes will be described below.
A registration process in step 801 is the same as the process of FIG. 7. In step 803, an entity for receiving an LTKM is a smartcard 51 included in a Terminal 50, unlike that in FIG. 7. The other steps 805 to 819 are to the same as steps 705 to 719 described in FIG. 7. Because the entity for receiving the LTKM is the smartcard 51 in the Terminal 50 as described above, an STKM is delivered in step 821 to the smartcard 51 in the Terminal 50 and a TEK is delivered to the Terminal 50 and then used for deciphering, in order to decipher the encrypted service. Thereafter, a process of transmitting the encrypted service in step 823 is to the same as the process of step 723. Therefore, the smartcard 51 included in the Terminal 50 can receive and process the encrypted service in the manner described in FIG. 8.
FIG. 9 illustrates a process performed during operation of a BCAST DRM profile in the broadcast content protection architecture presented in FIGS. 2 and 3.
The process of FIG. 9 is also similar to the process of FIG. 7. FIG. 9 is different from FIG. 7 in that it operates based on the broadcast content protection architecture. Components in the content protection architecture are the same in function to components in the service protection architecture, but a CP-M component 42 in a BSM 40 can generate a Rights Object that can be used for performing right management. That is, in FIG. 9, unlike in FIG. 7, an SP-M component 41 in a BSM 40 is replaced with a CP-M component 42, and the CP-M component 42 can generate a Rights Object that can be used for performing right management.
FIG. 10 illustrates a process performed during operation of a BCAST smartcard profile in the broadcast content protection architecture presented in FIGS. 2 and 3.
The process of FIG. 10 is similar to the process of FIG. 8 except that FIG. 10 operates based on the content protection architecture, like FIG. 9. Therefore, a difference between FIGS. 10 and 8 is to the same as the difference between FIGS. 7 and 9. That is, components in the content protection architecture are similar in function to components in the service protection architecture, but a CP-M component 42 in a BSM 40 can generate a Rights Object that can be used for performing right management. That is, in FIG. 10, unlike in FIG. 8, an SP-M component 41 in the BSM 40 is replaced with the CP-M component 42 which can generate a Rights Object that can be used for performing right management.
FIG. 11 illustrates a process in which the methods described in FIGS. 2 and 3 interwork with broadcast service and content protection methods. Although an FD/SD component 32 in a BSD/A 30 is used in a process of transmitting an STKM in the embodiment of FIG. 7, the FD/SD component 32 is not used in the embodiment of FIG. 11.
Referring to FIG. 11, an operation in steps 1101 to 1107 is to the same as the operation performed in steps 701 to 707 of FIG. 7. In steps 1101 to 1107, a Terminal 50 performs a registration procedure for subscription to and reception of a BCAST service with an SP-M component 41 in a BSM 40, and performs an operation of receiving an LTKM including therein SEK/SAK or PEK/PAK from the SP-M component 41, and the SP-KD component 33 in the BSD/A 30 performs an operation of generating a TEK and then transmitting the generated TEK and other parameters necessary for STKM generation (e.g. encryption method, information related to the encryption method, protocol version and time information), to the SP-M component 41 in the BSM 40.
However, in the embodiment of FIG. 11, because the FD/SD component 32 is not used, the SP-M component 41 in the BSM 40 generates in step 1109 a completed STKM by performing digital signature processing on the STKM using the service/program authentication keys SAK/PAK, and transmits the generated STKM to the SP-KD component 33 in the BSD/A 30. Herein, a public/private key scheme as RSA, or MAC function processing can be used as the digital signature processing. Thereafter, in step 1111, the SP-KD component 33 in the BSD/A 30 transmits the TEK generated in step 1105 to the SP-E component 31 in the BSD/A 30. The SP-E component 31 controls encryption of the received service.
An operation in steps 1113 to 1117 is the same as the operation in steps 713 to 717 of FIG. 7. In steps 1113 to 1117, a CC 10 delivers content to an FA/SA component 21 in a BSA 20, the FA/SA component 21 converts the received content into a service and delivers the service to the SP-E component 31 in the BSD/A 30, and the SP-E component 31 encrypts the service. If the service encryption is completed in this manner, the SP-KD component 33 in the BSD/A 30 sends in step 1119 an STKM including the TEK used for deciphering the encrypted service/content, received from the SP-M component 41 in step 1109, to the Terminal 50.
Thereafter, in step 1121, the SP-E component 31 in the BSD/A 30 delivers the encrypted service to the Terminal 50 which deciphers the encrypted service using the STKM received in step 1119. Although the Terminal 50 receives the encrypted service in the embodiment of FIG. 11, it can also receive encrypted content.
FIG. 12 illustrates a process in which the method described in FIG. 4 interworks with broadcast service and content protection methods. An embodiment of FIG. 12 is to the same as the embodiment of FIG. 11 except for the process of generating an STKM.
That is, in the process of generating the STKM, an SP-M component 41 in a BSM 40 sends in step 1207 an SEAK including therein SEK and SAK as keys used for encryption/digital signature for a service and/or a PEAK including therein PEK and PAK as keys used for encryption/digital signature for a program, to an SP-KD component 33 in a BSD/A 30. In step 1209, the SP-KD component 33 generates a completed STKM by performing digital signature processing thereon using service/program authentication keys SAK/PAK, and delivers in step 1219 the generated STKM to the Terminal 50. In addition, operations in steps 1201 to 1205 and steps 1211 to 1221 are to the same as the operations in steps 1101 to 1105 and steps 1111 to 1121 of FIG. 11, so a detailed description thereof will be omitted.
Although operations of the components in the service protection architecture have been described in the embodiments of FIGS. 11 and 12, operations of components in the content protection architecture can also be performed in the same manner. A difference between the embodiments of FIGS. 11 and 12 and the embodiments of FIGS. 9 and 10 for content protection is that the embodiments of FIGS. 11 and 12 do not use the FD/SD component 32 in the BSD/A 30. In addition, when the smartcard is used in the embodiments of FIGS. 11 and 12, the process of performing service registration on the Terminal 50 and receiving an LTKM can be achieved between the smartcard 51 and the SP-M component 41 or the CP-M component 42, and the STKM can be delivered to the smartcard 51 where the TEK can be acquired from the received STKM. In addition, the STKM delivery methods presented in FIGS. 2 and 3 can also be applied to the embodiments of FIGS. 11 and 12.
As can be understood from the foregoing description, the present invention provides a detailed TEK/STKM generation method and a detailed BCAST service protection method for transmitting/receiving encrypted service, between network entities in a mobile broadcast system, thereby enabling safe delivery of the broadcast service/content.
While the invention has been shown and described with reference to a certain preferred embodiment thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.

Claims (8)

What is claimed is:
1. A method for generating a short term key message (STKM) for protection of a broadcast service being broadcasted to a terminal in a broadcast system, the method comprising:
transmitting, by a broadcast service subscription management (BSM) responsible for managing subscription information, key information for encryption of the broadcast service to a broadcast service distribution/adaptation (BSD/A) responsible for transmitting the broadcast service;
generating, by the BSD/A, a traffic encryption key (TEK) for deciphering the broadcast service in the terminal; and
performing, by the BSD/A, message authentication code (MAC) processing on the STKM by using either a service encryption authentication key or a service encryption key included in the key information, thereby generating a completed STKM,
wherein the BSD/A and the BSM are comprised of one or more servers in the broadcast system, and
wherein the TEK is obtained using the completed STKM in the terminal to which the broadcast service is transmitted from the BSD/A.
2. The method of claim 1, wherein the broadcast service includes content being provided to the terminal.
3. The method of claim 1, wherein performing the MAC processing further comprises:
performing, by the BSD/A, digital signature processing on the STKM using the key information.
4. The method of claim 1, further comprising:
sending, by the BSD/A, a request for transmission of the key information to the BSM.
5. A broadcast system for transmitting a short term key message (STKM) for reception of a broadcast service to a terminal, the system comprising:
a broadcast service distribution/adaptation (BSD/A) for generating a traffic encryption key (TEK) for deciphering of the broadcast service in the terminal, performing message authentication code (MAC) processing on the STKM by using either a service encryption authentication key or a service encryption key included in key information for encryption of the broadcast service, thereby generating a completed STKM, and transmitting the broadcast service to the terminal; and
a broadcast service subscription management (BSM) for managing subscription information of the terminal, and transmitting the key information to the BSD/A,
wherein the BSD/A and the BSM are comprised of one or more servers in the broadcast system, and
wherein the TEK is obtained using the completed STKM in the terminal to which the broadcast service is transmitted from the BSD/A.
6. The broadcast system of claim 5, wherein the broadcast service includes content being provided to the terminal.
7. The broadcast system of claim 5, wherein the BSD/A performs digital signature processing on the STKM using the key information.
8. The broadcast system of claim 5, wherein the BSD/A sends a request for transmission of the key information to the BSM.
US13/422,760 2006-02-27 2012-03-16 Method and system for protecting broadcast service/content in a mobile broadcast system, and method for generating short term key message threfor Active 2028-07-03 US9800358B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/422,760 US9800358B2 (en) 2006-02-27 2012-03-16 Method and system for protecting broadcast service/content in a mobile broadcast system, and method for generating short term key message threfor

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
KR10-2006-0018849 2006-02-27
KR20060018849 2006-02-27
KR20060027184 2006-03-24
KR10-2006-0027184 2006-03-24
KR20060048168 2006-05-29
KR10-2006-0048168 2006-05-29
KR1020060063652A KR100975386B1 (en) 2006-02-27 2006-07-06 Method and system for protecting broadcasting service/content in a mobile broadcast system, and method for generating a short term key message thereof
KR10-2006-0063652 2006-07-06
US11/711,499 US8160252B2 (en) 2006-02-27 2007-02-27 Method and system for protecting broadcast service/content in a mobile broadcast system, and method for generating short term key message therefor
US13/422,760 US9800358B2 (en) 2006-02-27 2012-03-16 Method and system for protecting broadcast service/content in a mobile broadcast system, and method for generating short term key message threfor

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/711,499 Continuation US8160252B2 (en) 2006-02-27 2007-02-27 Method and system for protecting broadcast service/content in a mobile broadcast system, and method for generating short term key message therefor

Publications (2)

Publication Number Publication Date
US20120170747A1 US20120170747A1 (en) 2012-07-05
US9800358B2 true US9800358B2 (en) 2017-10-24

Family

ID=38077581

Family Applications (3)

Application Number Title Priority Date Filing Date
US11/711,499 Active 2030-12-10 US8160252B2 (en) 2006-02-27 2007-02-27 Method and system for protecting broadcast service/content in a mobile broadcast system, and method for generating short term key message therefor
US13/422,760 Active 2028-07-03 US9800358B2 (en) 2006-02-27 2012-03-16 Method and system for protecting broadcast service/content in a mobile broadcast system, and method for generating short term key message threfor
US13/422,778 Expired - Fee Related US9356718B2 (en) 2006-02-27 2012-03-16 Method and system for protecting broadcast service/content in a mobile broadcast system, and method for generating short term key message therefor

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/711,499 Active 2030-12-10 US8160252B2 (en) 2006-02-27 2007-02-27 Method and system for protecting broadcast service/content in a mobile broadcast system, and method for generating short term key message therefor

Family Applications After (1)

Application Number Title Priority Date Filing Date
US13/422,778 Expired - Fee Related US9356718B2 (en) 2006-02-27 2012-03-16 Method and system for protecting broadcast service/content in a mobile broadcast system, and method for generating short term key message therefor

Country Status (3)

Country Link
US (3) US8160252B2 (en)
EP (1) EP1826931B1 (en)
WO (1) WO2007097604A1 (en)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100840901B1 (en) * 2007-06-22 2008-06-24 주식회사 케이티프리텔 System for supporting over-the-air service and method thereof
KR101420874B1 (en) 2007-09-21 2014-07-30 삼성전자주식회사 Method for storing broadcasting content in open mobile alliance mobile broadcast
GB2453924A (en) * 2007-09-27 2009-04-29 Vodafone Plc Encrypted Mobile TV broadcast with encrypted content key while key encryption key is delivered over phone network
CN101420688B (en) * 2007-10-23 2010-06-16 中兴通讯股份有限公司 System and method for sharing content of mobile multimedia broadcast
WO2009064145A2 (en) * 2007-11-16 2009-05-22 Samsung Electronics Co., Ltd. System and method for acquiring terminal binding key
KR101485597B1 (en) 2007-11-16 2015-01-22 삼성전자주식회사 System and method for acquiring terminal binding key
KR20090086004A (en) * 2008-02-05 2009-08-10 삼성전자주식회사 Method for managing encryption key by mobile communication terminal connected with smartcard and apparatus therefor
WO2009145495A2 (en) * 2008-04-04 2009-12-03 Samsung Electronics Co., Ltd. Method and apparatus for providing broadcast service using encryption key in a communication system
KR101514840B1 (en) * 2008-06-11 2015-04-23 삼성전자주식회사 Method for Security Key Distribution in Broadcast Service System and System Therefor
KR101498288B1 (en) * 2008-06-24 2015-03-03 삼성전자주식회사 Apparatus and method for transmitting a plurality of key data
EP2150049A1 (en) 2008-07-30 2010-02-03 Koninklijke KPN N.V. Virtually increasing the number of content broadcast channels
KR20100047651A (en) * 2008-10-29 2010-05-10 삼성전자주식회사 Method and apparatus for acquiring encryption key for providing premium channel
EP2227015B1 (en) * 2009-03-02 2018-01-10 Irdeto B.V. Conditional entitlement processing for obtaining a control word
CN103095461B (en) * 2013-01-23 2015-12-09 山东量子科学技术研究院有限公司 The authentication method of network signal between a kind of quantum safety network equipment

Citations (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020143710A1 (en) 2001-04-03 2002-10-03 Gary Liu Certified transmission system
US20030039361A1 (en) * 2001-08-20 2003-02-27 Hawkes Philip Michael Method and apparatus for security in a data processing system
US20030070092A1 (en) * 2001-10-09 2003-04-10 Philip Hawkes Method and apparatus for security in a data processing system
US20040202329A1 (en) 2003-04-11 2004-10-14 Samsung Electronics Co., Ltd. Method and system for providing broadcast service using encryption in a mobile communication system
US20050010774A1 (en) * 2003-07-08 2005-01-13 Rose Gregory Gordon Apparatus and method for a secure broadcast system
US20050008159A1 (en) * 2003-07-07 2005-01-13 Francesco Grilli Secure registration for a multicast-broadcast-multimedia system (MBMS)
US20050079821A1 (en) 2003-10-10 2005-04-14 Hao Bi Wireless broadcast service quality indicator and method
US20050117743A1 (en) * 2003-08-18 2005-06-02 Bender Paul E. Method and apparatus for time-based charging for broadcast-multicast services (BCMCS) in a wireless communication system
WO2005057321A2 (en) 2003-12-09 2005-06-23 Electronics And Telecommunications Research Institute Method for requesting, generating and distributing service-specific traffic encryption key in wireless portable internet system, apparatus for the same, and protocol configuration method for the same
US20050138379A1 (en) * 2003-09-02 2005-06-23 James Semple Method and apparatus for providing authenticated challenges for broadcast-multicast communications in a communication system
EP1575210A1 (en) 2004-03-10 2005-09-14 Sun Microsystems, Inc. Method and apparatus for hybrid group key management
KR20050100124A (en) 2004-04-13 2005-10-18 에스케이 텔레콤주식회사 Portable internet broadcasting system
US20050250499A1 (en) 2004-05-07 2005-11-10 Samsung Electronics Co., Ltd. System and method for handover capable of minimizing service delay in broadband wireless access communication system
US20050251680A1 (en) * 2004-04-02 2005-11-10 Brown Michael K Systems and methods to securely generate shared keys
US20050289347A1 (en) * 2004-06-28 2005-12-29 Shlomo Ovadia Method and apparatus to authenticate base and subscriber stations and secure sessions for broadband wireless networks
US20060030312A1 (en) 2004-08-04 2006-02-09 Lg Electronics Inc. Broadcast/multicast service system and method providing inter-network roaming
WO2006014076A1 (en) 2004-08-04 2006-02-09 Lg Electronics Inc. Broadcast/multicast service system and method providing inter-network roaming
WO2006019236A1 (en) 2004-08-17 2006-02-23 Samsung Electronics Co., Ltd. Apparatus and method for providing poc service in wireless communication system supporting bcast service
US20060115084A1 (en) 2004-11-19 2006-06-01 Lg Electronics Inc. Conditional access for a multimedia broadcast service using a wireless terminal
US20060149965A1 (en) 2004-12-30 2006-07-06 Nokia Inc. System, method and computer program product for detecting a rogue member in a multicast group
US20060168446A1 (en) 2002-09-13 2006-07-27 Pasi Ahonen Secure broadcast/multicast service
US20060174037A1 (en) * 2002-07-29 2006-08-03 Bea Systems, Inc. Identifying a computer device
US20060189300A1 (en) 2005-01-25 2006-08-24 Samsung Electronics Co., Ltd. Method and apparatus for sending notification about broadcast service in a mobile broadcast system
US20060206708A1 (en) * 2005-01-14 2006-09-14 Lg Electronics Inc. Method for managing digital rights in broadcast/multicast service
US20060209843A1 (en) 2005-02-25 2006-09-21 Kan Zhang Secure spontaneous associations between networkable devices
US20060259433A1 (en) * 2005-05-12 2006-11-16 Nokia Corporation Fine grain rights management of streaming content
US20070061569A1 (en) 2005-09-15 2007-03-15 Samsung Electronics Co., Ltd. Inter-entity coupling method, apparatus and system for service protection
US20070061568A1 (en) 2005-09-15 2007-03-15 Samsung Electronics Co., Ltd. Inter-entity coupling method, apparatus and system for content protection
US20070093202A1 (en) 2005-10-14 2007-04-26 Sung-Oh Hwang Roaming service method in a mobile broadcasting system, and system thereof
US20070102140A1 (en) 2005-11-07 2007-05-10 3M Innovative Properties Company Structured thermal transfer article
US20070189535A1 (en) 2005-04-04 2007-08-16 Samsung Electronics Co., Ltd. Method and apparatus for protecting contents supporting broadcast service between service provider and a plurality of mobile stations
US20070204305A1 (en) 2006-02-03 2007-08-30 Samsung Electronics Co., Ltd. Method and system for sharing service guide or service guide fragments in mobile broadcast system
US20070274526A1 (en) 2006-02-03 2007-11-29 Qualcomm Incorporated Method and apparatus for content protection in wireless communications
JP2009512329A (en) 2005-10-14 2009-03-19 サムスン エレクトロニクス カンパニー リミテッド Roaming service method and system for mobile broadcast system
JP2009528069A (en) 2006-03-01 2009-08-06 ジェイアール ジョーンズ カンパニー Safety fence
US7643817B2 (en) 2005-05-18 2010-01-05 General Dynamics C4 Systems, Inc. Method and apparatus for rapid secure session establishment on half-duplex AD-hoc group voice cellular network channels

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6904110B2 (en) * 1997-07-31 2005-06-07 Francois Trans Channel equalization system and method
US20040120527A1 (en) * 2001-08-20 2004-06-24 Hawkes Philip Michael Method and apparatus for security in a data processing system
US8312265B2 (en) * 2001-12-11 2012-11-13 Pinder Howard G Encrypting received content
US7613925B2 (en) * 2003-01-10 2009-11-03 Motorola, Inc. Method for authenticating a message
US7991396B2 (en) * 2003-06-09 2011-08-02 Qualcomm Incorporated Method and apparatus for broadcast application in a wireless communication system
US7487349B2 (en) * 2004-04-23 2009-02-03 Nagracard S.A. Method for securing a ciphered content transmitted by a broadcaster
CN101019370A (en) * 2004-09-10 2007-08-15 皇家飞利浦电子股份有限公司 Method of providing conditional access
US20060291660A1 (en) * 2005-12-21 2006-12-28 Telefonaktiebolaget Lm Ericsson (Publ) SIM UICC based broadcast protection
WO2007052989A1 (en) * 2005-11-07 2007-05-10 Samsung Electronics Co., Ltd. Method and apparatus for transmitting service guide source in a mobile broadcast system
US20070162399A1 (en) * 2005-12-22 2007-07-12 Alexander Medvinsky Method and apparatus for providing broadcast trigger messages
US7752441B2 (en) * 2006-02-13 2010-07-06 Alcatel-Lucent Usa Inc. Method of cryptographic synchronization

Patent Citations (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020143710A1 (en) 2001-04-03 2002-10-03 Gary Liu Certified transmission system
US20030039361A1 (en) * 2001-08-20 2003-02-27 Hawkes Philip Michael Method and apparatus for security in a data processing system
US20030070092A1 (en) * 2001-10-09 2003-04-10 Philip Hawkes Method and apparatus for security in a data processing system
US20060174037A1 (en) * 2002-07-29 2006-08-03 Bea Systems, Inc. Identifying a computer device
US20060168446A1 (en) 2002-09-13 2006-07-27 Pasi Ahonen Secure broadcast/multicast service
US20040202329A1 (en) 2003-04-11 2004-10-14 Samsung Electronics Co., Ltd. Method and system for providing broadcast service using encryption in a mobile communication system
US20050008159A1 (en) * 2003-07-07 2005-01-13 Francesco Grilli Secure registration for a multicast-broadcast-multimedia system (MBMS)
US20050010774A1 (en) * 2003-07-08 2005-01-13 Rose Gregory Gordon Apparatus and method for a secure broadcast system
US20050117743A1 (en) * 2003-08-18 2005-06-02 Bender Paul E. Method and apparatus for time-based charging for broadcast-multicast services (BCMCS) in a wireless communication system
US20050138379A1 (en) * 2003-09-02 2005-06-23 James Semple Method and apparatus for providing authenticated challenges for broadcast-multicast communications in a communication system
US20050079821A1 (en) 2003-10-10 2005-04-14 Hao Bi Wireless broadcast service quality indicator and method
WO2005057321A2 (en) 2003-12-09 2005-06-23 Electronics And Telecommunications Research Institute Method for requesting, generating and distributing service-specific traffic encryption key in wireless portable internet system, apparatus for the same, and protocol configuration method for the same
EP1575210A1 (en) 2004-03-10 2005-09-14 Sun Microsystems, Inc. Method and apparatus for hybrid group key management
US7646872B2 (en) * 2004-04-02 2010-01-12 Research In Motion Limited Systems and methods to securely generate shared keys
US20050251680A1 (en) * 2004-04-02 2005-11-10 Brown Michael K Systems and methods to securely generate shared keys
KR20050100124A (en) 2004-04-13 2005-10-18 에스케이 텔레콤주식회사 Portable internet broadcasting system
US20050250499A1 (en) 2004-05-07 2005-11-10 Samsung Electronics Co., Ltd. System and method for handover capable of minimizing service delay in broadband wireless access communication system
US20050289347A1 (en) * 2004-06-28 2005-12-29 Shlomo Ovadia Method and apparatus to authenticate base and subscriber stations and secure sessions for broadband wireless networks
WO2006014076A1 (en) 2004-08-04 2006-02-09 Lg Electronics Inc. Broadcast/multicast service system and method providing inter-network roaming
US20060030312A1 (en) 2004-08-04 2006-02-09 Lg Electronics Inc. Broadcast/multicast service system and method providing inter-network roaming
JP2008508831A (en) 2004-08-04 2008-03-21 エルジー エレクトロニクス インコーポレイティド Broadcast / multicast service system and method for providing roaming between networks
WO2006019236A1 (en) 2004-08-17 2006-02-23 Samsung Electronics Co., Ltd. Apparatus and method for providing poc service in wireless communication system supporting bcast service
US20060115084A1 (en) 2004-11-19 2006-06-01 Lg Electronics Inc. Conditional access for a multimedia broadcast service using a wireless terminal
US20060149965A1 (en) 2004-12-30 2006-07-06 Nokia Inc. System, method and computer program product for detecting a rogue member in a multicast group
US20060206708A1 (en) * 2005-01-14 2006-09-14 Lg Electronics Inc. Method for managing digital rights in broadcast/multicast service
JP2008524914A (en) 2005-01-14 2008-07-10 エルジー エレクトロニクス インコーポレイティド Digital Rights Management Method for Broadcast / Multicast Service
US20060189300A1 (en) 2005-01-25 2006-08-24 Samsung Electronics Co., Ltd. Method and apparatus for sending notification about broadcast service in a mobile broadcast system
US20060209843A1 (en) 2005-02-25 2006-09-21 Kan Zhang Secure spontaneous associations between networkable devices
US20070189535A1 (en) 2005-04-04 2007-08-16 Samsung Electronics Co., Ltd. Method and apparatus for protecting contents supporting broadcast service between service provider and a plurality of mobile stations
US20060259433A1 (en) * 2005-05-12 2006-11-16 Nokia Corporation Fine grain rights management of streaming content
US7643817B2 (en) 2005-05-18 2010-01-05 General Dynamics C4 Systems, Inc. Method and apparatus for rapid secure session establishment on half-duplex AD-hoc group voice cellular network channels
JP2007082191A (en) 2005-09-15 2007-03-29 Samsung Electronics Co Ltd Entity relating method, device, and system for protecting content
US20070061569A1 (en) 2005-09-15 2007-03-15 Samsung Electronics Co., Ltd. Inter-entity coupling method, apparatus and system for service protection
US20070061568A1 (en) 2005-09-15 2007-03-15 Samsung Electronics Co., Ltd. Inter-entity coupling method, apparatus and system for content protection
JP2009508431A (en) 2005-09-15 2009-02-26 サムスン エレクトロニクス カンパニー リミテッド Inter-entity linking method and apparatus for service protection, and system thereof
US20070093202A1 (en) 2005-10-14 2007-04-26 Sung-Oh Hwang Roaming service method in a mobile broadcasting system, and system thereof
JP2009512329A (en) 2005-10-14 2009-03-19 サムスン エレクトロニクス カンパニー リミテッド Roaming service method and system for mobile broadcast system
US20070102140A1 (en) 2005-11-07 2007-05-10 3M Innovative Properties Company Structured thermal transfer article
JP2009515362A (en) 2005-11-07 2009-04-09 スリーエム イノベイティブ プロパティズ カンパニー Structured heat transfer article
US20070274526A1 (en) 2006-02-03 2007-11-29 Qualcomm Incorporated Method and apparatus for content protection in wireless communications
JP2009532922A (en) 2006-02-03 2009-09-10 クゥアルコム・インコーポレイテッド Method and apparatus for content protection in wireless communication
JP2009525668A (en) 2006-02-03 2009-07-09 サムスン エレクトロニクス カンパニー リミテッド Method and system for sharing a service guide or service guide fragment in a portable broadcast system
US20070204305A1 (en) 2006-02-03 2007-08-30 Samsung Electronics Co., Ltd. Method and system for sharing service guide or service guide fragments in mobile broadcast system
JP2009528069A (en) 2006-03-01 2009-08-06 ジェイアール ジョーンズ カンパニー Safety fence
US20110018290A1 (en) 2006-03-01 2011-01-27 Jr Jones Company Safety gaff

Non-Patent Citations (11)

* Cited by examiner, † Cited by third party
Title
Bruce Schneier, Applied Cryptography, 2nd Edition, John Wiley & Sons, 1996, Chapter 18: One Way Hash Functions.
Bruce Schneier, Applied Cryptography, 2nd Edition, John Wiley & Sons, 1996, Chapter 20: Public-Key Digital Signature Algorithms.
Holtmanns, Silke, "Trust and Security in Mobile Broadcast Systems", Nokia Research Center, May 17-18, 2006.
Menno Bangma et al., "Service Protection Functional Architecture Revisited", OMA-BCAST-2006-0189R01, Open Mobile Alliance, Feb. 24, 2006.
Menno Bangma et al., "Service Protection Functional Architecture", OMA-BCAST-2006-0189, Open Mobile Alliance, Feb. 24, 2006.
Open Mobile Alliance, "Draft Version 1.0, Mobile Broadcast Services Architecture", Mar. 28, 2006.
Open Mobile Alliance, "Draft Version 1.0, Service and Content Protection for Mobile Broadcast Service", Feb. 24, 2006.
Open Mobile Alliance, Draft Version 1.0, Service and Content Protection for Mobi e Broadcast Service, Feb. 24, 2006. *
Service and Content Protection for Mobile Broadcast Services Draft Version 1.0-Feb. 24, 2006, Open Mobile Alliance Feb. 24, 2006. *
Service and Content Protection for Mobile Broadcast Services Draft Version 1.0—Feb. 24, 2006, Open Mobile Alliance Feb. 24, 2006. *
Suomalainen, Jani, "Content Protection and Authorized Sharing for Mobile Broadcast", Helsinki University of Technology, Sep. 5, 2005.

Also Published As

Publication number Publication date
EP1826931A2 (en) 2007-08-29
US9356718B2 (en) 2016-05-31
US20070259647A1 (en) 2007-11-08
EP1826931A3 (en) 2013-09-11
US20120170747A1 (en) 2012-07-05
EP1826931B1 (en) 2018-12-19
WO2007097604A1 (en) 2007-08-30
US8160252B2 (en) 2012-04-17
US20120170748A1 (en) 2012-07-05

Similar Documents

Publication Publication Date Title
US9800358B2 (en) Method and system for protecting broadcast service/content in a mobile broadcast system, and method for generating short term key message threfor
US9282437B2 (en) Method and system for providing notification message in a mobile broadcast system
US8400956B2 (en) Method and apparatus for providing service guide in a mobile broadcasting system
US20080039078A1 (en) Method and apparatus for transmitting and receiving electronic service guide for roaming user in a digital broadcasting system
RU2357370C1 (en) Device and method of transmitting stream in mobile broadcasting system
US7801510B2 (en) Authentication method in a mobile broadcast system and system thereof
JP5367133B2 (en) Broadcast service / content protection method and system in portable broadcast system, and short-term key message generation method therefor
US20070118586A1 (en) Method and apparatus for delivering service guide contents and notification event information in a mobile broadcast system
US8208636B2 (en) Method for transmitting/receiving encryption information in a mobile broadcast system, and system therefor
US8774414B2 (en) Method and apparatus for transmitting/receiving encryption information in a mobile broadcast system
KR101300427B1 (en) Method and system for transmitting encryption key message through interaction channel in broadcasting system
KR20070096530A (en) Method and system for transmitting infromation btween entity in mobile broadcast system
KR20070078659A (en) Method for transmitting and receiving encryption key in mobile broadcasting system and system thereof
KR20070096531A (en) Encoding method in mobile broadcasting system and system thereof

Legal Events

Date Code Title Description
STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4