CN112187709B - 鉴权方法、设备及服务器 - Google Patents

Abstract

本申请实施例提供了一种鉴权方法、设备及服务器，该方法包括：终端设备接收用户输入的初始鉴权请求消息，初始鉴权请求消息用于请求验证终端设备对应用的使用权限。终端设备使用终端设备登录该应用的目标账号的证书，与应用服务器进行鉴权交互，目标账号的证书存储在终端设备的安全元件中。本申请实施例提供的鉴权方法、设备及服务器，应用服务器可以通过终端设备的安全元件中的账号的证书，对该账号进行鉴权，以验证使用终端设备的用户身份是否合法。该鉴权方法能够使应用服务器快速、稳定、安全的对使用终端设备的用户进行身份验证，并且没有现有的身份验证方法存在的局限性。

Description

鉴权方法、设备及服务器

技术领域

本申请实施例涉及通信技术，尤其涉及一种鉴权方法、设备及服务器。

背景技术

随着技术和需求的演进，提出了一种嵌入式通用集成电路卡(embeddeduniversal integrated circuit card，eUICC)，也称为嵌入式用户身份识别模块(embedded subscriber identification module，eSIM)卡。该eUICC是一种可由多个移动网络运营商(mobile network operator，MNO)远程管理签约用户的安全元件，可通过插拔的方式或焊接的方式放入终端设备中，实现终端设备的通信功能。即，eUICC可以是单个芯片形态嵌入在终端设备中，或者，eUICC可以作为终端设备中其他单个芯片的一部分嵌入在终端设备中，或者，eUICC可以是可移动的卡片形态(即SIM卡形态)插入终端设备中。

随着移动互联网的普及，通讯、支付、娱乐等应用风靡终端设备。传统的密码验证，已经难以应对复杂的网络环境。因此，网络安全也成为了行业焦点。目前，用户在终端设备上，使用eUICC上的电话号码登录或注册某一应用时，应用服务器通常采用采用动态口令、生物识别、U盾等方式对该电话号码进行验证，以对使用终端设备的用户进行身份验证。但是，这些验证方式都有其自身的局限性，无法满足用户实际使用时的需求。

因此，用户在终端设备上使用eUICC上的电话号码登录或注册某一应用时，应用服务器如何快速、安全的对用户进行身份验证是一个亟待解决的问题。

发明内容

本申请实施例提供一种鉴权方法、设备及服务器，用于解决用户在终端设备上使用eUICC上的电话号码登录或注册某一应用时，应用服务器如何快速、安全的对用户进行身份验证的技术问题。

第一方面，本申请实施例提供一种鉴权方法，该方法中，终端设备接收用户输入的初始鉴权请求消息，其中，所述初始鉴权请求消息用于请求验证所述终端设备对应用的使用权限。在接收到该初始鉴权请求消息后，所述终端设备可以使用所述终端设备登录所述应用的目标账号的证书，与所述应用服务器进行鉴权交互，所述目标账号的证书存储在所述终端设备的安全元件中。示例性的，所述目标账号为电话号码。

在上述方法中，应用服务器可以通过存储在终端设备的安全元件中的账号的证书，对该账号进行鉴权，以验证使用终端设备的用户身份是否合法。因安全元件能够防止外部恶意解析攻击，保护其上的数据安全。因此，通过存储在终端设备的安全元件中的账号的证书对账号进行鉴权，可以确保鉴权的准确性、安全性、稳定性及鉴权效率，并且没有前述所说的现有的身份验证方法存在的局限性，能够满足用户实际使用时的需求

在本实施例中，终端设备在接收到用户输入的初始鉴权请求消息之后，可以使用存储在所述终端设备的安全元件中的目标账号的证书，与所述应用服务器进行鉴权交互，以使应用服务器验证所述终端设备对应用的使用权限。对于该鉴权交互，包括如下两种鉴权方式：

第一种鉴权方式：应用服务器与终端设备之间采用单向鉴权的方式进行鉴权。

在该实现方式下，所述初始鉴权请求消息包括：所述应用服务器生成的第一随机数。则所述终端设备使用所述终端设备登录所述应用的目标账号的证书，与所述应用服务器进行鉴权交互，包括：所述终端设备向所述应用服务器发送第一鉴权请求消息。其中，所述第一鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第一签名，所述第一签名与所述第一随机数相关。然后，所述终端设备接收来自所述应用服务器响应所述第一鉴权请求消息的鉴权结果。

通过上述单向鉴权的方法，无需对应用服务器进行鉴权，可以快速完成鉴权，提高了鉴权效率。

可选的，所述目标账号的证书的签名数据中携带有所述目标账号的标识。也可以说，目标账号的标识携带在所述目标账号的证书的声明信息中。或者，所述第一鉴权请求消息还包括：所述目标账号的标识，所述第一签名与所述第一随机数和所述目标账号的标识相关。例如，目标账号的标识未携带在所述目标账号的证书的签名数据中(或者说目标账号的标识未携带在所述目标账号的证书的声明信息中)，而是放在使用该目标账号的证书的私钥签名的数据中。通过该方式，可以扩展鉴权方法的应用场景，以及，确保所携带的目标账号的标识的安全性。

第二种鉴权方式：应用服务器与终端设备之间可以采用双向鉴权的方式进行鉴权。

在该实现方式下，所述终端设备使用所述终端设备登录所述目标应用的目标账号的证书，与所述应用服务器进行鉴权交互，包括：

所述终端设备向应用服务器发送第二鉴权请求消息，其中，所述第二鉴权请求消息用于请求所述应用服务器验证应用服务器的证书与所述目标账号的证书是否来自同一根证书。所述第二鉴权请求消息包括：所述目标账号的证书的信息、所述目标账号的标识、所述终端设备生成的第二随机数，所述目标账号的证书的信息用于指示签发所述目标账号的证书的根证书。

所述终端设备接收所述应用服务器在应用服务器的证书与所述目标账号的证书来自同一根证书时发送的第三鉴权请求消息。其中，所述第三鉴权请求消息用于请求所述终端设备对所述应用服务器进行鉴权。所述第三鉴权请求消息包括：所述应用服务器的证书、使用所述应用服务器的证书的私钥签名得到的第二签名，所述第二签名与所述第二随机数和第三随机数相关，所述第三随机数为所述应用服务器生成的。

所述终端设备根据所述第三鉴权请求消息，对所述应用服务器鉴权。例如，所述终端设备使用所述目标账号的证书的根证书，对所述应用服务器的证书进行验证。然后，所述终端设备在所述应用服务器的证书验证通过后，使用所述应用服务器的证书对所述第二签名进行解密，得到所述第二随机数和所述第三随机数。若所述第二随机数未发生变化，则所述终端设备确认所述应用服务器鉴权通过，若所述第二随机数发生变化，则所述终端设备确认所述应用服务器鉴权失败。

在所述应用服务器鉴权通过后，所述终端设备向所述应用服务器发送第四鉴权请求消息。其中，所述第四鉴权请求消息用于请求所述应用服务器对所述目标账号进行鉴权。所述第四鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第三签名；所述第三签名与所述第三随机数相关。

所述终端设备接收来自所述应用服务器响应所述第四鉴权请求消息的鉴权结果。

通过上述双向鉴权的方法，可以进一步地确保鉴权结果的准确性，避免登录恶意应用。

可选的，所述目标账号的证书的签名数据中携带有所述目标账号的标识。也可以说，目标账号的标识携带在所述目标账号的证书的声明信息中。或者，所述第四鉴权请求消息还包括：所述目标账号的标识，所述第三签名与所述第三随机数和所述目标账号的标识相关。例如，目标账号的标识未携带在所述目标账号的证书的签名数据中(或者说目标账号的标识未携带在所述目标账号的证书的声明信息中)，而是放在使用所述目标账号的证书的私钥签名的数据中。通过该方式，可以扩展鉴权方法的应用场景，以及，确保所携带的目标账号的标识的安全性。

作为一种可能的实现方式，所述终端设备根据所述终端设备登录所述应用的目标账号的证书，与所述应用服务器进行鉴权交互之前，所述方法还包括：所述终端设备在用户界面显示至少一个账号。所述终端设备将用户在所述用户界面所选择的账号作为所述目标账号。通过该方式，可以使用户选择安装在安全元件中的多个账号证书对应的账号中的一个来完成身份验证。

作为一种可能的实现方式，所述终端设备上预置有所述目标账号的证书和所述目标账号的证书的父证书，或者，所述方法还包括：所述终端设备接收来自安全服务器的所述目标账号的证书、所述目标账号的证书的私钥和所述目标账号的证书的父证书，所述父证书为所述安全服务器的证书。通过该方式，可以扩展终端设备上的账号的证书的实现方式。

第二方面，本申请实施例提供一种鉴权方法，该方法中，应用服务器基于终端设备登录应用的目标账号的证书，与所述终端设备进行鉴权交互，验证所述终端设备对所述应用的使用权限。示例性的，所述目标账号为电话号码。

该鉴权交互可以包括如下两种鉴权方式：

第一种鉴权方式，应用服务器与终端设备之间采用单向鉴权的方式进行鉴权。

在该实现方式下，所述应用服务器基于终端设备登录目标应用的目标账号的证书，与所述终端设备进行鉴权交互，包括：所述应用服务器接收来自所述终端设备的第一鉴权请求消息。其中，所述第一鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第一签名。所述第一签名与第一随机数相关，所述第一随机数为所述应用服务器生成的随机数。

然后，所述应用服务器根据所述第一鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果，并向所述终端设备发送所述鉴权结果。例如，所述应用服务器对所述目标账号的证书和所述目标账号的证书的父证书进行验证。然后，所述应用服务器在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，使用所述目标账号的证书对所述第一签名进行解密，得到所述第一随机数。若所述第一随机数未发生变化，则所述应用服务器确认所述终端设备鉴权通过。若所述第一随机数发生变化，则所述应用服务器确认所述终端设备鉴权失败。

可选的，所述目标账号的证书的签名数据中携带有所述目标账号的标识。也可以说，目标账号的标识携带在所述目标账号的证书的声明信息中。或者，所述第一鉴权请求消息还包括：所述目标账号的标识，所述第一签名与所述第一随机数和所述目标账号的标识相关。例如，目标账号的标识未携带在所述目标账号的证书的签名数据中(或者说目标账号的标识未携带在所述目标账号的证书的声明信息中)，而是放在使用该目标账号的证书的私钥签名的数据中。

第二种鉴权方式：应用服务器与终端设备之间可以采用双向鉴权的方式进行鉴权。

在该实现方式下，所述应用服务器基于终端设备登录目标应用的目标账号的证书，与所述终端设备进行鉴权交互，包括：

所述应用服务器接收来自所述终端设备的第二鉴权请求消息。其中，所述第二鉴权请求消息用于请求验证应用服务器的证书与所述目标账号的证书是否来自同一根证书。所述第二鉴权请求消息包括：所述目标账号的证书的信息、所述目标账号的标识、所述终端设备生成的第二随机数，所述目标账号的证书的信息用于指示签发所述目标账号的证书的根证书。

所述应用服务器根据所述第二鉴权请求消息，验证所述应用服务器的证书与所述目标账号的证书是否来自同一根证书。若所述应用服务器根据所述第二鉴权请求消息，确定应用服务器的证书与所述目标账号的证书来自同一根证书，则所述应用服务器向所述终端设备发送第三鉴权请求消息。其中，所述第三鉴权请求消息用于请求所述终端设备对所述应用服务器进行鉴权。所述第三鉴权请求消息包括：所述应用服务器的证书、使用所述应用服务器的证书的私钥签名得到的第二签名，所述第二签名与所述第二随机数和第三随机数相关，所述第三随机数为所述应用服务器生成的。

所述应用服务器接收所述终端设备在对所述应用服务器鉴权通过后发送的第四鉴权请求消息。其中，所述第四鉴权请求消息用于请求所述应用服务器对所述目标账号进行鉴权，所述第四鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第三签名，所述第三签名与所述第三随机数相关。

所述应用服务器根据所述第四鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果，并向所述终端设备发送所述鉴权结果。例如，所述应用服务器使用所述应用服务器的证书的根证书，对所述目标账号的证书和所述目标账号的证书的父证书进行验证。所述应用服务器在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，使用所述目标账号的证书对所述第三签名进行解密，得到所述第三随机数，并从所述第四鉴权请求消息中获取所述目标账号的标识。若所述第三随机数未发生变化、且所述第四鉴权请求消息中携带的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识相同，则所述应用服务器确认所述终端设备鉴权通过。若所述第三随机数发生变化，和/或，所述第四鉴权请求消息中携带的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识不同，则所述应用服务器确认所述终端设备鉴权失败。

可选的，所述目标账号的证书的签名数据中携带有所述目标账号的标识。也可以说，目标账号的标识携带在所述目标账号的证书的声明信息中。或者，所述第四鉴权请求消息还包括：所述目标账号的标识，所述第三签名与所述第三随机数和所述目标账号的标识相关。例如，目标账号的标识未携带在所述目标账号的证书的签名数据中(或者说目标账号的标识未携带在所述目标账号的证书的声明信息中)，而是放在使用所述目标账号的证书的私钥签名的数据中。

上述第二方面和第二方面的各可能的实现方式所提供的鉴权方法，其有益效果可以参见上述第一方面和第一方面的各可能的实现方式所带来的有益效果，在此不加赘述。

第三方面，本申请实施例提供一种鉴权方法，该方法中，安全服务器使用所述安全服务器的证书生成目标账号的证书和所述目标账号的证书的私钥。然后，所述安全服务器向终端设备发送所述目标账号的证书、所述目标账号的证书的私钥，以及，所述安全服务器的证书。

上述第三方面所提供的鉴权方法，其有益效果可以参见上述第一方面和第一方面的各可能的实现方式所带来的有益效果，在此不加赘述。

第四方面，本申请实施例提供一种终端设备，所述终端设备包括：收发模块和处理模块。

收发模块，用于接收用户输入的初始鉴权请求消息，所述初始鉴权请求消息用于请求验证所述终端设备对应用的使用权限。

处理模块，用于使用所述终端设备登录所述应用的目标账号的证书，通过所述收发模块与所述应用服务器进行鉴权交互，所述目标账号的证书存储在所述终端设备的安全元件中。示例性的，所述目标账号为电话号码。

该鉴权交互可以包括如下两种鉴权方式：

第一种鉴权方式，应用服务器与终端设备之间采用单向鉴权的方式进行鉴权。

在该实现方式下，所述初始鉴权请求消息包括：所述应用服务器生成的第一随机数。所述处理模块，具体用于通过所述收发模块向所述应用服务器发送第一鉴权请求消息，并接收来自所述应用服务器响应所述第一鉴权请求消息的鉴权结果。其中，所述第一鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第一签名；所述第一签名与所述第一随机数相关。

可选的，所述目标账号的证书的签名数据中携带有所述目标账号的标识。也可以说，目标账号的标识携带在所述目标账号的证书的声明信息中。或者，所述第一鉴权请求消息还包括：所述目标账号的标识，所述第一签名与所述第一随机数和所述目标账号的标识相关。例如，目标账号的标识未携带在所述目标账号的证书的签名数据中(或者说目标账号的标识未携带在所述目标账号的证书的声明信息中)，而是放在使用该目标账号的证书的私钥签名的数据中。

第二种鉴权方式：应用服务器与终端设备之间可以采用双向鉴权的方式进行鉴权。

在该实现方式下，所述处理模块，具体用于：

通过所述收发模块向应用服务器发送第二鉴权请求消息。其中，所述第二鉴权请求消息用于请求所述应用服务器验证应用服务器的证书与所述目标账号的证书是否来自同一根证书。所述第二鉴权请求消息包括：所述目标账号的证书的信息、所述目标账号的标识、所述处理模块生成的第二随机数，所述目标账号的证书的信息用于指示签发所述目标账号的证书的根证书。

