Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/12—Applying verification of the received information
  • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
  • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
  • H04L63/1441—Countermeasures against malicious traffic
  • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks

Definitions

• Systems which utilize processors that rely on a proprietary communication protocol / communication bus are often limited in that they have little or no message security in the communication protocol / communication bus. Additionally, such messages are often limited in the size of the message payload. As such, adding a digital signature or a message counter to the message payload might contribute to message security, however, that contribution comes at the cost of reducing the size available for the message payload itself.
• a system is needed which will enable securing such messages while not consuming excessive bandwidth. This is particularly true but not limited to the realm of automotive systems, as well as buses, tanks, airplanes, etc. It is also appreciated that these systems may be either manned or unmanned.
• ECU electronice control units
• a modern automobile may have as many as 70 or 80 ECUs for various subsystems - providing for control of the automobile's engine; transmission; airbags; antilock braking; electrical system; power steering; audio systems; windows; doors; mirror adjustment; battery and recharging systems for hybrid/electric cars; and so forth. While some of these subsystems might be independent of others, communications between others of these subsystems may be essential to proper functioning of the automobile. For instance, and without limiting the generality of the foregoing, it is apparent that the engine controlling ECU must communicate with the transmission.
• Controller Area Network is a bus standard used in many vehicles, which is designed to allow microcontrollers and devices, such as, but not limited to the above-mentioned ECUs, to communicate with one another, without a host computer.
• CAN is a low-level protocol, and does not support any security features intrinsically. Applications are expected to deploy their own security mechanisms; for instance, and without limiting the generality of the foregoing, to authenticate each other. Failure to do so may result in various sorts of attacks, if an opponent manages to insert messages on the bus.
• One attack which might be implemented on the CAN bus (or any other bus which is not secured against such attacks) would be a replay attack, where messages sent over the bus are intercepted and replayed, thereby causing a recipient of the message to repeat an instruction in the replayed message.
• the present invention in certain embodiments thereof, seeks to provide an improved method and system for counter-measures against replay attacks on the CAN bus.
• a method for securely sending a message including receiving a nonce, storing the received nonce, preparing a message payload, appending the stored nonce to the message payload, classifying the message with a message-type, appending a message-type message counter to the appended message payload and the nonce, the message-type message counter including one of an incremented counter of messages of the message-type, and a base value, if no messages of the message-type have been either sent or received during a messaging session, signing the message payload, and appended nonce and appended message-type message counter, thereby producing a signature, appending the message payload, a plurality of the least significant bits of the message-type message counter, and the signature, thereby producing a data field for a data frame, sending the data frame including the data field.
• the signature includes one of a public key signature, and a message authentication code (MAC).
• MAC message authentication code
• a message destination address is inserted into a header of the message.
• the nonce includes one of a random and a pseudorandom number.
• the most significant bits of the message-type message counter include one of a random and a pseudorandom number.
• the method is executed in an automobile.
• the method is executed in a bus. Additionally in accordance with an embodiment of the present invention the method is executed in a tank.
• the method is executed in an airplane.
• the method is executed in one of a ship or a submarine.
• the method is executed in an unmanned vehicle.
• a system for securely sending a message including a communication module for receiving a nonce, a memory which stores the received nonce, a processor which prepares a message payload, and appends the stored nonce to the message payload, the processor further classifies the message with a message-type and appends a message-type message counter to the appended message payload and the nonce, the message -type message counter including one of an incremented counter of messages of the message-type, and a base value, if no messages of the message-type have been either sent or received during a messaging session, a cryptographic apparatus which signs the message payload, and appended nonce and appended message -type message counter, thereby producing a signature, the processer appends the message payload, a plurality of the least significant bits of the message-type message counter, and the signature, thereby producing a data field for a data frame which is sent by the communication module, the data frame including the data field.
• Fig. 1 is a simplified pictorial illustration of a plurality of microcontrollers disposed throughout an automobile and in communication with one another constructed and operative in accordance with an embodiment of the present invention
• Fig. 2 is a depiction of a startup condition within the system of Fig. 1;
• Fig. 3 is a depiction of a message payload ready to be digitally signed in the system of Fig. 1 ;
• Fig. 4 is a depiction of a message payload being sent from one microcontroller to a second microcontroller in the system of Fig. 1 ;
• Fig. 5 is a simplified block diagram of an exemplary ECU for use in the system of Fig. 1;
• Fig. 6 is a simplified flowchart diagram of methods of operation of the system of Fig. 1.
• Fig. 1 is a simplified pictorial illustration of a plurality of microcontrollers 110a - 1 lOf disposed throughout an automobile 120and in communication with one another constructed and operative in accordance with an embodiment of the present invention.
• the microcontrollers 110a - 1 lOf are electronic control units (ECU) 110a - 1 lOf.
• ECUs 110a - 11 Of may be used to control a variety of units in automobiles 120.
• other microcontrollers and engine management systems are also known in the art.
• the embodiments of the present invention described herein are described referring to ECUs 110a - 11 Of and automotive systems by way of example. It is appreciated that the alternative embodiments of the present invention may be operative with buses, tanks, airplanes, etc. Other systems which rely on a proprietary communication protocol / communication bus and have limited message payload size may also benefit from an implementation of embodiments of the present invention.
• the controller area network (CAN) bus is one example of a well-known communications bus used in automotive systems.
• Other communications buses, such as FlexCAN, Local Interconnect Network, and FlexRay are also known in the art.
• FlexCAN FlexCAN
• FlexRay Local Interconnect Network
• the present specification refers to ECUs and the CAN bus, such references are by way of example only, and are not meant to be limiting. Note that one or more networks of the same type or of differing types may be in any one vehicle.
• a CAN network is typically configured to support messages
• data frames in one of two different formats: base frame format and extended frame format.
• the message payload in the data frame regardless of whether the frame format is the basic format or the extended format, is limited to an eight byte (i.e., 64 bit) data field.
• An additional 15 bits are provided for a cyclic redundancy check (CRC), in order to verify that data is error free.
• CRC cyclic redundancy check
• the CAN protocol does not intrinsically support any security features. As a result, the protocol is subject to various attacks, such as a replay attack. Adding a message counter to the message payload coupled with message signatures is well-known method of protecting messages against replay attacks.
• adding a message counter to the message payload uses bits and bytes which are then no longer available for the actual message payload.
• the method described below enables using fewer than the full message counter while still maintaining message security.
• Fig. 2 is a depiction of a startup condition within the system of Fig. 1.
• one ECU 110a (by way of example) on the CAN communications bus sends out a nonce 210 (i.e. an arbitrary and typically a random or a pseudo-random number used only once).
• the nonce 210 would be sent over the communication bus (i.e. the CAN bus) once when the car engine is started.
• the nonce 210 is stored by ECUs 110a - HOf (not all depicted) which receive it.
• Fig. 3 is a depiction of a message payload 310 ready to be digitally signed in the system of Fig. 1. It is appreciated that the order of fields for signing (i.e., message payload 310, nonce 210, counter 320) does not matter. Any order is acceptable.
• the sending ECU 1 lOd prepares the message 310, and appends to the message 310 the stored nonce 210 and a counter 320.
• the counter 320 is appended as a method of securing the system against replay attacks. It is inherent that the counter can be viewed as a concatenation of two groups of bits: most significant bits (MSB) 330 and least significant bits (LSB) 340.
• each message has a different message type.
• each message has a single ECU 110a - 11 Of that generates that particular message, and several ECUs 110a - 11 Of that need to receive and act upon that message.
• ECU 110a - 11 Of that For example and without limiting the generality of the foregoing:
• the engine-ECU sends a message conveying the current engine rotation speed intended for the transmission-ECU, the chassis-ECU and the brakes-ECU;
• the dashboard-ECU sends a message conveying the current status of the dashboard buttons intended for the windshield wipers-ECU and the lights-ECUs.
• messages type is defined for the purpose of this specification and claims as an indication of the originator of the message, the occurrence being conveyed by that message, and the intended recipient(s) of the message.
• the intended recipient i.e. the message destination
• Other communication protocols do not support indicating the intended recipient in a destination field in the message header.
• the message counter LSB 340 begins at a base value, typically zero or one, but the MSB 330 will be a random or pseudorandom number. Alternatively, in that the nonce 210 is a random value added to the signature, the MSB 330 may also begin at some base value. At this point, per each message type, the message originator and all the message recipients store the full counter value, and it is synchronized between all of them.
• MSB 330 will be a random or pseudorandom number that the message originator of any given type of message type will determine randomly or pseudorandomly and inform potential recipients of the MSB 330.
• the counter value is first incremented by the originator of the message, and then the LSB 340 of the new counter value is appended to the message to be sent, along with the signature.
• the LSB 340 of the counter in the received message are used by the recipient of the message, to reconstruct the full counter value and verify the signature. If the LSB 340 of the counter in the received message is greater than the stored LSB 340, then the stored LSB 340 counter value is updated to match the new, received, LSB 340 counter value. If the LSB 340 of the counter in the received message is smaller than or equal to the stored LSB 340, then the recipient first increments the MSB 330 of its stored counter, and then updates the LSB 340 of its stored counter to match the new, received, LSB 340 counter value. Then the updated, stored, full counter value is used for verifying the message signature. It is appreciated that the both LSB 340 and MSB 330 values of the counter may only be updated upon successful validation of the message.
• Fig. 4 is a depiction of a message payload being sent from one microcontroller 410 to a second microcontroller 420 in the system of Fig. 1.
• the message 310 with the appended nonce 210 and counter 320 is digitally signed by a digital signing unit 430.
• the digital signature 440 may comprise one of signing with a public key signature scheme or a message authentication code (MAC).
• MAC message authentication code
• the message payload 450 i.e. the data field of the data frame
• the message payload 450 comprises the message 310 itself, the LSB 340 of the message counter 320, and the signature 440 on the nonce 210, message 310 and the full counter value 320.
• the message payload 450 is inserted in the CAN data frame as the data field. It is appreciated that when the number of bits in the signature begins to significantly impinge on the number of bits remaining for the message payload, the signature 440 (or part of it) can be moved to a different packet. A transport layer protocol should be employed to ensure that the message and its signature arrive together at their destination.
• the recipient ECU 420 updates its stored copy of the message counter 320 as described above.
• the signature 440 can then be verified as follows: the nonce 210 and the updated, stored full message counter 320 are retrieved from storage and appended to the received message 310 so that the various sections of: message 310; nonce 210; MSB 330; and LSB 340 are arranged in the order in which they were signed by the signing unit 430.
• the rearranged message 310; nonce 210; MSB 330; and LSB 340 are then cryptographically hashed by the receiving ECU 420, and the message signature 440 is verified against this newly generated hash result. Assuming that the signature verification passed, the message 310 is considered legitimate, and the receiving ECU 420 continues to process the message 310 according to the ordinary message processing procedures, as is known in the art.
• Fig. 5 is a simplified block diagram of an exemplary ECU 500 for use in the system of Fig. 1.
• Fig. 5 is a high-level block diagram not intended to show either standard features of ECUs which, for ease of depiction do not appear, nor is specialized hardware, such as, and without limiting the generality of the foregoing, variable valve timing controllers, transmission system controllers, or anti-theft system controllers, depicted.
• Fig. 5 describes a minimal configuration of an ECU 500 for implementation of the present invention.
• a communications module 510 is operative to receive the nonce.
• the nonce is sent by the communications module 510 to a processor (CPU) 520.
• the CPU 520 sends the nonce to an appropriate memory / storage module 530.
• the CPU 520 (or other specialized processor unit which is not depicted in Fig. 5) prepares an outgoing message payload.
• the CPU 520 (or other specialized processor unit which is not depicted in Fig. 5) then appends stored nonce (which has been retrieved from the memory / storage module 530) to the message payload, and classifies the message with a message-type.
• the CPU 520 (or other specialized processor unit which is not depicted in Fig.
• the CPU 520 (or other specialized processor unit which is not depicted in Fig. 5) then sends the message payload, the appended nonce, and the appended message-type message counter to a cryptographic apparatus 540 which is operative to produce a signature for the message.
• the signature for the message is then sent to the CPU 520 (or other specialized processor unit which is not depicted in Fig. 5) which then appends:
• the CPU 520 (or other specialized processor unit which is not depicted in Fig. 5) then sends the data field for the data frame to the communications module 510 for sending.
• the CPU 520 may be a single processing unit or a plurality of processing units or other appropriate hardware known in the art which are able to perform the above mentioned tasks.
• the memory / storage module 530 may comprise any or all of EEPROM, flash memory, or magnetic storage media, as is known in the art.
• Fig. 6 is a simplified flowchart diagram of preferred methods of operation of the system of Fig. 1. The method of Fig. 6 is believed to be self-explanatory in light of the above discussion.
• software components of the present invention may, if desired, be implemented in ROM (read only memory) form.
• the software components may, generally, be implemented in hardware, if desired, using conventional techniques.
• the software components may be instantiated, for example: as a computer program product; on a tangible medium; or as a signal interpretable by an appropriate computer. It is appreciated that various features of the invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Power Engineering (AREA)
• Small-Scale Networks (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=48182951

Family Applications (1)

Country Status (1)

Cited By (24)

Citations (2)

• 2013
  • 2013-02-13 WO PCT/IB2013/051167 patent/WO2013128317A1/fr not_active Ceased

Patent Citations (2)

Non-Patent Citations (3)

Similar Documents

Legal Events