Transaction risk identification method and device based on trusted environment, and electronic equipment

Abstract

The invention discloses a transaction risk identification method and device based on a trusted environment, and an electronic device, and relates to the field of financial science and technology or other related fields, and the transaction risk identification method comprises the steps: determining a target device for executing a transaction under the condition that it is detected that a client starts a preset financial application for transaction, and calling a preset client interface of the target equipment, reading all equipment behavior tags generated based on the non-sensitive data from the trusted environment of the target equipment by adopting the preset client interface, and carrying out risk identification on the transaction based on all the equipment behavior tags so as to take effective protection measures for the risk that a customer possibly suffers from loss. The technical problem that the efficiency of identifying the transaction risk is low is solved.

Description

Technical Field

[0001] This invention relates to the field of financial technology, and more specifically, to a method, apparatus, and electronic device for identifying transaction risks based on a trusted environment. Background Technology

[0002] A Trusted Execution Environment (TEE) is a hardware-level secure isolated area that creates a secure world independent of the ordinary operating system (REE) on the CPU (Central Processing Unit) of a mobile device. TEE uses hardware encryption and memory isolation mechanisms to ensure the confidentiality and integrity of sensitive data (such as biometrics and payment keys), preventing information theft by risky software or root (administrator privileges) attacks. A lightweight secure operating system runs within the TEE, supporting Trusted Apps (TAs) to handle high-security tasks such as fingerprint comparison and encrypted signatures. REE-side applications can only obtain processing results through secure communication interfaces and cannot directly access the original data. It is widely used in scenarios such as mobile payments, biometric authentication, and digital rights protection.

[0003] Currently, data from different operators, banks, and even regions is difficult to transfer due to privacy concerns, technical barriers, and fragmented management. Key risk characteristic data (such as making and receiving risky calls, accessing abnormal links, and downloading illegal installation packages) between different institutions cannot be shared and analyzed in real time, forming a scattered and unconnected "information barrier".

[0004] Among related technologies, federated learning and privacy-preserving computation techniques can be employed, based on encryption algorithms (such as secure multi-party computation) or hardware isolation (trusted execution environment), to achieve cross-institutional data-free joint modeling. Banks and operators exchange encrypted parameters instead of raw data to collaboratively train risk models and accurately associate abnormal phone numbers with financial accounts. Federated learning allows each institution to train its model locally, uploading only gradient updates, and then aggregating and optimizing the global model through a central server, avoiding the leakage of raw data. However, the process of building models among institutions is complex, requiring intermediate servers, and significant time is spent on network communication, resulting in low efficiency in identifying transaction risks.

[0005] There is currently no effective solution to the above problems. Summary of the Invention

[0006] This invention provides a method, apparatus, and electronic device for identifying transaction risks based on a trusted environment, in order to at least solve the technical problem of low efficiency in identifying transaction risks.

[0007] According to one aspect of the present invention, a transaction risk identification method based on a trusted environment is provided, comprising: upon detecting that a customer initiates a transaction using a preset financial application, determining the target device executing the transaction, wherein the target device has a pre-built trusted environment, the trusted environment storing device behavior tags written by different authorized institutions, wherein the device behavior tags are tags generated based on non-sensitive data; invoking a preset client interface of the target device, wherein the preset client interface is a unified interface built for devices from different manufacturers; using the preset client interface to read all device behavior tags from the trusted environment of the target device; and identifying the transaction risk based on all device behavior tags.

[0008] Furthermore, before determining the target device for executing the transaction after detecting that a customer has initiated a pre-set financial application to conduct a transaction, the process includes: constructing a federated insight chain, wherein the federated insight chain includes at least: a device hardware layer, a device-side trust layer, a management institution layer, and an institution application layer; the federated insight chain is used to store non-sensitive data and share the non-sensitive data with all authorized institutions; the non-sensitive data is a device behavior tag generated by each authorized institution based on abnormal events.

[0009] Furthermore, before determining the target device for executing the transaction after detecting that a customer has initiated a pre-set financial application to conduct a transaction, the process includes: constructing a trusted hardware environment, and constructing a device hardware layer based on the trusted hardware environment, wherein the device hardware layer is used to run trusted environments for devices manufactured by different manufacturers; and constructing a device-side trusted layer based on the device hardware layer, wherein the device-side trusted layer runs in a trusted environment and is used to store multiple trusted blocks, each trusted block including device behavior tags written by the same authorized institution.

[0010] Furthermore, before determining the target device for executing the transaction after detecting that a customer has launched a preset financial application to conduct a transaction, the process includes: encapsulating trusted call interfaces from different vendors to obtain a preset client interface, wherein the trusted call interface is used to call a trusted environment; building a management layer based on the preset client interface; issuing authorization certificates for institutions based on the management layer, and identifying institutions with authorization certificates as authorized institutions; and adding the authorized institutions to the institution application layer.

[0011] Furthermore, after constructing the federated insight chain, the process also includes: generating a device behavior tag when an abnormal event is detected at the authorized agency's end; calling the preset client interface of the abnormal device that executed the abnormal event; using the preset client interface to call a secure call instruction, and writing the device behavior tag into the target trusted block in the trusted environment of the abnormal device through the secure call instruction, wherein the target trusted block is a trusted block associated with the authorized agency's end.

[0012] Furthermore, the step of generating a device behavior tag when an abnormal event is detected at the authorized agency includes: parsing the abnormal event to determine the event timestamp, event type, and event information of the abnormal event; generating an initial device behavior tag based on the authorized agency's agency identifier, event timestamp, event type, and event information; and encrypting the initial device behavior tag based on a preset private key to obtain a device behavior tag, wherein each preset private key corresponds to a preset public key, and each authorized agency stores the preset public key.

[0013] Furthermore, the steps for risk identification of transactions based on all device behavior tags include: determining the transaction type and, based on the transaction type, determining a target risk identification model; using the target risk identification model to identify all device behavior tags and transaction information to obtain a risk score; and if the risk score is greater than a preset threshold, determining that the transaction has a risk and suspending the execution of the transaction.