通过所述收发模块接收所述应用服务器在应用服务器的证书与所述目标账号的证书来自同一根证书时发送的第三鉴权请求消息。其中，所述第三鉴权请求消息用于请求所述终端设备对所述应用服务器进行鉴权。所述第三鉴权请求消息包括：所述应用服务器的证书、使用所述应用服务器的证书的私钥签名得到的第二签名，所述第二签名与所述第二随机数和第三随机数相关，所述第三随机数为所述应用服务器生成的。

根据所述第三鉴权请求消息，对所述应用服务器鉴权。例如，使用所述目标账号的证书的根证书，对所述应用服务器的证书进行验证。在所述应用服务器的证书验证通过后，使用所述应用服务器的证书对所述第二签名进行解密，得到所述第二随机数和所述第三随机数。若所述第二随机数未发生变化，则确认所述应用服务器鉴权通过。

在所述应用服务器鉴权通过后，通过所述收发模块向所述应用服务器发送第四鉴权请求消息。其中，所述第四鉴权请求消息用于请求所述应用服务器对所述目标账号进行鉴权。所述第四鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第三签名；所述第三签名与所述第三随机数相关。

通过所述收发模块接收来自所述应用服务器响应所述第四鉴权请求消息的鉴权结果。

可选的，所述目标账号的证书的签名数据中携带有所述目标账号的标识。也可以说，目标账号的标识携带在所述目标账号的证书的声明信息中。或者，所述第四鉴权请求消息还包括：所述目标账号的标识，所述第三签名与所述第三随机数和所述目标账号的标识相关。例如，目标账号的标识未携带在所述目标账号的证书的签名数据中(或者说目标账号的标识未携带在所述目标账号的证书的声明信息中)，而是放在使用所述目标账号的证书的私钥签名的数据中。

作为一种可能的实现方式，所述处理模块，还用于在根据所述终端设备登录所述应用的目标账号的证书，通过上述收发模块与所述应用服务器进行鉴权交互之前，在用户界面显示至少一个账号，并将用户在所述用户界面所选择的账号作为所述目标账号。

作为一种可能的实现方式，所述收发模块，还用于接收来自安全服务器的所述目标账号的证书和所述目标账号的证书的父证书，所述父证书为所述安全服务器的证书。

上述第四方面和第四方面的各可能的实现方式所提供的终端设备，其有益效果可以参见上述第一方面和第一方面的各可能的实现方式所带来的有益效果，在此不加赘述。

第五方面，本申请实施例提供了一种服务器，所述服务器为应用服务器，所述应用服务器包括：处理模块。可选的，所述应用服务器还可以包括收发模块。

处理模块，用于基于终端设备登录应用的目标账号的证书，与所述终端设备进行鉴权交互，验证所述终端设备对所述应用的使用权限。示例性的，所述目标账号为电话号码。

该鉴权交互可以包括如下两种鉴权方式：

第一种鉴权方式，应用服务器与终端设备之间采用单向鉴权的方式进行鉴权。

在该实现方式下，所述处理模块，具体用于通过收发模块接收来自所述终端设备的第一鉴权请求消息；根据所述第一鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果，并通过所述收发模块向所述终端设备发送所述鉴权结果。其中，所述第一鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第一签名；所述第一签名与第一随机数相关，所述第一随机数为所述应用服务器生成的随机数。例如，所述处理模块，具体用于对所述目标账号的证书和所述目标账号的证书的父证书进行验证，并在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，使用所述目标账号的证书对所述第一签名进行解密，得到所述第一随机数。若所述第一随机数未发生变化，则确认所述终端设备鉴权通过，若所述第一随机数发生变化，则确认所述终端设备鉴权失败。

可选的，所述目标账号的证书的签名数据中携带有所述目标账号的标识。也可以说，目标账号的标识携带在所述目标账号的证书的声明信息中。或者，所述第一鉴权请求消息还包括：所述目标账号的标识，所述第一签名与所述第一随机数和所述目标账号的标识相关。例如，目标账号的标识未携带在所述目标账号的证书的签名数据中(或者说目标账号的标识未携带在所述目标账号的证书的声明信息中)，而是放在使用该目标账号的证书的私钥签名的数据中。

第二种鉴权方式：应用服务器与终端设备之间可以采用双向鉴权的方式进行鉴权。

在该实现方式下，所述处理模块，具体用于：

通过所述收发模块接收来自所述终端设备的第二鉴权请求消息。其中，所述第二鉴权请求消息用于请求验证应用服务器的证书与所述目标账号的证书是否来自同一根证书。所述第二鉴权请求消息包括：所述目标账号的证书的信息、所述目标账号的标识、所述终端设备生成的第二随机数，所述目标账号的证书的信息用于指示签发所述目标账号的证书的根证书。

根据所述第二鉴权请求消息，验证所述应用服务器的证书与所述目标账号的证书是否来自同一根证书。若根据所述第二鉴权请求消息，确定应用服务器的证书与所述目标账号的证书来自同一根证书，则通过所述收发模块向所述终端设备发送第三鉴权请求消息。其中，所述第三鉴权请求消息用于请求所述终端设备对所述应用服务器进行鉴权。所述第三鉴权请求消息包括：所述应用服务器的证书、使用所述应用服务器的证书的私钥签名得到的第二签名，所述第二签名与所述第二随机数和第三随机数相关，所述第三随机数为所述应用服务器生成的。

通过所述收发模块接收所述终端设备在对所述应用服务器鉴权通过后发送的第四鉴权请求消息。其中，所述第四鉴权请求消息用于请求所述应用服务器对所述目标账号进行鉴权。所述第四鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第三签名；所述第三签名与所述第三随机数相关。

根据所述第四鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果，并通过所述收发模块向所述终端设备发送所述鉴权结果。例如，使用所述应用服务器的证书的根证书，对所述目标账号的证书和所述目标账号的证书的父证书进行验证。在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，使用所述目标账号的证书对所述第三签名进行解密，得到所述第三随机数。从所述第四鉴权请求消息中获取所述目标账号的标识。若所述第三随机数未发生变化、且所述第四鉴权请求消息中携带的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识相同，则确认所述终端设备鉴权通过。若所述第三随机数发生变化，和/或，所述第四鉴权请求消息中携带的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识不同，则确认所述终端设备鉴权失败。

可选的，所述目标账号的证书的签名数据中携带有所述目标账号的标识。也可以说，目标账号的标识携带在所述目标账号的证书的声明信息中。或者，所述第四鉴权请求消息还包括：所述目标账号的标识，所述第三签名与所述第三随机数和所述目标账号的标识相关。例如，目标账号的标识未携带在所述目标账号的证书的签名数据中(或者说目标账号的标识未携带在所述目标账号的证书的声明信息中)，而是放在使用所述目标账号的证书的私钥签名的数据中。

上述第五方面和第五方面的各可能的实现方式所提供的应用服务器，其有益效果可以参见上述第一方面和第一方面的各可能的实现方式所带来的有益效果，在此不加赘述。

第六方面，本申请实施例提供了一种服务器，所述服务器为安全服务器，所述安全服务器包括：处理模块和发送模块。

处理模块，用于使用所述安全服务器的证书生成目标账号的证书和所述目标账号的证书的私钥。

发送模块，用于向终端设备发送所述目标账号的证书、所述目标账号的证书的私钥，以及，所述安全服务器的证书。

上述第六方面所提供的安全服务器，其有益效果可以参见上述第一方面和第一方面的各可能的实现方式所带来的有益效果，在此不加赘述。

第七方面，本申请实施例提供一种终端设备，所述终端设备包括：处理器、存储器、接收器、发送器；所述接收器和所述发送器均耦合至所述处理器，所述处理器控制所述接收器的接收动作，所述处理器控制所述发送器的发送动作；

其中，存储器用于存储计算机可执行程序代码，程序代码包括指令；当处理器执行指令时，指令使所述终端设备执行如第一方面或第一方面的各可能的实现方式所提供的方法。

第八方面，本申请实施例提供一种服务器，所述服务器包括：处理器、存储器；

其中，存储器用于存储计算机可执行程序代码，程序代码包括指令；当处理器执行指令时，指令使所述服务器执行如第二方面或第二方面的各可能的实现方式所提供的方法，或者，执行如第三方面所提供的方法。

第九方面，本申请实施例提供一种通信装置，包括用于执行以上第一方面或第一方面各可能的实现方式所提供的方法的单元、模块或电路。该通信装置可以为终端设备，也可以为应用于终端设备的一个模块，例如，可以为应用于终端设备的芯片。

第十方面，本申请实施例提供一种通信装置，包括用于执行以上第二方面或第二方面各可能的实现方式或第三方面所提供的方法的单元、模块或电路。该通信装置可以为服务器，也可以为应用于服务器的一个模块，例如，可以为应用于服务器的芯片。

第十一方面，本申请实施例提供一种芯片，所述芯片上存储有计算机程序，在所述计算机程序被所述芯片执行时，实现如第一方面或第一方面的各可能的实现方式所提供的方法。

第十二方面，本申请实施例提供一种芯片，所述芯片上存储有计算机程序，在所述计算机程序被所述芯片执行时，实现如第二方面或第二方面的各可能的实现方式所提供的方法。

第十三方面，本申请实施例提供一种芯片，所述芯片上存储有计算机程序，在所述计算机程序被所述芯片执行时，实现如第三方面所提供的方法。

第十四方面，本申请实施例提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面的各种可能的实现方式中的方法。

第十五方面，本申请实施例提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第二方面或第二方面的各种可能的实现方式中的方法。

第十六方面，本申请实施例提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第三方面的方法。

第十七方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面的各种可能的实现方式中的方法。

第十八方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第二方面或第二方面的各可能的实现方式所提供的方法。

第十九方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第三方面所提供的方法。

第二十方面，本申请实施例提供一种通信系统，包括前述所描述的终端设备、应用服务器和安全服务器，其中，终端设备可以执行上述第一方面或第一方面的各种可能的实现方式中的方法，应用服务器可以执行上述第二方面或第二方面的各可能的实现方式所提供的方法，安全服务器可以执行上述第三方面所提供的方法。

本申请实施例提供的鉴权方法、设备及服务器，应用服务器可以通过存储在终端设备的安全元件中的账号的证书，对该账号进行鉴权，以验证使用终端设备的用户身份是否合法。因安全元件能够防止外部恶意解析攻击，保护其上的数据安全。因此，通过存储在终端设备的安全元件中的账号的证书对账号进行鉴权，可以确保鉴权的准确性、安全性、稳定性及鉴权效率，并且没有前述所说的现有的身份验证方法存在的局限性，能够满足用户实际使用时的需求。

附图说明

图1为本申请实施例涉及的eUICC系统架构示意图；

图2为现有的eUICC系统架构中的证书链的示意图；

图3为一种采用短信验证码进行验证的系统架构图；

图4为本申请实施例提供的eUICC系统架构中的证书链的示意图；

图5为本申请实施例提供的一种鉴权方法的流程图；

图6为本申请实施例提供的另一种鉴权方法的流程图；

图7为本申请实施例提供的又一种鉴权方法的流程图；

图8为本申请实施例提供的又一种鉴权方法的流程图；

图9为本申请实施例提供的又一种鉴权方法的流程图；

图10为本申请实施例提供的又一种鉴权方法的流程图；

图11为本申请实施例提供的一种终端设备的结构示意图；

图12为本申请实施例提供的一种服务器的结构示意图；

图13为本申请实施例提供的另一种服务器的结构示意图；

图14为本申请实施例提供的一种终端设备的结构示意图；

图15为本申请实施例提供的又一种服务器的结构示意图。

具体实施方式

用户在使用终端设备时，需要在移动网络运营商(mobile network operator，MNO)处购买用户身份识别模块(subscriber identification module，SIM)卡。该SIM卡存储有MNO提供的用户的签约信息、加密的密钥等，可供MNO对用户进行身份鉴别，以判断用户是否有权使用该运营商提供的通信服务。

随着技术和需求的演进，提出了一种嵌入式通用集成电路卡(embeddeduniversal integrated circuit card，eUICC)，也称为嵌入式SIM(embedded SIM，eSIM)卡。该eUICC是一种可由多个MNO远程管理签约用户的安全元件，可通过插拔的方式或焊接的方式放入终端设备中，实现终端设备的通信功能。即，eUICC可以是单个芯片形态嵌入在终端设备中，或者，eUICC可以作为终端设备中其他单个芯片的一部分嵌入在终端设备中，或者，eUICC可以是可移动的卡片形态(即SIM卡形态)插入终端设备中。

上述eUICC中可以安装有至少一个MNO的电话号码的配置文件(Profile)。其中，每个电话号码对应一个Profile。每个电话号码的Profile可以包括：MNO数据和应用的集合等。这里所说的MNO数据例如可以包括网络接入参数(例如密钥参数Ki)，国际移动用户识别码(international mobile subscriber identity，IMSI)、移动网络运营商安全域(mobilenetwork operator-security domain，MNO-SD)、补充安全域(supplementary securitydomains，SSD)、控制权安全域(controlling authority security domain，CASD)、应用(例如近场通信(near field communication，NFC)应用等)、JAVA卡程序、文件系统中的其他元素以及配置文件元数据等。其中，IMSI和Ki的对应关系用于识别请求网络鉴权的用户的身份。在一些实施例中，Profile也可以叫做签约数据集。

当eUICC安装有多个MNO的电话号码的配置文件(Profile)时，用户可以根据自己需求，激活一个电话号码的配置文件(Profile)。这样，用户可以通过该电话号码实现终端设备的通信功能。

下面结合图1所示的系统架构示意图，对如何为eUICC提供配置文件进行示例说明。图1为本申请实施例涉及的eUICC系统架构示意图。如图1所示，该系统包括：签约管理-数据准备(subscription manager-data preparation，SM-DP)+服务器、MNO服务器、终端设备、CI服务器、eUICC制造商(eUICC manufacturer，EUM)服务器、签约管理发现服务(subscription manager-discovery service，SM-DS)服务器。

其中，SM-DP+服务器，用于根据MNO服务器提供的基本签约信息(例如国际移动用户识别码(international mobile subscriber identity，IMSI)等)，生成该MNO的电话号码的配置文件(Profile)，该Profile可以下载到eUICC上。在一些实施例中，SM-DP+服务器也称为Profile供应商(provisioner)或Profile下载服务器。应理解，在图1所示的系统架构中，可以包括一个或多个SM-DP+服务器，该一个或多个SM-DP+服务器为同一MNO对应的服务器。图1是以一个SM-DP+服务器为例的示意图。

终端设备包括eUICC和本地配置文件助手(local profile assistant，LPA)。LPA可以看作是一个应用程序，是SM-DP+服务器与eUICC之间通信的桥梁。一方面，LPA用于管理Profile的下载。以LPA安装在终端设备上为例，终端设备通过LPA，先从SM-DS服务器获取SM-DP+服务器地址。然后，终端设备通过LPA从SM-DP+服务器地址对应的SM-DP+服务器中获取加密的Profile。终端设备可以将该加密的Profile转发给eUICC。eUICC解密Profile后，将该Profile安装在eUICC中。另一方面，LPA可以提供用户界面(user interface，UI)给用户，以使用户可以通过UI管理eUICC上的Profile。例如，用户可以通过UI激活eUICC上的Profile、去激活eUICC上的Profile、删除eUICC上的Profile等。需要说明是，当终端设备的eUICC从SM-DP+服务器中获取到相应的Profile，并被激活后才可以被终端设备所使用，例如上网、打电话等通信功能。应理解，当eUICC中需要安装多个MNO的电话号码的Profile时，需要从每个MNO对应的SM-DP+服务器中获取该MNO的电话号码的Profile，对此不再赘述。

