Key issuance method, device, apparatus, medium, and program product

Abstract

The application provides a key distribution method, device, equipment, storage medium and program product, which can be applied to the technical field of quantum communication. The method comprises the following steps: in response to a key acquisition request sent by a client, acquiring identification information of the client; determining a first key corresponding to the client and historical feature information of the client according to the identification information, wherein the historical feature information represents running information of the client in a past preset time period; performing risk assessment on the client according to the historical feature information to obtain a risk assessment result, wherein the risk assessment result represents whether the client has risks; in the case that the risk assessment result represents that the client has risks, generating a second key with a key value different from the first key; and distributing the second key to the client.

Description

Technical Field

[0001] This application relates to the field of quantum communication, and more specifically to a key distribution method, apparatus, device, medium, and program product. Background Technology

[0002] In today's large-scale distributed system architectures, the security of data transmission and storage highly depends on an effective key management mechanism. Traditional mainstream key management schemes typically follow two models: one is to use static keys, where keys are generated during system deployment and remain unchanged indefinitely, hard-coded in configuration files or databases; the other is to use a fixed-period update strategy, where all service keys are rotated uniformly at preset time intervals such as 24 hours or 7 days, regardless of the actual operating status and security posture of the system.

[0003] These traditional approaches are increasingly revealing their inherent flaws in dynamic, heterogeneous modern distributed environments. First, static key policies are extremely vulnerable. Once a key is obtained by an attacker due to code leaks, misconfiguration, or internal threats, the entire system will be completely exposed during the long window before the key is manually changed. Attackers can decrypt all previously intercepted ciphertext data, posing a business risk. Second, while fixed periodic update strategies formally achieve key rotation, their mechanical update logic has significant drawbacks.

[0004] Therefore, there is an urgent need for a key dynamic management method that can deeply integrate real-time risk perception, support fine-grained differentiated strategies, and automate intelligent decision-making to address the new security challenges faced by distributed systems, thereby improving the initiative and accuracy of security protection while optimizing the overall resource efficiency and stability of the system. Summary of the Invention

[0005] In view of the above problems, embodiments of this application provide a key distribution method, apparatus, device, medium, and program product.

[0006] According to a first aspect of this application, a key distribution method is provided, comprising: responding to a key acquisition request issued by a client, acquiring the client's identification information; determining a first key and historical feature information corresponding to the client based on the identification information, wherein the historical feature information characterizes the client's operational information within a preset time period in the past; performing a risk assessment on the client based on the historical feature information to obtain a risk assessment result, wherein the risk assessment result characterizes whether the client is at risk; if the risk assessment result characterizes that the client is at risk, generating a second key with a key value different from the first key; and distributing the second key to the client.

[0007] According to an embodiment of this application, determining the first key and historical feature information corresponding to the client based on the identification information includes: performing an association query in a preset key configuration database based on the identification information to determine the first key corresponding to the identification information; extracting the historical operation logs and performance indicators corresponding to the client from a preset operation monitoring database based on the identification information; and aggregating the historical operation logs and performance indicators to obtain historical feature information.

[0008] According to an embodiment of this application, risk assessment of the client is performed based on historical feature information to obtain the risk assessment result, which includes: standardizing the historical feature information to obtain a standardized feature vector of a unified dimension; inputting the standardized feature vector into a pre-trained machine learning model to perform risk assessment of the client; obtaining the risk probability value output by the machine learning model; and determining the risk assessment result based on the risk probability value and a preset probability threshold.

[0009] According to an embodiment of this application, when the risk assessment result indicates that the client has a risk, generating a second key with a different key value from the first key includes: randomly generating a byte sequence of a preset length; formatting and encoding the byte sequence; and assigning a globally unique key version number to the formatted and encoded byte sequence to obtain the second key.