[0014] According to another aspect of the present invention, a transaction risk identification device based on a trusted environment is also provided, comprising: a determining unit, configured to determine the target device executing the transaction when a customer initiates a preset financial application to conduct a transaction, wherein the target device has a pre-built trusted environment, and the trusted environment stores device behavior tags written by different authorized institutions, wherein the device behavior tags are tags generated based on non-sensitive data; a calling unit, configured to call a preset client interface of the target device, wherein the preset client interface is a unified interface built for devices from different manufacturers; a reading unit, configured to read all device behavior tags from the trusted environment of the target device using the preset client interface; and an identification unit, configured to identify the risk of the transaction based on all device behavior tags.

[0015] Furthermore, the first building module for the transaction risk identification device also includes: before determining the target device for executing the transaction when a customer initiates a pre-set financial application to conduct a transaction, constructing a federated insight chain, wherein the federated insight chain includes at least: a device hardware layer, a device-side trust layer, a management institution layer, and an institution application layer; the federated insight chain is used to store non-sensitive data and share the non-sensitive data with all authorized institutions; the non-sensitive data is a device behavior tag generated by each authorized institution based on abnormal events.

[0016] Furthermore, the transaction risk identification device also includes: a second construction module, used to construct a trusted hardware environment before determining the target device for executing the transaction when a customer initiates a preset financial application to conduct a transaction, and to construct a device hardware layer based on the trusted hardware environment, wherein the device hardware layer is used to run trusted environments of devices manufactured by different manufacturers; and a first construction module, used to construct a device-side trusted layer based on the device hardware layer, wherein the device-side trusted layer runs in a trusted environment and is used to store multiple trusted blocks, each trusted block including device behavior tags written by the same authorized institution.

[0017] Furthermore, the transaction risk identification device also includes: a first encapsulation module, used to encapsulate trusted call interfaces from different vendors to obtain a preset client interface before determining the target device for executing the transaction when a customer initiates a preset financial application to conduct a transaction, wherein the trusted call interface is used to call a trusted environment; a third construction module, used to construct a management institution layer based on the preset client interface; a first issuance module, used to issue authorization certificates to the institution based on the management institution layer, and determine the institution with the authorization certificate as the authorized institution; and a first joining module, used to join the authorized institution to the institution application layer.

[0018] Furthermore, the transaction risk identification device also includes: a first generation module, used to generate a device behavior tag after an abnormal event is detected at the authorized institution after the federated insight chain is built; a first invocation module, used to invoke a preset client interface of the abnormal device that executes the abnormal event; and a second invocation module, used to invoke a secure invocation instruction using the preset client interface, and write the device behavior tag to a target trusted block in the trusted environment of the abnormal device through the secure invocation instruction, wherein the target trusted block is a trusted block associated with the authorized institution.

[0019] Furthermore, the first generation module includes: a first parsing submodule, used to parse the abnormal event and determine the event timestamp, event type, and event information of the abnormal event; a first generation submodule, used to generate an initial device behavior tag based on the institution identifier, event timestamp, event type, and event information of the authorized institution; and a first encryption submodule, used to encrypt the initial device behavior tag based on a preset private key to obtain a device behavior tag, wherein each preset private key corresponds to a preset public key, and each authorized institution stores a preset public key.

[0020] Furthermore, the identification unit includes: a first determining module, used to determine the transaction type of the transaction and, based on the transaction type, determine a target risk identification model; a first identification module, used to identify all device behavior tags and transaction information of the transaction using the target risk identification model to obtain a risk score; and a second determining module, used to determine that the transaction has a risk and suspend the execution of the transaction if the risk score is greater than a preset threshold.

[0021] According to another aspect of the present invention, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described transaction risk identification methods based on a trusted environment.

[0022] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement any of the above-described transaction risk identification methods based on a trusted environment.

[0023] In this invention, when it is detected that a customer has launched a preset financial application to conduct a transaction, the target device for executing the transaction is determined, the preset client interface of the target device is called, and all device behavior tags are read from the trusted environment of the target device using the preset client interface. Based on all device behavior tags, the transaction risk is identified, thereby solving the technical problem of low efficiency in identifying transaction risks.

[0024] This invention employs a TEE-based technical architecture and, by constructing standardized Trusted Application (TA) and Client Application (CA) interfaces (i.e., pre-defined client interfaces), achieves the goal of securely sharing device behavior tags across institutions. This enables real-time risk identification and early warning for transactions, thereby solving the problem of difficulty in identifying transaction risks due to data silos and privacy concerns. Specifically, when a customer initiates a pre-defined financial application to conduct a transaction, the target device for the transaction can be identified and its TEE accessed. A unified interface is used to call the TA within the TEE to read the stored non-sensitive device behavior information (i.e., device behavior tags). Then, a risk assessment strategy is executed based on these tags, effectively improving the efficiency and accuracy of transaction risk identification while ensuring user privacy. Attached Figure Description

[0025] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0026] Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a transaction risk identification method based on a trusted environment is shown.

[0027] Figure 2 This is a flowchart of a transaction risk identification method based on a trusted environment according to Embodiment 1 of the present invention;

[0028] Figure 3 This is a schematic diagram of the federated insight chain architecture according to Embodiment 1 of the present invention;

[0029] Figure 4 This is a schematic diagram of an optional transaction risk identification device based on a trusted environment according to an embodiment of the present invention;

[0030] Figure 5 This is a structural block diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] It should be noted that all relevant information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) collected and involved in this invention are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data comply with the relevant laws, regulations, and standards of the relevant regions, necessary confidentiality measures have been taken, and it does not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, this system has an interface with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface. The relevant information is obtained only after receiving consent from the aforementioned user or organization. If the user chooses to refuse, the process proceeds to an expert decision-making process.

