(19)
(11)EP 3 050 251 B1

(12)EUROPEAN PATENT SPECIFICATION

(45)Mention of the grant of the patent:
04.11.2020 Bulletin 2020/45

(21)Application number: 14849609.4

(22)Date of filing:  24.09.2014
(51)International Patent Classification (IPC): 
H04L 9/08(2006.01)
H04L 9/32(2006.01)
H04L 29/08(2006.01)
H04W 12/10(2009.01)
H04L 9/12(2006.01)
H04L 29/06(2006.01)
H04W 12/02(2009.01)
(86)International application number:
PCT/US2014/057104
(87)International publication number:
WO 2015/048058 (02.04.2015 Gazette  2015/13)

(54)

REAL-TIME FRAME AUTHENTICATION USING ID ANONYMIZATION IN AUTOMOTIVE NETWORKS

ECHTZEIT-RAHMENAUTHENTIFIZIERUNG UNTER VERWENDUNG VON ID-ANONYMISIERUNG IN AUTOMOBILNETZWERKEN

AUTHENTIFICATION DE TRAME EN TEMPS RÉEL À L'AIDE D'UNE MISE EN ANONYMAT D'IDENTIFICATEUR (ID) DANS DES RÉSEAUX AUTOMOBILES


(84)Designated Contracting States:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

(30)Priority: 24.09.2013 US 201361881544 P
23.09.2014 US 201414494141

(43)Date of publication of application:
03.08.2016 Bulletin 2016/31

(73)Proprietor: The Regents of The University of Michigan
Ann Arbor, MI 48109-2590 (US)

(72)Inventors:
  • HAN, Kyu Suk
    Ann Arbor, Michigan 48105 (US)
  • POTLURI, Swapna Divya
    Ann Arbor, Michigan 48109-2590 (US)
  • SHIN, Kang G.
    Ann Arbor, Michigan 48105 (US)

(74)Representative: Witte, Weller & Partner Patentanwälte mbB 
Postfach 10 54 62
70047 Stuttgart
70047 Stuttgart (DE)


(56)References cited: : 
WO-A2-2013/126759
US-A1- 2006 143 448
US-A1- 2010 313 009
KR-A- 20130 021 157
US-A1- 2010 306 457
  
  • S. KENT ET AL.: 'Security Architecture for Internet Protocol' INTERNET ENGINE ERING TASK FORCE (IETF vol. 2401, November 1998, XP055329382
  
Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).


Description

FIELD



[0001] The present disclosure relates to a real-time frame authentication using ID anonymization in automotive networks.

BACKGROUND



[0002] WO 2013/126759 A2 discloses methods, systems and devices which enable synchronizing obscured identification information between a wireless identity transmitter and a central server to support one way communication of the obscured identification information to the central server. US 2010/0306457 A1 discloses a microcontroller with a CAN module.

[0003] Modern vehicles are equipped with a large number of electronic control units (ECUs) which vary in processing capability and functional complexity. They monitor and control critical vehicle components such as engine and transmission (powertrain), and non-critical components such as airbags and telenetics. They are interconnected via several in-vehicle networks, such as the Controller Area Network (CAN) which has become the de facto standard due to its widespread deployment. Other standards include the Local Interconnect Network (LIN) which was designed for simpler vehicle components, such as roof, power seats or windows, and FlexRay which provides more capabilities (hence more expensive) than CAN.

[0004] CAN was originally designed without security in mind, and its design choices were greatly influenced by such strict constraints as low cost and low network latency in isolated/closed environments. As a result, it cannot ensure data authentication or privacy, thus becoming susceptible to various attacks.

[0005] However, vehicle manufacturers are now departing from this closed operation of in-vehicle networks by allowing external entities to send commands from a remote site to in-vehicle components for diagnosis and anti-theft purposes, which accompany new security risks. Several studies have already reported that connecting/exposing a vehicle's internal subsystems to external entities create serious security and safety risks. The security architecture of CAN is too weak to deal with this type of exposure.

[0006] There have been various efforts to address sophisticated cyber-vehicle security risks and attacks. For example, Automotive Open System Architecture (AUTOSAR) and the EVITA project focus on development of a standard security architecture. There have also been several research projects aimed at enhancing the security of CAN. However, none of these can cope with Denial-of-Service (DoS) attacks on ECUs. Since ECUs are very resource-constrained for cost and size reasons, requiring them to perform more than a simple computation can degrade/compromise their intended functionality and/or required performance.

[0007] To address these and other weaknesses of existing CAN protocols, this disclosure proposes an efficient security protocol which does not require modifications of current, cost-conscious in-vehicle networks.

[0008] This section provides background information related to the present disclosure which is not necessarily prior art.

SUMMARY



[0009] This section provides a general summary of the disclosure, and is not a comprehensive disclosure of its full scope or all of its features. Aspects of the invention are defined in the accompanying claims.

[0010] A method is presented for authenticating data frames in a vehicle network. At the receiving electronic control unit, the method includes: receiving a current frame identifier in a data frame sent via a serial data link by the sending electronic control unit; generating a next frame identifier in response to receiving the current frame identifier; and storing the next frame identifier in a data store for subsequent processing, where the next frame identifier is derived in part from the current frame identifier and a cryptographic key using an encoding function. Upon receiving another data frame subsequent to receiving the current frame identifier, the receiving electronic control unit extracts a frame identifier from the another data frame without decoding any portion of the another data frame; compares the extracted frame identifier to the next frame identifier residing in the data store; and processes the payload of the another data frame when the extracted frame identifier matches the next frame identifier. Conversely, the another data frame is discarded when the extracted frame identifier does not match the next frame identifier.

[0011] When the extracted frame identifier from the another data frame matches the next frame identifier, the receiving electronic control unit also generates a new frame identifier and replaces the next frame identifier residing in the data store with the new frame identifier, where the new frame identifier is derived in part from the extracted frame identifier and a cryptographic key using an encoding function.

[0012] Prior to processing the payload of the another data frame, the receiving electronic control unit can authenticate the message content. For example, the receiving electronic control unit can extract a message authentication code from the another data frame and authenticate the payload of the another data frame using the message authentication code, where the message authentication code differs from the extracted frame identifier and is derived in part from the payload in the another date frame.

[0013] In one aspect of this disclosure, a communication session is first established between the sending electronic control unit and the receiving electronic control unit. On the sending side, the communication session can be established by selecting a nonce; selecting a hash function for key generation; selecting a keyed hash function for message authentication; generating a hash output by applying the selected keyed hash function to an identifier for the sending electronic control unit, the nonce, and the cryptographic key; and sending an initiation data frame via the serial data link to the receiving electronic control unit, where the initiation data frame includes an identifier for the sending electronic control unit, the nonce, the hash value, an indicator for the hash function, an indicator for the keyed hash function and the hash output.

[0014] On the receive side, receiving electronic control unit receives the initiation data frame; determines the selected keyed hash function from the initiation data frame; generates a hash output by applying the selected keyed hash function to the identifier for the sending electronic control unit, the nonce, and the cryptographic key retrieved from the initiation data frame; and generates a session key by applying the selected hash function to the nonce and the cryptographic key when the generated hash output matches the hash output retrieved from the initiation data frame.

[0015] In another aspect of the disclosure, a system is presented for authenticating data frames sent from a sending electronic control unit over a vehicle network to a receiving electronic control unit.

[0016] On the send side, the electronic control unit includes a send module configured to retrieve the next frame identifier from a local data store, format a data frame with the next frame identifier and transmit the data frame over the vehicle network. The electronic control unit further includes an ID generator configured to retrieve the next frame identifier from the local data store, generate a new frame identifier based in part of the next frame identifier and replace the next frame identifier residing in the send data store with the new frame identifier. In some embodiments, the new frame identifier can be derived from the next frame identifier and a cryptographic key using an encoding function, where the cryptographic key is shared with the receiving electronic control unit.

[0017] On the receive side, the electronic control unit includes a filter configured to receive a data frame sent via a vehicle network by the sending electronic control unit. The filter extracts a frame identifier from the received data frame without decoding any portion of the data frame and compares the extracted frame identifier with the next frame identifier. When the extracted frame identifier matches the next frame identifier, a message authenticator receives the data frame from the filter and processes the payload of the data frame. When the extracted frame identifier does not match the next frame identifier, the filter discards the data frame. The electronic control unit further includes an ID generator interfaced with the message authenticator. The ID generator generate a new frame identifier and replace the next frame identifier in the receive data store with the new frame identifier when the extracted frame identifier matches the next frame identifier residing in the receive data store. In some embodiments, the new frame identifier can be derived from the next frame identifier and a cryptographic key using an encoding function, where the cryptographic key is shared with the receiving electronic control unit.

[0018] Further areas of applicability will become apparent from the description provided herein. The description and specific examples in this summary are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.

DRAWINGS



[0019] The drawings described herein are for illustrative purposes only of selected embodiments and not all possible implementations, and are not intended to limit the scope of the present disclosure.

Figure 1 is a diagram depicting the layered architecture the controller area network;

Figures 2A and 2B are diagrams depicting a standard and extended data format, respectively, for a CAN data frame;

Figure 3 is a diagram illustrating the CAN communication model;

Figure 4 is a diagram illustrating how a rogue ECU attached to CAN via the OBD port attacks the vehicle;

Figure 5A is a diagram depicting an attack scenario where the attacker impersonates a valid sender sending a frame;

Figure 5B is a diagram depicting an attack scenario where the attacker modifies the frame transmitted from the valid sender;

Figure 6 is a diagram illustrating how the validity of a data frame may be checked by an electronic control unit in a vehicle network;

Figure 7A is a flowchart depicting steps taken by a sending electronic control unit to send a data frame in a vehicle network in accordance with the ID anonymization protocol;

Figure 7B is a flowchart depicting steps taken by a receiving electronic control unit in accordance with the ID anonymization protocol;

Figure 8 is a diagram depicting a framework for authenticating data frames by a controller;

Figure 9 is a diagram illustrating how priority bits are preserved in certain data frames;

Figure 10 is a diagram depicting a data frame for a session refresh;

Figures 11A and 11B are diagrams illustrating placement of an anonymous identifier in a standard and remote data frame, respectively;

Figure 12 is a diagram illustrating the process for authenticating data frames in a vehicle network;

Figure 13 is a diagram illustrating how a single success in sending a bogus message does not affect the entire protocol;

Figures 14A and 14B are diagrams illustrating the authentication process in relation to the sending controller and the receiving controller, respectively; and

Figure 15 is a diagram depicting a system model extending the ID anonymization protocol outside the vehicle.



[0020] Corresponding reference numerals indicate corresponding parts throughout the several views of the drawings.

DETAILED DESCRIPTION



