WO2008125056A1 - Method, device and system for triggering device to operate - Google Patents
Method, device and system for triggering device to operate Download PDFInfo
- Publication number
- WO2008125056A1 WO2008125056A1 PCT/CN2008/070704 CN2008070704W WO2008125056A1 WO 2008125056 A1 WO2008125056 A1 WO 2008125056A1 CN 2008070704 W CN2008070704 W CN 2008070704W WO 2008125056 A1 WO2008125056 A1 WO 2008125056A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- trigger
- domain
- perform
- destination
- triggering
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/305—Authentication, i.e. establishing the identity or authorisation of security principals by remotely controlling device operation
-
- 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
-
- 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]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/101—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management
Definitions
- the present invention relates to the field of digital rights management technologies, and in particular, to a method, device and system for triggering a device to perform operations. 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 user obtains digital content from a network or other device, the digital content is generally encrypted, and together with other information (such as the encryption algorithm of the content) constitute a content data package.
- the Rights Issuer (RI) is responsible for issuing corresponding licenses for content packets, including the content decryption key and corresponding permissions.
- Devices can only use digital content if they have both content packets and licenses.
- the DRM device obtains the content decryption key through the license, thereby decrypting the digital content.
- the license contains information such as rights, restrictions, etc.
- the rights indicate what the device can do, such as allowing the device to print, browse, etc., while the restriction indicates under what conditions the device can do, for example, allowing browsing at most several times.
- the DRM device must perform the appropriate action based on the permission information in the license.
- a device When a device obtains a license from the RI, it usually needs to register with the RI first, and both parties complete the verification and exchange capability information of the other party through registration.
- the device may also request to join one or more domains to the RI.
- a domain is a collection of devices that can be purchased for a domain by any device in the domain. This domain license can be freely distributed among devices within the domain. Usually the devices in the domain have the same domain key, and the domain license is encapsulated with the domain key, so the domain license can be used by any device in the domain.
- the device can request the RI to exit the domain.
- the domain is not managed by the RI, but by the Domain Authority (DA). To manage, the device requests the DA to join or leave the domain.
- DA Domain Authority
- the RI can trigger the device to interact with it by issuing a trigger.
- the trigger can include a registration trigger, a permission request trigger, a join domain trigger, an exit domain trigger, an upper statistics trigger, and the like.
- the processing flow is as follows:
- Step 100 The RI sends a trigger to the device to exit the domain.
- Step 101 After receiving the trigger of the exit domain, the device deletes the locally saved domain related information.
- Step 102 The device sends an exit domain request message to the RI, to notify the RI that the device will exit the domain.
- Step 103 The RI returns an exit domain response message to the device, and confirms that the device has been deleted in the domain.
- the structure of the exit domain trigger is as follows:
- the ⁇ signature> element of the exit field trigger contains the signature of the ⁇ leaveDomain> element, which is the result of message authentication (HMac) with a message authentication code (mac) key, and the mac key is encapsulated with the domain key. And put it in the 11 ( ⁇ 6 > element to the device. Since any device in the domain has a domain key, an intra-domain device controlled by the attacker can intercept a device's legal exit domain trigger in the domain initiated by the RI, and then The trigger is arbitrarily propagated between the devices in the domain to attack other legitimate devices in the domain. At this time, although other devices are not the original target object of the trigger, the other devices cannot recognize whether the received trigger is sent to the device. Trigger, which leads to The device is unreasonably logged out of the domain, causing loss to the user.
- the device will not recognize whether the trigger is a trigger sent to the device, which may cause misoperation and cause unnecessary loss.
- Step 200 The LRM interacts with the RI to import a license, and the LRM specifies the identifier (ID) of the receiving device.
- Step 201 to step 202 The RI determines whether the receiving device has registered with the receiving device according to the ID of the receiving device. If not, the RI triggers the receiving device to register with the receiving device.
- Step 203 to step 204 The RI triggers the receiving device to acquire the license.
- the device ID is the public key hash value of the device certificate in the definition of OMADRM.
- the structure of the registration trigger is as follows:
- the receiving device cannot recognize whether the received registration trigger is a registration trigger sent to the device, and in the case that the receiving device has multiple certificates, the corresponding receiving device has multiple device IDs, when the receiving device is to the RI
- the receiving device can register with an ID and RI. This will most likely result in the ID of the receiving device being registered and the ID provided by the LRM to the RI cannot be consistent. If they are inconsistent, the receiving device cannot successfully obtain the license for importing the imported device. .
- Embodiments of the present invention provide a method, device, and system for triggering a device to perform operations, for verifying whether a received trigger is a trigger sent to the device, thereby preventing an attacker from using a trigger to attack.
- An embodiment of the present invention provides a method for a trigger device to perform an operation, where the method includes the following steps:
- the second device receives a trigger that is sent by the first device and includes information related to the destination device.
- the second device determines, when the device is the destination device, according to the related information, performing an operation triggered by the trigger.
- the embodiment of the invention further provides a communication device, including:
- a generating unit configured to generate a trigger that includes information related to the destination device
- a communication unit configured to send the trigger to trigger the destination device to perform a corresponding operation.
- the embodiment of the invention further provides a communication device, including:
- a communication unit configured to receive a trigger that is sent by another device and includes information related to the destination device
- a determining unit configured to determine, according to the related information, whether the device is the destination device; The operation of the hair.
- the embodiment of the invention further provides a communication system, including:
- a first device configured to provide a trigger including information related to the destination device, to trigger the target device to perform a corresponding operation
- a second device configured to receive a trigger that is sent by the first device and includes information related to the destination device, and when the device is determined to be the destination device according to the related information, perform an operation triggered by the trigger.
- the second device after receiving the trigger that is sent by the first device and including the information about the destination device, the second device determines that the device is the destination device of the trigger according to the related information, and the trigger is triggered by the trigger. Operation, so that the second device can verify whether the received trigger is a trigger sent to the device, preventing an attacker from using the trigger to attack.
- FIG. 1 is a flowchart of a process after a device receives an exit domain trigger in the prior art
- FIG. 2 is a flowchart of a process for importing a license by an LRM and interacting with a RI by a receiving device in the prior art
- FIG. 3 is a schematic structural diagram of a communication system according to an embodiment of the present invention.
- FIG. 4 is a schematic structural diagram of a first device according to an embodiment of the present invention.
- FIG. 5 is a schematic structural diagram of a second device according to an embodiment of the present invention.
- FIG. 6 is a flowchart of a process after a second device receives a trigger sent by an RI according to an embodiment of the present invention
- FIG. 7 is a flowchart of a process for a second device to register with an RI according to an embodiment of the present invention
- FIG. 8 is a flowchart of a process after a second device receives a registration trigger according to an embodiment of the present invention.
- the second device after receiving the trigger that is sent by the first device and including the information about the destination device, the second device determines whether the device is the destination device according to the related information, and performs trigger triggering when determining the target device. Operation, so that the second device can verify whether the received trigger is a trigger sent to the device, preventing an attacker from using the trigger to attack.
- the structure of a communication system in the embodiment of the present invention is as shown in FIG. 3, and includes: a first device 300, a second device 301, where the first device 300 is configured to provide a trigger that includes information about the destination device to trigger The destination device interacts with the second device 301, and is configured to receive a trigger that is sent by the first device 300 and includes information about the destination device, and when the device is determined to be the destination device of the received trigger according to the related information, perform The action triggered by the trigger.
- the first device 300 may be a copyright issuer (RI), or may be another service entity, such as a domain manager (DA), an import device (LRM), or the like, which generates a trigger.
- the first device 300 may also be It is an intermediate device that forwards a message, and the device that generates the trigger can send a trigger to the second device through the intermediate device.
- the structure of a first device in the embodiment of the present invention includes: a generating unit 400, a communication unit 401; wherein, the generating unit 400 is configured to generate a trigger that includes information about the destination device; and the communication unit 401, Used to send the generated trigger to trigger the destination device to perform the corresponding operation.
- the structure of a second device in the embodiment of the present invention includes: a communication unit 500, a determining unit 501, and an executing unit 502.
- the communication unit 500 is configured to receive, by the first device, a device related to the destination device.
- the triggering unit 501 is configured to determine, according to the related information, whether the device is a destination device of the received trigger, and the executing unit 502 is configured to perform an operation triggered by the trigger when the device is the destination device.
- the trigger received by the second device may be a trigger that triggers various operations, such as registering a trigger, joining a domain trigger, leaving a domain trigger, a permission acquisition trigger, or a statistical escalation trigger.
- the operations performed by the triggering device may be registration, joining a domain, leaving a domain, obtaining a license, or reporting statistics.
- the related information included in the trigger may be a device identifier and/or a device name of the destination device, or other information used to identify the destination device, such as a device address, etc.; the second device may use the device of the target device in the related information.
- One or a combination of the identifier, the device name, and the device address is compared with the corresponding information of the device, and the device is determined to be the device according to the comparison result.
- the trigger can contain the identifier (ID) of a destination device. If the RI triggers multiple devices to trigger subsequent interactions through the trigger, the trigger can also contain the IDs of multiple destination devices. Of course, the trigger can also contain no device ID. For example, if all devices in the RI trigger domain leave the domain, you can broadcast a leave domain trigger that does not contain any specified device ID.
- the trigger may further include a signature of the first device to the information related to the destination device.
- the first device may use the private key of the device to sign the information about the destination device,
- the second device verifies the signature with the public key of the first device.
- the processing flow is as shown in FIG. 6, and includes the following steps:
- Step 600 The second device receives the trigger sent by the RI to the RI.
- Step 601 The second device determines whether the received trigger carries the signature of the RI. If yes, step 602 is performed; otherwise, step 604 is performed.
- Step 602 The second device verifies the signature carried by the trigger, where the signature is a result of performing a signature operation on the information about the destination device carried in the trigger by using the private key of the RI, and the second device uses the public key of the RI to verify the signature.
- Step 603 The second device determines whether the verification result in step 602 is valid. If yes, step 604 is performed; otherwise, step 607 is performed.
- Step 604 The second device determines whether the destination device ID is specified in the trigger. If yes, step 605 is performed; otherwise, step 606 is performed.
- Step 605 The second device determines whether the destination device ID specified in the trigger is the same as an ID of the device. If yes, step 606 is performed; otherwise, step 607 is performed.
- Step 606 The second device performs a corresponding operation according to the type of the trigger, such as registering, joining the domain, leaving the domain, reporting the statistics, and the like, and ending the triggering process, where the second device may use the ID of the device included in the trigger. Execute the action triggered by the trigger.
- Step 607 The second device discards the trigger, and ends the triggering process.
- the second device when the second device receives certain types of triggers, such as obtaining a license trigger, joining a domain trigger, leaving a domain trigger, a statistics reporting trigger, the device There is no valid registration information. For example, if the registration information on the device has been deleted, or the registration information has expired and is invalid, or if other devices request permission from the device, the other device will obtain the acquisition permission trigger to the device, and the device also There is no registration with the RI, etc. At this point, the second device is first The registration agreement will be initiated automatically. If the destination device ID specified in the trigger previously received by the second device is the same as the ID of the device, the second device performs the registration interaction process by using the ID and RI of the device specified in the trigger. In a specific example, the processing flow of the second device registering with the RI is as shown in FIG. 7, and includes the following steps:
- Step 700 The second device receives a trigger, for example, obtaining a permission trigger, joining a domain trigger, leaving a domain trigger, a trigger on a statistical information, and the like.
- a trigger for example, obtaining a permission trigger, joining a domain trigger, leaving a domain trigger, a trigger on a statistical information, and the like.
- Step 701 The second device determines whether the device has valid registration information, and if yes, performs step 707; otherwise, performs step 702.
- Step 702 The second device determines whether the destination device ID is specified in the received trigger. If yes, step 703 is performed; otherwise, step 708 is performed.
- Step 703 The second device determines whether the device ID is consistent with the destination device ID specified in the trigger. If yes, step 704 is performed; otherwise, step 709 is performed.
- Step 704 The second device initiates a registration interaction with the RI. At this time, the second device needs to register with the local device ID and the RI that are consistent with the destination device ID specified in the trigger, and the trigger is specified in the registration request message. The device ID.
- Step 705 The second device determines whether the registration is successful. If yes, step 706 is performed; otherwise, step 709 is performed.
- Step 706 The second device performs a corresponding subsequent operation according to the previously received trigger type, and ends the triggering process.
- the second device can verify the signature included in the trigger. If the trigger is signed with the RI private key, the second device verifies the signature with the RI public key.
- Step 707 The second device verifies the signature included in the received trigger when the registration information is valid. At this time, if the trigger uses the RI private key for signature, the second device uses the RI public key to verify the signature. After the signature verification is completed, the second device performs subsequent corresponding operations according to the type of the received trigger. For the processing flow of the step, refer to the process shown in FIG. 6.
- Step 708 When the trigger received by the second device does not include the destination device ID, initiate a registration interaction process to the RI. If the second device has multiple device IDs, select an ID and an RI to register.
- Step 709 When the device ID of the second device is inconsistent with the destination device ID in the trigger or the second device registration is unsuccessful, the trigger is discarded, and the triggering process is ended.
- the second device when the second device initiates the registration message according to the registration trigger, it needs to register with a device ID and RI specified in the trigger to ensure successful interaction with the RI, for example: importing the license for the import device,
- the RI provides the receiving device ID.
- the device ID used by the second device to register with the RI is the same as the device ID that the import device provides to the RI, the second device can successfully obtain the license for importing the device.
- the second device may not know the public key of the RI, and the RI may also sign its own certificate or certificate chain at the same time. Placed in the trigger together to pass to the second device.
- the certificate chain carried in the second device trust trigger cannot be guaranteed. Verifying the signature without trusting the certificate does not guarantee security. Therefore, the signature of the RI may not be carried in the registration trigger message.
- the processing flow is as shown in FIG. 8, and includes the following steps:
- Step 800 The second device receives the registration trigger.
- Step 801 The second device determines whether the destination device ID is specified in the trigger. If yes, step 802 is performed; otherwise, step 803 is performed.
- Step 802 The second device determines whether the destination device ID specified in the trigger is the same as an ID of the device, and if yes, step 805 is performed; otherwise, step 804 is performed.
- Step 803 The second device initiates a registration interaction process to the RI, if the second device has multiple For each device ID, select one ID and RI to register.
- Step 804 When the device ID of the second device is different from the destination device ID in the trigger, the second device discards the trigger, and ends the triggering process.
- Step 805 The second device initiates a registration interaction process with the RI, where the second device needs to register with the local device ID and the RI specified in the trigger, and carries the specified local device ID in the registration request message.
- the RI sends a trigger to the device to trigger the device to perform the corresponding operation.
- the device can also be triggered by issuing a trigger.
- the processing flow is similar to the processing flow shown in Figures 7 and 8.
- the trigger needs to be signed, it is signed by other service entities that issue triggers.
- the second device after receiving the trigger that is sent by the first device and including the information about the destination device, the second device determines that the device is the destination device of the received trigger according to the related information, and performs a trigger-triggered operation. Therefore, the second device can check whether the received trigger is a trigger sent to the device, preventing the attacker from using the trigger to attack, in particular, leaving the domain trigger to attack.
- the service entity such as RI, DA, or LRM can also indicate that the second device uses the specific device ID to interact with the device through the issued trigger.
- the present invention can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is a better implementation. the way.
- the technical solution of the present invention which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium. There are several instructions for causing a terminal device to perform the methods described in various embodiments of the present invention.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Networks & Wireless Communication (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
Description
触发设备执行操作的方法、 设备及*** 技术领域
本发明涉及数字版权管理技术领域,尤其涉及触发设备执行操作 的方法、 设备及***。 背景技术
数字版权管理(Digital Rights Management, DRM )主要通过权 利限制和内容保护方案控制数字内容的使用,保护内容所有者的合法 权益。 用户从网络或其他设备处获取数字内容, 该数字内容一般是加 密的, 并和其他一些信息(如内容的加密算法)共同构成一个内容数 据包。 许可服务器( Rights Issuer, RI ) 负责为内容数据包发放对应的 许可, 许可中包括内容解密密钥及对应的权限。设备只有同时拥有内 容数据包和许可, 才能正常使用数字内容。 DRM设备通过许可获取 内容解密密钥,进而解密数字内容。许可中包含有权利、限制等信息, 权利指示设备可以干什么, 例如允许设备打印、 浏览等, 而限制则指 示设备在什么条件下可以干, 例如最多允许浏览几次等。 DRM设备 必须根据许可中的权限信息执行相应的操作。
设备从 RI处获取许可时, 通常需要先向 RI注册, 双方通过注册 来完成对对方的验证并交换能力信息。
可选的, 设备也可以向 RI请求加入一个或多个域。 域是一组设 备的集合, 域中的任何一个设备都可以为域购买域许可, 该域许可可 以在域内设备间自由的分发。 通常域内设备都拥有同样的域密钥, 域 许可用域密钥进行封装, 因此任何域内设备都可以使用域许可。 当设 备不需要享受该服务时, 可以向 RI请求退出域。 在另外的一些*** 架构中,域不是由 RI管理,而是由域管理器(Domain Authority, DA )
来管理, 设备向 DA请求加入或退出域。
现有技术的一种触发设备交互的实现方式例如在 OMA DRM标 准中, RI可以通过下发触发器(trigger )的方式来触发设备与其交互。 根据后续触发的消息的不同, 触发器可以包括注册触发器、许可请求 触发器、 加入域触发器、 退出域触发器、 上^艮统计信息触发器等。 如 图 1所示, 在一个实施例中,设备接收到退出域触发器后的处理流程 下:
步骤 100、 RI向设备发送一个退出域的触发器。
步骤 101、 设备接收到该退出域的触发器后, 删除本地保存的 域相关信息。
步骤 102、 设备向 RI发送退出域请求消息, 通知 RI本设备将退 出域。
步骤 103、 RI向设备返回退出域响应消息, 确认已将设备在域内 删除。
在图 1所示的实施例中, 退出域触发器的结构如下:
<complexType name="RoapTrigger">
<sequence>
... ... II省略
<element name="leaveDomain" type="roap:DomainTrigger"/>
<element name=" signature" type="ds: SignatureType" minOccurs="0"/>
<element name="encKey" type="xenc:EncryptedKeyType" minOccurs="0"/>
</sequence>
<attribute name="version" type="roap:Version"/>
<attribute name- 'proxy" type="boolean"/>
</complexType>
<complexType name="DomainTrigger">
<complexContent>
<extension base="roap:BasicRoapTrigger">
<sequence>
<element name="domainID" type="roap:DomainIdentifier" minOccurs="0"/>
<element name= " domain Alias " type="string" minOccurs="0"/> </sequence>
</extension>
</complexContent>
</complexType>
<complexType name="BasicRoapTrigger">
<sequence>
<element name="riID" type="roap:Identifier"/>
<element name="riAlias" type=" string" minOccurs="0"/>
<element name=" nonce" type="roap:Nonce" minOccurs="0"/> <element name="roapURL" type="anyURI"/>
</sequence>
<attribute name="id" type="ID"/>
</complexType> 发明人在实现本发明的过程中,发现此现有技术至少存在以下问 题:
退出域触发器的 <signature>元素包含对 <leaveDomain>元素的签 名, 该签名是用一个消息认证码(mac )密钥做消息认证(HMac )的 结果, 而 mac密钥是用域密钥封装并放在 11(^6 >元素中传送给设 备。 由于任何一个域内设备都拥有域密钥, 因此一个被攻击者控制的 域内设备可以截取 RI发起的域内一个设备合法的退出域触发器, 然 后将该触发器在域内设备间任意的传播, 从而攻击域内其他合法设 备。 此时虽然其它设备不是该触发器原始目标对象, 但由于其它设备 无法识别出接收到的触发器是否为发送给本设备的触发器,从而导致
本设备无端的退出域, 对用户造成损失。
类似的, 对于其它类型的触发器,设备也会由于无法识别接收到 是触发器是否为发送给本设备的触发器, 从而很可能导致误操作, 造 成不必要的损失。
现有技术的另一种设备间交互的实现方式例如在 OMA DRM新 的工作组 SCE中, 引入本地许可管理设备 ( Local Rights Manager, LRM ), 将一个非 OMA DRM的许可导入 OMA DRM中, 并在导入 时指定一个接收设备, 可以使该接收设备与 RI交互, 获取该非 ΟΜΑ DRM的许可。 如图 2所示, 由 LRM导入许可并使接收设备与 RI交 互的处理流程如下:
步骤 200、 LRM和 RI交互, 导入一个许可, 同时 LRM指定接 收设备的标识符 (ID )。
步骤 201至步骤 202、 RI根据接收设备的 ID判断该接收设备之 前是否已向其注册, 若没有, 则 RI触发该接收设备向其注册。
步骤 203至步骤 204、 RI触发接收设备获取许可。
在图 2所示的实施例中,设备 ID在 OMADRM的定义中为设备 证书的公钥 hash值。 其中, 注册触发器的结构如下:
<complexType name="RoapTrigger">
<sequence>
II省略
<element name= " regi strationReque st " type="roap: BasicRoap Trigger "/> </sequence>
<attribute name="version" type="roap:Version"/>
<attribute name- 'proxy" type="boolean"/>
</complexType>
发明人在实现本发明的过程中,发现此现有技术至少存在以下问
题:
接收设备无法识别接收到的注册触发器是否为发送给本设备的 注册触发器, 并且, 在接收设备有多个证书的情况下, 相应的接收设 备会有多个设备 ID, 当接收设备向 RI注册时, 接收设备可以任选一 个 ID和 RI完成注册, 这将很可能导致接收设备注册的 ID和 LRM 提供给 RI的 ID无法保持一致, 若不一致,接收设备无法成功获取到 导入设备导入的许可。
发明内容
本发明实施例提供一种触发设备执行操作的方法、 设备及***, 用以检验接收到的触发器是否为发送给本设备的触发器,从而防止攻 击者利用触发器进行攻击。
本发明实施例提供一种触发设备执行操作的方法,该方法包括以 下步骤:
第二设备接收第一设备发送的包含目的设备相关信息的触发器; 所述第二设备根据所述相关信息确定本设备为所述目的设备时, 执行所述触发器触发的操作。
本发明实施例还提供一种通信设备, 包括:
生成单元, 用于生成包含目的设备相关信息的触发器; 通信单元, 用于发送所述触发器, 以触发所述目的设备执行相应 操作。
本发明实施例还提供一种通信设备, 包括:
通信单元,用于接收其它设备发送的包含目的设备相关信息的触 发器;
确定单元,用于根据所述相关信息确定本设备是否为所述目的设 备;
发的操作。
本发明实施例还提供一种通信***, 包括:
第一设备, 用于提供包含目的设备相关信息的触发器, 以触发目 的设备执行相应的操作;
第二设备,用于接收所述第一设备发送的包含目的设备相关信息 的触发器, 并在根据所述相关信息确定本设备为所述目的设备时, 执 行所述触发器触发的操作。 本发明实施例中,第二设备接收到第一设备发送的包含目的设备 相关信息的触发器后,根据该相关信息确定本设备为所述触发器的目 的设备时, 执行所述触发器触发的操作, 从而使第二设备可以检验接 收到的触发器是否为发送给本设备的触发器,防止攻击者利用触发器 进行攻击。 附图说明
图 1为现有技术中设备接收到退出域触发器后的处理流程图; 图 2为现有技术中由 LRM导入许可并使接收设备与 RI交互的处 理流程图;
图 3为本发明实施例中一种通信***的结构示意图;
图 4为本发明实施例中第一设备的结构示意图;
图 5为本发明实施例中第二设备的结构示意图;
图 6为本发明实施例中第二设备接收到 RI发送的触发器后的处 理流程图;
图 7为本发明实施例中第二设备向 RI注册的处理流程图; 图 8 为本发明实施例中第二设备收到注册触发器后的处理流程 图。
具体实施方式
本发明实施例中,第二设备接收到第一设备发送的包含目的设备 相关信息的触发器后, 根据该相关信息确定本设备是否为目的设备, 并且在确定为目的设备时执行触发器触发的操作,从而使第二设备可 以检验接收到的触发器是否为发送给本设备的触发器,防止攻击者利 用触发器进行攻击。
本发明实施例中一种通信***的结构如图 3所示, 包括: 第一设 备 300、 第二设备 301 ; 其中, 第一设备 300, 用于提供包含目的设 备相关信息的触发器,以触发目的设备与其进行交互;第二设备 301 , 用于接收第一设备 300发送的包含目的设备相关信息的触发器,并在 根据该相关信息确定本设备为接收到的触发器的目的设备时,执行触 发器触发的操作。
第一设备 300可以是版权发行者(RI ), 也可以是其它服务实体, 如域管理器(DA )、 导入设备 ( LRM )等生成触发器的设备, 另夕卜, 第一设备 300还可以是转发消息的中间设备,生成触发器的设备可以 通过中间设备向第二设备发送触发器。本发明实施例中一种第一设备 的结构如图 4所示, 包括: 生成单元 400、 通信单元 401 ; 其中, 生 成单元 400 , 用于生成包含目的设备相关信息的触发器; 通信单元 401 , 用于发送生成的触发器, 以触发目的设备执行相应操作。
本发明实施例中一种第二设备的结构如图 5所示, 包括: 通信单 元 500、 确定单元 501、 执行单元 502; 其中, 通信单元 500, 用于接 收第一设备发送的包含目的设备相关信息的触发器; 确定单元 501 , 用于根据该相关信息确定本设备是否为接收的触发器的目的设备;执 行单元 502 , 用于确定本设备为所述目的设备时执行触发器触发的操 作。
第二设备接收的触发器可以是触发各种操作的触发器, 例如, 注 册触发器、 加入域触发器、 离开域触发器、 许可获取触发器或统计上 报触发器等。 相应的, 触发设备执行的操作可以是注册、 加入域、 离 开域、 获取许可或上报统计信息。 触发器中包含的相关信息可以是目 的设备的设备标识符和 /或设备名称, 也可以是其它用于标识目的设 备的信息, 例如设备地址等; 第二设备可以将相关信息中目标设备的 设备标识、设备名称和设备地址之一或组合与本设备的相应信息进行 比较, 根据比较结果确定本设备是否为的设备。
下面为触发器中包含目的设备的设备标识符的一个具体实例:
<complexType name="BasicRoapTrigger">
<sequence>
<element name="riID" type="roap:Identifier"/>
<element name="riAlias" type=" string" minOccurs="0"/>
<element name=" nonce" type="roap:Nonce" minOccurs="0"/> <element name="roapURL" type="anyURI"/>
<element name- 'devicelDs" type="roap: Identifier" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="id" type="ID"/>
</complexType> 上述实例中, 触发器可以包含某个目的设备的标识符(ID ), 若 RI 需通过触发器触发多个设备发起后续交互, 触发器也可以包含多 个目的设备的 ID。 当然, 触发器也可以不包含设备 ID, 例如, RI触 发域中的所有设备都离开域, 则可以广播一个离开域触发器, 该触发 器中不包含任何指定的设备 ID。
触发器中还可以包括第一设备对目的设备相关信息的签名。 例 如, 第一设备可以用本设备的私钥对目的设备相关信息进行签名, 第
二设备用第一设备的公钥验证该签名。
一个具体实例中, 第二设备接收到 RI发送的触发器后的处理流 程如图 6所示, 包括以下步骤:
步骤 600、 第二设备接收到 RI向其发送的触发器。
步骤 601、 第二设备判断接收到的触发器中是否携带有 RI的签 名, 若是, 则执行步骤 602, 否则执行步骤 604。
步骤 602、 第二设备验证触发器携带的签名, 该签名是用 RI的 私钥对触发器中携带的目的设备相关信息进行签名运算的结果,第二 设备用 RI的公钥来验证该签名。
步骤 603、第二设备判断步骤 602中的验证结果是否有效,若是, 则执行步骤 604 , 否则执行步骤 607。
步骤 604、第二设备判断触发器中是否指定了目的设备 ID,若是, 则执行步骤 605; 否则执行步骤 606。
步骤 605、 第二设备判断触发器中指定的目的设备 ID是否与本 设备的某个 ID相同,若是,则执行步骤 606; 否则,则执行步骤 607。
步骤 606、第二设备根据触发器的类型执行相应的操作,如注册、 加入域、 离开域、 上报统计信息等, 结束触发流程, 其中, 第二设备 可以使用触发器中包含的本设备的 ID执行触发器触发的操作。
步骤 607、 第二设备丟弃该触发器, 结束触发流程。
一种可能的情况是, 在 OMA DRM中, 当第二设备接收到某些 类型的触发器时, 例如获取许可触发器、 加入域触发器、 离开域触发 器、 统计信息上报触发器, 本设备没有有效的注册信息。 例如, 设备 上的注册信息已被删除, 或注册信息已经过期而无效, 或在其他设备 为本设备请求许可的情况下,其他设备将获得的获取许可触发器传送 给本设备, 而本设备还没有向 RI注册等情况。 此时, 第二设备首先
会自动的发起注册协议。若第二设备先前接收到的触发器中指定的目 的设备 ID和本设备的 ID相同,则第二设备釆用触发器中指定的本设 备的 ID和 RI执行注册交互过程。 一个具体实例中, 第二设备向 RI 注册的处理流程如图 7所示, 包括以下步骤:
步骤 700、 第二设备接收到一触发器, 例如, 获取许可触发器、 加入域触发器、 离开域触发器、 统计信息上 触发器等。
步骤 701、 第二设备判断本设备是否有有效的注册信息, 若是, 则执行步骤 707; 否则执行步骤 702。
步骤 702、 第二设备判断接收到的触发器中是否指定了目的设备 ID, 若是, 则执行步骤 703; 否则执行步骤 708。
步骤 703、 第二设备判断本设备 ID是否与触发器中指定的目的 设备 ID相一致, 若是, 则执行步骤 704; 否则, 执行步骤 709。
步骤 704、 第二设备向 RI发起注册交互, 此时第二设备需釆用 与触发器中指定的目的设备 ID相一致的本设备 ID和 RI进行注册, 在注册请求消息中携带触发器中指定的本设备 ID。
步骤 705、 第二设备判断注册是否成功, 若是, 则执行步骤 706; 否则, 执行步骤 709。
步骤 706、 第二设备根据先前接收的触发器类型执行相应的后续 操作, 结束触发流程, 当然, 在此之前, 第二设备可以对触发器中包 含的签名进行验证。 若触发器釆用 RI私钥进行签名, 则第二设备釆 用 RI公钥验证该签名。
步骤 707、 第二设备在注册信息有效时, 验证接收的触发器中包 含的签名, 此时, 若触发器釆用 RI私钥进行签名, 则第二设备釆用 RI公钥验证该签名。 第二设备在签名验证完成后, 根据接收的触发 器类型执行后续相应操作, 该步骤的处理流程参见图 6所示流程。
步骤 708、 第二设备接收的触发器中未包含目的设备 ID时, 向 RI发起注册交互流程,若第二设备有多个设备 ID, 则任选一个 ID和 RI进行注册。
步骤 709、 第二设备的设备 ID与触发器中目的设备 ID不一致或 第二设备注册未成功时, 丟弃该触发器, 结束触发流程。
对于注册触发器, 当第二设备根据注册触发器发起注册消息时, 需要使用触发器中指定的一个设备 ID和 RI进行注册,以保证后续与 RI成功交互, 如: 对于导入设备导入许可, 向 RI提供接收设备 ID 的情况, 在第二设备向 RI注册时使用的设备 ID与导入设备提供给 RI的设备 ID一致时, 第二设备才能成功获得导入设备导入的许可。
另外, 对注册触发器来说, 由于此时 RI和第二设备还没有进行 注册, 因此第二设备可能不知道 RI的公钥, 此时 RI也可以在签名的 同时将自己的证书或证书链放在触发器中一起传给第二设备。 但是, 由于 RI在注册前无法得知设备所信任的根 CA的情况, 因此无法保 证第二设备信任触发器中携带的证书链,在不信任证书的情况下验证 签名并不能保证安全性。 因此, 在注册触发消息中可以不携带 RI的 签名。
一个实施例中,第二设备收到注册触发器后的处理流程如图 8所 示, 包括以下步骤:
步骤 800、 第二设备接收到注册触发器。
步骤 801、第二设备判断触发器中是否指定了目的设备 ID,若是, 则执行步骤 802; 否则执行步骤 803。
步骤 802、 第二设备判断触发器中指定的目的设备 ID是否与本 设备的某个 ID相同, 若是, 则执行步骤 805; 否则执行步骤 804。
步骤 803、 第二设备向 RI发起注册交互流程, 若第二设备有多
个设备 ID, 则任选一个 ID和 RI进行注册。
步骤 804、第二设备的设备 ID与触发器中目的设备 ID不一致时, 第二设备丟弃该触发器, 结束触发流程。
步骤 805、 第二设备向 RI发起注册交互流程, 第二设备需要釆 用触发器中指定的本设备 ID和 RI进行注册,在注册请求消息中携带 该指定的本设备 ID。
图 7和图 8所示处理流程中, RI向设备下发触发器, 触发设备 执行相应操作, 当然, 对于其他服务实体, 如 DA、 LRM等, 也可以 通过下发触发器的方式触发设备执行相应操作,其处理流程与图 7和 图 8所示处理流程类似, 当然, 若触发器需要签名, 则由发放触发器 的其他服务实体来进行签名。
本领域普通技术人员可以理解上述实施例方法中的全部或部分 步骤是可以通过程序来指令相关的硬件完成 ,该程序可以存储于一计 算机可读存储介质中, 存储介质可以包括: ROM、 RAM, 磁盘或光 盘等。 本发明实施例中,第二设备接收到第一设备发送的包含目的设备 相关信息的触发器后,根据该相关信息确定本设备为接收到的触发器 的目的设备时, 执行触发器触发的操作, 从而使第二设备可以检验接 收到的触发器是否为发送给本设备的触发器,防止攻击者利用触发器 进行攻击, 特别是离开域触发器, 进行攻击的情况。 同时, RI、 DA 或 LRM等服务实体也可以通过下发的触发器指示第二设备釆用特定 的设备 ID和本设备进行交互。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解 到本发明可借助软件加必需的通用硬件平台的方式来实现, 当然也可 以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解, 本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以 软件产品的形式体现出来,该计算机机软件产品存储在一个存储介质
中,包括若干指令用以使得一台终端设备执行本发明各个实施例所述 的方法。
以上公开的仅为本发明的几个具体实施例, 但是, 本发明并非局 限于此,任何本领域的技术人员能思之的变化都应落入本发明的保护 范围。
Claims
1、 一种触发设备执行操作的方法, 其特征在于, 该方法包括以 下步骤:
第二设备接收第一设备发送的包含目的设备相关信息的触发器; 所述第二设备根据所述相关信息确定本设备为所述目的设备时, 执行所述触发器触发的操作。
2、 如权利要求 1所述触发设备执行操作的方法, 其特征在于, 所述第一设备包括版权发行者、 域管理器、 导入设备或转发消息的中 间设备。
3、 如权利要求 1所述的方法, 其特征在于, 所述触发器包括注 册触发器、 加入域触发器、 离开域触发器、 许可获取触发器或统计上 报触发器。
4、 如权利要求 3所述触发设备执行操作的方法, 其特征在于, 所述触发器为加入域触发器、 离开域触发器、许可获取触发器或统计 上报触发器时,所述触发器中还包括所述第一设备对所述相关信息的 签名。
5、 如权利要求 4所述触发设备执行操作的方法, 其特征在于, 所述第一设备用本设备的私钥对所述相关信息进行签名,所述第二设 备用所述第一设备的公钥验证该签名。
6、 如权利要求 1至 5任一项所述触发设备执行操作的方法, 其 特征在于, 所述操作包括注册、 加入域、 离开域、 获取许可或上报统 计信息。
7、 如权利要求 6所述触发设备执行操作的方法, 其特征在于, 所述相关信息包括设备的标识符和 /或名称, 所述第二设备将所述相 关信息中的标识符和 /或名称与本设备的标识符和 /或名称进行比较,
根据比较结果确定本设备为所述目的设备。
8、 如权利要求 7所述触发设备执行操作的方法, 其特征在于, 所述第二设备使用所述触发器中包含的本设备的标识和 /或名称执行 所述操作。
9、 如权利要求 8所述触发设备执行操作的方法, 其特征在于, 所述触发器为注册触发器时 ,所述第二设备在注册请求消息中携带所 述触发器中包含的本设备的标识和 /或名称。
10、 一种通信设备, 其特征在于, 包括:
生成单元, 用于生成包含目的设备相关信息的触发器; 通信单元, 用于发送所述触发器, 以触发所述目的设备执行相应 操作。
11、 一种通信设备, 其特征在于, 包括:
通信单元,用于接收其它设备发送的包含目的设备相关信息的触 发器;
确定单元,用于根据所述相关信息确定本设备是否为所述目的设 备; 发的操作。
12、 一种通信***, 其特征在于, 包括:
第一设备, 用于提供包含目的设备相关信息的触发器, 以触发目 的设备执行相应的操作;
第二设备,用于接收所述第一设备发送的包含目的设备相关信息 的触发器, 并在根据所述相关信息确定本设备为所述目的设备时, 执 行所述触发器触发的操作。
13、 如权利要求 12所述的通信***, 其特征在于, 所述触发器
为加入域触发器、 离开域触发器、许可获取触发器或统计上报触发器 时, 所述触发器中还包括所述第一设备对所述相关信息的签名。
14、 如权利要求 12或 13所述的通信***, 其特征在于, 所述第 二设备使用所述触发器中包含的本设备的标识和 /或名称执行所述操 作。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP08734062.6A EP2120385B1 (en) | 2007-04-16 | 2008-04-14 | Method, device and system for triggering device to operate |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200710097801.4 | 2007-04-16 | ||
CN 200710097801 CN101290641B (zh) | 2007-04-16 | 2007-04-16 | 触发设备执行操作的方法、设备及*** |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2008125056A1 true WO2008125056A1 (en) | 2008-10-23 |
Family
ID=39863274
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2008/070704 WO2008125056A1 (en) | 2007-04-16 | 2008-04-14 | Method, device and system for triggering device to operate |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP2120385B1 (zh) |
CN (1) | CN101290641B (zh) |
WO (1) | WO2008125056A1 (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2021205257A1 (en) * | 2020-04-09 | 2021-10-14 | International Business Machines Corporation | Key attribute verification |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1511347A2 (en) * | 2003-08-27 | 2005-03-02 | Koninklijke KPN N.V. | A method and system to restrict device features |
CN1851608A (zh) * | 2005-09-28 | 2006-10-25 | 华为技术有限公司 | Drm***内撤销ro的方法及*** |
CN1858769A (zh) * | 2006-02-17 | 2006-11-08 | 华为技术有限公司 | 一种对媒体内容的使用方进行限制的方法和*** |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1222819B1 (en) * | 1999-10-19 | 2004-07-21 | Thomson Licensing S.A. | System and method of verifying authorization for communicating protected content |
US7076467B1 (en) * | 2000-08-04 | 2006-07-11 | Sony Computer Entertainment America Inc. | Network-based method and system for transmitting digital data to a client computer and charging only for data that is used by the client computer user |
CN1564255A (zh) * | 2004-03-24 | 2005-01-12 | 华中科技大学 | 基于在线受控访问技术的数字存储媒体保护方法及其*** |
CN100395990C (zh) * | 2004-12-23 | 2008-06-18 | 华为技术有限公司 | 对设备进行授权许可的方法 |
-
2007
- 2007-04-16 CN CN 200710097801 patent/CN101290641B/zh active Active
-
2008
- 2008-04-14 EP EP08734062.6A patent/EP2120385B1/en active Active
- 2008-04-14 WO PCT/CN2008/070704 patent/WO2008125056A1/zh active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1511347A2 (en) * | 2003-08-27 | 2005-03-02 | Koninklijke KPN N.V. | A method and system to restrict device features |
CN1851608A (zh) * | 2005-09-28 | 2006-10-25 | 华为技术有限公司 | Drm***内撤销ro的方法及*** |
CN1858769A (zh) * | 2006-02-17 | 2006-11-08 | 华为技术有限公司 | 一种对媒体内容的使用方进行限制的方法和*** |
Non-Patent Citations (3)
Title |
---|
DIGITAL RIGHTS MANAGEMENT, DRM, SPECIFICATION VERSION 2.0, 16 July 2004 (2004-07-16) |
OMA DRM V2.0 EXTENSIONS FOR BROADCAST SUPPORT, 25 April 2006 (2006-04-25) |
See also references of EP2120385A4 * |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2021205257A1 (en) * | 2020-04-09 | 2021-10-14 | International Business Machines Corporation | Key attribute verification |
US11165588B1 (en) | 2020-04-09 | 2021-11-02 | International Business Machines Corporation | Key attribute verification |
GB2609168A (en) * | 2020-04-09 | 2023-01-25 | Ibm | Key attribute verification |
Also Published As
Publication number | Publication date |
---|---|
CN101290641B (zh) | 2010-10-13 |
EP2120385A4 (en) | 2010-05-12 |
EP2120385B1 (en) | 2015-11-04 |
CN101290641A (zh) | 2008-10-22 |
EP2120385A1 (en) | 2009-11-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9489498B2 (en) | Digital rights management using trusted processing techniques | |
WO2018050081A1 (zh) | 设备身份认证的方法、装置、电子设备及存储介质 | |
WO2016141856A1 (zh) | 一种用于网络应用访问的验证方法、装置和*** | |
US9177112B2 (en) | Method and device for communicating digital content | |
US20140281493A1 (en) | Provisioning sensitive data into third party | |
BRPI0313404B1 (pt) | "method and system for monitoring the customer's use of digital content loaded or transferred in continuous provided by a content provider to a customer system through a network" | |
US20180014196A9 (en) | Right object acquisition method and system | |
WO2008148356A1 (fr) | Procédé, dispositif et système destinés à transférer une autorisation | |
WO2013086968A1 (zh) | 一种网络安全防护方法、设备和*** | |
WO2006024216A1 (fr) | Procede pour mettre en oeuvre la certification et systemes correspondants | |
WO2007019760A1 (fr) | Methode et systeme pour terminal mobile se joignant a un domaine et obtenant un objet droits | |
US20080183831A1 (en) | Method, system, mobile terminal and ri server for withdrawing rights object | |
WO2020062667A1 (zh) | 数据资产管理方法、数据资产管理装置及计算机可读介质 | |
WO2024098730A1 (zh) | 星地一体化网络***的用户安全性提升 | |
Kravitz et al. | Achieving media portability through local content translation and end-to-end rights management | |
WO2013067792A1 (zh) | 智能卡的访问方法、装置及*** | |
WO2012000313A1 (zh) | 一种家庭网关认证方法和*** | |
WO2008125056A1 (en) | Method, device and system for triggering device to operate | |
WO2010127540A1 (zh) | 一种电视节目的分发方法及*** | |
WO2009015607A1 (fr) | Procédé, système et dispositif assurant la gestion de domaine pour un dispositif utilisateur par un gestionnaire de domaine |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 08734062 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2008734062 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |