Security authentication method, device, equipment, storage medium and product

Abstract

The application discloses a security authentication method and device, equipment, a storage medium and a product, relates to the technical field of terminal verification, and the method comprises the following steps: updating the lock value of the security lock of the block corresponding to the terminal equipment based on the risk level of the user interaction behavior on the terminal equipment; when a data query request of a target block is received, determining the current state of the security lock of the target block based on the lock value of the security lock of the target block; and when the current state of the security lock of the target block is an unlocked state, returning the data of the target block safely. Through the above method, the security lock mechanism is added to the block to which the terminal equipment belongs, and the terminal equipment is automatically locked and unlocked according to the risk level, so that the safety of data is guaranteed.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of terminal verification, in particular to a security authentication method and device, equipment, storage medium and product. BACKGROUND

[0002] At present, a verification code is usually issued to a user during user login, so that the user identifies and verifies the verification code, thereby preventing malicious programs (such as crawlers or ticket grabbing software) from maliciously accessing a website. However, with the development of artificial intelligence technology, the identification and verification ability of malicious programs on the verification code has exceeded that of humans, resulting in that the existing verification code technology not only cannot prevent malicious programs, but also increases the verification difficulty of normal users, and meanwhile, information security risks exist, and user data is easily accessed maliciously.

[0003] The above content is only used to assist in understanding the technical solutions of the present application and does not represent the acknowledgement of the above content as prior art. SUMMARY

[0004] The main purpose of the present application is to provide a security authentication method, device, equipment, storage medium and product, which aims to solve the technical problems of information security risks and easy malicious access of user data in the prior art.

[0005] To achieve the above purpose, the present application provides a security authentication method applied to a consortium chain, wherein a plurality of blocks are arranged in the consortium chain, the plurality of blocks are one-to-one corresponding to different terminal devices, and the plurality of blocks are each provided with a security lock. The method comprises the following steps:

[0006] Updating a lock value of the security lock of the block corresponding to the terminal device based on a risk level of a user interaction behavior on the terminal device;

[0007] When receiving a data query request of a target block, determining a current state of the security lock of the target block based on a lock value of the security lock of the target block;

[0008] When the current state of the security lock of the target block is an unlocked state, safely returning data of the target block.

[0009] In an embodiment, the step of updating the lock value of the security lock of the block corresponding to the terminal device based on the risk level of the user interaction behavior on the terminal device further comprises the following steps:

[0010] Obtaining a running environment detection result, a historical interaction record, device identity information and device address information of the terminal device;

[0011] After the running environment detection result, the device identity information, and the device address information of the terminal device pass through integrity verification and validity verification, a risk coefficient of a user interaction behavior on the terminal device is calculated based on the running environment detection result and historical interaction records of the terminal device.

[0012] Based on the risk coefficient of the terminal device meeting a risk level range, an initial risk level of the user interaction behavior on the terminal device is determined.

[0013] Based on the device address information of the terminal device, the initial risk level is adjusted to obtain the risk level of the user interaction behavior on the terminal device.

[0014] In an embodiment, the alliance chain has a consensus smart contract, and the step of calculating the risk coefficient of the user interaction behavior on the terminal device based on the running environment detection result and the historical interaction records of the terminal device comprises:

[0015] Based on the running environment detection result of the terminal device, a problem existing quantity of the environment detection content in the terminal device is determined.

[0016] Based on the historical interaction records of the terminal device, an interaction risk value of the interaction software in the terminal device is determined.

[0017] Based on the smart contract, a corresponding relationship between the problem existing quantity of the environment detection content, the interaction risk value of the interaction software, the weight of the environment detection, the weight of the interaction, and the risk coefficient is determined.

[0018] Based on the problem existing quantity of the environment detection content in the terminal device, the interaction risk value of the interaction software in the terminal device, the weight of the environment detection, the weight of the interaction, the number of the interaction software, and the corresponding relationship, the risk coefficient of the user interaction behavior on the terminal device is determined.

[0019] In an embodiment, the step of updating the lock value of the security lock of the block corresponding to the terminal device based on the risk level of the user interaction behavior on the terminal device comprises:

[0020] When the risk level of the user interaction behavior on the terminal device is a high-risk behavior level, the lock value of the security lock of the block corresponding to the terminal device is obtained.

[0021] When the lock value of the security lock of the block corresponding to the terminal device is an odd number, the lock value of the security lock of the block corresponding to the terminal device is continuously maintained.

[0022] When the lock value of the security lock corresponding to the terminal device in the target block is an even number, the lock value of the security lock corresponding to the terminal device in the target block is increased by a preset increment value, so that the lock value of the security lock corresponding to the terminal device in the target block after adjustment conforms to an odd number.

[0023] In an embodiment, the step of determining the current state of the security lock of the target block based on the lock value of the security lock of the target block when a data query request of the target block is received comprises:

[0024] When the lock value of the security lock of the target block is a first value, it is determined that the current state of the security lock of the target block is a locked state.

[0025] When the lock value of the security lock of the target block is a second value, it is determined that the current state of the security lock of the target block is an unlocked state, and the second value is greater than the first value.

[0026] When the lock value of the security lock of the target block is greater than the second value, it is determined that the current state of the security lock of the target block is a repeated locked and unlocked state.

[0027] In an embodiment, the method further comprises:

[0028] A preset number of random strategies are generated in the qualified node, and the random strategies that have passed consensus are randomly divided into other nodes to obtain available strategies of each node;

[0029] When the risk level of the user interaction behavior on the terminal device is a suspected risk behavior level, a current use strategy is determined based on the available strategies stored in the request node of the terminal device;

[0030] Based on the current use strategy, the user interaction behavior is securely verified to obtain corresponding interaction behavior verification data, and the current use strategy is deleted from the available strategies of the request node;

[0031] After the user interaction behavior passes the security verification, the user interaction behavior on the terminal device is allowed.

[0032] In addition, to achieve the above-mentioned purpose, the application also provides a security authentication device, which comprises:

[0033] A lock value updating module is configured to update the lock value of the security lock corresponding to the terminal device based on the risk level of the user interaction behavior on the terminal device.

[0034] A data security module is configured to determine the current state of the security lock of the target block based on the lock value of the security lock of the target block when a data query request of the target block is received.

[0035] The data security module is further configured to securely return the data of the target block when the current state of the security lock of the target block is the unlocked state.

[0036] In addition, to achieve the above-mentioned purpose, the present application further provides a security authentication device, which comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the above-mentioned security authentication method.

[0037] In addition, to achieve the above-mentioned purpose, the present application further provides a storage medium, which is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the above-mentioned security authentication method.

[0038] In addition, to achieve the above-mentioned purpose, the present application further provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the above-mentioned security authentication method.

[0039] The present application provides a security authentication method, which updates the lock value of the security lock of the block corresponding to the terminal device based on the risk level of the user interaction behavior on the terminal device; when receiving a data query request of a target block, determines the current state of the security lock of the target block based on the lock value of the security lock of the target block; and when the current state of the security lock of the target block is the unlocked state, securely returns the data of the target block. The present application adds a security lock mechanism to the block to which the terminal device belongs, and automatically locks and unlocks according to the risk level, so that the data corresponding to the terminal device is not easily obtained by off-chain personnel or organizations, ensuring the security of the data, preventing malicious access to user data, and storing the data in the form of a consortium chain, realizing the credibility of the data that cannot be tampered with, solving the technical problems of information security risks in traditional verification methods and easy malicious access to user data. BRIEF DESCRIPTION OF DRAWINGS

[0040] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the present application and, together with the specification, serve to explain the principles of the application.

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows. Obviously, for those skilled in the art, other drawings can also be obtained from these drawings without creative labor.

[0042] Figure 1 Flowchart of the security authentication method embodiment one of the present application;

[0043] Figure 2 Data storage schematic diagram of the security authentication method provided for Embodiment One of the present application;

[0044] Figure 3 Flowchart of the security authentication method of Embodiment Two of the present application;

[0045] Figure 4 Flowchart of the security authentication method of Embodiment Three of the present application;

[0046] Figure 5 Overall architecture schematic diagram of the security authentication method provided for Embodiment Two of the present application;

[0047] Figure 6 Module structure schematic diagram of the security authentication device of the present application;

[0048] Figure 7 Device structure schematic diagram of the hardware running environment involved in the security authentication method in the embodiments of the present application.

[0049] The implementation, functional features and advantages of the present application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0050] It should be understood that the specific embodiments described herein are merely intended to explain the technical solutions of the present application, and are not intended to limit the present application.

[0051] In order to better understand the technical solutions of the present application, the following will be described in detail in combination with the accompanying drawings and specific embodiments.

[0052] The main solution of the embodiments of the present application is: based on the risk level of the user interaction behavior on the terminal device, updating the lock value of the security lock of the corresponding block of the terminal device; upon receiving a data query request of a target block, determining the current state of the security lock of the target block based on the lock value of the security lock of the target block; when the current state of the security lock of the target block is the unlocked state, securely returning the data of the target block.

[0053] At present, with the development of artificial intelligence technology, the recognition and verification ability of malicious programs on the verification code has exceeded that of humans, resulting in that the existing verification code technology not only cannot stop malicious programs, but also increases the verification difficulty of normal users, and at the same time, there are information security risks, and user data is easy to be accessed maliciously.

[0054] The application provides a solution, a security lock mechanism is added to a block to which a terminal device belongs, and automatic locking and unlocking are performed according to a risk level, so that data corresponding to the terminal device is not easily obtained by off-chain personnel or organizations, the security of the data is ensured, malicious access of user data is prevented, and the data is stored in a consortium chain manner, the credibility of data that cannot be tampered with is realized, and the technical problems of information security risks in a traditional verification manner and easy malicious access of user data are solved.

[0055] The embodiment of the application provides a security authentication method, referring to Figure 1 , Figure 1 FIG. 1 is a flowchart of a first embodiment of the security authentication method of the application.

[0056] In the embodiment, the security authentication method includes steps S10-S30.

[0057] In step S10, a lock value of a security lock of a block corresponding to a terminal device is updated based on a risk level of a user interaction behavior on the terminal device.

[0058] It should be noted that the execution subject of the embodiment is a consortium chain, a plurality of blocks are provided in the consortium chain, the plurality of blocks respectively correspond to terminal devices of different users in one-to-one manner, and are used for storing related data of the terminal devices. The terminal device can be a mobile terminal, for example, a smart phone, which is not limited in this regard. Since there are information security risks in the traditional verification manner and user data is easily maliciously accessed, in the embodiment, the plurality of blocks are provided with security locks, a security lock mechanism is added to a block to which a terminal device belongs, so that data corresponding to the terminal device is not easily obtained by off-chain personnel or organizations, the security of the data is ensured, and malicious access of user data is prevented.

[0059] In addition, it should be noted that a consortium chain, that is, a consortium, usually needs to be established first. An APP software vendor on a terminal device can apply to join the consortium chain, an administrator performs account configuration of necessary information on an operation platform corresponding to a management node of the consortium chain, distributes the account configuration to each vendor, each vendor respectively integrates an SDK (Software Development Kit) of a configuration parameter of each vendor in each APP, and uploads the APP to an application market or the like for user download. After the vendor joins the consortium chain, the data of the consortium chain at a current time snapshot is synchronized first, and after the synchronization is completed, the vendor can become a normal node to receive data and participate in a consensus process. If more APP software vendors join the consortium chain subsequently, the above application and configuration process is continued.

[0060] It can be understood that the risk level, i.e., the risk degree of the user interaction behavior on the terminal device, can be divided into a no-risk behavior level, a suspected risk behavior level, and a high-risk behavior level. The user interaction behavior, i.e., the behavior that needs to be determined the risk level, for example, the user attempts to log in to the APP (APP manufacturer has joined the consortium chain) integrated with the SDK, can be set according to the actual situation, and no specific limitation is made. The risk level can be determined according to the running environment detection result of the terminal device. The running environment detection result refers to the detection result of the APP running environment. The detection of the APP running environment usually includes multiple detection contents, such as frida, network layer agent, emulator identification, etc. The detection contents can be flexibly adjusted according to the system configuration or system process name of the terminal device, and then it is determined whether the type of risk exists, the detection result of each detection content is obtained, and the corresponding running environment detection result is generated. The running environment detection result is generated by the SDK and fed back to the consortium chain.

[0061] It should be understood that the user interaction behavior usually triggers the running environment detection, thereby determining the risk level. Exemplarily, after the user downloads and installs the APP integrated with the SDK, each time the APP icon is clicked, the SDK starts to start the running environment detection, generates the running environment detection result, and feeds back to the consortium chain.