[0021] Example embodiments will now be described more fully with reference to the accompanying drawings.

[0022] Figure 1 depicts a layered architecture of a Controller Area Network (CAN) node with the functions of different layers and ECU components. An electronic control unit (ECU) is a node interconnected between the CAN and other vehicle components, such as sensors or mechanical components. A vehicle usually contains 60-70 ECUs, and the cost-conscious automotive industry makes ECUs very resource-constrained. For example, 8-bit microprocessors are used for light-weight functions such as turning on/off lights, while 32-bit microprocessors are used for more mission/safety-critical functions such as engine control. While particular reference is made to CAN, it is readily understood that the concepts described herein are applicable more generally to other types of vehicle networks, such as LIN or FlexRay.

[0023] CAN is composed of four layers: physical layer 11, medium access control (MAC) (or transfer) layer 12, logical link control (LLC) (or object) layer 13, and an application layer 14.

[0024] The physical layer 11 defines how signals are actually transmitted. The CAN transceiver resides in this layer.

[0025] The transfer layer 12 represents the core of the CAN protocol. Most of the CAN standard corresponds to the transfer layer which receives frames from the physical layer and transmits them to the object layer. It presents the received frame to the object layer and accepts frames to be sent from the object layer. The transfer layer is responsible for fault confinement error detection, frame/message validation, acknowledgement, arbitration, message framing, transfer rate and timing, etc.

[0026] The object layer 13 is concerned with message filtering and handling as well as transmission status.

[0027] The application layer 14 handles higher-level non-standard operations following a vendor's own design. The CPU or host processor resides in this layer. The host processor determines the meaning of the received messages and which messages to transmit to itself. Sensors, actuators and control devices can be connected to the host processor.

[0028] In general, the CAN transceiver and MAC layer are hardware components, while the LLC layer could be a software component.

[0029] CAN is a wired multi-master broadcast serial bus that interconnects the various CAN nodes (ECUs) inside a vehicle. There are four types of CAN frames: a data frame that is used to transmit data; a remote frame that requests transmission of data from another ECU; an error frame that is used to indicate an error and transmitted by any unit on detecting a bus error; and an overload frame to introduce extra delay between frames.

[0030] The CAN standard data frame format and the extended data frame format are depicted in Figures 2A and 2B, respectively. Both contain 1 bit for start of frame (SOF) and 7 bits for end of frame (EOF). The arbitration field contains identifier (ID) bits and 1 bit for setting the remote-transmission-request (RTR) status. The standard frame format allows an 11-bit ID (Identifier field in Fig. 2A), while the extended frame format allows a 29-bit ID (Identifier A and B fields in Fig. 2B). Setting RTR to 1 means that the frame is a remote frame which does not carry any data.

[0031] Control field contains a 4-bit data length code (DLC) indicating the number of bytes of data, and reserved bits (1-bit identifier extension (IDE), and 1-bit r0 for the standard frame format and r1 for the extended frame format). For IDE bit, Dominate (0) indicates an 11-bit message ID while Recessive (1) indicates a 29-bit message ID.

[0032] Payload of a CAN data frame can carry up to 8 bytes of data. While the data frame is sent autonomously by sender ECUs/nodes, receiver ECUs/nodes can send remote frames to request data from a source node. A 16-bit cyclic redundancy check (CRC) field (with a 1-bit CRC delimiter) is provided to check the integrity of each received frame. 2-bit acknowledgement (ACK) field is used to check whether the frame is received correctly.

[0033] Error frames only contains 6 bits of consecutive 'Dominant' or 'Recessive' field with 8-bit 'Recessive' delimiter field. Overload frames only contains 6 'Dominant' bits for flag with 8 'Recessive' bits for the delimiter. Error and Overload frames are special types for abnormal situations, where an error is detected or the extra delay is required. For more information on the CAN frame formats, see ISO 11898-1:2003 or other related CAN standards. Data frames having other types of formats also fall within the scope of this disclosure.

[0034] Since CAN relies on a multi-master broadcast model, each ECU broadcasts frames and the transmission order is decided via a bus contention mechanism called arbitration. Each ECU broadcasts a frame ID, one bit at a time, and determines the transmission priority by comparing each corresponding bit with the bits broadcast by the other ECUs. The frame with the smallest ID wins the arbitration and gets transmitted. After winning the bus arbitration, the ECU writes the data frame serially (i.e., one bit at a time) onto the CAN bus. Other ECUs must wait until the winner's frame transmission is completed.

[0035] Figure 3 illustrates an example CAN communication model. Each data frame include a frame ID but does not contain an address for either the transmitter nor the receiver ECU. A data frame is broadcast over the serial bus, and each node proceeds with message filtering by checking the frame ID to determine whether to accept or ignore it. In the illustrated example, ECU 2 broadcasts frame 1 which is received by all ECUs on the CAN. ECUs 1 and 4 accept the frame, while ECU 3 discards the frame.

[0036] Several researchers have already reported the weakness of CAN's security support. For example, researchers have demonstrated vulnerabilities in current automotive networks by presenting various attack scenarios. There have also been reports revealing CAN's weakness in security when it is open to the external world. Other researchers have argued that CAN is insecure and vulnerable to DoS attacks. All of these issues can be attributed to the following major drawbacks of the CAN architecture.
  • There is no provision for authenticating the sender and the receiver of a frame.
  • A CAN frame has no authentication field.
  • The payload field in a CAN frame provides space for only up to 8 bytes of data, making it difficult to implement strong security primitives.
  • ECU's have too limited computation capability to support strong cryptographic functions.
It is, however, important to note that CAN was designed to be simple and cheap, and to operate in isolation inside a vehicle. Other protocols, such as Flexray, have also been introduced and deployed without addressing these and other security issues. It is difficult to overhaul the entire design of this architecture to support security mechanisms due mainly to automotive manufacturers' reluctance to adopt new standards for cost reasons. Moreover, such cost-consciousness resulted in deploying various types of ECUs as described earlier, which raises significant performance and DoS risks.

[0037] Various possible attacks on CAN and the requirements for securing it are discussed next. While most ECUs still operate in an isolated environment, they are getting exposed to external devices through CAN and the on-board diagnostic (OBD) port. There are also a growing number of in-vehicle components connected to external networks through Bluetooth, dedicated short-range communications (DSRC), etc. Also, car manufacturers started remote control services via an external gateway for the engine ignition and door lock/unlock. These increasing exposures of CAN can lead to three types of attack:
  • M1 - physically attaching a rogue ECU to CAN via the OBD port;
  • M2 - remotely comprising ECUs with external interfaces; and
  • M3 - physically compromising ECUs.


[0038] Several researchers have already demonstrated attacks on CAN via the OBD port. Figure 4 illustrates how a rogue ECU can read (1) or write (2) frames from/to the CAN bus. The rogue ECU may not follow the CAN's arbitration rule, since it could contain modified hardware components.

[0039] In another type of attack, ECUs are remotely compromised with external interfaces. For V2X communications, the in-vehicle network is connected to external entities through a gateway ECU with wireless interfaces, which could be the target of attack for the purpose of compromising in-vehicle components. In addition to, or in place of M1, attackers are likely to attempt to compromise the points exposed to the external world, e.g., gateway ECU and tire pressure monitoring system (TPMS), as shown in Figure 4.

[0040] An attacker can send/receive information to/from the in-vehicle network through the compromised ECU, but can only partially control communications. In this type of attack, the compromised ECU may contain modified software components, but most of its hardware components including the CAN transceiver and arbitration controller remain intact/uncompromised.

[0041] Physically compromising an ECU is a third type of attack. In this type of attack, the attacker has full control of the ECU, and hence, has access to the secret information inside it. Under this type of attack, both the hardware and software components of the ECU may have been modified, and hence, it may not follow the CAN arbitration rule. In practice, M3 represents an extreme case, as it requires full modification of an ECU. This disclosure does not consider the case of an attacker physically modifying internal ECUs and extracting or flashing data directly to/from the compromised ECUs, as this is highly unlikely, requiring breaking into the vehicle and physically modifying its ECUs.

[0042] Possible attack scenarios based on the above attack models are interception, fabrication, modification, and interruption.

[0043] For interception (under M1, M2, or M3), the attacker sniffs CAN and may then use the eavesdropped data or remote frames for replay attacks. Privacy risks of interception-only are not a critical problem for in-vehicle communications, and hence, will not be considered further in this disclosure.

[0044] For fabrication (under M1, M2, or M3), the attacker 51 broadcasts fraudulent data or remote frames on CAN as depicted in Figure 5A. In conjunction with interception, the attacker could also mount a replay attack. That is, the transmission of valid data can be repeated maliciously or fraudulently. The attacker intercepts the data first and retransmits it. This attack can be mounted at any time.

[0045] For modification (under M1 or M3), the attacker 51 changes the existing data frame to be transmitted on CAN as depicted in Figure 5B. This type of attack is possible only during the transmission of a genuine frame.

[0046] For interruption, the attacker may cripple data transmission with the following attacks. The attacker floods the victim ECU with unwanted requests for information using multiple data frames, thus making the ECU unavailable for legitimate requests, i.e., exhausting the ECU's computation resource. The attacker may also disrupts the ECU's receiver by transmitting a large number of high-priority data, remote, error or overload frames on CAN, thus preventing other ECUs from using the CAN. There is no way to prevent the attacker from transmitting high-priority frames over CAN, but equipping each ECU with a fail-safe mode can be an effective solution against the starvation attack.

[0047] To address the vehicular security issues and prevent possible attacks discussed thus far, certain design requirements need to be met under the following assumptions.

[0048] First, vehicles have built-in fault-tolerance with feedback mechanisms that can deal with signal spikes/faults. A single compromised frame is usually considered to have negligible impact on physical/mechanical systems.

[0049] Second, ECUs can check timestamps. Recent specification of secure hardware extension (SHE) for ECUs includes clock functions. Time synchronization in CAN was also proposed and takes place when the vehicle is turned on. Since the failure of time synchronization results in the failure of initiation, there is no incentive for attackers to cause it.

[0050] The security protocol must also be designed to meet the following requirements. The receiver should be able to check the authenticity of a frame against fabrication/injection and modification. The receiver should be able to avoid the retransmission of a valid frame. The protocol should be able to prevent the attacker from crippling ECUs with DoS attacks.

[0051] Additional automotive industry requirements include the security protocol should not cause any perceivable delay in delivering data frames to applications and the security protocol should not require any change to the existing CAN architecture. Since ECUs only perform certain functions, various computing devices, such as 8- to 32- bit micro-controllers, have been deployed with computing resources sufficient to handle the required functions. Therefore, the security computation should be within the capability of these resource-constrained devices.

