System and method for centralized management and routing of multiple credentials

Abstract

Systems, methods, and computer readable media for managing digital certificates and other security credentials. The routing and management server is communicatively coupled to the certificate user device and the plurality of certificate generators. The server performs operations that may include: optionally registering a credential user device; receiving a request for one or more digital certificates from a certificate user device; analyzing the request to determine an appropriate certificate generator from a plurality of certificate generators for generating the one or more digital certificates; optionally converting the request to a format required by an appropriate certificate generator; sending the request to an appropriate certificate generator; receiving one or more digital certificates from an appropriate certificate generator; and providing the one or more digital certificates to the certificate user device.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of and priority to U.S. Provisional Application No. 63 / 330,026, filed on April 12, 2022, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present invention relates to systems, devices, computer applications and methods for securely and centrally managing and generating digital assets, particularly security infrastructure credentials such as digital certificates (e.g., public key infrastructure certificates). Background Art

[0004] The computers in a computerized device operate according to its software and / or firmware and data. To ensure secure and correct operation, a computerized device must be properly initialized and regularly updated with appropriate software, firmware, executable instructions, digital certificates (e.g., public key infrastructure certificates), cryptographic keys, etc. (collectively referred to as "digital assets" or "software") as intended by the manufacturer and the device ecosystem in which it operates.

[0005] Most, if not all, modern vehicles and transportation machines (e.g., cars, trucks, electric vehicles, aircraft (e.g., drones), trains, boats, motorcycles, scooters, etc.) contain multiple embedded processors or embedded computers in their subsystems and are controlled by computers in many aspects. Similarly, an increasing number of modern transportation ecosystem devices (e.g., traffic lights, traffic cameras, traffic sensors, electronic traffic signs, traffic safety systems, bridge monitors, bridge control systems, etc.) contain at least one, and often multiple, embedded processors or embedded computer systems and are controlled by computers in at least some aspects. These computer-controlled elements of the modern transportation ecosystem communicate with each other, passing various types of information back and forth, and they may react, respond, change operations, or otherwise rely on information received / sent from other elements to achieve safe, correct, efficient, and reliable operation. Recent examples of transportation ecosystems include vehicle-to-vehicle (V2V; electric vehicle-to-grid V2G; and similar European C2C, vehicle-to-vehicle) ecosystems and vehicle-to-infrastructure ecosystems (V2I, and similar C2I, vehicle-to-infrastructure). V2V and V2I together are often referred to as V2X (e.g., vehicle-to-anything communications) ecosystems.

[0006] In the connected vehicle technology space (V2V, V2G, C2C, C2I, V2X, etc.), all vehicles and devices in the ecosystem must use the appropriate security infrastructure and have current, authentic and valid security credentials (e.g. digital certificates) to operate in a safe, secure and privacy-preserving manner. As connected vehicle applications exchange information between vehicles, road infrastructure, traffic management centers and wireless mobile devices, the ecosystem and security infrastructure ensure that users and ecosystem devices can trust the validity of information received from other ecosystem users and devices, obfuscated users and devices that they have never seen and have no information about.

[0007] However, problems arise when a computerized device in an ecosystem has one or more invalid digital assets, such as one or more invalid security credentials (e.g., digital certificates), which may indicate, for example, that the device is unreliable and untrustworthy. These problems include that information sent by such devices may be incorrect, untrustworthy, or unreliable. Digital certificates associated with computerized devices may become invalid for a variety of reasons, including expiration or timeout, or because an unauthorized or malicious actor (e.g., a hacker) has damaged, replaced, or altered the certificate or device software.

[0008] These problems are compounded and additional problems and technical inefficiencies arise when a vehicle that includes multiple computerized devices and subsystems, each of which is typically produced by a different subsystem manufacturer, needs to update, replace, or supplement one or more digital certificates for one or more of its component computerized devices or subsystems because the digital certificates required for each subsystem device may come from a different digital certificate supplier or generator. These additional problems and technical inefficiencies include, among other things, establishing and maintaining relationships, login credentials, accounts, etc. with each different supplier or generator; establishing the correct interaction protocols with each different supplier or generator; maintaining the correct interaction protocols with each different supplier or generator, especially as they change over time; and lack of storage capacity for code, etc. to implement the foregoing for a large number of different suppliers or generators.

[0009] Similar complexities arise when vehicle manufacturers supply vehicles to different countries, each of which adopts different inter-vehicle and inter-infrastructure ecosystems, such as V2X infrastructure in the United States and C2X infrastructure in European countries, because the same model of vehicle must be able to recognize different suppliers (e.g., certificate generators (such as security credential management systems)) and different types of digital certificates depending on where the vehicle is sold or used.

[0010] A further similar problem is that the certificates required by the various subsystems of the vehicle may be of different types, for example, they may be different types of public key infrastructure (PKI) certificates. A further similar problem is that the certificates required by the various subsystems of the vehicle may come from different ecosystems and / or different security infrastructures, for example, a V2X certificate (e.g., a pseudonym certificate) for the V2X ecosystem and a V2G certificate for the power grid ecosystem.

