A data risk monitoring method, hardware device and computer program product

Abstract

The embodiment of the application relates to the technical field of data security, and provides a data risk monitoring method, a hardware device and a computer program product, which are applied to a hardware device deployed with a TEE. The method comprises the following steps: establishing an encrypted transmission link with a data providing end through the TEE; obtaining target encrypted data returned and decrypting the target encrypted data to obtain target data in the TEE; sending the target data to a computing device; obtaining a check value of security software in the computing device; comparing the check value of the security software with a check value stored in advance in the TEE, and determining that there is a data security risk when the comparison result is inconsistent. Based on the scheme, the hardware device completes the decryption and check of encrypted data in the TEE, and simultaneously performs integrity check on the security software, so that the data security problem caused by malicious tampering of the security software is avoided to a certain extent, data security protection is realized in the whole link of transmission, decryption and use, and the risks of leakage and ownership loss of control in the data flow process are avoided.

Description

Technical Field

[0001] This application relates to the field of data security technology, and in particular to a data risk monitoring method, hardware device, and computer program product. Background Technology

[0002] With the development of artificial intelligence (AI) technology, data, as a core element driving AI model training and application, is becoming increasingly valuable. However, data faces multiple security risks during its circulation, such as leakage, misuse, and unauthorized access. Especially in cross-organizational and cross-platform data collaboration scenarios, problems such as unclear data sovereignty, blurred usage boundaries, and lagging control measures are becoming increasingly prominent.

[0003] Commonly used data protection methods mainly include confidential computing, which can achieve isolated computing by deploying a Trusted Execution Environment (TEE).

[0004] However, confidential computing relies on dedicated hardware and requires significant invasive modifications to computing devices (such as servers), resulting in high deployment costs. Summary of the Invention

[0005] This application provides a data risk monitoring method, hardware device, and computer program product that can avoid large-scale invasive modifications to computing devices while also taking into account data security and the smoothness of data manipulation to a certain extent.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: In a first aspect, embodiments of this application provide a data risk monitoring method applied to a hardware device. The hardware device is used to communicate with a computing device through a first communication interface, and the hardware device is equipped with a Trusted Execution Environment (TEE). The method includes: establishing an encrypted transmission link with a data provider through the TEE; obtaining target encrypted data returned by the data provider through the encrypted transmission link and decrypting it in the TEE to obtain the target data; sending the target data to the computing device; obtaining a verification value of security software in the computing device and transmitting the verification value of the security software to the TEE; wherein the security software is software installed on the computing device and is used to monitor operations on the target data in the computing device during runtime; comparing the verification value of the security software with a pre-stored verification value in the TEE, and determining that there is a data security risk when the comparison result is inconsistent; wherein the pre-stored verification value is stored in the TEE.

[0007] Based on this solution, the hardware device is equipped with a Trusted Execution Environment (TEE). The decryption and verification of encrypted data are completed within the TEE. To utilize the computing power of the computing device and improve the smoothness of data operations, the hardware device sends the decrypted data to the computing device. However, this raises security concerns. Therefore, this application further deploys security software for monitoring in the computing device and performs integrity verification on the security software to prevent it from becoming ineffective due to malicious tampering. Data protection is achieved across the entire chain, from transmission, decryption, deployment of security software, to verification of security software. This not only overcomes the high deployment costs of existing technical solutions but also, to a certain extent, balances data security and the smoothness of data manipulation.

[0008] In one possible implementation, the method further includes: during the startup phase of the computing device, communicating with the computing device to obtain the storage address of the security software in the computing device; and accordingly, obtaining the verification value of the security software in the computing device, including: sending the storage address to the computing device and obtaining the verification value of the security software in the computing device.

[0009] Based on this solution, hardware devices can accurately locate the storage location of security software by obtaining the storage address, without having to traverse the entire storage space of the computing device to complete the security software location. This facilitates the hardware devices to perform software verification, reduces the computing resource consumption caused by the location process, and avoids the deviation of the verification object caused by incorrect storage location, thus ensuring the accuracy and execution efficiency of the integrity verification process.

[0010] In another possible implementation, the storage address is sent to the computing device to obtain the verification value of the security software in the computing device, including: sending the storage address to the computing device at preset time intervals to obtain the verification value of the security software in the computing device.

[0011] Based on this solution, hardware devices can periodically verify the integrity of security software, promptly detect the risk of malicious tampering of security software during operation, make up for the inadequacy of a single verification that can only cover the startup phase, realize the trustworthiness management of security software throughout its entire lifecycle, and further enhance the security protection capabilities in the data usage phase.

[0012] In another possible implementation, before the step of obtaining the target encrypted data returned by the data provider via an encrypted transmission link, the method of using the data to send the required target data to the data provider via an encrypted transmission link is also included.

[0013] Based on this solution, hardware devices can clearly define the usage boundaries of data to the data provider, and the data provider can pre-agree on the usage permissions after decryption according to the declared usage method to avoid the target data being used beyond the scope of permissions.

[0014] In another possible implementation, the method further includes: receiving usage constraints for the target data returned by the data provider via an encrypted transmission link; and sending the received usage constraints to a computing device to configure security software in the computing device.

[0015] Based on this solution, hardware devices can synchronize the permission rules agreed upon by the data provider to the security software on the computing device side. This enables the security software to control all operations on the target data in the computing device in real time according to the pre-agreed rules. Operations that exceed the agreed scope will be directly blocked by the security software, realizing a closed loop from permission agreement to operation control, and further strengthening the security protection capabilities of the data usage process.

[0016] In another possible implementation, before the step of obtaining the target encrypted data returned by the data provider via the encrypted transmission link, the method further includes: negotiating with the data provider via the encrypted transmission link to adjust the encryption algorithm of the encrypted transmission link based on the sensitivity level of the requested target data.

[0017] Based on this solution, hardware devices can be adapted to different strengths of encryption protection schemes for target data with different sensitivity levels. This avoids unnecessary waste of computing resources caused by using high-complexity encryption for low-sensitivity data, and also ensures that the encryption strength of high-sensitivity data meets security requirements. It can achieve a flexible balance between security and operating efficiency, and adapt to the differentiated data security protection needs in different scenarios.

[0018] In another possible implementation, before establishing an encrypted transmission link with the data provider via the TEE, the method further includes: during the startup phase of the computing device, communicating with the computing device to obtain the checksums of the computing device's Basic Input / Output System (BIOS) and Operating System (OS); within the TEE, performing a match between the checksums of the BIOS and OS and their corresponding preset checksums, and allowing the computing device to obtain data from the data provider when both the BIOS and OS checksums match their respective preset checksums.

[0019] Based on this solution, the hardware device can complete the integrity verification of the underlying system of the computing device before the data acquisition process starts, intercepting the data security risks caused by malicious tampering of the underlying system from the source, further improving the credibility and security of the entire data circulation link, and avoiding the subsequent protection failure problem caused by underlying risks.

