Patent Description:
As computers have become ever more miniaturized and commoditized, manufacturers are producing more and more varied devices that include one or more embedded computer or processor. The computer in a computerized device can control the device's operation; collect, store, and share data; communicate with other computers and other computerized devices; and update its own software, among other things.

The Internet of things (IoT) is the network of computerized physical devices that have embedded processor(s), electronics, software, data, sensors, actuators, and/or network connectivity, which enable these devices to connect and exchange data via digital networks, including the Internet, cellular networks, and other wireless networks. Typically, each "thing" is uniquely identifiable through its embedded computing system, and is able to communicate and inter-operate within the existing Internet infrastructure.

"Things", in the loT sense, can refer to a wide variety of computerized devices, such as consumer appliances, enterprise devices used in business and corporate settings, manufacturing machines, farming equipment, energy-consuming devices in homes and buildings (switches, power outlets, bulbs, televisions, etc.), medical and healthcare devices, infrastructure management devices, robots, drones, and transportation-related devices and vehicles, among many others.

For example, most, if not all, modern vehicles (e.g., cars, trucks, aircraft, trains, watercraft, and the like) contain several embedded processors or embedded computers in their subsystems, and are computer-controlled in at least some aspects. Similarly, a growing number of modern transportation infrastructure devices (e.g., traffic lights, traffic cameras, traffic sensors, bridge monitors, bridge control systems, and the like) contain at least one, and often many, embedded processors or embedded computer systems, and are computer-controlled in at least some aspects. These computer-controlled elements of the transportation network typically communicate with each other, passing various types of information back and forth, and they may react, respond, change their operation, or otherwise depend upon the information received/sent from/to other vehicles in Vehicle-to-Vehicle (V2V; also known as C2C, Car-to-Car) communications and/or from/to infrastructure elements in Vehicle-to-Infrastructure (V2I, also known as C2I, Car-to-lnfrastructure) communications for safe, correct, efficient, and reliable operation. These elements, communications, actions, and interactions may be collectively referred to as a V2X environment, where X represents any device, including another vehicle.

The computers in computerized devices operate according to their software and/or firmware and data in conjunction with the operation of their hardware, (such as processors, memory, busses, etc.), and the input data that the computerized devices use, (such as data from other devices; for example, location data (e.g., from a GPS device), speed data, braking data, time data, temperature data, etc.). Problems with software, data, hardware, or inputs can cause a computerized device to operate in an aberrant or anomalous manner, such that the device behaves in a way that deviates from its standard, normal, or expected behavior. Such problems may be unintentional, such as a problem caused by the failure of a hardware device or an unintentional bug in software; or intentional, such as a problem caused by unauthorized persons or organizations (e.g., hackers) replacing or changing the software in a computerized device.

Accordingly, it is desirable to provide improved systems, methods and techniques for securely identifying computerized devices that are behaving in an anomalous or aberrant manner, for example, in order to reduce or stop the effects of their misbehavior on other devices and their environment. <NPL>) proposed a security credential management system for V2X communications, which was related art of the present invention.

The present invention is directed to subject-matter as disclosed by the appended claims.

The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate implementations of the invention and together with the description, serve to explain the principles of the invention. In the figures:.

Reference will now be made in detail to various implementations of the invention, examples of which are illustrated in the accompanying drawings. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

Although the following description uses vehicular and transportation-infrastructure computerized devices (such a vehicles with OBUs and ECUs; and RSUs) as specific examples for clarity of explanation, the invention is not limited to those specific types of devices. Various implementations consistent with the invention may be used with and for a wide variety of computerized devices, such as medical devices (e.g., dialysis machines, infusion pumps, etc.); robots; drones; autonomous vehicles; various Internet of Things (IoT) devices; and wireless communication modules (e.g., embedded Universal Integrated Circuit Cards (eUICC)), among others.

Vehicle to vehicle (V2V) is an automobile technology designed to allow automobiles to communicate with each other. Vehicle to Infrastructure integration (V2I) is a series of technologies that link road vehicles to their physical surroundings. Both technologies together may be referred to as a V2X environment, which includes a primary goal of improving road safety.

In the V2X environment, a security asset (e.g., a digital asset related to security, such as pseudonym certificate) can be used to authorize and enable an entity (e.g., a V2X device, such as a vehicle) to participate and communicate in the V2X environment. Unlike traditional X. <NUM> certificates, the pseudonym certificates do not carry the identity of their entity within them; thus, an external observer cannot link their use with a particular vehicle or device. Additionally, after initial installation at manufacturing time, the security assets used in the V2X devices, including pseudonym certificates, are periodically changed and replenished or re-provisioned during the devices' operational lives.

This creates several technical problems in trying to match a given pseudonym certificate to the correct V2X device that used it; or in other words, in trying to identify the correct device (e.g., vehicle) that used a given pseudonym certificate.

Members of the V2X environment, such as cars and trucks, may behave in an anomalous or aberrant manner, which may be referred to as misbehaving or misbehavior. Misbehaving vehicles are typically detected by other members of the V2X environment; e.g., by other vehicles or by transportation infrastructure devices. In the V2X environment, however, the only available "identification" of a misbehaving vehicle is its pseudonym certificate(s), which are received by the detecting vehicle in communications from the misbehaving vehicles.

