Server security management method, expansion card and server security management system

Abstract

This application discloses a server security management method, an expansion card, and a server security management system, relating to the field of server security management technology. The method includes: obtaining the server product serial number and license file; generating a symmetric decryption key based on the version information in the server product serial number and license file; decrypting the encrypted data in the license file using the symmetric decryption key to obtain authorized plaintext data; verifying the digital signature of the license file based on the verification public key in the expansion card; if the verification passes, determining whether the authorized identity information in the authorized plaintext data matches the server's hardware identity information; if they match, generating a function enable signal based on the function authorization information in the authorized plaintext data and outputting it to the baseboard management controller to trigger the activation of the corresponding server function. This solves the problem of balancing security and flexibility in server function license management in related technologies, improving the reliability of server function management.

Description

Technical Field

[0001] This application relates to the field of server security management technology, and in particular to a server security management method, an expansion card, and a server security management system. Background Technology

[0002] In current server functional safety management, particularly in licensing schemes based on Baseboard Management Controllers (BMCs), license verification and functional control are typically implemented in software. This approach directly stores the license verification logic, decryption keys, and verification public keys in the BMC's general-purpose storage medium, with the BMC's processor performing the corresponding decryption, signature verification, and permission checks. However, this method exposes the core verification process entirely to the server operating system's software environment, making it vulnerable to malicious attacks, debugging, or tampering. It also makes it difficult to prevent licenses from being illegally copied or reused across multiple devices, thus fundamentally failing to build a truly hardware-bound trusted licensing system. Furthermore, complex asymmetric cryptographic operations consume the BMC's limited computing resources, potentially affecting the real-time performance and reliability of its core out-of-band management functions. Additionally, purely software-implemented logging lacks non-repudiation mechanisms, making it difficult to handle operational disputes. Summary of the Invention

[0003] This application provides a server security management method, an expansion card, and a server security management system to solve the technical problems of low security, susceptibility to tampering and cloning, and increased load on the baseboard management controller in related technologies based on software-based license verification schemes.

[0004] This application provides a server security management method applied to an expansion card, the method comprising: In response to receiving a scheduling instruction, the system obtains the server product serial number and license file; generates a symmetric decryption key based on the version information in the server product serial number and license file; decrypts the encrypted data in the license file using the symmetric decryption key to obtain authorized plaintext data; verifies the digital signature of the license file based on the verification public key pre-installed in the expansion card's read-only storage area; in response to successful digital signature verification, the system determines whether the authorized identity information in the authorized plaintext data matches the server's hardware identity information; in response to a match, the system generates a function enable signal based on the function authorization information in the authorized plaintext data and outputs it to the baseboard management controller to trigger the baseboard management controller to enable the corresponding server function.

[0005] This application also provides an expansion card for implementing the server security management method of this application during execution. The expansion card includes: The system includes: a hardware interface for data interaction with the baseboard management controller; a read-only memory area for storing the verification public key, function enable bitmap, and base authentication code; a cryptographic algorithm circuit for performing encryption, decryption, and hash operations; a comparison circuit including at least one comparator and an AND gate, with the output of the comparator connected to the input of the AND gate, for performing hardware identity information comparison of authorized identity information; an expansion circuit including at least one data selector with an enable terminal for generating at least one independent function enable signal based on the function enable bitmap; a reminder circuit including a timer for generating a reminder signal before the license expires; an interface management circuit including at least one controllable switch circuit for enabling or blocking the data channel between the baseboard management controller and the internal storage area of ​​the expansion card; and a control circuit connected to the hardware interface, read-only memory area, cryptographic algorithm circuit, comparison circuit, expansion circuit, reminder circuit, and interface management circuit, configured to execute control logic for server security management methods.

[0006] This application also provides a server security management system, the system comprising: A license management subsystem, deployed on the management side, is used to generate and distribute license files bound to server hardware; at least one expansion card, which implements the steps of the server security management method in this application during execution, is deployed on the user equipment side and connected to the server's baseboard management controller, used to verify the license files generated by the license management subsystem; wherein, the private key used by the license management subsystem to digitally sign the license files, together with the verification public key pre-installed in the expansion card for verifying digital signatures, constitutes an asymmetric key pair.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the server security management method described in the following embodiments.

[0008] In response to receiving a scheduling instruction, the system obtains the server product serial number and license file; generates a symmetric decryption key based on the version information in the server product serial number and license file; decrypts the encrypted data in the license file using the symmetric decryption key to obtain authorized plaintext data; verifies the digital signature of the license file based on the verification public key pre-installed in the expansion card's read-only storage area; in response to successful digital signature verification, the system determines whether the authorized identity information in the authorized plaintext data matches the server's hardware identity information; in response to a match, the system generates a function enable signal based on the function authorization information in the authorized plaintext data and outputs it to the baseboard management controller to trigger the baseboard management controller to enable the corresponding server function.

[0009] The server security management method provided in this application ensures that the verification process is actively triggered by the baseboard management controller by setting a response to receiving a scheduling instruction and obtaining the server product serial number and license file, thus forming a controllable security verification entry point. By generating a symmetric decryption key based on the version information in the server product serial number and license file, a dynamic strong binding between the key and specific server hardware and license version is achieved, fundamentally preventing the illegal copying and cross-device use of the license. By using the symmetric decryption key to decrypt the encrypted data in the license file, the authorized plaintext data is obtained, completing the extraction of core authorization information at the hardware layer and providing a trusted plaintext foundation for subsequent verification. Finally, by verifying the digital signature of the license file based on the verification public key pre-installed in the expansion card's read-only storage area, the public key embedded in the hardware completes the verification of the license issuer. Trusted verification of identity and document integrity ensures the authenticity and immutability of the authorization source. In response to successful digital signature verification, the system checks whether the authorized identity information in the plaintext authorization data matches the server's hardware identity information, performing a final verification of the server's hardware identity (such as product serial number and MAC address), thus forming a multi-layered security verification loop. Finally, in response to the match, a function enable signal is generated based on the function authorization information in the plaintext authorization data and output to the baseboard management controller to trigger the baseboard management controller to enable the corresponding server function. This transforms the successful verification result into a direct hardware control signal, making the activation of server functions entirely dependent on the security decisions of the hardware expansion card. This constructs a highly secure and trusted execution environment with a fully hardware-based process, from authorization triggering, identity binding, decryption and signature verification, hardware verification to function enable. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying 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.

[0011] Figure 1 A schematic flowchart illustrating a server security management method provided in an embodiment of this application; Figure 2 A schematic diagram of a license document provided for an embodiment of this application; Figure 3 A flowchart illustrating a server security management method provided in another embodiment of this application; Figure 4 A schematic diagram illustrating the process of generating a symmetric decryption key according to an embodiment of this application; Figure 5 A schematic diagram of a license document provided for another embodiment of this application; Figure 6 This is a schematic diagram of the structure of an expansion card provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a comparison circuit provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an expansion circuit provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a reminder circuit provided in an embodiment of this application; Figure 10 A flowchart illustrating a server security management method provided in yet another embodiment of this application; Figure 11 This is a schematic diagram of the structure of a license document management system provided in an embodiment of this application; Figure 12 A flowchart illustrating a server security management method provided in yet another embodiment of this application; Figure 13 This is a schematic diagram of the interface management circuit provided in another embodiment of this application; Figure 14 This is an internal structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0013] Currently, the fixed functions of the server's Baseband Control Center (BMC) cannot meet the diverse needs of users. For example, some users only need to use a portion of the functions to meet their daily needs, while other functional circuits remain idle most of the time, resulting in wasted resources. Other users require advanced or customized functions of the BMC, but the existing functions cannot meet their needs, thus limiting the flexibility of these functions. Furthermore, when server failures occur due to user errors such as not following the user manual or improper operation, users can tamper with the BMC logs to provide false information, concealing the true cause and evading responsibility. This prevents server vendors' maintenance personnel from locating the actual hardware failure or configuration error, which is detrimental to the server vendor's interests.

[0014] In related technologies, license files are primarily managed securely using the server's built-in BMC chip. License files are generated based on the client's own characteristic information, and feedback files are imported into the functional circuit to be unlocked, thus preventing unauthorized unlocking of the management controller's functional circuit. However, solutions for controlling multiple license files and providing expiration reminders are not disclosed. Regarding verification, the hash value of the log is checked once upon system power-on, and the log is verified via BIOS; no hash verification method is provided for log incrementing.

[0015] Therefore, the relevant technology has the following drawbacks: Insufficient security depth and weak non-repudiation capability: The single log hash verification performed only when the system is powered on cannot cope with log tampering during operation. The lack of a dynamic and continuous integrity protection mechanism allows users to cover up operational errors or failures by tampering with logs afterward. Server manufacturers lack effective technical means to trace responsibility and delineate faults.

[0016] Rigid function management and poor resource utilization and customization capabilities: The solution lacks a mechanism for flexible authorization and parallel control of multiple functional features, making it difficult to meet the actual needs of users to enable, combine, or temporarily try out diverse functions as needed. This results in the BMC function circuits either being fully activated, leading to resource waste, or failing to provide customized advanced functions, resulting in unsatisfactory user experience and resource efficiency.

[0017] Lack of proactive operation and maintenance and lifecycle management capabilities: The relevant solutions do not integrate license validity monitoring and proactive reminder functions before expiration. Users may cause licenses to expire and services to be interrupted due to negligence, which increases operation and maintenance risks and management costs, and cannot achieve closed-loop security operation and maintenance from authorization, use to renewal.

[0018] The verification burden is concentrated on the BMC, affecting core management functions: all license verification logic, cryptographic operations, and log verification rely on the BMC's general-purpose processor and software environment for execution. This not only consumes the computing and storage resources that the BMC should be used for critical out-of-band management tasks, but may also introduce performance bottlenecks due to complex cryptographic operations, affecting the real-time performance and reliability of server management functions. At the same time, it exposes core security logic to a relatively open software layer, lowering the overall security baseline of the system.

[0019] In response to the above technical problems, such as Figure 1 As shown, one embodiment of this application provides a server security management method applied to an expansion card. The method specifically includes the following steps: Step 101: In response to receiving the scheduling instruction, obtain the server product serial number and license file.

[0020] First, before receiving a scheduling command, the expansion card performs the following steps: verifying whether the authentication code entered by the user matches the base authentication code preset in the expansion card's read-only memory area; and in response to the base authentication code matching the authentication code entered by the user, the expansion card enters a ready state so that the expansion card can respond to the scheduling command of the baseboard management controller.

