A method for using a Soft PIN Pad secure password keyboard

Abstract

This application discloses a secure PIN pad method for use in general commercial off-the-shelf devices, comprising: S1 environment trustworthiness detection at startup; S2 initialization of random numbers in a multi-source entropy pool and deployment of white-box encryption; S3 three-layer key isolation (the first layer encrypts and protects the second layer, and the second layer derives the third layer transaction key); S4 encrypting the password in the TEE based on the third layer key, constructing a password block containing a key sequence number, and clearing the memory; S5 updating the first layer key according to trigger conditions and reencrypting the second layer. Through environment detection, multi-source entropy pool, white-box encryption, three-layer isolation, and transaction-level key derivation, end-to-end protection is achieved; memory clearing prevents password residue, and periodic rotation of the first layer key provides forward security, ensuring that even if the key is leaked, historical transactions cannot be traced back. This significantly improves key isolation strength, real-time response, and long-term encrypted security, meeting PCI MPoC / SPoC compliance requirements.

Description

Technical Field

[0001] This invention belongs to the field of payment system security technology, and in particular relates to a method for a Soft PIN Pad secure password keyboard. Background Technology

[0002] In the POS (Point of Sale) industry, traditional payment PIN input solutions heavily rely on dedicated hardware security modules (such as hardware PIN pads). The high costs of hardware deployment, maintenance, and regular updates limit the rapid adoption and expansion of payment services. With the improvement in the performance of general-purpose off-the-shelf (COTS) devices, the industry has begun to explore software-based PIN input solutions. However, existing software solutions typically focus only on single-time environment checks at startup or simple static key storage, lacking a dynamic protection system covering the entire lifecycle from device startup and key injection to secure input and anomaly handling. Particularly noteworthy is the lack of continuous runtime security monitoring in existing solutions, making it unable to effectively detect real-time threats such as debugger attachments, emulator operation, screen hijacking, or UI overlay during transactions. Key management often employs a single-level or fixed key approach; once a key is leaked, multiple or even all transactions will be at risk. Furthermore, key materials are bound to long-term certificates, failing to provide forward security—meaning that future certificate or key leaks cannot guarantee the long-term security of historical transaction ciphertext. Furthermore, existing solutions rely excessively on a single pseudo-random source for random number generation, which poses a predictability risk. They also lack real-time memory zeroing, white-box encryption as a fallback, and compliant security auditing mechanisms, making it difficult to simultaneously meet the stringent compliance certification requirements of PCI MPoC / SPoC and the ever-increasing demand for actual attack defense. Summary of the Invention

[0003] (a) Purpose of the invention To overcome the above shortcomings, the present invention aims to provide a Soft PIN Pad secure password keyboard method to solve the technical problem that existing software-based password keyboard schemes lack a complete security closed loop from key layer isolation and runtime dynamic monitoring to forward security protection, resulting in significant deficiencies in key isolation strength, real-time threat response capability, and long-term transaction ciphertext security during the password input process on general-purpose devices.

[0004] (II) Technical Solution To achieve the above objectives, the technical solution provided in this application is as follows: A method for using a Soft PIN Pad secure password keyboard, applicable to general commercial off-the-shelf devices, is characterized by comprising: S1, in response to the startup of the password keyboard application, performs an environment trustworthiness check to establish a secure operating environment; S2 initializes secure random numbers based on a multi-source entropy pool and deploys obfuscated encryption and decryption algorithms in the host environment; S3 establishes a three-layer key isolation architecture, where the first-layer key is used to encrypt and protect the second-layer key, and the second-layer key is used to dynamically derive the third-layer transaction key. S4, in response to the password input event, performs encryption processing on the plaintext password based on the current third-level transaction key in the trusted execution environment, constructs a password data block carrying the current key sequence number, and performs memory overwrite and zeroing on the plaintext password; S5 updates the first-layer key based on preset trigger conditions, and then uses the updated first-layer key to re-encrypt the second-layer key.