[0062] In a feasible implementation, when the risk level of the user interaction behavior on the terminal device is the suspected risk behavior level, the user interaction behavior is verified based on a consensus random strategy, and the corresponding interaction behavior verification data is obtained. The random strategy at least includes a random verification direction and a random verification intensity. When the risk level of the user interaction behavior on the terminal device is the no-risk behavior level, the user interaction behavior on the terminal device is allowed. When the risk level of the user interaction behavior on the terminal device is the high-risk behavior level, the user interaction behavior on the terminal device is prohibited.

[0063] It should be noted that the random strategy, i.e., the random verification mode, is used to evade and identify the machine behavior (the large-scale malicious behavior is usually to arrange the mobile phones simulating clicks in a horizontal shaking support). In the embodiment, the random strategy is a random shaking strategy, i.e., the verification is performed in the form of random shaking, and at this time, the random strategy at least includes a random verification direction and a random verification strength. The random verification direction is a random shaking direction, for example, up and down, left and right, and oblique direction. The random verification strength is a random shaking strength, for example, gently shaking (small force degree), normal shaking (ordinary force degree), and hard shaking (forceful shaking). Exemplarily, assuming that the random verification direction is divided into up and down, left and right, and oblique direction, and the random verification strength is divided into gently shaking, normal shaking, and hard shaking, at this time, the random strategy has nine kinds through permutation and combination: ① up and down gently shaking; ② up and down normal shaking; ③ up and down hard shaking; ④ left and right gently shaking; ⑤ left and right normal shaking; ⑥ left and right hard shaking; ⑦ oblique direction gently shaking; ⑧ oblique direction normal shaking; and ⑨ oblique direction hard shaking. The shaking random strategy can be selected each time the verification is performed.

[0064] It can be understood that if the risk level received by the SDK is a high-risk behavior level (for example, a simulator or machine behavior is found), the user is prohibited from logging in or the next step behavior; if the risk level received by the SDK is a no-risk behavior level, the SDK does not need to pop up the man-machine interaction verification page, and directly enters the next step operation without verification; if the risk level received by the SDK is a suspected risk behavior level, the SDK will pop up a shaking man-machine interaction verification page according to the shaking random strategy, the user shakes according to the requirement, and then passes the verification to enter the next step operation of the APP, and at the same time, the SDK returns the verification data (such as the used random strategy, the shaking strength of the user), the device GPS address, and the device network IP address and other data to the alliance chain for storage.

[0065] It should be understood that the running environment detection result of the terminal device, the risk level, and the interaction behavior verification data obtained based on the risk level are stored in the data chain of the corresponding block.

[0066] It should be noted that according to the device ID, it is checked whether the block of the device exists in the alliance chain. If the block exists, the key value of the corresponding double hash table can be found from the block, and the reported data is written as the value of the key in the first hash table for the smart contract to calculate. The key and value at this time are configured as: Key: hash value in the form of String, which is calculated according to the device ID, and can ensure that "different devices have different hash values, and the same device has the same device ID reported by different APPs"; Value: APPID: running environment detection result: interaction behavior verification data. If the block does not exist, a new block is created, and the device ID is used for hash calculation to obtain the hash value of the double hash table mounted on the block, and the above-mentioned writing process of the hash table is performed.

[0067] It can be understood that each node of the alliance chain packs the double hash table and the block hash value into a data block, and distributes it to the alliance chain. After each node of the alliance chain reaches a consensus on the data block, it is stored locally. At this time, the smart contract is used to calculate the risk coefficient, and the risk coefficient result is mounted in the second hash table in the double hash table with the same hash key value (that is, the first hash table saves the details required for risk coefficient calculation, and the second hash table saves the risk coefficient results). At this time, the structure of the blockchain can be referred to Figure 2 .

[0068] In a possible implementation, step S10 can include: when the risk level of the user interaction behavior on the terminal device is a high-risk behavior level, obtaining the lock value of the security lock of the block corresponding to the terminal device; when the lock value of the security lock of the block corresponding to the terminal device is an odd number, continuing to maintain the lock value of the security lock of the block corresponding to the terminal device; when the lock value of the security lock of the block corresponding to the terminal device is an even number, increasing the lock value of the security lock of the block corresponding to the terminal device by a preset incremental value, so that the lock value of the security lock of the block corresponding to the terminal device after adjustment conforms to an odd number.

[0069] It should be noted that the credibility of the block locking and unlocking process is particularly important, and at the same time, it is best not to bring great storage pressure and economic cost to the storage system of the alliance chain. Therefore, the embodiment adopts a HashMap structure to store the logical security lock of the block. Among them, the Key of HashMap is calculated according to the device ID stored in the block, and the Value is a number, which is 1 by default, that is, when the first data is stored in HashMap, it means that the device ID corresponding to the Key is high-risk, and when subsequent unlocking and locking, the Value continues to increase by 1. At this time, the Value will appear 2 cases, case 1: Value = 1 (locking, at this time, the terminal device corresponding to the Key is in the high-risk behavior level) or Value = 2 (unlocking, at this time, the terminal device corresponding to the Key is in the non-high-risk behavior level); Case 2: Value > 2 (repeated locking and unlocking, at this time, the terminal device corresponding to the Key is in the high-risk behavior level). The lock value of the security lock is the value of the Value corresponding to the Key calculated based on the device ID in the HashMap.

[0070] It can be understood that if the risk level is the high-risk behavior level, the security lock HashMap saved locally by the node is taken out to check whether the Key calculated based on the device ID exists in the HashMap. If it does not exist, it means that it is locked for the first time, and the Key of the HashMap is set to the Key calculated based on the device ID, and the Value = 1 (locking). If it exists, the Value corresponding to the Key calculated based on the device ID in the HashMap is taken out. If the Value = 1 or other odd numbers, it means that it has been locked and does not need to be locked repeatedly. If the Value = 2 or other even numbers, it means that it has been unlocked, and at this time, it continues to be locked, that is, the Value continues to increase by a preset incremental value, which is usually set to 1, and the value of the adjusted Value is an odd number.

[0071] It should be understood that if the risk level is the non-high-risk behavior level (suspected risk behavior level and no-risk behavior level), the security lock HashMap saved locally by the node is taken out to check whether the Key calculated based on the device ID exists in the HashMap. If it does not exist, it means that it is not locked, and at this time, it does not need to be operated. If it exists, the Value corresponding to the Key calculated based on the device ID in the HashMap is taken out. If the Value = 1 or other odd numbers, it means that it has been locked, and at this time, it is unlocked, that is, the Value continues to increase by 1, and the value of the adjusted Value is an even number. If the Value = 2 or even numbers, it means that it has been unlocked, and at this time, it does not need to be unlocked repeatedly.

