Vehicle service subscriber system, method and storage medium used in the system

Abstract

The present invention provides a vehicle service subscriber system, a method for the system, and a storage medium. A method, device, and system for session key generation for AV operation are disclosed. In an embodiment, the vehicle service subscriber system generates entropy. The vehicle service subscriber system is associated with a vehicle service subscriber. The vehicle service subscriber system sends a synchronization message to a vehicle service provider system associated with at least one vehicle. The synchronization message includes entropy. The vehicle service subscriber system receives a salt from the vehicle service provider system. The vehicle service subscriber system verifies that the salt is generated using entropy. The vehicle service subscriber system uses the salt to calculate a session key. The vehicle service subscriber system receives a protected message from the vehicle service provider system. The vehicle service subscriber system uses the session key to authenticate the protected message. The protected message is used to provide a ride involving at least one vehicle.

Description

Technical Field

[0001] Embodiments relate to vehicle operation, and in particular to session key generation for autonomous vehicle operation. Background Art

[0002] Autonomous vehicle (AV) service providers sometimes use communication channels to communicate with subscribers of AV services. However, the use of such communication channels is susceptible to replay attacks on AV service subscribers, for example, if a malicious entity uses a traditional communication channel to send a false message to the AV service subscriber. Summary of the invention

[0003] A method for a vehicle service subscriber system, comprising: generating entropy by a vehicle service subscriber system having at least one processor, the vehicle service subscriber system being associated with a vehicle service subscriber; sending a synchronization message by the vehicle service subscriber system using the at least one processor to a vehicle service provider system associated with at least one vehicle, the synchronization message including the entropy; receiving a salt from the vehicle service provider system using the at least one processor by the vehicle service subscriber system; verifying by the vehicle service subscriber system using the at least one processor that the salt was generated using the entropy; calculating a session key using the salt by the vehicle service subscriber system using the at least one processor; receiving a protected message from the vehicle service provider system using the at least one processor by the vehicle service subscriber system; and authenticating the protected message using the session key by the vehicle service subscriber system using the at least one processor, wherein the protected message is used to provide a ride involving the at least one vehicle.

[0004] A vehicle service subscriber system includes: at least one computer processor; and at least one non-transitory storage medium storing instructions, which, when executed by the at least one computer processor, cause the vehicle service subscriber system to perform the above method.

[0005] At least one non-transitory storage medium storing instructions that, when executed by at least one computer processor of a vehicle service subscriber system, cause the vehicle service subscriber system to perform the above method. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 is a block diagram illustrating an example of an AV with autonomous capabilities in accordance with at least one embodiment.

[0007] Figure 2 is a block diagram illustrating an example "cloud" computing environment in accordance with at least one embodiment.

[0008] Figure 3 is a block diagram illustrating a computer system according to at least one embodiment.

[0009] Figure 4 is a block diagram illustrating an example architecture of an AV in accordance with at least one embodiment.

[0010] Figure 5 is a flow chart illustrating a process for session key generation for AV operations according to at least one embodiment.

[0011] Figure 6 is a flow chart illustrating a process for session key generation for AV operations according to at least one embodiment.

[0012] Figure 7 is a timing diagram illustrating a process for session key generation for AV operations according to at least one embodiment.

[0013] Figure 8 is a flow chart illustrating a process for session key generation for AV operations according to at least one embodiment.

[0014] Fig. 9 is a timing diagram illustrating a process for session key generation for AV operations according to at least one embodiment.

[0015] Fig.10 is a timing diagram illustrating a process for session key generation for AV operations according to at least one embodiment.

[0016] Fig.11 is a flow chart illustrating a process for session key generation for AV operations according to at least one embodiment.

[0017] Fig.12 is a flow chart illustrating a process for session key generation for AV operations according to at least one embodiment.

[0018] Fig.13 is a flowchart illustrating the process of session key generation for AV operations.

[0019] Fig.14 is a flow chart illustrating a process for session key generation for AV operations according to at least one embodiment. DETAILED DESCRIPTION

[0020] In the following description, for the purpose of explanation, many specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent that the present invention can be implemented without these specific details. In other examples, well-known configurations and devices are shown in block diagram form to avoid unnecessarily obscuring the present invention.

[0021] In the accompanying drawings, for ease of description, the specific arrangement or order of schematic elements (such as those representing devices, modules, instruction blocks, and data elements) is shown. However, it should be understood by those skilled in the art that the specific order or arrangement of the schematic elements in the accompanying drawings is not intended to mean that a specific processing order or sequence, or separation of processing processes is required. In addition, the inclusion of schematic elements in the accompanying drawings is not intended to mean that such elements are required in all embodiments, nor is it intended to mean that the features represented by such elements cannot be included in the embodiments or cannot be combined with other elements in the embodiments.

[0022] In addition, in the accompanying drawings, connecting elements, such as solid or dotted lines or arrows, are used to illustrate the connection, relationship or association between two or more than two other schematic elements, and there is no such connecting element and is not intended to mean that there can be no connection, relationship or association. In other words, the connection, relationship or association between some elements are not shown in the accompanying drawings so as not to obscure the present disclosure. In addition, for ease of illustration, a single connecting element is used to represent multiple connections, relationships or associations between elements. For example, if the connecting element represents the communication of a signal, data or instruction, it will be understood by those skilled in the art that this element represents one or more signal paths (e.g., buses) that may be needed to affect the communication.

[0023] Reference will now be made in detail to the embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments described. However, it will be apparent to one of ordinary skill in the art that the various embodiments described may be implemented without these specific details. In other cases, well-known methods, procedures, components, circuits, and networks are not described in detail in order not to unnecessarily obscure aspects of the embodiments.

[0024] Several features described below can each be used independently of one another or in combination with other features. However, any individual feature may not solve any of the problems discussed above, or may only solve one of the problems discussed above. Some of the problems discussed above may not be fully solved by any one of the features described herein. Although a title is provided, information related to a specific title but not found in the section with that title may also be found elsewhere in this specification. This article describes an embodiment according to the following summary:

[0025] 1. General Overview

[0026] 2. System Overview

[0027] 3.AV Architecture

[0028] 4. Session key generation for AV operations

[0029] General Overview

[0030] Methods, systems and devices for session key generation for AV operations are presented herein. A session key is a single-use symmetric key calculated by an AV service provider that rents or distributes AV to users of AV services. The session key is used to encrypt messages in a communication session between the AV service provider and the AV service subscriber. The AV service provider incorporates the entropy generated by each AV service subscriber into its salt for calculating the session key. As used herein, "salt" refers to data such as random or pseudo-random data that is used as an additional input to a function for calculating a session key. Each AV service subscriber uses technology independent of the AV service provider to verify the salt provided by the AV service provider and calculate the session key.

[0031] Advantages and benefits of the embodiments disclosed herein include preventing replay attacks on subscribers of AV services by malicious entities. The disclosed embodiments also enable on-demand (e.g., when a particular AV service subscriber requests a new ride) key updates for AV service provider-subscriber groups. The AV service provider can easily generate new salts (and therefore, new session keys) and securely notify AV service subscribers of the changes. The entropy generated by individual AV service subscribers improves the security and robustness of the communication system. Furthermore, subscribers and providers independently determine matching session keys, thereby reducing computational overhead.

[0032] The salt does not change during the life of the session. Therefore, the AV service subscriber can avoid monitoring the salt message after successfully authenticating the protected message, thereby reducing data transfer and computation. Entropy is carried forward for the duration of the session, thereby reducing entropy weaknesses at the AV service provider and preventing replay attacks. Security is further improved because the generated salt chain represents the history of all entropy provided by the AV service subscriber in the session. The embodiments disclosed herein also prevent rainbow table attacks by forcing malicious entities to recalculate session keys using salt and entropy. A rainbow table attack is a type of hacker attack in which a perpetrator attempts to crack passwords stored in a database system using a rainbow hash table.

[0033] System Overview

[0034] Figure 1 is a block diagram illustrating an example of an AV 100 having autonomous capabilities in accordance with at least one embodiment.

[0035] As used herein, the term "autonomous capability" refers to a function, feature, or facility that enables a vehicle to operate partially or fully without real-time human intervention, including but not limited to fully autonomous vehicles, highly autonomous vehicles, and conditionally autonomous vehicles.

[0036] As used herein, an AV is a vehicle with autonomous capabilities.

[0037] As used herein, "vehicle" includes a mode of transport of goods or people. For example, a car, bus, train, airplane, drone, truck, boat, ship, submersible, spacecraft, etc. An unmanned car is an example of a vehicle.

[0038] As used herein, a "trajectory" refers to a path or route along which an AV is operated from a first spatiotemporal location to a second spatiotemporal location. In an embodiment, the first spatiotemporal location is referred to as an initial location or a starting location, and the second spatiotemporal location is referred to as a destination, a final location, a target, a target location, or a target location. In some examples, a trajectory consists of at least one road segment (e.g., several sections of a road), and each road segment consists of at least one block (e.g., a portion of a lane or intersection). In an embodiment, a spatiotemporal location corresponds to a real-world location. For example, a spatiotemporal location is a pickup or drop-off location to get people or cargo on or off the vehicle.

[0039] As used herein, "sensor(s)" includes at least one hardware component for detecting information about the environment surrounding the sensor. Some hardware components may include sensing components (e.g., image sensors, biometric sensors), transmission and / or reception components (e.g., laser or radio frequency wave transmitters and receivers), electronic components (such as analog-to-digital converters), data storage devices (such as random access memory (RAM) and / or non-volatile memory), software or firmware components and data processing components (such as application specific integrated circuits), microprocessors and / or microcontrollers.

[0040] As used herein, a “scene description” is a data structure (e.g., a list) or data stream that includes at least one classified or labeled object detected by at least one sensor on the AV vehicle, or one or more classified or labeled objects provided by a source external to the AV.

[0041] As used herein, a "road" is a physical area that can be traversed by a vehicle and may correspond to a named thoroughfare (e.g., a city street, an interstate highway, etc.) or may correspond to an unnamed thoroughfare (e.g., a driveway within a house or office building, a section of a parking lot, a section of a vacant parking lot, a dirt road in a rural area, etc.). Because some vehicles (e.g., four-wheel drive pickup trucks, off-road vehicles (SUVs), etc.) are able to traverse a variety of physical areas that are not particularly suitable for vehicle travel, a "road" may be any physical area that is not formally defined as a thoroughfare by a municipality or other governmental or administrative agency.

[0042] As used herein, a "lane" is a portion of a road that can be traversed by vehicles and may correspond to most or all of the space between lane markings, or only a portion of the space between lane markings (e.g., less than 50%). For example, a road with lane markings that are far apart may accommodate two or more vehicles, allowing one vehicle to pass another without crossing the lane markings and thus may be interpreted as having a lane narrower than the space between lane markings, or as having two lanes between lanes. Lanes may also be interpreted in the absence of lane markings. For example, lanes may be defined based on physical features of the environment, such as rocks in a rural area and trees along an avenue.

[0043] “At least one” includes a function performed by one element, a function performed by multiple elements, such as in a distributed manner, several functions performed by one element, several functions performed by several elements, or any combination of the above.

[0044] It will also be understood that although in some cases, the terms "first," "second," etc. are used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of the various described embodiments, a first contact may be referred to as a second contact, and similarly, a second contact may be referred to as a first contact. Both the first contact and the second contact are contacts, but they are not the same contact.

[0045] The terms used in the specification of the various embodiments described herein are only used for the purpose of describing specific embodiments and are not intended to be limiting. As used in the specification of the various embodiments described and the appended claims, the singular forms "a", "an" and "the" are also intended to include plural forms, unless the context clearly indicates otherwise. It will also be understood that "and / or" as used herein refers to and includes any and all possible combinations of at least one related list item. It will also be understood that when the terms "include", "comprises", "has" and / or "has" are used in this specification, the stated features, integers, elements, operations, elements and / or components are specifically stated, but the presence or addition of at least one other feature, integer, element, operation, element, component, and / or its group is not excluded.

[0046] As used herein, the term "if" is alternatively understood to mean "when" or "at the time" or "in response to determining that" or "in response to detecting," depending on the context. Similarly, the phrases "if it has been determined" or "if [the stated condition or event] has been detected" are alternatively understood to mean "upon determination" or "in response to determining that" or "upon detecting [the stated condition or event]" or "in response to detecting [the stated condition or event]," depending on the context.

[0047] As used herein, an AV system refers to an AV and the array of hardware, software, stored data, and real-time generated data that supports the operation of the AV. In an embodiment, the AV system is incorporated into the AV. In an embodiment, the AV system is distributed across several locations. For example, some software of the AV system is in a system similar to the following about Figure 3 The described cloud computing environment 300 is implemented on the cloud computing environment.

