Server high-strength authentication access control method based on hardware key

Abstract

The present application relates to the field of information security technology, in particular to a server high-strength identity authentication access control method based on hardware Key, comprising: disassembling hardware Key certificate to extract static identification component and variable coding component. The static identification component is compared with the registration list, and the derivative verification strategy containing additional verification link associated with the device in the list is activated. At the same time, the variable coding component is continuously processed through a special pipeline to generate a dynamic check factor. The dynamic factor and the verification element are combined to form a stage verification load, and the verification is performed by the server verification engine according to the strategy logic. The access control decision is generated according to the intermediate state of verification. The method realizes the differentiated dynamic triggering of the verification strategy based on the difference of the device identity, and enhances the dynamic anti-fake and anti-attack ability of the authentication data through the deep processing of the variable coding.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a server high-strength authentication access control method based on hardware keys. Background Technology

[0002] Traditional hardware key-based server access control methods primarily rely on the overall verification of static credentials such as digital certificates and fixed token codes stored within the hardware key. The server verification process is predefined and globally uniform, with all devices holding legitimate hardware keys undergoing the same authentication steps. This method treats the hardware key as a single, homogeneous authentication factor, making verification decisions directly based on the overall validity of the credentials.

[0003] Existing technical solutions have shortcomings. A static, uniform verification process cannot adaptively adjust to the individual identity or potential risk level of the requesting device. Even if the hardware key credential itself is valid, the system cannot implement differentiated verification strength or additional checks for specific devices during the verification process. For common variable-encoded components in hardware keys, existing methods typically involve direct comparison, simple hashing, or time-synchronized calculation, with relatively fixed and transparent algorithms for generating checksums. This approach has limited complexity and randomness, potentially allowing verification patterns to be analyzed or predicted.

[0004] The issues to be addressed include how to dynamically activate differentiated verification strategies based on device identity at the initial stage of verification, and how to improve the processing strength of variable coded components to generate dynamic verification elements that are resistant to analysis and replay protection. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing a server high-strength authentication access control method based on hardware keys.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: a server high-strength authentication access control method based on a hardware key, comprising:

[0007] Obtain the original access request initiated by the hardware key device, wherein the original access request encapsulates the native device credentials bound to the hardware key device;

[0008] The native device certificate is decomposed into a certificate structure, and static identifier components and variable code components are extracted from the native device certificate;

[0009] The static identifier component is compared with a preset list of registered devices, and the hardware key device is classified as a device in the list or a device to be verified based on the comparison result. When the hardware key device is a device in the list, the derived verification strategy associated with the static identifier component is activated. The derived verification strategy includes at least one additional verification step.

[0010] The variable coding components are input into a pre-built coding conversion pipeline, and a dynamic check factor is generated through continuous processing of the coding conversion pipeline.

[0011] By combining the dynamic verification factor with the verification elements required by the additional verification steps, a stage verification load is constructed.

[0012] The stage verification payload is submitted to the server's verification execution engine, which triggers the verification execution engine to perform authentication according to the logical sequence defined by the derived verification strategy;

[0013] The intermediate state data generated by the verification execution engine during the processing of the stage verification payload is captured, and the identity verification is determined based on the intermediate state data. An access control decision is generated based on the determination result.

[0014] Preferably, the credential structure decomposition of the native device credential includes the following steps:

[0015] Identify the encoding format and encapsulation boundary of the native device credential, and call the corresponding decoder to decode the native device credential according to the encoding format to obtain the plaintext credential data stream;

[0016] Locate the delimiter sequence in the plaintext voucher data stream, the delimiter sequence being composed of a predefined character or byte pattern;

[0017] The plaintext voucher data stream is divided into multiple voucher data segments based on the delimiter sequence;

[0018] Data segments that conform to the preset static feature template are selected from the voucher data segments and classified as static identifier components;

[0019] From the remaining voucher data fragments, data fragments with variable encoding lengths and random content are selected and classified as variable encoding components.

[0020] Preferably, comparing the static identifier component with a preset list of registered devices includes the following steps:

[0021] Load the registered device list, which is organized in a tree structure, with its leaf nodes storing the complete static identifier of the authorized hardware key device;

[0022] The static identifier component is matched with the root node of the tree structure level by level, and each level of matching is based on a portion of the fields of the static identifier component.

[0023] If a match fails at a certain level, the matching process is terminated, and the hardware key device is marked as a device to be verified.

[0024] If the matching process traverses to a leaf node of the tree structure and the static identifier component is completely consistent with the complete static identifier stored in the leaf node, then the hardware key device is classified as a device in the directory, and the policy index identifier associated with the leaf node is recorded.

[0025] Preferably, activating the derived verification strategy associated with the static identifier component includes the following steps:

[0026] Retrieve the corresponding basic policy template from the policy repository based on the policy index identifier;

[0027] Query the recent historical access logs of the hardware key device, and analyze the access behavior pattern characteristics from the historical access logs;

[0028] The access behavior pattern features are used as input parameters and injected into the policy variable slots of the basic policy template.

[0029] The strategy generation script embedded in the basic strategy template is executed. The strategy generation script dynamically combines and adjusts the verification process according to the injected access behavior pattern characteristics, and outputs the derived verification strategy.

