CN105472605A - 手机应用调用鉴权方法、多功能通用智能卡与移动终端 - Google Patents

Abstract

本公开涉及一种手机应用调用鉴权方法、多功能通用智能卡与移动终端。该方法包括响应于手机中的第一应用对第二应用的业务能力的调用请求，接收该调用请求，所述调用请求中携带第一应用的鉴权信息和第二应用的标识；根据接收的第一应用的鉴权信息和第二应用的标识判断第二应用是否允许第一应用调用其业务能力；如果允许，则通过第二应用向第一应用返回临时会话密钥以便第一应用能够根据接收到的临时会话密钥调用第二应用的业务能力。本公开可以更安全、稳定且便利地进行手机应用的调用鉴权。

Description

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

技术领域

本公开涉及通信领域，特别地，涉及一种手机应用调用鉴权方法、多功能通用智能卡与移动终端。

背景技术

随着手机应用市场极大速度的增长，手机应用之间的交互越来越多，一些基础手机应用开始开放一些基础业务能力，例如，百度开放了百度地图供其他应用调用，爱奇艺也开放了音视频数据搜索供第三方应用调用，除此之外还有身份令牌认证、数字签名等基础业务认证能力也逐渐开始向第三方应用开放。

现有的手机应用调用鉴权方案，或者是由提供业务能力的应用发布集成SDK(SoftwareDevelopmentKit，软件开发工具包)包供其他手机应用直接集成调用，或者由平台进行鉴权，或者通过手机应用中预置共享密钥的方式供其他手机应用加密调用，甚至是直接开放不做鉴权。

但是，这些方式存在以下问题：

(1)出现伪造调用；

(2)维护升级困难；

(3)平台负担重、浪费资源；

(4)预置密钥易泄漏。

发明内容

本公开鉴于以上问题中的至少一个提出了新的技术方案。

本公开在其一个方面提供了一种手机应用调用鉴权方法，其可以更安全、稳定且便利地进行手机应用的调用鉴权。

本公开在其另一方面提供了一种多功能通用智能卡，其可以更安全、稳定且便利地进行手机应用的调用鉴权。

本公开在其又一方面提供了一种移动终端，其可以更安全、稳定且便利地进行手机应用的调用鉴权。

根据本公开，提供一种手机应用调用鉴权方法，包括：

响应于手机中的第一应用对第二应用的业务能力的调用请求，接收该调用请求，所述调用请求中携带第一应用的鉴权信息和第二应用的标识；

根据接收的第一应用的鉴权信息和第二应用的标识判断第二应用是否允许第一应用调用其业务能力；

如果允许，则通过第二应用向第一应用返回临时会话密钥以便第一应用能够根据接收到的临时会话密钥调用第二应用的业务能力。

在本公开的一些实施例中，所述第一应用的鉴权信息为第一应用的数字签名证书的HASH值。

在本公开的一些实施例中，所述方法还包括：

在手机内的多功能通用智能卡中预存储被调用应用的标识与一个或多个请求应用的鉴权信息的对应关系。

在本公开的一些实施例中，根据将接收的第一应用的鉴权信息和第二应用的标识判断第二应用是否允许第一应用调用其业务能力包括：

将接收的第一应用的鉴权信息和第二应用的标识与预存储的对应关系进行匹配；

如果匹配成功，则确认允许第一应用调用第二应用的业务能力。

在本公开的一些实施例中，根据需求随时更新预存储的对应关系。

根据本公开，还提供了一种多功能通用智能卡，包括：

接收单元，用于响应于手机中的第一应用对第二应用的业务能力的调用请求，接收该调用请求，所述调用请求中携带第一应用的鉴权信息和第二应用的标识；

判断单元，用于根据接收的第一应用的鉴权信息和第二应用的标识判断第二应用是否允许第一应用调用其业务能力；

反馈单元，用于如果允许，则通过第二应用向第一应用返回临时会话密钥以便第一应用能够根据接收到的临时会话密钥调用第二应用的业务能力。

在本公开的一些实施例中，所述第一应用的鉴权信息为第一应用的数字签名证书的HASH值。

在本公开的一些实施例中，所述多功能通用智能卡还包括：

存储单元，用于存储被调用应用的标识与一个或多个请求应用的鉴权信息的对应关系。

在本公开的一些实施例中，所述判断单元包括：

匹配子单元，用于将接收的第一应用的鉴权信息和第二应用的标识与预存储的对应关系进行匹配；

确认子单元，用于如果匹配成功，则确认允许第一应用调用第二应用的业务能力。

