WO2011025809A1 - Method and system for use in managing vehicle digital certificates - Google Patents
Method and system for use in managing vehicle digital certificates Download PDFInfo
- Publication number
- WO2011025809A1 WO2011025809A1 PCT/US2010/046596 US2010046596W WO2011025809A1 WO 2011025809 A1 WO2011025809 A1 WO 2011025809A1 US 2010046596 W US2010046596 W US 2010046596W WO 2011025809 A1 WO2011025809 A1 WO 2011025809A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- vehicle
- certificate
- anonymous
- communication device
- crls
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
Definitions
- the present invention relates to the field of vehicle digital certificates management.
- V2V Vehicie-to-vehicle communications allow vehicles to interact with each other via radio waves by sending and receiving information.
- This technology is expected to improve traffic safety, such as in the prevention of vehicle collisions.
- vehicles broadcasting messages alert nearby vehicles of accidents, sudden lane changes, hazardous road conditions, etc. and assist in the reduction of traffic jams and ultimately CO2 emissions.
- Wireless radio devices are mounted in the vehicle.
- messages broadcast by the radio devices are cryptographically secured to ensure the message receivers of the authenticity and integrity of the message payloads and senders.
- These security functions are typically achieved with what is known in the field of cryptography as digital certificates.
- ViDC Vehicle Identifying Digital Certificates
- AVDCs updated Anonymous Vehicle Digital Certificates
- Certificate Revocation Lists to update their credentials, replace expired certificates, and be able to check the validity of messages signed with digital certificates.
- the challenge is to efficiently provide these updated VIDCs, AVDCs and CRLs in a manner consistent with the vehicle communications environment.
- CRLs commonly known as digital certificate management
- CA Certificate Authority
- a CA is a computer server system that typically operates in a land-based network infrastructure and is accessed by vehicles through one or more networks access methods.
- V2V communications may (or will) not be available for vehic!es-to-network infrastructure (V2!
- DSRC Dedicated Short Range Communications
- An object of the present invention is to describe a system and method for enabling vehicle certificate management functions in a vehicle network environment that has no or very limited dedicated roadside network infrastructure. If DSRC is used, the present invention allows vehicles to manage their digital certificates even when they cannot use DSRC to communicate with land-based CAs.
- the present invention enables vehicles to update their
- VIDCs identifying certificates
- AVDCs anonymous certificates
- CRLs receive the latest CRLs through a proxy agent in a wireless mobile device, such as a cellular phone or persona! digital assistant, that provides network connectivity and local storage of certificate updates and CRLs with a level of security and privacy similar to when the vehicle itself has direct connectivity with the CA to manage its certificates.
- a wireless mobile device such as a cellular phone or persona! digital assistant
- CA proactively downloads and stores the latest CRLs and anonymous certificates to be rekeyed and transfers them to any vehicle that can establish network connections and communicate with it.
- the proxy agent provides a mobile cache of CRLs and anonymous certificates to be rekeyed for fast transfer to nearby vehicles.
- the Proxy CA effectively enables vehicle certificate management in a vehicle network
- the present invention may be described as an apparatus for use in a system for managing digital certificates, the system including a one or more certificate authorities and a vehicle- bound digital certificate manager, the apparatus comprising: a mobile client having a wireless transceiver with internet protocol capabilities and a vehicle communication device; the client further including at least one processor and at least one non-transitory computer readable medium encoded with instructions, which when loaded on the at least one computer, establishes processes for information handling, comprising: establishing secure communications with a certificate authority to receive at ieast one of a Vehicle Identification Digital Certificate ("VIDC”), an Anonymous Vehicle digital Certificate ( "AVDC”), and a Certificate Revocation List (“CRL”); storage management of at least one of the VIDCs 1 AVDCs, and CRLs; and forwarding of at least one of the VIDCs, AVDCs, and CRLs received from the certificate authority to the vehicle-bound digital certificate manager using the vehicle communication device.
- VIP Vehicle Identification Digital Certificate
- AVDC Anonymous Vehicle digital Certificate
- CRL Certificate Revocation List
- the invention may be described as an apparatus for use in a system for managing digital certificates, the system including a mobile client having a wireless transceiver with internet protocol capabilities, the apparatus comprising: a vehicle onboard computer unit, including a vehicle communication device and a vehicle-to-vehicle wireless communication device; the vehicle on-board computer unit further including at ieast one processor and at least one non-transitory computer readable medium encoded with instructions, which when loaded on the at least one computer, establishes processes for information handling, comprising: secure receipt from the mobile client via the vehicle communication device of at least one of a Vehicle Identification Digital Certificate ("ViDC"), one or more Anonymous Vehicle Digital Certificates ("AVDCs”), and a Certificate Revocation Lists ("CRLs"); storage management of at least one of the VIDCs, AVDCs, and CRLs received from the mobile client; and forwarding of at !east one of the AVDCs, and CRLs received from the mobile client to another vehicle using the vehicie-to-
- ViDC Vehicle
- the invention may a!so be described as a method for
- a wireless client establishing secure communications with from the certificate authority using its native network means and receiving at least one of a Vehicle Identification Digital Certificate ("VIDC”), an Anonymous Vehicle Digital Certificates ( "AVDCs”), and Certificate Revocation Lists ("CRLs"); storing at least one of the VIDC, AVDCs, and CRL; and forwarding of at least one of the VIDCs, AVDCs, and CRLs from the wireless client to the vehicle-bound digital certificate manager using a vehicle communication device. And again, one or more of each of the VIDCs, AVDCs, and CRLs may be received,
- the method of the present invention may further comprise: forwarding of at least one of the AVDCs and CRLS received from the mobile client to another vehicle using a vehicle-to-vehicle wireless communication device.
- Figure 2 illustrates vehicle data transfer protocol
- Figure 3 illustrates CRL distribution with a Proxy CA
- Figure 4 illustrates Anonymous Certificate distribution with a
- Figure 5 illustrates vehicle Anonymous Certificate
- Figure 6 illustrates a Proxy CA and Vehicle Certificate
- Figure 7 illustrates interaction between a neighborhood CA and vehicles.
- a Proxy CA may be viewed as application software that runs on wireless mobile devices and enables the update of vehicle certificates and CRLs. It communicates with certificate authorities and servers using internet Protocol (IP) communications services provided over the wireless communications mechanism native to the mobile device and maintains a local store of certificate updates and the latest CRLs. it also communicates with the vehicle's on-board computer unit (OBU) to download the latest CRLs to the vehicle and updates its certificates.
- IP internet Protocol
- OBU on-board computer unit
- a Proxy CA communicates with a Vehicle
- Certificate Manager which is application software that runs on the vehicle OBU. Their communications may take place over Bluetooth, serial port, or other means of bi-directional communications capabilities available on the vehicle OBU.
- Proxy CA Proxy
- Proxy CA is associated with one or more
- the association allows the Proxy CA to make requests and receive replacement identifying certificates on behalf of the vehicles; however, the Proxy CA does not learn any identifying information about the vehicle itself. It also works as a proactive (or push) mechanism to distribute CRLs and shared anonymous certificates to other vehicles as iong as it can establish a communication channel with their Vehicle Certificate Managers.
- the Proxy CA is a flexible, inexpensive, and widely deployable mechanism for distributing CRLs and updating shared anonymous certificates using network connectivity that drivers are likely to bring into the vehicle and thereby overcome the constraints of no (or limited) deployment of dedicated roadside infrastructure in the vehicle network environment.
- FIG. 1 graphically shows the architectural components needed to manage vehicle certificates by means of the Proxy CA.
- the key components are:
- CA Vehicle Identity Certificate Authority
- Proxy CA application software that runs on a mobile wireless device, such as PDAs and smart phones, and acquires and maintains local storage of certificate updates and the latest CRLs by communicating with the Identity CA 1 Anonymous CA 1 AUL Server and CRL Server through its native network connectivity, such as commercial wireless service, and makes them available to one or more vehicles.
- Vehicle Certificate Manager (not shown in Figure 1) - application software that runs on the vehicle OBU and manages vehicle identifying and anonymous certificates by communicating with the Proxy CA when a dedicated roadside infrastructure is not available.
- CAs, CRL, and AUL servers are functional components.
- the exact architectural arrangement of a given component depends on specific implementation and deployment requirements, which are known to those skilled in the art and are not deait with herein.
- all the CAs and Vehicle Certificate Manager are provisioned with digital certificates that ailow mutual authentication of each other.
- the digital certificate of the Vehicle Certificate Manager uniquely identifies the Vehicle Certificate Manager and does not contain any information about the vehicle or OBLJ on which it runs.
- the Vehicle Certificate Manager can access and use the private and public keys of the vehicle's certificates.
- VCM_CERTi the Vehicle Certificate Manager's digital certificate trusted by the Identity CA • ⁇ yiN ⁇ k , a ciphertext produced by computing a digital signature of the vehicle's identification number (ViN) with VCM_CERT, and then encrypting the ViN and the digital signature with the public key of the identity CA
- the dealership or vehicle owner preferably performs the following tasks (assuming the vehicle OBE is Bluetooth-capable):
- Step 1 of Figure 2 the Vehicle Certificate Manager sends the serial number of its VCM_CERTj as a way of asking if the Proxy CA has its vehicle data. If the Proxy CA answers no (as shown in Step 2 of Figure 2), the Vehicle Certificate Manager sends ⁇ VCM_CERT h (ViNh ) 1 called Vehicle Data, to the Proxy CA, which stores it. if the Proxy CA answers yes, the Vehicie Certificate Manager understands that the Proxy CA already has its Vehicie Data.
- VCM_CERTj the serial number of its VCM_CERTj
- ViNh Vehicle Data
- Step 3 of Figure 2 may seek the customer's approval before sending the Vehicie Data in Step 3 of Figure 2 by alerting the customer with a pop-up dialog box on the dashboard display of the vehicle or other user interface (Ul) mechanisms and waiting for his or her response.
- the customer may have pre-configured the Vehicle Certificate Manager to acquire updates when available.
- the Proxy CA and Vehicle Certificate Manager proceed to download and install the identifying and anonymous certificates in the vehicle.
- the Proxy CA aiso downloads the CRLs of identifying and anonymous certificates and transfers them to the Vehicle Certificate Manager.
- the processes for these tasks are preferably the same as the ones used during normal operation.
- Certificate Revocation Lists are public data meant to be openly distributed to any entity or application that needs them.
- a CRL is typically accompanied by a digital signature of the CA that has issued it,
- One or ail methods can be used in combination with one another to improve the timeliness of CRL distribution and coverage in the population of vehicles.
- FIG. 3 graphically illustrates the process of CRL distribution to the Proxy CA.
- the Identity CA and Anonymous CA periodically publish the latest CRLs of identifying certificates and anonymous certificates, respectively, to the CRL Server.
- the CRL publication includes timestamp or version information.
- the Proxy CA periodically contacts the CRL server to determine if new CRLs have been published. It retrieves the timestamp or version information of the latest CRLs and compares them with those of the CRLs it has previously downloaded.
- the Proxy CA downloads the latest CRLs from the CRL Server on an as-needed basis.
- the CRL Server may be implemented as a Web server, and the Proxy CA as a Web client, and the HTTP protocol over TCP/IP may be used to realize the described request-response communications and transfer of CRLs.
- the Proxy CA stores the received CRLs on the mobile device and transfers them to the Vehicle Certificate Manager of any vehicle with which it can establish a Bluetooth connection.
- Proxy CA distribution is to seed some vehicles with the latest CRL and enable them to propagate it to the vehicle network using V2V
- a convenient seeding mechanism is to install the latest CRL in new vehicles during production. Each year approximately 10 to 15 million new vehicles are introduced into the vehicle population in the US, which is fairly stable from year to year at about 200 million vehicles, with a slight growth likely following the population growth.
- New vehicles can be equipped with the current CRL to
- a major benefit of this method is that it takes advantage of an existing process and introduces no infrastructure connectivity requirements in the vehicle network.
- Another method of seeding is to deploy the latest CRL on government vehicles, such as police cars and emergency vehicles, which already have infrastructure connectivity independent of vehicle networks.
- the CRL can propagate as these vehicles interact with the vehicle population in the normal course of their activity.
- CRLs from vehicle-to-vehicie can occur using a simple V2V protocol.
- vehicles communicate with one another, they each can broadcast their CRL version as part of their normal safety messaging.
- the vehicle with the most current CRL then broadcasts it to the group.
- Vehicles with older CRLs acquire the more recent CRL and begin to use and propagate it to other vehicles.
- the origin and integrity of the CRL can be determine by each vehicle to attest to its legitimacy.
- CRLs can be periodically broadcast to ail vehicles within the coverage area of the satellite.
- the current satellite fleet used by the provider Sirius at least one of its three satellites broadcast directly over the US at times, enabling CRLs to be broadcast to the entire vehicle population in a single instance.
- a major benefit of this approach is that it leverages the satellite receiver already built into most new vehicles and does not require any additional dedicated vehicle hardware. However, it does require bandwidth on satellite
- V2V propagation with sateliite broadcast may not require satellite receivers to be a critical part of the safety system for each vehicle.
- the Anonymous CA periodically publishes a list of Anonymous Certificates to be replaced, it can do so because it knows the expiration dates of anonymous certificates and whether a certificate has been placed on the CRL.
- AUL Anonymous Certificate List
- the Vehicle Certificate Manager receives an Anonymous Certificate List (AUL) (from the Proxy CA), it processes the list to determine if the vehicle has the anonymous certificates being replaced and installs new certificates and key pairs on an as-needed basis.
- An AUL has more security requirements than a CRL.
- an entry in an AUL consists of the following
- the Anonymous CA's digital signature secures the integrity of the entire content of a given AUL.
- the current holder of a to-be-replaced anonymous certificate can decrypt ⁇ NEW_CERT ⁇ o i d j ⁇ and gain access to the replacement certificate and the corresponding key materials.
- the serial number of an old anonymous certificate is included to allow the Vehicle Certificate Manager on the vehicle OBU to quickly determine if the vehicle has the old anonymous certificate.
- the replacement certificate has its own, unique serial number.
- Anonymous certificates in a shared certificate management scheme provide privacy by virtue of each individual certificate is held by multiple certificates.
- the Anonymous CA issues a given anonymous certificate to a given vehicle in a way that maximizes the certificate's likelihood of being co-owned by neighboring vehicles.
- the described anonymous certificate management approach ensures that the new anonymous certificate has the same likelihood of co-ownership as the one that it replaces without the Anonymous CA performing additional computations.
- Certificate List Server (AUL Server), as shown in Figure 4. From a functional and architectural point of view, the AUL Server plays a similar role to that of the CRL
- AULs anonymous certificate lists published by the Anonymous CA and distributes AULs to the Proxy CA on a request-response basis.
- the Proxy CA periodically communicates with the
- AUL server to determine if new AULs have been published. It retrieves the timestamp or version information of the latest AULs and compares them with those of the AULs it has previously downloaded.
- the AUL Server may be implemented as a Web server, and the Proxy CA as a Web client, and the HTTP protocol over TCP/IP may be used to realize the described request-response communications and transfer of AULs.
- the Proxy CA stores the received AULs on the mobile device and transfers them to the Vehicle Certificate Manager of any vehicle with which it can establish a Bluetooth connection. Furthermore, AULs can be distributed among vehicle by V2V communication.
- AULs are managed by the Anonymous CA such that an anonymous certificate is not replaced by means of AUL publication more than a maximum number of times, MAX_REKEY,
- the Anonymous CA does not include in the AUL an anonymous certificate that an intrusion detection system (IDS) has identified as having been misused.
- IDS intrusion detection system
- the Identity or Anonymous CA can interact with its respective intrusion detection system and determine whether or not to rekey the vehicle.
- each Vehicle Certificate Manager can wait for a random period of time subsequent to
- Replacements for anonymous certificates can be also distributed via satellite broadcast using the same AUL concept. Instead of the AUL server downloading the AUL to a Proxy CA, it would interconnect with a satellite broadcast system that would periodically transmit the AUL directly to vehicles in the satellite's coverage area. Upon acquiring the AUL through their satellite receivers, the Vehicle Certificate Manager would perform the certificate replacement process as previously described.
- the satellite broadcast of AULs does not provide the means for the CA to deny certificate replacement to vehicles that have been identified as misbehaving. Since satellite broadcasts are one-way and do not provide the means for vehicles to contact the Anonymous CA for certificate replacement, the application of the AUL management rules used in the case of the Proxy CA result in a permanent depletion of certificates.
- the Proxy CA approach with its two-way communication provides a more advantageous solution that supports the removal of misbehaving vehicles.
- the Proxy CA To update the identifying certificates of its associated vehicle, the Proxy CA periodically, or on request by the Vehicle Certificate Manager on the vehicle OBU, communicates with the Identity CA. First, the Proxy CA sends the Vehicle Data of its associated vehicle to the identity CA. The Vehicle Data is cryptographically secured so that only the Identity CA can decrypt ⁇ VIN ⁇ k in the Vehicle Data and check the integrity of the decrypted VIN by verifying the accompanying digital signature with the Vehicle Certificate Manager's digital certificate. [0078] Upon receiving the request from the Proxy CA, the identity
- CA retrieves the VIN from the received Vehicle Data and determines if any identifying certificates have been issued for the corresponding vehicle and checks the status of each issued certificate. It also records ⁇ VI N, VCM_CERTfr for later use (for example, when authorizing the Anonymous CA to issue anonymous).
- the Identity CA sends the following data to the
- the Identity Server may be implemented as a Web server, and the Proxy CA as a Web client, and the HTTP protocol over TCP/IP may be used to realize the described request-response communications.
- the Proxy CA stores the ⁇ ID_CERTS ⁇ k and (ID_KEYS ⁇ k on the mobile devices until it sends them to the Vehicle Certificate Manager of the associated vehicle.
- the Proxy CA or the attacker of the mobile device, preferably cannot retrieve the plain text of identifying certificates from ⁇ ID_ CER TS ⁇ k without having first compromised the vehicle OBLJ and obtained the private key of the Vehicle Certificate Manager. As such, storing ⁇ ID_CERTS ⁇ k and ⁇ ID_KEYS ⁇ k on the mobile device does not incur new security risks.
- the Anonymous CA manages anonymous certificates by way of publishing anonymous certificate lists (AULs) via the AUL Server. However, it still needs to issue anonymous certificates to individual vehicles when the vehicle is put into service for the first time.
- the provisioning of the initial set of anonymous certificates may occur during OBE assembly, vehicle manufacture, or vehicle sale.
- the Proxy CA is used to provision the initial set of certificates by "pulling" anonymous certificates from the Anonymous CA when it first receives the Vehicle Data from the Vehicle Certificate Manager.
- a critical goal of this transaction is to provide the same level of security as when issuing vehicle identifying certificates while preserving the identity of the vehicle hidden from the Anonymous CA.
- Anothergoal is to allow the Anonymous CA to keep track of how often the vehicle has asked for replacement anonymous certificates. If the frequency is too high, the vehicle may be a "bad actor,” and an appropriate action should be taken. To remove "bad actors" from the system, the Anonymous CA collaborates with the Identity CA as graphically illustrated in Figure 5..
- the Proxy CA To pull the anonymous certificates, the Proxy CA first sends the ⁇ VIN ⁇ k in the Vehicle Data to the Anonymous CA , which forwards it to the Identity CA. As when issuing identifying certificates, the Identity CA determines the authenticity of the received ⁇ VIN ⁇ k by decrypting and checking the data integrity of the VlN. For the latter, the Identity CA first looks up the certificate, VCM_CERTi, of the Vehicle Certificate Manager associated with the VIN, If successful, the Identity CA sends the Anonymous CA a permission to issue anonymous certificates. If unsuccessful, the Identity CA instructs the Anonymous CA to deny the request from the Proxy CA. [0085] When authorizing the Anonymous CA to issue anonymous certificates, the Identity CA sends the following data to the Anonymous CA:
- Anonymous CA generates the replacement anonymous certificates, digitally signs them with its own certificate, and encrypts them with the symmetric keys received from the Identity CA, Subsequently, the Anonymous CA sends the following data to the Proxy CA:
- the Anonymous CA notifies the Identity CA of the number of replacement anonymous certificates issued to the vehicle with (VlNj k and time of issuance. This information allows the Identity CA to keep track of the history of anonymous certificate issuance, which, in turn, can be used for detection of compromised vehicles and/or bad actors. Note that the Identity CA does not know what anonymous certificates have been issued to the vehicle, while the Anonymous CA does not know the identity of the vehicle.
- Proxy CA stores ⁇ ANONY_CERTS ⁇ k and ⁇ ANONY_KEYS ⁇ k on the mobile devices until it can send them to the Vehicle Certificate Manager of the associated vehicle. Note that the Proxy CA, or the attacker of the mobile device, cannot retrieve the plaintext of anonymous certificates without having first compromised the vehicle OBU and obtained the private key of the Vehicle
- Certificate Manager As such, storing ⁇ ANONY_CERTS ⁇ k and ⁇ ANONY_KEYS ⁇ k on the mobile device does not incur new security risks.
- Proxy CA provides a Bluetooth service, in which it functions as the server while the Vehicle Certificate Manager as the client.
- Bluetooth Device and Service Discovery mechanisms are used for the Vehicle Certificate Manager client to detect the presence of the Proxy CA server.
- the service uses the Bluetooth Object Push Profile ⁇ or File Transfer Profile) to transfer from the Proxy CA's mobile device to the Vehicle Certificate Manager's OBU the following:
- the described data transfer service can be augmented with a discovery mechanism or protocol that allows the Vehicle Certificate Manager to determine if it needs to transfer the AULs and CRLs from the Proxy CA's mobile device in the first place.
- the service's Bluetooth URL can contain timestamp parameters that indicate the time and date of the Proxy CA's previous CRL and AUL downloads. Such information can be used by the Vehicle
- Certificate Manager to determine if it should connect to the service in the first place.
- the Proxy CA provides a vehicle certificate management method that requires no dedicated roadside network infrastructure. It should be noted that the function of updating certificates for individual vehicles is cleanly separated from that of updating CRLs and AULs on a vehicle population. This increases the flexibility in how the Proxy CA-based system can be deployed. For example, the function of distributing CRLs and AULs can be implemented on "public" radio devices, such as those issued for police work, while consumer mobile devices are used to update certificates on associated vehicles only. In this arrangement, consumer mobile devices can be freed from downloading and distributing data meant for public consumption.
- the Vehicle Certificate Manager of an opted-in vehicle sends the Vehicle Data to the Vehicle Certificate Manager on, for example, a neighborhood patrol car via a (DSRC) V2V broadcast mechanism. This establishes an association between the vehicle and the neighborhood patrol car.
- the Proxy CA on the patrol car then sends the Vehicle Data to the Proxy CA on a networked wireless device or computer, which acquires identifying and anonymous certificates from the CAs and transfers them back to the Vehicle Certificate Manager of the patrol vehicle OBU, which, in turn, transfers them to the associated vehicle via the same V2V broadcast mechanism.
- the Vehicle Certificate Manager on the patrol vehicle is called the Neighborhood Proxy CA, which completely frees opted-in end users from having to use their mobile devices to manage certificates.
- the request- response transaction between the Neighborhood Proxy CA and vehicles may be asynchronous.
- the Neighborhood Proxy CA can indicate its presence to nearby vehicles by broadcasting a message with a unique ID signed with a digital certificate issued by the Identity CA. This way, a vehicle can recognize a
- ⁇ nCAj k is the unique ID of the Neighborhood Proxy CA signed with a certificate issued by the identity CA. All the messages, HELLO, GET, RETRIEVE, and SET, are broadcast messages.
- HELLO announces the presence of the Neighborhood Proxy CA
- GET is the vehicle's request to the Neighborhood Proxy CA to acquire update certificates
- RETRIEVE announces the vehicle's presence to the Neighborhood Proxy CA
- SET sends the update certificates to the vehicle.
- the ⁇ CERTS ⁇ k parameter In the SET message indicates the identifying and anonymous update certificates for the vehicle cryptographically.
- the described concept of the Neighborhood proxy CA takes advantage of the fact that the residents in a given community tend to have repeating travel patterns and that the number of vehicles in a given community is much smaller than that on major highways or roadways.
- the former increases the likelihood that neighborhood patrol vehicles and resident vehicles will encounter each other frequently.
- the latter reduces the inefficiency in network bandwidth usage in broadcasting identifying certificates by increasing the likelihood that a given broadcast message will contain identifying certificates relevant to vehicles in the same radio coverage area.
- the OBLJ on the Neighborhood Proxy CA vehicle does not function as a roadside network infrastructure unit. Rather, it functions as a special OBU capable of receiving the Vehicle Data of and transmitting updated certificates to associated vehicles over the broadcast medium.
Landscapes
- Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
A system and method is provided for managing digital certificates, the system including one or more a certificate authorities and a vehicle-bound digital certificate manager, the apparatus comprising: a mobile client having a wireless transceiver with internet protocol capabilities and a vehicle communication device; the client further including at least one processor and at least one non-transitory computer readable medium encoded with instructions, which when loaded on the at least one computer, establishes processes for information handling, comprising: establishing secure communications with a certificate authority to receive at least one of a Vehicle identification Digital Certificate ("VIDC"), an Anonymous Vehicle digital Certificate {"AVDC"), and a Certificate Revocation Lists ("CRLs"); storage management of at least one of the ViDC, AVDCs, and CRLs; and forwarding of at least one of the VIDC, AVDCs, and CRLs received from the certificate authority to the digital certificate manager using the vehicle communication device.
Description
METHOD AND SYSTEM FOR USE IN MANAGING VEHICLE DIGITAL
CERTIFICATES
BACKGROUND
RELATED APPLICATION
[0001] This application claims priority from Provisional Application No.
61/237,414, filed August 27, 2009, the contents of which are hereby expressly incorporated by reference.
TECHNICAL FIELD
[0002] The present invention relates to the field of vehicle digital certificates management.
DESCRIPTION OF THE RELATED ART
[0003] In a typical Intelligent Transportation System (ITS), vehicles communicate with each other for a variety of applications, including safety, mobility, entertainment, and commerce. Vehicie-to-vehicle (V2V) communications allow vehicles to interact with each other via radio waves by sending and receiving information. This technology is expected to improve traffic safety, such as in the prevention of vehicle collisions. In particular, vehicles broadcasting messages alert nearby vehicles of accidents, sudden lane changes, hazardous road conditions, etc. and assist in the reduction of traffic jams and ultimately CO2 emissions.
[0004] Wireless radio devices are mounted in the vehicle. Preferably messages broadcast by the radio devices are cryptographically secured to ensure the message receivers of the authenticity and integrity of the
message payloads and senders. These security functions are typically achieved with what is known in the field of cryptography as digital certificates.
[0005] in such a system, vehicles have a periodic need to receive updated Vehicle Identifying Digital Certificates ("ViDC"), updated Anonymous Vehicle Digital Certificates ("AVDCs") and updated
Certificate Revocation Lists ("CRLs") to update their credentials, replace expired certificates, and be able to check the validity of messages signed with digital certificates. The challenge is to efficiently provide these updated VIDCs, AVDCs and CRLs in a manner consistent with the vehicle communications environment.
[0006] Distribution, update, and removal of digital certificates and
CRLs, commonly known as digital certificate management, are an active area of research in vehicle networks. In general, individual vehicles communicate with a special component, called a Certificate Authority (CA) for certificate management. A CA is a computer server system that typically operates in a land-based network infrastructure and is accessed by vehicles through one or more networks access methods.
[0007] As the ITS evolves, it has become increasingly likely that the same wireless technologies used for V2V communications may (or will) not be available for vehic!es-to-network infrastructure (V2!)
communications needed for vehicles to communicate with CAs.
Specifically, a particular WiFi-like technology, called Dedicated Short Range Communications (DSRC) is considered to be the most suitable
wireless technology to realize V2V communications needed for broadcasting vehicle safety messages. However, it is highly unlikely that a DSRC network infrastructure needed for DSRC-equipped vehicles to communicate with CAs and other application servers wiil be available anytime soon. Such a network would require the deployment of hundreds of thousands of DSRC access points along intersections and major roadways to create what is commonly referred to as the dedicated roadside network infrastructure.
[0008] An object of the present invention is to describe a system and method for enabling vehicle certificate management functions in a vehicle network environment that has no or very limited dedicated roadside network infrastructure. If DSRC is used, the present invention allows vehicles to manage their digital certificates even when they cannot use DSRC to communicate with land-based CAs.
SUMMARY
[0009] It is important to understand that both the foregoing general description and the following detailed description are exemplary and explanatory only, and are not restrictive of the invention as claimed.
[0010] The present invention enables vehicles to update their
identifying certificates (VIDCs) and anonymous certificates (AVDCs) and receive the latest CRLs through a proxy agent in a wireless mobile device, such as a cellular phone or persona! digital assistant, that provides network connectivity and local storage of certificate updates
and CRLs with a level of security and privacy similar to when the vehicle itself has direct connectivity with the CA to manage its certificates.
[0011] Specifically, the proxy agent, called the Proxy Certificate
Authority (CA), proactively downloads and stores the latest CRLs and anonymous certificates to be rekeyed and transfers them to any vehicle that can establish network connections and communicate with it. in other words, the proxy agent provides a mobile cache of CRLs and anonymous certificates to be rekeyed for fast transfer to nearby vehicles.
[0012] Once a subset of the entire vehicle population is thus
"seeded" with the latest CRLs and anonymous certificates, they can propagate the CRLs and update certificates to the rest of the population via V2V broadcast mechanisms. Therefore, the Proxy CA effectively enables vehicle certificate management in a vehicle network
environment with no dedicated roadside infrastructure by reusing network connectivity that drivers are likely to bring into their vehicles to update certificates and distribute CRLs.
[0013] In other words, the present invention may be described as an apparatus for use in a system for managing digital certificates, the system including a one or more certificate authorities and a vehicle- bound digital certificate manager, the apparatus comprising: a mobile client having a wireless transceiver with internet protocol capabilities and a vehicle communication device; the client further including at least one processor and at least one non-transitory computer readable medium encoded with instructions, which when loaded on the at least
one computer, establishes processes for information handling, comprising: establishing secure communications with a certificate authority to receive at ieast one of a Vehicle Identification Digital Certificate ("VIDC"), an Anonymous Vehicle digital Certificate ( "AVDC"), and a Certificate Revocation List ("CRL"); storage management of at least one of the VIDCs1 AVDCs, and CRLs; and forwarding of at least one of the VIDCs, AVDCs, and CRLs received from the certificate authority to the vehicle-bound digital certificate manager using the vehicle communication device. One or more of each of the VIDCs, AVDCs, and CRLs may be received.
14] Viewed differently, the invention may be described as an apparatus for use in a system for managing digital certificates, the system including a mobile client having a wireless transceiver with internet protocol capabilities, the apparatus comprising: a vehicle onboard computer unit, including a vehicle communication device and a vehicle-to-vehicle wireless communication device; the vehicle on-board computer unit further including at ieast one processor and at least one non-transitory computer readable medium encoded with instructions, which when loaded on the at least one computer, establishes processes for information handling, comprising: secure receipt from the mobile client via the vehicle communication device of at least one of a Vehicle Identification Digital Certificate ("ViDC"), one or more Anonymous Vehicle Digital Certificates ("AVDCs"), and a Certificate Revocation Lists ("CRLs"); storage management of at least one of the VIDCs, AVDCs, and CRLs received from the mobile client; and forwarding of at
!east one of the AVDCs, and CRLs received from the mobile client to another vehicle using the vehicie-to-vehicle wireless communication device. Again, one or more of each of the ViDCs, AVDCs, and CRLs may be received.
[0015] The invention may a!so be described as a method for
managing digital certificates in a system including a certificate authority and a vehicle-bound digital certificate manager, the method comprising: a wireless client establishing secure communications with from the certificate authority using its native network means and receiving at least one of a Vehicle Identification Digital Certificate ("VIDC"), an Anonymous Vehicle Digital Certificates ( "AVDCs"), and Certificate Revocation Lists ("CRLs"); storing at least one of the VIDC, AVDCs, and CRL; and forwarding of at least one of the VIDCs, AVDCs, and CRLs from the wireless client to the vehicle-bound digital certificate manager using a vehicle communication device. And again, one or more of each of the VIDCs, AVDCs, and CRLs may be received,
[0016] The method of the present invention may further comprise: forwarding of at least one of the AVDCs and CRLS received from the mobile client to another vehicle using a vehicle-to-vehicle wireless communication device.
BRIEF DESCRIPTION OF THE DRAWINGS
[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments. In the drawings:
[0018] Figure 1 illustrates Proxy CA architectural components;
[0019] Figure 2 illustrates vehicle data transfer protocol;
[0020] Figure 3 illustrates CRL distribution with a Proxy CA;
[0021] Figure 4 illustrates Anonymous Certificate distribution with a
Proxy CA;
[0022] Figure 5 illustrates vehicle Anonymous Certificate
management with a Proxy CA;
[0023] Figure 6 illustrates a Proxy CA and Vehicle Certificate
manager communications; and
[0024] Figure 7 illustrates interaction between a neighborhood CA and vehicles.
DESCRIPTION OF THE EMBODIMENTS
[0025] In the following description, for purposes of explanation and not limitation, specific techniques and embodiments are set forth, such as particular sequences of steps, interfaces, and configurations, in order to provide a thorough understanding of the techniques presented here. While the techniques and embodiments will primarily be described in the context of the accompanying drawings, those skilled in the art will further appreciate that the techniques and embodiments can also be practiced in other electronic devices or systems.
[0026] Reference will now be made in detail to exemplary
embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Whenever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.
Overview of Proxy Certificate Authority (CA)
[0027] A Proxy CA may be viewed as application software that runs on wireless mobile devices and enables the update of vehicle certificates and CRLs. It communicates with certificate authorities and servers using internet Protocol (IP) communications services provided over the wireless communications mechanism native to the mobile device and maintains a local store of certificate updates and the latest CRLs. it also communicates with the vehicle's on-board computer unit (OBU) to download the latest CRLs to the vehicle and updates its certificates.
[0028] Preferably, a Proxy CA communicates with a Vehicle
Certificate Manager, which is application software that runs on the vehicle OBU. Their communications may take place over Bluetooth, serial port, or other means of bi-directional communications capabilities available on the vehicle OBU.
[0029] The word, "proxy," is used to indicate that the Proxy CA
proxies the CAs to the vehicle OBU. In general, the main functions of the Proxy CA are to:
• Securely acquire and maintain local copies of the identifying and anonymous certificates for a set of associated vehicles. The association is established at the time of vehicle purchase as described below.
• Download, cache, and transfer Certificate Revocation Lists (CRLs)1 not only to its associated vehicles but to other vehicles.
• Download, cache, and transfer shared anonymous certificates to be rekeyed (also termed updated) to other vehicles.
[0030] Note that the Proxy CA is associated with one or more
vehicles for which it enables the update of their identifying and anonymous certificates. The association allows the Proxy CA to make requests and receive replacement identifying certificates on behalf of the vehicles; however, the Proxy CA does not learn any identifying information about the vehicle itself. It also works as a proactive (or push) mechanism to distribute CRLs and shared anonymous certificates to other vehicles as iong as it can establish a communication channel with their Vehicle Certificate Managers.
[0031] By working as a mobile cache of the latest CRLs and
anonymous certificates to be rekeyed, it can distribute the CRLs and update certificates to as many vehicles as possible and as quickly as possible. In turn, the vehicles themselves can distribute CRLs and shared anonymous certificates to a wider population via native V2V broadcast mechanisms. In short, the Proxy CA is a flexible, inexpensive, and widely deployable mechanism for distributing CRLs and updating shared anonymous certificates using network connectivity that drivers are likely to bring into the vehicle and thereby overcome the constraints of no (or limited) deployment of dedicated roadside infrastructure in the vehicle network environment.
Architectural Components
[0032] Figure 1 graphically shows the architectural components needed to manage vehicle certificates by means of the Proxy CA. The key components are:
• Vehicle Identity Certificate Authority (CA) - manages vehicle identifying certificates
• Anonymous CA - manages vehicle anonymous certificates
• Anonymous Certificate Updates List Server (AUL Server) - distributes vehicle anonymous certificates
• CRL Server - distributes Certificate Revocation Lists
• Proxy CA— application software that runs on a mobile wireless device, such as PDAs and smart phones, and acquires and maintains local storage of certificate updates and the latest CRLs by communicating with the Identity CA1 Anonymous CA1 AUL Server and CRL Server through its native network connectivity, such as commercial wireless service, and makes them available to one or more vehicles.
• Vehicle Certificate Manager (not shown in Figure 1) - application software that runs on the vehicle OBU and manages vehicle identifying and anonymous certificates by communicating with the Proxy CA when a dedicated roadside infrastructure is not available.
[0033] The functional roles of these components are described and discussed in detail below. CAs, CRL, and AUL servers are functional components. The exact architectural arrangement of a given
component depends on specific implementation and deployment requirements, which are known to those skilled in the art and are not deait with herein.
Assumptions
[0034] Preferably, all the CAs and Vehicle Certificate Manager are provisioned with digital certificates that ailow mutual authentication of each other. The digital certificate of the Vehicle Certificate Manager uniquely identifies the Vehicle Certificate Manager and does not contain any information about the vehicle or OBLJ on which it runs. The Vehicle Certificate Manager can access and use the private and public keys of the vehicle's certificates.
Initial Provisioning
[0035] In this section, we describe the initial provisioning tasks that are performed to allow the Proxy CA to interact a vehicle to update its identifying and anonymous certificates of a given vehicle. When the vehicle is manufactured, the vehicle OEM installs on the vehicle OBU:
• Vehicle Certificate Manager software
• Trusted root certificate to validate the certificates of Identity CA and Anonymous CA
• identifying and anonymous private, public key pairs for the Vehicle Certificate Manager
• VCM_CERTi, the Vehicle Certificate Manager's digital certificate trusted by the Identity CA
• {yiN}k, a ciphertext produced by computing a digital signature of the vehicle's identification number (ViN) with VCM_CERT, and then encrypting the ViN and the digital signature with the public key of the identity CA
[0036] At the time of vehicle sale, the dealership or vehicle owner preferably performs the following tasks (assuming the vehicle OBE is Bluetooth-capable):
• Install the Proxy CA software on the customer's mobile device
• Check the pre-configured address information of the CAs, CRL, and AUL servers in the Proxy CA software
• Establish the vehicle OBU and customer's mobile device as Bluetooth peers
• Activate the Proxy CA and Vehicle Certificate Manager on the customer's mobile device and vehicle OBU respectively
[0037] Subsequently, the customer's mobile device and vehicle OBU establish a Bluetooth connection, and the Proxy CA and Vehicle
Certificate Manager discover each other. At this point, the Proxy CA and Vehicle Certificate Manager proceed to run a vehicle data transfer protocol shown in Figure 2,
[0038] The possession of valid vehicle data allows the Proxy CA to receive the vehicle's identifying and anonymous certificates from the CAs. In Step 1 of Figure 2, the Vehicle Certificate Manager sends the serial number of its VCM_CERTj as a way of asking if the Proxy CA has
its vehicle data. If the Proxy CA answers no (as shown in Step 2 of Figure 2), the Vehicle Certificate Manager sends {VCM_CERTh (ViNh )1 called Vehicle Data, to the Proxy CA, which stores it. if the Proxy CA answers yes, the Vehicie Certificate Manager understands that the Proxy CA already has its Vehicie Data. The Vehicle Certificate
Manager may seek the customer's approval before sending the Vehicie Data in Step 3 of Figure 2 by alerting the customer with a pop-up dialog box on the dashboard display of the vehicle or other user interface (Ul) mechanisms and waiting for his or her response. Alternatively, the customer may have pre-configured the Vehicle Certificate Manager to acquire updates when available.
[0039] Note that multiple instances of the Vehicle Data from different vehicles can be stored on the same mobile device. This enables the Proxy CA to interact and support multiple vehicles. Also note that only the identity CA can decrypt {VlN}k with its own private key and verify the digital signature and integrity of the VIN data with the public key of the Vehicie Certificate Manager. Therefore, the Proxy CA, or an attacker of the mobile device, cannot learn any information about the vehicle because the information is encrypted.
[0040] Subsequent to the transfer of the Vehicle Data, the Proxy CA and Vehicle Certificate Manager proceed to download and install the identifying and anonymous certificates in the vehicle. In addition, the Proxy CA aiso downloads the CRLs of identifying and anonymous certificates and transfers them to the Vehicle Certificate Manager. The
processes for these tasks are preferably the same as the ones used during normal operation.
CRL Management and Distribution
[0041] Certificate Revocation Lists (CRLs) are public data meant to be openly distributed to any entity or application that needs them. For integrity protection and authentication, a CRL is typically accompanied by a digital signature of the CA that has issued it,
[0042] Three methods may be used to distribute CRLs to vehicles.
These are:
CRL Downloads to Proxy CA
CRL Seeding with V2V Distribution CRL Broadcast via Satellite
[0043] One or ail methods can be used in combination with one another to improve the timeliness of CRL distribution and coverage in the population of vehicles.
CRL Downloads to Proxy CA
[0044] To facilitate CRL distribution, we introduce the concept of a
CRL Server, which downloads CRLs to the Proxy CA on a request- response basis. Figure 3 graphically illustrates the process of CRL distribution to the Proxy CA. First, the Identity CA and Anonymous CA periodically publish the latest CRLs of identifying certificates and anonymous certificates, respectively, to the CRL Server. The CRL publication includes timestamp or version information.
[0045] Meanwhile, the Proxy CA periodically contacts the CRL server to determine if new CRLs have been published. It retrieves the timestamp or version information of the latest CRLs and compares them with those of the CRLs it has previously downloaded. Finally, the Proxy CA downloads the latest CRLs from the CRL Server on an as-needed basis.
[0046] The CRL Server may be implemented as a Web server, and the Proxy CA as a Web client, and the HTTP protocol over TCP/IP may be used to realize the described request-response communications and transfer of CRLs. The Proxy CA stores the received CRLs on the mobile device and transfers them to the Vehicle Certificate Manager of any vehicle with which it can establish a Bluetooth connection.
CRL Seeding with V2V Distribution
[0047] A second means to distribute CRLs that can coexist with
Proxy CA distribution is to seed some vehicles with the latest CRL and enable them to propagate it to the vehicle network using V2V
communications. A convenient seeding mechanism is to install the latest CRL in new vehicles during production. Each year approximately 10 to 15 million new vehicles are introduced into the vehicle population in the US, which is fairly stable from year to year at about 200 million vehicles, with a slight growth likely following the population growth.
[0048] New vehicles can be equipped with the current CRL to
provide a 5 to 7.5% seeding of the vehicle population on yearly basis. A major benefit of this method is that it takes advantage of an existing
process and introduces no infrastructure connectivity requirements in the vehicle network.
[0049] Another method of seeding is to deploy the latest CRL on government vehicles, such as police cars and emergency vehicles, which already have infrastructure connectivity independent of vehicle networks. The CRL can propagate as these vehicles interact with the vehicle population in the normal course of their activity.
[0050] The propagation of CRLs from vehicle-to-vehicie can occur using a simple V2V protocol. When vehicles communicate with one another, they each can broadcast their CRL version as part of their normal safety messaging. The vehicle with the most current CRL then broadcasts it to the group. Vehicles with older CRLs acquire the more recent CRL and begin to use and propagate it to other vehicles. Given that the CRL is signed by an entity trusted by all vehicles, the origin and integrity of the CRL can be determine by each vehicle to attest to its legitimacy.
CRL Broadcast via Satellite
[0051] Another means to distribute CRLs is to piggyback on existing one-way broadcast services for consumer entertainment.
Specifically, many vehicles, particularly new vehicles, come equipped with satellite radio receivers to decode digital radio broadcasts. CRLs can be periodically broadcast to ail vehicles within the coverage area of the satellite. With the current satellite fleet used by the provider Sirius, at least one of its three satellites broadcast directly over the US at times, enabling CRLs to be broadcast to the entire vehicle population in
a single instance. Due to signal blockage caused by large buildings, natural structures and other facilities, such as indoor and underground parking lots, CRLs wouid be periodically broadcast to provide multiple opportunities for CRL acquisition. A major benefit of this approach is that it leverages the satellite receiver already built into most new vehicles and does not require any additional dedicated vehicle hardware. However, it does require bandwidth on satellite
transmissions, which is generally an expensive mode of communication.
[0052] A benefit of V2V propagation with sateliite broadcast is that it may not require satellite receivers to be a critical part of the safety system for each vehicle.
Anonymous Certificate Distribution with Proxy CA
[0053] In conventional certificate management, the owner of a given certificate initiates the process of updating the certificate when it expires (or is about to expire) or if its certificate is found on a CRL. In other words, it is the responsibiiity of the certificate holder to take proactive actions in the overall certificate management scheme. Anonymous certificates may be managed in a combinatorial certificate management scheme where each vehicle acquires a small number of certificates from a certificate pool that is shared by multiple vehicles. However, having individual vehicles update a shared anonymous certificate in separate, independent transactions is inefficient. Furthermore, having each vehicle update anonymous certificates on its own in an intermittent network environment may introduce too much delay and increase security risks.
[0054] Instead, a proactive approach to anonymous certificate management is presented, in which the Anonymous CA periodically publishes a list of Anonymous Certificates to be replaced, it can do so because it knows the expiration dates of anonymous certificates and whether a certificate has been placed on the CRL. When the Vehicle Certificate Manager receives an Anonymous Certificate List (AUL) (from the Proxy CA), it processes the list to determine if the vehicle has the anonymous certificates being replaced and installs new certificates and key pairs on an as-needed basis.
[0055] An AUL has more security requirements than a CRL.
Specifically, all the entries in a CRL are meant to be received and processed by the entire vehicle population, while each entry in an AUL is meant to be received and installed on a small subset of the vehicle population. Therefore, not only does the entire content of an AUL need to be integrity-protected (ϋke a CRL), but also each entry in the AUL should be cryptographically secured so that only the authorized vehicles can have new certificates.
[0056] Therefore, an entry in an AUL consists of the following
elements:
• SERIAL_NO, the serial number (or its hash) of old
anonymous certificate being replaced
• {NEW_CER7}oid_k, a new anonymous private/public key pair, the corresponding anonymous certificate, and
• the Anonymous CA's digital signature on the key pair and certificate, all of which are encrypted with the public key, old_k, of the old anonymous certificate
[0057] As is the case with a CRL, the Anonymous CA's digital signature secures the integrity of the entire content of a given AUL.
[0058] Preferably, only the current holder of a to-be-replaced anonymous certificate can decrypt {NEW_CERT}oidj< and gain access to the replacement certificate and the corresponding key materials. The serial number of an old anonymous certificate is included to allow the Vehicle Certificate Manager on the vehicle OBU to quickly determine if the vehicle has the old anonymous certificate. The replacement certificate has its own, unique serial number.
[0059] Anonymous certificates in a shared certificate management scheme provide privacy by virtue of each individual certificate is held by multiple certificates. The Anonymous CA issues a given anonymous certificate to a given vehicle in a way that maximizes the certificate's likelihood of being co-owned by neighboring vehicles. The described anonymous certificate management approach ensures that the new anonymous certificate has the same likelihood of co-ownership as the one that it replaces without the Anonymous CA performing additional computations.
[0060] To realize the described anonymous certificate management scheme, we introduce a new system component, called the Anonymous
Certificate List Server (AUL Server), as shown in Figure 4. From a functional and architectural point of view, the AUL Server plays a similar role to that of the CRL
Server in that it stores anonymous certificate lists (AULs) published by the
Anonymous CA and distributes AULs to the Proxy CA on a request-response basis.
[0061] Similarly, the Proxy CA periodically communicates with the
AUL server to determine if new AULs have been published. It retrieves the timestamp or version information of the latest AULs and compares them with those of the AULs it has previously downloaded.
[0062] Finally, the Proxy CA downloads the latest AULs from the
AUL Server on an as-needed basis. The AUL Server may be implemented as a Web server, and the Proxy CA as a Web client, and the HTTP protocol over TCP/IP may be used to realize the described request-response communications and transfer of AULs. The Proxy CA stores the received AULs on the mobile device and transfers them to the Vehicle Certificate Manager of any vehicle with which it can establish a Bluetooth connection. Furthermore, AULs can be distributed among vehicle by V2V communication.
[0063] While AULs distributed by proxy CAs and V2V
communication provide a convenient means to replace anonymous certificates in a fashion that maintains the distribution properties of the shared certificate pool, a mechanism is also needed to enable the Anonymous CA to deny certificate replacement to vehicles that are misbehaving. Gratuitous AUL distribution allows any vehicle with one or more certificates on the list to install a replacement, but it does not provide the means to deny certificate replacements to specific vehicles.
[0064] To address the need for the removal of misbehaving vehicles, additional criteria for creating AULs is imposed, and the two-way communications capability of the proxy CA is invoked. Specifically, AULs are managed by the
Anonymous CA such that an anonymous certificate is not replaced by means of AUL publication more than a maximum number of times, MAX_REKEY,
[0065] in addition, the Anonymous CA does not include in the AUL an anonymous certificate that an intrusion detection system (IDS) has identified as having been misused. The consequence of these two management ruies is that all vehicles will eventually deplete their store of valid anonymous certificates and need to make an explicit request to its associated Proxy CA to pull replacement anonymous certificates directly from the Anonymous CA, a process which is similar to the one for initially provisioning anonymous certificates in vehicles.
During this process, the Identity or Anonymous CA can interact with its respective intrusion detection system and determine whether or not to rekey the vehicle.
[0066] There may be a case in which a group of vehicles may have the same set of anonymous certificates. In such an unlikely scenario, or when anonymous certificates should individually be replaced one at a time, the vehicles may request for replacement anonymous certificates at the same time, which can increase the processing load on the Anonymous CA. To this end, each Vehicle Certificate Manager can wait for a random period of time subsequent to
determining the need for replacement certificates.
[0067] The concept of placing a maximum on certificate publication is consistent with imposing a rekeying threshold on all vehicles for the
combinatorial certificate management scheme in that each vehicle will be able to rekey a certain number of times before additional scrutiny. AUL distribution via the Proxy CA or V2V communication helps makes this process more efficient.
Comparison to Anonymous Certificate Distribution by Satellite
Broadcast
[0075] Replacements for anonymous certificates can be also distributed via satellite broadcast using the same AUL concept. Instead of the AUL server downloading the AUL to a Proxy CA, it would interconnect with a satellite broadcast system that would periodically transmit the AUL directly to vehicles in the satellite's coverage area. Upon acquiring the AUL through their satellite receivers, the Vehicle Certificate Manager would perform the certificate replacement process as previously described.
[0076] While providing efficient distribution of certificate
replacements, the satellite broadcast of AULs does not provide the means for the CA to deny certificate replacement to vehicles that have been identified as misbehaving. Since satellite broadcasts are one-way and do not provide the means for vehicles to contact the Anonymous CA for certificate replacement, the application of the AUL management rules used in the case of the Proxy CA result in a permanent depletion of certificates. The Proxy CA approach with its two-way communication provides a more advantageous solution that supports the removal of misbehaving vehicles.
Vehicle Identifying Certificate Management with Proxy CA
[0077] To update the identifying certificates of its associated vehicle, the Proxy CA periodically, or on request by the Vehicle Certificate Manager on the vehicle OBU, communicates with the Identity CA. First, the Proxy CA sends the Vehicle Data of its associated vehicle to the identity CA. The Vehicle Data is cryptographically secured so that only the Identity CA can decrypt {VIN}k in the Vehicle Data and check the integrity of the decrypted VIN by verifying the accompanying digital signature with the Vehicle Certificate Manager's digital certificate.
[0078] Upon receiving the request from the Proxy CA, the identity
CA retrieves the VIN from the received Vehicle Data and determines if any identifying certificates have been issued for the corresponding vehicle and checks the status of each issued certificate. It also records {VI N, VCM_CERTfr for later use (for example, when authorizing the Anonymous CA to issue anonymous).
[0079] Subsequently, the Identity CA sends the following data to the
Proxy CA in its response to the received request:
• {ID_CERTS}k, new or replacement vehicle identifying certificates, if any, signed by the Identity CA and encrypted with symmetric keys generated by the Identity CA
• (ID-KEYSJk, the above symmetric keys signed by the Identity CA and encrypted with the Vehicle Certificate Manager's public key
[0080] The Identity Server may be implemented as a Web server, and the Proxy CA as a Web client, and the HTTP protocol over TCP/IP may be used to realize the described request-response communications. The Proxy CA stores the {ID_CERTS}k and (ID_KEYS}k on the mobile devices until it sends them to the Vehicle Certificate Manager of the associated vehicle.
[0081] The Proxy CA, or the attacker of the mobile device, preferably cannot retrieve the plain text of identifying certificates from {ID_ CER TS}k without having first compromised the vehicle OBLJ and obtained the private key of the Vehicle Certificate Manager. As such, storing {ID_CERTS}k and {ID_KEYS}k on the mobile device does not incur new security risks.
Initial Provisioning of Vehicle Anonymous Certificates Management through Proxy CA
[0082] As noted above, the Anonymous CA manages anonymous certificates by way of publishing anonymous certificate lists (AULs) via the AUL Server. However, it still needs to issue anonymous certificates to individual vehicles when the vehicle is put into service for the first time. The provisioning of the initial set of anonymous certificates may occur during OBE assembly, vehicle manufacture, or vehicle sale. To this end, the Proxy CA is used to provision the initial set of certificates by "pulling" anonymous certificates from the Anonymous CA when it first receives the Vehicle Data from the Vehicle Certificate Manager. A critical goal of this transaction is to provide the same level of security as when issuing vehicle identifying certificates while preserving the identity of the vehicle hidden from the Anonymous CA.
[0083] Anothergoal is to allow the Anonymous CA to keep track of how often the vehicle has asked for replacement anonymous certificates. If the frequency is too high, the vehicle may be a "bad actor," and an appropriate action should be taken. To remove "bad actors" from the system, the Anonymous CA collaborates with the Identity CA as graphically illustrated in Figure 5..
[0084] To pull the anonymous certificates, the Proxy CA first sends the {VIN}k in the Vehicle Data to the Anonymous CA , which forwards it to the Identity CA. As when issuing identifying certificates, the Identity CA determines the authenticity of the received {VIN}k by decrypting and checking the data integrity of the VlN. For the latter, the Identity CA first looks up the certificate, VCM_CERTi, of the Vehicle Certificate Manager associated with the VIN, If successful, the Identity CA sends the Anonymous CA a permission to issue anonymous certificates. If unsuccessful, the Identity CA instructs the Anonymous CA to deny the request from the Proxy CA.
[0085] When authorizing the Anonymous CA to issue anonymous certificates, the Identity CA sends the following data to the Anonymous CA:
• Symmetric keys to encrypt the anonymous certificates
• {ANONY_KEYS}k, the above keys signed by the identity CA and encrypted with the public key of the Vehicle Certificate Manager
[0086] Upon receiving the authorization from the Identity CA, the
Anonymous CA generates the replacement anonymous certificates, digitally signs them with its own certificate, and encrypts them with the symmetric keys received from the Identity CA, Subsequently, the Anonymous CA sends the following data to the Proxy CA:
• {ANONY_CERTS}k, replacement anonymous certificates signed by the Anonymous CA and encrypted and integrity-protected with the symmetric keys generated by the Identity CA
• {ANONY_KEYS}k, the above keys signed by the Identity CA and encrypted with the public key of the Vehicle Certificate Manager
[0087] Subsequently, the Anonymous CA notifies the Identity CA of the number of replacement anonymous certificates issued to the vehicle with (VlNjk and time of issuance. This information allows the Identity CA to keep track of the history of anonymous certificate issuance, which, in turn, can be used for detection of compromised vehicles and/or bad actors. Note that the Identity CA does not know what anonymous certificates have been issued to the vehicle, while the Anonymous CA does not know the identity of the vehicle.
[0088] Proxy CA stores {ANONY_CERTS}k and {ANONY_KEYS}k on the mobile devices until it can send them to the Vehicle Certificate Manager of the associated vehicle. Note that the Proxy CA, or the attacker of the mobile device,
cannot retrieve the plaintext of anonymous certificates without having first compromised the vehicle OBU and obtained the private key of the Vehicle
Certificate Manager. As such, storing {ANONY_CERTS}k and {ANONY_KEYS}k on the mobile device does not incur new security risks.
Proxy CA and Vehicle Certificate Manager Communications
[0089] In this section, we give an overview of Bluetooth-based communications between the Proxy CA and the Vehicle Certificate Manager of the associated vehicle as shown in Figure 6. Proxy CA provides a Bluetooth service, in which it functions as the server while the Vehicle Certificate Manager as the client. Bluetooth Device and Service Discovery mechanisms are used for the Vehicle Certificate Manager client to detect the presence of the Proxy CA server. The service uses the Bluetooth Object Push Profile {or File Transfer Profile) to transfer from the Proxy CA's mobile device to the Vehicle Certificate Manager's OBU the following:
• {ID_CERTS}k
(IDJ(EYSh
(ANONY_CERTS}k
• (ANONY_KEYSh
• AULs
CRLs
[0090] Because (ID_CERTS}k , {ID_KEYS}κ, {ANONY_CERTS}k, and (ANONY_KEYS}k are only for the vehicle associated with a given Proxy CA, a secure Bluetooth connection may be used, while the transfer of AULs and CRLs can take place over open Bluetooth connections. Note that all the data elements are cryptographically secured with digital certificates of the Identity and
Anonymous CAs and Vehicle Certificate Managers. Therefore, the attacker cannot acquire plain certificate data unless he or she has already compromised one or more of these systems. Therefore, the transfer of these data elements over Bluetooth does not presently add new security risks to certificate data.
[0091] The described data transfer service can be augmented with a discovery mechanism or protocol that allows the Vehicle Certificate Manager to determine if it needs to transfer the AULs and CRLs from the Proxy CA's mobile device in the first place. For example, the service's Bluetooth URL can contain timestamp parameters that indicate the time and date of the Proxy CA's previous CRL and AUL downloads. Such information can be used by the Vehicle
Certificate Manager to determine if it should connect to the service in the first place.
Discussion
[0092] The Proxy CA provides a vehicle certificate management method that requires no dedicated roadside network infrastructure. It should be noted that the function of updating certificates for individual vehicles is cleanly separated from that of updating CRLs and AULs on a vehicle population. This increases the flexibility in how the Proxy CA-based system can be deployed. For example, the function of distributing CRLs and AULs can be implemented on "public" radio devices, such as those issued for police work, while consumer mobile devices are used to update certificates on associated vehicles only. In this arrangement, consumer mobile devices can be freed from downloading and distributing data meant for public consumption.
[0093] Furthermore, end users can completely rely on "public" means for total certificate management on an opt-in basis as follows. The Vehicle
Certificate Manager of an opted-in vehicle sends the Vehicle Data to the Vehicle Certificate Manager on, for example, a neighborhood patrol car via a (DSRC) V2V broadcast mechanism. This establishes an association between the vehicle and the neighborhood patrol car. The Proxy CA on the patrol car then sends the Vehicle Data to the Proxy CA on a networked wireless device or computer, which acquires identifying and anonymous certificates from the CAs and transfers them back to the Vehicle Certificate Manager of the patrol vehicle OBU, which, in turn, transfers them to the associated vehicle via the same V2V broadcast mechanism. In this function, the Vehicle Certificate Manager on the patrol vehicle is called the Neighborhood Proxy CA, which completely frees opted-in end users from having to use their mobile devices to manage certificates. Note that the request- response transaction between the Neighborhood Proxy CA and vehicles may be asynchronous. The Neighborhood Proxy CA can indicate its presence to nearby vehicles by broadcasting a message with a unique ID signed with a digital certificate issued by the Identity CA. This way, a vehicle can recognize a
Neighborhood CA to which it has sent a certificate update request (by sending its Vehicle Data) and retrieve update certificates by broadcasting its presence.
[0094] Figure 7 graphically illustrates the interaction between the
Neighborhood Proxy CA and vehicles. In Figure 7, {nCAjk is the unique ID of the Neighborhood Proxy CA signed with a certificate issued by the identity CA. All the messages, HELLO, GET, RETRIEVE, and SET, are broadcast messages.
HELLO announces the presence of the Neighborhood Proxy CA, GET is the vehicle's request to the Neighborhood Proxy CA to acquire update certificates, RETRIEVE announces the vehicle's presence to the Neighborhood Proxy CA, and SET sends the update certificates to the vehicle. The {CERTS}k parameter In the
SET message indicates the identifying and anonymous update certificates for the vehicle cryptographically.
[0095] The described concept of the Neighborhood proxy CA takes advantage of the fact that the residents in a given community tend to have repeating travel patterns and that the number of vehicles in a given community is much smaller than that on major highways or roadways. The former increases the likelihood that neighborhood patrol vehicles and resident vehicles will encounter each other frequently. The latter reduces the inefficiency in network bandwidth usage in broadcasting identifying certificates by increasing the likelihood that a given broadcast message will contain identifying certificates relevant to vehicles in the same radio coverage area.
[0096] Note that the OBLJ on the Neighborhood Proxy CA vehicle does not function as a roadside network infrastructure unit. Rather, it functions as a special OBU capable of receiving the Vehicle Data of and transmitting updated certificates to associated vehicles over the broadcast medium.
[0097] The foregoing description has been presented for purposes of illustration. It is not exhaustive and does not limit the invention to the precise forms or embodiments disclosed. Modifications and adaptations of the invention can be made from consideration of the specification and practice of the disclosed embodiments of the invention. For example, one or more steps of methods described above may be performed in a different order or concurrently and stiii achieve desirable results.
[0098] Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be
considered as exemplary only, with a true scope of the invention being indicated by the following claims.
Claims
1. An apparatus for use in a system for managing digital certificates, said system including a certificate authority and a vehicle-bound digital certificate manager, said apparatus comprising:
a mobile client having a wireless transceiver with internet protocol capabilities and a vehicle communication device;
said client further including at least one processor and at least one non- transitory computer readable medium encoded with instructions, which when loaded on said at least one computer, establish processes for information handling, comprising:
establishing secure communications with a certificate authority to receive at least one of a Vehicle Identification Digital Certificate ("VIDC"), an Anonymous Vehicle digital Certificate ( "AVDC"), and a Certificate Revocation List ("CRL"); storage management of at least one of said VlDC, AVDCs, and CRLs; and forwarding of at least one of said VIDC, AVDCs, and CRLs received from said certificate authority to said digital certificate manager using said vehicle communication device.
2. An apparatus for use in a system for managing digital certificates, said system including a mobile client having a wireless transceiver with internet protocol capabilities said apparatus comprising:
a vehicle on-board computer unit, including a vehicle communication device and a vehicle-to-vehicle wireless communication device;
said vehicle on-board computer unit further including at least one processor and at least one non-transitory computer readable medium encoded with instructions, which when loaded on said at least one computer, establish processes for information handling, comprising:
establishing secure communications with with said mobile client via said vehicle communication device and receiving of at least one of a Vehicle
Identification Digital Certificate ("VlDC"), an Anonymous Vehicle digital Certificate ( "AVDC"), and a Certificate Revocation Lists ("CRLs");
storage management of at least one of said VIDC, AVDCs, and CRLs received from said mobile client; and
forwarding of at least one of said AVDCs and CRLs received from said mobile client to another vehicle using said vehicle-to-vehicle wireless
communication device.
3. The apparatus of claim 1 further including:
said vehicle on-board computer unit including a vehicle communication device and a vehicle-to-vehicle wireless communication device;
said vehicle on-board computer unit further including at least one processor and at least one non-transitory computer readable medium encoded with instructions, which when loaded on said at least one computer, establish processes for information handling, comprising:
establishing secure communications with said mobile client via said vehicle communication device and receiving of at least one of a Vehicle Identification Digital Certificate ("ViDC"), an Anonymous Vehicle digital Certificate ( "AVDC"), and a Certificate Revocation Lists ("CRLs");
storage management of at least one of said VIDC, AVDCs1 and CRLs received from said mobile client; and forwarding of at least one of said AVDCs and CRLs received from said mobile client to another vehicle using said vehicle communication device.
4. A method for managing digital certificates in a system including a certificate authority and a vehicie-bound digital certificate manager, said method comprising:
receiving on a wireless client from said certificate authority at least one of a Vehicle Identification Digital Certificate ("VIDC"), one or more Anonymous Vehicle Digital Certificates ( "AVDCs"), and one or more Certificate Revocation Lists ("CRLs");
storing at least one of said VIDC, AVDCs, and CRLs; and
forwarding of at least one of said VIDC, AVDCs, and CRLs from said wireless client to said vehicle-bound digital certificate manager using a vehicle communication device.
5. The method of claim 4 further comprising:
forwarding of at least one of said AVDCs and CRLs received from said mobile client to another vehicle using a vehicle-to-vehicle wireless communication device.
6. The apparatus of claim 1 wherein said vehicle communication device comprises one of a Bluetooth, WiFi, or wireless serial port two-way communication device.
7. The apparatus of claim 2 wherein said vehicle communication device comprises one of a Bluetooth, WiFt1 or wireless serial port two-way communication device.
8. The apparatus of ciaim 3 wherein said vehicle communication device comprises one of a Bluetooth, WiFi, or wireless serial port two-way communication device.
9. The method of claim 4 wherein said vehicle communication device comprises one of a Bluetooth, WiFi, or wireless serial port two-way
communication device.
10. The apparatus of claim 1 wherein said mobile client comprises at least one of a cellular phone, PDA, orsmart phone.
11. The apparatus of claim 2 wherein said mobile client comprises at least one of a cellular phone, PDA, or smart phone.
12. The apparatus of ciaim 3 wherein said mobile client comprises at least one of a cellular phone, PDA, orsmart phone.
13. The method of claim 4 wherein said wireless client comprises at least one of a cellular phone, PDA, or smart phone.
14. The method of claim 5 wherein said wireless client comprises at least one of a cellular phone, PDA, orsmart phone.
15. The method of claim 4 further including receiving periodically published a list of ADVCs to be replaced.
16. The method of claim 15 wherein at least one entry of said list of ADVCs to be replaced includes: a serial number or a hash of the serial number of old anonymous certificate being replaced
a new anonymous private/public key pair, the corresponding anonymous certificate, and the Anonymous CA's digital signature of the key pair and certificate, all of which are encrypted with the public key, old_k, of the old anonymous certificate.
17. The method of claim 4 wherein said wireless client sends the VIN of vehicle for which said method Is being applied to a certificate authority.
18. The apparatus of claim 1 wherein said wireless client includes storage management for:
replacement anonymous certificates, (ANONY-CERTSJk, signed by an Anonymous Certificate Authority and encrypted and integrity-protected with symmetric keys generated by an Identity Certificate Authority; and
(ANONY_KEYS}k, the above keys signed by the Identity CA and encrypted with the public key of said vehicle-bound digital certificate manager
19. The method of claim 5 including storing in said wireless client: replacement anonymous certificates, {ANONY_CERTS}k, signed by an
Anonymous Certificate Authority and encrypted and integrity-protected with symmetric keys generated by an Identity Certificate Authority; and
{ANONY_KEYS}k, the above keys signed by the Identity CA and encrypted with the public key of vehicle-bound digital certificate manager.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP10812570A EP2471241A1 (en) | 2009-08-27 | 2010-08-25 | Method and system for use in managing vehicle digital certificates |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US23741409P | 2009-08-27 | 2009-08-27 | |
US61/237,414 | 2009-08-27 | ||
US12/846,055 US20110191581A1 (en) | 2009-08-27 | 2010-07-29 | Method and system for use in managing vehicle digital certificates |
US12/846,055 | 2010-07-29 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2011025809A1 true WO2011025809A1 (en) | 2011-03-03 |
Family
ID=43628358
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2010/046596 WO2011025809A1 (en) | 2009-08-27 | 2010-08-25 | Method and system for use in managing vehicle digital certificates |
Country Status (3)
Country | Link |
---|---|
US (1) | US20110191581A1 (en) |
EP (1) | EP2471241A1 (en) |
WO (1) | WO2011025809A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103477666A (en) * | 2011-03-31 | 2013-12-25 | 英特尔公司 | Connecting mobile devices, Internet-connected vehicles, and cloud services |
EP3640912A1 (en) * | 2018-10-19 | 2020-04-22 | BlackBerry Limited | Method and system for wireless road side units |
FR3099682A1 (en) * | 2019-08-01 | 2021-02-05 | Psa Automobiles Sa | Vehicle communication method and device |
Families Citing this family (35)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9268545B2 (en) | 2011-03-31 | 2016-02-23 | Intel Corporation | Connecting mobile devices, internet-connected hosts, and cloud services |
US8848919B2 (en) * | 2011-06-17 | 2014-09-30 | Assa Abloy Ab | Revocation status using other credentials |
US9342935B2 (en) * | 2013-01-04 | 2016-05-17 | Diamond 18 Ltd. | Smartphone based system for vehicle monitoring security |
FR3006836B1 (en) * | 2013-06-10 | 2016-02-19 | Renault Sas | METHOD FOR DOWNLOADING A PSEUDONYM CERTIFICATE DELIVERED BY A PUBLIC KEY INFRASTRUCTURE FOR A MOTOR VEHICLE AND A MOTOR VEHICLE USING SUCH A METHOD |
US9450970B2 (en) * | 2013-08-12 | 2016-09-20 | Wal-Mart Stores, Inc. | Automatic blocking of bad actors across a network |
US9680650B2 (en) | 2013-08-23 | 2017-06-13 | Qualcomm Incorporated | Secure content delivery using hashing of pre-coded packets |
DE112014006407B4 (en) * | 2014-02-26 | 2022-06-02 | Mitsubishi Electric Corporation | Certificate management device and certificate management method |
KR20160038091A (en) * | 2014-09-24 | 2016-04-07 | 현대자동차주식회사 | Method and System for Issuing CSR Certificate for Vehicle-to-Anything Communication |
US9602290B2 (en) * | 2014-10-16 | 2017-03-21 | Infineon Technologies Ag | System and method for vehicle messaging using a public key infrastructure |
US10439908B2 (en) | 2014-12-23 | 2019-10-08 | Talari Networks Incorporated | Methods and apparatus for providing adaptive private network centralized management system time correlated playback of network traffic |
DE102015107745B4 (en) * | 2015-05-18 | 2023-04-20 | Bayerische Motoren Werke Aktiengesellschaft | Procedure for providing communication resources in intelligent transport systems |
KR101673310B1 (en) * | 2015-08-24 | 2016-11-07 | 현대자동차주식회사 | Method For Controlling Vehicle Security Access Based On Certificate |
US10484351B2 (en) * | 2016-01-28 | 2019-11-19 | Etas Embedded Systems Canada Inc. | System and method for certificate selection in vehicle-to-vehicle applications to enhance privacy |
TWI600334B (en) * | 2016-03-23 | 2017-09-21 | 財團法人工業技術研究院 | Security certificate management method for a vehicular network node and vehicular network node applying the same |
EP3244360A1 (en) * | 2016-05-12 | 2017-11-15 | Skidata Ag | Method for registration of equipment, in particular for access control devices or payment or vending machines in a server of a system comprising several such devices |
JP6756168B2 (en) * | 2016-06-28 | 2020-09-16 | 株式会社オートネットワーク技術研究所 | Communications system |
FR3057973B1 (en) * | 2016-10-25 | 2018-11-30 | Peugeot Citroen Automobiles Sa | METHOD OF INSTALLING A CERTIFICATE IN A VEHICLE COMPUTER, COMPUTER AND ASSOCIATED SYSTEM |
EP3907639A1 (en) | 2016-11-14 | 2021-11-10 | Integrity Security Services Llc | Secure provisioning and management of devices |
US10581620B2 (en) * | 2016-11-14 | 2020-03-03 | Integrity Security Services Llc | Scalable certificate management system architectures |
US10756909B2 (en) * | 2016-12-06 | 2020-08-25 | Veniam, Inc. | Systems and methods for self and automated management of certificates in a network of moving things, for example including a network of autonomous vehicles |
US10171953B2 (en) | 2016-12-15 | 2019-01-01 | At&T Mobility Ii Llc | Vehicle event notification via cell broadcast |
US11025607B2 (en) | 2016-12-15 | 2021-06-01 | At&T Mobility Ii Llc | V2X certificate management |
US11030699B1 (en) | 2017-01-17 | 2021-06-08 | State Farm Mutual Automobile Insurance Company | Blockchain controlled multi-carrier auction system for usage-based auto insurance |
US10805091B2 (en) * | 2017-04-28 | 2020-10-13 | Sap Se | Certificate tracking |
US10680834B2 (en) * | 2018-01-31 | 2020-06-09 | GM Global Technology Operations LLC | Security credential programming system for programming security processor chips of vehicle control modules |
US11184178B2 (en) | 2018-09-28 | 2021-11-23 | Blackberry Limited | Method and system for intelligent transportation system certificate revocation list reduction |
US10439825B1 (en) * | 2018-11-13 | 2019-10-08 | INTEGRITY Security Services, Inc. | Providing quality of service for certificate management systems |
CN111200495A (en) * | 2018-11-20 | 2020-05-26 | 西安华为技术有限公司 | Certificate processing method, device and system for Internet of vehicles |
CN113168483A (en) * | 2018-12-06 | 2021-07-23 | 大众汽车股份公司 | System and method for using global voters using a regional certificate trust list |
US11343106B2 (en) | 2019-04-11 | 2022-05-24 | Lg Electronics, Inc. | Systems and methods for accelerated certificate provisioning |
WO2020229895A2 (en) * | 2019-04-11 | 2020-11-19 | Lg Electronics, Inc. | Systems and methods for countering co-existence attack |
DE102020103391A1 (en) | 2020-02-11 | 2021-08-12 | Bayerische Motoren Werke Aktiengesellschaft | Communication module, means of locomotion and method for operating a communication module |
CN113765668B (en) * | 2020-06-03 | 2024-07-02 | 广州汽车集团股份有限公司 | Vehicle digital certificate online installation method and vehicle digital certificate management device |
CN113810411B (en) * | 2021-09-17 | 2023-02-14 | 公安部交通管理科学研究所 | Traffic control facility digital certificate management method and system |
CN114360107B (en) * | 2021-12-24 | 2024-03-29 | 惠州市德赛西威智能交通技术研究院有限公司 | Intelligent vehicle key method and system for multi-user multi-vehicle |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050030202A1 (en) * | 2003-06-19 | 2005-02-10 | Shoichi Tsuboi | Inter-vehicle communication method and device |
US20070096892A1 (en) * | 2005-10-31 | 2007-05-03 | Lear Corporation | Method and system of alerting hazards |
US20070222555A1 (en) * | 2006-03-27 | 2007-09-27 | Steve Tengler | Security for anonymous vehicular broadcast messages |
US20080148374A1 (en) * | 2003-01-28 | 2008-06-19 | Cellport Systems, Inc. | Secure telematics |
US20080232595A1 (en) * | 2007-03-19 | 2008-09-25 | Telcordia Technologies, Inc. | Vehicle Segment Certificate Management Using Short-Lived, Unlinked Certificate Schemes |
US20080270605A1 (en) * | 2004-04-08 | 2008-10-30 | Viktors Berstis | Distributing and Geographically Load Balancing Location Aware Communication Device Client-Proxy Applications |
US20090019528A1 (en) * | 2005-02-28 | 2009-01-15 | Beijing Lenovo Software Ltd. | Method for realizing network access authentication |
US20090132813A1 (en) * | 2007-11-08 | 2009-05-21 | Suridx, Inc. | Apparatus and Methods for Providing Scalable, Dynamic, Individualized Credential Services Using Mobile Telephones |
Family Cites Families (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6233577B1 (en) * | 1998-02-17 | 2001-05-15 | Phone.Com, Inc. | Centralized certificate management system for two-way interactive communication devices in data networks |
US6510513B1 (en) * | 1999-01-13 | 2003-01-21 | Microsoft Corporation | Security services and policy enforcement for electronic data |
US6934848B1 (en) * | 2000-07-19 | 2005-08-23 | International Business Machines Corporation | Technique for handling subsequent user identification and password requests within a certificate-based host session |
CN1470112A (en) * | 2000-10-20 | 2004-01-21 | ά��ϵͳ��˾ | Cryptographic data security system and method |
US7114175B2 (en) * | 2001-08-03 | 2006-09-26 | Nokia Corporation | System and method for managing network service access and enrollment |
US7996888B2 (en) * | 2002-01-11 | 2011-08-09 | Nokia Corporation | Virtual identity apparatus and method for using same |
WO2006132987A1 (en) * | 2005-06-03 | 2006-12-14 | Board Of Trustees Of Michigan State University | Worm propagation modeling in a mobile ad-hoc network |
US7525933B1 (en) * | 2005-11-30 | 2009-04-28 | At&T Intellectual Property Ii, L.P. | System and method for mobile ad hoc network |
US7734050B2 (en) * | 2006-03-27 | 2010-06-08 | Nissan Technical Center North America, Inc. | Digital certificate pool |
US20080027602A1 (en) * | 2006-05-30 | 2008-01-31 | Yeap Tet H | System and method for deterring theft of vehicles and other products having integral computer means |
US20100138652A1 (en) * | 2006-07-07 | 2010-06-03 | Rotem Sela | Content control method using certificate revocation lists |
US8527770B2 (en) * | 2006-07-20 | 2013-09-03 | Research In Motion Limited | System and method for provisioning device certificates |
US8321677B2 (en) * | 2006-09-21 | 2012-11-27 | Google Inc. | Pre-binding and tight binding of an on-line identity to a digital signature |
SE530637C2 (en) * | 2006-10-11 | 2008-07-22 | Belleshill Ab | Debit in ad-hoc communication networks |
CA2677148C (en) * | 2007-02-02 | 2015-11-24 | Telcordia Technologies, Inc. | Method and system to authorize and assign digital certificates without loss of privacy |
WO2008115984A1 (en) * | 2007-03-19 | 2008-09-25 | Telcordia Technologies, Inc. | Vehicle segment certificate management using shared certificate schemes |
WO2008119948A1 (en) * | 2007-03-30 | 2008-10-09 | British Telecommunications Public Limited Company | Ad hoc communication system |
US8463238B2 (en) * | 2007-06-28 | 2013-06-11 | Apple Inc. | Mobile device base station |
KR100962399B1 (en) * | 2007-08-24 | 2010-06-11 | 한국전자통신연구원 | Method for providing anonymous public key infrastructure and method for providing service using the same |
US8090949B2 (en) * | 2008-03-13 | 2012-01-03 | GM Global Technology Operations LLC | Certificate assignment strategies for efficient operation of the PKI-based security architecture in a vehicular network |
US9461827B2 (en) * | 2008-04-11 | 2016-10-04 | Toyota Motor Engineering & Manufacturing North America, Inc. | Method for distributing a list of certificate revocations in a vanet |
US8316091B2 (en) * | 2008-12-01 | 2012-11-20 | At&T Mobility Ii Llc | Content management for wireless digital media frames |
US8499154B2 (en) * | 2009-01-27 | 2013-07-30 | GM Global Technology Operations LLC | System and method for establishing a secure connection with a mobile device |
US20100202346A1 (en) * | 2009-02-12 | 2010-08-12 | Sitzes Ryan Z | Wireless communication system and method |
US8582775B2 (en) * | 2009-02-12 | 2013-11-12 | General Motors Llc | Method of securing and authenticating data using micro-certificates |
CN101873301B (en) * | 2009-04-22 | 2015-10-21 | 索尼株式会社 | Anonymous registration system and method |
US20110078775A1 (en) * | 2009-09-30 | 2011-03-31 | Nokia Corporation | Method and apparatus for providing credibility information over an ad-hoc network |
US8397063B2 (en) * | 2009-10-07 | 2013-03-12 | Telcordia Technologies, Inc. | Method for a public-key infrastructure for vehicular networks with limited number of infrastructure servers |
US8819414B2 (en) * | 2010-04-19 | 2014-08-26 | GM Global Technology Operations LLC | Threat mitigation in a vehicle-to-vehicle communication network |
US8347080B2 (en) * | 2010-05-10 | 2013-01-01 | Research In Motion Limited | System and method for multi-certificate and certificate authority strategy |
US20120030470A1 (en) * | 2010-07-29 | 2012-02-02 | General Motors Llc | Wireless programming of vehicle modules |
-
2010
- 2010-07-29 US US12/846,055 patent/US20110191581A1/en not_active Abandoned
- 2010-08-25 EP EP10812570A patent/EP2471241A1/en not_active Withdrawn
- 2010-08-25 WO PCT/US2010/046596 patent/WO2011025809A1/en active Application Filing
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080148374A1 (en) * | 2003-01-28 | 2008-06-19 | Cellport Systems, Inc. | Secure telematics |
US20050030202A1 (en) * | 2003-06-19 | 2005-02-10 | Shoichi Tsuboi | Inter-vehicle communication method and device |
US20080270605A1 (en) * | 2004-04-08 | 2008-10-30 | Viktors Berstis | Distributing and Geographically Load Balancing Location Aware Communication Device Client-Proxy Applications |
US20090019528A1 (en) * | 2005-02-28 | 2009-01-15 | Beijing Lenovo Software Ltd. | Method for realizing network access authentication |
US20070096892A1 (en) * | 2005-10-31 | 2007-05-03 | Lear Corporation | Method and system of alerting hazards |
US20070222555A1 (en) * | 2006-03-27 | 2007-09-27 | Steve Tengler | Security for anonymous vehicular broadcast messages |
US20080232595A1 (en) * | 2007-03-19 | 2008-09-25 | Telcordia Technologies, Inc. | Vehicle Segment Certificate Management Using Short-Lived, Unlinked Certificate Schemes |
US20090132813A1 (en) * | 2007-11-08 | 2009-05-21 | Suridx, Inc. | Apparatus and Methods for Providing Scalable, Dynamic, Individualized Credential Services Using Mobile Telephones |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103477666A (en) * | 2011-03-31 | 2013-12-25 | 英特尔公司 | Connecting mobile devices, Internet-connected vehicles, and cloud services |
CN103477666B (en) * | 2011-03-31 | 2018-01-19 | 英特尔公司 | Mobile device is connected, is connected to vehicle and the cloud service of internet |
EP3640912A1 (en) * | 2018-10-19 | 2020-04-22 | BlackBerry Limited | Method and system for wireless road side units |
US11295617B2 (en) | 2018-10-19 | 2022-04-05 | Blackberry Limited | Method and system for wireless road side units |
US11670168B2 (en) | 2018-10-19 | 2023-06-06 | Blackberry Limited | Method and system for wireless road side units |
FR3099682A1 (en) * | 2019-08-01 | 2021-02-05 | Psa Automobiles Sa | Vehicle communication method and device |
Also Published As
Publication number | Publication date |
---|---|
US20110191581A1 (en) | 2011-08-04 |
EP2471241A1 (en) | 2012-07-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20110191581A1 (en) | Method and system for use in managing vehicle digital certificates | |
KR102182082B1 (en) | V2X communication device and data communication method thereof | |
EP2474143B1 (en) | System and methods to perform public key infrastructure (pki) operations in vehicle networks using one-way communications infrastructure | |
JP5367917B2 (en) | OBE | |
JP5587239B2 (en) | Vehicle-to-vehicle / road-vehicle communication system | |
Liu et al. | Securing vehicular ad hoc networks | |
Papadimitratos et al. | Secure vehicular communication systems: design and architecture | |
EP2942921B1 (en) | System and method for filtering digital certificates | |
US8438388B2 (en) | Method and apparatus for distributing certificate revocation lists (CRLs) to nodes in an ad hoc network | |
JP2013513256A (en) | Method for public key infrastructure for automotive networks with a limited number of infrastructure servers | |
WO2013111364A1 (en) | Encryption communication system, communication device, key distribution device, encryption communication method | |
JP3920583B2 (en) | COMMUNICATION SECURITY MAINTAINING METHOD, APPARATUS THEREOF, AND PROCESSING PROGRAM THEREOF | |
TWI600334B (en) | Security certificate management method for a vehicular network node and vehicular network node applying the same | |
Kohli et al. | Security challenges, applications and vehicular authentication methods in VANET for smart traffic management | |
CN1976503B (en) | Method and system for providing safety for communication signal transmitted from server to vehicle | |
WO2013024587A1 (en) | Communication apparatus | |
JP2014158105A (en) | Terminal device | |
Singh et al. | A single-hop based fast certificate revocation protocol in VANET | |
JP4540681B2 (en) | COMMUNICATION SECURITY MAINTAINING METHOD, APPARATUS THEREOF, AND PROCESSING PROGRAM THEREOF | |
Foo et al. | Security issues for future intelligent transport systems | |
EP4184863A1 (en) | Providing secure internet access to a client device in a remote location | |
JP2014158104A (en) | Terminal device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 10812570 Country of ref document: EP Kind code of ref document: A1 |
|
DPE1 | Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101) | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2010812570 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |