A CA certificate UKey sharing scheduling method and system based on an electronic bidding scene

Abstract

The application discloses a CA certificate UKey sharing scheduling method and system based on an electronic bidding scene, relates to the technical field of electronic government affairs, and comprises the following steps: acquiring a bidding process stage and security policy requirements; judging whether the bidding process stage is a CA signature stage or a CA signature verification stage, and generating a UKey scheduling request when the judgment result is yes; acquiring UKey capability portraits corresponding to each logical UKey instance in a logical UKey instance pool, and performing virtualization on a physical UKey device; screening a subset of available logical UKey instances that meet the security policy requirements; selecting a logical UKey instance with an idle state from the subset of available logical UKey instances, binding the logical UKey instance to a session identifier of a current bidding task, and performing a CA signature operation or a CA signature verification operation through the logical UKey instance; judging the bidding process stage, and releasing the logical UKey instance when the judgment result is yes, updating the state of the logical UKey instance to idle, and returning the logical UKey instance to the logical UKey instance pool. The application improves the robustness of sharing scheduling.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of e-government, in particular to a CA certificate UKey sharing scheduling method and system based on an electronic bidding scenario. BACKGROUND

[0002] In recent years, with the deepening of the reform of "Internet + government service" and the electronicization of public resources transactions, electronic bidding systems have been widely popularized in government procurement and engineering construction at all levels across the country. In order to protect the legal effect and identity of the bidding documents, the system generally uses UKey (USB Key) based on CA certificate for digital signature and identity authentication. However, the traditional UKey usage mode requires "one person one Key, local insertion, exclusive use", which leads to the fact that the physical UKey device becomes a system performance bottleneck in the high-concurrency bidding scenario, and it is difficult to meet the growing demand for online bidding. Therefore, some platforms try to introduce remote UKey or USB redirection technology to realize UKey resource sharing, but due to the problems of weak security isolation, inability to concurrency, and rough scheduling strategy, the actual application effect is limited.

[0003] However, the existing technical solutions still have the following outstanding problems: low resource utilization: the physical UKey is idle for a long time in the non-signing stage, and cannot be reused by other tasks, resulting in waste of hardware resources; lack of business awareness in scheduling: the scheduling decision is not linked with the bidding process stage, often occupying UKey in the non-signing stage, or causing bidding failure due to insufficient resources in the key signing stage; poor compatibility of heterogeneous devices: different manufacturers' UKeys support different cryptographic algorithms (such as SM2, RSA) and compliance attributes (such as national cryptography authentication), and the existing system lacks a unified capability description and matching mechanism, which may cause signing failure due to algorithm mismatch; unreliable resource recovery: after the client abnormally exits or the network is interrupted, the UKey resources cannot be automatically released, forming "zombie occupation", which will eventually exhaust the available resources; insufficient timeliness of metadata: after the change of key attributes such as UKey certificate validity period, the system cannot perceive it in time, and may still schedule the devices that will expire soon, affecting the legal effect of signing.

[0004] The above problems directly restrict the concurrency capability, system stability and compliance level of the electronic bidding platform, and an intelligent sharing scheduling method that can deeply integrate business processes, accurately perceive resource capabilities, dynamically schedule and reliably recycle UKey resources is urgently needed. SUMMARY

[0005] In view of the above problems, the present application is proposed.

[0006] Therefore, the present application provides a CA certificate UKey sharing scheduling method and system based on an electronic bidding scenario, which can solve the problems mentioned in the background art.

[0007] To solve the above technical problems, the application provides the following technical solutions:

[0008] In a first aspect, the application provides a CA certificate UKey sharing scheduling method based on an electronic bidding scenario, comprising: obtaining a bidding process stage and a security policy requirement of a current bidding task, wherein the security policy requirement comprises a cryptographic algorithm type requirement and a compliance requirement;

[0009] determining whether the bidding process stage is a CA signature stage or a CA signature verification stage, and generating a UKey scheduling request when the determination result is yes;

[0010] obtaining a UKey capability profile corresponding to each logical UKey instance in a logical UKey instance pool, wherein the logical UKey instance is generated by virtualizing a physical UKey device, and the UKey capability profile comprises a cryptographic algorithm support type, a certificate validity period, a vendor identifier, and a compliance label;

[0011] Based on the matching result of the security policy requirement of the UKey scheduling request and the UKey capability profile, filtering a set of available logical UKey instances that meet the security policy requirement from the logical UKey instance pool;

[0012] selecting a logical UKey instance with an idle state from the set of available logical UKey instances, binding the logical UKey instance to a session identifier of the current bidding task, and performing a CA signature operation or a CA signature verification operation through the logical UKey instance;

[0013] determining whether the bidding process stage is a non-CA signature stage and a non-CA signature verification stage, and releasing the logical UKey instance when the determination result is yes, updating the state of the logical UKey instance to idle, and returning the logical UKey instance to the logical UKey instance pool.

[0014] Preferably, the obtaining of the bidding process stage and the security policy requirement of the current bidding task comprises: receiving a task identifier of the current bidding task;

[0015] querying a bidding business state table according to the task identifier to obtain a bidding process stage associated with the task identifier;

[0016] querying a bidding policy configuration table according to the task identifier to obtain a security policy requirement associated with the task identifier;

[0017] The bidding process stage and the security policy requirement are used as input parameters of the current bidding task.

[0018] Preferably, the generation of the UKey scheduling request comprises:

[0019] parsing the bidding process phase, extracting a phase type field and a phase state validity flag;

[0020] checking whether the phase state validity flag indicates that the bidding process phase is in a valid state;

[0021] if the phase state validity flag indicates that the bidding process phase is in a valid state, determining whether the value of the phase type field is equal to a preset CA signature phase type value or a preset CA verification phase type value;

[0022] if the value of the phase type field is equal to the CA signature phase type value or the CA verification phase type value, querying a UKey scheduling state record of a current bidding task to determine whether there is an unfinished UKey scheduling request;

[0023] if there is no unfinished UKey scheduling request, constructing a UKey scheduling request, wherein the UKey scheduling request includes the task identifier, the security policy requirement, and a scheduling trigger timestamp, and marking the UKey scheduling request as a to-be-processed state.

[0024] Preferably, the virtualization generation includes:

[0025] traversing logical UKey instances in a logical UKey instance pool to obtain a physical UKey device identifier associated with each logical UKey instance;

[0026] querying a physical UKey device metadata table according to the physical UKey device identifier to obtain original capability metadata corresponding to the physical UKey device identifier, wherein the original capability metadata includes a cryptographic algorithm support type, a certificate validity period, and a manufacturer identifier;

[0027] performing compliance evaluation on the original capability metadata based on a preset compliance rule library to generate a compliance label;

[0028] combining the cryptographic algorithm support type, the certificate validity period, the manufacturer identifier, and the compliance label into a structured data object as a UKey capability portrait of the corresponding logical UKey instance;

[0029] binding the UKey capability portrait to the corresponding logical UKey instance and caching to a capability portrait cache area.

[0030] Preferably, when the UKey capability portrait is bound to the corresponding logical UKey instance and cached to the capability portrait cache area, a cache expiration time is calculated according to the certificate validity period.

[0031] and invalidating the UKey capability profile after the cache expiration time arrives, and reacquiring the UKey capability profile.

