Trusted remote management units, network switches, and remote access methods

Abstract

Embodiments of the present disclosure relate to a trusted remote management unit (RMU). A network switch is provided, comprising: a plurality of ports for communicating over a network; a processing circuit system, separate from a CPU, configured to process inbound frames received from the network via the ports and to send outbound frames to the network via the ports; and an RMU, in response to a command received from a host device outside the network switch, the RMU is separate from the CPU and configured to: receive a remote access request frame from the host device via one of the ports, wherein at least a portion of the remote access request frame is encrypted; decrypt the remote access request frame; and in response to successful decryption of a portion of the remote access request frame, access one or more configuration registers of the network switch independently of accessing any CPU, assemble a remote access response frame according to the remote access request frame, at least a portion of the remote access response frame is encrypted, and send the remote access response frame to the host device.

Description

Technical Field

[0001] The present disclosure relates generally to the field of communications, and more particularly to a network switch and a method for remote access in the network switch. Background Art

[0002] The Remote Management Unit (RMU) is a functional block designed in multiple automotive and SOHO network switches of Marvell Automotive BU to access its internal registers via Ethernet frames. It is designed to be a more efficient way to access registers and status in addition to the Serial Management Interface (SMI). Using Ethernet frames allows faster access to large information databases than the SMI consisting of two pins, without the need for an external SMI master. Summary of the invention

[0003] One of the purposes of the present invention is to solve the problem of effectiveness in network communication.

[0004] According to a first aspect of the present disclosure, a network switch is provided, comprising: a plurality of ports for communicating over a network; a processing circuit system, separate from a central processing unit (CPU), the processing circuit system being configured to process inbound frames received from the network via the ports and to send outbound frames to the network via the ports; and a remote management circuit system (RMU), responsive to a command received from a host device external to the network switch, the RMU being separate from the CPU and being configured to: receive a remote access request frame from the host device via one of the ports, wherein at least a portion of the remote access request frame is encrypted; decrypt the remote access request frame; and in response to successful decryption of a portion of the remote access request frame, access one or more configuration registers of the network switch based on the remote access request frame, independently of accessing any CPU, to assemble a remote access response frame, wherein at least a portion of the remote access response frame is encrypted, and send the remote access response frame to the host device.

[0005] In certain embodiments of the present disclosure, the remote management circuitry is configured to decrypt a portion of a remote access request frame and encrypt a portion of a remote access response frame independently of any CPU.

[0006] In certain embodiments of the present disclosure, a network switch is provided on one or more integrated circuits without the presence of CPU circuitry.

[0007] In certain embodiments of the present disclosure, the remote access request frame also carries authentication information, and wherein the remote management circuit system is configured to use the authentication information to authenticate the host device, and to assemble a remote access response frame only in response to: (i) successful decryption of a portion of the remote access request frame, and (ii) successful authentication of the host device.

[0008] In certain embodiments of the present disclosure, the remote management circuitry is configured to decrypt a portion of the remote access request frame using a symmetric encryption scheme and to authenticate the host device using an asymmetric encryption scheme.

[0009] In certain embodiments of the present disclosure, the network is an automotive network in a vehicle, and wherein the remote management circuitry is configured to receive the remote access request frame from outside the vehicle or from inside the vehicle.

[0010] According to a second aspect of the present disclosure, a method for remote access in a network switch is provided, the method comprising: receiving a remote access request frame from a host device outside the network switch via a port of the network switch, wherein at least a portion of the remote access request frame is encrypted; decrypting the remote access request frame separately from any central processing unit (CPU); and in response to successful decryption of a portion of the remote access request frame, independently of accessing any CPU: accessing one or more configuration registers of the network switch according to the remote access request frame, assembling a remote access response frame, at least a portion of the remote access response frame being encrypted, and sending the remote access response frame to the host device.

[0011] In certain embodiments of the present disclosure, decrypting a portion of a remote access request frame and encrypting a portion of a remote access response frame are performed independently of any CPU.

[0012] In certain embodiments of the present disclosure, the remote access request frame also carries authentication information, and the method further includes: using the authentication information to authenticate the host device; and constructing a remote access response frame only in response to: (i) successful decryption of a portion of the remote access request frame, and (ii) successful authentication of the host device.

