An interaction method, system, device and storage medium of a hardware security token

Abstract

The application discloses an interaction method, system and device of a hardware security token and a storage medium, relates to the technical field of communication, and comprises the following steps: generating application protocol data unit instruction data according to device information of a security token hardware and security service information to be executed sent by a client, and sending the application protocol data unit instruction data to the client to forward to the security token hardware; receiving application protocol data unit response data returned by the security token hardware; performing instruction interaction processing based on the application protocol data unit response data, and generating corresponding service processing results and returning the service processing results to the client. The hardware security token interaction and data processing function are deployed on the server, so that the risk of exposure of security logic and sensitive data in the client script is avoided. The user does not need to preinstall any special client software or driver, and can realize plug and play of the hardware security token only through a browser, so that the convenience and cross-platform compatibility of use are improved.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically to an interaction method, system, device, and storage medium for a hardware security token. Background Technology

[0002] In high-security application scenarios such as finance and government affairs, security token hardware is a key hardware carrier for ensuring identity authentication and business data security. There are two main technical architectures for the interaction between traditional web applications and security token hardware. The first is a local client software-based implementation, which requires pre-installing dedicated drivers and management suites provided by the hardware vendor in the user terminal operating system, relying on the local software stack to handle all security protocol interactions with the security token hardware. The second is a driverless implementation based on application programming interfaces (APIs), which has emerged with the development of browser technology. This allows script code within a webpage to directly communicate with USB devices through the browser's standard interface, enabling access to the device without pre-installing dedicated local software.

[0003] However, both of the aforementioned existing technical architectures have inherent shortcomings in deployment modes and security protection. While the local client-based solution can achieve high-level security mechanisms such as command encryption and two-way device authentication through a protected local software environment, the mandatory software installation requirement leads to cumbersome user operations, limited cross-platform compatibility, and high maintenance costs. The driverless solution based on a web application programming interface (API) eliminates the need for additional software installation, but the core interaction logic and security control functions corresponding to the security token hardware must be developed and run in the client's front-end script environment. This exposes critical business processes, command construction rules, and security-sensitive data to an untrusted front-end execution environment, posing significant security risks of reverse engineering, malicious tampering, and device spoofing. Summary of the Invention

[0004] The main objective of this invention is to provide a method, system, device, and storage medium for interacting with hardware security tokens, addressing the challenge of balancing security and convenience when using hardware security tokens on web pages in existing technologies. Specifically, by deploying the core control logic and data processing functions of hardware security token interaction on the server side, the client only handles communication forwarding. This avoids the risk of exposing core security logic and sensitive data in client scripts, thus improving security. Furthermore, it eliminates the need for users to pre-install any dedicated client software or drivers, enabling plug-and-play use of hardware security tokens solely through a browser, enhancing ease of use and cross-platform compatibility.

[0005] To achieve the above objectives, the embodiments of this application provide the following technical solutions: According to a first aspect of the embodiments of this application, a method for interacting with a hardware security token is provided, the method comprising: Receive a hardware security token interaction request sent by the client, the interaction request including device information of the security token hardware and security service information to be executed; Based on the device information and security service information, generate application protocol data unit instruction data; The application protocol data unit instruction data is sent to the client, so that the client forwards it to the security token hardware; Receive application protocol data unit response data returned by the client and fed back by the security token hardware; Based on the application protocol data unit response data, the system performs instruction interaction processing, generates the corresponding business processing result, and returns it to the client.

[0006] Optionally, the step of generating application protocol data unit instruction data based on the device information and security service information includes: Based on the device information, determine the instruction interaction process corresponding to the security token hardware; According to the instruction interaction process, the security business information is converted into an application protocol data unit instruction stream; The application protocol data unit instruction data to be issued is determined from the application protocol data unit instruction stream.

