WO2021146945A1

WO2021146945A1 - Methods for protecting sensitive information in cellular vehicle-to-everything (c-v2x) messages

Info

Publication number: WO2021146945A1
Application number: PCT/CN2020/073603
Authority: WO
Inventors: Rulin XING; Shuping Chen
Original assignee: Qualcomm Incorporated
Priority date: 2020-01-21
Filing date: 2020-01-21
Publication date: 2021-07-29

Abstract

Methods performed by a computing device of a vehicle for including sensitive information in cellular vehicle-to-everything (C-V2X) messages are disclosed. A vehicle computing device may generate a digest of vehicle identification information using a predefined algorithm, encrypt the digest with a private key associated with the vehicle to produce a signature, concatenate the signature and the vehicle identification information to form first concatenated data, select a public key of an authorized party from a list of public keys stored in memory, encrypt the first concatenated data using the selected public key to produce an encrypted output, concatenate the encrypted output and the key identifier of the selected public key to produce second concatenated data, and transmit the second concatenated data in a C-V2X message.

Description

METHODS FOR PROTECTING SENSITIVE INFORMATION IN CELLULAR VEHICLE-TO-EVERYTHING (C-V2X) MESSAGES

BACKGROUND

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 (RSUs) 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 transmit 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 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 tracking vehicles for legitimate government purposes.

SUMMARY

Various aspects include methods enabling a vehicle, such as an autonomous vehicle, a semi-autonomous vehicle, etc., to communicate sensitive information, such as vehicle identification information, in a cellular vehicle C-V2X message in a manner that protects the sensitive information from reception by an unauthorized party while also preventing tracking of the vehicle based on intercepted information.

Various aspects include generating a digest of vehicle identification information using a predefined algorithm, encrypting the digest with a private key associated with the vehicle to produce a signature, concatenating the signature and the vehicle identification information to form first concatenated data, selecting a public key of an authorized party from a list of public keys stored in memory that includes a key identifier for each public key, 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 C-V2X message. Some aspects 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.

Some aspects may include randomly selecting the public key of the authorized party from the list of public keys. Some aspects may include repeating the operations of randomly selecting the public key of the authorized party from the list of public keys, 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 C-V2X messages.

Some aspects include receiving an updated list of public keys from a certificate authority. In some implementations of the method, it may include storing the updated list of public keys in memory.

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.

Further aspects include methods that may be performed by a computing platform, such as a concerned party server, for receiving sensitive information encrypted in C-V2X messages. Various aspects may include receiving a cellular vehicle-to-everything (C-V2X) message from a vehicle in which the C-V2X message includes encrypted data and a key identifier of a public key that was used by the vehicle in generating the encrypted data, using the key identifier to obtain a private key corresponding to the public key that was used to in generating the encrypted data, using the obtained private key to decrypt the encrypted data to produce first decrypted data including vehicle identification information and a signature, using the vehicle identification information to obtain a vehicle public key, using the vehicle public key to decrypt the signature to obtain a decrypted digest of data, generating a digest of the first decrypted data using a predefined algorithm, and determining 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. Some aspects may further include considering the first decrypted data in response to determining that the first decrypted data is authentic, and discarding the first decrypted data in response to determining that the first decrypted data is not authentic. Some aspects may further include determining 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 determining 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.

Some aspects may further include generating a plurality of pairs of a public key and a private key with each public key/private key pair associated with a key identifier, 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, and 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. Some aspects may further include receiving from the certificate authority a vehicle public key associated with vehicle identification information for each of a plurality of vehicles, and 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 the vehicle public key using the vehicle identification information.

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.

BRIEF DESCRIPTION OF THE DRAWINGS

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 intentions and/or motion plans in accordance with various embodiments.

FIG. 4A shows a component block diagram of an example system configured for including sensitive information in cellular vehicle-to-everything messages.

FIG. 4B shows a component block diagram of an example system configured for receiving sensitive information encrypted in cellular vehicle-to-everything messages.

