Managing privileged operation request improper behavior

Abstract

Various embodiments include methods and systems for managing privileged operation request improper behaviors. In various embodiments, a network computing device may receive a first privileged operation request from a vehicle at a first location at a first time and a second privileged operation request from a vehicle at a second location at a second time, and may perform a safety action in response to determining that the vehicle cannot travel from the first position to the second position between the first time and the second time.

Description

[0001] Related Applications

[0002] This application claims the benefit of priority of U.S. Non - Provisional Application No. 18 / 069,625, filed on Dec. 21, 2022; the entire content of which is incorporated herein by reference. Background Art

[0003] Vehicle - to - Everything (V2X) systems support vehicle - to - vehicle and vehicle - to - highway system communications according to communication protocols and messaging formats defined under relevant standards such as Cellular Vehicle - to - Everything (C - V2X), Dedicated Short - Range Communications (DSRC), and ITS - G5. These standards serve as the basis for vehicle - based wireless communications and can be used to support smart highways, autonomous and semi - autonomous vehicles, and improve the overall efficiency and safety of highway transportation systems.

[0004] Certain vehicles (such as emergency responder vehicles) may be given priority access to roads. For example, intelligent transportation systems may attempt to clear other traffic from the path of an emergency responder vehicle, may change traffic signals to permit the emergency responder vehicle to cross an intersection, etc. The ability to request such priority access (sometimes referred to as "privileged operations") is restricted to authorized vehicles (e.g., emergency vehicles, police cars, etc.) that are typically issued an encrypted certificate unique to each vehicle. However, malicious actors may steal or copy the private key that enables the use of such a certificate, such as by physically extracting the private key from the secure key storage device on an authorized vehicle, or by cryptographic attacks to recover the private key based on the certificates obtained from the messages sent and incorrectly request privileged access at other locations. The resulting disruption to the intelligent transportation system may impede or disrupt normal traffic and, in more severe cases, may threaten human safety. Summary of the Invention

[0005] Aspects include methods that may be performed by a network computing device for managing the use of privileged access operations to detect and respond to abuse of certificates and similar improper behavior. In some aspects, the network computing device may receive a first privileged operation request purportedly from a vehicle at a first location at a first time, and a second privileged operation request purportedly from a vehicle at a second location at a second time, and may perform a security action in response to determining that the vehicle could not have traveled from the first location to the second location between the first time and the second time.

[0006] In some aspects, determining that the vehicle could not have traveled from the first location to the second location between the first time and the second time may include: determining that the speed of the vehicle required to travel from the first location to the second location between the first time and the second time exceeds a speed threshold.

[0007] In some aspects, determining that a vehicle cannot travel from a first location to a second location between a first time and a second time can include determining that the duration from the first time to the second time is below a time threshold.

[0008] In some aspects, determining that a vehicle cannot travel from a first location to a second location between a first time and a second time can be based on the geometry of the path between the first location and the second location. In some aspects, determining that a vehicle cannot travel from a first location to a second location between a first time and a second time can be based on the road conditions between the first location and the second location. Some aspects can include determining the road conditions between the first location and the second location based on vehicle-to-everything (V2X) information received from one or more other vehicles.

[0009] Some aspects can include performing a safety action in response to determining that the second location is outside a permitted operation area. In some aspects, performing the safety action can include one or more of the following: not approving a second privileged operation request, notifying other V2X devices to ignore any privileged operation requests from the vehicle, or issuing a revocation of an encryption certificate associated with the first privileged operation request or the second privileged operation request. In some aspects, each of the first privileged operation request and the second privileged operation request includes an encrypted signature based on an encryption certificate issued to a single vehicle.

[0010] Further aspects include a computing device that includes a memory and a processor configured to perform operations of any of the methods outlined above. Further aspects can include a computing device having various units for performing functions corresponding to any of the methods outlined above. Further aspects can include a non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause a processor of the computing device to perform various operations corresponding to any of the methods outlined above. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The drawings incorporated herein and forming a part of this specification illustrate exemplary embodiments of the claims and, together with the general description given and the detailed description given, serve to explain the features herein.

[0012] Figure 1A is a system block diagram showing an example communication system suitable for implementing various embodiments.

[0013] Figure 1B is a system block diagram showing an example decomposed base station architecture suitable for implementing various embodiments.

[0014] Figure 1C is a system block diagram showing a communication system suitable for implementing various embodiments.

[0015] Figure 2 is a component diagram of an example vehicle V2X processing system suitable for implementing various embodiments.

[0016] Figure 3 is a block diagram showing example components of a system - on - a - chip (SOC) for use in a processing system according to various embodiments.

[0017] Figure 4 is a component block diagram of a network computing device suitable for use with various embodiments.

[0018] Figure 5A is a process flow diagram of an example method for managing privilege operation request misbehavior executed by a processor of a network computing device according to various embodiments.

[0019] Figure 5B is a process flow diagram of example operations that can be executed by a processor of a computing device as part of a method for managing privilege operation request misbehavior according to various embodiments. Detailed Description of the Embodiments

[0020] Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings to refer to the same or like parts. References to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.

[0021] Priority access or special access to a road through traffic signals and / or other uses of traffic system resources by authorized vehicles is referred to herein as "privilege operation". A request from a vehicle computing system to be granted a privilege operation is referred to herein as a "privilege operation request". Such a request typically includes a certificate issued to an authorized vehicle that enables an Intelligent Highway System (IHS) to: authenticate the requesting vehicle and verify that the vehicle is authorized to perform the requested privilege operation (e.g., change a traffic light to green, open a traffic barrier, etc.). As described herein, providing privilege operations to authorized vehicles can enable emergency vehicles (e.g., ambulances, fire trucks, police cars, etc.) to accelerate through traffic and thus respond more quickly to emergencies and urgent needs.

