Mobile phone shield access record storage and alarm method and computer system

Abstract

The present application provides a computer system, which includes a terminal device and a server. A TEE trusted execution environment, a REE rich execution environment, and a mobile phone shield are deployed on the terminal device. A TA trusted application is deployed on the TEE, and a CA client application is deployed on the REE. The CA sends an access request for the mobile phone shield to the TA and sends the access request to the server; the TA sends all received access requests for the mobile phone shield to the server; the server compares the access requests sent by the TA with the access requests sent by the CA, and determines whether a malicious CA initiates an access request to the mobile phone shield; if it is determined that a malicious CA initiates an access request to the mobile phone shield, an alarm message is sent to the CA, prompting that a malicious CA has initiated access to the mobile phone shield.

Description

Technical Field

[0001] The present application relates to the field of computers, and more particularly to payment security. Background Art

[0002] Mobile payments are now commonplace. When users need to use their mobile phones to perform financial payment operations that require a higher level of security, such as large-amount transfers, they need to connect their mobile phones to USB keys to ensure payment security.

[0003] Mobile phone shield means that the U shield function is built into the mobile phone, so as to realize the financial payment function with a higher security level on the mobile terminal. For mobile phones with built-in mobile phone shield, there are three independent operating system running environments with different security levels, such as Figure 1 As shown in the figure, there are three independent operating system operating environments: rich execution environment (REE), trusted execution environment (TEE), and inside secure element (inSE). REE (e.g., Android system) runs client applications (CA) with low security requirements, such as third-party payment applications such as banking applications; TEE runs trusted applications (TA) whose security needs to be guaranteed, such as applications that perform critical services such as signing, encryption, and decryption calculations. TEE provides a secure execution environment for authorized trusted applications TA. The memory space of TEE is isolated from the memory space of REE. inSE refers to the built-in USB shield of the mobile phone, also known as mobile shield.

[0004] For security reasons, client applications (CAs) cannot directly access inSE, but can access it indirectly through the TEE. Within the TEE, trusted applications (TAs) provide interfaces for client CAs to access. These trusted applications can access the inSE interface and use the key stored in the USB key to sign transactions, thereby completing the transaction. Currently, trusted applications (TAs) cannot effectively distinguish legitimate access requests from the REE. Therefore, while malicious applications cannot steal the keys in inSE, a malicious CA can sign malicious transactions by calling the trusted application (TA) or, through sustained attacks, disable inSE. Summary of the Invention

[0005] This application provides a method and computer system for recording and recording access records and providing an alarm for a mobile phone shield, thereby improving the security of mobile phone shield access.

[0006] In a first aspect, the present application provides a computer system including a terminal device and a server, wherein a TEE trusted execution environment and a REE rich execution environment and a built-in security component (specifically the mobile shield inSE mentioned in the embodiment) are deployed on the terminal device, and the built-in security component is used to execute financial transactions according to the user key, the TEE is deployed with a TA trusted application, the REE is deployed with a CA client application, the CA is deployed with a first blockchain client module (for example, the blockchain client 1 mentioned in the embodiment), the TA is deployed with a second blockchain client module (for example, the blockchain client 2 mentioned in the embodiment), and the server is deployed with a smart contract unit.

[0007] The first blockchain client module is used to: send an access request for the built-in security component to the TA; send the access request to the server; the access request includes information about the CA;

[0008] The second blockchain client module is used to: send all received access requests to the built-in security component to the server;

[0009] The smart contract unit is used to: record all access requests to the built-in security component sent by the second blockchain client module and the access requests sent by the first blockchain client module in the blockchain stored on the server; compare the access requests received from the second blockchain client module with the access requests received from the first blockchain client module, and determine whether a malicious CA has initiated an access request to the built-in security component; if it is determined that a malicious CA has initiated an access request to the built-in security component, send an alarm message to the first blockchain client module, where the alarm message is used to prompt that a malicious CA has initiated access to the built-in security component.

[0010] Malicious CAs, like legitimate CAs, can also send access requests to the TE Connectivity Shield. Therefore, when a malicious CA exists in the REE, all access requests from the TE Connectivity Shield to the server will include requests from both legitimate and malicious CAs. However, only legitimate CAs can send access requests to the server through the blockchain client. This means that the access requests from the TEE stored in the server's blockchain can include requests from both legitimate and malicious CAs, while the access requests from the REE stored in the server's blockchain only include requests from legitimate CAs. Therefore, the server can compare the two stored evidence to determine the presence of a malicious CA and issue an alert to the legitimate CA. Furthermore, the blockchain's immutable nature ensures that the stored evidence cannot be tampered with, ensuring the accuracy of the alerts and enhancing the security of the TE Connectivity Shield.

[0011] In one implementation, the smart contract unit is further configured to: verify the legitimacy of the access request based on a legal list, and send a verification result to the TA; the verification result indicates whether the CA initiating the access request is malicious; the legal list stores information on multiple legal CAs;

[0012] The second blockchain client module is further configured to: receive the verification result from the smart contract unit; and reject the access request of the malicious CA when the verification result indicates that the CA that initiated the access request is malicious.

[0013] In one implementation, the second blockchain client module is further used to: send information about the malicious CA to the CA.

[0014] In a second aspect, the present application provides a terminal device, on which a TEE trusted execution environment and a REE rich execution environment and a built-in security component are deployed. The built-in security component is used to execute financial transactions based on user keys. The TEE is deployed with a TA trusted application, the REE is deployed with a CA client application, the CA is deployed with a first blockchain client module, and the TA is deployed with a second blockchain client module.