[0030] The derived verification strategy is described in the form of a directed graph, where vertices represent verification steps and edges represent the execution order and condition jump relationships between steps.

[0031] Preferably, generating a dynamic check factor through continuous processing in the encoding conversion pipeline includes the following steps:

[0032] The encoding conversion pipeline consists of multiple sequentially connected conversion units, each of which is configured with specific encoding operation rules.

[0033] The variable coded component is input to the first conversion unit, which applies its encoding operation rules to perform an initial transformation on the variable coded component and outputs intermediate result one.

[0034] The intermediate result one is passed to the next conversion unit, which combines the partial information of the static identifier component with the intermediate result one to perform a composite operation and output the intermediate result two.

[0035] After being processed by all the conversion units in sequence, the output of the last conversion unit is defined as the primary dynamic factor;

[0036] The primary dynamic factor is concatenated with the current system timestamp, and a one-way hash is calculated on the concatenated data. The resulting hash value is used as the final dynamic verification factor.

[0037] Preferably, constructing the staged verification load includes the following steps:

[0038] From the directed graph defined by the derived verification strategy, read the attributes of the verification step to be executed, the attributes including a list of verification element types required by the verification step;

[0039] Based on the list of verification element types, retrieve the corresponding baseline verification element from the local secure storage;

[0040] The dynamic verification factor and the benchmark verification element are fused bitwise to generate a fused verification element.

[0041] The fusion verification elements, the unique identifier of the verification step, and the classification information of the hardware key device are jointly encapsulated to form a stage verification payload for the verification step.

[0042] Preferably, triggering the verification execution engine to perform authentication according to the logical sequence defined by the derived verification strategy includes the following steps:

[0043] The verification execution engine parses the received stage verification payload and extracts the unique identifier of the verification step.

[0044] Based on the unique identifier, locate the corresponding vertex in the directed graph of the derived verification strategy;

[0045] The specific verification logic of the verification stage represented by the vertex is executed, and the verification logic includes parsing and verifying the fused verification elements in the stage verification load;

[0046] During the execution of the verification logic, information reflecting the verification progress, data matching status, and abnormal events is generated in real time. The information reflecting the verification progress, data matching status, and abnormal events together constitutes the intermediate state data.

[0047] Based on the execution result of the current verification step and the edge conditions defined in the directed graph, the next verification step to be executed is determined, and the system waits for the next corresponding stage verification load.

[0048] Preferably, capturing the intermediate state data generated by the verification execution engine during the processing of the stage verification payload includes the following steps:

[0049] Probe hooks are set within the verification execution engine, and these probe hooks are implanted into the key logic judgment points of each verification step.

[0050] When the execution flow passes through the key logic judgment point, the corresponding probe hook is triggered to collect the local variable values, logic judgment results and stack snapshot information at that time;

[0051] Information collected from different probe hooks is summarized and correlated in chronological order, with timestamps and stage identifiers added to form a structured intermediate state data stream;

[0052] The intermediate state data stream is continuously written to a circular buffer for real-time reading during the process of determining whether the authentication is successful.

[0053] Preferably, determining whether the authentication is successful based on the intermediate state data includes the following steps:

[0054] Read the latest intermediate state data stream from the circular buffer;

[0055] Pattern matching is performed on the intermediate state data stream based on predefined verification success rule templates and verification failure rule templates;

[0056] If a sequence of events matching the verification success rule template appears consecutively in the intermediate state data stream, and no key event matching the verification failure rule template appears, then the identity verification is deemed successful.

[0057] If a key event matching the verification failure rule template appears in the intermediate state data stream, or if the complete sequence of the verification success rule template is not matched, then the authentication is determined to have failed.

[0058] Generate access control decisions that include a conclusion and a summary of the main criteria.

[0059] Preferably, after generating the access control decision, the following steps are also included:

[0060] The native device credentials, static identifier components, variable encoding components, dynamic verification factors, verification payloads at each stage, intermediate state data streams, and final access control decisions generated throughout the entire authentication process are associated and bound together.

[0061] The complete data records after association and binding are standardized and formatted to generate tamper-proof audit traceability entries;

[0062] The audit traceability entries are synchronously stored in the local audit database and the remote security log server;

[0063] Periodically perform cluster analysis on the audit traceability entries to update the tree structure of the registered device directory and optimize the basic strategy template for the derived verification strategy.

[0064] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0065] By extracting the static identifier component from the hardware key's native credentials, the system compares and categorizes them against a pre-defined list of registered devices at the initial verification stage. Based on the device classification result, a derived verification strategy pre-associated with this static identifier component is activated. This strategy defines at least one additional verification step and its execution logic sequence. This transforms the verification process from a fixed model to a programmable, device-identity-bound dynamic model. The system can configure the strategy to incorporate verification challenges of varying complexity and type for different devices or access scenarios. The strength of access control can be finely adjusted at the initial stage of session establishment, rather than applying equal strength checks to all legitimate devices. The system's ability to dynamically construct verification paths based on device identity attributes is enhanced, improving the flexibility of strategies to address risks such as credential misuse.

