Server high-strength identity authentication access control method based on hardware Key

Abstract

The invention relates to the technical field of information security, in particular to a server high-strength identity authentication access control method based on a hardware Key, which comprises the following steps of: disassembling a hardware Key voucher to extract a static identification component and a variable coding component; and comparing the static identification component with the registered directory, and activating a derivative verification strategy which is associated with the equipment in the directory and comprises an additional verification link for the equipment in the directory. Meanwhile, the variable coding component is continuously processed through a special pipeline, and a dynamic check factor is generated. And combining the dynamic factor with the verification element to form a stage verification load, and executing verification by a server verification engine according to strategy logic. And generating an access control decision according to the verification intermediate state. According to the method, differentiated dynamic triggering of the verification strategy based on the device identity is realized, and the dynamic anti-counterfeiting and anti-attack capabilities of the authentication data are enhanced through deep processing of variable codes.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information security, and in particular to a high-strength identity authentication access control method for a server based on a hardware Key. BACKGROUND

[0002] Traditional server access control methods based on hardware Key mainly rely on the overall verification of static credentials such as digital certificates and fixed token codes stored in the hardware Key. The server verification process is predefined and globally unified, and all devices holding a legal hardware Key go through the same authentication steps. This method regards the hardware Key as a single and homogeneous authentication factor, and the verification decision is made directly based on the overall validity of the credentials.

[0003] The prior art has defects. The static and unified verification process cannot be adaptively adjusted according 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 verification steps for specific devices during the verification process; for the variable encoding components commonly found in hardware Key, the existing processing method is usually direct comparison, simple hashing or time synchronization calculation, and the algorithm for generating the check value is relatively fixed and transparent. The complexity and randomness of this processing method are limited, which may lead to the analysis or prediction of the check mode.

[0004] It is necessary to solve the problems of 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 encoding components to generate dynamic verification elements that are resistant to analysis and replay. SUMMARY

[0005] The purpose of the present application is to solve the problems existing in the prior art, and to provide a high-strength identity authentication access control method for a server based on a hardware Key.

[0006] In order to achieve the above purpose, the present application adopts the following technical scheme: a high-strength identity authentication access control method for a server based on a hardware Key, comprising:

[0007] Obtaining an original access request initiated by a hardware Key device, the original access request encapsulating a native device credential bound to the hardware Key device;

[0008] Decomposing the native device credential according to the credential structure, and extracting a static identification component and a variable encoding component from the native device credential;

[0009] comparing the static identification component with a preconfigured register device list, and classifying the hardware Key device as a list-in device or a to-be-checked device according to a comparison result, when the hardware Key device is a list-in device, activating a derived verification strategy associated with the static identification component, the derived verification strategy comprising at least one additional verification link;

[0010] inputting the variable encoding component into a pre-built encoding conversion pipeline, and generating a dynamic check factor through a continuous processing of the encoding conversion pipeline;

[0011] combining the dynamic check factor with a verification element required by the additional verification link, and constructing a stage verification load;

[0012] submitting the stage verification load to a verification execution engine of a server, and triggering the verification execution engine to perform identity verification according to a logic sequence defined by the derived verification strategy;

[0013] capturing intermediate state data generated by the verification execution engine in a process of processing the stage verification load, determining whether the identity verification passes according to the intermediate state data, and generating an access control decision based on a determination result.

[0014] Preferably, the credential structure disassembly of the native device credential comprises the following steps:

[0015] identifying an encoding format and an encapsulation boundary of the native device credential, decoding the native device credential according to the encoding format to obtain a clear-text credential data stream;

[0016] locating a delimiter sequence in the clear-text credential data stream, the delimiter sequence being composed of a pre-defined character or byte pattern;

[0017] cutting the clear-text credential data stream into multiple credential data segments based on the delimiter sequence;

[0018] screening a data segment conforming to a pre-set static feature template from the credential data segments, and classifying the data segment as a static identification component;

[0019] screening a data segment with a variable encoding length and a content conforming to a random feature from the remaining credential data segments, and classifying the data segment as a variable encoding component.

[0020] Preferably, the comparison of the static identification component with the preconfigured register device list comprises the following steps:

[0021] loading the register device list, the register device list being organized in a tree structure, and a leaf node of the register device list storing a complete static identification of an authorized hardware Key device;

[0022] The static identification component is matched with the root node of the tree structure, and each level of matching is based on a part of the fields of the static identification component;

[0023] If the matching fails at a certain level, the matching process is terminated, and the hardware Key device is marked as a device to be checked;

[0024] If the matching process reaches a certain leaf node of the tree structure, and the static identification component is completely consistent with the complete static identification stored in the leaf node, the hardware Key device is classified as an in-list device, and the policy index identification associated with the leaf node is recorded.

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

[0026] Retrieving the corresponding base policy template from the policy storage according to the policy index identification;

[0027] Querying the recent history access log of the hardware Key device, and analyzing the access behavior pattern features from the history access log;

[0028] Injecting the access behavior pattern features as input parameters into the policy variable slot of the base policy template;