[0020] In another possible implementation, the method further includes: when it is determined that the checksum of at least one of the BIOS and OS does not match the preset checksum, sending information to the computing device to configure the security software in the computing device to perform an interception operation on the data request.

[0021] Based on this solution, hardware devices can trigger a security interception mechanism as soon as they detect a risk of tampering with the underlying system. This blocks unauthorized data acquisition from the access point, prevents sensitive data from leaking out of untrusted system environments, improves the risk handling process after the underlying verification fails, and forms a complete risk identification and risk handling protection closed loop.

[0022] Secondly, embodiments of this application also provide a hardware device, including a first memory, a first processor, and a first communication interface. The first memory is used to store first program instructions, and the first communication interface is used to communicate with an external computing device. The hardware device is also equipped with a Trusted Execution Environment (TEE). The first processor is used to execute the first program instructions, causing the hardware device to perform the data risk monitoring method as described in any of the first aspects above.

[0023] Thirdly, this application also provides a data risk monitoring method applied to a computing device. The computing device communicates with an external hardware device through a second communication interface, and the hardware device is equipped with a Trusted Execution Environment (TEE). The method receives target data sent by the hardware device. The target data is data obtained by the hardware device after decrypting target encrypted data through the TEE, and the target encrypted data is data obtained by the hardware device from a data provider. The method monitors operations on the target data using installed security software. The security software is software installed on the computing device. The method sends the file data of the security software to the hardware device so that the hardware device can obtain the verification value of the security software and compare the verification value of the security software with a pre-stored verification value in the TEE.

[0024] Based on this solution, the hardware device is equipped with a Trusted Execution Environment (TEE). The decryption and verification of encrypted data are completed within the TEE. At the same time, in order to utilize the computing power of the computing device and improve the smoothness of data operations, the data is sent to the computing device. However, this raises security concerns. Therefore, this application further deploys security software for monitoring in the computing device and performs integrity verification on the security software to prevent it from becoming invalid due to malicious tampering. Data protection is achieved through the entire chain, from transmission, decryption, deployment of security software, to verification of security software. This not only overcomes the high deployment costs of existing technical solutions but also, to a certain extent, balances data security and the smoothness of data manipulation.

[0025] Fourthly, embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the method as described in the third aspect.

[0026] Fifthly, this application also provides a data risk monitoring method applied to a data demand end. The data demand end includes a hardware device and a computing device. The hardware device is connected to the computing device via a first communication interface and is equipped with a Trusted Execution Environment (TEE). The method includes: establishing an encrypted transmission link with a data provider via the TEE; obtaining target encrypted data returned by the data provider via the encrypted transmission link and decrypting it in the TEE to obtain the target data; sending the target data to the computing device; receiving the target data from the hardware device; monitoring operations on the target data in the computing device using installed security software; obtaining the verification value of the security software in the computing device and transmitting the verification value to the TEE; comparing the verification value of the security software with a pre-stored verification value in the TEE, and determining a data security risk when the comparison results are inconsistent; wherein the pre-stored verification value is stored in the TEE.

[0027] Based on this solution, the hardware device is equipped with a Trusted Execution Environment (TEE). The decryption and verification of encrypted data are completed within the TEE. At the same time, in order to utilize the computing power of the computing device and improve the smoothness of data operations, the data is sent to the computing device. However, this raises security concerns. Therefore, this application further deploys security software for monitoring in the computing device and performs integrity verification on the security software to prevent it from becoming invalid due to malicious tampering. Data protection is achieved through the entire chain, from transmission, decryption, deployment of security software, to verification of security software. This not only overcomes the high deployment costs of existing technical solutions but also, to a certain extent, balances data security and the smoothness of data manipulation.

[0028] Sixthly, embodiments of this application also provide a data risk monitoring system, including a computing device and a hardware device; wherein, the hardware device includes a first memory, a first processor, and a first communication interface, the first memory being used to store first program instructions, and the first communication interface being used to communicate with the computing device; the hardware device is also deployed with a Trusted Execution Environment (TEE); the computing device includes a second memory, a second processor, and a second communication interface, the second memory being used to store second program instructions, and the second communication interface being used to communicate with the hardware device; the first processor is used to execute the first program instructions, and the second processor is used to execute the second program instructions, so as to implement the data risk monitoring method as described in the fifth aspect above.

[0029] In a seventh aspect, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, implement the method as described in any of the first aspects.

[0030] Eighthly, embodiments of this application provide a computer program product including a computer program that, when executed by a processor, implements the method as described in any of the first aspects.

[0031] In a ninth aspect, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, implement the method as described in the third aspect.

[0032] In a tenth aspect, embodiments of this application provide a computing device, including a second memory, a second processor, and a second communication interface. The second memory is used to store second program instructions, and the second communication interface is used to communicate with external hardware devices. The second processor is used to execute the second program instructions, causing the computing device to perform the method described in the third aspect above. Attached Figure Description

[0033] Figure 1 A schematic diagram illustrating a computing device interaction provided in an embodiment of this application; Figure 2 A flowchart illustrating a data risk monitoring method provided in an embodiment of this application; Figure 3 A schematic diagram of a data security verification process provided in an embodiment of this application; Figure 4 A schematic diagram illustrating a configuration and usage constraint process provided in an embodiment of this application; Figure 5 A flowchart illustrating a negotiated encryption strategy provided in an embodiment of this application; Figure 6 This application provides a schematic diagram of a process for verifying the security of a device. Figure 7 A schematic diagram of a process for generating behavior logs provided in an embodiment of this application; Figure 8 This is a schematic diagram of a data risk monitoring system provided in an embodiment of this application; Figure 9 This is a schematic diagram illustrating the interaction between the data request end and the hardware device provided in an embodiment of this application. Figure 10 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0034] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the use of terms such as "first," "second," etc., in the embodiments of this application is for illustrative purposes and to distinguish the objects being described. There is no particular order between them, nor does it indicate a specific limitation on the number of devices in the embodiments of this application, and they do not constitute any limitation on the embodiments of this application.

[0035] The following explanations of the technical terms mentioned in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0036] A Trusted Execution Environment (TEE) is a trusted computing space provided by hardware isolation. By running sensitive data and critical code in the executable environment, data can be protected from the operating system and external attackers.

[0037] National cryptographic algorithms refer to national commercial cryptographic algorithms, including SM2 elliptic curve public key cryptography algorithm, SM3 cryptographic hash algorithm, SM4 block cipher algorithm, etc. The national cryptographic algorithms used in the embodiments of this application can be any one of SM2, SM3, SM4 or a combination thereof. Application examples are described in the subsequent process description.