[0010] According to an embodiment of this application, distributing the second key to the client includes: establishing an encrypted communication channel and sending a key update message to the client through the encrypted communication channel; in response to a first response message received from the client regarding the key update message, sending the second key to the client; and in response to a second response message received from the client indicating successful receipt of the second key, deassociating the first key with the identification information and associating the second key with the identification information.

[0011] According to an embodiment of this application, the key distribution method further includes: distributing the first key to the client when the risk assessment result indicates that the client does not pose a risk.

[0012] According to embodiments of this application, historical feature information includes: network latency data, number of authentication failures, and key usage frequency.

[0013] According to a second aspect of this application, a key distribution device is provided, comprising: an identifier acquisition module, configured to acquire identifier information of a client in response to a key acquisition request issued by a client; an information determination module, configured to determine a first key and historical feature information corresponding to the client based on the identifier information, wherein the historical feature information characterizes the client's operational information over a preset time period; a risk assessment module, configured to perform a risk assessment on the client based on the historical feature information, and obtain a risk assessment result, wherein the risk assessment result characterizes whether the client is at risk; a key generation module, configured to generate a second key with a key value different from the first key if the risk assessment result characterizes that the client is at risk; and a key distribution module, configured to distribute the second key to the client.

[0014] According to a third aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] According to a fourth aspect of this application, a computer-readable storage medium is also provided, on which a computer program or instructions are stored, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0016] According to a fifth aspect of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0017] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0018] Figure 1 The illustrations depict application scenarios of key distribution methods, apparatus, devices, media, and program products according to embodiments of this application.

[0019] Figure 2 A flowchart illustrating a key distribution method according to an embodiment of this application is shown schematically;

[0020] Figure 3 A flowchart illustrating a risk assessment according to an embodiment of this application is shown schematically;

[0021] Figure 4 A flowchart illustrating key association according to an embodiment of this application is shown schematically;

[0022] Figure 5 This schematic diagram illustrates a structural block diagram of a key distribution device according to an embodiment of this application;

[0023] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a key distribution method according to an embodiment of this application. Detailed Implementation

[0024] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0025] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0026] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0027] As used in this paper, the term "model" refers to a system that learns the relationship between inputs and outputs from training data, enabling it to generate corresponding outputs for a given input after training. Model generation can be based on machine learning techniques. Deep learning is a machine learning algorithm that uses multiple layers of processing units to process inputs and provide corresponding outputs. In this paper, "model" may also be referred to as a "machine learning model," "learning model," "machine learning network," or "learning network," and these terms are used interchangeably.

[0028] It should be understood that machine learning generally includes three phases: training, testing, and application (also known as inference). In the training phase, a given model is trained using a large amount of training data, iteratively updating parameter values ​​until the model can consistently generate inferences that meet the expected goals from the training data. Through training, the model can be considered to have learned the relationship between inputs and outputs (also known as the input-output mapping) from the training data. The parameter values ​​of the trained model are determined. In the testing phase, test inputs are applied to the trained model to test whether it can provide the correct output, thus determining the model's performance. In the application phase, the model can be used to process actual inputs based on the trained parameter values ​​to determine the corresponding output.

[0029] In one or more embodiments described herein, the term "large model" can refer to a deep learning model with a large number of model parameters, which can include hundreds of millions, tens of billions, hundreds of billions, trillions, or even tens of trillions of model parameters. Large models can also be called foundational models or basic models. They are pre-trained using large-scale unlabeled corpora to produce pre-trained models with hundreds of millions of parameters. Such models can adapt to a wide range of downstream tasks and have good generalization ability, such as large language models and multimodal pre-trained models. It should be understood that in practical applications, large models only require a small number of samples to fine-tune the pre-trained model before being applied to different tasks. Large models can be widely used in natural language processing, computer vision, and other fields. Specifically, they can be applied to computer vision tasks such as visual question answering, image captioning, and image generation, as well as natural language processing tasks such as text-based sentiment classification, text summarization, and machine translation. Major application scenarios for large models can include digital assistants, intelligent robots, search, online education, office software, e-commerce, and intelligent design.