[0029] Executing the policy generation script embedded in the base policy template, which dynamically combines and adjusts the verification links according to the injected access behavior pattern features, and outputs the derived verification policy;

[0030] The derived verification policy is described in the form of a directed graph, where the vertices represent verification links, and the edges represent the execution order and conditional jump relationship between links.

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

[0032] The encoding conversion pipeline is composed of multiple sequentially connected conversion units, each of which is configured with a specific encoding operation rule;

[0033] The variable encoding component is input into the first conversion unit, which applies its encoding operation rule to the variable encoding component for the first transformation, and outputs intermediate result one;

[0034] The intermediate result one is passed to the next conversion unit, which combines part of the information of the static identification component and the intermediate result one for complex operation, and outputs intermediate result two;

[0035] The result outputted by the last conversion unit is defined as a primary dynamic factor after the processing of all the conversion units in sequence;

[0036] The primary dynamic factor is spliced with a current system timestamp, and a one-way hash calculation is performed on the spliced overall data, and the obtained hash value is taken as a final dynamic check factor.

[0037] Preferably, the construction of the stage verification payload comprises the following steps:

[0038] From the directed graph defined by the derived verification strategy, the attributes of the current verification link to be executed are read, and the attributes include a verification element type list required by the verification link;

[0039] According to the verification element type list, the corresponding reference verification element is retrieved from the local security storage;

[0040] The dynamic check factor and the reference verification element are subjected to a bitwise fusion operation to generate a fusion verification element;

[0041] The fusion verification element, the unique identifier of the verification link, and the classification information of the hardware Key device are collectively encapsulated to form a stage verification payload for the verification link.

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

[0043] The verification execution engine parses the received stage verification payload to extract the unique identifier of the verification link;

[0044] According to the unique identifier, the corresponding vertex is located in the directed graph of the derived verification strategy;

[0045] The specific verification logic of the verification link represented by the vertex is executed, and the verification logic includes parsing and checking the fusion verification element in the stage verification payload;

[0046] During the execution of the verification logic, information reflecting the verification progress, data matching state and abnormal events is generated in real time, and the information reflecting the verification progress, data matching state and abnormal events collectively constitute the intermediate state data;

[0047] According to the execution result of the current verification link and the edge condition defined in the directed graph, the next verification link to be executed is determined, and the next corresponding stage verification payload is waited.

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

[0049] setting a probe hook in the verification execution engine, the probe hook being implanted into a key logical judgment point of each verification link;

[0050] when the execution flow passes through the key logical judgment point, triggering the corresponding probe hook, collecting the local variable value, logical judgment result and stack snapshot information at that time;

[0051] summarizing and correlating the information collected from different probe hooks in chronological order, adding time stamps and link identifiers, forming a structured intermediate state data stream;

[0052] continuously writing the intermediate state data stream into a circular buffer for real-time reading by the process of determining whether the identity verification is passed.

[0053] Preferably, determining whether the identity verification is passed according to the intermediate state data includes the following steps:

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

[0055] performing pattern matching on the intermediate state data stream according to predefined verification success rule templates and verification failure rule templates;

[0056] if a sequence of events in the intermediate state data stream continuously appears that matches the verification success rule template and no key event that matches the verification failure rule template appears, it is determined that the identity verification is passed;

[0057] if a key event in the intermediate state data stream appears that matches the verification failure rule template, or a complete sequence that matches the verification success rule template cannot be matched, it is determined that the identity verification fails;

[0058] generating an access control decision containing the determination conclusion and a summary of the main basis.

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

[0060] associating and binding the native device credential, static identification component, variable encoding component, dynamic verification factor, verification load at each stage, intermediate state data stream and final access control decision generated during the entire identity verification process;

[0061] standardizing and formatting the complete data record after association and binding to generate an unalterable audit trace entry;

[0062] storing the audit trace entry synchronously to a local audit database and a remote security log server;

[0063] Periodically cluster analysis is performed on the audit trail entries to update the tree structure of the registered device roster and to optimize the base policy template of the derived authentication strategy.

[0064] Compared with the prior art, the application has the advantages and positive effects that:

[0065] By extracting the static identification component in the hardware Key native credential, the initial verification stage is compared and classified with the pre-registered device roster, and the derived authentication strategy pre-associated with the static identification component is activated according to the device classification result. At least one additional verification link and its execution logic sequence are defined in the strategy. This makes the verification process change from a fixed mode to a programmable, dynamic mode bound to the device identity. The system can implant verification challenges of different complexity and types for different devices or access scenarios according to the policy configuration. The strength of access control can be fine-tuned at the initial stage of session establishment, rather than implementing equal strength checks for all legal devices. The system's ability to dynamically build verification paths based on device identity attributes is enhanced, improving the flexibility of the strategy to deal with risks such as credential spoofing.

