Function calling method, device, equipment, medium and program product

Abstract

The present application discloses a function calling method, device, equipment, medium and program product, the method comprising: receiving a calling request sent by a requesting end for calling a kernel function of an operating system; performing identity authentication on the requesting end based on a session key of a security bus and the calling request; the session key of the security bus is obtained through negotiation between the security bus and the requesting end; if the identity authentication of the requesting end passes, determining a calling method for calling the kernel function of the operating system based on the function type of the kernel function; and calling the kernel function based on the calling method. In this way, the efficiency of the requesting end in calling the kernel function of the operating system can be improved.

Description

Technical Field

[0001] The present application relates to but is not limited to the field of information security technology, and in particular to a function calling method, device, equipment, medium and program product. Background Art

[0002] The shell script call of the command line interpreter is often used as a means for the application layer of the cryptographic product to call the kernel function of the operating system. However, with the increase in the number and complexity of shell scripts, the method of directly calling the kernel function of the operating system through shell scripts, or indirectly calling the kernel function of the operating system through shell scripts through middleware may lead to a significant reduction in the efficiency of function calls. At the same time, when calling the kernel function of the operating system through middleware, the account password is used for authentication, and the account password is easily obtained by a third party, thereby reducing the security of calling the kernel function. Summary of the invention

[0003] In view of this, embodiments of the present application at least provide a function calling method, apparatus, device, medium and program product.

[0004] The technical solution of the embodiment of the present application is implemented as follows:

[0005] In a first aspect, an embodiment of the present application provides a function calling method, which is applied to a security bus; the function calling method includes: receiving a call request sent by a requesting end for calling a kernel function of an operating system; authenticating the requesting end based on a session key of the security bus and the call request; the session key of the security bus is obtained through negotiation between the security bus and the requesting end; when the identity authentication of the requesting end passes, determining a calling method for calling the kernel function of the operating system based on a function type of the kernel function; and calling the kernel function based on the calling method.

[0006] In an embodiment of the present application, by receiving a call request for calling a kernel function of an operating system sent by a requesting end, the security bus can obtain the kernel function requested by the requesting end to call, and the session key sent by the requesting end to establish a secure session with the security bus. Then the security bus authenticates the identity of the requesting end based on the session key of the requesting end. After the identity authentication of the requesting end is passed, the calling method for calling the kernel function is determined based on the function type of the kernel function requested by the requesting end to call. Finally, the kernel function of the operating system requested by the requesting end is called based on the determined calling method. In this way, by authenticating the identity of the requesting end, the security of the requesting end when calling the kernel function of the operating system is improved. In addition, according to the function type of the kernel function, different calling methods are adaptively selected to improve the efficiency of the requesting end calling the kernel function of the operating system.

[0007] In a second aspect, an embodiment of the present application provides a function calling method, which is applied to a security bus; the function calling method comprises: sending a call request for calling a kernel function of an operating system to the security bus; wherein the security bus is used to authenticate the identity of the requesting end based on the session key of the requesting end; when the identity authentication of the requesting end is passed, the kernel function of the operating system is called based on a calling method corresponding to the function type of the kernel function of the operating system.

[0008] In a third aspect, an embodiment of the present application provides a function calling device, which is applied to a requesting end; the function calling device includes: a server, which is used to receive a calling request sent by the requesting end for calling a kernel function of an operating system; an authentication unit, which is used to authenticate the identity of the requesting end based on a session key of a security bus and a calling request; the session key of the security bus is obtained by negotiation between the security bus and the requesting end; a management interface unit, which is used to determine a calling method for calling the kernel function of the operating system based on a function type of the kernel function when the identity authentication of the requesting end passes; and calling the kernel function based on the calling method.

[0009] In a fourth aspect, an embodiment of the present application provides a function calling device, including a memory and a processor, wherein the memory stores a computer program that can be executed on the processor, and when the processor executes the program, some or all of the steps in the above method are implemented.

[0010] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which implements some or all of the steps in the above method when executed by a processor.

[0011] In a sixth aspect, an embodiment of the present application provides a computer program product, including a computer program or instructions, which implement some or all of the steps in the above method when executed by a processor.

[0012] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and are used together with the specification to illustrate the technical solution of the present application.

[0014] Figure 1 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 1 ;

[0015] Figure 2A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 2 ;

[0016] Figure 3 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 3 ;

[0017] Figure 4 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 4 ;

[0018] Figure 5 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 5 ;

[0019] Figure 6 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 6 ;

[0020] Figure 7 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 7 ;

[0021] Figure 8 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 8 ;

[0022] Fig. 9 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 9 ;

[0023] Fig.10 A schematic diagram of a secure bus architecture provided in an embodiment of the present application Figure 1 ;

[0024] Fig.11 A schematic diagram of a secure bus architecture provided in an embodiment of the present application Figure 2 ;

[0025] Fig.12 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 10 ;

[0026] Fig.13 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 10 one;

[0027] Fig.14 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 10 two;

[0028] Fig.15 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 10 three;

[0029] Fig.16 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 10 Four;

[0030] Fig.17 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 10 five;

[0031] Fig.18 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 10 six;

[0032] Fig.19 A schematic diagram of the structure of a function calling device provided in an embodiment of the present application;

[0033] Fig. 20 A schematic diagram of a hardware entity of a function calling device in an embodiment of the present application. DETAILED DESCRIPTION

[0034] In order to make the purpose, technical solutions and advantages of the present application clearer, the technical solutions of the present application are further elaborated in detail below in conjunction with the drawings and embodiments. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0035] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0036] The terms "first / second / third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It is understandable that "first / second / third" can be interchanged with a specific order or sequence where permitted so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0037] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing this application and are not intended to limit this application.

[0038] Before describing the function calling method in the embodiment of the present application, the professional terms involved in the embodiment of the present application are first explained:

[0039] Security Bus (SBUS): A middleware used for data transmission between application layer requests (such as network and firewall configuration) of cryptographic products (such as cryptographic machines, cryptographic servers, and signature verification servers) and the kernel of the Linux operating system.

[0040] SM2 algorithm: an asymmetric cryptographic algorithm based on elliptic curve.

[0041] SM4 algorithm: A symmetric encryption algorithm, also known as the SM4 block cipher algorithm.

[0042] PBKDF2 (Password-Based Key Derivation Function 2): used to derive keys through a pseudo-random function.

[0043] Transmission Control Protocol (TCP): A connection-oriented, reliable, byte-stream-based transport layer communication protocol.

[0044] RESTFull: is a software architecture style that describes and implements the interface of Web services based on the standard method of HTTP protocol.

[0045] TLV (Tag-Length-Value): data exchange format with data type and length.

[0046] Golang: A statically strongly typed, compiled language.

[0047] Desktop Bus (DBUS): is a system bus used in Linux and other Unix-like operating systems.

[0048] Middleware (Open Wrtmicro Bus, UBUS): is a type of software between the application system and the system software. It uses the basic services (functions) provided by the system software to connect the various parts of the application system or different applications on the network, and can achieve the purpose of resource sharing and function sharing.

[0049] Netlink: An inter-process communication (Instruction Per Clock, IPC) method between user-mode programs and kernel modules in the Linux system.

[0050] Collaborative computing: cryptographic computing completed through interactive collaboration between two parties.

[0051] SBUSROOT: The requester and the secure bus jointly calculate the negotiated root key.

[0052] SBUSDMK: SBUSROOT derives a Message Authentication Code (MAC) authentication key based on PBKDF2, which is used to verify the integrity of the data.

[0053] PBKDF2: The algorithm can derive a symmetric key from any byte string (refer to RFC 2898).

[0054] Hash-based Message Authentication Code (HMAC): A method of message authentication based on a hash function and a secret key.

[0055] Hypertext Transfer Protocol (HTTP): is a simple request-response protocol. HTTP usually runs on top of TCP.

[0056] JSON (JavaScript Object Notation): is a lightweight data exchange format.

[0057] OpenWrt: Embedded Linux distribution, an open source, Linux-based embedded operating system designed for routers and embedded devices.

[0058] FASTHTTP: is a high-performance HTTP server and client library.

[0059] An Application Programming Interface (API) is a set of predefined functions that aims to provide applications and developers with the ability to access a set of routines based on certain software or hardware without having to access the source code.

[0060] In the field of information security technology, the existing function call mechanisms mainly cover three ways:

[0061] The first approach is to directly use shell calls to interact with the kernel of the operating system. Shell scripts are interpreted languages, that is, they need to be interpreted by the interpreter each time they are executed, resulting in low efficiency of function calls.

[0062] The second approach is to use a lightweight DBUS system in a Linux environment. First, although the DBUS system is powerful, it is complex and has a large source code size, including more than 100 files and a total size of nearly 2MB. Second, the interface design of DBUS is complex, and XML files are used to define interface details. Even with the help of libraries such as glib for binding, application developers still need to write relatively more code and have a deep understanding of the internal mechanism and working principle of DBUS. The complex syntax makes development and implementation difficult. In the DBUS system, when multiple threads request the same service, unpredictable results may occur, resulting in low efficiency of function calls. Third, due to low concurrency, it is only suitable for the transmission of a small amount of data. When calling complex functions, the efficiency of function calls is very low. Finally, the DBUS system is non-transactional and does not support rollback. When multiple operations are treated as a task, if the operation fails, the operation before the error will be executed, making it difficult to ensure data consistency, which increases the complexity and risk of data management. In other words, in order not to affect data consistency, multiple operations cannot be treated as the same task, resulting in low efficiency of function calls.

[0063] The third approach is for embedded Linux systems such as routers, such as OpenWrt, which also uses a more lightweight UBUS mechanism to meet the needs of efficient communication in resource-constrained environments. First, the UBUS system is only suitable for the transmission of small amounts of data, and has a maximum transmission data limit of 60 kilobytes (kb). When multiple threads request the same service, unpredictable results may occur, resulting in low efficiency of function calls. Secondly, the DBUS system is non-transactional and does not support rollback. In other words, in order not to affect data consistency, multiple operations cannot be treated as the same task, resulting in low efficiency of function calls.

[0064] In addition, the existing function calling method cannot solve the problem that the error code or error message prompt is not friendly enough when executing abnormally. In addition, the existing function calling method uses account password login for authentication. After successful login, a session identity document (Session ID) will be returned for accessing the bus. However, the credentials are easy to leak, the passwords are easy to forget, the authentication efficiency is low, and it is easy to cause information leakage, resulting in low efficiency and security of function calling.

[0065] In order to solve the problems of the related art, the embodiment of the present application provides a function calling method, which can be applied to a security bus. Figure 1 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 1 ,like Figure 1As shown, the function calling method can be implemented through steps S101 to S104:

[0066] Step S101, receiving a call request for calling a kernel function of an operating system sent by a requesting end.