[0021] The expansion card described in this application is a programmable hardware expansion card (FPGA card) specifically designed for server functional safety management. It connects to the baseboard management controller via a hardware interface and is a non-general-purpose network card, memory card, or graphics card. The core feature of this expansion card is the integration of cryptographic algorithm circuitry, protected read-only memory, and dedicated logic circuitry (such as parallel comparison circuitry and expansion circuitry) for license verification and functional control, thereby constructing a hardware root of trust at the physical level, independent of the baseboard management controller software system.

[0022] The baseline authentication code is a static password or key that is remotely pre-set in the read-only storage area of ​​the expansion card by the server manufacturer's administrator after the expansion card is manufactured or deployed. It serves as the baseline for verifying the user's identity. Only when the user enters an authentication code that is exactly the same as the base authentication code through the BMC interface can the expansion card be activated and put into a working state that can respond to scheduling commands, thus forming the first security barrier for hardware access control.

[0023] During the initialization phase of the server security management process, the expansion card itself is first ensured to be in a secure and controllable startup state. Specifically, before the expansion card can respond to scheduling commands issued by the baseboard management controller, the system performs strict local authentication. The user must enter their authentication code through the management interface (such as WebUI) provided by the baseboard management controller. The expansion card's control circuit then reads the baseline authentication code stored in its read-only memory and compares the two. Only when the authentication code entered by the user matches the baseline authentication code exactly will the expansion card's control logic unlock its internal lock and put it into a ready state. This ensures that only authorized administrators can wake up and use the secure hardware, effectively preventing unauthorized operations at the physical contact level.

[0024] When the expansion card receives a scheduling instruction from the baseboard management controller, it retrieves the server product serial number and license file from the baseboard management controller. The license file is generated based on server function customization information, which includes user identifier, server product serial number, server customized function features, and usage period requirements.

[0025] The server feature customization information here is a set of metadata submitted by users through official manufacturer channels to apply for specific feature authorizations. It includes at least a user identifier and server product serial number to uniquely identify the purchaser and the target device, as well as server customization feature characteristics that specifically describe the authorized content (such as a list of specific BMC advanced features that need to be enabled) and usage period requirements (such as permanent, 30-day trial, etc.), which is the original basis for manufacturers to generate targeted license documents.

[0026] Once the expansion card is confirmed to be ready and requires function authorization checks or activation, the baseboard management controller issues a scheduling command to the ready expansion card. The expansion card responds to the scheduling command and obtains the current server's product serial number from the baseboard management controller, serving as an immutable hardware identifier for the device, along with the license document to be verified. This license document is not a generic document but is specifically generated by the manufacturer's license management subsystem based on the server function customization information previously submitted by the user. Specifically, it can be a structured request packet that precisely includes who (user identifier) ​​is requesting which functions (customized features) for which device (product serial number) and for how long (usage period requirements). Therefore, the final generated license document establishes a binding relationship with a specific user and server hardware, laying a secure, reliable, and targeted input foundation for subsequent cryptographic verification and hardware comparison.

[0027] For example, in this application, an original license file is first generated based on the server function customization information submitted by the user through official channels, and the plaintext authorization data of the original license file is encrypted to obtain the license file.

[0028] like Figure 2 As shown, the original license file is logically divided into two main parts: license data and signature data.

[0029] 1. The plaintext authorization data contains the core parameters of the authorized content: 1) Document Identifier and Product Information: License ID serves as the unique identifier for the license document; License class (product type) and Product version (product version number) specify the applicable server product type and version, respectively.

[0030] 2) Licensing Strategy: The License Type field defines the licensing nature. For example, '0' represents perpetual validity, '1' represents a beta version with a fixed validity period (e.g., 90 days), and '2' represents an upgrade version based on the purchase duration. The Feature field specifically lists the names of the licensed BMC features.

[0031] 3) Device Binding Information: The Product SN (server product serial number, 63 bytes) and BMC MAC (media access control address of the baseboard management controller's management port, 8 bytes) together serve as the unique hardware identifier for the target server device. To ensure the reliability of the binding, the interface for users to modify these two identifiers has been blocked before the server leaves the factory, thereby effectively preventing the illegal reuse of the same license on multiple devices by tampering with the identifiers.

[0032] 4) Time Limit Control: Creator Time (license effective date) and Expired Date (license expiration date) precisely define the effective and expiration dates of the license. For perpetual licenses, the Expired Date field is set to '0'. Reserved is a reserved field for future expansion.

[0033] 2. The signature data provides the information needed to verify the authenticity and integrity of the document: 1) Version and Algorithm Identifier: The License version (license file version and comments) records the file format version. The Algorithm (cryptographic algorithm used in the license file) field explicitly declares the suite of cryptographic algorithms used for file generation and verification in a compact bit format (e.g., 12 bits), including symmetric encryption algorithms (such as AES), hash algorithms (such as SHA256), and asymmetric signature algorithms (such as RSA3072).

[0034] 2) Digital Signature Value: The SignatureValue field stores the result of cryptographic processing on the aforementioned authorized plaintext data. Its generation process is as follows: First, the hash algorithm circuit calculates a hash value on the License Data to generate a fixed-length digest; then, the digital signature circuit uses the vendor's private key to perform a digital signature operation on the digest, and the result is the SignatureValue. The corresponding public key will be pre-stored in the read-only memory area of ​​the user server's expansion card for subsequent verification.

[0035] After generating the original license file containing the authorized plaintext data and digital signature value, the authorized plaintext data portion can be encrypted using a symmetric key derived from information such as device identification, forming ciphertext. Finally, the encrypted data and signature data are assembled into a complete final license file that can be directly distributed to users. This file is distributed through the operations and maintenance management system and can be loaded by the user onto the target server's BMC, where it can then be decrypted and verified by the expansion card.

[0036] Step 102: Generate a symmetric decryption key based on the server product serial number and the version information in the license file.

[0037] Specifically, the server product serial number is padded with bytes, then segmented to obtain a first serial number and a second serial number; an XOR operation is performed on the first and second serial number to obtain a first intermediate value; a hash operation is performed on the version information in the license file to obtain a second intermediate value; an XOR operation is performed on the first and second intermediate values ​​to obtain a third intermediate value; the third intermediate value is segmented to obtain a fourth and a fifth intermediate value; and an XOR operation is performed on the fourth and fifth intermediate values ​​to generate a symmetric decryption key.

[0038] Byte padding refers to a preprocessing operation that extends the length of the original data (here, a 63-byte Product SN). By adding a predefined padding byte (such as 0x00), the total length is made to meet the requirements of subsequent processing steps (such as splitting into equal-length data blocks), forming a 64-byte extended sequence number SN.

[0039] The segmentation process involves dividing a continuous data block (here, a 64-byte SN) into two or more sub-data blocks of equal length according to a predetermined rule (such as dividing it from the middle). In this application, it specifically refers to dividing the SN into two parts: the first 32 bytes (SN(63..32)) and the last 32 bytes (SN(31..0)).

[0040] The XOR operation is a basic logical bitwise operation, symbolized as follows: The rule is: output 0 if the two input bits are the same, and output 1 if they are different. In this application, the XOR operation is used to obfuscate and merge data blocks, and is the core operation for generating intermediate values ​​and the final key. Its irreversibility helps to enhance the security of key derivation.

[0041] Intermediate values ​​are transitional data results generated during the key generation process by performing a series of intermediate steps (such as supplementation, splitting, hashing, and XOR) on the original input data. The first intermediate value (A32) and the second intermediate value (B32) respectively carry the characteristic information of the device hardware identifier and the license version. Their XOR and the subsequent fusion of the results generate the final key material.

[0042] A symmetric decryption key is a symmetric cryptographic algorithm key used to decrypt the encrypted data portion of a license file.

[0043] Specifically, the license document generation process includes digital signatures and data encryption.

[0044] The digital signature process is as follows: Figure 3As shown, the purpose of digital signatures is to assign an unforgeable identity credential to license data. First, the plaintext portion of the License Data, containing all authorization details, is hashed to generate a fixed-length, unique digital digest, Hash_value. This digest acts like a fingerprint; any slight alteration will cause its value to change drastically. Then, the system calls the digital signature circuit to generate a pair of asymmetric cryptographic public-private keys (Pub_Key, Pri_Key). Using the strictly confidential private key Pri_Key, a digital signature operation (which manifests as a decryption operation in algorithms like RSA) is performed on the aforementioned hash_value, generating a signature value, SignatureValue. This signature value is written to the SignatureValue field of the license file, while the hash algorithm and asymmetric algorithm identifier are written to the Algorithm field. Crucially, the public key Pub_Key, paired with the private key, is securely transmitted and pre-installed in the read-only memory (ROM) of the user server FPGA expansion card, serving as the sole trusted credential for subsequent signature verification. This step ensures that the license data cannot be tampered with from the date of issuance and can be verified by the expansion card as originating from a legitimate vendor.

[0045] like Figure 4As shown, data encryption aims to protect sensitive authorized plaintext information. The encryption process begins with the generation of a symmetric key, Key, bound to a specific device. First, the 63-byte Product Serial Number (SN) of the target server is padded with a 0x00 byte to form a 64-byte server product serial number. Next, this 64-byte server product serial number is split into the first 32 bytes SN (63..32), which is the first serial number data, and the last 32 bytes SN (31..0), which is the second serial number data. These two parts are XORed to obtain a first intermediate value A32 representing the device hardware. Simultaneously, a SHA256 hash operation is performed on the License version identifier in the license file to obtain a second intermediate value B32 representing the file version. XORing A32 and B32 results in C32. C32 is then divided into the first 16 bytes C32(31..16) and the last 16 bytes C32(15..0). XORing C32(31..16) and C32(15..0) generates the final 128-bit symmetric decryption key. This design makes the key dependent on both device identity and file version, achieving dual binding. Using the final 128-bit symmetric decryption key and a specified symmetric encryption algorithm (such as AES), the plaintext of the License Data portion is encrypted, generating ciphertext Data_Ciphertext. This ciphertext replaces the original plaintext and is stored in the corresponding field. The identifier of the symmetric encryption algorithm used is written to the Algorithm field.

[0046] After the above digital signature and data encryption operations, the original license file is transformed into a secure, final file. Its layout is as follows: Figure 5 As shown: the core license data exists in encrypted form and is protected by a dynamically generated device binding key; while the signature value and algorithm identifier required for verification remain in plaintext. Together with the public key pre-installed in the expansion card, they can reliably verify the integrity and origin of the license file data.

[0047] Step 103: Use the symmetric decryption key to decrypt the encrypted data in the license file to obtain the authorized plaintext data.