LPA可以安装在终端设备上，也可以安装在eUICC上。当LPA安装在终端设备时，LPA可以视为一个装置(device)，简称LPAd。作为一种可能的实现方式，LPAd可以包括本地发现服务装置(local discovery service，LDSd)、本地数据下载装置(local data downloaddevice，LPDd)、本地用户界面装置(local user interface，LUId)。其中，LUId用于为用户提供UI，LDSd用于与SM-DS服务器进行交互，LPDd用于与SM-DP+服务器进行交互。

当LPA安装在eUICC上时，可以包括本地发现服务(local discovery service，LDS)、本地数据下载(local data download device，LPD)、本地用户界面(local userinterface，LUI)。其中，LUI用于为用户提供UI，LDS用于与SM-DS服务器进行交互，LPD用于与SM-DP+服务器进行交互。

应理解，本申请实施例所涉及的终端设备也可以称为终端Terminal、用户设备(user equipment，UE)、移动台(mobile station，MS)、移动终端(mobile terminal，MT)等。终端设备可以是手机(mobile phone)、平板电脑(Pad)、带无线收发功能的电脑、虚拟现实(Virtual Reality，VR)终端设备、增强现实(Augmented Reality，AR)终端设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等等。

在全球移动通信系统协会(global system for mobile communicationsassociation，GSMA)的远程SIM卡供应(remote SIM provisioning，RSP)体系中，证书是是必不可少的重要组成部分，主要目的在于进行身份的验证、交互的鉴权。下面结合图2为所示的证书链，对本申请实施例所涉及的系统架构中现有的证书的签发进行说明和介绍。

图2为现有的eUICC系统架构中的证书链的示意图。如图2所示，CI服务器用于签名和颁发(简称：签发)GSMA CI证书(该证书的名称例如可以为CERT.CI.ECDSA)、EUM证书(该证书的名称例如可以为CERT.EUM.ECDSA)、SM-DP+服务器证书、SM-DS服务器证书等。EUM服务器用于为EUM生产的eUICC签名和颁发eUICC证书(该证书的名称例如可以为CERT.EUICC.ECDSA)，并将EUM证书预置在eUICC中。这样，在进行RSP业务时，各个实体之间使用GSMA根证书来相互验证对方证书的合法性。

其中，GSMA CI证书为整个RSP体系的根证书，EUM证书为EUM服务器的证书，该EUM证书由根证书生成。SM-DP+服务器证书由根证书生成，可以包括SM-DP+服务器的验证证书(该证书的名称例如可以为CERT.DPauth.ECDSA)、SM-DP+服务器的传输层安全(transportlayer security，TLS)证书(该证书的名称例如可以为CERT.DP.TLS)和SM-DP+服务器中用于为Profile加密的加密证书(该证书的名称例如可以为CERT.DPpb.ECDSA)。SM-DS服务器证书由根证书生成，可以包括：SM-DS服务器的验证证书(该证书的名称例如可以为CERT.DSauth.ECDSA)、SM-DS服务器的TLS证书(该证书的名称例如可以为CERT.DS.TLS)。

上述图2所示的证书链中，各证书包含公钥和身份信息，证书用于加密，可以对外公开。每个证书具有对应的私钥，私钥用于签名，不对外公开。应理解，上述图2中示出的各证书的名称，以及，各证书的公钥和私钥的名称仅是一种示意，本申请实施例对各证书的名称，以及，各证书的公钥和私钥的名称并不进行限定。

在上述图1所示的系统架构中，SM-DP+服务器与MNO服务器可通过ES2+接口通信，MNO服务器和eUICC之间可通过ES6接口通信，SM-DP+服务器与LPA之间可以通过ES9+接口通信；LPA与eUICC可以通过ES10a、ES10b以及ES10c等接口进行通信；SM-DP+服务器与eUICC之间可以通过ES8+接口进行通信；SM-DP+服务器与SM-DS之间可以通过ES12接口进行通信；SM-DS之间可以通过ES15接口进行通信；SM-DS与LPA可以通过ES11接口进行通信。

随着移动互联网的普及，通讯、支付、娱乐等应用风靡终端设备。传统的密码验证，已经难以应对复杂的网络环境。因此，网络安全也成为了行业焦点。目前，用户在终端设备上，使用eUICC上的电话号码登录或注册某一应用时，应用服务器通常采用如下三种方式对该电话号码进行验证，以对使用终端设备的用户进行身份验证。应理解，这里所说的验证也可以称为对使用终端设备的用户进行鉴权。即，鉴别用户对该应用的使用权限。在本申请实施例中，验证和鉴权的含义等同，本申请实施例对此不进行区分。

第一种方式：应用服务器使用动态口令对使用终端设备的用户进行验证。

动态口令是根据特定的算法生成一个不可预测的随机数字组合，每个密码只能使用一次。当前最广为人知的动态口令是短信验证码。图3为一种采用短信验证码进行验证的系统架构图。如图3所示，该系统架构包括：应用服务器(例如web服务器)、第三方平台服务器、MNO服务器、终端设备。

在用户操作终端设备登录或注册应用时，应用服务器基于短信验证码进行验证的流程如下：

步骤一、应用服务器可以通过例如随机函数生成短信验证码。

步骤二、应用服务器向第三方平台服务器发送该短信验证码。

步骤三、第三方平台服务器向MNO服务器发送请求消息，所述请求消息用于请求向终端设备发送该短信验证码。

步骤四、MNO服务器通过短信向终端设备发送该短信验证码。

步骤五、MNO服务器向第三方平台服务器发送状态码，所述状态码用于指示短信验证码发送成功。

步骤六、第三方平台服务器向应用服务器转发该状态码。

步骤七、应用服务器存储该终端设备与该短信验证码的映射关系。

步骤八、终端设备向应用服务器发送登录请求或注册请求，该登录请求或注册请求携带用户手动输入的短信验证码。

步骤九、应用服务器对比终端设备的登录请求或注册请求中的短信验证码，以及，应用服务器自己存储的终端设备对应的短信验证码是否一致。若一致，则应用服务器确定使用终端设备的用户身份验证通过。若不一致，则应用服务器确定使用终端设备的用户身份验证失败。

应理解，短信验证码一般在应用服务器中只存储预设时长(例如60秒)，超过预设时长后，短信验证码会过期失效，应用服务器会删除该短信验证码。

应用服务器在采用该方式对使用终端设备的用户进行验证时，存在如下问题：

1、短信接收存在时延。

2、操作不便利。原因如下：需要用户手动输入短信验证码。

3、可靠性低。原因如下：短信存在丢失的情况，另外，当终端设备欠费、或者终端设备位于无运营商的网络信号的区域时，终端设备无法接收到短信，进而无法进行验证。

4、安全性较差。原因如下：短信验证码需要第三方平台介入，存在短信嗅探、劫持等问题，容易被病毒、木马从终端设备中获取该短信验证码。

第二种方式：应用服务器通过生物识别，对使用终端设备的用户进行验证。

生物识别是指利用人体固有的生理特性(例如指纹、脸象、虹膜等)和行为特征(例如笔迹、声音、步态等)来进行验证。目前，常见的生物识别有人脸识别和指纹识别。

在应用服务器在采用该方式对使用终端设备的用户进行验证时，存在如下问题：

1、生物特征存在伪造的风险。例如，指纹可以被复制。

2、验证方的问题。即，存在由谁验证的问题。若由应用服务器验证，需要上传生物特征到应用服务器。但是，当前各应用服务器的安全性良莠不齐，存在“盗库”和生物特征被非法使用的风险。若由终端设备自己验证，则应用服务器也无法做到完全信赖终端设备提供的验证结果。

第三种方式：应用服务器通过U盾(USB key)，对使用终端设备的用户进行验证。

USB Key是一种USB接口的硬件设备。它内置单片机或智能卡芯片，有一定的存储空间，可以存储由应用服务器下发的用户的私钥以及数字证书。应用服务器可以利用USBKey内置的公钥算法对用户的身份进行验证。

应用服务器在采用该方式对使用终端设备的用户进行验证时，存在如下问题：

1、使用场景受限。原因如下：因USB Key需要通过USB接口接入终端设备，从而才能使应用服务器利用该USB Key对用户的身份进行验证，因此，该验证方式一般只有在具有雨USB Key匹配的USB接口的个人计算机(personal computer，PC)上使用，无法在无USB Key匹配的USB接口的终端设备(例如手机、PAD等)上使用。

2、USB key是一种独立于终端设备的硬件设备，使用不便利。若用户忘记携带USBkey，则无法进行身份验证。

3、通用性差。原因如下：目前一个USB Key只支持一个应用，即，一个应用一个USBKey，导致USB Key的通用性差。

通过上述描述可以看出，现有的这些身份验证方式都有其自身的局限性，无法满足用户实际使用时的需求。因此，用户在终端设备上使用eUICC上的电话号码登录或注册某一应用时，应用服务器如何快速、安全的对用户进行身份验证是一个亟待解决的问题。

考虑到上述问题，本申请实施例提供了一种鉴权方法，应用服务器可以通过存储在终端设备的安全元件中的账号的证书，对该账号进行鉴权，以验证使用终端设备的用户身份是否合法。因安全元件能够防止外部恶意解析攻击，保护其上的数据安全。因此，通过存储在终端设备的安全元件中的账号的证书对账号进行鉴权，可以确保鉴权的准确性、安全性、稳定性及鉴权效率，并且没有前述所说的现有的身份验证方法存在的局限性，能够满足用户实际使用时的需求。这里所说的账号可以为任一具有Profile的账号，例如：电话号码等。

应理解，本申请实施例提供的鉴权方法，可以适用于应用服务器需要对使用终端设备的用户进行身份验证的任一场景。例如，用户在终端设备上，使用账号登录应用的场景、使用账号注册应用的场景，使用应用的支付功能的场景(此时用户已使用账号登录该应用)等。

上述所说的安全元件(secure element，SE)可以是能够使终端设备实现通信功能的元件，例如，SIM、eUICC等。以eUICC为例，则本申请实施例中所涉及的账号为电话号码。则账号的证书可以为电话号码的Profile证书。

在本实施例中，终端设备的安全元件中的账号的证书可以由安全服务器生成。以安全元件为eUICC、账号为电话号码、账号的证书为电话号码的Profile证书为例，这里所说的安全服务器例如可以为SM-DP+服务器、SM-DP服务器、SM-DS服务器等中任一个。需要说明的是，SM-DP+服务器是SM-DP服务器的演进，在本申请实施例中，SM-DP+服务器与SM-DP服务器等同，本申请实施例对此不进行区分。

终端设备的安全元件中的账号的证书和该证书的私钥可以预置在安全元件中，也可以由安全服务器发送给终端设备的安全元件。例如，安全服务器可以使用所述安全服务器的证书生成目标账号的证书和该目标账号的证书的私钥，并向终端设备发送所述目标账号的证书和该目标账号的证书的私钥，以及，所述安全服务器的证书。相应地，终端设备接收该所述目标账号的证书和该目标账号的证书的私钥，以及，所述安全服务器的证书，并存储在所述终端设备的安全单元中。

下面以安全元件为eUICC、账号为电话号码、安全服务器为SM-DP+服务器、账号的证书为电话号码的Profile证书为例，对安全服务器如何向安全元件签发电话号码的Profile证书进行介绍：

图4为本申请实施例提供的eUICC系统架构中的证书链的示意图。如图4所示，本申请实施例所提供的证书链相比现有技术中的证书链(即图2所示的证书链)，新增了SM-DP+服务器的证书至Profile证书的分支。即，SM-DP+服务器可以根据MNO服务器的需求，使用自己的证书(例如验证证书)为SM-DP+服务器对应的电话号码的Profile生成Profile证书和该Profile证书的私钥，并为该电话号码的Profile签发Profile证书和该Profile证书的私钥。也就是说，MNO服务器控制SM-DP+服务器是否为Profile生成证书和该Profile证书的私钥。

Profile证书的声明信息(也可以称为证书颁发者对证书的签名数据)可以包括该Profile对应的电话号码、IMSI、集成电路卡识别码(integrate circuit card identity，ICCID)、用户的身份标识(identification，ID)等至少一项信息。在本申请实施例中，该至少一项信息可以作为声明Profile的唯一标识符。通过Profile证书的声明信息中声明Profile的唯一标识符，可以建立Profile证书和Profile的一一对应关系。例如，该唯一标识符可以是ICCID、IMSI、用户的ID等至少一项。

作为一种可能的实现方式，Profile证书和该Profile证书的私钥可以由SM-DP+服务器生成该Profile时同步生成，并和SM-DP+服务器的证书、Profile一同下载到eUICC上。例如，将Profile证书和该Profile证书的私钥下载到eUICC上专门用于存储eUICC相关证书的安全域中，或者，将Profile证书和该Profile证书的私钥下载到eUICC上，作为Profile的元数据存储。在该实现方式下，MNO服务器可以通过空中下载技术(over－the－airtechnology，OTA)的形式，对Profile证书进行管理。例如，Profile证书更新、Profile证书删除等管理操作。应理解，上述所说的Profile证书的管理操作，也可以由eUICC系统架构中的其他实体根据MNO服务器的管理需求来实现，例如，SM-DP+服务器、SM-DS服务器等。

作为另一种可能的实现方式，在将Profile下载到eUICC上后，该Profile对应的MNO通过OTA，将Profile证书和该Profile证书的私钥下发到eUICC上。在该场景下，MNO服务器可以通过OTA的形式，对Profile证书进行管理。例如，Profile证书下发、Profile证书更新、Profile证书删除等管理操作。应理解，上述所说的Profile证书的管理操作，也可以由eUICC系统架构中的其他实体根据MNO服务器的管理需求来实现，例如，SM-DP+服务器、SM-DS服务器等。

需要说明的是，当一个电话号码变更了Profile时，可以注销该电话号码旧的Profile证书。当删除eUICC内的一个Profile时，Profile证书可被同步删除，无需单独对Profile证书执行删除操作。应理解，该删除Profile操作可以是由用户通过终端设备的LPA实现的删除操作，还可以是MNO服务器通过OTA执行的删除Profile操作，还可以是SM-DP+服务器远程执行的删除操作。

可选的，在一些实施例中，上述Profile证书内或者终端设备的LPA还可以预置用户的昵称、生日、邮箱等账号信息，以供应用使用。另外，若用户是实名认证用户，则上述Profile证书内还可以预置有用户的身份证等信息。Profile证书内具体预置什么信息可以根据实际使用的需求确定，对此不再赘述。

应理解，上述图4中示出的各证书的名称，以及，各证书的公钥和私钥的名称仅是一种示意，本申请实施例对各证书的名称，以及，各证书的公钥和私钥的名称并不进行限定。另外，图4所示的证书链中，MNO服务器管理Profile证书仅是一种实现方式。具体实现时，可以是由Profile的任意拥有者(即Profile owner)管理Profile证书，本申请实施例对此不再进行赘述。

下面通过一些实施例对应用服务器如何通过存储在终端设备的安全元件中的账号的证书，对该账号进行鉴权进行详细说明。下面这几个实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图5为本申请实施例提供的一种鉴权方法的流程图。如图5所示，该方法包括：

S101、终端设备接收用户输入的初始鉴权请求消息。

其中，所述初始鉴权请求消息用于请求验证所述终端设备对应用的使用权限。该应用为任一可以使用账号进行登录的应用。

以用户登录应用的场景为例，则上述初始鉴权请求消息可以为用户在终端设备的用户界面上，点击应用的登录按钮所生成的初始鉴权请求消息(也可以称为登录请求消息)。以用户注册应用的场景为例，则上述初始鉴权请求消息例如可以为用户在终端设备的用户界面上，点击应用的注册按钮所生成的初始鉴权请求消息(也可以称为注册请求消息)。以用户使用应用的支付功能场景，则上述初始鉴权请求消息可以为用户点击跳转至该应用的支付页面的按钮所生成的初始鉴权请求消息(也可以称为跳转支付页面的请求消息)。

S102、所述终端设备使用所述终端设备登录所述应用的目标账号的证书，与所述应用服务器进行鉴权交互。