[0067] Here, the requesting end may be a cryptographic product for invoking a kernel function of an operating system. Exemplarily, the cryptographic product may be software, a chip, a complete machine, and a system.

[0068] The operating system is a built-in program that cooperates with various hardware of the computer to interact with the user. Exemplarily, the operating system may include at least one of the following: Windows, MacOS, Linux, and Huawei Hongmeng system.

[0069] The kernel is the most basic part of the operating system, and is a part of the kernel functions used to provide secure access to computer hardware for numerous application programs. Exemplarily, the kernel functions may include network configuration and firewall configuration.

[0070] In the embodiment of the present application, the secure bus can receive a call request for calling a kernel function of an operating system sent by a requesting end through its own server. Exemplarily, the server can be a fiber server.

[0071] It is understandable that before the secure bus calls the kernel function of the operating system, the secure bus needs to obtain the call request sent by the requesting end to determine the kernel function call requirement of the requesting end, and call the kernel function of the operating system according to the kernel function call requirement. In other words, each time the secure bus calls the kernel function of the operating system, it needs to re-receive the call request sent by the requesting end for calling the kernel function of the operating system.

[0072] Step S102: Authenticate the requesting end based on the session key of the secure bus and the calling request.

[0073] The session key of the secure bus is obtained through negotiation between the secure bus and the requesting end.

[0074] In an embodiment of the present application, the session key is used to encrypt and decrypt information transmitted in a session during network communication or data exchange. The session key is only valid in the current session and is discarded after the session ends. A new session key needs to be regenerated for the next communication.

[0075] In some embodiments, the negotiation method for obtaining the session key by the secure bus and the requesting end may include symmetric key negotiation and public key negotiation.

[0076] Symmetric key negotiation includes exchanging keys between two communicating parties through a secure channel. For example, the two communicating parties negotiate a key in advance and keep it secret, and before the communication begins, the two parties exchange the key through a secure channel.

[0077] Among them, public key key negotiation includes that each communication party has a pair of keys, namely a public key and a private key. The public key can be made public and is used to encrypt data, and the private key must be kept confidential and is used to decrypt data. The two communicating parties use the other party's public key to encrypt the communication data and use their own private key to decrypt the encrypted data.

[0078] In an embodiment of the present application, after the security bus receives a call request sent by the requesting end through the server for calling the kernel function of the operating system, the security bus can authenticate the identity of the requesting end through its own authentication unit based on the session key of the security bus and the call request.

[0079] It is understandable that the security bus does not directly call the kernel function of the operating system according to the call request. This is because when the kernel function of the operating system is called directly according to the call request, any cryptographic product can access, modify or destroy the data and kernel function of the operating system without authorization, posing a serious threat to the security of the operating system. In the embodiment of the present application, the request end is authenticated based on the session key of the security bus and the call request sent by the request end, so as to ensure that the authorized request end can call the kernel function of the operating system.

[0080] Step S103, when the identity authentication of the requesting end is passed, a calling method of calling the kernel function of the operating system is determined based on the function type of the kernel function.

[0081] It is understandable that the kernel functions can be divided into different function types according to different division methods, and different function types correspond to different calling methods. That is to say, each time the security bus calls the kernel function of the operating system, it needs to reselect the calling method corresponding to the kernel function type through the management interface unit.

[0082] Exemplarily, the kernel functions can be divided into built-in functions and non-built-in functions according to whether they are built-in to the kernel, and the built-in functions correspond to calling mode 1, and the non-built-in functions correspond to calling mode 2. The kernel functions can also be divided into software functions, hardware functions, and network functions according to the technical implementation division method, and the software functions correspond to calling mode 1, the hardware functions correspond to calling mode 2, and the network functions correspond to calling mode 3.

[0083] Step S104, calling the kernel function based on the calling method.

[0084] In the embodiment of the present application, the security bus receives a call request for calling the kernel function of the operating system sent by the requesting end through the server. When the call request is legal, the security bus can obtain the kernel function requested by the requesting end through the management interface unit, as well as the session key sent by the requesting end for establishing a secure session with the security bus. Then the security bus authenticates the identity of the requesting end based on the session key of the requesting end through the authentication unit. After the identity authentication of the requesting end is passed through the management interface unit of the security bus itself, the security bus determines the calling method for calling the kernel function based on the function type of the kernel function requested by the requesting end. Finally, the security bus calls the kernel function of the operating system requested by the requesting end through the management interface unit based on the determined calling method. In this way, the security bus authenticates the identity of the requesting end through the authentication unit, thereby improving the security of the requesting end when calling the kernel function of the operating system. In addition, the security bus adaptively selects different calling methods according to the function type of the kernel function through the management interface unit, which can improve the efficiency of the requesting end calling the kernel function of the operating system.

[0085] In some embodiments, the above call request carries message header information and message body information, such as Figure 2 As shown, the above step S102 can be implemented through step S201 and step S202:

[0086] Step S201: if there is authentication information in the message header information and the authentication information is legal, extract the authentication information of the requesting end in the message header information.

[0087] The authentication information of the requesting end is obtained by encrypting the message body information based on the session key of the requesting end; the session key of the requesting end is obtained based on the negotiation between the requesting end and the security bus.

[0088] Among them, the message header and the message body together constitute the basic unit of the message in network communication, and the message is the information carrier exchanged between the sender and the receiver. The message header provides basic information and transmission control information about the message, while the message body contains specific data content. The two cooperate with each other to ensure the reliable transmission and correct processing of data in network communication. Exemplarily, when the request end and the security bus exchange data through the HTTP protocol, network layer protocol, link layer protocol or other transport layer protocol, it is necessary to exchange messages between the request end and the security bus, wherein after the request end sends a request to the security bus, the message transmitted through the network protocol may include a message header containing request method information, and a message body containing request content, such as pictures, videos, etc.

[0089] It is understandable that the message header information contains authentication information obtained by encrypting the message body information by the requesting end using the session key of the requesting end. The authentication information can be saved in the message header information by using Base64 encoding or hexadecimal encoding conversion and other format conversion methods according to different format requirements. The authentication unit of the security bus can check the various fields of the message header information sent by the requesting end, and query whether there is a field name or value that meets the encrypted field characteristics in the message header information. If there is a field name or value that meets the encrypted field characteristics in the message header information, the call request carrying the message header information and the message body information is sent to the authentication unit of the security bus to obtain the authentication information contained in the message header information.

[0090] In some embodiments, if the authentication unit of the security bus does not query the field name or value that meets the characteristics of the encrypted field, it is determined that the message header information does not contain authentication information. If the field name or value that meets the characteristics of the encrypted field is queried, it is determined that the message header information includes authentication information.

[0091] In the case where the authentication information exists in the message header information, it is determined whether the authentication information satisfies the data format corresponding to the format conversion method to determine whether the authentication information is legal. Exemplarily, in the case where the authentication information is saved in the authorization field of the message header information by using the Base64 encoding format conversion method, it is determined whether the authentication information complies with the data format specified by the Base64 encoding. If it complies, the authentication information is determined to be legal, otherwise it is illegal; in the case where the authentication information is saved in the authorization field of the message header information by using the hexadecimal encoding format conversion method, it is determined whether the authentication information complies with the data format specified by the hexadecimal encoding. If it complies, the authentication information is determined to be legal, otherwise it is illegal. In the case where the authentication information exists and the authentication information is legal, the security bus will parse the message header information and extract the authentication information of the requesting end in the message header information.

[0092] Among them, Base64 encoding is a method of representing binary data based on 64 printable characters. It uses 64 characters (including uppercase letters AZ, lowercase letters az, numbers 0-9, plus sign +, slash / ) to represent binary data. Hexadecimal encoding is a counting system with a base of 16, using a radix of 16. It uses numbers 0-9 and letters AF (or af, case-insensitive) to represent values, where AF represents 10-15.

[0093] Step S202: Authenticate the identity of the requesting end based on the authentication information of the requesting end, the message body information and the session key of the secure bus.

[0094] In the embodiment of the present application, the security bus obtains the authentication information of the requesting end obtained by encrypting the message body information by the requesting end through the authentication unit, and encrypts the message body information based on the session key of the security bus through the encryption method pre-determined with the requesting end to obtain the authentication information of the security bus. When the authentication information of the requesting end is the same as the authentication information of the security bus, the security bus determines through the authentication unit whether the identity authentication of the requesting end has passed, otherwise, the identity authentication of the requesting end has failed.

[0095] It is understandable that the call request of the requesting end includes the message body information and the authentication information obtained by encrypting the message body information based on the session key. When authenticating the requesting end, the security bus and the requesting end encrypt the same authentication information through the same encryption method. If the encryption keys used by the two are also the same, the authentication information of the security bus and the authentication information of the requesting end should be consistent. Therefore, the identity of the requesting end can be authenticated based on the authentication information of the requesting end, the message body information and the session key of the security bus. In other words, when the authentication information exists in the message header information and the authentication information is legal, the authentication information of the requesting end in the message header information is extracted, and the identity of the requesting end is authenticated based on the authentication information of the requesting end, the message body information and the session key of the security bus.

[0096] In some embodiments, the identity of the requesting end is authenticated based on the authentication information of the requesting end, the message body information and the session key of the secure bus, which can include using the SBUSDMK negotiated with the requesting end to calculate the message body information, obtain the HMAC value of the secure bus (i.e., the authentication information above), parse the call request to obtain the HMAC value and message body information in the parsed message header, and verify whether the HMAC value of the requesting end is consistent, and reject illegal requests.

[0097] In some embodiments, the message body information may be preset data. For example, the message body information may be / x00*16.

[0098] In an embodiment of the present application, the security bus receives a call request sent by a requesting end and carrying message header information and message body information. When the message header information contains authentication information and the authentication information is legal, the call request carrying the message header information and message body information is transmitted to the authentication unit of the security bus. The authentication unit of the security bus parses the authentication information obtained by encrypting the message body information based on the requesting end's own session key, and performs identity authentication on the requesting end based on the authentication information of the requesting end and the authentication information of the security bus. In this way, the requesting end and the security bus respectively encrypt the same message body information to obtain authentication information, and perform identity authentication on the requesting end by comparing the authentication information of the requesting end and the authentication information of the security bus, which can reduce the risk of data leakage of the session keys of the requesting end and the security bus, and improve the security of the requesting end when calling the kernel function of the operating system.

[0099] In some embodiments, Figure 3 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 3 ,like Figure 3 As shown, the above step S202 can be implemented through steps S301 to S303:

[0100] Step S301, encrypting the message body information based on the session key of the secure bus to obtain the authentication information of the secure bus.

[0101] In some embodiments, the authentication unit of the secure bus uses an encryption algorithm and its own session key to encrypt the message body information sent by the requesting end to obtain the authentication information of the secure bus. Exemplarily, the encryption method may be an SM4 algorithm.