[0032] As preferred, the screening of the available logical UKey instance subset satisfying the security policy requirement comprises: extracting the security policy requirement from the UKey scheduling request, the security policy requirement comprising a cryptographic algorithm type requirement and a compliance requirement;

[0033] traversing each logical UKey instance of the logical UKey instance pool, and acquiring a UKey capability profile corresponding to each logical UKey instance;

[0034] For each UKey capability profile, it is judged whether the cryptographic algorithm support type of each UKey capability profile contains the cryptographic algorithm type requirement, and whether the compliance label thereof is consistent with the compliance requirement;

[0035] For the logical UKey instance satisfying the cryptographic algorithm type requirement and the compliance requirement, it is further checked whether its current state is idle;

[0036] The logical UKey instances satisfying the security policy requirement and having an idle state are aggregated to form an available logical UKey instance subset.

[0037] As preferred, the performing of the CA signature operation or the CA signature verification operation comprises:

[0038] All logical UKey instances in the available logical UKey instance subset are acquired, and it is verified that the current state of each logical UKey instance is still idle;

[0039] Based on a preset instance selection strategy, a target logical UKey instance is determined from the logical UKey instances whose verified state is idle;

[0040] The state of the target logical UKey instance is updated to occupied, and a binding relationship between the target logical UKey instance and a session identifier of the current bidding task is established;

[0041] According to the bidding process stage, a type of cryptographic operation to be performed is determined, the type of cryptographic operation being a CA signature operation or a CA signature verification operation;

[0042] A cryptographic service interface of the target logical UKey instance is called, and the type of cryptographic operation and to-be-processed data are input, so as to perform the CA signature operation or the CA signature verification operation.

[0043] As preferred, a stage type field value of the bidding process stage is acquired, and it is confirmed that the stage type field value is neither equal to a preset CA signature stage type value nor equal to a preset CA verification stage type value;

[0044] In response to the stage type field value being neither equal to the CA signature stage type value nor equal to the CA verification stage type value, a corresponding logical UKey instance is queried according to a session identifier of the current bidding task;

[0045] It is checked that a current state of the queried logical UKey instance is occupied, and a bound session identifier is consistent with the session identifier of the current bidding task;

[0046] Under the condition that the state of the logical UKey instance is occupied and the session identifier is consistent, the state of the logical UKey instance is updated to be idle, the bound relationship with the session identifier is released, and the logical UKey instance is returned to the logical UKey instance pool.

[0047] As preferred, the returning of the logical UKey instance to the logical UKey instance pool further comprises:

[0048] Before releasing the logical UKey instance, an active time of the bound session is checked;

[0049] If the last active time of the bound session is earlier than the current time minus a preset session timeout threshold, the state of the logical UKey instance is forcibly updated to be idle, and the logical UKey instance is returned to the logical UKey instance pool.

[0050] In a second aspect, the application further provides a CA certificate UKey sharing scheduling system based on an electronic bidding scenario, comprising: a task analysis module, configured to acquire a bidding process stage and a security policy requirement of a current bidding task, wherein the security policy requirement comprises a cryptographic algorithm type requirement and a compliance requirement;

[0051] A scheduling trigger module is configured to determine whether the bidding process stage is a CA signature stage or a CA verification stage, and generate a UKey scheduling request when the determination result is yes;

[0052] A capability profile module is configured to acquire a UKey capability profile corresponding to each logical UKey instance in a logical UKey instance pool, wherein the logical UKey instance is generated by virtualizing a physical UKey device, and the UKey capability profile comprises a cryptographic algorithm support type, a certificate validity period, a vendor identifier, and a compliance label;

[0053] a resource matching module, configured to filter a subset of available logical UKey instances that meet the security policy requirements from the logical UKey instance pool based on a matching result of the security policy requirements of the UKey scheduling request and the UKey capability profile;

[0054] a resource execution module, configured to select a logical UKey instance in an idle state from the subset of available logical UKey instances, bind the logical UKey instance to a session identifier of the current bidding task, and perform a CA signature operation or a CA verification operation through the logical UKey instance;

[0055] a resource recycling module, configured to determine whether the bidding process phase is a non-CA signature phase and a non-CA verification phase, and release the logical UKey instance, update a state of the logical UKey instance to idle, and return the logical UKey instance to the logical UKey instance pool when the determination result is yes.

[0056] The application has the following beneficial effects:

[0057] The application provides a CA certificate UKey sharing scheduling method and system based on an electronic bidding scenario, and systematically solves core bottlenecks such as exclusive occupation of physical UKey resources, weak concurrency capability, and rigid scheduling in the electronic bidding scenario by constructing a closed loop, intelligent, and business-aware CA certificate UKey sharing scheduling system. Specifically, the business semantics is accurately converted into scheduling input by obtaining a bidding process phase and security policy requirements; the accuracy and reliability of scheduling triggering are ensured by phase validity verification and idempotent scheduling request generation; the heterogeneous UKey resources are standardized modeled by constructing a UKey capability profile including a cryptographic algorithm, a certificate validity period, and a compliance label; the metadata timeliness is guaranteed by dynamically setting the profile cache expiration time according to the certificate validity period; in the resource screening stage, the candidate set accuracy is improved by double verification of policy matching and idle state; in the execution stage, the instance is selected and the business operation type is bound based on the preset policy, and the seamless connection of scheduling and cryptographic operation is realized; in the resource recycling link, not only is the release timing determined according to the process phase exit, but also a session timeout forced recycling mechanism is introduced to effectively manage the resource retention caused by zombie sessions. The above steps work together to enable a single physical UKey to safely and compliantly serve multiple bidding tasks, significantly improve the resource utilization and system concurrency capability without changing the existing CA system and hardware, ensure algorithm compatibility, certificate validity, and operation compliance, and fully support the electronic bidding business requirements of high concurrency, high security, and strong supervision, which has outstanding technical progress and significant industrial application value. BRIEF DESCRIPTION OF DRAWINGS

[0058] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the drawings needed to be used in the description of the embodiments of the present application or the related art will be briefly introduced. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other related drawings can also be obtained without creative labor.

[0059] Figure 1 is a whole flowchart of a CA certificate UKey sharing scheduling method based on an electronic bidding scenario related to the present application;

[0060] Figure 2 is a method flowchart of a CA certificate UKey sharing scheduling method based on an electronic bidding scenario related to the present application;

[0061] Figure 3 is a computer device diagram of a CA certificate UKey sharing scheduling method based on an electronic bidding scenario related to the present application. DETAILED DESCRIPTION

[0062] In order to make the purpose, technical solutions and advantages of the present application more clear, the present application will be further described in detail below in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not to limit the present application.

[0063] In an exemplary embodiment, as shown in Figure 1 , a CA certificate UKey sharing scheduling method based on an electronic bidding scenario is provided, wherein:

[0064] S100: Obtain the bidding process stage and security policy requirement of the current bidding task, and the security policy requirement includes the password algorithm type requirement and the compliance requirement;

[0065] Specifically, step S100 is implemented by the following steps, including:

[0066] S110: Receive the task identifier of the current bidding task;

[0067] In an optional embodiment, the task identifier is assigned by a task management module of the electronic bidding platform and is transmitted to the UKey sharing scheduling module through an inter-process communication interface, and the task identifier is a globally unique numerical identifier.