When a vehicle, or other member of the V2X environment, misbehaves, then it is desirable to identify the vehicle and to reduce or stop undesirable or negative effects caused by its misbehavior, for example by "removing" the misbehaving device from the V2X environment. A misbehaving vehicle may negatively affect the V2X environment by, for example, communicating erroneous, false, or misleading information to other vehicles or infrastructure devices, which may cause the other vehicles or devices to act or react inappropriately. One example of a way to remove a misbehaving vehicle from the V2X environment is to notify or direct the other members of the V2X environment (e.g., other cars and trucks and infrastructure devices) to disregard or ignore communications from the misbehaving vehicle.

<FIG> is a block diagram showing an example of a system <NUM> for identifying misbehaving vehicles <NUM> using a cloaking authority <NUM>, which is consistent with implementations of the invention. As shown in the example of <FIG>, the system <NUM> includes a conventional V2X environment <NUM>, which includes reporting vehicles <NUM>, each of which has a group of unique pseudonym certificates (PCs) <NUM> assigned to it, and misbehaving vehicles <NUM>, each of which has a group of unique PCs <NUM> assigned to it, as is known in the art.

A reporting vehicle <NUM> may receive wireless V2V communications <NUM> from a misbehaving vehicle <NUM>, and the V2V communications <NUM> may include the currently in-use PC <NUM> of the misbehaving vehicle <NUM>. Based on the V2V communications <NUM>, the reporting vehicle <NUM> may determine that the misbehaving vehicle <NUM> is acting in an aberrant or anomalous manner. For example, the reporting vehicle <NUM> may detect and be triggered to report misbehavior by the vehicle <NUM> when the vehicle <NUM> communicates data or information that conflicts with or is incompatible with the data and information known to the reporting vehicle <NUM>, for example, when the misbehaving vehicle <NUM> claims to occupy the same physical space as another vehicle on the road; i.e., the misbehaving vehicle <NUM> communicates <NUM> its GPS coordinates as being the same coordinates communicated by another vehicle or the same coordinates as the reporting vehicle <NUM>. In some other examples, the reporting vehicle <NUM> may report misbehavior when it detects that the misbehaving vehicle <NUM> claims to be in a location that the camera of the reporting vehicle <NUM> senses as being unoccupied, or when it detects that the misbehaving vehicle <NUM> claims to be travelling at an implausible speed (e.g. 200mph), or when it detects other aberrant or anomalous data or information from the misbehaving vehicle <NUM>.

Upon detecting the misbehavior, the reporting vehicle <NUM> may wirelessly send a misbehavior report (MBR) <NUM> to a misbehavior authority (MA) <NUM>, as is known in the art. The MBR <NUM> contains the currently in-use PC <NUM> of the reporting vehicle <NUM>, and the currently in-use PC <NUM> of the misbehaving vehicle <NUM>, among other things.

The MA <NUM> may be implemented as a server or other computer (e.g., a device having at least one processor and associated memory). In various implementations, the MA <NUM> functions to receive, log, and process MBRs <NUM> from the devices in the V2X environment <NUM>, and to make decisions related to protecting the V2X environment <NUM> from the misbehaving vehicle <NUM>, for example, by revoking <NUM> the communication privileges and/or other privileges of the misbehaving vehicles <NUM> within the V2X environment <NUM>. In other words, the misbehaving vehicle <NUM> is removed, in a virtual sense, from the V2X environment <NUM>. In various implementations consistent with the present disclosure, the MA <NUM> also securely communicates with a cloaking authority (CLA) <NUM> in order to obtain an identifier for the misbehaving vehicle <NUM>, where the identifier can be used to classify the vehicle <NUM> as misbehaving based on a "global" group or series of MBRs <NUM> and/or to take remedial action against the misbehaving vehicle <NUM>. In various implementations, the MA <NUM> may also perform recording or logging functions, such as storing information reflecting the communications received by the MA <NUM>, (such as the MBRs <NUM> and the cloak-index response <NUM> received by the MA <NUM>); the communications transmitted by the MA <NUM>, (such as cloak-index requests <NUM> sent to the CLA <NUM>); the remedial actions taken by the MA <NUM>, (such as revocation messages or commands <NUM> sent by the MA <NUM>); and the like.

The CLA <NUM> may be implemented as a server or other computer (e.g., a device having at least one processor and associated memory). In various implementations, and as explained in detail below, the CLA <NUM> functions to interact with a pseudonym certificate authority (PCA) <NUM> and a registration authority (RA) <NUM> to obtain data that identifies the misbehaving vehicle <NUM> from its PC <NUM>. The CLA <NUM> also generates a unique identifier from the data, where the unique identifier also identifies the misbehaving vehicle <NUM>. In the examples shown, the unique identifier may be referred to as a cloak index and may be stored in a cloak index table <NUM>. Although described as a table herein, in various implementations the cloak index table <NUM> may be implemented as any type of data structure or data associated with each other. The CLA <NUM> also communicates the generated unique identifier for the misbehaving vehicle <NUM> (e.g., the cloak index) to the MA <NUM>. In various implementations, the CLA <NUM> may also perform recording or logging functions, such as storing information reflecting the communications received by the CLA <NUM>, (such as cloak-index requests received by the CLA <NUM>); the communications transmitted by the CLA <NUM>, such as cloak-index responses sent to the MA210); and the like.

During operation of the system <NUM>, a reporting vehicle <NUM> reports to the MA <NUM>, via an MBR <NUM>, a detected misbehaving vehicle <NUM>. As is known in the art, and by design of the V2X environment <NUM>, however, the reporting vehicle <NUM> cannot specifically identify the misbehaving vehicle <NUM>, for example by make, model, VIN, license plate number, or the like. The only identification that is associated with the misbehaving vehicle <NUM> and known to the reporting vehicle <NUM> is the pseudonym certificate (PC) <NUM> that is included with the V2V communications <NUM> sent by the misbehaving vehicle <NUM>. By design, the members of the V2X environment <NUM> and the MA <NUM> do not know which PC came from, or is associated with, which vehicle.