[0048] The symmetric cryptographic algorithm in the signature data of the license file is read, and the encrypted data in the license file is decrypted based on the symmetric cryptographic algorithm and the symmetric decryption key to obtain the authorized plaintext data.

[0049] After successfully generating a symmetric decryption key bound to the current server and license version, the expansion card immediately initiates the decryption process. First, it needs to determine the specific algorithm used for encryption. To do this, the expansion card reads the Algorithm field from the license file's signature data. This field explicitly records the identifier of the symmetric cryptographic algorithm used to encrypt the License Data (e.g., indicating AES). After obtaining the algorithm identifier, the expansion card determines the specific cryptographic algorithm to be invoked for decryption. Subsequently, the expansion card inputs the dynamically generated symmetric decryption key along with the encrypted data parsed from the file (i.e., the ciphertext content of the License Data field) into the decryption algorithm, performing a standard symmetric decryption operation. In this way, the authorized plaintext data fully contains the original, structured authorization information, such as the license type, authorized features, bound device identifier, and effective and expiration dates. At this point, the encrypted and protected authorization content is securely restored within the expansion card, providing a clear and reliable data foundation for subsequent signature verification and authorization assessment. The entire decryption process is completed in the hardware security environment of the expansion card, ensuring that the key and intermediate calculation process are not leaked, which constitutes the key conversion step from ciphertext to trusted plaintext.

[0050] Step 104: Verify the digital signature of the license file based on the verification public key pre-installed in the read-only storage area of ​​the expansion card.

[0051] The algorithm identifier and digital signature value are read from the signature data of the license document. The algorithm identifier specifies the hash algorithm and asymmetric cryptographic algorithm required for verification. The verification public key corresponding to the asymmetric cryptographic algorithm is read from the verification parameters pre-installed in the read-only memory area of ​​the expansion card. The digital signature value is decrypted using the verification public key to obtain a first digest value. The authorized plaintext data is hashed according to the hash algorithm indicated by the algorithm identifier to obtain a second digest value. The first digest value and the second digest value are compared. If the first digest value and the second digest value match, the digital signature verification is confirmed to be successful. The digital signature of the license document is generated by signing the authorized plaintext data using a private key corresponding to the verification public key pre-installed in the read-only memory area of ​​the expansion card after performing a digest operation on the data.

[0052] A verification public key is a publicly distributed cryptographic key used in asymmetric cryptography algorithms. In this application, it specifically refers to a public key generated by the licensee (manufacturer) and strictly paired with the private key used for signing. This public key is pre-securely written into the read-only memory of the expansion card, and its sole purpose is to verify digital signatures signed with the corresponding private key. It cannot be used for signing itself, and the private key cannot be derived from the public key.

[0053] The algorithm identifier is an encoded field stored in the signature data section of the license document. It specifies the cryptographic algorithm in a compact format (such as a bitmap). In addition to the symmetric cryptographic algorithms mentioned above, it explicitly specifies two other types of cryptographic algorithms: hash algorithms (such as SHA256) used to calculate the data digest and asymmetric cryptographic algorithms (such as RSA3072) used to generate and verify the signature. This identifier is the basis for the verifier to correctly select the computation method.

[0054] A hash value, also known as a digest value, is a fixed-length, nearly unique data "fingerprint" generated by hashing data of arbitrary length using a hash algorithm. In this step, the first digest value is the original digest generated at the time of issuance, which is restored from the digital signature value using public key operations; the second digest value is a new digest obtained by the verifier re-hash the currently received authorized plaintext data using the same hash operation. Comparing the two is crucial for successful verification.

[0055] In this specific step, the decryption operation refers to the cryptographic operation performed on the digital signature value using the verification public key. Although in asymmetric cryptography, the public key is usually used for encryption, in this verification scenario, this operation is mathematically the inverse of the signature generation process (private key encryption), and its purpose is to recover the original hash digest from the signature. Therefore, it is referred to as the decryption operation in this application description to reflect its functional purpose.

[0056] The expansion card first extracts the crucial algorithm identifier and digital signature value from the signature data section of the license document. The algorithm identifier is a precise set of instructions that explicitly tells the expansion card which hash algorithm to use to verify data integrity and which asymmetric cryptographic algorithm to use to verify the signature's origin. Next, the expansion card turns to its own read-only memory and, guided by the algorithm identifier, reads the pre-installed verification public key that matches the specified asymmetric algorithm. This public key is a manufacturer-authoritative hardware credential paired with the private key cryptographically used when issuing the license.

[0057] Subsequently, the expansion card uses the acquired verification public key to perform specific cryptographic operations on the digital signature value attached to the file, thereby reconstructing the original hash result locked by the issuer when creating the signature, i.e., the first digest value, which theoretically represents the complete state of the license data at the time of issuance. Simultaneously, for objective comparison, the expansion card strictly follows the hash algorithm specified in the algorithm identifier to perform hash calculations on the successfully decrypted authorized plaintext data, generating a second digest value that reflects the current actual state of the data.

[0058] Finally, the expansion card performs a bit-level precise comparison between its self-generated second digest value and the first digest value authoritatively reconstructed from the signature. The digital signature verification is considered successful only if these two digest values ​​are completely identical. This consistency conveys two deterministic signals: first, the core authorized data of the license document has not been tampered with since its issuance, ensuring data integrity; second, the document was indeed issued by a legitimate vendor holding the corresponding private key, proving the authenticity of the source. The entire verification logic is built on a rigorous foundation of asymmetric cryptography. The digital signature in the document is initially generated by the vendor hashing its authorized plaintext data and then signing it using a private key paired with the public key within the expansion card. Therefore, this verification step, using the public key, is an irrefutable authoritative authentication of the license's legitimacy within the hardware security boundary, laying a credible foundation for subsequent functional authorization decisions.

[0059] Step 105: In response to successful digital signature verification, determine whether the authorized identity information in the authorized plaintext data matches the server's hardware identity information.

[0060] The authorized server identification information is extracted from the authorized plaintext data, including the authorized product type, authorized product serial number, and authorized network port address; the hardware identification information of the current server device is obtained from the baseboard management controller, including the product type, product serial number, and network port address; the authorized server identification information is compared with the hardware identification information; if the authorized server identification information matches the hardware identification information, the server identification verification is deemed successful; the license type and the authorized validity period indicated by the authorized plaintext data are extracted from the authorized plaintext data; if the license type is a time-limited license and the current system time is within the authorized validity period, the license validity period verification is deemed successful; if the server identification verification is successful and the license validity period verification is successful or skipped, the authorized identity information in the authorized plaintext data is determined to match the server's hardware identity information.

[0061] Authorized server identification information refers to a set of hardware characteristic parameters extracted from verified license authorization plaintext data to identify the license's authorized target. It includes at least: authorized product type (e.g., rack-mount, dual-socket server category code), authorized product serial number (a unique serial number of the server hardware allowed by the license), and authorized network port address (the MAC address of the BMC management network port allowed by the license). This information defines the "target device profile" to which the license is legally bound.

[0062] Hardware identification information: This refers to a set of parameters that characterize the true identity of the device, read in real time from the physical server hardware currently performing the verification operation via the baseboard management controller. It corresponds one-to-one with the "authorized server identification information," including: the server's actual product type, product serial number, and the actual network port address of the BMC management port. This information represents the "true identity of the current device."

[0063] The license type is a field in the license authorization plaintext data used to declare the validity mode of the license. It is mainly divided into perpetual licenses (no time limit) and time-limited licenses (with a clearly defined start and end time). This field directly determines whether time validity verification is required.

[0064] This application employs a dual verification mechanism: first, it verifies whether the device authorized by the license is the same entity as the physical server currently running the verification; second, it verifies that the license is still valid in terms of time. Only when both conditions are met does the license become valid. Specifically, after successfully decrypting and verifying the authorization information, the expansion card extracts the license type and detailed validity period from the plaintext authorization data. When the license is identified as a time-limited license, the expansion card immediately activates its internal hardware timer and begins precise timing from the license's effective date.

[0065] To provide early warnings, the expansion card calculates a specific warning time by combining a pre-set reminder threshold (e.g., representing 30 days in advance) stored in its read-only memory with the authorization expiration time. This time is the point at which the renewal or processing warning is expected to be sent to the user.

[0066] Throughout the license's validity period, the expansion card continuously compares the current timer duration with the calculated reminder time using its hardware circuitry. Once the current timer reaches or exceeds the preset reminder time, the expansion card automatically generates a clear reminder signal and outputs it to the baseboard management controller.

[0067] Upon receiving the alert signal from this hardware, the baseboard management controller can notify the system administrator or user, through its management interface (such as WebUI), logging system, or alarm interface, in a visual, audible, or recordable manner, indicating that their license is about to expire. This mechanism realizes a shift from passive expiration to proactive early warning management, allowing users ample time to operate and effectively avoiding the risk of business interruption due to unexpected license expiration, thus enhancing the proactivity and reliability of system operation and maintenance. The entire monitoring and alerting process is completed independently by the expansion card hardware, without relying on the BMC's software scheduling, ensuring the timeliness and accuracy of the alerts.

[0068] Specifically, when license file verification fails, the BMC records the specific reason in the SEL log, such as expired license or invalid license. Since users can provide false information by tampering with the log and corresponding digest value (e.g., concealing the reason for license verification failure, malfunctions caused by improper user operation, etc.), thus creating repudiation, this embodiment sets a response to digital signature verification failure and / or mismatch between authorized identity information and server hardware identity information. This response generates a verification failure signal and outputs it to the baseboard management controller, causing the baseboard management controller to record the corresponding system event log. In response to receiving an integrity guarantee request for the system event log initiated by the baseboard management controller, the current hash value of the log is calculated. This current hash value is written as an immutable base value to the expansion card's read-only storage area, and the current hash value is returned to the baseboard management controller for appending to the log for download verification, ensuring the integrity of the BMC log. Specifically: (1) During the operation of the server, the baseboard management controller will continuously generate and record system event logs.

[0069] (2) The system determines whether the user has triggered a request to download the system event log through the management interface (such as the Web interface) of the baseboard management controller.

[0070] (3) When a user triggers a request to download logs, the baseboard management controller sends the current system event log data to the expansion card, which then calls its internal hash algorithm calculation engine (such as the SHA256 algorithm) to perform a hash operation on the log data and generate the first hash value.

[0071] (4) The expansion card returns the first hash value to the baseboard management controller, which then appends it to the system event log file to be downloaded for the user to download. At the same time, the expansion card uses the first hash value as an immutable base value and writes it into its own read-only memory for permanent storage.