[0007] Optionally, the instruction interaction processing based on the application protocol data unit response data includes: Parse the application protocol data unit response data to obtain instruction execution result information; Determine whether the instruction execution result information indicates that the current instruction was executed successfully and that there are instructions that were not completed. If the current instruction is successfully executed but there are instructions that have not been completed, then the next application protocol data unit instruction data is generated based on the application protocol data unit response data. The generated next application protocol data unit instruction data is sent to the client, so that the client forwards it to the security token hardware; Receive the application protocol data unit response data returned by the client, which is the feedback from the security token hardware in response to the next application protocol data unit instruction data; Repeat the above steps until the instruction execution result information indicates that all business operations have been completed.

[0008] Optionally, after generating the application protocol data unit instruction data, the method further includes: Perform key negotiation with the security token hardware to obtain a session key; The application protocol data unit instruction data is encrypted using the session key to obtain encrypted application protocol data unit instruction data. The encrypted application protocol data unit instruction data is sent to the client.

[0009] Optionally, the step of performing key negotiation with the security token hardware to obtain a session key includes: Send a key negotiation instruction to the client, so that the client forwards the key negotiation instruction to the security token hardware; Receive the key negotiation response data returned by the client and fed back by the security token hardware; The session key is generated based on the key negotiation response data.

[0010] Optionally, before generating the application protocol data unit instruction data, the method further includes: Send a device authentication command to the client, so that the client forwards the device authentication command to the security token hardware; The system receives authentication response data returned by the client, which is generated by the security token hardware according to the device authentication instructions. The legitimacy of the security token hardware is verified based on the device information and the authentication response data. When the verification is successful, the step of generating application protocol data unit instruction data based on the device information and security business information is executed.

[0011] Optionally, after receiving the hardware security token interaction request sent by the client, the method further includes: Establish a Hypertext Transfer Security Protocol (HTTP) secure channel with the client to receive interaction requests sent by the client through the HTTP secure channel.

[0012] According to a second aspect of the embodiments of this application, an interaction system for a hardware security token is provided, the system comprising: The message receiving module is used to receive hardware security token interaction requests sent by the client. The interaction request includes device information of the security token hardware and security service information to be executed. The instruction generation module is used to generate application protocol data unit instruction data based on the device information and security service information; The instruction issuing module is used to send the application protocol data unit instruction data to the client, so that the client forwards it to the security token hardware; The message receiving module is also used to receive application protocol data unit response data returned by the client and fed back by the security token hardware; The interaction module is used to perform instruction interaction processing based on the response data of the application protocol data unit, generate the corresponding business processing result, and return it to the client.

[0013] According to a third aspect of the present application, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0014] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided having computer-readable instructions stored thereon, the computer-readable instructions being executable by a processor to implement the method described in the first aspect above.

[0015] In summary, this application provides a hardware security token interaction method, system, device, and storage medium. It involves receiving a hardware security token interaction request from a client, whereby the request includes device information of the security token hardware and security service information to be executed. Based on the device information and security service information, application protocol data unit (API) instruction data is generated. This API instruction data is then sent to the client, causing the client to forward it to the security token hardware. The system also receives API response data returned by the client and fed back by the security token hardware. Based on the API response data, instruction interaction processing is performed, and a corresponding service processing result is generated and returned to the client. By deploying the core control logic and data processing functions of the hardware security token interaction on the server side, the client only undertakes the communication forwarding responsibility. This avoids the risk of core security logic and sensitive data being exposed in the client script, improving security. Furthermore, it allows users to use the hardware security token plug-and-play directly through a browser without pre-installing any dedicated client software or drivers, enhancing ease of use and cross-platform compatibility. Attached Figure Description

[0016] 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 the structures shown in these drawings without creative effort.