Again by design, the PC <NUM> used and transmitted by the misbehaving vehicle <NUM> is changed over time, for the purpose of preserving the anonymity of the vehicle <NUM>. The same is true for all of the vehicles in the V2X environment. For example, when the reporting vehicle <NUM> sends a misbehavior report <NUM> to the MA <NUM>, the misbehavior report <NUM> includes the PC <NUM> currently in use by the reporting vehicle <NUM>, and the PC <NUM> is changed over time; i.e., a new PC <NUM> is periodically placed into service by the reporting vehicle <NUM>, and the old one is no longer used.

Thus, the misbehavior report <NUM> does not permanently identify the offending vehicle <NUM> or the reporting vehicle <NUM> because the pseudonym certificates <NUM>, <NUM> in the report <NUM> rotate in and out of use over time. The identities of the vehicles <NUM>, <NUM> in the V2X environment <NUM> are purposely obfuscated by the PCs, which are designed to prevent anyone from tracking particular vehicles (and their drivers) via the vehicles' communications within the V2X environment <NUM>.

This makes it technically difficult to detect repeated misbehavior by the same vehicle and to identify the misbehaving vehicle <NUM> in a manner that allows the misbehaving vehicle <NUM> can be removed from the V2X environment <NUM>, if needed. Repeatedly misbehaving vehicles (e.g., vehicles that demonstrate multiple misbehaviors, which may be referred to as global misbehavior) may, for a few examples, include: a single vehicle that is reported as misbehaving by a significant number of other vehicles (e.g. more than a predetermined threshold number or more than a threshold number above the average number); a single vehicle that reports, erroneously, a significant amount of misbehavior by other vehicles (e.g. more than a predetermined threshold amount or more than a threshold amount above the average amount); a vehicle whose misbehavior reports couldn't have been generated truthfully (e.g., a vehicle that appears to send a report from California and then an hour later appears to send a report from New Jersey); and vehicles with something in common that report on misbehaviors or are reported on as misbehaving significantly more often than the norm (for example, all <NUM> Ford Focuses built in a certain manufacturing plant-the misbehaviors may be indicative of a manufacturer's design, hardware, or software defect in the vehicles).

From a V2X environment standpoint, the misbehaving vehicle <NUM> needs to be identified positively in order to remove it from the environment <NUM>, and from a vehicle original equipment manufacturer's (OEM) or supplier's standpoint, misbehaving vehicles <NUM> need to be identified positively in order to detect and correct problems in certain groups of vehicles or their on-board equipment (e.g., via a recall).

There is currently nothing in the conventional V2X environment <NUM> that can identify a misbehaving vehicle <NUM> based on the misbehavior reports <NUM> (e.g., based on the PCs <NUM> in the misbehavior reports) caused by or associated with the misbehaving vehicle <NUM> because the PCs <NUM> are technologically designed not to identify their vehicle <NUM> during use of the PCs <NUM> in the V2X environment <NUM>. The systems, methods, and devices described in this disclosure introduce a new component--the cloaking authority (CLA) <NUM>--which can identify a misbehaving vehicle <NUM> based on its misbehavior reports <NUM>, which include its PCs <NUM>.

After receiving the MBR <NUM> from the conventional V2X environment <NUM> (e.g., from a reporting vehicle <NUM>), the MA <NUM> securely sends the MBR to the CLA <NUM>. As explained in detail below, the CLA <NUM> securely contacts the PCA <NUM> with at least a portion of the information from the PC <NUM> and in response gets a hash (or other representation) of the RA-to-PCA pseudonym certificate request (HPCR) that originally generated the PC <NUM> when the PC <NUM> was created. The RA-to-PCA pseudonym certificate request originally came from the RA <NUM> when the PC <NUM> was created. The CLA <NUM> then securely contacts the RA <NUM> with the HPCR to get a representation (e.g., a hash) of the HPCR's linkage chain index (LCI), which identifies the misbehaving vehicle <NUM> in the sense that the LCI is associated with a single vehicle for which specific PCs were originally created.

in various implementations, using the LCI from the RA <NUM> as a seed, the CLA <NUM> generates a random valued index, which is referred to as a cloak index, which uniquely identifies the misbehaving vehicle <NUM> for which the PC <NUM> was originally created, and returns the index to the MA <NUM>. In various implementations, the cloak index may be stored in the cloak index table <NUM> of the CLA <NUM>. If the MA <NUM> later sends the CLA <NUM> another MBR <NUM> having a different PC <NUM> from the same vehicle <NUM>, then the CLA <NUM> will return the same cloak index in response after processing the MBR <NUM>.

In various embodiments, the CLA <NUM> may perform similar processing for the PC <NUM> of the reporting vehicle <NUM> to generate a cloak index that identifies the reporting vehicle <NUM>. The cloak index of the reporting vehicle <NUM> may be used by the MA <NUM> to determine whether or not the reporting vehicle <NUM> is misbehaving, for example, by sending out erroneous MBRs <NUM>, or by using PCs that were not generated for it.

