System and method for detecting a traffic pole attack for a vehicle

Abstract

Examples of traffic pole verification systems are provided. In one example, a traffic detection system in a vehicle includes a navigation sensor, a communication system, a processor, and a storage device storing instructions executable by the processor to determine current location information of the vehicle, obtain reference traffic pole information based on the current location information, receive one or more of cryptopole data and associated cryptosign data from a transmitter associated with an expected reference traffic pole via the communication system, the expected reference traffic pole including an associated traffic sign mounted thereon, and selectively control one or more vehicle systems of the vehicle based on cryptov erification of the expected reference pole using the obtained reference traffic pole information; wherein the cryptoverification of the expected reference pole is performed after successful signature verification of one or more of the cryptopole data and the associated cryptosign data.

Description

Technical Field

[0001] This disclosure relates to traffic pole verification in vehicles, including the use of computer vision systems and cryptographic data transmission. Background Technology

[0002] Intelligent Transportation Systems (ITS) are an integral part of the evolving smart city landscape, enabling decision-making in traffic planning and management. Vehicles, traffic lights, drivers, sensors, roadside units, and other public infrastructure form a complex, interconnected system. ITS-based applications can include optimized traffic signal control, safe intersections, and emergency warning notifications, aiming to enhance travel efficiency, public safety, emergency response, and even disaster recovery. As a component of ITS, intelligent traffic lights, signals, and / or signs are increasingly used for traffic management. Some vehicles, such as autonomous or semi-autonomous vehicles, can utilize imaging systems to detect traffic lights, signals, and / or signs and adjust vehicle operations accordingly. Traffic infrastructure is typically complex and often includes multiple traffic poles to regulate vehicle movement from multiple directions using single or multiple signs. Summary of the Invention

[0003] This disclosure provides mechanisms for performing real-time detection and identification of traffic poles, traffic lights, signals, and / or signs, wherein the detected data is robustly authenticated and verified to address data security concerns. For example, a cryptographically associated signal verification mechanism can be employed to distinguish between legitimate traffic signs and counterfeit sign signals (such as those displayed by intruding into existing traffic signal control systems). However, the inventors recognize that a challenge with cryptographically associated signal verification mechanisms is the lack of clarity in understanding which traffic pole is appropriate when multiple traffic signs are present from multiple poles (e.g., due to the physical rotation of the traffic pole) or when a traffic pole is physically removed, resulting in no traffic signs at the intersection. In some examples, aspects of this disclosure provide cryptographically based traffic pole attack detection systems that complement cryptographically based traffic sign verification systems. In some disclosed systems, data indicating traffic poles and data indicating traffic signs are securely (e.g., encrypted and / or digitally signed) and transmitted to the vehicle. The vehicle verifies the secure data of the traffic poles based on traffic pole location information obtained using the vehicle's navigation system to check whether the traffic pole transmitting the secure data is appropriate for the lane in which the vehicle is traveling. In addition, vehicles use identified signs from a computer vision system to verify the safety data of associated traffic signs, so as to use cryptographic authentication to check the credibility of computer vision-based identified signs.

[0004] In one example of a traffic pole detection system in a vehicle, the system includes a navigation sensor; a communication system; a processor; and a storage device that stores instructions in a non-transitory memory, the instructions being executable by the processor to: determine the current location information of the vehicle, the current location information including lane information of the driving lane in which the vehicle is currently traveling; obtain reference traffic pole information for the driving lane based on the vehicle's current location information; receive cipher pole data via the communication system from a transmitter associated with a anticipated reference traffic pole, the anticipated reference traffic pole including associated traffic signs mounted thereon, the cipher pole data including a cipher representation of the anticipated reference traffic pole; and selectively control one or more vehicle systems of the vehicle based on cipher verification of the anticipated reference pole using the obtained reference traffic pole information.

[0005] In an example of a method for verifying a traffic pole using a vehicle, the method includes determining the vehicle's current location information; capturing an image of the vehicle's environment via an image sensor; obtaining reference traffic pole information based on the vehicle's current location information; wirelessly receiving coded information via the vehicle's communication system from a transmitter associated with a traffic pole on which traffic signs are mounted, the coded information including a pole coded representation of the traffic pole and a sign coded representation of the traffic signs; and selectively controlling one or more vehicle systems of the vehicle based on a first coded verification of the traffic pole using the pole coded representation and the reference traffic pole information.

[0006] Examples of methods for identifying a reference traffic pole among two or more traffic poles in a vehicle environment include: obtaining reference traffic pole location information based on the vehicle's location information and the vehicle's driving lane information from the vehicle's navigation system; obtaining a private key for the reference traffic pole based on the reference traffic pole location information; receiving corresponding cryptographic pole data from each of the two or more traffic poles via the vehicle's wireless communication system; decrypting each of the corresponding cryptographic pole data using the private key; identifying the reference pole of the vehicle based on successful decryption of the cryptographic pole data from one of the two or more traffic poles; and selectively controlling one or more vehicle systems of the vehicle based on the identified reference pole. For example, digital cryptographic signature verification of the received cryptographic pole data is completed before decryption. After successful signature verification, decryption is performed. Attached Figure Description

[0007] This disclosure can be better understood by referring to the following description of non-limiting embodiments, in which:

[0008] Figure 1An exemplary environment in which traffic pole and sign detection and verification can be performed according to one or more embodiments of this disclosure is schematically shown;

[0009] Figure 2 An exemplary traffic pole and sign verification transceiver system according to one or more embodiments of the present disclosure is shown;

[0010] Figure 3 A flowchart is shown illustrating exemplary methods for identifying traffic poles using navigation systems and cryptographic data, and for identifying traffic signs using computer vision and cryptographic data, according to one or more embodiments of this disclosure;

[0011] Figure 4A A flowchart illustrating an exemplary method for protecting traffic sign data for transmission by a transmitter system according to one or more embodiments of the present disclosure is shown.

[0012] Figure 4B A flowchart illustrating an exemplary method for transmitting traffic pole data to a transmitter system according to one or more embodiments of the present disclosure is shown.

[0013] Figure 5A A flowchart is shown of an exemplary method for identifying traffic signs at a receiver system according to one or more embodiments of the present disclosure;

[0014] Figure 5B A flowchart is shown of an exemplary method for identifying a rotated traffic pole at a receiver system according to one or more embodiments of the present disclosure;

[0015] Figures 6A to 6C An exemplary traffic intersection scenario according to one or more embodiments of the present disclosure is illustrated schematically, showing exemplary identification of traffic poles;

[0016] Figure 7 An exemplary partial view of a vehicle compartment according to one or more embodiments of the present disclosure is shown; and

[0017] Figure 8 A block diagram of an in-vehicle computing system according to one or more embodiments of the present disclosure is shown. Detailed Implementation

[0018] Traffic-related infrastructure plays a crucial role in enabling intelligent mobility through intelligent traffic management, which involves communication between vehicles and traffic poles, traffic signs, traffic processing control stations, and other vehicles to achieve intelligent traffic management involving autonomous vehicles. Adding advanced components to traffic infrastructure to aid in smooth traffic management increases the complexity of driving infrastructure, requiring vehicles to have a clear understanding in order to operate vehicle-to-infrastructure (V2I) based intelligent traffic management systems.

[0019] Advanced transportation infrastructure poses significant perturbation challenges to sensor-based traffic sign recognition systems. Existing traffic management systems utilize sophisticated deep learning-based traffic sign recognition systems to understand the infrastructure. However, the security of digital systems used in vehicles and transportation infrastructure further exacerbates these complexity challenges. Therefore, cryptographic traffic sign recognition systems can be employed to strengthen existing sensor-based systems. However, physical attacks on transportation infrastructure components (e.g., traffic poles) can alter the entire infrastructure, thus perplexing cryptographic systems. For example, physical attacks on transportation infrastructure involve shifting traffic sign poles by changing their orientation. When a vehicle encounters two traffic poles on a path, ambiguity arises in understanding and planning the vehicle's route.

[0020] This disclosure addresses at least partially one or more of the aforementioned problems in object identification systems by utilizing secure communication from traffic poles and signal information for verification purposes to detect traffic pole attacks. For example, Figure 1 An exemplary environment 100 is shown for performing safety traffic sign detection between a vehicle 102 traveling in lane 112 and a traffic sign 104 guiding traffic in lane 112. As used herein, the term "traffic sign" may be used to refer to traffic signals, traffic lights, traffic signs, and / or any other indications that may be used in a traffic scenario to control and / or notify vehicles and / or operators on the road of traffic regulations, ordinances, warnings, instructions, etc. As used herein, the term "driving lane" may be used to refer to the lane in which a vehicle is traveling.

[0021] The traffic sign detection system may include a transceiver, wherein the transmitter is housed in and / or accessible through traffic sign 104. The transmitter may use an antenna mounted on or near traffic signal pole 108 and / or otherwise mounted on or near traffic sign 104 to transmit digital coded information (represented by transmission signal 106), and a vehicle receiver may use an antenna mounted on the vehicle to receive this digital information. The digital transmission information may include a coded representation of the corresponding traffic sign 104 displayed on an associated traffic signal display. The coded representation distinguishes one traffic sign from another using a unique ID assigned individually to each traffic sign. In a non-limiting example, when a “stop” sign is displayed on the traffic display for traffic sign 104, the transmitter transmits a coded representation of the unique ID assigned to the “stop” sign.

[0022] Digital transmission information may include a pole code representation corresponding to traffic pole 108. The pole code representation can distinguish one traffic pole from another using a unique pole ID assigned individually to each pole. As will be further described below, the pole code representation can be used to detect whether the digital code information transmitted from the antenna of traffic pole 108 applies to the vehicle's driving lane 112, and therefore can be used to detect changes in the physical position / orientation of traffic pole 108 (e.g., pole rotation) that may cause traffic pole 108 and the sign 104 mounted thereon to incorrectly guide traffic from lanes other than driving lane 112.

[0023] The ciphertext of the received traffic sign and the ciphertext of the received pole, transmitted using the transmitter, are received at vehicle 102, and the ciphertext information is verified within the vehicle infotainment system / vehicle processor of vehicle 102. This verification may include using the received ciphertext to verify traffic signs identified by the vehicle's computer vision system. For example, vehicle 102 may include one or more cameras configured to image an area of ​​the environment surrounding the vehicle (e.g., represented by field of view 110), where the resulting images are processed to locate traffic signs in the imaging data. Any traffic signs identified in the imaging data may be used in conjunction with the received ciphertext data to verify and / or authenticate computer vision-recognized traffic signs. Using the above non-limiting example, if computer vision-based traffic recognition in vehicle 102 identifies traffic sign 104 as a "stop" sign, the vehicle performs ciphertext authentication of the received signal using information from a "stop" ID associated with the computer vision-recognized "stop" sign. If ciphertext authentication using the "stop" ID is successful, the traffic sign is considered an authenticated traffic sign; otherwise, the traffic sign is considered a forged / false signal.

[0024] During certain vehicle operating conditions, vehicle 102 may receive digital coded information from more than one traffic signal and its corresponding pole, and may identify more than one traffic sign via computer vision-based traffic recognition. Under certain other operating conditions, the vehicle may receive digital coded information from one traffic signal and identify that traffic signal via computer vision; however, traffic poles and signals may be intended for different lanes of traffic but may be physically altered to mislead traffic in lane 112. Therefore, in addition to traffic sign 104, verification may also include verifying traffic pole 108 to determine whether traffic sign 104 and pole 108 are intended for use in lane 112 and whether traffic sign 104 will be considered for subsequent vehicle operation. Verification of traffic pole 108 may be based on identifying a reference traffic pole location using one or more of computer vision-based pole recognition and navigation information from the vehicle navigation system. The reference traffic pole for the driving lane may be a traffic pole designated by an official agency for guiding traffic in a given driving lane. In this example, when a vehicle is traveling in lane 112 and approaches traffic pole 108 and its associated sign 104, the reference traffic pole for guiding vehicle 102 in the lane is traffic pole 108. The identified reference pole location can be used in conjunction with the ciphertext of traffic pole 108 received by the vehicle to authenticate traffic pole 108.

[0025] For example, a second traffic pole, on which a second traffic sign is mounted and intended for use with a perpendicular lane (i.e., a lane perpendicular to lane 112), can be physically altered (e.g., rotated) so that the second traffic pole with the second traffic sign is incorrectly facing vehicle 102. Therefore, in addition to the digital password information 106, vehicle 102 can also receive second digital password information from the second traffic sign and the pole, and vehicle 102 can identify a second traffic sign other than traffic sign 104. To determine which traffic sign to consider for subsequent vehicle operation, vehicle 102 can verify pole 108 using the pole password representation of pole 108 and position information based on the vehicle's navigation system intended for use with lane 112; and can verify the second pole using the second pole password representation of the second pole and the position information of the reference pole for lane 112. Since pole 108 is authorized as a reference pole for lane 112, verification of the pole password representation of pole 108 relative to the reference pole information may be successful, while verification of the second pole password representation based on the reference pole information may fail. After successful authentication of pole 108 relative to lane 112, traffic pole 108 can be identified as a reference pole for driving lane 112, and sign 104 can be considered credible for traffic lane 112, while the second pole can be marked as a rotated pole / physically misplaced pole, and the second sign mounted on the second pole may not be considered credible for lane 112.