[0011] Therefore, it is desirable to provide improved systems, methods, and techniques for securely, easily, and centrally obtaining security credentials (e.g., digital certificates) for use with a device or system (e.g., a vehicle) that uses multiple digital certificates, which may be provided by multiple certificate providers / generators and may be in a variety of different formats.

[0012] Various embodiments described herein address these and other issues associated with managing multiple security credentials. Summary of the invention

[0013] Embodiments and implementations described herein include systems, methods, and computer-readable media for managing digital certificates and other security credentials. Various embodiments include a routing and management server communicatively connected to a certificate user device and a plurality of certificate generators. Various embodiments described herein perform functions, steps, or operations including: optionally registering a certificate user device; receiving a request for one or more digital certificates from a certificate user device; analyzing the request to determine an appropriate certificate generator from a plurality of certificate generators for generating one or more digital certificates; optionally converting the request to a format required by the appropriate certificate generator; transmitting the request to the appropriate certificate generator; receiving one or more digital certificates from the appropriate certificate generator; and providing one or more digital certificates to the certificate user device.

[0014] In some embodiments, analyzing the request to determine an appropriate certificate generator includes analyzing the request and determining a plurality of appropriate certificate generators; converting the request into a format required by the appropriate certificate generator includes converting the request into a plurality of formats required by a plurality of appropriate certificate generators; transmitting the converted request to the appropriate certificate generator includes transmitting the plurality of converted requests to a plurality of appropriate certificate generators; and receiving one or more digital certificates from the appropriate certificate generator includes receiving one or more digital certificates from the plurality of appropriate certificate generators.

[0015] In some embodiments, wherein the credential user device is a land vehicle. In some other embodiments, the credential user device is an aircraft.

[0016] In some embodiments, analyzing the request to determine the appropriate certificate generator includes reading information indicating the appropriate certificate generator from the received request. In some such embodiments, the information specifies the type of certificate.

[0017] In some embodiments, transmitting the translated request to the appropriate credential generator includes sending the translated request using a communication protocol specific to the appropriate credential generator.

[0018] In some embodiments, transmitting the translated request to the appropriate credential generator includes transmitting the translated request using enrollment credentials of the credential user device.

[0019] In some embodiments, the operations further include: registering, by the routing and management server, with at least one of the plurality of certificate generators; and receiving, from at least one of the plurality of certificate generators, a registration certificate for the routing and management server. In some such embodiments, transmitting the request for conversion to the appropriate certificate generator includes transmitting the request for conversion using the registration certificate of the routing and management server. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0021] Figure 1 is a block diagram illustrating an example of a system having centralized multiple digital asset (e.g., certificate) management capabilities consistent with embodiments of the present invention;

[0022] Figure 2 is a flow chart illustrating an example of a method for managing and routing security credentials consistent with embodiments of the present invention; and

[0023] Figure 3 is a block diagram of an example of a computing system that may be used to host and implement systems and methods consistent with embodiments of the invention. DETAILED DESCRIPTION

[0024] Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings.

[0025] Various embodiments and implementations consistent with the present invention provide systems, components, methods, and computer program products for centrally processing requests for multiple different types of digital assets (e.g., certificates or other security credentials), converting the requests into an appropriate format or generating an equivalent request (if necessary), routing the requests to the appropriate digital asset generator, and providing the newly generated responsive digital asset back to the requestor.

[0026] For example, consider an automaker producing a new U.S. electric vehicle that must be equipped with both a V2X certificate and a vehicle-to-grid (V2G) certificate so that the electric vehicle can connect to the grid and the vehicle's battery can provide unused power to the grid. Further consider that different technology ecosystems (e.g., V2X and V2G) employ different types of certificate formats, interfaces, communication protocols, and generators (e.g., V2G employs the X509 certificate format and interface, while V2X employs the IEEE Std 1609.2 certificate format and interface). Similarly, note that the European C2C ecosystem employs an ETSI-based certificate format and interface, which must be used if new electric vehicles are exported to Europe.

[0027] Technical problems, inefficiencies, high-cost software and hardware duplication, and maintenance issues arise because vehicle manufacturers must build, maintain, and keep up-to-date vehicle subsystems and software for two, three, or more different types of security infrastructure (e.g., PKI) during the life of the vehicle. In addition, if additional features or subsystems are added to the vehicle that require secure communication and provisioning, the vehicle will have to be updated and will require more certificates and security infrastructure support in the future.

[0028] Currently there is no system or device that allows a certificate user (e.g., a vehicle manufacturer, the vehicle itself, etc.) to obtain multiple different types of certificates (or other digital assets), which may come from multiple different certificate generators or producers, from a single centralized management system. Various embodiments consistent with the present disclosure provide novel devices and capabilities, etc., to provide or obtain multiple different types of certificates (e.g., V2X IEEE Std 1609.2 certificates, V2G X509 certificates, C2C ETSI standard certificates, etc.), which may come from multiple different certificate generators or producers via a centralized routing and management system.

[0029] Figure 1 1 is a block diagram illustrating an example of a system 100 having multiple digital asset (e.g., digital certificates or other security credentials) generation and management capabilities consistent with an embodiment of the present invention. As shown in this embodiment, the system 100 includes a credential (e.g., a type of digital asset) routing and management system 110, which can be implemented by a server (e.g., having at least one processor and associated memory) or other computing system. As shown, the credential routing and management system 110 is accessible via a network 130, which can be or include a digital network (e.g., the Internet), a cellular network, a wireless network, and other networks.