[0022] Various embodiments include methods for detecting abuse of privilege access certificates and unauthorized use of such certificates in privilege operation requests from a vehicle computing system and computing devices implementing such methods. In various embodiments, a network computing device can include one or more processors and / or other components configured to perform operations for detecting false or unauthorized requests for privilege operations (referred to herein as "privilege operation request misbehavior").

[0023] As used herein, the term "vehicle" generally refers to any one of an automobile, a motorcycle, a truck, a bus, a train, a ship, and any other type of vehicle V2X-capable system that can be configured to manage the transmission of reports of misbehavior.

[0024] The term "system-on-chip" (SOC) is used herein to refer to a single integrated circuit (IC) chip that contains multiple resources and / or processors integrated on a single substrate. A single SOC can contain circuitry for digital, analog, mixed-signal, and radio-frequency functions. A single SOC can also include any number of general-purpose processors and / or dedicated processors (such as digital signal processors, modem processors, video processors, etc.), memory blocks (such as ROM, RAM, flash memory, etc.), and resources (such as timers, voltage regulators, oscillators, etc.). The SOC can also include software for controlling the integrated resources and processors, as well as for controlling peripheral devices.

[0025] The term "system-in-package" (SIP) can be used herein to refer to a single module or package that contains multiple resources, computing units, cores, and / or processors on two or more IC chips, substrates, or SOCs. For example, an SIP can include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, an SIP can include one or more multi-chip modules on which multiple ICs or semiconductor dies are encapsulated into a unified substrate. An SIP can also include multiple independent SOCs (such as on a single motherboard or in a single wireless device) that are coupled together via high-speed communication circuitry and are packaged closely together. The close proximity of the SOCs facilitates high-speed communication as well as the sharing of memory and resources.

[0026] One potential benefit of a V2X system or an intelligent transportation / transportation system (ITS) is to enable emergency response vehicles (such as ambulances, emergency medical response vehicles, police cars, fire trucks, etc.) to request priority access to roads and / or other transportation system resources (such as traffic signals) in order to, for example, reach the scene of an accident or a hospital more quickly. Vehicles that are authorized for privileged operations and are V2X-enabled can be issued a unique cryptographic certificate, and the vehicle computing system can use this unique cryptographic certificate to sign requests for privileged operations. The cryptographic binding of the certificate to the request purportedly indicates that the request for privileged operations has originated from an authorized vehicle. Privileged operation requests that are not cryptographically bound to an authorized cryptographic certificate will generally be rejected or ignored by the V2X system or ITS. In some implementations, the certificate can be public, but the private key corresponding to the certificate that can be used to generate the cryptographic signature can be stored in secure hardware in the authorized vehicle.

[0027] However, if such secure hardware is compromised and the private key is extracted, the private key can be used to construct and send improper (i.e., unauthorized) privileged operation requests, i.e., privileged operation request misbehavior. The privileged operation request misbehavior of a single vehicle can be manageable because the disruption to the V2X system caused by such misbehavior is similar to the traffic disruption caused by a legitimate privileged vehicle. However, multiple vehicles performing privileged operation requests at different locations at approximately the same or similar times can result in cross-regional or regional traffic disruptions, which can impede or interrupt normal traffic. In more severe cases, such misbehavior can threaten human safety, for example, by causing accidents or impeding the operations of legitimate emergency responders. Additionally, an attacker with one or more abused certificates can interrupt the emergency and normal operations of a city or intelligent highway system by flooding the system with false privileged operation requests.

[0028] Various embodiments include methods for identifying and responding to privileged operation request misbehavior and network computing devices that implement such methods. In various embodiments, a network computing device can receive a first privileged operation request purportedly from a vehicle at a first location at a first time and a second privileged operation request purportedly from a vehicle at a second location at a second time. The network computing device can perform a security action in response to determining that the vehicle cannot travel from the first location to the second location between the first time and the second time. The method identifies when both the first privileged operation request and the second privileged operation request include an encrypted signature based on an encrypted certificate issued to a single vehicle (i.e., a properly authorized vehicle).

[0029] In some embodiments, a network computing device may maintain a record of each privileged operation request received by the network computing device. Such a record may include various data associated with each privileged operation request, such as time and location, cryptographic signatures and / or cryptographic certificates, and / or other relevant data of the requesting vehicle. The network computing device may monitor such records to identify when two or more records reveal that the network computing device has received two privileged operation requests signed using the same cryptographic certificate. The use of the same cryptographic certificate indicates that the two (or more) requests are purportedly issued by the same vehicle. The network computing device may be configured to compare the locations of multiple privileged operation requests and the time intervals between the multiple privileged operation requests to determine whether a single vehicle could have traveled between the location of a first privileged operation request (“first location”) and the location of a second (or later) privileged operation request (“second location”). In some embodiments, the network computing device may determine that there has been privileged operation request misconduct in response to determining that the speed of the vehicle required to travel from the first location to the second location during the interval between the first time and the second time exceeds a speed threshold (such as the maximum speed that a vehicle can achieve on a given road or possible driving route based on speed limits, road conditions, etc.). In some embodiments, the network computing device may determine that there has been privileged operation request misconduct based on determining that the duration between the first time and the second time is less than a time threshold (e.g., less than the request interval of the vehicle computing device, less than the minimum time required for the vehicle to travel from the first location to the second location given the road conditions or possible driving route, or other factors).

[0030] In some embodiments, the network computing device may be configured to obtain and use additional V2X information when determining that a vehicle cannot travel from a first location to a second location between a first time and a second time. In some embodiments, the network computing device may determine that a vehicle cannot travel from a first location to a second location between a first time and a second time based on a street map or geometry of a possible path between the first location and the second location. In some embodiments, the network computing device may determine that a vehicle cannot travel from a first location to a second location between a first time and a second time based on the road conditions between the first location and the second location (such as paving condition (if any), presence of speed obstacles, road width, etc.). In some embodiments, the network computing device may determine the road conditions between the first location and the second location based on V2X information received from one or more other vehicles.

