Safe acquisition method and device of BMC information, equipment and medium

Abstract

The invention relates to the technical field of BMC security, and provides a security acquisition method and device of BMC information, equipment and a medium, and the method comprises the steps: generating a one-time public key and a one-time private key for a single communication session according to a self MAC address and real-time time; performing hash operation on the one-time public key to obtain a one-time public key hash value; sending the one-time public key hash value to a key management server, so that the key management server signs the one-time public key hash value by using a preset private key, and receiving a returned signature result; packaging the one-time public key and the signature result into a request message, and broadcasting the request message to a local area network to enable the BMC to generate and return an encrypted response message after signature verification; and monitoring and receiving an encrypted response message returned by the BMC, decrypting the encrypted response message by using the one-time private key, and extracting and displaying BMC information. According to the technical scheme, confidentiality, safety and integrity of the response information in the transmission process are guaranteed.

Description

Technical Field

[0001] This application relates to the field of BMC security technology, and in particular to a method, apparatus, device and medium for securely acquiring BMC information. Background Technology

[0002] The Baseboard Management Controller (BMC) serves as the core entry point for remote server operation and maintenance and troubleshooting. The efficiency and security of obtaining the IP address and related device information of its management network port directly impact the operational efficiency and business continuity of the data center. In practical applications, when the BMC's IP address cannot be obtained normally due to accidental modification, loss, or unknown configuration, existing technical solutions still have several unresolved pain points, specifically as follows: Dependent on system operating status, completely ineffective in downtime scenarios: Existing solutions for obtaining BMC information via IPMI in-band commands under the operating system (OS) are highly dependent on the normal operation of the server OS and the OS login permissions of the maintenance personnel. Once the server crashes, the OS is paralyzed, or the maintenance personnel's permissions are restricted, this solution will be completely unusable, causing remote maintenance to come to a standstill.

[0003] The method of restarting the server to access the BIOS Setup and view the BMC information requires manually interrupting the critical business processes running on the server. This is not only cumbersome and time-consuming, but may also lead to business interruption, data loss and other risks, making it extremely unsuitable for production environments.

[0004] Limited by physical hardware, it cannot meet the needs of remote large-scale operation and maintenance: the solution that relies on serial port login to BMC requires operation and maintenance personnel to connect dedicated serial port cables and hardware devices on site, which not only increases the cost of manpower and hardware investment, but is also limited by the site environment and is difficult to adapt to the remote centralized operation and maintenance needs of large-scale data centers, resulting in low operation and maintenance efficiency.

[0005] Dependent on external environment, lacking stability and reliability: Schemes that obtain BMC information through default IP addresses or dynamic allocation via DHCP have significant environmental dependencies. If the default IP is modified or disabled, or if the DHCP service malfunctions or allocation records are untraceable, the scheme will fail directly. Furthermore, such schemes often require manual adjustment of the network environment or unplugging and plugging in network cables, making automated operation impossible and susceptible to network fluctuations, thus compromising the reliability of information acquisition.

[0006] Lack of secure authentication mechanisms poses a risk of information leakage: Most existing solutions do not have identity authentication and data encryption transmission mechanisms. BMC information is easily tampered with, hijacked or stolen during transmission, posing security risks such as unauthorized access and information leakage, and failing to meet the security operation and maintenance needs of data centers.

[0007] In summary, existing BMC information acquisition solutions have significant shortcomings in terms of system environment adaptability, remote operability, large-scale operation and maintenance efficiency, security protection capabilities, and environmental stability. Especially in scenarios involving server downtime, non-restartable conditions, the need for remote large-scale management, or high security requirements, it is difficult to quickly, securely, and reliably acquire BMC information. Therefore, there is an urgent need for a BMC information acquisition solution that does not rely on server OS, physical hardware interfaces, or external network services and possesses a secure authentication mechanism to address the aforementioned technical pain points. Summary of the Invention

[0008] This application provides a method, apparatus, device, and medium for securely acquiring BMC information, aiming to solve technical problems such as complex firmware maintenance, high compatibility risks, and high single-point failure risks in related technologies.

[0009] In a first aspect, embodiments of this application provide a secure method for obtaining BMC information, for use on a client, the method comprising: Based on its own MAC address and real-time time, it generates a one-time public key and a one-time private key for a single communication session; Perform a hash operation on the one-time public key to obtain the one-time public key hash value; The one-time public key hash value is sent to the key management server, so that the key management server signs the one-time public key hash value using a preset private key, and receives the signature result returned by the key management server; The one-time public key and the signature result are encapsulated into a request message and broadcast to the local area network so that the BMC can perform signature verification and generate and return an encrypted response message based on the one-time public key. Listen for and receive encrypted response messages returned by the BMC, and use the one-time private key to decrypt the encrypted response messages, extract and display the BMC information.

[0010] In one embodiment, optionally, the broadcast to the local area network includes: Publish to the local area network via UDP broadcast. UDP (User Datagram Protocol) broadcast includes exact query mode and batch query mode.

[0011] In one embodiment, optionally, when the UDP broadcast method is in exact query mode, the step of encapsulating the request message based on the one-time public key and the signature result includes: Obtain the serial number of the target server; Based on the one-time public key, the signature result, and the serial number of the target server, a request message is encapsulated so that only the target BMC matching the target server responds to the request message; When the UDP broadcast method is in batch query mode, the step of encapsulating the request message according to the one-time public key and the signature result includes: The one-time public key and the signature result are encapsulated into a request message so that all BMCs listening on the preset UDP port in the local area network participate in the response.

[0012] In one embodiment, optionally, the BMC information includes at least one of the following: the BMC's IP address, MAC address, and server serial number.

[0013] In one embodiment, optionally, the method further includes: In response to the end of the single call session, the one-time public key and one-time private key are destroyed.

[0014] Secondly, embodiments of this application provide a secure method for obtaining BMC information, used in a BMC, wherein the BMC is programmed with an unchangeable preset public key, and the method includes: Listen for and parse request messages broadcast by the client, and determine whether a response is required to the request message; In response to the need to respond to the request message, the preset public key is invoked to verify the signature result in the request message; After the verification is passed, a response data packet is generated based on its own IP address, MAC address and server serial number, and the response data packet is encrypted using the one-time public key in the request message to obtain an encrypted response message; The encrypted response message is sent to the client.

