KR20200121820A - Systems, methods and devices for provisioning and processing location information for V2X devices - Google Patents

Abstract

It relates to a system, device and method for secure provisioning of a roadside unit (RSU) including an application program certificate, wherein the RSU device is geographically restricted according to the application program certificate. The enhanced SCMS system comprises: receiving an application certificate request for the RSU; Determining operating location information for the RSU in response to the request; Verifying that the operational location information is within the geographic area for the RSU; Generating an application program certificate including operating location information; And providing an application program certificate to the RSU device. It also carries out a new process and process to create and provide an application certificate containing accurate operational location information, an enhanced application certificate provisioning request that allows the requester to specify the correct operational location information, and an enhanced application certificate with geographic restriction information. It provides an improved computerized device such as an RSU that adopts accurate operational location information from an enhanced SCMS and application certificate.

Description

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

This application claims the priority of U.S. Provisional Patent Application No. 62/631,593 filed on February 16, 2018, which is a partial continuation application of U.S. Patent Application No. 16/191,030 filed on November 14, 2018. All of the 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 specifically, the present invention relates to an improved system, method, and technology for securely provisioning location information-specific digital assets on a computerized device of a V2X infrastructure.

As computers become more compact and commercialized, manufacturers are producing an increasing variety of devices including one or more embedded computers or processors. A computer in a computerized device can control the operation of the device, collect, store, and share data, and communicate with other computers and other computer devices. First of all, it updates its own software.

Internet of Things (IoT) is a network of computerized physical devices with built-in processors, electronic devices, software, data, sensors, actuators, and/or network connections, such devices being digital networks including the Internet, cellular networks, and other wireless networks. Data can be connected and exchanged through In general, each "thing" must be uniquely identifiable through an embedded computer system and must be able to inter-operate within the existing Internet infrastructure or using other communication media.

“Things” in the IoT sense are consumer electronics, enterprise devices used in business and enterprise environments, manufacturing equipment, agricultural equipment, and energy consuming devices (switches, power outlets, appliances, lighting systems, light bulbs, televisions, garages) in homes and buildings. 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, at least in some respects. It is controlled by a computer. Similarly, more and more modern traffic 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 are at least in some respects. It is controlled by a computer.

These computer-controlled elements of a transportation network usually communicate with each other to carry various types of information back and forth. For example, a roadside unit (RSU) is a roadside computer device that communicates with passing vehicles and other RSUs. The RSU may be a mobile portable device that is fixed to one location (eg, a box built next to a highway) or that road workers, emergency workers, and the like, transport and deploy as needed.

The various computer-controlled elements of the transport network respond, respond, change behavior, or otherwise rely on information received/transmitted from other vehicles in vehicle-to-vehicle (V2V; also known as vehicle-to-vehicle (C2C)). . It also communicates with infrastructure elements (such as RSU) within vehicle-to-infrastructure (also known as V2I, vehicle-to-infrastructure (C2I)) and communicates for safe, accurate, efficient and stable operation.

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

The computer of the computerized device operates according to software and/or firmware and data. In order to ensure safe and proper operation, computerized devices must be used with appropriate software, firmware, executable instructions, digital certificates (e.g. public key certificates), cryptographic keys and others (collectively'digital assets' or software' within this specification). It is initialized and updated accordingly as intended by the manufacturer or V2X system operator. Due to this, the IoT consists only of devices running approved and legitimate software and data.

However, problems arise when an unauthorized person or organization (such as a hacker) replaces or changes the software on a computer device. Problems also arise when old software, untested software, unauthorized software, and/or software with known bugs is installed on the computer device.

A particular problem arises when provisioning computerized devices designed to operate under geographic constraints, such as the RSU in V2X infrastructure. Such devices will not function properly if the location information-specific digital assets provided to the RSU are not appropriate, out of date, or do not correspond to the actual geographic operating location of the RSU.

Therefore, there is a need to provide an improved system, method, and technology for provisioning geolocation-specific digital assets to computerized devices such as RSUs of V2X infrastructure.

Disclosed herein are systems, methods, and devices for securely provisioning computerized devices such as roadside unit (RSU) devices. This includes listing certificates and application certificates, where the computerized device (e.g., RSU) is geographically limited in its proper operation according to the registration certificate and geographic information within the 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 listing certificate specifying a geographic area for the computerized device (eg, RSU); And receiving a request for an application program certificate for a computerized device (eg, RSU).

In response to the request for an application program certificate, the operation comprises: 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 an application program certificate including operating location information to a computerized device (eg, RSU).

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

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

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

In further various embodiments, the operation may comprise receiving a request including operational location information for the computerized device to store operational 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 a request for an application certificate); And determining the operating location information for the computerized device in response to the request further comprises obtaining the stored operating location information.

In some such embodiments, a request to store operational location information is received from a user of the 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 a computerized device such as a roadside unit (RSU) device, and once provisioned, the operating area of a computerized device (e.g., RSU device) is geographically Contains the restricting application certificate.

Yet another additional embodiment includes an enhanced SCMS that receives an application certificate request for a listing certificate specifying a geographic area for a computerized device (eg RSU) and an application certificate for a computerized device (eg RSU). do.

At this point, the request includes the desired operating location information (which may be within a geographic area); Check whether the operating location information is within the geographic area; Generating an application program certificate including operating location information; And providing an application program certificate including operation location information in response to the application certificate request to the RSU device geographically restricted according to the operation location information of the application program 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 showing an example of a method of provisioning and tracking a computerized device of an entity requiring a certificate executed in a security provisioning system corresponding to an embodiment of the present invention.
FIG. 2 is a diagram showing an example of a method for forming and providing a local policy file (LPF) for a computerized device executed in a security provisioning system corresponding to an embodiment of the present invention.
3 is a diagram showing an example of a method for providing a full charge of a secure asset to a computerized device executed within a secure provisioning system corresponding to an embodiment of the present invention.
4 is a diagram showing an example of a secure provisioning system configured to support multi-tenant operation corresponding to an embodiment of the present invention.
5 is a diagram showing a computerized device corresponding to multiple tenants of a security provisioning system corresponding to an embodiment of the present invention.
6 is a diagram showing an exemplary workflow in a secure provisioning system including a Certificate Management System (CMS) Management Portal (CMP) corresponding to 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 corresponding to an embodiment of the present invention.
FIG. 8A is a first part of a swim lane diagram illustrating an example of a process for securely providing credentials such as certificates corresponding to an embodiment of the present invention to multiple tenants.
Fig. 8B is a second part of a swim lane diagram showing an example of a process for securely providing credentials such as a certificate corresponding to an embodiment of the present invention to multiple tenants.
9 is a block diagram of an embodiment of a computerized system that can be used in a hosting system and method corresponding to an embodiment of the present invention.
10 is a diagram showing an example of a method for initial provisioning and tracking an RSU corresponding to an embodiment of the present invention.
11 is a diagram showing an example of a method for shaping a developed RSU corresponding to an embodiment of the present invention.
12 is a diagram illustrating an example of a method for providing non-initial digital assets to a deployed RSU device corresponding to an embodiment of the present invention.
13A is a first part of a swim lane diagram showing an example of a process for securely providing a digital asset such as an application program certificate including location information corresponding to an embodiment of the present invention to multiple tenants.
13B is a second part of a swim lane diagram illustrating an example of a process for securely providing a digital asset such as an application program certificate including location information corresponding to an embodiment of the present invention to multiple tenants.

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

In various embodiments, the embedded computer-controlled device can maintain security by provisioning secure assets within the device. For example, security assets can include encryption keys, unique identifiers, digital certificates and security software. The secure asset can also be used for secure communication, for example to authenticate the device and to perform over the air programming (OTA) software updates.

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

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

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

The following specification describes secure assets provisioned within vehicle-to-vehicle and vehicle-to-infrastructure (V2X) devices. The V2X device may include, for example, a vehicle-mounted unit (OBU), an electronic control unit (ECU), a roadside unit (RSU), and the like. OBU is included in all autonomous vehicles.

However, the embodiments described herein are not limited to V2X devices and the disclosed principles can be applied to other types of computer control 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, an enhanced SCMS with CMP, virtual enrollment rights, SMS and SMS database components similar to those shown in FIG. 4 can provide certificates to one or more OBUs, ECUs and RSUs.

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

Secure Credential Management System (SCMS) in the V2X ecosystem to identify and approve end entities (e.g. V2X devices) using secure assets (e.g. listing certificates) to secure other secure assets (e.g. pseudonyms and/or application certificates) You can request and receive from Unlike existing X.509 certificates, V2X listed certificates and pseudonym certificates do not contain the identity of the corresponding end entity. Thus, external observers cannot associate their use with specific vehicles or devices. In addition, the security assets used by V2X devices change periodically during the operating life of the device.

During V2X device manufacturing, the secure asset provisioning process takes place at a different location (and therefore at a different time), and the location belongs to or does not belong to another company (e.g., a third-party contract manufacturer, a different tenant, a customer, or a subscriber of the SCMS). For example, an initial secure asset provisioning process can occur to facilitate manufacturing requirements and comply with government regulations. For example, a Tier-1 manufacturer of V2X devices can provision an OBU with a listing certificate. In addition, a fully functional OBU can be created by provisioning pseudonymized certificates and other data after the unit is installed on a vehicle located at the original equipment manufacturer (OEM).

The fact that the secure asset provisioning process can take place in different locations can lead to 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, since certificates must be requested first and communicated with each other before installation, there may be a delay in manufacturing.

In addition, unlike existing X.509 certificates, V2X listed certificates and pseudonym certificates do not include the identity of the final entity. So, there is an additional challenge in matching the right security assets to the right V2X devices. This is especially the case when security 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) along with the correct security assets to the V2X device. Therefore, the existing SCMS can be used when an entity intends to provide user information only by one specific entity (eg, a tenant or client of the SCMS). Therefore, every entity providing customer information needs its own customized SCMS, which is expensive and not very scalable.

A multi-stage provisioning and multi-tenant security provisioning system including CMP, SMS and SCMS with virtual registration rights (collectively "enhanced SCMS") as described herein can solve the technical problems disclosed above. .

