Patent Description:
Motor vehicles, such as autonomous and/or non-autonomous vehicles, (e.g., automobiles, cars, trucks, buses, etc.) can use sensors and/or cameras to obtain information about their surroundings to operate safely. For example, autonomous vehicles can control their speed and/or direction and can recognize and/or avoid obstacles and/or hazards based on information obtained from sensors and/or cameras. For example, vehicles may use light detection and ranging (LIDAR), vehicle-to-everything (V2X), RADAR, and/or SONAR detection techniques, among others, to obtain information about their surroundings. As used herein, an autonomous vehicle can be a vehicle in which at least a portion of the decision-making and/or control over vehicle operations is controlled by computer hardware and/or software/firmware, as opposed to a human operator. For example, an autonomous vehicle can be a driverless vehicle.

Document <CIT> forms part of the relevant background art and discloses an automotive optical communication system.

Secure vehicular services communication is described herein. An example apparatus can include a processor and an external communication component. The external communication component can be coupled to the processor and can be configured to, in response to determining a vehicular entity is within a particular proximity to the external communication component, generate an external private key and an external public key, provide the external public key and data to a vehicular communication component associated with the vehicular entity, receive data from the vehicular communication component in response to providing the external public key and data to the vehicular communication component, decrypt the received data using the external private key, and provide a service to the vehicular entity based on the decrypted received data.

In some previous approaches, vehicles have used cameras and sensors to obtain information about their surroundings. However, the operation of these cameras and sensors can depend on weather conditions and can be hampered by inclement weather conditions. External communication components can provide redundancy and/or additional transportation information that can improve vehicle operation, resulting in technological improvements to the vehicle. For example, information provided by the external communication components that can be positioned on a transportation assistance entity can be used if vehicular cameras and/or sensors fail, such as due to weather-related events.

In some previous approaches, vehicles have used sensors, such as vehicle to infrastructure (V2I) sensors, to obtain route information from external communication components along a route, such as overhead radio frequency identification (RFID) readers, cameras, traffic lights, lane markers, streetlights, signage, parking meters, or the like. However, in these previous approaches, the communication between a vehicle and an external communication component can be both public and unsecured. In addition, the communication may not be able to be verified, introducing possible nefarious activity that can negatively affect the performance of the vehicle.

As will be described herein, by introducing a secure form of communication for obtaining vehicular services and an ability to accurately identify who is requesting and/or receiving vehicular services, information related to nefarious activity in relation to these vehicular services can be rejected, avoided, discarded, etc. Public keys can be exchanged and used to encrypt data while private keys, which remain private and exclusive to a single entity, can be used to decrypt data. In this way, those without the private key are prevented from intercepting service data and using it for purposes other than initially intended. Further, certificates and signatures can be used to verify identities of a sender of data and insure that data originates from an intended source.

<FIG> is a block diagram of an example vehicular entity <NUM> in accordance with an embodiment of the present disclosure. The vehicular entity <NUM> can be an autonomous vehicle, a traditional non-autonomous vehicle, an emergency vehicle, a service vehicle, or the like, and that can be referred to as an apparatus. The vehicular entity <NUM> can include a vehicle computing device <NUM>, such as an on-board computer. Vehicle computing device <NUM> can include a processor <NUM> coupled to a vehicular communication component <NUM>, such as a reader, writer, and/or other computing device capable of performing the functions described below, that is coupled to (e.g., or includes) an antenna <NUM>. Vehicular communication component <NUM> can include a processor <NUM> coupled to a memory <NUM>, such as a non-volatile flash memory, although embodiments are not so limited.

Vehicle computing device <NUM> can control operational parameters of vehicular entity <NUM>, such as steering and speed. For example, a controller (not shown) can be coupled to a steering control system <NUM> and a speed control system <NUM>. Further, vehicle computing device <NUM> can be coupled to an information system <NUM>. Information system <NUM> can be configured to display a message, such as the route information, and can display visual warnings and/or output audible warnings.

Communication component <NUM> can receive route information from additional computing devices, such as from external computing device <NUM> described in association with <FIG>. Processor <NUM> can cause steering control system <NUM> to adjust the direction of vehicular entity <NUM> and/or speed control system <NUM> to adjust the speed of vehicular entity <NUM> in response (e.g., according) to the route information from communication component <NUM> in <FIG>. For example, the route information can indicate the presence of a lane boundary, the presence of a pedestrian, the speed limit, the direction of the road (e.g., the road is straight or curves left or right), that there is a lane change, a detour, or the like. Processor <NUM> can cause information system <NUM> to display the route information from communication component <NUM>, such as a distance to a construction zone, a lane change, a crossroad, railroad crossing, or a detour, the presence of a pedestrian, the presence of another vehicle, or the like.