FIGS. 5A, 5B, 5C, 5D, and/or 5E show process flow diagrams of example methods performed by a computing device of a vehicle for including sensitive information in cellular vehicle-to-everything messages according to various embodiments.

FIGS. 6A, 6B, and 6C are process flow diagrams of example methods performed by a computing platform for receiving sensitive information encrypted in cellular vehicle-to-everything messages according to various embodiments.

FIG. 7 is a component block diagram of an example network element suitable for implementing various embodiments.

DETAILED DESCRIPTION

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 a concerned 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 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 concerned 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. ) . 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 to learn the permanent vehicle identifier information when circumstances present a need to receive such information.

To address this need to transmit permanent vehicle identifier information in C-V2X messages under certain circumstances, various embodiments include operations for encrypting vehicle identifier information and other sensitive information in a manner that can only be decrypted by an authorized party (e. g., law enforcement) , thereby enabling the sensitive information to be included in C-V2X messages without risk of compromise. Various embodiment methods further include signing encrypted information so the information cannot be altered without detection by the authorized party. Further, the method of encrypting may include randomly changing the encryption key so that the encrypted data cannot be used to track a vehicle by intercepting the C-V2X messages.

In various 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 concerned party, and use a signature of the information to enable authentication of the information by the concerned party. In various embodiments, the computing device may use a predefined algorithm known to the concerned 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 concerned 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. In some embodiments, the computing device may select the public key using a random selection algorithm. 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, that is broadcast by the vehicle.

In some embodiments, the vehicle computing device may continuously broadcast BSMs with embedded encrypted information. To ensure such broadcasts cannot be tracked by unauthorized parties, the vehicle computing device may repeat the operations of randomly selecting the public key of the authorized party from the list of public keys, 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 C-V2X messages. In this way the data in the BSM will appear different each time a different public key is selected and used to encrypt the sensitive information.

At the concerned 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 concerned 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 to 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.

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, a surface transportation network 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) . Network servers 224 may be coupled to wide area network 228, such as the Internet, and be configured to route permanent vehicle information to concerned parties 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 212to 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, 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, MAP, SPaT, and RSM messages, 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. 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 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 concerned 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 concerned 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 concerned 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 a concerned 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 a concerned 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 concerned 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 concerned 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 a concerned 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 concerned 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 a concerned party and the plurality of public keys and associated key identifiers of the concerned party stored in memory of vehicle computing devices, various embodiments may be implemented. Specifically, the computing device of a vehicle 100 may encrypt vehicle identification information and other sensitive information, and embed the encrypted information in broadcast BSMs 222. The BSMs with embedded encrypted information may be received by a road side unit 220. The road side unit 220 may collect information in the received BSM 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 an internet 420. The computing platform 224 of the concerned agency may then decrypt and authenticate the embedded encrypted information according 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., Bluetooth

, 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 including sensitive information in cellular vehicle-to-everything messages in accordance with various embodiments. In some embodiments, the system 400 may include one or more vehicle computing devices 402 and/or one or more concerned 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.

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.

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.

