IoT devices and security systems

Abstract

This invention provides a first IoT device, comprising a memory, a transceiver, a Bloom filter evaluation module, a false positive comparison module, and a control module. The memory stores: a Bloom filter set including a bit array representing entries in a certificate revocation list; and a false positive set including a list of certificate entries incorrectly identified as revoked. The transceiver receives a message including a certificate from a second IoT device. The Bloom filter evaluation module receives the Bloom filter set from a backend station and determines whether an identifier associated with the certificate is in the Bloom filter set. The false positive comparison module receives the false positive set from the backend station and determines whether the identifier is in the false positive set. The control module allows communication between the first IoT device and the second IoT device based on whether the identifier is in the Bloom filter set and the false positive set.

Description

[0001] introduction

[0002] The information provided in this section is intended to provide a general overview of the background of this disclosure. Within the scope described in this section, the work of the currently named inventor, and descriptions that may not conform to the prior art at the time of submission, are neither explicitly nor implicitly considered to be prior art to this disclosure. Technical Field

[0003] This disclosure relates to Internet of Things (IoT) communications, which may include vehicle-to-vehicle (V2V) communications, and more particularly to the distribution and verification of certificate revocation truth / status for IoT devices and modules. Background Technology

[0004] A vehicle control module may include one or more secure processor chips, memory, transceivers, and / or other circuit components. A vehicle may include multiple vehicle control modules. Some vehicle control modules require secure credentials to perform certain functions. As an example, a vehicle-to-vehicle (V2V) control module of a first vehicle communicates with other V2V control modules of other vehicles. To perform this communication, the V2V control module of the first vehicle needs a public certificate signed by a trusted certificate authority to communicate with other V2V control modules. To digitally sign and verify the authenticity of messages broadcast at a rate of, for example, 10 times per second (e.g., basic security messages), a public certificate and its corresponding private key are required. Messages are picked up by nearby vehicles and used to determine information associated with the vehicle that sent the message, other nearby vehicles, and / or other nearby objects. Messages may include vehicle position, vehicle speed, vehicle heading, information about other nearby objects, indicators of whether the vehicle is braking, and / or other status information.

[0005] According to the V2V communication protocol, each message transmitted from the first V2V module in the first vehicle to the second V2V module in the second vehicle needs to be signed using a private key, which is unique to the first V2V module. Additionally, each message needs to include a public certificate for signing, which contains the first V2V module's public key. The second V2V module obtains its public key based on the public certificate for signing. The second V2V module uses the public key to verify the signature of the corresponding message to determine if the message was signed with the appropriate private key. The second V2V module also verifies that the certificate's date has not expired. Finally, the second V2V module verifies that the certificate has not been revoked. If any of these verifications fails, the second V2V module may ignore messages from the first V2V module. Summary of the Invention

[0006] A first Internet of Things (IoT) device is provided, comprising a memory, a transceiver, a Bloom filter evaluation module, a false positive comparison module, and a control module. The memory is configured to store: a Bloom filter set including a bit array representing entries in a certificate revocation list; and a false positive set including a list of certificate entries incorrectly identified as revoked based on the Bloom filter set. The transceiver is configured to receive a message from a second IoT device, wherein the message includes a certificate. The Bloom filter evaluation module is configured to receive the Bloom filter set from a backend station and determine whether an identifier associated with a certificate is considered to be in the Bloom filter set. The false positive comparison module is configured to receive the false positive set from the backend station and determine whether an identifier is in the false positive set. The control module is configured to allow communication between the first IoT device and the second IoT device based on whether the identifier is considered to be in the Bloom filter set and whether the identifier is in the false positive set.

[0007] Among other features, the control module is configured to allow communication between the first IoT device and the second IoT device in response to the identifier being considered not to be in the Bloom filter set.

[0008] Among other features, the control module is configured to allow communication between the first IoT device and the second IoT device in response to an identifier being in the false positive set.

[0009] Among other features, the control module is configured to: add the identifier to the potential false positive list in response to the identifier being considered to be in the Bloom filter set and not in the false positive set, and ignore messages from the second IoT device at least temporarily.

[0010] Among other features, the control module is configured to: transmit a list of potential false positives to a backend station; and receive at least one of an updated version of the Bloom filter set or an updated version of the false positive set.

[0011] Among other features, the control module is configured to determine whether to communicate with the second IoT device based on at least one of an updated version of the Bloom filter set and an updated version of the false positive set.

[0012] Among other features, the false positive set includes identifiers of certificates that are not on the certificate revocation list but are on one or more potential false positive lists generated by the first IoT device, the second IoT device, or one or more other IoT devices.

[0013] Among other features, the control module is implemented as a vehicle-to-vehicle communication module.

[0014] Among other features, the Bloom filter evaluation module includes a Bloom filter and is configured to: use the Bloom filter to determine whether the identifier associated with the certificate is considered to be in the Bloom filter set.

[0015] Among other features, the Bloom filter evaluation module includes a Bloom filter. The Bloom filter includes a hash function. The hash function determines the corresponding bit position in the bit array of the identifier. The Bloom filter evaluation module determines that the identifier is in the Bloom filter when all bits at the bit position in the bit array are set to 1.

[0016] Among other features, a system is provided, and the system includes: a first IoT device; and a backend station including a Bloom filter, wherein the Bloom filter is configured to generate a set of Bloom filters based on entries in a certificate revocation list.

[0017] Among other features, the backend includes: a memory configured to store a certificate revocation list, a Bloom filter set, and a false positive set; a certificate revocation module configured to generate a certificate revocation list and store it in the memory; and a false positive module configured to generate a false positive set based on a set of potential false positive lists received from the first IoT device and other IoT devices.

[0018] Among other features, the Bloom filter evaluation module includes a second Bloom filter. The second Bloom filter is configured similarly or identically to the first Bloom filter. The Bloom filter evaluation module is configured to use the second Bloom filter to determine whether an identifier is in the Bloom filter set.

[0019] Among other features, the backend includes a memory, a certificate revocation module, a Bloom filter, a false positive module, and a control module. The memory is configured to store a certificate revocation list, a Bloom filter set, and a false positive set, wherein the certificate revocation list includes revoked certificate IDs of a first Internet of Things (IoT) device. The certificate revocation module is configured to generate a certificate revocation list and store it in the memory. The Bloom filter module includes Bloom filters and is configured to generate a Bloom filter set based on the certificate revocation list using the Bloom filters, wherein the Bloom filter set is a bit array representing the certificate revocation list. The false positive module is configured to generate a false positive set based on a first potential false positive list received from a second IoT device. The false positive set includes identifiers associated with certificates not in the certificate revocation list but in one or more potential false positive lists. The one or more false positive lists include the first potential false positive set. The false positive set includes an identifier of a third IoT device. The control module is configured to transmit the Bloom filter set and the false positive set to the second IoT device to prevent communication with the first IoT device and allow communication with the third IoT device.

[0020] Among other features, the control module operates in the following states: a first state, which initializes the Bloom filter set and distributes the Bloom filter set to at least a second IoT device and a third IoT device; a second state, when the Bloom filter set exists and the false positive set is empty, updating the false positive set based on a first potential false positive list and distributing the false positive set to at least a second IoT device and a third IoT device; a third state, when the Bloom filter set exists and the false positive set is not empty, updating the false positive set based on the first potential false positive list and distributing the false positive set to at least a second IoT device and a third IoT device; and a fourth state, which updates the Bloom filter set and the false positive set and distributes the updated Bloom filter set and the updated false positive set to at least a second IoT device and a third IoT device.