[0015] In one embodiment, optionally, listening to and parsing request messages broadcast by the client, and determining whether a response is needed to the request message, includes: It continuously listens for and parses request messages broadcast by clients on a preset UDP port; If the request message carries the serial number of the target server, check whether its own serial number is consistent with the serial number of the target server. If they are consistent, determine that a response to the request message is required. If the request message does not carry the serial number of the target server, it is determined that a response to the request message is required.

[0016] In one embodiment, optionally, the preset public key and the preset private key of the key management server are a pair of asymmetric keys.

[0017] Thirdly, a secure acquisition device for BMC information is provided for a client, the device comprising: The generation module is used to generate a one-time public key and a one-time private key for a single communication session based on its own MAC address and real-time time. The calculation module is used to perform a hash operation on the one-time public key to obtain the hash value of the one-time public key; The first sending module is used to send the one-time public key hash value to the key management server, so that the key management server signs the one-time public key hash value using a preset private key and receives the signature result returned by the key management server; The broadcast module is used to encapsulate a request message into a one-time public key and the signature result, and broadcast it to the local area network, so that after the BMC performs signature verification, it generates and returns an encrypted response message based on the one-time public key; The decryption module is used to listen to and receive the encrypted response message returned by the BMC, and use the one-time private key to decrypt the encrypted response message, extract and display the BMC information.

[0018] Fourthly, a secure acquisition device for BMC information is provided, for use with a BMC, wherein the BMC is programmed with an unchangeable preset public key, and the device includes: The listening module is used to listen for and parse the request messages broadcast by the client, and determine whether a response is needed to the request messages; The verification module is used to verify the signature result in the request message by calling the preset public key when a response is required. The encryption module is used to generate a response data packet based on its own IP address, MAC address and server serial number after the verification is passed, and to encrypt the response data packet using the one-time public key in the request message to obtain an encrypted response message. The second sending module is used to send the encrypted response message to the client.

[0019] Fifthly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method for securely acquiring BMC information.

[0020] In a sixth aspect, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described method for securely acquiring BMC information.

[0021] In the above-described secure acquisition method, apparatus, device, and medium for BMC information, a one-time public key and a one-time private key are generated based on the BMC's MAC address and real-time time for a single communication session. The one-time public key is hashed to obtain a hash value. This hash value is then sent to a key management server, which signs the hash value using a pre-set private key and receives the signature result returned by the key management server. A request message is encapsulated based on the one-time public key and the signature result and broadcast to the local area network. After signature verification by the BMC, an encrypted response message is generated and returned based on the one-time public key. The encrypted response message returned by the BMC is monitored and received, and the one-time private key is used to decrypt the encrypted response message to extract and display the BMC information. The above technical solution generates a one-time public-private key pair for each session by combining the client's MAC address and real-time time. After hashing and KMS (Key Management Service) signing, the key is encapsulated into a request message and broadcast to the local area network. The encrypted response from the BMC is then decrypted using the one-time private key to obtain the BMC information. This completely eliminates dependence on the server operating system, BIOS, and physical hardware interfaces. Even if the server crashes, BMC information can still be obtained normally without interrupting business operations, avoiding the risk of business interruption and data loss. Simultaneously, it achieves remote, contactless operation based on UDP broadcast, supports batch responses from multiple BMCs, and adapts to the remote centralized operation and maintenance needs of large-scale data centers, significantly reducing manpower and hardware costs. Furthermore, it does not rely on default IP configurations or external network services such as DHCP (Dynamic Host Configuration Protocol), and the entire process is automated without manual intervention, improving the stability and reliability of information acquisition. In addition, through hashing, KMS signature verification, and one-time key encrypted transmission, a full-link security protection is built, effectively preventing data tampering, hijacking, and unauthorized access, solving the information leakage risk of existing solutions, and ultimately realizing BMC... Information can be obtained quickly, securely, and reliably in complex scenarios. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A schematic flowchart of a method for securely obtaining BMC information according to an embodiment of this application is shown.

[0024] Figure 2 A schematic flowchart of a method for securely obtaining BMC information according to another embodiment of this application is shown.

[0025] Figure 3 A schematic flowchart of step S201 in a method for securely obtaining BMC information according to another embodiment of this application is shown.

[0026] Figure 4 A schematic diagram illustrating the data interaction process between the client, KMS, and BMC according to an embodiment of this application is shown.

[0027] Figure 5 A block diagram of a secure acquisition device for BMC information according to an embodiment of this application is shown.

[0028] Figure 6 A block diagram of a secure acquisition device for BMC information according to another embodiment of this application is shown.

[0029] Figure 7 A block diagram of a computer device according to one embodiment of this application is shown. Detailed Implementation

[0030] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0031] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0032] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0033] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0034] Please see Figure 1 , Figure 1 A schematic flowchart of a method for securely obtaining BMC information according to an embodiment of this application is shown.

[0035] like Figure 1 As shown, a method for securely obtaining BMC information includes: Step S101: Generate a one-time public key and a one-time private key for a single communication session based on its own MAC address and real-time time.

[0036] A MAC address, or Media Access Control address, is a unique physical identifier for a client's network interface card. It is used to distinguish different client devices and ensure the uniqueness of key generation.

[0037] Real-time time: The current timestamp is accurate to the millisecond level. It serves as a dynamic variable for key generation, ensuring that key pairs generated at different times by the same client are unrelated.

[0038] One-time public and private keys are temporary key pairs generated using asymmetric encryption algorithms (such as ECC elliptic curve cryptography and RSA). They are used only for a single communication session and are destroyed immediately after the session ends. They are the core carrier of the one-time session key mechanism of this invention.

[0039] A single communication session is a complete process from the client initiating a request to obtaining and displaying BMC information and destroying the key; the session is independent and isolated.

[0040] In this step, the client uses its unique MAC address and real-time timestamp to generate a one-time public-private key pair locally, without relying on external devices or services. The one-time public key is used for BMC encryption of response data, while the one-time private key is stored on the client for decryption. The key pair is only bound to this session, completely eliminating the risk of reuse. This design is the core embodiment of the one-time session key mechanism of this invention, generating a different temporary key for each communication, laying the foundation for forward confidentiality.

