Communication apparatus, method and system, device, medium, encryption system and server

Abstract

The present application discloses a communication apparatus, method and system, a device, a medium, an encryption system and a server. The communication apparatus comprises: a platform root of trust connector, arranged on a mainboard of a server and connected to a platform root of trust module; and a controller having an input end connected to the platform root of trust connector and a plurality of output ends connected on a one-to-one basis to a plurality of functional modules to be encrypted, the controller being used for determining a control instruction on the basis of preset encryption requirements, and on the basis of the control instruction, controlling the platform root of trust module to communicate with one or more of said functional modules.

Description

Communication device, method, system, equipment, medium, encryption system and server

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on October 31, 2023, with application number 202311425518.5 and application name “Communication device, method, system, equipment, medium, encryption system and server”, all contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to a communication device, method, system, equipment, medium, encryption system and server. Background Art

[0004] With the rapid development of internet technology, the security and stability of servers, as core components for information processing and transmission, have become crucial issues. In this data-driven era, data encryption and transmission security have attracted widespread attention. To meet this demand, many internet companies are continuously increasing their server deployments to provide more business deployments. However, this presents a challenge: the information stored in servers must be transmitted across the network. Some of this information is sensitive and requires encryption, while some is public. This places higher demands on the confidentiality of server designs to prevent ransomware or unidentified hacker attacks, which could lead to server failure.

[0005] Therefore, a PRoT (Platform Root of Trust) module is usually designed to connect to the PRoT connector on the motherboard to encrypt the various functional modules on the motherboard. Although this method has achieved encryption protection for the server to a certain extent, as the functions of the server continue to increase, the number of functional modules set on the motherboard is also increasing. This means that in order to connect with multiple PRoT modules, multiple PRoT connectors need to be set on the motherboard, which undoubtedly increases the hardware complexity and space requirements of the server. Especially in a limited space, this design may cause a series of problems such as heat dissipation and electromagnetic compatibility of the server.

[0006] Therefore, how to support the connection of more PRoT modules within a limited server space or a limited motherboard layout space has become an urgent problem that needs to be solved by those skilled in the art.

[0007] Summary of the Invention

[0008] According to an embodiment of the present application, in a first aspect, a communication device is provided, including: a platform trusted root connector, which is provided on a mainboard of a server and connected to a platform trusted root module; a controller, whose input end is connected to the platform trusted root connector, and multiple output ends are connected one-to-one with multiple functional modules to be encrypted on the server; and the controller is used to determine a control instruction according to a preset encryption requirement, and control the platform trusted root module to communicate with one or more functional modules to be encrypted according to the control instruction.

[0009] According to an embodiment of the present application, in a second aspect, a communication method is provided, which is applied to the above-mentioned communication device, including: obtaining preset encryption requirements, determining control instructions based on the preset encryption requirements; controlling the platform trust root module to communicate with one or more functional modules to be encrypted according to the control instructions; and triggering the platform trust root module to encrypt data of the functional module to be encrypted.

[0010] According to an embodiment of the present application, in a third aspect, the present application further provides a communication system, which is applied to the communication device of the first aspect mentioned above, including: an acquisition unit, used to obtain preset encryption requirements and determine control instructions according to the preset encryption requirements; a channel control unit, used to control the platform trust root module to communicate with one or more functional modules to be encrypted according to the control instructions; and an encryption unit, used to trigger the platform trust root module to encrypt data of the target encryption functional module.

[0011] According to an embodiment of the present application, in a fourth aspect, the present application further provides an electronic device, including:

[0012] memory for storing computer programs; and

[0013] The controller is configured to implement the steps of the communication method of the second aspect described above when executing a computer program.

[0014] According to an embodiment of the present application, in a fifth aspect, the present application further provides a non-volatile computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a controller, the steps of the communication method of the second aspect as described above are implemented.

[0015] According to the embodiments of the present application, in the sixth aspect, the present application also provides an encryption system, including a platform trust root connector, a platform trust root module, a controller and several functional modules to be encrypted, the functional modules to be encrypted include at least a baseboard management controller, a central processing unit, and a USB chip; the controller controls the platform trust root module to encrypt data with one or more functional modules to be encrypted through the platform trust root connector.

[0016] According to an embodiment of the present application, in a seventh aspect, the present application further provides a server, comprising the encryption system as described in the sixth aspect above.

[0017] The details of one or more embodiments of the present application are set forth in the accompanying drawings and the description below. Other features and advantages of the present application will become apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the prior art and the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0019] FIG1 is a block diagram of a communication device according to one or more embodiments of the present application;

[0020] FIG2 is a detailed schematic diagram of a communication device according to one or more embodiments of the present application;

[0021] FIG3 is a detailed schematic diagram of a communication device according to one or more embodiments of the present application;

[0022] FIG4 is a schematic diagram of an input / output expansion chip according to one or more embodiments of the present application;

[0023] FIG5 is a schematic diagram of a communication method according to one or more embodiments of the present application;

[0024] FIG6 is a schematic diagram of a specific embodiment of a communication method according to one or more embodiments of the present application;

[0025] FIG7 is a schematic diagram of a communication system according to one or more embodiments of the present application;

[0026] FIG8 is a schematic diagram of an electronic device according to one or more embodiments of the present application;

[0027] FIG9 is a schematic diagram of a non-volatile computer-readable storage medium according to one or more embodiments of the present application. DETAILED DESCRIPTION

[0028] The core of this application is to provide a communication device, method, system, equipment, medium, encryption system and server. Only one platform trust root connector is needed to connect the platform trust root module, and the controller is responsible for switching the communication channel between the platform trust root connector and multiple functional modules to be encrypted. In this way, encryption protection of multiple functional modules to be encrypted can be achieved within a limited space, while avoiding the heat dissipation and electromagnetic compatibility problems caused by setting up multiple platform trust root connectors.

[0029] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0030] The present application provides a communication device, as shown in FIG1 , comprising:

[0031] The platform trust root connector 11 is provided on the mainboard of the server and is connected to the platform trust root module;

