Service request processing method, service system and computer program product

Abstract

The invention provides a service request processing method, a service system and a computer program product. Relates to the technical field of digital signatures, and comprises the following steps: receiving an initial service request through a preset interface which supports a user to input a command line request and converts the command line request into the initial service request; according to the initial service request, determining a request parameter required for executing a target credible verification service, and converting the request parameter into a target service request conforming to a preset protocol, the request parameter at least comprising a target type identifier of the target credible verification service; and calling a target plug-in matched with the target type identifier from a preset plug-in set to process the target service request to obtain a service result of the target credible verification service. The technical problems of high complexity and low efficiency caused by adopting different tools and strategy execution services in different credible verification scenes are solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of digital signature, in particular to a service request processing method, a service system and a computer program product. BACKGROUND

[0002] In the existing software development and trusted verification field, the digital signature technology has become the cornerstone of guaranteeing software integrity and source credibility. However, with the complication of software supply chain, the signature tools and standards in each development stage and scene are highly fragmented, which aggravates the technical challenges in the whole life cycle management of software.

[0003] On the one hand, the developer needs to switch different tools in different scenes, which is complex in operation and time-consuming in signature link, affecting the software delivery efficiency. On the other hand, various signature tools adopt independent key storage mechanisms, and each signature scheme adopts different execution strategies, which is large in management and auditing workload, easy to cause key leakage events, and difficult to perform signature tracing across scenes.

[0004] At present, no effective solution has been proposed for the above problems. SUMMARY

[0005] The embodiments of the present application provide a service request processing method, a service system and a computer program product to at least solve the technical problems of high complexity and low efficiency caused by using different tools and strategy to perform services in different trusted verification scenes.

[0006] According to an aspect of the embodiments of the present application, a service request processing method is provided, including: receiving an initial service request through a preset interface, wherein the preset interface supports user input of a command line request and converts the command line request into the initial service request; determining a request parameter required for executing a target trusted verification service according to the initial service request, and converting the request parameter into a target service request conforming to a preset protocol, wherein the request parameter at least includes a target type identifier of the target trusted verification service; calling a target plug-in matching the target type identifier from a preset plug-in set to process the target service request, and obtaining a service result of the target trusted verification service, wherein the preset plug-in set includes different plug-ins for processing different trusted verification services.

[0007] Optionally, the target plugin matching the target type identifier is called from the preset plugin set to process the target service request to obtain the service result of the target trusted verification service, comprising: querying the plugin matching the target type identifier from the plugin registry to obtain the target plugin, wherein the plugin registry stores information of the plugin corresponding to different type identifiers of different trusted verification services in the form of key-value pairs; and forwarding the target service request to the target plugin and obtaining the service result fed back by the target plugin, wherein the target plugin is used to execute the target trusted verification service of the target type to obtain the service result.

[0008] Optionally, in the case that the target service request is a signature request, the target type identifier is a target signature type identifier, and the target plugin matching the target signature type identifier is determined from the preset plugin set to process the target service request to obtain the service result of the target trusted verification service, comprising: calling the target signature plugin to process the signature request to obtain a signature result, wherein the target signature plugin is used to execute the signature service of the target signature type based on the signature parameter in the signature request to obtain the signature result.

[0009] Optionally, in the case that the target service request is a signature verification request, the target type identifier is a target signature verification type identifier, and the target signature verification plugin matching the target signature verification type identifier is determined from the preset plugin set to process the signature verification request to obtain a signature verification result, wherein the target signature verification plugin is used to execute the signature verification service of the target signature verification type based on the signature verification parameter in the signature verification request to obtain the signature verification result.

[0010] Optionally, in the case that the target service request is a key generation request, the target type identifier is a target key generation type identifier, and the key management plugin matching the target key generation type identifier is determined from the preset plugin set to process the key generation request to generate a key meeting a preset rule, wherein the key meeting the preset rule is at least associated with the target key generation type identifier; after the target plugin matching the target type identifier is called from the preset plugin set to process the target service request to obtain the service result of the target trusted verification service, the method further comprises: storing the key in a database, regularly scanning the validity period of the key, and calling the key management plugin again to generate a new key and update the associated certificate of the key before the key expires.

[0011] Optionally, determining the request parameter required for performing the target trusted verification service according to the initial service request comprises: converting the initial service request into an intermediate service request conforming to a preset protocol; parsing the intermediate service request to obtain a first type of parameter, and obtaining a second type of parameter required for the target trusted verification service according to address information in the first type of parameter, wherein the first type of parameter at least includes a function identifier of the target trusted verification service, a target type identifier and the address information; and determining the request parameter according to the first type of parameter and the second type of parameter.

[0012] Optionally, after converting the initial service request into the intermediate service request conforming to the preset protocol, the method further comprises: performing identity verification on the user; performing permission verification on the user if the identity verification is passed, wherein the permission verification is used to verify whether the user is allowed to access the target trusted verification service; and if the permission verification is passed, judging whether a key usage requirement associated with the intermediate service request conforms to a key usage rule, if the key usage requirement is associated with the key usage requirement; and performing the step of parsing the intermediate service request to obtain the first type of parameter, if the key usage requirement conforms to the key usage rule.

[0013] Optionally, after calling the target plug-in matching the target type identifier from the preset plug-in set to process the target service request, the method further comprises: obtaining log data generated in the process of executing the target trusted verification service by the target plug-in; writing the log data into an audit database, and pushing the log data to an audit service through a monitoring stack.

[0014] According to another aspect of the embodiments of the present application, a method for processing a service request is also provided, comprising: receiving an intermediate service request sent by a gateway, wherein the gateway is used to convert an initial service request into an intermediate service request conforming to a preset protocol, and the initial service request is a command line request input by a user; determining a request parameter required for performing a target trusted verification service according to the intermediate service request, and converting the request parameter into a target service request conforming to the preset protocol, wherein the request parameter at least includes a target type identifier of the target trusted verification service; calling a target plug-in matching the target type identifier from a preset plug-in set to process the target service request, to obtain a service result of the target trusted verification service, wherein the preset plug-in set includes different plug-ins used to process different trusted verification services.

[0015] According to another aspect of the embodiments of the present application, a service system is also provided, comprising: a gateway configured to receive an initial service request through a preset interface, wherein the preset interface supports user input of a command line request and converts the command line request into the initial service request; a dispatcher and a preset plug-in set, wherein the dispatcher is configured to determine, according to the initial service request, a request parameter required for executing a target trusted verification service, convert the request parameter into a target service request conforming to a preset protocol, determine, from the preset plug-in set, a target plug-in matching a target type identifier in the request parameter, and invoke the target plug-in to process the target service request, to obtain a service result of the target trusted verification service, wherein the preset plug-in set comprises different plug-ins for processing different trusted verification services.

[0016] Optionally, the service system further comprises a plug-in manager configured to allocate running resources to the plug-ins in the preset plug-in set in a group unit, and / or create independent namespaces and system resources for different plug-ins in the preset plug-in set, and / or automatically terminate a process in which the plug-in is located when a main process of the plug-in abnormally exits.

[0017] Optionally, the preset plug-in set comprises at least the following plug-ins: a signature plug-in sub-set, a signature verification plug-in sub-set, and a key management plug-in.

[0018] Optionally, the service system further comprises a monitor configured to perform at least one of the following functions: collecting running resource usage of the plug-ins in the preset plug-in set, monitoring running conditions of the plug-ins in the preset plug-in set, recording log data generated by the plug-ins in the preset plug-in set in the process of executing services, and tracking a process in which a key plug-in in the preset plug-in set executes a key service.

[0019] Optionally, the service system further comprises an authentication component configured to perform identity verification on a user, and / or an authorization component configured to perform permission verification on the user, and configured to manage permission of the user to access services and key usage rules.

[0020] According to another aspect of the embodiments of the present application, a computer readable storage medium is also provided, comprising a stored executable program, wherein when the executable program is executed, the computer readable storage medium controls a device in which the computer readable storage medium is located to execute the method in the various embodiments of the present application.

[0021] According to another aspect of the embodiments of the present application, a computer program product is also provided, comprising a non-volatile computer readable storage medium, wherein the non-volatile computer readable storage medium stores a computer program, and when the computer program is executed by a processor, the method in the various embodiments of the present application is implemented.

[0022] In the embodiments of the present application, the preset interface can provide a consistent syntax operation environment for different scenarios, the user inputs a simple command line request to the preset interface in any scenario, and the preset interface converts the command line request into an initial service request, thereby shielding the difference of the underlying service tool; the request parameters required for executing the target trusted verification service are determined according to the initial service request, the request parameters are converted into a target service request conforming to a preset protocol, thereby avoiding language binding and facilitating communication with different plug-ins; the target plug-in is determined from the preset plug-in set according to the target type identifier of the target trusted verification service in the request parameters, and the target plug-in is called to process the target service request, thereby achieving the purpose of supporting multi-scenario parallel expansion of services through a dynamic routing mechanism, thereby achieving the technical effects of improving the efficiency of executing services and reducing the complexity of executing services, and further solving the technical problems of high complexity and low efficiency caused by using different tools and policy execution services in different trusted verification scenarios.

[0023] The above general description and the following detailed description are intended to illustrate and explain the present application, and do not constitute a limitation on the present application. BRIEF DESCRIPTION OF DRAWINGS

