Cloaking Authority System

Abstract

To provide a cloaking authority system that securely and anonymously identifies a misbehaving vehicle based on its digital certificate.SOLUTION: A cloaking authority system 100 includes a cloaking authority 230 that is communicatively connected to a misbehavior authority 210, a pseudonym certificate authority 310, and a registration authority 320. In response to a request from the misbehavior authority to identify a misbehaving vehicle by using the vehicle's pseudonym certificate (PC) 135, the cloaking authority interacts with the pseudonym certificate authority and the registration authority to securely obtain a representation of the linkage chain identifier that is associated with the misbehaving vehicle, while maintaining the anonymity of the real-world identifying information for the misbehaving vehicle, creates a cloak index that identifies the misbehaving vehicle, and provides the cloak index to the misbehavior authority.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention detects anomalously behaving Internet of Things devices, vehicles, and The present invention relates to systems, devices and methods for secure anonymous identification of computerized devices such as mobile or transportation infrastructure devices. [Background technology]

[0002] As computers continue to shrink and become more commoditized, manufacturers are producing an ever-increasing variety of devices that include one or more embedded computers or processors. The computers in computerized devices can, among other things, control the operation of the device; collect, store, and share data; communicate with other computers and other computerized devices; and update their own software.

[0003] The Internet of Things (IoT) is a network of computerized physical devices with embedded processor(s), electronics, software, data, sensors, actuators, and / or network connectivity capabilities that enable them to connect and exchange data over digital networks, including the Internet, cellular networks, and other wireless networks. Typically, each "thing" is uniquely identifiable through its embedded computing system and can communicate and interoperate within the existing Internet infrastructure.

[0004] "Things" in the IoT sense can refer to a wide variety of computerized devices, such as consumer electronics, enterprise devices used in business and corporate environments, manufacturing machinery, agricultural machinery, energy-consuming devices in homes and buildings (switches, power outlets, light bulbs, televisions, etc.), medical and health-management devices, infrastructure management devices, robots, drones, and transportation-related devices and vehicles, among others.

[0005] For example, most, if not all, modern vehicles (e.g., cars, trucks, airplanes, trains, ships, etc.) contain several embedded processors or embedded computers in their subsystems and are computer-controlled in at least some aspects. Similarly, an increasing number of modern transportation infrastructure devices (e.g., traffic lights, traffic cameras, traffic sensors, bridge monitors, bridge control systems, etc.) 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 a transportation network typically communicate with each other, sending various types of information back and forth, and may react, respond, modify their operations, or otherwise rely on information received / sent to other vehicles in vehicle-to-vehicle (V2V; also known as car-to-car, or C2C) communications and / or infrastructure elements in vehicle-to-infrastructure (V2I; also known as car-to-infrastructure, or C2I) communications for safe, accurate, efficient, and reliable operation. These elements, communications, operations, and interactions are sometimes collectively referred to as the V2X environment, where X represents any device, including another vehicle.

[0006] The computers in a computerized device are their software and / or firmware and data related to the operation of their hardware (processor, memory, bus, etc.) and the input data (data from other devices) used by the computerized device. A computerized device operates according to certain information, such as location data (e.g., from a GPS device), speed data, braking data, time data, temperature data, etc. Problems with software, data, hardware, or input can cause the computerized device to operate in an abnormal or anomalous manner, such that the device behaves in a manner that deviates from its standard, normal, or expected behavior. Such problems may be unintentional, such as problems caused by a hardware device failure or an unintentional bug in the software, or may be intentional, such as problems caused by an unauthorized person or organization (e.g., a hacker) replacing or modifying software in a computerized device. Summary of the Invention [Problem to be solved by the invention]

[0007] Thus, for example, behaving in an anomalous or aberrant manner It is desirable to provide improved systems, methods, and techniques for securely identifying computerized devices in order to reduce or stop the impact of their unauthorized activity on other devices and their environments. [Means for solving the problem]

[0008] Disclosed herein are systems, methods, and devices for identifying fraudulent computerized devices. In some embodiments, the system includes a fraud authority device that receives a report about the fraudulent computerized device, the report including an anonymous certificate from the fraudulent computerized device, the anonymous certificate including a linkage value; a cloaking authority device communicatively coupled to the fraud authority device to receive a request for a cloak index from the fraud authority device, the request for the cloak index including the linkage value; an anonymous certificate authority device communicatively coupled to the cloaking authority device to receive a message from the cloaking authority device that includes the linkage value and to send a message to the cloaking authority device that includes a hash of an anonymous certificate request that results in generation of the anonymous certificate; a registration authority device communicatively coupled to the cloaking authority device to receive a message from the cloaking authority device that includes the hash of the anonymous certificate request and to send a message to the cloaking authority device that includes a hash of a linkage chain identifier that corresponds to the anonymous certificate and that identifies the fraudulent computerized device; The cloaking authority device determines the cloak index that corresponds to the linkage chain identifier and identifies the fraud computerized device, and transmits the cloak index to the fraud authority device.

[0009] In various embodiments, the cloaking authority device may determine the cloak index by generating a random number as the cloak index, hi some such embodiments, generating a random number includes generating the random number using the hash of the linkage chain identifier as a seed to generate the random number.

[0010] In various embodiments, the cloaking authority device includes a cloak index table, and the cloaking authority device stores the determined cloak index in the cloak index table and the linkage chain identifier. In some such embodiments, the cloaking authority device determines the cloak index by accessing the cloak index from the cloak index table based on the hash of the linkage chain identifier. In some such embodiments, the cloaking authority device stores a query time in the cloak index table in association with the cloak index and the hash of the linkage chain identifier, and updates the query time whenever the cloaking authority device accesses the cloak index. The cloaking authority device also deletes the cloak index and the hash of the linkage chain identifier and the query time from the cloak index table after a predetermined time has elapsed after the query time.

[0011] In still other embodiments, a computer, such as a cloaking authority computer, may perform the method for identifying rogue computerized devices, and a non-transitory computer-readable medium may contain instructions that, when executed by a processor, perform the method for identifying rogue computerized devices. In some such embodiments, the method includes: an operation of receiving a request for a cloak index corresponding to the fraudulent computerized device from a fraud authority, the request for the cloak index including a linkage value from a pseudonym certificate from the fraudulent computerized device; sending a message including the linkage value to an anonymous certificate authority, the anonymous certificate authority performing a hash of the anonymous certificate request resulting in the generation of the anonymous certificate; receiving a message from the anonymous certificate authority that includes a hash of the anonymous certificate request; sending a message including a hash of the anonymous certificate request to a registration authority; receiving a message from the registration authority including a hash of a linkage chain identifier corresponding to the pseudonym certificate and identifying the fraudulent computerized device; determining the cloak index corresponding to the linkage chain identifier and identifying the fraudulent computerized device; transmitting the cloaked index to the fraud authority; may include:

[0012] In various such implementations, determining the cloak index may include generating a random number as the cloak index. In some such implementations, generating the random number may include generating the random number using the hash of the linkage chain identifier as a seed for a random number generator.

[0013] In still other embodiments, operations may further include storing the determined cloak index in a cloak index table and storing the hash of the linkage chain identifier in association with the cloak index in the cloak index table. In some such embodiments, determining the cloak index may include accessing the cloak index from the cloak index table based on the hash of the linkage chain identifier, and / or operations may include storing a query time in association with the cloak index and the hash of the linkage chain identifier in the cloak index table, updating the query time whenever the cloak index is accessed, and updating the query time after the query time. The method can further include deleting the cloak index and the hash of the linkage chain identifier and the query time from the cloak index table after a predetermined time has elapsed.

[0014] In yet other embodiments, the linkage value may be encrypted for the anonymous certificate authority, the hash of the anonymous certificate request may be encrypted for the registration authority (e.g., the cloaking authority computer cannot decrypt them), and / or the computerized device may be a vehicle.

[0015] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention. [Brief explanation of the drawings]

[0016] [Figure 1] FIG. 1 is a block diagram illustrating an example of a system of a cloaking authority that can securely and anonymously identify computerized devices, such as vehicles, consistent with embodiments of the present invention. [Figure 2]FIG. 2 is a block diagram illustrating an example of generating a cloaked index request in a system of cloaking authorities consistent with embodiments of the present invention. [Figure 3] FIG. 2 is a block diagram illustrating an example of requesting a hash of an anonymous certificate in a system of cloaking authorities consistent with embodiments of the present invention. [Figure 4] FIG. 2 is a block diagram illustrating an example of generating a cloak index that identifies computerized devices in a cloaking authority system consistent with embodiments of the present invention. [Figure 5] FIG. 1 is a block diagram of an example computing system that can be used to host or implement systems and methods consistent with embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0017] Reference will now be made in detail to various embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Wherever convenient, the same reference numerals will be used throughout the drawings to refer to the same or like parts.

[0018] For clarity, the following description uses vehicle computerized devices and transportation infrastructure computerized devices (such as vehicles with OBUs and ECUs, and RSUs) as specific examples, but the present invention is not limited to these particular types of devices. Various embodiments consistent with the present invention can 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 (eUICCs)), among others.

[0019] Vehicle-to-Vehicle (V2V) is an automotive technology designed to enable cars to communicate with each other. Vehicle-to-Infrastructure Integration (V2I) is a set of technologies that link road vehicles with their physical surroundings. Both technologies together can be called a V2X environment with the primary goal of improving road safety.

[0020] In a V2X environment, security assets (e.g., security-related digital assets such as anonymous certificates) can be used to authorize and enable entities (e.g., V2X devices such as vehicles) to participate and communicate in the V2X environment. Unlike certificates, pseudonymous certificates do not carry within them the identity of their entities. Therefore, an external observer cannot link their use to a particular vehicle or device. Additionally, after initial installation at the time of manufacture, security assets used in V2X devices, including pseudonymous certificates, are periodically changed, replenished, or re-provisioned during the operational life of the device.

[0021] This creates some technical problems when trying to match a given pseudonym certificate with the correct V2X device that uses this certificate, or in other words, when trying to identify the correct device (e.g., vehicle) that uses a given pseudonym certificate.

[0022] Members of the V2X environment, such as cars and trucks, should not misbehave. or behaving in an irregular or abnormal manner that can be termed misbehavior. A rogue vehicle is typically detected by other members of the V2X environment, such as other vehicles or transportation infrastructure devices. However, in a V2X environment, the only available "identification" of a rogue vehicle is its pseudonym certificate(s) that a detecting vehicle receives in a communication from the rogue vehicle.

[0023] When a vehicle or other member of a V2X environment misbehaves, it is desirable to identify the vehicle and reduce or stop the undesirable or adverse effects caused by the misbehavior, for example, by “removing” the misbehaving device from the V2X environment. A misbehaving vehicle may adversely affect the V2X environment, for example, by communicating false, deceptive, or misleading information to other vehicles or infrastructure devices. Such information may cause other vehicles or devices to operate or react inappropriately. One example of a method for removing a misbehaving vehicle from a V2X environment is to notify or instruct other members of the V2X environment (e.g., other cars and trucks and infrastructure devices) to not pay attention to or ignore communications from the misbehaving vehicle.

[0024] 1 is a block diagram illustrating an example of a system 100 for identifying misbehaving vehicles 130 using a cloaking authority 230 consistent with embodiments of the present invention. As shown in the example of FIG. 1, the system 100 includes a conventional V2X environment 110 that includes reporting vehicles 140 and misbehaving vehicles 130. As known in the art, each reporting vehicle has a group of unique pseudonym certificates (PCs) 145 assigned to it, and each misbehaving vehicle has a group of unique PCs 135 assigned to it.

[0025] The reporting vehicle 140 can receive wireless V2V communications 137 from the cheating vehicle 130, which can include the cheating vehicle's 130 current PC 135. Based on the V2V communications 137, the reporting vehicle 140 can determine that the cheating vehicle 130 is behaving in an abnormal or anomalous manner. For example, when the vehicle 130 communicates data or information that is contradictory or incompatible with data and information known to the reporting vehicle 140, such as when the cheating vehicle 130 claims to occupy the same physical space on the road as another vehicle, i.e., when the cheating vehicle 130 communicates (137) its GPS coordinates as the same as those communicated by another vehicle or as the reporting vehicle 140, the reporting vehicle 140 can detect cheating by the vehicle 130 and can be triggered to report the cheating activity. In some other examples, when a cheating vehicle 130 is detected as being in a location that the reporting vehicle's 140 camera detects as unoccupied, or when a cheating vehicle 130 is detected as being traveling at an unlikely speed (e.g., 200 mph), or other unusual or anomalous data from the cheating vehicle 130. Or, upon detecting the information, the reporting vehicle 140 can report the fraudulent activity.