[0017] The structures, proportions, sizes, etc. illustrated in this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed herein, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0018] Figure 1 A flowchart illustrating an interaction method for a hardware security token provided in an embodiment of this application; Figure 2 This is a schematic diagram of the overall interaction architecture provided for an embodiment of this application; Figure 3 A complete interactive timing diagram provided for embodiments of this application; Figure 4 A schematic diagram of an interactive system for a hardware security token provided in an embodiment of this application; Figure 5 This paper shows a structural diagram of an electronic device provided in an embodiment of this application; Figure 6 A diagram of a computer-readable storage medium provided in an embodiment of this application is shown.

[0019] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

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

[0021] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0022] Furthermore, in this invention, descriptions involving "first," "second," etc., are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0023] In this invention, unless otherwise explicitly specified and limited, the terms "connection," "fixed," etc., should be interpreted broadly. For example, "fixed" can mean a fixed connection, a detachable connection, or an integral part; it can mean a mechanical connection or an electrical connection; it can mean a direct connection or an indirect connection through an intermediate medium; it can mean the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0024] Furthermore, the technical solutions of the various embodiments of the present invention can be combined with each other, but only if they are feasible for those skilled in the art. If the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0025] Figure 1 This application illustrates an interaction method for a hardware security token provided by an embodiment of the present application. The method includes: Step 101: Receive a hardware security token interaction request sent by the client. The interaction request includes device information of the security token hardware and security service information to be executed. Step 102: Generate application protocol data unit instruction data based on the device information and security service information; Step 103: Send the application protocol data unit instruction data to the client so that the client forwards it to the security token hardware; Step 104: Receive the application protocol data unit response data returned by the client and fed back by the security token hardware; Step 105: Perform instruction interaction processing based on the application protocol data unit response data, generate the corresponding business processing result, and return it to the client.

[0026] This application provides a hardware security token interaction method that breaks away from the limitations of relying on local dedicated software and drivers when using security token hardware in traditional web pages. Hardware interaction can be completed through the browser's native communication capabilities, reducing the user's usage threshold and platform adaptation and maintenance costs.

[0027] The core logic for generating and scheduling hardware-related instructions for security tokens is uniformly deployed on the server side. The server uniformly receives hardware security token interaction requests initiated by clients, and obtains the hardware identity information and the security business content to be processed carried in the interaction request. Based on the inherent attributes of the hardware and the actual needs of the security business to be executed, the server generates application protocol data unit instruction data adapted to the identification and execution of the security token hardware, and sends it to the security token hardware through the client as a relay channel. There is no need for the front end to carry out instruction construction and business logic judgment work, reducing the security risks caused by the exposure of sensitive business logic on the front end.

[0028] The client only acts as a relay for command and response data, forwarding commands issued by the server to the security token hardware, and receiving the response data processed by the hardware and sending it back to the server. It does not participate in core business logic operations or command parsing. The server performs the complete command interaction process based on the response data returned by the hardware, generates the final business processing result based on the actual interaction execution, and sends it back to the client. This achieves convenient, driverless use of the security token hardware on the web interface while improving overall interaction security and business processing standardization.

[0029] In one possible implementation, after receiving a hardware security token interaction request sent by the client, the method further includes: establishing a Hypertext Transfer Security Protocol (HTTP) secure channel with the client to receive the interaction request sent by the client through the HTTP secure channel.

[0030] In one possible implementation, when data is transmitted through the secure channel of the Hypertext Transfer Protocol, the legitimacy of the client's identity is verified simultaneously to achieve two-way authentication between the server and the client.

[0031] Upon receiving a hardware security token interaction request from a client, this application prioritizes establishing a secure channel using the Hypertext Transfer Protocol (HTTP). This confines all subsequent interaction requests to a dedicated secure link, mitigating the risks of data leakage and tampering associated with plaintext transmission at the network level. This provides a stable and reliable communication foundation for hardware security token business interactions. The established secure channel facilitates front-end and back-end data interaction, simultaneously verifying the identities of both parties. This two-way identity confirmation between the server and client effectively blocks malicious requests from unauthorized terminals and prevents unauthorized access parties from arbitrarily connecting to the hardware security token interaction interface.

