Transaction privacy system for a smartphone

Abstract

The application relates to the technical field of information security, and discloses a transaction privacy protection system of a smart phone, which comprises a system initialization module, a life cycle log management module, a service access control module and a remote state proof module. The system initialization module is used for establishing a unique identity trust root at the starting point of the life cycle of the smart phone. The life cycle log management module is used for making non-falsifiable records of key events of the physical state of the bound device, thereby forming a secure event log chain. The service access control module is used for performing access control on internal high-privilege services based on the integrity of the log chain. The remote state proof module is used for generating a cryptographic proof of the current state and the historical integrity of the device in response to an external verification request. The application realizes the endogenous control of the forced association of the historical integrity and the current function permission of the device by constructing a non-falsifiable log chain based on a hardware trust root, helps to solve the defect that the traditional security mechanism can only detect the instantaneous state, and provides traceable whole-life-cycle security guarantee for the transaction of the smart phone.

Description

Technical Field

[0001] This invention relates to the field of information security technology, specifically to a transaction confidentiality system for smartphones. Background Technology

[0002] The transaction confidentiality system of a smartphone refers to a set of technical mechanisms deployed inside the smartphone to ensure the confidentiality and integrity of the entire process of financial transactions such as mobile payments. The core objective of the system is to ensure that sensitive information such as user credentials and transaction data can be effectively resisted from theft and tampering by malicious software or illegal physical contact during the input, processing, storage and transmission processes, thereby providing a safe and reliable execution environment for mobile payments.

[0003] To achieve transaction confidentiality, existing technologies mainly rely on a combination of hardware isolation and software detection. At the hardware level, trusted execution environment technology is commonly used to create a secure area within the processor that is isolated from the main operating system. This area is used to perform core operations such as payment credential verification and transaction signing. At the software level, when transaction applications start up or execute critical steps, they call the interfaces provided by the system to detect whether the device has been granted root privileges or whether there are known malicious programs. This serves as the basic basis for judging whether the current operating environment is secure.

[0004] However, existing transaction confidentiality systems lack awareness of historical risks. Their security assessment mechanisms are essentially instantaneous state detection, reflecting only the device's state at the moment of detection execution, but unable to trace integrity breaches the device has experienced. Attackers can exploit this flaw to gain root access to the device, implant potential threats, and then use technical means to restore the device's surface system state to pass security detection. Transaction confidentiality cannot be guaranteed on such substantially compromised devices, and users' financial assets face significant risks caused by historical security vulnerabilities. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a transaction confidentiality system for smartphones, aiming to solve the problem that existing smartphone transaction confidentiality systems rely solely on instantaneous detection of the device's current operating status, and cannot trace and verify the historical integrity throughout the device's lifecycle, thus resulting in an unreliable foundation for transaction confidentiality.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a transaction confidentiality system for smartphones, comprising: The system initialization module is configured to establish a unique root of identity trust for the smartphone at the beginning of its lifecycle. The lifecycle log management module, coupled to the system initialization module, is configured to perform tamper-proof log recording of predefined key events, including the physical state of the device, forming a security event log chain; The service access control module, coupled to the lifecycle log management module, is configured to perform access control on high-privilege services within the smartphone based on the integrity of the security event log chain. The remote state verification module, coupled to the lifecycle log management module, is configured to respond to verification requests from external devices and generate a cryptographic proof that can prove the current state and historical integrity of the smartphone.

[0007] Preferably, the lifecycle log management module includes: The hardware state trusted acquisition unit is configured to acquire the physical identifiers of key hardware components in the smartphone to generate a hardware state snapshot. An atomic log generation unit is configured to bind key event information with the hardware state snapshot to generate atomic log entries; The log chain maintenance and storage unit is configured to sign and hash the atomic log entries to maintain the security event log chain.

[0008] Preferably, the atomic log entries include: Event type, timestamp of the event, and hardware state snapshot taken when the event occurred.

[0009] The preferred option is...

[0010] Preferably, the log chain maintenance and storage unit is further configured as follows: A cryptographic hash function is used to calculate the hash value of the previous signed event proof in the security event log chain. Using the device private key established by the system initialization module, the hash value and the concatenated data of the current atomic log entry are digitally signed to generate the current signed event proof.

[0011] Preferably, the service access control module includes: The log chain integrity verification unit is configured to perform a comprehensive cryptographic integrity verification on the security event log chain. The service gating decision unit is configured to authorize or deny the high-privilege service based on the result of the cryptographic integrity verification.

[0012] Preferably, the log chain integrity verification unit is configured to perform the cryptographic integrity verification when a high-privilege service call request is received; The service gating decision unit is configured to authorize the high-privilege service invocation request only when the cryptographic integrity verification passes.

[0013] Preferably, the remote status verification module includes: The challenge-response processing unit is configured to receive a one-time random challenge code from the external device; The dynamic proof generation unit is configured to integrate the state of the random challenge code with the state of the security event log chain to generate the cryptographic proof.

[0014] Preferably, the cryptographic proof is a dynamic remote proof, and the dynamic proof generation unit generates the dynamic remote proof by digitally signing a dynamic proof payload using the device's private key. The dynamic proof payload includes: a one-time random challenge code, the latest signed event proof in the security event log chain, and a Boolean value indicating the integrity status of the security event log chain.

[0015] Preferably, the system initialization module includes a device identity anchoring unit, which is configured as follows: A pair of asymmetric keys is generated within the trusted execution environment of the smartphone, and the device private key is securely stored. Collaborate with the manufacturer's certificate issuing equipment to generate a digitally signed device genesis certificate containing the device's public key and key hardware identifiers.

[0016] Preferably, the predefined key events include at least one of the following: System update events, security policy change events, and critical service call events.

[0017] This invention provides a transaction confidentiality system for smartphones. It has the following beneficial effects: 1. This invention establishes a unique identity trust root bound to the hardware at the beginning of the smartphone's lifecycle through the system initialization module. Based on this trust root, the lifecycle log management module constructs an immutable secure event log chain using digital signature and hash chain technology. This scheme records all key events from the device's manufacturing process to the present, achieving complete traceability of the device's entire lifecycle history. This effectively prevents attackers from erasing traces after an attack by restoring factory settings, thus making up for the shortcomings of traditional security mechanisms that can only detect the current state.

[0018] 2. This invention sets up a service access control module, which uses the cryptographic integrity of the security event log chain as a mandatory prerequisite for the execution of high-privilege services (such as mobile payment). Before performing sensitive operations, the system will verify the signature and hash link of the entire log chain to ensure that the device history has not been tampered with. This inherent security gating mechanism, which directly binds the clean state of the history with the current functional permissions, helps devices with compromised integrity to execute critical transactions, thereby improving the system's defense-in-depth capabilities.

[0019] 3. This invention, through a remote status verification module, can respond to external verification requests and generate a dynamic remote verification certificate containing a one-time random challenge code, the latest log record, and the integrity status. This certificate is signed using the device's unique private key, ensuring its authenticity, timeliness, and unforgeability. This provides a reliable trust credential for smartphones to communicate with third-party entities such as bank servers, enabling them to remotely and reliably verify the device's current status and historical integrity, thus providing a solid cryptographic foundation for secure cross-entity interaction. Attached Figure Description

[0020] Figure 1 This is a system architecture diagram of the present invention; Figure 2 This is a system initialization flowchart for the present invention; Figure 3 This is a flowchart of the lifecycle log management process of the present invention; Figure 4 This is a service access control flowchart of the present invention; Figure 5 This is a flowchart of the remote status verification process of the present invention. Detailed Implementation

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

[0022] See attached document Figure 1 , Figure 1 This is a functional module architecture diagram of a device integrity self-certification system according to an embodiment of the present invention. The present invention provides a device integrity self-certification system, which can be deployed in an electronic device to establish an end-to-end, hardware root of trust-based lifecycle integrity certification and service control mechanism for the electronic device. The system may include: The system initialization module 100 establishes a unique and tamper-proof root of identity for the device at the beginning of its lifecycle.

[0023] The lifecycle log management module 200, coupled with the system initialization module 100, is responsible for recording reliable, atomically bound, and tamper-proof logs of predefined key events during the device lifecycle.

[0024] The service access control module 300 is coupled to the lifecycle log management module 200 and is responsible for controlling access to high-privilege services within the electronic device based on the integrity of the logs maintained by the lifecycle log management module 200.