In some embodiments, the CLA <NUM> may store the cloak index in the cloak index table <NUM> only temporarily, based on frequency of usage; i.e., frequency of MBRs <NUM> that map to the same cloak index. For example, if the cloak index has a resetting time to live (TTL) period of two weeks after the last matching inquiry, then if the CLA <NUM> does not receive a pertinent MBR <NUM> at least every <NUM> days, then the CLA <NUM> deletes that cloak index from the index table <NUM>. This prevents the CLA <NUM> and the MA <NUM> from keeping vehicle-identifying information indefinitely. Thus, implementations consistent with the present disclosure may generate a temporary cloak index that provides the technical advantage of enabling the MA <NUM> to detect misbehavior over time by the same vehicle despite the anonymity and variability of PCs, while reducing the possibility of compromising any vehicle's anonymity over a long period.

Because the CLA <NUM> responds with the same cloak index for a given misbehaving vehicle <NUM> regardless of which PC <NUM> the vehicle <NUM> is currently using, and regardless of which PC <NUM> the vehicle <NUM> switches to over time, the MA <NUM> can determine, based on a group or set of MBRs <NUM> whether or not the particular vehicle <NUM> is "globally" misbehaving, even though the MBRs contain different PCs <NUM>.

For example, if the MA <NUM> determines that the vehicle assigned cloak index "<NUM>" by the CLA <NUM> has caused <NUM> MBRs from <NUM> different reporting vehicles, then the MA <NUM> may classify the "<NUM>" vehicle as a misbehaving vehicle and may initiate remedial action, such as revocation <NUM>. For another example, if the MA <NUM> determines that the vehicle assigned cloak index "<NUM>" by the CLA <NUM> sent MBRs from California and from New Jersey within an hour of each other, (which may indicate that one or both of the vehicles in California or New Jersey is/are using an illegitimate PC that was not generated for it), then the MA <NUM> may classify the "<NUM>" vehicle as a misbehaving vehicle and may initiate remedial action. For yet another example, if the MA <NUM> determines that the vehicle assigned cloak index "<NUM>" by the CLA <NUM> sent MBRs reporting <NUM> other vehicles as misbehaving within <NUM> hours, (which may indicate that the reporting vehicle "<NUM>" is sending false or erroneous MBRs), then the MA <NUM> may classify the "<NUM>" vehicle as a misbehaving vehicle and may initiate remedial action. In various implementations, remedial action may include adding the misbehaving vehicle to the certification revocation list (CRL), as is known in the art, so that the misbehaving vehicle will no longer be able to communicate with other devices in the V2X environment <NUM>, and/or may include reporting the identity of the misbehaving vehicle(s) to the OEM.

In various implementations, in order to take remedial action against a misbehaving vehicle, the MA <NUM> may determine the actual linkage chain identification (LCI) of the misbehaving vehicle, which corresponds to the cloak index provided by the CLA <NUM>. The actual linkage chain identification may be used to add the misbehaving vehicle to the CRL, or to report the misbehaving vehicle back to the OEM. In some further implementations, the system <NUM> may include a server, database, or the like (not shown) that stores vehicle information (e.g., VIN, make, model, device serial number, etc.) in association with the LCI for the vehicle, which may be populated at manufacturer and replenishment time, when a vehicle is provisioned with PCs. In such implementations, the MA <NUM> (or the CLA <NUM>) may query this storage for make/model or other useful information to further the remedial efforts and/or report the information to the OEM, which may investigate and debug problems with the vehicle or with problematic models of vehicles.

In other implementations along similar lines, the system <NUM> may include a server, database, or the like (not shown) that can determine and return meta-characteristics about a group of HPCRs (or the like) that have been reported as misbehaving. Examples of such meta-characteristics include that a group of HPCRs are all from the same model vehicle, a group of HPCRs are all from vehicles that contain the same type of OBU, a group of HPCRs are all from vehicles that contain the same firmware version, and the like. Such meta-characteristics would, for example, enable OEMs to identify and correct problems or defects in vehicles of a certain type, make, model, year, etc. and in some cases the corrections may be done (e.g., using an over-the-air software update) before the vehicles are revoked or removed from the V2X environment <NUM> and/or recalled. Such meta-characteristics may also, for example, enable the system <NUM> to allow certain special vehicles, such as emergency vehicles, to remain in the V2X environment <NUM> even though they are misbehaving, and to notify the operators of those vehicles that the vehicles need to be repaired to correct the misbehavior.

One of ordinary skill will recognize that the components, processes, data, operations, and implementation details shown in <FIG> are examples presented for conciseness and clarity of explanation. Other components, processes, implementation details, and variations may be used without departing from the principles of the invention, as this example is not intended to be limiting and many variations are possible. For example, although only one misbehaving vehicle <NUM>, only one reporting vehicle <NUM>, only one MA <NUM>, and only one CLA <NUM> are shown in <FIG>, other implementations may have any number of each of these entities.

<FIG> is a block diagram illustrating an example of the components and process for generating a cloak index request in a system for a cloaking authority, consistent with implementations of the invention.

As shown in this example, a vehicle <NUM> transmits a MBR <NUM> to the MA <NUM>, which receives and processes the MBR <NUM>. The MBR <NUM> contains the PC <NUM> of the reporting vehicle <NUM> and the PC <NUM> of the offender, i.e., of the misbehaving vehicle <NUM>. In various implementations the MBR <NUM> contains other data, such as information describing the type of report; location information, information describing the anomalous action of the misbehaving vehicle <NUM>, time information, information about V2V communications between the vehicles, and the like.

The MA <NUM> extracts data from the received MBR <NUM> and processes the data to create a cloak-index request <NUM> for the CLA <NUM>.