[0068] In an optional embodiment, the task identifier is generated by splicing a timestamp and a random number, and the electronic bidding platform generates the task identifier when a user clicks the "initiate CA signature" button and writes it into a bidding task control block, and the UKey sharing scheduling module obtains the task identifier by reading the bidding task control block.

[0069] In an optional embodiment, the UKey sharing scheduling module subscribes to the bidding operation event stream of the electronic bidding platform, extracts the task identifier from the event payload after listening to the "signature task creation" event; the event payload also includes the operation user ID and the project code, and the task identifier is uniquely determined by the platform core service based on a distributed ID generation algorithm when the event is generated.

[0070] S120: Query the bidding business status table according to the task identifier to obtain the bidding process phase associated with the task identifier;

[0071] In an optional embodiment, the bidding business status table is a data table in a relational database, and the UKey sharing scheduling module returns the corresponding bidding process phase field value by using a SQL statement with the task identifier as the query condition.

[0072] In an optional embodiment, the bidding business status table is stored in an in-memory database, and the table structure includes three fields: task identifier, bidding process phase, and last update time; the UKey sharing scheduling module calls a status query service interface, inputs the task identifier, and returns the bidding process phase by the status query service interface.

[0073] In an optional embodiment, the bidding business status table is maintained by the bidding business engine in real time, and whenever the bidding task state changes, the business engine synchronously updates the bidding process phase associated with the task identifier in the bidding business status table; the UKey sharing scheduling module initiates the query within 100 milliseconds after receiving the task identifier, to ensure that the obtained bidding process phase is the latest state.

[0074] S130: Query the bidding strategy configuration table according to the task identifier to obtain the security policy requirement associated with the task identifier;

[0075] In an optional embodiment, the bidding strategy configuration table is a key-value storage structure managed by the configuration center, the key is the task identifier, and the value is the security policy requirement in JSON format; the UKey sharing scheduling module reads the security policy requirement by the configuration center client.

[0076] In an optional embodiment, the bidding strategy configuration table is initialized when the bidding project is created, the project-level security policy is copied as a task-level strategy and associated with the task identifier; the security policy requirement includes the password algorithm type requirement and the compliance requirement; the UKey sharing scheduling module obtains the structured security policy requirement by calling the strategy parsing module.

[0077] In an alternative embodiment, the bidding policy configuration table supports a dynamic override mechanism, when a user manually selects a CA certificate type before submitting a bidding file, the system updates the user's selection result to the record associated with the task identifier in the bidding policy configuration table; the security policy requirement obtained by the UKey sharing scheduling module when querying contains the user-defined password algorithm type requirement.

[0078] S140: Taking the bidding process phase and the security policy requirement as input parameters of the current bidding task for use in subsequent scheduling steps;

[0079] In an alternative embodiment, the UKey sharing scheduling module encapsulates the bidding process phase and the security policy requirement into a scheduling context object, and passes the scheduling context object to the scheduling decision engine as an input parameter for executing UKey resource matching.

[0080] In an alternative embodiment, the scheduling context object contains three fields of task identifier, bidding process phase, and security policy requirement, the UKey sharing scheduling module creates the scheduling context object in memory, and stores it in the scheduling task queue, which is taken out by the scheduling worker thread from the scheduling task queue and executed in subsequent steps.

[0081] In an alternative embodiment, the UKey sharing scheduling module assigns a unique scheduling session ID to the scheduling context object after generating it, and caches the scheduling context object to the session storage area; the bidding process phase and the security policy requirement are accessed through the scheduling session ID in subsequent steps, ensuring the consistency and traceability of input parameters in the scheduling process.

[0082] S200: Judging whether the bidding process phase is a CA signature phase or a CA signature verification phase, and generating a UKey scheduling request when the judgment result is yes;

[0083] Specifically, step S200 is implemented through the following steps, including:

[0084] S210: Parsing the bidding process phase to extract the stage type field and the stage state validity flag;

[0085] In an alternative embodiment, the bidding process phase is stored in JSON format, and the UKey sharing scheduling module reads the bidding process phase through a JSON parser, and extracts the stage type field with the field name of "stage_type" and the stage state validity flag with the field name of "is_valid" therefrom.

[0086] In an optional embodiment, the bidding process stage is passed by the bidding service engine in a Protobuf serialization format, the UKey sharing scheduling module calls a predefined StageInfo message parsing interface, and a structured object is obtained after deserialization, from which the stage type field and the stage state validity flag are obtained.

[0087] In an optional embodiment, the stage type field is of an enumeration type, and the values include "DRAFT", "CA_SIGN", "CA_VERIFY", "UPLOAD", and "SUBMIT"; the stage state validity flag is a Boolean type field, which is automatically set by the bidding service engine according to business rules at each state transition, and the UKey sharing scheduling module immediately performs field extraction operations after receiving the bidding process stage, to ensure that the subsequent judgment is based on the latest data.

[0088] S220: Verify whether the stage state validity flag indicates that the bidding process stage is in a valid state;

[0089] In an optional embodiment, the stage state validity flag is a Boolean value, and when the value is true, it is determined that the bidding process stage is in a valid state; and when the value is false, the current scheduling process is terminated.

[0090] In an optional embodiment, the UKey sharing scheduling module compares the stage state validity flag with a preset valid state threshold, the preset valid state threshold is a logical true value, and if the two are equal, it is determined that the bidding process stage is in a valid state.

[0091] In an optional embodiment, the stage state validity flag is dynamically updated by the bidding service engine according to the bidding deadline: if the current system time exceeds the bidding deadline, the stage state validity flag is automatically set to false; and the UKey sharing scheduling module, when verifying, only determines that the bidding process stage is in a valid state when the stage state validity flag is true and the current system time does not exceed the bidding file locking time window.

[0092] S230: Under the condition that the stage state validity flag indicates that the bidding process stage is in a valid state, it is determined whether the value of the stage type field is equal to a preset CA signature stage type value or a preset CA signature verification stage type value;

[0093] In an optional embodiment, the preset CA signature stage type value is a string "CA_SIGN", and the preset CA signature verification stage type value is a string "CA_VERIFY"; the UKey sharing scheduling module determines whether the stage type field is equal to any of the preset values through string exact matching.

[0094] In an alternative embodiment, the preset CA signature phase type value and the preset CA verification phase type value are stored in a system constant configuration table, and the UKey sharing scheduling module loads the system constant configuration table during initialization and reads the preset values from the memory during runtime for comparison.

[0095] In an alternative embodiment, the phase type field is an integer enumeration code, the preset CA signature phase type value is an integer 101, and the preset CA verification phase type value is an integer 102; the UKey sharing scheduling module performs integer equality judgment, and if the value of the phase type field is equal to 101 or 102, it is determined that the condition is met, and the matching result is recorded to the scheduling context buffer area.

[0096] S240: Under the condition that the value of the phase type field is equal to the CA signature phase type value or the CA verification phase type value, the UKey scheduling state record of the current bidding task is queried to confirm whether there is an unfinished UKey scheduling request;

[0097] In an alternative embodiment, the UKey scheduling state record is stored in a scheduling state database table, and the table structure includes a task identifier, a scheduling request ID, and a request state field; the UKey sharing scheduling module uses the task identifier as a query key to search whether there is a record with the request state field being “PENDING” or “PROCESSING”.

