CN102595216B - 一种实现密钥获取的方法和系统 - Google Patents

Abstract

本发明公开了一种实现密钥获取的方法和系统，可针对被拒绝的业务密钥请求，通过推送用户频道信息触发终端再次获取密钥。本发明实现密钥获取的技术可设置不同功能模块使得业务密钥请求失败数目减少；并且通过优化业务密钥请求的失败处理方式，使终端在请求业务密钥时能得到有效的响应，因而有效提高了业务密钥请求成功率，提高了用户播放成功率，提高了用户使用业务的成功率和体验度。

Description

一种实现密钥获取的方法和系统

技术领域

本发明涉及通信领域，具体涉及一种实现密钥获取的方法和系统。

背景技术

移动广播式手机电视业务管理系统(MBBMS，Mobile Broadcast BusinessManagement System)利用广电运营商的广播网络提供多媒体内容的下行传输，并且利用移动通信网络的鉴权管理系统和双向网络传输能力，以及广电的用户管理系统完成对用户的认证、授权和管理，同时利用移动网络的双向通道实现相关互动功能。

目前，只支持移动多媒体广播/手机电视业务中两种类型的业务：广播电视节目业务和基于广播电视节目业务的互动业务。其中广播电视节目业务是指广播电视播出机构提供的连续播出的节目。

如图1所示，移动侧MBBMS业务平台(在后续的描述中简称为平台)主要完成业务指南的分发，用户订购关系管理，用户密钥管理，用户的认证鉴权和计费等功能。

终端主要完成移动多媒体广播/手机电视业务接收展现并与网络侧MBBMS业务平台配合完成用户鉴权、订购关系管理和密钥管理。

终端的用户认证模块是终端侧鉴权和密钥管理的核心模块，主要完成密钥的存储、生成和解密功能。

广电侧移动多媒体广播/手机电视业务系统主要完成音视频编码、节目流加密、业务信息配置、广播信号的复用和发射，以及用户订购信息存储、广电用户密钥管理、业务密钥管理等。

MBBMS认证授权是通过对节目流进行加密，然后向用户发送解密密钥的方式实现的。为保证密钥在传输过程中的安全性，在网络中传送的密钥都是被加密的。密钥管理采用四层体系结构，图2所示，其中，

第一层：认证管理和用户初始化注册。用户与移动通信网络之间进行相互认证，认证通过后获得共享密钥。根据此共享密钥，终端的用户认证模块和网络生成认证密钥(MRK，MBMS Request Key)和用户密钥(MUK，MBMS UserKey)。其中MRK用于终端与MBBMS业务平台进行认证，用户密钥用于传输业务密钥时对业务密钥加密。广电用户密钥预置在终端的用户认证模块中和广电侧移动多媒体广播/手机电视业务系统中。

第二层：业务密钥管理。网络根据用户订购关系将业务密钥通过加密方式传送给用户。网络将先后使用广电用户密钥和移动用户密钥即MUK对业务密钥加密，终端的用户认证模块对业务密钥消息解密时同样将先后使用终端的用户认证模块中保存的MUK和广电用户密钥以进行解密。

第三层：节目流密钥管理。网络将加密后的节目流密钥在广播网络上广播。网络对节目流密钥进行加密时将使用业务密钥，终端的用户认证模块对节目流密钥消息解密时将使用解密后的业务密钥。

第四层：节目流管理。网络使用节目流密钥对节目流进行加密，加密后的节目流通过广播信道进行分发，终端使用解密后的节目流密钥进行解密。

终端侧设备与MBBMS平台交互，进行GBA(Generic BootstrappingArchitecture)认证，并在认证通过后由终端的用户认证模块生成共享密钥。根据此共享密钥，终端的用户认证模块和网络生成MRK和MUK。其中MRK用于终端与MBBMS业务平台进行认证，用户密钥MUK用于传输业务密钥时对业务密钥(MSK，MBMS Service Key)加密。

目前，终端和MBBMS业务平台播放业务(请求业务密钥)时，由于平台原因(比如请求数目超过系统阀值或者平台内部处理出错)导致请求业务密钥失败时，播放业务失败，这会影响用户体验，并降低业务密钥请求的成功率。

发明内容

