CN111310196B - Risk identification method and device and electronic equipment - Google Patents

Risk identification method and device and electronic equipment Download PDF

Info

Publication number
CN111310196B
CN111310196B CN202010384152.1A CN202010384152A CN111310196B CN 111310196 B CN111310196 B CN 111310196B CN 202010384152 A CN202010384152 A CN 202010384152A CN 111310196 B CN111310196 B CN 111310196B
Authority
CN
China
Prior art keywords
service request
service
risk
sent
user account
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010384152.1A
Other languages
Chinese (zh)
Other versions
CN111310196A (en
Inventor
陆毅成
周璟
宝鹏庆
吕乐
赵文飙
王维强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alipay Hangzhou Information Technology Co Ltd
Original Assignee
Alipay Hangzhou Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alipay Hangzhou Information Technology Co Ltd filed Critical Alipay Hangzhou Information Technology Co Ltd
Priority to CN202010384152.1A priority Critical patent/CN111310196B/en
Priority to CN202110050426.8A priority patent/CN112836218B/en
Publication of CN111310196A publication Critical patent/CN111310196A/en
Application granted granted Critical
Publication of CN111310196B publication Critical patent/CN111310196B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The specification provides a risk identification method and device and electronic equipment, and the risk identification method and device and the electronic equipment are applied to a trusted execution environment of terminal equipment. The trusted execution environment stores historical service requests and risk rules. The method comprises the following steps: responding to a service request to be sent initiated by a service client, and acquiring a user account and a terminal identifier contained in the service request; inquiring a historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain a numerical value of a risk index; judging whether the numerical value of the risk index reaches a threshold value set in a risk rule or not; deleting the equipment identifier carried in the service request to be sent, adding a judgment result, and sending the service request to a service server by the service client; so that the service server executes the service request based on the judgment result. Since the device identification is not transmitted to the outside, personal information of the user can be protected.

Description

Risk identification method and device and electronic equipment
Technical Field
The embodiment of the specification relates to the technical field of internet, in particular to a risk identification method and device and electronic equipment.
Background
With the continuous development of the internet, especially the popularization of the mobile internet, people can access the internet at any time and any place nowadays. But the security problem of the internet is getting more and more serious, and various illegal activities by means of the internet are getting more and more rampant.
In order to ensure the security of the internet, each service provider deploys a corresponding wind control strategy to cope with various attacks. For example, the service server performs risk identification on a service request initiated by each user, determines whether the service request, the user corresponding to the service request, the terminal device used by the user, and the like have risks, and if any one of the service request, the user corresponding to the service request, and the terminal device has a risk, executes corresponding risk control (such as refusing to execute the service request); the service request is executed if there is no risk. Therefore, risk identification can effectively resist risk attack, and normal service is prevented from being influenced.
Disclosure of Invention
The embodiment of the specification provides a risk identification method and device and electronic equipment.
According to a first aspect of embodiments of the present specification, a risk identification method is provided, which is applied to a trusted execution environment of a terminal device; the trusted execution environment stores historical service requests sent by a service client and risk rules for performing risk identification on the service requests initiated by the service client; the method comprises the following steps:
responding to a service request to be sent initiated by the service client, and acquiring a user account and a terminal identifier contained in the service request;
inquiring a historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain a numerical value of a risk index;
judging whether the numerical value of the risk index reaches a threshold value set in the risk rule or not;
deleting the equipment identifier carried in the service request to be sent, adding a judgment result, and sending the service request to a service server by the service client; so that the service server executes the service request based on the judgment result.
Optionally, the deleting the device identifier carried in the service request to be sent, and adding the determination result includes:
and replacing the equipment identifier carried in the service request to be sent with a judgment result.
Optionally, the device identifier carried in the service request to be sent is deleted, a judgment result is added, and the service client sends the service request to a service server; so that the service server executes the service request based on the judgment result, including:
if so, deleting the equipment identifier carried in the service request to be sent, adding a trusted identifier, and sending the service request to a service server by the service client; so that the service server executes the service request based on the trusted identification;
if not, deleting the equipment identifier carried in the service request to be sent, adding an untrusted identifier, and sending the service request to a service server by the service client; and the service server side carries out risk detection on the service request based on the non-beacon identification.
Optionally, the method further includes:
if the value of the risk index reaches a threshold value set in the risk rule, storing the trusted relationship between the user account and the equipment identifier in the trusted execution environment;
after the obtaining of the user account and the terminal identifier included in the service request, the method further includes:
inquiring whether the user account and the equipment identification in the service request are in a trusted relationship;
if yes, deleting the equipment identifier carried in the service request to be sent, adding a trusted identifier, and sending the service request to a service server by the service client;
and if not, executing the step of inquiring the historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain the numerical value of the risk index.
Optionally, the risk indicator includes at least one of a duration of a time from a time when the first service request is successful to a time when the service request is received, a number of times of successful service requests, and a cumulative amount of successful service requests.
Optionally, the method further includes:
and storing the risk rule which is received by the business client and issued by the business server into the trusted execution environment.
According to a second aspect of the embodiments of the present specification, a risk identification method is provided, which is applied to a service client of a terminal device; the service client stores historical service requests and risk rules; the method comprises the following steps:
responding to a service request to be sent triggered by a user, and acquiring a user account and a terminal identifier contained in the service request;
inquiring a historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain a numerical value of a risk index;
judging whether the numerical value of the risk index reaches a threshold value set in the risk rule or not;
deleting the equipment identifier carried in the service request to be sent, adding a judgment result, and sending the service request to a service server; so that the service server executes the service request based on the judgment result.
Optionally, the deleting the device identifier carried in the service request to be sent, and adding the determination result includes:
and replacing the equipment identifier carried in the service request to be sent with a judgment result.
Optionally, the device identifier carried in the service request to be sent is deleted, a judgment result is added, and the service request is sent to a service server; so that the service server executes the service request based on the judgment result, including:
if so, deleting the equipment identifier carried in the service request to be sent, adding a trusted identifier, and sending the service request to a service server; so that the service server executes the service request based on the trusted identification;
if not, deleting the equipment identifier carried in the service request to be sent, adding an untrusted identifier, and sending the service request to a service server; and the service server side carries out risk detection on the service request based on the non-beacon identification.
Optionally, the method further includes:
if the value of the risk index reaches a threshold value set in the risk rule, storing the credible relationship between the user account and the equipment identifier;
after the obtaining of the user account and the terminal identifier included in the service request, the method further includes:
inquiring whether the user account and the equipment identification in the service request are in a trusted relationship;
if yes, deleting the equipment identifier carried in the service request to be sent, adding a trusted identifier, and sending the service request to a service server;
and if not, executing the step of inquiring the historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain the numerical value of the risk index.
Optionally, the risk indicator includes at least one of a duration of a time from a time when the first service request is successful to a time when the service request is received, a number of times of successful service requests, and a cumulative amount of successful service requests.
Optionally, the method further includes:
and receiving and storing the risk rule issued by the service server.
According to a third aspect of the embodiments of the present specification, there is provided a risk identification apparatus, which is applied to a trusted execution environment of a terminal device; the trusted execution environment stores historical service requests sent by a service client and risk rules for performing risk identification on the service requests initiated by the service client; the device comprises:
the response unit is used for responding to a service request to be sent initiated by the service client and acquiring a user account and a terminal identifier contained in the service request;
the calculation unit is used for inquiring a historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain a numerical value of a risk index;
the judging unit is used for judging whether the numerical value of the risk index reaches a threshold value set in the risk rule or not;
the sending unit deletes the equipment identifier carried in the service request to be sent, adds a judgment result, and sends the service request to a service server by the service client; so that the service server executes the service request based on the judgment result.
Optionally, the deleting, by the sending unit, the device identifier carried in the service request to be sent, and adding the determination result includes:
and replacing the equipment identifier carried in the service request to be sent with a judgment result.
Optionally, the sending unit includes:
a first sending subunit, configured to delete the device identifier carried in the service request to be sent and add a trusted identifier if the value of the risk indicator reaches the threshold set in the risk rule, and send the service request to a service server by the service client; so that the service server executes the service request based on the trusted identification;
a second sending subunit, configured to delete the device identifier carried in the to-be-sent service request and add an untrusted identifier if the value of the risk indicator does not reach the threshold set in the risk rule, and send the service request to a service server by the service client; and the service server side carries out risk detection on the service request based on the non-beacon identification.
Optionally, the apparatus further comprises:
the storage unit is used for storing the credible relationship between the user account and the equipment identifier in the credible execution environment if the numerical value of the risk index reaches the threshold value set in the risk rule;
after the response unit, the method further comprises:
the query unit is used for querying whether the user account and the equipment identifier in the service request are in a trusted relationship; if yes, executing the first sending subunit; if not, the calculation unit is executed.
Optionally, the risk indicator includes at least one of a duration of a time from a time when the first service request is successful to a time when the service request is received, a number of times of successful service requests, and a cumulative amount of successful service requests.
Optionally, the apparatus further comprises:
and the storage unit is used for storing the risk rule received by the business client and issued by the business server into the trusted execution environment.
According to a fourth aspect of the embodiments of the present specification, there is provided a risk identification apparatus, which is applied to a service client of a terminal device; the service client stores historical service requests and risk rules; the device comprises:
the response unit is used for responding to a service request to be sent triggered by a user and acquiring a user account and a terminal identifier contained in the service request;
the calculation unit is used for inquiring a historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain a numerical value of a risk index;
the judging unit is used for judging whether the numerical value of the risk index reaches a threshold value set in the risk rule or not;
the sending unit deletes the equipment identifier carried in the service request to be sent, adds a judgment result and sends the service request to a service server; so that the service server executes the service request based on the judgment result.
Optionally, the deleting, by the sending unit, the device identifier carried in the service request to be sent, and adding the determination result includes:
and replacing the equipment identifier carried in the service request to be sent with a judgment result.
Optionally, the sending unit includes:
the first sending subunit deletes the equipment identifier carried in the service request to be sent if the value of the risk index reaches the threshold value set in the risk rule, adds a trusted identifier, and sends the service request to a service server; so that the service server executes the service request based on the trusted identification;
a second sending subunit, configured to delete the device identifier carried in the to-be-sent service request and add an untrusted identifier to the device identifier if the value of the risk indicator does not reach the threshold set in the risk rule, and send the service request to a service server; and the service server side carries out risk detection on the service request based on the non-beacon identification.
Optionally, the apparatus further comprises:
the storage unit is used for storing the credible relationship between the user account and the equipment identifier if the numerical value of the risk index reaches the threshold value set in the risk rule;
after the response unit, the method further comprises:
the query unit is used for querying whether the user account and the equipment identifier in the service request are in a trusted relationship; if yes, executing the first sending subunit; if not, the calculation unit is executed.
Optionally, the risk indicator includes at least one of a duration of a time from a time when the first service request is successful to a time when the service request is received, a number of times of successful service requests, and a cumulative amount of successful service requests.
Optionally, the apparatus further comprises:
and the storage unit is used for receiving and storing the risk rule issued by the service server.
According to a fifth aspect of embodiments herein, there is provided an electronic apparatus including:
a processor;
a memory for storing processor-executable instructions;
wherein the processor is configured to any of the above risk identification methods.
The embodiment of the specification provides a risk identification scheme, which is characterized in that a terminal device of a user locally identifies a risk of a service request to be sent, deletes a device identifier in the service request to be sent, adds a judgment result and sends the service request to a service server; and the service server side processes according to the judgment result in the service request. On one hand, risk identification is locally carried out by the terminal equipment, so that the risk identification pressure of the business server side can be reduced. On the other hand, although the service request to be sent generated by the service client originally carries the equipment identifier, the equipment identifier in the service request is deleted after the local risk identification of the terminal equipment, and the added judgment result does not relate to personal information of user privacy; therefore, even if leakage occurs in the transmission process, the personal information of the user cannot be leaked. The problem of privacy disclosure is solved fundamentally.
Drawings
FIG. 1 is a schematic diagram of a risk identification system provided by an embodiment of the present description;
FIG. 2 is a flow chart of a risk identification method provided by an embodiment of the present description;
FIG. 3 is a hardware block diagram of a risk identification device provided in an embodiment of the present disclosure;
fig. 4 is a schematic block diagram of a risk identification device according to an embodiment of the present disclosure.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below do not represent all implementations consistent with this specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the specification, as detailed in the appended claims.
The terminology used in the description herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the description. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. Plural in this context may refer to two or more.
It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the present specification. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
As mentioned above, in the related art, risk identification is generally performed by a service end. And the service end executes risk identification by means of the relevant information provided by the terminal equipment used by the user. For example, the service server may collect service requests uploaded by each terminal device, where the service requests carry device identifiers and user accounts. Then, the service end can take the user account and the equipment identifier as statistical dimensions, and calculate each preset risk index from each service request of the same user account and equipment identifier. If the value of the risk indicator satisfies the risk rule of the trusted device, a trusted relationship between the user account and the device identification may be established. If the subsequent service request carries the user account and the device identifier, the service request is low-risk, and the terminal device corresponding to the device identifier is trusted for the user, so that the service request is also trusted, and the service server directly executes the service request.
However, the above solution has the following drawbacks:
first, the service end needs to identify risks for all service requests. Regardless of which risk identification is required to consume a certain amount of time, if the time is long, there may be a delay in the service request response, thereby affecting the user experience. In addition, in practical applications, most of the service requests are normal service requests, and a small part of the service requests are abnormal service requests (or referred to as risky service requests). However, because of a small portion of abnormal service requests, the service server needs to identify the risk of each service request. Thus, a large amount of resources of the service end are occupied.
Secondly, the service request initiated by the user must carry the device identifier of the currently used terminal device, and the device identifier belongs to personal information of the user privacy. The device identifier may include any data that can uniquely identify or uniquely identify the terminal device together with other information, such as a Serial Number (SN) and a hardware Address (MAC). But the personal information may be leaked in the transmission process and the storage process on the service end, which is easy to cause privacy leakage.
In order to solve the above problems, the present specification provides a risk identification method, which aims to reduce resources occupied by risk identification of a business server and avoid personal information leakage of a user. Specifically, risk identification is carried out on a service request to be sent locally through terminal equipment of a user, then equipment identification in the service request to be sent is deleted, a judgment result is added, and the service request is sent to a service end; and the service server side processes according to the judgment result in the service request. On one hand, risk identification is locally carried out by the terminal equipment, so that the risk identification pressure of the business server side can be reduced. On the other hand, although the service request to be sent generated by the service client originally carries the equipment identifier, the equipment identifier in the service request is deleted after the local risk identification of the terminal equipment, and the added judgment result does not relate to personal information of user privacy; therefore, even if leakage occurs in the transmission process, the personal information of the user cannot be leaked. The problem of privacy disclosure is solved fundamentally.
Please refer to fig. 1 for a schematic diagram of a risk identification system. The system comprises a device terminal and a service server.
In this embodiment, the device terminal may refer to a client device in hardware, such as a desktop computer, a laptop computer, a tablet computer, a smart phone, a handheld computer, a personal digital assistant ("PDA"), or any other wired or wireless processor-driven device.
The device terminal is provided with an operating system, such as an android operating system, an IOS operating system, a Windows Phone operating system and the like, which are suitable for the mobile terminal. And a service client corresponding to the service server is also installed in the operating system.
The service client may refer to an application client on software, such as an electronic wallet APP, an instant messaging APP, and the like.
The service server may be a server, a server cluster, or a cloud platform constructed based on the server cluster, which responds to a service request sent by a service client on the device terminal.
The business server is used for determining the risk rules and issuing the risk rules meeting the issuing conditions to the business clients in the equipment terminals.
The equipment terminal locally stores a risk rule issued by the service server and data of a historical service request sent by the equipment terminal.
In implementation, a user may initiate a service request to a service server through a service client in an equipment terminal. For the equipment terminal, firstly, a service request initiated by a service client is intercepted, after the service request is combined with a locally stored historical service request, risk identification is carried out according to a locally stored risk rule so as to determine whether the service request is credible. And then deleting the equipment identifier in the service request to be sent, adding a judgment result and sending the service request to a service server. And the service server performs related processing according to the judgment result in the service request. The transaction request is executed directly, for example, skipping risk detection of the service request based on a trusted identification in the service request.
Reference is also made below to the example of the risk identification method shown in fig. 2, which may be applied to a trusted execution environment of a terminal device; the trusted execution environment stores historical service requests sent by a service client and risk rules for performing risk identification on the service requests initiated by the service client; the method may comprise the steps of:
step 210: responding to a service request to be sent initiated by the service client, and acquiring a user account and a terminal identifier contained in the service request;
step 220: inquiring a historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain a numerical value of a risk index;
step 230: judging whether the numerical value of the risk index reaches a threshold value set in the risk rule or not;
step 240: deleting the equipment identifier carried in the service request to be sent, adding a judgment result, and sending the service request to a service server by the service client; so that the service server executes the service request based on the judgment result.
The Trusted Execution Environment (Trusted Execution Environment) is an independent secure Execution Environment running in parallel with the general-purpose operating system loaded on the terminal device and kept isolated from the general-purpose operating system, and the secure Execution Environment is used for providing secure services for the general-purpose Execution Environment loaded on the terminal device.
The technical solution adopted for mounting the TEE on the terminal device is not particularly limited in this specification, and those skilled in the art can flexibly select the TEE based on actual needs.
For example, in implementation, a TrustZone architecture of ARM corporation may be adopted, and a TEE environment may be installed on a terminal device. The TrustZone architecture is a hardware level security operation solution proposed by ARM corporation. The TrustZone architecture divides the system into two areas, namely TEE and REE (untrusted Execution Environment), and the REE runs a general operating system loaded by the terminal equipment. The TEE has independent computation and storage resources and is completely isolated from the REE. All operations that require privacy (e.g., fingerprinting, cryptographic processing, risk identification, security authentication, etc.) are performed in the TEE, and the remaining operations that do not require privacy are performed in the REE.
Usually, a storage space may be created in the TEE to store historical service requests sent by the service client and risk rules for performing risk identification on the service requests to be sent.
In the implementation process, if a user executes a certain service in the service client, the service client is triggered to send a service request. At this time, the TEE of the device terminal responds to the service request to be sent initiated by the service client, intercepts the service request, and obtains a user account and a device identifier contained in the service request. Typically, service requests are generated in a standardized data format. The existing service request as shown above contains a user account and a device identification.
Then, the TEE may query a historical target service request, which also has the user account and the device identifier, in locally stored historical service requests, and calculate a numerical value of a preset risk indicator based on data of the target historical service request.
The risk indexes include the duration of the time from the first service request success to the time of receiving the service request (hereinafter referred to as the number of days from the first service request success), the number of times of service request success, and the accumulated amount of successful service request.
Generally, the more days until the first service request is successful, the longer the history of the user using the terminal device is, and the longer the user uses the same terminal device, the lower the risk of the user doing harm accordingly. Because, the malicious user needs to change the terminal device frequently to avoid the discovery probability; the frequency of replacing the terminal equipment by a normal user is not high; whether the current business request is at risk can be evaluated based on the risk index of the number of days until the first business request is successful.
Similarly, the more times the service request is successful, the longer the user uses the terminal device to perform normal service, and the lower the risk of doing harm accordingly. Because the malicious user needs to change the terminal device frequently, many normal services will not be executed on one terminal device; whether the current service request is at risk can be evaluated based on the risk index of the number of times the service request is successful.
Similarly, the more the amount of successful accumulated service request is, the more the user performs normal service by using the terminal device, and the larger the amount is, the lower the risk of doing harm accordingly. Because, the malicious user needs to change the terminal device frequently, and does not deposit too much money in order that the money is not frozen completely; it is possible to evaluate whether there is a risk in the current service request based on a risk indicator of the amount of successful accumulated service request.
It should be noted that the number of days until the first service request succeeds, the number of times the service request succeeds, and the accumulated amount of money until the service request succeeds are only some examples of the risk indicator, and any indicator that can be calculated accumulatively may be used as the risk indicator in practical applications, which is not limited in this specification.
The transaction request in the transaction scenario is taken as an example for explanation. Generally, the transaction request may include transaction information such as a user account for payment, a transaction amount, a transaction time, whether the transaction is successful, and the like. The risk indicator then comprises three indicators RFM. Wherein R represents the number of days until the first transaction request is successful; f represents the number of times the transaction request was successful; m represents the amount of successful cumulative transaction request.
The historical transaction requests are screened for the same target historical transaction request as the user account of the current transaction request. The RFM is then calculated from the target historical transaction requests. The calculation process is respectively as follows:
and acquiring the transaction time of each successful target historical transaction request, and calculating the number of days R from the earliest transaction time to the current time.
And acquiring the transaction time of the target historical transaction request with each successful transaction, and calculating the times F corresponding to the transaction times.
The transaction amount of the target historical transaction request of each successful transaction is obtained, and the sum M of the transaction amounts is calculated.
After the value of each risk indicator is calculated, the value of each risk indicator may be compared with a risk rule stored in the terminal device, and whether the value of each risk indicator meets a trust requirement in the risk rule is determined.
Wherein the credible requirement of the risk rule may refer to a threshold value of the risk index. For example, the value of each risk indicator is marked with a corresponding threshold, and if the value exceeds the threshold, the confidence requirement is met; if the value does not exceed the threshold, the confidence requirement is not satisfied.
In one embodiment, the step 240 further comprises:
step A: if the value of the risk index reaches the threshold value set in the risk rule, deleting the equipment identifier carried in the service request to be sent, adding a credible identifier, and sending the service request to a service server by the service client; so that the service server executes the service request based on the trusted identification;
and B: if the value of the risk index does not reach the threshold value set in the risk rule, deleting the equipment identifier carried in the service request to be sent, adding an untrusted identifier, and sending the service request to a service server by the service client; and the service server side carries out risk detection on the service request based on the non-beacon identification. The risk detection refers to that the service server performs more comprehensive (compared with local risk identification of the terminal device) detection on the service request.
Wherein, the trusted identification and the non-trusted identification can be sent in the form of 1 and 0, 1 represents trusted, and 0 represents non-trusted. Of course, in practical application, the configuration can be flexibly configured according to practical requirements, and the description does not limit the configuration.
In an embodiment, the adding determination result may be adding a new field in the service request. But in a more preferred embodiment:
and replacing the equipment identifier carried in the service request to be sent with a judgment result.
Therefore, the original standardized data format of the service request does not need to be changed, and the equipment identifier in the original plaintext is replaced by the desensitized judgment result. The modification cost is low.
In this embodiment, although the service request to be sent generated by the service client originally carries the device identifier; but the risk identification of the service request is carried out locally through the terminal equipment TEE, the equipment identification carried in the service request to be sent is deleted, and the judgment result is added; and the service client sends the processed service request to the service server. Therefore, the service request actually sent to the service server does not carry the equipment identifier, and the leakage of personal information of the user is effectively avoided.
In one embodiment, if the value of the risk indicator reaches a threshold value set in the risk rule, storing the trusted relationship between the user account and the device identifier in the trusted execution environment;
after the obtaining of the user account and the terminal identifier included in the service request, the method further includes:
inquiring whether the user account and the equipment identification in the service request are in a trusted relationship;
if yes, executing the step A; if not, step 220 is performed.
Therefore, when the service client side initiates the service request of the user account subsequently, whether the service request is credible or not is quickly determined by inquiring the credible relation in the TEE. And when the user account and the equipment identifier in the service request are in a trusted relationship, the service request is sent after being added with the trusted mark, and the risk index does not need to be calculated once every time.
In an embodiment, the risk rule is issued to the terminal device by the service server. Correspondingly, the TEE may store the risk rule issued by the service server and received by the service client into the TEE.
In this embodiment, the business server may formulate an initial threshold value of each risk indicator in the risk rule according to experience of the wind control expert.
In order to make the risk rules more accurate, the risk rules also need to be optimized. Specifically, the optimal threshold value of each risk indicator may be calculated based on a machine learning algorithm. Of course, the threshold value of the formulated risk index of the wind control expert may also be directly issued to the service client of the terminal device as the risk rule.
An example is illustrated below:
the business server side determines the business requests of a plurality of risk-free real labels and a plurality of risk real labels as training samples, and calculates the numerical values of risk indexes corresponding to the same equipment identification and the user account from the training samples; carrying out iterative processing by using the following steps until the risk identification rate is greater than a preset requirement:
based on an optimization algorithm, adjusting the threshold value of each risk index in the risk rule;
recording the credible relationship between the equipment identification and the user account after the numerical value of the risk index corresponding to the same equipment identification and the user account in the training sample exceeds the threshold value of the risk index;
determining the training samples which are in the credible relationship as non-risk training labels, and determining the training samples which are not in the credible relationship as risk training labels;
and comparing whether the training label of each training sample is consistent with the real label to determine the risk identification rate of the risk rule.
In this embodiment, the optimization algorithm may be an algorithm that can realize an optimal solution, such as simulated annealing, a gradient descent algorithm, a random forest, or the like. The specific optimization algorithm is not limited in this specification.
In an embodiment, the service server may further encrypt the risk rule and then send the encrypted risk rule to the service client of each terminal device. To improve safety performance.
Similarly, the trusted identifier is obtained by encrypting based on an encryption algorithm provided by the service server. Therefore, the judgment result can be prevented from being tampered in the service request transmission process. Because the trusted mark or the untrusted mark is encrypted, the original data cannot be restored even if the trusted mark or the untrusted mark is tampered, and the service request is discarded.
To sum up, in the embodiment of the present specification, a terminal device of a user locally performs risk identification on a service request to be sent, and then deletes a device identifier in the service request to be sent, adds a judgment result, and sends the service request to a service server; and the service server side processes according to the judgment result in the service request.
On one hand, the risk identification is locally carried out by the terminal equipment, so that the risk identification pressure of the service server can be reduced, the service server only needs to carry out risk detection on the service request with the judgment result of the untrusted identifier, and the service request is directly executed by skipping the risk detection on the service request with the trusted identifier.
On the other hand, the equipment identifier in the service request is deleted, and the added judgment result does not relate to personal information of user privacy; therefore, even if leakage occurs in the transmission process, the personal information of the user cannot be leaked. The problem of privacy disclosure is solved fundamentally.
On the other hand, the trusted relationship between the user account and the device identifier is only stored in the terminal device corresponding to the device identifier, which occupies a small storage space of the terminal device, but greatly releases the storage pressure of the service server.
In another aspect, since both the historical service request and the risk rule are stored in the TEE, and the value of the risk indicator is counted, whether the value of the risk indicator reaches the threshold set in the risk rule is judged; and deleting the equipment identifier carried in the service request to be sent, and adding the judgment result are all completed through the TEE, so that the processing process and the judgment result of the TEE can be ensured to be real and credible by utilizing the data security characteristic of the TEE.
The present specification below also provides an example of another risk identification method, which may be applied to a service client of a terminal device; the service client stores historical service requests and risk rules; the method may comprise the steps of:
responding to a service request to be sent triggered by a user, and acquiring a user account and a terminal identifier contained in the service request;
inquiring a historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain a numerical value of a risk index;
judging whether the numerical value of the risk index reaches a threshold value set in the risk rule or not;
deleting the equipment identifier carried in the service request to be sent, adding a judgment result, and sending the service request to a service server; so that the service server executes the service request based on the judgment result.
In an embodiment, the deleting the device identifier carried in the service request to be sent and adding the determination result includes:
and replacing the equipment identifier carried in the service request to be sent with a judgment result.
In an embodiment, the device identifier carried in the service request to be sent is deleted, a determination result is added, and the service request is sent to a service server; so that the service server executes the service request based on the judgment result, including:
if so, deleting the equipment identifier carried in the service request to be sent, adding a trusted identifier, and sending the service request to a service server; so that the service server executes the service request based on the trusted identification;
if not, deleting the equipment identifier carried in the service request to be sent, adding an untrusted identifier, and sending the service request to a service server; and the service server side carries out risk detection on the service request based on the non-beacon identification.
In an embodiment, the method further comprises:
if the value of the risk index reaches a threshold value set in the risk rule, storing the credible relationship between the user account and the equipment identifier;
after the obtaining of the user account and the terminal identifier included in the service request, the method further includes:
inquiring whether the user account and the equipment identification in the service request are in a trusted relationship;
if yes, deleting the equipment identifier carried in the service request to be sent, adding a trusted identifier, and sending the service request to a service server;
and if not, executing the step of inquiring the historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain the numerical value of the risk index.
In an embodiment, the risk indicator includes at least one of a duration of a time from a time when the first service request is successful to a time when the service request is received, a number of times of successful service requests, and an amount of money accumulated for successful service requests.
In an embodiment, the method further comprises:
and receiving and storing the risk rule issued by the service server.
The difference between this embodiment and the foregoing embodiment shown in fig. 2 is that in this embodiment, the service client performs local risk identification on the service request to be sent, and the historical service request and the risk rule are stored in the service client. Reference may be made to the description of the foregoing embodiments for other purposes.
Corresponding to the embodiment of the risk identification method, the specification also provides an embodiment of a risk identification device. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. The software implementation is taken as an example, and as a logical device, the device is formed by reading corresponding computer business program instructions in the nonvolatile memory into the memory for operation through the processor of the device in which the device is located. From a hardware aspect, as shown in fig. 3, the hardware structure diagram of the device where the risk identification apparatus is located in this specification is shown, except for the processor, the network interface, the memory, and the nonvolatile memory shown in fig. 3, the device where the apparatus is located in the embodiment may generally identify an actual function according to a risk, and may further include other hardware, which is not described again.
Referring to fig. 4, a block diagram of a risk identification apparatus provided in an embodiment of the present disclosure, where the apparatus corresponds to the embodiment shown in fig. 2 and is applied to a trusted execution environment of a terminal device; the trusted execution environment stores historical service requests sent by a service client and risk rules for performing risk identification on the service requests initiated by the service client; the device comprises:
a response unit 310, configured to respond to a service request to be sent initiated by the service client, and acquire a user account and a terminal identifier included in the service request;
the calculating unit 320 is configured to query a historical target service request, which also has the user account and the device identifier, in the historical service request, and perform statistical analysis on the historical target service request to obtain a numerical value of a risk indicator;
a determining unit 330, configured to determine whether the value of the risk indicator reaches a threshold set in the risk rule;
the sending unit 340 deletes the device identifier carried in the service request to be sent, adds the judgment result, and sends the service request to a service server by the service client; so that the service server executes the service request based on the judgment result.
Optionally, the deleting, in the sending unit 340, the device identifier carried in the service request to be sent, and adding the determination result includes:
and replacing the equipment identifier carried in the service request to be sent with a judgment result.
Optionally, the sending unit 340 includes:
a first sending subunit, configured to delete the device identifier carried in the service request to be sent and add a trusted identifier if the value of the risk indicator reaches the threshold set in the risk rule, and send the service request to a service server by the service client; so that the service server executes the service request based on the trusted identification;
a second sending subunit, configured to delete the device identifier carried in the to-be-sent service request and add an untrusted identifier if the value of the risk indicator does not reach the threshold set in the risk rule, and send the service request to a service server by the service client; and the service server side carries out risk detection on the service request based on the non-beacon identification.
Optionally, the apparatus further comprises:
the storage unit is used for storing the credible relationship between the user account and the equipment identifier in the credible execution environment if the numerical value of the risk index reaches the threshold value set in the risk rule;
after the response unit 310, further comprising:
the query unit is used for querying whether the user account and the equipment identifier in the service request are in a trusted relationship; if yes, executing the first sending subunit; if not, the calculation unit 320 is executed.
Optionally, the risk indicator includes at least one of a duration of a time from a time when the first service request is successful to a time when the service request is received, a number of times of successful service requests, and a cumulative amount of successful service requests.
Optionally, the apparatus further comprises:
and the storage unit is used for storing the risk rule received by the business client and issued by the business server into the trusted execution environment.
Corresponding to the risk identification method provided by another embodiment of the present specification, the present specification also provides another embodiment of a risk identification apparatus, which is applied to a service client of a terminal device; the service client stores historical service requests and risk rules; the device comprises:
the response unit is used for responding to a service request to be sent triggered by a user and acquiring a user account and a terminal identifier contained in the service request;
the calculation unit is used for inquiring a historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain a numerical value of a risk index;
the judging unit is used for judging whether the numerical value of the risk index reaches a threshold value set in the risk rule or not;
the sending unit deletes the equipment identifier carried in the service request to be sent, adds a judgment result and sends the service request to a service server; so that the service server executes the service request based on the judgment result.
Optionally, the deleting, by the sending unit, the device identifier carried in the service request to be sent, and adding the determination result includes:
and replacing the equipment identifier carried in the service request to be sent with a judgment result.
Optionally, the sending unit includes:
the first sending subunit deletes the equipment identifier carried in the service request to be sent if the value of the risk index reaches the threshold value set in the risk rule, adds a trusted identifier, and sends the service request to a service server; so that the service server executes the service request based on the trusted identification;
a second sending subunit, configured to delete the device identifier carried in the to-be-sent service request and add an untrusted identifier to the device identifier if the value of the risk indicator does not reach the threshold set in the risk rule, and send the service request to a service server; and the service server side carries out risk detection on the service request based on the non-beacon identification.
Optionally, the apparatus further comprises:
the storage unit is used for storing the credible relationship between the user account and the equipment identifier if the numerical value of the risk index reaches the threshold value set in the risk rule;
after the response unit, the method further comprises:
the query unit is used for querying whether the user account and the equipment identifier in the service request are in a trusted relationship; if yes, executing the first sending subunit; if not, the calculation unit is executed.
Optionally, the risk indicator includes at least one of a duration of a time from a time when the first service request is successful to a time when the service request is received, a number of times of successful service requests, and a cumulative amount of successful service requests.
Optionally, the apparatus further comprises:
and the storage unit is used for receiving and storing the risk rule issued by the service server.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.
Fig. 4 above describes the internal functional modules and the structural schematic of the risk identification device, and the actual execution subject of the risk identification device may be an electronic device, including:
a processor;
a memory for storing processor-executable instructions;
wherein the processor is configured as an embodiment of the risk identification method of any of the preceding claims.
In the above embodiments of the electronic device, it should be understood that the Processor may be a Central Processing Unit (CPU), other general-purpose processors, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), etc. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor, and the aforementioned memory may be a read-only memory (ROM), a Random Access Memory (RAM), a flash memory, a hard disk, or a solid state disk. The steps of a method disclosed in connection with the embodiments of the present specification may be embodied directly in a hardware processor, or in a combination of the hardware and software modules of the processor.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the embodiment of the electronic device, since it is substantially similar to the embodiment of the method, the description is simple, and for the relevant points, reference may be made to part of the description of the embodiment of the method.
Other embodiments of the present disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. This specification is intended to cover any variations, uses, or adaptations of the specification following, in general, the principles of the specification and including such departures from the present disclosure as come within known or customary practice within the art to which the specification pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the specification being indicated by the following claims.
It will be understood that the present description is not limited to the precise arrangements described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.

