Validating vehicles traveling within specific regions

A system comprises a computer including a processor and a memory. The memory storing instructions executable by the processor to transmit an authentication request to a vehicle computer, receive, from the vehicle computer, a response including data proving that the vehicle computer includes confidential information, wherein the data does not convey the confidential information, determine whether the response is valid based on the authentication request, and transmit a warning to the vehicle computer when the response is not valid.

BACKGROUND

In some instances, vehicles that transport goods are required to provide credentials at checkpoints to verify those vehicles are authorized to travel and/or transport goods within a specific region. Typically, the credentials include personally identifiable information, such as license plate numbers, vehicle identification numbers (VINs), or the like.

DETAILED DESCRIPTION

Transportation-as-a-Service (TaaS), or Mobility-as-a-Service (MaaS), involves providing transportation solutions to consumers as a service. Transportation solutions can include the transportation of customers or the transportation of goods for customers. In some instances, entities, such as governmental entities, e.g., Federal Aviation Administration, may restrict the third-party transportation of goods through specified regions. In these instances, these entities may require a TaaS provider to register vehicles used in the transportation of goods. Registration information/data may be stored in publicly available data logs, such as blockchains. For example, the entities may store information regarding approved TaaS operators in a blockchain. As vehicles that transport goods travel through various regions, the entities may require periodic auditing of the vehicle's credentials to travel within the region. During the audit, the entities may be privy to operator data that results in data asymmetry between the operator and the auditing entity.

A system comprises a computer including a processor and a memory. The memory storing instructions executable by the processor to transmit an authentication request to a vehicle computer, receive, from the vehicle computer, a response including data proving that the vehicle computer includes confidential information, wherein the data does not convey the confidential information, determine whether the response is valid based on the authentication request, and transmit a warning to the vehicle computer when the response is not valid.

In other features, the authentication request comprises at least one point to be evaluated by the vehicle computer and the response comprises an evaluation of a polynomial using the at least one point.

In other features, the vehicle computer causes at least one vehicle system to actuate based on the warning.

In other features, the vehicle computer is disposed within a vehicle.

In other features, the vehicle comprises at least one of a land vehicle, an aerial vehicle, or an aquatic vehicle.

In other features, the processor is further programmed to determine whether the vehicle is authorized to travel within a specific region based on the response.

In other features, the processor is further programmed to receive a registration corresponding to the vehicle computer, the registration including vehicle information, generate a private key and a public key corresponding to the vehicle computer, wherein the private key and the public key are indicative of a specific region that the vehicle is allowed to travel, store the public key and the vehicle information in a blockchain block, and transmit the private key to the vehicle computer.

In other features, the private key comprises a polynomial.

In other features, the processor is further programmed to determine whether a communication link is established with the vehicle computer, retrieve the public key and the vehicle information from the blockchain block based on a communication packet received from the vehicle computer, and generate the authentication request based on at least one of the public key or the vehicle information.

In other features, the processor is further programmed to determine whether the response is valid by applying a blind evaluation of a polynomial protocol to the response.

A method comprises transmitting an authentication request to a vehicle computer, receiving, from the vehicle computer, a response including data proving that the vehicle computer includes confidential information, wherein the data does not convey the confidential information, determining whether the response is valid based on the authentication request, and transmitting a warning to the vehicle computer when the response is not valid.

In other features, the authentication request comprises at least one point to be evaluated by the vehicle computer and the response comprises an evaluation of a polynomial using the at least one point.

In other features, the vehicle computer causes at least one vehicle system to actuate based on the warning.

In other features, the vehicle computer is disposed within a vehicle.

In other features, the vehicle comprises at least one of a land vehicle, an aerial vehicle, or an aquatic vehicle.

In other features, the vehicle comprises an autonomous vehicle.

In other features, the method further comprises receiving a registration corresponding to the vehicle computer, the registration including vehicle information, generating a private key and a public key corresponding to the vehicle computer, wherein the private key and the public key are indicative of a specific region that the vehicle is allowed to travel, storing the public key and the vehicle information in a blockchain block, and transmitting the private key to the vehicle computer.