有鉴于此，本发明的主要目的在于提供一种实现密钥获取的方法和系统，提高业务密钥请求成功率，提高了用户使用业务的成功率和体验度。

为达到上述目的，本发明的技术方案是这样实现的：

一种实现密钥获取的方法，该方法包括：

针对被拒绝的业务密钥请求，通过推送用户频道信息触发终端再次获取密钥。

触发所述终端之前，还对业务密钥请求数以及所属平台进行监测，在监测到平台运行正常时，确定要推送的与所述终端相对应的用户数。

确定要推送的所述用户数的过程包括：

进行业务密钥下发权限的有效性认证，将有业务密钥下发权限的用户确定为符合要求的要推送的所述用户数。

确定要推送的所述用户数时，如果预先保存的用户数小于当前所需要的用户数，就将最大有效用户数确定为要推送的所述用户数；否则将当前所需要的相应用户数确定为要推送的所述用户数。

根据要推送的所述用户数，还进行业务密钥下发权限的有效性认证，得到最终需要下发的用户数，据此向对应的终端发送用于触发业务密钥获取流程的用户频道信息。

所述推送的方式包括Http消息传输、短信传输中至少一种。

该方法还包括：

预设因所述推送而触发业务密钥请求的次数，据此避免触发业务密钥请求的过程进入死循环。

一种实现密钥获取的系统，该系统包括终端处理模块、业务密钥处理模块；其中，

所述业务密钥处理模块，用于针对被拒绝的业务密钥请求，通过推送用户频道信息触发所述终端处理模块再次获取密钥；

所述终端处理模块，用于根据推送的所述用户频道信息再次获取密钥。

所述业务密钥处理模块包括请求处理模块、推送处理模块；其中，

所述请求处理模块用于完成业务密钥处理的主干流程；

所述推送处理模块用于进行用户频道信息的推送。

所述业务密钥处理模块还包括用户记录维护模块、定时处理模块；其中，

所述用户记录维护模块，用于对请求失败的用户进行记录；

所述定时处理模块，用于对所属的平台系统运行状况做检测，以确定能否将用户记录维护模块记录的有效用户推送下去；并在监测到平台运行正常时，与请求处理模块确定要推送的与所述终端相对应的用户数。

确定要推送的所述用户数时，请求处理模块向用户记录维护模块请求对应的用户数，用户记录维护模块据此进行业务密钥下发权限的有效性认证，将有业务密钥下发权限的用户确定为符合要求的要推送的所述用户数。

确定要推送的所述用户数时，如果预先保存的用户数小于当前所需要的用户数，用户记录维护模块就将最大有效用户数确定为要推送的所述用户数；否则用户记录维护模块将当前所需要的相应用户数确定为要推送的所述用户数。

根据要推送的所述用户数，请求处理模块还进行业务密钥下发权限的有效性认证，得到最终需要下发的用户数，据此向对应的终端中的终端处理模块发送用于触发业务密钥获取流程的用户频道信息。

所述业务密钥处理模块在推送时，通过Http消息传输或短信传输。

所述请求处理模块还预设因所述推送而触发业务密钥请求的次数，据此避免触发业务密钥请求的过程进入死循环。

所述平台为移动广播式手机电视业务管理系统MBBMS平台。

本发明实现密钥获取的技术可设置不同功能模块使得业务密钥请求失败数目减少；并且通过优化业务密钥请求的失败处理方式，使终端在请求业务密钥时能得到有效的响应，因而有效提高了业务密钥请求成功率，提高了用户播放成功率，提高了用户使用业务的成功率和体验度。

附图说明

图1为移动广播式手机电视业务管理系统的系统结构图；

图2为移动广播式手机电视业务管理系统的四层密钥管理体系原理示意图；

图3为本发明实施例实现密钥获取的系统图；

图4为本发明实施例中终端主动发起业务密钥请求的流程图；

图5为本发明实施例中终端被动触发业务密钥请求的流程图；

图6为本发明实施例中实施用户频道信息推送的流程图；

图7为本发明实施例实现密钥获取的流程图；

图8为本发明实施例实现密钥获取的流程简图。

具体实施方式