<FIG> is a block diagram of an example transportation assistance entity <NUM>, such as a road or lane including an external communication component, in accordance with an embodiment of the present disclosure. The transportation assistance entity <NUM> can be a road, a road lane, a traffic sign, a street light, an emergency vehicle, a pedestrian, a traffic office, a police officer, etc. The transportation assistance entity <NUM> can be any element, object, or person capable of having an external communication component positioned, attached, or embedded within or on and able to assist the vehicular entity <NUM> of <FIG>.

The transportation assistance entity <NUM> can include an external computing device <NUM>, such as an on-board computer. External computing device <NUM> can include a processor <NUM> coupled to an external communication component <NUM>, such as a reader, writer, and/or other computing device capable of performing the functions described below, that is coupled to (e.g., or includes) an antenna <NUM>. Vehicular communication component <NUM> can include a processor <NUM> coupled to a memory <NUM>, such as a non-volatile flash memory, although embodiments are not so limited. The antenna <NUM> of the external computing device <NUM> can be in communication with the antenna <NUM> of the vehicular entity <NUM>.

In some examples, antennas <NUM> and <NUM> can be loop antennas configured as inductor coils, such as solenoids. Antenna <NUM> can loop around vehicular entity <NUM>, for example. Antenna <NUM> can generate an electromagnetic field in response to current flowing through antenna <NUM>. For example, the strength of the electromagnetic field can depend on the number of coils and the amount of current. The electromagnetic field generated by antenna <NUM> can induce current flow in an antenna <NUM> that powers the respective external computing device <NUM>. As an example, antenna <NUM> in <FIG> can induce current flow in antenna <NUM> when vehicular entity <NUM> brings antenna <NUM> to within a communication distance (e.g., a communication range) of the antenna <NUM>. For example, the communication distance can depend on the strength of the electromagnetic field generated by antenna <NUM>. The electromagnetic field generated by antenna <NUM> can be set, by the number of coils of antenna <NUM> and/or the current passing through antenna <NUM>, such that the communication distance can span the left and right lanes of a road. In some examples, the communication distance can be about <NUM> centimeters to about <NUM> centimeters on either side of vehicular entity <NUM>.

In some examples, the external computing device <NUM> can include a number of wireless communication devices, such as transmitters, transponders, transceivers, or the like. As an example, the external communication component <NUM> can be such a wireless communication device. In some examples, wireless communication devices can be passive wireless communication devices that are powered (e.g., energized) by vehicular entity <NUM>, as described above. Wireless communication devices can be located along a route, such as a road, on which vehicular entity <NUM> can travel. In some examples, the route can include a number of roads. For example, wireless communication devices can be embedded in the roads, embedded and/or located on the walls of a tunnel along the route, located on signs, such as traffic signs, along the route, located in and/or on traffic-control lights along the route, located in and/or on other vehicles along the route, on (e.g., carried by and/or worn by) pedestrians along the route, or the like.

Wireless communication devices can transmit route information about the route to vehicular entity <NUM> in response to being powered by vehicular entity <NUM> and/or collect information from vehicular entity <NUM> in response to being powered by vehicular entity <NUM>. In some examples, route information can include information that can affect the operation of vehicular entity <NUM> along the route, such as information that can affect the direction and/or the speed of vehicular entity <NUM> along the route. For example, vehicular entity <NUM> can make adjustments to its operation and/or indicate that adjustments should be made to its operation in response to the route information.

Wireless communication devices can be short-range wireless communication devices, such as near field communication (NFC) tags, RFID tags, or the like. In at least one embodiment, wireless communication devices can include non-volatile storage components that can be respectively integrated into chips, such as microchips. Each of the respective chips can be coupled to a respective antenna <NUM>. The respective storage components can store respective route information.

In some examples, wireless communication devices can be reprogrammable and can be wirelessly reprogrammed in situ. For example, wireless communication devices can be reprogrammed with updated route information to reflect changes to the road, such as due to road construction, flooding, bridge repairs, detours, lane closures, or the like. For examples in which wireless communication devices are NFC tags, a wireless device with NFC capabilities and application software that allows the device to reprogram the NFC tags can be used to reprogram the NFC tags.

