A dynamic risk management method and system for server cryptographic key

Abstract

The application relates to a dynamic risk management method and system for a server cryptographic key, and belongs to the technical field of cryptographic security, which solves the problems of single identity authentication mechanism and static risk control mechanism in the prior art. The method comprises the following steps: analyzing a current key calling request of a user to obtain a key index, a user IP address, a key calling time and an operation type on the key, taking each as a calling source feature, a time mode feature and an operation behavior feature, and comprehensively taking the three as a current calling behavior feature; according to the key index, corresponding key calling behavior feature baselines are matched from a key behavior attribute portrait library, a comparison result is obtained by comparing the current calling behavior feature with the key calling behavior feature baselines, and a behavior deviation degree is calculated; and after determining a risk level based on the behavior deviation degree, corresponding processing is performed on the current key calling request. The application realizes the increase of the identity authentication mechanism, changes the static authentication into dynamic authentication, and advances the risk control to the key calling stage.

Description

Technical Field

[0001] This invention relates to the field of cryptographic security technology, and in particular to a method and system for dynamic risk management of server cryptographic machine keys. Background Technology

[0002] In existing technologies, the keys stored internally by the server's cryptographic machine (such as the private key used for signing and the private key used for decryption) cannot be directly obtained or used. Applications must communicate with the cryptographic machine through a dedicated software toolkit (SDK). The usage process is as follows: Figure 1 As shown, this establishes a "authorize first, then use" security mechanism: Access Acquisition: Before using any private key, a third-party program must first call a specific interface and submit the private key access control code corresponding to the key to the cryptographic machine service through the cryptographic machine interface library. Only after the cryptographic machine service verifies the private key access control code will the third-party program obtain the corresponding private key operation permissions.

[0003] Key-based invocation: After gaining authorization, when a third-party program actually calls the signing, decryption, or other functional interfaces, it does not directly pass the key itself. Instead, it uses a pre-assigned "key index" number to specify which key to use. The cryptographic machine then uses this index to find the corresponding internal key to execute the operation.

[0004] If an attempt is made to use a non-existent key index, or if the first step of obtaining private key access for a key index has not been completed, the cipher machine will directly refuse the operation and return an error.

[0005] The existing technology has the following problems: (1) The identity verification mechanism is simple. Existing cryptographic key management schemes rely solely on "private key access control codes" for one-time authentication. Once this key is leaked, any holder can access the key, making it impossible to prevent abnormal operations after successful authentication.

[0006] (2) Static lag in risk control mechanism There is a lack of real-time analysis and dynamic control over key usage behavior. Risk detection typically relies on post-incident manual log auditing, which is slow and unable to block attacks immediately when they occur. Summary of the Invention

[0007] Based on the above analysis, the embodiments of the present invention aim to provide a dynamic risk management method and system for server cryptographic machine keys, in order to solve the problems in the prior art.

[0008] On one hand, embodiments of the present invention provide a method for dynamic risk management of server cryptographic machine keys, including: Receive the user's current key access request; The key index, user IP address, key call time, and operation type on the key are obtained by parsing the current key call request. The user IP address is used as the call source feature, the key call time is used as the time pattern feature, and the operation type on the key is used as the operation behavior feature. The call source feature, the time pattern feature, and the operation behavior feature are used as the current call behavior feature. The key index is matched with the corresponding key index from the key behavior attribute profile library according to the key index, and the corresponding key call behavior feature baseline is obtained. The current call behavior feature is compared with the key call behavior feature baseline to obtain the comparison result, and the behavior deviation degree is calculated based on the comparison result. The key behavior attribute profile library stores the key index and the corresponding key call behavior feature baseline. The risk level is determined based on the degree of behavioral deviation, and the key access request is processed accordingly based on the risk level.

[0009] Furthermore, the key invocation behavior characteristic baseline includes the invocation source characteristic baseline, the time pattern characteristic baseline, and the operation behavior characteristic baseline; The current call behavior characteristics are compared with the baseline of the key call behavior characteristics to obtain a comparison result, and the behavior deviation is calculated based on the comparison result, including: The call source characteristics are compared with the call source characteristic baseline to obtain the comparison result of the call source, and the IP deviation is determined based on the comparison result of the call source. The time pattern features are compared with the time pattern feature baseline to obtain the comparison result of the time features, and the time deviation is determined based on the comparison result of the time features. The operational behavior features are compared with the operational behavior feature baseline to obtain the comparison results of the operational behavior features, and the operational deviation is determined based on the comparison results of the operational behavior features. Behavioral deviation is calculated based on IP deviation, time deviation, and operational deviation.

[0010] Furthermore, the baseline of the call source characteristics is determined as follows: Retrieve the call records for each key index within a preset number of calls; Collect all caller IP addresses from the call records; The first three bytes of the caller's IP address are used as a prefix identifier, and the last byte is used as the host number. All caller IP addresses are grouped according to the prefix identifier, and caller IP addresses with the same prefix identifier are grouped into the same prefix group. For each prefix group, the baseline of the call source characteristics is determined based on all host numbers within the group.

[0011] Furthermore, for each prefix group, a baseline of call source characteristics is determined based on all host numbers within the group, including: Calculate the mean and sample standard deviation of all host numbers within the group; Compare the sample standard deviation with the call source mode switching threshold. When the sample standard deviation is less than or equal to the call source mode switching threshold, construct the call source feature baseline for the range mode. The range mode uses a continuous host number range determined based on this average value and the prefix identifier of this group as the call source feature baseline. When the standard deviation of the sample is greater than the threshold for switching the call source mode, the call source features of the whitelist mode are constructed. The whitelist mode uses the set of all host numbers that have appeared in the preset number of calls indexed by the key and the prefix identifier of the group as the baseline of the call source features.

[0012] Furthermore, a continuous range of host numbers is determined based on this average value as follows: Using the mean as the center, subtract the coverage factor times the sample standard deviation to the lower end and round down to obtain the lower bound, and add the coverage factor times the sample standard deviation to the higher end and round up to obtain the upper bound, where the coverage factor is a fixed value.