[0030] Figure 1 The illustrations depict application scenarios of key distribution methods, apparatuses, devices, media, and program products according to embodiments of this application. For example... Figure 1 As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, a user can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 through the network 104 to receive or send information, etc.

[0031] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be electronic devices such as smartphones, wearable devices, personal computers, intelligent voice interaction devices, smart home appliances, intelligent vehicles, in-vehicle terminals, aircraft, unmanned vending terminals, and extended reality devices. Extended reality devices can include virtual reality devices, augmented reality devices, and mixed reality devices. A client application for the target application can be installed and run on the terminal devices. This target application can include, but is not limited to, financial transaction applications, payment applications, shopping applications, web browser applications, search applications, instant messaging tools, email clients, and social media platform software (these are just examples). Furthermore, this application embodiment does not limit the form of the target application, and it can include, but is not limited to, applications, mini-programs, etc., installed on the terminal devices, and can also be in the form of web pages.

[0032] Server 105 can be a server providing various services, such as a backend management server supporting websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process received user requests and other data, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and basic cloud computing services such as big data. The server can be the backend server of the aforementioned target application, used to provide backend services to the clients of the target application.

[0033] It should be noted that the key distribution method provided in this application embodiment can generally be executed by server 105 and / or terminal devices 101-103. Accordingly, the key distribution device provided in this application embodiment can generally be set in server 105 and / or terminal devices 101-103.

[0034] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0035] Figure 2 A flowchart illustrating a key distribution method according to an embodiment of this application is shown schematically. Figure 2 As shown, the key distribution method according to the embodiments of this application may include steps S210 to S250.

[0036] In step S210, in response to the key acquisition request issued by the client, the client's identification information is obtained.

[0037] Identification information is a set of credentials used to uniquely distinguish different clients, which may include pre-assigned application identifiers, affiliated organization codes, and instance numbers.

[0038] In some embodiments, upon receiving a key retrieval request from a client, the request is first parsed and its format validated. Then, an identification field is extracted from the parsed request structure. These identification fields can then be compared with a pre-defined registration list to complete basic identity verification.

[0039] In step S220, the first key and historical feature information corresponding to the client are determined based on the identification information. The historical feature information represents the client's operating information in the past preset time period.

[0040] The primary key refers to the encryption key that is formally bound to the client's identity and should currently be in valid use. Historical feature information is an aggregated and processed quantified dataset that objectively reflects the client's operational status over a defined historical period.

[0041] In some embodiments, the verified client identification information is used as the query key to access the key repository and retrieve the currently active key record, including its ciphertext carrier, algorithm type, and version metadata, i.e., the first key. Simultaneously, all log entries and performance metric snapshots associated with the client identification information are asynchronously acquired; the time range of this raw data is defined by a preset strategy. Subsequently, this raw data can be cleaned and denoised to ultimately generate structured historical feature information.

[0042] In step S230, a risk assessment is performed on the client based on historical feature information to obtain a risk assessment result, which indicates whether the client has any risk.

[0043] Risk assessment here specifically refers to a formalized analytical process aimed at calculating a probabilistic measure of whether a client’s current behavior deviates from its normal baseline or implies a security threat.

[0044] In some embodiments, firstly, the historical feature information dataset obtained in step S220 can be input into a standardized preprocessing module to scale all numerical indicators to a uniform scale for easier model processing. Subsequently, this processed feature vector is fed into a machine learning evaluation model that has been trained on a large amount of historical data. Internally, the model uses its learned parameters and logic to perform nonlinear transformations and weighted calculations on the input features. The model ultimately outputs a quantitative risk assessment result. This result is compared with a pre-configured risk decision threshold to make a binary judgment of whether risk exists, providing a basis for decision-making in subsequent steps.

[0045] In step S240, if the risk assessment result indicates that the client has a risk, a second key with a different key value than the first key is generated.