[0038] A domain refers to an independent data management and trust boundary, corresponding to a physically, logically, and managerially defined scope of an organization or system. In this embodiment, taking a computing device cluster as an example, a domain can be a collection of computing devices located in the same physical location (e.g., the same computer room) within the computing device cluster, and the computing device cluster can include multiple domains.

[0039] The application scenarios of this application are described below.

[0040] Figure 1 This is a schematic diagram illustrating a computing device interaction provided in an embodiment of this application. The following is based on... Figure 1 The content shown illustrates the scenario of data transmission between computing devices in the embodiments of this application.

[0041] like Figure 1 As shown, the computing device cluster 100 contains multiple computing devices 110, and each computing device 110 can be located in the same physical location or distributed in different regions. In this embodiment, the computing devices 110 communicate with each other through a network connection between hardware devices 120 connected to the computing devices 110. The communication connection between the computing devices 110 and the hardware devices 120 can be achieved through a PCIe interface.

[0042] It should be understood that, Figure 1The connection relationship shown is only an example. In actual applications, each hardware device 120 can be connected to network connectors in other domains through a network connector, and then network connection between each computing device 110 can be realized based on the connection between each hardware device 120.

[0043] When a computing device 110 needs to use data managed by another computing device 110, it needs to send a data access request to the corresponding hardware device 120 of the other computing device 110 through its own connected hardware device 120. After verifying the request, the receiving hardware device 120 returns an address to the requesting computing device 110 to establish a corresponding encrypted channel. The requesting computing device 110 can register a corresponding storage area within its own storage resources to receive and decrypt data transmitted through the hardware device 120, thereby initiating a data flow process based on the transmission channel between the two devices.

[0044] Based on the above-mentioned interaction process, this application provides a data risk monitoring method, hardware device, and computer program product. By setting up hardware devices on computing devices to realize data interaction between computing devices, it is possible to avoid large-scale intrusive modifications to computing devices. At the same time, it also takes into account data security and the smoothness of data manipulation, realizes control over the data circulation process, and ensures that data sovereignty is always controllable and the circulation process is traceable, thereby improving the security, efficiency, and credibility of data circulation.

[0045] It should be understood that the data risk monitoring method provided in this application embodiment can be applied to hardware devices connected to computing devices, so that the hardware devices can provide security for data transmission between computing devices. The hardware devices can be external devices independent of the computing devices, while the computing devices can be devices with data processing capabilities, such as servers, personal computers, or mobile terminals. This application embodiment does not limit the specific types, deployment forms, or hardware configurations of the computing devices and hardware devices.

[0046] The technical solutions provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0047] Figure 2 This is a flowchart illustrating a data risk monitoring method provided in an embodiment of this application. The following is based on... Figure 2 The content shown here is an exemplary illustration of the process by which the hardware device performs data risk monitoring in the embodiments of this application.

[0048] like Figure 2 As shown, the process of hardware device performing data risk monitoring in this embodiment may include the following steps S100 to S500.

[0049] S100: Establishes an encrypted transmission link with the data provider via TEE.

[0050] In step S100, the hardware device utilizes the secure isolation features of the Trusted Execution Environment (TEE) to perform identity authentication and key negotiation with the data provider, thereby establishing an encrypted transmission link between the data requester and the data provider. In this embodiment, to balance the security of data flow between the data requester and the data provider, the design cost of the computing device, and the smoothness of data manipulation by the data requester, this application provides an externally connectable hardware device. This hardware device deploys a Trusted Execution Environment (TEE) and can communicate with the computing device of the data requester, providing a trusted and secure relay for data transmission.

[0051] Correspondingly, the computing devices in the data provider and data demand sides perform data interaction in subsequent processes through encrypted transmission links, avoiding direct plaintext data interaction between the two, thereby reducing the risk of data being eavesdropped or tampered with during transmission.

[0052] During the establishment of an encrypted transmission link, the hardware device can perform two-way authentication based on the identity identifiers of the computing devices in the data request end and the data provider end, and negotiate to obtain a dedicated session key for this transmission. All data in the transmission process will be encrypted using this session key. Even if the transmission process is eavesdropped on, the eavesdropper will not be able to crack the transmitted content, thus ensuring the security of the transmission link.

[0053] For example, within its trusted execution environment, a hardware device can transmit digital certificates or unique hardware identifiers between the data provider and the data requester to verify the legitimacy of both parties. After successful verification, both parties generate interactive key negotiation parameters based on random number negotiation, achieving two-way authentication and entering the key negotiation process.

[0054] In the key negotiation process, the computing device on the data request side can negotiate a session key with the data provider based on the national cryptographic algorithm. This session key is used to encrypt the data to be transmitted. The hardware device can then establish an encrypted transmission link between the data request side and the data provider using the negotiated session key.

[0055] In some embodiments of this application, the computing device of the data provider and the computing device of the data requester can each be equipped with a hardware device, so that the data requester and the data provider can each complete identity authentication and key negotiation through their connected hardware devices. This ensures that the key negotiation is carried out in a trusted execution environment, avoids the key being exposed in plaintext in memory, and reduces the risk of key leakage.

[0056] S200: Obtain the target encrypted data returned by the data provider through the encrypted transmission link, and decrypt it in the TEE to obtain the target data.

[0057] In step S200, after establishing an encrypted transmission link between the data requester and the data provider, the hardware device can receive target encrypted data from the data provider. In this embodiment, the target encrypted data refers to the ciphertext data obtained by the data provider encrypting the original data according to the request of the data requester, using an encryption algorithm and session key determined through negotiation.

[0058] After receiving the target encrypted data, the hardware device can decrypt the ciphertext data within the TEE (Transmission Equipment) to obtain the corresponding plaintext target data. The decryption process of the hardware device runs only within the TEE, and the decrypted plaintext data will not leak to untrusted external areas that the hardware device cannot monitor, thus preventing the plaintext data from being stolen or tampered with by malicious programs in the computing device.

[0059] This application does not limit the specific algorithm type used for decryption. The hardware device can select a symmetric encryption algorithm, an asymmetric encryption algorithm, or a national cryptographic algorithm to complete the encryption and decryption process of the target data according to the security level requirements and the negotiation results between the data requester and the data provider.

[0060] In some embodiments of this application, the hardware device may receive a data request from a computing device on the data requesting end before obtaining the target encrypted data. The data request may include identification information or query conditions for the target data that the computing device on the data requesting end wants to obtain, as well as the data usage method of the target data on the data requesting end. The identification information and query conditions of the target data are used to locate the original data stored on the data provider end, ensuring that the obtained data accurately matches the request from the requesting end; while the data usage method is used to indicate the scope of data use to the data provider end, thereby providing a basis for subsequent data security verification and access control.

[0061] After receiving a data request, the hardware device can securely forward the data request to the data provider through an encrypted transmission link. During the forwarding process, the content of the data request can also be encrypted using a pre-negotiated session key to prevent the data request from being illegally intercepted or tampered with during transmission.