The enhanced SCMS can be used by multiple entities (e.g. multi-tenant, clients, customers and subscribers) and can provide unique shaping capabilities to each entity, and can be used on distributed computerized devices (e.g. V2X or C2X devices). -Unique updates can be provided.

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 larger products (e.g. vehicles)), and traffic management centers. It can be (TMC) (an entity that uses or manages the RSU). In various embodiments the entity may be a combination of Tier-1 manufacturers, OEMs and/or traffic management centers.

According to various embodiments, the enhanced SCMS has the ability to provide multi-tenant operation by connecting computerized devices to specific tenants (eg, clients, customers, subscribers) or dispatches upon listing.

The enhanced SCMS, as described herein, provides the V2X device with an enrollment certificate during the first phase of provisioning via CMP, and by performing the additional steps of provisioning after identifying the device via CMP, the multi-level of security assets. Step provisioning can be provided.

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

For example, a listing certificate can be provisioned on a device at the device's manufacturing stage (eg by a Tier-1 manufacturer). At this stage, the enhanced SCMS can request a device identifier (e.g., a numeric or alphanumeric code, the serial number of the device microprocessor, etc.) and will not provision a listing certificate until the device identifier is received.

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

In certain embodiments, the aftermarket device may be included in the SMS database even if the listing 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 the enhanced SCMS. When an aftermarket device is added to the SMS database, the aftermarket device can be associated with a state indicating that it is ready to be provisioned by the enhanced SCMS.

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

Some devices, for example, have more physical security than others. Devices with enhanced physical security are less likely to be stolen or damaged. Therefore, if a device is compromised, a greater number of certificates can be provisioned on a physically more secure device, since security assets are less likely to be disclosed.

In addition, fewer certificates are useful for less physically secure devices, because when a device runs out of provisioned security assets, it can access the enhanced SCMS to "top-off" (ie, acquire more) security assets. can do.

Devices charge more often as fewer security assets are provisioned. Thus, when a device is damaged it is either terminated or processed when connected to "charge" a localized or enhanced SCMS. Thus, the more frequently a device is charged, the more likely it is to handle the device that is more likely to be damaged.

In some embodiments the second stage of provisioning for a V2X device may occur when a 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 can be received from the V2X device and the enhanced SCMS can use the device identifier to identify the V2X device, and based on the identified device (e.g., based on a previously provisioned listing certificate, Provisioning pseudonyms and application certificates)

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

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

For example, a customized workflow can be created and the customized shaping can be managed by the end entity via a subscriber management system (SMS, also referred to herein as an entity management system). The SMS operates to manage the tenant and information related to the tenant, some of which may be sent to the tenant's OBU, RSU, and TMC devices (TMCD).

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

For example, an element could be the amount of initial provisioning (e.g., the amount of certificate initially provisioned on the tenant's device), the encryption key and certificate, the connection permission (i.e., information identifying the connection permission used by the tenant), and the backend service to the tenant. Information such as an indication of dedicated hardware used to provide a quality (QoS) level may be included, but is not limited thereto.

In various embodiments, the initial provisioning amount indicated in the LPF for a tenant may be expressed as a specific type of certificate count (eg, 10,000 pseudonymized certificates) or duration (eg, 6 months of certificate supply).

According to some embodiments, the LPF for a given tenant is the validity period for the certificate (e.g., the validity period of the certificate), the number of certificates an entity can own, the duplicate period for the certificate, and the period of time the certificate is valid in the future (e.g., initial provisioning , The validity period of the certificate in the future), and an indication of the time when the tenant should request a certificate charge (how long the end entity waits for the certificate to be used before requesting an additional certificate).

LPF can be customized using customized workflows and customized shaping, and the operation and/or shaping of V2X devices can be customized by transferring the LPF to the V2X device. For example, customized workflows and/or customized configurations must be received and stored to ensure that information and security assets are provisioned (e.g. registration rights to use, customization information to be added to security assets, security assets provisioned on the device). Can be determined).

In various embodiments, the LPF may be installed on a computerized device that requires a certificate, such as a V2X device. This allows the end entity to customize the process performed by the V2X device and/or provide a custom interface for the V2X device.

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

In some embodiments, the LPF may also include a custom workflow and/or custom shaping based on the type of device being provisioned as a secure asset. For example, using an entity management system, the end entity can specify the number of secure assets to provision on various types of devices, and the customization configuration can be stored within the entity's LPF and secure assets to be provisioned when the device requests the secure assets. 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 a user account for each end entity in the SCMS; Creation of a new V2X device type in SCMS; Verification of the type of device approved by the Department of Transportation (DOT) or other approving entity; Acquisition of listed or other types of public keys (eg signing/encryption keys, Advanced Cryptographic Standards (AES) Butterfly Key Extensions, etc.); Return of public key, LPF and local certificate chain file (LCCF) for aftermarket devices; Return URL of registration authority for final programming of field device; Device tracking based on device identifier; It includes; provisioning of aftermarket devices.

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

1 is a diagram illustrating an example of a method performed in a security provisioning system corresponding to the disclosed embodiment. The illustrated method can begin at step 100 when a custom account is created for an entity in the entity management system of the enhanced SCMS. Additionally, in some embodiments, for the purposes of the embodiment described in connection with FIG. 1, the final entity may be a Tier-1 manufacturer of V2X devices.

In some embodiments the enhanced SCMS may create an account for the end entity based on receipt of the request from the end entity. The account creation request may include, for example, the identifier of the final entity, information on the final entity, the type of the final entity (eg, Tier-1 manufacturer), and security assets related to the final entity.

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 through an account or from an administrator of the 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. The enhanced SCMS can register the device type, for example by storing the device type's identifier in the SMS database.

In step 120, the enhanced SCMS may check whether the device type is approved by the authentication subject (eg, DOT). For example, the SCMS may send an identifier and/or secure asset to a server associated with the authenticating subject for request verification and/or compare the identifier and/or secure asset to a list of approved device types stored in the SMS database. The SCMS can then store an indication of whether the device type has been verified, for example in the SMS database.

