CN104065641A - 用于在应用之间执行认证的方法和装置 - Google Patents

Abstract

提供了一种由客户端装置中的第一应用执行来认证该客户端装置中的第二应用的方法。该方法包括：当第一应用从第二应用接收执行请求时，向认证服务器请求第二应用的认证信息；从认证服务器获得第二应用的认证信息；以及利用认证信息来认证第二应用，其中，第二应用的认证信息用认证服务器的私钥来加以签名。

Description

用于在应用之间执行认证的方法和装置

相关申请的交叉引用

本申请要求2013年3月18日在韩国知识产权局提交的分配序号为10-2013-0028822的韩国专利申请的权益，在此通过引用并入该韩国专利申请的全部公开内容。

技术领域

本公开涉及用于在应用之间准确地执行认证的方法和装置。更具体而言，本公开涉及用于通过从认证服务器接收要认证的应用的认证信息来在应用之间执行认证的方法和装置。

背景技术

可故意调用另一应用的安卓（Android）应用具有这样的优点：可容易地扩展安卓应用的动作并且可迅速开发应用服务。然而，当一应用调用另一应用时，为了维持安全性，作出调用的应用（以下称为主应用）需要认证被调用的应用（以下称为从动应用）并且从动应用需要认证主应用。

相关技术的认证应用的方法的示例包括通过证书授权机构（CertificateAuthority，CA）来交换认证的证书的方法和交换公钥的方法。然而，交换认证的证书的方法有如下缺点：由于CA的介入，成本较高。交换公钥的方法有如下问题：从动应用和主应用都必须具有作为一对的私钥和公钥，并且由于每个应用必须自己保护私钥，所以难以管理私钥并维持安全性。

因此，需要一种用于以低成本在应用之间准确地执行认证的方法和装置。

上述信息只是为了帮助对本公开的理解而作为背景信息给出的。关于上述任何内容就本公开而言是否可适用为现有技术，没有做出判定，也没有做出断言。

发明内容

本公开的各方面要解决至少以上提及的问题和/或缺点并且要提供至少以下所述的优点。从而，本公开的一方面提供了一种用于以低成本在应用之间准确地执行认证的方法和装置。

根据本公开的一方面，提供了一种由客户端装置中的第一应用执行来认证该客户端装置中的第二应用的方法。该方法包括：当第一应用接收到来自第二应用的执行请求时，向认证服务器请求第二应用的认证信息；从认证服务器获得第二应用的认证信息；以及由第一应用利用认证信息来认证第二应用，其中，第二应用的认证信息用认证服务器的私钥来加以签名。

对第二应用的认证可包括：利用认证服务器的公钥来认证第二应用的认证信息；以及把从第二应用的应用包（apk）文件获得的基于哈希的消息认证码（HMAC）值与经认证的认证信息中包括的HMAC值相比较。

对第二应用的认证可包括：根据比较的结果，从第二应用的apk文件和高速缓存存储器的每个中提取第二应用的执行文件，并且把从第二应用的apk文件提取的执行文件与从高速缓存存储器提取的执行文件相比较。

根据对第二应用的认证的结果，该方法还可包括结束第一应用的执行，并且将第一应用的识别信息发送给第二应用，其中，第二应用利用第一应用的识别信息从认证服务器获得第一应用的认证信息，并且其中，在第二应用认证第一应用时，使用所获得的认证信息。

在第二应用认证第一应用之后，该方法还可包括：当第一应用接收到来自第二应用的执行请求时，利用第二应用的认证信息来认证第二应用；以及根据对第二应用的认证的结果，使得第一应用能够执行第二应用所请求的动作。

当第一应用的动作完成时，方法还可包括结束第一应用的执行，并且将第一应用的识别信息和动作结果值发送给第二应用，其中第二应用利用第一应用的认证信息来认证第一应用，并且根据对第一应用的认证的结果，利用动作结果值执行另一动作。

对认证服务器的请求可包括：在第一应用向第二应用发送执行请求之前，向认证服务器请求第二应用的认证信息。

根据本公开的另一方面，提供了一种客户端装置，在该客户端装置中第一应用认证第二应用。该装置包括：应用管理单元，被配置为获得客户端装置中安装的应用的识别信息，并将第二应用的识别信息发送给第一应用；以及存储单元，被配置为存储公钥和签名认证信息，其中，第一应用当接收到来自第二应用的执行请求时，向认证服务器请求第二应用的认证信息，从认证服务器获得第二应用的认证信息，并且利用认证信息来认证第二应用，其中，第二应用向第一应用发送执行请求，并且其中，第二应用的认证信息用认证服务器的私钥来加以签名。

通过以下结合附图公开本公开的各种实施例的详细描述，本领域技术人员将清楚本公开的其他方面、优点和显著特征。

附图说明

通过以下结合附图的描述，本公开的某些实施例的上述和其他方面、特征和优点将会更加清楚，附图中：

图1是示出根据本公开的实施例的由第一应用执行来认证第二应用的方法的流程图；

图2是示出根据本公开的实施例的由第一应用执行来认证第二应用的方法的流程图；