[0030] Any number of certificate users, such as certificate user 1101, certificate user 2102, etc. in the figure, up to certificate user n103, can interact with the credential routing and management system 110 through the network 130. In various embodiments, the certificate users 101-103 can be, for example, devices or systems that use certificates (e.g., vehicle-mounted unit devices), or computing systems of device manufacturers (e.g., vehicle-mounted unit manufacturers), or people using computers, etc. Therefore, in addition to the above examples, the certificate users 101-103 can be vehicle manufacturers that produce new U.S. electric vehicles that require a V2X certificate and also require a V2G certificate when manufactured. As another example, the certificate users 101-103 can be the new electric vehicle itself, which needs to supplement its V2X pseudonym certificate and needs to replace an expired or damaged V2G certificate. Therefore, the certificate users 101-103 are typically computers or computerized devices, although in some cases it can be a person.

[0031] like Figure 1 As shown in the example of , the credential routing and management system 110 may include a user portal 135 through which the credential user 101 interacts with the credential routing and management system 110. In some embodiments, the credential routing and management system 110 may include a human-accessible interface, such as a human-specific user portal, for use by human users 101-103. Additionally or alternatively, the credential routing and management system 110 may include an application programming interface (API) 140, and the credential user 102 may interact with the credential routing and management system 110 via the API 140. In some embodiments (not shown), a user (e.g., user 101) may be able to interact with the credential routing and management system 110 via either the portal 135 or the API 140. Typically, the user portal 135 and the API 140 only enable credential users 101-103 that are known and trusted by the credential routing and management system 110 (e.g., credential users that have registered, signed up, or established an account and are verified as legitimate security infrastructure users) to interact with the credential routing and management system 110. In some embodiments, the certificate user (e.g., 102) may provide a copy of its registration credentials (e.g., a V2X registration certificate or equivalent certificate in other technology ecosystems) to the credential routing and management system 110, which may store the V2X registration credentials for use when communicating with the V2X certificate generator (e.g., 121) on behalf of the certificate user 102 and according to the communication protocol adopted by the V2X certificate generator 121. The registration credentials may include a C2C registration certificate, a V2G registration credential, etc.

[0032] Functionality available to certificate users 101-103 includes the ability to request 101A, 102A, 103A certificates and receive 101B, 102b, 103A certificates. For example, in operation, a certificate user 1101 may send a request 101A for one or more certificates to the credential routing and management system 110 via the user portal 135. In some embodiments, a certificate user 101 may request more than one type of certificate and / or may request more than one type of certificate in a single request 101A. In some embodiments, a certificate user 101 uses multiple separate requests to accomplish the same thing. For example, a certificate user 101 may first send a request for a set of V2X pseudonym certificates and then send a second request for a V2G certificate. These requests may be for multiple devices that require certificates (e.g., multiple new electric vehicles) or a single device that requires certificates (e.g., on an electric vehicle).

[0033] Similarly, other credential users 102 , 103 may each transmit or send (in this example) various requests 102A, 103A to the credential routing and management system 110 via the API 140 for different numbers and types of credentials.

[0034] like Figure 1 As shown, the system also includes several digital asset (e.g., certificate) generators 121-127, which are communicatively connected to the credential routing and management system 110 via a network 130. In this example, the certificate generators include a North American (NA) V2X certificate generator 121, a European (EU) C2C certificate generator 122, a Chinese (CN) V2X certificate generator 123, a vehicle-to-grid (V2G) certificate generator 124, a phone-as-key certificate generator 125, an advanced driver assistance (ADA) certificate generator 126, and other types of certificate generators 127 known in the art. In some cases, different types of certificates may be based on different types of public key infrastructures.

[0035] In some embodiments, one or more of the certificate generators 121-127 may be a traditional security credential management system (SCMS) or the like. SCMS is a message security solution for V2X communications. SCMS may employ PKI to enable trusted communications between participants or elements of the V2X ecosystem. Authorized V2X ecosystem participants use digital certificates generated by SCMS to verify and confirm security and mobility messages for various connected vehicle technologies and features. To protect the privacy of vehicle owners and operators, certificates typically do not contain personal or device identification information, but may still serve as ecosystem credentials so that other users (e.g., devices) in the ecosystem can trust the source of each message. In some embodiments, SCMS may also include devices and functionality for identifying and removing misbehaving devices from the ecosystem while still maintaining privacy.

[0036] In various embodiments, upon receiving a request for one or more certificates (or other types of security credentials) from a certificate user (e.g., from certificate user 101), the credential routing and management system 110 examines, interprets, parses, or otherwise analyzes the request 101A to determine the appropriate certificate generator 121-127 to route the request 101A to. For example, in some implementations, the credential routing and management system 110 may analyze the data or information in the request 101A to determine the type of certificate requested by user 101 (e.g., North American V2X type, European C2C type, phone-as-key type, etc.). For example, such analysis may be accomplished by reading data from a particular field in the request message and then using a lookup table, hard coding, etc. to determine the type of certificate corresponding to the data in that field.