[0015] The first blockchain client module is configured to: send an access request for the built-in security component to the TA; send the access request to the server; the access request includes information about the CA; and the access request sent by the first blockchain client module to the server is stored in the blockchain by the server;

[0016] The second blockchain client module is configured to: send all received access requests to the built-in security component to the server; all access requests to the built-in security component sent by the second blockchain client module to the server are stored in the blockchain by the server;

[0017] The first blockchain client module is further used to: receive an alarm message sent by the server, where the alarm message is used to prompt that a malicious CA has initiated access to the built-in security component. The alarm message is sent to the CA after the server compares the access request sent by the second blockchain client module with the access request sent by the first blockchain client module and determines that a malicious CA has initiated an access request to the built-in security component.

[0018] In one implementation, the second blockchain client module is further configured to: receive the verification result from the server; when the verification result indicates that the CA initiating the access request is malicious, reject the access request of the malicious CA; the verification result is a result obtained by the server verifying the legitimacy of the access request based on a legal list; the verification result indicates whether the CA initiating the access request is malicious; and the legal list stores information on multiple legal CAs.

[0019] In one implementation, the CA receives the information of the malicious CA sent by the server.

[0020] In a third aspect, the present application provides a method for storing and alerting access records of a mobile phone shield, which is applied to a terminal device. The terminal device is deployed with a TEE trusted execution environment and a REE rich execution environment and a built-in security component. The built-in security component is used to execute financial transactions based on user keys. The TEE is deployed with a TA trusted application, the REE is deployed with a CA client application, the CA is deployed with a first blockchain client, and the TA is deployed with a second blockchain client. The method includes:

[0021] The CA sends an access request for the built-in security component to the TA; sends the access request to the server; the access request includes information about the CA; the access request sent by the CA to the server is stored in the blockchain by the server;

[0022] The TA sends all received access requests to the built-in security component to the server; all access requests to the built-in security component sent by the TA to the server are stored in the blockchain by the server;

[0023] The CA receives the warning information sent by the server, where the warning information is used to prompt that a malicious CA has initiated access to the built-in security component. The warning information is sent to the CA after the server compares the access request sent by the TA with the access request sent by the CA and determines that a malicious CA has initiated access to the built-in security component.

[0024] In one implementation, the smart contract unit is further configured to: verify the legitimacy of the access request based on a legal list, and send a verification result to the TA; the verification result indicates whether the CA initiating the access request is malicious; the legal list stores information on multiple legal CAs;

[0025] The second blockchain client module is further configured to: receive the verification result from the smart contract unit; and reject the access request of the malicious CA when the verification result indicates that the CA that initiated the access request is malicious.

[0026] In one implementation, the second blockchain client module is further used to: send information about the malicious CA to the CA.

[0027] In a fourth aspect, the present application provides a server, which is communicatively connected to a terminal device, on which a TEE trusted execution environment and a REE rich execution environment and a built-in security component are deployed, wherein the built-in security component is used to execute financial transactions based on user keys, the TEE is deployed with a TA trusted application, the REE is deployed with a CA client application, the CA is deployed with a first blockchain client, and the TA is deployed with a second blockchain client.

[0028] The server is used to:

[0029] Recording all access requests to the built-in security component sent by the TA and the access requests sent by the CA in the blockchain stored on the server;

[0030] Comparing the received access request sent by the TA with the received access request sent by the CA, and determining whether a malicious CA has initiated an access request to the built-in security component;

[0031] If it is determined that the malicious CA has initiated an access request to the built-in security component, an alarm message is sent to the CA, where the alarm message is used to prompt that a malicious CA has initiated access to the built-in security component.

[0032] In a fifth aspect, the present application provides a computer system comprising a terminal device and a server, wherein a TEE trusted execution environment and a REE rich execution environment and a built-in security component are deployed on the terminal device, a TA trusted application is deployed on the TEE, and a CA client application is deployed on the REE.

[0033] The CA is used to: send an access request to the TA for the built-in security component;

[0034] The TA is used to: send the received access request to the server;

[0035] The server is used to verify the legitimacy of the access request based on the legal list and send the verification result to the TA; the verification result indicates whether the CA initiating the access request is malicious; the legal list stores information on multiple legal CAs;

[0036] The TA is configured to: receive the verification result from the server; and reject the access request of the malicious CA when the verification result indicates that the CA that initiated the access request is malicious.

[0037] In one implementation, the TA is further configured to send information about the malicious CA to the CA.

[0038] In a sixth aspect, the present application provides a computer system comprising a memory and a processor, wherein:

[0039] The memory is used to store computer-readable instructions; the processor is used to read the computer-readable instructions and implement the method as described in the third aspect and any one of its implementation methods.

[0040] In a seventh aspect, the present application provides a computer storage medium storing computer-readable instructions, and the computer-readable instructions, when executed by a processor, implement the method described in the third aspect and any one of its implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 Schematic diagram of the terminal device payment environment provided in the embodiment of the present application;

[0042] Figure 2 A schematic diagram of the system architecture provided in an embodiment of the present application;

[0043] Figure 3 A schematic diagram of the blockchain system architecture provided in an embodiment of the present application;

[0044] Figure 4 A system architecture diagram of nodes of the blockchain system provided in an embodiment of the present application;

