Method and system for protecting an in-vehicle Ethernet link

Abstract

A method and system for protecting an in-vehicle Ethernet link is disclosed. According to one embodiment, a method includes receiving a public key of an authenticator, a random number, and a challenge from an authenticator via an unsecure channel. A private key of a peer supplied to the peer is accessed from a local storage device at the peer. A state machine calculates a session key for the peer based on the random number, the public key of the authenticator, and the private key of the peer. The state machine calculates a peer response to the challenge using the session key for the peer and a symmetric cryptographic function.

Description

Technical Field

[0001] The present disclosure relates generally to communication systems, and more particularly to methods and systems for protecting in-vehicle Ethernet links. Background Art

[0002] Modern vehicles and autonomous vehicles (AVs) rely on a variety of hardware sensors connected to a central processing unit (CPU) and / or a graphics processing unit (GPU) to implement various control and / or artificial intelligence (AI) systems that can be used to assist drivers, or to drive vehicles without human intervention. Such sensors are typically connected to processors using high-speed wired communication links. In many applications, high-speed data can be transmitted from a source to a sink (e.g., from a sensor to a processor) substantially simultaneously with the transmission of low-speed data in the opposite direction.

[0003] These communication links are susceptible to security issues such as eavesdropping. Eavesdropping of such links can be used to remotely monitor sensor signals and inject malicious signals into the stream to be received by the processor. Malicious data can also be used to improperly program sensors, which can cause accidents when driving the vehicle. In addition, malicious data may be displayed on the driver console display, which can cause driver errors.

[0004] Currently, the Mobile Industry Processor Interface (MIPI) Camera Serial Interface-2 (CSI-2) is a connectivity protocol widely used in modern vehicles and AVs for sensor connectivity. CSI-2 data is typically transmitted over coaxial or twisted pair wiring using a serializer and a deserializer (SerDes) typically included in a physical layer PHY device, which includes a transmitter and / or a receiver. Such a link can be easily accessed by a malicious agent. Other high-speed links that can be used in vehicles include PCIe, USB, HDMI, Thunderbolt, and Ethernet. Hackers can also access these types of links. Examples of sensors used in modern vehicles and / or AVs include cameras, LIDAR, RADAR, GPS, etc.

[0005] Some conventional systems feature a secure communication link provided by employing a symmetric system in which devices at both ends of the data / control communication link are capable of generating encryption keys for secure communications and performing various operations related to encryption and decryption. Figure 1, in an Ethernet-based security system 100 using 802.1x and 802.1AE including an authenticator 102 and a client 104, encryption is performed by an 802.1AE encryption module 106a at the authenticator 102 and by another 802.1AE encryption module 106b at the client 104. In the authenticator 102, session keys for encryption and decryption are provided to the 802.1AE module 106a by an 802.1x software engine 108a. The 802.1x software engine 108a runs on a processor 110a. The 802.1x software engine 108a can communicate with an external server 112.

[0006] The processor 110a may access a storage device 114a that may provide a whitelist of devices that may communicate with the authenticator 102 and may also store encryption key(s) and certificate(s) generated and received by the 802.1x software engine 108a. The processor 110a may also communicate with a data source / receiver 116a (e.g., a video source, a sensor, a display, another processor, etc.). Additionally, the processor 110a may communicate with and / or control an 802.1AE module 106a and a physical layer transceiver (PHY) 118a.

[0007] The configuration at the client 104 is generally symmetrical because, in the client 104, session keys for encryption and decryption are provided to the 802.1AE module 106b by the 802.1x software engine 108b running on the processor 110b. The processor 110b has access to a storage device 114b, which can provide a whitelist of devices that can communicate with the client and can also store the encryption key(s) and certificate(s) generated and received by the 802.1x software engine 108b. In addition, the processor 110b communicates with a data source / receiver 116b (e.g., a video source, a sensor, a display, another processor, etc.), and communicates with and / or controls the 802.1AE module 106b and the physical layer transceiver (PHY) 118b.

[0008] In this configuration, both sides of the data and control link 120 are considered symmetric from a key generation and exchange perspective. In a typical networked security system such as system 100, this is not a problem because the two devices at both ends of the data / control link 120 typically contain powerful processors capable of executing the software stacks required to perform symmetric key generation and implement the exchange protocol.

[0009] However, in the case of modern vehicles, including smart and autonomous vehicles and Internet of Things (IoT) applications, the device at one end of the link typically contains a processor, while the device at the other end is typically a sensor with limited processing power and typically not equipped to run a software stack. As a result, conventional safety systems are typically not suitable for use in vehicles, IoT applications, and other similar systems. Summary of the invention