In operation 130, the SCMS may obtain a public key for the device (eg, a registration certificate public key, a signing key, an encryption key, an AES butterfly key extension value, 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 in the SMS database.

In step 140, based on the public key obtained in step 130, the enhanced SCMS may return the registration certificate to the final entity and provision it to the device and/or the device itself. In some embodiments the enhanced SCMS may also return the registration rights URL and specific shaping data to the device for final programming. For example, the registration rights URL is unique to the end entity and/or is customizable (via the entity management system) due to the end entity. As an additional embodiment, the registration right associated with the URL may be a virtual registration right related to the SCMS of the enhanced SCMS.

In various embodiments, the enhanced SCMS receives public keys from computerized devices that require certificates. For example, the enhanced SCMS receives only the listed public key, or the enhanced SCMS receives the listed public key and other application/pseudonym public keys. The enhanced SCMS returns only the listing certificate (including other data such as LPF), or the enhanced SCMS also returns the application/pseudonym certificate according to the provided 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 a specific embodiment, the downloading of LPF and LCCF for the computerized device is performed through a change of presentation state (REST) service call and does not include a registration certificate (eg, signed message).

For all other REST service calls, the SCMS host of the enhanced SCMS can perform a discovery, thereby verifying that the device's specific listing certificate is owned or associated with a specific tenant. That is, encryption validation can be performed to ensure that these service calls are allowed. For LPF and LCCF downloads, tenant identifiers (IDs) from URLs, routing, HTTP headers, or other mechanisms are used to determine which files to present to the computerized device. The LCCF can be consistent across all tenants of the enhanced SCMS (i.e., all included certificates), but the LPF is different from tenant to tenant.

For other service invocations, computerized device and certificate management is securely managed, even if a single enrollment authority (e.g., virtual enrollment authority) or a single set of SCMS backend components are handled in different directions over a strong cryptographic link.

In step 150, the improved SCMS may set the device's state to initially provisioned or provisioned when the device is an aftermarket device (eg, in the SMS database), and when the device is provisioned as described below with respect to FIG. Devices can be tracked for further provisioning by OEMs or traffic management centers in subsequent stages of

2 is a diagram showing an example of a method performed in a security provisioning system corresponding to the disclosed embodiment. The illustrated method can begin at step 200 when a customization account is created for the final 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 embodiments described in connection with FIG. 2, the 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 the entity may be a Tier-1 manufacturer of a V2X device when the Tier-1 manufacturer ships the partially or fully provisioned device to the OEM. The end entity may be USDOT or other approving entity and is used to create and manage a database of approved devices that issue certificates.

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

In some embodiments creating an account for the final entity may include creating one or more default LPFs for the entity. For example different base LPFs can 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 request for shaping a workflow for a specific device type, a request to set the URL for enrollment rights, a request to change or set a geographic restriction (e.g. geographic coordinates where RSU can operate), a request for shaping a filling policy (eg It may be changing the number of security assets to be provisioned, setting the type of approved security assets, etc.).

In some embodiments, the charging policy may be used to determine how to respond to the charging request as described in connection with 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, the 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 via an account created for the final entity in step 200.

In some embodiments, the listing certificate may be the listing certificate returned to the device by the enhanced SCMS in step 140 as described above. In other embodiments the device may be an aftermarket device and the listing 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 the V2X device and/or the V2X device based on the identifier of the V2X device.

In 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 customized device type selected by the final entity associated with the V2X device. Based on returning information to the V2X device, the enhanced SCMS can set the device's status to full provisioning or partial provisioning.

The provisioned device status in various embodiments indicates that the device has its listing certificate, pseudonym/application certificate, and other files (such as LPF and LCCF). The partially provisioned device state can be used to indicate that the computerized device has only a portion 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 end entity and may update the count based on setting the state of the provisioned device.

For example, the enhanced SCMS can use the number of provisioned devices to ensure that the number of provisioned devices does not exceed a predetermined production run size. Therefore, the improved SCMS can confirm that there is no unauthorized overproduction.

In step 240, the enhanced SCMS may receive a request to manage the deployed device. In some embodiments, the request to manage the deployed device may be a request to shape the LPF after the device is deployed. For example, the LPF shaping request may be a request to change or set a geographic restriction, 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, the device connects to the enhanced SCMS to request charging of the secure asset as described in connection with FIG. 3.

3 is a diagram illustrating an example of a method performed in a security provisioning system corresponding to the disclosed embodiment. The exemplary method may begin at step 300 when a hash of the 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 the enhanced SCMS or an aftermarket V2X device not provisioned through the enhanced SCMS.

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

In further embodiments, the content delivery network (see, for example, content delivery network 412 in 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 security assets, and allows the V2X device to charge the security asset in a device physically close to the V2X device (e.g., network delay). To reduce).

In step 310, the enhanced SCMS may check whether the device is 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 FIG. 3, step 310 can confirm that the computerized device is approved.

If the computerized device is not approved in step 310 (eg, stolen, malfunctioned, deactivated, etc.), the device is refused to charge. Verification of the approved device in step 310 ensures the security intent of proper and approved operation of the computerized device in the ecosystem. The enhanced SCMS does not provide certificates for unauthenticated devices. The device may not be approved due to payment failure, theft, or cancellation status.

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

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

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

If the V2X device is not verified as active in step 320, the enhanced SCMS may not provide charging of the secure asset in step 340, but instead, a customization non-customization set by the 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 the GPS coordinates from the device, and provides the updated LPF to the V2X device.

In some embodiments, the functionality described herein may prevent unauthorized provisioning or incorrect provisioning of V2X devices. Public safety vehicles, for example, have unique functions in the V2X ecosystem that controls traffic signals at intersections. The functions described above can ensure that a certificate with these functions is 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-registration 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-register these devices, the enhanced SCMS can securely re-provision these devices using a multi-step process to prevent unauthorized device re-registration. For example, the 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 can then request the device to retrieve the device's microprocessor serial number or other permanent identifier along with a request for signing a new listing key certificate. The enhanced SCMS can then check if the device was previously provisioned with a permanent identifier. If the enhanced SCMS can verify this, the enhanced SCMS returns a registration certificate along with other device provisioning information such as LPF. The enhanced CMS can maintain a status record indicating that the device has been re-registered. The device can then use the SCMS protocol to request a pseudonym/application certificate bundle.

According to the configuration of the enhanced SCMS, the SCMS uses a flexible provisioning mechanism to download only what it is entitled to receive to the device. This allows OEMs and/or their service sites to be queried to see if re-list provisioning has been approved. These additional checks are performed when there is malicious activity or when a high-value entity (e.g. a police car with special functions to control traffic lights at an intersection) is re-listed.

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

4 is a diagram illustrating an example of a secure provisioning system 400 corresponding to the disclosed embodiment. The secure provisioning system 400 includes an SCMS host 408 with virtual enrollment rights, a CMS management portal (CMP) 402, a subscriber management system (SMS) 404, an SMS database 406, and one or more computerized manufacturing systems. 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 shaping information for subscriber entities. In various embodiments, the SMS 404 may operate to manage the tenant and information related to the tenant, some of which may be sent to the tenant's OBU, RSU, and TMC devices. A device 414 disposed as shown in FIG. 4 may include a computerized device having an OBU (eg, a vehicle with a V2X or C2X device) and/or one or more RSUs.

In the embodiment of Fig. 4, the 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 the 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 by each tenant to configure the version of the security provisioning system 400 as needed.

For example, the tenant can determine the validity period of the certificate (e.g., the validity period of the certificate), the number of certificate devices in the tenant that can be owned, the duplication period for the tenant's certificate, and how long the tenant's certificate is valid in the future (e.g. To indicate the parameters to be stored in the LPF, shaping provisioning, how long the certificate will be valid in the future), and an indication of when the tenant should request a certificate recharge (e.g., how long the end entity waits for certificate use before requesting additional certificates) I can.

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

In some embodiments, each of the CMP 402, SMS 404 (e.g., entity management system), SMS database 406, and SCMS host 408 with virtual enrollment rights may each have one or more processors, one or more computer-readable It may be a separate device including a non-transitory medium or the like.

In alternative or additional embodiments, two or more of the CMP 402, SMS 404, SMS database 406, and SCMS host 408 with virtual enrollment rights 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 rights provides the secure asset and verifies the hash of the secure asset, as described above. In further embodiments CMP 402 provides an interface for entities (eg tenants, subscribers, clients) and computerized devices (eg V2X or C2X devices) to communicate with the enhanced SCMS.

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

In another embodiment, the SMS database 406 stores information about the enhanced SCMS. For example, the SMS database 406 may store information to identify the computerized device at a later stage and may further associate each computerized device with the final entity (e.g., tenant) provisioning the computerized device. .

As further shown in Figure 4, the device 410 being manufactured may represent a V2X or C2X device associated with the current Tier-1 manufacturer (as described above), and the deployed vehicle and RSU are currently OEM and/or traffic management It may represent a device associated with the center.

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

5 is a diagram showing computerized devices 502, 504, 506 corresponding to multiple tenants (e.g., Tenant A, Tenant B, and Tenant N) of a security provisioning system corresponding to an embodiment of the present invention. SCMS enhanced in accordance with various embodiments have the ability to provide multi-tenant operations by connecting computerized devices to specific tenants (eg, clients, customers and subscribers) or distribution upon enrollment.

In the embodiment of FIG. 5, n tenant groups exist and the improved SCMS connects the device 502 to tenant A, the device 504 to tenant B, and the device 506 is the last of the n tenant groups. It can be connected to the nth tenant (that is, tenant n). As shown in Figure 5, this connection to the corresponding tenant of devices 502, 504, 506 is what devices 502, 504, 506 use to access enrollment rights to determine the tenant identifier (tenant ID). This can be done by parsing each network address, path or URL.

In the embodiment of FIG. 5, the URL 503 includes the tenant ID of tenant A added to the URL 503, the URL 505 includes the tenant ID of tenant B, and the URL 507 is the tenant of tenant n. Include ID. These URLs 503, 505, 507 may be used by computerized devices 502, 504, 506 to access the enrollment rights of the enhanced SCMS. In alternative or additional embodiments, the tenant ID for the tenant may be provided to the devices 502, 504, 506 upon listing by including the tenant ID preceded by the URL 503, 505, 507 or otherwise indicated.

In another alternative or additional embodiment, the tenant ID for the tenant may be provided to a device (eg device 502) in a new file upon listing. 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 a message, thus protecting the identity of a tenant associated with a given device.

6 is an exemplary workflow 600 in a secure provisioning system including a Certificate Management System (CMS) Management Portal (CMP) 602, SMS 604 and SMS Database 606 corresponding to an embodiment of the present invention. It is a diagram showing. Tenants are registered through CMP 602 according to various embodiments. Within CMP 602, the device owner (e.g., the owner of one of the devices 502, 504, 506 discussed above with reference to Fig. 5) sets up an account to register the device and submit a certificate for the device, and Tenant ID is given by CMP 602.

Exemplary workflow 600 includes registering new customer information (eg, tenant or subscriber information) with CMP 602. Workflow 600 also includes identification 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 tenant's account information can be stored in the SMS database 606 and subsequently retrieved from the SMS database 606 by the CMP 602 and SMS 604 as needed.

As shown in Figure 6, the CMP 602 may operate to receive and shape SLA details for the tenant. In some embodiments, the CMP 602 may also be operable to shape business requirements details for specific customizations required by the tenant. For example, the tenant has the CMP 602 hardware separation for the tenant to generate a certificate (see e.g. a set of isolated and independent SCMS backend components 724 in Fig. 7 described below), encryption separation for cryptographic operations. , Separation of hardware security modules (HSMs) for sensitive operations, unique certificate chains of authentication rights, expected usage per week, local policy parameters (e.g. LPF) and other SLA details for tenants can be indicated.

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

Depending on the new tenant's shaping and service level, you can create a backend SCMS service according to the tenant's requirements and SLA details, and deploy the hardware for the new tenant. For example, as shown in FIG. 7 and described below, a dedicated registration right 721 and an independent SCMS backend component 724 may be deployed for tenant N with 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 operation corresponding to an embodiment of the present invention. As shown, the 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), and registration 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 tenants of n tenant groups. That is, the SCMS host 708 processes initial provisioning requests 703, 705, 707 from the computerized devices 702, 704, 706. Some tenants choose to share SCMS backend components based on the required service level and the purchased service tier (for example, 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 allows tenants to access separate and dedicated SCMS backend components, which is a separate hardware component. Has (e.g., separate and independent hardware components to perform cryptographic operations for a single tenant).

In the example 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 use of 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 each initial provisioning request 703, 705, 707 to the configured registration authority through the SCMS host 708, and the provisioning request (703, 705, 707) represents each tenant ID.

According to some embodiments tenants A, B, ... The tenant ID for N may be included in routing information submitted to the SCMS host 708. That is, in the operating environment 700, each computerized device 702, 704, 706 has been registered by a specific tenant (eg, one of tenants A, B, ... N) and their respective initial provisioning requests 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 in FIG. 5), routing, HTTP header elements (e.g.,'SCMS tenant' elements), or other mechanisms.

The SCMS host 708 is a single SCMS registration rights endpoint for centralized services. 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., determining the correct tenant for the listing certificate). for). The SCMS host 708 routes various requests to a virtual shared registration right 720 or dedicated registration right 721.

In various embodiments, the tenant ID is added to all messages transmitted within the operating environment 700 after the SCMS host 708 parses the tenant ID from the initial provisioning requests 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 for each UUID of the tenant ID may be stored in the SMS database 606 discussed above with reference to FIG. 6.

