Self-adaptive identification and dynamic drive loading method and device for password keyboard of self-service payment machine

Abstract

The invention discloses a self-adaptive identification and dynamic drive loading method and device for a password keyboard of a self-service payment machine. According to the system, VID, PID, firmware version, SN number and instruction fingerprint four-dimensional features of a keyboard are captured in parallel through a hardware detection engine, model matching is completed by using a hash table of O (1) time complexity, and online feature collection and block chain evidence storage updating are started when matching fails; and then, dynamically loading the driving module signed by the TPM, and realizing zero-interruption hot injection of the key through a double-buffering mechanism. Compared with the prior art, plug-and-play adaptation of any USB / serial port password keyboard can be completed within one second, a secret key can be updated without restarting equipment, meanwhile, an instruction fingerprint verification and block chain trusted link is provided, the development and maintenance cost is remarkably reduced, the safety is improved, and the method is suitable for ATM, POS and various self-service payment terminals.

Description

Technical Field

[0001] This invention relates to the field of financial self-service equipment technology, and in particular to an adaptive recognition and dynamic driving loading method and device for the PIN pad of a self-service payment machine. Background Technology

[0002] With the widespread adoption of bank card and mobile payments in self-service payment machines (self-service terminals, ATMs, POS terminals, etc.), the PIN pad, as a core component for entering personal identification numbers (PINs), is experiencing fragmentation in its models, interfaces, and protocols. Traditionally, this requires developing separate drivers for different PIN pads and manually configuring model information, leading to:

[0003] High development costs: Each new keyboard requires repeated adaptation.

[0004] Maintenance difficulties: Redeployment is required after firmware upgrades or model iterations;

[0005] Security risks: Static configurations are easily tampered with, and the key transmission link lacks dynamic verification;

[0006] Poor real-time performance: The device must be restarted after the keyboard is replaced for the change to take effect. Summary of the Invention

[0007] The purpose of this invention is to provide an adaptive recognition and dynamic driver loading method and system for the password keypad of a self-service payment machine, thereby solving the aforementioned problems existing in the prior art.

[0008] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0009] An adaptive recognition and dynamic driver loading method for a self-service payment machine's PIN pad includes:

[0010] a) After the self-service payment machine is powered on, the built-in hardware detection engine scans all USB ports and serial ports in parallel to capture the hardware feature set of the connected keypad. The hardware feature set includes at least: manufacturer identifier (VID), product identifier (PID), product string in USB device descriptor, and model / firmware version information in serial handshake response frame.

[0011] b) Perform multi-dimensional matching between the hardware feature set and the dynamic mapping table in the local encrypted feature library. The dynamic mapping table uses the "VID-PID-firmware version-instruction fingerprint" quadruple as the primary key. If the match is successful, the corresponding driver container entry is directly indexed; if the match fails, the online feature acquisition mode is activated.

[0012] i) Send a sequence of type verification instructions to the keypad. The instruction sequence consists of a timestamp challenge code and random padding bytes to defend against replay attacks.

[0013] ii) Calculate the instruction fingerprint based on the returned instruction response data, write the new "quadruple-driver container" entry into the encrypted feature library, and simultaneously synchronize the entry to the cloud blockchain evidence storage node;

[0014] c) Based on the matched or newly created entries, dynamically load the password keyboard driver module from the driver container. The driver module is registered to the unified key interface layer as a plug-in. The unified key interface layer exposes a set of encryption operation APIs that are independent of the keyboard model to the application layer. The encryption operation APIs include at least: opening / closing the keyboard, master key download, working key injection, MAC calculation, and password ciphertext retrieval.

[0015] d) After the driver loading is completed, the key hot injection process is executed through the unified key interface layer. The key hot injection process pushes the working key to the security chip of the keypad in real time without restarting the application layer and returns the injection result.

[0016] e) During the operation of the PIN pad, the integrity of the hardware feature set is periodically monitored. If an abnormal change in the feature value is detected, the driver module self-verification and key rollback mechanism are triggered.

[0017] Preferably, the dynamic mapping table uses a doubly linked list index to support the insertion, deletion and query of entries in O(1) time, and automatically triggers the LRU eviction policy when the number of entries exceeds the threshold.

[0018] Preferably, the model verification instruction sequence uses differentiated instruction templates for different manufacturers' password keyboards. The instruction templates are stored in the instruction fingerprint calculation engine in JSON format to achieve cross-manufacturer compatibility.

[0019] Preferably, in the online feature acquisition mode, feature entries are updated via an offline encrypted USB flash drive in a local area network isolated environment. The encrypted USB flash drive has a built-in read-only area for one-time writing, which is used to store digitally signed driver containers.

[0020] Preferably, the unified key interface layer maps the encryption operation API to the actual function pointer of the target driver module through a dynamic proxy mechanism, and falls back to the virtual keyboard security mode when the mapping fails.

[0021] Preferably, the key hot injection process employs a double buffering mechanism:

[0022] The first buffer caches the key to be injected;

[0023] The second buffer is used for atomic rollback in case of key injection failure, ensuring that application layer services are unaware of the issue.

[0024] Preferably, the self-verification of the driver module includes:

[0025] Calculate the SHA-256 digest of the driving binary file and compare it with the blockchain evidence hash;

[0026] If there is a discrepancy, the current driver will be automatically uninstalled and a signed alternative driver will be retrieved.

[0027] Preferably, the hardware detection engine supports hot-plug interruption monitoring. When a new keyboard is connected, the current business process is interrupted and the adaptive recognition process is executed first. After the recognition is completed, the business is seamlessly restored.

[0028] Preferably, the encrypted feature library is stored in a transparent encrypted manner, the key is sealed inside the TPM chip on the self-service payment machine motherboard, and is decrypted and loaded through a trusted boot chain when the system starts.

