WO2010124446A1 - 发行许可的方法、装置和系统 - Google Patents

发行许可的方法、装置和系统 Download PDF

Info

Publication number
WO2010124446A1
WO2010124446A1 PCT/CN2009/071503 CN2009071503W WO2010124446A1 WO 2010124446 A1 WO2010124446 A1 WO 2010124446A1 CN 2009071503 W CN2009071503 W CN 2009071503W WO 2010124446 A1 WO2010124446 A1 WO 2010124446A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
license
information
key
issuer
Prior art date
Application number
PCT/CN2009/071503
Other languages
English (en)
French (fr)
Inventor
袁卫忠
张仁宙
黄晨
周志鹏
李庆亮
Original Assignee
华为技术有限公司
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
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to CN2009801471644A priority Critical patent/CN102224703B/zh
Priority to PCT/CN2009/071503 priority patent/WO2010124446A1/zh
Publication of WO2010124446A1 publication Critical patent/WO2010124446A1/zh
Priority to US13/281,191 priority patent/US8407772B2/en

Links

Classifications

    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • 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/0822—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 key encryption key
    • 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/3247—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 involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • 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/603—Digital right managament [DRM]

Definitions

  • the present invention relates to the field of digital copyright protection technologies, and in particular, to a method, apparatus and system for issuing licenses. Background technique
  • Digital Rights Management protects the legitimate rights and interests of content owners by controlling the use of digital content through rights restrictions and content protection schemes.
  • the digital content publisher Content Issuer, CI
  • the provider Content Provider, CP
  • the license issuer Lights Issuer, RI/License Server
  • the destination entity can only use digital content if it has both content packets and permissions. Summary of the invention
  • An embodiment of the present invention provides a method for issuing a license, including:
  • the content issuer receives a request from the license issuer to assist in generating the license
  • the content issuer obtains the encapsulation key by encapsulating the content-related information using the key of the destination entity according to the information carried in the request for assisting the generation of the license, and generates a message authentication code for the part of the license information;
  • the content issuer sends the generated message verification code and the obtained package key to the license issuer to cause the license issuer to transmit the license containing the message verification code and the package key to the destination entity.
  • Another embodiment of the present invention provides a content distribution device, including:
  • a request receiving unit configured to receive a request from a license issuer to assist in generating a license
  • the assistance unit is configured to: according to the information carried in the request for assisting the generation of the license, use the key of the destination entity to encapsulate the content-related information to obtain the encapsulation key, and generate the information of the licensed part.
  • Information verification code
  • a response sending unit configured to send the message verification code generated by the assistance unit and the obtained encapsulation key to the license issuer, so that the license issuer will include the message verification code and the encapsulation key
  • the license is sent to the destination entity.
  • a further embodiment of the present invention provides a license issuing device, including:
  • a request sending unit configured to send a request to the content issuer to assist in generating a license
  • a response receiving unit configured to receive, according to the request sending unit, an encapsulation key obtained by encapsulating content-related information using a key of the destination entity, and a message verification code generated for the licensed partial information
  • a permission sending unit configured to send a permission including a message verification code and a package key received by the response receiving unit to the destination entity.
  • Yet another embodiment of the present invention provides a system for issuing a license, including:
  • a content issuer configured to receive a license issuer to assist in generating a license request, to encapsulate the content-related information using the key of the destination entity according to the information carried in the request for assisting the generation of the license, and obtain the encapsulation key, and the licensed part Generating a message verification code; transmitting the generated message verification code and the obtained package key to the license issuer;
  • a license issuer configured to send the request for assisting to generate a license to a content issuer; receiving the message verification code and the encapsulation key sent by the content issuer; and including the message verification code and the encapsulation The license for the key is sent to the destination entity.
  • the content issuer obtains the encapsulation key by using the key of the destination entity to encapsulate the content-related information according to the request of the license issuer to generate the license, and generates a message for the partial information of the license.
  • a verification code by which the license issuer transmits a license containing the message verification code and the encapsulation key to the destination entity, because the license issuer cannot decrypt the encapsulation key, thereby ensuring the confidentiality of the encapsulation key to the license issuer sexuality, and because the message verification code protects the integrity of part of the license, effectively preventing the license issuer from tampering with the information in the license including the permission information, and effectively preventing the license issuer from forging the license, thus achieving DRAWINGS
  • FIG. 1 is a schematic structural diagram of a release license system according to an embodiment of the present invention.
  • FIG. 2 is a schematic diagram of a topology of a distribution license system according to an embodiment of the present invention
  • FIG. 3 is a schematic diagram of a structure of an internal function module of a license issuance system according to an embodiment of the present invention
  • Schematic diagram of the method of issuing a license
  • FIG. 5 is a schematic diagram of a corresponding processing flow of the content distribution agent in FIG. 4;
  • FIG. 6 is a schematic flowchart of another method for issuing a license according to an embodiment of the present invention
  • FIG. 7 is a schematic flowchart of controlling by using an issuer license according to an embodiment of the present invention
  • FIG. 8 is a schematic flowchart of a method for issuing a license according to an embodiment of the present invention
  • FIG. 10 is a schematic diagram of a corresponding processing flow of a content distribution agent in FIG.
  • FIG. 11 is a schematic structural diagram of a content and a license in a Marlin system according to an embodiment of the present invention
  • FIG. 12 is a schematic flowchart of another method for issuing a license according to an embodiment of the present invention
  • FIG. 14 is a schematic flow chart of a method for issuing licenses provided under the system of FIG. 13;
  • 15 is a flowchart of a method for issuing a license according to an embodiment of the present invention.
  • FIG. 16 is a schematic structural diagram of a content distribution apparatus according to an embodiment of the present invention.
  • FIG. 17 is a schematic structural view of the assisting unit provided in FIG. 16;
  • FIG. 18 is a schematic structural diagram of a license issuing apparatus according to an embodiment of the present invention.
  • FIG. 19 is a schematic structural diagram of a license issuance system according to an embodiment of the present invention. detailed description
  • the inventors have found that: In the existing digital copyright protection system, when CI and RI belong to different business entities, respectively, or belong to the group head office and subordinate subsidiaries respectively, CI cannot know from RI.
  • the accurate issuance of digital content including: the use of users, permission information contained in the license, etc., which is very unfavorable for the management of the business entity to which the CI belongs, making it impossible to charge according to the actual distribution of digital content or as a commercial contract.
  • the reference cannot be effective in controlling or supervising the RI, so that it cannot fully protect its own interests.
  • CI participates in the process of RI encapsulation and issuance of licenses, and CI is responsible for encapsulating the key parts of the license, and RI is responsible for issuing the license, thereby realizing CI control RI issuance license.
  • CI is divided into CI Server (CI server) and CI Agent (CI client agent) according to functional modules.
  • CI Server is deployed on CI local area network
  • CI Agent is Can be deployed to the LAN where the RI is located.
  • the CI Agent preferred deployment solution is installed on a separate machine or a logically independent virtual machine.
  • the system architecture diagram of the present invention is shown in FIG.
  • CI has full control and management rights to CI Server and CI Agent.
  • CI Server can be deployed at CI, and CI Agent can be deployed to different RIs according to business needs.
  • the corresponding CI Agent can also be customized or modified to some extent according to the needs of supporting different RI services. If the network conditions and processing performance meet the RI service requirements, it is not excluded to deploy the CI Agent and CI Server in the same place.
  • the CI can also combine the CI Server and the CI Agent to provide the full functionality of the CI Server and CI Agent from the same module.
  • the deployment plan can be a centralized background CI Server, which connects several CI Agent front-end agents.
  • the topology diagram is shown in Figure 2.
  • CI Server keeps all the digital content owned by CI and its corresponding Content Encryption Key (CEK) information, business contacts and business policies, rules, etc. established with the associated RI, and related information for managing all CI Agents.
  • CEK Content Encryption Key
  • CI Server and can also protect data by constructing protection messages.
  • the CI Agent may store only part of the content related to the associated RI service and its corresponding CEK, and the business policies, rules, and the like related to the RI.
  • Figure 3 A schematic diagram of their functional modules is shown in Figure 3.
  • the CI Agent needs to register with the CI Server, exchange some necessary information after mutual authentication, and establish a Secure Authenticated Channel (SAC) for subsequent communication.
  • SAC Secure Authenticated Channel
  • the CI Server can also specify that the CI Agent can be enabled only after it is activated.
  • the CI Agent issues an enable request to the CI Server, and the CI Server activates the CIAgent by enabling the response message.
  • the CI Agent is registered to the CI Server and requires activation to enable it, which facilitates the management of the CI Agent.
  • the CI Server can even lock the CI Agent in the future to pause or stop its operation.
  • Content CEK acquisition Since the CI Agent may only store part of the content of the CEK, after the CI Server adds new digital content, it needs to trigger the CI Agent to update in time; or set the CI Agent to periodically request the CI Server for content. The increase requires an update. This time limit can be determined by the CI Agent configuration, or by using an update policy or the like.
  • the CI Server can choose the way of incremental update or full update, and the preferred scheme is incremental update.
  • the CI Server binds the content identifier CID and its CEK that have been updated since the last update to the CI Agent, and encapsulates it in the response message and returns it to the CI Agent; if no update occurs, it does not need to include any CID and its CEK in the response message. :.
  • the CI Agent processes it. If there is a CEK with new content, it updates to its own local service and content database.
  • the CI Agent controls the RI issue license through the service control module and the license release control information, and the license issue control information is provided to the CI by the CI Server. Agent.
  • the license issuance control information may be based on a license issuance policy, a rule, or an issuer license (Issuer RO, IRO), which is established based on a business contact or contract with the related RI. If the CI Agent performs the license issuance based on the IRO control RI, the CI Agent will act as the DRM client of the IRO mechanism, and the CI Server will issue the IRO to it; the CI Agent will consume the corresponding IRO each time it generates a license for the RI. Permissions.
  • the CI agent When the license issuance control information of the CI server is changed, the CI agent needs to be triggered to obtain the information; or the CI agent periodically submits the license issuance control information request message to the CI server.
  • the time limit can be determined by the CI agent configuration, or the policy is used. Determine, or request the new IRO from the CI Agent in time after the IRO is consumed.
  • the CI Server returns the appropriate license release control information based on the request.
  • the CI Agent reports the license release statistics to the CI Server: CI can trigger the CI Agent to report the license release statistics information, or the CI Agent periodically reports the license to the CI Server. Release statistics, this time period can be determined by the CI Agent configuration, or by using the policy. You can use 4 ⁇ to accumulate data, or classify statistics; you can perform total uploads, or just incremental uploads. Similarly, the CI server can specify whether the CI agent needs to delete the reported data after successfully reporting the statistics through configuration or policy. If the CI Agent adopts the IRO scheme, it is also possible to use the statistics information without the statistics. The CI Server collects statistics based on the IRO.
  • CI Server In order to ensure the security and correctness of the CI Agent deployed at the RI, the CI Agent can be checked for security such as annual inspection, etc., such as by remote login or expedition. Different methods such as desktop, remote attestation, and functional validity verification. In addition, the CI Server can trigger the CI Agent to process when the CI Agent configuration needs to be changed or some of the CIAgent function modules need to be upgraded.
  • the dotted line is connected between the CI Server and the CI Agent, indicating that they can not maintain the network connection all the time, or even have no connection mechanism at all.
  • the CI Server and the CI Agent may also use the out-of-band method to perform the necessary operations.
  • license release control information such as license issuance policies, rules or IRO updates.
  • the CI Agent acts as a server and controls and assists the RI to issue licenses in response to the RI request.
  • the interaction protocol and process diagram between them are shown in Figure 4. The operational steps of the process are briefly described as follows:
  • the RI receives a request from the user to generate a license for its device, or is triggered by the system.
  • a subscription user periodically generates licenses for its device for a period of time, or for other reasons, the following process may be triggered;
  • Step 41 The RI sends a request (Cooperate-RORequest) message to the CI Agent to generate a license, and the request message includes the following parameters:
  • the RI construct request message includes: encapsulating the content ID of the corresponding request, the requested authority, and the like into a ⁇ 1 ⁇ ⁇ ] ⁇ > element, but does not include the ⁇ EncryptedCEK> element (optional, RI and Not encapsulated into ⁇ 1 ⁇ > elements, but only provide information such as CID and permissions), in addition, RI will also set
  • CRL Certificate Revocation List
  • the support algorithm information negotiated with the requesting device the attribute information such as the roID assigned to the license, and whether the RI needs to be the license.
  • Signature indication, signature or MAC value of the request message if there is no secure channel between the RI and the CI Agent, you need to add a signature; if you use the Secure Authorized Channel (SAC), you can add the message authentication code MAC. (Message Authentication Code) value; optional if other secure channels are used.
  • SAC Secure Authorized Channel
  • the RI sends the constructed request message to the CI Agent.
  • a corresponding session identifier may be added to the message in all steps of the protocol, or a random number (Nonce) parameter item may be added to the message to ensure the freshness of the message and the anti-replay attack;
  • Step 42 The corresponding processing flow of the CI Agent is shown in Figure 5:
  • Step 501 The CIAgent will first determine whether to allow the response to the request based on the license issuance control information it has. If so, continue with the following processing steps, otherwise reject the request.
  • Step 502 The CI Agent then verifies whether the device certificate is still valid according to the device's certificate chain (if the device ID is required to obtain the device's certificate chain) and the corresponding certificate verification material, and the CI Agent may also need to respond from the OCSP itself.
  • the server or CRL directory server obtains verification material such as an OCSP response or a certificate invalidation list CRL for verifying the validity of the device certificate.
  • Step 503 Perform processing according to the result of verifying the device certificate. If the device certificate status is still valid, proceed as follows, otherwise reject the request.
  • Step 504 The CIAgent finds and acquires the associated CEK according to the CID of the content. There may be multiple CIDs, and the CEK may also need to perform decryption processing.
  • Step 505 randomly generating a K REK , and encapsulating the CEK by using a K REK and a key encapsulation algorithm in the support algorithm known in step 501 to obtain one or more ⁇ 1 07 16 ( ⁇ 3 ⁇ 4 > elements, and Filled into the ⁇ Rights> element.
  • steps 43 to 44 Whether these two steps require an indication value depending on whether the RI needs to be signed for the license in the previous step 41. If the indication is required, it must be executed; otherwise, you can jump directly to step 45 to continue execution.
  • the ⁇ Rights> element is calculated according to the hash algorithm used by the signature algorithm in the support algorithm obtained in step 41.
  • the hash value in which case it only needs to include its hash value, is encapsulated in the Cooperate-ROResponse message to be sent to the RI.
  • the RI generates a digital signature based on the received ⁇ Rights> element (or its hash value), and encapsulates the digital signature in a Cooperate-protected RORequest message to return to the CI Agent.
  • Step 45 The CI agent randomly generates a KMAC according to the key transmission algorithm in the support algorithm obtained in step 41, connects K rek in step 42 above to obtain K REK
  • OMA Open Key Alliance
  • DRM Digital Rights Management
  • the CI Agent randomly generates a Z, extracts the public key in the destination device certificate to encrypt Z to obtain the ciphertext C1, performs a key derivation function KDF (key derivation function) on Z to obtain a KEK, and then uses KEK to encapsulate K REK
  • Get ciphertext C2 connect C1 and C2 and encode to get 1 ( ⁇ 6 > element. If you need ⁇ timestamp> element, you can include it by RI in step 41 above, or you can use CI agent to realize time synchronization with RI. Add the own.
  • the CI Agent assembles the type ROPayloac ⁇ ⁇ ro> element, and applies the MAC algorithm in the support algorithm known in step 41 to the ⁇ 3 ⁇ 4)> element to generate the corresponding ⁇ 3 ⁇ 4 ⁇ element.
  • the CI Agent will have all the information needed to assemble a complete ⁇ ProtectedRO> and can be assembled into a ⁇ ProtectedRO> element.
  • Step 46 The CI Agent will ⁇ ?1"( ⁇ ( ⁇ (3 ⁇ 40> element encapsulation is sent to the RI in the response message. If the RI receives the Hash value of only the A ⁇ Rights> element in the above step 43, the RI may also When receiving the license, choose to verify whether the hash value of the ⁇ 1 ⁇ > element in the license is consistent with the hash value received in step 43. The CI Agent can store this license for subsequent remittance to the CI Server. statistics. Step 47: This is an optional step, and the specific implementation depends on the actual situation of the RI. The RI constructs a ROResponse message, ⁇ ?1"( ⁇ ( ⁇ (3 ⁇ 40> element) is an essential part of the ROResponse message and is sent to the terminal device.
  • the RI After the RI receives the ⁇ ProtectedRO> element, it can construct a license response message and generate and add a digital signature, and send a license response message to the destination device.
  • the inclusion relationship of the elements in the license response message 4 The shape of the structure is as follows:
  • Step 61 License the issuer RI to construct a ⁇ 1 ⁇ 1 ⁇ > element according to the user or system requirement, where the ⁇ KeyInfo> element is empty;
  • Step 62 The CI Agent generates EncryptedCEK, and fills in the ⁇ 3 ⁇ 4 ⁇ 11 ⁇ 0> element in the ⁇ 1 ⁇ 1 ⁇ > element to form a complete ⁇ rights> element;
  • Step 63 The license issuer RI signs the complete ⁇ 1 ⁇ 1 ⁇ > element to obtain ⁇ signature> element;
  • Step 64 The CI Agent generates a 1 ( ⁇ 6> element bound to the destination device, and encapsulates ⁇ 1 ⁇ 1 ⁇ >, ⁇ 8 ⁇ 1 ⁇ 1;1« ⁇ > and ⁇ 61 ( ⁇ 6> elements into the ⁇ 3 ⁇ 4 element >> element, and the ⁇ 3 ⁇ 4)> element is processed by MAC algorithm to form ⁇ 3 ⁇ 4 ⁇ 0 element, ⁇ 3 ⁇ 4)> element and ⁇ 3 ⁇ 4 ⁇ 0 element is mounted as protectedRO ⁇ " ⁇ ;
  • Step 65 The license issuer RI uses the ⁇ 1"( ⁇ ( ⁇ (3 ⁇ 40> element to construct a ROResponse message, issuing a license to the terminal device.
  • the last ⁇ 81 ⁇ 1 ⁇ 1 ⁇ > element is the signature of the RI.
  • the RI does not grasp the CEK of the content, the encapsulated CEK ciphertext EncryptedCEK of the content needs to be requested from the CI Agent, and the RI cannot decrypt the EncryptedCEK:.
  • the CI Agent encapsulates the K REK used to encrypt the CEK and the KMAC that guarantees the integrity of the license.
  • the RI does not own the private key of the destination device, so it cannot decrypt the K REK and KMAC to ensure the CEK pair. RI's confidentiality.
  • RI can not modify the license, because the license is protected by the CI Agent using KMA C integrity, which can effectively prevent the RI from modifying the permission information in the license, and prevent the RI from using the acquired EncryptedCEK and encapsulation to the destination device in the future.
  • K REK and KMAC issue additional licenses for this device.
  • the license issuance control information is in accordance with the issuer license IR0 scheme, and a flowchart of an embodiment for controlling the RI issue license is as shown in FIG.
  • the CI Agent uses the IR0 to control the RI issuance license, it needs to update the status information of the IR0 in time after controlling the RI to successfully issue the license.
  • the message flow of the CI Agent and the RI interaction may also be changed.
  • the process diagram is shown in Figure 8. The operation steps of the solution flow are as follows:
  • Step 81 The RI receives a request for the user to generate a license for the device, and then encapsulates the content identifier CID of the corresponding one or more requests, and the key encapsulation algorithm in the support algorithm information negotiated with the destination device, together with the request message. Inside, sent to CIAgent.
  • Step 82 The CI Agent finds the associated CEK according to the CID of the content, and randomly generates a K REK , and encapsulates the CEK by using the K REK and the key encapsulation algorithm obtained in step 81. ⁇ EncryptedCEK>/G ⁇ .
  • Step 83 The CI Agent will encapsulate the obtained CEK ciphertext, that is, the ⁇ £1 0 16 ( ⁇ 3 ⁇ 4 > element, and return it to the RI.
  • Step 84 The RI fills the ⁇ 1.17 16 ( ⁇ 3 ⁇ 410 element into the ⁇ Rights> element and submits the complete ⁇ Rights> element included in the request generation permission to the CI Agent (if it is necessary to include the ⁇ 1 ⁇ > element) Signature, RI will also generate and attach the signature ⁇ 1 ⁇ 1 ⁇ > element), some necessary license attributes, etc., device certificate chain (can also be accompanied by an OCSP response or certificate invalidation list for verifying the validity of the device certificate chain) CRL, or device ID only)), and other supporting algorithm information such as key transmission algorithm and MAC algorithm negotiated with the destination device.
  • Step 85 The CI Agent will first determine whether to allow response to this request based on the license issuance control information it owns, and reject the request if it is not allowed, otherwise continue the following processing. Then, according to the certificate chain of the destination device (if it is only the device ID, it is necessary to obtain the certificate chain of the device), and the corresponding certificate verification material to verify whether the device certificate is still valid, the CI Agent may need to respond from the online certificate status protocol OCSP. Server or certificate invalidation list The CRL directory server obtains verification material such as an OCSP response or certificate invalidation list CRL for verifying the validity of the destination device certificate. If the device certificate is invalid, reject the request, otherwise continue with the following processing.
  • the CI Agent randomly generates a K MAC , which is connected with the K REK generated in step 82, and encapsulates the connection values of K REK and K MAC to obtain an ⁇ encKey> element according to the key transmission algorithm in the support algorithm obtained in step 84. If a ⁇ timestamp> element is required, it can be included by the RI in step 84 above, or it can be generated by the CI Agent itself after synchronizing with the RI.
  • the CI Agent assembles the ⁇ ro> element of type ROPayload and applies the corresponding ⁇ 3 ⁇ 4 ⁇ element to the ⁇ 3 ⁇ 4)> element applying the MAC algorithm in the support algorithm known in step 84. In the end, the CI Agent will have all the information needed to assemble the complete ⁇ ?1"( ⁇ ( ⁇ (3 ⁇ 40> element).
  • Step 86 In order to reduce the amount of data for communication, the CI Agent may only choose to send the ⁇ encKey> element and the ⁇ 3 ⁇ 4 ⁇ element generated for the destination device to the RI, and the RI is responsible for assembling the ⁇ 1"( ⁇ ( ⁇ (3 ⁇ 40> element)
  • the CI Agent can also be assembled into a complete ⁇ ProtectedRO> and then sent to the RI, and the RI generates a license response to the target device.
  • the CI Agent can store this license for subsequent CI Server statistics.
  • the status reporting mechanism of the CI and the RI can be added to further ensure the accuracy of the RO delivery result of the CI statistics, and at the same time protect the rights of the RI, so that the DRM Agent fails to obtain the RO, and the CI performs statistics according to the success.
  • the operation steps of the solution flow are shown in Figure 9. The brief description is as follows:
  • Process triggering event After the RI receives the RO delivery status report reported by the destination receiving device, the RI processes the status report, and the replication status report is reported to the CI agent;
  • Step 91 The RI sends a Cooperate-StatusReportRequest message to the CI Agent, where the message includes the following parameters:
  • the RI configuration request message includes: a corresponding device certificate chain (which may also be accompanied by an OCSP response for verifying the validity of the device certificate chain or a certificate invalidation list CRL, or only the ID of the device), support algorithm information negotiated with the destination receiving device, And status reports signed by the receiving device.
  • the RI sends the constructed request message to the CI Agent.
  • Step 92 The corresponding processing flow of the CI Agent is as shown in FIG. 10, and includes the following steps: Step 101: The CI Agent will first determine whether to allow the response based on the license issuance control information and/or the history information of the issuance permission. request. If so, continue with the following processing steps, otherwise reject the request.
  • Step 102 The CI Agent then verifies whether the device certificate is still valid according to the device's certificate chain (if the device ID is required to obtain the device's certificate chain) and the corresponding certificate verification material, and the CI Agent may also need to respond from the OCSP itself.
  • the server or CRL directory server obtains verification material such as an OCSP response or a certificate invalidation list CRL for verifying the validity of the device certificate.
  • Step 103 Perform processing according to the result of verifying the device certificate. If the device certificate status is still valid, continue with the following processing steps, otherwise reject the request.
  • Step 104 The CI agent updates the status of the RO delivery record or updates the statistics according to the result of the status report.
  • step 93 The CI Agent returns the status of the report to the RI.
  • all the ROs can be sent to the CI Agent by default.
  • the RI can only report the status of the failed status (including various failure reasons) to the CI Agent. If the corresponding status is not received within the time interval, the default is that the RO is successfully delivered. This can reduce the number of status report messages between the CI Agent and the RI, improving overall system performance.
  • a CI Control RI release license may also be implemented under the Marlin framework.
  • the content object ( Content ) contains the content ID and content data.
  • the content data uses a symmetric key ContentKey.
  • a license is used to protect content and associate usage rules (control) onto protected content. Specifically includes:
  • Content Key Object The key and key ID of the content corresponding to the encryption license.
  • the content key is encrypted with the node key bound to the content.
  • the node can be a user account, domain, device, etc.
  • the key can be Is a public key or a symmetric key.
  • Protector A binding between a key used to represent content and protected content.
  • Control object A rule that governs how keys are used to decrypt content.
  • Controller object A binding between the ContentKey and the Control that manages its use.
  • the terminal will use the content in the ContentKey object to decrypt the key only under the management of the rules in the Control object, thereby using the content associated with the Protector object.
  • the Controller object must be signed to establish a valid binding between the ContentKey and the Control object that manages it, as well as a valid binding between the ContentKey ID and the actual key data.
  • the signature of the Controller object can be a public key signature or a symmetric key signature, or a combination of the two.
  • the solution is also used by the CI Agent as a server role to control and assist the RI to issue licenses in response to RI requests.
  • the interaction protocol and process diagram between them are shown in Figure 12. The operation steps of the solution flow are briefly described as follows:
  • the RI receives a request from the user to generate a license for its device or user account, or is triggered by the system to periodically generate a license for a user for a period of time, or for other reasons, may trigger the following process;
  • Step 121 The RI sends a Cooperate-ObjectsRequest message to the CI Agent, where the message includes at least the following parameters: an object representing the user account node or the device node (and possibly a link object connecting the user and the device), the request The ID of the content object.
  • the RI may also use the device certificate, the supporting algorithm information negotiated with the requesting device, and the indication information that the RI needs to sign the license, the signature of the request message or the MAC value, etc. (if there is no RI between the RI and the CI Agent) To use the secure channel, you need to add a signature; if you use SAC, you can add a MAC value; if you use another secure channel, you can choose).
  • the RI sends the constructed request message to the CI Agent. If the RI does not need to be signed for the license, or the CI needs to add the Agent control to the Control object.
  • the message also needs to include a Control object that specifies the usage rights of the content (if the CI does not need to strictly control the control information in the license generated by the RI, but only needs to pay attention to the RI to generate a license for a certain user or device, And the CI does not need to add an Agent in the Control object, then only the ID and hash value of the Control object can be sent); otherwise, the RI can choose to include in this message or the message in the following step 124.
  • Step 122 The CI Agent verifies the validity of the device certificate and the validity of the association between the node object (and possibly the link object). After the validity verification is passed, according to the ID of the content object, a corresponding ContentKey object, Protector object bound to the device node or the user account node is generated.
  • Step 125 If there are the above steps 123-124, the CI Agent generates a corresponding symmetric key signature for the Controller object (including the private key signature of the RI) by using the encryption key CEK of the content object according to the support algorithm information obtained in step 121. And embedding the symmetric key signature into the Controller object (or directly providing the corresponding symmetric key signature); otherwise, the CI Agent generates the Controller object, and according to the support algorithm information obtained in step 121, uses the encryption key ContentKey of the content object. The Controller object generates the corresponding symmetric key signature.
  • Step 126 The CI Agent encapsulates the generated object in a response message and sends a response message to the RI.
  • the CI Agent can store this license for subsequent reporting to the CI Server.
  • Step 127 This is an optional step, and the specific implementation depends on the actual situation of the RI.
  • the RI sends all license-related information to the destination terminal device.
  • the public key signature of the Controller object is optional, if the RI does not need to generate a public key signature for the Controller object, the interaction between the RI and the CI Agent can be simplified to one. For the message.
  • the RI may also choose not to send the permission information of the license (ie, the Control object) to the CI Agent, but only submit the ID and hash value of the permission information to the CI Agent.
  • the publisher or the CP of the digital content can flexibly deploy its own functional modules according to its own business needs, and at the same time meet the requirements of security, scalability, controllability and the like.
  • the CI Agent can effectively control the RI release license, but does not require modification of the terminal device implementation.
  • the device can still be developed and operated based on the existing OMA DRM or Marlin standards.
  • the solution can be: CI implements its own CI Agent function module according to the plug-in method.
  • the functional components of the CI Agent need to verify the integrity when calling, to prevent tampering or replacement, and need a secure executable. Environment, this can be done with security hardware and more.
  • CI installs the CI Agent plug-in to the RI server in an out-of-band manner. It can require a network connection between the CI Agent and the CI Server, or it can have no connection mechanism and completely use the out-of-band method to transfer data.
  • the system architecture diagram of the scheme is shown in Figure 13.
  • the RI server On the RI server, you can install a number of different CI agent module CI Agent plug-ins, which work independently of each other.
  • the RI has the ability to manage the CI Agent plug-ins installed on its own servers, including the installation, maintenance, deactivation, uninstallation, etc. of the plug-ins.
  • the RI may require the CI to code its CI Agent plug-in accordingly to properly identify and manage the corresponding CI Agent plug-in.
  • the registration information includes the parameters shown in the following table: Table 3 Registration information of the CI Agent plug-in on the RI
  • the service port of the CI Agent which can be an assigned address (whether it is only an internal address, a Network Address Translation (NAT) address or an IP address that can be directly accessed from outside) and a port number, or a service for interprocess communication. Interface scheme, and so on.
  • NAT Network Address Translation
  • RI can find and interact with the service port or service interface of the relevant CI Agent plug-in when it needs a digital content issued by a CI.
  • the CI Agent plug-in will provide the corresponding interface (either through the network connection with the CI Server, or through the graphical interface and the USB port, MMC/SD/CF card interface, etc.), and obtain information about the content such as the content identifier from the CI Server. CID, content CEK bound to CI Agent: other identification information of content, etc. After receiving the information, the CI Agent allows the RI to obtain the content information through the interface with the RI or the content database shared with the RI.
  • the content information that the RI needs to know includes the parameters shown in the following table:
  • the internal identifier of the CI or CP to which the RI belongs may be determined by the content CID, and then the corresponding CI/CP ID is known; Then the CI/CP ID can be used to determine the corresponding CI Agent plugin and its service port.
  • the CEK ciphertext bound to the CI Agent it can be obtained by the RI, and encapsulated in the request and sent to the CI Agent; or the CI Agent obtains itself according to the content CID. With the help of secure hardware devices, CI Agent will be able to get the clear text of CEK.
  • the CI Agent In order to control the RI release license, the CI Agent needs the corresponding license release control information.
  • the IRO solution mentioned in the above technical solution may be adopted, and the CI server issues the IRO for the CI Agent, and the CI Agent serves as the client of the IRO DRM mechanism, and the IRO controls the RI issuing license.
  • the CI Agent plug-in will provide the corresponding interface (either through a network connection to the CI Server, or through a graphical interface and USB port, MMC/SD/CF card interface, etc.), IRO from the CI Server, and responsible for maintaining the IRO. Status information, which also requires the help of a secure hardware device. After the CI Agent successfully controls the RI release license, the status information of the IRO needs to be updated.
  • the RI can be provided with an inquiry function for the remaining status of the IRO, which is used to generate an alarm to the RI when the authority allocation reaches a certain threshold.
  • RI gives the query conditions (such as less than 100 times of remaining licenses) and sends this query condition to all CI Agent plugins.
  • the CI Agent plug-in will query the status information of its own IRO and return the comparison result of the remaining rights information and query conditions to the RI. Or only the qualified CI Agent plug-in needs to send the alarm information to the RI.
  • FIG. 14 A flowchart of an embodiment is shown in FIG. 14, and includes the following steps:
  • Step 141 License the issuer according to the user or system requirements.
  • the RI submits the CID of one or more contents and the possible CEK ciphertext to the CI Agent.
  • Step 142 The CI Agent processes the CEK:.
  • Step 143 The CI Agent returns the processed CEK plaintext to the RI.
  • Step 144 The license issuer RI constructs a ROResponse message and sends a license to the terminal device.
  • the interaction protocol and process between the CI Agent and the RI given in the scheme of FIG. 4, 8 or 12 above may also be adopted, and the RI issuing license is controlled by the CI Agent plug-in.
  • a method for issuing a license provided by an embodiment of the present invention, as shown in FIG. 15, includes: Step 151: A content issuer receives a request for a license issuer to assist in generating a license;
  • Step 152 The content issuer encapsulates the content-related information by using the key of the target entity to obtain the encapsulation key according to the information carried in the request for assisting the generation of the license, and generates a message verification code for the part of the license information;
  • Step 153 The content issuer sends the generated message verification code and the obtained package key to the license issuer, so that the license issuer sends the license containing the message verification code and the encapsulation key to the license issuer. Destination entity.
  • step 152 is specifically:
  • the content issuer obtains information related to the content, authority information of the content used by the target entity, and key information of the destination entity according to the information carried in the request for assisting the generation of the license;
  • the content issuer finds an associated content encryption key based on the content-related information; the content issuer generates a license encryption key and a message verification key, and encapsulates the content encryption key using the license encryption key Encapsulating the license encryption key and the message verification key with a key of the destination entity to obtain a package key;
  • the content issuer generates a message verification code by using the message verification key pair permission information, wherein the license part information includes content related information, rights information of the target entity use content, and the obtained package key. .
  • step 152 is specifically:
  • the content issuer obtains information related to the content, authority information of the content used by the target entity, and key information of the destination entity according to the information carried in the request for assisting the generation of the license;
  • the content issuer finds an associated content encryption key according to the content-related information; the content issuer encapsulates the content encryption key with a key of the destination entity to obtain a package key; The content issuer generates a message verification code for the partial information of the license by using the content encryption key, where the partial information of the license includes content-related information, rights information of content used by the target entity, and the obtained package. Key.
  • the partial information of the license further includes: the license issuer's information about the content, the right information of the content used by the target entity, and the digital signature of the encapsulated content encryption key.
  • step 152 also specifically includes:
  • the content issuer transmits the encapsulated content encryption key to the license issuer; receives the digital signature of the license issuer; and generates a message verification code for the partial information of the license containing the digital signature.
  • the method further includes: counting the license issuer's license issue information by means of the destination entity confirmation.
  • embodiments of the present invention provide a content distribution device, a license issuance device, and a system for issuing licenses, respectively.
  • the content distribution device provided by the embodiment of the present invention includes:
  • a request receiving unit 161 configured to receive a request for a license issuer to assist in generating a license
  • the assisting unit 162 is configured to: according to the information carried in the request for assisting the generation of the license, encapsulate the content-related information by using the key of the target entity to obtain the encapsulation key, and generate a message 3 for the part information of the license;
  • the response sending unit 163 is configured to send the message verification code generated by the assisting unit 162 and the obtained encapsulation key to the license issuer, so that the license issuer will include the message verification code and the encapsulation The license for the key is sent to the destination entity.
  • the assistance unit 162 includes an information acquisition module 1621, a content key lookup module 1622, a key encapsulation module 1623, and a verification code generation module 1623.
  • each module in the assistance unit 162 is specifically configured to: the information obtaining module 1621, configured to obtain content-related information from the request receiving unit, The destination entity uses the rights information of the content and the key information of the destination entity;
  • the content key search module 1622 is configured to find an associated content encryption key according to the obtained information related to the content
  • a key encapsulation module 1623 configured to generate a license encryption key and a message verification key, and encapsulate the content encryption key using the license encryption key, and encapsulate the license encryption key by using a key of the destination entity And the message verification key to obtain the encapsulation key;
  • the verification code generating module 1624 is configured to generate a message verification code by using the message verification key to the partial information of the license, where the part information of the license includes content related information, rights information of the content used by the target entity, and the The resulting encapsulation key.
  • the modules in the assistance unit 162 are specifically used for:
  • the information obtaining module 1621 is configured to obtain, from the request receiving unit, information related to the content, rights information of the content used by the target entity, and key information of the destination entity;
  • the content key search module 1622 is configured to find an associated content encryption key according to the obtained information related to the content
  • the key encapsulation module 1623 is configured to encapsulate the content encryption key by using a key of the destination entity to obtain a package key;
  • the verification code generating module 1624 is configured to generate a message verification code for the partial information of the license by using the content encryption key, where the part information of the license includes content-related information, rights information of the content used by the target entity, and The resulting encapsulation key.
  • the partial information of the license further includes: the license issuer's information about the content, the right information of the content used by the target entity, and the digital signature of the encapsulated content encryption key.
  • the assisting unit 162 is further configured to send the encapsulated content encryption key to the license issuer, receive the digital signature of the license issuer, and generate a message verification for the partial information of the license including the digital signature. code.
  • the content distribution device provided by the embodiment of the invention further includes: The license issue information of the license issuer is counted in a manner confirmed by the destination entity.
  • the license issuing device provided by the embodiment of the present invention includes:
  • the request sending unit 181 is configured to send a request for assisting the generation of the license to the content issuer
  • the assistance receiving unit 182 is configured to receive, by the content issuer, the information related to the content by using the key of the destination entity according to the request sending unit 181.
  • the permission transmitting unit 183 is configured to send a permission including the message verification code and the encapsulation key received by the response receiving unit 182 to the destination entity.
  • the license issuing device provided by the embodiment of the present invention further includes:
  • the digital signature unit 184 is configured to digitally sign the content-related information, the rights information of the content entity using the content, and the encapsulated content encryption key. At this time, the assistance receiving unit 182 is further configured to receive the content. A message verification code generated by the issuer for the partial information of the license containing the digital signature.
  • the license issuing device further includes: a status reporting unit 185, configured to report, to the content issuer, a status report confirmed by the target entity, so that the Content issuer statistics license release information.
  • a status reporting unit 185 configured to report, to the content issuer, a status report confirmed by the target entity, so that the Content issuer statistics license release information.
  • a system for issuing licenses includes:
  • the content issuer 190 is configured to receive a request for the license issuer to assist in generating the license, and use the key of the destination entity to encapsulate the content-related information to obtain the encapsulation key according to the information carried in the request for assisting the generation of the license, and obtain the encapsulation key. Part of the information generating a message verification code; transmitting the generated message verification code and the obtained package key to the license issuer;
  • a license issuer 199 configured to send the request for assisting to generate a license to a content issuer; receiving the message verification code and the encapsulation key sent by the content issuer; the message verification code and the The license to encapsulate the key is sent to the destination entity.
  • the content issuer 190 is specifically configured to assist the student according to the Obtaining information related to the content, information about the content used by the target entity, and key information of the destination entity; obtaining the associated content encryption key according to the information related to the content; generating Encrypting a key and a message authentication key, and encapsulating the content encryption key using the license encryption key, encapsulating the license encryption key and the message verification key using a key of the destination entity to obtain a package key And generating, by using the message verification key, the message verification code, wherein the part information of the license includes content-related information, rights information of the content usage content of the target entity, and the obtained encapsulation key.
  • the content issuer 190 is specifically configured to obtain, according to the information carried in the request for assisting to generate a license, information related to the content, rights information of the content used by the target entity, and key information of the target entity; Obtaining an associated content encryption key according to the content-related information; encapsulating the content encryption key with a key of the destination entity to obtain a package key; generating a message for the licensed partial information by using the content encryption key a verification code, where the partial information of the license includes content-related information, rights information of content used by the target entity, and the obtained encapsulation key.
  • the license issuer 199 is further configured to generate a digital signature for the content-related information, the rights information of the content usage content of the target entity, and the encapsulated content encryption key;
  • the content issuer 190 is further configured to send the encapsulated content encryption key to the license issuer, receive the digital signature of the license issuer, and generate a message for the partial information of the license including the digital signature. Verification code.
  • the content issuer is divided into a content distribution server 191 and one or more content distribution agents (192, 193, 194...) according to the function module.
  • the content distribution server 191 stores all the licensed content information and the corresponding content encryption key, and manages related information of all content distribution agents; the content distribution agent (192, 193, 194...) only saves the associated license Content information and a corresponding content encryption key; wherein, the content distribution server 191 manages related information of all content distribution agents, including: Registration and activation of the content distribution agent; acquisition of the content encryption key by the content distribution agent; control information of the content distribution agent for obtaining the release license; content release agent reporting the release information of the release license to the content distribution server; and security verification of the content distribution agent , change configuration or function module upgrade.
  • One deployment method is as shown in FIG. 2, the content distribution server is deployed on a local area network where the content issuer is located, and the content distribution agent is deployed on a local area network where different license issuers are located.
  • This deployment method is suitable for some large-scale, content-rich content publishers or content providers.
  • FIG. 13 Another deployment method is as shown in Fig. 13, the content distribution agent is registered as a plug-in to the license issuer, and the content distribution server encodes its own content distribution agent. This deployment method is suitable for some small content publishers or content providers, using a lightweight solution that also controls the license issuer's release license.
  • the destination entity is a licensed destination receiving device (or a licensed target object or a licensed use entity), so the destination entity or the destination receiving device is also included in the above solution. Directly referred to as the destination device.
  • the destination entity here may be the destination user or destination device, i.e., the destination user node or destination device node acting as the license recipient.
  • the storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), or a Random Acces s Memory (RAM).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Power Engineering (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Description

发行许可的方法、 装置和系统 技术领域
本发明涉及数字版权保护技术领域， 尤其涉及一种发行许可的方法、 装 置和系统。 背景技术
数字版权管理（ Digital Rights Management, DRM )主要通过权利限制和 内容保护方案控制数字内容的使用， 保护内容所有者的合法权益。 数字内容 的发行者 （ Content Issuer, CI )或提供者（ Content Provider, CP )将数字内容 加密后，用户将加密的数字内容数据包下载到目的实体上；许可发行者（Rights Issuer, RI/License Server ) 负责为内容数据包发放对应的许可， 许可中包括内 容解密密钥及对应的权限。 目的实体只有同时拥有内容数据包和许可， 才能 正常使用数字内容。 发明内容
本发明的一个实施例提供了一种发行许可的方法， 包括：
内容发行者接收许可发行者协助生成许可的请求；
内容发行者根据所述协助生成许可的请求所携带的信息， 使用目的实体 的密钥封装内容相关的信息得到封装密钥， 并对许可的部分信息生成消息验 证码；
内容发行者将生成的消息验证码和得到的封装密钥发送给所述许可发行 者， 以使得所述许可发行者将包含所述消息验证码和所述封装密钥的许可发 送给目的实体。
本发明的另一个实施例提供了一种内容发行设备， 包括：
请求接收单元， 用于接收许可发行者协助生成许可的请求；
协助单元， 用于根据所述协助生成许可的请求所携带的信息， 使用目的 实体的密钥封装内容相关的信息得到封装密钥， 并对许可的部分信息生成消 息验证码；
响应发送单元， 用于将所述协助单元生成的消息验证码和得到的封装密 钥发送给所述许可发行者， 以使得所述许可发行者将包含所述消息验证码和 所述封装密钥的许可发送给目的实体。
本发明的再一个实施例提供了一种许可发行设备， 包括：
请求发送单元， 用于向内容发行者发送协助生成许可的请求；
响应接收单元， 用于接收所述内容发行者根据所述请求发送单元， 使用 目的实体的密钥封装内容相关的信息得到的封装密钥， 和对许可的部分信息 生成的消息验证码；
许可发送单元， 用于将包含所述响应接收单元接收的消息验证码和封装 密钥的许可发送给目的实体。
本发明的再一个实施例提供了一种发行许可的系统， 包括：
内容发行者， 用于接收许可发行者协助生成许可的请求， 根据所述协助 生成许可的请求所携带的信息， 使用目的实体的密钥封装内容相关的信息得 到封装密钥， 并对许可的部分信息生成消息验证码； 将所述生成的消息验证 码和所述得到的封装密钥发送给所述许可发行者；
许可发行者， 用于向内容发行者发送所述协助生成许可的请求； 接收所 述内容发行者发送的所述消息验证码和所述封装密钥； 将包含所述消息验证 码和所述封装密钥的许可发送给目的实体。
通过本发明实施例提供的上述技术方案可知， 内容发行者根据许可发行 者的协助生成许可的请求， 使用目的实体的密钥封装内容相关的信息得到封 装密钥， 并对许可的部分信息生成消息验证码， 由所述许可发行者将包含所 述消息验证码和所述封装密钥的许可发送给目的实体， 由于许可发行者无法 解密封装密钥， 从而保证封装密钥对许可发行者的机密性， 并且由于消息验 证码对许可的部分信息进行了完整性保护， 有效防范了许可发行者篡改包括 权限信息的许可内的信息， 以及有效防范了许可发行者伪造许可， 因此实现 附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实 施例或现有技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面 描述中的附图仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动性的前提下， 还可以根据这些附图获得其他的附图。
图 1是本发明实施例提供的一种发行许可系统架构示意图；
图 2是本发明实施例提供的一种发行许可系统拓朴结构示意图； 图 3是本发明实施例提供的一种发行许可系统内部功能模块结构示意图； 图 4是本发明实施例提供的一种发行许可的方法流程示意图；
图 5为图 4中内容发行代理的相应处理流程示意图；
图 6为本发明实施例提供的另一种发行许可的方法流程示意图； 图 7为本发明实施例采用发行者许可进行控制的流程示意图；
图 8为本发明实施例提供的再一种发行许可的方法流程示意图； 图 10为图 9中内容发行代理的相应处理流程示意图；
图 11为本发明实施例提供的 Marlin系统中内容和许可的组成结构图； 图 12为本发明实施例提供的又一种发行许可的方法流程示意图； 图 13为本发明实施例提供的另一种发行许可系统的架构示意图； 图 14为图 13系统下提供的一种发行许可的方法流程示意图；
图 15为本发明实施例提供的发行许可的方法流程图；
图 16为本发明实施例提供的内容发行装置的一种结构示意图；
图 17为图 16提供的协助单元的一种结构示意图；
图 18为本发明实施例提供的许可发行装置的一种结构示意图；
图 19为本发明实施例提供的许可发行系统的一种组成示意图。 具体实施方式
下面结合附图和具体实施例对本发明提供的技术方案进行说明， 可以理 解的是， 本发明实施例只是举例， 并不用以限制本发明的保护范围， 本发明 的保护范围由权利要求书确定。
在实现本发明过程中， 发明人研究发现： 现有的数字版权保护系统中， 当 CI和 RI分别属于不同的商业实体时， 或者分别属于集团总公司和下属子 公司时， CI不能从 RI获知数字内容的准确的发行情况， 包括： 使用用户、 许 可包含的权限信息等等， 这对 CI所属的商业实体的管理非常不利， 使其无法 按照数字内容实际发行情况进行计费或者作为制定商业合同的参考， 无法对 RI进行有效的控制或者监督管理， 从而无法充分保护自身的利益。
本发明实施例通过让 CI参与到 RI封装、 发行许可的过程中去， CI负责 封装许可的关键部分， RI负责发行这个许可，从而实现 CI控制 RI发行许可。 为了满足部署实施的灵活性， 以及及时响应 RI请求等需求， 将 CI根据功能 模块划分为 CI Server ( CI服务器 )和 CI Agent ( CI客户端代理）， CI Server 部署在 CI本地局域网， CI Agent则可以部署到 RI所在的局域网。基于安全性、 可控可管等多种因素考虑， CI Agent优选部署方案为安装在独立的机器上或者 逻辑独立的虚拟机上。 本发明的系统架构图如图 1所示。
在上述系统架构图中， CI拥有对 CI Server和 CI Agent的完全控制权和管 理权， CI Server可以部署在 CI处， 而 CI Agent则可以根据业务需要部署到不 同 RI处。 当然， 也可以根据支持不同 RI业务的需要， 对相应的 CI Agent进 行某种程度的定制或者修改。 而如果网络情况及处理性能等均能满足 RI业务 需求的话， 也不排除将 CI Agent和 CI Server部署在同一处。 或者， CI也可以 将 CI Server和 CI Agent进行合设，由同一个模块来提供 CI Server和 CI Agent 的全部功能。 部署方案可以为一个集中式的后台 CI Server, 连接若干个 CI Agent前端代理， 其拓朴结构图如图 2所示。
CI Server作为 CI的核心， 保存着该 CI所拥有的所有数字内容及其相应 的内容加密密钥 CEK ( Content Encryption Key )信息， 和关联 RI建立的商业 联系及业务策略、 规则等， 以及管理所有 CI Agent的相关信息。 CI Server和 的，也能够通过构造保护消息对数据进行保护。 CI Agent作为部署到某个具体 RI处的代理机构， 可以只存储与该关联 RI业务相关的部分内容及其相应的 CEK, 以及和该 RI相关的业务策略、 规则等。 它们的功能模块结构示意图如 图 3所示。
CI Server和 CI Agent之间可能存在如下一系列的交互联系：
1、 注册和启用： CI Agent需要注册到 CI Server, 在相互认证通过后交换 一些必要的信息， 以及建立供后续通讯使用的安全验证通道 （ Secure Authenticated Channel, SAC )等。 CI Server也可规定 CI Agent只有在被激活后 才能够正常启用， CI Agent向 CI Server发出启用请求， CI Server通过启用响 应消息激活 CIAgent。
CI Agent注册到 CI Server并需要激活才能启用， 有利于实现对 CI Agent 的管理。 CI Server甚至能在后续锁定 CI Agent, 使之暂停或停止运作。
2、 内容 CEK的获取： 由于 CI Agent可能仅存储部分内容的 CEK, 所以 在 CI Server增加新的数字内容之后， 需要及时触发 CI Agent进行更新； 或者 设定 CI Agent定期向 CI Server请求是否有内容增加而需要更新， 这个时间期 限可以通过 CI Agent配置来确定， 或者使用更新策略等确定。
CI Server可以选择增量更新或者全部更新的方式，优选方案为增量更新。
CI Server将自上次更新以后发生更新的内容标识 CID及其 CEK绑定到 CI Agent, 并封装在响应消息中返回给 CI Agent; 如果没有更新发生则在响应消 息中无需包括任何 CID及其 CEK：。 CI Agent接到响应消息后进行处理， 如果 有新增内容的 CEK, 则更新到自己的局部业务和内容数据库中。
3、 许可发行控制信息的获取： CI Agent通过业务控制模块和许可发行控 制信息来控制 RI发行许可， 而许可发行控制信息则由 CI Server提供给 CI Agent。 许可发行控制信息可以基于与相关 RI 的商业联系或合同等制定的许 可发行策略、 规则或者采用发行者许可（Issuer RO, IRO )等方式。 而如果 CI Agent基于 IRO控制 RI进行许可发放的话， 则 CI Agent将作为 IRO机制的 DRM客户端， CI Server向其发行 IRO; CI Agent每次为 RI生成一个许可后， 都将消费掉 IRO的相应权限。
当 CI Server端的许可发行控制信息发行变化时， 需要主动触发 CI Agent 来获取； 或者由 CI Agent定期向 CI Server提交许可发行控制信息请求消息， 这个时间期限可以通过 CI Agent配置的确定， 或者使用策略等确定， 或者在 IRO消费完之后由 CI Agent及时向 CI Server请求新的 IRO。 CI Server根据请 求返回相应的许可发行控制信息。
4、 CI Agent向 CI Server上报许可发行统计信息： CI为了便于掌握了解 某个 RI处的内容销售情况， 可以让 CI Server触发 CI Agent上报许可发行统 计信息， 或者由 CI Agent定期向 CI Server上报许可发行统计信息， 这个时间 期限可以通过 CI Agent配置的确定， 或者使用上 策略来确定。 可以上 4艮累 计数据， 或者分类统计数据； 可以实行总量上传， 或者只是增量上传。 同样， CI Server可以通过配置或者策略等， 规定 CI Agent是否需要在上报统计数据 成功后删除所述已上报数据。 如果 CI Agent采用的是 IRO方案， 也可以不用 上才艮统计信息， CI Server基于 IRO自行统计。
5、 安全检验、 更改配置或者功能模块升级： CI Server 为了确保部署在 RI处的 CI Agent的安全性和正确性 , 可以对 CI Agent进行安全性检验如年检 等， 这可以通过诸如远程登录或远征桌面、 远程证明 （ Remote Attestation )、 功能有效性验证等不同方式。 此外， CI Server可以在需要更改 CI Agent配置 或者 CIAgent某些功能模块需要升级时触发 CI Agent进行相应处理。
上述图 1的系统架构图中 CI Server和 CI Agent之间使用虚线连接， 表示 它们可以不用一直保持网络连接，甚至可以完全没有连接机制。这样的话， CI Server和 CI Agent之间也可能采用带外（ out-of-band )的方式进行必要的操作 如激活启用、 安全检验、 CI Agent更改配置以及数据传递， 例如使用光盘或者 移动设备等， 把新增内容的信息如 CID及其 CEK等、许可发行控制信息如许 可发行策略、 规则或者 IRO的更新提供给 CI Agent, 或者从 CI Agent处收集 获取许可发行统计信息。
CI Agent和 RI服务器之间需要建立及时可靠的连接， 由 CI Agent充当服 务器角色， 响应 RI的请求， 控制并协助 RI发行许可。 它们之间的交互协议 和流程示意图如图 4所示。 该流程的操作步骤简要描述如下：
初始化步骤： 在 CI Agent和 RI正式进行业务联系之前， 可能需要先完成 注册或者双向身份认证， 并在此基础上建立起安全通道 (当然也可以通过预 设共享密钥和算法或者安全套接层协议层 (Secure Socket Layer, SSL)等方案建 立安全通道）， 保障后续的通讯会话。
流程触发事件： RI收到用户为其设备生成许可的请求， 或者由系统触发 为某订阅用户在一段时期内定期为其设备生成许可， 或者由于其他原因， 都 可能触发以下流程；
步骤 41 , RI向 CI Agent发出协助生成许可的请求（ Cooperate-RORequest ) 消息， 该请求消息中包括如下参数：
表 1 Cooperate-RORequest消息参数
Figure imgf000009_0001
在上述表 1的 Status栏中， 值为 "M" 代表 Mandatory, 是必须包含； 而 值为 "0"则代表 Optional, 可以包含这一项。 后面表格的解释与此相同。
RI构造请求消息包括： 把相应的请求的内容标识 CID、 请求的权限等封 装到一个<1^§]^>元素内， 但并不包括 <EncryptedCEK>元素 （可选的， RI并 不封装成<^^1^>元素， 而是只提供 CID和权限等信息）， 此外， RI还将把设
( Online Certificate Status Protocol ) 响应或者证书作废列表 CRL ( Certificate Revocation List ), 或者仅仅设备的 ID, 和请求设备协商的支持算法信息、 为 该许可分配的 roID等属性信息， 以及 RI是否需要为该许可签名的指示信息， 对请求消息的签名或 MAC值等，如果 RI和 CI Agent之间没有使用安全通道， 需要添加签名；如果使用了安全授权通道 SAC( Secure Authenticated Channel ), 可以添加消息验证码 MAC ( Message Authentication Code )值； 而若使用了其 他安全通道则可选。 RI把构造好的请求消息发送给 CI Agent。
为了确保整个协议流程的完整性， 可以在协议所有步骤的消息中添加相 应的会话标识（session id ), 或者对消息添加随机数（Nonce )参数项来保证 消息的新鲜性及防重放攻击；
步骤 42: CI Agent的相应处理流程如图 5所示：
步骤 501 , CIAgent将首先基于其拥有的许可发行控制信息， 判断是否允 许响应这次请求。 如果允许则继续下面处理步骤， 否则拒绝这次请求。
步骤 502, CI Agent接着根据设备的证书链 (若是设备 ID的话则还需要 去获取设备的证书链）， 以及相应的证书验证材料来验证设备证书是否仍然有 效， CI Agent可能还需要自己从 OCSP响应服务器或 CRL目录服务器获取验 证设备证书有效性的验证材料如 OCSP响应或者证书作废列表 CRL。
步骤 503 ,根据验证设备证书的结果进行处理。如果设备证书状态仍然有 效则下面处理步骤， 否则拒绝这次请求。
步骤 504, CIAgent根据内容的 CID, 查找并获取到相关联的 CEK, 这里 可能有多个 CID, CEK也可能需要进行解密处理。
步骤 505, 随机产生一个 KREK, 并使用 KREK及在步骤 501中获知的支持算 法中的密钥封装算法对 CEK进行封装处理， 得到一个或多个< 1 07 16(^¾ > 元素， 并填充到 <Rights>元素内。 仍参见图 4, 步骤 43〜步骤 44: 这两个步骤是否需要取决于前面步骤 41 中 RI是否需要为该许可签名的指示信息值。 如果指示需要， 则必须执行； 否 则可以直接跳转到步骤 45 继续执行。 CI Agent把<^^1^>元素 （或者对 <1^1^>元素进行 XML规范化后， 按照步骤 41 中获得的支持算法中的签名 算法所使用的哈希算法， 计算 <Rights>元素的 Hash值， 这样的话仅需包括其 Hash值）封装在协助生成许可的响应 （Cooperate-ROResponse ) 消息中发送 给 RI。 RI根据所接收到 <Rights>元素 （或者其 Hash值）， 产生数字签名， 并 把 该 数 字 签 名 封 装 在 协 助 生 成 受 保 护 许 可 请 求 ( Cooperate-protectedRORequest ) 消息内返回给 CI Agent。
步骤 45: CI Agent根据步骤 41中获知的支持算法中的密钥传输算法， 随 机产生一个 KMAC, 连接上面步骤 42 中的 Krek得到 KREK|Kmac, 并对此连接值 进行算法封装。 例如可以应用开放移动联盟 ( OMA )的数字版权管理 ( DRM ) 标准默认的密钥传输算法 RSAES-KEM-KWS的处理过程进行处理。
CI Agent随机生成一个 Z, 提取目的设备证书中的公钥来加密 Z得到密文 C1 , 对 Z进行密钥导出函数 KDF (密钥导出函数）运算得到一个 KEK, 然后使 用 KEK封装 KREK|KMAC得到密文 C2 ,连接 C1和 C2并编码处理得到 1 (^6 >元 素。 如果需要有 <timestamp>元素， 可以由 RI在上面步骤 41中包括， 也可以由 CI Agent在和 RI实现时间同步后自己产生添加。 CI Agent组装得到类型为 ROPayloac^ <ro>元素， 并对<¾)>元素应用步骤 41 中获知的支持算法中的 MAC算法处理产生相应的<¾^ 元素。 最终， CI Agent将拥有组装完整 <ProtectedRO>所需的所有信息， 并可组装成 <ProtectedRO>元素。
步骤 46: CI Agent将<?1"(^(^(¾0>元素封装在响应消息中发送给 RI。 如 果 RI在上述步骤 43接收到的只 A<Rights>元素的 Hash值的话， RI也可以在 接收到许可时选择验证一下许可内的<^^1^>元素的 Hash值是否与步骤 43 中所接收到的 Hash值相一致。 CI Agent可以存储这个许可， 以便后续向 CI Server汇才艮统计。 步骤 47: 此为可选步骤， 具体实施方案依赖于 RI的实际情况。 RI构造 ROResponse消息， <?1"(^(^(¾0>元素作为 ROResponse消息的必要组成部分， 并发送给终端设备。
RI收到 <ProtectedRO>元素后， 即可构造许可响应消息并产生和添加数字 签名， 并把许可响应消息发送给目的设备。 许可响应消息内元素的包含关系 4对形结构如下所示：
<roResponse>
<protectedRO>
<ro | {ro attributes }> of ROPayload 〃步骤 41
<rights>
<asset> //可能有多个内容 asset
< context><uid>ContentID</uid></context>
< cyInfo
<CipherDitbt>E ii.rv¾riiii?i/C£'A' /CipherDitta>
</asset>
</rights>
<signature> </signature> //可选的， RI ft<rights>7U¾的数字签名 步骤 44
<timeStamp> </timeStamp> //可选的， 步骤 41或 45
<cn c cy>(ietaileil eaiKey vfl/«<?<''cnc ey 〃步骤 45
</ro>
<ιτπέΐΟ detailed mac value over ro<;r iK> 〃步骤 45
</protectedRO> 〃' 聚 46
<signature> </signature> //RI对许可响应消息的数字签名 〃步骤 47
</roResponse> 〃步骤 47
相应的， CI Agent控制并参与 RI发行许可的一个实施例流程图如图 6所 示：
步骤 61、 根据用户或系统需求许可发行者 RI 构造<1^1^>元素， 其中 <KeyInfo>元素为空；
步骤 62、 CI Agent生成 EncryptedCEK, 填入<1^1^>元素中的<¾^ 11^0> 元素内， 形成完整的 <rights>元素；
步骤 63、 许可发行者 RI对完整的<1^1^>元素进行签名得到 <signature> 元素；
步骤 64、 CI Agent生成绑定到目的设备的 1 (^6 >元素， 将<1^1^>、 <8 §1^1；1«^>和<61 (^6 >元素封装到<¾)>元素，并对 <¾)>元素进行 MAC算法处 理形成<¾^0元素， ^夺<¾)>元素和<¾^0元素 †装成 protectedRO ^"^；
步骤 65、许可发行者 RI用^1"(^(^(¾0>元素构造 ROResponse消息， 发 行许可给终端设备。 其中最后的<81§1^1^>元素为 RI的签名。
从流程图图 6可以看出， 由于 RI不掌握内容的 CEK, 需要向 CI Agent请求 内容的经过封装的 CEK密文 EncryptedCEK, RI并无法解密 EncryptedCEK：。 CI Agent把加密 CEK使用的 KREK以及保障许可完整性的 KMAC使用目的设备的公 钥进行封装， 因为 RI并不拥有目的设备的私钥， 所以也无法解密得到 KREK和 KMAC 从而能保证 CEK对 RI的机密性。 并且 RI也无法修改许可， 因为许可由 CI Agent使用 KMAC进行了完整性保护， 这能有效防范 RI修改许可内的权限信 息， 并防范 RI在以后利用已获取到的 EncryptedCEK和封装到目的设备的 KREK 和 KMAC为该设备发行其他许可。
许可发行控制信息采用发行者许可 IR0方案 ,对 RI发行许可进行控制的 一个实施例流程图如图 7所示。
CI Agent如果采用 IR0控制 RI发行许可， 需要在控制 RI成功发行许可 后及时更新 IR0的状态信息。
可选的， CI Agent和 RI交互的消息步骤流程也可进行一些改变， 其流程 示意图如图 8所示， 该方案流程的操作步骤描述如下：
初始化步骤及步骤 87同上述图 4中所给出的技术方案。
步骤 81 : RI接到用户为其设备生成许可的请求， 然后把相应的一个或者 多个请求的内容标识 CID, 以及和目的设备协商的支持算法信息中的密钥封 装算法， 一起封装在请求消息内， 发送给 CIAgent。
步骤 82: CI Agent根据内容的 CID, 查找到关联的 CEK, 并随机产生一个 KREK, 并使用 KREK及步骤 81 中获得的密钥封装算法对 CEK进行封装， 得到 <EncryptedCEK>/G ^。
步骤 83: CI Agent将封装得到的 CEK密文， 即<£1 0 16(^¾ >元素， 返 回给 RI。
步骤 84: RI把< 1。17 16(^¾10元素填充到 <Rights>元素内， 向 CI Agent 提交请求生成许可所包括的完整 <Rights>元素（如果需要包括对<^^1^>元素 的签名， RI还会产生并附上签名 <^§1^1^>元素）， 一些必要的许可属性等， 设备证书链（也可以附带用于验证设备证书链有效性的 OCSP响应或者证书 作废列表 CRL, 或者仅设备 ID ) ), 以及和目的设备协商的其他一些支持算法 信息如密钥传输算法和 MAC算法等。
步骤 85: CI Agent将首先基于其拥有的许可发行控制信息，判断是否允许 响应这次请求， 如果不允许则拒绝这次请求， 否则继续下面处理。 接着根据 目的设备的证书链（若仅是设备 ID则还需要去获取设备的证书链）， 以及相应 的证书验证材料来验证设备证书是否仍然有效， CI Agent可能需要自己从在线 证书状态协议 OCSP响应服务器或证书作废列表 CRL目录服务器获取验证目 的设备证书有效性的验证材料如 OCSP响应或者证书作废列表 CRL。 如果设备 证书无效则拒绝这次请求， 否则继续下面处理。 CI Agent随机产生一个 KMAC, 和步骤 82中产生的 KREK相连接， 并根据步骤 84中获得的支持算法中的密钥 传输算法， 封装 KREK和 KMAC的连接值得到 <encKey>元素。 如果需要有 <timestamp>元素， 可以由 RI在上面步骤 84中包括， 也可以由 CI Agent在和 RI 同步时间后自己产生添加。 CI Agent组装得到类型为 ROPayload的 <ro>元素， 并对<¾)>元素应用步骤 84中获知的支持算法中的 MAC算法产生相应的<¾^ 元素。 最终， CI Agent将拥有组装完整<?1"(^(^(¾0>元素所需的所有信息。
步骤 86: 为减少通讯的数据量， CI Agent可以仅选择把针对目的设备产 生的 <encKey>元素和<¾^ 元素发送给 RI, 由 RI负责组装<卩1"(^(^(¾0>元 素； 当然 CI Agent也可以选择组装成完整的 <ProtectedRO>后再发送给 RI, 由 RI生成许可响应发送给目标设备。 CI Agent可以存储这个许可， 以便后续向 CI Server汇艮统计数据。
为了确保整个协议流程的完整性， 可以在上述所有步骤的消息中添加相 应的会话标识（session id ), 或者对消息添加随机数（Nonce )参数项来保证 消息的新鲜性及防重放攻击。
可选的， 可以增加 CI与 RI的状态报告机制， 进一步确保 CI统计到的 RO下发结果的准确性， 同时保障 RI的权益，以免 DRM Agent获取 RO失败， CI却按照成功进行统计。 该方案流程的操作步骤如图 9所示， 其简要描述如 下：
初始化步骤： 在 CI Agent和 RI正式进行业务联系之前， 可能需要先完成 注册或者双向身份认证， 并在此基础上建立起安全通道 (当然也可以通过预 设共享密钥和算法或者 SSL等方案建立安全通道）， 保障后续的通讯会话。
流程触发事件： RI收到目的接收设备上报的 RO下发结果状态报告后， RI处理状态报告， 同时复制状态报告上报给 CI Agent;
步骤 91 , RI 向 CI Agent 发 出 协助生成状态报告请求 ( Cooperate-StatusReportRequest ) 消息， 该消息中包括如下参数：
表 2 Cooperate-RORequest消息参数
Figure imgf000015_0001
RI构造请求消息包括： 把相应的设备证书链（也可以附带用于验证设备 证书链有效性的 OCSP响应或者证书作废列表 CRL, 或者仅仅设备的 ID )、 与目的接收设备协商的支持算法信息、 和经过接收设备签名的状态报告。 RI 把构造好的请求消息发送给 CI Agent。
为了确保整个协议流程的完整性， 可以在协议所有步骤的消息中添加相 应的会话标识（session id ), 或者对消息添加随机数（Nonce )参数项来保证 消息的新鲜性及防重放攻击； 步骤 92: CI Agent的相应处理流程如图 10所示， 包括如下步骤： 步骤 101 , CI Agent将首先基于其拥有的许可发行控制信息和 /或发行许 可的历史信息等， 判断是否允许响应这次请求。 如果允许则继续下面处理步 骤， 否则拒绝这次请求。
步骤 102, CI Agent接着根据设备的证书链 (若是设备 ID的话则还需要 去获取设备的证书链）， 以及相应的证书验证材料来验证设备证书是否仍然有 效， CI Agent可能还需要自己从 OCSP响应服务器或 CRL目录服务器获取验 证设备证书有效性的验证材料如 OCSP响应或者证书作废列表 CRL。
步骤 103 ,根据验证设备证书的结果进行处理。如果设备证书状态仍然有 效则继续下面处理步骤， 否则拒绝这次请求。
步骤 104, CI Agent根据状态报告的结果， 更新 RO下发记录状态或更新 统计信息。
仍参见图 9, 步骤 93: CI Agent向 RI返回状态^艮告处理结果。
在方案实施上，可以在 CI Agent处默认所有的 RO下发状态均为 "成功"， RI可以只将"失败"状态（包括各种失败原因）的报告上报给 CI Agent, CI Agent 如果在一定时间间隔内未收到对应的状态 ^艮告，则默认为该 RO下发成功。这 样能减少 CI Agent与 RI之间的状态报告消息数量， 提升系统整体性能。
另一实施例， 在 Marlin框架下， 也可实现 CI控制 RI发行许可。
在 Marlin系统中内容和许可的组成形式如图 11所示：
内容对象（ Content ) 包含内容 ID 和内容数据。 内容数据使用对称密钥 ContentKey力口密。
许可对象（ license )用于保护内容并且关联使用规则（控制）到受保护内 容上。 具体包含：
内容密钥对象（ ContentKey ): 包含加密许可对应内容的密钥和密钥 ID , 其中内容密钥使用内容所绑定的节点密钥加密， 节点可以为用户帐户、 域、 设备等， 密钥可以为公钥或对称密钥。。 保护器对象（Protector ): 用于表示内容和保护内容的密钥之间的绑定。 控制 （Control )对象： 表示管理如何使用密钥以解密内容的规则。
控制器（ Controller )对象： 用于表示 ContentKey及管理其使用的 Control 之间的绑定。终端将只在 Control对象中的规则的管理下使用 ContentKey对象 中的内容解密密钥， 从而使用 Protector对象关联的内容。 Controller对象必须 经过签名，从而能够建立 ContentKey和管理它的 Control对象之间的有效绑定， 以及 ContentKey ID和实际密钥数据之间的有效绑定。 Controller对象的签名 可以是公共密钥签名 （ public key signature )或者是对称密钥签名 （ symmetric key signature ) , 或者两者的结合。
该方案同样由 CI Agent充当服务器角色， 响应 RI的请求， 控制并协助 RI发行许可。 它们之间的交互协议和流程示意图如图 12所示， 该方案流程的 操作步骤简要描述如下：
初始化步骤： 在 CI Agent和 RI正式进行业务联系之前， 可能需要先完成 注册或者双向身份认证， 并在此基础上建立起安全通道 (当然也可以通过预 设共享密钥和算法或者 SSL等方案建立安全通道）， 保障后续的通讯会话。
流程触发事件： RI收到用户为其设备或者用户账户生成许可的请求， 或 者由系统触发为某订阅用户在一段时期内定期为其设备生成许可， 或者由于 其他原因， 都可能触发以下流程；
步骤 121 , RI向 CI Agent发出协助对象请求（ Cooperate-ObjectsRequest ) 消息， 该消息中至少要包括如下参数： 表示用户账户节点或设备节点的对象 (及可能的连接用户和设备的链接对象）、 请求的内容对象的 ID。 可选的， RI还可以把设备证书、和请求设备协商的支持算法信息， 以及 RI是否需要为 该许可签名的指示信息，对请求消息的签名或 MAC值等（如果 RI和 CI Agent 之间没有使用安全通道， 需要添加签名； 如果使用了 SAC可以添加 MAC值； 而若使用了其他安全通道则可选）。 RI把构造好的请求消息发送给 CI Agent。 如果 RI不需要为许可签名， 或者 CI需要在 Control对象中增加 Agent控制终 端， 则消息中还需要包括规定内容使用权限的 Control对象（如果 CI不需要 严格控制 RI所产生的许可中的控制信息， 而只需要关注 RI为某个用户或设 备生成了某个许可的话， 且 CI不需要在 Control对象中增加 Agent, 则可只发 送 Control对象的 ID和 Hash值 ); 否则， RI可以选择在这个消息或者下面步 骤 124的消息中包括。
步骤 122, CI Agent验证设备证书的有效性， 以及节点对象（及可能的链 接对象）之间关联的有效性。 在有效性验证通过之后， 根据内容对象的 ID, 产生相应的绑定到设备节点或者用户账户节点的 ContentKey对象、 Protector 对象。
步骤 123 ~步骤 124: 这两个步骤是否需要取决于前述步骤 121 中 RI是 否需要为该许可签名的指示信息值。 如果指示需要， 则必须执行； 否则可以 直接跳转到步骤 125继续执行。 步骤 123: CI Agent把所生成的对象封装在响 应消息（ Cooperate-ObjectsResponse ) 中发送给 RI; 步骤 124: RI根据所接收 到对象信息， 产生 Controller对象， 并对 Controller对象使用自己的私钥进行 签名， 并把 Controller对象封装在协助许可请求 ( Cooperate-LicenseRequest ) 消息内返回给 CI Agent。
步骤 125: 如果有上述步骤 123 ~ 124, 则 CI Agent根据步骤 121中获知 的支持算法信息使用内容对象的加密密钥 CEK对 Controller对象（包含 RI的 私钥签名）产生相应的对称密钥签名， 并将对称密钥签名嵌入到 Controller对 象中 （或者直接提供相应的对称密钥签名）； 否则 CI Agent生成 Controller对 象， 并根据步骤 121 中获知的支持算法信息， 使用内容对象的加密密钥 ContentKey对 Controller对象产生相应的对称密钥签名。
步骤 126: CI Agent把生成的对象封装在响应消息中， 并把响应消息发送 给 RI。 CI Agent可以存储这个许可， 以便后续向 CI Server汇报统计。
步骤 127: 此为可选步骤， 具体实施方案依赖于 RI的实际情况。 RI把所 有与许可相关的信息发送给目的终端设备。 从上述交互协议和流程示意图可以看出， 由于 Controller对象的公共密钥 签名是可选的， 如果 RI不需要对 Controller对象产生公共密钥签名， 则 RI和 CI Agent之间的交互可以简化为一对消息。 此外， 为简化业务模式， RI也可 以选择不把许可的权限信息 （即 Control对象）发送给 CI Agent, 而仅仅把许 可的权限信息的 ID和 Hash值提交给 CI Agent。
通过本发明所提供的技术方案， 数字内容的发行者 CI或提供者 CP可以 根据自己的业务需要灵活部署自己的功能模块， 同时又可满足安全性、 可扩 展性、 可控可管等诸多需求。 此外， 通过 CI Agent可实现有效控制 RI发行许 可， 但却不要求修改终端设备实现， 设备仍然可以基于现有 OMA DRM或者 Marlin标准进行研发和操作使用。
相对而言， 以上技术方案比较适用于规模较大、 内容较多的内容发行者 或内容提供商。 但对于一些较小规模的 CI, 可能不愿花费如此大的代价， 因 此， 也可以考虑一种轻量级的解决方案， 把 CI Agent以插件的形式， 安装到 RI服务器上， 以实现同样的控制 RI发行许可的目的。
该方案可以是： CI把自己的 CI Agent功能模块按照插件的方式进行实现， CI Agent的各功能组件部分在调用时都需要验证完整性，以防止被篡改或者替 换， 并且需要一个安全的可执行环境， 这可以借助安全硬件设备及其他。 CI 把 CI Agent插件通过带外方式， 安装到 RI服务器上， 可以要求 CI Agent与 CI Server之间有网络连接， 也可以没有连接机制， 完全使用带外方式传递数 据。 该方案的系统架构示意图如图 13所示。
在 RI服务器上， 可以安装多个不同 CI的代理模块 CI Agent插件， 它们 彼此独立工作互不干扰。 RI具有管理安装到自己服务器上的 CI Agent插件的 功能，包括插件的安装、维护、停用、卸载等等。 RI可以要求 CI对它的 CI Agent 插件进行相应的代码签名 , 以便正确识别和管理相应的 CI Agent插件。
CI Agent插件在安装到 RI服务器上时，需要注册到 RI系统上，注册信息 包括如下表所示的参数： 表 3 CI Agent插件在 RI上的注册信息
Figure imgf000020_0001
CI Agent的服务端口， 可以是一个分配的地址（不管仅是个内部地址、 网 络地址转换 NAT ( Network Address Translation )地址还是能够从外部直接访 问的 IP地址）和端口号， 或者是进程间通信的服务接口方案， 等等。 CI Agent 一旦运行， 将对其服务端口或服务接口进行侦听， 接收请求并提供相应的服 务。通过这些信息， RI就能够在需要某个 CI发行的数字内容时可以找到相关 CI Agent插件的服务端口或服务接口， 并与之交互。
CI Agent插件将提供相应的接口（可以通过和 CI Server之间的网络连接， 或者通过图形界面以及 USB口、 MMC/SD/CF卡接口等方式）， 从 CI Server 获得内容的相关信息如内容标识 CID、 绑定到 CI Agent的内容 CEK：、 内容的 其他标识信息等。 CI Agent在收到这些信息后， 通过和 RI的接口或者和 RI 共享的内容数据库， 让 RI能获取到这些内容信息。 RI需要获知的内容信息包 括如下表所示的参数：
表 4 CI Agent插件在 RI上的注册信息
Figure imgf000020_0002
通过上述表 3和表 4的信息， 当 RI需要发行某个内容的许可时， 可以通 过内容 CID确定其所属的 CI或 CP的内部标识， 进而得知相应的 CI/CP ID; 再通过 CI/CP ID即可确定相应的 CI Agent插件以及它的服务端口。 至于绑定 到 CI Agent的 CEK密文， 可以由 RI获取到， 一并封装在请求中发送给 CI Agent; 或由 CI Agent根据内容 CID自己去获取。 CI Agent借助安全硬件设备 的帮助， 将能够得到 CEK的明文。
CI Agent为了控制 RI发行许可，需要相应的许可发行控制信息。较佳的， 可以采用上述技术方案所提到的 IRO方案，由 CI Server为 CI Agent发行 IRO, CI Agent作为 IRO DRM机制的客户端，基于 IRO控制 RI发行许可。 CI Agent 插件将提供相应的接口 （可以通过和 CI Server之间的网络连接， 或者通过图 形界面以及 USB口、 MMC/SD/CF卡接口等方式）， 从 CI Server获得 IRO, 并负责维护 IRO的状态信息， 这同样需要借助于安全硬件设备的帮助。 在 CI Agent成功控制 RI发行许可后， 需要更新 IRO的状态信息。
此外， 为了方便 RI及时掌握 IRO的剩余权限， 以免影响到许可的正常发 行， 可以向 RI提供对 IRO剩余权限状态的查询功能， 用于当权限分配达到一 定阈值时， 向 RI产生告警。 例如 RI给出查询条件（如剩余发行许可的次数 小于 100次）， 并将这个查询条件发送给所有 CI Agent插件。 CI Agent插件将 查询自己 IRO的状态信息， 并把剩余权限信息和查询条件的比较结果返回给 RI; 或者只有符合条件的 CI Agent插件才需要给 RI发送告警信息。
如果 CI Agent能够有效监控 RI产生许可和发行许可的过程， 则可以应 RI的请求， 直接将请求内容的明文 CEK返回给 RI, 供 RI发行许可使用。 一 个实施例的流程图如图 14所示， 包括如下步骤：
步骤 141、 根据用户或系统需求许可发行者 RI向 CI Agent提交一个或多 个内容的 CID以及可能的 CEK密文。
步骤 142、 CI Agent处理所述 CEK：。
步骤 143、 CI Agent将处理后的 CEK明文返回给 RI。
步骤 144、 许可发行者 RI构造 ROResponse消息， 并发送许可给终端设 备。 为了有效监控 RI产生许可和发行许可的过程， 也可以采用上述图 4、 8 或 12中方案所给出的 CI Agent和 RI之间的交互协议和流程， 由 CI Agent插 件来控制 RI发行许可。
综上所述， 本发明实施例提供的一种发行许可的方法， 参见图 15, 包括： 步骤 151 , 内容发行者接收许可发行者协助生成许可的请求；
步骤 152, 内容发行者根据所述协助生成许可的请求所携带的信息，使用 目的实体的密钥封装内容相关的信息得到封装密钥， 并对许可的部分信息生 成消息验证码；
步骤 153 ,内容发行者将生成的消息验证码和得到的封装密钥发送给所述 许可发行者， 以使得所述许可发行者将包含所述消息验证码和所述封装密钥 的许可发送给目的实体。
在 OMA DRM系统下 , 步骤 152具体为：
内容发行者根据所述协助生成许可的请求所携带的信息， 获取到内容相 关的信息、 目的实体使用内容的权限信息和目的实体的密钥信息；
内容发行者根据所述内容相关的信息， 查找到相关联的内容加密密钥； 内容发行者生成许可加密密钥和消息验证密钥， 并使用所述许可加密密 钥封装所述内容加密密钥， 使用所述目的实体的密钥封装所述许可加密密钥 和消息验证密钥得到封装密钥；
内容发行者使用所述消息验证密钥对许可的部分信息生成消息验证码， 其中， 所述许可的部分信息包括内容相关的信息、 目的实体使用内容的权限 信息、 和所述得到的封装密钥。
在 Marlin系统下， 步骤 152具体为：
内容发行者根据所述协助生成许可的请求所携带的信息， 获取到内容相 关的信息、 目的实体使用内容的权限信息和目的实体的密钥信息；
内容发行者根据所述内容相关的信息， 查找到相关联的内容加密密钥； 内容发行者使用目的实体的密钥封装所述内容加密密钥得到封装密钥； 内容发行者使用所述内容加密密钥对所述许可的部分信息生成消息验证 码， 其中， 所述许可的部分信息包括内容相关的信息、 目的实体使用内容的 权限信息、 和所述得到的封装密钥。
一个优选实施例， 所述许可的部分信息还包括： 所述许可发行者对内容 相关的信息、 目的实体使用内容的权限信息和封装的内容加密密钥的数字签 名。 为此步骤 152还具体包括：
内容发行者将封装的内容加密密钥发送给所述许可发行者； 接收所述许 可发行者的所述数字签名； 对包含所述数字签名的许可的部分信息生成消息 验证码。
可选地， 在所述许可发行者向目的实体发送许可之后， 所述方法还包括： 经过目的实体确认的方式， 统计所述许可发行者的许可发行信息。
基于上述的发行许可的方法， 本发明实施例分别提供一种内容发行设备、 一种许可发行设备及一种发行许可的系统。
参见图 16, 本发明实施例提供的内容发行设备， 包括：
请求接收单元 161 , 用于接收许可发行者协助生成许可的请求；
协助单元 162, 用于根据所述协助生成许可的请求所携带的信息，使用目 的实体的密钥封装内容相关的信息得到封装密钥， 并对许可的部分信息生成 消息 3全证码；
响应发送单元 163 ,用于将所述协助单元 162生成的消息验证码和得到的 封装密钥发送给所述许可发行者， 以使得所述许可发行者将包含所述消息验 证码和所述封装密钥的许可发送给目的实体。
参见图 17, 协助单元 162中包括信息获取模块 1621、 内容密钥查找模块 1622、 密钥封装模块 1623和验证码生成模块 1623。
其中， 在 OMA DRM系统下， 协助单元 162中各模块具体用于： 信息获取模块 1621 ,用于从所述请求接收单元中获取到内容相关的信息、 目的实体使用内容的权限信息和目的实体的密钥信息；
内容密钥查找模块 1622, 用于根据获取到的所述内容相关的信息， 查找 到相关联的内容加密密钥；
密钥封装模块 1623 , 用于生成许可加密密钥和消息验证密钥， 并使用所 述许可加密密钥封装所述内容加密密钥， 使用所述目的实体的密钥封装所述 许可加密密钥和消息验证密钥得到封装密钥；
验证码生成模块 1624, 用于使用所述消息验证密钥对许可的部分信息生 成消息验证码， 其中， 所述许可的部分信息包括内容相关的信息、 目的实体 使用内容的权限信息、 和所述得到的封装密钥。
在 Marlin系统下， 协助单元 162中各模块具体用于：
信息获取模块 1621 ,用于从所述请求接收单元中获取到内容相关的信息、 目的实体使用内容的权限信息和目的实体的密钥信息；
内容密钥查找模块 1622, 用于根据获取到的所述内容相关的信息， 查找 到相关联的内容加密密钥；
密钥封装模块 1623 , 用于使用目的实体的密钥封装所述内容加密密钥得 到封装密钥；
验证码生成模块 1624, 用于使用所述内容加密密钥对所述许可的部分信 息生成消息验证码， 其中， 所述许可的部分信息包括内容相关的信息、 目的 实体使用内容的权限信息、 和所述得到的封装密钥。
一个优选实施例， 所述许可的部分信息还包括： 所述许可发行者对内容 相关的信息、 目的实体使用内容的权限信息和封装的内容加密密钥的数字签 名。所述协助单元 162,还用于将封装的内容加密密钥发送给所述许可发行者， 接收所述许可发行者的所述数字签名， 对包含所述数字签名的许可的部分信 息生成消息验证码。 发明实施例提供的内容发行设备还包括： 并经过目的实体确认的方式， 统计所述许可发行者的许可发行信息。
参见图 18, 本发明实施例提供的许可发行设备， 包括：
请求发送单元 181 , 用于向内容发行者发送协助生成许可的请求； 协助接收单元 182,用于接收所述内容发行者根据所述请求发送单元 181 , 使用目的实体的密钥封装内容相关的信息得到的封装密钥， 和对许可的部分 信息生成的消息验证码；
许可发送单元 183 ,用于将包含所述响应接收单元 182接收的消息验证码 和封装密钥的许可发送给目的实体。
优选地， 本发明实施例提供的许可发行设备， 还包括：
数字签名单元 184, 用于对所述内容相关的信息、 目的实体使用内容的权 限信息和封装的内容加密密钥进行数字签名； 此时， 所述协助接收单元 182, 还用于接收所述内容发行者对包含所述数字签名的许可的部分信息生成的消 息验证码。
可选地， 在许可发送单元 183 向目的实体发送许可之后， 所述许可发行 设备还包括： 状态上报单元 185 , 用于向所述内容发行者上报经过目的实体确 认的状态报告， 以使得所述内容发行者统计许可发行信息。
参见图 19, 本发明实施例提供的一种发行许可的系统， 包括：
内容发行者 190, 用于接收许可发行者协助生成许可的请求，根据所述协 助生成许可的请求所携带的信息， 使用目的实体的密钥封装内容相关的信息 得到封装密钥， 并对许可的部分信息生成消息验证码； 将所述生成的消息验 证码和所述得到的封装密钥发送给所述许可发行者；
许可发行者 199, 用于向内容发行者发送所述协助生成许可的请求； 接收 所述内容发行者发送的所述消息验证码和所述封装密钥； 将包含所述消息验 证码和所述封装密钥的许可发送给目的实体。
在 OMA DRM系统下， 所述内容发行者 190, 具体用于根据所述协助生 成许可的请求所携带的信息， 获取到内容相关的信息、 目的实体使用内容的 权限信息和目的实体的密钥信息； 根据所述内容相关的信息， 查找到相关联 的内容加密密钥； 生成许可加密密钥和消息验证密钥， 并使用所述许可加密 密钥封装所述内容加密密钥， 使用所述目的实体的密钥封装所述许可加密密 钥和消息验证密钥得到封装密钥； 使用所述消息验证密钥对许可的部分信息 生成消息验证码， 其中， 所述许可的部分信息包括内容相关的信息、 目的实 体使用内容的权限信息、 和所述得到的封装密钥。
在 Marlin系统下， 所述内容发行者 190, 具体用于根据所述协助生成许 可的请求所携带的信息， 获取到内容相关的信息、 目的实体使用内容的权限 信息和目的实体的密钥信息； 根据所述内容相关的信息， 查找到相关联的内 容加密密钥； 使用目的实体的密钥封装所述内容加密密钥得到封装密钥； 使 用所述内容加密密钥对许可的部分信息生成消息验证码， 其中， 所述许可的 部分信息包括内容相关的信息、 目的实体使用内容的权限信息、 和所述得到 的封装密钥。
优选地， 所述许可发行者 199, 还用于对内容相关的信息、 目的实体使用 内容的权限信息和封装的内容加密密钥生成数字签名；
所述内容发行者 190,还用于将封装的内容加密密钥发送给所述许可发行 者， 接收所述许可发行者的所述数字签名， 对包含所述数字签名的许可的部 分信息生成消息验证码。
为了满足部署实施的灵活性， 以及及时响应许可发行者请求等需求， 内 容发行者根据功能模块划分为内容发行服务器 191 和一个以上的内容发行代 理（192、 193、 194... ), 所述内容发行服务器 191 保存所有许可的内容信息 及相应的内容加密密钥， 并管理所有内容发行代理的相关信息； 所述内容发 行代理（192、 193、 194... )只保存与己关联的许可的内容信息及相应的内容 加密密钥； 其中， 所述内容发行服务器 191 管理所有内容发行代理的相关信 息包括： 内容发行代理的注册和启用； 内容发行代理的获取内容加密密钥； 内容 发行代理的获取发行许可的控制信息； 内容发行代理向内容发行服务器上报 发行许可的统计信息； 以及内容发行代理的安全检验、 更改配置或者功能模 块升级。
一种部署方式是， 如附图 2所示， 所述内容发行服务器部署在所述内容 发行者所在的本地局域网， 所述内容发行代理部署在不同的许可发行者所在 的局域网。 该部署方式适用于一些规模较大、 内容较多的内容发行者或内容 提供商。
另一种部署方式是， 如附图 13所示， 所述内容发行代理以插件的方式注 册到所述许可发行者上， 由所述内容发行服务器对自身的内容发行代理进行 代码签名。 该部署方式适用于一些规模较小的内容发行者或内容提供商， 采 用一种轻量级的解决方案， 同样实现控制许可发行者发行许可的目的。
需要说明的是， 在以上所有 OMA DRM相关的实施例中， 目的实体就是 许可的目的接收设备 (或者许可颁发的目标对象或者许可的使用实体）， 因此 以上方案中也有把目的实体或者目的接收设备直接称为目的设备。 在 MARLIN 系统中， 这里的目的实体可以是目的用户或者目的设备， 也就是作 为所述许可接收者的目的用户节点或者目的设备节点。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流 程， 是可以通过计算机程序来指令相关的硬件来完成， 所述的程序可存储于 一计算机可读取存储介质中， 该程序在执行时， 可包括如上述各方法的实施 例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体（ Read-Only Memory , ROM )或随机存储记忆体 ( Random Acces s Memory, RAM )等。
上述具体实施例并不用以限制本发明， 对于本技术领域的普通技术人员 来说， 凡在不脱离本发明原理的前提下， 所作的任何修改、 等同替换、 改进 等， 均应包含在本发明的保护范围之内。