The respective wireless communication devices can respectively transmit their respective route information to communication component <NUM> in response to vehicular entity <NUM> passing within the communication distance of the respective wireless communication devices. For example, the respective wireless communication devices can respectively transmit their respective route information in response to being powered by communication component <NUM>. The information can be transferred from wireless communication devices to communication component <NUM> in the form of signals, such as radio frequency signals. For example, communication devices and communication component <NUM> can communicate using radio frequency signals.

For examples in which wireless communication devices are NFC tags, communication component <NUM> can be an NFC reader and can communicate with wireless communication devices using an NFC protocol that can be stored in memory <NUM> for processing by processor <NUM>. For example, communication component <NUM> and wireless communication devices can communicate at about <NUM> mega-Hertz according to the ISO/IEC <NUM>-<NUM> international standard for passive RFID for air interface communications. For example, the information can be transmitted in the form of a signal having a frequency of about <NUM> mega-Hertz.

In some examples, the communication distance may be set such that wireless communication devices are only activated when vehicular entity <NUM> is too close to wireless communication devices. For example, wireless communication devices can transmit information to communication component <NUM>, indicating that vehicular entity <NUM> is too close, such as within six inches, one foot, etc. For example, wireless communication devices can be embedded in a road along a centerline and/or an edge of a road and/or located in another vehicle, and the transmitted information can indicate that vehicular entity <NUM> is too close to the centerline, the edge of the road, or the other vehicle. Communication component <NUM> can then transmit the information to processor <NUM>. Processor <NUM> can cause information system <NUM> to display a visual warning and/or sound an audible alarm, indicating that vehicular entity <NUM> is too close to the centerline, the edge of the road, or the other vehicle. In some examples, processor <NUM> can cause steering system <NUM> to steer vehicular entity <NUM> away from the centerline, the edge of the road, or the other vehicle in response to the transmitted information.

Wireless communication devices can include information that is specific to and recognized only by particular vehicles that form a particular subset of all the vehicles passing by wireless communication devices, such as emergency vehicles (e.g., police or fire vehicles ambulances, or the like) or service vehicles. In examples where vehicular entity <NUM> is such a vehicle, communication component <NUM> can be configured to recognize that information.

In some examples, a wireless communication device can be used to collect information (e.g., traffic information), such as vehicle speeds, the number of vehicles passing by the communication device, or the like. Communication component <NUM> can be configured to energize a communication device and write the information to the energized communication device. For example, the current vehicle speed and/or a date and time can be written to the communication device. The communication device can collect such information from each vehicle that passes by the communication device. For example, the information can be used to determine the number of vehicles passing by (e.g., the amount of traffic) on a particular day and time and/or the speeds of the vehicles on a particular date and time.

Each of the respective wireless communication devices can include different route information. However, wireless communication devices can be distributed over a relatively short distance of a road, and the route information might change relatively little from wireless communication device to wireless communication device. As such, if a vehicular entity <NUM> fails to receive information from a wireless communication device, vehicular entity <NUM> can receive information from another wireless communication device without a significant loss of information. For example, wireless communication devices that are immediately adjacent to each other, with no intervening wireless communication devices, can include the same information so that no information is lost if vehicular entity <NUM> fails to receive information from one of the wireless communication devices.

Wireless communication devices can be respectively worn or carried by different pedestrians along a road. For example, in response to being energized by communication component <NUM>, wireless communication devices can respectively send messages to communication component <NUM> indicating the presence of the respective pedestrians.

<FIG> illustrates a communications system <NUM> in accordance with an embodiment of the present disclosure. System <NUM> can include a passive wireless communication device, such as a short-range communication device (e.g., an NFC tag <NUM>) that can be as described previously. The NFC tag can be in a vehicular entity <NUM>. Vehicular entity <NUM> can be configured as shown in <FIG> for vehicular entity <NUM> and include the components of vehicular entity <NUM> in addition to the NFC tag <NUM>. NFC tag <NUM> can include a chip <NUM> having a non-volatile storage component <NUM> that stores information, such as a user identity information, user financial information for paying a toll, and/or information about vehicular entity <NUM>, such as the speed of vehicular entity <NUM>, the number of passengers in vehicular entity <NUM>, etc. NFC tag <NUM> can include an antenna <NUM>.

System <NUM> can include a communications device <NUM>, such an active communications device (e.g., that includes a power supply), that can receive the information from NFC tag <NUM> and/or can transmit information to vehicular entity <NUM>. In some examples, communications device can include a reader (e.g., an NFC reader), such as a toll reader.