[0013] In certain embodiments of the present disclosure, decrypting a portion of the remote access request frame includes applying a symmetric encryption scheme, and wherein authenticating the host device includes applying an asymmetric encryption scheme. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The above and other features, advantages and aspects of the various embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. In the accompanying drawings, the same or similar reference numerals represent the same or similar elements, wherein:

[0015] Figure 1 is a block diagram schematically illustrating an example embodiment of an RMU having a locally connected host;

[0016] Figure 2 is a block diagram schematically illustrating an example embodiment of an RMU with a remotely connected host;

[0017] Figure 3 is a block diagram schematically illustrating an example embodiment of an RMU request frame with a DSA tag;

[0018] Figure 4 is a block diagram schematically illustrating an example embodiment of an RMU request frame having an Ether type DSA tag;

[0019] Figure 5 is a block diagram schematically illustrating an example embodiment of an RMU response frame with a DSA tag;

[0020] Figure 6 is a block diagram schematically illustrating an example of security risks on communications;

[0021] Figure 7 is a block diagram schematically illustrating an example embodiment of a trusted RMU architecture; and

[0022] Figure 8 is a flow chart schematically illustrating an example embodiment of a trusted RMU access flow. DETAILED DESCRIPTION

[0023] The following will describe the embodiments of the present disclosure in more detail with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments described herein, which are instead provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0024] In the description of the embodiments of the present disclosure, the term "including" and similar terms should be understood as open inclusion, that is, "including but not limited to". The term "based on" should be understood as "based at least in part on". The term "one embodiment / implementation" or "the embodiment / implementation" should be understood as "at least one embodiment / implementation". The terms "first", "second", etc. may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0025] An RMU (remote management unit, also referred to herein as a "remote management circuit system") is a functional block in a network switch (such as an Ethernet switch) that is configured to process remote access request Ethernet frames from an external host device and configure the network switch and / or return configuration / status in a response Ethernet frame.

[0026] To prevent unauthorized devices from manipulating and eavesdropping on request / response Ethernet frames, a trusted access mechanism is applied in the RMU to perform authentication of remote access request Ethernet frames.

[0027] This mechanism utilizes asymmetric cryptography where the source device uses a private key for encryption and the RMU uses a public key hash (stored on the device) to verify the public key (transmitted on the Ethernet frame) and uses the public key for decryption.

[0028] The RMU also uses the public key to encrypt a response Ethernet frame that conveys the private key hash value (stored on the device) and other information for setting up subsequent secure communications (e.g., setting up MAC security (MACsec) using the appropriate encryption keys).

[0029] The various tasks of the RMU are typically performed only in hardware or firmware without access to any CPU associated with the network switch. In some embodiments, the network switch includes a CPU, in which case the disclosed technology relieves the CPU of the burden of remote management tasks.

[0030] The RMU receives remote access request Ethernet frames from an external host device, decodes the remote access request Ethernet frames to configure a network switch (also referred to as a "device" in this document for simplicity) or obtain device configuration / status information, and constructs a remote access response Ethernet frame to transmit the obtained device configuration / status information (returned to the host that initiated the remote access request).

[0031] Additionally, utilizing Marvell Distributed Switching Architecture (DSA) tags, Ethernet frames intended for the RMU can be distinguished from normal traffic. Working in conjunction with the switch functionality, remote management frames can be forwarded to any connected switch, meaning a single CPU can be used to control a single device or a group of devices locally or remotely.

[0032] Without additional protection for remote access request and response Ethernet frames, the contents of the Ethernet frames will be fully observable by intermediate devices and can be recovered from the media by certain techniques. Since the contents are visible, a malicious device can forge or manipulate remote access request / response Ethernet frames.

[0033] In some embodiments, in order to prevent the remote access request / response Ethernet frames from being affected by unauthenticated devices (which may manipulate and / or eavesdrop on the remote access request / response Ethernet frames), the remote access request and response Ethernet frames communicated between the host device and the RMU are encrypted using authentication information. The RMU also performs authentication and decryption of the remote access request Ethernet frames.

[0034] RMU Function Overview

