WO2010012169A1

WO2010012169A1 - 在安全可移动媒介之间共享许可的方法及装置

Info

Publication number: WO2010012169A1
Application number: PCT/CN2009/071721
Authority: WO
Inventors: 黄晨; 张仁宙; 周志鹏; 袁卫忠
Original assignee: 华为技术有限公司
Priority date: 2008-07-29
Filing date: 2009-05-11
Publication date: 2010-02-04
Also published as: EP2323065A1; CN101640589A; US20110119494A1; EP2323065A4; US20130111604A1; CN101640589B; US8719956B2

Description

在安全可移动媒介之间共享许可的方法及装置本申请要求于 2008 年 7 月 29 日提交中国专利局、申请号为 200810134766.3、发明名称为"在安全可移动媒介之间共享许可的方法及装置" 的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本发明涉及数字版权管理（ Digital Rights Management, DRM )技术领域，尤其涉及一种在安全可移动媒介 ( Secure Removable Media, SRM )之间共享许可的方法及装置。

背景技术

为了保护内容所有者的合法权益， DRM通过内容保护和权限控制方案管理数字内容的使用。

典型的 DRM方案包括：数字内容发行者（ Content Issuer, CI )用内容加密密钥（ Content Encryption Key, CEK )对数字内容进行加密打包为内容数据包（ DRM Content Format, DCF )分发给设备，并将数字内容的内容标识与对应的 CEK提供给版权发行者（ Rights Issuer, RI )； RI生成与数字内容对应的许可并发送给设备中执行 DRM功能的代理 DRM Agent , 许可中包括加密的 CEK和使用内容的权利和限制，权利包括执行、播放和转移等，限制包括次数、累积时间和有效期等。 DRM Agent获得 DCF和许可后，可解密得到 CEK, 进而解密得到内容，并按照许可中的权限使用数字内容。

SRM是可以保护内部数据不被未授权访问的可移动媒介。通过使用 SRM 存储和转移 DCF和许可，扩大了存储空间，提供了许可的可移动性。

在某些场景下，用户希望将许可赠送给他人或者更换 SRM, 这就需要将许可从一个 SRM转移（ Move )或复制（ Copy )到另一个 SRM上。随着一机多卡的普及，用户对在 SRM卡之间共享许可的需求更加普遍。

开放移动联盟（ Open Mobile Alliance ) 的 SRM标准中给出了许可从设备转移到 SRM中和许可从 SRM中转移到设备的协议。 SRM Agent为 SRM中执行 DRM相关功能的实体。

现有方案提供了将许可从 DRM Agent转移到 SRM的方案，也提供了将许可从 SRM转移到 DRM Agent的方案，不论在哪种转移方案中，每次转移都需要扣除共享权限，那么，如果要实现将许可从 SRM1转移到 SRM2, 至少需要经过将许可首先从 SRM1转移到 DRM Agent, 然后再由 DRM Agent转移给 SRM2,也就是说至少需要扣除两次共享权限。本发明人在发明的过程中发现，现有技术中对许可的转移需要多次权限，对用户而言造成不必要的权限浪费发明内容

本发明提供一种在 SRM之间共享许可的方法及装置，以解决现有方案存在的过多消耗共享权限的问题。

为此，本发明实施例采用如下技术方案：

一种在 SRM之间共享许可的方法，包括： DRM Agent从第一 SRM获取许可，并将所述许可在本地设置为中转状态；所述 DRM Agent将所述许可的共享权限扣除一次；所述 DRM Agent将所述许可发送给第二 SRM。

一种共享许可的方法，包括： DRM Agent触发第一 SRM和第二 SRM协商共享密钥；所述第一 SRM使用所述共享密钥加密所述许可的部分或全部信息；所述第一 SRM将所述许可发送给第二 SRM。

一种共享许可的方法，包括：第一 DRM Agent从第一 SRM获取许可后，发送给版权发行者 RI；第二 DRM Agent从 RI获取所述许可，并发送给第二 SRM。

一种共享许可的方法，包括： DRM Agent确定所述第一 SRM和第二 SRM 属于相同用户时，将从第一 SRM获取的许可发送给第二 SRM。

一种共享许可的装置，其特征在于，包括：获取单元，用于从第一 SRM 获取许可；中转设置单元，用于将所述获取的许可设置为中转状态；发送单元，用于将所获取的许可发送给第二 SRM; 控制单元，扣除一次共享权限。

一种共享许可的装置，其特征在于，包括： SRM交互单元，用于触发第一 SRM和第二 SRM进行密钥协商；转发单元，用于将所述第一 SRM的许可转发给第二 SRM。。

一种在第一 SRM和第二 SRM之间共享许可的装置，位于第一 SRM中，包括：密钥协商单元，用于与第二 SRM进行密钥协商；处理单元，用于利用与第二 SRM协商的共享密钥对许可的部分或全部信息加密；发送单元，用于将许可发送给第二 SRM。

一种共享许可的装置，位于第二 SRM中，包括：密钥协商单元，用于与第一 SRM进行密钥协商；接收单元，用于接收第一 SRM发送的许可；权限扣除单元，用于在所述接收单元接收到正确的许可后，扣除一次操作权限。

一种共享许可的装置，包括：获取单元，用于从第一 DRM Agent获取第一 SRM的许可；发送单元，用于向第二 DRM Agent发送所述许可，通过第二 DRM Agent提供给第二 SRM。

一种共享许可的装置，包括：确定单元，确定所述第一 SRM和第二 SRM 是否属于相同用户；获取单元，用于在所述确定单元确定第一 SRM和第二 SRM 属于相同用户时，从所述第一 SRM获取许可；执行单元，用于将所述许可发送给第二 SRM。

与现有方案在许可从 SRM1转移到设备过程中需要扣除一次 Move权限、在设备转移到 SRM2过程中需要扣除另一次 Move权限相比，本发明实施例通过将 DRM Agent中转的许可设置为中转状态，由此仅扣除一次 Move权限，减少了 Move权限的消耗，有利于维护用户权益。

在本发明另一实施例中，在 SRM2确定可以安装 Rights后，才将 SRM1 中的 Rights删除，这在 SRM2无法安装 Rights的情况下， DRM Agent恢复 SRM1 上的原 Rights操作比较筒单，仅需将 Rights恢复为可用状态。

在本发明另一实施例中，是通过 SRM1和 SRM2之间建立 SAC,由该 SAC 将许可进行转移，其中的 DRM Agent仅是执行转发功能，由于转发的 Rights 是经过 SRM1和 SRM2协商的密钥加密的， DRM Agent无法对其执行操作，这在一定程度上提高了 Rights安全性。