Communications device <NUM> can include a processor <NUM> a memory <NUM>, such as a non-volatile memory, and an antenna <NUM>. Memory <NUM> can include an NFC protocol that allows communications device <NUM> to communicate with NFC tag <NUM>. For example, communications device <NUM> and NFC tag <NUM> can communicate using the NFC protocol, such as at about <NUM> mega-Hertz and according to the ISO/IEC <NUM>-<NUM> international standard.

Communications device <NUM> can communicate with an operations center. For example, communications device <NUM> can be wirelessly coupled or hardwired to the communications center. In some examples, communications device <NUM> can communicate with the operations center via WIFI or over the Internet. Communications device <NUM> can energize NFC tag <NUM> when vehicular entity <NUM> brings antenna <NUM> within a communication distance of antenna <NUM>, as described previously. The communication distance can be shorter and can provide better security than previous approaches that use RFID tags.

In some examples, communications device <NUM> can be a toll reader. For example, NFC tag <NUM> can transmit user information for paying the toll to communications device <NUM> in response to being energized by communications device <NUM>. Communications device <NUM> can then send payment confirmation back to vehicular entity <NUM>, in some instances.

In some examples, communications device <NUM> can receive real-time information from the operations center and can transmit that information to vehicular entity <NUM>. For example, communications device <NUM> can transmit road conditions, weather conditions, traffic conditions, etc. to vehicular entity <NUM>. In some examples, a number of communication devices <NUM> can embedded in a road along a route of vehicular entity <NUM>, located at an entrance to a bridge, located in or on the walls of a tunnel, located in or on a road signs, traffic signals. For example, communication devices <NUM> can be located anywhere communication devices <NUM> and/or <NUM> can be located, as described previously.

<FIG> each illustrate an example transportation environment <NUM>, including a transportation assistance entity <NUM> and a vehicular entity <NUM>, in accordance with an embodiment of the present disclosure. As illustrated in <FIG>, an external communication component <NUM> can be embedded within, positioned on, or attached to a transportation assistance entity <NUM>, such as a road lane. As an example, an external communication component <NUM> can be embedded within a transportation assistance entity <NUM>. As is illustrated, the transportation assistance entity <NUM> is a road lane. The vehicular entity <NUM> can include a vehicular communication component <NUM> that is in communication with the external communication component <NUM>. The vehicular entity <NUM> can drive in a first direction, indicated by arrow <NUM>, along the transportation assistance entity <NUM> and in a second direction, indicated by arrow <NUM>, along the transportation assistance entity <NUM>. In this way, the vehicular entity can travel towards, across, and/or away from the external communication component <NUM>. As the vehicular communication component <NUM> of the vehicular entity <NUM> approaches within a particular proximity of the external communication component <NUM>, communication can begin and/or become strengthened. The particular proximity, in this example, can refer to a distance of between <NUM> and <NUM>. In an example, the particular proximity can depend on a vehicle antenna system and a position of tags in the road. Although the transportation assistance entity is illustrated as including a road lane, embodiments of the present disclosure are not limited to this example of transportation assistance entities.

<FIG> is an illustrated of a vehicular entity <NUM> within the transportation environment <NUM> at different points of entry, engagement, and departure in relation to a transportation service being provided. As an example, the vehicular entity <NUM> can travel over a first location <NUM>-<NUM> of a first road lane portion <NUM>-<NUM>. The first road lane portion <NUM>-<NUM> can include a first external communication component <NUM>-<NUM>. As the vehicular entity <NUM> comes in close proximity to the vehicular communication component external communication component <NUM>-<NUM>, the vehicular communication component <NUM> can communicate with the external communication component <NUM>-<NUM>. In this example, the close proximity can refer to a distance of greater than <NUM> meter. In an example, the close proximity can refer to a distance of less than <NUM> meters. In an example, the close proximity can depend on a maximum distance between road lanes and/or a vehicle antenna system. The communication can indicate that the vehicular entity <NUM> has entered an entrance for receiving a transportation service. While at the first location <NUM>-<NUM>, the vehicular communication component <NUM> can send a vehicular public key to the external communication component <NUM>-<NUM> and the external communication component <NUM>-<NUM> can send an external public key to the vehicular communication component <NUM>.

