Patent Description:
With the development of modern information technologies, there are increasingly more electronic products in a vehicle, and complexity is increasingly higher. Automotive Ethernet technologies are more widely used in the automotive field. In automotive Ethernet, a network system in which electronic control units (electronic control units, ECUs) in a vehicle are interconnected is established by virtue of Ethernet technologies. <CIT> relates to systems supporting interoperability of devices having unequal capabilities. <CIT> relates to the field of communication networks, and more specifically to facilitating protection of a maintenance entity group.

To ensure security of data exchanged between the ECUs in the vehicle, a security protection mechanism needs to be established. However, in existing security protection mechanisms, such as a security protection mechanism based on transport layer security (transport layer security, TLS), a security protection mechanism based on Internet protocol security (internet protocol security, IPSEC), and a security protection mechanism based on a media access control security (media access control security, MACsec) technology, there are high requirements on device performance. However, the ECU in the vehicle usually has low performance. Therefore, a security protection mechanism for low-performance devices needs to be established.

Embodiments of this application provide a security protection method, to ensure security of data exchanged between low-performance devices. The dependent claims recite advantageous embodiments of the invention.

It should be understood that the security protection method provided in this application may be performed by an electronic apparatus. The electronic apparatus may be a security protection apparatus, for example, may be an entire computing device, or may be some components in the computing device, for example, a chip related to security protection. Specifically, the electronic apparatus may be a terminal such as an ECU in a vehicle, or may be a system chip that can be disposed in the terminal. The system chip is also referred to as a system on a chip (system on a chip, SoC), or a system-on-a-chip chip.

The following describes embodiments of this application with reference to accompanying drawings. It is clear that, the described embodiments are merely some but not all of the embodiments of this application. A person of ordinary skill in the art may learn that, with development of technologies and emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to a similar technical problem.

In the specification, claims, and accompanying drawings of this application, terms such as "first" and "second" are intended to distinguish between similar objects, but do not necessarily indicate a specific order or sequence. It should be understood that data used in such a way is interchangeable in proper circumstances, so that the embodiments described herein can be implemented in other orders than the order illustrated or described herein. In addition, terms "include" and "have" and any variants thereof are intended to cover the non-exclusive inclusion. For example, a process, method, system, product, or device that includes a list of steps or modules is not necessarily limited to those expressly listed steps or modules, but may include other steps or modules not expressly listed or inherent to such a process, method, product, or device. Naming or numbering of steps in this application does not mean that the steps in method procedures need to be performed in a time/logical order indicated by the naming or numbering. An execution order of the steps in the procedures that have been named or numbered can be changed based on a technical objective to be achieved, as long as same or similar technical effects can be achieved. Division into modules in this application is logical division and may be other division in an actual implementation. For example, a plurality of modules may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented through some ports. The indirect couplings or communication connections between the modules may be implemented in electronic or other similar forms. This is not limited in this application. In addition, modules or submodules described as separate parts may or may not be physically separate, may or may not be physical modules, or may be distributed into a plurality of circuit modules. Some or all of the modules may be selected based on actual requirements to achieve the objectives of the solutions of this application.

To better understand the technical solutions provided in this application, the following first describes a research idea of the solutions provided in this application.

To ensure security of communication between devices in a network, a security protection mechanism needs to be established, for example, a security protection mechanism based on transport layer security (transport layer security, TLS), a security protection mechanism based on Internet protocol security (internet protocol security, IPSEC), a security protection mechanism based on media access control security (media access control security, MACsec), and a security protection mechanism based on secure onboard communication (Secure Onboard Communication, SecOC). However, an existing security protection mechanism has a disadvantage, and is not applicable to a low-performance device. The low-performance device in this application may be a device that cannot process a large amount of data, or a device in a scenario in which there is no need to process a large amount of data. For example, a possible application scenario includes the Internet of vehicles, and the low-performance device may include a device in automotive Ethernet. Alternatively, a possible application scenario may include the Internet of things (Internet of things, IoT), and the low-performance device may include a device in the Internet of things. In this application, the low-performance device is also sometimes referred to as a poor-performance device. When a difference between the two devices is not emphasized, the two devices have a same meaning. One of reasons why the existing security protection mechanism is not applicable to the poor-performance device is that the existing security protection mechanism has a high requirement on processing performance of the device. For example, in a security protection mechanism based on a TLS technology, key agreement is required, two devices consume a long time period to establish communication, and an encryption speed is low. In addition, based on a session mechanism, different sessions need to be established for different services, and this is difficult for the low-performance device. For another example, in a security protection mechanism based on an IPsec technology, many items need to be preconfigured, key agreement is also required, and an encryption speed is low. In a security protection mechanism based on a MACsec technology, a large amount of data needs to be encrypted, and a chip is required to support an algorithm. This is not applicable to the low-performance device either. For another example, a security protection mechanism based on SecOC needs to rely on an automotive open system architecture (AUTomotive open system architecture, AUTOSAR) software stack, and a security technology based on SecOC does not support an encryption function.

The existing security protection mechanism in the conventional technology is not applicable to the low-performance device, and security of communication between low-performance devices cannot be ensured. Therefore, a security protection mechanism for the low-performance device urgently needs to be designed.

To resolve the foregoing problem, this application provides a security protection method. Different security levels are set for a plurality of VLANs in Ethernet, and security protection is performed on communication in the VLANs based on the different security levels, or security protection is not performed on communication in the VLANs. In this manner, communication between devices in a network does not require full-channel protection. In other words, security protection does not need to be performed on all data sent between any two devices. Through such design, a device does not need to have a high-performance processing capability. In other words, a performance requirement on the device is low. In addition, in the solutions provided in this application, a complete protection system is established for the low-performance device, and integrity protection, anti-replay attack protection, and confidentiality protection can be performed on data sent between devices.

With reference to the foregoing research idea, the following specifically describes the solutions provided in this application.

<FIG> is a schematic diagram depicting an application scenario of a security protection method according to this application. As shown in <FIG>, the Ethernet includes a plurality of devices, for example, a first device, a second device, a third device, a fourth device, and a fifth device shown in <FIG>. The Ethernet is divided into a plurality of virtual local area networks (virtual local area networks, VLANs). For example, the Ethernet is divided into three VLANs. A first VLAN includes the first device and the third device, a second VLAN includes the second device, the third device, and the fifth device, and a third VLAN includes the third device and the fourth device. Dividing the Ethernet into the plurality of VLANs may be understood as dividing the Ethernet into a plurality of logically isolated broadcast domains. Devices in only a same VLAN can communicate with each other. Restricting a data packet into one VLAN can prevent a broadcast storm, and enable a network to be relatively simple and intuitive during network management. There may be a plurality of manners for division into VLANs, for example, port-based division into VLANs. Each VLAN corresponds to a unique port number. For another example, protocol-based division into VLANs or service requirement-based division into VLANs may be used. The embodiments of this application only concern that the Ethernet is divided into the plurality of VLANs. A specific standard used to divide the Ethernet into the plurality of VLANs is not limited in this application. The solutions provided in this application may be applied to a communication scenario of a low-performance device. For example, the solutions provided in this application may be applied to an automotive Ethernet scenario. For example, the following provides a manner of performing division into VLANs based on different service types by using different protocols in the automotive Ethernet scenario. For example, a service <NUM> includes remote control, a driving mode, parameter display, and an OTA service interaction packet. A protocol used for these services is SOMEIP. The service <NUM> is classified into one VLAN. A service <NUM> includes log uploading and monitoring data uploading. A protocol used for these services is also SOME/IP. The service <NUM> is classified into one VLAN. For understanding, refer to Table <NUM>. Details are not described herein one by one.