This obfuscation helps to ensure the privacy of messages transmitted through the virtual registration rights 720 shared between multiple tenants (eg tenants A and B). The tenant ID is used to determine the key or certificate chain to use in the operating environment 700. The tenant ID also allows registration rights 720, 721 to determine which policy parameters to comply with 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 rights 720,721. The SCMS host 708 parses the tenant ID in the initial provisioning requests 703, 705, 707. Devices 702, 704, 706 and devices outside 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 requests 703, 705, 707, the operating environment 700 allows a specific portion of the computerized devices 702, 704, 706 to be Convinces that snooping cannot be used to determine whether it is owned or related by. This protects the identity and personal information of the tenant 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 the initial provisioning request 703, 705. , 707) to the correct registration rights (eg, shared registration rights 720 or dedicated registration rights 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 routes these requests to the registration authority 720 based on the parsed tenant ID. 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 tenant ID parsed for tenant N. In an alternative or additional embodiment there may be a single registration right to route requests to the tenant ID embedded in the internal message exchanged between a single SCMS host 708 and a single registration right.

In other alternative or additional embodiments there may be a completely independent internal virtual registration rights component that processes the initial provisioning requests 703, 705, 707 and then routes the request to the correct backend component.

The set of shared SCMS backend components 722 in the embodiment of FIG. 7 are components shared between tenants A and B. The shared set of SCMS backend components 722 includes shared pseudonym authentication rights 740, shared connection rights 1 (750), shared connection rights 2 (760), and shared listing authentication rights that provide certificates and connection values to tenants A and B. Including 730.

As shown in Fig. 7, the set of separate and independent SCMS backend components 724 is a component dedicated to carrying out a certificate request from tenant N, which is a single tenant. An independent set of SCMS backend components 724 includes independent pseudonym authentication rights (741), independent connection rights 1 (751), independent connection rights 2 (761), which provide certificates and connection values exclusively to tenant N. It includes an independent registration authentication authority 731.

In the embodiment of Figure 7, tenant N has a higher level of service (e.g., higher service layer or service priority) than tenants A and B, and as a result, tenant N is by an independent set of SCMS backend components 724. Serviced. In a particular embodiment, a service layer is associated with each tenant of n tenant groups, and the service layer of each tenant corresponds to one of a number of layers ranging from the lowest service level to the highest service level.

Dedicated registration rights 721 may also use shared SCMS backend components 722 in certain embodiments. That is, the embodiment can create a dedicated registration right 721 for tenant N that provides a unique interface to tenant N, but the shared SCMS backend component 722 used by tenant N is transferred to another tenant (for example, tenant A and tenant A). You can share with B).

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

According to some embodiments, the higher service layer may provide tenant N access to dedicated registration rights 721 that are not shared or used by other tenants. In one such embodiment, the dedicated registration right 721 may be created and shaped for tenant N based on the tenant's upper service layer so that the dedicated registration right 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 other shared SCMS backend components 722 depending on the product type for the tenant's device requiring a certificate. That is, the OBU device for the tenant may use one of the shared SCMS backend components 722 and the RSU device may use the other shared SCMS backend component 722.

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

In particular, the exemplary process 800 shown in FIGS. 8A and 8B includes the exchange of requests and responses between enhanced SCMS components to provide certificates to V2X devices such as device 810. However, the embodiments disclosed herein are not limited to multi-tenant operation for V2X devices, and the disclosed principles can 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 exemplary process 800 shown in FIGS. 8A and 8B provides a certificate to 2X devices in a multi-tenant environment. That is, Figures 8A and 8B show the components of an exemplary enhanced SCMS in the context of the V2X flow of request and response.

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

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

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

The enhanced SCMS includes virtual registration rights 820, one or more connection rights 850 and 860, and pseudonym authentication rights 840. The exemplary CMS includes one or more application program platforms that run applications for virtual registration rights 820. This application platform is communicatively connected to one or more computer engines that perform cryptographic operations required by the 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 running software applications). The enhanced SCMS also includes one or more VMs communicatively connected to one or more computer engines that execute (not shown) the listed authentication rights and perform cryptographic operations required by the listed authentication rights.

The registration authentication authority is operable to generate the registration certificate and conditionally transmit it to the virtual registration authority 820. The embodiment of the CMS host hosting the virtual registration authority 820 of FIGS. 8A and 8B is to execute an application program for the pseudonym authentication authority 840 and perform one or more cryptographic operations required by the pseudonym authentication authority 840 And one or more VMs communicatively connected to the computer engine.

The pseudonym authentication authority 840 is operable to generate a pseudonym certificate and conditionally transmit it to the virtual registration authority 820. The enhanced SCMS also executes the first and second connection rights 850, 860 and is communicatively connected to one or more computer engines that perform cryptographic operations required by the first and second connection rights 850, 860. Also includes the above VMs.

Each application program for the first connection right 850 and the second connection right 860 is operable to generate a connection value and conditionally transmit the connection value to the virtual registration right 820.

The enhanced SCMS including the virtual registration rights 820 shown in FIGS. 8A and 8B is one or more computer engines that execute an application program for the virtual registration rights 820 and perform cryptographic operations required by the virtual registration rights 820 It may also include one or more application platform communicatively connected to the.

The enhanced SCMS may further include one or more application platform communicatively connected to one or more computer engines that run applications for enrollment authentication authority and perform cryptographic operations required by enrollment authentication authority. It is operable to create and conditionally transmit to the virtual registration authority 820.

The enhanced SCMS may further include one or more application program platforms communicatively connected to one or more computer engines that run an application program for the pseudonym authentication authority 840 and perform cryptographic operations required by the pseudonym authentication authority 840. And it is operable to generate a pseudonym certificate and conditionally transmit it to the virtual registration authority 820.

In addition, the enhanced SCMS includes one or more application program platforms communicatively connected to one or more computer engines that execute an application program for the first connection right 850 and perform cryptographic operations required by the first connection right 850. can do.

Finally, the enhanced SCMS provides one or more application program platforms communicatively connected to one or more computer engines that execute an application program for the second connection right 860 and perform cryptographic operations required by the second connection right 860. It can also contain. The connection rights 850 and 860 are operable to generate connection values and conditionally transmit them to the virtual registration rights 820.

In yet another embodiment, the listing authentication right is operable to generate a listing certificate in response to receiving a request for the listing certificate from the virtual registration right 820; The pseudonym authentication authority 840 is operable to generate a pseudonymized certificate in response to receiving a request for a pseudonymized certificate from the virtual registration authority 820; And the first connection right 850 and the second connection right 860 are operable to generate a connection value in response to receiving a request for a connection value from the virtual registration right 820.

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

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

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

This allows SCMS host 808 to identify tenants and route requests to the correct virtual enrollment rights 820 without the need to change or reshape device 810 or process 800.

In some embodiments, the provisioning request may indicate configuration details for the tenant, required application privileges (eg, represented by a provider service identifier (PSID) value), and validity information for a certificate. This information can be carried over the path or HTTPS header. For example, the key value pair for the'SCMS tenant' header element may include the'tenant A'value. The privacy of this information may be protected within a Transport Layer Security (TLS) handshake between the device 810 and the SCMS host 808.

In an additional or alternative embodiment the provisioning request may be sent to a Domain Name System (DNS) where two different URLs or paths are identified (eg pointed to) to the same server or webpage. That is, with DNS, requests from two different tenants representing each tenant ID of the two tenants may have different routes 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 Partner LLC (CAMP)), a listing certificate is required to cover the application rights (identified by the PSID value) and the permitted geographic areas for each RSU and OBU. The RSU or OBU device may obtain only an application program certificate and/or an alias certificate corresponding to the PSID value included in the registration certificate.

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

In this way, process 800 can serve multiple tenants with a single SCMS host 808 and handle custom shaping. In the embodiment of Figure 8A, at operation 807, the SCMS host 808 parses the tenant ID for tenant A from the request. In a particular embodiment, the provisioning request includes metadata indicating the tenant ID for tenant A. Here, the tenant ID may be a hash, a UUID, or any other type of unique ID that does not reveal the tenant's identity.

Then, in operation 809, the SCMS host 808 verifies the tenant against the listed authentication right to determine if a separate listed authentication right exists for the tenant. According to a particular embodiment, the download of the LPF and LCCF to the device 810 is accomplished through a change of presentation state (REST) service call and does not include a registration certificate (eg, signed message).

For all other REST service calls in process 800, SCMS host 808 has a specific listing certificate for device 810 owned or associated with a specific tenant (e.g., tenant A in the embodiment of Figure 8A). You can do a search in operation 809 to see if it is. Encryption validation can be performed to ensure that these service calls are allowed.

For LPF and LCCF downloads, the file to be provided to the device 810 can be determined using the URL (as shown in FIG. 8A), the path, the HTTP header, or the tenant ID for tenant A in other mechanisms. The downloaded LCCF can be consistent across all tenants (i.e., including all certificates).

However, the downloaded LPF may differ from tenant to tenant. For other service invocations of process 800, the strong cryptographic connection may be a single enrollment privilege (e.g., virtual enrollment privilege 820) or a single set of SCMS backend components (e.g., the shared SCMS described above with reference to FIG. 7 ). Even if a set of backend components) are handled by different policies, it can be ensured that the device 810 and certificate management are safely managed.

The main role of the registration authentication authority is to issue a registration certificate to an end user device, for example, the device 810 by performing a request that may occur from the virtual registration authority 820. The listing authentication authority interacts directly with the SCMS host 808 to issue the requested listing certificate to the device 810.

In an additional or alternative embodiment, the enrollment authentication authority is a device 810 capable of acting as a proxy between the enhanced SCMS and the computerized device that requires the enrollment certificate. It can communicate directly with the server acting as a proxy for the client.

For example, the listed certification authority may communicate directly with the device 810 in the manufacturer's area (eg, a manufacturer's factory).

