KR102537712B1 - Systems, methods and devices for provisioning and processing location information for computerized devices - Google Patents

Abstract

A system, device and method for secure provisioning of a roadside unit (RSU) comprising an application certificate, wherein the RSU device is geographically restricted according to the application certificate. The enhanced SCMS system includes receiving an application certificate request for an RSU; determining operational location information for the RSU in response to the request; verifying that the operating location information is within the geographic area for the RSU; generating an application program certificate including operating location information; and providing the application certificate to the RSU device; Also performs new processes, processes to create and provide application certificates with accurate operational location information, enhanced application certificate provisioning requests that allow requestors to specify accurate operational location information, and enhanced application certificates with geographic restriction information. and advanced computerized devices such as RSUs that adopt accurate operating location information from application certificates.

Description

Systems, methods and devices for provisioning and processing location information for computerized devices

This application claims priority from U.S. Provisional Patent Application No. 62/631,593, filed on February 16, 2018, and this application is a continuation-in-part of U.S. Patent Application No. 16/191,030, filed on November 14, 2018, and claims two All applications are incorporated herein by reference in their entirety.

The present invention relates to systems, devices and methods for securely creating and providing certain types of digital assets, such as security credentials and digital certificates. More particularly, the present invention relates to improved systems, methods and techniques for securely provisioning location information-specific digital assets to computerized devices in a V2X infrastructure.

As computers become increasingly miniaturized and commoditized, manufacturers are producing an increasing variety of devices that contain one or more embedded computers or processors. A computer in a computerized device can control the operation of the device and collects, stores, and shares data and communicates with other computers and other computing devices. Above all, it updates its own software.

The Internet of Things (IoT) is a network of computerized physical devices with embedded processors, electronic devices, software, data, sensors, actuators, and/or network connections, which are digital networks, including the Internet, cellular networks, and other wireless networks. to connect and exchange data. In general, each "thing" must be uniquely identifiable by an embedded computer system and must be able to inter-operate within an existing Internet infrastructure or using other communication mediums.

“Things” in the sense of IoT are home appliances, enterprise devices used in business and corporate environments, manufacturing equipment, agricultural equipment, and energy-consuming devices in homes and buildings (switches, power outlets, appliances, lighting systems, light bulbs, televisions, garages, etc.). door opening devices, sprinkler systems, security systems, etc.), medical and healthcare devices, infrastructure management devices, robots, drones, transportation devices and vehicles.

For example, most, but not all, modern vehicles and transportation devices (e.g. cars, trucks, aircraft, trains, ships, motorcycles, scooters, etc.) contain multiple embedded processors or embedded computers in their subsystems, and in at least some respects controlled by computer Similarly, more and more modern transportation infrastructure devices (e.g. traffic lights, traffic cameras, traffic sensors, bridge monitors, bridge control systems, roadside units, etc.) contain one or more embedded processors or embedded computer systems, which in at least some respects controlled by computer

These computer-controlled elements of a transportation network typically communicate with each other to pass various types of information back and forth. For example, a roadside unit (RSU) is a roadside-located computer device that communicates with passing vehicles and other RSUs. An RSU can be fixed in one location (e.g., in a box built into the side of a highway) or it can be a mobile handheld device that is carried and deployed as needed by road workers, emergency workers, etc.

The various computer-controlled elements of a transportation network react, respond, change operation, or otherwise depend on information received/transmitted from other vehicles within the vehicle-to-vehicle (V2V; also known as vehicle-to-vehicle (C2C)). . It also communicates with infrastructure elements (such as RSUs) within vehicle-to-infrastructure (V2I, also known as vehicle-to-infrastructure (C2I)) and communicates for safe, accurate, efficient, and reliable operation.

In general, vehicle-to-everything (V2X) or vehicle-to-everything (V2X) refers to the transfer of information from a vehicle to any entity that can affect the vehicle (e.g., other vehicles (V2V) and infrastructure elements (V2I)) and vice versa. -It is called all things (C2X). Some of the main goals of V2X are road safety, traffic efficiency and energy saving.

