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

专利名称：在安全可移动媒介之间共享许可的方法及装置的制作方法
技术领域：
本发明涉及数字版权管理(Digital Rights Management, DRM)技术领域,尤其涉及一种在安全可移动媒介(Secure Removable Media, SRM)之间共享许可的方法及装置。
背景技术：
为了保护内容所有者的合法权益，DRM通过内容保护和权限控制方案管理数字内 容的使用。典型的DRM方案包括数字内容发行者(Content Issuer，Cl)用内容加密密钥(Content Encryption Key, CEK)对数字内容进行加密打包为内容数据包(DRM ContentFormat, 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获取许可，并将所述许可在本地设置为中转状态，指定转移给第二 SRM，不可用所述许可消费内容；所述DRM Agent将所述许可的共享权限扣除一次；所述DRM Agent将所述许可发送给第二 SRM。一种共享许可的装置，包括获取单元，用于从第一安全可移动媒介SRM获取许可；中转设置单元，用于将所述获取的许可设置为中转状态，指定转移给第二 S RM，不可用所述许可消费内容；发送单元，用于将所获取的许可发送给第二 SRM ；控制单元，扣除一次共享权限。与现有方案在许可从SRMl转移到设备过程中需要扣除一次Move权限、在设备转移到SRM2过程中需要扣除另一次Move权限相比，本发明实施例通过将DRM Agent中转的许可设置为中转状态，由此仅扣除一次Move权限，减少了 Move权限的消耗，有利于维护用户权益。


图I为本发明在SRM之间共享许可方法实施例一流程图；图2为本发明在SRM之间共享许可方法实施例二流程图；图3为本发明在SRM之间共享许可方法实施例三流程图；图4为本发明图3中SRM之间协商共享密钥的流程图；图5为本发明在SRM之间共享许可方法实施例四流程图；图6为本发明在属于相同用户的SRM之间共享许可方法实施例五流程图；图7为本发明在属于相同用户的SRM之间共享许可方法实施例六流程图。
具体实施例方式本发明实施例提供一种在SRM之间共享许可的方案，通过DRM Agent或RI等设备将SRMl中的许可共享给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，是在SRMl和SRM2之间共享许可方法实施例一流程图，包括SlOl DRM Agent和SRM Agentl相互认证并建立安全认证通道(SecureAuthenticated Channel, SAC),认证过程中 DRM Agent 和 SRM Agent I 互相交换证书并验证对方证书的有效性，交换随机数并根据随机数生成通信密钥，包括加密密钥和完整性保护密钥。在DRM Agent和SRM Agent之间建立SAC为现有技术，此处不过多描述。
S102-S103 DRM Agent 发起将 SRMl 上的 Rights 直接转移到另一 SRM :SRM2，该操作可由用户通过和DRM Agent的交互触发，DRM Agent从SRMl获取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通道。图I中以S107a表示。如果DRM Agent可同时和两个SRM Agent交互，则S107a在S107之前任意时刻执行即可。如果DRM Agent不能同时和两个SRM Agent交互，则在S107之前可先和SRMl断开连接，再和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权限的次数。Slll :如果 SRM2 成功安装 Rights，则 DRM Agent 删除本地的 Rights。可选地，在S104中不扣除Move权限，而在将Rights安装到SRM2时再在设备上执行扣除Move权限的操作。另外，在S106之后，设备可以保留该中转Rights的源SRM即SRMl的记录，这样如果在Rights安装到SRM2的过程中发生意外而导致失败，例如SRM2没有足够的空间安装该Rights,可以将Rights重新恢复到SRMl上,从而保证用户的权益不受损害。实施例一是以转移(Move)许可为例对共享许可进行说明，如前所述，共享还包括复制(Copy)，将SRMl中的许可复制到SRM2的过程与图I类似，不同在于，在复制过程中消耗的是Copy权限DRM Agent将SRMl上的所述许可的Copy权限扣除一次,DRM Agent发送给SRM2的许可不包含Copy权限；或者DRM Agent将发送给SRM2的许可的Copy权限扣除一次，并将SRMl上的许可的Copy权限全部扣除。SRMl无需删除该许可。可见，与现有方案在许可从SRMl转移到设备过程中需要扣除一次共享权限、在许可从设备转移到SRM2过程中需要扣除另一次共享权限相比，本发明实施例通过将DRMAgent中转的Rights设置为中转状态，由此仅扣除一次Move权限，减少了 Move权限的消耗，有利于维护用户权益。下面介绍在SRM之间共享许可方法的实施例二。在上述实施例一中图I的S107-S108中，如果Rights安装到SRM2的过程失败，将Rights重新恢复到SRMl则较为复杂，较佳的方案是在确认SRM2有足够的空间安装Rights后，再删除SRMl上的Rights。
参见图2，实施例二流程包括S201 DRM Agent 分别和 SRM AgentU SRM Agent2 互相认证并建立 SAC 通道，DRMAgent和SRM Agent2的认证可以在S205之前任何时候进行。S202-S203 DRM Agent发起将SRMl上的Rights直接转移到SRM2，该操作可由用户通过和DRM Agent的交互触发，DRM Agent从SRMl获取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,则DRM Agent删除本地的Rights。S209-S210 :如果 SRM2 成功安装 Rights，则 DRM Agent 指示 SRM Agentl 删除该Rights。其中，S209-S210也可以在S206之后执行。如果在将Rights安装到SRM2的过程中发生错误，例如SRM2空间不够，则DRMAgent可以取消Move操作，恢复SRMl上的原Rights。如果DRM Agent和某一 SRM连接中断，则DRM Agent可记录中断日志，中断日志具体包括操作类型、当前状态、许可标识、SRMl标识、许可在SRMl上对应的handle I、SRM2标识、许可在SRM2上对应的handle2。下次连接时根据中断日志中的信息进行恢复继续将许可发送到SRM2，完成操作；或者取消操作，将许可恢复到SRMl。为了从一定程度上提高REK的安全性，可以由DRM Agent将SRM2的公钥或证书提供给SRM Agentl, SRM Agentl使用SRM2的公钥对REK进行加密后通过DRM Agent传输给SRM2。可见，实施例二与实施例一相比，在SRM2确定可以安装Rights后，才将SRMl中的Rights删除,这在SRM2无法安装Rights的情况下,DRM Agent恢复SRMl上的原Rights操作比较简单，仅需将Rights恢复为可用状态。下面介绍在SRM之间共享许可方法的实施例三。
在实施例三中，通过DRMAgent协助，在SRMl和SRM2之间建立SAC，并使用SAC密钥共享许可。下面仍以转移许可为例介绍实施例三，对于复制许可，与其类似。概括而言，实施例三包括以下步骤[I]DRM Agent触发第一 SRM和第二 SRM协商共享密钥；[2]第一 SRM使用协商的共享密钥加密许可的部分或全部信息； [3]第一 SRM将许可发送给第二 SRM。下面结合附图对实施例三详细流程进行介绍。 参见图3，为实施例三流程图，包括S301 DRM Agent分别和SRM Agentl和SRM Agent2交换各自支持的信任锚(Trustanchor)。S302 DRM Agent 触发 SRM Agentl 和 SRM Agent2 认证。消息中包含选择的 Trustanchor,DRM Agent可根据待转移的Rights来选择。可选的,触发消息中还可包含SRM2标识。本步骤可由用户选择在两个SRM之间转移Rights的操作触发。S303 SRM Agentl 向 SRM Agent2 发送认证请求。请求中包含 Trust anchor>SRMl证书链、SRM Agentl支持的算法等。如果SRM Agentl和SRM Agent2之间可以直接通信，则消息可不经过DRM Agent，否则所有的消息都需要DRM Agent代为中转。S304 SRM Agent2向SRM Agentl返回认证响应。响应中包含SRM Agent2证书链、SRM2选择的算法、用于生成密钥的随机数RNl，其中RNl需要使用SRM2的公钥加密传输。S305 SRM Agentl向SRM Agent2发送密钥交换请求。请求中包含用于生成密钥的随机数RN2，其中RN2需要使用SRMl的公钥加密传输。S306 SRM Agent2向SRM Agentl返回密钥交换响应。响应中可能包含RNl和RN2的连接值的Hash用于确认随机数。至此，SRMl和SRM2均获得RNl和RN2，分别使用RNl和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中SRMAgentl发送了 Handle,则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权限
与实施例一或实施例二相比，实施例三中是通过SRMl和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间协商共享密钥的过程为本发明实施例新提出的，概括而言包括以下步骤[I]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 交换各自支持的 TrustanchorοS402 DRM Agent向SRM Agentl发起认证请求。消息中包含选择的Trust anchor,对应该Trust anchor的设备证书链等。DRM Agent可根据待转移的Rights来选择TrustanchorοS403 SRM Agentl返回认证响应。响应消息中包含SRMl证书链，使用设备公钥加密的随机数RNsId。S404 DRM Agent向SRM Agent2发起三方认证请求。消息中包含选择的Trustanchor,对应该Trust anchor的设备证书链和SRMl证书链等。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 SRM Agent2返回三方密钥交换响应。响应消息中可能包含RNsls2和RNs2sl的连接值的哈希以及RNds2和RNs2d的连接值的哈希。至此,DRM Agent和SRM AgentUSRM Agent2两两之间共享了一对随机数，可各自独立用其生成密钥。这样，SRMl向SRM2转移Rights时，重要信息如REK可以使用与SRM2之间的共享密钥加密，而其他信息可以使用和DRM Agent间的共享密钥加密或进行完整性保护以方便DRM Agent处理。DRM Agent向SRM Agentl和SRM Agent2提供的随机数可以一样，这样三方可以使用此公共随机数生成三方公共密钥。或者，DRMAgent 可以将 SRM Agentl 提供的 RNsld作为 RNds2提供给 SRM Agent2,将SRM Agent2提供的RNs2d作为RNdsl提供给SRM Agent I，也可生成三方共享密钥。 目前SRM Agent和DRM Agent使用随机数生成密钥时是按照RNd和RNs的顺序连接，但在本方案中为了保证密钥的一致性，可以默认对于每对随机数按照传输的顺序连接，即SRM Agentl使用RNsld和RNdsl的顺序连接，而SRM Agent2则使用RNds2和RNs2d的顺序连接。在不影响密钥的一致性的情况下，也可使用其它方式生成密钥。通过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，DRMAgent2 将该 Rights 转移到 SRM2。此外，也可以通过RI在两个SRM之间转移Rights，概括而言，包括以下步骤[I]在第一 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。触发器中可选的包含SRMl标识和许可标识。本步骤是可选的，用户可以通过人机界面操作设备upload SRMl上的许可，直接从S502开始。S502 DRM Agentl 向 SRM Agentl 发送 RightsUpload 请求消息，消息中包含标识Rights 的 handle、用于替换该 handle 的新 handle。在 S502 之前DRM Agentl 和 SRM Agentl之间需要互相认证和建立SAC通道。
S503 SRM Agentl判断新handle是否和本地其它handle重复,如果不重复,则使用新handle替换步骤I中的handle,并将Rights置为不可用。SRMAgentl向DRM Agentl返回RightsUpload响应消息,如果handle不重复,则消息中还包含Rights信息，REK, Kmac,时间戳，以及SRM Agentl对{指明upload的标志、REK、RI标识、时间戳}的签名。S504 DRM Agentl检查Rights信息中的RI签名以及状态信息是否超出Rights中的原始权限。S505 DRM Agentl向RI发送SRMROUpload请求消息，其中除了请求消息包含的一些公共參数，如设备I标识、RI标识、nonce、时间戳、设备I证书链等之外，还包含upload
信息·从 SRM Agentl 获取的 Rights 信息中的 RightsObjectContainer 部分(即原 RI 下发的许可中的〈rights〉和〈signature〉)或对其格式转换后的结果，如果RI在ROAPtrigger {SRMROUpload}中标记 roRequested 为 false,则该參数可省略；·如果该许可为有状态的，则包括从SRM Agentl获取的Rights信息中的状态信息；· RI公钥加密的REK和Kmac ；· SRMl标识、SRMl证书链、SRMRightsUpload响应消息中的时间戳、SRM Agentl对{指明upload的标志、REK、RI标识、时间戳}的签名；·以及使用Kmac对上述參数进行MAC操作的結果。DRM Agentl需对请求消息中的參数进行签名，并将签名在请求消息中一起发送给RI0S506 RI对请求消息中的各參数进行验证·如果请求消息中有DRM Agentl证书链，则验证其有效性(可能需要通过OCSP或CRL实现)，并使用请求消息中的设备I证书链或RI本地的设备上下文中的设备I证书链验证请求消息中DRM Agentl的签名；·解密得到REK和Kmac，使用Kmac验证请求消息中的MAC值； 验证SRMl证书链的有效性，可能需要通过OCSP或CRL实现，并使用SRMl证书链验证SRMl签名信息的有效性；·验证请求消息中的时间戳早于当前时间，验证SRMRightsUpload响应消息中的时间戳早于请求消息中的时间戳；·验证〈rights〉和〈signature〉的正确性(如果请求消息中有的话),如果许可为有状态的，还需验证状态信息在原始许可范围内； 尝试使用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 发送触发器 ROAPtrigger {SRMROAcquisition}，触发 DRMAgent2协助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和SRMAgent2之间需要互相认证和建立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的连接值发送给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和SRMl属于同一用户，验证方法包括多种可以是RI根据本地保存的SRM标识和用户标识的对应关系验证，或者RI向另ー实体(如用户管理器)查询，或者RI根据用户使用SRM提供的信息(如密码、问题答案等)来验证。用户可以一次性Upload多个许可到RI，也可以一次性安装多个许可到SRM2。这种批量处理方式尤其适用于用户更换SRM卡的情況。作为在同一用户的SRM之间共享Rights的替代方案，可以由DRM Agent向RI查询SRMl和SRM2是否属于同一用户，并直接进行Rights的共享，无需RI重新生成许可。概括而言，本发明实施例提供的在属于相同用户的SRM之间共享许可的方法包括以下步骤[1]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根据用户请求发起将SRMl上的Rights共享给同一用户的另一SRM, DRM Agent 从 SRMl 获取 Rights 信息和 REK。在 S601 之前 DRM Agent 和 SRM Agentl之间需要互相认证和建立SAC通道。S602-S603 DRM Agent向RI查询SRMl所属的用户。请求中包含SRMl标识，RI在响应消息中返回用户标识。S604 DRM Agent检查Rights信息中的RI签名以及状态信息是否超出Rights中的原始权限并在验证通过后安装该Rights, DRM Agent在安装该Rights时标识该Rights不可用，并指定关联到S603中RI返回的用户标识。S605 :如果共享操作为转移，则DRM Agent指示SRMl删除该Rights，具体步骤如图 I 中 S105-S106。S606-S607 DRM Agent 将 Rights 共享给 SRM2。由于 Rights 绑定用户标识，DRMAgent向RI查询SRM2所属的用户。请求中包含SRM2标识，RI在响应消息中返回用户标识。在S606之前DRM Agent和SRM Agent2之间需要互相认证和建立SAC通道。S608 DRM Agent验证SRM2所属的用户与Rights绑定的用户是否一致，即和SRMl所属的用户是否一致。如果一致则执行S609，否则拒绝将Rights共享给SRM2。S609 DRM Agent 将 Rights 安装到 SRM2，具体步骤如图 I 中 S107-S110。S610 :如果 SRM2 成功安装 Rights，则 DRM Agent 删除本地的 Rights。下面介绍在属于相同用户的SRM之间共享许可的实施例六。与实施例五中DRM Agent分别查询SRMl和SRM2所属的用户并自行进行比较不同，该实施例六中由DRM Agent将SRMl和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根据用户请求发起将SRMl上的Rights共享给同一用户的另一SRMjDRM Agent从SRMl获取Rights信息和REK，具体步骤如图I中S102-S103。在S701之前DRM Agent和SRM Agentl之间需要互相认证和建立SAC通道。S702 DRM Agent检查Rights信息中的RI签名以及状态信息是否超出Rights中的原始权限并在验证通过后安装该Rights, DRM Agent在安装该Rights时标识该Rights不可用，并指定关联到SRMl的用户。S703 :如果共享操作为转移，则DRM Agent指示SRMl删除该Rights，具体步骤如图 I 中 S105-S106。S704-S705 DRM Agent 将 Rights 共享给 SRM2。由于 Rights 绑定 SRMl 的用户，DRM Agent向RI查询SRMl和SRM2是否属于同一用户。请求中包含SRMl和SRM2的标识，RI检查SRMl和SRM2关联的用户是否一致并在响应消息中返回结果。如果结果表明SRMl和SRM2属于同一用户，则执行S706，否则DRM Agent拒绝将Rights共享给SRM2。在S904之前DRM Agent和SRM Agent2之间需要互相认证和建立SAC通道。S706 DRM Agent 将 Rights 安装到 SRM2，具体步骤如图 I 中 S107-S110。S707 :如果 SRM2 成功安装 Rights，则 DRM Agent 删除本地的 Rights。该实施例六中DRM Agent先从SRMl获取许可后再向RI查询SRMl和SRM2是否属于同一用户。如果用户发起共享时已经确定目的SRM，可选的，DRM Agent也可以先向RI 查询SRMl和SRM2是否属于同一用户再从SRMl获取许可。此外，DRM Agent也可以在确认SRM2上有足够的空间安装Rights后再删除SRMl上的Rights。上述在属于相同用户的SRM之间共享许可的两个实施例中，DRM Agent均向RI查询SRM所属的用户，如果RI无法获知SRM所属的用户，可能需要向其它实体，如用户管理器，查询SRM所属的用户，或者DRM Agent可以直接向管理SRM和用户关系的实体，如用户管理器，查询SRM所属的用户。另外，上述在属于相同用户的SRM之间共享许可的两个实施例中，都是以SRMl和SRM2连接于同一个DRM Agent为例进行说明的，某些情况下，可能两个SRM位于不同的地方，无法直接连接到同一个DRM Agent，则可能需要多个DRM Agent代为中转。例如，需对图6改动的是，DRM Agent实际为两个DRM Agent DRM Agentl和DRM Agent2，分别连接SRMl和SRM2，在具体流程上，可由DRM Agentl查询SRMl所属用户，并在将许可转移给DRMAgent2时指明该Rights只能共享给该用户的SRM，DRM Agent2确定SRM2同属于该用户后，才能将该Rights安装到SRM2 ;或者DRM Agentl确定SRMl和SRM2同属一个用户时，将许可共享给DRM Agent2并指明共享给SRM2，再由DRM Agent2安装到SRM2 ;或者DRM Agent将许可共享给DRM Agent2并指明共享给与SRMl同一用户的SRM，DRM Agent在确定SRMl和SRM2同属一个用户后，才能将该Rights安装到SRM2。需对图7改动的是，DRM Agentl向RI进行SRMl和SRM2所属用户查询，并且，在RI确定SRMl和SRM2同属一个用户时，由DRM Agentl将许可共享给DRM Agent2，再由DRM Agent2安装到SRM2 ;或者由DRM Agentl将许可共享给DRM Agent2，由DRM Agent2向RI进行SRMl和SRM2所属用户查询，并且，在RI确定SRMl和SRM2同属一个用户时，再由DRM Agent2安装到SRM2。可见，在实施例五和实施例六中，由于是对同属一个用户的两个SRM的许可的共享，无需消耗共享权限，进一步保证了用户权益。综上，针对用户发起的在两个SRM间共享许可，设备可先判断两个SRM是否属于同一用户如果属于同一用户则直接共享，不检查共享权限，如实施例五和实施例六所示；如果不属于同一用户则检查共享权限并扣除一次，如实施例一和实施例二所示。与上述各个方法实施例相对应，本发明实施例还提供各种装置。本发明实施例提供的第一装置是指DRM Agent或位于DRM Agent内的功能实体，该装置执行图I或图2中DRM Agent功能，该装置包括获取单元，用于从第一 SRM获取许可；中转设置单元，用于将所述获取的许可设置为中转状态；发送单元，用于将所获取的许可发送给第二 SRM ;控制单元，扣除一次共享权限。优选地，该装置还包括请求删除单元，用于请求所述第一 SRM删除所述许可；删除响应接收单元，用于接收所述第一 SRM返回的删除许可响应。另外，本发明实施例提供的第二装置是指DRM Agent或位于DRM Agent内的功能实体，该装置执行图3中DRM Agent功能，该装置包括SRM交互单元，用于触发第一 SRM和第二 SRM进行密钥协商；转发单元，用于将所述第一 SRM的许可转发给第二 SRM。另外，本发明实施例提供的第三装置是指第一SRM或位于第一 SRM中的功能实体，该装置实现图3中SRMl的功能，该装置包括密钥协商单元，用于与第二 SRM进行密钥协商；处理单元，用于利用与第二 SRM协商的共享密钥对许可的部分或全部信息加密；发送单元，用于将许可发送给第二 SRM。优选地，该装置还包括删除单元，用于在确认所述第二SRM接收到许可后，删除本地的所述许可。另外，本发明实施例提供的第四装置是指第二 SRM或位于第一 SRM中的功能实体，该装置实现图3中SRM2的功能，该装置包括密钥协商单元，用于与第一 SRM进行密钥协商；接收单元，用于接收第一 SRM发送的许可；权限扣除单元，用于在所述接收单元接收到正确的许可后，扣除一次操作权限。另外，本发明实施例提供的第五装置是指RI或用户管理器或位于RI或用户管理器内的功能实体，该装置执行图5中RI功能，该装置包括获取单元，用于从第一数字版权管理终端DRM Agent获取第一 SRM的许可；发送单元，用于向第二 DRM Agent发送所述许可，通过所述第二 DRM Agent提供给第二 SRM。另外，本发明实施例提供的第六装置是指DRM Agent或位于DRM Agent内的功能实体，该装置执行图6或图7中DRM Agent功能，该装置包括确定单元，确定所述第一 SRM和第二 SRM是否属于相同用户；获取单兀,用于在所述确定单兀确定第一 SRM和第二 SRM属于相同用户时，从所述第一 SRM获取许可；执行单元，用于将所述许可发送给第二 SRM。另外需要说明的是，上述各个实施例仅是以在两个SRM之间共享许可为例进行说明 的，本领域人员可毫无疑问地获知，本发明实施例可以实现在三个或三个以上SRM之间共享许可。本发明实施例也可应用于通过DRM Agent将SRM上的许可共享到另一 DRM Agent。本领域普通技术人员可以理解，实现上述实施例的方法的过程可以通过程序指令相关的硬件来完成，所述的程序可以存储于可读取存储介质中，该程序在执行时执行上述方法中的对应步骤。所述的存储介质可以如R0M/RAM、磁碟、光盘等。以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。
权利要求
1.一种在安全可移动媒介SRM之间共享许可的方法，其特征在于，包括 数字版权管理终端DRM Agent从第一 SRM获取许可，并将所述许可在本地设置为中转状态，指定转移给第二 SRM，不可用所述许可消费内容； 所述DRM Agent将所述许可的共享权限扣除一次； 所述DRM Agent将所述许可发送给第二 SRM。
2.根据权利要求I所述方法，其特征在于，所述共享许可是指复制许可，所述共享权限是指复制权限；或者，所述共享许可是指转移许可，所述共享权限是指转移权限； 当所述共享许可是指转移许可时，还包括所述DRM Agent触发所述第一 SRM删除所述许可； 当所述共享许可是指复制许可时，所述DRM Agent将所述许可的共享权限扣除一次具体包括 所述DRM Agent将第一 SRM上的所述许可的复制权限扣除一次，所述DRM Agent将所述许可发送给第二 SRM时许可不包含复制权限； 或者， 所述DRM Agent将发送给第二 SRM的所述许可的复制权限扣除一次，并将第一 SRM上的所述许可复制权限全部扣除。
3.根据权利要求I所述方法，其特征在于，所述DRMAgent将所述许可发送给第二 SRM后,还包括 所述DRM Agent删除本地的所述许可。
4.根据权利要求I所述方法，其特征在于，所述DRMAgent在中转操作过程中记录日志，所述日志包含操作类型、当前状态、许可标识、第一 SRM标识、许可在第一 SRM上对应的第一句柄、第二 SRM标识、许可在第二 SRM上对应的第二句柄中的部分或全部。
5.根据权利要求I所述方法，其特征在于，所述DRMAgent从第一 SRM获取许可前，还包括 所述DRM Agent将所述第二 SRM的公钥或证书提供给第一 SRM，第一 SRM使用第二 SRM的公钥加密许可中的权限加密密钥或内容加密密钥。
6.根据权利要求I所述方法，其特征在于，所述DRMAgent将所述许可发送给第二 SRM具体包括 所述DRM Agent将所述许可通过其它DRM Agent中转给第二 SRM。
7.一种共享许可的装置，其特征在于，包括 获取单元，用于从第一安全可移动媒介SRM获取许可； 中转设置单元，用于将所述获取的许可设置为中转状态，指定转移给第二 SRM，不可用所述许可消费内容； 发送单元，用于将所获取的许可发送给第二 SRM ； 控制单元，扣除一次共享权限。
8.根据权利要求7所述装置，其特征在于，还包括 请求删除单元，用于请求所述第一 SRM删除所述许可； 删除响应接收单元，用于接收所述第一 SRM返回的删除许可响应。
全文摘要
本发明公开了一种在SRM之间共享许可的方法及装置，其中的方法包括DRM Agent从第一SRM获取许可，并将所述许可在本地设置为中转状态，指定转移给第二SRM，不可用所述许可消费内容；所述DRM Agent将所述许可的共享权限扣除一次；所述DRM Agent将所述许可发送给第二SRM。与现有方案在许可从SRM1转移到设备过程中需要扣除一次Move权限、在许可从设备转移到SRM2过程中需要扣除另一次Move权限相比，本发明实施例通过将DRM Agent中转的许可设置为中转状态，由此仅扣除一次共享权限，减少了共享权限的不必要的消耗，有利于维护用户权益。
文档编号G06F21/00GK102752105SQ20121021821
公开日2012年10月24日 申请日期2008年7月29日 优先权日2008年7月29日
发明者周志鹏, 张仁宙, 袁卫忠, 黄晨 申请人:华为技术有限公司