A listing certificate 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 listing certificate. In addition, the approved participant may also receive a pseudonym certificate that enables communication and operation of the device 810 within the ecosystem (for example, enabling communication and operation between the vehicle and roadside infrastructure in USDOT's V2X ecosystem example). have.

In various embodiments, the verification performed at operation 809 includes the SCMS host 808 decrypting and verifying the provisioning request. This is done by verifying the signature, verifying the revocation status of the device 810, which is the destination of the certificate (e.g., a computerized device), using a list of unauthorized devices (e.g., blacklist), and It includes a determination of whether it is authorized to request a certificate from the host 808. For example, operation 809 includes determining whether the manufacturer's user is an authorized user (eg, part of an employee).

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

Next, in 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 including a tenant ID for tenant A. In Fig. 8A, the tenant ID is implemented as a UUID.

In operations 815-822, the connection rights 850 and 860 directly interact with the virtual registration rights 820 to fulfill a request for a connection value. In step 815, the provisioning request is received from the virtual registration right 820, and the virtual registration right 820 transmits a request for the first set of connection values LA1 to the connection right 1 850.

In response to receiving the request for the first set of connection values in step 816, the connection right 1 850 sends the first set of connection values to the virtual registration right 820. Connection permission 1 (850) can send the first set of previously created connection values (i.e. pre-generated connection values), or connection permission 1 (850) is the first connection value in case the value is not pre-generated. Create and transmit the second set.

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

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

In certain embodiments, the connection rights 850 and 860 shown in FIGS. 8A and 8B may link the identity of the certificate requester (ie, a unique identifier for the device of the certificate requester) to a pseudonymized certificate issued for revocation purposes. In other words, connection authority 1 (850) and connection authority 2 (860) are the first and second connections as unique identifiers of the certificate requester device to the pseudonymized certificate issued by the pseudonym authentication authority 840 as part of the process 800, respectively. Provide each set of values.

Connection rights 1 (850) and connection rights 2 (860) after receiving the connection value request sent from the virtual registration rights 820 in operations 815 and 819, and then to the virtual registration rights 820 in operations 816 and 821. Provides a connection value request.

Still referring to FIG. 8A, in step 823, the SCMS host 808 checks the policy parameter for tenant A, and generates a request for the correct pseudonym certificate from the pseudonym authentication authority 840 according to the policy parameter. In an embodiment operation 823 includes a SCMS host 808 that uses the tenant ID parsed from operation 807 to determine which policy parameters to comply with 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 pseudonymized certificate to the pseudonym authentication authority 840. This request is transmitted as a batch of pseudonymized certificate generation requests generated by virtual enrollment authority 820.

In step 827, a request for a pseudonymized certificate is received at the pseudonym authentication authority 840. In response to receiving the request at step 827, the pseudonym authentication authority 840 optionally signs the certificate using a different certificate chain or key using the information for tenant A. In step 827, the pseudonym authentication authority 840 generates the requested pseudonym certificate and transmits the generated pseudonym certificate to the virtual registration authority 820 again. In step 829, the pseudonymized certificate is received at the virtual registration authority 820.

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

At operation 833, the SCMS host 808 parses the tenant ID from the batch download request. Then, in step 835, the SCMS host 808 verifies the tenant for the registration authentication authority to determine whether a separate registration authentication 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 by requesting a specific batch alias certificate download. For example, step 837 includes retrieving local policy parameters for device 810 from the device's LPF. After ensuring that the policy for tenant A is in force with respect to the requested pseudonym certificate placement, control passes to operation 839.

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

In additional or alternative embodiments, a process similar to process 800 described above may be used to provide a certificate 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 for one or more on-vehicle units (OBUs), electronic control units (ECUs), roadside units (RSUs) and TMC devices. These OBUs and ECUs may be shaped 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, RSU can be installed in traffic control devices (eg, traffic signals), roadside content distribution systems, electronic fare systems, electronic signage devices and digital display devices (eg, electronic billboards). The TMCD is operable to be installed in a government (eg local, state or federal government) traffic management center for use in digitally signed messages for broadcast or display by RSU.

9 is a block diagram of an embodiment of a computer environment 901 including a computer system 900 that may be used to implement systems and methods corresponding to the embodiments of the present invention. Other components and/or arrangements may also be used.

In some embodiments, the computerized system 900 includes device 810, virtual enrollment privilege 820, SCMS host 808, connection privileges 850, 860, pseudonymized authentication privileges of FIGS. 8A and 8B, and security of FIG. It may be used to at least partially implement the 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, the computer system 900 has, among other things, the SCMS host 408, CMPs 402, 602, SMS 404, 604, and SMS databases 406, 606 of FIGS. 4 and 6 with virtual registration rights. It can be used to at least partially implement. Also, for example, the computer system 900 can be used to at least partially implement the SCMS host 708 of FIG. 7, the registration rights 720 and 721 and the SCMS backend components 722 and 724, 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 over a network 935. It can be programmed as a specialized server.

In the embodiment shown in FIG. 9, the computer system 900 includes a CPU 905, a memory 910, an input/output (I/O) device 925, a hardware security module (HSM) 940, and a nonvolatile 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 (e.g., server, workstation, personal computer, laptop, etc.) may include CPU 905, memory 910, non-volatile storage 920, and I/O device 925. have.

In this shaping, the components 905, 910, 920 and 925 can connect and communicate via a local data bus and via an external I/O connection (e.g. implemented as a separate data source or database system) data storage. 930 can be accessed. The I/O component 925 establishes a network and/or other suitable connection such as a direct communication connection (e.g., a wired or local WiFi connection), a local area network (LAN), or a wide area network (such as a WAN, cellular telephone network, or Internet). You can connect to external devices via System 900 may be standalone or may be a subsystem of a larger system.

The 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, CA, or an Athlon™ family of microprocessors manufactured by AMD Corporation of Sunnyvale, CA. . 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 is volatile or non-volatile, magnetic, semiconductor, tape, storage device 1120 is volatile or non-volatile, and magnetic, semiconductor, tape, optical or other type of storage device or computer readable medium, such as It may be a device such as CD and DVD and a solid device 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. Perform a variety of operations, procedures, processes or methods consistently.

Alternatively, CPU 905 may execute one or more programs located remotely from system 900. For example, computer system 900 may access one or more remote programs through a network 935 that, when executed, perform functions and processes associated with implementation of the present invention.

In a specific embodiment, the memory 910 includes a SCMS host 408, CMP 402, 602, SMS 404, 604, SCMS host 708 with virtual registration rights as shown in FIGS. 4, 6, 7, 8A and 8B. ), registration rights (720, 721), SCMS backend component set (722, 724), device 810, virtual registration rights (820), SCMS host 808, connection rights (850, 860), and pseudonym 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 functions to the present invention.

The memory 910 may also be embodied as an operating system (not shown) and/or other programs (not shown) that perform a number of functions well known in the art when executed by the CPU 905 (not shown). . 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 use of the operating system are not critical to the present invention.

The HSM 940 may be a device with its own processor that safely creates and stores digital security assets and/or safely performs various encryption 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 the computer system 900.

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

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

In the illustrated embodiment, the computer system 900 is connected to a network 935 (e.g., the Internet, a private network, a virtual private network, a cellular network, or other network or a combination thereof), which in turn is a server, a personal computer, a laptop computer, It can be connected to various systems and computer devices such as client devices. In general, the computer system 900 inputs data from external devices and devices and outputs data to the external devices and devices through the network 935.

In the exemplary embodiment shown in FIG. 9, storage 930 is a standalone data source external to system 900 such as a database. In other embodiments storage 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, storage 930 may be used to implement the SMS databases 406 and 606 of FIGS. 4 and 6 and the LPF and LCCF described herein. In some embodiments, the storage 930 may manage and store a data structure including status and log information for each computerized device having a certificate provisioned by the 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 through computer system 900. For example, the repository 930 is an Oracle™ database, a Sybase™ database, other relational or non-relational database. However, the system and method consistent with the present invention are not limited to use of a separate data structure or database, or a database or data structure.

Those skilled in the art will recognize that the components and implementation details of the system of FIG. 9 are examples presented for the sake of brevity and clarity of description. Other components and implementation details can be used.

As an implementation example, the current existing security credential management system (SCMS) as defined by the Anti-Collision Metric Partner 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. It cannot provide customized shaping capabilities for groups.

In the CAMP mechanism, a separate existing SCMS system is required for each customer who needs these functions. A function that provides customization shaping is desirable, but cannot be used in the CAMP mechanism. In the existing V2X environment (e.g., specified by CAMP), the listing certificate must include the application rights (identified by the PSID value) and permitted geographic areas (geographic areas) for each RSU and OBU.

The RSU or OBU device can only obtain the application certificate and/or pseudonymized certificate corresponding to the PSID value contained in the registration certificate, and the application and/or pseudonymized certificate (e.g., top-off certificate) issued afterwards may be included in the registration certificate. Permitted areas, which are identical to the area information included, should be included.

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

Embodiments of the invention described in connection with FIGS. 10 to 13 below are particularly useful in solving a series of geo-restricted technical problems associated with roadside units (RSUs), also known as roadside equipment (RSEs).

One technical issue is related to the fact that existing RSUs and existing SCMSs (e.g., as defined by Anti-Collision Metrics Partner LLC (CAMP)) store or retain geolocation restriction information only in RSU's listing certificate. In other words, the registration certificate is provided by the existing SCMS only while the RSU is physically connected to the existing Device Configuration Manager (DCM) system. This means that the system must be in the RSU manufacturer or other acceptable, safe and reliable programming position.

When manufacturing the RSU, the manufacturer entity has very little of all the necessary information that must be inserted into a certificate of operation (eg, registration and/or application certificate). In particular, there is no accurate information describing the future geographic location (location information) of the RSU as the buyer deploys and operates the RSU. This operating location information from the device's listing certificate is important because the correct operation of RSU in the V2X environment is limited to that location information.

In other words, the exact operating location information is generally known only after the manufacturer ships the device to the device buyer/owner/operator/user that places the RSU in the operating state and a specific location. Operation location information is unknown.

This is especially the case when manufacturers produce RSU devices for stock use long before they are ordered, sold, and shipped to users. At the time of manufacture, manufacturers generally do not know who the RSU will eventually sell to and where it will operate.

As used in some embodiments described herein, the term “accurate operational location information” refers to, 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 square meters, 600 square meters, 500 square meters, 400 square meters, 300 square meters, 200 square meters, 100 square meters, or 50 square meters, means an area less than about 2,000,000 square meters (2 square kilometers). And these terms include geographic points such as the intersection of latitude and longitude coordinates. This area can be of any shape. In general, a region is a larger area, such as a country or state.