[0045] Figure 5 Schematic diagram of the blockchain-based mobile shield access record storage and alarm system provided in an embodiment of the present application;

[0046] Figure 6 A flowchart of the method for storing and alerting access records of mobile phone shields provided in an embodiment of the present application;

[0047] Figure 7 Schematic diagram of the blockchain-based mobile shield access record storage and alarm system provided in an embodiment of the present application;

[0048] Figure 8 A business logic diagram of the blockchain client 1 module provided in an embodiment of the present application;

[0049] Figure 9 A business logic diagram of the blockchain client 1 module provided in an embodiment of the present application;

[0050] Figure 10 A business logic diagram of the blockchain client 2 module provided in an embodiment of the present application;

[0051] Figure 11 A business logic diagram of the smart contract unit provided in an embodiment of the present application;

[0052] Figure 12 A schematic diagram of the structure of a computer system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0053] In order to ensure the security of terminal devices, ARM (advanced RISC machines) have emerged. The terminal equipment security framework represented by RISC (the full name of RISC is reduced instructionset computer). Under the framework, system-level security is achieved by dividing the software and hardware resources of the system on chips (SoC) into two worlds. These two worlds are the normal world and the secure world (also called the security domain and the non-security domain), which correspond to the rich execution environment (REE) and the trusted execution environment (TEE) respectively. REE and TEE run on the same physical device and run an operating system respectively. CA and TA communicate with each other through ARM The provided communication mechanism is like a client and server. REE can be an Android operating system or a Linux operating system.

[0054] like Figure 2As shown, a system architecture is provided, comprising a Trusted Execution Environment (TEE) and a Rich Execution Environment (REE). This system architecture can reside in electronic devices, specifically servers or terminal devices. The terminal devices can be mobile phones, tablets, laptops, desktops, or smart wearable devices. In this system architecture, highly security-sensitive applications are isolated from the general software environment, providing a dedicated Trusted Execution Environment (TEE) to protect the confidentiality, integrity, and access rights of application resources and data. A general Rich Execution Environment (REE) is also provided for traditional, vulnerable operating systems such as Android. The REE runs client applications (CA) with low security requirements, such as third-party payment applications like banking apps. The TEE runs trusted applications (TAs) requiring security assurance, such as those performing critical services like signing and encryption / decryption calculations. The TEE provides a secure execution environment for authorized trusted applications. Because TAs run in the TEE, their deployment and upgrade operations must strictly adhere to the security verification specifications of the TEE issuer (typically the terminal manufacturer), using measures such as digital signatures to ensure that every aspect of the TEE is truly trustworthy. The Trusted Execution Environment (TEE) includes the Trusted Execution Environment (TEE) internal application programming interface (API) and a trusted operating system component. The TEE Internal API primarily provides trusted operating system component functionality, communicates with client applications (CAs), enables inter-TA communication, and provides secure storage, cryptography, and time functions. The trusted operating system component primarily includes a trusted core framework, trusted functions, a trusted kernel, and a trusted execution environment (TEE) communication agent. The trusted core framework provides operating system-like functionality for the TA; trusted functions provide support for application developers; the trusted kernel interacts with trusted devices in the platform hardware; and the trusted execution environment (TEE) communication agent provides a secure communication channel between the TA and the CA. For example, the trusted execution environment (TEE) communication agent passes messages to the rich execution environment (RFE) communication agent through the platform hardware, enabling interaction between the two. When the CA initiates an access operation, the two parties exchange data through the RFE communication agent, the hardware-layer message channel, and the TEE communication agent. These three components establish a secure communication channel between the CA and the TA, ensuring a certain degree of data security.The Rich Execution Environment (REE) includes the Trusted Execution Environment Client Application Programming Interface (TEE Client API), the Trusted Execution Environment Functional Application Programming Interface (TEE Functional API), and a multimedia operating system. The multimedia operating system components mainly include public device drivers and a Rich Execution Environment communication agent. The Rich Execution Environment communication agent is used to communicate with the TEE, the CA and the TA provide a secure communication channel, and the public device driver is used to drive public devices in the platform hardware. The CA uses the TEE Client API and the TEE Functional API to access the security services provided by the TA. Taking mobile phones as an example, in financial payment scenarios, mobile phones need to be connected to USB keys to implement financial payment operations with a higher level of security, such as large-scale transfers. The mobile phone key can be built into the terminal device in the form of inSE, such as. Figure 1 Shown to ensure the security of financial payments.

[0055] Existing technologies improve the security of mobile shields by isolating access between REE and inSE using a Trusted Execution Environment (TEE). However, this technology cannot accurately record and record malicious access, nor can it effectively defend against attacks.

[0056] The embodiment of the present application provides a method for storing and alerting mobile phone shield access records. The method records the access records of TA to the mobile phone shield through blockchain technology, and utilizes the advantages of TEE's trusted execution environment and the immutability of blockchain ledger records to achieve true and reliable evidence of mobile phone shield access records, providing the most accurate data for subsequent threat analysis and security reinforcement; through blockchain smart contracts, the evidence of mobile phone shield access records is analyzed and compared to discover malicious access requests and give users danger warnings; by reliably storing the whitelist of legal CAs allowed to access the mobile phone shield in advance through blockchain, in the TA program, by calling the CA whitelist, access requests from different CAs are filtered, and access requests not in the whitelist are filtered out, thereby achieving the effect of attack defense.

