Device update transmission using bloom filter

Abstract

To provide improved systems, devices, and methods for providing device updates to computerized devices.SOLUTION: A system includes a campaign management service to detect a campaign initiation request indicating the number of computerized devices to be updated for a campaign and store data corresponding to the computerized devices to be updated. The campaign management service can generate a bloom filter data structure comprising hash values based on the data for each of the computerized devices to be updated and transmit the bloom filter data structure to a network edge. The network edge uses the bloom filter data structure from the campaign management service to determine whether a computerized device is to obtain a device update from the campaign management service.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates generally to systems, apparatus and methods for securely providing device updates, and more particularly to improved systems, apparatus and methods for providing device updates to computerized devices, such as computerized devices in V2X vehicles, that are included in an update campaign. [Background technology]

[0002] As computers become smaller and more commoditized, manufacturers are producing more and more different devices that contain any number of embedded computers and processors. The computers in a computerized device can control the operation of the device, collect, store, and share data, communicate with other computers and other computerized devices, and update their own software, among other things. The Internet of Things (IoT) is a network of computerized physical devices with embedded processors, electronics, software, data, sensors, actuators, and / or network connections that allow these devices to connect and exchange data via digital networks, including the Internet, cellular networks, and other wireless networks. Typically, each "thing" is uniquely identifiable through its embedded computing system and can operate with each other within the existing Internet infrastructure. "Things" in the IoT sense can refer to a wide variety of computerized devices, such as consumer devices, enterprise devices used in business and enterprise settings, manufacturing machinery, agricultural equipment, energy consuming devices in homes and buildings (such as switches, power outlets, appliances, lighting devices, light bulbs, televisions, garage door openers, sprinkler systems, security systems, etc.), medical and healthcare devices, infrastructure management devices, robots, drones, and transportation devices and vehicles, among others.

[0003] In many instances, modern vehicles and transportation machinery (e.g., automobiles, trucks, airplanes, trains, ships, motorcycles, scooters, 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 to exchange various types of information, and they may react and respond to, modify their operation, or otherwise depend on information sent to and received from other vehicles in vehicle-to-vehicle (V2V; also known as Car-to-Car (C2C)) and / or information sent to and received from infrastructure elements in vehicle-to-infrastructure (V2I; also known as Car-to-Infrastructure (C2I)) for safe, accurate, efficient, and reliable operation. V2V and V2I systems together are commonly referred to as V2X systems or infrastructure.

[0004] The computers in the computerized devices operate according to their software and / or firmware and data. To ensure safe and proper operation, the computerized devices must be equipped with the appropriate software, firmware, executable instructions, and / or instructions. The IoT consists of devices running certified, known good software and data, which must be properly initialized and updated as intended by the manufacturer with digital assets, digital certificates (e.g., public key certificates), cryptographic keys, etc. (collectively referred to below as "digital assets" or "software"). However, problems arise when unauthorized persons or entities (e.g., hackers) replace or modify software within computerized devices. Problems also arise when older, untested, unauthorized, and / or software with known bugs is installed on computerized devices.

[0005] Conventional systems can require significant allocation of hardware and other resources to process device update requests for a "campaign" that includes a large number of devices, such as a campaign to update software for all of the V2X-enabled vehicles that are of a particular make, model, and year and / or have particular digital assets (e.g., one of a particular set of certificates), which may number in the tens or hundreds of thousands. For example, conventional systems processing device update requests for a large campaign require significant amounts of memory, processors, network bandwidth, etc. to process all of the requests, including requests from a set of devices that are part of the campaign (e.g., vehicles of a particular make, model, year, and / or certificate group) interspersed with requests from devices that are not part of the campaign (e.g., vehicles that are part of the V2X environment but are not of the campaign's particular make, model, year, and / or certificate set). A campaign as referred to herein can include device updates for a particular group of computerized devices, where device updates can include software updates, firmware updates, etc.

[0006] Some conventional systems may use linear or binary search techniques to determine whether a computerized device should receive a device update as part of a campaign, e.g., to determine whether a requesting automobile is in a particular set of makes, models, years, and / or certificates included in the campaign. However, linear and binary search techniques typically require storing large amounts of data, and searching the data typically requires a significant amount of processing time and power. Furthermore, the amount of time required to complete each such search grows with the number of devices (e.g., automobiles) in the campaign. Thus, conventional systems may result in significant delays or latencies, e.g., delays of 5 seconds or more per device / request, when determining whether a computerized device should be included in a campaign for a device update.

[0007] In some embodiments, the technology includes improved systems, devices, and methods that can verify that a computerized device belongs to a campaign or belongs to a group or set of computerized devices that are scheduled to receive device updates. In some embodiments, the technology includes a system that can determine whether a computerized device is included in a campaign to reduce hardware resources and time used to obtain device updates as part of a campaign. Summary of the Invention

[0008] Thus, the present technology includes improved systems, devices and methods that can provide updates to a computerized device. The system for providing updates to computerized devices can include a campaign management service including computer-executable instructions to cause a first processor to perform operations including detecting a campaign initiation request indicating a set of computerized devices to be updated for the campaign. The operations can also include generating a Bloom filter data structure including a plurality of hash values, where the plurality of hash values ​​correspond to the set of computerized devices to be updated. The operations can further include providing the Bloom filter data structure to a network edge. Additionally, the system can include a network edge including computer-executable instructions to cause a second processor to perform operations including determining that the computerized device receives a device update from the campaign management service based on a hash value associated with the computerized device matching a hash value of the plurality of hash values ​​of the Bloom filter data structure. The operations can also include obtaining a device update associated with the computerized device from the campaign management service in response to the campaign management service identifying the computerized device as a member of the campaign. Additionally, the operations can include providing the device update to the computerized device, whereby the device update modifies the computerized device.

[0009] In one embodiment, the network edge further includes computer-executable instructions that cause the second processor to perform operations including: using the Bloom filter data structure to determine that the computerized device does not belong to the campaign; and providing an indication to the computerized device that there are no device updates for the computerized device without communicating with the campaign management service.

[0010] In one embodiment, the computerized device is an Internet of Things (IoT) device, a consumer appliance, or a vehicle.

[0011] In one embodiment, the device update may include a registration certificate or an anonymous certificate.

[0012] In one embodiment, a device update may include software or firmware that is installed on a computerized device.

[0013] In one embodiment, a device update may include installation information or an installation script.

[0014] In one embodiment, the campaign management service further includes computer-executable instructions that cause the first processor to perform operations including storing data corresponding to the computerized device to be updated.

[0015] In one embodiment, the data may include one or more of a campaign start date, a campaign end date, a plurality of vehicle registration numbers, a plurality of product serial numbers, and a product model number.

[0016] In one embodiment, the campaign management service further includes computer-executable instructions that cause the first processor to perform operations including determining whether the computerized device is in a campaign by accessing the data.

[0017] In one embodiment, the Bloom filter data structure is a constant size regardless of the number of computerized devices in the set.

[0018] In one embodiment, generating the Bloom filter data structure may include adjusting a number of hash functions that generate hash values ​​for the Bloom filter data structure based on a false positive rate threshold.

[0019] In one embodiment, once the Bloom filter data structure is generated, the system enables a computerized device to poll a network edge for device updates.

[0020] In one embodiment, the campaign management service further includes computer-executable instructions that cause the first processor to perform operations including instructing the network edge to delete the Bloom filter data structure at the end of the campaign.

[0021] In one embodiment, each computerized device in the set of computerized devices includes a uniform resource locator for communicating with a network edge.

[0022] In one embodiment, the network edge device may include computer-executable instructions that cause a processor to perform operations including obtaining a Bloom filter data structure from a campaign management service, the Bloom filter data structure including a plurality of hash values. The operations may also include determining that the computerized device should receive a device update from the campaign management service based on a hash value associated with the computerized device matching a hash value of the Bloom filter data structure. The operations may further include sending a device update request to the campaign management service corresponding to the computerized device. Additionally, the operations may include obtaining a device update associated with the device update request from the campaign management service after the campaign management service has confirmed that the computerized device is a member of the campaign. Additionally, the operations may include providing the device update to the computerized device, thereby causing the computerized device to install the device update.

[0023] In one embodiment, the campaign management service may include computer-executable instructions to cause a processor to perform operations including detecting a campaign initiation request specifying that a plurality of computerized devices are to be updated with device updates for the campaign. The operations may also include storing data corresponding to the plurality of computerized devices to be updated and generating a Bloom filter data structure including a plurality of hash values, where each hash value is based on data for each of the computerized devices in the plurality of computerized devices. Additionally, the operations may include providing the Bloom filter data structure to a network edge and receiving a request for a device update from the computerized device. Further, the operations may include validating that the computerized device is a member of the campaign based on the data corresponding to the plurality of computerized devices to be updated. Further, the operations may include providing a device update associated with the request to the network edge, providing the device update to modify electronic data accessed or stored by the computerized device. [Brief description of the drawings]

[0024] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate numerous examples of the features of the disclosed subject matter. The accompanying drawings, together with the detailed description, illustrate various techniques described herein. It serves to explain the principle.

[0025] [Figure 1] FIG. 1 is a block diagram of an example operating environment for computerized devices, network edges, and campaign management services corresponding to example embodiments described herein. [Diagram 2]FIG. 1 is a block diagram of an example system that can initialize a Bloom filter data structure using computerized devices, network edges, and campaign management services, according to example embodiments described herein. [Figure 3A] FIG. 1 is a block diagram of an example operating environment for a computerized device, network edge, and campaign management service for processing requests for device updates, consistent with example embodiments described herein. [Figure 3B] FIG. 1 is a block diagram of an example operating environment for a computerized device, network edge, and campaign management service for processing requests for device updates, consistent with example embodiments described herein. [Figure 4] 1 is a process flow diagram of an example method for managing requests related to a campaign using a network edge, consistent with example embodiments described herein. [Diagram 5] 1 is a process flow diagram of an example method in which campaign-related requests may be managed using a campaign management service, corresponding to example embodiments described herein. [Figure 6] 1 is a data flow diagram illustrating an example data flow between a computerized device, a campaign management service, and a certificate management service, consistent with example embodiments described herein. [Figure 7] FIG. 1 is an example block diagram of a computing system capable of hosting systems and methods corresponding to example embodiments described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] Reference will now be made in detail to various embodiments of the technology described herein, examples of which are illustrated in the accompanying drawings. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

[0027] Introduction

[0028] More and more devices, sensors, and equipment include additional hardware components, such as network components, among others. The network components can enable various devices to communicate with any number of external devices, servers, and the like. In some examples, the software and firmware used to operate the devices becomes outdated or insecure. Thus, the devices can request device updates via the network components to improve device performance and prevent security issues. In some embodiments, devices are updated in groups or campaigns. A campaign can enable a manufacturer or other suitable entity to provide device updates to a set of devices. In some examples, the devices can periodically poll an external server or service to determine whether there are updates available for the devices (e.g., whether there is an active campaign that includes the devices) and / or whether the devices can obtain device updates.

[0029] In various embodiments, the device update is performed after the vehicle is manufactured and initialized. A digital asset can include updates for multiple components at once. For example, an embedded device, e.g., an electronic control unit (ECU) used in a vehicle, can be initialized during manufacturing by provisioning digital assets such as security assets to ensure safe and proper operation in the field. Digital assets can include various digital certificates, cryptographic keys, unique identifiers, and software. In some examples, a CMS or certificate management service generates these digital assets, and a secure provisioning system distributes the digital assets to the manufacturing plants.

[0030] Typically (but not always), after leaving the factory and being deployed into service, a device update can be requested by a computerized device to obtain new or replacement software, firmware, digital assets, etc., that enable the computerized device to function in a correct or revised manner. In some described embodiments, the computerized device can request a device update, and the request can be filtered using, among other things, a Bloom filter data structure. Various embodiments utilizing a Bloom filter data structure provide a determination as to whether the computerized device will receive a device update within a substantially constant amount of time that is less than the time required by conventional systems, while utilizing a reduced amount of storage as compared to conventional systems.

[0031] 1 is a block diagram of an exemplary operating environment for computerized devices, network edges, and campaign management services capable of processing requests for device updates. In some embodiments, system 100 may be implemented using any suitable computing devices, servers, external remote service networks, etc. As shown in this example, system 100 may include, among others, network edges 102, device management servers 104, devices 106, campaign management services 108, internal services 110, databases 112, Bloom filter devices 114, and message servers 116.

[0032] In some embodiments, the network edge 102 may include a device management server 104 capable of implementing campaign initialization 118 for device updates, etc. A campaign may designate or include any set, group, or number of devices (also referred to herein as computerized devices) 106 for, among other things, obtaining a device update, such as a software update, a firmware update, or a new application. In some embodiments, the device update may include installation information or an installation script associated with software, firmware, or any combination thereof, stored on the device 106. The installation information may indicate a directory or location for storing the device update in memory of the device 106. The installation script may include executable instructions for installing the device update.

[0033] In some embodiments, the device 106 may be, among other things, an Internet of Things (IoT) sensor, a consumer device, a vehicle, or a device that is part of a vehicle (e.g., an OBU, etc.). For example, the device 106 may include a vehicle, a watercraft (e.g., a boat), an aircraft, a spacecraft, a medical device, a robot, a drone, a wireless or wired communication module, or an IoT device. In some examples, the device 106 may be, among other things, a traffic control facility (e.g., a traffic signal, a traffic light, or an electronic traffic signage), a digital billboard, a pedestrian warning system, a motorcycle sensor, a bicycle sensor, an electronic sign, a street light sensor, a traffic ... The RSU can be a sensor or a structural warning sensor.

[0034] In some examples, the device management server 104 can detect 120 a campaign initiation request (not shown) from a web interface, an external server, or a device 106. In some embodiments, the device management server 104 can detect the campaign initiation request from a server or device that manages the campaign. The device management server 104 can then forward the campaign initiation request to a campaign management service 108, which can belong to an internal service 110 that can include any number of computing devices, such as servers, databases, client devices, etc. In some embodiments, the internal service 110 can detect the campaign initiation request through any suitable interface that avoids sending data related to the campaign through the device management server 104. The campaign initiation request can indicate a list or set of devices 106 that will be updated as part of a device update campaign. In some examples, the campaign initiation request can include a set of device identifiers or a set of identifying information for each device, such as a set of serial numbers, a set of product names, a set of Internet Protocol (IP) addresses, a set of Media Access Control (MAC) addresses, etc., along with a time to start the device update, a time to end the device update, and / or other information that optionally specifies the parameters of the campaign.

[0035] In some embodiments, the campaign management service 108 can determine that a campaign is to be initiated. In some examples, initiating the campaign can include storing 122 the campaign data and status in a database 112 of the internal services 110. The campaign data stored in the database 112 can include information from the campaign initiation request, such as a set of serial numbers, a set of product names, a set of Internet Protocol (IP) addresses, a set of Media Access Control (MAC) addresses, some other set of device identification information, a time to start a device update, a time to end a device update, etc. In some examples, the status of the campaign stored in the database 112 can indicate whether the campaign has started or whether the campaign is inactive until a later time. In some embodiments, the database 112 can store data locally within the campaign management service 108, or the database 112 can be an externally located database 112 that is accessed via a network connection (not shown).

[0036] In some embodiments, the campaign management service 108 initializes 124 a data structure for a campaign prior to processing a device update request for the campaign. The data structure may include a Bloom filter data structure, a linked list, a multi-dimensional array, or other data structure that may be used to quickly identify devices 106 and / or requests 134 that are included in or correspond to the campaign (e.g., devices listed in a list or set of device identifiers from a campaign initiation request). In some examples, the Bloom filter data structure is allocated as a static or fixed size structure that does not grow or shrink based on or according to the number of devices in the campaign, for example, as devices are added to the campaign. In some embodiments, the Bloom filter data structure may include an array of hash values ​​that correspond to computing devices included in the campaign. In some embodiments, each hash value may be generated using a separate hash function. For example, each Bloom filter data structure may be associated with a different hash function of X. Each different hash function of X may map a computing device to a position in the Bloom filter data structure array. Identifying information for a computerized device may be mapped or hashed. For example, to add a computing device to a Bloom filter data structure, identifying information for the computing device may be provided to each of X's different hash functions. Each of X's different hash functions generates an output value corresponding to an array location. The Bloom filter data structure array may be modified to store values ​​for each array location generated as output by X's different hash functions. In one example, identifying information for a computerized device may be provided to five hash functions, each of which generates a value for a distinct array location. The Bloom filter data structure may be modified to store a binary value or other suitable value at each array location mapped to the output of the five hash functions. Thus, after the computerized device is mapped to the Bloom filter data structure, the five array locations of the Bloom filter data structure may store a value of 1.

[0037] The number of hash functions that map hash values ​​to the Bloom filter data structure array can be based on a false positive rate threshold. For example, reducing the number of hash functions compared to the number of entries in the Bloom filter data structure array can reduce the false positive rate. In contrast, increasing the number of hash functions used to map hash values ​​to the Bloom filter data structure array can increase the false positive rate. In some examples, the campaign management service 108 can adjust the number of hash functions that generate hash values ​​for the Bloom filter data structure based on the false positive rate threshold.

[0038] In some embodiments, the campaign management service 108 can send 126 the Bloom filter data structure to the Bloom filter device 114 via the message server 116. For example, the message server 116 can enable the Bloom filter data structure to be provided 128 synchronously or asynchronously to the Bloom filter device 114. In some examples, the network edge 102 can begin launching or running the campaign 130 by storing a cached copy of the Bloom filter data structure in the Bloom filter device 114 or the device management server 104. Thus, the network edge 102 can begin processing the device update request following initialization of the Bloom filter data structure by storing the Bloom filter data structure within the network edge 102. In some embodiments, as described in more detail below with respect to FIG. 2, if the device 106 is a member of a campaign that has requested an update and has not yet finished initializing the Bloom filter data structure, the network edge 102 will respond that the requesting device 106 does not have an update available or is not part of the campaign. Thus, the device 106 can poll the network edge 102 and wait 132 for a response indicating whether the device 106 belongs to the campaign, including in some examples polling the network edge 102 for device updates when the Bloom filter data structure is generated.

[0039] 1 further illustrates an example of how the system 100 processes a device update request from a device 106 that is actually included in a campaign represented by the Bloom filter data structure, which may be referred to as a true positive. As shown in this example, after the Bloom filter data structure is initialized and the filtering process is running, the device 106 may send a device update request 134 to the network edge 102. The network edge 102 may query 136 the Bloom filter data structure (e.g., on the Bloom filter device 114) to determine whether the requesting device 106 belongs to the campaign. In some embodiments, querying 136 the Bloom filter data structure may include generating a hash value using a hash function applied to a device identifier (i.e., identification) from the device 106. The device identifier or identification may be or may include a MAC address, IP address, serial number, and the like. In various embodiments, a hash value for the identification of the device 106 that matches a hash value stored in the Bloom filter data structure may indicate that the device 106 may or likely belongs to the campaign, where the hash value stored in the Bloom filter data structure was generated from a list of device identifiers included in the campaign initiation request. In various embodiments, a match in the Bloom filter data structure does not guarantee that the requesting device 106 is part of the campaign, since the Bloom filter may generate false positives at a rate of about 10% or less, such as 8%, 6%, 5%, 4%, 3%, 2%, 1%, or less than 1% and greater than 0%. In some embodiments, the network edge 102 can determine 138 if matching hash values ​​for a device 106 are stored in the Bloom filter data structure in approximately constant time, regardless of the number of hash values ​​(which correspond to devices) in the Bloom filter data structure (which correspond to a campaign). Thus, when determining whether a device 106 belongs to a campaign, the Bloom filter data structure provides faster processing time and uses a smaller amount of memory than conventional systems, and these improvements increase as the number of devices in the campaign increases.

[0040] 1, upon searching, comparing or otherwise identifying a match, the Bloom filter device 114 can indicate 140 to the device management server 104 that the device 106 is a member of the campaign. The device management server 104 can then send 142 a device update request 134 to the campaign management service 108, for example, via the message server 116. In some examples, the message server 116 can forward 144 the device update request 134 to the campaign management service 108 asynchronously or synchronously.

[0041] In various embodiments, the campaign management service 108 may detect the device update request 144 / 134 and query 146 the database 112 to retrieve or otherwise determine whether the device 106 truly belongs to the campaign, which may not be the case if the Bloom filter data structure generates a false positive. In the example shown in FIG. 1, the database 112 may return 148 the campaign data, the status of the campaign, a list or range of devices (e.g., device identifiers), and / or other information to the campaign management service 108. The campaign management service 108 may determine 150 that the device 106 is a member of the retrieved campaign and that the device 106 will receive or be provided a device update as part of the campaign, in the example shown. In some embodiments, the campaign management server 108 may return 152 an indication to the device 106 that the device 106 is a member of the campaign via the message server 116, the Bloom filter device 114, and / or the device management server 104, or any combination thereof. In some embodiments, the campaign management service 108 returns, transmits, or otherwise provides 154 device update data to the device 106 via the network edge 102. In various embodiments, the device update data can include digital assets such as software, firmware, etc., that when executed or otherwise used, revise or update the device 106 by, for example, modifying existing functionality, adding new functionality, and removing undesirable functionality.

[0042] 1 thus represents an example of a true positive where a device 106 matches a hash value stored in a Bloom filter data structure and the device 106 confidently belongs to a campaign. In some embodiments, the system 100 may be implemented with any number of devices. For example, the network edge 102 may be implemented with a single server, the internal service 110 may be implemented with a single server, and the system 100 may not include a message server 116 such that the network edge 102 and the internal service 110 communicate directly with each other.

[0043] 2 depicts a block diagram of an example system for initializing a Bloom filter data structure. In some embodiments, the system 200 may be implemented using any suitable number of computing devices, such as the network edge 102, the device management server 104, the devices 106, and the campaign management service 108, among others.

[0044] In some embodiments, the system 200 may include a network edge 102 that may include a device management server 104 that may detect 202 a campaign initiation request (not shown) from a web interface, an external server, or a device 106. In some embodiments, the device management server 104 may detect the campaign initiation request from a server or device that manages the campaign. The device management server 104 may then forward the campaign request to a campaign management service 108 that may belong to an internal service 110. In some embodiments, the internal service 110 may detect the campaign initiation request through any suitable interface that avoids sending data related to the campaign via the device management server 104. The campaign initiation request may indicate a list of devices to be updated as part of a device update campaign. In some examples, the campaign request may include a set of serial numbers, a set of product names, a set of Internet Protocol (IP) addresses, a set of Media Access Control (MAC) addresses, a time to start the device update, a time to end the device update, etc.

[0045] In some embodiments, the campaign management service 108 may determine that a campaign is to be launched. In some examples, launching the campaign may include storing 204 campaign data and status in a database 112 of the internal services 110. The campaign data stored in the database 112 may include information from the campaign request, such as a set of serial numbers, a set of product names, a set of Internet Protocol (IP) addresses, a set of Media Access Control (MAC) addresses, a time to start a device update, a time to end a device update, and the like. In some examples, the campaign status stored in the database 112 may indicate whether the campaign has started or the next time and date to start the campaign. In some embodiments, the campaign management service 108 generates 206 a data structure for the campaign prior to processing a device update request for the campaign. The data structure may include a Bloom filter data structure, a linked list, a multi-dimensional array, or other data structure. In some embodiments, the Bloom filter data structure may include an array of hash values ​​corresponding to the computing devices included in the campaign. In some embodiments, each hash value may be generated using a separate hash function.

[0046] Figure 2 further shows how the Bloom filter data structure representing the campaign is 2 illustrates an example of how the system 200 processes a device update request received from a device 106 before the Bloom filter data structure is ready for use by the network edge 102. In the illustrated example, while the Bloom filter data structure is being generated at the campaign start time and / or before the Bloom filter data structure is retrieved and installed by the network edge 102, the device management server 104 may receive or detect 208 a device update request 134 from the device 106, which would trigger a determination as to whether the device 106 belongs to a campaign. In the illustrated example, because the campaign management service 108 is in the process of generating 206 a Bloom filter data structure for the campaign when the request 208 / 134 arrives, the device management server 104 returns a response 214 indicating that there are no updates for the device 106, or in other words, that the device 106 is not in a campaign.

[0047] In this particular example, the device management server 104 may send 210 a request for a device update 208 / 134 from the device 106 to the Bloom filter device 114. The Bloom filter device 114 may determine 212 whether the device 106 is a member of the campaign by generating a hash value based on identifying information about the device 106 (e.g., serial number, IP address, MAC address, etc.) included in the request 208 / 134. In various examples, the Bloom filter device 114 may attempt to identify a matching hash value by comparing the hash value for the device 106 to hash values ​​in a Bloom filter data structure stored at the Bloom filter device 114. In the example of FIG. 2, the Bloom filter device 114 cannot make any comparison because it does not yet have a stored Bloom filter data structure for the campaign, as a Bloom filter data structure has not yet been accepted from the campaign management service 108.

[0048] For this case in the illustrated embodiment, the Bloom filter device 114 returns 214 an exclusion response via the device management server 104 indicating that the device 106 is not in the campaign. This may occur even though the device 106 belongs to a campaign associated with a Bloom filter data structure that is simultaneously being created, constructed, or generated 206 by the campaign management service 108.

[0049] In some embodiments, the device 106 can periodically poll (e.g., send requests to) the network edge 102 for device updates. For example, the device 106 can send requests for device updates to the device management server 104 based on a predefined time interval, such as minutes, hours, days, weeks, months, years, etc. In such embodiments, one or more of the polling requests 208 can arrive at the network edge 102 while the bloom filter data structure is being generated. In some embodiments (shown), the network edge 102 can determine that the device does not belong to a campaign and return a no update or exclusion response 214 to the device 106 without communicating with the campaign management service 108.

[0050] As described above with respect to FIG. 1, following generation of the Bloom filter data structure, the campaign management service 108 may transmit 216 the Bloom filter data structure to the network edge 102, for example, via the message server 116. In some examples, the network edge 102 may store a cached copy of the Bloom filter data structure on the device management server 104 or on a separate Bloom filter device 114. In some embodiments, the network edge 102 initializes the Bloom filter data structure and transmits it to the network edge 102. After storing the Bloom filter data structure, the Bloom filter data structure can be used to begin processing device update requests 134. In various embodiments, following initialization of the Bloom filter data structure, the device management server 104 can return device updates 154 to any suitable devices 106 that belong to the campaign associated with the stored Bloom filter data structure.

[0051] 3A and 3B are block diagrams of an example operating environment for a computerized device, a network edge, and a campaign management service for processing requests for device updates. In some embodiments, the system 300 may be implemented using any suitable number of computing devices, such as a network edge 102, a device management server 104, a device 106, and a campaign management service 108, among others.

[0052] In the example shown in FIG. 3A, the Bloom filter data structure can be generated and stored as described above with respect to FIGS. 1 and 2. For example, any suitable external server, web-based interface, computing device, etc. can initialize 302 a campaign, such as for a device update, via an initialization request 304 sent to the internal service 110. In some embodiments, the campaign management service 108 can initiate the campaign by storing 306 the campaign data and status in the database 112 of the internal service 110. In some embodiments, the campaign management service 108 initializes 308 a data structure, such as a Bloom filter data structure, for the campaign prior to initiating the campaign. In some embodiments, the campaign management service 108 can send 310 the Bloom filter data structure to the Bloom filter device 114 via the message server 116.

[0053] First, FIG. 3A illustrates an example of how the system 100 processes a device update request from a device 106 that is not included in a campaign represented by a Bloom filter data structure. As shown in this example, the network edge 102 can begin implementing, activating, and executing a campaign 312 by storing a copy of the Bloom filter data structure in the Bloom filter device 114 or the device management server 104. The network edge 102 can then process a device update request related to information about the campaign, as the Bloom filter data structure representing the campaign is stored in the network edge 102. In some examples, the system 100 can wait 314 until the Bloom filter data structure representing the campaign is stored in the network edge 102 before processing the device update request. In some embodiments, the network edge 102 can support multiple concurrent campaigns related to different device updates for different devices. In some such embodiments, each campaign may be represented by a separate Bloom filter data structure, while in other embodiments, a single Bloom filter data structure generated from data from multiple campaigns may be used to represent all campaigns in a single data structure.

[0054] 3A, the device management server 104 may receive or detect 316 an update request from the device 106, as previously described. In some examples, the device management server 104 may send 318 a request for a device update from the device 106 to the Bloom filter device 114. Identification information may be included in the request 316, and the Bloom filter device 114 may generate a hash value based on or using the identification information for the device 106. and determine 320 membership of the device 106 in the campaign. In some examples, the Bloom filter device 114 may attempt to find or identify a matching hash value in the Bloom filter data structure by comparing the hash value for the device 106 to hash values ​​in the Bloom filter data structure stored in the Bloom filter device 114. Bloom filters do not generate false negatives, so the lack of a matching hash value indicates that the device 106 is not part of the campaign and / or that the device 106 does not have update data available. In the example shown, the hashed identification information for the device 106 is not in the Bloom filter data structure, so the Bloom filter device 114 returns a response 322 via the device management server 104 indicating that the device 106 is not currently in a campaign or that the device 106 does not have updates available.

[0055] FIG. 3B further illustrates an example of how the system 100 processes a device update request 324 from a device 106 that is not truly included in the campaign, but appears to be due to the representation of the Bloom filter data structure, which may be referred to as a false positive. As previously discussed, in various embodiments, the Bloom filter data structure may generate false positives at a rate of about 10% or less, such as at a rate of about 5%. As shown in this example, the device management server 104 receives or detects a request 324 from a device 106 for an update, which may trigger a determination as to whether the device 106 belongs to a campaign. In this example, the request 324 may come from or correspond to a different device 106 than the device that issued the request 316 and is not included in the campaign from the previous example.

[0056] In some examples, the device management server 104 can send 326 a request for a device update 324 from the device 106 to the Bloom filter device 114. The Bloom filter device 114 can generate a hash value based on an identification of the request for the device 106 and determine 328 that the requesting device 106 is a member of the campaign by finding a hash value in the Bloom filter data structure that is the same as the generated hash value. Upon finding the same hash value in the Bloom filter data structure, the Bloom filter device 114 returns 330 a response to the device management server 104 indicating that the device 106 is likely in the campaign (because the hash value identified in the Bloom filter data structure matched the generated hash value corresponding to the device 106).

[0057] In some embodiments, the device management server 104 can send 332 a request for a device update for the device 106 to the campaign management service 108 via the message server 116. In some examples, the campaign management service 108 can query 334 the database 112 to search for or otherwise determine whether the device is a member of a campaign, which may not be the case if the Bloom filter data structure generated a false positive. After the database 112 returns 336 the data and status information for the campaign to the campaign management service 108, in this particular example, the campaign management service 108 determines 338 that the requesting device 106 does not belong to the campaign. In some examples, the campaign management service 108 can return 340 a response indicating that the device 106 does not belong to the campaign via the message server 116, the Bloom filter device 114, and / or the device management server 104, or any combination thereof.

[0058] In this example from FIG. 3B, the network edge 102 is not aware that the device 106 is actually In some cases, the Bloom filter unit 114 generates a false positive indicating that the device 106 is part of the campaign and will receive a device update, even though the device 106 is not part of the campaign. This occurs when a hash value generated from the identity of the requesting device 106 happens to match a hash value of a different device that is actually part of the campaign represented by the Bloom filter data structure. As explained above, this false positive error is eventually detected when the campaign management service 108 accesses the data and status information for the campaign to verify that the requesting device 106 is actually a member of the campaign. Nonetheless, because various embodiments of the Bloom filter unit 114 never return a false negative membership response to a device 106 that is not part of the campaign, the overall performance of the Bloom filter unit 114 significantly reduces the number of device update requests (especially the number of requests that are not members of the campaign) that are sent to and processed by the campaign management service 108, thereby reducing the latency experienced by the requesting device 106 and reducing end-to-end resource usage and processing time.

[0059] 4 is a process flow diagram for an example method that may manage requests related to a campaign using a network edge. In some embodiments, the method 400 may be implemented using any suitable number of computing devices, such as the network edge 102, the device management server 104, the bloom filter device 114, the network edge 602, the campaign service 608, or any combination thereof.

[0060] As shown in this example, in block 402, a network edge can detect a request to initiate a campaign for a device update. In some embodiments, any suitable server, web-based interface, device, or computerized device can initiate the campaign by providing a list or set of computerized devices that are in or belong to the campaign, along with data such as a campaign start date and a campaign end date, where the computerized devices in the list or set are each identified by a unique identifier such as a vehicle registration number, a product serial number, a product model number, etc. In some embodiments, a uniform resource locator for the network edge is stored in a protected memory of each computerized device (e.g., computerized device 106) that requests a device update. The uniform resource locator enables the computerized device to securely contact a given authenticated network edge.

[0061] In block 404, the network edge may send the request to a campaign management service (e.g., campaign management service 108). In some embodiments, the network edge may send the request to the campaign management service via a messenger device or service (e.g., message service 116). The messenger device may support asynchronous or synchronous communication. For example, the messenger device may store any number of requests and send those requests to the campaign management service at some later time. In some embodiments, the messenger device may send requests for any number of campaigns from one or more network edges to one or more campaign management services.

[0062] In block 406, the network edge may accept, retrieve, obtain, or otherwise access a Bloom filter data structure corresponding to the requested campaign from the campaign management service. Following processing of a request to initialize a campaign by the campaign management service, the network edge may accept or obtain a Bloom filter data structure generated by the campaign management service. In some embodiments, the Bloom filter data structure may be stored in the network edge in a device management server that communicates with the computerized device. In some examples, the Bloom filter data structure may be stored in the network edge in a separate device (e.g., Bloom filter device 114) that has access to the device management server.

[0063] During operation, the device management server may receive or detect a request from a computerized device attempting to determine whether a device update for a campaign is available for the requesting device. The device management server may query a locally stored Bloom filter data structure or a separate Bloom filter device and determine either that the computerized device is not a member of the campaign or that the computerized device may be a member of the campaign with a low probability tending to be expected as a false positive.

[0064] In block 408, the network edge can determine that the computerized device likely has a device update available from the campaign management service based on a hash value associated with the computerized device matching a hash value stored in the Bloom filter data structure, where the stored hash value was identified by querying the Bloom filter data structure, as mentioned above. On the other hand, if the requesting computerized device is not part of the campaign or does not have any updates available for it, then the network edge can return a negative response to the computerized device. This occurs if the hash value associated with the computerized device does not match any of the hash values ​​stored in the Bloom filter data structure.

[0065] In some embodiments, the network edge may generate any number of hash values ​​from the identification information for the computerized device and compare the hash values ​​to the values ​​stored in the Bloom filter data structure. For example, the Bloom filter data structure may store five or more hash values ​​based on the output from the identification information for the computerized device applied to five or more separate hash functions. In some embodiments, any number of hash functions may be used to generate the hash values ​​stored in the Bloom filter data structure.

[0066] At block 410, the network edge may send a device update request corresponding to the computerized device to the campaign management service. In some embodiments, the network edge may forward the device update request to the campaign management service in response to detecting one or more hash values ​​corresponding to identifying information for the requesting device matching hash values ​​in the Bloom filter data structure. In some examples, sending the device update request to the campaign management service enables validation that the computerized device belongs to a campaign as opposed to a false positive.

[0067] In block 412, if the campaign management service verifies, confirms, or determines that the computerized device is in fact a member of the campaign, the network edge may receive, obtain, or otherwise acquire device updates associated with the requesting computerized device from the campaign management service. In some embodiments, the campaign management service may verify that the computerized device is a member of the campaign by providing a corresponding The network edge may verify the device update based on stored data stored in the campaign management service. For example, the data may include a list of identities for computerized devices that may receive device updates as part of the campaign (i.e., a list of identifiers corresponding to computerized devices included in the campaign), and the campaign management service may determine that the requesting device is on the list. In some embodiments, the network edge may receive or obtain device updates from the campaign management service directly or via a messenger device or other suitable computing device.

[0068] In block 414, the network edge may update, revise, provision, or modify the computerized device by sending the device update received from the campaign management service to the computerized device. In some embodiments, the device update may modify software, firmware, etc. stored within the computerized device. The network edge may send or otherwise provide the device update to the computerized device, and when it is received, the computerized device may automatically install the device update. In some examples, the device update may modify the computerized device by installing new applications, modifying existing applications, updating firmware drivers that control hardware components, etc.

[0069] The process flow diagram of FIG. 4 is not intended to indicate that the operations of method 400 are to be performed in any particular order, or that the operations may not be performed simultaneously, or that the operations of method 400 are to be included in all instances. Additionally, method 400 may include any suitable number of additional operations. For example, method 400 may also include a computerized device and a campaign management service exchanging mutual transport layer security credentials prior to obtaining a device update. In some embodiments, the network edge may not detect a request to initialize a campaign and send the request to the campaign management service. For example, an external server, web-based interface, or the like may initiate a campaign by sending data for the campaign directly to the campaign management service without accessing the network edge.

[0070] 5 is a process flow diagram for an example method in which a campaign management service may be used to manage requests related to a campaign. In some embodiments, the method 500 may be implemented using any suitable number of computing devices, such as the campaign management service 108, the database 112, the internal services 110, the campaign service 608, or any combination thereof.

[0071] In block 502, the campaign management service may receive or detect a campaign initiation request indicating a number of computerized devices to be updated for a campaign. In some embodiments, the campaign management service may detect the campaign initiation request from a network edge or from a messenger device that provides asynchronous or synchronous messages from a network edge. In some embodiments, the campaign management service may detect the campaign initiation request directly from a web-based interface, a device that manages the campaign, etc. As described above, campaign initiation may include, but is not limited to, a number of computerized devices that are updated for a campaign. The request may include an identification of each device that is to receive device updates as part of the campaign, a start date or time of the campaign, and an end date or time of the campaign.

[0072] At block 504, the campaign management service may store data corresponding to the computerized device to be updated. In some embodiments, the campaign management service may store data corresponding to the computerized device to be updated locally or in an external database. In some embodiments, the campaign management service may analyze, search, or query the data to determine if the computerized device belongs to a campaign. For example, if the campaign management service later detects a request for a device update from a computerized device having a unique identifier, the campaign management service may analyze, search, or query the data to determine if the device (e.g., unique identifier) ​​is included in the campaign and the device update may be provided to the computerized device.

[0073] In block 506, the campaign management service may generate a Bloom filter data structure representing the computerized devices that are included in the campaign and thus to be provided with the campaign's device updates. In various embodiments, the Bloom filter data structure includes multiple hash values ​​where a hash value is generated from a unique identifier (or other identifying information) for each of the computerized devices that are part of the campaign. In some examples, the Bloom filter data structure may include a hash value based on data or identifying information for each of the computerized devices to be updated.

[0074] In some embodiments, the Bloom filter data structure may include any number of hash values ​​based on the identity information for each computerized device to be updated. For example, the Bloom filter data structure may include an array, linked list, vector, etc., that may store any number of hash values. In some embodiments, the identity information for each computerized device is applied to any number of hash functions, each of which generates an output bit or series of bits that are stored in the Bloom filter data structure. In some embodiments, the campaign management service may generate a Bloom filter data structure based on a combining operation applied to multiple groups of computerized devices to be included in the campaign.

[0075] In block 508, the campaign management service may transmit or otherwise provide the Bloom filter data structure to the network edge, for example after initialization of the Bloom filter data structure. In some embodiments, the campaign management service may transmit the Bloom filter data structure to the network edge via an asynchronous messenger device (e.g., message server 116). For example, the asynchronous messenger device may accept the Bloom filter data structure and then delay transmitting the Bloom filter data structure to the network edge until a later time or date, which may improve communication over network interfaces having high latency and / or low bandwidth limitations.

[0076] In block 510, the campaign management service may receive a request for a device update from a computerized device. In this embodiment, the campaign management service may receive a request for a device update only after the network edge determines that the computerized device corresponding to the request likely (barring false positives) belongs to the campaign based on the Bloom filter data structure provided by the campaign management service to the network edge in block 508. In some such embodiments, the network edge forwards the request for a device update to the campaign management service only if a hash value generated or derived from identifying information for the requesting computerized device matches a hash value stored in the Bloom filter data structure. As described above, if a hash value generated or derived from identifying information for the requesting computerized device does not match any hash value stored in the Bloom filter data structure, then the network edge does not contact the campaign management service and instead provides an accurate "no update" response to computerized devices that request device updates but are not included in the campaign.

[0077] In block 512, the campaign management service may verify, validate, or otherwise determine that the computerized device is a member of the campaign. In some embodiments, to determine whether the campaign data indicates that the computerized device is part of a campaign, the campaign management service may compare an identification of the computerized device that requested the device update to data stored for the campaign (e.g., locally or in a database). In various embodiments, the identification of the computerized device is included in the request. As a more detailed example, the campaign management service may look up a unique identifier for the computerized device, such as a device serial number, in a list of unique identifiers (e.g., serial numbers) that are part of the campaign data, where the list of unique identifiers in the campaign data includes all of the devices that are part of the campaign.

[0078] In block 514, after determining that the computerized device is indeed a member of the campaign, the campaign management service may transmit a device update associated with the device update request (and the campaign) to the network edge. In some examples, the device update may be code, instructions, binaries, etc. that add to, replace, and / or modify firmware, software, or any combination thereof stored on the computerized device.

[0079] If the campaign management service does not confirm, verify, or otherwise determine in block 512 that the computerized device is a member of the campaign, then the campaign management service does not perform the action of block 514. In various embodiments, the campaign management service may determine that the computerized device is not a member of the campaign because the computerized device (e.g., an identity of the computerized device) is not listed, identified, or otherwise represented in the campaign data.

[0080] In some embodiments, if the campaign management service does not confirm, verify, or otherwise determine in block 512 that the computerized device is a member of the campaign, then the campaign management service in block 516 sends or otherwise provides or indicates, such as a message to the network edge indicating that the requesting device is not part of the campaign and / or that there are no updates for the requesting device.

[0081] 5 is not intended to imply that the operations of method 500 are to be performed in any particular order, or that the operations may not be performed simultaneously, or that the operations of method 500 are to be included in all cases. Additionally, method 500 may include any suitable number of additional operations. For example, when a campaign ends (e.g., when an end date for a campaign occurs), the campaign management service may instruct the network edge to delete the Bloom filter data structure by sending a message to the network edge to flush caches or memory elements that store the Bloom filter data structure, which may be triggered in response to the end of the campaign.

[0082] FIG. 6 depicts an exemplary operating environment 600 in which a network edge 602 interacts with a certificate management service 604, which is an example of a service type for providing digital assets. In some embodiments, the certificate management service 604 can be a V2X certificate management service. In additional or alternative embodiments, the certificate management service 604 can be a C2X certificate management service and can be implemented as a server(s), such as one or more virtual machines on one or more computing devices. As shown, the network edge 602 can submit requests for device updates, such as certificates, for one or more computerized devices 606 to the certificate management service 604 via a campaign service 608 and a network 610, such as the Internet. In some embodiments, the device updates can enable execution of applications on the computerized devices 606 in a secure environment. For example, the device updates can include certificates that enable the computerized devices 606 to securely transmit communications with additional computerized devices in a runtime environment.

[0083] In some embodiments, the computerized device 606 may correspond to one or more of a vehicle, a watercraft (e.g., a boat), an aircraft, a spacecraft, a medical device, a robot, a drone, a wireless or wired communication module, and an IoT device. For example, the computerized device 606 may correspond to an OBU or an ECU of a vehicle, a watercraft, an aircraft, a spacecraft, a robot, a drone, a medical device, or an IoT device. Also for example, the computerized device 606 may correspond to an RSU of a traffic control facility (e.g., a traffic light, a traffic light, or an electronic traffic light), a digital billboard, a pedestrian warning system, a motorcycle sensor, a bicycle sensor, an electronic sign, a street light sensor, or a structure warning sensor, among others.

[0084] In some embodiments, the network edge 602 can use the Bloom filter data structure as described above to determine whether the computerized device 606 receives a device update from the certificate management service 604. In some examples, the device update can include an enrollment certificate, an anonymous certificate, firmware, and software, etc. The enrollment certificate can include any suitable digital certificate that allows the computerized device 606 to provision a device update, such as a software update, a firmware update, or any combination thereof, to the computerized device 606. The anonymous certificate can include a separate digital certificate that allows the computerized device 606 to securely exchange data or communications during a runtime environment. In some embodiments, the network edge 602 can send a response to a computerized device 606 that is not included in a device update campaign. For example, a hash value based on the identity of the computerized device 606 may not match a hash value stored in a Bloom filter data structure associated with the device update campaign. In some examples, the network edge 602 can send a response to a computerized device 606 that is not included in a device update campaign. The network edge 602 may determine that one or more of the devices 606 are to be included in a device update campaign. The network edge 602 may send a request for the device update via the campaign service 608 to a registration authority 612, a registration authentication authority 614, an anonymous authentication authority 616, or any combination thereof.

[0085] In the operating environment 600, a request for a device update or certificate is received from the network edge 602 by the campaign service 608 via any suitable interface. For example, the campaign service 608 can implement an API based on the client representational state transfer (REST) ​​protocol or the simple object access protocol (SOAP) protocol, among others. As shown in FIG. 6, the campaign service 608 can implement a public or private API, and the certificate management service 604 can be a V2X or C2X certificate management service. The certificate management service 604 accepts the request for the device update, completes the task within a time frame, and then returns the result (e.g., a generated device update or certificate) to the network edge 602 via the campaign service 608 and the network 610. In some embodiments, the time frame can be minutes, hours, or days, depending on the processing capacity of the certificate management service 604, among others.

[0086] The certificate management service 604 includes components for generating requested device updates. In the example of FIG. 6, these components include a registration authority 612, a registration certification authority 614, an anonymous certification authority 616, a first linkage authority 618, and a second linkage authority 620.

[0087] In additional or alternative embodiments, the components of the certificate management service 604 may vary depending on whether the certificate management service 604 is configured as a V2X or C2X certificate management service. For example, when the certificate management service 604 functions as a C2X certificate management service, the certificate management service 604 may include a Long Term Certification Authority (LTCA) configured to perform a role similar to that of the Registration Certification Authority 614. Similarly, when the certificate management service 604 is embodied as a C2X certificate management service, the certificate management service 604 may include an Attestation Authority (AA) that performs a role similar to that of the Anonymous Certification Authority 616. The components of the certificate management service 604 are described in the following paragraphs.

[0088] In one example, the certificate management service 604 may be embodied as a CMS. Various embodiments of the certificate management service 604 may be used for very high volume device transactions and certificate generation processing. In various embodiments, the certificate management service 604 may be implemented using multiple servers, multiple hardware security modules (HSMs), multiple computing or computation engines, and multiple application platforms. In an exemplary embodiment, each application platform may include one or more virtual machines (VMs) for hosting the registration authority 612, the registration authority 614, the anonymous certificate authority 616, and the linkage authorities 618, 620. In additional or alternative embodiments, each application platform may include one or more hardware platforms, such as application servers, computers, or other computer hardware, capable of hosting and executing software applications. In the example of FIG. 6, the application platform for the registration authority 614 may be one or more VMs running the application for the registration authority 614. , the application platform for the anonymous certificate authority 616 can be one or more VMs operable to host and run an application for the anonymous certificate authority 616. Similarly, the application platform for the first linkage authority 618 can be one or more VMs configured to host and run a first linkage authority application, and the application platform for the second linkage authority 620 can be one or more VMs operable to host and run a second linkage authority application. Non-limiting examples of the certificate management service 604 can be implemented in a private data center, a cloud data center such as, for example, Amazon Web Services (AWS) from Amazon, or a hybrid of a private data center and a cloud data center.

[0089] In some embodiments, the certificate management service 604 can provide device updates including security certificates, such as registration certificates and anonymous certificates, for use by a manufacturer's dispensing equipment or the network edge 602. In some embodiments, the certificate management service 604 can interact with a digital asset management system (DAMS (not shown)) to provide certificates to the dispensing equipment (not shown).

[0090] As shown in FIG. 6, the architecture of the certificate management service 604 includes a registration authority 612, a registration authentication authority 614, an anonymous authentication authority 616, a first linkage authority 618, and a second linkage authority 620. Each of these components may utilize a dedicated computation engine (not shown) to perform tasks. For example, the registration authority 612 may utilize a registration authority computation engine, the registration authentication authority 614 may utilize a registration authentication authority computation engine, the anonymous authentication authority 616 may utilize an anonymous authentication authority computation engine, the first linkage authority 618 may utilize a first linkage authority computation engine, and the second linkage authority 620 may utilize a second linkage authority computation engine. The functionality of each of these components is described in the following paragraphs.

[0091] In some embodiments, the architecture of the certificate management service 604 advantageously separates non-security related applications from security functions. As shown in the example of FIG. 6, the registration authority 612, the registration authentication authority 614, the anonymous authentication authority 616, and the linkage authorities 618, 620 are implemented as applications on their own VMs running on their own dedicated compute engines, all of which are separate from any non-security related applications and functions. This provides both technical and security advantages and improvements over traditional systems where the HSMs are slow to perform, the cloud service provider is unable to provide the HSMs, or proper management of the HSMs is uncertain. In the certificate management service 604, cryptographic operations that utilize the HSMs are performed in the compute engine (e.g., one or more compute engines).

[0092] By isolating critical security functions from one another and placing them on separate computational engines, computationally intensive cryptographic and security functions (e.g., elliptic curve butterfly expansion calculations or elliptic curve digital signatures), as performed by, for example, the registration authority 612, the registration certification authority 614, the anonymous certification authority 616, and the linkage authorities 618, 620, as shown in FIG. 6, are performed significantly faster than in existing conventional registration authority systems. In connection with the campaign service 608 described below, this design allows for significant improvements in transaction processing in a multi-client environment by preventing any technical performance issues associated with the network 610 from preventing or delaying the provisioning of the computerized device 606 with digital assets obtained from the certificate management system 604. For example, the campaign service 608 may be configured to process a large number of transactions from any computerized device 606, as shown in FIG. The campaign service 608 may determine whether the computerized device 606 belongs to a device update campaign and is sending a request for a device update. Thus, the campaign service 608 may determine whether the computerized device 606 belongs to a device update campaign, and if so, provide the computerized device 606 with the obtained device updates, such as a registration certificate and an anonymous certificate, during or after the provisioning process. In some examples, while provisioning the computerized device 606, the campaign service 608 may avoid bandwidth issues, network connectivity issues, and the like. For example, the campaign service 608 may prevent many computerized devices 606 from querying the registration authority 612 for device updates. The campaign service 608 may also process requests for device updates faster with less data storage by storing hash values ​​in a Bloom filter data structure, where the hash values ​​may be based on identification information from the computerized devices 606 that belong to the campaign. Moreover, the campaign service 608, in some examples, can synchronously or asynchronously obtain the registration certificates and anonymous certificates from the CMS 604 and can synchronously or asynchronously provide the registration certificates and anonymous certificates to the computerized devices 606. In some examples, the asynchronous obtaining and distribution of the registration certificates and anonymous certificates can reduce the time of the provisioning process for each computerized device. Thus, embodiments consistent with the present disclosure provide a particular technically advantageous system architecture for determining which computerized devices 606 will receive device updates as part of a campaign and which will receive device updates such as digital assets from the certificate management system 604.

[0093] In some embodiments, if the scale of the registration authority application executed by the registration authority 612 is modified, additional VMs can be added while no changes are required to the secure computation capabilities of the registration authority computation engine. Instead, additional secure, registration authority computation engines can be added if security computations are performance limiting. This same multi-dimensional scaling is true for the other components of the certificate management service 604. These capabilities provide significant performance improvements and scalability over existing traditional certificate management services (CMS). In some embodiments, each application platform for the registration authority 612, registration authentication authority 614, anonymous authentication authority 616, and linkage authorities 618, 620 are communicatively coupled to the computation engine via a respective set of input message queues such that all of these components of the certificate management service 604 can be scaled independently of each other.

[0094] As discussed above and shown in the non-limiting example of Figure 6, each of the registration authority 612, the authentication authorities 614, 616, and the linkage authorities 618, 620 may be implemented as an application on its own virtual machine (VM). In additional or alternative embodiments, one or more of the registration authority 612, the authentication authorities 614, 616, and the linkage authorities 618, 620 may run on a hardware platform (e.g., a server or a computing engine). The roles and functions of each of these applications running on an application platform (e.g., a VM or a hardware platform) are described in the following paragraphs.

[0095] In various embodiments, the registration authority 612 can be an authority within a provisioning network that validates user requests for digital certificates, or other types of digital security assets, and can enable certificate authorities (e.g., the registration certificate authority 614 and the anonymous certificate authority 616) to issue digital certificates. 2 may implement any suitable public key infrastructure (PKI) technology. In various embodiments, the campaign service 608 may pass the certificate request to a registration authority 612, which may be implemented as a representational state transfer (REST) ​​web service or a SOAP-based service, among others. In various embodiments, there may be multiple instances of the registration authority 612 running simultaneously. This is similarly represented for the other components of the certificate management service 604 shown in FIG. 6. The registration authority function of the certificate management service 604 is not centralized in that its function may be performed by multiple instances of the registration authority 612 implemented as a REST web service. One role for the registration authority 612 is to grant and fulfill certificate provisioning requests while preventing the signing anonymous certificate authority 616 from determining which certificates are stored on a particular computerized device. The registration authority 612 may interact directly with the anonymous certificate authority 616 and the linkage authorities 618, 620 via message queues to fulfill their roles within the certificate management service 604.

[0096] In some embodiments, the registration authority 612 (and other components of FIG. 6) can be connected to a database (not shown). The certificate management service 604 can utilize a collection of data stores or databases for data storage and retrieval. For example, the database used can consist of one or more logical or physical database units, each unit having one or more tables that allow data separation, if necessary. As used herein, the term "database" refers to one or more databases or data stores. In some embodiments, the use of multiple databases allows data separation between the registration authority 612 and other components of FIG. 6. For example, such use of multiple databases allows data separation between the registration authority 612, the certification authorities 614, 616, and the linkage authorities 618, 620.

[0097] In some embodiments, the database used by the certificate management service 604 is a collection of one or more databases with fast access and low latency. In some embodiments, the database can be a NoSQL database or a database service, such as the DynamoDB data service offered by Amazon Web Services. In various embodiments, the data stored in the database depends on the application, but can include previously issued certificates, various linkage authority values, data on the device where the certificate was issued, operator actions, etc. In some examples, the data can be stored either unencrypted, encrypted, or a combination thereof.

[0098] In various embodiments, the certificate management service 604 includes a registration authority 614 and an anonymous certificate authority 616 such that digital certificates created by the registration authority 612 are split into different segments, e.g., registration digital certificates and anonymous digital certificates. The registration authority 614 is a non-centralized component of the certificate management service 604 because there can be multiple instances of the registration authority 614 running simultaneously. For example, in some embodiments, there can be multiple instances of the registration authority 614 running simultaneously. The registration authority 614 can receive requests for registration certificates from the registration authority 612. One role of the registration authority 614 is to fulfill requests from the registration authority 612 and issue registration certificates to terminal devices, e.g., dispensing devices. In some embodiments, the registration authority 614 interacts directly with the registration authority 612 to fulfill its role within the CMS 604.

[0099] The Anonymous Authentication Authority 616 is configured to allow multiple instances of the Anonymous Authentication Authority 616 to run simultaneously. Anonymous Authentication Authority 616 is a decentralized component of the CMS in that there may be multiple instances of Anonymous Authentication Authority 616 running simultaneously in parallel. Anonymous Authentication Authority 616 may receive requests for anonymous certificates from Registration Authority 612. The role of Anonymous Authentication Authority 616 is to fulfill requests from Registration Authority 612 and issue anonymous certificates to end devices such as computerized device 606. In some embodiments, Anonymous Authentication Authority 616 fulfills requests for short-term anonymous certificates for V2V functionality. In some embodiments, Anonymous Authentication Authority 616 interacts directly with Registration Authority 612 to fulfill its functions within CMS 604.

[0100] In various embodiments, the linkage authorities 618 and 620 shown in FIG. 6 link the identity of the certificate requester (i.e., a unique identifier of the certificate requester device) to the issued anonymous certificate for revocation purposes. That is, the first linkage authority 618 and the second linkage authority 620 provide the issued anonymous certificate with a respective linkage value as a unique identifier of the certificate requester device. The first linkage authority 618 and the second linkage authority 620 can receive requests for linkage values ​​from the registration authority 612 and can provide the requested linkage values ​​to the registration authority 612. The linkage authorities 618, 620 interact directly with the registration authority 612 to fulfill requests for linkage values.

[0101] In various embodiments, the computation engines of CSM 604 can include an HSM, allowing these components to perform secure computations without being overly threatened by hackers. In some embodiments, the computation engines can be designed to perform secure computations themselves without requiring an embedded HSM, and in such embodiments, they do embody an HSM.

[0102] In various embodiments, different HSM versions may be used in CMS 604. For example, the HSM may include an embedded HSM installed as a plug-in card within one or more compute engines. In such an example embodiment, the embedded HSM may be installed as a Peripheral Component Interconnect (PCI) HSM or PCI Express (PCIe) HSM within one or more compute engines. Also, for example, the HSM within certificate management service 604 may include an external, network-attached, or network-connected HSM that is separate from the compute engines within its own enclosure.

[0103] One of ordinary skill in the art will recognize that the components and embodiment details shown in Figure 6 are examples presented for simplicity and clarity of description, and that this example is not intended to be limiting, and many variations are possible, and other components, processes, embodiment details and variations can be used without departing from the principles of the technology described herein.

[0104] FIG. 7 is an exemplary block diagram of a computing environment 700, including a computing system 702 that may be used to implement systems and methods corresponding to the implementation of the present technology. Other components and / or arrangements may be used. In some embodiments, the computing system 702 may be used, at least in part, to implement various components of FIGS. 1-6, such as the network edge 102, the campaign management service 108, the network edge 602, or the campaign service 608, among others. In some embodiments, a set of computing systems similar to the computing system 700 may be used to implement various components of the network edge 102, the campaign management service 108, the network edge 602, or the campaign service 608, among others. Each can be customized with specialized hardware and / or programmed as a specialized server to implement one of the components of Figures 1-6 that can communicate with each other via network 704.

[0105] In the example shown in FIG. 7, a computing system 700 includes a number of components, such as a central processing unit (CPU) 706, memory 708, input / output (I / O) devices 710, a hardware security module (HSM) 712, and non-volatile storage 714. The system 700 can be implemented in a variety of ways. For example, an embodiment as an integrated platform (such as a server, workstation, personal computer, laptop, etc.) can include a CPU 706, memory 708, non-volatile storage 714, and I / O devices 710. In such a configuration, the components 706, 708, 714, and 710 can connect and communicate through a local data bus or access a data repository 716 (e.g., implemented as a separate database system) via an external I / O connection. The I / O component 710 can connect to external devices through a direct communications link (e.g., a hardwired connection or a local Wi-Fi connection), through a network such as a local area network (LAN) or a wide area network (WAN such as a cellular network or the Internet), and / or other suitable connection. System 700 can be stand-alone or can be a subsystem of a larger system.

[0106] The CPU 706 may be one or more known processors or control computing devices, such as a microprocessor from the Core family manufactured by Intel Corporation of Santa Clara, Calif., or a microprocessor from the Athlon family manufactured by AMD Corporation of Sunnyvale, Calif. The memory 708 may be one or more fast storage devices configured to store instructions and information executed or used by the CPU 706 to perform certain functions, methods, and processes related to embodiments of the present technology. The storage device 714 may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, or other type of storage device, or a computer-readable medium intended for long-term storage, including devices such as CDs and DVDs, as well as solid-state devices.

[0107] In the illustrated embodiment, memory 708 includes one or more programs or applications 718 loaded from storage 714 or from a remote system (not shown) that, when executed by CPU 706, perform various operations, procedures, processes or methods corresponding to the present technology. Alternatively, CPU 706 can execute one or more programs located remotely from system 700. For example, system 700 can access one or more remote programs via network 704 that, when executed, perform functions and processes related to embodiments of the present technology.

[0108] In one embodiment, the memory 708 can include programs 718 for performing specialized functions and operations described herein for the network edge 102 and / or for the campaign management server 108. In some embodiments, the memory 708 can include other programs or applications implementing other methods and processes that provide ancillary functionality to the techniques. In some examples, the memory 708 can include any suitable non-transitory computer-readable medium. For example, the non-transitory computer-readable medium can include computer-executable instructions that instruct the CPU 706 to execute instructions in accordance with the techniques described herein.

[0109] Memory 708 may also be configured with other programs (not shown) unrelated to the present technology and / or with an operating system (not shown) that performs a number of functions well known in the art when executed by CPU 706. Illustratively, the operating system may be Microsoft Windows, Unix, Linux, Apple Computer, or other operating systems. The choice of operating system and even the use of the operating system are not critical to the present technology.

[0110] The HSM 712 may be a device that includes a processor that securely generates and stores digital security assets and / or securely performs various cryptographic and sensitive calculations. The HSM 712 protects digital security assets and other sensitive data, such as cryptographic keys, from viable access by an attacker. In some embodiments, the HSM may be a plug-in card or board that installs directly into the computing system 700.

[0111] The I / O devices 710 may include one or more input / output devices that allow data to be received and / or transmitted by the system 700. For example, the I / O devices 710 may include one or more input devices, such as a keyboard, touch screen, mouse, etc., that allow data to be input from a user. Additionally, the I / O devices 710 may include one or more output devices, such as a display screen, CRT monitor, LCD monitor, plasma display, printer, speaker device, etc., that allow data to be output or presented to a user. The I / O devices 710 may also include one or more digital and / or analog communication input / output devices that allow the computing system 700 to communicate, e.g., digitally, with other equipment and devices. The I / O devices 710 may incorporate other configurations and / or numbers of input and / or output devices.

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

[0113] In the exemplary embodiment shown in FIG. 7, the data repository or data source 716 is a stand-alone database external to the system 700. In other embodiments, the data source 716 can be hosted by the system 700. In various embodiments, the data source 716 can manage and store data used to implement systems and methods corresponding to the present technology. For example, the data source 716 can manage and store, for example, a data structure including identifying information or data about each computerized device of a campaign. The data source 716 can also manage and store a Bloom filter data structure including hash values ​​based on the identifying information applied to any number of hash functions.

[0114] In some embodiments, data source 716 may include one or more databases that store information and are accessed and / or managed through system 700. Illustratively, database 716 may be an Oracle® database, a Sybase® database, or other relational database. However, systems and methods consistent with the present technology are not limited to separate data structures or databases, or even to the use of databases or data structures.

[0115] One of ordinary skill in the art will recognize that the system components and implementation details in Figure 7 are examples presented for brevity and clarity of explanation, and other components and implementation details may be used.

[0116] Although the above-mentioned examples use specific examples of computerized devices such as OBUs, ECUs, and RSUs for clarity of explanation, the present technology is not limited to those specific examples. Various embodiments corresponding to the present technology can be used in, among others, medical devices (e.g., dialysis machines, infusion pumps, etc.), robots, drones, autonomous vehicles, and wireless communication modules (e.g., embedded Universal Integrated Circuits, The present invention can be used with and for a wide variety of computerized devices, such as eUICC Cards (eUICC).

[0117] Other embodiments of the present technology will be apparent to those skilled in the art from consideration of the specification and practice of the technology disclosed herein. Other embodiments of the subject matter that are apparent to those skilled in the art and pertain to the disclosed subject matter, as well as various modifications of the exemplary embodiments, are intended to be within the scope of the disclosed subject matter.

Claims

1. 1. A system for providing updates to a computerized device, comprising: detecting a campaign initiation request indicating a set of computerized devices to be updated for the campaign; generating a Bloom filter data structure including a plurality of hash values ​​corresponding to the set of computerized devices to be updated; providing the Bloom filter data structure to a network edge; a campaign management service including computer executable instructions to cause a first processor to perform operations including: determining that the computerized device should receive a device update from the campaign management service based on a hash value associated with the computerized device matching a hash value of the plurality of hash values ​​of the Bloom filter data structure; responsive to the campaign management service identifying the computerized device as a member of the campaign, obtaining the device update associated with the computerized device from the campaign management service; providing the device update to the computerized device, whereby the device update modifies the computerized device; a network edge including computer executable instructions to cause a second processor to perform operations including: A system comprising:

2. The network edge includes: determining that the computerized device does not belong to the campaign using the Bloom filter data structure; providing an indication of a lack of device updates for the computerized device to the computerized device without communicating with the campaign management service; The system of claim 1 , further comprising computer-executable instructions that cause the second processor to perform operations including:

3. The system of claim 1 , wherein the computerized device is an Internet of Things (IoT) device, a consumer appliance, or a vehicle.

4. The system of claim 1 , wherein the device update includes a registration certificate or an anonymous certificate.

5. The system of claim 1 , wherein the device update comprises software or firmware to be installed on the computerized device.

6. The system of claim 5 , wherein the device update further comprises installation information or an installation script.

7. The campaign management service includes: storing data corresponding to said computerized device being updated; The system of claim 1 , further comprising computer-executable instructions that cause the first processor to perform operations including:

8. The data includes a campaign start date, a campaign end date, vehicle registration numbers, 8. The system of claim 7, further comprising one or more of a product serial number and a product model number.

9. The campaign management service includes: accessing said data to determine whether said computerized device is in said campaign; 8. The system of claim 7, further comprising computer-executable instructions that cause the first processor to perform operations including:

10. The system of claim 1 , wherein the Bloom filter data structure is of a constant size regardless of the number of computerized devices in the set.

11. Generating the Bloom filter data structure includes:

2. The system of claim 1, further comprising adjusting a number of hash functions that generate the hash value for the Bloom filter data structure based on a false positive rate threshold.

12. 2. The system of claim 1, wherein once the Bloom filter data structure is generated, the system causes the computerized device to poll the network edge for the device updates.

13. The campaign management service includes: instructing the network edges to delete the bloom filter data structure at the end of the campaign; The system of claim 1 , further comprising computer-executable instructions that cause the first processor to perform operations including:

14. 2. The system of claim 1, wherein each computerized device in the set of computerized devices includes a uniform resource locator for communicating with the network edge.

15. obtaining a bloom filter data structure from a campaign management service, the bloom filter data structure including a plurality of hash values; determining that the computerized device should receive device updates from the campaign management service based on a hash value associated with the computerized device matching a hash value of the Bloom filter data structure; sending a device update request corresponding to the computerized device to the campaign management service; obtaining the device update associated with the device update request from the campaign management service after the campaign management service has verified that the computerized device is a member of the campaign; providing the device update to the computerized device, whereby the computerized device installs the device update.

16. The operation further comprises: determining that the computerized device does not belong to the campaign using the Bloom filter data structure; an indication of a lack of device updates for the computerized device; to the computerized device without communicating with the campaign management service; The network edge of claim 15 comprising:

17. The network edge of claim 15 , wherein the device update includes a registration certificate or an anonymous certificate.

18. The network edge of claim 15 , wherein the device update comprises software or firmware to be installed on the computerized device.

19. Detecting a campaign initiation request specifying that a plurality of computerized devices are to be updated with device updates for the campaign; storing data corresponding to the plurality of computerized devices to be updated; generating a Bloom filter data structure including a plurality of hash values, each hash value being based on the data for each of the computerized devices in the plurality of computerized devices; providing the Bloom filter data structure to a network edge; receiving a request for the device update from a computerized device; verifying that the computerized device is a member of the campaign based on the data corresponding to the plurality of computerized devices being updated; providing the device update associated with the request to a network edge, the device update being for modifying electronic data accessed or stored by the computerized device; A campaign management service comprising computer-executable instructions that cause a processor to perform operations including:

20. 20. The campaign management service of claim 19, wherein the device update includes a registration certificate or an anonymous certificate.

Images