Therefore, it is impossible to load the RSU with an accurate location information-restricted listing certificate when manufacturing using an existing system. To address this issue, manufacturers have been working in geographic areas where RSU is likely to be sold and distributed, such as an entire country (e.g. United States), a group of states (e.g. New England, Mid-Atlantic States, etc.) or states (e.g. The RSU is loaded with a listing certificate specifying the geographic area).

This makes it easy to deploy RSU (for example, because RSU works well anywhere in the United States), but it is not advisable to designate a large area for RSU to operate. This is because the use of small and accurate location information negates or significantly reduces many of the benefits and features that it provides, including: It includes the ability to use specific road intersections, the ability to use physical map information, theft detection and prevention, loss detection, unauthorized or wrong work site detection, and malicious use prevention.

In addition, in the case of portable RSU devices, data such as operating location information changes very often over time. For example, the exact operating location information of a portable RSU changes daily as the operator using the RSU moves from job site to job site.

An operator can use a portable RSU to alert the vehicle, for example, to warn of the presence of an operator or to broadcast a message to the vehicle indicating that the operator has closed a highway lane. In the V2X environment, the information from the RSU broadcast can be used to inform or warn drivers approaching from the connected V2X vehicle about the work site, or instruct autonomous V2X vehicles.

To provide these mobile RSUs with up-to-date and accurate operational location information using existing existing SCMS and V2X provisioning systems and procedures, physically transferring the RSU to the manufacturer (or other trusted secure programming/provisioning location), secure location. It should include connecting to the DCM device of the company, provisioning with a new listing certificate containing accurate operational location information for the RSU and workers. This is impractical, costly, time consuming and inefficient. This is because the owner must physically move the RSU to a safe location whenever the operator wants to change the working position on a daily basis.

Moreover, these reliable and secure programming/provisioning locations are not widespread. For example, it is currently not available in urban traffic management centers or regional, state, or federal DOTs. And an important technical drawback of the existing registration certificate-based approach is that the RSU provided with accurate operating location information is physically brought to a reliable and secure provisioning location, and re-used with a new listing certificate specifying the operating location information of the new work site. It is essentially not working in a V2X environment so that it can be used by other work sites until provisioned.

As a result, re-provisioning of RSU listing certificates to update geographic restriction information is virtually not done in the existing RSU, instead a large geographic area (e.g. the United States) is provisioned by the manufacturer and left unchanged.

The systems, methods and devices described herein solve the above mentioned problems and disadvantages. I.e. an improved and easily updated application certificate containing accurate operational location information, an improved application certificate provisioning request allowing the requestor to specify the correct operational location information, application certificates with precise and accurate geo-restricted information, and these processes. The provision of an improved SCMS to perform the RSU, an improved computerized device such as an RSU that adopts accurate operational location information from an improved geographically restricted application certificate provisioned in the RSU.

10 is a diagram illustrating an example of a method 1001 for initial provisioning and tracking an RSU corresponding to an embodiment of the present invention. In various embodiments, method 1001 may be implemented by enhanced SCMS 400 as previously described. For example, method 1001 may be implemented by enhanced SCMS 400 by interacting with the RSU device manufacturer when the 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 the purposes of the embodiments disclosed in connection with FIG. 10, the final entity may be a manufacturer of an RSU device, such as a manufacturer of V2X RSU device 410.

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

In various embodiments, the enhanced SCMS 400 may create an account for the RSU manufacturer after receiving the request (in step 1000) from the RSU manufacturer. The account creation request may include, for example, the RSU manufacturer's identifier, information about the RSU manufacturer, the type of subscriber of the RSU manufacturer (eg Tier-1 manufacturer), security assets related to the RSU manufacturer, etc.

The method 1001 performed by the enhanced SCMS 400 in step 1010 may register the device type with the enhanced SCMS 400. For example, the RSU device type registration request may be received from an RSU manufacturer through their account or may be received from the 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, for example by storing the identifier of the RSU device type in the SMS database 406.

In step 1020, the improved SCMS 400 may selectively check whether the RSU device type is approved by the authorization entity (eg, DOT in the case of RSU). For example, SCMS 400 may request verification by sending an identifier and/or security asset to a server associated with the authorization entity and/or store the identifier and/or security asset previously stored in the SMS database 406. It can be compared to the list of device types. The SCMS may store an indication of whether the device type has been verified, for example in the SMS database 406.

In step 1030, the SCMS 400 acquires a digital asset (e.g., public key) for the RSU device (e.g., listing certificate public key, signing key, encryption key, AES butterfly key extension value, etc.), and an identifier for the RSU device. Acquire or create. For example, the public key may be received from the RSU device or the RSU manufacturer may access their account through the entity management system 404, enter a digital asset (e.g., a public key) and/or enter an identifier. have. The digital asset(s) and/or identifier for the device may be stored in the 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 SCMS 400) to the RSU manufacturer to be provisioned on the RSU device by the RSU manufacturer. It can do or return a new digital asset to the RSU device itself.

In some embodiments, a new digital asset may be derived from, created using, or created based on the digital asset obtained in step 1030. In various embodiments, the enhanced SCMS 400 may transmit, return, or provide the listing certificate and/or LPF and/or LCCF at this point in the provisioning life cycle of the RSU. In addition, the enhanced SCMS 400 may transmit or provide SCMS-access information (eg, URL) to the RSU and the RSU may later be used to connect to the enhanced SCMS 400 to acquire other digital assets.