[0025] The remote status verification module 400, coupled with the lifecycle log management module 200, is responsible for responding to verification requests from external devices and generating a time-sensitive cryptographic proof that can prove the current status and historical integrity of the electronic device.

[0026] The operation of a system depends on a specific hardware operating environment, which may include: A central processing unit with hardware isolation mechanisms, such as a processor using ARMT rust Zone technology, can separate a secure processing environment from an insecure processing environment. The secure storage area has its physical access strictly limited to a secure processing environment; Main memory, intended for use in insecure processing environments; One or more critical hardware components that can be securely accessed, such as flash memory controllers, screen controllers, battery management chips, etc., are able to provide unique physical identifiers; And communication interfaces for data interaction with external devices, such as near field communication (NFC) modules, Bluetooth modules, or QR code scanning modules.

[0027] The system's operation also depends on a specific software runtime environment, which is divided into two domains by the central processing unit's hardware isolation mechanism.

[0028] One is the non-security side software environment, which runs the main operating system (RichOS) and deploys at least one user-side agent application (Client Application, CA). The user-side agent application is responsible for handling user interactions and initiating service requests to the security side.

[0029] The second is the software environment on the security side, also known as the Trusted Execution Environment (TEE), on which a secure operating system (Secure OS) runs.

[0030] The specific functional implementation of the lifecycle log management module 200, service access control module 300, and remote status verification module 400 of the present invention are all embodied in one or more trusted applications (TAs) running in a Trusted Execution Environment (TEE).

[0031] Secure communication between the non-secure user-side agent application and the secure trusted application is achieved through the Secure Monitor Call mechanism provided by the central processing unit.

[0032] See attached document Figure 2 The system initialization module 100 functions to establish a unique, hardware-based root of trust for the electronic device throughout its lifecycle. This function is executed in a controlled, secure manufacturing environment to ensure the integrity and confidentiality of the initialization process. The system initialization module 100 can be specifically implemented through a device identity anchoring unit 110, which is embodied as a trusted application running within the trusted execution environment (TEE) of the electronic device.

[0033] When the device identity anchoring unit 110 is invoked, it first calls a hardware true random number generator (TRNG) within the Trusted Execution Environment (TEE) to generate a device-unique asymmetric key pair that conforms to a predetermined cryptographic standard (e.g., ECCP-256 or RSA2048). , ).

[0034] Device private key At the time of generation, the device is configured with non-exportable and non-modifiable attributes by the Trusted Execution Environment (TEE) security policy, and is securely stored in encrypted form in a tamper-proof storage area within the TEE, for example, by melting down a one-time programmable (OTP) storage unit or by hardware-derived encryption protection. This mechanism ensures the security of the device's private key. Throughout its entire lifecycle, it never leaves the security boundary of the Trusted Execution Environment (TEE) and is uniquely bound to the physical hardware instance of the current electronic device.

[0035] After the key pair is generated, the device identity anchoring unit 110 will use the device public key. Securely exported from within the security boundary of a Trusted Execution Environment (TEE) to the manufacturer's certificate issuing device. The manufacturer's certificate issuing device uses its root private key. For a device containing a public key One or more sets of key hardware identifiers for devices The data set, along with other metadata, is digitally signed to generate a unique device genesis certificate for the electronic device. The certificate generation process can be represented by the following formula: ; In the formula, The final generated device genesis certificate; For a specific digital signature algorithm operation, such as Elliptic Curve Digital Signature Algorithm (ECDSA) or RSA Probabilistic Signature Scheme (RSA-PSS). The manufacturer's root private key; A set of one or more unique identifiers permanently embedded in the device hardware; The device public key generated by the device identity anchoring unit 110; This represents a deterministic data concatenation operation; This is a metadata field containing information such as device model, production date, and hardware version.

[0036] Generated device genesis certificate After issuance, the device genesis certificate is written back to a non-volatile, publicly readable storage area of ​​the electronic device, such as a specific partition of flash memory. It serves as the trusted starting point for all subsequent verification processes, used to prove the device's public key to any third party. The actual correspondence between the physical entity and the electronic device.

[0037] This implementation generates and securely stores a non-transferable device private key uniquely bound to the device hardware within a trusted execution environment. Combined with a genesis certificate issued by the manufacturer that cryptographically associates the device public key with the hardware physical identifier, it enables the construction of a root of trust for electronic devices that is solidified from their physical birth, globally verifiable, and cannot be tampered with or cloned. This provides a cryptographic foundation for the trusted recording and verification of all subsequent lifecycle events.

