Dds security plug-in and heterogeneous chip

Abstract

The application discloses a DDS security plug-in and a heterogeneous chip, wherein the DDS security plug-in is used for performing security operations in a security environment in the process that a publisher and a subscriber communicate based on a DDS communication protocol, and the security operations include identity authentication operations, communication encryption and decryption operations and access control operations. Through the application, the DDS security plug-in performs the security operations in the security environment, reduces security risks and improves communication security.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a DDS security plug-in and heterogeneous chip. Background Technology

[0002] Data Distribution Service (DDS) is a standard for data sharing and real-time communication. Its main goal is to achieve efficient, reliable, and real-time data transmission in distributed systems. The DDS specification was developed by the Object Management Group (OMG) and is widely used in various fields requiring real-time data exchange, such as autonomous driving, aerospace, and industrial automation.

[0003] However, existing pure software-based DDS security solutions are vulnerable to attacks in complex in-vehicle environments, which may lead to unauthorized subscribers / publishers tampering with, replaying, or accessing data without authorization. Summary of the Invention

[0004] This application provides a DDS security plugin and a heterogeneous chip, which can solve the technical problem that pure software-implemented DDS security solutions in the prior art are vulnerable to attacks in complex vehicle environments.

[0005] In a first aspect, embodiments of this application provide a DDS security plugin, which is used to perform security operations in a secure environment during communication between a publisher and a subscriber based on the DDS communication protocol. The security operations include identity authentication operations, communication encryption and decryption operations, and access control operations.

[0006] In conjunction with the first aspect, in one implementation, when the DDS security plugin is running on a processor that supports security isolation technology, security operations are performed in the processor's Trusted Execution Environment (TEE).

[0007] In conjunction with the first aspect, in one implementation, when the DDS security plugin is running on a processor that does not support security isolation technology, security operations are performed in the hardware security module (HSM) integrated on the heterogeneous chip to which the processor belongs.

[0008] In conjunction with the first aspect, in one implementation, the identity authentication operation and the communication encryption / decryption operation are performed by a hardware encryption / decryption engine integrated on a heterogeneous chip to which the processor belongs.

[0009] In conjunction with the first aspect, in one implementation, the access control operation includes:

[0010] In response to the publisher's publishing operation, determine the first topic corresponding to the publishing operation;

[0011] Obtain the publisher's first digital certificate, and parse the publisher's first security capability information based on the first digital certificate;

[0012] Query the first security level requirements corresponding to the first topic in the first security policy database;

[0013] Detect whether the first security capability information meets the requirements of the first security level;

[0014] If the conditions are met, the publishing operation is allowed; otherwise, the publishing operation is rejected.

[0015] In conjunction with the first aspect, in one implementation, the access control operation further includes:

[0016] In response to the publisher's publishing operation, a second topic and a communication path type corresponding to the publishing operation are determined, wherein the communication path type is intra-chip communication or inter-chip communication;

[0017] Obtain the publisher's first digital certificate, and parse the publisher's first security capability information based on the first digital certificate;

[0018] Query the second topic and the second security level requirements corresponding to the communication path type in the second security policy library;

[0019] Detect whether the first security capability information meets the requirements of the second security level;

[0020] If the conditions are met, the publishing operation is allowed; otherwise, the publishing operation is rejected.

[0021] In conjunction with the first aspect, in one implementation, the access control operation further includes:

[0022] In response to a subscriber's subscription action, a third topic corresponding to the subscription action is determined;

[0023] Obtain the subscriber's second digital certificate, and parse the subscriber's second security capability information based on the second digital certificate;

[0024] Search the third security policy library for the third security level requirements corresponding to the third topic;

[0025] Detect whether the second security capability information meets the requirements of the third security level;

[0026] If the conditions are met, the subscription operation is allowed; otherwise, the subscription operation is rejected.

[0027] In conjunction with the first aspect, in one implementation, the access control operation further includes:

[0028] In response to the subscriber's subscription operation, a fourth topic and a communication path type corresponding to the subscription operation are determined, wherein the communication path type is intra-chip communication or inter-chip communication;

[0029] Obtain the subscriber's second digital certificate, and parse the subscriber's second security capability information based on the second digital certificate;