在本公开的一些实施例中，所述存储单元中存储的对应关系根据需求随时被更新。

根据本公开，还提供了一种移动终端，包括多功能通用智能卡，所述多功能通用智能卡通过OpenMobileAPI与移动终端中的应用交互。

在本公开的技术方案中，由于整个鉴权过程都是在手机内部进行的，未引入鉴权平台，因此避免了资源浪费；同时，由于整个鉴权过程均是在手机内部完成，因此使得整个鉴权过程更安全与稳定。

附图说明

此处所说明的附图用来提供对本公开的进一步理解，构成本申请的一部分。在附图中：

图1是本公开一个实施例的手机应用调用鉴权方法的流程示意图。

图2是本公开应用之间互相调用应用能力的一个实例的示意图。

图3是本公开另一实施例的手机应用调用鉴权方法的流程示意图。

图4是本公开一个实施例的多功能通用智能卡的结构示意图。

图5是本公开一个实施例的移动终端的结构示意图。

具体实施方式

下面将参照附图描述本公开。要注意的是，以下的描述在本质上仅是解释性和示例性的，决不作为对本公开及其应用或使用的任何限制。除非另外特别说明，否则，在实施例中阐述的部件和步骤的相对布置以及数字表达式和数值并不限制本公开的范围。另外，本领域技术人员已知的技术、方法和装置可能不被详细讨论，但在适当的情况下意在成为说明书的一部分。

鉴于现有技术中存在的技术问题，本公开下述实施例通过在现有的UICC(UniversalIntegratedCircuitCard，通用集成电路卡)卡里装载卡应用和关键鉴权数据，以及通过机卡交互接口来实现对手机应用调用的鉴权，可以更安全、稳定且便利地进行手机应用的调用鉴权。

其中，UICC卡是多功能通用智能卡。

关键鉴权数据主要包括终端应用的签名指数的HASH(即，哈希)值及目标应用的AID，即，目标应用标识。

图1是本公开一个实施例的手机应用调用鉴权方法的流程示意图。

如图1所示，该实施例可以包括以下步骤：

S102，响应于手机中的第一应用对第二应用的业务能力的调用请求，接收该调用请求，调用请求中携带第一应用的鉴权信息和第二应用的标识；

具体地，在手机中可以安装多个应用，不同应用之间可能会存在调用需求，例如，会有一个或一些应用具有调用百度地图的请求，为了保证调用的安全性，并非诸如百度地图等被调用的应用一接收到请求就开放其能力，只有通过鉴权的请求才被开放访问应用的能力。

需要指出的是，某个应用可能只对某个或某些应用开放其被调用的能力，因此，需在调用请求中携带第一应用的鉴权信息和第二应用的标识。

S104，根据接收的第一应用的鉴权信息和第二应用的标识判断第二应用是否允许第一应用调用其业务能力；

具体地，在手机的UICC卡内预先存储了各应用的标识与允许调用各应用的鉴权信息之间的对应关系，该对应关系可以为一一对应关系，也可以为一对多的关系，如下述表1所示：

应用标识	被开放调用权限的应用的鉴权信息
		应用1	应用2的鉴权信息
应用2	应用1与应用3的鉴权信息
		…	…
应用n	应用1、应用3与应用n-1的鉴权信息

表1

在接收到第一应用的鉴权信息和第二应用的标识后，与表1中的内容进行匹配，如果匹配成功，则允许第一应用调用第二应用，否则，不允许第一应用调用第二应用。

S106，如果允许，则通过第二应用向第一应用返回临时会话密钥以便第一应用能够根据接收到的临时会话密钥调用第二应用的业务能力，这样可以进一步保证对第二应用调用的安全性。

在该实施例中，由于整个鉴权过程都是在手机内部进行的，未引入鉴权平台，因此避免了资源浪费；同时，由于整个鉴权过程均是在手机内部完成，因此使得整个鉴权过程更安全与稳定。

在一个实例中，第一应用的鉴权信息可以为第一应用的数字签名证书的HASH值，但并不限于此，可以是任何实现鉴权功能的信息。

在又一实例中，在手机内的多功能通用智能卡中预存储被调用应用的标识与一个或多个请求应用的鉴权信息的对应关系，以实现对一个或多个请求应用的鉴权。

在再一实例中，根据将接收的第一应用的鉴权信息和第二应用的标识判断第二应用是否允许第一应用调用其业务能力的步骤可以包括：

将接收的第一应用的鉴权信息和第二应用的标识与预存储的对应关系进行匹配；