[0038] See attached document Figure 3 The Lifecycle Log Management Module 200 is designed to perform reliable, atomically bound, and tamper-proof log recording of predefined key events throughout the entire lifecycle of an electronic device.

[0039] The lifecycle log management module 200 is manifested as one or more trusted applications running in a Trusted Execution Environment (TEE), and may include a hardware status trusted acquisition unit 210, an atomic log generation unit 220, and a log chain maintenance and storage unit 230.

[0040] The hardware status trusted acquisition unit 210 is responsible for initiating query commands directly to one or more predefined critical hardware components through a trusted I / O path protected by the hardware isolation mechanism of the central processing unit.

[0041] Key hardware components, such as screen controllers, battery management chips, camera modules, or flash memory controllers, are identified by this unit. The unit acquires unique physical identifiers embedded within these key hardware components and constructs a hardware state snapshot from the set of all acquired identifiers. The structure can be represented by the following formula: ; In the formula, This is a snapshot of the hardware state. For the first Identification of each hardware component; For the first A unique physical identifier for each hardware component; Define the number of key hardware components.

[0042] The atomic log generation unit 220 is responsible for atomically binding the software-level information of a predefined critical lifecycle event to the physical state of the electronic device when the event occurs.

[0043] When a critical lifecycle event is triggered, the unit first invokes the hardware state trusted acquisition unit 210 to obtain a real-time snapshot of the current hardware state. Subsequently, the unit binds the event type information, the timestamp of the event occurrence, and the hardware state snapshot to generate an indivisible atomic log entry, the structure of which can be represented by the following formula: ; In the formula, For the first One atomic log entry; Event type; The timestamp of the event; A snapshot of the hardware state taken when the event occurred; Other data related to the event.

[0044] Predefined key lifecycle events may include, but are not limited to, one or more of the following combinations: System update events: such as the start, success, or failure of an over-the-air (OTA) update for the operating system; the application of security patches.

[0045] Application management events: such as the installation, uninstallation, or permission changes of applications with high privileges.

[0046] Security policy change events: such as enabling or disabling developer mode, unlocking the bootloader, and obtaining root privileges.

[0047] Device reset events: such as performing a factory reset or securely erasing user data.

[0048] Hardware change events: For example, if a critical hardware component (such as flash memory or camera module) is detected to have been replaced, it can be compared with the initial hardware snapshot.

[0049] Critical service call events: such as executing a mobile payment transaction or unlocking content protected by Digital Rights Management (DRM).

[0050] The log chain maintenance and storage unit 230 receives atomic log entries generated by the atomic log generation unit 220. To ensure the continuity and immutability of the logs, this unit first uses a defined cryptographic hash function, such as SHA-256, to calculate the previous signed event proof, obtaining a hash value that serves as a cryptographic pointer to the previous record.

[0051] Subsequently, the unit invokes the cryptographic service within the TEE, using the device private key established by the system initialization module 100 to digitally sign the concatenated data of the hash value and the current atomic log entry, generating the current signed event proof. The generation process can be represented by the following formula: ; In the formula, For the first A signed event proof; For a specific digital signature algorithm operation; The device's private key; For a given cryptographic hash function; Proof of the previous signed event in the log chain; This represents a deterministic data concatenation operation; This is the current atomic log entry.

[0052] For the first entry in the log chain, there is no logical preceding record to link to. As the starting point for establishing the trust chain, the required preceding hash value can be a predefined constant. As a preferred implementation, this preceding hash value can also be generated by hashing the device's genesis certificate, thereby cryptographically binding the root of trust of the entire log chain directly to the device's identity creation process. The first atomic log entry corresponding to this initial hash value can specifically record the "device initialization complete" event.

[0053] This implementation method achieves a logging mechanism that atomically binds software events to physical hardware states through a collaborative workflow consisting of trusted hardware state acquisition, atomic log generation, log chain maintenance, and storage. This not only ensures the authenticity and source reliability of each log entry but also guarantees the continuity, integrity, and immutability of the entire log history sequence through cryptographic hash chains and digital signature technology. See attached document Figure 4 The function of the service access control module 300 is to forcibly associate the integrity of the security event log chain maintained by the lifecycle log management module 200 with the access rights of the core services inside the electronic device, thereby establishing an endogenous security gating mechanism.