Claims (13)

1. A risk identification method is applied to a trusted execution environment of terminal equipment; the trusted execution environment stores historical service requests sent by a service client and risk rules for performing risk identification on the service requests initiated by the service client; the method comprises the following steps:
responding to a service request to be sent initiated by the service client, and acquiring a user account and an equipment identifier contained in the service request;
inquiring a historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain a numerical value of a risk index;
judging whether the numerical value of the risk index reaches a threshold value set in the risk rule or not;
if so, replacing the equipment identifier carried in the service request to be sent with a trusted identifier, and sending the service request to a service server by the service client; so that the service server executes the service request based on the trusted identification;
if not, replacing the equipment identifier carried in the service request to be sent with an untrusted identifier, and sending the service request to a service server by the service client; and the service server side carries out risk detection on the service request based on the non-beacon identification.
2. The method of claim 1, further comprising:
if the value of the risk index reaches a threshold value set in the risk rule, storing the trusted relationship between the user account and the equipment identifier in the trusted execution environment;
after the obtaining of the user account and the device identifier included in the service request, the method further includes:
inquiring whether the user account and the equipment identification in the service request are in a trusted relationship;
if so, replacing the equipment identifier carried in the service request to be sent with a trusted identifier, and sending the service request to a service server by the service client;
and if not, executing the step of inquiring the historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain the numerical value of the risk index.
3. The method of claim 1, wherein the risk indicator comprises at least one of a duration of a first successful service request from a time of receiving the service request, a number of successful service requests, and an amount of accumulated successful service requests.
4. The method of claim 1, further comprising:
and storing the risk rule which is received by the business client and issued by the business server into the trusted execution environment.
5. A risk identification method is applied to a business client of a terminal device; the service client stores historical service requests and risk rules; the method comprises the following steps:
responding to a service request to be sent triggered by a user, and acquiring a user account and an equipment identifier contained in the service request;
inquiring a historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain a numerical value of a risk index;
judging whether the numerical value of the risk index reaches a threshold value set in the risk rule or not;
if so, replacing the equipment identifier carried in the service request to be sent with a trusted identifier, and sending the service request to a service server; so that the service server executes the service request based on the trusted identification;
if not, replacing the equipment identifier carried in the service request to be sent with an untrusted identifier, and sending the service request to a service server; and the service server side carries out risk detection on the service request based on the non-beacon identification.
6. The method of claim 5, further comprising:
if the value of the risk index reaches a threshold value set in the risk rule, storing the credible relationship between the user account and the equipment identifier;
after the obtaining of the user account and the device identifier included in the service request, the method further includes:
inquiring whether the user account and the equipment identification in the service request are in a trusted relationship;
if so, replacing the equipment identifier carried in the service request to be sent with a trusted identifier, and sending the service request to a service server;
and if not, executing the step of inquiring the historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain the numerical value of the risk index.
7. A risk identification device is applied to a trusted execution environment of a terminal device; the trusted execution environment stores historical service requests sent by a service client and risk rules for performing risk identification on the service requests initiated by the service client; the device comprises:
the response unit is used for responding to a service request to be sent initiated by the service client and acquiring a user account and an equipment identifier contained in the service request;
the calculation unit is used for inquiring a historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain a numerical value of a risk index;
the judging unit is used for judging whether the numerical value of the risk index reaches a threshold value set in the risk rule or not;
a first sending subunit, configured to replace, if the value of the risk indicator reaches a threshold set in the risk rule, the device identifier carried in the service request to be sent with a trusted identifier, and send, by the service client, the service request to a service server; so that the service server executes the service request based on the trusted identification;
a second sending subunit, configured to, if the value of the risk indicator does not reach the threshold set in the risk rule, replace the device identifier carried in the service request to be sent with an untrusted identifier, and send the service request to a service server by the service client; and the service server side carries out risk detection on the service request based on the non-beacon identification.
8. The apparatus of claim 7, further comprising:
the storage unit is used for storing the credible relationship between the user account and the equipment identifier in the credible execution environment if the numerical value of the risk index reaches the threshold value set in the risk rule;
after the response unit, the method further comprises:
the query unit is used for querying whether the user account and the equipment identifier in the service request are in a trusted relationship; if yes, executing the first sending subunit; if not, the calculation unit is executed.
9. The apparatus of claim 7, wherein the risk indicator comprises at least one of a duration of a first successful service request from a time of receiving the service request, a number of successful service requests, and an amount of accumulated successful service requests.
10. The apparatus of claim 7, further comprising:
and the storage unit is used for storing the risk rule received by the business client and issued by the business server into the trusted execution environment.
11. A risk identification device is applied to a business client of a terminal device; the service client stores historical service requests and risk rules; the device comprises:
the response unit is used for responding to a service request to be sent triggered by a user and acquiring a user account and an equipment identifier contained in the service request;
the calculation unit is used for inquiring a historical target service request which also has the user account and the equipment identifier in the historical service request, and carrying out statistical analysis on the historical target service request to obtain a numerical value of a risk index;
the judging unit is used for judging whether the numerical value of the risk index reaches a threshold value set in the risk rule or not;
the first sending subunit, if the value of the risk index reaches the threshold value set in the risk rule, replaces the device identifier carried in the service request to be sent with a trusted identifier, and sends the service request to a service server; so that the service server executes the service request based on the trusted identification;
a second sending subunit, configured to, if the value of the risk indicator does not reach the threshold set in the risk rule, replace the device identifier carried in the service request to be sent with an untrusted identifier, and send the service request to a service server; and the service server side carries out risk detection on the service request based on the non-beacon identification.
12. The apparatus of claim 11, the apparatus further comprising:
the storage unit is used for storing the credible relationship between the user account and the equipment identifier if the numerical value of the risk index reaches the threshold value set in the risk rule;
after the response unit, the method further comprises:
the query unit is used for querying whether the user account and the equipment identifier in the service request are in a trusted relationship; if yes, executing the first sending subunit; if not, the calculation unit is executed.
13. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor is configured as the method of any of the preceding claims 1-6.
CN202010384152.1A 2020-05-09 2020-05-09 Risk identification method and device and electronic equipment Active CN111310196B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202010384152.1A CN111310196B (en) 2020-05-09 2020-05-09 Risk identification method and device and electronic equipment
CN202110050426.8A CN112836218B (en) 2020-05-09 2020-05-09 Risk identification method and apparatus, and electronic device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010384152.1A CN111310196B (en) 2020-05-09 2020-05-09 Risk identification method and device and electronic equipment

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202110050426.8A Division CN112836218B (en) 2020-05-09 2020-05-09 Risk identification method and apparatus, and electronic device