[0102] Step S302: When the authentication information of the secure bus is consistent with the authentication information of the requesting end, it is determined that the identity authentication of the requesting end is passed.

[0103] It is understandable that the security bus and the requesting end encrypt the same authentication information through the same encryption method. If the encryption keys used by the two are also the same, the authentication information of the security bus and the authentication information of the requesting end should be consistent. Therefore, when the authentication information of the security bus is consistent with the authentication information of the requesting end, it is determined that the session key of the security bus is consistent with the session key of the requesting end, that is, the identity authentication of the requesting end is passed. In other words, the message body information is encrypted based on the session key of the security bus to obtain the authentication information of the security bus. When the authentication information of the security bus is consistent with the authentication information of the requesting end, it is determined that the identity authentication of the requesting end is passed.

[0104] In some embodiments, the authentication unit of the secure bus uses the same encryption algorithm as the requesting end and encrypts the message body information sent by the requesting end in combination with its own session key to obtain the authentication information of the secure bus. Exemplarily, the encryption method may be the SM4 algorithm.

[0105] In some embodiments, if the number of session keys of the requesting end is at least two, the number of session keys of the security bus is also at least two, that is, the authentication information of the security bus and the authentication information of the requesting end are both at least two, and it is necessary to compare the authentication information of the security bus and the authentication information of the requesting end of the same type. The consistency of type here means that the type of the session key of the security bus is consistent with that of the session key of the requesting end. For example, when the session key of the security bus and the session key of the requesting end both include SBUSDMK, the consistency of the authentication information of the security bus encrypted by SBUSDMK and the authentication information of the requesting end encrypted by SBUSDMK is compared.

[0106] Step S303: when the authentication information of the secure bus is inconsistent with the authentication information of the requesting end, it is determined that the identity authentication of the requesting end fails.

[0107] In some embodiments, if the number of authentication information of the requesting end received by the secure bus is inconsistent with the number of session keys of the secure bus, it is not necessary to generate authentication information of the secure bus, and it is determined that the identity authentication of the requesting end fails.

[0108] In the embodiment of the present application, the authentication unit of the security bus encrypts the message body information based on the session key of the security bus to obtain the authentication information of the security bus. When the authentication information of the security bus is consistent with the authentication information of the requesting end, it is determined that the identity authentication of the requesting end is passed. When the authentication information of the security bus is inconsistent with the authentication information of the requesting end, it is determined that the identity authentication of the requesting end is not passed. In this way, when the requesting end and the security bus encrypt the same message body information to obtain the authentication information respectively, the identity of the requesting end is authenticated by comparing the authentication information of the requesting end and the authentication information of the security bus, thereby reducing the risk of data leakage of the session key of the requesting end and the security bus, and improving the security of the requesting end when calling the kernel function of the operating system.

[0109] In some embodiments, Figure 4 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 4 ,like Figure 4 As shown, before step S101, the above method can also be implemented through steps S401 to S404:

[0110] Step S401: encrypt preset data based on the root key pre-shared with the requesting end, obtain the root key verification value of the secure bus, and send the root key verification value of the secure bus to the requesting end.

[0111] In the embodiment of the present application, the preset data is data pre-agreed between the secure bus and the requesting end, and the encryption method used by the secure bus to encrypt the preset data through the root key adopted by the authentication unit is also an encryption method pre-agreed between the requesting end and the secure bus. The encryption method may be a symmetric encryption method, and illustratively, the encryption method may be an SM4 algorithm.

[0112] It is understandable that before the requesting end exchanges data with the secure bus through the session key, the authentication unit of the secure bus needs to authenticate the requesting end first. Therefore, the secure bus and the requesting end use the same encryption method and encrypt the same root key. By comparing the root key check value of the requesting end, the corresponding key can be determined to complete the authentication of the secure bus to the requesting end.

[0113] Step S402, receiving the ciphertext data of the requesting end sent by the requesting end.

[0114] Among them, the ciphertext data of the requesting end is obtained by encrypting the first random number and the number of iterations based on the pre-shared root key when the requesting end determines that the root key verification value of the requesting end is consistent with the root key verification value of the security bus; the root key verification value of the requesting end is obtained by encrypting the preset data using the pre-shared root key of the requesting end.

[0115] Step S403: decrypt the ciphertext data of the requesting end based on the pre-shared root key to obtain a first random number and an iteration number.

[0116] Step S404 : Based on a preset key generation algorithm, the pre-shared root key, the first random number, the second random number, the number of iterations and the first byte length are processed to generate a session key for the secure bus.

[0117] The first byte length is the byte length of the session key of the secure bus.

[0118] In some embodiments, the generation of the session key of the secure bus can be achieved by calculating the formula (1).

[0119] The session key of the secure bus = PBKDF2(p, r1+r2, iteration, keyLen) formula (1);

[0120] Wherein, p is the root key pre-shared between the requesting end and the secure bus; iteration is the number of iterations; r1 is the first random number generated by the requesting end within a preset range; r2 is the second random number generated by the secure bus within a preset range; keyLen is the byte length corresponding to the session key of the secure bus. For example, when the session key of the requesting end is SBUSDMK, keyLen is 16.

[0121] In the embodiment of the present application, the authentication unit of the security bus encrypts the preset data based on the root key pre-shared with the requesting end, obtains the root key check value of the security bus, sends the root key check value of the security bus to the requesting end, and receives the ciphertext data of the requesting end sent by the requesting end through the server of the security bus, decrypts the ciphertext data of the requesting end based on the root key, obtains the first random number and the number of iterations, and processes the pre-shared root key, the first random number, the second random number, the number of iterations and the first byte length based on the preset key generation algorithm to generate the session key of the security bus. In this way, the session key negotiated by the requesting end and the security bus can be used to encrypt and decrypt data during the communication process between the two parties, thereby improving the security of the requesting end when accessing the security bus.

[0122] In some embodiments, Figure 5 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 5 ,like Figure 5 As shown, the above step S103 can be implemented through steps S501 to S503:

[0123] Step S501, determining the function type of the kernel function;

[0124] The function type includes a first function type and a second function type. The first function type is used to characterize that the kernel function is a built-in function of the operating system; the second function type is used to characterize that the kernel function is a non-built-in function of the operating system.

[0125] Among them, the built-in functions of the operating system are functions that are directly integrated into the core of the operating system and can be directly called by the cryptographic product without additional installation or configuration. The non-built-in functions of the operating system are functions that are not directly integrated into the core of the operating system and need to be called through scripts or third-party software.

[0126] In some embodiments, the kernel functions corresponding to the first function type may include a function of modifying permissions of files and directories of the operating system, and may also include a function of modifying users and groups to which files and directories of the operating system belong.

[0127] In some embodiments, the kernel functions included in the second function type may include functions for modifying files, directories, and permissions of other networks and other firewalls.

[0128] In some embodiments, the method for determining the function type of the kernel function can determine the function type of the kernel function according to a preset mapping relationship between the kernel function and the function type. Exemplarily, the kernel function can be divided into functions built into the operating system and functions not built into the operating system using the interface technology definition in the Golang language.

[0129] In some embodiments, the kernel functions included in the first function type may also include non-built-in functions of the operating system encapsulated using CGO, where CGO is a technology that can serve as a bridge to allow indirect calls or encapsulation of libraries or APIs provided by the C language that can directly call kernel functions.

[0130] In some embodiments, kernel functions can be extended through CGO to enrich the kernel functions that can be called by the request end.

[0131] Step S502: when the function type of the kernel function is the first function type, determine that the calling method of calling the kernel function of the operating system is an application program interface call.

[0132] It is understandable that the application program interface defines the rules for the interaction between the application program and the operating system, including the call request of the cryptographic product and the call rules of the kernel function of the operating system. Then, the security bus can directly call the built-in functions of the operating system through the application program interface without the need for scripts or third-party software calls. Exemplarily, the security bus can call the built-in kernel functions of the operating system based on the application program interface, such as creating, modifying and deleting files and directories of the operating system.

[0133] In some embodiments, the application program interface may include a system call application program interface (Syscall Application Programming Interface, Syscall API), an operating system application interface (Operating System Application Programming Interface, OS API) and a network link Netlink interface.

[0134] Among them, Syscall API specifically refers to interfaces that allow applications to make requests to the operating system kernel to perform low-level operations. Exemplarily, low-level operations may include file operations, process management, network communications, etc. OS APIs include not only interfaces for performing low-level operations, but may also include other higher-level interfaces. Exemplarily, higher-level interfaces may include database interfaces, network programming interfaces, etc. The Netlink library is a third-party API library that is a communication bridge between Golang and kernel functions. It provides an interface for low-level access to the operating system. Exemplarily, the Netlink API may include a network configuration interface, a network protocol interface, etc.

[0135] In some embodiments, calling the kernel function based on the calling mode may include using the OS API to call the built-in kernel function in the operating system for displaying the user interface and implementing database operations. Exemplarily, the management interface unit of the secure bus uses the OS API to call the kernel function in the operating system to create, delete, modify and delete the database.

[0136] In some embodiments, calling the kernel function based on the calling method may also include using Syscall API to call the built-in kernel function in the operating system for implementing file operations, process management, network communication, etc. Exemplarily, the management interface unit of the secure bus uses Syscall API to call the kernel function in the operating system, which can create, delete, modify and delete the permissions of files and directories, and can also create, delete, modify and delete the users and groups to which the files and directories of the operating system belong.

[0137] In some embodiments, calling a kernel function based on a calling method may also include calling a kernel function related to a network subsystem or routing table management based on a Netlink API to achieve communication between the requesting end and the operating system. Exemplarily, the management interface unit of the security bus uses the Netlink API to call the kernel function in the operating system, which can achieve the addition and deletion of interfaces, setting Internet Protocol (Intellectual Property, IP) addresses, routing, and configuration of Internet Protocol Security (Internet Protocol Security, IPSec).

[0138] Step S503: when the function type of the kernel function is the second function type, determine that the calling mode of calling the kernel function of the operating system is command line interpreter calling.

[0139] It is understandable that when the requesting end calls a non-built-in kernel function in the operating system, it cannot call it directly through the interface, but needs to call the kernel function indirectly by executing the command line interpreter. Exemplarily, the management interface unit of the secure bus can implement the call of third-party software, such as image editing software (Photoshop), based on the command line interpreter.

[0140] Shell scripts can encapsulate network and firewall files, directories, permissions and other functions.

[0141] In some embodiments, calling a kernel function based on a calling method may include calling based on a shell script to implement calling of additional network service software, additional firewalls and other related functions.

[0142] In the embodiment of the present application, the management interface unit of the security bus determines the function type of the kernel function, and determines whether the calling method of calling the kernel function of the operating system is an application program interface call or a command line interpreter call according to the function type of the kernel function. In this way, when the function requested to be called by the requesting end is a function built into the operating system, the management interface unit of the security bus uses the application program interface call to directly call the kernel function, and when the function requested to be called by the requesting end is a function not built into the operating system, the management interface unit of the security bus uses the command line interpreter call to implement the expansion of the kernel function and improve the efficiency of the requesting end in calling the kernel function of the operating system.