[0066] An independent encoding conversion pipeline is constructed, and a series of continuous, nonlinear processing operations are performed on the variable encoding component to finally generate a dynamic check factor. This process replaces direct comparison or simple encryption processing of the variable encoding. The generation logic of the dynamic check factor is built into the pipeline, and the mapping relationship between the original encoding and the factor is complex and hidden. The factor is combined with the additional verification elements to form a unique stage verification payload for each request. Due to the dynamicity and unpredictability of the payload core elements, it is difficult for attackers to fake valid authentication requests through eavesdropping or analyzing historical data. This increases the difficulty of replay attacks and man-in-the-middle attacks, and strengthens the data security of the authentication process itself. BRIEF DESCRIPTION OF DRAWINGS

[0067] Figure 1 Flowchart of the hardware Key-based server high-strength identity authentication access control method described in the application;

[0068] Figure 2 Flowchart for activating the derived authentication strategy associated with the static identification component;

[0069] Figure 3 Unique dynamic factor comparison bar chart under different encoding conversion rules;

[0070] Figure 4 Probe hook data collection frequency analysis bar chart;

[0071] Figure 5 Full-process state comparison chart for hardware Key identity authentication. DETAILED DESCRIPTION

[0072] In order to make the objects, technical solutions and advantages of the present application clearer, the following further describes the present application with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not intended to limit the present application.

[0073] In the description of the present application, it should be understood that the terms "length", "width", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer" and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only used to facilitate the description of the present application and simplify the description, and therefore cannot be understood as indicating or implying that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as limiting the present application. In addition, in the description of the present application, the meaning of "a plurality of" is two or more, unless otherwise explicitly and specifically limited.

[0074] Referring to Figure 1 The method starts with receiving an original access request initiated by a hardware Key device, which internally encapsulates a native device credential bound to the hardware Key device. The system then performs a credential structure disassembly operation on the native device credential to separate and extract a static identification component and a variable encoding component from the credential. The extracted static identification component is sent to a pre-established register device directory for comparison, and the hardware Key device is distinguished as a directory-in device or a to-be-checked device according to the comparison result. When the hardware Key device is confirmed as a directory-in device, the system will activate a derived verification strategy pre-associated with the static identification component, which defines a logical sequence containing at least one additional verification link. At the same time, the system inputs the variable encoding component into a pre-constructed encoding conversion pipeline, which generates a dynamic check factor through a series of continuous conversion processes. The system combines the dynamic check factor with the verification element required by the additional verification link currently to be executed to construct a stage verification payload. The stage verification payload is submitted to the verification execution engine of the server, which triggers and executes the specific identity verification process according to the logical sequence defined by the derived verification strategy. In the process of the verification execution engine processing the stage verification payload, the system captures the intermediate state data generated by the engine, and determines whether the identity verification is passed according to the intermediate state data, and finally generates a corresponding access control decision based on the determination result.

[0075] In an embodiment of the present application, the system performs credential structure disassembly including steps of identifying encoding format and packaging boundary of native device credential, invoking corresponding decoder for decoding, locating separator sequence, cutting plaintext credential data stream, and screening data segments, etc. The system identifies encoding format and packaging boundary of native device credential, and invokes corresponding decoder for decoding operation according to the identified encoding format, so as to obtain plaintext credential data stream. In some embodiments, the system locates separator sequence composed of pre-defined character or byte pattern in the plaintext credential data stream, cuts the plaintext credential data stream into multiple credential data segments based on the located separator sequence, screens data segments conforming to pre-set static feature template from the cut credential data segments, classifies them as static identification components, and screens data segments with variable encoding length and content conforming to random features from the remaining credential data segments, classifies them as variable encoding components. In a specific implementation, the pre-set static feature template defines format specification and content features of the static identification components, and the system uses a matching function to evaluate the degree of conformity of each credential data segment to the pre-set static feature template, and the formalized representation of the matching function is:

[0076]

[0077] wherein: represents the credential data segment, represents the pre-set static feature template, represents a logical condition for judging whether the credential data segment conforms to the pre-set static feature template according to pre-defined rules, and when the return value is true, the credential data segment is classified as a static identification component.

[0078] It can be understood that the encoding format identification process involves parsing the header information or metadata of the native device credential, the decoder converts according to the encoding format such as Base64, hexadecimal or custom binary format, the separator sequence is pre-defined by the system and may include specific character combinations or byte patterns, such as two consecutive colons or a specific byte value sequence. The cutting operation divides the plaintext credential data stream into discrete credential data segments according to the position of the separator sequence, and the process of screening static identification components relies on the matching rules of the pre-set static feature template, which may include fixed length, specific character set or checksum verification. The process of screening variable encoding components focuses on the variability of encoding length and the random features of content presentation, such as judging the randomness degree of data segments by entropy value calculation.

[0079] Optionally, the system employs a sliding window algorithm to scan the plaintext credential data stream for locating the delimiter sequence, until a sequence fully matching the predefined pattern is found, and the credential data segment is cut out to generate a segment list for subsequent screening process. The matching function The logic condition in the matching function may be implemented as pattern matching, regular expression checking or field alignment checking. The system iterates through the segment list, applies the matching function to each credential data segment, and classifies the segments with true result into the static identity component set, and further classifies the remaining segments into the variable encoding component set according to length variation range and randomness test.