即，所述应用服务器基于终端设备登录应用的目标账号的证书，与所述终端设备进行鉴权交互，验证所述终端设备对所述应用的使用权限。

其中，所述目标账号的证书存储在所述终端设备的安全元件中。可选的，若上述终端设备的安全元件中仅存储有一个账号，以及该账号的证书，则该账号即为目标账号。若上述终端设备的安全元件中存储有多个账号，以及，该多个账号的证书，则上述所说的目标账号可以为该多个账号中的任一个。例如，该目标账号可以为终端设备从多个账号中随机选择的一个账号，也可以为用户从多个账号中选择的一个账号。

作为一种可能的实现方式，在步骤S102之前，所述终端设备可以在用户界面显示至少一个账号，并将用户在所述用户界面所选择的账号作为所述目标账号。应理解，该至少一个账号和该至少一个账号的证书均存储在终端设备的安全元件中。示例性的，以安全元件为eUICC为例，则终端设备例如可以通过LPA为用户提供选择目标账号的用户界面，其实现方式可以参见现有技术，对此不再赘述。

在本实施例中，终端设备在接收到用户输入的初始鉴权请求消息之后，可以使用存储在所述终端设备的安全元件中的目标账号的证书，与所述应用服务器进行鉴权交互，以使应用服务器验证所述终端设备对应用的使用权限。对于该鉴权交互，包括如下两种鉴权方式：

第一种鉴权方式：应用服务器与终端设备之间采用单向鉴权的方式进行鉴权。即，应用服务器基于目标账号的证书，对目标账号进行验证，而终端设备无需对应用服务器进行验证。应理解，在使用单向鉴权的方式进行鉴权时，不限定应用服务器上是否存在应用服务器的证书。即便应用服务器上存在应用服务器的证书，也不限定该证书与目标账号是否来自同一根证书。

第二种鉴权方式：应用服务器与终端设备之间可以采用双向鉴权的方式进行鉴权。即，应用服务器基于目标账号的证书，对目标账号进行验证，终端设备基于应用服务器的证书，对应用服务器进行验证。应理解，在使用双向鉴权的方式进行鉴权时，应用服务器上需要有应用服务器的证书，且应用服务器的证书与目标账号的证书来自同一根证书。继续参照图4所示的证书链，以安全元件为eUICC、目标账号为eUICC上的电话号码为例，则应用服务器的证书和该证书的私钥可以由CI服务器签发。

作为一种可能的实现方式，对于使用哪种鉴权方式，可以根据应用服务器是否存在证书确定。例如，当应用服务器上无应用服务器的证书时，可以采用单向鉴权的方式进行鉴权。当应用服务器上存储有应用服务器的证书时，可以选择双向鉴权的方式进行鉴权，也可以选择单向鉴权的方式进行鉴权。示例性的，终端设备与应用服务器在鉴权之前可以进行协商，以确定采用哪种鉴权方式进行鉴权。或者，终端设备与应用服务器在鉴权之前，接收应用服务器发送的指示信息，该指示信息用于指示双方采用哪种鉴权方式进行鉴权。该指示信息例如可以通过指示应用服务器是否有证书来隐式的指示双方采用哪种鉴权方式进行鉴权。该指示信息例如可以通过指示应用服务器有证书来隐式的指示双方采用双向鉴权方式进行鉴权，或者，该指示信息例如可以通过指示应用服务器无证书来隐式的指示双方采用单向鉴权方式进行鉴权。

下面基于上述两种鉴权方式，对终端设备如何使用目标账号的证书，与应用服务器进行鉴权交互进行详细说明。

图6为本申请实施例提供的另一种鉴权方法的流程图。本实施例涉及的是应用服务器与终端设备之间采用单向鉴权的方式进行鉴权的过程。即，应用服务器对终端设备的账号的证书的有效性和合法性进行验证，并通过随机数验证终端设备的账号的证书的私钥，以确定终端设备是否为该证书的合法持有者。

在本实施例中，所述初始鉴权请求消息包括：所述应用服务器生成的第一随机数。该第一随机数可以为所述应用服务器采用预设随机函数生成的随机数。该第一随机数例如可以为双方协商鉴权方式时，应用服务器发送给终端设备的。本申请实施例对第一随机数的长度不进行限定。例如，该第一随机数可以为16字节的随机数。

如图6所示，上述步骤S102可以包括：

S201、所述终端设备向所述应用服务器发送第一鉴权请求消息。

相应地，应用服务器接收该第一鉴权请求消息。其中，所述第一鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第一签名。所述第一签名与所述第一随机数相关。即，第一签名可以为根据该第一随机数得到。示例性的，该第一签名例如可以为使用目标账号的证书的私钥对第一随机数加密得到的签名。或者，该第一签名例如可以为使用目标账号的证书的私钥对第一随机数和其他预设随机数的运算结果进行加密得到的签名。例如，第一随机数和其他预设随机数之和、第一随机数和其他预设随机数之积、第一随机数和其他预设随机数之差等。

以账号为电话号码，安全元件为eUICC、安全服务器为SM-DP+服务器为例，则上述目标账号的证书可以为目标电话号码的Profile证书，目标账号的证书的父证书可以为生成该Profile证书的SM-DP+服务器的证书(例如SM-DP+服务器的验证证书)。

S202、所述应用服务器根据所述第一鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果。

在本步骤中，所述应用服务器可以先对所述目标账号的证书和所述目标账号的证书的父证书进行验证。例如，所述应用服务器可以采用现有的证书链验证证书的方式，对所述目标账号的证书和所述目标账号的证书的父证书进行验证。即，所述应用服务器可以先用根证书验证所述目标账号的证书的父证书的合法性和有效性。若所述目标账号的证书的父证书合法且有效，则所述应用服务器可以使用所述目标账号的证书的父证书，验证所述目标账号的证书的合法性和有效性。若所述目标账号的证书合法且有效，则应用服务器可以确认所述目标账号的证书和所述目标账号的证书的父证书验证通过，否则，应用服务器可以确认所述目标账号的证书和所述目标账号的证书的父证书验证失败。

所述应用服务器在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，可以使用所述目标账号的证书对所述第一签名进行解密，得到所述第一随机数。若解密所得到的第一随机数与所述应用服务器生成的第一随机数相同，即解密得到的第一随机数未发生变化，说明终端设备是该证书的合法持有者，则所述应用服务器确认所述终端设备鉴权通过。若解密所得到的第一随机数与所述应用服务器生成的第一随机数不同，即解密得到的第一随机数发生了变化，说明终端设备不是该证书的合法持有者(即终端设备是该证书的非法持有者)，则所述应用服务器确认所述终端设备鉴权失败。

应理解，这里所说的终端设备鉴权通过可以称为使用终端设备的用户身份验证通过，也可以称为目标账号的鉴权通过。这里所说的终端设备鉴权失败可以称为使用终端设备的用户身份验证失败，也可以称为目标账号的鉴权失败。应理解，这里所说的验证也可以称为对使用终端设备的用户进行鉴权。即，鉴别用户对该应用的使用权限。在本申请实施例中，验证和鉴权的含义等同，本申请实施例对此不进行区分。

在另一可能的实现方式中，所述应用服务器可以先使用所述目标账号的证书对所述第一签名进行解密，得到所述第一随机数。若解密所得到的第一随机数与所述应用服务器生成的第一随机数相同，即解密得到的第一随机数未发生变化，则所述应用服务器进一步地对所述目标账号的证书和所述目标账号的证书的父证书进行验证。若验证通过，则确认所述终端设备鉴权通过。若验证失败，则确认所述终端设备鉴权失败。若解密所得到的第一随机数与所述应用服务器生成的第一随机数不同，即解密得到的第一随机数发生了变化，则所述应用服务器直接确认所述终端设备鉴权失败。

S203、所述应用服务器向所述终端设备发送所述鉴权结果。

相应地，所述终端设备接收所述应用服务器响应所述第一鉴权请求消息的鉴权结果。在该场景下，终端设备可以通过用户界面向用户显示该鉴权结果。

可选的，所述目标账号的证书的签名数据中携带有所述目标账号的标识。该目标账号的标识可以能够唯一的标识该目标账号。以目标账号为电话号码为例，则目标账号的标识例如可以为电话号码本身，也可以为ICCID和/或IMSI等能够转换为电话号码的标识。在该实现方式下，所述应用服务器在对终端设备鉴权通过后，可以从目标账号的证书声明信息中获取该目标账号的标识，进而获取该目标账号。

在另一实现方式中，所述目标账号的证书的签名数据中不携带所述目标账号的标识，而是所述第一鉴权请求消息中携带所述目标账号的标识。即，所述第一鉴权请求消息还包括所述目标账号的标识。则在该实现方式下，所述第一签名可以与所述第一随机数和所述目标账号的标识相关。即，所述第一签名为根据第一随机数和所述目标账号的标识得到的。

例如，第一签名(即signature)可以为signature(第一随机数，目标账号的标识)。则在该实现方式下，所述应用服务器在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，可以使用所述目标账号的证书对所述第一签名进行解密，得到所述第一随机数和目标账号的标识。若解密所得到的第一随机数与所述应用服务器生成的第一随机数相同、且解密所得到的目标账号的标识与第一鉴权请求消息中携带的目标账号的标识相同，即解密得到的第一随机数和目标账号的标识均未发生变化，说明终端设备是该证书的合法持有者，则所述应用服务器确认所述终端设备鉴权通过。若解密所得到的第一随机数与所述应用服务器生成的第一随机数不同，和/或，解密所得到的目标账号的标识与第一鉴权请求消息中携带的目标账号的标识不同，即解密得到的第一随机数和/或目标账号的标识发生了变化，说明终端设备不是该证书的合法持有者(即终端设备是该证书的非法持有者)，则所述应用服务器确认所述终端设备鉴权失败。

或者，所述应用服务器可以使用所述目标账号的证书对所述第一签名进行解密，得到所述第一随机数和目标账号的标识。若解密所得到的第一随机数与所述应用服务器生成的第一随机数相同、且解密所得到的目标账号的标识与第一鉴权请求消息中携带的目标账号的标识相同，即解密得到的第一随机数和目标账号的标识均未发生变化，则所述应用服务器进一步地对所述目标账号的证书和所述目标账号的证书的父证书进行验证。若验证通过，则确认所述终端设备鉴权通过。若验证失败，则确认所述终端设备鉴权失败。若解密所得到的第一随机数与所述应用服务器生成的第一随机数不同，和/或，解密所得到的目标账号的标识与第一鉴权请求消息中携带的目标账号的标识不同，即解密得到的第一随机数和/或目标账号的标识发生了变化，则所述应用服务器直接确认所述终端设备鉴权失败。

在上述实现方式中，应用服务器在对终端设备鉴权通过后，可以从第一鉴权请求消息中获取该目标账号。

所述应用服务器根据所述第一鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果之后，可以向所述终端设备发送所述鉴权结果。

以用户登录应用的场景为例，在所述终端设备鉴权通过时，所述应用服务器可以使用所述目标账号登录所述应用，并向终端设备发送鉴权通过的鉴权结果。在所述终端设备鉴权失败时，所述应用服务器可以拒绝使用所述目标账号登录所述应用，并向终端设备发送鉴权失败的鉴权结果。例如，可以通过登录成功或登录失败来指示该鉴权结果。

以用户注册应用的场景为例，在所述终端设备鉴权通过时，所述应用服务器可以创建所述终端设备登录所述应用的账号(即目标账号)，并向终端设备发送注册成功的鉴权结果。或者，在所述终端设备鉴权通过时，所述应用服务器可以创建所述终端设备登录所述应用的账号(即目标账号)，使用所述目标账号登录所述应用，并向终端设备发送注册和登录成功的鉴权结果。在所述终端设备鉴权失败时，所述应用服务器可以拒绝为所述终端设备创建登录所述应用的账号，并向终端设备发送注册失败的鉴权结果。

以用户使用应用的支付功能场景，在所述终端设备鉴权通过时，所述应用服务器可以向终端设备推送显示该应用的支付页面的数据流，并向终端设备发送验证成功的鉴权结果。在一些实施例中，上述应用服务器也可以不单独发送鉴权结果，而是通过推送显示该应用的支付页面的数据流间接的指示所述终端设备鉴权通过。在所述终端设备鉴权失败时，所述应用服务器可以不向终端设备推送显示该应用的支付页面的数据流，并向终端设备发送验证失败的鉴权结果。

下面以安全元件为eUICC、安全服务器为SM-DP+服务器、账号为电话号码、账号的证书为电话号码的Profile证书、用户使用电话号码登录应用为例，对本申请实施例提供的单向鉴权方法进行示例说明。

下述实施例中，将SM-DP+服务器的证书称为CERT_DP，使用该CERT_DP生成的Profile证书称为CERT_PF，第一随机数为R1。

为了便于理解，下述实施例分别从应用、LPA、eUICC、应用服务器四者交互的角度进行了描述。应理解，上述应用的动作可以是由终端设备的处理器执行所实现的(例如，终端设备的应用处理器)。上述LPA的动作也可以是由终端设备的处理器执行所实现的。在该实现方式下，LPA和eUICC可以位于同一终端设备中，也可以在不同终端设备中，即为同一用户所拥有的不同终端设备。例如，LPA位于用户所拥有的手机中，eUICC位于用户所拥有的可穿戴设备(例如手环)中。当LPA和eUICC位于同一终端设备中时，LPA可以是安装在终端设备上的独立应用，也可以是安装在eUICC上的应用。

示例一、Profile证书的声明信息(即证书颁发者对证书的签名数据)中携带有该profile的电话号码的标识。

图7为本申请实施例提供的又一种鉴权方法的流程图。如图7所示，该方法包括：

S301、应用向LPA发送使用eUICC登录的登录请求消息。

其中，该登录请求消息可以携带有R1。在本示例中，该登录请求消息即为前述所说的初始鉴权请求消息。该登录请求消息可以为用户点击应用的注册或登录按钮所触发的登录请求消息。

可选的，在步骤S301之前，应用在用户点击应用的注册或登录按钮后，与应用服务器协商采用哪种鉴权方式进行鉴权。当双方协商确定采用单向鉴权方式进行鉴权时，应用可以接收到应用服务器发送的R1。

S302、LPA向eUICC发送鉴权申请消息。

其中，该鉴权申请消息可以包括：目标电话号码和R1。其中，该目标电话号码用于登录该应用。

可选的，LPA在向eUICC发送鉴权申请消息之前，可以在用户界面上显示eUICC中的至少一个电话号码，以由用户选择使用哪个电话号码登录该应用。然后，LPA可以将用户在所述用户界面所选择的电话号码作为目标电话号码。

应理解，若LPA和eUICC位于同一终端设备中，且LPA是安装在eUICC上的应用，则上述步骤S301和S302可以被下述步骤替换：

S301’、应用向eUICC发送使用eUICC登录的登录请求消息。其中，该登录请求消息可以携带有R1。

可选的，eUICC在接收到该登录请求消息后，通过运行LPA在用户界面上显示eUICC中的至少一个电话号码，以由用户选择使用哪个电话号码登录该应用。然后，eUICC可以将用户在所述用户界面所选择的电话号码作为目标电话号码。

S303、eUICC向应用发送证书CERT_PF、证书CERT_DP、第一签名。

在本示例中，CERT_PF为目标电话号码对应Profile的证书，第一签名为使用CERT_PF的私钥对R1进行加密得到的signature(R1)。

可以理解，若LPA并非是安装在eUICC上的应用，则eUICC向应用发送证书CERT_PF、证书CERT_DP、第一签名可以是eUICC直接向应用发送证书CERT_PF、证书CERT_DP、第一签名，也可以是eUICC通过LPA向应用发送证书CERT_PF、证书CERT_DP、第一签名，对此不进行限定。

S304、应用向应用服务器发送第一鉴权请求消息。

其中，第一鉴权请求消息包括：证书CERT_PF、证书CERT_DP、第一签名。