[0072] Step S20, when receiving the data query request of the target block, determining the current state of the security lock of the target block based on the lock value of the security lock of the target block;

[0073] In an implementable embodiment, step S20 can include: determining that the current state of the security lock of the target block is a locked state when the lock value of the security lock of the target block is a first value; determining that the current state of the security lock of the target block is an unlocked state when the lock value of the security lock of the target block is a second value, the second value being greater than the first value; and determining that the current state of the security lock of the target block is a repeated locked and unlocked state when the lock value of the security lock of the target block is greater than the second value.

[0074] It should be noted that the first value is 1 and the second value is 2. The data query request is a request for querying data in a block, which is usually a request from the outside. The target block is the block in which the data is queried in the request.

[0075] It can be understood that when the outside wants to query the data of the target block, each node first checks the locally saved security lock HashMap after receiving the related request. If the Key calculated based on the device ID does not exist, it means that the risk level of the device is a non-high-risk behavior level, and the data can be normally returned to the caller through the alliance link. If the Key calculated based on the device ID exists, the corresponding Value is processed respectively: when Value = 1, it means a locked state, which means that the device is a high-risk behavior level, and the data cannot be normally returned to the caller through the alliance link; when Value = 2, it means an unlocked state, which means that the device is not a non-high-risk behavior level, and the data can be normally returned to the caller through the alliance link; when Value > 2, it means that the device is a repeated locked and unlocked state, which means that the device is a high-risk behavior level, and the data cannot be normally returned to the caller through the alliance link.

[0076] Step S30: when the current state of the security lock of the target block is an unlocked state, the data of the target block is returned safely.

[0077] It should be noted that the data can be returned to the caller only when the security lock of the target block is in an unlocked state, so as to ensure the security of the data.

[0078] The embodiment provides a security authentication method, which updates a lock value of a security lock of a block corresponding to a terminal device based on a risk level of a user interaction behavior on the terminal device; when a data query request of a target block is received, determines a current state of the security lock of the target block based on the lock value of the security lock of the target block; and when the current state of the security lock of the target block is an unlocked state, returns data of the target block safely. The security lock mechanism is added to the block to which the terminal device belongs, and the terminal device is automatically locked and unlocked according to the risk level, so that data corresponding to the terminal device is not easily obtained by off-chain personnel or organizations, the security of the data is ensured, malicious access of user data is prevented, and the data is stored in the form of a consortium chain, so that the credibility of the data is ensured and the data is not tampered with.

[0079] Based on the first embodiment of the application, in the second embodiment of the application, the same or similar contents as the above-mentioned first embodiment can be referred to the above description, and will not be described hereinafter. On this basis, please refer to Figure 3 , before step S10, the steps S01-S04 can be included:

[0080] Step S01, obtaining a running environment detection result, a historical interaction record, device identity information and device address information of the terminal device;

[0081] It should be noted that the historical interaction record is the historical interaction behavior between the user and the terminal device and the risk coefficient of the historical interaction behavior, which is not limited specifically. The device identity information is information related to the device identity, for example, APPID, SDK account name, SDK ID, etc., which is not limited specifically. The device address information is information related to the device address, at least including device geographic location information and device network address information. The device geographic location information is the current location of the terminal device, for example, device GPS. The device network address information is the IP address of the terminal device, for example, the device network IP address.

[0082] Step S02, after the running environment detection result, the device identity information and the device address information of the terminal device pass through the integrity verification and the validity verification, calculating the risk coefficient of the user interaction behavior on the terminal device based on the running environment detection result and the historical interaction record of the terminal device;

[0083] It should be noted that the validity means that the terminal device (including SDK) identity reported to the consortium chain is valid, that is, the device identity information is valid. That is, the validity verification needs to be based on APP ID, SDK account name, etc. If these information is not chained, it is proved to be invalid information, and the validity verification is not passed. If all these information is chained, it is proved to be valid information, and the validity verification is passed.

[0084] Additionally, it should be noted that integrity refers to the presence of important information such as operating environment detection results, device identity information, and device address information. If all of these information are present, it means that the integrity verification is passed. If at least one type of information is not present, it means that the terminal device reported information is suspected to be artificially processed or machine processed, the integrity verification is not passed, and the user interaction behavior on the terminal device is at risk. At this time, the risk level of the user interaction behavior on the terminal device can be considered as a high-risk behavior level.

[0085] It can be understood that after passing the integrity verification and the validity verification, the risk coefficient of the user interaction behavior on the terminal device can be calculated.

[0086] In a feasible implementation, step S02 can include steps S021-S024:

[0087] Step S021, determining the number of problems existing in the environment detection content in the terminal device based on the operating environment detection results of the terminal device.

[0088] It should be noted that the environment detection content refers to the items of operating environment detection, and the number of problems existing refers to the total number of risks existing in the environment detection content when each interactive software performs operating environment detection, that is, the sum of the number of risks existing in the environment detection content when each interactive software performs operating environment detection. The interactive software refers to the APP that the user interacts with. For example, assuming that the environment detection content is frida, network layer agent, and emulator identification, the interactive software is A, B, and C, if the interactive software A has 2 risks, if the interactive software B has 1 risk, and if the interactive software C has 2 risks, the number of problems existing is 2+1+2=5, and the number of interactive software is 3.

[0089] Step S022, determining the interaction risk value of the interactive software in the terminal device based on the historical interaction record of the terminal device.

[0090] It should be noted that the interaction risk value of the interactive software can be determined according to the previous risk level. If the previous risk level of the interactive software is a no-risk behavior level, the interaction risk value is 1. If the previous risk level of the interactive software is a suspected risk behavior level, the interaction risk value is 2. If the previous risk level of the interactive software is a high-risk behavior level, the interaction risk value is 3.

[0091] Step S023, determining the corresponding relationship between the number of problems existing in the environment detection content, the interaction risk value of the interactive software, the weight of the environment detection, the weight of the interaction, the number of interactive software, and the risk coefficient based on the smart contract.

[0092] It should be noted that the alliance chain has a consensus smart contract, and the smart contract mainly includes contract content and contract functions. The contract content mainly involves environment detection content synchronized with the SDK. The contract function has two functions, which are used to calculate the risk coefficient of the terminal device in real time and real time, and to lock and unlock the security lock of the block to which the terminal device belongs.