[0032] By establishing secure channels and setting up two-way identity verification before formal business interactions, communication link reinforcement and access identity screening can be completed in advance without increasing the client's additional operational burden. This reduces the security risks of unauthorized access and data eavesdropping and tampering from the source and adapts to the protection requirements of hardware security token interaction in high-security scenarios.

[0033] In one possible implementation, before generating the application protocol data unit instruction data, the method further includes: sending a device authentication instruction to the client, causing the client to forward the device authentication instruction to the security token hardware; receiving authentication response data returned by the client, the authentication response data being generated by the security token hardware based on the device authentication instruction; verifying the legitimacy of the security token hardware based on the device information and the authentication response data; and when the verification is successful, performing the step of generating the application protocol data unit instruction data based on the device information and security service information.

[0034] Before generating the corresponding instruction data, this application adds a pre-authentication process for the security token hardware. The server first issues a device authentication instruction, which is then forwarded to the security token hardware via the client, triggering the hardware to complete the identity response interaction in advance. The server receives the hardware authentication response data returned by the client and performs compliance verification in conjunction with the acquired device information. This allows for accurate determination of whether the connected security token hardware is an authorized and compliant device, effectively blocking access attempts by counterfeit or unauthorized hardware.

[0035] Only after the security token hardware's legitimacy is verified does the subsequent instruction data generation stage begin. Invalid and unauthorized access requests are filtered at the business interaction entry point, preventing the waste of system interaction resources for unauthorized hardware and preventing malicious hardware from initiating unauthorized operations through business interfaces. By placing hardware authentication before instruction generation, an access control mechanism for business interactions is established, improving the controllability of security token hardware access and the overall security level of business interactions.

[0036] In one possible implementation, step 102, generating application protocol data unit instruction data based on the device information and security service information, includes: determining an instruction interaction process corresponding to the security token hardware based on the device information; converting the security service information into an application protocol data unit instruction stream based on the instruction interaction process; and determining the application protocol data unit instruction data to be issued from the application protocol data unit instruction stream.

[0037] In generating the corresponding instruction data, this application first matches and adapts a dedicated instruction interaction process to the current security token hardware based on the device information. This ensures compatibility with the protocol specifications and interaction logic of different hardware, avoiding interaction failures caused by incompatibility between the general process and hardware. Through the established instruction interaction process, the security business information to be executed is converted into a standardized application protocol data unit instruction stream. The complete business requirements are broken down into an ordered, step-by-step instruction sequence, adapting to the working mechanism of the security token hardware that processes instructions one by one.

[0038] The system filters and extracts the single instruction data that needs to be issued from the complete instruction stream, enabling step-by-step scheduling of instruction issuance according to the process rhythm. This eliminates the need to push all instructions at once, ensuring the orderliness and controllability of instruction interaction with the security token hardware.

[0039] In one possible implementation, the instruction interaction process includes the instruction parsing rules of the security token hardware, the instruction execution order, and the response verification standard. The application protocol data unit instruction stream consists of multiple consecutive application protocol data unit instructions arranged in the order of the instruction interaction process.

[0040] In one possible implementation, after generating the application protocol data unit instruction data, the method further includes: performing key negotiation with the security token hardware to obtain a session key; encrypting the application protocol data unit instruction data using the session key to obtain encrypted application protocol data unit instruction data; and sending the encrypted application protocol data unit instruction data to the client.

[0041] In one possible implementation, performing key negotiation with the security token hardware to obtain a session key includes: sending a key negotiation instruction to the client, causing the client to forward the key negotiation instruction to the security token hardware; receiving key negotiation response data returned by the client and fed back by the security token hardware; and generating the session key based on the key negotiation response data.