图3是示出根据本公开的实施例的在应用之间执行认证的方法的流程图；

图4是示出根据本公开的实施例的在应用之间执行认证的方法的流程图；

图5是示出根据本公开的实施例的用于在应用之间执行认证的客户端装置的框图；以及

图6是示出根据本公开的实施例的用于在应用之间执行认证的客户端装置的框图。

贯穿各图，应注意相似的标号用于描述相同或相似的元素、特征和结构。

具体实施方式

提供以下参照附图的描述来帮助全面理解如权利要求及其等同物所限定的本公开的各种实施例。描述包括各种具体细节以帮助理解，但这些细节应被视为只是示范性的。因此，本领域普通技术人员将会认识到，在不脱离本公开的范围和精神的情况下，能够对本文描述的各种实施例进行各种改变和修改。此外，为了清楚和简明，可省略对公知的功能和构造的描述。

在以下描述和权利要求中使用的术语和字词不受限于字面含义，而只是被发明人用来使得能够对于本公开有清楚且一致的理解。从而，本领域技术人员应当清楚，提供以下对本公开的各种实施例的描述只是为了说明，而不是为了限制如所附权利要求及其等同物所限定的本公开。

要理解，单数形式“一”和“该”包括复数指代，除非上下文明确地另有规定。从而，例如，对“一组件表面”的提及包括对一个或多个这样的表面的提及。

术语“基本上”是用来意指所记载的特性、参数或值不需要被精确地实现，而是在量上可发生偏离或变动，包括例如容差、测量误差、测量精确度限制和本领域技术人员已知的其他因素，而这些偏离或变动不会妨碍该特性打算提供的效果。

将参照附图来描述本公开，附图中示出了本公开的各种实施例。

图1是示出根据本公开的实施例的由第一应用执行来认证第二应用的方法的流程图。

在图1中，第一应用可以是从动应用，并且第二应用可以是主应用。然而，本实施例不限于此，第一应用也可以是主应用并且第二应用也可以是从动应用。在图1中，主应用可以是调用从动应用并使用从动应用的动作结果值的应用，而从动应用可以是被主应用调用、执行主应用请求执行的动作并且将动作结果值发送给主应用的应用。

参考图1，在操作S101中，当接收到来自第二应用的执行请求时，第一应用可向认证服务器请求第二应用的认证信息。认证服务器可以是基于哈希的消息认证码（Hash-based Message Authentication Code，HMAC）服务器，其存储并管理应用的HMAC值。在此情况下，在根据第二应用的执行请求而执行之前，第一应用可通过将包括第二应用的软件版本和包名称的识别信息发送给认证服务器来向认证服务器请求第二应用的认证信息。

在请求认证信息时发送给认证服务器的包括第二应用的软件版本和包名称的识别信息可在第一应用接收来自第二应用的执行请求时与执行请求一起被第一应用接收到。

在操作S103中，第一应用可接收并获得响应于操作S101中的请求的、来自认证服务器的第二应用的认证信息。一数字签名（其是通过用认证服务器的私钥对认证信息的哈希值加密而获得的值）也可与认证信息一起被接收。从而，从认证服务器接收到了认证信息的第一应用可通过将通过用认证服务器的公钥对该数字签名解密而获得的认证信息的哈希值与从认证服务器接收到的认证信息的哈希值相比较来确定认证信息的HMAC值是否被伪造或被更改。

认证信息可包括HMAC值，该HMAC值可以是从每个应用的应用包（application package，apk）文件生成的。用认证服务器的私钥加密的每个应用的数字签名可通过用认证服务器的私钥对可从每个应用的apk文件生成的HMAC值签名来生成。在此情况下，数字签名可以是通过用认证服务器的私钥对HMAC值的哈希值加密而获得的值。

一旦应用的apk文件被改变，应用的HMAC值也可被改变。从而，第一应用可通过把利用存储在客户端装置中的apk文件生成的HMAC值与从认证服务器接收的HMAC值相比较来认证第二应用。

认证服务器中存储的HMAC值可以是在安装应用的市场中注册的应用的HMAC值。此外，对于根据应用的市场注册请求而通过了审查的应用，在认证服务器中可存储HMAC值。在此情况下，通过了审查的应用的列表可作为白名单被注册在认证服务器中。一般地，HMAC值是用于检测消息在被发送时是否被伪造或更改的值。从而，当请求注册的apk文件被从应用的开发者发送到应用市场时，apk文件的HMAC值也可被发送以便检测apk文件被伪造或更改。HMAC值可根据HMAC生成算法从消息和在消息的接收者与消息的创建者之间共享的密钥值来生成。从而，当与消息相对应的apk文件被改变时，HMAC值也被改变。

利用HMAC值的特性，可通过将认证服务器中存储的认证服务器的白名单中包括的应用的HMAC值与客户端装置中的应用的HMAC值相比较来检测客户端装置中的应用是否被伪造或更改。从而，认证服务器可将apk文件的HMAC值存储为可根据关于应用的软件版本和包名称的信息来识别的认证信息，并可使用该HMAC值来认证应用。