[0066] An independent encoding conversion pipeline is constructed, performing a series of continuous, non-linear processing operations on the variable encoding components to ultimately generate a dynamic verification factor. This process replaces direct comparison or simple encryption of the variable encoding. The generation logic of the dynamic verification factor is built into the pipeline, and its mapping relationship with the original encoding is complex and concealed. This factor, combined with additional verification elements, forms a unique stage verification payload for each request. Due to the dynamic and unpredictable nature of the core elements of the payload, attackers find it difficult to forge valid authentication requests by eavesdropping or analyzing historical data. This increases the difficulty of replay attacks and man-in-the-middle attacks, strengthening the data security of the authentication process itself. Attached Figure Description

[0067] Figure 1 This is a flowchart of the server high-strength authentication access control method based on hardware key as described in this invention;

[0068] Figure 2 A flowchart for activating the derived verification strategy associated with the static identifier component;

[0069] Figure 3 A bar chart comparing the uniqueness of dynamic factors under different encoding conversion rules;

[0070] Figure 4 A bar chart analyzing the frequency of probe hook data acquisition;

[0071] Figure 5 A comparison chart of the entire process of hardware key authentication. Detailed Implementation

[0072] 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 and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0073] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0074] See Figure 1 The method begins by receiving an initial access request initiated by a hardware key device, which encapsulates the native device credentials bound to that hardware key device. The system then performs a credential structure decomposition operation on the native device credentials, separating and extracting a static identifier component and a variable encoding component. The extracted static identifier component is sent to a pre-defined list of registered devices for comparison. Based on the comparison result, the hardware key device is classified as either a device within the list or a device awaiting verification. When the hardware key device is confirmed to be a device within the list, the system activates a derived verification policy pre-associated with the static identifier component. This policy defines a logical sequence containing at least one additional verification step. Simultaneously, the system inputs the variable encoding component into a pre-built encoding conversion pipeline, which generates a dynamic verification factor through a series of continuous conversion processes. The system combines this dynamic verification factor with the verification elements required by the currently executed additional verification step to construct a staged verification payload. This staged verification payload is submitted to the server's verification execution engine, which triggers and executes the specific authentication process according to the logical sequence defined by the derived verification policy. During the verification of the payload in the execution engine processing phase, the system captures intermediate state data generated by the engine and determines whether the authentication is successful based on this intermediate state data. Finally, it generates corresponding access control decisions based on the determination results.

[0075] In one embodiment of the present invention, the system performs credential structure decomposition, including steps such as identifying the encoding format and encapsulation boundaries of the native device credential, calling the corresponding decoder for decoding, locating the delimiter sequence, segmenting the plaintext credential data stream, and filtering data fragments. The system identifies the encoding format and encapsulation boundaries of the native device credential, and calls the corresponding decoder to decode the native device credential according to the identified encoding format, thereby obtaining the plaintext credential data stream. In some embodiments, the system locates a delimiter sequence composed of predefined character or byte patterns in the plaintext credential data stream, segments the plaintext credential data stream into multiple credential data fragments based on the located delimiter sequence, filters out data fragments that conform to a preset static feature template from the segmented credential data fragments, classifies them as static identifier components, and filters out data fragments with variable encoding length and random content from the remaining credential data fragments, classifying them as variable encoding components. In a specific implementation, the preset static feature template defines the format specifications and content characteristics of the static identifier components. The system uses a matching function to evaluate the degree of conformity between each credential data fragment and the preset static feature template. The formal expression of the matching function is as follows:

[0076]

[0077] in: Represents a fragment of voucher data. Represents a preset static feature template. This indicates that the voucher data fragment is judged according to predefined rules. Does it conform to the preset static feature template? The logical condition, when When the return value is true, the voucher data fragment It is classified as a static identifier component.

[0078] It is understandable that the encoding format recognition process involves parsing the header information or metadata of the native device credential. The decoder converts the data according to the encoding format, such as Base64, hexadecimal, or a custom binary format. The delimiter sequence is predefined by the system and may contain specific character combinations or byte patterns, such as two consecutive colons or a specific sequence of byte values. The segmentation operation divides the plaintext credential data stream into discrete credential data fragments based on the position of the delimiter sequence. The process of filtering statically identified components relies on the matching rules of preset static feature templates. These rules may include fixed length, specific character sets, or checksum verification. The process of filtering variable-encoded components focuses on the variability of the encoding length and the randomness of the content presentation, such as judging the degree of randomness of the data fragments through entropy calculation.

[0079] Optionally, the system uses a sliding window algorithm to scan the plaintext voucher data stream when locating the delimiter sequence until a sequence completely matching a predefined pattern is found. After segmenting the voucher data, a fragment list is generated for subsequent filtering. Matching function. Logical conditions Specifically, this can be implemented as pattern matching, regular expression validation, or field alignment checking. The system traverses the fragment list, applies a matching function to each voucher data fragment, and assigns fragments with a result of true to the static identifier component set. The remaining fragments are further assigned to the variable encoding component set based on the length variation range and randomness test.