[0026] Upon detecting misbehavior, the reporting vehicle 140 may wirelessly transmit a misbehavior report (MBR) 21 to a misbehavior authority (MA) 210, as known in the art. The MBR 21 may, among other things, This includes the currently active PC 145 of both 140 and the currently active PC 135 of the cheating vehicle 130 .

[0027] The MA 210 may be implemented as a server or other computer (e.g., a device having at least one processor and associated memory). In various embodiments, the MA 210 functions to receive, log, and process the MBRs 21 from devices in the V2X environment 110 and to make decisions related to protecting the V2X environment 110 from the rogue vehicle 130, for example, by revoking 120 the communication and / or other privileges of the rogue vehicle 130 within the V2X environment 110. In other words, the rogue vehicle 130 is effectively removed from the V2X environment 110. In various embodiments consistent with the present disclosure, the MA 210 also securely communicates with a cloaking authority (CLA) 230 to obtain an identifier for the rogue vehicle 130. This identifier can then be used to classify vehicles 130 as cheating based on a "global" group or sequence of MBRs 21 and / or take corrective action against cheating vehicles 130. In various embodiments, the MA 210 may use the MBRs 21 and cloak-index responses 43 received by the MA 210 to identify and classify vehicles 130 as cheating. The MA 210 may also perform recording or logging functions, such as storing information reflecting communications sent by the MA 210 (such as a cloak index request 23 sent to the CLA 230), corrective actions taken by the MA 210 (such as a cancellation message or command 120 sent by the MA 210), etc.

[0028] The CLA 230 may be implemented as a server or other computer (e.g., a device having at least one processor and associated memory). In various embodiments, as described in more detail below, the CLA 230 interacts with a pseudonym certificate authority (PCA) 310 and a registration authority (RA) 320 to generate a decryption certificate identifying the fraudulent vehicle 130. The CLA 230 functions to retrieve data from its PC 135. The CLA 230 also generates a unique identifier from this data. This unique identifier also identifies the cheating vehicle 130. In the illustrated example, the unique identifier may be referred to as a cloak index and may be stored in a cloak index table 235. Although described herein as a table, in various embodiments, the cloak index table 235 may be implemented as any type of data structure or associated data. The CLA 230 also communicates this generated unique identifier (e.g., cloak index) of the cheating vehicle 130 to the MA 210. In various embodiments, the CLA 230 may also perform recording or logging functions, such as storing information reflecting communications received by the CLA 230 (e.g., a cloak index request received by the CLA 230), communications sent by the CLA 230 (e.g., a cloak index response sent to the MA 210), etc.

[0029] During operation of the system 100, the reporting vehicle 140 reports detected cheating vehicles 130 to the MA 210 via the MBR 21. However, as is known in the art, due to the design of the V2X environment 110, the reporting vehicle 140 is unable to specifically identify the cheating vehicle 130 by, for example, make, model, VIN, license plate number, etc. The only identifying information associated with the cheating vehicle 130 and known to the reporting vehicle 140 is the anonymous certificate included with the V2V communication 137 transmitted by the cheating vehicle 130. The PC is a Personal Computer (PC) 135. By design, members of the V2X environment 110 and the MA 210 do not know which PC comes from or is associated with which vehicle.

[0030] Furthermore, by design, the PC 135 used and transmitted by the misbehaving vehicle 130 changes over time in order to maintain the anonymity of the vehicle 130. The same applies to all of the vehicles in the V2X environment. For example, when the reporting vehicle 140 transmits a misbehavior report 21 to the MA 210, the misbehavior report 21 includes the PC 145 currently in use by the reporting vehicle 140, and the PC 145 changes over time. That is, new PCs 145 are periodically used by the reporting vehicle 140, and old ones are no longer used.

[0031] Thus, the misconduct report 21 does not permanently identify the offending vehicle 130 or the reporting vehicle 140 because the anonymous certificates 135, 145 in the report 21 become obsolete over time. The identities of the vehicles 130, 140 in the V2X environment 110 are intentionally obfuscated by PCs designed to prevent someone from tracking specific vehicles (and their drivers) through the vehicles' communications within the V2X environment 110.

[0032] This makes it technically difficult to detect repeated misbehavior by the same vehicle and to identify the misbehaving vehicle 130 in a manner that allows it to be removed from the V2X environment 110 as necessary. Repeatedly misbehaving vehicles (e.g., vehicles demonstrating multiple misbehaviors, sometimes referred to as global misbehaviors) can include, to name a few, a single vehicle that is reported as misbehaving by a significant number (e.g., more than a predetermined threshold number or more than a threshold number above the average number) of other vehicles, a single vehicle that falsely reports 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 report could not have been generated in good faith (e.g., a vehicle that appears to submit a report from California but an hour later appears to submit a report from New Jersey), and vehicles that share a commonality of reporting for or being reported as misbehaving significantly more frequently than normal (e.g., all 2018 Ford Focus assembled at a particular manufacturing plant—misbehavior may indicate a manufacturer design defect, hardware defect, or software defect in the vehicle).

[0033] From the perspective of the V2X environment, there is a need to reliably identify rogue vehicles 130 in order to remove them from the environment 110, and from the perspective of the vehicle original equipment manufacturer (OEM) or supplier, there is a need to reliably identify the vehicles or their In order to detect and correct (eg, via recall) problems within some specific group of onboard equipment, cheating vehicles 130 need to be reliably identified.

[0034] In a conventional V2X environment 110, there is currently nothing that can identify a rogue vehicle 130 based on a misbehavior report 21 (e.g., a PC 135 in the misbehavior report) that is caused by or associated with the rogue vehicle 130 because the PC 135 is technically designed not to identify those vehicles 130 during their use in the V2X environment 110. The systems, methods, and devices described in this disclosure introduce a new entity, the Cloaking Authority (CLA) 230, that can identify a rogue vehicle 130 based on its misbehavior report 21 that includes its PC 135.