在本发明另一实施例中，由于是 RI向 SRM2提供许可，因此可能不需要消耗 Move权限或 Copy权限，因此实施例四也适用于同一用户的 SRM之间许可的共享。

在本发明另外实施例中，在属于相同用户的 SRM之间共享许可， DRM Agent均向 RI查询 SRM所属的用户，如果 RI无法获知 SRM所属的用户，可能需要向其它实体，如用户管理器，查询 SRM所属的用户，或者 DRM Agent 可以直接向管理 SRM和用户关系的实体，如用户管理器，查询 SRM所属的用户，此时由于是在属于相同用户的 SRM之间共享许可，因此不需要扣除共享权限，节省了用户资源。

附图说明

图 1为本发明在 SRM之间共享许可方法实施例一流程图；

图 2为本发明在 SRM之间共享许可方法实施例二流程图；

图 3为本发明在 SRM之间共享许可方法实施例三流程图；

图 4为本发明图 3中 SRM之间协商共享密钥的流程图；

图 5为本发明在 SRM之间共享许可方法实施例四流程图；

图 6为本发明在属于相同用户的 SRM之间共享许可方法实施例五流程图；图 7为本发明在属于相同用户的 SRM之间共享许可方法实施例六流程图；图 8为本发明实施例 DRM Agent侧的第一装置结构示意图；

图 9为本发明实施例 DRM Agent侧的第二装置结构示意图；

图 10为本发明实施例第一 SRM侧的第三装置结构示意图；

图 11为本发明实施例第二 SRM侧的第四装置结构示意图；

图 12为本发明实施例 RI或用户管理器侧的第五装置结构示意图；图 13为本发明实施例 DRM Agent侧的第六装置结构示意图。

具体实施方式

本发明实施例提供一种在 SRM之间共享许可的方案，通过 DRM Agent 或 RI等设备将 SRM1中的许可共享给 SRM2, 仅消耗一次共享权限。

上述所谓的共享许可，包括转移许可和复制许可等情况，下面着重以转移许可为例对方法实施例进行说明。

下面介绍在 SRM之间共享许可方法的各个实施例。

概括而言，实施例一和实施例二方法包括以下步骤：

[1] DRM Agent从第一 SRM获取许可，并将所述许可在本地设置为中转状态；

[2] 所述 DRM Agent将所述许可的共享权限扣除一次；

[3] 所述 DRM Agent将所述许可发送给第二 SRM。其中，所述共享许可是指复制许可，所述共享权限是指复制权限；或者，所述共享许可是指转移许可，所述共享权限是指转移权限。

当所述共享许可是指转移许可时，还需要执行以下步骤：所述 DRM Agent 触发所述第一 SRM删除许可。

实施例一与实施例二主要区别即在于执行该步骤的时机不同，在实施例一中，是在所述 DRM Agent将获取的许可设置为中转状态后，执行所述 DRM Agent触发所述第一 SRM删除许可的步骤；而在实施例二中，是在所述 DRM Agent确定所述第二 SRM接收到所述许可后，执行所述 DRM Agent触发所述第一 SRM删除许可的步骤。

下面首先介绍实施例一。

参见图 1 ,是在 SRM1和 SRM2之间共享许可方法实施例一流程图，包括：

S101 : DRM Agent和 SRM Agentl相互认证并建立安全认证通道（ Secure Authenticated Channel, SAC ), 认证过程中 DRM Agent和 SRM Agentl互相交换证书并验证对方证书的有效性，交换随机数并根据随机数生成通信密钥，包括加密密钥和完整性保护密钥。

在 DRM Agent和 SRM Agent之间建立 SAC为现有技术，此处不过多描述。

S102-S103: DRM Agent发起将 SRM1上的 Rights直接转移到另一 SRM: SRM2 ,该操作可由用户通过和 DRM Agent的交互触发， DRM Agent从 SRM1 获取 Rights信息和 REK, 具体为现有技术。

S104: DRM Agent验证 Rights信息及 Move权限，并在验证通过后扣除

Move权限，具体为现有技术。扣除 Move权限具体可表现为将 Rights对应的状态信息中 Move权利的剩余次数扣减一次；或者，将 Rights对应的状态信息中 Move权利的已使用次数增加一次。 Rights在设备上设置为中转状态，即指定必须转移给另一 SRM, 即 DRM Agent不可用其消费内容。如果此时 DRM Agent已获知转移的目的设备为 SRM2, 则可指定具体 SRM2标识。

S105-106: DRM Agent指示 SRM Agentl删除该 Rights, 具体步骤为现有技术。

S107-S108: DRM Agent查询 SRM2是否有足够的空间安装该 Rights, 具体为现有技术。在 S107之前 DRM Agent和 SRM Agent2互相认证并建立 SAC通道。图 1 中以 S107a表示。如果 DRM Agent可同时和两个 SRM Agent交互，则 S107a 在 S107之前任意时刻执行即可。

如果 DRM Agent不能同时和两个 SRM Agent交互，则在 S107之前可先和 SRM1断开连接，再和 SRM2连接执行后续步骤。执行后续步骤的过程可由用户操作设备触发，具体的可以将 Rights在设备处存储为特殊格式的文件，用户浏览确定该 Rights处于中转状态，选择将该文件转移到另一 SRM完成中转，或者设备将 Rights信息提示给用户，用户选择是否继续转移。或者设备可根据 Rights关联的目的设备的标识自动执行，例如在连接到 SRM2时搜索本地处于中转状态且关联的目的设备为 SRM2的 Rights , 并自动执行 S 107后续步骤。

S109-S110: DRM Agent向 SRM Agent2发送 Rights安装请求消息，消息中包含 handle, REK、内容标识的 hash的列表、 Rights信息， SRM2安装 Rights 并返回响应，即不必进行第二次 Move权限的扣除，因此减少了扣除 Move权限的次数。

S111 : 如果 SRM2成功安装 Rights, 贝¹ J DRM Agent删除本地的 Rights。可选地，在 S104中不扣除 Move权限，而在将 Rights安装到 SRM2时再在设备上执行扣除 Move权限的操作。

另夕卜，在 S106之后，设备可以保留该中转 Rights的源 SRM即 SRM1的记录，这样如果在 Rights安装到 SRM2的过程中发生意外而导致失败，例如

SRM2没有足够的空间安装该 Rights , 可以将 Rights重新恢复到 SRM1上，从而保证用户的权益不受损害。