[0029] Furthermore, an electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described above.

[0030] The beneficial effects of this invention are:

[0031] The adaptive adapter provided by this invention has the following advantages:

[0032] Simplified adaptation process: By recognizing hardware interface features, automatic adaptation to multiple keypad models is achieved, avoiding the complexity and repetitive work of developing an adaptation program for each model.

[0033] Reduced development and maintenance costs: Developers only need to maintain one adapter program, reducing the development and implementation burden caused by hardware updates. When adding a new keypad model, simply integrate its hardware interface into the existing adapter program for immediate use.

[0034] Improved implementation efficiency: Since the adapter program can automatically identify hardware interfaces, implementers do not need to manually configure the keypad model. The automated testing process can quickly verify the accuracy of the adapter, significantly improving implementation efficiency.

[0035] Reduce configuration errors: By using automated hardware interface identification, the system avoids the errors caused by manually configuring hardware brands and models in traditional adaptation methods, thus ensuring system stability and reliability. Attached Figure Description

[0036] Figure 1 This is a diagram of the overall system architecture of the present invention;

[0037] Figure 2 This is a timing diagram for instruction fingerprint verification in this invention;

[0038] Figure 3 This is a schematic diagram of the key hot injection double buffering mechanism of the present invention;

[0039] Figure 4 This is a flowchart of the O(1) feature library query process of the present invention;

[0040] Figure 5 This is a flowchart of the method of the present invention. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0042] Reference Figures 1 to 5 The method for adaptive recognition and dynamic driver loading of a self-service payment machine PIN pad, as shown, includes:

[0043] S100: After the self-service payment machine is powered on, it uses the built-in hardware detection engine to scan all USB ports and serial ports in parallel to capture the hardware feature set of the connected password keypad. The hardware feature set includes at least: Manufacturer Identifier (VID), Product Identifier (PID), Product string in USB device descriptor, and Model / Firmware Version information in serial handshake response frame.

[0044] The specific steps for this operation are as follows:

[0045] Within the first 200 milliseconds after the self-service payment machine powers on, the ARM coprocessor on the motherboard starts the hardware detection engine with the highest real-time priority. The detection engine simultaneously starts two threads: one traverses all USB Root Hubs, using libusb to sequentially read the idVendor, idProduct, and iProduct string descriptors of each device; the other thread traverses COM1 to COM256 obtained by SetupAPI enumeration, or / sys / class / tty / * under Linux, sending query frames of 0x02 0x00 0x00 0x03 to the port sequentially at five baud rates of 9600, 19200, 38400, 57600, and 115200, waiting for the keyboard to return a response frame containing the model and firmware version.

[0046] The read USB descriptor includes a 256-bit ECDSA signature, and the serial port response frame is appended with an HMAC-SHA256 checksum. The coprocessor calls mbedTLS to verify the signature and checksum, ensuring the source is trustworthy.

[0047] If the same keyboard exposes both USB and serial ports, the USB channel will be used first; if only the serial port is detected, the VID / PID will be set to 0xFFFF / 0xFFFF and the serial port information will be used to complete the information.

[0048] All successfully acquired hardware feature vectors, along with SessionID, timestamp, interface type, and signature validity flag, are encapsulated into a JSON object, verified by CRC32, and then pushed to the main CPU with zero copy through a shared memory ring buffer.

[0049] The entire scanning process is completed within 500 milliseconds, and the total time taken for 8 concurrent ports is no more than 1.2 seconds, with a false positive rate of zero.

[0050] S200: Perform multi-dimensional matching between the hardware feature set and the dynamic mapping table in the local encrypted feature library. The dynamic mapping table uses the "VID-PID-firmware version-instruction fingerprint" quadruple as the primary key. If the match is successful, the corresponding driver container entry is directly indexed; if the match fails, the online feature acquisition mode is activated.

[0051] S210. Send a type verification command sequence to the keypad. The command sequence consists of a timestamp challenge code and random padding bytes to defend against replay attacks.

[0052] S220. Calculate the instruction fingerprint based on the returned instruction response data, write the new "quadruple-driver container" entry into the encrypted feature library, and simultaneously synchronize the entry to the cloud blockchain evidence storage node.

[0053] The specific operation method of this step is as follows: After the main CPU receives the four-dimensional feature vector pushed by the hardware detection engine, it immediately concatenates it into a UTF-8 string "VID-PID-firmware version-instruction fingerprint" as the key value, and calls CityHash128 to generate a 64-bit hash index.

[0054] The hash value directly locates the position of the dynamic mapping table bucket in the eMMC encrypted partition; the entries within the bucket use open addressing + linear probing to ensure that the comparison can be completed in a single memory access. If the entry exists and the HMAC-SHA256 verification passes, the corresponding driver container path is directly retrieved and loaded.

[0055] If the bucket is empty or the verification fails, the matching is deemed unsuccessful, and the system enters online feature acquisition mode.

[0056] a) The coprocessor’s internal true random number generator generates a 16-byte random padding R, which is then concatenated with the current Unix timestamp T to form a 24-byte challenge code;

[0057] b) The challenge code is encrypted with AES-256-GCM and encapsulated into a type verification instruction frame, which is transmitted via USB control or sent to the keyboard via serial port 0x09 function code.

[0058] c) The keyboard must return a response frame within 200ms. The first 32 bytes of the response frame are the plaintext firmware version, and the last 32 bytes are the ECDSA signature signed with the device private key.

[0059] d) Locally verify the signature S using the pre-set vendor public key. After successful verification, perform SHA-256 calculation on the entire response frame to obtain a 32-byte instruction fingerprint FP.