[0032] The controller 12 has an input end connected to the platform trusted root connector 11 and multiple output ends connected one-to-one with multiple function modules to be encrypted on the server;

[0033] The controller 12 is used to determine a control instruction according to a preset encryption requirement, and control the platform trusted root module to communicate with one or more functional modules to be encrypted according to the control instruction.

[0034] This embodiment describes a communication device that aims to reduce the number of connectors required to connect multiple PRoT modules on a server motherboard, thereby reducing hardware complexity and space requirements.

[0035] Specifically, the platform root of trust connector 11 is located on the server's motherboard and is used to connect to the platform root of trust module. The platform root of trust module is a hardware unit that provides security encryption and authentication functions. The controller 12 is connected to the input of the platform root of trust connector 11 and is also connected to multiple functional modules to be encrypted on the server. The controller 12 has multiple outputs, each of which is connected to a functional module to be encrypted.

[0036] The controller 12 has the following functions: according to the preset encryption requirements, determine the control instructions, and control the platform trust root module to communicate with one or more function modules to be encrypted according to the control instructions. Specifically, the target encryption function module (target encryption function component) can be determined according to the control instructions. The encryption requirements may be based on the specific requirements of the server. It may be that some modules need to be encrypted, while other modules may not be encrypted. This means that different encryption strategies or conditions can be set to select specific function modules that need encryption protection. Then the way to control the platform trust root module to communicate with the target encryption function module can be specifically: control the channel between its own (controller 12) input end and the corresponding output end of the target encryption function module. This means that when the controller 12 determines that it needs to communicate with a specific function module, it will open the corresponding channel so that the platform trust root module can communicate with the target encryption function module.

[0037] The concept of this embodiment is to achieve encryption protection for multiple functional modules on a server by integrating a platform root of trust connector 11 and a controller 12 module. Compared to traditional designs, this communication device simplifies the need to connect multiple PRoT modules to a single platform root of trust connector 11. By configuring the controller 12, encryption protection can be achieved for different functional modules, and communication with the target encryption functional module can be achieved when needed.

[0038] This design reduces the server's hardware complexity and space requirements to a certain extent, and mitigates heat dissipation and electromagnetic compatibility issues caused by connecting multiple PRoT modules. Furthermore, by presetting encryption requirements and configuring the controller 12, the communication device can flexibly adapt to the encryption protection requirements of different servers.

[0039] In some embodiments, the platform trust root module includes multiple types of sub-modules (sub-hardware units), and the controller 12 is specifically used to determine the control instruction according to the type of the sub-module connected to the platform trust root connector 11, and control the platform trust root module to communicate with one or more functional modules to be encrypted according to the control instruction.

[0040] This embodiment further describes in detail the composition of the platform trust root module and the functions of the controller 12. Specifically, the platform trust root module can be composed of multiple types of sub-modules. These sub-modules may have different functions, such as identity authentication, encryption algorithm, etc. The role of the controller 12 is specifically to determine the control instructions based on the type of sub-module connected to the platform trust root connector 11, and then determine the target encryption function module based on the control instructions, and control the channel conduction between its own input end and the output end corresponding to the target encryption function module. In this way, communication between the sub-module connected to the platform trust root and the target encryption function module can be achieved.

[0041] In summary, this embodiment details the components of the platform root of trust module and the role of controller 12. Through the functions of controller 12, the target cryptographic function module is determined based on the different sub-modules, and a channel is established to achieve communication with the platform root of trust module. This communication device can be flexibly applied to different types of platform root of trust modules to achieve secure communication functions.

[0042] In some embodiments, the platform trusted root connector 11 includes a predefined module type identification pin and a communication pin, and the predefined module type identification pin and the communication pin of the platform trusted root connector 11 are both connected to the controller 12;

[0043] The controller 12 is specifically used to determine the type of the sub-module connected to the platform trust root connector 11 according to the state of the predefined module type identification pin, so as to determine the control instruction, and then determine the target encryption function module, and control the channel conduction between its own input end connected to the communication pin and the output end corresponding to the target encryption function module, so as to realize the communication between the sub-module connected to the platform trust root and the target encryption function module.

[0044] This embodiment describes the specific composition and functionality of the platform root of trust connector 11. In this embodiment, the platform root of trust connector 11 includes two components: a predefined module type identification pin (SMB_CPLD) and communication pins (FLEXIO1 and FLEXIO2 in FIG. 2 ). These two pins are connected to the controller 12.

[0045] The predefined module type identification pins are used to determine the type of sub-module connected to the platform root of trust connector 11. By reading the status of these pins, the controller 12 can determine the type of the connected sub-module. The communication pins enable communication between the platform root of trust connector 11 and the target cryptographic function module. The controller 12 establishes a channel between the inputs connected to the communication pins and the corresponding outputs of the target cryptographic function module, thereby enabling communication between the sub-module connected to the platform root of trust and the target cryptographic function module.

[0046] In summary, this embodiment specifically describes the structure and function of the platform root of trust connector 11, and how the controller 12 determines the submodule type and implements communication using predefined module type identification pins and communication pins. This designed communication device can communicate with the target encryption function module based on different submodule types, while providing flexibility and scalability.

[0047] In some embodiments, the controller 12 reuses a complex programmable logic device (CPLD) on a motherboard.

[0048] In this embodiment, the controller 12 can utilize a complex programmable logic device (CPLD) already existing on the motherboard to implement its functions without introducing any new hardware components.

[0049] A programmable logic device (PLD) is an electronic device that can be reconfigured to suit the user's needs. This means it can achieve a variety of different functions by changing the connection and function of its internal circuits.

[0050] In this embodiment, controller 12 can reuse the programmable logic device (PLD) on the mainboard to control and communicate with the target encryption function module. Through programming, controller 12 can determine the target encryption function module based on preset encryption requirements and, by controlling the connection of the PLD, connect the channel between its own input and the corresponding output of the target encryption function module. This effectively enables communication between the platform root of trust module and the target encryption function module.

[0051] By reusing programmable logic devices, hardware costs and complexity can be reduced, and system flexibility and scalability can be improved. This also helps reduce design and development time and improve production efficiency.