[0041] The above steps, by combining the MAC address with the real-time time, ensure the uniqueness and independence of the key pair from the source, achieving forward confidentiality. Even if a key is leaked during a single session, it will not affect the security of historical or future communications; locally generated keys avoid the risk of transmission leakage, and asymmetric encryption algorithms ensure encryption strength, significantly enhancing communication security.

[0042] Step S102: Perform a hash operation on the one-time public key to obtain the hash value of the one-time public key.

[0043] Hash operations are one-way irreversible operations performed using cryptographic hash algorithms (such as SHA-256 and SHA-384). Even a small change in the input data can cause a drastic change in the output hash value.

[0044] A one-time public key hash is a fixed-length, compact data (e.g., 32 bytes for SHA-256) obtained by hashing a one-time public key, used for subsequent KMS signing and BMC verification.

[0045] In this step, the one-time public key is typically a long-byte asymmetric key (e.g., an RSA 2048-bit public key is approximately 256 bytes). Hash operations can compress the data volume and reduce transmission and computational overhead. The irreversibility of the hash value prevents attackers from reverse-engineering the original public key, and the avalanche effect can quickly identify whether the public key transmission has been tampered with.

[0046] The above steps significantly reduce the complexity of KMS signatures and the bandwidth consumption of data transmission, improving response efficiency; public key integrity verification is achieved through hash value characteristics, providing a reliable foundation for subsequent KMS signatures and BMC verification, and avoiding the risk of identity forgery.

[0047] Step S103: Send the one-time public key hash value to the key management server so that the key management server can sign the one-time public key hash value using a preset private key and receive the signature result returned by the key management server.

[0048] The Key Management Server (KMS) is an offline-deployed core key management device. It has a built-in pre-set private key that is paired with the BMC's pre-set public key and is responsible for digitally signing the one-time public key hash value.

[0049] The pre-set private key is an asymmetric key paired with the BMC pre-set public key. It is stored only in KMS and offline, and is used to generate authoritative digital signatures.

[0050] The signature result is a data packet containing signature information and a timestamp, generated by KMS after encrypting the hash value with a preset private key. It is used by BMC to verify the legitimacy of the client's identity.

[0051] In this step, the client sends the hash value to the KMS via a secure link (such as HTTPS). The KMS then uses a pre-set private key to digitally sign the hash and returns the result. This process is the core of the minimalist key management machine based on a pre-set public key in this invention. The BMC only needs to store the pre-set public key and does not need to store or update the private key, significantly reducing key maintenance costs.

[0052] In the above steps, the identity trust issue between BMC and the client is resolved by KMS third-party authoritative signature; KMS offline storage of pre-set private keys improves key management security and avoids the risk of global leakage; the timeliness of the signature result prevents reuse, and together with BMC's pre-set public key verification, a reliable identity authentication system is built; KMS only requires a short signature once, and subsequent client upgrades, revocations, or expansions do not require modification of BMC firmware, greatly simplifying the key management and system maintenance process.

[0053] Step S104: Encapsulate the one-time public key and the signature result into a request message and broadcast it to the local area network so that the BMC can perform signature verification and then generate and return an encrypted response message based on the one-time public key.

[0054] The request message is a structured data packaged in a preset format, containing a one-time public key, a signature result (optionally including the server SN), and other parts such as protocol identifier, message length, and data segments.

[0055] In the above steps, the client encapsulates the one-time public key and the signature result into a request message and broadcasts it to the local area network. This process requires no complex handshake or configuration; a single request initiates identity verification and data transmission. Upon receiving the request, the BMC verifies the signature using a pre-set public key; if successful, it encrypts the response using the one-time public key. The precise query mode carries the serial number (SN) and only matches BMC responses, while the batch query mode does not carry the SN, and all BMCs listening on preset ports respond, adapting to different operational scenarios.

[0056] In this way, structured encapsulation improves message parsing efficiency and accuracy, reducing the processing pressure on the BMC; LAN broadcast enables seamless BMC discovery without relying on default IP or DHCP services, solving the problem of locating unknown BMC addresses; signature and public key binding transmission ensures seamless authentication and data encryption, building a complete security link; precise and batch modes support clients to display multiple BMC information at once, significantly improving the operational efficiency of large-scale data centers.

[0057] Step S105: Listen to and receive the encrypted response message returned by the BMC, and use the one-time private key to decrypt the encrypted response message, extract and display the BMC information.

[0058] An encrypted response message is a data packet containing its own information, generated by BMC using a one-time public key. It can only be decrypted using the corresponding one-time private key.

[0059] BMC information consists of core data related to the BMC management network port and server, including but not limited to the BMC's IP address, MAC address, and server SN, and can be expanded to include fields such as BMC firmware version and device health status.

[0060] In this step, the client listens on a preset UDP port to receive encrypted response messages, decrypts them using a local one-time private key, and restores and displays the BMC information. The extraction and display of BMC information does not rely on the server OS or physical hardware interface, adapting to extreme scenarios such as server downtime, and supports field expansion to meet diverse operational and maintenance needs. This invention does not require pre-installed certificates or keys on the client; any new client can immediately access and obtain a legitimate identity, demonstrating excellent compatibility.

[0061] In this way, local decryption with a one-time private key ensures that BMC information can only be deciphered by the client, preventing tampering, hijacking, or theft during transmission and ensuring information confidentiality and integrity. It does not rely on physical / system resources such as server OS, BIOS, or serial ports, supporting scenarios where servers are down or cannot be restarted, avoiding the risk of business interruption. BMC information supports extended queries, providing richer device data to meet diverse data center operation and maintenance needs. Clients do not need to pre-install certificates or keys, new devices can be connected immediately, adapting to different operation and maintenance environments for rapid deployment with good compatibility.