Publications (2)

Publication Number Publication Date
CN111310196A CN111310196A (en) 2020-06-19
CN111310196B true CN111310196B (en) 2020-12-04

Family

ID=71161090

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202010384152.1A Active CN111310196B (en) 2020-05-09 2020-05-09 Risk identification method and device and electronic equipment
CN202110050426.8A Active CN112836218B (en) 2020-05-09 2020-05-09 Risk identification method and apparatus, and electronic device

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN202110050426.8A Active CN112836218B (en) 2020-05-09 2020-05-09 Risk identification method and apparatus, and electronic device

Country Status (1)

Country Link
CN (2) CN111310196B (en)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111738623B (en) * 2020-07-17 2020-12-04 支付宝(杭州)信息技术有限公司 Business risk detection method and device
CN111741027B (en) * 2020-08-13 2021-10-12 支付宝(杭州)信息技术有限公司 Risk identification method and device and electronic equipment
CN111737721A (en) * 2020-08-13 2020-10-02 支付宝(杭州)信息技术有限公司 Terminal device ID generation method and device and electronic device
CN112948824B (en) * 2021-03-31 2022-04-26 支付宝(杭州)信息技术有限公司 Program communication method, device and equipment based on privacy protection
CN114124568A (en) * 2021-12-07 2022-03-01 中国建设银行股份有限公司 Connection control method and system
CN114638685A (en) * 2022-03-07 2022-06-17 支付宝(杭州)信息技术有限公司 Risk identification method, device and equipment
CN114697698A (en) * 2022-05-10 2022-07-01 北京达佳互联信息技术有限公司 Live broadcast request processing method and device, electronic equipment and storage medium

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1440398A1 (en) * 2001-10-23 2004-07-28 Koninklijke Philips Electronics N.V. Anonymous network-access method and client
KR100923407B1 (en) * 2007-07-25 2009-10-23 삼성에스디에스 주식회사 System and method for risk management and estimation in information technology project
CN110084007B (en) * 2014-10-13 2023-11-28 创新先进技术有限公司 Method, device and terminal for constructing risk control model
CN106600275B (en) * 2015-10-14 2020-08-21 阿里巴巴集团控股有限公司 Risk identification method and device
CN111404887B (en) * 2015-11-02 2023-03-10 创新先进技术有限公司 Service processing method and device
CN107644340A (en) * 2016-07-22 2018-01-30 阿里巴巴集团控股有限公司 Risk Identification Method, client device and risk recognition system
CN109214632B (en) * 2017-07-05 2022-01-28 创新先进技术有限公司 Risk control method and equipment
CN107483500A (en) * 2017-09-25 2017-12-15 咪咕文化科技有限公司 A kind of Risk Identification Method based on user behavior, device and storage medium
CN108521405B (en) * 2018-03-20 2020-12-11 咪咕文化科技有限公司 Risk control method and device and storage medium
CN110059920B (en) * 2019-03-08 2021-08-06 创新先进技术有限公司 Risk decision method and device
CN110033166B (en) * 2019-03-08 2023-04-07 创新先进技术有限公司 Risk identification processing method and device
CN111078435A (en) * 2019-12-18 2020-04-28 支付宝(杭州)信息技术有限公司 Service processing method and device and electronic equipment

