The disclosed embodiments relate generally to vehicle systems and in particular, but not exclusively, to enabling wireless communications between a vehicle and a communications node.
Vehicles, such as cars, trucks, trains, etc., are becoming more connected. That is, a vehicle may include network communication capabilities enabling the vehicle to communicate via a network, such as a wide area network (e.g., cellular communications network), local communication network (e.g., a residential network), a personal area network (e.g., a network established between two devices), as well as other wireless communication networks. The vehicle may use one or more of the different types of network to establish a connection with, and exchange messages, between other device(s) via the network connections. For example, the vehicle may provide diagnostics information, receive software and firmware updates, etc. via a network connection to a remote maintenance management server. Driving conditions, such as within a city scape, in remote regions, and in other areas of low service availability, may prevent the vehicle's access to the communications network. Thus, the vehicle may be unable to exchange data with remote servers during these periods of no network connectivity.
As another example of a type of network connection established by the vehicle, the vehicle may directly communicate with other vehicles. Such a local connection and/or direct communications connection enables the vehicle to establish position, exchange driving strategies, transmit warnings, etc. However, the establishment of a connection, or local network, with another vehicle, another network device, etc., does not necessarily establish a trusted relationship with the other vehicle and/or device, or trust in the information exchanged with the other vehicle and/or device.
When two or more systems, such as a combination of vehicles and network nodes, directly connect with one another, a peer-to-peer network may be established that connects directly and/or indirectly each peer in the network with the other peers in the network. That is, each system in the peer-to-peer network may share resources with one another without having to go through a server computer system. Furthermore, a direct connection may not be needed to share information indirectly between peers, such as by using an intermediary peer. While peer-to-peer networking helps to expand the reach of computer networks and distribute networking loads and tasks, there are drawbacks when applied to vehicles. As discussed in Peer-to-Peer Networking: A coming of Age (Judy Hartley, Mar. 7, 2012), data exchanged within the peer-to-peer network is not necessarily encrypted, and therefore may be readable by any party. For vehicles that travel between in public spaces, the vulnerabilities associated with data security and privacy are exposed to both benign and nefarious parties. Furthermore, authentication of a party that a peer is directly and/or indirectly connected to may be weak. In other words, a system may not be able to establish trust and/or an identity of a party they are directly connected to, leading to low levels of trust in all of the peers in a network. Then, if data is being distributed in such a network with low levels of trust and authentication, the connections and the data being distributed between those peers inherits the low levels of trust.
The word “exemplary” or “example” is used herein to mean “serving as an example, instance, or illustration.” Any aspect or embodiment described herein as “exemplary” or as an “example” in not necessarily to be construed as preferred or advantageous over other aspects or embodiments.
In embodiments, vehicle 102 may be a fully electric vehicle, partially electric (i.e., hybrid) vehicles, non-electric vehicles (i.e., vehicle with a traditional internal combustion engine). Furthermore, although described mostly in the context of automobiles, the illustrated systems and methods can also be used in other wheeled vehicles such as trucks, motorcycles, electronic bicycles, buses, trains, etc. It can also be used in non-wheeled vehicles such as ships, airplanes (powered or gliders), drones, and rockets. In fact, the illustrated embodiments can be used in any situation in which it is useful to establish local and/or temporary wireless network connections with other nodes in a communications network.
In embodiments, vehicle network node(s) 170 may also be a combination of fully electric vehicles, partially electric (i.e., hybrid) vehicles, non-electric vehicles, trucks, motorcycles, buses, trains, etc. capable of performing the wireless communication and authentication techniques discussed herein. Furthermore, the network node(s) 160 may be stationary and/or mobile devices, such as traffic lights, access points, etc. that are also capable of performing the wireless communication and authentication techniques discussed herein. As discussed in greater detail herein, vehicle 102, network node(s) 160, and vehicle network node(s) 170 are each nodes in a network formed by a plurality of local area network connections between nodes.
In embodiments, certification authority server(s) 150 are remote servers that provide certification authority services, such as issuing identifiers to network nodes, generating and distributing public/private encryption keys, issuing certificates to network nodes, signing certificates, revoking certificates, verifying data within certificates, etc. Certification authority server(s) 150 may perform any of the services typically associated with certification authority systems. Certification authority server(s) 150 may be a single server computer system, or may be comprised of two or more server computer systems distributed over a network 130 (e.g., the Internet, a private network, or other network).
System 100 includes vehicle 102 communicatively coupled to any combination of network node(s) 160, vehicle network node(s) 170, and certification authority server(s) 150. In the context of this application, “communicatively coupled” means coupled in such a way that data can be exchanged, in one or both directions, between two entities or components (e.g., between the vehicle 102 and any of network node(s) 160, vehicle network node(s) 170, and certification authority server(s) 150).
In embodiments, each of vehicle 102, network node(s) 160, vehicle network node(s) 170, and certification authority server(s) 150 are associated with a manufacturer, such as a manufacturer of vehicles. For example, vehicle 102 and vehicle network node(s) 170 may be vehicles built by the manufacturer, network node(s) 160 may be devices (e.g., smart traffic lights, smart street signs, access points, etc.) placed by the manufacturer, and certification authority server(s) 150 may be run by, or their operation under the control of, the manufacturer. Thus, a network, similar to an internet or intranet, may be formed between the vehicles, network nodes, and remote servers, as discussed herein. In embodiments, one or more elements of authentication data (e.g., encryption key(s)) is shared and/or known by each of the systems of the manufacturer. However, in some embodiments, the network need not be restricted by a common manufacturer, and may instead be any collection of vehicles, network nodes, and/or remote servers that share authentication data and perform the techniques discussed in greater detail herein.
In one embodiment, vehicle 102 includes one or more systems, such as components 101, each having an electronic control unit (ECU) 105, and each ECU 105 is communicatively coupled via a communications network 107 to a vehicle control unit (VCU) 106. The communications network 107 may be a controller area network (CAN), an Ethernet network, a wireless communications network, another type of communications network, or a combination of different communication networks. VCU 106 is also communicatively coupled to a GPS unit 110, a user interface 112, and a transceiver 114. Transceiver 114, is a vehicle to anything (V2X), wireless fidelity, wide area network, or a combination of transceivers, that is communicatively coupled to an antenna 116, through which vehicle 102 can wirelessly transmit data to, and receive data from, any of certification authority server(s) 150, network node(s) 160, and vehicle network node(s) 170 using protocols for the exchange of information. In the illustrated embodiment, vehicle 102 communicates wirelessly via antenna 116 with a tower 132, which can then communicate via network 130 (e.g., a cellular communication network, a local area network, a wide area network, etc.) with certification authority server(s) 150. In embodiments, the vehicle 102 communicates with certification authority server(s) 150 and/or other remote server(s) when a wireless connection with tower 132 is available.
Components 101 are generally components of the systems of the vehicle 102. For example, components 101 can include adjustable seat actuators, power inverters, window controls, electronic braking systems, etc. Vehicle control unit (VCU) 106 is a controller including a microprocessor, memory, storage, and a communication interface with which it can communicate with components 101, global positioning system (GPS) 110, user interface 112, and transceiver 114 via network 107. In one embodiment VCU 106 is the vehicle's main computer, but in other embodiments it can be a component separate from the vehicle's main or primary computer.
In one embodiment, vehicle 107 includes vehicle gateway 120. Vehicle gateway 120 is a networking appliance that resides on vehicles communications network 107. Vehicle gateway 120 may include a network interface, processor, memory, and one or more processing modules. In one embodiment, vehicle gateway 120 may reside in VCU 106, as well as in other components with sufficient access to network 107, processing power, and memory resources to perform the operations described in greater detail herein.
In embodiments, vehicle gateway 120 may be a hardware security module that provides a secure computing and storage environment, which is isolated from other processing and memory of vehicle 102. For example, vehicle gateway 120 may perform processes such as broadcasting for new network connections, establishing secure network connections with nodes (e.g., one or more of nodes 160 and 170), performing encryption of network communications, exchanging information with certification authority server(s) 150, negotiating wireless connection parameters and/or session keys for a new network connection, etc., as will be discussed in greater detail herein.
In embodiments, as noted above, the vehicle gateway 120 may be a hardware security module that performs node authentication and/or secure communication processes. Furthermore, as a hardware security module, vehicle gateway 120 may provide a secure storage for sensitive information, such as signed certificates of the vehicle, encryption keys, session encryption keys, vehicle identifiers, etc. In the event the vehicle 102, security gateway 120, or other sensitive component of the vehicle 102 becomes compromised, the secure storage of vehicle gateway 120 may be erased to maintain the security of the keys, certificates, and other data (e.g., user information) that may be maintained in the vehicle gateway 120. To this end, vehicle gateway 120 implements one or more physical and logical barriers for accessing the vehicle gateway 120. Vehicle gateway 120 may include pressure switches, electrical connectors, etc. that detects physical access to the internal components of the vehicle gateway 120, such as attempts to open a container housing the vehicle gateway 120. Vehicle gateway 120 may also include one or more software components that detect disallowed logical accesses to the internal components of the vehicle gateway 120, such as attempts to access secure storage, reprogram, or otherwise tamper with the operation of vehicle gateway 120, as well as detection of disallowed accesses or actions with respect to any of the systems of vehicle 102. As a hardened appliance, in response to detecting a non-allowed physical or logical access, vehicle gateway 120 responds by taking one or more actions (e.g., shutting down, entering a safe mode, wiping storage and loading a clean configuration, etc.).
Vehicle gateway 120 performs one or more security functions for communications sent/received from vehicle. In embodiments, small and/or local network connections are continually established between vehicle 102 and any combination of node(s) (e.g., network node(s) 160 and/or vehicle network node(s) 170). For example, a local network connection may have a range of 10 meters, 100 meters, 1 kilometer, etc., and as vehicle 102 moves during operation, vehicle 102 is continuously coming within, or leaving, communication range with other network nodes capable of performing the processes discussed herein. Therefore, to ensure privacy and security in the established connections, and the data exchanged subsequent to establishing connections, for each new network connection that is to be established between vehicle 102 and another network node (160 or 170), vehicle gateway performs an initial discovery and handshaking process. In embodiments, as discussed in greater detail below, the discovery and handshaking process are used by each node (e.g., vehicle 102 and the other network nodes, such as 160 or 170) to broadcast messages for discovering other nodes of the network, verify each other's identity, establish that each has access to certain shared information (e.g., a network encryption key), and establish session encryption keys or other connection parameters (e.g., wireless communication channel parameters) for all communications exchanged between the vehicle 102 and the network node (160 or 170) after the handshaking process is performed. Such communications can include, for example, data shared between nodes (e.g., transmission of files, software updates, firmware updates, etc.), short message (e.g., traffic warnings, diagnostic events, etc.), relaying connections between nodes and/or a connection to network 130, as well as communication of other data.
In one embodiment, the system 100 may be used to establish a peer-to-peer network, in which vehicle 102 is a node within the peer-to-peer. For example,
In embodiments, nodes, such as node 660-N, which are not in range of a local connection (e.g., >1 km) with vehicle 102 can be connected via one or more intermediate peers (e.g., node 660-2). Thus, vehicle 102 can receive data from and transmit data to remote server 662 via peer nodes 660-N through 660-2 using peer-to-peer file sharing techniques, even when vehicle 102 lacks a connection to wide area network to which remote server 662 is connected. Furthermore, even if a connection to a wide area network is available, vehicle 102 may receive data (e.g., software updates, entertainment data, etc.) via the peer-to-peer network 600 in order to conserve bandwidth and the usage of individual connections to remote server 662. The exchange of messages in the peer-to-peer network 600 may be exchanged using the secure communications established herein.
Furthermore, the communications reach of vehicle 102 is therefore extended geographically (e.g., vehicle 102 being connected via intermediate nodes to node 660-N which is out of direct communication range), and logically (e.g., remote server 662 being accessible by node 660-N via a cellular or hard-wired network connection, where vehicle 102 can access node 660-N via the peer-to-peer network). This enables peer-to-peer data distribution in network 600 including, for example, short message alerts such as those generated by a node/vehicle in response to a monitored road or traffic condition that vehicle 102 has not yet encountered but which is on vehicle's 102 route of travel, data exchanges including those generated by a remote manufacturer or service server (e.g., server 662) that are to be distributed to all manufacturers' nodes (e.g., security updates, firmware updates, new network keys, software system updates, etc.), partial or incremental data transfers using peer-to-peer data sharing protocols (e.g., a node may receive/request a portion of data (e.g., a portion of firmware update) that it may already have a portion of (e.g., started to receive update when it had wide area network access to remote server 662, then lost access, and using data sharing over the network 600 to obtain the remainder of the firmware update), determining an approximate location of vehicle 102 using the peer-to-peer network 600 (e.g. using location data of peers and/or the network to relay the location to remove server 662 when vehicle 102 does not GPS reception and/or the ability to communicate their location to remote server 662), as well as other exchanges of data using the peer-to-peer network 600 and the connection of at least one peer to remote server 662.
In the embodiment illustrated in
In one embodiment, vehicle 202 is a system, which may include one or more processor(s) 212, a memory 205, and a network interface 204. It should be appreciated that vehicle 202 may also include, although not illustrated, a user and/or hardware interface, vehicle controls, one or more power device(s) (e.g., vehicle battery), drive control system, one or more vehicle systems (e.g., VCUs, components, positioning systems, etc.), a propulsion system (e.g. an electric, gasoline, natural gas, hybrid, etc. powered motor), a steering system, a braking system, as well as other components typically associated with vehicles. Although only a single network interface 204 is illustrated, it is understood that network interface 204 may be capable of communicatively coupling vehicle 202 to any number of nodes using one or more wireless subsystems (e.g., Bluetooth, WiFi, Cellular, or other networks) to transmit and receive data streams through one or more communication links (e.g., link 260).
In one embodiment, node 250 is also a system, which may include one or more processor(s), a memory, and communications subsystem. It should be appreciated that node 250 may also include, although not illustrated, a user interface (e.g., keyboard, touch-screen, or similar devices), a power device (e.g., a battery), a display screen (e.g., an LCD display), as well as other components typically associated with computer processing systems. Furthermore, node 250 may be any of the nodes illustrated in
In embodiments, memory 205 of vehicle 202 may be coupled to processor(s) to store instructions for execution by one or more processors, such as processor(s) 212. In some embodiments, the memory is non-transitory, and may store one or more processing modules. In one embodiment, memory 205 of vehicle 202 may store one or more processing modules of a vehicle gateway 220, such as an encryption engine 234, a networking manager 224, a node messaging manager 222, an ID, key, and certificate generator 228, and a secure data store 226 to implement embodiments described herein.
It should be appreciated that the embodiments as described herein may be implemented through the execution of instructions, for example as stored in memory or other element, by processor(s) 212 and/or other circuitry of vehicle 202. Particularly, circuitry of vehicle 202, including but not limited to processor(s) 212, may operate under the control of a program, routine, or the execution of instructions to execute methods or processes in accordance with the aspects and features described herein. For example, such a program may be implemented in firmware or software (e.g. stored in memory 205) and may be implemented by processor(s) 212, and/or other circuitry. Further, it should be appreciated that the terms processor, microprocessor, circuitry, controller, engine, manager, generator, etc., may refer to any type of logic or circuitry capable of executing logic, commands, instructions, software, firmware, functionality and the like.
Further, it should be appreciated that some or all of the functions, engines, or modules described herein may be performed by vehicle 202 itself and/or some or all of the functions, engines or modules described herein may be performed by another system connected through network interface 204 to vehicle 202. Thus, some and/or all of the functions may be performed by another system, and the results or intermediate calculations may be transferred back to vehicle 202. In some embodiments, such other system may comprise a server (not shown).
In one embodiment, vehicle 202 includes vehicle gateway 220. Vehicle gateway 220 may be a hardened network appliance, such as a hardware security module. The vehicle gateway 220 may therefore be physically and/or logically isolated from other processing and/or storage resources of the vehicle 202. For example, vehicle gateway 220 implemented in a hardware security module ensures that the processes performed by the vehicle gateway are free from attacks, that sensitive information (e.g., encryption keys, identifiers, certificates, session logs, etc.) is maintained in a secure location within vehicle 202, and that the processes using the sensitive information are performed within the logical and/or physical isolation of the hardware security module. Furthermore, as discussed above, the vehicle gateway 220 may be executed by a hardware security module that resides in the main processing unit of vehicle 202 (e.g., the VCU 106, as well as other processing unit of vehicle 202 capable of providing secure processing and memory resources).
In one embodiment, networking manager 224 is responsible for establishing the wireless communications link with node 250. To this end, in embodiments, networking manager 224 generates and causes the transmission of broadcast discovery messages as discussed below in
In one embodiment, when networking manager 224 of vehicle 202 receives and is able to successfully decrypt a broadcast discovery message of node, the encryption engine 234 performs one or more additional encryption processes, such as MAC tag verification in the received message, node ID authentication (using a signature and identifier using certificate authority services), generating a twice encrypted response (e.g., encrypted using a public key of node 250 and the network key) including one or more communication parameter proposal(s), and then transmitting a parameter proposal message to node 250.
However, when networking manager 224 of vehicle 202 receives a parameter proposal message from node 250 (e.g., in response to vehicles broadcast discovery message), networking manager 224 uses encryption engine 234 to perform complimentary operation to those discussed above. In embodiments, the operations can include MAC tag verification in the received message, decryption using a shared network key stored in secure data storage 226, decryption using the private key of the vehicle stored in secure data storage 226, validation of the sending node's signature (e.g., using a certificate authority and signatures/IDs in the decrypted message), generating a twice encrypted response (e.g., encrypted using a public key of node 250 and the network key) including one or more communication parameter proposal responses, and then transmitting a parameter proposal response message to node 250.
In embodiments, the network broadcast message generation and transmission, as well as receipt, can continue as communication parameters are negotiated and/or generated. In embodiments, the parameter generation can include the establishment and sharing of asymmetric session encryption keys (e.g., sharing of public keys with private keys secured by vehicle 202 and node 250). In other embodiments, the parameter generation and negotiation can include the exchange of a series of messages (e.g., a DH exchange) for the establishment and sharing of a symmetric session encryption key. In either embodiment, subsequent communications and data exchanged between vehicle 202 and node 250 may be secured using the negotiated session parameters (e.g., encryption key(s)). In embodiments, node messaging manager 222 uses the established session encryption key(s) with encryption engine 234 to encrypt/decrypt communications with node 250.
As a result, a secure communications channel is created between vehicle 202 and node 250. As discussed herein, vehicle 202 or node 250 may be peers in a peer-to-peer network linking vehicles, network nodes, and remote servers. Furthermore, each communications link is secured and identities of peers verified prior to communication exchange. Therefore, trust is established not only between the two entities in direct wireless communication (e.g. vehicle 202 and node 250), but between each peer including direct and indirect peers. Thus, when data is exchanged, distributed, requested, etc. in the peer-to-peer network, the data and sources inherit the established trust. As such a secure and trusted network of vehicles and network nodes is established using the techniques discussed herein.
In embodiments, further security may be established by ID, key, and certificate generator 228. In embodiments, each time vehicle 202 is turned or powered on for operation, one or more pieces of data used for establishing wireless communication connection is generated. In embodiments, ID, key, and certificate generator 228 may generate one or more of a new vehicle identifier, encryption keys, or certificates tied to the new identifier and/or encryption keys. For example, ID, key, and certificate generator 228 may include a certificate authority service that generates a new certificate tied to a chain of certificates back to a root certificate authority associated with a manufacturer of the vehicle. As another example, a new vehicle identifier is generated each time the vehicle is turned on, but a new certificate is generated less periodically (e.g., each day, once a week, once a month, etc.). By changing this data, additional security is added to anonymize each vehicle. In embodiments, ID, key, and certificate generator 228 stores the new IDs, key, and/or certificates in secure data storage 226 for later use consistent with the discussion herein.
In one embodiment, further security may be established by networking manager 224 logging the establishment of a communications sessions, such as the one established with node 250. For example, the node identifier of node 250 exchanged for the communications session may be stored to a session log maintained within secure data store 226 or elsewhere within memory 205. Furthermore, the log may include data, such as the duration of the connection maintained between vehicle 202 and node 250. The history of established connections, which may be limited to a certain number of entries, a freshness of entries, etc., and their associated durations, may be used by a security monitoring system of vehicle (not shown), a third party server (e.g., a manufacturer's security server), another security service, etc. to perform security monitoring for vehicle 202. In embodiments, the session log stores the node identifiers exchanged for each session and connection duration, which enables further security improvements for vehicle (e.g., being able to audit or analyze various connections), as well as anonymity of vehicles that are logged, using the techniques discussed herein.
Referring to
Processing logic then generates a broadcast message for establishing a network connection with a local network node (processing block 304). As discussed herein, the node may be any of a vehicle, network device (e.g. traffic light, access point, etc.), as well as other devices capable of performing the operations discussed herein. In one embodiment, processing logic of the vehicle maintains an ID for the vehicle, which is tied to a public and private key, and verifiable via a security certificate, as discussed herein. Processing logic utilizes this data to generate a broadcast message that can be encrypted, decrypted by other nodes, and an identity of the vehicle authenticated from the broadcast message contents.
In embodiments, processing logic further maintains and has access to a shared network encryption key. In embodiments, as discussed herein, the shared network encryption key is a network-wide key that is securely distributed to vehicles and network nodes by a manufacturer of the vehicle, a party that established the peer-to-peer network, or some other trusted party. New shared network encryption keys may be periodically distributed to vehicles and network nodes. Therefore, processing logic encrypts the broadcast message with the shared network security key (processing block 306). In one embodiment, processing logic utilizes AES-CCM mode encryption, which is a symmetric encryption technique capable of utilizing the shared network security key (e.g., can only be decrypted by other nodes/vehicles that have the shared network security key). In
It is noted that the broadcast message includes the random data (e.g., a timestamp, hash value, random number, etc.) inserted into the message contents prior to encryption so that no two broadcast messages that are generated and encrypted by the vehicle are the same, even when new IDs, certificates, etc. have been generated. The difference in broadcast message content ensures that the vehicle cannot be tracked via the broadcast message transmission (e.g., by network devices, cell towers, access points, etc.). Furthermore, in embodiments, additional data, such as nonce or other freshness day may also be added to encrypted broadcast message 370 to further enhance message security.
Processing logic then transmits the encrypted broadcast message (processing block 308). In embodiments, the vehicle utilizes a transmitter configured for establishing local network connections with one or more proximately located network nodes. For example, the transmitter may be able to transmit broadcast discovery messages reliably for a maximum range (e.g., 1 kilometer), so that local networks between the vehicle and a network node can be continuously established as the vehicle travels, encounters new nodes, leaves range of node to which vehicle is currently connected, etc.
Referring to
Processing logic validates the MAC tag in the encrypted broadcast message (processing block 404). In one embodiment, the MAC tag may be decrypted and/or analyzed using the shared network encryption key to validate the received message before decrypting the message's ciphertext, which also verifies that the transmitting node is using the shared network encryption key. In embodiments, use of a MAC tag in messaging exchanged between local network nodes is optional. However, once the MAC tag is validated, processing logic may then decrypt the encrypted broadcast message (e.g., the ciphertext) using the shared network encryption key (processing block 406). As discussed herein, processing logic may use a symmetric encryption technique, such as AES-CCM, AES-GCM, etc., to decrypt the encrypted broadcast message
Once successfully decrypted, processing logic verifies that the signature in the broadcast message matches the public key (e.g., in the Node ID data field) in the broadcast message using the node ID (e.g., extracted from the Node ID data field 354) (processing block 408). In one embodiment, the signature and public key can be verified using a certificate authority system verification technique (e.g., using a chain of certs stored by processing logic, accessing a remote certificate authority, etc.).
Processing logic then generates a parameter proposal message for establishing session keys for communication exchange with the node (processing block 410).
In embodiments, data field 456 may be either proposed session keys or a Diffie-Hellman (DH) exchange generated key. A DH exchange key is a symmetric encryption key that is cooperatively generated by processing logic of the vehicle and the node, in one embodiment. The DH exchange can be statically defined, but it can also depend on the contents of the messages exchanged between the vehicle and the node (e.g. at processing blocks 418-420). The DH exchange can lead to a more secure key and/or encryption for subsequent message exchange, and in embodiments, may be exchanged before exchanging and validating certificates. In another embodiment, proposed session keys are asymmetric keys generated by each party (e.g. the vehicle and the node). That is, vehicle can encrypt subsequent communications using the node's proposed key, and vice versa.
In embodiments, as discussed herein, the encoded certificate may be a static certificate, which is issued once per vehicle and signed by a certificate authority operated by the manufacturer (or a third party trusted by, or under the direction of, the manufacturer). A certificate chain may then be stored on each car in the secure data store 226, so that vehicle can verify the certificates of other nodes. In another embodiment, the vehicle can have its own certificate authority that issues temporary certificates. This may be beneficial in the event that the network encryption key is ever compromised. The temporary certificates would again be part of the certificate chain to a root certificate of the manufacturer. Thus, the manufacturer could revoke certificates periodically, in response to user requests, in response to certain events (e.g., detected data and/or security breaches, detected malicious activity, etc.), etc.
Processing logic of
Processing logic then transmits the encrypted broadcast message response to the node (processing block 416). Processing logic may then receive, decrypt, and validate a parameter proposal message from the node (processing block 418) and use secure communications for establishing session key(s) for subsequent communications exchanged with the node (processing block 420). As indicated by the dashed arrow, several messages may be exchanged between processing logic of the vehicle and the node, for example during the generation and suggesting of asymmetric encryption keys, or during a DH exchange.
Once the session key(s) are established, processing logic exchanges one or more wireless messages with the node using the session key(s) (processing block 422). Now that the vehicle and the node have validated one another and established session key(s), they may securely communicate with one another as long as the session key(s) remain valid. The exchanged messages can include peer-to-peer network messages for data distribution, generation and or receipt of alerts, updates (e.g., software, system, firmware, etc.) distributed via a peer-to-peer network, traffic notifications, etc.
Referring to
When the encrypted parameter proposal message includes a MAC tag, processing logic validates the MAC tag in the encrypted parameter proposal message (processing block 504). In one embodiment, the verification includes using the shared network encryption key to decrypt the MAC tag and perform a MAC verification process to authenticate that the message's contents have not been altered, and the correct shared network encryption key is being used. Processing logic then decrypts the encrypted parameter proposal message using the shared network encryption key to obtain an intermedia decrypted version of the parameter proposal message (processing block 506), and decrypts the intermedia decrypted version of the parameter proposal message using the private key of the vehicle (processing block 508).
Once decryption is complete, the node ID, certificate signature, certificate, and certificate chain in the fully decrypted version of the parameter proposal message can be verified (processing block 510), as discussed herein. Processing logic may then establish session key(s) for subsequent communications exchanged with the node (processing block 512). For example, one or more messages may participate in an DH exchange process in which symmetric keys are generated cooperatively over one or more exchanged messages. As another example, an asymmetric public key private key pair for ruse with RSA, or similar, encryption is generated by processing logic. An encrypted response to the parameter proposal message is generated (processing block 514). For example, processing logic may return to processing block 502 to receive a response (e.g., to a series of DH exchange messages).
However, once the session keys are established, processing logic exchanges one or more wireless messages with the node encrypted using the session key(s) (processing block 516). As discussed above, the messages are encrypted using the negotiated encryption keys so that subsequently exchanged communications between the vehicle and the node are secured from unwanted disclosure. Furthermore, the established trust during the handshaking and parameter exchange are used as trust that can be inherited in other communication in a peer-to-peer network for data sharing and distribution.
Therefore, in view of the discussion set forth herein, the problems associated with trust, authentication, and data security in direct network connections are solved by the techniques, processes, and systems discussed herein. That is, the handshaking process authenticates the parties to one another, as well as well as established a party's proper role within a vehicle manufacturer's network. Furthermore, encryption keys and other data are exchanged and/or established using the techniques discussed herein to protect the data exchanged in the established connections. Additionally, using the techniques and data exchanged in each message, unwanted tracking is prevented thereby increasing privacy for the parties implementing the technique discussed herein.
Those of skill would appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.
The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.
In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software as a computer program product, the functions may be stored on or transmitted over as one or more instructions or code on a non-transitory computer-readable medium. Computer-readable media can include both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such non-transitory computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a web site, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of non-transitory computer-readable media.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the methods, systems, and apparatus of the present disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.