S305、应用服务器根据第一鉴权请求消息，对终端设备进行鉴权，得到鉴权结果。

参照图4所示的证书链，应用服务器可以采用现有的证书链验证证书的方式，对证书CERT_PF、证书CERT_DP进行验证。即，所述应用服务器可以从CI服务器获取根证书。然后，所述应用服务器可以使用该根证书，验证SM-DP+服务器的证书CERT_DP的合法性和有效性。若该证书CERT_DP合法且有效，则所述应用服务器可以使用证书CERT_DP验证证书CERT_PF的合法性和有效性。若证书CERT_PF合法且有效，则应用服务器确认证书CERT_PF和证书CERT_DP验证通过，否则，应用服务器可以确认证书CERT_PF和证书CERT_DP验证失败。

所述应用服务器在证书CERT_PF和证书CERT_DP验证通过后，可以使用证书CERT_PF对所述第一签名signature(R1)进行解密，得到R1。若解密所得到的R1与所述应用服务器生成的R1相同，即解密得到的R1未发生变化，说明终端设备是该证书的合法持有者，则所述应用服务器确认所述终端设备鉴权通过。若解密所得到的R1与所述应用服务器生成的R1不同，即解密得到的R1发生了变化，说明终端设备不是该证书的合法持有者(即终端设备是该证书的非法持有者)，则所述应用服务器确认所述终端设备鉴权失败。

S306、应用服务器向应用发送鉴权结果。

在所述终端设备鉴权通过之后，若证书CERT_PF中携带的目标电话号码是第一次登录该应用，则应用服务器使用该目标电话号码为用户创建账号，并登录该应用。在该场景下，应用服务器可以将所创建的账号信息随同鉴权结果一同发送给应用，也可以单独发送给应用，对此不进行限定。此时，该鉴权成功的鉴权结果例如可以为注册成功。在所述终端设备鉴权失败时，所述应用服务器可以拒绝为所述终端设备创建登录所述应用的账号，并返回鉴权失败的鉴权结果(例如注册失败)。

若证书CERT_PF中携带的目标电话号码并非第一次登录该应用，则在所述终端设备鉴权通过之后，应用服务器使用该目标电话号码作为该应用的账号登录该应用，并返回鉴权成功的鉴权结果(例如登录成功)。在所述终端设备鉴权失败时，所述应用服务器可以拒绝使用所述目标电话号码登录所述应用，并返回鉴权失败的鉴权结果(例如登录失败)。

示例二、Profile证书的声明信息(即证书颁发者对证书的签名数据)中没有携带该profile的电话号码的标识。

图8为本申请实施例提供的又一种鉴权方法的流程图。如图8所示，该方法包括：

S401、应用向LPA发送使用eUICC登录的登录请求消息。

其中，该登录请求消息可以携带有R1。在本示例中，该登录请求消息即为前述所说的初始鉴权请求消息。该登录请求消息可以为用户点击应用的注册或登录按钮所触发的登录请求消息。

可选的，在步骤S401之前，应用在用户点击应用的注册或登录按钮后，可以与应用服务器协商采用哪种鉴权方式进行鉴权。当双方协商确定采用单向鉴权方式进行鉴权时，应用可以接收到应用服务器发送的R1。

S402、LPA向eUICC发送鉴权申请消息。

其中，该鉴权申请消息可以包括：目标电话号码和R1。其中，该目标电话号码用于登录该应用。

可选的，LPA在向eUICC发送鉴权申请消息之前，可以在用户界面上显示eUICC中的至少一个电话号码，以由用户选择使用哪个电话号码登录该应用。然后，LPA可以将用户在所述用户界面所选择的电话号码作为目标电话号码。

应理解，若LPA和eUICC位于同一终端设备中，且LPA是安装在eUICC上的应用，则上述步骤S401和S402可以被下述步骤替换：

S401’、应用向eUICC发送使用eUICC登录的登录请求消息。其中，该登录请求消息可以携带有R1。

可选的，eUICC在接收到该登录请求消息后，通过运行LPA在用户界面上显示eUICC中的至少一个电话号码，以由用户选择使用哪个电话号码登录该应用。然后，eUICC可以将用户在所述用户界面所选择的电话号码作为目标电话号码。

S403、eUICC向应用发送证书CERT_PF、证书CERT_DP、目标电话号码的标识PN、第一签名。

在本示例中，CERT_PF为目标电话号码对应Profile的证书，第一签名为使用目标电话号码对应CERT_PF的私钥对R1和PN进行加密得到的signature(R1，PN)。

可以理解，若LPA并非是安装在eUICC上的应用，则eUICC向应用发送证书CERT_PF、证书CERT_DP、第一签名可以是eUICC直接向应用发送证书CERT_PF、证书CERT_DP、PN、第一签名，也可以是eUICC通过LPA向应用发送证书CERT_PF、证书CERT_DP、PN、第一签名，对此不进行限定。

S404、应用向应用服务器发送第一鉴权请求消息。

其中，第一鉴权请求消息包括：证书CERT_PF、证书CERT_DP、PN、第一签名。

S405、应用服务器据第一鉴权请求消息，对终端设备进行鉴权，得到鉴权结果。

参照图4所示的证书链，应用服务器可以采用现有的证书链验证证书的方式，对证书CERT_PF、证书CERT_DP进行验证。即，所述应用服务器可以从CI服务器获取根证书。然后，所述应用服务器可以使用该根证书，验证SM-DP+服务器的证书CERT_DP的合法性和有效性。若该证书CERT_DP合法且有效，则所述应用服务器可以使用证书CERT_DP验证证书CERT_PF的合法性和有效性。若证书CERT_PF合法且有效，则应用服务器确认证书CERT_PF和证书CERT_DP验证通过，否则，应用服务器可以确认证书CERT_PF和证书CERT_DP验证失败。

所述应用服务器在证书CERT_PF和证书CERT_DP验证通过后，可以使用证书CERT_PF对所述第一签名signature(R1、PN)进行解密，得到R1和PN。若解密所得到的R1与所述应用服务器生成的R1相同、且解密所得到的PN与第一鉴权请求消息中携带的PN相同，即解密得到的R1和PN均未发生变化，说明终端设备是该证书的合法持有者，则所述应用服务器确认所述终端设备鉴权通过。若解密所得到的R1与所述应用服务器生成的R1不同，和/或，解密所得到的PN与第一鉴权请求消息中携带的PN不同，即解密得到的R1和/或PN发生了变化，说明终端设备不是该证书的合法持有者(即终端设备是该证书的非法持有者)，则所述应用服务器确认所述终端设备鉴权失败。

S406、应用服务器向应用发送鉴权结果。

在所述终端设备鉴权通过之后，若第一鉴权请求消息中携带的目标电话号码是第一次登录该应用，则应用服务器使用该目标电话号码为用户创建账号，并登录该应用。在该场景下，应用服务器可以将所创建的账号信息随同鉴权结果一同发送给应用，也可以单独发送给应用，对此不进行限定。此时，该鉴权成功的鉴权结果例如可以为注册成功。在所述终端设备鉴权失败时，所述应用服务器可以拒绝为所述终端设备创建登录所述应用的账号，并返回鉴权失败的鉴权结果(例如注册失败)。

若第一鉴权请求消息中携带的目标电话号码并非第一次登录该应用，则在所述终端设备鉴权通过之后，应用服务器使用该目标电话号码作为该应用的账号登录该应用，并返回鉴权成功的鉴权结果(例如登录成功)。在所述终端设备鉴权失败时，所述应用服务器可以拒绝使用所述目标电话号码登录所述应用，并返回鉴权失败的鉴权结果(例如登录失败)。

图9为本申请实施例提供的又一种鉴权方法的流程图。本实施例涉及的是应用服务器与终端设备之间采用双向鉴权的方式进行鉴权的过程。即，应用服务器与终端设备使用根证书完成对方证书的有效性和合法性的验证，并通过随机数验证对方持有的证书的私钥，以确定终端设备是否为该证书的合法持有者。如图9所示，上述步骤S102可以包括：

S501、所述终端设备向应用服务器发送第二鉴权请求消息。

相应地，所述应用服务器接收该第二鉴权请求消息。

其中，所述第二鉴权请求消息用于请求所述应用服务器验证应用服务器的证书与所述目标账号的证书是否来自同一根证书。所述第二鉴权请求消息包括：所述目标账号的证书的信息、所述目标账号的标识、所述终端设备生成的第二随机数。该第二随机数可以为所述终端设备采用预设随机函数生成的随机数。本申请实施例对第二随机数的长度不进行限定。例如，该第二随机数可以为16字节的随机数。所述目标账号的证书的信息用于指示签发所述目标账号的证书的根证书。例如，所述目标账号的证书的信息可以包括所述目标账号的证书的根证书的ID(简称PKID)。关于目标账号的标识的描述可以参见前述实施例。

可选的，在一些实施例中，上述所述目标账号的标识也可以携带在目标账号的证书的信息中。

S502、所述应用服务器根据所述第二鉴权请求消息，验证所述应用服务器的证书与所述目标账号的证书是否来自同一根证书。

所述应用服务器判断所述目标账号的证书的信息所指示的根证书，与所述应用服务器的证书的根证书是否相同。若相同，则确定所述应用服务器的证书与所述目标账号的证书来自同一根证书。若不同，则确定所述应用服务器的证书与所述目标账号的证书不是来自同一根证书。

以所述目标账号的证书的信息包括所述目标账号的证书的根证书的ID(简称PKID)，则应用服务器可以判断第二鉴权请求消息中携带的PKID，与应用服务器的证书的根证书的ID是否相同。若是，说明所述目标账号的证书的信息所指示的根证书，与所述应用服务器的证书的根证书相同，则确定所述应用服务器的证书与所述目标账号的证书来自同一根证书。若不同，说明所述目标账号的证书的信息所指示的根证书，与所述应用服务器的证书的根证书不同，则确定所述应用服务器的证书与所述目标账号的证书不是来自同一根证书。

应理解，若所述应用服务器的证书与所述目标账号的证书来自同一根证书，则应用服务器与终端设备才可以使用根证书对对方的证书进行验证，则执行后续步骤S503，以通过第三鉴权请求消息请求终端设备对应用服务器的证书进行验证。若所述应用服务器的证书与所述目标账号的证书不是来自同一根证书，则应用服务器与终端设备无法使用根证书对对方的证书进行验证，则所述应用服务器可以向终端设备发送鉴权失败的鉴权结果。

S503、所述应用服务器在确定应用服务器的证书与所述目标账号的证书来自同一根证书时，向所述终端设备发送第三鉴权请求消息。

相应地，所述终端设备接收该第三鉴权请求消息。

其中，所述第三鉴权请求消息用于请求所述终端设备对所述应用服务器进行鉴权，所述第三鉴权请求消息包括：所述应用服务器的证书、使用所述应用服务器的证书的私钥签名得到的第二签名。

所述第二签名与所述第二随机数和第三随机数相关。即，第二签名可以为根据该第二随机数和第三随机数得到。例如，第二签名(即signature)可以为使用所述应用服务器的证书的私钥对该第二随机数和第三随机数加密得到的signature(第二随机数，第三随机数)。所述第三随机数为所述应用服务器生成的。该第三随机数可以为所述应用服务器采用预设随机函数生成的随机数。本申请实施例对第三随机数的长度不进行限定。例如，该第三随机数可以为16字节的随机数。

S504、所述终端设备根据所述第三鉴权请求消息，对所述应用服务器鉴权。

在本步骤中，所述终端设备可以使用所述目标账号的证书的根证书，先对所述应用服务器的证书进行验证。例如，所述终端设备可以采用现有的证书链验证证书的方式，使用所述目标账号的证书的根证书，先对所述应用服务器的证书进行验证，对此不再赘述。

所述终端设备在所述应用服务器的证书验证通过后，可以使用所述应用服务器的证书对所述第二签名进行解密，得到所述第二随机数和第三随机数。若解密所得到的第二随机数与所述终端设备生成的第二随机数相同，即解密得到的第二随机数未发生变化，说明应用服务器是该证书的合法持有者，则所述终端设备确认所述应用服务器鉴权通过。若解密所得到的第二随机数与所述终端设备生成的第二随机数不同，即解密得到的第二随机数发生了变化，说明应用服务器不是该证书的合法持有者(即应用服务器是该证书的非法持有者)，则所述终端设备确认所述应用服务器鉴权失败。

应理解，这里所说的应用服务器鉴权通过可以称为使用应用服务器的身份验证通过。这里所说的应用服务器鉴权失败可以称为使用应用服务器的身份验证失败。在本申请实施例中，验证和鉴权的含义等同，本申请实施例对此不进行区分。

在另一可能的实现方式中，上述终端设备也可以先使用所述应用服务器的证书对所述第二签名进行解密，得到所述第二随机数和第三随机数。若解密所得到的第二随机数与所述终端设备生成的第二随机数相同，即解密得到的第二随机数未发生变化，则所述终端设备进一步使用所述目标账号的证书的根证书，对所述应用服务器的证书进行验证。若验证通过，则确认所述应用服务器鉴权通过。若验证失败，则确认所述应用服务器鉴权失败。若解密所得到的第二随机数与所述终端设备生成的第二随机数不同，即解密得到的第二随机数发生了变化，则所述终端设备直接确认所述应用服务器鉴权失败。

S505、所述终端设备在所述应用服务器鉴权通过后，向所述应用服务器发送第四鉴权请求消息。

即，在终端设备验证完应用服务器的证书之后，可以通过第四鉴权请求消息请求应用服务器对终端设备进行验证。相应地，应用服务器接收该第四鉴权请求消息。其中，所述第四鉴权请求消息用于请求所述应用服务器对所述目标账号进行鉴权，所述第四鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第三签名。

所述第三签名与所述第三随机数相关。即，第三签名可以为根据该第三随机数得到。示例性的，该第三签名例如可以为使用目标账号的证书的私钥对第三随机数加密得到的签名。或者，该第三签名例如可以为使用目标账号的证书的私钥对第三随机数和其他预设随机数的运算结果进行加密得到的签名。例如，第三随机数和其他预设随机数之和、第三随机数和其他预设随机数之积、第三随机数和其他预设随机数之差等。

以账号为电话号码，安全元件为eUICC、安全服务器为SM-DP+服务器为例，则上述目标账号的证书可以为目标电话号码的Profile证书，目标账号的证书的父证书可以为生成该Profile证书的SM-DP+服务器的证书。

S506、所述应用服务器根据所述第四鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果。

在本步骤中，所述应用服务器可以使用所述应用服务器的证书的根证书，对所述目标账号的证书和所述目标账号的证书的父证书进行验证。例如，所述应用服务器可以采用现有的证书链验证证书的方式，使用所述应用服务器的证书的根证书，先对所述目标账号的证书和所述目标账号的证书的父证书进行验证，对此不再赘述。

所述目标账号的证书的签名数据中携带有所述目标账号的标识。该目标账号的标识可以能够唯一的标识该目标账号。以目标账号为电话号码为例，则目标账号的标识例如可以为电话号码，也可以为ICCID和/或IMSI等能够转换为电话号码的标识。在该实现方式下，所述应用服务器可以从目标账号的证书中获取该目标账号的标识，进而获取该目标账号。

或者，所述目标账号的证书的签名数据中不携带所述目标账号的标识，而是所述第四鉴权请求消息中携带所述目标账号的标识。即，所述第四鉴权请求消息还包括所述目标账号的标识。则在该实现方式下，所述第三签名可以与所述第三随机数和所述目标账号的标识相关。即，所述第三签名为根据第三随机数和所述目标账号的标识得到的。例如，第三签名(即signature)可以为使用目标账号的证书的私钥对第三随机数和目标账号的标识进行加密得到的signature(第三随机数，目标账号的标识)。则在该实现方式下，所述应用服务器在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，可以使用所述目标账号的证书对所述第三签名进行解密，得到所述目标账号的标识。