[0060] e) Using "VID-PID-firmware version-FP" as the new primary key, along with the driver container path, signature public key index, and expiration timestamp, a 128-byte entry is written into the dynamic mapping table and immediately synchronized to the cloud blockchain node.

[0061] f) Synchronization uses MQTT over TLS 1.3. The message body includes the entry hash and ECDSA signature. The blockchain node returns a 256-bit evidence hash as a receipt, which is then written to the local TPM-NV index area to ensure the trusted root for subsequent verification.

[0062] S300. Based on the matched or newly created entries, dynamically load the password keyboard driver module from the driver container. The driver module is registered to the unified key interface layer as a plug-in. The unified key interface layer exposes a set of encryption operation APIs that are independent of the keyboard model to the application layer. The encryption operation APIs include at least: opening / closing the keyboard, master key download, working key injection, MAC calculation, and password ciphertext acquisition.

[0063] After obtaining a valid entry containing the "driver container path" field in the previous step, the main CPU immediately calls dlopen() (Linux) or LoadLibrary() (Windows) with that path as a parameter to complete the plug-in loading. Upon successful loading, the system performs registration through a predefined Unified Key Interface Layer (UKI) export table: the driver module exposes eight symbols: uk_init, uk_fini, uk_open, uk_close, uk_download_master, uk_inject_work, uk_calc_mac, and uk_get_cipher; UKI retrieves function pointers by symbol name and stores them in the global virtual table. Subsequently, UKI publishes fixed C interfaces such as uki_open() and uki_close() to the application layer. The function entities are dynamically bound to the corresponding drivers at runtime, making the keyboard model completely transparent to the upper layers.

[0064] If the installation fails or a symbol is missing, the UKI triggers an error code rollback, automatically uninstalls the plugin, and attempts to use a backup driver. The entire process is completed within 150ms without restarting the business process.

[0065] S400: After the driver loading is completed, the key hot injection process is executed through the unified key interface layer. The key hot injection process pushes the working key to the security chip of the keypad in real time without restarting the application layer and returns the injection result.

[0066] The specific steps of the key hot injection process in step S400 are as follows:

[0067] 1. After the driver plugin is successfully registered, the application layer calls uki_inject_work(work_key_blob) through the unified key interface layer. The work_key_blob has been generated by the encryption machine and encrypted with the master key.

[0068] 2. The interface layer writes the encrypted working key into the double-buffered A area, and at the same time backs up the double-buffered B area as a copy of the key that was successfully injected last time.

[0069] 3. The driver module sends an "injection command frame" to the keyboard security chip via USB control transmission or serial port; the frame format includes key ciphertext, timestamp challenge code, and CRC32 checksum.

[0070] 4. The chip completes decryption and verification within 100ms and returns the injection result code (0 for success, non-0 for failure).

[0071] 5. If the return code is 0, the system immediately marks the A area key as "valid" and returns success to the application layer; if the return code is not 0, the interface layer atomically writes the B area backup key back to the chip within 10ms to ensure uninterrupted service, and then returns the reason for failure.

[0072] 6. The entire injection-verification-rollback process is completed within 200ms. The application layer does not need to be restarted or reauthorized, and the transaction can continue to be executed.

[0073] S500: During the operation of the password keyboard, the integrity of the hardware feature set is periodically monitored. If an abnormal change in the feature value is detected, the driver module self-verification and key rollback mechanism are triggered.

[0074] 1. Periodic triggering

[0075] After the driver plugin starts, it creates an independent real-time thread in the background with a period of once every 30 seconds. The thread entry point calls uki_monitor_start(), which uses timerfd (Linux) or CreateTimerQueueTimer (Windows) to achieve high-precision timing.

[0076] 2. Integrity monitoring

[0077] Each time the timer triggers, the thread re-executes a lightweight hardware scan:

[0078] USB channel: Reread the VID, PID, and iProduct strings via libusb_get_device_descriptor;

[0079] Serial port channel: Send a fast handshake frame (1-byte instruction, 50ms timeout) to obtain a firmware version response.

[0080] The newly acquired four-dimensional feature vector is compared byte by byte with the baseline value cached during the initial load; any difference is considered an anomaly.

[0081] Anomaly detection and marking

[0082] 3. If differences are found:

[0083] Immediately set the global status flag KEYBOARD_TAMPER = 1;

[0084] Write a security event containing a difference field and a timestamp to the system log;

[0085] Pulling the alarm pin high via GPIO triggers the local buzzer to emit a 1-second warning sound.

[0086] 4. Driver self-verification

[0087] The thread then calls the uk_self_check() function exposed by the driver:

[0088] Calculate the SHA-256 digest of the current driver binary file;

[0089] Compare with the baseline hash in the TPM-NV storage area;

[0090] If the verification fails, CHECK_FAIL will be returned.

[0091] 5. Key rollback

[0092] Once you receive a CHECK_FAIL or KEYBOARD_TAMPER:

[0093] Immediately suspend all encrypted call queues;

[0094] Re-inject the last valid working key from the double-buffered B area into the keyboard security chip;

[0095] After successful injection, uninstall the current driver and mark it as "untrusted";

[0096] The message "key rollback event" is pushed to the cloud via MQTT, which includes the device serial number, the time of the incident, and the rollback key fingerprint.

[0097] 6. Recovery and Reload

[0098] After the rollback is completed, the system attempts to pull the latest trusted driver container from the blockchain node; after the download is complete, the entire S100-S400 process is executed again to achieve "self-healing" recovery, without the need for manual intervention or restarting the application layer.

[0099] Preferably, the dynamic mapping table uses a doubly linked list index to support the insertion, deletion and query of entries in O(1) time, and automatically triggers the LRU eviction policy when the number of entries exceeds the threshold.

[0100] initialization