[0037] As another example, in some embodiments, request 101A may include information (e.g., a field) identifying one of the credential generators 121-127 to which credential routing and management system 110 routes request 101A, and credential routing and management system 110 may use the generator identity information to properly route request 101A. In some embodiments, where credential user 101 has contracted or registered directly with one (or more) of credential generators 121-127, the generator identity information in request 101A may include information provided to credential user 101 by a particular credential generator 121-127 at the time of registration.

[0038] Based on the type of certificate requested and / or the generator identity information, the credential routing and management system 110 may then send, transmit, or otherwise provide a request to a digital asset provider 121-127 that generates or otherwise provides the type of certificate requested by the user 101. Figure 2 As described above, in some embodiments, the credential routing and management system 110 may convert, reformat, or otherwise modify the request 101 into a format required for operation with the specific certificate generator to which it is routed. Additionally or alternatively, the credential routing and management system 110 may generate or create a new request in an operable format required by the specific certificate generator based on the request 101A, wherein the new request is functionally equivalent to the request 101A. Converting the received certificate requests 101A, 102A, and 103A into a new format or creating a new request in an operable format required by the specific certificate generator may be performed in a manner that is consistent with the operation of the credential routing and management system 110. Figure 1103A, but it should be noted that in some cases and embodiments, the certificate request (e.g., 101A) can be the exact format required by the appropriate certificate generator 121-227, in which case the credential routing and management system 110 can route the original request (e.g., certificate request 101A) to the appropriate certificate generator without modification.

[0039] As a first example of general operation, consider a use case where a certificate user 101 sends a request 101A for a set of NAV2X certificates (e.g., a set of V2X pseudonym certificates, etc.) In response, the credential routing and management system 110 may first analyze the data in the request 101A to determine that it is a request for a V2X type certificate, and may then create and send a certificate request 121A to the NAV2X certificate generator 121, wherein the request 121A is based on the information in the request 101A.

[0040] In response to the request 121A, the NAV2X certificate generator 121 creates or otherwise obtains the requested V2X certificate 121B, which is then provided to the credential routing and management system 110. Upon receiving the requested V2X certificate 121B from the NAV2X certificate generator 121, the credential routing and management system 110 may then transmit or otherwise provide the generated V2X certificates 121B (indicated by reference 101B) to the certificate user 101 that requested them.

[0041] Similarly, if the certificate user 101 later sends a request 101A for a V2G certificate, the credential routing and management system 110 may analyze the data in the new request 101A to determine that it is a request for a V2G type certificate and may then send the request 124A to the V2G certificate generator 124. Upon receiving the requested V2G certificate 124B from the V2G certificate generator 124, the credential routing and management system 110 may transmit or otherwise provide the requested V2G certificate (indicated by reference 101B) to the certificate user 101 that requested it.

[0042] One of ordinary skill in the art will recognize that Figure 1 The components, connections, processes, data, operations, and implementation details shown in the examples are examples presented for simplicity and clarity of explanation. Other components, processes, implementation details, and variations may be used without departing from the principles of the present invention, as the examples are not intended to be limiting and many variations are possible. For example, although Figure 1Only six specific types of certificate generators are shown in FIG. 1 , but other embodiments may have many other types of certificate generators, as shown in component 127. For another example, although Figure 1 It is described in the context of digital certificates, but other implementations may include other types of digital assets, including software patches, software versions, etc.

[0043] Figure 2 is a flow chart illustrating an example of a method or process 200 for managing and routing security credentials according to an embodiment of the present invention. Note that optional operations or functions of the illustrated embodiment are represented by rectangles made of dashed lines. In various embodiments, some or all of the process 200 or the illustrated operations may be performed by code (e.g., instructions) executed on a general-purpose computing system (which may include one or more processors or one or more computing subsystems), a hardware-only system, or a hybrid system of the two. In various embodiments, some or all of the process 200 may be performed or executed by a credential routing and management system 110, which may communicate with the credential users 101-103 and the digital asset generators 121-127, as described with reference to FIG. Figure 1 and as described throughout this disclosure.

[0044] like Figure 2 As shown in the example of , process 200 can start at optional block 201 (e.g., optional operation) to register with or be registered by one or more certificate generators. For example, in an embodiment where the certificate generator (e.g., NAV2X certificate generator 121) is implemented by a traditional SCMS, the credential routing and management system 110 can register with the V2X ecosystem by signing a contract with the provider of the NAV2X certificate generator 121 (e.g., SCMS). Among other things, the provider can ensure that security standards that must be met for registrants to operate within their ecosystem are met. Once authorized or registered, the credential routing and management system 110 will be considered a trusted actor in the V2X ecosystem. Additionally or alternatively, a certificate user (e.g., 101-103) can register with one or more certificate generators so that certificate requests including users managed by the credential routing and management system will be executed by the generator that registered the user.