[0013] Furthermore, the time pattern characteristic baseline is determined as follows: Retrieve the call records for each key index within a preset number of calls; Collect all call times from the call records; Using a preset time as a complete cycle, the time of each call is converted into hours within the cycle, in units of hours. Calculate the hourly average and sample standard deviation for all periods; Compare the sample standard deviation with the time mode switching threshold. When the sample standard deviation is less than or equal to the time mode switching threshold, construct the time feature baseline for the range mode. The range mode uses a continuous time interval within a period determined based on this average value as the time feature baseline. When the standard deviation of the sample is greater than the time mode switching threshold, the time feature of the whitelist mode is constructed. The whitelist mode uses the set of all periods in which the key index has been called within a preset number of calls as the time feature baseline.

[0014] Furthermore, the baseline of operational behavior characteristics is determined as follows: Retrieve the call records for each key index within a preset number of calls; Collect all operation types invoked for the corresponding key from the call records; A set of operation types is formed based on all operation types and the agreed purpose of the key, serving as the baseline for operation types; The operation type transfer relationship between two consecutive calls is statistically analyzed to form a set of operation transfer pairs, which serve as the baseline of the call sequence. The operation type baseline and the call sequence baseline are used as operation behavior feature baselines.

[0015] Furthermore, it also includes: The cumulative risk score for this instance is calculated based on the behavioral deviation and the cumulative risk score from previous instances. The risk level is determined based on the cumulative risk score for this instance. The final risk level is determined based on the risk level determined by the deviation of the behavior in this instance and the risk level determined by the cumulative risk score in this instance. When the final risk level is low risk, record the call log; A safety alert will be issued when the final risk level is medium risk. When the final risk level is high, the call will be blocked and the key for the call will be frozen.

[0016] Furthermore, it also includes: Receive false alarm handling information after reviewing security alarms or blocking events, clear the current accumulated risk status of the key based on the false alarm handling information, and when the false alarm handling is for a blocking event, change the frozen status of the key to an available status.

[0017] On the other hand, embodiments of the present invention provide a dynamic risk management system for server cryptographic machine keys, comprising: The call request receiving module is used to receive the user's current key call request; The call behavior feature generation module is used to parse the current key call request to obtain the key index, user IP address, key call time, and operation type on the key. The user IP address is used as the call source feature, the key call time is used as the time pattern feature, and the operation type on the key is used as the operation behavior feature. The call source feature, the time pattern feature, and the operation behavior feature are used as the current call behavior feature. The comparison and behavior deviation calculation module is used to match the corresponding key index from the key behavior attribute profile library according to the key index, obtain the corresponding key call behavior feature baseline, compare the current call behavior feature with the key call behavior feature baseline, obtain the comparison result, and calculate the behavior deviation based on the comparison result; wherein, the key behavior attribute profile library stores the key index and the corresponding key call behavior feature baseline; The request processing module is invoked to determine the risk level based on the behavioral deviation, and to process the key invocation request accordingly based on the risk level.

[0018] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects: 1) From static authentication to dynamic verification: Based on traditional static password authentication, continuous dynamic verification of each operation is added. Even if an attacker obtains the private key access control code, the system can still identify and block it because the call behavior does not match the historical profile, effectively preventing abnormal use after the authentication credentials are leaked.

[0019] 2) Millisecond-level real-time response: By embedding the risk control engine into the call chain, anomaly detection and handling can be completed instantly before the business request is executed. The time from the occurrence of an attack to the response is shortened from the traditional post-event audit (hours to days) to the millisecond level, greatly compressing the attack window.

[0020] 3) Precise key-level control: Risk response measures can be accurate down to a single key index, minimizing the scope of impact.

[0021] 4) Human-machine collaborative closed loop: The false alarm feedback mechanism enables the system to continuously learn and adapt to business changes.

[0022] 5) Improve operational flexibility and fault tolerance: Through a tiered response and manual review mechanism, the potential impact of a "one-size-fits-all" approach to blocking on business operations is avoided.

[0023] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0024] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Figure 1 This is the original key access control process of the server's cryptographic machine; Figure 2 This invention provides a schematic diagram of a key access control process after a server cryptographic machine implements a risk control mechanism. Figure 3 This is a schematic flowchart of a dynamic risk management method for server cryptographic machine keys provided in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the information used in the initial construction of a key behavior profile library according to an embodiment of the present invention. Figure 5This is a schematic diagram illustrating an example of calculating the baseline of call source features in a key behavior profiling library, provided by an embodiment of the present invention. Figure 6 This is a schematic diagram illustrating an example of calculating the time pattern feature baseline in a key behavior profiling library, provided by an embodiment of the present invention. Figure 7 This is a schematic diagram illustrating an example of calculating the baseline of operational behavior features in a key behavior profiling library, provided by an embodiment of the present invention. Figure 8 A schematic diagram of the key behavior profiling library provided in an embodiment of the present invention; Figure 9 A schematic diagram illustrating the comparison process between a low-risk request and a key behavior profile database provided in an embodiment of the present invention; Figure 10 This is a schematic diagram of a complete key access control process provided in an embodiment of the present invention. Detailed Implementation

[0025] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0026] To address the problems existing in current technologies, this invention constructs a dynamic risk control mechanism embedded within a cryptographic machine, based on key call behavior analysis. Building upon traditional authorization verification, it adds continuous verification and risk control for each key call behavior (e.g., ...). Figure 2 The "comparison through the image database" shown in the image diagram enables proactive protection.

[0027] A specific embodiment of the present invention discloses a dynamic risk management method for server cryptographic machine keys, such as... Figure 3 As shown, it includes: S310: Receive the user's current key access request.

[0028] S320: Parse the current key call request to obtain the key index, user IP address, key call time, and operation type on the key. Use the user IP address as the call source feature, the key call time as the time pattern feature, and the operation type on the key as the operation behavior feature. Use the call source feature, the time pattern feature, and the operation behavior feature as the current call behavior feature.

[0029] In practical implementation, the call source characteristic is the IP address or address range of the application server initiating the call. This is used to identify the caller's identity, and it serves as the caller identifier in key-based call scenarios.

[0030] Time pattern characteristics: the typical working time period and date of the call. Used to identify normal call timing patterns and key operation timing patterns.

