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

Abstract

本发明公开了一种在SRM之间共享许可的方法及装置，其中的方法包括：DRM Agent从第一SRM获取许可，并将所述许可在本地设置为中转状态，指定转移给第二SRM，不可用所述许可消费内容；所述DRM Agent将所述许可的共享权限扣除一次；所述DRM Agent将所述许可发送给第二SRM。与现有方案在许可从SRM1转移到设备过程中需要扣除一次Move权限、在许可从设备转移到SRM2过程中需要扣除另一次Move权限相比，本发明实施例通过将DRM Agent中转的许可设置为中转状态，由此仅扣除一次共享权限，减少了共享权限的不必要的消耗，有利于维护用户权益。

Description

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

（本申请是针对2008年7月29日提交的，申请号为200810134766.3，发明名称为“在安全可移动媒介之间共享许可的方法及装置”的专利申请，所提交的分案申请）

技术领域

本发明涉及数字版权管理（DigitalRightsManagement，DRM）技术领域，尤其涉及一种在安全可移动媒介（SecureRemovableMedia，SRM）之间共享许可的方法及装置。

背景技术

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

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

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

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

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

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

发明内容

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

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

一种在SRM之间共享许可的方法，包括：数字版权管理终端DRMAgent从第一SRM获取许可，并将所述许可在本地设置为中转状态，指定转移给第二SRM，不可用所述许可消费内容；

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

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

一种共享许可的装置，包括：

获取单元，用于从第一安全可移动媒介SRM获取许可；

中转设置单元，用于将所述获取的许可设置为中转状态，指定转移给第二SRM，不可用所述许可消费内容；

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

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

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

附图说明

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

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

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

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

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

图6为本发明在属于相同用户的SRM之间共享许可方法实施例五流程图；

图7为本发明在属于相同用户的SRM之间共享许可方法实施例六流程图。

具体实施方式

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

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

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

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

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

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

[3]所述DRMAgent将所述许可发送给第二SRM。

其中，所述共享许可是指复制许可，所述共享权限是指复制权限；或者，所述共享许可是指转移许可，所述共享权限是指转移权限。

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

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

下面首先介绍实施例一。

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

S101：DRMAgent和SRMAgent1相互认证并建立安全认证通道（SecureAuthenticatedChannel，SAC），认证过程中DRMAgent和SRMAgent1互相交换证书并验证对方证书的有效性，交换随机数并根据随机数生成通信密钥，包括加密密钥和完整性保护密钥。

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

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

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

S105-106：DRMAgent指示SRMAgent1删除该Rights，具体步骤为现有技术。

S107-S108：DRMAgent查询SRM2是否有足够的空间安装该Rights，具体为现有技术。

在S107之前DRMAgent和SRMAgent2互相认证并建立SAC通道。图1中以S107a表示。如果DRMAgent可同时和两个SRMAgent交互，则S107a在S107之前任意时刻执行即可。

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

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

S111：如果SRM2成功安装Rights，则DRMAgent删除本地的Rights。

可选地，在S104中不扣除Move权限，而在将Rights安装到SRM2时再在设备上执行扣除Move权限的操作。

另外，在S106之后，设备可以保留该中转Rights的源SRM即SRM1的记录，这样如果在Rights安装到SRM2的过程中发生意外而导致失败，例如SRM2没有足够的空间安装该Rights，可以将Rights重新恢复到SRM1上，从而保证用户的权益不受损害。

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

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

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

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

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

S201：DRMAgent分别和SRMAgent1、SRMAgent2互相认证并建立SAC通道，DRMAgent和SRMAgent2的认证可以在S205之前任何时候进行。

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

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

S205-S206：DRMAgent查询SRM2是否有足够的空间安装该Rights。

S207-S208：DRMAgent向SRMAgent2发送Rights安装请求消息，消息中包含handle、REK、内容标识的hash的列表、Rights信息，SRM2安装Rights并返回响应。如果SRM2成功安装Rights，则DRMAgent删除本地的Rights。

S209-S210：如果SRM2成功安装Rights，则DRMAgent指示SRMAgent1删除该Rights。

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

如果在将Rights安装到SRM2的过程中发生错误，例如SRM2空间不够，则DRMAgent可以取消Move操作，恢复SRM1上的原Rights。如果DRMAgent和某一SRM连接中断，则DRMAgent可记录中断日志，中断日志具体包括：操作类型、当前状态、许可标识、SRM1标识、许可在SRM1上对应的handle1、SRM2标识、许可在SRM2上对应的handle2。下次连接时根据中断日志中的信息进行恢复：继续将许可发送到SRM2，完成操作；或者取消操作，将许可恢复到SRM1。

