A method and device for implementing a secure keyboard based on a honkong system

Abstract

The application discloses a kind of based on the realization method and device of safe keyboard of Hong Meng system, belong to information security technical field.The method includes: calling the device information interface of Hong Meng system obtains current device type;According to device type, create text input component, for the interface for obtaining key input for the text input component created Registration;In response to text input component obtains focus, calling the window privacy mode setting interface of Hong Meng system current window is set to private window mode;Pass through the interface of registration receives the key input of user;When the character key is contained in the key input information received, calling the increase character interface of encryption and decryption middleware generates new ciphertext;According to the data length of new ciphertext, the display content of text input component is updated to the mask character consistent with data length;Output new ciphertext.The application realizes the unified security input of soft keyboard and physical keyboard, effectively prevents the leakage of plaintext in input stage and screen capture attack.

Description

Technical Field

[0001] This invention belongs to the field of information security technology, and in particular relates to a method and device for implementing a secure keyboard based on the HarmonyOS system. Background Technology

[0002] HarmonyOS is a distributed operating system designed for all scenarios and widely used in mobile phones, tablets, smart screens, and IoT devices. In scenarios involving password input, payment verification, and digital identity authentication, users typically need to enter a personal identification code or password via a keyboard.

[0003] Currently, the keyboard that comes with HarmonyOS transmits characters in plaintext within the system when inputting passwords. The actual characters are briefly displayed in the input box, and there is no real-time encryption protection for the characters during the input process. For applications that require the use of security hardware, passwords must be encrypted during the input stage. Therefore, in applications that require the use of security hardware, the existing system keyboard poses a risk of plaintext password leakage during input.

[0004] Furthermore, existing technologies only support the replacement of soft keyboards with custom keyboards, lacking in-depth control over physical keyboard input. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method and apparatus for implementing a secure keyboard based on the HarmonyOS system.

[0006] According to a first aspect of the present invention, a method for implementing a secure keyboard based on the HarmonyOS system is provided, the method comprising: The secure keyboard component performs the following operations: Call the HarmonyOS system's device information interface to obtain the current device type; Create a text input component according to the device type, and register an interface for the created text input component to obtain key input before the system default input method processes it; In response to the text input component gaining focus, the window privacy mode setting interface of the HarmonyOS system is called to set the current window to privacy window mode; The user's key input information is received through the registered interface for obtaining key input. When the received key input information contains character keys, the encryption / decryption middleware's add character interface is invoked to generate new ciphertext; Based on the data length of the new ciphertext, update the display content of the text input component to a mask character of the same length; The new ciphertext is output through the external controller.

[0007] According to a second aspect of the present invention, a secure keyboard implementation device based on the HarmonyOS system is provided, the device comprising: The device adaptation module is used to call the HarmonyOS system's device information interface to obtain the current device type; The component building module is used to create a text input component according to the device type and register an interface for the created text input component to obtain key input before the system default input method processes it; The privacy protection module is used to call the window privacy mode setting interface of the HarmonyOS system to set the current window to privacy window mode when the text input component gains focus; The key input receiving module is used to receive user key input information through the registered key input interface; The encryption update module is used to call the add character interface of the encryption / decryption middleware to generate new ciphertext when the received key input information contains character keys; The mask display module is used to update the display content of the text input component with a mask character of the same length according to the data length of the new ciphertext; The ciphertext output module is used to output the new ciphertext through the external controller.

[0008] According to a third aspect of the present invention, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the secure keyboard implementation method based on the HarmonyOS system described in the first aspect.

[0009] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the secure keyboard implementation method based on the HarmonyOS system described in the first aspect.

[0010] The present invention has the following beneficial effects: (1) By calling the window privacy mode setting interface of HarmonyOS, the current window is automatically marked as a private window when the password is entered, thus preventing screen capture and recording from the operating system level; (2) A unified secure takeover of the soft keyboard and physical keyboard is achieved. By obtaining the device type, the corresponding interface for obtaining key input is registered according to the device type before the system default input method processes it. The input characters are all processed in real time by the encryption and decryption middleware, and all bypass the system default input method, which makes up for the lack of deep control over physical keyboard input in the existing technology; (3) A one-time password real-time encryption mechanism is implemented. Each character input calls the corresponding interface of the encryption / decryption middleware, and the processing is completed inside the middleware. The password is encrypted in real time during the input stage. External callers can only obtain the ciphertext through the controller and cannot access the plaintext, so the password input is safe and reliable. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of a secure keyboard implementation method based on the HarmonyOS system in Embodiment 1 of the present invention.

[0013] Figure 2 This is a flowchart illustrating the method for initializing the secure keyboard component on a mobile device in Embodiment 2 of the present invention.

[0014] Figure 3 This is a schematic diagram of the method flow for the interaction between the secure keyboard component on the mobile terminal and the user in Embodiment 2 of the present invention.

[0015] Figure 4 This is a flowchart illustrating the method for initializing the secure keyboard component on a PC in Embodiment 3 of the present invention.

[0016] Figure 5 This is a schematic diagram of the implementation method of the secure keyboard component on the PC in Embodiment 3 of the present invention.

[0017] Figure 6 This is a schematic diagram of the implementation method of the secure keyboard when inputting via a physical keyboard on a PC in Embodiment 4 of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0019] In the description of this invention, it should be noted that the terms "first," "second," etc., are used only for descriptive purposes and should not be construed as indicating or implying relative importance or order. In the following embodiments, the HarmonyOS version involved is HarmonyOS 5.0 and above. Those skilled in the art will understand that the technical solutions of this invention are also applicable to subsequent versions of HarmonyOS and other operating system environments that support the same component interface framework. The encryption algorithm involved in the embodiments preferentially adopts the Chinese national standard SM4 symmetric encryption algorithm, with a key length of 128 bits, encryption mode CBC, and padding method PKCS7. The key is obtained from the server or Bluetooth Key through a secure channel.

[0020] This invention provides a method for implementing a secure keyboard based on the HarmonyOS system, applicable to smart devices equipped with the HarmonyOS system.

[0021] The "HarmonyOS" mentioned in this invention is a holistic concept, encompassing the underlying HarmonyOS kernel and related system services (window management, display management, input method management, clipboard services, etc.), as well as the application development framework (ArkUI) running on the HarmonyOS. HarmonyOS provides developers with declarative components, lifecycle management, state management, event callback mechanisms, and encapsulated interfaces for underlying system services (such as modules like window, display, and componentUtils) through ArkUI. For simplicity, "HarmonyOS interface" or "system interface" as used below refers to functional interfaces supported by the underlying operating system that can be called through ArkUI; the "system callbacks" (such as onFocus and onKeyPreIme) are also automatically triggered by HarmonyOS when the corresponding events occur. The secure keyboard component of this invention fully complies with the component specifications and operating environment of HarmonyOS, and each step in the following embodiments is executed within this overall framework.

[0022] The secure keyboard component provided by this invention is a custom component encapsulated in the HarmonyOS framework, which includes a text input component, encryption / decryption middleware (running in the native layer), and a controller.

[0023] The text input component includes the native text input component TextInput provided by the HarmonyOS system. During development, the chained properties of the TextInput component are pre-configured, and the functionality of the secure keyboard component is implemented through the chained properties of TextInput.

[0024] The controller is the interface provided by the secure keyboard component. The interface includes clearText(), getEncPin(), getLength(), stopEditing(), openSoftKeyboard(), hideSoftKeyboard(), etc. External components (such as pages and parent components) can interact with the secure keyboard component by calling the interface.

[0025] The encryption / decryption middleware (keyboardNative) runs in a trusted execution environment or secure memory, providing interfaces such as SetEncKeyAndWay (set key and algorithm), SetMaxLength (set maximum length), Reset (clear buffer), AddKey (add character), DelKey (delete character), and GetKey (get ciphertext) for internal calls by the secure keyboard component. Example 1