[0031] In some embodiments, the use of an encryption certificate can be restricted to or limited by a permitted operating area. Such an operating area can include, for example, a geofence, municipal or city limits, the jurisdiction of a police vehicle, the operating range of an authenticated vehicle, or another definable geographic area. In some embodiments, the operating area can include a path (e.g., a road or another suitable driving route) for which the vehicle has requested a privileged operation, such as a driving route to a hospital or an accident scene. In some embodiments, the network computing device can perform a security action in response to determining that a second location (of a second privileged operation request) is outside the permitted operating area. Such embodiments can enable the network computing device to identify a vehicle that issues a second privileged operation request from outside the permitted operating area as a misbehaving vehicle.

[0032] The network computing device can respond more quickly to detecting improper privileged operation requests than a certificate authority or other issuer of the encryption certificate, which may be limited to revoking and / or changing the certificate and notifying the nodes in the intelligent highway system of the action. In some embodiments, the network computing device can perform a security action that includes disapproving (denying) the second privileged operation request (i.e., denying the requested privileged operation) and / or notifying other V2X systems (such as other V2X-enabled vehicles and / or V2X infrastructure devices (e.g., roadside units)) to ignore any privileged operation requests allegedly from the vehicle.

[0033] In some embodiments, the network computing device can issue a revocation of the encryption certificate associated with the first and second privileged operation requests. In such embodiments, the network computing device can issue such a revocation of the encryption certificate without first communicating with the certificate issuing authority. In some embodiments, the revocation issued by the network computing device can be temporal, e.g., for a few minutes, hours, or days.

[0034] Various embodiments improve the security and efficiency of V2X vehicles and systems by enabling the network computing device to quickly detect and take appropriate actions in response to detected improper privileged operation requests. Various embodiments improve the security and operation of systems in which such computing devices are deployed by enabling the computing device to reduce or eliminate disruptions to traffic and V2X system operation caused by vehicles or attackers using abused certificates in various types of improper privileged operation requests.

[0035] Figure 1Ais a system block diagram showing an example communication system 100 suitable for implementing various embodiments. The communication system 100 includes a 5G New Radio (NR) network, an Intelligent Transportation System (ITS) V2X wireless network, and / or any other suitable network, such as a Long-Term Evolution (LTE) network. References to 5G networks and 5G network elements in the following description are for illustrative purposes and are not intended to be limiting.

[0036] The communication system 100 may include a heterogeneous network architecture that includes a core network 140, multiple base stations 110, and various mobile devices, including a vehicle 102 equipped with a V2X processing system 104 that includes wireless communication capabilities. The base stations 110 may communicate with the core network 140 via a wired communication link 126. The communication system 100 may also include a roadside unit 112 that supports V2X communication with the vehicle 102 via a V2X wireless communication link 124.

[0037] The base stations 110 are network elements that communicate with wireless devices (e.g., the V2X processing system 104 of the vehicle 102) via a wireless communication link 122 and may be referred to as Node B, LTE evolved Node B (eNodeB or eNB), access point (AP), radio head, transmission reception point (TRP), New Radio base station (NR BS), 5G Node B (NB), next-generation Node B (gNodeB or gNB), etc. Each base station 110 may provide communication coverage for a specific geographical area or “cell”. In 3GPP, the term “cell” may refer to the coverage area of a base station, the base station subsystem serving this coverage area, or a combination thereof, depending on the context in which the term is used. The core network 140 may be any type of core network, such as an LTE core network (e.g., an evolved packet core (EPC) network), a 5G core network, a decomposed network as described Figure 1B in the reference

[0038] The roadside unit 112 may communicate with the core network 140 via a wired or wireless communication link 128. The roadside unit 112 may communicate with the vehicle 102 equipped with the V2X processing system via the V2X wireless communication link 124 to download information useful for the V2X processing system's autonomous and semi-autonomous driving functions and to receive information such as misbehavior reports from the V2X processing system 104.

[0039] A Misconduct Authorizing Network Computing Device (MA) 132 can communicate with a core network 140 via a wired or wireless communication link 127. The MA 132 can receive misconduct reports as may be occasionally sent by the V2X processing system 104 from the V2X processing system 104. In various embodiments, the MA 132 or another similar network computing device can be configured to perform operations to detect and respond to privilege operation request misconduct.

[0040] The wireless communication link 122 can include multiple carrier signals, frequencies, or frequency bands, each of which can include multiple logical channels. The wireless communication links 122 and 124 can utilize one or more radio access technologies (RATs). Examples of RATs that can be used in a wireless communication link include 3GPP LTE, 3G, 4G, 5G (such as NR), GSM, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), Time Division Multiple Access (TDMA), and other cellular RATs for mobile phone communication. Further examples of RATs that can be used in one or more of the various wireless communication links within the communication system 100 include medium-range protocols such as Wi-Fi, LTE-U, LTE-Direct (LTE-D), LAA, MuLTEfire, and relatively short-range RATs such as ZigBee, Bluetooth, and Bluetooth Low Energy (LE).

[0041] Figure 1B is a system block diagram showing an example disaggregated base station 160 architecture that can be part of a V2X and / or 5G network (e.g., communication system 100) according to any of the various embodiments. Referring to Figure 1A and 1B , the disaggregated base station 160 architecture can include one or more Central Units (CUs) 162, which can communicate directly with the core network 180 via a backhaul link, or indirectly with the core network 180 through one or more disaggregated base station units such as a Near Real-Time (Near RT) Radio Access Network Intelligent Controller (RIC) 164 via an E2 link, or a Non-Real-Time (Non RT) RIC 168 associated with a Service Management and Orchestration (SMO) framework 166, or both. The CU 162 can communicate with one or more Distributed Units (DUs) 170 via a corresponding mid-range link such as an F1 interface. The DU 170 can communicate with one or more Radio Units (RUs) 172 via a corresponding front-end link. The RU 172 can communicate with a corresponding UE 120 via one or more Radio Frequency (RF) access links. In some implementations, a user equipment (UE) such as the V2X processing system 104 can be served by multiple RUs 172 simultaneously.