[0080] In one embodiment of the present application, referring to Figure 2 , the specific operation process of comparing the static identity component with the preset registered device directory and activating the derived verification policy associated with the static identity component. In specific implementation, the system loads the registered device directory organized in tree structure, and the leaf nodes of the registered device directory store the complete static identity of the authorized hardware Key device. The system starts matching the static identity component from the root node of the tree structure, and each level of matching is based on the partial fields of the static identity component. If the matching fails at a certain level, the system terminates the matching process and marks the hardware Key device as a device to be checked. If the matching process successfully traverses to a certain leaf node of the tree structure, and the static identity component is fully consistent with the complete static identity stored in the leaf node, the system classifies the hardware Key device as a directory-in device, and records the policy index identification associated with the leaf node.

[0081] In some embodiments, the system retrieves the corresponding base policy template from the policy storage according to the policy index identification, queries the recent history access log of the hardware Key device and analyzes the access behavior pattern features from the history access log. The access behavior pattern features are injected as input parameters into the policy variable slots of the base policy template. The system executes the policy generation script embedded in the base policy template, and the policy generation script dynamically combines and adjusts the verification links according to the injected access behavior pattern features, and outputs the derived verification policy described in the form of directed graph, where the vertices represent the verification links, and the edges represent the execution order and conditional jump relationship between the links. In specific implementation, the access behavior pattern feature analysis involves quantitative extraction and pattern recognition of the fields such as timestamp, access frequency, operation sequence and resource request pattern in the history access log. The system calculates the feature vector from the history access log within a time window , where is the feature extraction function, represents the history access log dataset, ​representing a set analysis time window, representing a calculated multi-dimensional feature vector, which is injected into the policy variable slot of the base policy template.

[0082] It can be understood that each level of the tree structure corresponds to a certain field of the static identification component, for example, the root node represents the equipment manufacturer code, the child node represents the equipment model sequence, and the leaf node represents the unique equipment serial number. The matching process is recursively performed field by field. The policy repository is a database storing a plurality of base policy templates, each of which is bound to a unique policy index identifier. The policy variable slot is a predefined position marker in the base policy template for receiving external input parameters. The policy generation script is executable code logic embedded in the base policy template, which is responsible for generating a final derived verification policy directed graph according to the input parameters. The vertices in the derived verification policy directed graph contain the specific logic definition of the verification link, and the edges define the transition conditions between the vertices.

[0083] Optionally, when the system matches level by level, the static identification component is segmented according to the predefined field length and order. Starting from the root node, the current field is used to query the child node list of the current node. If a matching child node is found, the next level of matching is entered, otherwise the matching fails. The specific implementation of the feature extraction function may include calculating the statistical value of the access frequency, identifying the access time distribution rule, or constructing a Markov chain model of the operation sequence. When the system executes the policy generation script, the script logic reads the injected feature vector , and determines which verification links to enable, sets the jump condition threshold between the links, and adjusts the verification parameters based on the values in , thereby instantiating the directed graph. For example, when the value of the "irregular time access flag" in the feature vector is high, the policy generation script may add a biometric feature review vertex to the directed graph, and set the edge condition from the previous vertex to the newly added vertex as "when the flag value exceeds threshold K".

[0084] In one embodiment of the present application, the specific operation process of generating the dynamic check factor and constructing the stage verification payload is generated by the continuous processing of the encoding conversion pipeline. In a specific implementation, the system performs the steps of generating the dynamic check factor, including configuring the encoding conversion pipeline, sequentially processing the variable encoding component, combining the static identification component information, generating the preliminary dynamic factor, and performing the hash calculation, etc. The encoding conversion pipeline is composed of multiple sequentially connected conversion units, each of which is configured with an encoding operation rule. The system inputs the variable encoding component into the first conversion unit, and the first conversion unit applies the encoding operation rule to the variable encoding component for the first time to output the intermediate result one. The intermediate result one is passed to the next conversion unit, and the next conversion unit performs a composite operation on the intermediate result one combined with part of the information of the static identification component and outputs the intermediate result two. The system sequentially passes through the processing of all conversion units and defines the result output by the last conversion unit as the preliminary dynamic factor. The system splices the preliminary dynamic factor with the current system timestamp and performs a one-way hash calculation on the spliced overall data. The obtained hash value is used as the final dynamic check factor.

[0085] In some embodiments, the system constructs the stage verification payload including the steps of reading the verification link attribute, retrieving the reference verification element, performing the bitwise fusion operation, and packaging the payload, etc. The system reads the attribute of the current verification link to be executed from the directed graph defined by the derived verification strategy. The attribute of the verification link includes the list of verification element types required by the verification link. The system retrieves the corresponding reference verification element from the local secure storage according to the list of verification element types. The dynamic check factor and the reference verification element are fused by the bitwise fusion operation to generate the fusion verification element. The system encapsulates the fusion verification element, the unique identifier of the verification link, and the classification information of the hardware Key device together to form the stage verification payload for the verification link. In a specific implementation, the bitwise fusion operation follows the fusion function, and the formal representation of the fusion function is:

[0086]