[0026] In this way, by using the vehicle navigation system to identify the reference pole position information of the vehicle's driving lane and to identify the coded representation of the traffic pole received from it, the vehicle can verify whether the traffic pole is intended for its driving lane, identify whether the traffic pole is misplaced / rotated / attacked and causing misleading information, and discard information from the pole and the sign installed on it if the pole is not intended for the driving lane. (Reference) Figure 2 and Figure 3 An exemplary transceiver system for detecting changes in the position of traffic poles (e.g., physical attacks on traffic poles that mislead traffic in non-reference lanes, environmental factors such as strong winds that cause the traffic poles to rotate, etc.) is discussed. The transceiver system discussed here can also be used for cryptographic traffic sign verification. (See also...) Figure 4A and Figure 4B An exemplary method is described herein for generating and transmitting a cryptographic representation of a traffic sign and its associated traffic pole from a transmitting antenna. (See also: [details omitted]). Figure 5A and Figure 5B An exemplary method for receiving and verifying cryptographic representations of traffic signs and their associated poles via a vehicle system is discussed. Furthermore, in Figures 6A to 6C The text discusses the use of [something] in [something]. Figure 2 and Figure 3 Exemplary use cases of the transceiver system described in [the document] and methods for detecting traffic pole attacks and verifying traffic signs (in [the document]). Figure 4A , Figure 4B , Figure 5A and Figure 5B (in Chinese). (in Chinese) Figure 7 and Figure 8 An exemplary vehicle infotainment system and an exemplary in-vehicle computing and control system are illustrated. These can be used for password verification of traffic signs and their associated poles.

[0027] Figure 2A block diagram of an exemplary transceiver system 200 is shown. The transmitter portion 202 of the transceiver system 200 includes traffic signs 204, which display traffic instructions via a display 203 to control traffic flow (e.g., stop lights / signs, yield signs, etc.) and / or notify vehicle operators of traffic / road parameters (e.g., warnings or suggestions, regulations such as speed limits, etc.). Traffic signs 204 can be controlled via a traffic management system 205 (e.g., an official traffic authority, which in some examples may be a government entity). For example, authorized personnel and / or authorized automated controllers can provide input to and / or provide input via the traffic management system, which is directed to a traffic sign control system 207 and used to generate traffic sign signals instructing the desired output of traffic signs 204. The desired output may refer to the display output of variable signs (e.g., signs that can be controlled to display different sign names) and / or the printed and / or manufactured output of static signs (e.g., the shape, color, text, or other parameters of the sign).

[0028] Furthermore, the traffic management system 205 can input updated traffic pole information via the traffic pole information control system 250. The updated traffic pole information may include the geographic location information of each traffic pole (also referred to herein as location information) and lane reference information indicating which lane(s) a given traffic pole is intended to guide. In other words, the lane reference information indicates which lane(s) a given traffic pole with traffic signs mounted on it is intended to guide. The updated traffic pole information can be periodically updated and managed to include the latest location information and lane reference information for each pole. Therefore, before transmission, the traffic pole information control system 250 contains updated information about the location information of all traffic poles and the corresponding lane reference information (i.e., information about which lanes they are applicable to). For example, when a vehicle is moving in a specific lane (i.e., a driving lane), the traffic pole information control system 250 can indicate which traffic pole is assigned to that driving lane. This information in the traffic pole information control system 250 is distributed across all traffic poles and is available to all moving vehicles.

[0029] Traffic sign 204 may include a computing device configured to provide a coded representation of traffic signs (CRTS) and / or control the display of traffic signs, and / or communicate with said computing device. For example, traffic sign 204 may include a coded data transmission control system 209 having a CRTS module 206 and / or communicate with said coded data transmission control system, which may include a processor and a memory storing instructions thereon to provide a coded representation of traffic signs. In this way, CRTS module 206 may be configured to generate a coded representation of traffic sign signals received from traffic sign control system 207.

[0030] Traffic sign 204 may include a computing device and / or communicate with said computing device, which is configured to provide a coded representation of the traffic pole (CRTP). For example, traffic sign 204 may include a coded data transmission control system 209 having a CRTP module 252 and / or communicate with said coded data transmission control system, which may include a processor and a memory thereon storing instructions to provide a coded representation of the traffic pole on which traffic sign 204 is mounted. In this way, CRTP module 252 may be configured to generate a coded representation of updated information about the traffic pole (on which traffic sign 204 is mounted) received from traffic pole information control system 250.

[0031] The cryptographic data transmission control system 209 can communicate with a transmitting antenna 208 that wirelessly transmits and / or broadcasts the (e.g., digital) cryptographic representation of generated traffic sign signals and the cryptographic representation of generated traffic poles (e.g., periodically and / or in response to triggers, such as requests from nearby vehicles or the detection of nearby vehicles). Therefore, the cryptographic data transmitted (and / or broadcast) by the transmitting antenna 208 can include both the cryptographic representation of traffic sign signals and the cryptographic representation of traffic signs mounted on traffic poles.

[0032] Traffic sign 204 may also include a traffic sign display control system 211 and / or communicate with the traffic sign display control system, which may include a processor (or use the same processor as the cryptographic data transmission control system 209) and instructions stored in a memory to generate display control instructions to change the display 203 of traffic sign 204 according to traffic sign signals. For example, traffic sign signals may be received in parallel at traffic sign display control system 211 and cryptographic data transmission control system 209, such that the generation of the cryptographic representation of the traffic sign signals and the generation of display control instructions are performed in parallel, the display control instructions being used to control display 203 to display the traffic sign associated with the traffic sign signals. Therefore, display 203 may be controlled in parallel with transmitting antenna 208, such that the cryptographic representation of the traffic sign signals is transmitted synchronously with the display changes (e.g., without time or phase delay).

[0033] As traffic sign signals change (e.g., from "Stop" (red) to "Go" (green)), the corresponding coded representation of the traffic sign signal changes; however, the coded representation of the traffic pole remains unchanged and continues to be transmitted along with each transmission (and / or broadcast) of the coded representation of the traffic sign signal. In this way, pole information and traffic sign signal information are transmitted and / or broadcast from antenna 208.

[0034] The receiver portion 210 of the transceiver system 200 may be integrated into the vehicle 212 and includes a cascaded combination of computer vision-based traffic sign recognition and cryptographic traffic sign verification (e.g., where cryptographic traffic sign verification uses the output from computer vision-based traffic sign recognition to perform verification of the identified traffic signs). Computer vision-based traffic sign recognition can be used for the initial detection and recognition of traffic signs, while cryptographic traffic sign verification can be used to perform authentication tasks to verify the legality of traffic signs. However, it should be understood that one or more processes performed by computer vision-based traffic sign recognition may occur before, after, and / or concurrently with one or more processes performed by cryptographic traffic sign verification.

[0035] For computer vision-based recognition, the receiver portion includes one or more cameras 214 and a computer vision-based traffic sign recognition (CVTSR) module 216. Each camera 214 includes one or more image sensors mounted on or within the vehicle 212 for imaging the vehicle's environment. Cameras 214 may include rear-view cameras, front-view cameras, side-view cameras, cameras with a wide field of view (e.g., cameras with a field of view greater than 180 degrees), and / or any other suitable camera associated with the vehicle. In addition to imaging traffic signs, one or more cameras 214 may also be used to provide obstacle detection, lane recognition, surround-view imaging for display within the vehicle, and / or other imaging tasks.

[0036] The CVTSR module 216 can use one or more image analysis techniques (e.g., thresholding, edge detection, object classification, etc.) to identify and / or classify traffic signs present in images captured by one or more cameras 214. For example, multiple objects, shapes, and / or other defining characteristics of traffic signs can be classified and stored in memory accessible to the CVTSR module 216 (e.g., local memory in the vehicle and / or memory accessible via wired or wireless connections, such as cloud-based storage devices). Traffic sign identification and / or classification by the CVTSR module 216 may include using deep learning algorithms and / or otherwise applying machine learning to compare the shape of detected objects with those shapes already stored in the aforementioned memory to resolve the detected objects as corresponding to associated traffic signs. The CVTSR module 216 may filter the stored traffic signs based on parameters of the detected objects (such as size, shape, color, location / surroundings, position relative to the road surface, and / or other features of the detected objects, which may include text and / or graphic elements displayed or printed on the detected objects). Detected objects can be matched against stored traffic signs based on scores associated with one or more traffic signs, each score being a function of the similarity to one or more parameters of the stored traffic sign. For each stored traffic sign, each parameter may have a weight indicating its relevance or uniqueness to the stored traffic sign. For example, an octagon might be primarily used for stop signs, while a rectangle might be used for several different signs, such as speed limit signs, exit signs, etc. Accordingly, the matching shape might be given a higher weight for stop signs rather than speed limit signs. Any of the above factors, including the parameters used for matching and the weights of each parameter, can be tuned using machine learning (e.g., using training data during the initial calibration of the system and / or dynamically updated based on responses to real-time traffic sign indications).

[0037] The CVTSR module 216 can also identify traffic poles present in images captured by one or more cameras 214. Traffic pole identification can be performed similarly to the traffic signs discussed above, and will not be repeated for the sake of brevity.

[0038] The aforementioned components can be used to provide initial identification of traffic sign 204 and traffic pole 251 associated with traffic sign 204 via computer vision. The initial identification of traffic sign 204 can then be used to verify traffic sign 204 via a cryptographic traffic sign verification component, which includes antenna 218 and cryptographic traffic sign verification (CTRV) module 220. Antenna 218 can be configured to receive information, such as a cryptographic representation of traffic sign signals provided to control the output of traffic sign 204 and / or other cryptographic representations of traffic sign signals wirelessly received from other traffic signs. The received information can be passed to CTRV module 220 for processing to determine the traffic sign associated with (e.g., indicated by) the received information. For example, CTRV module 220 can perform verification of the received data (e.g., signature verification), decrypt the received information, and parse the decrypted information to confirm the identity associated with the associated traffic sign. The decrypted information can be compared with a database of traffic sign identifiers (e.g., locally stored in the vehicle and / or stored in a cloud-based storage device) to determine whether the transmitted data was corrupted during transmission (e.g., if the decrypted information matches a stored traffic sign identifier, the data was not corrupted during transmission). The CTRV module 220 can provide the result of the password-based traffic sign verification to the verified traffic sign indicator 222, which (e.g., outputs a signal to one or more vehicle systems, such as a display controller, processor, engine controller, etc.) indicating whether the traffic sign identified by the CVTSR module 216 is valid.

[0039] The initial identification of traffic poles by the CVTSR module 216 can be used in conjunction with the navigation-based reference traffic pole information determination module 256 to verify traffic pole 251 via a cryptographic traffic pole verification component (including antenna 218 and cryptographic traffic pole verification (CTRPV) module 258). Antenna 218 can be configured to wirelessly receive a cryptographic representation of the traffic pole along with a cryptographic representation of the traffic sign signal. The received traffic pole information can be passed to the cryptographic traffic pole verification (CTRPV) module 258, which also receives reference pole information for traffic poles corresponding to the current driving lane and navigation coordinates of the vehicle from the navigation-based module 256 of vehicle 212. The traffic pole information received from antenna 218, along with the navigation-based reference pole information from vehicle 212, can be processed to determine whether the pole information received from the traffic pole corresponds to a traffic pole applicable to the vehicle's driving lane. For example, CTRPV module 258 can perform verification of the received data (e.g., signature verification) and decrypt the received pole information based on navigation-based pole information from vehicle 212 to determine whether the traffic poles and signals identified by the vehicle (via computer vision) and the information transmitted to the vehicle are suitable for the vehicle's driving lane. If decryption is successful, the pole is authenticated and can be used for further verification of traffic signs. In particular, CTRPV module 258 can provide the result of the password-based traffic sign verification to the verified traffic sign indicator 222, which (e.g., to one or more vehicle systems, such as a display controller, processor, engine controller, etc.) outputs a signal indicating whether the traffic signs and poles identified by CVTSR module 216 are valid.

[0040] For example, if a traffic pole identified by CVTSR module 216 is confirmed to correspond to a driving lane and if a traffic sign identified by CVTSR module 216 is indicated as valid (e.g., if one or more vehicle systems receive an output from the verified traffic sign indicator 222 indicating successful decryption of received cipher data, followed by an ID comparison with a unique ID stored locally in the vehicle), then one or more vehicle systems can continue to control vehicle operation based on the identified traffic sign (e.g., providing automatic responses to the traffic sign, such as outputting the traffic sign indicator, adjusting the autonomous operation of the vehicle to comply with regulations and / or traffic control indicated by the traffic sign, etc.). However, if a traffic pole identified by CVTSR module 216 does not correspond to a driving lane, the traffic sign signal may be discarded even if the traffic sign identified by CVTSR module 216 is valid, and one or more vehicle systems may not adjust / control vehicle operation based on traffic sign information for a pole that is not applicable to a driving lane. Furthermore, if a traffic pole identified by CVTSR module 216 is determined to correspond to a driving lane, but a traffic sign identified by CVTSR module 216 is indicated as invalid (e.g., if one or more vehicle systems receive an output from verified traffic sign indicator 222 indicating unsuccessful decryption of received ciphertext sign data), one or more vehicle systems may not alter or control vehicle operation based on the identified traffic sign. In any case, if a traffic sign is not used to adjust vehicle operation, one or more vehicle systems may optionally output a warning to the driver and / or traffic authority services indicating that the traffic sign and / or pole may be damaged.