These public keys (vehicular and external) can be used to encrypt data sent to each respective communication component and verify an identity of each and exchange invoice, confirmation, and payment information. As an example, as will described further below in association with <FIG>, the vehicular communication component <NUM> can encrypt data using the received external public key and send the encrypted data to the external communication component <NUM>-<NUM>. Likewise, the external communication component <NUM>-<NUM> can encrypt data using the received vehicular public key and send the encrypted data to the vehicular communication component <NUM>. Data, such as service data sent by the vehicular entity <NUM> can include credit card information, phone number, email address, identification information, payment information, etc. A driver of the vehicular entity <NUM> can manually indicate payment and/or automatically confirm payment if this modality is enabled. This confirmation of payment can be sent with a digital signature to verify an identity of the vehicular entity <NUM>. Information about the service can be provided to the vehicular entity <NUM> and displayed on a dashboard of the vehicular entity <NUM> or sent to an email associated with the vehicular entity <NUM>. A driver of the vehicular entity <NUM> can manually confirm details of the service or the service can be previously enabled and automatically accepted at this point in the process.

Further, as the vehicular entity <NUM> travels, as illustrated by arrow <NUM>-<NUM>, to a second location <NUM>-<NUM> of a second road lane portion <NUM>-<NUM>, the vehicular communication component <NUM> can communicate with an external communication component <NUM>-<NUM> of the second road lane portion <NUM>-<NUM>. Communication between the vehicular communication component <NUM> and the external communication component <NUM>-<NUM> can indicate that the vehicular entity <NUM> is in the location <NUM>-<NUM> to receive the transportation service. As the vehicular entity <NUM> travels, as illustrated by arrow <NUM>-<NUM>, into a third location <NUM>-<NUM> of a third road lane portion <NUM>-<NUM>, the proximity of the vehicular communication component <NUM> to the external communication component <NUM>-<NUM> can indicate that the vehicular entity <NUM> has received the service and/or has paid for the service. In one example, the exiting vehicle can be recognized based on an identification of the vehicle, a VIN number, etc. along with a vehicular digital signature. Upon receipt and/or payment, data associated with the vehicular entity <NUM> can be discarded, erased, cleared, etc. from a database associated with the external communication component <NUM>-<NUM>.

While this example is described as having an external communication component at each portion of road, examples are not so limited. For example, a single external communication component can communicate with the vehicular entity <NUM> as it travels through each location and a proximity to the external communication component can indicate which portion of the process the vehicular entity <NUM> is going through, as described above. Further, in an example, all steps of the process can be performed in a single location, where the vehicular entity <NUM> enters a location, confirms the service (optionally with payment), and receives the service all at the same location. In addition, payment can occur prior to receiving the service, immediately after receiving the service, or at a later date through a billing process.

In an example, the transportation service received by the vehicular entity <NUM> can include public services such as travel through a toll gate, parking, and/or a vehicle washing. Each of the public services can be paid for by exchange of an invoice, a confirmation that the vehicular entity <NUM> wants the service (optionally accompanied by a signature, as described below, to verify the identity of the vehicular entity <NUM>), and payment for the service by the vehicular entity <NUM>. In another example, the transportation services can include services without payment, such as vehicles entering and/or exiting controlled traffic zones, private controlled access (e.g., into truck hubs, taxi stations, etc.), home car garage access, reserved bus stop area (e.g., bus stop area reserved for only for a particular company or business), taxi parking and/or a waiting area for taxis, etc. In the instance where the data sent is accompanied by a signature, a vehicular entity <NUM> can be prevented from subsequently denying that the vehicular entity <NUM> requested the transportation service after receiving the service.

In an example, data exchanged between the vehicular entity <NUM> and the transportation assistance entity <NUM> can have a freshness used by the other. As an example, data sent by the vehicular entity <NUM> to the transportation assistance entity <NUM> to indicate the exact same instructions can be altered at each of a particular time frame or for a particular amount of data being sent. This can prevent a hacker from intercepting previously sent data and sending the same data again to result in the same outcome. If the data has been slightly altered but still indicates a same instruction, the hacker would send the identical information at a later point in time and the same instruction would not be carried out due to the recipient expecting the altered data to carry out the same instruction.

The data exchanged between the vehicular entity <NUM> and the transportation assistance entity <NUM> can be performed using a number of encryption and/or decryption methods as described below. The securing of the data can insure that nefarious activity is prevented from interfering with the services procured by the vehicular entity <NUM> and/or interfering with payment and/or receipt of money for carrying out the services.

