Vehicle service provider system, method for using the system, and storage medium

Abstract

This invention provides a vehicle service provider system, a method for using the system, and a storage medium. A method, system, and apparatus for calculating a session key for autonomous vehicle operation are disclosed. The vehicle service provider system broadcasts a first salt to at least one vehicle service subscriber system. The vehicle service provider system is associated with at least one vehicle. The vehicle service provider system receives a synchronization message from at least one vehicle service subscriber system. The synchronization message includes entropy. The vehicle service provider system generates a second salt based on the first salt and the entropy. The vehicle service provider system calculates a session key based on the second salt. The vehicle service provider system sends an update to at least one vehicle service subscriber system. The update includes a second salt for decrypting a protected message using the session key. The protected message is used to provide rides involving at least one vehicle. Other embodiments may be described or claimed.

Description

Technical Field

[0001] The embodiments relate to the operation of a vehicle, and more specifically to the generation of session keys for the operation of an autonomous vehicle. Background Technology

[0002] Autonomous Vehicle (AV) service providers sometimes use communication channels to communicate with AV service subscribers. However, for example, the use of such communication channels is vulnerable to replay attacks against AV service subscribers, such as when malicious entities use traditional communication channels to send false messages to them. Summary of the Invention

[0003] A method for a transportation service provider system includes: broadcasting a first salt by the transportation service provider system, which includes at least one processor, to at least one transportation service subscriber system associated with a transportation service subscriber, the transportation service provider system being associated with at least one vehicle; receiving a synchronization message from the at least one transportation service subscriber system by the transportation service provider system using the at least one processor, the synchronization message including entropy; generating a second salt by the transportation service provider system using the at least one processor based on the first salt and the entropy; calculating a session key by the transportation service provider system using the at least one processor based on the second salt; and broadcasting an update by the transportation service provider system using the at least one processor to the at least one transportation service subscriber system, the update including the second salt for decrypting a protected message using the session key, the protected message being for providing boarding information related to the at least one vehicle.

[0004] A transportation service provider system includes: at least one computer processor; and at least one non-transitory storage medium storing instructions that, when executed by the at least one computer processor, cause the transportation service provider system to perform the methods described above.

[0005] At least one non-transitory storage medium storing instructions that, when executed by at least one computer processor of the vehicle service provider system, cause the vehicle service provider system to perform the above-described method. Attached Figure Description

[0006] Figure 1 This is a block diagram illustrating an example of an autonomous AV according to at least one embodiment.

[0007] Figure 2 This is a block diagram illustrating an example "cloud" computing environment according to at least one embodiment.

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

[0009] Figure 4 This is a block diagram illustrating an example architecture of an AV according to at least one embodiment.

[0010] Figure 5 This is a flowchart illustrating a process for generating a session key for AV operation according to at least one embodiment.

[0011] Figure 6 This is a flowchart illustrating a process for generating a session key for AV operation according to at least one embodiment.

[0012] Figure 7 This is a timing diagram illustrating the process of generating a session key for AV operation according to at least one embodiment.

[0013] Figure 8 This is a flowchart illustrating a process for generating a session key for AV operation according to at least one embodiment.

[0014] Figure 9 This is a timing diagram illustrating the process of generating a session key for AV operation according to at least one embodiment.

[0015] Figure 10 This is a timing diagram illustrating the process of generating a session key for AV operation according to at least one embodiment.

[0016] Figure 11 This is a flowchart illustrating a process for generating a session key for AV operation according to at least one embodiment.

[0017] Figure 12 This is a flowchart illustrating a process for generating a session key for AV operation according to at least one embodiment.

[0018] Figure 13 This is a flowchart illustrating the process of generating session keys for AV operations.

[0019] Figure 14 This is a flowchart illustrating a process for generating a session key for AV operation according to at least one embodiment. Detailed Implementation

[0020] In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of the invention. However, it will be apparent that the invention may be practiced without these specific details. In other instances, well-known constructions and apparatuses are shown in block diagram form to avoid unnecessarily obscuring the invention.

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

[0022] Furthermore, in the accompanying drawings, connecting elements, such as solid or dashed lines or arrows, are used to illustrate connections, relationships, or associations between two or more other schematic elements. The absence of any such connecting element does not imply that connections, relationships, or associations cannot exist. In other words, connections, relationships, or associations between some elements are not shown in the drawings so as not to obscure the content of this disclosure. Additionally, for ease of illustration, a single connecting element is used to represent multiple connections, relationships, or associations between elements. For example, if a connecting element represents communication of signals, data, or instructions, those skilled in the art will understand that such an element represents one or more signal paths (e.g., a bus) that may be necessary to influence the communication.

[0023] Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. Numerous specific details are set forth in the following detailed description in order to provide a thorough understanding of the various embodiments described. However, it will be apparent to those skilled in the art that the various embodiments described can be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0024] The features described below can each be used independently of each other or in any 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 adequately solved by any of the features described herein. Although headings are provided, information relating to specific headings but not found in the sections bearing those headings can be found elsewhere in this specification. Embodiments are described herein based on the following summary:

[0025] 1. General Overview

[0026] 2. System Overview

[0027] 3. AV Architecture

[0028] 4. Session key generation for AV operation

[0029] General Overview

[0030] This paper presents a method, system, and apparatus for generating session keys for AV operations. The session key is a single-use symmetric key calculated by the AV service provider (AV provider) that rents or distributes AV to users of the AV service. The session key is used to encrypt messages in a communication session between the AV service provider and AV service subscribers. The AV service provider incorporates the entropy generated by each AV service subscriber into its salt used to calculate the session key. As used herein, "salt" refers to data such as random or pseudo-random data that serves as additional input to the function used to calculate the session key. Each AV service subscriber uses a technique independent of the AV service provider to verify the salt provided by the AV service provider and calculates the session key.

[0031] The advantages and benefits of the embodiments disclosed herein include preventing replay attacks by malicious entities against subscribers of the AV service. The disclosed embodiments also enable on-demand key updates for AV service provider-subscriber groups (e.g., when a specific AV service subscriber requests a new ride). The AV service provider can easily generate a new salt (and therefore a new session key) and securely notify the AV service subscribers of the change. The entropy generated by each AV service subscriber 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 remains unchanged throughout the session's lifetime. Therefore, AV service subscribers can avoid monitoring the salt message after successfully authenticating a protected message, reducing data transfer and computation. Entropy is carried forward over the session's duration, reducing entropy weaknesses at the AV service provider and preventing replay attacks. Security is further enhanced because the generated salt chain represents the history of all entropy provided by the AV service subscriber during the session. The embodiments disclosed herein also prevent rainbow table attacks by forcing malicious entities to recalculate the session key using the salt and entropy. A rainbow table attack is a type of hacking attack in which criminals attempt to use a rainbow hash table to crack passwords stored in a database system.

[0033] System Overview

[0034] Figure 1 This is a block diagram illustrating an example of an autonomous AV 100 according to at least one embodiment.

[0035] As used herein, the term “autonomy” 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 in this article, an AV is a vehicle with autonomous capabilities.

[0037] As used in this article, "vehicle" includes any mode of transport for goods or people. Examples include cars, buses, trains, airplanes, drones, trucks, ships, vessels, submersibles, and spacecraft. Driverless cars are an example of vehicles.

[0038] As used herein, a “trajectory” refers to the path or route taken by an AV from a first spatiotemporal location to a second spatiotemporal location. In embodiments, the first spatiotemporal location is referred to as the initial location or starting point, and the second spatiotemporal location is referred to as the destination, final location, target, target location, or target position. In some examples, a trajectory consists of at least one road segment (e.g., several segments of a road), and each road segment consists of at least one block (e.g., a lane or part of an intersection). In embodiments, spatiotemporal locations correspond to real-world locations. For example, a spatiotemporal location is a pick-up or drop-off point for people or goods to board or alight.

[0039] As used herein, “(one or more) sensors” includes at least one hardware component for detecting information relating to the environment surrounding the sensor. Some hardware components may include sensing components (e.g., image sensors, biometric sensors), transmission and / or receiving 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 tagged object detected by at least one sensor on an AV vehicle, or one or more classified or tagged objects provided by a source outside the AV.

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

[0042] As used herein, a “lane” is the 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 spaced far apart may accommodate two or more vehicles, allowing one vehicle to overtake another without crossing the lane markings; therefore, it can be interpreted as a lane being narrower than the space between lane markings, or as having two lanes. Lanes can also be interpreted in the absence of lane markings. For example, a lane may be defined based on the physical characteristics of the environment (e.g., rocks in a rural area and trees along a road).