在实际应用时，终端和业务密钥处理模块进行业务交互，对于主动密钥请求数目很大的情况(超过平台设置的阀值时)，平台可能拒绝一部分用户请求，使得一部分用户获取密钥失败；另外，当平台内部处理出错时，也可能使一部分用户获取密钥失败。因此，应该定时检测平台运行状况(包括请求数目是否超过阀值以及平台内部处理是否正常)，通过推送用户频道信息触发终端获取密钥的流程；

需要说明的是，终端播放业务时，MBBMS业务平台进一步下发业务密钥给终端，终端将业务密钥写入用户认证模块。

如果是平台原因导致的业务密钥请求失败，通过对业务密钥请求失败的用户进行记录，在平台运行空闲时，对这些用户依次推送下去，使得终端能主动请求业务密钥，从而使得用户下次再次使用播放业务时，不需要再次请求业务密钥，从而提高了用户使用业务的体验度。

另外，由于业务密钥处理模块将一部分业务密钥请求失败的用户进行了再次触发，使得这部分用户请求业务密钥的成功率得到提高，从而提高了用户业务使用成功率，提高用户体验度。

具体而言，业务密钥处理模块包括请求处理模块，用户记录维护模块，推送处理模块，定时处理模块；其中，

请求处理模块主要完成业务密钥处理的主干流程；用户记录维护模块主要用于对请求失败的用户进行记录，能对用户记录进行处理，如删除、增加、查询、更新等；推送处理模块主要进行用户频道信息的推送；定时处理模块主要对平台系统运行状况做检测，以确定能否将用户记录维护模块记录的有效用户(即该用户是合法有效的)推送下去；

请求处理模块接收终端中的终端处理模块的业务密钥请求消息，如果终端进行请求的次数达到阀值，则拒绝终端的请求，并将该情况通知给用户记录维护模块；请求处理模块针对平台内部处理出错的请求，也发送用户请求信息给用户记录维护模块；

用户记录维护模块接收来自请求处理模块的通知并保存，还向请求处理模块返回成功响应；

如果请求处理模块成功处理了来自终端处理模块的业务密钥请求消息，则向用户记录维护模块发送删除用户信息的通知，以触发用户记录维护模块删除所述业务密钥请求消息所对应的用户信息；

用户记录维护模块接收来自请求处理模块的删除用户信息的通知，据此删除对应的用户信息；并给请求处理模块返回成功响应；

定时处理模块定时检查平台运行状况，对于每秒业务密钥请求数以及平台自身处理能力进行实时跟踪监测；

定时处理模块监测到平台运行正常时，向请求处理模块发送触发消息以触发推送业务密钥的流程，并根据系统运行情况提供需要推送的用户数；

请求处理模块接收到定时处理模块发送的所述触发消息后，向用户记录维护模块发送查询消息以请求对应的用户数；

用户记录维护模块收到请求处理模块的查询消息后，进行业务密钥下发权限的有效性(比如用户退订了就不需要推送)认证，将符合要求(也称为有效，如：有业务密钥下发权限)的用户返回给请求处理模块；针对不符合要求的用户则立即删除相应记录；

用户记录维护模块根据请求处理模块要求的用户数，返回符合要求的用户数；如果用户记录维护模块所保存的用户数小于请求处理模块所需要的用户数，就返回最大有效用户数；否则返回请求处理模块所需要的相应用户数；

请求处理模块根据要推送的用户数，进一步进行业务密钥下发权限的有效性(比如用户退订了就不需要推送)认证；得到最终需要下发的用户数，并依次将包含用户信息的推送消息发送给推送处理模块以触发用户频道信息的推送；

推送处理模块接收到请求处理模块发送的推送消息后，进行用户频道信息发送，用户频道信息包含用户进行业务密钥请求的必要信息。推送处理模块发送用户频道信息给对应的终端处理模块；终端处理模块接收到此信息后，可以触发业务密钥获取流程。

用户频道信息发出后，终端处理模块触发业务密钥请求流程，请求处理模块处理主动密钥请求，如果达到密钥请求阀值或者平台内部处理出错，向用户记录模块发送查询请求，以查询用户推送的次数；

用户记录模块接收到请求处理模块发送过来的查询请求消息，对相应的用户进行查询，如果查询出此用户已经达到推送的次数，则用户记录模块删除相应用户记录，并返回此用户失效的信息给请求处理模块；如果用户还未达到推送的次数，就累加此用户的推送次数，并返回此用户有效的信息给请求处理模块；