<FIG> is a block diagram of an example system including an external communication component <NUM> and a vehicular communication component <NUM> in accordance with an embodiment of the present disclosure. As a vehicular entity (e.g., <NUM> in <FIG>) comes in close proximity to a road lane (e.g., road lane <NUM>-<NUM>), the associated vehicular communication component <NUM> (e.g., <NUM>-<NUM> in <FIG>) of the vehicular entity can exchange data with the external communication component <NUM> of the road lane using a sensor (e.g., a radio frequency identification sensor (RFID)).

A computing device can boot in stages using layers, with each layer authenticating and loading a subsequent layer and providing increasingly sophisticated runtime services at each layer. A layer can be served by a prior layer and serve a subsequent layer, thereby creating an interconnected web of the layers that builds upon lower layers and serves higher order layers. As is illustrated in <FIG>, Layer <NUM> ("L<NUM>") <NUM> and Layer <NUM> ("L<NUM>") <NUM> are within the external communication component. Layer <NUM><NUM> can provide a Firmware Derivative Secret (FDS) key <NUM> to Layer <NUM><NUM>. The FDS key <NUM> can describe the identity of code of Layer <NUM><NUM> and other security relevant data. In an example, a particular protocol (such as robust internet of things (RIOT) core protocol) can use the FDS <NUM> to validate code of Layer <NUM><NUM> that it loads. In an example, the particular protocol can include a device identification composition engine (DICE) and/or the RIOT core protocol. As an example, an FDS can include Layer <NUM> firmware image itself, a manifest that cryptographically identifies authorized Layer <NUM> firmware, a firmware version number of signed firmware in the context of a secure boot implementation, and/or security-critical configuration settings for the device. A device secret <NUM> can be used to create the FDS <NUM> and be stored in memory of the external communication component <NUM>.

The external communication component can transmit data, as illustrated by arrow <NUM>, to the vehicular communication component <NUM>. The transmitted data can include an external identification that is public, a certificate (e.g., an external identification certificate), and/or an external public key. Layer <NUM> ("L<NUM>") <NUM> of the vehicular communication component <NUM> can receive the transmitted data execute the data in operations of the operating system ("OS") <NUM> and on a first application <NUM>-<NUM> and a second application <NUM>-<NUM>.

In an example operation, the external communication component <NUM> can read the device secret <NUM>, hash an identity of Layer <NUM><NUM>, and perform a calculation including:<MAT> where KL1 is an external public key, KDF (e.g., KDF defined in the National Institute of Standards and Technology (NIST) Special Publication <NUM>-<NUM>) is a key derivation function (i.e., HMAC-SHA256), and Fs(s) is the device secret <NUM>. FDS <NUM> can be determined by performing:<MAT> Likewise, the vehicular communication component <NUM> can transmit data, as illustrated by arrow <NUM>, including a vehicular identification that is public, a certificate (e.g., a vehicular identification certificate), and/or a vehicular public key. In the case of using an authenticated mode, the vehicular communication component <NUM> can send a vehicle identification number (VIN) for further authentication, identification, and/or verification of the vehicular entity.

In at least one example, the vehicular entity can log onto the system of the road lane (e.g., log into the external communication component <NUM>-<NUM>) using either of an anonymous log in or an authenticated log in. The authentication log in can allow the vehicular entity to obtain additional information that may not be accessible when logging in anonymously in an anonymous mode. In at least one example, the authentication can include providing a vehicular identification number (VIN) and/or authentication information, such as an exchange of public keys, as will be described below. In either of the anonymous and authenticated modes, the road lane can communicate with the vehicular entity to provide the external public key associated with the road lane to the vehicular entity.

<FIG> is a block diagram of an example process to determine a number of parameters in accordance with an embodiment of the present disclosure. <FIG> is an example of a determination of the parameters including the external public identification, the external certificate, and the external public key that are then sent, indicated by arrow <NUM>, to Layer <NUM> (e.g., Layer <NUM><NUM>) of a vehicular communication component (e.g., <NUM> in <FIG>). Layer <NUM> ("L<NUM>") <NUM> in <FIG> corresponds to Layer <NUM><NUM> in <FIG> and likewise FDS <NUM> corresponds to FDS <NUM>, Layer <NUM><NUM> corresponds to Layer <NUM><NUM>, and arrows <NUM> and <NUM> correspond to arrows <NUM> and <NUM>, respectively.

The FDS <NUM> from Layer <NUM><NUM> is sent to Layer <NUM><NUM> and used by an asymmetric ID generator <NUM> to generate a public identification ("IDlk public") <NUM> and a private identification <NUM>. In the abbreviated "IDlk public," the "lk" indicates Layer k (in this example Layer <NUM>), and the "public" indicates that the identification is openly shared. The public identification <NUM> is illustrated as shared by the arrow extending to the right and outside of Layer <NUM><NUM> of the external communication component. The generated private identification <NUM> is used as a key input into an encryptor <NUM>. The encryptor <NUM> can be any processor, computing device, etc. used to encrypt data.