[0043] "At least one" includes a function performed by one element, a function performed by multiple elements, for example 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 used only 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 terminology used in the description of the various embodiments described herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used in the description of the various embodiments described and the appended claims, the singular forms “a,” “an,” and “the” are also intended to include the 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 “comprising,” “including,” “possessing,” and / or “having” are used in this specification, they specifically indicate the presence of the stated features, integers, elements, operations, components, and / or components, but do not exclude the presence or addition of at least one other feature, integer, element, operation, component, and / or group thereof.

[0046] As used herein, depending on the context, the term "if" may optionally be understood as meaning "when" or "at that time" or "in response to being determined" or "in response to being detected." Similarly, depending on the context, the phrase "if determined" or "if [the stated condition or event] has been detected" may optionally be understood as meaning "when determined" or "in response to being determined" or "when [the stated condition or event] is detected" or "in response to being detected."

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

[0048] Generally, this document describes technologies applicable to any vehicle with at least one autonomous capability, including fully autonomous vehicles, 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 Definition of Terms Related to Automated Driving Systems for Motor Vehicles on Roads, the entire contents of which are incorporated herein by reference for further 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 Definition of Terms Related to Automated Driving Systems for Motor Vehicles on Roads). In embodiments, 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 map usage) under certain operating conditions based on the processing of sensor inputs. The technologies described in this document can benefit vehicles of any level, ranging from fully autonomous vehicles to human-operated vehicles.

[0049] refer to Figure 1 The AV system 120 enables the AV 100 to operate along a trajectory 198, traversing the environment 190 to a destination 199 (sometimes referred to as the 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 one embodiment, the AV system 120 includes means 101 for receiving and operating operation commands from a computer processor 146. In another embodiment, the computer processor 146 is referenced below. Figure 3 The processor 304 described is similar. Examples of the device 101 include a steering controller 102, a brake 103, a gear, an accelerator pedal or other acceleration control mechanism, a windshield wiper, a side door lock, a window controller, and a turn indicator.

[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 AV's position, linear velocity and acceleration, angular velocity and acceleration, and heading (e.g., the direction of the front of the AV 100). Examples of sensors 121 are Global Navigation Satellite Systems (GNSS), inertial measurement units (IMUs) that measure both linear acceleration and angular rate of a vehicle, wheel sensors for measuring or estimating wheel slip ratio, wheel braking pressure or braking torque sensors, engine torque or wheel torque sensors, and steering angle and angular rate sensors.

[0052] In an embodiment, sensor 121 also includes sensors for sensing or measuring properties of the AV's environment. Examples include a monocular or stereo camera 122 with visible, infrared, or thermal (or both) spectra, a LiDAR 123, a RADAR, an ultrasonic sensor, a time-of-flight (TOF) depth sensor, a rate sensor, a temperature sensor, a humidity sensor, and a precipitation sensor.

[0053] In one 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 another embodiment, the data storage unit 142 is associated with the following... Figure 3 The described ROM 308 or storage device 310 is similar. In this embodiment, memory 144 is similar to main memory 306 described below. In this embodiment, data storage unit 142 and memory 144 store historical, real-time, and / or predictive information about environment 190. In this embodiment, the stored information includes maps, driving performance, traffic congestion updates, or weather conditions. In this embodiment, data related to environment 190 is transmitted from remote database 134 to AV 100 via a communication channel.

[0054] In an embodiment, AV system 120 includes communication devices 140 for transmitting measured or inferred attributes of the state and conditions of other vehicles, such as position, linear velocity and angular velocity, linear acceleration and angular acceleration, and linear heading and angular heading, to AV 100. These devices include vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication devices, as well as devices for wireless communication via point-to-point or ad hoc networks, or both. In an embodiment, communication device 140 communicates across the electromagnetic spectrum (including radio and optical communications) or other media (e.g., air and acoustic media). Combinations of vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) communication (and at least one other type of communication in this embodiment) are sometimes referred to as vehicle-to-all-things (V2X) communication. V2X communication typically conforms to 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, this may be a wired, wireless, WiMAX, Wi-Fi, Bluetooth, satellite, cellular, optical, near-field, infrared, or radio interface. The communication interface transmits data from a remote database 134 to the AV system 120. In an embodiment, the remote database 134 is embedded in, for example... Figure 2In the cloud computing environment 200 described herein, communication interface 140 transmits data collected from sensor 121 or other data related to the operation of AV 100 to remote database 134. In one embodiment, communication interface 140 transmits information related to remote operation to AV 100. In another embodiment, AV 100 communicates with other remote (e.g., "cloud") servers 136.

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

[0057] In one embodiment, the remote database 134 stores and transmits historical information (e.g., rate and acceleration distribution) related to driving attributes of vehicles that previously traveled along trajectory 198 at similar times of day. In one implementation, such data may be stored in 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 AV 100 generates control actions in an algorithmic manner based on both real-time sensor data and prior information, allowing AV system 120 to perform its autonomous driving capabilities.

[0059] In one embodiment, the AV system 120 includes a computer peripheral device 132 coupled to a computing device 146 for providing information and alerts to a user of the AV 100 (e.g., an occupant or a remote user) and receiving input from that user. In another embodiment, the peripheral device 132 is similar to the one described in the following reference. Figure 3 The discussed display 312, input device 314, and cursor controller 316 are coupled wirelessly or wiredly. Any two or more interface devices can be integrated into a single device.

[0060] Example cloud computing environment

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

[0062] A cloud computing environment 200 includes at least one cloud data center. Generally, a cloud data center (e.g., ...) Figure 2 The cloud data center 204a shown refers to the cloud (e.g., Figure 2 The physical arrangement of servers in cloud 202 (or a specific portion of the cloud) is illustrated. For example, servers are physically arranged in rooms, groups, rows, and racks within a cloud data center. A cloud data center has at least one area, 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 areas, 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 embodiments, server nodes are similar to... Figure 3 The computer system described herein. 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) for connecting cloud data centers 204a, 204b, and 204c and facilitating access to cloud computing services by computing systems 206a-f. In embodiments, the network represents at least one local network, a wide area network, or any combination of wired or wireless links coupled via terrestrial or satellite connections. Data exchanged over the network is transmitted using various network layer protocols, such as Internet Protocol (IP), Multiprotocol Label Switching (MPLS), Asynchronous Transfer Mode (ATM), Frame Relay, etc. Furthermore, in embodiments where the network represents a combination of multiple sub-networks, different network layer protocols are used on each underlying sub-network. In embodiments, the network represents at least one interconnected internetwork (such as the public internet).

[0064] The computing system 206a-f or cloud computing service consumer connects to the cloud 202 via a network link and a network adapter. In embodiments, the computing system 206a-f is implemented as various computing devices, such as servers, desktops, laptops, tablets, smartphones, Internet of Things (IoT) devices, autonomous vehicles (including cars, drones, space shuttles, trains, buses, etc.), and consumer electronics. In embodiments, the computing system 206a-f is implemented in other systems or as part of other systems.

[0065] Computer System

[0066] Figure 3 This is a block diagram illustrating a computer system 300 according to at least one embodiment. In an implementation, the computer system 300 is a dedicated computing device. The dedicated computing device is hardwired to perform these technologies, or includes a digital electronic device such as at least one ASIC or field-programmable gate array (FPGA) that is persistently programmed to perform the aforementioned technologies, or may include at least one general-purpose hardware processor programmed to perform these technologies according to program instructions in firmware, memory, other memory, or a combination thereof. Such a dedicated computing device may also combine custom hardwired logic, ASIC, or FPGA with custom programming to accomplish these technologies. In various embodiments, the dedicated computing device is a desktop computer system, a portable computer system, a handheld device, a network device, or any other device that includes hardwired and / or program logic to implement these technologies.

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

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

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

[0070] According to one embodiment, the techniques described herein are executed by a computer system 300 in response to a 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. Executing the sequence of instructions contained in main memory 306 causes the processor 304 to execute the processing elements described herein. In alternative embodiments, hardwired circuitry is used instead of or in combination with software instructions.

[0071] As used herein, the term "storage medium" refers to any non-transitory medium that stores data and / or instructions that enable 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 discs, magnetic disks, solid-state drives, or three-dimensional cross-point memory such as storage device 310. Volatile media include dynamic memory, such as main memory 306. Common forms of storage media include, for example, floppy disks, floppy disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with perforations, RAM, PROMs and EPROMs, FLASH-EPROMs, NV-RAMs, or any other memory chips or memory cartridges.

[0072] Storage media differ from transmission media, but can be used in conjunction with them. Transmission media participate in the information transmission between storage media. For example, transmission media include coaxial cables, copper wires, and optical fibers, which include wires with a 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 communication.

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

[0074] Computer system 300 also includes a communication interface 318 coupled to bus 302. Communication interface 318 provides bidirectional data communication coupled to network link 320 connected to 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 used to provide data communication connectivity with a corresponding type of telephone line. As another example, communication interface 318 is a Local Area Network (LAN) card used to provide data communication connectivity with a compatible LAN. In some implementations, a wireless link is also implemented. In any such implementation, communication interface 318 transmits and receives electrical, electromagnetic, or optical signals carrying digital data streams representing various types of information.

[0075] Network link 320 typically provides data communication to other data devices via at least one network. For example, network link 320 provides connectivity to host computer 324 or to a cloud data center or device operated by Internet Service Provider (ISP) 326 via local network 322. ISP 326, in turn, provides data communication services via a worldwide packet data communication network now commonly referred to as the “Internet” 328. Both local network 322 and Internet 328 use electrical, electromagnetic, or optical signals carrying digital data streams. Signals through various networks and signals on network link 320 via communication interface 318 are example forms of transmission media carrying digital data entering and leaving computer system 300. In embodiments, network 320 includes the aforementioned cloud 202 or a portion of cloud 202.

[0076] Computer system 300 sends messages and receives data including program code through one or more networks, network links 320, and communication interfaces 318. In an embodiment, computer system 300 receives code for processing. The received code is executed by processor 304 upon receipt and / or stored in storage device 310, or in other non-volatile storage devices for later execution.

[0077] Autonomous Vehicle Architecture

[0078] Figure 4 This is an example of an AV (e.g., according to at least one embodiment) Figure 1 The diagram shows a block diagram of an example architecture 400 for the AV 100. Architecture 400 includes a sensing module 402 (sometimes called a sensing circuit), a planning module 404 (sometimes called a planning circuit), a control module 406 (sometimes called a control circuit), a positioning module 408 (sometimes called a positioning circuit), and a database module 410 (sometimes called a database circuit). Each module plays a role in the operation of the AV 100. Commonly, modules 402, 404, 406, 408, and 410 can be... Figure 1 This is part of the AV system 120 shown. In this embodiment, any of 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 combinations of these hardware).