[0052] Although the existing protocols check the authenticity of frames, they are still vulnerable to DoS attacks, i.e., an adversary transmits a very large number of frames to the ECUs on CAN. The CAN communication standard does not require node addresses and the content of a frame is only identified by its ID (defining the frame content) upon arrival at every ECU on the bus. Since there is no intermediate protection between the sender and the receiver ECUs, every receiving ECU verifies all frames upon their arrival. Thus, any attacker can transmit fraudulent frames to targets as far as CAN has bandwidth for their transport. On a 100% utilized a 1-Mbps CAN, the attacker can make a maximum of 215 attempts for a frame at 1000ms interval, assuming the attacker fully occupied the CAN. Requiring extensive computation on an ECU can degrade or even cripple its normal operation, especially in view of its limited resources.

[0053] There are also inefficiencies due to the CAN specification. The CAN frame format allocates a data field of up to 8 bytes in a frame. The frame data m and message authentication code MAC (k, m), where k is an authentication key, should be less than 64 bits of data in a frame. Certain frames use only a few bits; for example, Boolean type of data often requires at most 1 - or 0-bit data. In such a case, assigning MAC could significantly degrade the overall performance. Moreover, in case of a remote frame that contains no data field, it is not possible to assign MAC at all.

[0054] In view of these challenges, an improved ID anonymization protocol is presented for vehicle networks. Most of the existing work focuses only on authentication of frames upon their delivery. That is, the target ECUs verify the validity of each frame after receiving it. The two glaring drawbacks of this approach are: (1) receivers first accept all incoming frames irrespective of their validity; and (2) receivers need to do cryptographic computations to verify the validity of all frames, which inevitably incurs a significant additional delay. These, in turn, enable DoS attacks on resource-constrained devices like ECUs.

[0055] To overcome these drawbacks, a new concept is presented in which the ID is made anonymous to unauthorized entities, but identifiable by the authorized entities (referred to herein as ID anonymization). With reference to Figure 6, a frame filter 61 in the ECU 60 is configured to receive an incoming data frame, extract the anonymous ID from the frame and compare the anonymous ID to a pre-computed ID stored locally by the ECU 60. When the IDs match, the data frame is passed along the message authenticator 63 for further processing. The message authenticator 63 in turn checks the validity of frame data using a message authentication code (MAC) embedded in the frame. Once authenticated, the data frame is processed in a conventional manner. Conversely, invalid frames are filtered by the filter 61 without requiring any additional run-time computation by the ECU.

[0056] An ID generator 64 is also configured to receive the incoming data frame. When the anonymous ID extracted from the incoming frame matches the pre-computed ID, the ID generator 64 generates a new frame identifier, where the new frame identifier is derived in part from the extracted anonymous ID and a cryptographic key as is further described below. The newly generated frame identifier replaces the pre-computed ID and is used for validating the next data frame.

[0057] Figure 7A further depicts the steps taken by a sending electronic control unit to send a data frame in a vehicle network in accordance with the ID anonymization protocol. The data frame is first formatted at 72 in accordance with the applicable communication protocol. For illustration purposes, reference is made to CAN. Of note, the data frame includes an identifier as discussed above in relation to Figures 2A and 2B. The proposed anonymized ID is retrieved at 71 from a local data store and inserted into the identifier field of the data frame; remainder of the data frame is formatted in accordance with the application protocol. Once the frame has been formatted, a message authentication code may be computed for the frame as indicated at 73. In one example, the message authentication code is derived from a cyclic redundancy check although other types of codes are contemplated by this disclosure. The message authentication code is appended to the data frame and the data frame is sent at 74 across the vehicle network by the sending electronic control unit.

[0058] After sending the data frame, the sending ECU generates the anonymized ID for use in formatting the next frame as indicated at 75. In one example, the anonymized ID (i.e., next frame identifier) is derived from the previous frame identifier and a cryptographic key using an encoding function, such as a keyed hash function. An identifier assigned by the manufacturer may be used as the initial value for the previous frame identifier. The cyptographic key may be any secret key stored locally and shared between the sending ECU and the intended message recipient (i.e., receiving ECU). Alternatively, the cryptographic key may be unique to the communication session and negotiated between the sending ECU and the receiving ECU. The anonymized ID is then stored for use in transmitting the next data frame. It is to be understood that only the relevant steps of the methodology are discussed in relation to Figure 7A, but that other software-implemented instructions may be needed to control and manage the overall operation of the sending ECU.

[0059] Steps taken by the receiving electronic control unit upon receiving a data frame are shown in Figure 7B. Upon receipt, the anonymized ID is first extracted from the data frame without decoding any portion of the data frame as indicated at 82. Next, the extracted anonymized ID is compared at 83 with a stored frame identifier which has been derived from the immediately preceding data frame. When the extracted frame identifier matches the stored frame identifier, payload of the incoming data frame is authenticated at 86. In particular, the message authentication code is extracted from the incoming data frame and used to authenticate the data frame, where the message authentication code differs from the extracted frame identifier and is derived in part from the payload in the incoming date frame. For example, the payload of the data frame can be authenticated using a cyclic redundancy check. Once authenticated, the incoming data frame can be processed as indicated at 87. Conversely, when the extracted frame identifier does not match the stored frame identifier or the payload is not authenticated, the incoming data frame is discarded as indicated at 85. It is to be understood that only the relevant steps of the methodology are discussed in relation to Figure 7B, but that other software-implemented instructions may be needed to control and manage the overall operation of the receiving ECU.

[0060] IA-CAN protocol introduced above authenticates both sender entities and messages. Only an authorized sender/receiver can generate/identify a valid anonymous ID using a shared secret key and a random nonce. The frames broadcast by a valid sender will be received by only a valid receiver whose filter contains a matching pre-computed anonymous ID. The authorized receiver will immediately filter out invalid frames without requiring any computation. An unauthorized ECU on vehicle network cannot identify the original frame ID from an anonymous ID. The authorized receiver will immediately filter out invalid frames without requiring any computation. An unauthorized ECU on the vehicle network cannot identify the original frame ID from an anonymous ID. Since each anonymized ID is used only once, the attacker does not gain anything from reusing the captured ID, i.e., replay attack is not possible.

[0061] An anonymous ID provides message authentication against M2, which is the most probable attack. In the case of message modification by ignoring the CAN arbitration rule, the payload data is verified by the payload data authentication code. It prevents the attackers from randomly modifying the payload of unidentified frames by overriding bits on the CAN. Compared to previous models, IA-CAN can save more payload bits with a smaller MAC in conjunction with anonymized IDs.

[0062] Since the frame ID is altered on a per-frame basis, the attacker cannot replay frames using sniffed IDs as they will no longer be valid. IA-CAN is resilient to DoS attacks on ECUs as the receiver ECU will only accept frames with IDs that match the pre-computed ones. Since each ID to be filtered/passed needs to do only 11- or 29-bit string XOR computations, the associated overhead is negligible. The runtime overhead for frame authentication is incurred only when the frame is accepted by the frame filter.

[0063] Lastly, IA-CAN uses a two-step authentication process, and does not incur any additional latency compared to previous models. The computation delay for generating anonymous ID migrates from post-delivery of a frame to its pre-delivery, since the receiver pre-computes an anonymous ID in parallel with the transmission of the current frame. This reduces the communication latency significantly. The performance impact of generating anonymous IDs is discussed later in this disclosure. While payload data authentication to secure data frames incurs an additional runtime delay, the overall latency for the two-step authentication is the same as the previous models.

[0064] Figure 8 depicts in more detail a system model for IA-CAN. In an example embodiment, the system under consideration consists of n ECUs, ei, 1 ≤ in, connected to a vehicle network. Each ECU ei contains a reconfigurable frame filter

, a set of keys

, and a set of cryptographic hash functions

.

[0065] The frame filter

maintains a list of frame IDs that it accepts, where idj is a unique data frame ID,

is a unique remote frame ID, 0 ≤ j ≤ 211 (or229), and



is a maximum preset integer. Initially,

While the length of idj,0 is 11 (standard format) or 29 bits (extended format), the length of idj,Υ is defined as 11 - α + ζ bits or 29 - α + ζ bits for idj,Υ, and (16 - α) bits or (34 - α) bits for

where α is the number of bits used to specify priority and ζ is that to specify the data field. For remote frames, α is an option.

[0066] To ensure compatibility with CAN, the frame must be ensured to be transmitted according to their priority specified in their frame IDs. Thus, there is a need to ensure the preservation of frame priorities even after ID anonymization. To meet this requirement, the priority bits in the ID are kept intact and only the remaining bits are anonymized as shown in Figure 9. If the first α bits are used to specify priority, then the remaining (11 - α) or (29 - α) bits are used for ID anonymization. For example, the SAE J1939 standard assigns the first 3-bits of the 29-bit ID for specifying priority.

[0067] To make brute-force attacks difficult on a small number of anonymized bits (i.e., 11 - α or 29 - α bits), an additional ζ bits are borrowed from the data field to expand the anonymization field as shown in Fig. 9. In such a case, two-step frame filtering is required: a frame is filtered first by the ID field at the frame filter (step 2 in Fig. 8), and then by the anonymized bits in the data field (step 3 in Fig. 8). Since the remote frame contains no data field, ζ bits from the data field cannot be borrowed, but up to 5 bits can be assigned in the control field (DLC and r0). Also, α bits can also be assign as an option.

[0068] In the example embodiment, the set

maintains a set of secret keys associated with

, where kj is a symmetric long-term key associated with idj,0. ECUs send/receive a frame with idj,0 containing kj. The key management works as described next. IA-CAN follows the key management model further described in "CANAuth - A Simple, Backward Compatible Broadcast Authentication Protocol for CAN bus", (A. Herrewege et al., 10th escar Embedded Security in Cards Conference (November 2011)) that assigns a pre-shared long-term key to each unique frame ID. Each group of ECUs receiving a certain frame ID gets a pre-shared key uniquely assigned by manufacturers. The keys are stored in a tamper-proof storage and can be queried only by the node itself as stated in assumption A1. The lifetime of an ECU is usually the same as that of the vehicle, and hence, the size of an initial long-term key should be designed to support for approximately 10 to 15 years.

[0069] ECUs are capable of cryptographic computation, as specified in the Automotive Open System Architecture (AUTOSAR) standards. Several algorithms are specified in "Specification of Crypto Service Manager" (AUTOSAR 2013, Technical report, Automotive Open System Architecture (2013)). In the example embodiment, HMAC-SHA1 is used for the evaluation of IA-CAN although numerous other cryptographic functions fall within the scope of the disclosure.