[0101] During system startup, a contiguous physical page is allocated in the kernel space. The first 8 KiB is divided into 512 hash buckets, with each bucket head storing only a 64-bit pointer. The remaining space is used to store a doubly linked list node pool. Two sentinel nodes, HEAD and TAIL, are placed at the beginning of the node pool and remain fixed, forming an empty linked list.

[0102] Insert entry

[0103] Upon receiving the new "VID-PID-firmware version-instruction fingerprint" quadruple, the bucket index idx is first obtained by extracting the lower 32 bits using CityHash128. Then:

[0104] If the bucket is empty, take an idle node directly from the node pool, fill it with a quadruple and the driver container ID, insert the node into the head of the bucket linked list, and simultaneously add it to the head of the global LRU linked list (after HEAD).

[0105] If the bucket is not empty and the same quadruple already exists, simply move the hit node to the head of the LRU list to complete the update, and the time is still O(1).

[0106] After insertion, the global counter entry_cnt is incremented by 1 atomically.

[0107] Query Entries

[0108] To calculate the same hash index, the node can be located by traversing the singly linked list within the bucket; since the bucket depth is controlled within 4, only one pointer dereference is actually required, and the time consumption is constant.

[0109] Delete entry

[0110] When a user manually uninstalls a driver or a node fails, it is directly removed from both the LRU list and the bucket list by the prev and next pointers within the node, and the node is returned to the free pool; entry_cnt is atomically decremented by 1.

[0111] LRU phase-out

[0112] After each insertion, check if entry_cnt exceeds the preset threshold (2048). If it does:

[0113] Get the least recently used node from TAIL.prev;

[0114] Remove it from both the LRU and the bucket list using the same removal logic;

[0115] Release the node after writing its contents to the blockchain's evidence log;

[0116] Decrementing entry_cnt by 1 involves only four pointer modifications throughout the process, maintaining an O(1) time complexity.

[0117] Memory and Concurrency

[0118] The entire linked list and hash bucket reside in lock-free shared memory. Insertion, deletion, and querying all use the cmpxchg atomic instruction, ensuring multi-threaded concurrency safety. The node pool is managed using the buddy algorithm, ensuring no fragmentation, contiguous physical addresses, and a high CPU cache hit rate, thus maintaining a stable latency of less than 1 microsecond.

[0119] Preferably, the model verification instruction sequence uses differentiated instruction templates for different manufacturers' password keyboards. The instruction templates are stored in the instruction fingerprint calculation engine in JSON format to achieve cross-manufacturer compatibility.

[0120] In this embodiment, an "instruction fingerprint calculation engine"—a read-only ELF module of only 36kB—is embedded in the coprocessor's internal firmware. Upon power-up, the engine first opens the TPM-signed and verified JSON file `templates.json`. This file uses the vendor abbreviation as the primary key, with each key storing a unique instruction template object. The object fields include protocol type, instruction byte array, variable placeholders, CRC position, expected response length, and fingerprint truncation offset. The engine operates according to the following steps:

[0121] Resolution and Binding

[0122] Upon receiving the four-dimensional feature vector, the engine uses the "vendor abbreviation" field to locate the corresponding JSON sub-object and loads it into the L2 Cache line in one go. If the file is tampered with, the process will terminate immediately if the TPM signature verification fails.

[0123] Template rendering

[0124] The engine replaces the placeholder `{{timestamp}}` in the JSON with a 32-bit Unix timestamp and `{{random16}}` with a 16-bit random number generated by a true random number generator, then packages them in little-endian order at a fixed offset in the instruction byte array. CRC16 or CRC32 is appended to the end of the frame, consistent with the position declared in the template.

[0125] Protocol distribution

[0126] If the template field proto is "USB-HID", the engine sends the data at endpoint 0 via libusb_control_transfer; if it is "RS232", it sends the data within a 150ms timeout via the configured serial port handle. After sending, it waits for a response frame.

[0127] fingerprint computing

[0128] Upon receiving the response, the engine extracts a continuous block of bytes according to the fp_offset and fp_len specified in the template, sends it to the SHA-256 hardware accelerator to obtain a 32-byte instruction fingerprint, and returns it to the main process along with the rendered instruction frame for matching or table creation.

[0129] Vendor Expansion

[0130] New manufacturers only need to append the new JSON object to templates.json, and the entire file will be re-signed with ECDSA-P256 for it to take effect, without needing to recompile the firmware or update the operating system.

[0131] Preferably, in the online feature acquisition mode, feature entries are updated via an offline encrypted USB flash drive in a local area network isolated environment. The encrypted USB flash drive has a built-in read-only area for one-time writing, which is used to store digitally signed driver containers.

[0132] The specific steps for "Offline Encrypted USB Drive Update" are as follows:

[0133] Create offline packages

[0134] Operations and maintenance personnel use offline packaging workstations in the headquarters security room:

[0135] Package the new keyboard's quadruple features (VID-PID-firmware version-command fingerprint) and the corresponding driver container into a single .kbpack file;

[0136] Use the company's root private key to perform an ECDSA-P256 signature on the .kbpack file and generate a .sig file;

[0137] Write the .kbpack and .sig files together into the one-time write-only read-only area (WORM area) of the encrypted USB drive. This area is locked at the factory and cannot be erased or modified after being written.

[0138] The SHA-256 hash is recalculated for the entire read-only area of ​​the USB flash drive, and the result is written to the TPM-EEPROM in the USB flash drive controller as an integrity anchor point.

[0139] On-site operation

[0140] In business outlets isolated on a local area network:

[0141] Insert the encrypted USB flash drive into the front USB port of the self-service payment machine;

[0142] The system automatically identifies the USB flash drive's read-only partition identifier (Vendor ID + product string matching), and then verifies the anchor hash;

[0143] After successful verification, read the .kbpack and .sig files and use the pre-installed public key in the device to complete the signature verification.