[0041] Figure 3 A flowchart illustrating an exemplary method 300 for performing password verification of a traffic sign is shown, including password verification of a traffic pole to which the traffic sign is mounted. For example, method 300 can use... Figure 2 The transceiver system 200 is used to perform this. Method 300 will be referred to herein. Figure 2 The system and components described herein are explained, but it should be understood that the method can be applied to other systems and components without departing from the scope of this disclosure. At 302, the method includes generating a traffic sign and pole database. The traffic sign and pole database can be formed by generating a unique sign ID for each of a plurality of possible traffic signs and by generating a unique pole ID for each of a plurality of possible traffic poles associated with each of the plurality of possible traffic signs. The traffic sign and pole database can be generated using a centralized service and / or can be generated in each transmitter system (e.g., Figure 2The transmitter system 202) generates the data locally. The traffic sign and pole database can be generated during associated system initialization and / or continuously or periodically updated to refresh the allocation of unique sign and pole IDs. For example, to increase security, unique sign and pole IDs can be periodically reassigned, allowing traffic signs and associated traffic poles to periodically receive different unique IDs. Thus, the assigned unique IDs may expire after a predetermined threshold period and / or based on triggers (e.g., indications that the database may be compromised, such as an indication that a counterfeit traffic sign has been detected (examples of such detection are described below), an indication that a traffic pole has been rotated, etc.). (See also: Regarding...) Figure 2 As described, the traffic sign and pole database can be stored locally at the transmitter system and / or remotely at a centralized system (e.g., a cloud-based storage device) for the transmitter system to access.

[0042] At 304, the method includes using a database of traffic signs and poles generated at 302 to match traffic signs (e.g., with the transmitter system (such as...) performing this part of method 300). Figure 2 The transmitter system 202) maps traffic signs associated with traffic signs to unique identifier IDs. Furthermore, at 354, method 300 includes mapping traffic poles associated with traffic signs (i.e., traffic poles where traffic signs are installed) to unique pole IDs using a traffic sign and pole database. To prepare unique identifier IDs and their associated unique pole IDs for secure transmission, the method also includes cryptographically representing the unique identifier IDs, as shown at 306, and cryptographically representing the unique pole IDs, as shown at 356. As shown, the mapping and cryptographic representation of unique identifier IDs and unique pole IDs can be performed in parallel. Implementations where the mapping and cryptographic representation of unique identifier IDs and unique pole IDs are performed sequentially and in any order are also within the scope of this disclosure. By encrypting the unique identifier ID and its associated pole ID before transmission, the unique ID can be discovered only by systems having the associated keys used for signature verification and decryption (as will be referred to below). Figure 4A , Figure 4B , Figure 5A and Figure 5B (Described in more detail). In this way, the unique identifier ID and its associated unique bar ID can be protected from tampering during the verification process.

[0043] After representing the unique identifier ID cryptographically at 306 and the unique pole ID cryptographically at 356, method 300 proceeds to 308. At 308, method 300 includes (e.g., via antenna 309) transmitting identifier and pole cryptographic information, including the cryptographically represented unique identifier ID and the cryptographically represented unique pole ID. The transmission of the cryptographic identifier and pole information can be continuous (e.g., via continuous broadcast) to provide the highest availability of the transmitted information. In other examples, the transmission of the cryptographic identifier and pole information can be periodic (e.g., via broadcasts repeated at fixed intervals) to provide high availability while still providing some bandwidth, power, and / or other resource savings relative to the continuous broadcast example.

[0044] In other examples, the transmission of cipher signs and pole information may be performed solely in response to a trigger (e.g., in response to the detection of a request for information from an oncoming vehicle and / or in response to the detection of a vehicle approaching within a threshold distance of the traffic sign by sensors associated with the transmitter system, which in some examples is based on sensor range). In trigger-based examples, the system may perform continuous and / or periodic transmissions for a predetermined period of time after a trigger is detected and / or until an exit trigger is detected (e.g., determining that a vehicle is outside the threshold distance of the traffic sign and / or that a vehicle is detected as moving away from the traffic sign). Alternatively, in trigger-based examples, the system may perform a predetermined number of transmissions (e.g., one to three transmissions) in response to a trigger and not perform any additional transmissions until the next trigger is detected. By utilizing transmission resources only in response to triggers indicating that a vehicle or driver may be attempting to identify the associated traffic sign, trigger-based examples can provide the highest degree of resource savings compared to continuous and periodic broadcast examples. In each of the above transmission examples, data can be transmitted via a wireless communication link according to associated protocols (e.g., Wi-Fi, Wi-Fi Direct, cellular connectivity, Bluetooth, Near Field Communication [NFC], 5G, VANET protocol, etc.). For example, transmission can occur on a proximity-based communication link (e.g., Bluetooth, NFC, etc.) to target vehicles near the traffic sign. Furthermore, in each of the above-described examples of coded sign and pole information transmission, the coded sign and pole information can be updated in response to changes in traffic sign signals provided by the traffic sign control system (which also leads to associated changes in the display of the traffic sign). The updated coded sign and pole information can correspond to an updated unique ID that corresponds to the updated traffic sign signal. In some examples, only the coded sign ID can be updated; however, the updated coded sign ID can be transmitted along with the coded pole ID. Similarly, when only the coded pole ID is updated (e.g., due to the installation of a new pole, periodic pole ID updates, etc.), the updated coded pole ID is transmitted along with the coded sign ID. Therefore, during each transmission and / or broadcast, the ciphertext-represented flag ID is transmitted together with the ciphertext-represented pole ID.

[0045] Now turn to the receiver system side of method 300 (e.g., performed by a vehicle-based system, such as...). Figure 2 The receiver system 210, including vehicle 212, includes a method that involves detecting traffic signs and traffic poles associated with the traffic signs via a camera, as shown at 310. For example, it can be achieved by using... Figure 2Camera 214 images the vehicle's surrounding environment to perform detection at 310. At 312, the method includes using a CVTSR module (e.g., Figure 2 The CVTSR module 216) identifies traffic signs. For example, as mentioned above... Figure 2 The CVTSR module can process images captured by the camera (e.g., including the image captured at 310) and identify traffic signs and traffic poles associated with the traffic signs in the processed images. At 314, the method includes outputting an indicator of the traffic sign identified at 312 (e.g., an indicator associated with the traffic sign identified from the processed image). For example, the indicator could be a stored ID, locally stored in the vehicle and mapped to the identified traffic sign in the traffic sign database generated at 302, since the stored ID is used for verification and decryption of received password information, as will be described in more detail below.

[0046] Furthermore, in parallel with obtaining and outputting the traffic sign indicator at point 314, the method proceeds to point 362 after identifying the traffic sign and its associated pole. At point 362, method 300 includes obtaining reference pole position information using a vehicle navigation system. This includes determining the vehicle's current driving lane and the vehicle's navigation coordinates. Further, based on the vehicle's driving lane information and navigation coordinates, reference pole position information for the reference pole applicable to the vehicle's current driving lane and navigation coordinates can be obtained. In other words, the reference pole is a traffic pole designed to guide traffic in the current driving lane, and the reference pole position information of the reference pole can be obtained from the vehicle's driving lane information and navigation coordinates.

[0047] After obtaining the reference pole position information, at 364, method 300 includes obtaining the output indicator of the reference pole. The output indicator of the reference pole may be a stored pole ID, which is locally stored in the vehicle and mapped to a reference traffic pole in the traffic pole database generated at 302. The stored pole ID is then used to verify and decrypt the received password information, as described in more detail below.

[0048] While method 300 describes obtaining reference pole information using a vehicle navigation system after detecting a traffic sign and its associated traffic pole, the vehicle control system can also anticipate a reference traffic pole at an approaching intersection within a threshold distance ahead of the current vehicle position in the current driving lane. If the camera and CVTSR do not detect the anticipated reference pole, the vehicle control system can determine that the reference pole and therefore the associated sign mounted thereon are not present, and can provide instructions to the vehicle control system (e.g., provide an alert to the operator, an instruction to reduce speed at the approaching intersection, etc.) to take warning measures at the approaching intersection.

[0049] The output indicator of the identified flag obtained at 314 and the output indicator of the reference rod obtained at 364 can be provided to the CTRV module (e.g., Figure 2 The CTRV module 220 is used for verification of the identified marker and the received pole information, respectively. In some implementations, such as Figure 2 As shown, a password-based traffic pole verification module, such as CTRPV module 258, can be used to verify received pole information based on reference pole information.

[0050] To perform verification of the identified sign, at 316, the method includes receiving cipher information transmitted at 308 at the CTRV module. At 318, the method includes performing cipher verification of the identified sign provided via an indicator output at 314 using the CTRV module. Verifying the identified sign at 318 (e.g., identified via the CVTSR module at 312) may include decrypting the cipher information received at 316 with a stored ID to determine a unique ID transmitted by the transmitter system, and determining the traffic sign associated with that unique ID (e.g., mapping the unique ID to a traffic sign based on a traffic sign database generated at 302 and / or an equivalent traffic sign database).

[0051] As described above, the cipher information transmitted at 308 includes sign cipher information and pole cipher information. Therefore, at 316, the received cipher information may include the received sign and pole cipher information. Specifically, the received sign cipher information may include a cipher representation of a unique sign ID, and the received pole cipher information may include a cipher representation of an associated pole ID. The sign identified by the CVTSR module can be verified by the CTRV module using the cipher representation of the received unique sign ID and the output indicator of the identified sign, as discussed at 318. Furthermore, at 319, method 300 includes ciphering the received pole information. In particular, the received pole information (i.e., the cipher representation of the pole ID) can be verified using the output indicator of a reference pole and the cipher representation of the received associated pole ID. Verifying the received pole information may include decrypting the received associated pole ID using the stored pole ID of a reference pole to determine whether the pole transmitting the ciphered pole information is suitable for the current driving lane.

[0052] As shown at 320, sign verification may further include determining whether the traffic sign identified using the CVTSR module at 312 is valid for successfully decrypting the information transmitted at 308 (e.g., a locally stored ID associated with the traffic sign identified using the CVTSR module can be used to extract a private key (associated with the corresponding sign and stored in a secure storage device supported by a secure operating system). If verification of the identified sign from the CVTSR module is unsuccessful (e.g., "No" at 320), the method includes marking the traffic sign as counterfeit, as shown at 322. In some examples, verifying traffic signs may also include consulting additional information sources, such as news sources, police / fire / rescue information sources, weather forecasts, and / or other sources, which can identify the current conditions near the vehicle and help determine the likelihood of the traffic sign being valid. For example, if a traffic sign is determined to indicate a road closure and it is determined that a police scanner also reports such a closure, then the traffic sign is likely valid. Alternatively, if a traffic sign is determined to indicate a storm in the area, but no such storm is reported in the area by any news and / or weather sources, then the traffic sign may be invalid or inaccurate.

[0053] As mentioned above Figure 2 The act of marking a traffic sign as counterfeit may include ignoring traffic signs detected by the CVTSR module, such that one or more vehicle systems are not controlled based on traffic signs identified by the CVTSR module. This allows vehicle operation to be maintained as if no traffic sign were detected by the CVTSR module, and vehicle operation can be controlled based on traffic signs indicated by the cipher information received at 316 and processed by the CTRV module when the cipher information transmission lever verification is successful (as described below at 324). In an additional or alternative example, if a traffic sign is marked as counterfeit and the cipher information transmission lever verification is successful (as described below at 324), some vehicle operations may be maintained, while other vehicle operations may be adjusted in response to the detection of the counterfeit traffic sign (e.g., other traffic signs at a predetermined distance from the counterfeit traffic sign may be ignored and / or subjected to a higher level of scrutiny by the verification system; vehicle displays may be altered to output a warning about the counterfeit sign; vehicle communication systems may be operated to send indications of the counterfeit sign and associated details to traffic or law enforcement authority computing systems, etc.).

[0054] In another example, if a traffic sign is flagged as counterfeit and the ciphertext transmission pole is successfully verified (as described below at 324), vehicle operation can be selectively adjusted to comply with regulations and / or information from two potential traffic signs based on the predicted safety score of the traffic sign detected via computer vision or indicated by data received via the vehicle's antenna. For example, if a traffic sign detected via a camera is identified as a speed limit sign announcing a 70 mph speed limit, and a unique ID received via ciphertext data indicates a speed limit sign announcing a 60 mph speed limit, the vehicle can adjust to operate according to the lower speed limit, which may have a higher predicted safety score. The safety score can be determined based on various parameters, including known area laws, the behavior of detected neighboring vehicles, detected objects / obstacles near the vehicle, weather, and / or other conditions. The vehicle system can operate according to any one or more of the examples above and can repeat the previously described portion of method 300 until the traffic sign is verified at 320.

[0055] If CVTSR verification is successful (e.g., "Yes" at 320), the method proceeds to 324 to verify whether pole verification in the CTRV was successful. This includes determining whether the pole ID of the stored reference pole can be used to decrypt received cryptographic pole information (e.g., whether the private key of the reference pole intended to guide traffic in the current driving lane can be used to decrypt the public cryptographic key received by the vehicle). If the answer at 324 is "Yes," the transmitting pole and the reference pole are identical, and the transmitting pole is trusted; therefore, the marking on the transmitting pole corresponds to the current driving lane and can be considered for ADAS / autonomous vehicle processing. If the answer at 324 is "No," the transmitting pole is not applicable to the current driving lane, and the pole can be marked as attacked / rotated at 326; therefore, information from the transmitting pole and / or the marking (even if the marking has been verified) cannot be used for ADAS / autonomous vehicle processing. Marking a pole as attacked / rotated may include ignoring CVTSR detection of traffic signs mounted on the marked pole, such that one or more vehicle systems are not controlled based on traffic signs identified via the CVTSR module. Marking a pole as attacked can also include ignoring coded pole and sign information received at the vehicle from the attacked pole for further vehicle processing. In this way, vehicle operation can be maintained as if the CVTSR module had not detected the traffic sign and had not received coded information at 316 for ADAS / autonomous vehicle processing. In additional or alternative examples, some vehicle operations can be maintained while others are adjusted in response to the detection of an attacked pole (e.g., other traffic poles at a predetermined distance from the forged traffic sign could be subject to a higher level of verification by the system, the vehicle's display might be altered to output a warning about the attacked pole, the vehicle's communication system might be manipulated to send indications of the forged pole and associated details to traffic or law enforcement authority computing systems, etc.).

[0056] Returning to 324, if both pole verification and the identified sign verification are successful, the method proceeds to 328 to output an indicator indicating that the identified sign from the CVTSR module has been verified and the associated pole is a reference pole and therefore credible for traffic in the current driving lane. The method may also include consideration of certified / verified signs for Advanced Driver Assistance Systems (ADAS) and / or autonomous vehicle processing, as shown at 340. For example, as described above, verified signs can be used to control vehicle operation based on the type of traffic sign and the associated regulations / warnings / instructions provided by the verified sign.

[0057] Figure 4A and Figure 5AHigh-level flowcharts of exemplary methods 400 and 500 for cryptographic transmission and cryptographic reception / verification of traffic sign information are shown, respectively. In some examples, method 400 may be provided by a transmitter system associated with the traffic sign (such as...). Figure 2 The transmitter system 202) performs the method, while the method 500 can be performed by a receiver system associated with the vehicle (such as...). Figure 2 The receiver system 210) is executed.