[0030] Query the fourth security policy library for the fourth topic and the fourth security level requirements corresponding to the communication path type;

[0031] Detect whether the second security capability information meets the requirements of the fourth security level;

[0032] If the conditions are met, the subscription operation is allowed; otherwise, the subscription operation is rejected.

[0033] In conjunction with the first aspect, in one implementation, the identity authentication operation includes:

[0034] During the authentication handshake phase, receive the digital certificate from the other end of the communication network;

[0035] Parse the digital certificate to obtain the security capability information of the peer communication party carried in the digital certificate;

[0036] If the security capability information meets the preset security capability requirements, the authentication handshake process is completed.

[0037] If the security capability information does not meet the preset security capability requirements, the authentication handshake process will be terminated.

[0038] Secondly, embodiments of this application provide a heterogeneous chip, wherein at least one processor of the heterogeneous chip runs a DDS security plugin as described in any embodiment of the first aspect.

[0039] The beneficial effects of the technical solutions provided in this application include:

[0040] In this embodiment, the DDS security plugin performs security operations in a secure environment during communication between the publisher and subscriber based on the DDS communication protocol. These security operations include authentication, encryption / decryption, and access control. By performing these operations in a secure environment, the DDS security plugin reduces security risks and improves communication security. Attached Figure Description

[0041] Figure 1 This is a schematic diagram of the architecture for implementing security enhancements to the DDS security plugin in one embodiment of this application. Detailed Implementation

[0042] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0043] First, some of the technical terms used in this application will be explained to help those skilled in the art understand this application.

[0044] An HSM (Hardware Security Module) is a specially designed hardware device primarily used to protect sensitive data and ensure the security of encryption processes. In automotive electronics, HSMs protect the vehicle's electronic systems and data from attacks.

[0045] A Trusted Execution Environment (TEE) is a secure zone designed to protect the code and data executed within it from unauthorized access or tampering. TEE provides an isolated execution environment that allows applications to run under the protection of trusted hardware, thereby enhancing system security. Key features of TEE include:

[0046] Isolation: The TEE is separated from the regular operating system, ensuring that sensitive data and applications are not affected by external attacks during execution.

[0047] Security: The code and data running in the TEE are encrypted, and the content in the TEE remains secure even if the operating system or other applications are taken over by an attacker.

[0048] For ARM chips, TrustZone is the implementation method of its TEE. Many ARM Cortex-A series and some Cortex-M series processors support TrustZone technology, which allows for isolation between secure and non-secure environments.

[0049] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0050] In a first aspect, embodiments of this application provide a DDS security plugin.

[0051] In one embodiment, the DDS security plugin is used to perform security operations in a secure environment during communication between the publisher and the subscriber based on the DDS communication protocol. The security operations include authentication operations, communication encryption and decryption operations, and access control operations.

[0052] In this embodiment, the secure environment can be provided by a Trusted Execution Environment (TEE) or a Hardware Security Module (HSM), thereby enhancing the security of operations performed by the DDS security plugin. Specifically, when the DDS security plugin runs on a processor supporting security isolation technology, the security operations are performed within the processor's TEE. When the DDS security plugin runs on a processor that does not support security isolation technology, the security operations are performed within the Hardware Security Module (HSM) integrated on the heterogeneous chip to which the processor belongs. It should be noted that when the DDS security plugin runs on a processor supporting security isolation technology, if the heterogeneous chip to which the processor belongs has an integrated Hardware Security Module (HSM), then the security operations can also be performed within the HSM integrated on the heterogeneous chip.

[0053] Reference Figure 1 , Figure 1 This is a schematic diagram of the architecture for implementing security enhancements to the DDS security plugin in one embodiment of this application. Figure 1 As shown, the DDS security plugin includes an authentication plugin, a communication encryption / decryption plugin, and an access control plugin. The three plugins run in a secure environment provided by a Trusted Execution Environment (TEE) or a Hardware Security Module (HSM) to perform authentication, communication encryption / decryption, and access control operations within the secure environment.

[0054] Furthermore, in one embodiment, the identity authentication operation and the communication encryption / decryption operation are performed by a hardware encryption / decryption engine integrated on a heterogeneous chip to which the processor belongs.