[0042] Each of the units (i.e., CU 162, DU 170, RU 172) and the near RT RIC 164, non-RT RIC 168, and SMO framework 166 may include one or more interfaces, or be coupled to one or more interfaces, which are configured to receive or transmit signals, data, or information (collectively referred to as signals) via a wired or wireless transmission medium. Each of the units, or an associated processor or controller that provides instructions to the communication interfaces of the units, may be configured to communicate with one or more of the other units via the transmission medium. For example, the units may include a wired interface that is configured to receive or transmit signals via a wired transmission medium to one or more of the other units. Additionally, the units may include a wireless interface, which may include a receiver, transmitter, or transceiver (such as a radio frequency (RF) transceiver), that is configured to receive or transmit signals, or receive and transmit signals, to one or more of the other units via a wireless transmission medium.

[0043] In some aspects, the CU 162 may host one or more higher layer control functions. Such control functions may include radio resource control (RRC), packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), etc. Each control function may be implemented using an interface configured to convey signals with other control functions hosted by the CU 162. The CU 162 may be configured to handle user plane functions (i.e., Central Unit - User Plane (CU-UP)), control plane functions (i.e., Central Unit - Control Plane (CU-CP)), or a combination thereof. In some implementations, the CU 162 may be logically divided into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP units may communicate bidirectionally with the CU-CP units via an interface such as the E1 interface. The CU 162 may be implemented to communicate with the DU 170 as needed for network control and signaling.

[0044] The DU 170 may correspond to a logical unit that includes one or more base station functions to control the operation of one or more RUs 172. In some aspects, the DU 170 may host one or more of the radio link control (RLC) layer, the medium access control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation, and demodulation, etc.) at least partially depending on the functional split (such as those defined by the 3rd Generation Partnership Project (3GPP)). In some aspects, the DU 170 may also host one or more low PHY layers. Each layer (or module) may be implemented with an interface configured to communicate signals with other layers (and modules) hosted by the DU 170 or with the control functions hosted by the CU 162.

[0045] The low-layer functions may be implemented by one or more RUs 172. In some deployments, the RUs 172 controlled by the DU 170 may correspond to logical nodes that host RF processing functions or low PHY layer functions (such as performing fast Fourier transform (FFT), inverse FFT (iFFT), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc.) or both at least partially based on a functional split (such as a low-layer functional split). In such an architecture, the RUs 172 may be implemented to handle over-the-air (OTA) communications with one or more UEs 120. In some implementations, the real-time and non-real-time aspects of the control and user plane communications with the RUs 172 may be controlled by the corresponding DU 170. In some scenarios, this configuration may enable the DU 170 and the CU 162 to be implemented in a cloud-based radio access network (RAN) architecture (such as a vRAN architecture).

[0046] The SMO framework 166 can be configured to support the RAN deployment and provisioning of both non-virtualized network elements and virtualized network elements. For non-virtualized network elements, the SMO framework 166 can be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which can be managed via an operation and maintenance interface (such as the O1 interface). For virtualized network elements, the SMO framework 166 can be configured to interact with a cloud computing platform (such as the Open Cloud (O-Cloud) 176) to perform network element lifecycle management (such as to instantiate virtualized network elements) via a cloud computing platform interface (such as the O2 interface). Such virtualized network elements can include, but are not limited to, the CU 162, DU 170, RU 172, and the Near RT RIC 164. In some implementations, the SMO framework 166 can communicate with the hardware aspect of the 4G RAN (e.g., the Open eNB (O-eNB) 174) via the O1 interface. Additionally, in some implementations, the SMO framework 166 can communicate directly with one or more RUs 172 via the O1 interface. The SMO framework 166 can also include a Non-RT RIC 168 configured to support the functions of the SMO framework 166.

[0047] The Non-RT RIC 168 can be configured to include logic functions that implement non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updating, or policy-based guidance of applications / features in the Near RT RIC 164. The Non-RT RIC 168 can be coupled to or communicate with the Near RT RIC 164 (such as via the A1 interface). The Near RT RIC 164 can be configured to include logic functions that implement near-real-time control and optimization of RAN elements and resources via data collection and actions on an interface connecting one or more CUs 162, one or more DUs 170, or both, and the O-eNB to the Near RT RIC 164 (such as via the E2 interface).

[0048] In some implementations, to generate an AI / ML model to be deployed in the near-RT RIC 164, the non-RT RIC 168 can receive parameters or external enrichment information from an external server. Such information can be utilized by the near-RT RIC 164 and can be received from non-network data sources or from network functions at the SMO framework 166 or the non-RT RIC 168. In some examples, the non-RT RIC 168 or the near-RT RIC 164 can be configured to tune RAN behavior or performance. For example, the non-RT RIC 168 can monitor long-term trends and patterns of performance and adopt an AI / ML model via the SMO framework 166 (such as via reconfiguration of O1) or via creating a RAN management policy (such as an A1 policy) to perform corrective actions.

[0049] Figure 1C is a system block diagram showing a communication system 103 suitable for implementing various embodiments. Referring Figure 1A - Figure 1C , the communication system 103 can include three vehicles 12, 14, 16. Each vehicle 12, 14, 16 can respectively include a V2X processing system 104, 106, 108, each V2X processing system being configured to periodically broadcast V2X messages 30, 40, 50, such as BSM, CAM, MCM, MAP, SRM, and other types of V2X messages, for reception and processing by V2X processing systems of other vehicles (e.g., 104, 106, 108).

[0050] By sharing vehicle position, speed, direction, braking, and other information, vehicles can maintain a safe separation and identify and avoid potential collisions. For example, a rear vehicle 12 that receives the V2X message 40 from a front vehicle 16 can determine the speed and position of the vehicle 16, which in turn enables the vehicle 12 to match speeds and maintain a safe separation distance 20.

