Risk control method, electronic equipment and computer readable medium

Abstract

The invention relates to the technical field of computers, in particular to a risk control method, electronic equipment and a computer readable medium. According to the method, SE risk data correspondingly generated when a security element of a user terminal detects an attack and some system risk data collected by an operating system of the user terminal in some system security detection or environment detection and other processes are provided for a server with risk control decision-making capability for executing risk control decision-making. According to the method, the diversification and comprehensiveness of the risk data for risk control management are improved, so that the accuracy of risk control decision making is improved, the payment transaction risk is reduced, and the safety of user property and personal information is guaranteed.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a risk control method, electronic equipment and computer-readable medium. Background Art

[0002] With the development of terminal technology, users can use mobile phones and other user terminals to complete payment transactions and verify user identity information to handle various services related to user property safety. Correspondingly, the server or cloud responsible for processing the above payment transactions or identity verification related services can perform risk control management on the above payment transactions or identity verification related services in which the user terminal participates during the processing process.

[0003] However, the risk data currently used in the above-mentioned risk control decisions usually comes from the federated data stored in the corresponding models or algorithms such as the federated learning model deployed on the server, or from the cloud risk data updated on the operating platform such as the bank backend running on the server. The source of this part of risk data is relatively single, and the data is not comprehensive enough, especially some risk data detected by the secure element (SE) configured on user terminals such as mobile phones cannot be obtained. This will lead to a low accuracy rate of risk control decisions, which may in turn increase the corresponding transaction risks and the probability of causing user property losses. Summary of the invention

[0004] The present application provides a risk control method, an electronic device, and a computer-readable medium, which collects SE risk data generated corresponding to security element detection attacks through a user terminal performing payment transactions, and uses the data as one of the data sources for the payment server to make risk control decisions, thereby improving the diversity and comprehensiveness of risk data, thereby facilitating improving the accuracy of risk control decisions, reducing payment transaction risks, and protecting user property and personal information security.

[0005] In a first aspect, the present application provides a risk control method, which includes: a first device detects a first business request, and executes a first business in response to the first business request; the first device detects a risk data acquisition request; the first device sends first risk data to a second device in response to the risk data acquisition request, wherein the first risk data includes recorded data of a security element in the first device.

[0006] For example, the first device may be a user terminal such as a mobile phone, and the second device may be a payment server for determining the risk level of each payment transaction in which the user terminal participates. The above-mentioned first risk data may be data recorded corresponding to a security element configured by a user terminal such as a mobile phone, that is, the recorded data of the above-mentioned security element, which may be referred to as SE risk data in this application. The first service request detected by the above-mentioned first device may be, for example, a payment command received by a user terminal such as a mobile phone from a transaction counterparty device, and the transaction counterparty device may be, for example, a POS machine or a barcode scanning gun mentioned below, or a payment transaction platform associated with an online payment, such as a shopping application. Before receiving the above-mentioned first service request, a user terminal such as a mobile phone may establish a connection with the transaction counterparty device for payment transactions in response to operations such as swiping a card or presenting a collection / payment code performed by the user.

[0007] It can be understood that the risk control method provided in the first aspect above can provide SE risk data collected by the security element of the user terminal such as a mobile phone to transmit itself to the payment server, as one of the data sources for the payment server to conduct risk assessment for related payment transaction services (such as the first service mentioned above). In this way, the diversity and comprehensiveness of the risk data relied on by the payment server for risk control management can be improved, which is conducive to improving the accuracy of risk control decisions, reducing payment transaction risks, and protecting user property and personal information security.

[0008] In a possible implementation of the first aspect above, the recorded data of the security element in the first device includes: data generated and recorded by the first device based on the attack detected by the security element; or fused data generated by the first device based on the attack detected by the security element, where the fused data is obtained by fusion of the recorded data of the security element and the data of the operating system of the first device.

[0009] That is, the first risk data provided by the first device (e.g., a user terminal such as a mobile phone) to the second device (e.g., a payment server) may be the recorded data generated when the security element of the user terminal such as a mobile phone is attacked, or may be the recorded data obtained by integrating the data recorded when the security element is attacked with the relevant data collected by the operating system. The relevant data collected by the operating system may include, for example, the time, location, network environment, etc. corresponding to the attack on the security element, which is not limited here.

[0010] In a possible implementation of the first aspect above, the method above also includes: the first device sends second risk data to the second device in response to the risk data acquisition request, wherein the second risk data is recorded data related to the first business recorded by the operating system of the first device.

[0011] For example, the second risk data mentioned above can be system security data detected by the operating system of a user terminal such as a mobile phone when performing some system security detection, and environmental data detected by the environmental detection, etc., which can be called system risk data and will not be elaborated here. The above possible implementation is that user terminals such as mobile phones can also provide system risk data to the payment server for risk control management. In this way, the types of risk data provided by the first device to the second device can add some data types, which is more conducive to improving the accuracy of risk control decisions, reducing payment transaction risks, and protecting user property and personal information security.

[0012] In a possible implementation of the first aspect, the first device establishes a communication connection with the third device through near field communication, the first service includes a first payment service triggered by the first device in response to a payment command initiated by the third device, and,

[0013] The first device detects the risk data acquisition request, including: the first device receives the risk data acquisition request sent by the second device through the third device;

[0014] Furthermore, the first device sends the first risk data to the second device in response to the risk data acquisition request, including: in response to the risk data acquisition request, the first device sends the first risk data to the second device through the third device, wherein the third device establishes a communication connection with the second device via a wireless or wired manner.

[0015] For example, the third device may be a POS machine that establishes a connection with a user terminal such as a mobile phone of a user through a near field communication method such as NFC. A user terminal such as a mobile phone may receive a risk data acquisition request issued by a second device (such as a payment server) through a POS machine, and return the requested risk data, such as SE risk data, to the second device through the POS machine. Among them, the payment command initiated by the third device may be, for example, a payment command sent by a POS machine to a user terminal such as a mobile phone after receiving relevant transaction information provided by a user terminal such as a mobile phone in response to a user's card swiping operation, and the payment command may correspond to the first service request.

[0016] In a possible implementation of the first aspect, the first device sends the second risk data to the second device in response to the risk data acquisition request, including:

[0017] The first device sends first risk data and second risk data to the third device based on a first session established between the first device and the third device, wherein the first session is used to transmit a first acquisition request and the first risk data and second risk data corresponding to the first acquisition request between the third device and the first device.

[0018] In a possible implementation of the first aspect above, the first device sends the first risk data and the second risk data to the third device based on the first session established between the first device and the third device, including: the first device responds to the first initialization instruction sent by the third device, and obtains the ID of the first session carried by the first initialization instruction; the first device responds to the first initialization instruction, and establishes a first session with the third device; the first device sends the first risk data to the third device, and stores the first risk data and the second risk data in association with the ID of the first session; and the first device receives the first acquisition request sent by the third device through the first session, and sends the first risk data and the second risk data stored in association with the ID of the first session through the first session.

[0019] For example, a user terminal such as a mobile phone can respond to a risk data acquisition request forwarded by a POS machine for a corresponding transaction, and establish a session with the POS machine for transmitting the risk data acquisition request (such as the first acquisition request mentioned above) and risk data. At this time, the session can be used to request SE risk data and system risk data at the same time.

[0020] Correspondingly, mobile phones and other user terminals can respond to the risk data acquisition request transmitted by the POS machine through the above-mentioned first session, first feedback the recorded SE risk data to the POS machine, and then return the associated stored SE risk data and system risk data through the established first session. In this way, it can be ensured that when the mobile phone and other user terminals are turned on and the network environment is good, the SE risk data is promptly provided to the payment server through the POS machine for risk control management. Even if the mobile phone and other user terminals use the offline payment function, the SE risk data can be transmitted to the payment server through the POS machine. Furthermore, through the established first session, mobile phones and other user terminals can provide all the collected SE risk data and system risk data to the payment server through the POS machine, and the risk data provided at this time can be richer and more comprehensive.

[0021] In a possible implementation of the first aspect above, the first device sends second risk data to the second device in response to a risk data acquisition request, including: the first device sends the second risk data to the third device based on a second session established between the first device and the third device, wherein the second session is used to transmit the second acquisition request and the second risk data corresponding to the second acquisition request between the third device and the first device.

[0022] In a possible implementation of the first aspect above, the first device sends second risk data to the third device based on a second session established between the first device and the third device, including: the first device responds to a second initialization instruction sent by the third device, and obtains an ID of the second session carried by the second initialization instruction; the first device responds to the second initialization instruction, and establishes a second session with the third device; the first device associates and stores the second risk data with the ID of the second session; and the first device receives a second acquisition request sent by the third device based on the ID of the second session, and sends the second risk data associated and stored with the ID of the second session through the second session.

[0023] For example, a user terminal such as a mobile phone can respond to a risk data acquisition request transmitted by a POS machine through the above-mentioned first session, first feedback the recorded SE risk data to the POS machine, and then return the associated stored system risk data through the established second session. In this way, it can be ensured that when a user terminal such as a mobile phone is turned on and the network environment is good, the SE risk data is provided to the payment server through the POS machine in a timely manner for risk control management. Furthermore, through the established second session, a user terminal such as a mobile phone can provide the collected system risk data to the payment server through the POS machine. At this time, the risk data provided can also be more comprehensive, and the SE risk data will not be provided repeatedly, which is also conducive to improving data transmission efficiency.

[0024] In a possible implementation of the first aspect, before establishing the first session or the second session with the third device, the method further includes: the first device detecting a created historical session, and deleting the detected historical session.

[0025] For example, before establishing a first session between the first device and the third device, or before establishing a second session between the first device and the fourth device, the first device (such as a user terminal such as a mobile phone) can first check whether a session established in the historical interaction process already exists locally. If so, in order to ensure the accurate association between the risk data acquisition request to be transmitted and the corresponding risk data, the user terminal such as a mobile phone can first delete the established historical session, and then re-establish the session based on the ID of the second session provided by the POS machine according to the ID of the first session, and store the relevant risk data acquisition request and the corresponding risk data in association with the corresponding session ID. In this way, the accuracy of the risk data provided can be ensured, and it is also beneficial to improve the accuracy of the risk control decision-making of the second device (such as a payment server).

[0026] In a possible implementation of the first aspect, the first device establishes a communication connection with the fourth device by scanning a barcode, the first service includes a second payment service triggered by the fourth device scanning a barcode presented by the first device, and the first device detects a risk data acquisition request, including: the first device receives the risk data acquisition request sent by the second device through the fourth device;

[0027] Furthermore, the first device sends the first risk data to the second device in response to the risk data acquisition request, including: in response to the risk data acquisition request, the first device sends the first risk data to the second device through a fourth device, wherein the fourth device establishes a communication connection with the second device via a wireless or wired manner.

[0028] For example, the fourth device may be a barcode scanner for scanning a code collection / payment code, etc., which is not limited here. At this time, the first device (such as a user terminal such as a mobile phone) can provide SE risk data to the payment server through a barcode scanner.

[0029] In a possible implementation of the first aspect above, the first device sends the first risk data to the second device in response to a risk data acquisition request, including: the first device adds the first risk data and / or the second risk data to the information carried by the barcode; and the first device provides the first risk data and / or the second risk data to the fourth device during the process of establishing a communication connection with the fourth device by scanning the barcode.

[0030] In a possible implementation of the first aspect, the method further includes: the first device receives a prediction result of the second device on the risk level of the first business, wherein the prediction result is determined by the second device based on the first risk data and / or the second risk data.

[0031] In a possible implementation of the first aspect above, the prediction result includes a result indicating that there is a risk in the first business, and the above method also includes: the first device displays a first prompt message, wherein the first prompt message is used to indicate that the second device rejects the result of the first device executing the first business.

[0032] For example, the above prediction result can be that the payment server performs risk scoring on the corresponding payment transaction based on the SE risk data and / or system risk data provided by the user terminal such as a mobile phone, and then compares the calculated risk score with the corresponding score threshold to determine the corresponding prediction result, etc., which is not limited here. It can be understood that the payment server can perform a more accurate risk assessment on the corresponding payment transaction based on the obtained SE risk data, system risk data, traditional federal data, cloud risk data, etc., and thus obtain a more accurate prediction result.

[0033] In a second aspect, the present application provides an electronic device comprising: one or more processors; one or more memories; one or more memories storing one or more programs, wherein when one or more programs are executed by one or more processors, the electronic device executes the risk control method provided by the above-mentioned first aspect and various possible implementations of the first aspect.