In some implementations, vehicle computing device (s) 402, concerned party server (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, concerned party server (s) 404, and/or certificate authority 430 may be operatively linked via some other communication media.

A given concerned party computing platform 404 may include one or more processors configured to execute computer program modules. By way of non-limiting example, the given concerned 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 concerned 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 concerned party. In some embodiments, the certificate authority 430 may send the list of public keys associated with key identifiers of the concerned 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. ) , magnetically readable storage media (e. g., magnetic tape, magnetic hard drive, floppy drive, etc. ) , electrical charge-based storage media (e. g., EEPROM, RAM, etc. ) , solid-state storage media (e. g., flash drive, etc. ) , and/or other electronically readable storage media. 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 concerned party server (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. 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 receiving sensitive information encrypted in cellular vehicle-to-everything messages 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 concerned party server (s) 404 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” ) , in which such servers 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 concerned party server (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.

In some implementations, concerned party server (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 concerned party server (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 a concerned 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 a concerned party platform.

Concerned party server (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 server (s) 404 may include communication lines, or ports to enable the exchange of information with a network and/or other computing platforms. Illustration of concerned party server (s) 404 in FIG. 4B is not intended to be limiting. Concerned party server (s) 404 may include a plurality of hardware, software, and/or firmware components operating together to provide the functionality attributed herein to concerned party server (s) 404. For example, concerned party server (s) 404 may be implemented by a cloud of computing platforms operating together as concerned party server (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 concerned party server (s) 404 and/or removable storage that is removably connectable to concerned party server (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. ) , magnetically readable storage media (e. g., magnetic tape, magnetic hard drive, floppy drive, etc. ) , electrical charge-based storage media (e. g., EEPROM, RAM, etc. ) , solid-state storage media (e. g., flash drive, etc. ) , and/or other electronically readable storage media. 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 concerned party server (s) 404, information received from vehicle computing devices 402, and/or other information that enables concerned party server (s) 404 to function as described herein.

Processor (s) 454 may be configured to provide information processing capabilities in concerned party server (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 modules458, 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. 5A illustrates operations of a method 500 that may be performed by a computing device of a vehicle for encrypting sensitive information, including vehicle identification information in C-V2X messages in accordance with various embodiments. FIGS. 5B, 5C, 5D, and 5E illustrate alternative or further details of operations in the method 500 according to some embodiments. With reference to FIGs. 1A-5A, 5B, 5C, 5D, and/or 5E, 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. 5A, in block 502, 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 504, 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 506, the processor may perform operations including concatenating the signature and the vehicle identification information to form first concatenated data.

In block 508, the processor may perform operations including selecting a public key of an authorized concerned 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 510, the processor may perform operations including encrypting the first concatenated data using the selected public key to produce an encrypted output.

In block 512, 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 514, 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 that are transmitted once or repeatedly.

FIG. 5B illustrates operations of an embodiment of the method 500 in which sensitive information is also included in the encrypted data embedded in a C-V2X message.

In block 502a, 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, etc. The types of other sensitive information that may be included in the digest may depend on the authorized concerned party (e. g., law enforcement) that will be capable of decrypting the information.

In block 506a, 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 500.

FIG. 5C illustrates operations of an embodiment of the method 500 in which the public key is selected randomly form the list of public keys.

In block 508a, the processor may perform operations including randomly selecting the public key of the authorized party from the list of public keys. The processor may then proceed with the rest of the operations of the method 500.

FIG. 5D illustrates operations of an embodiment of the method 500 in which portions of the method are repeated using different randomly selected public keys to encrypt the second concatenated data before each transmission.

In block 508a, the processor may perform operations including randomly selecting the public key of the authorized party from the list of public keys.

In block 510, the processor may perform operations including encrypting the first concatenated data using the selected public key to produce an encrypted output as described.

In block 512, the processor may perform operations including concatenating the encrypted output and the key identifier of the selected public key to produce second concatenated data as described.

In block 514, the processor may perform operations including and transmitting the second concatenated data in C-V2X messages.

FIG. 5E illustrates operations of an embodiment of the method 500 in which the processor receives the list of public keys of the concerned party from a certificate authority (e. g., 430) .

In block 530, the processor may perform operations including receiving an updated list of public keys of the concerned party from a certificate authority. In an initial upload, the entire list of public keys of the concerned party may be received from the certificate authority. Thereafter, the processor may receive replacement lists or updates to the list of public keys from the certificate authority periodically or episodically. In some embodiments, the processor may receive a new list or additions to the list of public keys when the vehicle travels to a new region, such as a region including or associated with a different concerned party (e. g., a different law enforcement agency) .

In block 532, the processor may perform operations including storing the updated list of public keys in memory within or accessible to the vehicle computing device. With the list of public keys received or updated, the processor may perform the remaining operations of the method 500.

FIG. 6A illustrate operations of a method 600 performed by of a concerned party (e. g., a law enforcement agency) for processing sensitive information encrypted in cellular vehicle-to-everything messages received from a vehicle 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 computing platform, such as a server or a cloud-based service (variously referred to as a “processor” ) controlled by the concerned party. In some embodiments, the method 600 may be may be implemented in a processor of a server (e. g., a computing platform 224 of a concerned party, a concerned party server 404, etc. ) .

Referring to FIG. 6A, in block 602, a processor of the computing platform may perform operations including receiving 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., the Internet 420) through a network interface.

In block 604, 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 606, 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 608, 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 610, 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 612, 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 614, 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 614 = “Authentic” ) , the processor may consider or use the first decrypted data in an operation in block 616. 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 614 = “Not Authentic” ) , the processor may ignore or discard the first decrypted data in block 618.

The method 600 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. 6B illustrates example operations that a concerned party computing platform may perform as part of the method 600 for initiating a list of public keys that can be downloaded to wireless devices for use in the method 500 as described.

In block 624, 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 626, 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 628, 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 in block 604.

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. 6C illustrates example operations that a concerned party computing platform may perform as part of the method 600 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 630, 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 632, 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.

The computing platform of a concerned 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. 7. With reference to FIGS. 1A–7, a computing platform 700 may typically include a processor 701 coupled to volatile memory 702 and a large capacity nonvolatile memory, such as a disk drive 703. The computing platform700 also may include network access ports 704 (or interfaces) coupled to the processor 701 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 700 may include one or more antennas 708 coupled to a wireless transceiver 710 for sending and receiving C-V2X messages. The computing platform 700 also may include a peripheral memory access device such as a floppy disc drive, compact disc (CD) or digital video disc (DVD) drive 706 coupled to the processor 701. The computing platform 700 may include additional access ports, such as USB, Firewire, Thunderbolt, and the like for coupling to peripherals, external memory, or other devices.

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

A method performed by a computing device of a vehicle for including sensitive information in cellular vehicle-to-everything (C-V2X) messages, comprising:

generating a digest of vehicle identification information using a predefined algorithm;

encrypting the digest with a private key associated with the vehicle to produce a signature;

concatenating the signature and the vehicle identification information to form first concatenated data;

selecting a public key of an 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 C-V2X message.
The method of claim 1, wherein generating a digest of vehicle identification information using a predefined algorithm comprises:

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 method of claim 1, wherein selecting a public key of an authorized party from a list of public keys stored in memory comprises randomly selecting the public key of the authorized party from the list of public keys.
The method of claim 1, further comprising repeating the operations of randomly selecting the public key of the authorized party from the list of public keys, 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 C-V2X messages.
The method of claim 1, further comprising:

receiving an updated list of public keys from a certificate authority; and

storing the updated list of public keys in memory.
A computing device configured for use in a vehicle, comprising:

a memory; and

a processor coupled to the memory and to a transceiver and configured with processor-executable instructions to:

generate a digest of vehicle identification information using a predefined algorithm;

encrypt the digest with a private key associated with the vehicle to produce a signature;

concatenate the signature and the vehicle identification information to form first concatenated data;

select a public key of an authorized party from a list of public keys stored in memory, wherein each public key in the list is associated with a key identifier;

encrypt the first concatenated data using the selected public key to produce an encrypted output;

concatenate the encrypted output and the key identifier of the selected public key to produce second concatenated data; and

transmit the second concatenated data in a cellular vehicle-to-everything (C-V2X) message.
The computing device of claim 6, wherein the processor is further configured with processor-executable instructions to generate a digest of vehicle identification information using a predefined algorithm by:

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 computing device of claim 6, wherein the processor is further configured with processor-executable instructions to select the public key of an authorized party from a list of public keys stored in memory by randomly selecting the public key of the authorized party from the list of public keys.
The computing device of claim 6, wherein the processor is further configured with processor-executable instructions to repeat the operations of randomly selecting the public key of the authorized party from the list of public keys, 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 C-V2X messages.
The computing device of claim 6, wherein the processor is further configured with processor-executable instructions to:

receive an updated list of public keys from a certificate authority; and

store the updated list of public keys in memory.
A vehicle, comprising:

means for generating a digest of vehicle identification information using a predefined algorithm;

means for encrypting the digest with a private key associated with the vehicle 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 an 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 cellular vehicle-to-everything (C-V2X) message.
The vehicle of claim 11, wherein means for generating a digest of vehicle identification information using a predefined algorithm comprises:

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 vehicle of claim 11, wherein means for selecting a public key of an authorized party from a list of public keys stored in memory comprises randomly selecting the public key of the authorized party from the list of public keys.
The vehicle of claim 11, further comprising means for repeating the operations of randomly selecting the public key of the authorized party from the list of public keys, 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 C-V2X messages.
The vehicle of claim 11, further comprising:

means for receiving an updated list of public keys from a certificate authority; and

means for storing the updated list of public keys in memory.
A method performed by a computing platform for receiving sensitive information encrypted in cellular vehicle-to-everything (C-V2X) messages, comprising:

receiving a cellular vehicle-to-everything (C-V2X) message from a vehicle, 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;

using the key identifier to obtain a private key corresponding to the public key that was used to in generating the encrypted data;

using the obtained private key to decrypt the encrypted data to produce first decrypted data including vehicle identification information and a signature;

using the vehicle identification information to obtain a vehicle public key;

using the vehicle public key to decrypt the signature to obtain a decrypted digest of data;

generating a digest of the first decrypted data using a predefined algorithm; and

determining 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.
The method of claim 16, further comprising:

considering the first decrypted data in response to determining that the first decrypted data is authentic; and

discarding the first decrypted data in response to determining that the first decrypted data is not authentic.
The method of claim 16, further comprising:

determining 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

determining 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 method of claim 16, further comprising:

generating a plurality of pairs of a public key and a private key with each public key/private key pair associated with a key identifier;

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; and

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.
The method of claim 19, further comprising:

receiving from the certificate authority a vehicle public key associated with vehicle identification information for each of a plurality of vehicles; and

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 the vehicle public key using the vehicle identification information.
A computing platform, comprising:

a memory; and

a processor coupled to the memory and to a transceiver and configured with processor-executable instructions to:

receive a cellular vehicle-to-everything (C-V2X) message from a vehicle, 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;

use the key identifier to obtain a private key corresponding to the public key that was used to in generating the encrypted data;

use the obtained private key to decrypt the encrypted data to produce first decrypted data including vehicle identification information and a signature;

use the vehicle identification information to obtain a vehicle public key;

use the vehicle public key to decrypt the signature to obtain a decrypted digest of data;

generate a digest of the first decrypted data using a predefined algorithm; and

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.
The computing platform of claim 21, wherein the processor is further configured with processor-executable instructions to:

consider 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 of claim 21, wherein the processor is further configured with processor-executable instructions 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; 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 of claim 21, wherein the processor is further configured with processor-executable instructions 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;

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; 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 computing platform of claim 24, wherein the processor is further configured with processor-executable instructions to:

receive from the certificate authority a vehicle public key associated with vehicle identification information for each of a plurality of vehicles; and

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.
A computing platform, comprising:

means for receiving a cellular vehicle-to-everything (C-V2X) message from a vehicle, 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;

means for using the key identifier to obtain a private key corresponding to the public key that was used to in generating the encrypted data;

means for using the obtained private key to decrypt the encrypted data to produce first decrypted data including vehicle identification information and a signature;

means for using the vehicle identification information to obtain a vehicle public key;

means for using the vehicle public key to decrypt the signature to obtain a decrypted digest of data;

means for generating a digest of the first decrypted data using a predefined algorithm; and

means for determining 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.
The computing platform of claim 26, further comprising:

means for considering the first decrypted data in response to determining that the first decrypted data is authentic; and

means for discarding the first decrypted data in response to determining that the first decrypted data is not authentic.
The computing platform of claim 26, further comprising:

means for determining 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

means for determining 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 of claim 26, further comprising:

means for generating a plurality of pairs of a public key and a private key with each public key/private key pair associated with a key identifier;

means for 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; and

means for 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.
The computing platform of claim 29, further comprising:

means for receiving from the certificate authority a vehicle public key associated with vehicle identification information for each of a plurality of vehicles; and

means for 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 the vehicle public key using the vehicle identification information.