[0054] The service access control module 300 is manifested as one or more trusted applications running in a Trusted Execution Environment (TEE), which may specifically include a log chain integrity verification unit 310 and a service gating decision unit 320.

[0055] The log chain integrity verification unit 310 is responsible for performing a comprehensive cryptographic integrity verification on the security event log chain stored in the electronic device when invoked. The verification process starts from the latest record in the log chain and iterates backwards to verify each record until the initial record of the log chain.

[0056] For each record in the chain, the log chain integrity verification unit 310 performs two parallel verification operations: one is signature verification, and the other is hash link verification.

[0057] Only when the signatures of all records in the log chain are valid and the hash links between all adjacent records are consecutive and error-free can the unit determine that the entire log chain is in a complete state. The core verification logic can be expressed by the following formula: ; In the formula, This is a specific digital signature verification algorithm operation, the result of which is a Boolean value TRUE or FALSE; This is the device's public key, and its authenticity is verified by the device's genesis certificate. ensure; This serves as proof of the currently pending signed event. For a given cryptographic hash function; Proof of the previous signed event in the log chain; This represents a deterministic data concatenation operation; To prove from the currently signed events The atomic log entries parsed from the file.

[0058] The service gating decision unit 320 serves as a pre-security check logic for one or more high-privilege trusted applications (such as mobile payment applications or digital rights management applications) within the TEE. When the main operating system on the non-secure side initiates a service call request to these high-privilege trusted applications, the request is first intercepted by the service gating decision unit 320, which then drives the log chain integrity verification unit 310 to perform a complete log chain verification.

[0059] Upon receiving the verification result, if the result is complete, the service gating decision unit 320 authorizes the service request and passes it to the target high-privilege trusted application for continued execution. Conversely, if the verification result is incomplete, the unit immediately terminates the execution of the service request and returns a predefined error code indicating compromised device integrity to the upper-layer caller, thereby preventing any sensitive operations from being performed if the device's historical state is questionable.

[0060] This implementation establishes a unit that performs strict cryptographic integrity verification on the security event log chain and uses the verification result as a mandatory prerequisite for the execution of high-privilege trusted services. This directly binds the integrity of a device's historical behavior to its current access to core functions, creating an inherent security reward and punishment control mechanism. This ensures that only devices with a clean history and that have not been tampered with can perform high-security sensitive operations, thereby improving the security of the entire system.

[0061] See attached document Figure 5 The remote status verification module 400 is designed to respond to requests from external verification devices and generate a time-sensitive cryptographic proof that can prove the current status and historical integrity of the electronic device.

[0062] The remote state verification module 400 is manifested as one or more trusted applications running within a Trusted Execution Environment (TEE), and may specifically include a challenge-response processing unit 410 and a dynamic verification generation unit 420.

[0063] In one specific implementation, the challenge-response processing unit 410 is responsible for handling the initial interaction with the external verification device to ensure the timeliness of subsequent proof generation, thereby resisting replay attacks.

[0064] The challenge-response processing unit 410 receives a one-time random challenge code from an external verifier via a communication interface of an electronic device, such as a near-field communication (NFC) module or a Bluetooth module. After successfully receiving and verifying the format of the random challenge code, the unit securely transmits it to the dynamic proof generation unit 420.

[0065] After receiving the random challenge code, the dynamic proof generation unit 420 is responsible for integrating the device status information and generating the final cryptographic proof.

[0066] The dynamic proof generation unit 420 first obtains the latest signed event proof in the security event log chain Lchain maintained by the lifecycle log management module 200. At the same time, the unit calls the service access control module 300 to obtain the current cryptographic integrity status of the entire log chain.

[0067] Subsequently, the unit integrates the received random challenge code, the latest log proof obtained, and the log chain integrity status into a dynamic proof payload, the structure of which can be represented by the following formula: ; In the formula, To dynamically prove the load; A one-time random challenge code received and transmitted by the challenge-response processing unit 410; This serves as proof of the latest signed event in the log chain. This represents a deterministic data concatenation operation; A boolean or enumerated value representing the integrity status of the log chain.