[0035] After receiving the MBR 21 from the conventional V2X environment 110 (e.g., a reporting vehicle 140), the MA 210 securely transmits the MBR to the CLA 230, as described in more detail below. The CLA 230 securely contacts the PCA 310 with at least a portion of the information from the PC 135 and, in response, obtains the hash of the RA-to-PCA pseudonym certificate request (HPCR) (or other representation) that originally generated the PC 135 when the PC 135 was created. The request is first obtained from RA320 when PC135 is created. CLA230 then securely contacts RA320 with the HPCR to obtain a representation (e.g., a hash) of the HPCR's linkage chain index (LCI). This representation identifies the cheating vehicle 130 in the sense that the LCI is associated with the single vehicle for which the particular PC was originally created.

[0036] In various embodiments, using the LCI from the RA 320 as a seed, the CLA 230 generates a random value index, called a cloak index, that uniquely identifies the cheating vehicle 130 for which the PC 135 was originally created, and returns this index to the MA 210. In various embodiments, the cloak index can be stored in a cloak index table 235 of the CLA 230. If the MA 210 later sends the CLA 230 another MBR 21 with a different PC 135 from the same vehicle 130, the CLA 230 will respond by returning the same cloak index after processing this MBR 21.

[0037] In various embodiments, the CLA 230 may perform similar processing on the PC 145 of the reporting vehicle 140 to generate a cloak index that identifies the reporting vehicle 140. The cloak index of the reporting vehicle 140 may be used by the MA 210 to determine whether the reporting vehicle 140 is cheating, for example, by sending an incorrect MBR 21 or by using a PC that was not generated for this reporting vehicle.

[0038] In some embodiments, CLA 230 may only temporarily store cloak indexes in cloak index table 235 based on frequency of use, i.e., the frequency of MBRs 21 that map to the same cloak index. For example, if a cloak index has a reset time to live (TTL) period of two weeks after the last matching query, and CLA 230 does not receive the corresponding MBR 21 at least every 14 days, CLA 230 will delete the cloak index from index table 235. This prevents CLA 230 and MA 210 from retaining vehicle identification information indefinitely. Thus, implementations consistent with the present disclosure may generate temporary cloak indexes that provide the technical advantage of allowing MA 210 to detect fraudulent activity by the same vehicle over a period of time, while reducing the likelihood of compromising the anonymity of any vehicle over an extended period of time, despite the anonymity and volatility of PCs.

[0039] Because the CLA 230 responds using the same cloak index for a given cheating vehicle 130 regardless of which PC 135 the vehicle 130 is currently using and regardless of which PC 135 the vehicle 130 switches to over time, the MA 210 can determine whether a particular vehicle 130 is cheating "globally" based on a group or set of MBRs 21, even if the MBRs contain different PCs 135.

[0040] For example, if MA 210 determines that a vehicle assigned a cloak index of "12345" by CLA 230 has caused 100 MBRs from 75 different reporting vehicles, MA 210 can classify the "12345" vehicle as a cheating vehicle and can initiate corrective action, such as cancellation 120. As another example, if a vehicle assigned a cloak index of "23456" by CLA 230 has caused 100 MBRs from 75 different reporting vehicles, MA 210 can classify the "12345" vehicle as a cheating vehicle and can initiate corrective action, such as cancellation 120. If MA 210 determines that vehicle "23456" submitted an MBR from California and an MBR from New Jersey within one hour of each other (which may indicate that one or both of the vehicles in California or New Jersey are using illegal PCs that were not generated for that vehicle), then MA 210 can classify vehicle "23456" as a cheating vehicle and initiate corrective action. As yet another example, if MA 210 determines that a vehicle assigned cloak index "34567" by CLA 230 submitted MBRs within 24 hours that report 1,000 other vehicles as cheating (which may indicate that reporting vehicle "34567" is submitting false or erroneous MBRs), then MA 210 can classify vehicle "34567" as a cheating vehicle and initiate corrective action. In various embodiments, the corrective action may include adding the rogue vehicle to a certification revocation list (CRL), as known in the art, so that the rogue vehicle can no longer communicate with other devices in the V2X environment 110. and / or may include reporting the identity of the cheating vehicle(s) to the OEM.

[0041] In various embodiments, to take corrective action against a cheating vehicle, the MA 210 can identify the cheating vehicle's actual linkage chain identification (LCI) that corresponds to the cloak index provided by the CLA 230. This actual linkage chain identification can be used to add the cheating vehicle to a CRL or to report the cheating vehicle back to the OEM. In some further embodiments, the system 100 can include a server, database, etc. (not shown) that stores vehicle information (e.g., VIN, make, model, device serial number, etc.) in association with the vehicle's LCI. This vehicle information can be written at the manufacturer or at the time of refill when the vehicle is provisioned with a PC. In such embodiments, the MA 210 (or CLA 230) can query this store of make / model or other useful information to facilitate corrective efforts and / or report the information to the OEM, allowing the OEM to investigate and debug issues with the vehicle or problematic model of the vehicle.

[0042] In other embodiments along similar lines, system 100 may include a server, database, etc. (not shown) that can identify and return meta-characteristics for a group of HPCRs (or the like) that have been reported as misbehaving. Examples of such meta-characteristics include a group of HPCRs all being from the same model vehicle, a group of HPCRs all being from vehicles containing the same type of OBU, a group of HPCRs all being from vehicles containing the same firmware version, etc. Such meta-characteristics may, for example, enable an OEM to identify and correct issues or defects in a particular type, make, model, year, etc. of vehicles; in some cases, these corrections may be made (e.g., using an over-the-air software update) before the vehicles are cancelled or removed from V2X environment 110 and / or recalled. Such meta-characteristics may also, for example, enable system 100 to allow certain specialized vehicles, such as emergency vehicles, to remain in V2X environment 110 even if they are misbehaving, and notify the operators of those vehicles that the vehicles need to be repaired to correct the misbehavior.

[0043] Those skilled in the art will recognize that the components, processes, data, operations, and implementation details shown in Figure 1 are examples presented for simplicity and clarity of explanation. This example is not intended to be limiting, and many variations are possible, so other components, processes, implementation details, and variations can be used without departing from the principles of the present invention. For example, one cheating vehicle 130, one reporting vehicle 140, one MA 210, And although only one CLA 230 is shown in FIG. 1, other embodiments may have any number of each of these entities.

[0044] FIG. 2 is a block diagram illustrating an example of components and processes for generating cloaked index requests in a system of cloaking authorities consistent with embodiments of the present invention.