[0005] By implementing environment trustworthiness checks at startup, multi-source entropy pool random number initialization, and white-box encryption as a fallback, coupled with a three-layer key isolation architecture and real-time transaction-level key derivation, end-to-end protection is achieved on general-purpose commercial devices, from establishing a trustworthy environment and secure key distribution to encrypted password transmission. Simultaneously, a memory overwrite zeroing mechanism ensures no plaintext passwords remain, and the periodic rotation of the first-layer key provides forward security for historical transaction ciphertexts—even if a key at a certain layer is leaked in the future, past transactions cannot be decrypted. This significantly enhances the overall defense capabilities of the password input process in terms of key isolation strength, real-time threat response, and long-term ciphertext security, providing a complete technical foundation for PCI MPoC / SPoC compliance certification.

[0006] In some embodiments, environmental reliability testing includes: Application integrity verification and local runtime environment detection during application startup; and, The loop daemon continuously monitors for at least one runtime exception event among debugger attachment, emulator operation, network proxy connection, screen projection, and abnormal camera usage.

[0007] By combining application integrity verification at startup with local environment detection and continuous monitoring by a runtime loop daemon thread, it not only blocks pre-existing risks such as repackaging, code injection, and ROOT / HOOK at the initial stage, but also captures dynamic attack behaviors such as debugger attachment, emulator operation, proxy connection, screen casting, and abnormal camera usage in real time during the transaction process. This upgrades security detection from a single snapshot to continuous awareness throughout the entire lifecycle, enabling any anomalies to be detected in a timely manner and effectively compressing the attacker's window of opportunity.

[0008] In some embodiments, initializing secure random numbers based on a multi-source entropy pool includes: Obtain the random number seed issued by the server-side hardware security module, and construct an entropy pool by combining the device-side light sensor data, touch screen event noise, accelerometer noise, gyroscope noise, microphone ambient noise, and camera light sensor noise.

[0009] By integrating the random number seed issued by the server-side HSM with noise from various physical sensors on the device side to construct a multi-source entropy pool, random number generation is freed from dependence on a single pseudo-random source. This significantly improves the unpredictability and anti-reverse capability of the key derivation foundation, providing a high-quality entropy source that conforms to the NIST standard for subsequent DUKPT derivation chains, thus ensuring the security of the entire key system from the source.

[0010] In some embodiments, the three-layer key isolation architecture specifically includes: The first-level key is the key encryption key, used to encrypt the device-level initial key; The second-level key is the device-level initial key, which is derived from the root key and the initial key sequence number in the server-side hardware security module. The third-level key is the transaction-level session key, which is derived in real time from the device-level initial key based on the current key sequence number, and is unique for each transaction.

[0011] The functional boundaries of the three-layer key are clearly defined: the first layer, KEK, serves as an encryption protection shell; the second layer, IPEK, serves as a device-level root key; and the third layer, PEK, serves as a unique session key for each transaction. This layered isolation ensures that the leakage of any single key will not affect other layers. A PEK leakage only jeopardizes a single transaction, an IPEK leakage only affects a single device, and the root key never leaves the server-side HSM. This achieves refined control of key risks and greatly reduces the possibility of large-scale systemic leakage.

[0012] In some embodiments, the process of issuing the second-level key includes: The device generates a certificate signature request carrying the device fingerprint and initial key serial number, and reports it to the server through a secure transmission channel; The server-side hardware security module derives the device-level initial key based on the root key and the initial key serial number; The server generates a key encryption key, encrypts it using the certificate public key, and then sends it to the device. The device uses the certificate private key to decrypt and obtain the key encryption key, and then uses the key encryption key to decrypt and obtain the device-level initial key, which is then stored in the trusted execution environment.

