WO2020199134A1 - Procédés et systèmes de fourniture de certificats pour une communication à partir d'un véhicule - Google Patents

Procédés et systèmes de fourniture de certificats pour une communication à partir d'un véhicule Download PDF

Info

Publication number
WO2020199134A1
WO2020199134A1 PCT/CN2019/081058 CN2019081058W WO2020199134A1 WO 2020199134 A1 WO2020199134 A1 WO 2020199134A1 CN 2019081058 W CN2019081058 W CN 2019081058W WO 2020199134 A1 WO2020199134 A1 WO 2020199134A1
Authority
WO
WIPO (PCT)
Prior art keywords
component
certificates
removeable
certificate
connected vehicle
Prior art date
Application number
PCT/CN2019/081058
Other languages
English (en)
Inventor
Zhimin Du
Yan Li
Shuping Chen
Original Assignee
Qualcomm Incorporated
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Incorporated filed Critical Qualcomm Incorporated
Priority to PCT/CN2019/081058 priority Critical patent/WO2020199134A1/fr
Publication of WO2020199134A1 publication Critical patent/WO2020199134A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/68—Payment of value-added services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • 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

  • Automobiles are becoming more intelligent as the industry moves towards deploying increasingly sophisticated self-driving technologies that are capable of operating a vehicle with little or no human input.
  • These autonomous and semi-autonomous vehicles can detect information about their location and surroundings (e.g., using radar, LIDAR, GPS, file odometers, accelerometers, cameras, and other sensors) , and typically include control systems that interpret sensory information to identify hazards and determine navigation paths to follow.
  • 5G New Radio 5G New Radio
  • ITS intelligent transportation system
  • the cellular vehicle-to-everything (C-V2X) protocol serves as the foundation for vehicle-based wireless communications, and may improve the overall efficiency and safety of the highway transportation systems.
  • C-V2X defines two transmission modes that, together, provide a 360o non-line-of-sight awareness and a higher level of predictability for enhanced road safety and autonomous driving.
  • a first transmission mode includes direct C-V2X, which includes vehicle-to-vehicle (V2V) , vehicle-to-infrastructure (V2I) , and vehicle-to-pedestrian (V2P) , and that provides enhanced communication range and reliability in the dedicated ITS 5.9 gigahertz (GHz) spectrum that is independent of a cellular network.
  • V2V vehicle-to-vehicle
  • V2I vehicle-to-infrastructure
  • V2P vehicle-to-pedestrian
  • a second transmission mode includes vehicle-to-network communications (V2N) in mobile broadband systems and technologies, such as third generation wireless mobile communication technologies (3G) (e.g., global system for mobile communications (GSM) evolution (EDGE) systems, code division multiple access (CDMA) 2000 systems, etc. ) , fourth generation wireless mobile communication technologies (4G) (e.g., long term evolution (LTE) systems, LTE-Advanced systems, mobile Worldwide Interoperability for Microwave Access (mobile WiMAX) systems, etc. ) , fifth generation wireless mobile communication technologies (5G NR systems, etc. ) , etc.
  • 3G third generation wireless mobile communication technologies
  • 3G e.g., global system for mobile communications (GSM) evolution (EDGE) systems, code division multiple access (CDMA) 2000 systems, etc.
  • fourth generation wireless mobile communication technologies (4G) e.g., long term evolution (LTE) systems, LTE-Advanced systems, mobile Worldwide Interoperability for Microwave Access (mobile WiMAX) systems, etc.
  • Various aspects include methods of provisioning certificates for vehicle-based communication to a connected vehicle by using a generic bootstrapping architecture (GBA) with universal integrated circuit card (UICC) based enhancements (GBA_U) to provision certificates for the vehicle-based communications (e.g., V2X communications, etc. ) .
  • GBA generic bootstrapping architecture
  • UICC universal integrated circuit card
  • GAA_U universal integrated circuit card
  • Some aspects may include establishing a secure channel between a hardware security module (HSM) in the connected vehicle and a universal integrated circuit card (UICC) in the connected vehicle, and using the secure channel to communicate Application Protocol Data Unit (APDU) messages.
  • HSM hardware security module
  • UICC universal integrated circuit card
  • Some aspects may include provisioning the hardware security module with a key or a certificate that the universal integrated circuit card may use to determine whether the hardware security module is authorized to use GBA_U to bootstrap a shared root key with a certificate authority (CA) component, and using, by the universal integrated circuit card, the key or the certificate received from the hardware security module to determine whether the hardware security module is authorized to use GBA_U to bootstrap the shared root key with the certificate authority component.
  • CA certificate authority
  • Some aspects may include using, by the universal integrated circuit card, GBA_U to bootstrap the shared root key for future secure communications with the certificate authority component.
  • using GBA_U to bootstrap the shared root key for future secure communications with the certificate authority component may include generating a root-key authentication session key by the universal integrated circuit card, storing the root-key authentication session key in the universal integrated circuit card, establishing a secure communication link between the universal integrated circuit card and the certificate authority component, and sending, by the universal integrated circuit card, a bootstrapping transaction identifier that identifies the root-key authentication session key to the certificate authority component via the secure communication link.
  • Some aspects may further include receiving, by the certificate authority component, the bootstrapping transaction identifier via the secure communication link, querying, by the certificate authority component, a bootstrapping server function (BSF) component with the received bootstrapping transaction identifier, and receiving, by the certificate authority component, an authentication session key (Ks) from the bootstrapping server function component in response to querying the bootstrapping server function component with the received bootstrapping transaction identifier.
  • BSF bootstrapping server function
  • Ks authentication session key
  • Some aspects may include using Internet Protocol Security (IPSec) or Transport Layer Security (TLS) with the authentication session key (Ks) as a root key to establish a second secure communication link between the universal integrated circuit card and the certificate authority component, and sending, by the certificate authority component, the certificates for vehicle-based communication to the universal integrated circuit card via the second secure communication link.
  • IPSec Internet Protocol Security
  • TLS Transport Layer Security
  • Some aspects may include requesting, by the universal integrated circuit card, the certificates for vehicle-based communication from the certificate authority component, receiving, by the universal integrated circuit card, the requested certificates from the certificate authority component, and sending, by the universal integrated circuit card, the received requested certificates to the hardware security module.
  • Some aspects may include receiving, by the hardware security module, the certificates for vehicle-based communication from the universal integrated circuit card, and using, by the hardware security module, the received certificates for vehicle-based communication.
  • Various aspects also include methods of provisioning certificates for vehicle-based communication to a connected vehicle by using a removeable secure storage component as a media carrier to request and receive new certificates for vehicle-based communications. Some aspects may include signing a certificate request message stored on the removeable secure storage component by an enrollment certificate or other equivalent certificate of the connected vehicle with corresponding public keys anti-replay protection and authenticating the signed certificate request message via a certificate authority component.
  • Some aspects may include generating private keys and public keys in pairs for requested certificates by a hardware security module or a trusted execution environment in the connected vehicle. Some aspects may include including the public keys in the certificate request message. Some aspects may include securely generating, by the removeable secure storage component, random keys, and private key and public key pairs for requested certificates. Some aspects may include generating, by a certificate authority component, private key and public key pairs for requested certificates.
  • using the removeable secure storage component as the media carrier to request and receive the new certificates for vehicle-based communications may include sending certificates from a root certificate authority component to an enrollment certificate authority component and/or a pseudonym certificate authority component or otherwise establishing mutual trust relationship between the root certificate authority component, enrollment certificate authority component and/or the pseudonym certificate authority component, submitting, from a vehicle manufacturer server, a new connected vehicle model for a certification to ensure vehicle-to-everything (V2X) functionally compliance, notifying, by a certification entity component, the enrollment certificate authority component of compliance of the new connected vehicle model, requesting and receiving enrollment certificates for vehicles associated with the new connected vehicle model in the vehicle manufacturer server, provisioning, by the vehicle manufacturer server, an enrollment certificate into one or more connected vehicles associated with the new connected vehicle model, registering for vehicle-based communication services by the connected vehicle, requesting, by the connected vehicle, pseudonym certificates through a registration authority component, using the enrollment certificate as credential, receiving, by the registration authority component, massive pseudonym certificates for the connected vehicle from
  • registering for vehicle-based communication services by the connected vehicle and requesting the pseudonym certificates through the registration authority component may include generating, by a hardware security module or a trusted execution environment in the connected vehicle, a batch of private keys and their corresponding public keys, wherein the batch of private keys and their corresponding public keys are paired and identified with a key ID, storing, by the hardware security module or the trusted execution environment, the batch of public keys in the removeable secure storage component with a predefined format, and providing the removeable secure storage component to the registration authority component during service registration.
  • receiving massive pseudonym certificates for the connected vehicle from the pseudonym certificate authority component may include checking, by the registration authority component, the connected vehicle and the registration, passing the removeable secure storage component from the registration authority component to the pseudonym certificate authority component, verifying, by the pseudonym certificate authority component, a certificate request message and signature stored on the removeable secure storage component, retrieving, by the pseudonym certificate authority component, the batch of public keys from the removeable secure storage component, generating, by the pseudonym certificate authority component, pseudonym certificates with the batch of public keys, storing, by the pseudonym certificate authority component, the pseudonym certificates to the removeable secure storage component, and sending, by the pseudonym certificate authority component, the removeable secure storage component to the registration authority component.
  • sending the massive pseudonym certificates to the connected vehicle may include sending, by the registration authority component, the removeable secure storage component to the connected vehicle or applicant, and inserting the removeable secure storage component into an V2X on-board unit.
  • registering for vehicle-based communication services by the connected vehicle and requesting the pseudonym certificates through the registration authority component may include generating, by the removeable secure storage component, a batch of private keys and their corresponding public keys, wherein the batch of private keys and their corresponding public keys are paired and identified with a key ID, using, by a hardware security module or a trusted execution environment in the connected vehicle, the enrollment certificate to sign pseudonym certificate request message (s) with the batch of public keys as inputs, the hardware security module or the trusted execution environment storing the batch of public keys in the removeable secure storage component with a predefined format, and providing the removeable secure storage component to the registration authority component during service registration.
  • receiving massive pseudonym certificates for the connected vehicle from the pseudonym certificate authority component may include checking, by the registration authority component, the connected vehicle and the registration, passing the removeable secure storage component from the registration authority component to the pseudonym certificate authority component, verifying, by the pseudonym certificate authority component, a certificate request message and signature stored on the removeable secure storage component, retrieving, by the pseudonym certificate authority component, the batch of public keys from the removeable secure storage component, generating, by the pseudonym certificate authority component, pseudonym certificates with the batch of public keys, storing, by the pseudonym certificate authority component, the pseudonym certificates to the removeable secure storage component, and sending, by the pseudonym certificate authority component, the removeable secure storage component to the registration authority component.
  • registering for vehicle-based communication services by the connected vehicle and requesting the pseudonym certificates through the registration authority component may include using, by a hardware security module or a trusted execution environment in the connected vehicle, the enrollment certificate to sign pseudonym certificate request message (s) with public keys as inputs, storing, by the hardware security module or the trusted execution environment, the signed pseudonym certificate request message (s) in the removeable secure storage component, and providing the removeable secure storage component to the registration authority component during service registration.
  • receiving massive pseudonym certificates for the connected vehicle from the pseudonym certificate authority component may include checking, by the registration authority component, the connected vehicle and the registration, passing the removeable secure storage component from the registration authority component to the pseudonym certificate authority component, verifying, by the pseudonym certificate authority component, a certificate request message and signature stored on the removeable secure storage component, generating, by the pseudonym certificate authority component, a batch of private keys and their corresponding public keys for the connected vehicle, generating, by the pseudonym certificate authority component, pseudonym certificates with the public keys, storing, by the pseudonym certificate authority component, the pseudonym certificates to the removeable secure storage component, and encrypting, by the pseudonym certificate authority component, the batch of private keys and storing them in a secure message format in the removeable secure storage component.
  • sending the massive pseudonym certificates to the connected vehicle may include sending, by the registration authority component, the removeable secure storage component to the connected vehicle or applicant, inserting the removeable secure storage component into an V2X on-board unit, reading, by the hardware security module or the trusted execution environment, the pseudonym certificates from the removeable secure storage component, reading, by the hardware security module or the trusted execution environment, the secure message from the removeable secure storage component, and decrypting, by the hardware security module or the trusted execution environment, the batch of private keys from the secure message.
  • Various aspects may also include methods of provisioning of certificates for vehicle-based communication to a connected vehicle that include using a generic bootstrapping architecture (GBA) with UICC-based enhancements (GBA_U) to provision an initial certificate, and using a removeable secure storage (RSS) as a media carrier to request and receive new certificates or a large number of certificates for vehicle-to-everything (V2X) communications.
  • GBA generic bootstrapping architecture
  • GAA_U UICC-based enhancements
  • RSS removeable secure storage
  • FIG. 1 Further aspects may include a system that includes a certificate authority component and a connected vehicle.
  • the connected vehicle may include a hardware security module (HSM) , a universal integrated circuit card (UICC) , and a processor communicatively coupled to the hardware security module and the universal integrated circuit card.
  • the processor may be configured with processor-executable instructions to provision the hardware security module with a key or a certificate that the universal integrated circuit card may use to determine whether the hardware security module is authorized to use GBA_U to bootstrap a shared root key with the certificate authority component, and establish a secure channel between the hardware security module and the universal integrated circuit card that is suitable for communicating APDU messages.
  • the universal integrated circuit card may be configured to receive the key or the certificate received from the hardware security module via a secure communication link, use the key or the certificate received from the hardware security module to determine whether the hardware security module is authorized to use GBA_U to bootstrap the shared root key with the certificate authority component, generate a root-key authentication session key in response to determining that the hardware security module is authorized to use GBA_U to bootstrap the shared root key with the certificate authority component, store the root-key authentication session key, establish a secure communication link to the certificate authority component, send a bootstrapping transaction identifier that identifies the root-key authentication session key to the certificate authority component via the secure communication link, request certificates for vehicle-based communication from the certificate authority component, receive the requested certificates from the certificate authority component, and send the received requested certificates to the hardware security module via the secure channel.
  • the certificate authority component may be configured to receive the bootstrapping transaction identifier via the secure communication link, query a BSF component with the received bootstrapping transaction identifier, receive an authentication session key (Ks) from the bootstrapping server function component in response to querying the bootstrapping server function component with the received bootstrapping transaction identifier, use IPSec or TLS with the authentication session key (Ks) as a root key to establish a second secure communication link with the universal integrated circuit card, and send the certificates for vehicle-based communication to the universal integrated circuit card via the second secure communication link.
  • the hardware security module may be configured to receive the certificates for vehicle-based communication from the universal integrated circuit card via the secure channel between the hardware security module and the universal integrated circuit card, and use the received certificates for vehicle-based communications.
  • Further aspects may include a system that includes a root certificate authority component, an enrollment certificate authority component, a pseudonym certificate authority component, certification entity component, a registration authority component, a vehicle manufacturer server, and a connected vehicle.
  • the root certificate authority component may be configured to send certificates to an enrollment certificate authority component and/or a pseudonym certificate authority component (or these components may otherwise establish a trust relationship) .
  • the vehicle manufacturer server may include a server processor configured to submit a new connected vehicle model to the pseudonym certification authority component for a certification to ensure vehicle-to-everything, V2X, functionally compliance, request and receive enrollment certificates for vehicles associated with the new connected vehicle model, and provision an enrollment certificate into one or more connected vehicles associated with the new connected vehicle model.
  • the certification entity component may be configured to notify the enrollment certificate authority component of compliance of the new connected vehicle model.
  • the connected vehicle may include on-board unit that includes a removeable secure storage (RSS) and a processor coupled to the removeable secure storage.
  • the processor may be configured with processor-executable instructions to perform operations that include registering for vehicle-based communication services, and requesting pseudonym certificates through the registration authority component, using the enrollment certificate as credential.
  • the registration authority component may be configured to receive massive pseudonym certificates for the connected vehicle from the pseudonym certificate authority component (in which the pseudonym certificates are signed by the pseudonym certificate authority component for the connected vehicle, and sufficient pseudonym certificates are received for use in a registration period) , and send the massive pseudonym certificates to the connected vehicle.
  • connected vehicles may include connected vehicles, on board units (OBUs) or computing devices having one or more processors configured with processor-executable instructions to perform various operations corresponding to any of the methods summarized above.
  • the connected vehicles or computing devices may be configured or equipped with a root certificate authority component, an enrollment certificate authority component, a pseudonym certificate authority component, certification entity component, a registration authority component configured to perform all or portions of the operations corresponding to any of the methods discussed above.
  • Further aspects may include a computing device having various means for performing functions of any of the methods summarized above. Further aspects may include a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor in a server computing device to perform various operations corresponding to any of the methods summarized above.
  • FIG. 1 is a schematic block diagram illustrating a subset of a V2V communication system suitable for implementing various embodiments.
  • FIG. 2A is a system diagram illustrating various components, operations, and communications in a system configured to implement a method of issuing certificates to connected vehicles in accordance with some embodiments.
  • FIG. 2B is an activity diagram illustrating various components, operations, and communications in a system configured to implement a method of issuing certificates to connected vehicles in accordance with some embodiments.
  • FIG. 2C is a process flow diagram illustrating a method of issuing certificates to connected vehicles in accordance with some embodiments.
  • FIGs. 3-5 are process flow diagrams illustrating methods of using a removable secure storage to provision certificates for vehicle-based communications in accordance with some embodiments.
  • FIG. 6A is a system diagram of various components, operations, and communications in a system configured to use generic bootstrapping architecture (GBA) with UICC-based enhancements (GBA_U) to implement a method of issuing certificate to connected vehicles in accordance with some embodiments.
  • GBA generic bootstrapping architecture
  • GAA_U UICC-based enhancements
  • FIG. 6B is a process flow diagram illustrating a method of using a generic bootstrapping architecture (GBA) with UICC-based enhancements (GBA_U) to issue a certificate to a connected vehicle in accordance with some embodiments.
  • GBA generic bootstrapping architecture
  • GAA_U UICC-based enhancements
  • FIGs. 7 and 8 are activity diagrams illustrating example interactions and operations that may be performed when implementing a method of issuing certificates to connected vehicles in accordance with some embodiments.
  • FIGS. 9A and 9B are component block diagrams illustrating a vehicle suitable for implementing various embodiments.
  • FIG. 9C is a component block diagram illustrating components of a vehicle suitable for implementing various embodiments.
  • FIG. 10 is a schematic diagram of an example server suitable for implementing various embodiments.
  • various embodiments include methods, and connected vehicles and on-board units (OBUs) configured to implement the methods, that overcome various challenges associated with securely and efficiently provisioning and using certificates that comply with various standards set forth by the relevant standards developing organizations (SDOs) for intelligent transportation system (ITS) vehicle-to-everything (V2X) communications.
  • SDOs standards developing organizations
  • ITS intelligent transportation system
  • V2X vehicle-to-everything
  • an OBU or connected vehicle may be configured to use a generic bootstrapping architecture (GBA) with UICC-based enhancements (GBA_U) to provision certificates over the air (OTA) .
  • GBA generic bootstrapping architecture
  • UICC-based enhancements GAA_U
  • GBA_U is a standard defined mechanism published in the 3 rd Generation Partnership Project (3GPP) Technical Specification (TS) 33.220 (Release 15) for initially establishing (i.e., “bootstrapping” ) authentication and key agreement with wireless communication devices for application security that does require changes to the UICC, but provides enhanced security by storing certain derived keys on the UICC.
  • 3GPP 3rd Generation Partnership Project
  • TS Technical Specification
  • References herein to using GBA_U to perform various operations are intended to mean using the GBA_U process defined in the 3GPP TS 33.220, or equivalents thereof.
  • a removeable secure storage (RSS) may be configured to operate as a media carrier that is suitable for requesting and receiving new certificates.
  • an OBU or connected vehicle may be configured to use GBA_U and a removeable secure storage (RSS) collaboratively, for example using GBA_U to provision one initial or fundamental certificate and then using RSS to request and receive a large number of new certificates.
  • GBA_U removeable secure storage
  • RSS removeable secure storage
  • V2X Vehicle-to-everything
  • BSM basic safety messages
  • CAM Cooperative Awareness Message
  • V2X vehicle-to-everything
  • PKI public key infrastructure
  • CA certificate authorities
  • SAE society of automotive engineers
  • SCMS security credentials management system
  • CAs certificate authorities
  • SAE SCMS standards e.g., SAE 2945/1
  • SAE 2945/1 define various on-board system requirements for V2V safety communications. Implementation of these requirements require that each connected vehicle (CV) be securely provisioned with lots (several thousands) of short-lived pseudonym certificates. Three-year’s worth of certifications may be downloaded, and a daily key could be required to “unlock” the certificates for the day. There may only be few ( ⁇ 20) active certificates available to a connected vehicle (CV) at a time.
  • Each of the certificates may be valid for a week or two, but are shuffled to achieve untrackability “within a journey. ”
  • each connected vehicle (CV) should switch certificates every five (5) minutes, for example.
  • the SAE SCMS standards also introduce in two independent linkage authorities (LA) and pseudonym certificate authorities (PCA) to ensure that no entity (including CA/PCA itself) maps a pseudonym certificate to a connected vehicle (CV) .
  • LA linkage authorities
  • PCA pseudonym certificate authorities
  • LAs linkage authorities
  • RA registration authority
  • LOP location obscurer proxy
  • conventional vehicle designs include an intelligent transportation system (ITS) vehicle-to-everything (V2X) on-board unit (OBU) that includes a V2X modem, a cellular wide area connection modem (a “Uu modem” ) , an application processor (AP) with a trusted execution environment (TEE) that runs an ITS protocol stack, and a hardware security module (HSM) . While the HSM and TEE are secure, the other components in the V2X OBU are not secure. In addition, the HSM is static, fixed or immovable because it is integrated into the V2X OBU and provisioned by the vehicle manufacturer. Using the Uu modem interface to update the HSM with certificates could dilute or compromise their security.
  • ITS intelligent transportation system
  • V2X vehicle-to-everything
  • OBU cellular wide area connection modem
  • AP application processor
  • TEE trusted execution environment
  • HSM hardware security module
  • the V2X OBU or the connected vehicle may be configured to use a generic bootstrapping architecture (GBA) with UICC-based enhancements (GBA_U) to provision certificates over the air (OTA) .
  • GBA generic bootstrapping architecture
  • GBA_U UICC-based enhancements
  • OTA OTA
  • a removeable secure storage may be included in the V2X OBU and configured to operate as a media carrier that is suitable for requesting and receiving new certificates for V2X communications.
  • GBA_U and a removeable secure storage (RSS) may be used collaboratively, for example using GBA_U to provision one initial or fundamental certificate and then using RSS to request and receive a large number of new certificates.
  • FIG. 1 illustrates a portion of the V2V system 100 including three vehicles, 12, 14, 16.
  • Each vehicle 12, 14, 16 includes V2V onboard equipment 102, 104, 106, respectively, that are configured to periodically broadcast BSMs 112, 114, 116 for receipt and processing by other vehicles’ onboard equipment.
  • BSMs 112, 114, 116 for receipt and processing by other vehicles’ onboard equipment.
  • vehicles can maintain safe separation and identify and avoid potential collisions.
  • a trailing vehicle 12 receiving BSMs 114 from a leading vehicle 16 can determine the speed and location of the vehicle 16, enabling vehicle 12 to match the speed and maintain a safe separation distance 20.
  • the V2V equipment 102 in the trailing vehicle 12 can apply brakes simultaneously to maintain the safe separation distance 20 even when the leading vehicle 16 stopped suddenly.
  • the V2V equipment 104 within the truck vehicle 14 may receive BSMs 112, 116 from the two vehicles 12, 16, and thus be informed that the truck vehicle 14 should stop at the intersection to avoid a collision.
  • V2V onboard equipment in nearby vehicles and highway monitoring systems of a basic safety podcast can confirm the authenticity of the V2V onboard equipment issuing the BSM by verifying the signature on the broadcast messages.
  • V2V onboard equipment receiving a BSM can verify the signature using a public key.
  • V2V onboard equipment may be configured to ignore any received BSM that has no signature or that has been signed using an expired or invalid certificate.
  • Various equipment malfunctions may cause a V2V onboard equipment to produce incorrect BSMs.
  • faults in navigation sensors, speed sensors, and/or cabling from such sensors to the V2V onboard equipment may result in inaccurate reporting of vehicle position (e.g., in an incorrect lane or larger error) or speed.
  • a V2V onboard equipment may be maliciously altered to produce incorrect BSMs that are signed using a legitimate certificate. Both cases are referred to as misbehavior.
  • a receiving V2V onboard equipment may detect the misbehavior via misbehavior detection in onboard processing.
  • Incorrect BSMs may be recognized by V2V onboard equipment in other vehicles when information contained in such a message conflicts with trustworthy information available to the V2V onboard equipment.
  • V2V onboard equipment may recognize that the position information in a received BSM is incorrect when the reported location of the reporting vehicle overlaps with the position of the vehicle receiving the BSM.
  • V2V onboard equipment may recognize that the velocity information in received BSM is incorrect when the velocity is inconsistent with the velocity of the equipment’s own vehicle and surrounding vehicles. Other methods of recognizing incorrect BSMs may be used.
  • V2V onboard equipment may be configured to inform other vehicles and highway systems or authorities of detected incorrect BSMs by transmitting messages that notify other systems of the detected issues.
  • the receiving V2V onboard equipment may produce a misbehavior report or misbehavior detection report (MDR) .
  • MDR misbehavior detection report
  • Each misbehavior detection report may include the pseudonym certificate of the misbehaving V2V onboard equipment that signed the incorrect BSM.
  • the V2V onboard equipment that detected the misbehavior may be configured to send the misbehavior detection report to a specific network backend entity for processing, which is referred to herein as the misbehavior report catcher (MRC) .
  • the reporting V2V onboard equipment is typically configured by the original equipment manufacturer (OEM) , so the misbehavior report catcher is typically operated by, or on behalf of, the OEM of the reporting V2V onboard equipment.
  • BSM/MDRs may be collected by a misbehavior authority, which may be an entity run by any of a variety of parties, such as a government agency, an independent third-party agency or service provider, and/or an OEM.
  • a misbehavior authority may be configured to take actions to protect the reliability and integrity of the V2V systems and equipment. For example, a misbehavior authority may blacklist the certificates of misbehaving V2V onboard equipment so that other V2V onboard equipment can know to ignore BSMs containing blacklisted certificates. Decentralized misbehavior authorities may also inform certificate registration authorities of certificates so that appropriate actions can be taken by the corresponding registration authority.
  • misbehaving V2V onboard equipment is used herein for the V2V onboard equipment to which misbehavior is attributed to in an BSM/MDR.
  • another component or entity, and not the attributed V2V onboard equipment could be misbehaving using messages or credentials obtained from the V2V onboard equipment.
  • a faulty sensor or equipment in the same vehicle as the attributed V2V onboard equipment may be the cause of erroneous information in a BSM resulting in a misbehavior detection, although there are other scenarios in which an entity outside the vehicle may be responsible for transmission of incorrect BSMs.
  • An entity such as an original equipment manufacturer (OEM) may use of BSM/MDRs for a variety of reasons.
  • OEM original equipment manufacturer
  • an OEM of an V2V onboard equipment may be interested in seeing information regarding the BSM/MDR for misbehavior attributed to that V2V onboard equipment.
  • the OEM may want the information purely for recording statistics.
  • the OEM may take appropriate steps including, but not limited to, any of the following: attempting to fix errors in the V2V onboard equipment implementation; replacing the V2V onboard equipment; disabling the V2V onboard equipment; notifying the owner that the vehicle should be brought in for maintenance; deleting certificates from the V2V onboard equipment; placing some of the V2V onboard equipment certificates on a revocation list; issuing new certificates to the V2V onboard equipment.
  • the OEM may perform such steps over the air in some cases, while physical access to the V2V onboard equipment is required in other cases.
  • IEEE 1609.2 is the standard that defines the security mechanisms for IEEE 1609 V2V systems, components and onboard equipment.
  • the sending V2V onboard equipment attaches a signature (e.g., public key signature, private key signature, other digital signature, etc. ) to each BSM, which can be verified by the public signing key in a pseudonym certificate which has been issued to the sending V2V onboard equipment.
  • the public key signature applied by V2V onboard equipment using the provisioned pseudonym certificate attests that that V2V onboard equipment is trusted to provide correct BSMs.
  • the receiving V2V onboard equipment validates the pseudonym certificate, and then verifies the public key signature attached to the BSM using the public signing key in the certificate; other validity tests may be employed as well (e.g., feasibility assessment, comparison with own sensors, etc. ) . If these tests are all successful, then the BSM is considered to be trustworthy.
  • V2V onboard equipment uses a single certificate
  • the V2V onboard equipment (and its vehicle) might be tracked by recording the locations where this single certificate is used.
  • the V2V onboard equipment uses multiple certificates that can be easily linked to each other, then the V2V onboard equipment (and its vehicle) might be tracked by recording the locations where the set of certificates are used.
  • a pseudonym certificate authority issues each V2V onboard equipment with multiple pseudonym certificates which cannot be linked to each other without help from the pseudonym certificate authority and other entities that were involved in issuing the pseudonym certificate.
  • the Secure Credential Management System (SCMS) is an example of a system for generating and provisioning pseudonym certificates with these properties.
  • an OEM such as the vehicle manufacturer or the manufacturer of the V2V onboard equipment purchased by the vehicle OEM, is part of the system involved in issuing the pseudonym certificate, and thus may control or contact one or more of the pseudonym certificate authority, Intermediate Certificate Authority (ICA) , and registration authority, or other components of the certificate provisioning backend.
  • ICA Intermediate Certificate Authority
  • the system for issuing the pseudonym certificates to the V2V onboard equipment is modelled as having four logical components: pseudonym certificate authority (PCA) , registration authority (RA) , certificate provisioning backend (CPB) and V2V onboard equipment.
  • the term “certificate provisioning backend” is used to refer to various additional systems and components that may be implemented by an OEM or other entity for performing or enabling the provisioning (or requesting provisioning via third-parties) of certificates to V2V onboard equipment beyond those of the pseudonym certificate authority and registration authority.
  • the V2V onboard equipment and pseudonym certificate authority (PCA) have already been mentioned.
  • the registration authority (RA) manages the V2V onboard equipment’s interactions with the pseudonym certificate authority.
  • the certificate provisioning backend manages provisioning of the certificate into the V2V onboard equipment.
  • FIGs. 2A-2C illustrate various components, operations, and communications in a system configured to implement a method 200 of issuing certificates to connected vehicles.
  • the system may include a root certificate authority (RCA) 252 component, an enrollment certificate authority (ECA) 254 component, a pseudonym certificate authority (PCA) 256 component, a certification entity (CE) 258 component, a registration authority (RA) 260 component, a vehicle manufacturer (VM) 262 component, and a connected vehicle (CV) 264.
  • RCA root certificate authority
  • ECA enrollment certificate authority
  • PCA pseudonym certificate authority
  • CE certification entity
  • RA registration authority
  • VM vehicle manufacturer
  • CV connected vehicle
  • the CV 264 may include a V2X on-board unit (OBU) 270 that includes a V2X modem 272, an application processor (AP) 274 that runs an intelligent transportation system (ITS) protocol stack, a hardware security module (HSM) 276 component, and a removable secure storage 278 component.
  • the AP 274 may also include a trusted execution environment (TEE) 280, which is a secure area within the processor that provides various security features such as isolated execution, integrity of applications executing with the TEE, and confidentiality of assets.
  • the RSS 278 component may include an internal processor and/or may be configured to securely generate random keys, and the private key and public key pairs for requested certificates.
  • the RCA 252 component may send certificates to the ECA 254 and/or PCA 256 components.
  • the VM 262 component may submit a new connected vehicle model for certification to ensure the compliance of its V2X functionalities.
  • the CE 258 component may notify the ECA 254 of compliance of the new connected vehicle model.
  • the VM 262 component may request and receive enrollment certificates for the individual vehicles under that connected vehicle model.
  • the VM 262 component may provision one enrollment certificate into each connected vehicle that matches the connected vehicle model, including the CV 264 illustrated in FIGs. 2A and 2B.
  • the CV 264 may register for vehicle-based communication services, and request pseudonym certificates through the RA 260 component using the enrollment certificate as a credential.
  • the RA 260 component may receive massive pseudonym certificates for the CV 264 from PCA 256.
  • the pseudonym certificates may be signed by PCA 256 for the CV 264, and sufficient pseudonym certificates may be provided for use in the registration period.
  • the RA 260 component may send the massive pseudonym certificates to the CV 264.
  • FIGs. 3-5 illustrate alternative methods 300, 400, 500 of using a removable secure storage (RSS 278 illustrated in FIG. 2A) to provision certificates for vehicle-based communications in accordance with some embodiments.
  • the operations in methods 300, 400, and 500 may be performed as part of, or in lieu of, the operations in blocks 212, 214 and 216 of the method 200 illustrated in FIG. 2C.
  • the TEE 280 or HSM 276 may securely generate a batch of private keys and the corresponding public keys.
  • the generated keys may be paired and identified with Key ID.
  • the private keys will not leave the TEE 280 or HSM 276 (or a secured memory dedicated for the TEE 280 or HSM 276 access) .
  • the TEE 280 or HSM 276 may store the public keys into the RSS 278 with a predefined format. For example, they may be stored as one or more pseudonym certificate request messages with the public keys as inputs. The TEE 280 or HSM 276 may use the vehicle’s enrollment certificate to sign the message.
  • the applicant e.g., the end user or another party acting on behalf of the end user
  • CV 264 may provide the RSS 278 to the RA 260.
  • the applicant or CV 264 may provide the RSS 278 to the RA 260 during service registration.
  • the RA 260 may make necessary checks on the applicant/CV and the registration.
  • the RA 260 may pass the RSS 278 to the PCA 256.
  • the PCA 256 verifies the request message and the signature in the RSS 278. Once verified, the PCA 256 may abstract/retrieve the public keys from the RSS 278, generate pseudonym certificates with the public keys, and store the pseudonym certificates to the RSS 278. As part of the operations in block 312, the PCA 256 may optionally implement additional security mechanism when storing pseudonym certificates, such as by using the pubic key of the vehicle’s enrollment certificate to encrypt the pseudonym certificates.
  • the PCA 256 may return the RSS 278 to the RA 260.
  • the RA 260 may provide the RSS 278 to the applicant.
  • the applicant may insert the RSS 260 into the V2X OBU 270 of the CV 264.
  • the TEE 280 or HSM 276 may read out the pseudonym certificates from the RSS 278.
  • the TEE 280 or HSM 276 may also conditionally decrypt the pseudonym certificates with the private key of its enrollment certificate in block 322.
  • the RSS 278 may securely generate the batch of private keys and the corresponding public keys.
  • the private keys and the corresponding public keys may be paired and identified with Key ID.
  • the private keys may not leave the secured and hidden memory of the RSS 278, and may be used only by the RSS 278.
  • the signing operation of V2X message with the selected pseudonym certificate in V2X communications may be performed by the RSS 278 because the private key of the selected pseudonym certificate is only known to and accessible by the RSS 278.
  • the TEE 280 or HSM 276 may use the enrollment certificate to sign one or more pseudonym certificate request message (s) with the public keys as inputs.
  • the components may perform the operations of the like numbered blocks of the method 300 as described with reference to FIG. 3.
  • the TEE 280 or HSM 276 use enrollment certificate to sign a pseudonym certificate request message and stores it in the RSS 278.
  • the components may perform the operations of the like numbered blocks of the method 300 as described with reference to FIG. 3.
  • the PCA 256 may securely generate a batch of private keys and the corresponding public keys for the CV 264, generate pseudonym certificates with the public keys, and stores the pseudonym certificates in the RSS 278.
  • the PCA 256 may encrypt the private keys, and store them in a secure message format in the RSS 278.
  • the components may perform the operations of the like numbered blocks of the method 300 as described with reference to FIG. 3.
  • the TEE 280 or HSM 276 may read out the secure message from the RSS 278, and decrypt the private keys from the secure message.
  • the RSS 278 may decrypt the private keys from the secure message and store them accordingly.
  • the signing operation of V2X Message with the selected pseudonym certificate should be performed by the RSS 278.
  • the RSS 278 component is used as the media carrier to request and receive new certificates for V2X communications. As such, these methods are particularly useful when massive pseudonym certificates need to be provisioned.
  • a certificate request message stored on the RSS 278 component may be signed by the enrollment certificate or other equivalent certificate of the connected vehicle (e.g., CV 264) with anti-replay protection.
  • the certificate authority e.g., PCA 256
  • the HSM 276 or TEE 280 of the CV 264 may generate the private key and public key pairs for the requested certificates.
  • the public keys may be included in the certificate request message.
  • the RSS 278 component may include an internal processor and/or may be configured to securely generate random keys, and the private key and public key pairs for the requested certificates.
  • the private key and public key pairs for the requested certificates may be generated by the certificate authority (e.g., PCA 256) .
  • a certificate authority e.g., PCA 256
  • PCA 256 may read/retrieve the certificate request message stored on the RSS 278 component and authenticate the eligibility of the request.
  • the certificate authority may store the requested V2X certificates onto the RSS 278.
  • the V2X certificates may be encrypted by the public key of the enrollment certificate or other equivalent certificate, and the RSS 278 may be inserted back to the CV 264.
  • the HSM 276 or TEE 280 of the CV 264 may decrypt the V2X certificates and verify their authenticity. Once verified, the CV 264 may use these V2X certificates together with the corresponding private key.
  • FIGs. 6A and 6B illustrate various components, operations, and communications in a system configured to implement another method 600 of issuing certificates to connected vehicles.
  • FIG. 7 illustrates example interactions and operations that may be performed as part of the operations in blocks 604 through 608 of method 600.
  • FIG. 8 illustrates example interactions and operations that may be performed as part of the operations in blocks 610 through 614 of method 600.
  • the system may include a connected vehicle (CV) 264 communicatively coupled to a bootstrapping server function (BSF) 656 via a cellular network 654.
  • the BSF 656 may be communicatively coupled to a home subscriber server (HSS) 658 component and to a certificate authority (CA) 660 component.
  • the CV 264 may include a V2X on-board unit (OBU) 270 that includes a universal integrated circuit card (UICC) , which is a smart card that conforms to the specification written and maintained by the European Telecommunications Standards Institute (ETSI) Smart Card Platform project) .
  • the CV 264 may also include an embedded subscriber identity module (eSIM) 652 component.
  • the CA 660 component may be a PCA 256 or ECA 254 component.
  • the CV 264 does not have valid credential for V2X communications.
  • the HSM 276 in the V2X OBU 270 of the CV 264 is pre-provisioned with a key or a certificate, which may be authenticated by the UICC/eSIM 652.
  • the CV 264 commences over-the-air (OTA) provisioning of V2X credentials.
  • the V2X Application requests that the HSM 276 set up a secure channel with UICC/eSIM 652.
  • the HSM 276 exchanges secured application protocol data units (APDUs) with UICC/eSIM 652, and the pre-provisioned key or certificate is used to authenticate each other and to derive session key to encrypt the APDUs.
  • APDUs application protocol data units
  • the CV 264 may retrieve International mobile subscriber identity (IMSI) information from the UICC/eSIM 652 component, include the IMSI information in a GBA Request message, and send the GBA Request to the BSF 656 associated with its home operator.
  • IMSI International mobile subscriber identity
  • the BSF 656 may retrieve an authentication vector from HSS 658 for the UICC/eSIM 652 in the CV 264.
  • the BSF 656 and the UICC/eSIM 652 may use GBA_U procedures to mutually authenticate each other and to bootstrap a shared key Authentication Session Key (Ks) .
  • Ks may be identified with a bootstrapping transaction identifier (B-TID) .
  • the CV 264 may send a provisioning request that includes the B-TID to the CA 660 component.
  • the CA 660 component may use B-TID to locate BSF 656, establish a secure connection with BSF 656 using Internet Protocol Security (IPSec) or Transport Layer Security (TLS) , and send an authentication request message that includes the B-TID and other parameters to the BSF 656.
  • IPSec Internet Protocol Security
  • TLS Transport Layer Security
  • the BSF 656 may return an authentication answer message, which includes Ks and Key Lifetime parameters.
  • the CA 660 component may use the Ks to set up secure connection with the CV 264, sign the V2X Certificate for the CV 264, and send it securely to the CV 264.
  • the HSM 276 may securely generate one or a batch of Private Keys and the corresponding Public Keys.
  • the Private Keys and the corresponding Public Keys are paired and identified with Key ID.
  • the Private Keys will not leave the secured and hidden memory of HSM 276, and the Private Keys can be used only by the HSM 276.
  • the HSM 276 may send the Public Keys to UICC/eSIM 652 via Secured APDUs.
  • the UICC/eSIM 652 component After the secure connection is set up between CA 660 component and UICC/eSIM 652 component, the UICC/eSIM 652 component passes the Public Keys to CA 660 component and requests that the CA 660 component sign them and generate the certificates for the CV 264.
  • the CA 660 component returns the certificates to UICC/eSIM 652 through the secure connection, the UICC/eSIM 652 forwards the certificates to the HSM 276, and the HSM 276 stores the certificates in an internal or external memory.
  • method 600 uses GBA_U to issue certificates.
  • UICC/eSIM 652 components may set up a secure channel between them and use Secured APDU to exchange messages.
  • the HSM 276 may be pre-provisioned with a key or a certificate, with which the UICC/eSIM 652 may authenticate to determine whether HSM 276 has the right to involve GBA_U to bootstrap a shared root key with CA 660 component for V2X Certificate provisioning.
  • the UICC/eSIM 652 starts a GBA_U process to bootstrap a shared root key for the future secure communications with CA 660 component.
  • the UICC/eSIM 652, BSF 656 and HSS 658 collaboratively perform the GBA_U process, a new root key Ks is generated by UICC/eSIM 652 and kept within UICC/eSIM 652.
  • the UICC/eSIM 652 sets up a secure connection with CA.
  • the UICC/eSIM sends the B-TID, which identifies the key Ks that UICC/eSIM 652 proposes to use and protect the communications.
  • CA uses the B-TID to retrieve the Ks from BSF.
  • the UICC/eSIM 652 and CA use IPSec or TLS with Ks as the root key to protect the communications.
  • UICC/eSIM 652 requests for V2X Certificates and CA returns the Certificates.
  • the UICC/eSIM 652 send the V2X Certificates to HSM 276, and the HSM 276 uses V2X Certificate for V2X communications.
  • the HSM 276 component may be integrated into and its function may be provided by UICC/eSIM 652.
  • a connected vehicle 900 may include a plurality of sensors 902-938 disposed in or on the connected vehicle that are used for various purposes involved in autonomous and semiautonomous navigation as well as sensor data regarding objects and people in or on the connected vehicle 900.
  • the sensors 902-938 may include one or more of a wide variety of sensors capable of detecting a variety of information useful for navigation and collision avoidance.
  • Each of the sensors 902-938 may be in wired or wireless communication with a control unit 940, as well as with each other.
  • the sensors may include one or more cameras 922, 936 or other optical sensors or photo optic sensors.
  • the sensors may further include other types of object detection and ranging sensors, such as radar 932, lidar 938, IR sensors, and ultrasonic sensors.
  • the sensors may further include tire pressure sensors 914, 920, humidity sensors, temperature sensors, satellite geopositioning sensors 908, accelerometers, vibration sensors, gyroscopes, gravimeters, impact sensors 930, force meters, stress meters, strain sensors, fluid sensors, chemical sensors, gas content analyzers, pH sensors, radiation sensors, Geiger counters, neutron detectors, biological material sensors, microphones 924, 934, occupancy sensors 912, 916, 918, 926, 928, proximity sensors, and other sensors.
  • the connected vehicle control unit 940 may be configured with processor-executable instructions to perform various embodiments using information received from various sensors, such as the cameras 922, 936. In some embodiments, the control unit 940 may supplement the processing of camera images using distance and relative position (e.g., relative bearing angle) that may be obtained from radar 932 and/or lidar 938 sensors. The control unit 940 may further be configured to control steering, breaking and speed of the connected vehicle 900 when operating in an autonomous or semiautonomous mode using information regarding other vehicles determined using various embodiments. In some embodiments, the control unit 940 may be configured to implement all or portions of the vehicle autonomous driving system (VADS) discussed throughout this application.
  • VADS vehicle autonomous driving system
  • FIG. 9C is a component block diagram illustrating a system 950 of components and support systems suitable for implementing various embodiments.
  • a connected vehicle 900 may include a control unit 940, which may include various circuits and devices used to control the operation of the connected vehicle 900.
  • the control unit 940 may be coupled to and configured to control drive control components 954, navigation components 956, and one or more sensors 958 of the connected vehicle 900.
  • the control unit 940 may include a processor 964 configured with processor-executable instructions to control maneuvering, navigation, and other operations of the connected vehicle 900, including operations of various embodiments.
  • the processor 964 may be coupled to a memory 966.
  • the control unit 962 may include an input module 968, an output module 970, and a radio module 972.
  • the processor 964 may be configured to implement the functions of the vehicle autonomous driving system (VADS) discussed throughout this application.
  • VADS vehicle autonomous driving system
  • the radio module 972 may be configured for wireless communication.
  • the radio module 972 may exchange signals 982 (e.g., command signals for controlling maneuvering, signals from navigation facilities, etc. ) with a network transceiver 980, and may provide the signals 982 to the processor 964 and/or the navigation unit 956.
  • the radio module 972 may enable the connected vehicle 900 to communicate with a wireless communication device 990 through a wireless communication link 992.
  • the wireless communication link 992 may be a bidirectional or unidirectional communication link, and may use one or more communication protocols.
  • the input module 968 may receive sensor data from one or more vehicle sensors 958 as well as electronic signals from other components, including the drive control components 954 and the navigation components 956.
  • the output module 970 may be used to communicate with or activate various components of the connected vehicle 900, including the drive control components 954, the navigation components 956, and the sensor (s) 958.
  • the control unit 940 may be coupled to the drive control components 954 to control physical elements of the connected vehicle 900 related to maneuvering and navigation of the connected vehicle, such as the engine, motors, throttles, steering elements, flight control elements, braking or deceleration elements, and the like.
  • the drive control components 954 may also include components that control other devices of the connected vehicle, including environmental controls (e.g., air conditioning and heating) , external and/or interior lighting, interior and/or exterior informational displays (which may include a display screen or other devices to display information) , and other similar devices.
  • the control unit 940 may be coupled to the navigation components 956, and may receive data from the navigation components 956 and be configured to use such data to determine the present position and orientation of the connected vehicle 900, as well as an appropriate course toward a destination.
  • the navigation components 956 may include or be coupled to a global navigation satellite system (GNSS) receiver system (e.g., one or more Global Positioning System (GPS) receivers) enabling the connected vehicle 900 to determine its current position using GNSS signals.
  • GNSS global navigation satellite system
  • GPS Global Positioning System
  • the navigation components 956 may include radio navigation receivers for receiving navigation beacons or other signals from radio nodes, such as Wi-Fi access points, cellular network sites, radio station, remote computing devices, other vehicles, etc.
  • the processor 964 may control the connected vehicle 900 to navigate and maneuver.
  • the processor 964 and/or the navigation components 956 may be configured to communicate with a server 984 on a network 986 (e.g., the Internet) using a wireless connection 982 with a cellular data network 980 to receive commands to control maneuvering, receive data useful in navigation, provide real-time position reports, and assess other data.
  • a network 986 e.g., the Internet
  • the control unit 962 may be coupled to one or more sensors 958.
  • the sensor (s) 958 may include the sensors 902-938 as described, and may the configured to provide a variety of data to the processor 964.
  • control unit 940 is described as including separate components, in some embodiments some or all of the components (e.g., the processor 964, the memory 966, the input module 968, the output module 970, and the radio module 972) may be integrated in a single device or module, such as a system-on-chip (SOC) processing device.
  • SOC system-on-chip
  • Such an SOC processing device may be configured for use in vehicles and be configured, such as with processor-executable instructions executing in the processor 964, to perform operations of various embodiments when installed into a connected vehicle.
  • server 1000 typically includes a processor 1001 coupled to volatile memory 1002 and a large capacity nonvolatile memory, such as a disk drive 1004.
  • the server 1000 may also include a floppy disc drive, compact disc (CD) or digital versatile disc (DVD) disc drive 1006 coupled to the processor 1001.
  • the server 1000 may also include one or more wired or wireless network transceivers 1003, such one or more network access ports and/or wired or wireless modems (e.g., one wireless modem, two wireless modems, three wireless modems, four wireless modems, or more than four wireless modems) , coupled to the processor 1001 for establishing network interface connections with one or more communication networks 1007, such as a local area network (e.g., Ethernet, etc. ) coupled to other computing devices and/or servers, the Internet, the public switched telephone network, and/or one or more cellular networks (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, LTE, or any other type of cellular network) .
  • wired or wireless network transceivers 1003 such one or more network access ports and/or wired or wireless modems (e.g., one wireless modem, two wireless modems, three wireless modems, four wireless modems, or more than four wireless modems) ,
  • the processors 274, 964, 1001 may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described above. In some devices, multiple processors may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications may be stored in the internal memory before they are accessed and loaded into the processor 274, 964, 1001.
  • the processor 274, 964, 1001 may include internal memory sufficient to store the application software instructions. In many devices, the internal memory may be a volatile or nonvolatile memory, such as flash memory, or a mixture of both. For the purposes of this description, a general reference to memory refers to memory accessible by the processor 274, 964, 1001 including internal memory or removable memory plugged into the device and memory within the processor 274, 964, 1001.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • a general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine.
  • a processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some steps or methods may be performed by circuitry that is specific to a given function.
  • the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable medium or non-transitory processor-readable medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module, which may reside on a non-transitory computer-readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor.
  • non-transitory computer-readable or processor-readable media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer.
  • Disk and disc includes compact disc (CD) , laser disc, optical disc, digital versatile disc (DVD) , floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media.
  • the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable medium and/or computer-readable medium, which may be incorporated into a computer program product.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne des procédés, des dispositifs et des supports non transitoires lisibles par un processeur afin de communiquer des certificats d'un équipement embarqué de véhicule-à-tout (V2X) à une entité associée. Un véhicule connecté (264) peut être configuré afin d'utiliser l'architecture d'amorçage générique (GBA) ayant des améliorations à base d'UICC (GBA_U) afin de fournir les certificats par une liaison radio (OTA). Le véhicule connecté (264) peut également être équipé d'un stockage sécurisé amovible (RSS) (278) qui fonctionne comme un support multimédia approprié afin de demander et recevoir de nouveaux certificats destinées aux communications V2X.