[0024] The drawings described herein are intended to provide further understanding of the present application, and form a part of the present application. The illustrative embodiments of the present application and their description serve to explain the present application, and do not constitute an improper limitation on the present application. In the drawings:

[0025] Figure 1 is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a service request processing method according to an embodiment of the present application;

[0026] Figure 2 is a structure block diagram of a computing environment according to an embodiment of the present application;

[0027] Figure 3 is a flowchart of a service request processing method according to an embodiment of the present application;

[0028] Figure 4 is a flowchart of another service request processing method according to an embodiment of the present application;

[0029] Figure 5 is a flowchart of an optional service request processing method according to an embodiment of the present application;

[0030] Figure 6 is a schematic diagram of a service system according to an embodiment of the present application;

[0031] Figure 7 is a schematic diagram of a service request processing device according to an embodiment of the present application;

[0032] Figure 8 is a schematic diagram of another service request processing device according to an embodiment of the application;

[0033] Figure 9 is a structural block diagram of an electronic device according to an embodiment of the application. DETAILED DESCRIPTION

[0034] In order to make the personnel in the art better understand the scheme of the present application, the technical scheme in the embodiments of the present application will be clearly and completely described below in combination with the drawings in the embodiments of the present application. Obviously, the embodiments described below are part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative labor should fall within the scope of protection of the present application.

[0035] It should be noted that the terms "first", "second", and the like in the specification and claims of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in other orders. The other order here refers to an order other than those illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not necessarily limit to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to the process, method, product or device.

[0036] According to an embodiment of the present application, a service request processing method is provided. The steps shown in the flowchart of the drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in an order different from that shown herein.

[0037] The method embodiments provided by the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 is a hardware structural block diagram of a computer terminal (or mobile device) for implementing a service request processing method according to an embodiment of the present application. As shown in Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU (Microcontroller Unit) or a programmable gate array (FPGA), etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is schematic and does not limit the structure of the aforementioned electronic device. For example, the computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0038] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be wholly or partially embodied in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or wholly or partially integrated into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuit serves as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0039] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method in the embodiments of this application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the method in the above embodiments. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102. These remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0040] The transport 106 is configured to receive or transmit data via a network. Examples of the network can include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transport 106 includes a network interface controller (NIC) that can connect to other network devices through a base station to communicate with the Internet. In one example, the transport 106 can be a radio frequency (RF) module that is configured to communicate with the Internet via wireless means.

[0041] The display can be a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 (or mobile device).

[0042] Figure 1 The illustrated hardware architecture diagram can be used as an exemplary diagram of the computer terminal 10 (or mobile device) described above, and can also be used as an exemplary diagram of the server described above, in an alternative embodiment, Figure 2 The use of the above-described Figure 1 The computer terminal 10 (or mobile device) is illustrated as an embodiment of a computing node in a computing environment 201. Figure 2 is a structural diagram of a computing environment according to an embodiment of the present application, as described above. Figure 2 As illustrated, the computing environment 201 includes a plurality of computing nodes (e.g., servers) running on a distributed network (shown as 210-1, 210-2,..., in the figure). The computing nodes include local processing and memory resources, and end users 202 can remotely run applications or store data in the computing environment 201. The applications can be provided as a plurality of services 220-1, 220-2, 220-3, and 220-4 in the computing environment 201, representing services "A", "D", "E", and "H", respectively.

[0043] The end users 202 can provide and access the services through a web browser or other software applications on a client, and in some embodiments, the provisioning and / or requests of the end users 202 can be provided to an entry gateway 230. The entry gateway 230 can include a corresponding proxy to handle the provisioning and / or requests for the services (one or more of the services provided in the computing environment 201).

[0044] Services are provided or deployed in accordance with various virtualization technologies supported by the computing environment 201. In some embodiments, services can be provided in accordance with virtualization based on virtual machines (VMs), virtualization based on containers, and / or the like. Virtualization based on virtual machines can be emulating a real computer by initializing a virtual machine, executing programs and applications without directly accessing any actual hardware resources. While the virtual machine is virtualized, in accordance with virtualization based on containers, a container can be launched to virtualize an entire operating system (OS) so that multiple workloads can run on a single operating system instance.

[0045] In one embodiment of container-based virtualization, several containers of a service can be assembled into a Pod (e.g., a Kubernetes Pod). For example, as shown in Figure 2 Service 220-2 can be equipped with one or more Pods 240-1, 240-2, …, 240-N (collectively, Pods). A Pod can include a proxy 245 and one or more containers 242-1, 242-2, …, 242-M (collectively, containers). The one or more containers in a Pod handle requests related to one or more respective functions of the service, and the proxy 245 generally controls network functions related to the service, such as routing, load balancing, and the like. Other services can also be equipped with similar Pods.

[0046] In operation, user requests from end users 202 can be executed, possibly requiring invocation of one or more services in the computing environment 201. Execution of one or more functions of a service can require invocation of one or more functions of another service. As shown in Figure 2 Service “A” 220-1 receives a user request from an end user 202 from an ingress gateway 230, service “A” 220-1 can invoke service “D” 220-2, which can request service “E” 220-3 to execute one or more functions.

[0047] The computing environment described above can be a cloud computing environment, with allocation of resources managed by a cloud service provider, allowing development of functionality without regard to implementation, tuning, or scaling of servers. The computing environment allows developers to execute code in response to events without building or maintaining complex infrastructure. Services can be partitioned into a set of functions that can automatically scale independently, rather than scaling a single hardware device to handle potential loads.

[0048] Embodiments of the present application can be applied in a software development scenario, where digital signing and key management are carried out throughout multiple critical stages in the software development process to ensure the integrity and provenance of the software.

[0049] In the requirement analysis and design verification phase, the type of digital signature and the corresponding key policy need to be determined for use in the project. For example, decide which key pair to use, and the scope and permission level of each key pair. Avoid security risks caused by chaotic key management later.

[0050] In the code compilation phase, the compiled software package needs to be digitally signed to ensure its authenticity. The signed software package can be verified for its integrity and origin during subsequent deployment and use, preventing malicious software or tampered code from being executed.

[0051] In the build and deployment phase, after the container image is built, it needs to be signed using the preset key to ensure that the software deployment in the cloud environment is trustworthy. At the same time, the key used for signing needs to be replaced regularly according to the pre-set policy to reduce the security risks caused by long-term use of the key.

[0052] In the testing and verification phase, all signed software packages and images need to be verified to ensure their reliability during testing and avoid pushing incomplete or unknown-origin software to production environments.

[0053] In the product release phase, the software package, image, and document to be released need to be signed using a unified signing service to ensure consistent signing standards and processes. At the same time, the key needs to be audited before use to check the validity period, permission settings, and use scenarios to ensure they meet the project requirements of software development.

[0054] In the runtime monitoring and maintenance phase, software packages, updates, and patches need to be verified regularly or in real-time to prevent the execution of illegal software components in the running environment. At the same time, the use of the key needs to be monitored to ensure its effectiveness, and the key expiration or revocation needs to be discovered and handled in a timely manner.

[0055] However, the traditional key management system in the related art provides basic signing service capabilities, but users need to call dedicated software toolkits for different signing scenarios and develop conversion layers to support the signing process, which is cumbersome and mainly serves general encryption and decryption operations, making it difficult to meet the signing needs of specific scenarios. The offline signing solution in the related art relies on static signing tool chains, each signing scenario requires an independent tool chain, and the key usage policy needs to be manually configured. The log formats of different signing tools are different, and it is impossible to implement unified monitoring of the entire signing link and unified auditing across scenarios. The solution in the related art integrates signing capabilities through middleware, which embeds plugins in the main process in the form of code libraries, which can easily cause single-point failure to spread, requires reconstruction of the main system for new signing formats, cannot dynamically load heterogeneous backend plugins, and separates key policy management and signing operations into different systems, causing policy effectiveness delay and auditing gaps.

[0056] The application provides a service system and a service request processing method to solve the problems in the related art. By integrating unified signature services and key management services throughout the software development life cycle, the process of digital signature can be systematically managed and controlled, the operational efficiency loss caused by tool chain switching can be reduced, the overall security and credibility of software can be improved, the operation of developers can be simplified, and the risk of misusing or abusing keys can be reduced.

[0057] In the above operating environment, the application provides a service request processing method as shown in Figure 3 Figure 3 is a flowchart of the service request processing method according to an embodiment of the application.

[0058] In step S32, an initial service request is received through a preset interface. The preset interface supports user input of a command line request and converts the command line request into the initial service request.

[0059] The execution subject of the embodiment can be a service system, for example, a UDSS (Unified Digital Signature Service). The preset interface is an interface for interaction between the user and the service system, and can be a command line interface (CLI). The user can input a command line request to the preset interface, and a syntax parsing engine in the preset interface converts the command line request into an initial service request that can be recognized by the service system to access a target trusted verification service. In a software development scenario, the user can be a software developer.

[0060] The target trusted verification service can be various, such as signature, signature verification, key management, etc. The command line request can be various, such as signature request, signature verification request, key management request, etc. Illustratively, in the case where the command line request is a signature request, the preset format of the command line request is bashudss-cli sign--type=<scenario>--target=<object>.

[0061] Wherein, bash refers to a shell environment for executing commands, udss refers to a unified digital signature service, cli refers to a command line interface, and sign refers to a signature; type=<scenario> refers to a signature type, and the specific content of <scenario> is used to map the signature to different signature plugins, for example, type=ko is used to map the signature to a kernel module, type=sigstore is used to map the signature to a container image, and type=whl is used to map the signature to a Python package signature; target refers to an object, which can be the storage path of an object that needs to be signed.​

[0062] For example, in the case where the signature request is used to request signing of a kernel module file, the format of the command line request can be: udss-clisign --type=ko --target=<kernel module file>.

[0063] In this step, the preset interface serves as a unified entrance for multiple signature scenarios, and multiple signature operation scenarios can be abstracted into a unified command paradigm. A user only needs to provide a simple command line request to the preset interface, and the services of various plugins can be invoked, thereby simplifying the operation of the user.

[0064] In step S34, the request parameters required for the target trusted verification service are determined according to the initial service request, and the request parameters are converted into a target service request conforming to a preset protocol, wherein the request parameters at least include a target type identifier of the target trusted verification service.

[0065] The request parameters required for the target trusted verification service can include parameters obtained by directly analyzing the initial service request, or service parameters extracted from a path indicated by address information obtained by analysis.

[0066] For example, in the case where the initial service request is a signature request, the request parameters required for the target trusted verification service can include a signature function parameter (for example, sign), a signature type identifier (for example, ko, sigstore, and whl), a target path where the signature parameter is located, a file or object to be signed extracted from the target path, and various parameters required for signature, such as a hash value and a key ID (Identifier).

[0067] After obtaining the request parameters required for the target trusted verification service, the service system converts the request parameters into a target service request conforming to a preset protocol. The preset protocol is a protocol used for communication with the plugin. For example, the preset protocol can be a gRPC (Google Remote Procedure Call) protocol. In the case where the target trusted verification service is a signature, the request parameters are converted into a unified data structure defined in a Protobuf (Protocol Buffers) format, and a gRPC request for requesting signature is obtained.

[0068] In this step, the request parameters required for the service are normalized into a data structure matching the preset protocol, so that the plugins in the service system only need to process standardized inputs, thereby improving the efficiency of the service execution and reducing the development complexity of the service system.

[0069] Step S36, calling a target plug-in matching the target type identifier from a preset plug-in set to process the target service request, obtaining a service result of the target trusted verification service, wherein the preset plug-in set includes different plug-ins for processing different trusted verification services.

[0070] The server-side built-in dynamic routing mechanism can identify the target type identifier in the target service request, determine and call a target plug-in according to the target type identifier, the target plug-in receives the target service request, executes the target trusted verification service, encapsulates the service result into a response packet conforming to a preset protocol, and then converts it into an output format that can be understood by the preset interface, so as to send it to the user.

[0071] For example, the initial service request is: bashudss-cli sign--type=sigstore--target=<target>, the service system automatically extracts the image digest based on the content of the target, generates a hash value, and converts various signature parameters into a unified data structure defined by Protobuf format, and encapsulates it into a gRPC request for requesting container image signature. Since the target type identifier is sigstore, the target plug-in mapped according to sigstore is the container image signature plug-in, the gRPC request is forwarded to the container image signature plug-in, the container image signature plug-in performs specific signature operation, encapsulates the signature result as a gRPC response, and then converts it into an output format that can be understood by the CLI tool, and presents it to the user through the CLI tool.

[0072] In the embodiments of the present application, the preset interface can provide a consistent syntax operation environment for different scenarios, the user inputs a simple command line request to the preset interface in any scenario, the preset interface converts the command line request into an initial service request, thereby shielding the differences of the underlying service tools; the request parameters required for executing the target trusted verification service are determined according to the initial service request, the request parameters are converted into a target service request conforming to a preset protocol, thereby avoiding language binding and facilitating communication with different plug-ins; a matching target plug-in is determined from a preset plug-in set according to the target type identifier of the target trusted verification service in the request parameter, and the target plug-in is called to process the target service request, thereby achieving the purpose of supporting multi-scenario parallel expansion of services through a dynamic routing mechanism, thereby achieving the technical effects of improving the efficiency of executing services and reducing the complexity of executing services, and further solving the technical problems of high complexity and low efficiency caused by using different tools and strategy to execute services in different trusted verification scenarios.

[0073] As an optional implementation, determining the request parameter required for performing the target trusted verification service according to the initial service request comprises: converting the initial service request into an intermediate service request conforming to a preset protocol; parsing the intermediate service request to obtain a first type of parameter, and obtaining a second type of parameter required for the target trusted verification service according to address information in the first type of parameter, wherein the first type of parameter at least includes a function identifier of the target trusted verification service, a target type identifier and the address information; and determining the request parameter according to the first type of parameter and the second type of parameter.

[0074] Exemplarily, a user initiates a command line request by inputting parameters to the CLI tool, for example, udss-clisign --type=sigstore / ko / whl --target=resource, and the CLI tool converts the command line request into a request conforming to the HTTP protocol (initial service request), and then sends the request to the gateway of the service system.

[0075] After the gateway of the service system receives the HTTP request, the gateway encodes the parameters of the HTTP (HyperText Transfer Protocol) request in a data structure defined by Protobuf format, converts the HTTP request into a gRPC request (intermediate service request), and sends the gRPC request to the core component of the service system. Through this conversion, the CLI tool shields the complexity of the underlying protocol, and the gateway as the hub of protocol conversion ensures the communication compatibility and efficiency from the front end to the back end, so that the user can initiate a service request in a simple command line format, and manage multiple signature scenarios through a unified CLI tool.

[0076] Further, after receiving the gRPC request, the core component of the service system first parses the Protobuf structure carried in the request to extract the key parameters such as the function identifier, target type identifier, and address information, to obtain the first type of parameters. According to the address information, the service parameters required by the target trusted verification service are further obtained, such as the specific content of the object to be signed, the parameters of the signature algorithm, and the like, to obtain the second type of parameters. Then, the first type of parameters (function, type identifier, address information) and the second type of parameters (specific parameters of the service) are combined to construct complete request parameters, and these parameters are organized again into a gRPC request that meets the expectations of the plug-in. For example, the target trusted verification service is to sign a container image, the first type of parameters includes stringfunction_id = 1 (function identifier, such as "SIGN"), stringtarget_type = 2 (target type identifier, such as "CONTAINER_IMAGE"), and stringservice_address = 3 (service address information of the plug-in, used for dynamic routing). The second type of parameters includes ImageInfoimage_info = 4 (image information to be signed) and AlgorithmParamsalgorithm_params (signature algorithm parameters). The first type of parameters and the second type of parameters are combined to construct complete request parameters, and the following gRPC call format is formed: messageFullSignRequest{stringfunction_id = 1; stringtarget_type = 2; stringservice_address = 3; ImageInfoimage_info = 4; AlgorithmParamsalgorithm_params = 5}.

[0077] Through the above process, the core component converts the abstract parameters in the user request into specific parameters for executing a specific service, and converts them into a gRPC request, realizing the standardization and adaptation of the request parameters.

[0078] Among them, the gRPC request of the CLI tool facing the user and the gRPC request between the core component of the service system and the plug-in will define different Protobuf structures, respectively adapting the ease of use of the front-end user interface and the efficiency of the back-end plug-in service.

[0079] The embodiment effectively decouples the user's operation interface and the services of different plug-ins, enabling the user to call the services of diversified plug-ins with a unified command line request. Through two conversions and analyses, the service system can flexibly cope with different service request scenarios, ensuring accurate analysis, efficient transmission, and safe execution of service requests.

[0080] As an optional implementation, after converting the initial service request into the intermediate service request conforming to the preset protocol, the method further comprises: performing identity verification on the user; performing permission verification on the user if the identity verification is passed, wherein the permission verification is used to verify whether the user is allowed to access the target trusted verification service; if the permission verification is passed, judging whether the key usage requirement conforms to the key usage rule if the intermediate service request is associated with the key usage requirement; and performing the step of parsing the intermediate service request to obtain the first type of parameter if the key usage requirement conforms to the key usage rule.

[0081] When the user issues any initial service request to the service system through a preset interface, the gateway of the service system first converts the initial service request into an intermediate service request that can be recognized by the service system. The authentication component of the service system first performs identity verification on the user, including but not limited to: comparing the AK (Access Key, access key) / SK (Secret Key, secret key), OAuthtoken (Open Authorization token, open authorization token) or other credentials provided by the user, to ensure that the request comes from an authenticated user, prevent unauthorized access and service abuse, and protect the service system resources from illegal users.

[0082] After the user identity verification is passed, the authorization component of the service system continues to perform permission verification to check whether the user has the right to access the service indicated by the request. The permission verification can be implemented based on the RBAC (Role-Based Access Control, role-based access control) model, that is, the RBAC automatically determines the right of the user to access a specific service according to the role of the user in advance, without setting the permission for each user, and judges whether the user has the permission to access according to the role of the user when the user accesses. The permission verification can also be implemented based on the authorized user group, that is, the policy engine defines the authorized user group in advance, for example, only members of a specific user group are allowed to request such services for the use of high-strength national cryptographic algorithms (such as SM2 / SM4). If the user requests a key generation or signature service, the service system will check whether the user belongs to the "key administrator" or "signature permission user" group.

[0083] In the case where the permission verification is passed, it is checked whether the intermediate service request is associated with a key usage requirement, such as key generation, signature or signature verification service. If the request contains a key usage requirement, the service system further judges whether the requirement conforms to the preset key usage rule, such as key strength requirement, validity period limit, etc. For example, when the user attempts to generate an SM2 key for container image signature, the policy engine will check whether the user belongs to the predefined "national cryptographic algorithm user" group and whether the current signature scenario allows the use of SM2 algorithm.

[0084] In the case that the key usage requirement meets the rule, the service system starts to parse the intermediate service request, extracts the request parameters, and lays a data foundation for calling the corresponding plug-in to perform specific services.

[0085] The embodiment ensures that the access of the service and the use of the key meet the security specifications through user identity and permission verification and verification of whether the key usage requirement meets the key usage rule, thereby enhancing the security of the service system and improving the reliability of the service.

[0086] As an optional implementation, the target plug-in that matches the target type identifier is called from the preset plug-in set to process the target service request, and the service result of the target trusted verification service includes: querying the plug-in that matches the target type identifier from the plug-in registry to obtain the target plug-in, wherein the plug-in registry stores the information of the plug-in corresponding to different type identifiers of different trusted verification services in the form of key-value pairs; and forwarding the target service request to the target plug-in and obtaining the service result fed back by the target plug-in, wherein the target plug-in is used to execute the target trusted verification service of the target type to obtain the service result.

[0087] The plug-in registry exists in the core component of the service system and stores the information of the plug-in corresponding to different type identifiers (such as ko, sigstore, whl, etc.) of different trusted verification services in the form of key-value pairs. The “key” points to the type identifier of the service, and the “value” points to the reference of the specific plug-in, including the position, version information, state, and other metadata of the plug-in.

[0088] The core component includes a core dispatcher. When the core dispatcher receives a target service request with a --type parameter, it first queries the plug-in information that matches the --type parameter from the plug-in registry. For example, for a request with --type=ko, the plug-in registry is searched for an entry of the kernel module signature plug-in, so as to locate the kernel module signature plug-in responsible for the kernel module signature, and the target service request is forwarded to the target plug-in.

[0089] The target plug-in processes the target request according to its set function to perform operations such as signature and verification, and generates result data including but not limited to signature data, certificate information, success or failure status code, etc. after processing the service request.

[0090] The core dispatcher waits for and receives the service result fed back by the target plug-in, and converts the feedback result into a format that can be output by the preset interface. The core dispatcher can also further process the feedback result for auditing and log recording, and finally present it to the user.

[0091] The embodiment queries the plug-in information corresponding to the target type identifier from the plug-in registry through a dynamic routing mechanism, forwards the target service request to the target plug-in indicated by the plug-in information, and feeds back the service result generated by the plug-in to the user in a format supported by a preset interface, without manual switching of tools or protocols throughout the process, ensuring that the plug-in only needs to process standardized inputs, improving the efficiency of the plug-in in executing services, and reducing the development complexity of the service system.

[0092] The target service request can be of various types. Optionally, in the case of a signature request, the target type identifier is a target signature type identifier, and the target plug-in that matches the target type identifier is called from the preset plug-in set to process the target service request, to obtain the service result of the target trusted verification service. The method comprises the following steps: determining the target signature plug-in that matches the target signature type identifier from the preset plug-in set; and calling the target signature plug-in to process the signature request to obtain a signature result, wherein the target signature plug-in is used to execute a signature service of the target signature type based on the signature parameter in the signature request to obtain the signature result.

[0093] In an optional embodiment, full-link signature and verification of a container image are required, a verifiable signature is provided for each published container, and a "SIGNED" identifier is displayed on the publishing interface. In the signature stage, a user issues a signature request through a unified CLI tool, for example: bash udss-cli sign --type=signature --target=<image module file>, where sigstore is the target signature type identifier, indicating that the type of the signature request is container image signature.

[0094] The gateway of the service system sends the signature request to the authorization component, the signature request is subjected to identity verification by the authentication component and permission verification by the authorization component, the authorization component has a risk interception function, can block the operation and trigger the alarm mechanism immediately when detecting that the signature request comes from a non-whitelist, and the request of a non-authorized user will be rejected immediately, effectively preventing potential signature fraud or unauthorized access, thereby enhancing the security of the signature service, and when the signature request comes from a whitelist, it is sent to the dispatcher in the core component of the service system. For example, the whitelist can be a special permission user group (such as root:kernel-admin).

[0095] The core dispatcher parses the signature request, determines the required request parameters for the signature according to the signature request, converts the request parameters into a gRPC request, dynamically routes the gRPC request to the container image signature plug-in according to the type identifier, the container image signature plug-in receives the gRPC request, obtains a private key from the key center (ensuring that the key is not stored locally to reduce the risk of leakage), generates standard signature data, writes the signature status into the image metadata and / or synchronizes it to the publishing platform, and displays the "SIGNED" identifier by the front end.

[0096] In another alternative embodiment, kernel module security signing is required to provide a tamper-resistant signature for kernel modules, ensuring that only authorized administrators can load modules.

[0097] A user issues a kernel module signing request through a CLI tool, for example: bash uds s-cli sign --type=ko --target=<kernel module file>, where ko is a target signature type identifier indicating that the type of the signature request is a kernel module signature. The gateway of the service system sends the signature request to the authorization component, and after the signature request is authenticated by the authorization component, it is sent to the dispatcher in the core component of the service system.

[0098] The core dispatcher parses the signature request, determines the required request parameters for signing according to the signature request, converts the request parameters into a gRPC request, dynamically routes the gRPC request to the kernel module signature plug-in according to the type identifier, and the kernel module signature plug-in receives the gRPC request, obtains a private key from the key center to generate a signature, after the signature is completed, the kernel module signature plug-in returns the signature result, the core dispatcher processes and feeds back to the user, and at the same time, the audit log of the signature operation can be recorded to ensure the observability of the whole signature process.

[0099] In this embodiment, the service system eliminates the tool chain switching step, can realize unified management of various signature operations (for example, container image full link signature and kernel module security signature), the user only needs to input a standardized command line request, the service system can call complex signature services through a dynamic routing mechanism, without understanding the implementation details of the underlying plug-in or switching different tools and protocols, and the development efficiency is greatly improved in the software development process, and the keys can be centrally controlled, and the security of the signature operation is improved.

[0100] In addition to the signature request, the target service request can also be a signature verification request. Optionally, in the case where the target service request is a signature verification request, the target type identifier is a target signature verification type identifier, a target plug-in matching the target type identifier is called from the preset plug-in set to process the target service request, and a service result of a target trusted verification service is obtained. The method comprises the following steps: determining a target signature verification plug-in matching the target signature verification type identifier from the preset plug-in set; calling the target signature verification plug-in to process the signature verification request to obtain a signature verification result, wherein the target signature verification plug-in is used to execute a target signature verification type signature verification service based on signature verification parameters in the signature verification request to obtain a signature verification result.

[0101] In an optional embodiment, full-link signature and verification of the container image are required to provide verifiable signature for each published container and display the "SIGNED" logo on the publishing interface. In the signature verification stage, the user issues a signature verification request through the CLI tool, for example: bash udss-cli verify --type=sigstore target=<image module file>, where sigstore is the target signature verification type identifier, indicating that the verification request is a container image signature verification. The gateway of the service system sends the signature verification request to the authorization component, and after the signature verification request is authenticated by the authorization component, it is sent to the scheduler in the core component of the service system.

[0102] The core scheduler parses the signature verification request and determines the required request parameters for signature verification, including the function parameters of signature verification, the type identifier of signature verification, and the signature verification parameters (such as image digest value, signature data, and certificate information). The request parameters are converted into gRPC requests, and the gRPC requests are dynamically routed to the container image signature verification plug-in according to the type identifier.

[0103] After receiving the gRPC request, the container image signature verification plug-in performs the signature verification service of the container image based on the signature verification parameters in the gRPC request. The verification result is audited by the policy engine to ensure the compliance and security of the signature process. If the signature is valid, the plug-in returns a positive verification result, and the service system updates the "SIGNED" status badge on the official website in real time, indicating that the image has been officially certified and can be safely downloaded; if the signature is invalid, a negative result and possible verification failure reasons are returned.

[0104] In this embodiment, the service system eliminates the tool chain switching step, can realize unified management of different signature verification operations, and the user only needs to input a standardized command line request. The service system can call complex signature verification services through a dynamic routing mechanism to verify the integrity of the signature, simplifying user operations and improving the efficiency and security of signature verification.

[0105] In the process of signing, the key needs to be used. Optionally, in the case of a key generation request for a target service request, the target type identifier is a target key generation type identifier, a target plug-in matching the target type identifier is called from the preset plug-in set to process the target service request, and the service result of the target trusted verification service is obtained. The method comprises: determining a key management plug-in matching the target key generation type identifier from the preset plug-in set, calling the key management plug-in to process the key generation request, and generating a key conforming to a preset rule, wherein the key conforming to the preset rule is at least associated with the target key generation type identifier; after the target plug-in matching the target type identifier is called from the preset plug-in set to process the target service request and obtain the service result of the target trusted verification service, the method further comprises: storing the key in a database, periodically scanning the validity period of the key, and before the key expires, calling the key management plug-in again to generate a new key and updating the associated certificate of the key.