[0048] In general, this document describes technologies applicable to any vehicle having at least one autonomous capability, including fully AVs, highly autonomous vehicles, and conditionally autonomous vehicles, such as so-called Level 5, Level 4, and Level 3 vehicles, respectively (see SAE International Standard J3016: Classification and Definitions of Terms Relating to Automated Driving Systems for On-Road Motor Vehicles, which is incorporated herein by reference in its entirety for more details on vehicle autonomy levels). The technologies described in this document are also applicable to partially autonomous vehicles and driver-assisted vehicles, such as so-called Level 2 and Level 1 vehicles (see SAE International Standard J3016: Classification and Definitions of Terms Relating to Automated Driving Systems for On-Road Motor Vehicles). In an embodiment, at least one of the Level 1, Level 2, Level 3, Level 4, and Level 5 vehicle systems can automatically perform certain vehicle operations (e.g., steering, braking, and use of maps) under certain operating conditions based on processing of sensor inputs. The technologies described in this document can benefit any level of vehicle ranging from fully autonomous vehicles to human-operated vehicles.

[0049] refer to Figure 1 , the AV system 120 causes the AV 100 to operate along a trajectory 198, through an environment 190 to a destination 199 (sometimes referred to as a final location), while avoiding objects (e.g., natural obstacles 191, vehicles 193, pedestrians 192, cyclists, and other obstacles) and complying with road rules (e.g., operating rules or driving preferences).

[0050] In an embodiment, the AV system 120 includes means 101 for receiving and operating commands from a computer processor 146. In an embodiment, the computer processor 146 is associated with the following reference Figure 3 The processor 304 is similarly described. Examples of devices 101 include steering controls 102, brakes 103, gears, an accelerator pedal or other acceleration control mechanism, windshield wipers, side door locks, window controls, and turn indicators.

[0051] In an embodiment, the AV system 120 includes sensors 121 for measuring or inferring attributes of the state or condition of the AV 100, such as the position, linear velocity and acceleration, angular velocity and acceleration, and heading (e.g., the direction of the front end of the AV 100) of the AV. Examples of sensors 121 are a global navigation satellite system (GNSS), an inertial measurement unit (IMU) that measures both linear acceleration and angular rate of the vehicle, wheel sensors for measuring or estimating wheel slip, wheel brake pressure or brake torque sensors, engine torque or wheel torque sensors, and steering angle and angular rate sensors.

[0052] In an embodiment, the sensors 121 also include sensors for sensing or measuring properties of the environment of the AV, such as monocular or stereo cameras 122 in the visible, infrared, or thermal (or both) spectrum, LiDAR 123, RADAR, ultrasonic sensors, time-of-flight (TOF) depth sensors, velocity sensors, temperature sensors, humidity sensors, and precipitation sensors.

[0053] In an embodiment, the AV system 120 includes a data storage unit 142 and a memory 144 for storing machine instructions associated with a computer processor 146 or data collected by the sensor 121. In an embodiment, the data storage unit 142 is associated with the following Figure 3 190. In an embodiment, the memory 144 is similar to the main memory 306 described below. In an embodiment, the data storage unit 142 and the memory 144 store historical, real-time, and / or predictive information about the environment 190. In an embodiment, the stored information includes maps, driving performance, traffic congestion updates, or weather conditions. In an embodiment, data related to the environment 190 is transmitted from the remote database 134 to the AV 100 via a communication channel.

[0054] In an embodiment, the AV system 120 includes a communication device 140 for transmitting measured or inferred properties of the state and condition of other vehicles (such as position, linear and angular velocity, linear and angular acceleration, and linear and angular heading) to the AV 100. These devices include vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication devices and devices for wireless communication through point-to-point or ad hoc networks or both. In an embodiment, the communication device 140 communicates across the electromagnetic spectrum (including radio and optical communications) or other media (e.g., air and acoustic media). The combination of vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) communication (and in an embodiment, at least one other type of communication) is sometimes referred to as vehicle-to-everything (V2X) communication. V2X communication generally complies with at least one communication standard for communication with and between autonomous vehicles.

[0055] In an embodiment, the communication device 140 includes a communication interface. For example, a wired, wireless, WiMAX, Wi-Fi, Bluetooth, satellite, cellular, optical, near field, infrared, or radio interface. The communication interface transmits data from the remote database 134 to the AV system 120. In an embodiment, the remote database 134 is embedded in a Figure 2The communication interface 140 transmits data collected from the sensor 121 or other data related to the operation of the AV 100 to the remote database 134. In an embodiment, the communication interface 140 transmits information related to teleoperation to the AV 100. In an embodiment, the AV 100 communicates with other remote (e.g., "cloud") servers 136.

[0056] In an embodiment, the remote database 134 also stores and transmits digital data (e.g., stores data such as roads and street locations). Such data is stored in the memory 144 on the AV 100 or transmitted from the remote database 134 to the AV 100 via a communication channel.

[0057] In an embodiment, the remote database 134 stores and transmits historical information (e.g., speed and acceleration profiles) related to driving attributes of vehicles that have previously traveled along the trajectory 198 at similar times of day. In one implementation, such data may be stored in the memory 144 on the AV 100 or transmitted from the remote database 134 to the AV 100 via a communication channel.

[0058] The computing device 146 located on the AV 100 algorithmically generates control actions based on both real-time sensor data and a priori information, allowing the AV system 120 to perform its autonomous driving capabilities.

[0059] In an embodiment, the AV system 120 includes a computer peripheral device 132 coupled to the computing device 146 for providing information and reminders to a user of the AV 100 (e.g., an occupant or a remote user) and receiving input from the user. In an embodiment, the peripheral device 132 is similar to the one described below with reference to Figure 3 Display 312, input device 314 and cursor control 316 are discussed. The coupling is wireless or wired. Any two or more interface devices may be integrated into a single device.

[0060] Sample cloud computing environment

[0061] Figure 2 is a block diagram illustrating an example "cloud" computing environment according to at least one embodiment. Cloud computing is a service delivery model for enabling convenient, on-demand access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) over a network. In a typical cloud computing system, at least one large cloud data center houses the machines used to deliver the services provided by the cloud. Reference is now made to Figure 2, cloud computing environment 200 includes cloud data centers 204a, 204b, and 204c interconnected by cloud 202. Data centers 204a, 204b, and 204c provide cloud computing services for computer systems 206a, 206b, 206c, 206d, 206e, and 206f connected to cloud 202.