[0034] In a third aspect, the present application provides a computer-readable medium having instructions stored thereon, which, when executed on a computer, causes the computer to execute the risk control method provided by the first aspect and various possible implementations of the first aspect.

[0035] In a fourth aspect, an embodiment of the present application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the risk control method provided by the above-mentioned first aspect and various possible implementations of the first aspect.

[0036] The beneficial effects of the second to fourth aspects mentioned above can be referred to the relevant descriptions in the first aspect mentioned above and various possible implementations of the first aspect, and will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 Shown is a schematic diagram of a payment transaction scenario.

[0038] Figure 2a Shown is a schematic diagram of the types of attacks on the security element provided by the embodiment of the present application.

[0039] Figure 2b The figure shows a schematic diagram of a business card based on a security element to ensure security provided by an embodiment of the present application.

[0040] Figure 2c Shown is a schematic diagram of the data structure of system risk data provided in an embodiment of the present application.

[0041] Figure 3 Shown is a schematic diagram of an end-cloud collaborative risk control system architecture provided in an embodiment of the present application.

[0042] Figure 4 Shown is a schematic diagram of the end-cloud structure based on which a risk control method provided in an embodiment of the present application is implemented.

[0043] Figure 5a Shown is a schematic diagram of the implementation process of a risk control method provided in Example 1 of the present application.

[0044] Figure 5b FIG. 1 is a schematic diagram of another implementation process of a risk control method provided in Example 1 of the present application.

[0045] Figure 6 The figure is a schematic diagram of an implementation process of collecting SE risk data by a security element in an attack scenario provided by Example 1 of the present application.

[0046] Figure 7a The figure shows a schematic diagram of a process in which an existing security element triggers self-destruction when a security sensor detects an attack.

[0047] Figure 7b The figure is a schematic diagram of the process of triggering self-destruction of the security element provided in Example 1 of the present application when the security sensor detects an attack.

[0048] Figure 7c The figure shows a schematic diagram of the process of the security element provided in Example 1 of the present application detecting attacks based on Applet and collecting SE risk data.

[0049] Figure 8 Shown is a schematic diagram of the implementation process of a risk control method provided in Example 2 of the present application.

[0050] Fig. 9 Shown is a schematic diagram of the structure of a software execution environment provided by a mobile phone provided in an embodiment of the present application.

[0051] Fig.10 The figure shows a hardware structure diagram of a user terminal provided in an embodiment of the present application.

[0052] Fig.11 The figure is a schematic block diagram of the software system architecture of a user terminal provided in an embodiment of the present application.

[0053] Fig.12 The figure shows a software structure diagram of another user terminal provided in an embodiment of the present application that can provide different execution environments. DETAILED DESCRIPTION

[0054] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0055] refer to Figure 1 In the scenario shown, when a user uses mobile phone 100 to perform a transaction, mobile phone 100 may, for example, run a wallet application or WeChat TM , Alipay TM Payment applications (application, APP), etc., display Figure 1The payment interface 101 shown. The wallet application usually needs to manage the bank cards added by the user through the Applet running on the SE, for example, displaying the payment code 102 of "XX Bank" on the above payment interface 101, and displaying the prompt information 103 and other simulated cards 104 that support near field communication (NFC), including company access cards, car keys, etc. The content of the prompt information 103 can be, for example, "Please put the back of the phone close to the POS machine or show the QR code". The POS machine and the barcode scanning gun with the barcode scanning function can be Figure 1 The illustrated scenario is just an example of the acceptance terminal 300 and is not limited here.

[0056] According to the prompt information 103, the user brings the back of the mobile phone 100 close to the acceptance terminal 300 or presents a barcode (such as a QR code) to the acceptance terminal 300 for scanning, thereby initiating an offline transaction, and the acceptance terminal 300 can initiate a transaction confirmation request to the server 200. In other embodiments, the user can also use the mobile phone 100 to initiate an online transaction, such as using the mobile banking installed on the mobile phone 100 to transfer transactions or placing orders on a shopping app for payment transactions, etc., and the mobile phone 100 can initiate a transaction confirmation request to the server 200.

[0057] When the server 200 receives a transaction request initiated by the mobile phone 100 or the acceptance terminal 300, the server 200 can make a risk control decision based on some of the risk data that has been obtained, and then determine the transaction confirmation result of passing or rejecting the transaction based on the decision result. For example, if the server 200 determines that the current transaction is risk-free or the risk control score is lower than the threshold based on the risk data, the transaction confirmation result of the successful transaction can be fed back to the mobile phone 100 through the transaction request. On the contrary, if the processor 200 determines that the current transaction is risky or the risk control score is higher than the threshold, the transaction request can be rejected and the transaction confirmation result of the failed transaction can be fed back to the mobile phone 100.

[0058] However, as mentioned above, the risk data source based on which the server makes risk control decisions is relatively single and the data is not comprehensive. Therefore, when users make payment transactions or identity authentication through user terminals such as mobile phones 100, the server that handles the relevant business cannot make risk control decisions based on the risk data generated on the SE, which will lead to low decision accuracy and increase security risks in transactions and other aspects.

[0059] In order to solve the above problems, the present application provides a risk control method. Specifically, the method provides the SE risk data generated when the security element of the user terminal detects an attack, and some system risk data collected by the operating system of the user terminal during some system security detection or environmental detection, to a server with risk control decision-making capabilities for executing risk control decisions.

[0060] Among them, the above-mentioned server with risk control decision-making capabilities can be, for example, a payment server. In some embodiments, the server can also be called a risk control server. The above-mentioned SE risk data and system risk data are provided to the payment server for risk control decision-making, which can enrich the types of risk data based on which the server makes risk control decisions and provide more sources of risk data for the server. Therefore, the models or algorithms such as the federated learning model deployed on the payment server for risk control decision calculation can perform risk control decision calculations based on more types of risk data, and the corresponding calculated risk control decision results can also be comprehensively determined in combination with the real-time security situation of the user terminal, thereby facilitating the improvement of the accuracy of risk control decisions.

[0061] The above-mentioned SE risk data may be provided to the payment server in at least two ways: the first way is to upload it to the payment server through the operating system of the user terminal, such as the user installing WeChat on the mobile phone. TM , Alipay TM When shopping online using applications such as NFC, the SE risk data generated by the security element corresponding to the attack detected by the security element can be transmitted to the payment server through the operating system. The second method is to upload it to the payment server through an acceptance terminal connected to the user terminal, such as a point of sale (POS, referred to as POS machine). Among them, the POS machine can establish a communication connection with the user terminal through NFC, and the SE risk data collected by the security element can be transmitted to the payment server through the POS machine based on the NFC communication connection. In some embodiments, a user terminal such as a mobile phone runs the above WeChat TM , Alipay TM Applications such as , can also support offline transactions by presenting the collection / payment code. In this transaction scenario, when the user terminal such as a mobile phone presents the collection / payment information, the SE risk data generated by the attack detected by the security element can be transmitted to the payment server through the acceptance terminal such as a barcode scanner, without any restrictions.

[0062] It can be understood that a security element refers to a dedicated hardware or chip used to store and process sensitive data and perform security operations. SE is usually used to protect user identification information, encryption keys, passwords and other sensitive data, and can prevent external malicious parsing attacks and protect data security. The chip that serves as a security element generally has encryption / decryption logic circuits. It can be considered that the security element provides security at the physical level, making these sensitive data more secure and protective during storage and processing. Therefore, SE can run Applet (a smart card application). When the bank cards, transportation cards, etc. managed by it need to perform payment, identity authentication and other operations, they generally need to access the Applet in SE first, and the Applet implements payment transaction authentication, identity authentication and other functions. The payment server that receives payment transactions, identity authentication and other related services participated by the user terminal can make risk control decisions based on some risk data that has been obtained, and then determine the transaction confirmation result of passing or rejecting the transaction based on the decision result. Among them, SE in Android TM There are various integrated forms in user terminals of operating systems such as embedded secure element (eSE), universal integrated circuit card (UICC) and SD Card (secure digital memory card), which are not limited here.

[0063] In addition, WeChat installed on mobile phones, watches and other user terminals TM , Alipay TM As well as online banking and other payment applications (applications, APPs) can improve transaction security by running in a trusted execution environment (TEE). When running such payment APPs for payment transactions or identity authentication and other related services, mobile phones and other user terminals can add the SE risk data collected by the security element to the information carried by the payment / collection code displayed by such applications in related services, and provide it to the payment server through acceptance terminals 300 such as barcode scanners, which will not be elaborated here.

[0064] As an example, refer to Figure 2a As shown, the above SE risk data can be generated based on the attacks detected by the security element, and the attacks may include but are not limited to Figure 2aThe voltage attack, current attack, frequency attack, optical attack, abnormal temperature attack, slice attack and fault injection program attack shown are shown. Among them, voltage attack, current attack and frequency attack are attack methods that act on the circuit connected to the security element; optical attack, for example, uses special light to illuminate the security element chip to try to obtain the private information in the chip; slice attack, for example, can be an attack method that uses tools to cut the security element chip to package the chip in an attempt to obtain the private information in the chip; fault injection, for example, can be an attack method that writes a malicious attack program into the security element chip to perform a program attack, etc. This application will not go into details here.

[0065] In some embodiments, the security element of the user terminal can detect the above-mentioned attacks based on a security sensor. The security sensor can be an integrated circuit or a sensor, which is not limited here. Usually, the security sensor of the security element will trigger the self-destruction of the security element when detecting the above-mentioned attack. In an embodiment of the present application, the security element can generate the above-mentioned SE risk data based on the detection result of the security sensor, or the security element can generate the above-mentioned SE risk data when the security sensor detects a smaller degree of attack (such as a voltage attack, etc.), and trigger self-destruction when a larger degree of attack (such as a slice attack, etc.) is detected. In other embodiments, the security sensor may be missing in the security element. At this time, the security element can detect the above-mentioned attacks on bank cards, transportation cards, etc. managed by the security element according to the running Applet, which is not limited in this application.

[0066] refer to Figure 2b As shown, in some embodiments, business cards that are secured by security elements may include bank cards, transportation cards, car keys, work cards, access cards, and citizen network electronic identities (electronic identities, eIDs), etc., where eIDs can also be referred to as electronic certificates.

[0067] In some embodiments, the operating system of the user terminal can detect some risk data when performing system security detection or environmental detection, which can be referred to as system risk data in the present application embodiment. The system risk data can be provided to the payment server together with the risk data generated when the security element is attacked to improve the accuracy of the server's risk control decision-making.

[0068] refer to Figure 2cAs shown, the risk data from the operating system, i.e., the above-mentioned system risk data, may include system security data detected by the system security detection and environmental data detected by the environment detection. Among them, the system security data may be the risk data detected when the operating system of the user terminal performs some security detections, including root detection, system integrity detection, malicious application detection, associated device detection, real machine detection, and system risk data detected by the official ROM detection. Among them, the ROM in the official ROM detection is the abbreviation of read-only memory image (ROM image). If it is detected that there are some potential risks due to the presence of unofficial ROM in the system, the detection result and the source of ROM may be reported as system risk data.

[0069] In addition, the above environmental data may include, for example, the location, displacement, time, subscriber identity model (SIM) card status, universal serial bus (USB) status, etc. acquired by the operating system of the user terminal. These environmental data can be combined with the above system security data or SE risk data at a specific time and place to identify some transaction risks, so as to timely avoid the user from suffering property losses in risky transactions.

[0070] It is understandable that the risks brought by illegal users performing payment transactions, changing passwords, and other operations on user terminals such as mobile phones may include illegal personnel obtaining the owner's private information through some illegal means, and transferring money, defrauding, and other operations through payment applications on mobile phones and other terminals, which damage the user's personal information security and property security. Therefore, the payment server can make risk control decisions with higher accuracy based on the system risk data detected by the operating system of user terminals such as mobile phones and the SE risk data generated when the security element detects an attack. A higher accuracy of risk control decisions can also better protect the security of users' property and privacy information.

[0071] It can be understood that the user terminals applicable to the risk control method provided in the embodiments of the present application may include but are not limited to the above-mentioned mobile phones, tablet computers, desktops, laptops, handheld computers, netbooks, and wearable devices such as augmented reality (AR) / virtual reality (VR) devices, smart TVs, smart watches, car equipment, portable game consoles, portable music players, reader devices, and other electronic devices with one or more processors and security elements. In some embodiments, the above-mentioned user devices may also be called security devices in other embodiments because they are equipped with security elements, which is not limited here.