[0068] Finally, the dynamic proof generation unit 420 calls the cryptographic service within the TEE and uses the device private key established by the system initialization module 100 to digitally sign the dynamic proof payload, generating the final dynamic remote proof. The generation process can be represented by the following formula: ; In the formula, This is the final generated dynamic remote proof; For a specific digital signature algorithm operation; The device's private key; The dynamic proof payload to be signed.

[0069] The generated dynamic remote proof is sent to an external verifier via a communication interface for subsequent verification and decision-making.

[0070] This implementation method ensures the timeliness of proof through a challenge-response mechanism, integrates the latest log records of the device with the complete historical log chain verification status, and uses the device's unique private key for signing. This achieves the ability to provide third parties with real-time, unforgeable, and dynamic remote proof that fully reflects the current status and historical integrity of the device, providing reliable trust credentials for the transfer and interaction of the device between different entities.

Claims

1. A transaction confidentiality system for smartphones, characterized in that, include: The system initialization module is configured to establish a unique root of identity trust for the smartphone at the beginning of its lifecycle. The lifecycle log management module, coupled to the system initialization module, is configured to perform tamper-proof log recording of predefined key events, including the physical state of the device, forming a security event log chain; The service access control module, coupled to the lifecycle log management module, is configured to perform access control on high-privilege services within the smartphone based on the integrity of the security event log chain. The remote state verification module, coupled to the lifecycle log management module, is configured to respond to verification requests from external devices and generate a cryptographic proof that can prove the current state and historical integrity of the smartphone.

2. The transaction confidentiality system for a smartphone according to claim 1, characterized in that, The lifecycle log management module includes: The hardware state trusted acquisition unit is configured to acquire the physical identifiers of key hardware components in the smartphone to generate a hardware state snapshot. An atomic log generation unit is configured to bind key event information with the hardware state snapshot to generate atomic log entries; The log chain maintenance and storage unit is configured to sign and hash the atomic log entries to maintain the security event log chain.

3. A transaction confidentiality system for smartphones according to claim 2, characterized in that, The atomic log entries include: Event type, timestamp of the event, and hardware state snapshot taken when the event occurred.

4. A transaction confidentiality system for smartphones according to claim 3, characterized in that, The log chain maintenance and storage unit is also configured as follows: A cryptographic hash function is used to calculate the hash value of the previous signed event proof in the security event log chain. Using the device private key established by the system initialization module, the hash value and the concatenated data of the current atomic log entry are digitally signed to generate the current signed event proof.

5. A transaction confidentiality system for smartphones according to claim 1, characterized in that, The service access control module includes: The log chain integrity verification unit is configured to perform a comprehensive cryptographic integrity verification on the security event log chain. The service gating decision unit is configured to authorize or deny the high-privilege service based on the result of the cryptographic integrity verification.

6. A transaction confidentiality system for a smartphone according to claim 5, characterized in that, The log chain integrity verification unit is configured to perform the cryptographic integrity verification when a high-privilege service call request is received. The service gating decision unit is configured to authorize the high-privilege service invocation request only when the cryptographic integrity verification passes.

7. A transaction confidentiality system for a smartphone according to claim 1, characterized in that, The remote status verification module includes: The challenge-response processing unit is configured to receive a one-time random challenge code from the external device; The dynamic proof generation unit is configured to integrate the state of the random challenge code with the state of the security event log chain to generate the cryptographic proof.

8. A transaction confidentiality system for a smartphone according to claim 7, characterized in that, The cryptographic proof is a dynamic remote proof, and the dynamic proof generation unit generates the dynamic remote proof by digitally signing a dynamic proof payload using the device's private key. The dynamic proof payload includes: a one-time random challenge code, the latest signed event proof in the security event log chain, and a Boolean value indicating the integrity status of the security event log chain.

9. A transaction confidentiality system for a smartphone according to claim 1, characterized in that, The system initialization module includes a device identity anchoring unit, which is configured as follows: A pair of asymmetric keys is generated within the trusted execution environment of the smartphone, and the device private key is securely stored. Collaborate with the manufacturer's certificate issuing equipment to generate a digitally signed device genesis certificate containing the device's public key and key hardware identifiers.

10. A transaction confidentiality system for a smartphone according to claim 3, characterized in that, The predefined key events include at least one of the following: System update events, security policy change events, and critical service call events.

Images