[0055] In this embodiment, the identity authentication operation and the communication encryption and decryption operation involve signing, signature verification and data encryption and decryption operations. The underlying implementation of these operations is to process the data using a key. By performing these operations in the hardware encryption and decryption engine, both data security and data processing performance are improved.

[0056] Furthermore, in one embodiment, the access control operation includes:

[0057] In response to the publisher's publishing operation, a first topic corresponding to the publishing operation is determined; the publisher's first digital certificate is obtained, and the publisher's first security capability information is parsed from the first digital certificate; the first security level requirement corresponding to the first topic is queried in the first security policy library; the first security capability information is checked to see if it meets the first security level requirement; if it does, the publishing operation is allowed to be executed; if it does not, the publishing operation is rejected.

[0058] In this embodiment, we assume there is a topic named VehicleControlCommand, specifically used to publish critical control commands such as braking and steering. This is a highly important topic, and it is essential to ensure that only components with the highest safety level can publish data.

[0059] Publisher: BrakeSystemManager, running on a chassis domain controller that supports HSM. Because its hardware environment is HSM, the security capability attribute in its digital certificate is set to HSM_HIGH.

[0060] Security policy library: The system administrator has pre-configured a rule:

[0061] The required safety level for VehicleControlCommand is HSM_HIGH.

[0062] The BrakeSystemManager application calls data_writer.write(brake_command), which triggers the DDS middleware. Before sending data, the DDS middleware hands over control to the access control plugin. The access control plugin examines the target of this write operation and confirms that data is to be published to the topic VehicleControlCommand; that is, the first topic corresponding to the publish operation is VehicleControlCommand.

[0063] The access control plugin obtains the first digital certificate of the DDS participant BrakeSystemManager, parses the extended fields in the first digital certificate, and extracts the first security capability information as HSM_HIGH.

[0064] The access control plugin queries the first security policy library using the topic name VehicleControlCommand as the key. The policy library returns the first security level requirement: VehicleControlCommand requires a security level of HSM_HIGH.

[0065] Since the first security capability information is HSM_HIGH at this time, which meets the first security level requirement, BrakeSystemManager is allowed to publish data to VehicleControlCommand.

[0066] In another embodiment, suppose a compromised infotainment system (IVI) attempts to maliciously issue a braking command. If the access control plugin detects that the IVI's first security capability information, SOFTWARE_LOW, does not meet the first security level requirements, it will refuse the IVI from issuing data to VehicleControlCommand, thus ensuring that the malicious braking command cannot be issued at all, and the vehicle remains safe.

[0067] Furthermore, in one embodiment, the access control operation further includes:

[0068] In response to the publisher's publishing operation, a second topic and communication path type corresponding to the publishing operation are determined, wherein the communication path type is intra-chip communication or inter-chip communication; the publisher's first digital certificate is obtained, and the publisher's first security capability information is parsed from the first digital certificate; the second security level requirements corresponding to the second topic and the communication path type are queried in the second security policy library; whether the first security capability information meets the second security level requirements is checked; if it meets the requirements, the publishing operation is allowed to be executed; if it does not meet the requirements, the publishing operation is rejected.

[0069] In this embodiment, it is assumed that a smart car has multiple domain controllers:

[0070] Intelligent Driving Domain Controller (SoC_A): Contains a Cortex-A core that supports TEE and a Cortex-R / M core that supports HSM, running key autonomous driving algorithms.

[0071] Intelligent Cockpit Domain Controller (SoC_B): Contains a Cortex-A core with TEE support, running the infotainment system.

[0072] Topics include:

[0073] DrivingPlan: Driving planning command, issued by the PlanningModule within the intelligent driving domain controller.

[0074] VehicleSpeed: Vehicle speed information, published by the SensorFusionModule within the intelligent driving domain controller.

[0075] The security policy library (second security policy library) is configured as shown in Table 1 below:

[0076] Table 1

[0077]

[0078] Scenario 1: Cross-chip critical instruction deployment operation: The PlanningModule (running in the TEE of SoC_A) needs to send the calculated driving plan to the display module located on the intelligent cockpit domain controller (SoC_B) for preview. It calls data_writer.write(driving_plan).