[0106] For example, in the case of generating a key, the user issues a key generation request through a CLI tool, for example: bash udss-cli keygen --scenario=ko, wherein keygen indicates to generate a new key pair, and --scenario=ko is a target key generation type identifier, indicating that the type of key to be generated is related to the kernel module signature scenario.

[0107] The gateway of the service system sends the key generation request to the authorization component, and after the key generation request is authenticated by the authorization component, it is sent to the dispatcher in the core component of the service system.

[0108] The core dispatcher parses the key generation request, determines the required request parameters for generating the key according to the key generation request, converts the request parameters into a gRPC request, and dynamically routes the gRPC request to the key management plug-in matching the ko type identifier, i.e. the kernel module key generation plug-in.

[0109] After the kernel module key generation plug-in receives the gRPC request, a key conforming to a preset rule is generated, such as a PKCS#8 format RSA key. It should be noted that the key name can be automatically named according to the {scenario}-{user ID}-{KMS name}-priv rule, such as ko-dys-kms-priv, thereby ensuring key isolation in different scenarios and preventing confusion and misuse, wherein KMS is the abbreviation of Key Management Service, which refers to a key management service.

[0110] The generated key is stored in the database as part of key resource management. At the same time, the policy engine periodically scans the keys in the database to check their validity period, to ensure timely rotation and management of the keys. Before the key is about to expire, the policy engine automatically triggers a new round of key generation process, again calls the corresponding key management plug-in to generate a new key, and updates the certificate associated with it, to maintain the validity of the key and the synchronization of the certificate.

[0111] For example, according to the preset key life cycle policy, the policy engine ensures that the key is automatically rotated within a specified period (for example, 90 days). In addition, the certificate corresponding to the old key is revoked and published to the CRL (Certificate Revocation List), and the old key is marked as obsolete to support historical signature verification and avoid invalidation of historical signatures due to key rotation.

[0112] In addition, the key management plug-in also supports seamless integration of encryption algorithms. For example, in the case of container image signature (scenario = sigstore), the service system can directly call the SM2 signature algorithm conforming to the GM / T0036-2014 specification in the sigstore plug-in without the need for users to make additional command modifications or parameter adjustments.

[0113] The key generation, storage, rotation, and revocation of the present embodiment all follow the key life cycle policy. Users only need to interact with the preset interface and the service system to complete the full life cycle management of the key, without the need to worry about the specific storage location and format of the key, greatly simplifying the operation process and improving the security of key management.

[0114] As an optional implementation, after calling the target plug-in matching the target type identifier from the preset plug-in set to process the target service request, the method further includes: obtaining log data generated by the target plug-in in the process of executing the target trusted verification service; writing the log data into an audit database, and pushing the log data to an audit service through a monitoring stack.

[0115] In the process of plug-in executing services such as signature or signature verification, structured log data containing operation type, key ID, timestamp, and other key information is generated. These log data not only record the details of the operation, but also provide metadata for auditing, laying a data foundation for building a closed-loop audit.

[0116] For example, when the sigstore plug-in generates a signature for a container image, the generated log data records the digest information of the container image, the key ID used (such as dys-kms-sigstore-priv), and the signature timestamp.

[0117] After the service request processing is completed, the log management service of the service system automatically captures the log data generated by the target plug-in, ensuring that the operation log is recorded in time. The log data is written into the audit database in a structured format, facilitating subsequent retrieval and analysis. Even if the audit database and the storage mechanism of each plug-in are different, the structured log ensures that the audit service can read and understand the log data across scenarios.

[0118] The audit database can be a special database system for centralized storage and management of audit logs, or it can be part of the existing persistent storage on the server, as long as the integrity and traceability of the log data are ensured.

[0119] In addition to writing into the audit database, the service system can also push the log data to the audit service through the monitoring stack, allowing the audit service to subscribe and receive log data from the plug-in. The audit service receives and processes log data in real time, forming a unified audit view, which not only enhances the real-time nature of the audit, but also provides monitoring of system health and performance indicators.

[0120] This embodiment builds an audit closed loop for software supply chain security by capturing structured log data in real time, writing it into the audit database and pushing it to the audit service. This not only ensures the traceability of cross-scenario operations, but also enhances the security monitoring capabilities of the system, laying the foundation for realizing software full life cycle security and trusted verification.

[0121] Figure 4 is a flowchart of another method for processing a service request according to an embodiment of the present application, as shown in Figure 4 The method comprises the following steps:

[0122] In step S42, an intermediate service request sent by the gateway is received, wherein the gateway is used to convert the initial service request into an intermediate service request conforming to a preset protocol, and the initial service request is a request converted from a command line request input by a user.

[0123] The execution subject of the embodiment can be a dispatcher, specifically a core dispatcher of the core components of the service system. The service system can be a UDSS (Unified Digital Signature Service).

[0124] The user can input a command line request to the CLI tool, and the syntax parsing engine in the CLI tool converts the command line request into a request conforming to the HTTP protocol (initial service request) that can be recognized by the service system, and then sends it to the gateway of the service system to access the target trusted verification service. The target trusted verification service can be various, such as signature, signature verification, key management, etc.

[0125] After receiving the HTTP request, the gateway encodes the parameters of the HTTP request in a data structure defined in the Protobuf format, converts the HTTP request into a gRPC request (intermediate service request), and sends the gRPC request to the dispatcher of the service system.

[0126] In step S44, the request parameters required for executing the target trusted verification service are determined according to the intermediate service request, and the request parameters are converted into a target service request conforming to a preset protocol, wherein the request parameters at least include a target type identifier of the target trusted verification service.

[0127] The dispatcher first parses the Protobuf structure carried in the gRPC request to determine the request parameters required for the target trusted verification service after receiving the gRPC request. The request parameters can include parameters obtained by directly parsing the initial service request, or service parameters extracted from the path indicated by the address information obtained by parsing.

[0128] For example, if the initial service request is a signature request, the request parameters required for executing the target trusted verification service can include the function parameter (e.g., sign) of the signature, the type identifier (e.g., ko, sigstore, and whl) of the signature, the target path where the parameters to be signed are located, the file or object to be signed extracted from the target path, and various parameters required for the signature, such as the hash value and the key ID (Identifier).

[0129] After obtaining the request parameters required for the target trusted verification service, the dispatcher converts the request parameters into a target service request conforming to a preset protocol. The preset protocol is a protocol used for communication with the plug-in. For example, the preset protocol can be a gRPC (Google Remote Procedure Call) protocol. In the case where the target trusted verification service is a signature, the request parameters are converted into a unified data structure defined in the Protobuf (Protocol Buffers) format to obtain a gRPC request for requesting the signature.

[0130] In step S46, a target plug-in matching the target type identifier is called from a preset plug-in set to process the target service request, and a service result of the target trusted verification service is obtained, wherein the preset plug-in set includes different plug-ins for processing different trusted verification services.

[0131] The dispatcher has a built-in dynamic routing mechanism that can identify the target type identifier in the target service request and determine and call the target plug-in according to the target type identifier. After receiving the target service request, the target plug-in executes the target trusted verification service, encapsulates the service result into a response packet conforming to the preset protocol, and then converts it into an output format that can be understood by the preset interface, so as to send it to the user.

[0132] For example, the initial service request is bashudss-cli sign--type=sigstore--target=<target>. The dispatcher automatically extracts the image digest, generates a hash value based on the content of the target, and converts various signature parameters into a unified data structure defined by Protobuf format. The gRPC request for requesting container image signature is encapsulated. Since the target type is identified as sigstore, the target plugin mapped by sigstore is the container image signature plugin. The gRPC request is forwarded to the container image signature plugin, which performs specific signature operations, encapsulates the signature result as a gRPC response, and then converts it into an output format that can be understood by the CLI tool. The user is presented with the output format through the CLI tool.

[0133] In the embodiments of the present application, the gateway is used to convert the initial service request into an intermediate service request conforming to the preset protocol and send it to the dispatcher. Since the initial service request is a request converted from the command line request input by the user, the user inputs a simple command line request to the preset interface in any scenario. The preset interface converts the command line request into an initial service request, thereby shielding the differences between the underlying service tools. The dispatcher determines the request parameters required for executing the target trusted verification service according to the intermediate service request, converts the request parameters into a target service request conforming to the preset protocol, thereby avoiding language binding and facilitating communication with different plugins. According to the target type identifier of the target trusted verification service in the request parameters, a matching target plugin is determined from the preset plugin set, and the target plugin is called to process the target service request, thereby achieving the purpose of supporting parallel expansion of services in multiple scenarios through a dynamic routing mechanism. Therefore, the technical effects of improving the efficiency of executing services and reducing the complexity of executing services are achieved, thereby solving the technical problems of high complexity and low efficiency caused by using different tools and policy execution services in different trusted verification scenarios.

[0134] Figure 5 is a flowchart of an optional service request processing method according to an embodiment of the present application. The method comprises:

[0135] First, the user applies for a key, and the management party of the UDSS approves the key. If the approval is not passed, the process is ended. If the approval is passed, the UDSS creates a user and associates a data table with the user. The data table includes at least the following information: user information, AK / SK, key resources, key policies, and usage scenarios. At the same time, the key management module associates the data table of the user, grants the user corresponding resources and access rights to services, sends the authorization information and application result to the user, and generates a UDSS key ID for the user.

[0136] Further, the user can send a service request to the UDSS, and the UDSS can complete the service by calling the plug-in in the KMS through the internal plug-in. For example, the user can send a signature request to the UDSS, and the signature module in the UDSS receives the signature request and implements the signature by calling the signature algorithm in the KMS. For another example, the user can also send a signature verification request to the UDSS, and the signature verification module in the UDSS receives the signature verification request and implements the signature verification by calling the signature verification algorithm in the KMS. For another example, the user can also send a key information query request to the UDSS to request public key information, and the key management module in the UDSS receives the key information query request and implements the public key query by calling the key management module in the KMS.

[0137] 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 laws, regulations and standards of relevant countries and regions, and provide corresponding operation portal for user to choose authorization or refusal.

[0138] For the foregoing method embodiments, in order to simply describe, they are all expressed as a series of action combinations, but those skilled in the art should know that the present application is not limited by the action sequence described. Because according to the present application, some steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions and modules involved are not necessarily necessary for the present application.

[0139] From the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software and necessary general hardware platform, and of course it can also be realized by hardware. Based on such understanding, the technical solutions of the present application can be embodied in the form of software product. The computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a plurality of instructions to make a terminal device (which can be a mobile phone, computer, server, or network device, etc.) execute the method described in each embodiment of the present application.

[0140] According to the embodiments of the present application, a service system for implementing the processing method of the above service request is also provided, Figure 6 is a schematic diagram of a service system according to an embodiment of the present application, as Figure 6 shown, the service system comprises:

[0141] The gateway is configured to receive an initial service request via a preset interface, wherein the preset interface supports user input of a command line request and converts the command line request into the initial service request.

[0142] The preset interface can be a client interface, for example, an interface of a CLI tool. The user inputs a command via the CLI, and the CLI tool converts the command line request into a request conforming to the HTTP protocol (the initial service request) and then sends the request to the gateway of the service system. For another example, the client interface can also be an HTTP interface. The user can input a request conforming to the HTTP protocol via the HTTP interface of the network service. For another example, the client interface can also be an HTTP (HyperText Transfer Protocol Secure) interface. The user can also input a request conforming to the HTTP protocol via the HTTPS interface of the network service.

[0143] Through the conversion, the CLI tool shields the complexity of the underlying protocol. Meanwhile, the gateway serves as the hub of protocol conversion, ensuring the communication compatibility and efficiency from the front end to the back end, so that the user can initiate a service request in a simple command line format and manage multiple signature scenarios via a unified CLI tool.

[0144] The scheduler and a preset plugin set, wherein the scheduler is configured to determine, according to the initial service request, a request parameter required for executing the target trusted verification service, convert the request parameter into a target service request conforming to a preset protocol, determine, from the preset plugin set, a target plugin matching a target type identifier in the request parameter, and invoke the target plugin to process the target service request to obtain a service result of the target trusted verification service, wherein the preset plugin set includes different plugins for processing different trusted verification services.

[0145] Since the gateway is equivalent to a proxy component and plays a role in load balancing and remote procedure calling, after receiving the HTTP request, the gateway encodes the parameters of the HTTP request in a data structure defined in the Protobuf format, converts the HTTP request into a gRPC request (the intermediate service request), and sends the gRPC request to the core component of the service system.

[0146] The scheduler can be a core scheduler of the core component of the service system. After receiving the gRPC request, the core scheduler first parses the Protobuf structure carried in the request, extracts key parameters such as a function identifier, a target type identifier, and address information, further obtains service parameters required for the target trusted verification service according to the address information, constructs complete request parameters, and organizes the parameters again into a gRPC request conforming to the expectation of the plugin.

[0147] The core scheduler stores a plug-in registry in the form of key-value pairs, which stores different types of identifiers (such as ko, sigstore, whl, etc.) of different trusted verification services and corresponding plug-in information. The core scheduler looks up the target plug-in corresponding to the target type identifier in the plug-in registry, and forwards the target service request to the target plug-in. The target plug-in processes the target request according to its set function to generate result data. This fundamentally eliminates the technical burden of developing an adaptation layer for different trusted verification scenarios in the traditional scheme, greatly reducing development costs.

[0148] The plug-ins maintained in the service system can include multiple plug-ins. Optionally, the preset plug-in set at least includes the following plug-ins: a signature plug-in sub-set, a signature verification plug-in sub-set, and a key management plug-in.

[0149] The core component of the service system includes a request processor, and the preset plug-in set includes plug-ins in the request processor. The plug-ins in the request processor can include a signature plug-in sub-set, a signature verification plug-in sub-set, and a key management plug-in. The signature plug-in sub-set can include a container image signature plug-in, a kernel module signature plug-in, and a Python package signature plug-in. The signature verification plug-in sub-set can include a container image signature verification plug-in, a kernel module signature verification plug-in, and a Python package signature verification plug-in. The key management plug-in is used to manage the generation, revocation, rotation, and other stages of the life cycle of the key.

[0150] The preset plug-in set can also include built-in plug-ins, such as a relational database plug-in that interacts with a relational database (such as a MySQL database) to store and retrieve data; a vault plug-in that interacts with a vault service (such as a Vault service) to manage keys and secrets; a key management system plug-in that interacts with a key management system (Key Management System) to create, store, rotate, and revoke keys; a public key infrastructure plug-in that interacts with a public key infrastructure (PublicKey Infrastructure) to handle certificates and signatures; and a container image plug-in that integrates with a container image ecosystem to sign and verify container images and related artifacts.

[0151] The preset plug-in set can also include third-party plug-ins, such as a stream log service plug-in (used to provide log stream processing and storage for collecting and analyzing audit logs of signature services) and other plug-ins for signature or verification operations in specific scenarios.

[0152] In order to store the data required by the plugins in the plugin set in the execution service and the generated data, the service system further comprises different key management systems (for example, a first key management system, a second key management system, a third key management system, etc.) for storing different built-in plugin-associated key pairs, certificates and other security assets, and a database for storing system metadata, audit information or user information.

[0153] Optionally, the service system further comprises a plugin manager for allocating running resources to the plugins in the preset plugin set in groups, and / or creating independent namespaces and system resources for different plugins in the preset plugin set, and / or automatically terminating the process in which the plugin is located when the main process of a plugin abnormally exits.

[0154] The plugin manager comprises a plugin resource manager for securely isolating different plugins, and the secure isolation can be in the form of running resource isolation, system resource isolation or link-level keep-alive.

[0155] The running resource isolation refers to running each plugin in an independent process, dividing the plugins into multiple groups, and allowing the operating system to allocate system resources (such as CPU (central processing unit) time, memory, disk I / O) to a group of processes rather than a single process. Compared with the static signing tool chain in the related art, the signing operation is ensured to be secure (blocking the unauthorized access of the plugin to the host), and the extensibility is not sacrificed.

[0156] The system resource isolation refers to allowing a process to create a new namespace, thereby being isolated from its parent process and other processes in the view of certain system resources. The process can have its own set of system resources (such as process ID, file system, network interface, etc.), thereby blocking its unauthorized access to the host environment.

[0157] The link-level keep-alive refers to setting parent-child process signal propagation, automatically terminating the plugin process when the main process abnormally exits, avoiding the residual of a zombie service (the zombie service no longer executes any code, but still occupies system resources and entries in the process table), and circumventing the process coupling risk of the traditional middleware solution.

[0158] In an optional embodiment, the plugin manager further comprises a plugin register for registering the plugin through a stored plugin registration strategy, a plugin monitor for monitoring the running of the plugin through a stored plugin monitoring strategy, and a plugin high-availability manager for ensuring the continuous availability and stable running of the plugin service through a fault recovery, load balancing, capacity backup and the like strategy.

[0159] Optionally, the service system further comprises a monitor configured to perform at least one of the following functions: collecting running resource usage of the plugins in the preset plugin set, monitoring running status of the plugins in the preset plugin set, recording log data generated by the plugins in the preset plugin set during execution of the services, and tracking execution of a key service by a key plugin in the preset plugin set.

[0160] The monitor can provide an index collection service configured to collect running resource usage of the plugins in the preset plugin set, such as CPU usage, memory occupation, request processing time, etc. The monitor can also provide a status monitoring service configured to monitor running status of the plugins in the preset plugin set, to ensure that the plugins can run normally. The monitor can also provide a log recording service configured to record log data generated by the plugins in the preset plugin set during execution of the services. The monitor can also provide an audit service configured to track and record a key service by a key plugin. For example, the key plugin can be a container image signing plugin, and the key service can be a signing service or a certificate management service. For example, the key plugin can be a kernel module signing plugin, and the key service can be a signing service or a key rotation service. For example, the key plugin can be a Python package signing plugin, and the key service can be a signing service or a signature verification service. For example, the key plugin can be a key management plugin, and the key service can be a key storage service or a key policy service, to ensure traceability and security of the key service by the key plugin. The monitor can also provide an observation service configured to observe running status of the service system, to provide a comprehensive status view of the service system.

[0161] The monitor of the embodiment not only facilitates efficient allocation of resources and performance optimization, but also improves control of the service system over the plugins, improves security, stability and compliance of the service system, reduces complexity of operation and maintenance of the service system, and improves overall service quality and user experience.

[0162] As an optional implementation, the service system further comprises an authentication component configured to perform identity verification on a user, and / or an authorization component configured to manage access rights of the user to the services and key usage rules.