[0080] In one embodiment of the present invention, see [reference] Figure 2 This describes the specific operational process of comparing the static identifier component with a pre-set list of registered devices and activating the derived verification strategy associated with the static identifier component. In practice, the system loads a list of registered devices organized in a tree structure. The leaf nodes of the list store the complete static identifier of the authorized hardware key device. The system performs a step-by-step matching of the static identifier component, starting from the root node of the tree structure. Each level of matching is based on a portion of the static identifier component's fields. If a match fails at a certain level, the system terminates the matching process and marks the hardware key device as a device to be verified. If the matching process successfully traverses to a leaf node in the tree structure, and the static identifier component completely matches the complete static identifier stored in the leaf node, the system classifies the hardware key device as a device within the list and records the strategy index identifier associated with the leaf node.

[0081] In some embodiments, the system retrieves the corresponding basic policy template from the policy repository based on the policy index identifier, queries the recent historical access logs of the hardware key device, and analyzes the access behavior pattern characteristics from the historical access logs. The access behavior pattern characteristics are injected as input parameters into the policy variable slots of the basic policy template. The system executes the policy generation script embedded in the basic policy template. The policy generation script dynamically combines and adjusts the verification steps according to the injected access behavior pattern characteristics, outputting a derived verification policy described in the form of a directed graph. In the derived verification policy graph, vertices represent verification steps, and edges represent the execution order and conditional jump relationships between steps. In specific implementations, access behavior pattern feature analysis involves the quantitative extraction and pattern recognition of fields such as timestamps, access frequency, operation sequences, and resource request patterns in historical access logs. The system uses a feature extraction function... From historical access logs In the time window Calculate the eigenvectors internally ,in Represents the feature extraction function. Represents a historical access log dataset. This represents the set analysis time window. This represents the calculated multidimensional feature vector, which... The policy variable slots are fully injected into the base policy template.

[0082] As can be understood, each level of the tree structure corresponds to a specific field of a static identifier component. For example, the root node represents the device manufacturer code, child nodes represent the device model sequence, and leaf nodes represent unique device serial numbers. The matching process is performed recursively, field by field. The policy repository is a database that stores multiple basic policy templates, each bound to a unique policy index identifier. Policy variable slots are predefined location markers in the basic policy templates used to receive external input parameters. The policy generation script is executable code logic embedded in the basic policy templates, responsible for generating the final directed graph of derived verification policies based on the input parameters. The vertices in the directed graph of derived verification policies contain the specific logical definitions of the verification steps, while the edges define the conditions for transitions between vertices.

[0083] Optionally, during hierarchical matching, the system segments the static identifier component according to predefined field lengths and orders. Starting from the root node, it uses the current field to query the list of child nodes of the current node. If a matching child node is found, it proceeds to the next level of matching; otherwise, the matching fails. Feature extraction function The specific implementation may include calculating statistical values ​​of access counts, identifying patterns in access time distribution, or constructing a Markov chain model of operation sequences. When the system executes the strategy generation script, the script logic reads the injected feature vectors. and based on The values ​​in the graph determine which verification steps are enabled, the threshold values ​​for transitions between steps are set, and the verification parameters are adjusted, thereby instantiating the directed graph. For example, when the feature vector... When the "unconventional time access flag" value is high, the policy generation script may add a biometric kernel vertex to the directed graph and set the edge condition from the previous vertex to the newly added vertex to "when the flag value exceeds the threshold K".

[0084] In one embodiment of the present invention, the specific operation process of generating dynamic verification factors and constructing verification payloads through continuous processing of the encoding conversion pipeline is described. In a specific implementation, the system generates dynamic verification factors by configuring the encoding conversion pipeline, sequentially processing variable encoded components, combining static identifier component information, generating primary dynamic factors, and performing hash calculations. The encoding conversion pipeline consists of multiple sequentially connected conversion units, each configured with encoding operation rules. The system inputs the variable encoded components to the first conversion unit, which applies the encoding operation rules to perform an initial transformation on the variable encoded components and outputs intermediate result one. Intermediate result one is passed to the next conversion unit, which combines partial information from the static identifier component with intermediate result one to perform a composite operation and outputs intermediate result two. The system sequentially processes all conversion units and defines the result output by the last conversion unit as the primary dynamic factor. The system concatenates the primary dynamic factor with the current system timestamp and performs a one-way hash calculation on the concatenated overall data, using the resulting hash value as the final dynamic verification factor.

[0085] In some embodiments, the system constructs a stage verification payload including steps such as reading verification stage attributes, retrieving baseline verification elements, performing bitwise fusion operations, and encapsulating the payload. The system reads the attributes of the currently to-be-executed verification stage from the directed graph defined by the derived verification strategy. The attributes of the verification stage include a list of verification element types required by the verification stage. The system retrieves the corresponding baseline verification elements from local secure storage based on the verification element type list, performs a bitwise fusion operation between the dynamic check factor and the baseline verification elements to generate a fused verification element, and encapsulates the fused verification element, the unique identifier of the verification stage, and the classification information of the hardware key device to form a stage verification payload for the verification stage. In a specific implementation, the bitwise fusion operation follows a fusion function, the formal expression of which is:

[0086]