[0045] Process 200 may continue at 203 with registering a certificate user (e.g., 101-103). In various embodiments, a certificate user may register with the credential routing and management system 110 by signing a contract with a provider of the credential routing and management system 110. Among other things, the provider may ensure that security standards that must be met for the registrant to operate in one or more ecosystems associated with the generators 121-127 are met. Once authorized or registered, the user 101-103 will be considered a trusted actor in the technology ecosystem in which it is registered. As previously described, in some embodiments, a certificate user (e.g., 102) may provide a copy of its V2X registration certificate (or its equivalent in other technology ecosystems) to the credential routing and management system 110, and the credential routing and processing system 110 may store the registration certificate for use when communicating with the V2X certificate generator (e.g., 121) on behalf of the certificate user 102 and according to the communication protocol employed by the V2X certificate generator 121.

[0046] Process 200 continues at 205 with receiving a request for one or more certificates (e.g., 101A-103A), where the request is from a certificate user (e.g., 101-103), which in some cases may be a device (e.g., a vehicle or an onboard unit). In some embodiments, block 205 may involve the user 101-103 logging into the credential routing and management system 110, such as via a user portal (e.g., 135), and then entering the request 101A-103A. In some embodiments, block 205 may involve the user device 101-103 interacting with the API 140 of the credential routing and management system 110 to communicate the request 101A-103A. As previously described, the certificate user 101-103 may be any number of things, including a computing system or device of a device manufacturer that uses the certificate (e.g., a V2X vehicle or a subsystem of a vehicle (e.g., an OBU) or a computerized device).

[0047] In various embodiments, the requests 101A-103A may be for any number or type of digital certificates from any one or more of the certificate generators 121-127. For example, the requests 101A-103A may be for one digital certificate from a single generator (e.g., for a single CN V2X registration certificate), or for multiple digital certificates from a single generator (e.g., for a set of CN V2X pseudonym certificates), or for two or more individual digital certificates generated by two or more different generators (e.g., for a single NAV2X registration certificate and a single V2G certificate), or for any other combination of number and type of certificates. In some embodiments, the requests 101A-103A may include a registration certificate for the requesting user 101-103, which may be used to communicate with the certificate generator, e.g., as described below.

[0048] At 210, the process 200 analyzes the request (e.g., 101A-103A) to determine an appropriate certificate generator to satisfy the request by generating or otherwise producing the requested digital certificate. In various embodiments, the request may include information that directly or indirectly identifies an appropriate certificate generator. For example, the request may include information or fields that specify an appropriate certificate generator (e.g., according to parameters and definitions of API 140). For another example, the request may include information that specifies the general type of certificate requested, and analyzing the request may include reading, parsing, or otherwise identifying data or information in the request that identifies the desired certificate type (e.g., data from a specific field in a data structure). In such an embodiment, the process 200 may determine or select an appropriate certificate generator based on the certificate type specified in the request. In such an embodiment, selecting a certificate generator may include using the type of certificate as a search term, a lookup keyword, an index, etc. to find, retrieve, or otherwise identify a specific generator from a set of available generators 121-127.

[0049] At optional block 220, process 200 may convert the request for a certificate (e.g., 101A-103A) from block 205 into a format usable by the certificate generator determined or selected in operation 210. In some such embodiments, the request 101A-103A may be in a format that is easily understood and used by the credential routing and management system 110; for example, a format that speeds up and simplifies the determination of the type of certificate being requested (e.g., operation 210) and the routing of the request, while such a request format may be incompatible with the selected certificate generator. In such a case, operation 220 may convert, reformat, or otherwise convert the received request 101A-103A into a request (e.g., 121A-127A) that is compatible with the selected appropriate certificate generator as needed. In some embodiments, process 200 may use information from the request (e.g., 101A-103A) received at block 205 to create a new request (e.g., 121A ... 127A) from scratch for the selected appropriate certificate generator.

[0050] At 225, process 200 transmits, routes, or otherwise provides the (possibly converted) request (e.g., 121A-127A) to the appropriate credential generator determined in block 210. As previously described, the request sent to the credential generator may be optionally reformatted prior to being sent.

[0051] In various embodiments, some or all of the certificate generators 121-127 may employ different communication protocols from one another; for example, the protocol used to request (e.g., 121A) and receive (e.g., 121B) certificates from the NAV2X certificate generator 121 is different than the protocol used to request (e.g., 124A) and receive (e.g., 124B) certificates from the V2G certificate generator 124. In such embodiments, when communicating with each of the certificate generators 121-127, the process 200 (e.g., implemented by the credential routing and management system 110) employs the respective protocol associated with each certificate generator. In embodiments where process 200 has access to a registration certificate (or similar certificate) of a requesting certificate user 101-103 (e.g., as previously stored by credential routing and management system 110 or received in request 101A-103A), the process may use the registration certificate when communicating with a corresponding certificate generator (e.g., 121 of a V2X registration certificate) in accordance with a communication protocol such that credential routing and management system 110 acts as a proxy for requesting certificate user 101-103 and certificate generator 121 responds as if it were interacting with a registration certificate holder device (e.g., 101-103).

[0052] After receiving a request (e.g., 121A-127A) sent from the credential routing and management system 110, the certificate generator 121-127 processes the request and generates, calculates, retrieves, or otherwise generates a certificate (e.g., 121B-127B, which is a type of digital asset or security credential) based on the request, and sends the certificate (e.g., 121B-127B) to the credential routing and management system 110.