Also Published As

Publication number Publication date
CN112836218A (en) 2021-05-25
CN112836218B (en) 2024-04-16
CN111310196A (en) 2020-06-19

Similar Documents

Publication Publication Date Title
CN111310196B (en) Risk identification method and device and electronic equipment
US11388193B2 (en) Systems and methods for detecting online fraud
US10356099B2 (en) Systems and methods to authenticate users and/or control access made by users on a computer network using identity services
US10187369B2 (en) Systems and methods to authenticate users and/or control access made by users on a computer network based on scanning elements for inspection according to changes made in a relation graph
US20190207966A1 (en) Platform and Method for Enhanced Cyber-Attack Detection and Response Employing a Global Data Store
US20190207967A1 (en) Platform and method for retroactive reclassification employing a cybersecurity-based global data store
US20180109507A1 (en) Systems and methods to authenticate users and/or control access made by users on a computer network using a graph score
US11240275B1 (en) Platform and method for performing cybersecurity analyses employing an intelligence hub with a modular architecture
US20140380475A1 (en) User centric fraud detection
WO2020106639A1 (en) Cryptocurrency based malware and ransomware detection systems and methods
CN111738623B (en) Business risk detection method and device
EP3750275B1 (en) Method and apparatus for identity authentication, server and computer readable medium
CN111783073A (en) Black product identification method and device and readable storage medium
CN109815702B (en) Software behavior safety detection method, device and equipment
US11924226B2 (en) Device analytics engine
CN108809909B (en) Data processing method and data processing device
CN113709136A (en) Access request verification method and device
WO2020215123A1 (en) Mitigation of phishing risk
KR101748116B1 (en) Smishing blocking appatatus on cloud mobile environments
CN114401126B (en) Interface security monitoring method and device
JP6857627B2 (en) White list management system
CN117640159A (en) Abnormal access detection method, device, equipment, medium and program product
CN115310128A (en) Risk operation behavior identification method and device, storage medium and computer equipment
CN118102307A (en) Fraud risk prediction method and related device
CN117640165A (en) Defending method, defending device, defending equipment, defending medium and defending program product

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40031265

Country of ref document: HK