为了从一定程度上提高REK的安全性，可以由DRMAgent将SRM2的公钥或证书提供给SRMAgent1，SRMAgent1使用SRM2的公钥对REK进行加密后通过DRMAgent传输给SRM2。

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

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

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

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

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

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

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

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

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

S301：DRMAgent分别和SRMAgent1和SRMAgent2交换各自支持的信任锚（Trustanchor）。

S302：DRMAgent触发SRMAgent1和SRMAgent2认证。消息中包含选择的Trustanchor，DRMAgent可根据待转移的Rights来选择。可选的，触发消息中还可包含SRM2标识。本步骤可由用户选择在两个SRM之间转移Rights的操作触发。

S303：SRMAgent1向SRMAgent2发送认证请求。请求中包含Trustanchor、SRM1证书链、SRMAgent1支持的算法等。如果SRMAgent1和SRMAgent2之间可以直接通信，则消息可不经过DRMAgent，否则所有的消息都需要DRMAgent代为中转。

S304：SRMAgent2向SRMAgent1返回认证响应。响应中包含SRMAgent2证书链、SRM2选择的算法、用于生成密钥的随机数RN1，其中RN1需要使用SRM2的公钥加密传输。

S305：SRMAgent1向SRMAgent2发送密钥交换请求。请求中包含用于生成密钥的随机数RN2，其中RN2需要使用SRM1的公钥加密传输。

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

S307：DRMAgent触发SRMAgent1向SRM2转移Rights，消息中可包含该Rights在SRM1上对应的Handle或者许可标识。

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

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

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

S311：SRMAgent2验证Rights信息，验证通过后扣减Move权限，并将Rights存放在SRM2中。

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

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

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

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

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

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

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

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

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

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

S401：DRMAgent分别和SRMAgent1和SRMAgent2交换各自支持的Trustanchor。

S402：DRMAgent向SRMAgent1发起认证请求。消息中包含选择的Trustanchor，对应该Trustanchor的设备证书链等。DRMAgent可根据待转移的Rights来选择Trustanchor。

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

S404：DRMAgent向SRMAgent2发起三方认证请求。消息中包含选择的Trustanchor，对应该Trustanchor的设备证书链和SRM1证书链等。

S405：SRMAgent2返回三方认证响应。响应消息中包含SRM2证书链，使用设备公钥加密的随机数RNs2d和使用SRM1公钥加密的随机数RNs2s1。

S406：DRMAgent向SRMAgent1发送三方密钥交换请求。消息中包含SRM2证书链，使用SRM1公钥加密的随机数RNs2s1，使用SRM1公钥加密的随机数RNds1（可以和RNs1d的哈希连接后再使用SRM1公钥加密）。

S407：SRMAgent1返回三方密钥交换响应。响应消息中包含使用SRM2公钥加密的随机数RNs1s2（可以和RNs2s1的哈希连接后再使用SRM2公钥加密），可能包含RNds1和RNs1d的连接值的哈希。

S408：DRMAgent向SRMAgent2发起三方密钥交换请求。消息中包含使用SRM2公钥加密的随机数RNs1s2（可以和RNs2s1的哈希连接后再使用SRM2公钥加密），使用SRM2公钥加密的随机数RNds2（可以和RNs2d的哈希连接后再使用SRM2公钥加密）。

S409：SRMAgent2返回三方密钥交换响应。响应消息中可能包含RNs1s2和RNs2s1的连接值的哈希以及RNds2和RNs2d的连接值的哈希。

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

DRMAgent向SRMAgent1和SRMAgent2提供的随机数可以一样，这样三方可以使用此公共随机数生成三方公共密钥。

或者，DRMAgent可以将SRMAgent1提供的RNs1d作为RNds2提供给SRMAgent2，将SRMAgent2提供的RNs2d作为RNds1提供给SRMAgent1，也可生成三方共享密钥。

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

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

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

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

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

[1]在第一DRMAgent从第一SRM获取许可后，发送给RI；

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

具体流程如图5所示：

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

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

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

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

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

·从SRMAgent1获取的Rights信息中的RightsObjectContainer部分（即原RI下发的许可中的<rights>和<signature>）或对其格式转换后的结果，如果RI在ROAPtrigger{SRMROUpload}中标记roRequested为false，则该参数可省略；

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

·RI公钥加密的REK和Kmac；

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

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

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

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

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

·解密得到REK和Kmac，使用Kmac验证请求消息中的MAC值；

·验证SRM1证书链的有效性，可能需要通过OCSP或CRL实现，并使用SRM1证书链验证SRM1签名信息的有效性；

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

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

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