In this scenario, the first device, the second device, and the fourth device each may be an ECU, and the third device may be a gateway. The solutions provided in this application may be further applied to an Internet of things scenario. In this scenario, the first device, the second device, and the fourth device each may be a home electronic device, and the third device may be a home gateway.

<FIG> is a schematic flowchart depicting a security protection method according to an embodiment of this application.

As shown in <FIG>, the security protection method provided in this embodiment of this application may include the following steps.

<NUM>: A source device obtains a security level of a first VLAN.

The source device and a destination device corresponding to the source device are devices in the first VLAN, the first VLAN is one of a plurality of VLANs included in Ethernet, and each of the plurality of VLANs corresponds to one security level.

That the Ethernet includes the plurality of VLANs and how to perform division into the VLANs have been described above. The following describes how to classify security levels of the plurality of VLANs in the Ethernet.

In a possible implementation, the security level of each VLAN may be customized. For example, security levels may include a high level and a low level. Alternatively, there may be more security levels. For example, security levels may include a high level, a medium level, and a low level. A higher security level corresponding to a VLAN indicates that data transmitted in the VLAN requires more comprehensive security protection. For example, when a security level of a VLAN is the high level, integrity protection, anti-replay attack protection, and confidentiality protection need to be performed on data transmitted in the VLAN. When a security level of a VLAN is the medium level, integrity protection and anti-replay attack protection need to be performed on data transmitted in the VLAN. When a security level of a VLAN is the low level, security protection may not be performed on data transmitted in the VLAN, to avoid a problem that a device needs to process a large amount of data.

In a possible implementation, the security level of each VLAN may be determined through threat analysis. For example, the following provides a manner of determining the security level of each VLAN through threat analysis. It should be noted that a manner of determining the security level of each VLAN by using another threat analysis method should also fall within the protection scope of this application. A possibility of occurrence of a threat, that is, a probability of occurrence of the threat, is recognized with reference to an attribute of the threat, vulnerability of assets, and a used security measure by analyzing a threat path. Threat impact is recognized by analyzing value of a threat object, a threat coverage area, damage severity, remediability, and the like. A method for calculating a threat value based on an attack capability and an attack motive of a threat source, a threat occurrence probability, and an impact degree is analyzed and determined. Through comprehensive analysis of the foregoing factors, a value is assigned to a possibility of the threat. Values assigned to threats are classified into five levels: very high, high, medium, low, and very low. A higher level indicates a higher possibility of occurrence of the threat. A higher possibility of occurrence of the threat indicates a higher specified security level corresponding to the VLAN.

<NUM>: The source device determines, based on the security level of the first VLAN, whether to perform security protection on user data to be sent to the destination device.

When sending the data to the destination device in the first VLAN, the source device may determine, based on the security level of the first VLAN, whether to perform security protection on the user data to be sent to the destination device. It should be noted that, in this application, the user data is also sometimes referred to as data for short. This should be understood by a person skilled in the art.

In a possible implementation, whether to perform security protection on the user data to be sent to the destination device may be determined by querying a table. The following provides descriptions with reference to Table <NUM> and Table <NUM>.

As shown in Table <NUM>, the VLAN list may record an identifier ID of each of a plurality of VLANs. The source device may determine, by querying an ID of a VLAN, a security level corresponding to the VLAN. It is assumed that the following is specified: When a security level is high or medium, security protection needs to be performed on to-be-sent data, and when a security level is low, security protection does not need to be performed on to-be-sent data. In this case, if the first VLAN is the VLAN <NUM>, the source device may learn, by querying Table <NUM>, that the security level corresponding to the first VLAN is high, and security protection needs to be performed on the user data to be sent to the destination device. If the first VLAN is the VLAN <NUM>, the source device may learn, by querying Table <NUM>, that the security level corresponding to the first VLAN is medium, and security protection needs to be performed on the user data to be sent to the destination device. If the first VLAN is the VLAN <NUM>, the source device may learn, by querying Table <NUM>, that the security level corresponding to the first VLAN is low, and security protection does not need to be performed on the user data to be sent to the destination device.

As shown in Table <NUM>, a security level corresponding to a VLAN and security protection corresponding to the security level may be further determined by querying a table. For example, if the first VLAN is the VLAN <NUM>, the source device may learn, by querying Table <NUM>, that the security level corresponding to the first VLAN is high, and security protection needs to be performed on the user data to be sent to the destination device. Specifically, integrity protection, anti-replay protection, and confidentiality protection need to be performed on communication data in the first VLAN. If the first VLAN is the VLAN <NUM>, the source device may learn, by querying Table <NUM>, that the security level corresponding to the first VLAN is medium, and security protection needs to be performed on the user data to be sent to the destination device. In addition, integrity protection and anti-replay protection need to be performed on communication data in the first VLAN. If the first VLAN is the VLAN <NUM>, the source device may learn, by querying Table <NUM>, that the security level corresponding to the first VLAN is low, and security protection does not need to be performed on the user data to be sent to the destination device.

It should be noted that, other than determining the security level of the first VLAN by querying a table, the security level of the first VLAN may be alternatively obtained in another manner. There may be a plurality of specific manners of obtaining the security level of the first VLAN.

It can be learned from the embodiment corresponding to <FIG> that, in the solutions provided in this application, a security level is set for each of the plurality of VLANs included in the Ethernet, and whether to perform security protection on communication data in a VLAN is determined based on a security level of the VLAN. According to the solutions provided in this application, security protection is performed or no security protection is performed on data in a VLAN based on a security level of the VLAN. This avoids a need to protect communication between any two devices in the Ethernet. According to the solutions provided in this application, an amount of data that needs to be processed when a device performs security protection can be reduced, a requirement on processing performance of the device is low, and this is applicable to security protection of communication data between low-performance devices.

In the solutions provided in this application, a complete protection system is established for the low-performance device, and integrity protection, anti-replay attack protection, and confidentiality protection can be performed on data sent between devices. The following provides detailed descriptions.

<FIG> is a schematic flowchart depicting another security protection method according to an embodiment of this application.

As shown in <FIG>, the another security protection method provided in this embodiment of this application may include the following steps.

Step <NUM> may be understood with reference to step <NUM> in the embodiment corresponding to <FIG>.

<NUM>: When the source device determines, based on the security level of the first VLAN, to perform security protection on user data to be sent to a destination device, the source device encapsulates a first packet based on a header of the first VLAN, to obtain a second packet.

The header of the first VLAN includes a first field, a counter-related PN field, and a decryption type-related AE field, the first field is used to indicate the destination device to perform security verification on received data, the PN field is used by the destination device to verify whether the received data is replayed data, and the AE field is used by the destination device to determine whether to decrypt the data. The first packet is a packet obtained after the source device encapsulates the data based on an identifier ID of the first VLAN. In a possible implementation, the header of the first VLAN may further include a version (version) number.

It can be learned from the embodiment corresponding to <FIG> that, in a packet encapsulation process, the source device encapsulates the header of the VLAN after the ID of the VLAN is encapsulated. Therefore, the source device may select, based on the ID of the VLAN, data that needs to be protected. For example, the source device communicates with the destination device in the first VLAN, and the first packet is obtained after the data is encapsulated based on the ID of the first VLAN. Whether to perform security protection on the data may be determined based on the ID of the first VLAN. If it is determined, based on the ID of the first VLAN, that the data does not need to be protected, the first packet does not need to be encapsulated based on the header of the first VLAN. If it is determined, based on the ID of the first VLAN, that the data needs to be protected, the first packet may be encapsulated based on the header of the first VLAN, and a value of each field in the header of the first VLAN may be set. In addition, the header of the first VLAN includes the first field, the PN field, and the AE field. When parsing a received packet, the destination device may determine and identify a frame format based on the first field to determine whether to perform security verification, determine, based on the PN field, whether the packet is a replayed packet, and determine, based on the AE field, whether to perform decryption.