[0072] (5) After the user downloads the log file containing the first hash value to the local machine, the same hash algorithm can be used in the local environment to re-hash the log data part of the log file to obtain the second hash value.

[0073] (6) The user compares the second hash value calculated locally with the first hash value attached to the log file.

[0074] (7) If the second hash value is consistent with the first hash value, it proves that the log downloaded by the user has remained intact since its generation and has not been tampered with.

[0075] Thus, even if a user maliciously tampers with the log content after downloading and accordingly calculates and replaces the hash value in the file in an attempt to cover up the fact, the original calculated and stored baseline value is already fixed in the expansion card's read-only storage area, and the user cannot modify this hardware storage area. Therefore, when auditing or accountability is needed, the tampering can be easily identified by comparing the hash value of the log file provided by the user with the original baseline value stored in the expansion card. Since the user cannot provide a tampered log that matches the baseline value in the hardware, they cannot effectively deny the tampering.

[0076] Thus, while meeting the basic requirement of verifiable integrity of system event logs, this method fundamentally prevents users from denying responsibility by modifying logs and their verification values ​​after the fact by fixing the cryptographic anchor point of the logs in a hardware security area that cannot be tampered with by the user. This provides a reliable audit and accountability basis for server operation and maintenance.

[0077] Step 106: In response to the matching, generate a function enable signal based on the function authorization information in the authorized plaintext data and output it to the board management controller to trigger the board management controller to enable the corresponding server function.

[0078] In response to the matching of authorized identity information in the authorized plaintext data with the hardware identity information of the server, a verification pass signal is generated; server customized function feature information is extracted from the authorized plaintext data; based on the server customized function feature information, a function enable signal corresponding to the server customized function is generated; the verification pass signal and the function enable signal are output to the baseboard management controller to trigger the baseboard management controller to activate the corresponding server function according to the function enable signal.

[0079] Functional authorization information refers to feature identification information extracted from verified license authorization plaintext data that specifically describes one or more server functions that are licensed for use. This information clearly indicates which specific BMC functional features (such as specific monitoring, configuration, or management functions) the user has purchased through the license.

[0080] A function enable signal is a physical electrical or logic level signal generated by the expansion card's hardware circuitry based on function authorization information. This signal directly corresponds to one or more specific server functions. Its function is as a "hardware switch instruction," informing the baseboard management controller which one or more authorized server functions should be activated. A single function enable signal can control a single function, or multiple functions can be controlled through a set of parallel signals.

[0081] The verification pass signal is a summary status signal (usually a high level or a specific digital code) generated by the expansion card after determining that the authorized identity information matches the hardware identity information. This signal indicates that the entire license verification process (including decryption, signature verification, device matching, time verification, etc.) has been successfully completed. It is the prerequisite for the generation and output of all function enable signals.

[0082] Server-customized feature information, also known as the aforementioned feature authorization information, is a detailed description of the specific server features that the user specifies and desires to enable when applying for a license. This information is written into the license during license generation and extracted after successful verification, serving as the direct basis for generating specific feature enable signals.

[0083] Once the expansion card determines in step 105 that the authorized identity information matches the server's hardware identity information, the entire security verification process is considered complete. As a hardware declaration of this success, the expansion card first generates a verification pass signal. This signal summarizes and confirms the results of all previous verification steps.

[0084] Next, the expansion card precisely extracts server-customized feature information from the verified, authentic, complete, and applicable plaintext authorization data. This information clearly lists the specific features that the user is permitted to enable.

[0085] Based on the extracted functional characteristic information, the control logic or dedicated circuitry (such as feature expansion circuitry) within the expansion card begins to operate, generating one or more corresponding function enable signals. These signals are specific control instructions that can be directly recognized by the baseboard management controller hardware interface, and each signal maps to a specific server function (e.g., enabling advanced power management, activating specific diagnostic circuitry, etc.). For situations where multiple functions need to be enabled simultaneously, the expansion card can generate a set of independent function enable signals in parallel.

[0086] Finally, the expansion card outputs a verification pass signal (which serves as the overall prerequisite) and a function enable signal carrying specific operation instructions to the baseboard management controller through its hardware interface.

[0087] Upon receiving this set of signals from the trusted hardware (expansion card), the baseboard management controller's control logic executes the final operation: the verification pass signal confirms the authorization's legitimacy; the controller parses the function enable signals and, based on these signals, activates the corresponding internal server function circuitry, such as enabling specific management services, unlocking configuration options, or enabling advanced monitoring features. Thus, the specific server functions purchased by the user through the license are securely and controllably enabled. The entire process ensures the activation of server functions, relying entirely on the end-to-end trusted verification and authorization chain guaranteed by the hardware expansion card.

[0088] When multiple server functions need to be enabled, the generation of function enable signals based on the function authorization information in the authorized plaintext data includes: extracting multiple server-customized function feature information from the authorized plaintext data; generating multiple function signals corresponding to the multiple server-customized function based on the multiple server-customized function feature information; reading the function enable bitmap pre-stored in the read-only memory area of ​​the expansion card, the function enable bitmap containing multiple bits, each bit corresponding to an authorized server function feature; enabling multiple data selector circuits in the expansion card based on the multiple function signals, so that multiple independent function enable signals are generated in parallel by the multiple data selector circuits according to the logic values ​​of each bit in the function enable bitmap; and outputting the multiple function enable signals to the baseboard management controller, so that the baseboard management controller can enable multiple server functions in parallel based on different function enable signals.

[0089] A feature enable bitmap is a binary data structure pre-installed in the read-only memory of an expansion card, typically represented as a field consisting of multiple consecutive bits. In this bitmap, each bit uniquely maps to and represents an authorized server feature. For example, bit 0 represents "remote control function," bit 1 represents "advanced diagnostic function," and so on. The value of the bit ('1' or '0') indicates whether the corresponding feature is authorized and enabled.

[0090] A data selector circuit is a digital logic circuit (such as a multiplexer, MUX) that has at least one data input, one select input, and one output. Its function is to select one signal from multiple data inputs to the output based on the signal at the select input. In this application, the enable terminal of the circuit is controlled by a verified overall enable signal, while its data inputs are respectively connected to different bits of a function enable bitmap.

[0091] In applications requiring the simultaneous activation of multiple server functions, a set of control signals, electrically and logically separated, is generated in parallel by multiple data selector circuits. Each signal independently corresponds to a specific server function, and its level state (e.g., high / low) is determined solely by the authorization state of the corresponding bit in the function enable bitmap. This set of signals is output simultaneously to achieve concurrent control of multiple server functions.

[0092] Specifically, once the expansion card determines that the authorization verification is successful, it extracts information about the multiple server-customized features requested by the user from the plaintext authorization data. Based on this information, the expansion card's control logic first generates a set of abstract functional signals, which represent the set of functions the user intends to enable.

[0093] The expansion card reads a function enable bitmap pre-stored in its read-only memory. This bitmap is a predefined authorization policy template, where each bit represents a hardware or software function circuit on the server that can be individually authorized and controlled. The core parallel control is implemented by a set of data selector circuits. These circuits are pre-configured such that each circuit corresponds to a specific bit in the function enable bitmap. When the expansion card needs to generate the final control signal, it enables this set of data selector circuits based on the aforementioned function signal. Each enabled data selector circuit immediately and in parallel checks the logic value of its corresponding bit in the function enable bitmap. If the bit is '1' (indicating authorization enabled), the circuit generates a valid function enable signal (e.g., high level) at its output; if the bit is '0' (indicating unauthorized or not enabled), it outputs an invalid signal (e.g., low level or high impedance). Because all data selector circuits operate in parallel, multiple independent function enable signals can be generated simultaneously. Finally, this set of parallel-generated function enable signals, each of which precisely reflects the authorization status of a specific function, is output together to the board management controller.

[0094] Upon receiving this set of parallel hardware signals, the baseboard management controller can simultaneously and independently activate multiple corresponding server function circuits based on different signal line states. For example, setting one signal line high enables the remote KVM function, while setting another signal line high unlocks performance tuning options, thereby achieving efficient, secure, and flexible parallel activation and control of multiple server functions based on a single license. This hardware-based parallel mechanism not only responds quickly but also ensures high reliability and tamper resistance to the multi-functional control process by embedding the licensing strategy (bitmap) in the hardware and executing it through dedicated circuitry.

[0095] In one embodiment, in response to receiving a firmware update command from the baseboard management controller and an authentication code input by the user; verifying whether the authentication code input by the user matches the reference authentication code pre-stored in the read-only memory area of ​​the expansion card; in response to the authentication code input by the user matching the reference authentication code pre-stored in the read-only memory area of ​​the expansion card, activating the interface management circuit of the expansion card to allow the baseboard management controller to read the update firmware file pre-stored in the random access memory area of ​​the expansion card; wherein, the update firmware file is a function downgrade firmware, which is configured to modify the function authorization state inside the expansion card; modifying the function authorization state inside the expansion card includes clearing the bit corresponding to the function to be deleted in the function enable bitmap or replacing it with a firmware version that does not have the logic for the function to be deleted; transmitting the update firmware file to the baseboard management controller to complete the burning, so that the expansion card loads the updated firmware after restarting, and permanently disables the function to be deleted in subsequent function authorization verification.

[0096] Specifically, when the expansion card receives a firmware update command and accompanying user authentication code from the baseboard management controller, it first performs strict authentication, comparing the user-input authentication code with a baseline authentication code pre-stored in the expansion card's read-only memory. Only if the two match will the expansion card's control logic activate its interface management circuitry, thereby opening the data channel for the baseboard management controller to access the expansion card's internal random access memory.

[0097] It is worth emphasizing that the updated firmware file in this embodiment specifically refers to the function downgrade firmware. This firmware is designed to modify the function authorization status within the expansion card, and its implementation includes one of two approaches: one is to clear specific bits corresponding to the function to be deleted in the function enable bitmap pre-installed within the expansion card; the other is to completely replace the existing firmware of the expansion card with a new firmware version that does not contain the logic for the function to be deleted. Regardless of the approach used, this function downgrade firmware is protected by the server manufacturer's digital signature to ensure its integrity and authenticity.

[0098] After the interface management circuit is activated, the baseboard management controller can read the function degradation firmware from the expansion card's random access memory and transfer it to the target storage area to complete the firmware flashing. The expansion card then performs a reboot operation, loading the updated firmware. Subsequently, during any function authorization verification process during server operation, the expansion card will, based on its internally modified function authorization status, permanently prohibit the generation of enable signals corresponding to the function to be deleted, thereby achieving irreversible disabling of the server function at the hardware level. This mechanism fundamentally overcomes the recoverability risk of traditional software authorization revocation schemes, ensuring the reliability of authorization execution.