[0034] In this invention, against the backdrop of the high integration of digital finance and communication services, device-level risk behaviors (such as risky behavior and account theft) exhibit cross-institutional collaborative characteristics. The data silos of individual institutions lead to delays in risk identification, while directly sharing raw data faces privacy compliance pressures. Therefore, this invention can unite different institutions to construct a device-based federated insight chain. The federated insight chain uses TEE technology to build a trusted middleware layer, enabling institutions to exchange only anonymized device behavior tags, achieving collaborative risk insight rather than the transfer of the data itself. This allows the insight chain to store non-sensitive information, authorizing institutions to share insight chain information, thereby breaking down the data silos built by individual institutions and enabling the entire institution to jointly identify transaction risks.

[0035] In this invention, the Federated Insight Chain is a secure data sharing architecture based on a TEE (Technical Equipment Exchange) that enables secure interaction for cross-institutional device behavior insights. This architecture constructs a standardized TEE access layer, allowing authorized institutions such as operators and financial institutions to exchange device behavior tags (such as abnormal call records and transaction anomalies) in a strictly isolated environment, thereby forming a joint transaction risk identification capability. It leverages the hardware-level security isolation characteristics of the TEE to ensure data is "usable but not visible," and achieves collaborative defense for risk warnings through a chain-like propagation mechanism.

[0036] The present invention will now be described in detail with reference to various embodiments.

[0037] Example 1

[0038] According to an embodiment of this application, an embodiment of a transaction risk identification method based on a trusted environment is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0039] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a transaction risk identification method based on a trusted environment is shown. Figure 1 As shown, computer terminal 10 (or mobile device) may include one or more ( Figure 1 The processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions may also be included. In addition, it may include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera, wherein the network interface can be connected to wired and / or wireless networks. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0040] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0041] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the trusted environment-based transaction risk identification method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned trusted environment-based transaction risk identification method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0042] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0043] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0044] Under the aforementioned operating environment, this application provides the following: Figure 2 The method for identifying transaction risks based on a trusted environment is shown. Figure 2 This is a flowchart of a transaction risk identification method based on a trusted environment according to Embodiment 1 of the present invention, as shown below. Figure 2 As shown, the method includes the following steps:

[0045] Step S201: When it is detected that a customer has launched a preset financial application to conduct a transaction, the target device for executing the transaction is determined. The target device has a pre-built trusted environment, which stores device behavior tags written by different authorized institutions. The device behavior tags are tags generated based on non-sensitive data.

[0046] In this embodiment of the invention, when a customer initiates a preset financial application to conduct a transaction, such as a transfer or payment, the target device for executing the transaction can be determined first. Here, each device is pre-installed with the components required for the Federated Insight Chain architecture at the factory, giving it the ability to build a Trusted Environment (TEE). The Trusted Environment can store device behavior tags written by different authorized institutions. These tags are standardized, anonymized records of device behavior written into the TEE by the authorized institutions (such as operators and banks), for example, abnormal calls or access to abnormal links, used for risk identification. These tags are stored in the form of an encrypted structure, encrypted using a key derived from the device hardware key and the TA identity key, ensuring data security and privacy.

[0047] Step S202: Call the preset client interface of the target device. The preset client interface is a unified interface built for devices from different manufacturers.

[0048] In this embodiment of the invention, communication with the TA within the TEE is achieved by calling the CA interface (preset client interface) of the target device. Here, CA is a unified interface built for devices from different manufacturers. CA encapsulates the differences in TEE calls from different device manufacturers and provides a standardized interface to adapt to the TEE implementations of different device manufacturers.

[0049] Step S203: Using a preset client interface, read all device behavior tags from the trusted environment of the target device.

[0050] In this embodiment of the invention, after the CA is invoked, the CA communicates with the TA in the TEE through the Secure Monitor Call (SMC) instruction to read all stored device behavior tags, thereby obtaining all relevant device behavior information.

[0051] Step S204: Based on the behavioral tags of all devices, risk identification is performed on the transaction.

[0052] In this embodiment of the invention, after obtaining the device behavior tags of an institution, a risk assessment model can be applied, such as checking for abnormal call records and large-amount transfers within a short period of time, to determine whether the transaction is abnormal. This model is a local model customized by the institution according to its own needs. By analyzing the tags, it can respond quickly and take corresponding security measures, such as restricting transactions and requiring secondary verification.

[0053] Through the steps described above, the Federated Insight Chain architecture ensures that different institutions can collaborate during transactions, leveraging their respective data advantages to jointly identify and mitigate transaction risks without directly sharing raw data. This protects user privacy while improving the efficiency and accuracy of transaction risk identification.

[0054] In summary, by adopting a TEE-based technical architecture and constructing standardized Trusted Application (TA) and Client Application (CA) interfaces (i.e., pre-defined client interfaces), the goal of securely sharing device behavior tags across institutions is achieved. This enables real-time risk identification and early warning for transactions, thereby solving the problem of difficulty in identifying transaction risks due to data silos and privacy concerns. Specifically, when a customer initiates a transaction using a pre-defined financial application, the target device for the transaction can be identified and its TEE accessed. A unified interface is used to call the TA within the TEE to read the stored non-sensitive device behavior information (i.e., device behavior tags). Then, risk assessment strategies are executed based on these tags, effectively improving the efficiency and accuracy of transaction risk identification while ensuring user privacy.

[0055] To improve the accuracy of constructing the federated insight chain, in the transaction risk identification method based on a trusted environment provided in Embodiment 1 of this application, a federated insight chain is constructed before determining the target device executing the transaction when a customer initiates a pre-set financial application to conduct a transaction. The federated insight chain includes at least: a device hardware layer, a device-side trusted layer, a management institution layer, and an institution application layer. The federated insight chain is used to store non-sensitive data and share the non-sensitive data with all authorized institutions. The non-sensitive data consists of device behavior tags generated by each authorized institution based on abnormal events.

[0056] In this embodiment of the invention, a federated insight chain can be constructed to achieve secure interaction for cross-agency device behavior insights. This federated insight chain can achieve minimal data exposure, meaning the TEE does not store sensitive data; cross-vendor compatibility, meaning it is achieved through a unified management organization adapting TEEs from different vendors; and low-latency interaction, meaning it utilizes the device's local TEE to avoid round trips to the cloud, with an insight response time of less than 10ms.