所述应用服务器在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，可以使用所述目标账号的证书对所述第三签名进行解密，得到所述第三随机数。若解密所得到的第三随机数与所述应用服务器生成的第三随机数相同、且从所述第四鉴权请求消息中获取到的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识相同，即解密得到的第三随机数未发生变化(说明终端设备是该证书的合法持有者)、目标账号的标识也未发生变化，则所述应用服务器确认所述终端设备鉴权通过。若解密所得到的第三随机数与所述应用服务器生成的第三随机数不同，和/或、从所述第四鉴权请求消息中获取到的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识不同，即解密得到的第三随机数发生了变化(说明终端设备不是该证书的合法持有者(即终端设备是该证书的非法持有者))和/或目标账号的标识发生了变化，则所述应用服务器确认所述终端设备鉴权失败。

应理解，这里所说的终端设备鉴权通过可以称为使用终端设备的用户身份验证通过，也可以称为目标账号的鉴权通过。这里所说的终端设备鉴权失败可以称为使用终端设备的用户身份验证失败，也可以称为目标账号的鉴权失败。应理解，这里所说的验证也可以称为对使用终端设备的用户进行鉴权。即，鉴别用户对该应用的使用权限。在本申请实施例中，验证和鉴权的含义等同，本申请实施例对此不进行区分。

在另一可能的实现方式中，所述应用服务器可以先使用所述目标账号的证书对所述第三签名进行解密，得到所述第三随机数。若解密所得到的第三随机数与所述应用服务器生成的第三随机数相同、且从所述第四鉴权请求消息中获取到的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识相同，即解密得到的第三随机数未发生变化、目标账号的标识也未发生变化，则所述应用服务器进一步地对所述目标账号的证书和所述目标账号的证书的父证书进行验证。若验证通过，则确认所述终端设备鉴权通过。若验证失败，则确认所述终端设备鉴权失败。若解密所得到的第三随机数与所述应用服务器生成的第三随机数不同，和/或、从所述第四鉴权请求消息中获取到的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识不同，即解密得到的第三随机数和/或目标账号的标识发生了变化，则所述应用服务器直接确认所述终端设备鉴权失败。

S507、所述应用服务器向所述终端设备发送鉴权结果。

相应地，所述终端设备接收来自所述应用服务器响应所述第四鉴权请求消息的鉴权结果。在该场景下，终端设备可以通过用户界面向用户显示该鉴权结果。

以用户登录应用的场景为例，在所述终端设备鉴权通过时，所述应用服务器可以使用所述目标账号登录所述应用，并向终端设备发送鉴权通过的鉴权结果。在所述终端设备鉴权失败时，所述应用服务器可以拒绝使用所述目标账号登录所述应用，并向终端设备发送鉴权失败的鉴权结果。例如，可以通过登录成功或登录失败来指示该鉴权结果。

以用户注册应用的场景为例，在所述终端设备鉴权通过时，所述应用服务器可以创建所述终端设备登录所述应用的账号(即目标账号)，并向终端设备发送注册成功的鉴权结果。或者，在所述终端设备鉴权通过时，所述应用服务器可以创建所述终端设备登录所述应用的账号(即目标账号)，使用所述目标账号登录所述应用，并向终端设备发送注册和登录成功的鉴权结果。在所述终端设备鉴权失败时，所述应用服务器可以拒绝为所述终端设备创建登录所述应用的账号，并向终端设备发送注册失败的鉴权结果。

以用户使用应用的支付功能场景，在所述终端设备鉴权通过时，所述应用服务器可以向终端设备推送显示该应用的支付页面的数据流，并向终端设备发送验证成功的鉴权结果。在一些实施例中，上述应用服务器也可以不单独发送鉴权结果，而是通过推送显示该应用的支付页面的数据流间接的指示所述终端设备鉴权通过。在所述终端设备鉴权失败时，所述应用服务器可以不向终端设备推送显示该应用的支付页面的数据流，并向终端设备发送验证失败的鉴权结果。

下面以安全元件为eUICC、安全服务器为SM-DP+服务器、账号为电话号码、账号的证书为电话号码的Profile证书、用户使用电话号码登录应用为例，对本申请实施例提供的双向鉴权方法进行示例说明。

下述实施例中，将SM-DP+服务器的证书称为CERT_DP，使用该CERT_DP生成的Profile证书称为CERT_PF，应用服务器的证书为CERT_SP，第二随机数为R2、第三随机数为R3。

为了便于理解，下述实施例分别从应用、LPA、eUICC、应用服务器四者交互的角度进行了描述。应理解，上述应用的动作可以是由终端设备的处理器执行所实现的(例如，终端设备的应用处理器)。上述LPA的动作也可以是由终端设备的处理器执行所实现的。在该实现方式下，LPA和eUICC可以位于同一终端设备中，也可以在不同终端设备中，即为同一用户所拥有的不同终端设备。例如，LPA位于用户所拥有的手机中，eUICC位于用户所拥有的可穿戴设备(例如手环)中。当LPA和eUICC位于同一终端设备中时，LPA可以是安装在终端设备上的独立应用，也可以是安装在eUICC上的应用。

图10为本申请实施例提供的又一种鉴权方法的流程图。如图10所示，该方法包括：

S601、应用向LPA发送使用eUICC登录的登录请求消息。

在本示例中，该登录请求消息即为前述所说的初始鉴权请求消息。该登录请求消息可以为用户点击应用的注册或登录按钮所触发的登录请求消息。

可选的，在步骤S601之前，应用在用户点击应用的注册或登录按钮后，与应用服务器协商采用哪种鉴权方式进行鉴权。在本示例中，双方协商确定采用双向鉴权方式进行鉴权。

S602、LPA向eUICC发送获取请求消息。

其中，所述获取请求消息用于请求获取目标电话号码对应的Profile证书的信息(简称：CERT_PF信息)。其中，CERT_PF信息包括签发CERT_PF的根证书PKID和目标电话号码的标识。

可选的，LPA在向eUICC发送获取请求之前，可以在用户界面上显示eUICC中的至少一个电话号码，以由用户选择使用哪个电话号码登录该应用。然后，LPA可以将用户在所述用户界面所选择的电话号码作为目标电话号码。

应理解，若LPA和eUICC位于同一终端设备中，且LPA是安装在eUICC上的应用，则上述步骤S601和S602可以被下述步骤替换：

S601’、应用向eUICC发送使用eUICC登录的登录请求消息。

可选的，eUICC在接收到该登录请求消息后，通过运行LPA在用户界面上显示eUICC中的至少一个电话号码，以由用户选择使用哪个电话号码登录该应用。然后，eUICC可以将用户在所述用户界面所选择的电话号码作为目标电话号码。

S603、eUICC向应用发送目标电话号码的CERT_PF信息、第二随机数R2。

可以理解，若LPA并非是安装在eUICC上的应用，则eUICC向应用发送CERT_PF信息和第二随机数R2可以是eUICC直接向应用发送，也可以是eUICC通过LPA向应用发送，对此不进行限定。

该第二随机数R2可以为所述终端设备采用预设随机函数生成的随机数。本申请实施例对第二随机数R2的长度不进行限定。例如，该第二随机数R2可以为16字节的随机数。

S604、应用向应用服务器发送第二鉴权请求消息。

其中，第二鉴权请求消息包括：CERT_PF信息、目标电话号码的标识和R2。

S605、应用服务器根据CERT_PF信息，验证CERT_SP与CERT_PF是否来自同一根证书。

应用服务器可以判断第二鉴权请求消息中CERT_PF信息所携带的PKID，与应用服务器的证书CERT_SP的根证书的ID是否相同。若是，说明CERT_PF信息所指示的根证书，与CERT_SP的根证书相同，则确定CERT_SP与CERT_PF来自同一根证书。若不同，说明所述CERT_PF信息所指示的根证书，与CERT_SP的根证书不同，则确定CERT_SP与CERT_PF不是来自同一根证书。

应理解，若CERT_SP与CERT_PF来自同一根证书，则应用服务器与终端设备才可以使用根证书对对方的证书进行验证，则执行后续步骤S606，以通过第三鉴权请求消息请求终端设备对CERT_SP进行验证。若CERT_SP与CERT_PF不是来自同一根证书，则应用服务器与终端设备无法使用根证书对对方的证书进行验证，则所述应用服务器可以向终端设备发送鉴权失败的鉴权结果。

S606、所述应用服务器在CERT_SP与CERT_PF来自同一根证书时，向eUICC发送第三鉴权请求消息。

其中，第三鉴权请求消息包括：应用服务器的证书CERT_SP、第二签名。在本示例中，第二签名为使用CERT_SP的私钥对R2和R3进行加密得到的signature(R2，R3)。

该第三随机数R3可以为所述应用服务器采用预设随机函数生成的随机数。本申请实施例对第三随机数R3的长度不进行限定。例如，该第三随机数R3可以为16字节的随机数。

可以理解，所述应用服务器向eUICC发送第三鉴权请求消息可以是所述应用服务器向应用发送该第三鉴权请求消息，应用通过LPA将该第三鉴权请求消息转发给eUICC。

S607、所述eUICC根据所述第三鉴权请求消息，对所述应用服务器鉴权。

在本步骤中，所述eUICC可以使用CERT_PF的根证书，先对所述应用服务器的证书CERT_SP进行验证。例如，所述eUICC可以采用现有的证书链验证证书的方式，使用CERT_PF的根证书，先对所述应用服务器的证书CERT_SP进行验证，对此不再赘述。

所述eUICC在所述应用服务器的证书CERT_SP验证通过后，可以使用所述应用服务器的证书CERT_SP对所述第二签名进行解密，得到所述第二随机数R2和第三随机数R3。若解密所得到的第二随机数R2与所述eUICC生成的第二随机数R2相同，即解密得到的第二随机数R2未发生变化，说明应用服务器是该证书的合法持有者，则所述eUICC确认所述应用服务器鉴权通过。若解密所得到的第二随机数R2与所述eUICC生成的第二随机数R2不同，即解密得到的第二随机数R2发生了变化，说明应用服务器不是该证书的合法持有者(即应用服务器是该证书的非法持有者)，则所述eUICC确认所述应用服务器鉴权失败。

应理解，若所述eUICC确认所述应用服务器鉴权通过，则eUICC进一步向应用服务器发送第四鉴权请求消息，以请求应用服务器对eUICC的目标电话号码的Profile证书进行验证，则执行后续步骤S608。若所述eUICC确认所述应用服务器鉴权失败，则流程结束。此时，终端设备例如可以在用户界面显示应用非法等提示信息。

S608、eUICC在应用服务器鉴权通过时，向所述应用服务器发送第四鉴权请求消息。

其中，所述第四鉴权请求消息包括：CERT_PF、CERT_DP、使用CERT_PF签名得到的第三签名。在本示例中，第三签名为使用CERT_PF的私钥对从第二签名解密得到的R3进行加密得到的signature(R3)。

S609、所述应用服务器根据所述第四鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果。

在本步骤中，所述应用服务器可以使用所述应用服务器的证书CERT_SP的根证书，对CERT_DP、CERT_PF进行验证。例如，所述应用服务器可以采用现有的证书链验证证书的方式，使用所述应用服务器的证书CERT_SP的根证书，先对CERT_DP、CERT_PF进行验证，对此不再赘述。

所述应用服务器在CERT_DP、CERT_PF验证通过后，可以使用CERT_PF对所述第三签名进行解密，得到所述第三随机数R3。若解密所得到的第三随机数R3与所述应用服务器生成的第三随机数R3相同、且所述第四鉴权请求消息中携带的所述目标电话号码的标识与所述第二鉴权请求消息中携带的所述目标电话号码的标识相同，即解密得到的第三随机数R3未发生变化(说明终端设备是该证书的合法持有者)、目标电话号码的标识也未发生变化，则所述应用服务器确认所述终端设备鉴权通过。若解密所得到的第三随机数R3与所述应用服务器生成的第三随机数R3不同，和/或、所述第四鉴权请求消息中携带的所述目标电话号码的标识与所述第二鉴权请求消息中携带的所述目标电话号码的标识不同，即解密得到的第三随机数R3发生了变化(说明终端设备不是该证书的合法持有者(即终端设备是该证书的非法持有者))和/或目标电话号码的标识发生了变化，则所述应用服务器确认所述终端设备鉴权失败。

上述所说的所述第四鉴权请求消息中携带的所述目标电话号码的标识可以是：CERT_PF的签名数据中携带有所述目标电话号码的标识，所述目标电话号码的标识存储在所述终端设备的eUICC中。该目标电话号码的标识可以能够唯一的标识该目标电话号码，例如可以为电话号码，也可以为ICCID和/或IMSI等能够转换为电话号码的标识。在该实现方式下，所述应用服务器可以从CERT_PF中获取该目标电话号码的标识，进而获取该目标电话号码。

在另一实现方式中，所述CERT_PF的签名数据中不携带所述目标电话号码的标识，而是所述第四鉴权请求消息中携带所述目标电话号码的标识。即，所述第四鉴权请求消息还包括所述目标电话号码的标识。则在该实现方式下，所述第三签名为根据第三随机数R3得到的，或者，所述第三签名与所述第三随机数R3和所述目标电话号码的标识相关。即，所述第三签名为根据第三随机数和所述目标电话号码的标识得到的。例如，第三签名(即signature)可以为使用所述CERT_PF的私钥对第三随机数R3和目标电话号码的标识进行加密得到的signature(第三随机数R3，目标电话号码的标识)。则在该实现方式下，所述应用服务器在CERT_DP、CERT_PF验证通过后，可以使用CERT_PF对所述第三签名进行解密，得到所述目标电话号码的标识，进而获取该目标电话号码。

S610、所述应用服务器向应用发送鉴权结果。

在该场景下，终端设备可以通过用户界面向用户显示该鉴权结果。

在所述终端设备鉴权通过之后，若目标电话号码是第一次登录该应用，则应用服务器使用该目标电话号码为用户创建账号，并登录该应用。在该场景下，应用服务器可以将所创建的账号信息随同鉴权结果一同发送给应用，也可以单独发送给应用，对此不进行限定。此时，该鉴权成功的鉴权结果例如可以为注册成功。在所述终端设备鉴权失败时，所述应用服务器可以拒绝为所述终端设备创建登录所述应用的账号，并返回鉴权失败的鉴权结果(例如注册失败)。

若目标电话号码并非第一次登录该应用，则在所述终端设备鉴权通过之后，应用服务器使用该目标电话号码作为该应用的账号登录该应用，并返回鉴权成功的鉴权结果(例如登录成功)。在所述终端设备鉴权失败时，所述应用服务器可以拒绝使用所述目标电话号码登录所述应用，并返回鉴权失败的鉴权结果(例如登录失败)。

本申请实施例提供额鉴权方法，应用服务器可以通过存储在终端设备的安全元件中的账号的证书，对该账号进行鉴权，以验证使用终端设备的用户身份是否合法。因安全元件能够防止外部恶意解析攻击，保护其上的数据安全。因此，通过存储在终端设备的安全元件中的账号的证书对账号进行鉴权，可以确保鉴权的准确性、安全性、稳定性及鉴权效率，并且没有前述所说的现有的身份验证方法存在的局限性，能够满足用户实际使用时的需求。下面以安全元件为eUICC、账号为电话号码为例，通过表1，来对本申请实施例提供的鉴权方法不存在现有的身份验证方法存在的局限性进行说明：

表1

图11为本申请实施例提供的一种终端设备的结构示意图。如图11所示，所述终端设备包括：收发模块11和处理模块12。其中，

收发模块11，用于接收用户输入的初始鉴权请求消息，所述初始鉴权请求消息用于请求验证所述终端设备对应用的使用权限。

处理模块12，用于使用所述终端设备登录所述应用的目标账号的证书，通过所述收发模块11与所述应用服务器进行鉴权交互，所述目标账号的证书存储在所述终端设备的安全元件中。示例性的，所述目标账号为电话号码。

该鉴权交互可以包括如下两种鉴权方式：

