WO2021159488A1 - A method of vehicle permanent id report triggering and collecting - Google Patents
A method of vehicle permanent id report triggering and collecting Download PDFInfo
- 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
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
Various embodiments include methods that may be performed by computing platforms of authorized parties, road side units of a surface transportation network, and vehicles to prompt particular vehicles to report permanent vehicle identification in cellular vehicle-to-everything (C-V2X) messages in a protected manner. 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.
Description
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.
The surface transportation industry has increasingly looked to leverage the growing capabilities of cellular and wireless communication technologies through the adoption of Intelligent Transportation Systems (ITS) technologies to increase intercommunication and Safety for both driver-operated vehicles and autonomous vehicles. The vehicle-to-everything (V2X) , particularly the cellular vehicle-to-everything (C-V2X) protocol defined by the 3rd Generation Partnership Project (3GPP) , support ITS technologies and serves as the foundation for vehicles to communicate directly with the communication devices around them.
C-V2X communication technologies hold promise for improving vehicle safety, managing traffic congestion and support autonomous and semi-autonomous vehicles. In V2X system, the most important information broadcasted/exchanged between vehicles, and between vehicles and road side units are basic safety messages. However, there are many other types of messages being defined. For example, SAE J2735 has defined 16 messages, including basic safety messages (BSM) , roadway safety announcements (RSA) , map data (MAP) , Signal Phase and Timing (SPaT) messages, etc. China has defined BSM, Road Sign Information (RSI) messages, MAP, SPaT and Road Safety Messages (RSM) for phase 1 C-V2X deployment.
In C-V2X applications, there is a potential requirement that law enforcement may need to be able to track particular vehicle for various reasons, i.e., car has been stolen. In such case, the vehicle needs to be paged to trigger the transmission the vehicle permanent identification information for routing to the authorized law enforcement agency with proper security and privacy protections. However, there is currently no message in any format that has been defined for paging vehicles or transmitting permanent vehicle identifier information so that it can be received by the authorized law enforcement agency’s server.
To the contrary, most vehicle transmissions, including BSMs which are one of the most important messages transmitted by vehicles, include a temporary identifier due to privacy concerns. 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.
SUMMARY
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. 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. In some aspects, 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. In some aspects, 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.
Further aspects include methods that may be performed by a computing device of a vehicle configured to transmit and receive vehicle-to-everything (C-V2X) messages. Various aspects may include receiving a C-V2X message that includes a protected vehicle identifier, using a vehicle private key to decrypt the protected vehicle identifier to produce an encrypted digest and a signature of an authorized party, obtaining a public key associated with the signature of the authorized party, using the obtained public key to decrypt the encrypted digest to produce a first digest of vehicle identification information, generating a second digest of vehicle identification information using a predefined algorithm, and 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. 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.
In various aspects, 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. In various aspects, 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. In various aspects, the second C-V2X message is a basic safety message (BSM) or a PermanentIDInformationMessage. In various aspects, 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.
The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate exemplary embodiments, and together with the general description given above and the detailed description given below, serve to explain the features of the various embodiments.
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.
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.
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.
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.
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.
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.
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 aspects will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and embodiments are for illustrative purposes and are not intended to limit the scope of the various aspects or the claims.
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.
However, there are a number of circumstances and situations in which 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. ) . As one specific example, 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. ) to page vehicles because the permanent vehicle identifier information is not included in conventional C-V2X messages. Additionally, as a vehicle’s permanent identifier is sensitive information, even when concerned parties (e.g., law enforcement, tax collection, vehicle authorization, etc. ) have a need to page a particular vehicle, the use of the unprotected broadcast of the vehicle’s permanent identifier poses a security and privacy concern. Thus, there is no method in current C-V2X messaging based systems to enable paging of a particular vehicle to cause the particular vehicle to perform certain actions, such as to trigger the particular vehicle to send out its permanent vehicle identifier information and other information, such as its location, status, etc., in a protected manner.
To address this need to page particular vehicles and/or trigger particular vehicle operations using C-V2X messages under certain circumstances, 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. 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. In various embodiments, 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.
In various embodiments, at an authorized party (also referred to as an authorized party) , such as a law enforcement agency, a computing platform (e.g., a server) may cause road side units in a concerned area to broadcast C-V2X messages including a certain information element. In various embodiments, 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. In various embodiments, if a vehicle receives C-V2X messages including the certain information (e.g., embedded in SPAT messages, MAP messages, RSI messages, etc., or in a PermanentIDInformationRequestMessage) , the vehicle may check whether it is the intended receiver vehicle. In various embodiments, as 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) can only be decoded by the intended receiver vehicle, a non-concerned vehicle can only know that it is not the intended receiver vehicle upon receiving the C-V2X message.
In various embodiments, if the vehicle is the intended receiver, 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) . In various embodiments, 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. In various embodiments, if a RSU receives the C-V2X message including the permanent vehicle identifier information (e.g., a BSM that is embedded with permanent vehicle identifier information or a PermanentIDInformationMessage) , 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. In various embodiments, 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.
At the authorized party, such as a law enforcement agency, a computing platform (e.g., one or more servers) 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. As one example, 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.
At the authorized party (also referred to as an authorized party) , such as a law enforcement agency, a computing platform (e.g., a server) 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. In various embodiments, 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) . As examples, the public key may be obtained from memory and/or downloaded from a certificate authority.
In various embodiments, the computing platform (e.g., a server) of the authorized party (also referred to as an authorized party) , such as a law enforcement agency, 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. In various embodiments, the computing platform (e.g., a server) of the authorized party (also referred to as an authorized party) , such as a law enforcement agency, may encrypt the digest with a private key associated with the authorized party to produce an encrypted digest. In various embodiments, 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. 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 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. In various embodiments, 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. In some embodiments, 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. In some embodiments, 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. In some embodiments, the paging instruction message may be a C-V2X message. In some embodiments, 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. As examples, instruction-V2X message including the protected vehicle identifier (either sent to road side units or generated by road side units) 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.
In various embodiments, a road side unit may receive a paging instruction message including a protected vehicle identifier. For example, 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. In various embodiments, the road side unit may transmit a C-V2X message including the protected vehicle identifier. For example, the road side unit may broadcast a C-V2X message including the protected vehicle identifier. In some embodiments, 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. In some embodiments, the C-V2X message including the protected vehicle identifier may be a message type dedicated to carrying protected vehicle identifiers such as a
PermanentIDInformationRequestMessage.
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:
An example schema for a PermanentIDInformationRequestMessage is as follows:
In various embodiments, the computing device of a vehicle may receive the C-V2X message including the protected vehicle identifier from a road side unit. In various embodiments, 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) . In various embodiments, 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. As an example, 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. ) may indicate the decryption was successful. As another example, 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. As another example, 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.
In various embodiments, 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.
In various embodiments, 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. In various embodiments, 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.
In various embodiments, 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.
In some embodiments, 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. At the authorized party, such as a law enforcement agency, a computing platform (e.g., a server) may use the information received in such C-V2X messages (e.g., BSMs or dedicated messages, such as PermanentIDInformationMessages) to determine the private key to decrypt the embedded encrypted information and public key for the vehicle to authenticate the received information.
In some embodiments, 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. In some embodiments, 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.
In various embodiments, a road side unit (RSU) may receive the C-V2X message including the protected vehicle permanent ID information from the vehicle. In various embodiments, the road side unit may generate a reporting message in response to receiving the C-V2X message including the protected vehicle permanent ID information. In some embodiments, 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. In some embodiments, 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. In some embodiments, the generated reporting message may be a C-V2X message, such as a BSM or dedicated message (e.g., PermanentIDInformationMessage) . In this manner 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.
At the authorized party, such as a law enforcement agency, a computing platform (e.g., a server) may use the information received in the BSMs to determine the private key to decrypt the embedded encrypted information and public key for the vehicle to authenticate the received information.
In various embodiments 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. As described, 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. To authenticate the received information, 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. In some embodiments 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. Thus, various embodiments enable authorized parties to obtain information regarding a particular vehicle without compromising the identify or location of the vehicle to unauthorized parties.
As used herein, the terms “component, ” “system, ” “unit, ” “module, ” and the like include a computer-related entity, such as, but not limited to, hardware, firmware, a combination of hardware and software, software, or software in execution, which are configured to perform particular operations or functions. For example, 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. By way of illustration, both 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. 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.
Various embodiments may be implemented within a variety of vehicles, an example vehicle 100 of which is illustrated in FIGS. 1A and 1B. With reference to FIGS. 1A and 1B, 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.
The plurality of sensors 102-138, disposed in or on the vehicle, 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. In particular, 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.
FIG. 2A is a component block diagram illustrating a system 200 of components and support systems suitable for implementing various embodiments. With reference to FIGS. 1A, 1B, and 2A, 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) .
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.
In the example illustrated in FIG. 2A, 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.
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. In various embodiments, 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. Alternatively, or in addition, 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. Through control of the drive control elements 214, 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. For example, 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.
In various embodiments, 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. In some embodiments, 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. In some embodiments, 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.
While the 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. 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.
With reference to FIGS. 1A-2B, a computing platform 224 of an authorized party, such as a law enforcement agency, 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. In some embodiments, the authorized party may control the certificate authority 430.
Vehicle manufacturers or manufacturers of vehicle computing devices (e.g., 140) 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. In some embodiments, the computing platform 224 may store vehicle public keys in a database maintained in memory. In other embodiments, 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.
With vehicle public keys stored in memory of the computing platform 224 of an authorized party and the plurality of public keys and associated key identifiers of the authorized party stored in memory of vehicle computing devices, various embodiments may be implemented. As one specific example, 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. In response to receiving a C-V2X message including its encrypted vehicle identification 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.
The term “system-on-chip” (SOC) is used herein to refer to a set of interconnected electronic circuits typically, but not exclusively, including one or more processors, a memory, and a communication interface. The SOC may include a variety of different types of processors and processor cores, such as a general purpose processor, a central processing unit (CPU) , a digital signal processor (DSP) , a graphics processing unit (GPU) , an accelerated processing unit (APU) , a sub-system processor, an auxiliary processor, a single-core processor, and 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. 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. With reference to FIGS. 1A–3, 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. 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. For example, 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) . In some embodiments, 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. The CAM 305 may be an independent processing unit and/or include an independent or internal clock.
In some embodiments, 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. For example, 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. In some embodiments, 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) .
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) may be shared by two or more of the internal SOC processors/cores (e.g., a DSP 303, a modem processor 304, a graphics processor 306, an applications processor 308, etc. ) .
In some embodiments, the processing device SOC 300 may be included in a vehicle computing device (e.g., 140) for use in a vehicle (e.g., 100) . The 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.
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. In some embodiments, the system 600 may include one or more vehicle computing devices 402 and/or one or more authorized party computing platform (s) 404. With reference to FIGS. 1A-4A, 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.
In some implementations, 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. For example, such 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. In some embodiments, 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.
Processor (s) 434 may be configured to provide information processing capabilities in vehicle computing device (s) 402. As such, 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. Although processor (s) 434 is shown in FIG. 4A as a single entity, this is for illustrative purposes only. In some implementations, 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. As used herein, 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.
It should be appreciated that although 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. The description of the functionality provided by the different 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. For example, one or more of 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. As another example, 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. In some 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. 1A-4B, 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.
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.
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.
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.
In some implementations, 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. For example, such 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. For example, authorized party computing platform (s) 404 may be implemented by a cloud of computing platforms operating together as authorized party computing platform (s) 404.
Processor (s) 454 may be configured to provide information processing capabilities in authorized party computing platform (s) 404. As such, 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. Although processor (s) 454 is shown in FIG. 4B as a single entity, this is for illustrative purposes only. In some implementations, 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. As used herein, 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.
It should be appreciated that although 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. The description of the functionality provided by the different 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. For example, one or more of 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. As another example, 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. In some embodiments, the system 489 may include one or more computing platforms 404 and/or one or more vehicle computing devices 402. With reference to FIGS. 1A-4C, 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.
Concerned information determination module 497 may be configured to determine concerned information, such as a timestamp, position, velocity, heading, etc. In various embodiments, 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.
PermanentIDInformationRequestMessage. In various embodiments, 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. In some embodiments, the generated reporting message may be a C-V2X message, such as a BSM or dedicated message (e.g., PermanentIDInformationMessage) . In this manner 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.
In some implementations, 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. For example, such 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. By way of non-limiting example, 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. By way of non-limiting example, 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.
Processor (s) 494 may be configured to provide information processing capabilities in road side unit 490. As such, 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. Although processor (s) 494 is shown in FIG. 4C as a single entity, this is for illustrative purposes only. In some implementations, 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. As used herein, 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.
It should be appreciated that although 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. For example, one or more of 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. As another example, 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. With reference to FIGS. 1A-5A, 5B, 5C, and 5D, 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. In some embodiments, the method 500 may be may be implemented in a processor of a server within an authorized party computing platform 404.
Referring to FIG. 5A, in block 502, 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. As one example, 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.
In block 504, 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. In various embodiments, 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) . As examples, the public key may be obtained from memory and/or downloaded from a certificate authority.
In block 506, a processor of the computing platform may perform operations including generating a digest of vehicle identification information using a predefined algorithm. In various embodiments, 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.
In block 508, 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. In various embodiments, the computing platform may encrypt the digest with a private key associated with the authorized party to produce an encrypted digest. In various embodiments, 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.
In block 510, 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. In various embodiments, 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.
In block 512, 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. 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 reconstitute the first concatenated data (e.g., the encrypted digest and a signature of the authorized party) .
In block 514, 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. In various embodiments, 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. In some embodiments, 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. In some embodiments, 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. In some embodiments, the paging instruction message may be a C-V2X message. In some embodiments, 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. As examples, instruction-V2X message including the protected vehicle identifier (either sent to road side units or generated by road side units) 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.
In block 516, 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 (including the embedded encrypted information) 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.
In block 518, 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) .
In block 520, 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. For example, 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.
In block 522, the processor may perform operations including using the vehicle identification information to obtain a vehicle public key. For example, 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.
In block 524, 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.
In block 526, the processor may perform operations including generating a digest of the first decrypted data using a predefined algorithm. In particular, 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.
In determination block 528, 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. ) .
In response to determining that the first decrypted data is authentic (i.e., determination block 528 = “Authentic” ) , the processor may consider or use the first decrypted data in an operation in block 532. For example, 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.
In response to determining that the first decrypted data is not authentic (i.e., determination block 528 = “Not Authentic” ) , 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.
In block 534, 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.
In block 536, 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.
In block 538, 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.
In block 540, 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.
In block 542, 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. With reference to FIGs. 1A-6A, 6B, and 6C, the method 600 may be implemented in a processor of a road side unit. In some embodiments, the method 600 may be implements in processor of a road side unit (e.g., RSU 220, road side unit 490, etc. ) .
Referring to FIG. 6A, in block 602, a processor of the road side unit may perform operations including receiving a paging instruction message including a protected vehicle identifier. For example, 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.
In block 604, the processor may perform operations including transmitting a C-V2X message including the protected vehicle identifier in response to receiving the paging instruction message. For example, the road side unit may broadcast a C-V2X message including the protected vehicle identifier. In various embodiments, 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. In various embodiments, 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.
In block 606, the processor may perform operations including receiving a C-V2X message including protected vehicle permanent ID information. In various embodiments, a road side unit (RSU) may receive the C-V2X message including the protected vehicle permanent ID information from the vehicle.
In block 608, the processor may perform operations including generating a reporting message in response to receiving the C-V2X message including protected vehicle permanent ID information. In various embodiments, 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.
In block 610, the processor may perform operations including sending the reporting message to an authorized party. In various embodiments, 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. In some embodiments, the generated reporting message may be a C-V2X message, such as a BSM or dedicated message (e.g., PermanentIDInformationMessage) . In this manner 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.
In block 612, 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. In various embodiments, 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.
In block 608a, 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. With reference to FIGs. 1A-7A, 7B, 7C, and/or 7D, 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) .
Referring to FIG. 7A, in block 702, 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. In various embodiments, the computing device of a vehicle may receive the C-V2X message including the protected vehicle identifier from a road side unit.
In block 704, 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. In various embodiments, 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) .
In block 706, the processor of the vehicle computing device may perform operations including obtaining a public key associated with the signature of the authorized party. In various embodiments, 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.
In block 708, 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.
In block 710, 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.
In determination block 712, 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. ) .
In response to determining the digests do not match (i.e., determination block 712 = “No Match” ) , the processor of the vehicle computing device may perform operations including ignoring the C-V2X message including the protected vehicle identifier in block 714.
In response to determining the digests do match (i.e., determination block 712 = “Match” ) , the processor may perform operations including triggering sensitive information reporting in block 716. In various embodiments, 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.
In block 718, 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.
In block 720, 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.
In block 722, the processor may perform operations including concatenating the signature and the vehicle identification information to form first concatenated data.
In block 724, 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.
In block 726, the processor may perform operations including encrypting the first concatenated data using the selected public key to produce an encrypted output.
In block 728, the processor may perform operations including concatenating the encrypted output and the key identifier of the selected public key to produce second concatenated data.
In block 730, the processor may perform operations including transmitting the second concatenated data in a C-V2X message. For example, 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.
In block 718a, 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.
In block 722a, 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.
In determination block 732, 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) .
In response to determining that the decryption of the protected vehicle identifier was successful (i.e., determination block 732 = “Success” ) , 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. In this manner, 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.
In response to determining that the decryption of the protected vehicle identifier was not successful (i.e., determination block 732 = “Failure” ) , 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) implementing various embodiments may be a stand-alone computing device, such as a server, coupled to a network, or may be implemented in a distributed fashion in a network of servers (e.g., in the “cloud” ) . An example computing platform in the form of a server suitable for implementing the computing platform in a stand-alone or distributed architecture is illustrated in FIG. 8. With reference to FIGS. 1A–8, 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. In some embodiments, 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. For example, 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. With reference to FIGS. 1A–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. In some embodiments, 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. In some embodiments, 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. In some embodiments, 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. In some embodiments, 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. In some embodiments, 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. In some embodiments, 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.
Various embodiments illustrated and described are provided merely as examples to illustrate various features of the claims. However, features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment and may be used or combined with other embodiments that are shown and described. Further, the claims are not intended to be limited by any one example embodiment.
The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the blocks of various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the order of blocks in the foregoing embodiments may be performed in any order. Words such as “thereafter, ” “then, ” “next, ” etc. are not intended to limit the order of the blocks; these words are simply used to guide the reader through the description of the methods. Further, any reference to claim elements in the singular, for example, using the articles “a, ” “an” or “the” is not to be construed as limiting the element to the singular.
The various illustrative logical blocks, modules, circuits, and algorithm blocks described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and blocks have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such embodiment decisions should not be interpreted as causing a departure from the scope of various embodiments.
The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. 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.
In various embodiments, 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. By way of example but not limitation, such 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, as used herein, 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. Additionally, 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.
The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present embodiments. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the scope of the embodiments. Thus, various embodiments are not intended to be limited to the embodiments shown herein but are to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.
Claims (26)
- A method performed by a computing platform for paging a vehicle using a cellular vehicle-to-everything (C-V2X) message, comprising:receiving vehicle identification information of a 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 an 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; andsending a paging instruction message including the protected vehicle identifier to all road side units in the paging area of concern.
- The method of claim 1, wherein the paging instruction message is a C-V2X message.
- A computing platform, comprising:a memory; anda processor coupled to the memory and to a transceiver and configured with process-executable instructions to:receive vehicle identification information of a vehicle to be paged and an indication of a paging area of concern;obtain a public key associated with the vehicle identification information;generate a digest of vehicle identification information using a predefined algorithm;encrypt the digest with a private key associated with an authorized party to produce an encrypted digest;concatenate the encrypted digest and a signature of the authorized party to form first concatenated data;encrypt the first concatenated data using the obtained public key associated with the vehicle identification information to produce a protected vehicle identifier; andsend a paging instruction message including the protected vehicle identifier to all road side units in the paging area of concern.
- The computing platform of claim 3, wherein the processor is further configured with processor-executable instructions such that the paging instruction message is a C-V2X message.
- A method performed by a road side unit for paging a vehicle using a cellular vehicle-to-everything (C-V2X) message, comprising:receiving a paging instruction message from an authorized party, the paging instruction message including a protected vehicle identifier; andtransmitting a C-V2X message including the protected vehicle identifier in response to receiving the paging instruction message.
- The method of claim 5, wherein the C-V2X message is a Signal Phase and Timing (SPAT) message, Map Data (MAP) message, Road Sign Information (RSI) message, or a PermanentIDInformationRequestMessage.
- The method of claim 5, further comprising:receiving a C-V2X message from a vehicle, the received C-V2X message including protected vehicle permanent ID information;generating a reporting message in response to receiving the C-V2X message including protected vehicle permanent ID information; andsending the reporting message to the authorized party.
- The method of claim 7, further comprising:determining concerned information based at least in part on the received C-V2X message including protected vehicle permanent ID information,wherein 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.
- A road side unit, comprising:a memory;a transceiver; anda processor coupled to the memory and the transceiver and configured with process-executable instructions to:receive a paging instruction message from an authorized party, the paging instruction message including a protected vehicle identifier; andtransmit a C-V2X message including the protected vehicle identifier in response to receiving the paging instruction message.
- The road side unit of claim 9, wherein the processor is further configured with processor-executable instructions such that the C-V2X message is a Signal Phase and Timing (SPAT) message, Map Data (MAP) message, Road Sign Information (RSI) message, or a PermanentIDInformationRequestMessage.
- The road side unit of claim 9, wherein the processor is further configured with processor-executable instructions to:receive a C-V2X message from a vehicle, the received C-V2X message including protected vehicle permanent ID information;generate a reporting message in response to receiving the C-V2X message including protected vehicle permanent ID information; andsend the reporting message to the authorized party.
- The road side unit of claim 11, wherein:the processor is further configured with processor-executable instructions to determine concerned information based at least in part on the received C-V2X message including protected vehicle permanent ID information; andthe processor is further configured with processor-executable instructions such that 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.
- A method performed by a computing device of a vehicle configured to transmit and receive cellular vehicle-to-everything (C-V2X) messages, comprising:receiving a C-V2X message that includes a protected vehicle identifier;using a vehicle private key to decrypt the protected vehicle identifier to produce an encrypted digest and a signature of an authorized party;obtaining a public key associated with the signature of the authorized party;using the obtained public key to decrypt the encrypted digest to produce a first digest of vehicle identification information;generating a second digest of vehicle identification information using a predefined algorithm; anddetermining 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.
- The method of claim 13, further comprising:ignoring the C-V2X message including the protected vehicle identifier in response to determining the vehicle is not the intended receiver; andtriggering sensitive information reporting in response to determining the vehicle is the intended receiver.
- The method of claim 14, wherein sensitive information reporting comprises: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; andtransmitting the second concatenated data in a second C-V2X message.
- The method of claim 15, wherein generating a digest of vehicle identification information using the predefined algorithm comprises:generating the digest of vehicle identification information and other sensitive information using the predefined algorithm; andconcatenating the signature, the vehicle identification information and the other sensitive information to form the second concatenated data.
- The method of claim 15, wherein the second C-V2X message is a basic safety message (BSM) or a PermanentIDInformationMessage.
- The method of claim 13, further comprising:determining whether decryption of the protected vehicle identifier to produce the encrypted digest and the signature of the authorized party was successful; andignoring the C-V2X message including the protected vehicle identifier in response to determining the decryption of the protected vehicle identifier was not successful.
- The method of claim 13, wherein 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.
- A vehicle, comprising:a memory; anda processor coupled to the memory and to a transceiver and configured with process-executable instructions to:receive a C-V2X message that includes a protected vehicle identifier;use a vehicle private key to decrypt the protected vehicle identifier to produce an encrypted digest and a signature of an authorized party;obtain a public key associated with the signature of the authorized party;use the obtained public key to decrypt the encrypted digest to produce a first digest of vehicle identification information;generate a second digest of vehicle identification information using a predefined algorithm; anddetermine 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.
- The vehicle of claim 20, wherein the processor is further configured with processor-executable instructions to:ignore the C-V2X message including the protected vehicle identifier in response to determining the vehicle is not the intended receiver; andtrigger sensitive information reporting in response to determining the vehicle is the intended receiver.
- The vehicle of claim 21, wherein the processor is further configured with processor-executable instructions such that sensitive information reporting comprises: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; andtransmitting the second concatenated data in a second C-V2X message.
- The vehicle of claim 22, wherein the processor is further configured with processor-executable instructions such that generating a digest of vehicle identification information using the predefined algorithm comprises:generating the digest of vehicle identification information and other sensitive information using the predefined algorithm; andconcatenating the signature, the vehicle identification information and the other sensitive information to form the second concatenated data.
- The vehicle of claim 22, wherein the processor is further configured with processor-executable instructions such that the second C-V2X message is a basic safety message (BSM) or a PermanentIDInformationMessage.
- The vehicle of claim 20, wherein the processor is further configured with processor-executable instructions to:determine whether decryption of the protected vehicle identifier to produce the encrypted digest and the signature of the authorized party was successful; andignore the C-V2X message including the protected vehicle identifier in response to determining the decryption of the protected vehicle identifier was not successful.
- The vehicle of claim 20, wherein the processor is further configured with processor-executable instructions such that 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.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2020/075328 WO2021159488A1 (en) | 2020-02-14 | 2020-02-14 | A method of vehicle permanent id report triggering and collecting |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2020/075328 WO2021159488A1 (en) | 2020-02-14 | 2020-02-14 | A method of vehicle permanent id report triggering and collecting |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2021159488A1 true WO2021159488A1 (en) | 2021-08-19 |
Family
ID=77291401
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2020/075328 WO2021159488A1 (en) | 2020-02-14 | 2020-02-14 | A method of vehicle permanent id report triggering and collecting |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2021159488A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115037546A (en) * | 2022-06-20 | 2022-09-09 | 深圳海星智驾科技有限公司 | Key leakage judgment method and device, electronic equipment and storage medium |
CN115240430A (en) * | 2022-09-15 | 2022-10-25 | 湖南众天云科技有限公司 | Method, system and medium for distributed cascade fusion of roadside device information |
CN117565892A (en) * | 2023-11-17 | 2024-02-20 | 上海智能汽车融合创新中心有限公司 | Relay type automatic driving system and method |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109462822A (en) * | 2018-12-19 | 2019-03-12 | 安徽典典科技发展有限责任公司 | A kind of vehicle is accurately positioned the control system and control method of component |
CN109672996A (en) * | 2018-12-29 | 2019-04-23 | 重庆邮电大学 | One kind being based on V2X roadside device system and its information dispensing method |
WO2019104280A1 (en) * | 2017-11-27 | 2019-05-31 | Intel IP Corporation | Multi-access edge computing (mec) based multi-operator support for c-v2x systems |
EP3562231A1 (en) * | 2016-12-23 | 2019-10-30 | LG Electronics Inc. -1- | Method for performing v2x communication in wireless communication system and device for same |
CN110619749A (en) * | 2019-07-22 | 2019-12-27 | 北京计算机技术及应用研究所 | Automobile electronic identification reading device fused with C-V2X |
CN110769393A (en) * | 2019-11-07 | 2020-02-07 | 公安部交通管理科学研究所 | Identity authentication system and method for vehicle-road cooperation |
CN110784849A (en) * | 2018-07-27 | 2020-02-11 | 福特全球技术公司 | Cellular pair V2X authentication and authorization |
-
2020
- 2020-02-14 WO PCT/CN2020/075328 patent/WO2021159488A1/en active Application Filing
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3562231A1 (en) * | 2016-12-23 | 2019-10-30 | LG Electronics Inc. -1- | Method for performing v2x communication in wireless communication system and device for same |
WO2019104280A1 (en) * | 2017-11-27 | 2019-05-31 | Intel IP Corporation | Multi-access edge computing (mec) based multi-operator support for c-v2x systems |
CN110784849A (en) * | 2018-07-27 | 2020-02-11 | 福特全球技术公司 | Cellular pair V2X authentication and authorization |
CN109462822A (en) * | 2018-12-19 | 2019-03-12 | 安徽典典科技发展有限责任公司 | A kind of vehicle is accurately positioned the control system and control method of component |
CN109672996A (en) * | 2018-12-29 | 2019-04-23 | 重庆邮电大学 | One kind being based on V2X roadside device system and its information dispensing method |
CN110619749A (en) * | 2019-07-22 | 2019-12-27 | 北京计算机技术及应用研究所 | Automobile electronic identification reading device fused with C-V2X |
CN110769393A (en) * | 2019-11-07 | 2020-02-07 | 公安部交通管理科学研究所 | Identity authentication system and method for vehicle-road cooperation |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115037546A (en) * | 2022-06-20 | 2022-09-09 | 深圳海星智驾科技有限公司 | Key leakage judgment method and device, electronic equipment and storage medium |
CN115037546B (en) * | 2022-06-20 | 2024-04-26 | 深圳海星智驾科技有限公司 | Key leakage judging method and device, electronic equipment and storage medium |
CN115240430A (en) * | 2022-09-15 | 2022-10-25 | 湖南众天云科技有限公司 | Method, system and medium for distributed cascade fusion of roadside device information |
CN117565892A (en) * | 2023-11-17 | 2024-02-20 | 上海智能汽车融合创新中心有限公司 | Relay type automatic driving system and method |
CN117565892B (en) * | 2023-11-17 | 2024-07-02 | 上海智能汽车融合创新中心有限公司 | Relay type automatic driving system and method |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107659550B (en) | Vehicle-to-vehicle private communication | |
WO2021159488A1 (en) | A method of vehicle permanent id report triggering and collecting | |
CN112640502B (en) | Communication method, device and system | |
US10887111B2 (en) | Verification method, verification apparatus, and storage medium including program stored therein | |
CN110149611B (en) | Identity verification method, equipment, system and computer readable medium | |
US11589236B2 (en) | Detecting misbehavior conditions in vehicle-to-everything (V2X) messages | |
US11823554B2 (en) | Methods for embedding protected vehicle identifier information in cellular vehicle-to-everything (C-V2X) messages | |
US20220256333A1 (en) | Method and System for Protecting Proprietary Information Used to Determine a Misbehavior Condition for Vehicle-to-Everything (V2X) Reporting | |
US20240135274A1 (en) | Frictionless, secure method to determine devices are at the same location | |
WO2021146945A1 (en) | Methods for protecting sensitive information in cellular vehicle-to-everything (c-v2x) messages | |
CN115280816B (en) | Method for efficiently providing path history in C-V2X | |
US20230254672A1 (en) | A Method of Communicating Elevation Information In C-V2X | |
TW202232978A (en) | Method and system for protecting proprietary information used to determine a misbehavior condition for vehicle-to-everything (v2x) reporting | |
Maple | Edge computing to support message prioritisation in connected vehicular systems | |
WO2024013789A1 (en) | User equipment, base station, and communication method | |
CN116830622A (en) | Method and system for protecting proprietary information used to determine offending behavior for internet of vehicles (V2X) reporting | |
Rai et al. | Security Challenges of IoT-Enabled Vehicular Communications and Their Countermeasures | |
KR20230153382A (en) | Plaintext and ciphertext authentication in Vehicle-To-Everything (V2X) messages |
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 |