[0143] In some embodiments, Figure 6 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 6 ,like Figure 6 As shown, the above step S104 can be implemented through step S601 and step S602:

[0144] Step S601, configuring a configuration file for instructing to call a kernel function of an operating system.

[0145] The configuration file is used to indicate the correspondence between the kernel functions of the operating system and the calling methods.

[0146] In some embodiments, the configuration file can also configure the network management tool supported by the specific security bus. For example, in the Ubuntu system, the network management tool Netplan supported by the specific security bus and the command line interface nmcli can be configured by editing the configuration file to perform system-level network management. Among them, Ubuntu is an operating system based on desktop applications. Netplan is a tool for configuring network interfaces on Ubuntu, and nmcli is a command line interface for calling Netplan.

[0147] In some embodiments, configuring the network management tool supported by a specific security bus may also include configuring the management tool Ufw by editing a configuration file, and configuring the system to support a specified security management policy using a command line tool firewalld-cmd to manage system security aspects such as firewalls. Ufw is a simple firewall management tool. firewalld-cmd is a command line tool for managing firewalls.

[0148] In some embodiments, configuring a configuration file for indicating the call of the kernel function of the operating system may also include accessing the non-built-in functions of the operating system to management by writing a custom shell script in the configuration file. Exemplarily, by writing a custom shell script in the configuration file, the non-built-in functions of the operating system, such as Keepalived and SNMP management functions, are accessed to management to enable the management interface unit of the security bus to call the Keepalived and SNMP management functions. Among them, Keepalived is a high-availability service software, mainly used for load balancing and failover. The Simple Network Management Protocol (SNMP) is an application layer protocol for network management. It is mainly used to monitor and manage devices on the network and collect device status and performance information. Exemplarily, calling Keepalived through a shell script prevents single point failures and realizes load balancing of the interaction process between the requester and the security bus. By calling SNMP through a shell script, the device status and performance information of the interaction process between the requester and the security bus can be obtained in a timely manner.

[0149] In some embodiments, configuring a configuration file for instructing to call a kernel function of an operating system may include decoupling built-in functions and non-built-in functions in the operating system by editing a module in the configuration file, wherein the module name and the key-value pairs below constitute a complete module.

[0150] Exemplarily, the module name currently supported by the security bus is [modules]. Different values ​​are set in the configuration file to configure whether the [modules] module supports the call request of the requesting end, and when responding to the call request of the requesting end, the management interface unit of the security bus implements the call to the kernel function in the operating system by calling the Netlink API or the Syscall API, or executes a shell script to implement the call to the kernel function in the operating system.

[0151] For example, when the value of the parameter in the configuration file is set to 0, it indicates that the request from the requesting end is not supported; when the value of the parameter is set to 1, it indicates that the kernel function in the operating system is called by calling the API; when the value of the parameter is set to 2, it indicates that the kernel function in the operating system is called by executing a shell script. The firewall parameter indicates the firewall function. When the firewall parameter is configured to 2, it indicates that when the requesting end calls the firewall function, it is implemented by executing a shell script. The ntp parameter indicates the network time protocol, which is used to provide time information to the requesting end. When the ntp parameter value is configured to 1, it indicates that when the requesting end calls the time information, it is implemented by calling the API.

[0152] In some embodiments, configuring a configuration file for indicating calling a kernel function of an operating system may include, in the case where the kernel function can be called either in an API call or in a shell call, configuring the calling priority of the kernel function when it is called in an API manner and when it is called in a shell manner in the configuration file of the kernel function. Exemplarily, in the case where the create file function can be called either in an API manner or in a shell manner, when the priority of calling in an API manner is higher than the priority of calling in a shell manner, determining that the management interface unit of the secure bus calls the create file function in an API manner.

[0153] In some embodiments, the configuration file for instructing to call the kernel function of the operating system may also include a custom shell script to add a configuration module to support dynamic access to other management tools.

[0154] In some embodiments, the interface address, public request parameters, client key, and other specific parameters of the API interface can be configured in the configuration file. The interface address is used to specify the location of the file or resource called by the API, the public request parameters are used to build a correct request, and the public request parameters may include data types, parameter descriptions, etc. Other specific parameters may include parameters required by specific business needs and technology stacks to ensure stable operation and high availability of the system.

[0155] In an embodiment of the present application, the security bus also includes a configuration management unit, and the management interface unit in the security bus is configured by the configuration management unit to indicate a configuration file for calling a kernel function of the operating system.

[0156] Step S602: Using the calling method in the configuration file, call the kernel function of the operating system.

[0157] In some embodiments, calling the kernel function of the operating system may include the secure bus using the calling method in the configuration file to adaptively select the tool with the highest priority to perform system management.

[0158] In an embodiment of the present application, a configuration file of a security bus is configured to indicate calling the kernel function of the operating system, and the management interface unit of the security bus uses the calling method in the configuration file to call the kernel function of the operating system. In this way, it is possible to use some API interface calls instead of shell script calls, thereby improving the efficiency of the requesting end in calling the kernel function of the operating system. In addition, a custom shell script method is provided to configure other non-operating system built-in management functions, so that the non-operating system built-in functions can be called by the requesting end, thereby improving the availability of the requesting end in calling the kernel function of the operating system.

[0159] In some embodiments, Figure 7 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 7 ,like Figure 7 As shown, the above method can also be implemented through step S701 and step S702:

[0160] Step S701, when a call operation to a kernel function fails, a rollback operation is performed according to operation information recorded in a database of the security bus to restore the call operation of the kernel function to a state before the failed call operation is performed.

[0161] In some embodiments, executing a rollback operation may include, before the operation, storing the current state of the database and setting a flag for the database for data rollback. After the calling operation fails, all operations after the flag will be undone.

[0162] A database is a collection of related data that is stored in a computer system to facilitate management, processing, and access. When an operation is stored in a database, at least one data item in the database is updated. Various data items constitute an operation sequence, which is also called a transaction. A transaction is an indivisible unit of work, that is, all operations included in a transaction are either executed in full or not executed at all.

[0163] In some embodiments, the database supports transaction operations. When an operation includes multiple sub-operations, the operation information recorded in the database may include a single work unit that combines the multiple sub-operation information, and the single work unit is added to the transaction of the database. After each operation included in the single work unit is successfully completed, it is considered successful, and each operation is recorded in the database; if a failure occurs in the middle, the rollback operation is performed according to the records in the database.

[0164] For example, when authorizing a server for dozens of IP services, the security bus will perform batch operations on the IP services. If the last one fails, the requester will be notified of the operation failure, and then the authorization information of the IP service will be restored to the original state, that is, the previously successfully authorized one will be withdrawn. It is understandable that if all IP authorization operations are not rolled back, some redundant operations will be written into the operating system.

[0165] Step S702, until the kernel function executes the calling operation successfully, the calling operation is stored in the database.

[0166] In some embodiments, storing the call operation in a database may include storing the call operation in the database in a JSON format.

[0167] Exemplarily, the data information of the call operation stored in the database in JSON format can be in JSON format, such as: {"key1": "data1", "key2": "data2", ...}. Among them, key1 and key2 represent keys, which can also be called attribute names, data1 represents the attribute value corresponding to the attribute name key1, and data2 represents the attribute value corresponding to the attribute name key2. The data information can also be stored in the database in TLV format, and the data in TLV format can be represented as: Key1\x00\x05data1key2\x00\x06data11...

[0168] In some embodiments, the transmission method for storing the call operation in the database may be: using the RESTFull data protocol based on HTTP transmission.

[0169] In some embodiments, storing the call operation in the database may further include storing the call operation in the database in a TLV data format.

[0170] In the embodiment of the present application, in the case that the management interface unit of the security bus fails to perform a call operation on the kernel function, a rollback operation can be performed according to the operation information recorded in the database of the security bus to restore the call operation of the kernel function to the state before the failed call operation is performed, until the kernel function successfully performs the call operation and stores the call operation in the database. In this way, in the case that the call operation fails during the execution process, some data may be incorrectly modified or deleted. Performing a rollback operation according to the operation information recorded in the database of the security bus can ensure that when an error occurs in the call operation, the database state can be restored to the state before the call operation, thereby reducing the risk of data loss and improving the security of the request end calling the kernel function of the operating system.

[0171] In some embodiments, Figure 8 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 8 ,like Figure 8 As shown, the above method can also be implemented through steps S801 to S803:

[0172] Step S801, when the call to the kernel function based on the command line interpreter fails, an error code is returned.

[0173] In some embodiments, the method of setting the error code may include using regular matching special information to set the error code according to the call request. Among them, regular matching special information is also called a regular expression, which is used to use a single string to describe and match a series of strings that match a certain syntactic rule, and is usually used to retrieve and replace texts that meet a certain pattern. Exemplarily, when a certain syntactic rule is "*1*", all error codes containing the character "1" in the error code can be matched.

[0174] In some embodiments, the method of setting the error code may also include setting the error code by using the exit code returned by the operating system when the execution of the shell command fails.

[0175] For example, the error code of shell script execution failure is set to 1, and the error code of shell script execution success is set to 0. Use the "eval $@ 2>&1" command to redirect the output of the standard error stream stderr to the standard output stream stdout. This method can define a set of error code systems suitable for the security bus at the shell layer.

[0176] Step S802: based on a preset first script, convert the error code into error information corresponding to the error code.

[0177] The preset first script is used to define the corresponding relationship between the error code and the operation information.

[0178] Step S803: Return error information corresponding to the error code to the requesting end.

[0179] In some embodiments, returning error information corresponding to the error code to the requesting end may include setting different display styles for different errors and returning them to the requesting end. Exemplarily, the display style may include the color and size of the error code.

[0180] In the embodiment of the present application, when the kernel function call based on the command line interpreter fails, an error code is returned, and based on the preset first script, the error code is converted into an error message corresponding to the error code, and the error message corresponding to the error code is returned to the request end. In this way, by executing a custom shell script for subdividing the error message of executing the kernel function call, it is possible to implement error code subdivision processing for abnormal situations in the calling process, which is beneficial to the developer's call and improves the availability of the request end to call the kernel function of the operating system.

[0181] In some embodiments, the present application also provides a function calling method, which can be applied to the request end. The function calling method can be implemented by step S901:

[0182] Step S901: sending a call request for calling a kernel function of an operating system to a secure bus.

[0183] The security bus includes a server, an authentication unit, and a management interface unit. The server of the security bus is used to receive a call request sent by a requesting end to call a kernel function of an operating system, and the authentication unit of the security bus is used to authenticate the identity of the requesting end based on a session key of the requesting end; if the identity authentication of the requesting end is passed, the management interface unit of the security bus is used to call the kernel function of the operating system based on a call method corresponding to the function type of the kernel function of the operating system.