[0070] Secure Hardware Extension (SHE) specifies the clock function deployment into ECUs, although the CAN standard does not specify time synchronization. The authors of "Message Authenticated CAN" (Hartkopp et al, CAN escar 2012, Embedded Security in Cars Conference, Berlin, Germany (November 2012)), proposed time synchronization using the clock in ECUs over CAN. Thus, the proposed protocol assumes ECUs with the clock function and time synchronization between ECUs.

[0071] IA-CAN is designed to address all the attack scenarios mentioned earlier. Table I below shows a complete set of notations and their descriptions. For discussion purposes, consider a sender ECU e1 broadcasting a frame associated with idj,0 to a target ECU e2 among the receiver group.



[0072] A session refresh phase is initiated when a session is set up between e1 and e2 for the first time, or when the session key needs to be refreshed. For example, a session refresh can be done when the car is getting turned on, or the counter reaches the maximum present count, ctrj,θ. Considering general public driving patterns, it is reasonable to assume a session period of 24 hours. Or, against M2, the session can be shortened. The maximum θ or session period can be pre-defined by the vehicle manufacturer during the design of CAN. Under A2, a session can be refreshed every minute, hour, day, or a pre-defined period with the maximum count Tj × ctrj,γ.

[0073] ECUs e1 and e2 must agree on a random nonce selj,δ, and algorithm ALG (to select a MAC in

) for generation of the session update information, Updatej,δ. e1 first selects selj,δ and generates a hash output Updatej,δ:

When the session is initiated for the first time, REMj,γ is not included in Updatej,δ. REMj,γ is used to maintain the freshness of an update request. If ECUs support time synchronization, current timestamp - instead of REMj,γ - can be included to prevent replay attacks.

[0074] Selection of a MAC from

will affect the output size. For example, using HMAC with SHA-1 for f1 would result in a 160-bit output, which can be transmitted in multiple frames. Or, a truncated output can also be used to transmit in a single frame. Then, e1 sends selj,δ, Updatej,δ to e2 as shown in the format of Figure 10.

is an anonymous ID for the frame, and

is ζ bits borrowed from the data field. Initially,

and

are padded with 0s. INIT is to indicate that the frame is for session refresh, and ALG is for indicating h and f1 from

.

[0075] When e2 receives a frame, as shown in Figure 12, it verifies Updatej,δ by generating Verifyj,δ, where f1 : {idj,0, selj,δ, kj REMj,γ} → Verifyj,δ. If Updatej,δ, e2 accepts selj,δ to update the session key as follows. e2 generates

and

where

h The key generation function h is chosen from

.

[0076] During the session δ, both e1 and e2 generate anonymous IDs (not at the same time, though) using the session key

shared between them. e1 and e2 generate idj,γ and

as follows.

[0077] On the sender side, as soon as e1 finishes sending the (previous) frame with idj,γ-1 (as shown in Fig. 12(1)), it generates Outputj,γ from idj,γ-1,

REMj,γ-1 and

using f1.

Next, idj,γ is extracted from Outputj,γ using

e1 and e2 store

and the remaining bits REMj,γ after the ID is extracted.

is used only when e2 needs to send a remote frame. e1 also updates

at its frame filter. There can be several ways to select idj,γ from Outputj,γ, but we assume f2 to truncate Outputj,γ to fit the size of idj,γ and

e1 then updates idj,γ to idj,γ+1, and stores REMj,γ to generate the next anonymous ID.

[0078] On the receiver side, as soon as e2 receives the previous frame and verifies it, it generates Outputj,γ with

idj,γ-1, and REMj,γ-1, and then retrieves idj,γ and

The filter

immediately replaces idj,γ-1 with idj,γ in the frame acceptance list (as shown in Fig. 12 (4)). e2 now waits for the next frame with the new ID idj,γ. At such iteration or after a certain time elapsed, the counter is incremented by 1 until it reaches ctrj,θ. The time period of idj,0 is preset as a design parameter. When the counter reaches ctrj,θ, REMj,γ is used to generate Updatej,δ, which is then transmitted with idj,γ.

[0079] As described earlier, a remote frame is transmitted by a receiver ECU e2, when it needs to request a data frame. Since the remote frame does not contain the data field, it can use 4 bits of the DLC field for an anonymous ID. The reserved bit r0 can also be used.

[0080] As the CAN standard specifies both Data and Remote frames to share same identifier, different anonymous IDs are designed for the two types of frames. While the ID of a Data frame is idj,γ, assign

as the ID of a Remote frame which (16 - α) bits (the standard format) or (34 - α) bits (the extended format) extracted from REMj,γ. For the Remote frame, α can be an option.

[0081] Use of anonymous IDs prevents injection of unauthorized frames (defense against M2). However, attackers with M1 or M3 can modify frame data, although they represent extreme cases. So, we also provide data authentication for payloads. A MAC is generated for a payload. When a payload mj,γ is generated, sender ECU e1 generates a β-bit MAC

, where f1 :

e1 then puts

in the data field as depicted in Figure 11A. The size of β is a design parameter. For practical security strengths, 11 (or 29) + ζ + β ≥ 32 is recommended, where 11 (or 29) + ζ is the size of anonymous ID and β is the size of

.

[0082] While IA-CAN proceeds with anonymous ID generation immediately after the previous frame is transmitted/received, since it has no relation with the frame data itself, MAC for payload authentication can be generated when the payload data mj,γ is generated/received. Thus, the runtime latency tm for payload data authentication code generation is invoked.

[0083] For the Remote frame in Figure 11B, this phase is skipped since it has no data field.

[0084] When e2 receives a message, it checks whether the frame ID idj,γ matches one of IDs in the acceptance filter list

(Fig. 12(2)). If a match is found (as shown in Fig. 12(2)), e2 accepts the frame and then performs an integrity check, for example using CRC (Fig 12(3)).

[0085] For a non-zero-bit data frame, e2 verifies the authenticity of message mj,γ by comparing

with

, where



. If

e2 accepts the frame. Whether e2 accepts the frame, or the time period Tj ends (when time synchronization is available), it repeats the process in the Anonymous ID generation phase to generate the next ID idj,γ+1 (Fig. 12(4)).

[0086] For a Remote frame, as soon as e1 accepts the frame, it filters the valid

Then, the sender ECU e1 can send the data frame with idj,γ.

[0087] Next, the security of IA-CAN is evaluated and analyzed. In particular, it is shown that IA-CAN provides frame authentication against injection and modification, and is secure against replay attacks and interruption, which are the requirements listed earlier in this disclosure. The following definitions will be used here.

[0088] Definition 1. A MAC generator

satisfies the first and second preimage resistance as well as collision-freedom, and transforms t arbitrary messages/frames m to a uniformly-distributed N-bit hash output Yn using a shared key kj.

[0089] Definition 2. A function

truncates YN to Yn and YN-n, where Yn is an n-bit truncated part of YN, nN, while YN-n is the remaining (N - n) bits of YN. For example, consider a truncated output from a 160-bit hashed output using SHA-1.

[0090] Definition 3. An attacker Adv's function

is used to generate

which is to be believed as Yn using his own resource mAdv. It is assumed that Adv can obtain idj,γ-1, AG and selj,δ by eavesdropping on the CAN bus.

[0091] The security of IA-CAN is shown against the attacker's malicious injection. An attacker Adv with M1, M2 or M3 can inject a fraudulent Data frame or a fraudulent Remote frame to the CAN bus. Suppose Adv injects a fraudulent Data frame with idAdv and

.

[0092] Security of Anonymous ID (Step 1 only). Show the security of anonymous ID by following four theorems. Let

be the i-th hash output of N bits, where

and let

be the i-th frame ID formed by truncating n bits out of an N-bit string.

[0093] Theorem 1. Authorized entities can identify the message he must accept.

[0094] Proof. An authorized user

who already knows kj,



can generate

Thus

can immediately identify whether the received message Rn is identical to the pre-computed

Thus, Theorem 1 follows. Thus, a pseudo-random number generator or bloom filter is not used to satisfy Theorem 1.

[0095] Theorem 2. The probability that Adv finds idAdv, where idAdvidj,γ, with

is not higher than the probability that Adv randomly selects it.

[0096] Proof. Adv who does not know kj and

can intercept

from the previous transmission. If Adv knows

which

he can identify

being transmitted or send a fraudulent frame with

However, by Definition 1, the probability of generating a compromised message

with known information

is not greater than the probability of finding collision from a randomly-generated message. Thus, the theorem holds.

[0097] Theorem 3. A success in compromising a message does not increase the probability of compromising the subsequent messages.

[0098] Proof. Let the probability of Adv's success in finding

be

Once Adv succeeds in finding the collision

he will try to find the next collision

using mAdvi, in addition to mAdvi+1, with a success probability

where



If a successful finding of collision does not increase the probability of finding future collisions,

then Lemma 3 holds.

[0099] Since

is generated by truncating

the probability of finding a collision from

is the same as that of finding a collision from the full-sized hash output. While

is generated from



as



and

is also a truncation of

the probability of finding a collision of

only depends on the strength of

which has the same probability of finding a collision of

Therefore

and

are independent, and

So,

So, even though the attack collides with

it doesn't affect/increase the probability of finding collisions for the other Yi+1, and hence, the theorem holds.

[0100] Theorem 4. A single success of compromising a message does not affect the entire protocol operation.

[0101] Proof. As shown in Fig. 13, let us assume Adv successfully sends a bogus frame with idAdv and

where idAdv = idj,γ and

although the probability of success is negligible as shown earlier.

[0102] In such a case, the receiver ECU will accept it and wait for the frame with idj,γ+1. idj,γ from a valid sender will be discarded in this case. However, the sender ECU will send idj,γ+1 for the next frame, and then the receiver ECU will accept it again.

[0103] If Adv still generates 11 (or29)-α + ζ-bit

with

, and the target ECU ei's filter Fi, Adv still has to generate β-bit

with fraudulent data mAdv without knowing

and REMj,γ. The probability that the attacker compromises both anonymous ID and MAC is

for standard data frames and

for extended data frames. The attacker can continuously mount this attack as far as the CAN bus has capacity of accommodating it.

[0104] Adv can also attempt to inject fraudulent Remote frames. Since the size of

for a Remote frame is only 16(or34)-α bits, the probability of success that Adv injects idAdv, where

idAdv could be higher. However, successful attacks only allow the sender ECU to transmit a Data frame, giving no meaningful benefit to Adv. Thus, this attack will be meaningful with data frame modification for which only M1 and M3 can proceed. In such a case, the probability that the attacker compromises both anonymous ID of a remote frame and MAC in the Data frame is

for the standard format and

for the extended format. Adv can continue transmitting the Remote frame as far as the CAN bus has capacity to accommodate the attack traffic, but the attack on the Data frame can proceed only once.