In other features, the private key comprises a polynomial.

In other features, the method further comprises determining whether a communication link is established with the vehicle computer, retrieving the public key and the vehicle information from the blockchain block based on a communication packet received from the vehicle computer, and generating the authentication request based on at least one of the public key or the vehicle information.

In other features, the method further comprises determining whether the response is valid by applying a blind evaluation of a polynomial protocol to the response.

The present disclosure is directed to systems and methods that allow vehicles that transport goods to provide authorized travel credentials through privacy preserving protocols, such as Zero-Knowledge Proofs. Thus, the vehicle, in response to an authentication request, may provide a response that indicates the vehicle is authorized to travel within the region and that does not provide personally identifiable information. Personally identifiable information may be user identification, vehicle identification numbers, license plate numbers, and the like.

A blockchain is a distributed electronic ledger. Each blockchain node stores a local copy of the same blockchain ledger. When a blockchain node generates a new block and proposes to link with a previous block, the previous block is stored locally at the generating node as well as all other nodes on the same blockchain. Each blockchain node verifies the new block against their local copy to determine whether consensus is reached within the network. If consensus is reached, the new block is added by each node to their local copy.

The blockchain stores data based on generation of hashes for blocks of data. A hash in the present context is a one-way encryption of data having a fixed number of bits. An example of hash encryption is SHA-256. The hashes provide links to blocks of data by identifying locations of the block of data in storage (digital memory), for example by use of an association table mapping the hashes of the storage locations. An association table provides a mechanism for associating the hash (which may also be referred to as a hash key) with an address specifying a physical storage device either in a vehicle or a stationary location. The hash for the block of data further provides a code to verify the data to which the hash links. Upon retrieving the block of data, a computer can recompute the hash of the block of data and compare the resulting hash with the hash providing the link. In the case that the recomputed hash matches the linking hash, the computer can determine that the block of data is unchanged. Conversely, a recomputed hash that does not match the linking hash indicates that the block of data or the hash has been changed, for example through corruption or tampering. The hash providing the link to a block of data may also be referred to as a key or a hash key.

FIG. 1is a block diagram of an example system100that includes a vehicle105, a network device110, a Domain Name Server (DNS) device113, and a server115within a communication environment120. In an example implementation, the communication environment120corresponds a specific region in which the vehicle105may be authorized to travel. While illustrated as within the communication environment120, it is understood that the server115may be located in other regions or environments.

As disclosed in greater detail herein, as the vehicle105travels through the communication environment120, the network device110may initiate communication with the vehicle105. The server115, via the network device110, may transmit an authentication request to the vehicle105to ensure the vehicle105has proper credentials to travel within the environment120. In an example implementation, the authentication request is a Zero-Knowledge Proof (ZKP) challenge. In response to the authentication request, the vehicle105may transmit a response to the server115verifying the vehicle105has proper credentials to travel within the environment120. In the example implementation, the verification is a ZKP generated response based on the ZKP challenge. For example, the ZKP response may provide sufficient proof that the vehicle105is associated with a private key authorizing the vehicle105to travel within the specific environment120while not providing the private key. It is understood that the ZKP protocols discussed herein may be implemented as interactive ZKP challenges or non-interactive ZKP challenges.

The ZKP is a protocol by which one party, the vehicle105, can prove to another party, such as a verifier, the server115, that a given statement is true without conveying any information apart from the fact that the statement is indeed true. For example, the ZKP is a protocol related to two or more parties and includes a series of steps adopted by the two or more parties to complete a task. In this context, the prover proves to the verifier that the prover has certain confidential information without revealing the confidential information to the verifier. Within the present context, the vehicle105may provide a response indicating the vehicle105is associated with a private key distributed by the server115.