[0098] In an alternative embodiment, the UKey scheduling state record is maintained by a distributed cache system, and the UKey sharing scheduling module queries the scheduling state object with the task identifier as the key through a cache client; if the object exists and its state attribute is not equal to “COMPLETED” or “CANCELLED”, it is determined that there is an unfinished UKey scheduling request.

[0099] In an alternative embodiment, the UKey scheduling state record includes a request creation timestamp, and the UKey sharing scheduling module simultaneously checks whether the request creation timestamp is earlier than the current time minus a preset timeout threshold (for example, 30 seconds) during the query; if there is an unfinished request but it has timed out, its state is automatically marked as “EXPIRED” and considered as not having a valid unfinished request, thereby allowing a new request to be generated.

[0100] S250: Under the condition that there is no unfinished UKey scheduling request, a UKey scheduling request is constructed, the UKey scheduling request includes a task identifier, a security policy requirement, and a scheduling trigger timestamp, and the UKey scheduling request is marked as a to-be-processed state;

[0101] In an optional embodiment, the UKey scheduling request is a structured data object, and the UKey shared scheduling module calls a scheduling request constructor to pass in the task identifier, security policy requirement, and current system time as the scheduling trigger timestamp, generates the UKey scheduling request, and sets its initial state as "to be processed".

[0102] In an optional embodiment, the UKey scheduling request is published in a message queue producer mode, and the UKey shared scheduling module serializes the task identifier, security policy requirement, and scheduling trigger timestamp into an AMQP message body, sets the state field in the message attribute as "to be processed", and then delivers it to the UKey scheduling task queue.

[0103] In an optional embodiment, the scheduling trigger timestamp adopts the UTC nanosecond timestamp format, the UKey scheduling request is written into the scheduling log audit table immediately after being built, and the UKey scheduling state record is updated synchronously, setting the scheduling state corresponding to the task identifier as "to be processed", to ensure that the subsequent steps can be implemented through state query to achieve idempotent scheduling and fault recovery.

[0104] S300: Obtain the UKey capability profile corresponding to each logical UKey instance in the logical UKey instance pool, which is generated by virtualizing a physical UKey device, and the UKey capability profile includes the password algorithm support type, certificate validity period, vendor identifier, and compliance label;

[0105] Specifically, step S300 is implemented through the following steps, including:

[0106] S310: Traverse all logical UKey instances in the logical UKey instance pool, and obtain the physical UKey device identifier associated with each logical UKey instance;

[0107] In an optional embodiment, the logical UKey instance pool is a hash table structure in memory, the key is the logical UKey instance identifier, and the value is the logical UKey instance object; the UKey shared scheduling module traverses the hash table through an iterator, reads the member variable "physical_device_id" from each logical UKey instance object as the physical UKey device identifier.

[0108] In an optional embodiment, each logical UKey instance is written with its corresponding physical UKey device identifier by the virtualization manager when created, and stored in the instance metadata field; after the UKey shared scheduling module calls the "get_all_instances" interface of the instance pool and returns the instance list, the physical UKey device identifier of each instance is extracted in turn.

[0109] In an optional embodiment, the logical UKey instance pool is deployed in a distributed scheduling node, and the UKey sharing scheduling module sends a "ListLogicalInstances" request to the virtualization agent service through a gRPC protocol, and the response message contains each logical UKey instance and its associated physical UKey device identifier; the UKey sharing scheduling module parses the response message to complete traversal and extraction.

[0110] S320: According to the physical UKey device identifier, query the physical UKey device metadata table to obtain the original capability metadata corresponding to the physical UKey device identifier, and the original capability metadata includes the cryptographic algorithm support type, the certificate validity period, and the manufacturer identifier;

[0111] In an optional embodiment, the physical UKey device metadata table is a data table in a relational database, and contains fields: physical UKey device identifier, cryptographic algorithm support type, certificate validity period, and manufacturer identifier; the UKey sharing scheduling module executes a SQL query statement with the physical UKey device identifier as the WHERE condition to return the corresponding original capability metadata.

[0112] In an optional embodiment, the physical UKey device metadata table is maintained by a device registration center, and the UKey sharing scheduling module transmits the physical UKey device identifier through a RESTful API interface to receive a JSON format response and parse out the cryptographic algorithm support type, the certificate validity period, and the manufacturer identifier.

[0113] In an optional embodiment, the original capability metadata is automatically collected through a device self-description protocol (such as a USB HID descriptor extension) when the physical UKey device first accesses the system, and is persistently stored; when the UKey sharing scheduling module queries, if it is found that the certificate validity period is less than 7 days from the current time, the "about to expire" state is marked in the returned original capability metadata, but the field structure is not changed.

[0114] S330: Based on a preset compliance rule library, the original capability metadata is subjected to compliance evaluation to generate a compliance label;

[0115] In an optional embodiment, the compliance rule library is stored in a configuration center, and contains multiple rule items, each rule item defining the mapping relationship between the cryptographic algorithm support type and the compliance label; the UKey sharing scheduling module matches the cryptographic algorithm support type with the rule item to output the corresponding compliance label.

[0116] In an optional embodiment, the compliance rule base includes a rule: if the password algorithm support type contains SM2 and the vendor identifier belongs to the list of certified vendors of the National Cryptographic Administration, the compliance label is "national standard compliance"; otherwise, if the password algorithm support type contains RSA and the certificate validity period is within the validity period, the compliance label is "international standard compliance"; otherwise, the compliance label is "non-compliant".

[0117] In an optional embodiment, the compliance rule base supports dynamic hot updating, and the UKey sharing scheduling module loads the latest version of the compliance rule base from the rule engine before each execution of the compliance evaluation; the evaluation process is performed through the rule matching engine, and a structured compliance label is output, and the rule version number is recorded to the audit log.

[0118] S340: Combine the password algorithm support type, the certificate validity period, the vendor identifier, and the compliance label into a structured data object as a UKey capability profile of the corresponding logical UKey instance;

[0119] In an optional embodiment, the UKey capability profile is a message type UKeyCapabilityProfile defined by Protocol Buffers, containing fields: algorithm_types (string list), cert_expiry (timestamp), vendor_id (string), compliance_tag (string); the UKey sharing scheduling module calls the constructor and inputs the password algorithm support type, the certificate validity period, the vendor identifier, and the compliance label to generate the UKey capability profile.

[0120] In an optional embodiment, the structured data object is serialized in JSON format, and the field names are "algorithm_support", "cert_valid_until", "vendor_identifier", and "compliance_label" respectively; the UKey sharing scheduling module fills in each metadata value according to the field mapping to form a complete UKey capability profile.

[0121] In an optional embodiment, the UKey capability profile is attached with the logical UKey instance identifier and the generation timestamp when it is built, which is used for subsequent version tracking; the structured data object exists in the form of an immutable object in memory to prevent accidental modification during the scheduling process.

[0122] S350: Bind the UKey capability profile to the corresponding logical UKey instance and cache it to the capability profile cache area for subsequent scheduling matching step calls;