[0013] The document details the two-way authentication and encrypted transmission process for secure IPEK issuance. The device sends a certificate signing request carrying the device fingerprint and initial KSN. After being reported through a secure channel, the server derives the IPEK from the HSM and encrypts the KEK with the certificate public key before issuing it. The device decrypts the IPEK step by step to obtain it and stores it in the TEE. This process ensures that the IPEK is always under encrypted protection during transmission and storage, eliminating the risk of plaintext exposure. At the same time, the device fingerprint binding achieves a strong association between the key and the device, preventing the key from being migrated to unauthorized terminals.

[0014] In some embodiments, prior to performing encryption on the plaintext cipher based on the current Layer 3 transaction key in a trusted execution environment in response to a cipher input event, the method further includes: Implement input protection policies; input protection policies include: Customize and render a secure keyboard by using secure random numbers to randomly shuffle the positions of the numbers on the keyboard. Bypassing the system input method and disabling accessibility services to read window content; Detect and prevent floating windows, split screens, screen mirroring, and remote control interfaces from covering the screen. Disable input sound effects and vibration feedback; Prevent malware from taking screenshots.

[0015] A multi-layered input protection strategy was deployed before password input, including a secure keyboard with randomly shuffled number positions, bypassing the system input method and disabling accessibility reading, detecting and blocking floating windows / split screen / casting / remote control overlays, disabling sound effects and vibration feedback, and preventing screenshot operations. These measures worked together to resist common attack methods such as side-channel snooping, keylogging, UI hijacking, and screen recording theft, building a defense-in-depth barrier for the short period of plaintext passwords on the input interface, and significantly reducing the risk of information leakage during the input process.

[0016] In some embodiments, in a trusted execution environment, the plaintext cipher is encrypted based on the current third-level transaction key to construct a cryptographic data block carrying the current key sequence number, specifically including: Based on the device-level initial key and the current key sequence number, a third-layer transaction key is derived through an algorithm that derives an independent key for each transaction. Use a third-layer transaction key to encrypt plaintext ciphers; Construct a cryptographic data block carrying the current key sequence number according to the ISO 9564 standard; Increment the current key sequence number.

[0017] The encryption process within the TEE is standardized. Based on the IPEK and the current KSN, an independent PEK is derived for each transaction in real time. The plaintext cipher is encrypted using the PEK, and a cryptographic data block carrying the KSN is constructed according to the ISO 9564 standard. Subsequently, the KSN is incrementally updated. This process ensures that each transaction uses a brand new key and the KSN is monotonically incremented, so that the same plaintext presents completely different ciphertexts in different transactions. At the same time, the KSN is embedded in the cryptographic block as a unique identifier for the transaction, providing a reliable basis for server-side decryption verification and replay attack detection.

[0018] In some embodiments, the first-layer key is updated based on a preset trigger condition, and the second-layer key is re-encrypted using the updated first-layer key, specifically including: When the first-level key reaches its preset validity period or a security policy trigger instruction is received, the server-side hardware security module generates a new first-level key and sends it to the device. The device replaces the old first-level key with the new first-level key and re-encrypts the second-level key using the new first-level key. Mark the old first-level key as invalid.

[0019] A periodic rotation mechanism for the KEK, independent of the certificate lifecycle, is introduced. When the KEK expires or a security policy instruction is received, the server generates a new KEK and issues it. The device replaces the old KEK, re-encrypts the IPEK, and marks the old KEK as invalid. This mechanism decouples the key protection material from the long-term certificate. Even if the certificate private key is compromised in the future, the attacker can only obtain the expired old KEK and cannot backtrack to decrypt historical IPEKs, thus achieving forward security protection and further enhancing the anti-leakage capability of long-term stored ciphertext.

[0020] In some embodiments, when the loop daemon detects an abnormal event, it immediately triggers an emergency response, specifically including: Destroy the third-level transaction key currently residing in memory; Erase the device-level initial key and sensitive cached data stored in the trusted execution environment; Forcefully exit the current password keyboard application process and report the abnormal event to the server.