[0052] As shown in Figure 4, in some embodiments, the platform trusted root module also includes an input and output expansion chip, the input end of the input and output expansion chip is connected to the platform trusted root connector 11, and the multiple output ends of the input and output expansion chip correspond one-to-one to multiple types of sub-modules. Each output end of the input and output expansion chip is provided with a pull-up resistor and / or a pull-down resistor. When a sub-module is connected to the output end, the level state of the output end connected to the sub-module is a preset state.

[0053] In this embodiment, the platform root of trust module includes an input / output expansion chip. The input end of the input / output expansion chip is connected to the platform root of trust connector 11, while the output end corresponds one-to-one with multiple sub-modules of different types. Each output end is equipped with a pull-up resistor and / or a pull-down resistor. When a sub-module is connected to an output end, the output end is in a predetermined state.

[0054] The function of the controller 12 is to determine the target encryption function module according to the type of sub-module connected to the platform trust root connector 11, and to control the channel conduction between its own input end and the output end corresponding to the target encryption function module to realize the communication between the platform trust root module and the target encryption function module.

[0055] In other words, when a sub-module of a specific type is connected to the platform root of trust connector 11, the controller 12 will identify the sub-module of that type and determine the corresponding target cryptographic function module. The controller 12 then opens the channel corresponding to the target cryptographic function module so that the platform root of trust module can communicate with the target cryptographic function module.

[0056] In Figure 4, four IOs are connected through an input / output expansion chip (an I2C to IO chip, typically using PCA9554 / PCA9555 / CA9554 and other chips), and different sub-modules are distinguished by external pull-up and pull-down resistors.

[0057] This embodiment uses an input / output expansion chip and preset level settings to identify and control the channel conduction of different submodules. This design can flexibly adapt to different types of encryption function modules and ensure effective communication with the platform's root of trust module.

[0058] To solve the above technical problems, the present application further provides a communication method, as shown in FIG5 , which is applied to the above communication device, including:

[0059] S11: Obtaining a preset encryption requirement and determining a control instruction according to the preset encryption requirement;

[0060] The first step in this method is to obtain the preset encryption requirements. This means that a mechanism must be set up in the communication device to obtain the preset encryption requirements, which may be input by the user or automatically specified by other programs or systems. The preset encryption requirements may include a specific encryption algorithm, key length, or other encryption parameters.

[0061] S12: Controlling the platform trusted root module to communicate with one or more to-be-encrypted functional modules according to the control instructions;

[0062] Next, according to the preset encryption requirements, the control instructions are determined, and then the target encryption function module to be encrypted can be determined. In the communication device, there may be multiple encryption function modules to be selected, and according to the preset requirements, the target encryption function module, that is, the module to be encrypted, needs to be determined.

[0063] Then, the channel between the input terminal of the controller 12 and the corresponding output terminal of the target encryption function module is controlled to be conductive. This means that in the communication device, there must be a mechanism or interface that can connect the input of the controller 12 to the output of the target encryption function module to establish a data transmission channel. In this way, data flow from the controller 12 to the target encryption function module is realized.

[0064] S13: Trigger the platform trust root module to encrypt data of one or more functional modules to be encrypted.

[0065] Finally, the platform root of trust module is triggered to encrypt data from one or more function modules to be encrypted (i.e., the target encryption function modules described in the above embodiments). Once the channel is established, the controller 12 triggers the platform root of trust module in some way to encrypt data from the target encryption function modules. This may involve invoking an encryption algorithm and using the corresponding key to ensure that the target encryption function module correctly encrypts the data to achieve secure communication.

[0066] In summary, this embodiment describes a communication method that uses preset encryption requirements to identify a target encryption function module and, by controlling the controller 12 and channel connectivity, triggers the platform root of trust module to encrypt data in the target encryption function module. This method ensures that during communication, the communication device can protect and securely transmit data according to specific encryption requirements and function selections.

[0067] In some embodiments, obtaining the preset encryption requirement includes:

[0068] Obtain the status of the pins connecting the platform trusted root connector 11 and the controller 12;

[0069] The preset encryption requirement is determined based on the status of the pin.

[0070] This embodiment provides a detailed description of a method for obtaining preset encryption requirements. In this embodiment, obtaining the preset encryption requirements involves the following steps: First, detecting the status of the pin connecting the platform trust root connector 11 to the controller 12. By detecting the status of the pin, information about the platform trust root connection can be obtained. Second, the preset encryption requirements are determined based on the status of the pin. This means that based on the status of the pin, the specific requirements of the required encryption function, such as the encryption algorithm, key length, etc., can be determined. This method of determining the preset encryption requirements by detecting the pin status can ensure that the encryption function is configured according to actual needs and environment, enhancing the flexibility and customizability of the system.

[0071] In some embodiments, before obtaining the status of the pin connecting the platform trusted root connector 11 and the controller 12, the method further includes:

[0072] Determine whether the platform trust root module is connected to the platform trust root connector 11;

[0073] If connected, the process proceeds to the step of obtaining the status of the pins connecting the platform trusted root connector 11 and the controller 12 .

[0074] This embodiment describes a step of obtaining a preset encryption requirement in an embodiment. In this embodiment, it is first necessary to determine whether the platform trust root module is connected to the platform trust root connector 11. If the connection exists, the operation of obtaining the preset encryption requirement can be further performed.

[0075] By obtaining the status of the pins connecting the platform root of trust connector 11 and the controller 12, the connection status between them can be understood. Based on the pin status, the preset encryption requirements can be determined. The pin status may contain information such as control signals or the module type of the connected sub-module. By analyzing this information, the relevant preset encryption requirements can be determined.

[0076] Therefore, this embodiment provides a method for obtaining preset encryption requirements, which involves determining the connection status between the platform trust root module and the platform trust root connector 11, and obtaining the status of the pin connecting the platform trust root connector 11 and the controller 12 based on the connection status to determine the preset encryption requirements.

[0077] In some embodiments, it further includes:

[0078] The first pin connecting the platform trusted root connector 11 and the controller 12 is predefined as a presence determination pin;