[0072] The above-mentioned server may be, for example, a payment server, which may be understood as a server used by a third party in the payment transaction process to confirm whether the payment transaction is successful, such as a server used by a bank to confirm whether a payment transfer is successful, and may also be referred to as a risk control server, etc. The above-mentioned payment server or risk control server may include, but is not limited to, a cloud server, a server cluster, an application server, a communication server (such as a mail server, a fax server, a file transfer protocol (FTP) server, etc.), a website server, a database server, and a workgroup-level server, a department-level server, an enterprise-level server, etc., without limitation herein.

[0073] Figure 3 According to an embodiment of the present application, a schematic diagram of a risk control system architecture of end-cloud collaboration is shown.

[0074] like Figure 3 As shown, the risk control system 300 may include a decision operation module 310, a decision calculation module 320 and a risk data collection module 330. The decision operation module 310 and the decision calculation module 320 may be run on the server 200, and the risk data collection module 330 may be run on the user terminal.

[0075] Specifically, the decision-making operation module 310 may include a real-time risk control decision module 311 and a risk control operation management module 312. The real-time risk control decision module 311 may provide real-time risk control decision-making capabilities. The risk control decision-making capabilities include the ability to cope with various payment risks, including but not limited to the ability to avoid merchant transaction risks.

[0076] The risk control operation management module 312 can be used to manage the rules for estimating the degree of risk adopted in risk control decisions. The risk control operation management module 312 can set model parameters or algorithm parameters to the decision calculation module 320, and can also obtain the results of the decision calculation from the decision calculation module 320 and provide them to the real-time risk control decision module 311 for risk control decision-making.

[0077] The decision-making calculation module 320 can provide the models and algorithms required to execute risk control decisions, including the end-cloud federated learning model and the cloud-to-cloud federated learning model based on federated learning (a distributed machine learning method). Among them, "end" refers to the user terminal or the acceptance terminal. The user terminal includes electronic devices such as mobile phones, tablet computers, and laptops used by users, and the acceptance terminal includes the above-mentioned POS machines and other electronic devices. For the above-mentioned federated learning model, specific reference can be made to the implementation mechanism of some existing federated learning models, which will not be elaborated in this application. The decision-making calculation module 320 can obtain various risk data provided by the risk data collection module 330, perform relevant calculations using the above-mentioned models and algorithms, and provide the calculation results to the above-mentioned decision operation module 310 for risk decision-making.

[0078] The risk data collection module 330 can be used to collect and store risk data from various sources, including federal data, system risk data from the user terminal operating system, SE risk data collected from the security element of the user terminal, and cloud risk data synchronized from other service areas or the cloud. Among them, federal data refers to the original risk data concentrated on a central server for use in federated learning. Federated learning allows learning model updates to be shared between devices that retain and process data locally, thereby protecting the privacy of individual user data. The cloud risk data may include sample data for training the models required to execute the risk control decisions mentioned above, as well as historical risk data used by the above-mentioned decision calculation module to provide risk control decision results based on the corresponding model, etc., without limitation here.

[0079] In other embodiments, some user terminals may also run the decision calculation module 320 and the decision operation module 310. At the same time, the risk data collection module 330 may also run on a payment server or other server 200 with a storage function, and is used to store the collected federal data, system risk data from the operating system, SE risk data, and risk data synchronized with the cloud, etc., which are not limited here.

[0080] It can be understood that the user terminal applicable to the risk control method provided in the embodiment of the present application can install a hardware isolated trusted execution environment (TEE) to run the security element to improve the security performance of the security element. The lower the risk level indicated by the SE risk data and the lower the risk level indicated by the system risk data, the result of the risk decision made by the above-mentioned decision operation module 310 based on the calculation result of the decision calculation module 320 is more inclined to confirm the corresponding payment transaction or pass the corresponding payment transaction. In other embodiments, the result of the above-mentioned risk decision may also correspond to low risk or no risk.

[0081] Based on the above Figure 3The risk control system architecture shown below is combined with Figure 4 Introduce the end-cloud structure involved in the risk control process of the risk control system.

[0082] Figure 4 According to an embodiment of the present application, a schematic diagram of a terminal-cloud structure based on which a risk control method is implemented is shown.

[0083] like Figure 4 As shown, the end-cloud structure may include a user terminal 400 on the end side and a server 200 on the cloud side. The user terminal 400 may include the mobile phone 100 described above, on which an operating system 110 may be installed and a security element 120 may be configured.

[0084] The server 200 may include a payment server 210, which may have the ability to execute risk control decisions, for example, a risk control module may be provided in the payment server 210. In some embodiments, the server 200 may also include a payment server 210 and a risk control server, respectively, to execute transaction confirmation and risk control decisions, which is not limited here.

[0085] Some payment apps 111 may be installed in the operating system 110 of the user terminal 400, and a system risk control management module 112 may be configured. The system risk control management module 112 may collect the system security data detected by the operating system and the collected environment data, and report them to the server 200 as system risk data. During the reporting process, the system risk control management module 112 may encrypt the system risk data using a system risk control key to ensure data security.

[0086] Continue to refer Figure 4 As shown, the security element 120 configured in the user terminal 400 can run Applet 121 and SE risk control management module 122. As mentioned above, Applet 121 can be used to implement payment transaction authentication, identity authentication, etc. for managed bank cards, transportation cards, eIDs, etc. The security element 120 can also be configured with a security sensor 123 to detect various attacks against the security element.

[0087] The SE risk control management module 122 can collect the SE risk data generated when the security element detects an attack, and can transmit the collected SE risk data to the server 200 through the system risk control management module 112 in the operating system 110. Alternatively, the SE risk control management module 122 can also transmit the SE risk control data to the server 200 through the NFC module through a POS terminal or other acceptance terminal.

[0088] It can be understood that in the process of transmitting SE risk data through the system risk control management module 112 or the acceptance terminal, the SE risk data can also be encrypted using the SE risk control key to ensure data security. The SE risk control key can be the same as or corresponding to the system risk control key, and can share the key with the server 200, so that the server 200 can decrypt and obtain the SE risk data and system risk data.

[0089] Continue to refer Figure 4 As shown, the system risk control management module 112 of the operating system 110 can also transmit system risk data to the SE risk control management module 122. When the user terminal 400 is not connected to the Internet (also known as offline) or performs payment transactions through offline transaction methods such as swiping a card, presenting a collection / payment code, etc., the system risk control management module 112 can transmit system risk data to the SE risk control management module 122. At this time, the SE risk control management module 122 can transmit the received system risk data together with the SE risk data to the POS machine, and transmit the system risk data to the server 200 through the acceptance terminal 300 such as the POS machine. Alternatively, the SE risk control management module 122 can also add the system risk data and the SE risk data to the information carried by the collection / payment code corresponding to the payment APP 111, so as to transmit it to the server through the acceptance terminal 300 such as a barcode scanner, without limitation. In this way, it can also ensure that the system risk data can be reported to the server 200 when the user device 100 is offline or performing offline transactions, and applied to risk control decisions.

[0090] In the embodiment of the present application, the user terminal 400 may be a mobile phone and the server 200 may be a payment server for example.

[0091] Based on the above Figure 1 The payment transaction scenario shown and Figure 4 The end-cloud structure shown is described in detail below in combination with different embodiments to describe the specific implementation process of the risk control method provided by the present application in online and offline transaction scenarios, in which SE risk data and system risk data are provided to the payment server in different ways.

[0092] In conjunction with Example 1, the following will first introduce in detail the specific implementation process of transmitting SE risk data and system risk data to the payment server for risk control decision-making based on the risk control method provided by the present application in an online transaction scenario.

[0093] Example 1

[0094] Refer to the above Figure 1In the payment transaction scenario shown, the mobile phone 100 can perform offline payment transaction operations by presenting the payment / collection code to the acceptance terminal 300 or approaching the acceptance terminal 300 by swiping the NFC card. After the user pays the acceptance terminal 300 or performs related transaction confirmation operations on the mobile phone 100, the acceptance terminal 300 can accept the transaction and send a transaction confirmation request to the server 200. It can be understood that in the above offline transaction scenario, the mobile phone 100 and the server 200 may not establish a communication connection, and the acceptance terminal 300 may establish a communication connection with the server 200 in a wired or wireless manner. Among them, the server 200 can be a payment server 210, and the acceptance terminal 300 can be a POS machine 301, etc.

[0095] At this time, the SE risk data generated by the security element of the mobile phone 100 and the system risk data collected by the operating system can be transmitted to the server 200 through the acceptance terminal such as the POS machine 301. The server 200 can be, for example, the payment server 210 mentioned above.

[0096] Figure 5a According to an embodiment of the present application, a schematic diagram of an implementation process of a risk control method is shown.

[0097] As an example, Figure 5a As shown, in an offline transaction scenario, the implementation process may involve the interaction between the operating system 110 of the mobile phone 100, the security element 120, the acceptance terminal 300 and the server 200. More specifically, Figure 5a The process shown involves the interaction between the payment server 210 , the system risk control management module 112 , the SE risk control management module 122 , the Applet 121 and the POS machine 301 .

[0098] It should also be stated that the steps in the methods and processes in the embodiments of the present application are numbered for ease of reference, rather than to limit the order of precedence. If there is an order between the steps, the text description shall prevail.

[0099] Specifically, Figure 5a The process shown may include the following steps:

[0100] It can be understood that the implementation process of the risk control method provided in the embodiment of the present application may include the following steps 501 to 503 corresponding to the description of entering the payment transaction scene. In other embodiments, the implementation process of the risk control method can be implemented after entering the payment transaction scene, that is, starting from the following step 504, which is not limited here.

[0101] 501: POS machine 301 detects a payment transaction request.

[0102] Exemplarily, the mobile phone 100 can perform offline payment transaction operation by swiping the card with NFC close to the POS machine 301, which is referred to as offline transaction. At this time, when the POS machine 301 detects the card swiping operation of the mobile phone 100, it can detect the payment transaction request.

[0103] In other embodiments, the mobile phone 100 can also conduct offline transactions by presenting a payment code for scanning by a barcode scanner, which is not limited here.

[0104] 502: POS machine 301 sends a payment command to Applet 121.

[0105] Exemplarily, when the POS machine 301 detects a payment transaction request initiated by a user terminal such as the mobile phone 100, it can send a payment command related to the transaction to the mobile phone 100. The payment command may include, for example, a command for the POS machine 301 to verify the payment account number with the mobile phone 100, a command to verify the identity of the paying user, and a command to input the payment amount corresponding to the transaction for the paying user to determine, etc., which are not limited here.

[0106] It is worth noting that the payment command sent by the POS machine 301 at this time is used to interact with user terminals such as the mobile phone 100, guiding the user to complete relevant payment confirmation operations on the relevant interface of the mobile phone 100, such as verifying fingerprints, verifying the preset deduction password, etc.

[0107] 503: Applet 121 responds to the payment command to the POS machine 301.

[0108] Exemplarily, the mobile phone 100 can respond to the payment command sent by the POS machine 301 based on the Applet 121 running in the security element 120, perform corresponding payment authentication and identity authentication to confirm or reject the payment operation, and then return the response result of the corresponding payment command to the POS machine 301. It is worth noting that the authentication completed by the mobile phone based on Applet 121 and the process of responding to the payment command sent by the POS machine 301 at this time are different from the risk control process performed by the subsequent steps 504 to 519, which can be understood as the process of entering the payment transaction scene before the risk control process performed by steps 504 to 519, which will not be repeated here.

[0109] 504: The POS machine 301 requests the payment server 210 to make a risk control decision for the payment transaction.

[0110] Exemplarily, in order to ensure the security of payment transactions, after completing the transaction with the mobile phone 100, including completing the instruction interaction and obtaining the payment result of the payment made by the mobile phone 100 based on the confirmation returned by Applet 121, the POS machine 301 can request the server of the payment platform associated with the POS machine 301, such as the above-mentioned payment server 210, to make a risk control decision for the payment transaction.

[0111] It can be understood that the payment platform associated with the POS machine 301 can be the bank backend corresponding to the payment account used by the mobile phone 100, or the Alipay corresponding to the payment account. TM or WeChat TM There is no restriction on the account management platform corresponding to payment apps.

[0112] 505: The payment server 210 returns an instruction to obtain SE risk data and system risk data to the POS machine 301.

[0113] Exemplarily, after receiving the above request from the POS machine 301 , the payment server 210 may return an instruction to obtain the SE risk data and the system risk data to the POS machine 301 .

[0114] In some other embodiments, the payment server 210 may also send acquisition instructions for SE risk data and system risk data respectively when executing this step. For details, please refer to the following Figure 5b The relevant descriptions in steps 505a to 505e in the illustrated process are not repeated here.