[0062] The above technical solution generates a one-time public-private key pair for each session by combining the client's MAC address and real-time time. After hashing and KMS signing, the key is encapsulated into a request message and broadcast to the local area network. The encrypted response from the BMC is then decrypted using the one-time private key to obtain the BMC information. This completely eliminates dependence on the server's operating system, BIOS, and physical hardware interfaces. Even if the server crashes, BMC information can still be obtained normally without interrupting business operations, avoiding the risk of business interruption and data loss. At the same time, it enables remote non-contact operation based on UDP broadcast, supports batch responses from multiple BMCs, and adapts to the needs of remote centralized operation and maintenance of large-scale data centers, significantly reducing manpower and hardware costs. It does not rely on default IP configurations or external network services such as DHCP, and the entire process is automated without manual intervention, improving the stability and reliability of information acquisition. In addition, by constructing end-to-end security protection through hashing, KMS signature verification, and one-time key encrypted transmission, it effectively prevents data tampering, hijacking, and unauthorized access, solving the information leakage risk of existing solutions. Ultimately, it enables fast, secure, and reliable acquisition of BMC information in complex scenarios.

[0063] In one embodiment, optionally, the broadcast to the local area network includes: Broadcast to the local area network via UDP broadcast, which includes both exact query mode and batch query mode.

[0064] UDP broadcast is a connectionless data broadcast mechanism based on the UDP protocol. It features lightweight and low latency characteristics, making it suitable for the rapid discovery needs of BMC.

[0065] The exact query mode is a query mode in which the request message carries the target server's SN, and only the BMC responds with a SN that matches that SN.

[0066] Batch query mode is a query mode in which the request message does not carry the server SN, and all BMCs listening on the preset UDP port in the local area network respond.

[0067] In the above solution, the client selects UDP broadcast to send request messages, and can flexibly switch between precise or batch query modes according to operational needs. The precise mode is for a single target server BMC, while the batch mode is for multiple BMCs within a local area network. Both modes require no manual intervention in the network environment or hardware status, achieving automated operation.

[0068] In this way, the lightweight nature of the UDP protocol improves message transmission efficiency and shortens information retrieval response time; two query modes enhance the flexibility of the solution, supporting both precise location of a single BMC and batch discovery of multiple BMCs, adapting to different scale operation and maintenance scenarios; no manual adjustment of the network or hardware is required, reducing operational complexity and labor costs, and improving operation and maintenance efficiency.

[0069] In one embodiment, optionally, when the UDP broadcast method is in exact query mode, the step of encapsulating the request message based on the one-time public key and the signature result includes: Obtain the serial number of the target server; based on the one-time public key, the signature result, and the serial number of the target server, encapsulate it into a request message so that only the target BMC matching the target server responds to the request message; The target server's serial number (SN) is a unique hardware identifier configured at the factory and is used to accurately associate the corresponding BMC device.

[0070] The target BMC is the BMC device that matches the SN in the request message, and only this device will respond to the request.

[0071] In precise query mode, the client first obtains the target server SN (Signature) input by the user or a preset value, encapsulates it as a new field in the request message, and arranges them in the order of "Protocol Identifier → Message Length → One-Time Public Key → Signature Result → SN". After receiving the message, the BMC verifies whether its stored SN matches the SN in the message. If they match, the subsequent verification and response process is executed.

[0072] The above technical solution enables accurate querying of a single target BMC, avoids redundant responses from irrelevant BMCs, and improves the targeting and efficiency of information acquisition; it also reduces invalid data transmission within the local area network and lowers network bandwidth usage, making it particularly suitable for scenarios involving rapid location of a single server BMC in large-scale data centers.

[0073] When the UDP broadcast method is in batch query mode, the step of encapsulating the request message according to the one-time public key and the signature result includes: The one-time public key and the signature result are encapsulated into a request message so that all BMCs listening on the preset UDP port in the local area network participate in the response.

[0074] The default UDP port is a fixed communication port pre-agreed between the client and the BMC, used by the BMC to accurately listen for and receive request messages.

[0075] In batch query mode, the request message only encapsulates the one-time public key and signature result, without adding the SN field. The format is "protocol identifier → message length → one-time public key → signature result". All BMCs on the local area network that have UDP listening enabled and whose ports match will perform signature verification upon receiving the message. If successful, an encrypted response will be returned.

[0076] This enables batch discovery and information retrieval of multiple BMCs within a local area network without the need to initiate queries for each machine, significantly improving the operational efficiency of large-scale data centers; it also eliminates the need for users to remember or input multiple server serial numbers, reducing operational complexity and making it suitable for scenarios involving centralized statistics and management of batch server BMC information.

[0077] In one embodiment, optionally, the BMC information includes at least one of the following: the BMC's IP address, MAC address, and server serial number.

[0078] The BMC's IP address is the network address of the BMC management port and is the core entry point for remotely logging into the BMC to perform operation and maintenance.

[0079] The MAC address of the BMC is the physical address of the BMC management port, which can be used to assist in network positioning and device identification.

[0080] The server's serial number (SN) is a unique hardware identifier used to associate server hardware information with the BMC device.

[0081] This information is all built-in basic management data in the BMC, requiring no additional collection or calculation; the BMC can quickly assemble it into a response data packet. The information can be extended with fields such as firmware version and device health status to meet diverse operational and maintenance needs.

[0082] In this way, it provides core operation and maintenance information such as remote login, device location, and hardware association. Users can directly use this information for subsequent operations without the need for secondary queries. It also supports field expansion to enrich information dimensions, adapt to diverse operation and maintenance scenarios in data centers, and improve the practicality of the solution.

[0083] In one embodiment, optionally, the method further includes: In response to the end of the single call session, the one-time public key and one-time private key are destroyed.

[0084] Key destruction is the process of completely erasing the one-time public and private keys stored locally on the client after the session ends, through irreversible methods such as overwriting the key storage memory or deleting the key file.

[0085] When the client completes the BMC information display, detects a communication link disconnection, or the user actively terminates the operation, it determines that the session has ended and immediately performs key destruction. The destruction operation is irreversible, ensuring that the key is no longer reused, which is a key step in achieving forward confidentiality.

[0086] This ensures that keys are used exclusively for a single session, strengthening forward confidentiality. Even if the key for this session is accidentally leaked, it will not affect the security of historical or future sessions; complete destruction eliminates the risk of key reuse or leakage, further enhancing communication security and meeting the high-security operation and maintenance requirements of data centers.