[0057] In this embodiment of the invention, the Federated Insight Chain possesses security and privacy protection, as well as interoperability and standardization features. Security and privacy protection includes: hardware-isolated trust roots, i.e., relying on the Secure World to isolate sensitive data, while the Normal World can only access restricted interfaces through Secure Calls (SMC); and least privilege access, i.e., each organization's TA can only read and write predefined data fields, and memory isolation mechanisms prevent out-of-bounds access. Interoperability and standardization include: GP API (Global Platform Application Programming Interface) compatibility: using the TEE internal API defined by the Global Platform (such as TEEC_InvokeCommand) to ensure cross-device consistency; and layered abstraction design: management organizations encapsulate vendor differences and provide a unified API for organizational business systems to call.

[0058] In this embodiment of the invention, the Federated Insight Chain can only be accessed by authorized institutions, and third-party institutions cannot access it. Furthermore, third-party institutions cannot obtain the data stored in the Federated Insight Chain through attacks.

[0059] In this embodiment of the invention, the Federated Insight Chain adopts a four-layer architecture, including: a device hardware layer, a device-side trust layer, a management layer, and an organization application layer. The device hardware layer provides the TEE foundation, the device-side trust layer runs multiple TAs, the management layer integrates vendor interfaces, and the organization application layer accesses via standard APIs. This Federated Insight Chain is used to store non-sensitive data and share it with all authorized organizations. Here, the non-sensitive data consists of device behavior tags generated by each authorized organization based on abnormal events.

[0060] Figure 3 This is a schematic diagram of the federated insight chain architecture according to Embodiment 1 of the present invention, as shown below. Figure 3As shown, the system comprises: a device-side TEE layer, a device hardware layer, a management layer, and an institution application layer. The device hardware layer deploys a TEE hardware environment. The device-side TEE layer has an Insight Chain time-series storage area, divided into different blocks (e.g., block 1, block 2, block 3, ..., block N). Each block stores non-sensitive data for the corresponding institution. For example, block 1 stores data from telecom operators (e.g., overseas calls); block 2 stores data from banks (e.g., large-amount transfer attempts); and block 3 stores data from e-commerce platforms (e.g., abnormal logins). The management layer has a unified TEE interface gateway (with certificate / auditing / routing functions). This gateway calls vendor adapters via standardized APIs and can fulfill requests from different institutions (i.e., write / read Insight Chain data requests, such as writing Insight Chain data to or reading Insight Chain data from a corresponding block) through SMC commands. The institution application layer includes multiple authorized institutions, such as telecom operators, banks, e-commerce platforms, insurance companies, and payment institutions. These institutions can write / read Insight Chain data by calling the TEE interface gateway.

[0061] In this embodiment, the construction and implementation of the Federated Insight Chain enables secure cross-agency sharing of non-sensitive data (device behavior tags), breaking down data silos. This not only enhances the ability to identify transaction risks but also ensures the privacy and security of user data. Through hardware isolation and data anonymization technologies, different agencies can collaboratively improve the accuracy and timeliness of risk identification without leaking sensitive information.

[0062] To improve the accuracy of constructing the device hardware layer and the device-side trusted layer, in the transaction risk identification method based on a trusted environment provided in Embodiment 1 of this application, before determining the target device for executing the transaction after detecting that a customer has launched a preset financial application to conduct a transaction, a trusted hardware environment is constructed, and a device hardware layer is constructed based on the trusted hardware environment. The device hardware layer is used to run trusted environments of devices manufactured by different manufacturers. Based on the device hardware layer, a device-side trusted layer is built, which runs in a trusted environment and is used to store multiple trusted blocks. Each trusted block includes device behavior tags written by the same authorized institution.

[0063] In this embodiment of the invention, ARM (Advanced RISC Machines, where RISC (Reduced Instruction Set Computer)) TrustZone (a hardware security technology that allows the creation of two independent secure worlds on the same processor) technology can be used to divide the CPU of the device into two independent execution environments: Secure World (a trusted hardware environment) and Normal World (an insecure world). As a hardware-level secure zone, Secure World interacts with Normal World only through the Secure Call (SMC) mechanism, ensuring that data and operations within Secure World are not accessed or interfered with by risky software or root attacks running in Normal World.

[0064] Based on the established trusted hardware environment, a device hardware layer is further built. This layer not only includes the hardware infrastructure supporting ARM TrustZone technology but also involves compatibility design for TEE implementations from different device manufacturers. In this way, the device hardware layer can support devices from different manufacturers, ensuring the architecture's broad applicability and cross-platform compatibility.

[0065] A device-side trusted layer runs on the Secure World provided by the device hardware layer. This layer contains multiple trusted blocks, each managed by an independent trusted application (TA) responsible for storing device behavior tags written by the same authorized institution. For example, a bank's TA stores abnormal behavior related to financial transactions, while a telecom operator's TA records tags such as abnormal calls. These TAs can use encryption algorithms to encrypt and store data using keys derived from the device hardware key and the TA's identity key, ensuring data security and privacy.

[0066] In this embodiment, by constructing a trusted environment at the device hardware layer and then building a trusted layer on the device side within that trusted environment, the Federated Insight Chain achieves secure storage and efficient management of device behavior tags. This overcomes the data silo problem, allowing authorized institutions to share non-sensitive device behavior data without disclosing sensitive information, enhancing collaborative defense capabilities among financial institutions, and improving the industry's ability to detect and respond to risky behaviors. Simultaneously, by utilizing hardware-level security isolation and data encryption technologies, user privacy and data security are guaranteed, achieving a dual improvement in security and efficiency.

[0067] To improve the accuracy of constructing the management layer and the application layer, in the transaction risk identification method based on a trusted environment provided in Embodiment 1 of this application, before determining the target device for executing the transaction after detecting that a customer has launched a preset financial application to conduct a transaction, the trusted call interfaces of different manufacturers are encapsulated to obtain a preset client interface, wherein the trusted call interface is used to call the trusted environment; based on the preset client interface, the management layer is constructed; based on the management layer, an authorization certificate is issued to the institution, and the institution with the authorization certificate is determined as the authorized institution; the authorized institution is added to the application layer.