[0115] It can be understood that the risk data requested by the above-mentioned instructions for obtaining risk data may be SE risk data collected by the security element 120 of the mobile phone 100 and system risk data collected by the operating system 110 of the mobile phone 100 .

[0116] 506: The POS terminal 301 requests the SE risk control management module 122 to initialize the session related to obtaining SE risk data and system risk data.

[0117] Exemplarily, the POS machine 301 can request to obtain SE risk data and system risk data through the SE risk control management module 122 by requesting to establish a session (session) to the SE risk control management module 122. The establishment process of the relevant session can be completed through multiple instructions such as initialization instructions, identity authentication instructions, and session establishment instructions. At this time, the POS machine 301 can send an initialization instruction to the SE risk control management module 122 when executing this step 506 to request the SE risk control management module 122 to generate identification information such as the ID of the relevant session, and then continue to execute the following steps 507 to 513 to complete the establishment of the relevant session and obtain SE based on the session ID.

[0118] It can be understood that since the SE risk control management module 122 may not record the system risk data, or only records the system risk data sent by the mobile phone 100 in response to the request when it was last powered on, the POS machine 301 cannot directly obtain the system risk data from the SE risk control management module 122. At this time, the POS machine 301 can request the SE risk control management module 122 to obtain the system risk data from the operating system 110 of the mobile phone 100 by requesting to establish a session, and return the SE risk data collected by itself and the system risk data obtained from the operating system 110 to the POS machine 301. For each payment transaction, the POS machine 301 can request the mobile phone 100 to obtain the latest system risk data and SE risk data to improve the accuracy of the risk control decision corresponding to the payment transaction.

[0119] 507: The SE risk control management module 122 determines whether the session already exists based on the session ID (identity).

[0120] If the result of the judgment is yes, the SE risk control management module 122 may continue to execute the following step 508 to clear the existing sessions and corresponding system risk data in the historical records;

[0121] If the judgment result is no, the SE risk control management module 122 may continue to execute the following step 509 and send a request to the system risk control management module 112 to obtain system risk data.

[0122] Exemplarily, after receiving the above initial session initiated by the POS machine 301, the SE risk control management module 122 may determine whether the ID of the session already exists. If it already exists, it indicates that the session received at this time may be a session request repeatedly initiated by the POS machine 301 for requesting system risk data for historical payment transactions. If it does not exist, it indicates that the session received at this time should be a session request initiated by the POS machine 301 for the first time for requesting system risk data for the current payment transaction.

[0123] 508: The SE risk control management module 122 clears the existing acquisition session and the historically received system risk data.

[0124] 509: The SE risk control management module 122 sends a request to the system risk control management module 112 to obtain system risk data.

[0125] Exemplarily, the SE risk control management module 122 may request system risk data from the system risk control management module 112 via HCI. After receiving the acquisition request sent by the SE risk control management module 122, the system risk control management module 112 may return the system risk data to the SE risk control management module 122 in an "asynchronous return" manner.

[0126] It can be understood that in the process of the operating system 110 of the mobile phone 100 running the system risk control management module 112 to respond to the request sent by the SE risk control management module 122 in the security element 120, there must be some time difference between the processor (such as the central processing unit, CPU) and the hardware such as the security element 120 in executing the corresponding instructions. Correspondingly, there is usually some time difference in the system risk control management module 112 returning the requested system risk data to the SE risk control management module 122, that is, there is "asynchrony". Therefore, the system risk control management module 112 usually adopts the "asynchronous return" method to return the system risk data to the SE risk control management module 122.

[0127] It can be understood that when the phone is powered off, the operating system 110 of the mobile phone 100 is not working, the system risk control management module 112 will not respond to the request sent by the SE risk control management module 122, and the SE risk control management module 122 may not respond to the request of the POS machine 301. In the powered on state, the SE risk control management module 122 can save the above initial session ID, and execute the above step 509 to send a request to obtain system risk data. After receiving the request for obtaining system risk data sent by the SE risk control management module 122, the system risk control management module 112 collects and prepares the system risk data that can be returned to the SE for a period of time, and then returns the collected system risk data to the SE risk control management module 122. Therefore, the time for the system risk control management module 112 to return the system risk data in the "asynchronous return" method can also be longer or shorter, and there is no limitation here. For detailed example procedures of the above-mentioned "asynchronous return" method, please refer to the following. Figure 6 The relevant descriptions in the corresponding steps in the shown process are not repeated here.

[0128] 510 : The SE risk control management module 122 returns the corresponding SE risk data to the POS terminal 301 .

[0129] Exemplarily, when the SE risk control management module 122 receives the initialization instruction of the relevant session sent by the POS machine 301, it can immediately return the collected SE risk data related to the payment transaction to the POS machine 301. In this way, regardless of whether the SE risk control management module 122 can subsequently obtain the system risk data returned by the system risk control management module 112 in a timely and successful manner, it can ensure that the POS machine 301 can provide the SE risk data collected by itself to the payment server 210 for risk control decision-making, thereby ensuring that the accuracy of risk control decisions can be improved to a certain extent.

[0130] 511: The system risk control management module 112 sends corresponding system risk data to the SE risk control management module 122.

[0131] Exemplarily, referring to the relevant description in the above step 509, the system risk control management module 112 can adopt the "asynchronous return" method, and execute this step 511 to return the system risk data to the SE risk control management module 122 a period of time after the relevant request is received corresponding to the above step 509.

[0132] 512: The SE risk control management module 122 associates and stores the received system risk data and the currently collected SE risk data with the initial session ID.

[0133] Exemplarily, after receiving the system risk data returned by the system risk management module 112 , the SE risk control management module 122 may store the system risk data and the currently collected SE risk data in association with the initial session ID obtained after step 506 above.

[0134] 513: The POS machine 301 initiates a request to obtain SE risk data and system risk data to the SE risk control management module 122 through the session established corresponding to the relevant session ID.

[0135] Exemplarily, the POS machine 301 can initiate an acquisition request to the SE risk control management module 122 based on the relevant session established by executing the above steps 507 to 512, so as to request to obtain the SE risk data and system risk data through the relevant session. It can be understood that the SE risk data and system risk data to be obtained can be the risk data corresponding to the request to obtain when the above step 506 is initialized. At this point, a relevant session that can transmit the acquisition request and the requested SE risk data and system risk data can be established between the POS machine 301 and the SE risk control management module 122.

[0136] 514: The SE risk control management module 122 queries whether there is SE risk data and system risk data stored corresponding to the relevant session ID.

[0137] If the judgment result is yes, that is, there is a matching session ID, then the following step 515 may be continued to send the system risk data corresponding to the session ID;

[0138] If the judgment result is no, that is, there is no matching session ID, the following step 516 can be continued to be executed to return an error value to the POS machine 301.

[0139] Exemplarily, the SE risk control management module 122 can query whether the currently stored session ID matches the session ID carried in the session request sent by the POS machine 301. If it matches, it can be determined that the session ID requested by the POS machine 301 corresponds to the stored SE risk data and system risk data, and then the following step 515 is executed to send the SE risk data and system risk data.

[0140] 515: The SE risk control management module 122 returns the queried SE risk data and system risk data to the POS terminal 301.

[0141] Exemplarily, the SE risk control management module 122 may return the corresponding SE risk data and system risk data matched according to the session ID to the POS machine 301 .

[0142] It can be understood that the length of time that the user swipes the card on the POS machine can affect, to a certain extent, the amount of SE risk data and system risk data that the POS machine 301 obtains from the user terminal. Generally speaking, the longer the card swiping time is, the more time the POS machine 301 and the user terminal have to complete the interaction process and data transmission process of steps 504 to 515, and the higher the amount of data corresponding to the risk data that the POS machine 301 can obtain.

[0143] 516: The SE risk control management module 122 returns an error value to the POS terminal 301.

[0144] Exemplarily, when the SE risk control management module 122 determines that there is no session ID that matches the session ID sent by the POS machine 301, it is unable to return the corresponding system risk data to the POS machine 301. At this time, the SE risk control management module 122 can return a preset error value to the POS machine 301 to inform the POS machine 301 that the corresponding system risk data is not matched.

[0145] It can be understood that the process of managing the correspondence between the session ID and the SE risk data and the system risk data described in the above steps 506 to 516 can ensure the security of the transmission process of the SE risk data and the system risk data.

[0146] 517 : The POS machine 301 transmits the received SE risk data and system risk data to the payment server 210 .

[0147] 518: The payment server 210 combines the SE risk data and the system risk data to make a risk control decision.

[0148] For example, after receiving the SE risk data and system risk data returned by the POS machine 301 in the above corresponding steps, the payment server 210 can combine these two parts of risk data and the above Figure 3 The risk score is calculated based on the federal data and cloud risk data shown. Then, based on whether the calculated risk score is higher or lower than the preset value, it is determined whether the corresponding payment transaction has risks such as fraudulent payment, that is, risk control decisions are made.

[0149] 519: The payment server 210 returns the risk control decision result to the POS terminal 301.

[0150] Exemplarily, the payment server 210 performs risk control decision-making in executing the above step 518, and determines whether the corresponding payment transaction is risk-free or may be risky. For example, after detecting that the corresponding calculated risk score is higher than a preset value, the transaction may be approved or rejected, and the result of the approved transaction or rejected transaction is fed back to the POS machine 301 as the risk control decision result. Conversely, after detecting that the corresponding calculated risk score is lower than a preset value, the payment server 210 may approve the transaction.

[0151] Accordingly, when the POS machine 301 receives the above-mentioned risk control decision result, it can prompt that the transaction has failed, or it can prompt the user to re-enter the transaction password on the POS machine, etc., to further eliminate the risk of the transaction. In some embodiments, the POS machine can also further notify the user terminal, such as the above-mentioned mobile phone 100, of the received risk control decision result. After receiving the risk control decision result, the user terminal such as the mobile phone 100 can display a corresponding prompt interface, such as "This transaction failed, please try again" or "This transaction has risks, please confirm safety and try again", etc., which are not limited here.

[0152] In some embodiments, when the payment server 210 makes the decision to approve or reject the transaction, it may directly execute the result without notifying the POS machine 301, that is, it may not return the risk control decision result to the POS machine 301, and there is no limitation here.

[0153] Based on the execution process of the above steps 501 to 519, the risk management method provided by this application can support providing SE risk data and some system security data, environmental data and other system risk data detected by the system to the server through the acceptance terminal in the offline transaction scenario as the data basis for risk control decision-making. In this way, the accuracy of risk control decision-making by the payment transaction backend (such as the above payment server) can be improved, which is conducive to protecting the property safety and personal information security of users during payment transactions.

[0154] For another implementation process of obtaining SE risk data and system risk data through instructions involved in the above step 505, please refer to Figure 5b The relevant descriptions of steps 505a to 505e are shown.

[0155] like Figure 5b As shown, another implementation process corresponding to the risk management method provided in the embodiment of the present application may include the following steps:

[0156] 501': POS machine 301 detects a payment transaction request.

[0157] 502': POS machine 301 sends a payment command to Applet 121.

[0158] 503': Applet 121 responds to the payment command to the POS machine 301.

[0159] 504': The POS machine 301 requests the payment server 210 to make a risk control decision for the payment transaction.

[0160] The execution contents of the above steps 501' to 504' are the same as those of the above Figure 5a The execution contents of steps 501 to 504 are the same, and the details are as follows. Figure 5a The description of the related steps shown will not be repeated here.

[0161] 505a: The payment server 210 returns an instruction to obtain SE risk data to the POS machine 301.

[0162] 505b: The POS terminal 301 sends a request to the SE risk control management module 122 to obtain SE risk data.

[0163] Exemplarily, in response to the instruction of obtaining SE risk data returned by the payment server 210 , the POS terminal 301 may send a request for obtaining SE risk data to the SE risk control management module 122 .

[0164] 505c: The SE risk control management module 122 returns the recorded SE risk data to the POS terminal 301.

[0165] Exemplarily, the SE risk control management module 122 responds to the above request sent by the POS machine 301, and can return the corresponding SE risk data to the POS machine 301. The SE risk control management module 122 can be set in the security element 120 of the mobile phone 100, and the module can obtain and record the corresponding SE risk data generated when an attack is detected from the Applet 121 or the security sensor 123.

[0166] The detailed implementation process of the security element 120 of the specific mobile phone 100 recording the generated SE risk data in the SE risk control management module 122 when an attack is detected can be referred to the detailed introduction in conjunction with the corresponding drawings below, which will not be repeated here.

[0167] 505d: The POS machine 301 transmits the received SE risk data to the payment server 210.