[0045] As shown in this example, vehicle 140 transmits MBR 21 to MA 210, which receives and processes MBR 21. MBR 21 includes PC 145 of reporting vehicle 140 and PC 135 of offender, i.e., cheating vehicle 130. In various embodiments, MBR 21 includes other data, such as information describing the type of report, location information, information describing the anomalous behavior of cheating vehicle 130, time information, information about V2V communication between vehicles, etc.

[0046] The MA 210 extracts data from the received MBR 21 and processes this data to create a cloak index request 23 for the CLA 230 .

[0047] In some embodiments, as shown in FIG. 2, the MA 210 can extract the PC 135 of the cheating vehicle 130 (and / or the PC 145 of the reporting vehicle 140) from the MBR 21, and then extract the linkage value L from the PC 135. The MA 210 can then extract the linkage value L of the PCA 310. PCA That is, only the PCA 310 can encrypt the linkage value L PCA can be encrypted using a key from PCA 310 so that L can be decrypted. PCA The L can be compromised by an unauthorized person who intercepts or threatens the cloaked index request 23 and makes their own request to the CLA 230, such as in a replay attack. PCA or L PCA A timestamp may be included so that a cloaked index request 23 containing the

[0048] The linkage value is used by the system 100 to anonymously identify the vehicle from which the PC 135 was obtained, and the linkage value links the PC to the vehicle or device that issued or provisioned it. However, the linkage value does not provide a direct or simple linkage because the V2X environment 110 is designed to maintain the anonymity of vehicles. The linkage value can also be used by vehicles in the V2X environment 110 to determine whether the device associated with the linkage value is on a certificate revocation list (CRL) and, if so, ignore its communications.

[0049] In some embodiments, as shown in Figure 2, the MA 210 also generates a cryptographic nonce, which is combined with the MBR 21 and hashed to generate In some embodiments, the hash output H may be used for system accounting or system auditing purposes.

[0050] In the illustrated example, the MA 210 receives the nonce, a hash H of the nonce and the MBR 21, and a linkage value L of the encrypted anonymous certificate. PCA Create a cloak index request message 23 containing the MBR 21 and the linkage value L in PC 135. PCA By encrypting the linkage value, the MA 210 prevents the CLA 230 from having any vehicle identification information, because that information is encrypted for the PCA 310 and the CLA 230 does not have the key to decrypt it. Because the linkage value is encrypted for the PCA, the CLA 230 cannot obtain any information about the PC. The CLA 230 only knows that the MA 210 sent a cloak index request 23 to the CLA.

[0051] To secure the cloaked index request 23, the MA 210 may cryptographically sign the cloaked index request 23 with its encryption key.

[0052] After processing the received MBR 21 to create a cloak index request message 23 , the MA 210 sends this cloak index request message 23 to the CLA 230 .

[0053] With regard to accounting or auditing uses of the hashed MBR 21, in some embodiments, the hashed MBR 21 allows an auditor to match cloak index requests 23 received and logged by the CLA 230 with the corresponding MBR 21 received and logged by the MA 210 to verify that every cloak index request 23 was triggered by the MBR 21. This type of accounting or auditing can be done periodically (e.g., every three or six months) to detect situations in which the MA 210 has been compromised or is not operating correctly and sending cloak index requests 23 that are not based on the MBR 21, for example, cloak index requests 23 using a PC from any vehicle, whether rogue or not.

[0054] 3 is a block diagram illustrating an example process for requesting a hash of a pseudonym certificate in a cloaking authority system consistent with embodiments of the present invention. As shown in this example, the CLA 230 receives the cloak index request 23, and as described in more detail below, the CLA 230 communicates with the PCA and RA to obtain a hashed linkage chain identification (hashed LCI). Because every PC assigned to a given vehicle (or device) has the same LCI, this hashed linkage chain identification is an indicator, such as a unique number, that identifies a particular vehicle based on the PC assigned to that vehicle. The LCI has a one-to-one correspondence with the vehicle (or device) and distinguishes the given vehicle from all other vehicles and devices in the V2X environment 110.

[0055] As shown in this example, CLA230 uses the encrypted linkage value L PCAThe MA 210 sends the encrypted linkage value L to the PCA 310 (33). PCA can only be decrypted by the PCA 310.

[0056] PCA310 is a linkage value L PCA and verifies that the cloaked index request 23 is valid by decrypting the MA 210's cryptographic signature on the cloaked index request 23, which ensures that the cloaked index request 23 originated from the MA 210. In some embodiments, the PCA 310 may optionally communicate with the MA 210 after receiving the cloaked index request 23 to require that the MA 210 verify that the MA 210 sent the cloaked index request 23 (33.5) before the CLA 310 processes requests 23 and 33. This option prevents the PCA 310 from responding to a forged or unauthorized cloaked index request 23 that was not genuinely obtained from the MA 210.

[0057] The PCA 310 uses the decrypted linkage value L, for example, as an index to look up the hash of the RA-PCA anonymous certificate request (HPCR).

[0058] As is known in the art, this lookup is based on how anonymous certificates are generated and provisioned into a standard V2X environment 110. In terms of the workings behind the scenes of the V2X environment 110, at the time of vehicle manufacture and subsequent PC refills, the vehicle makes a request to obtain a bundle or group of PCs (e.g., a group of PCs 135) from the RA 320. The RA 320 then sends the RA 320 a set of RA-PCA requests for PCs 135. The RA 320 interacts with the PCA 310 and two linkage authorities (not shown) to generate and provide bundles of PCs to the requesting vehicle. For example, a given vehicle 130 may send an initial request for a group or bundle of 3,000 PCs 135 to the RA 320 at the time of vehicle manufacture, and in response, the RA 320 may create and send 3,000 individual RA-PCA requests for PCs to the PCA 310. To correlate the resulting PCs with the requesting vehicle 130, the RA 320 hashes each individual RA-PCA request for PCs, thereby creating a hash result (referred to as an HPCR) representing the RA-PCA request, which includes a hash result (i.e., an HPCR) for each of the 3,000 RA-PCA requests that it sends to the PCA 310. Additionally, the RA 320 assigns at least one Linkage Chain ID (LCI) to the requesting vehicle 130 and stores all of the HPCRs generated for the vehicle 130 in association with their LCI(s) so that every HPCR for a given vehicle is associated with the same LCI(s) and the RA 320 can use the HPCRs to look up the LCI(s). Note that while conventional RAs 320 in current V2X environments use two LCIs, for ease and clarity of explanation, the examples used herein generally refer to only one LCI. Nevertheless, embodiments consistent with the present invention include embodiments using more than one LCI.