[0026] Embodiment 1 of this invention provides a method for implementing a secure keyboard based on the HarmonyOS system, such as... Figure 1 As shown, the method includes: The secure keyboard component performs the following operations: Step S1: Call the HarmonyOS system's device information interface to obtain the current device type; Step S2: Create a text input component according to the device type, and register an interface for the created text input component to obtain key input before the system default input method processes it; In this embodiment, if the current device type is a mobile device, a custom keyboard construction function is bound to the text input component. The custom keyboard construction function is an interface for obtaining key input, which is used to automatically generate and pop up the soft keyboard when the text input component gains focus. The click event on the soft keyboard is bound to the implementation method inside the secure keyboard component so as to obtain key input information before the system default input method processes it. If the current device type is PC, then register the key pre-input event callback provided by HarmonyOS for the text input component; the key pre-input event callback is an interface for obtaining key input, used to receive key input information entered by the user through the physical keyboard, process the key input information and return a response to the system, so as to intercept key input events before the system's default input method processes them;

[0027] Specifically, a text input component is created according to the device type, and an interface for obtaining key input before the system default input method processes the text input component is registered, including: if the current device type is a PC, a focus processing function is registered for the text input component, and the focus processing function is the interface for obtaining key input; The method also includes: in response to the text input component gaining focus, performing the following operations through the focus handling function: The window creation function of the HarmonyOS system is called to create a child window with a soft keyboard interface, with the main window of the current application as the parent window. The character keys in the soft keyboard interface of the child window are pre-bound to callback functions that call the internal implementation methods of the secure keyboard component. When a user touches or clicks a key on the soft keyboard interface in the child window, the implementation method inside the secure keyboard component is executed according to the bound callback function.

[0028] Furthermore, creating a child window displaying a soft keyboard interface with the current application's main window as the parent window specifically includes: Call the HarmonyOS component location query interface to obtain the position information of the text input component on the screen; adaptively adjust the display position and size of the child window according to the position information so that the child window does not exceed the visible range of the screen and does not obscure the text input component; load the soft keyboard interface in the child window.

[0029] Step S3: In response to the text input component gaining focus, call the HarmonyOS system's window privacy mode setting interface to set the current window to privacy window mode; Step S4: Receive the user's key input information through the registered key input interface; In one feasible manner, the key pre-input event callback is also used to perform at least one of the following operations: Intercept key combinations used for copy, paste, or select all; Ignore the arrow keys used to move the cursor and force the input cursor to be fixed at the end of the entered content; Verify whether the key input information is within the preset allowed character set; if not, reject the input.

[0030] Step S5: When the received key input information contains character keys, call the add character interface of the encryption / decryption middleware to generate new ciphertext; Specifically, the process of calling the encryption / decryption middleware's add-character interface to generate new ciphertext includes: When the add character interface of the encryption / decryption middleware is called, the encryption / decryption middleware reads the currently stored ciphertext in the internal buffer and determines whether the read data is empty; If not empty, the preset encryption and decryption algorithm and key are used to decrypt the read ciphertext to obtain plaintext. The character value passed when calling the add character interface is appended to the end of the plaintext as new plaintext. The encryption and decryption algorithm and key are used to encrypt the new plaintext to obtain new ciphertext. The new ciphertext is then used to replace the ciphertext stored in the internal buffer.

[0031] One feasible approach is to call the deletion character interface of the encryption / decryption middleware to generate new ciphertext when the received key input is the delete key. The specific steps involved in generating new ciphertext by calling the character deletion interface of the encryption / decryption middleware are as follows: When the character deletion interface of the encryption / decryption middleware is called, the encryption / decryption middleware reads the currently stored ciphertext in the internal buffer, uses the preset encryption / decryption algorithm and key to decrypt the obtained ciphertext to obtain plaintext, deletes the last character of the plaintext to obtain new plaintext, and determines whether the new plaintext is empty. If it is not empty, use the encryption and decryption algorithm and key to encrypt the new plaintext to obtain the new ciphertext, and replace the ciphertext stored in the internal buffer with the new ciphertext. If the buffer is empty, the ciphertext in the internal buffer will be set to empty.

[0032] Step S6: Update the display content of the text input component to a mask character of the same length according to the data length of the new ciphertext; Specifically, step S6 includes: modifying the mask string variable decorated by the HarmonyOS state management decorator according to the data length of the new ciphertext, so that the HarmonyOS system automatically refreshes the display content of the text input component after detecting that the mask string variable has changed;

[0033] One possible implementation, after step S6, further includes: the secure keyboard component moving the cursor of the text input component to the end of the mask character.

[0034] Step S7: Output the new ciphertext through the external controller.

[0035] In this embodiment, the method further includes: in response to the text input component losing focus, calling the window privacy mode setting interface of the HarmonyOS system to close the privacy window mode and restore the screenshot and screen recording permissions; Alternatively, in response to the destruction of the secure keyboard component, the window privacy mode setting interface can be called to disable the privacy window mode.

[0036] It should be noted that this invention supports three implementation methods (mobile terminal, PC soft keyboard, and PC physical keyboard). In actual operation, the secure keyboard component obtains the current device type (such as mobile phone, tablet, or PC) by calling the device information interface provided by the HarmonyOS system during the initialization phase. Based on the device type, it registers an interface for the created text input component to obtain key input before the system default input method processes it. If the obtained device type is a mobile phone or tablet, the secure keyboard component uses the mobile terminal mode described in Embodiment 2 to register the interface for obtaining key input before the system default input method processes it. If the device type is a PC, it uses the mode described in Embodiment 3 (PC soft keyboard) or Embodiment 4 (PC physical keyboard) to register the interface for obtaining key input before the system default input method processes it. Example 2

[0037] This second embodiment describes a method for implementing a secure keyboard on a mobile device (phone or tablet).

[0038] like Figure 2 As shown, this is the initialization process of the secure keyboard component in a secure keyboard implementation method based on the HarmonyOS system provided by the present invention. When the aboutToAppear() lifecycle method of the secure keyboard component is called by the HarmonyOS system, the secure keyboard component executes step 101. When the build() method of the secure keyboard component is called by the HarmonyOS system, the secure keyboard component executes step 102. When the onReady() method of the secure keyboard component is called by the HarmonyOS system, the secure keyboard component executes step 103. Step 101: Obtain the current device type. If the device type is mobile, set the internal flag to "mobile mode". Call the HarmonyOS system interface to obtain the current window instance. Call the privacy mode setting method of the current window instance and pass in the value. Bind the method of the externally passed controller to the internal implementation method. Call the interface of the encryption / decryption middleware and set the attribute value of the encryption / decryption middleware according to the attribute value passed in from the outside. One feasible way to obtain the current device type is to call the device information interface provided by the HarmonyOS system (the interface is: deviceInfo.deviceType), obtain the device type string returned by the interface (for example, the string is 'phone' for mobile devices and '2in1' for PC devices), and determine the current device type based on the device type string; One feasible approach involves calling the HarmonyOS system interface: window.getLastWindow(), and setting the privacy mode using the method: window.setWindowPrivacyMode(), with the value passed as true. This execution step is used to notify the HarmonyOS system to mark the current window as a privacy window, prohibiting any application from taking screenshots or recording the screen of the current window.

[0039] In this embodiment, binding the methods of the externally passed controller with the internal implementation methods specifically involves the secure keyboard component obtaining the externally passed controller instance and binding each method of that controller instance (including but not limited to clearing input, obtaining encrypted text, obtaining length, stopping editing, opening the soft keyboard, and hiding the soft keyboard) with the corresponding implementation methods within the secure keyboard component using closures. Thus, all calls initiated externally through the controller are routed to the actual processing logic within the secure keyboard component, achieving loose coupling between the external interface and the internal implementation.

[0040] In this embodiment, the lifecycle methods of the secure keyboard component are invoked before the secure keyboard component saves externally passed attribute values; Specifically, when declaring the secure keyboard component, the external business code (parent component) passes configuration parameters to the secure keyboard component through the tag attribute. The HarmonyOS system then passes the attribute values ​​to the member variables of the secure keyboard component, which then saves them.