The computer of the computerized device operates according to software and/or firmware and data. To ensure safe and proper operation, computerized devices may include appropriate software, firmware, executable instructions, digital certificates (eg public key certificates), cryptographic keys and other information (collectively referred to herein as 'digital assets' or software'). is properly initialized and updated as intended by the manufacturer or V2X system operator. Because of this, the IoT consists only of devices running approved, legitimate software and data.

However, problems arise when unauthorized persons or organizations (e.g. hackers) replace or change the software of a computer device. Problems also arise when old software, untested software, unapproved software and/or software with known bugs are installed on a computer device.

Particular challenges arise when provisioning computerized devices designed to operate under geographic restrictions, such as RSUs in V2X infrastructure. These devices will not function properly if the geolocation-specific digital assets provided to the RSU are not adequate, out of date, or do not match the actual geographic operating location of the RSU.

Accordingly, there is a need to provide improved systems, methods and techniques for provisioning location information-specific digital assets to computerized devices such as RSUs of V2X infrastructures.

Disclosed herein are systems, methods and devices for secure provisioning of computerized devices such as roadside unit (RSU) devices. This includes enrollment certificates and application certificates, where a computerized device (eg RSU) is geographically constrained from proper operation according to geographic information in the enrollment certificate and application certificate.

Various disclosed embodiments may be implemented by an enhanced security credential management system (SCMS) that may be hosted by one or more computerized systems, such as one or more server computers.

In various embodiments systems and devices may include providing a computerized device (eg RSU) with a registration certificate specifying a geographic area for the computerized device (eg RSU); and receiving a request for an application certificate for a computerized device (eg RSU).

In response to the request for application certificate, the operation may include determining operating geolocation for the computerized device (eg, RSU); verifying whether the operating location information is within a geographic area; generating an application program certificate including operating location information; and providing the application certificate containing the operating location information to the computerized device (eg RSU).

In various embodiments, proper operation of the computerized device is geographically restricted according to the operating location information in the application certificate.

In various embodiments the request includes operating location information for a computerized device (eg RSU). The step of determining operating location information for the computerized device in response to the request also includes obtaining operating location information from the request.

In a further embodiment the request is received from a computerized device. In yet other embodiments the computerized device is configured with operating location information and the computerized device includes the operating location information in the request.

Further operations in various embodiments may include receiving a request containing operating location information for a computerized device to store operating location information for the computerized device (eg, RSU); storing operating location information for the computerized device in response to the request (which may be performed prior to receiving the request for the application certificate); and determining operating location information for the computerized device in response to the request further includes obtaining stored operating location information.

In some such embodiments a request to store operating location information is received from a user of a computerized device. In some embodiments the geographic area is country or state and operational location information.

Another embodiment described herein is a system, method, and device for securely provisioning computerized devices, such as roadside unit (RSU) devices, that once provisioned, geographically define the operating area of a computerized device (eg, RSU device). Include restrictive application certificates.

Still further embodiments include an enhanced SCMS receiving application certificate requests for enrollment certificates specifying a geographic area for computerized devices (eg RSUs) and application certificates for computerized devices (eg RSUs). do.

The request then includes the desired operational location information (which may be within the geographic area); verify that the operating location information is within the geographic area; generate an application certificate containing operational location information; and in response to the application certificate request, providing an application certificate including operating location information to the geographically restricted RSU device according to the operating location information of the application certificate.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the specification serve to explain the principles of the invention.
1 is a diagram illustrating an example of a method for tracking the provisioning of a computerized device of an entity requiring a certificate performed within a secure provisioning system consistent with an embodiment of the present invention.
2 is a diagram illustrating an example of a method for shaping and providing a local policy file (LPF) for a computerized device implemented within a secure provisioning system consistent with an embodiment of the present invention.
3 is a diagram illustrating an example of a method for providing a full charge of secure assets to a computerized device performed within a secure provisioning system consistent with an embodiment of the present invention.
4 is a diagram illustrating an example of a secure provisioning system configured to support multi-tenant operation consistent with an embodiment of the present invention.
5 is a diagram illustrating a computerized device corresponding to multiple tenants of a secure provisioning system consistent with an embodiment of the present invention.
6 is a diagram illustrating an exemplary workflow within a security provisioning system that includes a certificate management system (CMS) management portal (CMP) consistent with an embodiment of the present invention.
7 is a diagram illustrating an exemplary operating environment for a secure provisioning system configured to support multi-tenant operation consistent with an embodiment of the present invention.
8A is a first portion of a swimlane diagram illustrating an example of a process for securely providing multiple tenants with credentials, such as certificates, consistent with an embodiment of the present invention.
8B is a second portion of a swimlane diagram illustrating an example of a process for securely providing multiple tenants with credentials, such as certificates, consistent with an embodiment of the present invention.
9 is a block diagram of an embodiment of a computerized system that may be used with hosting systems and methods consistent with embodiments of the present invention.
10 is a diagram illustrating an example of a method for initial provisioning and tracking RSUs consistent with an embodiment of the present invention.
11 is a diagram illustrating an example of a method for shaping an deployed RSU consistent with an embodiment of the present invention.
12 is a diagram illustrating an example of a method for providing a non-pristine digital asset to a deployed RSU device consistent with an embodiment of the present invention.
13A is a first portion of a swimlane diagram illustrating an example of a process for securely providing multiple tenants with digital assets, such as application certificates, containing location information consistent with an embodiment of the present invention.
13B is a second portion of a swimlane diagram illustrating an example of a process for securely providing multiple tenants with digital assets, such as application certificates, containing location information consistent with an embodiment of the present invention.

Reference will now be made in detail to exemplary embodiments of the present invention, examples of which are shown in the accompanying drawings. For convenience, the same reference numbers are used throughout the drawings to refer to the same or like parts.

In various embodiments, an embedded computer-controlled device may be secured by provisioning secure assets within the device. For example, secure assets may include cryptographic keys, unique identifiers, digital certificates, and security software. Secure assets can also be used for secure communications, for example to authenticate devices and perform over-the-air programming (OTA) software updates.

To ensure safe and proper operation in the field, embedded devices such as electronic control units (ECUs) used in vehicles, for example, must be properly initialized during manufacturing by provisioning digital assets such as security assets. Digital assets may include various digital certificates, cryptographic keys, unique identifiers and software.

In most cases, the SCMS that create these digital assets for different tenants and manufacturing plants are located in different geographic locations and are interconnected via typically insecure internet communications. Therefore, it is desirable to create an end-to-end secure channel from the source of these digital assets to the devices of multiple tenants so that they cannot be accessed or modified by malicious parties or by accident.

Typically, different manufacturing plants and tenants (eg clients, customers and subscribers) require different SCMS configurations. In various embodiments a tenant may be an entity such as a company or manufacturer, a client of SCMS or a subscriber to SCMS. Typically, a separate SCMS with dedicated hardware must be configured for each tenant. Therefore, it is desirable to minimize the redundancy and costs associated with using a dedicated custom SCMS to provide these digital assets to multiple tenants.

The following specification describes security assets that are provisioned within vehicle-to-vehicle and vehicle-to-infrastructure (V2X) devices. V2X devices may include, for example, vehicle-mounted units (OBUs), electronic control units (ECUs), roadside units (RSUs), and the like. OBUs are included in all self-driving vehicles.

However, the embodiments described herein are not limited to V2X devices and the principles disclosed may be applied to other types of computer controlled devices. For example, in additional or alternative embodiments multi-tenant processes and systems may be used to provide certificates to other computerized devices, such as, for example, C2X devices. For example, enhanced SCMS with CMP, Virtual Enrollment Authority, SMS, and SMS database components similar to those shown in FIG. 4 may provide certificates to one or more OBUs, ECUs, and RSUs.

In various embodiments, OBUs and ECUs are intended to be installed in autonomous vehicles, ships (eg boats), aircraft (eg airplanes and drones), spacecraft, medical devices, robots, vehicles including wireless or wired communication modules and IoT devices. can be shaped. Likewise, RSUs can be installed in traffic control devices (eg traffic signals), roadside content distribution systems, electronic toll systems, electronic signage devices and digital display devices (eg electronic billboards).

In the V2X ecosystem, secure assets (e.g. enlistment certificates) are used to identify and authorize end entities (e.g. V2X devices) to transfer other secure assets (e.g. pseudonyms and/or application certificates) to a Security Credential Management System (SCMS). can be requested and received from Unlike existing X.509 certificates, V2X enrollment certificates and pseudonym certificates do not contain the identity of the corresponding end entity. Therefore, outside observers cannot associate their use with a specific vehicle or device. In addition, the security assets used in V2X devices change periodically during the operating life of the device.

During the manufacture of V2X devices, the secure asset provisioning process takes place in different locations (and therefore different times), and locations either belong to or do not belong to other companies (e.g., third-party contract manufacturers, other tenants, customers, or subscribers of SCMS). For example, the initial secure asset provisioning process may occur to expedite manufacturing requirements and comply with government regulations. For example, Tier-1 manufacturers of V2X devices can provision OBUs with enlistment certificates. Additionally, pseudonymous certificates and other data can be provisioned after the unit is installed in the vehicle located at the original equipment manufacturer (OEM) to create a fully functional OBU.

The fact that the secure asset provisioning process can occur in different locations can introduce problems that previous systems could not handle.

For example, to provision secure assets in different locations, some systems may allow secure assets to be communicated between locations. However, it can cause delays in the manufacturing process, as certificates must first be requested and must be communicated to each other prior to installation.

Also, unlike existing X.509 certificates, V2X enlisted certificates and pseudonymous certificates do not contain the identity of the end entity in question. Therefore, there is an additional challenge in matching the right security assets to the right V2X devices. This is especially true when secure assets are provisioned in different locations.

In addition, in the existing SCMS, each SCMS is configured to deliver specific OBU/RSU information (eg, configuration information) to the V2X device along with the correct security assets. Therefore, existing SCMS can be used when an entity intends to provide user information only by one specific entity (eg, a tenant or client of SCMS). Therefore, any entity that provides customer information needs its own customized SCMS, which is expensive and does not scale well.

A multi-step provisioning and multi-tenant secure provisioning system including CMP, SMS, and SCMS with Virtual Enrollment Authorization (collectively referred to as “enhanced SCMS”) as described herein can solve the technical problems disclosed above. .

Enhanced SCMS can be used by multiple entities (e.g. multiple tenants, clients, customers and subscribers), can provide unique shaping capabilities to each entity, and can be used by distributed computerized devices (e.g. V2X or C2X devices) to the entity. - Can provide unique updates.

Exemplary entities are Tier-1 manufacturers (entities that manufacture V2X or C2X devices), OEMs (entities that provide devices to consumers or combine multiple V2X or C2X devices into a larger product, such as a vehicle), and traffic management centers. (TMC) (an entity that uses or manages RSUs). In various embodiments, an entity may be a combination of a Tier-1 manufacturer, OEM, and/or traffic management center.

According to various embodiments, the enhanced SCMS has the ability to provide multi-tenant operations by associating a computerized device to a particular tenant (eg, client, customer, subscriber) or dispatch at the time of enrolment.

The enhanced SCMS as described herein provides a V2X device with an enrolment certificate during the first step of provisioning via CMP and performing additional steps of provisioning after identifying the device via CMP. Step provisioning can be provided.

In various embodiments the enhanced SCMS may store information to identify the device at a later stage in the SMS database and may store each device and the final entity provisioning the device as described in more detail below with reference to FIGS. 4-6. can be further related. Also, after the enrollment certificate is provisioned to the device, the device can be associated with an initial provisioning state.

For example, a Certificate of Enrollment could be provisioned to a device at the manufacturing stage of the device (eg by a Tier-1 manufacturer). At this stage, the enhanced SCMS may request a device identifier (eg numeric or alphanumeric code, serial number of the device microprocessor, etc.) and will not provision an enrollment certificate until the device identifier is received.

When the device identifier is received, the enhanced SCMS may store the received device identifier and associate the device identifier with the enrollment certificate provisioned for the device and/or with the end entity provisioning the device.

In certain embodiments, an aftermarket device may be included in the SMS database even if an enrollment certificate has already been provisioned on the device. As described herein, an aftermarket device may be a device not manufactured by a Tier-1 manufacturer and/or a device manufactured by an entity that does not use enhanced SCMS. When an aftermarket device is added to the SMS database, the aftermarket device can be associated with a status indicating that it is ready to be provisioned by the enhanced SCMS.

In some embodiments the enhanced SCMS can identify the type of device and/or the function of the device. For example, the type of device may be determined through communication with the end entity that provisions the device identifier and/or secure asset to the device. In various embodiments the device type can be used, for example, to determine compatible security assets to provision and to determine the number of security assets to provision.

For example, some devices have more physical security than others. Devices with enhanced physical security are less likely to be stolen or damaged. This allows a larger number of certificates to be provisioned to physically more secure devices, since secure assets are less likely to be disclosed if the device is compromised.

Fewer certificates are also useful for devices that are physically less secure because when a device runs out of provisioned security assets, it can "top-off" (i.e. acquire more) security assets by contacting the enhanced SCMS. can do.

When fewer secure assets are provisioned, devices are charged more frequently. Thus, if the device is damaged, it is terminated or handled when connected to "charge" to a localized or enhanced SCMS. Therefore, the more frequently a device is charged, the more likely it is to deal with a device that is more likely to be damaged.

In some embodiments, the second step of provisioning for the V2X device may occur when the pseudonym and/or application certificate is provisioned to the V2X device at the OEM (eg after being combined with another device in the vehicle). At this stage, the device identifier may be received from the V2X device and the enhanced SCMS may use the device identifier to identify the V2X device and based on the identified device (e.g., based on a previously provisioned enrollment certificate), the device Provision pseudonyms and application certificates (based on the physical security level for

In some embodiments, in addition to the device identifier, the enhanced SCMS may also retrieve other data from third parties, such as test data indicating that the device has been properly installed. Based on the device identifier and verifying correct installation, the enhanced SCMS can provision pseudonyms and/or application certificates.

As further described herein, the enhanced SCMS provides SMS (alternatively, an entity management system) to tenants (eg end entities) and local policy files containing information specific to each end entity within the V2X ecosystem. (LPF) to provide multi-tenant operation.

For example, customized workflows can be created and customized configurations can be managed by end entities via a Subscriber Management System (SMS, also referred to herein as Entity Management System). SMS operates to manage tenants and tenant-related information, some of which can be sent to tenants' OBUs, RSUs, and TMC devices (TMCD).

In a specific embodiment, shaping information for each tenant of a plurality of tenants may be stored as an LPF element or data field for the corresponding tenant. For example, LPF stores data per tenant. For example, the LPF stores information relating to the type or class of computerized device associated with the tenant, but not information for a specific end entity or specific computerized device requiring a certificate.

Elements include, for example, the initial provisioning amount (i.e. the amount of certificates to be initially provisioned on the tenant's devices), cryptographic keys and certificates, connection rights (i.e. information that identifies the connection rights used by the tenant), and backend services to the tenant. It may include, but is not limited to, information such as an indication of dedicated hardware used to provide quality of service (QoS) levels.

In various embodiments, the initial provisioning amount indicated in the LPF for a tenant may be expressed as a number of certificates of a particular type (eg, 10,000 pseudonym certificates) or a period (eg, 6 months of supply of certificates).

According to some embodiments, the LPF for a given tenant depends on the validity period for the certificate (eg, the validity period of the certificate), the number of certificates an entity may possess, the overlapping period for the certificate, and the duration for which future certificates will be valid (eg, initial provisioning , how long the certificate will be valid in the future), and an indication of how long the tenant should request certificate charging (how long an end entity will wait to use the certificate before requesting additional certificates).

LPFs can be customized using customized workflows and customized configurations, and LPFs can be sent to V2X devices to customize the operation and/or configuration of V2X devices. For example, customerized workflows and/or customerized configurations must be received and stored to provision information and security assets (e.g. enrolments to use, customerization information to add to secure assets, security assets to provision devices) of customerized quantity, etc.) can be determined.

In various embodiments, the LPF may be installed in a computerized device that requires a certificate, such as a V2X device, for example. Through this, the final entity may customize the process performed by the V2X device and/or provide a customized interface for the V2X device.

For example, the LPF may instruct the V2X device to connect to a specific entity's server (eg, via a customized resource location identifier (URL)) and/or to a specific SCMS. As a further example, the LPF may allow a V2X device to download a limited amount of secure assets or define the lifetime of a certificate downloaded by a V2X device (eg 1 week instead of 3 years).

In some embodiments, LPFs may also include custom workflows and/or custom configurations based on the type of device being provisioned as a secure asset. For example, using an entity management system, an end entity can specify the number of security assets to provision to devices of various types, and custom configurations can be stored within the entity's LPF, and security assets to provision when a device requests a security asset. LPF is used to determine the number of

Additional functions that can be performed by the enhanced SCMS include, for example, provision of virtual registration rights that can be accessed by V2X devices; creation of user accounts for each end entity in SCMS; Creation of new V2X device types in SCMS; Verification of device types approved by the Department of Transportation (DOT) or other approving entity; Obtaining registration or other types of public keys (eg, signing/encryption keys, Advanced Encryption Standard (AES) Butterfly Key Extensions, etc.); Return of public key, LPF and Local Certificate Chain File (LCCF) for aftermarket devices; Return registration authorization URL for final programming of field devices; device tracking based on device identifier; provisioning of aftermarket devices;

In various embodiments, the LCCF may be a binary encoding array of certificates generated by the enrollment authority for publication to the end entity.

1 is a diagram illustrating one example of a method performed in a secure provisioning system consistent with disclosed embodiments. The illustrated method may begin at step 100 when a customized account for an entity is created in the entity management system of the enhanced SCMS. Additionally, in some embodiments, for the purposes of the embodiment described with respect to FIG. 1, the end entity may be a Tier-1 manufacturer of V2X devices.

In some embodiments the enhanced SCMS may create an account for an end entity based on receiving a request from the end entity. The account creation request may include, for example, an identifier of the end entity, information about the end entity, the type of end entity (eg, Tier-1 manufacturer), a security asset associated with the end entity, and the like.

In step 110, the enhanced SCMS may register the device type in the CMP of the enhanced SCMS. For example, a device type registration request may be received from an end entity via an account or from an administrator of an enhanced SCMS. In some embodiments the device type registration request may include an identifier of the device type or a security asset associated with the device type. An enhanced SCMS may register a device type by, for example, storing an identifier of the device type in an SMS database.

In step 120, the enhanced SCMS may check whether the device type has been approved by the authentication entity (eg, DOT). For example, the SCMS may send identifiers and/or security assets to the server associated with the authentication subject for request validation and/or compare the identifiers and/or security assets against a list of authorized device types stored within the SMS database. The SCMS may then store an indication of whether the device type has been verified, for example in an SMS database.

In step 130, the SCMS may obtain a public key for the device (eg, enrollment certificate public key, signing key, encryption key, AES butterfly key extension, etc.) and obtain or generate an identifier for the device. For example, the public key may be received at the device or the end entity may access its account through the entity management system and enter the public key and/or identifier. The device's public key and/or identifier may be stored within the SMS database.

At step 140, based on the public key obtained at step 130, the enhanced SCMS may return the enrollment certificate to the end entity to provision the device and/or the device itself. In some embodiments the enhanced SCMS may also return registration authority URLs and specific configuration data to the device for final programming. For example, the registration authority URL is unique to and/or customized by the end entity (through the entity management system). As a further embodiment, the registration authority associated with the URL may be a virtual registration authority associated with the SCMS of the enhanced SCMS.

In various embodiments the enhanced SCMS receives a public key from a computerized device requiring a certificate. For example, enhanced SCMS will receive only the registry public key, or enhanced SCMS will receive the registry public key and other application/pseudonym public keys. Enhanced SCMS returns only the Enrollment Certificate (with other data such as LPF), or Enhanced SCMS also returns the Application/Pseudonym Certificate depending on the supplied public key received from the device.

In certain embodiments where the computerized device is an aftermarket device, the enhanced SCMS can receive a public key for the aftermarket device and returns the public key, LPF, LCCF and other data to the aftermarket device. According to certain embodiments, the download of the LPF and LCCF for the computerized device is performed via a Representation State Change (REST) service call and does not include a registration certificate (eg, signed message).

For all other REST service calls, the SCMS host in Enhanced SCMS can perform a lookup to see if a particular enrollment certificate on a device is owned by or associated with a particular tenant. That is, cryptographic validation can be performed to ensure that these service calls are allowed. For LPF and LCCF downloads, the tenant identifier (ID) in the URL, routing, HTTP headers, or other mechanism is used to determine which file to serve to the computerized device. The LCCF can be consistent for all tenants of the enhanced SCMS (i.e. all certificates included), but the LPF is different per tenant.

For other service calls, the computerized device and certificate management are securely managed, even though a single enrolment authority (e.g., a virtual enrolment) or a single set of SCMS backend components handles the different directions via a strong cryptographic link.

At step 150 the enhanced SCMS may set the state of the device to Initial Provisioned or Provisioned if the device is an aftermarket device (e.g., in the SMS database), and when the device is provisioned as described below with respect to FIG. A device can be tracked for further provisioning by an OEM or traffic management center at a later stage of the process.

2 is a diagram illustrating one example of a method performed in a secure provisioning system consistent with the disclosed embodiments. The illustrated method may begin at step 200 when a customized account is created for an end entity in the enhanced SCMS. In various embodiments user accounts may be created and/or managed through the enhanced SCMS entity management system.

Additionally, in some embodiments, for the purposes of the embodiment described with respect to FIG. 2, an entity may be a traffic management center or OEM that operates a V2X device and/or operates a product incorporating one or more V2X devices.

In another embodiment, an entity may be a Tier-1 manufacturer of V2X devices when a Tier-1 manufacturer ships a partially or fully provisioned device to an OEM. End entities may also be USDOT or other accrediting entities and are used to create and manage a database of authorized devices issuing certificates.

In some embodiments the enhanced SCMS may create an account for an end entity based on receiving a request from the end entity. The account creation request may include, for example, the identifier of the end entity, information about the end entity, the type of end entity (eg OEM or traffic management center), and security assets associated with the end entity.

In some embodiments creating an account for an end entity may include creating one or more default LPFs for the entity. For example, different basic LPFs may be associated with different device types.

In step 210, the enhanced SCMS may receive an LPF shaping request. For example, an LPF shaping request could be a workflow shaping request for a specific device type, a request to set the URL of registration rights, a request to change or set geographic restrictions (e.g. geographic coordinates at which the RSU can operate), a request to shaping a charging policy (e.g. change the number of security assets to be provisioned, set the types of authorized security assets, etc.), etc.

In some embodiments the charging policy may be used to determine how to respond to charging requests as described with respect to FIG. 3 below. In further embodiments, the charging policy may be set based on the device type, the application certificate associated with the device and/or the location of the device.

In step 220, SCMS may receive the hash of the registration certificate or the hash of the initial certificate request from the V2X device through the CMP and the identifier of the V2X device. In some embodiments the hash and identifier may be received in step 200 via the account created for the end entity.

In some embodiments the enrollment certificate may be the enrollment certificate returned to the device by the enhanced SCMS at step 140 as described above. In other embodiments the device may be an aftermarket device and the enrollment certificate may not have been provided by the enhanced SCMS.

In some embodiments, the identifier may be an identifier received or generated by the enhanced SCMS in step 140 as described above, and the enhanced SCMS may identify the type of V2X device and / or V2X device based on the identifier of the V2X device.

At step 230 the enhanced SCMS may return the public key bundle, LPF and LCCF to the device. In some embodiments the information returned to the device may be determined based on identifying the device in step 220 .

For example, the returned LPF may correspond to the LPF for the device type selected and customized by the final entity associated with the V2X device. Based on returning information to the V2X device, the enhanced SCMS can set the state of the device to Full Provisioning or Partial Provisioning.

In various embodiments the provisioned device state indicates that the device has its enrollment certificate, pseudonym/application certificate and other files (such as LPF and LCCF for example). A partially provisioned device state can be used to indicate that the computerized device has only some of this data.

In some embodiments the enhanced SCMS may maintain a count of the number of provisioned devices associated with the enhanced SCMS and/or each final entity, and may update the count based on setting the state of the provisioned device.

For example, enhanced SCMS can use the number of provisioned devices to ensure that the number of provisioned devices does not exceed a pre-determined production run size. Thus, enhanced SCMS can ensure that there is no unauthorized overproduction.

In step 240, the enhanced SCMS may receive a request for managing distributed devices. In some embodiments, a request to manage a deployed device may be a request to shape the LPF after the device is deployed. For example, the LPF configuration request may be a request to change or set geographic restrictions, a request to change the number of security assets to be provisioned, and the like.

After the LPF is updated, the enhanced SCMS can send the updated LPF to the appropriate device the next time the device connects to the enhanced SCMS. For example, a device connects to the enhanced SCMS to request charging of a secure asset as described with respect to FIG. 3 .

3 is a diagram illustrating one example of a method performed in a secure provisioning system consistent with the disclosed embodiments. An exemplary method may begin at step 300 when a hash of an initial pseudonym provisioning request is received at the enhanced SCMS. In various embodiments, the hash of the initial pseudonym provisioning request may be received from a V2X device provisioned through enhanced SCMS or an aftermarket V2X device not provisioned through enhanced SCMS.

In some embodiments, the hash of the initial pseudonym provisioning request may be included as part of the request to top up the secure asset in the V2X device.

In further embodiments, a content delivery network (eg, see content delivery network 412 of FIG. 4 discussed below) may be associated with a secure provisioning system. The content delivery network may include a distributed network of devices capable of storing and/or obtaining secure assets, and may allow V2X devices to charge secure assets from devices in physical proximity to the V2X devices (e.g., to reduce network latency). to reduce).

In step 310, the enhanced SCMS may check whether the device has been authenticated. For example, the enhanced SCMS may access information related to the account of the end entity associated with the V2X device to determine whether the device is authenticated and active. As shown in Figure 3, step 310 may confirm that the computerized device has been approved.

In step 310, if the computerized device is not authorized (eg, stolen, malfunctioning, disabled, etc.), the device is denied charging. Verification of authorized devices in step 310 ensures the secure intent of proper and authorized operation of the computerized devices in the ecosystem. Enhanced SCMS does not provide certificates to unauthenticated devices. The device may not be approved due to payment failure, theft, cancellation status, etc.

In various embodiments, an end entity may change the state of a V2X device associated with the end entity between active and inactive. For example, if a V2X device is reported stolen or otherwise compromised, the end entity changes the state of the V2X device from active to inactive.

If it is confirmed that the V2X device is active in step 320, the enhanced SCMS may provide charging of the security asset in step 330. In some embodiments, SCMS may provide charging of secure assets based on a charging policy set by the end entity associated with the V2X device. For example, the final entity may designate the number of security assets to be provisioned to the V2X device as described above and/or the type of security asset authorized to be provisioned to the V2X device.

Additionally, in some embodiments, the enhanced SCMS may provide updated LPFs to V2X devices when appropriate. In a further embodiment the enhanced SCMS directs the V2X device to query the charge of the secure asset over the content delivery network by determining which device is physically closer to the V2X device and instructing the V2X device to retrieve the charge from the nearby device. can do.

If the V2X device is not confirmed to be active at step 320, the enhanced SCMS may not provide charging of the secure asset at step 340, but instead a custom non-established end entity associated with that device (e.g., via CMP). You can follow the verification workflow. For example, the enhanced SCMS sends a shutdown request to the V2X device, retrieves GPS coordinates from the device, and provides an updated LPF to the V2X device.

In some embodiments, the functionality described herein may prevent unauthorized or incorrect provisioning of V2X devices. Public safety vehicles, for example, have a unique function in the V2X ecosystem that controls intersection traffic signals. The functions described above can ensure that certificates with these functions are issued only to public safety vehicles in order to maintain the overall correct operation of the V2X ecosystem.

In a further embodiment the enhanced SCMS provides re-listing functionality. In some cases, field devices may need to be reset to factory “default” provisioning where all keys and data originally provisioned are erased. To re-enroll these devices, the enhanced SCMS can use a multi-step process to securely re-provision these devices to prevent re-enrollment of unauthorized devices. For example, enhanced SCMS establishes a secure communication path to a known end location, such as an OEM's service bay. Mutually authenticated transport layer security can be used to establish these secure communication paths.

The enhanced SCMS may then request to retrieve the device's microprocessor serial number or other permanent identifier from the device, along with a new enrollment key certificate signing request. The enhanced SCMS can then verify that it has previously provisioned the device with a persistent identifier. If Enhanced SCMS can verify this, Enhanced SCMS returns an Enrollment Certificate along with other device provisioning information such as LPF, etc. An enhanced CMS can maintain a state record indicating that a device has been re-enrolled. The device may then use the SCMS protocol to request an alias/application certificate bundle.

Depending on the configuration settings of the enhanced SCMS, SCMS uses a flexible provisioning mechanism to download only those that are entitled to receive to the device. This allows the OEM and/or its service site to be queried to see if re-enrollment provisioning has been approved. These additional checks are performed in the case of malicious activity or re-listing of high-value entities (e.g. police cars with special capabilities to control intersection lights).

One example of a V2X system is used to illustrate these new capabilities, but it could be used, for example, in European C-ITS car-to-vehicle (C2C) and car-to-infrastructure (C2I, C2X) systems or other IoT devices such as intelligent medical devices. there is.

4 is a diagram illustrating one example of a secure provisioning system 400 consistent with the disclosed embodiments. The secure provisioning system 400 comprises a SCMS host 408 with virtual enrollment rights, a CMS management portal (CMP) 402, a subscriber management system (SMS) 404, an SMS database 406, one or more computerized It may include a device 410 , a content delivery network 412 and one or more deployed devices 414 .

In some embodiments, SMS 404 functions as an entity management system for managing configuration information for subscriber entities. In various embodiments, SMS 404 may operate to manage tenants and tenant-related information, some of which may be transmitted to the tenant's OBU, RSU, and TMC devices. A device 414 deployed as shown in FIG. 4 may include an OBU (eg, a vehicle with a V2X or C2X device) and/or a computerized device with one or more RSUs.

In the embodiment of Figure 4, CMP 402 may function as a subscriber portal. In certain embodiments, CMP 402 receives tenant information from a tenant (eg, a client) and CMP 402 then stores parameters from the tenant in the LPF. According to this embodiment, a separate LPF is created for each tenant and the CMP 402 is used to configure the version of the security provisioning system 400 as needed by each tenant.

For example, the tenant can determine the validity period of the certificate (e.g., the validity period of the certificate), the number of tenant's certificate devices that can be possessed, the overlapping period for the tenant's certificate, and how long the tenant's certificate will be valid in the future (e.g., the initial period of the tenant's device). provisioning, how long future certificates will be valid), and an indication of when a tenant should request certificate charging (e.g., how long an end entity will wait to use a certificate before requesting additional certificates). can