[0087] like Figure 2 As shown, in a second aspect, embodiments of this application provide a secure method for obtaining BMC information, used in a BMC, wherein the BMC has an unchangeable preset public key programmed into it, the method comprising: Step S201: Listen to and parse the request message broadcast by the client, and determine whether a response is required to the request message.

[0088] The request message is a structured data packaged by the client, containing a one-time public key and a signature result (optionally including the target server's SN), used to initiate a BMC identity authentication and information retrieval request.

[0089] Parsing is the process of parsing the received request message to extract key information such as protocol identifier, message length, and core data fields.

[0090] Response determination is the decision-making process that determines whether data needs to be returned to the client based on the content of the request message (such as whether it carries a serial number and whether the serial number matches).

[0091] The BMC continuously listens for broadcast messages within the local area network on a preset UDP port. Upon receiving a request message, it first performs format verification (checking if the protocol identifier and message length match preset rules), and then parses the core fields. It then determines whether it is the target responding device by checking if the message carries the target server's serial number (SN). If the SN is present, consistency is verified; otherwise, a response is directly required, ensuring the accuracy and comprehensiveness of the response. This process is the core implementation of the zero-handshake UDP broadcast mechanism of this invention on the BMC side, eliminating the need for complex connection establishment and quickly completing request reception and initial screening.

[0092] In this solution, a pre-defined UDP port listener ensures that the BMC accurately captures target requests and avoids confusion with other network data; the structured parsing and response judgment logic is simple and efficient, reducing the processing pressure on the BMC; the precise filtering based on the SN avoids irrelevant responses, reduces local area network bandwidth consumption, and supports batch response scenarios to adapt to different operation and maintenance needs; no TCP connection needs to be established, which fits the zero-handshake design, improves request processing efficiency, and ensures rapid response to client needs.

[0093] Step S202: In response to the need to respond to the request message, the preset public key is invoked to verify the signature result in the request message.

[0094] The pre-set public key is an asymmetric key that is burned into the BMC at the factory and cannot be changed. It is paired with the pre-set private key of the Key Management Server (KMS) and used to verify the legality of the client's signature result.

[0095] Signature verification is the process of using a pre-set public key to decrypt and verify the signature result in the request message, confirming the client's identity and the integrity of the request data.

[0096] After determining that a response is required, the BMC retrieves the pre-set public key from local storage and performs a verification operation on the signature result in the request message. The core of the verification is to verify whether the signature was generated by the KMS pre-set private key paired with the pre-set public key, and whether the corresponding one-time public key hash value has been tampered with. If the verification fails, the BMC directly discards the request message without any response; if the verification passes, it proceeds to the subsequent data assembly and encryption process. This is the key verification step of the minimalist key management mechanism based on the pre-set public key in this invention. The BMC only needs to store the pre-set public key and does not need to maintain a complex key system.

[0097] By pairing and verifying a pre-configured public key with a pre-configured private key in KMS, the client's identity is ensured to be legitimate, preventing malicious devices from forging requests. The verification process relies solely on the locally configured public key, eliminating the need for online queries or additional hardware support, thus improving verification efficiency. The design of not responding to verification failures avoids exposing BMC information and enhances system security. The BMC does not need to store or update the private key, significantly reducing key maintenance costs. Subsequent client upgrades and revocations do not require modifications to the BMC firmware, ensuring strong compatibility.

[0098] Step S203: After the verification is passed, a response data packet is generated based on its own IP address, MAC address and server serial number, and the response data packet is encrypted using the one-time public key in the request message to obtain an encrypted response message.

[0099] The response data packet is a plaintext data set assembled by the BMC that contains its own core management information; it is the target data that the client needs to obtain.

[0100] An encrypted response message is ciphertext data generated by encrypting the response data packet using a one-time public key sent by the client. It can only be decrypted using the corresponding one-time private key.

[0101] Own IP address / MAC address: The network address and physical address of the BMC management port, which is the core entry point information for remote operation and maintenance by the client.

[0102] Server Serial Number (SN): A unique hardware identifier for the server to which the BMC belongs, used to associate device information with clients.

[0103] After signature verification, the BMC automatically extracts its own IP address, MAC address, and server serial number (SN), assembling them into a structured response data packet. If additional operational information (such as BMC firmware version or device health status) is needed, fields can be added directly to the data packet, maintaining a lightweight protocol while increasing information richness. Subsequently, the BMC uses the one-time public key from the request message and employs the corresponding asymmetric encryption algorithm to encrypt the response data packet, generating an encrypted response message to ensure the security of data transmission.

[0104] In the above technical solution, the response data packet is automatically assembled without manual intervention, improving data generation efficiency; one-time public key encryption ensures that the response data can only be decrypted by the client, preventing tampering, hijacking or theft during transmission and ensuring information confidentiality and integrity; it supports the expansion of additional operation and maintenance fields to meet the diverse needs of data centers and improve the practicality of the solution; the encryption process does not rely on external encryption devices, but is completed only through local calculation by BMC, adapting to scenarios without system dependencies such as server downtime, ensuring the stability of the solution.

[0105] Step S204: Send the encrypted response message to the client.

[0106] After generating the encrypted response message, the BMC sends it to the requesting client via UDP unicast, based on the client source address carried in the request message. Unicast transmission prevents the response message from being captured by other devices on the local network, further enhancing transmission security. The entire process requires no additional request from the client, aligning with zero-handshake design and achieving efficient interaction of one request → one response.

[0107] In the above technical solutions, UDP unicast directed transmission ensures that response messages are accurately delivered to the client, avoiding data leakage or interference from irrelevant devices; there is no additional handshake process, shortening the response transmission time and improving the overall interaction efficiency; the core design of adapting to zero-handshake UDP broadcast forms a closed loop with the client process, realizing the rapid and secure delivery of BMC information; the unicast method consumes low network bandwidth, supports multiple BMCs to respond simultaneously, and is suitable for large-scale operation and maintenance needs in batch query scenarios.

[0108] like Figure 3 As shown, in one embodiment, optionally, step S201 includes: Step S301: Continuously listen for and parse request messages broadcast by the client on the preset UDP port.

[0109] The default UDP port is a fixed communication port pre-agreed between the BMC and the client, used exclusively to receive client request messages and avoid port conflicts.

[0110] Step S302: If the request message carries the serial number of the target server, check whether the serial number of the user is consistent with the serial number of the target server. If they are consistent, determine that a response to the request message is required.

[0111] The target server's serial number is a unique identifier for the server to be queried, specified by the client, and is used to accurately locate the target BMC.

[0112] Its own serial number is the SN of the server to which the BMC belongs, and is used to verify consistency with the SN of the request message.

[0113] Step S303: If the request message does not carry the sequence number of the target server, it is determined that a response to the request message is required.

[0114] The BMC continuously listens on a preset UDP port, capturing broadcast requests from clients within the local area network in real time. After parsing the packets, it first determines whether the target server's serial number (SN) is included: if so, it compares the packet's SN with its own stored server SN; if they match, a response is required; otherwise, all BMCs listening on that port are required to respond, enabling batch queries. This design supports both precise and batch query modes to adapt to different operational scenarios.

[0115] In the above technical solution, the preset UDP port ensures the exclusivity of request reception and improves message capture efficiency; SN consistency verification enables accurate response from a single BMC, avoiding redundant data transmission; batch response without SN supports simultaneous querying by multiple devices, greatly improving the operation and maintenance efficiency of large-scale data centers; the two modes automatically adapt to each other, eliminating the need for manual configuration of BMC response rules, reducing operational complexity and improving the flexibility of the solution.

[0116] In one embodiment, optionally, the preset public key and the preset private key of the key management server are a pair of asymmetric keys.

[0117] An asymmetric key is a key pair consisting of a public key and a private key. The public key can be transmitted publicly, while the private key must be stored confidentially. The encryption and decryption process is irreversible (public key encryption requires private key decryption, and private key signing requires public key verification).

[0118] The pre-set public key and the pre-set private key of KMS are generated based on the same asymmetric encryption algorithm (such as ECC or RSA), forming a unique pair. The pre-set public key cannot be changed after being burned into the BMC, while the pre-set private key is stored offline in the KMS and is only used for signing the client's one-time public key hash value. This key pairing design is the foundation of the minimalist key management mechanism based on the pre-set public key in this invention, ensuring the authority and security of identity authentication. The data interaction process between the client, KMS, and BMC is as follows: Figure 4 As shown.

[0119] In this way, the pairing characteristic of asymmetric keys ensures the uniqueness of signatures and verifications, preventing forged signatures from passing verification; pre-installed private keys are stored offline to avoid the risk of leakage and improve the security of key management; BMC only stores public keys and does not need to be involved in private key-related operations, reducing the complexity and security risks of BMC firmware; the asymmetric encryption algorithm has high encryption strength, ensuring the security of data transmission and identity authentication, and meeting the high security requirements of data centers.

[0120] The above technical solution of the present invention will be described in detail below with reference to a specific embodiment.

[0121] A large data center deploys 100 identical servers (server SN range: SN2025001-SN2025100). Each server has a built-in BMC (model: IPMI 2.0 compatible version), and a pre-programmed public key (public key algorithm: ECC P-256, key identifier: PK-BMC-2025) is pre-programmed at the factory. Data center operations personnel need to remotely obtain the BMC IP addresses and firmware version information of 5 target servers (SN2025003, SN2025015, SN2025047, SN2025072, SN2025096). Some servers are offline due to hardware failure and cannot obtain information through the OS or BIOS.

[0122] The Key Management Server (KMS) is deployed in the offline area of ​​the data center intranet, storing a pre-configured private key (SK-KMS-2025) paired with the BMC's pre-configured public key, and supporting ECC signature calculations on hash values ​​submitted by clients. The client is a laptop used by operations and maintenance personnel (MAC address: 00:1B:44:11:3A:B7), with self-developed operations and maintenance tools installed (supporting UDP broadcast / unicast, ECC encryption, and SHA-256 hash calculations).

[0123] The core parameter configurations are shown in Table 1.

[0124] Table 1

[0125] (a) Client operation process 1) One-time key pair generation: The operations and maintenance personnel open the client-side operations and maintenance tool, select "Batch Query Mode" (requires simultaneous acquisition of BMC information for 5 servers), and the tool automatically obtains the client's MAC address (00:1B:44:11:3A:B7) and real-time timestamp (2025-06-10 14:32:45.789), and locally generates a one-time public-private key pair using the ECC P-256 algorithm. One-time public key (PK-Temp): 0x046A1F... (64 bytes, anonymized display) One-time private key (SK-Temp): 0x7C3D9E... (32 bytes, stored only in client memory) After the key pair is generated, the tool automatically marks it as "for single session use" and will automatically destroy it after the session ends.