如果匹配成功，则确认允许第一应用调用第二应用的业务能力。

需要指出的是，可以根据需求随时更新预存储的对应关系，例如，当某个应用需要变更调用权限时，可以通过卡应用管理平台对这种对应关系进行管理与更新。

上述实施例基于用户卡的手机应用调用鉴权，将关键鉴权数据存储在卡应用安全空间，利用手机与用户卡交互API完成手机应用之间的调用鉴权，提高了各手机应用调用鉴权的安全性，降低了平台鉴权的负担，使得手机应用的基础业务能力开放更加便捷安全。

为了增强手机应用调用鉴权过程的安全性，本公开利用了机卡通信技术。

SIMalliance提出的“OpenMobileAPI”使得手机应用能够访问手机中的各种不同的安全模块，例如，用户手机卡和嵌入式安全模块。

用户卡进行手机应用调用鉴权是以用户手机卡作为一种硬件承载方式装载应用调用鉴权模块，同时将鉴权名单存储在相应卡应用所在的辅助安全域上，具有安全方便的优势。各种应用与用户卡之间的通信可以通过OpenMobileAPI来完成，从而实现整个手机应用的调用鉴权过程。

图2是本公开应用之间互相调用应用能力的一个实例的示意图。

如图2所示，可以通过在现有的UICC卡里装载卡应用和关键鉴权数据，以及机卡交互接口来实现对手机应用调用的鉴权，其中，关键鉴权数据主要包括终端应用的数字签名的HASH值与目标应用的标识。

图3是本公开另一实施例的手机应用调用鉴权方法的流程示意图。

如图3所示，可以包括以下步骤：

(1)手机合法应用1请求调用应用2的业务能力，在该请求中携带应用1的数字签名证书的HASH值与应用2的标识信息；

(2)被请求调用的应用2通过机卡接口访问存在手机卡上安全域(可以是ISD(IssuerSecurityDomain，主安全域)或SSD(SupplementarySecurityDomain，辅助安全域))的鉴权卡应用，鉴权卡应用将接收到的应用1的签名证书的HASH值与预先存储的证书的HASH值的白名单进行比对，以进行访问鉴权；

(3)用户卡卡应用向应用2返回鉴权结果；

(4)如果鉴权通过，则应用2向应用1返回临时会话密钥，应用1使用该临时会话密钥加密调用应用2所开放的相关业务能力。其中，临时会话密钥是用作通信过程中数据的加解密，如果应用1通过鉴权获得了临时会话密钥，那么才可以对应用2发送的加密数据进行解密，也就是说可以使用应用2开放的业务能力了，否则，对于非法应用1，则鉴权不能通过，进而也就不允许非法应用1调用应用2的业务能力。

在整个鉴权过程中，该实施例利用了用户卡的安全特性，全部在用户手机和用户卡之间完成，过程更加安全，同时无需与外部平台进行通信，避免了频繁通信所带来的资源浪费。

本领域普通技术人员可以理解，实现上述方法实施例的全部和部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算设备可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤，而前述的存储介质可以包括ROM、RAM、磁碟和光盘等各种可以存储程序代码的介质。

图4是本公开一个实施例的多功能通用智能卡的结构示意图。

如图4所示，该实施例中的多功能通过智能卡40可以包括接收单元402、判断单元404和反馈单元406。其中，

接收单元402，用于响应于手机中的第一应用对第二应用的业务能力的调用请求，接收该调用请求，调用请求中携带第一应用的鉴权信息和第二应用的标识；

判断单元404，用于根据接收的第一应用的鉴权信息和第二应用的标识判断第二应用是否允许第一应用调用其业务能力；

反馈单元406，用于如果允许，则通过第二应用向第一应用返回临时会话密钥以便第一应用能够根据接收到的临时会话密钥调用第二应用的业务能力。

在该实施例中，由于整个鉴权过程都是在手机内部进行的，未引入鉴权平台，因此避免了资源浪费；同时，由于整个鉴权过程均是在手机内部完成，因此使得整个鉴权过程更安全与稳定。

在一个实施例中，第一应用的鉴权信息可以为第一应用的数字签名证书的HASH值，但并不限于此。

在另一实施例中，多功能通用智能卡还可以包括：

存储单元，用于存储被调用应用的标识与一个或多个请求应用的鉴权信息的对应关系。

在又一实施例中，判断单元可以包括匹配子单元和确认子单元。其中，

匹配子单元，用于将接收的第一应用的鉴权信息和第二应用的标识与预存储的对应关系进行匹配；