[0046] The second key refers to the new encryption key that will be generated and used to replace the first key. The fact that its key value is different from the first key means that each bit of the binary value of the second key is generated randomly independently of the old key, rather than being derived from the old key through some function deduction. This ensures the independence and security of the second key.

[0047] In some embodiments, when the client is at risk, a securely certified cryptographic random number generator can be invoked to generate a completely random byte sequence that meets specified length and strength requirements. Then, this byte sequence is encoded and encapsulated according to a predetermined key format specification. Simultaneously, the key management service generates a globally incrementing and unique version identifier and strongly associates this identifier with the encapsulated new key byte sequence. Finally, the second key object is constructed in a secure memory area, and its ciphertext is backed up to persistent storage.

[0048] In step S250, the second key is issued to the client.

[0049] The key distribution method in this application transforms the key update distribution mechanism from being driven by a fixed time period to being driven by the real-time behavioral risks of specific clients. By automatically analyzing the historical operating characteristics of each client, potential threats are accurately identified, and key updates are triggered only for clients with risks. This significantly shortens the effective exposure window of keys under high-risk conditions and improves the system's proactive defense capability against targeted attacks.

[0050] According to an embodiment of this application, determining the first key and historical feature information corresponding to the client based on the identification information includes: performing an association query in a preset key configuration database based on the identification information to determine the first key corresponding to the identification information; extracting the historical operation logs and performance indicators corresponding to the client from a preset operation monitoring database based on the identification information; and aggregating the historical operation logs and performance indicators to obtain historical feature information.

[0051] The default key configuration database is a persistent storage system that records the static mapping between each client identifier and its currently assigned key, as well as metadata such as the key's algorithm and version. The default runtime monitoring database is another independent data storage system that continuously records runtime events and system metrics from all clients. Historical runtime logs record the sequence of operations initiated by clients and their results, while performance metrics include quantitative measurements such as response time and resource utilization. Historical feature information is a standardized dataset representing client behavior patterns, formed by statistically processing the above raw data.

[0052] In some embodiments, firstly, a query request can be initiated to the key configuration database using the verified client identifier as the primary key. After the database performs the retrieval, it returns the complete key record bound to the identifier, and parses out the key content and related attributes from it, confirming it as the first key. Simultaneously, an asynchronous query can be initiated to the runtime monitoring database, submitting the same client identifier and a preset past time range (e.g., the last 24 hours). The runtime monitoring database returns all log entries and metric sampling data generated by the client within this time window. Subsequently, a dedicated data processing module cleans and aggregates this batch of raw data, for example, calculating the request frequency per unit time, average response latency, the occurrence frequency of various error codes, and their changing trends. Finally, a structured, vectorized dataset, i.e., historical feature information, is output.

[0053] The key distribution method in this application embodiment obtains key configuration and runtime data from two functionally separated storage systems, thereby achieving a reliable supply of static identity binding information and dynamic behavioral evidence required for decision-making. This provides an accurate and consistent input basis for subsequent data-driven risk assessment, ensuring the data quality and integrity at the starting point of the entire decision-making process.

[0054] Figure 3 A flowchart illustrating an embodiment of this application is shown schematically. Figure 3 As shown, the key distribution method according to the embodiments of this application may include steps S310 to S330.

[0055] In step S310, the historical feature information is standardized to obtain a standardized feature vector with a unified dimension.

[0056] The purpose of standardization is to eliminate the incomparability caused by differences in units, magnitudes, or value ranges in historical feature information, so that all features are on the same relative scale. The standardized feature vector with uniform dimensions is an ordered list of values ​​obtained after this transformation.

[0057] In some embodiments, upon receiving historical feature information, its integrity is first verified to exclude missing or invalid fields. Next, for each numerical feature column in the historical feature information, a pre-defined standardization algorithm is invoked to calculate the arithmetic mean and standard deviation of all sample values ​​for that feature column. Then, the mean is subtracted from each original value, and the result is divided by the standard deviation, yielding a new value with a mean of 0 and a standard deviation of 1. For features with a limited value range, max-min scaling may be used to linearly transform them to a fixed interval, such as between 0 and 1. After all feature columns have undergone this transformation independently, they are concatenated into a fixed-length array, i.e., the standardized feature vector, in a predefined order.