此外，在图1中，即使当存在如图HMAC值那样的根据应用的文件（例如apk文件）而变化的数据生成方法时，也可按与利用HMAC值来检测伪造或更改的方法相同的方式来认证应用。例如，要认证另一应用的应用可通过把在该数据生成方法中生成并存储在服务器中的数据值与在该数据生成方法中从客户端装置的apk文件生成的数据值相比较来检测要认证的应用是否被伪造或更改。

第一应用可利用认证服务器的公钥和以认证服务器的私钥加密的数字签名来认证接收的认证信息。更具体而言，第一应用可通过把通过利用认证服务器的公钥对数字签名解密而获得的认证信息的哈希值与从认证服务器接收的认证信息的哈希值相比较，来认证从认证服务器接收的认证信息。第一应用可通过用数字签名和公钥对认证信息进行认证来认证出认证信息不是伪造或更改的并且发送认证信息的实体是认证服务器。在此情况下，认证服务器的公钥可从认证服务器接收并被第一应用用于对认证信息进行认证。

当用私钥对认证信息签名时，可以按数字签名方法来对认证信息签名。作为附加或逻辑上耦合到要发送的数据的数字信息的数字签名可用于识别签名者并且表明签名者确认数据的内容。可利用非对称加密方法以数字签名生成密钥生成的数字签名可被定义为连续的任意数字、字母、符号等的集合。想要数字签名的订户拥有数字签名生成密钥和数字签名验证密钥作为他/她的数字签名密钥。数字签名生成密钥是订户可使用的私钥，而数字签名验证密钥是当他人验证携带数字签名的数据时使用的公钥。例如，他人可利用公钥来识别签名者并且访问和读取数据，并且私钥可用于在订户将数据发送给他人时将数字签名放在数据上。由于数字签名不对数据本身加密，所以第三方可以没有困难地访问并读取数据的内容。然而，数字签名用于验证被称为数据的创建者的人创建了数据并且数据在被发送/接收时未被伪造或更改，从而使得创建者不可能否认他/她创建了数据。

当不可从认证服务器接收到第二应用的认证信息时，也即，当第二应用未被包括在白名单中，从而认证信息不存在时，第二应用对应于未注册应用，从而不可被认证。

在操作S105中，第一应用可利用从认证服务器接收的认证信息来认证第二应用。第一应用可利用以认证服务器的公钥认证的认证信息来认证客户端装置中的第二应用。在认证第二应用之后，第一应用可根据第二应用的执行请求来执行动作。

即使当第一应用是主应用且第二应用是从动应用时，也可按与参考图1所述相同的方式来执行认证。当第一应用要利用第二应用的动作结果值来执行另一动作时，第一应用可认证第二应用是否安全。在此情况下，在利用认证信息认证第二应用以便验证了第二应用之后，第一应用可向第二应用发送第一应用的执行请求。例如，在获得从动应用的识别信息之后，主应用可认证从动应用并且可以以显式意图向从动应用发送执行请求。

图2是示出根据本公开的实施例的由第一应用在客户端装置中执行来认证第二应用的方法的流程图。

参考图2，在操作S201中，要认证第二应用的第一应用可利用认证服务器的公钥来认证第二应用的认证信息。第一应用可通过用公钥和以私钥加密的认证信息的数字签名对认证信息进行认证，来确认从认证服务器接收的认证信息未被伪造或更改并且发送认证信息的实体是认证服务器。然后，第一应用可使用认证信息来认证第二应用。

在操作S203中，第一应用可从第二应用的apk文件获得要与经认证的认证信息相比较的认证信息。在此情况下，认证信息可包括可从每个应用的apk文件获得的HMAC值。apk文件是在客户端装置中安装应用所需要的应用包文件。执行应用所需要的文件被包括在apk文件中。可从提供应用的apk文件的服务器将apk文件下载到客户端装置以便安装应用。已下载的应用的apk文件可存储在客户端装置中的/data/app文件中。客户端装置可利用下载的apk文件来安装应用。

第一应用可利用存储在客户端装置中的第二应用的apk文件和生成HMAC值所需要的密钥值来根据HMAC生成算法生成第二应用的HMAC值。在此情况下，该密钥值和HMAC生成算法与存储在认证服务器的认证信息中并用于生成HMAC值的密钥值和HMAC生成算法相同。密钥值和HMAC算法可从认证服务器发送到客户端装置并可用于生成HMAC值。

在操作S205中，第一应用把从认证服务器接收的认证信息与利用第二应用的apk文件创建的认证信息相比较。在此情况下，第一应用可以把从第二应用的apk文件获得的HMAC值与从认证服务器接收的认证信息中包括的HMAC值相比较。

在操作S207中，判定HMAC值是否相同。当在操作S207中判定HMAC值不相同时，该方法前进到操作S219。在操作S219中，第二应用未能得到认证。否则，当在操作S207中判定HMAC值相同时，由于第二应用的apk文件与在应用市场中注册的安全性得到验证的apk文件相同，所以可以认证出apk文件未被伪造或更改。在认证apk文件之后，第一应用可继续认证第二应用的执行文件。