请求处理模块接收到用户记录模块返回用户是否有效的响应，如果用户是有效的，那么因平台原因而不能处理终端处理模块发送的业务密钥请求流程时，暂时不进行后续处理；如果用户是无效的，也不需要进行后续处理；

用户推送信息的次数是可以配置的，这样保证推送用户频道信息所触发的密钥请求流程可以进行多次，最终使得用户最大化地得到业务密钥，真正提高业务密钥请求成功率；

用户记录中要保存有因推送而触发业务密钥请求的次数，以确定用户因用户频道信息推送而触发密钥请求流程的次数，避免使用户进入死循环；

用户频道信息推送流程中，如果业务密钥请求流程正常处理结束，请求处理模块发送删除用户记录的信息给用户记录模块，用户记录模块收到请求后及时删除相应用户记录；

用户记录模块维护着近期业务密钥请求失败的用户记录，终端处理模块在接收到用户频道信息后，可能会因自身原因而无法触发业务密钥请求流程，这种情况下业务密钥请求失败的用户记录就会一直保存着。应用时，可以在保存用户记录时就记录该用户记录的创建时间，比较用户记录的创建时间以及用户记录存放有效期以确认用户记录是否超时，并删除超时的用户记录；并且，用户记录存放有效期是可以配置的；

定时处理模块在检测平台运行情况时，如果检测到平台运行情况为空闲，则可以批量触发用户频道信息的推送，终端因接收到用户频道信息而再次发起请求的过程中，可能会有时延，有可能在终端再次发起请求时平台不处于空闲状态，因此可以通过配置用户频道信息推送次数使终端发起多次请求，这样可以有效提高因用户频道信息推送而触发的业务密钥请求的成功率；

业务密钥请求失败的原因可以分为终端侧原因和平台侧原因；终端侧原因即业务密钥请求失败是由终端侧的错误导致的，比如请求消息非法或者鉴权失败等；平台侧原因即业务密钥请求失败是由平台侧导致的错误，如用户数超过阀值或平台内部处理出现问题；其中，用户数超过阀值即用户请求数目过多，平台因此进行了阀值限制，以拒绝一些用户；平台内部处理出现问题即平台内部模块处理有问题，比如网元之间超时等。

定时处理模块设置定时器(如秒级定时器)，并应用该定时器对平台性能进行监控，比如平台CPU占用率、当前请求数目等；在平台性能稳定的情况下，根据平台设置的请求数目阀值和当前请求数目的差值确定能够进行用户频道信息推送的用户数，并将此用户数作为参考值发送给请求处理模块，如果不出现请求数目波动，可以对请求数目阀值进行合理设置，使得终端处理模块发送的业务密钥请求的消息数目(即用户请求数目)和当前实际请求的用户数的总和不超过所述请求数目阀值；

用户记录模块与请求处理模块进行交互的消息涉及以下三类操作：(1)由请求处理模块发起，对业务密钥请求流程处理失败的用户进行新增用户信息的操作；(2)由请求处理模块发起，对业务密钥请求流程处理失败的用户进行删除用户信息的操作；(3)由请求处理模块发起，查询用户频道信息推送次数，如果用户未到达配置的用户频道信息推送次数，则用户记录模块更新相应用户记录，累加其中的用户频道信息推送次数；否则，不需要进行更新，删除相应用户记录；

针对业务密钥请求失败的用户删除用户信息的操作包括两种情况：(1)业务密钥请求的正常流程处理结束，需要删除用户信息记录；(2)定时处理模块触发查询批量用户时，要检查业务密钥下发权限有效性，如果检查结果为用户是无效用户，需要删除相应用户记录；

检查业务密钥下发权限有效性时可以检查用户当时是否是合法的，比如是订购生效的用户，没有欠费的用户；

推送处理模块触发的用户频道信息推送方式有很多种，只要平台能够将数据正常传输到终端处理模块即可；例如常见的Http消息传输，短信传输等；

所述平台指MBBMS平台。

下面结合附图和实施例对本发明进行详细描述。

