Method and apparatus for secure key distribution

Abstract

The invention relates to a method and apparatus for secure key distribution. A new approach is proposed for supporting secure key distribution between a host and a resource-constrained Ethernet bridge using MACSec, wherein the resource-constrained Ethernet bridge is hardware with multiple hardware blocks but without a processor or non-volatile storage. In the proposed method, existing hardware modules using a resource-constrained Ethernet bridge completely implement a secure key distribution protocol. First, a session encryption key is independently generated by a host and an Ethernet bridge. If the SEKs match, the host is configured to generate and distribute a security association key (SAK) to the Ethernet bridge for installation thereon. After the SAK is installed on the Ethernet bridge, a secure communication channel is established between the host and the Ethernet bridge. A secure communication channel may be used for secure communication of sensitive data collected by an Ethernet bridge from a plurality of electronic devices.

Description

[0001] Cross Reference to Related Applications

[0002] This application is a non-provisional application and claims the benefit of and priority to provisional application 63 / 672,044, filed July 16, 2024, the entire contents of which are incorporated by reference in their entirety. TECHNICAL FIELD

[0003] The present disclosure relates to Ethernet devices, and in particular to methods and apparatus for secure key distribution between a host and a resource-constrained Ethernet bridge. BACKGROUND

[0004] An Ethernet bridge is a hardware device connected to a plurality of electronic devices that converts data received from the plurality of electronic devices into Ethernet frames / packets and transmits the Ethernet frames / packets to a host over Ethernet. In some embodiments, the electronic devices are sensing devices configured to sense / collect data at a location where the electronic devices are deployed. As non-limiting examples, the electronic devices can be, but are not limited to, video cameras, and the video camera Ethernet bridge is a hardware device that converts frames captured by the video cameras into Ethernet frames / packets and sends to a host. In one example, the video cameras and the video camera Ethernet bridge are deployed in a vehicle.

[0005] The data collected by the Ethernet bridge can be sensitive, for example, containing data of vehicle motion, environment, and vehicle passengers. Such sensitive information needs to be protected with adequate security mechanisms. Media Access Control Security or MACsec is a well-known standard in IEEE Local Area Network (LAN) standards for protecting Layer 2 TCP / IP network traffic. Extensible Authentication Protocol over a Local Area Network in conjunction with the MACsec Key Agreement (EAPOL-MKA) protocol in IEEE 802. lx-2020 standard provides a method for automatic distribution of MACsec keys and monitoring of participants of established secure associations / tunnels. However, EAPOL-MKA requires a state machine to be implemented in software to be stored in memory (e.g., static random access memory) and executed by a processor (e.g., CPU), and only hardware implementation on a resource-constrained Ethernet bridge can take up more silicon space and memory.

[0006] The foregoing examples of the related art and their associated limitations, are intended to be illustrative and not exclusive. Other limitations of the related art will become apparent to those of skill in the art upon reading this description and studying the drawings. BRIEF DESCRIPTION OF DRAWINGS

[0007] Various aspects of the disclosure can be better understood when read from the following detailed description in conjunction with the accompanying drawings. Note that, in accordance with the standard practice in the industry, various features are not drawn to scale. In fact, the dimensions of the various features can be arbitrarily increased or decreased for clarity. Included in the detailed description are specific details for the purpose of providing a thorough understanding of the

[0008] Figure 1A An example of a schematic diagram depicting a system 100 that supports secure host-to-ethernet bridge key distribution is depicted in accordance with an aspect of the present embodiment; Figure 1B Another example of a system that supports host-to-ethernet bridge key distribution is described, wherein the system further comprises a switch communicatively connected between the host 102 and the plurality of ethernet bridges in accordance with an aspect of the present embodiment.

[0009] Figure 2 An example of an ethernet bridge having a plurality of hardware blocks that can be configured by a host is depicted in accordance with an aspect of the present embodiment.

[0010] Figure 3A An example of sending periodic frames / packets from an ethernet bridge to a host to find potential participants of a MACsec session is shown; Figure 3B An example of a SAK distribution packet sent from a host to an ethernet bridge is described; Figure 3C An example of an install status frame containing an Install_Status field for tracking the status of SAK installation is described; Figure 3D An example of a heartbeat frame in accordance with an aspect of the present embodiment is depicted.

[0011] Figure 4 A flowchart of an example of a process that supports secure host-to-ethernet bridge key distribution in accordance with an aspect of the present embodiment is depicted. DETAILED DESCRIPTION

[0012] The following disclosure provides many different embodiments, or examples, for implementing different features of the subject matter. Each example is provided to illustrate specific embodiments of the disclosure, and is not intended to limit the scope of the disclosure. Additionally, the disclosure can refer to subject matter in terms of functional or logical block diagrams, and / or using computer science or information science terminology. Such descriptions are for convenience of explanation for understanding only, and are not intended to limit the subject matter in any way. Furthermore, the instant disclosure can be repeated with variations as appropriate to the individual embodiments.

[0013] Before various embodiments are described in detail, it is to be understood that the embodiments are not limited to what can be conceived as the embodiments can be changed. It is also to be understood that the particular embodiments described and / or illustrated herein have elements that can be readily separated from the specific embodiment and optionally combined with any of a number of other embodiments without departing from the scope of the specific embodiment described herein. It is also to be understood that the terminology used herein is for the purpose of describing certain concepts and should not be regarded as limiting. Unless otherwise defined, all technical terms used in this application have the same meaning as commonly understood by one of ordinary skill in the art to which the embodiments belong.

[0014] A new approach is proposed that takes into account systems and methods for secure key distribution between a host and a resource-constrained Ethernet bridge, where the resource-constrained Ethernet bridge is a hardware with multiple hardware (e.g., application-specific integrated circuit) blocks but without a processor or non-volatile storage (e.g., flash memory). Under the proposed approach, the secure key distribution protocol is fully implemented using the existing MACsec hardware modules of the resource-constrained Ethernet bridge. First, the session encryption key is independently generated by the host and the Ethernet bridge. Second, the host and the Ethernet bridge exchange frames / data packets to determine whether they have the same SEK. If the SEKs match, the host will be configured to distribute the MACSec key (also known as the security association key or SAK key) to the Ethernet bridge for installation thereon. After the SAK is installed on the Ethernet bridge, a secure communication channel is established between the host and the Ethernet bridge. The secure communication channel can then be used for the secure communication of sensitive data collected by the Ethernet bridge from multiple electronic devices.

[0015] Under the proposed approach, the entire protocol for MACsec key distribution involves a simple transaction and is implemented in the hardware of the resource-constrained Ethernet bridge with minimal resources (e.g., without using a CPU or flash memory and with minimal volatile memory, such as static random access memory). Under the key distribution protocol, a secure communication channel can be established with the exchange of a small amount of data, such as less than 100 bytes for the SAK distribution frames / data packets. Additionally, hardware modules already available in the Ethernet bridge, such as the Advanced Encryption Standard (AES) in Galois / Counter Mode (GCM), i.e., AES-GCM, and / or the Cipher-based Message Authentication Code (CMAC), i.e., AES-CMAC, can be reused for the session encryption key derivation.

[0016] As discussed herein, each of the host or the Ethernet bridge is referred to as a peer in the Ethernet communication channel, and each message, frame, or packet is referred to as an Ethernet packet, including the content / data generated by the host or the Ethernet bridge and exchanged between the peers.

[0017] Figure 1A An example of a schematic of a system 100 that supports secure host-to-ethernet bridge key distribution is described. Although the components described in the figure are functionally independent, this description is merely for illustration. It is clear that the components depicted in the figure can be combined or divided into separate software, firmware, and / or hardware components. Moreover, it is also clear that these components can be executed on the same or multiple hosts regardless of how they are combined or divided, and that multiple hosts can be connected through one or more networks.

[0018] In Figure 1A In an example, the system 100 includes a host 102, an Ethernet bridge 104, and a plurality of electronic devices 106 connected to the Ethernet bridge 104. Here, the host 102 is a computing unit / appliance / device having one or more processors and software instructions stored in a storage unit (e.g., non-volatile memory of the computing unit) for implementing one or more processes. When the software instructions are executed, the computing unit loads at least a subset of the software instructions into memory, which becomes a specialized instruction for implementing the process. The process can also be at least partially contained in the computing unit where the computer program code is loaded and / or executed, such that the host becomes a specialized computing unit for implementing the process. For non-limiting examples, the host 102 can be a computing device, a communication device, a storage device, or any computing device capable of running software components. As non-limiting examples, the computing device can be, but is not limited to, a server, a notebook computer, a desktop computer, a tablet computer, a Google Android device, an iPhone, an iPad, and a voice-controlled speaker or controller.

[0019] In Figure 1A In an example, the Ethernet bridge 104 includes a plurality of hardware blocks, each configured to perform a specific task. In some embodiments, unlike the host 102, the Ethernet bridge 104 is resource-constrained, the Ethernet bridge 104 has no processor, no non-volatile memory (e.g., flash memory), and the Ethernet bridge 104 has limited volatile storage (e.g., static random access memory). The Ethernet bridge 104 is configured to interact with the host 102 through one or more communication networks (not shown), which can be, but are not limited to, the Internet, an intranet, a wide area network (WAN), a local area network (LAN), a wireless network, Bluetooth, Wi-Fi, and a mobile communication network, for communication between engines. The physical connection of the communication network and the communication protocol is well known to those skilled in the art.

[0020] Figure 2 An example of the Ethernet bridge 104 is depicted, which has a plurality of hardware blocks that can be configured by the host 102. As Figure 2The Ethernet bridge 104 includes, in the example shown, an ingress block 202 configured to collect data from the plurality of electronic devices 106. In some embodiments, the Ethernet bridge 104 further includes a data converter block 204 configured to convert the data collected from the plurality of electronic devices 106 into one or more Ethernet frames / packets. In some embodiments, the Ethernet bridge 104 further includes a resource-constrained MKA block 206 configured to receive the SAK distributed from the host 102 and install the SAK on the Ethernet bridge 104. In some embodiments, the Ethernet bridge 104 further includes a MACsec block 208 configured to encrypt the one or more Ethernet packets before transmitting them to the host 102 and decrypt Ethernet packets received from the host 102. Note that the MACsec module 208 only functions when the SAK has been successfully installed on the Ethernet bridge 104. In some embodiments, the Ethernet bridge 104 further includes an egress block 212 configured to communicate (transmit and receive) packets to the host 102 and a frame parser 210 configured to parse the packets received from the host 102 and retrieve content (e.g., SAK) from the received packets. In some embodiments, the Ethernet bridge 104 further includes a set of registers 214 configured to temporarily maintain data generated by the plurality of hardware blocks of the Ethernet bridge 104 during operation.

[0021] In Figure 1A In the example, each of the plurality of electronic devices 106 can be a sensing device or a sensor configured to collect data at a location where the sensing device is deployed and provide the collected data to the Ethernet bridge 104. For example, each electronic device 106 can be, but is not limited to, an audio / video enabled device such as an image and / or video camera, an audio recording device, a GPS enabled device, a radar, a Light Detection and Ranging (LiDAR) device, and other types of electronic devices capable of collecting data. Once the Ethernet bridge 104 receives the collected data, the Ethernet bridge 104 is configured to convert the received data into a plurality of Ethernet frames / packets for transmission to the host 102. In some embodiments, the Ethernet bridge 104 and the plurality of electronic devices 106 are both deployed in an automobile.

[0022] Figure 1BAnother example of a schematic diagram depicting a system 150 that supports host-to-ethernet bridge key distribution is depicted, where the system 150 further includes a switch 152 communicatively connected between the host 102 and a plurality of Ethernet bridges 104, where each of the plurality of Ethernet bridges 104 is connected to a plurality of electronic devices 106. In some embodiments, the host 102 is configured to select one of the plurality of Ethernet bridges 104 at a time by correspondingly configuring the switch 152, such that the host 102 can distribute a SAK to one of the plurality of Ethernet bridges 104 to establish a peer-to-peer communication channel with the one of the plurality of Ethernet bridges 104 to receive data from the electronic devices 106 associated with the Ethernet bridge 104. Once communication with the particular Ethernet bridge 104 is complete, the host 102 can close the peer-to-peer communication channel and establish a new communication channel with another Ethernet bridge 104 in order to receive data from the electronic devices 106 associated with the Ethernet bridge 104.

[0023] Since the data collected by the electronic devices 106 can be sensitive, the data needs to be communicated from the Ethernet bridges 104 to the host 102 over a secure communication channel. As described below, a protocol scheme for secure key distribution is implemented with a hardware block in the Ethernet bridge 104, as shown in Figure 2

[0024] A typical MACsec encryption scheme with a cipher suite, such as GCM-AES-128, uses the following formula, such as the AES-GCM encryption formula:

[0025] (E, TAG) = AES GCM (Input, AAD, IV, Key)

[0026] where E is the encrypted Ethernet data packet, TAG is the AES-GCM tag, Input is the Ethernet frame of data / content, AAD is the combination of the Ethernet and MACsec headers, the initial value (IV) is the combination of the secure channel identifier (SCI) and the port number, and Key is the security association key (SAK) of the secure communication channel. In some embodiments, the SCI is defined in MACsec as the combination of a MAC address and a port number.

[0027] ​To establish a secure communication channel from both peers, the sending side (e.g., Ethernet bridge 104) and the receiving side (e.g., host 102), one or more of the following parameters are required: SCI, minimum packet number (PN), next PN (both PNs can be set to 0 during configuration), confidentiality obtained from the user and / or protocol, confidentiality offset (always 0 when encrypting the entire data frame), and association number (AN) of the current SAK. Once the communication and / or hard-coded, these parameters can be used to establish a secure communication channel and generate and install the SAK to establish a secure association.

[0028] The proposed secure communication method between host 102 and Ethernet bridge 104 has two steps, the first step is to implement an encryption scheme for host 102 and Ethernet bridge 104, and the second step is to implement a key distribution protocol, which uses the encryption scheme for SAK distribution and installation on Ethernet bridge 104. In the first step, a session encryption key (SEK) is derived by each of host 102 and Ethernet bridge 104 using a pseudo-random function (PRF) defined in NIST SP 800 108r1. The SEK can then be used to encrypt communications related to implementing the key distribution protocol between host 102 and Ethernet bridge 104. In some embodiments, host 102 and / or Ethernet bridge 104 are configured to determine the peer (Ethernet bridge 104 or host 102) with which they will communicate by periodically sending messages / frames / packets encrypted with the SEK to ping the peer. Based on the response capability of the peer, e.g., the peer can reply to the message and encrypt the response with its SEK, host 102 and / or Ethernet bridge 104 can determine whether their SEKs match, so that they can encrypt and decrypt the packets exchanged between them using the same SEK under the encryption scheme. In some embodiments, AES-GCM is used as the encryption scheme for secure message communication and key distribution as described above. Alternatively, if a PRF is used, AES-CMAC can be used as the encryption scheme; if a PRF is used, a hash-based message authentication code (HMAC) can be used as the key derivation function (HKDF). Since the communication between host 102 and Ethernet bridge 104 is encrypted, there is no need for key wrapping, and there is no need to have or use a key wrapping hardware block in Ethernet bridge 104.

[0029] If the SEKs of the peers match, i.e., host 102 and Ethernet bridge 104 have the same SEK, the second step is to track the distribution of the SAK (MACsec key) generated by host 102 using, for example, a True Random Number Generator (TRNG) or a Strong Pseudo Random Number Generator (PRNG) to Ethernet bridge 104, and to install the SAK on Ethernet bridge 104 according to the key distribution protocol. In some embodiments, the key distribution protocol is a Layer 2 protocol and requires the use of an Ethernet type created to define the MACsec key distribution protocol. In some embodiments, the key distribution protocol also provides a mechanism to track peer activity to detect interruptions in the established secure communication channel, where such tracking is particularly important when an older SAK is updated. In some embodiments, the protocol is a simple server-client communication mechanism, where host 102 is the fixed key (SAK) server and Ethernet bridge 104 is the fixed supplicant of the SAK. In some embodiments, tracking is enabled by sharing the AN of the distributed SAK and the latest and old transmit (tx) and receive (rx) secure association (SA) channel bits.

[0030] In some embodiments, it is assumed that the following are configured before the encryption scheme and protocol implementation steps described above. For pre-shared key configuration, host 102 is configured to pre-program a connection association key (CAK) to Ethernet bridge 104 using a one-time password (OTP). In terms of configuration, the read / write register group 214 of Ethernet bridge 104 is configured to maintain one or more of the following pre-programmed and configurable parameters: CAK name (CKN), confidentiality / security scheme (e.g., integrity and encryption), key length, minimum PN, next PN, PN expiration value, periodic packet interval (default 1 second), and heartbeat packet interval (default 2 seconds). Note that the protocol supports generating 128-bit keys, which provides strong security, but the protocol can be extended to support 256-bit key sizes by updating the register configuration.

[0031] In some embodiments, in the first step described above, host 102 and Ethernet bridge 104 can generate the SEK using two methods. In some embodiments, one method is to use HKDF for SEK generation, which requires fewer input parameters. The following formula shows the SEK generation using the HKDF scheme:

[0032] SEK=HKDF(CAK, Constant_SEK, CKN)

[0033] Where Constant_SEK is a text string constant, for example, "session key".

[0034] In some embodiments, another approach is to iteratively generate SEK in counter mode using AES-CMACPRF defined in NIST SP 800 108r1:

[0035] For iterator = 1 to NSEK = SEK|AES_CMAC(CAK, iterator|label|0|constant|Key_Len);

[0036] Where N=2 represents a 128-bit key length, and N=3 represents a 256-bit key length. The iterator is the loop counter used when deriving SEK, labeled Constant_SEK, with CKN as the constant, and Key_Len is the key length (in bits).

[0037] In some embodiments, the key distribution protocol used in the second step described above involves exchanging some parameters to identify the SAK and to create and track MACsec sessions. The following is an example of the SAK generation and distribution process:

[0038] In step 1, Ethernet bridge 104 uses its SCI to create a secure transmission channel with host 102.

[0039] In step 2, Ethernet bridge 104 initiates a MACsec session to send its ID (the unique identifier of Ethernet bridge 104, Id_EB) and SCI along with the sequence number (SQ) as an Ethernet frame / packet to host 102.

[0040] In step 3, Ethernet bridge 104 encrypts Ethernet frames / packets containing its ID and SCI with SQ, and periodically sends the encrypted Ethernet frames / packets as frames / packets to host 102 via a secure transmission channel. Figure 3A An example of periodic frames / packets sent from Ethernet bridge 104 to host 102 is shown to identify potential participants in a MACsec session. Figure 3A As shown, the plaintext portion of the packet, such as the packet header, includes the version, device ID, and SQ. This portion is used in part as Additional Authentication Data (AAD) for the AES-GCM encryption process. The remaining data packet content is encrypted using AES-GCM-128. In some embodiments, the SQ is incremented for each frame / packet transmitted by Ethernet bridge 104. The SQ starts at 0, counts to a maximum defined value, and is rounded to 0 after reaching the maximum defined value. The protocol ensures that no rounding occurs during the key update process that detects potential SQ rounding, as discussed below.

[0041] In step 4, host 102 receives the encrypted frame / packet and verifies the tag on the frame. If the verification passes, host 102 decrypts the frame. If the verification fails, host 102 discards the frame. Verifying the tag and successfully decrypting the frame proves that Ethernet bridge 104 is a legitimate sender.

[0042] In step 5, once Ethernet bridge 104 is proven to be a legitimate sender, host 102 creates a secure transmit channel using its SCI and a secure receive channel using the SCI of Ethernet bridge 104. Host 102 then generates a SAK using a TRNG or strong PRNG source in the hardware. The key number (KN) of the SAK starts from 1 and increments each time a new SAK corresponding to that MACsec session is distributed. In some embodiments, the session is identified by participant IDs exchanged during session initialization.

[0043] In step 6, host 102 uses SEK to distribute the newly generated SAK along with the rest of the encrypted packet back to Ethernet bridge 104 via a secure channel. Figure 3B An example of an SAK distribution packet sent from host 102 to Ethernet bridge 104 is described. In some embodiments, the encrypted packet is a unicast frame with the MAC address of Ethernet bridge 104 as its destination address. In some embodiments, if the SAK is installed with its corresponding AN, host 104 also tracks the installation of the SAK on Ethernet bridge 104 by sending its installation status bit in the Install_Status field of the frame / packet.

[0044] In step 7, Ethernet bridge 104 receives the SAK distribution packet and verifies its authenticity by verifying the presence of the AES-GCM tag in the packet. If the data packet is verified, Ethernet bridge 104 decrypts the data packet, retrieves the SAK from the data packet, installs the SAK, and sends its installation status back to host 102 in the Install_Status field of the installation status frame. Figure 3C An example of an installation status frame that includes an Installation_Status field for tracking the installation status of the SAK is described. In some embodiments, this is a unicast frame with the MAC address of host 102 as its destination address.

[0045] In step 8, once both host 102 and Ethernet bridge 104 confirm that SAK has been successfully installed and that a secure transmit and receive channel has been established, host 102 and Ethernet bridge 104 begin secure communication with each other through the secure channel. In some embodiments, host 102 and Ethernet bridge 104 exchange heartbeat frames to monitor the activity of both parties. b. If either party encounters a situation where the other is no longer in use, it will return to a special mode in which the secure receive channel is closed, as detailed below.

[0046] In some embodiments, host 102 is configured to use sequence numbers (SQs) of packets exchanged between host 102 and Ethernet bridge 104 as the primary mechanism for detecting packet replay used in network attacks. In some embodiments, the SQ is combined with the device identifier (ID) of Ethernet bridge 104 generated during a MACsec session to create an IV, which is used as an input parameter for encryption under AES-GCM. The receiver of a data packet continuously tracks the expected next SQ based on the previous SQ it received. An attacker can replay the received frame. Under a key distribution protocol, once a replay frame with a replay SQ is received, the receiver can identify whether the received packet is a replay by matching the received SQ with the expected SQ. In some embodiments, an SQ is added to detect replay and then used with the session ID value during IV generation. In some embodiments, the sender may have already sent the frame, but the receiver missed receiving the packet due to packet loss. A threshold can be defined and configured to allow packets that may have been lost (and thus retransmitted) not to be identified as replay packets.

[0047] In some embodiments, host 102 is configured to initiate a key update, i.e., SAK regeneration, by detecting the expiration of the PN in a packet received from Ethernet bridge 104. In some embodiments, host 102 periodically performs a MACsec packet number check by comparing the PN to a configurable PN expiration value. For example, the PN in a MACsec frame is 4 bytes, and for the default cipher suite of GCM-AES-128, the default value of the PN can be derived from the IEEE 802.1x-2020EAPOL-MKA frame as 0xC0000000. In some embodiments, the last SAK distribution frame in use is repeated (e.g., up to 2 times) by host 102 and Ethernet bridge 104 until the current SAK is updated and the new SAK is fully installed on Ethernet bridge 104. In some embodiments, the key update process can be optimized based on the hardware capabilities / configuration of the peer. If the hardware of host 102 can directly install the new SAK, both the latest_tx and latest_rx bits in the Install_Status field can be set to 1 and sent by host 102. Ethernet bridge 104 has the same key installation hardware capability and includes both the latest_tx and old_rx bits in its response. Once a response frame is received from Ethernet bridge 104, host 102 enables a new transmit and receive security association (SA) corresponding to the updated SAK and removes the transmit and receive SA corresponding to the old SAK. A new SAK distribution frame is sent, indicating that the SAK is installed on Ethernet bridge 104 by setting the old_tx and old_rx bits to 1 and including the AN of the currently distributed SAK.

[0048] In some embodiments, host 102 and Ethernet bridge 104 are configured to exchange one or more heartbeat messages between them to determine whether another peer is active. In some embodiments, heartbeat messages are exchanged periodically, and a lost heartbeat message from a peer indicates that the peer is offline. If host 102 detects a lost heartbeat message, host 102 will stop communicating with Ethernet bridge 104 and enter a silent mode in which host 102 does not announce information about the MACsec session and will not send an SAK distribution frame until host 102 receives packets again from Ethernet bridge 104. Instead, host 102 will simply listen for frames that match certain SEKs. In some embodiments, host 102 will delete its transmit and receive SAs and all receive secure channels corresponding to the session. If Ethernet bridge 104 detects a lost heartbeat message, Ethernet bridge 104 will delete its transmit and receive SAs and all receive secure channels corresponding to the session. In some embodiments, Ethernet bridge 104 will delete its identity / ID, create a new ID, and reset its SQ starting from 0. In some embodiments, Ethernet bridge 104 will recreate new packets and periodically ping host 102 to establish a connection.

[0049] In some embodiments, as described above, the CAK is pre-programmed into the OTP for pre-shared key configuration. The CAK can be reused for a long time along with the generated SEK. Cryptanalysis could lead to the reconstruction of the CAK with sufficient received messages, which could affect the security of the entire SAK distribution protocol using the SEK. In one embodiment, the size of the CAK can be increased, for example from 128 bits to 256 bits, to make cryptanalysis more difficult. In another embodiment, to avoid leakage, the CAK is provided in a secure environment, and after the CAK is successfully provided, traces of the CAK are securely erased elsewhere.

[0050] Figure 4 A flowchart 400 illustrates an example of a process supporting the distribution of keys from a secure host to an Ethernet bridge. Although the diagram depicts functional steps in a specific order for illustrative purposes, the process is not limited to any particular order or arrangement of steps. Those skilled in the art will understand that the individual steps depicted in the diagram can be omitted, rearranged, combined, and / or modified in various ways.

[0051] exist Figure 4In the example, flowchart 400 begins at block 402, where an SEK is generated under an encryption scheme, and packets encrypted using the SEK are sent from the Ethernet bridge to the host of the MACsec session. Flowchart 400 continues to step 404, where, if the SEK generated by the Ethernet bridge matches the SEK generated by the host, the Ethernet bridge receives an SAK generated by the host and encrypted using the SEK for the MACsec session. Flowchart 400 continues to step 406, where the SAK is decrypted and installed on the Ethernet bridge. Flowchart 400 ends at step 408, where a secure communication channel is established between the host and the Ethernet bridge using the SAK, and communication between the host and the Ethernet bridge is encrypted using the SEK.

[0052] The foregoing description of various embodiments of the claimed subject matter is provided for illustrative and descriptive purposes. It is not intended to be exhaustive or limit the claimed subject matter to the precise form disclosed. Many modifications and variations will be apparent to those skilled in the art. The embodiments were chosen and described in order to best illustrate the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the claimed subject matter, the various embodiments, and the various modifications suitable for the particular intended use.

Claims

1. A system comprising: an Ethernet bridge having a plurality of hardware blocks, wherein one or more of the plurality of hardware blocks are configured to: generate a session encryption key (SEK) under a cryptographic scheme and send a packet encrypted using the SEK to a host for a media access control security (MACsec) session; receive a secure association key (SAK) generated by the host and encrypted using the SEK for the MACsec session if the SEK generated by the Ethernet bridge matches the SEK generated by the host; decrypt and install the SAK on the Ethernet bridge; and establish a secure communication channel between the host and the Ethernet bridge using the SAK, wherein all communications between the host and the Ethernet bridge are encrypted with the SEK.

2. The system of claim 1, wherein: the Ethernet bridge is resource constrained, has no processor and has no non-volatile memory.

3. The system of claim 1, wherein: the Ethernet bridge is configured to collect data from a plurality of electronic devices; and convert the collected data into one or more Ethernet packets for sending to the host.

4. The system of claim 3, wherein: each of the plurality of electronic devices is a sensing device.

5. The system of claim 4, wherein: both the Ethernet bridge and the plurality of electronic devices are deployed in an automobile.

6. The system of claim 4, wherein: each of the plurality of electronic devices is one of: an audio / video enabled device, a GPS enabled device, a radar, a light detection and ranging (LiDAR) device, and other types of electronic devices capable of collecting data.

7. The system of claim 1, wherein: the Ethernet bridge and the host are configured to use a hash-based message authentication code (HMAC)-based Extract-and-Expand Key Derivation Function (HKDF) as the cryptographic scheme for SEK generation.

8. The system of claim 1, wherein: the Ethernet bridge and the host are configured to use an AES cipher-based message authentication code (CMAC) as the cryptographic scheme for SEK generation.

9. The system of claim 1, further comprising: the host configured to determine whether the SEK generated by the Ethernet bridge matches the SEK generated by the host; generate and distribute the SAK to the Ethernet bridge, wherein the SAK is encrypted with the SEK.

10. The system of claim 9, further comprising: a switch communicatively coupled between the host and a plurality of Ethernet bridges, wherein each of the plurality of Ethernet bridges is connected to a plurality of electronic devices.

11. The system of claim 10, wherein: The host is configured to configure the switch to select one of the plurality of Ethernet bridges at a time, such that the host is configured to distribute a SAK to be installed on the one of the plurality of Ethernet bridges to establish a secure communication channel with the one of the plurality of Ethernet bridges to receive data from the plurality of electronic devices associated with the Ethernet bridge.

12. The system of claim 9, wherein: The host is configured to generate the SAK using a true random number generator (TRNG) or a strong pseudo-random number generator (PRNG).

13. The system of claim 9, wherein: The host is configured to track the status of installation of the SAK on the Ethernet bridge.

14. The system of claim 9, wherein: The host is configured to detect packet replay used in a network attack using sequence numbers (SQ) of packets exchanged between the host and the Ethernet bridge.

15. The system of claim 9, wherein: The host is configured to initiate regeneration of the SAK by detecting expiration of a packet number (PN) of a packet received from the Ethernet bridge.

16. The system of claim 9, wherein: The host and the Ethernet bridge are configured to exchange one or more heartbeat messages between them to determine whether the other peer is active / alive.

17. The system of claim 9, wherein: The host is configured to pre-program a connectivity association key (CAK) to the Ethernet bridge in a one-time password (OTP), wherein the CAK is provided in a secure environment to avoid leakage.

18. A hardware-implemented method comprising: generating a session encryption key (SEK) under a cryptographic scheme and sending a packet encrypted using the SEK from an Ethernet bridge to a host for a media access control security (MACsec) session; receiving a secure association key (SAK) generated by the host and encrypted using the SEK for the MACsec session if the SEK generated by the Ethernet bridge matches the SEK generated by the host; decrypting and installing the SAK on the Ethernet bridge; and establishing a secure communication channel between the host and the Ethernet bridge using the SAK, wherein communications between the host and the Ethernet bridge are encrypted using the SEK.

19. The method of claim 18, wherein: The Ethernet bridge is resource-constrained, has no processor and has no non-volatile memory.

20. The method of claim 18, further comprising: using a hash-based message authentication code (HMAC)-based message extract and expand key derivation function (HKDF) as the cryptographic scheme for SEK generation.

21. The method of claim 18, further comprising: using an AES cipher-based message authentication code (CMAC) as the cryptographic scheme for SEK generation.

22. The method of claim 18, further comprising: determining whether the SEK generated by the Ethernet bridge matches the SEK generated by the host; generating and distributing the SAK to the Ethernet bridge, wherein the SAK is encrypted with the SEK.

23. The method of claim 22, further comprising: configuring a switch communicatively coupled between the host and the plurality of Ethernet bridges to select one of the plurality of Ethernet bridges at a time, such that the host is configured to distribute a SAK to be installed on one of the plurality of Ethernet bridges to establish a secure communication channel with one of the plurality of Ethernet bridges to receive data from a plurality of electronic devices associated with the Ethernet bridge.

24. The method of claim 22, further comprising: generating the SAK using a true random number generator (TRNG) or a strong pseudo random number generator (PRNG).

25. The method of claim 22, further comprising: tracking the status of installation of the SAK on the Ethernet bridge.

26. The method of claim 22, further comprising: detecting packet replay used in a network attack using sequence numbers (SQ) of packets exchanged between the host and the Ethernet bridge.

27. The method of claim 22, further comprising: initiating regeneration of the SAK by detecting expiration of a packet number (PN) of a packet received from the Ethernet bridge.

28. The method of claim 22, further comprising: exchanging one or more heartbeat messages between the host and the Ethernet bridge to determine whether the other peer is active / alive.

29. The method of claim 22, further comprising: pre-programming a connectivity association key (CAK) of the Ethernet bridge in a one-time password (OTP), wherein the CAK is provided in a secure environment to avoid leakage.

30. A system comprising: means for generating a session encryption key (SEK) under an encryption scheme and sending a packet encrypted using the SEK from an Ethernet bridge to a host for a media access control security (MACsec) session; means for receiving a secure association key (SAK) generated by the host and encrypted using the SEK for the MACsec session if the SEK generated by the Ethernet bridge matches the SEK generated by the host; means for decrypting and installing the SAK on the Ethernet bridge; and means for establishing a secure communication channel between the host and the Ethernet bridge using the SAK, wherein communication between the host and the Ethernet bridge is encrypted using the SEK.

Images