[0010] A method and system for protecting an in-vehicle Ethernet link is disclosed. According to one embodiment, a method includes receiving a public key of an authenticator, a random number, and a challenge from an authenticator via an unsecure channel. A private key of a peer supplied to the peer is accessed from a local storage device at the peer. A state machine calculates a session key of the peer based on the random number, the public key of the authenticator, and the private key of the peer. The state machine calculates a peer response to the challenge using the session key of the peer and a symmetric cryptographic function. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The present invention will become more apparent in view of the attached drawings and the accompanying detailed description. The embodiments depicted therein are provided by way of example and not by way of limitation, wherein the same reference numerals / labels generally refer to the same or similar elements. However, in different drawings, different reference numerals / labels may be used to refer to the same or similar elements. The drawings are not necessarily to scale, with emphasis instead being placed on illustrating various aspects of the present invention. In the drawings:

[0012] Figure 1 A typical server-client authentication system is schematically depicted;

[0013] Figure 2 Schematically depicts a system for performing client-initiated authentication, according to one embodiment, featuring a client with limited processing capabilities;

[0014] Figure 3 schematically depicts an authentication system for performing client authentication according to one embodiment, which features a client having limited processing capabilities;

[0015] Figure 4 is a flow chart illustrating a process by which an authenticator can authenticate a client according to one embodiment;

[0016] Figure 5 illustrates a sequence of events and messages exchanged between an authenticator (also referred to as a server) and a client (also referred to as a peer to be authenticated) when authentication is successful according to one embodiment; and

[0017] Figure 6Illustrated is a sequence of events and messages exchanged between an authenticator / server and a client / peer to be authenticated when authentication fails according to one embodiment. DETAILED DESCRIPTION

[0018] The following disclosure provides different embodiments or examples for realizing the different features of the present subject matter. Specific examples of components and arrangements are described below to simplify the present disclosure. Of course, these are merely examples and are not intended to be limiting.

[0019] A method and system for protecting an in-vehicle Ethernet link is disclosed. According to one embodiment, a method includes receiving an authenticator's public key, a random number, and a challenge from an authenticator via an unsecure channel. A private key of a peer supplied to the peer is accessed from a local storage device at the peer. A state machine calculates a session key of the peer based on the random number, the authenticator's public key, and the peer's private key. The state machine calculates a peer response to the challenge using the peer's session key and a symmetric cryptographic function.

[0020] In various embodiments, a short asymmetric challenge ("SAC") is provided that can support authentication and key derivation. Embodiments of the SAC technology can be integrated with EAP, and as an EAP technology, SAC is highly scalable and generally does not require user intervention. In addition, the SAC technology imposes a relatively lightweight computation on the endpoint - making it highly advantageous for sensors, IoT endpoints, and other devices with limited processing power. The EAP-based SAC technology can reuse existing enterprise and global infrastructure used in EAP-based authentication, and can therefore be easily deployed. Using public-private key pairs supplied during manufacturing and / or maintenance, secure keys for encrypted communications can be generated over insecure channels. Nevertheless, embodiments of the SAC technology can be used to securely authenticate endpoints.

[0021] the term

[0022] The following list provides general meanings of certain terms used in this disclosure.

[0023] EAP (Extensible Authentication Protocol) - an authentication framework that supports multiple authentication methods defined in RFC 3748.

[0024] SAC (Short Asymmetric Challenge) - An authentication method described herein for challenge-response authentication between two independent entities, each of which has an elliptic curve public-private key pair. As an asymmetric challenge-response mechanism, it can ensure that both parties establish a shared secret over an insecure channel, where the shared secret can be further used to derive a symmetric key for encrypted communication over an insecure channel. EAP-SAC can be used as an EAP method to authenticate entities as well as encrypt communications.

[0025] EAP Authenticator - the end of the link that initiates EAP authentication. The term authenticator is derived and has the same meaning as described by IEEE-802.1X and RFC 3748. In this document, unless otherwise specified, authenticator or EAP authenticator refers to the same entity.

[0026] EAP peer - the end of the link that responds to the authenticator and is authenticated. This term is interchangeable with the term supplicant widely used by IEEE-802.1X. In this document, peer or EAP peer refers to the same entity unless otherwise specified.

[0027] EAP Server - A backend authentication server that provides authentication assistance to the Authenticator. An EAP Server can act as a standalone entity or be integrated with an EAP Authenticator, but is adapted to the same functionality of storing, verifying, and authenticating EAP peers.

[0028] ECDH - Elliptic Curve Diffie-Hellman is an anonymous key agreement protocol that allows two parties, each with an elliptic curve public-private key, to establish a shared secret over an insecure communication channel.

[0029] IoT – The Internet of Things is the network of computing devices that exist anywhere and everywhere. It is generally defined as a network of endpoints capable of communicating over wired or wireless networks. Endpoints are physical devices, vehicles, home appliances, home security and automation appliances, actuators, sensors, imaging devices, etc. Typically, these endpoints relay physical information to computer-based or digital systems.

[0030] IEEE 802 - IEEE 802 is a family of IEEE standards dealing with Local Area Networks (LANs) and Metropolitan Area Networks (MANs).