[0068] In this embodiment of the invention, a generic TEEOperator interface is constructed. This interface includes, but is not limited to, methods such as invokeCommand() and verifyTA(), encapsulating the differences in TEE calls from different vendors to obtain a preset client interface CA. For different TEE implementations, adapter classes are created. These adapters are responsible for translating the generic interface into specific calls for the corresponding TEE. A dynamic loading mechanism is developed to automatically select and load the appropriate adapter class at runtime based on the device's hardware information. Then, based on the preset client interface, a management layer is constructed. In the federated insight chain architecture, this management layer is not only responsible for certificate management but also implements traffic routing, providing a bridge for secure communication between the agency-side and device-side TEEs.

[0069] In this embodiment of the invention, a digital certificate is issued to each organization applying to join the Federated Insight Chain, based on the management layer. The root key of the certificate chain must be securely stored in a hardware security module to ensure the security and authority of the certificate. When an organization submits an application to join the Federated Insight Chain, the management layer can verify its legitimacy and then issue an authorization certificate to it through the certificate management submodule of the TEE interface gateway. For example, when an organization first connects to the Federated Insight Chain, it must go through the authentication process provided by the management layer. This process includes submitting its public key, organization information, and business scope, as well as accepting remote certificate verification from the management layer. If the organization passes the authorization verification, it can obtain a unified interface document. Based on these documents, the organization can develop or modify its business system to securely interact with the TEE through a preset client interface.

[0070] In some optional embodiments, the data access behavior of all participating institutions in the Federated Insight Chain will be recorded in the TEE logs. These logs are anonymized, retaining only the necessary behavioral records for subsequent security audits and anomaly detection.

[0071] In this embodiment, by implementing strict identity verification and certificate management for institutions accessing the Federated Insight Chain, and by providing a unified, standardized interface, the security and interoperability of cross-institutional data sharing are improved. This not only overcomes the problems caused by data silos but also reduces the complexity and time cost required for institutions to establish trust relationships and achieve data interaction. By ensuring that only authorized institutions can join the institutional application layer, data within the Federated Insight Chain is further protected from unauthorized access and potential risky behaviors, enhancing the robustness and reliability of the entire system.

[0072] To improve the accuracy of constructing trusted blocks for each authorized institution, in the transaction risk identification method based on a trusted environment provided in Embodiment 1 of this application, after constructing the federated insight chain, when an abnormal event is detected at the authorized institution's end, a device behavior tag is generated; a preset client interface of the abnormal device executing the abnormal event is called; using the preset client interface, a secure call instruction is called, and the device behavior tag is written to the target trusted block in the trusted environment of the abnormal device through the secure call instruction, wherein the target trusted block is a trusted block associated with the authorized institution's end.

[0073] In this embodiment of the invention, when an authorized agency (e.g., an operator) detects a matching abnormal event (abnormal call), it automatically generates a device behavior tag. This tag contains basic information about the event, such as the event type and timestamp, but does not contain sensitive user information. Here, an abnormal event refers to a series of abnormal events defined in the agency's business system that may indicate risky behavior, such as multiple consecutive failed login attempts or large-scale fund transfers within a short period of time.

[0074] Then, the business system on the authorizing agency side initiates a request to write a behavior tag to the abnormal device by calling a pre-configured preset client interface (CA). This interface has encapsulated the TEE's calling logic, so the business system does not need to care about the specific details. The preset client interface further calls a secure calling instruction (such as the SMC instruction), which is a privileged instruction used to enter the secure world (TEE) from the insecure world (REE) to perform operations. SMC ensures the security and isolation of the write operation. Through the SMC instruction, the device behavior tag is written to the target trusted block in the abnormal device's TEE. The target trusted block is a secure area specifically used to store device behavior information related to the authorizing agency, managed by the trusted application (TA) on the authorizing agency side. During the write process, the data is first encrypted to ensure that even if the TEE is physically attacked, the data is difficult to decipher.

[0075] In this embodiment, the authorized agency can respond promptly to detected abnormal events, generating and securely writing device behavior tags into the target trusted block of the TEE (Trusted Execution Environment) of the abnormal device. This mechanism enables real-time risk information sharing across agencies, enhancing the risk identification capabilities of the entire industry. Simultaneously, through data anonymization and hardware-level encryption, it protects user privacy and complies with data protection regulations. Furthermore, the use of a pre-defined client interface simplifies the communication process between the agency and the TEE, reduces development and maintenance costs, and promotes secure collaboration between different agencies.

[0076] To improve the accuracy of determining device behavior tags, in the transaction risk identification method based on a trusted environment provided in Embodiment 1 of this application, abnormal events are analyzed to determine the event timestamp, event type, and event information of the abnormal event; an initial device behavior tag is generated based on the institution identifier, event timestamp, event type, and event information of the authorized institution; and the initial device behavior tag is encrypted based on a preset private key to obtain the device behavior tag, wherein each preset private key corresponds to a preset public key, and each authorized institution stores the preset public key.

[0077] In this embodiment of the invention, when the risk control system of the authorized institution (such as a bank or telecommunications operator) detects an abnormal event, it first needs to analyze the event and extract key information. This includes determining the exact timestamp of the event, the type of the event (such as receiving an abnormal call, frequent account login attempts within a short period of time, etc.), and the detailed information of the event (the specific content or context of the event, such as non-sensitive information such as call duration and transfer amount).

[0078] Then, based on the authorized agency's identifier, the event's timestamp, event type, and event information, an initial device behavior tag is generated. This tag is a structured data packet containing all the necessary information about the abnormal event, but it has undergone appropriate anonymization to avoid including any information that could directly or indirectly identify the user. Furthermore, to ensure the security of the initial device behavior tag during transmission, the authorized agency encrypts the tag using its corresponding preset private key, generating an encrypted device behavior tag. This encryption utilizes the principle of asymmetric encryption, whereby each authorized agency possesses a private key and a paired public key. The private key is used for encryption, while the public key is stored at each authorized agency for decryption.