[0031] Operational behavior characteristics: the specific function invoked (decryption, signing), and the rationality of the invocation sequence. Used to identify normal operation patterns; this is an operation type unique to the key.

[0032] S330: Match the corresponding key index from the key behavior attribute profile library according to the key index, obtain the corresponding key call behavior feature baseline, compare the current call behavior feature with the key call behavior feature baseline, obtain the comparison result, and calculate the behavior deviation degree based on the comparison result; wherein, the key behavior attribute profile library stores the key index and the corresponding key call behavior feature baseline.

[0033] In some embodiments, the key invocation behavior characteristic baseline includes the invocation source characteristic baseline, the time pattern characteristic baseline, and the operation behavior characteristic baseline.

[0034] In practice, after generating or importing a key for an index, the default key behavior attribute profile library for that key is empty. The call source (i.e., user IP address), time pattern (i.e., key call time), and operation behavior (i.e., operation type on the key) of key call requests within a preset number of calls (e.g., the first ten) are parsed and used as a reference for initializing the attribute profile library. Figure 4 As shown, this allows for the calculation and determination of the historical behavior baseline for feature dimensions. Longer learning periods (such as the first 100 calls) can also be set, or historical profiles based on the same key can be copied, or the initial profile can be manually configured by the administrator.

[0035] In some embodiments, the call source characteristic baseline is determined as follows: Retrieve the call records for each key index within a preset number of calls; Collect all caller IP addresses from the call records; The first three bytes of the caller's IP address are used as a prefix identifier, and the last byte is used as the host number. All caller IP addresses are grouped according to the prefix identifier, and caller IP addresses with the same prefix identifier are grouped into the same prefix group. For each prefix group, the baseline of the call source characteristics is determined based on all host numbers within the group.

[0036] For each prefix group, a baseline of call source characteristics is determined based on all host numbers within the group, including: Calculate the mean and sample standard deviation of all host numbers within the group; Compare the sample standard deviation with the call source mode switching threshold. When the sample standard deviation is less than or equal to the call source mode switching threshold, construct the call source feature baseline for the range mode. The range mode uses a continuous host number interval determined based on this average value as the call source feature baseline. When the standard deviation of the sample is greater than the threshold for switching the call source mode, the call source features of the whitelist mode are constructed. The whitelist mode uses the set of all host numbers that have appeared in the call within a preset number of calls as the baseline of the call source features.

[0037] In specific implementation, such as Figure 5 As shown, the call source feature baseline calculation involves collecting the call IPs from the call records within a preset number of calls and establishing a call source feature baseline for each key based on this address set.

[0038] The first step is address decomposition and grouping.

[0039] Extract the caller's IP address from the call record. Use the first 3 bytes of the IP address as a prefix identifier and the last byte as the host number, with the host number ranging from 1 to 254. Group all call records according to the prefix identifier. Calls with the same prefix identifier are grouped into the same prefix group. Each prefix group calculates its baseline independently, and different prefix groups do not affect each other.

[0040] The second step is to calculate the deviation.

[0041] For each prefix group, calculate the mean and sample standard deviation of all host numbers within the group.

[0042] The third step is pattern matching.

[0043] During the initialization phase, the system calculates the sample mean and sample standard deviation for each prefix group. The sample standard deviation reflects the dispersion of the caller's IP host number around the mean; a smaller standard deviation indicates that the host number is more concentrated around the mean, while a larger standard deviation indicates that the host number deviates more from the mean and is more dispersed. The baseline serves as a reference for subsequent risk detection, and its calculation accuracy directly affects the detection precision. Therefore, it is necessary to select an appropriate baseline construction method based on the distribution characteristics reflected by the sample standard deviation.

[0044] To address this, two baseline construction modes are proposed: range mode and whitelist mode. Range mode uses a continuous range of host numbers as the baseline, and calls falling within this range are considered normal. Whitelist mode uses a precise set of host numbers that appeared during initialization as the baseline, and calls only within this set are considered normal. Range mode is suitable for situations where host numbers are concentrated, as its continuous range naturally encompasses normal fluctuations adjacent to existing host numbers, reducing the likelihood of false alarms. Whitelist mode is suitable for situations where host numbers are dispersed, maintaining accurate differentiation capabilities regardless of the distribution pattern.