[0079] In use, the planning module 404 receives data representing the destination 412 and determines data representing the trajectory 414 (sometimes called the route) that the AV100 can travel 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 sensing module 402, the positioning module 408, and the database module 410.

[0080] The sensing module 402 is used, for example, as follows Figure 1 At least one sensor 121 is shown to identify nearby physical objects. The 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 location 418 from the positioning module 408. The positioning module 408 determines the AV location by calculating the location using data from the sensor 121 and data from the database module 410 (e.g., geographic data). For example, the positioning module 408 uses data from the GNSS unit and geographic data to calculate the longitude and latitude of the AV. In embodiments, the data used by the positioning module 408 includes high-precision maps with lane geometry properties, maps describing road network connectivity properties, maps describing lane physical properties (such as traffic speed, traffic volume, number of vehicle and bicycle lanes, lane width, lane traffic direction, or lane marking type and location, or combinations thereof), and maps describing the spatial locations of road features (such as intersections, traffic signs, or various types of other traffic signals).

[0082] The control module 406 receives data representing trajectory 414 and data representing AV position 418, and operates the AV's control functions 420a-420c (e.g., steering, throttle, braking, ignition) in a manner that will cause the AV 100 to travel along trajectory 414 to reach destination 412. For example, if trajectory 414 includes a left turn, the control module 406 will operate the control functions 420a-420c in such a way that the steering angle of the steering function will cause the AV 100 to turn left, and the throttle and brake will cause the AV 100 to pause before turning and wait for passing pedestrians or vehicles.

[0083] Session key generation for AV operations

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

