手机应用调用鉴权方法、多功能通用智能卡与移动终端的制作方法

文档序号:9712159阅读:375来源:国知局
手机应用调用鉴权方法、多功能通用智能卡与移动终端的制作方法
【技术领域】
[0001] 本公开涉及通信领域,特别地,涉及一种手机应用调用鉴权方法、多功能通用智能 卡与移动终端。
【背景技术】
[0002] 随着手机应用市场极大速度的增长,手机应用之间的交互越来越多,一些基础手 机应用开始开放一些基础业务能力,例如,百度开放了百度地图供其他应用调用,爱奇艺也 开放了音视频数据搜索供第H方应用调用,除此之外还有身份令牌认证、数字签名等基础 业务认证能力也逐渐开始向第H方应用开放。
[0003] 现有的手机应用调用鉴权方案,或者是由提供业务能力的应用发布集成 SDK(Software Development Kit,软件开发工具包)包供其他手机应用直接集成调用,或者 由平台进行鉴权,或者通过手机应用中预置共享密钥的方式供其他手机应用加密调用,甚 至是直接开放不做鉴权。
[0004] 但是,送些方式存在W下问题:
[0005] (1)出现伪造调用;
[0006] 似维护升级困难;
[0007] (3)平台负担重、浪费资源;
[000引 (4)预置密钥易泄漏。

【发明内容】

[0009] 本公开鉴于W上问题中的至少一个提出了新的技术方案。
[0010] 本公开在其一个方面提供了一种手机应用调用鉴权方法,其可W更安全、稳定且 便利地进行手机应用的调用鉴权。
[0011] 本公开在其另一方面提供了一种多功能通用智能卡,其可W更安全、稳定且便利 地进行手机应用的调用鉴权。
[0012] 本公开在其又一方面提供了一种移动终端,其可W更安全、稳定且便利地进行手 机应用的调用鉴权。
[0013] 根据本公开,提供一种手机应用调用鉴权方法,包括:
[0014] 响应于手机中的第一应用对第二应用的业务能力的调用请求,接收该调用请求, 所述调用请求中携带第一应用的鉴权信息和第二应用的标识;
[0015] 根据接收的第一应用的鉴权信息和第二应用的标识判断第二应用是否允许第一 应用调用其业务能力;
[0016] 如果允许,则通过第二应用向第一应用返回临时会话密钥W便第一应用能够根据 接收到的临时会话密钥调用第二应用的业务能力。
[0017] 在本公开的一些实施例中,所述第一应用的鉴权信息为第一应用的数字签名证书 的HA甜值。
[0018] 在本公开的一些实施例中,所述方法还包括:
[0019] 在手机内的多功能通用智能卡中预存储被调用应用的标识与一个或多个请求应 用的鉴权信息的对应关系。
[0020] 在本公开的一些实施例中,根据将接收的第一应用的鉴权信息和第二应用的标识 判断第二应用是否允许第一应用调用其业务能力包括:
[0021] 将接收的第一应用的鉴权信息和第二应用的标识与预存储的对应关系进行匹 配;
[0022] 如果匹配成功,则确认允许第一应用调用第二应用的业务能力。
[0023] 在本公开的一些实施例中,根据需求随时更新预存储的对应关系。
[0024] 根据本公开,还提供了一种多功能通用智能卡,包括:
[0025] 接收单元,用于响应于手机中的第一应用对第二应用的业务能力的调用请求,接 收该调用请求,所述调用请求中携带第一应用的鉴权信息和第二应用的标识;
[0026] 判断单元,用于根据接收的第一应用的鉴权信息和第二应用的标识判断第二应用 是否允许第一应用调用其业务能力;
[0027] 反馈单元,用于如果允许,则通过第二应用向第一应用返回临时会话密钥W便第 一应用能够根据接收到的临时会话密钥调用第二应用的业务能力。
[0028] 在本公开的一些实施例中,所述第一应用的鉴权信息为第一应用的数字签名证书 的HA甜值。
[0029] 在本公开的一些实施例中,所述多功能通用智能卡还包括:
[0030] 存储单元,用于存储被调用应用的标识与一个或多个请求应用的鉴权信息的对应 关系。
[0031] 在本公开的一些实施例中,所述判断单元包括:
[0032] 匹配子单元,用于将接收的第一应用的鉴权信息和第二应用的标识与预存储的对 应关系进行匹配;
[0033] 确认子单元,用于如果匹配成功,则确认允许第一应用调用第二应用的业务能力。
[0034] 在本公开的一些实施例中,所述存储单元中存储的对应关系根据需求随时被更新。
[0035] 根据本公开,还提供了一种移动终端,包括多功能通用智能卡,所述多功能通用智 能卡通过化en Mobile API与移动终端中的应用交互。
[0036] 在本公开的技术方案中,由于整个鉴权过程都是在手机内部进行的,未引入鉴权 平台,因此避免了资源浪费;同时,由于整个鉴权过程均是在手机内部完成,因此使得整个 鉴权过程更安全与稳定。
【附图说明】
[0037] 此处所说明的附图用来提供对本公开的进一步理解,构成本申请的一部分。在附 图中:
[0038] 图1是本公开一个实施例的手机应用调用鉴权方法的流程示意图。
[0039] 图2是本公开应用之间互相调用应用能力的一个实例的示意图。
[0040] 图3是本公开另一实施例的手机应用调用鉴权方法的流程示意图。
[0041] 图4是本公开一个实施例的多功能通用智能卡的结构示意图。
[0042] 图5是本公开一个实施例的移动终端的结构示意图。
【具体实施方式】
[0043] 下面将参照附图描述本公开。要注意的是,W下的描述在本质上仅是解释性和示 例性的,决不作为对本公开及其应用或使用的任何限制。除非另外特别说明,否则,在实施 例中阐述的部件和步骤的相对布置W及数字表达式和数值并不限制本公开的范围。另外, 本领域技术人员已知的技术、方法和装置可能不被详细讨论,但在适当的情况下意在成为 说明书的一部分。
[0044] 鉴于现有技术中存在的技术问题,本公开下述实施例通过在现有的 UICC(Universal Integrated Circuit Card,通用集成电路卡)卡里装载卡应用和关键鉴 权数据,W及通过机卡交互接口来实现对手机应用调用的鉴权,可W更安全、稳定且便利地 进行手机应用的调用鉴权。
[004引其中,UICC卡是多功能通用智能卡。
[0046] 关键鉴权数据主要包括终端应用的签名指数的HA甜(即,哈希)值及目标应用的 AID,即,目标应用标识。
[0047] 图1是本公开一个实施例的手机应用调用鉴权方法的流程示意图。
[004引如图1所示,该实施例可W包括W下步骤:
[0049] S102,响应于手机中的第一应用对第二应用的业务能力的调用请求,接收该调用 请求,调用请求中携带第一应用的鉴权信息和第二应用的标识;
[0050] 具体地,在手机中可W安装多个应用,不同应用之间可能会存在调用需求,例如, 会有一个或一些应用具有调用百度地图的请求,为了保证调用的安全性,并非诸如百度地 图等被调用的应用一接收到请求就开放其能力,只有通过鉴权的请求才被开放访问应用的 能力。
[0051] 需要指出的是,某个应用可能只对某个或某些应用开放其被调用的能力,因此,需 在调用请求中携带第一应用的鉴权信息和第二应用的标识。
[0052] S104,根据接收的第一应用的鉴权信息和第二应用的标识判断第二应用是否允许 第一应用调用其业务能力;
[0053] 具体地,在手机的UICC卡内预先存储了各应用的标识与允许调用各应用的鉴权 信息之间的对应关系,该对应关系可W为一一对应关系,也可W为一对多的关系,如下述表 1所示:
[0054]
[00巧] 表1
[0056] 在接收到第一应用的鉴权信息和第二应用的标识后,与表1中的内容进行匹配, 如果匹配成功,则允许第一应用调用第二应用,否则,不允许第一应用调用第二应用。
[0057] S106,如果允许,则通过第二应用向第一应用返回临时会话密钥W便第一应用能 够根据接收到的临时会话密钥调用第二应用的业务能力,送样可W进一步保证对第二应用 调用的安全性。
[0058] 在该实施例中,由于整个鉴权过程都是在手机内部进行的,未引入鉴权平台,因此 避免了资源浪费;同时,由于整个鉴权过程均是在手机内部完成,因此使得整个鉴权过程更 安全与稳定。
[0059] 在一个实例中,第一应用的鉴权信息可W为第一应用的数字签名证书的HA甜值, 但并不限于此,可W是任何实现鉴权功能的信息。
[0060] 在又一实例中,在手机内的多功能通用智能卡中预存储被调用应用的标识与一个 或多个请求应用的鉴权信息的对应关系,W实现对一个或多个请求应用的鉴权。
[0061] 在再一实例中,根据将接收的第一应用的鉴权信息和第二应用的标识判断第二应 用是否允许第一应用调用其业务能力的步骤可W包括:
[0062] 将接收的第一应用的鉴权信息和第二应用的标识与预存储的对应关系进行匹 配;
[0063] 如果匹配成功,则确认允许第一应用调用第二应用的业务能力。
[0064] 需要指出的是,可W根据需求随时更新预存储的对应关系,例如,当某个应用需要 变更调用权限时,可W通过卡应用管理平台对送种对应关系进行管理与更新。
[0065] 上述实施例基于用户卡的手机应用调用鉴权,将关键鉴权数据存储在卡应用安全 空间,利用手机与用户卡交互API完成手机应用之间的调用鉴权,提高了各手机应用调用 鉴权的安全性,降低了平台鉴权的负担,使得手机应用的基础业务能力开放更加便捷安全。
[0066] 为了增强手机应用调用鉴权过程的安全性,本公开利用了机卡通信技术。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1