[0087] Wherein: represents the fusion function, represents the dynamic check factor, represents the reference verification element, represents the bitwise XOR operation, represents the cyclic left shift operation, represents the bit shift constant derived from the unique identifier of the verification link, and the output result of the fusion function is the fusion verification element.

[0088] It can be understood that each conversion unit in the encoding conversion pipeline performs mathematical transformation or encoding operation, and the composite operation introduces part of the information of the static identification component to enhance the binding relationship between the dynamic check factor and the hardware Key device. The one-way hash calculation uses a cryptographic hash function such as SHA-256, and the hash function processes the spliced data to generate a fixed-length dynamic check factor. The verification element type list explicitly specifies the data format and identification of the reference verification element, and the local secure storage protects the confidentiality of the reference verification element through an access control mechanism. The bitwise fusion operation combines the dynamic check factor and the reference verification element to generate a temporary fusion verification element, and the fusion verification element is only used for the current verification link. The packaging process serializes the fusion verification element, the unique identifier of the verification link, and the classification information of the hardware Key device into a structured data packet, which contains necessary header information and payload.

[0089] Optionally, the encoding operation rule includes a linear feedback shift register operation or an S-box substitution, and the composite operation performs a modulo addition operation on the specified byte segment of the static identification component and the intermediate result at a specific conversion unit. The system timestamp is obtained from a high-precision clock source, and the timestamp data is converted into a standard format before splicing. The bit shift constant The CRC checksum of the verification link unique identifier is calculated and taken modulo operation to obtain the left cyclic shift operation The number of bits is determined by the bit shift constant The packaging of the stage verification payload adopts the TLV format, each field contains type, length and value, and the classification information of the hardware Key device indicates whether the device is in the directory or to be checked.

[0090] Optionally, the system retrieves the reference verification element from the local secure storage according to the type identifier in the verification element type list, and the reference verification element is stored in encrypted form and decrypted in memory for use. The fusion function Ensures sufficient mixing of the dynamic check factor And the reference verification element The fusion verification element is cleared from the memory after the verification link ends. The stage verification payload is attached with a message authentication code before being submitted to the verification execution engine, and the message authentication code is calculated and generated based on the shared key and the payload content.

[0091] Referring to Figure 3This is a unique dynamic factor comparison column chart under different encoding conversion rules, which intuitively shows the uniqueness of the dynamic check factor under five encoding conversion rules, namely LFSR, S-box substitution, modulo addition operation, bit rearrangement and mixed rule, in different sample sizes. The uniqueness of all rules decreases slightly with the increase of sample size, but the decline of "mixed rule" is the smallest, while the decline of "LFSR rule" is the largest. This trend verifies the stability difference of the algorithm under different scales. The chart provides a quantitative basis for algorithm selection of the encoding conversion pipeline, and clearly shows the advantage of "mixed rule", which can directly guide system optimization. By comparing the performance of different rules under large samples, engineers can find the optimal balance point between algorithm complexity, performance overhead and security strength. The data show that the mixed use of multiple algorithms can effectively improve the anti-collision ability of the dynamic check factor, which is crucial to ensure the security of hardware Key authentication.

[0092] In one embodiment of the present application, the trigger verification execution engine performs identity verification according to the logical sequence defined in the derived verification strategy, and captures the intermediate state data generated by the verification execution engine during the processing phase of the verification payload. In specific implementation, the verification execution engine parses the received stage verification payload and extracts the unique identifier of the verification link, locates the corresponding vertex in the directed graph of the derived verification strategy according to the extracted unique identifier, and executes the specific verification logic of the verification link represented by the vertex. The verification logic includes parsing and checking the fusion verification elements in the stage verification payload. During the execution of the verification logic, information reflecting the verification progress, data matching state and abnormal events is generated in real time. These information collectively constitute the intermediate state data. According to the execution result of the current verification link and the edge condition defined in the directed graph, the next verification link to be executed is determined, and the system waits for the next corresponding stage verification payload. In some embodiments, the system captures the intermediate state data by setting probe hooks in the verification execution engine, triggering the hook to collect information, summarizing associated information, and writing to the buffer. The probe hook is implanted into the key logic judgment point of each verification link. When the execution flow passes through the key logic judgment point, the corresponding probe hook is triggered and the local variable value, logic judgment result and stack snapshot information at that time are collected. The system summarizes and associates the information collected from different probe hooks in chronological order and adds time stamp and link identification to form structured intermediate state data stream. The system continuously writes the intermediate state data stream to the circular buffer for real-time reading by the process of determining whether the identity verification is passed.

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

[0094]

[0095] wherein: represents a state transition function, represents a system state vector before the execution of a verification phase, represents a set of conditions that need to be satisfied in the verification logic, represents n intermediate state vectors generated in sequence during the execution process, each intermediate state vector contains the verification progress, data matching status and exception event information at time i, these intermediate state vectors are the basic elements of the intermediate state data stream.