With continuing reference to FIG. 4 , the components of the secure provisioning system 400 include an enhanced SCMS that may include an SMS 404 , a SCMS host 408 with virtual enrollment authority 408 , a CMP 402 , and an SMS database 406 . form

In some embodiments, each of CMP 402, SMS 404 (eg, entity management system), SMS database 406, and SCMS Host 408 with Virtual Enrollment Authority may each have one or more processors, one or more computer-readable It may be a separate device containing a non-transitory medium or the like.

In an alternative or additional embodiment, two or more of CMP 402, SMS 404, SMS database 406, and SCMS host 408 with virtual registration authority may be combined into a single computerized device. As shown in FIG. 4 , components of the secure provisioning system 400 are communicatively coupled to other components of the secure provisioning system 400 .

In various embodiments, the SCMS host 408 with virtual registration authority provides the secure asset and verifies the hash of the secure asset as described above. In a further embodiment the CMP 402 provides interfaces for entities (eg tenants, subscribers, clients) and computerized devices (eg V2X or C2X devices) to communicate with the enhanced SCMS.

For example, CMP 402 may provide a communication interface that multiple tenants and their computerized devices may use to exchange communications with SCMS host 408 . Such communications may include, for example, provisioning requests, HTTPS POST requests, request receipt notifications, request results, deployment certificate downloads, and other messages. In additional or alternative embodiments, the SMS 404 is an entity capable of storing and/or managing accounts (eg, account information) of various entities (eg, tenants, subscribers, clients, customers) using the enhanced SCMS. It functions as a management system.

In another embodiment, the SMS database 406 stores information about enhanced SCMS. For example, SMS database 406 may store information for identifying computerized devices at a later stage and may further associate each computerized device with the final entity (eg, tenant) that provisions the computerized device. .

As further shown in FIG. 4 , device under manufacture 410 may represent a V2X or C2X device currently associated with a Tier-1 manufacturer (as described above), and deployed vehicles and RSUs may currently represent OEMs and/or traffic management It can indicate a device associated with the center.

As shown in the example implementation of FIG. 4 , content delivery network 412 may be a component of or associated with secure provisioning system 400 . The content delivery network 412 is a set of devices that can store and/or obtain secure assets and recharge the secure assets at devices in physical proximity to the deployed device 414 (eg, to reduce network latency). may include distributed networks. For example, a deployed V2X device may charge a certificate from a peripheral device by communicating through the content delivery network 412 .

5 is a diagram illustrating computerized devices 502 , 504 , 506 corresponding to multiple tenants (eg Tenant A, Tenant B and Tenant N) of a secure provisioning system consistent with an embodiment of the present invention. An SCMS enhanced in accordance with various embodiments has the ability to provide multi-tenant operations by associating computerized devices to specific tenants (eg, clients, customers, and subscribers) or distributions at the time of enrolment.

In the embodiment of FIG. 5 , there are n tenant groups and the enhanced SCMS can connect device 502 to tenant A, device 504 to tenant B, and device 506 to be the last of the n tenant groups. You can connect to the nth tenant (i.e., tenant n). As shown in FIG. 5 , this connection to the corresponding tenant of device 502 , 504 , 506 is used by device 502 , 504 , 506 to access enrollment rights to determine tenant identifier (tenant ID). This can be done by parsing each network address, path or URL.

In the embodiment of Fig. 5, URL 503 contains the tenant ID of tenant A appended to URL 503, URL 505 contains the tenant ID of tenant B, and URL 507 contains the tenant ID of tenant n. Include ID. These URLs 503, 505, 507 may be used by computerized devices 502, 504, 506 to access the registration rights of the enhanced SCMS. In an alternative or additional embodiment, a tenant ID for a tenant may be provided to device 502 , 504 , 506 upon registration by including the tenant ID prefixed with URL 503 , 505 , 507 or otherwise indicated.

In another alternative or additional embodiment, the tenant ID for the tenant may be provided to the device (eg, device 502) in the new file upon enrolment. Here, the device adds the tenant ID to a new HTTP header element, such as the 'SCMS Tenant' header element. According to various embodiments, tenant information, such as a tenant ID, may be encrypted in the message to protect the identity of the tenant associated with a given device.

6 is an exemplary workflow 600 within a secure provisioning system that includes a certificate management system (CMS) management portal (CMP) 602, SMS 604, and SMS database 606 consistent with an embodiment of the present invention. It is a diagram that represents Tenants are registered through the CMP 602 according to various embodiments. Within the CMP 602, the device owner (e.g., the owner of one of the devices 502, 504, and 506 discussed above with reference to FIG. 5) sets up an account to register the device, submit credentials for the device, and A tenant ID is given by the CMP 602.

Exemplary workflow 600 includes registering new customer information (eg, tenant or subscriber information) with CMP 602 . Workflow 600 also includes verification of the tenant's device, the intended use of the device (eg, the intended use of the tenant's computerized device), and the tenant providing the certificate document. This information is submitted by the tenant to the CMP 602 for approval. Upon out-of-band authorization by CMP 602, the tenant receives the generated tenant ID and account information. The tenant ID and account information of the tenant may be stored in SMS database 606 and subsequently retrieved from SMS database 606 by CMP 602 and SMS 604 as needed.

As shown in FIG. 6 , CMP 602 may operate to receive and shape SLA details for a tenant. In some embodiments, CMP 602 may also be operable to shape business requirement details for specific customizations required by tenants. For example, tenants can provide CMP 602 with hardware isolation for certificate generation (see e.g. the set of isolated and independent SCMS backend components 724 in FIG. 7 described below), cryptographic isolation for cryptographic operations. , hardware security module (HSM) separation for sensitive operations, unique certificate chains for authentication authorities, estimated usage per week, local policy parameters (e.g. LPF), and other SLA details for the tenant.

In workflow 600, CMP 602 submits these SLA details to SMS database 606 for storage and then notifies SMS 604 of the contract and billing service. In various embodiments, SMS 604 is configured to manage tenants and tenant-related information, some of which is stored in SMS database 606 and transmitted to tenants' OBUs, RSUs, and TMC devices.

Depending on the configuration and service level of the new tenant, backend SCMS services can be created and hardware deployed for the new tenant according to the tenant's requirements and SLA details. For example, as shown in FIG. 7 and described below, a dedicated registration authority 721 and independent SCMS backend component 724 can be deployed for Tenant N, which has a higher level of service than other tenants.

7 is a diagram illustrating an exemplary operating environment 700 for a secure provisioning system configured to support multi-tenant operations consistent with an embodiment of the present invention. As shown, an operating environment 700 includes a SCMS host 708, computerized devices 702, 704, 706 associated with multiple tenants of a group of n tenants (e.g., tenants A, B, ... N), enrollment rights ( 720, 721) and a set of SCMS backend components 722, 724.

In the exemplary operating environment 700, a single SCMS host 708 is a hardware platform with a single IP address, where the SCMS host 708 is shared among the tenants of a group of n tenants. That is, the SCMS host 708 processes initial provisioning requests 703 , 705 , 707 from computerized devices 702 , 704 , 706 . Some tenants choose to share SCMS backend components based on the level of service required and the service tier purchased (e.g. captured in a service level agreement (SLA)).

In the example of FIG. 7 , tenants A and B have chosen to use a shared set of SCMS backend components 722 . Alternatively, other tenants that require a higher service tier or have a greater need for faster provisioning of more certificates may have an SLA that gives the tenant access to a separate and dedicated SCMS backend component, which is a separate hardware component. (e.g. a separate and independent hardware component to perform cryptographic operations for a single tenant).

In the embodiment of Figure 7, Tenant N has chosen to use a separate and independent set of SCMS backend components 724. In certain embodiments, tenants A, B, . . . The parameters of each LPF for N may specify the purpose of either a set of SCMS backend components 722 or a set of separate and independent SCMS backend components 724.

As shown in FIG. 7 , each of the plurality of computerized devices 702 , 704 , 706 may submit a respective initial provisioning request 703 , 705 , 707 to the configured registration authority via the SCMS host 708 and the provisioning request (703, 705, 707) represent each tenant ID.