[0057] To facilitate understanding of the solution, before introducing the specific implementation of this application, we first introduce some concepts in the blockchain network architecture.

[0058] Client: Users can use the client in a blockchain system to create chaincodes, initiate transactions, and perform other functions. The client can be deployed on any terminal and implemented using the blockchain system's corresponding SDK (Software Development Kit). The terminal communicates with nodes in the blockchain network to implement the client's corresponding functions.

[0059] Block: In blockchain technology, data is permanently stored as electronic records. The files that hold these electronic records are called "blocks." Blocks are generated one by one in chronological order. Each block records all the value exchanges that occurred during its creation. All blocks are aggregated to form a chained record collection.

[0060] Block Structure: A block records transaction data within the timeframe of its creation. The block body is essentially a collection of transaction information. While the structural design of each blockchain may vary, it generally consists of a header and a body. The header links to previous blocks and ensures the integrity of the blockchain database, while the body contains a verified record of all value exchanges that occurred during the block's creation.

[0061] Peer: The blockchain network employs a distributed network structure, ensuring that all data in the database is updated in real time and stored across all participating nodes. Furthermore, the blockchain network employs a comprehensive set of protocols, ensuring that every node in the network, while participating in the recording process, also verifies the accuracy of the records of other nodes. Only when, through the protocol mechanism, all eligible nodes (e.g., all nodes, a majority of nodes, or a specific set of nodes) simultaneously deem a record correct, or when all participating nodes unanimously agree on the results, is the record's authenticity recognized by the entire network and allowed to be written into the blockchain. Therefore, in the blockchain network, all nodes collectively form a decentralized, distributed database.

[0062] In various blockchain systems, nodes not only store block data but also include specialized nodes. These include endorsing nodes and ordering nodes. Endorsing nodes execute smart contract state machines and simulate transactions. Endorsing nodes contain a pre-specified set of endorsement policies, which are installed with specific chaincodes. All transactions must comply with these endorsement policies, as only endorsed transactions are considered legitimate and recognized. In practice, upon receiving a client's transaction request, an endorsing node simulates the transaction and generates an endorsement signature based on the simulated transaction results, thereby endorsing the transaction.

[0063] A smart contract is a computer protocol designed to communicate, verify, or execute contracts in an information-based manner. Essentially, a smart contract is implemented through computer code triggered by transactional actions. The implementation of smart contracts varies across different blockchain systems. For example, in Ethereum, the behavior of smart contracts is controlled by code, and smart contract accounts store the contract state. The core of Ethereum is the EVM (Ethereum Virtual Machine), and contract code execution occurs within the EVM. Naturally, every node has an EVM, a Turing-complete virtual machine. In Fabric, smart contracts are called chaincode, which is divided into system chaincode and user chaincode. System chaincode implements system-level functions, while user chaincode implements user application functions. Chaincode is compiled into a standalone application and runs in an isolated Docker container. Compared to Ethereum, Fabric chaincode is separate from the underlying ledger. Upgrading chaincode does not require migrating ledger data to the new chaincode, truly achieving the separation of logic and data. Furthermore, chaincode is written in Go, Java, and Node.js.

[0064] Relational Database (RDB): An RDB database is a database based on the relational model, also known as a relational database. In computers, a relational database is a collection of data and database objects. Database objects include tables, views, stored procedures, triggers, and so on. The computer software that manages relational databases is a relational database management system (RDBMS). A relational database consists of data tables and relationships between them. Table associations are a crucial component of relational databases. Table associations connect tables within a database using corresponding fields.

[0065] refer to Figure 3 , is a block chain system architecture diagram of an embodiment of the present invention. Figure 3 As shown, the blockchain system architecture of the embodiment of the present invention is divided into three layers, including the protocol layer, the extension layer, and the application layer. The protocol layer can be further divided into the storage layer and the network layer. In different specific blockchain systems, the specific implementation of each layer of the three-layer architecture may vary. In this embodiment, only the basic architecture of the blockchain system is introduced.

[0066] The protocol layer provides the underlying capabilities of the blockchain system, maintaining network nodes and generally offering only APIs for invocation. The protocol layer builds the blockchain system's network environment, establishes transaction channels, and establishes node reward mechanisms or consensus mechanisms. Technically, the protocol layer primarily encompasses network programming, distributed algorithms, cryptographic signatures, and data storage.

[0067] From a functional and technical perspective, the protocol layer can be further divided into the network layer and the storage layer. The data layer primarily describes the storage format of blockchain data. This includes chain storage technology for block data, including timestamp technology and hash verification technology; it also includes database implementation methods and the interface implementation for nodes to call the database.

[0068] The primary purpose of the network layer is to facilitate information exchange between nodes in a blockchain network. A blockchain network is essentially a peer-to-peer (P2P) network. Each node both receives and generates information. Nodes maintain communication by maintaining a shared blockchain. Within a blockchain network, nodes can create new blocks. Once a new block is created, it is broadcast to other nodes, who then verify it. Once all nodes in the blockchain network reach consensus, the new block is added to the main chain.

[0069] Above the protocol layer lies the extension layer, which implements the blockchain system's functionality based on the protocol layer. Leveraging the foundational capabilities provided by the protocol layer, the extension layer enables various script codes, algorithmic mechanisms, and application mechanisms. For example, smart contracts are a typical application of the extension layer. Nodes deploy smart contracts to automatically execute contracts upon meeting certain conditions. Another example is the virtual currency trading market, where scripts encapsulate the transaction methods and implementation details of the virtual currency transaction process, also implemented in the extension layer.