[0168] Exemplarily, after receiving the SE risk data returned by the SE risk control management module 122 , the POS terminal 301 may transmit the part of the risk data to the payment server 210 for the payment server 210 to make a risk control decision.

[0169] 505e: The payment server 210 returns an instruction to obtain system risk data to the POS machine 301.

[0170] Exemplarily, after receiving the SE risk data transmitted by the POS machine 301 , the payment server 210 may return an instruction for obtaining the system risk data to the POS machine 301 .

[0171] 506 ′: The POS terminal 301 requests the SE risk control management module 122 to initialize the session related to obtaining system risk data.

[0172] With the above Figure 5a The difference from step 506 is that the POS terminal 301 executes step 506' to obtain system risk data through the initial session request, but does not include the SE risk data requested in step 505b. The specific process of POS terminal 301 executing step 506' can refer to the relevant description of step 506, which will not be repeated here.

[0173] 507': ​​The SE risk control management module 122 determines whether the session already exists based on the session ID.

[0174] If the result of the judgment is yes, the SE risk control management module 122 may continue to execute the following step 508 ′ to clear the existing sessions and corresponding system risk data in the historical records;

[0175] If the judgment result is no, the SE risk control management module 122 may continue to execute the following step 509 ′, and send a request to the system risk control management module 112 to obtain system risk data.

[0176] 508': The SE risk control management module 122 clears the existing acquisition session and the historically received system risk data.

[0177] 509': SE risk control management module 122 sends a request for obtaining system risk data to system risk control management module 112. System risk control management module 112 may correspondingly adopt an "asynchronous return" method and return the requested system risk data to SE risk control management module 122 when executing the following step 511'.

[0178] 510 ′: The SE risk control management module 122 returns the corresponding SE risk data to the POS terminal 301 .

[0179] 511 ′: The system risk control management module 112 sends the corresponding system risk data to the SE risk control management module 122 .

[0180] 512': The SE risk control management module 122 associates and stores the received system risk data with the initial session ID.

[0181] With the above Figure 5a The difference from step 512 shown is that the risk data stored in association with the initial session ID by the SE risk control management module 122 in step 512' may include system risk data, but does not include the SE risk data returned to the POS machine 301 in step 505c. The specific process of the SE risk control management module 122 executing step 512' can refer to the relevant description in step 512 above, which will not be repeated here.

[0182] 513': The POS machine 301 initiates a request for obtaining system risk data to the SE risk control management module 122 through the session established corresponding to the relevant session ID.

[0183] With the above Figure 5a The difference from step 513 is that the risk data requested by the session request sent again by the POS machine 301 in step 513' may include system risk data, but does not include the SE risk data received by the POS machine 301 after step 505c. The specific process of the POS machine 301 executing step 513' can refer to the relevant description in step 513 above, which will not be repeated here.

[0184] 514': The SE risk control management module 122 queries whether there is system risk data stored corresponding to the relevant session ID.

[0185] If the judgment result is yes, that is, there is a matching session ID, then the following step 515' may be continued to send the system risk data corresponding to the session ID;

[0186] If the judgment result is no, that is, there is no matching session ID, the following step 516' can be continued to be executed to return an error value to the POS machine 301.

[0187] With the above Figure 5a The difference from step 514 shown is that the risk data stored corresponding to the corresponding session ID queried by the SE risk control management module 122 in step 514' may include system risk data, but does not include the SE risk data returned to the POS machine 301 in the above step 505c. The specific process of the SE risk control management module 122 executing step 514' can refer to the relevant description in the above step 514, which will not be repeated here.

[0188] 515 ′: The SE risk control management module 122 returns the queried system risk data to the POS terminal 301 .

[0189] With the above Figure 5a The difference from the step 515 shown is that the risk data returned by the SE risk control management module 122 to the POS machine 301 after executing the step 515' may include system risk data, but does not include the SE risk data returned to the POS machine 301 in the above step 505c. The specific process of the SE risk control management module 122 executing the step 515' can refer to the relevant description in the above step 515, which will not be repeated here.

[0190] 516': The SE risk control management module 122 returns an error value to the POS machine 301.

[0191] The execution content of this step 516' is the same as the above Figure 5a The execution content of step 516 is the same as that of step 517. Figure 5a The description of step 516 is omitted here.

[0192] 517 ′: The POS machine 301 transmits the received system risk data to the payment server 210 .

[0193] With the above Figure 5a The difference from the step 517 shown is that the risk data returned to the POS machine 301 after the POS machine 301 executes the step 517' may include system risk data, but does not include the SE risk data that the POS machine 301 has returned to the payment server 210 in the above step 505d. The specific process of the POS machine 301 executing the step 517' can refer to the relevant description in the above step 517, which will not be repeated here.

[0194] 518': The payment server 210 combines the SE risk data and the system risk data to make a risk control decision.

[0195] 519': The payment server 210 returns the risk control decision result to the POS terminal 301.

[0196] The execution contents of the above steps 518' to 519' are the same as those of the above steps. Figure 5a The execution contents of steps 518 to 519 are the same, and the details are as follows. Figure 5a The description of steps 518 to 519 is omitted here.

[0197] Regarding the detailed implementation process of the security element 120 involved in the above step 507, when an attack is detected, the generated SE risk data is recorded in the SE risk control management module 122. Figure 6 The process shown is described in detail.

[0198] Figure 6 According to an embodiment of the present application, a schematic diagram of an implementation process of a security element collecting SE risk data in an attack scenario is shown.

[0199] like Figure 6 As shown, the implementation process may involve the interaction between the operating system 110 of the mobile phone 100, the security element 120 and the server 200. More specifically, Figure 6 The illustrated process involves the interaction between the payment server 210 , the system risk control management module 112 , the SE risk control management module 122 , and the security sensor 123 .

[0200] Specifically, Figure 6 The process shown may include the following steps:

[0201] 601: The security sensor 123 detects an attack and determines the type of attack.

[0202] Exemplarily, when a user operates the mobile phone 100 to conduct an online transaction, such as placing an order to purchase goods on a shopping platform, he may be attacked by an attacker. In some embodiments, the attack may be, for example, an attack carried out by an illegal user who operates the mobile phone as described above, such as inputting a transaction password or disguising the fingerprint or voiceprint of a real user for identity authentication through voltage attack, current attack, frequency attack, etc., in an attempt to complete the payment transaction. At this time, if the security element 120 of the mobile phone 100 is equipped with a security sensor 123, the security sensor 123 can detect the above-mentioned various attacks and determine the corresponding attack type.

[0203] 602: The security sensor 123 reports the detected attack type to the SE risk control management module 122.

[0204] For example, the security sensor 123 in the security element 120 may report the type of attack detected to the SE risk control management module 122. The attack type detected by the security sensor 123 may include but is not limited to the above Figure 2a Various types shown.

[0205] 603: The SE risk control management module 122 records the attack type and number as SE risk data.

[0206] Exemplarily, after the SE risk control management module 122 receives the attack type reported by the security sensor 123, it can record the type and update the recorded number of attacks. Among them, the number of attacks recorded by the SE risk control management module 122 can include the number of times corresponding to various attack types and the total number of attacks. Further, the SE risk control management module 122 can also count the number of attacks received within a preset time period and calculate the corresponding attack frequency. The attack frequency can be calculated separately for various types of attacks, or it can be calculated based on the total number of attacks, which is not limited here.

[0207] It can be understood that the above-recorded attack types and the number of attacks or the total number of attacks corresponding to each type can all be recorded or stored as SE risk data.

[0208] 604: The SE risk control management module 122 determines whether the degree of the attack meets the preset conditions.

[0209] If the judgment result is yes, indicating that the security element is under a more serious attack or has been subjected to more serious attacks, the following step 605 may be executed to send a self-destruction command to the security sensor 123 to protect the property safety of the user.

[0210] If the judgment result is no, indicating that the security element is currently attacked to a lesser extent or has been subjected to fewer severe attacks, the following step 606 may be executed to send the SE risk data to the operating system 110 .

[0211] Exemplarily, the above-mentioned preset conditions may be some preset types of attacks that are evaluated as more serious attacks. When the SE risk control management module 122 identifies that the attacker implements these types of attacks, it can be judged that the degree of the attack meets the preset conditions, that is, the program attacked is more serious. The above-mentioned preset conditions may also be preset frequency thresholds or frequency thresholds corresponding to different attack types. When the SE risk control management module 122 detects that the number of times a certain type of attack is suffered within a preset time period is greater than or equal to the preset frequency threshold or frequency threshold, it can be judged that the degree of the attack meets the preset conditions. In some embodiments, the above-mentioned preset conditions may also be a combination of preset types of more serious attacks and frequency thresholds corresponding to each type, such as setting a threshold for the number of times a security element is subjected to serious attacks as a preset condition, etc., which is not limited here.

[0212] 605 : The SE risk control management module 122 sends a self-destruction instruction to the security sensor 123 .

[0213] Exemplarily, when the SE risk control management module 122 determines that the current level of attack meets preset conditions, for example, when it determines that the level of attack is serious, it can send a self-destruction instruction to the security sensor 123 to trigger the security sensor 123 to execute the self-destruction process.

[0214] refer to Figure 7a As shown, usually when a security element is equipped with a security sensor, the security sensor triggers a self-destruction process when it detects an attack.

[0215] In the examples of this application, refer to Figure 7b As shown, when the security sensor detects an attack, it can first report to the SE risk control management module, and the SE risk control management module will then determine whether the attack level suffered by the current security element is serious enough to require self-destruction based on the type and number of attacks received. When the SE risk control management module determines that the security element is suffering a serious attack, it will send a self-destruction instruction to the security sensor, triggering the security sensor to execute the self-destruction process.

[0216] Compare the above Figure 7a and 7b It can be seen from the process shown that, based on the risk management method provided by the present application, while effectively utilizing the SE risk data generated when the security element detects an attack, it is possible to perform a more refined identification of the detected attack on the security element, thereby preventing some lighter attacks from causing the security element to self-destruct, which is beneficial to extending the service life of the security element and user terminals such as mobile phones equipped with the security element.

[0217] 606: The SE risk control management module 122 sends the recorded SE risk data to the system risk control management module 112 and requests to obtain the system risk data.

[0218] Exemplarily, when the SE risk control management module 122 determines that the current degree of attack does not meet the preset conditions, for example, when it is determined that the degree of attack is relatively light or the number of attacks to a certain extent is relatively small, it can send the recorded SE risk data to the system risk control management module 112 in the operating system 110, and obtain the system risk data from the operating system 110 of the mobile phone 100, so as to be used for merging with the SE risk data generated corresponding to the attack on the security element 120, so as to form SE risk data containing more risk control information. In this way, the mobile phone 100 can transmit the collected SE risk data and system risk data to the payment server 210 through the operating system 110, which is more conducive to improving the accuracy of risk control decisions. The specific transmission process can continue to refer to the relevant descriptions in the following steps 607 to 608, which will not be repeated here.

[0219] As an example, the SE risk control management module 122 can send the above SE risk data to the system risk control management module 112 through the host controller interface (HCI). It can be understood that the software environment of the mobile phone 100 includes a rich execution environment (REE) and a trusted execution environment. The security element can run in the TEE. As part of the TEE security function, it can be used to store password secrets with high security requirements. The above HCI can be used to provide a channel for the security element to send data to the REE. The specific software environment of the mobile phone 100 can refer to the relevant description in conjunction with the corresponding drawings below, which will not be repeated here.

[0220] Among them, REE can be used to run general operating systems such as Linux, Hongmeng TM , Android TM In the embodiment of the present application, it can correspond to the above operating system 110. The above general operating system can be used to run services with low security requirements or services that need to collect system-related data, such as NFC services that can be run in the operating system 110. The storage security requirements of such system-related data are usually low. TEE can be used to run highly secure operating systems or trusted applications (TA), such as Applets running in security elements, and WeChat. TM , Alipay TM And other payment apps.

[0221] It can be understood that the above system risk data can be system security data and environmental data collected by the operating system 110 through relevant detection within a preset time range before and after the moment when the security element 120 is attacked or the moment of controlled attack. These system risk data are integrated with the SE risk data generated at the moment when the security element 120 is attacked, which can more objectively and comprehensively reflect the risk level corresponding to the attack on the security element.

[0222] As mentioned above, when the system risk control management module 112 receives the above-mentioned acquisition request for system risk data sent by the SE risk control management module 122, it can use the "asynchronous return" method to return the requested system risk data to the SE risk control management module 122. Specifically, it can be reflected that the system risk control management module 112 can return the requested system risk data to the SE risk control management module 122 when executing the following step 611.