According to some embodiments Tenants A, B,... The tenant ID for N may be included in the routing information submitted to the SCMS host 708. That is, each computerized device 702, 704, 706 in the operating environment 700 has been registered by a particular tenant (eg, one of tenants A, B, ... N) and their respective initial provisioning request 703, 705 , 707), the tenant provides an individual tenant ID.

In various embodiments, the tenant ID may be provided within a URL (e.g., as in URLs 503, 505, and 507 of FIG. 5), routing, HTTP header elements (e.g., 'SCMS Tenant' element), or some other mechanism.

The SCMS host 708 is the single SCMS registration authority endpoint for centralized services. The SCMS host 708 receives all requests, including initial provisioning requests 703, 705, 707, parses the tenant ID from the request and performs validation (e.g. to determine the correct tenant for the enrollment certificate). for). The SCMS host 708 routes various requests to either a virtual shared registration authority 720 or a dedicated registration authority 721 .

In various embodiments, the tenant ID is added to all messages sent within the operating environment 700 after the SCMS host 708 parses the tenant ID from the initial provisioning request 703, 705, 707. According to some embodiments, the tenant ID may be obfuscated in such messages by using a hash or by mapping the tenant ID to a universally unique identifier (UUID). This mapping of tenant IDs to respective UUIDs may be stored in the SMS database 606 discussed above with reference to FIG. 6 .

This obfuscation helps to ensure privacy for messages transmitted through virtual registration rights 720 shared between multiple tenants (e.g., Tenants A and B). The tenant ID is used by the operating environment 700 to determine which key or certificate chain to use. The tenant ID also allows the registration authority 720, 721 to determine which policy parameters to adhere to for a particular request (eg one of provisioning requests 703, 705, 707).

In the operating environment 700, the SCMS host 708 may be an abstract or virtual layer above the registration authority 720, 721. The SCMS host 708 parses the tenant ID from the initial provisioning request (703, 705, 707). Devices 702 , 704 , 706 and devices external to the operating environment 700 have one SCMS URL that all tenants (eg clients) use to connect to the SCMS host 708 .

In this way, by using the SCMS host 708 to parse the tenant ID from the initial provisioning request 703, 705, 707, the operating environment 700 can determine whether certain portions of the computerized devices 702, 704, 706 are specific to a particular tenant. to ensure that snooping cannot be used to determine whether it is owned by or related to This protects the tenant's identity and personal information from any entity attempting to snoop on network traffic delivered to the operating environment 700 .

Within the operating environment 700, the SCMS host 708 parses the tenant ID from the path, URL, HTTP header, or other mechanism used for the initial provisioning request 703, 705, 707, and sends the initial provisioning request 703, 705 , 707) to the correct registration authority (e.g. shared registration authority 720 or dedicated registration authority 721).

As shown in FIG. 7 , the SCMS host 708 parses the tenant IDs for tenants A and B from the initial provisioning requests 703 and 705 and then routes these requests to the registration authority 720 based on the parsed tenant IDs. do.

Similarly, the SCMS host 708 parses the tenant ID for tenant N from the initial provisioning request 707 and then routes the request to the dedicated registration authority 721 based on the parsed tenant ID for tenant N. In an alternative or additional embodiment there may be a single registration authority routing requests to the embedded tenant ID in internal messages exchanged between a single SCMS host 708 and a single registration authority.

In another alternative or additional embodiment there may be a completely independent internal virtual registration authority component that handles the initial provisioning request (703, 705, 707) and then routes the request to the correct backend component.

In the embodiment of Figure 7, the set of shared SCMS backend components 722 are components that are shared between Tenants A and B. The shared set of SCMS backend components (722) are Shared Alias Authentication Authority (740), Shared Connection Authority 1 (750), Shared Connection Authority 2 (760), and Shared Enrollment Authority to provide certificates and connection values to Tenants A and B. (730).

As shown in FIG. 7, the separate and independent set of SCMS backend components 724 are the components dedicated to fulfilling certificate requests from a single tenant, Tenant N. The independent set of SCMS backend components 724 include Independent Authentication Authorization 741, Independent Association Authorization 1 (751), Independent Association Authorization 2 (761) and Independent listing certification authority 731 included.

In the embodiment of FIG. 7 , Tenant N has a higher level of service (eg, higher service tier or service priority) than Tenants A and B, and as a result, Tenant N is provided with an independent set of SCMS backend components 724. serviced In a particular embodiment, a service tier is associated with each tenant of the group of n tenants, and each tenant's service tier corresponds to one of multiple tiers ranging from the lowest service level to the highest service level.

In certain embodiments, the dedicated registration authority 721 may also use a shared SCMS backend component 722. That is, an embodiment may create a dedicated registration authority 721 for Tenant N that provides a unique interface to Tenant N, but does not share the shared SCMS backend component 722 used by Tenant N with other tenants (e.g. Tenant A and B) can be shared with.

In an alternative or additional embodiment, the dedicated enrollment authority 721 may access a different set of shared SCMS backend components 722 depending on the product type of the tenant's computerized device requiring the certificate. That is, a given tenant's OBU may use one set of shared SCMS backend components 722 and the RSU for that tenant may use another set of shared SCMS backend components 722.

According to some embodiments, higher service layers may provide tenant N access to dedicated registration rights 721 that are not shared or used by other tenants. In one such embodiment, a dedicated registration authority 721 may be created and shaped for Tenant N based on the tenant's upper service layer such that the dedicated registration authority 721 provides a unique interface to Tenant N. In some embodiments, tenant N with a higher service tier is provided access to a separate and independent backend SCMS component 724 that is not shared with other tenants.

In additional or alternative embodiments, other tenants with higher service tiers and dedicated enrollment rights may access different shared SCMS backend components 722 depending on the product type for the tenant's device for which a certificate is required. That is, an OBU device for a tenant may use one of the shared SCMS backend components 722 and an RSU device may use another shared SCMS backend component 722.

8A and 8B together are swim lane diagrams illustrating a process 800 for securely providing credentials, such as certificates, consistent with an embodiment of the present invention. In process 800, virtual enrollment rights are used to provide certificates to multiple tenants.

In particular, the example process 800 shown in FIGS. 8A and 8B includes the exchange of requests and responses between enhanced SCMS components to provide a certificate to a V2X device, such as device 810 . However, the embodiments disclosed herein are not limited to multi-tenant operation for V2X devices and the disclosed principles may be applied to other types of computerized devices, computer-controlled devices such as C2X devices.

That is, the enhanced SCMS functions as a V2X or C2X certificate management service. The example process 800 shown in FIGS. 8A and 8B provides certificates to 2X devices in a multi-tenant environment. That is, FIGS. 8A and 8B illustrate the components of an exemplary enhanced SCMS in the context of a V2X flow of request and response.

In various embodiments, some or all of the process 800 or represented operations may be performed by a hardware-only system through code running on a computer system (which may include one or more processors or one or more computing subsystems) or a hybrid of the two. performed by the system. As shown across the top of FIGS. 8A and 8B, the entities involved in process 800 are device 810, SCMS host 808, virtual registration authority 820, connection authority 850, 860, and pseudonym authentication authority 840. ).

In various embodiments these entities communicate with each other to perform tasks as part of a process 800 for providing certificates, as described below with respect to FIGS. 8A and 8B and throughout this specification. In some embodiments device 810 is a V2X device located at a manufacturer (not shown).

In certain embodiments, the SCMS host 808 may host the virtual registration authority 820. Process 800 may be performed by an enhanced SCMS communicating with a device (eg, device 810 ) submitting a provisioning request.

The enhanced SCMS includes virtual registration authority 820, one or more connection authority 850, 860 and pseudonym authentication authority 840. The exemplary CMS includes one or more application platforms that run applications for virtual registration authority 820 . This application platform is communicatively coupled to one or more computer engines that perform cryptographic operations required by virtual registration authority 820 .

The one or more application platforms include one or more virtual machines (VMs) or one or more hardware platforms (eg, servers, computers, or other computer hardware capable of hosting and executing software applications). The enhanced SCMS also includes one or more VMs communicatively coupled to one or more computer engines that execute the enrolment certification authority (not shown) and perform the cryptographic operations required by the enrolment certification authority.

The enrolment certificate authority is operable to generate and conditionally send the enrolment certificate to the virtual enrolment authority 820 . The embodiment of the CMS host hosting the virtual enrollment authority 820 of FIGS. 8A and 8B includes one or more servers that run applications for the pseudonym authentication authority 840 and perform cryptographic operations required by the pseudonym authentication authority 840 . It further includes one or more VMs communicatively coupled to the computer engine.

The pseudonym authentication authority 840 is operable to generate and conditionally send a pseudonym certificate to the virtual enrollment authority 820 . The enhanced SCMS also includes one communicatively coupled to one or more computer engines that execute the first and second connection authorities 850, 860 and perform the cryptographic operations required by the first and second connection authorities 850, 860. The above VMs are also included.

Each application for the first connection authority 850 and the second connection authority 860 is operable to create a connection value and conditionally send the connection value to the virtual registration authority 820 .

The enhanced SCMS including the virtual entitlement 820 shown in FIGS. 8A and 8B is one or more computer engines that run applications for the virtual entitlement 820 and perform cryptographic operations required by the virtual entitlement 820. It may also include one or more application platforms communicatively coupled to.

The enhanced SCMS may further include one or more application platforms communicatively coupled to one or more computer engines that run applications for the Enrollment Certificate Authority and perform cryptographic operations required by the Enrollment Certificate Authority, which transmit the Enrollment Certificate Authority. It is operable to create and conditionally transmit to virtual registration authority 820.

The enhanced SCMS may further include one or more application platforms communicatively coupled to one or more computer engines that execute applications for the pseudonym authentication authority 840 and perform cryptographic operations required by the pseudonym authentication authority 840. , which is operable to generate pseudonymous certificates and conditionally send them to the Virtual Enrollment Authority 820 .

The enhanced SCMS also includes one or more application platforms communicatively coupled to one or more computer engines that execute applications for the first connection authority 850 and perform cryptographic operations required by the first connection authority 850. can do.

Finally, the enhanced SCMS includes one or more application platforms communicatively connected to one or more computer engines that execute applications for the second connection authority 860 and perform cryptographic operations required by the second connection authority 860. can also contain Connection authority 850, 860 is operable to generate and conditionally send a connection value to virtual registration authority 820.

In another embodiment, the enrollment certification authority is operable to generate an enrollment certificate in response to receiving a request for an enrollment certificate from the virtual enrollment authority 820; the pseudonym authentication authority 840 is operable to generate a pseudonym certificate in response to receiving a request for a pseudonym certificate from the virtual enrollment authority 820; and the first connection authority 850 and the second connection authority 860 are operable to generate a connection value in response to receiving a request for a connection value from the virtual registration authority 820 .

In an alternative or additional embodiment, the enrollment certificate authority is operable to generate an enrollment certificate in response to receiving a request directly from the computerized device. That is, there are various ways to obtain a certificate, and the exemplary process 800 shown in FIGS. 8A and 8B is merely an exemplary method.

As shown in the embodiment of FIG. 8A , process 800 begins with operation 805 where device 810 (e.g. end entity V2X device) submits an initial provisioning request for a pseudonym certificate to SCMS host 808. do. As shown, operation 805 may include device 810 submitting an HTTPS POST command using a URL that includes a tenant ID for tenant A.

In some embodiments device 810 is provided with a URL upon registration and the initial provisioning request in operation 805 is provided directly from device 810 and as shown in FIG. 8A the provisioning request is embedded in a defined path and URL. It may be an HTTPS POST command with the URL and port number of the virtual registration authority 820 with the registered tenant identifier (ID).

This allows the SCMS host 808 to identify the tenant and route the request to the correct virtual registration authority 820 without having to change or reconfigure the device 810 or process 800.

In some embodiments, the provisioning request may indicate configuration details about the tenant, required application rights (eg, indicated by a provider service identifier (PSID) value), and validity information about the certificate. This information can be delivered via routes or HTTPS headers. For example, a key value pair for the 'SCMS Tenant' header element may include a 'Tenant A' value. The privacy of this information may be protected within the transport layer security (TLS) handshake between device 810 and SCMS host 808.

In additional or alternative embodiments, a provisioning request may be sent to a domain name system (DNS) where two different URLs or paths resolve (eg, point) to the same server or webpage. That is, using DNS, requests from two different tenants representing the respective tenant IDs of the two tenants may have different paths or URLs, but both resolve to the same enhanced SCMS and the same SCMS host 808 .

Within a V2X environment (e.g., as specified by Anti-Collision Metrics Partners LLC (CAMP)), Enrollment Certificates are required to include Application Authority (identified by PSID value) and allowed geographic area for each RSU and OBU. An RSU or OBU device can only obtain an application certificate and/or pseudonym certificate corresponding to the PSID value included in the enrollment certificate.

After the device 810 sends a provisioning request to the SCMS host 808 with the URL for the virtual registration authority 820 in operation 807, the SCMS host 808 parses the tenant ID from the request. Accordingly, the request may be routed to the virtual registration authority 820 that handles that tenant.

In this way, process 800 can serve multiple tenants with a single SCMS host 808 and handle custom configurations. In operation 807 in the embodiment of Figure 8A, the SCMS host 808 parses the Tenant ID for Tenant A from the request. In certain embodiments, the provisioning request includes meta data representing the Tenant ID for Tenant A. Here, the tenant ID can be a hash, UUID, or other type of unique ID that does not reveal the identity of the tenant.

Then in operation 809 the SCMS host 808 verifies the tenant against the enrolment certification authority to determine if a separate enrolment certification authority exists for the tenant. According to a particular embodiment, the download of the LPF and LCCF to device 810 is accomplished through a Representation State Change (REST) service call and does not include a registration certificate (eg a signed message).

For all other REST service calls in process 800, SCMS host 808 determines that a particular enrollment certificate for device 810 is owned by or associated with a particular tenant (e.g., Tenant A in the embodiment of FIG. 8A). A search can be performed at action 809 to see if it is. Cryptographic validation can be performed to ensure that these service calls are allowed.

For LPF and LCCF downloads, the tenant ID for tenant A in a URL (as shown in FIG. 8A), path, HTTP header, or other mechanism may be used to determine the file to be served to device 810. A downloaded LCCF can be consistent across all tenants (i.e. including all certificates).

However, the downloaded LPF may be different for each tenant. For other service invocations of process 800, the strong cryptographic connection is a single registration authority (e.g., virtual registration authority 820) or a single set of SCMS backend components (e.g., the shared SCMS described above with reference to FIG. 7). It is possible to ensure that the device 810 and certificate management are safely managed even if the set of backend components) are handled by different policies.