请参阅图3，图3所示系统包括终端处理模块31以及业务密钥处理模块32，所述业务密钥处理模块32包括请求处理模块321、推送处理模块322、用户记录维护模块323以及定时处理模块324，结合前述描述可知，所述终端处理模块31用于实现终端侧业务的功能；所述请求处理模块321主要完成业务密钥处理的主干流程；所述推送处理模块322主要进行用户频道信息的推送；所述用户记录维护模块323主要对业务密钥请求失败的用户进行用户信息的记录，如删除、增加、查询或更新用户记录等；所述定时处理模块324主要对平台系统运行状况做检测，以确定能否将用户记录维护模块记录的有效用户推送下去。

结合图4、图5、图6可以得到如图7所示的密钥获取流程，该流程包括以下步骤：

S701：设置于终端中的终端处理模块向请求处理模块发送业务密钥请求；

S702：请求处理模块判断发送业务密钥请求的次数是否达到请求数目阀值；

S703：如果发送业务密钥请求的次数达到所述阀值，请求处理模块向用户记录维护模块发送用户记录；否则，请求处理模块继续进行密钥请求处理；

S704：请求处理模块判断是否平台内部处理出错；

S705：如果是平台内部处理出错，请求处理模块向用户记录维护模块发送用户记录；否则，请求处理模块继续进行密钥请求处理；

S706：请求处理模块处理业务密钥请求的流程结束，用户记录维护模块删除当前用户记录；

S707：请求处理模块给终端返回业务密钥响应；

S708：定时处理模块判断当前请求用户数是否达到阀值以及平台是否运行良好；

S709：定时处理模块向请求处理模块发起推送用户请求；

S710：请求处理模块向用户记录维护模块查询估算数量的用户信息；

S711：用户记录维护模块检查用户下发业务密钥的有效性；

S712：如果业务密钥下发有效，用户记录维护模块选出相应用户记录作为返回给请求处理模块的结果；否则，用户记录维护模块删除相应用户记录；

S713：用户记录维护模块返回符合要求的用户数给请求处理模块；

S714：请求处理模块向推送处理模块发送触发推送用户频道信息的请求；

S715：推送处理模块向终端处理模块推送用户频道信息；

S716：终端处理模块向请求处理模块发送业务密钥请求；

S717：请求处理模块判断请求用户数是否达到阀值；

S718：如果所述请求用户数达到阀值，请求处理模块判断是否达到推送次数；在达到推送次数时，请求处理模块触发用户记录维护模块删除相应用户记录；在达不到推送次数时，请求处理模块不进行处理，等下次平台正常情况下处理；如果所述请求用户数达不到阀值，请求处理模块继续进行密钥请求；

S719：请求处理模块判断是否平台内部处理出错；

S720：如果是平台内部处理出错，请求处理模块判断是否达到推送次数；在达到推送次数时，触发用户记录维护模块删除相应用户记录；在达不到推送次数时不进行处理，等下次平台正常情况下处理；如果不是平台内部处理出错，请求处理模块继续进行密钥请求；

S721：请求处理模块处理密钥请求的流程结束，向用户记录维护模块发送删除当前已请求的用户记录的请求；

S722：请求处理模块向终端处理模块发送业务密钥响应。

结合以上描述可知，本发明实现密钥获取的操作思路可以表示如图8所示的流程，该流程包括以下步骤：

步骤810：业务密钥请求被拒绝；

步骤820：针对被拒绝的所述业务密钥请求，通过推送用户频道信息触发终端再次获取密钥。

综上所述可见，无论是业务密钥处理模块还是其支持的操作方法，本发明实现密钥获取的技术可设置不同功能模块使得业务密钥请求失败数目减少；并且通过优化业务密钥请求的失败处理方式，使终端在请求业务密钥时能得到有效的响应，因而有效提高了业务密钥请求成功率，提高了用户播放成功率，提高了用户使用业务的成功率和体验度。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (16)

1.一种实现密钥获取的方法，其特征在于，该方法包括：

针对被拒绝的业务密钥请求，通过配置推送用户频道信息的次数，推送用户频道信息以触发终端发出密钥请求再次获取密钥；其中，

当达到密钥请求阈值或平台处理出错时，发送用于查询用户频道信息推送次数的查询请求；

如果查询出已经达到推送的次数，则删除相应用户记录，并返回此用户失效的信息给请求处理模块；如果还未达到推送的次数，则累加推送次数，并返回此用户有效的信息给请求处理模块。