[0021] The emergency response actions are defined when the loop daemon detects an anomaly, including immediately destroying the PEK in memory, erasing the IPEK and sensitive cache in the TEE, forcibly exiting the application and reporting to the server. This series of rapid circuit breaker measures ensures that all sensitive keys are terminated as soon as signs of intrusion are detected, preventing attackers from continuously extracting keys by taking advantage of the abnormal environment, compressing the emergency response time to the millisecond level, and minimizing potential losses.

[0022] In some embodiments, a security audit step is also included: In response to the password input result, a security audit log is generated; the audit log only records the event type identifier of password input success or failure, and does not contain plaintext passwords or key sequence fragments; The integrity of the audit logs is protected by a hash-based message authentication code, and the audit logs are uploaded to a separate audit domain on the server.

[0023] By generating security audit logs that only record the type of successful / failed input events and contain no plaintext or keystroke fragments, and then uploading the logs to an independent audit domain after protecting their integrity using HMAC, the traceability requirements of compliance audits such as PCI DSS are met. At the same time, the design avoids the logs themselves becoming a channel for the leakage of sensitive information. Furthermore, the separation of the independent audit domain from the business system ensures the logs' tamper-proof and non-repudiation properties, providing a reliable basis for post-event security analysis and forensics. Attached Figure Description

[0024] Figure 1 This is a flowchart of the Soft PIN Pad secure password keyboard method of the present invention; Figure 2 This is a schematic diagram of the key management architecture of the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. It should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0026] This invention provides a Soft PIN Pad secure password keyboard method applicable to general commercial off-the-shelf devices, namely various standard smartphones, tablets, and other commercial terminals that do not require customized hardware. Unlike existing technologies that rely solely on single-level key or static key management, perform only one-time environment checks at startup, and lack forward security protection and runtime dynamic response, this application constructs a complete lifecycle security closed loop from device startup, key injection, secure input to anomaly handling. The core of this method lies in: employing a three-layer key isolation architecture, strictly separating the root key, device-level initial key, and transaction-level session key, and introducing a periodic KEK rotation mechanism independent of the certificate lifecycle to achieve forward security; simultaneously, continuous runtime security monitoring is achieved through a looping daemon thread, coupled with white-box encryption as a fallback protection outside the trusted execution environment, thereby achieving end-to-end password input security on general commercial devices. The specific steps will be described in detail below.

[0027] S1, in response to the startup of the password keyboard application, performs an environment trustworthiness check to establish a secure operating environment.

[0028] Specifically, during application startup, the system first performs an application integrity check, which verifies the signature and hash value of the APK or binary file to prevent repackaging, code injection, or patch tampering. After successful verification, the system enters a local runtime environment check to confirm that a trusted execution environment is available, the device is not rooted, there are no hooking software (such as Frida or Xposed), no malicious permissions have been granted, and the system's screenshot and screen recording functions are disabled. In particular, the system also starts a looping daemon thread that continuously monitors whether a debugger is attached to the process, whether the device is running in an emulator environment, whether a VPN or network proxy connection is enabled, whether screen projection is being performed via Miracast or AirPlay, and whether the front-facing camera is being abnormally occupied. It is worth noting that this looping daemon thread does not only perform this check once during startup, but runs continuously throughout the entire lifecycle of the password keyboard application, ensuring that any anomalies are promptly captured. In this way, the integrity verification at startup and the local environment detection are combined with continuous monitoring during runtime. This not only blocks pre-existing risks such as repackaging, code injection, and ROOT or HOOK at the initial stage, but also captures dynamic attack behaviors such as debugger attachment, simulator operation, proxy connection, screen projection, and abnormal camera usage in real time during the transaction process, thereby effectively compressing the attacker's operating window.

[0029] S2 initializes secure random numbers based on a multi-source entropy pool and deploys obfuscated encryption / decryption algorithms in the host environment.