[0099] In one feasible implementation, after generating a symmetric decryption key based on the server product serial number and version information in the license file, the generated symmetric decryption key is verified in the expansion card based on preset verification logic. The verification logic includes at least one of the following: verifying whether the bit length of the symmetric decryption key meets the preset algorithm requirements; verifying whether the symmetric decryption key is all zeros, all ones, or contains a preset invalid pattern; comparing the similarity of the symmetric decryption key with one or more reference key samples pre-stored in the read-only memory area of ​​the expansion card; and executing the step of decryption using the symmetric decryption key only after the key activity verification passes.

[0100] After completing the symmetric decryption key generation process based on the server product serial number and version information in the software license file, the system will immediately initiate an internal key verification mechanism. This verification process is executed in a secure environment within the expansion card and follows strict preset logic to ensure the validity and security of the generated key, preventing subsequent decryption operations from malfunctioning or data corruption due to input errors or malicious tampering.

[0101] The preset verification logic covers one or more of the following core verifications: Basic specification verification: First, verify whether the bit length of the generated symmetric decryption key fully meets the preset requirements of the target decryption algorithm (such as AES-256) to ensure that its data structure is legal.

[0102] Weak key detection: Next, check whether the key is all zeros, all ones, or contains other known, weak, preset invalid patterns (such as simple repeating sequences) to exclude weak keys generated by logical errors or attacks.

[0103] Benchmark Sample Comparison: In more stringent verification scenarios, the expansion card compares one or more pre-stored benchmark key samples in its built-in read-only memory with the currently generated key at the cryptographic level. This step aims to verify whether the key's generation source and pattern conform to the expected authorized scope, effectively identifying unauthorized or anomalous key constructions.

[0104] The entire verification process is an active verification. Only if all applicable verification items mentioned above pass successfully will the expansion card's security controller determine that the symmetric decryption key is an active key and authorize the execution of subsequent processes. The system then uses this verified key to decrypt the target encrypted data. If any verification step fails, the decryption process will be immediately terminated, and a security audit log will be recorded to ensure that the system state is secure and controllable.

[0105] Please see Figure 6 An embodiment of this application provides an expansion card for executing the server security management method of this application. The expansion card specifically includes: Hardware interface for data interaction with the baseboard management controller.

[0106] The hardware interface can be a PCIe interface. The FPGA (programmable logic expansion card) is built into the user's server through the PCIe physical interface and interacts with the BMC through this interface.

[0107] The read-only storage area is used to store the verification public key, the function enable bitmap, and the base authentication code.

[0108] To ensure that data is not lost after the system loses power, this application sets up a read-only storage area in the expansion card to store user data that needs to be stored for a long time, such as authentication code Auth_code, public key Pub_Key of asymmetric cryptography algorithm, key of symmetric cryptography algorithm, etc.; there are N groups, which can store data of N users; and the ROM access permissions are not open to users, so users cannot tamper with the data in the ROM.

[0109] Cryptographic algorithm circuits are used to perform encryption, decryption, and hash operations. These circuits include SHA256, RSA, and AES algorithm engines.

[0110] The comparison circuit includes at least one comparator and an AND gate. The output of the comparator is connected to the input of the AND gate, and is used to perform hardware identity information comparison of authorized identity information and verify the integrity of BMC log.

[0111] Specifically, the circuit structure of the comparison circuit is as follows: Figure 7 As shown, The system includes n comparators (JMP_1~JMP_n), as shown in the diagram: Comparator 1, Comparator 2, Comparator n, and a three-input AND gate. The function of comparator JMP is to compare inputs 1 and 2. When input 1 equals input 2, the output is high; when input 1 does not equal input 2, the output is low. Input 1 of JMP_1~JMP_n is connected to parameters read from the License file, such as 'License_class' (product type), 'Product_SN' (server product serial number), and 'BMC_MAC' (media access control address of the baseboard management controller's management network port). Input 2 of JMP_1~JMP_n is connected to the RAM area (random access memory), which stores the 'License_class', 'Product_SN', and 'BMC_MAC' parameters read from the BMC and passed to the FPGA card. The outputs of JMP_1~JMP_n are connected to the inputs of the multi-input AND gate, and the output of the three-input AND gate is connected to the check signal Check_sig.

[0112] Taking JMP_1 as an example, when the product type License_class' read from the License file by the FPGA card is equal to the product type License_class of the server device, the output of JMP_1 is Result_1='1'; when License_class' ≠ License_class, Result_1='0'. Only when all parameter comparison results are '1', the AND output is high, i.e., the check signal Check_sig='1', indicating that the verification passed; when any one or more comparison results are '0', the AND output is low, thus making Check_sig='0', indicating that the verification failed.

[0113] The expansion circuit includes at least one data selector with an enable terminal for generating at least one independent function enable signal based on a function enable bitmap to enable multiple functional features of the BMC.

[0114] In related technologies, one license file corresponds to one functional feature. When a user requires multiple functional features, the manufacturer needs to output multiple license files, resulting in low efficiency. Therefore, a feature extension circuit is used to enable multiple functional features of the BMC.

[0115] Specifically, the circuit structure of the expansion circuit is as follows: Figure 8 As shown, the expansion circuit includes N 2-to-1 data selectors MUX_1~MUX_n with enable terminals e. The figure shows data selector 1, data selector 2, data selector n, comparator JMP, and three-input AND gate AND_3. The function of MUX is: when enable terminal e is high, MUX is enabled; when e is low, MUX is disabled. Under the condition e='1', when input terminal Y='1', the signal is output from output terminal 1; when input terminal Y='0', the signal is output from output terminal 2. The input terminals Y of MUX_1~MUX_n are connected to the N bits Bit(1)~Bit(n) of the Feature cell expansion circuit in the ROM area (Read-Only Memory). The output terminals 1 of MUX_1~MUX_n are connected to the function enable signals Function_en(1)~Function(n). The diagram shows function enable signal 1, function enable signal 2, and function enable signal n. The output terminals 2 of MUX_1~MUX_n are grounded. Terminal 1 of JMP is connected to the Code_in input port, terminal 2 of JMP is connected to the Auth_code area of ​​the ROM, and the output terminal of JMP is connected to input terminal 1 of AND_3. Input terminal 2 of AND_3 is connected to the Check_sig verification signal, and input terminal 3 is connected to the License file validity period signal Valid_sig. The output terminal of AND_3 is the enable control signal enable_sig, which is connected to the enable terminal e of MUX_1~MUX_n.

[0116] The function of this circuit is as follows: (1) The manufacturer administrator writes the bit corresponding to the functional feature to be enabled into the Feature area of ​​the ROM. Each bit represents a functional feature. Setting '1' means enabling a certain functional feature, and setting '0' means disabling the corresponding functional feature. At the same time, the manufacturer administrator writes the authentication code Auth_code entered by the user into the ROM.

[0117] (2) The user inputs the authentication code through the Code_in input port of BMC. JMP outputs a high level only when the correct authentication code is input. When the License file is verified (Check_sig='1') and the License file has not expired (Valid_sig='1'), AND_3 outputs a high level and enable_sig='1', thus enabling MUX_1~MUX_n to work normally.

[0118] (3) with Figure 8 Taking MUX_1 and MUX_2 as examples, when e='1', Bit(1) in the Feature='1', so MUX_1 outputs a high level, thus enabling the function signal 1 Function(1)='1'; since Bit(2)='0', MUX_2 outputs a low level (grounded) from output terminal 2, at which time output terminal 1 is floating and has no output, so Function(2) has no output. Function(1)='1' is passed to the BMC, and the BMC enables the corresponding feature function.

[0119] (4) When the user enters an incorrect authentication code, or the license file verification fails (Check_sig='0'), or the license file expires (Valid_sig='0'), enable_sig='0', the MUX_1~MUX_n functions are disabled, and Function(1)~Function(n) have no output. Therefore, BMC will not enable the corresponding feature functions, thus ensuring security.

[0120] The reminder circuit, including a timer, generates a reminder signal before the license expires. The function of the reminder circuit is to send a reminder signal before the expiration of trial versions or licenses with fixed validity periods, so as to remind users to renew their licenses in time to ensure the continuity and availability of business functions; and to send a license validity invalidation signal when the license expires, so that the corresponding functions of the BMC are disabled.

[0121] Please see Figure 9The reminder circuit structure includes a timer, an accumulator (ADD), a comparator (JMP), comparators (CMP1~2), and NOT gates (NOT_1~NOT_3). Terminal 1 of JMP is connected to the License_Type of the License file, terminal 2 of JMP is grounded, the output of JMP is connected to the input of NOT_1, and the output of NOT_1 is connected to the E terminal of the timer. The clk terminal of the timer is connected to the clock signal CLK, the T terminal of the timer is connected to the Creator_Time of the License file, and the Q output of the timer is connected to CMP_1 (…). Figure 9 Comparator 1) CMP_2 Figure 9 The input terminal 1 of comparator 2 in the ADD is connected to the Expired_Date field of the License file; the IN_2 terminal of ADD is connected to the Threshold area of ​​the ROM (where the expiration reminder threshold is set); the output terminal of ADD is connected to the input terminal 2 of CMP_1; the output terminal of CMP_1 is connected to the input terminal of NOT_2; the output terminal of NOT_2 is connected to the alarm signal Alarm_sig; the input terminal 2 of CMP_2 is connected to Expired_Date, and the output terminal is connected to the Valid_sig signal.

[0122] Among them, Timer: E is the enable terminal, T is the start time. When E is high, Timer is enabled. Under the excitation of the clock signal clk, it starts timing with T as the start time, and the Q terminal outputs the real-time time value.

[0123] Accumulator ADD: Receives the values ​​of inputs IN_1 and IN_2 / , and adds the two's complement of the value of IN_2 / to the value of IN_1 (i.e., subtracting the values ​​of IN_1 and IN_2 / ). The accumulated value is output by OUT.

[0124] Comparator CMP: When the value of input 1 is less than the value of input 2, the output is high; when the value of input 1 is greater than or equal to the value of input 2, the output is low.

[0125] The function of the reminder circuit is: (1) The manufacturer administrator writes the specific number of days before the expiration date, Threshold, into the ROM area of ​​the FPGA card. For example, Threshold=30 means that the user will be reminded 30 days before the license file expires. (2)When License_Type = '0', it indicates that the License file is permanently valid. At this time, Input 1 of JMP = Input 2 of JMP = '0', JMP outputs a high level, which becomes a low level after passing through NOT_1, so that the E terminal of Timer is '0', and Timer has no output because it is disabled. Since the Alarm_sig signal is grounded (weak pull-down), the Alarm_sig outputs a low level by default and no alarm is generated, that is, no expiration reminder is made for the permanently valid License file.