[0042] After generating the instruction data, a key negotiation process is initiated with the security token hardware to generate a dedicated communication session key. The negotiated session key is then used to encrypt the application protocol data unit instruction data, carrying the business interaction instructions in ciphertext form. This prevents the instruction content from being exposed in plaintext during transmission, effectively mitigating the security risk of instruction data theft and parsing. The encrypted instruction data is then sent to the client for relay forwarding, maintaining the original interaction relay architecture while achieving end-to-end encrypted transmission of downlink instructions, balancing the simplicity of the interaction architecture with data transmission security.

[0043] The server sends key negotiation commands to the security token hardware via the client, using the client to relay commands and send responses, thus adapting to the interaction limitations of browser environments without direct hardware connection. Based on the negotiation response data from the security token hardware, the server generates and calculates the session key. The entire key interaction is managed and controlled by the server, without requiring client participation in key calculation logic, thus avoiding the exposure of sensitive key-related logic on the front end.

[0044] In one possible implementation, the Hypertext Transfer Security Protocol (HTTP) secure channel performs secondary encryption on the transmitted encrypted application protocol data unit instruction data, forming a two-layer data security protection system together with the encryption of the session key.

[0045] In one possible implementation, step 105, the instruction interaction processing based on the application protocol data unit response data, includes: parsing the application protocol data unit response data to obtain instruction execution result information; determining whether the instruction execution result information indicates that the current instruction was successfully executed and that there are instructions that have not been completed; if it indicates that the current instruction was successfully executed and that there are instructions that have not been completed, then generating the next application protocol data unit instruction data based on the application protocol data unit response data; sending the generated next application protocol data unit instruction data to the client so that the client forwards it to the security token hardware; receiving the application protocol data unit response data returned by the client, which is fed back by the security token hardware for the next application protocol data unit instruction data; repeating the above steps until the instruction execution result information indicates that all services have been completed.

[0046] After obtaining the application protocol data unit response data returned by the security token hardware, this application first parses and processes the response data to extract the corresponding instruction execution result information, thus understanding the actual execution status of each instruction on the hardware side. Logical judgments are then performed based on the parsed execution result information to confirm whether the current instruction was executed successfully and whether there are any remaining business instructions to be processed, allowing the overall interaction process to automatically flow based on the actual hardware feedback.

[0047] If the current instruction executes successfully but there are still incomplete business instructions, the next application protocol data unit instruction data is generated based on the existing response data. The interaction process continues to advance according to the rhythm of the business process, enabling the server to uniformly schedule and control the entire set of business instructions. The newly generated instruction data is sent to the client and forwarded to the security token hardware by the client. At the same time, the response data of the hardware for the new round of instructions is received, maintaining the consistency of the relay interaction architecture between the front-end, back-end and hardware.

[0048] The entire process of instruction parsing, status judgment, instruction generation, issuance, and response reception is executed in a loop until the instruction execution result information indicates that all security services have been completed. The server centrally manages the multi-round instruction interaction logic, eliminating the need for the front end to handle business branch judgment and process scheduling. This simplifies the client processing logic while ensuring the orderliness of multi-round instruction interaction and the complete closed loop of the overall business process.

[0049] In one possible implementation, the instruction execution result information includes the instruction execution status and the current working status of the security token hardware. When the instruction execution result information indicates that the current instruction execution has failed, the instruction interaction processing is terminated, and a corresponding error message is generated and returned to the client.

[0050] In one possible implementation, the device information includes a supplier identifier and a product identifier; the supplier identifier is used to identify the device manufacturer corresponding to the security token hardware, and the product identifier is used to identify the device model or unique device number corresponding to the security token hardware.

[0051] In one possible implementation, the client is a terminal browser, which establishes communication with the security token hardware through its native communication capabilities, without the need to install additional dedicated client software or hardware drivers.