[0087] in: Represents the fusion function. Represents the dynamic check factor. Represents the benchmark verification element, This indicates a bitwise XOR operation. This indicates a circular left shift operation. The fusion function represents the displacement constant derived from the unique identifier in the verification process. The output is the fusion verification element.

[0088] It is understandable that each conversion unit in the encoding conversion pipeline performs mathematical transformations or encoding operations. Composite operations introduce partial information from the static identifier component to enhance the binding relationship between the dynamic verification factor and the hardware key device. One-way hash calculation uses cryptographic hash functions such as SHA-256, which process and concatenate data to generate a fixed-length dynamic verification factor. The verification element type list explicitly specifies the data format and identifier of the baseline verification element, and local secure storage protects the confidentiality of the baseline verification element through access control mechanisms. Bitwise fusion operations combine the dynamic verification factor with the baseline verification element to generate a temporary fused verification element, which is only used in the current verification stage. The encapsulation process serializes the fused verification element, the unique identifier of the verification stage, and the classification information of the hardware key device into a structured data packet, which contains the necessary header information and payload.

[0089] Optionally, the encoding operation rules include linear feedback shift register operations or S-box substitution. Composite operations perform modulo addition on a specified byte segment of the statically identified component and the intermediate result in a specific conversion unit. The system timestamp is obtained from a high-precision clock source, and the timestamp data is converted to a standard format before being concatenated. Displacement constant. The unique identifier in the verification process is obtained by calculating the CRC checksum and performing a modulo operation, followed by a circular left shift operation. The number of bits is determined by the displacement constant. Confirmed. The phase verification payload is encapsulated in TLV format, with each field containing type, length, and value. The hardware key device classification information indicates whether the device is a listed device or a device to be verified.

[0090] Optionally, when retrieving benchmark verification elements from local secure storage, the system performs a lookup operation based on the type identifier in the verification element type list. The benchmark verification elements are stored in encrypted form and decrypted in memory for use. Fusion function Ensure dynamic check factor With benchmark verification elements The elements are thoroughly mixed and merged, and then cleared from memory after the verification process is complete. Before being submitted to the verification execution engine, the stage verification payload is appended with a message authentication code, which is calculated based on the shared key and the payload content.

[0091] See Figure 3This is a bar chart comparing the uniqueness of dynamic factors under different encoding conversion rules. It visually demonstrates the uniqueness performance of dynamic check factors with different sample sizes under five encoding conversion rules: LFSR, S-box replacement, modulo addition, bit rearrangement, and hybrid rules. The uniqueness of all rules decreases slightly with increasing sample size, but the "hybrid rule" shows the smallest decrease, while the "LFSR rule" shows the largest decrease. This trend verifies the difference in algorithm stability at different scales. The chart provides a quantitative basis for algorithm selection in the encoding conversion pipeline, clarifies the advantages of the "hybrid rule," and can directly guide system optimization. By comparing the performance of different rules under large samples, engineers can find the optimal balance between algorithm complexity, performance overhead, and security strength. The data shows that using a hybrid approach with multiple algorithms can effectively improve the collision resistance of dynamic check factors, which is crucial for ensuring the security of hardware key authentication.

[0092] In one embodiment of the present invention, the specific operation process of triggering the verification execution engine to perform identity verification according to the logical sequence defined by the derived verification strategy and capturing the intermediate state data generated by the verification execution engine during the processing of the stage verification payload is as follows: In a specific implementation, the verification execution engine parses the received stage verification payload and extracts the unique identifier of the verification link. Based on the extracted unique identifier, it locates the corresponding vertex in the directed graph of the derived verification strategy and executes the specific verification logic of the verification link represented by the vertex. The verification logic includes parsing and verifying the fused verification elements in the stage verification payload. During the execution of the verification logic, information reflecting the verification progress, data matching status and abnormal events is generated in real time. This information together constitutes the intermediate state data. Based on the execution result of the current verification link and the edge conditions defined in the directed graph, the next verification link to be executed is determined. The system waits for the next corresponding stage verification payload. In some embodiments, the system captures intermediate state data by setting probe hooks within the verification execution engine, triggering hooks to collect information, summarizing related information, and writing to a buffer. The probe hooks are implanted into the key logic judgment points of each verification stage. When the execution flow passes through a key logic judgment point, the corresponding probe hook is triggered and the local variable values, logic judgment results, and stack snapshot information at that time are collected. The system summarizes and correlates the information collected from different probe hooks in chronological order and adds timestamps and stage identifiers to form a structured intermediate state data stream. The system continuously writes the intermediate state data stream to a circular buffer for real-time reading during the process of determining whether the identity verification is successful.

[0093] The specific execution process of the verification logic in the verification phase can be described as a state transition function. In practical implementation, the function is formally represented as follows:

[0094]

[0095] in: Represents the state transition function. This represents the system state vector before the verification process begins. This represents the set of conditions that need to be satisfied in the verification logic. This represents n intermediate state vectors generated sequentially during the execution process, each intermediate state vector... It contains fragments of verification progress, data matching status, and abnormal event information at time i. These intermediate state vectors are the basic elements that constitute the intermediate state data stream.