Layer <NUM><NUM> of an external communication component can include an asymmetric key generator <NUM>. In at least one example, a random number generator (RND) <NUM> can optionally input a random number into the asymmetric key generator <NUM>. The asymmetric key generator <NUM> can generate a public key ("KLk public") <NUM> (referred to as an external public key) and a private key ("KLK private") <NUM> (referred to as an external private key) associated with an external communication component such as external communication component <NUM> in <FIG>. The external public key <NUM> can be an input (as "data") into the encryptor <NUM>. The encryptor <NUM> can generate a result K'<NUM> using the inputs of the external private identification <NUM> and the external public key <NUM>. The external private key <NUM> and the result K'<NUM> can be input into an additional encryptor <NUM>, resulting in output K" <NUM>. The output K" <NUM> is the external certificate ("IDL1 certificate") <NUM> transmitted to the Layer <NUM> (<NUM> of <FIG>). The external certificate <NUM> can provide an ability to verify and/or authenticate an origin of data sent from a device. As an example, data sent from the external communication component can be associated with an identity of the external communication component by verifying the certificate, as will be described further in association with <FIG>. Further, the external public key ("KL1 public key") <NUM> can be transmitted to Layer <NUM>. Therefore, the public identification <NUM>, the certificate <NUM>, and the external public key <NUM> of an external communication component <NUM> can be transmitted to Layer <NUM> of a vehicular communication component.

<FIG> is a block diagram of an example process to determine a number of parameters in accordance with an embodiment of the present disclosure. <FIG> illustrates a Layer <NUM><NUM> of a vehicular communication component (e.g., vehicular communication component <NUM> in <FIG>) generating a vehicular identification ("IDL2 public") <NUM>, a vehicular certificate ("IDL2 Certificate") <NUM>, and a vehicular public key ("KL2 public key") <NUM>.

The external public key ("KL1 public key") <NUM> transmitted from Layer <NUM> of the external communication component to Layer <NUM><NUM> of a vehicular communication component, as described in <FIG>, is used by an asymmetric ID generator <NUM> of the vehicular communication component to generate a public identification ("IDlk public") <NUM> and a private identification <NUM> of the vehicular communication component. In the abbreviated "IDlk public," the "lk" indicates Layer k (in this example Layer <NUM>), and the "public" indicates that the identification is openly shared. The public identification <NUM> is illustrated as shared by the arrow extending to the right and outside Layer <NUM><NUM>. The generated private identification <NUM> is used as a key input into an encryptor <NUM>.

Layer <NUM><NUM> of the vehicular communication component can include an asymmetric key generator <NUM>. In at least one example, a random number generator (RND) <NUM> can optionally input a random number into the asymmetric key generator <NUM>. The asymmetric key generator <NUM> can generate a public key ("KLk public") <NUM> (referred to as a vehicular public key) and a private key ("KLK private") <NUM> (referred to as a vehicular private key) associated with a vehicular communication component such as vehicular communication component <NUM> in <FIG>. The vehicular public key <NUM> can be an input (as "data") into the encryptor <NUM>. The encryptor <NUM> can generate a result K' <NUM> using the inputs of the vehicular private identification <NUM> and the vehicular public key <NUM>. The vehicular private key <NUM> and the result K' <NUM> can be input into an additional encryptor <NUM>, resulting in output K" <NUM>. The output K" <NUM> is the vehicular certificate ("IDL2 certificate") <NUM> transmitted back to the Layer <NUM> (<NUM> of <FIG>). The vehicular certificate <NUM> can provide an ability to verify and/or authenticate an origin of data sent from a device. As an example, data sent from the vehicular communication component can be associated with an identity of the vehicular communication component by verifying the certificate, as will be described further in association with <FIG>. Further, the vehicular public key ("KL2 public key") <NUM> can be transmitted to Layer <NUM>. Therefore, the public identification <NUM>, the certificate <NUM>, and the vehicular public key <NUM> of the vehicular communication component can be transmitted to Layer <NUM> of an external communication component.