第一种鉴权方式，应用服务器与终端设备之间采用单向鉴权的方式进行鉴权。

在该实现方式下，所述初始鉴权请求消息包括：所述应用服务器生成的第一随机数。所述处理模块12，具体用于通过所述收发模块11向所述应用服务器发送第一鉴权请求消息，并接收来自所述应用服务器响应所述第一鉴权请求消息的鉴权结果。其中，所述第一鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第一签名；所述第一签名与所述第一随机数相关。

可选的，所述目标账号的证书的签名数据中携带有所述目标账号的标识。也可以说，目标账号的标识携带在所述目标账号的证书的声明信息中。或者，所述第一鉴权请求消息还包括：所述目标账号的标识，所述第一签名与所述第一随机数和所述目标账号的标识相关。例如，目标账号的标识未携带在所述目标账号的证书的签名数据中(或者说目标账号的标识未携带在所述目标账号的证书的声明信息中)，而是放在使用该目标账号的证书的私钥签名的数据中。

第二种鉴权方式：应用服务器与终端设备之间可以采用双向鉴权的方式进行鉴权。

在该实现方式下，所述处理模块12，具体用于：

通过所述收发模块11向应用服务器发送第二鉴权请求消息。其中，所述第二鉴权请求消息用于请求所述应用服务器验证应用服务器的证书与所述目标账号的证书是否来自同一根证书。所述第二鉴权请求消息包括：所述目标账号的证书的信息、所述目标账号的标识、所述处理模块12生成的第二随机数，所述目标账号的证书的信息用于指示签发所述目标账号的证书的根证书。

通过所述收发模块11接收所述应用服务器在应用服务器的证书与所述目标账号的证书来自同一根证书时发送的第三鉴权请求消息。其中，所述第三鉴权请求消息用于请求所述终端设备对所述应用服务器进行鉴权。所述第三鉴权请求消息包括：所述应用服务器的证书、使用所述应用服务器的证书的私钥签名得到的第二签名，所述第二签名与所述第二随机数和第三随机数相关，所述第三随机数为所述应用服务器生成的。

根据所述第三鉴权请求消息，对所述应用服务器鉴权。例如，使用所述目标账号的证书的根证书，对所述应用服务器的证书进行验证。在所述应用服务器的证书验证通过后，使用所述应用服务器的证书对所述第二签名进行解密，得到所述第二随机数和所述第三随机数。若所述第二随机数未发生变化，则确认所述应用服务器鉴权通过。

在所述应用服务器鉴权通过后，通过所述收发模块11向所述应用服务器发送第四鉴权请求消息。其中，所述第四鉴权请求消息用于请求所述应用服务器对所述目标账号进行鉴权。所述第四鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第三签名；所述第三签名与所述第三随机数相关。

通过所述收发模块11接收来自所述应用服务器响应所述第四鉴权请求消息的鉴权结果。

可选的，所述目标账号的证书的签名数据中携带有所述目标账号的标识。也可以说，目标账号的标识携带在所述目标账号的证书的声明信息中。或者，所述第四鉴权请求消息还包括：所述目标账号的标识，所述第三签名与所述第三随机数和所述目标账号的标识相关。例如，目标账号的标识未携带在所述目标账号的证书的签名数据中(或者说目标账号的标识未携带在所述目标账号的证书的声明信息中)，而是放在使用所述目标账号的证书的私钥签名的数据中。

作为一种可能的实现方式，所述处理模块12，还用于在根据所述终端设备登录所述应用的目标账号的证书，通过上述收发模块11与所述应用服务器进行鉴权交互之前，在用户界面显示至少一个账号，并将用户在所述用户界面所选择的账号作为所述目标账号。

作为一种可能的实现方式，所述收发模块11，还用于接收来自安全服务器的所述目标账号的证书、所述目标账号的证书的私钥和所述目标账号的证书的父证书，所述父证书为所述安全服务器的证书。

本申请实施例提供的终端设备，可以执行上述方法实施例中终端设备的动作，其实现原理和技术效果类似，在此不再赘述。

图12为本申请实施例提供的一种服务器的结构示意图。如图12所示，所述服务器为应用服务器，所述应用服务器包括：处理模块21。可选的，所述应用服务器还可以包括收发模块22。

处理模块21，用于基于终端设备登录应用的目标账号的证书，与所述终端设备进行鉴权交互，验证所述终端设备对所述应用的使用权限。示例性的，所述目标账号为电话号码。

该鉴权交互可以包括如下两种鉴权方式：

第一种鉴权方式，应用服务器与终端设备之间采用单向鉴权的方式进行鉴权。

在该实现方式下，所述处理模块21，具体用于通过收发模块22接收来自所述终端设备的第一鉴权请求消息；根据所述第一鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果，并通过所述收发模块22向所述终端设备发送所述鉴权结果。其中，所述第一鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第一签名；所述第一签名与第一随机数相关，所述第一随机数为所述应用服务器生成的随机数。例如，所述处理模块21，具体用于对所述目标账号的证书和所述目标账号的证书的父证书进行验证，并在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，使用所述目标账号的证书对所述第一签名进行解密，得到所述第一随机数。若所述第一随机数未发生变化，则确认所述终端设备鉴权通过，若所述第一随机数发生变化，则确认所述终端设备鉴权失败。

可选的，所述目标账号的证书的签名数据中携带有所述目标账号的标识。也可以说，目标账号的标识携带在所述目标账号的证书的声明信息中。或者，所述第一鉴权请求消息还包括：所述目标账号的标识，所述第一签名与所述第一随机数和所述目标账号的标识相关。例如，目标账号的标识未携带在所述目标账号的证书的签名数据中(或者说目标账号的标识未携带在所述目标账号的证书的声明信息中)，而是放在使用该目标账号的证书的私钥签名的数据中。

第二种鉴权方式：应用服务器与终端设备之间可以采用双向鉴权的方式进行鉴权。

在该实现方式下，所述处理模块21，具体用于：

通过所述收发模块22接收来自所述终端设备的第二鉴权请求消息。其中，所述第二鉴权请求消息用于请求验证应用服务器的证书与所述目标账号的证书是否来自同一根证书。所述第二鉴权请求消息包括：所述目标账号的证书的信息、所述目标账号的标识、所述终端设备生成的第二随机数，所述目标账号的证书的信息用于指示签发所述目标账号的证书的根证书。

根据所述第二鉴权请求消息，验证所述应用服务器的证书与所述目标账号的证书是否来自同一根证书。若根据所述第二鉴权请求消息，确定应用服务器的证书与所述目标账号的证书来自同一根证书，则通过所述收发模块22向所述终端设备发送第三鉴权请求消息。其中，所述第三鉴权请求消息用于请求所述终端设备对所述应用服务器进行鉴权。所述第三鉴权请求消息包括：所述应用服务器的证书、使用所述应用服务器的证书的私钥签名得到的第二签名，所述第二签名与所述第二随机数和第三随机数相关，所述第三随机数为所述应用服务器生成的。

通过所述收发模块22接收所述终端设备在对所述应用服务器鉴权通过后发送的第四鉴权请求消息。其中，所述第四鉴权请求消息用于请求所述应用服务器对所述目标账号进行鉴权。所述第四鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第三签名；所述第三签名与所述第三随机数相关。

根据所述第四鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果，并通过所述收发模块22向所述终端设备发送所述鉴权结果。例如，使用所述应用服务器的证书的根证书，对所述目标账号的证书和所述目标账号的证书的父证书进行验证。在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，使用所述目标账号的证书对所述第三签名进行解密，得到所述第三随机数。从所述第四鉴权请求消息中获取所述目标账号的标识。若所述第三随机数未发生变化、且所述第四鉴权请求消息中携带的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识相同，则确认所述终端设备鉴权通过。若所述第三随机数发生变化，和/或，所述第四鉴权请求消息中携带的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识不同，则确认所述终端设备鉴权失败。

可选的，所述目标账号的证书的签名数据中携带有所述目标账号的标识。也可以说，目标账号的标识携带在所述目标账号的证书的声明信息中。或者，所述第四鉴权请求消息还包括：所述目标账号的标识，所述第三签名与所述第三随机数和所述目标账号的标识相关。例如，目标账号的标识未携带在所述目标账号的证书的签名数据中(或者说目标账号的标识未携带在所述目标账号的证书的声明信息中)，而是放在使用所述目标账号的证书的私钥签名的数据中。

本申请实施例提供的应用服务器，可以执行上述方法实施例中应用服务器的动作，其实现原理和技术效果类似，在此不再赘述。

图13为本申请实施例提供的另一种服务器的结构示意图。如图13所示，所述服务器为安全服务器，所述安全服务器包括：处理模块31和发送模块32。其中，

处理模块31，用于使用所述安全服务器的证书生成目标账号的证书和所述目标账号的证书的私钥。

发送模块32，用于向终端设备发送所述目标账号的证书、所述目标账号的证书的私钥，以及，所述安全服务器的证书。

本申请实施例提供的安全服务器，可以执行上述方法实施例中安全服务器的动作，其实现原理和技术效果类似，在此不再赘述。

需要说明的是，应理解以上收发模块实际实现时可以为收发器或通信接口、发送模块实际实现时可以为发送器或通信接口。而处理模块可以以软件通过处理元件调用的形式实现；也可以以硬件的形式实现。例如，处理模块可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上处理模块的功能。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个专用集成电路(application specific integrated circuit，ASIC)，或，一个或多个微处理器(digital signal processor，DSP)，或，一个或者多个现场可编程门阵列(field programmable gate array，FPGA)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(centralprocessing unit，CPU)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，SOC)的形式实现。

图14为本申请实施例提供的一种终端设备的结构示意图。如图14所示，该终端设备可以包括：处理器41(例如CPU)、存储器42、接收器43、发送器44；接收器43和发送器44均耦合至处理器41，处理器41控制接收器43的接收动作、处理器41控制发送器44的发送动作；存储器42可能包含高速随机存取存储器(random-access memory，RAM)，也可能还包括非易失性存储器(non-volatile memory，NVM)，例如至少一个磁盘存储器，存储器42中可以存储各种指令，以用于完成各种处理功能以及实现本申请的方法步骤。可选的，本申请涉及的终端设备还可以包括：电源45、通信总线46以及通信端口47。接收器43和发送器44可以集成在终端设备的收发信机中，也可以为终端设备上独立的收发天线。通信总线46用于实现元件之间的通信连接。上述通信端口47用于实现终端设备与其他外设之间进行连接通信。

在本申请实施例中，上述存储器42用于存储计算机可执行程序代码，程序代码包括指令；当处理器41执行指令时，指令使终端设备的处理器41执行上述方法实施例中终端设备的处理动作，使接收器43执行上述方法实施例中终端设备的接收动作，使发送器44执行上述方法实施例中终端设备的发送动作，其实现原理和技术效果类似，在此不再赘述。

图15为本申请实施例提供的又一种服务器的结构示意图。如图15所示，该服务器可以包括：至少一个处理器51和存储器52。图15示出的是以一个处理器为例的服务器，其中，

存储器52，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器52可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

作为一种可能的实现方式，处理器51用于执行所述存储器52存储的计算机执行指令，以实现上述实施例中的鉴权方法中的应用服务器的动作，其实现原理和技术效果类似，在此不再赘述。

作为另一种可能的实现方式，处理器51用于执行所述存储器52存储的计算机执行指令，以实现上述实施例中的鉴权方法中的安全服务器的动作，其实现原理和技术效果类似，在此不再赘述。

应理解，处理器51可能是一个中央处理器(Central Processing Unit，简称为CPU)，或者是特定集成电路(Application Specific Integrated Circuit，简称为ASIC)，或者是被配置成实施本发明实施例的一个或多个集成电路。