[0079] Then, determining whether the platform trust root module is connected to the platform trust root connector 11 includes:

[0080] Whether the platform trusted root module is connected to the platform trusted root connector 11 is determined according to the pin status of the presence determination pin.

[0081] This embodiment describes a newly added additional step for determining whether the platform root of trust module is connected to the platform root of trust connector 11. The purpose of this step is to ensure that the status of the pin connecting the platform root of trust connector 11 and the controller 12 is correctly obtained.

[0082] In this embodiment, the first pin connecting the platform trusted root connector 11 and the controller 12 is predefined as a presence determination pin. The state of the presence determination pin can be used to determine whether the platform trusted root module is connected to the platform trusted root connector 11.

[0083] Therefore, in the first step, a pin status check is performed to determine whether the platform trusted root module is connected to the platform trusted root connector 11. This can be achieved by reading the pin status of a presence determination pin. If the pin status of the presence determination pin indicates that the platform trusted root module is connected to the platform trusted root connector 11, then the step of obtaining the pin status of the pin connecting the platform trusted root connector 11 to the controller 12 can be continued. If the pin status of the presence determination pin indicates that the platform trusted root module is not connected to the platform trusted root connector 11, then the execution of this communication method can be terminated or appropriate processing measures can be taken.

[0084] In some embodiments, determining whether the platform root of trust module is connected to the platform root of trust connector 11 according to the pin status of the presence determination pin includes:

[0085] Whether the platform trusted root module is connected to the platform trusted root connector 11 is determined according to the level state of the presence determination pin.

[0086] In this embodiment, it is pointed out that whether the platform root of trust module is connected to the platform root of trust connector 11 is determined based on the pin state of the presence determination pin. Specifically, by observing the level state of the presence determination pin, it can be determined whether the platform root of trust module has been successfully connected to the platform root of trust connector 11.

[0087] Presence pins are typically a set of specific pins used to indicate whether a component or module is plugged in or connected. These pins typically have two states, such as high and low. When the platform root of trust module is successfully connected to the platform root of trust connector 11, the level state of these pins changes.

[0088] By monitoring the level status of the presence determination pin, it is possible to determine whether the platform root of trust module is connected to the platform root of trust connector 11. If the level status of the presence determination pin is consistent with a predefined connection status, that is, if the connection condition is met, it can be confirmed that the platform root of trust module is connected to the platform root of trust connector 11.

[0089] The purpose of this step is to ensure that the connection between the platform root of trust module and the controller 12 is normal. In subsequent operations, the platform root of trust module will encrypt data from the target encryption function module, which requires ensuring effective communication between the platform root of trust module and the controller 12. Therefore, by detecting the level status of the in-position determination pin, it is possible to confirm whether the platform root of trust module is correctly connected, thereby ensuring the accuracy and reliability of subsequent encryption processing operations.

[0090] In some embodiments, the platform root of trust module includes multiple types of sub-modules, including:

[0091] The second pin for connecting the platform trusted root connector 11 and the controller 12 is predefined as a module type identification pin;

[0092] Then, the preset encryption requirements are determined based on the pin status, including:

[0093] Determine the type of the sub-module connected to the platform trusted root connector 11 according to the status of the module type identification pin;

[0094] The preset encryption requirements are determined based on the determined sub-module type.

[0095] This embodiment describes the structure and functionality of a platform root of trust module. The platform root of trust module includes multiple sub-module types and a pin for module type identification. The status of the pin can be used to determine the type of sub-module connected to the platform root of trust connector 11, thereby determining the preset encryption requirements.

[0096] In this embodiment, the platform root of trust module is designed to provide security and encryption functions. It contains multiple sub-modules, each of which may have different encryption functions or capabilities. To determine which sub-module is actually being used, a pin is assigned as a module type identification pin.

[0097] By reading the state of the module type identification pin, the type of sub-module connected to the platform root of trust connector 11 can be determined. Based on the determined sub-module type, the preset encryption requirements can be determined. This means that different sub-module types may require different encryption functions. Therefore, determining the preset encryption requirements based on the sub-module type ensures that the correct encryption function module is used.

[0098] In some embodiments, determining the type of the sub-module connected to the platform trusted root connector 11 according to the state of the module type identification pin includes:

[0099] The type of the sub-module connected to the platform trusted root connector 11 is determined according to the level state of the module type identification pin.

[0100] This embodiment determines the type of the sub-module connected to the platform trusted root connector 11 by identifying the status of the module type pin.

[0101] In this embodiment, the platform trusted root module includes multiple types of sub-modules, and the second pin connecting the platform trusted root connector 11 and the controller 12 is predefined as a module type identification pin.

[0102] By detecting the level state of the module type identification pin, the type of the sub-module connected to the platform trusted root connector 11 can be determined. According to different level states, the sub-modules can be classified into different types.

[0103] This method of determining the submodule type can help the system select the appropriate preset encryption function based on different requirements. For example, if the submodule is determined to be type A, the system can perform corresponding configuration and operation based on the preset encryption requirements of type A.

[0104] This approach provides an efficient way to determine preset encryption requirements based on different module types, thereby achieving a more flexible and intelligent communication system.

[0105] In some embodiments, determining the type of the sub-module connected to the platform trusted root connector 11 according to the level state of the module type identification pin includes:

[0106] Determine the identity of the submodule connected to the platform trusted root connector 11 according to the level state of the module type identification pin;

[0107] The type of the sub-module connected to the platform trusted root connector 11 is determined according to the determined identity identifier.

[0108] This embodiment involves determining the type of a sub-module connected to the platform trusted root connector 11 based on the level of a module type identification pin. Specifically, this embodiment determines the identity of the sub-module connected to the platform trusted root connector 11 by detecting the level of the module type identification pin, and then determines the type of the sub-module based on the determined identity.

[0109] In this embodiment, the platform root of trust module includes multiple sub-modules. A second pin connecting the platform root of trust connector 11 to the controller 12 is predefined as a module type identification pin. When the communication device is operating, the level of this pin changes. Based on this level change, the identity of the sub-module connected to the platform root of trust connector 11 can be inferred.