[0070] Above the extension layer is the application layer, which encapsulates various blockchain application scenarios and use cases. The application layer implements blockchain functions that directly interact with users, mostly in the form of clients.

[0071] In an embodiment of the present application, the application client is deployed on an electronic device, and the extension layer, protocol layer, network layer, and storage layer can be deployed on a cloud server. The cloud server communicates with the electronic device on which the application client is deployed to transmit data.

[0072] refer to Figure 4, is a system architecture diagram of a node in a blockchain system according to one embodiment of the present invention. As shown in the figure, a blockchain node is a decentralized node within a decentralized, distributed blockchain system. Blockchain node 20 connects to client 21, processes transaction instructions initiated by the client, executes transactions within the blockchain system, and stores transaction results. In this embodiment of the present application, blockchain node 20 is the aforementioned cloud server. Within the node, an endorsement unit 201 is used to perform endorsement operations. A smart contract unit 202 is used to store and execute smart contracts. A parsing unit 203 is used to parse received transaction instructions. In some implementations, a sorting node 204 is required in the blockchain system. In this case, a node with sorting functionality also includes a sorting unit that receives transactions with endorsement signatures sent by other nodes and packages the transactions into block data in a specified order. The node also includes an asymmetric encryption unit 205, a digital certificate unit 206, or a digital signature unit 207 to implement the corresponding blockchain system functions, a network unit 208 to handle data transmission with other nodes, and a storage unit 209 to store transactions in a database.

[0073] like Figure 5 The following is a diagram of a blockchain-based mobile shield access record storage and alarm system provided by an embodiment of the present application. The system includes a blockchain cloud server and a terminal device deployed with REE and TEE and a built-in security component inSE (mobile shield).

[0074] The blockchain client 1 of the client application CA in REE that executes financial transactions is used to: send the access request of the legitimate app (legitimate client application CA) to the mobile shield to the cloud server, so that the smart contract unit of the cloud server records all access requests sent by the legitimate app; it is also used to obtain an alarm prompt of the access of the malicious app (malicious client application CA) to the mobile shield from the smart contract module.

[0075] The blockchain client 2 of the trusted application TA in TEE is used to: receive the mobile shield access request from REE; send the received access request to the smart contract unit of the cloud server, so that the smart contract unit records the access request from TEE; filter the access request from REE through the smart contract unit's judgment on the legitimacy of the access request; send the legitimate access request to the mobile shield, and send the access result returned by the mobile shield to the legitimate app in REE.

[0076] The blockchain cloud server is used to store blockchain data. Smart contract units (such as Figure 4The smart contract unit 202 in the TEE); the smart contract unit can verify the legitimacy of the access request received by the trusted application TA, filter the access request of the client application CA to the mobile shield according to the whitelist, and prevent malicious client applications from accessing the mobile shield; store the access request sent by the blockchain client 1 of the legitimate client application CA and the access request sent by the blockchain client 2 of the trusted application TA in the TEE; compare and analyze the access request sent by the blockchain client 1 of the legitimate client application CA and the access request sent by the blockchain client 2 of the trusted application TA in the TEE to determine whether there is a malicious app accessing the mobile shield, and feedback the confirmation result to the legitimate app of REE to alert the user of malicious app access.

[0077] like Figure 6 As shown, an embodiment of the present application provides a method for storing and alerting access records of mobile phone shields.

[0078] Step 301: The client application CA in REE sends an access request to the trusted application TA in TEE for the mobile shield;

[0079] Step 302: The trusted application TA in the TEE receives the access request for the mobile shield sent by the client application CA and sends the access request to the blockchain smart contract unit;

[0080] Step 303: The smart contract unit verifies the legitimacy of the access request and returns the verification result to the trusted application TA in the TEE.

[0081] The smart contract unit can obtain a list of legal entities recorded in the blockchain. This list contains information about legal client application CAs. This information may include the package name of the client application CA, which uniquely identifies the application and is unique for each application. The information may also include the version number of the client application CA. The smart contract unit verifies whether the client application CA initiating the access request is on the list and sends the verification result to the trusted application TA in the TEE.

[0082] If the client application CA that initiates the access request is not in the legal list, the client application CA is a malicious client application, and step 304 is executed; if the client application CA that initiates the access request is in the legal list, the client application CA is a legal client application, and step 305 is continued.

[0083] Step 304: The trusted application TA receives the verification result and sends an access denial instruction to the client application CA that initiated the access request;

[0084] If the verification result shows that the client application CA that initiated the access request is malicious, that is, illegal, the trusted application TA sends an access denial instruction to the client application CA that initiated the access request, denying the client application CA access to the mobile shield.

[0085] Optionally, the trusted application TA may also present information about the malicious client application on the user interface.

[0086] Step 305: The trusted application TA receives the verification result and forwards the access request to the mobile shield;

[0087] Step 306: The mobile shield receives the access request and returns the access result to the trusted application TA;

[0088] Step 307: The trusted application TA returns the access result to the client application CA;

[0089] In the above embodiment, the access request sent by the client application CA is verified according to the legal list recorded in the blockchain to prevent malicious client application CA from accessing the mobile shield.

[0090] In another embodiment, step 308 is further included after step 302;

[0091] Step 308: The smart contract unit stores the access request sent by the trusted application TA;