[0062] After receiving an encrypted data request, the computing device at the data provider end will decrypt the request within the TEE through its connected hardware device, parse the specific data request content, locate the stored original data based on the parsed query conditions, encrypt the original data according to the agreement to obtain the target encrypted data, and then send it back to the hardware device connected to the data request end along the encrypted transmission link, thus completing the entire data request and response flow process.

[0063] It should be understood that after receiving a data request, the computing device at the data provider end will verify the legality and security of the data request. This includes verifying whether the data provider possesses the target data corresponding to the request, confirming the identity authentication information of the request source, and checking whether the data usage method complies with the access permissions of the target data. The computing device at the data provider end will only perform subsequent target data extraction and encryption operations after confirming that the data request has passed verification. If the verification fails, it will return a request error message to the data requesting end through hardware devices, preventing unauthorized access to sensitive data and further enhancing data security capabilities.

[0064] S300: Sends target data to the computing device.

[0065] In step S300, after the hardware device decrypts the target encrypted data within the TEE, it transmits the decrypted target data to the trusted application corresponding to the data-demanding computing device, thus completing the delivery of the target data. In some embodiments, if the data-demanding computing device itself does not deploy a trusted execution environment, the hardware device may only provide the decrypted target data to the legitimate application specified by the computing device through a preset security interface, while monitoring the access behavior of the target data throughout the process to prevent the target data from being called and stolen by other unauthorized applications.

[0066] In this way, hardware devices can utilize the processor in the computing device to process the corresponding target data, reducing the number of operations that the hardware device needs to perform, reducing the complexity of the hardware device, and thereby reducing the cost of the hardware device.

[0067] S400: Obtain the verification value of the security software in the computing device and pass the verification value of the security software to the TEE.

[0068] In step S400, the hardware device may continuously acquire the verification value of the security software in the computing device before sending the target data to the computing device at the data request end, and during the computing device's manipulation of the target data to perform corresponding computing tasks, and transmit the verification value of the security software to the TEE to verify the integrity and security of the computing device's operating environment.

[0069] Security software is software installed on computing devices that require data, used to monitor operations on target data within the computing device during runtime. The checksum is a hash value calculated using a hash algorithm based on the security software's runtime characteristics, used to uniquely identify the current running state of the security software.

[0070] In some embodiments, if the security software is tampered with by malicious programs, its corresponding verification value will also change, enabling the hardware device to promptly identify security risks in the computing device's operating environment. During the process of acquiring the verification value, the hardware device can directly read the corresponding parameters through a preset communication interface with the computing device, and the entire reading process only transmits the verification value into the TEE for verification, ensuring the security of the verification process itself.

[0071] In this way, the hardware can retain the processing of target data within the computing device on the data-demanding side, avoiding the need for the hardware to frequently participate in complex data operations, reducing the load on the hardware, and thus improving overall data processing efficiency and system response speed. Simultaneously, by deploying security software within the computing device, the hardware can monitor the access and manipulation of target data in real time, ensuring that data is only legitimately used in a trusted and secure environment.

[0072] In some embodiments of this application, the hardware device can also verify the hardware components and other software components in the computing device at the data request end through a preset detection mechanism. For example, by reading the feature information of the system firmware and kernel module and generating a hash value using a hash algorithm, the hardware device can compare it with a trusted benchmark value pre-stored in the TEE to identify whether there is a risk of the overall operating environment of the computing device being tampered with or implanted with malicious programs, further expanding the coverage of security verification and improving the security protection capability of the entire data usage process.

[0073] After verification is completed, if any component's verification result is found to be mismatched, the hardware device can immediately terminate the delivery of the target data or suspend open access to the target data, thus promptly blocking illegal data theft.

[0074] S500: In the TEE, the verification value of the security software is compared with the pre-stored verification value, and if the comparison results are inconsistent, it is determined that there is a data security risk.

[0075] In step S500, the hardware device can compare the current security software verification value obtained in the TEE with the baseline verification value pre-stored in the TEE to determine whether the security software has been illegally tampered with. If the comparison results are consistent, it indicates that the current operating environment of the computing device is secure, and the hardware device maintains the computing device's access rights to the current target data; if the comparison results are inconsistent, it is directly determined that there is a data security risk, and the hardware device can trigger a preset security response mechanism.

[0076] In one embodiment, the security response mechanism can be configured according to actual security level requirements. For example, it can forcibly revoke the computing device's access rights to the target data, encrypt and lock the currently open target data, and send risk alert information to the administrators of the data provider and data requester to remind the administrators to investigate malicious attacks in a timely manner and prevent sensitive target data from being illegally stolen or tampered with.

[0077] Through the processes described in steps S100 to S500, the hardware device deploys a Trusted Execution Environment (TEE). Within the TEE, the decryption and verification of encrypted data are completed. Simultaneously, the hardware device sends the decrypted data to the computing device, leveraging its computing power to improve the smoothness of data operations and reduce deployment costs. Furthermore, this application deploys security software for monitoring within the computing device, enabling the hardware device to perform integrity verification on the security software. This prevents the security software from becoming ineffective due to malicious tampering. By implementing end-to-end data protection from transmission, decryption, security software deployment, and security software verification, this approach overcomes the high deployment costs of existing solutions while further ensuring data security and smooth data manipulation to a certain extent.

[0078] The steps S100 to S500 described above will be explained in detail below with reference to the accompanying drawings.

[0079] Figure 3 This is a schematic diagram illustrating a data security verification process provided in an embodiment of this application. The following is based on... Figure 3 The content shown here is an exemplary illustration of the process by which the hardware device obtains the security software verification value in the embodiments of this application.

[0080] like Figure 3 As shown, the process of the hardware device obtaining the security software verification value in this embodiment may include the following steps S401 to S402.

[0081] S401: During the startup phase of the computing device, communicate with the computing device to obtain the storage address of the security software in the computing device.

[0082] In step S401, during the computing device startup phase, the hardware device can send an address query request to the computing device at the data request end to obtain the storage address information of the security software stored locally on the computing device. The storage address can be the starting address and length of the executable file corresponding to the security software in the storage medium of the computing device, which facilitates the subsequent extraction of the complete features of the security software.

[0083] S402: Send the storage address to the computing device to obtain the verification value of the security software in the computing device.

[0084] In step S402, the hardware device, based on the obtained storage address, can send the obtained storage address to the computing device before the computing device executes the target data manipulation task, so as to read the complete binary feature data of the security software from the storage medium of the computing device. After reading the feature data, the hardware device can perform hash calculation on the read complete feature data through a preset hash algorithm, and finally obtain the current verification value of the corresponding security software. Then, the obtained verification value is passed into the TEE to complete the subsequent comparison and verification.