[0085] As used herein, a vehicle service provider system refers to a computer system that provides AVs for rental by a single passenger or group of passengers for non-shared or carpooling (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 between locations selected by the passengers in the AV. In embodiments, the vehicle service provider system rents out AVs for short periods of time (typically ranging from a few hours to a few weeks). The vehicle service provider system serves passengers who require temporary transportation (e.g., passengers who do not own their own cars, travelers, or owners of damaged or destroyed vehicles awaiting repair or insurance compensation). In embodiments, the vehicle service provider system rents out autonomous vans or trucks for moving goods. (References) Figure 3 The components of the example computer system 300, illustrated and described in more detail, implement a transportation service provider system. In an embodiment, the transportation 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 transportation service subscriber system refers to a computer system that responds to communications from a transportation service provider system in an AV associated with the transportation service provider system in order to book or provide AV rides to transportation service subscribers. In embodiments, the transportation service subscriber system is the same as or similar to AV service subscriber system 708. In embodiments, a mobile app running on the transportation service subscriber system is used to book an AV ride. In embodiments, the transportation service subscriber system is part of a mobile device (such as a smartphone, laptop computer, tablet computer, or personal digital assistant) and is implemented using components of example computer system 300. For example, a transportation service subscriber (e.g., a mobile app or user) sets up a personal profile on the transportation service subscriber system with a name, phone number, other information, or payment preferences.

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

[0088] In embodiments, the vehicle service subscriber system is part of an AV system (e.g., AV system 120) and is implemented using, for example, a processor 146. For instance, in one embodiment, the vehicle service subscriber is a software client running on either the vehicle service subscriber system or the AV system. Therefore, the vehicle service provider system communicates with the vehicle service subscriber system embedded in the AV system, enabling the AV to be operated using commands or messages sent from 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. Protected messages can be, for example, black channel messages. Embodiments herein will be described with reference to specific examples of black channel messages; however, it should be understood that other embodiments may include different types of encryption or protection protocols.

[0090] Security-related data and diagnostic information are exchanged via black channel messages over existing network connections (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 session keys for the communication session. As mentioned above, "salt" refers to random or pseudo-random data generated by the vehicle service provider system and used by the various vehicle service subscriber systems to calculate the session key. For example, the vehicle service subscriber system uses the salt as input to a function that hashes pre-shared data (such as keys, data, passwords, or passphrases).

[0091] Session keys are used to authenticate, decode, or decrypt protected (e.g., black channel) messages transmitted between the vehicle service provider's system and the vehicle service subscriber's system. Black channel messages are used to offer rides to passengers (vehicle service subscribers) in the vehicle (AV) associated with the vehicle service provider's system. For example, black channel messages include geographic data related to the AV's origin, geographic data related to the AV's destination, the number of passengers on the AV, the amount of luggage the AV will carry, carpooling details, route details, information about the AV's brand and model, passenger identification, or AV speed data. As previously mentioned, such messages include one or more of the following: sensor data, vehicle diagnostic data, vehicle commands, vehicle status data, or other types of data.

[0092] The embodiments disclosed herein prevent replay attacks by malicious entities by enabling individual vehicle service subscriber systems to generate and contribute entropy to the salt. A replay attack is a network attack in which valid data transmission (e.g., black channel messages or salt messages) is maliciously or deceptively repeated or delayed by a malicious entity. For example, a malicious entity intercepting black channel messages intended for use by a vehicle service subscriber system could launch a replay attack as part of a deceptive attack using black channel messages as IP packet replacements. The embodiments disclosed herein use entropy to prevent such attacks and also enable vehicle service subscriber systems and vehicle service provider systems to compute the same session key used for communication sessions, thereby avoiding excessive computational load. The embodiments can provide additional benefits such as protection against deception and tampering.

[0093] refer to Figure 5 The vehicle service provider system generates (500) a salt for encrypting communication sessions with at least one vehicle service subscriber system. The salt includes random bits added to an instance of the cipher (e.g., the session key) before the cipher 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 one embodiment, the vehicle service provider system selects the salt from an entropy pool. In one embodiment, entropy refers to the average level of information inherent in the possible values ​​of a random variable. In another embodiment, entropy refers to a set of random data (e.g., a mixture of random data from various sources). For example, entropy represents the mathematical constraint of losslessly compressing data onto a noise-free channel. Even when the vehicle service provider system and the various vehicle service subscriber systems use the same pre-shared data, the salt is used to create a unique cipher.

[0094] One advantage of the embodiments disclosed herein is that they allow different subscribers and publishers to agree on a unique key used for different sessions (e.g., vehicle guidance or when a vehicle provides a ride to passengers) that begins only with pre-shared data. Another advantage of the embodiments disclosed herein is that they prevent rainbow table attacks by forcing malicious entities to recalculate the session key using salt. A rainbow table attack is a type of hacking attack in which criminals attempt to use a rainbow hash table to crack passwords stored in a database system.

[0095] The vehicle service provider system uses salt to compute a session key (504). In an embodiment, a hashed key derivation function (HKDF), an input key content (IKM), and salt are used to compute the session key. For example, the session key is determined using an HKDF based on a hash-based message authentication code (HMAC). The session key is an encryption and decryption key that is randomly computed to ensure the security of communication sessions between the vehicle service provider system and the various vehicle service subscriber systems. 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 the various vehicle service subscriber systems. The HKDF is an HMAC-based key derivation function (KDF). The HKDF serves 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) of a type involving a cryptographic hash function and a secret encryption key (e.g., salt). In an embodiment, an 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 (the output of HKDF), as represented by the following equation (1):

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

[0097] The transportation service provider system uses a session key to initialize (508) its protected message (e.g., black channel) transmitter, making the black channel transmitter ready to send black channel messages to the transportation service subscriber system for user scheduling and ride provisioning in AVs. The black channel transmitter is part of the transportation service provider system and uses a reference... Figure 3 The components of the example computer system 300 are illustrated and described in more detail. The vehicle service provider system begins broadcasting a black channel protected message to the vehicle service subscriber system. Salt messages containing a salt generated or selected at startup are broadcast periodically.

[0098] In one embodiment, the vehicle service provider system broadcasts one or more black channel protected messages to a group of vehicle service subscriber systems, enabling one or more subscriber systems in that group to authenticate the black channel messages and their session keys. After authentication of the session keys and the first or more black channel protected messages, subsequent black channel messages are sent from the vehicle service provider system to the respective vehicle service subscriber system to which the black channel message is addressed. These black channel messages carry confidential or protected information about a specific AV ride associated with the respective vehicle service subscriber system. For example, the black channel messages may include details such as the ride destination, ride time, passenger identity, route information, or number of passengers.

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

[0100]

[0101] New ride-hailing service subscriber systems joining the session receive the salt in this manner. The ride-hailing service provider system uses a timer to periodically rebroadcast (516) the salt, causing newly joining ride-hailing service subscriber systems to receive the salt. In this 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. Each ride-hailing service subscriber system uses the salt to calculate a session key in the same manner as described for the ride-hailing service provider system in element 504. The session key is used to decode or decrypt black channel messages from the ride-hailing service provider system to provide rides in one or more AVs associated with the ride-hailing service provider system.

[0102] Figure 6 This is a flowchart illustrating an example process for generating a session key for AV operation according to at least one embodiment. At least one AV operating using this process is connected to a reference... Figure 1 The AV 100 is the same as or similar to the one illustrated and described in more detail. In the embodiments, Figure 6 The processing is performed by the 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 (e.g., processor 304).

[0103] In other embodiments, other entities (e.g., 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 of the elements of this process. It will be appreciated that... Figure 6 The technology described herein is intended as an example, and other embodiments may include more or fewer elements, elements in a different order than those depicted, etc.

[0104] In this 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 data transfer volume, and reduced computational load, especially 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.

[0105] Upon 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 a salt from the vehicle service provider system. The vehicle service provider system is the same as or similar to the AV service provider system 704 and is implemented using at least one processor, such as processor 304.

[0106] The salt will ultimately be used by the vehicle service subscriber system to calculate the session key, enabling the subscriber system to authenticate and decode (or decrypt) black channel messages from the vehicle service provider system to offer rides to passengers in the AV provided by the vehicle service provider system. The vehicle service provider system broadcasts the next salt message containing the salt, as shown in the reference. Figure 5 The elements 500 are illustrated and described in more detail. The vehicle service subscriber system receives a broadcast salt in the (608) salt message from the vehicle service provider system.

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

[0108] To verify that the salt and session key are correct and have been properly received and generated / computed, the vehicle service subscriber system attempts to authenticate the black channel message using the session key. If 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 any future salt messages received during the session. Therefore, the vehicle service subscriber system terminates (616) monitoring of salt messages. On the other hand, if authentication of the black channel message using the session key fails, the vehicle service subscriber system discards the black channel message.

[0109] To authenticate black-channel messages, the transportation service subscriber system verifies the data origin of the black-channel message and that the message has not been modified during transit. In this embodiment, the transportation service subscriber system uses MAC, Authenticated Encryption (AE), or digital signatures for authentication. MAC or digital authenticators are used as salt-based integrity checks. MAC is based on either cryptographic hashing or symmetric encryption.

[0110] Upon receiving a new black channel message, the vehicle service subscriber system re-verifies the salt and session key by attempting to authenticate the new black channel message using the session key. If 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 a new session key for the session (612) using the IKM and the new salt, similar to the method described in Reference. Figure 5 Element 504 is illustrated and described in more detail by the vehicle service provider system. 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.

[0111] 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 any future salt messages received during the session. Therefore, the vehicle service subscriber system terminates (616) monitoring of additional salt messages. The salt remains constant throughout the lifetime of the session, so the vehicle service subscriber system stops monitoring salt messages after successfully authenticating the black channel protected message. The vehicle service subscriber system does not become desynchronized with the vehicle service provider system and uses the same session key to authenticate black channel messages from the vehicle service provider system for the duration of the session.

[0112] Figure 7This is 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 using this process is the same as or similar to an AV. In the embodiment, Figure 7 The processing is handled by AV service provider system 704 and AV service subscriber system 708. (Reference) Figure 5 The AV service provider system 704 is described in more detail. The AV service provider system 704 is implemented using at least one processor (e.g., example processor 304).

[0113] AV service subscriber system 708 is one of the vehicle service subscriber systems group, and references Figure 5 A more detailed description follows. The AV service subscriber system 708 is implemented using at least one processor. 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., 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 of the elements of this process. As mentioned above, other embodiments include more, fewer, or different elements, or elements performed in a different order than those depicted.

[0114] In element 712, the AV service provider system 704 generates a salt. For example, see reference... Figure 5 In a more detailed illustration and description, the AV service provider system 704 selects a salt from the entropy pool. (See reference...) Figure 5 In a more detailed illustration and description, the AV service provider system 704 uses IKM and salt to calculate a session key via HKDF. The session key can be adjusted based on the hash algorithm used and its implementation. The AV service provider system 704 uses the session key to initialize its black channel transmitter and broadcasts (716) at least one black channel message to the vehicle service subscriber system group.

[0115] In element 720, AV service subscriber system 708 receives a black channel message but determines that it has not yet received the salt or calculated the session key for the session. AV service subscriber system 708 discards the black channel message and does not attempt to authenticate it. (See reference...) Figure 6As illustrated and described in more detail by element 604, the AV service subscriber system 708 continues to await 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, containing the salt previously generated in element 712. The AV service subscriber system 708 receives the salt. Salt messages are periodically broadcast by the AV service provider system 704 to allow subsequent and re-emerging vehicle service subscriber systems to synchronize with the AV service provider system 704.

[0116] In element 728, AV service subscriber system 708 uses salt and IKM to calculate a session key, similar to the processing performed by AV service provider system 704 in element 712. AV service provider system 704 broadcasts (732) a new black channel message to the vehicle service subscriber system group, which is received by AV service subscriber system 708. AV service subscriber system 708 uses the calculated session key to authenticate (736) the new black channel message and stops monitoring for further salt messages. AV service subscriber system 708 uses the session key to decode or decrypt subsequent black channel messages to provide passengers with a ride in the AV provided by AV service provider system 704.

[0117] The frequency of salt message broadcasting is adjusted based on at least one consideration. In an embodiment, the AV service provider system 704 sends black channel messages at a first frequency greater than or equal to a second frequency of sending salt messages. The frequency of salt message broadcasting determines the latency experienced by the vehicle service subscriber system at startup. Therefore, a higher frequency of salt message broadcasting is desired, and a trade-off is made between this frequency and network overhead. Furthermore, in the first implementation, there will be more black channel protected messages than salt messages. However, in the 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 rapidly.

[0118] Figure 8 This is a flowchart illustrating an example process for generating a session key for AV operation according to at least one embodiment. At least one AV operating using this process is connected to a reference... Figure 1 The AV 100 is the same as or similar to the one illustrated and described in more detail. In the embodiments, Figure 8The processing is performed by a vehicle service provider system. This vehicle service provider system is the same as or similar to 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 of the elements of this processing. Similarly, embodiments may include different, fewer, or additional elements, or perform these elements in a different order.

[0119] In element 804, the vehicle service provider system generates a first salt for encrypting communication sessions with at least one vehicle service subscriber system. In this embodiment, the vehicle service subscriber system is the same as or similar to 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., mobile devices or AV systems) perform some or all of these elements of the process. The AV system is the same as or similar to AV system 120. Similarly, embodiments may include different and / or additional elements, or perform these elements in a different order.

[0120] In one embodiment, the vehicle service provider system selects a first salt from an entropy pool and uses the first salt to compute one or more session keys. The vehicle service provider system uses the session keys to initialize its black channel transmitter, preparing it to send black channel messages to the vehicle service subscriber system group for user scheduling and ride provisioning in AVs. The vehicle service provider system then broadcasts a black channel protected message to the vehicle service subscriber system.

[0121] A salt message containing a first salt generated or selected at startup is periodically broadcast (808). For example, the vehicle service provider system uses a timer to periodically rebroadcast (812) the first salt. In embodiments, 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, etc. The vehicle service provider system may additionally calculate (814) a session key, for example, in a manner similar to that described above with respect to element 504.

[0122] In this embodiment, a key update is triggered for the collection of vehicle service provider systems and the group of vehicle service subscriber systems. For example, a key update is triggered periodically or in response to an event within the system (e.g., a request from a vehicle service subscriber system for a new ride in an AV supplied by the vehicle service provider system, or the commencement of a new ride in an AV). When a key update is required, the vehicle service provider system generates (816) a new (second) salt, and thus a corresponding second session key, and notifies (820) the vehicle service subscriber system group of the change. During the key update, 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 black channel transmitter remain synchronized so that no black channel messages are discarded during session key transitions.

[0123] In this embodiment, the vehicle service provider system initiates a key update for the session by sending a salt update message containing the entropy generated by the vehicle service provider system. For example, if a vehicle service subscriber system has not initiated a key update or contributed entropy within a threshold time period, the vehicle service provider system initiates a key update. The threshold time period is from a few seconds to a few minutes. In this 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 missing 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) to initiate key updates periodically.