用于在客户端装置中执行应用的文件是通过对安卓系统中的apk文件中的classes.dex文件进行优化而获得的优化classes.dex文件。apk文件是用于在客户端装置中安装应用的包文件，而不是在执行应用时执行的文件。优化classes.dex文件可存储在客户端装置的缓存存储器中，例如/data/dalvik-cache/文件夹中，并且当优化classes.dex文件被执行时，应用可被执行。从而，当优化classes.dex文件而不是apk文件被伪造或更改时，仅通过认证apk文件是不可以认证出应用是否被伪造或更改的。

从而，根据本实施例，为了让第一应用准确地检测出第二应用是否被伪造或更改，第一应用不仅需要认证第二应用的apk文件，还需要认证第二应用的执行文件。

在操作S209中，为了认证第二应用的执行文件，第一应用从在操作S207中认证的第二应用的apk文件中提取classes.dex文件。在操作S211中，第一应用可提取优化classes.dex文件，其是存储在客户端装置的高速缓存存储器中的第二应用的执行文件。第一应用可通过对从第二应用的apk文件提取的classes.dex文件进行优化来提取优化classes.dex文件。在操作S213中，第一应用将优化classes.dex文件与在操作S211中提取的优化classes.dex文件相比较。

优化classes.dex文件可包括odex头部、dex头部和优化dex主体。这里，每当产生优化*.dex文件时，就可改变作为幻数的odex头部。从而，第一应用可通过按照除odex头部以外的dex头部和优化dex主体比较两个优化classes.dex文件，来检测第二应用的执行文件是否被伪造或更改。

虽然在图2中优化classes.dex文件被用作基于安卓系统的应用的执行文件，但本实施例不限于此，而认证方法可应用到任何其他用于执行应用的执行文件。例如，可通过把从经认证的apk文件获得的执行文件与存储在高速缓存存储器中的执行文件相比较来认证应用的执行文件是否被伪造或更改。

当在操作S215中判定两个优化classes.dex文件就dex头部和优化dex主体而言相同时，该方法前进到操作S217。在操作S217中，第一应用可最终认证出第二应用未被伪造或更改。否则，当在操作S215中判定两个优化classes.dex文件不相同时，该方法前进到操作S219。在操作S219中，第二应用被判定为被伪造或更改了并且第二应用未能得到认证。

图3是示出根据本公开的实施例的在主应用和从动应用之间执行认证的方法的流程图。

假定主应用调用从动应用，当从动应用被伪造或更改并且具有安全性风险时，从动应用的动作结果值不可被信任，并且当该动作结果值被用于主应用时，会产生安全性问题。从而，在向从动应用发送执行请求之前，需要由主应用执行的认证从动应用的过程。类似地，假定从动应用被主应用调用并且执行所请求的动作，当主应用被伪造或更改并且具有安全性风险时，当从动应用的动作结果值被发送到主应用时，安全性问题可产生。从而，在将动作结果值发送给主应用之前，需要由从动应用执行的认证主应用的过程。

例如，当主应用是销售点（Point-Of-Sales，POS）应用并且从动应用是读卡器配件应用时，移动POS应用可向读卡器配件应用请求关于用来进行支付的卡的信息。在此情况下，当读卡器配件应用被伪造或更改时，移动POS应用可能会以不正确的卡结算信息来进行支付。此外，当移动POS应用被伪造或更改时，由读卡器配件应用获得的卡结算信息可被该移动POS应用泄漏。

从而，为了解决这些问题，将描述根据本公开的实施例在主应用和从动应用之间执行认证的方法。

这里使用的主应用和从动应用可对应于图1和图2的第一应用或第二应用。例如，当第一应用接收到来自第二应用的执行请求时，第一应用和第二应用可分别对应于从动应用和主应用。当第一应用向第二应用发送执行请求时，第一应用和第二应用可分别对应于主应用和从动应用。

参考图3，在操作S301中，执行主应用。在操作S303中，主应用可以以隐式意图请求从动应用的执行。

隐式意图是安卓系统中可使用的包括关于主应用请求执行的动作的信息的消息。从而，安卓系统可分析从主应用发送来的隐式意图以判定哪个应用可执行主应用请求执行的动作，并且可在客户端装置上显示应用的列表以允许用户选择执行该动作的应用。用户选择的应用是本实施例中接收到了主应用的执行请求的从动应用。

然而，当主应用以隐式意图向从动应用发送执行请求时，由于所选择的应用的识别信息未被发送给主应用，所以主应用不可知道哪个应用是从动应用。因此，在没有认证从动应用的过程的情况下，主应用以隐式意图向从动应用发送执行请求。接收到了执行请求的从动应用认证主应用，并且将从动应用的识别信息发送给主应用。主应用可利用该识别信息来认证从动应用，并可将执行请求重发送给从动应用。

从而，为了让从动应用认证主应用，主应用在发送隐式意图时可以也将主应用的识别信息通过安卓系统发送给从动应用。识别信息可包括关于每个应用的软件版本和包名称的信息以便识别应用的认证信息和应用的apk文件。