[0144] If the verification is successful, the new entry is written to the local dynamic mapping table, and a driver hot-load test is immediately triggered to ensure that the keyboard can work properly.

[0145] Once completed, eject the USB drive and unplug it to finish the update; the entire process requires no network connection or manual system login.

[0146] Preferably, the unified key interface layer maps the encryption operation API to the actual function pointer of the target driver module through a dynamic proxy mechanism, and falls back to the virtual keyboard security mode when the mapping fails.

[0147] This step, "Dynamic Proxy and Rollback of Unified Key Interface Layer," is executed in the following order:

[0148] Start-up phase

[0149] Once the driver plugin is loaded, it immediately registers a function table pointer array with the Unified Key Interface (UKI). The array sequentially stores the addresses of six actual functions: open, close, download_master, inject_work, calc_mac, and get_cipher. The UKI then stores this pointer array in a global virtual table slot.

[0150] Proxy mapping

[0151] When the application layer calls APIs such as uki_open(), the UKI internal macros directly dereference the corresponding index of the virtual table slot and jump to the actual function provided by the driver. The entire process is a single pointer dereference with no additional overhead.

[0152] Failure detection

[0153] If a function pointer is null during registration, or if dlerror() / GetProcAddress returns NULL at runtime, UKI immediately sets the MAP_FAIL flag.

[0154] Virtual keyboard back

[0155] Once MAP_FAIL is set, UKI replaces the original pointer with a pre-configured virtual driver virtual table:

[0156] open / close returns a success message but no actual operation is performed;

[0157] download_master directly returns the "Not supported" error code;

[0158] calc_mac and get_cipher are performed in the local software security module and are logged with a "virtual mode" flag.

[0159] The virtual driver itself does not depend on any hardware, thus ensuring that business logic continues to run (only downgraded to software encryption), while prompting maintenance personnel to replace the keyboard.

[0160] Preferably, the key hot injection process employs a double buffering mechanism:

[0161] The first buffer caches the key to be injected;

[0162] The second buffer is used for atomic rollback in case of key injection failure, ensuring that application layer services are unaware of the issue.

[0163] The double-buffered mechanism for key hot injection is executed precisely at the code level in the following steps, completed within 200ms, with zero awareness of the application layer:

[0164] Memory layout

[0165] Two contiguous 256-byte physical pages are allocated within the Unified Key Interface (UKI) layer, named Buf_A and Buf_B respectively, and aligned to a 64-byte cache line.

[0166] An additional 1-byte atomic flag, active_idx, is maintained. A value of 0 indicates that Buf_A is the "effective zone", and a value of 1 indicates that Buf_B is the "effective zone".

[0167] Key writing

[0168] When the application layer calls uki_inject_work(kblob):

[0169] Copy the encrypted working key kblob to the "non-active area" (write Buf_B if active_idx == 0, otherwise write Buf_A).

[0170] Execute the mfence command immediately after completion to ensure that the write is globally visible.

[0171] Injection and Confirmation

[0172] The driver module sends the content of the "non-effective area" as the payload to the keyboard security chip; the sending API returns a 32-bit result code.

[0173] If the result code is 0 (success), the active_idx is atomically inverted, making the buffer just written instantly the "effective area", and the original buffer automatically becomes the "backup area".

[0174] If the result code is non-zero (failure or timeout), the driver does not perform any state switch and directly discards the contents of the "non-effective area"; at this time, the "effective area" still points to the last successful key, realizing atomic rollback.

[0175] Concurrency protection

[0176] active_idx uses C11's atomic_uint8_t, and all reads and writes are memory_order_seq_cst, ensuring that rollback and switching are seamless in a multi-threaded environment.

[0177] Any concurrent call at the application layer will immediately see the latest effective key, without needing to restart the business or reauthorize.

[0178] Completion notification

[0179] Regardless of whether the switchover or rollback is successful, UKI returns UK_INJECT_OK or UK_INJECT_ROLLBACK to the application layer within 1ms. The log synchronously records the switchover or rollback event, and the business continues without interruption.

[0180] Preferably, the self-verification of the driver module includes:

[0181] Calculate the SHA-256 digest of the driving binary file and compare it with the blockchain evidence hash;

[0182] If there is a discrepancy, the current driver will be automatically uninstalled and a signed alternative driver will be retrieved.

[0183] The specific steps for driver module self-verification and automatic replacement are as follows:

[0184] Triggering timing

[0185] The driver self-verification routine uk_self_verify() is woken up whenever the integrity monitoring thread detects an anomaly or when the system timer expires every 30 minutes.

[0186] Summary calculation

[0187] The routine maps the driver binary file into memory using mmap, and calls the hardware-accelerated SHA-256 engine to read the entire .so / .dll file at once and generate a 256-bit digest current_hash.

[0188] Blockchain comparison

[0189] The summary compares current_hash byte-by-byte with the trusted baseline hash (written by blockchain nodes and immutable) stored in the TPM-NV index area; the comparison uses memcmp and is time-constant.

[0190] Inconsistency handling

[0191] If the hashes are different, immediately:

[0192] Call dlclose() or FreeLibrary() to unload the current driver;

[0193] Set the global flag DRIVER_TAMPERED to pause all encrypted calls;

[0194] Output event code 0xF001 to the local log and trigger a buzzer for 2 seconds;

[0195] Pull the backup driver package (filename: driver_) from the pre-built image server via HTTPS-CA link. <vid-pid>.sig);

[0196] Verify the signature using the local TPM embedded public key; once verification is successful, dlopen() loads the new driver, and after completion, reset DRIVER_TAMPERED and resume service.

[0197] Completed confirmation