[0096] The verification execution engine is a software module that interprets and executes a directed graph of derived verification strategies. Unique identifiers strictly correspond to the identifiers of vertices in the directed graph, and vertex location is accomplished by searching for matching identifiers in the strategy graph. The implementation of the verification logic includes parsing the format of the fused verification elements, extracting dynamic verification factors and baseline verification element components, and performing specific operations such as comparison or decryption. Edge conditions define the logical prerequisites for jumping from one verification stage vertex to the next, such as "match successful" or "match failed and the number of retries has not exceeded the limit." Probe hooks are data collection points pre-embedded in key locations in the verification execution engine code. Local variable values ​​reflect internal data snapshots when the verification logic executes to a specific point. Logical judgment results record the direction of conditional branches, stack snapshot information records function call relationships, timestamps and stage identifiers are used to chain discretely collected information fragments into a data stream with temporal and logical connections, and a circular buffer is a fixed-size memory area that stores intermediate state data streams in a first-in-first-out manner for consumption by subsequent judgment processes. Refer to Table 1; the intermediate state data structure example illustrates the composition of a typical entry in the data stream.

[0097] Table 1: Intermediate State Data Structure Table

[0098] field name Data types describe timestamp 64-bit integer The system's high-precision timestamp at the moment of information collection vertex_id String The unique identifier of the vertex in the current verification process. hook_point String Probe hook position marker that triggers data acquisition local_vars_snapshot Binary large objects Serialized values ​​of key local variables at the time of acquisition judgment_result Boolean value Output result (true / false) of key logical judgment points call_stack_frame string array Current function call stack summary information event_flag Integer Enumeration Identify whether an abnormal event has occurred and the type of event.

[0099] Optionally, during the verification execution engine's parsing phase, an ASN.1 decoder or a custom binary unpacker is used to extract encapsulated fields when verifying the payload. Vertex location operations utilize hash tables for fast lookups in the directed graph of the derived verification strategy. The verification logic's checking of fused verification elements may involve cryptographic operations, such as using asymmetric algorithms to verify signatures or using symmetric algorithms to decrypt data. The probe hook triggering mechanism is implemented based on code instrumentation technology; the collected information is temporarily stored in thread-local storage awaiting aggregation. The aggregation and correlation process is executed by a separate log aggregation thread, which maintains a session context for each verification session and merges and sorts data from different probe hooks within the same session. Write operations to the circular buffer are atomic; the process of determining whether authentication is successful reads data entries sequentially from the head of the buffer.

[0100] See Figure 4 This is a bar chart analyzing the frequency of probe hook data acquisition, showing the distribution of acquisition frequency of the four probe hooks in different verification stages of the hardware key authentication process. The high acquisition frequency of stages V03 and V05 directly points to their core role in computation and data interaction within the verification process, making them key targets for performance optimization. The stepwise change in hook acquisition frequency (entry → parsing → judgment → output) closely matches the execution logic of the verification stages, validating the rationality of the probe hook deployment. For low-frequency stages such as V06, reducing the number of hooks or lowering the acquisition frequency can be considered to reduce system overhead; for high-load stages such as V03, the sampling depth of the hooks needs to be increased to obtain more granular status data.

[0101] In one embodiment of the present invention, the specific operation process for determining whether authentication is successful based on intermediate state data and for auditing and tracing after generating access control decisions involves the following steps: In a specific implementation, the system reads the latest intermediate state data stream from a circular buffer and performs pattern matching on the intermediate state data stream according to predefined authentication success rule templates and authentication failure rule templates. If a sequence of events matching the authentication success rule template appears consecutively in the intermediate state data stream and no key event matching the authentication failure rule template appears, the system determines that authentication is successful; if a key event matching the authentication failure rule template appears in the intermediate state data stream or no complete sequence matching the authentication success rule template appears, the system determines that authentication has failed. The system generates access control decisions that include a summary of the judgment conclusion and the main basis. After generating the access control decisions, the system associates and binds the original device credentials, static identifier components, variable encoding components, dynamic verification factors, verification payloads at each stage, intermediate state data streams, and the final access control decisions generated throughout the authentication process. The system then standardizes and formats the complete data records after association and binding to generate tamper-proof audit traceability entries. These audit traceability entries are synchronously stored in the local audit database and the remote security log server. The system periodically performs cluster analysis on the stored audit traceability entries to update the tree structure of the registered device directory and optimize the basic policy template for derived verification strategies.

[0102] In some embodiments, the pattern matching process is formally described by a matching function:

[0103]

[0104] in: Represents the matching function. This represents the intermediate state data stream read from the circular buffer. This represents a predefined successful verification rule template. This represents a predefined validation failure rule template. This represents the result of the matching function output, i.e., "passed," "failed," or "pending." Matching function Internal logical sequence scan of intermediate state data stream At the same time, try and verify the successful rule template. Match the defined expected event sequence and examine the intermediate state data stream. Does the verification failure rule template exist? Defined key event patterns.