[0092] The access requests sent by the trusted application (TA) stored in the smart contract unit are all access requests received by the trusted application (TA) from the REE. In other words, the access requests sent by the trusted application (TA) stored in the smart contract unit include access requests sent by both legitimate and malicious apps on the REE side.

[0093] Step 309: The smart contract unit compares the access request sent by the client application CA on the REE side with the access request sent by the trusted application TA to determine whether there is a malicious app accessing the mobile shield;

[0094] For a legitimate client application CA, during step 301, the legitimate client application CA sends an access request to the smart contract unit via blockchain client 1. In other words, the access request sent by the client application CA on the REE side, as evidenced by the smart contract unit, only includes access requests from legitimate apps. If a malicious app on the REE side sends an access request to the trusted application TA, the access request sent by the REE side, as evidenced by the smart contract unit, and the access request sent by the TEE side will not match, for example, the number of requests will be different.

[0095] Step 310: The smart contract unit alerts the legitimate app that a malicious app has accessed the mobile shield.

[0096] The smart contract unit sends the information of the malicious app to the blockchain client 1 of the legitimate client application CA to call the blockchain smart contract; notifies the legitimate app that a malicious app has also attempted to access the mobile shield between this legitimate access and the last legitimate access, and presents the warning information to the user.

[0097] like Figure 7 As shown, a blockchain-based mobile phone shield access record storage and alarm system is provided in an embodiment of the present application.

[0098] In the legitimate app, implement a Fabric client module: Fabric client 1, which can normally access the Hyperledger Fabric blockchain system, call the smart contract unit in the blockchain system, and complete the storage of the legitimate app's access record to the mobile shield;

[0099] In the TA program, a Fabric client module is implemented: Fabric client 2, which can normally access the Hyperledger Fabric blockchain system, call the smart contract in the blockchain system, and complete the storage of all access records of the mobile shield through the TA program;

[0100] On the Hyperledger Fabric blockchain platform, a smart contract unit is developed to complete the following functions: (1) Complete the access record of the mobile phone shield issued by the blockchain client module Fabric client 1 of the legal App; (2) Complete the access record of the mobile phone shield issued by the blockchain client module Fabric client 2 of the TA program; (3) Complete the comparative analysis of the above two evidence records and support the legal App blockchain client module to obtain the analysis results.

[0101] The specific software business logic of the Fabric client1 module accessing the mobile shield record stored on the blockchain is as follows Figure 8 shown.

[0102] In the legitimate app, the Fabric client1 module completes the record and evidence of the legitimate app accessing the mobile shield through the above process. The structure of the evidence information is defined as follows:

[0103]

[0104] It should be noted that in the blockchain system, when a smart contract is called to store evidence, the result of the evidence is not immediately recorded in the blockchain ledger. Instead, the result is first returned to the Fabric client, which then packages it into a transaction and sends it to the orderer node of the blockchain system for sorting and packaging into blocks.

[0105] The Fabric client1 module accesses the evidence in the blockchain smart contract unit and issues an alarm. Figure 9 shown.

[0106] The Fabric client1 module provides an API for legitimate apps to access the Mobile Shield. The API integrates Fabric's SDK (Software Development Kit). Through the SDK's call interface, it queries whether any malicious apps have accessed the Mobile Shield between the current and last accesses. The malicious app's package name and access time are displayed to the user in a pop-up alert.

[0107] The specific software business logic of the Fabric client2 module is as follows Figure 10 shown.

[0108] In the Fabric client2 module, an API is provided for the TA program to access the main process call of the mobile shield. Inside the API, the Fabric SDK is integrated, and the smart contract is accessed through the SDK's invoke interface. The hash value of the information of the app accessing the mobile shield is recorded on the blockchain; at the same time, the smart contract is accessed through the query interface to obtain the whitelist of legal apps (the whitelist of legal apps is recorded in the smart contract, including but not limited to: hard-coding the whitelist information in the smart contract). The package name of the app accessing the mobile shield is searched in the whitelist. If it is found, it means it is a legal app, and the access is forwarded to the mobile shield. If it is not found, it means it is a malicious app, and the access is denied.

[0109] The software business logic of the smart contract unit is as follows: Figure 11 shown.

[0110] In response to the access requests from Fabric client1 and Fabric client2, there are four business processes in the smart contract that are handled separately: (1) For the evidence of legal access records, the smart contract stores them in the form of key-value and returns the evidence results to Fabric client1; (2) All access records of the mobile shield accessed by the TA program are evidenced and the evidence results are returned to Fabric client2; (3) The access records of legal apps accessing the mobile shield are compared with the access records of all accesses to the mobile shield recorded by the TA program, and the comparison results are fed back to Fabric client1; (4) The whitelist of legal apps is fed back to Fabric client2 for Fabric client2 to intercept malicious requests.

[0111] Through the above technical solution, reliable evidence storage of mobile phone shield access records is achieved. At the same time, a certain attack defense effect against malicious apps can be achieved based on the legal app whitelist on the blockchain. When a legal app accesses the mobile phone shield, an alarm for malicious access requests to the mobile phone shield can be achieved based on the comparison of the evidence records. The embodiment of the present invention improves the existing mobile phone shield solution and introduces access record evidence and attack defense capabilities through the tamper-proof property of the blockchain ledger. While improving the attack defense capability of the mobile phone shield, reliable data is provided for mobile phone shield threat analysis. The embodiment of the present invention improves the existing mobile phone shield solution and introduces the client module of the blockchain on both the REE side and the TEE side. Through the tamper-proof property of the blockchain ledger, the access record evidence and attack defense capabilities of the mobile phone shield are achieved.