[0030] The device submits its fingerprint and initial key serial number (KSN) via a remote management service, and the server verifies whether the device characteristics meet the security baseline. Upon successful verification, the server's hardware security module (HSM) returns a random number seed. The device then obtains this random number seed and further collects various local physical entropy sources, including light sensor data, touchscreen event noise, accelerometer noise, gyroscope noise, microphone ambient noise, and camera ambient noise. The system combines these random number seeds from the server's HSM with various local physical noises to construct a multi-source entropy pool. This entropy pool meets the NIST SP 800-22 true randomness requirement and serves as the security foundation for all subsequent random number generation. Compared to existing technologies that rely on a single pseudo-random number generator, the multi-source entropy pool significantly improves the unpredictability and reversibility of the key derivation foundation, ensuring the security of the subsequent DUKPT (each transaction derives a unique key) derivation chain from the source. Meanwhile, the system also deploys white-box encryption (such as white-box AES tables and white-box SM4) in the host environment, deploying core algorithms such as AES or RSA in an obfuscated form at the host operating system layer, forming a "double insurance" mechanism with the trusted execution environment. In this way, even if the host environment's memory is dumped, attackers cannot extract valid keys from the obfuscated code, providing additional security redundancy for the system.

[0031] S3 establishes a three-layer key isolation architecture, where the first-layer key is used to encrypt and protect the second-layer key, and the second-layer key is used to dynamically derive the third-layer transaction key.

[0032] The hierarchical relationship and functional division of this three-tier architecture are as follows.

[0033] The first-level key is the key encryption key (KEK), which is encrypted and protected by the CA certificate public key. It is specifically used for encrypting the initial key at the device level and does not directly participate in the encryption of any transaction data.

[0034] The second layer of key is the device-level initial key (IPEK), which is derived from the root key (BDK) and the initial key serial number in the server-side hardware security module. It is a unique initial key material for each device.

[0035] The third-level key is the transaction-level session key (PEK or Transaction Key), which is derived in real time from the device-level initial key based on the current key sequence number, and is unique for each transaction.

[0036] Specifically, in each transaction, the device uses the IPEK and the current KSN to derive a PEK specific to that transaction in real time using the DUKPT algorithm. This PEK only resides briefly in the memory of the current transaction and is destroyed after the transaction is completed. In this three-layer architecture, the BDK, as the root key, never leaves the server-side HSM and is the root of trust for the entire derivation chain. This layered isolation ensures that any single point of key leakage will not affect other layers: a PEK leakage only jeopardizes a single transaction, an IPEK leakage only affects a single device, and the root key is always securely stored within the server-side HSM. This design contrasts sharply with the common single static key or simple two-level derivation schemes in existing technologies, significantly improving the fine-grainedness and security of key management.

[0037] The specific steps for the secure distribution of the second-level key (IPEK) are as follows: The device generates a Certificate Signing Request (CSR) carrying the device fingerprint and initial key sequence number, and reports it to the server via a secure transmission channel using TLS 1.2 or later and SSL Pinning. Upon receiving the request, the server's hardware security module derives a unique device-level initial key (IPEK) for the device based on the root key (BDK) and the initial key sequence number reported by the device using the DUKPT algorithm.

[0038] Subsequently, the server generates the first-layer key, the Key Encryption Key (KEK), encrypts it using the public key of the device certificate, and sends it to the device. Upon receiving the ciphertext, the device decrypts it using its own certificate's private key to obtain the KEK and stores it in the system's Keystore. The device then uses this KEK to decrypt the ciphertext of the IPEK from the server, obtaining the plaintext IPEK, which is immediately stored in the secure storage area of ​​the Trusted Execution Environment (TEE). Simultaneously, the device's KSN counter is initialized, and its initial value is consistent with the initial KSN used when the server derives the IPEK from the HSM. This process ensures that the IPEK remains encrypted throughout transmission and storage, eliminating the risk of plaintext exposure. Furthermore, device fingerprint binding establishes a strong association between the key and the device, preventing the key from being transferred to unauthorized terminals.