[0198] After the new driver is successfully registered, the system writes the new SHA-256 digest back to TPM-NV as the new base hash and pushes the "driver updated" event to the monitoring center. No manual intervention or application restart is required throughout the process.

[0199] Preferably, the hardware detection engine supports hot-plug interruption monitoring. When a new keyboard is connected, the current business process is interrupted and the adaptive recognition process is executed first. After the recognition is completed, the business is seamlessly restored.

[0200] This step, "Hot-plug interruption monitoring and seamless recovery," is executed according to the following action chain:

[0201] Interrupted registration

[0202] During system startup, the detection engine registers USB hot-plug callbacks and serial device notification callbacks in the operating system kernel space:

[0203] Use udev_monitor_filter_add_match_subsystem_devtype("usb", "usb_device") under Linux;

[0204] Call RegisterDeviceNotification(hWnd,&dbcc,DEVICE_NOTIFY_WINDOW_HANDLE) under Windows.

[0205] Interrupt trigger

[0206] When a physical keyboard is inserted, the kernel immediately generates a UEvent (Linux) or WM_DEVICECHANGE message (Windows). The detection engine's callback function obtains the highest real-time CPU priority, immediately preempts the current business thread, pushes the keyboard event into the LIFO high-priority queue, and sets the BUSY_ADAPT flag.

[0207] Adaptive recognition

[0208] High-priority tasks take over the CPU within 1ms:

[0209] Perform the complete S100-S300 process (feature capture → hash matching → driver loading → key injection);

[0210] During this period, the business thread was suspended, but the network connection and log stream remained active.

[0211] Seamless recovery

[0212] Upon successful identification, the detection engine clears the BUSY_ADAPT flag and returns control to the business thread.

[0213] If the transaction is in the "waiting for PIN" stage, the "please re-enter" prompt will be automatically resent;

[0214] If the transaction is in the data upload stage, continue the original process without losing the uploaded bytes;

[0215] The entire pause time is less than 3.5 seconds, and the user perceives it as a brief "Please wait" prompt.

[0216] Abnormal rollback

[0217] If identification fails (no matching driver), the detection engine will display a "Please contact maintenance" interface within 5 seconds, and provide a QR code at the bottom of the interface. Scanning the code will download the offline driver package. The business thread will remain in a waiting state until the driver is installed or the user cancels the transaction.

[0218] Preferably, the encrypted feature library is stored in a transparent encrypted manner, the key is sealed inside the TPM chip on the self-service payment machine motherboard, and is decrypted and loaded through a trusted boot chain when the system starts.

[0219] Key generation and sealing

[0220] The motherboard TPM2.0 chip generates a 256-bit AES-GCM master key K_feat during the power-on self-test phase, and binds it to the PCR[0]+PCR[7] combination (measuring BIOS, Boot Loader and kernel hash) through TPM2_CreatePrimary. The key attributes are set to

[0221] TPM2_OA_SEAL, export is prohibited;

[0222] TPM2_OA_DECRYPT only allows internal decryption within the TPM.

[0223] Once completed, the sealed Blob of K_feat is written to TPM NV index 0x01810003 and marked as "non-migratable".

[0224] Trusted Startup Chain Decryption

[0225] During system startup, Coreboot / UEFI measures itself, GRUB, the Linux kernel, and initramfs in sequence, and extends the measurement values ​​to PCR[0..7].

[0226] Before the kernel mounts the root file system, it calls tpm2_unseal:

[0227] Pass in NV index 0x01810003;

[0228] TPM compares the current PCR value with the PCR value at the time of sealing;

[0229] If they match, TPM internally decrypts and returns the plaintext K_feat to the kernel keyring 0x1101; the decryption process only takes place within the TPM silicon chip, and the plaintext never leaves the chip boundary.

[0230] Transparent encrypted storage

[0231] The encryption signature library file / opt / kbmap.enc uses dm-crypt device mapping and uses K_feat from the kernel key ring as the AES-GCM session key.

[0232] During writing, the kernel automatically encrypts each 4KiB block;

[0233] The kernel automatically decrypts the data during reading.

[0234] If the PCR value changes due to firmware or kernel modifications, K_feat cannot be re-unsealed, dm-crypt mapping fails, the system refuses to load the signature library, and enters "maintenance mode" prompting for an update.

[0235] Furthermore, an electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described above.

[0236] Electronic device implementation steps: hardware power-on

[0237] The ARM main CPU on the motherboard reads the firmware Boot ROM from the memory (eMMC), completes initialization, and then hands over control to U-Boot, subsequently loading the Linux kernel image and initramfs.

[0238] Trusted Startup Chain Verification

[0239] U-Boot accesses the TPM chip via the SPI bus, reads the AES-GCM key sealed blob from NV index 0x01810003; after TPM verifies that the PCR[0]+PCR[7] metric is correct, it internally unseales and outputs the 256-bit master key to the kernel key ring. The kernel uses this key to automatically mount the dm-crypt device, transparently decrypts the encryption feature library / opt / kbmap.enc into / dev / mapper / kbmap and mounts it to the read-only directory / etc / kb.

[0240] Program loading and execution

[0241] After the kernel boots up, systemd loads the executable file / usr / bin / kb-adapt from memory into DRAM, and the CPU begins execution. This program performs the following sequential actions:

[0242] a) Register via USB and serial port hot-plug callbacks and wait for keyboard insertion interrupt;

[0243] b) After the interrupt is triggered, all methods of S100 to S500 are executed, including O(1) hash lookup, differential instruction template rendering, double-buffered key hot injection, driver self-verification and rollback;

[0244] c) All encryption operations are called through the unified key interface layer. The interface layer uses dynamic proxies to map function pointers to the actual implementation of the current driver module. In case of failure, it automatically falls back to the virtual keyboard security mode.