A listing certificate is a public key certificate that identifies its owner as an authorized participant within the ecosystem (e.g. USDOT V2X ecosystem). All participants must share a valid enrollment certificate, and the authorized participant must enable communication and operation of computerized devices within that environment or infrastructure (e.g. between the vehicle and the roadside infrastructure device in an embodiment of USDOT's V2X environment or infrastructure. Enables communication and operation) Can receive pseudonym certificates and application certificates.

In various embodiments, the at least one digital asset, such as the listing certificate returned in step 1040, includes information specifying a geographic area in which operation of the RSU device is authorized or permitted. In various embodiments, the geographic area information may designate a geographic area or area in which the RSU device may function properly as part of the V2X environment. These geographic areas may be referred to as “allowed geographic areas” of RSU, and examples include specific countries (eg United States), states (eg Virginia or New England), counties (eg Fairfax County, Virginia), and cities. Includes areas such as within (eg Richmond, Virginia) or other geographic territories or territories defined by coordinates, boundaries, etc.

In such embodiments, the RSU device may operate, function and/or cooperate as appropriate with other V2X devices only in the permitted geographic area of the RSU (i.e. in a V2X environment) as specified in the returned digital asset, e.g. the listing certificate. .

In various embodiments, digital assets (eg, listing certificates) returned by the enhanced SCMS 400 in operation 1040 generally designate a large “allowed” geographic area, such as a country, state group, or state. At this point, the RSU device is usually not yet deployed (e.g. still at the RSU manufacturer's factory) and, as previously explained, the exact future location of the RSU is not yet clear.

In some embodiments, the enhanced SCMS 400 may return a registration rights URL and specific shaping data for final programming into the RSU device. For example, the registration rights URL may be unique to the end entity (via the entity management system) and/or may be customized by the end entity. As an additional embodiment, the registration rights related to the URL may be virtual registration rights related to 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, the 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, for example in a record in the SMS database 406 for the RSU device. In addition, RSU records in SMS database 406 can be used to track future interactions with RSU devices, such as when devices are additionally provisioned by owners or operators (e.g. DOT) in subsequent stages of the RSU life cycle. .

11 is a diagram illustrating an example of a method 1101 for shaping a newly deployed RSU corresponding to an embodiment of the present invention. For example, method 1101 may be implemented by the 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 the method 1101 begins at step 1100 when the device user's account is created by an RSU purchaser, user, operator, or owner such as the state's Department of Transportation. Generation is done using the enhanced SCMS 400. In various embodiments the device user's account may be created and/or managed through the entity of the enhanced SCMS 400 or the subscriber management system 404.

In addition, in some embodiments and for the purposes of the embodiments disclosed in connection with FIG. 11, the device user may purchase and operate an RSU V2X device, or be a traffic management center of a DOT operating a V2X product or device that is integrated with one or more RSU devices. have.

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

In some embodiments, the enhanced SCMS 400 may create an account for a user of RSU based on data received in a request from an RSU user. The account creation request includes, for example, the RSU user's identifier, information about the RSU user, the type describing the RSU user (e.g., authorization authority, traffic management center, private construction company, etc.), digital assets associated with the RSU user, etc. I can.

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

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

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

In step 1115, accurate operating location information may be embodied in the RSU device. This operation is optional as indicated by the dashed line forming the box in step 1115. For example, the RSU owner can 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 road workers, etc., the owner of the RSU (e.g., the State Department of Transportation) can create or store operational location information indicating where the road worker is working or working on that day. In other words, it is like a small area defined by a set of geographic coordinates (eg GPS coordinates or latitude and longitude coordinates), a specific intersection, a specific road section, or a set of coordinates.

In various embodiments, the RSU owner may enter operational location information into the RSU according to the instructions of 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 at or within the location specified by the operating location information of the application program certificate. In such embodiments, when the RSU is in a different location than the operational location information or too far away (e.g., 10 to 500 meters or more), the V2X device communicating with the RSU device recognizes that the RSU device is operating outside the appropriate location and As a result, it ignores the signal from the V2X infrastructure, or reports that the RSU is malfunctioning or malfunctioning 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 the SCMS 400 enhanced by the owner/user of the RSU, for example via CMS 402. Shaped or stored (eg in SMS database 406).

For example, the RSU owner uses the CMS 402 to log in to the enhanced SCMS 400 and submits a request to store operational location information for a specific RSU device, the request being the desired operational location information for that RSU device. It may include. In response, the enhanced SCMS 400 may store desired or requested operating location information for that particular RSU in the SMS database 406.

In this embodiment, the improved SCMS 400 can later query the stored operating location information using a unique identifier for the RSU, and through this, the improved SCMS 400 uses the operating location information stored by the owner/user to obtain a specific RSU. You can generate 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 alternative 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 from the owner of the RSU device, for example from the RSU or via the CMP 402. have. 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 an account created for the user of the RSU device in step 1100.

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

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

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

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

In step 1120, some embodiments including operational location information in the initial request for an application program certificate modify the existing request structure and protocol, EeRa*CertProvisioningRequest (the asterisk indicates an EE-RA certificate request), so that these location information fields are not existing. Since it does not exist in the CAMP-specified software and data of, a new location information field is added to CommonProvisioningRequestFields used in the existing EeRa*CertProvisioningRequest.

In this embodiment, this new field is used to specify the desired operational location information of the device that should be within the geographic area (eg, a subset) included in the RSU's listing certificate. This new field and improved EeRa*CertProvisioningRequest format allows the owner/operator to retrieve an RSU from the field or TMC and send it to a specialized secure programming/provisioning location, and without reprogramming, the RSU can request an application certificate with accurate operating location information. .

In some embodiments (not shown in Figure 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. This is disclosed below with respect to operations 1210, 1220 and 1240 before proceeding to step 1125.

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

For embodiments in which the request received in step 1120 includes the desired operational location information for the RSU device, the enhanced SCMS 400 parses the received request, for example by obtaining operational location information from the request and The desired operating location information is determined by reading the field.

In the case of an embodiment in which the owner/operator/user of the RSU previously stored operational location information for the RSU device in the enhanced SCMS 400 (for example, as described above with respect to step 1115), the enhanced SCMS 400 Determines the desired operating location information as follows. For example, it is possible to obtain operational location information from its storage location by searching for a storage location based on or using the unique identifier of the RSU device (eg, searching a database), reading the operating location information, and the like.

In step 1125, method 1101 ascertains whether the desired operating location information is within the permitted geographic area, a subset, part, or corresponding thereto.

In various embodiments, the allowed geographic area may be specified within the RSU device's listing certificate or as part of the initial request received in step 1120 and/or act 1010 and/or act 1050 of method 1001 of FIG. ) Is stored in the SMS database 406 with respect to the RSU device. In addition, the enhanced SCMS 400 can obtain permitted geographic areas from one or more of these sources.

The enhanced SCMS 400 in the illustrated embodiment compares or analyzes the desired operational location information in relation to the permitted geographic areas (eg geographic areas designated within the RSU's listing certificate). If the desired location information is not within the allowed geographic area, is not a subset thereof, or does not correspond to it (operation 1125 is no), method 1101 is divided into operation 1127 and rejects the corresponding 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.

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

On the other hand, if the desired location information is within or corresponds to the permitted geographic area (operation 1125 is an example), method 1101 is branched 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 permitted geographic areas are Maryland and Delaware, the SCMS 400 generates an application certificate for RSU, and the application certificate specifies the operational location information as an intersection in Maryland. Information is included. Thereafter, the SCMS 400 transmits or provides a new application program certificate to the requester.

In some embodiments, the enhanced SCMS 400 at step 1130 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 in step 1120. For example, the LPF returned may correspond to an LPF for an RSU device type selected and/or customized by the RSU owner with respect to the RSU device. In addition, after providing the application certificate and/or other information to the RSU device in step 1130, the enhanced SCMS 400 sets the status of the RSU device to "Provisioned" or "Partially Provisioned" within the SMS database 406. I can.

Device state provisioned in various embodiments indicates that the device has an application certificate and other files such as LPF and LCCF. The partially provisioned device state can be used to indicate that only some of these digital assets are present on the computerized device.

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

For example, the portable RSU may have been initially provisioned according to FIG. 11. The RSU may also require road workers to be re-provisioned with a new application certificate that reflects the new operating location information that the RSU will use that day. Since the RSU recognizes that the information is not applied to the current location information unless it is re-provisioned with a new application certificate reflecting the new operating location information, the V2X vehicle ignores or rejects the information broadcast by the RSU.

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 the 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, that is, a certificate other than the first or initial certificate for the RSU (described in FIG. 11). In various embodiments, the request in step 1205 may be sent or provided to the SCMS 400 by an RSU device that already has an application certificate that has expired or needs replacement, or the request may come from the user through the CMP 402. I can. In various embodiments the request may include the identifier of the RSU device as described in connection with FIG. 11.

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

In some embodiments where the RSU device transmits the non-initial request received in step 1205, the RSU device reads the operational location information stored in the RSU device in step 1115 and uses the operational location information to formulate a non-initial request. . In various embodiments the non-initial request may be an improved 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 by the enhanced SCMS 400, for example in step 1210, whether the RSU device is approved to use the SCMS system 400 and/or is authorized to be provided with a digital asset such as a non-initial application certificate. Can be determined or confirmed. For example, the enhanced SCMS 400 may access information from a user account or user information related thereto or information related to the RSU device to determine whether the RSU device is, for example, an authenticated device with an activation status.

If the RSU device is not approved in step 1220 (no step 1220), method 1201 is divided into an unauthorized workflow 1240, where the RSU device refuses or refuses to receive the requested non-initial application certificate. do. The enhanced SCMS 400 does not provide certificates to unauthorized devices. The device may be disapproved due to payment failure, theft, cancellation, theft, malfunction, or deactivation.

In various embodiments an end entity, such as an RSU owner, may change the state of a V2X device registered by the entity or associated with the entity, for example 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 in to the enhanced SCMS 400 and change the state of the RSU device from active to inactive. In some embodiments, the disapproved workflow 1240 may be customized for an end entity (eg, the owner) associated with the 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 an example), method 1201 branches to step 1122.

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

In step 1125, method 1201 verifies that the desired operating location information, as determined in step 1122, corresponds to, or a subset of, the allowed geographic areas as described above with respect to FIG. 11.

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

On the other hand, if the desired operational location information is within the permitted geographic area (operation 1125 is an example), method 1201 branches to operation 1230 and generates and provides or returns the requested non-initial application certificate for the RSU. It may contain or contain information indicating the operating location information determined in the generated non-initial application certificate step 1122.

For example, if the desired operational location information is specified in Maryland's latitude and longitude coordinates, and the permitted geographic areas are Maryland and Delaware, the SCMS 400 can generate and transmit a non-initial application certificate for the RSU. The provided application program certificate may include information that designates operating location information with specified latitude and longitude coordinates.

In a variation of the embodiment shown in FIG. 12, the enhanced SCMS 400 can handle 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 initially deployed.

In this variation, a request to provide or shape an LPF may be a request to change the number of allowed application program certificates issued and used every week. In addition, the improved SCMS 400 may update the existing LPF (or generate a new LPF) for the requesting RSU device. Subsequently, for example, when the RSU device later connects to the enhanced SCMS 400, it sends or provides an updated or new LPF to the requesting RSU device.

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

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

In various embodiments, the process 1300 or some or all of the illustrated operations are by code executing 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. 13A and 13B, entities or devices associated with 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 a location information retention certificate as described below in connection with FIGS. 13A and 13B and throughout this specification. have.

In certain embodiments, SCMS host 1308 may be one or more computer systems (eg, secure or specialized servers) hosting virtual enrollment rights 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.

The enhanced SCMS may include virtual registration rights 1320, one or more connection rights 1350, 1360, and pseudonym authentication rights 1340, similar to those disclosed above with respect to FIG. 8.

As shown in the embodiment of FIG. 13A, process 1300 begins at step 1303 of shaping geographic information in RSU device 1310. In various embodiments, the process may be performed by shaping the registration certificate installed on the RSU device 1310 with geographic area information, for example as described for operation 1040 in FIG. 10 and/or described for operation 1115 in FIG. This is accomplished by writing 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 a provisioning request for an application program certificate including operation location information to the SCMS host 1308. As shown in some embodiments, the provisioning request of operation 1305 comes directly from the RSU device 1310 and will include the desired operational location information for the RSU device 1310 along with the tenant identifier (ID) described above with respect to FIG. I can.

In various embodiments, the RSU device 1310 may use the information from the listing certificate to form a provisioning request. Within a V2X environment (e.g., as specified by CAMP), the listing certificate must include the application rights (identified by the PSID value) and the geographic area permitted for each of the RSU and OBU. The RSU or OBU device can obtain only an application program certificate and/or a pseudonym certificate corresponding to the PSID value included in the registration certificate in the existing environment specified in the CAMP.

In operation 1307, after the RSU device 1310 sends an identifier for the virtual enrollment authority 1320 and a provisioning request to the SCMS host 1308, the SCMS host 1308 sends the tenant ID (e.g., the UUID for tenant A) from the request. Or other unique identifier), and then route the request to the virtual registration authority 1320 that handles the tenant. In this manner, process 1300 can serve multiple tenants with a single SCMS host 1308 and perform customer shaping.

In operation 1307 of the FIG. 13A embodiment, the SCMS host 1308 parses the tenant ID for tenant A from the request. In a specific embodiment, the provisioning request includes metadata indicating the tenant ID of tenant A. Here, the tenant ID may be a hash, UUID, or other type of unique ID that does not indicate the tenant's ID.

Thereafter, in step 1309, the SCMS host 1308 verifies the tenant against the registration authentication authority to determine whether a separate registration authentication authority exists for the tenant. For example, the SCMS host 1308 may perform a lookup to see if a particular listing certificate for the device 1310 is owned or associated with a particular tenant (e.g., tenant A in the example of FIG. 13A). . Therefore, it is possible to check whether the RSU device 1310 has the authority by performing encryption verification for such a service call.

In various embodiments, the verification or authorization verification performed in operation 1309 is performed by the SCMS host 1308 decrypting and verifying the provisioning request, including the signature verification, and the certificate using a list of unauthorized devices (e.g., blacklist). Checking the revocation status of the RSU device 1310, which is the destination of the RSU device 1310, and checking whether the requestor (eg, the device 1310) is permitted 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, the SCMS host 1308 may determine in step 1309 whether the computerized device (eg, RSU 1310) for receiving the certificate has been approved for use. In some embodiments, a list of approved devices (e.g., a white list) may be provided by the regulatory body and used to make this decision.

If the tenant passes the verification or authorization confirmation, in 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 in step 1312.

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

After the request for the certificate and the desired location information is verified in step 1313, the SCMS host 1308 initiates a provisioning request including the tenant ID for tenant A. In the embodiment of Fig. 13A, the tenant ID is implemented as a UUID. This initiates the creation of the requested certificate including the operating location information.

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

In an embodiment, the operation 1323 includes the SCMS host 1308, through which it uses the tenant ID parsed from the operation 1307 to determine the policy parameters that should be adhered to for a particular application certificate request, and pseudonym authentication. The operational location information from the request 1305 is used to specify the operational location information contained within the application certificate from the authority 1340.

In step 1325, the virtual registration authority 1320 transmits a request for an application program certificate to the pseudonym authentication authority 1340. Such a request may be transmitted in batches of a request for generating an application program certificate generated by the virtual registration authority 1320.

In step 1327, a request for an application program certificate is received from the pseudonym authentication authority 1340. In response to receiving the request in step 1327, the pseudonym authentication authority 1340 selectively uses the information for tenant A to use another certificate chain or key to sign the certificate.

In step 1327, the pseudonym authentication authority 1340 generates the requested location information-restricted application program certificate and transmits the generated application program certificate to the virtual registration authority 1320 again. In step 1329, the location information-restricted application program certificate is received from the virtual registration authority 1320.

Next, as shown in FIG. 13B, in step 1331, the RSU device 1310 makes a request to the SCMS host 1308 to download a batch of location information-restricted application certificates, for example, as described above with respect to FIG. 8B. Can be transmitted.

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

Next, in step 1337, the SCMS host 1308 checks whether the policy for tenant A is enforced. The operation 1335 includes the SCMS host 1308 using the tenant ID parsed from the operation 1333, which can determine which policy parameters to comply with for a particular batch application certificate download request. For example, step 1337 may include searching for a local policy parameter for the RSU device 1310 in the LPF of the corresponding device. After verifying that the policy for tenant A is in force with respect to the requested application certificate deployment, the adjustment passes to operation 1339.

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

In additional or alternative embodiments, other computerized devices using systems, devices and processes similar to those described in connection with FIGS. 10 to 13 above, for example other V2Xs requiring digital assets with current geographic operational limitations. You can provision a certificate on the device.

In other additional or alternative embodiments, a system, device, and process similar to those described in connection with FIGS. 10 to 13 above can be used to create, provision, and use geographically restricted application certificates containing multiple operational location information. have. For example, an application certificate including the geographic coordinates of 5 different intersections or an application certificate including details of 10 different geographic areas corresponding to 10 different road sections.

In this embodiment, the RSU device works well with all or all of the operating location information stored in the RSU's application certificate. In this embodiment, a worker who plans to work in 10 different locations for 2 weeks can request and provision an application certificate containing 10 different operational location information from the RSU device, thus eliminating the need to re-provision the application certificate. You can reduce the frequency.

In some embodiments, the application certificate containing multiple operational location information will also include a period of time (e.g., a day or a week) associated with each operational location information while the RSU device is operating properly on each operational location information. I can. For example, according to the information in the application program certificate, the first operating location information may be valid for normal operation only on January 1st, and the second operating location information is only normal for the period from January 2nd to January 4th. Can be available for operation.

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

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

In this embodiment, the RSU user can provision the RSU with the geo-restricted application certificate required for each of the multiple work site locations over the next few days (eg, next week or two).

Various embodiments consistent with the present invention as described herein solve the technical shortcomings of the current conventional provisioning system and satisfy the technical requirements of the V2X environment. As described in the embodiments herein, various embodiments can be used by multiple subscribers (e.g., tenants), can provide unique shaping functions to each subscriber, and are subscriber-specific required for deployed V2X devices. It can provide an extended SCMS 400 that can provide updates.

Various embodiments consistent with the present invention are that RSU is initially programmed/provisioned at the manufacturing site with geographic location information and is not required to be a specialized site after being delivered to the owner/operator. Securely programmed or provisioned into appropriate operational digital assets, such as application certificates with restricted information.

As described herein, in various embodiments corresponding to the present invention, SCMS subscribers (e.g., tenants who own or use RSU) are CAMP-defined for CMS management portal 402, secure email, RA communications. It allows you to use the serial number of the end entity (modified as described herein) or device and request a new geo-restricted certificate via a REST API using an existing internet-connected computer.

The described extended SCMS 400 is part of the disclosed multi-stage provisioning process, and the serial number of the RSU is known to the extended SCMS 400 during the initial manufacturing provisioning phase (e.g., the device is approved) as the system obtains a serial number at manufacturing time. Check if there is or decide. Upon successful verification of the serial number, SCMS verifies that the new location information requested for the RSU is within the permitted 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 RSU.

Some embodiments consistent with the present invention include a PSID (provider service identifier) that requires a SCMS subscriber (e.g. tenant) and a device to be associated with the extended SCMS 400 via a CMS management portal 402, secure email or REST API. Have the serial number pre-registered. When the SCMS 400 receives the application certificate request from the RSU (eg, in steps 1120 and 1205), the enrollment certificate is used to identify the device's associated serial number. The SCMS 400 then uses the serial number to identify the correct PSID and other data, such as geographic area information, and the SCMS 400 generates an appropriately shaped application certificate and returns it to the requesting RSU.

Although the above-described embodiments have used specific embodiments of computerized devices such as OBU, ECU and RSU for clarity of description, the present invention is not limited by these specific embodiments. In addition to the V2X device used herein to describe these new functions, devices, and methods, it can be applied to all IoT devices including IoT devices requiring geographic operation restrictions.

Thus, in various embodiments corresponding to the present invention, medical devices (eg dialysis devices, infusion pumps, etc.); robot; drone; Autonomous vehicle; And wireless communication modules (eg, embedded universal integrated circuit cards (eUICC)) and the like.

Various operations of the application programs described herein may be performed at least partially by one or more VMs. In additional or alternative embodiments, the operation of the application programs described herein may be performed at least partially by one or more processors that are temporarily configured (for example by software) or permanently configured to perform the associated operations. .

Regardless of whether temporarily or permanently embodied, such processors may constitute processor-implemented modules that operate to perform one or more of the application operations, functions and roles described herein. The term'processor-implemented module' as used herein 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 that is an embodiment of hardware. For example, at least some of the operations of the method may be performed by one or more processors or processor-implemented modules.

In addition, one or more processors operate to support the 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 can be accessed through a network (e.g. Internet) and one or more suitable interfaces (e.g. API). Do.

The performance of certain tasks not only resides on a single computer, but can be distributed across multiple computers and distributed among processors. In some exemplary 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 exemplary embodiments the processors or processor-implemented modules may be distributed across multiple geographic locations.

Other embodiments of the present invention will be apparent to those skilled in the art upon consideration of the detailed description and examples disclosed herein. The specification and examples are considered to be exemplary only and the true scope of the invention is judged by the following claims.

Claims (20)

In a method implemented by an enhanced security credential management system (SCMS) for secure provisioning of a roadside unit (RSU) device comprising an enrollment certificate and an application program certificate,
The RSU device is geographically restricted according to both the registration certificate and the application program certificate,
The above method is
Providing the RSU device with a listing certificate detailing the geographic area for the RSU device;
Receiving an application certificate request for the RSU device;
Determining operating 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
In response to the request, providing an application program certificate including operation location information to the RSU device geographically restricted according to the operation location information of the application program certificate;
A method comprising a.
The method of claim 1, wherein the request includes operational location information for the RSU device, and determining the operational location information for the RSU device in response to the request comprises obtaining operational location information from the request. Way.
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 operational location information, and the RSU device includes operational location information in the request.
The method of claim 1, wherein the method
Prior to receiving the request for an application certificate, receiving a request including operating location information for the RSU device for storing operating location information for the RSU device; And
In response to the request, storing operating location information for the RSU device; further comprising,
And determining the operating location information for the RSU device in response to the request comprises obtaining the stored operating location information.
6. The method of claim 5, wherein a request for storage of operational location information is received from a user of the RSU device.
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 enrollment certificate and an application program certificate, comprising:
The RSU device is geographically restricted according to both the registration certificate and the application program certificate,
The above method is
Providing the RSU device with a listing certificate detailing the geographic area for the RSU device;
Receiving an application certificate request for the RSU device;
Determining operating 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
In response to the request, providing an application program certificate including operation location information to the RSU device geographically restricted according to the operation location information of the application program certificate;
Non-transitory computer-readable medium comprising a.
The method of claim 8, wherein the request includes operational location information for the RSU device, and determining operational location information for the RSU device in response to the request comprises obtaining operational location information from the request. 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 configured with operational location information, and the RSU device includes operational location information in the request.
The method of claim 8, wherein the method
Prior to receiving the request for an application certificate, receiving a request including operating location information for the RSU device for storing operating location information for the RSU device; And
In response to the request, storing operating location information for the RSU device; further comprising,
The non-transitory computer-readable medium, characterized in that the step of determining the operating location information for the RSU device in response to the request comprises obtaining the stored operating location information.
13. The non-transitory computer-readable medium of claim 12, wherein a request to store operational 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.
In a system for secure provisioning of a roadside unit (RSU) device including a registration certificate and an application program certificate,
The RSU device is geographically restricted according to the application program certificate,
A system comprising one or more memories containing instructions, one or more processors operatively coupled to the one or more memories to execute operational instructions,
The system is
Providing the RSU device with a listing certificate detailing the geographic area for the RSU device;
Receiving an application certificate request for the RSU device;
Determining operating 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
In response to the request, providing an application program certificate including operation location information to the RSU device geographically restricted according to the operation location information of the application program certificate;
A system, characterized in that to perform.
The method of claim 15, wherein the request includes operational location information for the RSU device, and determining the operational location information for the RSU device in response to the request comprises obtaining operational 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 configured with operational location information, and the RSU device includes operational location information in the request.
The method of claim 15, wherein the operation is
Prior to receiving the request for an application certificate, receiving a request including operating location information for the RSU device for storing operating location information for the RSU device; And
In response to the request, storing operating location information for the RSU device; further comprising,
And determining the operating location information for the RSU device in response to the request comprises obtaining the stored operating location information.
20. The system of claim 19, wherein a request to store operational location information is received from a user of the RSU device.

Images