[0045] Switching from range mode to whitelist mode is essentially a process of the caller IPs moving from clustering to dispersion, i.e., a process of the sample standard deviation increasing from small to large. Therefore, there is a critical standard deviation value between the two. This critical value means: below this value, the width of the interval selected by range mode is less than the total width of the network segment, the proportion of valid data within the interval is large, the baseline is accurate, and subsequent detection is accurate; above this value, the width of the interval selected by range mode reaches or exceeds the total width of the network segment, the interval contains a large number of invalid host numbers that have never appeared before, the baseline is blurred, and subsequent detection is prone to false negatives. Therefore, this critical value is the precise mathematical boundary at which range mode changes from valid to invalid, and its solution condition is that the baseline interval width of range mode is exactly equal to the total width of available host numbers in the network segment, i.e., 2. k s=254, solving for s gives 254 / (2 (k) where k is the coverage coefficient and s is the sample standard deviation. This value is the threshold for switching the source mode. When the sample standard deviation is greater than this threshold, the host number distribution of the caller's IP is relatively dispersed, and the baseline interval width of the range mode will inevitably exceed the total width of the network segment. The range mode will fail and cannot effectively distinguish between normal and abnormal host numbers, so a whitelist mode is constructed. When the sample standard deviation is less than or equal to this threshold, the baseline interval width of the range mode does not exceed the total width of the network segment, the range mode is effective, and a range mode is constructed.

[0046] Step 4: Baseline calculation.

[0047] The baseline construction method for the range pattern is as follows: For the range pattern, since the calling behavior of the caller IP exhibits an approximately normal distribution around the mean, the baseline interval of the range pattern can be constructed by extending a certain distance to both the left and right sides, using the average value of the prefix group as the center. To ensure that this extension distance reflects the actual dispersion of the data, it is defined as the coverage coefficient k times the sample standard deviation, i.e., extending a distance of k times s to both the left and right sides. Therefore, the total width of the baseline interval of the range pattern is equal to 2. k s, where 2 represents the sum of the two-way extensions, k is the coverage coefficient, and s is the sample standard deviation. Specifically, with the mean as the center, subtracting k times s towards the lower end and rounding down yields the lower bound, while adding k times s towards the higher end and rounding up yields the upper bound. If the lower bound is less than 1, it is truncated to 1; if the upper bound is greater than 254, it is truncated to 254, ensuring that the result always falls within the valid host number range. When the sample standard deviation is 0, both the lower and upper bounds are equal to the mean, and the baseline range covers only a single host number. This prefix identifier, together with the range from the lower to the upper bound, constitutes the call source characteristic baseline of this prefix group.

[0048] The default value of the coverage coefficient k is derived as follows: The calling behavior of the caller IP follows an approximately normal distribution centered on the mean. Under the normal distribution, the coverage ratio of data within k standard deviations on both sides of the mean depends on the value of k. When k equals 1, the coverage is about 68%, that is, 30% of normal calls are excluded from the range, resulting in an excessively high false alarm rate; when k equals 3, the coverage is about 99.7%, that is, the range is too wide and only a very small number of anomalies can be detected, resulting in an excessively high false negative rate; when k equals 2, the coverage is about 95%, that is, most normal calls are within the range and are not affected, while retaining the detection space for abnormal calls that deviate from the mean. This is the classic balance point between security interception capability and business false alarm tolerance in statistics. Therefore, the default value of k is 2. Substituting into the call source mode switching threshold formula, we get s=254 / 4=63.5.

[0049] The baseline construction method for whitelist mode is as follows: For whitelist mode, the baseline is the exact set of all host numbers that have appeared in the prefix group during initialization, without constructing a continuous range.

[0050] The core feature of the whitelist mode is that its distinguishing ability is not affected by the distribution pattern. In the range mode, as the standard deviation increases, the continuous interval widens, and the number of host numbers that have never appeared in the interval increases, gradually reducing the distinguishing ability until it becomes completely ineffective; while the whitelist mode, regardless of the standard deviation or how dispersed the distribution is, always only recognizes host numbers that have actually appeared, and judges all host numbers that have not appeared as abnormal, thus maintaining a constant distinguishing ability.

[0051] In some embodiments, the time pattern feature baseline is determined as follows: Retrieve the call records for each key index within a preset number of calls; Collect all call times from the call records; Using a preset time as a complete cycle (e.g., a week as a complete cycle), convert the time of each call into hours within the cycle; Calculate the hourly average and sample standard deviation for all periods; Compare the sample standard deviation with the time mode switching threshold. When the sample standard deviation is less than or equal to the time mode switching threshold, construct the time feature baseline for the range mode. The range mode uses a continuous time interval within a period determined based on this average value as the time feature baseline. When the standard deviation of the sample is greater than the time mode switching threshold, the time feature of the whitelist mode is constructed. The whitelist mode uses the set of all periods in which the key index has been called within a preset number of calls as the time feature baseline.

[0052] In specific implementation, such as Figure 6As shown, the time pattern feature baseline calculation method is as follows: Call times are collected from call records within a preset threshold for the number of calls, with a full week as the cycle (but this does not mean that a whole week's worth of data needs to be collected). Each call time is converted to hours within the cycle, with a total duration of 7. 24 = 168 hours. For example, if a call occurs at 00:22:23 on Monday, it is counted as a call occurring within the first hour; similarly, if a call occurs at 09:44:34 on Thursday, it is counted as a call occurring within the 82nd hour. Furthermore, a call time characteristic baseline is established for each key based on this hourly distribution.

[0053] The specific calculation method is consistent with the baseline calculation method of the source feature. The baseline is constructed using range mode and whitelist mode. The method for determining mode switching is still to compare the sample standard deviation with the mode switching threshold. In range mode, a continuous interval is constructed by extending k times the sample standard deviation to both sides of the mean. In whitelist mode, the set of exact values ​​that have appeared is used as the baseline.

[0054] However, the call time is based on a complete week, converting each call time into an hourly sequence number within the week. A week has a total of 168 hours. The coverage coefficient k in range mode is 2, and the mode switching threshold is s = 168 / 4 = 42. The baseline of range mode converts the lower and upper bound sequences into "AA hour of week A to BB hour of week B", while the baseline of whitelist mode converts the precise hour sequence set into the precise time point set of "AA hour of week A".

[0055] In some embodiments, the operational behavior characteristic baseline is determined as follows: Retrieve the call records for each key index within a preset number of calls; Collect all operation types invoked for the corresponding key from the call records; A set of operation types is formed based on all operation types and the agreed purpose of the key, serving as the baseline for operation types; The operation type transfer relationship between two consecutive calls is statistically analyzed to form a set of operation transfer pairs, which serve as the baseline of the call sequence. The operation type baseline and the call sequence baseline are used as operation behavior feature baselines.

[0056] In specific implementation, such as Figure 7 As shown, the baseline calculation method for operation behavior features is as follows: the call sequence in the call record within the preset threshold of the number of calls is collected. Unlike the call source feature and time pattern feature, the operation behavior feature includes two dimensions of description: operation type and call sequence. Moreover, its actual content does not have numerical order and distance relationship, and the range mode is not applicable. The whitelist mode is adopted.

[0057] Operation type baseline calculation: In a cryptographic machine, keys are typically used for operations such as encryption, decryption, signing, and signature verification. Keys themselves also have a type classification: the signing key (private key) is primarily used for signing operations, and the decryption key (private key) is primarily used for decryption operations. If a key suddenly exhibits an operation type different from its historical and agreed-upon purpose, it is highly likely that the key is being used aberrantly.

[0058] During the initialization phase, the system records all operation types invoked by the index key and further filters and judges them against the agreed purpose of the key to form a set of operation types. This set is the operation type baseline.

[0059] Call sequence baseline calculation: A call sequence refers to the operation type transfer relationship between two adjacent calls to the same key index. In normal business operations, key calls usually follow certain operation patterns: some operation types frequently appear in conjunction, while other combinations never appear or appear very rarely. For example, the normal pattern for a signing key might be multiple consecutive signings, while a cross-type transfer like 'decrypt -> sign' might be abnormal.

[0060] During the initialization phase, the system records the operation type transition pairs for each call to the key index, i.e., (operation type of the previous call -> operation type of the current call), forming a set of operation transition pairs. This set is the call sequence baseline.

[0061] To better illustrate the calculation of sequence baselines, the following example is provided for reference: Suppose that the call sequence during the initialization of a certain index key is as follows: Signature, signature, signature, signature, decryption, signature, signature, signature, signature, decryption The resulting transfer pairs are: signature->signature, signature->decryption, decryption->signature.

[0062] Therefore, the baseline of the call sequence is: {signature->signature, signature->decryption, decryption->signature}.

[0063] In summary, by establishing a dynamic profile of key call behavior, a comparable baseline is provided for subsequent risk assessment, which is the foundation for achieving "continuous verification".

[0064] The final behavioral attribute profile library, such as Figure 8 As shown.

[0065] In some embodiments, S330 compares the current call behavior characteristics with the baseline of the key call behavior characteristics to obtain a comparison result, and calculates the behavior deviation based on the comparison result, including: Based on the key index, the corresponding key index is matched from the key behavior attribute profile library to obtain the corresponding key call behavior feature baseline; The call source characteristics are compared with the call source characteristic baseline to obtain the comparison result of the call source, and the IP deviation is determined based on the comparison result of the call source. The time pattern features are compared with the time pattern feature baseline to obtain the comparison result of the time features, and the time deviation is determined based on the comparison result of the time features. The operational behavior features are compared with the operational behavior feature baseline to obtain the comparison results of the operational behavior features, and the operational deviation is determined based on the comparison results of the operational behavior features. Behavioral deviation is calculated based on IP deviation, time deviation, and operational deviation.

[0066] In practice, the characteristics of the current call source will be compared with the baseline characteristics of the current call source: If the prefix identifier of the caller's IP address does not exist in any established prefix group, the IP deviation is directly determined to be 1. If the prefix group corresponding to the prefix identifier is in range mode, it is determined whether the host number of the caller's IP address is greater than or equal to the lower bound and less than or equal to the upper bound. If it meets the condition, the IP deviation is 0; otherwise, it is 1. If the prefix group corresponding to the prefix identifier is in whitelist mode, it is determined whether the host number belongs to the exact set of host numbers in the prefix group. If it does, the IP deviation is 0; otherwise, it is 1.

[0067] Additionally, when the sample standard deviation is 0, both the lower and upper bounds are equal to the mean, and the baseline range only covers a single host number. At this point, any call different from that host number is considered abnormal. If a false alarm occurs later, the administrator can add the new host number to the profile database through the false alarm feedback mechanism to expand the baseline range.

[0068] Compare the current time pattern features with the time pattern feature baseline: When a subsequent key call occurs, the time of this call is extracted. Using a one-week period as the complete cycle, each call time is converted into an hourly sequence number within that cycle. In range mode, it is determined whether the current call time is greater than or equal to the lower bound and less than or equal to the upper bound; if so, the time deviation is 0; otherwise, it is 1. In whitelist mode, it is determined whether the time belongs to the exact set of times; if so, the time deviation is 0; otherwise, it is 1.

[0069] Compare the current operational behavior characteristics with the baseline operational behavior characteristics: When a subsequent key call occurs, extract the operation type of this call: if the operation type belongs to the set of operation types, the operation type deviation is 0; otherwise, it is 1.

[0070] Extract the operation type of the current call and the operation type of the previous call to form the current transition pair: if the transition pair belongs to the call sequence baseline set, the call sequence deviation is 0; otherwise, it is 1.

[0071] The overall operation deviation is calculated as follows: Operation Deviation = max(Operation Type Deviation, Call Sequence Deviation). That is, if either the Operation Type Deviation or the Call Sequence Deviation is 1, the operation deviation is 1; if both are 0, the operation deviation is 0.

[0072] Then, the final behavioral deviation calculation method is as follows: Behavioral deviation = w1 × IP deviation + w2 × Time deviation + w3 × Operational deviation; Where w1, w2, and w3 are the weight coefficients for each dimension, which can be configured according to actual security needs. The default value for each is 1 / 3.

[0073] Of course, the weighting coefficients of the feature dimensions can be adjusted individually for each type of key based on the focus of the actual application scenario. For example, a key with index 1 is only used for applications on a fixed IP application server, but the call time is not fixed, and the call behavior is mostly signature verification. Then, w1, w2, w3 = (0.5, 0.2, 0.3) can be configured for this key, indicating that the deviation of the key's behavior focuses on reflecting the situation of the call source. When the call source deviates, it enters the medium risk category; if the other dimensions deviate further, it enters the high risk category.

[0074] For example, such as Figure 9 As shown, from a certain key call request, we obtain IP: 192.168.122.52, date: Monday, June 29, 2026, time: 10:21:33, operation: SM2 decryption, key index: 2. This information is then passed to the dynamic risk control engine. The engine searches for "key index: 2" in the internal attribute profile database of the cryptographic machine. It then compares "IP: 192.168.122.52" with the baseline of the call source characteristics corresponding to "key index: 2" in the profile database. Host number 52 is not located in host number {23, 47}, indicating a network address deviation, with an IP deviation degree of 1. Converting "Date: Monday, June 29, 2026, Time: 10:21:33" to the 10th hour within the period, and comparing it with the baseline range {1, 82} of the call time feature corresponding to "Key Index: 2" in the profile database, it falls within {1, 82}, showing no deviation, therefore the time deviation is 0. Comparing "Operation: SM2 Signature" with the baseline range {Signature} of the operation behavior feature corresponding to "Key Index: 2" in the profile database,... If no deviation is found when comparing the signatures, the operational deviation is 0. The final behavioral deviation = 1 / 3 × 1 + 1 / 3 × 0 + 1 / 3 × 0 = 1 / 3, which is determined to be low risk (a risk assessment will be provided later).

[0075] S340: Determine the risk level based on the behavioral deviation, and process the key call request accordingly based on the risk level.

[0076] In some embodiments, the key access request is processed accordingly based on the risk level, including: When the risk level is low, record the call log; When the risk level is medium risk, a safety alarm will be issued; When the risk level is high, the call will be blocked and the key for the call will be frozen.

[0077] In practice, the tiered response mechanism employs three preset risk levels: low risk, medium risk, and high risk. A behavioral deviation score corresponds to a specific risk level, triggering different response measures.

[0078] Low risk [0, 0.3): Only logs are recorded. Slight fluctuations within the normal range do not affect business operations. Low risk can only be defined as zero deviation in IP, time, and operation. IP deviation, time deviation, and operation deviation are all 0.

[0079] Medium risk [0.3, 0.7): Record security alerts and notify the administrator, but allow operations to continue. Some anomalies exist, requiring attention but not affecting business continuity. If any one of these factors deviates, and the other two do not, the default value is slightly over 0.3. If any two of these factors deviate, and the other does not, the default value is slightly over 0.6, falling within the medium risk range.

[0080] High risk [0.7, 1): Immediately block this call and freeze the key. A serious anomaly requiring immediate blocking. When all three values ​​deviate from the target value, the default value is slightly over 0.9, falling within the high-risk range based on the risk level.

[0081] For a setting w1, w2, w3 = (0.5, 0.2, 0.3), if the source of the call deviates, it enters the medium risk level; if the other dimensions deviate further, it enters the high risk level.

[0082] The key freezing mechanism for high-risk keys is a security response measure unique to cryptographic machines, which can fundamentally prevent the continued use of risky keys.

[0083] Key freezing mechanism: The key index cannot be used by any caller until it is unfrozen.

[0084] Unfreezing method: Requires manual unfreezing by the administrator.

[0085] During the freeze: The system continues to record call attempts to the key index, providing data for subsequent security analysis.

[0086] Alternatively, for high-risk cases, instead of freezing the key, a delayed response can be implemented, with an additional manual confirmation step.

[0087] In some embodiments, it also includes: The cumulative risk score for this instance is calculated based on the behavioral deviation and the cumulative risk score from previous instances. The risk level is determined based on the cumulative risk score for this instance. The final risk level is determined based on the risk level determined by the deviation of the behavior in this instance and the risk level determined by the cumulative risk score in this instance. When the final risk level is low risk, record the call log; A safety alert will be issued when the final risk level is medium risk. When the final risk level is high risk, block the current call and freeze the key for this call; Receive false alarm handling information after reviewing security alarms or blocking events, clear the current accumulated risk status of the key based on the false alarm handling information, and when the false alarm handling is for a blocking event, change the frozen status of the key to an available status.

[0088] In practice, the above describes the immediate risk of a single call. For the same key, if abnormal behavior occurs consecutively within a short period, the system will accumulate risk scores, increasing and escalating the risk. Even if a single deviation does not reach the highest threshold, the accumulated result may trigger a higher level of response (e.g., escalating from medium risk to high risk, thereby triggering a freeze response mechanism).

[0089] Example of risk accumulation calculation: Cumulative risk score = Previous cumulative score × Decay coefficient + Current deviation score The attenuation coefficient (e.g., 0.9) ensures that the impact of historical risks gradually decreases while retaining a certain cumulative effect.

[0090] Cumulative risk score corresponds to risk level classification: [0, 0.3) represents low risk, [0.3, 0.7) represents medium risk, and [0.7, +∞) represents high risk.

[0091] Examples of cumulative upgrades are shown in Table 1 below: Table 1

[0092] In the example above, the result of each deviation calculation is medium risk (0.3-0.7), but after the second medium risk call, the cumulative score exceeds 0.7, triggering a high risk freeze.

[0093] In practice, all risk alerts and blocking events are pushed to the audit interface, where administrators can view relevant information and make judgments based on actual usage.

[0094] (1) Risk information content Risk alerts and blocking event information include: basic event information (key index, triggering event, behavior deviation, cumulative risk score), deviation details (IP deviation and corresponding baseline range, event deviation and corresponding baseline range, operation deviation and baseline mode), and operation options (confirm threat (maintain freeze) / confirm false alarm (unfreeze + update baseline) / ignore (only record, do not process)).

[0095] (2) False alarm determination Based on the information displayed on the audit page, administrators determine whether a report is a false alarm by considering the following factors: 1. Changes in call characteristics due to business adjustments. For example: a newly deployed application server causes the call source IP to exceed the original baseline range; adjustments to the business call time period cause the call time to exceed the original baseline; changes in business processes cause changes in operation types or call sequences.

[0096] 2. Insufficient sample size or coverage during the initialization phase resulted in the baseline failing to cover all legitimate call patterns. For example, calls only occurred on weekdays during the initialization phase, leading to misjudgments of legitimate calls on weekends; or calls were made only by a single server during the initialization phase, resulting in new IPs being misjudged as having abnormal origins after multi-server deployment.

[0097] 3. Temporary, legitimate operations whose behavioral patterns are no longer within the daily baseline. Examples include: temporary business scenarios such as annual settlement and emergency response; one-time operations such as system migration and disaster recovery.

[0098] (3) False alarm handling If the report is false (e.g., a normal business change), the administrator can click the "False Report" button. After clicking, the backend will: 1) Immediately clear the current accumulated score and deviation, as well as the risk status, of this key; 2) Change the key status from "frozen" to "available"; 3) Treat the misjudged call characteristics as positive samples, update the behavior profile library for that key, and recalculate the statistical baselines for each characteristic dimension. Afterward, calls with the same characteristics will be considered normal and will no longer trigger risk alerts.