In an example, in response to an external communication component receiving a public key from a vehicular communication component, the external communication component can encrypt data to be sent to the vehicular communication component using the vehicular public key. Vice versa, the vehicular communication component can encrypt data to be sent to the external communication component using the external public key. In response to the vehicular communication component receiving data encrypted using the vehicular public key, the vehicular communication component can decrypt the data using its own vehicular private key. Likewise, in response to the external communication component receiving data encrypted using the external public key, the external communication component can decrypt the data using its own external private key. As the vehicular private key is not shared with another device outside the vehicular communication component and the external private key is not shared with another device outside the external communication component, the data sent to the vehicular communication component and the external communication component remains secure.

<FIG> is a block diagram of an example process to verify a certificate in accordance with an embodiment of the present disclosure. In the illustrated example of <FIG>, a public key <NUM>, a certificate <NUM>, and a public identification is provided from an external communication component (e.g., from Layer <NUM><NUM> of external communication component <NUM> in <FIG>). The data of the certificate <NUM> and the external public key <NUM> can be used as inputs into a decryptor <NUM>. The decryptor <NUM> can be any processor, computing device, etc used to decrypt data. The result of the decryption of the certificate <NUM> and the external public key <NUM> can be used as an input into a secondary decryptor <NUM> along with the public identification, result in an output. The external public key <NUM> and the output from the decryptor <NUM> can indicate, as illustrated at <NUM>, whether the certificate is verified, resulting in a yes or no <NUM> as an output. In response to the certificate being verified, data received from the device being verified can be accepted, decrypted, and processed. In response to the certificate not being verified, data received from the device being verified can be discarded, removed, and/or ignored. In this way, nefarious devices sending nefarious data can be detected and avoided. As an example, a hacker sending data to be processed can be identified and the hacking data not processed.

<FIG> is a block diagram of an example process to verify a signature in accordance with an embodiment of the present disclosure. In the instance where a device is sending data that may be verified in order to avoid subsequent repudiation, a signature can be generated and sent with data. As an example, a first device may make a request of a second device and once the second device performs the request, the first device may indicate that the first device never made such a request. An anti-repudiation approach, such as using a signature, can avoid repudiation by the first device and insure that the second device can perform the requested task without subsequent difficulty.

A vehicle computing device <NUM> (such as vehicle computing device <NUM> in <FIG>) can send data <NUM> to an external computing device (such as external computing device <NUM>). The vehicle computing device <NUM> can generate, at <NUM>, a signature <NUM> using a vehicular private key <NUM>. The signature <NUM> can be transmitted to the external computing device <NUM>. The external computing device <NUM> can verify, at <NUM>, using data <NUM> and the external public key <NUM> previously received. In this way, signature verification operates by using a private key to encrypt the signature and a public key to decrypt the signature. In this way, a unique signature for each device can remain private to the device sending the signature while allowing the receiving device to be able to decrypt the signature for verification. This is in contrast to encryption/decryption of the data, which is encrypted by the sending device using the public key of the receiving device and decrypted by the receiving device using the private key of the receiver. In at least one example, the vehicle can verify the digital signature by using an internal cryptography process (e.g., Elliptical Curve Digital signature (ECDSA) or a similar process.

In the preceding detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown, by way of illustration, specific examples. In the drawings, like numerals describe substantially similar components throughout the several views. Other examples may be utilized, and structural, logical and/or electrical changes may be made without departing from the scope of the present disclosure.

As will be appreciated, elements shown in the various embodiments herein can be added, exchanged, and/or eliminated so as to provide a number of additional embodiments of the present disclosure. In addition, as will be appreciated, the proportion and the relative scale of the elements provided in the figures are intended to illustrate the embodiments of the present disclosure and should not be taken in a limiting sense.

Claim 1:
An apparatus, comprising:
a processor (<NUM>, <NUM>, <NUM>, <NUM>); and
an external communication component (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) coupled to the processor, wherein the external communication component is configured to, in response to determining a vehicular entity (<NUM>, <NUM>, <NUM>) is within a particular proximity to the external communication component:
generate an external private key (<NUM>) and an external public key (<NUM>, <NUM>, <NUM>, <NUM>);
provide the external public key and data to a vehicular communication component (<NUM>, <NUM>, <NUM>, <NUM>) associated with the vehicular entity;
receive data from the vehicular communication component in response to providing the external public key and data to the vehicular communication component, wherein the received data comprises a vehicular digital signature;
determine an identity of the vehicular entity based on the vehicular digital signature, wherein the determined identity prevents subsequent repudiation of a provided service;
decrypt the received data using the external private key; and
provide the service to the vehicular entity based on the decrypted received data.