在操作S305中，在将主应用的识别信息发送给认证服务器时，从动应用可请求主应用的认证信息并接收该认证信息。在此情况下，从动应用还可接收用于对认证信息进行认证的数字签名。认证服务器可以把关于与识别信息中包括的关于主应用的软件版本和包名称的信息相对应的apk文件的认证信息与数字签名一起发送给从动应用。认证信息可包括要认证的每个应用的apk文件的HMAC值。

发送给从动应用的认证信息被存储在客户端装置的存储器中并且以后可被使用。由于该认证信息是用认证服务器的私钥来签名的，从而当认证服务器的私钥未知时该认证信息不会被伪造或更改，所以只要用认证服务器的公钥来认证了认证信息，携带数字签名的认证信息就没有伪造或更改的可能性。这是因为可以用认证服务器的私钥来生成数字签名，并且可以用认证服务器的公钥来对用认证服务器的私钥生成的数字签名进行解密。从而，即使当应用的认证信息和数字签名都被存储在客户端装置的存储器中并且该应用被用于认证同一apk文件时，安全性问题的风险也较低。

在操作S307中，从动应用可利用主应用的认证信息来认证主应用。更具体而言，从动应用可利用认证服务器的公钥和以认证服务器的私钥签名的认证信息的数字签名来判定认证信息是否被伪造或更改。此外，从动应用可通过把从认证服务器接收的认证信息与从主应用的apk文件生成的认证信息相比较来判定apk文件是否被伪造或更改。在本实施例中，签名认证信息指的是携带数字签名的认证信息。从而，可利用认证服务器的公钥来判定签名认证信息是否被伪造或更改。

从动应用可通过把从apk文件提取的优化classes.dex文件与存储在高速缓存存储器中的优化classes.dex文件相比较来判定执行文件是否被伪造或更改，从而来认证主应用。当判定apk文件被伪造或更改时，无需判定执行文件是否被伪造或更改，即可判定主应用未能得到认证。

当认证了主应用未被伪造或更改时，该方法前进到操作S309。在操作S309中，从动应用将从动应用的识别信息发送给主应用。在操作S311中，从动应用的执行结束。从动应用的执行结束的原因是由于从动应用尚未得到认证，所以当从动应用执行主应用请求的动作时，安全性问题可产生。

当接收到从动应用的识别信息时，主应用认证从动应用。在操作S313中，在将从动应用的识别信息发送给认证服务器时主应用可请求并接收从动应用的签名认证信息。认证服务器可向主应用发送与识别信息中包括的关于从动应用的软件版本和包名称的信息相对应的apk文件的签名认证信息。签名认证信息可存储在客户端装置的存储器中并且可用于认证与该apk文件相同的apk文件。

在操作S315中，主应用可利用从动应用的认证信息来认证从动应用。更具体而言，主应用可利用认证服务器的公钥来判定用认证服务器的私钥签名的认证信息是否被伪造或更改，并且可通过将认证信息与从从动应用的apk文件生成的认证信息相比较来判定apk文件是否被伪造或更改。主应用可通过把从从动应用的apk文件提取的优化classes.dex文件与高速缓存存储器中存储的优化classes.dex文件相比较来判定执行文件是否被伪造或更改，从而来完全认证从动应用。当判定apk文件被伪造或更改时，无需判定执行文件是否被伪造或更改，即可判定从动应用被伪造或更改。

在操作S317中，当判定从动应用未被伪造或更改时，主应用可以以显式意图请求从动应用的执行。在此情况下，主应用也可将主应用的识别信息发送给从动应用。

显式意图是安卓系统中可使用的一种消息，该消息不仅包括关于主应用请求执行的动作的信息，而且包括关于要执行该动作的从动应用的信息。从而，主应用可向在操作S303中选择的从动应用请求动作。

在此情况下，主应用还可向从动应用发送从动应用的动作所需要的值，例如支付额信息。此外，主应用可生成作为一对的私钥和公钥，这对私钥和公钥可被一次性使用以便安全地从从动应用接收动作结果值，并且主应用可将该公钥发送给从动应用。从而，从动应用可利用该公钥对动作结果值加密，并且可将动作结果值发送给主应用。用公钥加密的数据可以用私钥来解密。从而，即使当数据泄漏给外部装置时，由于该外部装置不可知道私钥并从而不可对数据解密，因此发送的数据的安全性也可得到维持。由于主应用和从动应用使用的私钥和公钥是一次性使用的，所以当包括动作结果值的数据已被完全发送时，私钥和公钥可被丢弃。

在以显式意图执行的从动应用根据主应用的执行请求而执行动作之前，在操作S319中，从动应用认证主应用。虽然从动应用在操作S307中已经认证了主应用，但由于在主应用被认证之后从动应用结束，所以被以显式意图来重新执行的从动应用需要重新认证主应用。

在操作S319中，从动应用可利用主应用的认证信息来认证主应用。从动应用可利用在操作S305中接收并存储在客户端装置的存储器中的主应用的签名认证信息来认证主应用。更具体而言，从动应用可利用认证服务器的公钥和以认证服务器的私钥加密的认证信息的数字签名来判定认证信息是否被伪造或更改。此外，从动应用可通过将认证信息与从主应用的apk文件生成的认证信息相比较来判定apk文件是否被伪造或更改。从动应用可通过把从apk文件提取的优化classes.dex文件与高速缓存存储器中存储的优化classes.dex文件相比较来判定执行文件是否被伪造或更改，从而来认证主应用。当判定apk文件被伪造或更改时，无需判定执行文件是否被伪造或更改，即可判定主应用被伪造或更改。