[0126] (3)When License_Type = '1' or '2', a reminder before the expiration of the License file is required. Taking Creator_Time = 2025.9.1 00:00:00, Expired_Time = 2025.11.30 23:59:59, and Threshold = 30 as an example for illustration. Since License_Type = '1' or '2', the E terminal of Timer becomes a high level, enabling Timer to start timing from 2025.9.1 00:00:00; and the output OUT of ADD at this time = 2025.11.30 23:59:59 - 30 = 2025.11.01 00:00:00. CMP_1 compares the current timing time with 2025.11.01 00:00:00. When the current time has not reached 2025.11.01 00:00:00, CMP_1 outputs a high level, which becomes a low level after passing through NOT_2, so that Alarm_sig = '0' and no alarm is generated. If the current time reaches or exceeds 2025.11.01 00:00:00, CMP_1 outputs a low level, making Alarm_sig = '1' and generating an alarm signal. The Alarm_sig signal returns to BMC to remind the user of the expiration time of the License file. The alarm signal of this circuit is always valid within 30 days before the expiration of the License, so it will always remind the user to facilitate the user to renew the fee in time before the expiration.

[0127] (4)When the License is within the validity period, that is, when the output value of Timer has not reached Expired_Date (Q < Expired_Date), after comparison by CMP_2, it outputs a high level, making Valid_sig = '1', indicating that the License file is valid. Similarly, when Q ≥ Expired_Date, Valid_sig = '0', indicating that the License file has exceeded the validity period. At this time, BMC disables the corresponding function module; only after the user renews the fee to obtain a new license period, Valid_sig becomes '1' again.

[0128] In this embodiment, the license file verification task is transferred from the BMC to the FPGA card, thus reducing the memory resources consumed by the BMC and alleviating its burden. It also facilitates license file upgrades and maintenance by the manufacturer, while ensuring security.

[0129] The interface management circuit includes at least one controllable switch circuit for turning on or off the data channel between the baseboard management controller and the internal storage area of ​​the expansion card.

[0130] The interface management circuit in this application refers to a set of digital logic circuits inside the expansion card specifically responsible for managing and controlling the connection and disconnection of the data path between the baseboard management controller and the internal storage area of ​​the expansion card. Its core function is to achieve fine-grained and secure hardware control over external access to internal critical data (such as authentication codes and firmware) under the instructions of the control circuit.

[0131] The controllable switch circuit may include a first controllable switch circuit and a second controllable switch circuit. The first controllable switch circuit is connected between the read-only memory area and the control circuit and is configured to controllably enable or block the reading path of the reference authentication code. The second controllable switch circuit is connected between the random access memory area and the hardware interface and is configured to controllably enable or block the transmission path of the updated firmware file.

[0132] For example, a controllable switching circuit can specifically be a tri-state buffer, which is a digital logic device with three output states: high level, low level, and high impedance. Its output state is controlled by an independent enable terminal. When the enable is active, it acts as a transparent buffer, allowing data to pass through; when the enable is inactive, its output presents a high impedance state, electrically equivalent to a disconnection, thus physically isolating the preceding and following circuits. It is a commonly used and reliable hardware unit for implementing controllable data channels.

[0133] This application establishes data access isolation through the physical on / off characteristics of dedicated hardware circuits (such as tri-state buffers), rather than relying on software permission checks. Once this boundary is established, it cannot be bypassed by software means, providing a more fundamental and reliable security guarantee than software policies.

[0134] Thus, the controllable switching circuit is strategically deployed on the data path between the baseboard management controller and the internal storage area (including read-only memory and random access memory) of the expansion card. This allows the control circuit to precisely enable or disable this data path, achieving two key security controls: first, secure reading control of the reference authentication code, whereby the control circuit only enables the corresponding path after receiving a legitimate startup signal, allowing the reference authentication code to be securely read internally for verification, preventing unauthorized reading; second, secure transmission control of the firmware to be updated, whereby the path is only enabled to securely transmit the authorized firmware image temporarily stored in the random access memory to the BMC for updating after user authentication, preventing unauthorized firmware writing.

[0135] It should be noted that the controllable switching circuit in this application is not limited to a three-state buffer. It can be any digital switching element or circuit combination that can reliably realize both connected and isolated states electrically according to the enable signal (e.g., using a transmission gate, a multiplexer configured as a switch, or a custom circuit with similar functions constructed from logic gates, etc.). As long as the same secure access control purpose can be achieved under the management of the control circuit, it should be regarded as an equivalent or modified implementation of this interface management circuit and fall within the protection scope of this application.

[0136] By introducing interface management circuitry, the expansion card achieves fine-grained access control over its internal critical data assets at the physical level. This is not merely a simple data buffer, but rather the construction of a hardware-enforced security boundary that ensures that only data interactions conforming to strict security policies can occur, fundamentally preventing unauthorized access and tampering, and significantly enhancing the security baseline and reliability of the entire system.

[0137] The control circuit is connected to the hardware interface, read-only storage area, password algorithm circuit, comparison circuit, expansion circuit, reminder circuit and interface management circuit respectively, and is configured to execute the control logic of server security management methods.

[0138] The control circuit is the brain of the expansion card. It is connected to the hardware interface, read-only memory, cryptographic algorithm circuit, comparison circuit, expansion circuit, and alert circuit via internal bus or signal lines. It is configured to execute the overall control logic of the aforementioned server security management method, specifically including: receiving data and signals transmitted by the BMC, coordinating and controlling the orderly operation of other circuits, and transmitting the data and signals generated by each circuit after completing its task (such as verification results, function enable signals, and alarm signals) back to the BMC.

[0139] The expansion card also includes a random access memory (RAM) area, which is volatile memory. Its main function is as a data buffer, temporarily storing license file data and intermediate calculation results transmitted from the BMC, supporting high-speed data processing for various circuit modules. Since the data is lost after a power outage, it is only used temporarily as a data buffer, such as for receiving license file data transmitted from the BMC.

[0140] Embodiments of this application provide a server security management system, the system comprising: The license management subsystem, deployed on the management side, is used to generate and distribute license files that are bound to the server hardware.

[0141] License Management Subsystem: This subsystem is deployed on the management side, i.e., the back-end management environment of the server manufacturer or service provider. Its main function is to respond to server function customization requests from users. Based on the target server hardware identifier (such as product serial number, MAC address), the list of required functionalities, and the usage period specified in the request information, it generates a structured, plaintext authorization data. Subsequently, the system digitally signs the authorization data using its strictly protected private key and encrypts it using a key bound to the target device, ultimately generating a complete and secure license file. After generation, the system is responsible for distributing the file to the corresponding user through secure channels (such as the official website, customer service system).

[0142] At least one expansion card for executing the server security management method of this application is deployed on the user equipment side and connected to the baseboard management controller of the server for verifying the license file generated by the license management subsystem.

[0143] The expansion card is deployed on the user equipment side, i.e., inside each target server requiring controlled functions. It connects to the server's baseboard management controller (BMC) via a physical interface (such as PCIe). This system includes at least one such expansion card. The core function of the expansion card is to act as a local, hardware-based "verification terminal" and "executor," internally containing all the dedicated circuitry for executing the aforementioned server security management methods. It receives the license file from the BMC and independently completes a series of verification steps, including decryption, signature verification, device identity comparison, and validity period check. Only after all verifications are successful will it generate the final function enable signal, triggering the BMC to activate the corresponding server function.

[0144] The license management subsystem uses a private key for digitally signing license documents, which, together with the verification public key used by the expansion card to verify the digital signature, forms an asymmetric key pair.

[0145] The foundation of the system's security and trust lies in the fact that the private key used by the license management subsystem to digitally sign license documents, and the verification public key pre-installed in the read-only memory of each expansion card to verify the digital signature, constitute a cryptographic asymmetric key pair. This means that any license issued by the administrator's private key can only be verified as authentic and trustworthy by the expansion card possessing the corresponding public key.

[0146] The trust that the expansion card places in the public key is established physically (pre-configured, hardened), and cannot be tampered with by the user. This pre-configured key mapping establishes a scalable, online-needed cryptographic trust chain between the administrator (issuer) and a massive number of user devices (verifiers).

[0147] By physically and logically separating authorization issuance from local verification execution, and by using asymmetric cryptography to achieve reliable trust transfer across domains, a server function authorization ecosystem is built that is both easy to centrally manage and can achieve distributed, high-strength security control.

[0148] In a specific example, when a user needs customized functionality, they submit information such as User ID (Custom ID), Product Serial Number (Product SN), required features, and usage period to the manufacturer's customer service system. The customer service system then transmits this information to the manufacturer's operations and maintenance management system, which in turn feeds it back to the license management system. The license management system generates a license file and signs and encrypts it. The signed and encrypted license file is then transmitted to the operations and maintenance management system, and finally to the customer service system. The user obtains the license file through the customer service system, downloads it, and loads it onto the BMC. The BMC then uses the FPGA expansion card to decrypt the license file and verify the signature before the customized functionality can be used. Using an FPGA expansion card facilitates license file verification by the user's BMC and allows the manufacturer to control and manage the license file. Furthermore, a hash operation is performed on the BMC's SEL log, and the hash value is synchronously stored on the FPGA expansion card for backup, preventing users from repudiating the user by tampering with the SEL log and hash value. This application improves the flexibility and security of the BMC system through the FPGA expansion card without affecting the related system functions, and is easy to deploy and implement.

[0149] The BMC customization features in this application can include two types: adding features and deleting features. The following is an example of adding features; please refer to [link / reference]. Figure 10First, the user logs into the manufacturer's official website customer service system. The user submits information through the system, including their User ID (Custom ID), Product Serial Number (Product SN), BMC MAC address, and customized requirements (new features). The Custom ID, Product SN, and BMC MAC address serve as identifiers for the user's product, ensuring its uniqueness. This allows for customized functionality tailored to a specific user's server product, preventing its use on multiple devices or other user products and protecting the user's interests. The submitted information is then transmitted to the manufacturer's operations and maintenance management system.

[0150] For new features added in user-customized requests, i.e. BMC features that users need to purchase, the submitted information also includes: the name of the BMC feature to be purchased, and the required usage period (e.g., 30 days, 60 days, permanent use, etc.).

[0151] The vendor administrator logs into the operation and maintenance management system to obtain the information submitted by the user, and calls the license management system to generate a license file. The license file corresponds one-to-one with the user's server product, and is not displayed in plain text, but in encrypted form, thereby preventing the user from tampering with it.