[0039] Before a password input event occurs, the method also includes implementing a series of input protection strategies. Specifically, the system renders a custom secure keyboard that uses the previously initialized secure random numbers to randomly shuffle the positions of the numbers on the keyboard each time it pops up, preventing attackers from guessing the user's input based on fixed key positions. Simultaneously, the system bypasses the system input method, directly taking over keyboard input events, and disables the accessibility service's ability to read window content, preventing malicious applications from stealing input content through accessibility services. The system also detects and blocks overlays of floating windows, split-screen, screen mirroring, and remote control interfaces, ensuring the input interface is not obscured by any third-party views. Furthermore, the system disables input sound effects and vibration feedback to prevent these feedback signals from being captured by side-channel attacks. The system also prevents malicious software from taking screenshots, ensuring the input interface cannot be captured. These measures work together to effectively resist common attack methods such as side-channel snooping, keylogging, UI hijacking, and screen recording, building a defense-in-depth barrier for the brief period of plaintext passwords on the input interface.

[0040] S4, in response to the password input event, perform encryption processing on the plaintext password based on the current third-level transaction key in the trusted execution environment, construct a password data block carrying the current key sequence number, and perform memory overwrite and zeroing on the plaintext password.

[0041] The specific process for performing this encryption process in a trusted execution environment is as follows.

[0042] The system first derives the third-level transaction key (PEK) based on the device-level initial key (IPEK) already stored in the trusted execution environment and the current key sequence number (KSN), using an independent key derivation algorithm for each transaction. This derivation process is completed within the TEE, ensuring that intermediate calculation results are not exposed to the host operating system.

[0043] The system then uses the PEK to encrypt the plaintext password entered by the user. After encryption, the system constructs a PIN block according to the ISO 9564 standard (Format 0 / 2 / 4), which carries the current key sequence number (KSN) as a unique identifier for this transaction.

[0044] After completing the above operations, the system immediately performs a zeroing operation on the memory area where the plaintext password is located, i.e., zeroing, overwriting it to 0x00, to ensure that the plaintext password leaves no trace in memory.

[0045] Subsequently, the system increments and updates the current key sequence number, preparing a new derivation starting point for the next transaction. The encrypted cryptographic data block is securely transmitted to the server via PCI standard messages, which also include fields such as the key version number and random number padding to prevent replay attacks. This process ensures that each transaction uses a completely new key and that the KSN monotonically increments, so that the same plaintext presents completely different ciphertexts in different transactions. At the same time, the KSN, as a unique identifier for the transaction, is embedded in the cryptographic block, providing a reliable basis for server-side decryption verification and replay attack detection.

[0046] S5, update the first layer key based on a preset trigger condition, and re-encrypt the second layer key using the updated first layer key.

[0047] The update mechanism for the first-level key (KEK) is as follows.

[0048] The system presets the validity period of the first-level key, which is independent of the certificate's validity period. When the first-level key reaches its preset validity period (e.g., 24 hours, 7 days), or when the server actively triggers a key update command due to security policy requirements, the server's hardware security module generates a brand-new key encryption key (new KEK), encrypts the new KEK using the device certificate's public key, and then sends it to the device.

[0049] Upon receiving the new KEK ciphertext, the device decrypts it using its own certificate's private key to obtain the new KEK. This new KEK replaces the old one, and the device-level initial key (IPEK) stored in the Trusted Execution Environment (TEEI) is immediately re-encrypted using the new KEK. The old KEK is marked as invalid and is no longer used for any encryption or decryption operations. This mechanism decouples key protection materials from long-term certificates. Even if the certificate's private key is compromised in the future, attackers can only obtain the invalidated old KEK ciphertext and cannot backtrack to decrypt historical IPEKs, thus achieving forward security. This feature is not publicly disclosed in existing schemes involving DUKPT or remote key injection, and combined with a three-layer key architecture, it makes historical transaction ciphertext resistant to leakage during long-term storage, significantly improving the overall security of the system.