[0051] By being notified via the V2X message 40 when the front vehicle 16 applies the brakes, even when the front vehicle 16 suddenly stops, the V2X processing system 102 in the rear vehicle 12 can also apply the brakes simultaneously to maintain the safe separation distance 20. As another example, the V2X processing system 104 in the truck vehicle 14 can receive the V2X messages 30, 50 from two vehicles 12, 16 and is thus notified that the truck vehicle 14 should stop at the intersection to avoid a collision.

[0052] Each of the vehicle V2X on-vehicle devices 104, 106, 108 can communicate with each other using any one of various short-range communication protocols. Additionally, the vehicle may be able to send data and information regarding detected V2X messages and misbehavior reports regarding detected V2X misbehavior to the original equipment manufacturers (70, 72) and / or the MA 74 (e.g., 132) via communication networks 18 through communication links 60, 61, 62. The misbehavior report can be sent directly to the MA 74 (e.g., via communication links 64, 66).

[0053] In some embodiments, the misbehavior report can be first sent to a misbehavior report preprocessing unit such as the OEM servers 70, 72, etc. for preprocessing via communication links 64, 66. Then, the preprocessed misbehavior report can be sent from the misbehavior report preprocessing servers 70, 72 to the MA 74 via communication links 64, 66.

[0054] In some embodiments, the misbehavior report can be received at the MA 74 from a vehicle (such as from vehicle 16). The MA 74 can relay the misbehavior report received from vehicle 16 to the OEM servers 70, 72 via communication links 64, 66. Additionally, the OEM servers 70, 72 can provide an acknowledgement report to the MA 74 via communication links 64, 66.

[0055] Figure 2 is a component diagram of an exemplary vehicle V2X processing system 200 suitable for implementing various embodiments. Referring Figure 1A - Figure 2 , the processing system 200 can include a vehicle 102, and the vehicle 102 includes a V2X processing system 104. The vehicle V2X processing system 104 can communicate with various systems and devices, such as in-vehicle network 210, infotainment system 212, various sensors 214, various actuators 216, and a radio module 218 coupled to an antenna 219. The vehicle V2X processing system 104 can also communicate with a roadside unit 112, a cellular communication network base station 110, and other external devices.

[0056] The V2X processing system 104 can include a processor 205, a memory 206, an input module 207, an output module 208, and a radio module 218. The processor 205 can be coupled to the memory 206 (i.e., a non-transitory storage medium), and can be configured with processor-executable instructions stored in the memory 206 to perform operations of methods according to various embodiments described herein. Additionally, the processor 205 can be coupled to the output module 208 (which can control an in-vehicle display), and coupled to the input module 207 to receive information from vehicle sensors as well as driver input.

[0057] The V2X processing system 104 may include a V2X antenna 219 coupled to a radio module 218 configured to communicate with one or more ITS participants (e.g., stations), a roadside unit 112, and a base station 110 or another suitable network access point. The V2X antenna 219 and the radio module 218 may be configured to receive dynamic traffic flow characteristic information via vehicle-to-everything (V2X) communication. In various embodiments, the V2X processing system may receive information from multiple information sources such as an in-vehicle network 210, an infotainment system 212, various sensors 214, various actuators 216, and the radio module 218. The V2X processing system may be configured to perform autonomous or semi-autonomous driving functions using map data in addition to sensor data, as described further below.

[0058] Examples of the in-vehicle network 210 include a controller area network (CAN), a local interconnect network (LIN), a network using the FlexRay protocol, a media-oriented system transport (MOST) network, and automotive Ethernet. Examples of vehicle sensors 214 include position determination systems such as a global navigation satellite system (GNSS) system, cameras, radar, lidar, ultrasonic sensors, infrared sensors, and other suitable sensor devices and systems. Examples of vehicle actuators 216 include various physical control systems such as those for steering, braking, engine operation, lights, turn signals, and the like.

[0059] Figure 3 is a block diagram showing example components of a system-on-chip (SOC) 300 for use in a processing system (e.g., a V2X processing system) according to various embodiments. Referring Figure 1A - Figure 3 , the processing device SOC 300 may include multiple 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 application 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 coprocessors) connected to one or more of the heterogeneous processors 303, 304, 306, 307, 308, 317.

[0060] Each processor may include one or more cores and an independent / internal clock. Each processor / core may perform operations independently of 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 application processor 308 may be the main processor, central processing unit (CPU), microprocessor unit (MPU), arithmetic logic unit (ALU), etc. of the SOC 300. The graphics processor 306 may be a graphics processing unit (GPU).

[0061] The processing device SOC 300 may include analog circuits and custom circuits 314 for managing sensor data, analog-to-digital conversion, wireless data transmission, and for performing other specialized operations, such as processing encoded audio and video signals for presentation on a web browser. The processing device SOC 300 may also 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 for supporting processors and software clients (e.g., web browsers) running on the computing device.

[0062] The processing device SOC 300 also includes dedicated circuits for camera actuation and management (CAM) 305, which include, provide, control, and / or manage the operations of one or more cameras (e.g., main camera, network camera, 3D camera, etc.), video display data from camera firmware, image processing, video preprocessing, video front end (VFE), in-line JPEG, high-definition video codecs, etc. The CAM 305 may be an independent processing unit and / or include an independent or internal clock.

[0063] In some embodiments, the image and object recognition processor 306 may be configured with processor-executable instructions and / or dedicated hardware configured to perform image processing and object recognition analysis involved in various embodiments. For example, the image and object recognition processor 306 may be configured to perform operations of processing images received from a camera via the CAM 305 to recognize and / or identify other vehicles. In some embodiments, the processor 306 may be configured to process radar or lidar data.

[0064] System components and resources 316, analog and custom circuitry 314, and / or CAM 305 may include circuitry for interacting with peripheral devices such as cameras, radars, lidars, electronic displays, wireless communication devices, external storage chips, etc. 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 interconnect / bus module 324, which may include an array of reconfigurable logic gates and / or implement a bus architecture such as CoreConnect, AMBA, etc. Communication may be provided via an improved interconnect such as a high-performance on-chip network (NoC).