[0099] 4) Update the logs.

[0100] Specifically, the call source feature baseline update is as follows: After a "false alarm" is confirmed, the system will extract the prefix identifier and host number of the caller's IP address. If the prefix identifier does not exist in the existing grouping table of the baseline, a new prefix group will be created for the prefix identifier, and the host number will be used as the first sample of the group. Subsequent calls will gradually accumulate until the initialization threshold is reached to establish the baseline, i.e., whitelist mode. If the prefix identifier already exists in a grouping table, the host number will be added as a new sample to the historical data of the corresponding prefix group, the sample mean and sample standard deviation of the prefix group will be recalculated, and the pattern determination and baseline calculation will be re-performed based on the updated standard deviation.

[0101] After updating the source feature baseline, a mode switch may occur due to changes in the sample mean and standard deviation. If the previous mode was range mode and the updated standard deviation is still less than or equal to the mode switch threshold, the range mode is maintained, and the range interval is recalculated based on the updated mean and standard deviation. If the updated standard deviation is greater than the mode switch threshold, the mode is switched to whitelist mode, and the baseline is changed to the updated exact set of host numbers. If the previous mode was whitelist mode and the updated standard deviation is less than or equal to the mode switch threshold, the mode is switched to range mode, and the baseline is changed to a continuous interval constructed based on the updated mean and standard deviation.