[0059] At approximately the same time as vehicle 130, other new vehicles are requesting bundles of PCs with vehicle 130 from RA 320, and therefore the RA must fulfill a large number of requests. For example, if 1,000 vehicles each request 3,000 PCs, RA 320 will send 3,000,000 RA-PCA requests to PCA 310 for individual PCs. RA 320 typically shuffles the order of the RA-PCA requests so that PCA 310 cannot correlate any group or sequence of RA-PCA requests with any particular vehicle or with each other.

[0060] In response to each RA-PCA request, PCA 310 creates a new PC. Once PCA 310 creates a new PC that includes linkage value L, it associates this linkage value L with the HPCR that was included in each request and stores it in a manner that allows PCA 310 to look up the HPCR using linkage value L. PCA 310 sends the newly created PC to RA 320. PCA 310 can encrypt each PC for a vehicle so that RA 320 cannot see the contents of the PC (i.e., each PC can only be decrypted by that vehicle).

[0061] Because the RA 320 received each PC in response to an RA-PCA request that the RA 320 made to the PCA 310, and each RA-PCA request that the RA 320 made to the PCA 310 was correlated using the HPCR to a PC bundle request received from a particular vehicle 130 via the LCI, the RA 320 can determine which PCs 135 were generated for and destined for that particular vehicle 130. Thus, the hash of the RA-PCA request (HPCR) is the information that allows the RA 320 to correlate the newly created PC with a particular vehicle and provision the newly created PC to that particular vehicle.

[0062] 3 and concluding the discussion of the mechanics behind the V2X environment 110, with the decrypted linkage value L, the PCA 310 looks up in its stored records and retrieves or otherwise determines the hashed RA-to-PCA request (HPCR) that it received from the RA 320 and in response created a PC containing the linkage value L. After the PCA 310 retrieves the HPCR corresponding to the PC containing the linkage value L, it encrypts a copy of the HPCR for the RA 320 (e.g., so that the CLA 230 cannot access the HPCR), and the PCA 310 sends the encrypted HPCR to the CLA 230. Send to (34).

[0063] The CLA 230 receives the message with the encrypted HPCR and transmits the encrypted HPCR to the RA 320 (35).

[0064] The RA 320 receives the message and decrypts the encrypted HPCR to verify that the message is valid. The RA 320 then uses the decrypted HPCR to look up the stored linkage chain ID(s) (LCI) that corresponds to the HPCR and indicates the vehicle to which the RA-PCA request maps. Referring back to the previous example where the vehicle 130 requested a group of 3000 PCs at the time of manufacture, the RA 320 has stored 3000 HPCRs that map to the same LCI and therefore to the same vehicle 130. In various embodiments, the LCI can be or represent actual information about the identity of the vehicle 130 within the V2X environment 110 (in some embodiments, using information outside the conventional V2X environment 110, the LCI can be mappable to a real-world identity, such as a vehicle ID number). To keep that information secure, the RA 320 can hash the LCI with a static cryptographic nonce before responding to the CLA 230. The RA 320 then responds (36) by sending the hashed LCI to the CLA 230. Because both of these inputs are deterministic (i.e., the LCI does not change and the static nonce does not change), the hashing algorithm will produce the same hash value each time it runs on a given vehicle 130 (i.e., the LCI associated with a given vehicle). Thus, the CLA 230 (and other entities) cannot know what the value of the LCI was, but they can tell from the hash value that it was the same LCI.

[0065] The hashed LCI received by the CLA 230 maps or corresponds to the PC used by the MA 210 in the cloak index request 23. However, neither the true LCI nor the linkage value of the PC from the vehicle 130, 140 can be determined by the CLA 230 because that information is securely encrypted when passing through the CLA 230.

[0066] 4 is a block diagram illustrating an example of a process for generating a cloak index in a cloaking authority system consistent with embodiments of the present invention. As shown in this example, the CLA 230 attempts to determine whether the hashed LCI received from the RA 320 (36) is in the cloak index table 235 (e.g., in other words, whether the MA 210 previously sent a request 23 corresponding to this hashed LCI).

[0067] If the received hashed LCI is not stored in cloak index table 235, CLA 230 creates a new random cloak index corresponding to the received hashed LCI and sends this new cloak index to MA 210 in response message 43. CLA 230 also stores a copy of this new cloak index in cloak index table 235. In various embodiments, CLA 230 can store the new cloak index by adding a row to cloak index table 235. This row includes information or fields that hold the hashed LCI, the new cloak index, the creation date and time of the new cloak index, and the most recent query date and time of the new cloak index (which can be the same as the creation date and time when a new cloak index is first added to the table).

[0068] On the other hand, if the received hashed LCI 36 is already stored in the cloak index table 235, the CLA 230 finds the corresponding previously generated cloak index in the same row of the cloak index table 235 and sets the cloak index to It sends it to the MA 210 in a response message 43 and updates the query time corresponding to that cloak index in the cloak index table 235 .

[0069] In various embodiments, if a cloak index (e.g., a row) in cloak index table 235 has not been queried for a predetermined time (e.g., a predetermined TTL time, such as 6 days, 2 weeks, 3 weeks, 1 month, etc.) after the last query time, CLA 230 may delete the cloak index entry (e.g., a row) from cloak index table 235. In such embodiments, CLA 230 does not retain records of cloak indexes (corresponding to hashed LCIs corresponding to particular vehicles) for an indefinite period of time.

[0070] In some embodiments where the cloak index value range is limited to a relatively small number of bits (e.g., 8 or 16 bits), CLA 230 may reuse a cloak index when a cloak index row (which indirectly corresponds to a particular vehicle) ages out according to a predetermined TTL value and is removed from cloak index table 235. In such embodiments, after CLA 230 removes a row, CLA 230 may generate a new random cloak index in the future, which may be the same as the cloak index previously used by CLA 230. And in such embodiments, response 43 to MA 210 may indicate whether a cloak index has been reused, so that MA 210 can treat the reused cloak index as corresponding to a different vehicle than the vehicle to which the reused cloak index previously corresponded.