[0123] In an optional embodiment, the capability profile cache is a local memory cache with LRU eviction policy; the UKey sharing scheduling module stores the UKey capability profile into the cache with logical UKey instance identifier as key and UKey capability profile as value, and establishes a binding relationship.

[0124] In an optional embodiment, the capability profile cache is a distributed cache cluster, and the UKey sharing scheduling module executes a SET command through a Redis client, with the key name being "ukey_profile:{logical_instance_id}" and the value being the serialized byte stream of the UKey capability profile, to realize cross-node shared access.

[0125] In an optional embodiment, the cache validity period of the UKey capability profile is set to 10% of the remaining time of the certificate validity period or 300 seconds (whichever is smaller); the UKey sharing scheduling module sets the expiration time when writing to the cache, to ensure that the UKey capability profile is automatically invalidated when the certificate is about to expire, triggering the next S300 reacquisition, and guaranteeing the timeliness and accuracy of the scheduling decision.

[0126] S400: Based on the matching result of the security policy requirement of the UKey scheduling request and the UKey capability profile, filtering a set of available logical UKey instances from the logical UKey instance pool that meet the security policy requirement;

[0127] Specifically, step S400 is implemented through the following steps, including:

[0128] S410: Extracting the security policy requirement from the UKey scheduling request, including the cryptographic algorithm type requirement and the compliance requirement;

[0129] In an optional embodiment, the UKey scheduling request is a JSON format data object, and the UKey sharing scheduling module obtains the security policy requirement by parsing the field "security_policy", wherein the field value of "algorithm_requirement" is the cryptographic algorithm type requirement, and the field value of "compliance_requirement" is the compliance requirement.

[0130] In an optional embodiment, the UKey scheduling request is a predefined scheduling request structure, and the UKey sharing scheduling module directly accesses the member variables security_policy.algorithm_type_req and security_policy.compliance_req to obtain the cryptographic algorithm type requirement and the compliance requirement, respectively.

[0131] In an optional embodiment, the password algorithm type requirement is a string set, containing "SM2" or "RSA2048"; the compliance requirement is an enumeration value, taking values including "national standard compliance" and "international standard compliance"; the UKey sharing scheduling module performs format checking on the security policy requirement after extraction, and if the field is missing or the type is incorrect, the scheduling process is terminated and an exception log is recorded.

[0132] S420: Traverse each logical UKey instance in the logical UKey instance pool to obtain the UKey capability profile corresponding to each logical UKey instance;

[0133] In an optional embodiment, the logical UKey instance pool is a mapping table in memory, the key is the logical UKey instance identifier, and the value is the logical UKey instance object; the UKey sharing scheduling module traverses the mapping table through an iterator and calls the get_capability_profile() method of each logical UKey instance object to return the corresponding UKey capability profile.

[0134] In an optional embodiment, the UKey capability profile is stored in a distributed cache system, the UKey sharing scheduling module obtains a list of all logical UKey instance identifiers in the logical UKey instance pool, and batch calls the mget interface of the cache client to obtain all corresponding UKey capability profiles at once with the logical UKey instance identifier as the key.

[0135] In an optional embodiment, the UKey sharing scheduling module skips logical UKey instances in the "fault" or "maintenance" state when traversing, and only attempts to obtain the UKey capability profile for instances in the "idle" or "occupied but preemptable" state, to reduce invalid matching calculation overhead.

[0136] S430: For each UKey capability profile, determine whether its password algorithm support type contains the password algorithm type requirement and whether its compliance label is consistent with the compliance requirement;

[0137] In an optional embodiment, the password algorithm support type is a string list, and the UKey sharing scheduling module checks whether the password algorithm type requirement is an element in the string list; at the same time, it compares whether the compliance label field in the UKey capability profile is completely equal to the compliance requirement field.

[0138] In an optional embodiment, the password algorithm type requirement is "SM2", and the UKey sharing scheduling module calls the set of judgment functions contains(algorithm_support_list, "SM2"); the compliance requirement is "national secret compliance", and the string exact match compliance_tag.equals("national secret compliance") is executed. Both are true, and the judgment condition is established.

[0139] In an optional embodiment, the UKey sharing scheduling module matches the password algorithm type requirement with the password algorithm support type in a many-to-many manner: if the password algorithm type requirement contains multiple algorithms (such as ["SM2", "SM9"]), the password algorithm support type is required to contain at least one of them; the compliance tag is matched with the compliance requirement, and an alias mapping table is supported, for example, "GM_Compliant" is mapped to "national secret compliance" to be compatible with multiple manufacturer tag formats.

[0140] S440: For the logical UKey instance that meets the password algorithm type requirement and the compliance requirement, further check whether its current state is idle;

[0141] In an optional embodiment, each logical UKey instance contains a state field, and the value includes "idle", "occupied", and "fault"; the UKey sharing scheduling module reads the state field, and only when the value is equal to "idle", it is determined that the logical UKey instance is available.

[0142] In an optional embodiment, the state field is stored in the runtime context of the logical UKey instance, and the UKey sharing scheduling module obtains the real-time state by calling the state query interface get_current_state() of the instance, and compares the value with the preset idle state constant.

[0143] In an optional embodiment, the UKey sharing scheduling module synchronously checks the session timeout when checking the state: if a logical UKey instance is in the "occupied" state, but the last active timestamp of its bound session is earlier than the current time minus the preset session timeout threshold (such as 60 seconds), it is forced to reset its state to "idle" and included in the available candidate range.

[0144] S450: Aggregate the logical UKey instances whose state is idle and meet the security policy requirements to form a set of available logical UKey instances;

[0145] In an optional embodiment, the UKey sharing scheduling module initializes an empty list, and adds the logical UKey instances that pass the double checks of S430 and S440 to the list one by one, and finally takes the list as the set of available logical UKey instances.

[0146] In an optional embodiment, the available logical UKey instance subset is stored in a Set data structure, ensuring no duplicate instances; the UKey sharing scheduling module sorts the available logical UKey instance subset in ascending order according to the response delay history value of the logical UKey instance after aggregation is completed, providing priority basis for subsequent selection.

[0147] In an optional embodiment, the available logical UKey instance subset is encapsulated as a scheduling candidate object and attached with meta information, including subset generation timestamp, matching strategy version number, and instance number; the scheduling candidate object is written into the scheduling context for direct reference in subsequent steps, ensuring data consistency and traceability of the scheduling decision chain.

[0148] S500: Select a logical UKey instance with an idle state from the available logical UKey instance subset, bind the logical UKey instance to the session identifier of the current bidding task, and perform CA signature or CA verification operation through the logical UKey instance;

[0149] Specifically, step S500 is implemented through the following steps, including:

[0150] S510: Obtain all logical UKey instances in the available logical UKey instance subset and verify that the current state of each logical UKey instance is still idle;

[0151] In an optional embodiment, the UKey sharing scheduling module iterates through each logical UKey instance in the available logical UKey instance subset, reads its runtime state field, and if the value of the state field is equal to the preset idle state constant, it is determined that the current state of the logical UKey instance is still idle.

[0152] In an optional embodiment, the state of each logical UKey instance is uniformly maintained by a distributed state service, and the UKey sharing scheduling module queries the latest state of each instance in the available logical UKey instance subset through a state service client, and filters out a list of instances with a state value of "idle".