当在操作S319中判定主应用未被伪造或更改时，该方法前进到操作S321。在操作S321中，从动应用执行主应用请求的动作。在操作S325中，从动应用将动作结果值发送给主应用。在此情况下，可利用在公钥交换方法中从主应用发送来的公钥对动作结果值加密，然后可将其发送给主应用。在操作S323中，从动应用在将动作结果值发送给主应用之后结束执行。

在操作S327中，从从动应用接收到了动作结果值的主应用可利用该动作结果值来执行另一动作。例如，当动作结果值是关于要用来进行支付的卡的信息时，作为主应用的移动POS应用可利用该卡信息来进行支付。

图4是示出根据本公开的实施例的在应用之间执行认证的方法的流程图。

图3的方法有如下问题：由于从动应用认证主应用两次，所以主应用要花较长的时间才能使用从从动应用接收的动作结果值。

为了解决此问题，在主应用首先认证从动应用之后，主应用可向从动应用发送执行请求。为此，客户端装置还可包括可将从动应用的识别信息发送给主应用的应用管理单元。应用管理单元可获得客户端装置中安装的应用的识别信息并将从动应用的识别信息发送给主应用。此外，应用管理单元可利用关于每个应用可执行的动作的信息来生成可执行主应用所请求的动作的应用的列表。在图4中，主应用和从动应用的认证可被执行一次。

参考图4，在操作S401中，执行主应用。在操作S403中，主应用可选择请求执行的从动应用。更具体而言，主应用可向应用管理单元请求可执行期望的动作的应用的列表。应用管理单元根据该请求生成的应用的列表可被显示在客户端装置中的显示屏幕（未示出）上，并且用户可选择应用。一旦选择了应用，主应用就可从应用管理单元接收所选应用也就是从动应用的识别信息，然后才向从动应用发送执行请求。从而，主应用可利用从动应用的识别信息来认证从动应用，并且可以以显式意图向从动应用发送执行请求。

或者，主应用可向应用管理单元请求客户端装置中安装的每个应用的识别信息。根据该请求，主应用可从应用管理单元接收客户端装置中安装的应用的识别信息。主应用可利用接收到的每个应用的识别信息来生成可执行期望动作的应用的列表。所生成的应用的列表可被显示在客户端装置中的显示屏幕（未示出）上并且一个应用可被用户选择。主应用利用从应用管理单元接收的关于每个应用的识别信息之中的从动应用的识别信息来认证从动应用，并且可以以显式意图向从动应用发送执行请求。

在操作S405中，主应用利用从动应用的识别信息从认证服务器接收签名认证信息。在操作S407中，主应用可认证从动应用。操作S405和S407对应于图3的操作S303和S305，从而将不对其给予重复说明。

当判定从动应用未被伪造或更改时，该方法前进到操作S409。在操作S409中，主应用可以以显式意图向从动应用发送执行请求。在此情况下，主应用还可将主应用的识别信息发送给从动应用。操作S409对应于图3的操作S317，从而将不对其给予重复说明。

在操作S411中，在将主应用的识别信息发送给认证服务器时从动应用可请求并接收主应用的签名认证信息。在操作S413中，从动应用可利用主应用的认证信息来认证主应用。操作S411和S413对应于图3的操作S305和S307或S319，从而将不对其给予重复说明。

当从动应用认证了主应用未被伪造或更改时，该方法前进到操作S415。在操作S415中，从动应用执行主应用请求的动作。在操作S415中，从动应用将动作结果值发送给主应用。在操作S419中，从动应用在将动作结果值发送给主应用之后结束执行。在操作S421中，从从动应用接收到了动作结果值的主应用可利用动作结果值执行另一动作。操作S415至S421对应于图3的操作S321至S327，从而将不对其给予重复说明。

图5是示出根据本公开的实施例的用于在应用之间执行认证的客户端装置的框图。

参考图5，安全性系统可包括认证服务器510和客户端装置520。

认证服务器510可存储认证服务器510的公钥和用认证服务器510的私钥加以数字签名的认证信息，并且可将公钥和认证信息发送给客户端装置520。经数字签名的认证信息是通过用认证服务器510的私钥对认证信息的哈希值加密而生成的信息，并且携带数字签名。从而，可利用认证服务器510的公钥和数字签名来认证经数字签名的认证信息。认证信息和可根据每个应用的软件版本和包名称来识别的apk文件可形成一对并且可被存储在认证服务器510中。认证信息可包括apk文件的HMAC值。

客户端装置520可包括个人计算机（PC）、笔记本计算机、移动电话、平板电脑、导航终端、智能电话、个人数字助理（PDA）、便携式多媒体播放器（PMP）、数字广播接收机，等等。然而，本实施例不限于此，当前开发并常用的或者将来开发来用于通信的任何装置都可用作客户端装置520。

