A security detection method, system, device and storage medium
By verifying the firmware signature at server startup and performing two-way authentication during microservice communication, the problem of neglecting server hardware security in existing technologies is solved, thereby improving the overall security of the server and the reliability of microservice communication.
Patent Information
- Application Number
- CN202310827855.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-07-06
- Publication Date
- 2026-02-03
- Estimated Expiration
- 2043-07-06
AI Technical Summary
Existing technologies only perform security checks on the application layer in server security testing, ignoring potential dangers in the server itself, which leads to a decrease in overall operational security, especially making hardware chip attacks difficult to detect.
When the server starts, its identity is verified, and the trusted signature of the firmware is obtained and verified. If there is no abnormality, the microservice is allowed to start; otherwise, an error is displayed. When the microservice communicates, two-way authentication is performed, and the file is encrypted with a private key for authentication.
Multi-dimensional security testing improves the overall security of server operation, prevents hardware chip attacks, and ensures the security of microservice communication.
Smart Images

Figure CN116866028B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of network security, and in particular to a security detection method, system, device and storage medium. BACKGROUND
[0002] With the advent of the digital era, various servers have emerged and are widely used in various industries and life. A server can mainly be composed of a CPU, a hard disk, a memory, a system, a system bus, etc., and provides computing or application services for other clients (such as computers, smart phones, etc.) in a network. A server can carry many application services to meet the needs of users, and these application services can be implemented based on a micro-service architecture, with one application service corresponding to one micro-service. The micro-service architecture refers to the composition of a single application program by many loosely coupled and independently deployable smaller components or services.
[0003] However, with the iterative development of information security technology, attackers have adopted various attack methods, especially starting from the hardware chips of servers. Once successful, they can avoid tracking by antivirus software and security auxiliary tools installed on the server, and have high concealment, making it difficult for attackers to detect.
[0004] For example, as shown in FIG. 1, when micro-service a of server A wants to access micro-service b of server B, micro-service A submits its signature, access target, and request parameters to the micro-service proxy platform; the micro-service proxy platform verifies micro-service a, and if it is legal, sends a token to micro-service a, which sends its token to micro-service b. If micro-service b verifies that the token of the opposite end is qualified, communication is established between micro-service a and micro-service b. This way of security detection only detects the security of the application layer, and the security of the server before the start of the micro-service is unknown, ignoring whether the server itself has potential dangers, thereby reducing the overall security of the server. Figure 1 SUMMARY
[0005] The present application provides a security detection method to improve the overall security of the server.
[0006] In a first aspect, a security detection method is provided, comprising:
[0007] When it is determined that the first server identity verification is qualified, the trusted signature of the firmware to be detected in the first server is obtained, the first server being a server in a domain; the trusted signature is verified to determine whether the firmware is abnormal; if the firmware is normal, a start instruction indicating the start of a first micro-service is output, the first micro-service being a micro-service deployed on the first server; and if the firmware is abnormal, prompt information indicating that the firmware is abnormal is output.
[0008] Optionally, after the output indicates the start command of the first microservice in the first server, it further includes:
[0009] Record the basic information of the first microservice; wherein, the basic information includes at least one of the first microservice port number, the first microservice intranet domain name information, and the first microservice version number; generate a first private key and a first public key based on the basic information of the first microservice and the device information of the first server; send the first private key to the first microservice and store the first public key.
[0010] Optionally, the method further includes:
[0011] When the first microservice and the second microservice are about to establish a communication connection, the system obtains a first encrypted file encrypted by the first microservice using the first private key and a second encrypted file encrypted by the second microservice using the second private key. The second microservice is a microservice deployed on the second server within the domain service, and the second private key is generated based on the basic information of the second microservice and the device information of the second server. The system authenticates the first microservice based on the first encrypted file and the second microservice based on the second encrypted file. If both the first and second microservices are successfully authenticated, the system sends the IP address of the first microservice to the second microservice and the IP address of the second microservice to the first microservice, enabling the first and second microservices to establish a communication connection based on each other's IP addresses.
[0012] Optionally, determining that the first server's identity verification is successful includes:
[0013] Obtain the device information of the first server; verify the identity of the first server based on the device information; if the device information meets the specifications, determine that the identity verification of the first server is qualified.
[0014] Optionally, the firmware to be detected includes at least one of the following:
[0015] BIOS firmware; bootloader firmware; system kernel firmware.
[0016] Optionally, the method further includes:
[0017] If it is determined that the identity verification of the first server is unsuccessful, a shutdown command instructing the first server to be shut down will be output.
[0018] Secondly, a security detection system is provided, including:
[0019] Security detection module, trusted signature storage module;
[0020] The security detection module is used to, when determining that the identity verification of the first server is qualified, obtain the trusted signature of the firmware to be tested in the first server from the trusted signature storage module, wherein the first server is a server in a domain server; verify the trusted signature to determine whether the firmware is abnormal; if the firmware is normal, output a start command indicating that the first microservice is started, wherein the first microservice is a microservice deployed on the first server; if the firmware is abnormal, output a prompt message indicating that the firmware is abnormal; the trusted signature storage module is used to store the trusted signature of the firmware to be tested in the first server.
[0021] Optionally, the security detection module is further used for:
[0022] Record the basic information of the first microservice; wherein, the basic information includes at least one of the first microservice port number, the first microservice intranet domain name information, and the first microservice version number; generate a first private key and a first public key based on the basic information of the first microservice and the device information of the first server; send the first private key to the first microservice and store the first public key.
[0023] Optionally, the security detection module is further used for:
[0024] When the first microservice and the second microservice are about to establish a communication connection, the system obtains a first encrypted file encrypted by the first microservice using the first private key and a second encrypted file encrypted by the second microservice using the second private key. The second microservice is a microservice deployed on the second server within the domain service, and the second private key is generated based on the basic information of the second microservice and the device information of the second server. The system authenticates the first microservice based on the first encrypted file and the second microservice based on the second encrypted file. If both the first and second microservices are successfully authenticated, the system sends the IP address of the first microservice to the second microservice and the IP address of the second microservice to the first microservice, enabling the first and second microservices to establish a communication connection based on each other's IP addresses.
[0025] Optionally, the security detection module is specifically used for:
[0026] Obtain the device information of the first server; verify the identity of the first server based on the device information; if the device information meets the specifications, determine that the identity verification of the first server is qualified.
[0027] Optionally, the firmware to be detected includes at least one of the following:
[0028] BIOS firmware; bootloader firmware; system kernel firmware.
[0029] Optionally, the security detection module is further used for:
[0030] If it is determined that the identity verification of the first server is unsuccessful, a shutdown command instructing the first server to be shut down will be output.
[0031] Thirdly, an electronic device is provided, comprising:
[0032] A memory for storing computer programs; a processor for executing the computer programs stored in the memory to implement the method steps described in any one of the first aspects.
[0033] Fourthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements the steps of the method described in any one of the first aspects.
[0034] In this embodiment, when the identity verification of the first server is determined to be qualified, a trusted signature of the firmware to be tested within the first server is obtained. The first server is a server within a domain server. The trusted signature is verified to determine whether the firmware is abnormal. If the firmware is normal, a startup command instructing the first microservice to start is output. The first microservice is a microservice deployed on the first server. If the firmware is abnormal, a prompt message indicating that the firmware is abnormal is output. Since the above method not only verifies the identity of the server itself but also verifies the firmware within the server when the microservice starts, it takes into account the security risks that exist when the microservice starts from multiple aspects, thereby improving the overall security of the server operation.
[0035] For the various aspects of the second to fourth aspects mentioned above, and the technical effects that each aspect may achieve, please refer to the above description of the technical effects that can be achieved for the first aspect or the various possible solutions in the first aspect, which will not be repeated here. Attached Figure Description
[0036] Figure 1 A schematic diagram illustrating a scenario for performing security checks on current microservice access;
[0037] Figure 2 This is a schematic diagram illustrating an application scenario applicable to an embodiment of this application;
[0038] Figure 3 A flowchart illustrating a security detection method provided in this application embodiment;
[0039] Figure 4A flowchart of microservice access provided in an embodiment of this application;
[0040] Figure 5 A flowchart illustrating a complete security detection method provided in this application embodiment;
[0041] Figure 6 This is a schematic diagram of the structure of a security detection system provided in an embodiment of this application;
[0042] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0043] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The specific operational methods in the method embodiments can also be applied to the device embodiments or system embodiments. It should be noted that in the description of this application, "multiple" is understood as "at least two". "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. A connected to B can represent: A and B directly connected, and A and B connected through C. Furthermore, in the description of this application, terms such as "first" and "second" are used only for distinguishing the purpose of description and should not be construed as indicating or implying relative importance or order.
[0044] To facilitate understanding by those skilled in the art, the nouns and technical terms involved in the embodiments of this application will be explained first.
[0045] (1) The Basic Input Output System (BIOS) firmware is a set of system programs embedded in a memory chip on the motherboard of a computing device. It plays an indispensable role in the normal initialization, startup and operating system boot of the computer system, and is a key link in realizing the key functions of the computer system such as security and reliability.
[0046] (2) The boot program is located on a computer or other computer application and refers to the program that boots the operating system.
[0047] (3) The system kernel is the most basic part of the operating system. It is responsible for managing the system's processes, memory, device drivers, files and network systems, and determines the performance and stability of the operating system.
[0048] (4) Firmware refers to the device driver stored inside the terminal device. Through the firmware, the operating system can realize the specific machine's operation according to the standard device driver. For example, optical drives and burners all have internal firmware.
[0049] (5) Microservice architecture advocates breaking down a single application into multiple small services, each of which runs in its own independent process and uses lightweight communication mechanisms to provide the final value to the user.
[0050] (6) Asymmetric keys are used for asymmetric encryption. It uses a pair of keys, one for encryption and one for decryption. The key for encryption is called the private key, and the key for decryption is called the public key.
[0051] The following is a brief introduction to the application scenarios to which the technical solutions of the embodiments of this application are applicable. It should be noted that the application scenarios described below are only for illustrating the embodiments of this application and are not intended to limit the scope. In specific implementation, the technical solutions provided by the embodiments of this application can be flexibly applied according to actual needs.
[0052] Figure 2 This is a schematic diagram illustrating an application scenario applicable to the embodiments of this application. For example... Figure 2 As shown, the application scenario mainly includes: a security detection system 200, a server 201, and a server 202; wherein, a microservice 201a is deployed on server 201, and a microservice 202b is deployed on server 202. The security detection system 200 can communicate with the microservice 201a on server 201 and the microservice 202b on server 202 respectively, and the microservice 201a and the microservice 202b can also communicate with each other.
[0053] It should be noted that this application embodiment does not impose any limitations on the number of servers or the number of microservices deployed on the servers. Multiple servers constitute a single domain server. Figure 2 The description only uses 2 servers and 2 microservices.
[0054] It should be noted that the embodiments of this application do not impose any restrictions on the scale or type of the above-mentioned servers. In terms of scale, servers 201 and 202 can be workgroup servers, department servers, enterprise servers, etc.; in terms of type, servers 201 and 202 can be rack servers, blade servers, cabinet servers, etc.
[0055] Security detection system 200, used when the server (e.g., Figure 2 When server 201 starts up, it can perform identity verification on server 201 itself; it can also perform security verification on the firmware in server 201; furthermore, it can also perform security verification on the interactions between microservices (e.g., Figure 2When microservices 201a and 202b communicate, two-way authentication is performed. If any of the above steps fails the verification, a corresponding prompt will be given. This allows for security performance testing during server startup, operation, and access, thus improving overall security.
[0056] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation steps as shown in the following embodiments or drawings, the method may include more or fewer operation steps based on conventional or non-inventive methods. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application. In actual processing or when the device executes the method, it may be executed in the order shown in the embodiments or drawings, or in combination.
[0057] Figure 3 A flowchart illustrating a security detection method provided in an embodiment of this application. This process can be performed by a security detection system (such as...). Figure 2 The security detection system 200 shown is used to improve the overall security of the server operation. Figure 3 As shown, the process includes the following steps:
[0058] 301: When the identity verification of the first server is determined to be qualified, obtain the trusted signature of the firmware to be tested within the first server.
[0059] In this step, the first server can specifically be... Figure 2 The server shown is 201 or 202.
[0060] Optionally, the identity of the first server can be verified, specifically through the following methods:
[0061] Obtain the device information of the first server, which may include the server's Internet Protocol Address (IP) address, model, serial number, name, etc. Verify the identity of the first server based on the device information to determine whether the model, serial number, etc. in the device information meet the specifications. If yes, the identity verification of the first server is deemed qualified; otherwise, it indicates that the first server does not meet the specifications, and output a shutdown command to shut down the first server and prohibit the first server from accessing the network.
[0062] Optionally, the firmware to be detected may include BIOS firmware, bootloader firmware, system kernel firmware, and may also include other firmware that is easily attacked. This application embodiment does not limit this.
[0063] 302: Verify the above trusted signature to determine if there is any abnormality in the above firmware. If yes, proceed to 303; otherwise, proceed to 304.
[0064] Optionally, verifying the aforementioned trusted signature may include the following aspects:
[0065] Aspect 1: Verify whether the content in the trusted signature is complete. If it is, it indicates that the firmware is normal and proceeds to 304. If not, it indicates that the firmware is abnormal and proceeds to 303.
[0066] Aspect 2: Verify if the signature time is valid. If it is, the firmware is normal and will proceed to 304. If not, the firmware is abnormal and will proceed to 303.
[0067] Aspect 3: If the security certificate exists, it indicates that the firmware is normal and will proceed to 304. If not, it indicates that the firmware is abnormal and will proceed to 303.
[0068] It should be noted that the above-mentioned aspects are only examples. In actual practice, other verifications can be performed on trusted signatures. The application implementation is not limited here.
[0069] It should be noted that determining whether the firmware is abnormal can be done by verifying one of the above-mentioned aspects or by verifying multiple aspects. This application embodiment does not impose any limitations on this.
[0070] 303: Outputs a message indicating an error in the firmware.
[0071] Optionally, the prompt information may include firmware identification, location, cause of the error, etc., to facilitate prompting the user to take appropriate measures.
[0072] 304: Outputs the startup command indicating that the first microservice has started.
[0073] In this step, the first microservice is the microservice deployed on the first server (e.g., Figure 2 The microservices shown are 201a).
[0074] Optionally, after outputting the startup command indicating the start of the first microservice, basic information of the first microservice can also be recorded. This basic information includes at least one of the following: the port number of the first microservice, the intranet domain name information of the first microservice, and the version number of the first microservice. Based on the basic information of the first microservice and the device information of the first server, a first private key and a first public key are generated. The first private key is sent to the first microservice, and the first public key is stored so that the first microservice can encrypt relevant device information, basic information, etc., based on the first private key, thereby further ensuring the security of communication.
[0075] Optionally, the first public key and the first private key can be generated based on one of the following algorithms: Digital Signature Algorithm (DSA), RSA, or DH.
[0076] It should be noted that other servers within the domain can also follow the same procedure when starting or deploying microservices. Figure 3 The method shown is used for safety performance testing, and will not be described again here.
[0077] In this embodiment, when the identity verification of the first server is determined to be qualified, a trusted signature of the firmware to be tested within the first server is obtained. The first server is a server within a domain server. The trusted signature is verified to determine whether the firmware is abnormal. If the firmware is normal, a startup command instructing the first microservice to start is output. The first microservice is a microservice deployed on the first server. If the firmware is abnormal, a prompt message indicating that the firmware is abnormal is output. Since the above method not only verifies the identity of the server itself but also verifies the firmware within the server when the microservice starts, it takes into account the security risks that exist when the microservice starts from multiple aspects, thereby improving the overall security of the server operation.
[0078] In some embodiments, when independent servers within a domain server need to establish a communication connection, two-way authentication can be performed on both sides to ensure that there are no security risks when the microservices at both ends communicate, further improving the overall security of the server operation. Figure 4 As shown, an exemplary flowchart of a microservice access method provided in an embodiment of this application is illustrated. The process includes the following steps:
[0079] 401: When the first microservice and the second microservice are about to establish a communication connection, obtain the first encrypted file encrypted by the first microservice using the first private key and the second encrypted file encrypted by the second microservice using the second private key.
[0080] The first microservice can be Figure 2 The microservice 202a shown can be a second microservice. Figure 2 The microservice 202b shown here has a second private key generated based on the basic information of the second microservice and the device information of the second server.
[0081] Optionally, the first encrypted file may specifically include the device information of the first server, a trusted signature, and basic information of the first microservice, and the second encrypted file may specifically include the device information of the second server, a trusted signature, and basic information of the second microservice.
[0082] 402: Authenticate the first microservice according to the first encrypted file and the second microservice according to the second encrypted file, and determine whether the first microservice and the second microservice are both successfully authenticated. If yes, proceed to 403; otherwise, proceed to 404.
[0083] Optionally, to determine whether the first microservice has been successfully authenticated, the following steps can be taken: after decrypting the first encrypted file using the first public key paired with the first private key, verify the trusted signature, device information, and microservice version number in the first encrypted file one by one. If the verification is successful, the first microservice is confirmed to be successfully authenticated and the process is redirected to 403; otherwise, it indicates that the first microservice has a security vulnerability and the process is redirected to 404.
[0084] Optionally, to determine whether the second microservice has been successfully authenticated, the following steps can be taken: after decrypting the second encrypted file using the second public key paired with the second private key, verify the trusted signature, device information, and microservice version number in the second encrypted file one by one. If the verification is successful, the second microservice is confirmed to be successfully authenticated and the process is redirected to 403; otherwise, it indicates that the second microservice has a security vulnerability and the process is redirected to 404.
[0085] 403: Send the IP address of the first microservice to the second microservice, and send the IP address of the second microservice to the first microservice.
[0086] In this step, once both parties obtain each other's IP addresses, they can establish a communication connection.
[0087] In some embodiments, during microservice communication, the server's device information, trusted signature, and basic information of the microservice can be verified at set intervals, thereby enabling timely detection of servers with security vulnerabilities and further improving the overall security of the server operation.
[0088] 404: Communication between the first microservice and the second microservice is prohibited.
[0089] During microservice access, through the above Figure 4 The two-way authentication shown allows both parties to verify the security of each other's microservices, compared to using one-way authentication (such as...). Figure 1 (As shown) this further ensures security during the access process.
[0090] Based on the above Figure 3 and Figure 4 The method shown, Figure 5 This is a flowchart illustrating a complete security detection method provided in an embodiment of this application. Figure 5 As shown, the process includes the following steps:
[0091] 501: When the first server starts, obtain the device information of the first server.
[0092] The first server can be Figure 1 The server shown is 201.
[0093] 502: Based on the device information, determine whether the identity of the first server is valid. If yes, proceed to 503; otherwise, output a shutdown command to shut down the first server.
[0094] 503: Obtain the trusted signature of the firmware to be tested within the first server.
[0095] 504: Verify the trusted signature of the firmware to determine if there is any abnormality in the firmware. If not, proceed to 505; if yes, output a message indicating that there is an abnormality in the firmware.
[0096] 505: Outputs the startup command indicating that the first microservice is started.
[0097] The first microservice could be Figure 1 The microservice 201a shown.
[0098] 506: Record the basic information of the first microservice, and generate the first private key and the first public key based on the basic information and the device information of the first server.
[0099] 507: Send the first private key to the first microservice and store the first public key.
[0100] 508: When the first microservice and the second microservice are about to establish a communication connection, perform two-way authentication with the first microservice and the second microservice respectively to determine whether the first microservice and the second microservice have both been successfully authenticated. If yes, proceed to 509; otherwise, prohibit the first microservice and the second microservice from establishing a communication connection.
[0101] The two-way authentication in this step Figure 4 Similarities will not be repeated here.
[0102] 509: Send the IP address of the first microservice to the second microservice, and send the IP address of the second microservice to the first microservice, so that both parties can obtain each other's IP addresses and establish a communication connection.
[0103] Through the above Figure 5 As shown, during microservice access, the server identity is first verified, then the firmware on the server is verified, and finally two-way authentication is performed. Security performance is tested from multiple dimensions, which improves overall security and enhances user experience.
[0104] Based on the same technical concept, this application also provides a schematic diagram of a security detection system, which can implement the security detection method flow described in this application.
[0105] Figure 6 This is a schematic diagram of a security detection system provided in an embodiment of this application. Figure 6 As shown, the system includes: a security detection module 601 and a trusted signature storage module 602.
[0106] The security detection module 601 is used to, when the identity verification of the first server is determined to be qualified, obtain the trusted signature of the firmware to be tested in the trusted signature storage module from the trusted signature storage module, wherein the first server is a server in the domain server; verify the trusted signature to determine whether the firmware is abnormal; if the firmware is normal, output a start command indicating the start of the first microservice, wherein the first microservice is a microservice deployed on the first server; if the firmware is abnormal, output a prompt message indicating that the firmware is abnormal.
[0107] The trusted signature storage module 602 is used to store the trusted signature of the firmware to be tested in the first server.
[0108] Optionally, the security detection module 601 is further configured to:
[0109] Record the basic information of the first microservice; wherein, the basic information includes at least one of the first microservice port number, the first microservice intranet domain name information, and the first microservice version number; generate a first private key and a first public key based on the basic information of the first microservice and the device information of the first server; send the first private key to the first microservice and store the first public key.
[0110] Optionally, the security detection module 601 is further configured to:
[0111] When the first microservice and the second microservice are about to establish a communication connection, the system obtains a first encrypted file encrypted by the first microservice using the first private key and a second encrypted file encrypted by the second microservice using the second private key. The second microservice is a microservice deployed on the second server within the domain service, and the second private key is generated based on the basic information of the second microservice and the device information of the second server. The system authenticates the first microservice based on the first encrypted file and the second microservice based on the second encrypted file. If both the first and second microservices are successfully authenticated, the system sends the IP address of the first microservice to the second microservice and the IP address of the second microservice to the first microservice, enabling the first and second microservices to establish a communication connection based on each other's IP addresses.
[0112] Optionally, the security detection module 601 is specifically used for:
[0113] Obtain the device information of the first server; verify the identity of the first server based on the device information; if the device information meets the specifications, determine that the identity verification of the first server is qualified.
[0114] Optionally, the security detection module 601 is further configured to:
[0115] If it is determined that the identity verification of the first server is unsuccessful, a shutdown command instructing the first server to be shut down will be output.
[0116] It should be noted that the system provided in this application embodiment can implement all the method steps in the above method embodiment and achieve the same technical effect. Therefore, the parts and beneficial effects that are the same as those in the method embodiment will not be described in detail here.
[0117] Based on the same technical concept, this application also provides an electronic device that can realize the functions of the aforementioned security detection system.
[0118] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.
[0119] At least one processor 701 and a memory 702 connected to at least one processor 701. In this embodiment, the specific connection medium between the processor 701 and the memory 702 is not limited. Figure 7 The example shown is the connection between processor 701 and memory 702 via bus 700. Bus 700 is... Figure 7The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. The 700 bus can be divided into address bus, data bus, control bus, etc., for ease of representation. Figure 7 The term is represented by a single thick line, but this does not imply that there is only one bus or one type of bus. Alternatively, the processor 701 can also be called a controller; there is no restriction on the name.
[0120] In this embodiment, memory 702 stores instructions executable by at least one processor 701. By executing the instructions stored in memory 702, at least one processor 701 can perform a security detection method as described above. Processor 701 can implement... Figure 6 The system shown illustrates the functions of each module.
[0121] The processor 701 is the control center of the device. It can connect to various parts of the control device through various interfaces and lines. By running or executing instructions stored in memory 702 and calling data stored in memory 702, the processor can perform various functions and process data, thereby monitoring the device as a whole.
[0122] In one possible design, processor 701 may include one or more processing units. Processor 701 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into processor 701. In some embodiments, processor 701 and memory 702 may be implemented on the same chip; in some embodiments, they may also be implemented on separate chips.
[0123] The processor 701 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit, field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of a security detection method disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules within the processor.
[0124] Memory 702, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 702 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 702 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 702 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.
[0125] By designing and programming the processor 701, the code corresponding to a security detection method described in the foregoing embodiments can be embedded into the chip, enabling the chip to execute the code during operation. Figure 3 The illustrated embodiment presents a security detection method. How to design and program the processor 701 is a technique well-known to those skilled in the art and will not be described further here.
[0126] It should be noted that the electronic device provided in this application embodiment can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.
[0127] This application also provides a computer-readable storage medium storing computer-executable instructions for causing a computer to execute a security detection method described in the above embodiments.
[0128] This application also provides a computer program product, which, when invoked by a computer, causes the computer to execute a security detection method described in the above embodiments.
[0129] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0130] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0131] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0132] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 Figure 1 The steps of the function specified in one or more boxes.
Claims
1. A security detection method, characterized in that, include: When the identity verification of the first server is found to be qualified, the trusted signature of the firmware to be tested in the first server is obtained. The first server is a server in the domain. The trusted signature is verified to determine whether the firmware is abnormal; If the firmware is normal, a startup command is output indicating that the first microservice is started. The first microservice is the microservice deployed on the first server. If the firmware is faulty, a message indicating that the firmware is faulty will be output. The method further includes: When the first microservice and the second microservice are about to establish a communication connection, the system obtains a first encrypted file encrypted by the first microservice using a first private key and a second encrypted file encrypted by the second microservice using a second private key; wherein, the second microservice is a microservice deployed on the second server in the domain service, and the second private key is generated based on the basic information of the second microservice and the device information of the second server; wherein, the first private key is generated based on the basic information of the first microservice and the device information of the first server; The first microservice is authenticated based on the first encrypted file, and the second microservice is authenticated based on the second encrypted file; If both the first microservice and the second microservice are successfully authenticated, the IP address of the first microservice is sent to the second microservice, and the IP address of the second microservice is sent to the first microservice, so that the first microservice and the second microservice can establish a communication connection based on each other's IP addresses.
2. The method as described in claim 1, characterized in that, After the output indicates the start command of the first microservice in the first server, it also includes: Record the basic information of the first microservice; wherein, the basic information includes at least one of the following: the port number of the first microservice, the intranet domain name information of the first microservice, and the version number of the first microservice; Based on the basic information of the first microservice and the device information of the first server, a first public key is also generated; Send the first private key to the first microservice and store the first public key.
3. The method as described in claim 1, characterized in that, The determination that the first server's identity verification is qualified includes: Obtain the device information of the first server; The identity of the first server is verified based on the device information; If the device information meets the specifications, then the identity verification of the first server is deemed successful.
4. The method as described in claim 1, characterized in that, The firmware to be detected includes at least one of the following: Basic Input / Output System (BIOS) firmware; Bootloader firmware; System kernel firmware.
5. The method as described in claim 1, characterized in that, The method further includes: If it is determined that the identity verification of the first server is unsuccessful, a shutdown command instructing the first server to be shut down will be output.
6. A security detection system, characterized in that, The system includes: a security detection module and a trusted signature storage module; The security detection module is used to, when determining that the identity verification of the first server is qualified, obtain the trusted signature of the firmware to be tested in the trusted signature storage module, where the first server is a server in the domain server; verify the trusted signature to determine whether the firmware is abnormal; if the firmware is normal, output a start command indicating the start of the first microservice, where the first microservice is a microservice deployed on the first server; if the firmware is abnormal, output a prompt message indicating that the firmware is abnormal. The trusted signature storage module is used to store the trusted signature of the firmware to be tested in the first server; The security detection module is further configured to: When the first microservice and the second microservice are about to establish a communication connection, the system obtains a first encrypted file encrypted by the first microservice using a first private key and a second encrypted file encrypted by the second microservice using a second private key; wherein, the second microservice is a microservice deployed on the second server in the domain service, and the second private key is generated based on the basic information of the second microservice and the device information of the second server; wherein, the first private key is generated based on the basic information of the first microservice and the device information of the first server; The first microservice is authenticated based on the first encrypted file, and the second microservice is authenticated based on the second encrypted file; If both the first microservice and the second microservice are successfully authenticated, the IP address of the first microservice is sent to the second microservice, and the IP address of the second microservice is sent to the first microservice, so that the first microservice and the second microservice can establish a communication connection based on each other's IP addresses.
7. The system as described in claim 6, characterized in that, The security detection module is also used for: Record the basic information of the first microservice; wherein, the basic information includes at least one of the following: the port number of the first microservice, the intranet domain name information of the first microservice, and the version number of the first microservice; Based on the basic information of the first microservice and the device information of the first server, a first public key is also generated; Send the first private key to the first microservice and store the first public key.
8. The system as described in claim 6, characterized in that, The security detection module is specifically used for: Obtain the device information of the first server; The identity of the first server is verified based on the device information; If the device information meets the specifications, then the identity verification of the first server is deemed successful.
9. The system as described in claim 6, characterized in that, The firmware to be detected includes at least one of the following: Basic Input / Output System (BIOS) firmware; Bootloader firmware; System kernel firmware.
10. The system as described in claim 6, characterized in that, The security detection module is also used for: If it is determined that the identity verification of the first server is unsuccessful, a shutdown command instructing the first server to be shut down will be output.
11. An electronic device, characterized in that, include: Memory, used to store computer programs; The processor, when executing the computer program stored in the memory, implements the security detection method according to any one of claims 1-5.
12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the security detection method according to any one of claims 1-5.
Citation Information
Patent Citations
Trusted BMC (Baseboard Management Controller)-based server safe-starting method
CN107506663A
Server BIOS full life cycle safety protection system based on BMC
CN114444083A