In some implementations, as shown in <FIG>, the MA <NUM> may extract the PC <NUM> of the misbehaving vehicle <NUM> (and/or the PC <NUM> of the reporting vehicle <NUM>) from the MBR <NUM> and then extract a linkage value L from the PC <NUM>. The MA <NUM> may encrypt the linkage value LPCA for the PCA <NUM>; i.e., using a key from the PCA <NUM> so that only the PCA <NUM> can decrypt the linkage value LPCA. In various implementations, the LPCA may include a timestamp so that the LPCA or the cloak-index request <NUM> containing the LPCA cannot be reused by an unauthorized person who intercepts or compromises the cloak-index request <NUM> to make their own requests to the CLA <NUM> in a replay attack or the like.

The linkage value is used by the system <NUM> to anonymously identify the vehicle from which the PC <NUM> came; the linkage value links a PC back to the vehicle or device to which the PC was issued or provisioned, although it does not provide a direct or straightforward linkage because the V2X environment <NUM> is designed to maintain vehicle anonymity. The linkage value can also be used by vehicles in the V2X environment <NUM> to determine whether the device associated with the linkage value is on a certificate revocation list (CRL), and if so to ignore its communications.

In some implementations, as shown in <FIG>, the MA <NUM> also generates a cryptographic nonce, which is combined with the MBR <NUM> and hashed, and in some implementations the hash output H may be used for system accounting or auditing purposes.

In the example shown, the MA <NUM> creates a cloak-index request message <NUM> that contains the nonce, the hash H of the nonce and the MBR <NUM>, and the encrypted pseudonym certificate's linkage value LPCA. By hashing the MBR <NUM> and encrypting the PC <NUM>'s linkage value LPCA, the MA <NUM> prevents the CLA <NUM> from having any vehicle-identifying information because that information is encrypted for the PCA <NUM> and the CLA <NUM> does not have the key to decrypt it. Because the linkage value is encrypted for the PCA, the CLA <NUM> cannot obtain any information about the PC--all the CLA <NUM> knows is that the MA <NUM> sent it a cloak-index request <NUM>.

To secure the cloak-index request <NUM>, the MA <NUM> may cryptographically sign the cloak-index request <NUM> using its cryptographic key.

After processing the received MBR <NUM> to create the cloak-index request message <NUM>, the MA <NUM> transmits the cloak-index request message <NUM> to the CLA <NUM>.

With respect to the accounting or auditing uses of the hashed MBR <NUM>, in some implementations, the hashed MBR <NUM> allows an auditor to match cloak-index requests <NUM> that were received and logged by the CLA <NUM> with the corresponding MBRs <NUM> that were received and logged by the MA <NUM> and to verify that every cloak-index requests <NUM> was triggered by a MBR <NUM>. This type of accounting or auditing may be done periodically (e.g., ever three months or every six months or the like) and would detect a situation where the MA <NUM> has been compromised or is malfunctioning and is sending cloak-index requests <NUM> that are not based on a MBR <NUM>, e.g., a cloak-index request <NUM> that uses a PC from any vehicle, whether misbehaving or not.

<FIG> is a block diagram illustrating an example of a process for a request for a hash of a pseudonym certificate in a system for a cloaking authority, consistent with implementations of the invention. As shown in this example, the CLA <NUM> receives the cloak-index request <NUM>, and as explained in more detail below, the CLA <NUM> communicates with the PCA and the RA to get a hashed linkage chain identification (hashed LCI), which is an indicator, such as a unique number, that identifies a specific vehicle based on the PCs assigned to that vehicle, because every PC assigned to a given vehicle (or device) has the same LCI. An LCI has a one-to-one correspondence with a vehicle (or device) and distinguishes a given vehicle from all of the other vehicles and devices in the V2X environment <NUM>.

As shown in this example, the CLA <NUM> transmits <NUM> the encrypted linkage value LPCA and a copy of the cloak-index request <NUM> signed by the MA <NUM> to the PCA <NUM>. The encrypted linkage value LPCA can only be decrypted by the PCA <NUM>.

The PCA <NUM> decrypts the linkage value LPCA and verifies that the cloak-index request <NUM> is valid by verifying the cryptographic signature of the MA <NUM> on the cloak-index request <NUM>, which ensures that the cloak-index request <NUM> was originated by the MA <NUM>. In some implementations, the PCA <NUM> may optionally communicate <NUM> with the MA <NUM> after receiving the cloak-index request <NUM> and request that the MA <NUM> verify that it sent that cloak-index request <NUM> before the CLA <NUM> processes the request <NUM> and <NUM>. This option would prevent the PCA <NUM> from responding to a fake or unauthorized cloak-index request <NUM> that did not truly come from the MA <NUM>.

The PCA <NUM> looks up the hash of the RA-to-PCA pseudonym certificate request (HPCR) using the decrypted linkage value L, for example, as an index.