The server115generates a custom request corresponding to the vehicle105. For example, when communication has been established, communication packets transmitted by the vehicle105can include an Internet Protocol (IP) address. The server115can provide the vehicle's105IP address to the DNS device113, and the DNS device113can return information corresponding to the IP address. For example, the DNS device113may return a domain name mapped to the IP address. The server115can access a blockchain (seeFIG. 3) to retrieve information corresponding to the vehicle105. For example, the server115may use the domain name to retrieve provided information pertaining to the vehicle105based on the domain name. The information may have been provided to the server115during registration. Additionally, the information includes a public key generated by the server115for the vehicle105. Using the retrieved information and/or the domain name, the server115generates the custom ZKP challenge for the vehicle105.

The system100may utilize one or more suitable ZKP protocols for verification purposes. In an example implementation, the system100may employ ZKP responses having Homomorphic Hiding (HH) properties. Homomorphic Hiding properties may include:For a given number x, it is hard to find x given function E(x);Different inputs correspond to different outputs—so if x≠y (where y is a number), then E(x)≠E(y); andIf a party knows E(x) and E(y), that party can generate the HH of arithmetic expressions in x and y. For example, the party can compute E(x+y) from E(x) and E(y).

In an example, the computer210can prove to the computer235that the computer210has access to x and y such that x+y=10. The vehicle105computer210may transmit E(x) and E(y) to the computer235, and the computer235computes E(x+y) from E(x) and E(y). The computer235also computes E(10) to determine whether E(x+y) equals E(10) and accepts the proof provided by the computer210.

Using the HH properties, the computers210,235may incorporate a blind evaluation of a polynomial protocol for authentication purposes. Within the current context, the computer210may include a polynomial P of degree d, and the computer235may include a point s E Fprandomly selected by the computer235, where Fpincludes the elements {0, . . . , p−1} and addition and multiplication are computed using mod p, where p is a prime number. A polynomial P of degree d over Fpcan take the form as represented in Equation 1:
P(X)a0+a1·X+a2·X2+ . . . +ad·Xd.  Eq. 1.

The polynomial P can be evaluated at point s∈Fpby substituting the point s for X as represented in Equation 2:
P(s)=a0+a1·s+a2·s2+ . . . +ad·sd,  Eq. 2.

For an entity that knows P, the value P(s) is a linear combination of values 1, s, sdand a0. . . adrepresent weights of the polynomial P(s). As discussed above, the HH properties allow the function E(x+y) to be computed from E(x) and E(y). In this context, given a, b, E(x), and E(y), an entity can compute E(ax+by) because of the following mathematical relations:
E(ax+by)=gax+by=gax·gby=(gx)a·(gy)b=E(x)a·E(y)b.

The computer235may transmit an authentication request according to the blind evaluation of a polynomial protocol. For instance, the computer235may request a solution to E(P(s)), and the computer210possesses the polynomial P. The blind evaluation may be performed by (Step 1) the computer235transmitting E(1), E(s), . . . , E(sd) to the computer210, and (Step 2) the computer210computes E(P(s)) from the elements transmitted in Step 1. The computer210then transmits the solution E(P(s)) to the computer235for verification purposes. The computer235can compute E(P(s)) because the function E supports linear combinations, and P(s) is a linear combination of 1, s, . . . , sd.

In an example implementation, a private key of a private/public key pair provided to vehicle105may comprise a polynomial. The polynomial may correspond to the public key, e.g., another polynomial, stored by the server135. The private/public key pair can indicate specific regions that the vehicle105is approved to travel in. For example, to ensure that the vehicle105is authorized to transport goods within the region, the server135may request that the vehicle105computer210evaluate the vehicle's105polynomial at numerical values, e.g., points selected by the server135. In response, the vehicle105computer210evaluates, i.e., computes, the polynomial at the selected values and provides the computed values to the server135. Based on the computed values, the server135determines whether the vehicle105computer210is in possession of the correct polynomial.