客户端装置520可包括第一应用521、第二应用522和通信单元523。

当接收到来自第二应用522的执行请求时，第一应用521可将包括第二应用522的软件版本和包名称的识别信息发送给认证服务器510，并且可向认证服务器510请求第二应用522的利用认证服务器510的私钥加以签名的认证信息。第一应用521可利用从认证服务器510接收的认证信息来认证第二应用522，并且可根据第二应用522的执行请求来执行动作。

或者，在向第二应用522发送执行请求之前，第一应用521可从认证服务器510接收第二应用522的签名认证信息，并且可利用该认证信息来认证第二应用522。然后，第一应用521可向第二应用522发送执行请求。当从第二应用522接收到动作结果值时，第一应用521可利用动作结果值执行另一动作。

通信单元523支持有线或无线通信，使得客户端装置520可向/从认证服务器510发送/接收数据。

图6是示出根据本公开的实施例的用于在应用之间执行认证的客户端装置的框图。

参考图6，图6的认证服务器610、客户端装置620、第一应用621、第二应用622和通信单元623对应于图5的认证服务器510、客户端装置520、第一应用521、第二应用522和通信单元523，从而将不对其给予重复说明。

客户端装置620还可包括存储单元624、应用管理单元625和输入/输出单元626。

存储单元624可存储从认证服务器610接收的认证服务器610的公钥和签名认证信息，也就是认证信息和认证信息的数字签名。认证信息可包括要认证的每个应用的apk文件的HMAC值。

用于对签名认证信息进行认证的认证服务器610的公钥可用于判定根据数字签名方法签名的认证信息是否被伪造或更改。

可根据每个应用的识别信息来识别认证信息，其中每个应用的识别信息包括关于该应用的软件版本和包名称的信息。可以用与识别信息相对应的认证信息来认证客户端装置620的应用。可将从认证服务器610发送的认证信息存储在存储单元624中，并且可利用存储在存储单元624中的认证信息来认证每个应用。

应用管理单元625可收集关于客户端装置620中的每个应用可执行的动作的动作信息以生成可执行特定动作的应用的列表，或者可将用户选择的应用的识别信息发送给主应用。

接收到来自主应用的要求生成可执行期望动作的应用的列表的请求的应用管理单元625可利用所收集的动作信息生成应用列表。此外，应用管理单元625可将所生成的应用列表和应用列表中包括的应用的识别信息发送给主应用。从而，当用户选择要执行的应用时，主应用可利用所选应用的识别信息来认证该应用。

或者，不是将应用列表和应用列表中包括的应用的识别信息发送给主应用，应用管理单元625而是可控制应用列表被显示在客户端装置620中的显示屏幕（未示出）上以便用户选择要执行的应用。主应用可利用所选应用的识别信息来认证所选应用，即从动应用。

或者，在要调用另一应用的主应用向从动应用发送执行请求之前，客户端装置620的应用管理单元625可发送从动应用的识别信息。从而，主应用可利用从动应用的识别信息来认证从动应用，并可向从动应用发送执行请求。

在图5中，执行了三个认证过程，因为从动应用结束，从而主应用被认证两次。然而，在图6中，可将主应用和从动应用中的每一个认证一次，从而可执行两个认证过程，因而与图5中相比更快速地执行了应用之间的认证。

输入/输出单元626包括接收用户的输入的输入单元和可输出用户界面和处理结果的输出单元。

根据本公开的一个或多个实施例，在安全性不佳的安卓系统中，可通过从认证服务器接收认证信息来判定另一应用是否被伪造或更改，而不必让应用直接管理私钥，也无需认证机构的介入。

此外，根据本公开的一个或多个实施例，当主应用调用从动应用时，通过主应用和从动应用之间的认证可确保信息交换的高可靠性。

本公开的某些方面可实现为非暂态计算机可读记录介质上的计算机可读代码。非暂态计算机可读记录介质是任何可存储以后可被计算机系统读取的数据的数据存储设备。非暂态计算机可读记录介质的示例包括只读存储器（ROM）、随机访问存储器（RAM）、致密盘（CD）-ROM，磁带、软盘和光数据存储设备。非暂态计算机可读记录介质也可分布在由网络耦合的计算机系统上，使得计算机可读代码被以分布方式来存储和执行。此外，本公开所属领域的程序员可容易理解用于实现本公开的功能程序、代码和代码段。

在此，应当注意，如上所述的本公开的各种实施例通常在某种程度上涉及输入数据的处理和输出数据的生成。此输入数据处理和输出数据生成可以用硬件实现或者用软件与硬件结合实现。例如，在移动设备或者类似或相关的电路中可采用特定电子组件来实现与如上所述的本公开的各种实施例相关联的功能。或者，根据存储的指令操作的一个或多个处理器可实现与如上所述的本公开的各种实施例相关联的功能。如果是这样的话，则这种指令可存储在一个或多个非暂态处理器可读介质上，这是在本公开的范围内的。处理器可读介质的示例包括ROM、RAM、CD-ROM、磁带、软盘和光数据存储设备。处理器可读介质也可分布在由网络耦合的计算机系统上，使得指令被以分布方式来存储和执行。此外，本公开所属领域的程序员可容易理解用于实现本公开的功能计算机程序、指令和指令段。