[0124] If a malicious entity attempts to force a key update by submitting a synchronization request, the embodiments disclosed herein prevent this by using an adjustable time interval between salt messages and salt update messages. For example, after broadcasting a salt update, the vehicle service provider system increases the frequency of salt messages within a threshold time period. This increased salt message frequency provides the vehicle service subscriber group with an opportunity to resynchronize with the vehicle service provider system. In embodiments, the threshold time period is from a few seconds to a few minutes. In embodiments, the vehicle service provider system broadcasts salt update messages at a higher frequency than salt messages. This increased 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 system security.

[0125] In element 820, the vehicle service provider system broadcasts a salt update message, including a second salt, to the vehicle service subscriber system group. The salt update message is sometimes referred to as an "update." For example, a salt update message is represented as:

[0126]

[0127] In one embodiment, the vehicle service provider system monitors a timer associated with the duration of the first broadcast salt. For example, the duration of the first broadcast salt may range from a few milliseconds to a few seconds. In this 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 broadcast is sent to the vehicle service subscriber system group.

[0128] 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 "second salt" 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 hash functions. In an embodiment, the value of "valid through" is the specific time before the incoming black channel protected message will be protected by the current session key (derived from the first salt).

[0129] In element 824, the vehicle service provider system rebroadcasts the salt update. When a salt update needs to be scheduled, the vehicle service provider system selects an appropriate value for (820) "valid through" and retrieves (816) the new salt from its entropy pool. The vehicle service provider system then begins periodically rebroadcasting (824) the salt update message instead of the original salt message. For example, as... Figure 8 As shown, the timer is used to periodically rebroadcast the salt update message. In this 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.

[0130] At the selected time when "valid through" expires, the vehicle service provider system calculates (828) a second (new) session key and returns it to 816. In this way, a seamless transition to a new session key is possible without discarding messages.

[0131] In an embodiment where a new ride-hailing service subscriber joins a group of ride-hailing service subscribers, for example by requesting a new ride, the new ride-hailing service subscriber waits (820) after an update has been scheduled and broadcast. For example, the new ride-hailing service subscriber waits for the update at 820 or 824 to complete and waits for the new salt to become valid. The new ride-hailing service subscriber then uses the new salt to calculate (828) a session key and attempts to authenticate a black channel protected message to confirm that the calculated session key is correct. In this embodiment, the value of "valid through" is adjusted so that the slower-responding ride-hailing service subscriber has sufficient time to process the salt update message and calculate the new session key before the update occurs.

[0132] Figure 9 This is a timing diagram illustrating an example process for generating a session key 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 the embodiment, Figure 9 The processing is performed by an AV service provider system 704 implemented using at least one processor (e.g., processor 304).