[0053] At 230 , process 200 receives one or more certificates (eg, 121B- 127B) from the certificate generator selected in operation 215 , and transmits the request to the certificate generator in operation 225 .

[0054] At 235, process 200 transmits or otherwise provides the credentials (eg, 101B-103B) to the requesting entity (eg, to the credential user 101-103 that sent the request 101A-103A).

[0055] Figure 2The example depicted in is for illustrative purposes only and is not intended to be limiting. In addition, the process 200 depicted is a somewhat simplified example for the purpose of clearly explaining certain novel and innovative features consistent with certain disclosed embodiments, but the example is not intended to be limiting and many variations are possible. For example, for clarity, process 200 is described in the context of a certificate user request (e.g., 102A) that is routed to a single generator (e.g., 121) because the certificate user request is for a single type of certificate (e.g., a NAV2X certificate), but a certificate user request (e.g., 102A) that includes sub-requests for several types of certificates (e.g., a NAV2X certificate, a V2G certificate, and an aftermarket ADA certificate) will cause the sub-requests to be routed to three appropriate generators (e.g., 121, 124, and 126).

[0056] Although functions and operations are shown as being performed in a particular order, the order described is only an example, and various different blocks or sequences of operations consistent with certain disclosed embodiments may be performed. In addition, the operations are described as discrete steps for purposes of explanation only, and in some embodiments, multiple operations may be performed simultaneously and / or as part of a single calculation or larger operation. The operations described are not exhaustive, limiting, or absolute, and various operations may be modified, inserted, or deleted.

[0057] Other variations are also possible. As an example of a variation, although Figure 2 It is described in the context of digital certificates, but systems and processes consistent with the present disclosure may similarly handle other types of digital assets (eg, software patches, application versions, etc.).

[0058] Figure 3 3 is a block diagram of an example of a computing environment that includes a computing system 300 that can be used to implement systems and methods consistent with embodiments of the present invention. Other components and / or arrangements may also be used. In some embodiments, computing system 300 can be used to at least partially implement Figure 1-2 In some embodiments, a series of computing systems similar to computing system 300 can each be customized and / or programmed as a dedicated server with dedicated hardware to implement Figure 1-2 One of the components or blocks, which can communicate with each other via network 335.

[0059] exist Figure 3In the example shown, computing system 300 includes multiple components, such as CPU 305, memory 310, input / output (I / O) device 325, hardware security module (HSM) 340 and storage device 320. System 300 can be implemented in various ways. For example, an implementation as an integrated platform (such as a server, workstation, personal computer, laptop, etc.) can include CPU 305, memory 310, non-volatile memory 320 and I / O device 325. In this configuration, components 305, 310, 320 and 325 can be connected and communicated through a local data bus, and can access data repository 330 (for example, implemented as a separate database system) through an external I / O connection. I / O component 325 can be connected to external devices through a direct communication link (for example, a hardwired or local wifi connection), through a network (such as a local area network (LAN) or a wide area network (WAN, such as a cellular phone network or the Internet)) and / or through other suitable connections. System 300 can be independent or a subsystem of a larger system.

[0060] CPU 305 may be one or more known processors or processing devices, such as the Core 200, manufactured by Intel Corporation of Santa Clara, California. TM AMD Sunnyvale, California TM Athlon manufactured by the company TM Memory 310 may be one or more fast storage devices for storing instructions and information executed or used by CPU 305 to perform certain functions, methods and processes associated with embodiments of the present invention. Memory 320 may be a volatile or non-volatile, magnetic, semiconductor, tape, optical or other type of storage device or computer-readable medium, including devices for long-term storage such as CDs and DVDs and solid-state devices.

[0061] In the illustrated embodiment, memory 310 contains one or more instructions, programs, or applications 315 loaded from storage device 320 or from a remote system (not shown) that, when executed by CPU 305, perform various operations, procedures, processes, or methods consistent with the present invention. Alternatively, CPU 305 may execute one or more programs located remotely from system 300. For example, system 300 may access one or more remote programs via network 335 that, when executed, perform functions and processes associated with embodiments of the present invention.

[0062] In one embodiment, memory 310 may include programs 315 for performing the specialized functions and operations described herein for credential management and routing system 110. In some embodiments, memory 310 may also include other programs or applications that implement other methods and processes that provide auxiliary functionality to the present invention.

[0063] The memory 310 may also be configured with other programs (not shown) not related to the present invention and / or an operating system (not shown) that performs several functions known in the art when executed by the CPU 305. For example, the operating system may be Microsoft Windows TM , Unix TM 、Linux TM 、Apple Computers TM operating system or other operating systems. The choice of operating system, or even the use of an operating system, is not important to the present invention.

[0064] The HSM 340 may be a device with its own processor that securely manages digital security assets and / or securely performs various cryptographic and sensitive calculations. In some embodiments, the HSM 340 protects digital security assets (such as cryptographic keys and digital certificates) and other sensitive data from possible access by attackers. In some implementations, the HSM may be a plug-in card or board that is directly connected to the computing system 300.