[0052] To more clearly illustrate the implementation process of the above hardware security token interaction method, the interaction architecture and timing flow provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0053] This application provides an interaction method for a hardware security token. The overall interaction architecture can be found by referring to... Figure 2 The interaction topology is shown below. The hardware security token is a USB Key. The USB Key vendor provides three core components: USB Key hardware, USB Key JS interface package, and USB Key management service. The USB Key JS interface package provides the USB Key functionality API, which is integrated into the web application's source code during development. The USB Key management service is deployed on the server side and can be hosted by the web application's service provider or directly managed by the USB Key vendor. The server-side management service fully executes the entire hardware security token interaction process, sequentially completing interaction request reception, pre-security verification, command generation and distribution, response data reception, and multi-round interaction scheduling, forming a closed-loop server-side business control logic.

[0054] Figure 2In this process, the page's JavaScript initiates business requests by calling the API provided by the JS interface package. The JS interface package also handles data relay and protocol conversion. On one hand, it establishes a secure channel with the USB Key management service via the HTTPS protocol; on the other hand, it interacts with the browser's operating system via the Web USB protocol, and then establishes a connection with the USB Key hardware via the system's USB driver. The server receives hardware security token interaction requests from the client through the established secure channel. Before formally engaging in business command interaction, it verifies the identity and legitimacy of the security token hardware, and then combines the acquired device information with security business information to generate matching interaction command data. The USB Key management service completes identity authentication, key negotiation, and command interaction with the USB Key hardware through a security protocol. The entire process requires no additional software or drivers to be installed on the user's client; remote control of the security token hardware can be achieved solely through the browser's native capabilities.

[0055] Figure 3 The diagram illustrates the interaction sequence between the user client-side web application, the USB Key JS interface package, the browser, the USB Key hardware, and the server-side USB Key management service. The process is divided into two main phases.

[0056] The first stage is the local device discovery process. The JS interface package calls the Web USB API to declare the USB device information to be accessed. The browser and operating system complete the device enumeration process of the USB protocol. After user authorization, the browser returns an available device object to the JS interface package, completing the preparatory work for device access and providing a reliable device information foundation for the server to receive interaction requests and conduct hardware legitimacy verification.

[0057] The second phase involves a multi-round interaction between the management service and the USB Key. The JS interface package initiates an HTTPS request to the USB Key management service, sending device information and the USB Key function to be executed. After receiving the interaction request from the client, the server matches the corresponding security token hardware's specific instruction interaction flow based on the device information. Then, it organizes the security business information into a standard instruction stream according to the established interaction flow, and simultaneously filters out the instruction data suitable for issuance from the instruction stream. After generating the instruction data, the server and the security token hardware complete key negotiation and generate a unique session key. The session key is used to encrypt the instruction data before the encrypted instruction is sent to the JS interface package.

[0058] The JS interface package sends command data to the USB Key hardware via the Web USB API and sends the response data returned by the hardware back to the management service. The server parses the returned response data, extracts the corresponding command execution result information, and determines whether to generate the next command and repeat the interaction based on the execution status. This process can be repeated multiple times until the entire business process is completed.

[0059] The management service and the USB Key hardware undergo a session key negotiation process. Upon successful negotiation, APDU command data is transmitted in encrypted form. Building upon this command encryption, the JS interface package and the management service transmit data via an HTTPS channel. This process achieves both authentication of the management service and secondary encryption of the encrypted data, forming a two-layer security system. After completing the business logic, the management service returns the final result to the JS interface package, which then returns it to the page's JavaScript. The page remains unaware of the management service's existence, maintaining a consistent user experience with traditional local client solutions.

[0060] Based on the aforementioned interaction architecture and timing process, the hardware security token interaction method provided in this application migrates the core control logic of the hardware security token, originally deployed on the local client, to the server for unified operation. The server receives interaction requests from the client carrying device information and security business information, establishes a secure transmission channel in advance, completes pre-verification of hardware legitimacy, determines a dedicated interaction process based on device attributes and business requirements, generates standardized instruction data, and after key negotiation and instruction encryption, transparently relays it to the security token hardware via the client. Simultaneously, the server receives response data from the hardware and performs multiple rounds of instruction interaction processing, ultimately generating a compliant business processing result and sending it back to the client.