确认子单元，用于如果匹配成功，则确认允许第一应用调用第二应用的业务能力。

进一步地，存储单元中存储的对应关系可以根据需求随时被更新。

图5是本公开一个实施例的移动终端的结构示意图。

如图5所示，该实施例中的终端50可以包括多功能通用智能卡502，多功能通用智能卡可以通过OpenMobileAPI与移动终端中的应用交互。其中，多功能通用智能卡502可以通过前述实施例实现。

目前手机内的各应用在互相调用业务能力接口时，存在预置共享密钥较易泄漏、鉴权不足、容易被伪造调用、维护升级集成包版本较困难、采用平台鉴权加大了平台负担浪费资源等问题。

本公开提出了利用用户手机卡中卡应用的安全空间存储有调用权的手机应用签名证书的哈希值，在手机应用调用时用作比对鉴权，当调用者携带自己的应用签名证书申请调用相关业务能力时，被调用应用通过机卡接口与用户卡进行通信，与卡应用安全空间里存储的签名证书的哈希值进行对比，进而返回鉴权结果。如果鉴权通过，则向调用者返回临时会话密钥，供其加密调用相关业务能力。

本说明书中各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同和相似的部分可以相互参见。对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处可以参见方法实施例部分的说明。

虽然已参照示例性实施例描述了本公开，但应理解，本公开不限于上述的示例性实施例。对于本领域技术人员显然的是，可以在不背离本公开的范围和精神的条件下修改上述的示例性实施例。所附的权利要求的范围应被赋予最宽的解释，以包含所有这样的修改以及等同的结构和功能。

Claims (11)

1.一种手机应用调用鉴权方法，其特征在于，包括：

响应于手机中的第一应用对第二应用的业务能力的调用请求，接收该调用请求，所述调用请求中携带第一应用的鉴权信息和第二应用的标识；

根据接收的第一应用的鉴权信息和第二应用的标识判断第二应用是否允许第一应用调用其业务能力；

如果允许，则通过第二应用向第一应用返回临时会话密钥以便第一应用能够根据接收到的临时会话密钥调用第二应用的业务能力。

2.根据权利要求1所述的手机应用调用鉴权方法，其特征在于，所述第一应用的鉴权信息为第一应用的数字签名证书的HASH值。

3.根据权利要求1所述的手机应用调用鉴权方法，其特征在于，所述方法还包括：

在手机内的多功能通用智能卡中预存储被调用应用的标识与一个或多个请求应用的鉴权信息的对应关系。

4.根据权利要求3所述的手机应用调用鉴权方法，其特征在于，根据将接收的第一应用的鉴权信息和第二应用的标识判断第二应用是否允许第一应用调用其业务能力包括：

将接收的第一应用的鉴权信息和第二应用的标识与预存储的对应关系进行匹配；

如果匹配成功，则确认允许第一应用调用第二应用的业务能力。

5.根据权利要求3所述的手机应用调用鉴权方法，其特征在于，根据需求随时更新预存储的对应关系。

6.一种多功能通用智能卡，其特征在于，包括：

接收单元，用于响应于手机中的第一应用对第二应用的业务能力的调用请求，接收该调用请求，所述调用请求中携带第一应用的鉴权信息和第二应用的标识；

判断单元，用于根据接收的第一应用的鉴权信息和第二应用的标识判断第二应用是否允许第一应用调用其业务能力；

反馈单元，用于如果允许，则通过第二应用向第一应用返回临时会话密钥以便第一应用能够根据接收到的临时会话密钥调用第二应用的业务能力。

7.根据权利要求6所述的多功能通用智能卡，其特征在于，所述第一应用的鉴权信息为第一应用的数字签名证书的HASH值。

8.根据权利要求6所述的多功能通用智能卡，其特征在于，所述多功能通用智能卡还包括：

存储单元，用于存储被调用应用的标识与一个或多个请求应用的鉴权信息的对应关系。

9.根据权利要求8所述的多功能通用智能卡，其特征在于，所述判断单元包括：

匹配子单元，用于将接收的第一应用的鉴权信息和第二应用的标识与预存储的对应关系进行匹配；

确认子单元，用于如果匹配成功，则确认允许第一应用调用第二应用的业务能力。

10.根据权利要求8所述的多功能通用智能卡，其特征在于，所述存储单元中存储的对应关系根据需求随时被更新。

11.一种移动终端，其特征在于，包括权利要求6-8中任一项所述的多功能通用智能卡，所述多功能通用智能卡通过OpenMobileAPI与移动终端中的应用交互。