[0041] Furthermore, the attribute values ​​include: key, encryption / decryption algorithm type, maximum input length value, random layout switch, random number on the alphabet keyboard switch, key press feedback switch, completion callback function, focus callback function, focus loss callback function, and controller binding identifier; One feasible approach is to call the interface of the encryption / decryption middleware and set the attribute values ​​of the encryption / decryption middleware according to the attribute values ​​passed in from the outside. Specifically, the approach is to call the key setting interface to write the key passed in from the outside into the encryption / decryption middleware, call the algorithm interface to write the encryption / decryption algorithm type passed in from the outside into the encryption / decryption middleware, call the maximum length setting interface to write the maximum length value of the input passed in from the outside into the encryption / decryption middleware, and call the reset interface to clear the historical data in the encryption / decryption middleware. Specifically, the interface for setting the maximum length is: SetMaxLength; The reset interface is: Reset().

[0042] Step 102: Create a vertical layout container and place a text input component (i.e., TextInput) in the vertical layout container. Set the properties of the text input component according to the attribute values ​​passed in from the outside. Bind the text input component to the custom keyboard construction function of the HarmonyOS system as an interface for obtaining key input before the system's default input method processes it.

[0043] Specifically, the `customKeyboard` method is called to bind a custom constructor to the text input component. This constructor implements the keyboard layout, keys, and key click events. When the text input component gains focus, the framework automatically calls this constructor to dynamically generate and display the custom keyboard interface.

[0044] A custom constructor is used to bind the safe keyboard component's `addChar` method to each character key's click / touch event and pass in the key value. It also binds the safe keyboard component's `deleteChar` method to the delete key and an externally passed `doneAction` callback to the completion key (this callback is already stored as a member variable in the component). Because the custom constructor is defined inside the safe keyboard component, it can capture the safe keyboard component's `this` context through closures, thus directly calling the safe keyboard component's internal methods. When the user clicks a key on the custom keyboard, the safe keyboard component's internal methods are called, without requiring an additional callback function.

[0045] In one implementable manner, step 102 further includes: the secure keyboard component registering other event callback functions for the text input component;

[0046] Specifically, the event callback functions include: handleFocus (focus handling function), handleBlur (out-of-focus handling function), forceMask (force mask verification function), doneAction callback, and caretToEnd (cursor end function). Furthermore, the `.onFocus(this.handleFocus)` method of the HarmonyOS system is called to bind the `handleFocus` (focus handling function) to the focus event of the text input component. When the text input component gains focus, the system automatically executes this function to reset the state, pop up the keyboard, etc.

[0047] The `.onBlur(this.handleBlur)` method of the HarmonyOS system is called to bind `handleBlur` (the focus loss handling function) to the focus loss event. This function is automatically executed by the system when the text input component loses focus.

[0048] The `.onChange(this.forceMask)` method of the HarmonyOS system is called to bind `forceMask` (the forced mask validation function) to the text change event. When the content of the text input component changes, the system automatically executes this function to ensure that the mask format is correct.

[0049] The `.onSubmit(this.doneAction)` method of the HarmonyOS system is called to bind the externally passed-in `doneAction` callback to the submit event. When the user presses the submit key on the keyboard (such as Enter), the system automatically executes this callback;

[0050] The `.onTouch(this.caretToEnd)` and `.onClick(this.caretToEnd)` methods of the HarmonyOS system are called to bind `caretToEnd` (the cursor end function) to touch and click events. When the user touches or clicks the text input component, the system automatically executes this function to force the cursor to the end.

[0051] One feasible approach is to set the properties of the text input component through a chained method. The properties to be set include width, height, maximum input length, copy option, and text selection menu mode. Specifically, the copy option is set to disable copying, and the text selection menu mode is set to hidden to enhance security.

[0052] Step 103: Call the controller's focus acquisition method, which internally calls the HarmonyOS system's focus management interface to make the text input component gain focus.

[0053] Specifically, after the secure keyboard component and its child components are mounted to the rendering tree, the onReady() method of the secure keyboard component is called by the system. When the default focus setting is true externally, the controller's focus acquisition method is called. This method internally calls the HarmonyOS system's focus management interface to make the text input component gain focus.

[0054] like Figure 3 As shown, the user interaction phase of the secure keyboard component includes: Step 201: When the focus handling function of the secure keyboard component is called by the HarmonyOS system, the secure keyboard component performs a reset operation and pops up the custom keyboard; In this embodiment, when a user taps the text input component area on the screen, the HarmonyOS touch event handling mechanism captures the touch point and converts it into a focus request event. Based on the identifier of the text input component, the system determines that the component currently needing focus is the TextInput component within the secure keyboard component. The HarmonyOS then calls the registered callback function, namely the focus handling function handleFocus within the secure keyboard component.

[0055] One feasible approach is for the secure keyboard component to perform a reset operation by calling its internal reset function `reset()`.

[0056] Specifically, the reset function reset() performs the following: calls the reset interface of the encryption / decryption middleware, clears any remaining historical password data, calls the SetEncKeyAndWay() interface to reset the key and algorithm (ensuring that the latest key is used for this input), clears the internally maintained mask string inputValue, and sets the length variable mInputTextLen to 0.

[0057] Because a build function has already been bound to the TextInput component during the initialization phase of the secure keyboard component's `build()` method, the HarmonyOS system automatically calls the custom build function after detecting that the text input component has focus. This custom build function dynamically generates the complete interface of the custom secure keyboard (including character keys, delete key, finish key, and random layout, etc.) and displays it below the text input component or in an appropriate position on the screen. At this point, the user can see that the custom keyboard has popped up, ready for input.

[0058] One feasible approach, after completing the above reset operation and keyboard pop-up, also includes: the secure keyboard component checking whether an onFocusAction callback function has been passed in from outside; if so, the onFocusAction callback function is called, where external business code can perform operations such as instrumentation and clearing prompts.

[0059] By following the steps above, when a user clicks the text input component, the internal state of the secure keyboard component is cleared, and a custom secure keyboard is obtained, allowing the user to start entering their password.

[0060] Step 202: When a key on the custom keyboard is touched or clicked by the user, the secure keyboard component determines the key type. If the key type is a character key, proceed to step 203; if the key type is a delete key, proceed to step 206; if the key type is a finish key, proceed to step 208. In this embodiment, when a user clicks or touches a key on the custom keyboard, the HarmonyOS system passes the touch event to the onClick listener that is pre-bound in the custom constructor. The secure keyboard component determines the key type based on the data listened to by the onClick listener and executes different processing logic according to different key types (character key, delete key, and finish key).

[0061] Step 203: The secure keyboard component calls the addChar (add character) method and passes the character corresponding to the key (such as '5') as a parameter.

[0062] Step 204: The secure keyboard component uses the addChar method to determine whether the current password data length has reached the maximum length. If yes, the process ends; otherwise, proceed to step 205.

[0063] Step 205: Call the AddKey interface of the encryption / decryption middleware, pass the character as a parameter, and modify the mask string variable inputValue decorated by the HarmonyOS system state management decorator @State to change the attribute value in the text input component, thereby increasing the mask character in the page text input component.

[0064] One feasible approach is to perform the following steps when the AddKey interface of the encryption / decryption middleware is called: Step 2051: The encryption / decryption middleware reads the currently stored ciphertext byte array M in the internal buffer, and determines whether the ciphertext byte array is empty. If it is not empty, proceed to step 2052; if it is empty, proceed to step 2053.

[0065] In this embodiment, if this is the first input, M is empty.

[0066] Step 2052: Decrypt the ciphertext byte array M using the preset SM4 decryption algorithm and session key to obtain the plaintext string P_old of the currently entered password. Append the new character '5' to the end of the plaintext string P_old as the new plaintext string P_new, and proceed to step 2054.

[0067] Step 2053: Use the new character '5' as the new plaintext string P_new, and proceed to step 2054.

[0068] Step 2054: Encrypt the new plaintext string P_new using the SM4 encryption algorithm and the session key to obtain a new ciphertext byte array M_new. Write M_new into the internal buffer or replace the original ciphertext byte array M.

[0069] Throughout the entire process of processing the characters described above, no external entity can obtain any plaintext in any intermediate state.