[0093] Generally, the smart contract can be edited on the operation platform corresponding to the alliance chain management node. The edited smart contract is packaged into the alliance chain block and published to the alliance chain. Each node of the alliance chain receives the alliance chain block, and saves it in the local main chain after consensus by the consensus algorithm. With the upgrading of human-computer interaction attack and defense technology, for example, when the environment detection content is added or reduced, the smart contract can be upgraded and then published and consensus again.

[0094] It can be understood that the corresponding relationship between the number of problems existing in the environment detection content, the interaction risk value of the interaction software, the weight of the environment detection, the weight of the interaction, the number of interaction software and the risk coefficient, i.e. the calculation relationship of the risk coefficient, is as follows:

[0095]

[0096] In the formula, L represents the risk coefficient, W represents the number of problems existing in the environment detection content, λ i represents the interaction risk value of the interaction software i, k0 represents the weight of the environment detection, k1 represents the weight of the interaction, and N represents the number of interaction software.

[0097] Step S024, based on the number of problems existing in the environment detection content in the terminal device, the interaction risk value of the interaction software in the terminal device, the weight of the environment detection, the weight of the interaction, and the corresponding relationship, determining the risk coefficient of the user interaction behavior on the terminal device.

[0098] It can be understood that the number of problems existing in the environment detection content in the terminal device, the interaction risk value of the interaction software in the terminal device, the weight of the environment detection, the weight of the interaction, and the corresponding relationship, i.e. the calculation relationship of the risk coefficient, can be obtained.

[0099] Step S03, based on the risk level range that the risk coefficient of the terminal device conforms to, determining the initial risk level of the user interaction behavior on the terminal device;

[0100] It should be noted that the risk level range, i.e., the range of risk levels, generally includes a risk level range of a no-risk behavior level, a risk level range of a suspected risk behavior level, and a risk level range of a high-risk behavior level. Exemplarily, the risk coefficient is a decimal less than 1, and the interval (0, 1) is divided into three segments, (0, 0.1] is the risk level range of the no-risk behavior level, (0.1, 0.5] is the risk level range of the suspected risk behavior level, and (0.5, 1) is the risk level range of the high-risk behavior level. The risk coefficient falls into which risk level range, i.e., the risk coefficient is considered to meet the risk level range, so as to obtain the corresponding risk level, and the obtained risk level is the preliminary judgment result, i.e., the initial risk level, which needs to be further determined.

[0101] In step S04, the initial risk level is adjusted based on the device address information of the terminal device, to obtain the risk level of the user interaction behavior on the terminal device.

[0102] It should be noted that the present embodiment cross- validates the initial risk level in combination with the device address information.

[0103] It can be understood that if the GPS address of the device is within a similar distance range compared with the data on the chain and the data of the current on-chain data, or the IP address of the device is a value compared with the data on the chain and the data of the current on-chain data, it indicates that the device has not moved, and the risk level is upgraded, that is, if the initial risk level is a suspected risk behavior level, it is upgraded to a high-risk behavior level, and if the initial risk level is a no-risk behavior level, it is upgraded to a suspected risk behavior level. If the GPS address of the device is not within a similar distance range compared with the data on the chain and the data of the current on-chain data, or the IP address of the device is not a value compared with the data on the chain and the data of the current on-chain data, it indicates that the device has moved, i.e., it moves following the movement of the person to whom the device belongs, and the initial risk level obtained before is maintained, and the initial risk level is taken as the final risk level.

[0104] The embodiment provides a security authentication method, obtains a running environment detection result, a historical interaction record, device identity information and device address information of a terminal device, performs integrity verification and validity verification on the running environment detection result, the device identity information and the device address information of the terminal device, calculates a risk coefficient of a user interaction behavior on the terminal device based on the running environment detection result and the historical interaction record of the terminal device, determines an initial risk level of the user interaction behavior on the terminal device based on a risk level range that the risk coefficient of the terminal device meets, adjusts the initial risk level based on the device address information of the terminal device, and obtains the risk level of the user interaction behavior on the terminal device. The security locking mechanism is added to the block to which the terminal device belongs, and automatic locking and unlocking are performed according to the risk level, so that the data corresponding to the terminal device is not easy to be acquired by off-chain personnel or organizations, the safety of the data is ensured, malicious access of user data is prevented, and the data is stored in the form of a consortium chain, so that the credibility of the data is achieved.

[0105] In the third embodiment of the present application, the same or similar contents as the above embodiments can be referred to the above introduction, and will not be described in detail. On this basis, please refer to Figure 4 , the security authentication method further comprises steps S10' to S40':

[0106] In step S10', a preset number of random strategies are generated in the required nodes, the random strategies that pass the consensus are randomly divided into other nodes to obtain available strategies of each node.

[0107] It should be noted that the random strategy is a random verification method, which is used to evade and identify machine behavior (large-scale malicious behavior is often to arrange a row of simulated click mobile phones on a horizontal shaking support). In the embodiment, the random strategy is a shake random strategy, that is, verification is performed in the form of random shaking. The random strategy at least includes a random verification direction and a random verification intensity. The random verification direction is a random shaking direction, for example: up and down, left and right, and oblique direction. The random verification intensity is a random shaking intensity, for example: gently shaking (small force degree), normal shaking (ordinary force degree), and hard shaking (forceful shaking). Exemplarily, assuming that the random verification direction is divided into up and down, left and right, and oblique direction, and the random verification intensity is divided into gently shaking, normal shaking, and hard shaking, at this time, a maximum of nine random strategies can be generated through permutation and combination: ① up and down gently shaking; ② up and down normal shaking; ③ up and down hard shaking; ④ left and right gently shaking; ⑤ left and right normal shaking; ⑥ left and right hard shaking; ⑦ oblique direction gently shaking; ⑧ oblique direction normal shaking; and ⑨ oblique direction hard shaking.

[0108] In addition, it should be noted that the preset number is the number of random strategies that need to be generated. The alliance chain usually has multiple nodes, and the preset number is related to the current number of nodes of the alliance chain and the frequency of strategy requests in the previous time period, so as to ensure that the supply of random strategies meets the demand and is not wasted. The calculation relationship is as follows:

[0109]

[0110] In the formula, tt represents the minimum value of the number of random strategies allocated to each node, t is the unit time, F is the frequency of strategy requests in the unit time t, and N is the current number of nodes of the alliance chain.

[0111] When the alliance chain is built, the nodes that meet the requirements generate a preset number of random strategies locally, and send these strategies to the alliance chain in a packaged manner. After consensus by a consensus algorithm, the strategies are stored in other nodes. The available strategies are the random strategies stored in each node that can be used for verification, that is, the random strategies allocated to each node.