[0071] In particular, a novel technical advantage of the system and process described above with respect to FIGS. 1-4 is that the CLA 230 never obtains unencrypted information about any of the vehicles and cannot decrypt information passing through the CLA 230. Because of this secure and anonymous handling of identifying information, even if the CLA 230 is compromised by a malicious actor, the malicious actor cannot track or learn anything about any of the vehicles and devices in the V2X environment 110. Nor can the malicious actor use the CLA 230 to trigger processing in the MA 210, PCA 310, or RA 320, because CLA 230 processing requires that the MA 210 cryptographically sign the message 33 that the CLA 230 passes to the PCA 310. Because the CLA 230 cannot cryptographically sign messages as if it were the MA 210, the PCA 310 does not process or react to any messages that the CLA signs alone.

[0072] Those skilled in the art will recognize that the components, processes, data, operations, and implementation details shown in Figures 2-4 are examples presented for simplicity and clarity of explanation. This example is not intended to be limiting, and since many variations are possible, other components, processes, implementation details, and variations can be used without departing from the principles of the invention.

[0073] 5 is a block diagram of an example computing environment including a computing system 500 that can be used to implement systems and methods consistent with embodiments of the present invention. Other components and / or arrangements can also be used. In some embodiments, computing system 500 can be used to at least partially implement various components of FIGS. 1-4, such as CLA 230 and MA 210, among others. In some embodiments, a series of computing systems similar to computing system 500 can each be customized with specialized hardware to implement one of the components of FIGS. 1-4, which can communicate with each other via network 535. and / or can be programmed as a specialized server.

[0074] In the example shown in FIG. 5, the computing system 500 includes a central processing unit (CPU) 505, memory 510, input / output (I / O) The system 500 includes multiple components, such as a CPU 505, a memory 510, a non-volatile storage device 520, and an I / O device 525. The system 500 can be implemented in various ways. For example, an implementation as an integrated platform (e.g., a server, workstation, personal computer, laptop, etc.) can include a CPU 505, a memory 510, a non-volatile storage device 520, and an I / O device 525. In such a configuration, the components 505, 510, 520, and 525 can be connected and communicate through a local data bus and can access a data repository 530 (e.g., implemented as a separate database system) through an external I / O connection. The I / O component(s) 525 can be connected to external devices through a direct communication link (e.g., a hardwired or local Wi-Fi connection), a network such as a local area network (LAN) or a wide area network (WAN) (e.g., a cellular telephone network or the Internet), and / or other suitable connection. The system 500 can be standalone or a subsystem of a larger system.

[0075] The CPU505 is manufactured by Intel Corporation of Santa Clara, California. TM Micropro from the Core® family manufactured by Micropro Corporation processor or AMD® Corporation of Sunnyvale, California TM A microprocessor from the Athlon® family manufactured by Intel Corporation The memory 510 may be one or more known processors or processing devices such as a processor, a memory controller, a processor unit, a processor ...

[0076] In the illustrated embodiment, memory 510 includes one or more programs or applications 515 loaded from storage device 520 or a remote system (not shown) that, when executed by CPU 505, perform various operations, procedures, processes, or methods consistent with the present disclosure. Alternatively, CPU 505 can execute one or more programs located remotely from system 500. For example, system 500 can access one or more remote programs over network 535 that, when executed, perform functions and processes related to embodiments of the present disclosure.

[0077] In one embodiment, memory 510 may include program(s) 515 that perform the specialized functions and operations described herein for CLA 230 and / or MA 210. In some embodiments, memory 510 may also include other programs or applications that implement other methods and processes that provide auxiliary functionality to the embodiments disclosed herein.

[0078] Memory 510 may also be configured to include other programs (not shown) not related to the present invention and / or an operating system (not shown) that, when executed by CPU 505, performs several functions well known in the art. By way of example, the operating system may be a Microsoft Windows® operating system. The operating system may be a Unix operating system, a Linux operating system, an Apple Computers operating system, or other operating system. The choice of operating system is not critical to the present invention, and even the use of the operating system is not critical to the present invention.

[0079] I / O device(s) 525 may include one or more input / output devices that allow system 500 to receive and / or transmit data. For example, I / O devices 525 may include one or more input devices, such as a keyboard, touch screen, mouse, etc., that allow for input of data from a user. Additionally, I / O devices 525 may include one or more output devices, such as a display screen, CRT monitor, LCD monitor, plasma display, printer, speaker device, etc., that allow for output or presentation of data to a user. I / O devices 525 may also include one or more digital and / or analog communication input / output devices, such as a network card and USB card, that allow computing system 500 to digitally communicate with other machines and devices, including, for example, via network 535. Other configurations and / or numbers of input and / or output devices may also be incorporated into I / O devices 525.

[0080] In the illustrated embodiment, system 500 is connected to a network 535 (such as the Internet, a private network, a virtual private network, a cellular network, or other network, or a combination thereof), which in turn may be connected to various systems and computing machines (not shown), such as servers, personal computers, laptop computers, client devices, etc. In general, system 500 may input data from and output data to external machines and devices via network 535.

[0081] 5, repository 530 is a standalone data store external to system 500, such as a standalone database. In other embodiments, repository 530 may be hosted by system 500. In various embodiments, repository 530 may manage and store data used to implement systems and methods consistent with the present invention. For example, repository 530 may manage and store data structures implementing cloak index table 235, including audit logs for MA 210 and / or CLA 230, etc.

[0082] Repository 530 may comprise one or more databases that store information and that are accessed and / or managed through system 500. By way of example, repository 530 may be an Oracle® database, a Sybase® database, or other relational database. However, systems and methods consistent with the present invention are not limited to individual data structures or databases or to any particular type of database, nor are they limited to the use of databases or data structures.

[0083] Those skilled in the art will recognize that the system components and implementation details in Figure 5 are examples presented for simplicity and clarity of explanation. Other components and implementation details may be used.

[0084] Although the above description uses specific examples of computerized devices in the V2X environment 110, such as vehicles, OBUs, ECUs, and RSUs, for clarity of explanation, the present invention is not limited to these. By way of non-limiting example, various embodiments consistent with the present invention may be used with and in a wide variety of computerized devices, including IoT devices, further examples of which include medical devices (e.g., dialysis machines, infusion pumps, etc.), robots, drones, autonomous vehicles, and wireless communication modules (e.g., embedded universal integrated circuit cards (eUICCs)), among others.

[0085] Other embodiments of the present invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with the true scope of the invention being indicated by the appended claims.

Claims