[0065] The processing device SOC 300 may also include an input / output module (not shown) for communicating with resources external to the SOC such as a clock 318 and a voltage regulator 320. Resources external to the SOC such as the clock 318, voltage regulator 320 may be shared by two or more of the internal SOC processors / cores such as the DSP 303, modem processor 304, graphics processor 306, application processor 308, etc.

[0066] In some embodiments, the processing device SOC 300 may be included in a control unit (e.g., 140) for a vehicle (e.g., 100). The control unit may include a communication link for communicating with a telephone network (e.g., 180), the Internet, and / or a network server (e.g., 184) as described above.

[0067] The processing device SOC 300 may also include additional hardware and / or software components suitable for collecting sensor data from sensors, including motion sensors such as accelerometers and gyroscopes of an IMU, user interface elements such as input buttons, touchscreen displays, etc., microphone arrays, sensors for monitoring physical conditions such as position, orientation, motion, orientation, vibration, pressure, etc., cameras, compasses, GPS receivers, communication circuitry such as WLAN, Wi-Fi, etc., and other well-known components of modern electronic devices.

[0068] Figure 4 is a block diagram of components of a network computing device 400 suitable for use with various embodiments. Referring Figure 1A - Figure 4 to, various embodiments may be implemented on various network computing devices, examples of which are in Figure 4is shown in the form of a server device. The network computing device 400 may include a processor 401 coupled to a volatile memory 402 and a mass non-volatile memory such as a disk drive 403. The network computing device 400 may also include a peripheral memory access device, such as a floppy disk drive, a compact disc (CD) or a digital video disc (DVD) drive 406 coupled to the processor 401. The network computing device 400 may also include a network access port 404 (or interface) coupled to the processor 401 for establishing a data connection with a network such as the Internet and / or a local area network coupled to other system computers and servers. The network computing device 400 may include one or more transceivers 405 for transmitting and receiving electromagnetic radiation, and the transceivers 405 may be connected to a wireless communication link. The network computing device 400 may include additional access ports, such as USB, Firewire, Thunderbolt, etc., for coupling to peripheral devices, external memories or other devices. The processor 401 may include any or all elements or components of the processing device SOC 300.

[0069] Figure 5A is a process flow diagram of an example method 500a for managing improper behavior of privilege operation requests executed by a processor of a network computing device according to various embodiments. Referring to Figure 1A - Figure 5A , the method 500a may be executed by one or more processors (e.g., 300) of a network computing device (e.g., 70, 72, 74, 112, 110, 132, 400) that may be implemented in hardware elements, software elements or a combination of hardware and software elements. In order to cover any one of the processors, hardware elements and software elements that may be involved when executing the method 500a, the element or subsystem that executes the method operation is generally referred to as a "processor".

[0070] In block 502, the processor may receive a first privilege operation request allegedly from a vehicle at a first location at a first time and a second privilege operation request allegedly from a vehicle at a second location at a second time. In some embodiments, each of the first privilege operation request and the second privilege operation request may include an encrypted signature based on an encrypted certificate issued to a single vehicle. In some embodiments, the processor may store each privilege operation request in a memory.

[0071] In block 504, the processor may perform a safety action in response to determining that the vehicle cannot travel from a first location to a second location between a first time and a second time. In some embodiments, the processor may determine that a speed of the vehicle required to travel from the first location to the second location between the first time and the second time exceeds a speed threshold. In some embodiments, the processor may determine that a duration from the first time to the second time is below a time threshold. In some embodiments, as part of determining whether the vehicle may have traveled from the first location to the second location between the first time and the second time, the processor may compare a newly received request to a stored record of a previously received request in block 504.

[0072] The operations in method 500a may be performed each time a privileged operation request is received.

[0073] Figure 5B is a process flow diagram of example operation 500b that may be performed by a processor of a computing device as part of method 500a for managing misbehavior of privileged operation requests. Referring Figure 1A - Figure 5B , operation 500b may be performed by one or more processors (e.g., 300) of a network computing device (e.g., 70, 72, 74, 112, 110, 132, 400) that may be implemented in a hardware element, a software element, or a combination of hardware and software elements. To cover any one of the processors, hardware elements, and software elements that may be involved in performing method 500b, the element or subsystem that performs the method operations is generally referred to as a "processor".

[0074] As described, after receiving a first privileged operation request and a second privileged operation request in block 502, the processor may determine a geometry of a path between a first location and a second location in block 510. In some embodiments, the geometry of the path may include a path length, a path shape, one or more turns along the path, one or more elevation changes along the path, a path complexity, and / or other suitable factors.

[0075] Additionally or alternatively, after receiving a first privileged operation request and a second privileged operation request in block 502 as described, the processor may determine a road condition between the first location and the second location in block 512. In some embodiments, the processor may determine the road condition based on V2X information received from one or more other vehicles (such as V2X-enabled vehicles).

[0076] As described, after determining the geometry of the path between the first position and the second position in block 510 and / or the road conditions between the first position and the second position in block 512, the processor may determine in decision block 514 whether the speed of the vehicle required to travel from the first position to the second position between a first time and a second time exceeds a speed threshold.

[0077] In response to determining that the speed of the vehicle required to travel from the first position to the second position between the first time and the second time exceeds the speed threshold (i.e., decision block 514 = "yes"), in block 526, the processor may determine that the vehicle cannot travel from the first position to the second position between the first time and the second time.

[0078] In response to determining that the speed of the vehicle required to travel from the first position to the second position between the first time and the second time does not exceed the speed threshold (i.e., decision block 514 = "no"), the processor may determine in block 522 that the vehicle may have traveled from the first position to the second position between the first time and the second time. In other words, the processor may determine that the speed required to travel between the first position and the second position during the interval between the first time and the second time is within that which an authorized vehicle may maintain (e.g., a vehicle using a siren and having the right of way). In such a case, in block 524, the processor may grant the requested privileged operation for the vehicle.