[0126] 2) One-time public key hash operation The client performs a SHA-256 hash operation on the generated one-time public key (PK-Temp) to obtain a fixed-length (32-byte) hash value: Hash value (Hash-PK): 0x8F2E4D... (Anonymized display) The hash operation is irreversible, and if PK-Temp is tampered with, Hash-PK will change drastically, ensuring the integrity of the public key.

[0127] 3) KMS Signature Request and Receive The client sends the Hash-PK to KMS via an HTTPS secure link, requesting a signature. Upon receiving the request, KMS uses a pre-set private key (SK-KMS-2025) to perform an ECC-SHA256 signature operation on the Hash-PK, generating a signature result (Sign-Result, 72 bytes), which is then returned to the client via HTTPS. The client, upon receiving the signature result, verifies its format (length, signature algorithm identifier) ​​and proceeds to the next step if everything is correct.

[0128] 4) Request message encapsulation and UDP broadcast The client encapsulates the request message according to a preset format, as shown in Table 2.

[0129] Table 2

[0130] 5) Encrypted response reception and decryption The client continuously listens on port 5000, receiving encrypted response messages from five target server BMCs within one second (one message per BMC, each message approximately 128 bytes long). The client parses each message in the order of "protocol identifier → message length → ciphertext data". After confirming the format is valid, the client calls the locally stored SK-Temp to decrypt the ciphertext data and reconstruct the response data packet.

[0131] 6) BMC Information Display and Key Destruction The client extracts the core information from the decrypted response data packet, organizes it, and displays it through the tool interface as shown in Table 3.

[0132] Table 3

[0133] After the information is displayed, the client automatically performs a key destruction operation, which completely clears the key data by overwriting the storage areas of SK-Temp and PK-Temp in memory, ensuring that it cannot be reused.