虽然已参考本公开的各种实施例示出和描述了本公开，但本领域技术人员应理解，在不脱离如所附权利要求及其等同物所限定的本公开的精神和范围的情况下，可对本公开进行形式和细节上的各种改变。

Claims (14)

1.一种由客户端装置中的第一应用执行来认证该客户端装置中的第二应用的方法，该方法包括：

当所述第一应用接收到来自所述第二应用的执行请求时，向认证服务器请求所述第二应用的认证信息；

从所述认证服务器获得所述第二应用的认证信息；以及

由所述第一应用利用所述认证信息来认证所述第二应用，

其中，所述第二应用的认证信息用所述认证服务器的私钥来加以签名。

2.如权利要求1所述的方法，其中，对所述第二应用的认证包括：

利用所述认证服务器的公钥来认证所述第二应用的认证信息；以及

把从所述第二应用的应用包（apk）文件获得的基于哈希的消息认证码（HMAC）值与经认证的认证信息中包括的HMAC值相比较。

3.如权利要求2所述的方法，其中，对所述第二应用的认证包括：根据所述比较的结果，从所述第二应用的apk文件以及高速缓存存储器的每个中提取所述第二应用的执行文件，并且把从所述第二应用的apk文件提取的执行文件与从所述高速缓存存储器提取的执行文件相比较。

4.如权利要求1所述的方法，还包括：

根据对所述第二应用的认证的结果，结束所述第一应用的执行；以及

将所述第一应用的识别信息发送给所述第二应用，

其中，所述第二应用利用所述第一应用的识别信息从所述认证服务器获得所述第一应用的认证信息，并且

其中，当所述第二应用认证所述第一应用时，使用所获得的认证信息。

5.如权利要求4所述的方法，其中，在所述第二应用认证所述第一应用之后，所述方法还包括：

当所述第一应用从所述第二应用接收执行请求时，利用所述第二应用的认证信息来认证所述第二应用；以及

根据对所述第二应用的认证的结果，使得所述第一应用能够执行所述第二应用所请求的动作。

6.如权利要求5所述的方法，其中，当所述第一应用的动作完成时，所述方法还包括结束所述第一应用的执行，并且将所述第一应用的识别信息和动作结果值发送给所述第二应用，其中所述第二应用利用所述第一应用的认证信息来认证所述第一应用，并且根据对所述第一应用的认证的结果，利用所述动作结果值执行另一动作。

7.如权利要求1所述的方法，其中，对所述认证服务器的请求包括：在所述第一应用向所述第二应用发送执行请求之前，向所述认证服务器请求所述第二应用的认证信息。

8.一种客户端装置，在该客户端装置中第一应用认证第二应用，该装置包括：

应用管理单元，被配置为获得所述客户端装置中安装的应用的识别信息，并将所述第二应用的识别信息发送给所述第一应用；以及

存储单元，被配置为存储公钥和签名认证信息，

其中，所述第一应用当从所述第二应用接收执行请求时，向认证服务器请求所述第二应用的认证信息，从所述认证服务器获得所述第二应用的认证信息，并且利用所述认证信息来认证所述第二应用，

其中，所述第二应用向所述第一应用发送所述执行请求，以及

其中，所述第二应用的认证信息用所述认证服务器的私钥来加以签名。

9.如权利要求8所述的装置，其中，所述第一应用利用所述认证服务器的公钥来认证所述第二应用的认证信息，并且把从所述第二应用的应用包（apk）文件获得的基于哈希的消息认证码（HMAC）值与经认证的认证信息中包括的HMAC值相比较。

10.如权利要求9所述的装置，其中，所述第一应用根据所述比较的结果，从所述第二应用的apk文件和高速缓存存储器的每个中提取所述第二应用的执行文件，并且把从所述第二应用的apk文件提取的执行文件与从所述高速缓存存储器提取的执行文件相比较。

11.如权利要求8所述的装置，其中，所述第一应用根据对所述第二应用的认证的结果，结束所述第一应用的执行，并且将所述第一应用的识别信息发送给所述第二应用，并且其中，所述第二应用利用所述第一应用的识别信息从所述认证服务器获得所述第一应用的认证信息，并且利用所述认证信息来认证所述第一应用。

12.如权利要求11所述的装置，其中，在所述第二应用认证所述第一应用之后，所述第一应用在接收到来自所述第二应用的执行请求时，利用所述第二应用的认证信息来认证所述第二应用，并且根据所述认证的结果，执行所述第二应用所请求的动作。

13.如权利要求12所述的装置，其中，当所述第一应用的动作完成时，所述第一应用结束执行，并且将所述第一应用的识别信息和动作结果值发送给所述第二应用，并且其中，所述第二应用利用所述第一应用的认证信息来认证所述第一应用，并且根据对所述第一应用的认证的结果，利用所述动作结果值执行另一动作。

14.如权利要求8所述的装置，其中，所述第一应用在向所述第二应用发送执行请求之前向所述认证服务器请求所述第二应用的认证信息。