[0223] In other embodiments, the SE risk control management module 122 may not perform this step 607, that is, it may not request the system risk control management module 112 to obtain the system risk data, but directly or preferentially provide the SE risk data generated when the security element 120 is attacked to the payment server 210 for risk control decision-making in the corresponding payment transaction scenario, so as to ensure that at least the SE risk data can be successfully provided to the payment server 210 for risk control decision-making. It can be understood that the risk control information provided by the SE risk data that is not integrated with the system risk data is less than the risk control information provided by the SE risk data after the fusion described below, but it can also improve the accuracy of the risk control decision-making of the payment server 210 to a certain extent.

[0224] 607: The system risk control management module 112 receives SE risk data and collects system risk data.

[0225] Exemplarily, when a user conducts an online transaction via mobile phone 100, mobile phone 100 is usually powered on. At this time, the system risk control management module 112 running the operating system 110 of mobile phone 100 can receive SE risk data sent by SE risk control management module 122. At the same time, the system risk control management module 112 can also collect system risk data when the mobile phone 100 is powered on and the operating system 110 is running. The system risk data may include, for example, system security data detected when malicious applications are detected during the operation of the operating system 110, and may also include environmental data such as location acquired by the positioning system of mobile phone 100. For specific examples of the above-mentioned system risk data, please refer to the above-mentioned Figure 2c The above and related descriptions will not be repeated here.

[0226] 608 : The system risk control management module 112 synchronizes the SE risk data and the system risk data to the payment server 210 .

[0227] Exemplarily, the mobile phone 100 can be connected to the network based on cellular mobile communication, wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) network), etc., and establish a communication connection with the payment server 210. At this time, the operating system 110 of the mobile phone 100 can send the above-mentioned SE risk data and system risk data to the payment server 112 based on the above-mentioned system risk control management module 11. As mentioned above, the above-mentioned SE risk data comes from the security element of the mobile phone 100, and the above-mentioned system risk data comes from the operating system of the mobile phone 100.

[0228] It can be understood that in the scenario where the security element 120 of the mobile phone 100 is attacked, the SE risk data collected by the SE risk control management module 122 in the security element 120 and the system risk data collected by the system risk control management module 112 of the operating system 110 can be sent to the payment server 210 connected to the mobile phone 100 through the system risk control management module 112, so as to make risk control decisions in the corresponding payment transaction process. The mobile phone 100 can execute this step 608 to transmit the collected SE risk data and system risk data to the payment server 210 in a timely manner when connected to the network. In this way, when the user terminal such as the mobile phone 100 is performing some offline transactions such as card payment, the payment server 210 can also perform risk control decisions based on the risk data obtained historically.

[0229] 609: The payment server 210 stores the received risk data.

[0230] It is understandable that the payment server 210 can accumulate and store the SE risk data and system risk data received at different times. The corresponding stored data can be managed or marked according to different types and / or different times, so as to facilitate calling when risk control decisions are needed.

[0231] 610 : The payment server 210 sends a return value of the received risk data to the system risk control management module 112 .

[0232] For example, in some payment transaction scenarios, when the payment server 210 receives risk data such as SE risk data and system risk data sent by the system risk control management module 112, it can return a corresponding return value to the system risk control management module 112 that transmits the risk data, so as to notify the system risk control management module 112 of the status of receiving the risk data. In other embodiments, the payment server 210 can also achieve the purpose of notification to the system risk control management module 112 by returning a notification message or other means, which is not limited here.

[0233] 611: The system risk control management module 112 returns the system risk data to the SE risk control management module 122.

[0234] Exemplarily, the system risk control management module 112 may asynchronously return the collected system risk data to the SE risk control management module 122 .

[0235] It can be understood that when the SE risk control management module 122 executes the above step 606, it requests the system risk control management module 112 to obtain the system risk data. The system risk control management module 112 can return the system risk data when executing this step 611. This method of returning the requested data with an execution time difference can be described as the above-mentioned "asynchronous return" method.

[0236] 612: The SE risk control management module 122 merges and records the received system risk data with the SE risk data generated when the security element is attacked to form merged SE risk data.

[0237] Exemplarily, the SE risk control management module 122 can analyze and associate the SE risk data recorded when the security element is attacked with the location, timing time, SIM card status, and system security data corresponding to malicious application detection in the received system risk data, i.e., perform fusion recording to form fused SE risk data. Thus, the fused SE risk data finally recorded by the SE risk control management module 122 can contain more risk control information, which can help improve the accuracy of risk control decisions after being provided to the payment server 210 in some online or offline transaction scenarios.

[0238] In some other embodiments, if the security element 120 is not equipped with the security sensor 123, the above Figure 5a The steps related to the security sensor 123 in the illustrated process may also be executed by the Applet 121 running in the security element 120, which is not limited here. Figure 7c As shown, when the security element is not equipped with a security sensor, relevant data can be collected during the payment authentication or identity authentication process of Applet 121, and then provided to the SE risk control management module 122 as the collected SE risk data.

[0239] In conjunction with Example 2, the following will first introduce in detail the specific implementation process of transmitting SE risk data and system risk data to the payment server for risk control decision-making based on the risk control method provided by this application in an online transaction scenario.

[0240] Example 2

[0241] In some online transaction scenarios, for example, users install WeChat on their mobile phones. TM, Alipay TM When a payment APP such as a mobile phone 100 performs a payment transaction such as a transfer or shopping payment, the operating system of the mobile phone 100 can establish a communication connection with a server (such as a payment server 210) based on the communication system. After the user submits a shopping order on the mobile phone 100 and confirms the payment, the payment server 210 can receive a payment confirmation request corresponding to the payment transaction sent by the mobile phone 100. Furthermore, after making a risk control decision, the payment server 210 can respond to the received payment confirmation request to pass or reject the transaction based on the result of the risk control decision. It can be understood that if the payment server 210 passes the payment transaction, the user's relevant payment account is successfully deducted, and the payment transaction is completed. If the payment server 210 rejects the payment transaction, the user's relevant account may fail to deduct the money, and the payment transaction fails. Among them, the payment server 210 can reject the received payment confirmation request when the risk control decision result indicates that the transaction is risky or the risk is relatively high, so as to protect the user's property safety.

[0242] Figure 8 According to the embodiment of the present application, a schematic diagram of the implementation process of a risk control method is shown. Figure 8 As shown, in an online transaction scenario, the implementation process may involve the interaction between the operating system 110 of the mobile phone 100, the security element 120, the acceptance terminal 300 and the server 200. More specifically, Figure 8 The process shown involves the interaction between the payment APP 111, the system risk control management module 112, the SE risk control management module 122 and the payment server 210.

[0243] It should also be stated that the steps in the methods and processes in the embodiments of the present application are numbered for ease of reference, rather than to limit the order of precedence. If there is an order between the steps, the text description shall prevail.

[0244] Specifically, Figure 8 The process shown may include the following steps:

[0245] 801: The payment server 210 receives a payment transaction request.

[0246] For example, the user installs WeChat on the mobile phone 100 TM , Alipay TM When a payment APP performs a payment transaction such as a transfer or shopping payment, the payment server 210 may receive a corresponding payment transaction request.

[0247] 802 : The payment server 210 sends a payment command to the payment APP 111 .

[0248] Exemplarily, when the payment server 210 receives the payment transaction request initiated by the user through the payment APP on the mobile phone 100, it can send a payment command related to the transaction to the payment APP 111. The payment command may include but is not limited to an instruction to verify the payment account, an instruction to verify the identity of the payment user, etc. For details, please refer to the relevant description in step 502 in the above embodiment 1, and no limitation is made here.

[0249] 803: The payment APP 111 responds to the payment server 210 with a payment command.

[0250] For example, when processing the received payment command, the payment APP 111 in the mobile phone 100 can provide the corresponding payment account, identity information, etc. to respond to the payment command. In this way, after the user confirms the payment through the payment APP 111, the response result for the payment command can be returned to the payment server 210.

[0251] It can be understood that, similar to steps 501 to 503 in the aforementioned embodiment 1, the corresponding description of steps 801 to 803 is still entering the payment transaction scene. In other embodiments, the implementation process of the risk control method can be started after entering the payment transaction scene, that is, starting from the following step 804, which is not limited here.

[0252] In addition, it is worth noting that the process of authentication completed by the mobile phone running the payment APP and responding to the payment command sent by the payment server 210 is different from the risk control process performed by the subsequent steps 804 to 810. It can be understood as the process of entering the payment transaction scenario before the risk control process performed by steps 804 to 810, which will not be elaborated here.

[0253] 804 : The payment server 210 sends a request to the system risk control management module 112 to obtain SE risk data and system risk data.

[0254] For example, the payment server 210 can make a risk assessment based on the corresponding risk data for the payment transaction confirmed by the payment APP 111, and decide whether to approve the payment transaction. Therefore, the payment server 210 can obtain relevant risk data from the system risk control management module 112 in the operating system 110 of the mobile phone 100 for the payment transaction. The relevant risk data may include system risk data collected by the system risk control management module 112, SE risk data collected by the SE risk control management module 122 in the security element 120, etc.

[0255] It can be understood that during the online transaction process, the operating system 110 of the mobile phone 100 can establish a communication connection with the payment server 210 based on Wi-Fi or cellular mobile communication, and the security element 120 of the mobile phone 100 can transmit the collected SE risk data to the payment server 210 through the operating system 110 for risk control decision-making.

[0256] 805: The system risk control management module 112 prepares the system risk data to be returned.

[0257] Exemplarily, the system risk management module 112 may encrypt, package, and process the collected system risk data related to the payment transaction confirmed by the payment APP 111 as the system risk data to be returned, in preparation for continuing to execute the following step 808 .

[0258] 806: The system risk control management module 112 sends a request to the SE risk control management module 122 to obtain SE risk data.

[0259] Exemplarily, when the system risk control management module 112 receives a request for obtaining SE risk data from the payment server 210, it can request the secure element 120 to obtain SE risk data through the development terminal interface (open mobile API, OMA). The above OMA is an interface for the REE environment to send commands to the secure element, and the system risk control management module 112 can send request information to the SE risk control management module 122 in the secure element 120 through the interface to request to obtain the corresponding SE risk data.

[0260] In other embodiments, the system risk management module 112 may also obtain SE risk data from the security element 120 in other ways, such as through an access interface provided by the TEE environment to the REE environment, etc., which is not limited here.

[0261] 807 : The SE risk control management module 122 returns the recorded SE risk data to the system risk control management module 112 .

[0262] Exemplarily, upon receiving an acquisition request from the system risk control management module 112 , the SE risk control management module 122 in the security element 120 may return the recorded SE risk data to the system risk control management module 112 .

[0263] It is understandable that if the SE risk management module 122 records a lot of SE risk data, the SE risk management module 122 can return the SE risk data collected in the most recent preset time period to the system risk management module 112. For example, the SE risk management module 122 can use the SE risk data corresponding to the security element being attacked, collected in a time period such as nearly a week or a month, as the SE risk data returned to the system risk management module 112.

[0264] 808 : The system risk control management module 112 returns the system risk data and SE risk data to the payment server 210 .

[0265] Exemplarily, the system risk control management module 112 can return the system risk data collected by itself and the received SE risk data to the payment server 210 for use in risk control decision making. In other embodiments, the system risk control management module 112 can also return the system risk data collected by itself and the received SE risk data to the payment server 210 successively, which is not limited here.

[0266] 809: The payment server 210 combines the SE risk data and the system risk data to make a risk control decision.

[0267] The process of the payment server 210 making a risk control decision by combining the received SE risk data and the system risk data is the same as the execution process corresponding to step 518 in the above embodiment 1. Figure 5a The relevant description in step 518 is not repeated here.

[0268] 810 : The payment server 210 returns the risk control decision result to the payment APP 111 .

[0269] In some embodiments, after completing the risk control decision and passing or rejecting the corresponding payment transaction, the payment server 210 may return the risk control decision result to the payment APP 111. The process of the payment server 210 returning the risk control decision result to the payment APP 111 is similar to the process of feeding back the risk control decision result to the POS terminal in step 519 of the above embodiment 1. For details, please refer to the above Figure 5a The relevant description in step 519 is not repeated here.

[0270] Similarly, when receiving the above risk control decision result, the payment APP 111 running on the user terminal such as the mobile phone 100 can prompt that the transaction has failed, or prompt the user to re-enter the transaction password for security authentication, or prompt the user to perform fingerprint authentication or face recognition authentication to further eliminate the risk of the transaction. Among them, the way in which the mobile phone 100 prompts the transaction failure can be achieved by, for example, displaying a corresponding prompt interface, such as displaying a pop-up window to remind "This transaction failed, please try again" or "This transaction has risks, please confirm safety and try again", etc., which are not limited here.