[0058] In step S320, the standardized feature vector is input into the pre-trained machine learning model to perform risk assessment on the client.

[0059] A pre-trained machine learning model is a program module that has been pre-trained on a large amount of historical data and encapsulates specific mathematical computational logic. This module is able to identify the inherent patterns related to security risks from the input data patterns.

[0060] In some embodiments, once the standardized feature vectors are ready, they can be passed as input parameters to the loaded machine learning model. Internally, the machine learning model performs a series of nonlinear transformations and weighted calculations on the input vectors according to its trained parameters and structure. The core of the machine learning model's computation lies in mapping its input feature combinations to a predefined evaluation dimension.

[0061] In step S330, the risk probability value output by the machine learning model is obtained, and the risk assessment result is determined based on the risk probability value and the preset probability threshold.

[0062] The risk probability value output by the machine learning model is a continuous numerical value between 0 and 1. It quantifies the credibility of the model's assessment that the client's current state poses a risk. The closer the value is to 1, the higher the credibility of the model's assessment of risk. The preset probability threshold is a critical value configured in advance by the system administrator or security policy to make a binary judgment. The risk assessment result is the final output of this stage. It is a clear binary classification conclusion: "risk exists" or "no risk exists." This conclusion directly determines the branching of subsequent processes.

[0063] In some embodiments, the output risk probability value is obtained, and then a probability threshold configured for the current policy or the specific type of client is read. This threshold may be dynamically adjusted according to different security level requirements. A comparison logic is then executed: if the obtained risk probability value is greater than or equal to the preset probability threshold, the judgment condition is met. Based on this comparison result, a deterministic risk assessment result is generated, such as marking the state as having risk. Conversely, if the risk probability value is lower than the threshold, a result indicating no risk is generated. This judgment result is encapsulated as a specific event signal and passed to subsequent key management logic as a key decision-making basis for whether to trigger a key update operation.

[0064] The key distribution method in this application ensures the consistency of the evaluation benchmark through standardization and uses a pre-trained model to replace subjective or simple rule-based judgments. It can identify complex and nonlinear risk patterns, enabling key management decisions to be made based on continuous and accurate risk perception, thereby improving the accuracy and timeliness of security responses.

[0065] According to an embodiment of this application, when the risk assessment result indicates that the client has a risk, generating a second key with a different key value from the first key includes: randomly generating a byte sequence of a preset length; formatting and encoding the byte sequence; and assigning a globally unique key version number to the formatted and encoded byte sequence to obtain the second key.

[0066] In some embodiments, randomly generating a byte sequence of a preset length refers to calling a random number generator that conforms to cryptographic security standards to generate a binary data sequence of a specified length whose statistical characteristics satisfy the requirements of unpredictability and uniform distribution. Formatted encoding refers to structurally encapsulating the original byte sequence according to the system's predefined key storage format specifications, such as adding a header identifier, padding to the standard block length, or converting it to a specific text encoding format. A globally unique key version number is a sequence number or identifier string strongly associated with the key and not repeated within the system, used for unambiguous identification and tracking of the key throughout its entire lifecycle.

[0067] In some embodiments, when a risk assessment confirms the existence of a risk, a key generation instruction is first triggered. The generation process begins by calling a cryptographic random number generation function provided by the underlying security module to request the generation of a raw byte sequence whose length conforms to a predetermined security policy. After obtaining the raw sequence, it is immediately sent to a formatting unit. This unit performs a series of operations on the raw sequence according to the pre-installed format specifications, such as calculating and attaching a checksum, dividing it into several data blocks that meet storage requirements, or converting it from binary to an encoding form that is easy to transmit and store, thereby generating a formatted key data body. At the same time, it also accesses the serial number management service to request a new version number that has not been used within the scope of the service's management. Finally, this globally unique version number is used as metadata and bound and encapsulated with the formatted key data body to form a second key object that can be circulated, stored, and used within the system.

