A secure keyboard encryption method, storage medium and terminal device
Patent Information
- Application Number
- CN202611496589.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-09-24
- Publication Date
- 2026-10-30
AI Technical Summary
[0005]在存储与传输阶段,即使部分方案采用随机键盘布局或整体加密传输,但单个字符在输入后、整体加密前的映射关系或缓存数据仍可能在内存中留存,且其加密过程多依赖单一的传统公钥密码体系,在量子计算算力突破的威胁下,长期存储的密文数据存在被批量破解的风险
(1)采用安全软键盘替代系统输入法,并在此基础上引入动态字符映射机制,使用户输入的真实字符在客户端运行过程中始终以映射值形式存在,而非以明文形式长期驻留于浏览器DOM节点、JavaScript变量或客户端内存中,有效避免了系统输入法监听、第三方输入法记录以及恶意键盘监听程序窃取输入内容的风险,显著提升了客户端对恶意攻击的防护能力。
Smart Images

Figure CN123013193A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of internet terminal encryption technology, and in particular to an encryption method, storage medium and terminal device for a secure keyboard. Background Technology
[0002] Currently, in mobile H5 pages, hybrid applications, and web systems within the financial industry, user login, payment, transfer, and identity authentication scenarios typically require the input of sensitive information such as bank card passwords, payment passwords, and SMS verification codes. As the financial industry becomes increasingly mobile-centric, the security requirements for sensitive input processes on client-side applications are also rising. According to industry requirements such as the "Mobile Financial Client Application Software Security Management Specification," financial clients must possess security capabilities including real-time protection of sensitive input, secure password transmission, prevention of keystroke eavesdropping, and prevention of plaintext memory leaks.
[0003] Currently, common sensitive input protection schemes mainly include the following: The first option is to use the system input method to enter the password, and then use " The first approach hides the input content using characters like "" or "●". The second approach replaces the system input method with a standard H5 soft keyboard, implementing the keyboard UI component via front-end JavaScript and capturing user input through click events. The third approach enhances password security by using random keyboard layouts or random number arrangements, such as dynamically shuffling the numeric keypad order with each input. The fourth approach employs traditional encryption algorithms like RSA and AES, establishing an encrypted communication mechanism between the client and server to encrypt the transmission of sensitive data.
[0004] However, the existing solutions described above still have the following security vulnerabilities at each stage of sensitive data input, storage, and transmission: During the input phase, most existing solutions only encrypt the overall data upon submission. As the user inputs character by character, the actual input content remains in plaintext form in browser DOM nodes, JavaScript variables, or client process memory for an extended period. Attackers can steal the unencrypted raw input data through memory analysis, dynamic debugging, or hook injection.
[0005] During the storage and transmission phases, even if some schemes employ random keyboard layouts or overall encrypted transmission, the mapping relationships or cached data of individual characters after input but before overall encryption may still remain in memory. Furthermore, their encryption processes often rely on a single traditional public-key cryptosystem. Given the threat of breakthroughs in quantum computing power, long-term stored encrypted data is at risk of being compromised in bulk. In addition, existing schemes generally lack dual protection mechanisms for integrity verification and message authentication during data transmission, making it difficult to effectively resist man-in-the-middle tampering or replay attacks.
[0006] At the end of the data lifecycle, most existing solutions do not immediately clear sensitive data after input is completed, which means that related caches, variables and residual information may still remain in the client's memory for a long time. Even if the data has been sent, the residual information still poses a risk of leakage.
[0007] In summary, existing technical solutions have significant shortcomings in areas such as real-time protection of sensitive data input, secure memory residency, resistance to quantum computing attacks, integrity verification, and removal of residual information. Summary of the Invention
[0008] In view of this, embodiments of this application provide an encryption method, storage medium, and terminal device for a secure keyboard, aiming to provide full-process security protection for sensitive data during the input, storage, and transmission stages.
[0009] To achieve the above objectives, according to one aspect of the embodiments of this application, a secure keyboard encryption method is provided, the method being applied to a client, comprising: A three-way handshake is performed with the server to establish a secure communication channel and negotiate a session key, and to obtain the dynamic character mapping table generated by the server. The dynamic character mapping table is used to map the characters input by the user to the corresponding mapping values. The system receives characters input by the user via a secure soft keyboard and converts the characters into mapped values according to the dynamic character mapping table. The converted mapping value is segmented and encrypted in real time, and the encrypted segments are stored in memory. After the user completes the input, the segmented ciphertext is decrypted and concatenated to obtain the overall mapping value. The overall mapping value is then encrypted using the session key, and integrity verification information is generated. The encrypted overall mapping value and the integrity verification information are sent to the server through the secure communication channel. After the data is sent, the segmented ciphertext, the overall mapping value, and the session key stored in memory are cleared.
[0010] Optionally, the three-way handshake includes: First handshake: Send a handshake request to the server and receive the SM2 public key and ML-KEM quantum-resistant encryption public key generated by the server after receiving the handshake request; Second handshake: Send client information and client random number to the server, and receive the dynamic character mapping table and server random number returned by the server; The third handshake involves generating a pre-master key and encapsulating it using the ML-KEM quantum-resistant encryption public key to obtain corresponding ciphertext data. The pre-master key and the ciphertext data are then sent to the server. The server derives the session key based on the pre-master key, the client's random number, and the server's random number, and returns a success message upon successful derivation. In response to the success message, the client derives the same session key using the same algorithm.
[0011] Optionally, the client derives the same session key based on the same algorithm, including: The master key is generated by mixing and calculating the pre-master key, the client random number, and the server random number using a key derivation function; The SM4 encryption key, HMAC key, and CMAC key are derived from the master key, and the session key is composed of the SM4 encryption key, the HMAC key, and the CMAC key.
[0012] Optionally, the real-time segmentation and encryption of the converted mapping value includes: The mapping value corresponding to each character is encrypted independently using the SM4 algorithm; Each encrypted segment of ciphertext is stored in a different memory region, so that there is no complete plaintext mapping value in memory.
[0013] Optionally, the process of generating the integrity verification information is as follows: The HMAC key is used to calculate the encrypted overall mapping value to generate an HMAC verification code; The encrypted overall mapping value is calculated using the CMAC key to generate a CMAC verification code; The HMAC verification code and the CMAC verification code are used as the integrity verification information.
[0014] Optionally, the real-time segmentation and encryption of the converted mapping value includes: The mapping value corresponding to each character is encrypted independently using the SM4 algorithm; Each encrypted segment of ciphertext is stored in a different memory region, so that there is no complete plaintext mapping value in memory.
[0015] According to another aspect of the embodiments of this application, an encryption method for a secure keyboard is provided, the method being applied to a server, including: A three-way handshake is performed with the client to establish a secure communication channel and negotiate a session key, generate a dynamic character mapping table and send it to the client. The dynamic character mapping table is used to map the characters input by the user to the corresponding mapping values. The encrypted overall mapping value and integrity verification information sent by the client are received through the secure communication channel. The encrypted overall mapping value is obtained by the client mapping, encrypting, and concatenating the user input characters based on the dynamic character mapping table, and then encrypting them as a whole using the session key. The encrypted overall mapping value is verified based on the integrity verification information; After the verification is successful, the encrypted overall mapping value is decrypted using the session key to obtain the overall mapping value; The overall mapping value is restored to the actual character input by the user based on the dynamic character mapping table, and the business operation corresponding to the actual character is executed.
[0016] Optionally, the three handshakes each include: First handshake: In response to the handshake request sent by the client, generate an SM2 key pair and an ML-KEM quantum-resistant encryption key pair, return the SM2 public key and the ML-KEM quantum-resistant encryption public key, and save the private keys of both. Second handshake: Receive client information and client random number sent by the client, generate the dynamic character mapping table, and return the dynamic character mapping table and server random number to the client; Third handshake: Receive the pre-master key and ciphertext data sent by the client, derive the session key based on the pre-master key, the client's random number and the server's random number, and return a successful derivation message to the client after successful derivation.
[0017] Optionally, generating the dynamic character mapping table includes: The client-side random number and the server-side random array are combined to form a random seed, and the server-side secure random number generator generates true random numbers based on the random seed; The true random number is used as a random source and input into the shuffling algorithm, which shuffles the order of the integer sequence to obtain a random arrangement; A one-to-one correspondence is established between the random arrangement and the 95 printable characters, which serves as the dynamic character mapping table.
[0018] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the storage medium storing a computer program, wherein the computer program is configured to execute, at runtime, a secure keyboard encryption method as described in any of the preceding claims.
[0019] According to another aspect of the embodiments of this application, a terminal device is provided, the terminal device including a processor and a memory, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform an encryption method for a secure keyboard as described in any of the preceding claims.
[0020] By employing the above technical solutions, the encryption method, storage medium, and terminal device for a secure keyboard provided in this application establish a secure communication channel and negotiate a session key and obtain a dynamic character mapping table through a three-way handshake between the client and the server. During the user input process, the real characters are mapped to the mapping values in real time and stored in segments with encryption. After the input is completed, the segmented ciphertexts are decrypted, concatenated, and then encrypted as a whole with additional integrity verification information before being sent to the server. The server verifies the data and restores it to the user's real characters, thereby achieving full-process security protection for sensitive data during the input, storage, and transmission stages.
[0021] Based on the above technical principles, the embodiments of this application can achieve the following technical effects: (1) A secure soft keyboard is used to replace the system input method, and a dynamic character mapping mechanism is introduced on this basis. This ensures that the real characters entered by the user always exist in the form of mapped values during the operation of the client, rather than residing in the browser DOM node, JavaScript variable or client memory in plain text for a long time. This effectively avoids the risks of system input method monitoring, third-party input method recording and malicious keyboard monitoring programs stealing input content, and significantly improves the client's ability to protect against malicious attacks.
[0022] (2) By using a real-time segmented encryption mechanism, the mapping value is independently encrypted and stored in segments each time the user inputs a character. After each segment of ciphertext is stored, the corresponding plaintext mapping value is destroyed. Compared with the traditional scheme that only encrypts the whole at the submission stage, this fundamentally eliminates the plaintext exposure window of sensitive data at the input stage, ensuring that there is no complete plaintext sensitive data in memory, and greatly reducing the risk of sensitive data being directly read from memory or dumped.
[0023] (3) The dynamic character mapping mechanism is adopted so that the mapping value of the same character changes dynamically in different sessions. Attackers cannot deduce the user input pattern by intercepting the mapping relationship of a single session. Since the dynamic character mapping table is generated by the client random number and the server random array as a random seed, its randomness comes from the joint contribution of the client and the server, and has higher unpredictability, effectively resisting replay attacks and data recovery attacks.
[0024] (4) By combining HMAC and CMAC verification codes, the purpose of double integrity verification of the encrypted overall mapping value is achieved. That is, when one verification code is broken, the other verification code can still provide effective protection, ensuring the ability of sensitive data to be tampered with and forged during transmission.
[0025] (5) After the data is sent, the segmented ciphertext, overall mapping value and session key stored in memory are cleared immediately, avoiding the risk of information leakage caused by the long-term retention of cached or residual information in the client's memory. The last security defense line is built at the end of the sensitive data life cycle, realizing a complete security closed loop from input to transmission to clearing. Attached Figure Description
[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. In the drawings: Figure 1 An example diagram illustrating the operational scenario of an encryption method for a secure keyboard provided in this application embodiment; Figure 2 A flowchart illustrating an encryption method for a secure keyboard provided in an embodiment of this application; Figure 3 An example diagram illustrating a three-way handshake between a client and a server, provided in an embodiment of this application. Figure 4 This is a structural diagram of a terminal device provided in an embodiment of this application. Detailed Implementation
[0027] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.
[0028] Figure 1 This diagram illustrates an example of an operational scenario for an encryption method for a secure keyboard provided in this application. Figure 1 As shown, this operational scenario includes a client and a server. The client can be a smartphone, tablet, or other mobile terminal device running an H5 page, a Hybrid application, or a Web application. The server is the business server corresponding to the client, used to perform operations such as key generation and distribution, dynamic character mapping table generation, and data integrity verification during the three-way handshake process with the client.
[0029] On the client side, sensitive data such as passwords and verification codes entered by users, if stored in plaintext in memory, may be at risk of being stolen by malicious programs through memory scanning, dynamic debugging, or hook injection. To eliminate this security risk at the source, this embodiment introduces a secure soft keyboard on the client side to replace the system input method. Combined with a dynamic character mapping mechanism and a real-time segmented encryption mechanism, each character entered by the user is instantly converted into a mapping value and independently encrypted and stored, ensuring that sensitive data does not reside in client memory in plaintext. Furthermore, a secure session mechanism based on national cryptographic algorithms and quantum-resistant encryption algorithms, along with a data integrity verification mechanism, is integrated to achieve full-process security protection for sensitive data during the input, storage, and transmission stages.
[0030] To facilitate understanding of the technical solutions of the embodiments of this application, the key terms and algorithms involved in this application will be explained first.
[0031] The secure soft keyboard is a client-side component that is custom-drawn by the application. This component does not rely on the operating system's input method; instead, the application draws the keyboard interface, captures user click events, and processes input. The secure soft keyboard includes three switchable layouts: an alphabetic keyboard, a numeric keyboard, and a character keyboard. The Shift key can be used to switch between uppercase and lowercase letters. When the secure soft keyboard starts, the client calls the operating system's anti-screenshot interface, such as a pre-configured system security program. This program controls the current page to be in anti-screenshot and anti-screen recording mode, preventing malicious programs from obtaining input content through screen recording or screenshots.
[0032] A dynamic character mapping table (VTMA) is a data structure used to convert user-input characters into mapped values. The VTMA is dynamically generated by the server during session establishment and sent to the client. It establishes a one-to-one correspondence between printable characters and integer sequences. The same character corresponds to different mapped values in different sessions, thus preventing attackers from reconstructing user input by analyzing mapping patterns.
[0033] Real-time segmented encryption is a mechanism that encrypts data character by character as the user inputs. Each time a character is entered, the client immediately encrypts it and stores the encrypted ciphertext in segments. Throughout the entire input process, no complete plaintext data exists in memory.
[0034] A session key is a symmetric key negotiated between the client and server through a key derivation function during session establishment. A session key includes at least an SM4 encryption key, an HMAC key, and a CMAC key. The SM4 encryption key is used for symmetric encryption of the mapped value. The HMAC key is used for hash-based message authentication code calculation. The CMAC key is used for block cipher-based message authentication code calculation.
[0035] The SM2 algorithm is a public-key cryptography algorithm based on elliptic curve cryptography, primarily used for digital signatures and public-key encryption. The SM3 algorithm is a cryptographic hash algorithm used to generate message digests. The SM4 algorithm is a block symmetric encryption algorithm used for data encryption and decryption.
[0036] ML-KEM is a quantum-resistant encryption algorithm based on lattice cryptography, making it resistant to attacks from quantum computers. During key encapsulation, the client uses the server's ML-KEM quantum-resistant public key to encapsulate sensitive data and generate ciphertext. Only the server holding the corresponding ML-KEM quantum-resistant private key can decapsulate the ciphertext and recover the data.
[0037] A key derivation function (KDF) is an algorithm that derives one or more keys from initial key materials. A KDF consists of an extraction phase and an expansion phase. In the extraction phase, the KDF mixes and computes the input key materials to generate a fixed-length master key. In the expansion phase, the KDF derives multiple independent keys of the required length from this master key for use in subsequent cryptographic operations.
[0038] HMAC (Hash-based Message Authentication Code) is an algorithm that uses a key and a hash function to generate an authentication code for a message, used to verify the integrity and authenticity of the message. CMAC (Clock Cipher-based Message Authentication Code) is also an algorithm that uses a block cipher algorithm and a key to generate an authentication code for a message, similarly used to verify message integrity and authenticity. This application uses both HMAC and CMAC to perform double verification of the ciphertext to improve security.
[0039] Figure 2 This is a flowchart illustrating an encryption method for a secure keyboard provided in an embodiment of this application. Figure 2 As shown, according to the interaction sequence between the client and the server, the security protection of sensitive data in this embodiment is divided into the initialization stage, the data input stage, and the data processing stage. Each stage is described below.
[0040] The goal of the initialization phase is to establish a secure communication channel for sensitive data, achieved through a three-way handshake. Specifically, after the client detects that a user clicks on a business input box and triggers a focus event, it initiates the secure soft keyboard initialization process, starting a three-way handshake with the server. The interaction flow of the three-way handshake can be found in [reference needed]. Figure 3 As shown, the specific interaction process is as follows.
[0041] First handshake The client sends a handshake request to the server. In a specific example, this handshake request might be represented by a ClientHello message, primarily used to inform the server of the SSL / TLS protocol versions and cipher suites supported by the client. The client includes a list of supported algorithms and cipher suites in this request, including a declaration of support for Chinese national cryptographic algorithms and a support identifier for the secure soft keyboard interaction method. It also includes information such as the keyboard type and version, allowing the server to select an appropriate encryption strategy based on the client's supported protocols. Furthermore, the server determines whether to enable the secure soft keyboard encryption process based on the client's support identifier for the secure soft keyboard interaction method, i.e., whether to provide full-process security protection for input characters during this session.
[0042] After receiving the handshake request from the client, the server selects a matching encryption strategy based on the client's supported algorithms and cipher suite list. For example, in a specific example of this application, the client supports the SM2 encryption algorithm, the SM3 cryptographic hash algorithm, and the SM4 symmetric encryption algorithm, and also declares support for the ML-KEM quantum-resistant encryption algorithm and the dynamic character mapping mechanism required for the secure soft keyboard. Based on the above support, the server selects a cipher suite combination that includes the SM2 encryption algorithm and the ML-KEM quantum-resistant encryption algorithm; that is, the server generates an SM2 key pair and an ML-KEM quantum-resistant encryption key pair. The SM2 key pair contains an SM2 public key and an SM2 private key, and the ML-KEM quantum-resistant encryption key pair contains an ML-KEM quantum-resistant encryption public key and an ML-KEM quantum-resistant encryption private key. The server stores the SM2 private key and the ML-KEM quantum-resistant encryption private key, while Base64 encoding the SM2 public key and the ML-KEM quantum-resistant encryption public key respectively, obtaining the encoded SM2 public key and the encoded ML-KEM quantum-resistant encryption public key. To facilitate client verification of the integrity and authenticity of the public key, the server also uses the SM3 algorithm to generate an SM2 public key fingerprint from the encoded SM2 public key and an ML-KEM quantum-resistant public key fingerprint from the encoded ML-KEM quantum-resistant public key. Subsequently, the server returns a handshake response message to the client. In a specific example, this handshake response message can be represented as a ServerHello message, which contains the encryption and security policy information selected by the server. The security policy information includes, but is not limited to, session timeout, key update cycle, and other configuration items. The server also returns its server certificate and digital certificate signature to the client. The server certificate is used by the client to verify the legitimacy of the server's identity, while the digital certificate signature ensures that the server certificate has not been tampered with during transmission.
[0043] After receiving the above data, the client first verifies the server's certificate to confirm the server's identity. Then, it verifies the SM2 public key fingerprint and the ML-KEM quantum-resistant encryption public key fingerprint to confirm the integrity and authenticity of the public key. If all verifications pass, the client performs Base64 decoding on the encoded SM2 public key and the encoded ML-KEM quantum-resistant encryption public key to obtain their original data, preparing for the second handshake. Otherwise, if any verification fails, the client terminates the handshake.
[0044] Second handshake The client sends its information and a client-side random number to the server. The client information includes, but is not limited to, browser type, version information, operating system information, and client identification information; the client-side random number is generated by the client's secure random number generator.
[0045] After receiving the client's information and random number, the server first verifies the client's information to confirm its legitimacy and version compatibility. If client information verification fails, for example, if the client version is too low or the client identifier is not trusted by the server, the server rejects the handshake and returns an error message to the client. If verification succeeds, the server saves the client's random number and generates a dynamic character mapping table based on the client's random number and its own server-generated random number. The server-generated random number is a random number generated by the server's secure random number generator.
[0046] Specifically, the dynamic character mapping table is generated as follows: First, the server generates an integer sequence from 0 to 94, which corresponds one-to-one with the 95 printable characters whose ASCII codes are 32 to 126. Second, the server combines a client-side random number and a server-side random array as a random seed. For example, two random numbers are concatenated and input into the server's secure random number generator, which then generates truly random numbers based on this seed. Because the random seed contains randomness provided by both the client and the server, the generated truly random numbers have higher unpredictability. The server uses this truly random number as a random source and inputs it into a shuffling algorithm, which shuffles the integer sequence to obtain a randomly permuted integer sequence. Finally, the server establishes a one-to-one correspondence between this random permutation and the 95 printable characters, serving as the dynamic character mapping table.
[0047] It should be noted that in practical applications, either client-side or server-side random numbers can be used as the random source to trigger the generation of the dynamic character mapping table. For example, in scenarios with relatively low security requirements or limited computing resources, only server-side random numbers can be used to generate truly random numbers and shuffle the integer sequence.
[0048] After the dynamic character mapping table is generated, the server uses the SM3 algorithm to calculate a digest value from the combination of the dynamic character mapping table, server-side random numbers, and client-side random numbers. Then, the server signs this digest value using its SM2 private key, obtaining a signature result. The server returns the signature result and the dynamic character mapping table to the client, allowing the client to verify the authenticity of the signature result using its SM2 public key upon receiving the dynamic character mapping table, confirming that the dynamic character mapping table has not been tampered with during transmission and that the server-side random numbers are trustworthy. If signature verification fails, the client determines that the dynamic character mapping table is untrustworthy and terminates the handshake.
[0049] It should be noted that if any verification step in the first or second handshake fails, the client or server will terminate the handshake process, and the secure soft keyboard will not enter the data input stage, thereby avoiding the receipt of sensitive user data input without a secure communication channel being established.
[0050] Third handshake The client generates a pre-master key, which is another random number generated by the client's secure random number generator, independent of the client's own random number. Specifically, the client's random number was generated and sent to the server during the second handshake, while the pre-master key is a different random number regenerated by the client during the third handshake. The client uses the ML-KEM quantum-resistant encryption public key to perform a key encapsulation operation on the pre-master key, generating corresponding ciphertext data. Simultaneously, the client encrypts the pre-master key using the SM2 public key, obtaining an SM2 encryption result. Further, the client uses the SM3 algorithm to perform a digest calculation on the combination of the SM2 encryption result, the ciphertext data, the client's random number, and the server's random number, obtaining signature data. The client digitally signs this signature data using its private key, obtaining a signature result. It should be noted that the client's private key is the SM2 private key corresponding to the client's certificate. This private key is generated and securely stored by the client during certificate issuance, used to prove the legitimacy of the client's identity and ensure the integrity of data during transmission. Finally, the client sends the SM2 encryption result, the ciphertext data, the client certificate, and the signature result to the server.
[0051] After receiving data from the client, the server first verifies the client's certificate to confirm its legitimacy. If the certificate verification is successful, the server decrypts the SM2 encryption result using the SM2 private key to obtain the pre-master key. If SM2 decryption fails, it indicates that the SM2 encryption result has been tampered with during transmission or the client used an incorrect public key, and the server terminates the handshake. The server then decrypts the ciphertext data using the ML-KEM quantum-resistant encryption private key to obtain the quantum-resistant shared key. Similarly, if decryption fails, it indicates that the ciphertext data is corrupted or the client used a mismatched public key during encapsulation, and the server again terminates the handshake. Once all verifications are successful, the server performs a key derivation operation using a key derivation function, taking the pre-master key, the quantum-resistant shared key, a client random number, and a server random number as input. Specifically, during the key derivation function's extraction phase, the above input data is mixed and calculated to generate the master key. During the key derivation function expansion phase, the master key is used to derive the SM4 encryption key, initialization vector, HMAC key, and CMAC key. These derived data collectively constitute the session key. Upon successful derivation, a success message is generated and returned to the client. In a specific example, the success message is the digest checksum obtained by the server using the SM3 algorithm to calculate the digest of all handshake messages. All handshake messages here include all handshake messages exchanged between the client and server during the first to third handshake processes, such as the ClientHello message, ServerHello message, server certificate, client certificate, and key exchange data. If key derivation fails, the server returns a failure message to the client, and the client re-initiates the third handshake. If the third handshake fails multiple times, the client displays the corresponding error message or terminates the handshake.
[0052] After receiving the derivation success message, the client, based on the same pre-master key, quantum-resistant shared key, client-side random number, and server-side random number, performs a key derivation operation using the same key derivation function to generate a session key identical to the server's. The client uses the SM3 algorithm to calculate the digest of all handshake messages recorded locally and compares the result with the digest checksum reflected in the derivation success message. If they match, it means that all messages during the three-way handshake process have not been tampered with, and the session keys derived by both parties are the same; the handshake is complete, and a secure communication channel is established between the client and the server. If they do not match, it indicates that a man-in-the-middle attack or message tampering may have occurred during the handshake process, and the client terminates the handshake.
[0053] At this point, the initialization phase is complete. A secure communication channel has been established between the client and the server, and a session key has been negotiated. The client has obtained the dynamic character mapping table and automatically enters the data input phase.
[0054] The data input phase is executed on the client side. When a user clicks a key on the security soft keyboard, the client captures the click event and obtains the actual character corresponding to that key. Then, it queries the dynamic character mapping table to find the mapping value corresponding to that actual character. For example, if the mapping value for the character 'a' in the dynamic character mapping table is 23, then the client converts the user-input character 'a' into the mapping value 23.
[0055] Throughout the input process, only obscured characters, such as asterisks or dots, are displayed in the client's input fields, instead of the actual characters entered by the user. Simultaneously, the client invokes the operating system's anti-screenshot interface upon startup of the secure soft keyboard, for example, by calling a pre-configured system security program. This program controls the current page to be in anti-screenshot and anti-screen recording mode. This dual security protection at both the display and system levels ensures the safety of users when entering sensitive data.
[0056] After a user inputs a character and completes the mapping value conversion, the client uses this mapping value as the current segment data and independently encrypts the segment data using the SM4 algorithm, generating an independent segment ciphertext. The client stores the generated segment ciphertexts sequentially into memory according to the input order. After each segment ciphertext is stored, the client immediately destroys the plaintext mapping value corresponding to that segment ciphertext, ensuring that the plaintext mapping value no longer remains in memory. The client continuously performs the above operations throughout the input process, performing independent encryption and storage for each character input. Because the mapping value corresponding to each character is destroyed after encryption, and the segment ciphertexts are stored in different areas of memory, there is no complete sequence of plaintext mapping values in memory.
[0057] It should be noted that because the segmented ciphertext is stored in memory in the order of user input, and each segment has a corresponding sequence identifier, the complete mapping value sequence can be recovered in the correct order during subsequent decryption and reassembly. Furthermore, sensitive data is usually passwords or verification codes, which are generally less than 30 characters long, limiting the number of segments and eliminating the problem of storage or reassembly chaos caused by a large number of segments.
[0058] After the user completes all the character input and clicks the submit button (e.g., the login or payment button), the data processing stage begins.
[0059] Upon entering the data processing stage, the client first reads the stored segmented ciphertext from memory and decrypts each segment using the SM4 algorithm to recover the corresponding mapping value. The client then concatenates these mapping values in the input order to form a complete overall mapping value. Next, the client encrypts the entire mapping value using the SM4 encryption key, generating an encrypted overall mapping value. Integrity verification information, including HMAC and CMAC verification codes, is then generated based on this encrypted overall mapping value. Specifically, the client calculates the HMAC verification code using the HMAC key and the CMAC verification code using the CMAC key. Both the HMAC and CMAC verification codes are used as integrity verification information. In practical applications, the integrity verification information may also include a hash fingerprint, a fixed-length digest value obtained by calculating the digest of the encrypted overall mapping value using the SM3 algorithm, used by the server to quickly verify data integrity.
[0060] Next, the client sends the encrypted overall mapping value and integrity verification information to the server through a secure communication channel. Immediately after data transmission, the client performs a memory cleanup operation, clearing all segmented ciphertext, the mapping values corresponding to each segmented ciphertext, the overall mapping value, and the session key stored in memory, ensuring that no sensitive data related to user input exists in the client's memory.
[0061] After receiving data from the client through a secure communication channel, the server performs integrity verification. Specifically, the server recalculates the received encrypted overall mapping value using the HMAC key and compares the recalculated result with the received HMAC verification code; it then recalculates the received encrypted overall mapping value using the CMAC key and compares the recalculated result with the received CMAC verification code. When both the HMAC and CMAC verification codes match, the server determines that the verification has passed. After the integrity verification passes, the server decrypts the encrypted overall mapping value using the SM4 encryption key to obtain the overall mapping value. It then queries the dynamic character mapping table, reconstructing each mapping value in the overall mapping value into its corresponding real character, and concatenates all the reconstructed real characters in order to obtain the complete sensitive data input by the user. The server then performs corresponding business operations based on this sensitive data, such as login authentication, payment verification, or identity authentication. If any verification fails, the server determines that the verification has failed, rejects the business request, and returns an error message to the client.
[0062] At this point, the data processing phase is complete. The server has obtained the actual characters input by the user and executed the corresponding business operations, while the client has cleared the sensitive data stored in memory after data transmission. Throughout the process, the sensitive characters input by the user are mapped and encrypted in segments during the client input phase, no complete plaintext remains during the storage phase, they undergo integrity verification and encryption protection during the transmission phase, and are promptly cleared at the end of their lifecycle, achieving end-to-end security protection for sensitive data from input to transmission to clearing.
[0063] It should be noted that the sequence numbers of the steps in the above embodiments do not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. In practical applications, all the above possible implementation methods can be arbitrarily combined in a combined manner to form possible embodiments of this application, which will not be described in detail here.
[0064] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute a secure keyboard encryption method of any of the above embodiments at runtime.
[0065] This application also provides a terminal device, including a processor and a memory, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute a secure keyboard encryption method of any of the above embodiments.
[0066] In an exemplary embodiment, a terminal device is provided, such as Figure 4 As shown, Figure 4 The terminal device shown includes a processor and a memory. The processor and memory are connected, for example, via a bus. Optionally, the terminal device may also include a transceiver, which integrates software programs or hardware such as applications, application programming interfaces (APIs), middleware, and kernels. It should be noted that in practical applications, the transceiver is not limited to one unit, and the structure of this terminal device does not constitute a limitation on the embodiments of this application.
[0067] The processor can be a CPU (Central Processing Unit), a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), a FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.
[0068] A bus can include a pathway for transmitting information between the aforementioned components or connecting these devices to hardware such as input / output interfaces, display devices, and communication interfaces. The bus can be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0069] The memory can be ROM (Read Only Memory), which is another type of static storage device that stores static information and instructions; RAM (Random Access Memory), which is another type of dynamic storage device that stores information and instructions; it can also be EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disk storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto.
[0070] The memory stores computer program code that executes the scheme of this application, and its execution is controlled by a processor. The processor executes the computer program code stored in the memory to implement the content shown in the foregoing method embodiments.
[0071] Terminal devices include, but are not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), and in-vehicle terminals (such as in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 4 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.
[0072] Those skilled in the art will clearly understand that the specific working process of the systems, devices, and modules described above can be referred to the corresponding process in the foregoing method embodiments. For the sake of brevity, it will not be repeated here.
[0073] Those skilled in the art will understand that the technical solution of this application, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several program instructions to cause an electronic device (such as a personal computer, server, or network device) to execute all or part of the steps of the methods described in the embodiments of this application when running the program instructions. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.
[0074] Alternatively, all or part of the steps of the foregoing method embodiments can be implemented by hardware (such as electronic devices like personal computers, servers, or network devices) associated with program instructions. The program instructions can be stored in a computer-readable storage medium. When the program instructions are executed by the processor of the electronic device, the electronic device executes all or part of the steps of the methods described in the embodiments of this application.
[0075] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that within the spirit and principles of this application, modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the corresponding technical solutions to leave the protection scope of this application.
Claims
1. A method for encrypting a secure keyboard, characterized in that, Applied to a client, the method includes: A three-way handshake is performed with the server to establish a secure communication channel and negotiate a session key, and to obtain the dynamic character mapping table generated by the server. The dynamic character mapping table is used to map the characters input by the user to the corresponding mapping values. The system receives characters input by the user via a secure soft keyboard and converts the characters into mapped values according to the dynamic character mapping table. The converted mapping value is segmented and encrypted in real time, and the encrypted segments are stored in memory. After the user completes the input, the segmented ciphertext is decrypted and concatenated to obtain the overall mapping value. The overall mapping value is then encrypted using the session key, and integrity verification information is generated. The encrypted overall mapping value and the integrity verification information are sent to the server through the secure communication channel. After the data is sent, the segmented ciphertext, the overall mapping value, and the session key stored in memory are cleared.
2. The encryption method for a secure keyboard according to claim 1, characterized in that, The three handshakes each include: First handshake: Send a handshake request to the server and receive the SM2 public key and ML-KEM quantum-resistant encryption public key generated by the server after receiving the handshake request; Second handshake: Send client information and client random number to the server, and receive the dynamic character mapping table and server random number returned by the server; The third handshake involves generating a pre-master key and encapsulating it using the ML-KEM quantum-resistant encryption public key to obtain corresponding ciphertext data. The pre-master key and the ciphertext data are then sent to the server. The server derives the session key based on the pre-master key, the client's random number, and the server's random number, and returns a success message upon successful derivation. In response to the success message, the client derives the same session key using the same algorithm.
3. The encryption method for a secure keyboard according to claim 2, characterized in that, The client derives the same session key based on the same algorithm, including: The master key is generated by mixing and calculating the pre-master key, the client random number, and the server random number using a key derivation function; The SM4 encryption key, HMAC key, and CMAC key are derived from the master key, and the session key is composed of the SM4 encryption key, the HMAC key, and the CMAC key.
4. The encryption method for a secure keyboard according to claim 3, characterized in that, The process for generating the integrity verification information is as follows: The HMAC key is used to calculate the encrypted overall mapping value to generate an HMAC verification code; The encrypted overall mapping value is calculated using the CMAC key to generate a CMAC verification code; The HMAC verification code and the CMAC verification code are used as the integrity verification information.
5. The encryption method for a secure keyboard according to claim 1, characterized in that, The real-time segmented encryption of the converted mapping value includes: The mapping value corresponding to each character is encrypted independently using the SM4 algorithm; Each encrypted segment of ciphertext is stored in a different memory region, so that there is no complete plaintext mapping value in memory.
6. A method for encrypting a secure keyboard, characterized in that, Applied to the server side, the method includes: A three-way handshake is performed with the client to establish a secure communication channel and negotiate a session key, generate a dynamic character mapping table and send it to the client. The dynamic character mapping table is used to map the characters input by the user to the corresponding mapping values. The encrypted overall mapping value and integrity verification information sent by the client are received through the secure communication channel. The encrypted overall mapping value is obtained by the client mapping, encrypting, and concatenating the user input characters based on the dynamic character mapping table, and then encrypting them as a whole using the session key. The encrypted overall mapping value is verified based on the integrity verification information; After the verification is successful, the encrypted overall mapping value is decrypted using the session key to obtain the overall mapping value; The overall mapping value is restored to the actual character input by the user based on the dynamic character mapping table, and the business operation corresponding to the actual character is executed.
7. The encryption method for a secure keyboard according to claim 6, characterized in that, The three handshakes each include: First handshake: In response to the handshake request sent by the client, generate an SM2 key pair and an ML-KEM quantum-resistant encryption key pair, return the SM2 public key and the ML-KEM quantum-resistant encryption public key, and save the private keys of both. Second handshake: Receive client information and client random number sent by the client, generate the dynamic character mapping table, and return the dynamic character mapping table and server random number to the client; Third handshake: Receive the pre-master key and ciphertext data sent by the client, derive the session key based on the pre-master key, the client's random number and the server's random number, and return a successful derivation message to the client after successful derivation.
8. The encryption method for a secure keyboard according to claim 7, characterized in that, The generation of the dynamic character mapping table includes: The client-side random number and the server-side random array are combined to form a random seed, and the server-side secure random number generator generates true random numbers based on the random seed; The true random number is used as a random source and input into the shuffling algorithm, which shuffles the order of the integer sequence to obtain a random arrangement; A one-to-one correspondence is established between the random arrangement and the 95 printable characters, which serves as the dynamic character mapping table.
9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the encryption method of the secure keyboard according to any one of claims 1 to 8 when it runs.
10. A terminal device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the encryption method of the secure keyboard according to any one of claims 1 to 8.