[0085] In this embodiment, the hardware device can periodically acquire the verification value of the security software in the computing device to monitor in real time whether the security software has been tampered with or replaced, ensuring the continuous trustworthiness of the operating environment. For example, the hardware device can send the storage address to the computing device at preset intervals, such as 1 second, thereby obtaining the feature data in the corresponding storage address and thus obtaining the verification value of the security software in the computing device.

[0086] It should be noted that the verification process for other hardware and software in a computing device can also refer to the verification logic for security software. Similar integrity verifications can be performed on other critical components in a computing device, such as the operating system kernel, drivers, or basic firmware. This enables the hardware device to perform comprehensive integrity monitoring of the overall operating environment of the computing device, further improving the security and reliability of the data interaction process.

[0087] Through the above steps S401 to S402, the hardware device can continuously and dynamically verify the integrity of the security software during the startup and operation phases of the computing device, thereby verifying the security status of the computing device in real time during data interaction, effectively preventing malicious tampering or illegal replacement, and ensuring the trustworthiness and integrity of the data interaction environment.

[0088] Figure 4 This is a schematic diagram illustrating a configuration and usage constraint process provided in an embodiment of this application. The following is based on... Figure 4 The content shown here is an exemplary illustration of the process of configuring data usage constraints in a computing device using hardware in the embodiments of this application.

[0089] like Figure 4 As shown, the process of the hardware device obtaining the security software verification value in this embodiment may include the following steps S610 to S620.

[0090] S610: Receive usage constraints for the target data returned by the data provider via an encrypted transmission link.

[0091] In step S610, after establishing an encrypted transmission link, the hardware device can simultaneously receive the target encrypted data provided by the data provider and the usage constraints preset by the data provider for this transmission of the target data. These usage constraints may include limitations such as allowed usage scenarios, allowed operation types, maximum number of uses, effective usage duration, and data destruction period for the target data. These constraints are used to constrain the usage behavior of the computing device on the data requesting end regarding the target data, preventing the target data from being misused beyond its permitted scope.

[0092] In this embodiment, the constraints can be pre-configured by the computing device of the data provider according to the sensitivity level and open permissions of the target data. The content corresponding to the constraints can also be encrypted during transmission using the negotiated session key. The parsing is completed only within the TEE of the hardware device. The entire configuration process will not expose the constraint content to untrusted areas, thus preventing the constraints from being maliciously tampered with.

[0093] For example, the computing device at the data provider end can generate usage constraints for the corresponding data during the registration process of the generated data, and thereby generate metadata containing the usage constraints. The metadata describes the attribute information of the data stored in the computing device at the data provider end, such as data type, sensitivity level, and source identifier. In this embodiment, the metadata may also include the usage constraints corresponding to the data.

[0094] After receiving a data request initiated by a hardware device, the computing device at the data provider end can parse the information carried in the request, read the metadata containing usage constraints corresponding to the target data according to the target data matched in the request, and encrypt the metadata together with the target encrypted data before sending it to the hardware device connected to the data request end through an encrypted transmission link, thereby completing the secure transmission of usage constraints.

[0095] In some embodiments, after receiving a data request from a hardware device, the computing device at the data provider end can obtain the data usage method of the computing device at the data request end for the target data. Then, in combination with the metadata of the target data in the data provider end, it can verify the data usage method requested by the data request end and finally generate usage constraints that are suitable for this data interaction.

[0096] It should be understood that the computing device at the data provider end will only send the target encrypted data and its corresponding usage constraints to the hardware device when the coverage of the data usage requirements it receives is less than or equal to the preset usage constraints in the target data metadata, so as to ensure that data interaction always takes place within the preset security boundaries.

[0097] Taking the usage constraints of target data as an example, if the maximum number of uses preset in the metadata is 10 times, and the data requester requests 15 times, the data provider can reject the request; however, if the requested number of uses is 5 times, which is within the preset range, the data provider can generate a usage constraint with a maximum number of uses of 5 times, and send it to the hardware device along with the target data through an encrypted transmission link.

[0098] S620: Sends the received usage constraints to the computing device to configure the security software in the computing device.

[0099] In step S620, after receiving the usage constraints of the target data, the hardware device can first pass the usage constraints to the security software in the computing device before sending the target data to the computing device that requests the data, so as to configure the security software in the computing device, and then control the subsequent data access behavior according to the usage constraints.

[0100] In this embodiment, the security software needs to manage all operations of the computing device to access and use target data in accordance with the usage constraints issued by the hardware device. For example, when the computing device initiates a request to access target data, the security software will first verify whether the operation meets the usage constraints. Only after the verification is passed will the operation be allowed to execute. If the operation does not meet the constraints, the software will directly intercept the operation and report the abnormal event to the hardware device.

[0101] For example, if a constraint limits the maximum number of times the target data can be used to five times, the security software will increment the usage count after each legitimate use. When the count reaches the five-times limit, the security software will directly block all subsequent access operations to the target data and report the count exceeding the limit event to the hardware device, triggering a security response. If a constraint limits the effective usage time of the target data, the security software will automatically disable the computing device's access to the target data after the time expires and work with the hardware device to encrypt, lock, or securely destroy the target data.

[0102] After receiving the usage constraints, the hardware device will also store a backup of the usage constraints in the TEE. This backup is used to periodically verify whether the constraint content stored in the security software has been maliciously tampered with. If the constraint content in the security software is found to be inconsistent with the backup, a preset security response mechanism will be triggered to further ensure the effectiveness and reliability of the usage constraints.

[0103] Through steps S610 to S620, the hardware device can complete the secure transmission and configuration of target data usage constraints between the data provider and the data demander, realizing permission control of the target data throughout the entire process from transmission to use. This allows the data provider to flexibly and accurately constrain the scope of target data usage, effectively preventing the target data from being abused by the computing devices of the data demander beyond their permissions, and further improving the security protection system for the entire data lifecycle.

[0104] Figure 5 This is a flowchart illustrating a negotiated encryption strategy provided in an embodiment of this application. The following is based on... Figure 5 The content shown here serves as an exemplary illustration of the process by which the hardware device negotiates the encryption strategy in the embodiments of this application.

[0105] like Figure 5 As shown, the hardware device negotiation encryption strategy process in this embodiment may include the following steps S201 to S202.

[0106] S201: Sensitivity level of the requested target data.

[0107] In step S201, after receiving a target data request from the data requesting party, the hardware device can parse the request to determine the sensitivity level of the target data to be acquired. The sensitivity level is typically pre-defined by the data provider during the data registration phase based on the data's confidentiality and scope of influence. For example, sensitivity levels can be divided into multiple levels such as public, internal, sensitive, and confidential, with different sensitivity levels corresponding to different security encryption strength requirements.

[0108] In some embodiments, the hardware device may send a query request to the data provider to obtain the sensitivity level information of the target data; alternatively, the hardware device may directly read the sensitivity level from local cache or metadata pre-delivered by the data provider. After obtaining the sensitivity level, the hardware device can match the corresponding security baseline based on the level, providing a decision-making basis for subsequent negotiation of encryption strategies.

