WO2021159488A1 - Procédé de déclenchement de signalement et de collecte d'id permanent de véhicule - Google Patents

Procédé de déclenchement de signalement et de collecte d'id permanent de véhicule Download PDF

Info

Publication number
WO2021159488A1
WO2021159488A1 PCT/CN2020/075328 CN2020075328W WO2021159488A1 WO 2021159488 A1 WO2021159488 A1 WO 2021159488A1 CN 2020075328 W CN2020075328 W CN 2020075328W WO 2021159488 A1 WO2021159488 A1 WO 2021159488A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
message
processor
information
digest
Prior art date
Application number
PCT/CN2020/075328
Other languages
English (en)
Inventor
Rulin XING
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/CN2020/075328 priority Critical patent/WO2021159488A1/fr
Publication of WO2021159488A1 publication Critical patent/WO2021159488A1/fr

Links

Images

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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/80—Arrangements enabling lawful interception [LI]
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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/30—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/75—Temporary identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like

Definitions

  • Cellular and wireless communication technologies have seen explosive growth over the past several years and are being used to support communications between a host of different types of communication devices, such as smartphones, vehicle-based communication devices, infrastructure communication devices, network communication devices, etc. This growth has been fueled by better communications hardware, larger networks, and more reliable protocols.
  • V2X vehicle-to-everything
  • C-V2X cellular vehicle-to-everything
  • 3GPP 3rd Generation Partnership Project
  • C-V2X communication technologies hold promise for improving vehicle safety, managing traffic congestion and support autonomous and semi-autonomous vehicles.
  • V2X system the most important information broadcasted/exchanged between vehicles, and between vehicles and road side units are basic safety messages.
  • BSM basic safety messages
  • RSA roadway safety announcements
  • MAP map data
  • SPaT Signal Phase and Timing
  • BSM basic safety messages
  • RSI Road Sign Information
  • MAP MAP
  • SPaT Road Safety Messages
  • BSMs which are one of the most important messages transmitted by vehicles
  • BSMs can be decoded by all parties for traffic safety purpose. Including temporary identifiers in transmitted BSMs prevents unauthorized parties from tracking vehicles. However, this also prevents law enforcement from paging and tracking vehicles for legitimate government purposes.
  • Various aspects include methods enabling paging of a vehicle, such as an autonomous vehicle, a semi-autonomous vehicle, a driver-operated vehicle, etc., using a cellular vehicle-to-everything (C-V2X) message.
  • C-V2X vehicle-to-everything
  • Various aspects include methods that may be performed by a computing platform of an authorized party to page a particular vehicle using a C-V2X message to cause the vehicle to begin transmitting its permanent identifier and optionally other information via C-V2X messages in a format that can be received and decoded by the computing platform.
  • Various aspects may include receiving vehicle identification information of a particular vehicle to be paged and an indication of a paging area of concern, obtaining a public key associated with the vehicle identification information, generating a digest of vehicle identification information using a predefined algorithm, encrypting the digest with a private key associated with the authorized party to produce an encrypted digest, concatenating the encrypted digest and a signature of the authorized party to form first concatenated data, encrypting the first concatenated data using the obtained public key associated with the vehicle identification information to produce a protected vehicle identifier, and sending a paging instruction message including the protected vehicle identifier to all road side units in the paging area of concern for broadcast.
  • the paging instruction message may be a C-V2X message to be broadcast by the road side units in the paging area of concern.
  • Further aspects include a computing platform having a processor configured with processor-executable instructions to perform operations of any of the methods summarized above. Further aspects include a non-transitory processor-readable storage medium having stored thereon processor-executable software instructions configured to cause a processor of a computing platform to perform operations of any of the methods summarized above. Further aspects include a computing platform having means for performing functions of any of the methods summarized above.
  • Further aspects include methods that may be performed by a road side unit (RSU) for paging a vehicle using a cellular vehicle-to-everything (C-V2X) message.
  • Various aspects may include receiving, from an authorized party, a paging instruction message including a protected vehicle identifier, and transmitting a C-V2X message including the protected vehicle identifier in response to receiving the paging instruction message.
  • the C-V2X message may be a Signal Phase and Timing (SPAT) message, Map Data (MAP) message, Road Sign Information (RSI) message, or a PermanentIDInformationRequestMessage.
  • Various aspects may further include receiving a C-V2X message from a vehicle in which the received C-V2X message includes protected vehicle permanent ID information, generating a reporting message in response to receiving the C-V2X message including protected vehicle permanent ID information, and sending the reporting message to an authorized party.
  • Various aspects may further include determining concerned information based at least in part on the received C-V2X message including protected vehicle permanent ID information and generating the reporting message in response to receiving the C-V2X message including protected vehicle permanent ID information comprises concatenating the concerned information and the protected vehicle permanent ID information to generate the reporting message.
  • Further aspects include a road side unit including a processor configured with processor-executable instructions to perform operations of any of the methods summarized above. Further aspects include a non-transitory processor-readable storage medium having stored thereon processor-executable software instructions configured to cause a processor of a road side unit to perform operations of any of the methods summarized above. Further aspects include a computing device for use in a road side unit and configured to perform operations of any of the methods summarized above. Further aspects include a road side unit having means for performing functions of any of the methods summarized above.
  • Various aspects may further include ignoring the C-V2X message including the protected vehicle identifier in response to determining the vehicle is not the intended receiver, and triggering sensitive information reporting in response to determining the vehicle is the intended receiver.
  • Various aspects may further include determining whether decryption of the protected vehicle identifier to produce the encrypted digest and the signature of the authorized party was successful and ignoring the C-V2X message including the protected vehicle identifier in response to determining the decryption of the protected vehicle identifier was not successful.
  • sensitive information reporting may include generating a digest of vehicle identification information using the predefined algorithm, encrypting the digest with the vehicle private key to produce a signature, concatenating the signature and the vehicle identification information to form first concatenated data, selecting a public key of the authorized party from a list of public keys stored in memory, wherein each public key in the list is associated with a key identifier, encrypting the first concatenated data using the selected public key to produce an encrypted output, concatenating the encrypted output and the key identifier of the selected public key to produce second concatenated data, and transmitting the second concatenated data in a second C-V2X message.
  • generating a digest of vehicle identification information using the predefined algorithm may include generating the digest of vehicle identification information and other sensitive information using the predefined algorithm, and concatenating the signature, the vehicle identification information and the other sensitive information to form the second concatenated data.
  • the second C-V2X message is a basic safety message (BSM) or a PermanentIDInformationMessage.
  • the C-V2X message including the protected vehicle identifier is a Signal Phase and Timing (SPAT) message, Map Data (MAP) message, Road Sign Information (RSI) message, or a PermanentIDInformationRequestMessage.
  • Further aspects include a vehicle including a vehicle computing device having a processor configured with processor-executable instructions to perform operations of any of the methods summarized above. Further aspects include a non-transitory processor-readable storage medium having stored thereon processor-executable software instructions configured to cause a processor to perform operations of any of the methods summarized above. Further aspects include a computing device for use in a vehicle and configured to perform operations of any of the methods summarized above. Further aspects include a vehicle having means for performing functions of any of the methods summarized above.
  • FIGS. 1A and 1B are component block diagrams illustrating a vehicle suitable for implementing various embodiments.
  • FIG. 2A is a system block diagram illustrating components of a vehicle computing device in communication with road side units and other vehicles suitable for implementing various embodiments.
  • FIG. 2B is a communication network diagram illustrating communications between various system elements implementing various embodiments.
  • FIG. 3 is a block diagram illustrating components of an example system on chip for use in a vehicle that may be configured to broadcast, receive, and/or otherwise use C-V2X messages in accordance with various embodiments.
  • FIG. 4A shows a component block diagram of an example system configured for paging a vehicle using a cellular vehicle-to-everything (C-V2X) message.
  • C-V2X cellular vehicle-to-everything
  • FIG. 4B shows a component block diagram of an example system configured for paging a vehicle using a cellular vehicle-to-everything (C-V2X) message.
  • C-V2X cellular vehicle-to-everything
  • FIG. 4C shows a component block diagram of an example system configured for paging a vehicle using a cellular vehicle-to-everything (C-V2X) message.
  • C-V2X cellular vehicle-to-everything
  • FIGS. 5A, 5B, 5C, and/or 5D are process flow diagrams of example methods performed by a computing platform for paging a vehicle using a cellular vehicle-to-everything (C-V2X) message and receiving sensitive information according to various embodiments.
  • C-V2X vehicle-to-everything
  • FIGS. 6A, 6B and 6C show process flow diagrams of example methods performed by a computing device of a road side unit for paging a vehicle using a cellular vehicle-to-everything (C-V2X) message according to various embodiments.
  • C-V2X cellular vehicle-to-everything
  • FIGS. 7A, 7B, 7C, and 7D show process flow diagrams of example methods performed by a computing device of a vehicle for responding to paging via a cellular vehicle-to-everything (C-V2X) message according to various embodiments.
  • C-V2X vehicle-to-everything
  • FIG. 8 is a component block diagram of an example network element suitable for implementing various embodiments.
  • FIG. 9 is a component block diagram of an example Road Side Unit suitable for implementing various embodiments.
  • Various embodiments provide methods and a communication schema for communicating permanent vehicle identification information to an authorized party, such as law enforcement, in response to detecting that there is a need to provide such information.
  • C-V2X messages are designed to be decoded by many parties, including other vehicles and road side units which may be under control of different operators. For this reason, the identifier contained in many C-V2X messages, such as BSMs, is a temporary identifier that cannot be used to track the vehicle and also to maintain the privacy of the operator. Thus, vehicle identification information is obscured from the C-V2X transmissions by vehicles interacting with a surface transportation network, including road side units.
  • an authorized party may need to receive permanent vehicle identification information in order to provide and/or perform legitimate functions (e.g., law enforcement, tax collection, vehicle authorization, etc. ) or provide needed services (e.g., fleet management, emergency response, etc. ) .
  • law enforcement may need to be able to track a particular vehicle for various reasons, including that the vehicle may have been stolen. Since temporary vehicle identifiers included in C-V2X messages are not linked to the vehicle’s permanent identifier and change frequently to prevent unauthorized tracking of vehicles, conventional C-V2X messages may not address the need for concerned parties (e.g., law enforcement, tax collection, vehicle authorization, etc.
  • various embodiments include operations for paging a vehicle, such as an autonomous vehicle, a semi-autonomous vehicle, etc., using a cellular vehicle-to-everything (C-V2X) messages.
  • C-V2X vehicle-to-everything
  • Various embodiments enable paging of particular vehicles using C-V2X messages including encrypted vehicle identifier information in a manner that can only be decrypted by an intended receiver vehicle (e.g., the particular vehicle of interest to an authorized party, such as law enforcement) thereby enabling particular vehicles to be paged by C-V2X messages without risk of compromising the permanent vehicle identifier information of the intended receiver vehicle.
  • such C-V2X messages including encrypted vehicle identifier information may trigger the intended receiver vehicle to send out its permanent vehicle identifier information, as well as optionally other sensitive information (e.g., its location, its status, etc. ) , in a protected manner such that the permanent vehicle identifier information, as well as optionally other sensitive information (e.g., its location, its status, etc. ) , is communicated back to the authorized party (e.g., law enforcement) without risk of compromising the permanent vehicle identifier information of the intended receiver vehicle.
  • the authorized party e.g., law enforcement
  • a computing platform may cause road side units in a concerned area to broadcast C-V2X messages including a certain information element.
  • the certain information element may be either embedded in C-V2X message formats broadcast by the RSU, such as Signal Phase and Timing (SPAT) messages; Map Data (MAP) messages, Road Sign Information (RSI) messages, and Road Safety Messages (RSM) , etc. or may be defined in a C-V2X message format dedicated to carrying the certain information, such as a PermanentIDInformationRequestMessage.
  • a vehicle may check whether it is the intended receiver vehicle.
  • the vehicle may check whether it is the intended receiver vehicle.
  • the permanent vehicle identifier information in the received C-V2X messages including the certain information e.g., embedded in SPAT messages, MAP messages, RSI messages, etc., or in a PermanentIDInformationRequestMessage
  • a non-concerned vehicle can only know that it is not the intended receiver vehicle upon receiving the C-V2X message.
  • the vehicle will send a C-V2X message including its permanent vehicle identifier (e.g., embed its permanent vehicle identifier information is a C-V2X message, such as a Basic Safety Message (BSM) , or send a dedicated C-V2X message including the permanent vehicle identifier information, such as a PermanentIDInformationMessage) .
  • the C-V2X message including the permanent vehicle identifier information at an instructed rate that may be pre-provisioned to the vehicle or indicated by the authorized party.
  • the instructed rate may be a rate lower than that typically used for BSM messages, for example the instructed rate may be lower than 10Hz.
  • the road side unit may collect the permanent vehicle identifier information and relevant predefined concerned information, such as a timestamp, position, velocity, heading, etc., and send the information to the authorized party (also referred to as an authorized party) , such as a law enforcement agency, at previous negotiated rate over a secured channel.
  • the authorized party also referred to as an authorized party
  • the permanent vehicle identifier information in the C-V2X message sent by vehicle is protected (e.g., encrypted) , and only the authorized party can decode the permanent vehicle identifier information.
  • a computing platform may receive vehicle identification information of a vehicle to be paged and an indication of a paging area of concern.
  • the vehicle identification information of the vehicle to be paged may be permanent vehicle identifier of the vehicle to be paged.
  • the indication of the paging area of concern may be a geographic indication of an area over which a paging message is to be broadcast.
  • the vehicle identification information of a vehicle to be paged and an indication of a paging area of concern may be received by a law enforcement entity indicating a specific vehicle has been stolen and the geographic area, such as a city, state, or province, in which the vehicle was last in.
  • a computing platform may obtain a public key associated with the vehicle identification information.
  • the public key may be the public key corresponding to the private key of the vehicle to be paged.
  • public keys of vehicles may be stored in a manner such that public keys are associated with the vehicle identification information of vehicles (e.g., a vehicle permanent ID) .
  • the public key may be obtained from memory and/or downloaded from a certificate authority.
  • the computing platform (e.g., a server) of the authorized party (also referred to as an authorized party) may use a predefined algorithm known to the authorized party and the vehicle, such as a one-way hash function, to generate a digest of vehicle identification information using the predefined algorithm.
  • the computing platform (e.g., a server) of the authorized party (also referred to as an authorized party) may encrypt the digest with a private key associated with the authorized party to produce an encrypted digest.
  • the private key associated with the authorized party may be a private key of a private/public key pair with the public key held by the vehicle to be paged.
  • the processor of the computing platform may concatenate the encrypted digest and a signature of the authorized party to form a first concatenated data.
  • the signature of the authorized party may be an identifier of the authorized party and may be associated with a public key such that a vehicle may use the signature of the authorized party to identify a public key that may be used to decrypt the digest.
  • the processor of the computing platform may encrypt the first concatenated data using the obtained public key associated with the vehicle identification information to produce a protected vehicle identifier.
  • the protected vehicle identifier is encrypted with the public key of the vehicle that is being paged, only that vehicle using its respective private key may be able to successfully decrypt the protected vehicle identifier to reconstitute the first concatenated data (e.g., the encrypted digest and a signature of the authorized party) .
  • the processor of the computing platform may send a paging instruction message including the protected vehicle identifier to all road side units in the paging area of concern.
  • the computing platform may send the paging instruction message to road side units via a surface transportation network (e.g., 435) and/or the Internet (e.g., 224) using any network messaging protocol.
  • the paging instruction message may include indications of sensitive information, such as a vehicle’s location, status, etc., that are to be reported by the vehicle being paged in response to the paging instruction message.
  • the paging instruction message may indicate a rate at which messages responding to the paging instruction message are to be transmitted by the vehicle being paged.
  • the paging instruction message may be a C-V2X message.
  • the paging instruction message may be a non-C-V2X message that is configured to cause a road side unit to generate and broadcast a C-V2X message including the protected vehicle identifier in response to receiving the paging instruction message.
  • instruction-V2X message including the protected vehicle identifier may be a SPAT message, MAP message, RSI message, etc. with the protected vehicle identifier embedded therein or may be a C-V2X message dedicated to carrying protected vehicle identifiers such as a PermanentIDInformationRequestMessage.
  • a road side unit may receive a paging instruction message including a protected vehicle identifier.
  • the road side unit may receive the paging instruction message from the computing platform (e.g., a server) of the authorized party, such as a law enforcement agency.
  • the road side unit may transmit a C-V2X message including the protected vehicle identifier.
  • the road side unit may broadcast a C-V2X message including the protected vehicle identifier.
  • the C-V2X message including the protected vehicle identifier may be a SPAT message, MAP message, RSI message, etc. with the protected vehicle identifier embedded therein.
  • the C-V2X message including the protected vehicle identifier may be a message type dedicated to carrying protected vehicle identifiers such as a
  • An example schema for a SPAT message having a protected vehicle identifier embedded therein is as follows:
  • An example schema for an RSI message having a protected vehicle identifier embedded therein is as follows:
  • An example schema for a MAP message having a protected vehicle identifier embedded therein is as follows:
  • the computing device of a vehicle may receive the C-V2X message including the protected vehicle identifier from a road side unit.
  • the computing device of the vehicle may use the vehicle private key to decrypt the protected vehicle identifier to produce an encrypted digest and a signature of the authorized party (e.g., law enforcement) .
  • the computing device of the vehicle may determine whether decryption of the protected vehicle identifier was successful. As the protected vehicle identifier is encrypted with the public key of the vehicle that is being paged, only that vehicle using its respective private key may be able to successfully decrypt the protected vehicle identifier to successfully reconstitute the encrypted digest and a signature of the authorized party.
  • an attempt at decrypting the protected vehicle identifier to produce an encrypted digest and a signature of the authorized party e.g., law enforcement
  • generating values recognizable as an encrypted digest and a signature of an authorized party e.g., having the correct format, values within an assigned sequence, matching a known authorized party signature, etc.
  • the decryption may indicate the decryption was successful.
  • an attempt at decrypting the protected vehicle identifier to produce an encrypted digest and a signature of the authorized party (e.g., law enforcement) using the vehicle’s private key when the message is not intended for that vehicle may generating values that are not recognizable as an encrypted digest and a signature of an authorized party (e.g., having the wrong format, values within outside an assigned sequence, not matching any known authorized party signatures, etc. ) .
  • An unrecognizable output would indicate to the processor that the decryption failed (was unsuccessful) , and therefore the vehicle is not the intended receiver and the C-V2X message may be ignored.
  • an attempt at decrypting the protected vehicle identifier using the vehicle’s private key when the message is not intended for that vehicle may result in the decryption attempt failing to generate any output at all, in which case the processor would have no result to process and the C-V2X message may be ignored.
  • the computing device of the vehicle may obtain a public key associated with the signature of the authorized party.
  • the signature of the authorized party may be correlated with public keys in a list of public keys stored in memory such that the computing device may select a public key of the authorized party from a list of public keys stored in memory.
  • the computing device of the vehicle may use the obtained public key to decrypt the encrypted digest to produce a first digest of the vehicle identification information.
  • the computing device of the vehicle may generate a second digest of the vehicle identification information using the predefined algorithm.
  • the predefined algorithm may be the same algorithm known to the authorized party and the vehicle, such as a one-way hash function, used to generate the digest of vehicle identification information in the protected vehicle identifier.
  • the computing device of the vehicle may determine whether the vehicle is the intended receiver of the C-V2X message including the protected vehicle identifier based on a comparison of the first digest and the second digest. A mismatch between the digests may indicate the vehicle is not the intended receiver and the C-V2X message may be ignored. A match between the two digests may indicate the vehicle is the intended vehicle and the computing device of the vehicle may trigger sensitive information reporting.
  • sensitive information reporting may include operations to generate a C-V2X message intended for the authorized party, such as a law enforcement agency, that includes the vehicle’s permanent vehicle identifier, as well as optionally other sensitive information (e.g., location, status, etc. ) , protected from identification by parties other than the authorized party.
  • a computing platform e.g., a server
  • the computing device of a vehicle may encrypt vehicle identification information as well as other sensitive information for inclusion within BSM or other C-V2X messages using a combination of a vehicle private key and a selected public key of the authorized party, and use a signature of the information to enable authentication of the information by the authorized party.
  • the computing device may use a predefined algorithm known to the authorized party, such as a one-way hash function, to generate a digest of vehicle identification information and other sensitive information.
  • the computing device may then encrypt the digest using a private key associated with the vehicle to produce a signature or signature value.
  • the computing device may concatenate the signature with the vehicle identification information and other sensitive information to form first concatenated data.
  • the computing device may select a public key of the authorized party from a list of public keys stored in memory. Each public key stored in memory is associated with a key identifier that the computing device also obtains. The computing device may then encrypt the first concatenated data using the selected public key to produce an encrypted output. The computing device may then concatenate the encrypted output with the key identifier of the selected public key to produce second concatenated data. The computing device may then embed the second concatenated data in a C-V2X message, such as a BSM or dedicated message (e.g., PermanentIDInformationMessage) , that is broadcast by the vehicle.
  • the C-V2X message may be broadcast by the vehicle at a low rate, such as a rate lower than typically used for BSM messages, such as below 10Hz. This low rate of broadcast may conserve modem resources at the vehicle and reduce C-V2X bandwidth usage.
  • a road side unit may receive the C-V2X message including the protected vehicle permanent ID information from the vehicle.
  • the road side unit may generate a reporting message in response to receiving the C-V2X message including the protected vehicle permanent ID information.
  • the road side unit may determine concerned information based at least in part on the received C-V2X message including the protected vehicle permanent ID information.
  • the concerned information may include information such as a timestamp, position, velocity, and heading.
  • the RSU may concatenate the concerned information and the protected vehicle permanent ID information to generate the reporting message.
  • the road side unit may send the generated reporting message to the computing platform (e.g., a server) of the authorized party, such as a law enforcement agency.
  • the RSU may send the generated reporting message over a secure channel at a predefined rate.
  • the generated reporting message may be a C-V2X message, such as a BSM or dedicated message (e.g., PermanentIDInformationMessage) .
  • the road side unit may collect reporting messages and send them an authorized party (also referred to as an authorized party) , such as a law enforcement agency.
  • a computing platform e.g., a server
  • the computing platform of the authorized party may receive a C-V2X message from a vehicle, or receive the information in such a message, such as forwarded by a road side unit.
  • the C-V2X message includes encrypted data and a key identifier of the public key that was used by the vehicle computing device in generating the encrypted data.
  • the computing platform may use the key identifier to obtain from memory the private key corresponding to the public key that was used in generating the encrypted data.
  • the computing platform may use the obtained private key to decrypt the encrypted data to read the sensitive information encrypted by the vehicle computing device (referred to as first decrypted data) .
  • the first decrypted data includes vehicle identification information and other sensitive information concatenated with a signature.
  • the computing platform may use the vehicle identification information to obtain a vehicle public key.
  • the computing platform may use the vehicle public key to decrypt the signature to obtain a digest of the data that was encrypted by the vehicle computing device.
  • the computing platform may use the same predetermined algorithm (e.g., one-way has algorithm) as used by the vehicle computing device to produce a digest of the first decrypted data.
  • the computing platform may then compare the decrypted digest of data to the generated digest of the first decrypted data to determine whether the first decrypted data is authentic.
  • the computing platform may consider, use or apply the first decrypted data in response to determining that the first decrypted data is authentic, and discard the first decrypted data in response to determining that the first decrypted data is not authentic.
  • the computing platform may determine that the first decrypted data is authentic in response to the decrypted digest of data matching the generated digest of the first decrypted data, and determine that the first decrypted data is not authentic in response to the decrypted digest of data not matching the generated digest of the first decrypted data.
  • the computing platform may generate the plurality of pairs of a public key and a private key with each public key/private key pair associated with a key identifier, and register the plurality of public keys and associated key identifiers with a certificate authority, and store the private keys and associated key identifiers in memory for use in obtaining private keys corresponding to public keys used by vehicles in generating encrypted data included in received C-V2X messages.
  • the certificate authority may distribute the plurality of public keys and associated key identifiers to vehicles for use in encrypting data for inclusion in C-V2X messages.
  • the computing platform may receive downloads from the certificate authority of a vehicle public key associated with vehicle identification information for each of a plurality of vehicles.
  • the computing platform may store the vehicle public keys and key identifiers, such as in a locally stored database, and use the database to obtain the vehicle public key using the vehicle identification information.
  • Various embodiments provide mechanisms and methods to enable an authorized party, such as law enforcement, to track a particular vehicle via standard C-V2X messaging without revealing which vehicle is being tracked or enabling unauthorized parties to also track the vehicle.
  • an authorized party such as law enforcement
  • various embodiments enable authorized parties to obtain information regarding a particular vehicle without compromising the identify or location of the vehicle to unauthorized parties.
  • a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer.
  • a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer.
  • an application running on a communication device and the communication device may be referred to as a component.
  • One or more components may reside within a process and/or thread of execution and a component may be localized on one processor or core and/or distributed between two or more processors or cores. In addition, these components may execute from various non-transitory computer readable media having various instructions and/or data structures stored thereon. Components may communicate by way of local and/or remote processes, function or procedure calls, electronic signals, data packets, memory read/writes, and other known computer, processor, and/or process related communication methodologies.
  • the C-V2X protocol defines two transmission modes that, together, provide a 360° 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) (e.g., 5G New Radio (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.
  • 4G e.g., long term evolution (LTE) systems, LTE- Advanced systems, mobile Worldwide Interoperability for Microwave Access (mobile WiMAX) systems,
  • a vehicle 100 may include a vehicle computing device 140 and a plurality of sensors 102-138, including satellite geopositioning system receivers 108, occupancy sensors 112, 116, 118, 126, 128, tire pressure sensors 114, 120, cameras 122, 136, microphones 124, 134, impact sensors 130, radar 132, and lidar 138.
  • satellite geopositioning system receivers 108 including satellite geopositioning system receivers 108, occupancy sensors 112, 116, 118, 126, 128, tire pressure sensors 114, 120, cameras 122, 136, microphones 124, 134, impact sensors 130, radar 132, and lidar 138.
  • the plurality of sensors 102-138 may be used for various purposes, such as autonomous and semi-autonomous navigation and control, crash avoidance, position determination, etc., as well to provide sensor data regarding objects and people in or on the vehicle 100.
  • the sensors 102-138 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 102-138 may be in wired or wireless communication with a vehicle computing device 140, as well as with each other.
  • the sensors may include one or more cameras 122, 136 or other optical sensors or photo optic sensors.
  • the sensors may further include other types of object detection and ranging sensors, such as radar 132, lidar 138, IR sensors, and ultrasonic sensors.
  • the sensors may further include tire pressure sensors 114, 120, humidity sensors, temperature sensors, satellite geopositioning sensors 108, accelerometers, vibration sensors, gyroscopes, gravimeters, impact sensors 130, 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 124, 134, occupancy sensors 112, 116, 118, 126, 128, proximity sensors, and other sensors.
  • the vehicle computing device 140 which is sometimes referred to as an onboard unit (OBU) , may be configured with processor-executable instructions to perform various embodiments using information received from various sensors, particularly the cameras 122, 136. In some embodiments, the vehicle computing device 140 may supplement the processing of camera images using distance and relative position (e.g., relative bearing angle) that may be obtained from radar 132 and/or lidar 138 sensors. The vehicle computing device 140 may further be configured to control steering, breaking and speed of the vehicle 100 when operating in an autonomous or semi-autonomous mode using information regarding other vehicles determined using various embodiments.
  • OBU onboard unit
  • FIG. 2A is a component block diagram illustrating a system 200 of components and support systems suitable for implementing various embodiments.
  • the system 200 may include vehicle computing devices 140 in vehicles 100, 230 that are configured to communicate via wireless communications (e.g., C-V2X protocol messages 222) with other vehicles and road side units 220, and road side units 220 may communicate with network servers 224 (e.g., via wireless or wired communication links 226) .
  • wireless communications e.g., C-V2X protocol messages 222
  • network servers 224 e.g., via wireless or wired communication links 226) .
  • the road side units 220, the network servers 224 and the wired 226 and wireless communication links connecting such units together into an integrated communication and tracking system may comprise and are referred to generally herein as a surface transportation network 435.
  • Network servers 224 of the surface transportation network 435 may be coupled to wide area network, such as the Internet 228, and be configured to route permanent vehicle information to computing platforms of authorized parties and a certificate authority 430 using any of a variety of known network message transport protocols.
  • a vehicle computing device 140 which may include various circuits and devices used to control the operation of the vehicle 100 as well as communicate with other devices within a surface transportation network 200.
  • the vehicle computing device 140 includes a processor 204, memory 206, an input module 208, an output module 210 and a radio transceiver 212.
  • the vehicle computing device 140 may be coupled to and configured to control drive control components 214, navigation components 216, and one or more sensors 218 of the vehicle 100.
  • the processor 204 that may be configured with processor-executable instructions to control maneuvering, navigation, and/or other operations of the vehicle 100, including operations of various embodiments.
  • the processor 204 may be coupled to the memory 206.
  • the vehicle computing device 140 may include the input module 208, the output module 210, and the radio transceiver 212.
  • the radio transceiver 212 may be configured to transmit and receive C-V2X protocol messages (e.g., BSMs) with road side units 220 and other vehicles 230.
  • C-V2X protocol messages e.g., BSMs
  • the input module 208 may receive sensor data from one or more vehicle sensors 218 as well as electronic signals from other components, including the drive control components 214 and the navigation components 216.
  • the output module 210 may be used to communicate with or activate various components of the vehicle 100, including the drive control components 214, the navigation components 216, and the sensor (s) 218.
  • the vehicle computing device 140 may be coupled to the drive control components 214 to control physical elements of the vehicle 100 related to maneuvering and navigation of the vehicle, such as the engine, motors, throttles, steering elements, flight control elements, braking or deceleration elements, and the like.
  • the drive control components 214 may also include components that control other devices of the 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) , safety devices (e.g., haptic devices, audible alarms, etc. ) , and other similar devices.
  • the vehicle computing device 140 may be coupled to the navigation components 216, and may receive data from the navigation components 216 and be configured to use such data to determine the present position and orientation of the vehicle 100, as well as an appropriate course toward a destination.
  • the navigation components 216 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 vehicle 100 to determine its current position using GNSS signals.
  • GNSS global navigation satellite system
  • GPS Global Positioning System
  • the navigation components 216 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 204 may control the vehicle 100 to navigate and maneuver.
  • the processor 204 and/or the navigation components 216 may be configured to communicate with a road side unit 230 to receive commands to control maneuvering, receive data useful in navigation, provide real-time position reports, and assess other data.
  • the vehicle computing device 140 may be coupled to one or more sensors 218.
  • the sensor (s) 218 may include the sensors 102-138 as described, and may the configured to provide a variety of data to the processor 204.
  • the processor 204 of the vehicle computing device 140 may be configured to receive information regarding the vehicle’s position and direction of travel (e.g., from navigation components 216) , speed (e.g., from drive control components 214) , and other information (e.g., from sensor (s) 218) and generate C-V2X messages, such as BSMs, PermanentIDInformationMessages, etc., for transmission by the radio transceiver 212.
  • BSMs inform other vehicles 230 as well as the surface transportation network 200 via road side units 220 of the vehicle’s status, position, direction of travel and speed so that other vehicles, such as autonomous vehicles, can avoid collisions.
  • BSMs also inform the surface transportation network 200 of the locations and speeds of vehicles on the roadway, enabling the system to identify safety concerns, traffic jams, etc. BSMs may be transmitted frequently so that other vehicles 230 and road side units 220 are kept informed about the vehicles position and state.
  • the processor 204 of the vehicle computing device 140 may be configured to receive BSMs from other vehicles 230 and use such information in controlling vehicle operations (e.g., providing other vehicle positions to drive control components 214 and/or navigation components 216) .
  • the processor 204 may also be configured to receive and process other C-V2X messages from road side units 220, such as RSI messages, MAP messages, SPaT messages, RSM messages, and PermanentIDInformationRequestMessages, and use the information in such messages and use such information in controlling vehicle operations, notifying the operator of safety conditions, etc.
  • the processor 204 may include permanent vehicle identification information in C-V2X messages that will be received by road side units 220, such as BSMs, PermanentIDInformationMessages, etc.
  • the road side units 220 may be configured to forward C-V2X messages including permanent vehicle identification information, as well as other information, to a server 224 of the surface transportation network 220.
  • the road side units 220 may forward the information as C-V2X messages and/or in other type messages.
  • the server 224 may be configured to forward permanent vehicle identification information, as well as other information, obtained from vehicle C-V2X messages, to an appropriate authorized party, such as law enforcement.
  • the vehicle C-V2X messages may include an indication of the circumstance or condition triggering the need to transmit permanent vehicle identification information in vehicle C-V2X messages, which information the server 224 to determine the appropriate authorized party to which the permanent vehicle identification information and other vehicle information should be routed.
  • the vehicle C-V2X messages may identify how permanent vehicle identification information and other information in vehicle C-V2X messages should be routed to the appropriate authorized party, such as an Internet address.
  • vehicle computing device 140 is described as including separate components, in some embodiments some or all of the components (e.g., the processor 204, the memory 206, the input module 208, the output module 210, and the radio transceiver 212) 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 204, to perform operations of various embodiments when installed into a vehicle.
  • FIG. 2B is a communications diagram 250 illustrating examples of information and messages that may be communicated between vehicles 100, the computing platform of an authorized party, such as a law enforcement agency, and a certificate authority 430 in setting up the communication system and during performance of various embodiment methods.
  • an authorized party such as a law enforcement agency
  • a certificate authority 430 in setting up the communication system and during performance of various embodiment methods.
  • a computing platform 224 of an authorized party may initially generate a plurality of pairs of public keys and private keys, along with a key identifier for each pair.
  • the computing platform 224 may store the plurality of private keys and associated key identifiers in local memory in a secure manner.
  • the authorized party computing platform 224 may also register the plurality of public keys along with associated key identifiers with the certificate authority 430.
  • the authorized party may control the certificate authority 430.
  • Vehicle manufacturers or manufacturers of vehicle computing devices may generate a public key and private key for each vehicle computing device, store the private key in secure memory of the vehicle computing device and register the public key with the certificate authority 430. In this registration process the public key of a vehicle computing device may be associated with identification information of the vehicle.
  • the computing platform 224 of an authorized party may receive downloads of vehicle public keys and vehicle identification information from the certificate authority 430.
  • the computing platform 224 may store vehicle public keys in a database maintained in memory.
  • the computing platform 224 may access the certificate authority to obtain a vehicle key by providing the vehicle’s identification information in a query process.
  • the certificate authority 430 may provide a list of authorized party public keys with their associated key identifiers to vehicles 100 and may be stored in local memory by each vehicle’s computing device. In some embodiments, the list of public keys and key identifiers may be stored in memory of the vehicle computing device at the time of manufacture or of registration of the vehicle. In some embodiments, the list or an update to the list of public keys and key identifiers may be transmitted to vehicles by the certificate authority 430, such as in an over-the-air update 258, which the vehicle computing device may receive and store in memory.
  • the computing platform 224 of the concerned agency may encrypt vehicle identification information to generate paging messages for a specific vehicle 100 and instruct the road side unit 220 to broadcast C-V2X messages including the encrypted vehicle identification information to trigger the vehicle 100 to send sensitive information.
  • the computing device of a vehicle 100 may encrypt vehicle identification information and other sensitive information, and embed the encrypted information in broadcast C-V2X messages 222.
  • the C-V2X messages 222 with embedded encrypted information may be received by a road side unit 220.
  • the road side unit 220 may collect information in the received C-V2X messages 222 and pass that information, including the embedded encrypted information to the computing platform 224 of the concerned agency, such as via a direct network connection or via surface transportation network 435.
  • the computing platform 224 of the concerned agency may then decrypt and authenticate the embedded encrypted information according to embodiment methods described herein.
  • SOC system-on-chip
  • CPU central processing unit
  • DSP digital signal processor
  • GPU graphics processing unit
  • APU accelerated processing unit
  • sub-system processor a sub-system processor
  • auxiliary processor a single-core processor
  • multicore processor a multicore processor
  • the SOC may further embody other hardware and hardware combinations, such as a field programmable gate array (FPGA) , a configuration and status register (CSR) , an application-specific integrated circuit (ASIC) , other programmable logic device, discrete gate logic, transistor logic, registers, performance monitoring hardware, watchdog hardware, counters, and time references.
  • FPGA field programmable gate array
  • CSR configuration and status register
  • ASIC application-specific integrated circuit
  • SOCs may be integrated circuits (ICs) configured such that the components of the ICs reside on the same substrate, such as a single piece of semiconductor material (e.g., silicon, etc. ) .
  • FIG. 3 illustrates an example system-on-chip (SOC) architecture of a processing device SOC 300 suitable for implementing various embodiments in vehicles.
  • the processing device SOC 300 may include a number of heterogeneous processors, such as a digital signal processor (DSP) 303, a modem processor 304, an image and object recognition processor 306, a mobile display processor 307, an applications processor 308, and a resource and power management (RPM) processor 317.
  • the processing device SOC 300 may also include one or more coprocessors 310 (e.g., vector co-processor) connected to one or more of the heterogeneous processors 303, 304, 306, 307, 308, 317.
  • coprocessors 310 e.g., vector co-processor
  • Each of the processors may include one or more cores, and an independent/internal clock. Each processor/core may perform operations independent of the other processors/cores.
  • the processing device SOC 300 may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc. ) and a processor that executes a second type of operating system (e.g., Microsoft Windows) .
  • the applications processor 308 may be the SOC’s 300 main processor, central processing unit (CPU) , microprocessor unit (MPU) , arithmetic logic unit (ALU) , etc.
  • the graphics processor 306 may be graphics processing unit (GPU) .
  • the processing device SOC 300 may include analog circuitry and custom circuitry 314 for managing sensor data, analog-to-digital conversions, wireless data transmissions, and for performing other specialized operations, such as processing encoded audio and video signals for rendering in a web browser.
  • the processing device SOC 300 may further include system components and resources 316, such as voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components used to support the processors and software clients (e.g., a web browser) running on a computing device.
  • the processing device SOC 300 also include specialized circuitry for camera actuation and management (CAM) 305 that includes, provides, controls and/or manages the operations of one or more vehicle cameras (e.g., a primary camera, webcam, 3D camera, etc. ) , the video display data from camera firmware, image processing, video preprocessing, video front-end (VFE) , in-line JPEG, high definition video codec, etc.
  • vehicle cameras e.g., a primary camera, webcam, 3D camera, etc.
  • VFE video front-end
  • the CAM 305 may be an independent processing unit and/or include an independent or internal clock.
  • the image and object recognition processor 306 may be configured with processor-executable instructions and/or specialized hardware configured to perform image processing and object recognition analyses involved in various embodiments.
  • the image and object recognition processor 306 may be configured to perform the operations of processing images received from cameras via the CAM 305 to recognize and/or identify other vehicles, and otherwise perform functions of the camera perception layer 204 as described.
  • the processor 306 may be configured to process radar or lidar data.
  • the system components and resources 316, analog and custom circuitry 314, and/or CAM 305 may include circuitry to interface with peripheral devices, such as cameras radar, lidar, electronic displays, wireless communication devices, external memory chips, etc.
  • the processors 303, 304, 306, 307, 308 may be interconnected to one or more memory elements 312, system components and resources 316, analog and custom circuitry 314, CAM 305, and RPM processor 317 via an interconnection/bus module 324, which may include an array of reconfigurable logic gates and/or implement a bus architecture (e.g., CoreConnect, AMBA, etc. ) .
  • Communications may be provided by advanced interconnects, such as high-performance networks-on chip (NoCs) .
  • NoCs high-performance networks-on chip
  • the processing device SOC 300 may further include an input/output module (not illustrated) for communicating with resources external to the SOC, such as a radio transceiver 212, a clock 318 and a voltage regulator 320.
  • Resources external to the SOC e.g., clock 318, voltage regulator 320
  • the processing device SOC 300 may be included in a vehicle computing device (e.g., 140) for use in a vehicle (e.g., 100) .
  • vehicle computing device may include communication links for communication with a telephone network (e.g., 220) , the Internet, and/or a network server (e.g., 184) as described.
  • the processing device SOC 300 may also include additional hardware and/or software components that are suitable for collecting sensor data from sensors, including motion sensors (e.g., accelerometers and gyroscopes of an IMU) , user interface elements (e.g., input buttons, touch screen display, etc. ) , microphone arrays, sensors for monitoring physical conditions (e.g., location, direction, motion, orientation, vibration, pressure, etc. ) , cameras, compasses, GPS receivers, communications circuitry (e.g., WLAN, WiFi, etc. ) , and other well-known components of modern electronic devices.
  • motion sensors e.g., accelerometers and gyroscopes of an IMU
  • user interface elements e.g., input buttons, touch screen display, etc.
  • microphone arrays e.g., sensors for monitoring physical conditions (e.g., location, direction, motion, orientation, vibration, pressure, etc. )
  • GPS receivers e.g., GPS receivers, communications circuitry (e.g.
  • FIG. 4A shows a component block diagram illustrating a system 400 configured performed by a computing device of a vehicle for paging a vehicle using a cellular vehicle-to-everything (C-V2X) message in accordance with various embodiments.
  • the system 600 may include one or more vehicle computing devices 402 and/or one or more authorized party computing platform (s) 404.
  • the vehicle computing device (s) 402 may be similar to the vehicle computing device 140 and include a processor (e.g., 164) or a processing device (e.g., 300) (referred to as a “processor” ) of a vehicle (e.g., 100) .
  • the vehicle computing device (s) 402 may be configured by machine-executable instructions 406.
  • Machine-executable instructions 406 may include one or more instruction modules.
  • the instruction modules may include computer program modules.
  • the instruction modules may include one or more of a digest generating module 408, digest encrypting module 410, signature concatenation module 412, key selection module 414, data encrypting module 416, output concatenation module 418, data transmittal module 420, operation repetition module 422, second transmittal module 424, list receiving module 426, list storing module 428, and/or other instruction modules.
  • Digest generating module 408 may be configured to generate a digest of vehicle identification information using a predefined algorithm.
  • Digest generating module 408 may be configured to generate the digest of vehicle identification information and other sensitive information using the predefined algorithm.
  • Digest encrypting module 410 may be configured to encrypt the digest with a private key associated with the vehicle to produce a signature.
  • Signature concatenation module 412 may be configured to concatenate the signature and the vehicle identification information to form first concatenated data. In some embodiments, the signature concatenation module 412 may be configured to concatenate the signature, the vehicle identification information and the other sensitive information to form the second concatenated data.
  • Key selection module 414 may be configured to select a public key of an authorized party from a list of public keys stored in memory. Each public key in the list may be associated with a key identifier and/or signature of the authorized party.
  • Key selection module 414 may be configured to randomly select the public key of the authorized party from the list of public keys.
  • Data encrypting module 416 may be configured to encrypt the first concatenated data using the selected public key to produce an encrypted output.
  • Output concatenation module 418 may be configured to concatenate the encrypted output and the key identifier of the selected public key to produce second concatenated data.
  • Data transmittal module 420 may be configured to transmit the second concatenated data in a C-V2X message.
  • Operation repetition module 422 may be configured to repeat the operations of randomly selecting the public key of the authorized party from the list of public keys.
  • Second transmittal module 424 may be configured to transmit the second concatenated data in C-V2X messages.
  • List receiving module 426 may be configured to receive an updated list of public keys from a certificate authority 430.
  • List storing module 428 may be configured to store the updated list of public keys in memory.
  • vehicle computing device (s) 402, authorized party computing platform (s) 404, and/or certificate authority 430 may be operatively linked via one or more electronic communication links.
  • electronic communication links may be established, at least in part, via a network such as the Internet and/or other networks. It will be appreciated that this is not intended to be limiting, and that the scope of this disclosure includes implementations in which vehicle computing device (s) 402, authorized party computing platform (s) 404, and/or certificate authority 430 may be operatively linked via some other communication media.
  • a given authorized party computing platform 404 may include one or more servers configured to execute computer program modules.
  • the authorized party computing platform 404 may be may be deployed in the cloud as functionality executing computer program modules on a server within the cloud.
  • the vehicle computing device 402 may access the certificate authority 430 to download the list of public keys associated with key identifiers of the authorized party. For example, the vehicle computing device 402 may periodically access the certificate authority 430 to download an updated list of public keys associated with key identifiers of the authorized party. In some embodiments, the certificate authority 430 may send the list of public keys associated with key identifiers of the authorized party, such as in an over-the-air update procedure.
  • Vehicle computing device (s) 402 may include electronic storage 432, one or more processors 434, and/or other components. Vehicle computing device (s) 402 may include communication lines, or ports to enable the exchange of information with a network and/or other computing platforms. Illustration of vehicle computing device (s) 402 in FIG. 4A is not intended to be limiting. Computing platform (s) 402 may include a plurality of hardware, software, and/or firmware components operating together to provide the functionality attributed herein to vehicle computing device (s) 402. For example, computing platform (s) 402 may be implemented by a cloud of computing platforms operating together as vehicle computing device (s) 402.
  • Electronic storage 432 may include non-transitory storage media that electronically stores information.
  • the electronic storage media of electronic storage 432 may include one or both of system storage that is provided integrally (i.e., substantially non-removable) with vehicle computing device (s) 402 and/or removable storage that is removably connectable to vehicle computing device (s) 402 via, for example, a port (e.g., a universal serial bus (USB) port, a firewire port, etc. ) or a drive (e.g., a disk drive, etc. ) .
  • Electronic storage 432 may include one or more of optically readable storage media (e.g., optical disks, etc.
  • Electronic storage 432 may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and/or other virtual storage resources) .
  • Electronic storage 432 may store software algorithms, information determined by processor (s) 434, information received from computing platform (s) 402, information received from authorized party computing platform (s) 404, and/or other information that enables vehicle computing device (s) 402 to function as described herein.
  • Processor (s) 434 may be configured to provide information processing capabilities in vehicle computing device (s) 402.
  • processor (s) 434 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information.
  • processor (s) 434 is shown in FIG. 4A as a single entity, this is for illustrative purposes only.
  • processor (s) 434 may include a plurality of processing units. These processing units may be physically located within the same device, or processor (s) 434 may represent processing functionality of a plurality of devices operating in coordination.
  • Processor (s) 434 may be configured to execute modules 408, 410, 412, 414, 416, 418, 420, 422, 424, 426, and/or 428, and/or other modules.
  • Processor (s) 434 may be configured to execute modules 408, 410, 412, 414, 416, 418, 420, 422, 424, 426, and/or 428, and/or other modules by software; hardware; firmware; some combination of software, hardware, and/or firmware; and/or other mechanisms for configuring processing capabilities on processor (s) 434.
  • the term “module” may refer to any component or set of components that perform the functionality attributed to the module. This may include one or more physical processors during execution of processor readable instructions, the processor readable instructions, circuitry, hardware, storage media, or any other components.
  • modules 408, 410, 412, 414, 416, 418, 420, 422, 424, 426, and/or 428 are illustrated in FIG. 4A as being implemented within a single processing unit, in implementations in which processor (s) 434 includes multiple processing units, one or more of modules 408, 410, 412, 414, 416, 418, 420, 422, 424, 426, and/or 428 may be implemented remotely from the other modules.
  • modules 408, 410, 412, 414, 416, 418, 420, 422, 424, 426, and/or 428 described below is for illustrative purposes, and is not intended to be limiting, as any of modules 408, 410, 412, 414, 416, 418, 420, 422, 424, 426, and/or 428 may provide more or less functionality than is described.
  • modules 408, 410, 412, 414, 416, 418, 420, 422, 424, 426, and/or 428 may be eliminated, and some or all of its functionality may be provided by other ones of modules 408, 410, 412, 414, 416, 418, 420, 422, 424, 426, and/or 428.
  • processor (s) 434 may be configured to execute one or more additional modules that may perform some or all of the functionality attributed below to one of modules 408, 410, 412, 414, 416, 418, 420, 422, 424, 426, and/or 428.
  • FIG. 4B shows a component block diagram illustrating a system 450 performed by a computing platform 404 for paging a vehicle using a cellular vehicle-to-everything (C-V2X) message in accordance with various embodiments.
  • the system 450 may include one or more computing platforms 404 and/or one or more vehicle computing devices 402. With reference to FIGS.
  • the authorized party computing platform (s) 404 may be a stand-alone computing device, such as a server, coupled to a network, a plurality of servers in a local network, or implemented in a distributed fashion in a disbursed network of servers (e.g., in the “cloud” ) , in which such servers may include a processor for executing operations of the method 500.
  • the vehicle computing devices 402 may include a processor (e.g., 164) or a processing device (e.g., 300) of a vehicle (e.g., 100) as described.
  • the authorized party computing platform (s) 404 may be configured by machine-executable instructions 456.
  • Machine-executable instructions 456 may include one or more instruction modules.
  • the instruction modules may include computer program modules.
  • the instruction modules may include one or more of a message receiving module 458, identifier using module 460, key using module 462, vehicle identification information using module 464, vehicle public key using module 466, digest generating module 468, data determination module 470, data considering module 472, data discarding module 474, pair generating module 476, key registering module 478, key storing module 480, certificate authority receiving module 482, database using module 484, and/or other instruction modules.
  • Message receiving module 458 may be configured to receive a cellular vehicle-to-everything message from a vehicle.
  • the C-V2X message may include encrypted data and a key identifier of a public key that was used by the vehicle in generating the encrypted data.
  • Identifier using module 460 may be configured to use the key identifier to obtain a private key corresponding to the public key that was used to in generating the encrypted data.
  • Key using module 462 may be configured to use the obtained private key to decrypt the encrypted data to produce first decrypted data including vehicle identification information and a signature.
  • Vehicle identification information using module 464 may be configured to use the vehicle identification information to obtain a vehicle public key.
  • Vehicle public key using module 466 may be configured to use the vehicle public key to decrypt the signature to obtain a decrypted digest of data.
  • Digest generating module 468 may be configured to generate a digest of the first decrypted data using a predefined algorithm.
  • Data determination module 470 may be configured to determine whether the first decrypted data is authentic based on a comparison of the decrypted digest of data and the generated digest of the first decrypted data.
  • Data determination module 470 may be configured to determine that the first decrypted data is authentic in response to the decrypted digest of data matching the generated digest of the first decrypted data.
  • Data determination module 470 may be configured to determine that the first decrypted data is not authentic in response to the decrypted digest of data not matching the generated digest of the first decrypted data.
  • Data considering module 472 may be configured to consider the first decrypted data in response to determining that the first decrypted data is authentic.
  • Data discarding module 474 may be configured to discard the first decrypted data in response to determining that the first decrypted data is not authentic.
  • Pair generating module 476 may be configured to generate a plurality of pairs of a public key and a private key with each public key/private key pair associated with a key identifier.
  • Key registering module 478 may be configured to register the plurality of public keys and associated key identifiers with a certificate authority for distribution to vehicles for use in encrypting data for inclusion in C-V2X messages.
  • Key storing module 480 may be configured to store the private keys and associated key identifiers in memory for use in obtaining private keys corresponding to public keys used by vehicles in generating encrypted data included in received C-V2X messages.
  • Certificate authority receiving module 482 may be configured to receive from the certificate authority a vehicle public key associated with vehicle identification information for each of a plurality of vehicles.
  • Database module 484 may be configured to add the received vehicle public key and associated vehicle identification information to a database of vehicle public keys associated with key identifiers that the computing platform uses to obtain the vehicle public key using the vehicle identification information.
  • authorized party computing platform (s) 404, vehicle computing devices 402, and/or the certificate authority 430 may be operatively linked via one or more electronic communication links.
  • electronic communication links may be established, at least in part, via a network such as the Internet and/or other networks. It will be appreciated that this is not intended to be limiting, and that the scope of this disclosure includes implementations in which authorized party computing platform (s) 404, vehicle computing devices 402, and/or certificate authority 430 may be operatively linked via some other communication media.
  • a certificate authority 430 may receive a plurality of public keys associated with key identifiers from a computing platform of an authorized party in a registration process and store the public keys and key identifiers in a database that can be accessed by and downloaded to vehicle computing devices implementing various embodiments.
  • the certificate authority may also receive from manufactures of vehicles or vehicle computing devices a public key that is associated with a private key stored in each vehicle computing device.
  • the certificate authority may store the vehicle public keys in a database that associates each vehicle public key with vehicle identification information, and make the database available for querying or downloading by an authorized party platform.
  • Concerned party computing platform (s) 404 may include electronic storage 452, one or more processors 454, and/or other components as described with reference to FIG. 4B.
  • Concerned party computing platform (s) 404 may include communication lines, or ports to enable the exchange of information with a network and/or other computing platforms. Illustration of authorized party computing platform (s) 404 in FIG. 4B is not intended to be limiting.
  • Concerned party computing platform (s) 404 may include a plurality of hardware, software, and/or firmware components operating together to provide the functionality attributed herein to authorized party computing platform (s) 404.
  • authorized party computing platform (s) 404 may be implemented by a cloud of computing platforms operating together as authorized party computing platform (s) 404.
  • Electronic storage 452 may comprise non-transitory storage media that electronically stores information.
  • the electronic storage media of electronic storage 452 may include one or both of system storage that is provided integrally (i.e., substantially non-removable) with authorized party computing platform (s) 404 and/or removable storage that is removably connectable to authorized party computing platform (s) 404 via, for example, a port (e.g., a USB port, a firewire port, etc. ) or a drive (e.g., a disk drive, etc. ) .
  • Electronic storage 452 may include one or more of optically readable storage media (e.g., optical disks, etc.
  • Electronic storage 452 may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and/or other virtual storage resources) .
  • Electronic storage 452 may store software algorithms, information determined by processor (s) 454, information received from authorized party computing platform (s) 404, information received from vehicle computing devices 402, and/or other information that enables authorized party computing platform (s) 404 to function as described herein.
  • Processor (s) 454 may be configured to provide information processing capabilities in authorized party computing platform (s) 404.
  • processor (s) 454 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information.
  • processor (s) 454 is shown in FIG. 4B as a single entity, this is for illustrative purposes only.
  • processor (s) 454 may include a plurality of processing units. These processing units may be physically located within the same device, or processor (s) 454 may represent processing functionality of a plurality of devices operating in coordination.
  • Processor (s) 454 may be configured to execute modules 458, 460, 462, 464, 466, 468, 470, 472, 474, 476, 478, 480, 482, and/or 484, and/or other modules.
  • Processor (s) 440 may be configured to execute modules 458, 460, 462, 464, 466, 468, 470, 472, 474, 476, 478, 480, 482, and/or 484, and/or other modules by software; hardware; firmware; some combination of software, hardware, and/or firmware; and/or other mechanisms for configuring processing capabilities on processor (s) 454.
  • the term “module” may refer to any component or set of components that perform the functionality attributed to the module. This may include one or more physical processors during execution of processor readable instructions, the processor readable instructions, circuitry, hardware, storage media, or any other components.
  • modules 458, 460, 462, 464, 466, 468, 470, 472, 474, 476, 478, 480, 482, and/or 484 are illustrated in FIG. 4B as being implemented within a single processing unit, in implementations in which processor (s) 454 includes multiple processing units, one or more of modules 458, 460, 462, 464, 466, 468, 470, 472, 474, 476, 478, 480, 482, and/or 484 may be implemented remotely from the other modules.
  • modules 458, 460, 462, 464, 466, 468, 470, 472, 474, 476, 478, 480, 482, and/or 484 described below is for illustrative purposes, and is not intended to be limiting, as any of modules 458, 460, 462, 464, 466, 468, 470, 472, 474, 476, 478, 480, 482, and/or 484 may provide more or less functionality than is described.
  • modules 458, 460, 462, 464, 466, 468, 470, 472, 474, 476, 478, 480, 482, and/or 484 may be eliminated, and some or all of its functionality may be provided by other ones of modules 458, 460, 462, 464, 466, 468, 470, 472, 474, 476, 478, 480, 482, and/or 484.
  • processor (s) 454 may be configured to execute one or more additional modules that may perform some or all of the functionality attributed below to one of modules 458, 460, 462, 464, 466, 468, 470, 472, 474, 476, 478, 480, 482, and/or 484.
  • FIG. 4C shows a component block diagram illustrating a system 489 performed by a road side unit 490 ( “RSU” in the figures) for paging a vehicle using a cellular vehicle-to-everything (C-V2X) message in accordance with various embodiments.
  • the system 489 may include one or more computing platforms 404 and/or one or more vehicle computing devices 402.
  • the road side unit 490 may be computing devices of a surface transportation network, such as base stations, smart street signs, smart lights, closed-circuit television (CCTV) cameras, etc., and may include a processor for executing operations of the method 600.
  • the vehicle computing devices 402 may include a processor (e.g., 164) or a processing device (e.g., 300) of a vehicle (e.g., 100) as described.
  • the road side unit 490 may be configured by machine-executable instructions 494.
  • Machine-executable instructions 494 may include one or more instruction modules.
  • the instruction modules may include computer program modules.
  • the instruction modules may include one or more of a message receiving module 495, message generating module 496, concerned information determination module 497, message transmittal module 498, and/or other instruction modules.
  • Message receiving module 495 may be configured to receive a paging instruction message including a protected vehicle identifier.
  • the road side unit may receive the paging instruction message from the computing platform (e.g., a server) of the authorized party, such as a law enforcement agency.
  • Message receiving module 495 may be configured to receive the C-V2X message including the protected vehicle permanent ID information from the vehicle
  • Message generating module 496 may be configured to generate a C-V2X message.
  • the road side unit may transmit a C-V2X message including the protected vehicle identifier.
  • the road side unit may broadcast a C-V2X message including the protected vehicle identifier.
  • the C-V2X message including the protected vehicle identifier may be a SPAT message, MAP message, RSI message, etc. with the protected vehicle identifier embedded therein.
  • the C-V2X message including the protected vehicle identifier may be a message type dedicated to carrying protected vehicle identifiers such as a PermanentIDInformationRequestMessage.
  • the road side unit may generate a reporting message in response to receiving the C-V2X message including the protected vehicle permanent ID information.
  • Concerned information determination module 497 may be configured to determine concerned information, such as a timestamp, position, velocity, heading, etc.
  • the road side unit may determine concerned information based at least in part on the received C-V2X message including the protected vehicle permanent ID information.
  • the concerned information may include information such as a timestamp, position, velocity, and heading.
  • the RSU may concatenate the concerned information and the protected vehicle permanent ID information to generate the reporting message.
  • Message transmittal module 498 may be configured to transmit C-V2X messages and/or other type messages.
  • the road side unit may transmit a C-V2X message including the protected vehicle identifier.
  • the road side unit may broadcast a C-V2X message including the protected vehicle identifier.
  • the C-V2X message including the protected vehicle identifier may be a SPAT message, MAP message, RSI message, etc. with the protected vehicle identifier embedded therein.
  • the C-V2X message including the protected vehicle identifier may be a message type dedicated to carrying protected vehicle identifiers such as a
  • the road side unit may send the generated reporting message to the computing platform (e.g., a server) of the authorized party, such as a law enforcement agency.
  • the RSU may send the generated reporting message over a secure channel at a predefined rate.
  • the generated reporting message may be a C-V2X message, such as a BSM or dedicated message (e.g., PermanentIDInformationMessage) .
  • the road side unit may collect reporting messages and send them an authorized party (also referred to as an authorized party) , such as a law enforcement agency.
  • vehicle computing device (s) 402, authorized party computing platform (s) 404, road side unit 490, and/or certificate authority 430 may be operatively linked via one or more electronic communication links.
  • electronic communication links may be established, at least in part, via a network such as the Internet and/or other networks. It will be appreciated that this is not intended to be limiting, and that the scope of this disclosure includes implementations in which vehicle computing device (s) 402, authorized party computing platform (s) 404, road side unit 490, and/or certificate authority 430 may be operatively linked via some other communication media.
  • a given road side unit 490 may include one or more processors configured to execute computer program modules.
  • the given road side unit 490 may be base stations, smart street signs, smart lights, CCTV cameras, etc.
  • a given authorized party computing platform 404 may include one or more processors configured to execute computer program modules.
  • the given authorized party computing platform 404 may be a server or may be deployed in the cloud.
  • the vehicle computing device 402 may access the certificate authority 430 to download the list of public keys associated with key identifiers of the authorized party. For example, the vehicle computing device 402 may periodically access the certificate authority 430 to download an updated list of public keys associated with key identifiers of the authorized party. In some embodiments, the certificate authority 430 may send the list of public keys associated with key identifiers of the authorized party, such as in an over-the-air update procedure.
  • road side unit 490 may include electronic storage 492, one or more processors 493, and/or other components.
  • road side unit 490 may include communication lines, or ports to enable the exchange of information with a network and/or other computing platforms. Illustration of road side unit 490 in FIG. 4C is not intended to be limiting.
  • Electronic storage 492 may include non-transitory storage media that electronically stores information.
  • the electronic storage media of electronic storage 492 may include one or both of system storage that is provided integrally (i.e., substantially non-removable) with road side unit 490 and/or removable storage that is removably connectable to road side unit 490 via, for example, a port (e.g., a universal serial bus (USB) port, a firewire port, etc. ) or a drive (e.g., a disk drive, etc. ) .
  • Electronic storage 492 may include one or more of optically readable storage media (e.g., optical disks, etc. ) , magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy drive, etc.
  • Electronic storage 492 may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and/or other virtual storage resources) .
  • Electronic storage 492 may store software algorithms, information determined by processor (s) 494, information received from computing platform (s) 402, information received from authorized party computing platform (s) 404, and/or other information that enables road side unit 490 to function as described herein.
  • Processor (s) 494 may be configured to provide information processing capabilities in road side unit 490.
  • processor (s) 494 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information.
  • processor (s) 494 is shown in FIG. 4C as a single entity, this is for illustrative purposes only.
  • processor (s) 494 may include a plurality of processing units. These processing units may be physically located within the same device, or processor (s) 494 may represent processing functionality of a plurality of devices operating in coordination.
  • Processor (s) 494 may be configured to execute modules 495, 496, 497, and/or 498, and/or other modules.
  • Processor (s) 434 may be configured to execute modules 495, 496, 497, and/or 498, and/or other modules by software; hardware; firmware; some combination of software, hardware, and/or firmware; and/or other mechanisms for configuring processing capabilities on processor (s) 494.
  • the term “module” may refer to any component or set of components that perform the functionality attributed to the module. This may include one or more physical processors during execution of processor readable instructions, the processor readable instructions, circuitry, hardware, storage media, or any other components.
  • modules 495, 496, 497, and/or 498 are illustrated in FIG. 4C as being implemented within a single processing unit, in implementations in which processor (s) 494 includes multiple processing units, one or more of modules 495, 496, 497, and/or 498 may be implemented remotely from the other modules.
  • the description of the functionality provided by the different modules 495, 496, 497, and/or 498 described below is for illustrative purposes, and is not intended to be limiting, as any of modules 495, 496, 497, and/or 498 may provide more or less functionality than is described.
  • modules 495, 496, 497, and/or 498 may be eliminated, and some or all of its functionality may be provided by other ones of modules 495, 496, 497, and/or 498.
  • processor (s) 494 may be configured to execute one or more additional modules that may perform some or all of the functionality attributed below to one of modules 495, 496, 497, and/or 498.
  • FIG. 5A illustrate operations of a method 500 performed by an authorized party (e.g., a law enforcement agency) for paging vehicles to begin transmitting a permanent ID of the vehicle using cellular vehicle-to-everything messages and processing sensitive information encrypted in cellular vehicle-to-everything messages received from the vehicle in accordance with various embodiments.
  • FIGS. 5B, 5C, and 5D illustrate alternative or further details of operations in the method 500 according to some embodiments.
  • the method 500 may be implemented in a processor of a computing platform, such as a server or a cloud-based service (variously referred to as a “processor” ) controlled by the authorized party.
  • the method 500 may be may be implemented in a processor of a server within an authorized party computing platform 404.
  • a processor of the computing platform may perform operations including receiving vehicle identification information of a vehicle to be paged and an indication of a paging area of concern.
  • the vehicle identification information of the vehicle to be paged may be permanent vehicle identifier of the vehicle to be paged.
  • the indication of the paging area of concern may be a geographic indication of an area over which a paging message is to be broadcast.
  • the vehicle identification information of a vehicle to be paged and an indication of a paging area of concern may be received by a law enforcement entity indicating a specific vehicle has been stolen and the geographic area, such as a city, state, or province, in which the vehicle was last in.
  • a processor of the computing platform may perform operations including obtaining a public key associated with the vehicle identification information.
  • the public key may be the public key corresponding to the private key of the vehicle to be paged.
  • public keys of vehicles may be stored in a manner such that public keys are associated with the vehicle identification information of vehicles (e.g., a vehicle permanent ID) .
  • the public key may be obtained from memory and/or downloaded from a certificate authority.
  • a processor of the computing platform may perform operations including generating a digest of vehicle identification information using a predefined algorithm.
  • the computing platform may use a predefined algorithm known to the authorized party and the vehicle, such as a one-way hash function, to generate a digest of vehicle identification information using the predefined algorithm.
  • a processor of the computing platform may perform operations including encrypting the digest with a private key associated with the authorized party to produce an encrypted digest.
  • the computing platform may encrypt the digest with a private key associated with the authorized party to produce an encrypted digest.
  • the private key associated with the authorized party may be a private key of a private/public key pair with the public key held by the vehicle to be paged.
  • a processor of the computing platform may perform operations including concatenating the encrypted digest and a signature of the authorized party to form first concatenated data.
  • the computing platform e.g., 404 of the authorized party, such as a law enforcement agency, may concatenated the encrypted digest and a signature of the authorized party to form a first concatenated data.
  • the signature of the authorized party may be an identifier of the authorized party and may be associated with a public key such that a vehicle may use the signature of the authorized party to identify a public key that may be used to decrypt the digest.
  • a processor of the computing platform may perform operations including encrypting the first concatenated data using the obtained public key associated with the vehicle identification information to produce a protected vehicle identifier.
  • the processor of the computing platform may encrypt the first concatenated data using the obtained public key associated with the vehicle identification information to produce a protected vehicle identifier.
  • the protected vehicle identifier is encrypted with the public key of the vehicle that is being paged, only that vehicle using its respective private key may be able to successfully decrypt the protected vehicle identifier to reconstitute the first concatenated data (e.g., the encrypted digest and a signature of the authorized party) .
  • a processor of the computing platform may perform operations including sending a paging instruction message including the protected vehicle identifier to all road side units in the paging area of concern.
  • the computing platform e.g., 404 of the authorized party, such as a law enforcement agency, may send a paging instruction message including the protected vehicle identifier to all road side units in the paging area of concern.
  • the paging instruction message may be sent via a surface transportation network (e.g., 435) using any network messaging protocol.
  • the paging instruction message may include indications of sensitive information, such as a vehicle’s location, status, etc., that are to be reported by the vehicle being paged in response to the paging instruction message.
  • the paging instruction message may indicate a rate at which messages responding to the paging instruction message are to be transmitted by the vehicle being paged.
  • the paging instruction message may be a C-V2X message.
  • the paging instruction message may be a non-C-V2X message that is configured to cause a road side unit to generate and broadcast a C-V2X message including the protected vehicle identifier in response to receiving the paging instruction message.
  • instruction-V2X message including the protected vehicle identifier may be a SPAT message, MAP message, RSI message, etc. with the protected vehicle identifier embedded therein or may be a C-V2X message dedicated to carrying protected vehicle identifiers such as a PermanentIDInformationRequestMessage.
  • FIG. 5B illustrates example operations that an authorized party computing platform may perform as part of the method 500 for authenticating data received from a vehicle computing device.
  • a processor of the computing platform may perform operations including receiving a reporting message from a road side unit.
  • the reporting message may be a message sent by the road side unit via a secure channel, such as via a surface transportation network (e.g., 435) or the Internet (e.g., 228) .
  • the message may be a cellular vehicle-to-everything message from a vehicle or receiving information that was included in the C-V2X message, including encrypted data and a key identifier of a public key that was used by the vehicle in generating the encrypted data.
  • the C-V2X message or information that was included in the C-V2X message may be received by the computing platform from a road side unit or a surface transportation network via a direct network connection, or via an inter-network (e.g., a transportation system network 435) through a network interface.
  • a road side unit or a surface transportation network via a direct network connection, or via an inter-network (e.g., a transportation system network 435) through a network interface.
  • the processor may perform operations including using the key identifier to obtain a private key corresponding to the public key that was used to in generating the encrypted data.
  • the processor may parse the information that was included in the C-V2X message to obtain the key identifier that was concatenated to the encrypted information (e.g., second encrypted output) .
  • the processor may perform operations including using the obtained private key to decrypt the encrypted data to produce first decrypted data including vehicle identification information and a signature.
  • the processor may use the identifier as a look up value to look up the corresponding public key in a database of public keys maintained in or accessible by the computing platform.
  • the processor may perform operations including using the vehicle identification information to obtain a vehicle public key.
  • the processor may use the vehicle identification information as a look up value to look up the corresponding public key in a database of vehicle public keys maintained in the computing platform or in a query to the certificate authority.
  • the processor may perform operations including using the vehicle public key to decrypt the signature to obtain a decrypted digest of data.
  • the decryption process may use any known method of decryption (e.g., PKI) corresponding to the encryption method used by the vehicle computing device.
  • the processor may perform operations including generating a digest of the first decrypted data using a predefined algorithm.
  • the processor may use the same algorithm, such as a one-way hash algorithm, that was used by the vehicle computing device in generating the signature that is included in the first decrypted data.
  • the processor may determine whether the first decrypted data is authentic based on a comparison of the decrypted digest of data and the generated digest of the first decrypted data. In some embodiments, the processor may determine that the first decrypted data is authentic in response to the decrypted digest of data matching the generated digest of the first decrypted data. In some embodiments, the processor may determine that the first decrypted data is not authentic in response to the decrypted digest of data not matching the generated digest of the first decrypted data.
  • the processor may use any of a number of methods of comparing the decrypted digest of data and the generated digest to determine whether the two values match (e.g., subtracting and check for a remainder, dividing and checking whether the dividend is not equal to 1.0, etc. ) .
  • the processor may consider or use the first decrypted data in an operation in block 532.
  • a law enforcement authority may use permanent vehicle identification information in combination with vehicle position information included in the first decrypted data to track a stolen vehicle.
  • the processor may ignore or discard the first decrypted data in block 530.
  • the method 500 may be repeated periodically or each time a vehicle C-V2X message (or information from a vehicle C-V2X message) is received by the computing platform.
  • FIG. 5C illustrates example operations that an authorized party computing platform may perform as part of the method 500 for initiating a list of public keys that can be downloaded to wireless devices for use in the method 700 as described.
  • a processor of the computing platform may generate a plurality of pairs of a public key and a private key with each public key/private key pair associated with a key identifier. The more public/private key pairs generated, the greater the variability in encrypted data, and thus the greater the protections against unauthorized tracking of vehicles.
  • the processor may perform operations including registering the plurality of public keys and associated key identifiers with a certificate authority for distribution to vehicles for use in encrypting data for inclusion in C-V2X messages.
  • the processor may perform operations including storing the private keys and associated key identifiers in memory for use in obtaining private keys corresponding to public keys used by vehicles in generating encrypted data included in received C-V2X messages. For example, the processor may generate, populate or update a database stored in memory (or accessible memory) of private keys associated with key identifiers for use in obtaining an appropriate private key.
  • the process of generating and registering a plurality of public/private keys may be performed periodically, such as to refresh, update or replace public keys registered with the certificate authority to improve security.
  • FIG. 5D illustrates example operations that an authorized party computing platform may perform as part of the method 500 for obtaining public key information from vehicles for use in decrypting data included in C-V2X messages in accordance with one or more implementations.
  • a processor of the computing platform may perform operations including receiving from the certificate authority a vehicle public key associated with vehicle identification information for each of a plurality of vehicles. For example, these operations may be performed each time a vehicle is registered with a highway authority (e.g., issued a license plate) , each time a vehicle is manufactured, or when a vehicle is registered with a fleet tracking system.
  • a highway authority e.g., issued a license plate
  • the processor may perform operations including adding the received vehicle public key and associated vehicle identification information to a database of vehicle public keys associated with key identifiers that the computing platform uses to obtain vehicle public keys using vehicle identification information.
  • FIG. 6A illustrates operations of a method 600 that may be performed by a road side unit for paging vehicles using C-V2X messages in accordance with various embodiments.
  • FIGS. 6B and 6C illustrate alternative or further details of operations in the method 600 according to some embodiments.
  • the method 600 may be implemented in a processor of a road side unit.
  • the method 600 may be implements in processor of a road side unit (e.g., RSU 220, road side unit 490, etc. ) .
  • a processor of the road side unit may perform operations including receiving a paging instruction message including a protected vehicle identifier.
  • the road side unit may receive the paging instruction message from the computing platform (e.g., a server) of the authorized party, such as a law enforcement agency.
  • the computing platform e.g., a server
  • the authorized party such as a law enforcement agency.
  • the processor may perform operations including transmitting a C-V2X message including the protected vehicle identifier in response to receiving the paging instruction message.
  • the road side unit may broadcast a C-V2X message including the protected vehicle identifier.
  • the C-V2X message including the protected vehicle identifier may be a SPAT message, MAP message, RSI message, etc. with the protected vehicle identifier embedded therein.
  • the C-V2X message including the protected vehicle identifier may be a message type dedicated to carrying protected vehicle identifiers such as a PermanentIDInformationRequestMessage.
  • FIG. 6B illustrates example operations that a road side unit may perform as part of the method 600 for sending reporting messages to an authorized party in accordance with one or more implementations.
  • the processor may perform operations including receiving a C-V2X message including protected vehicle permanent ID information.
  • a road side unit RSU may receive the C-V2X message including the protected vehicle permanent ID information from the vehicle.
  • the processor may perform operations including generating a reporting message in response to receiving the C-V2X message including protected vehicle permanent ID information.
  • the road side unit may generate a reporting message in response to receiving the C-V2X message including the protected vehicle permanent ID information from the vehicle.
  • the processor may perform operations including sending the reporting message to an authorized party.
  • the road side unit may send the generated reporting message to the computing platform (e.g., a server) of the authorized party, such as a law enforcement agency.
  • the RSU may send the generated reporting message over a secure channel at a predefined rate.
  • the generated reporting message may be a C-V2X message, such as a BSM or dedicated message (e.g., PermanentIDInformationMessage) .
  • the road side unit may collect reporting messages and send them an authorized party (also referred to as an authorized party) , such as a law enforcement agency.
  • FIG. 6C illustrates example operations that a road side unit may perform as part of the method 600 for sending reporting messages to an authorized party in accordance with one or more implementations.
  • the processor may perform operations including determining concerned information based at least in part on the received C-V2X message including protected vehicle permanent ID information.
  • the road side unit may determine concerned information based at least in part on the received C-V2X message including the protected vehicle permanent ID information.
  • the concerned information may include information such as a timestamp, position, velocity, and heading.
  • the processor may perform operations including concatenating the concerned information and the protected vehicle permanent ID information to generate the reporting message.
  • the RSU may concatenate the concerned information and the protected vehicle permanent ID information to generate the reporting message.
  • FIG. 7A illustrates operations of a method 700 that may be performed by a computing device of a vehicle for receiving a paging message and encrypting sensitive information, including vehicle identification information in C-V2X messages in accordance with various embodiments.
  • FIGS. 7B, 7C, and 7D illustrate alternative or further details of operations in the method 700 according to some embodiments.
  • the method 500 may be implemented in a processor (e.g., 164) or a processing device (e.g., 300) (variously referred to as a “processor” ) of a vehicle computing device (e.g., 140) of a vehicle (e.g., 100) .
  • the processor of a vehicle computing device may perform operations including receiving a cellular vehicle-to-everything (C-V2X) message including a protected vehicle identifier.
  • the computing device of a vehicle may receive the C-V2X message including the protected vehicle identifier from a road side unit.
  • C-V2X cellular vehicle-to-everything
  • the processor of the vehicle computing device may perform operations including using a vehicle private key to decrypt the protected vehicle identifier to produce an encrypted digest and a signature of an authorized party.
  • the computing device of the vehicle may use the vehicle private key to decrypt the protected vehicle identifier to produce an encrypted digest and a signature of the authorized party (e.g., law enforcement) .
  • the processor of the vehicle computing device may perform operations including obtaining a public key associated with the signature of the authorized party.
  • the computing device of the vehicle may obtain a public key associated with the signature of the authorized party.
  • the signature of the authorized party may be correlated with public keys in a list of public keys stored in memory such that the computing device may select a public key of the authorized party from a list of public keys stored in memory.
  • the processor of the vehicle computing device may perform operations including using the obtained public key to decrypt the encrypted digest to produce a first digest of vehicle identification information.
  • the processor of the vehicle computing device may perform operations including generating a second digest of vehicle identification information using a predefined algorithm.
  • the predefined algorithm may be the same algorithm known to the authorized party and the vehicle, such as a one-way hash function, used to generate the digest of vehicle identification information in the protected vehicle identifier.
  • the processor of the vehicle computing device may perform operations including determining whether the vehicle is an intended receiver of the C-V2X message including the protected vehicle identifier based on a comparison of the first digest and the second digest.
  • a mismatch between the digests may indicate the vehicle is not the intended receiver and the C-V2X message may be ignored.
  • a match between the two digests may indicate the vehicle is the intended vehicle and the computing device of the vehicle may trigger sensitive information reporting.
  • the processor may use any of a number of methods of comparing the digests to determine whether the two values match (e.g., subtracting and check for a remainder, dividing and checking whether the dividend is not equal to 1.0, etc. ) .
  • the processor of the vehicle computing device may perform operations including ignoring the C-V2X message including the protected vehicle identifier in block 714.
  • the processor may perform operations including triggering sensitive information reporting in block 716.
  • sensitive information reporting may include operations to generate a C-V2X message intended for the authorized party, such as a law enforcement agency, that includes the vehicle’s permanent vehicle identifier, as well as optionally other sensitive information (e.g., location, status, etc. ) , protected from identification by parties other than the authorized party.
  • FIG. 7B illustrates operations of an embodiment of the method 700 for sensitive information reporting.
  • the processor of a vehicle computing device may generate a digest of vehicle identification information using a predefined algorithm.
  • the predefined algorithm may be a one-way hash algorithm or other algorithm that will generate a non-reversable value based on the data processed through the algorithm.
  • the processor may perform operations including encrypting the digest with a private key associated with the vehicle to produce a signature.
  • the processor may use any form of encryption based on public keys and private keys.
  • the processor may perform operations including concatenating the signature and the vehicle identification information to form first concatenated data.
  • the processor may perform operations including selecting a public key of an authorized party from a list of public keys stored in memory. Each public key in the list may be associated with a key identifier. This selection of a public key from a list of public keys may be performed randomly so that encrypted data embedded in C-V2X messages does not have a consistent data pattern that can be recognized and tracked by unauthorized parties.
  • the processor may perform operations including encrypting the first concatenated data using the selected public key to produce an encrypted output.
  • the processor may perform operations including concatenating the encrypted output and the key identifier of the selected public key to produce second concatenated data.
  • the processor may perform operations including transmitting the second concatenated data in a C-V2X message.
  • the second concatenated data may be embedded within or appended to BSMs or dedicated messages, such as PermanentIDInformationMessages, that are transmitted once or repeatedly.
  • the C-V2X message may be broadcast by the vehicle at a low rate, such as a rate lower than typically used for BSM messages, such as below 10Hz. This low rate of broadcast may conserve modem resources at the vehicle and reduce C-V2X bandwidth usage.
  • FIG. 7C illustrates operations of an embodiment of the method 700 in which sensitive information is also included in the encrypted data embedded in a C-V2X message.
  • the processor may perform operations including generating the digest of vehicle identification information and other sensitive information using the predefined algorithm.
  • Examples of other sensitive information may include operator information, cargo information, destination information, location, status, etc.
  • the types of other sensitive information that may be included in the digest may depend on the authorized party (e.g., law enforcement) that will be capable of decrypting the information.
  • the processor may perform operations including concatenating the signature, the vehicle identification information, and the other sensitive information to form the second concatenated data. The processor may then proceed with the rest of the operations of the method 700.
  • FIG. 7D illustrates operations of an embodiment of the method 700 in which the success or failure in decrypting the protected vehicle identifier may indicate whether to process or ignore the C-V2X message including the protected vehicle identifier.
  • the processor of the vehicle computing device may perform operations including determining whether decryption of the protected vehicle identifier was successful. For example, if the operations of block 704 generate values that are recognizable as an encrypted digest and a signature of an authorized party (e.g., having the correct format, values within an assigned sequence, matching a known authorized party signature, etc. ) , the processor may determine that the decryption was successful. As another example, if the operations of block 704 generate values that are not recognizable as an encrypted digest and a signature of an authorized party (e.g., having the wrong format, values within outside an assigned sequence, not matching any known authorized party signatures, etc. ) , or fails to generate an output all together, the processor may determine that decryption failed (was unsuccessful) .
  • the processor may perform operations in block 706 including obtaining a public key associated with the signature of the authorized party, and proceed with the rest of the operations of the method 700 as described.
  • obtaining a public key associated with the signature of the authorized party may include obtaining a public key associated with the signature of the authorized party in response to determining the decryption of the protected vehicle identifier was successful.
  • the processor of the vehicle computing device may perform operations including ignoring the C-V2X message including the protected vehicle identifier in block 714.
  • the computing platform of an authorized party e.g., a law enforcement agency
  • a computing platform 800 may typically include a processor 801 coupled to volatile memory 802 and a large capacity nonvolatile memory, such as a disk drive 803.
  • the computing platform 800 also may include network access ports 804 (or interfaces) coupled to the processor 801 for establishing data connections with a network, such as the Internet or a surface transportation network coupled to road side units.
  • the computing platform 800 may include one or more antennas 808 coupled to a wireless transceiver 810 for sending and receiving C-V2X messages.
  • the computing platform 800 also may include a peripheral memory access device such as a floppy disc drive, compact disc (CD) or digital video disc (DVD) drive 806 coupled to the processor 801.
  • the computing platform 800 may include additional access ports, such as USB, Firewire, Thunderbolt, and the like for coupling to peripherals, external memory, or other devices.
  • FIG. 9 is a component block diagram of an example Road Side Unit 900, such as a base station, smart street sign, smart light, CCTV camera, etc., suitable for use in various implementations.
  • the Road Side Unit 900 of FIG. 9 may be a smart light having a light 915 controlled by a processor 901.
  • Such Road Side Units may include at least the components illustrated in FIG. 9.
  • the Road Side Unit 900 may typically include a processor 901 coupled to volatile memory 902.
  • the Road Side Unit 900 may include one or more antennas 907 for sending and receiving wireless RSU messages (e.g., Signal Phase and Timing (SPAT) messages; Map Data (MAP) messages, Road Sign Information (RSI) messages, and Road Safety Messages (RSM) ) .
  • the Road Side Unit 900 also may include a peripheral memory access device such as a floppy disc drive, compact disc (CD) or digital video disc (DVD) drive 906 coupled to the processor 901.
  • the Road Side Unit 900 also may include network access ports 904 (or interfaces) coupled to the processor 901 for establishing data connections with a network, such as the Internet or a local area network coupled to other system computers and servers.
  • the Road Side Unit 900 may include additional access ports, such as USB, Firewire, Thunderbolt, and the like for coupling to peripherals, external memory, or other devices
  • Various embodiments include a computing platform including means for receiving vehicle identification information of a vehicle to be paged and an indication of a paging area of concern, means for obtaining a public key associated with the vehicle identification information, means for generating a digest of vehicle identification information using a predefined algorithm, means for encrypting the digest with a private key associated with an authorized party to produce an encrypted digest, means for concatenating the encrypted digest and a signature of the authorized party to form first concatenated data, means for encrypting the first concatenated data using the obtained public key associated with the vehicle identification information to produce a protected vehicle identifier, and means for sending a paging instruction message including the protected vehicle identifier to all road side units in the paging area of concern.
  • the paging instruction message is a C-V2X message.
  • Various embodiments include a road side unit including means for receiving a paging instruction message from an authorized party, the paging instruction message including a protected vehicle identifier, and means for transmitting a C-V2X message including the protected vehicle identifier in response to receiving the paging instruction message.
  • the C-V2X message is a Signal Phase and Timing (SPAT) message, Map Data (MAP) message, Road Sign Information (RSI) message, or a PermanentIDInformationRequestMessage.
  • Some embodiments may further include, means for receiving a C-V2X message from a vehicle, the received C-V2X message including protected vehicle permanent ID information, means for generating a reporting message in response to receiving the C-V2X message including protected vehicle permanent ID information, and means for sending the reporting message to the authorized party. Some embodiments may further include means for determining concerned information based at least in part on the received C-V2X message including protected vehicle permanent ID information, wherein means for generating the reporting message in response to receiving the C-V2X message including protected vehicle permanent ID information includes means for concatenating the concerned information and the protected vehicle permanent ID information to generate the reporting message.
  • Various embodiments include a vehicle including means for receiving a C- V2X message that includes a protected vehicle identifier, means for using a vehicle private key to decrypt the protected vehicle identifier to produce an encrypted digest and a signature of an authorized party, means for obtaining a public key associated with the signature of the authorized party, means for using the obtained public key to decrypt the encrypted digest to produce a first digest of vehicle identification information, means for generating a second digest of vehicle identification information using a predefined algorithm, and means for determining whether the vehicle is an intended receiver of the C-V2X message including the protected vehicle identifier based on a comparison of the first digest and the second digest.
  • Some embodiments may further include means for ignoring the C-V2X message including the protected vehicle identifier in response to determining the vehicle is not the intended receiver, and means for triggering sensitive information reporting in response to determining the vehicle is the intended receiver.
  • sensitive information reporting may include means for generating a digest of vehicle identification information using the predefined algorithm, means for encrypting the digest with the vehicle private key to produce a signature, means for concatenating the signature and the vehicle identification information to form first concatenated data, means for selecting a public key of the authorized party from a list of public keys stored in memory, wherein each public key in the list is associated with a key identifier, means for encrypting the first concatenated data using the selected public key to produce an encrypted output, means for concatenating the encrypted output and the key identifier of the selected public key to produce second concatenated data, and means for transmitting the second concatenated data in a second C-V2X message.
  • means for generating a digest of vehicle identification information using the predefined algorithm may include means for generating the digest of vehicle identification information and other sensitive information using the predefined algorithm, and means for concatenating the signature, the vehicle identification information and the other sensitive information to form the second concatenated data.
  • the second C-V2X message is a basic safety message (BSM) or a PermanentIDInformationMessage.
  • Some embodiments may further include means for determining whether decryption of the protected vehicle identifier to produce the encrypted digest and the signature of the authorized party was successful, and means for ignoring the C-V2X message including the protected vehicle identifier in response to determining the decryption of the protected vehicle identifier was not successful.
  • the C-V2X message including the protected vehicle identifier is a Signal Phase and Timing (SPAT) message, Map Data (MAP) message, Road Sign Information (RSI) message, or a PermanentIDInformationRequestMessage.
  • SPAT Signal Phase and Timing
  • MAP Map Data
  • RSI Road Sign
  • 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 communication 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 blocks 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 operations 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)
  • Technology Law (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Divers modes de réalisation de l'invention concernent des procédés qui peuvent être mis en œuvre par des plates-formes informatiques de parties autorisées, des unités côté route d'un réseau de transport en surface, et des véhicules pour inviter des véhicules particuliers à signaler une identification de véhicule permanente dans ces messages cellulaires de véhicule à tout (C-V2X) d'une manière protégée. Divers modes de réalisation concernent des mécanismes et des procédés pour permettre à une partie autorisée, tels que les forces de l'ordre, de suivre un véhicule particulier par le biais de la messagerie C-V2X standard sans révéler quel véhicule est suivi ou sans permettre à des parties non autorisées de suivre également le véhicule.
PCT/CN2020/075328 2020-02-14 2020-02-14 Procédé de déclenchement de signalement et de collecte d'id permanent de véhicule WO2021159488A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/075328 WO2021159488A1 (fr) 2020-02-14 2020-02-14 Procédé de déclenchement de signalement et de collecte d'id permanent de véhicule

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/075328 WO2021159488A1 (fr) 2020-02-14 2020-02-14 Procédé de déclenchement de signalement et de collecte d'id permanent de véhicule

Publications (1)

Publication Number Publication Date
WO2021159488A1 true WO2021159488A1 (fr) 2021-08-19

Family

ID=77291401

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/075328 WO2021159488A1 (fr) 2020-02-14 2020-02-14 Procédé de déclenchement de signalement et de collecte d'id permanent de véhicule

Country Status (1)

Country Link
WO (1) WO2021159488A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115037546A (zh) * 2022-06-20 2022-09-09 深圳海星智驾科技有限公司 密钥泄露的判定方法和装置、电子设备和存储介质
CN115240430A (zh) * 2022-09-15 2022-10-25 湖南众天云科技有限公司 路侧设备信息分布式级联融合方法、系统及介质
CN117565892A (zh) * 2023-11-17 2024-02-20 上海智能汽车融合创新中心有限公司 一种接力型自动驾驶系统和方法

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109462822A (zh) * 2018-12-19 2019-03-12 安徽典典科技发展有限责任公司 一种车辆精确定位组件的控制系统及控制方法
CN109672996A (zh) * 2018-12-29 2019-04-23 重庆邮电大学 一种基于v2x路侧设备系统及其信息分发方法
WO2019104280A1 (fr) * 2017-11-27 2019-05-31 Intel IP Corporation Support multi-opérateur basé sur le calcul en périphérie multi-accès (mec) pour systèmes c-v2x
EP3562231A1 (fr) * 2016-12-23 2019-10-30 LG Electronics Inc. -1- Procédé de réalisation d'une communication v2x dans un système de communication sans fil et dispositif associé
CN110619749A (zh) * 2019-07-22 2019-12-27 北京计算机技术及应用研究所 一种融合c-v2x的汽车电子标识识读装置
CN110769393A (zh) * 2019-11-07 2020-02-07 公安部交通管理科学研究所 一种车路协同的身份认证系统及方法
CN110784849A (zh) * 2018-07-27 2020-02-11 福特全球技术公司 蜂窝对v2x认证及授权

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3562231A1 (fr) * 2016-12-23 2019-10-30 LG Electronics Inc. -1- Procédé de réalisation d'une communication v2x dans un système de communication sans fil et dispositif associé
WO2019104280A1 (fr) * 2017-11-27 2019-05-31 Intel IP Corporation Support multi-opérateur basé sur le calcul en périphérie multi-accès (mec) pour systèmes c-v2x
CN110784849A (zh) * 2018-07-27 2020-02-11 福特全球技术公司 蜂窝对v2x认证及授权
CN109462822A (zh) * 2018-12-19 2019-03-12 安徽典典科技发展有限责任公司 一种车辆精确定位组件的控制系统及控制方法
CN109672996A (zh) * 2018-12-29 2019-04-23 重庆邮电大学 一种基于v2x路侧设备系统及其信息分发方法
CN110619749A (zh) * 2019-07-22 2019-12-27 北京计算机技术及应用研究所 一种融合c-v2x的汽车电子标识识读装置
CN110769393A (zh) * 2019-11-07 2020-02-07 公安部交通管理科学研究所 一种车路协同的身份认证系统及方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115037546A (zh) * 2022-06-20 2022-09-09 深圳海星智驾科技有限公司 密钥泄露的判定方法和装置、电子设备和存储介质
CN115037546B (zh) * 2022-06-20 2024-04-26 深圳海星智驾科技有限公司 密钥泄露的判定方法和装置、电子设备和存储介质
CN115240430A (zh) * 2022-09-15 2022-10-25 湖南众天云科技有限公司 路侧设备信息分布式级联融合方法、系统及介质
CN117565892A (zh) * 2023-11-17 2024-02-20 上海智能汽车融合创新中心有限公司 一种接力型自动驾驶系统和方法

Similar Documents

Publication Publication Date Title
CN107659550B (zh) 车辆到车辆的私人通信
WO2021159488A1 (fr) Procédé de déclenchement de signalement et de collecte d'id permanent de véhicule
CN112640502B (zh) 一种通信方法、装置以及系统
US10887111B2 (en) Verification method, verification apparatus, and storage medium including program stored therein
CN110149611B (zh) 一种身份验证方法、设备、系统及计算机可读介质
US11823554B2 (en) Methods for embedding protected vehicle identifier information in cellular vehicle-to-everything (C-V2X) messages
US11589236B2 (en) Detecting misbehavior conditions in vehicle-to-everything (V2X) messages
US20240135274A1 (en) Frictionless, secure method to determine devices are at the same location
US20220256333A1 (en) Method and System for Protecting Proprietary Information Used to Determine a Misbehavior Condition for Vehicle-to-Everything (V2X) Reporting
WO2021146945A1 (fr) Procédés de protection d'informations sensibles dans des messages de véhicule cellulaire à tout (c-v2x)
US20230254672A1 (en) A Method of Communicating Elevation Information In C-V2X
TW202232978A (zh) 用於車輛到一切（ｖ２ｘ）報告的保護用於決定違規行為狀況的專有資訊的方法和系統
Maple Edge computing to support message prioritisation in connected vehicular systems
US20230045323A1 (en) A method of efficiently providing pathhistory in c-v2x
WO2024013789A1 (fr) Équipement utilisateur, station de base, et procédé de communication
CN116830622A (zh) 用于保护用来确定违规行为状况的专有信息以用于车联网（v2x）报告的方法和系统
Rai et al. Security Challenges of IoT-Enabled Vehicular Communications and Their Countermeasures
KR20230156040A (ko) V2X(Vehicle-To-Everything) 정보를 통신하기 위한 방법들 및 시스템들
KR20230153382A (ko) V2X(Vehicle-To-Everything) 메시지에서 평문 및 암호문 인증

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

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

Country of ref document: EP

Kind code of ref document: A1