The primary role of the enrolment certificate authority is to issue a certificate of enrolment to an end user device, e.g. The enrollment authentication authority interacts directly with the SCMS host 808 to issue the requested enrollment certificate to the device 810 .

In additional or alternative embodiments, the Enrollment Authentication Authority is a device 810 capable of acting as a proxy between the enhanced SCMS and the computerized device requiring the Enrollment Certificate, requesting the Enrollment Certificate and the computerized device requiring the Enrollment Certificate. You can communicate directly with a server that acts as a proxy for clients.

For example, the Enrollment Certification Authority may communicate directly with the device 810 at the manufacturer's location (eg, the manufacturer's factory).

A Certificate of Enrollment is a public key certificate that identifies its owner as an authorized participant within an ecosystem (e.g. USDOT V2X ecosystem) where all participants must share a valid Certificate of Enrollment. Approved participants may also receive pseudonymous certificates that enable communication and operation of devices 810 within the ecosystem (e.g., enable communication and operation between vehicles and roadside infrastructure in USDOT's V2X ecosystem example). there is.

In various embodiments, the verification performed at operation 809 includes the SCMS host 808 decrypting and verifying the provisioning request. This includes verifying the signature, checking the revocation status of the device 810 to which the certificate is destined (eg, a computerized device) using a list of disapproved devices (eg, a blacklist), and verifying that the requestor (eg, the device 810) is using the SCMS It includes determining whether the host 808 is authorized to request a certificate. For example, operation 809 includes determining whether a user of the manufacturer is an authorized user (eg, part of an employee).

In some embodiments, the SCMS host 808 may also determine in step 809 whether the computerized device (eg product) for receiving the certificate has been approved for use. In some embodiments, a list of approved devices (eg, a whitelist) is provided by a regulatory authority and the provisioning controller may be used to make this determination.

Next at step 811 the SCMS host 808 responds back to the device 810 with a general acknowledgment (ACK) message confirming that the provisioning request has been received.

After the request for the certificate is confirmed in step 813, the SCMS host 808 initiates a provisioning request for Tenant A that includes the Tenant ID. In Figure 8a, the tenant ID is implemented as a UUID.

In operations 815-822, the connection authority 850, 860 interacts directly with the virtual registration authority 820 to fulfill the request for the connection value. In step 815 the provisioning request is received by the virtual registration authority 820 and the virtual registration authority 820 sends a request for the first set of connection values LA1 to the connection authority 1 850 .

In response to receiving the request for the first set of connection values at step 816, connection authority 1 850 forwards the first set of connection values to virtual registration authority 820. Connection Right 1 850 may transmit the first set of previously created connection values (i.e. pre-generated connection values) or Connection Right 1 850 may transmit the first set of connection values in case the values are not pre-generated. Create and transmit the second set.

At step 817 a first set of associated values is received at virtual registration authority 820 . In step 819, the virtual registration authority 820 transmits a request for the second set of connection values LA2 to the connection authority 2 860.

Next, as shown in FIG. 8A , in response to receiving the request for the second set of connection values in step 821 , connection authority 2 860 transmits the second set of connection values to virtual registration authority 820 . In various embodiments connection authority 2 860 may transmit a pre-generated second set of connection values, or alternatively connection authority 2 860 may generate and transmit a second set of connection values. At step 822 a second set of connection values is received at virtual registration authority 820 .

In certain embodiments, the connection authority 850, 860 shown in FIGS. 8A and 8B may link the certificate requestor's identity (ie, a unique identifier for the certificate requestor's device) to a pseudonym certificate issued for revocation purposes. That is, connection authority 1 (850) and connection authority 2 (860) respectively connect the first and second connections as unique identifiers of the certificate requestor device to the pseudonym certificate issued by pseudonym authentication authority 840 as part of process 800. Each provides a set of values.

Connection authority 1 (850) and connection authority 2 (860) receive connection value requests sent from virtual registration authority (820) in operations 815 and 819, and then connect to virtual registration authority (820) in operations 816 and 821. Provide connection value request.

Still referring to FIG. 8A , in step 823 the SCMS host 808 checks the policy parameters for tenant A and generates a request for the correct pseudonym certificate from the pseudonym authentication authority 840 according to the policy parameters. In an embodiment, operation 823 includes the SCMS host 808 using the tenant ID parsed from operation 807 to determine which policy parameters to adhere to for a particular pseudonym certificate request. For example, step 823 includes retrieving local policy parameters for device 810 from the device's LPF.

In step 825, the virtual registration authority 820 transmits a request for a pseudonym certificate to the pseudonym authentication authority 840. This request is sent as a batch of pseudonymous certificate creation requests generated by the Virtual Enrollment Authority 820 .

In step 827 a request for a pseudonym certificate is received from the pseudonym authentication authority 840 . In response to receiving the request at step 827, the pseudonym authentication authority 840 optionally uses information about Tenant A to sign the certificate using another certificate chain or key. In step 827, the pseudonym authentication authority 840 generates the requested pseudonym certificate and transmits the generated pseudonym certificate back to the virtual enrollment authority 820. At step 829 the pseudonym certificate is received at virtual enrollment authority 820 .

Next, as shown in FIG. 8B , at step 831 device 810 sends a request to SCMS host 808 to download the batch of certificates. As shown, the request sent in operation 831 may be an HTTP POST request with a URL containing the Tenant ID for Tenant A.

In operation 833 the SCMS host 808 parses the tenant ID from the batch download request. Next, in step 835, the SCMS host 808 verifies the tenant for the enrolment certification authority to determine if a separate enrolment certification authority exists for the tenant.

Next in step 837 the SCMS host 808 ensures that the policy for Tenant A is enforced. Operation 837 may include the SCMS host 808 using the tenant ID parsed from operation 833 to determine which policy parameters to comply with with the particular batch pseudonym certificate download request. For example, step 837 includes retrieving local policy parameters for device 810 from the device's LPF. After verifying that the policies for Tenant A are in effect with respect to the requested pseudonym certificate deployment, control passes to operation 839.

When the pseudonym certificate is ready in step 839, the SCMS host 808 transmits the downloaded file to the device 810 together with the pseudonym certificate. In step 841, the device 810 receives a pseudonym certificate. At this point device 810 has provisioned the pseudonym certificate and device 810 can use the pseudonym certificate and the pseudonym certificate provisioning operation is complete.

In additional or alternative embodiments, processes similar to process 800 described above may be used to provide certificates to other computerized devices, such as, for example, C2X devices.

For example, a CMS with components similar to those shown in FIGS. 8A and 8B may provide certificates to one or more on-vehicle units (OBUs), electronic control units (ECUs), roadside units (RSUs) and TMC devices. These OBUs and ECUs can be configured to be installed in vehicles, ships (eg boats), aircraft (eg airplanes and drones), spacecraft, medical devices, robots, wireless or wired communication modules and IoT devices.

Similarly, RSUs can be installed in traffic control devices (eg traffic signals), roadside content distribution systems, electronic toll systems, electronic signage devices and digital display devices (eg electronic billboards). The TMCD is operable to be installed in a governmental (eg, local, state or federal) traffic management center for use in digitally signing messages for broadcast or display by the RSU.

9 is a block diagram of an embodiment of a computer environment 901 comprising a computer system 900 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, computerized system 900 includes device 810, virtual enrollment authority 820, SCMS host 808, connection authority 850, 860, pseudonym authentication authority of FIGS. 8A and 8B, and security of FIG. It may be used to at least partially implement various components of FIGS. 1-8 , such as components of the provisioning system and components of the operating environment 700 of FIG. 7 .

For example, computer system 900 may include, among other things, SCMS host 408 with virtual registration authority, CMP 402, 602, SMS 404, 604, and SMS database 406, 606 of FIGS. 4 and 6. It can be used to at least partially implement. Also for example, computer system 900 can be used to at least partially implement SCMS host 708, registration authorities 720, 721 and SCMS backend components 722, 724 of FIG. 7, among others.

In some embodiments, a series of computer systems, similar to computer system 900, are each customized with specialized hardware and/or to implement one of the components of FIGS. 1-10 that can communicate with each other via network 935. It can be programmed as a specialized server.

In the embodiment shown in FIG. 9 , computer system 900 includes CPU 905, memory 910, input/output (I/O) device 925, hardware security module (HSM) 940, and a non-volatile storage device. It includes a number of components, such as 920. System 900 can be implemented in a variety of ways. For example, an implementation as an integrated platform (eg, server, workstation, personal computer, laptop, etc.) may include CPU 905, memory 910, non-volatile storage 920, and I/O device 925. there is.

In this embodiment, components 905, 910, 920, and 925 can connect and communicate via a local data bus and via external I/O connections (e.g., implemented as a separate data source or database system) for data storage. (930). The I/O component 925 connects to a network and/or other suitable connection, such as a direct communications connection (eg, wired or local WiFi connection), a local area network (LAN), or a wide area network (such as a WAN, cellular telephone network, or the Internet). You can connect to an external device via System 900 may be stand-alone or a subsystem of a larger system.

CPU 905 may be one or more known processors or processing devices, such as a Core™ family of microprocessors manufactured by Intel Corporation of Santa Clara, Calif. or an Athlon™ family of microprocessors manufactured by AMD Corporation of Sunnyvale, Calif. . CPU 905 may also be an ARM CPU or a proprietary CPU. Memory 910 may be one or more high-speed storage devices configured to store instructions and information executed or used by CPU 905 to perform specific functions, methods, and processes related to embodiments of the present invention.

Storage device 920 may be volatile or non-volatile, magnetic, semiconductor, tape, storage device 1120 may be volatile or non-volatile, and may be a magnetic, semiconductor, tape, optical or other tangible storage device or computer readable medium, such as It can be devices such as CDs and DVDs and solid-state devices for long-term storage.

In the illustrated embodiment, memory 910 includes one or more programs or applications 915 loaded from storage 920 or from a remote system (not shown), which when executed by CPU 905 are consistent with the present invention. Consistently perform various operations, procedures, processes or methods.

Alternatively, CPU 905 may execute one or more programs remotely located from system 900 . For example, computer system 900 may access one or more remote programs over network 935 that, when executed, perform functions and processes related to implementations of the present invention.

In certain embodiments, memory 910 includes SCMS host 408, CMP 402, 602, SMS 404, 604, SCMS host 708 with virtual registration rights shown in FIGS. 4, 6, 7, 8A and 8B. ), Enrollment Rights (720, 721), SCMS Backend Component Set (722, 724), Devices (810), Virtual Enrollment Rights (820), SCMS Host (808), Connect Rights (850, 860), and Alias Authentication Rights ( 840) may include a program 915 that performs the specialized functions and operations disclosed herein.

In some embodiments, memory 910 may also contain other programs or applications that implement other methods and processes that provide auxiliary functionality to the present invention.

Memory 910 may also be embodied in an operating system (not shown) and/or other programs not related to the present invention (not shown) that, when executed by CPU 905, perform various functions well known in the art. . The operating system may be a Microsoft Windows™, Unix™, Linux™, Apple Computer™ operating system or other operating system including a real-time operating system. The choice of operating system and the use of the operating system are not critical to the present invention.

HSM 940 may be a device with its own processor that securely creates and stores digital security assets and/or securely performs various cryptographic and sensitive operations. The HSM 940 protects digital security assets such as encryption keys and other sensitive data from attacker access. In some embodiments, the HSM may be a plug-in card or board that attaches directly to computer system 900.

I/O devices 925 may include one or more input/output devices that allow data to be received and/or transmitted by computer system 900 . For example, I/O device 925 may include one or more input devices capable of inputting data from a user, such as a keyboard, touch screen, mouse, and the like. I/O device 925 may also include one or more output devices that allow data to be output or presented to a user, such as a display screen, CRT monitor, LCD monitor, plasma display, printer, speaker device, or the like.

I/O devices 925 may also include one or more digital and/or analog communication input/output devices that enable computer system 900 to digitally communicate with other appliances and devices, for example. Other shapes and/or numbers of input/output devices may be incorporated into I/O device 925 .

In the illustrated embodiment, computer system 900 is coupled to a network 935 (eg, the Internet, a private network, a virtual private network, a cellular network, or other network, or combinations thereof), which in turn may include servers, personal computers, laptop computers, It can be connected to various systems and computer devices such as client devices. In general, computer system 900 inputs data from external instruments and devices and outputs data to external instruments and devices via network 935 .

In the exemplary embodiment shown in FIG. 9, repository 930 is a stand-alone data source external to system 900, such as a database. In other embodiments, repository 930 may be hosted by computer system 900 . In various embodiments, storage 930 may manage and store data used to implement systems and methods in accordance with the present invention.

For example, repository 930 can be used to implement the SMS databases 406 and 606 of FIGS. 4 and 6 and the LPFs and LCCFs described herein. In some embodiments, storage 930 may manage and store data structures containing status and log information for each computerized device having a certificate provisioned by secure provisioning system 400, such as FIG. 4.

Repository 930 may include one or more databases that store information and are accessed and/or managed via computer system 900 . Storage 930 is, for example, an Oracle™ database, a Sybase™ database, other relational database, or a non-relational database. However, systems and methods consistent with the present invention are not limited to separate data structures or databases, or even to the use of databases or data structures.

Skilled artisans will recognize that the components and implementation details of the system of FIG. 9 are examples presented for brevity and clarity of description. Other components and implementation details may be used.

As an implementation example, a currently existing Secure Credential Management System (SCMS) as defined by Collision Avoidance Metrics Partners LLC (CAMP) in a V2X environment is a V2X device owned or operated by a specific entity, such as a city or state transportation department. We cannot provide customized shaping capabilities for groups.

The CAMP mechanism requires a separate legacy SCMS system for each customer requiring these capabilities. The ability to provide custom configurations is desirable, but not available in the CAMP mechanism. In an existing V2X environment (e.g. specified by CAMP), the enrollment certificate must include the application authority (identified by the PSID value) and allowed geographic area (geographical area) for each RSU and OBU.

An RSU or OBU device can only obtain Application Certificates and/or Aliased Certificates that correspond to the PSID value contained in the Enrollment Certificate, and any subsequently issued Application and/or Aliased Certificates (e.g., top-off certificates) will be subject to the Enrollment Certificate. It should include the same permitted areas as the included area information.