[0271] Based on the execution process of the above steps 801 to 810, the risk management method provided by this application can support providing SE risk data and some system security data, environmental data and other system risk data detected by the system to the server through the operating system of the user terminal supporting online transactions as the data basis for risk control decisions. In this way, the accuracy of risk control decisions made by the payment transaction backend (such as the above payment server) can be improved, which is conducive to protecting the property safety and personal information security of users during payment transactions.

[0272] Fig. 9 According to an embodiment of the present application, a schematic diagram of the structure of a software execution environment provided by a mobile phone 100 is shown.

[0273] like Fig. 9 As shown, the software environment provided by the mobile phone 100 includes a rich execution environment (REE) 11 and a trusted execution environment (TEE) 12 .

[0274] Among them, REE 11 is used to run the above operating system 110, including Android TM 、iOS TM , Hongmeng TM The operating system 110 can be used to run applications / services with low security requirements, such as the wallet application 11A, the NFC service 11B supporting the NFC function, and the above-mentioned system risk control management module 112, or store data with low security requirements. Among them, the wallet application 11A can manage the bank cards, transportation cards, access cards, etc. added by the user based on the security capabilities provided by the security element, which is not limited here.

[0275] TEE 12 can be used to run a highly secure operating system, such as a trusted operating system (Trusted OS), a card operating system (COS), etc. The trusted operating system is used to run a trusted application (TA), such as a trusted application corresponding to a wallet application (hereinafter referred to as wallet application TA) 12A, applications or services related to payment / biometrics / security verification, etc., or to store data with high security requirements, such as keys, biometrics information, card information of simulated cards, etc.

[0276] The NFC-related hardware of the mobile phone 100 may include a security unit 13 and an NFC controller 14. The security unit 13 may be used to store a simulated card (e.g. Figure 2b The card information of the bank card, transportation card, etc. shown in the figure is stored in the security unit 13, and according to the instructions of the trusted application in the TEE 12, the card information of the stored simulated card is written into the NFC controller 14, or the card information of the physical card currently close to the NFC controller 14 is obtained from the NFC controller 14 and stored in the security unit 13.

[0277] In the embodiment of the present application, the security unit 13 is a hardware for storing data with high security requirements, for example, the above-mentioned security element 120. The security element 120 can run an Applet 121, which is used to write the card information of the simulated card to the NFC controller 14 according to the instructions of the trusted application in the TEE 12, or to read the card information of the physical card through the eSE 13 according to the trusted application in the TEE 12.

[0278] The NFC controller 14 can be used to send a trigger instruction for triggering the NFC-based card swiping method provided in the embodiment of the present application to an application in the REE 11, such as the wallet application 11A and / or the NFC service 11B, when an NFC signal is detected, such as when an NFC signal of the POS machine 301 is detected. The NFC controller 14 can also be used to send the card information to the security unit 13 when the card information is read. The NFC controller 14 can also be used to send the card information to the card reading device, such as the POS machine 301, through the NFC technology after receiving the card information sent by the security unit 13, to realize the card swiping.

[0279] Understandably, Fig. 9 The software execution environment structure diagram shown is only an example. In other embodiments, the mobile phone 100 may include more or fewer execution environments / hardware, and may also split or combine the functions / hardware of some execution environments, which is not limited to the embodiments of the present application.

[0280] Fig.10 According to an embodiment of the present application, a schematic diagram of the hardware structure of a user terminal 400 is shown.

[0281] The user terminal 400 may include a processor 410, an external memory interface 420, an internal memory 421, a universal serial bus interface (USB interface) 430, a charging management module 440, a power management module 441, a battery 442, an antenna 1, an antenna 2, a mobile communication module 450, a wireless communication module 460, an audio module 470, a speaker 470A, a receiver 470B, a microphone 470C, an earphone interface 470D, a sensor module 480, a button 490, a motor 491, an indicator 492, a camera 493, a display screen 494, and a subscriber identification module (SIM) card interface 495, etc. The sensor module 480 may include a pressure sensor 480A, a gyroscope sensor 480B, an air pressure sensor 480C, a magnetic sensor 480D, an acceleration sensor 480E, a distance sensor 480F, a proximity light sensor 480G, a fingerprint sensor 480H, a temperature sensor 480J, a touch sensor 480K, an ambient light sensor 480L, a bone conduction sensor 480M, etc.

[0282] It is to be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the user terminal 400. In other embodiments of the present application, the user terminal 400 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0283] The processor 410 may include one or more processing units, for example, the processor 410 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0284] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0285] In the embodiment of the present application, the processor 410 of the user terminal 400 may execute the above-mentioned Figure 5a , Figure 5b , Figure 6 as well as Figure 8 The steps performed by the relevant modules of the security element 120 and the relevant modules of the operating system 110 in the process shown in the figure are as follows. Figure 5a , Figure 5b , Figure 6 as well as Figure 8 The above and related descriptions will not be repeated here.

[0286] The processor 410 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 410 is a cache memory. The memory may store instructions or data that the processor 410 has just used or cyclically used. If the processor 410 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 410, and thus improves the efficiency of the system.

[0287] In some embodiments, the processor 410 may include one or more interfaces. The interface may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module interface (SIM card interface), and / or a USB interface 430, etc.

[0288] The USB interface 430 is an interface that complies with the USB standard specification, and specifically can be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 430 can be used to connect a charger to charge the user terminal 400, and can also be used to transmit data between the user terminal 400 and peripheral devices. It can also be used to connect headphones to play audio through the headphones. The interface can also be used to connect other electronic devices, such as AR devices, etc.

[0289] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present invention is only a schematic illustration and does not constitute a structural limitation on the user terminal 400. In other embodiments of the present application, the user terminal 400 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0290] The charging management module 440 is used to receive charging input from a charger. While the charging management module 440 is charging the battery 442 , it can also power the electronic device through the power management module 441 .

[0291] The power management module 441 is used to connect the battery 442, the charging management module 440 and the processor 410. The power management module 441 receives input from the battery 442 and / or the charging management module 440 to power the processor 410, the internal memory 421, the display screen 494, the camera 493, and the wireless communication module 460.

[0292] The wireless communication function of the user terminal 400 can be implemented through the antenna 1, the antenna 2, the mobile communication module 450, the wireless communication module 460, the modem processor and the baseband processor.

[0293] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals.

[0294] The mobile communication module 450 can provide wireless communication solutions including 2G / 3G / 4G / 5G etc. applied on the user terminal 400 .

[0295] The wireless communication module 460 can provide wireless communication solutions for application on the user terminal 400, including wireless local area network (WLAN) (such as Wi-Fi network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared technology (IR), etc.

[0296] In some embodiments, the antenna 1 of the user terminal 400 is coupled to the mobile communication module 450, and the antenna 2 is coupled to the wireless communication module 460, so that the user terminal 400 can communicate with the network and other devices through wireless communication technology. The above wireless communication technology may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology, etc. The above-mentioned GNSS may include a global positioning system (GPS), a global navigation satellite system (GLONASS), a Beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS) and / or a satellite based augmentation system (SBAS).

[0297] The user terminal 400 implements the display function through a GPU, a display screen 494, and an application processor.

[0298] The display screen 494 is used to display images, videos, etc. The display screen 494 includes a display panel. In some embodiments, the user terminal 400 may include 1 or N display screens 494, where N is a positive integer greater than 1.

[0299] The user terminal 400 can realize the shooting function through the ISP, the camera 493, the video codec, the GPU, the display screen 494 and the application processor.

[0300] The ISP is used to process the data fed back by the camera 493. The camera 493 is used to capture static images or videos. The object generates an optical image through the lens and projects it onto the photosensitive element. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV or other format. In some embodiments, the user terminal 400 may include 1 or N cameras 493, where N is a positive integer greater than 1.

[0301] The external memory interface 420 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the user terminal 400. The external memory card communicates with the processor 410 through the external memory interface 420 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0302] The internal memory 421 can be used to store computer executable program codes, which include instructions. The internal memory 421 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the user terminal 400 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 421 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 410 executes various functional applications and data processing of the user terminal 400 by running instructions stored in the internal memory 421, and / or instructions stored in a memory provided in the processor.

[0303] The user terminal 400 can implement audio functions such as music playing and recording through the audio module 470, the speaker 470A, the receiver 470B, the microphone 470C, the earphone interface 470D, and the application processor.

[0304] The audio module 470 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signal. The audio module 470 can also be used to encode and decode audio signals. In some embodiments, the audio module 470 can be arranged in the processor 410, or some functional modules of the audio module 470 can be arranged in the processor 410.

[0305] The speaker 470A, also called a "speaker", is used to convert an audio electrical signal into a sound signal. The user terminal 400 can listen to music or listen to a hands-free call through the speaker 470A.

[0306] The receiver 470B, also called a "handset", is used to convert audio electrical signals into sound signals. When the user terminal 400 receives a call or voice message, the user can receive the voice by placing the receiver 470B close to the ear.

[0307] Microphone 470C, also called "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or sending a voice message, the user can make a sound by approaching the microphone 470C with his mouth to input the sound signal into the microphone 470C. The user terminal 400 can be provided with at least one microphone 470C. In other embodiments, the user terminal 400 can be provided with two microphones 470C, which can not only collect sound signals but also realize noise reduction function. In other embodiments, the user terminal 400 can also be provided with three, four or more microphones 470C to collect sound signals, reduce noise, identify the sound source, realize directional recording function, etc.

[0308] The earphone interface 470D is used to connect a wired earphone and can be a USB interface 430 or a 3.5 mm open mobile terminal platform (OMTP) standard interface or a cellular telecommunications industry association of the USA (CTIA) standard interface.

[0309] The key 490 includes a power key, a volume key, etc. The key 490 may be a mechanical key or a touch key. The user terminal 400 may receive key input and generate key signal input related to user settings and function control of the user terminal 400.

[0310] Motor 491 can generate vibration prompts. Motor 491 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback. For example, touch operations acting on different applications (such as taking pictures, audio playback, etc.) can correspond to different vibration feedback effects. For touch operations acting on different areas of the display screen 494, motor 491 can also correspond to different vibration feedback effects. Different application scenarios (for example: time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also support customization.

[0311] Indicator 492 may be an indicator light, which may be used to indicate charging status, power changes, messages, missed calls, notifications, etc.

[0312] The SIM card interface 495 is used to connect the SIM card. The SIM card can be connected to and separated from the user terminal 400 by inserting it into the SIM card interface 495 or pulling it out from the SIM card interface 495. The user terminal 400 can support 1 or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 495 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 495 at the same time. The types of the above multiple cards can be the same or different. The SIM card interface 495 can also be compatible with different types of SIM cards. The SIM card interface 495 can also be compatible with external memory cards. The user terminal 400 interacts with the network through the SIM card to realize functions such as calls and data communications. In some embodiments, the user terminal 400 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the user terminal 400 and cannot be separated from the user terminal 400.

[0313] Fig.11 It is a schematic block diagram of the software system architecture of the user terminal 400 according to an embodiment of the present invention.

[0314] It is understood that the software system of the user terminal 400 can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present invention takes the Android system of the layered architecture as an example to exemplify the software structure of the user terminal 400.

[0315] The layered architecture divides the software into several layers, each with a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, Android TM The system is divided into four layers, from top to bottom: application layer, application framework layer, Android TM Runtime (Android TM runtime) and system libraries, as well as the kernel layer.

[0316] like Fig.11 As shown, the application layer may include a series of application packages, which may include camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications.

[0317] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0318] The application framework layer may include a window manager, content provider, view system, telephony manager, resource manager, notification manager, and the like.

[0319] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

[0320] Content providers are used to store and retrieve data and make it accessible to applications. This data can include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0321] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0322] The phone manager is used to provide communication functions of the electronic device 100, such as management of call status (including connecting, hanging up, etc.).

[0323] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0324] The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, an electronic device vibrates, an indicator light flashes, etc.

[0325] Android TM Runtime includes core libraries and virtual machines. Android TM runtime is responsible for Android TM Scheduling and management of the system.

[0326] The core library consists of two parts: one part is the function that needs to be called by the Java language, and the other part is the Android core library.

[0327] The application layer and the application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0328] The system library may include multiple functional modules, such as surface manager, media libraries, 3D graphics processing library (such as openGL ES), 2D graphics engine (such as SGL), etc.

[0329] The surface manager is used to manage the display subsystem and provide the fusion of 2D and 3D layers for multiple applications.