[0153] In an optional embodiment, the verification process includes timestamp verification: if the state update timestamp of a logical UKey instance is earlier than the current system time minus a preset state invalidation window (e.g., 500 milliseconds), it is considered to be an untrusted state, even if its state field is "idle", it is excluded from the valid candidate, to avoid resource conflicts caused by state synchronization delay.

[0154] S520: Determine the target logical UKey instance from the logical UKey instances with an idle state based on the preset instance selection strategy;

[0155] In an optional embodiment, the preset instance selection strategy is a round-robin strategy, the UKey sharing scheduling module maintains a round-robin pointer, and each time selects the next instance as the target logical UKey instance according to the pointer position in the list of logical UKey instances in the verified idle state, and updates the round-robin pointer.

[0156] In an optional embodiment, the preset instance selection strategy is a performance priority strategy, the UKey sharing scheduling module sorts the instances in the verified idle state in ascending order according to the historical average response delay of each logical UKey instance, and selects the first instance in the order as the target logical UKey instance.

[0157] In an optional embodiment, the preset instance selection strategy supports dynamic switching, and the strategy type is delivered by the scheduling configuration center; if the strategy type is "nearest scheduling", the UKey sharing scheduling module selects the idle instance with the lowest network delay as the target logical UKey instance in combination with the IP address of the current bidding task initiator and the network topology distance of each logical UKey instance from the physical node.

[0158] S530: updating the state of the target logical UKey instance to occupied, and establishing a binding relationship between the target logical UKey instance and the session identifier of the current bidding task;

[0159] In an optional embodiment, the UKey sharing scheduling module calls the interface of the state management module, updates the state field of the target logical UKey instance to "occupied", and inserts a record in the binding relationship table, which contains the identifier of the target logical UKey instance and the session identifier of the current bidding task.

[0160] In an optional embodiment, the binding relationship is stored in the form of key-value pair in the in-memory database, the key is the session identifier of the current bidding task, and the value is the identifier of the target logical UKey instance; at the same time, the reverse index key is the identifier of the target logical UKey instance, and the value is the session identifier, supporting bidirectional fast query.

[0161] In an optional embodiment, the state updating and binding operations are executed in the same distributed transaction, and if any operation fails, all changes are rolled back to ensure system state consistency; after the transaction is successfully committed, a resource binding event is generated and published to the audit message queue for subsequent monitoring and fault recovery.

[0162] S540: determining the type of password operation to be executed according to the bidding process stage, and the password operation type is CA signature operation or CA signature verification operation;

[0163] In an optional embodiment, the UKey sharing scheduling module compares the phase type field value of the bidding process phase: if equal to "CA_SIGN", the password operation type is determined as a CA signature operation; if equal to "CA_VERIFY", the password operation type is determined as a CA signature verification operation.

[0164] In an optional embodiment, the password operation type is determined through a mapping table, which is stored in a configuration file, and the content is { "CA_SIGN": "SIGN", "CA_VERIFY": "VERIFY"}; the UKey sharing scheduling module queries the mapping table according to the bidding process phase, and outputs the corresponding password operation type.

[0165] In an optional embodiment, the UKey sharing scheduling module checks the integrity of the to-be-processed data while determining the password operation type: if it is a CA signature operation, it checks whether the to-be-signed data hash value exists; if it is a CA signature verification operation, it verifies whether the digital signature field is non-empty, and only after the verification is passed, it is allowed to enter the execution phase.

[0166] S550: Call the password service interface of the target logical UKey instance, input the to-be-processed data and the password operation type, and execute the CA signature operation or the CA signature verification operation;

[0167] In an optional embodiment, the target logical UKey instance encapsulates a password service proxy object, and the UKey sharing scheduling module calls the execute_crypto_operation(operation_type, input_data) method thereof, inputs the password operation type and the to-be-processed data, and forwards them to the underlying physical UKey device for execution by the proxy object.

[0168] In an optional embodiment, the password service interface is a gRPC remote service, and the UKey sharing scheduling module sends an encrypted gRPC request to the virtualization agent node to which the target logical UKey instance belongs, the request body containing the password operation type, the to-be-processed data and the session token, and the agent node verifies the token and then calls the local UKey driver to complete the operation.

[0169] In an optional embodiment, the execution process includes timeout control: the UKey sharing scheduling module starts a timer, and if the operation result is not received within a preset time limit (such as 10 seconds), the call is terminated, the target logical UKey instance is released, and an operation timeout exception is recorded; the operation result includes the signature value or the signature verification boolean result, and is returned to the bidding business engine.

[0170] S600: judging whether the bidding process phase is a non-CA signature phase and a non-CA verification phase, and releasing the logical UKey instance, updating the state of the logical UKey instance to idle, and returning the logical UKey instance to the logical UKey instance pool when the judgment result is yes.

[0171] Specifically, step S600 is implemented by the following steps, including:

[0172] S610: obtaining the phase type field value of the bidding process phase, and confirming that the phase type field value is neither equal to the preset CA signature phase type value nor equal to the preset CA verification phase type value;

[0173] In an optional embodiment, the bidding process phase is stored in the form of a structured object, the UKey sharing scheduling module reads the "stage_type" field as the phase type field value, and performs inequality comparison with the string constants "CA_SIGN" and "CA_VERIFY" respectively, and if the comparison results of the two times are both true, it is confirmed that the condition is established.

[0174] In an optional embodiment, the preset CA signature phase type value and the preset CA verification phase type value are stored in the system enumeration class StageTypeEnum, and the UKey sharing scheduling module calls the compare method of the enumeration to judge that the phase type field value does not belong to the {StageTypeEnum.CA_SIGN, StageTypeEnum.CA_VERIFY} set.

[0175] In an optional embodiment, the confirmation operation is executed in the callback function of the bidding business state listener, and when the "process phase change" event is received, the new phase type field value is contained in the event payload, and the scheduling module immediately performs double inequality judgment to avoid resource retention caused by polling delay.

[0176] S620: in response to the phase type field value being neither equal to the CA signature phase type value nor equal to the CA verification phase type value, querying the corresponding logical UKey instance according to the session identifier of the current bidding task;

[0177] In an optional embodiment, the UKey sharing scheduling module accesses the session-resource binding mapping table, takes the session identifier of the current bidding task as the key, performs hash search, returns the corresponding logical UKey instance identifier, and loads the logical UKey instance through the instance factory.

[0178] In an optional embodiment, the binding relationship is stored in a distributed cache system, the key format is "session:{session_id}", and the value is the logical UKey instance identifier; the UKey shared scheduling module calls the get interface of the cache client, inputs the key constructed by the session identifier, and obtains the logical UKey instance by analyzing the return value.

[0179] In an optional embodiment, if the corresponding logical UKey instance is not queried according to the session identifier, the "resource unbinding" audit log is recorded and the release process is terminated; this case may be caused by abnormal termination of a task or repeated triggering of release, and the system does not regard it as an error, but needs to be recorded for operation and maintenance analysis.

[0180] S630: Check that the current state of the queried logical UKey instance is occupied, and that the session identifier bound by the logical UKey instance is consistent with the session identifier of the current bidding task.

[0181] In an optional embodiment, the logical UKey instance includes a state field and a bound session field, the UKey shared scheduling module reads the state field, judges that the value is equal to "occupied", reads the bound session field, and judges that the value is completely same as the session identifier of the current bidding task.