[0050] When the aforementioned loop daemon detects an abnormal event, the system immediately triggers an emergency response mechanism.

[0051] The specific execution process of this emergency response is as follows: The system first destroys the third-level transaction key (PEK) currently residing in memory to ensure that the session key for this transaction is not obtained by an attacker.

[0052] Subsequently, the system erases the device-level initial key (IPEK) and other sensitive cached data stored in the trusted execution environment, thus completely erasing the key materials on the device side.

[0053] Finally, the system forcibly exits the current password keyboard application process, preventing attackers from further exploiting the process for malicious operations, and reports this anomaly to the server for security analysis and subsequent handling by operations and maintenance personnel. This series of rapid circuit breaker measures ensures that all sensitive keys are terminated as soon as intrusion signs are detected, preventing attackers from continuously extracting keys using the abnormal environment, compressing the emergency response time to the millisecond level. Compared with solutions that only perform startup detection, this application's runtime continuous monitoring combined with emergency response can cut off the key exposure path "at the first moment" of an attack, greatly reducing the probability of a successful attack.

[0054] Preferably, the method further includes a security audit step. In response to each password input result, the system generates a security audit log. This audit log only records the event type identifier of successful or failed password input, such as "PIN input successful" or "PIN input failed," and never contains the plaintext password itself or any keystroke sequence fragments. The system uses a hash-based message authentication code (HMAC) to protect the integrity of the audit log, preventing its content from being tampered with. Subsequently, the system uploads the audit log to an independent audit domain on the server side. This independent audit domain is logically and physically isolated from the business system, ensuring the log's tamper-proof and non-repudiation properties. This mechanism not only meets the traceability requirements of compliance audits such as PCI DSS, but also avoids the log itself becoming a channel for the leakage of sensitive information by design.

[0055] In summary, this invention constructs a security protection system covering the entire key lifecycle on general-purpose commercial off-the-shelf devices through the organic combination of five main steps (S1 to S5) and their subordinate features. These features are not simply a superposition of single methods found in existing technologies, but rather synergistic and indispensable: three-layer isolation provides hierarchical risk control for the key; KEK rotation provides forward security; runtime monitoring ensures that dynamic threats can be detected in real time; and white-box encryption adds software-layer redundancy beyond the hardware root of trust. Together, these features address the systemic deficiencies of existing software cryptographic keyboard schemes in terms of key isolation strength, real-time response capability, and long-term ciphertext security.

[0056] It should be understood that the specific embodiments described above are merely illustrative or explanatory of the principles of the invention and do not constitute a limitation thereof. Therefore, any modifications, equivalent substitutions, improvements, etc., made without departing from the spirit and scope of the invention should be included within the protection scope of the invention. Furthermore, the appended claims are intended to cover all variations and modifications falling within the scope and boundaries of the appended claims, or equivalent forms of such scope and boundaries.

Claims

1. A method for using a Soft PIN Pad secure password keyboard, applied to general commercial off-the-shelf devices, characterized in that, include: S1, in response to the startup of the password keyboard application, performs an environment trustworthiness check to establish a secure operating environment; S2 initializes secure random numbers based on a multi-source entropy pool and deploys obfuscated encryption and decryption algorithms in the host environment; S3, establish a three-layer key isolation architecture, where the first-layer key is used to encrypt and protect the second-layer key, and the second-layer key is used to dynamically derive the third-layer transaction key; S4, in response to the password input event, in the trusted execution environment, the plaintext password is encrypted based on the current third-level transaction key, a password data block carrying the current key sequence number is constructed, and the plaintext password is overwritten and cleared in memory; S5, update the first layer key based on a preset trigger condition, and re-encrypt the second layer key using the updated first layer key.