[0152] After the vendor administrator completes the operation, the license file is transferred to the customer service system through the operation and maintenance management system.

[0153] Users then obtain the license file through the manufacturer's official website customer service system. The user loads the license file into the BMC on the user server, and the BMC calls the FPGA expansion card to decrypt the license file and verify its signature. After successful verification, the BMC activates the customized function, and the user can use the customized function normally within the license period.

[0154] Regarding the control of the FPGA expansion card: the BMC transmits signals and data to the FPGA card, which then verifies the license file and returns the verification result to the BMC. When a user obtains the license file through the manufacturer's official website customer service system, the manufacturer's administrator remotely writes parameters such as the authentication code (Auth_code), the public key of the asymmetric cryptography algorithm (Pub_Key), and the key of the symmetric cryptography algorithm (Key) into the ROM area of ​​the FPGA card via the user's BMC. The FPGA card can only boot normally after the user enters the correct authentication code (Auth_code) into the BMC. Afterwards, the BMC transmits a boot signal to the FPGA card, and the FPGA card's control circuit reads the ROM area to obtain the Key and Pub_Key, and calls the cryptographic algorithm circuit to decrypt the license file and verify the digital signature.

[0155] Please see Figure 11 It consists of the manufacturer's license management system (license document management system).

[0156] The manufacturer's license management system includes an input interface, a license generation circuit, a hash algorithm circuit, a digital signature circuit, an encryption circuit, and a license output circuit.

[0157] (1) Input interface: Receives the request to generate a License file sent by the operation and maintenance management system, as well as the aforementioned CustomID, Product SN and other information.

[0158] (2) License generation circuit: Generates the original license file based on information such as Custom ID and Product SN. The license file can be in JSON or XML format.

[0159] In one specific implementation, the user obtains the license file from the manufacturer's official website customer service system. First, it is loaded into the BMC and the BMC is restarted. Upon startup, the BMC reads the server time for time synchronization. Then, the BMC sends a startup signal (Start_sig='1') to call the FPGA expansion card. The read server Product SN and license file are transferred to the FPGA expansion card's RAM buffer. The control circuit decrypts the license file to obtain its plaintext, then verifies the signature value to determine its legality. Next, it verifies parameters such as the Product SN, BMC MAC, authorized time range, and authorized features to ensure consistency. Only after all verifications pass can the BMC functionalities specified in the license file be used. The control circuit is implemented using VHDL programming. In one specific implementation, as shown... Figure 12 As shown, the specific steps of the server security management method are as follows: The control circuit receives the start signal (Start_sig='1'), Product SN (server product serial number), and other parameters, as well as the license file, transmitted by the BMC, and then decrypts the encrypted License Date part of the license file.

[0160] Specifically, based on the Product SN, the key Key is generated by calling the SHA256 algorithm of the cryptographic algorithm circuit; the Algorithm field of the License file is read to obtain the identifier bit of the symmetric cryptographic algorithm; the symmetric cryptographic algorithm (AES) is called, and the ciphertext License Data is decrypted using the Key to obtain the plaintext License Data, i.e., LicenseData=DECKey(Data_Ciphertext); the control circuit verifies the digital signature of the License file.

[0161] The control circuit verifies the digital signature of the license file by: reading the Algorithm field of the license file to obtain the identifier bits of the digest algorithm and the asymmetric cryptographic algorithm; reading the signature value of the license file, reading the public key from the read-only memory, and calling the asymmetric cryptographic algorithm to verify the signature value (running the asymmetric cryptographic encryption operation) to obtain the hash value, Hash_value, i.e., Hash_value = ENCPub_Key (SignatureValue); that is, hash value = public key encryption (signature value); calling the digest algorithm to calculate the digest value of the license data to obtain the hash value', i.e., hash value' = hash (license data), and comparing it with the hash value. When hash value' = hash value, it means that the license file has not been tampered with and the digital signature verification is successful; when hash value' ≠ hash value, the verification fails. Next, the product category, product serial number, and MAC address of the BMC management port in the license data (plaintext authorization data) are read and compared with the parameters corresponding to the server device sent by the BMC to the FPGA expansion card to determine whether the information obtained from the license file is consistent with the actual information of the server device. The license type, effective date, and expiration date in the license data (plaintext authorization data) are read and compared with the system time on the server to determine whether the license file is within the authorized time range. When license type = '0', it indicates a permanent license, and no expiration check is performed. When license type = '1' or '2', an expiration check is required; if the current system time is earlier than the effective date or later than the expiration date, the verification fails.

[0162] Next, the License Class, ProductSN, and BMC MAC fields from the License Data (plaintext authorization data) are read and compared with the parameters sent by the BMC to the server device of the FPGA expansion card to determine whether the information obtained from the License file is consistent with the actual information of the server device. The License Type, Creator Time, and Expired Date from the License Data are then read and compared with the system time on the server to determine if the License file is within the authorized time range. When License Type='0', it indicates a permanent license, and no expiration check is performed. When License Type='1' or '2', an expiration check is required; if the current system time is earlier than the Creator Time or later than the Expired Date, the verification fails.

[0163] After the license file is verified, the control circuit sends a verification pass signal (Check_sig='1') to the BMC, and then the BMC starts the corresponding function requested by the Feature field in the License Data; if the verification fails, the control circuit sends a verification failure signal (Check_sig='0') to the BMC, the BMC does not start the function corresponding to the Feature, and records it in the BMC's SEL log.

[0164] In another specific implementation, a technical solution for reducing customized features is described.

[0165] For the deletion function requested by users, the user submits the name of the existing BMC function to be deleted through the customer service system; the vendor administrator trims and compiles the BMC source code to generate a simplified BMC firmware binary image file, i.e., the firmware file; then the updated firmware file is updated to the RAM area of ​​the client's FPGA expansion card. The specific process of the client updating the BMC after obtaining the firmware file is described below: like Figure 13As shown, this application sets up a tri-state buffer Tri (first controllable switch circuit) and a bidirectional tri-state buffer Bri_Tri (second controllable switch circuit) in the FPGA expansion card. For Tri, when the enable pin is high (en='1'), the buffer is turned on, and data can be transmitted; when en='0', the buffer is blocked, and data cannot be transmitted. Similarly, for Bri_Tri, the enable pin en1 controls the on / off state of the first data channel; en2 controls the on / off state of the second data channel. The authentication code Auth_code in the ROM and the comparator JMP in the control circuit have the same function as before.

[0166] When the BMC's start signal is valid (Start_sig='1'), Bri_Tri's en1 is valid, and Auth_code can be transmitted to JMP's 2nd terminal; and when the authentication code entered by the user from the Code_in terminal is equal to Auth_code, JMP outputs a high level, controlling Tri's en to be valid, thereby enabling the firmware file in RAM to be transmitted to the BMC.

[0167] Afterwards, the user performs an image update of the BMC system, burning the simplified firmware file into the BMC's Flash memory to replace the old firmware file. After restarting the BMC, the user can use the simplified BMC with the reduced functionality.

[0168] By adding Bri_Tri, data reading from the ROM is only performed by the FPGA expansion card's control circuit when the Start_sig signal is valid. When writing data to the ROM, only the manufacturer's administrator can input a management command (Manage_Code) to enable en2, thus writing data to the ROM. Therefore, the ROM area does not have an interface for read / write operations open to the user, preventing users from tampering with the data in the ROM area.

[0169] The server security management solution provided in this application introduces dedicated hardware, with expansion cards (such as FPGA cards) serving as the trusted verification core. Working in conjunction with the baseboard management controller and cloud-based license management system, it constructs a complete, efficient, and highly secure server function authorization and operation and maintenance management system. Its comprehensive benefits are reflected in multiple aspects, including technology, security, business, and operation and maintenance, as detailed below: Technical implementation: Hardware-level security verification builds a root of trust: Critical security operations such as core license decryption, digital signature verification, and device identity comparison are offloaded from the BMC software layer to a dedicated FPGA expansion card hardware. The solidified logic and tamper-proof nature of the hardware circuitry fundamentally eliminates reverse engineering, debugging attacks, and logic tampering that could occur at the software level. This establishes a physical hardware root of trust for the entire authorization system, achieving a substantial improvement in security.

[0170] Dynamic key binding for cloning and transfer prevention: A mechanism is employed to dynamically generate decryption keys based on the server's unique identifier (product serial number, MAC address) and license version information. This achieves a strong cryptographic binding between the license and specific server hardware (one machine, one license, one key). Even if the license file is copied, it is impossible to generate a correct decryption key on other devices, effectively preventing unauthorized cloning and cross-device reuse of licenses, protecting the interests of manufacturers and paying users.

[0171] Hardware parallel processing enhances efficiency and reliability: The expansion card integrates dedicated comparison circuits and feature expansion circuits, enabling parallel execution of multi-parameter comparisons and multi-function enable signal generation. Compared to the serial execution of BMC software, this hardware parallel processing significantly improves the response speed and throughput of verification and function enable, while reducing the consumption of BMC's general-purpose computing resources. This allows the BMC to focus more on its core out-of-band management tasks, improving the overall reliability and real-time performance of the server management subsystem.

[0172] Independent hardware monitoring enables precise alerts: The built-in alert circuitry operates independently of the main verification process, continuously timing expired licenses and proactively issuing alerts before they expire. This does not rely on the BMC's system task scheduling, ensuring the timeliness and accuracy of the alert function, avoiding missed alerts due to BMC overload or software malfunctions, and improving the proactiveness of operations and maintenance and the user experience.

[0173] Achieve the following at the security level: End-to-end encryption and integrity protection: From data encryption and digital signature during license generation, to transmission, storage, and finally decryption and verification within the expansion card, end-to-end confidentiality and integrity protection is achieved throughout the entire lifecycle. Combined with a verification public key stored securely in hardware, this ensures that authorized information is tamper-proof and forgery-proof.

[0174] Enhanced identity authentication and access control: An independent user authentication code verification step is introduced, forming a two-factor security mechanism together with license verification. Only users who possess a valid license document and enter the correct authentication code in the BMC interface can activate and use the expansion card function, effectively preventing physical contact and unauthorized access.

[0175] Non-repudiable audit trail: By hashing the BMC system event logs and storing the hash base value in the expansion card's read-only storage area, an tamper-proof "audit anchor" is established. This provides server maintenance with reliable and non-repudiable operation logs, enabling clear tracing of the true cause in the event of a failure or dispute. This effectively prevents users from evading responsibility by tampering with logs, protecting the legitimate rights and interests of server manufacturers.