Existing V2X environments (e.g. specified in CAMP) must perform the initial provisioning step of requesting an enrollment certificate and installing it on the RSU or OBU device in a secure and trusted programming/provisioning location that is protected from unauthorized persons such as hackers. .

The embodiments of the present invention described in connection with FIGS. 10-13 below are particularly useful in solving a series of geographically-restricted technology problems associated with roadside units (RSUs), also known as roadside equipment (RSEs).

One technical issue relates to the fact that existing RSUs and existing SCMSs (e.g. as defined by Anti-Collision Metrics Partners LLC (CAMP)) store or retain geolocation restriction information only in the RSU's Enrollment Certificate. That is, enrollment certificates are provided by the existing SCMS only while the RSU is physically connected to the existing Device Configuration Manager (DCM) system. That is, this system must be from the RSU manufacturer or other acceptable, safe and reliable programming location.

When manufacturing an RSU, the manufacturer entity rarely has all the necessary information that needs to be inserted into a certificate of operation (e.g. certificate of listing and/or application). In particular, there is no precise information describing the future geographic location (location information) of the RSU when the purchaser deploys and operates the RSU. This operational location information from the device's enrollment certificate is important because the correct operation of the RSU in a V2X environment is limited to that location information.

This means that accurate operational location information is generally only known after the device is shipped by the manufacturer to the device purchaser/owner/operator/user who places the RSU in its operating state and location, thus providing accurate information about the RSU when manufacturing and registration certificates are generated. Operating location information is unknown.

This is especially true when manufacturers produce stock RSU devices long before they are ordered, sold, and shipped to users. At the time of manufacture, manufacturers typically do not know to whom the RSU will eventually be sold and where it will operate.

As used in some embodiments described herein, the term "precise operating location information" means, for example, 900,000 square meters, 800,000 square meters, 700,000 square meters, 600,000 square meters, 500,000 square meters, 400,000 square meters, 300,000 square meters square meter, 200,000 square meter, 100,000 square meter, 50,000 square meter, 40,000 square meter, 30,000 square meter, 20,000 square meter, 10,000 square meter, 9,500 square meter, 7,000 square meter, 5,000 square meter, 3,000 square meter, 2,000 square meter , 1,000 sqm, 600 sqm, 500 sqm, 400 sqm, 300 sqm, 200 sqm, 100 sqm or 50 sqm; And these terms include geographic points such as the intersection of latitude and longitude coordinates. This area can be of any shape. A region is usually a larger area than this, such as a country or state.

Therefore, it is not possible to load an RSU with an accurate geolocation-restricted enrollment certificate at manufacture using existing systems. To address this issue, manufacturers may choose geographic areas where RSUs are likely to be sold and distributed, such as entire countries (e.g., the United States), groups of states (e.g., New England, Mid-Atlantic States, etc.), or states (e.g., Virginia). load the RSU with a registration certificate specifying a geographic area).

While this makes it easy to deploy RSUs (eg, because RSUs work just fine anywhere in the United States), it is not advisable to designate a large geographic area for an RSU's operation. This is because the use of small, precise location information negates or greatly diminishes many of the benefits and capabilities it provides, including: These include the ability to use specific road intersections, the ability to use physical map information, theft detection and prevention, loss detection, unauthorized or incorrect worksite detection, and malicious use prevention.

Also, for portable RSU devices, data such as operational location information changes very often over time. For example, the exact operational location of a portable RSU changes daily as workers using the RSU move from job site to job site.

A portable RSU could be used to broadcast a message to vehicles, for example, alerting them to the presence of a worker or indicating that a worker has closed a highway lane. In a V2X environment, information from RSU broadcasts can be used to notify or alert drivers approaching from connected V2X vehicles about the work site or to direct autonomous V2X vehicles.

Steps to physically transfer the RSU to the manufacturer (or other trusted secure programming/provisioning location) to provide these mobile RSUs with up-to-date and accurate operational location information using current legacy SCMS and V2X provisioning systems and procedures; It should include connecting to the DCM device of the RSU and provisioning with a new enlistment certificate that contains accurate operational location information for the operator. This is impractical, expensive, time consuming and inefficient. This is because the owner has to physically move the RSU to a safe location every time the operator wants to change the working location every day.

Moreover, these reliable and secure programming/provisioning locations are not widespread. For example, it is currently not available from city traffic control centers or local, state, or federal DOTs. And a significant technical drawback of the existing enlistment certificate-based approach is that the RSU, provided with accurate operational location information, is physically imported to a trusted and secure provisioning location, and re-enrolled with a new Enrollment Certificate specifying the operational location information of the new job site. It is essentially non-functional in a V2X environment so that it can be used on other working sites until provisioned.

As a result, re-provisioning of RSU enrollment certificates to update geo-restriction information is in fact not done on existing RSUs, instead large geographic areas (e.g. the United States) are provisioned by manufacturers and left unchanged.

The systems, methods and devices described herein address the above-mentioned problems, disadvantages. Namely, application certificates containing refined and easily updatable accurate operating location information, enhanced application certificate provisioning requests allowing requestors to specify accurate operating location information, application certificates containing precise and accurate geo-restricted information, and these processes. Provide an improved computerized device, such as an RSU, that adopts accurate operating location information from advanced and geo-restricted application certificates provisioned on the RSU.

10 is a diagram illustrating an example method 1001 for initial provisioning and tracking RSUs consistent with an embodiment of the present invention. In various embodiments method 1001 may be implemented by an enhanced SCMS 400 as previously described. For example, method 1001 may be implemented by an enhanced SCMS 400 interacting with an RSU device manufacturer when an RSU is newly manufactured.

In the embodiment shown, the method begins at step 1000 when a customized account is created for an entity in the entity management system of the enhanced SCMS 400. In various embodiments, and for purposes of the embodiment disclosed with respect to FIG. 10 , the end entity may be the manufacturer of the RSU device, such as the manufacturer of the V2X RSU device 410 .

However, those skilled in the art will understand that the same or similar devices and processes as described herein can be used for other types of computerized devices (eg IoT devices or other devices 410) that use or require location information-specific digital assets. You will recognize that you can.

In various embodiments, the enhanced SCMS 400 may create an account with the RSU manufacturer after receiving a request from the RSU manufacturer (at step 1000). The account creation request may include, for example, an identifier of the RSU manufacturer, information about the RSU manufacturer, a subscriber type of the RSU manufacturer (e.g. Tier-1 manufacturer), secure assets related to the RSU manufacturer, and the like.

The method 1001 performed by the enhanced SCMS 400 in step 1010 may register a device type with the enhanced SCMS 400 . For example, an RSU device type registration request may be received from the RSU manufacturer through their account or may be received from an administrator of the enhanced SCMS 400. In some embodiments the RSU device type registration request may include an identifier of the RSU device type or a security asset associated with the RSU device type. The enhanced SCMS 400 may register the device type by, for example, storing the identifier of the RSU device type in the SMS database 406.

In step 1020, the enhanced SCMS 400 may optionally check whether the RSU device type is authorized by an authorization authority (eg, DOT in case of RSU). For example, SCMS 400 may send an identifier and/or security asset to a server associated with an authorizing entity to request verification and/or send the identifier and/or security asset to an authorized entity previously stored in SMS database 406. You can compare against the list of device types. The SCMS may store an indication of whether the device type has been verified in the SMS database 406, for example.

In step 1030, the SCMS 400 obtains a digital asset (eg, public key) for the RSU device (eg, enrollment certificate public key, signing key, encryption key, AES butterfly key extension value, etc.) and an identifier for the RSU device. obtain or create For example, the public key may be received from the RSU device or the RSU manufacturer may access their account via the entity management system 404 and enter a digital asset (eg public key) and/or enter an identifier. there is. Digital asset(s) and/or identifiers for a device may be stored in SMS database 406 .

In step 1040, the enhanced SCMS 400 transmits, transmits, returns, or provides new digital assets (e.g., digital assets created and/or previously stored by the SCMS 400) to be provisioned to the RSU device by the RSU manufacturer to the RSU manufacturer. can or return new digital assets to the RSU device itself.

In some embodiments, the new digital asset may be derived from, created using, or based on the digital asset obtained in step 1030 . In various embodiments, the enhanced SCMS 400 may transmit, return, or provide the Enrollment Certificate and/or LPF and/or LCCF at this point in the RSU's provisioning life cycle. The enhanced SCMS 400 may also transmit or provide SCMS-access information (e.g. URL) to the RSU, which the RSU may later use to access the enhanced SCMS 400 to acquire other digital assets.