[0070] In this embodiment, after the HarmonyOS system detects a change in the @State variable, it automatically re-executes the initialization operations related to TextInput in build() and refreshes the interface display, which can realize the change of the mask character in the text input component; for example, if the original mask character in the text input component is "●●", after modification, a mask character "●" is added to the text input component to become "●●●".

[0071] At this point, the length variable mInputTextLen is also automatically incremented by 1.

[0072] In this embodiment, step 205 further includes: the secure keyboard component obtaining the ciphertext stored in the encryption / decryption middleware and modifying the string type variable mEncPwd modified by the HarmonyOS two-way data binding decorator @Link; Specifically, the value of the string type variable is set to the hexadecimal data of the obtained ciphertext; Specifically, after the secure keyboard component modifies a variable, the HarmonyOS system automatically passes the value of that variable to the variable bound in the parent component, allowing external systems to perceive changes in the ciphertext in real time.

[0073] In this embodiment, step 205 further includes: Step 2055: When the forced mask verification function of the secure keyboard component is called by the HarmonyOS system, the expected mask length is calculated based on the length variable. It is then determined whether the length of the mask characters displayed in the current text input component is equal to the expected mask length. If they are not equal, the state variable is modified to the expected mask length so that the change of the attribute value in the text input component realizes the change of the mask characters in the page text input component. Step 2056 is then executed. If they are equal, step 2056 is then executed.