1. 1. A system for identifying fraudulent computerized devices, the system comprising: a fraud authority device; a cloaking authority device communicatively coupled to said fraud authority device; Equipped with receiving, by the fraud authority device, a report about the fraudulent computerized device, the report including an anonymous certificate from the fraudulent computerized device, the anonymous certificate including a linkage value; sending, by the fraud authority device, a request for a cloak index to the cloaking authority device, the request for the cloak index including the linkage value; processing the linkage value by the cloaking authority device to generate a cloak index identifying the fraudulent computerized device, wherein generating the cloak index includes obtaining first information used to generate the cloak index from an anonymous certificate authority device, the information being associated with the linkage value; transmitting, by the cloaking authority device, the cloak index to the fraud authority device; the fraud authority device receiving the cloak index from the cloaking authority device; and determining, by the fraud authority device, using the cloak index to determine that a particular computerized device is repeatedly engaging in fraudulent activity.

2. The operation is The system of claim 1 , further comprising instructing, by the fraud authority device, a plurality of computerized devices to ignore the particular computerized device that repeatedly engages in fraudulent activity.

3. Processing the linkage value by the cloaking authority device to generate the cloak index includes:

2. The system of claim 1, further comprising obtaining second information from a registration authority device that is used to generate the cloak index, the second information being associated with the first information.

4. Processing the linkage value by the cloaking authority device to generate the cloak index includes: receiving, by the cloaking authority device, from an anonymous certificate authority device, a hash of an anonymous certificate request (HPCR) resulting in generation of the anonymous certificate corresponding to the linkage value; receiving, by the cloaking authority device, from a registration authority device, a hash of a linkage chain identifier corresponding to the anonymous certificate identified by the HPCR, the hash of the linkage chain identifier identifying the fraudulent computerized device; determining, by the cloaking authority device, the cloak index identifying the fraudulent computerized device based on the linkage chain identifier; The system of claim 1 , comprising:

5. Processing the linkage value by the cloaking authority device to generate the cloak index includes: sending, by the cloaking authority device, a message including the linkage value to an anonymous certificate authority device; receiving, by the cloaking authority device and from the anonymous certificate authority device, a message including a hash of an anonymous certificate request (HPCR) resulting in generation of the anonymous certificate; sending, by the cloaking authority device, a message including the HPCR to a registration authority device; receiving, by the cloaking authority device, from the registration authority device, a message including a hash of a linkage chain identifier corresponding to the pseudonym certificate and identifying the fraudulent computerized device; determining, by the cloaking authority device, the cloak index identifying the fraudulent computerized device based on the linkage chain identifier; The system of claim 1 , comprising:

6. The system of claim 1 , wherein the computerized device is a vehicle.

7. 1. A method for identifying a fraud computerized device, the method being implemented by a fraud authority computer, comprising: receiving a report about the fraudulent computerized device, the report including an anonymous certificate from the fraudulent computerized device, the anonymous certificate including a linkage value; sending a request for a cloak index corresponding to the fraudulent computerized device to a cloaking authority, the request for the cloak index including a linkage value from the pseudonym certificate from the fraudulent computerized device; Including, The cloaking authority: sending a message including the linkage value to an anonymous certificate authority, the anonymous certificate authority determining a hash of an anonymous certificate request (HPCR) that results in the generation of the anonymous certificate; receiving a message from the anonymous certificate authority including the HPCR; sending a message including said HPCR to a registration authority; receiving a message from the registration authority including a hash of a linkage chain identifier corresponding to the anonymous certificate and identifying the fraudulent computerized device; determining the cloak index corresponding to the linkage chain identifier and identifying the fraudulent computerized device; receiving the cloak index from the cloaking authority; The method uses the cloak index to determine that a particular computerized device is engaging in repeated fraudulent activity.

8. 8. The method of claim 7, further comprising instructing a plurality of computerized devices to ignore the particular computerized device that repeatedly engages in fraudulent activity.

9. The method of claim 7 , wherein the cloaking authority determines the cloak index by using the hash of the linkage chain identifier as a seed in a random number generator to generate a random number as the cloak index.

10. the cloaking authority stores the determined cloak index in a cloak index table; The method of claim 7 , wherein the hash of the linkage chain identifier is associated with the cloak index and stored in the cloak index table.

11. The method of claim 10 , wherein the cloaking authority determines the cloak index by accessing the cloak index from the cloak index table based on the hash of the linkage chain identifier.

12. The method of claim 7 , wherein the computerized device is a vehicle.

13. 1. A system for identifying fraudulent computerized devices, the system comprising: a memory containing instructions; a processor operatively coupled to the memory and configured to execute the instructions to perform the following operations: Equipped with The operation is receiving a request for a cloak index corresponding to the fraudulent computerized device from a fraud authority, the request for the cloak index including a linkage value from an anonymous certificate from the fraudulent computerized device; sending a message including the linkage value to an anonymous certificate authority, the anonymous certificate authority determining a hash (HPCR) of the anonymous certificate request resulting in generation of the anonymous certificate; receiving a message including the HPCR from the pseudonym certificate authority; and sending a message including the HPCR to a registration authority. receiving a message from the registration authority including a hash of a linkage chain identifier corresponding to the pseudonym certificate and identifying the fraudulent computerized device; determining the cloak index corresponding to the linkage chain identifier and identifying the fraudulent computerized device; and transmitting the cloaked index to the fraud authority.

14. Determining the cloak index comprises: The system of claim 13 , further comprising generating a random number as the cloak index.

15. Generating random numbers is 15. The system of claim 14, further comprising: generating the random number using the hash of the linkage chain identifier as a seed in a random number generator.

16. The operation is 14. The system of claim 13, further comprising: storing the determined cloak index in a cloak index table; and storing the hash of the linkage chain identifier in association with the cloak index in the cloak index table.

17. Determining the cloak index comprises:

17. The system of claim 16, further comprising accessing the cloak index from the cloak index table based on the hash of the linkage chain identifier.

18. The operation further comprises: storing a query time in association with the cloak index and the hash of the linkage chain identifier in the cloak index table; updating the query time whenever the cloaked index is accessed; 17. The system of claim 16, further comprising: deleting the hash of the cloak index and the linkage chain identifier and the query time from the cloak index table after a predetermined time has elapsed after the query time.

19. The system of claim 13 , wherein the fraud computerized device is a vehicle.

Images