[0105] Additionally, the attacker can mount a brute-force attack to find idAdv, idAdvidj,γ or

idAdv with

. Since idj,γ and

are used only once and only valid for one frame, the attacker is forced to guess the valid IDs on a per-frame basis. The attacker must therefore be able to transmit multiple fraudulent frames consecutively during one transmission interval, but such an attack is highly unlikely to succeed as we show below.

[0106] For the anonymous ID part (Step 1), Adv's probability of success is

for the standard format and

for the extended format, when α bits are assigned for the priority and ζ bits are assigned for additional anonymization bits. For the MAC part (Step 2), Adv's probability of success to find

,

with

is 1/β, when β bits are assigned for the MAC.

[0107] Let's assume the worst case when Adv initiates a brute-force attack by transmitting 44-bit (0 bit for the data field in Fig. 2) frames on the CAN bus of 1 Mbps (i.e., maximum CAN bandwidth) and 100% utilization (usually 30-40% utilization). Then, Adv can theoretically transmit up to 22727 frames per second (assuming there is no frame drop), Adv's chances are limited to the interval p of frame transmission. When p = 1000ms, Adv can try up to 22727 (< 215) times, and when p = 5ms, Adv can try up to 113 (< 27) times.

[0108] Manufacturers can flexibly assign α bits from the ID field and ζ bits from the data field for anonymous ID and β bits for MAC, depending on the CAN design. For example, the attack's success probability for the standard format is

where α = 6, ζ = 8, and β=32. In this case, a brute-force attack is infeasible even when the frame interval p = 1000ms. Also, even ζ = 0, for Adv to succeed in the attack for the frame with p = 5ms is obviously infeasible. Note that attacks can be mounted via the CAN bus, and are thus limited by the CAN's communication bandwidth.

[0109] Security of IA-CAN against modification is also demonstrated. Since the Remote frame modification only results in frame drops and gives no incentive for Adv, we only assume Adv try to modify a Data frame over CAN from the sender ECU.

[0110] Suppose Adv modifies a target frame with idj,γ that is being transmitted on the CAN bus. Adv can try to modify mj,γ and

to

and

without knowing

(only with

). Adv's probability of success in finding

,

without

is 1/2β, when β bits are assigned for the MAC. Adv can mount this attack once only when the target frame is being transmitted by legitimate sender ECU.

[0111] Next, the resilience of IA-CAN against replay attacks is shown. For this type of attack, Adv captures frames and tries to use them for the next frame transmission or session. Suppose Adv captures an anonymous ID idj,δ and sends the target ECU ei forged frames with idj,δ.

[0112] Adv's attempts will fail because the filter idj,δ to idj,δ during the anonymous ID generation phase after receiving idj,δ, and idj,δ is no longer valid. All valid IDs are discarded by Fi as shown in Figure 3. Adv cannot resend

as

either, since REMj,γ+1REMj,γ.

[0113] Adv may capture selj,δ and try to send it for a fraudulent update to use captured IDs. Suppose Adv has idAdv, idAdv = idj,γ and ei receives the bogus frame to refresh the session. However, to make ei accept selj,δ as selj,δ+1, Adv should be able to make ei use REMj,γ for Updatej,δ to be verified as Updatej,δ+1. The probability that REMj,γ = REMj,γ+1 is negligible.

[0114] Lastly, the security of IA-CAN is shown against interruption. Adv generates a number of frames for arbitrary target ECUs using compromised (or attached) ECUs. Since the attacker's objective is to cripple in-vehicle communications by disabling target ECUs, he may attempt to generate a large number of high-priority frames, which the target ECUs will accept.

[0115] Under IA-CAN, since ECUs update the acceptance filters on a per-frame basis, such flooding attacks are prevented. The process of checking an anonymous ID is the same as the general CAN architecture described earlier. Checking the additional bits in the data field is ζ bitwise operations which incur negligible overhead. For the data frame, the ECU only checks the authenticity of payload in the frame that passed through the frame filters.

[0116] Adv with M1, M2, or M3 can mount starvation attacks so that the victim ECUs may not receive frames from the CAN bus. Adv may try to disable specific targets or the entire network.

[0117] Adv with M1 and M3 can overwrite bits into anonymous ID idj,γ that will lead the receiver ECU to drop the frame. As described earlier, if time synchronization is available, under A2, the receiver updates anonymous ID idj,γ to idj,γ+1 after the time Tj elapsed.

[0118] Another way of mounting a DoS attack on CAN is just flooding a large number of high-priority (garbage) messages on the CAN bus. For example, flooding an ID with 0x00 will always win the bus arbitration. Although there is no way to prevent attackers from broadcasting bogus messages to overload the CAN, several research efforts introduced intrusion detection mechanisms against such flooding attempts on CAN. Moreover, initiating a fail-safe mode when ECUs do not receive frames within a certain time will effectively give resiliency against such an attack.

[0119] Performance of the IA-CAN is evaluated below. Table II lists the computations required for IA-CAN, where H is the amount of computation for a cryptographic one-way compression function such as SHA-1, XOR the computation of XOR, and F the amount of computation for a non-cryptographic function that divides one string into multiple parts. The overheads of XOR and F are negligible compared to H.
Table II. Computation overhead
PhaseComputationOperation
Session refresh 3 H Session initiation time
Anonymous ID generation 1 H + 1 F Idle-time
Payload authentication code generation 1XOR + 1 H Run-time (Sender)
Data frame authentication 1XOR + 1 H Run-time (Receiver)
Remote frame authentication 1XOR Run-time (Receiver)


[0120] Even a millisecond computation delay may result in unpredictable vehicle control behavior (often related to safety). It is therefore important to consider the time overhead of hash computations. Based on both performance and cost considerations, ECUs are usually built with 8- to 32-bit microprocessors with various capabilities. Let tl (th) be the computation time of H in a low-end (high-end) microprocessor. To estimate tl and th, the overheads for 8-bit, 16MHz Arduino UNO R3 for low-end processors and 32-bit, 40MHz Chipkit 32MAX for high-end processors by implementing the HMAC-SHA1 function were evaluated. More specifically, four example cases were evaluated: SHA-1 with 64-byte key (A.1), SHA-1 with 20-byte key (A.2), SHA-1 with 100-byte key (A.3), and SHA-1 with 49-byte key, truncated to 12-byte HMAC (A.4).
Table III, Average computation time for HMAC with SHA-1 on a low-end microprocessor (8-bit, 16 Mhz Arduino UNO R3) and a high-end processor (32-bit, 40 MHz Chipkit 32MAX)
 tl, 8bit, 16Mhz Arduino UNO R3th, 32bit, 40MHz Chipkit 32MAX
Cases1 trial (µs)25,000 trials (µs)1 trial (µs)25,000 trials (µs)
A.1 12.152 287,506,800 230 5,717,186
A.2 12.156 287,506,800 287,506,772 228 5,717,187
A.3 12.160 287,506,768 228 5,718,086
A.4 12.156 287,506,792 228 5,717,370


[0121] The result on the 8-bit microprocessor with a 16MHz clock incurred an overhead tl of approximately 12ms for one-time computation and 287 seconds for computation for 25,000 times, while the 32-bit microprocessor with a 40MHz clock, exhibited an overhead th of approximately 200µs for one-time computation and 5.7 seconds for computation for 25,000 times in each of the scenarios as listed in Table III. Computation of SHA-1 is shown to take less than 1.2ms on an 80Mhz 16-bit microprocessor. Mathematica is shown to take approximately 2ms for one time computation and 32 seconds for 25,000 times computation on the Intel i7 2.7GHz dual core; these numbers are used for the attack simulation.

[0122] In contrast, it takes only about 4µs to perform bit-comparison for 25,000 times on the 8-bit Arduino UNO R3, which is negligible, compared to the time required to generate MAC once on the same microprocessor.

[0123] Commonly-used payload authentication models invoke the cryptographic computation before an ECU transmits each frame, and also after the ECU receives it. The actual frame latency thus depends on the cryptographic computation time tm, and hence the previous models focused on how to reduce the message authentication delay tm. One such example is the protocol in which reduces the delay by authenticating 4/8 frames at a time. This approach incurs less overhead but, since the message can be authenticated only after receiving all the frames, it still incurs a long frame latency.

[0124] Although IA-CAN performs a two-step authentication process, the runtime latency of IA-CAN is not different from previous models, since the first step that generates an anonymous ID is computed only during an idle time as depicted in Figure 14. The latency of checking IDs in the filter remains the same as the original CAN model.

[0125] Let

be the period of low (high) frequency frames. The periods of CAN frame transmissions used in several SAE range from 5 to 1000ms. Usually, higher-end processors are used for more critical processes with higher frequencies and shorter periods (e.g.,

), while lower-end processors are used for less critical processes with lower frequencies (e.g.,

100ms).

[0126] To guarantee the feasibility of IA-CAN, the inequality Tj >> t' (as depicted in Fig. 12) should hold, where Tj is the frame transmission interval time at the sender side. t' is the computation time required for a session update including verification, key generation, and anonymous ID generation, and tn for anonymous ID generation, where t' ≃ 3tn. For the frame arrival interval

at the receiver side



due to the possible transmission latency of CAN. The results show

and

and hence IA-CAN easily satisfies the inequality Tj >> t'. That is, an anonymous ID generation is trivially done within idle time.

[0127] An anonymous ID of IA-CAN only invokes bit-comparison before transmitting a frame and after receiving it, so the runtime frame latency is negligible. For full steps of IA-CAN, the sender ECU computes MAC for payload authentication just before its transmission, and the receiver ECU also computes MAC after performing IA-CAN. While both IA-CAN and MAC generation incur the computation overhead, the runtime latency is still tm, contributed only by MAC generation. Note that HMAC-SHA1 is used for the evaluation purpose mentioned earlier, and does not exclude use of other algorithms for MAC and anonymous ID generation.

[0128] Performance of IA-CAN under attack is also evaluated. For attack scenarios, it can be assumed that the attacker transmits bogus frames to a certain target where the following aspects must be considered.

[0129] For bus speed (i.e., 125/500/1000 kbps), currently, the CAN standard supports up to 1 Mbps, while practical implementations still use 125 kbps.

[0130] For bus utilization, practical implementations utilize 20-30% of CAN bandwidth to ensure that all frames will meet their deadlines. There have been numerous efforts to increase bus utilization, so it is assumed the maximum 100% utilization as an ideal case.

[0131] For frame length, 44-108 bits for the standard format. The actual number of bits in a frame without accounting for the data field is 44 bits with 1 bit SOF (Start of Frame), 12 bits for arbitration, 6 bits for control, 16 bits for CRC, 2 bits for ACK, and 7 bits EOF (End of Frame). The size of data field ranges from 0 to 8 bytes.