[0112] It can be understood that the nodes that meet the requirements will allocate the preset number (T) of random strategies to each of the other nodes according to the current alliance chain node situation (the number of nodes N, the node name) and the order of the consensus results fed back by each of the other nodes, that is, each node uses T / N strategies, the random strategies allocated to the first node that feeds back the consensus result are the first T / N strategies, the random strategies allocated to the second node that feeds back the consensus result are the T / N+1th to 2×(T / N)th strategies, and so on, so that each node has its own available strategies. Since the number of nodes of the alliance chain is variable, and the communication quality of each node is also variable, the strategy allocation has strong randomness.

[0113] It should be understood that the nodes that meet the requirements can be the first node to start, a new node to join, or a node that stores a number of available strategies less than the preset number of strategies. The preset number of strategies can be set to a specific value according to actual needs, which is usually less than the preset number (T). The consensus speed of the mode of generating a batch of strategies by a single node is faster than that of generating a batch of strategies by multiple nodes. On the basis of consensus, the strategy allocation can ensure that the position and number of strategies allocated to each node are dynamically changed in the case of dynamic changes of the nodes of the blockchain, thereby increasing the security of the strategies and making them less likely to be cracked.

[0114] In step S20', when the risk level of the user interaction behavior on the terminal device is a suspected risk behavior level, a current use strategy is determined based on the available strategies stored in the request node of the terminal device;

[0115] It should be noted that the requesting node is a node requesting a random strategy from the SDK, and the current use strategy is a random strategy randomly selected from the available strategies. The risk level can be generally divided into a no-risk behavior level, a suspected risk behavior level, and a high-risk behavior level. When the risk level of the user interaction behavior is the suspected risk behavior level, the SDK requests a random strategy for verification from the requesting node, and the requesting node randomly selects a random strategy from the available strategies stored locally as the current use strategy and returns it to the SDK.

[0116] Exemplarily, when the requesting node receives the request of the SDK, the requesting node takes the first random strategy in the available strategies locally and returns it to the SDK.

[0117] In a feasible implementation, the step of determining the risk level of the user interaction behavior includes: obtaining a running environment detection result, a historical interaction record, device identity information, and device address information of the terminal device; after the running environment detection result, the device identity information, and the device address information of the terminal device pass through integrity verification and validity verification, calculating a risk coefficient of the user interaction behavior on the terminal device based on the running environment detection result and the historical interaction record of the terminal device; determining an initial risk level of the user interaction behavior on the terminal device based on a risk level range that the risk coefficient of the terminal device conforms to; and adjusting the initial risk level based on the device address information of the terminal device to obtain the risk level of the user interaction behavior on the terminal device. For specific contents, reference can be made to the second embodiment described above, which will not be described here again.

[0118] In step S30', the user interaction behavior is securely verified based on the current use strategy, corresponding interaction behavior verification data is obtained, and the current use strategy is deleted from the available strategies of the requesting node.

[0119] It can be understood that after the SDK receives the current use strategy returned by the requesting node, the SDK can pop up a shake-to-activate human-computer interaction verification page on the interface of the terminal device according to the obtained current use strategy, securely verify the user interaction behavior, and the page will prompt the random verification direction and the random verification intensity of the current use strategy. If the direction and intensity of the user's shaking both conform to the current use strategy, it is considered that the user passes the security verification. If at least one of the direction and intensity of the user's shaking does not conform to the current use strategy, it is considered that the user does not pass the security verification. At the same time, the SDK transmits the data of the human-computer interaction verification (such as the current use strategy, the intensity of the user's shaking, and the direction of the user's shaking), the device GPS address, and the device network access IP address back to the alliance chain for storage.

[0120] It should be understood that in order to ensure that the new strategy can be used next time when the request arrives, the current use strategy is deleted from the available strategies each time. Illustratively, when the request node receives a request of the SDK, if the request node takes out the first random strategy in the available strategies as the current use strategy from the local and returns it to the SDK, the first random strategy in the available strategies that has been used is deleted.

[0121] Step S40', after the user interaction behavior is verified, the user interaction behavior on the terminal device is allowed.

[0122] It can be understood that the user can enter the next step of the APP through verification.

[0123] In addition, when the risk level of the user interaction behavior on the terminal device is the no-risk behavior level, the user interaction behavior on the terminal device is allowed; and when the risk level of the user interaction behavior on the terminal device is the high-risk behavior level, the user interaction behavior on the terminal device is prohibited.

[0124] In a specific implementation, when the risk level received by the SDK is the high-risk behavior level (for example, it is found that it is a simulator or a machine behavior), the user is prohibited from logging in or proceeding to the next step; when the risk level received by the SDK is the no-risk behavior level, the SDK does not need to pop up the man-machine interaction verification page and directly enters the next step of operation without verification; and when the risk level received by the SDK is the suspected risk behavior level, the SDK pops up the man-machine interaction verification page of the shake according to the shake random strategy, and the user can enter the next step of the APP through verification after shaking according to the requirement.

[0125] The embodiment provides a security authentication method, which divides the risk level into a no-risk behavior level, a suspected risk behavior level and a high-risk behavior level, the no-risk behavior level does not need to be verified by man-machine interaction, the suspected risk behavior level is verified by the shake with a random strategy, and the high-risk behavior level is prohibited from logging in or proceeding to the next step, wherein the random strategy is obtained from the existing consensus of the alliance chain. The security verification is realized in the shake mode which can be easily realized at each age stage, the random direction and the random strength of the consensus are obtained from the alliance chain, and the device GPS address and the device network IP address are combined, so that the user can be conveniently verified, and the simulator and other machine behaviors can be accurately identified and avoided.

[0126] Illustratively, in order to assist in understanding the implementation process of the security authentication method obtained after the embodiment two is combined, please refer to Figure 5 , Figure 5 An overall architecture diagram of a security authentication method is provided, and specifically:

[0127] The overall architecture is composed of a consortium chain and a terminal device of a user, and the terminal device is installed with multiple APPs integrated with an SDK. The SDK is used to detect a running environment of the terminal device and divide the user into a no-risk user, a suspected risk user and a high-risk user according to a risk coefficient calculated by a smart contract of the consortium chain. No human-computer interaction verification is required for the no-risk user, a shake verification with a random strategy is used for the suspected risk user, and the high-risk user is prohibited from logging in or performing a next operation. The random strategy is obtained from an existing consensus of the consortium chain. The shake verification is easily realized at each age stage, a random direction and strength are obtained from the consensus of the consortium chain, and a device GPS address and a device IP address are combined, so as to facilitate the user in the human-computer verification and identify and avoid machine behaviors such as simulators. The consortium chain is responsible for storing and consensus of detection contents of each on-chain device environment, an interaction verification result of the user on each APP in the on-chain device and calculation and result consensus storage of a risk coefficient of the terminal device. The risk coefficient is calculated based on the environment detection data on the device and historical data on the chain, and the data is obtained by the consortium chain, so as to realize the unforgeable credibility of the interaction data of the on-chain device, and thus is applicable to all APPs of the device. When the risk coefficient of the device corresponds to no risk, the verification link of all APPs does not require human-computer interaction, and when the suspected risk user passes the shake verification, other APPs also do not require human-computer interaction.

[0128] It should be noted that the above examples are only used for understanding the present application and do not constitute a limitation on the security authentication method of the present application. More forms of simple changes based on the technical concept are within the protection scope of the present application.

[0129] The present application also provides a security authentication device, which is described in detail in Figure 6 The security authentication device comprises:

[0130] A lock value updating module 10 is configured to update a lock value of a security lock of a block corresponding to the terminal device based on a risk level of a user interaction behavior on the terminal device.

[0131] A data security module 20 is configured to determine a current state of the security lock of the target block based on the lock value of the security lock of the target block when receiving a data query request of the target block.

[0132] The data security module 20 is further configured to securely return data of the target block when the current state of the security lock of the target block is the unlocked state.

[0133] In a feasible implementation, the lock value updating module 10 is further configured to obtain a running environment detection result, a historical interaction record, device identity information and device address information of the terminal device.

[0134] After the running environment detection result, the device identity information, and the device address information of the terminal device are verified for integrity and validity, a risk coefficient of a user interaction behavior on the terminal device is calculated based on the running environment detection result and the historical interaction record of the terminal device.

[0135] Based on the risk coefficient of the terminal device meeting the risk level range, an initial risk level of the user interaction behavior on the terminal device is determined.

[0136] Based on the device address information of the terminal device, the initial risk level is adjusted to obtain the risk level of the user interaction behavior on the terminal device.

[0137] In a feasible implementation, the lock value updating module 10 is further configured to determine the number of problems existing in the environment detection content in the terminal device based on the running environment detection result of the terminal device.

[0138] Based on the historical interaction record of the terminal device, an interaction risk value of the interaction software in the terminal device is determined.

[0139] Based on the smart contract, a corresponding relationship between the number of problems existing in the environment detection content, the interaction risk value of the interaction software, the weight of the environment detection, the weight of the interaction, and the risk coefficient is determined.

[0140] Based on the number of problems existing in the environment detection content in the terminal device, the interaction risk value of the interaction software in the terminal device, the weight of the environment detection, the weight of the interaction, the number of the interaction software, and the corresponding relationship, the risk coefficient of the user interaction behavior on the terminal device is determined.

[0141] In a feasible implementation, the lock value updating module 10 is further configured to, when the risk level of the user interaction behavior on the terminal device is a high-risk behavior level, acquire a lock value of a safety lock of a block corresponding to the terminal device.

[0142] When the lock value of the safety lock of the block corresponding to the terminal device is an odd number, the lock value of the safety lock of the block corresponding to the terminal device is continuously maintained.

[0143] When the lock value of the safety lock of the block corresponding to the terminal device is an even number, the lock value of the safety lock of the block corresponding to the terminal device is increased by a preset incremental value, so that the lock value of the safety lock of the block corresponding to the terminal device meets an odd number after adjustment.

[0144] In a feasible implementation, the data security module 20 is further configured to, when the lock value of the safety lock of the target block is a first value, determine that a current state of the safety lock of the target block is a locked state.

[0145] When the lock value of the security lock of the target block is the second value, the current state of the security lock of the target block is determined to be the unlocked state, and the second value is greater than the first value;

[0146] When the lock value of the security lock of the target block is greater than the second value, the current state of the security lock of the target block is determined to be a repeated locking and unlocking state.

[0147] In one feasible implementation, the data security module 20 is further configured to generate a preset number of random policies in eligible nodes, and randomly distribute the consensus-agreed random policies to other nodes to obtain the available policies for each node.

[0148] When the risk level of user interaction behavior on the terminal device is a suspected risk behavior level, the current usage strategy is determined based on the available strategies stored in the request node of the terminal device.

[0149] Based on the current usage policy, perform security verification on user interaction behavior, obtain corresponding interaction behavior verification data, and delete the current usage policy from the available policies of the request node;

[0150] After the user interaction behavior passes security verification, the user interaction behavior on the terminal device is allowed.

[0151] The security authentication device provided in this application, employing the security authentication method described in the above embodiments, can solve the technical problem that traditional verification methods have information security risks and user data is easily accessed maliciously. Compared with the prior art, the beneficial effects of the security authentication device provided in this application are the same as those of the security authentication method provided in the above embodiments, and other technical features in the security authentication device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0152] This application provides a security authentication device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the security authentication method in Embodiment 1 above.

[0153] The following is for reference. Figure 7The diagram illustrates a structural schematic suitable for implementing the security authentication device in the embodiments of this application. The security authentication device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The security authentication device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0154] like Figure 7 As shown, the security authentication device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the security authentication device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the security authentication device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows security authentication devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0155] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program codes for executing the method shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network through a communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiments disclosed in the present application are executed.

[0156] The security authentication device provided by the present application adopts the security authentication method in the above-mentioned embodiments, and can solve the technical problems of information security risks and easy malicious access of user data in the traditional verification method. Compared with the prior art, the security authentication device provided by the present application has the same beneficial effects as the security authentication method provided by the above-mentioned embodiments, and other technical features in the security authentication device are the same as the features disclosed in the previous embodiment method, which will not be repeated here.

[0157] It should be understood that various parts of the present application can be realized by hardware, software, firmware or a combination thereof. In the description of the above-mentioned embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0158] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0159] The present application provides a computer readable storage medium having stored thereon computer readable program instructions (i.e. computer program) for executing the security authentication method in the above-mentioned embodiments.

[0160] The computer readable storage medium provided in the application may be, for example, a U disk, but is not limited to an electric, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination thereof. More specific examples of the computer readable storage medium may include, but are not limited to, an electric connection with one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the embodiment, the computer readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system, or device. The program code contained on the computer readable storage medium can be transmitted by any suitable medium, including but not limited to an electric wire, an optical cable, an RF (Radio Frequency), and the like, or any suitable combination thereof.