实施例一是以转移（Move )许可为例对共享许可进行说明，如前所述，共享还包括复制（ Copy ),将 SRM1中的许可复制到 SRM2的过程与图 1类似，不同在于，在复制过程中消耗的是 Copy权限： DRM Agent将 SRM1上的所述许可的 Copy权限扣除一次， DRM Agent发送给 SRM2的许可不包含 Copy权限；或者 DRM Agent将发送给 SRM2的许可的 Copy权限扣除一次，并将 SRM1 上的许可的 Copy权限全部扣除。 SRM 1无需删除该许可。

可见，与现有方案在许可从 SRM1转移到设备过程中需要扣除一次共享权限、在许可从设备转移到 SRM2过程中需要扣除另一次共享权限相比，本发明实施例通过将 DRM Agent 中转的 Rights设置为中转状态，由此仅扣除一次 Move权限，减少了 Move权限的消耗，有利于维护用户权益。

下面介绍在 SRM之间共享许可方法的实施例二。

在上述实施例一中图 1的 S107-S108中，如果 Rights安装到 SRM2的过程失败，将 Rights重新恢复到 SRM1则较为复杂，较佳的方案是在确认 SRM2 有足够的空间安装 Rights后，再删除 SRM1上的 Rights。

参见图 2, 实施例二流程包括：

S201： DRM Agent分别和 SRM Agentl、 SRM Agent2互相认证并建立 SAC 通道， DRM Agent和 SRM Agent2的认证可以在 S205之前任何时候进行。

S202-S203: DRM Agent发起将 SRM1上的 Rights直接转移到 SRM2, 该操作可由用户通过和 DRM Agent的交互触发， DRM Agent从 SRM1获取 Rights 信息和 REK。

S204: DRM Agent验证 Rights信息以及 Move权限，并在验证通过后扣除 Move权限。扣除 Move权限的操作可以在 S406之后再执行。

S205-S206: DRM Agent查询 SRM2是否有足够的空间安装该 Rights。 S207-S208: DRM Agent向 SRM Agent2发送 Rights安装请求消息，消息中包含 handle, REK、内容标识的 hash的列表、 Rights信息， SRM2安装 Rights 并返回响应。如果 SRM2成功安装 Rights, 贝¹ J DRM Agent删除本地的 Rights。

S209-S210:如果 SRM2成功安装 Rights ,则 DRM Agent指示 SRM Agentl 删除该 Rights。

其中， S209-S210也可以在 S206之后执行。

如果在将 Rights安装到 SRM2的过程中发生错误，例如 SRM2空间不够，则 DRM Agent可以取消 Move操作，恢复 SRM1上的原 Rights。如果 DRM Agent 和某一 SRM连接中断，则 DRM Agent可记录中断日志，中断日志具体包括：操作类型、当前状态、许可标识、 SRM1 标识、许可在 SRM1上对应的 handle 1、 SRM2标识、许可在 SRM2上对应的 handle2。下次连接时根据中断日志中的信息进行恢复：继续将许可发送到 SRM2, 完成操作；或者取消操作，将许可恢复到 SRM1。为了从一定程度上提高 REK的安全性，可以由 DRM Agent将 SRM2的公钥或证书提供给 SRM Agentl , SRM Agentl使用 SRM2的公钥对 REK进行加密后通过 DRM Agent传输给 SRM2。

可见，实施例二与实施例一相比，在 SRM2确定可以安装 Rights后，才将 SRM1中的 Rights删除，这在 SRM2无法安装 Rights的情况下， DRM Agent 恢复 SRM1上的原 Rights操作比较筒单，仅需将 Rights恢复为可用状态。

下面介绍在 SRM之间共享许可方法的实施例三。

在实施例三中，通过 DRM Agent协助，在 SRM1和 SRM2之间建立 SAC, 并使用 SAC密钥共享许可。下面仍以转移许可为例介绍实施例三，对于复制许可，与其类似。

概括而言，实施例三包括以下步骤：

[1] DRM Agent触发第一 SRM和第二 SRM协商共享密钥；

[2] 第一 SRM使用协商的共享密钥加密许可的部分或全部信息；

[3] 第一 SRM将许可发送给第二 SRM。

下面结合附图对实施例三详细流程进行介绍。

参见图 3 , 为实施例三流程图，包括：

S301 : DRM Agent分别和 SRM Agentl和 SRM Agent2交换各自支持的信任错 ( Trust anchor )。

S302: DRM Agent触发 SRM Agentl和 SRM Agent2认证。消息中包含选择的 Trust anchor, DRM Agent可根据待转移的 Rights来选择。可选的，触发消息中还可包含 SRM2标识。本步骤可由用户选择在两个 SRM之间转移 Rights 的操作触发。

S303: SRM Agentl向 SRM Agent2发送认证请求。请求中包含 Trust anchor, SRM1证书链、 SRM Agentl支持的算法等。如果 SRM Agentl和 SRM Agent2 之间可以直接通信，则消息可不经过 DRM Agent,否则所有的消息都需要 DRM Agent代为中转。

S304: SRM Agent2向 SRM Agentl返回认证响应。响应中包含 SRM Agent2 证书链、 SRM2选择的算法、用于生成密钥的随机数 RN1 , 其中 RN1需要使用 SRM2的公钥加密传输。 S305: SRM Agentl向 SRM Agent2发送密钥交换请求。请求中包含用于生成密钥的随机数 RN2, 其中 RN2需要使用 SRM1的公钥加密传输。

S306: SRM Agent2向 SRM Agentl返回密钥交换响应。响应中可能包含 RN1和 RN2的连接值的 Hash用于确认随机数。至此， SRM1和 SRM2均获得 RN1和 RN2, 分别使用 RN1和 RN2生成会话密钥和 MAC密钥。

S307: DRM Agent触发 SRM Agentl向 SRM2转移 Rights, 消息中可包含该 Rights在 SRM1上对应的 Handle或者许可标识。

S308: SRM Agentl 向 SRM Agent2发送初始化转移请求，请求中包含 Rights的大小，可能包含该 Rights在 SRM2上对应的 Handle。

S309: SRM Agent2检查本地是否有足够的空间安装该 Rights, 如果 S508 中 SRM Agentl发送了 Handle, 贝' J SRM Agent2需要检查该 Handle和 SRM2 上已有的 Handle是否重复。并在向 SRM Agentl返回的初始化转移响应中包含检查结果。如果 S308中 SRM Agentl没有发送 Handle, 则 SRM Agent2可自动生成一个和本地其他 Handle不同的 Handle, 并可在响应中返回。

S310: SRM Agentl向 SRM Agent2发送转移请求，请求中包含 Rights信息、 REK、 Rights关联的内容标识等，如果 SRM Agentl获知 Rights在 SRM2 上关联的 Handle , 则可在请求消息中包含该 Handle。