[0096] It can be understood that the verification execution engine is a software module that interprets and executes the directed graph of the derived verification strategy, the unique identifier strictly corresponds to the identifier of the vertex in the directed graph, and the positioning of the vertex is completed by searching for the matching identifier in the strategy graph. The implementation of the verification logic includes parsing the format of the fused verification element, extracting the dynamic check factor and the reference verification element component, performing comparison or decryption, etc. The edge condition defines the logical premise for jumping from one verification phase vertex to the next vertex, such as “match success” or “match failure and retry count not exceeded”. The probe hook is a data collection point pre-implanted in the key position of the verification execution engine code, the local variable value reflects the internal data snapshot when the verification logic executes to a certain point, the logic judgment result records the direction of the condition branch, the stack snapshot information records the function call relationship, the timestamp and the phase identifier are used to concatenate the discrete information fragments into a data stream with time sequence and logical association, and the circular buffer is a fixed-size memory area that stores the intermediate state data stream in a first-in, first-out manner for subsequent judgment process consumption. Referring to Table 1, the intermediate state data structure example shows the composition of a typical entry in the data stream.

[0097] Table 1: Intermediate state data structure table

[0098] Field Name Data Type Description timestamp 64-bit integer System high-precision timestamp of the time when the information is collected vertex_id String Unique identifier of the current executing verification link vertex hook_point String Identification of the probe hook position that triggers the collection local_vars_snapshot Binary Large Object Serialized value of the key local variables at the time of collection judgment_result Boolean Output result (true / false) of the key logic judgment point call_stack_frame String array Current function call stack summary information event_flag Integer enumeration Identify whether an abnormal event occurs and the event type

[0099] Optionally, the verification execution engine uses an ASN.1 decoder or a custom binary unpacker to extract the encapsulated fields when parsing the phase verification payload, and the positioning vertex operation uses a hash table for fast lookup in the derived verification strategy directed graph. The verification logic may involve cryptographic operations, such as verifying a signature using an asymmetric algorithm or decrypting data using a symmetric algorithm. The triggering mechanism of the probe hook is based on code instrumentation technology, and the collected information is temporarily stored in the thread local storage for aggregation. The aggregation association process is performed by a separate log aggregation thread, which maintains a session context for each verification session and merges and sorts the data from different probe hooks of the same session. The write operation of the circular buffer is atomic, and the process of determining whether the authentication is passed reads the data entries from the head of the buffer in order.

[0100] Referring to Figure 4 This is a probe hook data collection frequency analysis histogram, which shows the distribution of the collection frequency of the four probe hooks in different verification links in the hardware Key identity authentication process. The high collection frequency of V03 and V05 links directly points to the fact that they are the core of calculation and data interaction in the verification process and can be used as the focus of performance optimization. The stepwise change of hook collection frequency (entry→analysis→judgment→output) is highly consistent with the execution logic of the verification link, which verifies the rationality of the deployment of the probe hook. For low-frequency links such as V06, the number of hooks can be reduced or the collection frequency can be reduced to reduce system overhead; for high-load links such as V03, the sampling depth of the hook needs to be increased to obtain more fine-grained state data.

[0101] In an embodiment of the present application, the specific operation process of determining whether the identity authentication is passed according to the intermediate state data and performing audit trace after generating the access control decision, in the specific implementation, the system reads the latest intermediate state data stream from the circular buffer, and performs pattern matching on the intermediate state data stream according to the predefined verification success rule template and the verification failure rule template. If a sequence of events matching the verification success rule template appears continuously in the intermediate state data stream and no key event matching the verification failure rule template appears, the system determines that the identity authentication is passed; if a key event matching the verification failure rule template appears in the intermediate state data stream or a complete sequence that fails to match the verification success rule template appears, the system determines that the identity authentication fails. The system generates an access control decision containing a determination conclusion and a main basis summary, and after generating the access control decision, the system associates and binds the native device credential, the static identification component, the variable encoding component, the dynamic check factor, the verification load of each stage, the intermediate state data stream, and the final access control decision generated in the whole process of this identity authentication. The system performs standardized formatting processing on the complete data record after association and binding to generate an unforgeable audit trace entry, synchronously stores the audit trace entry to the local audit database and the remote security log server, and periodically performs clustering analysis on the stored audit trace entries to update the tree structure of the registered device directory and optimize the basic strategy template of the derived verification strategy.

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

[0103]

[0104] Wherein: represents the matching function, represents the intermediate state data stream read from the circular buffer, represents the predefined verification success rule template, representing a predefined verification success rule template, representing the decision result of the matching function output, i.e. "pass", "fail" or "pending". The matching function scans the intermediate state data stream in an internal logic order while trying to match against the verification success rule template defined expected sequence of events, and checks the intermediate state data stream for the presence of the verification failure rule template defined critical event pattern.