[0058] Method 400 includes generating and / or accessing a traffic sign database at 402. For example, all possible traffic signs known to the transmitter system can be collected into the traffic sign database. As described in more detail above, the traffic sign database can be generated locally on the transmitter system and / or remotely (e.g., at a centralized system such as a cloud-based storage system). Therefore, the generation of the traffic sign database as described herein can be performed on the transmitter system and / or at a remote system. At 404, the method includes generating a unique ID for each traffic sign using a True Random Number Generator (TRNG). It should be understood that the TRNG generation technique described herein is an exemplary identifier generation technique, and unique IDs can be generated in other ways without departing from the scope of this disclosure.

[0059] At 406, the method includes mapping the unique IDs generated at 404 to traffic signs in a database generated / accessed at 402. This allows the database generated at 402 to be updated to store the association between a traffic sign (e.g., an initial traffic sign identifier) ​​and a selected one of the generated unique IDs for each traffic sign. The mapping performed at 406 can be rule-based (e.g., the association and / or assignment of unique IDs to traffic signs can be determined based on one or more rules) and / or can be random (e.g., determined via a random generation technique).

[0060] The unique ID can be encrypted using public-key cryptography. For example, at 408, the method includes accessing the encryption public key of the encryption algorithm, which is used at 410 to encrypt the unique ID generated at 404. For example, each unique ID may be converted into a different value and / or string by applying the public key accessed at 408 to the unique ID according to the selected encryption algorithm (e.g., applying a mathematical function to each unique ID where at least the unique ID and the public key are inputs). The method may also include signing the encrypted unique ID by accessing a private key (e.g., known only to the transmitter system) at 412 and applying a cryptographic signature algorithm (as shown at 414) to the encrypted unique ID (encrypted at 410) using the private key. The private key (and the public key) may be stored in a proprietary, legitimate traffic signal installation facility.

[0061] At 416, the method includes combining the encrypted unique ID (encrypted at 410) with the associated signature (applied at 414) to generate cryptographic data. Thus, the cryptographic data for each unique ID includes an encrypted unique ID (encrypted using a public key) signed with a digital signature based on a private key. In some examples, the digital signature may include a hash of the encrypted unique ID, which in turn is encrypted using a private key.

[0062] At 418, the method includes receiving a traffic sign signal from a traffic controller, the signal including an indication that the traffic sign is to be displayed on a traffic sign 420 associated with a transmitter system. For example, traffic sign 420 may include computing elements such as the transmitter system. A processor of the traffic sign may synchronize cryptographic data with the corresponding displayed traffic sign based on the traffic sign signal received at 418, as shown at 422. Synchronization at 422 may be performed to select cryptographic data associated with (e.g., formed using) a unique ID assigned to the traffic sign to be displayed, based on the traffic sign signal. In some examples, an additional security layer may be present to ensure that synchronization is performed only for the indication displayed on the traffic sign, which originates from changes to the traffic sign performed by an authorized source.

[0063] At point 424, the method includes transmitting cryptographic information via the antenna of the transmitter system. For example, at point 424, cryptographic information corresponding to cryptographic data associated with a unique ID from a traffic sign signal from a traffic controller is transmitted. The transmission of the cryptographic data can be similar to that described above. Figure 3 The method is performed by the transmission described at 308 of method 300. At 426, the method includes controlling the traffic sign display of traffic sign 420 to display the sign indicated by the traffic sign signal received at 418. The control of the traffic sign display can be synchronized with the transmission of coded information, such that the display of the traffic sign changes as the transmitted coded information changes. In this way, the synchronization performed at 422 can generate a signal that is transmitted to both the display and the antenna without any time delay between them.

[0064] Below is an example of pseudocode that can represent the operations at the transmitter system:

[0065] / / Infinite loop

[0066] 1. Traffic sign DB = {Sn1, Sn2, ..., SnN}

[0067] 2. A unique ID = TRNG(x), where ID = {ID1, ID2, ..., IDN}

[0068] 3. Assign {Sn1, Sn2…………..SnN} = {ID1, ID2…………IDN}

[0069] 4. Encrypted identifier (ID) = Encrypted(ID, E.Key Pub)

[0070] 5. Digital signature (encrypted identifier (ID)) = signature algorithm (encrypted identifier (ID), S.KeyPri)

[0071] 6. Cryptographic Identifier Data = [Encrypted Identifier (ID) Digital Signature (Encrypted Identifier (ID))], where Cryptographic Identifier Data = {Cryptographic Identifier Data (ID1), Cryptographic Identifier Data (ID2), Cryptographic Identifier Data (ID3) ………..Cryptographic Identifier Data (IDN)}

[0072] 7. Synchronized password flag data = Synchronize(display_flag, password flag data)

[0073] 8. Output = Transmission (synchronized cryptographic flag data)

[0074] Now turning to method 500, as described above, illustrates the password reception operation of a vehicle-based receiver system. At 502, the method includes capturing images of traffic signs using the vehicle's camera. This can be discussed as above regarding... Figure 2 The operation of camera 214 and / or Figure 3 The method at 310 of 300 performs the capture of the traffic sign image as described above. At 504, the method includes identifying the detected sign via a CVTSR module (e.g., as described above regarding...). Figure 2 CVTSR module 216 and / or Figure 3 The identification operation at 312 of method 300 is described. For example, an external information image including electronic display information received at the vehicle can be analyzed to identify electronic display information from a display source (e.g., a traffic sign). Electronic display information may include images, characters, and / or other electronic display information presented by the display source (e.g., a traffic sign). Thus, at 506, the indication of the traffic sign identified via computer vision (e.g., the stored ID of the identified sign stored locally at the vehicle) is identified. This identification may additionally or alternatively include generation characteristic fields (e.g., character fields including characters associated with or included in the electronic display information, a simplified version of the image / electronic display information from the display source, and / or another representation of the electronic display information).

[0075] At 508, the method includes accessing a replay protection memory block (RPMB) local to the vehicle (which stores multiple public keys for decrypting received data, each public key representing / corresponding to a different, corresponding potentially identifiable flag). To decrypt and verify the received data, the method also includes importing at 510 a corresponding private key for the identified flag (e.g., for the flag identified at 504, the private key corresponding to a stored ID associated with the identified flag as identified at 506). For example, a unique public / private key is used to encrypt unique IDs for different flags; thus, each unique ID is encrypted during encryption using a unique public key in the transmitter and decrypted at the receiver (e.g., the vehicle) using the corresponding unique private key.

[0076] To verify the identified tag, the vehicle can perform verification using data transmitted by a transmitter associated with the tag. At 512, the method includes receiving cryptographic data of a digital signature (e.g., cryptographic data of a digital signature transmitted at 424 of method 400 in Figure 4) via the vehicle's antenna. The signature for each tag is performed at the transmitter using a single private key (e.g., the same private key for all tags), and thus, a corresponding public key (e.g., part of a symmetric public / private key pair used for signature verification) is used for signature verification at the receiver. Therefore, at 514, the method includes accessing the vehicle's write-protected memory, and at 516, the method includes (e.g., from write-protected memory with associated integrity checks) importing a signing public key (e.g., processed and / or generated via the original equipment manufacturer) for signature verification.

[0077] At 516, the method includes performing signature verification on the received digitally signed cryptographic data (received at 512) using an imported signature public key. For example, the public key can be applied to the cryptographic data to ensure that the received data matches the signed data (e.g., to verify that no changes were made to the data after it was signed). The verification process may include using the imported signature public key to decrypt the signed / digitally signed cryptographic data to generate a decrypted hash, and then performing a second hash calculation on the same data (e.g., using the same hash algorithm as the transmitter system) to determine if the second hash calculation matches the received digitally signed cryptographic data. A match indicates that the data may not have been tampered with, while a mismatch indicates that the data may have been corrupted.

[0078] Unauthorized signals are rejected in the aforementioned signature verification, while authorized traffic signals that have been successfully verified in the aforementioned digital signature verification are passed for decryption. Therefore, at 520, the method includes decrypting the signed and verified cryptographic data using a private key (imported from the RPMB at 510 based on computer vision-based sign recognition) in the secure execution mode of the vehicle's secure operating system. At 522, the method includes determining whether the decryption was successful. For example, identifying successful decryption may include determining whether the private key imported at 510 can be used to decrypt the cryptographic data (e.g., indicating that the correct key is retrieved from the RPMB for decryption, which in turn indicates that the identified sign from computer vision-based traffic sign recognition is correct). If decryption is unsuccessful (e.g., "No" at 522), the method includes marking the detected traffic sign as counterfeit, as shown at 524. This marking may be propagated to vehicle systems and / or third-party systems (e.g., traffic management bureau systems), as referenced above. Figure 3 The mark at position 322 is mentioned.

[0079] Alternatively, if decryption is successful (e.g., "Yes" at 522), the method proceeds to 526 to determine whether the decrypted sign ID (e.g., revealed via decryption performed at 520) is the same as a stored ID locally stored at the vehicle (e.g., the stored ID assigned to the identified sign by computer vision-based sign recognition at 504, which is the same ID assigned to the corresponding traffic sign at the transmitter side during transmission). Additionally or alternatively, the determination at 526 may include comparing a characteristic field generated based on the CVTSR-based identifier from electronic display information (e.g., traffic sign) with cryptographic data received from the display source at the vehicle. The cryptographic data may include encrypted security information, including characters of the electronic display information (e.g., traffic sign), a subset of the characters of the electronic display information, and / or data representing the electronic display information (which in some examples may be a simplified or truncated version of the displayed sign). The comparison of the characteristic field with the cryptographic data may include decrypting the cryptographic data using a key retrieved based on the characteristic field (e.g., as described above with reference to retrieving a key using the stored ID) to generate the resulting decrypted data. The decrypted data can be compared with the feature fields to determine if a match exists (this indicates a verified flag).

[0080] If the decrypted sign ID differs from the stored ID (e.g., "No" at 526, indicating the sign ID is corrupted), the method proceeds to 524 to mark the sign as counterfeit, as described above. Alternatively, if the decrypted sign ID matches the stored ID (e.g., "Yes" at 526, indicating the sign ID is not corrupted), the method includes transmitting the authenticated and verified traffic sign to one or more vehicle systems (e.g., transmitting the identifier of the authenticated traffic sign to ADAS and / or autonomous vehicle processing systems for controlling the vehicle and / or one or more vehicle systems), as shown at 528. For example, if the sign is verified, one or more vehicle systems can be controlled to comply with regulations associated with the verified sign (e.g., the electronic display information of the verified sign). Otherwise, if the sign is not verified and / or otherwise marked as counterfeit, the vehicle systems may not be controlled to comply with regulations associated with that sign / electronic display information.

[0081] Below is an example of pseudocode that can represent the operation at the receiver system:

[0082] / / Infinite loop

[0083] 1. Traffic sign image = camera (traffic sign pole)

[0084] 2. The identified traffic sign = CVTSR (Traffic Sign Image)

[0085] 3. Received password = Received (Transmitted (Synchronized password flag password))

[0086] 4.S.KeyPub = Import signing key (integrity check storage (identified traffic sign))