[0102] Time pattern feature baseline update: When a false alarm is updated, the hour sequence number within the period of the current false alarm call is added to the historical data as a new sample, the sample mean and sample standard deviation are recalculated, and the pattern determination and baseline calculation are re-performed based on the updated standard deviation. If the pattern is switched, the baseline is reconstructed according to the new pattern and converted into the expression of weekday and time.

[0103] Operation behavior feature baseline update: When a false alarm is updated, the key operation type of the false alarm is added to the historical data as a new sample, and the operation behavior feature baseline is redefined.

[0104] If it is not a false alarm, confirm the threat and keep the key frozen.

[0105] like Figure 10 As shown, the complete process of this invention is as follows: Upon receiving a key access request, the system verifies the private key access control code (traditional permission verification) based on the request. If verification fails, the request is rejected. If verification succeeds, the system extracts the access characteristics (key index, IP, time, and operation sequence) from the request. These characteristics are then matched against a key behavior attribute profile database and compared to the baseline of key access behavior characteristics corresponding to the matched key index. Based on the comparison results, the system calculates the deviation from the target behavior and determines the risk level. A cumulative risk score is then obtained and the cumulative risk level is determined. The final risk level is obtained by combining the risk level with the cumulative risk level. For each risk level assessment, if the final risk level is low, the process ends; if it is medium, a security alert is issued; if it is high, the call is blocked, and the key for the call is frozen. Both medium and high risk levels require administrator review, including checking deviation details, baseline comparison, and cumulative score to determine if it's a false alarm. If a false alarm is confirmed, then: ① the cumulative score and deviation are reset to zero; ② the key is unfrozen; ③ the false alarm information is added as a sample to update the profile; ④ the logs are updated. If it's determined not to be a false alarm, the threat is confirmed, and the key remains frozen.