[0079] In this embodiment, a standardized event parsing and tag generation mechanism ensures the effective identification and communication of abnormal event information. Encryption of device behavior tags further enhances data security; even if the tag is intercepted during network transmission or within the TEE, its content cannot be deciphered without the correct pre-defined public key. This process strengthens the data security and privacy protection of the Federated Insight Chain architecture, while also promoting efficient communication and collaboration among authorized agencies based on standardized behavior records, jointly building a more intelligent cross-agency risk identification system. The use of asymmetric encryption ensures data confidentiality while maintaining data integrity, as the decryption process verifies whether the data has been tampered with. This allows device behavior tags to be securely stored and processed within the TEE without being leaked to the external insecure world or unauthorized third parties, thereby reducing the risk of data leakage.

[0080] To improve the accuracy of risk identification for transactions, the transaction risk identification method based on a trusted environment provided in Embodiment 1 of this application determines the transaction type and, based on the transaction type, determines a target risk identification model; the target risk identification model is used to identify all device behavior tags and transaction information to obtain a risk score; if the risk score is greater than a preset threshold, it is determined that the transaction has a risk and the execution of the transaction is suspended.

[0081] In this embodiment of the invention, the risk control system of the institution (e.g., a bank) needs to determine the specific type of transaction. Transaction types can be varied, such as transfers, payments, large transactions, cross-border transactions, etc., and different types of transactions are associated with different risk identification models. Based on the transaction type, the most suitable model is selected as the target risk identification model from a pre-set risk identification model library. For example, for cross-border transactions, a model containing cross-border risk characteristics might be used.

[0082] Before calculating the risk score, all device behavior tags related to the transaction must be collected. These tags are generated by participating institutions in the Federated Insight Chain and stored in the device's TEE (Technical Equipment Environment), covering multi-dimensional risk information such as device usage habits and abnormal behavior. Then, a target risk identification model is used to identify the collected device behavior tags and detailed transaction information, including data preprocessing, model parameter calls, and complex risk analysis algorithms. Finally, the model outputs a quantitative indicator representing the degree of transaction risk, namely the risk score. The calculated risk score is then compared with a preset threshold. If the risk score is higher than the threshold, it indicates that the transaction carries a high risk.

[0083] If the risk score exceeds a preset threshold, the institution will immediately mark the transaction as suspended to prevent any further execution. Simultaneously, it will trigger a subsequent risk investigation process or notify the user to undergo additional authentication.

[0084] In this embodiment, the Federated Insight Chain architecture can respond to and assess transaction risks in real time, providing a comprehensive risk view through the joint analysis of device behavior tags and transaction information. Selectively using risk identification models that match transaction types improves the accuracy and efficiency of risk identification. Once a high-risk transaction is identified, execution is immediately suspended, effectively preventing potential risky behavior and protecting users' funds.

[0085] The transaction risk identification method based on a trusted environment provided in this application adopts a TEE-based technical architecture. By constructing standardized trusted application (TA) and client application (CA) interfaces (i.e., preset client interfaces), it achieves the goal of securely sharing device behavior tags across institutions, thereby realizing the technical effect of real-time risk identification and early warning for transactions. This solves the problem of difficulty in transaction risk identification caused by data silos and privacy concerns. Specifically, when a customer launches a preset financial application to conduct a transaction, the target device for executing the transaction can be identified and its TEE accessed. A unified interface is used to call the TA within the TEE to read the stored non-sensitive device behavior information (i.e., device behavior tags). Then, a risk assessment strategy is executed based on these tags, effectively improving the efficiency and accuracy of transaction risk identification while ensuring the security of user privacy.

[0086] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0087] Example 2

[0088] This application also provides a transaction risk identification device based on a trusted environment. It should be noted that this trusted environment-based transaction risk identification device can be used to execute the trusted environment-based transaction risk identification method provided in this application. The trusted environment-based transaction risk identification device provided in this application will be described below.

[0089] According to an embodiment of this application, an apparatus for implementing the above-described transaction risk identification method based on a trusted environment is also provided. Figure 4 This is a schematic diagram of an optional transaction risk identification device based on a trusted environment according to an embodiment of the present invention, such as... Figure 4 As shown, the transaction risk identification device may include: a determination unit 40, a calling unit 41, a reading unit 42, and an identification unit 43.

[0090] The determining unit 40 is used to determine the target device for executing the transaction when it is detected that a customer has launched a preset financial application to conduct a transaction. The target device has a pre-built trusted environment, which stores device behavior tags written by different authorized institutions. The device behavior tags are generated based on non-sensitive data.

[0091] Calling unit 41 is used to call the preset client interface of the target device, wherein the preset client interface is a unified interface built for devices from different manufacturers;

[0092] Reading unit 42 is used to read all device behavior tags from the trusted environment of the target device using a preset client interface;

[0093] The identification unit 43 is used to identify risks in transactions based on behavioral tags of all devices.

[0094] The transaction risk identification device based on a trusted environment provided in this application adopts a TEE-based technical architecture. By constructing standardized trusted application (TA) and client application (CA) interfaces (i.e., preset client interfaces), it achieves the goal of securely sharing device behavior tags across institutions, thereby realizing the technical effect of real-time risk identification and early warning for transactions. This solves the problem of difficulty in transaction risk identification caused by data silos and privacy concerns. Specifically, when a customer launches a preset financial application to conduct a transaction, the target device for executing the transaction can be identified and its TEE accessed. A unified interface is used to call the TA within the TEE to read the stored non-sensitive device behavior information (i.e., device behavior tags). Then, a risk assessment strategy is executed based on these tags, effectively improving the efficiency and accuracy of transaction risk identification while ensuring the security of user privacy.

[0095] Optionally, the first building module for the transaction risk identification device further includes: before determining the target device for executing the transaction when a customer initiates a pre-set financial application to conduct a transaction, constructing a federated insight chain, wherein the federated insight chain includes at least: a device hardware layer, a device-side trust layer, a management institution layer, and an institution application layer; the federated insight chain is used to store non-sensitive data and share the non-sensitive data with all authorized institutions; the non-sensitive data is a device behavior tag generated by each authorized institution based on abnormal events.

