WO2021168037A1 - Authenticating devices over a public communication network - Google Patents

Authenticating devices over a public communication network Download PDF

Info

Publication number
WO2021168037A1
WO2021168037A1 PCT/US2021/018457 US2021018457W WO2021168037A1 WO 2021168037 A1 WO2021168037 A1 WO 2021168037A1 US 2021018457 W US2021018457 W US 2021018457W WO 2021168037 A1 WO2021168037 A1 WO 2021168037A1
Authority
WO
WIPO (PCT)
Prior art keywords
hmac
vehicle device
vehicle
random number
actual
Prior art date
Application number
PCT/US2021/018457
Other languages
English (en)
French (fr)
Inventor
William A. BURGIN
Liam James GARSTANG
Original Assignee
Bae Systems Controls Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bae Systems Controls Inc. filed Critical Bae Systems Controls Inc.
Priority to EP21757129.8A priority Critical patent/EP4107038B1/de
Priority to US17/282,887 priority patent/US11303455B2/en
Priority to CA3172759A priority patent/CA3172759C/en
Publication of WO2021168037A1 publication Critical patent/WO2021168037A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3236Cryptographic 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/3242Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3271Cryptographic 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 challenge-response
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10Integrity
    • H04W12/108Source integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40208Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215Controller Area Network CAN
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40267Bus for use in transportation systems
    • H04L2012/40273Bus for use in transportation systems the transportation system being a vehicle
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84Vehicles
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04SSYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y04S40/20Information technology specific aspects, e.g. CAD, simulation, modelling, system security