[0184] In some embodiments, Fig. 9 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 9 ,like Fig. 9 As shown, before step S901, the above method can also be implemented through steps S902 to S908:

[0185] Step S902: Encrypt preset data based on the root key pre-shared with the secure bus to obtain a root key verification value of the requesting end.

[0186] Step S903: receiving the root key verification value of the secure bus.

[0187] Step S904: when the root key check value of the requesting end is consistent with the root key check value of the secure bus, encrypt the first random number and the number of iterations based on the pre-shared root key to obtain the ciphertext data of the requesting end.

[0188] It is understandable that the encryption method used by the requesting end to encrypt the message body information and the encryption method used by the security bus to encrypt the message body information are pre-agreed, and the encryption method is a symmetric encryption method. Then, after the security bus obtains the authentication information obtained by encrypting the message body information by the requesting end, the security bus can encrypt the message body information based on the agreed encryption method and its own session key to obtain the authentication information of the security bus. Compare the authentication information of the requesting end with the authentication information of the security bus. If the comparison result indicates that the authentication information of the requesting end is consistent with the authentication information of the security bus, it means that the session key of the requesting end is consistent with the root key of the security bus; if the comparison result indicates that the authentication information of the requesting end is inconsistent with the authentication information of the security bus, it means that the session key of the requesting end is inconsistent with the root key of the security bus.

[0189] In some embodiments, the first random number is a value randomly generated by the requesting end within a first preset range.

[0190] Step S905: Send the ciphertext data of the requesting end to the security bus.

[0191] Step S906, receiving the ciphertext data of the secure bus sent by the secure bus.

[0192] The ciphertext data of the secure bus is obtained by encrypting the second random number based on the pre-shared root key of the secure bus.

[0193] Step S907: decrypt the ciphertext data of the secure bus based on the pre-shared root key to obtain a second random number.

[0194] Step S908: Based on a preset key generation algorithm, the pre-shared root key, the first random number, the second random number, the number of iterations, and the second byte length are processed to generate a session key of the requesting end.

[0195] In some embodiments, the session key of the requesting end can be implemented by the above formula (1).

[0196] The second byte length is the byte length of the session key of the requesting end.

[0197] In the embodiment of the present application, based on the root key pre-shared with the security bus, the preset data is encrypted to obtain the root key check value of the requesting end, the root key check value of the security bus is received, and when the root key check value of the requesting end is consistent with the root key check value of the security bus, the first random number and the number of iterations are encrypted based on the pre-shared root key to obtain the ciphertext data of the requesting end, the ciphertext data of the security bus sent by the security bus is received, and the ciphertext data of the security bus is decrypted based on the pre-shared root key to obtain the second random number. Based on the preset key generation algorithm, the pre-shared root key, the first random number, the second random number, the number of iterations and the second byte length are processed to generate the session key of the requesting end. In this way, by comparing the root key consistency of the requesting end and the security bus and verifying the session key consistency of the requesting end and the security bus, two key negotiations between the security bus and the requesting end can be achieved. Therefore, when the requesting end uses the current session key obtained after two key negotiations to interact with the security bus, compared with the authentication method of combining account and password in the prior art, the use of HMAC value authentication and authorization improves the security of the requesting end when calling kernel functions, and also improves the efficiency of the requesting end calling the kernel functions of the operating system (that is, there is no need for the user to enter the account and password).

[0198] Fig.10 A schematic diagram of a secure bus architecture provided in an embodiment of the present application Figure 1 .like Fig.10 As shown, the core components of the architecture of the security bus in the embodiment of the present application may include a server module 1003 (server in the above embodiment), an authentication module 1004 (authentication unit in the above embodiment), a management interface module 1005 (management interface unit in the above embodiment), a configuration management module 1007 and a database 1008. Among them, the management interface module 1005 at least includes a Netlink interface 1009, a Syscall interface 1010 and a shell call 1011.

[0199] In some embodiments, the architecture of the secure bus can be implemented based on Golang's Fiber framework.

[0200] The server module 1003 is a Fiber framework. The Fiber framework is a high-performance WEB framework based on FastHTTP inspired by Express. FastHTTP is Golang's HTTP engine, which usually refers to HTTP servers that perform particularly well compared to other HTTP libraries or frameworks. As a server architecture that combines HTTP and JSON, the Fiber framework can support multiple key negotiation methods to generate HMAC values. The Fiber framework is simple in design and can be developed quickly, while taking into account zero memory allocation and performance issues.

[0201] In some embodiments, each time the business end requests a secure bus, it needs to use SBUSDMK to calculate the HMAC value of the message body of the request message. The business end uses SBUSDMK and a hash function to calculate the HMAC value of the message body. This process involves processing the key and the message body together through a hash function to generate an HMAC value of a fixed length. The HMAC value is set in the message header of the HTTP message. The calculated HMAC value needs to be added to the header of the HTTP request in some form (such as Base64 encoding).

[0202] First, after receiving the call request sent by the service end 1001 based on HTTP or other network protocols, the fiber server module 1003 parses the message header information carried by the call request, and determines whether there is an HMAC value field in the message header information, or whether the HMAC value field in the message header information complies with the rules, and rejects the request message without the HMAC value field or the HMAC value field data is illegal, that is, rejects the call request of the service end. Secondly, when the authentication module 1004 determines that there is an HMAC value field in the message header information and the HMAC value field complies with the rules, the identity of the service end 1001 is authenticated based on the HMAC value field, wherein the message header of the call request includes the HMAC value of the service end 1001.

[0203] In some embodiments, the authentication module 1004 may parse the call request message by the following steps:

[0204] Step 1: Read the message of the call request, including the message header information and the message body information.

[0205] Step 2: Extract the HMAC value of service end 1001 from the message header information.

[0206] Step 3, using the same hash function, root key or session key as the service end 1001, calculate the HMAC value of the received message body information.

[0207] Step 4: Compare the HMAC value calculated by the secure bus 1002 with the HMAC value extracted from the message header.

[0208] If the HMAC values ​​of the business end 1001 and the security bus 1002 are the same, it means that the message body has not been tampered with during transmission and is sent by a legitimate business end with the SBUSDMK key. SBUS can continue to process the request. If the HMAC values ​​of the business end 1001 and the security bus 1002 are different, it means that the message body may have been tampered with, or the call request is not sent by a legitimate business end. The security bus will refuse to process the call request and return an error message or error code.

[0209] Finally, the management interface module 1005 calls the function in the kernel 1006 according to the calling method corresponding to the kernel function type requested by the service end 1001.

[0210] In some embodiments, the management interface module 1005 may include configuring and managing the calling modes corresponding to different kernel functions, so as to adaptively select the calling mode corresponding to the kernel function and make a calling request to the kernel function.

[0211] In some embodiments, the access management may be configured by providing a custom shell script for a non-built-in management function in the operating system, so as to call the non-built-in management function in the operating system.

[0212] In some embodiments, the management interface module 1005 calls functions in the kernel 1006, which may include implementing management functions by calling functions in the kernel 1006 through Golang native APIs and shell scripts. Exemplarily, built-in management functions in the kernel 1006 may be called based on the Netlink API and the Syscall API, and non-built-in management functions in the kernel 1006 may be called based on the shell.

[0213] In some embodiments, the calling methods can be divided into API calls and shell calls according to the interface technology of the Golang language.

[0214] In some embodiments, the secure bus can realize adaptive selection of the calling method of calling the kernel function of the operating system through interface technology.

[0215] In some embodiments, in order to make up for the limitation that Golang does not directly support kernel API calls, CGO can be used to encapsulate interface libraries written in C language, which implement calls to kernel APIs internally. In this way, CGO is used to expand Golang's API calling capabilities, enabling it to indirectly call and operate services provided by the operating system kernel.

[0216] Exemplarily, based on Netlink API and Syscall API, the kernel built-in management function can be called by calling the interface, wherein the kernel built-in management function includes the configuration function for configuring the network and firewall, etc. Based on the shell, the non-kernel built-in management function can be called by calling the encapsulation program, wherein the kernel non-kernel built-in management function includes the function of third-party software or hardware.

[0217] In some embodiments, the interactive data between the service end 1001 and the security bus 1002 may include key data and service data obtained through negotiation between the service end 1001 and the security bus 1002. The key data may include the current session key, public key and root key in the above embodiments; service data refers to data generated by the service end 1001 calling the kernel function and needs to be stored in the database 1008.

[0218] In some embodiments, the data transmission method can be: using RESTFull data protocol based on HTTP transmission

[0219] Exemplarily, the data format stored in the database 1008 may be in JSON format, such as: {"type":"firewall","api":{},"group":"0000000000000001","cmd":"firewall-cmd--delete-zone=managerZone--permanent","state":"success"}. The type parameter indicates the system management type of the operation, the api parameter indicates the called API interface and the key-value pair parameters corresponding to the API call interface, the group parameter indicates that a group of transaction operations includes multiple transaction operations with the same groupid, the cmd parameter indicates the command used to call the shell script, and the state parameter indicates whether the call operation is executed successfully, failed, or not executed.

[0220] In some embodiments, the data format stored in the database 1008 may also include a TLV data format.

[0221] In some embodiments, the overall architecture includes two application modes, a one-to-one collaborative mode and a many-to-one pre-sharing mode. The security bus 1002 can select the collaborative mode or the pre-sharing mode from the two application modes to authenticate the business end 1001 when the business end 1001 passes the identity authentication.

[0222] In some embodiments, in collaborative mode, the business end 1001 and the security bus 1002 are integrated on a server. Because calling kernel functions requires authentication, the security bus can only process the business end request that initiates the initialization operation for the first time.

[0223] In some embodiments, in the pre-shared mode, the root key does not need to be negotiated but the session key needs to be negotiated.

[0224] In some embodiments, the pre-sharing mode supports multiple service terminals 1001 to issue call requests at the same time, and different service terminals 1001 have different session keys. When the session key check values ​​of a service terminal 1001 and the security bus 1002 are consistent, it means that the session key of the service terminal 1001 is consistent with the plain text of the session key of the security bus 1002, because the algorithm of the session key of the service terminal 1001 and the session key check value of the security bus 1002 is the same.

[0225] In some embodiments, Fig.11 A schematic diagram of a secure bus architecture provided in an embodiment of the present application Figure 2 ,like Fig.11 As shown, the servo module 1003 can implement steps S1101 to S1106:

[0226] Step S1101, setting fiber control parameters.

[0227] In some embodiments, setting the fiber control parameters includes a read and write timeout parameter, a maximum supported message parameter, a concurrent data parameter, and a long connection number retention time parameter.

[0228] In some embodiments, the read and write timeout parameters of Fiber are set to prevent long-suspended call requests from occupying resources.