S507：DRMAgent1向SRMAgent1发送RightsRemovalRequest消息，消息中包含标识Rights的handle，此handle即S502中的新handle。

S508:SRMAgent1删除RightsRemovalRequest消息中的handle对应的Rights，并向DRMAgent1返回RightsRemovalResponse消息，其中包含处理结果。

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

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

S511：RI向DRMAgent2返回许可响应，响应消息中包含设备2标识、RI标识、nonce、受保护的许可、RI证书链（如果DRMAgent2在请求消息中标识其已经保存了RI证书链，则此参数不需要）。许可可以绑定SRM2，也可以绑定DRMAgent2，但指定必须提供给SRM2。

S512：DRMAgent2将RI下发的许可写入SRM2。如果许可绑定SRM2，则DRMAgent2可先将加密的REK和Kmac的连接值发送给SRMAgent2，由SRMAgent2提供Kmac，并用其验证许可的完整性，再由DRMAgent2将rights和signature等写入SRM2。如果许可绑定DRMAgent2，则由DRMAgent2解密出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的替代方案，可以由DRMAgent向RI查询SRM1和SRM2是否属于同一用户，并直接进行Rights的共享，无需RI重新生成许可。

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

[1]DRMAgent确定第一SRM和第二SRM属于相同用户时，将从第一SRM获取的许可发送给第二SRM；

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

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

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

概括而言，实施例五中查询第一SRM和第二SRM所属用户的过程为：

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

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

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

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

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

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

S604：DRMAgent检查Rights信息中的RI签名以及状态信息是否超出Rights中的原始权限并在验证通过后安装该Rights，DRMAgent在安装该Rights时标识该Rights不可用，并指定关联到S603中RI返回的用户标识。

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

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

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

S609：DRMAgent将Rights安装到SRM2，具体步骤如图1中S107-S110。

S610：如果SRM2成功安装Rights，则DRMAgent删除本地的Rights。

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

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

概括而言，实施例六中查询第一SRM和第二SRM所属用户的过程为：

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

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

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

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

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

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

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

S706：DRMAgent将Rights安装到SRM2，具体步骤如图1中S107-S110。

S707：如果SRM2成功安装Rights，则DRMAgent删除本地的Rights。

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

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

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

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

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

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

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

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

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

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

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

需要说明的是，上述各个实施例仅是以在两个SRM之间共享许可为例进行说明的，本领域人员可毫无疑问地获知，本发明实施例可以实现在三个或三个以上SRM之间共享许可。本发明实施例也可应用于通过DRMAgent将SRM上的许可共享到另一DRMAgent。

本领域普通技术人员可以理解，实现上述实施例的方法的过程可以通过程序指令相关的硬件来完成，所述的程序可以存储于可读取存储介质中，该程序在执行时执行上述方法中的对应步骤。所述的存储介质可以如：ROM/RAM、磁碟、光盘等。

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

Claims (8)

1.一种在安全可移动媒介SRM之间共享许可的方法，其特征在于，包括：

数字版权管理终端DRMAgent发起将第一SRM上的许可直接转移到第二SRM，从第一SRM获取许可，并将所述许可在本地设置为中转状态，指定转移给第二SRM，不可用所述许可消费内容；

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

所述DRMAgent将所述许可发送给第二SRM；

其中，所述DRMAgent将所述许可发送给第二SRM具体包括：所述DRMAgent向所述第二SRM发送许可安装请求消息，所述许可安装请求消息中包括句柄handle、REK、内容标识的hash的列表和许可信息，以便所述第二SRM安装许可并返回响应。

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

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

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

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

或者，

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

3.根据权利要求1所述方法，其特征在于，所述DRMAgent将所述许可发送给第二SRM后，还包括：

所述DRMAgent删除本地的所述许可。

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

5.根据权利要求1所述方法，其特征在于，所述DRMAgent从第一SRM获取许可前，还包括：

所述DRMAgent将所述第二SRM的公钥或证书提供给第一SRM，第一SRM使用第二SRM的公钥加密许可中的权限加密密钥或内容加密密钥。

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

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

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

获取单元，用于发起将第一SRM上的许可直接转移到第二SRM，从第一安全可移动媒介SRM获取许可；

中转设置单元，用于将所述获取的许可设置为中转状态，指定转移给第二SRM，不可用所述许可消费内容；

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

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

其中，所述发送单元具体用于：所述第二SRM发送许可安装请求消息，所述许可安装请求消息中包括句柄handle、REK、内容标识的hash的列表和许可信息，以便所述第二SRM安装许可并返回响应。

8.根据权利要求7所述装置，其特征在于，还包括：

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

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