S311 : SRM Agent2验证 Rights信息，险证通过后扣减 Move权限，并将 Rights存放在 SRM2中。

可选的，也可由 SRM Agentl在步骤 S310之前检查 Move权限并扣减，这样，在步骤 S311中 SRM Agent2无需扣减 Move权限

与实施例一或实施例二相比，实施例三中是通过 SRM1和 SRM2之间建立 SAC , 由该 SAC将许可进行转移，其中的 DRM Agent仅是执行转发功能，由于转发的 Rights是经过 SRM1和 SRM2协商的密钥加密的， DRM Agent无法对其执行操作，这在一定程度上提高了 Rights安全性。

但是如果 SRM1 和 SRM2 由于能力问题无法险证 Rights, 则可由 DRM Agent代为验证，并扣减 Move权限，可在 S310中执行，这需要 SRM Agentl 或 SRM Agent2将 MAC密钥告知 DRM Agent。

图 3中 S301-S306完成的在两个 SRM间协商共享密钥的过程为本发明实施例新提出的，概括而言包括以下步骤：

[ 1 ] DRM Agent向第一 SRM发起认证过程，获取第一 SRM证书链；

[2] DRM Agent向第二 SRM发起认证过程，将所获取的第一 SRM证书链发送给第二 SRM , 并从第二 SRM获取第二 SRM证书链和第一 SRM公钥加密的第二随机数；

[3] DRM Agent向第一 SRM发起密钥交换过程，将所获取的第二 SRM证书链和第一 SRM公钥加密的第二随机数发送给第一 SRM, 并从第一 SRM获取第二 SRM公钥加密的第一随机数；

[4] DRM Agent向第二 SRM发起密钥交换过程，将所获取的第二 SRM公钥加密的第一随机数发送给第二 SRM；

[5] 第一 SRM和第二 SRM利用所述第一随机数和第二随机数，确定共享密钥。

该过程可以和 DRM Agent和两个 SRM协商共享密钥的过程一起完成，下面结合图 4, 对其进一步描述：

S401 : DRM Agent分别和 SRM Agentl和 SRM Agent2交换各自支持的

Trust anchor。

S402: DRM Agent向 SRM Agentl发起认证请求。消息中包含选择的 Trust anchor, 对应该 Trust anchor 的设备证书链等。 DRM Agent可才艮据待转移的 Rights来选择 Trust anchor„

S403: SRM Agentl返回认证响应。响应消息中包含 SRM1证书链，使用设备公钥加密的随机数 RNsldo

S404: DRM Agent向 SRM Agent2发起三方认证请求。消息中包含选择的 Trust anchor , 对应该 Trust anchor的设备证书链和 SRM 1证书链等。

S405: SRM Agent2返回三方认证响应。响应消息中包含 SRM2证书链，使用设备公钥加密的随机数 RNs2d和使用 SRM 1公钥加密的随机数 RNs2s 1。