[0133] 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 (e.g., 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 of the elements of this processing. Additionally, embodiments may include elements that are different from, more or fewer than, those depicted, or elements that appear in a different order than those depicted.

[0134] AV service provider system 704 generates the first salt S. For example, AV service provider system 704 generates the first salt S as a vector of pseudo-random values, or as referenced... Figure 5 A more detailed example and description of selecting the first salt S from the entropy pool is provided. (See reference...) Figure 5 In a more detailed illustration and description, the AV service provider system 704 uses the IKM and a first salt S to calculate a session key via the HKDF. The AV service provider system 704 initializes its black channel transmitter using the session key and broadcasts the first salt S to the vehicle service subscriber system group in a salt message. The AV service subscriber system 708 receives the first salt S and calculates the session key from it 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.

[0135] AV service provider system 704 broadcasts black channel message X to the vehicle service subscriber system group using its black channel transmitter. AV service subscriber system 708 receives black channel message X using its black channel receiver. To determine if the correct salt and session key are present, AV service subscriber system 708 attempts to authenticate black channel message X using the session key in element 904. Black channel message X is correctly authenticated. To provide additional security, the embodiments disclosed herein are designed such that AV service provider system 704 broadcasts at least one salt update message between salt changes. To signal potential cyberattacks, 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, AV service subscriber system 708 receives a salt message with a second salt S' from 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.

[0136] To determine the cause of the error, AV service subscriber system 708 checks for additional black channel protected messages received from AV service provider system 704 in element 912. AV service provider system 704 broadcasts black channel message X+1 received by AV service subscriber system 708. In element 912, AV service subscriber system 708 correctly authenticates black channel message X+1 using the session key derived from the first salt S. Next, AV service provider system 704 broadcasts black channel message X+2, which AV service subscriber system 708 receives. In element 916, AV service subscriber system 708 correctly authenticates black channel message X+2 using the session key derived from the first salt S. Since black channel messages X+1 and X+2 continue to be correctly authenticated, the erroneous second salt S' is discarded. The AV service subscriber system 708 sends a message or warning to the AV service provider system 704 or the central server, thereby notifying the AV service provider system 704 or the central server of an erroneous second saltS' and warning of potential replay attacks by potential salt tampering or malicious entities.

[0137] Figure 10 This is a timing diagram illustrating an example process for generating a session key 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 the embodiment, as described above, Figure 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 uses at least one processor (e.g., example processor 304).

[0138] AV service subscriber system 708 is one of the vehicle service subscriber systems group described above, and is implemented using at least one processor, such as processor 304. In other embodiments, other entities (e.g., 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 of the elements of this process. Additionally, other embodiments include more, fewer, or different elements, elements performed in an order different from the depicted order, etc.

[0139] The AV service provider system generates the first salt S with a 704 error. For example, see reference... Figure 5 In a more detailed illustration and description, the AV service provider system 704 selects the first salt S from the entropy pool. (See reference...) Figure 5 In a more detailed illustration and description, the AV service provider system 704 uses the IKM and a first salt S to calculate a session key via the HKDF. The AV service provider system 704 initializes its black channel transmitter using the session key and broadcasts the first salt S to the vehicle service subscriber system group in a salt message. The AV service subscriber system 708 receives the first salt S and calculates the 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.

[0140] AV service provider system 704 broadcasts a first black channel message X to the vehicle service subscriber system group using its black channel transmitter. AV service subscriber system 708 receives the first black channel message X using its black channel receiver. To determine if it has the correct salt and session key, AV service subscriber system 708 attempts to authenticate the first black channel message X using the session key in element 1004. The first black channel message X is successfully authenticated.

[0141] In one embodiment, AV service subscriber system 708 receives a second salt S' from AV service provider system 704. A salt message including the second salt S' indicates that no scheduled salt update associated with the second salt S' exists. AV service subscriber system 708 sends a replay warning message to AV service provider system 704 indicating a possible replay attack. For example, AV service provider system 704 broadcasts an update with the second salt S' to the vehicle service subscriber system group. However, in element 1008, AV service subscriber system 708 misses receiving the update due to network failure, power outage, packet dropping, or other reasons, or combinations thereof.

[0142] AV service provider system 704 broadcasts a second black channel message X+1 to the vehicle service subscriber system group using its black channel transmitter. AV service subscriber system 708 receives the second black channel message X+1 using its black channel receiver. In element 1012, 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 AV service subscriber system 708 is unaware of any salt update). In this embodiment, 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 AV service provider system 704 broadcasts the next black channel message 0. To decrypt black channel message 0, a new session key generated using the second salt S' is required. However, AV service subscriber system 708 still uses the set of previous session keys calculated using the first salt S.

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

[0144] Figure 11 This is a flowchart illustrating an example process for generating a session key 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 the embodiment, Figure 11The processing is performed by a vehicle service provider system, which is the same as or similar to 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 of the elements of this processing. It should be understood that other embodiments include more, fewer, or different elements, or elements in a different order than that described herein.

[0145] 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 communication sessions with at least one vehicle service subscriber system. The vehicle service subscriber system is one in a group of vehicle service subscriber systems. In other embodiments, other entities (e.g., mobile devices or AV systems (e.g., AV system 120)) perform some or all of these elements of the process.

[0146] In one embodiment, the vehicle service provider system selects a first salt from an entropy pool. The vehicle service provider system uses the first salt to calculate a session key. The vehicle service provider system uses the session key to initialize its black channel transmitter, making the black channel transmitter ready to send black channel messages to the vehicle service subscriber system group for user scheduling and ride provisioning in AVs.

[0147] In one 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 the duration for which the first salt is broadcast to the group of vehicle service subscriber systems within a salt message. In response to the timer expiring, the vehicle service provider system broadcasts (1104) a salt message containing the first salt generated or selected at startup. The timer associated with the duration of the first salt broadcast is reset, and the vehicle service provider system periodically rebroadcasts (1104) the 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, etc.

[0148] The embodiments described herein use entropy generated by each vehicle service subscriber system in the vehicle service subscriber system group to update the salt to enhance the security benefits of HKDF. This avoids system sensitivity to entropy weaknesses at the vehicle service provider system. It also prevents vulnerabilities in the vehicle service subscriber system group against replay attacks. The embodiments also prevent vulnerabilities in 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 advanced for the remainder of the session.

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

[0150]

[0151] 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 the validity of the "last salt" field in the synchronization message. For validity, 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.

[0152] In one embodiment, the vehicle service provider system determines that the result of hash-based message authentication of the first salt does not match the "last salt" received from the vehicle service subscriber system in a synchronization message. In response to the determination that the result does not match the "last salt," the vehicle service provider system determines indications of a possible denial-of-service (DoS) attack. For example, to prevent malicious entities from flooding the vehicle service subscriber system group with synchronization messages and triggering numerous session key recalculations, thereby causing a DoS attack on the availability of the central processing unit (CPU) at both 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):

[0153] Finally, salt = HMAC[Kss, current salt||entropy] (2)

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

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

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

[0157] In an embodiment, the vehicle service provider system generates a second salt based on a first salt and 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) with entropy from a received synchronization message. In an embodiment, generating the second salt involves the vehicle service provider system performing an HMAC on the concatenation of the first salt and entropy. For example, the concatenated data is passed through a hash algorithm to produce the value of the second salt. For example, the second salt is generated as in equation (4):

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

[0159] In this embodiment, information identifying the vehicle service provider system (such as name, identifier, or IP address) is included in the cascaded data to enhance data security.

[0160] The vehicle service provider system calculates the (1112) session key based on the second salt. In an embodiment, as referenced... Figure 5 In a more detailed illustration and description, the 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 when the timer expires, the vehicle service provider system generates a second salt. When the second salt is generated, the vehicle service provider system reinitializes its black channel transmitter context using the session key derived from the second salt. In an embodiment that further enhances security, before generating the session key, the vehicle service provider system verifies that a hash-based message authentication performed on 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.

[0161] The vehicle service provider system broadcasts an update (1116) to the vehicle service subscriber system group. The update includes a second salt for decrypting black channel messages using a session key. The black channel messages are used to provide rides 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 extended salt update message is adapted 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:

[0162]

[0163] The "entropy" field in the extended update represents the entropy contributed by at least one vehicle service subscriber system. In this embodiment, security is further enhanced by strengthening salt generation to prevent attackers from forging salt update messages and potentially launching a DoS attack against the vehicle service subscriber system group. Salt generation is strengthened by replacing the cryptographic hash with HMAC to prevent attackers from forging salt update messages. The strengthened salt generation is performed as shown in equation (5):

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

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

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

[0167] In this embodiment, key reuse issues are avoided by using different IKMs.

[0168] The vehicle service provider system periodically rebroadcasts (1116) salt update messages. For example, see reference Figure 8 In a more detailed illustration and description, a timer is used to periodically rebroadcast the salt update message. In an embodiment, the salt update message is broadcast at intervals controlled by the timer (1116) and repeated a maximum of 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, etc. The vehicle service provider system returns to element 1104 to broadcast the second salt to the vehicle service subscriber system group, thereby providing rides in at least one vehicle associated with the vehicle service provider system.

[0169] In one embodiment, the vehicle service provider system uses its computed session key to encrypt black channel messages. (See reference...) Figure 7 In a more detailed illustration and description, the vehicle service provider system sends black channel messages to at least one vehicle service subscriber system in the vehicle service subscriber system group. In an embodiment, the black channel uses a new session key to protect any black channel messages broadcast after the generation of the second salt (1108).

[0170] In this embodiment, the described entropy 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. An 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 this 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.

[0171] In this embodiment, the second salt comprises 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, a first valid synchronization message that passes the verification checks described herein causes the vehicle service provider system to schedule a salt update. The entropy from any synchronization messages received from the group of vehicle service subscriber systems prior to the salt update will be included in the new salt generation.

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