[0106] Compared with existing technologies, the dynamic risk management method for server cryptographic machine keys provided in this embodiment can achieve the following beneficial effects: 1) From Static Authentication to Dynamic Verification: Building upon traditional static password authentication, continuous dynamic verification of each operation is added. Even if an attacker obtains the private key access control code, the system can still identify and block the attack because the call behavior does not match the historical profile, effectively preventing abnormal use after authentication credentials are leaked. By establishing a dynamic profile of key call behavior, a comparable baseline is provided for subsequent risk assessment, which is the foundation for achieving "continuous verification".

[0107] 2) Millisecond-level real-time response: By embedding the risk control engine into the call chain, anomaly detection and handling can be completed instantly before the business request is executed. The time from the occurrence of an attack to the response is shortened from the traditional post-event audit (hours to days) to the millisecond level, greatly compressing the attack window.

[0108] 3) Precise key-level control: Risk response measures can be accurate down to a single key index, minimizing the scope of impact.

[0109] 4) Risk accumulation and escalation mechanism: effectively prevent attackers from using "low-frequency probing" methods to evade detection.

[0110] 5) Human-machine collaborative closed loop: The false alarm feedback mechanism enables the system to continuously learn and adapt to business changes. Through... 6) Enhance operational flexibility and fault tolerance: Through tiered response and manual review mechanisms, and a closed-loop mechanism of human-machine collaboration, the potential impact of "one-size-fits-all" blocking on business operations is avoided, thereby enhancing operational flexibility and fault tolerance while ensuring security.

[0111] A specific embodiment of the present invention discloses a dynamic risk management method system for server cryptographic machine keys, namely a dynamic risk control engine, comprising: The call request receiving module is used to receive the user's current key call request; The call behavior feature generation module is used to parse the current key call request to obtain the key index, user IP address, key call time, and operation type on the key. The user IP address is used as the call source feature, the key call time is used as the time pattern feature, and the operation type on the key is used as the operation behavior feature. The call source feature, the time pattern feature, and the operation behavior feature are used as the current call behavior feature. The comparison and behavior deviation calculation module is used to match the corresponding key index from the key behavior attribute profile library according to the key index, obtain the corresponding key call behavior feature baseline, compare the current call behavior feature with the key call behavior feature baseline, obtain the comparison result, and calculate the behavior deviation based on the comparison result; wherein, the key behavior attribute profile library stores the key index and the corresponding key call behavior feature baseline; The request processing module is invoked to determine the risk level based on the behavioral deviation, and to process the key invocation request accordingly based on the risk level.

[0112] It also includes: Management interaction module: providing manual review and status rollback functions.

[0113] The above-described method and system embodiments are based on the same principles, and their related aspects can be referenced from each other to achieve the same technical effects. For specific implementation processes, please refer to the foregoing embodiments, which will not be repeated here.

[0114] Electronic device example: One specific implementation of this application discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the kernel probe configuration method based on visual interaction in the method embodiment.

[0115] Examples of readable storage media: One specific implementation of this application discloses a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the kernel probe configuration method based on visual interaction in the method embodiment.

[0116] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0117] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for dynamic risk management of server cryptographic machine keys, characterized in that, include: Receive the user's current key access request; The key index, user IP address, key call time, and operation type on the key are obtained by parsing the current key call request. The user IP address is used as the call source feature, the key call time is used as the time pattern feature, and the operation type on the key is used as the operation behavior feature. The call source feature, the time pattern feature, and the operation behavior feature are used as the current call behavior feature. The key index is matched with the corresponding key index from the key behavior attribute profile library according to the key index, and the corresponding key call behavior feature baseline is obtained. The current call behavior feature is compared with the key call behavior feature baseline to obtain the comparison result, and the behavior deviation degree is calculated based on the comparison result. The key behavior attribute profile library stores the key index and the corresponding key call behavior feature baseline. The risk level is determined based on the degree of behavioral deviation, and the key access request is processed accordingly based on the risk level.