[0229] In some embodiments, a maximum supported message parameter of Fiber is set to prevent resource overload.

[0230] In some embodiments, the concurrent data parameters of Fiber are set to limit the number of call requests issued by the processing end at the same time to avoid resource exhaustion.

[0231] In some embodiments, the long connection count holding time parameter of Fiber is set to prevent resource loss.

[0232] Step S1102, create a Fiber instance.

[0233] It is understandable that the Fiber instance is the context for executing the coroutine, and they will be used to process the incoming request. Then, when executing step S1102, one or more fiber instances are created based on the parameters set in step S1101.

[0234] In some embodiments, when creating a Fiber instance, some initialization options can be specified, such as the network library used, the coroutine scheduler, etc.

[0235] Step S1103, register the middleware route.

[0236] It can be understood that middleware is a key link in the process of processing HTTP requests. They can execute code before or after the Fiber instance reaches the actual processing function. Middleware routing involves defining the processing logic of these middlewares and inserting them into the appropriate position in the request processing flow. Then, when executing step S1103, based on the request information in the Fiber instance created in step S1102, the middleware route for processing the request information is registered.

[0237] In some embodiments, registering a middleware route may include adding pre- and post-actions that handle HTTP requests.

[0238] In some embodiments, registration middleware routes may be used to implement logging, authentication, request pre-processing, and the like.

[0239] Step S1104, registering the interface route.

[0240] The interface route defines the HTTP requests that the application can respond to. The processing logic of the HTTP request can be defined by setting the interface route.

[0241] In some embodiments, registering an interface route may include adding the interface to the route for registration.

[0242] In some embodiments, registering an interface route includes specifying a URL path of an HTTP request and a function for processing the request, executing the request content of the HTTP request according to the URL and the processing function, and returning a response to the requesting end.

[0243] Step S1105, start necessary coroutines to process other tasks.

[0244] It is understandable that in addition to processing the call request sent by the requesting end, other background tasks may need to be performed, and other background tasks can be executed concurrently by starting additional coroutines. Then, when executing step S1105, it is necessary to start necessary coroutines to process other tasks. Exemplarily, other background tasks can be timed tasks or database connection maintenance.

[0245] In some embodiments, starting the necessary coroutines to process other tasks may include starting a Kotlin coroutine to process the scheduled task of the requester in the process of calling the kernel function of the operating system. Kotlin is a statically typed programming language that can maintain full interoperability with the service process, allowing developers to seamlessly integrate other tasks into existing tasks.

[0246] In some embodiments, while assisting in processing other tasks by starting necessary coroutines, the Fiber server module 1003 can exit the service without losing the currently processed request or data, that is, safely shut down the service.

[0247] Exemplarily, exiting the service may include monitoring interrupt signals, notifying other components, waiting for the current task to be completed, closing resources, and exiting. Exemplarily, other components may include a database and other task processes.

[0248] Step S1106, monitoring the local port server.

[0249] It is understandable that the security bus needs to monitor one or more local ports to receive the call request from the request end.

[0250] In some embodiments, when monitoring a port, the address and port number to be monitored can be specified. Once the port is successfully monitored, the security bus can begin to receive and process requests.

[0251] In some embodiments, Fig.12 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 10 ,like Fig.12 As shown, the function calling method can be implemented through steps S1201 to S1206:

[0252] Step S1201: The service end and the security bus randomly generate their own SM2 key pairs.

[0253] Among them, the business end can be understood as the request end mentioned above; the SM2 key pair includes a public key and a private key.

[0254] In step S1202, the business end and the security bus exchange their respective public keys and calculate the collaborative key SBUSROOT (which can be understood as the root key mentioned above).

[0255] In some embodiments, the computing service collaboration key may be generated by formula (2):

[0256] q=d1[*]p2-n[*]G formula (2).

[0257] Among them, q is the collaborative key of the business end, d1 is the private key of the business end, p2 is the public key of the security bus, [*] represents the point multiplication algorithm; the value range of n is [0, N], N is the order of point G of the SM2 elliptic curve; G is the base point in the SM2 elliptic curve.

[0258] In some embodiments, the collaborative key of the secure bus can be generated by formula (3):

[0259] p=d2[*]p1-n[*]G formula (3).

[0260] Among them, p is the collaborative key of the security bus, d2 is the private key of the security bus, and p1 is the public key of the business end; the value range of n is [0, N], N is the order of point G of the SM2 elliptic curve; G is the base point in the SM2 elliptic curve.

[0261] In step S1203, the service end and the security bus encrypt the preset data based on their own collaborative keys respectively, and obtain the collaborative key verification value of the service end and the collaborative key verification value of the security bus.

[0262] Exemplarily, the preset data may be / x00*16.

[0263] Step S1204: When the collaborative key verification values ​​of the service end and the security bus are consistent, the session key of the service end and the session key of the security bus are derived.

[0264] In some embodiments, the service end derives the session key of the service end through PBKDF2 based on the collaborative key of the service end; the security bus derives the session key of the security bus through PBKDF2 based on the collaborative key of the security bus. The session key of the security bus and the session key of the service end include SBUSDMK.

[0265] In some embodiments, the service end generates a salt value, number of iterations, and length of a derived key for key encryption according to PBKDF2, and passes the agreed parameters to the security bus. The service end and the security bus use PBKDF2 to derive session keys from the collaborative key.

[0266] For example, the session key of the service end can be realized by formula (4):

[0267] The session key of the business end = PBKDF2 (q, salt, iteration, keyLen) formula (4).

[0268] Wherein, q is the collaborative key of the business end; salt is the preset salt value; iteration is the number of iterations; keyLen is the byte length corresponding to the session key of the business end. For example, when the session key of the business end is SBUSDMK, keyLen is 16 bytes.

[0269] Step S1205: The service end and the security bus encrypt the preset data based on their own session keys respectively to obtain a session key verification value.

[0270] Step S1206: The service end sends the service end key verification value to the security bus and compares it with the session key verification value of the security bus for consistency.

[0271] In some embodiments, if the session key verification values ​​are consistent, the verification key negotiation is successful, otherwise it fails.

[0272] In some embodiments, the public key p2 of the secure bus can be represented by d2[*]G, and the public key p1 of the requesting end can be represented by d1[*]G. Substituting p2=d2[*]G into formula (2) and p1=d1[*]G into formula (3), we can obtain:

[0273] q=d1[*]d2[*]Gn[*]G=d2[*]d1[*]Gn[*]G=pFormula (5).

[0274] From formula (5), it can be seen that if the requesting end is legitimate, the root key q of the requesting end is consistent with the root key p of the secure bus. Therefore, through the first key negotiation between the requesting end and the secure bus, the root key used to generate the session key can be determined, and thus whether the requesting end is legitimate can also be determined.

[0275] In some embodiments, Fig.13 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 10 One, such as Fig.13 As shown, the above step S1202 can be implemented through steps S1301 to S1307:

[0276] Step S1301: The business end sends the business end public key to the security bus.

[0277] Step S1302: The secure bus sends the secure bus public key to the service end.

[0278] Step S1303: The business end generates a root key of the business end based on the security bus public key and the business end private key.

[0279] In some embodiments, the root key of the service end can be implemented by the above formula (3).

[0280] Step S1304: the service end uses the service end's root key to encrypt the preset value and sends the encrypted preset data to the security bus.

[0281] In some embodiments, the preset value may be / x00*16, the encryption method may be SM4, the root key of the service end may be represented by q, and step S1004 may be represented by SM4 (q, / x00*16).

[0282] Step S1305: The secure bus generates a root key of the secure bus based on the service end public key and the secure bus private key.

[0283] In some embodiments, the root key of the secure bus can be implemented by formula (2).

[0284] Step S1306, the security bus uses the root key of the security bus to encrypt the preset value, and determines whether the data encrypted by the security bus is consistent with the data encrypted by the business end, so as to determine whether the root key of the security bus is consistent with the root key of the business end.

[0285] Step S1307: the security bus encrypts the root key of the security bus and sends the result of determining whether the root key of the security bus is consistent with the root key of the service end to the service end.

[0286] In some embodiments, step S1307 can be represented by SM4 (p, success / fail), where SM4 is an encryption method, p is the root key of the security bus, success indicates that the root key of the security bus is consistent with the root key of the business end, and fail indicates that the root key of the security bus is inconsistent with the root key of the business end.

[0287] In some embodiments, Fig.14 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 3 ,like Fig.14 As shown, the above step S1204 can be implemented through steps S1401 to S1404:

[0288] Step S1401, the service end generates a session key of the service end based on the service end's root key, salt value and number of iterations.

[0289] Step S1402: The service end sends the salt value and the number of iterations to the security bus.

[0290] Step S1403: The secure bus generates a session key of the secure bus based on the salt value, the number of iterations, and the root key of the secure bus.

[0291] In some embodiments, the service end uses a pre-shared key to encrypt and transmit the first random number r1 to the security bus, and the security bus uses a pre-shared key to encrypt and transmit the second random number r2 to the service end; the service end agrees on the salt value and the number of iterations according to PBKDF2, and passes the agreed parameters to the security bus. The calling end and the security bus use PBKDF2 to derive the session key from the pre-shared key.

[0292] Exemplarily, the generation of the session key of the secure bus can be implemented by the above formula (1).

[0293] Step S1404: The secure bus uses the session key of the secure bus to encrypt the preset value and sends the encrypted data to the service end.

[0294] In some embodiments, when the session key of the secure bus includes SBUSDMK, step S1403 may be represented by SM4 (SBUSDMK, / x00*16), where SM4 is an encryption method, / x00*16 is a preset value, and SBUSDMK is an encryption key.

[0295] In some embodiments, Fig.15 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 10 Three, such as Fig.15 As shown, the function calling method can be implemented through steps S1501 to S1504:

[0296] Step S1501: The calling end and the security bus encrypt preset data based on their own pre-shared keys respectively, and obtain the pre-shared key verification value of the service end and the pre-shared key verification value of the security bus.

[0297] The business end and the security bus pre-share the same pre-shared key.

[0298] Step S1502: When the pre-shared key verification values ​​of the service end and the security bus are consistent, the session key of the service end and the session key of the security bus are derived.

[0299] In some embodiments, deriving the session key of the service end and the session key of the security bus can be implemented by formula (1).

[0300] Step S1503: the service end and the security bus encrypt the preset data based on their own session keys respectively to obtain a session key verification value.

[0301] In some embodiments, the business end and the security bus use SBUSDMK to encrypt preset data, such as / x00*16, to obtain their respective session key verification values. The calling end sends the session key verification value to the security bus for authentication, and compares the session key verification values ​​of the calling end and the security bus. If the session key verification values ​​are consistent, the key negotiation is verified to be successful, otherwise it fails.

[0302] Step S1504: The service end sends the service end key verification value to the security bus and compares it with the session key verification value of the security bus for consistency.