[0173] Figure 12 This is a flowchart illustrating an example process for generating a session key for AV operation according to at least one embodiment. At least one AV operating using this process is connected to a reference... Figure 1 The AV 100 is the same as or similar to the one illustrated and described in more detail. In the embodiments, Figure 12The processing is performed by a vehicle service subscriber system (e.g., an AV service subscriber system 708 implemented using at least one processor such as processor 304) within the vehicle service subscriber system group. In other embodiments, other entities (e.g., 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. Furthermore, other embodiments of this technology include more or fewer elements, different elements, elements performed in an order different from the depicted order, etc.

[0174] At startup, when the vehicle service subscriber system joins a session with the 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.

[0175] In one embodiment, upon startup, when a vehicle service subscriber system attempts to coordinate with a vehicle service provider system to provide a ride to a user or passenger associated with the subscriber system, the subscriber system sends a notification to the vehicle service provider system requesting a new ride. The subscriber system joins a session with both the subscriber system group and 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, the subscriber system receives a salt from the vehicle service provider system. In this embodiment, the salt received from the vehicle service provider system includes or is generated by the vehicle service provider system using pseudo-random data. For example, the pseudo-random data is selected by the vehicle service provider system from its entropy pool. The vehicle service provider system's entropy pool is independent of the entropy generated by the subscriber system.

[0176] Salt will ultimately be used by the transportation service subscriber system to calculate the session key, enabling the system to authenticate and decode (or decrypt) black channel messages from the transportation service provider system in order to offer rides to passengers in AVs associated with or provided by the transportation service provider system. (See reference...) Figure 5 Element 500 illustrates and describes in more detail the transportation service provider system broadcasting a salt message containing salt. The transportation service subscriber system receives the broadcast salt from the transportation service provider system's salt message.

[0177] The transportation service subscriber system is associated with a transportation service subscriber, who can be a user of the mobile device on which the transportation service subscriber system resides, a software client of the transportation service subscriber system, an app running on the mobile device, or a software client running on an AV system (of which the transportation service subscriber system is part). The transportation service subscriber system generates entropy. See reference. Figure 11 In a more detailed illustration and description, entropy is generated by a separate entropy pool from the vehicle service subscriber system and independent of the vehicle service provider system. Entropy is a random value (integer or floating-point), a pseudo-random value, a randomly generated bit vector, or a combination thereof. In an embodiment, the vehicle service subscriber system selects entropy from an entropy pool that is independent of the vehicle service provider system.

[0178] The vehicle service subscriber system sends a synchronization message (1208) to the 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. In element 1204, before sending 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 there is currently no scheduled salt update. The vehicle service provider system discards any synchronization messages received after the broadcast of the salt update has begun. The vehicle service provider system uses a timer to periodically send salts 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, etc. The vehicle service subscriber system sends a (1208) synchronization message in response to receiving a salt message from the vehicle service provider system.

[0179] In response to receiving an update containing the salt (salt update message) from the vehicle service provider system, the vehicle service subscriber system verifies that the salt is 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 is generated using HMAC and entropy generated and sent by the vehicle service subscriber system. For example, once a 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 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 in element 1212 and begins authenticating the black channel protected message.

[0180] In one embodiment, the salt is generated by cryptographically hashing a previous salt (received by the vehicle service provider 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 encrypted text. In one embodiment, if the vehicle service provider system determines that its entropy contribution is not listed or incorporated into the salt update message, or if salt verification fails, the vehicle service provider system retryes the synchronization message element of element 1208. In one embodiment, the vehicle service provider system sends a warning message to the vehicle service provider system indicating a potential replay attack. The vehicle service provider system does not trust broadcast salts until its entropy contribution is incorporated into the salt by the vehicle service provider system. The vehicle service provider system attempts to verify this incorporation, and if the verification is successful, the salt is considered trustworthy by the vehicle service provider system. The vehicle service subscriber system uses only a trusted salt to calculate the session key used to authenticate protected messages from the vehicle service provider system's black channel.

[0181] In this 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 this embodiment, once the vehicle service subscriber system, having successfully completed the synchronization message process in element 1208, receives a salt update message indicating that a salt update has been 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 the new session key. If verification fails, the vehicle service subscriber system retrys the synchronization message process of element 1208.

[0182] In this 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 missing scheduled salt update. In response to receiving the salt message indicating a missing scheduled salt update from the vehicle service provider system, the vehicle service subscriber system retransmits (1208) the synchronization message. In this embodiment, the vehicle service subscriber system determines that the salt excludes entropy. In response, the vehicle service subscriber system sends a message to the vehicle service provider system indicating a possible replay attack. In this embodiment, once the vehicle service subscriber system, which has successfully completed the synchronization message process for element 1208, receives the salt message and the salt value does not match the vehicle service subscriber system's own record, the vehicle service subscriber system retryes the synchronization message process for element 1208.

[0183] Therefore, the embodiments disclosed herein detect and prevent two types of attacks. Prevention of replay attacks: In a replay attack, a malicious entity intercepts salt messages or updates, impersonates a transportation service provider system, and pretends to send messages to a transportation service subscriber system. For example, a malicious entity might attempt a replay attack to extract personal, financial, or confidential information or payments from a transportation service subscriber system. Prevention of DoS attacks: In a DoS attack, a malicious entity intercepts salt messages or updates, impersonates a transportation service subscriber system, and pretends to send messages to a transportation service provider system. A malicious entity might attempt a DoS attack to extract personal, financial, or confidential information from a transportation service provider system, achieving denial of service, or attempt to hijack the transportation service provider system for ransomware purposes.

[0184] In element 1212, the vehicle service subscriber system uses a salt to calculate a session key. 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 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 group of vehicle service subscriber systems. The session key calculated by the first vehicle service subscriber system in element 1212 is the first session key. In element 1216, 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 group of vehicle service subscriber systems. 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 uses the second salt to calculate the second session key. Usage and Reference Figure 11 A more detailed description of the process for calculating the second session key is provided.

[0185] In this 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 the session key calculated based on a salt including entropy from another vehicle service subscriber system fails to authenticate the 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.

[0186] In this embodiment, the vehicle service subscriber system is one of a group of vehicle service subscriber systems. The salt comprises a chained set of elements. Each element in the chained set is generated using different entropies generated by the respective vehicle service subscribers in the group. Therefore, each vehicle service subscriber in the group enhances the security of the other vehicle service subscribers and the vehicle service provider system. For example, further salt updates may occur in element 1208 that are not directly contributed by a particular vehicle service subscriber. By verifying each link in the "salt chain," a particular vehicle service subscriber verifies that its entropy contribution still exists. The "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 in a session. Even a large influx of new vehicle service subscribers entering a session with the vehicle service provider system will not "wash away" existing entropy contributions. If the vehicle service subscriber system detects that the "salt chain" has been broken, it will consider any new salt to be untrustworthy until it contributes more entropy and verifies that the entropy has been incorporated into the salt by the vehicle service provider system.

[0187] A vehicle service subscriber system receives black channel messages from a vehicle service provider system. The subscriber system uses a session key to authenticate the black channel messages, thereby enabling rides to be provided in at least one vehicle associated with the vehicle service provider system. If black channel message authentication fails, the subscriber system moves to element 1204 in processing and waits for the next salt message. In an embodiment, the 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 subscriber system initializes its black channel receiver to receive and decrypt additional black channel messages associated with providing AV rides.

[0188] In this embodiment, in element 1216, the vehicle service subscriber system receives the next update. The vehicle service subscriber system moves to the processing element 1212 and calculates the session key based on the next salt. The vehicle service subscriber system determines that the next update indicates the current salt is valid until a specific time. For example, a "valid through" value is used as an indicator. (See reference...) Figure 8A more detailed description of the "valid through" indicator. The vehicle service subscriber system receives the next salt from the vehicle service provider system in 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 offer rides in vehicles associated with the vehicle service provider system.

[0189] In element 1216, the vehicle service subscriber system periodically receives salt messages containing the current salt from the vehicle service provider system. 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 awaits the next salt message from the vehicle service provider system. For example, as referenced... Figure 8 In a more detailed illustration and description, the vehicle service provider system uses a timer to periodically rebroadcast the salt message. In an embodiment, the salt message is broadcast at intervals controlled by the timer and repeated a maximum of M 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, etc.

[0190] Figure 13 This is a flowchart illustrating an example process for generating a session key 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 the embodiment, Figure 13 The processing 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 processing. Additionally, other embodiments of the processing shown include more, fewer, or different elements, or elements arranged in a different order than those depicted.

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

[0192] The vehicle service provider system starts a timer associated with the duration of a first salt broadcast to the vehicle service subscriber system group within a salt message. In response to the timer expiring, 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 the first salt broadcast is reset, and the vehicle service provider system periodically rebroadcasts (1304) the 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, etc.

[0193] The vehicle service provider system receives a synchronization message (1308) 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 within the vehicle service provider system. Entropy is a random value (integer or floating-point), a pseudo-random value, a randomly generated bit vector, or a combination thereof. The synchronization message is generated by the vehicle service subscriber system to contribute the entropy to the next salt update.

[0194] 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 the validity of the "last salt" field of the synchronization message. For validity, 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.

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

[0196] The vehicle service provider system calculates the (1316) session key based on the second salt. In an embodiment, as referenced... Figure 5 In a more detailed illustration and description, the 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 when the timer expires, the vehicle service provider system generates a second salt. When the second salt is generated, the vehicle service provider system reinitializes its protected message (e.g., black channel message) sender context using the session key derived from the second salt. In an embodiment that further enhances security, before generating the session key, the vehicle service provider system verifies that a hash-based message authentication performed on 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.

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

[0198] The "entropy" field in the extended update represents the entropy contributed by at least one vehicle service subscriber system. In this embodiment, security is further improved by enhancing salt generation to prevent attackers from forging salt update messages and potentially launching a DoS attack against the vehicle service subscriber system group. Salt generation is enhanced by replacing the cryptographic hash with HMAC to prevent attackers from forging salt update messages.

[0199] Figure 14 This is a flowchart illustrating an example process for generating a session key for operation of an AV (e.g., AV 100) according to at least one embodiment. In the embodiment, Figure 14 The processing is performed by a vehicle service subscriber system (e.g., an AV service subscriber system 708 implemented using at least one processor such as processor 304) within the vehicle service subscriber system group. In other embodiments, other entities (e.g., 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. It should be understood that other embodiments of the processing include more or fewer elements, different elements, elements arranged in a different order, etc.

[0200] The vehicle service subscriber system generates (1404) entropy. The vehicle service subscriber system is associated with a vehicle service subscriber, who is a software client running on the vehicle service subscriber system or a user of the vehicle service subscriber system. (See reference...) Figure 11 In a more detailed illustration and description, entropy is generated by a separate entropy pool from the vehicle service subscriber system and independent of the vehicle service provider system. Entropy is a random value (integer or floating-point), a pseudo-random value, a randomly generated bit vector, or a combination thereof. In an embodiment, the vehicle service subscriber system selects entropy from an entropy pool that is independent of the vehicle service provider system.

[0201] A vehicle service subscriber system sends a synchronization message (1408) 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 sending 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 update is currently scheduled. The vehicle service provider system discards any synchronization messages received after the broadcast of the salt update has begun. The vehicle service provider system uses a timer to periodically send salts to the vehicle service subscriber system at regular intervals. The salt message differs 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.

[0202] The vehicle service subscriber system receives (1412) 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 is 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 is 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.

[0203] 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, 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 the protected message. In an embodiment, the salt is generated by using an entropy-based cryptographic hash of the previous salt (received by the vehicle service subscriber system). 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.

[0204] The vehicle service subscriber system verifies (1416) the salt using entropy generation. 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 salt verification fails, the vehicle service subscriber system retrying to synchronize message elements. 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 broadcast salts until its entropy contribution is incorporated into the salt by the vehicle service provider system. The subscriber attempts to verify this incorporation, and if verification is successful, the salt is considered trustworthy by the vehicle service subscriber system. The vehicle service subscriber system uses only trusted salts to calculate the session key used to authenticate protected messages from the vehicle service provider system.

[0205] The vehicle service subscriber system uses a salt to calculate (1420) a session key. The session key is used for communication sessions 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 a first entropy. The vehicle service subscriber system that generates the first entropy is the first vehicle service subscriber system in the group of vehicle service subscriber systems. 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 group of vehicle service subscriber systems. 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 uses the second salt to calculate a second session key. (Usage and References) Figure 11 The process described in more detail is the same or similar process for calculating the second session key.

[0206] The vehicle service subscriber system receives (1424) a protected message from the vehicle service provider system. The vehicle service subscriber system uses a session key to authenticate the protected message, thereby providing 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 the protected message from the vehicle service provider system in response to verifying that the salt is 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 an AV ride.

[0207] The vehicle service subscriber system uses a session key to authenticate (1428) protected messages. The protected messages are used to provide boarding permission for at least one vehicle associated with the vehicle service provider system. If authentication of the protected message using the session key is successful, the vehicle service subscriber system has the correct session key for the session. The vehicle service subscriber system consumes the protected messages and ignores any future salt messages received 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.

[0208] In the preceding description, embodiments of the invention have been described with reference to numerous specific details, which may vary from implementation to implementation. Therefore, the specification and drawings should be considered illustrative rather than restrictive. The sole and exclusive indication of the scope of the invention, and what the applicant expects to be within the scope of the invention, is the literal and equivalent scope of the claims published from this application in the specific form of the published claims, including any subsequent amendments. Any definitions of terms expressly set forth herein for inclusion in such claims should be taken as meaning as such terms are used in the claims. Furthermore, when the term “comprising” is used in the preceding specification or appended claims, the following phrase may be an additional element or entity, or a sub-element / sub-entity of a previously stated element or entity.

Claims

1. A method for a transportation service provider system, comprising: A first salt is broadcast by a vehicle service provider system including at least one processor to at least one vehicle service subscriber system associated with a vehicle service subscriber, the vehicle service provider system being associated with at least one vehicle; The vehicle service provider system receives a synchronization message from the at least one vehicle service subscriber system using the at least one processor; the synchronization message includes entropy. The vehicle service provider system uses the at least one processor to generate a second salt based on the first salt and the entropy; The vehicle service provider system uses the at least one processor to calculate the session key based on the second salt; as well as The transportation service provider system broadcasts an update to the at least one transportation service subscriber system using the at least one processor. The update includes a second salt for decrypting a protected message using the session key, the protected message being used to provide boarding information related to the at least one vehicle. The entropy is generated independently of the vehicle service subscriber system and the vehicle service provider system.

2. The method according to claim 1, wherein, The vehicle service subscriber system includes an autonomous vehicle system associated with the at least one vehicle, and the vehicle service subscriber includes a software client running on the autonomous vehicle system.

3. The method according to claim 1 or 2, wherein, The vehicle service subscriber is associated with a user, and the vehicle service subscriber system includes a user device.

4. The method according to claim 1 or 2, wherein, The session key is calculated using a hashed key derivation function, the input key content, and the second salt.

5. The method according to claim 1 or 2, further comprising: The vehicle service provider system uses the at least one processor and the session key to initialize a protected message transmitter to send the protected message to the at least one vehicle service subscriber system.

6. The method according to claim 1 or 2, further comprising: The transportation service provider system uses the at least one processor to monitor a timer associated with the duration of broadcasting the first salt, wherein, in response to the timer expiring, the update is broadcast to the at least one transportation service subscriber system.

7. The method according to claim 1 or 2, wherein, The entropy is a first entropy, the at least one transportation service subscriber system is a first transportation service subscriber system, the ride is a first ride, and the update is a first update; the method further includes: The transportation service provider system uses the at least one processor to receive a request for a second ride from the second transportation service subscriber system; The transportation service provider system uses the at least one processor to generate a third salt based on the second salt and a second entropy generated by the second transportation service subscriber system; and The vehicle service provider system uses the at least one processor to broadcast a second update to the at least one vehicle service subscriber system and the second vehicle service subscriber system, the second update including the third salt.

8. The method according to claim 1 or 2, wherein, Generating the second salt includes: hash-based message authentication of the concatenation of the first salt and the entropy by the vehicle service provider system using the at least one processor.

9. The method according to claim 1 or 2, wherein, The second salt comprises a hash of multiple entropy values, each of which is received by the vehicle service provider system from the corresponding vehicle service subscriber system.

10. The method according to claim 1 or 2, wherein, The synchronization message is the first synchronization message, and the method further includes: Following the broadcast of the update, the vehicle service provider system receives the second synchronization message using the at least one processor; and In response to the broadcast of the update, the vehicle service provider system discards the second synchronization message using the at least one processor.

11. The method according to claim 1 or 2, wherein, The synchronization message also includes a previous salt, and the method further includes the vehicle service provider system using the at least one processor to verify, before calculating the session key, that a hash-based message authentication performed on the concatenation of the previous salt and the entropy matches the second salt.

12. The method according to claim 1 or 2, further comprising: The protected message is encrypted using the session key by the vehicle service provider system using the at least one processor; as well as The protected message is sent by the vehicle service provider system to the at least one vehicle service subscriber system using the at least one processor.

13. The method according to claim 1 or 2, wherein, The first frequency at which the vehicle service provider system sends the protected message is greater than or equal to the second frequency at which the first salt is sent.

14. The method of claim 1 or 2, further comprising broadcasting the second salt to the at least one transportation service subscriber system by the transportation service provider system using the at least one processor to provide rides in the at least one transportation vehicle.

15. The method of claim 14, further comprising: The vehicle service provider system monitors a timer associated with the duration of the broadcast update, wherein the second salt is broadcast in response to the timer expiring.

16. The method according to claim 1 or 2, further comprising: The vehicle service provider system determines, using the at least one processor, that the result of hash-based message authentication of the first salt does not match a previous salt, wherein the synchronization message also includes the previous salt; and In response to the determination that the result does not match the previous salt, the vehicle service provider system uses the at least one processor to determine an indication of a possible denial-of-service attack.

17. The method according to claim 1 or 2, wherein, The protected message is a black channel message.

18. A transportation service provider 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 provider system to perform the method according to any one of claims 1 to 17.

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

20. A computer program product comprising instructions that, when executed by at least one computer processor of a transportation service provider system, cause the transportation service provider system to perform the method according to any one of claims 1 to 17.

Images