[0079] Alternatively, in response to determining that the speed of the vehicle required to travel from the first position to the second position between the first time and the second time does not exceed the speed threshold (i.e., decision block 514 = "no"), the processor may determine in decision block 516 whether the duration from the first time to the second time is below a time threshold.

[0080] In response to determining that the duration from the first time to the second time is below the time threshold (i.e., decision block 516 = "yes"), in block 522, the processor may determine that the vehicle may have traveled from the first position to the second position between the first time and the second time.

[0081] In response to determining that the duration from the first time to the second time is not below the time threshold (i.e., decision block 516 = "no"), in block 522, the processor may determine that the vehicle may have traveled from the first position to the second position between the first time and the second time. In other words, the interval between the first time and the second time is long enough to permit an authorized vehicle (e.g., a vehicle using a siren and having the right of way) to reach the second position. In such a case, in block 524, the processor may grant the requested privileged operation for the vehicle.

[0082] Alternatively, in response to determining that the duration from the first time to the second time is not less than the time threshold (i.e., determining that block 516 = "No"), the processor may determine in decision block 518 whether the second request is from a location outside the permitted operating area.

[0083] In response to determining that the second request is from a location outside the permitted operating area (i.e., determining that block 518 = "Yes"), the processor may perform a security action in block 520.

[0084] In response to determining that the second request is from a location within the permitted operating area (i.e., determining that block 518 = "No"), the processor may permit a privileged operation for the vehicle in block 524.

[0085] After performing the operation of block 526, the processor may perform a security operation in block 504, as described.

[0086] The operations in method 500b may be performed each time a privileged operation request is received.

[0087] The various embodiments shown and described are provided only as examples to illustrate the various features of the claims. However, the 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 shown and described. Additionally, the claims are not intended to be limited by any one example embodiment. For example, one or more operations in methods and operations 500a and 500b may replace or combine one or more operations in methods or operations 500a and 500b.

[0088] Example implementations are described in the following paragraphs. While some of the example implementations in the following paragraphs are described from the perspective of example methods, further example implementations may include: example methods implemented by a computing device including a processor configured with processor-executable instructions to perform the operations of the methods of the following example implementations; example methods implemented by a computing device including units for performing the functions of the methods of the following example implementations; and the example methods discussed in the following paragraphs may be implemented as a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a computing device to perform the operations of the methods of the following example implementations.

[0089] Example 1. A method for managing improper behavior of privilege operation requests, including: receiving, by a network computing device, a first privilege operation request allegedly from a vehicle at a first location at a first time and a second privilege operation request allegedly from the vehicle at a second location at a second time; and performing a security action in response to determining that the vehicle cannot travel from the first location to the second location between the first time and the second time.

[0090] Example 2. The method according to Example 1, wherein determining that the vehicle cannot travel from the first location to the second location between the first time and the second time includes: determining that the speed required for the vehicle to travel from the first location to the second location between the first time and the second time exceeds a speed threshold.

[0091] Example 3. The method according to any one of Examples 1 or 2, wherein determining that the vehicle cannot travel from the first location to the second location between the first time and the second time includes: determining that the duration from the first time to the second time is below a time threshold.

[0092] Example 4. The method according to any one of Examples 1 - 3, wherein determining that the vehicle cannot travel from the first location to the second location between the first time and the second time is based on the geometry of the path between the first location and the second location.

[0093] Example 5. The method according to any one of Examples 1 - 4, wherein determining that the vehicle cannot travel from the first location to the second location between the first time and the second time is based on the road conditions between the first location and the second location.

[0094] Example 6. The method according to Example 5, further including: determining the road conditions between the first location and the second location based on vehicle - to - everything (V2X) information received from one or more other vehicles.

[0095] Example 7. The method according to any one of Examples 1 - 6, further including: performing a security action in response to determining that the second location is outside a permitted operation area.

[0096] Example 8. The method according to any one of Examples 1 - 7, wherein performing the security action includes one or more of the following: not approving the second privilege operation request, notifying other V2X devices to ignore any privilege operation requests from the vehicle, or issuing a revocation of the encryption certificate associated with the first privilege operation request or the second privilege operation request.

[0097] Example 9. The method according to any one of Examples 1 - 8, wherein each of the first privilege operation request and the second privilege operation request includes an encryption signature based on an encryption certificate issued to a single vehicle.

[0098] The above method descriptions and process flowcharts are provided only as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order shown. As will be appreciated by those skilled in the art, the order of operations 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 operations; these words are only used to guide the reader through the description of the method. In addition, any reference to a singular claim element using, for example, the articles "a," "an," or "the" should not be construed as limiting the element to the singular.

[0099] The various illustrative logical blocks, modules, circuits, and algorithmic operations described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, the foregoing has been described generally in terms of the functionality of the various illustrative components, blocks, modules, circuits, and operations. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Those skilled in the art can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0100] Hardware for implementing or performing the various illustrative logical units, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein can be implemented using 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. The general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some methods or operations may be performed by circuitry specific to a given function.

[0101] In one or more embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or code on a non-transitory computer-readable medium or a non-transitory processor-readable medium. 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. A non-transitory computer-readable or processor-readable storage medium may be any storage medium that can be accessed by a computer or a processor. By way of example and 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, disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. As used herein, disk and optical disk include: compact disk (CD), laser disk, optical disk, digital versatile disk (DVD), floppy disk, and Blu-ray disk, where disks typically reproduce data magnetically, while optical disks 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, operations of a method or algorithm may reside as one or any combination or collection of code and / or instructions on a non-transitory processor-readable medium and / or a computer-readable medium, which may be incorporated into a computer program product.

[0102] The foregoing description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the claims and the principles and novel features disclosed herein.

Claims

1. A method for managing improper behavior of privileged operation requests, comprising: Receiving, by a network computing device, a first privileged operation request allegedly from a vehicle at a first location at a first time and a second privileged operation request allegedly from the vehicle at a second location at a second time; And Performing a security action in response to determining that the vehicle cannot travel from the first location to the second location between the first time and the second time.