[0021] Among other features, the certificate revocation module is configured to update the certificate revocation list. The Bloom filter module is configured to periodically update the Bloom filter set based on the updated certificate revocation list.

[0022] Among other features, for each entry in the first potential false positive list, the control module is configured to: check whether the entry is in the Bloom filter set and the certificate revocation list; and in response to the entry being in the Bloom filter set and not in the certificate revocation list, update the false positive set to include the entry.

[0023] Among other features, the control module is configured to: update the Bloom filter set based on the new entry received in response to the certificate revocation list, and remove the new entry from the false positive set if it exists.

[0024] Among other features, the Bloom filter includes hash functions. Each hash function is configured to determine the bit position in the bit array based on an entry in the certificate revocation list. The Bloom filter module is configured to set the bit at the bit position to 1 based on the output of the multiple hash functions.

[0025] Among other features, the Bloom filter module is configured to: identify bit positions in the bit array of the identifier of the third IoT device's certificate; and determine whether the identifier of the third IoT device's certificate is in the Bloom filter set based on the identified bit positions in the bit array of the identifier; and communicate with the third IoT device in response to the fact that the identifier of the third IoT device's certificate is not in the Bloom filter set.

[0026] This invention provides the following technical solutions:

[0027] 1. A first Internet of Things (IoT) device, the device comprising:

[0028] Memory, the memory being configured to store

[0029] A Bloom filter set, comprising a bit array representing entries in a certificate revocation list, and a false positive set comprising a list of certificate entries incorrectly identified as revoked by the Bloom filter set;

[0030] A transceiver configured to receive a message from a second IoT device, wherein the message includes a certificate; and a Bloom filter evaluation module configured to receive the Bloom filter set from a backend station and determine whether an identifier associated with the certificate is considered to be in the Bloom filter set.

[0031] A false positive comparison module, configured to receive the false positive set from the backend station and determine whether the identifier is in the false positive set; and

[0032] A control module configured to allow communication between the first IoT device and the second IoT device based on whether the identifier is considered to be in the Bloom filter set and whether the identifier is in the false positive set.

[0033] 2. The first IoT device according to technical solution 1, wherein the control module is configured to: allow communication between the first IoT device and the second IoT device in response to the identifier being considered not to be in the Bloom filter set.

[0034] 3. The first IoT device according to technical solution 1, wherein the control module is configured to: allow communication between the first IoT device and the second IoT device in response to the identifier being in the false positive set.

[0035] 4. The first IoT device according to technical solution 1, wherein the control module is configured to: add the identifier to the potential false positive list in response to the identifier being considered to be in the Bloom filter set and not in the false positive set, and at least temporarily ignore communication from the second IoT device.

[0036] 5. The first IoT device according to technical solution 4, wherein the control module is configured to:

[0037] Transmit the potential false positive list to the backend station; and

[0038] Receive at least one of an updated version of the Bloom filter set or an updated version of the false positive set.

[0039] 6. The first IoT device according to technical solution 5, wherein the control module is configured to: determine whether to communicate with the second IoT device based on at least one of the updated version of the Bloom filter set and the updated version of the false positive set.

[0040] 7. The first IoT device according to technical solution 1, wherein the false positive set includes identifiers of certificates that are not in the certificate revocation list but are in one or more potential false positive lists generated by the first IoT device, the second IoT device, or one or more other IoT devices.

[0041] 8. The first IoT device according to technical solution 1, wherein the control module is implemented as a vehicle-to-vehicle communication module.

[0042] 9. The first IoT device according to technical solution 1, wherein the Bloom filter evaluation module includes a Bloom filter and is configured to: use the Bloom filter to determine whether an identifier associated with the certificate is considered to be in the set of Bloom filters.

[0043] 10. The first IoT device according to technical solution 1, wherein:

[0044] The Bloom filter evaluation module includes a Bloom filter;

[0045] The Bloom filter includes multiple hash functions;

[0046] The plurality of hash functions determine the corresponding bit positions in the bit array of the identifier; and

[0047] When all bits at the bit position of the bit array are set to 1, the Bloom filter evaluation module determines that the identifier is in the Bloom filter.

[0048] 11. A system comprising:

[0049] The first IoT device according to technical solution 1; and

[0050] The backend station includes a first Bloom filter, wherein the first Bloom filter is configured to generate a first Bloom filter set based on the entries in the certificate revocation list.

[0051] 12. The system according to technical solution 11, wherein:

[0052] The backend station includes:

[0053] A memory configured to store the certificate revocation list, the Bloom filter set, and the false positive set;

[0054] A certificate revocation module, configured to generate the certificate revocation list and store it in the memory; and

[0055] A false positive module is configured to generate the false positive set based on a first potential false positive list received from the first IoT device or another IoT device.

[0056] 13. The system according to technical solution 11, wherein:

[0057] The Bloom filter evaluation module includes a second Bloom filter;

[0058] The second Bloom filter is configured similarly or identically to the first Bloom filter; and

[0059] The Bloom filter evaluation module is configured to use the second Bloom filter to determine whether the identifier is in the set of Bloom filters.

[0060] 14. A backend station, the backend station comprising:

[0061] A memory configured to store a certificate revocation list, a Bloom filter set, and a false positive set, wherein the certificate revocation list includes revoked certificates of a first Internet of Things (IoT) device;

[0062] A certificate revocation module, configured to generate the certificate revocation list and store it in the memory;

[0063] A Bloom filter module, comprising Bloom filters and configured to generate a set of Bloom filters based on the certificate revocation list using the Bloom filters, wherein the set of Bloom filters is a bit array representing the certificate revocation list;

[0064] A false positive module, configured to generate a false positive set based on a first potential false positive list received from a second IoT device, wherein the false positive set includes identifiers associated with certificates not in the certificate revocation list but in one or more potential false positive lists, wherein the one or more false positive lists include the first potential false positive list, and wherein the false positive set includes an identifier of a third IoT device; and

[0065] A control module configured to transmit the Bloom filter set and the false positive set to the second IoT device to prevent communication with the first IoT device and allow communication with the third IoT device.

[0066] 15. The back-end station according to technical solution 14, wherein the control module operates in the following states:

[0067] The first state is used to initialize the Bloom filter set and distribute the Bloom filter set to at least the second IoT device and the third IoT device;

[0068] In the second state, when the Bloom filter set exists and the false positive set is an empty set, the false positive set is updated based on the first potential false positive list, and the false positive set is distributed to at least the second IoT device and the third IoT device.

[0069] In the third state, when the Bloom filter set exists and the false positive set is not empty, the false positive set is updated based on the first potential false positive list, and the false positive set is distributed to at least the second IoT device and the third IoT device; and

[0070] The fourth state is used to update the Bloom filter set and the false positive set, and to distribute the updated Bloom filter set and the updated false positive set to at least the second IoT device and the third IoT device.

[0071] 16. The back-end station according to technical solution 14, wherein:

[0072] The certificate revocation module is configured to update the certificate revocation list; and

[0073] The Bloom filter module is configured to periodically update the Bloom filter set based on the updated certificate revocation list.