[0031] IEEE 802.1 - IEEE 802.1 is the IEEE working group responsible for 802 LAN / MAN architecture, internetworking of LANs, MANs, and WANs, 802 link security, network management, and protocol layers above MAC and LLC.

[0032] IEEE 802.11 - IEEE 802.11 is a collection of medium access control (MAC) and physical layer (PHY) specifications for implementing wireless local area networks (WLANs).

[0033] IEEE 802.1X - IEEE 802.1X is an IEEE standard for port-based network access control. It is part of the IEEE 802.1 grouping of network protocols. The latest revision of this specification is defined by IEEE 802.1X-2010.

[0034] PPP – Point-to-Point Protocol is a data link communications protocol used to establish a direct connection between two nodes.

[0035] Extensible Authentication Protocol (EAP) is an authentication framework commonly used to authenticate endpoints on wireless, wired, and ad hoc networks. EAP as a framework relies on EAP methods to negotiate credentials for authentication and key derivation. EAP supports multiple authentication methods and provides many suitable authentication methods. EAP usually runs directly through the data link layer, and is therefore able to support several encapsulation schemes to encapsulate EAP messages. Two widely used methods for implementing EAP include IEEE 802 and Point-to-Point Protocol (PPP). For wired (LAN) and wireless (WLAN) networks, IEEE 802.1X is a common standard for port-based network access control. IEEE 802.1X provides an authentication mechanism to endpoints joining a wired or wireless network, and defines the encapsulation of EAP through IEEE802 frames.

[0036] EAP generally provides a messaging framework to authenticate endpoints. It provides flexibility in choosing the authentication mechanism to be negotiated, and there are several EAP methods defined by IETF RFCs, several vendor extensible methods, and experimental methods. EAP methods generally implement a variety of protections ranging from: passwords, challenge-handshake authentication protocol, lightweight extensible authentication protocol using user credentials, TLS based on X.509 certificates, MD5-based challenges, pre-shared credentials or keys, IKEv2, etc.

[0037] Over a period of time, EAP methods have evolved from simple and insecure mechanisms to secure but computationally intensive mechanisms that require pre-configured certificates and enterprise-level scalable infrastructure. These methods support authentication techniques based on passwords, one-time passwords, pre-shared keys, high entropy shared keys, symmetric keys, public key certificates, and many other mechanisms suitable for specific purposes. Typically, EAP is a message passing framework and is agnostic to the encapsulation used to transmit these messages. Typically, EAP is encapsulated into 802.1X frames, 802.11, PEAP, RADIUS, or any other wired protocol capable of transmitting these messages. EAP and its applications have evolved around endpoints that are typically personal computers, workstations, servers, mobile devices, and similar computing devices. These endpoints typically have significant computing power and pre-provisioned support for running existing EAP methods.

[0038] With the advent of IoT (Internet of Things), computing devices that need to be authenticated with the highest security are ubiquitous and are employed in modern vehicles, including autonomous vehicles, mobile devices, home automation systems, industrial automation systems, etc. The requirements for authenticating endpoints in such systems are very different in terms of the size of the devices, the limitations on their computing power, and the time required for authentication. Typically, various EAP methods including EAP-MD5, EAP-SIM, EAP-TLS, EAP-PSK, etc. are also generally not suitable for use in vehicles (including autonomous vehicles), IoT applications, and in other similar systems due to the limited computing power of various endpoint devices such as sensors, IoT devices, etc.

[0039] refer to Figure 2 According to one embodiment, an exemplary system 200 for implementing a security mechanism for Ethernet using asymmetric key generation includes an endpoint 202 (e.g., a host unit (HU)). The endpoint 202 includes a gateway 204, which is capable of communicating with a database 208 via a computer 206, which can be a local database or a network / cloud-based database. The database 208 can be a public database or a private database and can be implemented as a blockchain. The endpoint 202 is capable of storing and / or accessing public keys of the endpoint 202 and / or endpoint 212 (e.g., a sensor unit (SU)) also included in the system 200.

[0040] Endpoint 212 includes an 802.1AE module 106b for encrypting and decrypting messages using an encryption key, a data source / receiver 116b (e.g., a video source, a sensor, a display, another processor, etc.), and a physical layer transceiver (PHY) 118b. Endpoint 212 does not include an 802.1x software engine running on a processor. Instead, endpoint 212 includes a state machine 214 for key management (as discussed below). State machine 212 may have limited computing capabilities. Two endpoints 202, 212 can communicate via link 120 and can exchange data and / or control information.

[0041] System 200 can be used for initial programming and / or subsequent inspection / testing of endpoints 202, 212, which can communicate with each other via an Ethernet link (e.g., link 120). Such an endpoint may be provided in a vehicle or may be part of an IoT system. Computer 206 is provided at an external facility, such as at a vehicle manufacturing or repair facility. At the time of initial programming (e.g., at the time of manufacturing or maintenance), computer 206 may assign a unique identifier such as a universally unique identifier (UUID) to endpoint 212 (e.g., sensor unit (SU)). Computer 206 may also generate a public key / private key pair for endpoint 212: PubS, PrvS. In some cases, endpoint 212 may generate and provide a key pair. The UUID and private key (PrvS) are stored on endpoint 212 in a non-volatile storage device (not shown). The UUID and public key (PubS) are uploaded to database 208 so that the information can be accessed by gateway 204 at a later time.