2. The dynamic risk management method for server cryptographic machine keys according to claim 1, characterized in that, The key invocation behavior characteristic baseline includes the invocation source characteristic baseline, the time pattern characteristic baseline, and the operation behavior characteristic baseline; The characteristics of this invocation behavior are compared with the baseline characteristics of key invocation behavior to obtain the comparison result, and the behavior deviation is calculated based on the comparison result, including: The call source characteristics are compared with the call source characteristic baseline to obtain the comparison result of the call source, and the IP deviation is determined based on the comparison result of the call source. The time pattern features are compared with the time pattern feature baseline to obtain the comparison result of the time features, and the time deviation is determined based on the comparison result of the time features. The operational behavior features are compared with the operational behavior feature baseline to obtain the comparison results of the operational behavior features, and the operational deviation is determined based on the comparison results of the operational behavior features. Behavioral deviation is calculated based on IP deviation, time deviation, and operational deviation.

3. The dynamic risk management method for server cryptographic machine keys according to claim 2, characterized in that, Determine the baseline of the call source characteristics as follows: Retrieve the call records for each key index within a preset number of calls; Collect all caller IP addresses from the call records; The first three bytes of the caller's IP address are used as a prefix identifier, and the last byte is used as the host number. All caller IP addresses are grouped according to the prefix identifier, and caller IP addresses with the same prefix identifier are grouped into the same prefix group. For each prefix group, the baseline of the call source characteristics is determined based on all host numbers within the group.

4. The dynamic risk management method for server cryptographic machine keys according to claim 3, characterized in that, For each prefix group, a baseline of call source characteristics is determined based on all host numbers within the group, including: Calculate the mean and sample standard deviation of all host numbers within the group; Compare the sample standard deviation with the call source mode switching threshold. When the sample standard deviation is less than or equal to the call source mode switching threshold, construct the call source feature baseline for the range mode. The range mode uses a continuous host number range determined based on this average value and the prefix identifier of this group as the call source feature baseline. When the standard deviation of the sample is greater than the threshold for switching the call source mode, the call source features of the whitelist mode are constructed. The whitelist mode uses the set of all host numbers that have appeared in the preset number of calls indexed by the key and the prefix identifier of the group as the baseline of the call source features.

5. The dynamic risk management method for server cryptographic machine keys according to claim 4, characterized in that, A continuous range of host numbers is determined based on this average value as follows: Using the mean as the center, subtract the coverage factor times the sample standard deviation to the lower end and round down to obtain the lower bound, and add the coverage factor times the sample standard deviation to the higher end and round up to obtain the upper bound, where the coverage factor is a fixed value.

6. The dynamic risk management method for server cryptographic machine keys according to claim 2, characterized in that, The time pattern feature baseline is determined as follows: Retrieve the call records for each key index within a preset number of calls; Collect all call times from the call records; Using a preset time as a complete cycle, the time of each call is converted into hours within the cycle, in units of hours. Calculate the hourly average and sample standard deviation for all periods; Compare the sample standard deviation with the time mode switching threshold. When the sample standard deviation is less than or equal to the time mode switching threshold, construct the time feature baseline of the range mode. The range pattern uses a continuous periodic time interval determined based on this average value as the baseline for time characteristics; When the standard deviation of the sample is greater than the time mode switching threshold, the time feature of the whitelist mode is constructed. The whitelist mode uses the set of all periods in which the key index has been called within a preset number of calls as the time feature baseline.

7. The dynamic risk management method for server cryptographic machine keys according to claim 2, characterized in that, The baseline of operational behavior characteristics shall be determined as follows: Retrieve the call records for each key index within a preset number of calls; Collect all operation types invoked for the corresponding key from the call records; A set of operation types is formed based on all operation types and the agreed purpose of the key, serving as the baseline for operation types; The operation type transfer relationship between two consecutive calls is statistically analyzed to form a set of operation transfer pairs, which serve as the baseline of the call sequence. The operation type baseline and the call sequence baseline are used as operation behavior feature baselines.

8. The dynamic risk management method for server cryptographic machine keys according to claim 1, characterized in that, Also includes: The cumulative risk score for this instance is calculated based on the behavioral deviation and the cumulative risk score from previous instances. The risk level is determined based on the cumulative risk score for this instance. The final risk level is determined based on the risk level determined by the deviation of the behavior in this instance and the risk level determined by the cumulative risk score in this instance. When the final risk level is low risk, record the call log; A safety alert will be issued when the final risk level is medium risk. When the final risk level is high, the call will be blocked and the key for the call will be frozen.

9. The dynamic risk management method for server cryptographic machine keys according to claim 8, characterized in that, Also includes: Receive false alarm handling information after reviewing security alarms or blocking events, clear the current accumulated risk status of the key based on the false alarm handling information, and when the false alarm handling is for a blocking event, change the frozen status of the key to an available status.

10. A dynamic risk management system for server cryptographic machine keys, characterized in that, include: The call request receiving module is used to receive the user's current key call request; The call behavior feature generation module is used to parse the current key call request to obtain the key index, user IP address, key call time, and operation type on the key. The user IP address is used as the call source feature, the key call time is used as the time pattern feature, and the operation type on the key is used as the operation behavior feature. The call source feature, the time pattern feature, and the operation behavior feature are used as the current call behavior feature. The comparison and behavior deviation calculation module is used to match the corresponding key index from the key behavior attribute profile library according to the key index, obtain the corresponding key call behavior feature baseline, compare the current call behavior feature with the key call behavior feature baseline, obtain the comparison result, and calculate the behavior deviation based on the comparison result; wherein, the key behavior attribute profile library stores the key index and the corresponding key call behavior feature baseline; The request processing module is invoked to determine the risk level based on the behavioral deviation, and to process the key invocation request accordingly based on the risk level.

Images