Claims

权 利 要 求 书
1、 一种发行许可的方法， 其特征在于， 包括：
内容发行者接收许可发行者协助生成许可的请求；
内容发行者根据所述协助生成许可的请求所携带的信息， 使用目的实体的 密钥封装内容相关的信息得到封装密钥， 并对许可的部分信息生成消息验证码； 内容发行者将生成的消息验证码和得到的封装密钥发送给所述许可发行 者， 以使得所述许可发行者将包含所述消息验证码和所述封装密钥的许可发送 给目的实体。
2、 根据权利要求 1所述的方法， 其特征在于， 所述内容发行者根据所述协 助生成许可的请求所携带的信息， 使用目的实体的密钥封装内容相关的信息得 到封装密钥， 并对许可的部分信息生成消息验证码的步骤， 具体包括：
内容发行者根据所述协助生成许可的请求所携带的信息， 获取到内容相关 的信息、 目的实体使用内容的权限信息和目的实体的密钥信息；
内容发行者根据所述内容相关的信息， 查找到相关联的内容加密密钥； 内容发行者生成许可加密密钥和消息验证密钥， 并使用所述许可加密密钥 封装所述内容加密密钥， 使用所述目的实体的密钥封装所述许可加密密钥和消 息验证密钥得到封装密钥；
内容发行者使用所述消息验证密钥对许可的部分信息生成消息验证码， 其 中， 所述许可的部分信息包括内容相关的信息、 目的实体使用内容的权限信息、 和所述得到的封装密钥。
3、 根据权利要求 1所述的方法， 其特征在于， 所述内容发行者根据所述协 助生成许可的请求所携带的信息， 使用目的实体的密钥封装内容相关的信息得 到封装密钥， 并对许可的部分信息生成消息验证码的步骤， 具体包括：
内容发行者根据所述协助生成许可的请求所携带的信息， 获取到内容相关 的信息、 目的实体使用内容的权限信息和目的实体的密钥信息； 内容发行者根据所述内容相关的信息， 查找到相关联的内容加密密钥； 内容发行者使用目的实体的密钥封装所述内容加密密钥得到封装密钥； 内容发行者使用所述内容加密密钥对所述许可的部分信息生成消息验证 码， 其中， 所述许可的部分信息包括内容相关的信息、 目的实体使用内容的权 限信息、 和所述得到的封装密钥。
4、 根据权利要求 2或 3所述的方法， 其特征在于， 所述许可的部分信息还 包括： 所述许可发行者对内容相关的信息、 目的实体使用内容的权限信息和封 装的内容加密密钥的数字签名；
所述内容发行者根据所述协助生成许可的请求所携带的信息， 使用目的实 体的密钥封装内容相关的信息得到封装密钥， 并对许可的部分信息生成消息验 证码的步骤， 还包括：
内容发行者将封装的内容加密密钥发送给所述许可发行者；
内容发行者接收所述许可发行者的所述数字签名；
内容发行者对包含所述数字签名的许可的部分信息生成消息验证码。
5、 根据权利要求 1-4任一所述的方法， 其特征在于， 在所述许可发行者向 目的实体发送许可之后， 所述方法还包括：
-许可的方式或有
体确认的方式， 统计所述许可发行者的许可发行信息。
6、 一种内容发行设备， 其特征在于， 包括：
请求接收单元， 用于接收许可发行者协助生成许可的请求；
协助单元， 用于根据所述协助生成许可的请求所携带的信息， 使用目的实 体的密钥封装内容相关的信息得到封装密钥， 并对许可的部分信息生成消息验 证码；
响应发送单元， 用于将所述协助单元生成的消息验证码和得到的封装密钥 发送给所述许可发行者， 以使得所述许可发行者将包含所述消息验证码和所述 封装密钥的许可发送给目的实体。
7、 根据权利要求 6所述的内容发行设备， 其特征在于， 所述协助单元具体 包括：
信息获取模块， 用于从所述请求接收单元中获取到内容相关的信息、 目的 实体使用内容的权限信息和目的实体的密钥信息；
内容密钥查找模块， 用于根据获取到的所述内容相关的信息， 查找到相关 联的内容加密密钥；
密钥封装模块， 用于生成许可加密密钥和消息验证密钥， 并使用所述许可 加密密钥封装所述内容加密密钥， 使用所述目的实体的密钥封装所述许可加密 密钥和消息验证密钥得到封装密钥；
验证码生成模块， 用于使用所述消息验证密钥对许可的部分信息生成消息 验证码， 其中， 所述许可的部分信息包括内容相关的信息、 目的实体使用内容 的权限信息、 和所述得到的封装密钥。
8、 根据权利要求 6所述的内容发行设备， 其特征在于， 所述协助单元具体 包括：
信息获取模块， 用于从所述请求接收单元中获取到内容相关的信息、 目的 实体使用内容的权限信息和目的实体的密钥信息；
内容密钥查找模块， 用于根据获取到的所述内容相关的信息， 查找到相关 联的内容加密密钥；
密钥封装模块， 用于使用目的实体的密钥封装所述内容加密密钥得到封装 密钥；
验证码生成模块， 用于使用所述内容加密密钥对所述许可的部分信息生成 消息验证码， 其中， 所述许可的部分信息包括内容相关的信息、 目的实体使用 内容的权限信息、 和所述得到的封装密钥。
9、 根据权利要求 7或 8所述的内容发行设备， 其特征在于， 所述许可的部 分信息还包括： 所述许可发行者对内容相关的信息、 目的实体使用内容的权限 信息和封装的内容加密密钥的数字签名； 所述协助单元， 还用于将封装的内容加密密钥发送给所述许可发行者， 接 收所述许可发行者的所述数字签名， 对包含所述数字签名的许可的部分信息生 成消息验证码。
10、根据权利要求 6-9任一所述的内容发行设备， 其特征在于， 在所述许可 发行者向目的实体发送许可之后， 所述内容发行设备还包括： 过目的实体确认的方式， 统计所述许可发行者的许可发行信息。
11、 一种许可发行设备， 其特征在于， 包括：
请求发送单元， 用于向内容发行者发送协助生成许可的请求；
协助接收单元， 用于接收所述内容发行者根据所述请求发送单元， 使用目 的实体的密钥封装内容相关的信息得到的封装密钥， 和对许可的部分信息生成 的消息验证码；
许可发送单元， 用于将包含所述响应接收单元接收的消息验证码和封装密 钥的许可发送给目的实体。
12、 根据权利要求 11所述的许可发行设备， 其特征在于， 还包括： 数字签名单元， 用于对所述内容相关的信息、 目的实体使用内容的权限信 息和封装的内容加密密钥进行数字签名；
所述协助接收单元， 还用于接收所述内容发行者对包含所述数字签名的许 可的部分信息生成的消息验证码。
13、 根据权利要求 11或 12所述的许可发行设备， 其特征在于， 在所述许 可发送单元向目的实体发送许可之后， 还包括： 以使得所述内容发行者统计许可发行信息。
14、 一种发行许可的系统， 其特征在于， 包括：
内容发行者， 用于接收许可发行者协助生成许可的请求， 根据所述协助生 成许可的请求所携带的信息， 使用目的实体的密钥封装内容相关的信息得到封 装密钥， 并对许可的部分信息生成消息验证码； 将所述生成的消息验证码和所 述得到的封装密钥发送给所述许可发行者；
许可发行者， 用于向内容发行者发送所述协助生成许可的请求； 接收所述 内容发行者发送的所述消息验证码和所述封装密钥； 将包含所述消息验证码和 所述封装密钥的许可发送给目的实体。
15、 根据权利要求 14所述的发行许可的系统， 其特征在于，
所述内容发行者 , 具体用于根据所述协助生成许可的请求所携带的信息 , 获取到内容相关的信息、 目的实体使用内容的权限信息和目的实体的密钥信息； 根据所述内容相关的信息， 查找到相关联的内容加密密钥； 生成许可加密密钥 和消息验证密钥， 并使用所述许可加密密钥封装所述内容加密密钥， 使用所述 目的实体的密钥封装所述许可加密密钥和消息验证密钥得到封装密钥； 使用所 述消息验证密钥对许可的部分信息生成消息验证码， 其中， 所述许可的部分信 息包括内容相关的信息、 目的实体使用内容的权限信息、 和所述得到的封装密 钥。
16、 根据权利要求 14所述的发行许可的系统， 其特征在于，
所述内容发行者 , 具体用于根据所述协助生成许可的请求所携带的信息 , 获取到内容相关的信息、 目的实体使用内容的权限信息和目的实体的密钥信息； 根据所述内容相关的信息， 查找到相关联的内容加密密钥； 使用目的实体的密 钥封装所述内容加密密钥得到封装密钥； 使用所述内容加密密钥对许可的部分 信息生成消息验证码， 其中， 所述许可的部分信息包括内容相关的信息、 目的 实体使用内容的权限信息、 和所述得到的封装密钥。
17、 根据权利要求 15或 16所述的发行许可的系统， 其特征在于， 所述许可发行者， 还用于对内容相关的信息、 目的实体使用内容的权限信 息和封装的内容加密密钥生成数字签名；
所述内容发行者， 还用于将封装的内容加密密钥发送给所述许可发行者， 接收所述许可发行者的所述数字签名， 对包含所述数字签名的许可的部分信息 生成消息 3全证码。
18、根据权利要求 14-17任一所述的发行许可的系统， 其特征在于， 所述内 容发行者包括内容发行服务器和一个以上的内容发行代理， 所述内容发行服务 器保存所有内容相关的信息及相关联的内容加密密钥， 并管理所有内容发行代 理的相关信息； 所述内容发行代理只保存与己关联的内容相关的信息及相关联 的内容加密密钥； 内容发行代理的注册和启用； 内容发行代理的获取内容加密密钥； 内容发 行代理的获取发行许可的控制信息； 内容发行代理向内容发行服务器上报发行 许可的统计信息； 以及内容发行代理的安全检验、 更改配置或者功能模块升级。
19、 根据权利要求 18所述的发行许可的系统， 其特征在于， 所述内容发行 服务器部署在所述内容发行者所在的本地局域网， 所述内容发行代理部署在不 同的许可发行者所在的局域网。
20、 根据权利要求 18所述的发行许可的系统， 其特征在于， 所述内容发行 代理以插件的方式注册到所述许可发行者上， 由所述内容发行服务器对自身的 内容发行代理进行代码签名。
PCT/CN2009/071503 2009-04-27 2009-04-27 发行许可的方法、装置和系统 WO2010124446A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN2009801471644A CN102224703B (zh) 2009-04-27 2009-04-27 发行许可的方法、装置和系统
PCT/CN2009/071503 WO2010124446A1 (zh) 2009-04-27 2009-04-27 发行许可的方法、装置和系统
US13/281,191 US8407772B2 (en) 2009-04-27 2011-10-25 Method, device, and system for issuing license

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2009/071503 WO2010124446A1 (zh) 2009-04-27 2009-04-27 发行许可的方法、装置和系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/281,191 Continuation US8407772B2 (en) 2009-04-27 2011-10-25 Method, device, and system for issuing license