[0109] S202: Based on the sensitivity level of the requested target data, negotiate with the data provider through the encrypted transmission link to adjust the encryption algorithm of the encrypted transmission link.

[0110] In step S202, the hardware device, based on the sensitivity level of the acquired target data, matches the corresponding security level's encryption algorithm, key length, and encryption process to generate a preliminary encryption strategy. This strategy is then sent to the data provider's computing device via a pre-defined encryption negotiation channel. The data provider confirms whether the encryption strategy meets its own security specifications, thus completing the encryption strategy negotiation and determination. After the encryption strategy negotiation is complete, the hardware device can apply the negotiated encryption algorithm and key configuration to the current encrypted transmission link, performing adaptive encryption on all subsequently transmitted data.

[0111] For example, for target data with a high level of sensitivity, the hardware device will negotiate and select a longer key length and a more secure encryption algorithm, such as using asymmetric encryption algorithms or attribute-based encryption algorithms, to improve the security of data transmission within an acceptable range of performance loss. For target data with a lower level of sensitivity, a faster encryption algorithm can be selected, such as using a symmetric encryption algorithm, to reduce the performance loss caused by the encryption and decryption process and balance the security of data interaction with transmission efficiency.

[0112] Through the above steps S201 to S202, the hardware device can dynamically negotiate the encryption strategy according to the sensitivity of the target data itself. It will not consume too much unnecessary computing and transmission resources due to excessive encryption, nor will it reduce the security protection level of highly sensitive data for the sake of efficiency. It achieves a flexible balance between security and operating efficiency and adapts to the interaction needs of different types of data.

[0113] Figure 6 This is a schematic diagram illustrating a security verification process for an embodiment of this application. The following is based on... Figure 6 The content shown here is an exemplary illustration of the process by which a hardware device verifies the security of a computing device in the embodiments of this application.

[0114] like Figure 6 As shown, the process of hardware device verifying the computing device at the data request end in this embodiment may include the following steps S101 to S103.

[0115] S101: During the startup phase of the computing device, communicate with the computing device to obtain the check values ​​of the computing device's Basic Input / Output System (BIOS) and Operating System (OS).

[0116] In step S101, the hardware device can establish a basic communication connection with the computing device during the startup initialization process of the computing device at the data request end, initiate a feature extraction request to the computing device, and obtain feature data of the basic input / output system BIOS and operating system OS kernel files stored in the corresponding storage area of ​​the computing device.

[0117] Based on the read feature data, the hardware device calculates the current checksum of the corresponding BIOS and operating system (OS) using a preset hash algorithm. During the reading process, the hardware device only extracts the feature data for hash calculation and does not transmit the complete original data of the BIOS and operating system to the outside, thus avoiding the leakage of core system file information.

[0118] In this embodiment, the process of converting feature data into a verification value in the hardware device can be consistent with the verification calculation logic of the security software in the aforementioned embodiment. A hash value that identifies the current state is generated by a preset hash algorithm, ensuring the universality and consistency of the verification process. There is no need to deploy an additional dedicated feature calculation module, which reduces the complexity of the solution implementation.

[0119] S102: In the TEE, the BIOS and OS check values ​​are matched with the corresponding preset check values. When both the BIOS and OS check values ​​match the corresponding preset check values, the computing device is allowed to obtain data from the data provider.

[0120] In step S102, after obtaining the BIOS and OS verification values, the hardware device can use TEE to compare and match them with the pre-stored BIOS benchmark verification value and OS benchmark verification value to determine whether the core system components have been illegally tampered with.

[0121] If the checksums of both the BIOS and the OS match the corresponding baseline values, it indicates that the core operating environment of the computing device has not been tampered with. The hardware device will allow the computing device to initiate a target data acquisition request to the data provider through the hardware device and carry out the subsequent data interaction process normally.

[0122] By verifying the integrity of core system components within the computing device at the data request end during the startup phase, the hardware device can complete a preliminary verification of the security status of the computing device before the formal start of data interaction, identify operating environments with the risk of malicious tampering in advance, and prevent sensitive data from flowing into untrusted computing devices from the source.

[0123] S103: When it is determined that at least one of the checksums of the BIOS and the OS does not match the preset checksum, a message is sent to the computing device to configure the security software in the computing device to perform an interception operation on the data request.

[0124] In step S103, when the BIOS or OS check value is found to be inconsistent with the preset baseline value, it indicates that the core operating environment of the computing device has changed. At this time, performing data operations poses a great security risk. The hardware device will immediately block the current data interaction process, reject the connection establishment request of the computing device on the data request side, and issue a security instruction to the computing device to configure security software to directly block all subsequent access requests for target data. At the same time, the security anomaly event will be reported to the user and management terminal to remind the administrator to conduct risk investigation and handling, thereby preventing the leakage of sensitive data from the source and ensuring the overall security of data interaction.

[0125] In this embodiment of the application, the hardware device can also periodically re-verify the BIOS and OS check values ​​during the operation of the computing device on the data demand side, promptly identify illegal tampering that occurs during operation, continuously ensure the security of the computing device's operating environment, and avoid data security risks caused by malicious tampering of the core system after the device starts up.

[0126] Through steps S101 to S103, the hardware device can complete the integrity verification of the core operating environment of the computing device before the data interaction begins, and continuously monitor the security status of the operating environment through periodic re-verification, blocking the interaction process that may be tampered with in advance, reducing the possibility of sensitive data leakage from the source, and improving data security during the data interaction process.

[0127] Figure 7 This is a schematic diagram illustrating a process for generating behavior logs, provided as an embodiment of this application. The following is based on... Figure 7 The content shown here is an exemplary description of the process by which the hardware device generates behavior logs in the embodiments of this application.

[0128] like Figure 7 As shown, the process of generating behavior logs by the hardware device in this embodiment may include the following steps S710 to S740.

[0129] S710: Acquire the behavior logs of computing devices on the data request side.

[0130] In step S710, the hardware device can collect all operation behavior data of the computing device on the target data through security software. The operation behavior data may include information such as operation initiation time, operation type, operation applicant, and operation result. After the computing device completes its operation on the target data, the security software can summarize the operation behavior data to form a behavior log of the computing device on the target data and send it to the hardware device.

[0131] It should be understood that during the collection of operational behavior data, the security software only records the characteristic information of the operation and does not export the original content of the target data at the same time, so as to achieve operation traceability and avoid sensitive data leakage with logs.

[0132] S720: Generates data flow reports based on behavior logs.

[0133] In step S720, after receiving the behavior logs summarized and reported by the security software, the hardware device can integrate and standardize the behavior logs within the TEE, and finally generate a data flow report that meets the format requirements of the data provider.

