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

专利名称：在安全可移动媒介之间共享许可的方法及装置的制作方法
技术领域：
本发明涉及数字版权管理(Digital Rights Management, DRM)技术领域， 尤其涉及一种在安全可移动i某介(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的方案，不论在哪种转移方案中，每次转移 都需要扣除共享权限，那么，如果要实现将许可从SRMl转移到SRM2，至 少需要经过将许可首先从SRMl转移到DRM Agent,然后再由DRM Agent 转移给SRM2，也就是说至少需要扣除两次共享权限。本发明人在发明的过程 中发现，现有技术中对许可的转移需要多次权限，对用户而言造成不必要的 权限浪费

发明内容
本发明提供一种在SRM之间共享许可的方法及装置，以解决现有方案存 在的过多消耗共享权限的问题。
为此，本发明实施例采用如下技术方案
一种在SRM之间共享许可的方法，包括DRM Agent从第一 SRM获取 许可，并将所述许可在本地设置为中转状态；所述DRM Agent将所述许可的 共享权限扣除一次；所述DRM Agent将所述许可发送给第二 SRM。
一种共享许可的方法，包括DRMAgent触发第一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的许可；发送单元，用于向第二DRMAgent发送所述许可，通过第 二 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之间 许可的共享。
9在本发明另外实施例中，在属于相同用户的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之间共享许可方法实施例六流程图。
具体实施例方式
本发明实施例提供一种在SRM之间共享许可的方案，通过DRM Agent 或RI等设备将SRM1中的许可共享给SRM2，仅消耗一次共享权限。
上述所谓的共享许可，包括转移许可和复制许可等情况，下面着重以转 移许可为例对方法实施例进行说明。
下面介绍在SRM之间共享许可方法的各个实施例。 概括而言，实施例一和实施例二方法包括以下步骤 [1] DRM Agent从第一 SRM获取许可，并将所述许可在本地设置为中转 状态；所述DRM Agent将所述许可的共享4又限扣除一次；[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: DRMAgent发起将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指示SRMAgentl删除该Rights,具体步骤为现有 技术。
S107-S108: DRMAgent查询SRM2是否有足够的空间安装该Rights,具 体为现有技术。
在S107之前DRM Agent和SRM Agent2互相认证并建立SAC通道。图 1中以S107a表示。如果DRM Agent可同时和两个SRM Agent交互，则SI07a 在S107之前任意时刻执行即可。
如果DRM Agent不能同时和两个SRM Agent交互，则在S107之前可先 和SRM1断开连接，再和SRM2连接执行后续步骤。执行后续步骤的过程可 由用户操作设备触发，具体的可以将Rights在设备处存储为特殊格式的文件， 用户浏览确定该Rights处于中转状态，选择将该文件转移到另一 SRM完成中 转，或者设备将Rights信息提示给用户，用户选择是否继续转移。或者设备 可根据Rights关联的目的设备的标识自动执行，例如在连接到SRM2时搜索 本地处于中转状态且关联的目的设备为SRM2的Rights,并自动执行S107后 续步骤。
S109-S110: DRM Agent向SRM Agent2发送Rights安装请求消息，消息 中包含handle、 REK、内容标识的hash的列表、Rights信息，SRM2安装Rights 并返回响应，即不必进行第二次Move权限的扣除，因此减少了扣除Move权 限的次数。
Sill:如果SRM2成功安装Rights,则DRM Agent删除本地的Rights。
可选地，在S104中不扣除Move权限，而在将Rights安装到SRM2时再 在设备上执行扣除Move权限的操作。
另外，在S106之后，设备可以保留该中转Rights的源SRM即SRM1的 记录，这样如果在Rights安装到SRM2的过程中发生意外而导致失败，例如 SRM2没有足够的空间安装该Rights,可以将Rights重新恢复到SRM1上， 从而保证用户的权益不受损害。
实施例一是以转移(Move)许可为例对共享许可进行说明，如前所述，
12共享还包括复制(Copy ),将SRM1中的许可复制到SRM2的过程与图1类似， 不同在于，在复制过程中消耗的是Copy权限DRM Agent将SRMl上的所 述许可的Copy权限扣除一次，DRM Agent发送给SRM2的许可不包含Copy 权限；或者DRM Agent将发送给SRM2的许可的Copy权限扣除一次，并将 SRMl上的许可的Copy权限全部扣除。SRMl无需删除该许可。
可见，与现有方案在许可从SRMl转移到设备过程中需要扣除一次共享 权限、在许可从设备转移到SRM2过程中需要扣除另一次共享权限相比，本 发明实施例通过将DRM Agent中转的Rights设置为中转状态，由此仅扣除一 次Move权限，减少了 Move权限的消耗，有利于维护用户权益。
下面介绍在SRM之间共享许可方法的实施例二。
在上述实施例一中图1的S107-S108中，如果Rights安装到SRM2的过 程失败，将Rights重新恢复到SRMl则较为复杂，较佳的方案是在确认SRM2 有足够的空间安装Rights后，再删除SRMl上的Rights。
参见图2,实施例二流程包括
S201: DRM Agent分别和SRM Agentl 、 SRM Agent2互相认证并建立SAC 通道，DRM Agent和SRM Agent2的认证可以在S205之前任何时候进行。
S202-S203: DRM Agent发起将SRMl上的Rights直接转移到SRM2,该 操作可由用户通过和DRM Agent的交互触发，DRM Agent从SRMl获取Rights 信息和REK。
S204: DRM Agent -验证Rights信息以及Move权限，并在验i正通过后扣 除Move ^又限。扣除Move权限的梯:作可以在S406之后再执4亍。
S205-S206: DRM Agent查询SRM2是否有足够的空间安装该Rights。
S207-S208: DRM Agent向SRM Agent2发送Rights安装请求消息，消息 中包含handle、 REK、内容标识的hash的列表、Rights信息，SRM2安装Rights 并返回响应。如果SRM2成功安装Rights,则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上对应的handlel、 SRM2标识、许可在SRM2上对应的handle2。下次连接时根据中断日志中的 信息进行恢复继续将许可发送到SRM2,完成操作；或者取消操作，将许可 恢复到SRM1。
为了从一定程度上提高REK的安全性，可以由DRM Agent将SRM2的 公钥或证书提供给SRMAgentl ， SRMAgentl使用SRM2的公钥对REK进行 加密后通过DRM Agent传输给SRM2。
可见，实施例二与实施例 一相比，在SRM2确定可以安装Rights后，才 将SRM1中的Rights删除，这在SRM2无法安装Rights的情况下，DRM Agent 恢复SRMl上的原Rights操作比较简单，仅需将Rights恢复为可用状态。
下面介绍在SRM之间共享许可方法的实施例三。
在实施例三中，通过DRM Agent协助，在SRMl和SRM2之间建立SAC, 并使用SAC密钥共享许可。下面仍以转移许可为例介绍实施例三，对于复制 许可，与其类似。
概括而言，实施例三包括以下步骤 DRM Agent触发第一 SRM和第二 SRM协商共享密钥；第一 SRM使用协商的共享密钥加密许可的部分或全部信息；第一 SRM将许可发送给第二 SRM。
下面结合附图对实施例三详细流程进行介绍。
参见图3，为实施例三流程图，包括
S301: DRM Agent分别和SRMAgentl和SRMAgent2交换各自支持的信任锚(Trust anchor )。
S302: DRM Agent触发SRM Agentl和SRM Agent2认证。消息中包含选 择的Trust anchor, DRM Agent可根据待转移的Rights来选择。可选的，触发 消息中还可包含SRM2标识。本步骤可由用户选择在两个SRM之间转移 Rights的纟喿作触发。
S303: SRM Agentl向SRM Agent2发送认证请求。请求中包含Trust anchor、 SRMl证书链、SRMAgentl支持的算法等。如果SRMAgentl和SRM Agent2之间可以直接通信，则消息可不经过DRM Agent,否则所有的消息都 需要DRM Agent代为中转。
S304: SRM Agent2向SRM Agentl返回认证响应。响应中包含SRM Agent2 证书链、SRM2选择的算法、用于生成密钥的随机数RNl,其中RN1需要使 用SRM2的公钥加密传输。
S305: SRM Agentl向SRM Agent2发送密钥交换请求。请求中包含用于 生成密钥的随机数RN2，其中RN2需要使用SRM1的公钥加密传输。
S306: SRM Agent2向SRM Agentl返回密钥交换响应。响应中可能包含 RN1和RN2的连接值的Hash用于确i人随机凄t。至此，SRM1和SRM2均获 得RN1和RN2，分别4吏用RN1和RN2生成会话密钥和MAC密钥。
S307: DRM Agent触发SRM Agentl向SRM2转移Rights,消息中可包 含该Rights在SRMl上对应的Handle或者许可标识。
S308: SRM Agentl向SRM Agent2发送初始化转移请求，请求中包含 Rights的大小，可能包含该Rights在SRM2上对应的Handle。
S309: SRM Agent2检查本地是否有足够的空间安装该Rights,如果S508 中SRM Agentl发送了 Handle,贝'J SRM Agent2需要^r查该Handle和SRM2 上已有的Handle是否重复。并在向SRM Agentl返回的初始化转移响应中包 含^r查结果。如果S308中SRM Agentl没有发送Handle,则SRM Agent2可 自动生成一个和本地其他Handle不同的Handle,并可在响应中返回。
S310: SRM Agentl向SRM Agent2发送转移请求，请求中包含Rights信
15息、REK、 Rights关联的内容标识等，如果SRM Agentl获知Rights在SRM2 上关联的Handle,则可在请求消息中包含该Handle。
S311: SRMAgent2验证Rights信息，验证通过后扣减Move权限，并将 Rights存放在SRM2中。
可选的，也可由SRM Agentl在步骤S310之前检查Move权限并扣减， 这样，在步骤S311中SRMAgent2无需扣减Move权限
与实施例一或实施例二相比，实施例三中是通过SRM1和SRM2之间建 立SAC,由该SAC将许可进行转移，其中的DRM Agent仅是执行转发功能， 由于转发的Rights是经过SRMl和SRM2协商的密钥加密的，DRM Agent无 法对其执行操作，这在一定程度上提高了 Rights安全性。
但是如果SRMl和SRM2由于能力问题无法-验证Rights,则可由DRM Agent代为验证，并扣减Move权限，可在S310中执行，这需要SRM Agentl 或SRM Agent2将MAC密钥告知DRM Agent。
图3中S301-S306完成的在两个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利用所述第一随机数和第二随机数，确定共享 密钥。
该过程可以和DRM Agent和两个SRM协商共享密钥的过程一起完成， 下面结合图4，对其进一步描述S401: DRM Agent分别和SRM Agentl和SRM Agent2交换各自支持的 Trust anchor。
S402: DRM Agent向SRM Agentl发起认证请求。消息中包含选择的Trust anchor,对应该Trust anchor的i殳备i正书链等。DRM Agent可才艮据4寺转移的 Rights来选捧Trust anchor。
S403: SRM Agentl返回认证响应。响应消息中包含SRMl证书链，使用 设备/>钥加密的随机数RNsld。
S404: DRM Agent向SRM Agent2发起三方i人i正请求。消息中包含选择 的Trust anchor,对应该Trust anchor的设备证书链和SRMl i正书链等。
S405: SRM Agent2返回三方认证响应。响应消息中包含SRM2证书链， 使用设备公钥加密的随机数RNs2d和使用SRMl公钥加密的随机数RNs2sl。
S406: DRM Agent向SRM Agentl发送三方密钥交换请求。消息中包含 SRM2证书链，使用SRMl公钥加密的随机数RNs2sl，使用SRMl公钥加密 的随机数RNdsl (可以和RNsld的哈希连接后再使用SRMl公钥加密)。
S407: SRM Agentl返回三方密钥交换响应。响应消息中包含使用SRM2 公钥加密的随机数RNsls2 (可以和RNs2sl的哈希连接后再使用SRM2公钥 加密)，可能包含RNdsl和RNsld的连接值的哈希。
S408: DRM Agent向SRM Agent2发起三方密钥交换请求。消息中包含 使用SRM2公钥加密的随机数RNsls2 (可以和RNs2sl的哈希连接后再使用 SRM2公钥加密)，使用SRM2公钥加密的随机数RNds2 (可以和RNs2d的哈 希连接后再使用SRM2公钥加密)。
S409: SRMAgent2返回三方密钥交换响应。响应消息中可能包含RNsls2 和RNs2sl的连接值的哈希以及RNds2和RNs2d的连接值的哈希。
至此，DRM Agent和SRM Agentl 、 SRM Agent2两两之间共享了 一对随 机数，可各自独立用其生成密钥。这样，SRM1向SRM2转移Rights时，重 要信息如REK可以使用与SRM2之间的共享密钥加密，而其他信息可以使用 和DRM Agent间的共享密钥加密或进行完整性保护以方便DRM Agent处理。
17DRM Agent向SRM Agentl和SRM Agent2提供的随机数可以一样，这样 三方可以使用此公共随机数生成三方公共密钥。
或者，DRM Agent可以将SRM Agentl提供的RNsld作为RNds2提供给 SRM Agent2,将SRM Agent2提供的RNs2d作为RNds 1提供给SRM Agentl,
也可生成三方共享密钥。
目前SRM Agent和DRM Agent使用随机数生成密钥时是按照RNd和RNs 的顺序连接，但在本方案中为了保证密钥的一致性，可以默认对于每对随机 数按照传输的顺序连接，即SRM Agentl使用RNsld和RNdsl的顺序连接， 而SRM Agent2则使用RNds2和RNs2d的顺序连接。在不影响密钥的 一致性 的情况下，也可^f吏用其它方式生成密钥。
通过DRM Agent将Rights从SRMl转移到SRM2的过程中，为了安全起 见，SRMl可在获得SRM2收到Rights的确认后才删除Rights。具体的，SRM2 的确认可以是使用私钥对安装信息(如REK)的签名，或者使用仅由SRMl 和SRM2共享的密钥对安装信息(如REK)进行加密的结果；或者由SRMl 向SRM2提供确认信息(如随机数)，该确认信息可以使用SRM2的公钥或者 SRMl和SRM2共享的密钥加密传输，SRM2向SRMl表示获知该确认信息， 例如使用私钥对其签名或对该确认信息进行某种转换(如哈希或简单的加一 操作)后使用SRMl和SRM2共享的密钥加密返回。
下面介绍在SRM之间共享许可方法的实施例四。
以上方案中通过DRM Agent在两个SRM之间转移Rights,某些情况下可 能两个SRM位于不同的地方，无法直接连接到同一个DRM Agent,则可能需 要经过多个DRM Agent代为中转。例如，可由DRM Agentl从SRMl获取 Rights,转移到DRM Agent2并指明给SRM2， DRM Agent2将该Rights转移 到SRM2。
此外，也可以通过RI在两个SRM之间转移Rights,概括而言，包括以 下步骤在第一 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,否则为true。触发器中可选的 包含SRM1标识和许可标识。本步骤是可选的，用户可以通过人机界面操作 设备upload SRM1上的许可，直接从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下发的许可中的々ights〉和〈signature〉)或对其才各式转换后的结果， 如果RI在ROAP trigger {SRMROUpload}中标记roRequested为false,则该参 数可省略；
如果该许可为有状态的，则包括从SRM Agentl获取的Rights信息 中的状态信息； RI公钥加密的REK和Kmac;
SRM1标识、SRM1证书链、SRMRightsUpload响应消息中的时间戳、SRM Agentl对{指明upload的标志、REK、 RI标识、时间戳}的签名；
以及使用Kmac对上述参数进行MAC操作的结果。
DRMAgentl需对请求消息中的参数进行签名，并将签名在请求消息中一起发送给RI。
S506: RI对请求消息中的各参数进行验证
如果请求消息中有DRMAgentl证书链，则验证其有效性(可能需要
通过OCSP或CRL实现)，并使用请求消息中的设备1证书链或RI本地的设备上下文中的设备1证书链验证请求消息中DRMAgentl的签名；
解密得到REK和Kmac,使用Kmac验证请求消息中的MAC值；
验证SRM1证书链的有效性，可能需要通过OCSP或CRL实现，并使用SRM1证书链验证SRM1签名信息的有效性；
验证请求消息中的时间戳早于当前时间，验证SRMRightsUpload响应消息中的时间戳早于请求消息中的时间戳；
验i正〈rights〉和〈signature〉的正确性(如果请求消息中有的话)，如果许可为有状态的，还需验证状态信息在原始许可范围内；
尝试使用REK解密々ights〉元素中的加密的CEK验证REK和Rights的正确性。
S507: DRMAgentl向SRM Agentl发送RightsRemovalRequest消息，消息中包含标识Rights的handle,此handle即S502中的新handle。
S508:SRM Agentl删除RightsRemovalR叫uest消息中的handle对应的Rights,并向DRM Agentl返回RightsRemovalResponse消息，其中包含处理结果。S509:RI向DRM Agent2发送触发器ROAP trigger{SRMROAcquisition},触发DRM Agent2协助SRM2获取Upload的许可，触发器中包含RI标识、RI别名、RI URL、许可标识、许可别名、内容标识、以及RI是否保存了设备2和SRM2的证书链等参数。DRM Agent2和DRM Agentl可以为同一 DRMAgent。本步骤是可选的，用户可以通过人机界面操作设备代理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,则DRM Agent2可先将加密的REK和Kmac的连4妄值发送给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之间共享许可的方案，此时不需要消耗共享权限。
21虽然在同一用户的SRM之间共享Rights不会消耗Rights的Move权限，但是RI需要验证SRM2和SRM1属于同一用户，验证方法包括多种可以是RI根据本地保存的SRM标识和用户标识的对应关系验证，或者RI向另一实体(如用户管理器)查询，或者RI根据用户使用SRM提供的信息(如密码、问题答案等)来验证。
用户可以一次性Upload多个许可到RI，也可以一次性安装多个许可到SRM2。这种批量处理方式尤其适用于用户更换SRM卡的情况。
作为在同一用户的SRM之间共享Rights的替代方案，可以由DRM Agent向RI查询SRMl和SRM2是否属于同 一用户，并直接进行Rights的共享，无需RI重新生成许可。
概括而言，本发明实施例提供的在属于相同用户的SRM之间共享许可的方法包括以下步骤 DRM Agent确定第一 SRM和第二 SRM属于相同用户时，将从第一SRM获取的许可发送给第二 SRM;
其中，在实施例五和实施例六中，区别主要在所述DRM Agent向RI或用户管理器查询第一 SRM和第二 SRM所属用户的过程不同。
下面详细介绍在属于相同用户的SRM之间共享许可的各个实施例。
首先介绍在属于相同用户的SRM之间共享许可的实施例五。
概括而言，实施例五中查询第一 SRM和第二 SRM所属用户的过程为 DRM Agent向RI或用户管理器发送包含第二 SRM标识的查询消息，
查询所述第二 SRM所属用户； DRM Agent验证第一 SRM和第二 SRM是否属于相同用户。参见图6,为实施例五流程图，包括
S601: DRM Agent根据用户请求发起将SRMl上的Rights共享给同一用户的另一 SRM, DRM Agent从SRMl获取Rights信息和REK。在S601之前DRM Agent和SRM Agent 1之间需要互相认证和建立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,具体步骤如图i中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所属的用户并自行进行比4交不同，该实施例六中由DRM Agent将SRM1和SRM2的标识上才艮给RI，由RI进行比较后返回比较结果。这种情况下DRM Agent无需了解用户标识细节。
概括而言，实施例六中查询第一 SRM和第二 SRM所属用户的过程为[1] DRM Agent向RI或用户管理器发送包含第一 SRM标识和第二 SRM标识的查询消息，查询所述第一 SRM和所述第二 SRM是否属于相同用户；[2]RI或用户管理器向DRMAgent返回查询响应，告知所述第一 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:如果共享4喿作为转移，则DRM Agent指示SRM1删除该Rights,具体步骤如图i中S105-S106。
S704-S705: DRM Agent将Rights共享给SRM2。由于Rights绑定SRM1的用户，DRMAgent向RI查询SRM1和SRM2是否属于同一用户。请求中包含SRM1和SRM2的标识，RI检查SRM1和SRM2关联的用户是否一致并在响应消息中返回结果。如果结果表明SRM1和SRM2属于同一用户，则执行S706，否则DRMAgent拒绝将Rights共享给SRM2。在S904之前DRMAgent和SRM Agent2之间需要互相认证和建立SAC通道。
S706: DRM Agent将Rights安装到SRM2,具体步骤如图1中S107-S110。
S707:如果SRM2成功安装Rights,则DRMAgent删除本地的Rights。
该实施例六中DRM Agent先从SRM1获取许可后再向RI查询SRM1和SRM2是否属于同一用户。如果用户发起共享时已经确定目的SRM,可选的，DRM Agent也可以先向RI查询SRM1和SRM2是否属于同 一用户再从SRM1获取许可。此外，DRMAgent也可以在确认SRM2上有足够的空间安装Rights后再删除SRM1上的Rights。
上述在属于相同用户的SRM之间共享许可的两个实施例中，DRM Agent均向RI查询SRM所属的用户，如果RI无法获知SRM所属的用户，可能需
24要向其它实体，如用户管理器，查询SRM所属的用户，或者DRMAgent可以直接向管理SRM和用户关系的实体，如用户管理器，查询SRM所属的用户。
另外，上述在属于相同用户的SRM之间共享许可的两个实施例中，都是以SRM1和SRM2连接于同 一个DRM Agent为例进行说明的，某些情况下，可能两个SRM位于不同的地方，无法直接连接到同一个DRMAgent，则可能需要多个DRM Agent代为中转。例如，需对图6改动的是，DRM Agent实际为两个DRM Agent: DRM Agentl和DRM Agent2,分别连4妄SRM1和SRM2,在具体流程上，可由DRM Agentl查询SRM1所属用户，并在将许可转移给DRM Agent2时指明该Rights只能共享给该用户的SRM， DRM Agent2确定SRM2同属于该用户后，才能将该Rights安装到SRM2;或者DRM Agentl确定SRM1和SRM2同属一个用户时，将许可共享给DRMAgent2并指明共享给SRM2,再由DRM Agent2安装到SRM2;或者DRM Agent将许可共享给DRMAgent2并指明共享给与SRM1同一用户的SRM, DRM Agent在确定SRM1和SRM2同属一个用户后，才能将该Rights安装到SRM2。需对图7改动的是，DRM Agentl向RI进行SRM1和SRM2所属用户查询，并且，在RI确定SRM1和SRM2同属一个用户时，由DRM Agentl将许可共享给DRMAgent2,再由DRMAgent2安装到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功能，该装置包括获:f又单元， 用于从第一SRM获取许可；中转设置单元，用于将所述获取的许可设置为中 转状态；发送单元，用于将所获取的许可发送给第二SRM;控制单元，扣除 一次共享权限。优选地，该装置还包括请求删除单元，用于请求所述第一 SRM删除所述许可；删除响应接收单元，用于接收所述第一SRM返回的删 除i午可响应。
另外，本发明实施例提供的第二装置是指DRM Agent或位于DRM Agent 内的功能实体，该装置执行图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的许可；发送 单元，用于向第二 DRM Agent发送所述许可，通过所述第二 DRM Agent提供 给第二SRM。
另外，本发明实施例提供的第六装置是指DRM Agent或位于DRM Agent 内的功能实体，该装置执行图6或图7中DRMAgent功能，该装置包括确定单元，确定所述第一SRM和第二SRM是否属于相同用户；获取单元，用 于在所述确定单元确定第一 SRM和第二 SRM属于相同用户时，从所述第一 SRM获取许可；执行单元，用于将所述许可发送给第二SRM。另外
需要说明的是，上述各个实施例仅是以在两个SRM之间共享许可为例进 行说明的，本领域人员可毫无疑问地获知，本发明实施例可以实现在三个或 三个以上SRM之间共享许可。本发明实施例也可应用于通过DRM Agent将 SRM上的许可共享到另一 DRM Agent。
本领域普通技术人员可以理解，实现上述实施例的方法的过程可以通过 程序指令相关的硬件来完成，所述的程序可以存储于可读取存储介质中，该 程序在执行时执行上述方法中的对应步骤。所述的存储介质可以如 ROM/RAM、磁碟、光盘等。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普 通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润 饰，这些改进和润饰也应视为本发明的保护范围。
权利要求
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、 根据权利要求l所述方法，其特征在于，所述DRM Agent将所述许 可发送给第二SRM后，还包括所述DRM Agent删除本地的所述许可。
4、 根据权利要求l所述方法，其特征在于，所述DRM Agent在中转操 作过程中记录日志，所述日志包含才喿作类型、当前状态、许可标识、第一SRM 标识、许可在第一 SRM上对应的第 一 句柄、第二 SRM标识、许可在第二 SRM 上对应的第二句柄中的部分或全部。
5、 根据权利要求4所述方法，其特征在于，当共享许可操作发生中断时， 还包括所述DRM Agent才艮据所述日志将许可继续发送到第二 SRM; 或者，所述DRM Agent根据所述日志将许可恢复到第一 SRM。
6、 根据权利要求1所述方法，其特征在于，所述DRM Agent从第一 SRM 获取许可前，还包括所述DRM Agent将所述第二 SRM的公钥或证书提供给第一 SRM，第一 SRM使用第二 SRM的公钥加密许可中的权限加密密钥或内容加密密钥。
7、 根据权利要求l所述方法，其特征在于，所述DRM Agent将所述许 可发送给第二 SRM具体包括所述DRM Agent将所述许可通过其它DRM Agent中转给第二 SRM。
8、 一种共享许可的方法，其特征在于，包括数字版权管理终端DRM Agent触发第一 SRM和第二 SRM协商共享密钥； 所述第一SRM使用所述共享密钥加密所述许可的部分或全部信息； 所述第一 SRM将所述许可发送给第二 SRM。
9、 根据权利要求8所述方法，其特征在于，所述许可的部分或全部信息 包括权限加密密钥或内容加密密钥。
10、 根据权利要求8所述方法，其特征在于，在所述第一SRM将所述许 可发送给第二SRM之前，还包括所述第一SRM使用所述共享密钥对许可的部分或全部信息进行完整性保护。
11、 根据权利要求8所述方法，其特征在于，在所述第一SRM将所述许 可发送给第二SRM之后，还包括所述第二 SRM验证所述许可，并在通过后扣除一次共享权限。
12、 根据权利要求8所述方法，其特征在于，在所述第一SRM将所述许 可发送给第二SRM之前，还包括所述第一 SRM将许可的共享权限扣除一次。
13、 根据权利要求8所述方法，其特征在于，所述第一SRM将所述许可 发送给第二 SRM具体包括所述第一 SRM通过所述DRM Agent将所述许可发送给第二 SRM; 所述DRM Agent在中转过程中验证许可并扣除一次共享权限。
14、 根据权利8至13任一项所述方法，其特征在于，当所述共享许可是 指转移许可时，还包括所述第一SRM在确认所述第二SRM接收到许可后， 删除本地的所述许可。
15、 根据权利要求8所述方法，其特征在于，所述DRM Agent触发第一 SRM和第二SRM协商共享密钥的过程包括所述DRM Agent向第一 SRM发起认证过程，获取第一 SRM证书链； 所述DRM Agent向第二 SRM发起认证过程，将所获取的第一 SRM证书链发送给第二 SRM,并从第二 SRM获取第二 SRM证书链和第一 SRM公钥加密的第二随机数；所述DRM Agent向第一 SRM发起密钥交换过程，将所获取的第二 SRM 证书链和第一 SRM公钥加密的第二随机数发送给第一 SRM,并从第一 SRM 获取第二 SRM公钥加密的第一随机数；所述DRMAgent向第二 SRM发起密钥交换过程，将所获取的第二 SRM 公钥加密的第一随机数发送给第二 SRM;第一 SRM和第二 SRM利用所述第一随机数和第二随机数，确定共享密钥。
16、 一种共享许可的方法，其特征在于，包括第 一数字版权管理终端DRM Agent从第一 SRM获取许可后，发送给版 权发行者RI;第二 DRM Agent从RI获取所述许可，并发送给第二 SRM。
17、 根据权利要求16所述方法，其特征在于，当所述共享许可是指转移 许可时，还包括所述第一SRM删除所述许可。
18 、根据权利要求16所述方法，其特征在于，所述第二 DRM Agent从 RI获^^所述许可前，还包括RI根据从第一 SRM获取的许可生成绑定第二 SRM的许可。
19、 根据权利要求16所述方法，其特征在于，所述第二DRMAgent从 RI获取所述许可前，还包括RI验证第一 SRM和第二 SRM属于相同用户。
20、 一种共享许可的方法，其特征在于，包括数字版权管理终端DRM Agent确定第一 SRM和第二 SRM属于相同用户 时，将从第一 SRM获取的许可发送给第二 SRM。
21、 根据权利要求20所述方法，其特征在于，所述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是否属于相同用户。
22、 一种共享许可的装置，其特征在于，包括 获取单元，用于从第一SRM获取许可； 中转设置单元，用于将所述获取的许可设置为中转状态； 发送单元，用于将所获取的许可发送给第二 SRM; 控制单元，扣除一次共享权限。
23、 根据权利要求22所述装置，其特征在于，还包括 请求删除单元，用于请求所述第一 SRM删除所述许可； 删除响应接收单元，用于接收所述第一 SRM返回的删除许可响应。
24、 一种共享许可的装置，其特征在于，包括 SRM交互单元，用于触发第一SRM和第二SRM进行密钥协商； 转发单元，用于将所述第一 SRM的许可转发给第二 SRM。
25、 一种在第一安全可移动媒介SRM和第二 SRM之间共享许可的装置， 位于第一SRM中，其特征在于，包括密钥协商单元，用于与第二SRM进行密钥协商；处理单元，用于利用与第二 SRM协商的共享密钥对许可的部分或全部信 息加密；发送单元，用于将许可发送给第二SRM。
26、 根据权利要求25所述装置，其特征在于，还包括删除单元，用于在确认所述第二SRM接收到许可后，删除本地的所述许可。
27、 一种共享许可的装置，位于第二SRM中，其特征在于，包括 密钥协商单元，用于与第一SRM进行密钥协商；接收单元，用于接收第一SRM发送的许可；权限扣除单元，用于在所述接收单元接收到正确的许可后，扣除一次操 作权限。
28、 一种共享许可的装置，其特征在于，包括获取单元，用于从第一数字版权管理终端DRM Agent获取第一 SRM的 许可；发送单元，用于向第二 DRM Agent发送所述许可，通过所述第二DRM Agent提供给第二 SRM。
29、 一种共享许可的装置，其特征在于，包括 确定单元，确定第一SRM和第二SRM是否属于相同用户； 获取单元，用于在所述确定单元确定第一 SRM和第二 SRM属于相同用户时，从所述第一SRM获取许可；执行单元，用于将所述许可发送给所述第二 SRM。
全文摘要
本发明公开了一种在SRM之间共享许可的方法及装置，其中的方法包括DRM Agent从第一SRM获取许可，并将所述许可在本地设置为中转状态；所述DRM Agent将所述许可的共享权限扣除一次；所述DRM Agent将所述许可发送给第二SRM。与现有方案在许可从SRM1转移到设备过程中需要扣除一次Move权限、在许可从设备转移到SRM2过程中需要扣除另一次Move权限相比，本发明实施例通过将DRM Agent中转的许可设置为中转状态，由此仅扣除一次共享权限，减少了共享权限的不必要的消耗，有利于维护用户权益。
文档编号G06F21/10GK101640589SQ20081013476
公开日2010年2月3日 申请日期2008年7月29日 优先权日2008年7月29日
发明者周志鹏, 张仁宙, 袁卫忠, 晨 黄 申请人:华为技术有限公司