[0068] The key distribution method in this application embodiment ensures the strong randomness and independence of the new key material in cryptography, so that it has no derivation relationship with the old key, thereby ensuring the security of key updates from the source.

[0069] Figure 4 A flowchart illustrating key association according to an embodiment of this application is shown schematically. Figure 4 As shown, the key distribution method according to the embodiments of this application may include steps S410 to S430.

[0070] In step S410, an encrypted communication channel is established, and a key update message is sent to the client through the encrypted communication channel.

[0071] An encrypted communication channel refers to a secure data transmission link established between a key management server and a client through negotiation using standard cryptographic protocols. A key update message is a specific formatted control instruction data packet whose core function is to formally notify the client that a new key is about to be distributed and instruct the client to prepare to receive it.

[0072] In some embodiments, firstly, based on the network address information parsed from the client's identification information, a standard, certificate-based, two-way authentication-based secure connection establishment request is initiated. After both parties complete a protocol handshake, exchange encryption parameters, and verify each other's identities, an encrypted communication channel is established. Subsequently, a key update message is constructed. The payload of this message typically includes a unique serial number for this update transaction, an algorithm type identifier for the new key, and a digest message digitally signed by the server using the client's currently valid key, thereby proving the legitimacy and integrity of the notification. After construction, this message is sent to the client through the established encrypted communication channel. The sending process follows standard data segmentation, encrypted encapsulation, and transmission confirmation mechanisms to ensure accurate delivery of the message.

[0073] In step S420, in response to the first response message received from the client for the key update message, the second key is sent to the client.

[0074] The first response message is an acknowledgment message returned by the client to the server after receiving and verifying the key update message, indicating that the client is ready to receive the new key materials.

[0075] In some embodiments, after sending a key update message, the server enters a waiting state. Upon receiving a first response message, the server first parses the message, verifies whether the transaction serial number matches the sent update notification, and checks the integrity of the message itself. If everything is correct, the server determines that the client is ready. Next, the server retrieves the complete object of the second key from secure storage and performs a final encapsulation before sending. The encapsulation process may include encrypting the second key using the session key of the current encrypted communication channel, or re-signing the second key using the first key to provide additional application-layer security guarantees. After encapsulation, the data packet containing the second key is sent to the client through the encrypted communication channel.

[0076] In step S430, in response to the received second response message indicating that the client has successfully received the second key, the association between the first key and the identification information is released, and the second key is associated with the identification information.

[0077] The second response message is a final success confirmation message returned by the client to the server after successfully receiving, decrypting, and storing the second key locally.

[0078] In some embodiments, after sending the second key, the channel continues to listen for the client's final status feedback. Upon receiving the second response message, the message is parsed and verified to confirm that the key version number specified therein matches the version of the second key issued. This confirmation indicates that the client has fully and correctly obtained the new key. Subsequently, the status of the first key record currently associated with the client identifier and marked as active is updated to historical or invalid, thereby removing its active association. Next, the record status of the second key is set to active, and it is explicitly associated with the client identifier.

[0079] The key distribution method in this application establishes a secure channel and a multi-step confirmation mechanism to ensure the transmission security and end-to-end reliability of sensitive key materials during the distribution process. It ensures that the server and client are strictly synchronized in their understanding of the currently effective key, prevents service interruptions caused by inconsistent states, and achieves reliability and consistency in the key update process.

[0080] According to an embodiment of this application, the key distribution method further includes: distributing the first key to the client when the risk assessment result indicates that the client does not pose a risk.

[0081] In some embodiments, the process enters this branch after a risk assessment is completed and a conclusion is reached that there is no risk. First, the complete record of the first key, strictly bound to the client identifier, is retrieved from storage again, including its key value, algorithm type, and current version number. Then, the complete record of the first key is sent to the client via the established secure communication link. Upon receiving it, the client can verify the version number and other information to confirm that the key it is using is the latest valid version.