[0176] Fine-grained and flexible feature licensing: Through pre-defined feature enable bitmaps, it supports bit-level fine-grained licensing control over multiple BMC features. Manufacturers can flexibly define and combine feature packages, and users can purchase as needed, realizing a shift from "all or nothing" to "on-demand, fine-grained control," greatly improving the flexibility of licensing strategies and resource utilization efficiency.

[0177] Furthermore, this application enables the software-defined hardware sales of advanced BMC functions. Manufacturers can sell these functions as independently licensed, on-demand subscription services, opening up new revenue streams and enhancing customer loyalty through hardware bundling. For users, this reduces initial procurement costs and achieves a better total cost of ownership. Moreover, the expansion card integrates with the server via a standard interface (such as PCIe) without altering the core BMC hardware design. The license application, issuance, and loading process is clear and user-friendly. For manufacturers, expansion cards can be initialized remotely (writing public keys, authentication codes, etc.) and the license lifecycle can be managed, greatly simplifying on-site deployment and subsequent maintenance complexity and reducing operational costs.

[0178] In summary, this application, through its innovative hardware and software collaborative architecture, not only solves the inherent defects of traditional software licensing schemes in terms of security, flexibility, and auditability, but also creates a new model for server function licensing and operation and maintenance that is secure, efficient, flexible, and easy to manage. It provides key technical support for the server industry's intelligent and service-oriented transformation, and has significant technological advancement and commercial application value.

[0179] like Figure 14 As shown, embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described server security management method embodiments.

[0180] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described server security management method embodiments when it is run.

[0181] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0182] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0183] The foregoing has provided a detailed description of a server security management method, expansion card, and server security management system provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A server security management method characterized by comprising: Applied to an expansion card, the method includes: Upon receiving a scheduling instruction, retrieve the server product serial number and license file; A symmetric decryption key is generated based on the server product serial number and the version information in the license file; The encrypted data in the license file is decrypted using the symmetric decryption key to obtain the authorized plaintext data; The digital signature of the license file is verified based on the verification public key pre-installed in the read-only storage area of ​​the expansion card. In response to successful digital signature verification, it is determined whether the authorized identity information in the authorized plaintext data matches the hardware identity information of the server; In response to the matching, a function enable signal is generated based on the function authorization information in the authorized plaintext data and output to the baseboard management controller to trigger the baseboard management controller to enable the corresponding server function.

2. The server security management method of claim 1, wherein, The response prior to receiving the scheduling instruction includes: Verify whether the authentication code entered by the user is consistent with the reference authentication code preset in the read-only storage area of ​​the expansion card; In response to the base authentication code matching the authentication code entered by the user, the expansion card enters a ready state, enabling the expansion card to respond to the scheduling instructions of the baseboard management controller.

3. The server security management method according to claim 1, characterized in that, The step of receiving a scheduling instruction and obtaining the server product serial number and license file includes: In response to receiving a scheduling instruction from the baseboard management controller, the server product serial number and license document are obtained from the baseboard management controller; The license document is generated based on server function customization information, which includes user identifier, server product serial number, server customized function characteristics, and usage period requirements.

4. The server security management method according to claim 1, characterized in that, The process of generating a symmetric decryption key based on the server product serial number and the version information in the license file includes: The server product serial number is padded with bytes, and the padded server product serial number is segmented to obtain first serial number data and second serial number data. Perform an XOR operation on the first serial number data and the second serial number data to obtain the first intermediate value; A hash operation is performed on the version information in the license file to obtain a second intermediate value; Perform an XOR operation on the first and second intermediate values ​​to obtain the third intermediate value; The third intermediate value is segmented to obtain the fourth and fifth intermediate values; The fourth intermediate value and the fifth intermediate value are XORed to generate the symmetric decryption key.

5. The server security management method according to claim 1, characterized in that, The step of decrypting the encrypted data in the license file using the symmetric decryption key to obtain the authorized plaintext data includes: The symmetric cryptographic algorithm in the signature data of the license file is read, and the encrypted data in the license file is decrypted based on the symmetric cryptographic algorithm and the symmetric decryption key to obtain the authorized plaintext data.

6. The server security management method according to claim 1, characterized in that, The verification of the digital signature of the license file based on the verification public key pre-installed in the read-only storage area of ​​the expansion card includes: Read the algorithm identifier and digital signature value from the signature data of the license document, wherein the algorithm identifier is used to indicate the hash algorithm and asymmetric cryptographic algorithm required for verification; Read the verification public key corresponding to the asymmetric cryptographic algorithm from the verification parameters pre-stored in the read-only memory area of ​​the expansion card; The digital signature value is decrypted based on the verification public key to obtain a first digest value; The authorized plaintext data is hashed according to the hash algorithm indicated by the algorithm identifier to obtain a second digest value; Compare the first summary value with the second summary value; If the first digest value matches the second digest value, the digital signature verification is deemed successful. The digital signature value is generated by performing a digest operation on the authorized plaintext data and then signing it with a private key corresponding to the verification public key pre-stored in the read-only storage area of ​​the expansion card.

7. The server security management method according to claim 1, characterized in that, The step of determining whether the authorized identity information in the authorized plaintext data matches the server's hardware identity information includes: The authorization server identification information extracted from the authorization plaintext data includes the authorized product type, authorized product serial number, and authorized network port address; Obtain the hardware identification information of the current server device from the baseboard management controller. The hardware identification information includes product type, product serial number, and network port address. The authorization server identification information is compared with the hardware identification information; If the authorized server identification information matches the hardware identification information, the server identification verification is deemed successful. Extract the license type and the valid time range of the license indicated by the plaintext authorization data; If the license type is a time-limited license and the current system time is within the authorized validity period, the license validity period verification is deemed successful. When the server identifier verification is successful and the license validity period verification is successful or skipped, it is determined that the authorized identity information in the authorized plaintext data matches the server's hardware identity information.

8. The server security management method according to claim 1, characterized in that, The step of responding to the matching, generating a function enable signal and outputting it to the board management controller based on the function authorization information in the authorized plaintext data, includes: In response to the matching of the authorized identity information in the authorized plaintext data with the server's hardware identity information, a verification pass signal is generated; Extract server-customized feature information from the authorized plaintext data; Based on the server-customized function feature information, generate a function enable signal corresponding to the server-customized function; The verification pass signal and the function enable signal are output to the baseboard management controller to trigger the baseboard management controller to activate the corresponding server function according to the function enable signal.

9. The server security management method according to claim 1, characterized in that, When multiple server functions need to be enabled, generating a function enable signal based on the function authorization information in the authorized plaintext data includes: Extract multiple server-customized feature information from the authorized plaintext data; Based on the customized feature information of the multiple servers, generate multiple functional signals corresponding to the multiple customized functions of the multiple servers; Read the function enable bitmap pre-installed in the read-only memory area of ​​the expansion card. The function enable bitmap contains multiple bits, each bit corresponding to an authorizable server function feature. Based on multiple functional signals, multiple data selector circuits in the expansion card are enabled, so that multiple independent functional enable signals are generated in parallel by the multiple data selector circuits according to the logic values ​​of each bit in the functional enable bitmap. Multiple function enable signals are output to the baseboard management controller so that the baseboard management controller can enable multiple server functions in parallel based on the multiple function enable signals.

10. The server security management method according to claim 1, characterized in that, The method further includes: Extract the license type and the validity period of the license from the plaintext authorization data; In response to the license type being a time-limited license, start the timer in the expansion card; The reminder time point is calculated based on the authorized valid time range and the reminder threshold preset in the read-only storage area of ​​the expansion card. Compare the current timeout of the timer with the reminder time. In response to the current timing time reaching or exceeding the reminder time point, a reminder signal is generated and output to the baseboard management controller.

11. The server security management method according to claim 1, characterized in that, The method further includes: In response to a digital signature verification failure and / or a mismatch between the authorized identity information and the server's hardware identity information, a verification failure signal is generated and output to the baseboard management controller, so that the baseboard management controller records the corresponding system event log; In response to receiving an integrity guarantee request for the system event log initiated by the baseboard management controller, the current hash value of the log is calculated; The current hash value is written to the expansion card as an immutable base value, and the current hash value is returned to the baseboard management controller.

12. The server security management method according to claim 1, characterized in that, The method further includes: In response to receiving a firmware update command from the baseboard management controller and an authentication code entered by the user, the system verifies whether the authentication code entered by the user matches the reference authentication code pre-stored in the expansion card's read-only memory area. In response to the user-input authentication code matching the baseline authentication code pre-installed in the expansion card's read-only memory area, the expansion card's interface management circuit is activated to allow the baseboard management controller to read the pre-installed update firmware file in the expansion card; The updated firmware file is a function downgrade firmware, which is configured to modify the function authorization status inside the expansion card; the modification of the function authorization status inside the expansion card includes clearing the bit corresponding to the function to be deleted in the function enable bitmap or replacing it with a firmware version that does not have the logic for the function to be deleted. The updated firmware file is transferred to the baseboard management controller to complete the flashing process, so that the expansion card loads the updated firmware after restarting and disables the function to be deleted during subsequent function authorization verification.

13. An expansion card, characterized in that, For performing the server security management method as described in any one of claims 1 to 12, the expansion card includes: Hardware interface for data interaction with the baseboard management controller; Read-only storage area is used to store the verification public key, function enable bitmap, and base authentication code; Cryptographic algorithm circuitry, used to perform encryption, decryption, and hash operations; The comparison circuit includes at least one comparator and an AND gate, wherein the output of the comparator is connected to the input of the AND gate, and is used to perform hardware identity information comparison of authorized identity information; The expansion circuit includes at least one data selector with an enable terminal for generating at least one independent function enable signal according to the function enable bitmap. The reminder circuit includes a timer for generating a reminder signal before the license expires; An interface management circuit includes at least one controllable switch circuit for connecting or blocking the data channel between the baseboard management controller and the internal storage area of ​​the expansion card; The control circuit is connected to the hardware interface, read-only storage area, password algorithm circuit, comparison circuit, expansion circuit, reminder circuit and interface management circuit respectively, and is configured to execute the control logic of the server security management method.

14. A server security management system, characterized in that, The system includes: The license management subsystem, deployed on the management side, is used to generate and distribute license files that are bound to the server hardware; At least one expansion card as described in claim 13 is deployed on the user equipment side and connected to the baseboard management controller of the server for verifying the license file generated by the license management subsystem; The license management subsystem uses a private key to digitally sign the license file, which forms an asymmetric key pair with a verification public key pre-installed in the expansion card for verifying the digital signature.

15. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the server security management method as described in any one of claims 1 to 12 when executing the computer program.

Images