[0074] 17. The backend station according to technical solution 14, wherein, for each entry in the first potential false positive list, the control module is configured to:

[0075] Check whether the entry is in the Bloom filter set and the certificate revocation list; and

[0076] In response to the entry being in the Bloom filter set and not in the certificate revocation list, the false positive set is updated to include the entry.

[0077] 18. The backend station according to technical solution 14, wherein the control module is configured to: in response to receiving a new entry in the certificate revocation list, update the Bloom filter set based on the new entry, and remove the new entry from the false positive set.

[0078] 19. The back-end station according to technical solution 14, wherein:

[0079] The Bloom filter includes multiple hash functions;

[0080] Each of the plurality of hash functions is configured to determine the bit position in the bit array based on an entry in the certificate revocation list; and

[0081] The Bloom filter module is configured to set the bit at the bit position to 1 based on the output of the plurality of hash functions.

[0082] 20. According to the backend station described in technical solution 19, the Bloom filter module is configured as follows:

[0083] The bit position in the bit array that identifies the certificate identifier of the third IoT device; and

[0084] Based on the bit position identified in the bit array of the identifier, determine whether the identifier of the certificate of the third IoT device is in the Bloom filter set; and

[0085] In response to the fact that the identifier of the certificate of the third IoT device is not in the Bloom filter set, communication is conducted with the third IoT device.

[0086] Further applicability of this disclosure will become apparent from the detailed description, claims, and drawings. The detailed description and specific examples are for illustrative purposes only and are not intended to limit the scope of this disclosure. Attached Figure Description

[0087] This disclosure will be more fully understood from the detailed embodiments and accompanying drawings, in which:

[0088] Figure 1 This is a functional block diagram of an example security system including a backend station and an Internet of Things (IoT) device according to the present disclosure;

[0089] Figure 2 This is a functional block diagram of an example vehicle including a V2V module according to this disclosure;

[0090] Figure 3 This is a functional block diagram of an example V2V security system illustrating the state of the background control module according to this disclosure;

[0091] Figure 4 This is an example of a Bloom filter array according to this disclosure;

[0092] Figure 5 The illustration shows an example operation method of the background control module according to this disclosure; and

[0093] Figure 6 The illustration shows an example operation method of a transmitting IoT (or V2V) module according to this disclosure; and

[0094] Figure 7 An example operation method of receiving an IoT (or V2V) module according to this disclosure is illustrated.

[0095] In the figures, reference numerals may be reused to identify similar and / or identical elements. Detailed Implementation

[0096] During communication between V2V communication modules (hereinafter referred to as "V2V modules") of two vehicles, messages are transmitted from the sending V2V module to the receiving V2V module. Each message transmitted by the sending V2V module includes a certificate verified by the receiving V2V module. The receiving V2V module uses the public key from the certificate to verify the signature in the message and determines (i) whether the certificate was signed by a trusted certificate authority, (ii) whether the certificate has not expired, and (iii) whether the certificate has not been revoked. As an example, a certificate may be revoked because it has been identified as being used by an attack device and / or for some other reason. A backend station may store a Certificate Revocation List (CRL) that includes a list of revoked certificate identifiers (IDs) and periodically broadcast the complete CRL to the V2V modules. The receiving V2V module can compare the certificate ID of the sending V2V module with the certificate ID in the CRL. If the certificate ID is in the CRL, the certificate has been revoked and is invalid. If, for example, the certificate of the sending V2V module has been revoked, the receiving V2V module ignores the status information in the received message.

[0097] CRLs can include tens of thousands of certificate IDs, requiring significant storage space. For example, there are over 250 million vehicles in the United States. An example revocation rate for these vehicles' certificates could be 1%, or 2.5 million vehicles. If each revocation entry in the CRL comprises 40 bytes, then 100 megabytes (MB) would be needed to store the CRL. Typical vehicles have limited storage space and processing resources, regularly travel at high speeds, and may have limited and / or intermittent internet connectivity. The massive data exchange between backend stations and vehicles to obtain CRLs is costly in terms of both time and bandwidth.

[0098] Considering the vehicle's speed, the certificate revocation check response time should be less than 100 milliseconds (ms). This is necessary to enable the receiving V2V module to quickly determine the validity of the sending V2V module's certificate, and, if valid, to have an appropriate amount of remaining time to perform vehicle operations. Vehicle operations may include safety actions such as controlling vehicle acceleration or deceleration, controlling vehicle steering, and providing alert messages to the driver. Vehicle operations can be performed based on safety and / or status information received from the sending V2V module.

[0099] At least for the reasons mentioned above, broadcasting a CRL to V2V modules for certificate revocation checks provides a poorly scalable solution for scenarios with many V2V modules. Similarly, due to stated vehicle constraints and the size of the CRL, the system performance for checking certificate revocation status is poor and inefficient. A CRL containing 100MB of data not only requires a large amount of memory space to store but also a significant number of processing cycles to search for entries in the CRL and determine if a specific certificate ID is present. The memory, processing resources, computing power, and device type required for receiving and processing large CRLs within less than 100ms are expensive and often infeasible. In environments with many V2V modules, security breaches and functional losses can occur where individual V2V modules are unable to host and / or search large CRLs within the allowed timeframe.

[0100] The examples described herein include techniques for efficiently performing certificate revocation checks at V2V modules with limited storage, limited computing power, and a lack of reliable network connectivity to remotely located backend stations. The examples provide certificate revocation status in real time (i.e., less than, for example, 100ms). Certificate revocation status can be determined locally and efficiently at the V2V module, both in terms of time and storage.

[0101] The examples described in this document include a backend station broadcasting certificate revocation truth data in the form of a Bloom Filter Set (BFS) and a False Positive Set (FPS). The BFS refers to a bit array generated based on the CRL. The FPS may include zero or more entries for certificate IDs (or vehicle IDs) that have been identified as being in the BFS by one or more V2V modules but are identified as false positives by the backend based on the complete CRL. The V2V modules perform certificate revocation checks based on the BFS and FPS, which includes data significantly smaller than the amount in the corresponding CRL. If, for example, a certificate ID is determined not to be in the BFS, the certificate has not been revoked. If a certificate ID is determined to be in the BFS, the receiving V2V module checks the FPS. If it is in the FPS, the certificate has not been revoked. If the certificate has not been revoked, the content of the message sent by the V2V module is processed by the receiving V2V module.

[0102] If the certificate ID is in BFS but not in FPS, the certificate ID is placed on the potential false positive list of the receiving V2V module. The receiving V2V module then ignores messages from the sending V2V module, at least temporarily, and shares the potential false positive list with the backend station. In response, the backend station verifies whether the certificate ID has been revoked based on CRL. The result of this verification is reported as part of the updated FPS to the receiving V2V module and other V2V modules. The V2V module can determine whether to process the message from the sending V2V module based on the updated FPS received from the backend station.

[0103] Each of the shared BFS and FPS pairs is significantly smaller than the corresponding CRL size, and therefore requires significantly less memory. V2V modules with limited resources can efficiently store and process BFS and FPS to provide fast certificate revocation checks. The disclosed examples are scalable to environments with many V2V modules and are applicable to Internet of Things (IoT) devices, as further described below.

[0104] Figure 1 A security system 100 comprising a backend station 102 and Internet of Things (IoT) devices 104 is illustrated. The backend station 102 may be a server of a service provider. The IoT device 104 may refer to a vehicle, a component of a vehicle, an appliance, a mobile network device, a wearable device, a machine, a tool, a base station, a beacon, and / or other network devices that are part of a public key infrastructure. The backend station 102 includes a control module 110, a transceiver 112, and a memory 114. The control module 110 includes a CRL module 115, a Bloom filter module 116, and an FPS module 118. The memory 114 stores a CRL 120, a Bloom filter 122, and an FPS 124. Each of the IoT devices 104 includes a control module 130, an IoT module 132, a transceiver 134, and a memory 136. The IoT module 132 may be implemented as part of the control module 130. Each of the IoT modules 132 includes a Bloom filter 138 and an FPS comparison module 140. The memory 136 can store the latest received version of BFS 122', the latest received version of FPS 124', and the potential false positive (FP) list 142. Each of the memory modules 136 stores the corresponding potential FP list generated by the respective BFS evaluation module 138 and FPS comparison module 140.

[0105] The CRL module 115 of the backend station 102 maintains and updates the CRL 120. The Bloom filter module 116 includes a Bloom filter 150 and uses the Bloom filter 150 to generate and update the BFS 122 based on the CRL 120. The FPS module 118 maintains and updates the FPS 124 based on the CRL 120. The control module 110 provides the BFS 122 and FPS 124 to the IoT device 104 via transceiver 112. Through modules 138 and 140, the IoT module 132 can then perform a certificate revocation check based on the BFS 122 and FPS 124. The BFS evaluation module 138 includes a Bloom filter 152, each of which can be configured similarly or identically to the Bloom filter 150. The Bloom filter 152 is used to determine whether the BSM's certificate ID is in the BFS 122'. IoT device 104 generates a potential FP list 142 based on the certificate ID included in BFS 122' and / or FPS 124', and periodically sends the potential FP list 142 to the backend station 102 to verify and update FPS 124. The updated FPS is then shared with IoT device 104. These operations will be described further below.

[0106] Figure 2 A vehicle 200 is shown, including a V2V module 202 and other modules such as a vehicle control module 204. Although the vehicle 200 is shown as having multiple vehicle control modules, it could have a single vehicle control module. The V2V module is... Figure 1 This is an example of one of the IoT modules 132. Similarly, although V2V module 202 is shown as connected to transceiver 206 and vehicle control module 204, V2V module 202 can be connected to one or more devices and systems to which vehicle control module 204 is connected.

[0107] V2V module 202 performs vehicle-to-vehicle communication via transceiver 206. V2V module 202 includes memory 203 that stores credential packets 214 that can be generated by a certificate authority network device. The credential packet includes a signed public certificate. The signed public certificate includes a corresponding public key.

[0108] V2V module 202 also includes a security processor chip 210 with memory 212. Memory 212 stores private / public key pairs 216 generated by the security processor chip 210 prior to installation on V2V module 202. Security processor chip 210 may also include a BFS evaluation module 218 and an FPS comparison module 219, which are similar to... Figure 1 It operates in the same manner as modules 138 and 140. The V2V module 202 can generate an alarm signal to warn the driver of vehicle 200. The alarm signal can be provided, for example, by the infotainment system 262.

[0109] Vehicle control module 204 can control the operation of various vehicle systems. V2V module 202 can transmit information received from vehicle control module 204 regarding, for example, the status of the systems, to other V2V modules in other vehicles. Vehicle systems may include propulsion system 254, air conditioning system 256, seating system 258, lighting system 260, infotainment system 262, navigation system 264, and / or other vehicle systems 266, such as braking systems, communication systems, etc. Vehicle control module 204 can execute applications and corresponding functions to control vehicle systems. Vehicle systems may include actuators. For example, air conditioning system 256 may include one or more pumps 269, heaters 270, and fans 271. This control may be based on signals from sensor 272 and may include wireless communication via transceiver 206 and / or other transceivers. Propulsion system 254 may include engine 274, transmission 276, one or more motors 278, and power source (e.g., battery system) 280. Engine 274 may include throttle system 282, ignition system 284, and fuel system 286.