[0065] I / O device 325 may include one or more input / output devices that allow system 300 to receive and / or transmit data. For example, I / O device 325 may include one or more input devices (e.g., keyboard, touch screen, mouse, etc.) that can input data from a user. In addition, I / O device 325 may include one or more output devices (e.g., display screen, CRT monitor, LCD monitor, plasma display, printer, speaker device, etc.) that can output or present data to a user. I / O device 325 may also include one or more digital and / or analog communication input / output devices that allow computing system 300 to communicate with other machines and devices, such as digitally. Other configurations and / or quantity input and / or output devices may be included in I / O device 325.

[0066] In the illustrated embodiment, the system 300 is connected to a network 335 (e.g., the Internet, a private network, a virtual private network, a cellular network, or other network or a combination of these networks), which in turn can be connected to various systems and computing machines (e.g., servers, personal computers, laptops, client devices, etc.). In general, the system 300 can input data from external machines and devices and output data to external machines and devices through the network 335. In some embodiments, the network 335 can be the network 130, or a portion of the network 130.

[0067] exist Figure 3 In the exemplary embodiment shown, data repository 330 is a separate database (e.g., database 125) external to system 300. In other embodiments, data repository 330 can be hosted by system 300. In various embodiments, data repository 330 can manage and store data used to implement systems and methods consistent with the present invention. For example, data repository 330 can manage and store data structures used by credential management and routing system 110.

[0068] Data repository 330 may include one or more databases that store information and are accessed and / or managed by system 300. For example, database 330 may be an Oracle TM Database, Sybase TM Databases or other relational databases. However, systems and methods consistent with the present invention are not limited to a single data structure or database, or even to the use of a database or data structure.

[0069] One of ordinary skill in the art will recognize that Figure 3 The components and implementation details of the systems in are examples presented for simplicity and clarity of explanation. Other components and implementation details may be used.

[0070] Although for the sake of clarity, Figure 1-3 The examples are described in the context of road vehicles and V2X / C2X ecosystems, but other embodiments consistent with the invention may also be used in the context of aircraft and aircraft ecosystems (including drones and drone ecosystems), and other ecosystems using trusted communication devices based on secure credentials (such as digital certificates). Other examples include ecosystems for medical devices (e.g., dialysis machines, infusion pumps, etc.), robots, autonomous vehicles, and secure voice and digital communications, etc.

[0071] The various operations of the applications described herein may be performed at least in part by one or more virtual machines (VMs). In additional or alternative embodiments, the operations of the applications described herein may be performed at least in part by one or more processors, which are temporarily configured (e.g., by software) or permanently configured to perform related operations. Whether temporarily or permanently configured, these processors may constitute processor-implemented modules for performing one or more application operations, functions, and roles described herein. As used herein, the term "processor-implemented module" refers to a hardware module implemented using one or more processors.

[0072] Similarly, the methods described herein may be implemented at least in part by a processor, and a specific processor or multiple processors are examples of hardware. For example, at least some operations of the method may be performed by one or more processors or modules implemented by the processor. In addition, one or more processors may also support the performance of related operations in a "cloud computing" environment or as "software as a service" (SaaS). For example, at least some operations may be performed by a group of computers (as an example of a machine including a processor), which may be accessed via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs).

[0073] The performance of certain operations may be distributed among processors, not only residing in a single machine, but also deployed on multiple machines. In some example embodiments, the processor or processor-implemented modules may be located in a single geographic location (e.g., in an office environment, a manufacturing environment, or a server farm). In other example embodiments, the processor or processor-implemented modules may be distributed in multiple geographic locations.

Claims

1. A system for managing digital certificates, the system comprising: A routing and management server is communicatively connected to a certificate user device and a plurality of certificate generators and is operable to perform operations including: Registering the certificate user device; receiving a request for one or more digital certificates from the certificate user device; analyzing the request to determine an appropriate certificate generator from the plurality of certificate generators for generating the one or more digital certificates; converting the request into a format required by the appropriate credential generator; transmitting the converted request to the appropriate certificate generator; receiving the one or more digital certificates from the appropriate certificate generator; as well as The one or more digital certificates are provided to the certificate user device.

2. The system according to claim 1, wherein: Analyzing the request to determine an appropriate credential generator includes analyzing the request and determining a plurality of appropriate credential generators; wherein converting the request into a format required by the appropriate certificate generator comprises converting the request into multiple formats required by multiple appropriate certificate generators; wherein transmitting the converted request to the appropriate credential generator comprises transmitting a plurality of converted requests to the plurality of appropriate credential generators; and Wherein, receiving the one or more digital certificates from the appropriate certificate generator includes receiving one or more digital certificates from the plurality of appropriate certificate generators.

3. The system according to claim 1, wherein: The credential user device is a land vehicle.

4. The system according to claim 1, wherein: The certificate user device is an aircraft.

5. The system according to claim 1, wherein: Analyzing the request to determine an appropriate credential generator includes reading information indicative of the appropriate credential generator from the received request.

6. The system according to claim 5, wherein: The information specifies the type of certificate.

7. The system according to claim 1, wherein: Transmitting the translated request to the appropriate credential generator includes sending the translated request using a communication protocol specific to the appropriate credential generator.