[0112] Please refer to Figure 12 , is a schematic diagram of the structure of a computer system provided in this embodiment. The computer system can be a terminal device. As shown in the figure, the computer system includes a communication module 810, a sensor 820, a user input module 830, an output module 840, a processor 850, an audio and video input module 860, a memory 870, and a power supply 880. Furthermore, the computer system provided in this embodiment may also include an NPU 890.

[0113] The communication module 810 may include at least one module that enables the computer system to communicate with a communication system or other computer systems. For example, the communication module 810 may include one or more of a wired network interface, a broadcast receiving module, a mobile communication module, a wireless Internet module, a local area communication module, and a location (or positioning) information module. These various modules have various implementations in the prior art and are not described in detail herein.

[0114] The sensor 820 may sense the current state of the system, such as open / closed state, position, presence or absence of contact with a user, direction, and acceleration / deceleration, and may generate a sensing signal for controlling operation of the system.

[0115] The user input module 830 is used to receive input digital information, character information, or contact touch operations / contactless gestures, as well as receive signal input related to user settings and function control of the system. The user input module 830 includes a touch panel and / or other input devices.

[0116] The output module 840 includes a display panel for displaying information input by the user, information provided to the user, or various menu interfaces of the system. Optionally, the display panel can be configured in the form of a liquid crystal display (LCD) or an organic light-emitting diode (OLED). In other embodiments, a touch panel can be overlaid on the display panel to form a touch screen display. In addition, the output module 840 may also include an audio output module, an alarm, and a tactile module.

[0117] The audio and video input module 860 is used to input audio signals or video signals. The audio and video input module 860 may include a camera and a microphone.

[0118] The power supply 880 may receive external power and internal power under the control of the processor 850 and provide power required for the operation of various components of the system.

[0119] The processor 850 includes one or more processors. For example, the processor 850 may include a central processing unit (CPU) and a graphics processing unit (GPU). The CPU in this application has multiple cores and is a multi-core processor. These multiple cores may be integrated on the same chip or may be independent chips.

[0120] The memory 870 stores computer programs, including operating system programs 872 and application programs 871. Typical operating systems include Microsoft Windows, Apple MacOS, etc., which are used for desktops or notebooks, and Google's development of the operating system based on Android The method provided in the above embodiment can be implemented by software and can be considered as a specific implementation of the operating system program 872.

[0121] The memory 870 may be one or more of the following types: flash memory, hard disk type memory, micro multimedia card type memory, card memory (such as SD or XD memory), random access memory (RAM), static random access memory (SRAM), read only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), replay protected memory block (RPMB), magnetic storage, magnetic disk, or optical disk. In some other embodiments, the memory 870 may also be a network storage device on the Internet, and the system may perform operations such as updating or reading the memory 870 on the Internet.

[0122] The processor 850 is used to read the computer program in the memory 870 and then execute the method defined by the computer program. For example, the processor 850 reads the operating system program 872 to run the operating system on the system and implement various functions of the operating system, or reads one or more application programs 871 to run applications on the system.

[0123] The memory 870 also stores other data 873 in addition to the computer programs.

[0124] The NPU 890 is mounted on the main processor 850 as a coprocessor and is used to execute tasks assigned to it by the main processor 850. In this embodiment, the NPU 890 can be called by one or more sub-threads of the face recognition TA to implement some of the complex algorithms involved in face recognition. Specifically, the sub-threads of the face recognition TA run on multiple cores of the main processor 850, and then the main processor 850 calls the NPU 890, and the results achieved by the NPU 890 are returned to the main processor 850.

[0125] The connection relationship between the above modules is only an example. The method provided in any embodiment of the present application can also be applied to terminal devices with other connection methods, for example, all modules are connected through a bus.

[0126] It should be noted that the division of modules or units in the aforementioned embodiments is merely exemplary, and the functions of the modules described are merely illustrative, and the present application is not limited thereto. A person skilled in the art may combine the functions of two or more modules as needed, or split the functions of a module to obtain more and finer-grained modules, or perform other variations.

[0127] The same or similar parts between the various embodiments described above can be referenced to each other. Unless otherwise specified, "multiple" in this application refers to two or more, or "at least two." "A / B" in this application includes three situations: "A," "B," and "A and B."

[0128] The device embodiments described above are merely illustrative, wherein the modules described as separate components may or may not be physically separate, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed over multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment. In addition, in the drawings of the device embodiments provided in this application, the connection relationship between the modules indicates that there is a communication connection between them, which can be specifically implemented as one or more communication buses or signal lines. Those of ordinary skill in the art can understand and implement the present invention without paying any creative work.

[0129] The above descriptions are only some specific implementation methods of the present application, but the protection scope of the present application is not limited thereto.

Claims