[0132] For frame interval (i.e., 5/100/500/1000ms), these intervals are pre-defined by the vendors, and example numbers are taken from the SAE benchmarks.

[0133] For attacker's bus occupation (up to 100), while the attacker can increase data transmission by a negligibly small amount, we also consider the case when he occupies the entire bus.

[0134] For length of an anonymous ID, 16 bits for an anonymous ID is used in IA-CAN. 16 bits are assigned for fair comparison with 16 bit-truncated MAC for the payload authentication model. Assuming 5 bits assigned for priority, 6 bits are assigned in the ID field for

and 10 bits in the data field for

For IA-CAN for Data frame, two cases are shown: assigning 6 bits for

(small ID) and 16 bits for

For Remote frame case, α = 0. For the size of Message Authenticate Code (MAC), 16 bits of truncated MAC are used for general payload authentication as well as IA-CAN for data frame. 8 or 32 bits can also be assigned.

[0135] Assuming an attacker occupies the entire bus utilizing 100% of its bandwidth, the maximum number of possible attack trials are specified as in Table IV. Note that the case when attackers mounts DoS attacks on CAN bus itself is not considered.
Table IV. The maximum possible number of trials an attacker can make on a 100 % utilized bus, 100% attacker occupied, transmitting a 40-bit frame.
 Maximum possible trials for the frame interval of
Bandwidth1000ms500ms100ms5ms
1000 25,000 12,500 2,500 125
500 12,500 6,250 1,250 62
125 3,125 1,562 312 15


[0136] Simulation results were obtained for the following four models:
  • Data in the payload authentication model (PA) / M1, M2, M3
  • IA-CAN for the Remote frame (anonymous ID only) / M2 only
  • IA-CAN for the Data frame assigning ζ bits / M1, M2, M3
  • IA-CAN for the Data frame without ζ bits / M1, M2, M3 IA-CAN for a Remote frame contains only an anonymous ID, while that for a Data frame contains both anonymous ID and payload authentication. A 16-bit anonymous ID is assigned in IA-CAN for a Remote frame, a 6- or 16-bit anonymous ID is used in IA-CAN for a Data frame. For a fair comparison, a 16-bit MAC is assigned for payload authentication.


[0137] It is also assumed the ideal attack scenarios in which an attacker occupies the entire bus utilizing 100% of its bandwidth and the maximum number of available attack trials is specified as in Table IV. Simulated attacks were tested using Mathematica on an Intel i7 2.7GHz dual core processor. HMAC-SHA1 operation is computed 25000 times for each frame, which takes approximately 31 seconds in this setting.

[0138] Six ideal attack cases are shown, where the attacker transmits 40-bit bogus frames, occupying the entire bandwidth of a 100%-utilized bus. The first three cases are for the frames with a 100ms inter-arrival interval, and the last three cases for the frames with a 5ms interval, on 125kbps, 500 kbps, and 1Mbps buses in sequence.

[0139] Case 1: p = 1000ms. In this scenario, the attack proceeds with frames at a 1000ms-interval on the 125/500/1000 kbps CAN bus. IA-CAN for the remote frame takes approximately 20/70/134ms, while the general PA using MAC takes 4/16/31 seconds, exceeding the 1000ms time-bound. Using IA-CAN for the data frame, assignment of 6-bit anonymous IDs takes 90/400/679ms which is still far below the 1000ms bound, while assigning 16-bit anonymous IDs still takes 30/70/156ms.

[0140] Case 2: p = 5ms. In this scenario, the attack proceeds with frames at a 5ms-interval on the 125/500/1000kbps CAN bus. IA-CAN for the remote frame takes approximately 1.7/2.4/3.2ms, while the general PA using MAC takes 23/85/167ms, which exceeds the 5ms time-bound. Using IA-CAN for the data frame, assignment of 6-bit anonymous IDs takes 4.1/4.8/8.2ms, while assigning 16-bit anonymous IDs still takes 2.8/4.6/5ms.

[0141] Cases 2 show that the computation of IA-CAN for data frame when a small ID (6 bits) may exceed the time-bound on a high-speed bus because with a high probability, there will be collision from 26 bits. Thus, to avoid such an overhead, assigning more bits ID with

is recommended. In fact, 100% bus utilization with 100% bus occupation for one frame is unlikely in reality; the bus utilization is usually 30-40%.

[0142] In comparison, IA-CAN is very efficient, not incurring any additional notable runtime overhead for anonymous ID compared to previous models. Although previous models that only provide payload authentication using MAC can achieve the authenticity of payload data, the computation overhead incurred by a DoS attacker as is plotted. Simulation results show that the general PA models incur approximately 285x more computation overhead than IA-CAN under attacks. Table V compares the models summarizing the results discussed above.
Table V. Design comparison
TypeDoS resilience on ECURun-time Latency
NormalAttack exists
Payload authentication X tm Exceed time bound
IA-CAN (remote frame) negligible within time bound
IA-CAN (without ζ bits) tm within time bound
IA-CAN tm within time bound


[0143] The ID anonymized protocol can be extended to support communications outside of the vehicle network. In remote access or V2X communications, the compromised ECUs that interconnect the external entities to the in-vehicle network, are still susceptible to intelligent attacks. The attackers could compromise the gateway ECUs (or any ECUs with external interface) and send malicious information into the in-vehicle network.

[0144] For external communication, the extended IA-CAN is modified as follows. With reference to Figure 15, an external entity sends a remote command to the gateway ECU. The external entity (EE) wants to initiate a new session of RC1 with a gateway ECU (GE). A known protocols can be used to establish a secure channel. As a result of the establishment, EE and GE share a secret key (K1). EE sends a random nonce (N1) to GE using the secure channel. EE first generates N1 and H{N1}, where H{N1} is hash of N1. EE then encrypts N1 and H{N1} with K1. That is, EE → GE: ENC(K1,N1,H{N1}). GE decrypts N1 and H{N1} using K1, and checks the integrity of N1 and H{N1}. Next, GE generates a second random nonce (N2) and another hash value H{N1|N2}, then encrypt them with K1. GE sends it to EE as follows: GE→EE: ENC (K1,N2,H{N1|2}). As a result, GE and EE share N1 andN2. Purpose of sharing N1 and N2 is to guarantee the freshness of session between GE and EE.

[0145] After exchanging random nonces, EE selects RC1 and generates a certificate (CERT) to certify RC1 is requested by EE. The certification may be generated, for example by CERT = H{N1,N2,Si}. A shared secret (Si) is generated from Si - 1 and K3 as follows: H: {Si-1,K3}→ Si. EE then sends RC1, CERT to GE as follows:
EEGE: ENC(K1, RC1, CERT, H{RC1, CERT, N2, N1})
GE can decrypt it and check the integrity of RC1 and CERT.

[0146] The gateway in turn sends the commands from the external entity to the target ECU. GE already knows N1 and N2. GE then looks up TID1 from ID1 with RC1. It is noted that GE knows RC1 and finds the in-vehicle message identifier (ID1) first, then finds a temporal identifier (TID1). GE generates UPDATE as follows: f1: (ID1,CERT,K2) → UPDATE, where f1 is a one-way function, f1: {a} → b, a is an input and b is the output from a. GE sends N1,N2, UPDATE in the same manner as described above for IA-CAN procedure. That is, GE → IE: N1,N2, UPDATE, where IE is the target ECU. IE receives UPDATE and generates CERT*. IE knows N1,N2 (just received) and Si. IE also knows Si and K3. It follows that the certification is generated by CERT* = H{N1,N2,Si}. IE now generates UPDATE* and compares to UPDATE which IE received, where F1: {id1, CERT*, K2} → UPDATE*. If UPDATEUPDATE*, then IE generates the new session key (which is updated k2), and sets the session counter to 0. MAX number of counter is preset. When the counter reaches to MAX, the session expires. If EE does not send new CERT to GE, GE has no more authority to send message to IE. AID generation and verification within the session is identical to IA-CAN.

[0147] When the attacker takes full control of the compromised gateway ECU, it results in complete failure in previous models. However, IA-CAN EXT limits the attacker's capability using the compromised gateway ECU only in session.

[0148] The techniques described herein may be implemented by one or more computer programs executed by one or more processors. The computer programs include processor-executable instructions that are stored on a non-transitory tangible computer readable medium. The computer programs may also include stored data. Non-limiting examples of the non-transitory tangible computer readable medium are nonvolatile memory, magnetic storage, and optical storage.

[0149] Some portions of the above description present the techniques described herein in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. These operations, while described functionally or logically, are understood to be implemented by computer programs. Furthermore, it has also proven convenient at times to refer to these arrangements of operations as modules or by functional names, without loss of generality. It is understood that grouping of operations within in a given module is not limiting and operations may be shared amongst multiple modules or combined into a single module.

[0150] Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic control unit, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[0151] Certain aspects of the described techniques include process steps and instructions described herein in the form of an algorithm. It should be noted that the described process steps and instructions could be embodied in software, firmware or hardware, and when embodied in software, could be downloaded to reside on and be operated from different platforms used by real time network operating systems.

[0152] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a controller selectively activated or reconfigured by a computer program stored on a computer readable medium that can be accessed by the computer. Such a computer program may be stored in a tangible computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

[0153] The algorithms and operations presented herein are not inherently related to any particular computer or other apparatus. Various electronic control units may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatuses to perform the required method steps. The required structure for a variety of these systems will be apparent to those of skill in the art, along with equivalent variations. In addition, the present disclosure is not described with reference to any particular programming language. It is appreciated that a variety of programming languages may be used to implement the teachings of the present disclosure as described herein.

[0154] The foregoing description of the embodiments has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure. Individual elements or features of a particular embodiment are generally not limited to that particular embodiment, but, where applicable, are interchangeable and can be used in a selected embodiment, even if not specifically shown or described. The same may also be varied in many ways. Such variations are not to be regarded as a departure from the disclosure, and all such modifications are intended to be included within the scope of the disclosure.


Claims

1. A computer-implemented method for authenticating data frames in a vehicle network, comprising:

storing, by a receiving electronic control unit, a cryptographic key, where the cryptographic key is shared with a sending electronic control unit;

receiving, by the receiving electronic control unit, a current frame identifier in a data frame sent via a serial data link by the sending electronic control unit, wherein the data frame does not include an identifier for the receiving electronic control unit;

generating, by the receiving electronic control unit, a next frame identifier in response to receiving the current frame identifier, where the next frame identifier is derived in part based on the received current frame identifier and the cryptographic key using an encoding function;

storing, by the receiving electronic control unit, the next frame identifier in a data store for subsequent processing;

receiving, by the receiving electronic control unit, another data frame subsequently to receiving the current frame identifier;