[0134] BMC Side Operation Procedure 1) Request message listening and parsing All server BMCs within the data center continuously listen on the preset UDP port 5000. Upon receiving a request message broadcast by a client, they first verify the protocol identifier (whether it is 0x5B5D) and the message length (whether it matches the actual data length). If the verification is successful, they parse the core fields of the message (one-time public key, signature result). Since the request message does not carry the server SN, all BMCs determine that a response is required to this request.

[0135] 2) Signature result verification Each BMC calls its locally pre-configured public key (PK-BMC-2025) to verify the Sign-Result in the request message: it decrypts the Sign-Result using the ECC algorithm to obtain the decrypted hash value, and compares it with the SHA-256 hash value of the one-time public key (PK-Temp) in the request message. If they match, the verification passes; otherwise, the message is discarded without a response. In this implementation, the verification passed on all 5 target server BMCs. The remaining 95 BMCs, which were not specified (no SN filtering), also passed the verification and generated response messages (operations personnel can later filter for the required information).

[0136] 3) Response packet assembly and encryption After successful verification, the BMC automatically extracts its core information: BMC IP, BMC MAC, server SN, and extended fields (firmware version, health status), and assembles them into a JSON format response data packet (plaintext example): json { "server_sn": "SN2025003", "bmc_ip": "192.168.1.103", "bmc_mac": "00:22:44:66:88:AA", "firmware_version": "V2.5.1", "health_status": "normal" } Subsequently, the BMC uses the PK-Temp in the request message to perform ECC P-256 encryption on the response data packet, generating an encrypted response message (ciphertext data + protocol identifier + message length) to ensure secure data transmission.

[0137] 4) Unicast transmission of encrypted response messages The BMC extracts the client's source address (192.168.1.200:5000) from the request message and forwards the encrypted response message to that address via UDP unicast. Unicast transmission prevents the response message from being captured by other devices, ensuring that the data can only be received by the client.

[0138] Scenario adaptability: Two of the five target servers were down (OS paralysis), but the BMC still responded normally and successfully obtained BMC information, verifying the advantages of the solution that "does not require system dependencies and supports downtime scenarios".

[0139] Security: Packet capture analysis using Wireshark shows that the encrypted response message is ciphertext and cannot be directly deciphered; after the key is destroyed, no key data remains in the client's memory, and the forward secrecy feature is effective.

[0140] Efficiency: The entire process from initiating a request to displaying information takes 8 seconds, including 3 seconds for key generation, signature request, and broadcast transmission, and 5 seconds for response reception and decryption. This is 75 times more efficient than traditional serial port login (which takes 10 minutes per unit), and has significant advantages in batch querying.

[0141] Scalability: BMC successfully returned the extended firmware version and health status fields, verifying the solution's "strong scalability" and meeting diverse operation and maintenance needs.

[0142] Compatibility: The client does not have any pre-installed certificates or keys and can complete the operation by directly connecting to the data center network, which verifies "good compatibility" and facilitates rapid deployment.

[0143] like Figure 5 As shown, in a third aspect, embodiments of this application provide a secure acquisition device 50 for BMC information, comprising: The generation module 51 is used to generate a one-time public key and a one-time private key for a single communication session based on its own MAC address and real-time time. The calculation module 52 is used to perform a hash operation on the one-time public key to obtain the hash value of the one-time public key; The first sending module 53 is used to send the one-time public key hash value to the key management server, so that the key management server signs the one-time public key hash value using a preset private key and receives the signature result returned by the key management server; Broadcast module 54 is used to encapsulate a request message into a one-time public key and the signature result, and broadcast it to the local area network, so that after BMC performs signature verification, it generates and returns an encrypted response message based on the one-time public key; The decryption module 55 is used to listen to and receive the encrypted response message returned by the BMC, and use the one-time private key to decrypt the encrypted response message, extract and display the BMC information.

[0144] In one embodiment, optionally, the broadcast module is used for: Broadcast to the local area network via UDP broadcast, which includes both exact query mode and batch query mode.

[0145] In one embodiment, optionally, when the UDP broadcast method is in exact query mode, the broadcast module is specifically used for: Obtain the serial number of the target server; Based on the one-time public key, the signature result, and the serial number of the target server, a request message is encapsulated so that only the target BMC matching the target server responds to the request message; When the UDP broadcast method is in batch query mode, the broadcast module is specifically used for: The one-time public key and the signature result are encapsulated into a request message so that all BMCs listening on the preset UDP port in the local area network participate in the response.

[0146] In one embodiment, optionally, the BMC information includes at least one of the following: the BMC's IP address, MAC address, and server serial number.

[0147] In one embodiment, optionally, the apparatus further includes: The destruction module is used to destroy the one-time public key and one-time private key in response to the end of the single call session.

[0148] like Figure 6 As shown, in a fourth aspect, a secure acquisition device 60 for BMC information is provided, for a BMC, wherein the BMC has an unchangeable preset public key burned into it, and the device includes: The listening module 61 is used to listen to and parse the request messages broadcast by the client, and determine whether a response is needed to the request messages; Verification module 62 is used to verify the signature result in the request message by calling the preset public key in response to the need to respond to the request message; The encryption module 63 is used to generate a response data packet based on its own IP address, MAC address and server serial number after the verification is passed, and to encrypt the response data packet using the one-time public key in the request message to obtain an encrypted response message. The second sending module 64 is used to send the encrypted response message to the client.

[0149] In one embodiment, optionally, the listening module 61 includes: The parsing unit is used to continuously listen for and parse request messages broadcast by clients on a preset UDP port; The first determining unit is configured to check whether its own serial number is consistent with the serial number of the target server if the request message carries the serial number of the target server; if they are consistent, it determines that a response to the request message is required. The second determining unit is used to determine that a response to the request message is required if the request message does not carry the serial number of the target server.

[0150] In one embodiment, optionally, the preset public key and the preset private key of the key management server are a pair of asymmetric keys.

[0151] Fifthly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method for securely acquiring BMC information.

[0152] In a sixth aspect, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described method for securely acquiring BMC information.