1. A computer system comprising a terminal device and a server, wherein a TEE trusted execution environment and a REE rich execution environment and a built-in security component are deployed on the terminal device, wherein the built-in security component is used to execute financial transactions based on user keys, the TEE is deployed with a TA trusted application, and the REE is deployed with a CA client application, characterized in that: The CA is deployed with a first blockchain client module, the TA is deployed with a second blockchain client module, and the server is deployed with a smart contract unit. The first blockchain client module is used to: send an access request for the built-in security component to the TA; send the access request to the server; the access request includes information about the CA; The second blockchain client module is used to: send all received access requests to the built-in security component to the server; The smart contract unit is configured to: record all access requests to the built-in security component sent by the second blockchain client module and the access requests sent by the first blockchain client module in a blockchain stored on the server; compare the access requests received from the second blockchain client module with the access requests received from the first blockchain client module to determine whether a malicious CA has initiated an access request to the built-in security component; If it is determined that the malicious CA has initiated an access request to the built-in security component, an alarm message is sent to the first blockchain client module, where the alarm message is used to prompt that a malicious CA has initiated access to the built-in security component.

2. The computer system according to claim 1, wherein: The smart contract unit is further configured to: verify the legitimacy of the access request based on a legal list and send the verification result to the TA; the verification result indicates whether the CA initiating the access request is malicious; the legal list stores information on multiple legal CAs; The second blockchain client module is further configured to: receive the verification result from the smart contract unit; and reject the access request of the malicious CA when the verification result indicates that the CA that initiated the access request is malicious.

3. The computer system according to claim 1, wherein: The second blockchain client module is further used to send information about the malicious CA to the CA.

4. A terminal device, wherein a TEE trusted execution environment and a REE rich execution environment and a built-in security component are deployed on the terminal device, wherein the built-in security component is used to execute financial transactions based on user keys, the TEE is deployed with a TA trusted application, and the REE is deployed with a CA client application, characterized in that: The CA is deployed with a first blockchain client module, and the TA is deployed with a second blockchain client module. The first blockchain client module is used to: send an access request for the built-in security component to the TA; send the access request to the server; the access request includes information about the CA; The access request sent by the first blockchain client module to the server is stored in the blockchain by the server; The second blockchain client module is used to: send all received access requests to the built-in security component to the server; All access requests to the built-in security component sent by the second blockchain client module to the server are stored in the blockchain by the server; The first blockchain client module is further used to: receive an alarm message sent by the server, where the alarm message is used to prompt that a malicious CA has initiated access to the built-in security component. The alarm message is sent to the CA after the server compares the access request sent by the second blockchain client module with the access request sent by the first blockchain client module and determines that a malicious CA has initiated an access request to the built-in security component.

5. The terminal device according to claim 4, characterized in that The second blockchain client module is further configured to: receive a verification result from the server; and when the verification result indicates that the CA initiating the access request is malicious, reject the access request of the malicious CA; The verification result is a result obtained by the server verifying the legitimacy of the access request according to the legal list; The verification result indicates whether the CA that initiates the access request is malicious; the legal list stores information of multiple legal CAs.

6. The terminal device according to claim 5, characterized in that The CA receives the information of the malicious CA sent by the server.

7. A method for recording and recording access records and providing an alarm for a mobile phone shield, the method being applied to a terminal device, wherein the terminal device is deployed with a TEE trusted execution environment and a REE rich execution environment and a built-in security component, wherein the built-in security component is used to execute financial transactions based on user keys, and the TEE is deployed with a TA trusted application, characterized in that: The REE is deployed with a CA client application, the CA is deployed with a first blockchain client, and the TA is deployed with a second blockchain client. The method includes: The CA sends an access request for the built-in security component to the TA; sends the access request to the server; the access request includes information about the CA; the access request sent by the CA to the server is stored in the blockchain by the server; The TA sends all received access requests to the built-in security component to the server; all access requests to the built-in security component sent by the TA to the server are stored in the blockchain by the server; The CA receives the warning information sent by the server, where the warning information is used to prompt that a malicious CA has initiated access to the built-in security component. The warning information is sent to the CA after the server compares the access request sent by the TA with the access request sent by the CA and determines that a malicious CA has initiated access to the built-in security component.

8. The method for storing and alerting mobile phone shield access records according to claim 7, characterized in that: Verify the legitimacy of the access request according to the legal list and send the verification result to the TA; The verification result indicates whether the CA that initiated the access request is malicious; The legal list stores information of multiple legal CAs; Receive the verification result from the smart contract unit; When the verification result indicates that the CA that initiated the access request is malicious, the access request of the malicious CA is rejected.

9. The method for storing and alerting mobile phone shield access records according to claim 8, characterized in that: Send the malicious CA information to the CA.

10. A server, wherein the server is in communication with a terminal device, The terminal device is deployed with a TEE trusted execution environment and a REE rich execution environment and a built-in security component, the built-in security component is used to execute financial transactions based on user keys, the TEE is deployed with a TA trusted application, the REE is deployed with a CA client application, the CA is deployed with a first blockchain client, and the TA is deployed with a second blockchain client. The server is used to: Recording all access requests to the built-in security component sent by the TA and the access requests sent by the CA in the blockchain stored on the server; Comparing the received access request sent by the TA with the received access request sent by the CA, and determining whether a malicious CA has initiated an access request to the built-in security component; If it is determined that the malicious CA has initiated an access request to the built-in security component, an alarm message is sent to the CA, where the alarm message is used to prompt that a malicious CA has initiated access to the built-in security component.

11. A computer system, characterized in that: comprising a memory and a processor, wherein, The memory is used to store computer-readable instructions; the processor is used to read the computer-readable instructions and implement the method according to any one of claims 7 to 9.

12. A computer storage medium, characterized in that Computer-readable instructions are stored, and when the computer-readable instructions are executed by a processor, the method according to any one of claims 7 to 9 is implemented.

Images