[0105] As can be understood, a circular buffer is a fixed-capacity storage area for intermediate state data streams, following a first-in, first-out (FIFO) read / write rule. The successful authentication rule template defines multiple key states or events that must occur sequentially for successful authentication and their logical relationships. The failed authentication rule template defines any specific abnormal event or error state pattern that would cause authentication to fail immediately. The pattern matching process is a streaming process; the system continuously consumes the intermediate state data stream and updates the matching status in real time. The judgment conclusion is the final decision, primarily based on the digest extracted from the intermediate state data stream containing specific event identifiers that successfully match the rule template or descriptions of key events that failed to match. The association and binding process generates a globally unique session identifier for all relevant data in this verification session. Standardized formatting processes include data serialization, timestamp alignment, and digital signatures. Generating tamper-proof audit traceability entries relies on calculating cryptographic hash values ​​for the entry content and storing the hash values. Synchronous storage operations ensure that audit data has copies both locally and remotely to improve reliability and non-repudiation. Periodic cluster analysis performs data mining on historical audit traceability entries to identify device access patterns, policy execution effects, and potential risk characteristics. The analysis results are used to guide the adjustment of nodes in the registered device directory tree structure and the optimization of the verification logic and parameters of the basic policy template.

[0106] Optional, matching function This can be implemented using a state machine model, verifying the successful rule template. And verification failure rule template Defined using a declarative rule language or finite automata. When generating access control decisions, the system includes a concise text summary in addition to a Boolean pass / fail conclusion, listing the last event that triggered the success rule sequence or the failure rule matching event that caused the failure. Association binding operations are completed within a single transaction, ensuring the integrity of the bound records. Standardized formatting uses serialization formats such as JSON or Protocol Buffers, and applies a private key-based digital signature to the serialized data to generate tamper-proof audit traceability entries. The local audit database uses a relational database with transaction support, and a remote security log server receives audit traceability entries through a secure, authenticated log transmission protocol. Periodic clustering analysis tasks are scheduled and executed in the background. Analysis algorithms can include access frequency clustering based on device static identifier components or pattern classification based on verification process execution results. Conclusions such as "a certain type of device frequently fails at a specific stage" can be translated into suggestions for modifying the basic policy template, such as dynamically adding an auxiliary verification stage for this type of device.

[0107] See Figure 5 This is a comparison chart of the entire hardware key authentication process, clearly showing the status changes of successful and failed authentication processes, as well as the dynamic improvement of the system's security level. It clearly identifies "static identifier comparison" as the main risk point for authentication failure, providing a precise direction for security hardening. The stability of the successful process and the upward trend in security level verify the effectiveness and security of this high-strength authentication scheme. Consider adding a retry mechanism or introducing a more flexible exception handling strategy to the "static identifier comparison" stage to reduce the failure rate and improve user experience. Clearly revealing that "static identifier comparison" is the only stage that causes the authentication process to be interrupted provides the security team with a clear target for risk, allowing for priority hardening of this stage, such as adding tolerance mechanisms for device credentials or introducing multi-factor backup verification.

[0108] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A server high-strength authentication access control method based on hardware keys, characterized in that, include: Obtain the original access request initiated by the hardware key device, wherein the original access request encapsulates the native device credentials bound to the hardware key device; The native device certificate is decomposed into a certificate structure, and static identifier components and variable code components are extracted from the native device certificate; The static identifier component is compared with a preset list of registered devices, and the hardware key device is classified as a device in the list or a device to be verified based on the comparison result. When the hardware key device is a device in the list, the derived verification strategy associated with the static identifier component is activated. The derived verification strategy includes at least one additional verification step. The variable coding components are input into a pre-built coding conversion pipeline, and a dynamic check factor is generated through continuous processing of the coding conversion pipeline. By combining the dynamic verification factor with the verification elements required by the additional verification steps, a stage verification load is constructed. The stage verification payload is submitted to the server's verification execution engine, which triggers the verification execution engine to perform authentication according to the logical sequence defined by the derived verification strategy; The intermediate state data generated by the verification execution engine during the processing of the stage verification payload is captured, and the identity verification is determined based on the intermediate state data. An access control decision is generated based on the determination result.

2. The server high-strength authentication access control method based on hardware key according to claim 1, characterized in that, Deconstructing the native device credentials involves the following steps: Identify the encoding format and encapsulation boundary of the native device credential, and call the corresponding decoder to decode the native device credential according to the encoding format to obtain the plaintext credential data stream; Locate the delimiter sequence in the plaintext voucher data stream, the delimiter sequence being composed of a predefined character or byte pattern; The plaintext voucher data stream is divided into multiple voucher data segments based on the delimiter sequence; Data segments that conform to the preset static feature template are selected from the voucher data segments and classified as static identifier components; From the remaining voucher data fragments, data fragments with variable encoding lengths and random content are selected and classified as variable encoding components.

3. The server high-strength authentication access control method based on hardware key according to claim 2, characterized in that, Comparing the static identifier component with the preset list of registered devices includes the following steps: Load the registered device list, which is organized in a tree structure, with its leaf nodes storing the complete static identifier of the authorized hardware key device; The static identifier component is matched with the root node of the tree structure level by level, and each level of matching is based on a portion of the fields of the static identifier component. If a match fails at a certain level, the matching process is terminated, and the hardware key device is marked as a device to be verified. If the matching process traverses to a leaf node of the tree structure and the static identifier component is completely consistent with the complete static identifier stored in the leaf node, then the hardware key device is classified as a device in the directory, and the policy index identifier associated with the leaf node is recorded.