PCT/CN2019/081058 2019-04-02 2019-04-02 Procédés et systèmes de fourniture de certificats pour une communication à partir d'un véhicule WO2020199134A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2019/081058 WO2020199134A1 (fr) 2019-04-02 2019-04-02 Procédés et systèmes de fourniture de certificats pour une communication à partir d'un véhicule

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2019/081058 WO2020199134A1 (fr) 2019-04-02 2019-04-02 Procédés et systèmes de fourniture de certificats pour une communication à partir d'un véhicule

Publications (1)

Publication Number Publication Date
WO2020199134A1 true WO2020199134A1 (fr) 2020-10-08

Family

ID=72664592

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/081058 WO2020199134A1 (fr) 2019-04-02 2019-04-02 Procédés et systèmes de fourniture de certificats pour une communication à partir d'un véhicule

Country Status (1)

Country Link
WO (1) WO2020199134A1 (fr)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112311539A (zh) * 2020-10-30 2021-02-02 中电智能技术南京有限公司 一种基于gba机制发放证书的方法
GB2600498A (en) * 2020-10-29 2022-05-04 Motional Ad Llc Device provisioning and authentication
WO2022159173A1 (fr) * 2021-01-19 2022-07-28 Qualcomm Incorporated Détection de mauvais comportement de véhicule à tout (v2x) à l'aide d'un modèle de données de carte dynamique locale
CN115242694A (zh) * 2022-07-05 2022-10-25 卡斯柯信号(北京)有限公司 一种自动注册多车的方法和系统
US20220368540A1 (en) * 2021-05-13 2022-11-17 Autocrypt Co., Ltd. Method of secure and automated bootstrapping on keys and certificates for v2x environment and device thereof
CN116896761A (zh) * 2023-09-11 2023-10-17 中汽智联技术有限公司 V2x通信异常处理方法、装置、设备及介质
WO2023244013A1 (fr) * 2022-06-14 2023-12-21 엘지전자 주식회사 Procédé et dispositif de détection de mauvais comportement par intégration d'informations environnantes
US12008895B2 (en) 2021-09-23 2024-06-11 Qualcomm Incorporated Vehicle-to-everything (V2X) misbehavior detection using a local dynamic map data model

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090209232A1 (en) * 2007-10-05 2009-08-20 Interdigital Technology Corporation Techniques for secure channelization between uicc and a terminal
US20110258435A1 (en) * 2010-04-19 2011-10-20 Gm Global Technology Operations, Inc. Threat Mitigation in a Vehicle-to-Vehicle Communication Network
US20110289315A1 (en) * 2010-05-18 2011-11-24 Nokia Corporation Generic Bootstrapping Architecture Usage With WEB Applications And WEB Pages
CN103888261A (zh) * 2014-03-24 2014-06-25 北京智谷睿拓技术服务有限公司 证书更新方法及装置
US20150334566A1 (en) * 2012-12-17 2015-11-19 Telefonaktiebolaget L M Ericsson (Publ) Authenticating Public Land Mobile Networks to Mobile Stations
CN105812131A (zh) * 2014-12-30 2016-07-27 浙江高鸿电子技术有限公司 基于车载短距离通信网的车载节点证书更新方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090209232A1 (en) * 2007-10-05 2009-08-20 Interdigital Technology Corporation Techniques for secure channelization between uicc and a terminal
US20110258435A1 (en) * 2010-04-19 2011-10-20 Gm Global Technology Operations, Inc. Threat Mitigation in a Vehicle-to-Vehicle Communication Network
US20110289315A1 (en) * 2010-05-18 2011-11-24 Nokia Corporation Generic Bootstrapping Architecture Usage With WEB Applications And WEB Pages
US20150334566A1 (en) * 2012-12-17 2015-11-19 Telefonaktiebolaget L M Ericsson (Publ) Authenticating Public Land Mobile Networks to Mobile Stations
CN103888261A (zh) * 2014-03-24 2014-06-25 北京智谷睿拓技术服务有限公司 证书更新方法及装置
CN105812131A (zh) * 2014-12-30 2016-07-27 浙江高鸿电子技术有限公司 基于车载短距离通信网的车载节点证书更新方法

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2600498A (en) * 2020-10-29 2022-05-04 Motional Ad Llc Device provisioning and authentication
GB2600498B (en) * 2020-10-29 2023-04-19 Motional Ad Llc Device provisioning and authentication
US11785463B2 (en) 2020-10-29 2023-10-10 Motional Ad Llc Device provisioning and authentication
CN112311539A (zh) * 2020-10-30 2021-02-02 中电智能技术南京有限公司 一种基于gba机制发放证书的方法
WO2022159173A1 (fr) * 2021-01-19 2022-07-28 Qualcomm Incorporated Détection de mauvais comportement de véhicule à tout (v2x) à l'aide d'un modèle de données de carte dynamique locale
US20220368540A1 (en) * 2021-05-13 2022-11-17 Autocrypt Co., Ltd. Method of secure and automated bootstrapping on keys and certificates for v2x environment and device thereof
US12008895B2 (en) 2021-09-23 2024-06-11 Qualcomm Incorporated Vehicle-to-everything (V2X) misbehavior detection using a local dynamic map data model
WO2023244013A1 (fr) * 2022-06-14 2023-12-21 엘지전자 주식회사 Procédé et dispositif de détection de mauvais comportement par intégration d'informations environnantes
CN115242694A (zh) * 2022-07-05 2022-10-25 卡斯柯信号(北京)有限公司 一种自动注册多车的方法和系统
CN116896761A (zh) * 2023-09-11 2023-10-17 中汽智联技术有限公司 V2x通信异常处理方法、装置、设备及介质
CN116896761B (zh) * 2023-09-11 2023-11-28 中汽智联技术有限公司 V2x通信异常处理方法、装置、设备及介质