[0042] refer to Figure 3 According to another embodiment, another exemplary system 300 uses asymmetric key generation to implement a security mechanism for Ethernet. In the system 300, the gateway 204 is configured to communicate directly with the database 208 without the need for the computer 206. Therefore, the endpoint 202 is generally able to authenticate the endpoint 212 at any time and anywhere (for example, when the two endpoints 202, 212 are included in the vehicle and the vehicle is moving). The authentication of the endpoint 212 (e.g., SU) can be initiated by only the endpoint 212, only the endpoint 202 (e.g., host processor (HP)), or by either endpoint.

[0043] In the following discussion, reference is made to a host unit (HU) and to a sensor unit (SU) for convenience only. Figure 2 and 3The endpoints 202 in the example, such as processors, servers, data sources, data receivers and / or sensors, IoT devices, etc.) can perform the operations described with respect to the host unit (HU), and any other endpoints (e.g., Figure 2 and 3 The endpoint 212 in the sensor unit, such as a camera, display, IoT device, GPS and / or data source, data receiver, etc., can perform the operations described with respect to the sensor unit. In addition, in the following discussion, examples of EAP-based signals / frames are provided for convenience only. The SAC-based messaging described herein is not limited to EAP and can be used with other Ethernet or even wireless communication / authentication protocols.

[0044] refer to Figure 4 In an exemplary host initialization process 400 according to one embodiment, upon power-up or restart of the device initialization process, the sensor unit begins transmitting a start authentication message (e.g., 801.1X EAP over LAN (EAPOL)-Start frame) on the Ethernet link (step 402). The sensor unit continues to send the start authentication message (e.g., EAPOL-Start frame) until it receives an identification request message (e.g., EAP-Request) from the host processor. The host processor, upon receiving the start authentication message (e.g., EAPOL-Start frame) from the SU, sends an identification request message (e.g., EAP-Request / Identity frame) to the SU (step 404).

[0045] Upon receiving the Identification Request message (e.g., EAP Request / Identity frame), the SU responds with an Identifier message (e.g., EAP Response / Identity frame) containing the SU's identifier (e.g., UUID) read from its non-volatile memory. (Step not shown). This identifies the SU's unique identity to the HP. If the HP knows the UUID (step 406), the HP retrieves the sensor unit's public key (PubS) from local storage (step 408). Otherwise, the HP retrieves the public key (PubS) from an Internet-based public or private database or blockchain (e.g., Figure 2 and 3 The public key (PubS) of the sensor unit is retrieved from the database 208 in Figure 4 HP may store the retrieved public key (PubS) in a local storage device (step 412).

[0046] The HP verifies the identity of the SU and sends a Short Asymmetric Challenge, SAC-Request Start (e.g., EAP-Request / EAP-Type=EAP-SAC (Start) frame) (step 414). The Start message / frame indicates that the SU should participate in the Short Asymmetric Challenge-Request protocol. Upon receiving this message, the SU responds with a SAC Client Ready message (e.g., EAP-Response / EAP-Type=EAP-SAC (Client_Hello) frame) indicating that the SU will participate in the Short Asymmetric Challenge. (step not shown).

[0047] Safety circuits on the HP side (e.g. Figure 2 and 3 The encryption / decryption module 106a in the HP side uses a random number generator to generate a random number (R) and a private key pair (PubH, PrvH) (step 416). The challenge generator (not shown) on the HP side uses a random number generator to generate a random challenge (C) (step 416). The combination of (R, PubH, C) is sent to the SU via an authenticator SAC challenge message (e.g., an EAP-Request / EAP-Type=EAP-SAC (server_hello) frame), step (418). The SU receives the authenticator SAC challenge message (e.g., an EAP-Request frame), and the SU's security circuit (e.g., Figure 2 and 3 The encryption / decryption module 106b) in generates a response (C') using a key agreement protocol (e.g., ECDH algorithm) and a symmetric cryptographic algorithm (e.g., AES) as follows:

[0048] E(R, PubH, PrivS)->K1, where E is a function representing a key agreement protocol (e.g., ECDH algorithm), and K1 is the encryption / decryption key (also called session key) output by the function.

[0049] AES(C, K1)->C', where AES can be any symmetric cryptographic algorithm, and C' is an encrypted version of the challenge C, where the encryption is performed using the key K1.

[0050] This calculated response (C') is sent to the HP via a SAC Client Response message (eg, EAP-Response / EAP-Type=EAP-SAC(C')) (step not shown).

[0051] Upon receipt of the client response message, the HP's security circuitry validates the value of the response by comparing the value C' (received from the SU) with the value Cc' calculated by the HP's security circuitry (step 420), as follows:

[0052] E(R, PubS, PrivH)->K1', where E is the same function used by SU, which represents the key agreement protocol (e.g., ECDH algorithm), and K1' is the encryption / decryption key (also called session key) output by this function when executed by HP.

[0053] • AES(C, K1')->Cc', where AES is the same symmetric cryptographic algorithm used by SU, and C' is an encrypted version of the challenge C, where the encryption is performed using the key K1'.

[0054] On the HP side, the security circuit compares C' with Cc' (step 420) and enables the session key KI' to be used for encryption of data traffic if: C' is equal to Cc' (which means that keys K1 and K1' are also identical, although they are independently generated). In this case, the HP determines that the SU is authentic.

[0055] If authentication is successful, the HP sends a SAC-End message (e.g., an EAP-Request / EAP-Type=EAP-SAC (change_cipher, challenge_finished) frame) to the SU, which indicates to the SU that it is authenticated (step 422). The SU responds with a SAC-Start message (e.g., an EAP-Response / EAP-Type=EAP-SAC (change_cipher) notification) indicating that the SU is ready to use the updated session key K1 in further communications with the HP (step not shown).

[0056] The HP sends an authentication success message (e.g., an EAP-Success frame) to the SU (step 424), and uses the key K1' calculated in step 420 for encrypting data / control information to be transmitted to the SU (step 426). Upon receiving the authentication success message (e.g., an EAP-Success frame), the SU uses the key K1 as the generated session key that the SU has previously calculated for encrypting data / control information to be transmitted to the HP (step not shown). If the authentication fails, that is, when C' is not equal to Cc', the HP sends a failure message (e.g., an EAP-Failure message) to the SU (step 428).