[0161] The computer readable storage medium described above may be contained in the security authentication device, or may exist separately without being assembled into the security authentication device.

[0162] The computer readable storage medium described above carries one or more programs, which, when executed by the security authentication device, cause the security authentication device to: update a lock value of a security lock of a corresponding block of a terminal device based on a risk level of a user interaction behavior on the terminal device; determine a current state of the security lock of a target block based on the lock value of the security lock of the target block when receiving a data query request of the target block; and return data of the target block in a security mode when the current state of the security lock of the target block is an unlocked state.

[0163] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0164] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a segment, or a portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may

[0165] The modules involved in the embodiments of the present application can be implemented in the form of software or in the form of hardware. In some cases, the name of the module does not constitute a limitation on the module itself.

[0166] The readable storage medium provided by the present application is a computer readable storage medium, which stores computer readable program instructions (i.e., a computer program) for executing the above security authentication method, and can solve the technical problems of information security risks and easy malicious access of user data in the traditional verification method. Compared with the prior art, the computer readable storage medium provided by the present application has the same beneficial effects as the security authentication method provided by the above embodiments, and will not be described here.

[0167] The application further provides a computer program product comprising a computer program which, when executed by a processor, implements the steps of the secure authentication method as described above.

[0168] The computer program product provided by the application can solve the technical problem of information security risks in the conventional verification method and easy malicious access of user data. Compared with the prior art, the beneficial effects of the computer program product provided by the application are the same as those of the secure authentication method provided by the above-mentioned embodiments, and are not described here.

[0169] The above is only some embodiments of the application, and does not limit the patent scope of the application. Any equivalent structural transformation made by using the content of the specification and drawings, or direct / indirect application in other related technical fields under the technical concept of the application is included in the patent protection scope of the application.

Claims

1. A security authentication method, characterized in that, Applied to a consortium blockchain, wherein the consortium blockchain has multiple blocks, each block corresponding to a different terminal device, and each block is equipped with a security lock, the method includes: Based on the risk level of user interaction behavior on the terminal device, update the lock value of the security lock of the corresponding block on the terminal device; Upon receiving a data query request for the target block, the current state of the target block's security lock is determined based on the lock value of the target block's security lock. When the current state of the security lock of the target block is unlocked, the data of the target block is safely returned.

2. The method as described in claim 1, characterized in that, Before the step of updating the lock value of the security lock of the corresponding block of the terminal device based on the risk level of user interaction behavior on the terminal device, the method further includes: Obtain the operating environment detection results, historical interaction records, device identity information, and device address information of the terminal device; After the operating environment detection results, device identity information, and device address information of the terminal device pass the integrity verification and validity verification, the risk coefficient of user interaction behavior on the terminal device is calculated based on the operating environment detection results and historical interaction records of the terminal device. Based on the risk level range that the risk coefficient of the terminal device falls within, the initial risk level of the user interaction behavior on the terminal device is determined; Based on the device address information of the terminal device, the initial risk level is adjusted to obtain the risk level of user interaction behavior on the terminal device.

3. The method as described in claim 2, characterized in that, The consortium blockchain contains consensus-agreed smart contracts. The step of calculating the risk coefficient of user interaction behavior on the terminal device based on the terminal device's operating environment detection results and historical interaction records includes: Based on the operating environment detection results of the terminal device, determine the number of problems existing in the environmental detection content of the terminal device; Based on the historical interaction records of the terminal device, the interaction risk value of the interaction software in the terminal device is determined; Based on the smart contract, the number of problems in the environmental detection content, the interaction risk value of the interactive software, the weight of environmental detection, and the correspondence between the interaction weight and the risk coefficient are determined. Based on the number of problems in the environmental detection content of the terminal device, the interaction risk value of the interactive software in the terminal device, the weight of environmental detection, the weight of interaction, the number of interactive software, and the corresponding relationship, the risk coefficient of user interaction behavior on the terminal device is determined.

4. The method as described in claim 1, characterized in that, The step of updating the security lock value of the corresponding block of the terminal device based on the risk level of user interaction behavior on the terminal device includes: When the risk level of user interaction behavior on the terminal device is high-risk behavior level, the lock value of the security lock of the corresponding block of the terminal device is obtained; When the lock value of the security lock of the corresponding block of the terminal device is odd, the lock value of the security lock of the corresponding block of the terminal device shall be maintained. When the lock value of the security lock of the corresponding block of the terminal device is even, the lock value of the security lock of the corresponding block of the terminal device is increased by a preset increment value so that the lock value of the security lock of the corresponding block of the terminal device is odd after adjustment.

5. The method as described in claim 1, characterized in that, The step of determining the current state of the security lock of the target block based on the lock value of the security lock of the target block when a data query request for the target block is received includes: When the lock value of the security lock of the target block is the first value, the current state of the security lock of the target block is determined to be the locked state; When the lock value of the security lock of the target block is the second value, the current state of the security lock of the target block is determined to be the unlocked state, and the second value is greater than the first value; When the lock value of the security lock of the target block is greater than the second value, the current state of the security lock of the target block is determined to be a repeated locking and unlocking state.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: A preset number of random strategies are generated in the nodes that meet the requirements. The consensus-agreed random strategies are then randomly distributed to other nodes to obtain the available strategies for each node. When the risk level of user interaction behavior on the terminal device is a suspected risk behavior level, the current usage strategy is determined based on the available strategies stored in the request node of the terminal device. Based on the current usage policy, perform security verification on user interaction behavior, obtain corresponding interaction behavior verification data, and delete the current usage policy from the available policies of the request node; After the user interaction behavior passes security verification, the user interaction behavior on the terminal device is allowed.

7. A security authentication device, characterized in that, Applied to a consortium blockchain, wherein the consortium blockchain has multiple blocks, each block corresponding to a different terminal device, and each block is equipped with a security lock, the device includes: The lock value update module is used to update the lock value of the security lock of the corresponding block of the terminal device based on the risk level of the user interaction behavior on the terminal device. The data security module is used to determine the current state of the security lock of the target block based on the lock value of the security lock of the target block when a data query request for the target block is received. The data security module is also used to securely return the data of the target block when the current state of the security lock of the target block is unlocked.

8. A security authentication device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the security authentication method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the security authentication method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the security authentication method as described in any one of claims 1 to 6.

Images