[0303] In some embodiments, if the session key verification values ​​are consistent, the verification key negotiation is successful, otherwise it fails.

[0304] In some embodiments, Fig.16 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 10 Four, such as Fig.16As shown, the above step S1502 can be implemented through steps S1601 to S1604:

[0305] Step S1601: The service end sends the first random number, salt value and iteration number to the security bus.

[0306] Step S1602: The security bus sends the second random number to the service end.

[0307] Step S1603, the business end generates a session key of the business end based on the first random number, the second random number, the salt value, the number of iterations and the root key of the business end, and uses the session key of the business end to encrypt the preset value, and sends the encrypted data and the preset value to the security bus.

[0308] In the embodiment of the present application, the generation of the session key of the secure bus can be implemented by the above formula (1).

[0309] Step S1604, the security bus calculates the session key of the security bus using the same session key calculation method as the business end, and encrypts the preset value, and sends the judgment result of whether the session key of the security bus is consistent with the session key of the business end to the business end after encrypting it with the session key of the security bus.

[0310] In some embodiments, the judgment result of whether the session key of the security bus is consistent with the session key of the business end can be expressed by SM4 (SBUSDMK, success / fail), where SM4 is an encryption method, SBUSDMK is the session key of the security bus, success indicates that the root key of the security bus is consistent with the root key of the business end, and fail indicates that the root key of the security bus is inconsistent with the root key of the business end.

[0311] Fig.17 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 10 5. If Fig.17 As shown, the interaction between the service end 1001 and the security bus 1002 in the collaborative mode is shown, and the interaction may at least include steps S1701 to S1705:

[0312] Step S1701, the business end 1001 calls sbus_init to initialize the security bus.

[0313] Among them, sbus_init is a function used to initialize the security bus device in the operating system.

[0314] In step S1702, the business end 1001 obtains the root key of the business end based on the public key of the business end and the public key of the security bus, and encrypts the first preset data based on the root key of the business end and the SM4 algorithm to obtain the root key verification value, and sends the root key verification value and the first preset data to the security bus.

[0315] Step S1703, the security bus 1002 obtains the root key of the security bus based on the same encryption algorithm as the business end, encrypts the first preset data based on the root key of the business end and the SM4 algorithm to obtain the root key verification value, and performs consistency verification on the root key of the business end.

[0316] Step S1704, if the consistency check passes, the business end 1001 receives the second random number sent by the security bus, obtains the session key based on the first random number and the number of iterations of the business end, encrypts the second preset data based on the session key and the SM4 algorithm of the business end to obtain the session key verification value, and sends the session key verification value and the second preset data to the security bus.

[0317] Step S1705, the security bus 1002 responds to the data sent by the service end, obtains the session key verification value of the security bus based on the same encryption algorithm as the service end, and performs consistency verification on the session key of the service end.

[0318] Fig.18 A schematic diagram of an implementation process of a function calling method provided in an embodiment of the present application Figure 10 6. If Fig.18 As shown, the interaction between the service end 1001 and the security bus 1002 in the pre-sharing mode is shown, and the interaction may at least include steps S1801 to S1804:

[0319] Step S1801, the service end 1001 calls sbus_init to initialize the security bus.

[0320] In step S1802, the service end 1001 obtains a derived session key based on the service end's root key, iteration number and random number, encrypts preset data based on the session key and SM4 algorithm to obtain a session key verification value, and sends the session key verification value to the security bus.

[0321] Step S1803, the security bus 1002 responds to the session key verification value, obtains the session key verification value of the security bus based on the same encryption algorithm as the service end, and performs consistency verification on the session key of the service end.

[0322] Step S1804, the security bus 1002 initializes the security bus.

[0323] In the embodiments of the present application, collaborative management, shell script error code and error information segmentation are implemented through multiple interface calling methods, modular configuration decoupling system management, and custom shell scripts. It can achieve: 1) abandon the traditional authentication method combining account and password, use HMAC value authentication authorization to ensure the security of system management. 2) Support the use of collaborative calculation to negotiate HMAC value session keys and pre-sharing to negotiate HMAC value session keys. Provide multiple authentication methods to ensure the security of system management. 3) Introduce database support for transaction operations. When several operations are executed as a whole, any operation failure will be rolled back to ensure the management security of system management. 4) Use GolangNetlink user-mode and kernel-mode communication interfaces (two-way communication, asynchronous communication) and Syscall to replace some shell calls to ensure the system's efficient processing of user requests. 5) Provide custom shell scripts for other non-operating system built-in management functions to configure access management, providing better scalability. 6) Supports proxy execution of custom shell scripts, and performs error code segmentation for abnormal execution situations, which is convenient for developers to call and ensures the ease of use of cryptographic products and function calling methods.

[0324] In the embodiment of the present application, a security bus is designed to solve the problem that the application process (request end) of the cryptographic product in the prior art uses a single direct call to the shell command line to interact with the kernel (using the kernel function). The shell belongs to a script interpretive programming language, and the security bus belongs to a middleware, which can combine the interpretive programming language with the API interface call method to realize the data transmission interaction between the application request and the kernel, and improve the security of the request end calling the kernel function of the operating system. This product is a system bus, which is used to connect the management service middleware of the application service and the system kernel, and can provide a secure system management function for various cryptographic products. Through two key negotiation methods (cooperative calculation and pre-shared key), the key is negotiated, and the HMAC value is calculated and attached to the request message for HMAC value authentication, and transaction operations are also supported, so as to realize a more secure middleware. The solution of interface calling service, modular configuration decoupling system management, custom shell script to realize collaborative management, and shell script error code and error information segmentation provides better ease of use and scalability. In addition, the cryptographic product only needs to focus on its own external cryptographic operation business function, without the learning cost of various operating systems and management tools, which simplifies the development of cryptographic products.

[0325] In some embodiments, the cryptographic product of the present application can be designed and developed based on Golang to ensure timely maintenance and upgrades and controllable performance.

[0326] In some embodiments, in addition to the two negotiated key authentication methods proposed in the embodiments of the present application, any method using a similar authentication method can implement the authentication of the present application.

[0327] Exemplarily, authentication methods may also include Open Authorization (OAuth), API Key, and TLS / SSL certificates. OAuth does not directly provide usernames and passwords to third parties, but allows users to authorize third-party applications to access their information stored on a specific service provider. API Key is usually used to control access rights to APIs, but it does not provide encryption or signing mechanisms to ensure data integrity.

[0328] Fig.19 A schematic diagram of the structure of a function calling device provided in an embodiment of the present application Figure 1 , the function calling device is applied to the safety bus; such as Fig.19 As shown, the function calling device 1900 includes: a server 1901, an authentication unit 1902 and a management interface unit 1903, wherein:

[0329] The server 1901 is used to receive a call request sent by a request end for calling a kernel function of an operating system;

[0330] The authentication unit 1902 is used to authenticate the identity of the requesting end based on the session key of the secure bus and the call request; the session key of the secure bus is obtained through negotiation between the secure bus and the requesting end;

[0331] The management interface unit 1903 is used to determine the calling method of calling the kernel function of the operating system based on the function type of the kernel function when the identity authentication of the requesting end is passed; and call the kernel function based on the calling method.

[0332] In some embodiments, the call request carries message header information and message body information. The authentication unit 1902 is also used to extract the authentication information of the requesting end in the message header information when the authentication information exists in the message header information and the authentication information is legal; the authentication information of the requesting end is obtained by encrypting the message body information based on the session key of the requesting end; the session key of the requesting end is obtained based on the negotiation between the requesting end and the security bus; the identity of the requesting end is authenticated based on the authentication information of the requesting end, the message body information and the session key of the security bus.

[0333] In some embodiments, the authentication unit 1902 is also used to encrypt the message body information based on the session key of the security bus to obtain the authentication information of the security bus; when the authentication information of the security bus is consistent with the authentication information of the requesting end, it is determined that the identity authentication of the requesting end is passed; when the authentication information of the security bus is inconsistent with the authentication information of the requesting end, it is determined that the identity authentication of the requesting end is not passed.

[0334] In some embodiments, the function calling device 1900 further includes a sending unit, a receiving unit, a decryption unit, and a processing unit, wherein:

[0335] A sending unit, used to encrypt the preset data based on the root key pre-shared with the requesting end, obtain the root key verification value of the security bus, and send the root key verification value of the security bus to the requesting end;

[0336] A receiving unit, configured to receive ciphertext data of the requesting end sent by the requesting end; wherein the ciphertext data of the requesting end is obtained by encrypting the first random number and the number of iterations based on the pre-shared root key when the requesting end determines that the root key check value of the requesting end is consistent with the root key check value of the security bus; the root key check value of the requesting end is obtained by encrypting the preset data by the requesting end using the pre-shared root key;

[0337] A decryption unit, used to decrypt the ciphertext data of the requesting end based on the pre-shared root key to obtain a first random number and an iteration number;

[0338] The processing unit is used to process the pre-shared root key, the first random number, the second random number, the number of iterations and the first byte length based on a preset key generation algorithm to generate a session key of the security bus; the first byte length is the byte length of the session key of the security bus.

[0339] In some embodiments, the call request carries message header information and message body information, and the management interface unit 1903 is also used to determine the function type of the kernel function; the function type includes a first function type and a second function type; the first function type is used to characterize that the kernel function is a built-in function of the operating system; the second function type is used to characterize that the kernel function is a non-built-in function of the operating system; when the function type of the kernel function is the first function type, it is determined that the calling method of calling the kernel function of the operating system is an application program interface call; when the function type of the kernel function is the second function type, it is determined that the calling method of calling the kernel function of the operating system is a command line interpreter call.

[0340] In some embodiments, the management interface unit 1903 is also used to configure a configuration file for indicating calling the kernel function of the operating system; the configuration file is used to indicate the correspondence between the kernel function of the operating system and the calling method; and the kernel function of the operating system is called using the calling method in the configuration file.

[0341] In some embodiments, the function calling device 1900 further includes: an execution unit and a storage unit, wherein:

[0342] An execution unit, configured to, in the event of a failure in executing a call operation on a kernel function, execute a rollback operation according to operation information recorded in a database of the security bus, so as to restore the call operation of the kernel function to a state before the failed call operation is executed;

[0343] The storage unit is used to store the calling operation in the database until the kernel function executes the calling operation successfully.

[0344] In some embodiments, the function calling device 1900 further includes: a first return unit, a conversion unit, and a second return unit, wherein:

[0345] A first returning unit, used for returning an error code when a kernel function call based on a command line interpreter fails;

[0346] A conversion unit, configured to convert the error code into error information corresponding to the error code based on a preset first script; the preset first script is used to define a corresponding relationship between the error code and the operation information;

[0347] The second returning unit is used to return error information corresponding to the error code to the requesting end.