<FIG> shows a possible packet format according to an embodiment of this application. As shown in <FIG>, user data is encapsulated based on an Internet protocol (Internet protocol, IP) header. The user data may be plaintext or ciphertext. Then, a packet is encapsulated based on an ID (for example, a VLAN tag) of a VLAN. Subsequently, encapsulation is performed based on a header of the VLAN. Then, encapsulation is performed based on physical addresses (media access control address, MAC) of the source device and the destination device. The packet further includes a check code. The check code may be used to confirm integrity of the packet and perform integrity check on the packet.

In the solutions provided in this application, security protection may be selectively performed on data. For example, security protection may not be performed on the data, or integrity protection, anti-replay attack protection, and confidentiality protection may be performed on the data. In a preferred implementation, integrity protection and anti-replay attack protection may be performed on the data, and confidentiality protection may not be performed. In a preferred implementation, integrity protection, anti-replay attack protection, and confidentiality protection may be performed on the data. This is described below in detail.

<NUM>: The source device determines, based on the security level of the first VLAN, to perform integrity protection on data.

<NUM>: The source device determines a first check value based on an identifier ID of the first VLAN, the user data, and a header of the first VLAN.

The first check value is used to verify integrity of the data.

An objective of the check value is to generate unique additional information for a packet sent by the source device, so that a destination device may determine, based on the additional information, whether a received packet is complete, accurate, or tampered with.

In most scenarios, when integrity protection is performed on the packet, anti-replay attack protection further needs to be performed on the packet. Therefore, in a possible implementation, the method may further include <NUM>: The source device determines, based on the security level of the first VLAN, to perform anti-replay attack protection on the data. It should be noted that the anti-replay attack protection is also sometimes referred to as anti-replay protection in this application. When a difference between the anti-replay attack protection and the anti-replay protection is not emphasized, the anti-replay attack protection and the anti-replay protection represent a same meaning.

For step <NUM>, the method may further include step <NUM>: Add <NUM> to a value of a counter-related PN field each time the source device sends data to the destination device.

The header of the first VLAN includes the PN field, and the value of the PN field is increased by <NUM> each time the source device sends data to the destination device. For example, when the source device sends data to the destination device for the first time, the value of the PN field is <NUM>, when the source device sends data to the destination device for the second time, the value of the PN field is <NUM>, and so on.

<NUM>: The destination device receives a packet sent by the source device.

The packet is a packet obtained after the source device encapsulates a first packet based on the header of the first VLAN, and the first packet is a packet obtained after the source device encapsulates, based on the identifier ID of the first VLAN, the data to be sent to the destination device. The packet sent by the source device has been described above, and details are not described herein again.

<NUM>: The destination device parses the packet, and determines, based on a first field included in the header of the first VLAN, whether to perform security verification on the packet.

In a possible implementation, if determining, based on the first field, that security verification needs to be performed on the packet, the destination device determines a second check value based on the identifier ID of the first VLAN, the data, and the header of the first VLAN. The destination device verifies integrity of the data by comparing the second check value with the first check value. If the second check value is the same as the first check value, it indicates that the received packet is accurate and is not tampered with. If the second check value is different from the first check value, it indicates that the received packet is inaccurate or is tampered with. It should be noted that an algorithm for determining the second check value by the destination device based on the identifier ID of the first VLAN, the data, and the header of the first VLAN is the same as an algorithm for determining the first check value by the source device.

In a possible implementation, if determining, based on the first field, that security verification needs to be performed on the packet, the destination device determines, based on the value of the PN field, whether the received packet is a replayed packet. Each time the destination device receives a packet, the destination device stores a value of a PN field included in the packet. If a value of a PN field in a next received packet is not greater than the locally stored value of the PN field, the destination device considers that the packet is a replayed packet. For example, if a value of a PN field in a packet is <NUM> after the destination device receives the packet for the first time, the destination device locally stores the value <NUM> of the PN field. After the destination device receives a packet for the second time, if a value of a PN field in the packet is <NUM>, the destination device updates the locally stored value of the PN field from <NUM> to <NUM>. If a value of a PN field in a packet is <NUM> after the destination device receives the packet for the third time, the destination device may determine that the packet received for the third time is a replayed packet. This is because the value of the PN field in the packet received for the third time is not greater than the locally stored value of the PN field, that is, not greater than <NUM> in this example.

In a possible implementation, if determining, based on the first field, not to perform security verification on the packet, the destination device needs only to parse the packet, and does not need to perform security verification on the packet.

For example, if the source device determines that security protection is required in the first VLAN, a value of the first field is set to 0x99F6. If the destination device determines, after parsing the packet, that the first field is 0x99F6, the destination device determines that security verification needs to be performed on the packet. If the destination device determines, after parsing the packet, that the first field is not 0x99F6, the destination device determines that security verification does not need to be performed on the packet.

In a preferred implementation, confidentiality protection may be further performed on the packet. The following describes this embodiment.

<NUM>: The source device determines, based on the security level of the first VLAN, to perform confidentiality protection on data.

The source device may set a value of an AE field to indicate a destination device whether to decrypt a received packet. For example, if the source device determines, based on the security level of the first VLAN, to perform confidentiality protection on the data, the source device sets the value of the AE field to 0x1, or if the source device determines, based on the security level of the first VLAN, not to perform confidentiality protection on the data, the source device sets the value of the AE field to 0x0.

<NUM>: The source device calculates a first key based on a pre-shared key (pre-shared key, PSK) and an identifier ID of the first VLAN.

The first key is used to encrypt the user data.

A key is determined based on the PSK and a unique identifier of each VLAN, and user data in the VLAN is encrypted by using the key corresponding to the VLAN.

<NUM>: The source device performs encryption calculation on the data based on the first key, to obtain the data that is encrypted.

A method for encrypting data based on a key in a related technology may be used in this embodiment of this application.

The packet is a packet obtained after the source device encapsulates a first packet based on a header of the first VLAN, and the first packet is a packet obtained after the source device encapsulates, based on the identifier ID of the first VLAN, the data to be sent to the destination device. The packet sent by the source device has been described above, and details are not described herein again.

<NUM>: The destination device determines, based on a decryption type-related AE field included in the packet, whether to decrypt the data.

<NUM>: The destination device performs decryption calculation on the data based on the first key, to obtain the data that is decrypted. The first key is a key obtained by the destination device through calculation based on the pre-shared key PSK and the identifier ID of the first VLAN.

In a possible implementation, it is assumed that it is determined, based on the first field, that security verification needs to be performed on the packet, and it is determined, based on the AE field, that the packet needs to be decrypted. For example, it is pre-specified that if a value of the AE field is 0x1, it indicates that decryption is required, or if a value of the AE field is 0x0, it indicates that decryption is required. If determining, based on the AE field, that the packet needs to be decrypted, the destination device performs decryption calculation on the data based on the first key, to obtain the data that is decrypted, where the first key is the key obtained by the destination device through calculation based on the pre-shared key PSK and the identifier ID of the first VLAN.

It should be noted that, when confidentiality protection is performed on the packet, integrity protection and anti-replay attack protection further need to be performed on the packet. Therefore, in a possible implementation, the method may further include: The source device determines, based on the security level of the first VLAN, to perform integrity protection on the data. The source device determines, based on the security level of the first VLAN, to perform anti-replay attack protection on the data. For a process in which the source device performs integrity protection on the data and performs anti-replay attack protection on the data, refer to the description in the embodiment corresponding to <FIG> for understanding. The source device performs integrity protection and anti-replay attack protection on the packet, and correspondingly, the destination device performs integrity verification and duplicate packet verification on the received packet. For integrity verification, refer to the description of integrity verification in the embodiment corresponding to <FIG> for understanding. For replayed packet verification, refer to the description of replayed packet verification in the embodiment corresponding to <FIG> for understanding.

In a possible implementation, a check value and ciphertext may be separately calculated by using two different algorithms. For example, the ciphertext is calculated by using a cipher block chaining (cipher block chaining, CBC) algorithm, and the check value is calculated by using a cipher-based message authentication code (CMAC) algorithm. In a possible implementation, the check value and the ciphertext may alternatively be output by using one algorithm. In a preferred implementation, in this application, an Advanced Encryption Standard Galois/Counter Mode (AES-GCM) may be used to output the check value and the ciphertext. This algorithm is fast, and a low-performance device can process a packet without a delay. This algorithm supports integrity check and encryption, or supports only integrity check. If only integrity check is required, a calculation speed can be further improved. AES is a symmetric encryption algorithm. GCM (Galois/counter mode) is a mode used for symmetric encryption. When an encryption operation is performed in the algorithm, input parameters include K, IV, A, and T, and when a decryption operation is performed in the algorithm, input parameters include K, IC, A, and C. The parameter A usually indicates plaintext that does not need to be encrypted, and only integrity protection needs to be performed. A parameter P indicates plaintext that needs to be encrypted. The parameter C indicates ciphertext. The parameter T indicates a check value. K indicates a key, and IV indicates a counter. Data included in the input parameter vary depending on whether a gateway performs layer <NUM> forwarding or layer <NUM> forwarding. The following separately provides descriptions.

<FIG> and <FIG> are a schematic flowchart depicting another security protection method according to an embodiment of this application.

As shown in <FIG> and <FIG>, the another security protection method provided in this embodiment of this application may include the following steps.

<NUM>: The source device determines, based on the security level of the first VLAN, whether to perform security protection on user data to be sent to a destination device.

If the source device determines, based on to the security level of the first VLAN, not to perform security protection on the user data, the source device does not perform any of step <NUM> to step <NUM>.

If the source device determines, based on to the security level of the first VLAN, to perform security protection on the user data, the source device performs step <NUM> to step <NUM>.

The first field is used to indicate the destination device to perform security verification on the user data. For example, if the source device determines that security protection is required in the first VLAN, a value of the first field is set to 0x99F6. If the destination device determines, after parsing a packet, that the first field is 0x99F6, the destination device determines that security verification needs to be performed on the packet. If the destination device determines, after parsing a packet, that the first field is not 0x99F6, the destination device determines that security verification does not need to be performed on the packet.

Compared with a value of a PN field in a last packet sent by the source device to the destination device, the value of the PN field is increased by <NUM>. For example, when the source device sends a packet to the destination device for the first time, the PN field is <NUM>. When the source device sends a packet to the same destination device for the second time, the value of the PN field is increased by <NUM>, that is, the value is <NUM>.

<NUM>: The source device determines, based on the security level of the first VLAN, whether to encrypt the user data, and set a value of an AE field.

The source device may set the value of the AE field to indicate the destination device whether to decrypt a received packet. For example, if the source device determines, based on the security level of the first VLAN, to perform confidentiality protection on the data, the source device sets the value of the AE field to 0x1, or if the source device determines, based on the security level of the first VLAN, not to perform confidentiality protection on the data, the source device sets the value of the AE field to 0x0.

<NUM>: The source device calculates a check value by using an AES-GCM algorithm, or the source device calculates a check value and ciphertext by using an AES-GCM algorithm.

In a possible implementation, if the destination device is a gateway, and the gateway is a gateway for layer <NUM> forwarding, an input parameter K of the AES-GCM is a first key, the first key is obtained through calculation based on a pre-shared key PSK and an ID of the first VLAN, an input parameter IV of the AES-GCM is a value of the counter-related PN field, an input parameter A of the AES-GCM includes a header of the first VLAN, the ID of the first VLAN, the data, an Internet protocol IP header of the data, a physical MAC address of the source device, and a MAC address of the destination device, and an input parameter P of the AES-GCM is null (null). The check value is obtained based on output of the Advanced Encryption Standard Galois/Counter Mode AES-GCM. In this implementation, only integrity protection needs to be performed on the data.

In a possible implementation, if the destination device is a gateway, and the gateway is a gateway for layer <NUM> forwarding, an input parameter K of the AES-GCM is a first key, an input parameter K of the AES-GCM is a first key, an input parameter IV of the AES-GCM is a value of the counter-related PN field, an input parameter A of the AES-GCM includes a header of the first VLAN, an ID of the first VLAN, a physical MAC address of the source device, and a MAC address of the destination device, and an input parameter P of the AES-GCM includes the data and an Internet protocol IP header of the data. Output of the AES-GCM includes the check value and ciphertext. In this implementation, integrity protection and confidentiality protection need to be performed on the data.

In a possible implementation, if the destination device is a gateway, and the gateway is a gateway for layer <NUM> forwarding, an input parameter K of the AES-GCM is a first key, the first key is obtained through calculation based on a pre-shared key PSK and an ID of the first VLAN, an input parameter IV of the AES-GCM is a value of the counter-related PN field, an input parameter A of the AES-GCM includes a header of the first VLAN, the ID of the first VLAN, the data, and an Internet protocol IP header of the data, and an input parameter P of the AES-GCM is null. The check value is obtained based on output of the AES-GCM. In this implementation, only integrity protection needs to be performed on the data. When the gateway is a gateway for layer <NUM> forwarding, after receiving a packet sent by the source device, the gateway removes a MAC address of the source device and a MAC address of the destination device, adds an address of the gateway as a MAC address of the source device, and adds a new MAC address of the destination device. Therefore, the input parameter of the AES-GCM does not need to include the MAC address of the source device and the MAC address of the destination device.

In a possible implementation, if the destination device is a gateway, and the gateway is a gateway for layer <NUM> forwarding, an input parameter K of the AES-GCM is a first key, an input parameter K of the AES-GCM is a first key, an input parameter IV of the AES-GCM is a value of the counter-related PN field, an input parameter A of the AES-GCM includes a header of the first VLAN, an ID of the first VLAN, and an Internet protocol IP header of the data, and an input parameter P of the AES-GCM is the data. Output of the AES-GCM includes the check value and ciphertext. In this implementation, integrity protection and confidentiality protection need to be performed on the data. When the gateway is a gateway for layer <NUM> forwarding, after receiving a packet sent by the source device, the gateway removes a MAC address of the source device and a MAC address of the destination device, adds an address of the gateway as a MAC address of the source device, and adds a new MAC address of the destination device. Therefore, the input parameter of the AES-GCM does not need to include the MAC address of the source device and the MAC address of the destination device.

To more intuitively reflect different input parameters of the AES-GCM in different scenarios, the following shows, by using <FIG>, content included in the input parameters A and P of the AES-GCM when the source device determines the check value and the ciphertext according to the AES-GCM algorithm. <FIG> shows input content included in the parameter A and the parameter P when the gateway performs layer <NUM> forwarding and the source device performs only integrity protection and anti-replay attack protection on the data. <FIG> shows input content included in the parameter A and the parameter P when the gateway performs layer <NUM> forwarding and the source device performs integrity protection, anti-replay attack protection, and confidentiality protection on the data. <FIG> shows input content included in the parameter A and the parameter P when the gateway performs layer <NUM> forwarding and the source device performs only integrity protection and anti-replay attack protection on the data. <FIG> shows input content included in the parameter A and the parameter P when the gateway performs layer <NUM> forwarding and the source device performs integrity protection, anti-replay attack protection, and confidentiality protection on the data.