As shown inFIG. 1, the server115is connected to the network device110and the DNS device113via a communication network130. The network130can be one or more of various wired or wireless communication mechanisms, including any desired combination of wired (e.g., cable and fiber) and/or wireless (e.g., cellular, wireless, satellite, microwave, and radio frequency) communication mechanisms and any desired network topology (or topologies when multiple communication mechanisms are utilized). Exemplary communication networks include wireless communication networks (e.g., using Bluetooth®, Bluetooth® Low Energy (BLE), IEEE 802.11, vehicle-to-vehicle (V2V) such as Dedicated Short-Range Communications (DSRC), etc.), local area networks (LAN) and/or wide area networks (WAN), including the Internet, providing data communication services.

FIG. 2Ais a block diagram of an example vehicle control system200. The system200includes a vehicle105, which can be a land vehicle such as a car, truck, etc., an aerial vehicle such as a drone, or an aquatic vehicle, such as a boat. The vehicle105includes a computer210, vehicle sensors215, actuators220to actuate various vehicle components225, and a vehicle communications module230. Via a network, the communications module230allows the computer210to communicate with the network device110and/or the server115.

The computer210includes a processor and a memory. The memory includes one or more forms of computer-readable media, and stores instructions executable by the computer210for performing various operations, including as disclosed herein.

The computer210may operate a vehicle105in an autonomous, a semi-autonomous mode, or a non-autonomous (manual) mode. For purposes of this disclosure, an autonomous mode is defined as one in which each of vehicle105propulsion, braking (e.g., stopping), and steering are controlled by the computer210; in a semi-autonomous mode the computer210controls one or two of vehicles105propulsion, braking, and steering; in a non-autonomous mode a human operator controls each of vehicle105propulsion, braking, and steering.

The computer210may include programming to operate one or more of vehicle105brakes, propulsion (e.g., control of acceleration in the vehicle by controlling one or more of an internal combustion engine, electric motor, hybrid engine, etc.), steering, climate control, interior and/or exterior lights, etc., as well as to determine whether and when the computer210, as opposed to a human operator, is to control such operations. Additionally, the computer210may be programmed to determine whether and when a human operator is to control such operations.

The computer210may include or be communicatively coupled to, e.g., via the vehicle105communications module230as described further below, more than one processor, e.g., included in electronic controller units (ECUs) or the like included in the vehicle105for monitoring and/or controlling various vehicle components225, e.g., a powertrain controller, a brake controller, a steering controller, etc. Further, the computer210may communicate, via the vehicle105communications module230, with a navigation system that uses the Global Position System (GPS). As an example, the computer210may request and receive location data of the vehicle105. The location data may be in a known form, e.g., geo-coordinates (latitudinal and longitudinal coordinates).

The computer210is generally arranged for communications on the vehicle105communications module230and also with a vehicle105internal wired and/or wireless network, e.g., a bus or the like in the vehicle105such as a controller area network (CAN) or the like, and/or other wired and/or wireless mechanisms.

Via the vehicle105communications network, the computer210may transmit messages to various devices in the vehicle105and/or receive messages from the various devices, e.g., vehicle sensors215, actuators220, vehicle components225, a human machine interface (HMI), etc. Alternatively or additionally, in cases where the computer210actually comprises a plurality of devices, the vehicle105communications network may be used for communications between devices represented as the computer210in this disclosure. Further, as mentioned below, various controllers and/or vehicle sensors215may provide data to the computer210.

Vehicle sensors215may include a variety of devices such as are known to provide data to the computer210. For example, the vehicle sensors215may include Light Detection and Ranging (lidar) sensor(s)115, etc., e.g., disposed on a top of the vehicle105, behind a vehicle105front windshield, around the vehicle105, etc., that provide relative locations, sizes, and shapes of objects and/or conditions surrounding the vehicle105. As another example, one or more radar sensors215, e.g., fixed to vehicle105bumpers may provide data to provide and range velocity of objects (possibly including second vehicles106), etc., relative to the location of the vehicle105. The vehicle sensors215may further include camera sensor(s)215, e.g. front view, side view, rear view, etc., providing images from a field of view inside and/or outside the vehicle105.