[0061] By centrally hosting core business logic such as instruction generation, process scheduling, identity authentication, and encryption protection on the server side, and forming a two-layer data security protection through secure transmission channels and session keys, this approach not only improves the problems of cumbersome installation processes, poor cross-platform compatibility, and high maintenance costs associated with traditional client solutions, but also avoids the security risks of reverse engineering and tampering with core business logic carried by front-end scripts. Relying solely on a browser without the need for additional software and drivers, it effectively enhances the standardization of hardware security token business interaction processes and the overall level of security protection.

[0062] In summary, this application provides a hardware security token interaction method, system, device, and storage medium. It involves receiving a hardware security token interaction request from a client, whereby the request includes device information of the security token hardware and security service information to be executed. Based on the device information and security service information, application protocol data unit (API) instruction data is generated. This API instruction data is then sent to the client, causing the client to forward it to the security token hardware. The system also receives API response data returned by the client and fed back by the security token hardware. Based on the API response data, instruction interaction processing is performed, and a corresponding service processing result is generated and returned to the client. By deploying the core control logic and data processing functions of the hardware security token interaction on the server side, the client only undertakes the communication forwarding responsibility. This avoids the risk of core security logic and sensitive data being exposed in the client script, improving security. Furthermore, it allows users to use the hardware security token plug-and-play directly through a browser without pre-installing any dedicated client software or drivers, enhancing ease of use and cross-platform compatibility.

[0063] Based on the same technical concept, embodiments of this application also provide an interaction system for a hardware security token, such as... Figure 4 As shown, the system includes: The message receiving module 401 is used to receive a hardware security token interaction request sent by the client. The interaction request includes device information of the security token hardware and security service information to be executed. The instruction generation module 402 is used to generate application protocol data unit instruction data based on the device information and security service information; The instruction issuing module 403 is used to send the application protocol data unit instruction data to the client, so that the client forwards it to the security token hardware; The message receiving module 401 is also used to receive application protocol data unit response data returned by the client and fed back by the security token hardware; The interaction module 404 is used to perform instruction interaction processing based on the response data of the application protocol data unit, generate the corresponding business processing result, and return it to the client.

[0064] This application also provides an electronic device corresponding to the method provided in the foregoing embodiments. Please refer to... Figure 5The diagram illustrates an electronic device provided by some embodiments of this application. The electronic device 20 may include: a processor 200, a memory 201, a bus 202, and a communication interface 203, wherein the processor 200, the communication interface 203, and the memory 201 are connected via the bus 202; the memory 201 stores a computer program that can run on the processor 200, and when the processor 200 runs the computer program, it executes the method provided by any of the foregoing embodiments of this application.

[0065] The memory 201 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one physical port (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network.

[0066] Bus 202 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. The memory 201 is used to store programs. After receiving an execution instruction, the processor 200 executes the program. The method disclosed in any of the foregoing embodiments of this application can be applied to the processor 200, or implemented by the processor 200.

[0067] The processor 200 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 200 or by instructions in software form. The processor 200 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 201. The processor 200 reads the information in memory 201 and, in conjunction with its hardware, completes the steps of the above method.

[0068] The electronic devices and methods provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods they employ, operate, or implement.

[0069] This application also provides a computer-readable storage medium corresponding to the method provided in the foregoing embodiments. Please refer to... Figure 6 The computer-readable storage medium shown is an optical disc 30, on which a computer program (i.e., a program product) is stored, which, when run by a processor, executes the methods provided in any of the foregoing embodiments.

[0070] It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0071] The computer-readable storage medium provided in the above embodiments of this application and the method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0072] It should be noted that the above embodiments are illustrative of this application and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0073] The above description is merely a preferred embodiment of this application, but the scope of protection of this application 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 this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0074] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. All equivalent structural transformations made under the concept of the present invention using the contents of the present invention specification and drawings, or direct / indirect applications in other related technical fields, are included within the patent protection scope of the present invention.