Publications (1)

Publication Number Publication Date
WO2010124446A1 true WO2010124446A1 (zh) 2010-11-04

Family

ID=43031667

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/071503 WO2010124446A1 (zh) 2009-04-27 2009-04-27 发行许可的方法、装置和系统

Country Status (3)

Country Link
US (1) US8407772B2 (zh)
CN (1) CN102224703B (zh)
WO (1) WO2010124446A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103379365A (zh) * 2012-04-27 2013-10-30 日立(中国)研究开发有限公司 内容获取装置及方法、内容及多媒体发行系统
CN111601117A (zh) * 2020-05-11 2020-08-28 知安视娱(南京)科技有限公司 一种数字版权管理方法及系统

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009155574A1 (en) 2008-06-19 2009-12-23 Servicemesh, Inc. Cloud computing gateway, cloud computing hypervisor, and methods for implementing same
US9489647B2 (en) 2008-06-19 2016-11-08 Csc Agility Platform, Inc. System and method for a cloud computing abstraction with self-service portal for publishing resources
US10411975B2 (en) 2013-03-15 2019-09-10 Csc Agility Platform, Inc. System and method for a cloud computing abstraction with multi-tier deployment policy
US10691860B2 (en) 2009-02-24 2020-06-23 Rambus Inc. Secure logic locking and configuration with camouflaged programmable micro netlists
US10476883B2 (en) 2012-03-02 2019-11-12 Inside Secure Signaling conditional access system switching and key derivation
WO2011091056A1 (en) * 2010-01-19 2011-07-28 Servicemesh, Inc. System and method for a cloud computing abstraction layer
US9430622B2 (en) * 2011-07-13 2016-08-30 Dell Products L.P. Mini appliance
EP2820546B1 (en) * 2012-03-02 2019-07-31 INSIDE Secure Blackbox security provider programming system permitting multiple customer use and in field conditional access switching
US9841999B2 (en) 2015-07-31 2017-12-12 Futurewei Technologies, Inc. Apparatus and method for allocating resources to threads to perform a service
JPWO2019159689A1 (ja) * 2018-02-13 2021-01-28 ソニー株式会社 電子機器、情報処理装置、情報処理方法、プログラム、及び、情報処理システム
CN113935072B (zh) * 2021-09-26 2024-04-30 网易（杭州）网络有限公司 发行者注册方法、装置、计算机设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1496627A (zh) * 2001-12-07 2004-05-12 索尼公司 信息处理设备和方法
CN1607762A (zh) * 2003-10-14 2005-04-20 微软公司 数字权限管理系统
WO2008087743A1 (en) * 2007-01-16 2008-07-24 Telefonaktiebolaget Lm Ericsson (Publ) Control device, reproducing device, permission server, method for controlling control device, method for controlling reproducing device, and method for controlling permission server
WO2008088163A1 (en) * 2007-01-15 2008-07-24 Samsung Electronics Co., Ltd. Rights object acquisition method of mobile terminal in digital right management system

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000260121A (ja) * 1999-03-05 2000-09-22 Toshiba Corp 情報再生装置および情報記録装置
US6772340B1 (en) * 2000-01-14 2004-08-03 Microsoft Corporation Digital rights management system operating on computing device and having black box tied to computing device
US6996544B2 (en) 2002-02-27 2006-02-07 Imagineer Software, Inc. Multiple party content distribution system and method with rights management features
JP4326186B2 (ja) * 2002-04-15 2009-09-02 ソニー株式会社 情報処理装置および方法
JP3821768B2 (ja) * 2002-09-11 2006-09-13 ソニー株式会社 情報記録媒体、情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
WO2004051453A1 (en) * 2002-12-04 2004-06-17 Entriq Inc. Multiple content provider user interface
US7801820B2 (en) * 2003-01-13 2010-09-21 Sony Corporation Real-time delivery of license for previously stored encrypted content
US7792517B2 (en) * 2003-06-10 2010-09-07 Motorola, Inc. Digital content acquisition and distribution in digitial rights management enabled communications devices and methods
US7801819B2 (en) 2003-10-03 2010-09-21 Sony Corporation Rendering rights delegation system and method
AU2003286146A1 (en) * 2003-10-31 2005-06-08 Telefonaktiebolaget Lm Ericsson (Publ) Method and devices for the control of the usage of content
WO2005064484A1 (ja) * 2003-12-25 2005-07-14 Mitsubishi Denki Kabushiki Kaisha デジタルコンテンツ利用権管理システム
US7617158B2 (en) * 2004-03-22 2009-11-10 Telefonaktiebolaget L M Ericsson (Publ) System and method for digital rights management of electronic content
US7477749B2 (en) * 2004-05-12 2009-01-13 Nokia Corporation Integrity protection of streamed content
US7711647B2 (en) * 2004-06-10 2010-05-04 Akamai Technologies, Inc. Digital rights management in a distributed network
CN100354788C (zh) 2005-07-20 2007-12-12 华为技术有限公司 一种数字版权保护系统及方法
KR20070050712A (ko) * 2005-11-11 2007-05-16 엘지전자 주식회사 Srm의 디지털 저작권 관리 방법 및 장치
US20070112680A1 (en) * 2005-11-11 2007-05-17 Infineon Technologies Ag System and method for processing digital media content in a mobile device
WO2007087749A1 (fr) * 2006-01-26 2007-08-09 Huawei Technologies Co. Ltd. Procédé et système pour la génération et l'acquisition de droits d'auteurs et centre d'octroi de droits
EP1982458B1 (en) * 2006-01-26 2018-12-05 LG Electronics Inc. Apparatus and method for moving rights object from one device to another device via server
GB0702603D0 (en) * 2006-05-05 2007-03-21 Omnifone Ltd Pc client
CN102982257B (zh) * 2006-05-05 2016-06-22 交互数字技术公司 在re和te间执行平台完整性和drm软件完整性检查的方法
US8095466B2 (en) * 2006-05-15 2012-01-10 The Directv Group, Inc. Methods and apparatus to conditionally authorize content delivery at content servers in pay delivery systems
US9112874B2 (en) * 2006-08-21 2015-08-18 Pantech Co., Ltd. Method for importing digital rights management data for user domain
US20080319851A1 (en) * 2007-06-25 2008-12-25 Microsoft Corporation Using delegation for distributing protected content
KR100973576B1 (ko) * 2008-03-26 2010-08-03 주식회사 팬택 권한 객체 생성 방법 및 그 디바이스, 권한 객체 전송 방법및 그 디바이스와 권한 객체 수신 방법 및 그 디바이스
WO2010087567A1 (en) * 2009-01-29 2010-08-05 Lg Electronics Inc. Method for installing rights object for content in memory card

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1496627A (zh) * 2001-12-07 2004-05-12 索尼公司 信息处理设备和方法
CN1607762A (zh) * 2003-10-14 2005-04-20 微软公司 数字权限管理系统
WO2008088163A1 (en) * 2007-01-15 2008-07-24 Samsung Electronics Co., Ltd. Rights object acquisition method of mobile terminal in digital right management system
WO2008087743A1 (en) * 2007-01-16 2008-07-24 Telefonaktiebolaget Lm Ericsson (Publ) Control device, reproducing device, permission server, method for controlling control device, method for controlling reproducing device, and method for controlling permission server

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103379365A (zh) * 2012-04-27 2013-10-30 日立(中国)研究开发有限公司 内容获取装置及方法、内容及多媒体发行系统
CN103379365B (zh) * 2012-04-27 2017-08-08 日立(中国)研究开发有限公司 内容获取装置及方法、内容及多媒体发行系统
CN111601117A (zh) * 2020-05-11 2020-08-28 知安视娱(南京)科技有限公司 一种数字版权管理方法及系统
CN111601117B (zh) * 2020-05-11 2021-04-02 知安视娱(南京)科技有限公司 一种数字版权管理方法及系统