[0105] It can be understood that the circular buffer is a fixed capacity storage area for storing the intermediate state data stream, following the first-in-first-out read-write rule. The verification success rule template defines multiple critical states or events that must appear in sequence for the identity verification to pass, and their logical relationship. The verification failure rule template defines a specific abnormal event or error state pattern that will cause the identity verification to fail immediately. The pattern matching process is a streaming process, the system continuously consumes the intermediate state data stream and updates the matching state in real time, and the decision conclusion is the final ruling result, mainly based on the abstract extraction from the specific event identifier matched successfully or the critical event description failed to match in the intermediate state data stream. The association binding process generates a globally unique session identifier for all related data of this verification session, and the standardized formatting process includes data serialization, timestamp alignment and digital signature, generating an unforgeable audit trail entry. The calculation of the cryptographic hash value of the entry content and the storage of the hash value together ensure the reliability and anti-repudiation of the audit data, and the synchronous storage operation ensures that the audit data has a copy on the local and remote to improve the reliability and anti-repudiation. Regular clustering analysis is used to mine historical audit trail entries to identify device access patterns, policy execution effectiveness and potential risk characteristics, and the analysis results are used to guide the adjustment of the node of the registered device directory tree structure and the optimization of the verification logic and parameters of the basic policy template.

[0106] Optionally, the implementation of the matching function can adopt a state machine model, the verification success rule template and the verification failure rule template The system generates a concise text summary in addition to the Boolean pass / fail conclusion when making access control decisions, listing the last event that triggered the sequence of successful rules or the failed rule matching event that led to failure. The association binding operation is completed within a transaction, ensuring the integrity of the bound records. The standardized formatting process uses a serialization format such as JSON or ProtocolBuffers, and applies a private key-based digital signature on the serialized data to generate tamper-proof audit trail entries. The local audit database uses a relational database with transaction support, and the remote secure log server receives audit trail entries through a secure, authenticated log transfer protocol. Periodic clustering analysis tasks are executed by the background scheduler, and the analysis algorithms can include access frequency clustering based on device static identification components or pattern classification based on the results of the verification steps. The conclusions of the analysis, such as "a certain type of device frequently fails at a specific step," can be converted into modification suggestions for the underlying policy templates, such as dynamically adding an auxiliary verification step for this type of device.

[0107] Referring to Figure 5 This is a hardware Key identity authentication full-process state comparison chart, which clearly shows the state changes of the success and failure verification processes, as well as the dynamic improvement process of the system security level. It is clear that "static identification comparison" is the main risk point of verification failure, providing a precise direction for security reinforcement. The stability of the success process and the upward trend of the security level verify the effectiveness and security of the high-strength identity verification scheme. It is possible to consider adding a retry mechanism in the "static identification comparison" step, or introducing a more flexible exception handling strategy, to reduce the failure rate and improve user experience. It is clear that "static identification comparison" is the only stage that causes the verification process to be interrupted, providing a clear risk target for the security team, which can prioritize reinforcement of this step, such as increasing the tolerance mechanism of device credentials or introducing multi-factor backup verification.

[0108] The above is only a preferred embodiment of the present application, and is not intended to limit the form of the present application in other forms. Any skilled person in the art can use the above disclosed technical content to make changes or modifications to equivalent embodiments applied to other fields, but any simple modification, equivalent change and modification made in accordance with the technical essence of the present application to the above embodiments, without departing from the technical solution content of the present application, still belongs to the protection scope of the present application technical solution.

Claims

1. A method for server high strength authentication access control based on hardware Key, characterized in that, Comprising: obtaining a raw access request initiated by a hardware Key device, the raw access request encapsulating a native device credential bound to the hardware Key device; performing a credential structure disassembly on the native device credential to extract a static identification component and a variable encoding component from the native device credential; comparing the static identification component with a pre-configured registered device roster, and classifying the hardware Key device as a rostered device or a pending verification device according to the comparison result, activating a derived verification policy associated with the static identification component when the hardware Key device is a rostered device, the derived verification policy comprising at least one additional verification step; inputting the variable encoding component into a pre-built encoding conversion pipeline to generate a dynamic check factor through successive processing of the encoding conversion pipeline; combining the dynamic check factor with verification elements required by the additional verification step to construct a stage verification payload; submitting the stage verification payload to a verification execution engine of a server to trigger the verification execution engine to perform identity verification according to a logical sequence defined by the derived verification policy; capturing intermediate state data generated by the verification execution engine in processing the stage verification payload, determining whether the identity verification is passed according to the intermediate state data, and generating an access control decision based on the determination result.

2. The hardware Key based server high strength authentication access control method of claim 1, wherein, The credential structure disassembly on the native device credential comprises the following steps: identifying an encoding format and an encapsulation boundary of the native device credential, decoding the native device credential according to the encoding format to obtain a clear-text credential data stream; locating a delimiter sequence in the clear-text credential data stream, the delimiter sequence being composed of a predefined character or byte pattern; cutting the clear-text credential data stream into multiple credential data segments based on the delimiter sequence; screening data segments that conform to a pre-set static feature template from the credential data segments, and classifying them as static identification components; screening data segments that have variable encoding length and content conforming to random features from the remaining credential data segments, and classifying them as variable encoding components.