As is known in the art, this look-up is based on the way pseudonym certificates are generated and provisioned in the standard V2X environment <NUM>. With respect to the background workings of the V2X environment <NUM>, at vehicle manufacture time and at subsequent PC replenishment times, a vehicle sends a request to the RA <NUM> to get a bundle or group of PCs (e.g., the group of PCs <NUM>) from the RA <NUM>. The RA <NUM> interacts with the PCA <NUM> and two linkage authorities (not shown) to generate and provide the bundle of PCs to the requesting vehicle. For example, a given vehicle <NUM> may send an initial request for a group or bundle of <NUM> PCs <NUM> to the RA <NUM> at vehicle manufacture time, and in response the RA <NUM> may create and send <NUM> individual RA-to-PCA requests for a PC to the PCA <NUM>. In order to correlate the resulting PCs with the requesting vehicle <NUM>, the RA <NUM> hashes each individual RA-to-PCA request for a PC, which creates a hash result representing the RA-to-PCA request (referred to as an HPCR), and includes the hash result (i.e., the HPCR) with each of the <NUM> RA-to-PCA requests that it sends to the PCA <NUM>. In addition, the RA <NUM> assigns at least one linkage chain ID (LCI) to the requesting vehicle <NUM>, and stores all of the HPCRs generated for the vehicle <NUM> in association with that LCI(s), such that every HPCR for a given vehicle is associated with the same LCI(s) and such that the RA <NUM> can look up the LCI(s) using an HPCR. Note that although the conventional RA <NUM> of the current V2X environment uses two LCIs, for ease and clarity of explanation, the examples used herein generally refer to only one LCI. Implementations consistent with the invention, nonetheless, include implementations that use two or more LCIs.

At about the same time as the vehicle <NUM>, other new vehicles are requesting bundles of PCs from the RA <NUM> along with vehicle <NUM>, and thus the RA has to fulfill a large number of requests. For instance, if a thousand vehicles each ask for <NUM> PCs, then the RA <NUM> will send <NUM>,<NUM>,<NUM> RA-to-PCA requests for individual PCs to the PCA <NUM>. The RA <NUM> will typically shuffle the order of the RA-to-PCA requests so that the PCA <NUM> cannot correlate any group or sequence of RA-to-PCA requests with any particular vehicle or with each other.

In response to each RA-to-PCA request, the PCA <NUM> creates a new PC. When it creates a new PC, which includes a linkage value L, the PCA <NUM> stores the linkage value L in association with the HPCR that was included in each request and in a manner that allows the PCA <NUM> to look up the HPCR using the linkage value L. The PCA <NUM> sends the newly created PC to the RA <NUM>. The PCA <NUM> may encrypt each PC for the vehicle (i.e., so that it can only be decrypted by the vehicle) such that the RA <NUM> cannot see the contents of the PC.

Because the RA <NUM> receives each PC in response to a RA-to-PCA request that it made to the PCA <NUM>, and because each RA-to-PCA request it made to the PCA <NUM> was correlated, using the HPCR, to a PC bundle request received from a specific vehicle <NUM> via the LCI, the RA <NUM> can determine which PCs <NUM> were generated for and go to that specific vehicle <NUM>. Thus, the hash of the RA-to-PCA request (the HPCR) is information that allows the RA <NUM> to correlate a newly created PC with a specific vehicle and to provision the newly created PC to that specific vehicle.

Concluding the discussion of the background workings of the V2X environment <NUM> and referring again to the example shown in <FIG>, using the decrypted linkage value L, the PCA <NUM> consults its stored records and looks up or otherwise determines the hashed RA-to-PCA request (HPCR) that it received from the RA <NUM> and in response to which it created the PC that contains the linkage value L. After it retrieves the HPCR that corresponds to the PC that contains to linkage value L, the PCA <NUM> encrypts a copy of the HPCR for the RA <NUM>, (so that, e.g., the CLA <NUM> cannot access the HPCR), and the PCA <NUM> transmits <NUM> the encrypted HPCR to the CLA <NUM>.

The CLA <NUM> receives the message with the encrypted HPCR and transmits <NUM> the encrypted HPCR to the RA <NUM>.

The RA <NUM> receives that message and decrypts the encrypted HPCR to verify that the message is valid. The RA <NUM> then uses the decrypted HPCR to look up the stored linkage chain ID(s) (LCI) that corresponds to the HPCR, and that indicates the vehicle to which the RA-to-PCA request maps. Referring to the earlier example where the vehicle <NUM> requested a group of <NUM> PCs at manufacture time, the RA <NUM> would have stored <NUM> HPCRs that map to the same LCI and thus to the same vehicle <NUM>. In various implementations, the LCI may be or represent actual information about the identity of the vehicle <NUM> within the V2X environment <NUM> (and in some embodiments, using information outside of the conventional V2X environment <NUM>, the LCI may be mappable to real world identification information, such as a vehicle ID number, etc.). In order to keep that information secure, the RA <NUM> may hash the LCI with a static cryptographic nonce before responding to the CLA <NUM>. The RA <NUM> then responds by transmitting <NUM> the hashed LCI to the CLA <NUM>. Because both of the inputs are deterministic (i.e., the LCI does not change and the static nonce does not change), the hash algorithm will produce the same hash value every time it is run for a given vehicle <NUM> (i.e., for the LCI associated with a given vehicle). Thus, the CLA <NUM> (and other entities) cannot tell what the value of the LCI was, but it can tell from the hash value that it was the same LCI.

The hashed LCI that the CLA <NUM> receives maps or corresponds to the PC which was used by the MA <NUM> in the cloak-index request <NUM>. However, neither the true LCI nor the linkage value of the PC from the vehicle <NUM>, <NUM> can be determined by the CLA <NUM> because that information is securely encrypted as it passes through the CLA <NUM>.

<FIG> is a block diagram illustrating an example of a process for generating a cloak index in a system for a cloaking authority, consistent with implementations of the invention. As shown in this example, the CLA <NUM> looks to see if a hashed LCI that was received <NUM> from the RA <NUM> is in the cloak index table <NUM> (e.g., in other words, has the MA <NUM> previously sent a request <NUM> that corresponded to this hashed LCI).