extracting, by the receiving electronic control unit, a frame identifier from the another data frame without decoding any portion of the another data frame;

comparing, by the receiving electronic control unit, the extracted frame identifier to the next frame identifier residing in the data store;

processing, by the receiving electronic control unit, payload of the another data frame when the extracted frame identifier matches the next frame identifier; and

discarding, by the receiving electronic control unit, the another data frame when the extracted frame identifier does not match the next frame identifier.


 
2. The method of claim 1 wherein generating a next frame identifier further comprises using a keyed-hash function.
 
3. The method of claim 1 further comprises generating, by the receiving electronic control unit, a new frame identifier when the extracted frame identifier matches the next frame identifier and replacing the next frame identifier in the data store with the new frame identifier, where the new frame identifier is derived in part from the extracted frame identifier and the cryptographic key using an encoding function.
 
4. The method of claim 1 further comprises extracting, by the receiving electronic control unit, a message authentication code from the another data frame and authenticating the payload of the another data frame using the message authentication code, where the message authentication code differs from the extracted frame identifier and is derived in part from the payload in the another date frame and the steps of extracting and authenticating occur when the extracted frame identifier matches the next frame identifier and prior to the step of processing the payload of the another data frame.
 
5. The method of claim 1 further comprises initiating a session between the sending electronic control unit and the receiving electronic control unit by

selecting, by the sending electronic control unit, a nonce;

selecting, by the sending electronic control unit, a hash function for key generation;

selecting, by the sending electronic control unit, a keyed hash function for message authentication;

generating, by the sending electronic control unit, a hash output by applying the selected keyed hash function to an identifier for the sending electronic control unit, the nonce, and the cryptographic key; and

sending, by the sending electronic control unit, an initiation data frame via the serial data link to the receiving electronic control unit, where the initiation data frame includes an identifier for the sending electronic control unit, the nonce, the hash value, an indicator for the hash function, an indicator for the keyed hash function and the hash output.


 
6. The method of claim 5 further comprising

receiving, by the receiving electronic control unit, the initiation data frame;

determining, by the receiving electronic control unit, the selected keyed hash function from the initiation data frame;

generating, by the receiving electronic control unit, a hash output by applying the selected keyed hash function to the identifier for the sending electronic control unit, the nonce, and the cryptographic key retrieved from the initiation data frame;

generating, by the receiving electronic control unit, a session key by applying the selected hash function to the nonce and the cryptographic key when the generated hash output matches the hash output retrieved from the initiation data frame.


 
7. The method of claim 1 wherein the serial data link is further defined as a controller area network.
 
8. The method of claim 1 wherein the serial data link is further defined as a Local Interconnect Network.
 
9. A system for authenticating data frames in a vehicle system, comprising:

a cryptographic key residing in a data store of a receiving electronic control unit, where the cryptographic key is shared with a sending electronic control unit;

a next frame identifier residing in a data store of the receiving electronic control unit;

a filter (61) configured to receive a data frame sent via a vehicle network by the sending electronic control unit, the filter extracts a frame identifier from the received data frame without decoding any portion of the data frame and compares the extracted frame identifier with the next frame identifier, wherein the data frame does not include an identifier for the receiving electronic control unit;

a message authenticator (63) configured to receive the data frame from the filter and process payload of the data frame when the extracted frame identifier matches the next frame identifier; and

an ID generator (64) configured to receive the extracted frame identifier and, when the extracted frame identifier matches the next frame identifier, generate a new frame identifier and replace the next frame identifier in the data store with the new frame identifier, where the new frame identifier is derived in part based on the extracted frame identifier and the cryptographic key using an encoding function.


 
10. The system of claim 9 wherein the filter discards the data frame when the extracted frame identifier does not match the next frame identifier.
 
11. The system of claim 9 wherein the message authenticator extracts a message authentication code from the data frame and authenticates payload of the data frame prior to processing the payload of the data frame, where the message authentication code differs from the extracted frame identifier and is derived in part from the payload in the another date frame.
 
12. The system of claim 11 wherein the message authenticator authenticates the payload of the data frame using a cyclic redundancy check.
 
13. The system of claim 9 wherein the vehicle network is further defined by a serial data bus residing in a vehicle.
 
14. The system of claim 9 wherein the data frame is communicated in accordance with the Controller Area Network.
 


Ansprüche

1. Computer-implementiertes Verfahren zur Authentifizierung von Datenrahmen in einem Fahrzeugnetzwerk, umfassend:

Speicherung eines kryptographischen Schlüssels durch eine empfangende elektronische Steuereinheit, wobei der kryptographische Schlüssel mit einer sendenden elektronischen Steuereinheit geteilt wird;

Empfangen, durch die empfangende elektronische Steuereinheit, eines aktuellen Rahmen-Identifikator in einem Datenrahmen, der über eine serielle Datenverbindung durch die sendende elektronische Steuereinheit gesendet wird, wobei der Datenrahmen keinen Identifikator für die empfangende elektronische Steuereinheit enthält;

Erzeugen, durch die empfangende elektronische Steuereinheit, eines nächsten Rahmen-Identifikators als Antwort auf den Empfang des aktuellen Rahmen-Identifikators, wobei der nächste Rahmen-Identifikator teilweise auf der Grundlage des empfangenen aktuellen Rahmen-Identifikators und des kryptographischen Schlüssels unter Verwendung einer Codierfunktion abgeleitet wird;

Speichern des nächsten Rahmen-Identifikators durch die empfangende elektronische Steuereinheit in einem Datenspeicher zur späteren Verarbeitung;

Empfangen eines weiteren Datenrahmens durch die empfangende elektronische Steuereinheit im Anschluss an den Empfang des aktuellen Rahmen-Identifikators;

Extrahieren eines Rahmen-Identifikators aus dem anderen Datenrahmen durch die empfangende elektronische Steuereinheit, ohne einen Teil des anderen Datenrahmens zu dekodieren;

Vergleichen des extrahierten Rahmen-Identifikators mit dem nächsten Rahmen-Identifikator, der sich im Datenspeicher befindet, durch die empfangende elektronische Steuereinheit;

Verarbeiten der Nutzlast des anderen Datenrahmens durch die empfangende elektronische Steuereinheit, wenn der extrahierte Rahmen-Identifikator mit dem nächsten Rahmen-Identifikator übereinstimmt; und

Verwerfen des anderen Datenrahmens durch die empfangende elektronische Steuereinheit, wenn der extrahierte Rahmen-Identifikator nicht mit dem nächsten Rahmen-Identifikator übereinstimmt.


 
2. Verfahren nach Anspruch 1, wobei das Erzeugen Erzeugung eines Identifikators des nächsten Rahmens ferner die Verwendung einer Keyed-Hash-Funktion umfasst.
 
3. Verfahren nach Anspruch 1, das ferner umfasst: Erzeugen eines neuen Rahmen-Identifikators durch die empfangende elektronische Steuereinheit, wenn der extrahierte Rahmen-Identifikator mit dem nächsten Rahmen-Identifikator übereinstimmt, und Ersetzen des nächsten Rahmen-Identifikators im Datenspeicher durch den neuen Rahmen-Identifikator, wobei der neue Rahmen-Identifikator teilweise aus dem extrahierten Rahmen-Identifikator und dem kryptographischen Schlüssel unter Verwendung einer Codierfunktion abgeleitet wird.
 
4. Verfahren nach Anspruch 1, das ferner umfasst: Extrahieren eines Nachrichten-Authentifizierungscodes aus dem anderen Datenrahmen durch die empfangende elektronische Steuereinheit und Authentifizieren der Nutzlast des anderen Datenrahmens unter Verwendung des Nachrichten-Authentifizierungscodes, wobei sich der Nachrichten-Authentifizierungscode von dem extrahierten Rahmen-Identifikator unterscheidet und teilweise von der Nutzlast in dem anderen Datenrahmen abgeleitet wird und die Schritte des Extrahierens und Authentifizierens erfolgen, wenn der extrahierte Rahmen-Identifikator mit dem nächsten Rahmen-Identifikator übereinstimmt und vor dem Schritt der Verarbeitung der Nutzlast des anderen Datenrahmens.
 
5. Verfahren nach Anspruch 1, das ferner umfasst: Einleiten einer Sitzung zwischen der sendenden elektronischen Steuereinheit und der empfangenden elektronischen Steuereinheit durch

Auswählen, durch die sendende elektronische Steuereinheit, einer Nonce;

Auswählen einer Hash-Funktion zur Schlüsselerzeugung durch die sendende elektronische Steuereinheit;

Auswählen einer Hash-Funktion für die Nachrichtenauthentifizierung durch die sendende elektronische Steuereinheit;

Erzeugen einer Hash-Ausgabe durch die sendende elektronische Steuereinheit durch Anwenden der ausgewählten verschlüsselten Hash-Funktion auf einen Identifikator für die sendende elektronische Steuereinheit, die Nonce und den kryptographischen Schlüssel; und

Senden, durch die sendende elektronische Steuereinheit, eines Initiierungs-Datenrahmens über die serielle Datenverbindung an die empfangende elektronische Steuereinheit, wobei der Initiierungs-Datenrahmen einen Identifikator für die sendende elektronische Steuereinheit, die Nonce, den Hash-Wert, einen Indikator für die Hash-Funktion, einen Indikator für die getastete Hash-Funktion und die Hash-Ausgabe enthält.


 
6. Verfahren nach Anspruch 5, das ferner umfasst:

Empfangen des Initiierungs-Datenrahmens durch die empfangende elektronische Steuereinheit;

Bestimmen der ausgewählten Hash-Funktion durch die empfangende elektronische Steuereinheit aus dem Initiierungs-Datenrahmen;

Erzeugen einer Hash-Ausgabe durch die empfangende elektronische Steuereinheit durch Anwenden der ausgewählten verschlüsselten Hash-Funktion auf den Identifikator für die sendende elektronische Steuereinheit, die Nonce und den kryptographischen Schlüssel, der aus dem Initiierungs-Datenrahmen abgerufen wurde;

Erzeugung eines Sitzungsschlüssels durch die empfangende elektronische Steuereinheit durch Anwendung der ausgewählten Hash-Funktion auf die Nonce und den kryptographischen Schlüssel, wenn die erzeugte Hash-Ausgabe mit der aus dem Initiierungsdatenrahmen abgerufenen Hash-Ausgabe übereinstimmt.


 
7. Verfahren nach Anspruch 1, wobei die serielle Datenverbindung weiter als ein Controller-Bereichsnetz definiert ist.
 
8. Verfahren nach Anspruch 1, wobei die serielle Datenverbindung weiter als lokales Verbindungsnetzwerk definiert ist.
 