<NUM>: Add <NUM> to the value of the PN field after the source device sends a packet.

<NUM>: The destination device receives the packet sent by the source device.

<NUM>: The destination device parses the packet, and determines, based on the first field included in the header of the first VLAN, whether to perform security verification on the packet.

If the destination device determines, based on the first field, not to perform security verification on the packet, the destination device does not perform step <NUM> or step <NUM>.

If the destination device determines, based on the first field, to perform verification on the packet, the destination device performs step <NUM> and step <NUM>.

For example, it is specified that when the value of the first field is 0x99F6, the destination device performs security verification on the packet. If the destination device determines, after parsing the packet, that the first field is 0x99F6, the destination device determines that security verification needs to be performed on the packet. If the destination device determines, after parsing the packet, that the first field is not 0x99F6, the destination device determines that security verification does not need to be performed on the packet. In other words, if the destination device determines, after parsing the packet, that the first field is not a preset value, for example, is not 0x99F6, the destination device does not perform a subsequent step related to security verification.

<NUM>: The destination device verifies, based on the PN field, whether the received packet is a replayed packet.

If the value of the PN field is not greater than a locally stored value of the PN field, it is determined that the packet is a replayed packet. In this case, the destination device does not perform step <NUM>. To be specific, if determining that the packet is a duplicate packet, the destination device discards the packet, does not verify integrity of the packet, and does not decrypt the packet.

<NUM>: The destination device calculates the check value by using the AES-GCM algorithm, or the source device calculates the check value and the ciphertext by using the AES-GCM algorithm.

In a possible implementation, the destination device determines, based on the value of the AE field, whether to decrypt the packet. For example, it is pre-specified that if the value of the AE field is 0x1, it indicates that decryption is required, or if the value of the AE field is 0x0, it indicates that decryption is required. In this case, if the destination device determines, based on the AE field, that decryption is not required, the destination device determines the check value based on the output of the AES-GCM, and verifies integrity of the packet based on the check value. If the destination device determines, based on the AE field, that decryption is required, the destination device determines the check value and plaintext based on the output of the AES-GCM.

In a possible implementation, if the destination device is a gateway, and the gateway is a gateway for layer <NUM> forwarding, the input parameter K of the AES-GCM is the first key, the first key is obtained by the destination device through calculation based on the pre-shared key PSK and the ID of the first VLAN, the input parameter IV of the AES-GCM is the value of the counter-related PN field, the input parameter A of the AES-GCM includes the header of the first VLAN, the ID of the first VLAN, the data that is encrypted, and an Internet protocol IP header of the packet, and an input parameter C of the AES-GCM is null. A second check value is obtained based on output of the AES-GCM. In this implementation, only integrity protection needs to be performed on the data. If the second check value obtained through calculation based on the AES-GCM is the same as a received first check value, the destination device determines that the packet is complete; or if the second check value is different from the received first check value, the destination device determines that the packet is incomplete. If the second check value is different from the first check value, the AES-GCM returns a failure (fail). In this case, even if the AE field is set to indicate that decryption is required, decryption is not required. When the second check value is the same as the first check value, integrity check succeeds. If the AE field is set to indicate that decryption is required, the packet is decrypted.

In a possible implementation, if the destination device is a gateway, and the gateway is a gateway for layer <NUM> forwarding, the input parameter K of the AES-GCM is the first key, the first key is obtained through calculation based on the pre-shared key PSK and the ID of the first VLAN, the input parameter IV of the AES-GCM is the value of the counter-related PN field, the input parameter A of the AES-GCM includes the header of the first VLAN, the ID of the first VLAN, the data that is encrypted, an Internet protocol IP header of the packet, the physical MAC address of the source device, and the MAC address of the destination device, and an input parameter C of the AES-GCM is null. A second check value is obtained based on output of the AES-GCM. In this implementation, only integrity protection needs to be performed on the data.

In a possible implementation, if the destination device is a gateway, and the gateway is a gateway for layer <NUM> forwarding, the input parameter K of the AES-GCM is the first key, the input parameter IV of the AES-GCM is the value of the counter-related PN field, the input parameter A of the AES-GCM includes the header of the first VLAN, the ID of the first VLAN, and an Internet protocol IP header of the packet, and an input parameter C of the AES-GCM is the ciphertext. Output of the AES-GCM includes the check value and the data that is decrypted. In this implementation, integrity protection and confidentiality protection need to be performed on the data.

In a possible implementation, if the destination device is a gateway, and the gateway is a gateway for layer <NUM> forwarding, the input parameter K of the AES-GCM is the first key, the input parameter IV of the AES-GCM is the value of the counter-related PN field, the input parameter A of the AES-GCM includes the header of the first VLAN, the ID of the first VLAN, the physical MAC address of the source device, and the MAC address of the destination device, and an input parameter C of the AES-GCM includes the ciphertext and an Internet protocol IP header of the packet. Output of the AES-GCM includes the check value and the data that is decrypted. In this implementation, integrity protection and confidentiality protection need to be performed on the data.

To more intuitively reflect different input parameters of the AES-GCM in different scenarios, the following shows, by using <FIG>, content included in the input parameters A and C of the AES-GCM when the destination device determines the check value and decryption according to the AES-GCM algorithm. <FIG> shows input content included in the parameter A and the parameter P when the gateway performs layer <NUM> forwarding and the destination device only performs integrity verification on the data and verifies whether the packet is a duplicate packet. <FIG> shows input content included in the parameter A and the parameter P when the gateway performs layer <NUM> forwarding and the destination device performs integrity verification on the data, verifies whether the packet is a duplicate packet, and performs decryption. <FIG> shows input content included in the parameter A and the parameter P when the gateway performs layer <NUM> forwarding and the destination device only performs integrity verification on the data and verifies whether the packet is a duplicate packet. <FIG> shows input content included in the parameter A and the parameter P when the gateway performs layer <NUM> forwarding and the destination device performs integrity verification on the data, verifies whether the packet is a duplicate packet, and performs decryption.

In a preferred implementation, in this application, an AES-GCM-<NUM> algorithm may be used to output the check value and the ciphertext, or output the check value and plaintext. K may occupy <NUM> bits, IV occupies <NUM> bits, and T occupies <NUM> bits.

The method provided in this application is particularly applicable to security protection for communication between low-performance devices. In a preferred implementation, the solutions provided in this application are applicable to automotive Ethernet. The following describes the solutions provided in this application with reference to this scenario.

A vehicle described in this application may be an internal combustion engine vehicle that uses an engine as a power source, a hybrid vehicle that uses an engine and an electric motor as a power source, an electric vehicle that uses an electric motor as a power source, or the like.

To facilitate understanding of this solution, a structure of the vehicle is first described in an embodiment of this application with reference to <FIG> is a schematic diagram depicting the structure of the vehicle according to an embodiment of this application.

The vehicle may include various subsystems, such as a travel system <NUM>, a sensor system <NUM>, a control system <NUM>, one or more peripheral devices <NUM>, a power supply <NUM>, and a user interface <NUM>. Optionally, the vehicle may include more or fewer subsystems, and each subsystem may include a plurality of components. In addition, each subsystem and component of the vehicle may be interconnected in a wired or wireless manner (for example, Bluetooth).

The travel system <NUM> may include a component that provides power for the vehicle to move. In an embodiment, the travel system <NUM> may include an engine <NUM>, an energy source <NUM>, a transmission apparatus <NUM>, and wheels <NUM>.

The engine <NUM> may be an internal combustion engine, an electric motor, an air compression engine, or a combination of other types of engines, for example, a hybrid engine including a gasoline engine and an electric motor, or a hybrid engine including an internal combustion engine and an air compression engine. The engine <NUM> converts the energy source <NUM> into mechanical energy. Examples of the energy source <NUM> include gasoline, diesel, other oil-based fuels, propane, other compressed gas-based fuels, ethanol, solar panels, batteries, and other power sources. The energy source <NUM> may also provide energy for another system of the vehicle. The transmission apparatus <NUM> may transmit mechanical power from the engine <NUM> to the wheels <NUM>. The transmission apparatus <NUM> may include a gearbox, a differential, and a drive shaft. In an embodiment, the transmission apparatus <NUM> may further include another component, for example, a clutch. The drive shaft may include one or more shafts that may be coupled to the wheels <NUM>.

The sensor system <NUM> may include a plurality of sensors that sense location information of the vehicle. For example, the sensor system <NUM> may include a positioning system <NUM> (the positioning system may be a global positioning system GPS, a BeiDou system, or another positioning system), an inertial measurement unit (inertial measurement unit, IMU) <NUM>, radar <NUM>, a laser rangefinder <NUM>, and a camera <NUM>. The sensor system <NUM> may further include sensors (for example, an in-vehicle air quality monitor, a fuel gauge, and an oil temperature gauge) in an internal system of the monitored vehicle. Sensor data from one or more of these sensors can be used to detect an object and corresponding features (for example, a location, a shape, a direction, and a speed) of the object. Such detection and identification are key functions of security operations of an autonomous vehicle.

The positioning system <NUM> may be configured to estimate a geographical location of the vehicle, for example, longitude and latitude information of the vehicle. The IMU <NUM> is configured to sense a location and orientation change of the vehicle based on inertial acceleration. In an embodiment, the IMU <NUM> may be a combination of an accelerometer and a gyroscope. The radar <NUM> may sense an object in the ambient environment of the vehicle by using a radio signal, and may be specifically represented as millimeter-wave radar or laser radar. In some embodiments, in addition to sensing the object, the radar <NUM> may be further configured to sense a speed and/or a heading direction of the object. The laser rangefinder <NUM> may sense, by using a laser, an object in an environment in which the vehicle is located. In some embodiments, the laser rangefinder <NUM> may include one or more laser sources, a laser scanner, one or more detectors, and another system component. The camera <NUM> may be configured to capture a plurality of images of the ambient environment of the vehicle. The camera <NUM> may be a still camera or a video camera.

The control system <NUM> controls operations of the vehicle and the components of the vehicle. The control system <NUM> may include various components including a steering system <NUM>, an accelerator <NUM>, a brake unit <NUM>, an electronic control unit (electronic control unit, ECU) <NUM>, and a vehicle control unit (vehicle control unit, VCU) <NUM>.

The steering system <NUM> may operate to adjust a heading direction of the vehicle. For example, in an embodiment, the steering system <NUM> may be a steering wheel system. The accelerator <NUM> is configured to control an operating speed of the engine <NUM> and further control a vehicle speed. The brake unit <NUM> is configured to control the vehicle to decelerate. The brake unit <NUM> may use friction to slow down the wheels <NUM>. In another embodiment, the brake unit <NUM> may convert kinetic energy of the wheels <NUM> into a current. The brake unit <NUM> may alternatively use another form to reduce a rotational speed of the wheels <NUM>, so as to control the vehicle speed. The electronic control unit <NUM> of the vehicle may be implemented as a single ECU or a plurality of ECUs on the vehicle. The single ECU or the plurality of ECUs is/are configured to communicate with the peripheral device <NUM> and the sensor system <NUM>. The ECU <NUM> of the vehicle may include at least one processor <NUM> and a memory (read-only memory, ROM) <NUM>. The at least one processor may be implemented or executed by using one or more general-purpose processors, a content addressable memory, a digital signal processor, an application-specific integrated circuit, a field programmable gate array, any suitable programmable logic device, a discrete gate or transistor logic, a discrete hardware component, or any combination designed to perform the functions described herein. In particular, the at least one processor may be implemented as one or more microprocessors, controllers, micro controller units (micro controller units, MCUs), or state machines. In addition, the at least one processor may be implemented as a combination of computing devices, such as a digital signal processor or microprocessor, a plurality of microprocessors, one or more microprocessors combined with a digital signal processor core, or any other combination of such configurations. The ROM may provide data storage, including storage of an address, a route, and a driving direction in this application.

The VCU <NUM> may provide information such as an engine status, a speed, a gear, and a steering wheel angle of the vehicle for the ECU <NUM>.

The vehicle interacts with an external sensor, another vehicle, another computer system, or a user through the peripheral device <NUM>. The peripheral device <NUM> may include a wireless communications system <NUM>, a navigation system <NUM>, a microphone <NUM>, and/or a speaker <NUM>. In some embodiments, the peripheral device <NUM> provides a means for the user of the vehicle to interact with the user interface <NUM>. For example, the navigation system <NUM> may be implemented as a part of an in-vehicle entertainment system, an in-vehicle display system, an in-vehicle instrument cluster, or the like. In a practical embodiment, the navigation system <NUM> is implemented to include or cooperate with the sensor system <NUM>. The sensor system <NUM> derives a current geographical location of the vehicle in real time or substantially in real time. The navigation system <NUM> is configured to provide navigation data for a driver of the vehicle. The navigation data may include location data of the vehicle, suggested route planned traveling indications, and visible map information for a vehicle operator. The navigation system <NUM> may present the location data to the driver of the vehicle through a display element or another presenting device. The current location of the vehicle may be described by using one or more of the following information: a triangulation location, a latitude/longitude location, x and y coordinates, or any other symbol or any measurement that indicates the geographical location of the vehicle.

The user interface <NUM> may further operate the navigation system <NUM> to receive user input. The navigation system <NUM> may be operated through a touchscreen. The navigation system <NUM> provides a route planning capability and a navigation capability when the user enters geographical location values of start and end points. In another case, the peripheral device <NUM> may provide a means for the vehicle to communicate with another device located in the vehicle. For example, the microphone <NUM> may receive audio (for example, a voice command or other audio input) from the user of the vehicle. Similarly, the speaker <NUM> may output audio to the user of the vehicle. The wireless communications system <NUM> may perform wireless communication with one or more devices directly or through a communications network. For example, the wireless communications system <NUM> may use <NUM> cellular communication such as code division multiple access (code division multiple access, CDMA), EVD0, or global system for mobile communications (global system for mobile communications, GSM)/general packet radio service (general packet radio service, GPRS), or <NUM> cellular communication such as long term evolution (long term evolution, LTE), or <NUM> cellular communication. The wireless communications system <NUM> may communicate with a wireless local area network (wireless local area network, WLAN) by using Wi-Fi. In some embodiments, the wireless communications system <NUM> may directly communicate with a device by using an infrared link, Bluetooth, or ZigBee. Other wireless protocols, for example, various vehicle communications systems, such as the wireless communications system <NUM>, may include one or more dedicated short range communications (dedicated short range communications, DSRC) devices, and these devices may include public and/or private data communication between the vehicle and/or roadside stations.

The power supply <NUM> may supply power to various components of the vehicle. In an embodiment, the power supply <NUM> may be a rechargeable lithium-ion or lead-acid battery. One or more battery packs of such a battery may be configured as a power supply to supply power to the various components of the vehicle. In some embodiments, the power supply <NUM> and the energy source <NUM> may be implemented together, for example, in some pure electric vehicles.

Optionally, one or more of the foregoing components may be installed separately from or associated with the vehicle. For example, the memory <NUM> may exist partially or entirely separate from the vehicle. The foregoing components may be communicatively coupled together in a wired and/or wireless manner.

Optionally, the foregoing components are merely examples. During actual application, components in the foregoing modules may be added or deleted according to an actual requirement. <FIG> should not be understood as a limitation on this embodiment of this application.

The vehicle may be a car, a truck, a motorcycle, a bus, a boat, a lawn mower, a recreational vehicle, a playground vehicle, a construction device, a trolley, a golf cart, or the like. This is not specifically limited in this embodiment of this application.

It should be noted that the vehicle provided in this application may alternatively be an autonomous driving vehicle.

<FIG> describes a functional block diagram of the vehicle, and an automotive Ethernet system in the vehicle is described below. <FIG> is a schematic diagram depicting communication between devices in automotive Ethernet according to an embodiment of this application. <FIG> and <FIG> describe the vehicle from different perspectives. For example, an ECU of each component in a system in <FIG> may be considered as the electronic control unit <NUM> in <FIG>.

As shown in <FIG>, any ECU in <FIG> may be used as a source device in the embodiments of this application, and any ECU other than the selected source device may be used as a destination device in the embodiments of this application. A gateway in <FIG> may be used as a source device in the embodiments of this application in some scenarios, or may be used as a destination device in the embodiments of this application in some other scenarios. The solutions provided in this application may be applied to a device with an automotive Ethernet connection. For example, the device includes but is not limited to a body control module (body control module, BCM), a human machine interface (human machine interface, HMI) system, an advanced driver assistance system (advanced driver assistance system, ADAS) sensing system, a VCU, an on-board diagnostic system (on-board diagnostic system, OBD), a telematics box (telematics box, TBOX), and the gateway shown in <FIG>.

The device provided in this application may be a device connected to the automotive Ethernet, or may be a low-performance device in another scenario, for example, may be a device connected to the Internet of things. Based on the embodiments corresponding to <FIG> and <FIG>, to better implement the foregoing solutions in the embodiments of this application, the following further provides related devices configured to implement the foregoing solutions.

<FIG> is a schematic diagram depicting a structure of a security protection apparatus according to an embodiment of this application. The security protection apparatus is a source device. The security protection apparatus provided in this application may include: an obtaining module <NUM>, configured to obtain a security level of a first virtual local area network VLAN, where the source device and a destination device corresponding to the source device are devices in the first VLAN, the first VLAN is one of a plurality of VLANs that may be included in Ethernet, and each of the plurality of VLANs corresponds to one security level; and a protection module <NUM>, configured to determine, based on the security level of the first VLAN, whether to perform security protection on data to be sent to the destination device.

In a possible implementation, the apparatus may further include: an encapsulation module <NUM>, configured to encapsulate a first packet based on a header of the first VLAN, to obtain a second packet, where the header of the first VLAN may include a first field, a counter-related PN field, and a decryption type-related AE field, the first field is used to indicate the destination device to perform security verification on received data, the PN field is used by the destination device to verify whether the received data is replayed data, the AE field is used by the destination device to determine whether to decrypt the data, and the first packet is a packet obtained after the source device encapsulates the data based on an identifier ID of the first VLAN.

In a possible implementation, the protection module <NUM> is specifically configured to determine, based on the security level of the first VLAN, to perform integrity protection on the data. The apparatus may further include a calculation module <NUM>, configured to determine a check value based on the identifier ID of the first VLAN, the data, and the header of the first VLAN, where the check value is used to verify integrity of the data.

In a possible implementation, the check value is obtained based on output of an Advanced Encryption Standard Galois/Counter Mode AES-GCM, an input parameter K of the AES-GCM is a first key, the first key is obtained through calculation based on a pre-shared key PSK and the ID of the first VLAN, an input parameter IV of the AES-GCM is a value of the counter-related PN field, an input parameter A of the AES-GCM may include the header of the first VLAN, the ID of the first VLAN, the data, and an Internet protocol IP header of the data, and an input parameter P of the AES-GCM is null.

In a possible implementation, the check value is obtained based on output of an Advanced Encryption Standard Galois/Counter Mode AES-GCM, an input parameter K of the AES-GCM is a first key, the first key is obtained through calculation based on a pre-shared key PSK and the ID of the first VLAN, an input parameter IV of the AES-GCM is a value of the counter-related PN field, an input parameter A of the AES-GCM may include the header of the first VLAN, the ID of the first VLAN, the data, an Internet protocol IP header of the data, a physical MAC address of the source device, and a MAC address of the destination device, and an input parameter P of the AES-GCM is null.

In a possible implementation, the protection module <NUM> is further configured to determine, based on the security level of the first VLAN, to perform confidentiality protection on the data. The calculation module <NUM> is further configured to calculate a first key based on a pre-shared key PSK and the identifier ID of the first VLAN. The source device performs encryption calculation on the data based on the first key, to obtain the data that is encrypted.

In a possible implementation, the encrypted data is obtained based on output of an Advanced Encryption Standard Galois/Counter Mode AES-GCM, an input parameter K of the AES-GCM is the first key, an input parameter IV of the AES-GCM is a value of the counter-related PN field, an input parameter A of the AES-GCM may include the header of the first VLAN, the ID of the first VLAN, and an Internet protocol IP header of the data, and an input parameter P of the AES-GCM is the data.

In a possible implementation, the encrypted data is obtained based on output of an Advanced Encryption Standard Galois/Counter Mode AES-GCM, an input parameter K of the AES-GCM is the first key, an input parameter IV of the AES-GCM is a value of the counter-related PN field, an input parameter A of the AES-GCM may include the header of the first VLAN, the ID of the first VLAN, a physical MAC address of the source device, and a MAC address of the destination device, and an input parameter P of the AES-GCM may include the data and an Internet protocol IP header of the data.

In a possible implementation, the protection module <NUM> is further configured to determine, by the source device based on the security level of the first VLAN, to perform anti-replay protection on the data. The source device adds <NUM> to a value of the counter-related PN field each time the source device sends data to the destination device, so that the destination device verifies, based on the PN field, whether the data is replayed data.

In a possible implementation, the protection module <NUM> is further configured to determine, based on the security level of the first VLAN, not to perform security protection on the data.

In a possible implementation, the Ethernet is automotive Ethernet, and the source device and the destination device each are an electronic control unit ECU or a gateway.

<FIG> is a schematic diagram depicting a structure of a security protection apparatus according to an embodiment of this application. The security protection apparatus is a destination device. The apparatus may include: a receiving module <NUM>, configured to receive a packet sent by a source device, where the packet is a packet obtained after the source device encapsulates a first packet based on a header of a first VLAN, and the first packet is a packet obtained after the source device encapsulates, based on an identifier ID of the first VLAN, data to be sent to the destination device; and a parsing module <NUM>, configured to determine, based on a first field that may be included in the header of the first VLAN, whether to perform security verification on the packet.

In a possible implementation, the packet may include a first check value, the first check value is a check value determined by the source device based on the identifier ID of the first VLAN, the data, and the header of the first VLAN, and when the destination device determines to perform security verification on the packet, the apparatus may further include: a check module <NUM>, configured to: determine a second check value based on the identifier ID of the first VLAN, the data, and the header of the first VLAN; and verify integrity of the data by comparing the second check value with the first check value.

In a possible implementation, the second check value is obtained based on output of an Advanced Encryption Standard Galois/Counter Mode AES-GCM, an input parameter K of the AES-GCM is a first key, the first key is obtained by the destination device through calculation based on a pre-shared key PSK and the ID of the first VLAN, an input parameter IV of the AES-GCM is a value of a counter-related PN field, an input parameter A of the AES-GCM may include the header of the first VLAN, the ID of the first VLAN, the data that is encrypted, and an Internet protocol IP header of the packet, and an input parameter C of the AES-GCM is null.