2. The method according to claim 1, characterized in that, The environmental reliability test includes: Application integrity verification and local runtime environment detection during application startup; and, The loop daemon continuously monitors for at least one runtime exception event among debugger attachment, emulator operation, network proxy connection, screen projection, and abnormal camera usage.

3. The method according to claim 1, characterized in that, The method for initializing secure random numbers based on a multi-source entropy pool includes: Obtain the random number seed issued by the server-side hardware security module, and construct an entropy pool by combining the device-side light sensor data, touch screen event noise, accelerometer noise, gyroscope noise, microphone ambient noise, and camera light sensor noise.

4. The method according to claim 1, characterized in that, The three-layer key isolation architecture specifically includes: The first-level key is the key encryption key, used to encrypt the device-level initial key; The second-level key is the device-level initial key, which is derived from the root key and the initial key sequence number in the server-side hardware security module. The third-level key is a transaction-level session key, which is derived in real time from the device-level initial key based on the current key sequence number, and is unique for each transaction.

5. The method according to claim 4, characterized in that, The process of distributing the second-level key includes: The device generates a certificate signature request carrying the device fingerprint and initial key serial number, and reports it to the server through a secure transmission channel; The server-side hardware security module derives the device-level initial key based on the root key and the initial key serial number; The server generates a key encryption key, encrypts it using the certificate public key, and then sends it to the device. The device uses the certificate private key to decrypt and obtain the key encryption key, and uses the key encryption key to decrypt and obtain the device-level initial key, which is then stored in the trusted execution environment.

6. The method according to claim 1, characterized in that, The method of responding to a password input event and performing encryption on the plaintext password based on the current third-level transaction key in a trusted execution environment, before doing so, also includes: Implement an input protection policy; the input protection policy includes: A custom-rendered secure keyboard is created by randomly shuffling the positions of the keyboard numbers using the secure random number generator. Bypassing the system input method and disabling accessibility services to read window content; Detect and prevent floating windows, split screens, screen mirroring, and remote control interfaces from covering the screen. Disable input sound effects and vibration feedback; Prevent malware from taking screenshots.

7. The method according to claim 4, characterized in that, The step of encrypting plaintext cryptography based on the current third-layer transaction key in a trusted execution environment to construct a cryptographic data block carrying the current key sequence number specifically includes: Based on the device-level initial key and the current key sequence number, the third-layer transaction key is derived through an algorithm that derives an independent key for each transaction. The plaintext cipher is encrypted using the third-layer transaction key; Construct a cryptographic data block carrying the current key sequence number according to the ISO 9564 standard; The current key sequence number is incremented and updated.

8. The method according to claim 1, characterized in that, The step of updating the first-layer key based on preset triggering conditions and re-encrypting the second-layer key using the updated first-layer key specifically includes: When the first-level key reaches its preset validity period or a security policy trigger instruction is received, the server-side hardware security module generates a new first-level key and sends it to the device. The device replaces the old first-level key with the new first-level key and re-encrypts the second-level key using the new first-level key; The old first-level key is marked as invalid.

9. The method according to claim 2, characterized in that, When the loop daemon detects an abnormal event, it immediately triggers an emergency response, which includes: Destroy the third-level transaction key currently residing in memory; Erase the device-level initial key and sensitive cached data stored in the trusted execution environment; Forcefully exit the current password keyboard application process and report the abnormal event to the server.

10. The method according to claim 1, characterized in that, It also includes security auditing steps: In response to the password input result, a security audit log is generated; the audit log only records the event type identifier of password input success or failure, and does not contain plaintext passwords or key sequence fragments; The integrity of the audit logs is protected by a hash-based message authentication code, and the audit logs are uploaded to a separate audit domain on the server.

Images