If the received hashed LCI is not stored in the cloak index table <NUM>, then the CLA <NUM> creates a new, random cloak index that corresponds to the received hashed LCI and transmits the new cloak index to the MA <NUM> in a response message <NUM>. The CLA <NUM> also stores a copy of the new cloak index in the cloak index table <NUM>. In various implementations, the CLA <NUM> may store the new cloak index by adding a row to the cloak index table <NUM>, where the row includes information or fields that hold the hashed LCI, the new cloak index, the creation time and date of the new cloak index and the most-recent query time and date for the new cloak index, (which may be the same as the creation time and date when the new cloak index is initially added to the table).

If, on the other hand, the received hashed LCI <NUM> is already stored in the cloak index table <NUM>, then the CLA <NUM> finds the corresponding, previously generated cloak index in the same row of the cloak index table <NUM>, transmits that cloak index to the MA <NUM> in a response message <NUM>, and updates the query time corresponding to that cloak index in the cloak index table <NUM>.

In various implementations, when a cloak index (e.g., a row) in the cloak index table <NUM> has not been queried for a predetermined amount of time after the last query time (e.g. a predetermined TTL time such as six days, two weeks, three weeks, one month, or the like), the CLA <NUM> may delete that cloak index's entry (e.g., row) from the cloak index table <NUM>. In such implementations, the CLA <NUM> does not keep records for a cloak index, (which corresponds to a hashed LCI, which corresponds to a specific vehicle), for an indefinite amount of time.

In some implementations in which the range of the values of the cloak index is limited to relatively small number of bits (e.g., <NUM> or <NUM>), the CLA <NUM> may reuse cloak indexes as cloak index rows (which indirectly correspond to specific vehicles), are aged out of the cloak index table <NUM> according to the predetermined TTL value. In such implementations, after the CLA <NUM> deletes a row, the CLA <NUM> may generate a new random cloak index sometime in the future that could be the same as a cloak index that it has used before. And in such implementations, the response <NUM> to the MA <NUM> may indicate whether the cloak index is being reused, such that the MA <NUM> can treat the reused cloak index as corresponding to a different vehicle than the vehicle to which the reused cloak index previously corresponded.

Among others, a new technical advantage of the systems and processes described above with respect to <FIG> is that the CLA <NUM> never gets any unencrypted information about any of the vehicles and it cannot decrypt the information that passes through it. Because of this secure and anonymous handling of the identifying information, if the CLA <NUM> were compromised by a malicious actor, the malicious actor could not track or learn anything about any of the vehicles and devices in the V2X environment <NUM>. Nor could the malicious actor use the CLA <NUM> to trigger processing in the MA210, the PCA <NUM> or the RA <NUM> because the CLA <NUM>'s processing requires the MA <NUM> to cryptographically sign the message <NUM> that the CLA <NUM> passes to the PCA <NUM>. Because the CLA <NUM> cannot cryptographically sign messages as if it was the MA <NUM>, the PCA <NUM> will not process or react to any message that the CLA signs on its own.

One of ordinary skill will recognize that the components, processes, data, operations, and implementation details shown in <FIG> are examples presented for conciseness and clarity of explanation. Other components, processes, implementation details, and variations may be used without departing from the principles of the invention, as this example is not intended to be limiting and many variations are possible.

<FIG> is a block diagram of an example of a computing environment, which includes a computing system <NUM> that may be used for implementing systems and methods consistent with implementations of the invention. Other components and/or arrangements may also be used. In some implementations, the computing system <NUM> may be used to implement, at least partially, various components of <FIG>, such as the CLA <NUM> and the MA <NUM>, among other things. In some implementations, a series of computing systems similar to the computing system <NUM> may be each customized with specialized hardware and/or programmed as a specialized server to implement one of the components of <FIG>, which may communicate with each other via a network <NUM>.

In the example shown in <FIG>, the computing system <NUM> includes a number of components, such as a central processing unit (CPU) <NUM>, a memory <NUM>, an input/output (I/O) device(s) <NUM>, and a nonvolatile storage device <NUM>. The system <NUM> can be implemented in various ways. For example, an implementation as an integrated platform (such as a server, workstation, personal computer, laptop, etc.) may comprise a CPU <NUM>, a memory <NUM>, a nonvolatile storage <NUM>, and I/O devices <NUM>. In such a configuration, the components <NUM>, <NUM>, <NUM>, and <NUM> may connect and communicate through a local data bus and may access a data repository <NUM> (implemented, for example, as a separate database system) via an external I/O connection. The I/O component(s) <NUM> may connect to external devices through a direct communication link (e.g., a hardwired or local wifi connection), through a network, such as a local area network (LAN) or a wide area network (WAN, such as a cellular telephone network or the Internet), and/or through other suitable connections. The system <NUM> may be standalone or it may be a subsystem of a larger system.

The CPU <NUM> may be one or more known processor or processing devices, such as a microprocessor from the Core™ family manufactured by the Intel™ Corporation of Santa Clara, CA or a microprocessor from the Athlon™ family manufactured by the AMD™ Corporation of Sunnyvale, CA. The memory <NUM> may be one or more fast storage devices (e.g., solid state devices) configured to store instructions and information executed or used by the CPU <NUM> to perform certain functions, methods, and processes related to implementations of the present invention. The storage <NUM> may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, or other type of storage device or computer-readable medium, including devices such as CDs and DVDs and solid state devices, meant for long-term storage.