[0134] In this embodiment of the application, the data circulation report is used to fully record all operations and circulation processes of the target data throughout the entire data interaction cycle, providing complete and reliable original evidence for subsequent security audits and risk tracing.

[0135] The process of hardware devices performing log consolidation and report generation can be completed within the TEE, avoiding the exposure of the original log content to untrusted areas of the computing device and reducing the risk of behavior logs being illegally stolen or tampered with during processing.

[0136] S730: Determine the closed-loop status of the requested data flow based on the data flow report.

[0137] In step S730, the hardware device can verify whether the entire data interaction process is executed in accordance with the preset usage constraints based on the generated data circulation report. After confirming that all operations meet the requirements, all agreed processes have been completed, and data use has been terminated according to the constraints and destroyed or recycled, the hardware device can determine that the data interaction has formed a complete circulation loop.

[0138] If the verification reveals operation records that exceed the constraints or failure to complete the agreed terminal handling process, it will be determined that the circulation loop has not been formed. The hardware device will trigger the corresponding risk warning mechanism to handle the situation, send a risk alarm to the data provider, and block subsequent data access requests.

[0139] S740: Synchronize behavior logs, data flow reports, and flow closed-loop status to the TEE.

[0140] In step S740, after obtaining the behavior logs, data circulation reports, and circulation closed-loop status, the hardware device can encrypt and store these data inside the TEE of the hardware device for subsequent security audits and risk tracing. All log data reading and query operations must be authorized and verified by the hardware device, and the access process is fully traceable, further ensuring the security and integrity of the behavior log data itself, and making the security management of the entire data lifecycle feasible and traceable.

[0141] Simultaneously, the hardware can encrypt the aforementioned content and synchronously transmit it back to the data provider for archiving, facilitating the data provider's retrospective audit of the entire process. Since the entire process from log collection and report generation to storage and transmission is completed under the protection of a trusted execution environment, neither the behavior logs nor the circulation reports can be tampered with by external malicious programs, ensuring the integrity and credibility of the traceability data itself and providing reliable support for data security auditing and tracing violations.

[0142] Through steps S710 to S740, the hardware device can achieve complete recording and closed-loop verification of the target data's full interactive cycle operation behavior, making data security management traceable and auditable. Once a violation or data leakage risk occurs, the risk link can be quickly located, effectively improving the efficiency of data security incident handling and further improving the closed-loop management system for data security protection throughout the entire life cycle.

[0143] Figure 8 This is a schematic diagram of a data risk monitoring system provided in an embodiment of this application. Figure 9 This is a schematic diagram illustrating the interaction between the data request end and the hardware device provided in an embodiment of this application. The following is based on... Figure 8 and Figure 9 The content shown is an exemplary description of the data risk monitoring system provided in the embodiments of this application.

[0144] Corresponding to the aforementioned embodiments of the data risk monitoring method, this application also provides an embodiment of a data risk monitoring system. For example... Figure 8 As shown, the data risk monitoring system 800 provided in this application embodiment may include a computing device 810 and a hardware device 820.

[0145] The hardware device 820 includes a first memory 821, a first processor 822, and a first communication interface 823. The first memory 821 is used to store first program instructions that can be executed on the first processor 822, and the first communication interface 823 is used for communication connection with the computing device 810 to realize the interactive transmission of instructions.

[0146] The hardware device 820 may also include a Trusted Execution Environment (TEE) to provide an isolated and secure operating space for the first processor 822. In this embodiment, the TEE may include some or all of the operating resources of the first memory 821 and the first processor 822. All operations related to security verification, encryption / decryption, and sensitive data storage can be completed in the TEE, which is isolated from the operating system environment of the computing device, preventing malicious programs from stealing or tampering with sensitive data and improving the overall system's security protection capabilities.

[0147] When the first processor 822 runs the computer program, it can execute the data risk monitoring and processing steps described in any of the foregoing embodiments to complete data security management operations such as usage constraint transmission, encryption policy negotiation, device security verification, and behavior log generation and storage.

[0148] The computing device 810, serving as the operating platform for data requests, may include a second memory 811, a second processor 812, and a second communication interface 813. The second memory 811 stores second program instructions, and the second communication interface 813 establishes a communication connection with the hardware device 820 to receive control commands issued by the hardware device. When the second processor 812 executes the second program instructions stored in the second memory 811, it can cooperate with the hardware device to complete the security control of target data access operations, including data collection and reporting of operational behavior, and interception of abnormal operations, forming a collaborative protection mechanism with the hardware device's security control mechanism.

[0149] In one example, the first communication interface 823 and the second communication interface 813 can be one of PCIe interface, USB interface or other high-speed hardware communication interface, which realizes high-speed data interaction between hardware device and computing device through direct connection, without going through general network transmission link, reducing the risk of eavesdropping during data transmission, while ensuring the transmission efficiency of data interaction.

[0150] In another embodiment, the computing device 810 may also have a built-in target data storage area, which is also set within the protection range of the TEE. During the operation of the target data, the computing device 810 can cache the target data in the storage area without writing the target data to the local storage of the computing device 810. This further prevents the target data from being illegally read by malicious programs of the computing device 810, reduces the exposure range of sensitive data, and lowers the risk of data leakage.

[0151] In this embodiment, the hardware device 820 is a physically pluggable independent hardware carrier with an independent processing chip and trusted execution environment. All core security control operations are completed in the trusted execution environment provided inside the hardware device 820, and sensitive data will not be exposed to the external computing device 810. The core control process is isolated from the normal operating environment of the computing device 810 at the hardware level, which can effectively resist attacks launched by malicious software from the computing device 810 and prevent sensitive security data such as control parameters and behavior logs from being stolen or tampered with.

[0152] In some embodiments of this application, the computing device 810 can be used to execute another data risk monitoring method in conjunction with the data risk monitoring method executed by the hardware device 820. The computing device 810 is communicatively connected to the hardware device 820 via a second communication interface 813.

[0153] The computing device 810 can receive target data sent by the hardware device 820 during operation; wherein, the target data is the data obtained by the hardware device 820 after decrypting the target encrypted data through TEE, and the target encrypted data is the data obtained by the hardware device 820 from the data provider.

[0154] During the process of receiving and processing target data, the computing device 810 can monitor the operations on the target data through installed security software; the security software is the software installed in the computing device 810.

[0155] During monitoring, the computing device 810 can send the security software's file data to the hardware device 820, enabling the hardware device 820 to obtain the security software's verification value. The hardware device 820 then compares the security software's verification value with pre-stored verification values ​​in the TEE (Transfer Equipment Environment). It should be understood that the security software's file data refers to the original file corresponding to the security software, or it can be the verification value generated by the computing device 810 after verifying the security software based on a preset algorithm. This application embodiment does not limit the specific form of the file data.