2. The method according to claim 1, wherein, Determining that the vehicle cannot travel from the first location to the second location between the first time and the second time includes: determining that a speed of the vehicle required to travel from the first location to the second location between the first time and the second time exceeds a speed threshold.

3. The method according to claim 1, wherein, Determining that the vehicle cannot travel from the first location to the second location between the first time and the second time includes: determining that a duration from the first time to the second time is below a time threshold.

4. The method according to claim 1, wherein, Determining that the vehicle cannot travel from the first location to the second location between the first time and the second time is based on a geometry of a path between the first location and the second location.

5. The method according to claim 1, wherein, Determining that the vehicle cannot travel from the first location to the second location between the first time and the second time is based on a road condition between the first location and the second location.

6. The method according to claim 5 further comprises: Determining the road condition between the first location and the second location based on vehicle-to-everything (V2X) information received from one or more other vehicles.

7. The method according to claim 1, further comprising: Performing the security action in response to determining that the second location is outside a permitted operation area.

8. The method according to claim 1, wherein, Performing the security action includes one or more of the following: not approving the second privileged operation request, notifying other V2X devices to ignore any privileged operation requests from the vehicle, or issuing a revocation of an encryption certificate associated with the first privileged operation request or the second privileged operation request.

9. The method according to claim 1, wherein, Each of the first privileged operation request and the second privileged operation request includes an encryption signature based on an encryption certificate issued to a single vehicle.

10. A network computing device, comprising: A processor configured with processor-executable instructions to perform the following operations: Receiving a first privileged operation request allegedly from a vehicle at a first location at a first time and a second privileged operation request allegedly from the vehicle at a second location at a second time; And Performing a security action in response to determining that the vehicle cannot travel from the first location to the second location between the first time and the second time.

11. The network computing device according to claim 10, wherein, The processor is further configured with processor-executable instructions to perform the following operation: determining that a speed of the vehicle required to travel from the first location to the second location between the first time and the second time exceeds a speed threshold.

12. The network computing device according to claim 10, wherein, The processor is further configured with processor-executable instructions to perform the following operation: determining that a duration from the first time to the second time is below a time threshold.

13. The network computing device according to claim 10, wherein, The processor is further configured with processor-executable instructions to perform the following operations: determine that the vehicle cannot travel from the first position to the second position between the first time and the second time based on the geometry of the path between the first position and the second position.

14. The network computing device according to claim 10, wherein, The processor is further configured with processor-executable instructions to perform the following operations: determine that the vehicle cannot travel from the first position to the second position between the first time and the second time based on the road conditions between the first position and the second position.

15. The network computing device according to claim 14, wherein, The processor is further configured with processor-executable instructions to perform the following operations: determine the road conditions between the first position and the second position based on vehicle-to-everything (V2X) information received from one or more other vehicles.

16. The network computing device according to claim 10, wherein, The processor is further configured with processor-executable instructions to perform the following operations: execute the safety action in response to determining that the second position is outside the permitted operation area.

17. The network computing device according to claim 10, wherein, The processor is further configured with processor-executable instructions to perform one or more of the following operations: Deny the second privileged operation request; Notify other V2X devices to ignore any privileged operation requests from the vehicle; or Issue a revocation of the cryptographic certificate associated with the first privileged operation request or the second privileged operation request.

18. The network computing device according to claim 10, wherein, The processor is further configured with processor-executable instructions such that each of the first privileged operation request and the second privileged operation request includes a cryptographic signature based on a cryptographic certificate issued to a single vehicle.

19. A network computing device, comprising: A unit for receiving a first privileged operation request allegedly from a vehicle at a first position at a first time and a second privileged operation request allegedly from the vehicle at a second position at a second time; And A unit for executing a safety action in response to determining that the vehicle cannot travel from the first position to the second position between the first time and the second time.

20. The network computing device according to claim 19, wherein The unit for determining that the vehicle cannot travel from the first position to the second position between the first time and the second time includes: a unit for determining that the speed of the vehicle required to travel from the first position to the second position between the first time and the second time exceeds a speed threshold.

21. The network computing device according to claim 19, wherein, The unit for determining that the vehicle cannot travel from the first position to the second position between the first time and the second time includes: a unit for determining that the duration from the first time to the second time is less than a time threshold.

22. The network computing device according to claim 19, wherein, The unit for determining that the vehicle cannot travel from the first position to the second position between the first time and the second time includes: a unit for using the geometry of the path between the first position and the second position to determine that the vehicle cannot travel along the path between the first time and the second time.

23. The network computing device according to claim 19, wherein, The unit for determining that the vehicle cannot travel from the first position to the second position between the first time and the second time includes: a unit for using the road conditions between the first position and the second position to determine that the vehicle cannot travel between the first time and the second time.

24. The network computing device according to claim 23, further comprising: A unit for determining the road conditions between the first position and the second position based on vehicle-to-everything (V2X) information received from one or more other vehicles.

25. The network computing device according to claim 19, further comprising: A unit for performing the safety action in response to determining that the second position is outside the permitted operation area.

26. The network computing device according to claim 19, wherein, The unit for performing the safety action includes one or more of the following: A unit for not approving the second privileged operation request; A unit for notifying other V2X devices to ignore any privileged operation requests from the vehicle; Or A unit for issuing a revocation of the cryptographic certificate associated with the first privileged operation request or the second privileged operation request.

27. The network computing device according to claim 19, wherein, Each of the first privileged operation request and the second privileged operation request includes a cryptographic signature based on a cryptographic certificate issued to a single vehicle.

28. A non-transitory processor-readable medium storing processor-executable instructions, the processor-executable instructions being configured to cause a processing device in a network computing device to perform operations, the operations including: Receiving a first privileged operation request allegedly from a vehicle at a first position at a first time and a second privileged operation request allegedly from the vehicle at a second position at a second time; And Performing a safety action in response to determining that the vehicle cannot travel from the first position to the second position between the first time and the second time.

Images