[0057] The above scheme allows the same session keys (K1 and K1') to be generated independently on the HP and SU. The sensor side circuit encrypts each frame to be transmitted to the HP using the session key K1. The HP side circuit decrypts the frame using the session key K1', where the keys K1 and K1' are the same when the authentication is successful. Encrypting frames of all or selected data / control services can prevent or minimize snooping and modification of services between the sensor unit and the host processor. Authenticating the sensor unit can also prevent man-in-the-middle attacks. The current EAP-SAC authentication technology can eliminate the need for complex authentication protocols, and therefore, the various embodiments described herein do not require an operating system or microprocessor on the sensor unit to perform key management functions, and therefore can reduce system cost and / or complexity.

[0058] In various embodiments, a SAC (Short Asymmetric Challenge) based security mechanism allows lightweight devices (sensors, IoT devices, etc.) to implement a relatively lightweight authentication protocol while providing security comparable to that provided by complex certificate-based systems. This is achieved at least in part using an asymmetric key exchange protocol for authentication and for communication over insecure channels such as Ethernet, I2C, etc. In various embodiments, a host processor can participate in authenticating multiple sensor units simultaneously.

[0059] According to one embodiment, only when a new SU identifier (e.g., UUID) is received by the HP, the public database (e.g., Figure 3 Implement the authentication process 400 ( Figure 4 ) system 300( Figure 3 ) does not require continuous network connectivity, and therefore, the system 300 can operate in a moving vehicle (or a vehicle with limited network connectivity). In addition, a change in the SU identifier causes the HP to obtain a new public key for the SU, and therefore can be a traceable security event.

[0060] User Intervention

[0061] Endpoint devices that can be included in current SAC-based systems can range from sensors, camera devices, actuators, or relatively complex computing devices running an operating system. For any of these devices, user intervention is generally not required to initiate the authentication process. The device only needs to be powered on and is required to implement a simple state machine. For the end user, this is a simple plug-and-play event, but in the background, the device's security mechanism (e.g., EAP mechanism) is automatically authenticated and keys are also automatically generated for secure communications over an insecure channel.

[0062] Computing power

[0063] The device implementing the embodiment of the SAC mechanism runs a lightweight authentication protocol (e.g., EAP), which can be embedded in a small processor or provided as an integrated circuit. The authentication protocol (e.g., EAP) can retrieve cryptographic keys, execute lightweight cryptographic algorithms, generate random numbers, and respond to authentication protocol messages (e.g., EAP messages) through an insecure communication channel.

[0064] Storage Devices

[0065] A device implementing an embodiment of the SAC mechanism requires minimal storage (less than 1 kB for many cases) to store a set of unique identifiers (eg, serial numbers, UUIDs, product codes, etc.) and cryptographic keys.

[0066] Compute Challenge and Response

[0067] SAC as an authentication mechanism uses a key agreement protocol (e.g., ECDH) and a symmetric key cipher to challenge the peer to be authenticated (also called the client) and validates its response using an authentication protocol (e.g., EAP) over an insecure channel. Each entity participating in the SAC process (authenticator and peer to be authenticated) has access to its own unique public-private key pair. These public-private key pairs can be one-time programmable, for example during the manufacturing process. In addition, the authenticator has access to a database of public keys of the peer to be authenticated, where based on the unique identity of the peer to be authenticated, its public key can be retrieved.

[0068] Symmetric Cipher

[0069] SYM_CIPHER refers to a symmetric cipher on the endpoints and provides sufficient security to not compromise the session key K1. Any strong symmetric cipher can be used in different embodiments, such as AES, DES simple hash with various known parameters, etc.

[0070] Questions

[0071] The authenticator can challenge the peer to be authenticated with any random number. The challenge (C) does not need to be derived from a previously known pattern, although challenges derived in this way can be used. For the security of the system, neither the challenge C nor the number of ECDH seeds R are reused and are unpredictable to an attacker.

[0072] The response computed by the peer to be authenticated

[0073] The peer to be authenticated has access to its own public-private key pair (PrivH and PubH). In addition, when it receives the authenticator SAC challenge message (e.g., EAP-Request / Challenge message), the peer to be authenticated receives the following data from the authenticator:

[0074] PubH - the public key of the authenticator

[0075] R - random number to be used by the key agreement protocol (e.g., ECDH cryptographic algorithm)

[0076] C - Challenge used to compute the response

[0077] These received parameters are used to calculate the symmetric session key K1, such as, for example:

[0078] K1 = ECDH (PubH, PrivS, R)

[0079] The symmetric session key K1 is then used to encrypt the challenge C using any SYM_CIPHER that forms a response to the challenge.

[0080] C' = SYM_CIPHER (K1, C)

[0081] The response computed by the authenticator

[0082] The authenticator obtains the identity of the peer to be authenticated by sending it an identification request message (e.g., an EAP Request / Identity message). This allows the authenticator to query a database of public keys to extract the public key (PubS) associated with the unique identity of the peer to be authenticated. The authenticator has access to its own public-private keys PubH and PrivH. This allows the authenticator to calculate the same symmetric session key Kc1 using PubS, PrivH, and R sent to the peer to be authenticated. For example, using ECDH as the key agreement protocol, Kcl is calculated as:

[0083] ·Kc1=ECDH(PubS,PrivH,R)

[0084] The authenticator then calculates its own response (Cc') to the challenge (C) and compares the response (Cc') with the response (C') received from the peer to be authenticated. The authenticator's response (Cc') is calculated as:

[0085] Cc' = SYM_CIPHER (C, Kc1)

[0086] When Cc' is equal to C', the comparison succeeds if and only if key Kc1 is the same as key K1. Thus, this SAC-based mechanism allows the authenticator and the peer to be authenticated to establish a shared secret (K1) over an insecure channel. The shared secret is used to derive a response (C') to a challenge (C) sent by the authenticator, and is also used to derive a response (Cc') by the authenticator to the same challenge (C). This ensures that the shared secret (K1) or (Kc1) is never communicated over an insecure channel. Instead, the authenticator and the peer to be authenticated are communicated over an insecure channel (e.g., Figure 2 and 3 The link 120 in ) only communicates the encrypted response (C').

[0087] Message Exchange

[0088] The exchange of messages that occur in a typical SAC-based authentication technique is described below in the context of an EAP-SAC system. However, it should be understood that embodiments of SAC-based authentication techniques are not limited to EAP and can be used as part of any other authentication protocol.

[0089] refer to Figure 5 In an exemplary EAP-SAC authentication process according to one embodiment, the sequence of events that occur in a typical authentication process includes:

[0090] Initiation and identification - steps 505 and 510

[0091] Method exchange - steps 515 and 520

[0092] Challenge-Response - Steps 525 and 530

[0093] Challenge accepted or failed - steps 535 and 540

[0094] Change Password Confirmation - Steps 545 and 550

[0095] Initiation of EAP-SAC dialogue

[0096] The EAP authenticator sends an EAP-Request / Identity packet to the EAP peer (step 505), and the EAP peer responds to the EAP authenticator with an EAP-Response / Identity packet, thereby conveying identification information of the peer to be authenticated (step 510). After the identity exchange, the authenticator knows the unique identity of the peer to be authenticated.

[0097] The EAP dialogue occurs between an EAP authenticator and a peer. However, the authenticator may choose to act as a pass-through device, where the authenticator encapsulates EAP packets received from the peer and sends the encapsulated packets to a backend authentication server. As described herein, an EAP server generally refers to a combination of an authenticator or a pass-through identifier and a backend authentication server. The EAP-SAC dialogue does not define any additional EAP packets, nor does it add any new EAP message formats.

[0098] After having received the identity of the peer, the EAP server initiates a server_hello with EAP-Request / EAP-Type=EAP-SAC (step 515), thereby notifying the peer of the start of an asymmetric challenge. The peer supporting the EAP-SAC procedure responds with an acknowledgment that the start of an asymmetric challenge has been received (step 520), thereby indicating that it expects a challenge from the EAP server.

[0099] Upon confirming the identity of the peer to be authenticated, and upon receiving notification that the peer can use EAP-SAC as an authentication mechanism, the EAP server sends an EAP-SAC / Challenge packet containing (i) a server hello indication (ii) the authenticator's public key PubH (iii) a random number R and (iv) a challenge C (step 525). The peer to be authenticated receives the EAP-SAC / Challenge packet and calculates its symmetric session key K1 (=ECDH(PubH, PrivS, R)) and the corresponding response C' (=SYM_CIPHER(C, K1)) based on the challenge C. The peer then sends the calculated response to the EAP server using an EAP-SAC / Challenge-Response message (step 530).

[0100] The EAP server receives the EAP-SAC / Challenge-Response packet and computes the response locally using the EAP server's private key PrivH, the peer's public key PubS (looked up in the public key database) and the same random number R sent to the peer to be authenticated. The session key computed by the EAP server is Kc1 (=ECDH(PubS, PrivH, R)) and the response Cc'=SYM_CIPHER(C, Kc1) is computed using this session key (step 535).

[0101] The EAP server compares C' and Cc' locally. If they match, the authentication is successful and an authentication success message is sent from the EAP server to the peer (step 535). The authentication success message is an EAP-Request / EAP-Type=EAP-SAC with a Change Password and Challenge Completed message sent from the EAP server to the peer to be authenticated. The peer to be authenticated confirms the receipt of the Change Password message by responding with an EAP-Response / EAP-Type=EAP-SAC with a Change Password Confirmation (step 540).

[0102] At this point, neither the EAP server nor the peer is using a symmetric key to encrypt data. Upon receiving the EAP-Response / EAP-Type=EAP-SAC with the Change Cipher Complete message, the EAP server completes the EAP handshake and sends out an EAP-Success message (step 545). Network access between the EAP server and the now authenticated peer is then enabled. The EAP server begins using Kcl as its symmetric session key for encrypted communications. Upon receiving the EAP-Success message, the (now authenticated) peer changes its cipher suite to begin using K1 as its symmetric session key for encrypted communications (step 550).

[0103] Authentication failed

[0104] Figure 6 An exemplary sequence of events when authentication fails according to one embodiment is illustrated, wherein steps 605-625 are similar to Figure 5 505-525 of the authentication process. However, during step 630 of the authentication process, the peer to be authenticated computes the response (C2') instead of (C'). In step 635, the EAP server / authenticator receives a response (C2') that does not match the cached or computed challenge-response Cc'. Therefore, the EAP server / authenticator determines that the authentication of the peer is unsuccessful. The EAP server then sends an EAP-Request packet with an EAP-Type=EAP-SAC / Failure message (step 635).

[0105] At this point, the peer has the option to send an EAP-Response packet with an EAP-Type=EAP-SAC (client_hello) packet with the option to restart the authentication process. At this point, the server has the option to allow the peer to reauthenticate. According to one embodiment, the security implementation limits the number of times the peer is allowed to attempt authentication during a certain time window (e.g., a window of seconds, minutes, hours, etc.), which can provide protection against denial of service attacks.

[0106] For the purpose of explanation, the foregoing description uses specific terms to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that specific details are not required in order to practice the present invention. Therefore, the foregoing descriptions of specific embodiments of the present invention are presented for the purpose of illustration and description. They are not intended to be exhaustive or to limit the present invention to the precise form disclosed; obviously, many modifications and variations are possible in view of the above teachings. The embodiments are selected and described in order to best explain the principles of the present invention and its practical application, which thereby enables those skilled in the art to best utilize the present invention and various embodiments with various modifications as suitable for the intended specific use.

Claims

1. A method for protecting a vehicle-mounted Ethernet link, comprising: receiving a public key, a random number, and a challenge from an authenticator via an insecure channel; accessing, from local storage at a peer, a private key of the peer that was provisioned to the peer, wherein the peer comprises a sensor, a camera, or an IoT device, each of which lacks a processor capable of loading and executing software; computing a session key for the peer using a state machine at the peer based on the random number, the public key of the authenticator, and the private key of the peer; as well as A peer response to the challenge is computed on the state machine using the session key and a symmetric cryptographic function for the peer.

2. The method of claim 1, wherein the steps of receiving and transmitting are based on an Extensible Authentication Protocol.

3. The method of claim 1, wherein calculating the session key for the peer comprises executing an Elliptic Curve Diffie-Hellman function by the state machine.

4. The method according to claim 1, further comprising: receiving, from an external processor, an identifier for said peer and said private key of said peer; as well as The identifier and the private key of the peer are stored in the local storage.

5. The method according to claim 1, further comprising: transmitting an authentication initiation message to the authenticator; receiving a request for identification from the authenticator; as well as An identifier of the peer is transmitted to the authenticator.

6. The method according to claim 1, further comprising: receiving an authorization success message from the authenticator; encrypting an information packet using said session key of said peer; as well as The encrypted packet is transmitted to the authenticator via the insecure channel.

7. The method according to claim 1, further comprising: receiving an authorization failure message from the authenticator; as well as In response, an authentication initiation message is transmitted to the authenticator.

8. A method for protecting a vehicle-mounted Ethernet link, comprising: transmitting a public key of the authenticator, a random number, and a challenge to a peer via an insecure channel, wherein the peer comprises a sensor, a camera, or an IoT device, each of which lacks a processor capable of loading and executing software; receiving, from the peer via the insecure channel, a peer response to the challenge generated on a state machine; calculating a session key of the authenticator based on the random number, the public key of the peer, and the private key of the authenticator; computing an authenticator response to the challenge via a symmetric cryptographic function using the session key for the authenticator; as well as If the authenticator response and the peer response are identical, the peer is determined to be authentic, and, in different circumstances, the peer is determined to have failed authentication.

9. The method of claim 8, wherein the steps of transmitting and receiving are based on Extensible Authentication Protocol.

10. The method of claim 8, wherein calculating the session key for the authenticator comprises performing an Elliptic Curve Diffie-Hellman function.

11. The method according to claim 8, further comprising: receiving an authentication initiation message from the peer; transmitting a request for an identification to the peer; as well as An identifier of the peer is received from the peer.

12. The method according to claim 11, further comprising: The identifier of the peer is located in local storage and the public key of the peer is accessed therefrom.

13. The method according to claim 8, further comprising: transmitting an authorization success message to the peer; encrypting an information packet using the session key of the authenticator; as well as The encrypted packet is transmitted to the peer via the insecure channel.

14. The method according to claim 8, further comprising: transmitting an authorization failure message to the peer; receiving an authentication initiation message from the peer; transmitting a request for an identification to the peer; as well as An identifier of the peer is received from the peer.

15. The method according to claim 8, further comprising: transmitting an authorization failure message to the peer; as well as The processing of subsequently received messages from the peer is suspended for a specified period of time.

16. A system for protecting a vehicle-mounted Ethernet link, comprising: an authenticator that sends a public key, a random number, and a challenge of the authenticator via an insecure channel; local storage at a peer, the local storage comprising a private key of the peer, wherein the peer comprises a sensor, a camera, or an IoT device, each of which lacks a processor capable of loading and executing software; as well as A state machine at a peer that computes a session key for the peer based on the random number, the public key of the authenticator, and the private key of the peer, wherein the state machine computes a peer response to the challenge using the session key for the peer and a symmetric cryptographic function.

17. The system of claim 16, wherein the state machine implements an Elliptic Curve Diffie-Hellman function.

18. The system of claim 16, further comprising: An external processor generates an identifier for the peer and the private key of the peer, wherein the local storage stores the identifier and the private key of the peer.

19. The system of claim 16, further comprising: an authentication initiation message transmitted to the authenticator; a request for identification received from the authenticator; as well as An identifier of the peer is transmitted to the authenticator.

20. The system of claim 16, further comprising: an authorization success message received from the authenticator; information packets encrypted using said session key of said peer; as well as Wherein the encrypted packet is transmitted to the authenticator via the insecure channel.

21. The system of claim 16, further comprising: an authorization failure message received from the authenticator; as well as An authentication initiation message is transmitted to the authenticator.

22. A system for protecting a vehicle-mounted Ethernet link, comprising: Authenticator; a peer communicating with the authenticator via an insecure channel, wherein the peer comprises a sensor, a camera, or an IoT device, each of which lacks a processor capable of loading and executing software, the public key of the authenticator, Random numbers and challenges; a peer response to the challenge generated on a state machine received from the peer via the insecure channel; a session key for the authenticator based on the random number, the peer's public key, and the authenticator's private key; as well as an authenticator response to the challenge using the session key for the authenticator; Wherein if the authenticator response and the peer response are identical, the peer is determined to be authentic.

23. The system of claim 22, wherein the session key for the authenticator is determined by performing an Elliptic Curve Diffie-Hellman function.

24. The system of claim 22, further comprising: an authentication initiation message received from said peer; a request for an identity transmitted to said peer; as well as An identifier of the peer received from the peer.

25. The system of claim 24, further comprising: wherein the identifier of the peer is located in a local storage device, and the public key of the peer is retrieved from the local storage device.

26. The system of claim 24, further comprising: Wherein if the identifier of the peer is not stored in the local storage device, accessing the public key of the peer from a networking database and storing the identifier and the public key of the peer in the local storage device.

27. The system of claim 22, further comprising: an authorization success message transmitted to said peer; as well as an information packet encrypted using said session key of said authenticator; Wherein the encrypted packets are transmitted to the peer via the insecure channel.

28. The system of claim 22, further comprising: an authorization failure message transmitted to said peer; an authentication initiation message received from said peer; a request for an identity transmitted to said peer; as well as An identifier of the peer received from the peer.

29. The system of claim 22, further comprising: an authorization failure message transmitted to said peer; Therein processing of subsequently received messages from the peer is suspended for a specified period of time.

Images