[0110] Once the submodule's identity is determined, the specific type of the submodule can be determined based on the identity. This type determination helps determine the preset encryption requirements of the target encryption function module that communicates with the communication device.

[0111] This embodiment enables, in a communication device, the determination of the type of submodule connected to the platform trusted root connector 11 based on the level of the module type identification pin, and, based on this, the determination of the preset encryption requirements of the target encryption function module communicating with the communication device. This implementation helps better meet specific encryption requirements and improves the security and reliability of the communication device.

[0112] In some embodiments, it further includes:

[0113] Establish in advance the correspondence between the level status of the module type identification pin and the identity identifier of each sub-module;

[0114] Then, the identity of the sub-module connected to the platform trusted root connector 11 is determined according to the level state of the module type identification pin, including:

[0115] The identity of the sub-module connected to the platform trusted root connector 11 is determined according to the level status and the corresponding relationship of the module type identification pin.

[0116] In the embodiment, a correspondence between the level state of the module type identification pin and the identity of each sub-module is pre-established. Based on this correspondence, the identity of the sub-module connected to the platform trusted root connector 11 can be determined.

[0117] The purpose of this embodiment is to better determine the preset encryption requirements, thereby enabling customization of the encryption function of the communication device. In this embodiment, the platform trust root module includes multiple types of sub-modules, and the second pin connecting the platform trust root connector 11 to the controller 12 is pre-defined as a module type identification pin.

[0118] According to the description of this embodiment, the correspondence between the level state of the module type identification pin and the identity of each sub-module is pre-established. This means that for each sub-module, its type can be determined according to the level state corresponding to its identity.

[0119] In practical applications, the module type identification pin may have multiple potential levels. For example, a high level and a low level may represent different types of sub-modules. Based on a pre-established correspondence, the identity of the sub-module connected to the platform trusted root connector 11 can be determined based on the module type identification pin's level.

[0120] As shown in Table 1, Table 1 shows the correspondence between the level status of the module type identification pin and the identity identifier of each sub-module.

[0121] Table 1

[0122] In summary, this embodiment pre-establishes a correspondence between the level state of the module type identification pin and the identity of each sub-module. This allows the identity of the sub-module connected to the platform trusted root connector 11 to be determined based on the level state of the module type identification pin. This helps accurately define preset encryption requirements, thereby enabling customized encryption functionality for the communication device.

[0123] In some embodiments, further comprising:

[0124] The third pin and the fourth pin of the platform trusted root connector 11 are predefined as two communication pins;

[0125] Then, according to the control instructions, the platform trust root module is controlled to communicate with one or more function modules to be encrypted, including:

[0126] The target encryption function module is determined according to the control instruction, and the two data transmission pins corresponding to the target encryption function module in the control controller 12 are connected to the two communication pins of the platform trusted root connector 11 in a one-to-one correspondence.

[0127] In this embodiment, the pin configuration of the platform trust root connector 11 is additionally defined. The third pin and the fourth pin are defined as two communication pins. According to this configuration, the two data transmission pins in the controller 12 are respectively connected to the communication pins of the target encryption function module in a one-to-one correspondence. Then, after determining the target encryption function module, it is only necessary to control the data transmission pin in the controller 12 that is connected to the target encryption function module and the communication pin on the platform trust root connector 11 to connect them, so as to realize the connection between the platform trust root connector 11 and the target encryption function module, and then the platform trust root module can communicate with the target encryption function module by itself, and can effectively perform encryption processing. This configuration can meet the requirements of the communication device for encryption functions and provide a secure encrypted communication environment.

[0128] In some embodiments, controlling the platform trusted root module to communicate with one or more to-be-encrypted functional modules according to control instructions includes:

[0129] The controller 12 controls the channel conduction between its own input end and the output ends corresponding to one or more functional modules to be encrypted in a transparent transmission or conversion manner according to the control instruction, so that the platform trust root module communicates with the one or more functional modules to be encrypted.

[0130] This embodiment describes a method for controlling the channel between the input terminal of the controller 12 and the output terminal of the function module to be encrypted in a communication device. The method can be implemented by transparent transmission or conversion.

[0131] The transparent transmission mode refers to the controller 12 directly transferring the data received at the input end to the output end of the target encryption function module, achieving lossless data transmission. This mode is similar to direct data transmission, and the controller 12 does not process or modify the data.

[0132] Another way is conversion, which means that the controller 12 processes or modifies the received data before passing it to the output of the target encryption function module. This may include conversion of data format or protocol to ensure that the data can be correctly processed by the target encryption function module.

[0133] Through the above method, the controller 12 can effectively connect its own input end and the output end corresponding to the encrypted functional module to be encrypted, realize the communication between the platform trust root module and one or more encrypted functional modules, and ensure that the data can be processed and encrypted according to the preset encryption requirements.

[0134] In some embodiments, after controlling the platform trusted root module to communicate with one or more to-be-encrypted function modules according to the control instruction, the method further includes:

[0135] Trigger a log recording operation, where the log includes at least the current time and the identifier of the currently connected channel.

[0136] In this embodiment, the log recording operation is triggered after the channel is connected. In a specific implementation, the log recording operation must at least include the current time and the identifier of the current connected channel.

[0137] Logging is a method for recording system operation status. In this technical solution, the system automatically triggers a logging operation when the channel between the input terminal of the control controller 12 and the corresponding output terminal of the target encryption function module is connected. The recorded content includes two main elements: the current time and the identifier of the currently connected channel.

[0138] The current time represents the timestamp of the log record, marking a specific point in time for subsequent tracking and analysis. The current time can be obtained using the existing system clock or other time synchronization mechanisms and recorded in the log in a specific format.

[0139] The currently active channel ID identifies the specific channel that triggered the logging operation. The channel ID can be a unique number, name, or other identifier to ensure that each channel is uniquely identified. By using the channel ID, you can accurately locate and track the operation of each active channel during subsequent analysis.