[0182] In an optional embodiment, the check operation is executed in a database transaction: when querying the logical UKey instance record, the WHERE condition status = 'occupied' AND bound_session_id =? is added, and if the number of returned records is 1, the check passes; otherwise, it is regarded as a check failure.

[0183] In an optional embodiment, the check process includes a time window check: if the binding timestamp of the logical UKey instance is earlier than the current time minus the maximum session validity period (such as 300 seconds), even if the state is "occupied", it is regarded as invalid binding, the check result is inconsistent, and the zombie session is prevented from blocking resource recycling.

[0184] S640: Under the condition that the state of the logical UKey instance is occupied and the session identifier is consistent, the state of the logical UKey instance is updated to idle, the binding relationship between the logical UKey instance and the session identifier is released, and the logical UKey instance is returned to the logical UKey instance pool.

[0185] In an optional embodiment, the UKey shared scheduling module calls the release method of the resource manager, inputs the logical UKey instance identifier and the session identifier; the resource manager internally executes: sets the state field to "idle", clears the bound session field, and re-adds the instance identifier to the available queue of the logical UKey instance pool.

[0186] In an alternative embodiment, the update, unbind and return operations are completed in the same atomic transaction: if any sub-operation fails, the entire transaction is rolled back, ensuring system state consistency; after the transaction is successfully committed, a "UKey instance release" event is published to the message bus for the monitoring module to subscribe.

[0187] In an alternative embodiment, the return operation includes a capability profile refresh trigger: if the logical UKey instance corresponds to a physical UKey device whose certificate validity period has been updated after the last use, its capability profile is marked as "to be refreshed" at the time of return, and the next time S300 is executed, the metadata is preferentially re-collected, ensuring the accuracy of subsequent scheduling decisions.

[0188] It should be understood that, although each step in the flowchart involved in each of the above embodiments is shown in sequence according to the direction of the arrow, these steps are not necessarily executed in the order indicated by the arrow. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least some of the steps in the flowchart involved in each of the above embodiments can include multiple steps or stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily sequential, but can be alternately executed with at least some of the other steps or steps or stages in other steps.

[0189] Based on the same inventive concept, the embodiments of the present application also provide a CA certificate UKey sharing scheduling system based on an electronic bidding scenario. The implementation scheme for solving the problem provided by the system is similar to the implementation scheme described in the above method, so the specific limitations in one or more CA certificate UKey sharing scheduling system embodiments based on an electronic bidding scenario provided below can be referred to the limitations of the CA certificate UKey sharing scheduling method based on an electronic bidding scenario in the above, which will not be repeated here.

[0190] In an exemplary embodiment, a CA certificate UKey sharing scheduling system based on an electronic bidding scenario is provided, comprising:

[0191] A task analysis module is configured to obtain a bidding process stage and a security policy requirement of a current bidding task, wherein the security policy requirement includes a cryptographic algorithm type requirement and a compliance requirement;

[0192] A scheduling trigger module is configured to determine whether the bidding process stage is a CA signature stage or a CA signature verification stage, and generate a UKey scheduling request when the determination result is yes.

[0193] The capability profile module is configured to acquire a UKey capability profile corresponding to each logical UKey instance in a logical UKey instance pool, the logical UKey instance being generated by virtualizing a physical UKey device, and the UKey capability profile including a cryptographic algorithm support type, a certificate validity period, a vendor identifier, and a compliance label.

[0194] The resource matching module is configured to filter a subset of available logical UKey instances meeting the security policy requirement from the logical UKey instance pool based on a matching result of the security policy requirement of the UKey scheduling request and the UKey capability profile.

[0195] The resource execution module is configured to select a logical UKey instance in an idle state from the subset of available logical UKey instances, bind the logical UKey instance to a session identifier of the current bidding task, and perform a CA signature operation or a CA signature verification operation through the logical UKey instance.

[0196] The resource recycling module is configured to determine whether the bidding process phase is a non-CA signature phase and a non-CA signature verification phase, and release the logical UKey instance, update a state of the logical UKey instance to idle, and return the logical UKey instance to the logical UKey instance pool when the determination result is yes.

[0197] The above-mentioned modules in the CA certificate UKey sharing scheduling system based on an electronic bidding scenario can be all or partially implemented by software, hardware, or a combination thereof. The above-mentioned modules can be embedded in or independent of a processor in a computer device in a hardware form, or stored in a memory in a computer device in a software form, so as to be called and executed by a processor to perform operations corresponding to the above-mentioned modules.

[0198] In an exemplary embodiment, a computer device, which can be a terminal, is provided, and an internal structure diagram of the computer device can be as shown in FIG. 1. Figure 3As shown in the figure. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. Among them, the processor, the memory and the input / output interface are connected through the system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capability. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with the external terminal in a wired or wireless manner. The wireless manner can be realized through WIFI, mobile cellular network, near field communication (Near Field Communication, NFC) or other technologies. The computer program is executed by the processor to realize a CA certificate UKey sharing scheduling method based on an electronic bidding scene. The display unit of the computer device is used to form a visually visible picture, which can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer overlaid on the display screen, or a key, trackball or touchpad arranged on the shell of the computer device, or an external keyboard, touchpad or mouse, etc.

[0199] Those skilled in the art can understand that, Figure 3 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different component arrangement.

[0200] In one embodiment, a computer device is also provided, including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to realize the steps in each of the above method embodiments.

[0201] In one embodiment, a computer readable storage medium is provided, which stores a computer program, and the computer program is executed by a processor to realize the steps in each of the above method embodiments.

[0202] In one embodiment, a computer program product is provided, including a computer program, and the computer program is executed by a processor to realize the steps in each of the above method embodiments.

[0203] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant regulations.

[0204] It can be understood by those skilled in the art that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing related hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments of each method. In the embodiments provided in the present application, any reference to memory, database or other medium can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration but not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., without being limited thereto. The processor involved in the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., without being limited thereto.

[0205] Any technical features in the above embodiments can be combined, and for the sake of brevity, not all possible combinations are described above, however, any combination of these technical features is deemed to be within the scope of the present application.

[0206] The above embodiments only express several implementation manners of the present application, and the description is relatively specific and detailed, but it should not be understood as a limitation on the patent scope of the present application. It should be pointed out that, for ordinary skilled persons in the art, several modifications and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. A CA certificate UKey sharing and scheduling method based on electronic bidding scenarios, characterized in that, include: Obtain the current bidding process stage and security policy requirements for the bidding task, including cryptographic algorithm type requirements and compliance requirements; Determine whether the bidding process stage is the CA signature stage or the CA verification stage, and generate a UKey scheduling request if the determination result is yes; Obtain the UKey capability profile corresponding to each logical UKey instance in the logical UKey instance pool. The logical UKey instance is generated by virtualizing the physical UKey device. The UKey capability profile includes the cryptographic algorithm support type, certificate validity period, manufacturer identification and compliance label. Based on the matching result between the security policy requirements of the UKey scheduling request and the UKey capability profile, a subset of available logical UKey instances that meet the security policy requirements is selected from the logical UKey instance pool; Select an idle logical UKey instance from the subset of available logical UKey instances, bind the logical UKey instance to the session identifier of the current bidding task, and perform a CA signature operation or a CA verification operation through the logical UKey instance; If the bidding process stage is determined to be a non-CA signature stage and a non-CA verification stage, and the determination result is yes, the logical UKey instance is released, the status of the logical UKey instance is updated to idle, and the logical UKey instance is returned to the logical UKey instance pool.