Similar Documents

Publication Publication Date Title
WO2020199134A1 (fr) Procédés et systèmes de fourniture de certificats pour une communication à partir d'un véhicule
EP3769549B1 (fr) Procédé et système de routage d'un rapport de détection de mauvais comportement d'un équipement embarqué
Hasan et al. Securing vehicle-to-everything (V2X) communication platforms
KR102182082B1 (ko) V2x 통신 장치 및 그의 데이터 통신 방법
US11356284B2 (en) Method and system for reduced V2X receiver processing load using certificates
CN107659550B (zh) 车辆到车辆的私人通信
US9990844B2 (en) Method for handling misbehaving vehicle and V2X communicaton system performing the same
US20160119151A1 (en) Method and system for detecting misbehavior for vehicle-to-anything communication
KR20200141034A (ko) 네트워크 기반 애플리케이션 계층 메시지 처리를 사용하여 v2x 수신기 처리 부하를 감소시키기 위한 방법 및 시스템
US20160087804A1 (en) Method and system for issuing csr certificate for vehicle-to-anything communication
KR101954507B1 (ko) 차량의 인증서 생성 방법 및 장치
US20230155813A1 (en) Vehicle Certificate Application Method, Vehicle-Mounted Device, and Roadside Unit
US10979897B2 (en) Ranking identity and security posture for automotive devices
US11716596B2 (en) Methods and systems for communication vehicle-to-everything (V2X) information
Maple Key security challenges for cloud-assisted connected and autonomous vehicles
Haidar et al. Experimentation and assessment of pseudonym certificate management and misbehavior detection in C-ITS
US11613264B2 (en) Transmit-side misbehavior condition management
US12003966B2 (en) Local misbehavior prevention system for cooperative intelligent transportation systems
US20220232383A1 (en) Local Misbehavior Prevention System for Cooperative Intelligent Transportation Systems
Boström et al. Wireless Threats Against V2X Communication
JP2024512289A (ja) ビークルツーエブリシング（ｖ２ｘ）メッセージ内のプレーンテキストおよび暗号文の認証
CN117044162A (zh) 认证车联网（v2x）消息中的明文和密文
Notaro Simulating Malicious Attacks on VANETs for Connected and Autonomous Vehicles
WO2022191909A1 (fr) Procédés et systèmes de communication d'informations de véhicule à tout (v2x)
CN116918361A (zh) 用于传达车联网(v2x)信息的方法和系统

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: 19922708

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19922708

Country of ref document: EP

Kind code of ref document: A1