[0082] The key distribution method in this application avoids a large number of unnecessary key generation, transmission and replacement operations by only confirming the key status of risk-free clients instead of forcibly updating it. This significantly reduces the overall computing and communication overhead of the system and reduces the risk of business connection reconstruction or temporary service interruption caused by key rotation.

[0083] According to embodiments of this application, historical feature information includes: network latency data, number of authentication failures, and key usage frequency.

[0084] Network latency data refers to the set of measurements of round-trip time for network communication between a client and a server or other critical service nodes over a period of time. Fluctuations in latency can reflect network path stability or the presence of abnormal interference. Authentication failure counts refer to the cumulative number of times a client is rejected by the system during authentication operations due to incorrect credentials or other reasons within the same time period. This is a direct indicator of potential password guessing or credential theft attacks. Key usage frequency refers to the statistical rate at which a client uses its current key to perform encryption, decryption, or signing operations. Abnormally high frequency may indicate key testing behavior, while abnormally low frequency may suggest an abnormal client state.

[0085] In some embodiments, for network latency data, the response timestamps corresponding to each request initiated by the client can be extracted from the monitoring logs, and their average, standard deviation, and recent trend slope can be calculated. For authentication failures, the number of entries returning a specific error code in all login or access token refresh requests from the client within a preset time window can be counted. For key usage frequency, the number of times the client's key is successfully invoked per unit time can be counted by monitoring the key call interface or analyzing the audit logs of the security module. These raw counts or measurements are aggregated (e.g., calculating the average per minute or the cumulative value every five minutes) to form the historical feature information ultimately used for model input.

[0086] The key distribution method in this application anchors the abstract security risk assessment to several key, measurable technical indicators that are strongly correlated with common attack patterns, making the data collection target clear and improving the accuracy of risk identification.

[0087] Based on the above key distribution method, embodiments of this application also provide a key distribution device. The following will be combined with... Figure 5 The device is described in detail.

[0088] Figure 5 A schematic block diagram of a key distribution device according to an embodiment of this application is shown.

[0089] like Figure 5 As shown, the key distribution device 500 of this embodiment includes an identifier acquisition module 510, an information determination module 520, a risk assessment module 530, a key generation module 540, and a key distribution module 550.

[0090] The identifier acquisition module 510 is used to acquire the client's identifier information in response to a key acquisition request issued by the client. In one embodiment, the identifier acquisition module 510 can be used to perform step S210 described above, which will not be repeated here.

[0091] The information determination module 520 is used to determine the first key and historical feature information corresponding to the client based on the identification information. The historical feature information represents the client's operating information within a preset time period in the past. In one embodiment, the information determination module 520 can be used to execute step S220 described above, which will not be repeated here.

[0092] The risk assessment module 530 is used to perform a risk assessment on the client based on historical feature information, and obtain a risk assessment result, which indicates whether the client poses a risk. In one embodiment, the risk assessment module 530 can be used to perform step S230 described above, which will not be repeated here.

[0093] The key generation module 540 is used to generate a second key whose key value is different from the first key when the risk assessment result indicates that the client has a risk. In one embodiment, the key generation module 540 can be used to perform step S240 described above, which will not be repeated here.

[0094] The key distribution module 550 is used to distribute the second key to the client. In one embodiment, the key distribution module 550 can be used to perform step S250 described above, which will not be repeated here.

[0095] According to embodiments of this application, any multiple modules among the acquisition module 510, information determination module 520, risk assessment module 530, key generation module 540, and key distribution module 550 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the acquisition module 510, information determination module 520, risk assessment module 530, key generation module 540, and key distribution module 550 can be at least partially implemented as hardware circuitry, such as field-programmable gate arrays, programmable logic arrays, systems-on-a-chip, systems-on-a-substrate, systems-on-package, application-specific integrated circuits, or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any appropriate combination of any of these three implementation methods. Alternatively, at least one of the acquisition module 510, information determination module 520, risk assessment module 530, key generation module 540, and key distribution module 550 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0096] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a key distribution method according to an embodiment of this application.