The vehicle105actuators220are implemented via circuits, chips, motors, or other electronic and or mechanical components that can actuate various vehicle subsystems in accordance with appropriate control signals as is known. The actuators220may be used to control components225, including initiating operation, braking, acceleration, steering, and/or control of the vehicle105.

In the context of the present disclosure, a vehicle component225is one or more hardware components adapted to perform a mechanical or electro-mechanical function or operation—such as moving the vehicle105, slowing or stopping the vehicle105, steering the vehicle105, etc. Non-limiting examples of components225include a propulsion component (that includes, e.g., an internal combustion engine and/or an electric motor, etc.), a transmission component, a steering component (e.g., that may include one or more of a steering wheel, a steering rack, etc.), a brake component, a park assist component, an adaptive cruise control component, an adaptive steering component, a movable seat, etc.

In addition, the computer210may be configured for communicating via a vehicle-to-vehicle communication module or interface with devices outside of the vehicle105, e.g., through a vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2X) wireless communications to another vehicle. The module230could include one or more mechanisms by which the computer210may communicate, including any desired combination of wireless (e.g., cellular, wireless, satellite, microwave and radio frequency) communication mechanisms and any desired network topology (or topologies when a plurality of communication mechanisms are utilized). Exemplary communications provided via the module230include cellular, Bluetooth®, IEEE 802.11, dedicated short range communications (DSRC), and/or wide area networks (WAN), including the Internet, providing data communication services.

FIG. 2Bis a block diagram of an example server115. The server115includes a computer235and a communications module240. The computer235includes a processor and a memory. The memory includes one or more forms of computer-readable media, and stores instructions executable by the computer235for performing various operations, including as disclosed herein. The communications module240allows the computer235to communicate with other devices within the respective environment120. In one or more implementations, the server115may operate one or more aspects of the blockchain within a trusted execution environment (TEE). For example, the server115may include suitable hardware, software, firmware, or combinations thereof to execute the functionality described herein.

FIG. 3illustrates example blocks305,310of a blockchain300stored by the blockchain nodes. It is understood that the blockchain300can include additional or fewer blocks. Each block305,310maintains verified records315,320. The records315,320represent events, records, and/or transactions that have been executed between two or more participants within the blockchain300. Each record315,320is verified by a majority of the blockchain nodes. It is understood that the records315,320can correspond to financial transactions and/or to non-financial transactions, e.g., transportation records, public keys, authorized transporters. The blocks305,310also includes a respective header325,330including a hash. The hash is derived from the contents of the records315,320in the respective block305,310and can be used to connect blocks305,310.

Within the present context, the blocks305,310can store public identifiable information corresponding to the vehicle105. In an example implementation, the vehicle's105owner registers the vehicle105with a government entity. The registration can include public vehicle information, such as public identification information, corresponding to the vehicle105, and the public vehicle information can be stored in the blocks305,310of the blockchain. The government entity, in turn, can provide a credential indicating the vehicle105is authorized to transport goods within the environment120. The credentials for the vehicle105can be stored in the vehicle105computer210.

FIG. 4is a flowchart of an exemplary process400for receiving a request to register the vehicle105with an entity, such as a government entity, that provides certifications for transporting goods and/or traveling within specified regions. Blocks of the process400can be executed by the computer235of the server115, and the server115is associated with the entity.

The process400begins at block405in which the computer235receives a request to register the vehicle105with the entity such that the vehicle105is approved to transport goods within the environment120. For example, the computer235may receive a registration request from a TaaS operator via another computing device. The registration request can include vehicle information corresponding to the vehicle105, such as a public identification information, or the like. At block410, the computer235generates a private key corresponding to the vehicle105. As discussed herein, the private key may be provided to the TaaS operator indicating the registered vehicle105is approved to transport goods within the environment120and is associated with at least one of multiple public keys authenticated by the server115. In some implementations, the private key and corresponding public key comprise a polynomial.