8. The system according to claim 1, wherein: Transmitting the request for conversion to the appropriate credential generator includes transmitting the request for conversion using a registration credential of the credential user device.

9. The system of claim 1, further comprising: registering, by the routing and management server, with at least one of the plurality of credential generators; as well as A registration certificate for the routing and management server is received from at least one of the plurality of certificate generators.

10. The system according to claim 9, wherein: Transmitting the translated request to the appropriate credential generator includes transmitting the translated request using a registration credential of the routing and management server.

11. A method for managing digital certificates using a routing and management server, the routing and management server being communicatively connected to a certificate user device and a plurality of certificate generators, the method comprising: Registering the certificate user equipment by the routing and management server; receiving, by the routing and management server, a request for one or more digital certificates from the certificate user device; analyzing, by the routing and management server, the request to determine an appropriate certificate generator from among the plurality of certificate generators for generating the one or more digital certificates; The routing and management server converts the request into a format required by an appropriate certificate generator; transmitting, by said routing and management server, the translated request to an appropriate credential generator; receiving, by the routing and management server, one or more digital certificates from an appropriate certificate generator; as well as One or more digital certificates are provided by the routing and management server to the certificate user device.

12. The method according to claim 11, wherein: Analyzing the request to determine an appropriate credential generator includes analyzing the request and determining a plurality of appropriate credential generators; wherein converting the request into a format required by the appropriate certificate generator comprises converting the request into multiple formats required by multiple appropriate certificate generators; wherein transmitting the transformed request to the appropriate credential generator comprises transmitting a plurality of transformed requests to a plurality of appropriate credential generators; and Wherein, receiving the one or more digital certificates from the appropriate certificate generator includes receiving one or more digital certificates from the plurality of appropriate certificate generators.

13. The method according to claim 11, wherein: The credential user device is a land vehicle.

14. The method according to claim 11, wherein: The certificate user device is an aircraft.

15. The method according to claim 11, wherein: Analyzing the request to determine an appropriate credential generator includes reading information indicative of the appropriate credential generator from the received request.

16. The method according to claim 15, wherein: The information specifies the type of certificate.

17. The method according to claim 11, wherein: Transmitting the translated request to the appropriate credential generator includes sending the translated request using a communication protocol specific to the appropriate credential generator.

18. The method according to claim 11, wherein: Transmitting the request for conversion to the appropriate credential generator includes transmitting the request for conversion using a registration credential of the credential user device.

19. The method according to claim 11, further comprising: registering, by the routing and management server, with at least one of the plurality of credential generators; as well as A registration certificate for the routing and management server is received from at least one of the plurality of certificate generators.

20. The method according to claim 19, wherein: Transmitting the translated request to the appropriate credential generator includes transmitting the translated request using a registration credential of the routing and management server.

21. A non-transitory computer readable medium comprising instructions that, when executed by a processor, perform a method for managing digital certificates, the method comprising: Registering certificate user devices by routing and management servers; receiving, by the routing and management server, a request for one or more digital certificates from the certificate user device; analyzing, by the routing and management server, the request to determine an appropriate certificate generator from a plurality of certificate generators for generating the one or more digital certificates; converting, by the routing and management server, the request into a format required by the appropriate credential generator; transmitting, by the routing and management server, the translated request to the appropriate credential generator; receiving, by the routing and management server, one or more digital certificates from the appropriate certificate generator; as well as One or more digital certificates are provided by the routing and management server to the certificate user device.

22. The non-transitory computer readable medium of claim 21, wherein: Analyzing the request to determine an appropriate credential generator includes analyzing the request and determining a plurality of appropriate credential generators; wherein converting the request into a format required by the appropriate certificate generator comprises converting the request into multiple formats required by multiple appropriate certificate generators; wherein transmitting the converted request to the appropriate credential generator comprises transmitting a plurality of converted requests to the plurality of appropriate credential generators; and Wherein, receiving the one or more digital certificates from the appropriate certificate generator includes receiving one or more digital certificates from the plurality of appropriate certificate generators.

23. The non-transitory computer readable medium of claim 21, wherein: The credential user device is a land vehicle.

24. The non-transitory computer readable medium of claim 21, wherein: The certificate user device is an aircraft.

25. The non-transitory computer readable medium of claim 21, wherein: Analyzing the request to determine an appropriate credential generator includes reading information indicative of the appropriate credential generator from the received request.

26. The non-transitory computer readable medium of claim 25, wherein: The information specifies the type of certificate.

27. The non-transitory computer readable medium of claim 21, wherein: Transmitting the translated request to the appropriate credential generator includes sending the translated request using a communication protocol specific to the appropriate credential generator.

28. The non-transitory computer readable medium of claim 21, wherein: Transmitting the translated request to the appropriate credential generator includes transmitting the translated request using a registration credential of the credential user device.

29. The non-transitory computer readable medium of claim 21, further comprising: registering, by the routing and management server, with at least one of a plurality of credential generators; as well as A registration certificate for the routing and management server is received from at least one of the plurality of certificate generators.

30. The non-transitory computer readable medium of claim 29, wherein: Transmitting the translated request to the appropriate credential generator includes transmitting the translated request using a registration credential of the routing and management server.

Images