Also Published As

Publication number Publication date
CN102224703A (zh) 2011-10-19
US8407772B2 (en) 2013-03-26
US20120042168A1 (en) 2012-02-16
CN102224703B (zh) 2013-11-06

Similar Documents

Publication Publication Date Title
WO2010124446A1 (zh) 发行许可的方法、装置和系统
JP5977292B2 (ja) 信頼される処理技術を使用したデジタル権利管理
US9177112B2 (en) Method and device for communicating digital content
US10212149B2 (en) System and method for securing the life-cycle of user domain rights objects
TW200828944A (en) Simplified management of authentication credientials for unattended applications
BRPI0313404B1 (pt) &#34;method and system for monitoring the customer&#39;s use of digital content loaded or transferred in continuous provided by a content provider to a customer system through a network&#34;
CN107948235B (zh) 基于jar的云数据安全管理与审计装置
KR101377352B1 (ko) 중소 기업 내의 디지털 저작권 관리 수행 방법 및 장치 및 디지털 저작권 관리 서비스를 제공하기 위한 방법
TWI426765B (zh) 基於語彙基元存取控制之網路服務管理系統及其方法
CN117957813A (zh) 安全管理系统及安全管理方法
JP2007043475A (ja) 情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラム
KR20090036498A (ko) 사용자 도메인에서의 키 관리 방법 및 콘텐츠 사용 방법
WO2001099380A1 (en) Negotiation between encryption devices to establish parameters for communication

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980147164.4

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09843858

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09843858

Country of ref document: EP

Kind code of ref document: A1