[0140] This logging helps system administrators and developers understand the system's operational status, including the time and specific channels that were connected. By recording logs, we can better manage and maintain the system, identify and resolve potential issues promptly, and improve system reliability and security.

[0141] In some embodiments, after controlling the platform trusted root module to communicate with one or more to-be-encrypted function modules according to the control instruction, the method further includes:

[0142] Verify whether the currently connected channel can transmit data normally;

[0143] If yes, the process proceeds to the step of triggering the platform trust root module to encrypt the data of one or more function modules to be encrypted; otherwise, an exception message is output.

[0144] This embodiment describes further operations after the channel between the input end of the control controller 12 and the output end corresponding to one or more functional modules to be encrypted that need to be encrypted is turned on. Specifically, after the channel is turned on, the controller 12 will verify the channel. The purpose of this verification is to ensure that the channel is working properly and can successfully transmit data. If the verification result shows that the channel can transmit data normally, the system will proceed to the next step, that is, triggering the platform trust root module to encrypt the data of the functional modules to be encrypted that need to be encrypted. This means that the system has confirmed the reliability of the channel and started to process the data of the functional modules to be encrypted that need to be encrypted. If the verification result shows that the channel cannot transmit data normally, the system will output an exception message. This exception message may indicate that there is a fault or other problem with the current channel and encryption processing cannot continue. By outputting the exception message, the user or technician can be prompted to troubleshoot or repair the problem.

[0145] In summary, this embodiment describes the subsequent operations after the channel is established, including verifying whether the channel can transmit data normally, performing encryption processing, and outputting exception information when an exception occurs. These steps can ensure the reliability and security of the system during the data encryption process.

[0146] In some embodiments, the method is specifically applied to the controller 12 in the communication device, and triggering the platform root of trust module to encrypt data of the encrypted functional module to be encrypted includes:

[0147] Receiving data to be encrypted generated by a to-be-encrypted function module that needs to be encrypted;

[0148] Transmit the data to be encrypted to the platform trusted root connector 11 through its own conductive channel, so that the platform trusted root module obtains the data to be encrypted;

[0149] Trigger the platform's root of trust module to encrypt the data to be encrypted;

[0150] Obtain the encrypted data sent by the platform trust root module through the platform trust root connector 11;

[0151] The encrypted data is transmitted to the encryption module.

[0152] This embodiment describes the functions of a controller 12 in a communication device. The controller 12 uses a communication method to implement encryption processing of data of a function module to be encrypted.

[0153] First, the method includes receiving the encrypted data generated by the encrypted functional module to be encrypted. These data may contain sensitive information that needs to be encrypted. Next, the method transmits the encrypted data to the platform trust root connector 11 through the channel that is conducted by itself. The platform trust root connector 11 is an interface connected to the platform trust root module for data transmission. Once the encrypted data is transmitted to the platform trust root connector 11, the method triggers the platform trust root module to encrypt the encrypted data. The platform trust root module is the module with the highest trust level and is responsible for securely encrypting the data. After the encryption is completed, the platform trust root module will send the encrypted data back through the platform trust root connector 11. Then, the method transmits the encrypted data to the encrypted functional module to be encrypted.

[0154] In summary, this embodiment describes an encryption process implemented by controller 12. When transmitting data, controller 12 maintains a connection with the platform's root of trust module and triggers it to encrypt the data. This enhances the security of the communication device and ensures that sensitive information is protected during transmission.

[0155] In a specific embodiment, as shown in Figures 2 and 3, the platform trust root connector 11 generally reuses an M.2M-Key type connector. This connector is a mature connector commonly used in the industry and has a low cost. Baseboard management controller: a management and control center commonly used by servers, used to manage network information data and other management. USB (Universal Serial Bus) chip: a PCIe (Peripheral Component Interconnect Express, peripheral component interconnection standard) to USB chip commonly used by servers. In this embodiment, it refers to a PCIe to USB2.0 chip, which converts out USB D+ / D- signals. The implementation process of this embodiment is briefly described as follows:

[0156] The conventionally designed platform trusted root connector 11 on the motherboard can only support PFR (Platform Firmware Resilience) and BIOS TPM (BIOS Trusted Platform Module) modules. In this embodiment, self-definition is performed by modifying the definition of two pins of the platform trust root connector 11, setting the signals of these two pins to FLEXIO1 and FLEXIO2 (communication pins), and connecting the signals of these two pins to the complex programmable logic device CPLD of the motherboard. The motherboard CPLD and the baseboard management controller are interconnected with TPM_I2C signals (specifically TPM_I2C_SCL and TPM_I2C_SDA) and UART signals (specifically UART_TX and UART_RX); the central processing unit and the USB chip are interconnected, and the central processing unit outputs PCIe signals (this PCIe signal is a general term, which can be x1, x2, x4 bandwidth, and the rate can be Gen3, Gen4, Gen5) to the USB chip, which converts them into USB2.0 signals (USB_D+ and USB_D-), and these USB2.0 signals are connected to the motherboard CPLD. The other end of the central processing unit is connected to the platform trust root connector 11 for transmitting the CPU_TPM_SPI signal. The platform trust root connector 11 is also connected to the firmware of the basic input and output system to transmit the BIOS_SPI signal; the platform trust root connector 11 is connected to the firmware of the marine management controller to transmit the BMC_SPI signal.

[0157] As shown in Figure 6, the motherboard CPLD uses the PROT_PRSNT# signal and the SMB_CPLD signal on the platform root of trust connector 11 to perform logical judgment. The identification logic is as follows: First, the CPLD recognizes the presence of the PRoT module. Then, by reading the BOARD ID on the PRoT module and using the PROT module comparison table corresponding to the BOARD ID stored in the CPLD, it identifies the PRoT module type. After determining the corresponding PROT module type, the CPLD switches one of the UART, TPM I2C, and USB signals to the FLEXIO1 and FLEXIO2 pins. This allows the CPLD to implement channel switching, thereby enabling support for multiple PRoT modules.

[0158] To solve the above technical problems, the present application further provides a communication system, as shown in FIG7 , which is applied to the above communication device and includes:

[0159] An acquiring unit 71 is configured to acquire a preset encryption requirement and determine a control instruction according to the preset encryption requirement;

[0160] A channel control unit 72 is configured to control the platform trusted root module to communicate with one or more function modules to be encrypted according to control instructions;

[0161] The encryption unit 73 is used to trigger the platform trusted root module to encrypt the data of one or more functional modules to be encrypted.

[0162] In some embodiments, the acquisition unit 71 includes:

[0163] A pin status acquisition unit, used to obtain the status of the pin connecting the platform trust root connector and the controller;

[0164] The requirement determination unit is used to determine the preset encryption requirement according to the status of the pin.

[0165] In some embodiments, it further includes:

[0166] The connection determination unit is used to determine whether the platform trust root module is connected to the platform trust root connector, and feed back the output result to the pin status acquisition unit.

[0167] In some embodiments, it further includes:

[0168] A first predefined unit is used to predefine a first pin connected to the platform trusted root connector and the controller as a presence determination pin;

[0169] Then, the connection determination unit is specifically used to determine whether the platform trusted root module is connected to the platform trusted root connector according to the level state of the in-position judgment pin, and feed back the output result to the pin state acquisition unit.

[0170] In some embodiments, the platform root of trust module includes multiple types of sub-modules, including:

[0171] A second predefined unit is used to predefine a second pin for connecting the platform trusted root connector to the controller as a module type identification pin;

[0172] Then, the requirement determination unit is specifically used to determine the type of the sub-module connected to the platform trusted root connector according to the level state of the module type identification pin, and determine the preset encryption requirement according to the determined sub-module type.

[0173] In some embodiments, the requirement determination unit is specifically used to determine the identity of the sub-module connected to the platform trust root connector based on the level state of the module type identification pin; determine the type of the sub-module connected to the platform trust root connector based on the determined identity; and determine the preset encryption requirement based on the determined type of the sub-module.

[0174] In some embodiments, it further includes:

[0175] A third pre-definition unit is used to pre-establish a correspondence between the level state of the module type identification pin and the identity identifier of each sub-module;

[0176] Then, the requirement determination unit is specifically used to determine the identity of the sub-module connected to the platform trust root connector according to the level status and corresponding relationship of the module type identification pin, determine the type of the sub-module connected to the platform trust root connector according to the determined identity, and determine the preset encryption requirement according to the determined type of the sub-module.

[0177] In some embodiments, further comprising:

[0178] a fourth predefined unit, configured to predefine a third pin and a fourth pin of the platform trusted root connector as two communication pins;

[0179] Then, the channel control unit 72 is specifically used to determine the target encryption function module according to the control instruction, and control the two data transmission pins corresponding to the target encryption function module in the controller and the two communication pins of the platform trust root connector to be connected one by one.

[0180] In some embodiments, the channel control unit 72 is specifically used to control the channel conduction between the input end of the controller 12 and the output end corresponding to one or more functional modules to be encrypted in a transparent transmission or conversion manner according to the control instruction, so that the platform trust root module can communicate with one or more functional modules to be encrypted.

[0181] In some embodiments, further comprising:

[0182] The log unit is used to trigger a log recording operation. The log includes at least the current time and the identifier of the currently connected channel.

[0183] In some embodiments, further comprising:

[0184] The verification unit is used to verify whether the currently connected channel can transmit data normally; if so, it enters the step of triggering the platform trust root module to encrypt the data of one or more functional modules to be encrypted; otherwise, it outputs an exception message.

[0185] In some embodiments, the encryption unit 73 is specifically used to receive data to be encrypted generated by one or more functional modules to be encrypted; transmit the data to be encrypted to the platform trust root connector through its own conductive channel, so that the platform trust root module obtains the data to be encrypted; trigger the platform trust root module to encrypt the data to be encrypted; obtain the encrypted data sent by the platform trust root module through the platform trust root connector; and transmit the encrypted data to one or more functional modules to be encrypted.

[0186] For an introduction to the communication system, please refer to the above embodiments, which will not be described in detail in this application.

[0187] To solve the above technical problems, the present application further provides an electronic device, as shown in FIG8 , comprising:

[0188] Memory 81, for storing computer programs;

[0189] The controller 12 is configured to implement the steps of the communication method described above when executing a computer program.

[0190] For an introduction to the electronic device, please refer to the above embodiments, and this application will not go into details here.

[0191] To solve the above technical problems, the present application also provides a non-volatile computer-readable storage medium 90. As shown in FIG9 , the non-volatile computer-readable storage medium 90 stores a computer program 91. When the computer program 91 is executed by the controller 12, the steps of the communication method described above are implemented.

[0192] For an introduction to the non-volatile computer-readable storage medium, please refer to the above embodiments, and this application will not go into details here.

[0193] To solve the above technical problems, the present application also provides an encryption system, including a platform trust root connector, a platform trust root module, a controller and several functional modules to be encrypted, the functional modules to be encrypted at least including a baseboard management controller, a central processing unit, and a USB chip;

[0194] The controller controls the platform trust root module to encrypt data with one or more function modules to be encrypted through the platform trust root connector.

[0195] For an introduction to the encryption system, please refer to the above embodiments, which will not be described in detail in this application.

[0196] To solve the above technical problems, the present application also provides a server, including the encryption system as described above.

[0197] For an introduction to the server, please refer to the above embodiment, and this application will not go into details here.

[0198] It should also be noted that, in this specification, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus comprising the element.

[0199] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present application. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A communication device, characterized in that: include: A platform trust root connector is provided on the mainboard of the server and is connected to the platform trust root module; A controller, wherein an input end is connected to the platform trust root connector, and multiple output ends are connected one-to-one with multiple to-be-encrypted function modules on the server; as well as The controller is used to determine a control instruction according to a preset encryption requirement, and control the platform trusted root module to communicate with one or more of the function modules to be encrypted according to the control instruction.

2. The communication device according to claim 1, wherein: The platform trusted root module includes multiple types of sub-modules, and the controller is used to determine a control instruction according to the type of the sub-module connected to the platform trusted root connector, and control the platform trusted root module to communicate with one or more of the functional modules to be encrypted according to the control instruction.