[0110] Figure 3 Explanation is shown Figure 1 The background control module 110 is a state-controlled V2V security system 300, and includes V2V modules 302 and 304. Although two V2V modules are shown, the background station 102 can communicate with any number of IoT (or V2V) modules, each implemented in a corresponding network device or vehicle. The background control module 110 can start in state 1 and initialize a Bloom filter to provide a Bloom Filter Set (BFS) and distribute the BFS to the V2V modules and / or other IoT modules. The BFS includes a bit array representing a specific CRL. A Bloom filter is a spatially efficient probabilistic data structure used to quickly test whether an element (or entry e) is a member of a set S. Bloom filters allow efficient determination, in both time and space (storage space), of whether a certificate ID, IoT ID, and / or vehicle ID is in a CRL without needing to check the CRL. When using a Bloom filter, false positives are possible, but false negatives are not. ID entries can be added to the BFS and / or the BFS can be queried to determine whether an ID is in the BFS. The names used to add entries to the set are (S∪{e1}, D∪{e2}, S∪{e3}, ..., S∪{e... n}, where e n There are entries, and n is an integer. The naming convention used for querying BFS is to determine whether an ID might be in the i-th entry of set S, i.e., (e i ∈S?).

[0111] Figure 4 An example Bloom filter array 400 is shown. In the example shown, the Bloom filter array 400 has 18 bits, but can include a different number of bits m. The Bloom filter can have a predetermined number of different hash functions k, which are used to set the bit values ​​in the Bloom filter array 400, where k << m. Each of the hash functions maps or hashes an element to one of the m array positions, thus generating a uniform random distribution. Initially, all bits of the array are 0, meaning the set S (or BFS) is empty. To add an element (or ID entry) e, the ID entry is provided to each of the k hash functions to obtain k array positions, and the bits at the k array positions are set to 1. For example, in Figure 4 In this process, entries x, y, and z are received and hashed to provide corresponding positions in the Bloom filter array 400. For the example shown, the Bloom filter has 3 hash functions, and therefore provides 3 positions for each of entries x, y, and z.

[0112] To query an element (or ID entry) e in a set S (or BFS), also known as determining whether an ID entry is in a Bloom filter, the entry e is fed to each of k hash functions to obtain the corresponding k array positions. This is as follows: Figure 4 As shown. If any bit at the provided position is 0, then entry e is not in the set. If all bits at the provided position are 1, then either entry e is in the set, or the bit was accidentally set to 1 during the insertion of another entry, resulting in a false positive. Figure 4 In the example shown, entry e is one of entries x, y, z because it hashes to a bit array position containing 0, while the positions of x, y, and z are all set to 1.

[0113] The query time of a Bloom filter is constant, and its complexity is represented as O(k). For a Bloom filter with a fixed array size, the more elements (or entries) added to the BFS, the higher the probability of false positives. The accuracy of a Bloom filter depends on the size of the filter (i.e., the number of bit positions), the number of hash functions k used in the filter, and the number of elements n added to the BFS. Typically, k is a constant and much smaller than m, where m is proportional to the number of elements to be added. The choice of k and the proportionality constant m can be determined by the expected false positive probability ratio p of the Bloom filter. The false positive probability ratio p can be represented by Equation 1.

[0114]

[0115] In contrast, a Bloom filter with a 1% error and a properly set value of k requires approximately 9.6 bits per entry in the array, regardless of the entry size. This advantage is primarily due to the small size of the BFS and partly due to the probabilistic nature of the Bloom filter. By increasing the false positive rate by approximately 4.8 bits per entry in the array, the 1% false positive rate can be reduced by a factor of 10. For a given m and n, the value of k that minimizes the false positive probability ratio p can be represented by Equation 2.

[0116]

[0117] Table 1 below shows examples of false positive probability ratios for different m, n, and k values. The m, n, and k values ​​can be selected and / or adjusted according to the application. Table 1 provides false positive probability ratios for different ratios m / n (2-16) and k values ​​(1-8). Column 2 of Table 1 also includes k values ​​for m / n values ​​2-16 according to Formula 2. The shaded boxes are examples of m, n, and k values ​​that provide efficient processing with low false positive probabilities and minimal memory usage. The shaded boxes also correspond to the examples in Table 2.

[0118]

[0119]

[0120] Table 1 – False positive probability ratios for m, n, and k values.

[0121] Refer again Figure 3 During state 1 (indicated by box 310), Bloom filter module 116 initializes Bloom filter 150 with predetermined parameter values ​​for m, n, and k. The number of hash functions k and the number of bits n allocated to each element are set and depend on the selected false positive probability ratio p. The false positive probability ratio p can be selected based on available resources, such as the memory and processing power of IoT devices and / or vehicles. For each entry e in the CRL, entry e is added to the Bloom filter by setting the bits of the Bloom filter array as described above.

[0122] Control module 110 can periodically operate in states 2 to 3. When there is an existing BFS but no existing FPS and a potential FP list is received from one of the V2V modules 302 and 304, control module 110 operates in state 2 (indicated by box 312). FPS module 118 generates a new FPS based on the potential FP list and distributes the FPS to V2V modules 302 and 304, and may distribute it to other V2V modules. During state 2, FPS module 118 collects potential FP lists from the V2V modules. FPS can be initialized to an empty set, represented as FPS = {}. For each false positive entry (fpe) in each of the potential FP lists, FPS module 118 checks whether fpe is in CRL and / or BFS. If fpe is in BFS (fpe∈BFS) but not in CRL... Then fpe is included in FPS, which is represented as FPS∪{fpe}.

[0123] When the BFS and FPS exist (i.e., have been generated) and a new list of potential FPs is received, control module 110 operates in state 3 (indicated by block 314). FPS module 118 updates the existing FPS and distributes the updated FPS to V2V modules 302 and 304, and may also distribute the FPS to other V2V (or IoT) modules. FPS module 118 collects the potential FP list from the V2V modules. For each entry fpe in the potential FP list, FPS module 118 checks if fpe is in the CRL and BFS. If fpe ∈ BFS and Then FPS∪{fpe}.

[0124] If an FPS exists and the updated BFS is distributed to V2V modules 302 and 304, and optionally the updated FPS is also distributed to V2V modules 302 and 304, then when the existing BFS is updated and the FPS is optionally updated, the control module 110 operates in state 4 (indicated by block 316). The updated BFS and FPS can also be distributed to other V2V (or IoT) modules. For each new certificate entry e in the CRL, entry e is added to the BFS, and if entry e ∈ FPS, entry e is removed from the FPS, which is represented as FPS = FPS\{e}.

[0125] If a new potential FP list is received, control module 110 can periodically transition from state 1 to state 2. If a new potential FP list is received, control module 110 can periodically transition from state 2 to state 3. If a new CRL entry is received, control module 110 can periodically transition from state 2 to state 4. If a new CRL entry is received, control module 110 can periodically transition from state 3 to state 4. If a new potential FP list is received, control module 110 can periodically remain in state 3. If a new potential CRL entry is received, control module 110 can periodically transition from state 4 to state 0. If a new potential FP list is received, control module 110 can periodically transition from state 4 to state 3. If a new CRL entry is received, control module 110 can periodically remain in state 4.

[0126] V2V modules 302 and 304 periodically receive and store BFS and FPS from backend station 102. Each V2V module evaluates the certificate ID (or vehicle ID) of the received incoming message. The ID can be referred to as entry c. The evaluation includes querying the BFS. If Entry c is determined not to be revoked. If c ∈ BFS, then entry c can be revoked or the BFS query result is a false positive. If c ∈ BFS, then entry c is checked according to FPS. If c ∈ FPS, then the certificate is not revoked. Then entry c is either revoked or assumed to be revoked, and entry c is added to the potential FP list of the V2V module. The V2V module periodically sends the potential FP list to backend station 102.

[0127] The system disclosed in this article can be operated in many ways; example methods are provided in... Figures 5 to 7 The diagram is shown in the image. Figure 5 The operation method of the background control module is shown. Figure 6 The method for sending IoT (or V2V) modules is shown. Figure 7 The method of receiving an IoT (or V2V) module is shown.

[0128] While the following methods are primarily described for a V2V example including a V2V module, the methods can be similarly implemented for other IoT modules. Similarly, although the following methods are shown as individual methods, the methods and / or operations derived from the individual methods can be combined and executed as separate methods. Figure 6 and Figure 7 The method can be executed simultaneously Figure 5 The method.

[0129] Although the following operations are mainly about Figures 1 to 4The implementation methods described herein are as follows, but the operation can be easily modified to suit other implementation methods of this disclosure. Figures 5 to 7 The operation can be executed iteratively. Figure 5 The method can begin at 500. At 502, CRL module 115 generates and stores the initial CRL. This may include the CRL module receiving ID entries corresponding to the corresponding certificates from network devices, such as those in a vendor facility, which may occur periodically. The ID entries in CRL 120 may be certificate IDs, IoT IDs, and / or vehicle IDs.

[0130] At 504, Bloom filter module 116 uses a probability data structure called Bloom filter 150 to compute BFS 122, which is a bit array representing CRL 120. At 506, Bloom filter module 116 distributes the BFS to IoT modules, such as modules 132, 302, 304 and / or other IoT modules.

[0131] At point 508, and to overcome the drawbacks of the Bloom filter 150 with its low false positive rate, the FPS module 118 generates FPS 124. Initially, FPS 124 can be generated as an empty set (i.e., without any entries). FPS 124 is then updated based on the potential FP list 142 generated by the IoT module to include entries.

[0132] At 510, CRL module 115 determines whether a new CRL entry and / or other updates have been received. CRL module 115 may periodically receive additional entries for CRL and / or other updates. If an update has been received, operation 512 is performed.

[0133] At 512, CRL module 115 updates CRL 120 based on the received update. This may include adding new ID entries to CRL 120 and / or updating, changing, or removing current ID entries. At 514, Bloom filter module 116 may update BFS 122 via Bloom filter 150 based on the changes to CRL that occurred at 512.

[0134] At point 516, control module 110 can determine whether a predetermined time has elapsed since the latest versions of BFS122 and FPS124 were sent to the IoT module. If so, operation 528 can be performed; otherwise, operation 510 can be performed. The background control module 110 periodically sends the latest and / or updated versions of BFS and FPS to the IoT module.

[0135] The following operations 518, 520, 522, 523, 524, and 526 can be performed for each IoT module and determine whether each entry in the received potential FP list is in the CRL.

[0136] At 518, control module 110 determines whether a potential FP list has been received from one or more IoT modules. If so, operation 520 is executed. At 520, CRL module 115 compares the ID entries in the received potential FP list with the entries in CRL 120. At 522, CRL module 115 determines whether the ID entry in the potential FP list is in CRL 120. If the ID entry is not in CRL 120, operation 523 is executed, and the ID entry is identified as a false positive. If the ID entry is in CRL 120, operation 526 is executed, and the entry is identified as revoked for the corresponding IoT device (or vehicle).

[0137] At 523, Bloom filter module 116 determines whether the ID entry in the potential FP list is in BFS 122. If not, operation 526 is performed. If the ID entry is in BFS 122, operation 524 is performed. At 524, FPS module 118 adds the ID entry from the potential FP list to FPS 124.

[0138] At point 526, control module 110 can determine if there is another entry in the received potential FP list for comparison. If so, operation 520 is executed; otherwise, operation 528 is executed. Tasks 520, 522, 523, 524, and 526 are performed until FPS module 118 has already considered the received potential FP list (including entries from...). Figures 6 to 7 The method described above updates FPS 124 by using ID entries from the potential FP list received from the transmitting and receiving IoT modules. At 528, the background control module 110 sends the latest and / or updated versions of BFS 122 and / or FPS 124 to the IoT module.

[0139] Figure 6 The method can begin at 600 and is executed by the transmitting IoT (or V2V) module. At 602, the control module 130 and / or IoT module 132 of the transmitting IoT device receive the initial BFS 122 and (optionally) FPS 124 and store them in memory 136.

[0140] At 604, control module 130 and / or IoT module 132 generate a Basic Security Message (BSM) for transmission to the receiving IoT device. The BSM includes the aforementioned certificate. At 606, control module 130 broadcasts the BSM via transceiver 134, which can be received by the receiving IoT device. After operation 606, the method may end at 608.

[0141] Figure 7The method of receiving an IoT (or V2V) module is shown. Figure 7 The method can begin at 700 and is executed by the receiving IoT (or V2V) module. At 702, the receiving IoT device's IoT module receives the initial BFS122 and (optionally) FPS124 received from the backend station 102 and stores them in the receiving IoT device's memory.

[0142] At 704, the IoT module receives the BSM transmitted by the sending IoT module at 606. At 706, the IoT module determines the certificate ID, IoT ID, and / or vehicle ID of the sending IoT module as indicated in the certificate of the BSM. The certificate ID, IoT ID, and / or vehicle ID are referred to below as the received ID or certificate entry c.

[0143] At 708, the BFS evaluation module receiving the IoT device evaluates the certificate entry c of the received BSM by first querying BFS122' to determine if the received ID is in the BFS. If BFS122' has not been updated to match BFS 122, then BFS122' can be identical to BFS122. The certificate entry c is evaluated to determine if the received ID has been revoked. The BFS evaluation module performs k hash functions of the Bloom filter 150 on the received ID to determine if the received ID is in BFS122'. If none of the bits in the Bloom filter array at the positions provided by the k hash functions are set to 1, then... Furthermore, certificate entry c is definitely not revoked. If all bits of the Bloom filter array at the positions provided by the k hash functions are set to 1, then c ∈ BFS, and certificate entry c may or may not be revoked.

[0144] Potential hash collisions can occur, leading to false positives. A hash collision occurs when all bits at the positions provided by k hash functions are set to 1, even though the received corresponding ID has not actually been revoked. In this case, an unrevoked "false positive" can become a security vulnerability because all IoT devices determine that certificate entry c has been revoked and therefore ignore messages from the sending IoT device. To correct this problem and eliminate the need for IoT devices to send signals to the backend station to provide an indication of whether certificate entry c has been revoked, FPS124 is generated by the backend station 102 and provided to the IoT devices for inspection. This also helps overcome the time constraints and intermittent internet connectivity issues of IoT devices.

[0145] At 710, if the received ID is in BFS122' (c∈BFS), then operation 711 can be performed. When it is in BFS122', the BFS evaluation module can at least temporarily consider the certificate ID as revoked and ignore the BSM from the sending IoT module until it is determined that the certificate ID is a false positive as indicated by the backend station 102. If c∈BFS, then c may have been revoked or the BFS query result is a false positive. If the received ID is not in BFS... Then operation 716 can be executed.

[0146] At 711, the FPS comparison module of the receiving IoT device determines whether the received ID is in FPS124'. If FPS124' has not been updated to match FPS124 at backend station 102, then FPS124' can be the same as FPS124. If the received ID is in FPS124' (c∈FPS), the certificate is not revoked, and operation 716 is performed. If the received ID is not in FPS124'... The conclusion is (assuming) the certificate is revoked until further notice, and operation 712 is performed.

[0147] At 712, the FPS comparison module adds the received ID to the potential FP list. At 714, the control module and / or IoT module of the receiving IoT device ignores the received BSM. At 716, the control module of the receiving IoT device continues execution to process the contents of the received BSM.

[0148] At point 718, the control module or receiving IoT module of the receiving IoT device determines whether it is time to send the potential FP list to the backend station 102. As an example, the receiving IoT module may send the potential FP list to the backend station 102 once a week via the Internet. If it is time to send the potential FP list, operation 720 is performed; otherwise, if another BSM is received or the process may end at 724, operation 704 can be performed. The result of the certificate revocation check is cached, so that the receiving IoT (or V2V) module does not need to repeatedly check the revocation status of the sending vehicles for hundreds of thousands of messages received within a short period.

[0149] At 720, the control module or receiving IoT module of the receiving IoT device sends the potential FP list to the backend station 102. At 721, the receiving IoT module clears the potential FP list at the receiving IoT device (or vehicle).

[0150] At 722, in response to sending the potential FP list, the IoT module can receive an updated BFS and / or an updated FPS from the backend station 102. The BFS can indicate whether an entry ID in the potential FP list has been withdrawn, and the FPS can indicate whether an entry ID in the potential FP list is a false positive. If one or more of the entry IDs are false positives, the control module and / or IoT module of the receiving IoT device can allow communication with (multiple) sending IoT devices and / or receive and process BSM broadcasts from (multiple) corresponding sending IoT devices. If another BSM is received, the method can end at 724 or return to operation 704.

[0151] Figures 5 to 7 The above operations are considered illustrative examples. Depending on the application, operations may be performed sequentially, synchronously, simultaneously, continuously, within overlapping time periods, or in different orders. Similarly, any operation may not be performed or may be skipped, depending on the implementation and / or order of the events.

[0152] The above example solves the CRL distribution and verification problem under the same constraints in a scalable and efficient manner. The disclosed backend control module generates a transformed version of the CRL that is much smaller than the original CRL. The transformed version is represented as the generated BFS and the generated FPS. This allows a separate IoT device (or V2V module) with limited computing power and storage to store the BFS and FPS, and to perform certificate revocation checks efficiently at the IoT device (or V2V module). Less bandwidth is required to transmit the BFS and FPS compared to the CRL. Due to the Bloom filter properties and the fact that the combined BFS and FPS are orders of magnitude smaller than the CRL, querying the BFS and FPS is more efficient in both time and space than querying the CRL.

[0153] Examples can be implemented to protect all IoT devices (or vehicles) capable of performing the exposed operations. Compared to a system that distributes the entire CRL to vehicles, the examples can reduce file size by 25 times, resulting in lower data transfer costs, lower module storage costs, and lower module processing costs. The less than 25x reduction in memory usage is illustrated by the example values ​​in Table 2. Table 2 is a comparison and applicability table of example performance. The variable O refers to the complexity of the query performed. The complexity of the CRL broadcast technique is proportional to log2(n), which is significantly more complex than a solution proportional to a constant 1.

[0154]

[0155] Table 2 – Performance Comparison.

[0156] The examples disclosed in this article are applicable to IoT devices with a large number of end devices using public key infrastructure (PKI) security, each with limited storage and processing capacity, and each with only occasional internet access.

[0157] Distributing a complete CRL to vehicles requires significant data transfer and expensive memory, and has slow associated processing times. Another impractical approach involves using Bloom filters and having vehicles call a backend in real-time to check if the certificate ID is in the CRL (or "hit"), and thus check whether a "potentially revoked" certificate is actually revoked or merely a false positive. This is because vehicles have less than a tenth of a second to verify any given certificate. Such real-time internet interaction is impossible in V2V networks, where vehicles check hundreds of certificates per second, and WAN latency (potentially hundreds of milliseconds) will produce useless responses at certain points. Ignoring "false positive" checks prevents legitimate vehicles from using V2V security systems.

[0158] Another infeasible approach is to use a Bloom filter, assuming all hits are genuine revocations while ignoring the possibility of false positives. This is because if a vehicle is a false positive, it might be permanently ignored by other vehicles, thus losing the security benefits associated with V2V communication. Another infeasible approach is to have the back-end station identify known false positives without the vehicle uploading a list of potential false positives. Whenever any certificate is revoked, the back-end station could check all issued certificates. However, this would require hundreds of millions of checks per cycle, and the back-end station (or the central CRL maintenance office) would not know all the certificates generated by original equipment manufacturers (OEMs).

[0159] The examples disclosed in this paper overcome the aforementioned problems by enabling revocation across a population of hundreds of millions of vehicles (or IoT devices) using several orders of magnitude less memory storage by using an aggregated set of Bloom filters and a set of false positives instead of the full CRL. This reduces memory costs and the amount of bandwidth associated with revocation. The examples disclosed in this paper involve vehicles collecting “potentially revoked” certificate files and periodically uploading them to a backend station. The backend station uses the full CRL to identify false positives and periodically distributes corresponding “known false positive” files to the vehicles to supplement the provided BFS.

[0160] The foregoing description is merely illustrative in nature and is not intended to limit this disclosure, its application, or use. The broad teachings of this disclosure can be implemented in various forms. Therefore, while this disclosure includes specific examples, its true scope should not be limited thereto, as other modifications will become apparent upon study of the drawings, specification, and the following claims. It should be understood that one or more steps within the method may be performed in a different order (or simultaneously) without altering the principles of this disclosure. Furthermore, while each embodiment is described above as having certain features, any one or more of those features described with respect to any embodiment of this disclosure can be implemented and / or combined with features of any other embodiment, even if such combination is not explicitly described. In other words, the described embodiments are not mutually exclusive, and arrangements of one or more embodiments with another embodiment remain within the scope of this disclosure.

[0161] Spatial and functional relationships between components (e.g., between modules, circuit elements, semiconductor layers, etc.) are described using various terms, including “connected,” “engaged,” “coupled,” “adjacent,” “right next to,” “on top of,” “below,” and “set.” Unless explicitly described as “direct,” when describing the relationship between a first and a second component in the above disclosure, such relationship can be a direct relationship in which no other intervening component is present between the first and second components, but it can also be an indirect relationship in which one or more intervening components are present (spatially or functionally) between the first and second components. As used herein, the phrase “at least one of A, B, and C” should be interpreted as referring to the logic of using a non-exclusive OR (A or B or C) and should not be interpreted as referring to “at least one of A, at least one of B, and at least one of C.”

[0162] In a diagram, the direction of an arrow (as indicated by the arrow) typically represents the flow of information (such as data or instructions) that is meaningful to the diagram. For example, when components A and B exchange various types of information, but the information transmitted from component A to component B is relevant to the diagram, the arrow can point from component A to component B. This unidirectional arrow does not mean that no other information is being sent from component B to component A. Furthermore, for information transmitted from component A to component B, component B can send a request for the information to component A or receive confirmation of the information.

[0163] In this application, which includes the definitions below, the term "module" or "controller" may be replaced by the term "circuit". The term "module" may refer to, be part of, or include the following: application-specific integrated circuit (ASIC), digital, analog, or mixed analog / digital discrete circuit, digital, analog, or mixed analog / digital integrated circuit, combinational logic circuit, field-programmable gate array (FPGA), processor circuitry (shared, dedicated, or grouped) that executes code, memory circuitry (shared, dedicated, or grouped) that stores code executed by the processor circuitry, other suitable hardware components that provide the described functionality, or combinations of some or all of the above, such as in a system-on-a-chip.

[0164] A module may include one or more interface circuits. In some examples, the interface circuits may include wired or wireless interfaces that connect to a local area network (LAN), the Internet, a wide area network (WAN), or a combination thereof. The functionality of any given module of this disclosure can be distributed among multiple modules connected via interface circuits. For example, multiple modules can allow for load balancing. In further examples, a server (also referred to as a remote or cloud) module may perform certain functions on behalf of a client module.

[0165] As used above, the term "code" can include software, firmware, and / or microcode, and can refer to programs, routines, functions, classes, data structures, and / or objects. The term "shared processor circuitry" includes a single processor circuitry that executes some or all of the code from multiple modules. The term "group processor circuitry" includes processor circuitry that, in combination with additional processor circuitry, executes some or all of the code from one or more modules. References to multiple processor circuitry include multiple processor circuitry on a discrete die, multiple processor circuitry on a single die, multiple cores of a single processor circuitry, multiple threads of a single processor circuitry, or a combination of the above. The term "shared memory circuitry" includes a single memory circuitry that stores some or all of the code from multiple modules. The term "group memory circuitry" includes memory circuitry that, in combination with additional memory, stores some or all of the code from one or more modules.

[0166] The term "memory circuit" is a subset of the term "computer-readable medium." As used herein, the term "computer-readable medium" does not include transient electrical or electromagnetic signals propagated through a medium (such as on a carrier wave); therefore, the term "computer-readable medium" can be considered tangible and non-transient. Non-limiting examples of non-transient, tangible computer-readable media are non-volatile memory circuits (such as flash memory circuits, erasable programmable read-only memory circuits, or mask read-only memory circuits), volatile memory circuits (such as static random access memory circuits or dynamic random access memory circuits), magnetic storage media (such as analog or digital magnetic tape or hard disk drives), and optical storage media (such as CDs, DVDs, or Blu-ray discs).

[0167] The apparatus and methods described in this application can be implemented, in part or in whole, by a special-purpose computer created by configuring a general-purpose computer to perform one or more specific functions embodied in a computer program. The aforementioned function blocks, flowchart components, and other elements serve as a software specification that can be translated into a computer program through the routine work of a skilled technician or programmer.

[0168] A computer program includes processor-executable instructions stored on at least one non-transitory, tangible, computer-readable medium. A computer program may also include or depend on stored data. A computer program may include a basic input / output system (BIOS) that interacts with the hardware of a special-purpose computer, device drivers that interact with specific devices of the special-purpose computer, one or more operating systems, user applications, background services, background applications, etc.

[0169] Computer programs may include: (i) descriptive text to be parsed, such as HTML (Hypertext Markup Language), XML (Extensible Markup Language), or JSON (JavaScript Object Annotation); (ii) assembly code; (iii) object code generated from source code by a compiler; (iv) source code executed by an interpreter; (v) source code compiled and executed by a just-in-time (JIT) compiler, etc. As an example only, source code can be written using the syntax of a language, including C, C++, C#, Objective C, Swift, Haskell, Go, SQL, R, Lisp, etc. Fortran, Perl, Pascal, Curl, OCaml, HTML5 (Hypertext Markup Language 5th Edition), Ada, ASP (Dynamic Server Homepage), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Visual Lua, MATLAB, SIMULINK and

[0170] None of the elements described in the claims are intended to be a means-plus-function element within the scope of meaning of 35 § 112(f) of the United States Code, unless the element is explicitly described by the phrase “for a manner of” or in the case of a method claim using the phrase “for an operation of” or “for a step of”.

Claims

1. A first Internet of Things (IoT) device, the device comprising: Memory, the memory being configured to store A Bloom filter set, comprising a bit array representing entries in a certificate revocation list, and a false positive set comprising a list of certificate entries incorrectly identified as revoked by the Bloom filter set; A transceiver configured to receive a set of Bloom filters from a first Bloom filter at a backend station and to receive messages from a second Internet of Things device, wherein the messages include certificates; A Bloom filter evaluation module is configured to receive the Bloom filter set from the backend station via the transceiver and includes a second Bloom filter, the second Bloom filter being configured to determine whether the identifier of the certificate is considered to be in the Bloom filter set. A false positive comparison module, configured to receive the false positive set from the backend station via the transceiver and determine whether the identifier is in the false positive set; and A control module configured to allow communication between a first IoT device and a second IoT device based on whether the identifier is considered to be in the Bloom filter set and whether the identifier is considered to be in the false positive set; in response to the identifier being considered to be in the Bloom filter set and not in the false positive set, add the identifier to a potential false positive list and at least temporarily ignore communication from the second IoT device; transmit the potential false positive list to the backend station; and receive at least one of an updated version of the Bloom filter set or an updated version of the false positive set; and determine whether to communicate with the second IoT device based on at least one of the updated version of the Bloom filter set and the updated version of the false positive set.

2. The first Internet of Things device according to claim 1, wherein, The control module is configured to allow communication between the first IoT device and the second IoT device in response to the identifier being considered not to be in the Bloom filter set.

3. The first Internet of Things device according to claim 1, wherein, The control module is configured to allow communication between the first IoT device and the second IoT device in response to the identifier being in the false positive set.

4. The first Internet of Things device according to claim 1, wherein, The false positive set includes identifiers of certificates that are not in the certificate revocation list but are in one or more potential false positive lists generated by the first IoT device, the second IoT device, or one or more other IoT devices.

5. The first Internet of Things device according to claim 1, wherein, The control module is implemented as a vehicle-to-vehicle communication module.

6. The first Internet of Things device according to claim 1, wherein: The Bloom filter evaluation module includes a Bloom filter; The Bloom filter includes multiple hash functions; The plurality of hash functions determine the corresponding bit positions in the bit array of the identifier; and When all bits at the bit position of the bit array are set to 1, the Bloom filter evaluation module determines that the identifier is in the Bloom filter.

7. A security system, the system comprising: The first Internet of Things device according to claim 1; and The backend station includes a first Bloom filter, wherein the first Bloom filter is configured to generate a first Bloom filter set based on the entries in the certificate revocation list.

8. The system according to claim 7, wherein: The backend station includes: A memory configured to store the certificate revocation list, the Bloom filter set, and the false positive set; A certificate revocation module, configured to generate the certificate revocation list and store it in the memory; and A false positive module is configured to generate the false positive set based on a first list of potential false positives received from the first IoT device or another IoT device.

9. The system according to claim 7, wherein: The Bloom filter evaluation module includes a second Bloom filter; The second Bloom filter is configured similarly or identically to the first Bloom filter; and The Bloom filter evaluation module is configured to use the second Bloom filter to determine whether the identifier is in the set of Bloom filters.

10. A backend station, the backend station comprising: A memory configured to store a certificate revocation list, a Bloom filter set, and a false positive set, wherein the certificate revocation list includes revoked certificates of the first Internet of Things device; A certificate revocation module, configured to generate the certificate revocation list and store it in the memory; A Bloom filter module, comprising Bloom filters and configured to generate a set of Bloom filters based on the certificate revocation list using the Bloom filters, wherein the set of Bloom filters is a bit array representing the certificate revocation list; A false positive module, configured to generate a false positive set based on a first potential false positive list received from a second IoT device, wherein the false positive set includes identifiers associated with certificates not in the certificate revocation list but in one or more potential false positive lists, wherein the one or more false positive lists include the first potential false positive list, and wherein the false positive set includes an identifier of a third IoT device; and The control module is configured to: The Bloom filter set and the false positive set are transmitted to the second IoT device to prevent communication with the first IoT device and to allow communication with the third IoT device; and For each entry in the first potential false positive list, check whether the entry is in the Bloom filter set and the certificate revocation list; and in response to the entry being in the Bloom filter set but not in the certificate revocation list, update the false positive set to include the entry, wherein the Bloom filter set is a bit array representing the certificate revocation list; The control module operates in the following states: The first state is used to initialize the Bloom filter set and distribute the Bloom filter set to at least the second IoT device and the third IoT device; In the second state, when the Bloom filter set exists and the false positive set is an empty set, the false positive set is updated based on the first potential false positive list, and the false positive set is distributed to at least the second IoT device and the third IoT device. In the third state, when the Bloom filter set exists and the false positive set is not empty, the false positive set is updated based on the first potential false positive list, and the false positive set is distributed to at least the second IoT device and the third IoT device; and The fourth state is used to update the Bloom filter set and the false positive set, and to distribute the updated Bloom filter set and the updated false positive set to at least the second IoT device and the third IoT device. The certificate revocation module is configured to update the certificate revocation list; and the Bloom filter module is configured to periodically update the Bloom filter set based on the updated certificate revocation list. The control module is configured to: in response to receiving a new entry in the certificate revocation list, update the Bloom filter set based on the new entry, and remove the new entry from the false positive set.

11. The backend station according to claim 10, wherein: The Bloom filter includes multiple hash functions; Each of the plurality of hash functions is configured to determine the bit position in the bit array based on an entry in the certificate revocation list; and The Bloom filter module is configured to set the bit at the bit position to 1 based on the output of the plurality of hash functions.

12. The backend station according to claim 11, wherein the Bloom filter module is configured to: The bit position in the bit array that identifies the certificate identifier of the third IoT device; and Based on the bit position identified in the bit array of the identifier, determine whether the identifier of the certificate of the third IoT device is in the Bloom filter set; and In response to the fact that the identifier of the certificate of the third IoT device is not in the Bloom filter set, communication is made with the third IoT device.

Images