[0087] 5. Encrypted identifier (ID) = Signature verification algorithm(received_password_password, S.KeyPub)

[0088] 6. Signature verification successful

[0089] 7.D.KeyPri = Import decryption key (replay protected memory block)

[0090] 8. Decrypt (encrypted identifier (ID), D.KeyPri)

[0091] 9. ADAS / Autonomous Vehicle Operation = Transmitting (Identified Traffic Signs, Decryption Successful)

[0092] Figure 4B and Figure 5BHigh-level flowcharts of exemplary methods 450 and 550 for cipher transmission and cipher reception / verification of traffic pole information are shown, respectively. In some examples, method 450 may be performed by a transmitter system associated with the traffic sign, such as... Figure 2 The transmitter system 202, and the method 550 can be performed by a receiver system associated with the vehicle, such as... Figure 2 Receiver system 210.

[0093] Method 450 includes obtaining updated pole information at 452. The updated pole information can be obtained from a traffic management system, such as traffic management system 205, which may be maintained and updated by an official agency (e.g., an official traffic authority, which in some examples may be a government entity). Obtaining the updated pole information may include obtaining updated pole-lane information at 453, which includes reference lane information for each of multiple traffic poles in a traffic pole database (such as traffic sign and pole database 302). For example, all possible traffic poles known to the transmitter system can be collected into the traffic pole database. As described in more detail above, the traffic pole database can be generated locally on the transmitter system and / or remotely (e.g., at a centralized system such as a cloud-based storage system). Therefore, operations regarding the generation of the traffic pole database as described herein can be performed on the transmitter system and / or at a remote system.

[0094] Next, at 454, method 450 includes updating the traffic pole database with the updated pole information. At 456, method 450 includes generating a unique pole ID for each traffic pole using a true random number generator (TRNG). It should be understood that the TRNG generation technique described herein is an exemplary identifier generation technique, and unique pole IDs can be generated in other ways without departing from the scope of this disclosure.

[0095] At 460, the method includes mapping a unique pole ID generated at 456 to a traffic pole in a database updated / accessed at 454. This allows the database updated at 454 to be updated to store the association between a traffic pole (e.g., an initial traffic sign identifier) ​​and a selected one of the generated unique IDs for each traffic pole. The mapping performed at 406 can be rule-based (e.g., the association and / or assignment of unique IDs to traffic poles can be determined based on one or more rules) and / or can be random (e.g., determined via a random generation technique).

[0096] Next, at 460, method 450 includes encrypting the unique pole ID for each pole with the corresponding public key. For example, the unique pole ID can be encrypted using public-key cryptography. Therefore, at 458, method 450 includes, for each unique pole ID, accessing the encrypted public key of the encryption algorithm, which is used at 450 to encrypt the unique pole ID generated at 456. For example, by applying the corresponding unique public key accessed at 458 to the unique pole ID according to the selected encryption algorithm (e.g., applying a mathematical function to each unique ID where at least the unique pole ID and the public key are inputs), each unique ID may be converted into a different value and / or string.

[0097] Furthermore, at 462, method 450 includes encrypting the unique sign ID of each sign associated with each pole (i.e., the unique sign ID of each sign installed on the corresponding pole) using a public key generated and accessed for each sign in a traffic sign database (such as traffic sign and pole database 302). Details regarding the encryption of the sign are provided above. Figure 4A A discussion was held.

[0098] After encrypting each unique pole ID, at 466, method 450 includes signing each of the encrypted unique IDs by accessing the corresponding unique private key (e.g., known only to the transmitter system) at 464 and applying a cryptographic signature algorithm (as shown at 466) to the encrypted unique IDs (encrypted at 410) using that unique private key. The private key and public key may be stored in a proprietary, legitimate traffic signal installation facility.

[0099] Next, at 468, method 450 includes combining the encrypted unique pole ID (encrypted at 460) with the associated signature (applied at 466) to generate cipher pole data. Thus, the cipher pole data for each unique pole ID includes an encrypted unique pole ID (encrypted using the corresponding unique public key) signed with a digital signature based on the corresponding unique private key. In some examples, the digital signature may include a hash of the encrypted unique pole ID, which in turn is encrypted using the private key.

[0100] Next, at 470, method 450 includes transmitting coded information via the antenna of the transmitter system of the traffic pole. For example, at 470, coded information corresponding to coded pole data and a unique pole ID associated with the traffic pole from the traffic controller is transmitted. The transmission of the coded data can be similar to that described above. Figure 3 The method described at 308 of 300 is used to perform the transmission. Therefore, the transmitted cryptographic information may include cipher lever data and cipher flag data (such as...). Figure 4A(The obtained information is missing). Thus, each traffic pole on which associated traffic signs are installed can encrypt its unique pole ID using the corresponding pole public key and sign the encrypted unique pole ID using the corresponding pole private key. It can also encrypt its unique sign ID using the corresponding sign public key and sign the encrypted unique sign ID using the corresponding sign private key. After encrypting and signing the encrypted pole and sign unique IDs, the transmitters of the traffic poles and signs can transmit the encrypted and signed unique pole IDs and the encrypted and signed unique sign IDs together. Furthermore, as described above, the method includes controlling the traffic sign display to show the traffic sign signals received from the traffic controller (in...). Figure 4A (418 locations) indicates the sign. The control of traffic sign display can be synchronized with the transmission of coded information for signs and poles.

[0101] Below is an example of pseudocode that can represent the operations at the transmitter system:

[0102] / / Infinite loop

[0103] 1. Traffic pole DB = {Pn1, Pn2, ..., PnN}

[0104] 2. A unique lever ID = TRNG(x), where lever ID = {lever ID1, lever ID2, ..., lever IDN}

[0105] 3. Assign {Pn1, Pn2, ..., PnN} = {rod ID1, rod ID2, ..., rod IDN}

[0106] 4. Encrypted lever (ID) = Encrypted (lever ID, E.KeyPubPole)