[0163] When the user issues any initial service request to the service system through a preset interface, the gateway of the service system first converts the initial service request into an intermediate service request recognizable by the service system.

[0164] Then, the authentication component of the service system first checks the identity of the user, and the authentication component can store certificates, which include the identity information and public key of the certificate holder. The authentication component can also store user credentials, such as a username and password. The authentication component can also be configured with an IP access control policy based on CIDR (Classless Inter-Domain Routing) to define the access control range at the IP level.

[0165] The authentication of the authentication component includes but is not limited to comparing the AK / SK, OAuthtoken or other credentials provided by the user, ensuring that the request comes from an authenticated user, preventing unauthorized access and service abuse, and protecting the resources of the service system from illegal users.

[0166] After the user's identity is authenticated, a JWT (JSON Web Token) is attached to the request context, and the authorization component performs authentication based on the JWT and the policy to check whether the user has the right to access the service indicated by the request. The authorization component can include an RBAC model, which assigns permissions to users based on their roles in advance, and can also include an authorization protocol that allows limited access without exposing the user's credentials.

[0167] Permission verification can be based on an RBAC model, that is, the RBAC automatically determines the user's right to access a specific service based on the user's role, and determines whether the user has the right to access the service based on the user's role when the user accesses the service. Permission verification can also be based on an authorized user group, that is, the policy engine defines an authorized user group in advance, for example, only members of a specific user group are allowed to request such services for high-strength national cryptographic algorithms. If the user requests a key generation or signature service, the service system will check whether the user belongs to the "key administrator" or "signature permission user" group.

[0168] If the permission verification is passed, the service system checks whether the intermediate service request is associated with a key usage requirement, such as key generation, signature or signature verification service. If the request contains a key usage requirement, the service system further determines whether the requirement meets the pre-set key usage rules, such as key strength requirements, validity period limits, etc. For example, when a user attempts to generate an SM2 key for container image signature, the policy engine checks whether the user belongs to the pre-defined "national cryptographic algorithm user" group and whether the current signature scenario allows the use of the SM2 algorithm. If the key usage requirement meets the rules, the service system begins to parse the intermediate service request and extracts the request parameters to lay the data foundation for calling the corresponding plug-in to perform specific services.

[0169] The service system constructed by the embodiment covers a unified signature abstraction layer of the whole life cycle of software. A user can input a simple command to call a corresponding service, support full-chain audit of key generation, signature operation, and certificate rotation, support operation traceability across key management systems, solve problems such as tool chain fragmentation, key management risks, and lack of policy control, and achieve the purpose of unified multi-scene signature operation and security in-depth defense.

[0170] According to the embodiments of the application, a device for implementing the processing method of the service request is also provided, Figure 7 is a schematic diagram of a service request processing device according to an embodiment of the application, as Figure 7 shown, the device comprises:

[0171] The first receiving unit 702 is configured to receive an initial service request through a preset interface, wherein the preset interface supports user input of a command line request and converts the command line request into the initial service request.

[0172] The first conversion unit 704 is configured to determine a request parameter required for executing a target trusted verification service according to the initial service request, and convert the request parameter into a target service request conforming to a preset protocol, wherein the request parameter at least includes a target type identifier of the target trusted verification service.

[0173] The first calling unit 706 is configured to call a target plug-in matching the target type identifier from a preset plug-in set to process the target service request, to obtain a service result of the target trusted verification service, wherein the preset plug-in set includes different plug-ins for processing different trusted verification services.

[0174] Optionally, the first calling unit 706 includes a query module configured to query a plug-in matching the target type identifier from a plug-in registry to obtain the target plug-in, wherein the plug-in registry stores information of the plug-in corresponding to different type identifiers of different trusted verification services in the form of key-value pairs; and a forwarding module configured to forward the target service request to the target plug-in and obtain a service result fed back by the target plug-in, wherein the target plug-in is used to execute a target trusted verification service of a target type to obtain the service result.

[0175] Optionally, in the case that the target service request is a signature request, the target type identifier is a target signature type identifier, and the first calling unit 706 includes a first determination module configured to determine a target signature plug-in matching the target signature type identifier from the preset plug-in set; and a first calling module configured to call the target signature plug-in to process the signature request to obtain a signature result, wherein the target signature plug-in is used to execute a signature service of a target signature type based on a signature parameter in the signature request to obtain the signature result.

[0176] Optionally, in the case that the target service request is a signature verification request, the target type identifier is a target signature verification type identifier, and the first calling unit 706 includes: a second determination module configured to determine, from the preset plug-in set, a target signature verification plug-in matching the target signature verification type identifier; and a second calling module configured to call the target signature verification plug-in to process the signature verification request and obtain a signature verification result, wherein the target signature verification plug-in is configured to perform a signature verification service of a target signature verification type based on a signature verification parameter in the signature verification request, and obtain the signature verification result.

[0177] Optionally, in the case that the target service request is a key generation request, the target type identifier is a target key generation type identifier, and the first calling unit 706 includes: a third determination module configured to determine, from the preset plug-in set, a key management plug-in matching the target key generation type identifier, and call the key management plug-in to process the key generation request and generate a key conforming to a preset rule, wherein the key conforming to the preset rule is at least associated with the target key generation type identifier; and the apparatus further includes: a scanning module configured to, after calling the target plug-in matching the target type identifier from the preset plug-in set to process the target service request and obtaining a service result of the target trusted verification service, store the key in a database, regularly scan an effective period of the key, and before the key expires, call the key management plug-in again to generate a new key and update an associated certificate of the key.

[0178] Optionally, the first conversion unit 704 includes a request parameter determination module configured to determine a request parameter required for performing the target trusted verification service according to the initial service request, and the request parameter determination module includes: a conversion submodule configured to convert the initial service request into an intermediate service request conforming to a preset protocol; an analysis submodule configured to analyze the intermediate service request to obtain a first type of parameter, and obtain a second type of parameter according to a service parameter required by the target trusted verification service based on address information in the first type of parameter, wherein the first type of parameter at least includes a function identifier of the target trusted verification service, the target type identifier, and the address information; and a determination submodule configured to determine the request parameter according to the first type of parameter and the second type of parameter.

[0179] Optionally, the apparatus further includes: an identity checking unit configured to perform identity checking on a user after converting the initial service request into the intermediate service request conforming to the preset protocol; a permission checking unit configured to perform permission checking on the user in the case that the identity checking is passed, wherein the permission checking is configured to check whether the user is allowed to access the target trusted verification service; a judgment unit configured to, in the case that the permission checking is passed, judge whether a key usage demand associated with the intermediate service request conforms to a key usage rule; and an execution unit configured to, in the case that the key usage demand conforms to the key usage rule, perform the step of analyzing the intermediate service request to obtain the first type of parameter.

[0180] Optionally, the apparatus further comprises: an acquisition unit, configured to acquire log data generated by the target plug-in in the process of executing the target trusted verification service after calling the target plug-in matching the target type identifier from the preset plug-in set to process the target service request; and a pushing unit, configured to write the log data into an audit database and push the log data to an audit service through a monitoring stack.

[0181] According to the embodiments of the present application, a device for implementing the processing method of the service request is further provided, Figure 8 is a schematic diagram of another device for processing a service request according to an embodiment of the present application, as Figure 8 shown, the device comprises:

[0182] The second receiving unit 802 is configured to receive the intermediate service request sent by the gateway, wherein the gateway is configured to convert the initial service request into the intermediate service request conforming to the preset protocol, and the initial service request is a request converted from a command line request input by a user;

[0183] The second conversion unit 804 is configured to determine a request parameter required for executing the target trusted verification service according to the intermediate service request, and convert the request parameter into the target service request conforming to the preset protocol, wherein the request parameter at least comprises a target type identifier of the target trusted verification service;

[0184] The second calling unit 806 is configured to call the target plug-in matching the target type identifier from a preset plug-in set to process the target service request, to obtain a service result of the target trusted verification service, wherein the preset plug-in set comprises different plug-ins for processing different trusted verification services.

[0185] The above units or modules correspond to the steps in the above embodiments. The above units or modules have the same instances and application scenarios as the corresponding steps, but are not limited to the disclosed content in the above embodiments. It should be noted that the above units or modules can be hardware components or software components stored in a memory (for example, the memory 104) and processed by one or more processors (for example, the processors 102a, 102b, …, 102n). The above units or modules can also be a part of the device and can run in the computer terminal 10 provided in the above embodiments.

[0186] The preferred embodiments involved in the above embodiments of the present application have the same scheme, application scenario and implementation process as the above embodiments, and will not be repeated here.

[0187] The embodiments of the present application can provide an electronic device, which can be any one of the electronic devices in the electronic device group. Optionally, in the present embodiment, the above electronic device can also be replaced by a terminal device such as a mobile terminal.

[0188] Optionally, in the embodiment, the electronic device can be located in at least one of the plurality of network devices of the computer network.

[0189] In the embodiment, the computer terminal can execute the program code in the method.

[0190] Optionally, Figure 9 is a structural block diagram of an electronic device according to an embodiment of the present application. As Figure 9 shown, the electronic device A can include one or more (one is shown in the figure) processors 102, a memory 104, a storage controller, and a peripheral interface. The peripheral interface is connected with a radio frequency module, an audio module, and a display. Figure 9