[0096] Optionally, the transaction risk identification device further includes: a second construction module, used to construct a trusted hardware environment before determining the target device for executing the transaction when a customer initiates a preset financial application to conduct a transaction, and to construct a device hardware layer based on the trusted hardware environment, wherein the device hardware layer is used to run trusted environments of devices manufactured by different manufacturers; and a first construction module, used to construct a device-side trusted layer based on the device hardware layer, wherein the device-side trusted layer runs in a trusted environment and is used to store multiple trusted blocks, each trusted block including device behavior tags written by the same authorized institution.

[0097] Optionally, the transaction risk identification device further includes: a first encapsulation module, used to encapsulate trusted call interfaces from different vendors to obtain a preset client interface before determining the target device for executing the transaction when a customer initiates a preset financial application to conduct a transaction, wherein the trusted call interface is used to call a trusted environment; a third construction module, used to construct a management institution layer based on the preset client interface; a first issuance module, used to issue authorization certificates to the institution based on the management institution layer, and determine the institution with the authorization certificate as the authorized institution; and a first joining module, used to join the authorized institution to the institution application layer.

[0098] Optionally, the transaction risk identification device further includes: a first generation module, used to generate a device behavior tag after the federated insight chain is built and an abnormal event is detected at the authorized institution; a first invocation module, used to invoke a preset client interface of the abnormal device that executes the abnormal event; and a second invocation module, used to invoke a secure invocation instruction using the preset client interface, and write the device behavior tag to a target trusted block in the trusted environment of the abnormal device through the secure invocation instruction, wherein the target trusted block is a trusted block associated with the authorized institution.

[0099] Optionally, the first generation module includes: a first parsing submodule, used to parse the abnormal event and determine the event timestamp, event type, and event information of the abnormal event; a first generation submodule, used to generate an initial device behavior tag based on the institution identifier, event timestamp, event type, and event information of the authorized institution; and a first encryption submodule, used to encrypt the initial device behavior tag based on a preset private key to obtain a device behavior tag, wherein each preset private key corresponds to a preset public key, and each authorized institution stores a preset public key.

[0100] Optionally, the identification unit includes: a first determining module, used to determine the transaction type of the transaction and, based on the transaction type, determine a target risk identification model; a first identification module, used to identify all device behavior tags and transaction information of the transaction using the target risk identification model to obtain a risk score; and a second determining module, used to determine that the transaction has a risk and suspend the execution of the transaction if the risk score is greater than a preset threshold.

[0101] The aforementioned transaction risk identification device may also include a processor and a memory. The aforementioned determining unit 40, calling unit 41, reading unit 42, identification unit 43, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0102] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and by adjusting kernel parameters, risk identification can be performed on transactions based on behavioral tags from all devices.

[0103] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0104] It should be noted that the aforementioned determining unit 40, calling unit 41, reading unit 42, and identifying unit 43 correspond to steps S201 to S204 in Embodiment 1. The instances and application scenarios implemented by these units and their corresponding steps are the same, but they are not limited to the content disclosed in Embodiment 1. It should be noted that the aforementioned units may be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The aforementioned units may also be part of a device and may run in the computer terminal 10 provided in Embodiment 1.

[0105] Example 3

[0106] Embodiments of this application may provide an electronic device. Figure 5 This is a structural block diagram of an electronic device according to an embodiment of the present invention. Figure 5 As shown, the electronic device may include: one or more ( Figure 5 (Only one is shown) processor 502, memory 504, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0107] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the trusted environment-based transaction risk identification method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned trusted environment-based transaction risk identification method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0108] The processor can access information and applications stored in memory via a transmission device to perform the following steps: upon detecting that a customer has initiated a pre-set financial application for trading, the processor determines the target device for the transaction, wherein the target device has a pre-built trusted environment that stores device behavior tags written by different authorized institutions, wherein the device behavior tags are tags generated based on non-sensitive data; the processor calls the target device's pre-set client interface, wherein the pre-set client interface is a unified interface built for devices from different manufacturers; the processor uses the pre-set client interface to read all device behavior tags from the target device's trusted environment; and the processor performs risk identification on the transaction based on all device behavior tags.

[0109] The processor can access information and applications stored in memory via a transmission device to perform the following steps: constructing a federated insight chain, wherein the federated insight chain includes at least: a device hardware layer, a device-side trust layer, a management agency layer, and an agency application layer; the federated insight chain is used to store non-sensitive data and share non-sensitive data with all authorized agencies; the non-sensitive data is a device behavior tag generated by each authorized agency based on abnormal events.

[0110] The processor can access information and applications stored in memory via a transmission device to perform the following steps: construct a trusted hardware environment, and based on the trusted hardware environment, construct a device hardware layer, wherein the device hardware layer is used to run trusted environments for devices manufactured by different manufacturers; based on the device hardware layer, construct a device-side trusted layer, wherein the device-side trusted layer runs in a trusted environment and is used to store multiple trusted blocks, each trusted block including device behavior tags written by the same authorized agency.

[0111] The processor can access information and applications stored in memory via a transmission device to perform the following steps: encapsulate trusted calling interfaces from different vendors to obtain a preset client interface, wherein the trusted calling interface is used to call a trusted environment; build a management layer based on the preset client interface; issue authorization certificates to the management layer and identify the management layer with the authorization certificate as the authorized management layer; add the authorized management layer to the management application layer.

[0112] The processor can access information and applications stored in memory via a transmission device to perform the following steps: generating a device behavior tag when an abnormal event is detected at the authorization authority; calling the preset client interface of the abnormal device that executed the abnormal event; using the preset client interface to call a security call instruction, and writing the device behavior tag to the target trusted block in the trusted environment of the abnormal device through the security call instruction, wherein the target trusted block is a trusted block associated with the authorization authority.

[0113] The processor can access information and applications stored in the memory via the transmission device to perform the following steps: parse the abnormal event to determine the event timestamp, event type, and event information of the abnormal event; generate an initial device behavior tag based on the institution identifier, event timestamp, event type, and event information of the authorized institution; encrypt the initial device behavior tag based on a preset private key to obtain a device behavior tag, wherein each preset private key corresponds to a preset public key, and each authorized institution stores a preset public key.