In a possible implementation, the second check value is obtained based on output of an Advanced Encryption Standard Galois/Counter Mode AES-GCM, an input parameter K of the AES-GCM is a first key, the first key is obtained through calculation based on a pre-shared key PSK and the ID of the first VLAN, an input parameter IV of the AES-GCM is a value of a counter-related PN field, an input parameter A of the AES-GCM may include the header of the first VLAN, the ID of the first VLAN, the data that is encrypted, an Internet protocol IP header of the packet, a physical MAC address of the source device, and a MAC address of the destination device, and an input parameter C of the AES-GCM is null.

In a possible implementation, the check module <NUM> is further configured to: determine, based on a decryption type-related AE field that may be included in the packet, whether to decrypt the data; and when determining, based on the AE field, to decrypt the data, perform decryption calculation on the data based on a first key, to obtain the data that is decrypted, where the first key is a key obtained by the destination device through calculation based on a pre-shared key PSK and the identifier ID of the first VLAN.

In a possible implementation, the decrypted data is obtained based on output of an Advanced Encryption Standard Galois/Counter Mode AES-GCM, an input parameter K of the AES-GCM is the first key, an input parameter IV of the AES-GCM is a value of a counter-related PN field, an input parameter A of the AES-GCM may include the header of the first VLAN, the ID of the first VLAN, and an Internet protocol IP header of the packet, and an input parameter C of the AES-GCM is the data that is encrypted.

In a possible implementation, the decrypted data is obtained based on output of an Advanced Encryption Standard Galois/Counter Mode AES-GCM, an input parameter K of the AES-GCM is the first key, an input parameter IV of the AES-GCM is a value of a counter-related PN field, an input parameter A of the AES-GCM may include the header of the first VLAN, the ID of the first VLAN, a physical MAC address of the source device, and a MAC address of the destination device, and an input parameter C of the AES-GCM may include the data that is encrypted and an Internet protocol IP header of the packet.

In a possible implementation, when the destination device determines, based on the first field that may be included in the header of the first VLAN, to perform security verification on the packet, the check module <NUM> is further configured to verify, based on a PN field that may be included in the header of the first VLAN, whether the received data is replayed data. The destination device stores a value of the PN field if the data is non-replayed data.

In a possible implementation, the check module <NUM> may be further configured to parse the packet, and determine, based on the first field that may be included in the header of the first VLAN, not to perform security verification on the packet.

In a possible implementation, the source device and the destination device each are an electronic control unit ECU or a gateway in automotive Ethernet.

It should be noted that content such as information exchange and an execution process between the modules/units in the security protection apparatus is based on a same concept as the method embodiments corresponding to <FIG> and <FIG> in this application. For specific content, refer to the descriptions in the foregoing method embodiments in this application.

In addition, it should be noted that a name of a module is not limited in the embodiments of this application.

The security protection apparatus may be specifically an ECU.

It should be noted that, for a specific implementation and beneficial effects of performing the security protection method by the security protection apparatus or the ECU, refer to the descriptions in the method embodiments corresponding to <FIG> and <FIG>.

An embodiment of this application further provides an ECU, a vehicle, or an electronic device. <FIG> shows a security protection apparatus according to an embodiment of this application. The security protection apparatus may be an ECU, a vehicle, or an electronic device. The security protection apparatus includes a processor <NUM>. The processor <NUM> is coupled to a memory <NUM>. The memory <NUM> stores program instructions. When the program instructions stored in the memory <NUM> are executed by the processor <NUM>, the methods described in <FIG> and <FIG> are performed.

An embodiment of this application further provides a computer-readable storage medium. The computer-readable storage medium stores a program used for security protection. When the program is run on a computer, the computer is enabled to perform the steps performed by the source device and the destination device in the methods described in the embodiments shown in <FIG> and <FIG>.

An embodiment of this application further provides a computer program product. When the computer program product runs on a computer, the computer is enabled to perform the steps performed by the source device and the destination device in the methods described in the embodiments shown in <FIG> and <FIG>.

The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the procedures or the functions according to the embodiments of this application are all or partially generated. The computer may be a general-purpose computer, a dedicated computer, a computer network, or another programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or may be transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wired (for example, a coaxial cable, an optical fiber, or a digital subscriber line (DSL)) or wireless (for example, infrared, radio, or microwave) manner. The computer-readable storage medium may be any usable medium accessible by a computer, or a data storage device, such as a server or a data center, integrating one or more usable media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, or a magnetic tape), an optical medium (for example, a DVD), a semiconductor medium (for example, a solid state disk (solid state disk, SSD)), or the like.

An embodiment of this application further provides a circuit system. The circuit system includes a processing circuit and a storage circuit. The processing circuit and the storage circuit are configured to perform the steps performed by the source device and the destination device in the methods described in the embodiments shown in <FIG> and <FIG>. The processing circuit may be any suitable type of computing unit, for example, a microprocessor, a digital signal processor (digital signal processor, DSP), a field programmable gate array (field programmable gate array, FPGA), an application-specific integrated circuit (application-specific integrated circuit, ASIC), or any other form of circuit. The storage circuit may be volatile (volatile) and/or non-volatile (non-volatile). For example, the storage circuit may be a register, a cache, or the like. Specifically, a volatile storage circuit may include a cache memory, and a non-volatile storage circuit may include a flash memory.

The security protection apparatus or the ECU provided in the embodiments of this application may be specifically a chip. The chip includes a processing unit and a communications unit. The processing unit may be, for example, a processor, and the communications unit may be, for example, an input/output interface, a pin, or a circuit. The processing unit may execute computer-executable instructions stored in a storage unit, so that the chip in a server performs the security protection apparatuses described in the embodiments shown in <FIG> and <FIG>. Optionally, the storage unit is a storage unit in the chip, for example, a register or a cache, or the storage unit may be a storage unit that is at a radio access device end and that is located outside the chip, for example, a read-only memory (read-only memory, ROM), another type of static storage device that can store static information and instructions, or a random access memory (random access memory, RAM).

In addition, it should be noted that the described apparatus embodiments are merely examples. Some or all of the modules may be selected based on an actual requirement to achieve the objectives of the solutions of the embodiments. In addition, in the accompanying drawings of the apparatus embodiments provided in this application, a connection relationship between modules indicates that there is a communication connection between the modules, and the communication connection may be specifically implemented as one or more communications buses or signal cables.

Claim 1:
A security protection method, comprising:
obtaining, by a source device, a security level of a first virtual local area network VLAN, wherein the source device and a destination device corresponding to the source device are devices in the first VLAN, the first VLAN is one of a plurality of VLANs comprised in an Ethernet, each of the plurality of VLANs corresponds to one security level, and the security level of each of the plurality of VLANs is preset; and
(<NUM>) determining, by the source device using the security level of the first VLAN, whether to perform security protection on data to be sent to the destination device;
characterized in that
when the source device determines (<NUM>), using the security level of the first VLAN, to perform security protection on the data to be sent to the destination device, the method further comprises:
(<NUM>) encapsulating, by the source device, a first packet using a header of the first VLAN, to obtain a second packet, wherein the header of the first VLAN comprises a first field, a counter-related PN field, and a decryption type-related AE field, the first field is used to indicate the destination device to perform security verification on the data sent to the destination device, the PN field is used by the destination device to verify whether the data sent to the destination device is replayed data, the AE field is used by the destination device to determine whether to decrypt the data sent to the destination device, and wherein the first packet is a packet obtained after the source device encapsulates, using an identifier ID of the first VLAN, the data to be sent to the destination device.