可选的，在具体实现上，如果通信接口、存储器52和处理器51独立实现，则通信接口、存储器52和处理器51可以通过总线相互连接并完成相互间的通信。所述总线可以是工业标准体系结构(Industry Standard Architecture，简称为ISA)总线、外部设备互连(Peripheral Component，简称为PCI)总线或扩展工业标准体系结构(Extended IndustryStandard Architecture，简称为EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等，但并不表示仅有一根总线或一种类型的总线。可选的，在具体实现上，如果通信接口、存储器52和处理器51集成在一块芯片上实现，则通信接口、存储器52和处理器51可以通过内部接口完成相同间的通信。

在本申请实施例图11-图15的设备或装置中处理模块(或者处理器)、存储模块(或者存储器)和收发模块(收发器)之间通过内部连接通路互相通信，传递控制和/或数据信号。本申请上述方法实施例可以应用于处理器中，或者由处理器实现上述方法实施例的步骤。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是中央处理器(central processing unit，CPU)，网络处理器(networkprocessor，NP)或者CPU和NP的组合、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。虽然图中仅仅示出了一个处理器，该装置可以包括多个处理器或者处理器包括多个处理模块。具体的，处理器可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。

存储器用于存储处理器执行的计算机指令。存储器可以是存储电路也可以是存储器。存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。存储器可以独立于处理器，也可以是处理器中的存储模块，在此不做限定。虽然图中仅仅示出了一个存储器，该装置也可以包括多个存储器或者存储器包括多个存储模块。

收发器用于实现处理器与其他模块或者网元的内容交互。具体的，收发器可以是该装置的通信接口，也可以是收发电路或者通信模块，还可以是收发信机。收发器还可以是处理器的通信接口或者收发电路。可选的，收发器可以是一个收发芯片。该收发器还可以包括发送模块和/或接收模块。在一种可能的实现方式中，该收发器可以包括至少一个通信接口。在另一种可能的实现方式中，该收发器也可以是以软件形式实现的模块。在本申请的各实施例中，处理器可以通过收发器与其他模块或者网元进行交互。例如：处理器通过该收发器获取或者接收来自其他网元的内容。若处理器与收发器是物理上分离的两个部件，处理器可以不经过收发器与该装置的其他模块进行内容交互。

一种可能的实现方式中，处理器、存储器以及收发器可以通过总线相互连接。总线可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。

本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请的各实施例中，为了方面理解，进行了多种举例说明。然而，这些例子仅仅是一些举例，并不意味着是实现本申请的最佳实现方式。

在本申请的各实施例中，为了方便的描述，采用了请求消息，响应消息以及其他各种消息的名称。然而，这些消息仅仅是以举例方式说明需要携带的内容或者实现的功能，消息的具体名称并不对本申请的做出限定，例如：还可以是第一消息，第二消息，第三消息等。这些消息可以是具体的一些消息，可以是消息中的某些字段。这些消息还可以代表各种服务化操作。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

本文中的术语“多个”是指两个或两个以上。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。

可以理解的是，在本申请的实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请的实施例的实施过程构成任何限定。

Claims (28)

1.一种鉴权方法，其特征在于，所述方法包括：

终端设备通过本地配置文件助手LPA，从签约管理-数据准备SM-DS服务器获取安全服务器地址；

所述终端设备通过所述LPA从所述安全服务器地址对应的安全服务器中，下载加密的多个目标账号的配置文件、多个所述目标账号的证书到所述终端设备的安全元件存储，其中，任一所述目标账号为电话号码；

终端设备接收用户输入的初始鉴权请求消息，所述初始鉴权请求消息用于请求验证所述终端设备对应用的使用权限，所述初始鉴权请求消息为所述终端设备在显示所述应用的用户界面上，响应于用户对所述用户界面的点击操作所生成，所述应用为用户从多个所述目标账号中选择的一个目标账号进行登录的应用；

所述终端设备使用所述终端设备登录所述应用的目标账号的证书，与所述应用服务器进行鉴权交互，所述目标账号的证书存储在所述终端设备的安全元件中。

2.根据权利要求1所述的方法，其特征在于，所述初始鉴权请求消息包括：所述应用服务器生成的第一随机数；

所述终端设备使用所述终端设备登录所述应用的目标账号的证书，与所述应用服务器进行鉴权交互，包括：

所述终端设备向所述应用服务器发送第一鉴权请求消息，所述第一鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第一签名；所述第一签名与所述第一随机数相关；

所述终端设备接收来自所述应用服务器响应所述第一鉴权请求消息的鉴权结果。

3.根据权利要求2所述的方法，其特征在于，所述目标账号的证书的签名数据中携带有所述目标账号的标识；或者，

所述第一鉴权请求消息还包括：所述目标账号的标识，所述第一签名与所述第一随机数和所述目标账号的标识相关。

4.根据权利要求1所述的方法，其特征在于，所述终端设备使用所述终端设备登录所述目标应用的目标账号的证书，与所述应用服务器进行鉴权交互，包括：

所述终端设备向应用服务器发送第二鉴权请求消息，所述第二鉴权请求消息用于请求所述应用服务器验证应用服务器的证书与所述目标账号的证书是否来自同一根证书，所述第二鉴权请求消息包括：所述目标账号的证书的信息、所述目标账号的标识、所述终端设备生成的第二随机数，所述目标账号的证书的信息用于指示签发所述目标账号的证书的根证书；

所述终端设备接收所述应用服务器在应用服务器的证书与所述目标账号的证书来自同一根证书时发送的第三鉴权请求消息，所述第三鉴权请求消息用于请求所述终端设备对所述应用服务器进行鉴权，所述第三鉴权请求消息包括：所述应用服务器的证书、使用所述应用服务器的证书的私钥签名得到的第二签名，所述第二签名与所述第二随机数和第三随机数相关，所述第三随机数为所述应用服务器生成的；

所述终端设备根据所述第三鉴权请求消息，对所述应用服务器鉴权；

所述终端设备在所述应用服务器鉴权通过后，向所述应用服务器发送第四鉴权请求消息，所述第四鉴权请求消息用于请求所述应用服务器对所述目标账号进行鉴权，所述第四鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第三签名；所述第三签名与所述第三随机数相关；

所述终端设备接收来自所述应用服务器响应所述第四鉴权请求消息的鉴权结果。

5.根据权利要求4所述的方法，其特征在于，所述目标账号的证书的签名数据中携带有所述目标账号的标识；或者，

所述第四鉴权请求消息还包括：所述目标账号的标识，所述第三签名与所述第三随机数和所述目标账号的标识相关。

6.根据权利要求4或5所述的方法，其特征在于，所述终端设备根据所述第三鉴权请求消息，对所述应用服务器鉴权，包括：

所述终端设备使用所述目标账号的证书的根证书，对所述应用服务器的证书进行验证；

所述终端设备在所述应用服务器的证书验证通过后，使用所述应用服务器的证书对所述第二签名进行解密，得到所述第二随机数和所述第三随机数；

若所述第二随机数未发生变化，则所述终端设备确认所述应用服务器鉴权通过。

7.一种鉴权方法，其特征在于，所述方法包括：

应用服务器基于终端设备登录应用的目标账号的证书，与所述终端设备进行鉴权交互，验证所述终端设备对所述应用的使用权限，其中，所述目标账号为用户从包括多个目标账号的应用中选择的，任一所述目标账号为电话号码，所述目标账号的证书是所述终端设备从安全元件向所述应用服务器发送的。

8.根据权利要求7所述的方法，其特征在于，所述应用服务器基于终端设备登录目标应用的目标账号的证书，与所述终端设备进行鉴权交互，包括：

所述应用服务器接收来自所述终端设备的第一鉴权请求消息，所述第一鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第一签名；所述第一签名与第一随机数相关，所述第一随机数为所述应用服务器生成的随机数；

所述应用服务器根据所述第一鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果；

所述应用服务器向所述终端设备发送所述鉴权结果。

9.根据权利要求8所述的方法，其特征在于，所述应用服务器根据所述第一鉴权请求消息，对所述终端设备进行鉴权，包括：

所述应用服务器对所述目标账号的证书和所述目标账号的证书的父证书进行验证；

所述应用服务器在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，使用所述目标账号的证书对所述第一签名进行解密，得到所述第一随机数；

若所述第一随机数未发生变化，则所述应用服务器确认所述终端设备鉴权通过；

若所述第一随机数发生变化，则所述应用服务器确认所述终端设备鉴权失败。

10.根据权利要求8或9所述的方法，其特征在于，所述目标账号的证书的签名数据中携带有所述目标账号的标识；或者，

所述第一鉴权请求消息还包括：所述目标账号的标识，所述第一签名与所述第一随机数和所述目标账号的标识相关。

11.根据权利要求7所述的方法，其特征在于，所述应用服务器基于终端设备登录目标应用的目标账号的证书，与所述终端设备进行鉴权交互，包括：

所述应用服务器接收来自所述终端设备的第二鉴权请求消息，所述第二鉴权请求消息用于请求验证应用服务器的证书与所述目标账号的证书是否来自同一根证书，所述第二鉴权请求消息包括：所述目标账号的证书的信息、所述目标账号的标识、所述终端设备生成的第二随机数，所述目标账号的证书的信息用于指示签发所述目标账号的证书的根证书；

所述应用服务器根据所述第二鉴权请求消息，验证所述应用服务器的证书与所述目标账号的证书是否来自同一根证书；

若所述应用服务器根据所述第二鉴权请求消息，确定应用服务器的证书与所述目标账号的证书来自同一根证书，则所述应用服务器向所述终端设备发送第三鉴权请求消息，所述第三鉴权请求消息用于请求所述终端设备对所述应用服务器进行鉴权，所述第三鉴权请求消息包括：所述应用服务器的证书、使用所述应用服务器的证书的私钥签名得到的第二签名，所述第二签名与所述第二随机数和第三随机数相关，所述第三随机数为所述应用服务器生成的；

所述应用服务器接收所述终端设备在对所述应用服务器鉴权通过后发送的第四鉴权请求消息，所述第四鉴权请求消息用于请求所述应用服务器对所述目标账号进行鉴权，所述第四鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第三签名；所述第三签名与所述第三随机数相关；

所述应用服务器根据所述第四鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果；

所述应用服务器向所述终端设备发送所述鉴权结果。

12.根据权利要求11所述的方法，其特征在于，所述目标账号的证书的签名数据中携带有所述目标账号的标识；或者，

所述第四鉴权请求消息还包括：所述目标账号的标识，所述第三签名与所述第三随机数和所述目标账号的标识相关。

13.根据权利要求12所述的方法，其特征在于，所述应用服务器根据所述第四鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果，包括：

所述应用服务器使用所述应用服务器的证书的根证书，对所述目标账号的证书和所述目标账号的证书的父证书进行验证；

所述应用服务器在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，使用所述目标账号的证书对所述第三签名进行解密，得到所述第三随机数；

所述应用服务器从所述第四鉴权请求消息中获取所述目标账号的标识；

若所述第三随机数未发生变化、且所述第四鉴权请求消息中携带的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识相同，则所述应用服务器确认所述终端设备鉴权通过；

若所述第三随机数发生变化，和/或，所述第四鉴权请求消息中携带的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识不同，则所述应用服务器确认所述终端设备鉴权失败。

14.一种鉴权方法，其特征在于，所述方法包括：

安全服务器使用所述安全服务器的证书生成目标账号的证书和所述目标账号的证书的私钥；

所述安全服务器向终端设备的安全元件发送所述目标账号的证书、所述目标账号的证书的私钥，以及，所述安全服务器的证书；其中，所述目标账号为用户从包括多个目标账号的应用中选择的，任一所述目标账号为电话号码。

15.一种终端设备，其特征在于，所述终端设备包括：

收发模块，用于通过本地配置文件助手LPA，从签约管理-数据准备SM-DS服务器获取安全服务器地址；

所述收发模块，还用于通过所述LPA从所述安全服务器地址对应的安全服务器中，下载加密的多个目标账号的配置文件、多个所述目标账号的证书到所述终端设备的安全元件存储，其中，任一所述目标账号为电话号码；

收发模块，用于接收用户输入的初始鉴权请求消息，所述初始鉴权请求消息用于请求验证所述终端设备对应用的使用权限；所述初始鉴权请求消息为所述终端设备在显示所述应用的用户界面上，响应于用户对所述用户界面的点击操作所生成，所述应用为任一可以使用用户输入的目标账号进行登录的应用；

处理模块，用于使用所述终端设备登录所述应用的目标账号的证书，通过所述收发模块与所述应用服务器进行鉴权交互，所述目标账号的证书存储在所述终端设备的安全元件中；所述应用为用户从多个所述目标账号中选择的一个所述目标账号进行登录的应用，任一所述目标账号为电话号码。

16.根据权利要求15所述的设备，其特征在于，所述初始鉴权请求消息包括：所述应用服务器生成的第一随机数；

所述处理模块，具体用于通过所述收发模块向所述应用服务器发送第一鉴权请求消息，并接收来自所述应用服务器响应所述第一鉴权请求消息的鉴权结果；

其中，所述第一鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第一签名；所述第一签名与所述第一随机数相关。

17.根据权利要求16所述的设备，其特征在于，所述目标账号的证书的签名数据中携带有所述目标账号的标识；或者，

所述第一鉴权请求消息还包括：所述目标账号的标识，所述第一签名与所述第一随机数和所述目标账号的标识相关。

18.根据权利要求15所述的设备，其特征在于，所述处理模块，具体用于：

通过所述收发模块向应用服务器发送第二鉴权请求消息，所述第二鉴权请求消息用于请求所述应用服务器验证应用服务器的证书与所述目标账号的证书是否来自同一根证书，所述第二鉴权请求消息包括：所述目标账号的证书的信息、所述目标账号的标识、所述处理模块生成的第二随机数，所述目标账号的证书的信息用于指示签发所述目标账号的证书的根证书；

通过所述收发模块接收所述应用服务器在应用服务器的证书与所述目标账号的证书来自同一根证书时发送的第三鉴权请求消息；所述第三鉴权请求消息用于请求所述终端设备对所述应用服务器进行鉴权，所述第三鉴权请求消息包括：所述应用服务器的证书、使用所述应用服务器的证书的私钥签名得到的第二签名，所述第二签名与所述第二随机数和第三随机数相关，所述第三随机数为所述应用服务器生成的；

根据所述第三鉴权请求消息，对所述应用服务器鉴权；

在所述应用服务器鉴权通过后，通过所述收发模块向所述应用服务器发送第四鉴权请求消息，所述第四鉴权请求消息用于请求所述应用服务器对所述目标账号进行鉴权，所述第四鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第三签名；所述第三签名与所述第三随机数相关；

通过所述收发模块接收来自所述应用服务器响应所述第四鉴权请求消息的鉴权结果。

19.根据权利要求18所述的设备，其特征在于，所述目标账号的证书的签名数据中携带有所述目标账号的标识；或者，

所述第四鉴权请求消息还包括：所述目标账号的标识，所述第三签名与所述第三随机数和所述目标账号的标识相关。

20.根据权利要求18或19所述的设备，其特征在于，所述处理模块，具体用于：

使用所述目标账号的证书的根证书，对所述应用服务器的证书进行验证；

在所述应用服务器的证书验证通过后，使用所述应用服务器的证书对所述第二签名进行解密，得到所述第二随机数和所述第三随机数；

若所述第二随机数未发生变化，则确认所述应用服务器鉴权通过。

21.一种服务器，其特征在于，所述服务器为应用服务器，所述应用服务器包括：

处理模块，用于基于终端设备登录应用的目标账号的证书，与所述终端设备进行鉴权交互，验证所述终端设备对所述应用的使用权限；其中，所述目标账号为用户从包括多个目标账号的应用中选择的，任一所述目标账号为电话号码，所述目标账号的证书是所述终端设备从安全元件向所述应用服务器发送的。

22.根据权利要求21所述的服务器，其特征在于，所述应用服务器还包括：收发模块；

所述处理模块，具体用于通过收发模块接收来自所述终端设备的第一鉴权请求消息；根据所述第一鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果，并通过所述收发模块向所述终端设备发送所述鉴权结果；

其中，所述第一鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第一签名；所述第一签名与第一随机数相关，所述第一随机数为所述应用服务器生成的随机数。

23.根据权利要求22所述的服务器，其特征在于，

所述处理模块，具体用于对所述目标账号的证书和所述目标账号的证书的父证书进行验证，并在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，使用所述目标账号的证书对所述第一签名进行解密，得到所述第一随机数；若所述第一随机数未发生变化，则确认所述终端设备鉴权通过，若所述第一随机数发生变化，则确认所述终端设备鉴权失败。

24.根据权利要求22或23所述的服务器，其特征在于，所述目标账号的证书的签名数据中携带有所述目标账号的标识；或者，

所述第一鉴权请求消息还包括：所述目标账号的标识，所述第一签名与所述第一随机数和所述目标账号的标识相关。

25.根据权利要求21所述的服务器，其特征在于，所述应用服务器还包括：收发模块；

所述处理模块，具体用于：

通过所述收发模块接收来自所述终端设备的第二鉴权请求消息，所述第二鉴权请求消息用于请求验证应用服务器的证书与所述目标账号的证书是否来自同一根证书，所述第二鉴权请求消息包括：所述目标账号的证书的信息、所述目标账号的标识、所述终端设备生成的第二随机数，所述目标账号的证书的信息用于指示签发所述目标账号的证书的根证书；

根据所述第二鉴权请求消息，验证所述应用服务器的证书与所述目标账号的证书是否来自同一根证书；

若根据所述第二鉴权请求消息，确定应用服务器的证书与所述目标账号的证书来自同一根证书，则通过所述收发模块向所述终端设备发送第三鉴权请求消息，所述第三鉴权请求消息用于请求所述终端设备对所述应用服务器进行鉴权，所述第三鉴权请求消息包括：所述应用服务器的证书、使用所述应用服务器的证书的私钥签名得到的第二签名，所述第二签名与所述第二随机数和第三随机数相关，所述第三随机数为所述应用服务器生成的；

通过所述收发模块接收所述终端设备在对所述应用服务器鉴权通过后发送的第四鉴权请求消息，所述第四鉴权请求消息用于请求所述应用服务器对所述目标账号进行鉴权，所述第四鉴权请求消息包括：所述目标账号的证书、所述目标账号的证书的父证书、使用所述目标账号的证书的私钥签名得到的第三签名；所述第三签名与所述第三随机数相关；

根据所述第四鉴权请求消息，对所述终端设备进行鉴权，得到鉴权结果；

通过所述收发模块向所述终端设备发送所述鉴权结果。

26.根据权利要求25所述的服务器，其特征在于，所述目标账号的证书的签名数据中携带有所述目标账号的标识；或者，

所述第四鉴权请求消息还包括：所述目标账号的标识，所述第三签名与所述第三随机数和所述目标账号的标识相关。

27.根据权利要求26所述的服务器，其特征在于，所述处理模块，具体用于：

使用所述应用服务器的证书的根证书，对所述目标账号的证书和所述目标账号的证书的父证书进行验证；

在所述目标账号的证书和所述目标账号的证书的父证书验证通过后，使用所述目标账号的证书对所述第三签名进行解密，得到所述第三随机数；

从所述第四鉴权请求消息中获取所述目标账号的标识；

若所述第三随机数未发生变化、且所述第四鉴权请求消息中携带的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识相同，则确认所述终端设备鉴权通过；

若所述第三随机数发生变化，和/或，所述第四鉴权请求消息中携带的所述目标账号的标识与所述第二鉴权请求消息中携带的所述目标账号的标识不同，则确认所述终端设备鉴权失败。

28.一种服务器，其特征在于，所述服务器为安全服务器，所述安全服务器包括：

处理模块，用于使用所述安全服务器的证书生成目标账号的证书和所述目标账号的证书的私钥；

发送模块，用于向终端设备的安全元件发送所述目标账号的证书、所述目标账号的证书的私钥，以及，所述安全服务器的证书；所述目标账号为用户从包括多个目标账号的应用中选择的，任一所述目标账号为电话号码。

Images