[0156] like Figure 9 As shown in this embodiment, the computing device 810 and the hardware device 820 are connected in communication. The hardware device 820, in response to a request from the computing device 810, establishes an encrypted transmission link with the data provider corresponding to the request via a TEE. After establishing the encrypted transmission link, the hardware device 820 can obtain the target encrypted data returned by the data provider through the link, and after completing decryption and integrity verification within the TEE, send the corresponding target data to the computing device 810.

[0157] After receiving the target data sent by the hardware device, the computing device 810 can use its internally installed security software to monitor and verify the access behavior of the computing device 810 to the target data in real time, ensuring that the data is used only within the authorized scope.

[0158] When the computing device 810 performs an access operation on the target data, the hardware device 820 can obtain the verification value of the security software and transmit it to the TEE for secondary verification. If the verification value matches the pre-stored verification value, the computing device 810 is allowed to continue to perform subsequent data access operations. If the verification value does not match, the hardware device 820 can confirm that there is a data security risk, block the data access operation of the computing device 810, and generate a security alarm.

[0159] Figure 10 This is a schematic diagram of a computing device provided in an embodiment of this application.

[0160] like Figure 10As shown, the computing device 1000 includes a processor 1001 and a memory 1002. Exemplarily, the computing device 1000 may also include a communications interface 1003 and a communications bus 1004.

[0161] The processor 1001, memory 1002, and communication interface 1003 communicate with each other via communication bus 1004. The communication interface 1003 may include a transmitter and receiver for communicating with other devices or communication networks, and may be a wired interface (port), such as a fiber distributed data interface (FDDI) or a gigabit Ethernet interface (GE).

[0162] In this embodiment, the communication interface 1003 can be used to enable communication between the computing device 1000 and the terminal device operated by the user, so that the computing device 1000 can receive the operation input by the user, provide a visual interface for the terminal device and execute the operation to generate the corresponding operation result, so as to configure the interface of the management system deployed in the computing device 1000.

[0163] In some embodiments, the processor 1001 is used to execute program 1005, specifically executing the relevant steps in the above-described embodiments of the data risk monitoring method applied to hardware devices, or executing the relevant steps in the above-described embodiments of the data risk monitoring method applied to computing devices. Specifically, program 1005 may include program code, which includes computer-executable instructions.

[0164] For example, processor 1001 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement some embodiments of this application. Computing device 1000 may include one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs. The CPU may be a single-core CPU or a multi-core CPU.

[0165] In some embodiments, memory 1002 is used to store program 1005. Memory 1002 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0166] Specifically, program 1005 can be called by processor 1001 to cause computing device 1000 to execute a data risk monitoring method applied to hardware device, or to execute a data risk monitoring method applied to computing device.

[0167] Some embodiments of this application provide a computer-readable storage medium storing at least one executable instruction that, when executed on a computing device 1000, causes the computing device 1000 to perform the aforementioned data risk monitoring method applied to a hardware device, or to perform the aforementioned data risk monitoring method applied to a computing device.

[0168] For example, the computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device.

[0169] The beneficial effects that the readable storage medium provided in some embodiments of this application can achieve can be referred to the beneficial effects of the corresponding data risk monitoring method provided above, and will not be repeated here.

[0170] The embodiments described above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solution of this application should be included within the scope of protection of this application.

Claims

1. A data risk monitoring method, characterized in that, Applied to a hardware device, the hardware device is used to communicate with a computing device through a first communication interface, and the hardware device is deployed with a Trusted Execution Environment (TEE); The method includes: An encrypted transmission link is established with the data provider through the TEE; The target encrypted data is obtained by acquiring the data returned by the data provider through the encrypted transmission link and then decrypting it in the TEE to obtain the target data. Send the target data to the computing device; Obtain the verification value of the security software in the computing device and transmit the verification value of the security software to the TEE; wherein, the security software is software installed on the computing device and is used to monitor the operations on the target data in the computing device during runtime; In the TEE, the verification value of the security software is compared with the pre-stored verification value, and if the comparison result is inconsistent, it is determined that there is a data security risk; wherein, the pre-stored verification value is stored in the TEE.

2. The method according to claim 1, characterized in that, The method further includes: During the startup phase of the computing device, communication is established with the computing device to obtain the storage address of the security software in the computing device; Accordingly, obtaining the verification value of the security software in the computing device includes: At preset time intervals, the storage address is sent to the computing device to obtain the verification value of the security software in the computing device.

3. The method according to any one of claims 1-2, characterized in that, Before the step of obtaining the target encrypted data returned by the data provider through the encrypted transmission link, the method further includes: The method of using data to send the required target data to the data provider through the encrypted transmission link.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: Through the encrypted transmission link, the user receives the usage constraints for the target data returned by the data provider. The received usage constraints are sent to the computing device to configure the security software in the computing device.

5. The method according to any one of claims 1-4, characterized in that, Before the step of obtaining the target encrypted data returned by the data provider through the encrypted transmission link, the method further includes: Based on the sensitivity level of the target data to be requested, the encryption algorithm of the encrypted transmission link is adjusted through negotiation with the data provider.

6. The method according to any one of claims 1-5, characterized in that, Before the step of establishing an encrypted transmission link with the data provider via the TEE, the method further includes: During the startup phase of the computing device, communication is established with the computing device to obtain the check values ​​of the computing device's Basic Input / Output System (BIOS) and Operating System (OS). In the TEE, the checksums of the BIOS and the OS are matched with the corresponding preset checksums, and when the checksums of the BIOS and the OS both match the corresponding preset checksums, the computing device is allowed to obtain data from the data provider.

7. The method according to claim 6, characterized in that, The method further includes: When it is determined that the checksum of at least one of the BIOS and the OS does not match the preset checksum, information is sent to the computing device to configure the security software in the computing device to perform a data request interception operation.

8. A hardware device, characterized in that, The hardware device includes a first memory, a first processor, and a first communication interface. The first memory is used to store first program instructions, and the first communication interface is used to communicate with an external computing device. The hardware device also deploys a Trusted Execution Environment (TEE). The first processor is used to execute the first program instructions, causing the hardware device to perform the data risk monitoring method as described in any one of claims 1-7.

9. A data risk monitoring method, characterized in that, Applied to a computing device, the computing device is connected to an external hardware device via a second communication interface, and the hardware device is equipped with a Trusted Execution Environment (TEE). The method includes: Receive target data sent by the hardware device; wherein, the target data is data obtained by the hardware device after decrypting target encrypted data through the TEE, and the target encrypted data is data obtained by the hardware device from the data provider. Operations targeting the target data are monitored by installed security software; the security software is software installed on the computing device. The file data of the security software is sent to the hardware device, so that the hardware device can obtain the verification value of the security software and compare the verification value of the security software with the pre-stored verification value in the TEE.

10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the data risk monitoring method as described in claim 9.

Images