[0153] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the BMC information secure acquisition device and each module described above can be referred to the corresponding process in the aforementioned BMC information secure acquisition method embodiment, and will not be repeated here.

[0154] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the model training device and each module described above can be referred to the corresponding process in the aforementioned embodiment of the secure acquisition method for BMC information, and will not be repeated here.

[0155] The aforementioned secure acquisition device for BMC information can be implemented as a computer program, which can, for example... Figure 7 It runs on the computer device shown.

[0156] Figure 7 A block diagram of a computer device according to one embodiment of this application is shown.

[0157] See Figure 7 The computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include storage media and internal memory.

[0158] The storage medium may store an operating system and a computer program. The computer program includes program instructions that, when executed, cause the processor to perform any of the secure acquisition methods for BMC information from multi-source data provided in the embodiments of this application.

[0159] The processor provides computing and control capabilities, supporting the operation of the entire computer device.

[0160] The internal memory provides an environment for the execution of a computer program stored in the storage medium. When executed by a processor, this computer program enables the processor to perform any method for securely acquiring BMC information from multiple sources. The storage medium can be non-volatile or volatile.

[0161] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0162] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0163] In addition, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions for performing the steps of the method in the first aspect embodiment.

[0164] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or electronic device described above can be referred to the relevant descriptions in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0165] It should be understood that the term "and / or" used in this article is merely a description of 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. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0166] It should be understood that although the terms "first," "second," etc., may be used to describe the setting units in the embodiments of this application, these setting units should not be limited to these terms. These terms are only used to distinguish the setting units from each other. For example, without departing from the scope of the embodiments of this application, the first setting unit may also be referred to as the second setting unit, and similarly, the second setting unit may also be referred to as the first setting unit.

[0167] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0168] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0169] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0170] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0171] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for securely obtaining BMC information, characterized in that, The method for a client comprises: According to the MAC address and real-time time, a one-time public key and a one-time private key for a single communication session are generated; Hash operation is performed on the one-time public key to obtain a one-time public key hash value; The one-time public key hash value is sent to a key management server, so that the key management server signs the one-time public key hash value by using a preset private key, and a signature result returned by the key management server is received; A request message is encapsulated according to the one-time public key and the signature result, and is broadcast to a local area network, so that a BMC performs signature verification, generates an encrypted response message according to the one-time public key, and returns the encrypted response message; The encrypted response message returned by the BMC is listened to and received, and the encrypted response message is decrypted by using the one-time private key, and BMC information is extracted and displayed.

2. The method of claim 1, wherein, The broadcast to the local area network comprises: Broadcasting to the local area network by a UDP broadcast mode, wherein the UDP broadcast mode comprises a precise query mode and a batch query mode.

3. The method of claim 2, wherein When the UDP broadcast mode is the precise query mode, the encapsulation of the request message according to the one-time public key and the signature result comprises: The sequence number of a target server is obtained; The request message is encapsulated according to the one-time public key, the signature result and the sequence number of the target server, so that only the target server matching the target BMC responds to the request message; When the UDP broadcast mode is the batch query mode, the encapsulation of the request message according to the one-time public key and the signature result comprises: The request message is encapsulated according to the one-time public key and the signature result, so that all the BMCs in the local area network listening to a preset UDP port participate in responding.

4. The method of claim 1, wherein The BMC information comprises at least one of the following: the IP address, the MAC address of the BMC and the sequence number of the server.

5. The method of claim 1, wherein The method further comprises: In response to the end of the single communication session, the one-time public key and the one-time private key are destroyed.

6. A method for securely obtaining BMC information, characterized by, The method for a BMC, which is burned with an unchangeable preset public key, comprises: The request message broadcast by the client is listened to and parsed, and it is determined whether the request message needs to be responded to; In response to the request message needing to be responded to, the preset public key is called to verify the signature result in the request message; After the verification passes, a response data packet is generated according to the IP address, the MAC address and the sequence number of the server, and the response data packet is encrypted by using the one-time public key in the request message to obtain an encrypted response message; The encrypted response message is sent to the client.

7. The method of claim 6, wherein, The request message broadcast by the client is listened to and parsed, and it is determined whether the request message needs to be responded to, comprising: The request message broadcast by the client is continuously listened to and parsed at a preset UDP port; If the sequence number of the target server is carried in the request message, it is verified whether the sequence number of the server is consistent with the sequence number of the target server, and if so, it is determined that the request message needs to be responded to; If the sequence number of the target server is not carried in the request message, it is determined that the request message needs to be responded to.

8. The method of claim 6, wherein, The preset public key and a preset private key of the key management server form a pair of asymmetric keys.

9. A device for securely obtaining BMC information, characterized by, For a client, the apparatus comprises: A generating module configured to generate a one-time public key and a one-time private key for a single communication session according to a MAC address and a real-time time of the client; An operating module configured to perform a hash operation on the one-time public key to obtain a one-time public key hash value; A first sending module configured to send the one-time public key hash value to a key management server, so that the key management server signs the one-time public key hash value by using a preset private key, and receives a signature result returned by the key management server; A broadcasting module configured to encapsulate the one-time public key and the signature result into a request message, and broadcast the request message to a local area network, so that a BMC performs signature verification, generates an encrypted response message according to the one-time public key, and returns the encrypted response message; A decrypting module configured to listen to and receive the encrypted response message returned by the BMC, decrypt the encrypted response message by using the one-time private key, and extract and display BMC information.

10. A device for securely obtaining BMC information, characterized by, For a BMC, the BMC is burned with an unchangeable preset public key, and the apparatus comprises: A listening module configured to listen to and analyze a request message broadcast by a client, and determine whether the request message needs to be responded to; A verifying module configured to, in response to the request message needing to be responded to, call the preset public key to verify a signature result in the request message; An encrypting module configured to, after the verification passes, generate a response data packet according to an IP address, a MAC address of the BMC, and a serial number of a server, encrypt the response data packet by using a one-time public key in the request message to obtain an encrypted response message; A second sending module configured to send the encrypted response message to the client.

11. A computer device, comprising: comprise: at least one processor; and a memory connected with the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, the instructions being configured to perform the method for securely obtaining BMC information according to any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that, The computer executable instructions are used to perform the method for securely obtaining BMC information according to any one of claims 1 to 8.

Images