[0107] 5. Digital signature (encrypted lever (ID)) = signature algorithm (encrypted lever (ID, S.KeyPriPole)

[0108] 6. Cipher stick data = [encrypted stick (ID) digital signature (encrypted stick (ID))], where cipher stick data = {cipher stick data (stick ID1), cipher stick data (stick ID2), cipher stick data (stick ID3) ... cipher stick data (stick IDN)}

[0109] 7. Combined cipher flags and lever data = Combined (synchronized cipher flag data, cipher lever data)

[0110] 8. Output = Transmission (synchronized cipher flag data, cipher stick data)

[0111] Turn Figure 5BThe diagram illustrates a method 550 for password reception operation of a vehicle-based receiver system, as described above. At 562, method 550 includes detecting and identifying traffic signs and poles using the vehicle's cameras. This can be discussed as described above regarding... Figure 2 The operation of camera 214 and / or Figure 3 The method 300 at 310 performs the capture of traffic sign and pole images as described above. After detecting traffic signs and poles, the detected signs can be identified via the CVTSR module (e.g., as described above regarding...). Figure 2 CVTSR module 216 and / or Figure 3 The identification operation at 312 of method 300 is described. In some examples, the CVSTR module can be used to identify the detected rod, and therefore, it can be combined with Figure 5A Steps 502, 504, and 506 discuss the detection and identification of traffic signs to perform the detection and identification of traffic poles.

[0112] Furthermore, at 562, method 550 includes obtaining pole position information using a vehicle navigation system. The pole position information is reference pole position information and can therefore be obtained in a manner similar to obtaining reference pole position information using a vehicle navigation system as described above with respect to 362. This includes determining the vehicle's current driving lane and the vehicle's navigation coordinates. Further, based on the vehicle's driving lane information and navigation coordinates, reference pole position information for a reference pole applicable to the vehicle's current driving lane and navigation coordinates can be obtained. While this exemplary method 550 illustrates obtaining reference pole position information after a traffic pole and its associated sign are detected via a camera, reference pole position information can be obtained independently of camera detection. For example, traffic pole position information including the geographic coordinates of multiple traffic poles and reference lane information (or reference lanes) for each traffic pole intended to guide traffic can be stored in a navigation database coupled to the vehicle navigation system. As the vehicle travels and approaches an intersection where a traffic pole applicable to its current driving lane is located, the vehicle navigation system can obtain reference pole information relating to the vehicle's current driving lane and geographic coordinates based on the vehicle's current geographic coordinates and the current driving lane information and traffic pole position information in the navigation database. This reference pole information is based on information from traffic pole databases (such as the traffic pole and sign database 302 managed and updated by official agencies), and therefore provides information about reference traffic poles applicable to the current driving lane and that vehicles in the driving lane must consider.

[0113] After obtaining the reference rod position information, method 550 proceeds to 566. At 566, method 550 includes importing the corresponding private key for the reference rod. The imported private key for the reference rod can be similar to... Figure 5AThe system imports the corresponding pole private key for the identified marker at point 510, and thus may include access to the RPBM, which is local to the vehicle and stores multiple private keys for decrypting received traffic pole data (encrypted by the corresponding public key). Further, when accessing the RPBM, the corresponding pole private key for a reference pole can be imported. The imported reference pole's pole private key can be used to decrypt the cipher pole ID (transmitted by the traffic pole) received by the vehicle via the antenna, and thus used to authenticate the traffic pole by verifying whether the pole ID received from the traffic pole corresponds to the reference traffic pole using the imported private key.

[0114] For example, a unique public key / private key pair is used for encryption of unique IDs for different poles. Thus, each unique pole ID is encrypted using the unique pole public key in the transmitter during encryption and decrypted using the corresponding unique pole private key in the receiver (e.g., a vehicle).

[0115] Turning now to 552, method 550 includes receiving digitally signed cryptographic stick data (e.g., the digitally signed cryptographic data transmitted at 470 of method 400 in Figure 4) via the vehicle's antenna. The signature for each stick is performed at the transmitter using a single private key; therefore, the corresponding public key (e.g., it is part of a symmetric public / private key pair used for signature verification) is used for signature verification at the vehicle's receiver. Verifying the signature of the cryptographic stick data received at the vehicle's receiver is similar to... Figure 5A The verification of the signature of the cryptographic token data is discussed at steps 514, 516, and 518. Therefore, at 554, the method includes (e.g., from a write-protected memory of a vehicle with associated integrity checks) importing a signature bar public key (e.g., processed and / or generated via the original equipment manufacturer) for signature verification.

[0116] At 556, method 550 includes performing signature verification on the received digitally signed cipher data (received at 552) using an imported signature public key (imported at 554). Pole signature verification can be performed to ensure that the cipher data has not been altered after it was signed. An exemplary pole signature verification process may be similar to a flag signature verification process and may include using the imported signature pole public key to decrypt the signed / digitally signed cipher data to generate a decrypted hash, and then performing a second hash calculation (e.g., using the same hash algorithm as the transmitter system) on the same data to determine if the second hash calculation matches the received digitally signed cipher data. A match indicates the data may not have been tampered with, while a mismatch indicates the data may have been corrupted.

[0117] Unauthorized transmissions from poles are rejected in the aforementioned signature verification, while cipher pole data from authorized traffic poles that have successfully verified their digital signatures are transmitted for decryption. Therefore, at 558, the method includes decrypting the signed and verified cipher pole data using a private key (imported from the RPMB at 566 based on reference pole information obtained from vehicle navigation information) in the secure execution mode of the vehicle's secure operating system.

[0118] Next, at 568, method 550 includes determining whether decryption was successful. For example, identifying successful decryption may include determining whether the private key imported at 566 is sufficient to decrypt the cipher pole data, indicating that the correct key is retrieved from the RPMB for decryption, which in turn indicates that the reference pole indicated by the vehicle navigation system corresponds to the traffic pole transmitting the cipher data. In other words, successful decryption indicates that the received cipher data comes from a traffic pole that serves as a reference pole intended to guide traffic in the current lane. If decryption is unsuccessful (e.g., "No" at 568), the method includes marking the detected traffic pole as rotated, as shown at 572. This marking may be propagated to the vehicle system and / or third-party systems (e.g., traffic management bureau systems), as referenced above. Figure 3 The mark at position 322 is mentioned.

[0119] Alternatively, if decryption is successful (e.g., "Yes" at 568), the method proceeds to 570. At 570, method 550 includes verifying that the traffic pole transmitting the cipher data is a reference pole for the vehicle's current driving lane and geographical location. After verifying the reference pole, other cipher data from the reference pole, such as... Figure 5A The cipher flag data shown, after verification of trustworthiness, can be considered by the vehicle system (e.g., for ADAS / autonomous processing). If the decryption of the received pole ID fails (e.g., "No" at 568), the sign information may not be considered by the vehicle even if the associated traffic sign ID is successfully decrypted, because the pole to which the associated sign is installed is not suitable for the current driving lane.

[0120] Below is an example of pseudocode that can represent the operation at the receiver system:

[0121] / / Infinite loop

[0122] 1. Reference pole marker = vehicle navigation system (vehicle geographic coordinates, current driving lane)

[0123] 2. Received cipher lever data = Receive (transmit (synchronized cipher-associated flags and lever data))

[0124] 3.S.KeyPub = Import Signature Key (Integrity Check Storage (Received _Password_Bar Data))

[0125] 4. Encrypted bar (ID) = Signature verification algorithm (received _password_bar_data, S.KeyPub)

[0126] 5. Signature verification successful

[0127] 6.D.KeyPri = Import decryption key (replay protected memory block (reference bar))

[0128] 8. Decrypt (encrypted key (ID), D.KeyPri)

[0129] 9. ADAS / Autonomous Vehicle Operation = Transmission (Confirm via traffic pole, decryption successful)

[0130] For illustrative purposes, a non-limiting exemplary scenario using the traffic pole attack detection system of this disclosure is provided. Figure 6A In an exemplary scenario, a four-way intersection 600 is shown having a traffic pole 622 for lane 621, a traffic pole 624 for lane 623, a traffic pole 626 for lane 625, and a traffic pole 628 for lane 628. A vehicle 620 traveling in lane 621 receives coded information 640 from the traffic pole 622. The coded information may include coded pole information for the traffic pole 622 and coded information for the traffic sign 632 associated with the traffic pole 622. As the vehicle 620 approaches the intersection, based on the vehicle's geographic coordinates and the driving lane 621, it can determine the reference traffic pole position information for the driving lane 621 via a vehicle navigation system. Simultaneously, via one or more cameras of the vehicle 620 and the vehicle's CVTSR, the vehicle can detect and identify the traffic pole 622 and its associated sign 632. In this example, all traffic poles are positioned to be appropriate for their corresponding lanes (i.e., there is no attack / alteration at any pole in intersection 600 that could cause a traffic pole to be appropriate for a non-reference lane). Therefore, the vehicle's computing system can use the reference pole location information to import a private key, which can then be used to successfully decrypt the cipher data of traffic pole 622. Thus, the vehicle can confirm that traffic pole 622 is the reference pole for driving lane 622 and can proceed with sign verification and subsequent vehicle processing (e.g., cipher information for sign 632) using the cipher information. It should be understood that the decryption of the cipher data will be performed after signature verification, as described above regarding... Figure 5B The discussion is ongoing. In some examples, cipher flag information and cipher pole information can be verified simultaneously or in any order; however, any verified cipher flag can be used in response to cipher pole information verification for subsequent vehicle processing (i.e., when cipher information is verified from a reference pole (e.g., pole 622) in the driving lane (e.g., lane 621 in this example).

[0131] In some examples, non-reference poles 624, 626, and 628 relative to lane 621 may also transmit and / or broadcast their respective pole and sign cipher information, which vehicle 620 can receive. However, the private key imported based on the reference pole position information determined by the vehicle for lane 621 may not be able to successfully decrypt the cipher pole information from non-reference poles 624, 626, and 628. Therefore, the cipher sign and pole information from non-reference traffic poles 624, 626, and 628 can be ignored by vehicle 620 traveling in lane 621. Thus, the cipher information from reference pole 622 for lane 621 can be selectively identified by vehicle 620 traveling in lane 621 and used for associated sign (632) verification and subsequent vehicle processing.

[0132] Figure 6B Another exemplary scenario of intersection 600 is shown. In this scenario, traffic pole 624 is rotated so that traffic pole 624 and its associated sign 634 are detected and identified by one or more cameras and CVTSRs of the vehicle. Furthermore, traffic pole 622 for lane 621, along with its associated sign 632, is also detected. Additionally, cipher information 640 from traffic pole 622 and cipher information 650 from traffic pole 634 are received at vehicle 620. Furthermore, the vehicle's cipher verification of traffic signs 634 and 632 can indicate that both signs are trusted (i.e., signature verification and decryption were successful). To determine which traffic sign (634 or 632) should be considered for subsequent vehicle operations, vehicle 620 can identify which traffic pole is the reference pole for driving lane 621, thus identifying the rotated traffic pole. Therefore, vehicle 620 can use the pole position information of the reference pole (identified using the vehicle navigation system) to import the private key for the reference pole for driving lane 621, as described above. Figure 6A As described in [the document]. The private key imported by vehicle 620 can be used to successfully decrypt encrypted pole data transmitted from the reference pole and received at vehicle 620. Therefore, the encrypted pole information included in the encrypted information 640 from pole 622 is successfully decrypted by the imported private key, while the encrypted pole information of pole 624 included in the encrypted information 650 from pole 624 is not successfully decrypted by the private key. Therefore, pole 624 can be marked as rotated. Therefore, in response to the detection and identification of one or more poles and associated markers via the vehicle's camera and CVTSR, when the decryption of the identified traffic pole using the private key obtained from the vehicle navigation system fails, the identified traffic pole with a verified signature that failed decryption may be marked as rotated.

[0133] In some examples, non-reference poles 626 and 628, which are not rotated relative to lane 621, may also transmit and / or broadcast their respective pole and sign cipher information, which vehicle 620 can receive. However, the private key imported based on the reference pole position information determined by the vehicle for lane 621 may fail to decrypt the cipher pole information from non-reference poles 626 and 628. Therefore, the cipher sign and pole information from non-reference traffic poles 626 and 628 can be ignored by vehicle 620 traveling in lane 621 and not marked as rotated because the vehicle camera does not recognize the traffic signs 636 and 638 associated with non-reference poles 626 and 628 (e.g., because signs 636 and 638 are not facing the vehicle and therefore the signals are not in the field of view of the vehicle camera). As described above, pole 624 can be identified as rotated. Thus, the cipher information from reference pole 622 for lane 621 can be selectively recognized by vehicle 620 traveling in lane 621 and used for associated sign (632) verification and subsequent vehicle processing.

[0134] exist Figure 6C Another exemplary scenario is depicted, in which traffic pole 622 and its associated sign 632 are knocked down, and traffic pole 624 and its associated sign 634 turn into lane 621. Vehicle 620 can identify and recognize traffic pole 624 and its associated sign. Furthermore, vehicle 620 can receive cipher information 650 from traffic pole 624 and can import a private key corresponding to a reference pole in lane 621, as described above. However, the private key may not be usable for successfully decrypting the cipher information (for pole 624) included in cipher information 650; therefore, pole 624 may be marked as rotated, and cipher information 650 may not be considered for any additional sign verification and / or vehicle operation processing (e.g., ADAS / autonomous operation). Furthermore, in response to the failure to identify and / or recognize a reference pole for lane 621 in the expected geographic area by the camera and / or CVTSR, and / or the failure to receive a broadcast from the reference pole in the expected geographic area, the vehicle computing system may perform one or more vehicle operations (e.g., slowing down at an intersection and using computer vision and / or other sensors (e.g., LIDAR) to detect objects relative to the vehicle's travel path and act accordingly).

[0135] The disclosed traffic pole attack detection system utilizes multiple security layers—computer vision-based identification, navigation-based pole position detection, and cryptographic verification—to authenticate detected traffic signals and poles. This method improves the accuracy and reliability of traffic sign detection in vehicles, which in turn enhances the accuracy and reliability of vehicle control based on detected traffic signs. Furthermore, the method detects misleading traffic poles, further improving the accuracy and reliability of traffic sign detection in vehicles. Therefore, by detecting misleading traffic poles, the accuracy and reliability of vehicle control are further enhanced.

[0136] As described above, the method can be performed at least in part within a vehicle using an onboard computing system as an emergency vehicle alarm system.

[0137] Figure 7 An exemplary partial view of an environment of one type of emergency vehicle alarm system (the interior of the passenger compartment 700 of a vehicle 702 in which the driver and / or one or more passengers may sit) is shown. Figure 7 The vehicle 702 may include Figure 1 Vehicle 102 and / or Figure 2 Examples of vehicle 212 and / or examples thereof.

[0138] As shown in the figure, the instrument panel 706 may include various displays and controls accessible to the driver (also referred to as the user) of the vehicle 702. For example, the instrument panel 706 may include a touchscreen 708 of an in-vehicle computing system 709 (e.g., an infotainment system), an audio system control panel, and an instrument cluster 710.

[0139] In some embodiments, one or more hardware components of the in-vehicle computing system 709, such as a touchscreen 708, a display screen, various control dials, knobs and buttons, memory, a processor, and any interface components (e.g., connectors or ports), may form an integrated host unit mounted in the vehicle's dashboard 706. The host unit may be fixedly or removably attached to the dashboard 706. In additional or alternative embodiments, one or more hardware components of the in-vehicle computing system may be modular and may be mounted in multiple locations within the vehicle.

[0140] The passenger compartment 700 may include one or more sensors for monitoring the vehicle, the user, and / or the environment. For example, the passenger compartment 700 may include one or more microphones to receive user input in the form of voice commands and / or to measure ambient noise, etc., inside or outside the passenger compartment 700. It should be understood that the aforementioned sensors and / or one or more additional or alternative sensors may be located at any suitable location within the vehicle. For example, sensors may be located in the engine compartment, on the outer surface of the vehicle, and / or other suitable locations to provide information about vehicle operation, environmental conditions of the vehicle, the user of the vehicle, etc. Information about the vehicle's environmental conditions, vehicle status, or the vehicle driver may also be received from sensors located outside the vehicle or sensors separate from the vehicle (i.e., not part of the vehicle system) such as sensors coupled to external device 650 and / or moving device 728.

[0141] The vehicle compartment 700 may also include one or more user objects, such as mobile devices 728, stored in the vehicle before, during, and / or after travel. Mobile devices 728 may include smartphones, tablets, laptops, portable media players, and / or any suitable mobile computing device. Mobile devices 728 may be connected to an in-vehicle computing system via a communication link 730. The communication link 730 may be wired (e.g., via Universal Serial Bus [USB], Mobile High Definition Link [MHL], High Definition Multimedia Interface [HDMI], Ethernet, etc.) or wireless (e.g., via Bluetooth, Wi-Fi, Wi-Fi Direct, Near Field Communication [NFC], cellular connection, etc.) and configured to provide bidirectional communication between the mobile device and the in-vehicle computing system. Mobile devices 728 may include one or more wireless communication interfaces for connecting to one or more communication links (e.g., one or more of the exemplary communication links described above). The wireless communication interface may include: one or more physical devices, such as antennas or ports, coupled to data lines to carry transmitted or received data; and one or more modules / drivers for operating said physical devices according to other devices in the mobile device. For example, communication link 730 can provide sensor and / or control signals from various vehicle systems (such as vehicle audio systems, sensor subsystems, etc.) and touchscreen 708 to mobile device 728, and can provide control and / or display signals from mobile device 728 to in-vehicle systems and touchscreen 608. Communication link 730 can also provide power from the in-vehicle power supply to mobile device 728 to charge the internal battery of the mobile device.

[0142] The in-vehicle computing system 709 can also be communicatively coupled to additional devices, such as one or more external devices 750, that are operated and / or accessed by a user but located outside the vehicle 702. In the depicted embodiments, the external devices are located outside the vehicle 702; however, it will be understood that in alternative embodiments, the external devices may be located inside the vehicle compartment 700. The external devices may include server computing systems, personal computing systems, portable electronic devices, electronic wristbands, electronic headbands, portable music players, electronic activity trackers, pedometers, smartwatches, GPS systems, etc. The external devices 750 may be connected to the in-vehicle computing system via a communication link 736, which may be wired or wireless, as discussed with reference to communication link 730, and the external devices are configured to provide bidirectional communication between the external devices and the in-vehicle computing system. For example, the external device 750 may include one or more sensors, and the communication link 736 may transmit sensor output from the external device 750 to the in-vehicle computing system 709 and the touchscreen 708. The external device 750 may also store and / or receive information about navigation map data, image feature mapping data, etc., and may transmit such information from the external device 750 to the in-vehicle computing system 709 and / or the touch screen 708.

[0143] The in-vehicle computing system 709 can analyze input received from external device 750, mobile device 728, and / or other input sources, and provide output via touchscreen 708 and / or speaker 712, communicate with mobile device 728 and / or external device 750, and / or perform other actions based on evaluation. In some embodiments, all or part of the evaluation may be performed by mobile device 728 and / or external device 750. In some embodiments, external device 750 may include an in-vehicle computing device of another vehicle.

[0144] In some implementations, one or more of the external devices 750 may be communicatively coupled to the in-vehicle computing system 709 via mobile device 728 and / or another external device 750. For example, communication link 736 may communicatively couple external device 750 to mobile device 728, such that output from external device 750 is relayed to mobile device 728. Data received from external device 750 may then be aggregated at mobile device 728 with data collected by mobile device 728, and the aggregated data may then be transmitted to in-vehicle computing system 709 and touchscreen 708 via communication link 730. Similar data aggregation may occur at a server system and then be transmitted to in-vehicle computing system 709 and touchscreen 708 via communication links 736 / 730.

[0145] Figure 7 A block diagram of an onboard computing system 800 configured and / or integrated within a vehicle 801 is shown. The onboard computing system 800 may be... Figure 7 Examples of the in-vehicle computing system 709 and / or methods described herein in some embodiments are included. In some examples, the in-vehicle computing system may be a vehicle infotainment system configured to provide information-based media content (audio and / or visual media content, including entertainment content, navigation services, etc.) to vehicle users to enhance the operator's in-vehicle experience. The vehicle infotainment system may include or be coupled to various vehicle systems, subsystems, hardware components, and software applications and systems integrated into or capable of being integrated into vehicle 801 to enhance the in-vehicle experience for the driver and / or passengers.

[0146] The in-vehicle computing system 800 may include one or more processors, including an operating system processor 814 and an interface processor 820. The operating system processor 814 can execute an operating system on the in-vehicle computing system and control the input / output, display, playback, and other operations of the in-vehicle computing system. The interface processor 820 can interface with the vehicle control system 830 via an in-vehicle communication module 822.

[0147] The in-vehicle communication module 822 can output data to other vehicle systems 831 and vehicle control elements 861, and also receive data input from other vehicle components and systems 831, 861, for example, via the vehicle control system 830. When outputting data, the in-vehicle communication module 822 can provide signals via a bus corresponding to any state of the vehicle, the vehicle's surrounding environment (e.g., as measured by one or more microphones or cameras mounted on the vehicle), or the output of any other information source connected to the vehicle. For example, vehicle data output may include analog signals (such as current speed), digital signals provided by individual information sources (such as clocks, thermometers, position sensors such as GPS sensors, etc.), and digital signals propagated via vehicle data networks (such as the Engine Controller Area Network (CAN) bus for transmitting engine-related information, and / or the Audio Video Bridge (AVB) network for transmitting vehicle information). For example, the on-board computing system can retrieve the vehicle's current speed estimated by wheel sensors, the vehicle's current position provided by GPS sensors, and the vehicle's current trajectory provided by one or more inertial measurement sensors from the engine CAN bus to determine the vehicle's estimated path. In addition, other interface devices such as Ethernet may be used without departing from the scope of this disclosure.

[0148] The in-vehicle computing system 800 may include a non-volatile storage device 808 to store data, such as instructions executable by processors 814 and 820, in a non-volatile form. Storage device 808 may store application data to enable the in-vehicle computing system 800 to perform any of the methods described above and / or run applications to connect to a cloud-based server and / or collect information for transmission to the cloud-based server. Connection to the cloud-based server may be facilitated via an external communication module 824. The application may retrieve information aggregated from vehicle systems / sensors, input devices (e.g., user interface 818), devices communicating with the in-vehicle computing system (e.g., mobile devices connected via Bluetooth links), etc. The in-vehicle computing system 800 may also include volatile memory 816. Volatile memory 816 may be random access memory (RAM). Non-transitory storage devices, such as non-volatile storage device 808 and / or volatile memory 816, may store instructions and / or code that, when executed by a processor (e.g., operating system processor 814 and / or interface processor 820), control the in-vehicle computing system 800 to perform one or more of the actions described in this disclosure.

[0149] Microphone 802 may be included in the vehicle computing system 800 to measure ambient noise inside the vehicle, ambient noise outside the vehicle, etc. One or more additional sensors may be included in and / or communicatively coupled to the sensor subsystem 810 of the vehicle computing system 800. For example, sensor subsystem 810 may include and / or be communicatively coupled to cameras, such as a rear-view camera for assisting a user in parking the vehicle, a cabin camera for identifying the user, and / or a forward-view camera for assessing the quality of the road ahead. As mentioned above, the cameras may also be used to provide images to a computer vision-based traffic sign detection module. The sensor subsystem 810 of the vehicle computing system 800 can communicate with and receive input from various vehicle sensors and may further receive user input. While some vehicle system sensors may communicate with sensor subsystem 810 individually, other sensors may communicate with both sensor subsystem 810 and vehicle control system 830, or indirectly with sensor subsystem 810 via vehicle control system 830. The sensor subsystem 810 can be used as an interface (e.g., a hardware interface) and / or processing unit for receiving and / or processing signals received from one or more sensors described in this disclosure.

[0150] The navigation subsystem 811 of the in-vehicle computing system 800 can generate and / or receive navigation information, such as location information (e.g., via GPS sensors and / or other sensors from sensor subsystem 810), route guidance, traffic information, point-of-interest (POI) identification, and / or provide other navigation services to the driver. The navigation subsystem 811 may include an inertial navigation system, which can further determine the vehicle's position, orientation, and speed via motion and rotation sensor inputs. Examples of motion sensors include accelerometers, while examples of rotation sensors include gyroscopes. The navigation subsystem 811 can communicate with the motion and rotation sensors included in the sensor subsystem 810. Alternatively, the navigation subsystem 811 may include motion and rotation sensors and determine movement and rotation based on the output of these sensors. The navigation subsystem 811 can transmit and receive data from a cloud-based server and / or external navigation services via an external communication module 824.

[0151] During vehicle operation, the navigation subsystem can obtain the vehicle's location information and current lane information as described above via GPS sensors and / or other sensors of the vehicle system. Based on the location and lane information, the navigation subsystem can identify a reference traffic pole in the current lane. The onboard computing system can then access the vehicle's access replay protected memory block and import the private key corresponding to the identified reference traffic pole. The private key of the identified reference traffic pole can then be used to decrypt the transmitting / broadcast antenna (such as...) at the vehicle's antenna from the intended reference traffic pole. Figure 2 The onboard computing system 700 receives the cipher pole information from the antenna 208 in the vehicle. The onboard computing system 700 can also access the vehicle's write-protected memory to import a public key for verifying the signature of the cipher pole information (e.g., to verify that no changes have been made to the data after the cipher pole information was signed). After verifying the signature of the received cipher pole information, the onboard computing system can perform decryption of the cipher pole data in a secure execution environment using a private key imported for the identified reference pole. If decryption is successful, the reference pole is expected to be a reference traffic pole for the current driving lane, and after sign verification as described herein, other cryptographic information (e.g., cipher flag information) from the antenna of the confirmed reference traffic pole can be considered for subsequent vehicle operations.

[0152] The external device interface 812 of the in-vehicle computing system 800 may be capable of coupling to and / or communicating with one or more external devices 840 located outside the vehicle 801. Although the external devices are shown as being located outside the vehicle 801, it will be understood that they may be temporarily housed within the vehicle 801, such as when a user is operating the vehicle 801 while simultaneously operating the external devices. In other words, the external devices 840 are not integrated with the vehicle 801. The external devices 840 may include mobile devices 842 (e.g., connected via Bluetooth, NFC, Wi-Fi Direct, or other wireless connections) or alternative devices 852 with Bluetooth functionality. The mobile device 842 may be a mobile phone, smartphone, wearable device / sensor, or other portable electronic device capable of communicating with the in-vehicle computing system via wired and / or wireless communication. Other external devices include external services 846. For example, the external devices may include external devices separate from and located outside the vehicle. Other external devices include external storage devices 854, such as solid-state drives, pen drives, USB drives, etc. Without departing from the scope of this disclosure, the external device 840 may communicate wirelessly or via a connector with the vehicle computing system 800. For example, the external device 840 may communicate with the vehicle computing system 800 via an external device interface 812 via a network 860, a universal serial bus (USB) connection, a direct wired connection, a direct wireless connection, and / or other communication links.

[0153] One or more applications 844 may be operable on mobile device 842. As an example, mobile device application 844 may be operable to monitor the vehicle's environment (e.g., collect audio and / or visual data of the vehicle environment) and / or process audio and / or visual data received from vehicle sensors. The collected / processed data may be transmitted by application 844 to external device interface 812 via network 860. Similarly, one or more applications 848 may be operable on external service 846. As an example, external service application 848 may be operable to aggregate and / or analyze data from multiple data sources. For example, external service application 848 may aggregate data (e.g., sensor data, log files, user input, etc.) from in-vehicle computing systems, etc. The collected data may be transmitted to another device and / or analyzed by an application to determine the location of emergency vehicles and / or determine recommended course of action to avoid interfering with emergency vehicles.

[0154] The vehicle control system 830 may include controls for controlling aspects of various vehicle systems 831 involved in different in-vehicle functions. These may include, for example, controlling aspects of the vehicle audio system 832 to provide audio output to vehicle occupants. The audio system 832 may include one or more acoustic reproduction devices, including electromagnetic transducers such as speakers. In some examples, the in-vehicle computing system may be the only audio source for the acoustic reproduction devices, or there may be other audio sources connected to the audio reproduction system (e.g., external devices such as mobile phones) to produce audio output, such as one or more of the audible alarms described above. The connection of any such external device to the audio reproduction device may be analog, digital, or any combination of analog and digital technologies.

[0155] The vehicle control system 830 may also include controls for adjusting settings of various vehicle controls 861 (or vehicle system control elements) (such as steering controls 862, braking controls 863, and lighting controls 864 (e.g., cabin lighting, exterior vehicle lighting, light signals)) associated with auxiliary components within the engine and / or vehicle compartment. For example, the vehicle control system 830 may include controls for adjusting vehicle controls 861 to present one or more of the aforementioned alarms (e.g., adjusting cabin lighting, automatically controlling steering or braking to maneuver according to detected traffic signs, etc.). Vehicle controls 861 may also include internal engine and vehicle operation controls (e.g., engine controller module, actuators, valves, etc.) configured to receive instructions via the vehicle's CAN bus to change the operation of one or more of the engine, exhaust system, transmission, and / or other vehicle systems (e.g., to provide the aforementioned alarms). Control signals may also control audio output (e.g., audible alarms) at one or more speakers of the vehicle's audio system 832.

[0156] The in-vehicle computing system 800 may also include an antenna 806, which can be communicatively coupled to an external device interface 812 and / or an external communication module 824. The in-vehicle computing system may receive positioning signals such as GPS signals and / or wireless commands via the antenna 806 or via infrared or other means through suitable receiving devices.

[0157] Users can control one or more components of the in-vehicle computing system 800 via user interface 818. User interface 818 may include a graphical user interface presented on a touchscreen such as touchscreen 608 of FIG. 6, and / or user-actuated buttons, switches, knobs, dials, sliders, etc. Users can also interact with one or more applications of the in-vehicle computing system 800 and the mobile device 842 via user interface 818. Notifications and other messages (e.g., alarms) and navigation assistance may be displayed to the user on the display of the user interface. User preferences / information and / or responses to presented alarms may be executed via user input to the user interface.

[0158] This disclosure also provides support for a traffic pole detection system in a vehicle, the system comprising: a navigation sensor, a communication system, a processor, and a storage device that stores instructions in a non-transitory memory, the instructions being executable by the processor to: determine the current location information of the vehicle, the current location information including lane information of the driving lane in which the vehicle is currently traveling; obtain reference traffic pole information for the driving lane based on the vehicle's current location information; receive cipher pole data via the communication system from a transmitter associated with a anticipated reference traffic pole, the anticipated reference traffic pole including associated traffic signs mounted thereon, the cipher pole data including a cipher representation of the anticipated reference traffic pole; and selectively control one or more vehicle systems of the vehicle based on cipher verification of the anticipated reference traffic pole using the obtained reference traffic pole information. In a first example of the system, the cipher representation of the anticipated reference traffic pole includes a unique pole ID associated with the anticipated reference traffic pole, the unique pole ID being encrypted using a first public key. In a second example, which optionally includes the first example, the cryptographic representation of the intended reference traffic pole is digitally signed using a first private key, accessible by the transmitter associated with the intended reference traffic pole. In a third example, which optionally includes the first and second examples, cryptographic verification of the intended reference pole includes obtaining a second private key associated with the reference traffic pole, accessible by the processor, and decrypting received pole data using the second private key. In a fourth example, which optionally includes the first to third examples, the second private key is stored in a replay-protected memory block of the storage device, and the pole data is wirelessly broadcast from an antenna associated with the intended traffic pole. In a fifth example, which optionally includes the first to fourth examples, cryptographic verification of the intended reference pole includes performing verification of the digital signature of the pole data using a second public key, retrieved based on an association between the first private key and a stored ID locally stored in the vehicle corresponding to the intended reference traffic pole. In a sixth example, which optionally includes the first to fifth examples of the system, the expected traffic pole is determined to be the reference traffic pole in response to successfully decrypting the cipher pole data using the second private key corresponding to the reference traffic pole to retrieve the unique pole ID. In a seventh example, which optionally includes the first to sixth examples of the system, the expected reference traffic pole is further determined to be the reference traffic pole in response to determining that the unique pole ID retrieved by decrypting the cipher pole data using the second private key is the same as a stored pole ID associated with the expected reference traffic pole.In an eighth example, which optionally includes the first to seventh examples of the system, one or more vehicle systems that selectively control the vehicle based on the password verification of the expected reference traffic pole include adjusting the operation of the vehicle to comply with regulations associated with the traffic sign installed on the expected reference traffic pole in response to determining that the expected reference traffic pole has been password verified as the reference traffic pole, and not adjusting the operation of the vehicle based on the expected reference traffic pole in response to determining that the expected reference traffic pole has not been password verified as the reference traffic pole.

[0159] This disclosure also provides support for a method of verifying traffic poles using a vehicle, the method comprising: determining the vehicle's current location information; obtaining reference traffic pole information based on the vehicle's current location information; wirelessly receiving cipher information via the vehicle's communication system from a transmitter associated with a traffic pole on which traffic signs are mounted, the cipher information including a pole cipher representation and a sign cipher representation of the traffic signs; and selectively controlling one or more vehicle systems of the vehicle based on a first cipher verification of the traffic pole using the pole cipher representation and the reference traffic pole information. In a first example of the method, the pole cipher representation includes a unique pole ID associated with the traffic pole, and wherein the sign cipher representation includes a unique sign ID associated with the traffic sign mounted on the traffic pole. In a second example of the method, optionally including the first example, the cipher information includes a first encryption of the unique pole ID, which is encrypted using a first pole public key of an encryption algorithm, and wherein the cipher information further includes a second encryption of the unique sign ID, which is encrypted using the first sign public key of the encryption algorithm. In a third example, optionally including the first and second examples of the method, the cryptographic information further includes a combination of the first encryption and a first digital signature of the unique pole ID, and wherein the cryptographic information further includes a combination of the second encryption and a second digital signature of the unique identifier ID, each of the first and second digital signatures being generated by applying an encryption signature algorithm to the first encryption of the unique pole ID using a first pole private key and to the second encryption of the unique identifier ID using a second identifier private key, respectively. In a fourth example, optionally including the first to third examples of the method, the first cryptographic verification of the traffic pole includes obtaining a second pole private key associated with the reference pole, the second pole private key being accessible by the vehicle's processor, and decrypting the first encryption of the unique pole ID using the second pole private key, and wherein the first cryptographic verification of the traffic pole further includes performing signature verification on the pole cryptographic representation using a second pole public key of the encryption algorithm, the second pole public key being retrieved from the vehicle's integrity check storage. In a fifth example, which optionally includes the first to fourth examples, the traffic pole is determined to be the reference pole in response to the following: successful decryption of the first encryption of the unique pole ID using the second pole private key corresponding to the reference traffic pole, and successful verification of the first signature of the cryptographic information using the second pole public key.In a sixth example, which optionally includes the first to fifth examples, the method further includes: in response to successful decryption of the first encryption of the unique pole ID, performing a second cryptographic verification of the traffic sign mounted on the cryptographically verified traffic pole; and in response to successful execution of the second cryptographic verification, adjusting the operation of the vehicle to comply with regulations associated with the traffic sign; and in response to determining that the first encryption of the unique pole ID has not been successfully decrypted, not performing the second cryptographic verification of the traffic sign and not adjusting the operation of the vehicle based on the traffic sign.

[0160] This disclosure also provides support for a method for identifying a reference traffic pole among two or more traffic poles in a vehicle's environment, the method comprising: obtaining reference traffic pole position information based on the vehicle's location information and the vehicle's driving lane information from the vehicle's navigation system; obtaining a private key for the reference traffic pole based on the reference traffic pole position information; receiving corresponding cipher pole data from each of the two or more traffic poles via the vehicle's wireless communication system; decrypting each of the corresponding cipher pole data using the private key; identifying the reference pole of the vehicle based on successful decryption of the cipher pole data from one of the two or more traffic poles; and selectively controlling one or more vehicle systems of the vehicle based on the identified reference pole. In a first example of the method, the method further includes: during a first condition, wherein the vehicle's image sensor detects and identifies a reference traffic sign mounted on an identified reference pole, receives a coded representation of the reference sign from a transmitter associated with the reference traffic pole along with the coded representation of the reference traffic pole, and selectively controls one or more vehicle systems of the vehicle based on coded verification of the identified reference sign using the coded representation of the reference sign; and during a second condition, wherein in addition to the reference traffic sign, the image sensor also detects and identifies a second traffic sign, selectively controls one or more vehicle systems of the vehicle based on coded verification of the identified reference sign using the coded representation of the reference sign, and marks a second traffic pole mounted on the second sign as rotated, wherein the second traffic pole is from one of the two or more traffic poles that have not been coded as the reference traffic pole. In a second example of the method, which optionally includes the first example, selectively controlling one or more vehicle systems of the vehicle based on the coded verification of the identified reference sign includes adjusting the operation of the vehicle to comply with regulations associated with the reference traffic sign. In a third example, which optionally includes the first and second examples, the identification of the reference pole for the vehicle is further based on performing signature verification on the cryptographic pole data of the identified reference pole using a public key retrieved from the vehicle's integrity check storage and associated with the reference pole.

[0161] The description of the implementation scheme has been presented for illustrative and descriptive purposes. Suitable modifications and changes to the implementation scheme can be made in light of the foregoing description, or such suitable modifications and changes can be obtained through practical methods. For example, unless otherwise indicated, one or more of the described methods can be performed by suitable means and / or combinations of means, such as those referenced in [reference to...]. Figure 7 and Figure 8The described in-vehicle computing systems 709 and / or 800. The methods can be executed by using a combination of one or more logic devices (e.g., processors) and one or more additional hardware elements, such as storage devices, memories, hardware network interfaces / antennas, switches, actuators, clock circuits, etc. The described methods and associated actions can also be performed in various orders other than those described in this application, in parallel, and / or simultaneously. The described systems are exemplary in nature and may include additional elements and / or omit elements. The subject matter of this disclosure includes all novel and non-obvious combinations and sub-combinations of the various systems and configurations disclosed with other features, functions, and / or properties.

[0162] As used in this application, an element or step described in the singular and preceded by the words "an" or "a" should be understood as not excluding multiple said elements or steps, unless such exclusion is specified. Furthermore, references to "an embodiment" or "an example" in this disclosure are not intended to exclude the existence of additional embodiments that also incorporate the described features. The terms "first," "second," and "third," etc., are used merely as illustrative marks and are not intended to impose numerical requirements or a particular order on their objects. The appended claims specifically point to subject matter deemed novel and not obvious from the foregoing disclosure.

Claims

1. A traffic pole detection system for a vehicle, the traffic pole detection system comprising: Navigation sensors; Communication systems; processor; and A storage device that stores instructions in a non-transitory memory, the instructions being executable by the processor to perform the following operations: Identifying expected reference traffic poles, wherein identifying expected reference traffic poles includes: image the environment of the vehicle using a camera installed in or on the vehicle, detecting traffic poles present in the image from the camera, determining the current position information of the vehicle, the current position information including lane information of the driving lane in which the vehicle is currently traveling, and obtaining reference traffic pole information of the driving lane based on the current position information of the vehicle. In response to the identification of the intended reference traffic pole, cipher pole data is received via the communication system from a transmitter associated with the intended reference traffic pole, the intended reference traffic pole including associated traffic signs mounted thereon, the cipher pole data including a cipher representation of the intended reference traffic pole; and Selectively control one or more vehicle systems of the vehicle based on password verification of the intended reference traffic pole using the obtained reference traffic pole information; The password verification of the intended reference traffic pole is performed after successful password verification of one or more of the password pole data and the associated password flag data.

2. The traffic pole detection system of claim 1, wherein the cryptographic representation of the intended reference traffic pole includes a unique pole ID associated with the intended reference traffic pole, the unique pole ID being encrypted using a first public key. in, The processor can also perform the following operations: In response to successful password verification of the intended reference traffic pole and the relevant traffic sign installed on the intended reference traffic pole using the obtained reference traffic pole information, an indicator is output indicating that the relevant traffic sign has been verified and the intended reference traffic pole is trustworthy for traffic in the driving lane.

3. The traffic pole detection system of claim 2, wherein the cryptographic representation of the intended reference traffic pole is digitally signed with a first private key, the first private key being accessible by the transmitter associated with the intended reference traffic pole.

4. The traffic pole detection system of claim 3, wherein the password verification of the intended reference traffic pole includes: Obtain a second private key associated with the reference traffic pole, the second private key being accessible by the processor; And the received cipher data is decrypted using the second private key.

5. The traffic pole detection system of claim 4, wherein the second private key is stored in a replay-protected memory block of the storage device, and wherein the cryptographic pole data is wirelessly broadcast from an antenna associated with the intended reference traffic pole.

6. The traffic pole detection system of claim 3, wherein the cryptographic verification of the intended reference traffic pole includes performing verification of a digital signature of the cryptographic pole data using a second public key, the second public key being retrieved based on the association between the first private key and a stored ID locally stored in the vehicle and corresponding to the intended reference traffic pole.

7. The traffic pole detection system of claim 4, wherein the expected reference traffic pole is determined to be the reference traffic pole by cryptographic verification in response to successfully decrypting the cryptographic pole data using a second private key corresponding to the reference traffic pole to retrieve the unique pole ID.

8. The traffic pole detection system of claim 7, further comprising determining, in response to determining that the unique pole ID retrieved by decrypting the cryptographic pole data using the second private key is the same as a stored pole ID associated with the expected reference traffic pole, that the expected reference traffic pole is cryptographically verified as the reference traffic pole.

9. The traffic pole detection system of claim 1, wherein one or more vehicle systems that selectively control the vehicle based on the cryptographic verification of the intended reference traffic pole include: The vehicle's operation is adjusted to comply with regulations associated with the traffic sign installed on the expected reference traffic pole in response to determining that the expected reference traffic pole has been verified as a reference traffic pole by a password; and the vehicle's operation is not adjusted based on the expected reference traffic pole in response to determining that the expected reference traffic pole has not been verified as a reference traffic pole by a password. Obtaining the reference traffic pole information includes accessing a traffic pole database, which stores the geographical locations and lane reference information of multiple traffic poles, wherein the lane reference information indicates which lane or lanes each traffic pole is intended to guide. In this process, cipher pole data and associated cipher marker data are transmitted, while the display of relevant traffic signs changes, so that updated cipher marker data corresponding to the updated traffic sign signals are transmitted together with the cipher pole data.

10. A method for verifying traffic poles using vehicles, the method comprising: Identifying a anticipated reference traffic pole, wherein identifying the anticipated reference traffic pole includes: image the environment of the vehicle using a camera mounted in or on the vehicle, detecting traffic poles present in the image from the camera, determining the current position information of the vehicle, and obtaining reference traffic pole information based on the current position information of the vehicle. In response to the identification of the intended reference traffic pole, coded information is wirelessly received via the vehicle's communication system from a transmitter associated with the traffic pole on which traffic signs are mounted, the coded information including a pole code representation of the traffic pole and a sign code representation of the traffic signs; and One or more vehicle systems of the vehicle are selectively controlled based on a first password verification of the traffic pole using the pole password representation and the reference traffic pole information; The password verification of the intended reference traffic pole is performed after successful password verification of one or more of the password pole data and the associated password flag data.

11. The method of claim 10, wherein the pole password representation includes a unique pole ID associated with the traffic pole, and wherein the sign password representation includes a unique sign ID associated with the traffic sign mounted on the traffic pole.

12. The method of claim 11, wherein the cryptographic information includes a first encryption of the unique stick ID, which is encrypted using a first stick public key of an encryption algorithm; and wherein the cryptographic information further includes a second encryption of the unique identifier ID, which is encrypted using a first identifier public key of the encryption algorithm.

13. The method of claim 12, wherein the cryptographic information further comprises a combination of the first encryption and the first digital signature of the unique pole ID; and wherein the cryptographic information further comprises a combination of the second encryption and the second digital signature of the unique identifier ID, each of the first digital signature and the second digital signature being generated by applying an encryption signature algorithm to the first encryption of the unique pole ID using the first pole private key and applying an encryption signature algorithm to the second encryption of the unique identifier ID using the second identifier private key, respectively.

14. The method of claim 13, wherein the first password verification of the traffic pole comprises: Obtain a second pole private key associated with a reference traffic pole, which can be accessed by the vehicle's processor; The first encryption of the unique pole ID is decrypted using the second pole private key; and the first password verification of the traffic pole further includes performing a signature verification on the pole password representation using the second pole public key of the encryption algorithm, the second pole public key being retrieved from the vehicle's integrity check storage.

15. The method of claim 14, wherein the traffic pole is determined to be the reference traffic pole in response to any of the following: The first encryption of the unique pole ID was successfully decrypted using the second pole private key corresponding to the reference traffic pole, and The first signature of the cryptographic information was successfully verified using the second public key.

16. The method of claim 15, further comprising, in response to successful decryption of the first encryption of the unique pole ID, performing a second cryptographic verification of the traffic sign mounted on the cryptographically verified traffic pole; And in response to the successful execution of the second password verification, the operation of the vehicle is adjusted to comply with the regulations associated with the traffic sign; Furthermore, in response to determining that the first encryption of the unique pole ID has not been successfully decrypted, the second password verification of the traffic sign is not performed and the operation of the vehicle is not adjusted based on the traffic sign.

17. A method for identifying a reference traffic pole among two or more traffic poles in a vehicle environment, the method comprising: The reference traffic pole position information is obtained based on the vehicle's location information and the vehicle's driving lane information from the vehicle's navigation system; The private key of the reference traffic pole is obtained based on the location information of the reference traffic pole; The corresponding cipher pole data is received from each of the two or more traffic poles via the vehicle's wireless communication system; Decrypt each of the corresponding cipher data using the private key; The reference traffic pole of the vehicle is identified based on the successful decryption of the cipher data from one of the two or more traffic poles; as well as One or more vehicle systems of the vehicle are selectively controlled based on the identified reference traffic poles; The second traffic pole is marked as rotated or physically misaligned, wherein the second traffic pole is one of the two or more traffic poles that have not been password verified as the reference traffic pole; The password verification of the reference traffic pole is performed after successful password verification of one or more of the password pole data and the associated password flag data.

18. The method of claim 17, wherein selectively controlling one or more vehicle systems of the vehicle based on the cryptographic verification of the identified reference traffic sign includes adjusting the operation of the vehicle to comply with regulations associated with the reference traffic sign.

19. The method of claim 18, wherein the identification of the reference traffic pole for the vehicle is further based on performing signature verification on the cryptographic pole data of the identified reference traffic pole using a public key retrieved from the vehicle's integrity check storage and associated with the reference traffic pole.

Images