[0245] d) During operation, exception logs are periodically written to / var / log / kb.log and uploaded to the cloud monitoring node via MQTT over TLS 1.3.

[0246] Power failure protection

[0247] When the mains power is interrupted, the supercapacitor maintains power supply for 3 seconds, the CPU flushes back the dirty data that has not been written to TPM-NV, and then sends a shutdown command to the watchdog to ensure that the integrity of the signature database and key is not lost.

[0248] Furthermore, refer to Figure 1 The overall data and control flow of the "Self-service Payment Machine Password Keyboard Adaptive System" of this invention is shown in a "three-layer architecture" manner, which can be summarized as a two-way path of "top-down calling and bottom-up identification".

[0249] Application layer

[0250] Located at the very top, it runs the "card-based self-service payment program," responsible for functions such as purchase, cancellation, refund, and balance inquiry. This layer issues commands downwards through a unified device operation call interface, completely eliminating the need to know the brand or interface of the underlying PIN pad.

[0251] Hardware adaptation layer

[0252] The middle layer is the hardware adaptation layer, which contains an "automatic hardware interface recognition" module.

[0253] When the application layer requests operations such as "open keyboard", "download key", and "password input", the adaptation layer first calls the device feature interface to capture the four-dimensional features of the current keyboard, such as VID, PID, firmware version, and command fingerprint.

[0254] Then, O(1) matching is performed in the local encryption feature library using a dynamic mapping table (O(1) hash + doubly linked list + LRU);

[0255] If a match is successful, the corresponding driver container will be directly indexed; if a match fails, online feature collection (timestamp challenge code + blockchain notarization) will be initiated and a new entry will be generated.

[0256] Finally, the results are written to the device operation interface, exposing four unified APIs for serial port operation, key download, data encryption / decryption, and password input, enabling calls independent of the keyboard model.

[0257] Hardware driver layer

[0258] The bottom layer is the hardware driver layer, which stores dedicated drivers for different brands (keyboard 1-5).

[0259] The adaptation layer dynamically loads the required driver plugins through driver management;

[0260] After loading, the driver module directly controls the specific keyboard hardware to complete operations such as key injection, rollback, and integrity verification.

[0261] The driver layer is also responsible for periodic feature monitoring and self-verification (SHA-256 digest comparison with blockchain evidence hash). Once an anomaly is detected, it will immediately uninstall and pull a backup driver to ensure the continuous availability of the system.

[0262] Figure 1 It clearly demonstrates the decoupled structure of "application layer - adaptation layer - driver layer" and the complete closed loop of "automatic identification → dynamic loading → unified interface → secure rollback", enabling the self-service payment machine to be "plug and play with any USB / serial password keypad and require zero manual configuration".

[0263] Figure 2 The complete closed loop of the "adaptive password keyboard" of this invention, from recognition to invocation, is visually presented using a "three-layer loop" diagram:

[0264] Application layer

[0265] It always calls only a unified keyboard operation API (check balance, make purchases, return items, etc.), without needing to care about underlying brand differences.

[0266] Adapter layer

[0267] Feature Interface Recognition

[0268] Matching is performed in an O(1) hash table using a four-dimensional feature vector (VID-PID-firmware version-instruction fingerprint);

[0269] If a match is found, immediately confirm the keyboard type and return the interface address (function pointer) to the application layer;

[0270] If a match fails, online feature collection and blockchain notarization are triggered, and a new entry is generated before the type is confirmed.

[0271] Unified API Mapping

[0272] The adaptation layer encapsulates operations such as "open / close / key download / MAC calculation / password input" into fixed functions and dynamically proxies them to the current driver module;

[0273] When the driver fails, it automatically reverts to the virtual keyboard safe mode, without affecting the business operations.

[0274] Hardware layer

[0275] Responsible for interacting with specific keyboard hardware, completing key hot injection, integrity verification, SHA-256 self-verification, etc.

[0276] If an anomaly is detected, the driver is immediately uninstalled and a backup driver is retrieved, then the process loops back to the adapter layer for re-identification. The entire process is illustrated in the diagram. Clockwise cycle:

[0277] Identify → Confirm → Use → Monitor → Update → Re-identify to ensure that any USB / serial password keyboard can be plugged and played with zero restarts and zero manual configuration.

[0278] Figure 3 The entire process of the "self-service payment machine password keyboard adaptive recognition" invention is fully presented in a vertical flowchart:

[0279] Adaptive Start

[0280] After the application layer loads the adapter, it immediately enters the "Default Start" node, ready to recognize any inserted PIN pad with zero human intervention.

[0281] USB detection path

[0282] Obtain current USB device information → Compare VID / PID with local encryption signature database → If a match is found, directly load the corresponding model driver, and the process ends.

[0283] Serial port detection path (automatically switches to when USB is not found)

[0284] Collect new device feature information → attempt to connect one by one according to the serial port parameter matrix in the feature library → if successful, load the corresponding model driver;

[0285] If no match is found, the new feature quadruple is written into the feature library and the blockchain is synchronized for notarization, completing the "feature library self-learning" process, and then the new driver is loaded.

[0286] Adaptive termination

[0287] Regardless of whether either path succeeds or expands, it ultimately sends the "keyboard type + unified interface address" back to the application layer, achieving a plug-and-play, zero-restart, and continuously scalable adaptive closed loop.

[0288] Figure 4 The key actions of the invention "Adaptive Keyboard Recognition and Key Injection" are fully presented in the form of a swimlane flowchart:

[0289] Start (Insert via Keyboard)

[0290] Once any USB or serial keypad is plugged in, a hot-plug interrupt is immediately triggered, and the process requires no manual intervention.

[0291] Hardware detection parallel scanning

[0292] ① The detection engine simultaneously scans the USB and serial ports to capture a four-dimensional feature vector (VID, PID, firmware version, SN, and command fingerprint).