In the illustrated implementation, the memory <NUM> contains one or more programs or applications <NUM> loaded from the storage <NUM> or from a remote system (not shown) that, when executed by the CPU <NUM>, perform various operations, procedures, processes, or methods consistent with the present disclosure. Alternatively, the CPU <NUM> may execute one or more programs located remotely from the system <NUM>. For example, the system <NUM> may access one or more remote programs via the network <NUM> that, when executed, perform functions and processes related to implementations of the present disclosure.

In one implementation, the memory <NUM> may include a program(s) <NUM> for performing the specialized functions and operations described herein for the CLA <NUM> and/or the MA <NUM>. In some implementations, the memory <NUM> may also include other programs or applications that implement other methods and processes that provide ancillary functionality to the implementations disclosed herein.

The memory <NUM> may be also be configured with other programs (not shown) unrelated to the invention and/or with an operating system (not shown) that performs several functions well known in the art when executed by the CPU <NUM>. By way of example, the operating system may be Microsoft Windows™, Unix™, Linux™, an Apple Computers™ operating system, or other operating system. The choice of operating system, and even to the use of an operating system, is not critical to the invention.

The I/O device(s) <NUM> may include one or more input/output devices that allow data to be received and/or transmitted by the system <NUM>. For example, the I/O device <NUM> may include one or more input devices, such as a keyboard, touch screen, mouse, and the like, that enable data to be input from a user. Further, the I/O device <NUM> may include one or more output devices, such as a display screen, a CRT monitor, an LCD monitor, a plasma display, a printer, speaker devices, and the like, that enable data to be output or presented to a user. The I/O device <NUM> may also include one or more digital and/or analog communication input/output devices, such as network cards and USB cards and the like, that allow the computing system <NUM> to communicate, for example, digitally, with other machines and devices, including via the network <NUM>. Other configurations and/or numbers of input and/or output devices may be incorporated in the I/O device <NUM>.

In the implementation shown, the system <NUM> is connected to the network <NUM> (such as the Internet, a private network, a virtual private network, a cellular network or other network or combination of these), which may in turn be connected to various systems and computing machines (not shown), such as servers, personal computers, laptop computers, client devices, etc. In general, the system <NUM> may input data from external machines and devices and output data to external machines and devices via the network <NUM>.

In the exemplary implementation shown in <FIG>, the repository <NUM> is a standalone data storage external to system <NUM>, such as a standalone database. In other implementations, the repository <NUM> may be hosted by the system <NUM>. In various implementations, the repository <NUM> may manage and store data used to implement systems and methods consistent with the invention. For example, the repository <NUM> may manage and store data structures that implement the cloak index table <NUM>, that contain the audit logs of the MA <NUM> and/or the CLA <NUM>, and the like.

The repository <NUM> may comprise one or more databases that store information and are accessed and/or managed through the system <NUM>. By way of example, the repository <NUM> may be an Oracle™ database, a Sybase™ database, or other relational database. Systems and methods consistent with the invention, however, are not limited to separate data structures or databases or particular types of databases, or even to the use of a database or data structure.

One of ordinary skill will recognize that the components and implementation details of the system in <FIG> are examples presented for conciseness and clarity of explanation. Other components and implementation details may be used.

Although the foregoing description uses specific examples of computerized devices in the V2X environment <NUM>, such as vehicles, OBUs, ECUs, and RSUs, for clarity of explanation, the invention is not limited to those specific examples. Various implementations consistent with the invention may be used with and for a wide variety of computerized devices, including IoT devices, and additional examples include medical device (e.g., dialysis machines, infusion pumps, etc.); robots; drones; autonomous vehicles; and wireless communication modules (e.g., embedded Universal Integrated Circuit Cards (eUICC)), among others.

Claim 1:
A system (<NUM>) for identifying a misbehaving computerized device (<NUM>), the system (<NUM>) comprising:
a misbehavior authority device (<NUM>) that receives a report (<NUM>) about the misbehaving computerized device (<NUM>), wherein the report (<NUM>) includes a pseudonym certificate (<NUM>) from the misbehaving computerized device (<NUM>), and wherein the pseudonym certificate (<NUM>) includes a linkage value;
a cloaking authority device (<NUM>) that is communicatively connected to the misbehavior authority device (<NUM>), and that receives a request (<NUM>) for a cloak index from the misbehavior authority device (<NUM>), wherein the request (<NUM>) for the cloak index includes the linkage value;
a pseudonym certificate authority device (<NUM>) that is communicatively connected to the cloaking authority device (<NUM>), and that receives, from the cloaking authority device (<NUM>), a message that includes the linkage value, and that transmits a message, to the cloaking authority device (<NUM>), that includes a hash of a pseudonym certificate request, HPCR, that caused the pseudonym certificate (<NUM>) to be generated; and
a registration authority device (<NUM>) that is communicatively connected to the cloaking authority device (<NUM>), and that receives, from the cloaking authority device (<NUM>), a message that includes the HPCR, and that transmits a message, to the cloaking authority device (<NUM>), that includes a hash of a linkage chain identifier that corresponds to the pseudonym certificate (<NUM>) and that identifies the misbehaving computerized device (<NUM>);
wherein the cloaking authority device (<NUM>) determines the cloak index, which corresponds to the linkage chain identifier and which identifies the misbehaving computerized device (<NUM>), and transmits the cloak index to the misbehavior authority device (<NUM>); and
wherein the determined cloak index is either created by the cloaking authority device (<NUM>) in response to the request (<NUM>) from the misbehavior authority (<NUM>), or has been previously created by the cloaking authority device (<NUM>) in response to a prior request from the misbehavior authority (<NUM>).