3. The communication device according to claim 2, wherein: The platform trusted root module also includes an input / output extension chip, the input end of the input / output extension chip is connected to the platform trusted root connector, the multiple output ends of the input / output extension chip correspond one-to-one to the multiple types of sub-modules, each of the output ends of the input / output extension chip is provided with a pull-up resistor and / or a pull-down resistor, and when the output end is connected to a sub-module, the level state of the output end connected to the sub-module is a preset state.

4. A communication method, characterized in that: The communication device according to any one of claims 1 to 3 comprises: Obtaining a preset encryption requirement, and determining a control instruction according to the preset encryption requirement; Controlling the platform trusted root module to communicate with one or more to-be-encrypted functional modules according to the control instructions; and The platform trusted root module is triggered to encrypt the data of the function module to be encrypted.

5. The communication method according to claim 4, characterized in that: Get preset encryption requirements, including: Obtaining a status of a pin connecting the platform trusted root connector and the controller; and The preset encryption requirement is determined according to the state of the pin.

6. The communication method according to claim 5, characterized in that: Before obtaining the status of the pin connecting the platform trusted root connector and the controller, the method further includes: Determining whether the platform trusted root module is connected to the platform trusted root connector; and In response to the platform trusted root module being connected to the platform trusted root connector, a step of obtaining a state of a pin connecting the platform trusted root connector to the controller is entered.

7. The communication method according to claim 6, characterized in that: Also includes: Predefine a first pin connecting the platform trusted root connector and the controller as a presence determination pin; as well as Determining whether the platform trusted root module is connected to the platform trusted root connector includes: Determine whether the platform trusted root module is connected to the platform trusted root connector according to the level state of the presence determination pin.

8. The communication method according to claim 5, characterized in that: The platform trust root module includes multiple types of sub-modules, including: predefine a second pin for connecting the platform trusted root connector to the controller as a module type identification pin; and Determining the preset encryption requirement according to the state of the pin includes: The type of the sub-module connected to the platform trusted root connector is determined according to the level state of the module type identification pin.

9. The communication method according to claim 8, characterized in that: Determining the type of the sub-module connected to the platform trusted root connector according to the level state of the module type identification pin includes: Determining the identity of the sub-module connected to the platform trusted root connector according to the level state of the module type identification pin; and The type of the sub-module connected to the platform trusted root connector is determined according to the determined identity identifier.

10. The communication method according to claim 9, characterized in that: Also includes: Pre-establishing a correspondence between the level state of the module type identification pin and the identity identifier of each sub-module; as well as Determining the identity of the submodule connected to the platform trusted root connector according to the level state of the module type identification pin includes: The identity of the sub-module connected to the platform trusted root connector is determined according to the level state of the module type identification pin and the corresponding relationship.

11. The communication method according to claim 4, characterized in that: Also includes: pre-define the third pin and the fourth pin of the platform trusted root connector as two communication pins; as well as Controlling the platform trust root module to communicate with one or more to-be-encrypted function modules according to the control instruction includes: Determine the target encryption function module according to the control instruction, and control the two data transmission pins corresponding to the target encryption function module in the controller and the two communication pins of the platform trust root connector to pair with each other. should be connected.

12. The communication method according to claim 4, characterized in that: Controlling the platform trust root module to communicate with one or more to-be-encrypted function modules according to the control instruction includes: The controller controls the channel conduction between its own input end and the output ends corresponding to one or more functional modules to be encrypted in a transparent transmission or conversion manner according to the control instruction, so that the platform trusted root module communicates with one or more functional modules to be encrypted.

13. The communication method according to claim 12, characterized in that: After the platform trust root module communicates with one or more to-be-encrypted function modules according to the control instruction, the method further includes: A log recording operation is triggered, wherein the log includes at least the current time and the identifier of the currently connected channel.

14. The communication method according to claim 12, characterized in that: After the platform trust root module communicates with one or more to-be-encrypted function modules according to the control instruction, the method further includes: Verify whether the currently turned-on channel is transmitting data normally; and In response to the currently turned-on channel transmitting data normally, the step of triggering the platform trusted root module to encrypt the data of the functional module to be encrypted is entered; in response to the currently turned-on channel transmitting data abnormally, abnormal information is output.

15. The communication method according to any one of claims 4 to 14, characterized in that: The method is specifically applied to a controller in the communication device, triggering the platform trusted root module to perform encryption processing on the data of the to-be-encrypted functional module, including: Receiving the data to be encrypted generated by the function module to be encrypted; Transmitting the data to be encrypted to the platform trusted root connector through the self-conducting channel, so that the platform trusted root module obtains the data to be encrypted; Triggering the platform trusted root module to encrypt the data to be encrypted; Obtaining the encrypted data sent by the platform trusted root module through the platform trusted root connector; and The encrypted data is transmitted to the function module to be encrypted.

16. A communication system, characterized in that: The communication device according to any one of claims 1 to 3 comprises: An acquisition unit, used to acquire a preset encryption requirement and determine a control instruction according to the preset encryption requirement; A channel control unit, used for controlling the platform trusted root module to communicate with one or more to-be-encrypted functional modules according to the control instruction; and The encryption unit is used to trigger the platform trust root module to encrypt the data of the one or more functional modules to be encrypted.

17. An electronic device, characterized in that: include: Memory for storing computer programs; as well as A controller, used to implement the steps of the communication method as described in any one of claims 4 to 15 when executing a computer program.

18. A non-volatile computer-readable storage medium, characterized in that: The non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by the controller, the steps of the communication method according to any one of claims 4 to 15 are implemented.

19. An encryption system, characterized in that: It includes a platform trust root connector, a platform trust root module, a controller and several function modules to be encrypted, wherein the function modules to be encrypted include at least a baseboard management controller, a central processing unit and a USB chip; as well as The controller controls the platform trusted root module to encrypt data with one or more of the to-be-encrypted functional modules through the platform trusted root connector.

20. A server, characterized in that: Comprising an encryption system as claimed in claim 19.

Images