[0035] In some embodiments, the basic function of the RMU is to transmit configuration information to a target device (a target network switch that supports the RMU) and to transmit configuration / status information from a target device using Ethernet frames. The Ethernet frame can come from a local (but still external) host connected to the Ethernet port of the target device, or from a remote host that communicates with the target device and other devices in between. The following figure illustrates a network switch equipped with an RMU in an embodiment. In addition to the RMU, the switch typically includes multiple ports and a processing circuit system. The processing circuit system is configured to process inbound frames received from the network via the port, and is configured to send outbound frames to the network via the port.

[0036] Figure 1 is a block diagram schematically illustrating an example embodiment of an RMU with a locally connected host. Figure 2 is a block diagram schematically illustrating an example embodiment of an RMU with a remotely connected host.

[0037] When an Ethernet frame is received on a physical port of a device with the RMU function enabled, the frame is presented to the ingress logic, which examines the frame's DA (the first 6 bytes of frame data after the SFD) and DSA or EtherType DSA tag (13 to 16 or 20 bytes after the SFD) to determine whether the frame is a remote access request or response frame (RMU request frame or RMU response frame) and whether the frame is targeted at the device. If the frame is a remote access request and is targeted at the device, the frame is presented to the RMU block for further processing. Otherwise, the frame is forwarded normally. The three figures below show the required DSA or EtherType DSA tag for the frame so that the frame can be classified as an RMU request frame or an RMU response frame.

[0038] Figure 3 is a block diagram schematically illustrating an example embodiment of an RMU request frame with a DSA tag. Figure 4 is a block diagram schematically illustrating an example embodiment of an RMU request frame with an EtherType DSA tag. Figure 5 is a block diagram schematically illustrating an example embodiment of an RMU response frame with a DSA tag.

[0039] When the frame is identified as an RMU request frame, the RMU block will parse the first 6 bytes in the MAC client data field to determine the type of RMU request frame and determine which registers should be accessed. And the RMU block constructs an RMU response frame using the information obtained from the device and sends it out on the physical port.

[0040] RMU Security Considerations

[0041] By using the RMU block, the target device can be efficiently configured and checked by a local or remote CPU (or other types of devices that can initiate RMU request frames and / or accept RMU response frames). However, this convenience introduces security risks to the communication between the external host (local or remote) and the target device.

[0042] When RMU frames are used in communications between a remote host and a target device, any device connected to an intermediate device (between the remote host and the target device) that understands the RMU frame format can forge RMU request frames to manipulate the configuration of the target device and obtain the status of the device. In addition, a malicious device can also forge RMU response frames to deceive the remote host when the malicious device sees an RMU request frame. Even when the host is directly connected to the Ethernet port of the target device, it is possible to eavesdrop on the data transmitted on the line through certain techniques.

[0043] Figure 6 is a block diagram schematically illustrating an example of security risks on communications.

[0044] To prevent security risks, the "MAC Client Data" portion of the RMU frame that transmits configuration and / or status information should be encrypted so that malicious devices cannot inspect and manipulate the content without knowing the secret. In addition, other authentication information (also encrypted) should be transmitted on the "MAC Client Data" portion so that both the host and the target device can know whether the RMU request frame and response frame are from the real other party.

[0045] Password for RMU frames

[0046] Generally, there are two types of ciphers used for encryption and decryption: symmetric key ciphers and asymmetric key ciphers.

[0047] With symmetric key ciphers, the sender and receiver of a message use a single common key to encrypt and decrypt messages.

[0048] For asymmetric key cryptography, a pair of keys (public key and private key) is used to encrypt and decrypt messages. The public key and private key are different. The public key is used for encryption and the private key is used for decryption, and vice versa.

[0049] Symmetric key cryptography is faster and simpler than asymmetric key cryptography, but the problem is that the sender and receiver must exchange keys in some secure way. In this case, both the host and the RMU block need to know the symmetric key before communication. If the symmetric key is used for a long time without being refreshed, there will be security risks.

[0050] Asymmetric key ciphers can be a better solution for RMU frames even though they have a higher complexity than symmetric key ciphers. Since different keys are used for encryption and decryption, there is no need to worry about exposing a key (e.g., a public key) if the content of the RMU frame is not sensitive to the device. For example, the RMU request frame is used to initiate communication between the RMU blocks of the host and the target device.

[0051] A public key can be transmitted on the RMU request frame without the need for synchronization prior to communication, and different key pairs can be used whenever the host initiates communication with the RMU block of the target device (assuming that the RMU block has enough information to distinguish whether the RMU request frame comes from an authenticated host).

[0052] The RMU block of the target device may also use the public key to encrypt the response frame to transmit device sensitive information. For example, a random symmetric key may be generated by the RMU block and transmitted (using the received public key) on the encrypted response frame to ensure the security of subsequent communications within a certain time or a certain number of request / response frames.

[0053] Trusted RMU Architecture

[0054] The following figure shows the overall architecture of a trusted RMU according to an embodiment, which has both asymmetric and symmetric decryption / encryption engines for initial and subsequent communications (highlighted in green background). The RMU is implemented entirely in hardware and / or firmware, and its operation does not rely on or involve any CPU of the switch (if a CPU exists).

[0055] Figure 7 is a block diagram schematically illustrating an example embodiment of a trusted RMU architecture.

[0056] When the RMU block is configured as an untrusted RMU (legacy RMU), the received request frame on the Ethernet port of the device is stored in the RMU memory (see arrow 1) and processed by the request frame decoding engine (see arrow 4), regardless of when the entire request frame is stored. The request frame decoding engine processes the stored request frame and accesses the switch register to apply a new configuration or obtain the device status (see arrow 5), and also notifies the response frame generation engine with appropriate data (see arrow 6) to construct a response frame on the RMU memory (see arrow 7). When the construction of the response frame is completed, the frame is read out from the RMU memory and sent out on the Ethernet port (see arrow 10).

[0057] When the RMU block is configured as a trusted RMU, the stored request frame should be decrypted before being processed by the request frame decoding engine (see arrow 2a / 3a or 2b / 3b). If the frame can be decrypted correctly and verified as coming from an authenticated host, the decryption engine should notify both the request frame decoding engine and the response frame generation engine to continue the process. Otherwise, the decryption engine should notify the request frame decoding engine not to proceed further and notify the response frame generation engine to build an error response frame to indicate the failure of the decryption process and / or the authentication process. If the process is allowed to continue and a subsequent response frame is built on the RMU memory, it should be encrypted before being sent out on the device's Ethernet port (see arrow 8a / 9a or 8b / 9b).

[0058] (1) Trusted communication request

[0059] By using asymmetric key cryptography, a request frame for setting up trusted communications can be used to transmit a public key because the request frame only needs to contain device-insensitive information such as the type of RMU request frame (e.g., indicating that the request frame is for setting up trusted communications) and some encrypted data to distinguish whether the transmitted public key is correct.

[0060] When the requested frame is identified for a trusted communication setup, the RMU block shall decrypt the encrypted data by using the public key (both transmitted on the request frame) and perform the following two checks (public key verification):

[0061] 1) Compare the decrypted data with the public key or its hash value (calculated by some algorithm).

[0062] 2) Compare the public key or its hash value with the pre-stored value on the device.

[0063] Any device can see the value of the public key and the decrypted data by monitoring the request frame, but if they do not know the private key, they cannot forge a different request frame. The first check ensures that the public key does correspond to the private key used for encryption, and the second check ensures that the public key comes from an authenticated host (assuming that only the host has a private and public key pair).

[0064] By using the pre-stored public key or its hash value, the RMU block can distinguish whether the request frame for setting up trusted communication comes from an authenticated host.

[0065] If the public key verification passes, the RMU shall send a response frame on the device's Ethernet port to confirm the acceptance of the trusted communication setup. Otherwise, a response frame shall be constructed to indicate the rejection of the trusted communication setup and sent out on the device's Ethernet port.

[0066] (2) Trusted Communication Response

[0067] By using asymmetric key cryptography, the response frame used to confirm the acceptance of the trusted communication setup can encrypt its security / device sensitive data with the public key extracted from the received request frame. In this case, all other devices that do not know the private key cannot decrypt the response frame.

[0068] The security / device sensitive data on the response frame should include the following two parts:

[0069] 1) Randomly generated symmetric key.

[0070] 2) Encrypted secret identifier (via generated symmetric key).

[0071] When the host receives the trusted communication setup response frame, the symmetric key may be recovered by using the private key, and the secret identifier may be recovered by using the private key and then by using the recovered symmetric key.

[0072] The secret identifier (e.g., the private key used or its hash value) should be pre-stored on the target device and known only to the host. Because the secret identifier is not only encrypted by the public key but also by the randomly generated symmetric key, other devices cannot manipulate the response frame using different symmetric keys (even if they know the public key) without knowing the secret identifier. In this way, the host can distinguish whether the trusted communication setup response frame comes from the RMU block of the target device.