At block415, the computer235associates an authenticated public key with the vehicle information for the vehicle105. At block420, the vehicle information is stored in the blockchain300. The private key is transmitted to the computing device of the TaaS operator at block425. The TaaS operator may provide the private key to the vehicle105for storage in some implementations.

FIG. 5illustrates an example flow diagram of a process500for validating the vehicle105within the environment120. Blocks of the process500can be executed by the computer235of the server115. The process500begins at block505in which a determination is made by the computer235whether communication has been established with a vehicle105. For example, as the vehicle105is traveling through the environment120, the vehicle105computer210may establish communication with the network device110and/or the server115. If communication has not been established, the process500returns to block505.

If communication is established, the computer235requests data pertaining to the vehicle105from the DNS device113and/or the blockchain300at block510. For example, the server115passes the IP address of the vehicle105to the DNS113. The DNS113retrieves domain name data pertaining to the vehicle105based on the IP address and transmits the retrieved domain name data to the server115. The server115also retrieves vehicle105information from the blockchain300. For example, the server115can retrieve the vehicle105data and/or public key information from the blockchain300using the domain name data.

At block515, the computer235generates the authentication request based on the retrieved vehicle105data and/or domain name data. For example, the authentication request can be generated, in part, based on a public key corresponding to the vehicle105, a domain name corresponding to the vehicle105, an IP address corresponding to the vehicle105, or the like. The authentication request can be generated in accordance with the blind evaluation of a polynomial protocol. In an example implementation, the authentication request comprises one or more selected points used to evaluate a polynomial, and the selected points may be randomly selected by the server115.

At block520, the computer235transmits the authentication request to vehicle105. At block525, a determination is made whether a ZKP response has been received from the vehicle105computer210. The response may be one or more computed values corresponding to the selected points and the selected points. If no response has been received, the process500returns to block520. As discussed above, the ZKP response can be generated by the computer210based on the private key of the vehicle105.

If a response has been received, the computer235determines whether the ZKP response is authenticated, i.e., valid, at block530to determine whether the vehicle105is authorized to travel within the environment120. The computer235can apply a suitable ZKP verification algorithm to the received ZKP response to determine whether the ZKP response is authenticate, i.e., that the vehicle approved to travel within the specific region. For instance, the ZKP response compare the computed values with corresponding computed values generated by the server115computer235. The corresponding computed values can be generated by evaluating the public key with the selected points and comparing the evaluated public key with the received ZKP response. If the response is validated, the vehicle105is approved to travel within the specific region.

If the ZKP response is not authenticated, the computer235may transmit a warning to the vehicle105regarding the non-authenticated ZKP response at block535. In response to receiving the warning, one or more vehicle systems may be actuated. For instance, the vehicle systems may be actuated by the computer210to cause the vehicle105to discontinue operation or to travel to a predetermined location within the environment120. Otherwise, the process500ends.

FIG. 6is a flowchart of an exemplary process600for generating and providing a ZKP response. Blocks of the process600can be executed by the computer210of the vehicle105. The process600begins at block605in which computer210establishes communication with the server115, i.e., the entity. In an example implementation, the server115may cause the network device110to broadcast signals within the communication environment120. The vehicle105communication module230can detect the signals and establishes communication via a suitable communication protocol with the server115. At block610, a determination is made whether an authentication request has been received. If no authentication request has been received, the process600returns to block610. If the authentication request has been received, the computer210generates the ZKP response (ZKP proof) at block615. The computer210can generate the ZKP response in accordance with the blind evaluation of a polynomial protocol. As discussed above, the computer210evaluates the polynomial using one or more selected points.

At block620, the computer210transmits the ZKP response and the authentication request, e.g., selected points, to the server115. At block625, a determination is made whether a warning has been received. If a warning is received, the computer210can actuate one or more vehicle systems at block630. In some implementations, the actuation may be based on instructions encoded in the warning communication or subsequent communications provided by the server115.

With regard to the media, processes, systems, methods, heuristics, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes may be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps may be performed simultaneously, that other steps may be added, or that certain steps described herein may be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments, and should in no way be construed so as to limit the claims.