[0074] Because the secure keyboard component registers a callback function (i.e., the component's forceMask function) through .onChange(), the system automatically calls this callback function when the text in the text input component changes.

[0075] Step 2056: The secure keyboard component calls the TextInputController.caretPosition(mInputTextLen) function to position the cursor at the end.

[0076] Ensure the cursor is at the end of all dots to prevent the user from moving the cursor to the middle to insert characters.

[0077] Step 206: The secure keyboard component calls the deleteChar (delete character) method to determine if the length of the current password is greater than 0. If it is, proceed to step 207; otherwise, end the process.

[0078] Step 207: Call the DelKey interface of the encryption / decryption middleware to modify the mask string variable inputValue in the state decorator @State, so that the attribute value in the text input component changes and the mask characters in the page text input component are reduced.

[0079] One feasible approach is to perform the following steps when the DelKey interface of the encryption / decryption middleware is invoked: Step 2071: The encryption / decryption middleware reads the current ciphertext M from the internal buffer, and decrypts the read ciphertext using a preset algorithm and key pair to obtain the plaintext P_old.

[0080] Step 2072: Delete the last character of plaintext P_old to get the latest plaintext P_new. Determine if the latest plaintext is empty. If it is, set the ciphertext in the internal buffer to empty. Otherwise, proceed to step 2073. Step 2073: Encrypt the latest plaintext P_new using the preset algorithm and key to obtain the new ciphertext M_new and replace the ciphertext in the internal buffer.

[0081] In this embodiment, after the HarmonyOS system detects the change of the @State variable, it automatically re-executes the initialization operations related to TextInput in build() and refreshes the interface display, which can realize the change of the mask character in the text input component; for example, if the original mask character in the text input component is "●●●", after modification, one mask character "●" is removed from the text input component and it becomes "●●".

[0082] At this point, the length variable mInputTextLen is also automatically decremented by 1.

[0083] In this embodiment, step 207 further includes: the secure keyboard component obtaining the ciphertext stored in the encryption / decryption middleware and modifying the string type variable mEncPwd modified by the two-way data binding decorator @Link; Specifically, the value of the string type variable is set to the hexadecimal data of the obtained ciphertext; Specifically, after the secure keyboard component modifies a variable, the HarmonyOS system automatically passes the variable value to the variable bound in the parent component, allowing external systems to perceive changes in the ciphertext in real time.

[0084] In this embodiment, step 207 further includes: Step 2074: When the forced mask verification function of the secure keyboard component is called by the HarmonyOS system, the expected mask length is calculated based on the length variable. It is then determined whether the length of the mask characters displayed in the current text input component is equal to the expected mask length. If they are not equal, the state variable is modified to the expected mask length so that the change of the attribute value in the text input component realizes the change of the mask characters in the page text input component. Step 2075 is then executed. If they are equal, step 2075 is then executed.

[0085] Because the secure keyboard component registers a callback function (i.e., the component's forceMask function) via .onChange(), the system automatically calls this callback function when the text in the text input component changes.

[0086] Step 2075: The secure keyboard component calls the TextInputController.caretPosition(mInputTextLen) function to position the cursor at the end.

[0087] Ensure the cursor is at the end of all mask characters to prevent the user from moving the cursor to the middle to insert characters.

[0088] Step 208: The secure keyboard component calls the externally passed-in doneAction callback.

[0089] In this embodiment, within the `doneAction` callback, the external controller can call the `getEncPin()` interface to obtain the ciphertext (hexadecimal string) of the current password and submit it to the server for verification. The secure keyboard component itself does not automatically clear the password or close the keyboard; the external controller can call `clearText()` or `stopEditing()` to close the keyboard as needed.

[0090] In this embodiment, it also includes: when the focus loss handling function of the security keyboard component is called by the system, the security keyboard component calls the external focus loss callback; Specifically, when a user clicks on an area outside the text input component, the system calls the handleBlur (out-of-focus handling function) method bound to .onBlur(this.handleBlur), which invokes the external out-of-focus callback.

[0091] In this embodiment, it also includes: when the page is closed or the secure keyboard component is removed, the aboutToDisappear() method of the secure keyboard component is called by the system, the secure keyboard component calls the system's window privacy mode setting interface and passes in a value (which indicates that the privacy mode is turned off), and notifies the system that the screenshot / screen recording permission of the window has been restored.

[0092] In this embodiment, it also includes: when the clear input method of the secure keyboard component is called externally, the secure keyboard component calls the reset interface and key and algorithm setting interface of the encryption and decryption middleware to clear the mask string and length, and the text input component interface is updated.

[0093] When the secure keyboard component's ciphertext retrieval method is called externally, the secure keyboard component calls the encryption / decryption middleware's ciphertext retrieval interface, which returns a hexadecimal string of the ciphertext.

[0094] When the stop editing method of the secure keyboard component is called externally, the secure keyboard component calls the stop editing interface of the system's text input component controller, causing the text input component to lose focus and the custom keyboard to be collapsed.

[0095] One possible implementation is to use a non-exportable encryption key that is generated and securely stored via KeyStore or Universal KeystoreKit.

[0096] One possible implementation is that the secure keyboard component can encrypt the data input by keystrokes using a HarmonyOS encryption framework (such as @kit.SecurityCryptoFramework).

[0097] One possible implementation is that the encrypted ciphertext can be stored in the memory of the secure keyboard component. Example 3

[0098] This embodiment three describes the implementation method of the secure keyboard on a HarmonyOS PC device when a user clicks the soft keyboard with a mouse for input. The premise for the execution of this embodiment method is that when the aboutToAppear() interface is called during the initialization phase of the secure keyboard component, the device type is obtained through the device information interface as PC, and the external configuration or user selection is set to soft keyboard mode (or the soft keyboard and physical keyboard are allowed to coexist).

[0099] like Figure 4 As shown, the initialization phase of the secure keyboard component includes: When the aboutToAppear() lifecycle method of the secure keyboard component is called by the HarmonyOS system, step 301 is executed; when the build() method of the secure keyboard component is called by the HarmonyOS system, step 302 is executed; when the onReady() method of the secure keyboard component is called by the HarmonyOS system, step 303 is executed. Step 301: Obtain the current device type. If the device type is PC, set the internal flag to "PC mode". Call the HarmonyOS system interface to obtain the current window instance. Call the privacy mode setting method of the current window instance and pass in the value. Bind the method of the externally passed controller to the internal implementation method. Call the encryption / decryption middleware interface. Set the attribute value of the encryption / decryption middleware according to the attribute value passed in from the outside. Create a soft keyboard callback function. One feasible way to create a soft keyboard callback function is as follows: the secure keyboard component creates a soft keyboard instance and binds the callback function in the instance to an internal method; Specifically, the soft keyboard callback functions include add character callback, delete character callback, completion callback, close callback, gain focus callback, and set callback; Furthermore, binding the callback functions in the example to the internal methods specifically involves: binding the add character callback to the internal addChar (add character) method, binding the delete character callback to the internal deleteChar (delete character) method, binding the action completion callback to the external doneAction callback, binding the close callback to the closeSoftKeyboard (close soft keyboard) method, binding the focus callback to the focus method of the text input component, and binding the set callback to the method that returns a component property or calls the encryption library to obtain a random key array;

[0100] The soft keyboard callback function is passed to the child window page when the child window is created, and is invoked when a key is clicked.

[0101] Step 302: Create a vertical layout container and place a text input component (i.e., TextInput) in the vertical layout container. Set the properties of the text input component according to the attribute values ​​passed in from the outside. Register an event callback function for the text input component. Use the registered focus handling function as the interface to get key input. Define and bind state variables. One feasible approach is to set the properties of the text input component through a chained method. The properties to be set include width, height, maximum input length, copy option, and text selection menu mode. Specifically, the copy option is set to disable copying, and the text selection menu mode is set to hidden to enhance security; In this embodiment, unlike the mobile version, it is not necessary to bind a custom keyboard construction function; One feasible approach is to register event callback functions including: handleFocus (focus handling function), handleBlur (out-of-focus handling function), forceMask (force mask verification function), doneAction callback, and caretToEnd (cursor end function). Specifically, the `.onFocus(this.handleFocus)` method is called to bind `handleFocus` (the focus handling function) to the focus event of the text input component. When the text input component gains focus, the HarmonyOS system automatically executes this focus handling function, which calls `openSoftKeyboard()` to create and display a child window.

[0102] Call the `.onBlur(this.handleBlur)` method to bind `handleBlur` (the focus loss handling function) to the focus loss event. When the text input component loses focus, the system automatically executes this focus loss handling function, which calls `closeSoftKeyboard()` to destroy the child window.

[0103] Call the `.onChange(this.forceMask)` method to bind `forceMask` (the mandatory mask validation function) to the text change event. When the content of the text input component changes, the system automatically executes this mandatory mask validation function to ensure the mask format is correct.

[0104] Call the `.onSubmit(this.doneAction)` method to bind the externally passed-in `doneAction` callback to the submit event. When the user presses the submit key (such as Enter), the system automatically executes the `doneAction` callback.

[0105] Call the `.onTouch(this.caretToEnd)` and `.onClick(this.caretToEnd)` methods to bind `caretToEnd` (the cursor end function) to the touch and click events. When the user touches or clicks the text input component, the system automatically executes this cursor end function, forcing the cursor to the end.

[0106] Specifically, defining and binding state variables includes: the secure keyboard component defines a string variable inputValue modified by @State to store the mask string (composed of several dots "●") displayed in the page text input component; and defines a string variable mEncPwd modified by @Link to establish a two-way binding with the state variable passed in from the parent component via the $ syntax for synchronizing ciphertext. The inputValue is then bound to the display content of the TextInput through the chained method .text(this.inputValue).

[0107] Step 303: Call the controller's focus acquisition method, which is used to call the HarmonyOS system's focus management interface to make the text input component gain focus.

[0108] Specifically, after the secure keyboard component and its child components are mounted to the rendering tree, the onReady() method of the secure keyboard component is called by the system. When the default focus setting is true externally, the secure keyboard component calls the controller's focus acquisition method. This method internally calls the HarmonyOS system's focus management interface to make the text input component gain focus.

[0109] Furthermore, once the text input component gains focus, the handleFocus function bound to .onFocus is triggered, which in turn calls openSoftKeyboard() to create a child window.

[0110] like Figure 5 The diagram shows the implementation process of the secure keyboard component on the PC, specifically including: Step 401: When the focus handling function of the secure keyboard component is called by the system, the secure keyboard component calls the openSoftKeyboard() function to create a child window with the soft keyboard interface displayed, with the current application's main window as the parent window. The character keys in the soft keyboard interface of the child window are pre-bound to callback functions that call the internal implementation methods of the secure keyboard component. In this embodiment, when the user clicks the TextInput component, the focus callback function of the secure keyboard component is called by the HarmonyOS framework, and the secure keyboard component executes step 401. Specifically, creating a child window displaying a soft keyboard interface with the current application's main window as the parent window includes: Step 4011: The secure keyboard component obtains the position information of the text input component on the screen.

[0111] The secure keyboard component calls the component location query interface provided by the HarmonyOS system (this.getUIContext().getComponentUtils().getRectangleById("myInputId")) to obtain the precise rectangular area information of the text input component on the screen;

[0112] The obtained position information includes: the X coordinate of the top left corner of the text input component relative to the top left corner of the screen (unit: pixels), the Y coordinate of the top left corner of the text input component relative to the top left corner of the screen (unit: pixels), the width of the text input component (unit: pixels), and the height of the text input component (unit: pixels).

[0113] Meanwhile, the secure keyboard component obtains the total width and height (in pixels) of the current device screen through the HarmonyOS window management interface.

[0114] Step 4012: Calculate the default display position of the child window.

[0115] The secure keyboard component calculates the default display position of child windows based on the position information of the text input component, using the following strategy: (1) By default, the top left corner of the child window is positioned at the bottom right corner of the text input component;

[0116] The specific calculation method is as follows: Child window X coordinate = Text input component X coordinate + Text input component width; Child window Y coordinate = Text input component Y coordinate + Text input component height;

[0117] (2) Determine the width (e.g., 350 pixels) and height (e.g., 280 pixels) of the sub-windows according to the design dimensions of the soft keyboard interface layout.

[0118] The soft keyboard interface contains four rows of keys: the first row contains number keys 1-9 (arranged in 3×3), the second row contains number key 0, symbol key "." and backspace key, the third row contains letter toggle labels, and the fourth row contains the confirmation key;

[0119] In this embodiment, the default position may cause the soft keyboard to be outside the visible range of the screen or not be fully displayed due to insufficient space. Therefore, this embodiment also includes: the safe keyboard component performs boundary detection based on the calculated default display position to determine whether the default position is outside the visible range of the screen. If so, the size of the soft keyboard will be adjusted. Specifically, the secure keyboard component performs boundary detection based on the calculated default display position to determine whether the default position exceeds the visible area of ​​the screen, including: Step M1: Detect the right boundary; If the child window's X coordinate + child window width > total screen width, it means there isn't enough horizontal space on the right side of the text input component to fully display the soft keyboard. In this case, adjust the child window's X coordinate to: total screen width – child window width, so that the soft keyboard is displayed flush with the right edge of the screen.

[0120] Step M2: Detect the bottom boundary; If the sum of the child window's Y-coordinate and its height is greater than the total screen height, it means there isn't enough vertical space below the text input component to fully display the soft keyboard. In this case, prioritize displaying the child window above the text input component, i.e., adjust the child window's Y-coordinate to the difference between the text input component's Y-coordinate and the child window's height. If there is still insufficient space above the text input component (i.e., the adjusted Y-coordinate is less than 0), then adjust the Y-coordinate to the difference between the total screen height and the child window's height, so that the soft keyboard is displayed flush against the bottom of the screen.

[0121] Step M3: Overlap detection; Check if the adjusted child window display area overlaps with the main visible area of ​​the text input component. If overlap exists and affects the visibility of the text input component, further fine-tune the child window position to ensure it does not obstruct the text input component;

[0122] In this embodiment, adjusting the size of the soft keyboard specifically involves scaling the soft keyboard interface proportionally.

[0123] Specifically, the scaling ratio is calculated as follows: the smaller of the ratio of available horizontal space to the designed width of the soft keyboard and the ratio of available vertical space to the designed height of the soft keyboard is used as the scaling ratio. The scaling ratio should not be less than 80% of the original size; if it is less than 80%, it should remain at 80% to ensure the operability and readability of the keys.

[0124] Step 4013: The secure keyboard component uses the current application's main window as the parent window, calls the HarmonyOS system's window.createSubWindow interface to create a child window instance, and sets its properties; In this embodiment, the attributes set include: Window title bar: Hide (do not display title bar) Window border: Hide (no border style) Window background: Set to semi-transparent (transparency value 0.9). Modal attribute: Set to false (non-modal window, does not block user operations on other areas of the application). Get focus property: Set to false (Set this property to prevent the child window from taking away the current focus of the text input component when it pops up, causing the text input component to lose focus and the user to be unable to continue typing). Window width and height: Set to the design size or the scaled size. Window position: Set to the calculated and adjusted X and Y coordinates.

[0125] Step 4014: The secure keyboard component loads the pre-built soft keyboard interface layout file into the created child window and calls the child window's interface to display the child window on the screen.

[0126] Click event listeners for each button are registered uniformly when the interface loads. When each button is clicked, the corresponding character or operation command is passed to the button handling function of the secure keyboard component.

[0127] Once the interface has loaded, the secure keyboard component calls the show interface of its child window, causing the child window to appear on the screen. The child window floats above the main window, located near the text input component, without obstructing the main visible area of ​​the text input component.

[0128] Step 402: When a user touches or clicks a key on the child window's soft keyboard interface, the secure keyboard component executes its internal implementation method according to the callback function called by the child window; In this embodiment, each button in the sub-window is assigned a type identifier during construction, such as character keys (numbers, letters, symbols), delete keys (backspace icon), and completion keys ("Done" button). When the user clicks a button, the sub-window determines the current button type based on the button type identifier and calls the callback function bound during initialization according to the button type. When the key type is a character key, the add character callback of the secure keyboard component is called, the key value is passed in, and the secure keyboard component calls the addChar (add character) method to perform the same process as the mobile secure keyboard component in Example 2; When the key type is the delete key, the delete character callback of the secure keyboard component is invoked, and the secure keyboard component calls the deleteChar(delete character) method to perform the same process as the mobile secure keyboard component in Example 2. When the key type is a complete key, the completion callback of the secure keyboard component is invoked, and the secure keyboard component calls the externally passed-in doneAction callback.

[0129] In this embodiment, it also includes: when the focus loss handling function of the security keyboard component is called by the system, the security keyboard component calls the external focus loss callback; Specifically, when the user clicks on an area outside the text input component, the system calls the handleBlur (out-of-focus handling function) method bound to .onBlur(this.handleBlur), which calls the external focus loss callback and calls the closeSoftKeyboard() function to close the child window.

[0130] In this embodiment, it also includes: when the page is closed or the secure keyboard component is removed, the aboutToDisappear() method of the secure keyboard component is called by the system, the secure keyboard component calls the system's window privacy mode setting interface and passes in a value (which indicates that the privacy mode is turned off), and notifies the system to restore the screenshot / screen recording permission of the window.

[0131] In this embodiment, it also includes: when the method of actively opening the soft keyboard of the secure keyboard component is called externally, the secure keyboard component calls the open soft keyboard interface to create and display a sub-window; When the safe keyboard component's active soft keyboard close method is called externally, the safe keyboard component calls the close soft keyboard interface to close the child window; When the clear input method of the secure keyboard component is called externally, the secure keyboard component calls the reset interface and key and algorithm setting interface of the encryption / decryption middleware to clear the mask string and length, and the text input component interface is updated.

[0132] When the secure keyboard component's ciphertext retrieval method is called externally, the secure keyboard component calls the encryption / decryption middleware's ciphertext retrieval interface, which returns a hexadecimal string of the ciphertext.

[0133] When the stop editing method of the safe keyboard component is called externally, the safe keyboard component calls the stop editing interface of the system's text input component controller, causing the text input component to lose focus and the child window to be closed.

[0134] The PC-based secure keyboard component is a password input component designed for HarmonyOS PC (or PC-like devices). Unlike the mobile version, the PC version does not use the system's custom keyboard; instead, it displays a clickable soft keyboard by creating a separate sub-window. Example 4

[0135] This embodiment describes how, on a PC device connected to a physical keyboard, a secure keyboard component achieves secure input by intercepting key events from the physical keyboard on the HarmonyOS system. It also supports users actively opening a sub-window of a custom soft keyboard interface, enabling coexistence and seamless switching between physical and soft keyboard input methods. This embodiment is based on the premise that the secure keyboard component, in aboutToAppear(), obtains the device type as PC through the device information interface, and that the external configuration or user selection is set to physical keyboard mode (or allows coexistence).

[0136] In one feasible approach, this embodiment, when the `build()` method of the secure keyboard component is called by the HarmonyOS system, further includes, based on embodiment three: the secure keyboard component calls `.onKeyPreIme(this.handlePhysicalKey)` to register the physical key handling function `handlePhysicalKey` as a key pre-input event callback provided by the HarmonyOS system, using the key pre-input event callback as an interface to obtain key input before the system's default input method processes it. The key pre-input event callback is a mechanism provided by the HarmonyOS system, triggered before the system input method (IME) processes the key input.

[0137] like Figure 6 The diagram illustrates the implementation process of a secure keyboard on a PC when using a physical keyboard for input. Specifically, it includes: When a user presses a key on the physical keyboard, the HarmonyOS system receives the key press event and calls the key pre-input event callback (.onKeyPreIme callback) registered on the TextInput by the secure keyboard component. The secure keyboard component then performs the following operations: Step 501: The secure keyboard component receives physical key events and determines the key type. If the key is a regular character key, proceed to step 502; if the key is the delete key, proceed to step 503; if the key is the Enter key, proceed to step 504; if the key is an arrow key, proceed to step 505; if the key is a combination key, proceed to step 506.

[0138] When a user presses any key on the physical keyboard, the HarmonyOS system generates a key event. The key event triggers the key pre-input event callback (.onKeyPreIme callback) pre-registered by the secure keyboard component. In the key pre-input event callback (.onKeyPreIme callback), the secure keyboard component classifies and judges the key based on the information in the KeyEvent parameter. The standard character keys include letters A, Z, numbers 0-9, and preset allowed special symbols; The key code for the delete key is either Delete or Backspace. The key code for the Enter key is Enter; The arrow keys include the left arrow key, right arrow key, up arrow key, and down arrow key; Key combinations include pressing other character keys while pressing modifier keys such as Ctrl, Alt, and Shift.

[0139] Step 502: The secure keyboard component extracts the Unicode character corresponding to the key, calls the addChar interface of the encryption / decryption middleware to pass the character, appends a mask character to the password text input component, and returns true to the HarmonyOS framework through a callback function; After the secure keyboard component extracts the Unicode character corresponding to the key, it also checks whether the character is within the preset allowed input character set. If it is, it calls the addChar interface of the encryption / decryption middleware; otherwise, it returns an error. For example, if the business scenario involves numeric PIN code input, only numeric characters from 0 to 9 are allowed, while letters and symbols are rejected. If a character is not within the allowed range, true (processed flag) is returned directly, terminating the processing without updating the password status.

[0140] Calling the addChar interface of the encryption / decryption middleware to pass in the character specifically includes: reading the current ciphertext M from the internal buffer, decrypting the ciphertext M using the preset SM4 decryption algorithm and key to obtain the current plaintext P_old, appending the character input this time to the end of P_old to form a new plaintext P_new, encrypting the new plaintext P_new using the SM4 encryption algorithm and key to obtain a new ciphertext M_new, and overwriting the original ciphertext in the internal buffer with M_new.

[0141] The entire encryption and decryption process is completed atomically within the encryption and decryption middleware, and the decrypted plaintext cannot be obtained from the outside.

[0142] In this embodiment, the mask character is such as "●". The text input component displays only the mask character string with the same length as the password data, and does not display the actual input characters.

[0143] In this embodiment, the callback function returns true to inform the HarmonyOS system that the key event has been processed by the application layer and will no longer be passed to the system input method.

[0144] Step 503: The secure keyboard component calls the deleteLastChar interface of the encryption / decryption middleware and removes the last mask character in the password text input component. The callback function returns true. In this embodiment, after calling the deleteLastChar interface of the encryption / decryption middleware, the encryption / decryption middleware internally executes the following: read the current ciphertext M from the internal buffer, decrypt it to obtain the plaintext P_old, determine whether P_old is an empty string, if it is empty, return the operation failure directly, if it is not empty, delete the last character of P_old to obtain P_new, if P_new is an empty string, set the ciphertext in the internal buffer to empty, if P_new is not empty, encrypt P_new to obtain the new ciphertext M_new and replace the ciphertext M in the internal buffer;

[0145] In this embodiment, if the length of the password becomes 0 after removing the last mask character from the password text input component, the text input component will be displayed as empty.

[0146] Step 504: The secure keyboard component calls the externally passed-in doneAction callback, and the callback function returns true.

[0147] External business code can retrieve the hexadecimal ciphertext of the current password by calling getEncPin() in the callback and submit it to the server for verification.

[0148] Step 505: The secure keyboard component keeps the cursor on the end of the entered characters in the text input component, and the callback function returns true.

[0149] In this embodiment, for the arrow keys (left, right, up, down), to prevent users from bypassing the encryption logic by moving the cursor to the middle of the already entered characters to perform insertion operations, the secure keyboard component directly ignores the cursor movement effect produced by the arrow keys, forcing the cursor of the text input component to always stay at the end of the already entered characters, and the callback function returns true.

[0150] Step 506: The secure keyboard component intercepts all key combinations and returns true.

[0151] In this embodiment, step 506 further includes: the secure keyboard component detects the form of the key combination. If the Ctrl+C key combination (copy) or Ctrl+V key combination (paste) is detected, it is directly intercepted, and the callback function returns true to prevent the injection of unencrypted characters into the password text input component through clipboard operation. If the Ctrl+A key combination (select all) is detected, it is directly intercepted, and the callback function returns true. If other non-sensitive key combinations are detected, the system selects to allow or intercept according to a preset strategy. The default strategy is to block all key combinations and returns true.

[0152] In this embodiment, the shortcut keys include a combination of modifier keys (Ctrl, Alt, Shift) and character keys; In this embodiment, since all key presses in steps 502 to 506 return true, the HarmonyOS system determines that the key press event has been fully processed by the application layer and will no longer pass the event to the system input method. Therefore, the system input method will not pop up a candidate word window, will not perform automatic case conversion, and will not trigger any input method association or error correction functions. From the user's perspective, all characters entered via the physical keyboard are directly acquired and encrypted in real time by the secure keyboard component, and only masked characters are displayed in the page text input component, making it like a "dedicated password input terminal."

[0153] The PC-side physical keyboard security keyboard component is a password input component designed for HarmonyOS PC devices connected to a physical keyboard. Unlike mobile and PC soft keyboards, this mode does not pop up any virtual soft keyboard; users directly type on the physical keyboard. The security keyboard component intercepts all physical key events through the `onKeyPreIme` callback of `TextInput`, performing custom processing before the system input method (IME) processes them, thus achieving secure input.

[0154] In physical keyboard mode, users can still actively open a sub-window of the custom soft keyboard interface and input data by clicking virtual keys with the mouse. The creation, display, and closing logic of the soft keyboard interface sub-window is exactly the same as in Example 3, and it does not interfere with the physical keyboard's key interception mechanism. When the user presses the physical keyboard, the key events are still intercepted and processed by handlePhysicalKey, without conflicting with soft keyboard input. Both input methods share the same encryption state and text input component display (mask character "●"), and can be seamlessly switched or used simultaneously. Example 5

[0155] The following are embodiments of the apparatus of the present invention, which can be used to execute embodiments of the method of the present invention. For details not disclosed in the embodiments of the apparatus of the present invention, please refer to the embodiments of the method of the present invention.

[0156] An exemplary embodiment of the present invention provides a secure keyboard implementation device based on the HarmonyOS system, the device comprising: The device adaptation module is used to call the HarmonyOS system's device information interface to obtain the current device type; The component building module is used to create text input components based on device type and register an interface for the created text input components to obtain key input before the system default input method processes it; The privacy protection module is used to call the HarmonyOS window privacy mode setting interface to set the current window to privacy window mode when the text input component gains focus; The key input receiving module is used to receive user key input information through a registered key input interface; The encryption update module is used to call the add character interface of the encryption / decryption middleware to generate new ciphertext when the received key input information contains character keys; The mask display module is used to update the display content of the text input component with a mask character of the same length according to the data length of the new ciphertext; The ciphertext output module is used to output new ciphertext through the external controller.

[0157] Preferably, the component building module is specifically used to bind a custom keyboard building function to the text input component when the current device type is a mobile terminal; the custom keyboard building function is an interface for obtaining key input, used to automatically generate and pop up the soft keyboard when the text input component gains focus, and to bind the click event of the soft keyboard to the implementation method; When the current device type is PC, register the key pre-input event callback provided by HarmonyOS for the text input component; the key pre-input event callback is an interface for obtaining key input, used to receive key input information entered by the user through the physical keyboard, process the key input information and return a response to the system.

[0158] Preferably, when the current device type is a PC, the component building module registers a focus handling function for the text input component, and the focus handling function is an interface for obtaining key input; The device also includes: a child window creation module, which calls the window creation function of the HarmonyOS system when the text input component gains focus, and creates a child window with a soft keyboard interface with the current application's main window as the parent window. The character keys in the soft keyboard interface are pre-bound to callback functions that call the implementation method. When a user touches or clicks a key on the child window's soft keyboard interface, the internal implementation method is executed according to the bound callback function.

[0159] Furthermore, the sub-window creation module is specifically used to call the HarmonyOS system's component location query interface to obtain the position information of the text input component on the screen; adaptively adjust the display position and size of the sub-window according to the position information so that the sub-window does not exceed the visible range of the screen and does not obscure the text input component; and load the soft keyboard interface in the sub-window.

[0160] Preferably, the encryption update module is specifically used to read the currently stored ciphertext in the internal buffer through the encryption / decryption middleware, and determine whether the read data is empty; if it is not empty, the module uses a preset encryption / decryption algorithm and key to decrypt the read ciphertext to obtain plaintext, appends the character value passed when calling the add character interface to the end of the plaintext as new plaintext, uses the encryption / decryption algorithm and key to encrypt the new plaintext to obtain new ciphertext, and replaces the ciphertext stored in the internal buffer with the new ciphertext.

[0161] Preferably, the device further includes: a deletion and update module, used to call the deletion character interface of the encryption and decryption middleware to generate new ciphertext when the received key input information is the delete key; Furthermore, the delete update module is specifically used to read the currently stored ciphertext in the internal buffer through the encryption and decryption middleware, decrypt the obtained ciphertext using a preset encryption and decryption algorithm and key to obtain plaintext, delete the last character of the plaintext to obtain new plaintext, and determine whether the new plaintext is empty; If it is not empty, the encryption and decryption algorithm and key are used to encrypt the new plaintext to obtain the new ciphertext, and the ciphertext stored in the internal buffer is replaced by the new ciphertext. If the buffer is empty, the ciphertext in the internal buffer will be set to empty.

[0162] Preferably, the mask display module is specifically used to modify the mask string variable decorated by the HarmonyOS system state management decorator, so that the HarmonyOS system automatically refreshes the display content of the text input component after detecting that the mask string variable has changed.

[0163] Preferably, the device further includes a cursor movement module for moving the cursor of the text input component to the end of the mask character.

[0164] Preferably, the interface for obtaining key input registered by the component building module is also used to intercept key combinations used for copying, pasting, or selecting all; ignore arrow keys used to move the cursor and force the input cursor to be fixed at the end of the entered content; and verify whether the key input information is within the preset allowed character set range, and if not, reject the input.

[0165] Preferably, the device further includes a privacy-disabling module, used to call the HarmonyOS window privacy mode setting interface to disable the privacy window mode and restore screenshot and screen recording permissions in response to the text input component losing focus; or, in response to the destruction of the secure keyboard component, to call the window privacy mode setting interface to disable the privacy window mode.

[0166] As can be seen from the above embodiments, this invention achieves unified secure input between the soft keyboard and the physical keyboard by constructing a custom secure keyboard component that integrates functions such as an encryption state machine, physical keyboard interception, sub-window management of the soft keyboard interface, privacy window protection, and linkage control of text input components. Each character change triggers a complete process of "decrypting the current ciphertext → updating the plaintext → re-encrypting → storing the new ciphertext," ensuring that the plaintext is not exposed during input; the input interface only displays masked characters. The privacy window mode effectively prevents screen capture and recording attacks during the input process.

[0167] The aforementioned functional units communicate and collaborate through internal interfaces. Each unit can be implemented as a software module (packaged during compilation as part of the secure keyboard component code package), a hardware module, or a combination of software and hardware. The specific functional division of each unit is for illustrative purposes only; in actual deployment, some units can be merged or further split as needed, as long as the functionality of the methods described in the various embodiments of this invention can be achieved.

[0168] It should be noted that the above embodiments of the secure keyboard implementation device based on the HarmonyOS system, when executing the secure keyboard implementation method based on the HarmonyOS system, are only illustrative examples of the above-described division of functional modules. In practical applications, the above functions can be allocated and completed by different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the secure keyboard implementation device based on the HarmonyOS system provided in the above embodiments and the secure keyboard implementation method embodiments based on the HarmonyOS system belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0169] The sequence numbers of the above embodiments of the present invention are merely for description and do not represent the superiority or inferiority of the embodiments.

[0170] This invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of any of the methods described in the foregoing embodiments.

[0171] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of any of the methods described in the foregoing embodiments. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives, as well as magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

[0172] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, equivalent variations made according to the claims of the present invention are still within the scope of the present invention.

Claims

1. A method for implementing a secure keyboard based on the HarmonyOS system, characterized in that, The method includes: The secure keyboard component performs the following operations: Call the HarmonyOS system's device information interface to obtain the current device type; Create a text input component according to the device type, and register an interface for the created text input component to obtain key input before the system default input method processes it; In response to the text input component gaining focus, the window privacy mode setting interface of the HarmonyOS system is called to set the current window to privacy window mode; The user's key input information is received through the registered interface for obtaining key input. When the received key input information contains character keys, the encryption / decryption middleware's add character interface is invoked to generate new ciphertext; Based on the data length of the new ciphertext, update the display content of the text input component to a mask character of the same length; The new ciphertext is output through the external controller; The step of creating a text input component according to the device type and registering an interface for the created text input component to obtain key input before the system default input method processes it includes: If the current device type is a mobile device, then a custom keyboard construction function is bound to the text input component; the custom keyboard construction function is the interface for obtaining key input, which is used to automatically generate and pop up a soft keyboard when the text input component gains focus, and bind the click event of the soft keyboard to the implementation method inside the secure keyboard component so as to obtain key input information before the system default input method processes it; If the current device type is a PC, then register the key pre-input event callback provided by the HarmonyOS system for the text input component; the key pre-input event callback is the interface for obtaining key input, which is used to receive key input information input by the user through the physical keyboard, process the key input information and return a response to the system, so as to intercept key input events before the system's default input method processes them.

2. The secure keyboard implementation method based on HarmonyOS according to claim 1, characterized in that, The step of creating a text input component according to the device type and registering an interface for the created text input component to obtain key input before the system default input method processes it includes: if the current device type is a PC, then registering a focus processing function for the text input component, wherein the focus processing function is the interface for obtaining key input; The method further includes: in response to the text input component gaining focus, performing the following operations through the focus handling function: The window creation function of the HarmonyOS system is called to create a child window with a soft keyboard interface, with the main window of the current application as the parent window. The character keys in the soft keyboard interface of the child window are pre-bound to callback functions that call the internal implementation methods of the secure keyboard component. When a user touches or clicks a key on the soft keyboard interface in the sub-window, the implementation method inside the secure keyboard component is executed according to the bound callback function.

3. The secure keyboard implementation method based on HarmonyOS according to claim 2, characterized in that, The process of creating a child window displaying a soft keyboard interface with the current application's main window as the parent window specifically includes: Call the component location query interface of the HarmonyOS system to obtain the position information of the text input component on the screen; The display position and size of the sub-window are adaptively adjusted according to the location information so that the sub-window does not exceed the visible range of the screen and does not obstruct the text input component; Load the soft keyboard interface in the sub-window.

4. The secure keyboard implementation method based on HarmonyOS according to claim 1, characterized in that, The step of calling the encryption / decryption middleware's add-character interface to generate new ciphertext includes: When the encryption / decryption middleware is invoked, it reads the currently stored ciphertext in the internal buffer and determines whether the read data is empty. If not empty, the preset encryption / decryption algorithm and key are used to decrypt the read ciphertext to obtain plaintext. The character value passed when calling the add character interface is appended to the end of the plaintext as new plaintext. The encryption / decryption algorithm and key are used to encrypt the new plaintext to obtain new ciphertext. The ciphertext stored in the internal buffer is replaced by the new ciphertext.

5. The secure keyboard implementation method based on HarmonyOS according to claim 1, characterized in that, The method further includes: When the received key input information is the delete key, the delete character interface of the encryption / decryption middleware is called to generate new ciphertext; The specific steps for generating new ciphertext by calling the character deletion interface of the encryption / decryption middleware include: When the character deletion interface of the encryption / decryption middleware is called, it reads the ciphertext currently stored in the internal buffer, decrypts the obtained ciphertext using a preset encryption / decryption algorithm and key to obtain plaintext, deletes the last character of the plaintext to obtain new plaintext, and determines whether the new plaintext is empty. If it is not empty, the encryption / decryption algorithm and the key are used to encrypt the new plaintext to obtain a new ciphertext, and the new ciphertext replaces the ciphertext stored in the internal buffer. If the internal buffer is empty, the ciphertext in the internal buffer will be set to empty.

6. The secure keyboard implementation method based on HarmonyOS according to claim 1, characterized in that, The step of updating the display content of the text input component to a mask character of the same length according to the data length of the new ciphertext specifically includes: modifying the mask string variable decorated by the HarmonyOS state management decorator so that the HarmonyOS system automatically refreshes the display content of the text input component after detecting that the mask string variable has changed.

7. The secure keyboard implementation method based on HarmonyOS according to claim 1, characterized in that, After updating the display content of the text input component to a mask character of the same length according to the data length of the new ciphertext, the method further includes: the secure keyboard component moving the cursor of the text input component to the end of the mask character.

8. The method according to claim 1, characterized in that, The key pre-input event callback is also used to perform at least one of the following operations: Intercept key combinations used for copy, paste, or select all; Ignore the arrow keys used to move the cursor and force the input cursor to be fixed at the end of the entered content; Verify whether the key input information is within the preset allowed character set; if not, reject the input.

9. The secure keyboard implementation method based on HarmonyOS according to claim 1, characterized in that, The method further includes: in response to the text input component losing focus, calling the window privacy mode setting interface of the HarmonyOS system to close the privacy window mode and restore the screenshot and screen recording permissions; Alternatively, in response to the destruction of the secure keyboard component, the window privacy mode setting interface is invoked to close the privacy window mode.

10. A secure keyboard implementation device based on the HarmonyOS system, characterized in that, include: The device adaptation module is used to call the HarmonyOS system's device information interface to obtain the current device type; The component building module is used to create a text input component according to the device type and register an interface for the created text input component to obtain key input before the system default input method processes it; The privacy protection module is used to call the window privacy mode setting interface of the HarmonyOS system to set the current window to privacy window mode when the text input component gains focus; The key input receiving module is used to receive user key input information through the registered key input interface; The encryption update module is used to call the add character interface of the encryption / decryption middleware to generate new ciphertext when the received key input information contains character keys; The mask display module is used to update the display content of the text input component with a mask character of the same length according to the data length of the new ciphertext; The ciphertext output module is used to output the new ciphertext through the external controller; The component building module is specifically used when the current device type is a mobile device to bind a custom keyboard building function to the text input component; the custom keyboard building function is an interface for obtaining key input, used to automatically generate and pop up the soft keyboard when the text input component gains focus, and to bind the click event of the soft keyboard to the implementation method; When the current device type is PC, register the key pre-input event callback provided by HarmonyOS for the text input component; the key pre-input event callback is an interface for obtaining key input, used to receive key input information entered by the user through the physical keyboard, process the key input information and return a response to the system.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images