[0073] (3)Secure communication

[0074] After the host confirms that the trusted communication setup response frame is from the RMU block of the target device, the establishment of trusted communication is completed. The host and RMU block use symmetric keys to protect subsequent communications, in which device sensitive data on subsequent request and response frames are encrypted by the symmetric key.

[0075] In addition, the host can resend the request frame for setting up trusted communication after a certain time of secure communication to restart the trusted communication setting process. In this case, the RMU block can generate another random symmetric key for further communication.

[0076] Figure 8is a flow chart schematically illustrating an example embodiment of a trusted RMU access flow.

[0077] Figure 8 The left side shows a portion of the process performed in the host device. Figure 8 The right side of the diagram shows a portion of the process performed in the RMU. Initially, the host sends a request to set up a trusted communication session with the RMU. The RMU verifies the authenticity of the request and, if successful, sends a response frame. The setup portion of the process uses asymmetric encryption.

[0078] Once a session is established, the host will send a remote access request frame. The RMU decrypts the request frame and, if successful, accesses the relevant registers and composes and sends a remote access response frame. This part of the process uses symmetric encryption. In the same session, the host can send any desired number of remote access request frames.

[0079] The above description is only an optional embodiment of the present disclosure and is not intended to limit the present disclosure. For those skilled in the art, the present disclosure may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.

Claims

1. A network switch, comprising: Multiple ports for communicating over the network; processing circuitry, separate from a central processing unit (CPU), configured to process inbound frames received from the network via the port and to send outbound frames to the network via the port; as well as a remote management circuitry (RMU) responsive to a command received from a host device external to the network switch, the RMU being separate from the CPU and configured to: receiving a remote access request frame from the host device via one of the ports, wherein at least a portion of the remote access request frame is encrypted; decrypting the remote access request frame; as well as In response to successful decryption of the portion of the remote access request frame, constructing a remote access response frame based on the remote access request frame, accessing one or more configuration registers of the network switch independently of accessing any CPU, at least a portion of the remote access response frame being encrypted, and sending the remote access response frame to the host device.

2. The network switch of claim 1, wherein the remote management circuitry is configured to decrypt the portion of the remote access request frame and encrypt the portion of the remote access response frame independently of any CPU.

3. The network switch of claim 1, wherein the network switch is provided on one or more integrated circuits without CPU circuitry.

4. The network switch of claim 1 , wherein the remote access request frame also carries authentication information, and wherein the remote management circuit system is configured to use the authentication information to authenticate the host device, and to construct the remote access response frame only in response to: (i) successful decryption of the portion of the remote access request frame, and (ii) successful authentication of the host device.

5. The network switch of claim 4, wherein the remote management circuitry is configured to decrypt the portion of the remote access request frame using a symmetric encryption scheme and to authenticate the host device using an asymmetric encryption scheme. 6 . The network switch of claim 1 , wherein the network is an automotive network in a vehicle, and wherein the remote management circuitry is configured to receive the remote access request frame from outside the vehicle or from inside the vehicle.

7. A method for remote access in a network switch, the method comprising: receiving, via a port of the network switch, a remote access request frame from a host device external to the network switch, wherein at least a portion of the remote access request frame is encrypted; decrypting the remote access request frame separately from any central processing unit (CPU); and In response to successful decryption of the portion of the remote access request frame, independently of accessing any CPU, performing: One or more configuration registers of the network switch are accessed based on the remote access request frame, a remote access response frame is constructed, at least a portion of the remote access response frame is encrypted, and the remote access response frame is sent to the host device.

8. The method of claim 7, wherein decrypting the portion of the remote access request frame and encrypting the portion of the remote access response frame are performed independently of any CPU.

9. The method according to claim 7, wherein the remote access request frame also carries authentication information, and wherein the method further comprises: authenticating the host device using the authentication information; and constructing the remote access response frame only in response to: (i) successful decryption of the portion of the remote access request frame, and (ii) successful authentication of the host device.

10. The method of claim 9, decrypting the portion of the remote access request frame comprises applying a symmetric encryption scheme, and wherein authenticating the host device comprises applying an asymmetric encryption scheme.

Images