2. The CA certificate UKey sharing and scheduling method based on electronic bidding scenario as described in claim 1, characterized in that: The requirements for obtaining the bidding process stage and security strategy of the current bidding task include: receiving the task identifier of the current bidding task; The bidding process stage associated with the task identifier is obtained by querying the bidding business status table based on the task identifier. Query the bidding strategy configuration table based on the task identifier to obtain the security policy requirements associated with the task identifier; The bidding process stage and the security policy requirements are used as input parameters for the current bidding task.

3. The CA certificate UKey sharing and scheduling method based on electronic bidding scenario as described in claim 2, characterized in that: The generation of the UKey scheduling request includes: Analyze the bidding process stages and extract the stage type field and stage status validity flag; Verify whether the stage status validity flag indicates that the bidding process stage is in a valid state; If the validity flag of the stage status indicates that the bidding process stage is in a valid state, determine whether the value of the stage type field is equal to the preset CA signature stage type value or the preset CA verification stage type value. Under the condition that the value of the stage type field is equal to the CA signature stage type value or the CA verification stage type value, query the UKey scheduling status record of the current bidding task to confirm whether there are any incomplete UKey scheduling requests. If there are no incomplete UKey scheduling requests, construct a UKey scheduling request, which includes the task identifier, the security policy requirements, and the scheduling trigger timestamp, and mark the UKey scheduling request as pending.

4. The CA certificate UKey sharing and scheduling method based on electronic bidding scenario as described in claim 3, characterized in that: The virtualization generation includes: Iterate through the logical UKey instances in the logical UKey instance pool and obtain the physical UKey device identifier associated with each logical UKey instance; Based on the physical UKey device identifier, query the physical UKey device metadata table to obtain the original capability metadata corresponding to the physical UKey device identifier. The original capability metadata includes cryptographic algorithm support type, certificate validity period, and vendor identifier. Based on a pre-defined compliance rule base, the original capability metadata is evaluated for compliance, and compliance tags are generated. The cryptographic algorithm support type, the certificate validity period, the vendor identifier, and the compliance label are combined into a structured data object, which serves as the UKey capability profile of the corresponding logical UKey instance; The UKey capability profile is bound to the corresponding logical UKey instance and cached in the capability profile cache area.

5. The CA certificate UKey sharing and scheduling method based on electronic bidding scenario as described in claim 4, characterized in that: When binding the UKey capability profile to the corresponding logical UKey instance and caching it in the capability profile cache area, the cache expiration time is calculated based on the certificate validity period; And after the cache expires, the UKey capability profile is invalidated, and the UKey capability profile is re-acquired.

6. The CA certificate UKey sharing and scheduling method based on electronic bidding scenario as described in claim 5, characterized in that: The filtering of a subset of available logical UKey instances that meet the security policy requirements includes: extracting the security policy requirements from the UKey scheduling request, wherein the security policy requirements include cryptographic algorithm type requirements and compliance requirements; Iterate through each logical UKey instance in the logical UKey instance pool to obtain the UKey capability profile corresponding to each logical UKey instance; For each UKey capability profile, determine whether the cryptographic algorithm support type of each UKey capability profile includes the cryptographic algorithm type requirement, and whether its compliance label is consistent with the compliance requirement; For logical UKey instances that meet the cryptographic algorithm type requirements and the compliance requirements, further verify whether their current state is idle; The logical UKey instances that are idle and meet the security policy requirements are aggregated to form a subset of available logical UKey instances.

7. The CA certificate UKey sharing and scheduling method based on electronic bidding scenario as described in claim 6, characterized in that: The execution of CA signature operation or CA verification operation includes: Obtain all logical UKey instances from the subset of available logical UKey instances, and verify that the current state of each logical UKey instance is still idle; Based on a preset instance selection strategy, the target logical UKey instance is determined from logical UKey instances whose verified status is idle. Update the status of the target logical UKey instance to occupied, and establish a binding relationship between the target logical UKey instance and the session identifier of the current bidding task; Based on the bidding process stage, the type of cryptographic operation to be performed is determined, which is either a CA signature operation or a CA signature verification operation. Call the password service interface of the target logical UKey instance, pass in the data to be processed and the password operation type, and execute the CA signature operation or the CA verification operation.

8. The CA certificate UKey sharing and scheduling method based on electronic bidding scenario as described in claim 7, characterized in that: Returning the logical UKey instance to the logical UKey instance pool includes: Obtain the stage type field value of the bidding process stage, and confirm that the stage type field value is neither equal to the preset CA signature stage type value nor equal to the preset CA verification stage type value. In response to the fact that the value of the stage type field is neither equal to the value of the CA signature stage type nor equal to the value of the CA verification stage type, the corresponding logical UKey instance is queried based on the session identifier of the current bidding task. The current status of the logical UKey instance queried is checked to be occupied, and its bound session identifier is consistent with the session identifier of the current bidding task. If the logical UKey instance is in an occupied state and the session identifier is consistent, update the state of the logical UKey instance to idle, release its binding relationship with the session identifier, and return the logical UKey instance to the logical UKey instance pool.

9. The CA certificate UKey sharing and scheduling method based on electronic bidding scenario as described in claim 8, characterized in that: Returning the logical UKey instance to the logical UKey instance pool also includes: Before releasing the logical UKey instance, check the active time of the bound session; If the last active time of the bound session is earlier than the current time minus the preset session timeout threshold, the state of the logical UKey instance will be forcibly updated to idle and returned to the logical UKey instance pool.

10. A CA certificate UKey sharing and scheduling system based on electronic bidding scenarios, employing the CA certificate UKey sharing and scheduling method based on electronic bidding scenarios as described in any one of claims 1 to 9, characterized in that, include: The task parsing module is used to obtain the bidding process stage and security policy requirements of the current bidding task. The security policy requirements include cryptographic algorithm type requirements and compliance requirements. The scheduling triggering module is used to determine whether the bidding process stage is the CA signature stage or the CA verification stage, and generate a UKey scheduling request when the determination result is yes; The capability profile module is used to obtain the UKey capability profile corresponding to each logical UKey instance in the logical UKey instance pool. The logical UKey instance is generated by virtualizing the physical UKey device. The UKey capability profile includes cryptographic algorithm support type, certificate validity period, vendor identifier and compliance label. The resource matching module is used to filter a subset of available logical UKey instances that meet the security policy requirements from the logical UKey instance pool based on the matching result between the security policy requirements of the UKey scheduling request and the UKey capability profile. The resource execution module is used to select an idle logical UKey instance from the subset of available logical UKey instances, bind the logical UKey instance to the session identifier of the current bidding task, and perform CA signature operation or CA verification operation through the logical UKey instance. The resource recycling module is used to determine whether the bidding process stage is a non-CA signature stage or a non-CA verification stage. When the determination result is yes, the module releases the logical UKey instance, updates the status of the logical UKey instance to idle, and returns the logical UKey instance to the logical UKey instance pool.

Images