[0114] The processor can access the information and application programs stored in the memory via the transmission device to perform the following steps: determine the transaction type of the transaction, and determine the target risk identification model based on the transaction type; use the target risk identification model to identify all device behavior tags and transaction information to obtain a risk score; if the risk score is greater than a preset threshold, determine that the transaction has a risk and suspend the execution of the transaction.

[0115] This application provides a scheme for transaction risk identification based on a trusted environment. Employing a TEE-based technical architecture, it achieves secure sharing of device behavior tags across institutions by constructing standardized Trusted Application (TA) and Client Application (CA) interfaces (i.e., pre-defined client interfaces). This enables real-time risk identification and early warning for transactions, thus solving the problem of difficulty in transaction risk identification caused by data silos and privacy concerns. Specifically, when a customer initiates a transaction using a pre-defined financial application, the target device executing the transaction can be identified and its TEE accessed. A unified interface is used to call the TA within the TEE to read stored non-sensitive device behavior information (i.e., device behavior tags). Risk assessment strategies are then executed based on these tags, effectively improving the efficiency and accuracy of transaction risk identification while ensuring user privacy.

[0116] Those skilled in the art will understand that Figure 5 The structure shown is for illustrative purposes only. Electronic devices can also be terminal devices such as smartphones, tablets, PDAs, and mobile internet devices (MIDs). Figure 5 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 5 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 5 The different configurations shown.

[0117] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0118] Example 4

[0119] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the trusted environment-based transaction risk identification method provided in Embodiment 1.

[0120] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0121] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing steps of a transaction risk identification method based on a trusted environment.

[0122] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0123] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0124] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0125] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0126] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0127] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0128] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for identifying transaction risks based on a trusted environment, characterized in that, include: When it is detected that a customer has launched a preset financial application to conduct a transaction, the target device for executing the transaction is determined. The target device has a pre-built trusted environment, which stores device behavior tags written by different authorized institutions. The device behavior tags are generated based on non-sensitive data. Call the preset client interface of the target device, wherein the preset client interface is a unified interface built for devices from different manufacturers; Using the preset client interface, all device behavior tags are read from the trusted environment of the target device; Risk identification is performed on the transaction based on all the aforementioned device behavior tags.

2. The transaction risk identification method according to claim 1, characterized in that, Before determining the target device to execute the transaction, in the event that a customer has initiated a pre-set financial application to conduct a transaction, the process further includes: A federated insight chain is constructed, comprising at least: a device hardware layer, a device-side trust layer, a management agency layer, and an agency application layer; the federated insight chain is used to store non-sensitive data and share the non-sensitive data with all authorized agencies; the non-sensitive data is the device behavior tag generated by each authorized agency based on anomaly events.

3. The transaction risk identification method according to claim 2, characterized in that, Before determining the target device to execute the transaction, in the event that a customer has initiated a pre-set financial application to conduct a transaction, the process further includes: A trusted hardware environment is constructed, and based on the trusted hardware environment, the device hardware layer is constructed, wherein the device hardware layer is used to run the trusted environment of devices manufactured by different manufacturers; Based on the device hardware layer, a device-side trusted layer is built, wherein the device-side trusted layer runs in the trusted environment and is used to store multiple trusted blocks, each of the trusted blocks including the device behavior tag written by the same authorized agency.

4. The transaction risk identification method according to claim 2, characterized in that, Before determining the target device to execute the transaction, in the event that a customer has initiated a pre-set financial application to conduct a transaction, the process further includes: The trusted calling interfaces of different vendors are encapsulated to obtain the preset client interface, wherein the trusted calling interface is used to call the trusted environment; The management organization layer is constructed based on the preset client interface; Based on the management layer, an authorization certificate is issued to the institution, and the institution with the authorization certificate is identified as the authorized institution. Add the authorized agency to the agency's application layer.

5. The transaction risk identification method according to claim 2, characterized in that, Following the construction of the federated insight chain, the following is also included: If the abnormal event is detected at the authorized agency, the device behavior tag is generated; Invoke the preset client interface of the abnormal device that executes the abnormal event; Using the preset client interface, a secure call instruction is invoked, and the device behavior tag is written to the target trusted block in the trusted environment of the abnormal device through the secure call instruction. The target trusted block is a trusted block associated with the authorized agency.

6. The transaction risk identification method according to claim 5, characterized in that, The step of generating the device behavior tag when the abnormal event is detected at the authorized agency includes: The abnormal event is analyzed to determine the event timestamp, event type, and event information of the abnormal event; Based on the organization identifier of the authorized organization, the event timestamp, the event type, and the event information, an initial device behavior tag is generated; Based on a preset private key, the initial device behavior tag is encrypted to obtain the device behavior tag, wherein each preset private key corresponds to a preset public key, and each authorized agency stores the preset public key.

7. The transaction risk identification method according to claim 1, characterized in that, The steps for risk identification of the transaction based on all the aforementioned device behavior tags include: Determine the transaction type of the transaction, and based on the transaction type, determine the target risk identification model; The target risk identification model is used to identify all device behavior tags and transaction information to obtain a risk score; If the risk score is greater than a preset threshold, the transaction is determined to be risky, and the execution of the transaction is suspended.

8. A transaction risk identification device based on a trusted environment, characterized in that, include: The determining unit is used to determine the target device for executing the transaction when it is detected that a customer has launched a preset financial application to conduct a transaction. The target device has a pre-built trusted environment, and the trusted environment stores device behavior tags written by different authorized institutions. The device behavior tags are generated based on non-sensitive data. The calling unit is used to call the preset client interface of the target device, wherein the preset client interface is a unified interface built for devices from different manufacturers; The reading unit is used to read all the device behavior tags from the trusted environment of the target device using the preset client interface; An identification unit is used to identify risks in the transaction based on all the device behavior tags.

9. A computer program product, characterized in that, The method includes a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the transaction risk identification method based on any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the transaction risk identification method based on any one of claims 1 to 7.

Images