9. System zur Authentifizierung von Datenrahmen in einem Fahrzeugsystem, umfassend:

einen kryptographischen Schlüssel, der sich in einem Datenspeicher einer empfangenden elektronischen Steuereinheit befindet, wobei der kryptographische Schlüssel mit einer sendenden elektronischen Steuereinheit geteilt wird;

einen nächsten Rahmen-Identifikator, der sich in einem Datenspeicher der empfangenden elektronischen Steuereinheit befindet;

einen Filter (61), der so konfiguriert ist, dass er einen von der sendenden elektronischen Steuereinheit über ein Fahrzeugnetz gesendeten Datenrahmen empfängt, wobei der Filter einen Rahmen-Identifikator aus dem empfangenen Datenrahmen extrahiert, ohne irgendeinen Teil des Datenrahmens zu dekodieren, und der extrahierte Rahmen-Identifikator mit dem nächsten Rahmen-Identifikator vergleicht, wobei der Datenrahmen keinen Identifikator für die empfangende elektronische Steuereinheit enthält;

eine Nachrichten-Authentifizierungseinrichtung (63), die so konfiguriert ist, dass sie den Datenrahmen von dem Filter empfängt und die Nutzlast des Datenrahmens verarbeitet, wenn der extrahierte Rahmen-Identifikator mit dem nächsten Rahmen-Identifikator übereinstimmt; und

einen ID-Generator (64), der so konfiguriert ist, dass er den extrahierten Rahmen-Identifikator empfängt und, wenn der extrahierte Rahmen-Identifikator mit dem nächsten Rahmen-Identifikator übereinstimmt, einen neuen Rahmen-Identifikator erzeugt und den nächsten Rahmen-Identifikator in dem Datenspeicher durch den neuen Rahmen-Identifikator ersetzt, wobei der neue Rahmen-Identifikator teilweise auf der Grundlage des extrahierten Rahmen-Identifikator und des kryptographischen Schlüssels unter Verwendung einer Codierfunktion abgeleitet wird.


 
10. System nach Anspruch 9, wobei der Filter den Datenrahmen verwirft, wenn der extrahierte Rahmen-Identifikator nicht mit dem nächsten Rahmen-Identifikator übereinstimmt.
 
11. System nach Anspruch 9, wobei der Nachrichten-Authentifizierer einen Nachrichten-Authentifizierungscode aus dem Datenrahmen extrahiert und die Nutzlast des Datenrahmens vor der Verarbeitung der Nutzlast des Datenrahmens authentifiziert, wobei sich der Nachrichten-Authentifizierungscode von dem extrahierten Rahmen-Identifikator unterscheidet und zum Teil von der Nutzlast in dem anderen Datenrahmen abgeleitet wird.
 
12. System nach Anspruch 11, wobei der Nachrichten-Authentifikator die Nutzlast des Datenrahmens unter Verwendung einer zyklischen Redundanzprüfung authentifiziert.
 
13. System nach Anspruch 9, wobei das Fahrzeugnetzwerk weiter durch einen in einem Fahrzeug befindlichen seriellen Datenbus definiert ist.
 
14. System nach Anspruch 9, wobei der Datenrahmen in Übereinstimmung mit dem Controller-Bereichsnetzwerk kommuniziert wird.
 


Revendications

1. Procédé informatique permettant d'authentifier des trames de données dans un réseau de véhicule, comprenant :

le stockage, par une unité de commande électronique de réception, d'une clé cryptographique, la clé cryptographique étant partagée avec une unité de commande électronique d'envoi ;

la réception, par l'unité de commande électronique de réception, d'un identificateur de trame courante envoyé par l'intermédiaire d'une liaison de données série, la trame de données ne comprenant pas un identificateur pour l'unité de commande électronique de réception ;

la génération, par l'unité de commande électronique de réception, d'un identificateur de trame suivante en réponse à la réception de l'identificateur de trame courante, l'identificateur de trame suivante étant dérivé en partie sur la base de l'identificateur de trame courante reçue et de la clé cryptographique en utilisant une fonction de codage ;

le stockage, par l'unité de commande électronique de réception, de l'identificateur de trame suivante dans une mémoire de données en vue d'un traitement ultérieur ;

la réception, par l'unité de commande électronique de réception, d'une autre trame de données suite à la réception de l'identificateur de trame courante ;

l'extraction, par l'unité de commande électronique de réception, d'un identificateur de trame à partir de l'autre trame de données sans décoder une partie quelconque de l'autre trame de données ;

la comparaison, par l'unité de commande électronique de réception, de l'identificateur de trame extrait avec l'identificateur de trame suivante résidant dans la mémoire de données ;

le traitement, par l'unité de commande électronique de réception, de la charge utile de l'autre trame de données lorsque l'identificateur de trame extrait correspond à l'identificateur de trame suivante ; et

le rejet, par l'unité de commande électronique de réception, de l'autre trame de données lorsque l'identificateur de trame extrait ne correspond pas à l'identificateur de trame suivante.


 
2. Procédé selon la revendication 1, la génération d'un identificateur de trame suivante comprenant en outre l'utilisation d'une fonction de hachage à clé.
 
3. Procédé selon la revendication 1 comprenant en outre la génération, par l'unité de commande électronique de réception, d'un nouvel identificateur de trame lorsque l'identificateur de trame extrait correspond à l'identificateur de trame suivante et le remplacement de l'identificateur de trame suivante dans la mémoire de données par le nouvel identificateur de trame, le nouvel identificateur de trame étant dérivé en partie à partir de l'identificateur de trame extrait et de la clé cryptographique en utilisant une fonction de codage.
 
4. Procédé selon la revendication 1 comprenant en outre l'extraction, par l'unité de commande électronique de réception, d'un code d'authentification de message à partir de l'autre trame de données et l'authentification de la charge utile de l'autre trame de données en utilisant le code d'authentification de message, le code d'authentification de message différant de l'identificateur de trame extrait et étant dérivé en partie à partir de la charge utile de l'autre trame de données, et les étapes d'extraction et d'authentification ayant lieu lorsque l'identificateur de trame extrait correspond à l'identificateur de trame suivante et avant l'étape de traitement de la charge utile de l'autre trame de données.
 
5. Procédé selon la revendication 1, comprenant en outre l'initiation d'une session entre l'unité de commande électronique d'envoi et l'unité de commande électronique de réception par :

la sélection, par l'unité de commande électronique d'envoi, d'un nonce ;

la sélection, par l'unité de commande électronique d'envoi, d'une fonction de hachage pour la génération de clé ;

la sélection, par l'unité de commande électronique d'envoi, d'une fonction de hachage à clé pour l'authentification de message ;

la génération, par l'unité de commande électronique d'envoi, d'une sortie de hachage en appliquant la fonction de hachage à clé sélectionnée à un identificateur pour l'unité de commande électronique d'envoi, le nonce et la clé cryptographique ; et

l'envoi, par l'unité de commande électronique d'envoi, d'une trame de données d'initiation par la liaison de données série à l'unité de commande électronique de réception, la trame de données d'initiation comprenant un identificateur pour l'unité de commande électronique d'envoi, le nonce, la valeur de hachage, un indicateur pour la fonction de hachage, un indicateur pour la fonction de hachage à clé et la sortie de hachage.


 
6. Procédé selon la revendication 5, comprenant en outre :

la réception, par l'unité de commande électronique de réception, de la trame de données d'initiation ;

la détermination, par l'unité de commande électronique de réception, de la fonction de hachage à clé sélectionnée à partir de la trame de données d'initiation ;

la génération, par l'unité de commande électronique de réception, d'une sortie de hachage en appliquant la fonction de hachage à clé sélectionnée à l'identificateur de l'unité de commande électronique d'envoi, au nonce et à la clé cryptographique récupérée à partir de la trame de données d'initiation ;

la génération, par l'unité de commande électronique de réception, d'une clé de session en appliquant la fonction de hachage sélectionnée au nonce et à la clé cryptographique lorsque la sortie de hachage générée correspond à la sortie de hachage récupérée à partir de la trame de données d'initiation.


 
7. Procédé selon la revendication 1, la liaison de données série étant en outre définie comme un réseau de zones de dispositifs de commande.
 
8. Procédé selon la revendication 1, la liaison de données série étant en outre définie comme un réseau d'interconnexion local.
 
9. Système pour authentifier des trames de données dans un système de véhicule, comprenant :

une clé cryptographique résidant dans une mémoire de données d'une unité de commande électronique de réception, la clé cryptographique étant partagée avec une unité de commande électronique d'envoi ;

un identificateur de trame suivante résidant dans une mémoire de données de l'unité de commande électronique de réception ;

un filtre (61) configuré pour recevoir une trame de données envoyée par l'intermédiaire d'un réseau de véhicule par l'unité de commande électronique d'envoi, le filtre extrait un identificateur de trame à partir de la trame de données reçue sans décoder une partie quelconque de la trame de données et compare l'identificateur de trame extrait à l'identificateur de trame suivante, la trame de données ne comprenant pas un identificateur pour l'unité de commande électronique de réception ;

un authentificateur de message (63) configuré pour recevoir la trame de données à partir du filtre et traiter la charge utile de la trame de données lorsque l'identificateur de trame extrait correspond à l'identificateur de trame suivante ; et

un générateur d'ID (64) configuré pour recevoir l'identificateur de trame extrait et, lorsque l'identificateur de trame extrait correspond à l'identificateur de trame suivante, générer un nouvel identificateur de trame et remplacer l'identificateur de trame suivante dans la mémoire de données par le nouvel identificateur de trame, le nouvel identificateur de trame étant dérivé en partie sur la base de l'identificateur de trame extrait et de la clé cryptographique en utilisant une fonction de codage.


 
10. Système selon la revendication 9, le filtre rejetant la trame de données lorsque l'identificateur de trame extrait ne correspond pas à l'identificateur de trame suivante.
 
11. Système selon la revendication 9, l'authentificateur de message extrayant un code d'authentification de message à partir de la trame de données et authentifiant la charge utile de la trame de données avant de traiter la charge utile de la trame de données, le code d'authentification de message différant de l'identificateur de trame extrait et étant dérivé en partie à partir de la charge utile dans l'autre trame de données.
 
12. Système selon la revendication 11, l'authentificateur de message authentifiant la charge utile de la trame de données en utilisant un contrôle de redondance cyclique.
 
13. Système selon la revendication 9, le réseau de véhicule étant en outre défini par un bus de données série résidant dans un véhicule.
 
14. Système selon la revendication 9, la trame de données étant communiquée conformément au réseau de zones de dispositifs de commande.
 




Drawing









































Cited references

REFERENCES CITED IN THE DESCRIPTION



This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

Patent documents cited in the description




Non-patent literature cited in the description