[0079] The access control plugin determines that the second topic is DrivingPlan. The DDS middleware uses the discovery mechanism to determine that the subscriber is located on another physical chip (SoC_B), and therefore determines that this communication is inter-chip communication.

[0080] The access control plugin obtains the PlanningModule's digital certificate and parses it to show that its security capability is TEE_LEVEL_2.

[0081] The access control plugin queries the second security policy library using (DrivingPlan, inter-chip communication) as the union key. It returns the second security level requirement: the required security level is HSM_LEVEL_3.

[0082] Since the security level of TEE_LEVEL_2 is lower than that of HSM_LEVEL_3, meaning that the first security capability information does not meet the requirements of the second security level, the PlanningModule is refused to publish data to DrivingPlan.

[0083] Scenario 2: Data Release Within the Chip

[0084] Publishing operation: The SensorFusionModule (running on SoC_A) needs to publish vehicle speed information to other modules also running on SoC_A (such as the logging module). It calls data_writer.write(vehicle_speed).

[0085] The access control plugin determines that the second topic is VehicleSpeed. The DDS middleware uses a discovery mechanism to determine that the subscribers are located in the same chip, thus classifying it as intra-chip communication.

[0086] The access control plugin obtains the digital certificate of the SensorFusionModule and parses it to show that its security capability is TEE_LEVEL_1.

[0087] The access control plugin queries the second security policy library using (VehicleSpeed, intra-chip communication) as the key. It returns the second security level requirement: the required security level is TEE_LEVEL_1.

[0088] Since the SensorFusionModule's first security capability information meets the second security level requirements, the SensorFusionModule is allowed to publish data to VehicleSpeed.

[0089] Furthermore, in one embodiment, the access control operation further includes:

[0090] In response to a subscriber's subscription operation, a third topic corresponding to the subscription operation is determined; the subscriber's second digital certificate is obtained, and the subscriber's second security capability information is parsed from the second digital certificate; the third security level requirement corresponding to the third topic is queried in the third security policy library; the second security capability information is checked to see if it meets the third security level requirement; if it does, the subscription operation is allowed to proceed; if it does not, the subscription operation is rejected.

[0091] In this embodiment, it is assumed that the intelligent cockpit domain controller contains a Cortex-A core that supports TEE and runs the DashboardDisplay module. It requests to subscribe to the SteeringCommand topic (i.e., the third topic) to display the current steering angle on the dashboard in real time.

[0092] Specifically, the DashboardDisplay module initializes a DataReader to subscribe to the SteeringCommand topic. This subscription operation triggers the DDS middleware, which, before establishing a communication link, hands over control to the access control plugin for verification.

[0093] The access control plugin confirms that the third topic corresponding to this subscription operation is SteeringCommand.

[0094] The access control plugin obtains the second digital certificate of the DDS participant to which the DashboardDisplay module belongs. It parses the extended fields in the certificate to extract its security capability attribute value. Since this module runs in the TEE environment of the smart cockpit, its security capability is TEE_MEDIUM.

[0095] The access control plugin queries the third-party security policy library using the topic name SteeringCommand as the key. The returned third-party security level requirement is HSM_HIGH, which is the security level required to subscribe to the SteeringCommand topic.

[0096] The subscription operation is rejected because the subscriber's second security capability information TEE_MEDIUM is lower than the HSM_HIGH level required for subscribing to the third topic.

[0097] Similarly, if the subscriber's second security capability information meets the second security level requirements for subscribing to a third topic, then the subscription operation is permitted.

[0098] Furthermore, in one embodiment, the access control operation further includes:

[0099] In response to a subscriber's subscription operation, the system determines a fourth topic and communication path type corresponding to the subscription operation, wherein the communication path type is intra-chip communication or inter-chip communication; obtains the subscriber's second digital certificate and parses the subscriber's second security capability information based on the second digital certificate; queries the fourth security policy library for the fourth security level requirements corresponding to the fourth topic and the communication path type; checks whether the second security capability information meets the fourth security level requirements; if it does, the subscription operation is allowed to proceed; if it does not, the subscription operation is rejected.

[0100] In this embodiment, it is assumed that a smart car has multiple domain controllers:

[0101] Intelligent Driving Domain Controller (SoC_A): Contains a Cortex-A core supporting TEE and a Cortex-R core supporting HSM. Running on it is the ObjectDetection module, which publishes information such as the position and speed of pedestrians ahead of the vehicle to the CriticalObjects topic.

[0102] The Intelligent Cockpit Domain Controller (SoC_B) contains a Cortex-A core with TEE support. The DriverMonitoring module runs on it. It subscribes to the CriticalObjects topic to issue warnings when it detects driver distraction and an obstacle ahead.

[0103] Based on data sensitivity and transmission risks, the system administrator configured the policy rules shown in Table 2 in the fourth security policy library:

[0104] Table 2

[0105]

[0106] Scene 1:

[0107] In response to the subscription operation initiated by the DriverMonitoring module of the intelligent cockpit domain controller (SoC_B), the fourth topic is determined to be CriticalObjects. The DDS middleware determines through the discovery mechanism that the publisher of the information to ObjectDetection is located on another physical chip (SoC_A), and therefore determines that the communication path type is inter-chip communication.

[0108] The access control plugin obtains DriverMonitoring's digital certificate and parses its secondary security capability information as TEE_MEDIUM.

[0109] The access control plugin queries the fourth security policy library using (CriticalObjects, inter-chip communication) as the union key. The returned fourth security level requirement is: the required security level is HSM_HIGH.

[0110] The subscription operation is rejected because the subscriber's second security capability information TEE_MEDIUM is lower than the HSM_HIGH level required for subscribing to the fourth topic.

[0111] Scene 2:

[0112] Inside SoC_A, there is also an InternalAnalyzer module, which also needs to subscribe to CriticalObjects data for real-time analysis.

[0113] In response to the subscription operation initiated by the InternalAnalyzer module, the fourth topic is determined to be CriticalObjects. The DDS middleware uses the discovery mechanism to determine that the publisher of the information to ObjectDetection is located on the physical chip (SoC_A), and therefore determines that the communication path type is intra-chip communication.

[0114] The access control plugin obtains the InternalAnalyzer's digital certificate and parses its secondary security capability information as TEE_MEDIUM.

[0115] The access control plugin queries the fourth security policy library using (CriticalObjects, intra-chip communication) as the union key. The returned fourth security level requirement is: the required security level is TEE_MEDIUM.

[0116] Since the subscriber's second security capability information TEE_MEDIUM meets the TEE_MEDIUM level required for subscribing to the fourth topic, this subscription operation is permitted.

[0117] Furthermore, in one embodiment, the identity authentication operation includes:

[0118] During the authentication handshake phase, the system receives the digital certificate from the peer; parses the digital certificate to obtain the security capability information of the peer carried in the digital certificate; if the security capability information meets the preset security capability requirements, the authentication handshake process is completed; if the security capability information does not meet the preset security capability requirements, the authentication handshake process is terminated.

[0119] In this embodiment, a custom "security capability" attribute is embedded as an extended field in the digital certificate of each DDS communication participant. For example, an object identifier (OID) can be defined to represent this attribute, with values ​​such as TEE_HIGH, HSM_MEDIUM, and SOFTWARE_LOW. When two participants (A and B) establish a connection, the DDS Security standard authentication handshake process is executed. During this process, both parties exchange their respective digital certificates.

[0120] After receiving the digital certificate from the other party, the authentication plugin of either party will parse the certificate content and extract the value of the "security capability" extended field, that is, obtain the security capability information of the other party carried in the digital certificate.

[0121] Each participant is configured with preset security capability requirements, for example:

[0122] a) Global policy: For example, "When communicating with any entity in this domain, its security capabilities must not be lower than HSM_MEDIUM".

[0123] The authentication plugin of either party will compare the security capability information extracted from the other party's digital certificate with the security capability requirements preset in the local policy to check whether the other party's security capability meets the preset security capability requirements.

[0124] If the verification passes, the authentication process continues, the two parties establish a secure association, and the subsequent access control operations and communication encryption / decryption operations continue. If the verification fails, the identity authentication plugin immediately terminates the handshake process and returns an authentication failure error. The communication link between the two parties cannot be established, thus enabling only trusted nodes to interact.

[0125] By making "security capability" an inherent attribute of the certificate and verifying it during the standard authentication handshake phase, the possibility of nodes with insufficient security capabilities entering the system's communication network is fundamentally eliminated.

[0126] The above embodiments enable an intelligent balance between security and functionality in different scenarios, and allow for the implementation of the most appropriate security measures in complex heterogeneous chip environments.

[0127] Secondly, embodiments of this application also provide a heterogeneous chip.

[0128] In one embodiment, at least one processor of the heterogeneous chip runs the DDS security plugin described in the first aspect.

[0129] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0130] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0131] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0132] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0133] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0134] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0135] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method implemented based on a DDS security plug-in, characterized in that, The DDS security plug-in is used to perform security operations in a secure environment in a process in which a publisher and a subscriber communicate based on a DDS communication protocol, wherein the security operations include identity authentication operations, communication encryption and decryption operations, and access control operations; the access control operations include: In response to a publish operation of the publisher, a second topic corresponding to the publish operation and a communication path type are determined, wherein the communication path type is intra-chip communication or inter-chip communication; A first digital certificate of the publisher is obtained, and first security capability information of the publisher is parsed from the first digital certificate; A second security level requirement corresponding to the second topic and the communication path type is queried in a second security policy library; It is detected whether the first security capability information meets the second security level requirement; If the first security capability information meets the second security level requirement, the publish operation is allowed to be executed; if the first security capability information does not meet the second security level requirement, the publish operation is rejected.

2. The method implemented by the DDS security plug-in as claimed in claim 1, wherein, When the DDS security plug-in runs on a processor supporting a security isolation technology, the security operations are performed in a trusted execution environment (TEE) of the processor.

3. The method implemented by the DDS security plug-in based on claim 1, wherein, When the DDS security plug-in runs on a processor not supporting a security isolation technology, the security operations are performed in a hardware security module (HSM) integrated on a heterogeneous chip to which the processor belongs.

4. The method implemented by the DDS security plug-in based on claim 2 or 3, characterized in that, The identity authentication operations and the communication encryption and decryption operations are performed by a hardware encryption and decryption engine integrated on a heterogeneous chip to which the processor belongs.

5. The method implemented by the DDS security plug-in based on claim 1, wherein, The access control operations further include: In response to a subscribe operation of the subscriber, a third topic corresponding to the subscribe operation is determined; A second digital certificate of the subscriber is obtained, and second security capability information of the subscriber is parsed from the second digital certificate; A third security level requirement corresponding to the third topic is queried in a third security policy library; It is detected whether the second security capability information meets the third security level requirement; If the second security capability information meets the third security level requirement, the subscribe operation is allowed to be executed; if the second security capability information does not meet the third security level requirement, the subscribe operation is rejected.

6. The method implemented by the DDS security plug-in based on claim 1, wherein, The access control operations further include: In response to a subscribe operation of the subscriber, a fourth topic corresponding to the subscribe operation and a communication path type are determined, wherein the communication path type is intra-chip communication or inter-chip communication; A second digital certificate of the subscriber is obtained, and second security capability information of the subscriber is parsed from the second digital certificate; A fourth security level requirement corresponding to the fourth topic and the communication path type is queried in a fourth security policy library; It is detected whether the second security capability information meets the fourth security level requirement; If the second security capability information meets the fourth security level requirement, the subscribe operation is allowed to be executed; if the second security capability information does not meet the fourth security level requirement, the subscribe operation is rejected.

7. The method implemented by the DDS security plug-in based on claim 1, wherein, The identity authentication operations include: In an authentication handshake phase, a digital certificate of a peer communication party is received; The digital certificate is parsed to obtain security capability information of the peer communication party carried in the digital certificate; If the security capability information meets a preset security capability requirement, an authentication handshake process is completed; If the security capability information does not meet the preset security capability requirement, the authentication handshake process is terminated.

8. A heterogeneous chip, comprising: The at least one processor of the heterogeneous chip runs a DDS security plug-in, which, when executed by the processor, implements the steps of the method implemented based on the DDS security plug-in as claimed in any one of claims 1 to 7.

Images