4. The server high-strength authentication access control method based on hardware key according to claim 3, characterized in that, Activating the derived verification strategy associated with the static identifier component includes the following steps: Retrieve the corresponding basic policy template from the policy repository based on the policy index identifier; Query the recent historical access logs of the hardware key device, and analyze the access behavior pattern characteristics from the historical access logs; The access behavior pattern features are used as input parameters and injected into the policy variable slots of the basic policy template. The strategy generation script embedded in the basic strategy template is executed. The strategy generation script dynamically combines and adjusts the verification process according to the injected access behavior pattern characteristics, and outputs the derived verification strategy. The derived verification strategy is described in the form of a directed graph, where vertices represent verification steps and edges represent the execution order and condition jump relationships between steps.

5. The server high-strength authentication access control method based on hardware key according to claim 2, characterized in that, Generating a dynamic check factor through continuous processing in the encoding conversion pipeline includes the following steps: The encoding conversion pipeline consists of multiple sequentially connected conversion units, each of which is configured with specific encoding operation rules. The variable coded component is input to the first conversion unit, which applies its encoding operation rules to perform an initial transformation on the variable coded component and outputs intermediate result one. The intermediate result one is passed to the next conversion unit, which combines the partial information of the static identifier component with the intermediate result one to perform a composite operation and output the intermediate result two. After being processed by all the conversion units in sequence, the output of the last conversion unit is defined as the primary dynamic factor; The primary dynamic factor is concatenated with the current system timestamp, and a one-way hash is calculated on the concatenated data. The resulting hash value is used as the final dynamic verification factor.

6. The server high-strength authentication access control method based on hardware key according to claim 5, characterized in that, Constructing the stage verification load includes the following steps: From the directed graph defined by the derived verification strategy, read the attributes of the verification step to be executed, the attributes including a list of verification element types required by the verification step; Based on the list of verification element types, retrieve the corresponding baseline verification element from the local secure storage; The dynamic verification factor and the benchmark verification element are fused bitwise to generate a fused verification element. The fusion verification elements, the unique identifier of the verification step, and the classification information of the hardware key device are jointly encapsulated to form a stage verification payload for the verification step.

7. The server high-strength authentication access control method based on hardware key according to claim 6, characterized in that, Triggering the verification execution engine to perform authentication according to the logical sequence defined by the derived verification strategy includes the following steps: The verification execution engine parses the received stage verification payload and extracts the unique identifier of the verification step. Based on the unique identifier, locate the corresponding vertex in the directed graph of the derived verification strategy; The specific verification logic of the verification stage represented by the vertex is executed, and the verification logic includes parsing and verifying the fused verification elements in the stage verification load; During the execution of the verification logic, information reflecting the verification progress, data matching status, and abnormal events is generated in real time. The information reflecting the verification progress, data matching status, and abnormal events together constitutes the intermediate state data. Based on the execution result of the current verification step and the edge conditions defined in the directed graph, the next verification step to be executed is determined, and the system waits for the next corresponding stage verification load.

8. The server high-strength authentication access control method based on hardware key according to claim 7, characterized in that, Capturing the intermediate state data generated by the verification execution engine during the processing of the phase verification payload includes the following steps: Probe hooks are set within the verification execution engine, and these probe hooks are implanted into the key logic judgment points of each verification step. When the execution flow passes through the key logic judgment point, the corresponding probe hook is triggered to collect the local variable values, logic judgment results and stack snapshot information at that time; Information collected from different probe hooks is summarized and correlated in chronological order, with timestamps and stage identifiers added to form a structured intermediate state data stream; The intermediate state data stream is continuously written to a circular buffer for real-time reading during the process of determining whether the authentication is successful.

9. The server high-strength authentication access control method based on hardware key according to claim 8, characterized in that, Determining whether the authentication is successful based on the intermediate state data includes the following steps: Read the latest intermediate state data stream from the circular buffer; Pattern matching is performed on the intermediate state data stream based on predefined verification success rule templates and verification failure rule templates; If a sequence of events matching the verification success rule template appears consecutively in the intermediate state data stream, and no key event matching the verification failure rule template appears, then the identity verification is deemed successful. If a key event matching the verification failure rule template appears in the intermediate state data stream, or if the complete sequence of the verification success rule template is not matched, then the authentication is determined to have failed. Generate access control decisions that include a conclusion and a summary of the main criteria.

10. The server high-strength authentication access control method based on hardware key according to claim 9, characterized in that, After generating access control decisions, the following steps are also included: The native device credentials, static identifier components, variable encoding components, dynamic verification factors, verification payloads at each stage, intermediate state data streams, and final access control decisions generated throughout the entire authentication process are associated and bound together. The complete data records after association and binding are standardized and formatted to generate tamper-proof audit traceability entries; The audit traceability entries are synchronously stored in the local audit database and the remote security log server; Periodically perform cluster analysis on the audit traceability entries to update the tree structure of the registered device directory and optimize the basic strategy template for the derived verification strategy.

Images