[0348] In some embodiments, the function calling device 1900 is also used to return an error code when a kernel function call based on a command line interpreter fails; based on a preset first script, convert the error code into error information corresponding to the error code; the preset first script is used to define the correspondence between the error code and the operation information; and return the error information corresponding to the error code to the requesting end.

[0349] In some embodiments, the present application also provides a function calling device, which is applied to a requesting end, and includes: a sending and receiving unit, wherein:

[0350] The sending and receiving unit is used to send a call request for calling a kernel function of the operating system to the security bus.

[0351] In some embodiments, the function calling device further includes an encryption unit, a receiving unit, a sending unit, a receiving unit, a decryption unit, and a processing unit, wherein:

[0352] An encryption unit, used to encrypt preset data based on a root key pre-shared with the security bus to obtain a root key check value of the requesting end;

[0353] A receiving unit, used for receiving a root key verification value of a secure bus;

[0354] An encryption unit, configured to encrypt the first random number and the number of iterations based on the pre-shared root key to obtain ciphertext data of the requesting end when the root key check value of the requesting end is consistent with the root key check value of the secure bus;

[0355] A sending unit, used for sending the ciphertext data of the requesting end to the security bus;

[0356] A receiving unit, used for receiving ciphertext data of a security bus sent by the security bus; the ciphertext data of the security bus is obtained by encrypting the second random number based on the pre-shared root key of the security bus;

[0357] A decryption unit, used to decrypt the ciphertext data of the security bus based on the pre-shared root key to obtain a second random number;

[0358] The processing unit is used to process the pre-shared root key, the first random number, the second random number, the number of iterations and the second byte length based on a preset key generation algorithm to generate a session key of the requesting end; the second byte length is the byte length of the session key of the requesting end.

[0359] The description of the above device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. In some embodiments, the functions or modules included in the device provided by the embodiments of the present disclosure can be used to execute the method described in the above method embodiment. For technical details not disclosed in the device embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.

[0360] The embodiment of the present application provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, some or all of the steps in the above method are implemented. The computer-readable storage medium can be transient or non-transient.

[0361] An embodiment of the present application provides a computer program, including a computer-readable code. When the computer-readable code is run in a computer device, a processor in the computer device executes some or all of the steps for implementing the above method.

[0362] The embodiment of the present application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, some or all of the steps in the above method are implemented. The computer program product can be implemented in hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium, and in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0363] Fig. 20 A schematic diagram of a hardware entity of a function calling device in an embodiment of the present application is shown in FIG. Fig. 20 As shown, the hardware entity of the function calling device 2000 includes: a processor 2001, a communication interface 2002 and a memory 2003, wherein:

[0364] The processor 2001 generally controls the overall operation of the function calling device 2000 , and the overall operation may be to implement the function calling method provided in the embodiment of the present application.

[0365] The communication interface 2002 enables the function calling device 2000 to communicate with other terminals or servers through a network.

[0366] The memory 2003 is configured to store instructions and applications executable by the processor 2001, and can also cache data to be processed or processed by the processor 2001 and each module in the function calling device 2000 (for example, image data, audio data, voice communication data, and video communication data), which can be implemented by flash memory (FLASH) or random access memory (Random Access Memory, RAM). Data can be transmitted between the processor 2001, the communication interface 2002, and the memory 2003 through the bus 2004.

[0367] It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the size of the serial number of each step / process mentioned above does not mean the order of execution, and the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. The serial numbers of the embodiments of the present application mentioned above are for description only and do not represent the advantages and disadvantages of the embodiments.

[0368] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0369] The above are only implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. A function calling method, characterized in that: The function calling method is applied to a security bus, and the function calling method comprises: Receiving a call request sent by a requesting end for calling a kernel function of an operating system; Based on the session key of the security bus and the call request, the identity of the requesting end is authenticated; the session key of the security bus is obtained through negotiation between the security bus and the requesting end; In the case where the identity authentication of the requesting end is passed, determining a calling mode of calling the kernel function of the operating system based on the function type of the kernel function; Calling the kernel function based on the calling mode; Wherein, determining the calling mode of calling the kernel function of the operating system based on the function type of the kernel function includes: Determine a function type of the kernel function; the function type includes a first function type and a second function type; the first function type is used to characterize that the kernel function is a built-in function of the operating system; the second function type is used to characterize that the kernel function is a non-built-in function of the operating system; In a case where the function type of the kernel function is the first function type, determining that the calling method of calling the kernel function of the operating system is an application program interface call; When the function type of the kernel function is the second function type, it is determined that the calling mode of calling the kernel function of the operating system is a command line interpreter call.

2. The function calling method according to claim 1, characterized in that: The call request carries message header information and message body information; The step of authenticating the requesting end based on the session key of the secure bus and the calling request includes: When authentication information exists in the message header information and the authentication information is legal, extract the authentication information of the requesting end in the message header information; the authentication information of the requesting end is obtained by encrypting the message body information based on the session key of the requesting end; the session key of the requesting end is obtained based on the negotiation between the requesting end and the security bus; The identity of the requesting end is authenticated based on the authentication information of the requesting end, the message body information and the session key of the secure bus.

3. The function calling method according to claim 2, characterized in that: The step of authenticating the identity of the requesting end based on the authentication information of the requesting end, the message body information, and the session key of the secure bus includes: Encrypting the message body information based on the session key of the secure bus to obtain authentication information of the secure bus; When the authentication information of the secure bus is consistent with the authentication information of the requesting end, determining that the identity authentication of the requesting end is passed; When the authentication information of the secure bus is inconsistent with the authentication information of the requesting end, it is determined that the identity authentication of the requesting end fails.

4. The function calling method according to claim 1, characterized in that: The method further comprises: Encrypting the preset data based on the root key pre-shared with the requesting end to obtain the root key verification value of the secure bus, and sending the root key verification value of the secure bus to the requesting end; Receiving ciphertext data of the requesting end sent by the requesting end; wherein the ciphertext data of the requesting end is obtained by encrypting a first random number and a number of iterations based on the pre-shared root key when the requesting end determines that the root key check value of the requesting end is consistent with the root key check value of the security bus; the root key check value of the requesting end is obtained by the requesting end encrypting the preset data using the pre-shared root key; Decrypting the ciphertext data of the requesting end based on the pre-shared root key to obtain the first random number and the number of iterations; Based on a preset key generation algorithm, the pre-shared root key, the first random number, the second random number, the number of iterations and the first byte length are processed to generate a session key for the security bus; the first byte length is the byte length of the session key for the security bus.

5. The function calling method according to claim 1, characterized in that: The calling of the kernel function based on the calling mode includes: Configuring a configuration file for indicating calling a kernel function of the operating system; the configuration file is used to indicate a corresponding relationship between the kernel function of the operating system and the calling method; The kernel function of the operating system is called using the calling method in the configuration file.

6. The function calling method according to any one of claims 1 to 5, characterized in that: The function calling method also includes: In the case where the call operation to the kernel function fails, a rollback operation is performed according to the operation information recorded in the database of the security bus to restore the call operation of the kernel function to a state before the failed call operation is performed; Until the kernel function executes the calling operation successfully, the calling operation is stored in the database.

7. The function calling method according to claim 1, characterized in that: The function calling method also includes: In the event of failure in calling the kernel function based on the command line interpreter, returning an error code; Based on a preset first script, converting the error code into error information corresponding to the error code; the preset first script is used to define a corresponding relationship between the error code and the operation information; The error information corresponding to the error code is returned to the requesting end.

8. A function calling method, characterized in that: The function calling method is applied to the requesting end, and the function calling method includes: Sending a call request for calling a kernel function of an operating system to a security bus; Wherein, the security bus is used to authenticate the identity of the requesting end based on the session key of the requesting end; if the identity authentication of the requesting end is passed, based on the function type of the kernel function, determine the calling method of calling the kernel function of the operating system; call the kernel function of the operating system based on the calling method; wherein, determining the calling method of calling the kernel function of the operating system based on the function type of the kernel function includes: determining the function type of the kernel function; the function type includes a first function type and a second function type; the first function type is used to characterize that the kernel function is a built-in function of the operating system; the second function type is used to characterize that the kernel function is a non-built-in function of the operating system; if the function type of the kernel function is the first function type, determine that the calling method of calling the kernel function of the operating system is an application program interface call; if the function type of the kernel function is the second function type, determine that the calling method of calling the kernel function of the operating system is a command line interpreter call.

9. The function calling method according to claim 8, characterized in that: The method further comprises: Encrypting the preset data based on the root key pre-shared with the secure bus to obtain the root key verification value of the requesting end; Receiving a root key check value of the secure bus; When the root key check value of the requesting end is consistent with the root key check value of the secure bus, encrypting the first random number and the number of iterations based on the pre-shared root key to obtain the ciphertext data of the requesting end; Sending the ciphertext data of the requesting end to a secure bus; Receiving ciphertext data of the security bus sent by the security bus; the ciphertext data of the security bus is obtained by encrypting the second random number based on the pre-shared root key of the security bus; Decrypting the ciphertext data of the security bus based on the pre-shared root key to obtain the second random number; Based on a preset key generation algorithm, the pre-shared root key, the first random number, the second random number, the number of iterations and the second byte length are processed to generate the session key of the requesting end; the second byte length is the byte length of the session key of the requesting end.

10. A function calling device, characterized in that: The function calling device is applied to a safety bus, and the function calling device comprises: The server is used to receive a call request sent by a requesting end for calling a kernel function of an operating system; An authentication unit, configured to authenticate the identity of the requesting end based on the session key of the secure bus and the calling request; the session key of the secure bus is obtained through negotiation between the secure bus and the requesting end; A management interface unit is used to determine, if the identity authentication of the requesting end is passed, a calling method for calling the kernel function of the operating system based on the function type of the kernel function; and call the kernel function based on the calling method; wherein, determining the calling method for calling the kernel function of the operating system based on the function type of the kernel function comprises: determining the function type of the kernel function; the function type comprises a first function type and a second function type; the first function type is used to characterize that the kernel function is a built-in function of the operating system; the second function type is used to characterize that the kernel function is a non-built-in function of the operating system; if the function type of the kernel function is the first function type, determining that the calling method for calling the kernel function of the operating system is an application program interface call; if the function type of the kernel function is the second function type, determining that the calling method for calling the kernel function of the operating system is a command line interpreter call.

11. A function calling device, characterized in that: include: A memory for storing executable instructions; A processor, configured to implement the method described in any one of claims 1 to 7, or the method described in any one of claims 8 to 9, when executing the executable instructions stored in the memory.

12. A storage medium, characterized in that: The storage medium stores executable instructions, which, when executed by a processor, implement the method described in any one of claims 1 to 7, or the method described in any one of claims 8 to 9.

13. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the method described in any one of claims 1 to 7 or the method described in any one of claims 8 to 9 is implemented.

Images