[0191] The memory can be used to store software programs and modules, such as program instructions / modules corresponding to the method and device in the embodiments of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, implements the method in the above embodiments. The memory can include a high-speed random access memory, and can further include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory can further include a memory remotely arranged with respect to the processor, which can be connected to the terminal A through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0192] The processor can call the executable program stored in the memory through the transmission device to execute the method in the various embodiments of the present application.

[0193] Those skilled in the art can understand that the structure shown in Figure 9 is a schematic structure. The electronic device can also be a terminal device such as a smart phone, a tablet computer, a palm computer, a Mobile Internet Device (MID), a PAD, etc. The Figure 9 does not limit the structure of the above electronic device. For example, the electronic device A can further include more or less components (such as a network interface, a display device, etc.) than those shown in the Figure 9 or have a different configuration from that shown in the Figure 9 .

[0194] ​Those skilled in the art can understand that all or part of the steps of various methods in the above embodiments can be instructed by programs to terminal device related hardware. The programs can be stored in a computer readable storage medium. The storage medium can include a flash disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0195] The embodiments of the present application further provide a computer readable storage medium. Optionally, in the embodiments, the computer readable storage medium can be used to store the program codes executed by the methods provided by the embodiments.

[0196] Optionally, in the embodiments, the storage medium can be located in any one of the electronic devices in the computer network or in any one of the mobile terminals in the mobile terminal group.

[0197] Optionally, in the embodiments, the computer readable storage medium includes a stored executable program, wherein the executable program is executed by the processor to implement the methods in the embodiments of the present application.

[0198] The embodiments of the present application further provide a computer program product. Optionally, in the embodiments, the computer program product can include a computer program, and the computer program is executed by the processor to implement the methods provided by the embodiments.

[0199] The embodiments of the present application further provide a computer program product. Optionally, the computer program product can include a non-volatile computer readable storage medium. The non-volatile computer readable storage medium can be used to store a computer program. The computer program is executed by the processor to implement the methods provided by the embodiments.

[0200] The embodiments of the present application further provide a computer program. Optionally, in the embodiments, the computer program is executed by the processor to implement the methods provided by the embodiments.

[0201] In the above embodiments of the present application, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0202] In several embodiments provided in the present application, the disclosed technical contents can be implemented in other manners. Of course, the described apparatus embodiments are merely schematic, and the division of units is merely logical function division. There can be other division manners in actual implementation, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed coupling or direct coupling or communication connection between units can be indirect coupling or communication connection through some interfaces, and can be electrical or other forms.

[0203] The units described as separate components can or can not be physically separate, and the components displayed as units can or can not be physical units, that is, can be located in one place or distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0204] In addition, each functional unit in the various embodiments of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0205] When the integrated unit is realized in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The foregoing storage medium includes: a U disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store program codes.

[0206] The above is the preferred embodiment of the present application. For those skilled in the art, without departing from the principles of the present application, some improvements and refinements can be made, which should also be considered as the protection scope of the present application.

Claims

1. A method for processing service requests, characterized in that, include: The system receives an initial service request through a preset interface, wherein the preset interface supports user input of command line requests and converts the command line requests into the initial service request. The request parameters required to execute the target trusted verification service are determined based on the initial service request, and the request parameters are converted into a target service request that conforms to a preset protocol, wherein the request parameters include at least the target type identifier of the target trusted verification service; The target service request is processed by calling the target plugin that matches the target type identifier from the preset plugin set to obtain the service result of the target trusted verification service. The preset plugin set includes different plugins for processing different trusted verification services.

2. The method according to claim 1, characterized in that, The service result of obtaining the target trusted verification service by calling the target plugin that matches the target type identifier from the preset plugin set to process the target service request includes: The target plugin is obtained by querying the plugin registry to find the plugin that matches the target type identifier. The plugin registry stores information about the plugins corresponding to different type identifiers of different trusted verification services in the form of key-value pairs. The target service request is forwarded to the target plugin, and the service result fed back by the target plugin is obtained. The target plugin is used to execute the target trusted verification service of the target type and obtain the service result.

3. The method according to claim 1, characterized in that, When the target service request is a signature request, the target type identifier is a target signature type identifier. The target plugin matching the target type identifier is called from a preset plugin set to process the target service request, and the service result of the target trusted verification service includes: Determine the target signature plugin that matches the target signature type identifier from the preset plugin set; The target signature plugin is invoked to process the signature request and obtain a signature result. The target signature plugin is used to perform a signature service of the target signature type based on the signature parameters in the signature request and obtain the signature result.

4. The method according to claim 1, characterized in that, When the target service request is a signature verification request, the target type identifier is a target signature verification type identifier. The target plugin matching the target type identifier is called from a preset plugin set to process the target service request, and the service result of the target trusted verification service includes: Determine the target signature verification plugin that matches the target signature verification type identifier from the preset plugin set; The target signature verification plugin is invoked to process the signature verification request and obtain a signature verification result. The target signature verification plugin is used to execute a signature verification service of the target signature verification type based on the signature verification parameters in the signature verification request and obtain the signature verification result.

5. The method according to claim 1, characterized in that, When the target service request is a key generation request, the target type identifier is a target key generation type identifier. The target plugin matching the target type identifier is called from a preset plugin set to process the target service request, and the service result of the target trusted verification service includes: A key management plugin matching the target key generation type identifier is determined from the preset plugin set, and the key management plugin is invoked to process the key generation request and generate a key that conforms to the preset rules, wherein the key that conforms to the preset rules is associated with at least the target key generation type identifier; After invoking a target plugin matching the target type identifier from a preset plugin set to process the target service request and obtaining the service result of the target trusted verification service, the method further includes: The key is stored in the database, and its validity period is scanned periodically. Before the key expires, the key management plugin is called again to generate a new key and update the associated certificate of the key.

6. The method according to claim 1, characterized in that, The request parameters required to execute the target trusted verification service, as determined by the initial service request, include: The initial service request is converted into an intermediate service request that conforms to the preset protocol; The intermediate service request is parsed to obtain a first type of parameters, and the service parameters required by the target trusted verification service are obtained based on the address information in the first type of parameters to obtain a second type of parameters. The first type of parameters includes at least the function identifier of the target trusted verification service, the target type identifier, and the address information. The request parameters are determined based on the first type of parameters and the second type of parameters.

7. The method according to claim 6, characterized in that, After converting the initial service request into an intermediate service request conforming to the preset protocol, the method further includes: The user's identity is verified; If the identity verification passes, the user's permissions are verified, wherein the permission verification is used to verify whether the user is allowed to access the target trusted verification service; If the permission verification passes, and the intermediate service request is associated with a key usage requirement, determine whether the key usage requirement complies with the key usage rules. If the key usage requirement meets the key usage rules, the step of parsing the intermediate service request to obtain the first type of parameters is performed.

8. The method according to any one of claims 1 to 7, characterized in that, After invoking a target plugin from a preset plugin set that matches the target type identifier to process the target service request, the method further includes: Obtain the log data generated by the target plugin during the execution of the target trusted verification service; The log data is written to the audit database and pushed to the audit service through the monitoring stack.

9. A method for processing service requests, characterized in that, include: The system receives intermediate service requests sent by a gateway, wherein the gateway is used to convert an initial service request into an intermediate service request that conforms to a preset protocol, and the initial service request is a request obtained by converting a command line request input by the user. The intermediate service request determines the request parameters required to execute the target trusted verification service, and converts the request parameters into a target service request that conforms to a preset protocol, wherein the request parameters include at least the target type identifier of the target trusted verification service; The target service request is processed by calling the target plugin that matches the target type identifier from the preset plugin set to obtain the service result of the target trusted verification service. The preset plugin set includes different plugins for processing different trusted verification services.

10. A service system, characterized in that, include: A gateway is used to receive initial service requests through a preset interface, wherein the preset interface supports user input command line requests and converts the command line requests into the initial service requests; The scheduler and a set of preset plugins are configured to determine the request parameters required to execute the target trusted verification service based on the initial service request, convert the request parameters into a target service request that conforms to a preset protocol, determine the target plugin that matches the target type identifier in the request parameters from the set of preset plugins, and call the target plugin to process the target service request to obtain the service result of the target trusted verification service. The set of preset plugins includes different plugins for processing different trusted verification services.

11. The service system according to claim 10, characterized in that, The service system also includes a plugin manager, which includes: A security isolation component is used to allocate runtime resources to plugins in the preset plugin set in groups, and / or to create independent namespaces and system resources for different plugins in the preset plugin set, and / or to automatically terminate the process where a plugin resides when the main process of a plugin exits abnormally.

12. The service system according to claim 10, characterized in that, The preset plugin set includes at least the following plugins: Subset of signature plugins, subset of signature verification plugins, and key management plugin.

13. The service system according to claim 10, characterized in that, The service system also includes: The monitor is configured to perform at least one of the following functions: collect the runtime resource usage of plugins in the preset plugin set, monitor the runtime status of plugins in the preset plugin set, record log data generated by plugins in the preset plugin set during service execution, and track the process of key plugins in the preset plugin set executing key services.

14. The service system according to any one of claims 10 to 13, characterized in that, The service system also includes: An authentication component is used to verify the identity of the user; And / or, an authorization component for managing user access permissions to the service and managing key usage rules.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 9.

16. A computer program product, characterized in that, The method includes a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 9.

Images