Claims

1. A method for interacting with a hardware security token, characterized in that, The method includes: Receive a hardware security token interaction request sent by the client, the interaction request including device information of the security token hardware and security service information to be executed; Based on the device information and security service information, generate application protocol data unit instruction data; The application protocol data unit instruction data is sent to the client, so that the client forwards it to the security token hardware; Receive application protocol data unit response data returned by the client and fed back by the security token hardware; Based on the application protocol data unit response data, the system performs instruction interaction processing, generates the corresponding business processing result, and returns it to the client.

2. The method as described in claim 1, characterized in that, The step of generating application protocol data unit instruction data based on the device information and security service information includes: Based on the device information, determine the instruction interaction process corresponding to the security token hardware; According to the instruction interaction process, the security business information is converted into an application protocol data unit instruction stream; The application protocol data unit instruction data to be issued is determined from the application protocol data unit instruction stream.

3. The method as described in claim 1, characterized in that, The instruction interaction processing based on the application protocol data unit response data includes: Parse the application protocol data unit response data to obtain instruction execution result information; Determine whether the instruction execution result information indicates that the current instruction was executed successfully and that there are instructions that were not completed. If the current instruction is successfully executed but there are instructions that have not been completed, then the next application protocol data unit instruction data is generated based on the application protocol data unit response data. The generated next application protocol data unit instruction data is sent to the client, so that the client forwards it to the security token hardware; Receive the application protocol data unit response data returned by the client, which is the feedback from the security token hardware in response to the next application protocol data unit instruction data; Repeat the above steps until the instruction execution result information indicates that all business operations have been completed.

4. The method as described in claim 1, characterized in that, After generating the application protocol data unit instruction data, the method further includes: Perform key negotiation with the security token hardware to obtain a session key; The application protocol data unit instruction data is encrypted using the session key to obtain encrypted application protocol data unit instruction data. The encrypted application protocol data unit instruction data is sent to the client.

5. The method as described in claim 4, characterized in that, The step of performing key negotiation with the security token hardware to obtain a session key includes: Send a key negotiation instruction to the client, so that the client forwards the key negotiation instruction to the security token hardware; Receive the key negotiation response data returned by the client and fed back by the security token hardware; The session key is generated based on the key negotiation response data.

6. The method as described in claim 1, characterized in that, Before generating the application protocol data unit instruction data, the method further includes: Send a device authentication command to the client, so that the client forwards the device authentication command to the security token hardware; The system receives authentication response data returned by the client, which is generated by the security token hardware according to the device authentication instructions. The legitimacy of the security token hardware is verified based on the device information and the authentication response data. When the verification is successful, the step of generating application protocol data unit instruction data based on the device information and security business information is executed.

7. The method as described in claim 1, characterized in that, After receiving the hardware security token interaction request sent by the client, the method further includes: Establish a Hypertext Transfer Security Protocol (HTTP) secure channel with the client to receive interaction requests sent by the client through the HTTP secure channel.

8. An interactive system for a hardware security token, characterized in that, The system includes: The message receiving module is used to receive hardware security token interaction requests sent by the client. The interaction request includes device information of the security token hardware and security service information to be executed. The instruction generation module is used to generate application protocol data unit instruction data based on the device information and security service information; The instruction issuing module is used to send the application protocol data unit instruction data to the client, so that the client forwards it to the security token hardware; The message receiving module is also used to receive application protocol data unit response data returned by the client and fed back by the security token hardware; The interaction module is used to perform instruction interaction processing based on the response data of the application protocol data unit, generate the corresponding business processing result, and return it to the client.

9. An electronic device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when running the computer program, performs an action to implement the method as claimed in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores computer-readable instructions that can be executed by a processor to implement the method as described in any one of claims 1-7.

Images