S406: DRM Agent向 SRM Agentl发送三方密钥交换请求。消息中包含 SRM2证书链，使用 SRM 1公钥加密的随机数 RNs2s 1 , 使用 SRM 1公钥加密的随机数 RNdsl (可以和 RNsld的哈希连接后再使用 SRM1公钥加密）。

S407: SRM Agentl返回三方密钥交换响应。响应消息中包含使用 SRM2 公钥加密的随机数 RN sls2 (可以和 RNs2sl的哈希连接后再使用 SRM2公钥加密），可能包含 RNds 1和 RNs 1 d的连接值的哈希。

S408: DRM Agent向 SRM Agent2发起三方密钥交换请求。消息中包含使用 SRM2公钥加密的随机数 RNsls2 (可以和 RNs2sl 的哈希连接后再使用 SRM2公钥加密），使用 SRM2公钥加密的随机数 RNds2 (可以和 RNs2d的哈希连接后再使用 SRM2公钥加密）。

S409: SRM Agent2返回三方密钥交换响应。响应消息中可能包含 RN sls2 和 RNs2sl的连接值的哈希以及 RNds2和 RNs2d的连接值的哈希。

至此， DRM Agent和 SRM Agentl、 SRM Agent2两两之间共享了一对随机数，可各自独立用其生成密钥。这样， SRM1向 SRM2转移 Rights时，重要信息如 REK可以使用与 SRM2之间的共享密钥加密，而其他信息可以使用和 DRM Agent间的共享密钥加密或进行完整性保护以方便 DRM Agent处理。

DRM Agent向 SRM Agentl和 SRM Agent2提供的随机数可以一样，这样三方可以使用此公共随机数生成三方公共密钥。

或者， DRM Agent可以将 SRM Agentl提供的 RNsld作为 RNds2提供给

SRM Agent2, 将 SRM Agent2提供的 RNs2d作为 RNdsl提供给 SRM Agentl , 也可生成三方共享密钥。

目前 SRM Agent和 DRM Agent使用随机数生成密钥时是按照 RNd和 RNs 的顺序连接，但在本方案中为了保证密钥的一致性，可以默认对于每对随机数按照传输的顺序连接，即 SRM Agentl使用 RNsld和 RNdsl的顺序连接，而 SRM Agent2则使用 RNds2和 RNs2d的顺序连接。在不影响密钥的一致性的情况下，也可使用其它方式生成密钥。

通过 DRM Agent将 Rights从 SRM1转移到 SRM2的过程中，为了安全起见， SRM1可在获得 SRM2收到 Rights的确认后才删除 Rights。具体的， SRM2 的确认可以是使用私钥对安装信息（如 REK ) 的签名，或者使用仅由 SRM1 和 SRM2共享的密钥对安装信息（如 REK )进行加密的结果；或者由 SRM1 向 SRM2提供确认信息（如随机数），该确认信息可以使用 SRM2的公钥或者 SRM1和 SRM2共享的密钥加密传输， SRM2向 SRM1表示获知该确认信息，例如使用私钥对其签名或对该确认信息进行某种转换（如哈希或筒单的加一操作 )后使用 SRM1和 SRM2共享的密钥加密返回。

下面介绍在 SRM之间共享许可方法的实施例四。

以上方案中通过 DRM Agent在两个 SRM之间转移 Rights ,某些情况下可能两个 SRM位于不同的地方，无法直接连接到同一个 DRM Agent, 则可能需要经过多个 DRM Agent代为中转。例如，可由 DRM Agentl从 SRM1获取 Rights, 转移到 DRM Agent2并指明给 SRM2, DRM Agent2将该 Rights转移到 SRM2。

此外，也可以通过 RI在两个 SRM之间转移 Rights, 概括而言，包括以下步骤：

[1] 在第一 DRM Agent从第一 SRM获取许可后，发送给 RI;

[2]所述第二 DRM Agent从 RI获取许可并发送给第二 SRM。

具体流程如图 5所示：

S501 : RI向 DRM Agentl发送触发器 ROAP trigger{SRMROUpload}，触发设备 Upload SRM上的许可。触发器包括： RI标识、 RIURL等信息，并包括布尔类型的 roRequested ,用于表示 RI是否需要 SRM上报待 upload的 rights , 如果 RI緩存了下发的许可，则该属性为 false, 否则为 tme。触发器中可选的包含 SRM1标识和许可标识。本步骤是可选的，用户可以通过人机界面操作设备 upload SRM 1上的许可，直接从 S502开始。

S502: DRM Agentl向 SRM Agentl发送 RightsUpload请求消息，消息中包含：标识 Rights的 handle, 用于替换该 handle的新 handle。在 S502之前 DRM Agentl和 SRM Agentl之间需要互相认证和建立 SAC通道。

S503: SRM Agentl判断新 handle是否和本地其它 handle重复，如果不重复，则使用新 handle替换步骤 1中的 handle, 并将 Rights置为不可用。 SRM Agentl向 DRM Agentl返回 RightsUpload响应消息，如果 handle不重复，则消息中还包含 Rights信息， REK , Kmac , 时间戳，以及 SRM Agentl对 {指明 upload的标志、 REK、 RI标识、时间戳 }的签名。

S504: DRM Agentl检查 Rights信息中的 RI签名以及状态信息是否超出 Rights中的原始权限。

S505: DRM Agentl向 RI发送 SRMROUpload请求消息，其中除了请求消息包含的一些公共参数，如设备 1标识、 RI标识、 nonce、时间戳、设备 1 证书链等之外，还包含 upload信息：

• 从 SRM Agentl获取的 Rights信息中的 RightsObjectContainer部分

(即原 RI下发的许可中的<1^1^>和<8181^1^> )或对其格式转换后的结果，如果 RI在 ROAP trigger { SRMROUpload }中标记 roRequested为 false , 则该参数可省略；

• 如果该许可为有状态的，则包括从 SRM Agentl获取的 Rights信息中的状态信息；

• RI公钥加密的 REK和 Kmac；

· SRM 1标识、 SRM 1证书链、 SRMRightsUpload响应消息中的时间戳、 SRM Agentl对{指明 upload的标志、 REK、 RI标识、时间戳 }的签名；

• 以及使用 Kmac对上述参数进行 MAC操作的结果。

DRM Agentl需对请求消息中的参数进行签名，并将签名在请求消息中一起发送给 RI。

S506: RI对请求消息中的各参数进行验证：

• 如果请求消息中有 DRM Agentl证书链，则验证其有效性（可能需要通过 OCSP或 CRL实现），并使用请求消息中的设备 1证书链或 RI本地的设备上下文中的设备 1证书链验证请求消息中 DRM Agentl的签名；

• 解密得到 REK和 Kmac , 使用 Kmac验证请求消息中的 MAC值； · 验证 SRM1证书链的有效性，可能需要通过 OCSP或 CRL实现，并使用 SRM 1证书链验证 SRM 1签名信息的有效性；

• 验证请求消息中的时间戳早于当前时间，验证 SRMRightsUpload响应消息中的时间戳早于请求消息中的时间戳；

• 验证 <1^111；8>和<818 1；1^>的正确性（如果请求消息中有的话），如果许可为有状态的，还需验证状态信息在原始许可范围内；

• 尝试使用 REK解密 <rights>元素中的加密的 CEK验证 REK和 Rights 的正确性。

S507: DRM Agentl向 SRM Agentl发送 RightsRemovalRequest消息，消息中包含标识 Rights的 handle, 此 handle即 S502中的新 handle。 S508:SRM Agentl 删除 RightsRemovalRequest 消息中的 handle对应的 Rights,并向 DRM Agentl返回 RightsRemovalResponse消息，其中包含处理结果。

S509:RI向 DRM Agent2发送触发器 ROAP trigger { SRMRO Acquisition} , 触发 DRM Agent2协助 SRM2获取 Upload的许可，触发器中包含 RI标识、 RI别名、 RI URL、许可标识、许可别名、内容标识、以及 RI是否保存了设备 2和 SRM2的证书链等参数。 DRM Agent2和 DRM Agentl可以为同一 DRM Agent。本步骤是可选的，用户可以通过人机界面操作设备代理 SRM2获取许可，直接从 S510开始。

S510: DRM Agent2向 RI发送获取许可请求，请求消息中包含设备 2标识、 RI标识、 nonce、时间戳、许可标识、 SRM2标识、设备 2证书链及 SRM2 的证书链等，如果 trigger中指示 RI已保存设备 2或 SRM2的证书链，则无需重复发送。在步骤 10之前 DRM Agent2和 SRM Agent2之间需要互相认证和建立 SAC通道。

S511： RI向 DRM Agent2返回许可响应，响应消息中包 ^殳备 2标识、

RI标识、 nonce、受保护的许可、 RI证书链（如果 DRM Agent2在请求消息中标识其已经保存了 RI证书链，则此参数不需要）。许可可以绑定 SRM2, 也可以绑定 DRM Agent2, 但指定必须提供给 SRM2。

S512: DRM Agent2将 RI下发的许可写入 SRM2。如果许可绑定 SRM2, 贝¹ J DRM Agent2可先将加密的 REK和 Kmac的连接值发送给 SRM Agent2 , 由 SRM Agent2提供 Kmac,并用其险证许可的完整性，再由 DRM Agent2将 rights 和 signature等写入 SRM2。如果许可绑定 DRM Agent2, 则由 DRM Agent2解密出 REK后和 rights, signature等一起写入 SRM2。

上述流程中 S507-S508和 S509-512没有时间上的顺序关系。

以上是对在 SRM之间共享许可方法的各个实施例的介绍，其中的实施例一至实施例三，仅需要消耗一次 Move权限或 Copy权限，而实施例四，由于是 RI向 SRM2提供许可，因此可能不需要消耗 Move权限或 Copy权限，因此实施例四也适用于同一用户的 SRM之间许可的共享。如果在同一用户的 SRM 之间共享许可还需要消耗共享权限，对用户而言则是一种损失，因此，本发明实施例还提供一种在相同用户的 SRM之间共享许可的方案，此时不需要消耗共享权限。

虽然在同一用户的 SRM之间共享 Rights不会消耗 Rights的 Move权限，但是 RI需要验证 SRM2和 SRM1属于同一用户，验证方法包括多种：可以是 RI根据本地保存的 SRM标识和用户标识的对应关系验证，或者 RI向另一实体（如用户管理器）查询，或者 RI根据用户使用 SRM提供的信息（如密码、问题答案等）来验证。

用户可以一次性 Upload 多个许可到 RI, 也可以一次性安装多个许可到 SRM2。这种批量处理方式尤其适用于用户更换 SRM卡的情况。

作为在同一用户的 SRM之间共享 Rights的替代方案，可以由 DRM Agent 向 RI查询 SRM1和 SRM2是否属于同一用户，并直接进行 Rights的共享，无需 RI重新生成许可。

概括而言，本发明实施例提供的在属于相同用户的 SRM之间共享许可的方法包括以下步骤：

[l] DRM Agent确定第一 SRM和第二 SRM属于相同用户时，将从第一

SRM获取的许可发送给第二 SRM。

其中，在实施例五和实施例六中，区别主要在所述 DRM Agent向 RI或用户管理器查询第一 SRM和第二 SRM所属用户的过程不同。

下面详细介绍在属于相同用户的 SRM之间共享许可的各个实施例。

首先介绍在属于相同用户的 SRM之间共享许可的实施例五。

概括而言，实施例五中查询第一 SRM和第二 SRM所属用户的过程为： [1] DRM Agent向 RI或用户管理器发送包含第一 SRM标识的查询消息，查询所述第一 SRM所属用户；

[2] DRM Agent向 RI或用户管理器发送包含第二 SRM标识的查询消息，查询所述第二 SRM所属用户；

[3] DRM Agent验证第一 SRM和第二 SRM是否属于相同用户。

参见图 6, 为实施例五流程图，包括：

S601 : DRM Agent根据用户请求发起将 SRM1上的 Rights共享给同一用户的另一 SRM, DRM Agent从 SRM1获取 Rights信息和 REK。在 S601之前 DRM Agent和 SRM Agentl之间需要互相认证和建立 SAC通道。

S602-S603: DRM Agent向 RI查询 SRM1所属的用户。请求中包含 SRM1 标识， RI在响应消息中返回用户标识。

S604: DRM Agent检查 Rights信息中的 RI签名以及状态信息是否超出 Rights 中的原始权限并在验证通过后安装该 Rights , DRM Agent在安装该

Rights时标识该 Rights不可用，并指定关联到 S603中 RI返回的用户标识。

S605: 如果共享操作为转移，则 DRM Agent指示 SRM1删除该 Rights, 具体步骤如图 1中 S105-S106。

S606-S607: DRM Agent将 Rights共享给 SRM2。由于 Rights绑定用户标识， DRM Agent向 RI查询 SRM2所属的用户。请求中包含 SRM2标识， RI 在响应消息中返回用户标识。在 S606之前 DRM Agent和 SRM Agent2之间需要互相认证和建立 SAC通道。

S608: DRM Agent验证 SRM2所属的用户与 Rights绑定的用户是否一致，即和 SRM1所属的用户是否一致。如果一致则执行 S609, 否则拒绝将 Rights 共享给 SRM2。

S609: DRM Agent将 Rights安装到 SRM2,具体步骤如图 1中 S107-S110。 S610: 如果 SRM2成功安装 Rights, 则 DRM Agent删除本地的 Rights。下面介绍在属于相同用户的 SRM之间共享许可的实施例六。

与实施例五中 DRM Agent分别查询 SRM1和 SRM2所属的用户并自行进行比较不同，该实施例六中由 DRM Agent将 SRM1和 SRM2的标识上报给 RI, 由 RI进行比较后返回比较结果。这种情况下 DRM Agent无需了解用户标识细节。

概括而言，实施例六中查询第一 SRM和第二 SRM所属用户的过程为： [1] DRM Agent向 RI或用户管理器发送包含第一 SRM标识和第二 SRM 标识的查询消息，查询所述第一 SRM和所述第二 SRM是否属于相同用户；

[2] RI或用户管理器向 DRM Agent返回查询响应，告知所述第一 SRM和第二 SRM是否属于相同用户。

参见图 7, 实施例六包括：

S701 : DRM Agent根据用户请求发起将 SRM1上的 Rights共享给同一用户的另一 SRM, DRM Agent从 SRM1获取 Rights信息和 REK, 具体步骤如图 1中 S102-S103。在 S701之前 DRM Agent和 SRM Agentl之间需要互相认证和建立 SAC通道。

S702: DRM Agent检查 Rights信息中的 RI签名以及状态信息是否超出 Rights 中的原始权限并在验证通过后安装该 Rights , DRM Agent在安装该 Rights时标识该 Rights不可用，并指定关联到 SRM1的用户。

S703: 如果共享操作为转移，则 DRM Agent指示 SRM1删除该 Rights, 具体步骤如图 1中 S105-S106。

S704-S705: DRM Agent将 Rights共享给 SRM2。由于 Rights绑定 SRM1 的用户， DRM Agent向 RI查询 SRM1和 SRM2是否属于同一用户。请求中包含 SRM1和 SRM2的标识， RI检查 SRM1和 SRM2关联的用户是否一致并在响应消息中返回结果。如果结果表明 SRM1和 SRM2属于同一用户，则执行 S706,否则 DRM Agent拒绝将 Rights共享给 SRM2。在 S904之前 DRM Agent 和 SRM Agent2之间需要互相认证和建立 SAC通道。

S706: DRM Agent将 Rights安装到 SRM2,具体步骤如图 1中 S107-S110。

S707: 如果 SRM2成功安装 Rights, 贝¹ J DRM Agent删除本地的 Rights。该实施例六中 DRM Agent先从 SRM1获取许可后再向 RI查询 SRM1和 SRM2是否属于同一用户。如果用户发起共享时已经确定目的 SRM, 可选的， DRM Agent也可以先向 RI查询 SRM1和 SRM2是否属于同一用户再从 SRM1 获取许可。此外， DRM Agent也可以在确认 SRM2上有足够的空间安装 Rights 后再删除 SRM1上的 Rights。

上述在属于相同用户的 SRM之间共享许可的两个实施例中， DRM Agent 均向 RI查询 SRM所属的用户，如果 RI无法获知 SRM所属的用户，可能需要向其它实体，如用户管理器，查询 SRM所属的用户，或者 DRM Agent可以直接向管理 SRM和用户关系的实体，如用户管理器，查询 SRM所属的用户。

另外，上述在属于相同用户的 SRM之间共享许可的两个实施例中，都是以 SRM1和 SRM2连接于同一个 DRM Agent为例进行说明的，某些情况下，可能两个 SRM位于不同的地方，无法直接连接到同一个 DRM Agent , 则可能需要多个 DRM Agent代为中转。例如，需对图 6改动的是， DRM Agent实际为两个 DRM Agent: DRM Agentl和 DRM Agent2, 分别连接 SRM1和 SRM2, 在具体流程上，可由 DRM Agentl查询 SRM1所属用户，并在将许可转移给 DRM Agent2时指明该 Rights只能共享给该用户的 SRM , DRM Agent2确定 SRM2同属于该用户后，才能将该 Rights安装到 SRM2; 或者 DRM Agentl确定 SRM1和 SRM2同属一个用户时，将许可共享给 DRM Agent2并指明共享给 SRM2, 再由 DRM Agent2安装到 SRM2; 或者 DRM Agent将许可共享给 DRM Agent2并指明共享给与 SRM1同一用户的 SRM, DRM Agent在确定 SRM1和 SRM2同属一个用户后，才能将该 Rights安装到 SRM2。需对图 7改动的是， DRM Agentl向 RI进行 SRM1和 SRM2所属用户查询，并且，在 RI 确定 SRM1和 SRM2同属一个用户时，由 DRM Agentl将许可共享给 DRM Agent2, 再由 DRM Agent2安装到 SRM2; 或者由 DRM Agentl将许可共享给 DRM Agent2,由 DRM Agent2向 RI进行 SRM1和 SRM2所属用户查询，并且，在 RI确定 SRM1和 SRM2同属一个用户时，再由 DRM Agent2安装到 SRM2。可见，在实施例五和实施例六中，由于是对同属一个用户的两个 SRM的许可的共享，无需消耗共享权限，进一步保证了用户权益。

综上，针对用户发起的在两个 SRM间共享许可，设备可先判断两个 SRM 是否属于同一用户：如果属于同一用户则直接共享，不检查共享权限，如实施例五和实施例六所示；如果不属于同一用户则检查共享权限并扣除一次，如实施例一和实施例二所示。

与上述各个方法实施例相对应，本发明实施例还提供各种装置。

本发明实施例提供的第一装置是指 DRM Agent或位于 DRM Agent内的功能实体，该装置执行图 1或图 2中 DRM Agent功能，参见图 8, 该装置包括：获取单元 801 , 用于从第一 SRM获取许可；中转设置单元 802, 用于将获取单元 801获取的许可设置为中转状态；发送单元 803 , 用于将获取单元 801获取的许可发送给第二 SRM; 控制单元 804, 扣除一次共享权限。优选地，该装置还包括：请求删除单元 805 , 用于请求所述第一 SRM删除所述许可；删除响应接收单元 806, 用于接收所述第一 SRM返回的删除许可响应。

另外，本发明实施例提供的第二装置是指 DRM Agent或位于 DRM Agent 内的功能实体，该装置执行图 3中 DRM Agent功能，参见图 9, 该装置包括： SRM交互单元 901 , 用于触发第一 SRM和第二 SRM进行密钥协商；转发单元 902, 用于将所述第一 SRM的许可转发给第二 SRM。

另外，本发明实施例提供的第三装置是指第一 SRM或位于第一 SRM中的功能实体，该装置实现图 3中 SRM1的功能，参见图 10, 该装置包括：密钥协商单元 1001 , 用于与第二 SRM进行密钥协商；处理单元 1002, 用于利用与第二 SRM协商的共享密钥对许可的部分或全部信息加密；发送单元 1003 , 用于将许可发送给第二 SRM。优选地，该装置还包括：删除单元 1004, 用于在确认所述第二 SRM接收到许可后，删除本地的所述许可。

另外，本发明实施例提供的第四装置是指第二 SRM或位于第一 SRM中的功能实体，该装置实现图 3中 SRM2的功能，参见图 11 , 该装置包括：密钥协商单元 1101 , 用于与第一 SRM进行密钥协商；接收单元 1102, 用于接收第一 SRM发送的许可；权限扣除单元 1103 , 用于在所述接收单元 1102接收到正确的许可后，扣除一次操作权限。

另夕卜，本发明实施例提供的第五装置是指 RI或用户管理器或位于 RI或用户管理器内的功能实体，该装置执行图 5中 RI功能，参见图 12,该装置包括：获取单元 1201 , 用于从第一数字版权管理终端 DRM Agent获取第一 SRM的许可；发送单元 1202, 用于向第二 DRM Agent发送所述许可，通过所述第二 DRM Agent提供给第二 SRM。

另外，本发明实施例提供的第六装置是指 DRM Agent或位于 DRM Agent 内的功能实体，该装置执行图 6或图 7中 DRM Agent功能，参见图 13该装置包括：确定单元 1301 , 确定所述第一 SRM和第二 SRM是否属于相同用户；获取单元 1302,用于在所述确定单元 1301确定第一 SRM和第二 SRM属于相同用户时，从所述第一 SRM获取许可；执行单元 1303 , 用于将获取单元 1302 获取的许可发送给第二 SRM。

另外需要说明的是，上述各个实施例仅是以在两个 SRM之间共享许可为例进行说明的，本领域人员可毫无疑问地获知，本发明实施例可以实现在三个或三个以上 SRM之间共享许可。本发明实施例也可应用于通过 DRM Agent 将 SRM上的许可共享到另一 DRM Agent。本领域普通技术人员可以理解，实现上述实施例的方法的过程可以通过程序指令相关的硬件来完成，所述的程序可以存储于可读取存储介质中，该程序在执行时执行上述方法中的对应步骤。所述的存储介质可以如： ROM/RAM、磁碟、光盘等。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims

权利要求

1、一种在安全可移动媒介 SRM之间共享许可的方法，其特征在于，包括：数字版权管理终端 DRM Agent从第一 SRM获取许可，并将所述许可在本地设置为中转状态；

所述 DRM Agent将所述许可的共享权限扣除一次；

所述 DRM Agent将所述许可发送给第二 SRM。

2、根据权利要求 1所述方法，其特征在于，所述共享许可是指复制许可，所述共享权限是指复制权限；或者，所述共享许可是指转移许可，所述共享权限是指转移权限；

当所述共享许可是指转移许可时，还包括：所述 DRM Agent触发所述第一 SRM删除所述许可；

当所述共享许可是指复制许可时，所述 DRM Agent将所述许可的共享权限扣除一次具体包括：

所述 DRM终端将第一 SRM上的所述许可的复制权限扣除一次，所述 DRM Agent将所述许可发送给第二 SRM时许可不包含复制权限；

或者，

所述 DRM Agent将发送给第二 SRM的所述许可的复制权限扣除一次，并将第一 SRM上的所述许可复制权限全部扣除。

3、根据权利要求 1 所述方法，其特征在于，还包括：所述 DRM Agent 在中转操作过程中记录日志；所述日志包含操作类型、当前状态、许可标识、第一 SRM标识、许可在第一 SRM上对应的第一句柄、第二 SRM标识、许可在第二 SRM上对应的第二句柄中的部分或全部；

当共享许可操作发生中断时，还包括：

所述 DRM Agent根据所述日志将许可继续发送到第二 SRM;

或者，

所述 DRM Agent根据所述日志将许可恢复到第一 SRM。

4、根据权利要求 1 所述方法，其特征在于，所述 DRM Agent将所述许可发送给第二 SRM具体包括：

所述 DRM Agent将所述许可通过其它 DRM Agent中转给第二 SRM。

5、一种共享许可的方法，其特征在于，包括：

数字版权管理终端 DRM Agent触发第一 SRM和第二 SRM协商共享密钥；所述第一 SRM使用所述共享密钥加密所述许可的部分或全部信息；所述第一 SRM将所述许可发送给第二 SRM。

6、根据权利要求 5所述方法，其特征在于，在所述第一 SRM将所述许可发送给第二 SRM之前，还包括：

所述第一 SRM使用所述共享密钥对许可的部分或全部信息进行完整性保护。

7、根据权利要求 5所述方法，其特征在于，在所述第一 SRM将所述许可发送给第二 SRM之后，还包括：

所述第二 SRM验证所述许可，并在通过后扣除一次共享权限。

8、根据权利要求 5所述方法，其特征在于，在所述第一 SRM将所述许可发送给第二 SRM之前，还包括：

所述第一 SRM将许可的共享权限扣除一次。

9、根据权利要求 5所述方法，其特征在于，所述第一 SRM将所述许可发送给第二 SRM具体包括：

所述第一 SRM通过所述 DRM Agent将所述许可发送给第二 SRM;

所述 DRM Agent在中转过程中验证许可并扣除一次共享权限。

10、根据权利要求 5所述方法，其特征在于，所述 DRM Agent触发第一 SRM和第二 SRM协商共享密钥的过程包括：

所述 DRM Agent向第一 SRM发起认证过程，获取第一 SRM证书链；所述 DRM Agent向第二 SRM发起认证过程，将所获取的第一 SRM证书链发送给第二 SRM , 并从第二 SRM获取第二 SRM证书链和第一 SRM公钥加密的第二随机数；

所述 DRM Agent向第一 SRM发起密钥交换过程，将所获取的第二 SRM 证书链和第一 SRM公钥加密的第二随机数发送给第一 SRM , 并从第一 SRM 获取第二 SRM公钥加密的第一随机数；

所述 DRM Agent向第二 SRM发起密钥交换过程，将所获取的第二 SRM 公钥加密的第一随机数发送给第二 SRM；第一 SRM和第二 SRM利用所述第一随机数和第二随机数，确定共享密钥。

11、一种共享许可的方法，其特征在于，包括：

第一数字版权管理终端 DRM Agent从第一 SRM获取许可后，发送给版权发行者 RI;

第二 DRM Agent从 RI获取所述许可，并发送给第二 SRM。

12、根据权利要求 11所述方法，其特征在于，所述第二 DRM Agent从 RI获取所述许可前，还包括：

RI根据从第一 SRM获取的许可生成绑定第二 SRM的许可。

13、根据权利要求 11所述方法，其特征在于，所述第二 DRM Agent从

RI获取所述许可前，还包括：

RI验证第一 SRM和第二 SRM属于相同用户。

14、一种共享许可的方法，其特征在于，包括：

数字版权管理终端 DRM Agent确定第一 SRM和第二 SRM属于相同用户时，将从第一 SRM获取的许可发送给第二 SRM。

15、根据权利要求 14所述方法，其特征在于，所述 DRM Agent确定所述第一 SRM和第二 SRM属于相同用户的过程为：

所述 DRM Agent向所述 RI或用户管理器发送包含第一 SRM标识的查询消息，查询所述第一 SRM所属用户；

所述 DRM Agent向所述 RI或用户管理器发送包含第二 SRM标识的查询消息，查询所述第二 SRM所属用户；

所述 DRM Agent验证所述第一 SRM和第二 SRM是否属于相同用户；或者，

所述 DRM Agent向所述 RI或用户管理器发送包含第一 SRM标识和第二 SRM标识的查询消息，查询所述第一 SRM和所述第二 SRM是否属于相同用户；

所述 RI或用户管理器向所述 DRM Agent返回查询响应，告知所述第一 SRM和第二 SRM是否属于相同用户。

16、一种共享许可的装置，其特征在于，包括：获取单元，用于从第一 SRM获取许可；

中转设置单元，用于将所述获取的许可设置为中转状态；

发送单元，用于将所获取的许可发送给第二 SRM;

控制单元，扣除一次共享权限。

17、根据权利要求 16所述装置，其特征在于，还包括：

请求删除单元，用于请求所述第一 SRM删除所述许可；

删除响应接收单元，用于接收所述第一 SRM返回的删除许可响应。

18、一种共享许可的装置，其特征在于，包括：

SRM交互单元，用于触发第一 SRM和第二 SRM进行密钥协商；转发单元，用于将所述第一 SRM的许可转发给第二 SRM。

19、一种在第一安全可移动媒介 SRM和第二 SRM之间共享许可的装置，位于第一 SRM中，其特征在于，包括：

密钥协商单元，用于与第二 SRM进行密钥协商；

处理单元，用于利用与第二 SRM协商的共享密钥对许可的部分或全部信息加密；

发送单元，用于将许可发送给第二 SRM。

20、根据权利要求 19所述装置，其特征在于，还包括：

删除单元，用于在确认所述第二 SRM接收到许可后，删除本地的所述许可。

21、一种共享许可的装置，位于第二 SRM中，其特征在于，包括：密钥协商单元，用于与第一 SRM进行密钥协商；

接收单元，用于接收第一 SRM发送的许可；

权限扣除单元，用于在所述接收单元接收到正确的许可后，扣除一次操作权限。

22、一种共享许可的装置，其特征在于，包括：

获取单元，用于从第一数字版权管理终端 DRM Agent获取第一 SRM的许可；

发送单元，用于向第二 DRM Agent发送所述许可，通过所述第二 DRM Agent提供给第二 SRM。

23、一种共享许可的装置，其特征在于，包括：

确定单元，确定第一 SRM和第二 SRM是否属于相同用户；

获取单元，用于在所述确定单元确定第一 SRM和第二 SRM属于相同用户时，从所述第一 SRM获取许可；

执行单元，用于将所述许可发送给所述第二 SRM。