A Certificate of Enrollment is a public key certificate that identifies its owner as an authorized participant within an ecosystem (e.g. USDOT V2X ecosystem). All participants must share a valid Certificate of Enrollment and Authorized Participants are required to enable communication and operation of computerized devices within that environment or infrastructure (e.g., between vehicles and roadside infrastructure devices in USDOT's embodiments of V2X environments or infrastructures). communication and operation) can receive pseudonym certificates and application certificates.

In various embodiments, the at least one digital asset, such as the enrollment certificate returned at step 1040, includes information specifying a geographic area in which operation of the RSU device is authorized or permitted. In various embodiments, geographic area information may designate a geographic area or areas in which an RSU device may properly function as part of a V2X environment. Such geographic areas may be referred to as RSU's "Permitted Geographic Areas", examples of which include certain countries (e.g., United States), states (e.g., Virginia or New England), counties (e.g., Fairfax County, Virginia), cities (eg, Richmond, Virginia) or within other geographic territories or regions defined by coordinates, boundaries, etc.

In such an embodiment, the RSU device may properly operate, function, and/or cooperate with other V2X devices only in the allowed geographic area of the RSU (i.e., in the V2X environment) as specified in the returned digital asset, eg, enrollment certificate. .

In various embodiments, the digital assets returned by the enhanced SCMS 400 at operation 1040 (e.g. Certificates of Enrollment) typically designate large "allowed" geographic areas such as countries, state groups, or states. This is because at this point the RSU device has typically not yet been deployed (i.e. it is still in the RSU manufacturer's factory) and, as previously discussed, the exact future location of the RSU is not yet clear.

In some embodiments, the enhanced SCMS 400 may return a registration authority URL and specific configuration data for final programming into the RSU device. For example, the registration authority URL may be unique to the end entity (through the entity management system) and/or customized by the end entity. As a further embodiment, the registration authority associated with the URL may be a virtual registration authority associated with the SCMS host 408 of the enhanced SCMS 400.

In various embodiments, the enhanced SCMS 400 receives a public key from a computerized RSU device that ultimately requires a location information-specific application certificate. For example, enhanced SCMS 400 may receive a public key for an RSU device and return the public key, LPF, LCCF, and other data to the RSU device.

In step 1050 the enhanced SCMS may set the state of the RSU device to initial provisioning, eg in a record in the SMS database 406 for the RSU device. It may also use RSU records within the SMS database 406 to track future interactions with RSU devices, such as when devices are further provisioned by owners or operators (e.g. DOT) at subsequent stages of the RSU life cycle. .

11 is a diagram illustrating an example method 1101 for shaping a newly deployed RSU consistent with an embodiment of the present invention. For example, method 1101 can be implemented by an enhanced SCMS 400 and a user who has just received an RSU from the RSU device owner or manufacturer, and the owner/user must now complete the RSU configuration for operational use.

In the illustrated embodiment, method 1101 begins at step 1100 when a device user's account is created by an RSU purchaser, user, operator, or owner, such as a state department of transportation. Creation is performed using the enhanced SCMS 400. In various embodiments, a device user's account may be created and/or managed through an entity of the enhanced SCMS 400 or subscriber management system 404 .

Additionally, in some embodiments and for purposes of the embodiment disclosed in connection with FIG. 11 , a device user may purchase and operate an RSU V2X device or may be a DOT's traffic management center that operates a V2X product or device integrated with one or more RSU devices. there is.

In some embodiments, the entity creating the account may be a national government entity such as USDOT or an authorized entity, which may use SCMS 400 to create and manage a database of authorized V2X devices on which digital assets may be issued. .

In some embodiments, enhanced SCMS 400 may create an account for a user of an RSU based on data received in a request from the RSU user. The account creation request will include, for example, the RSU User's identifier, information about the RSU User, the type of description of the RSU User (e.g. Authorizing Authority, Traffic Management Center, Private Construction Company, etc.), digital assets associated with the RSU User, etc. can

In some embodiments, creating an account for an RSU user may include creating one or more default LPFs for the RSU user. In some cases, different default LPFs may be associated with different device types.

In step 1110, the enhanced SCMS 400 may shape the LPF in response to receiving a request to shape the LPF from the RSU user, for example. For example, the LPF shaping request may be a workflow shaping request for RSU, a URL setting request of registration authority, an approved digital asset type setting, a PSID shaping request, and the like.

In some embodiments the charging policy may be used to determine how to respond to a charge request as described with respect to FIG. 3 above. In further embodiments a charging policy may be set based on the device type, enrolment certificate associated with the device and/or geographic area or precise location information associated with the device.

In step 1115, accurate operating location information may be configured in the RSU device. This operation is optional, as indicated by the dotted line forming the box of step 1115. For example, the RSU owner may write or store location information restriction information in the non-volatile memory of the RSU device.

If the RSU is a portable RSU used by a road worker or the like, the RSU owner (eg, state department of transportation) may create or store operating location information indicating where the road worker is working or working on a given day. That is, a set of geographic coordinates (eg GPS coordinates or latitude and longitude coordinates), a specific intersection, a specific road segment, or a small area defined by a set of coordinates.

In various embodiments, the RSU owner may enter operational location information into the RSU as directed by the RSU manufacturer and/or through the CMP 402 of the enhanced SCMS 400.

In various embodiments, the RSU device may properly function as part of the V2X environment only or within the location specified by the operating location information of the application certificate. In this embodiment, when the RSU is in a different location than the operating location information or is too far away (eg, 10 to 500 meters or more), the V2X device communicating with the RSU device recognizes that the RSU device is operating outside the proper location and the RSU device is operating. result in ignoring signals from or reporting malfunctioning or abnormal behavior of RSUs within the V2X infrastructure.

In some embodiments operation 1115 may be replaced or supplemented by a sub-process or operation (not shown) where the location information is within SCMS 400 enhanced by the owner/user of the RSU via CMS 402 for example. formatted or stored (e.g., within the SMS database 406).

For example, the RSU owner logs into the enhanced SCMS 400 using the CMS 402 and submits a request to store operational location information for a particular RSU device, and the request is sent with the desired operational location information for that RSU device. can include In response, the enhanced SCMS 400 may store the desired or requested operating location information for that particular RSU in the SMS database 406.

In this embodiment, the enhanced SCMS 400 can later query the stored operating location information using the unique identifier for the RSU, through which the enhanced SCMS 400 can use the stored operating location information by the owner/user to retrieve a specific RSU. You can create an application certificate for .

In various embodiments, optional operations 1115 and/or previous sub-processes may be eliminated from method 1101 . In some embodiments, optional operations 1115 and/or alternate sub-processes may be performed before method 1101 begins.

In step 1120 according to the embodiment of the method shown in FIG. 11, the SCMS 400 may receive an initial request for an application certificate for the RSU device, for example from the RSU or from the owner of the RSU device via the CMP 402. there is. In various embodiments, the request includes the identifier of the RSU and originates from the RSU device. In some embodiments the identifier may be received and matched to the account created for the user of the RSU device at step 1100 .

In some embodiments the identifier may be an identifier received or generated by the enhanced SCMS 400 in step 1040 described above. Also, the enhanced SCMS 400 may identify the type of V2X device that is an RSU device and/or "RSU" based on the received identifier.

In some embodiments, the initial request for an application certificate for the RSU is part of the certificate request provided to the RSU in addition to the RSU identifier. It will also include the requested operational location information specifying where the RSU will operate (eg the request includes location information specifying a specific intersection or latitude and longitude coordinates or other geographic or geometric details).

In some embodiments, the desired operating location information may be specified as information or data comprising three or more geographic coordinates forming an area greater than zero, and the area may be of any shape. Additionally or alternatively, the desired operating location information may be specified as information or data including a center point (eg latitude and longitude points) and a radius defining a circular area. Other forms of specifying geographic areas may also be used.

In some such embodiments, the requested operational location information included in the request at step 1120 may match the location information optionally input to the RSU device at step 1115 . In some embodiments where the RSU device transmits the initial request received at step 1120, the RSU device may read operating location information stored in the RSU device at step 1115 and use that operating location information to formulate or include the initial request.

Some embodiments that include operational location information in the initial request for application certificates at step 1120 modify the existing request structure and protocol, EeRa*CertProvisioningRequest (the asterisk indicates an EE-RA certificate request) so that these location information fields are Adds a new location information field to the CommonProvisioningRequestFields used in the existing EeRa*CertProvisioningRequest because it does not exist in the CAMP-specified software and data of

In this embodiment, this new field is used to specify the desired operating location information of devices that must be within the geographic area included in the RSU's enrollment certificate (eg, a subset). These new fields and the improved EeRa*CertProvisioningRequest format allow owners/operators to retrieve an RSU from a field or TMC, send it to a specialized secure programming/provisioning location, and without reprogramming, the RSU requests an application certificate with precise operational location information. .

In some embodiments (not shown in FIG. 11 ) the enhanced SCMS 400 authorizes the RSU device to request and receive digital assets from the enhanced SCMS 400 at this point (e.g., after receiving the request in step 1120). You can decide whether or not it has happened. This is disclosed below with respect to operations 1210, 1220 and 1240 before proceeding to step 1125.

At step 1122, the method 1101 determines desired or requested operating location information for the RSU device. This may be done in different ways for different implementations and embodiments.

For embodiments that include the desired operating location information for the RSU device in the request received at step 1120, the enhanced SCMS 400 may parse the received request, e.g., by obtaining the operating location information from the request, and appropriately convert the request data to Reading the field determines the desired operating location information.

For embodiments where the owner/operator/user of the RSU has previously stored operating location information for the RSU device within the enhanced SCMS 400 (e.g. as described above with respect to step 1115), the enhanced SCMS 400 determines the desired operating location information as follows. Operating location information may be obtained from its storage location by, for example, searching the storage location based on or using the RSU device's unique identifier (eg, database search), reading the operating location information, and the like.

At step 1125, method 1101 ascertains whether the desired operational location information corresponds to, within, a subset of, a portion of, or an allowed geographic area thereof.

In various embodiments, the allowed geographic area may be specified within the enrollment certificate of the RSU device or as part of the initial request received at step 1120 and/or operation 1010 and/or operation 1050 of method 1001 of FIG. 10 . ) is stored in the SMS database 406 in association with the RSU device. Enhanced SCMS 400 may also obtain allowed geographic areas from one or more of these sources.

In the illustrated embodiment, the enhanced SCMS 400 compares or analyzes the desired operating location information relative to an allowed geographic area (eg, a geographic area specified in the RSU's enrollment certificate). If the desired location information is not within, is not a subset of, or does not correspond to an allowed geographic area (operation 1125 no), method 1101 branches to operation 1127 and rejects the application certificate request to the RSU. For example, if the desired location information is a road segment in Virginia and the allowed geographic areas are Maryland and Delaware, the request is denied.

Denying the request in various embodiments may involve the enhanced SCMS 400 sending an error message to the requesting entity or device, such as the requesting RSU or RSU owner/user.

If, on the other hand, the desired location information is within or corresponds to an allowed geographic area (operation 1125 is YES), method 1101 branches to operation 1130 and generates and provides or returns the requested application certificate for the RSU. For example, if the desired location information is an intersection in Maryland and the allowed geographic areas are Maryland and Delaware, SCMS 400 generates an application certificate for the RSU, and the application certificate specifies the operational location information as an intersection in Maryland. information is included. SCMS 400 then transmits or provides a new application certificate to the requestor.

In some embodiments, at step 1130 the enhanced SCMS 400 may provide or return the LPF and/or LCCF to the RSU device along with the requested application certificate.

In some embodiments the information conveyed to the RSU device may be determined based on the device identifier received at step 1120. For example, the returned LPF may correspond to an LPF for an RSU device type selected and/or customized by the RSU owner with respect to the RSU device. Additionally, after providing the application certificate and/or other information to the RSU device at step 1130, the enhanced SCMS 400 will set the status of the RSU device within the SMS database 406 to "provisioned" or "partially provisioned". can

In various embodiments provisioned device state indicates the presence of application certificates and other files, such as LPF and LCCF, on the device. A partially provisioned device state can be used to indicate that only some of these digital assets exist on a computerized device.

12 is a diagram illustrating an embodiment of a method 1201 for providing a non-first digital asset to a deployed RSU device consistent with an embodiment of the present invention. In various embodiments, method 1201 may be implemented by an enhanced SCMS 400 and an RSU or RSU device owner/user that is using the RSU and distributes the RSU to new location information that is different from the previously deployed location.

For example, a portable RSU may have been initially provisioned according to FIG. 11 . RSUs may also require that road workers be re-provisioned that day with new application certificates that reflect the new operating location information that will use the RSU. Unless the RSU is re-provisioned with a new application certificate that reflects the new operational location information, the V2X vehicle will ignore or reject the information broadcast by the RSU as it recognizes that the information does not apply to the current location information.

In the illustrated embodiment, method 1201 may optionally begin with shaping location information within the RSU device as in step 1115 . For example, the RSU owner may write or store operating location information in non-volatile memory of the RSU device as described above.

At step 1205, method 1201 includes receiving a request for a non-initial application certificate, i.e., a certificate that is not the first or initial certificate for that RSU (described in FIG. 11). In various embodiments, the request in step 1205 may be sent or provided to SCMS 400 by an RSU device that already has an application certificate that has expired or requires replacement, or the request may come from a user via CMP 402. can In various embodiments the request may include the identifier of the RSU device as described with respect to FIG. 11 .

In some embodiments, the non-initial application certificate request for the RSU also includes information indicating the desired operating location information for the RSU. It is included in, or becomes part of, the non-initial application certificate provided to the RSU and, as described above, specifies where the RSU will operate geographically.

In some embodiments where the RSU device forwards the non-initial request received at step 1205, the RSU device reads operating location information stored in the RSU device at step 1115 and uses the operating location information to formulate the non-initial request. . In various embodiments the non-initial request may be an enhanced EeRa*CertProvisioningRequest with an additional operational location information field that allows the RSU to request an application certificate with appropriate operational location information.

Method 1201, performed for example by the enhanced SCMS 400 in step 1210, determines whether the RSU device is authorized to use the SCMS system 400 and/or authorized to receive digital assets such as non-initial application certificates. can be determined or verified. For example, enhanced SCMS 400 may access information from or related to a user account or information related to an RSU device to determine whether an RSU device is an authenticated device with, for example, an activation status.

If at step 1220 the RSU device is not authorized (step 1220 is not), method 1201 branches to unauthorized workflow 1240 where the RSU device refuses or declines to receive the requested non-initial application certificate. do. The enhanced SCMS 400 does not provide certificates to unauthenticated devices. A device may not be approved due to payment failure, theft, cancellation status, theft status, malfunction status, or inactive status.

In various embodiments, an end entity, such as an RSU owner, may change the state of a V2X device registered by or associated with an entity, eg between an active state and an inactive state. For example, if an RSU device is stolen from an operator or otherwise damaged, the RSU owner can log into the enhanced SCMS 400 and change the status of that RSU device from active to inactive. In some embodiments, unapproved workflow 1240 may be customized for an end entity (eg owner) associated with an RSU device as described above with respect to FIG. 3 .

On the other hand, if the RSU device is authorized to receive the digital asset (step 1220 is YES), method 1201 branches to step 1122.

At step 1122, method 1201 determines desired or requested operating location information for the RSU device. This may be done in different ways for different embodiments and implementations as described above with respect to FIG. 11 .

At step 1125 the method 1201 verifies that the desired operational location information as determined at step 1122 corresponds to, or is part of, a subset of the allowed geographic areas as described above with respect to FIG. 11 .

In the embodiment shown, if the desired operating location information is not a subset of the allowed geographic regions (no for operation 1125), method 1201 branches to operation 1127 and rejects the request for that application certificate to the RSU. . For example, if the desired operating location information is specified in the latitude and longitude coordinates of Virginia and the allowed geographic regions are Maryland and Delaware, the request is rejected in step 1127.

If, on the other hand, the desired operational location information is within the allowed geographic area (operation 1125 is YES), method 1201 branches to operation 1230 and generates and provides or returns the requested non-initial application certificate for the RSU. The generated non-initial application certificate contains or may contain information indicating the operational location information determined in step 1122.

For example, if the desired operational location information is specified in the latitude and longitude coordinates of Maryland and the allowed geographic regions are Maryland and Delaware, the SCMS 400 may generate and transmit a non-initial application certificate for the RSU. The provided application certificate may contain information specifying operational location information with specified latitude and longitude coordinates.

In a variation of the embodiment shown in FIG. 12, the enhanced SCMS 400 may process other requests related to a deployed device, such as a deployed RSU, in a manner similar to method 1201. For example, the enhanced SCMS 400 may receive a request to provide or shape an LPF for a device such as an RSU after the device is first deployed.

In this variant, a request to provide or shape an LPF may be a request to change the number of permitted application certificates issued and used per week. Also, the enhanced SCMS 400 may update an existing LPF (or create a new LPF) for a requesting RSU device. Subsequently, for example, when the RSU device later accesses the enhanced SCMS 400, an updated or new LPF is transmitted or provided to the requesting RSU device.

13A and 13B are swim lane diagrams illustrating an example process 1300 for securely providing one or more tenants with digital assets, such as application certificates, containing geolocation information consistent with embodiments of the present invention. In the embodiment illustrated by process 1300, virtual enrollment authorities are used to provide certificates to multiple tenants.

An example of the process 1300 illustrated in particular in FIGS. 13A and 13B includes exchange of requests and responses between enhanced SCMS components to provide a V2X device, such as the RSU device 810, with a certificate that includes a geographic location. However, the embodiments described herein are not limited to multi-tenant operation for V2X devices and the disclosed principles may be applied to other types of computerized and computer controlled devices such as IoT devices.

In various embodiments, some or all of the process 1300 or illustrated operations may be performed by code running on a computer system (which may include one or more processors or one or more computer subsystems), by a hardware-only system, or is a hybrid system of As shown at the top of FIGS. 13A and 13B , entities or devices involved in process 1300 include RSU device 1310 , SCMS host 1308 , virtual registration authority 1320 and pseudonym authentication authority 1340 .

In various embodiments these devices may communicate with each other to perform tasks as part of a process 1300 for providing location information holding certificates as described below with respect to FIGS. 13A and 13B and throughout this specification. there is.

In certain embodiments, the SCMS host 1308 may be one or more computer systems (e.g., secure or special servers) hosting the virtual registration authority 1320. Process 1300 may be performed by an enhanced SCMS (eg, enhanced SCMS 400) in communication with a computerized device (eg, RSU device 810) submitting a provisioning request.

An enhanced SCMS may include a virtual registration authority 1320, one or more connection authorities 1350, 1360, and a pseudonym authentication authority 1340, similar to that described above with respect to FIG.

As shown in the embodiment of FIG. 13A , process 1300 begins at step 1303 with shaping geographic information at RSU device 1310 . In various embodiments, the process may be performed by configuring the enrollment certificate installed on the RSU device 1310 with geographic area information, for example as described with respect to operation 1040 of FIG. 10 and/or as described with respect to operation 1115 of FIG. 11 . It is performed by recording or storing operating location information in the memory of the RSU device 1310 as described above.

Next in operation 1305 the RSU device 1310 submits to the SCMS host 1308 a provisioning request for an application certificate containing operational location information. As indicated in some embodiments, the provisioning request of operation 1305 comes directly from the RSU device 1310 and will include the desired operating location information for the RSU device 1310 along with the tenant identifier (ID) described above with respect to FIG. 8 . can

In various embodiments, the RSU device 1310 may use information from the enrollment certificate to form the provisioning request. Within the V2X environment (e.g. as specified by the CAMP), the enrollment certificate shall include the application authority (identified by the PSID value) and the allowed geographic area for the RSU and OBU respectively. An RSU or OBU device can only obtain application certificates and/or pseudonym certificates corresponding to the PSID values contained within the enrollment certificate in the existing environment specified in the CAMP.

In operation 1307 the RSU device 1310 sends a provisioning request and an identifier for the virtual registration authority 1320 to the SCMS host 1308, then the SCMS host 1308 returns the tenant ID (e.g. UUID for tenant A) from the request. or other unique identifier), then routes the request to the Virtual Enrollment Authority 1320, which handles the tenant. In this way, process 1300 can serve multiple tenants and perform customer configuration with a single SCMS host 1308.

In operation 1307 of the FIG. 13A embodiment, the SCMS host 1308 parses the Tenant ID for Tenant A from the request. In certain embodiments, the provisioning request includes meta data representing Tenant A's Tenant ID. Here, the tenant ID can be a hash, UUID, or other type of unique ID that does not indicate the tenant's ID.

Then in step 1309 the SCMS host 1308 verifies the tenant against the registration authorization authority to determine if a separate registration authorization authority exists for the tenant. For example, SCMS host 1308 may perform a query to see if a particular enrollment certificate for device 1310 is owned by or associated with a particular tenant (e.g., Tenant A in the example of FIG. 13A). . Accordingly, it is possible to verify whether the RSU device 1310 has authority by performing cryptographic verification on the service call.

In various embodiments, the verification or authorization check performed at operation 1309 involves the SCMS host 1308 decrypting and verifying the provisioning request, including verifying the signature and certificate certificate using a list of unauthorized devices (e.g., a blacklist). It includes checking the revocation status of the destination RSU device 1310 and checking whether the requester (eg device 1310) is allowed to request a certificate from the SCMS host 1308.

For example, operation 1309 may include determining from the manufacturer whether the user is an authorized user (eg, part of an employee). In some embodiments, SCMS host 1308 may determine at step 1309 whether a computerized device (e.g., RSU 1310) for receiving a certificate has been approved for use. In some embodiments, a list of approved devices (eg, a whitelist) may be provided by a regulatory authority and used to make this determination.

If the tenant passes the verification or authorization check, at step 1311 the SCMS host 1308 sends a general acknowledgment (ACK) message confirming that the provisioning request has been received, which is received by the RSU device 1310 at step 1312.

In step 1311 the SCMS host 1308 ascertains or determines whether the desired location information is within or in a subset of, or corresponds to, the geographic area allowed for the RSU device 1310 as described with respect to operation 1125 of FIG. 11 . .

After the request for the certificate and desired location information is verified in step 1313, the SCMS host 1308 initiates a provisioning request for Tenant A that includes the Tenant ID. In the embodiment of FIG. 13A, the tenant ID is implemented as a UUID. This initiates the creation of the requested certificate containing operational location information.

In step 1323 of the embodiment shown in FIG. 13A, the SCMS host 1308 examines the policy parameters for the tenant and generates a request for an accurate location-restricted application certificate from the pseudonym authentication authority 1340 according to the policy parameters.

In an embodiment, operation 1323 involves the SCMS host 1308 using the tenant ID parsed from operation 1307 to determine which policy parameters it must adhere to for a particular application certificate request, and for pseudonym authentication. Use the operational location information from request 1305 to specify the operational location information contained within the application certificate from authority 1340.

In step 1325, the virtual registration authority 1320 transmits a request for an application certificate to the pseudonym authentication authority 1340. This request may be sent in a batch of application certificate creation requests generated by virtual enrollment authority 1320.

At step 1327 a request for an application certificate is received from the pseudonym authentication authority 1340 . In response to receiving the request at step 1327, pseudonym authentication authority 1340 uses another certificate chain or key to sign the certificate, optionally using information about Tenant A.

In step 1327, the pseudonym authentication authority 1340 generates the requested location information-restricted application certificate and transmits the generated application certificate back to the virtual registration authority 1320. At step 1329 the location information-limited application certificate is received at virtual enrollment authority 1320 .

Next, as shown in FIG. 13B, at step 1331, the RSU device 1310 sends a request to the SCMS host 1308 to download a batch of location-limited application certificates, for example as described above with respect to FIG. 8B. can transmit

In operation 1333 the SCMS host 1308 parses the tenant ID from the batch download request. Then in step 1335 the SCMS host 1308 verifies the tenant against the registration authorization authority to determine if a separate registration authorization authority exists for the tenant.

Next, in step 1337, the SCMS host 1308 checks whether the policy for Tenant A is enforced. Action 1337 includes the SCMS host 1308 using the tenant ID parsed from action 1333 to determine what policy parameters to adhere to for a particular deployment application certificate download request. For example, step 1337 may include retrieving local policy parameters for the RSU device 1310 from the LPF of the corresponding device. Adjustment is passed to action 1339 after verifying that the policies for Tenant A are in effect with respect to the requested application certificate deployment.

When the geolocation-limited application certificate is ready in operation 1339, the SCMS host 1308, for example from the virtual enrollment authority 1320, sends or returns the application certificate to the device 1310. In step 1341, the device 1310 receives a location information-restricted application certificate. At this point, device 1310 is provisioned with a location information-restricted application certificate and device 1310 can use the application certificate.

Additional or alternative embodiments may use systems, devices, and processes similar to those described with respect to FIGS. 10-13 above to other computerized devices, eg, other V2X requiring digital assets with current geographic operational limitations. You can provision certificates on your device.

In other additional or alternative embodiments, systems, devices, and processes similar to those described with respect to FIGS. 10-13 above may be used to create, provision, and use geo-restricted application certificates containing multiple operational location information. there is. For example, an application certificate containing geographic coordinates of 5 different intersections, or an application certificate containing details of 10 different geographic areas corresponding to 10 different road segments.

In this embodiment, the RSU device works well with all or all of the operational location information stored in the RSU's application certificate. In this embodiment, a worker planning to work in 10 different locations over a two-week period can request and provision application certificates to the RSU device with information about the 10 different operating locations, thus reducing the need to re-provision application certificates. frequency can be reduced.

In some embodiments the application credential containing multiple operating location information may also include a period of time (eg a day or a week) associated with each operating location information during which the RSU device is operating properly at each operating location information. can For example, depending on the information within the application certificate, the first operating location information may only be valid for normal operation on January 1st, and the second operating location information may only be valid for the period from January 2nd to January 4th. may be valid for operation.

In other similar additional or alternative embodiments, the system may provision the RSU with multiple application certificates and the RSU may use them. Each of these contains only a single operating location information and a specific period of time for which the corresponding certificate permits proper operation of the RSU.

In this variant embodiment, the first application certificate may only be used by the RSU on January 1st and may only be valid for proper operation on that day at the first operational location information. On the other hand, a second application certificate containing the second operational location information may be used by the RSU for proper operation only with the second operational location information in the period from January 2nd to January 4th.

In this embodiment, RSU users may provision RSUs with geo-restricted application certificates required for each of several work site locations over the next few days (eg, next week or two weeks).

Various embodiments consistent with the present invention as described herein address the technical shortcomings of current conventional provisioning systems and meet the technical requirements of the V2X environment. As described in the embodiments herein, various embodiments can be used by a plurality of subscribers (eg, tenants), can provide unique shaping functions to each subscriber, and are subscriber-specific required for distributed V2X devices. An extended SCMS 400 capable of providing updates may be provided.

Various embodiments, consistent with the present invention, suggest that RSUs are initially programmed/provisioned at the manufacturing site with geolocation information and shipped to the owner/operator, then current application rights and geographic at the owner/operator's site, which need not be a specialized site. Securely programmed or provisioned with appropriate operational digital assets, such as application certificates with restricted information.

In various embodiments consistent with the present invention as described herein, SCMS subscribers (e.g., tenants who own or use RSUs) can use CAMP-defined Enables requesting new geolocation-restricted certificates via a REST API using the serial number of an end entity (modified as described herein) or device and using an existing Internet-connected computer.

As part of the described multi-step provisioning process, the serial number of the RSU is known to the extended SCMS 400 in the initial manufacturing provisioning phase (e.g., device is approved) as the system acquires the serial number at manufacturing time. determine whether or not there is If the serial number is successfully verified, SCMS verifies that the new location information requested for the RSU is within the allowed geographic area for the RSU (e.g. as set by the manufacturer during initial provisioning) and the application certificate with the requested new location information. is issued to the RSU.

Some embodiments, consistent with the present invention, require SCMS subscribers (eg tenants) to associate a PSID (Provider Service Identifier) and SCMS 400 extension via CMS management portal 402, secure email, or REST APIs with a device to be associated with. Let the serial number be pre-registered. When SCMS 400 receives the application certificate request from the RSU (e.g., in steps 1120 and 1205), it uses the enrollment certificate to identify the associated serial number of the device. SCMS 400 then uses the serial number to identify the correct PSID and other data such as geographic area information, and SCMS 400 creates an appropriately shaped application certificate and returns it to the requesting RSU.

Although the foregoing embodiments have used specific embodiments of computerized devices such as OBUs, ECUs and RSUs for clarity of explanation, the present invention is not limited by these specific embodiments. In addition to the V2X devices used herein to describe these new functions, devices and methods, they can be applied to all IoT devices, including IoT devices that require geographical operational restrictions.

Accordingly, in various embodiments consistent with the present invention, medical devices (eg dialysis machines, infusion pumps, etc.); robot; drone; autonomous vehicles; and wireless communication modules (eg, embedded universal integrated circuit cards (eUICC)) and the like.

Various operations of the applications described herein may be performed at least in part by one or more VMs. In additional or alternative embodiments, the operation of the applications described herein may be performed at least in part by one or more processors that are either temporarily configured to perform related operations or permanently configured (eg, by software). .

Whether temporarily or permanently, such processors may constitute processor-implemented modules that operate to perform 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.

Similarly, the methods described herein may be at least partially processor-implemented with a processor or specific processor being an embodiment of hardware. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules.

The one or more processors also operate to support performance of related operations in a 'cloud computer' environment or as 'Software as a Service' (SaaS). For example, at least some of the operations may be performed by a group of computers (an embodiment of a machine containing a processor), which operations may be accessible via a network (eg the Internet) and one or more suitable interfaces (eg API). do.

The performance of a particular task can be distributed across processors, not only on a single computer, but also distributed across multiple computers. In some demonstrative embodiments, a processor or processor-implemented module may be located in a single geographic location (eg, within an office environment, manufacturing environment, or server farm). In other example embodiments, processors or processor-implemented modules may be distributed in multiple geographic locations.

Other embodiments of the present invention will become apparent to those skilled in the art from consideration of the detailed description and examples set forth herein. The specification and examples are to be regarded as illustrative only and the true scope of the invention is to be determined by the claims that follow.

Claims (20)

A method implemented by an enhanced security credential management system (SCMS) for secure provisioning of a roadside unit (RSU) device that includes enrolment certificates and application certificates, the method comprising:
The RSU device is geographically restricted according to both enrollment certificates and application certificates,
The above method
providing an enrollment certificate to the RSU device that specifies a geographic area for the RSU device;
Receiving an application certificate request for an RSU device;
determining operational location information for the RSU device in response to the request;
verifying whether the operating location information is within a geographic area;
generating an application program certificate including operating location information; and
providing an application certificate including operating location information in response to the request to the RSU device geographically restricted according to the operating location information of the application certificate;
A method characterized by comprising a.
2. The method of claim 1, wherein the request includes operating location information for the RSU device and wherein determining the operating location information for the RSU device in response to the request comprises obtaining operating location information from the request. method.
3. The method of claim 2, wherein the request is received from an RSU device.
4. The method of claim 3, wherein the RSU device is configured with operating location information, and wherein the RSU device includes the operating location information in the request.
The method of claim 1, wherein the method
receiving a request including operating location information for the RSU device to store operating location information for the RSU device before receiving the request for the application certificate; and
Storing operating location information for the RSU device in response to the request; further comprising,
wherein determining operating location information for the RSU device in response to the request comprises obtaining stored operating location information.
6. The method of claim 5, wherein a request for storage of operating location information is received from a user of the RSU device.
2. The method of claim 1, wherein the geographic area is a country or state.
A non-transitory computer readable medium comprising instructions for executing one or more processors to perform a method for securely provisioning a roadside unit (RSU) device comprising an enrolment certificate and an application certificate, comprising:
The RSU device is geographically restricted according to both enrollment certificates and application certificates,
The above method
providing an enrollment certificate to the RSU device that specifies a geographic area for the RSU device;
Receiving an application certificate request for an RSU device;
determining operational location information for the RSU device in response to the request;
verifying whether the operating location information is within a geographic area;
generating an application program certificate including operating location information; and
providing an application certificate including operating location information in response to the request to the RSU device geographically restricted according to the operating location information of the application certificate;
A non-transitory computer readable medium comprising a.
9. The method of claim 8, wherein the request includes operating location information for the RSU device and wherein determining the operating location information for the RSU device in response to the request comprises obtaining operating location information from the request. A non-transitory computer readable medium.
10. The non-transitory computer readable medium of claim 9, wherein the request is received from an RSU device.
11. The non-transitory computer readable medium of claim 10, wherein the RSU device is shaped with operating location information, and the RSU device includes the operating location information in the request.
9. The method of claim 8, wherein the method
receiving a request including operating location information for the RSU device to store operating location information for the RSU device before receiving the request for the application certificate; and
Storing operating location information for the RSU device in response to the request; further comprising,
A non-transitory computer readable medium, wherein determining operating location information for the RSU device in response to the request comprises obtaining stored operating location information.
13. The non-transitory computer readable medium of claim 12, wherein a request for storage of operating location information is received from a user of the RSU device.
9. The non-transitory computer readable medium of claim 8, wherein the geographic area is a country or state.
A system for secure provisioning of a roadside unit (RSU) device comprising an enrolment certificate and an application certificate, comprising:
The RSU device is geographically restricted according to an application certificate,
a system comprising one or more processors operably coupled to the one or more memories, one or more memories containing instructions for executing operational instructions;
The system
providing an enrollment certificate to the RSU device that specifies a geographic area for the RSU device;
Receiving an application certificate request for an RSU device;
determining operational location information for the RSU device in response to the request;
verifying whether the operating location information is within a geographic area;
generating an application program certificate including operating location information; and
providing an application certificate including operating location information in response to the request to the RSU device geographically restricted according to the operating location information of the application certificate;
A system characterized in that for performing.
16. The method of claim 15, wherein the request includes operating location information for the RSU device and wherein determining the operating location information for the RSU device in response to the request comprises obtaining operating location information from the request. system.
17. The system of claim 16, wherein the request is received from an RSU device.
18. The system of claim 17, wherein the RSU device is shaped with operating location information, and wherein the RSU device includes the operating location information in the request.
16. The method of claim 15, wherein the operation
receiving a request including operating location information for the RSU device to store operating location information for the RSU device before receiving the request for the application certificate; and
Storing operating location information for the RSU device in response to the request; further comprising,
wherein determining operating location information for the RSU device in response to the request comprises obtaining stored operating location information.
20. The system of claim 19, wherein a request for storage of operating location information is received from a user of the RSU device.

Images