[0097] like Figure 6 As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory 602 or a program loaded from a storage portion 608 into a random access memory 603. The processor 601 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0098] Random access memory 603 stores various programs and data required for the operation of electronic device 600. Processor 601, read-only memory 602, and random access memory 603 are interconnected via bus 604. Processor 601 executes various steps of the method flow according to embodiments of this application by executing programs in read-only memory 602 and / or random access memory 603. It should be noted that the programs may also be stored in one or more memories other than read-only memory 602 and random access memory 603. Processor 601 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0099] According to embodiments of this application, the electronic device 600 may further include an input / output interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card, such as a local area network card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0100] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0101] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 602 described above, and / or random access memory 603, and / or one or more memories other than read-only memory 602 and random access memory 603.

[0102] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0103] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0104] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by processor 601, it performs the functions defined in the system of embodiments of this application. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0105] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0106] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0107] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A key distribution method, characterized in that, The method includes: In response to a key acquisition request from a client, the client's identification information is obtained; The first key and historical feature information corresponding to the client are determined based on the identification information, wherein the historical feature information represents the client's operating information within a preset time period in the past. Based on the historical feature information, a risk assessment is performed on the client to obtain a risk assessment result, which indicates whether the client poses a risk. If the risk assessment result indicates that the client has a risk, a second key with a different key value than the first key is generated. The second key is distributed to the client.

2. The method according to claim 1, characterized in that, The step of determining the first key and historical feature information corresponding to the client based on the identification information includes: Based on the identification information, a correlation query is performed in the preset key configuration database to determine the first key corresponding to the identification information; Based on the identification information, extract the historical operation logs and performance indicators corresponding to the client from the preset operation monitoring database; The historical operation logs and performance metrics are aggregated to obtain the historical feature information.

3. The method according to claim 1, characterized in that, The risk assessment of the client based on the historical feature information, and the resulting risk assessment, include: The historical feature information is standardized to obtain a standardized feature vector with a unified dimension. The standardized feature vectors are input into a pre-trained machine learning model to perform risk assessment on the client. Obtain the risk probability value output by the machine learning model, and determine the risk assessment result based on the risk probability value and a preset probability threshold.

4. The method according to claim 1, characterized in that, When the risk assessment result indicates that the client has a risk, generating a second key with a different key value from the first key includes: Randomly generate a byte sequence of a preset length; The byte sequence is formatted and encoded, and a globally unique key version number is assigned to the formatted and encoded byte sequence to obtain the second key.

5. The method according to claim 1, characterized in that, The step of distributing the second key to the client includes: Establish an encrypted communication channel and send a key update message to the client through the encrypted communication channel; In response to the first response message received from the client regarding the key update message, the second key is sent to the client; In response to the client successfully receiving the second response message of the second key, the association between the first key and the identification information is released, and the second key is associated with the identification information.

6. The method according to claim 1, characterized in that, The method further includes: If the risk assessment results indicate that the client poses no risk, the first key will be issued to the client.

7. The method according to claim 1, characterized in that, The historical feature information includes: network latency data, number of authentication failures, and key usage frequency.

8. A key distribution device, characterized in that, The device includes: The identifier acquisition module is used to acquire the identifier information of the client in response to a key acquisition request sent by the client; The information determination module is used to determine the first key and historical feature information corresponding to the client based on the identification information, wherein the historical feature information represents the client's operating information within a preset time period in the past; The risk assessment module is used to perform a risk assessment on the client based on the historical feature information, and obtain a risk assessment result, which indicates whether the client is at risk. The key generation module is used to generate a second key with a different key value from the first key when the risk assessment result indicates that the client has a risk. A key distribution module is used to distribute the second key to the client.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images