Definitions

  • This disclosure relates generally to authenticating devices such as removable devices which use a communication bus.
  • a system may comprise multiple devices. These devices may be removable and replaced with after- market parts or replaced with inferior components. Additionally, the devices may be upgraded with newer components. Further, the devices may be tampered with.
  • the devices may be connected to a public communication network. When non-authenticated devices are connected to the public communication network, the operation of the system may be compromised.
  • a system may be part of a vehicle (an example of a system).
  • the vehicle may employ microprocessors or a processor in each device, each having program(s) that allow the vehicle to operate.
  • Each device may have a role or function within the vehicle or collectively have a function within the vehicle.
  • data may be exchanged between the devices via a vehicle communication network (communication bus).
  • vehicle communication network communication bus
  • the data and messages sent over the communication bus are typically unprotected and vulnerable and can be intercepted and read. This also allows for corruption of the messages and data and a lack of security for the devices responsible for operating the vehicle.
  • an apparatus, method and a computer program product for authenticating devices and causing at least one operation of a system to be inhibited or restricted.
  • an apparatus comprising a storage storing a key associated with an vehicle device and a processor.
  • the processor is configured to generate a random number, send the random number to the vehicle device via a vehicle communication network and receive an actual hash message authentication code (HMAC) from the vehicle device via the vehicle communication network.
  • HMAC hash message authentication code
  • the vehicle device determines the actual HMAC using a HMAC algorithm on an input and the key stored in a storage of the vehicle device.
  • the input is determined by the vehicle device using a hash function on the random number.
  • the processor is further configured to determine an expected hash message authentication code (HMAC) for the vehicle device using the HMAC algorithm on an input and the key stored in the storage.
  • HMAC hash message authentication code
  • the input is determined by the apparatus using the hash function on the random number. The determination may be after sending the random number or in response to receipt of the actual HMAC.
  • the processor is further configured to compare the actual HMAC with the expected HMAC, determine that the vehicle device fails authentication when the actual HMAC does not match the expected HMAC and cause at least one vehicle operation to be inhibited when the vehicle device fails authentication for a preset number of times while the vehicle device is connected to the vehicle communication network.
  • the vehicle device may be authenticated when the actual HMAC matches the expected HMAC.
  • the processor may control the vehicle operation based on signals received from interfaces without inhibiting any operations.
  • the processor may set a timer when the random number is sent to the vehicle device.
  • the timer may be set to a time where the apparatus must receive the actual HMAC from the vehicle device.
  • the processor may determine that the vehicle device fails authentication when the actual HMAC is not received within the time set on the timer.
  • the vehicle device may be an energy storage system (ESS).
  • the ESS may comprise energy cells, a processor and contactors.
  • the processor may transmit a command to the ESS (processor in the ESS) to maintain the contacts open to isolate the energy cells from a DC voltage bus.
  • the apparatus may authentication multiple devices.
  • the storage may store a plurality of keys associated with a plurality of vehicle devices, respectively.
  • the vehicle device may be a propulsion control system, a accessory power supply and/or an EV charger controller.
  • the processor may count the number of attempts for authentication or number of retries and compare with a preset number of times. When the counted number of times is less than a preset number of times, the processor may generate a new random number and send the same to the same vehicle device and attempt authentication again.
  • the method comprises generating a random number from a master, sending the random number from the master unit to at least one vehicle device, receiving an actual hash message authentication code (HMAC) from the at least one vehicle device via the vehicle communication network, processing at the master an expected hash message authentication code (HMAC) for each of the at least one vehicle device using the HMAC algorithm on an input and a stored key associated with each of the at least one vehicle device, comparing the actual HMAC to the expected HMAC in the master for each of the at least one vehicle device, and authenticating the at least one vehicle device if the actual HMAC matches the expected HMAC, and failing authentication if the actual HMAC does not match the expected HMAC.
  • the method further comprises controlling certain vehicle operations upon authentication based on input received from interfaces; and causing at least one vehicle operation to be inhibited upon failing authentication for a preset number of times while the vehicle device is connected to the vehicle communication network.
  • each vehicle device determines the actual HMAC using a HMAC algorithm on an input and a key stored in the respective vehicle device.
  • T input is determined by each vehicle device using a hash function on the random number.
  • the master determines the input for each vehicle device, respectively, using the hash function on the respect random number. A different key is stored in association with each vehicle device.
  • the preset number of times may be 1. In other aspects, the preset number of times may be greater than 1.
  • the master may be a system control unit (SCU) of a hybrid electric vehicle or an electric vehicle.
  • SCU system control unit
  • the at least one vehicle operation is an operation associated with a vehicle device that failed authentication for the preset number of times.
  • the vehicle operation(s) may comprise high voltage, high, current, high power, navigation, range and/or duration.
  • the vehicle device when the vehicle device is an energy storage system (ESS), the ESS may be isolated from a DC voltage bus.
  • ESS energy storage system
  • a different random number may be generated and used for different vehicle devices.
  • the hash function may be SHA3-256.
  • the actual HMAC may be truncated or padded to a 64 bit size.
  • the random number may be generated by a pseudorandom number generator (PRNG) or a cryptographically secure random number generator (CSRNG).
  • PRNG pseudorandom number generator
  • CSRNG cryptographically secure random number generator
  • the method may further comprise setting at least one timer when the random number is sent to each vehicle device, respectively.
  • the set time is a time where the master must receive the actual HMAC from a vehicle device.
  • the time may be different for different vehicle devices.
  • the time may be 500 ms. In other aspects, the time may be 1 second.
  • the master may determine that an attempted authentication fails for a vehicle device when the time expires without receipt of the actual HMAC from the vehicle device.
  • the method may further comprise counting a number of times authentication has failed per vehicle device; and comparing the counted number of times with the preset number of times.
  • the authentication process may be repeated with a new random number when the counted number of times is less than the preset number of times.
  • a computer program product including one or more non-transitory machine-readable media having instructions encoded thereon that, when executed by a processor, cause the processor to authenticate onboard processors over a vehicle communication network.
  • FIG. 1 is a diagrammatic overview of an authentication process in accordance with aspects of the disclosure
  • FIG. 2 is a diagram showing certain components of a vehicle in accordance with aspects of the disclosure.
  • FIG. 3 is a diagram of a master in accordance with aspects of the disclosure.
  • Fig. 4 is a diagram of a slave in accordance with aspects of the disclosure.
  • FIG. 5 is a diagrammatic overview showing how a Hash message authentication code is generated, in accordance with aspects of the disclosure;
  • Fig. 6 and Fig. 7 are flow charts depicting a method of authentication in accordance with aspects of the disclosure;
  • Fig. 8 is a flow chart depicting an example of authentication of an energy storage system in accordance with aspects of the disclosure.
  • FIG. 9 is a diagram of an energy storage system in accordance with aspects of the disclosure.
  • Fig. 10 is an example of a table in the volatile memory showing the association between a slave, random number, timer and counter in accordance with aspect of the disclosure
  • Fig. 11 A is a diagram showing an example of a message frame from a master to a slave(s).
  • Fig. 1 IB is a diagram showing an example of a message frame from a slave(s) to a master.
  • FIG. 1 is a diagrammatic overview of an authentication system in accordance with aspects of the disclosure.
  • the authentication system may be used in any system where devices are connected to a public network.
  • the authentication system may be included in a vehicle.
  • vehicle(s) refers to any land based items such as cars, trucks, buses, tanks and the like.
  • Vehicle(s) also includes airborne vehicles such as UAVs, planes and helicopters.
  • vehicle(s) also includes water based vehicles such as amphibious vehicles, ships, UUVs and submarines.
  • the vehicle may be a combustion vehicle, a hybrid vehicle or an electric vehicle.
  • the authentication system has a master-slave configuration.
  • the master 100 is responsible for authenticating the slaves 102, 104.
  • the slaves are identified as Slave 0 though Slave n, e.g., a plurality of slaves with a master 100.
  • N can be one or more.
  • a slave may also be an additional master.
  • the master 100 has a copy of keys 110 issued to all of the slaves 102, 104.
  • the set of keys is identified in Fig. 1 as ⁇ K n ⁇ .
  • Each individual slave has a unique key.
  • the keys 110 may be programmed or loaded into the master 100 when the system is configured. For example, the keys 110 may be incorporated in firmware.
  • the unique key in each slave 102, 104 may be programmed or loaded into the slave 102, 104 also when the system is configured. If there is a need to replace or change one of the slaves, in an aspect of the disclosure, a new key may loaded or programmed into both the master 100 and the slave that is new. In other aspects of the disclosure, a key may be unique to a type of slave as opposed to a specific slave such that when the same type of slave is replaced, a new key need not be assigned. For example, the same key may be used for a particle model of ESS 205. In an aspect of the disclosure, the keys may be loaded by an authorized user. In an aspect of the disclosure, the keys may also be periodically changed.
  • the key for slave 0 102 is identified as Ko 106.
  • the key for slave n 104 is identified as K n 108.
  • the master 100 may also be responsible for controlling functions of the system (e.g., vehicle) and the respective slaves 102, 104 (in addition to authentication).
  • the master 100 and slaves 102, 104 may be line replaceable units (LRUs).
  • the public network may support broadcast messaging where the master 100 sends one a message (transmission) to all of the slaves 102, 104. Each slave 102, 104 sends message(s). The messages may be heard by other slaves as well as the master 100.
  • Fig. 2 is a diagram showing certain components of a vehicle such as a hybrid or an electric vehicle in accordance with aspects of the disclosure.
  • Fig. 2 shows a system control unit (SCU) 200 (example of master) and an energy storage system (ESS) 205, propulsion control system (PCS) 210 and accessory power supply (APS) 215 (examples of slaves) and a vehicle communication network 220 (example of a public network).
  • the vehicle communication network 220 may be implemented as a control area network (CAN).
  • CAN is a common communication protocol used across various industries. However, CAN is both non-encrypted and public. Therefore, data and messages sent over this network are unprotected and vulnerable.
  • the ESS 205 provides a direct current (DC) electrical power to a DC link.
  • the DC link may be a high voltage DC link.
  • High voltage used herein means a voltage above 50V.
  • a block diagram of the ESS 205 is shown in Fig. 9.
  • the ESS 205 may include lithium ion batteries (cells 1050). In an aspect of the disclosure, the nominal voltage of DC link is above 600V.
  • the DC link is a high voltage.
  • the ESS 205 may provide power to a transmission to move the vehicle.
  • the ESS 205 may also be recharged (regenerative energy recovered from the drivetrain).
  • the ESS 205 may also alternatively include ultra-capacitors, lead-acid batteries, and other energy storage mediums.
  • the ultra-capacitor may include an electric double-layer capacitor (EDLC), also known as a, supercapacitor, supercondenser, or an electrochemical double layer capacitor, which has an electrochemical capacitor with relatively high energy density.
  • EDLC electric double-layer capacitor
  • the ESS 205 may also have contactors 1060.
  • the contactors 1060 is/are positioned to isolate or electrically couple the ESS 205 from/to the DC link.
  • the contactors 1060 may be external to the ESS 205.
  • the contactors 1060 may in incorporated into the PCS 210.
  • the contactors 1060 enable the voltage of the DC link to be independent of the voltage of the ESS 205.
  • the contactors 1060 may be controlled based on a command received from the SCU 200.
  • the ESS 205 may also include additional components which are described for slaves including processor 400, non-volatile memory 405 and volatile memory 410 as shown in Fig. 4 (and Fig. 9).
  • the PCS 210 functions to regulate power to a motor to move the vehicle.
  • the PCS 210 may comprise an inverter (for an electric vehicle).
  • the inverter may be coupled to the DC link and the motor.
  • the PCS 210 may comprise two inverters. One inverter coupled to a genset (generator and engine) and other coupled to the motor. Both inverters may be coupled to the DC link.
  • the SCU 200 may control one or more functions of the vehicle based on input received from user interfaces (such as a pedal or brake), input received from sensors, input from the ESS 205, such as state of charge (SOC) and PCS 210.
  • the SCU 200 may receive input from the user interfaces and issue a torque or speed command to the PCS 210, which in turns regulates power from the DC link into a motor.
  • the SCU 200 may also determine torque sharing between a genset and the ESS 205.
  • the hybrid vehicle may be a series or parallel hybrid.
  • the APS 215 may comprise one or more modules for supplying power for the accessories.
  • the modules may be DC to DC converters or DC to AC converters.
  • the slaves are not limited to the example of devices depicted in Fig. 2.
  • other slaves may be, but not limited to, an engine controller, steering controller, display, information systems, air conditioning controllers, electric brake controller, EV charge controller, high voltage PDUs, air compressors, ....etc.
  • Fig. 3 illustrates a block diagram of a master 100 in accordance with aspects of the disclosure.
  • the master 100 comprises a processor 300, non-volatile memory 305 and volatile memory 310.
  • the processor 300 may be microcontrollers, microprocessors or field programmable gate arrays (FPGAs).
  • the non-volatile memory 305 may be read-only memory (ROM) and flash memory.
  • the non-volatile memory 305 may include one or more programs or modules to execute the functionality description herein.
  • the programs or modules may include an authentication program 355.
  • the authentication program 355 may include a hash function and a HMAC algorithm.
  • the authentication program 355 may include an algorithm (or module) for random number generation.
  • the authentication program 355 may have a module for fault mode, such as causing one or more operations of the system (e.g., vehicle) to be inhibited or restricted.
  • the non-volatile memory 305 may also have the keys 110.
  • the non-volatile memory 305 may have programs or modules for controlling the slaves after authentication. The programs are not shown for simplifying the figures.
  • the volatile memory 310 may be RAM or other temporary storage.
  • the volatile memory 310 may be working memory for the authentication program 355, information needed to control the slaves 102, 104, information received from sensors and the slaves 102, 104.
  • the volatile memory 310 may include counter(s) 360, timer(s) 365 and random number 370 used by processor 300 in executing the authentication program 355.
  • the counter(s) 360, timer(s) 365 and random numbers 370 may be associated with respective slaves 102, 104.
  • the volatile memory 310 may include a database of slave associated with the counter 360, timer 365 and random number 370 as shown in Fig. 10.
  • the counter 360 may be used to count failed authentications in a given period or retries.
  • the timer 365 may be used as a time-bound limitation for a reply to a message from the master 100, e.g., set when a random number is set (as will be described later). For example, in Fig. 10, slave SO is associated with a random number R0, the timer is TO and the counter (total attempts or retries) is CO.
  • Fig. 4 illustrates a block diagram of a slave (e.g., slave 0 102) in accordance with aspects of the disclosure.
  • a slave comprises a processor 400, non-volatile memory 405 and volatile memory 410.
  • the processor 400 may be microcontrollers, microprocessors or field programmable gate arrays (FPGAs).
  • the non-volatile memory 405 may be read-only memory (ROM) and flash memory.
  • the non-volatile memory 405 may include one or more programs or modules to execute the functionality description herein.
  • the programs or modules may include the same hash function 455 and HMAC algorithm 460 as the master 100.
  • the non-volatile memory 405 may also include the unique key (e.g., key 106) for the slave (e.g., 102).
  • the non-volatile memory 405 may also include programs or modules for executing function(s) associated with the slave. The function(s) may depend on the type of device the slave is.
  • the volatile memory 410 may be ROM or other temporary memory.
  • the volatile memory may be working memory for the slave and store the results of the hash function 455 and the HMAC 460.
  • the volatile memory 410 may also store information used in executing function(s) associated with the slave.
  • the slave may also have additional components (not shown in Fig. 4) specific to the type of slave such as the power electronics described above and other circuitry.
  • Figs. 6 and 7 illustrate flow charts for the authentication of a slave in accordance with aspects of the disclosure.
  • Fig. 6 shows functions of the master 100
  • Fig. 7 shows functions of the slave(s) 102, 104.
  • the authentication process may automatically begin when a preset event occurs.
  • the preset event may be when the system (e.g. vehicle) is powered on.
  • the preset event may be when the key for an ignition is turned (power-up state).
  • the SCU 200 may receive a key-on signal (a master run signal).
  • the preset event may be when an ESS 205 is recharged by an external device.
  • the preset event may be idle for a preset time.
  • the preset event may be periodic.
  • the master 100 and slaves 102, 104 begin to communicate with each other over the CAN (e.g., vehicle communication network 220). In this manner, the master 100 is aware of all slaves connected with the public network.
  • the master 100 receives a message from a slave, the master lOObroadcast a request for authentication to the slave (e.g., 102).
  • the request may include a predefined identifier in the CAN message.
  • the predefined identifier may be used to discriminate a request for authentication from other CAN messages.
  • a CAN message in typically sent as a frame. The frame includes an ID/header and data field.
  • the predefined identifier may be included in the ID/header.
  • the data field may be 0-64 bits in length. In another aspect of the disclosure, the data field may contain this predefined identifier.
  • Fig. 11A illustrates an example of a frame 1100 from the master 100 to a slave (e.g., 102).
  • the frame 1100 may also be a remote transmission request, e.g., requesting transmission of the random number.
  • the frame 1100 may also include both a start of frame (SOF) and an end of frame (EOF) to indicate the start and end of the message..
  • SOF start of frame
  • EEF end of frame
  • the identifier of the source of the frame may be included in the ID/header and ID/header may also include the destination identifier, e.g., the identifier of the slave, when the random number is different for each slave. In other aspects, the destination identifier may be omitted when the random number is the same for the slaves.
  • the ID/header may be 29 bits.
  • the request for authentication may include a random number associated with the slave.
  • the master 100 generates a random number for the slave at S600.
  • the master 100 will generate a different random number for each slave 102, 104.
  • this random number is generated from a pseudorandom number generator (PRNG).
  • PRNG pseudorandom number generator
  • CSRNG cryptographically secure random number generator
  • the use of a PRNG or a CSRNG ensures a certain level of entropy or randomness.
  • the processor 300 generates the random number using one of the above techniques.
  • the same random number may be used for all the slaves in a given authentication session (cycle) such that the random number is valid for a period of time.
  • the slave 102, 104 may initially transmit a request for authentication.
  • the request for authentication may include the predefined identifier in the CAN message.
  • the predefined identifier may be used to discriminate a request for authentication from other CAN messages.
  • the master 100 broadcasts the frame 1100 to the slave that requested authentication.
  • the master 100 sends the random number to any slave that communicated with the master 100.
  • the master 100 sends the random number to each slave 102, 104 that requested authentication.
  • the master 100 generates a unique frame for each slave 102, 104.. This is to allow for only the target slave to respond to the frame.
  • the same frame 1100 may be used for all slaves, where the random number is the same for all slaves.
  • the random number may be included in the data field.
  • the random number may be 64 bits in length or less.
  • the random number may be padded to obtain a number of 64 bits in length.
  • the generated random number is stored in the volatile memory 310 (in 370).
  • Each frame may be broadcast onto the vehicle communication network 220 (CAN bus).
  • the frame may also include a bit to identify a remote transmission request (RTR).
  • one frame may be sent instead of multiple frames.
  • the random number is shown in Fig. 1 as R g .
  • the processor 300 sets a timer to a preset, as a time-bound limitation.
  • the value of the timer is stored in the volatile memory 310 (timer 365) in association with the random number 370 and an identifier of the respective slave.
  • the time-bound limitation provides an additional level of safety and security and can also deter bad actors from attempting to infiltrate and tamper with a system in accordance with aspects of the disclosure.
  • the time-bound limitation may be a variable value. For example, the time-bound limitation may be longer when there are more slaves to allow for time for sequential authentication. For example, in a vehicle where there are multiple ESS connected, authentication may take longer and thus, the time-bound limitation may be set to a higher value to avoid false time-outs.
  • the authentication may be in parallel.
  • the time-bound limitation is 500 milliseconds (ms). In other aspects, the time-bound limitation may be higher such as 1 second.
  • a different time-bound limitation may be used for different types of slaves. For example, when the slave is a high voltage, and/or high power and/or high current device, the time may be shorter than when the slave is of lower voltage, and/or lower power and/or lower current.
  • the timers 365 may count down. In other aspects, the timers 365 may start at zero and count up to the set time.
  • the processor 300 may continuously monitor each of the set timers for expiration (e.g., reaching the time-bound limitation). When a response is received with a frame containing an actual HMAC, the respective timer is stopped, otherwise, the timer(s) continue.
  • the slave receives a frame containing the random number.
  • the processor 400 in the slave extracts the random number from the frame and retrieves a key (e.g., 106) stored in the non-volatile memory 405 at S705.
  • FIG. 5 is a diagrammatic overview showing how the HMAC is generated, in accordance with aspects of the present disclosure.
  • the respective slave 102, 104 takes the respective random number (RQ) from the master 100 and runs it through a secure one-way hash function 455.
  • the secure hash function may be a National Institute of Standards and Technology (NIST) approved hash function such as SHA1, SHA2, SHA3 and SHAKE.
  • NIST National Institute of Standards and Technology
  • the SHA3 may be a SHA3-256 hash function.
  • the SHA3-256 hash function has a low memory overhead and good runtime speed.
  • the secure hash function allows for updates published by the NIST as a U.S.
  • the secure hash function 455 produces an output (So), e.g., computes SHA3(R) and receives S out, where R is the random number.
  • the respective slave 102, 104 will use its unique key (K m ) with So in the HMAC Generator (HMAC algorithm 460) to produce an HMAC (H m ), e.g., computes HMAC(S, K) and receives an HMAC as output, where K is the key and S is the output of the secure hash function (input to the HMAC).
  • the HMAC algorithm 460 may use FIPS standard such as FIPS 198-1 keyed HMAC algorithm.
  • the processor 400 compares the length of key (e.g., 106) with a set length, e.g., B-bytes. If the length is less than B-bytes, than, the processor 400 appends set values to the end of the key (e.g., 106) to create a k’ having the set length.
  • the set length may be 64 bytes.
  • the processor 400 executes a hash of the key (e.g., 106) to obtain a string of length F.
  • the string of length F may be padded if necessary to create the key k’ having the set length.
  • the processor 400 may perform a set logical operation on the key k’ (or key, e.g., 106, if the key is the set length) (collectively referenced as K’) and another value.
  • the logical operation may be an XOR function. This other value may be ipad. Ipad is an inner padding where a certain pattern is repeated and may be set to a predefined value.
  • the processor 400 uses the result of the logical operation and appends the result of the secure hash function S to the same.
  • the processor 400 executes a hash function on the result of the logical operation and the appended result of the secure hash function S, e.g., H (K’ XOR ipad) concatenation S.
  • the processor 400 also may perform a set logical operation on K’ and another value.
  • the logical operation may be an XOR function.
  • the other value may be opad.
  • Opad is an outer padding where a certain pattern is repeated and may be set to a predefined value.
  • the result of the logical operation is appended to the hash function results and the processor 400 executes a hash of the final result, e.g., H ((K’ XOR opad) concatenation H (K’ XOR ipad) concatenation S) which becomes the HMAC.
  • HMAC may be padded or truncated to a set length.
  • the set length may be 64 bits, e.g., the length of the data field.
  • the leftmost bits of the determined HMAC may be used in the data field.
  • the HMAC may be truncated to a length less than the set length and then padded to the set length (referenced herein as the actual HMAC).
  • each slave 102, 104 sends a frame 1150 to the master 100 using the vehicle communication network 220 with the actual HMAC in the data field of the frame.
  • the actual HMAC is shown in Fig. 1 as Ho to H n .
  • the frame 1150 may also include the identifier of the respective slave such that the master 100 knows which slave sent the frame and the identifier of the master 100 (in the ID/header).
  • the master 100 receives the actual HMAC from the slave. In response to receipt thereof, the master 100 stops or resets the timer 365 associated with the slave 102, 104. Additionally, in response to receipt of the actual HMAC from the slave 102, 104, the processor 300 in the master 100 determines the expected HMAC (or truncated and/or padded HMAC). The processor 300 uses the same hash function 455 and HMAC algorithm 460 that the slave uses. The processor 300 also truncates and/or padded calculated HMAC to obtain the expected HMAC, as necessary. In an aspect of the disclosure, the processor 300 waits until the actual HMAC from the slave is received prior to starting the determination to save processing resources.
  • the processor 300 determines the expected HMAC prior to receipt of the actual HMAC to save time.
  • the processor 300 in the master 100 compares the actual HMAC received from a slave with the expected HMAC determined by the master (for each slave). At S625, the processor 300 in the master determines whether the slave is authentic based on the comparison (or a failure to authenticate). [0080] If the received HMAC (from a slave) equals the expected HMAC (for the same slave), then that slave (e.g., 102) is authentic. Once the authentication process has successfully completed (e.g., a match), then the master 100 may control a system such as a vehicle based on a normal operation mode, e.g., cause certain operations to be enabled (at S630). At S630, the master 100 may issue commands, as needed, to the slave to control at least one function of the system. The command and the function may depend on the functionality of the slave and the overall system.
  • the slave receives the command and executes the corresponding function or functions.
  • the slave If the actual HMAC received from a slave (e.g., 102) does not match the expected HMAC (determined by the master), the slave is not authenticated.
  • a slave is allowed to attempt to authenticate a predetermined number of times within a period in case a slave is not authenticated the first attempt.
  • the number of times may be 5.
  • the number of times may be variable and may depend on the type of slave. For example, when the slave is a high voltage, and/or high power and/or high current device, the number of times may be less than when the slave is of lower voltage, and/or lower power and/or lower current.
  • the number of times allowed may be stored in volatile memory 310 (and the processor 300 maintains a count of the attempts). The counts may be counted by counters which may be stored in volatile memory (counter(s) 360).
  • a number of retries may be used instead of using a total number of attempts.
  • the total number of attempts includes the first attempt and thus is one more than the number of retries.
  • the master 100 if the master 100 does not receive an actual HMAC from a slave within the time (timer expires), the master 100 declares an authentication failure (failed attempt). This may count as one of the allowed failed attempts for that slave.
  • Fig. 8 illustrates an example of the authentication process for an ESS 205 (example of a slave) by an SCU 200 (example of a master) in accordance with aspects of the disclosure.
  • the system may be either a hybrid electric vehicle or an electric vehicle such as a bus with a PCS 210 that is the power processing and power management center of the vehicle.
  • the process in Fig. 8 is shown in three phases: the negotiation phase 1000, the hashing phase 1010 and the verification phase 1020 for descriptive purposes; however, the process may not have distinct phases.
  • the processing starts in the SCU 200 and in one example, as described above; this is done as the vehicle is powered on.
  • the negotiation phase 1000 the processing commences with communication being established at S800. If communication between the SCU 200 and the ESS 205 is established, the SCU 200 generates the random number at S815 for the ESS 205.
  • the SCU 200 uses a random number generator (included in the authentication program 355) such as the pseudorandom number generator (PRNG) or cryptographically secure random number generator (CSRNG) to generate the ESS random number.
  • PRNG pseudorandom number generator
  • CSRNG cryptographically secure random number generator
  • the ESS 205 may send a request for authentication.
  • the SCU 200 may determine whether the authentication is requested.
  • the request may include the predefined identifier.
  • the SCU 200 may generate the random number for the ESS 205.
  • the SCU 200 sends the random number to the ESS 205 via the vehicle communication network 220 (CAN bus).
  • CAN bus vehicle communication network 220
  • the random number is included in the data field of the frame 1100.
  • the predefined identifier may also be included in the ID/header such that the ESS 205 may distinguish the request for authentication from other CAN messages.
  • the SCU 200 set a timer 365 to a time, e.g., time-bound limitation, for the ESS 205.
  • this time-bound limitation may be specific for the ESS 205 (different from other time-bound limitations from other slaves).
  • a running timer may be stored in the volatile memory 310.
  • the ESS 205 determines whether a frame 1100 with the random number has been received via the vehicle communication network 220 (CAN bus). If the frame 1100 with the random number is not received (“NO” at S825), the ESS 205 waits and repeats the determination (S825).
  • the processing proceeds to the hash phase 1010 (at S830).
  • the ESS 205 may retrieve the key (e.g., 106) from the non-volatile memory 305.
  • the ESS 205 calculates the HMAC for the ESS 205.
  • the ESS 205 uses a secure hash function 455 to generate an input to an HMAC algorithm 460.
  • An example of the secure hash function 455 was described above.
  • the secure hash function 455 is executed on the received random number.
  • the ESS 205 executes that HMAC algorithm 460 using the output of the secure hash function 455 and the retrieved key as input.
  • the ESS 205 may execute the secure hash function 455 on the received random number prior to retrieving the key for use in the HMAC algorithm 460 as the key is not needed in the secure hash function 455.
  • the ESS 205 sends a frame 1150 having the HMAC (actual HMAC) in the data field to the SCU 200 via the vehicle communication network 200 (CAN bus).
  • the SCU 200 determines whether the frame 1150 having an actual HMAC has been received. For example, the SCU 200 may determine whether it received a frame having an HMAC in the data field from the ESS 205.
  • the SCU 200 determines that the actual HMAC is received (“YES” at S845), the retrieves the key and the random number 370 associated with the ESS 205 from the non-volatile memory 305. For example, the SCU 200 matches an identifier associated with the ESS 205 from the received frame with an identifier in the non volatile memory 405 (which is associated with a key and a random number).
  • the SCU 200 independently calculates an expected HMAC for the ESS.
  • the SCU 200 uses the same secure hash function 455 to generate an input to the same HMAC algorithm 460. An example of the secure hash function 455 was described above.
  • the secure hash function 455 is executed on the random number generated by the SCU 200 for the ESS 205.
  • the SCU 200 executes that HMAC algorithm 460 using the output of the secure hash function 455 and the retrieved key as input.
  • An example, of the HMAC algorithm was described above.
  • the SCU 200 may execute the secure hash function 455 on the random number prior to retrieving the key for use in the HMAC algorithm 460 as the key is not needed in the secure hash function 455 (e.g., only retrieves the random number 370 from the volatile memory 310).
  • the SCU 200 may calculate the expected HMAC while waiting for the actual HMAC from the ESS 205. In this aspect, after calculating the expected HMAC at S855, the SCU 200 proceeds to S845.
  • the SCU 200 at S845 determines whether the actual HMAC from the ESS 205 has not been received (“NO” at S845), the SCU 200 determines whether the time for receipt has expired, e.g., time-bound limitation, at S810. S810 is shown separate from S845 however,, these steps may be executed together. At S810, the SCU 200 may monitor the value remaining on the timer 365 for the ESS 205 in the volatile memory 310. If there is remaining time, e.g., timer 365 has not expired or reached the time-bound limitation for the ESS, the SCU 200 continues to wait for the actual HMAC (returns to S845), otherwise, the process moves to the verification phase 1020 and to S 875.
  • the time for receipt e.g., time-bound limitation
  • the SCU 200 compares the expected HMAC determined by the SCU 200 with the actual HMAC received from the ESS 205 at S860, to determine whether they are the same. If there is a match (“YES” at S865), the ESS 205 is authenticated and the SCET 200 is able to control the ESS at S870.
  • normal control may include the SCU 200 issuing a command to the ESS 205 to close the contactors 1060 such that the ESS 205 is electrically connected with the DC link.
  • the attempted authentication is unsuccessful and the SCU 200 may determine whether there are more attempts allowed at S875.
  • the SCU 200 may retrieve a counter 360 associated with the ESS 205 to determine if more attempts are allowed.
  • the counter 360 may start at zero and count up to a maximum total attempts or retries or start at a maximum number of total attempts or retries and count down to zero.
  • the SCU 200 increments (or decrements) the counter 360 by 1 at S880.
  • the new value is stored in the volatile memory 310 and the process returns to S805.
  • a new random number may be generated. In other aspects, the same random number may be used.
  • the failure mode (S885) may be asserted after only one failed attempt. In this case, S875 and S880 may be omitted. In this aspect, there are no retries.
  • the SCU 200 may issue a command to the ESS 200 to maintain the contactors 1060 in an open position isolating the ESS 205 from the DC link. This is to prevent an unauthorized ESS 205 that may be improper and/or inferior from the original equipment manufacturer (OEM) ESS 205, from powering the vehicle, which can have severe consequences.
  • the ESS 205 may have a different rating. Where the vehicle is a hybrid vehicle and can run only using the combustion engine, the vehicle may run only on the combustion engine.
  • the SCU 200 may issue a notification to an operator via one of the interfaces such as a display.
  • the vehicle may also have another network interface to an external network.
  • the SCU 200 may also issue a notification to an external device that the authentication failed.
  • the SCU 200 may issue a speed or torque command to the PCS 210 such that power to the motor is reduced (speed governor) or if the vehicle is a hybrid electric vehicle, the SCU 200 may issue a speed or torque command that requires a higher percentage of the torque sharing to come from the combustion engine (gen set).
  • the SCU 200 may cause the vehicle to be controlled in such a manner with a mileage (Kilometer) limit (distance) and/or time limit for operation allowing time for the operator to drive the vehicle to a safe region or customer service center for maintenance or analysis.
  • the SCU 200 may issue a notification to an interface such as a display or a speaker indicating the failure mode such that the time and/or distance may be displayed or heard.
  • the distance and/or time being continuously updated such that the operator is aware of the remaining distance/time.
  • the functions or operations of the vehicle which are limited, restricted or inhibited may depend of the functions or operations of the slave which is not authenticated.
  • high power operations current or voltage
  • the downstream components such as a motor made be operated in a derated condition (lower power, speed, etc).
  • the recording function can be disabled upon an authentication failure. If the navigation system fails authentication, the corresponding features involving the navigation system can be limited such as reliance upon the GPS coordinates or location mapping.
  • frames received from slaves that are not authenticated may be ignored until another slave confirms the information contained in the data field.
  • the SCU 200 may check for timeout at S 810 (time-bound limitation). This time may be different than the time set for receipt of an HMAC after sending the random number. In an aspect of the disclosure, if the SCU 200 determines a timeout, the SCU 200 may assert a failure mode at S885.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Small-Scale Networks (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
PCT/US2021/018457 2020-02-18 2021-02-18 Authenticating devices over a public communication network WO2021168037A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP21757129.8A EP4107038B1 (de) 2020-02-18 2021-02-18 Authentifizierung von geräten über ein öffentliches kommunikationsnetz
US17/282,887 US11303455B2 (en) 2020-02-18 2021-02-18 Authenticating devices over a public communication network
CA3172759A CA3172759C (en) 2020-02-18 2021-02-18 Authenticating devices over a public communication network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202062978264P 2020-02-18 2020-02-18
US62/978,264 2020-02-18

Publications (1)

Publication Number Publication Date
WO2021168037A1 true WO2021168037A1 (en) 2021-08-26

Family

ID=77391665

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2021/018457 WO2021168037A1 (en) 2020-02-18 2021-02-18 Authenticating devices over a public communication network

Country Status (4)

Country Link
US (1) US11303455B2 (de)
EP (1) EP4107038B1 (de)
CA (1) CA3172759C (de)
WO (1) WO2021168037A1 (de)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070200671A1 (en) * 2006-02-28 2007-08-30 Kelley Nia L Methods and apparatuses for remote control of vehicle devices and vehicle lock-out notification
US20180084412A1 (en) * 2016-09-20 2018-03-22 2236008 Ontario Inc. In-vehicle networking
WO2019069129A1 (en) * 2017-10-04 2019-04-11 Keyfree Technologies Inc. METHODS AND DEVICES FOR MANAGING ACCESS TO A VEHICLE
US20190213145A1 (en) * 2018-01-05 2019-07-11 Denso International America, Inc. Mobile De-Whitening
US20200005570A1 (en) * 2018-06-29 2020-01-02 Micron Technology, Inc. Secure wireless lock-actuation exchange

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7730307B2 (en) * 2006-04-07 2010-06-01 Sensis Corporation Secure ADS-B authentication system and method
CN105594155B (zh) * 2014-05-08 2019-08-02 松下电器(美国)知识产权公司 车载网络系统、电子控制单元以及更新处理方法
US9860689B2 (en) 2015-10-28 2018-01-02 International Business Machines Corporation Issuing notifications about lost devices
DE102016210786A1 (de) * 2016-02-18 2017-08-24 Volkswagen Aktiengesellschaft Komponente zur Anbindung an einen Datenbus und Verfahren zur Umsetzung einer kryptografischen Funktionalität in einer solchen Komponente
KR101831134B1 (ko) * 2016-05-17 2018-02-26 현대자동차주식회사 암호화를 적용한 제어기 보안 방법 및 그 장치
JP6870072B2 (ja) * 2016-09-23 2021-05-12 アップル インコーポレイテッドApple Inc. ネットワークタイミング同期
EP3321892A1 (de) * 2016-11-10 2018-05-16 Gemalto Sa Physischer schlüssel zur bereitstellung einer kommunikationsvorrichtung mit daten zur ermöglichung des zugriffs auf eine fahrzeugressource
WO2018189885A1 (ja) * 2017-04-14 2018-10-18 三菱電機株式会社 鍵管理システム、通信機器および鍵共有方法
US10009325B1 (en) * 2017-12-07 2018-06-26 Karamba Security End-to-end communication security
US10850684B2 (en) * 2017-12-19 2020-12-01 Micron Technology, Inc. Vehicle secure messages based on a vehicle private key
US10757676B1 (en) * 2019-03-08 2020-08-25 Tile, Inc. Commissioning electronic devices for use in a tracking system
US11089004B2 (en) * 2019-05-01 2021-08-10 Blackberry Limited Method and system for application authenticity attestation

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070200671A1 (en) * 2006-02-28 2007-08-30 Kelley Nia L Methods and apparatuses for remote control of vehicle devices and vehicle lock-out notification
US20180084412A1 (en) * 2016-09-20 2018-03-22 2236008 Ontario Inc. In-vehicle networking
WO2019069129A1 (en) * 2017-10-04 2019-04-11 Keyfree Technologies Inc. METHODS AND DEVICES FOR MANAGING ACCESS TO A VEHICLE
US20190213145A1 (en) * 2018-01-05 2019-07-11 Denso International America, Inc. Mobile De-Whitening
US20200005570A1 (en) * 2018-06-29 2020-01-02 Micron Technology, Inc. Secure wireless lock-actuation exchange

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
See also references of EP4107038A4 *
YU-HSIU HUANG, FAN KAI-HSUN, HSIEH WEN-SHYONG: "Message Authentication Scheme for Vehicular Ad-Hoc Wireless Networks without RSU", JOURNAL OF INFORMATION HIDING AND MULTIMEDIA SIGNAL PROCESSING, vol. 6, no. 1, 1 January 2015 (2015-01-01), pages 113 - 122, XP055267262, ISSN: 2073-4212 *

Also Published As

Publication number Publication date
CA3172759C (en) 2023-07-04
EP4107038A4 (de) 2023-08-02
US20210385089A1 (en) 2021-12-09
EP4107038B1 (de) 2024-04-17
EP4107038A1 (de) 2022-12-28
US11303455B2 (en) 2022-04-12
CA3172759A1 (en) 2021-08-26

Similar Documents

Publication Publication Date Title
CN112849055B (zh) 基于底盘域控制器的智能汽车信息流冗余安全控制系统
US10630481B2 (en) Controller area network message authentication
KR101849357B1 (ko) 차량 주행 제어 방법
WO2017211035A1 (zh) 增程式电动车辆及其能量管理控制方法和装置
US20160330032A1 (en) Authenticating messages sent over a vehicle bus that include message authentication codes
EP3926500B1 (de) Upgrade-verfahren für vorrichtung und zugehörige vorrichtung
US20080306647A1 (en) In-vehicle network system and control method thereof
EP4089978A1 (de) Authentifizierungsverfahren und -vorrichtung für eine fahrzeugmontierte vorrichtung
CN112740617B (zh) 证书列表更新方法及装置
EP4107038B1 (de) Authentifizierung von geräten über ein öffentliches kommunikationsnetz
CN113268046B (zh) Autosar架构下诊断联网安全解锁实现系统
CN111038296A (zh) 车辆及用于控制车辆的方法
JP2019187231A (ja) バッテリー電力供給のための認証方法及びシステム
CN112622692B (zh) 一种用于电动车的电池包认证方法
CN114785557B (zh) 一种整车对称密钥分发系统、方法及存储介质
US11488404B2 (en) Session unique access token for communications with a vehicle
CN114157489A (zh) 基于周期性鉴权握手机制的通信域控制器安全通信方法
KR20230145367A (ko) 탈착식 배터리 모듈이 있는 전력 시스템
KR20220037120A (ko) 배터리 장치 및 통신 방법
US20230087521A1 (en) Computing device verification
CN111200498A (zh) 对机动车中的数据包的验证
JP6921034B2 (ja) 車載ネットワークへの不正メッセージ注入防止技術
JP2002164905A (ja) 車両用制御システム
CN113645029A (zh) 直流充电桩的通讯方法、通讯装置
JP2021176721A (ja) 車両制御システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21757129

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3172759

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021757129

Country of ref document: EP

Effective date: 20220919