[0330] The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0331] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0332] A 2D graphics engine is a drawing engine for 2D drawings.

[0333] The kernel layer is a layer between hardware and software. The kernel layer includes at least a display driver, a camera driver, an audio driver, and a sensor driver. In the embodiment of the present application, the kernel layer may also include a chip driver for driving the security element to execute related steps, which is not limited here.

[0334] Fig.12 According to an embodiment of the present application, a schematic diagram of the software structure of another user terminal capable of providing different execution environments is shown.

[0335] like Fig.12 As shown, the user terminal 400 includes three application environments, namely, the above-mentioned rich execution environment (REE) module, the trusted execution environment (TEE) module and the secure element (SE) module. In one example, the REE module and the TEE module are integrated on one chip, such as the above-mentioned application processor (AP) chip, and the SE module is integrated on another chip, such as the SE chip.

[0336] Among them, the REE module includes a general operating system (not shown in the figure) running on a general embedded processor, such as Rich OS or a kernel-based operating system (such as Android system, Hongmeng system, etc.), and applications / services in the REE module.

[0337] In some examples, the REE module may include an application layer and a system framework layer. Among them, the application layer includes a series of application programs (APPs), such as business APPs (such as wallet APPs), which support adding bank cards, transportation cards, electronic certificates, change, membership cards, invoices, and community access cards, smart home lock cards, smart hotel room cards, etc., and can meet the security services such as transportation, mobile payment, etc. through the terminal. In some examples, the business APP can also receive information about the security services (i.e., cards) that can be traded after the user is turned off. Optionally, the business APP can also receive information about the security services that need to switch the working mode after the user is turned off. Among them, the system framework layer provides APIs and programming frameworks for the APPs in the application layer. The system framework layer includes some predefined functions. For example, the system framework layer includes a trigger event detection module, and a business management service. Among them, the trigger event detection module detects the trigger event of the user terminal 400, including a first trigger event and a second trigger event. Among them, the first trigger event is used to trigger the terminal to start switching the state of the card in the terminal (such as switching the activated state to the inactivated state, or switching the inactivated state to the activated state).

[0338] For example, the first trigger event may include a shutdown event, and / or an event in which the terminal power is less than a preset threshold, etc. The second trigger event is used to trigger the terminal to restore the state of each card in the terminal before the first trigger event is detected (such as an activated state or an unactivated state). For example, the second trigger event includes a power-on event, and / or an event in which the terminal power is equal to or greater than a preset threshold. Specifically, the trigger event detection module includes a power-on and power-off service, which is used to detect the power-on and power-off events of the user terminal 400, and notify the business management service of the detected power-on event or power-off event of the user terminal 400.

[0339] Among them, the TEE module is an independent operating environment running outside the REE module, which provides security services to the REE module and is isolated from the REE module. The REE module (including the general operating system and the applications on it) cannot directly access the hardware and software resources of the TEE module. The TEE module provides a trusted operating environment for the applications in the TEE module, and then ensures end-to-end security by protecting confidentiality, integrity and controlling data access rights. The TEE module runs in parallel with the REE module and interacts with the REE module through a secure API. The TEE module provides an operating environment with a higher security level than the REE module, but cannot provide a secure key storage and key operating environment at the hardware isolation level. Among them, the application in the TEE module is also called the above-mentioned trusted application (TA).

[0340] For example, the TEE module includes a service management TA, which is used to notify the SE module to activate security services that can be traded after shutdown or when the terminal power is less than a preset threshold after receiving the first trigger event forwarded by the service management service (such as a shutdown event or an event that the terminal power is less than a preset threshold), and deactivate (deactived) security services that cannot be traded after shutdown or when the terminal power is less than a preset threshold, such as offline payment.

[0341] For another example, the business management TA is used to notify the SE module to restore the status of each card to the state and / or working mode before the first trigger event was detected after receiving a second trigger event forwarded by the business management service (such as a power-on event or an event in which the terminal power is equal to or greater than a preset threshold).

[0342] The SE module is used to build a trusted and secure key storage and key operation environment. This is because the software system in the SE module is simple and the hardware components are relatively few, so it is easy to establish physical protection and implement security assurance, thereby improving the security strength of the SE module, so that it can serve security systems with higher security requirements. The SE module includes a card operating system (COS) module (not shown in the figure), a contactless registry service (CRS) module, and applications in the SE module (such as Figure 2b The application in the SE module can also be called an Applet or a card, for example, it can be one or more of a bank card, a transportation card, an access card, a work card, an electronic certificate, or a car key.

[0343] It should also be noted that the "business APP", "trigger event detection module", "business management service", "business management TA", etc. here are all names provided by this application to facilitate the description of the solution, and cannot be used as a limitation on the functions of the solution of this application in some examples.

[0344] It should be noted that the user terminal 400 also includes an NFC module for supporting the user terminal 400 to communicate with other NFC devices (such as card reading devices). The NFC module includes a contactless front-end (CLF), which is a controller of the NFC module, and can receive APDU instructions from the card reading device and send the received APDU instructions to the COS of the SE chip, so that the COS distributes the received APDU instructions to the application in the corresponding SE module for business transactions. In one example, the NFC module can be integrated on another chip independent of the AP chip and the SE chip, also referred to as an NFC chip. It should be noted that when the user terminal 400 is turned off, the remaining power of the user terminal 400 can power the NFC module and the SE module of the user terminal 400, that is, the NFC module and the SE module of the user terminal 400 can still work. Then, after the user terminal 400 is turned off, if the card 1 in the SE module is in an activated state, the card 1 can still trade with the card reading device.

[0345] The embodiments of the present application also provide a computer program product for implementing the risk control methods provided in the above embodiments.

[0346] The various embodiments of the mechanism disclosed in the present application can be implemented in hardware, software, firmware or a combination of these implementation methods. The embodiments of the present application can be implemented as a computer program module or module code executed on a programmable system, and the programmable system includes at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device and at least one output device.

[0347] A computer program module or module code can be applied to input instructions to perform the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

[0348] Module code can be implemented with high-level modular language or object-oriented programming language to communicate with the processing system. When necessary, module code can also be implemented with assembly language or machine language. In fact, the mechanism described in this application is not limited to the scope of any specific programming language. In either case, the language can be a compiled language or an interpreted language.

[0349] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, instructions may be distributed over a network or through other computer-readable media. Therefore, a machine-readable medium may include any mechanism for storing or transmitting information in a machine (e.g., computer) readable form, including, but not limited to, a floppy disk, an optical disk, an optical disk, a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic card or an optical card, a flash memory, or a tangible machine-readable memory for transmitting information (e.g., a carrier wave, an infrared signal, a digital signal, etc.) using the Internet in an electrical, optical, acoustic, or other form of propagation signal. Accordingly, machine-readable media include any type of machine-readable media suitable for storing or transmitting electronic instructions or information in a form readable by a machine (eg, a computer).

[0350] References to "one embodiment" or "an embodiment" in the specification mean that the specific features, structures, or characteristics described in conjunction with the embodiment are included in at least one exemplary implementation or technology disclosed according to the embodiment of the present application. The appearance of the phrase "in one embodiment" in various places in the specification does not necessarily all refer to the same embodiment.

[0351] The disclosure of the embodiment of the present application also relates to an operating device for executing the text. The device can be specially constructed for the required purpose or it can include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer-readable medium, such as, but not limited to any type of disk, including a floppy disk, an optical disk, a CD-ROM, a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic or optical card, an application-specific integrated circuit (ASIC) or any type of medium suitable for storing electronic instructions, and each can be coupled to a computer system bus. In addition, the computer mentioned in the specification may include a single processor or may be an architecture involving multiple processors for increased computing power.

[0352] In addition, the language used in this specification has been primarily selected for readability and instructional purposes and may not be selected to describe or limit the disclosed subject matter. Therefore, the present application embodiment disclosure is intended to illustrate rather than limit the scope of the concepts discussed herein.

Claims

1. A risk control method, characterized in that: include: The first device detects the first service request, and executes the first service in response to the first service request; The first device detects a risk data acquisition request; In response to the risk data acquisition request, the first device sends first risk data to the second device, wherein the first risk data includes record data of a security element in the first device.

2. The method according to claim 1, characterized in that The recorded data of the security element in the first device includes: Data generated and recorded by the first device based on the attack detected by the security element; or, The first device generates fusion data corresponding to the attack detected by the security element, and the fusion data is obtained by fusing the recorded data of the security element with the data of the operating system of the first device.

3. The method according to claim 1, characterized in that The method further comprises: In response to the risk data acquisition request, the first device sends second risk data to the second device, where the second risk data is recorded data related to the first service and recorded by the operating system of the first device.

4. The method according to claim 3, characterized in that The first device establishes a communication connection with a third device through near field communication, the first service includes a first payment service triggered by the first device in response to a payment command initiated by the third device, and The first device detects a risk data acquisition request, including: The first device receives a risk data acquisition request sent by the second device through the third device; and The first device sends the first risk data to the second device in response to the risk data acquisition request, including: In response to the risk data acquisition request, the first device sends the first risk data to the second device through the third device, wherein the third device establishes a communication connection with the second device in a wireless or wired manner.

5. The method according to claim 4, characterized in that The first device sends the second risk data to the second device in response to the risk data acquisition request, including: The first device sends the first risk data and the second risk data to the third device based on a first session established between the first device and the third device, wherein: The first session is used to transmit a first acquisition request, and first risk data and second risk data corresponding to the first acquisition request between the third device and the first device.

6. The method according to claim 5, characterized in that The first device sending the first risk data and the second risk data to the third device based on the first session established between the first device and the third device includes: The first device obtains, in response to the first initialization instruction sent by the third device, the ID of the first session carried in the first initialization instruction; The first device establishes the first session with the third device in response to the first initialization instruction; The first device sends the first risk data to the third device, and associates and stores the first risk data and the second risk data corresponding to the ID of the first session; and The first device receives the first acquisition request sent by the third device through the first session, and sends the first risk data and the second risk data stored in association with the ID corresponding to the first session through the first session.

7. The method according to claim 4, characterized in that The first device sends the second risk data to the second device in response to the risk data acquisition request, including: The first device sends the second risk data to the third device based on a second session established between the first device and the third device, wherein: The second session is used to transmit a second acquisition request and second risk data corresponding to the second acquisition request between the third device and the first device.

8. The method according to claim 7, characterized in that The first device sending the second risk data to the third device based on the second session established between the first device and the third device includes: The first device obtains, in response to the second initialization instruction sent by the third device, the ID of the second session carried in the second initialization instruction; The first device establishes the second session with the third device in response to the second initialization instruction; The first device associates and stores the second risk data with the ID of the second session; and The first device receives the second acquisition request sent by the third device based on the ID of the second session, and sends the second risk data stored in association with the ID of the second session through the second session.

9. The method according to claim 6 or 8, characterized in that: Before establishing the first session or the second session with the third device, the method further includes: The first device detects the created historical session and deletes the detected historical session.

10. The method according to claim 3, characterized in that The first device establishes a communication connection with the fourth device by scanning a barcode, the first service includes a second payment service triggered by the fourth device scanning a barcode presented by the first device, and, The first device detects a risk data acquisition request, including: The first device receives a risk data acquisition request sent by the second device through the fourth device; and The first device sends the first risk data to the second device in response to the risk data acquisition request, including: In response to the risk data acquisition request, the first device sends the first risk data to the second device through the fourth device, wherein the fourth device establishes a communication connection with the second device in a wireless or wired manner.

11. The method according to claim 10, characterized in that The first device sends the first risk data to the second device in response to the risk data acquisition request, including: The first device adds the first risk data and / or the second risk data to the information carried by the barcode; When the first device establishes a communication connection with the fourth device by scanning a code, the first device provides the first risk data and / or the second risk data to the fourth device.

12. The method according to any one of claims 1 to 11, characterized in that The method further comprises: The first device receives a prediction result of the risk level of the first business by the second device, wherein the prediction result is determined by the second device based on the first risk data and / or the second risk data.

13. The method according to claim 12, characterized in that The prediction result includes a result indicating that the first business has a risk, and the method further includes: The first device displays a first prompt message, wherein the first prompt message is used to indicate that the second device rejects a result of the first device executing the first service.

14. An electronic device, characterized in that: include: one or more processors; One or more memories; the one or more memories store one or more programs, and when the one or more programs are executed by the one or more processors, the electronic device executes the risk control method described in any one of claims 1 to 13.

15. A computer readable medium, characterized in that The readable medium stores instructions, which, when executed on a computer, enable the computer to execute the risk control method according to any one of claims 1 to 13.

Images