3. The hardware Key based server high strength authentication access control method of claim 2, wherein, The comparison of the static identification component with the pre-configured registered device roster comprises the following steps: loading the registered device roster, the registered device roster being organized in a tree structure, and leaf nodes of the tree structure storing complete static identifications of authorized hardware Key devices; starting a level-by-level matching of the static identification component with root nodes of the tree structure, each level of matching being based on partial fields of the static identification component; terminating the matching process and marking the hardware Key device as a pending verification device if a level of matching fails; classifying the hardware Key device as a rostered device and recording a policy index identification associated with a leaf node of the tree structure if the matching process traverses to the leaf node and the static identification component is identical to the complete static identification stored in the leaf node.

4. The hardware Key based server high strength authentication access control method of claim 3, wherein, The activation of the derived verification policy associated with the static identification component comprises the following steps: retrieving a corresponding base policy template from a policy storage according to the policy index identification; querying a recent history access log of the hardware Key device, and analyzing an access behavior pattern feature from the history access log; injecting the access behavior pattern feature as an input parameter into a policy variable slot of the basic policy template; executing a policy generation script embedded in the basic policy template, and outputting the derived verification policy according to the access behavior pattern feature injected into the policy generation script; the derived verification policy is described in a directed graph form, wherein a vertex represents a verification link, and an edge represents an execution order and a conditional jump relationship between links.

5. The hardware Key based server high strength authentication access control method of claim 2, wherein, generating a dynamic check factor through continuous processing of the encoding conversion pipeline includes the following steps: the encoding conversion pipeline is composed of a plurality of sequentially connected conversion units, and each conversion unit is configured with a specific encoding operation rule; input the variable encoding component into the first conversion unit, and the conversion unit applies its encoding operation rule to the variable encoding component for primary transformation, and outputs intermediate result one; pass the intermediate result one to the next conversion unit, and the conversion unit performs a composite operation on the intermediate result one combined with part of the information of the static identification component, and outputs intermediate result two; after processing through all the conversion units, the result output by the last conversion unit is defined as the primary dynamic factor; splice the primary dynamic factor with the current system timestamp, and perform one-way hash calculation on the spliced overall data, and take the obtained hash value as the final dynamic check factor.

6. The hardware Key based server high strength authentication access control method of claim 5, wherein, constructing a stage verification payload includes the following steps: read the attributes of the current verification link to be executed from the directed graph defined by the derived verification policy, including the list of verification element types required by the verification link; retrieve the corresponding reference verification element from the local security storage according to the verification element type list; perform a bitwise fusion operation on the dynamic check factor and the reference verification element to generate a fusion verification element; encapsulate the fusion verification element, the unique identifier of the verification link, and the classification information of the hardware Key device together to form a stage verification payload for the verification link.

7. The hardware Key based server high strength authentication access control method of claim 6, wherein, triggering the verification execution engine to perform identity verification according to the logical sequence defined by the derived verification policy includes the following steps: the verification execution engine parses the received stage verification payload to extract the unique identifier of the verification link; according to the unique identifier, locate the corresponding vertex in the directed graph of the derived verification policy; execute the specific verification logic of the verification link represented by the vertex, which includes parsing and checking the fusion verification element in the stage verification payload; during the verification logic execution process, real-time generate information reflecting the verification progress, data matching state and abnormal events, which together constitute the intermediate state data; according to the execution result of the current verification link and the edge condition defined in the directed graph, determine the next verification link to be executed, and wait for the next corresponding stage verification payload.

8. The hardware Key based server high strength authentication access control method of claim 7, wherein, The capturing of the intermediate state data generated by the authentication execution engine in processing the stage authentication payload includes the following steps: Setting a probe hook in the authentication execution engine, which is implanted into the key logical judgment point of each authentication link; When the execution flow passes through the key logical judgment point, triggering the corresponding probe hook, collecting the local variable value, logical judgment result and stack snapshot information at that time; According to the time sequence, the information collected from different probe hooks is summarized and associated, and the time stamp and link identification are added to form a structured intermediate state data stream; The intermediate state data stream is continuously written into a circular buffer for real-time reading by the process of determining whether the identity authentication is passed.

9. The hardware Key based server high strength authentication access control method of claim 8, wherein, According to the intermediate state data, the identity authentication is determined to be passed or failed, including the following steps: Reading the latest intermediate state data stream from the circular buffer; According to the pre-defined authentication success rule template and authentication failure rule template, the intermediate state data stream is pattern matched; If the event sequence matching the authentication success rule template appears continuously in the intermediate state data stream, and no key event matching the authentication failure rule template appears, it is determined that the identity authentication is passed; If the key event matching the authentication failure rule template appears in the intermediate state data stream, or the complete sequence matching the authentication success rule template fails, it is determined that the identity authentication is failed; Generating an access control decision containing the determination conclusion and the main basis summary.

10. The hardware Key based server high strength authentication access control method of claim 9, wherein, After generating the access control decision, the following steps are further included: Associating and binding the original device credential, static identification component, variable encoding component, dynamic check factor, stage authentication payload, intermediate state data stream and final access control decision generated in the whole process of this identity authentication; Standardizing and formatting the complete data record after association and binding to generate an unforgeable audit trace entry; Synchronously storing the audit trace entry to the local audit database and remote security log server; Periodically clustering the audit trace entry to update the tree structure of the registered device directory and optimize the basic strategy template of the derived authentication strategy.

Images