确定风险信息的方法、装置、电子设备及存储介质与流程

1.本公开涉及通信认证领域，尤其涉及一种确定风险信息的方法、装置、电子设备及存储介质。


背景技术：

2.随着终端设备以及互联网技术的快速发展，终端设备所能支持的第三方应用越来越多，使用终端设备的过程中面临的安全问题也越来越多。因此，移动终端设备的风险防控体系日益重要，以期实现在多元化的互联网环境下有效保护设备及用户数据的隐私安全。
3.相关技术中还缺乏有效的风险监控方法，无法及时获知风险将导致更多的设备安全问题或用户隐私泄露问题。


技术实现要素：

4.为克服相关技术中存在的问题，本公开提供一种确定风险信息的方法、装置、电子设备及存储介质。
5.根据本公开实施例的第一方面，提出了一种确定风险信息的方法，应用于第三方应用，方法包括：
6.在终端设备的可信执行环境tee层获取终端设备的当前状态信息；
7.根据所述当前状态信息确定风险信息，其中，所述风险信息用于表征所述当前状态信息是否存在风险。
8.在一些可能的实施方式中，所述根据所述当前状态信息确定风险信息，包括：
9.向所述第三方应用的第三方厂商服务器发送所述当前状态信息；
10.接收所述第三方厂商服务器基于所述当前状态信息确定的风险信息。
11.在一些可能的实施方式中，所述方法还包括：
12.响应于所述风险信息表征存在风险，向第三方厂商服务器发送所述风险信息；
13.接收所述第三方厂商服务器基于所述风险信息确定的风险控制措施，执行所述风险控制措施。
14.在一些可能的实施方式中，所述在终端设备的可信执行环境tee层获取终端设备的当前状态信息，包括：
15.响应于当前业务场景为预设场景，调用所述第三方应用的第一风控管理服务向终端设备的安全程序发送请求消息；其中，所述请求消息中包括所述第三方应用的应用标识；
16.通过所述第三方应用对应的第一风控ta，接收终端设备内的第二风控ta所发送的所述当前状态信息，其中，所述第一风控ta与所述第二风控ta运行于终端设备的可信执行环境tee层。
17.在一些可能的实施方式中，响应于当前业务场景为预设场景，所述方法还包括：
18.通过设备厂商服务器将所述第一风控ta在线下发至终端设备的所述tee层。
19.在一些可能的实施方式中，所述方法还包括：
20.响应于所述第三方应用被卸载或被清理，所述第一风控ta结束生命周期。
21.根据本公开实施例的第二方面，提出了一种确定风险信息的方法，应用于终端设备，方法包括：
22.响应于接收到第三方应用的请求消息，确定终端设备的当前状态信息；其中，所述请求消息中包括所述第三方应用的应用标识；
23.在tee层向所述第三方应用发送所述当前状态信息，或者，向设备厂商服务器发送所述当前状态信息。
24.在一些可能的实施方式中，所述在tee层向所述第三方应用发送所述当前状态信息，包括：
25.响应于tee层中存在所述第三方应用对应的第一风控ta，通过tee层的第二风控ta向所述第三方应用发送所述当前状态信息。
26.在一些可能的实施方式中，所述向设备厂商服务器发送所述当前状态信息，包括：
27.通过第二风控ta对所述当前状态信息加密处理，并将加密处理得到的第一数据发送至安全程序；其中，所述当前状态信息包括：安全等级依次降低的一级状态信息、二级状态信息和三级状态信息；
28.通过所述安全程序向所述设备厂商服务器发送所述第一数据或者解密的所述当前状态信息。
29.在一些可能的实施方式中，所述方法还包括：
30.通过所述第二风控ta对终端设备的设备指纹以及第三方应用的应用标识加密处理，获得第二数据。
31.在一些可能的实施方式中，所述向设备厂商服务器发送所述当前状态信息，包括：
32.向所述设备厂商服务器发送所述第一数据和所述第二数据。
33.根据本公开实施例的第三方面，提出了一种确定风险信息的方法，应用于设备厂商服务器，方法包括：
34.接收终端设备发送的当前状态信息；
35.根据所述当前状态信息确定风险信息，其中，所述风险信息用于表征所述当前状态信息是否存在风险；
36.向第三方应用对应的第三方厂商服务器发送所述风险信息和/或风险控制措施。
37.在一些可能的实施方式中，所述接收终端设备发送的当前状态信息，包括：
38.接收终端设备发送的第一数据和第二数据，其中，所述第一数据为所述终端设备的第二风控ta对所述当前状态信息加密处理所得，所述第二数据为所述第二风控ta对终端设备的设备指纹以及第三方应用的应用标识加密处理所得。
39.在一些可能的实施方式中，所述根据所述当前状态信息确定风险信息，包括：
40.对所述第二数据解密获得设备指纹，根据所述设备指纹获得所述第一数据解密后的所述当前状态信息；
41.根据所述当前状态信息确定风险信息。
42.在一些可能的实施方式中，所述根据所述当前状态信息确定风险信息，包括：
43.响应于所述当前状态信息与前一次状态信息相同，确定所述当前状态信息安全；
44.响应于所述当前状态信息与前一次状态信息不同，确定所述当前状态信息存在风
险。
45.在一些可能的实施方式中，所述确定所述当前状态信息存在风险，包括：
46.根据所述当前状态信息与前一次状态信息的变化程度，确定风险等级。
47.根据本公开实施例的第四方面，提出了一种确定风险信息的方法，应用于第三方厂商服务器，方法包括：
48.接收第三方应用发送的风险信息，或者接收设备厂商服务器发送的所述风险信息。
49.在一些可能的实施方式中，所述方法还包括：
50.根据所述风险信息，确定预设场景下的风险控制措施；
51.向所述第三方应用发送所述风险控制措施。
52.根据本公开实施例的第五方面，提出了一种确定风险信息的装置，被配置于第三方应用，装置包括：
53.获取模块，用于在终端设备的可信执行环境tee层获取终端设备的当前状态信息；
54.第一确定模块，用于根据所述当前状态信息确定风险信息，其中，所述风险信息用于表征所述当前状态信息是否存在风险。
55.根据本公开实施例的第六方面，提出了一种确定风险信息的装置，被配置于终端设备，装置包括：
56.第二确定模块，用于响应于接收到第三方应用的请求消息，确定终端设备的当前状态信息；其中，所述请求消息中包括所述第三方应用的应用标识；
57.第一发送模块，用于在tee层向所述第三方应用发送所述当前状态信息，或者，向设备厂商服务器发送所述当前状态信息。
58.根据本公开实施例的第七方面，提出了一种确定风险信息的装置，被配置于设备厂商服务器，装置包括：
59.第一接收模块，用于接收终端设备发送的当前状态信息；
60.第三确定模块，用于根据所述当前状态信息确定风险信息，其中，所述风险信息用于表征所述当前状态信息是否存在风险；
61.第二发送模块，用于向第三方应用对应的第三方厂商服务器发送所述风险信息和/或风险控制措施。
62.根据本公开实施例的第八方面，提出了一种确定风险信息的装置，被配置于第三方厂商服务器，装置包括：
63.第二接收模块，用于接收第三方应用发送的风险信息，或者接收设备厂商服务器发送的所述风险信息。
64.根据本公开实施例的第九方面，提出了一种电子设备，包括：
65.处理器；
66.用于存储处理器的可执行指令的存储器；
67.其中，所述处理器被配置为执行如上任一项所述的确定风险信息的方法。
68.根据本公开实施例的第十方面，提出了一种非临时性计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如上任一项所述的确定风险信息的方法。
69.本公开的实施例提供的技术方案可以包括以下有益效果：
70.本公开的方法中，第三方应用通过终端设备底层的tee层获得当前状态信息，以保证获取状态信息过程中的安全性；并可以基于当前状态信息获知风险信息，从而及时发现或监控到风险，有利于及时采取风控措施。
71.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
72.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。
73.图1是根据一示例性实施例示出的应用场景示意图。
74.图2是根据一示例性实施例示出的方法的流程图。
75.图3是根据一示例性实施例示出的交互示意图。
76.图4是根据一示例性实施例示出的方法的流程图。
77.图5是根据一示例性实施例示出的交互示意图。
78.图6是根据一示例性实施例示出的方法的流程图。
79.图7是根据一示例性实施例示出的交互示意图。
80.图8是根据一示例性实施例示出的方法的流程图。
81.图9是根据一示例性实施例示出的装置的框图。
82.图10是根据另一示例性实施例示出的装置的框图。
83.图11是根据另一示例性实施例示出的装置的框图。
84.图12是根据另一示例性实施例示出的装置的框图。
85.图13是根据一示例性实施例示出的电子设备的框图。
具体实施方式
86.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。
87.相关技术中，终端设备须向第三方应用发送设备指纹，第三方应用或其对应的第三方厂商服务器通过设备指纹索引设备状态信息，以完成设定场景下的信息交互。
88.在此过程中，一方面，由于设备指纹能够唯一定位对应设备的特点，第三方应用或其对应的第三方厂商服务器可能会侵犯用户的隐私数据。另一方面，攻击方可能对终端设备的设备状态信息进行篡改或作假，第三方应用或其对应的互联网厂商不能获得真实的设备状态信息。
89.为解决相关技术中的问题，本公开实施例提出了一种确定风险信息的方法，应用于第三方应用，方法包括：在终端设备的可信执行环境tee层获取终端设备的当前状态信息；根据当前状态信息确定风险信息，其中，风险信息用于表征所述当前状态信息是否存在风险。本公开的方法中，第三方应用通过终端设备底层的tee层获得当前状态信息，以保证
获取状态信息过程中的安全性；并可以基于当前状态信息获知风险信息，从而及时发现或监控到风险，有利于及时采取风控措施。
90.图1是本公开确定风险信息的系统的架构示意图。如图1所示，该系统包括：终端设备100、安装于终端设备100内的第三方应用200、第三方应用200对应的第三方厂商服务器300、以及终端设备对应的设备厂商服务器400。
91.该系统中，终端设备100比如是智能手机、平板电、笔记本电脑、智能穿戴设备、车联网设备等。终端设备可以基于安卓(android)操作系统，并具有富执行环境(rich execution environment，ree)和独立的可信执行环境(trusted execution environment，tee)。tee与ree隔离开，ree一般指通用的操作系统。在tee层运行的程序为可信应用程序(trusted application，ta)，在ree中运行的程序为客户端应用程序(client application，ca)。
92.tee是一种安全执行环境，可用于实现密钥和ta管理，并处理开放信任协议(otrp)。
93.ree中的ca可通过设备厂商提供的软件开发工具包(sdk)接入到设备厂商服务器400。在ree层还包括设备厂商的代理服务节点以及硬件抽象层接口定义语言(hardware abstraction layer interface definition language，hidl)服务节点，代理服务节点用于处理otrp协议的转发等，hidl服务节点用于与tee转发otrp协议消息。
94.该系统中，第三方应用200可安装于终端设备100操作系统中的应用层(app层)，其可以是支付类、身份验证类、消费购物类、游戏类或社交媒体类等app。
95.该系统中，第三方厂商服务器(service provider，sp)300是第三方应用200实现的服务器，能够接入设备厂商服务器400。并且可通过与终端设备100内的ca配合，实现终端设备100与服务端的协议通信和第三方自研的逻辑功能。
96.该系统中，设备厂商服务器400可以是一种可信应用管理服务器(trusted application management server，tam server)，或者，设备厂商服务器400是集成有tam功能的服务器，例如，设备厂商服务器400包括ta下发系统。设备厂商服务器400用于实现otrp的逻辑处理，第三方厂商服务器300的认证，以及证书和ta的管理。
97.在该系统中，可通过证书认证中心(certificate authority，ca)建立tee、第三方厂商服务器300以及设备厂商服务器400之间的信任关系。
98.基于该系统，本公开的方法可应用在第三方应用200需获取终端设备100的设备状态信息的场景中，例如移动支付场景。以下本公开的方法实施过程中所涉及的终端设备100，可理解为终端设备100的操作系统。
99.可以理解的，图1中细线示意的流程对应于本公开一种实施方式，粗线示意的流程对应本公开另一种实施方式，具体可参见下述实施例的描述。
100.在一个示例性的实施例中，图2是本公开实施例提供的一种确定风险信息的方法的示意图。结合图1所示，本实施例的方法被安装于终端设备100内的第三方应用200执行。如图2所示，本实施例的方法可以包括如下步骤s210～s220：
101.步骤s210，在终端设备的可信执行环境tee层获取终端设备的当前状态信息。
102.步骤s220，根据当前状态信息确定风险信息。
103.其中，在步骤s210中，在第三方应用200运行过程中，可在业务场景为预设场景时
触发步骤s210。预设场景比如是在支付场景下或者在游戏场景下，例如，在一些应用程序的使用过程中，自动调用到第三方应用200的支付功能或用户隐私数据采集功能的场景。在预设场景下，结合图1细线所示流程，第三方应用200可通过向终端设备100发送请求消息，来请求获取终端设备100的当前状态信息。当前状态信息用于表征终端设备100的设备信息或运行信息，第三方应用200获知当前状态信息旨在根据当前状态信息确定终端设备100的设备状态信息是否存在风险，如当前状态信息是否真实、是否被篡改。
104.本步骤中，第三方应用200在tee层获得当前状态信息，保证获得当前状态信息过程中的安全性。例如第三方应用200在终端设备100的tee层配置受终端设备100信任的第三方应用200的ta程序，如图1所示的第一风控ta202。
105.在步骤s220中，风险信息用于表征当前状态信息是否存在风险或是否安全。例如，若当前状态信息与前一次获取的终端设备100的状态信息不同，则认为当前状态信息存在风险，可能被篡改。若当前状态信息与前一次获取的终端设备100的状态信息相同，则认为当前状态信息无风险，是安全状态，可继续进行预设场景下的业务。
106.本步骤中，第三方应用200在步骤s210中所获得的当前状态信息可以是未经过加密的状态；未加密状态的当前状态信息通过第三方应用200在tee层(如通过第一风控ta202)进行风险分析，确定风险信息。例如，终端设备100在采集当前状态信息后，可在tee层向第三方应用200的第一风控ta202发送未加密状态的当前状态信息，并对当前状态信息设定使用权限。设定使用权限可以是以下中的至少一项：时间权限，即当前状态信息在设定时长内有效；使用次数权限，即当前状态信息仅在当前次有效；使用场景权限，即当前状态信息仅用于预设场景下的风险信息确定。
107.或者，当前状态信息是经过加密和/或签名的状态，经过加密和/或签名状态的可记为第一数据，该第一数据中包含当前状态信息。第一数据既可通过第三方应用200的第一风控ta202在tee层进行解密和风险分析，确定风险信息；第一数据也可以通过第三方应用200对应的第三方厂商服务器300进行解密和风险分析，确定风险信息。其中，第一风控ta202可存储或即时接受设备厂商服务器400授权的公私钥对中的公钥(devstatus_pub)，通过公钥进行第一数据的解密。
108.在一个示例中，本示例中步骤s220可以包括如下子步骤s221和s222：
109.步骤s221，向第三方应用的第三方厂商服务器发送当前状态信息。
110.步骤s222，接收第三方厂商服务器基于当前状态信息确定的风险信息。
111.其中，在步骤s221中，终端设备100在采集当前状态信息后，可在tee层采用公私钥对中的私钥(devstatus_pri)对当前状态信息以及随机数进行加密，获得第一数据。终端设备100在tee层将第一数据在tee层发送给第三方应用200的第一风控ta202。第三方应用200的第一风控ta202可利用公钥对第一数据解密，向第三方厂商服务器发送解密后的当前状态信息；或者，向第三方厂商服务器发送包含当前状态信息的第一数据。
112.在步骤s222中，在第三方应用200发送解密后的当前状态信息时，第三方厂商服务器300可对比当前状态信息与前一次获取的终端设备100的状态信息，确定风险信息。在第三方应用200发送第一数据时，第三方厂商服务器300可对第一数据解密，并对解密获得的当前状态信息进行风险分析；或者，第三方厂商服务器300借助与设备厂商服务器400的通信，获得解密后的当前状态信息，然后进行风险分析。可以理解的，第三方厂商服务器300中
存储或可即时获取加密数据所需的密钥或临时密钥。
113.在另一个示例中，如图3所示，本示例中在步骤s210及s220的基础上，还包括如下步骤s230～s240：
114.步骤s230，响应于风险信息表征存在风险，向第三方厂商服务器发送风险信息。
115.步骤s240，接收第三方厂商服务器基于风险信息确定的风险控制措施，执行风险控制措施。
116.其中，在步骤s230中，第三方应用200的第一风控ta202可以是对未加密状态的当前状态信息进行风险分析，确定风险信息；或者是利用公钥对第一数据进行解密，对解密后的当前状态信息进行风险分析，确定风险信息。
117.本步骤中，在风险信息表征当前状态信息存在风险时，如当前状态信息与前一次设备状态信息不同，第三方应用200可向第三方厂商服务器300上报风险信息。
118.在步骤s240中，上报风险信息后，第三方厂商服务器300可下发相应的风险控制措施，第三方应用200执行第三方厂商服务器300所下发的风险控制措施，以及时防控。风险控制措施包括但不限于：暂停预设场景，暂停预设场景的设定业务，将调用预设场景的相关应用加入黑名单。
119.例如，在a应用程序的使用过程中，自动调用到第三方应用200的支付功能或用户隐私数据采集功能的场景中，当第三方应用200上报风险信息后，风险控制措施可以包括将程序a加入到第三方应用200的使用黑名单中，从而程序a在当前无法调用第三方应用200执行支付或采集用户隐私数据。
120.再例如，第三方应用200还可以依据第三方厂商服务器300的风控措施或风控策略，在本次结束支付场景或用户隐私数据采集场景，以实现风险规避。
121.本公开实施例中，第三方应用200在终端设备100的tee层获取当前状态信息，以保证当前状态信息传输过程中的安全性。还可以基于当前状态信息获知风险信息，及时发现风险漏洞；并及时上报风险信息，以便于通过第三方厂商服务器300能够及时快速的更新风控安全策略，有利于及时采取风控措施。
122.在一个示例性的实施例中，本实施例的方法可以包括如图2所示的步骤s210～s220，其中，本实施例中步骤s210可以包括如下子步骤s2101～s2102：
123.s2101、响应于当前业务场景为预设场景，调用第三方应用的第一风控管理服务向终端设备的安全程序发送请求消息；其中，请求消息中包括第三方应用的应用标识。
124.s2102、通过第三方应用对应的第一风控ta，接收终端设备内的第二风控ta所发送的当前状态信息，其中，第一风控ta与第二风控ta运行于终端设备的可信执行环境tee层。
125.其中，在步骤s2101中，结合图1所示，第三方应用200的风控体系包括：第一风控管理服务201和第一风控ta202，第一风控管理服务201运行于终端设备100的应用层，第一风控ta202运行于终端设备100的tee层。终端设备100的风控体系包括：安全程序101、第二风控管理服务(sdk)102以及第二风控ta103，安全程序101运行于应用层，第二风控管理服务102运行于ree层，第二风控ta103运行于tee层。
126.本步骤中，预设场景比如是前述的支付场景或者获取用户隐私信息的场景。在应用层，第三方应用200的第一风控管理服务201与安全程序101直接通信。响应于预设场景的触发，第一风控管理服务201将请求消息发送至安全程序101。在接收到请求消息后，安全程
序101可发起与底层(如ree层和tee层)的交互，以收集终端设备的状态信息。
127.在一个示例中，请求消息中可包含第三方应用200的应用标识(userid)。userid是设备厂商为第三方应用200所分配的唯一对应的id，用于标识唯一的应用程序。第三方应用200在请求消息中携带userid，便于终端设备的安全程序101或设备厂商服务器400获知第三方应用200的相关信息。
128.在步骤s2102中，终端设备的当前状态信息可汇总于第二风控ta103中，以保证安全性。在tee层，依据请求信息，第二风控ta103可将未经过加密的当前状态信息发送给第一风控ta202；或者，第二风控ta103对当前状态信息进行加密得到第一数据，将包含当前状态信息的第一数据发送给第一风控ta202。安全程序101还可将第三方应用200的标识通过第二风控管理服务102发送给第二风控ta103。
129.在一个示例中，当前状态信息包括：安全等级依次降低的一级状态信息、二级状态信息和三级状态信息。比如：一级状态信息包括设备型号或处理器标识(cpuid)等，设备型号一般采用厂商名称加字母或数字的形式，例如，厂商a12，或者厂商b note 11。二级状态信息包括设备解锁状态或者国际移动设备识别码(imei)等，设备解锁状态例如包括：bootloader(引导加载程序)解锁状态和bootloader未解锁状态。三级状态信息包括终端设备中是否有恶意应用程序或者非法链接等。
130.本示例中，终端设备100在接收到请求信息后，安全程序101采集安全等级和可信程度等级最低的三级设备状态信息，并将三级设备状态信息发送至ree层的第二风控管理服务102。第二风控管理服务102采集安全等级和可信程度等级次高的二级状态信息，并将三级状态信息和收到的二级状态信息一并发送至tee层的第二风控ta103中。第二风控ta103采集安全等级和可信程度等级最高的一级状态信息，由此第二风控ta103中包含一级状态信息、二级状态信息以及三级状态信息，即获得全部当前状态信息，第二风控ta103可将当前状态信息预留在终端设备的内存中。在获得全部当前状态信息后，第二风控ta103可对全部当前状态信息利用私钥devstatus_pri进行加密，并向第一风控ta202发送加密的第一数据。
131.本公开实施例中，第三方应用200通过自身对应的第一风控ta202从第二风控ta103获得当前状态信息，此数据交互获取过程基于终端设备100的tee层，从而有效保证数据交互过程的安全性和可靠性。
132.在一个示例性的实施例中，本实施例的方法可以包括如图2所示的步骤s210～s230。本公开实施例中，第三方应用200在tee层安全获取当前状态信息的前提是：受终端设备100信任的第一风控ta202的配置。第一风控ta202可以是互联网厂商所自研的ta程序，并且须经过设备厂商服务器400的授权方可下发至终端设备100操作系统的tee层。
133.在一种可能的实施方式中，在运行第三方应用200过程中首次触发预设场景时，设备厂商服务器400将第一风控ta202下发至tee层。此种实施方式可在首次触发预设场景时执行，而在后续触发预设场景时可直接调用预先配置的第一风控ta202。
134.在本公开中的一种实施方式中，响应于当前业务场景为预设场景时，本实施例中步骤s210包括如下子步骤s2100～s2102：
135.步骤s2100，响应于当前业务场景为预设场景，通过设备厂商服务器将第一风控ta在线下发至终端设备的tee层。
136.步骤s2101，调用第三方应用的第一风控管理服务向终端设备的安全程序发送请求消息；其中，请求消息中包括第三方应用的应用标识。
137.步骤s2102，通过第三方应用对应的第一风控ta，接收终端设备内的第二风控ta所发送的当前状态信息，其中，第一风控ta与第二风控ta运行于终端设备的可信执行环境tee层。
138.其中，步骤s2101至步骤s2102的实施方式可参见前述实施例的描述，此处不再赘述。步骤s2100在步骤s2101之前执行。
139.在步骤s2100中，设备厂商服务器400可对第三方应用200的第一风控ta202授权，并在预设场景时将第一风控ta202在线下发至tee层，从而第三方应用200通过第一风控ta202获得终端设备100的信任，并可以在满足设备厂商定义的接口协议的基础上安全的从第二风控ta103获取到当前状态信息。
140.在一个示例中，第一风控ta202可以进行密钥管理以及隐私计算。例如，第一风控ta202可以对公钥进行加密或解密，还可以对当前状态信息加密或解密，或者对第一数据采用公钥进行加密或解密。
141.在一个示例中，第一风控ta202的生命周期与第三方应用200绑定。
142.比如，本示例的方法还包括如下步骤s250：步骤s250，响应于第三方应用被卸载或被清理，第一风控ta结束生命周期。此步骤中，在预设场景时第一风控ta被下发。当第三方应用200被卸载时，终端设备100将卸载与之绑定的第一风控ta202，即第一风控ta202结束生命周期。当因用户手动清理或终端设备100自动查杀后台，导致第三方应用200被清理掉即杀死时，其对应的第一风控ta202也将被卸载，结束生命周期。
143.再比如，第一风控ta202随第三方应用200的升级而动态升级。第一风控ta202可以在经过设备厂商服务器400授权签名之后在终端设备100的应用商店上线，以便于能够及时获得升级版本信息。
144.再比如，第一风控ta202的运行时间与第三方应用200绑定，不会影响其他app。在第一风控ta202在异常时，也不会影响终端设备100的正常运行。
145.在一个示例中，第三方应用200的第一风控ta202所占用的内存可以满足：第一风控ta202的堆内存和栈内存占用小于或等于2m。
146.本公开实施例中，对于第三方应用200的第一风控ta202配置了多种规则，第三方应用200可在遵守相关规则的基础上通过授权接入终端设备100内。并且结合前述实施例所述，第三方应用200通过第一风控ta202所获取的当前状态信息，需在一定的权限下使用。
147.例如，当前状态信息仅用于进行风险信息的确定，当第三方应用200利用当前状态信息进行超出权限的操作，设备厂商服务器400可以将第三方应用200加入黑名单。设备厂商服务器400可监测或管控当前状态信息的使用安全性。
148.在以上图2至图3所示的实施例中，第三方应用200通过风控管理服务接入终端设备100内部的风控体系。第三方应用200对应的第一风控ta202通过设备厂商服务器400授权而接入终端设备100，从而第一风控ta202可获得终端设备100的信任。本公开实施例为第三方应用200提供合理权限、接口能力以及底层驱动能力，互联网厂商可按自己需求和设备厂商服务器400的要求开发第一风控ta202，以便于实现在tee层安全的获得当前状态信息，以通过第三方应用200及时监控到风险，并及时防控，以提升安全性，保护各方利益。
149.在第三方应用200未开发对应第一风控ta202的场景中，本公开实施例还提出了一种通过终端设备100采集当前状态信息，并通过设备厂商服务器400进行风险分析的实施方式。
150.在一个示例性的实施例中，图4是本公开实施例提供的一种确定风险信息的方法的示意图。结合图1所示，本实施例的方法被终端设备100(的操作系统)执行。如图4所示，本实施例的方法可以包括如下步骤s410～s420：
151.步骤s410，响应于接收到第三方应用的请求消息，确定终端设备的当前状态信息；其中，请求消息中包括第三方应用的应用标识。
152.步骤s420，在tee层向第三方应用发送当前状态信息，或者，向设备厂商服务器发送当前状态信息。
153.其中，在步骤s410中，结合前述图2至图3对应的实施例，第三方应用200可以是在预设场景下发送请求信息。例如，在应用层，第三方应用200的第一风控管理服务201调用进程间通信binder服务，向安全程序101发送请求信息，安全程序101可将应用标识(userid)依次传送给ree层的第二风控管理服务102以及tee层的第二风控ta103。
154.本步骤中，在接收到请求消息后，终端设备100风控体系中的安全程序101、第二风控管理服务(sdk)102以及第二风控ta103会分别进行状态信息的采集。可以理解的，第二风控管理服务102在采集数据时不使用公开的应用程序接口(api)，并具备反调试、反注入、内存校验等优势；在数据传输时具有防重放攻击等特点。
155.在一个示例中，当前状态信息包括安全等级依次降低的一级状态信息、二级状态信息和三级状态信息。各级状态信息的示例可参照前述实施例的描述，此处不再赘述。在接收到请求信息后，安全程序101采集安全等级和可信程度等级最低的三级设备状态信息，并将三级设备状态信息发送至ree层的第二风控管理服务102。第二风控管理服务102采集安全等级和可信程度等级次高的二级状态信息，并将三级状态信息和收到的二级状态信息一并发送至tee层的第二风控ta103中。第二风控ta103采集安全等级和可信程度等级最高的一级状态信息，由此第二风控ta103中包含一级状态信息、二级状态信息以及三级状态信息，即获得全部当前状态信息，第二风控ta103可将当前状态信息预留在终端设备的内存中。在获得全部当前状态信息后，第二风控ta103可对全部当前状态信息利用私钥devstatus_pri进行加密。
156.在步骤s420中，根据第三方应用200的不同授权情况，终端设备100可以向其发送当前状态信息，通过第三方应用200或其对应的第三方厂商服务器300进行风险分析。或者，终端设备100不向第三方应用200发送当前状态信息，而是向设备厂商服务器400发送当前状态信息，通过设备厂商服务器400进行风险分析。
157.在第一个示例中，本示例中步骤s420可以包括如下子步骤s420-10：
158.步骤s420-10，响应于tee层中存在第三方应用对应的第一风控ta，通过tee层的第二风控ta向第三方应用发送当前状态信息。
159.此步骤中，结合前述实施例的描述，第一风控ta202是经过设备厂商服务器400授权后下发至终端设备100中的。由此第二风控ta103可在tee层向第一风控ta202发送当前状态信息，例如发送加密的第一数据。
160.本示例中，第三方应用200在终端设备的tee层获得当前状态信息后，可自行或通
过第三方厂商服务器进行风险分析，确定风险信息，并及时进行预设场景下的风险防控。实施方式可参见前述实施例，此处不再赘述。
161.在第二个示例中，本示例中步骤s420可以包括如下子步骤s420-21～s420-22：
162.步骤s420-21，通过第二风控ta对当前状态信息加密处理，并将加密处理得到的第一数据发送至安全程序；其中，当前状态信息包括：安全等级依次降低的一级状态信息、二级状态信息和三级状态信息；
163.步骤s420-22，通过安全程序向设备厂商服务器发送第一数据或者解密的当前状态信息。
164.其中，在步骤s420-21中，第二风控ta103将一级状态信息、二级状态信息和三级状态信息一起加密处理，得到第一数据。结合前述实施例的描述，终端设备的风控体系分别采集各级状态信息，并汇集在第二风控ta103，第三方应用的应用标识也会传递至第二风控ta103。
165.在此步骤的一个示例中，当各级状态信息逐层下陷到ree层的第二风控ta103时，第二风控ta103可生成一个随机数(random)。第二风控ta103将当前状态信息、第一随机数以及设备状态版本号(devstatus_version)采用公钥加密获得第一数据。可以理解的，设备状态版本号用于表征设备状态信息的不同版本，设备状态版本号可从0开始，每发生变化一次，该设备状态版本号递增1。设备状态版本号可由设备厂商服务器400控制是否递增。此外，终端设备100与设备厂商服务器400还可约定协商加解密协议和加解密协议版本号，比如加解密协议指示加解密过程中所涉及的密钥以及加密所需元素等。若加解密协议不变，其加解密协议版本号始终保持不变；当加解密协议变化，其协议版本号可按变化次数逐次递增加1。
166.本示例中，结合图7的流程所示，第二风控ta103还可以采用随机密钥对第一数据进行签名。例如，采用终端设备100内的随机密钥(f key pri)对第一数据签名，签名后所得签名值记为encrypt_sign_devstatus。对第一数据签名，可有效保证第一数据传输过程中的真实性和完整性，以免数据在传输过程中被篡改。
167.在步骤s420-22中，第二风控ta103可以将第一数据发送给安全程序101，安全程序101将第一数据直接转发给设备厂商服务器400；或者，安全程序101对第一数据解密，向设备厂商服务器400发送解密后的数据。为保证安全性，本公开实施例中通过安全程序101将第一数据对应的签名值encrypt_sign_devstatus转发给设备厂商服务器400。
168.在第三个示例中，本示例的方法中步骤s420还可以包括如下步骤s420-31～s420-22：
169.步骤s420-31，通过第二风控ta对终端设备的设备指纹以及第三方应用的应用标识加密处理，获得第二数据。
170.步骤s420-32，向设备厂商服务器发送第一数据和第二数据。
171.其中，本示例中步骤s420还可包括前述示例中的步骤s420-21～s420-22。
172.在步骤s420-31中，第二风控ta103采用公钥(devstatus_pub)将设备指纹(fid)、应用标识(userid)以及其生成的随机数(random)加密处理，获得第二数据。结合图5的流程所示，该第二数据是匿名化的设备指纹，可记为annoymizedevicefingerprint。采用随机数对设备指纹进行匿名化，随机数在不同次加密时会发生变化，当加密所涉及元素均相同的
情况下，由于随机数的变化性，每次加密所获得的匿名化设备指纹也并不是固定不变的，进一步提升可靠性。从而第三方应用或第三方厂商服务器即使获得第二数据，也不会唯一定位终端设备，有效提升用户隐私安全和终端设备安全。可以理解的，在第二数据中，加密要素还可补充设备状态版本号(devstatus_version)，即对设备指纹(fid)、应用标识(userid)、随机数(random)和devstatus_version加密获得第二数据。
173.在步骤s420-32中，结合图5的流程所示，终端设备可将第一数据对应的签名值encrypt_sign_devstatus以及第二数据annoymizedevicefingerprint均发送至设备厂商服务器400。以便于设备厂商服务器400根据第一数据和第二数据，获得设备指纹以及当前状态信息。
174.本公开实施例中，在终端设备100中需保证用户的隐私安全，终端设备100由安全程序101作为向外界(如设备厂商服务器400)提供状态信息的入口。并且所传输的数据为经过加密和签名的数据，有效保证传输过程中的安全性，最后通过设备厂商服务器400对当前状态信息进行风险分析。
175.在一个示例性的实施例中，图6是本公开实施例提供的一种确定风险信息的方法的示意图。结合图1所示，本实施例的方法被设备厂商服务器400执行。如图6所示，本实施例的方法可以包括如下步骤s610～s630：
176.步骤s610，接收终端设备发送的当前状态信息。
177.步骤s620，根据当前状态信息确定风险信息，其中，风险信息用于表征当前状态信息是否存在风险。
178.步骤s630，向第三方应用对应的第三方厂商服务器发送风险信息和/或风险控制措施。
179.其中，在步骤s610中，设备厂商服务器400可接收终端设备100中安全程序101所发送的当前状态信息。本公开实施例中，以安全程序101发送加密状态的当前状态信息为例描述。
180.在一个示例中，本步骤s610可以包括如下步骤s611：
181.步骤s611，接收终端设备发送的第一数据和第二数据，其中，结合图7所示的流程图，第一数据为终端设备的第二风控ta对当前状态信息加密处理所得，第二数据为第二风控ta对终端设备的设备指纹以及第三方应用的应用标识加密处理所得。此步骤中，结合前述实施方式，设备厂商服务器400接收到第一数据对应的签名值encrypt_sign_devstatus以及第二数据annoymizedevicefingerprint。第一数据中包含加密状态的当前状态信息、第一随机数以及设备状态版本号(devstatus_version)，第二数据中包括加密状态的终端设备100的设备指纹、第三方应用200的应用标识(userid)以及随机数。
182.在步骤s620中，终端设备可以持续性的向设备厂商服务器400上传设备状态信息，由此设备厂商服务器400可建立历史数据库，以按时间顺序存储各终端设备的多个版本的设备状态信息，并为每次的设备状态信息配置对应的设备状态版本号(devstatus_version)。该历史数据库可定时清理或更新，例如每半年或一年清理设备状态信息，更新为新的设备状态信息。可以理解的，每个终端设备的设备指纹不同。设备状态信息变化时，设备状态版本号将发生变化。例如，若当前状态信息与前一次状态信息相同，则二者设备状态版本号记为n。再例如，若当前状态信息与前一次状态信息不同，前一次状态信息的设备状
态版本号记为n，当前状态信息的设备状态版本号则为(n+1)。
183.在接收第一数据和第二数据的场景下，本步骤s620可以包括如下子步骤s621～s622：
184.步骤s621，对第二数据解密获得设备指纹，根据设备指纹获得第一数据解密后的当前状态信息。此步骤中，结合图7所示的流程图，设备厂商服务器400首先利用私钥devstatus_pri对第二数据解密获得设备指纹、随机数、第三方应用的应用标识以及devstatus_version。设备厂商服务器400根据解密所得设备指纹索引终端设备100对应的用于签名第一数据的密钥，利用索引到的密钥对encrypt_sign_devstatus验签，验签通过之后利用私钥devstatus_pri对第一数据解密，获得当前状态信息、随机数以及devstatus_version。
185.此步骤中，设备厂商服务器400还可对数据进行安全验证。例如，对第一数据和第二数据两次解密所得的随机数和devstatus_version进行对比，两次解密所得随机数一致且两次解密所得devstatus_version一致，再进行下一步，如进行确定风险信息。若不一致，则发送拒绝消息。
186.步骤s622，根据当前状态信息确定风险信息。此步骤中，结合图7所示的流程图，设备厂商服务器400在获得当前状态信息后，可对历史数据库中对应终端设备的最近一次的设备状态信息对比(也即当前状态信息的前一次状态信息)，从而确定风险信息。
187.在一示例中，响应于当前状态信息与前一次状态信息相同，确定当前状态信息安全。本示例中，若当前状态信息与前一次相同，认为设备状态信息未被篡改，因此可正常进行预设场景的业务。本示例中，设备厂商服务器400可不向安全程序101或第三方厂商服务器300发送数据，或可向安全程序101发送安全的通知消息，安全程序101可向第三方应用200转发该通知消息。
188.在另一个示例中，响应于当前状态信息与前一次状态信息不同，确定当前状态信息存在风险。本示例中，在当前状态信息变化时，设备厂商服务器400确定存在风险，可分别向安全程序101和第三方厂商服务器300发送风险信息，以便于进行及时风控。例如，将风险信息发送给安全程序101，安全程序101执行预设的风控策略，例如暂停预设场景的业务。再例如，将风险信息发送给第三方厂商服务器300，以间接发送至第三方应用200。
189.本示例中的步骤s620还可以包括如下步骤：s6201、根据当前状态信息与前一次状态信息的变化程度，确定风险等级。此步骤中，可对当前状态信息中发生变化的数据比例进行统计，将数据比例大于第一阈值的确定为高风险等级，将数据比例在第一阈值与第二阈值之间的确定为中风险等级，将数据比例小于第二阈值的确定为低风险等级，有利于针对性的进行风控处理。
190.在步骤s630中，在设备厂商服务器400向第三方厂商服务器300发送风险信息的实施方式中，第三方厂商服务器300可根据风险信息自行确定风险控制措施。本公开实施例中，结合图1粗线示意的流程，可通过设备厂商服务器400根据风险信息确定风险控制措施，并将所确定的风险控制措施发送给第三方厂商服务器300，由此第三方厂商服务器300可指示第三方应用200执行风险控制措施。
191.本步骤中，设备厂商服务器400向第三方厂商服务器300发送风险信息或者风险控制措施的方式，可以是按照双方协商约定的方式进行。比如，按照双方约定的数据格式(例
如json格式)进行发送，并可以采用加密传输的方式进行发送数据。
192.可以理解的，设备厂商服务器400可为各终端设备100分配公私钥对进行数据的加解密，其中，公私钥对包括公钥devstatus_pub和私钥devstatus_pri。公钥devstatus_pub在终端设备100中，私钥devstatus_pri在设备厂商服务器400。
193.本公开实施例中，结合图7所示的流程图，设备厂商服务器400在解密获得当前状态信息并且数据经过验签后，可存储当前状态信息或者将该终端设备100的设备信息更新为当前状态信息。
194.本实施例中，设备厂商服务器400还可向终端设备100反馈接收到当前状态信息。例如，设备厂商服务器400将随机数或devstatus_version作哈希的消息认证码(hash-based message authentication code，hmac)运算，运算结果记为rsp_token。设备厂商服务器400将rsp_token发送给终端设备100的安全程序101，表明已确认接收到当前状态信息。安全程序101将rsp_token依次发送给第二风控管理服务102和第二风控ta103。
195.若第二风控ta103一直未收到rsp_token，将任务设备厂商服务器400未收到当前状态信息，需进行重传。
196.本公开实施例中，设备厂商服务器400与终端设备100之间进行安全的数据传输，以便于可通过设备厂商服务器400确定风险信息，无需向第三方应用200或第三方厂商服务器300发送设备指纹，从而第三方应用200或第三方厂商服务器300无法唯一定位终端设备，有利于保证用户隐私安全。
197.在一个示例性的实施例中，图8是本公开实施例提供的一种确定风险信息的方法的示意图。结合图1所示，本实施例的方法被第三方厂商服务器300执行。如图8所示，本实施例的方法可以包括如下步骤s810，或者步骤s810～s830：
198.步骤s810，接收第三方应用发送的风险信息，或者接收设备厂商服务器发送的风险信息。
199.步骤s820，根据风险信息，确定预设场景下的风险控制措施。
200.步骤s830，向第三方应用发送风险控制措施。
201.其中，步骤s810至步骤s830的实施方式可参见前述实施例的描述，此处不再赘述。
202.本公开实施例中，第三方厂商服务器300根据风险信息，及时进行风险控制，以便于保证自身利益以及终端设备的安全。
203.在一个示例性的实施例中，本公开实施例还提出了一种确定风险信息的装置，被配置于第三方应用。如图9所示，本实施例的装置包括：获取模块901和第一确定模块902。本实施例的装置用于实现如图2至图3所示的方法。其中，获取模块901用于在终端设备的可信执行环境tee层获取终端设备的当前状态信息。第一确定模块902用于根据当前状态信息确定风险信息，其中，风险信息用于表征当前状态信息是否存在风险。
204.在一个示例性的实施例中，本公开实施例中还提出了一种确定风险信息的装置，被配置于终端设备。如图10所示，本实施例的装置包括：第二确定模块1001以及第一发送模块1002。本实施例的装置用于实现如图4至图5所示的方法。其中，第二确定模块1001用于响应于接收到第三方应用的请求消息，确定终端设备的当前状态信息；其中，请求消息中包括所述第三方应用的应用标识。第一发送模块1002用于在tee层向第三方应用发送当前状态信息，或者，向设备厂商服务器发送当前状态信息。
205.在一个示例性的实施例中，本公开实施例中还提出了一种确定风险信息的装置，被配置于设备厂商服务器，如图11所示，本实施例的装置包括：第一接收模块1101、第三确定模块1102以及第二发送模块1103。本实施例的装置用于实现如图6至图7所示的方法。其中，第一接收模块1101用于接收终端设备发送的当前状态信息。第三确定模块1102用于根据当前状态信息确定风险信息，其中，风险信息用于表征当前状态信息是否存在风险。第二发送模块1103用于向第三方应用对应的第三方厂商服务器发送风险信息和/或风险控制措施。
206.在一个示例性的实施例中，本公开实施例中还提出了一种确定风险信息的装置，其特征在于，被配置于第三方厂商服务器。如图12所示，本实施例的装置包括：第二接收模块1201。其中，第二接收模块1201用于接收第三方应用发送的风险信息，或者接收设备厂商服务器发送的风险信息。
207.当确定风险信息的装置为终端设备时，其结构还可参照图13所示。如图13所示是一种电子设备的框图。本公开还提供了一种电子设备，例如，设备600可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。
208.设备600可以包括以下一个或多个组件：处理组件602，存储器604，电力组件606，多媒体组件608，音频组件610，输入/输出(i/o)的接口612，传感器组件614，以及通信组件616。
209.处理组件602通常控制设备600的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件602可以包括一个或多个处理器620来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件602可以包括一个或多个模块，便于处理组件602和其他组件之间的交互。例如，处理组件602可以包括多媒体模块，以方便多媒体组件608和处理组件602之间的交互。
210.存储器604被配置为存储各种类型的数据以支持在设备600的操作。这些数据的示例包括用于在设备600上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器604可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。
211.电力组件606为设备600的各种组件提供电力。电力组件606可以包括电源管理系统，一个或多个电源，及其他与为装置600生成、管理和分配电力相关联的组件。
212.多媒体组件608包括在设备600和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(lcd)和触摸面板(tp)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件608包括一个前置摄像头和/或后置摄像头。当设备600处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。
213.音频组件610被配置为输出和/或输入音频信号。例如，音频组件610包括一个麦克风(mic)，当设备600处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器604或经由通信组件616发送。在一些实施例中，音频组件610还包括一个扬声器，用于输出音频信号。
214.i/o接口612为处理组件602和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。
215.传感器组件614包括一个或多个传感器，用于为设备600提供各个方面的状态评估。例如，传感器组件614可以检测到设备600的打开/关闭状态，组件的相对定位，例如组件为设备600的显示器和小键盘，传感器组件614还可以检测设备600或设备600一个组件的位置改变，用户与设备600接触的存在或不存在，设备600方位或加速/减速和装置600的温度变化。传感器组件614可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件614还可以包括光传感器，如cmos或ccd图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件614还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。
216.通信组件616被配置为便于设备600和其他设备之间有线或无线方式的通信。设备600可以接入基于通信标准的无线网络，如wifi，2g或3g，或它们的组合。在一个示例性实施例中，通信组件616经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件616还包括近场通信(nfc)模块，以促进短程通信。例如，在nfc模块可基于射频识别(rfid)技术，红外数据协会(irda)技术，超宽带(uwb)技术，蓝牙(bt)技术和其他技术来实现。
217.在示例性实施例中，设备600可以被一个或多个应用专用集成电路(asic)、数字信号处理器(dsp)、数字信号处理设备(dspd)、可编程逻辑器件(pld)、现场可编程门阵列(fpga)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述的方法。
218.本公开另一个示例性实施例中提供的一种非临时性计算机可读存储介质，例如包括指令的存储器604，上述指令可由设备600的处理器620执行以完成上述方法。例如，计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。当存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述的方法。
219.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本技术旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。
220.应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。