[0293] Hash table O(1) query

[0294] ② Calculate CityHash128 using the quadruple as the key to obtain the bucket index;

[0295] ③ Perform an O(1) query in the dynamic mapping table.

[0296] Hit Branch

[0297] Yes → Directly retrieve driver entry → Secondary verification (timestamp challenge code + instruction fingerprint comparison) → Verification passed → Load driver → Key hot injection → End.

[0298] Branches missed

[0299] No → Level 3 Expansion: Online Feature Collection + Blockchain Writing → Generate New Entry → Write Back to Hash Table → Return to Load Driver Step to Continue Execution.

[0300] Failure rollback

[0301] If secondary verification or driver loading fails, failure handling is triggered: automatically uninstall the suspicious driver, roll back the last valid key, sound an alarm and prompt maintenance to ensure uninterrupted business operations.

[0302] The entire process is presented in the diagram as a closed loop of "one insertion → parallel probing → O(1) matching → verification / expansion → driver loading → key injection → end", ensuring that any brand and interface of password keyboard can complete the adaptation and be put into use within 3.5 seconds.

[0303] By adopting the above-disclosed technical solution of this invention, the following beneficial effects are achieved: Simplified adaptation process: Automatic adaptation of multiple password keyboards is realized through hardware interface feature recognition, avoiding the complexity and repetitive work of developing an adaptation program for each model separately.

[0304] Reduced development and maintenance costs: Developers only need to maintain one adapter program, reducing the development and implementation burden caused by hardware updates. When adding a new keypad model, simply integrate its hardware interface into the existing adapter program for immediate use.

[0305] Improved implementation efficiency: Since the adapter program can automatically identify hardware interfaces, implementers do not need to manually configure the keypad model. The automated testing process can quickly verify the accuracy of the adapter, significantly improving implementation efficiency.

[0306] Reduce configuration errors: By using automated hardware interface identification, the system avoids the errors caused by manually configuring hardware brands and models in traditional adaptation methods, thus ensuring system stability and reliability.

[0307] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An adaptive recognition and dynamic driver loading method for a self-service payment machine's PIN pad, characterized in that, include: a) After the self-service payment machine is powered on, it uses the built-in hardware detection engine to scan all USB ports and serial ports in parallel to capture the hardware feature set of the connected password keypad. The hardware feature set includes at least: manufacturer identifier VID, product identifier PID, product string in USB device descriptor, and model / firmware version information in serial port handshake response frame. b) Perform multi-dimensional matching between the hardware feature set and the dynamic mapping table in the local encrypted feature library. The dynamic mapping table uses the "VID-PID-firmware version-instruction fingerprint" quadruple as the primary key. If the match is successful, the corresponding driver container entry is directly indexed; if the match fails, the online feature acquisition mode is activated. i) Send a model verification instruction sequence to the keypad, the instruction sequence consisting of a timestamp challenge code and random padding bytes to defend against replay attacks; ii) Calculate the instruction fingerprint based on the returned instruction response data, write the new "quadruple-driver container" entry into the encrypted feature library, and simultaneously synchronize the entry to the cloud blockchain evidence storage node; c) Based on the matched or newly created entries, dynamically load the password keyboard driver module from the driver container. The driver module is registered to the unified key interface layer as a plug-in. The unified key interface layer exposes a set of encryption operation APIs that are independent of the keyboard model to the application layer. The encryption operation APIs include at least: opening / closing the keyboard, master key download, working key injection, MAC calculation, and password ciphertext acquisition. d) After the driver loading is completed, the key hot injection process is executed through the unified key interface layer. The key hot injection process pushes the working key to the security chip of the keypad in real time without restarting the application layer and returns the injection result. e) During the operation of the password keyboard, the integrity of the hardware feature set is periodically monitored. If an abnormal change in the feature value is detected, the driver module self-verification and key rollback mechanism are triggered.

2. The method according to claim 1, wherein the dynamic mapping table supports entry insertion, deletion and query in O(1) time through a doubly linked list index, and automatically triggers the LRU eviction policy when the number of entries exceeds the threshold.

3. The method according to claim 1, wherein the model verification instruction sequence adopts a differentiated instruction template for different manufacturers' password keyboards, and the instruction template is stored in the instruction fingerprint calculation engine in JSON format to achieve cross-manufacturer compatibility.

4. The method according to claim 1, wherein the online feature acquisition mode updates feature entries through an offline encrypted USB flash drive in a local area network isolated environment, and the encrypted USB flash drive has a built-in read-only area for storing a digitally signed driver container.

5. The method according to claim 1, wherein the unified key interface layer maps the encryption operation API to the actual function pointer of the target driver module through a dynamic proxy mechanism, and falls back to the virtual keyboard security mode when the mapping fails.

6. The method according to claim 1, wherein the key hot injection process employs a double buffering mechanism: The first buffer caches the key to be injected; The second buffer is used for atomic rollback in case of key injection failure, ensuring that application layer services are unaware of the issue.

7. The method according to claim 1, wherein the driver module self-verification includes: Calculate the SHA-256 digest of the driving binary file and compare it with the blockchain evidence hash; If there is a discrepancy, the current driver will be automatically uninstalled and a signed alternative driver will be retrieved.

8. The method according to claim 1, wherein the hardware detection engine supports hot-plug interruption monitoring, and when a new keyboard is connected, the current business process is interrupted and the adaptive recognition process is executed first, and the business is seamlessly restored after the recognition is completed.

9. The method according to claim 1, wherein the encrypted feature library is stored in a transparent encrypted manner, the key is sealed inside the TPM chip on the motherboard of the self-service payment machine, and is decrypted and loaded through a trusted boot chain when the system starts.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method of any one of claims 1-9.

Images