2.根据权利要求1所述的方法，其特征在于，触发所述终端之前，还对业务密钥请求数以及所属平台进行监测，在监测到平台运行正常时，确定要推送的与所述终端相对应的用户数。

3.根据权利要求2所述的方法，其特征在于，确定要推送的所述用户数的过程包括：

进行业务密钥下发权限的有效性认证，将有业务密钥下发权限的用户确定为符合要求的要推送的所述用户数。

4.根据权利要求3所述的方法，其特征在于，确定要推送的所述用户数时，如果预先保存的用户数小于当前所需要的用户数，就将最大有效用户数确定为要推送的所述用户数；否则将当前所需要的相应用户数确定为要推送的所述用户数。

5.根据权利要求2至4任一项所述的方法，其特征在于，根据要推送的所述用户数，还进行业务密钥下发权限的有效性认证，得到最终需要下发的用户数，据此向对应的终端发送用于触发业务密钥获取流程的用户频道信息。

6.根据权利要求1所述的方法，其特征在于，所述推送的方式包括Http消息传输、短信传输中至少一种。

7.根据权利要求1所述的方法，其特征在于，该方法还包括：

预设因所述推送而触发业务密钥请求的次数，据此避免触发业务密钥请求的过程进入死循环。

8.一种实现密钥获取的系统，其特征在于，该系统包括终端处理模块、业务密钥处理模块；其中，

所述业务密钥处理模块，用于针对被拒绝的业务密钥请求，通过配置推送用户频道信息的次数，推送用户频道信息以触发终端发出密钥请求再次获取密钥；

所述终端处理模块，用于根据推送的所述用户频道信息再次获取密钥；

所述业务密钥处理模块包括：请求处理模块、用户记录维护模块；

所述请求处理模块，用于当达到密钥请求阈值或平台处理出错时，向所述用户记录维护模块发送用于查询用户频道信息推送次数的查询请求；

所述用户记录维护模块，用于如果查询出已经达到推送的次数，则删除相应用户记录，并返回此用户失效的信息给请求处理模块；如果还未达到推送的次数，则累加推送次数，并返回此用户有效的信息给请求处理模块。

9.根据权利要求8所述的系统，其特征在于，所述业务密钥处理模块还包括：推送处理模块；其中，

所述请求处理模块还用于完成业务密钥处理的主干流程；

所述推送处理模块用于进行用户频道信息的推送。

10.根据权利要求8所述的系统，其特征在于，所述业务密钥处理模块还包括：定时处理模块；其中，

所述用户记录维护模块，还用于对请求失败的用户进行记录；

所述定时处理模块，用于对所属的平台系统运行状况做检测，以确定能否将用户记录维护模块记录的有效用户推送下去；并在监测到平台运行正常时，与请求处理模块确定要推送的与所述终端相对应的用户数。

11.根据权利要求9所述的系统，其特征在于，确定要推送的所述用户数时，请求处理模块向用户记录维护模块请求对应的用户数，用户记录维护模块据此进行业务密钥下发权限的有效性认证，将有业务密钥下发权限的用户确定为符合要求的要推送的所述用户数。

12.根据权利要求11所述的系统，其特征在于，确定要推送的所述用户数时，如果预先保存的用户数小于当前所需要的用户数，用户记录维护模块就将最大有效用户数确定为要推送的所述用户数；否则用户记录维护模块将当前所需要的相应用户数确定为要推送的所述用户数。

13.根据权利要求9至12任一项所述的系统，其特征在于，根据要推送的所述用户数，请求处理模块还进行业务密钥下发权限的有效性认证，得到最终需要下发的用户数，据此向对应的终端中的终端处理模块发送用于触发业务密钥获取流程的用户频道信息。

14.根据权利要求8所述的系统，其特征在于，所述业务密钥处理模块在推送时，通过Http消息传输或短信传输。

15.根据权利要求8所述的系统，其特征在于，所述请求处理模块还预设因所述推送而触发业务密钥请求的次数，据此避免触发业务密钥请求的过程进入死循环。

16.根据权利要求8所述的系统，其特征在于，所述平台为移动广播式手机电视业务管理系统MBBMS平台。