[0062] The cloud computing environment 200 includes at least one cloud data center. Figure 2 The cloud data center 204a shown in FIG. 2 refers to a cloud (eg, Figure 2 The physical arrangement of servers in a cloud 202 or a specific portion of a cloud (as shown in FIG. 202 or a specific portion of a cloud). For example, servers are physically arranged into rooms, groups, rows, and racks in a cloud data center. A cloud data center has at least one region, which includes at least one server room. Each room has at least one row of servers, and each row includes at least one rack. Each rack includes at least one individual server node. In some implementations, servers in regions, rooms, racks, and / or rows are arranged into groups based on the physical infrastructure requirements of the data center facility, including power, energy, heat, heat sources, and / or other requirements. In an embodiment, server nodes are similar to Figure 3 The data center 204a has many computing systems distributed across multiple racks.

[0063] Cloud 202 includes cloud data centers 204a, 204b, and 204c and networks and network resources (e.g., network devices, nodes, routers, switches, and network cables) used to connect cloud data centers 204a, 204b, and 204c and help facilitate access to cloud computing services by computing systems 206a-f. In an embodiment, the network represents any combination of at least one local network, wide area network, or internetwork coupled by wired or wireless links deployed using terrestrial or satellite connections. Data exchanged through the network is transmitted using a variety of network layer protocols (such as Internet Protocol (IP), Multi-Protocol Label Switching (MPLS), Asynchronous Transfer Mode (ATM), Frame Relay, etc.). In addition, in embodiments where the network represents a combination of multiple subnetworks, different network layer protocols are used on each underlying subnetwork. In an embodiment, the network represents at least one interconnected internetwork (such as the public Internet, etc.).

[0064] Computing systems 206a-f or cloud computing service consumers are connected to the cloud 202 through network links and network adapters. In an embodiment, computing systems 206a-f are implemented as various computing devices, such as servers, desktops, laptops, tablets, smart phones, Internet of Things (IoT) devices, autonomous vehicles (including cars, drones, shuttles, trains, buses, etc.) and consumer electronics. In an embodiment, computing systems 206a-f are implemented in other systems or as part of other systems.

[0065] Computer Systems

[0066] Figure 3 300 is a block diagram illustrating a computer system 300 according to at least one embodiment. In implementation, the computer system 300 is a special-purpose computing device. The special-purpose computing device is hard-wired to perform these techniques, or includes a digital electronic device such as at least one ASIC or field programmable gate array (FPGA) that is permanently programmed to perform the above-mentioned techniques, or may include at least one general-purpose hardware processor that is programmed to perform these techniques according to program instructions in firmware, memory, other memory, or a combination. Such a special-purpose computing device can also combine customized hard-wired logic, ASIC or FPGA with customized programming to complete these techniques. In various embodiments, the special-purpose computing device is a desktop computer system, a portable computer system, a handheld device, a network device, or any other device that contains hard-wired and / or program logic to implement these techniques.

[0067] In an embodiment, computer system 300 includes a bus 302 or other communication mechanism for communicating information, and a hardware processor 304 coupled to bus 302 to process information. Hardware processor 304 is, for example, a general-purpose microprocessor. Computer system 300 also includes a main memory 306, such as a RAM or other dynamic storage device, coupled to bus 302 to store information and instructions, which are executed by processor 304. In one implementation, main memory 306 is used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 304. When these instructions are stored in a non-transitory storage medium accessible to processor 304, computer system 300 becomes a special-purpose machine that is customized to perform the operations specified in the instructions.

[0068] In an embodiment, computer system 300 also includes a read only memory (ROM) 308 or other static storage device coupled to bus 302 for storing static information and instructions for processor 304. A storage device 310, such as a magnetic disk, optical disk, solid state drive, or three-dimensional cross point memory, is provided and coupled to bus 302 to store information and instructions.

[0069] In an embodiment, the computer system 300 is coupled to a display 312 such as a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, a light emitting diode (LED) display, or an organic light emitting diode (OLED) display for displaying information to a computer user via bus 302. An input device 314 including alphanumeric and other keys is coupled to bus 302 for communicating information and command selections to processor 304. Another type of user input device is a cursor controller 316, such as a mouse, a trackball, a touch display, or cursor direction keys, for communicating direction information and command selections to processor 304 and for controlling movement of a cursor on display 312. Such input devices typically have two degrees of freedom in two axes, a first axis (e.g., an x-axis) and a second axis (e.g., a y-axis) that allow the device to specify a position on a plane.

[0070] According to one embodiment, the techniques herein are performed by computer system 300 in response to processor 304 executing at least one sequence of at least one instruction contained in main memory 306. These instructions are read into main memory 306 from another storage medium, such as storage device 310. Execution of the sequences of instructions contained in main memory 306 causes processor 304 to perform the processing elements described herein. In alternative embodiments, hard-wired circuitry is used in place of or in combination with software instructions.

[0071] As used herein, the term "storage medium" refers to any non-temporary medium that stores data and / or instructions that cause a machine to operate in a particular manner. Such storage media include non-volatile media and / or volatile media. Non-volatile media include, for example, optical disks, magnetic disks, solid-state drives, or three-dimensional cross-point memories such as storage device 310. Volatile media include dynamic memories such as main memory 306. Common forms of storage media include, for example, floppy disks, floppy disks, hard disks, solid-state drives, tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a hole pattern, RAM, PROM and EPROM, FLASH-EPROM, NV-RAM, or any other memory chip or storage box.

[0072] Storage media are distinct from transmission media, but can be used in conjunction with transmission media. Transmission media participate in the transmission of information between storage media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including wires that provide bus 302. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communications.

[0073] In an embodiment, various forms of media are involved in carrying at least one sequence of at least one instruction to the processor 304 for execution. For example, the instructions are initially executed on a disk or solid-state drive of a remote computer. The remote computer loads the instructions into its dynamic memory and sends the instructions over a telephone line using a modem. The local modem of the computer system 300 receives the data on the telephone line and uses an infrared transmitter to convert the data to an infrared signal. An infrared detector receives the data carried in the infrared signal, and appropriate circuitry places the data on the bus 302. The bus 302 carries the data to the main memory 306, from which the processor 304 retrieves and executes the instructions. The instructions received by the main memory 306 may optionally be stored on the storage device 310 before or after execution by the processor 304.

[0074] Computer system 300 also includes a communication interface 318 coupled to bus 302. Communication interface 318 provides a two-way data communication coupled to a network link 320 connected to a local network 322. For example, communication interface 318 is an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem for providing a data communication connection with a corresponding type of telephone line. As another example, communication interface 318 is a local area network (LAN) card for providing a data communication connection with a compatible LAN. In some implementations, a wireless link is also implemented. In any such implementation, communication interface 318 sends and receives an electrical, electromagnetic or optical signal carrying a digital data stream representing various types of information.

[0075] The network link 320 typically provides data communication to other data devices through at least one network. For example, the network link 320 provides a connection to a host computer 324 or to a cloud data center or device operated by an Internet Service Provider (ISP) 326 through a local network 322. The ISP 326, in turn, provides data communication services through a worldwide packet data communication network now commonly referred to as the "Internet" 328. Both the local network 322 and the Internet 328 use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 320 and through the communication interface 318 are example forms of transmission media, where these signals carry digital data to and from the computer system 300. In an embodiment, the network 320 includes the cloud 202 described above or a portion of the cloud 202.

[0076] Computer system 300 sends messages and receives data, including program code, through network(s), network link 320, and communication interface 318. In an embodiment, computer system 300 receives code for processing. The received code is executed by processor 304 as it is received, and / or stored in storage device 310, or other non-volatile storage for later execution.

[0077] Autonomous Vehicle Architecture

[0078] Figure 4 is an example of a method for AV (e.g., Figure 1 100). The architecture 400 includes a sensing module 402 (sometimes referred to as sensing circuitry), a planning module 404 (sometimes referred to as planning circuitry), a control module 406 (sometimes referred to as control circuitry), a positioning module 408 (sometimes referred to as positioning circuitry), and a database module 410 (sometimes referred to as database circuitry). Each module plays a role in the operation of the AV 100. Collectively, the modules 402, 404, 406, 408, and 410 may be Figure 1 4 is a portion of the AV system 120 shown. In an embodiment, any of the modules 402, 404, 406, 408, and 410 is a combination of computer software (e.g., executable code stored on a computer-readable medium) and computer hardware (e.g., at least one microprocessor, microcontroller, application specific integrated circuit [ASIC], hardware memory device, other type of integrated circuit, other type of computer hardware, or any or all of these hardware combinations).

[0079] In use, the planning module 404 receives data representing a destination 412 and determines data representing a trajectory 414 (sometimes referred to as a route) that the AV 100 may travel in order to reach (e.g., arrive at) the destination 412. In order for the planning module 404 to determine the data representing the trajectory 414, the planning module 404 receives data from the perception module 402, the positioning module 408, and the database module 410.

[0080] The perception module 402 uses, for example, Figure 1 At least one sensor 121 is shown to identify nearby physical objects. Objects are classified (e.g., grouped into types such as pedestrians, bicycles, cars, traffic signs, etc.), and a scene description including the classified objects 416 is provided to the planning module 404.

[0081] The planning module 404 also receives data representing the AV position 418 from the positioning module 408. The positioning module 408 determines the AV position by using the data from the sensor 121 and the data from the database module 410 (e.g., geographic data) to calculate the position. For example, the positioning module 408 uses the data from the GNSS unit and the geographic data to calculate the longitude and latitude of the AV. In an embodiment, the data used by the positioning module 408 includes a high-precision map with lane geometry attributes, a map describing the road network connection attributes, a map describing the physical attributes of the lane (such as traffic speed, traffic volume, the number of vehicles and bicycle lanes, lane width, lane traffic direction, or lane marking type and location, or a combination thereof), and a map describing the spatial location of road features (such as intersections, traffic signs or various types of other driving signals, etc.).

[0082] The control module 406 receives data representing the trajectory 414 and data representing the AV position 418, and operates control functions 420a-420c (e.g., steering, throttle, brakes, ignition) of the AV in a manner that will cause the AV 100 to travel the trajectory 414 to reach the destination 412. For example, if the trajectory 414 includes a left turn, the control module 406 will operate the control functions 420a-420c in the following manner: the steering angle of the steering function will cause the AV 100 to turn left, and the throttle and brakes will cause the AV 100 to pause and wait for a passing pedestrian or vehicle before making the turn.

[0083] Session key generation for AV operations

[0084] Figure 5 is a flow chart illustrating an example process for generating a session key for an AV operation according to at least one embodiment. Figure 1 The AV 100 illustrated and described in more detail is the same or similar. In an embodiment, Figure 5 The processing is performed by the vehicle service provider system. The vehicle service provider system and the reference Figure 7 The AV service provider system 704 illustrated and described in more detail may be the same or similar. In other embodiments, other entities (e.g., servers or computer systems) perform some or all elements of the processing. The server may be the same or similar to, for example, server 136, and the computer system may be the same or similar to, for example, computer system 300. It should be understood that Figure 5 The embodiment described is intended to be treated as an example, and other embodiments include different elements, more or fewer elements, or elements performed in a different order.

[0085] As used herein, a vehicle service provider system refers to a computer system that provides an AV for rent that is used by a single passenger or group of passengers for non-shared rides or for carpool (shared) rides. The vehicle service provider system is implemented using at least one processor (e.g., processor 304). The vehicle service provider system transports passengers in an AV between locations of the passenger's choice. In an embodiment, the vehicle service provider system rents AVs for short periods of time, typically ranging from a few hours to a few weeks. The vehicle service provider system serves passengers who need temporary transportation (e.g., passengers who do not own their own cars, travelers who are out of town, or owners of damaged or destroyed vehicles who are awaiting repairs or insurance compensation). In an embodiment, the vehicle service provider system rents autonomous vans or trucks for moving goods. Using reference Figure 3 The components of the example computer system 300 illustrated and described in greater detail implement a vehicle service provider system. In an embodiment, the vehicle service provider system functions as a ride-sharing provider for AVs, for example, a system that matches passengers with AVs for rental via a website and mobile app.

[0086] As described herein, a vehicle service subscriber system refers to a computer system that responds to communications from a vehicle service provider system in an AV associated with the vehicle service provider system in order to order a ride or provide an AV ride to a vehicle service subscriber. In an embodiment, the vehicle service subscriber system is the same as or similar to the AV service subscriber system 708. In an embodiment, an AV ride is ordered using a mobile app running on the vehicle service subscriber system. In an embodiment, the vehicle service subscriber system is part of a mobile device (such as a smart phone, laptop, tablet computer, or personal digital assistant, etc.) and is implemented using components of the example computer system 300. For example, a vehicle service subscriber (e.g., a mobile app or user) sets up a personal profile with a name, phone number, other information, or payment preferences on the vehicle service subscriber system.

[0087] In an alternative or additional embodiment, the vehicle service provider is a sensor such as one of the sensors 121. The vehicle service subscriber system is a high performance computing node (or a task running thereon) that uses the data provided by the sensor. An example of such a computing node is processor 304. In this embodiment, the session keys described herein will be used to protect messages or data passed between the sensor and the processor. In other embodiments, the vehicle service provider system and the vehicle service subscriber system may be other vehicle-mounted systems or elements as described herein with reference to other figures.

[0088] In an embodiment, the vehicle service subscriber system is part of the AV system (e.g., AV system 120) and is implemented using, for example, processor 146. For example, in one embodiment, the vehicle service subscriber is a software client running on the vehicle service subscriber system or the AV system. Thus, the vehicle service provider system communicates with the vehicle service subscriber system built into the AV system so that the AV is operated using commands or messages sent by the vehicle service provider system to the vehicle service subscriber system.

[0089] For secure communication between the vehicle service provider system and the vehicle service subscriber system group, protected messages are used for message exchange. The protected messages can be, for example, black channel messages. The embodiments of this document will be described with reference to the specific example of black channel messages, however, it should be understood that other embodiments may include different types of encryption or protection protocols.

[0090] Using black channel messaging, safety-related data as well as diagnostic information are exchanged via an existing network connection (e.g., local network 322 or Internet 328). The vehicle service provider system broadcasts a salt to one or more vehicle service subscriber systems to generate a session key for a communication session. As described above, "salt" refers to random or pseudo-random data generated by the vehicle service provider system and used by each vehicle service subscriber system to calculate a session key. For example, a vehicle service subscriber system uses a salt as an input to a function that hashes pre-shared data (such as a key, data, password, or passphrase, etc.).

[0091] The session key is used to authenticate, decode or decrypt protected (e.g., black channel) messages transmitted between the vehicle service provider system and the vehicle service subscriber system. Black channel messages are used to provide rides to passengers (vehicle service subscribers) in an AV associated with the vehicle service provider system. For example, a black channel message includes geographic data related to the origin of the AV ride, geographic data related to the destination of the AV ride, the number of passengers on the AV ride, the amount of luggage the AV will carry, carpooling details, route details, information about the make and model of the AV, the identity of the passenger, or the rate data of the AV. As previously described, such messages include one or more of sensor data, vehicle diagnostic data, vehicle commands, vehicle status data, or some other type of data.

[0092] The embodiments disclosed herein prevent replay attacks by malicious entities by enabling each vehicle service subscriber system to generate and contribute entropy to salt. A replay attack refers to a network attack in which a valid data transmission (e.g., a black channel message or a salt message) is maliciously or deceptively repeated or delayed by a malicious entity. For example, a malicious entity that intercepts a black channel message intended for a vehicle service subscriber system can initiate a replay attack using the black channel message as part of a spoofing attack for IP packet replacement. The embodiments disclosed herein use entropy to prevent such attacks, and also enable the vehicle service subscriber system and the vehicle service provider system to calculate the same session key for the communication session, thereby avoiding excessive computational load. The embodiments can provide additional benefits such as anti-spoofing, anti-tampering, etc.

[0093] refer to Figure 5 , a vehicle service provider system generates (500) a salt for encrypting a session key for a communication session with at least one vehicle service subscriber system. The salt includes random bits that are added to an instance of a password (e.g., a session key) before the password is hashed. In additional or alternative embodiments, the salt includes pre-shared data known to both the vehicle service provider system and the vehicle service subscriber system. In an embodiment, the vehicle service provider system selects the salt from an entropy pool. In one embodiment, entropy refers to an average level of information inherent in the possible values ​​of a random variable. In another embodiment, entropy refers to a collection of random data (e.g., a mixture of random data from various sources). For example, entropy represents a mathematical limit on the lossless compression of data onto a noiseless channel. The salt is used to create a unique password even when the vehicle service provider system and the respective vehicle service subscriber systems use the same pre-shared data.

[0094] One advantage of the embodiments disclosed herein is that the embodiments allow different subscribers and publishers to agree on unique keys for different sessions (e.g., guidance of a vehicle or when a vehicle provides a ride to an occupant) starting with only pre-shared data. Another advantage of the embodiments disclosed herein is preventing rainbow table attacks by forcing malicious entities to recalculate session keys using salt. A rainbow table attack is a type of hacker attack in which a perpetrator attempts to crack passwords stored in a database system using a rainbow hash table.

[0095] The vehicle service provider system uses salt to calculate the session key (504). In an embodiment, the session key is calculated using a hashed key derivation function (HKDF), an input key content (IKM) and salt. For example, the session key is determined using HKDF based on a hash message authentication code (HMAC). The session key is an encryption and decryption key that is randomly calculated to ensure the security of the communication session between the vehicle service provider system and each vehicle service subscriber system. The session key is sometimes referred to as a symmetric key because the same key is used to encrypt and decrypt black channel messages transmitted between the vehicle service provider system and each vehicle service subscriber system. HKDF is a key derivation function (KDF) based on HMAC. HKDF is used as a building block in various protocols and applications, and also prevents the proliferation of multiple KDF mechanisms. HMAC is a message authentication code (MAC) involving a type of cryptographic hash function and a secret encryption key (e.g., salt). In an embodiment, IKM (which is a cryptographically strong pseudo-random string) is used to extract a fixed-length pseudo-random key. The fixed-length pseudo-random key is expanded into several additional pseudo-random keys (output of HKDF), as expressed in the following equation (1):

[0096] Session key = [HKDF (IKM, salt)] (1)

[0097] The vehicle service provider system initializes (508) its protected message (e.g., black channel) sender using the session key so that the black channel sender is ready to send black channel messages to the vehicle service subscriber system to schedule and provide rides in an AV to users of the vehicle service subscriber system. The black channel sender is part of the vehicle service provider system and uses the reference Figure 3 The components of the example computer system 300 illustrated and described in more detail are implemented. The vehicle service provider system begins broadcasting a black channel protected message to the vehicle service subscriber system. A salt message containing a salt generated or selected at startup is broadcast periodically.

[0098] In an embodiment, the vehicle service provider system broadcasts a first one or more black channel protected messages to a group of vehicle service subscriber systems so that one or more vehicle service subscriber systems of the group authenticate the black channel message and its session key. After authenticating the session key and the first one or more black channel protected messages, each next black channel message is sent from the vehicle service provider system to the corresponding vehicle service subscriber system to which the black channel message is directed. Such black channel messages carry confidential or protected information about a specific AV ride associated with the corresponding vehicle service subscriber system. For example, a black channel message includes details of the ride destination, ride time, passenger identity, route information, or number of passengers.

[0099] The vehicle service provider system broadcasts (512) the salt it generated or selected in element 500 to the vehicle service subscriber system to inform the vehicle service subscriber system of the salt. For example, the salt is sent within a salt message that contains other metadata. An example salt message is represented as:

[0100] Salt Message

[0101] {

[0102] salt

[0103] }

[0104] New vehicle service subscriber systems that join the session receive the salt in this manner. The vehicle service provider system uses a timer to periodically rebroadcast (516) the salt so that the new vehicle service subscriber systems that join receive the salt. In an embodiment, the timer is an electronic timer, such as a quartz timer with digital electronics, an integrated circuit timer, a software timer, or a programmable logic controller (PLC) with ladder logic, etc. Each vehicle service subscriber system uses the salt to calculate a session key in the same manner as described for the vehicle service provider system in element 504. The session key is used to decode or decrypt black channel messages from the vehicle service provider system to provide a ride in one or more AVs associated with the vehicle service provider system.

[0105] Figure 6 is a flow chart illustrating an example process for session key generation for AV operations according to at least one embodiment. Figure 1 The AV 100 illustrated and described in more detail is the same or similar. In an embodiment, Figure 6 The processing is performed by a vehicle service subscriber system in the vehicle service subscriber system group. The vehicle service subscriber system is the same as or similar to the AV service subscriber system 708. The vehicle service subscriber system is implemented using at least one processor (eg, processor 304).

[0106] In other embodiments, other entities (e.g., a server (e.g., server 136), a computer system (e.g., computer system 300), a mobile device, or an AV system (e.g., AV system 120)) perform some or all elements of the processing. It will be appreciated that Figure 6 The techniques described are intended as example techniques, and other embodiments include more or fewer elements, elements in a different order than depicted, and so forth.

[0107] In an embodiment, the maximum number of vehicle service subscriber systems allowed to join a service session managed by the vehicle service provider system is limited to a threshold number of vehicle service subscriber systems specified by the vehicle service provider system. For example, the size of the vehicle service subscriber system group in a service session with the vehicle service provider system is limited to 10, 25, 50, 100, etc. The threshold number of vehicle service subscriber systems specified by the vehicle service provider system provides improved communication latency, reduced amount of transmitted data, and reduced computational load, particularly when the vehicle service provider system is calculating a new salt from entropy contributed by several different vehicle service subscriber systems in the vehicle service subscriber system group.

[0108] At startup, when the vehicle service subscriber system joins a session with the vehicle service provider system, the vehicle service subscriber system waits 604 to receive a salt message and salt from the vehicle service provider system. The vehicle service provider system is the same or similar to the AV service provider system 704 and is implemented using at least one processor such as processor 304.

[0109] The salt will eventually be used by the vehicle service subscriber system to compute a session key for the session so that the vehicle service subscriber system can authenticate and decode (or decrypt) the black channel message from the vehicle service provider system to provide a ride to the passenger in the AV provided by the vehicle service provider system. The vehicle service provider system broadcasts the next salt message containing the salt, as referenced in Figure 5 The elements 500 in are illustrated and described in more detail in FIG. The vehicle service subscriber system receives ( 608 ) the broadcast salt in the salt message from the vehicle service provider system.

[0110] The vehicle service subscriber system uses the IKM and the salt to calculate (612) the session key for the session, similar to that described in reference Figure 5 Element 504 performed by a vehicle service provider system is illustrated and described in more detail. The vehicle service subscriber system initializes its protected message (e.g., black channel) receiver using a session key. The black channel receiver is part of the vehicle service subscriber system and is implemented using components of the example computer system 300. The black channel receiver is used to receive a black channel message from the vehicle service provider system to schedule a ride in an AV provided by the vehicle service provider system. The vehicle service provider system broadcasts at least one black channel message to the group of vehicle service subscriber systems.

[0111] To verify that the salt and session key are correct and are correctly received and generated / calculated, the vehicle service subscriber system attempts to authenticate the black channel message using the session key. If the authentication of the black channel message using the session key is successful, the vehicle service subscriber system has the correct session key. The vehicle service subscriber system consumes the black channel message and ignores future salt messages it receives during the session. Therefore, the vehicle service subscriber system terminates (616) monitoring the salt message. On the other hand, if the authentication of the black channel message using the session key fails, the vehicle service subscriber system discards the black channel message.

[0112] To authenticate the black channel message, the vehicle service subscriber system verifies the data source of the black channel message and that the black channel message has not been modified in transit. In an embodiment, the vehicle service subscriber system uses MAC, authenticated encryption (AE) or digital signature for authentication. MAC or digital authenticator is used as a salt-based integrity check. MAC is based on the use of cryptographic hashing or symmetric encryption.

[0113] Upon receiving a new black channel message, the vehicle service subscriber system again verifies that the salt and session key are correct by attempting to authenticate the new black channel message using the session key. If the black channel message authentication fails but the vehicle service subscriber system receives a new salt message with a different salt, the vehicle service subscriber system calculates (612) a new session key for the session using the IKM and the new salt, similar to the example described in reference to FIG. Figure 5 Element 504 used by the vehicle service provider system is illustrated and described in greater detail. To verify that the new salt and new session key are correct, the vehicle service subscriber system attempts to authenticate at least one black channel message using the new session key.

[0114] If authentication of the black channel message using the new session key is successful, the vehicle service subscriber system has the correct session key for the session. The vehicle service subscriber system consumes the black channel message and ignores future salt messages it receives during the session. Therefore, the vehicle service subscriber system terminates (616) monitoring additional salt messages. The salt remains unchanged throughout the life of the session, so the vehicle service subscriber system stops monitoring the salt message after successfully authenticating the black channel protected message. The vehicle service subscriber system does not become desynchronized with the vehicle service provider system, and the same session key is used to authenticate black channel messages from the vehicle service provider system for the duration of the session.

[0115] Figure 7is a timing diagram illustrating an example process for session key generation and authentication for AV operation according to at least one embodiment. At least one AV operating using the process is the same as or similar to the AV. In an embodiment, Figure 7 The processing is performed by the AV service provider system 704 and the AV service subscriber system 708. Figure 5 The AV service provider system 704 is described in further detail. The AV service provider system 704 is implemented using at least one processor (eg, example processor 304).

[0116] AV service subscriber system 708 is one of a group of vehicle service subscriber systems and refers to Figure 5 AV service subscriber system 708 is implemented using at least one processor. The processor and reference Figure 3 The processor 304 illustrated and described in more detail is the same or similar. In other embodiments, other entities (e.g., a server (e.g., server 136), a computer system (e.g., computer system 300), a mobile device, or an AV system (e.g., AV system 120)) perform some or all elements of the processing. As described above, other embodiments include more, fewer, or different elements, or elements performed in a different order than that depicted.

[0117] In element 712, the AV service provider system 704 generates a salt. For example, as referenced Figure 5 As illustrated and described in more detail, the AV service provider system 704 selects a salt from an entropy pool. Figure 5 As illustrated and described in more detail, the AV service provider system 704 calculates a session key using the IKM and the salt using HKDF. The session key may be adjusted based on the hashing algorithm used and the implementation of the hashing algorithm. The AV service provider system 704 initializes its black channel transmitter using the session key and broadcasts (716) at least one black channel message to the vehicle service subscriber system group.

[0118] In element 720, the AV service subscriber system 708 receives the black channel message, but determines that it has not yet received the salt or calculated the session key for the session. The AV service subscriber system 708 discards the black channel message and does not attempt to authenticate the black channel message. Figure 6, the AV service subscriber system 708 continues to wait for a salt message from the vehicle service provider system. In element 724, the AV service provider system 704 broadcasts a salt message to the vehicle service subscriber system group, the salt message containing the salt previously generated in element 712. The AV service subscriber system 708 receives the salt. The salt message is broadcast periodically by the AV service provider system 704 to allow subsequent and regenerated vehicle service subscriber systems to synchronize with the AV service provider system 704.

[0119] In element 728, the AV service subscriber system 708 calculates a session key using the salt and the IKM, similar to the process performed by the AV service provider system 704 in element 712. The AV service provider system 704 broadcasts (732) a new black channel message to the vehicle service subscriber system group, which is received by the AV service subscriber system 708. The AV service subscriber system 708 authenticates (736) the new black channel message using the calculated session key and stops monitoring for additional salt messages. The AV service subscriber system 708 decodes or decrypts subsequent black channel messages using the session key to provide a ride to the passenger in the AV provided by the AV service provider system 704.

[0120] The frequency of salt message broadcasts is adjusted based on at least one consideration. In an embodiment, the first frequency at which the AV service provider system 704 sends black channel messages is greater than or equal to the second frequency at which the salt messages are sent. The frequency of salt message broadcasts determines the delay experienced by the vehicle service subscriber system at startup. Therefore, a higher frequency of salt message broadcasts is desired, and the frequency of the salt message broadcasts is weighed against network overhead. In addition, in a first implementation, there will be more black channel protected messages than salt messages. However, in a second implementation, there may be more salt messages than black channel messages. The vehicle service subscriber system successfully authenticates at least one black channel protected message to confirm that it has correctly calculated the session key. Therefore, the minimum ratio of black channel protected messages to salt messages should be at least 1:1 to allow authentication checks to occur quickly.

[0121] Figure 8 is a flow chart illustrating an example process for session key generation for AV operations according to at least one embodiment. Figure 1 The AV 100 illustrated and described in more detail is the same or similar. In an embodiment, Figure 8The processing is performed by a vehicle service provider system. The vehicle service provider system is the same as or similar to the AV service provider system 704. In other embodiments, other entities (e.g., a server (e.g., server 136) or a computer system (e.g., computer system 300)) perform some or all elements of the processing. Likewise, embodiments may include different, fewer, or additional elements, or perform these elements in a different order.

[0122] In element 804, the vehicle service provider system generates a first salt for encrypting a session key for a communication session with at least one vehicle service subscriber system. In an embodiment, the vehicle service subscriber system is the same as or similar to the AV service subscriber system 708. The vehicle service subscriber system is implemented using at least one processor (e.g., example processor 304). In other embodiments, other entities (e.g., a mobile device or an AV system) perform some or all elements of the processing. The AV system is the same as or similar to the AV system 120. Likewise, embodiments may include different and / or additional elements, or perform these elements in a different order.

[0123] In an embodiment, the vehicle service provider system selects a first salt from the entropy pool and uses the first salt to calculate one or more session keys. The vehicle service provider system initializes its black channel transmitter using the session key so that the black channel transmitter is ready to send black channel messages to the group of vehicle service subscriber systems to schedule and provide rides in AVs to users of the vehicle service subscriber systems. The vehicle service provider system then broadcasts the black channel protected message to the vehicle service subscriber systems.

[0124] Periodically broadcast (808) a salt message containing a first salt generated or selected at startup. For example, the vehicle service provider system uses a timer to periodically rebroadcast (812) the first salt. In an embodiment, the timer is an electronic timer, such as a quartz timer with digital electronics, an integrated circuit timer, a software timer, or a PLC with ladder logic. The vehicle service provider system can additionally calculate (814) a session key, for example, in a manner similar to that described above with respect to element 504.

[0125] In an embodiment, a key update of a set of vehicle service provider systems and a vehicle service subscriber system group is triggered. For example, a key update is triggered periodically or in response to an event within the system (e.g., a vehicle service subscriber system request for a new ride in an AV supplied by the vehicle service provider system or the start of a new ride in the AV). When a key update is required, the vehicle service provider system generates (816) a new (second) salt, and thus generates a corresponding second session key, and notifies (820) the vehicle service subscriber system group of the change. When a key update is performed, the black channel receiver of the vehicle service subscriber system group and the black channel transmitter of the vehicle service provider system are reinitialized with the second session key, and the black channel message sequence counter is reset to 0. The black channel receiver and the black channel transmitter are kept synchronized so that no black channel messages are discarded during the session key conversion.

[0126] In an embodiment, the vehicle service provider system initiates a key update for a session by sending a salt update message containing entropy generated by the vehicle service provider system. For example, if the vehicle service subscriber system has not initiated a key update or contributed entropy within a threshold amount of time, the vehicle service provider system initiates a key update. The threshold amount of time is a few seconds to a few minutes. In an embodiment, the vehicle service provider system initiates key updates periodically. The periodic key update interval is longer than the periodic salt message broadcast interval to prevent the vehicle service subscriber system group from losing the opportunity to send synchronization messages. For example, the vehicle service provider system uses a timer (such as a quartz timer with digital electronics, an integrated circuit timer, a software timer, or a PLC with ladder logic, etc.) to periodically initiate key updates.

[0127] If a malicious entity attempts to force a key update by submitting a synchronization request, the embodiments disclosed herein use an adjustable time interval between salt messages and salt update messages to prevent this. For example, after broadcasting a salt update, the vehicle service provider system increases the frequency of salt messages within a threshold time period. The increase in the frequency of salt messages provides an opportunity for the group of vehicle service subscriber systems to resynchronize with the vehicle service provider system. In an embodiment, the threshold time period is from a few seconds to a few minutes. In an embodiment, the vehicle service provider system broadcasts salt update messages at a higher frequency than salt messages. The increase in the update frequency increases the number of retransmissions of salt update messages and reduces the number of vehicle service subscriber systems that fail to receive at least one update, thereby enhancing the security of the system.

[0128] In element 820, the vehicle service provider system broadcasts a salt update message including the second salt to the vehicle service subscriber system group. Salt update messages are sometimes referred to as "updates". For example, a salt update message is represented as:

[0129] Salt Update Message

[0130] {

[0131] valid through

[0132] second salt

[0133] }

[0134] In an embodiment, the vehicle service provider system monitors a timer associated with the duration of broadcasting the first salt. For example, the duration of broadcasting the first salt is in the range of a few milliseconds to a few seconds. In an embodiment, the timer is an electronic timer, such as a quartz timer with digital electronics, an integrated circuit timer, a software timer, or a PLC with ladder logic. In response to the timer expiring, an update is broadcast to the vehicle service subscriber system group.

[0135] The salt update message has at least two fields. In an embodiment, the value of "valid through" is the sequence number of the last black channel protected message protected by the current session key (derived from the first salt). The value of "secondsalt" is the new salt that will be used next. The value of the second salt can be adjusted using different hash algorithms or different implementations of the hash function. In an embodiment, the value of "valid through" is a specific time before an incoming black channel protected message will be protected by the current session key (derived from the first salt).

[0136] In element 824, the carrier service provider system rebroadcasts the salt update. When a salt update is scheduled, the carrier service provider system selects (820) an appropriate value for "valid through" and extracts (816) a new salt from its entropy pool. The carrier service provider system begins to periodically rebroadcast (824) salt update messages instead of salt messages. For example, Figure 8 As shown, the timer is used to periodically rebroadcast the salt update message. In an embodiment, the timer is an electronic timer, such as a quartz timer with digital electronic devices, an integrated circuit timer, a software timer, or a PLC with ladder logic.

[0137] At a selected time when "valid through" expires, the carrier service provider system calculates (828) a second (new) session key and returns to 816. In this manner, a seamless transition to a new session key can be achieved without discarding messages.

[0138] In an embodiment where a new vehicle service subscriber system joins a vehicle service subscriber system group, for example to request a new ride, the new vehicle service subscriber system waits (820) while an update has been scheduled for broadcast. For example, the new vehicle service subscriber system waits for the update at 820 or 824 to complete and for the new salt to become valid. The new vehicle service subscriber system then calculates (828) a session key using the new salt and attempts to authenticate a black channel protected message to confirm that the calculated session key is correct. In an embodiment, the value of "valid through" is adjusted so that a slower-reacting vehicle service subscriber system has enough time to process the salt update message and calculate a new session key before the update occurs.

[0139] Fig. 9 1 is a timing diagram illustrating an example process for session key generation for AV operation according to at least one embodiment. At least one AV operating using this process is the same as or similar to AV 100. In an embodiment, Fig. 9 The processing is performed by the AV service provider system 704 implemented using at least one processor (eg, the processor 304).

[0140] AV service subscriber system 708 is one of a group of vehicle service subscriber systems as described herein and is implemented using at least one processor, such as processor 304. In other embodiments, other entities, such as servers (e.g., server 136), computer systems (e.g., computer system 300), mobile devices, or AV systems (e.g., AV system 120), perform some or all elements of the processing. Additionally, embodiments may include different, more, or fewer elements than depicted, or elements that appear in an order different from that depicted.

[0141] The AV service provider system 704 generates a first salt S. For example, the AV service provider system 704 generates the first salt S as a vector of pseudo-random values, or as described in reference Figure 5 The first salt S is selected from the entropy pool as exemplified and described in more detail. Figure 5As illustrated and described in more detail, the AV service provider system 704 calculates a session key using the IKM and the first salt S through HKDF. The AV service provider system 704 initializes its black channel transmitter using the session key and broadcasts the first salt S in a salt message to the group of vehicle service subscriber systems. The AV service subscriber system 708 receives the first salt S and calculates a session key from the first salt S in a manner similar to that used by the AV service provider system 704. The AV service subscriber system 708 initializes its black channel receiver using the session key.

[0142] The AV service provider system 704 uses its black channel transmitter to broadcast a black channel message X to the vehicle service subscriber system group. The AV service subscriber system 708 uses its black channel receiver to receive the black channel message X. In order to determine whether it has the correct salt and session key, the AV service subscriber system 708 attempts to authenticate the black channel message X using the session key in element 904. The black channel message X is correctly authenticated. In order to provide additional security, the embodiments disclosed herein are designed so that the AV service provider system 704 broadcasts at least one salt update message between changes in the salt. In order to signal a potential network attack, an error condition is triggered when the vehicle service subscriber system receives two sequential salt messages with different content without an intermediate salt update message. For example, in element 908, the AV service subscriber system 708 receives a salt message with a second salt S' from the AV service provider system 704. Since there is no update between element 904 and element 908, an error is signaled and the second salt S' is ignored.

[0143] To determine the cause of the error condition, the AV service subscriber system 708 examines additional black channel protected messages received from the AV service provider system 704 in element 912. The AV service provider system 704 broadcasts a black channel message X+1, which is received by the AV service subscriber system 708. In element 912, the AV service subscriber system 708 correctly authenticates the black channel message X+1 using the session key derived from the first salt S. Next, the AV service provider system 704 broadcasts a black channel message X+2, which the AV service subscriber system 708 receives. In element 916, the AV service subscriber system 708 correctly authenticates the black channel message X+2 using the session key derived from the first salt S. Since the black channel messages X+1 and X+2 continue to authenticate correctly, the erroneous second salt S' is discarded. The AV service subscriber system 708 sends a message or alert to the AV service provider system 704 or central server, notifying the AV service provider system 704 or central server of the erroneous second salt S' and alerting of potential tampering of the salt or potential replay attack by a malicious entity.

[0144] Fig.10 is a timing diagram illustrating an example process for session key generation for AV operation according to at least one embodiment. At least one AV operating using this process is the same as or similar to AV 100. In an embodiment, as described above, Fig.10 The processing is performed by the AV service provider system 704 and the AV service subscriber system 708. In an embodiment, the AV service provider system 704 is implemented using at least one processor (eg, the example processor 304).

[0145] AV service subscriber system 708 is one of the vehicle service subscriber system group as described above, and is implemented using at least one processor, such as processor 304. In other embodiments, other entities (e.g., a server (e.g., server 136), a computer system (e.g., computer system 300), a mobile device, or an AV system (e.g., AV system 120)) perform some or all elements of the process. Additionally, other embodiments include more, fewer, or different elements, elements performed in a different order than depicted, etc.

[0146] The AV service provider system 704 generates a first salt S. For example, as shown in FIG. Figure 5 As illustrated and described in more detail, the AV service provider system 704 selects a first salt S from the entropy pool. Figure 5As illustrated and described in more detail, the AV service provider system 704 calculates a session key using the IKM and the first salt S through HKDF. The AV service provider system 704 initializes its black channel transmitter using the session key and broadcasts the first salt S to the group of vehicle service subscriber systems in a salt message. The AV service subscriber system 708 receives the first salt S and calculates a session key from the first salt S in a manner similar to that used by the AV service provider system 704. The AV service subscriber system 708 initializes its black channel receiver using the session key.

[0147] The AV service provider system 704 uses its black channel transmitter to broadcast a first black channel message X to the vehicle service subscriber system group. The AV service subscriber system 708 uses its black channel receiver to receive the first black channel message X. To determine whether it has the correct salt and session key, the AV service subscriber system 708 attempts to use the session key to authenticate the first black channel message X in element 1004. The first black channel message X is correctly authenticated.

[0148] In an embodiment, the AV service subscriber system 708 receives a second salt S' from the AV service provider system 704. The salt message including the second salt S' indicates that there is no scheduled salt update associated with the second salt S'. The AV service subscriber system 708 sends a replay warning message to the AV service provider system 704 indicating a possible replay attack. For example, the AV service provider system 704 broadcasts an update with the second salt S' to the group of vehicle service subscriber systems. However, in element 1008, the AV service subscriber system 708 misses receiving the update due to a failure in the network, a power outage, other reasons for packets being dropped, or a combination thereof.

[0149] The AV service provider system 704 uses its black channel transmitter to broadcast a second black channel message X+1 to the vehicle service subscriber system group. The AV service subscriber system 708 uses its black channel receiver to receive the second black channel message X+1. In element 1012, the AV service subscriber system 708 successfully authenticates the second black channel message X+1 using a session key based on the first salt S (because the AV service subscriber system 708 is unaware of the existence of a salt update). In an embodiment, the AV service provider system 704 monitors a timer associated with the duration of the broadcast update. After the timer expires, the black channel message sequence counter is set to 0, and the AV service provider system 704 broadcasts the next black channel message 0. In order to decrypt the black channel message 0, a new session key generated using the second salt S' is required. However, the AV service subscriber system 708 still uses the set of previous session keys calculated using the first salt S.

[0150] The AV service subscriber system 708 receives the black channel message 0 using its black channel receiver. In element 1016, the AV service subscriber system 708 attempts to authenticate the black channel message 0 using the session key calculated based on the first salt S'. Authentication failed. In an embodiment, the AV service provider system 704 monitors a timer associated with the duration of the broadcast update. The AV service provider system 704 broadcasts a salt message with a second salt S in response to the expiration of the timer. Since the AV service subscriber system 708 receives the second salt S' after receiving the first salt S without receiving an intermediate update, at 1020, the AV service subscriber system 708 is desynchronized with the AV service provider system 704. The AV service provider system 704 sends a replay warning message indicating a possible replay attack to the AV service provider system 704. Therefore, in the case of a discarded or lost salt update message as in element 1008, the black channel protected message is no longer correctly authenticated (element 1016). The AV service subscriber system 708 needs to resynchronize with the AV service provider system 704.

[0151] Fig.11 1 is a flow chart illustrating an example process for session key generation for AV operation according to at least one embodiment. At least one AV operating using this process is the same as or similar to AV 100. In an embodiment, Fig.11 The processing is performed by a vehicle service provider system that is the same as or similar to the AV service provider system 704. In other embodiments, other entities (e.g., a server (e.g., server 136) or a computer system (e.g., computer system 300)) perform some or all elements of the processing. It should be understood that other embodiments include more, fewer, or different elements, or elements in a different order than depicted herein.

[0152] In element 1100, a vehicle service provider system (e.g., an AV service subscriber system 708 implemented using at least one processor such as processor 304) generates a first salt for encrypting a session key for a communication session with at least one vehicle service subscriber system. The vehicle service subscriber system is one of a group of vehicle service subscriber systems. In other embodiments, other entities (e.g., a mobile device or an AV system (e.g., AV system 120)) perform some or all elements of the process.

[0153] In an embodiment, the vehicle service provider system selects a first salt from the entropy pool. The vehicle service provider system calculates a session key using the first salt. The vehicle service provider system initializes its black channel sender using the session key so that the black channel sender is ready to send black channel messages to the vehicle service subscriber system group to dispatch and provide rides in AVs to users of the vehicle service subscriber systems.

[0154] In an embodiment, a vehicle service provider system broadcasts a first salt to at least one vehicle service subscriber system associated with a vehicle service subscriber. The vehicle service subscriber is a user of the vehicle service subscriber system or a software client running on the vehicle service subscriber system. The vehicle service provider system is associated with at least one vehicle (e.g., AV 100). The vehicle service provider system starts a timer associated with a duration for broadcasting the first salt to the group of vehicle service subscriber systems within a salt message. In response to the expiration of the timer, the vehicle service provider system broadcasts (1104) a salt message containing the first salt generated or selected at the time of startup. The timer associated with the duration for broadcasting the first salt is reset, and the vehicle service provider system periodically rebroadcasts (1104) a salt message containing the first salt when the timer expires. For example, the timer is an electronic timer, such as a quartz timer with digital electronics, an integrated circuit timer, a software timer, or a PLC with ladder logic.

[0155] The embodiments described herein use entropy generated by each vehicle service subscriber system in the vehicle service subscriber system group to update salt to enhance the security benefits of HKDF. Therefore, the sensitivity of the system to entropy weaknesses at the vehicle service provider system is avoided. The vulnerability of the vehicle service subscriber system group to replay attacks is also prevented. The embodiments also prevent the vulnerability of the vehicle service subscriber system before it authenticates its first black channel protected message and the session key is "locked" and when a key update occurs. The entropy contributed by the vehicle service subscriber system is carried forward in the remainder of the session.

[0156] In an embodiment, a vehicle service provider system receives a synchronization message from a vehicle service subscriber system in a vehicle service subscriber system group. The synchronization message includes entropy generated by the vehicle service subscriber system. Entropy is generated by the vehicle service subscriber system independently of the vehicle service provider system and independently of a different entropy pool of the vehicle service provider system. Entropy is a random value (integer or floating point), a pseudo-random value, a digital vector of randomly generated bits, or a combination thereof. The synchronization message is generated by the vehicle service subscriber system to contribute entropy to the next salt update. The synchronization message is represented as follows:

[0157] Synchronization Message

[0158] {

[0159] entropy

[0160] last salt

[0161] }

[0162] The entropy value is adjusted by the vehicle service subscriber system using different hash algorithms and hash implementations. In an embodiment, the "entropy" field in the synchronization message is a random number drawn by the vehicle service subscriber system from its own entropy pool. "Last salt" refers to the salt value of the last salt message received from the vehicle service subscriber system. For example, "last salt" is the first salt generated by the vehicle service provider system in element 1100. In an embodiment, the vehicle service provider system enhances security by verifying that the "last salt" field of the synchronization message is valid. To be valid, the "last salt" field value of the synchronization message should match the current salt (e.g., the first salt) of the vehicle service provider system. If the verification is successful, the vehicle service provider system processes the synchronization message.

[0163] In an embodiment, the vehicle service provider system determines that the result of the hash-based message authentication performed on the first salt does not match the "last salt" received from the vehicle service subscriber system in the synchronization message. In response to determining that the result does not match the "last salt", the vehicle service provider system determines an indication of a possible denial of service (DoS) attack. For example, to prevent a malicious entity from flooding the vehicle service subscriber system group with synchronization messages and triggering a large number of session key recalculations, thereby causing a DoS attack on the availability of the central processing unit (CPU) at the vehicle service provider system and the vehicle service subscriber system group, the content of the "last salt" field is adjusted as in equation (2):

[0164] Final salt = HMAC[Kss, current salt||entropy] (2)

[0165] Here, Kss represents the encrypted session key, which is determined by the carrier service provider system (using an open, forward-looking heuristic) assuming that the current salt (e.g., the first salt generated by the carrier service provider system) is trustworthy. Therefore, the key Kss is determined using equation (3):

[0166] Kss=HKDF(salt,IKM)* (3)

[0167] When the vehicle service provider system receives the synchronization message, the vehicle service provider system uses the entropy provided by the vehicle service subscriber system and a copy of the vehicle service provider system's current salt (e.g., first salt) to perform the same HMAC determination as the vehicle service subscriber system. The vehicle service provider system compares the result of the HMAC with the "last salt" received from the vehicle service subscriber system. If the validation check succeeds, the vehicle service provider system moves to element 1108. If the validation check fails, the vehicle service provider system discards the synchronization message and signals a potential DoS attack or irregularity. In an embodiment, if there is a key reuse issue, a different IKM is used to avoid key duplication.

[0168] In an embodiment, the vehicle service provider system generates a second salt based on the first salt and the entropy received from the vehicle service subscriber system. For example, the vehicle service provider system extends (1108) the first salt by concatenating the current salt (e.g., the first salt) and the entropy from the received synchronization message. In an embodiment, generating the second salt includes performing an HMAC by the vehicle service provider system on the concatenation of the first salt and the entropy. For example, the concatenated data is passed through a hash algorithm to produce a value for the second salt. For example, the second salt is generated as in equation (4):

[0169] Second salt = Hash[current salt||entropy] (4)

[0170] In an embodiment, information identifying the vehicle service provider system (such as a name, identification number, or IP address, etc.) is included in the concatenated data to enhance data security.

[0171] The vehicle service provider system calculates (1112) a session key based on the second salt. In an embodiment, as shown in FIG. Figure 5 As illustrated and described in more detail, a session key is calculated using HKDF, IKM, and a second salt. For example, an HMAC-based HKDF is used to determine the session key. In an embodiment, the vehicle service provider system sets a timer after receiving a synchronization message, and a second salt is generated by the vehicle service provider system when the timer expires. When the second salt is generated, the vehicle service provider system reinitializes its black channel transmitter context using a session key derived from the second salt. In an embodiment that further improves security, before generating the session key, the vehicle service provider system verifies that a hash-based message authentication of a concatenation of a "last salt" and entropy from a vehicle service subscriber system matches the second salt. In response to a verification failure, the vehicle service provider system signals a potential DoS attack or irregularity.

[0172] The vehicle service provider system broadcasts (1116) an update to the vehicle service subscriber system group. The update includes a second salt for decrypting a black channel message using the session key. The black channel message is used to provide a ride in at least one vehicle associated with the vehicle service provider system. In an embodiment, the vehicle service provider system broadcasts an extended salt update message. The salt update message is extended to accommodate at least one entropy contribution received from the vehicle service subscriber system group as part of a synchronization message. For example, the extended update is represented as follows:

[0173] Salt Update Message

[0174] {

[0175] second salt

[0176] entropy

[0177] }

[0178] The "entropy" field in the extended update represents the entropy contributed by at least one vehicle service subscriber system. In an embodiment, security is further improved by enhancing salt generation to prevent attackers from crafting salt update messages and potentially causing a DoS attack on the group of vehicle service subscriber systems. Salt generation is enhanced by replacing cryptographic hashes with HMAC to prevent attackers from forging salt update messages.

[0179] The enhanced salt generation is performed as in equation (5):

[0180] Second salt = HMAC[Kns, current salt||entropy] (5)

[0181] The key Kns is determined under the assumption that the current salt (e.g., the first salt) is authentic. Therefore, the key Kns is determined using equation (6):

[0182] Kns=HKDF(Salt,IKM) (6)

[0183] In an embodiment, the key reuse problem is avoided by using different IKMs.

[0184] The carrier service provider system periodically rebroadcasts (1116) salt update messages. For example, as referenced Figure 8 As illustrated and described in more detail, a timer is used to periodically rebroadcast the salt update message. In an embodiment, the salt update message is broadcast (1116) at an interval controlled by the timer and is repeated a maximum number N times. In an embodiment, the timer is an electronic timer, such as a quartz timer with digital electronics, an integrated circuit timer, a software timer, or a PLC with ladder logic. The vehicle service provider system returns to element 1104 to broadcast a second salt to the vehicle service subscriber system group to provide a ride in at least one vehicle associated with the vehicle service provider system.

[0185] In an embodiment, the vehicle service provider system uses its calculated session key to encrypt the black channel message. Figure 7As illustrated and described in more detail, the vehicle service provider system sends a black channel message to at least one vehicle service subscriber system in the vehicle service subscriber system group. In an embodiment, the black channel protects any black channel message broadcast after generating (1108) the second salt using a new session key.

[0186] In an embodiment, the entropy described is a first entropy generated by a first vehicle service subscriber system in a vehicle service subscriber system group. The first vehicle service subscriber system is associated with a first ride in a first vehicle associated with a vehicle service provider system. The update broadcast (1116) by the vehicle service provider system is a first update to the first salt, thereby generating a second salt. The vehicle service provider system receives a request for a second ride from a second vehicle service subscriber system (in the vehicle service subscriber system group). In an embodiment, the second vehicle service subscriber system is a new entrant to the vehicle service subscriber system group. The vehicle service provider system generates (1108) a third salt based on the second salt and the second entropy generated by the second vehicle service subscriber system. The vehicle service provider system broadcasts (1116) a second update to the vehicle service subscriber system group, such that the second update includes the third salt.

[0187] In an embodiment, the second salt includes a hash of multiple entropy values. Each entropy value is received by the vehicle service provider system from the corresponding vehicle service subscriber system. For example, the first valid synchronization message that passes the verification check described herein causes the vehicle service provider system to schedule a salt update. Entropy from any synchronization messages received from the vehicle service subscriber system group before the salt update is performed will be included in the new salt generation.

[0188] In an embodiment, when the vehicle service provider system receives a sync message and the salt update message has been broadcast, the sync message is discarded. For example, the sync message received by the vehicle service provider system is a first sync message. The vehicle service provider system receives a second sync message after broadcasting (1116) the update but before broadcasting (1104) the new salt. In response, the vehicle service provider system discards the second sync message received just after broadcasting (1116) the update.

[0189] Fig.12 is a flow chart illustrating an example process for session key generation for AV operations according to at least one embodiment. Figure 1 The AV 100 illustrated and described in more detail is the same or similar. In an embodiment, Fig.12The processing is performed by a vehicle service subscriber system in the vehicle service subscriber system group (e.g., an AV service subscriber system 708 implemented using at least one processor such as processor 304). In other embodiments, other entities (e.g., a server (e.g., server 136), a computer system (e.g., computer system 300), a mobile device, or an AV system (e.g., AV system 120)) perform some or all elements of the processing. In addition, other embodiments of the technology include more or fewer elements, different elements, elements performed in an order different from the order depicted, etc.

[0190] At startup, when the vehicle service subscriber system joins a session with a vehicle service provider system (e.g., AV service provider system 704 implemented using at least one processor such as processor 304), the vehicle service subscriber system waits (1204) to receive a salt message and salt from the vehicle service provider system.

[0191] In an embodiment, at startup, when the vehicle service subscriber system attempts to coordinate with the vehicle service provider system to provide a ride to a user or passenger associated with the vehicle service subscriber system, the vehicle service subscriber system sends a notification to the vehicle service provider system requesting a new ride. The vehicle service subscriber system joins a session with the vehicle service subscriber system group and the vehicle service provider system. The vehicle service subscriber system receives a salt from the vehicle service provider system in response to sending a request to the vehicle service provider system for a ride in a vehicle associated with the vehicle service provider system. In an embodiment, the salt received from the vehicle service provider system includes or is pseudo-random data generated by the vehicle service provider system. For example, the pseudo-random data is selected by the vehicle service provider system from an entropy pool of the vehicle service provider system. The entropy pool of the vehicle service provider system is independent of the entropy generated by the vehicle service subscriber system.

[0192] The salt will eventually be used by the vehicle service subscriber system to compute a session key for the session so that the vehicle service subscriber system can authenticate and decode (or decrypt) a black channel message from the vehicle service provider system to provide a ride to a passenger in an AV associated with or provided by the vehicle service provider system. Figure 5 As illustrated and described in more detail in element 500 of FIG. 1 , the vehicle service provider system broadcasts a salt message containing a salt. The vehicle service subscriber system receives the broadcast salt in the salt message from the vehicle service provider system.

[0193] The vehicle service subscriber system is associated with a vehicle service subscriber, who may be a user of a mobile device on which the vehicle service subscriber system resides, a software client of the vehicle service subscriber system, an app executing on a mobile device, or a software client running on an AV system of which the vehicle service subscriber system is a part. The vehicle service subscriber system generates entropy. As referenced Fig.11 As illustrated and described in more detail, entropy is generated by a vehicle service subscriber system that is independent of the vehicle service provider system and independent of a different entropy pool of the vehicle service provider system. Entropy is a random value (integer or floating point), a pseudo-random value, a digital vector of randomly generated bits, or a combination thereof. In an embodiment, the vehicle service subscriber system selects entropy from an entropy pool that is independent of a different entropy pool of the vehicle service provider system.

[0194] The vehicle service subscriber system sends (1208) a synchronization message to a vehicle service provider system associated with at least one vehicle. The synchronization message includes entropy. In an embodiment, the vehicle service subscriber system receives a salt message indicating a lack of scheduled salt updates. Before the vehicle service subscriber system sends the synchronization message to the vehicle service provider system, in element 1204, the vehicle service subscriber system waits for at least one salt message to be broadcast by the vehicle service provider system. The salt message indicates that no salt updates are currently scheduled. The vehicle service provider system discards any synchronization messages received after the broadcast of the salt updates has begun. The vehicle service provider system uses a timer to periodically send salt to the vehicle service subscriber system at regular intervals. The salt message is different from an update indicating that the vehicle service provider system is performing a salt update. In an embodiment, the timer is an electronic timer, such as a quartz timer with digital electronics, an integrated circuit timer, a software timer, or a PLC with ladder logic. The vehicle service subscriber system sends (1208) a synchronization message in response to receiving the salt message from the vehicle service provider system.

[0195] In response to receiving an update (salt update message) containing salt from the vehicle service provider system, the vehicle service subscriber system verifies that the salt is generated using the entropy contributed by the vehicle service subscriber system to the vehicle service provider system. In an embodiment, the salt is generated by the vehicle service provider system using HMAC based on entropy. The vehicle service subscriber system verifies that the salt is generated using HMAC and the entropy generated and sent by the vehicle service subscriber system. For example, once the synchronization message is sent in element 1208, the vehicle service subscriber system waits for the salt update message to be broadcast by the vehicle service provider system. If the entropy contribution of the vehicle service subscriber system is listed, shown or incorporated into the entropy field of the salt update message, and the vehicle service subscriber system verifies the determination of the new salt, the vehicle service subscriber system has successfully contributed its entropy to the salt. Then, the vehicle service subscriber system calculates the session key in element 1212 and begins to authenticate the black channel protected message.

[0196] In an embodiment, the salt is generated by cryptographically hashing a previous salt (received by the vehicle service subscriber system at element 1204) using entropy. For example, the vehicle service provider system uses a hash function to process the entropy and generate a fixed-size salt that includes the encrypted text. In an embodiment, if the vehicle service subscriber system determines that its entropy contribution is not listed or incorporated into the salt update message, or if the salt verification fails, the vehicle service subscriber system retries the synchronization message element of element 1208. In an embodiment, the vehicle service subscriber system sends a warning message indicating a potential replay attack to the vehicle service provider system. The vehicle service subscriber system does not trust the broadcast salt until the entropy contribution of the vehicle service subscriber system is incorporated into the salt by the vehicle service provider system. The vehicle service subscriber system attempts to verify the incorporation, and if the verification is successful, the salt is considered to be trusted by the vehicle service subscriber system. The vehicle service subscriber system uses only the trusted salt to compute the session key used to authenticate the black channel protected messages from the vehicle service provider system.

[0197] In an embodiment, the vehicle service subscriber system receives a salt within an update from the vehicle service provider system. A first frequency of sending salt messages is greater than a second frequency of sending updates. For example, salt messages (different from update messages) are sent more frequently than update messages. In an embodiment, once the vehicle service subscriber system that successfully completes the synchronization message process in element 1208 receives a salt update message indicating that a salt update is scheduled, the vehicle service subscriber system verifies the salt determination. If the salt determination is successfully verified, the vehicle service subscriber system calculates (1212) and uses a new session key. If the verification fails, the vehicle service subscriber system retries the synchronization message process of element 1208.

[0198] In an embodiment, the vehicle service subscriber system determines that the salt received in the update message excludes entropy. The vehicle service subscriber system waits (1204) for a salt message from the vehicle service provider system indicating a lack of scheduled salt updates. In response to receiving a salt message from the vehicle service provider system indicating a lack of scheduled salt updates, the vehicle service subscriber system resends (1208) the synchronization message. In an embodiment, the vehicle service subscriber system determines that the salt excludes entropy. In response, the vehicle service subscriber system sends a message indicating a possible replay attack to the vehicle service provider system. In an embodiment, once a vehicle service subscriber system that has successfully completed the synchronization message process of element 1208 receives a salt message and the salt value does not match the vehicle service subscriber system's own records, the vehicle service subscriber system retries the synchronization message process of element 1208.

[0199] Thus, embodiments disclosed herein detect and prevent two types of attacks. Protection against replay attacks, in which a malicious entity intercepts a salt message or update, impersonates a vehicle service provider system, and pretends to be the vehicle service provider system to send messages to the vehicle service subscriber system. For example, a malicious entity may attempt a replay attack to extract personal, financial, or confidential information or payments from a vehicle service subscriber system. Protection against DoS attacks, in which a malicious entity intercepts a salt message or update, impersonates a vehicle service subscriber system, and pretends to be the vehicle service subscriber system to send messages to the vehicle service provider system. A malicious entity may attempt a DoS attack to extract personal, financial, or confidential information from a vehicle service provider system, achieve a denial of service, or attempt to hijack a vehicle service provider system for ransom.

[0200] In element 1212, the vehicle service subscriber system calculates a session key using the salt. The session key is calculated in a manner similar or identical to that described in more detail elsewhere herein. In an embodiment, the salt received by the vehicle service subscriber system from the vehicle service provider system in element 1208 is a first salt, and the entropy generated and sent by the vehicle service subscriber system in element 1208 is a first entropy. The vehicle service subscriber system that generates the first entropy is the first vehicle service subscriber system in the vehicle service subscriber system group. The session key calculated by the first vehicle service subscriber system in element 1212 is the first session key. The first vehicle service subscriber system receives an update from the vehicle service provider system in element 1216. The update includes a second salt generated using a second entropy generated by a second vehicle service subscriber system in the vehicle service subscriber system group. For example, the vehicle service subscriber system is requesting an AV ride for a passenger in another vehicle associated with the vehicle service provider system. The first vehicle service subscriber system moves to element 1212 and computes a second session key using the second salt. Fig.11 The same or similar process as described in more detail is used to calculate the second session key.

[0201] In an embodiment, the black channel message received by the vehicle service subscriber system in element 1212 is a first black channel message. The vehicle service subscriber system determines that a session key calculated based on a salt including entropy from another vehicle service subscriber system fails to authenticate a second black channel message received from the vehicle service provider system. For example, there is a risk that the second vehicle service subscriber system is a malicious entity. The vehicle service subscriber system generates a replay warning message to the vehicle service provider system indicating a possible replay attack.

[0202] In an embodiment, the vehicle service subscriber system is one of a vehicle service subscriber system group. Salt includes a chained element set. Each element in the chained set is generated using different entropies generated by the corresponding vehicle service subscriber systems in the vehicle service subscriber system group. Therefore, each vehicle service subscriber system in the vehicle service subscriber system group enhances the security of each other vehicle service subscriber system and the vehicle service provider system. For example, further salt updates that are not directly contributed by a specific vehicle service subscriber system may occur in element 1208. By verifying each link in the "salt chain", the specific vehicle service subscriber system verifies that its entropy contribution still exists. A "salt chain" is constructed using a series of cryptographic hashes. Therefore, the salt value represents the history of entropy contributed by the vehicle service subscriber system in the session. Even a large number of new vehicle service subscriber systems entering a session with the vehicle service provider system will not "flush" the existing entropy contribution. If the vehicle service subscriber system detects that the "salt chain" has been broken, the vehicle service subscriber system will consider any new salt to be untrustworthy until the vehicle service subscriber system contributes more entropy and verifies that the entropy is incorporated into the salt by the vehicle service provider system.

[0203] The vehicle service subscriber system receives a black channel message from the vehicle service provider system. The vehicle service subscriber system uses the session key to authenticate the black channel message to provide a ride in at least one vehicle associated with the vehicle service provider system. If the black channel message authentication fails, the vehicle service subscriber system moves to element 1204 in process and waits for the next salt message. In an embodiment, the vehicle service subscriber system initializes a black channel receiver for receiving black channel messages from the vehicle service provider system in response to verifying that the salt is generated using entropy. In element 1216, once the black channel message is authenticated and the salt is trusted, the vehicle service subscriber system initializes its black channel receiver to receive and decrypt additional black channel messages associated with providing AV rides.

[0204] In an embodiment, in element 1216, the vehicle service subscriber system receives the next update. The vehicle service subscriber system moves to element 1212 in the process and calculates the session key based on the next salt. The vehicle service subscriber system determines that the next update indicates that the current salt is valid until a certain time. For example, a "valid through" value is used as an indicator. Reference Figure 8The "valid through" indicator is described in more detail. The vehicle service subscriber system receives the next salt from the vehicle service provider system within the next update. The vehicle service subscriber system decrypts the black channel message based on the current salt. The black channel message is used to provide a ride in a vehicle associated with the vehicle service provider system.

[0205] In element 1216, the vehicle service subscriber system periodically receives salt messages from the vehicle service provider system containing the current salt. If one of these received salt values ​​does not match the current salt, the vehicle service subscriber system moves to element 1204 in the process, where it waits for the next salt message from the vehicle service provider system. For example, as referenced Figure 8 As illustrated and described in more detail, the vehicle service provider system uses a timer to periodically rebroadcast the salt message. In an embodiment, the salt message is broadcast at an interval controlled by the timer and repeated a maximum number of times M. In an embodiment, the timer is an electronic timer, such as a quartz timer with digital electronics, an integrated circuit timer, a software timer, or a PLC with ladder logic.

[0206] Fig.13 1 is a flow chart illustrating an example process for session key generation for AV operation according to at least one embodiment. At least one AV operating using this process is the same as or similar to AV 100. In an embodiment, Fig.13 The process is performed by a vehicle service provider system (e.g., AV service provider system 704). In other embodiments, other entities (e.g., servers (e.g., server 136) or computer systems (e.g., computer system 300)) perform some or all elements of the process. Additionally, other embodiments of the illustrated process include more, fewer, or different elements, or elements arranged in an order different from that depicted.

[0207] The vehicle service provider system broadcasts 1304 a first salt to at least one vehicle service subscriber system associated with a vehicle service subscriber (e.g., AV service subscriber system 708 implemented using at least one processor such as processor 304). The vehicle service provider system is associated with at least one vehicle.

[0208] The vehicle service provider system starts a timer associated with a duration of broadcasting a first salt within a salt message to the vehicle service subscriber system group. In response to expiration of the timer, the vehicle service provider system broadcasts (1304) a salt message containing the first salt generated or selected at startup. The timer associated with the duration of broadcasting the first salt is reset, and the vehicle service provider system periodically rebroadcasts (1304) a salt message containing the first salt upon expiration of the timer. For example, the timer is an electronic timer, such as a quartz timer having digital electronics, an integrated circuit timer, a software timer, or a PLC having ladder logic.

[0209] The vehicle service provider system receives (1308) a synchronization message from the vehicle service subscriber system. The synchronization message includes entropy generated by the vehicle service subscriber system. The entropy is generated by the vehicle service subscriber system independently of the vehicle service provider system and independently of a different entropy pool of the vehicle service provider system. Entropy is a random value (integer or floating point), a pseudo-random value, a digital vector of randomly generated bits, or a combination thereof. The synchronization message is generated by the vehicle service subscriber system to contribute entropy to the next salt update.

[0210] The entropy value is adjusted by the vehicle service subscriber system using different hash algorithms and hash implementations. In an embodiment, the "entropy" field in the synchronization message is a random number drawn by the vehicle service subscriber system from its own entropy pool. The "last salt" field refers to the salt value of the last salt message received by the vehicle service subscriber system. For example, the "last salt" is the first salt generated by the vehicle service provider system in element 1304. In an embodiment, the vehicle service provider system enhances security by verifying that the "last salt" field of the synchronization message is valid. To be valid, the "last salt" field value of the synchronization message should match the current salt (e.g., the first salt) of the vehicle service provider system. If the verification is successful, the vehicle service provider system processes the synchronization message.

[0211] The vehicle service provider system generates (1312) a second salt based on the first salt and the entropy. For example, the vehicle service provider system updates (1308) the first salt by concatenating a current salt (e.g., the first salt) and the entropy from the received synchronization message. In an embodiment, generating the second salt includes performing an HMAC, by the vehicle service provider system, on the concatenation of the first salt and the entropy. For example, the concatenated data is passed through a hash algorithm to produce a value for the second salt. In an embodiment, information identifying the vehicle service provider system (such as a name, identification number, or IP address, etc.) is included in the concatenated data to enhance data security.

[0212] The vehicle service provider system calculates (1316) a session key based on the second salt. In an embodiment, as shown in FIG. Figure 5 As illustrated and described in more detail, a session key is calculated using HKDF, IKM, and a second salt. For example, an HMAC-based HKDF is used to determine the session key. In an embodiment, the vehicle service provider system sets a timer after receiving a synchronization message, and a second salt is generated by the vehicle service provider system when the timer expires. When the second salt is generated, the vehicle service provider system reinitializes its protected message (e.g., black channel message) transmitter context using the session key derived from the second salt. In an embodiment that further improves security, before generating the session key, the vehicle service provider system verifies that the hash-based message authentication of the concatenation of the "last salt" and entropy from the vehicle service subscriber system matches the second salt. In response to a verification failure, the vehicle service provider system signals a potential DoS attack or irregularity.

[0213] The vehicle service provider system broadcasts (1320) an update to the vehicle service subscriber systems. The update includes a second salt for decrypting a protected message using a session key. The protected message is used to provide a ride involving at least one vehicle. In an embodiment, the vehicle service provider system broadcasts an extended salt update message. The salt update message is extended to accommodate at least one entropy contribution received from the group of vehicle service subscriber systems as part of a synchronization message.

[0214] The "entropy" field in the extended update represents the entropy contributed by at least one vehicle service subscriber system. In an embodiment, security is further improved by enhancing salt generation to prevent attackers from crafting salt update messages and potentially causing a DoS attack on the group of vehicle service subscriber systems. Salt generation is enhanced by replacing cryptographic hashes with HMACs to prevent attackers from forging salt update messages.

[0215] Fig.14 is a flow chart illustrating an example process for session key generation for operation of an AV (e.g., AV 100) according to at least one embodiment. In an embodiment, Fig.14 The processing is performed by a vehicle service subscriber system in the vehicle service subscriber system group (e.g., an AV service subscriber system 708 implemented using at least one processor such as processor 304). In other embodiments, other entities (e.g., a server (e.g., server 136), a computer system (e.g., computer system 300), a mobile device, or an AV system (e.g., AV system 120)) perform some or all elements of the processing. It should be understood that other embodiments of the processing include more or fewer elements, different elements, elements arranged in a different order, etc.

[0216] The vehicle service subscriber system generates (1404) entropy. The vehicle service subscriber system is associated with a vehicle service subscriber, which is a software client running on the vehicle service subscriber system or a user of the vehicle service subscriber system. Fig.11 As illustrated and described in more detail, entropy is generated by a vehicle service subscriber system that is independent of the vehicle service provider system and independent of a different entropy pool of the vehicle service provider system. Entropy is a random value (integer or floating point), a pseudo-random value, a digital vector of randomly generated bits, or a combination thereof. In an embodiment, the vehicle service subscriber system selects entropy from an entropy pool that is independent of a different entropy pool of the vehicle service provider system.

[0217] The vehicle service subscriber system sends (1408) a synchronization message to a vehicle service provider system associated with at least one vehicle. The synchronization message includes entropy. In an embodiment, the vehicle service subscriber system receives a salt message indicating a lack of scheduled salt updates. Before the vehicle service subscriber system sends the synchronization message to the vehicle service provider system, the vehicle service subscriber system waits for at least one salt message to be broadcast by the vehicle service provider system. The salt message indicates that no salt updates are currently scheduled. The vehicle service provider system discards any synchronization messages received after the broadcast of the salt updates has begun. The vehicle service provider system uses a timer to periodically send salt to the vehicle service subscriber system at regular intervals. The salt message is different from an update, which indicates that the vehicle service provider system is performing a salt update. In an embodiment, the timer is an electronic timer, such as a quartz timer with digital electronics, an integrated circuit timer, a software timer, or a PLC with ladder logic.

[0218] The vehicle service subscriber system receives (1412) a salt from the vehicle service provider system. The salt is received within an update from the vehicle service provider system. The vehicle service subscriber system verifies that the salt was generated using entropy contributed by the vehicle service subscriber system to the vehicle service provider system. In an embodiment, the salt is generated by the vehicle service provider system using HMAC based on entropy. The vehicle service subscriber system verifies that the salt was generated using HMAC and entropy generated and sent by the vehicle service subscriber system. For example, once a synchronization message is sent, the vehicle service subscriber system waits for a salt update message broadcast by the vehicle service provider system.

[0219] If the vehicle service subscriber system's entropy contribution is listed, shown, or incorporated into the entropy field of the salt update message, and the vehicle service subscriber system verifies the determination of the new salt, then the vehicle service subscriber system has successfully contributed its entropy to the salt. The vehicle service subscriber system then calculates the session key and begins authenticating protected messages. In an embodiment, the salt is generated by cryptographically hashing a previous salt (received by the vehicle service subscriber system) using entropy. For example, the vehicle service provider system uses a hash function to process the entropy and generate a fixed-size salt that includes encrypted text.

[0220] The vehicle service subscriber system verifies (1416) that the salt was generated using entropy. In an embodiment, if the vehicle service subscriber system determines that its entropy contribution is not listed or incorporated into the salt update message, or if the salt verification fails, the vehicle service subscriber system retries the synchronization message element. In an embodiment, the vehicle service subscriber system sends a warning message to the vehicle service provider system indicating a potential replay attack. The vehicle service subscriber system does not trust the broadcast salt until the entropy contribution of the vehicle service subscriber system is incorporated into the salt by the vehicle service provider system. The subscriber attempts to verify the incorporation, and if the verification is successful, the salt is considered to be trusted by the vehicle service subscriber system. The vehicle service subscriber system only uses the trusted salt to calculate the session key used to authenticate the protected message from the vehicle service provider system.

[0221] The vehicle service subscriber system calculates (1420) a session key using the salt. The session key is used for a communication session with the vehicle service provider system. The session key is calculated in a manner similar to or identical to that described in more detail elsewhere herein. In an embodiment, the salt received by the vehicle service subscriber system from the vehicle service provider system is a first salt, and the entropy generated and sent by the vehicle service subscriber system is the first entropy. The vehicle service subscriber system that generates the first entropy is the first vehicle service subscriber system in the vehicle service subscriber system group. The session key calculated by the first vehicle service subscriber system is the first session key. The first vehicle service subscriber system receives an update from the vehicle service provider system. The update includes a second salt generated using a second entropy generated by a second vehicle service subscriber system in the vehicle service subscriber system group. For example, the vehicle service subscriber system is requesting an AV ride for a passenger in another vehicle associated with the vehicle service provider system. The first vehicle service subscriber system calculates a second session key using the second salt. Using the same salt as reference Fig.11 The same or similar process as described in more detail is used to calculate the second session key.

[0222] The vehicle service subscriber system receives (1424) a protected message from the vehicle service provider system. The vehicle service subscriber system uses the session key to authenticate the protected message to provide a ride in at least one vehicle associated with the vehicle service provider system. If the protected message authentication fails, the vehicle service subscriber system waits for the next salt message. In an embodiment, the vehicle service subscriber system initializes a protected message receiver for receiving protected messages from the vehicle service provider system in response to verifying that the salt was generated using entropy. Once the protected message is authenticated and the salt is trusted, the vehicle service subscriber system initializes its protected message receiver to receive and decrypt additional black channel messages associated with providing AV rides.

[0223] The vehicle service subscriber system authenticates (1428) a protected message using the session key. The protected message is used to provide a ride involving at least one vehicle associated with the vehicle service provider system. If authentication of the protected message using the session key is successful, then the vehicle service subscriber system has the correct session key for the session. The vehicle service subscriber system consumes the protected message and ignores future salt messages it receives during the session. The vehicle service subscriber system does not become desynchronized with the vehicle service provider system and uses the same session key to authenticate protected messages from the vehicle service provider system for the duration of the session.

[0224] In the previous description, embodiments of the present invention have been described with reference to many specific details, which may be different due to implementation. Therefore, the description and the accompanying drawings should be regarded as illustrative, rather than restrictive. The only and exclusive indication of the scope of the present invention, and the content that the applicant expects to become the scope of the present invention is the literal and equivalent scope of the claims issued from this application in the specific form of issuing the claims, including any subsequent amendments. Any definition of the terms clearly set forth herein for being included in such claims should be based on the meaning of such terms as used in the claims. In addition, when the term "also includes" is used in the previous description or the attached claims, the following of the phrase can be an additional element or entity, or a sub-element / sub-entity of the previously described element or entity.

Claims

1. A method for a vehicle service subscriber system, comprising: generating entropy by a vehicle service subscriber system having at least one processor, the vehicle service subscriber system being associated with a vehicle service subscriber; sending, by the vehicle service subscriber system using the at least one processor, a synchronization message to a vehicle service provider system associated with at least one vehicle, the synchronization message including the entropy; receiving, by the vehicle service subscriber system using the at least one processor, a salt from the vehicle service provider system; verifying, by the vehicle service subscriber system using the at least one processor, that the salt was generated using the entropy; computing, by the vehicle service subscriber system using the at least one processor, a session key using the salt; receiving, by the vehicle service subscriber system using the at least one processor, a protected message from the vehicle service provider system; as well as authenticating, by the vehicle service subscriber system, using the at least one processor, the protected message using the session key, wherein the protected message is used to provide a ride involving the at least one vehicle, The method further comprises: receiving, by the vehicle service subscriber system using the at least one processor, a salt message from the vehicle service provider system indicating a lack of scheduled salt updates, wherein the vehicle service subscriber system sends the synchronization message in response to receiving the salt message.

2. The method according to claim 1, wherein: The vehicle service subscriber system receives a salt within an update from the vehicle service provider system, and a first frequency of sending the salt message is greater than a second frequency of sending the updates.

3. The method according to claim 1, further comprising: determining, by the vehicle service subscriber system using the at least one processor, that the salt excludes the entropy; waiting, by the vehicle service subscriber system using the at least one processor, for the salt message from the vehicle service provider system indicating a lack of a scheduled salt update; as well as The synchronization message is resent by the vehicle service subscriber system using the at least one processor.

4. The method according to any one of claims 1 to 3, further comprising: determining, by the vehicle service subscriber system using the at least one processor, that the salt excludes the entropy; as well as A message is sent, by the vehicle service subscriber system using the at least one processor, to the vehicle service provider system indicating a possible replay attack.

5. The method according to any one of claims 1 to 3, wherein: The session key is calculated using a hash key derivation function, the input key content and the salt.

6. The method according to any one of claims 1 to 3, wherein: The salt is generated based on the entropy using a hash-based message authentication code.

7. The method according to any one of claims 1 to 3 further includes, in response to verifying that the salt is generated using the entropy, initializing a protected message receiver by the vehicle service subscriber system using the at least one processor, the protected message receiver receiving the protected message from the vehicle service provider system.

8. The method according to any one of claims 1 to 3, wherein: The vehicle service subscriber system receives the salt in response to sending a request to the vehicle service provider system for a ride in the at least one vehicle.

9. The method according to any one of claims 1 to 3, wherein: The salt is generated by cryptographically hashing the previous salt using the entropy.

10. The method according to claim 9, wherein: The previous salt includes pseudo-random data generated by the vehicle service provider system.

11. The method according to claim 9, further comprising: determining, by the vehicle service subscriber system using the at least one processor, an update indicating that the previous salt was valid until a specific time, wherein the vehicle service subscriber system received the salt from the vehicle service provider system within the update; and A protected message is decrypted by the vehicle service subscriber system using the at least one processor based on the previous salt, the protected message being used to provide a ride in the at least one vehicle.

12. The method according to any one of claims 1 to 3, wherein: The vehicle service subscriber system is one of a plurality of vehicle service subscriber systems, and the salt comprises a plurality of chained elements, wherein each of the plurality of chained elements is generated using a different entropy generated by a corresponding vehicle service subscriber system of the plurality of vehicle service subscriber systems.

13. The method according to claim 12, wherein: The salt is a first salt, the entropy is a first entropy, the vehicle service subscriber system is a first vehicle service subscriber system of the plurality of vehicle service subscriber systems, and the session key is a first session key, the method further comprising: receiving, by the first vehicle service subscriber system using the at least one processor, an update from the vehicle service provider system, the update comprising a second salt generated using second entropy generated by a second vehicle service subscriber system of the plurality of vehicle service subscriber systems; and The at least one processor is used by the first vehicle service subscriber system to compute a second session key using the second salt to provide a ride in the at least one vehicle.

14. The method according to claim 13, wherein: The protected message is a first protected message, and the method further comprises: determining, by the vehicle service subscriber system using the at least one processor, that the second session key is incapable of authenticating a second protected message received from the vehicle service provider system; and A replay warning message is sent, by the vehicle service subscriber system using the at least one processor, to the vehicle service provider system indicating a possible replay attack.

15. The method according to any one of claims 1 to 3, wherein: The maximum number of vehicle service subscriber systems allowed to join a service session managed by the vehicle service provider system is limited to a threshold number of vehicle service subscriber systems specified by the vehicle service provider system.

16. The method according to any one of claims 1 to 3, wherein: The salt is a first salt, and the method further includes: receiving, by the vehicle service subscriber system using the at least one processor, from the vehicle service provider system a second salt, the second salt excluding a scheduled salt update associated with the second salt; and A replay warning message is sent, by the vehicle service subscriber system using the at least one processor, to the vehicle service provider system indicating a possible replay attack.

17. The method according to any one of claims 1 to 3, wherein: The protected message is a black channel message.

18. A vehicle service subscriber system comprising: at least one computer processor; as well as At least one non-transitory storage medium storing instructions that, when executed by the at least one computer processor, cause the vehicle service subscriber system to perform the method of any one of claims 1 to 17.

19. A non-transitory storage medium storing instructions that, when executed by at least one computer processor of a vehicle service subscriber system, cause the vehicle service subscriber system to perform the method of any one of claims 1 to 17.

20. A computer program product comprising a computer program which, when run by a processor, performs the method according to any one of claims 1 to 17.

Images