US20180302228A1 - Systems and methods for secure communications in vehicle telematics systems - Google Patents

Abstract

A vehicle telematics system is provided having secure communication capabilities between a vehicle telematics device and external computing devices. In one embodiment, the vehicle telematics device includes a processor; a memory coupled to the processor and storing a vehicle telematics application; and a security chip coupled to the processor and the memory, wherein the security chip is configured to support a Transport Layer Security (TLS) stack.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This non-provisional United States (U.S.) patent application claims the benefit of U.S. Provisional Patent Application No. 62/481,437 entitled SYSTEMS AND METHODS FOR SECURE COMMUNICATIONS IN VEHICLE TELEMATICS SYSTEMS filed on Apr. 4, 2017 by inventor Peter Hergesheimer, incorporated herein by reference.
FIELD
• The embodiments generally relate to secure data communication of data by wireless networks.
BACKGROUND
• Telematics is the integrated use of telecommunications and informatics. Telematics units are installed in vehicles to provide a variety of telematics functionality in the vehicle. This functionality includes, but is not limited to, emergency warning systems, navigation functionality, safety warnings, and automated driving assistance. Telematics units are also capable of recording data related to the operation of the vehicle and providing that information for analysis, whether in real-time or during a time when the vehicle is being serviced. This information can be used in a variety of applications, such as fleet tracking, shipment tracking, insurance calculations, and in vehicle management and service.
• A Global Positioning System (GPS) is a space-based global navigation satellite system that utilizes a network of geo-synchronous satellites that can be utilized by a GPS receiver to determine its location. Many telematics systems incorporate a Global Positioning System (GPS) receiver that can be used to obtain the location of a vehicle at a certain measured time. Using the signals received by the GPS receiver, the heading information of the vehicle can be determined. A GPS receiver can determine velocity information in a variety of ways including, but not limited to, measuring the Doppler shift of the received signals and by comparing the location of a vehicle at a plurality of measured times. The acceleration of the vehicle can be determined as the change in speed divided by the time between the measurements. A GPS receiver's ability to determine acceleration can be limited due to the dependence of the measurement upon factors such as, but not limited to, reception and satellite availability. In addition to location information, a GPS receiver can also be configured to provide time data. However, measurements determined via a GPS receiver can contain errors that affect the accuracy of the measured information. In particular, GPS signals are vulnerable to signal delays, inconsistencies of atmospheric conditions that affect the speed of the GPS signals as they pass through Earth's atmosphere, and multipath distortions. Additionally, other factors not listed can influence GPS signals and result in measurement errors.
BRIEF SUMMARY
• The embodiments are best summarized by the claims included herein. Briefly, systems and methods for secure communications in vehicle telematics systems in accordance with the embodiments are disclosed.
BRIEF DESCRIPTIONS OF THE DRAWINGS
• FIG. 1 is a conceptual illustration of a vehicle telematics system in accordance with an embodiment.
• FIG. 2A is a conceptual illustration of a vehicle telematics device in accordance with an embodiment.
• FIG. 2B is a conceptual illustration of another vehicle telematics device in accordance with an embodiment.
• FIG. 3 is a chart showing example threat descriptions and corresponding security risk levels.
• FIG. 4 is a conceptual block diagram of a vehicle telematics system having existing security (e.g., base level security).
• FIG. 5 is a conceptual block diagram of a vehicle telematics system having Level-1 security (e.g., enhanced access protection).
• FIG. 6 is a conceptual block diagram of a vehicle telematics system having level-2 security (e.g., full TLS).
• FIG. 7 is a tree diagram showing a public key infrastructure (PKI) for the vehicle telematics system, which has level-2 security.
• FIG. 8 is a conceptual block diagram of a system for provisioning a vehicle telematics system having level-2 security.
• FIG. 9 is a chart showing example mitigation techniques for various threat descriptions and corresponding security risk levels.
DETAILED DESCRIPTION
• In the following detailed description of the embodiments, numerous specific details are set forth in order to provide a thorough understanding. However, it will be obvious to one skilled in the art that the embodiments may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.
• The embodiments include a method, an apparatus, and a system for secure communications in vehicle telematics systems. Many vehicles are equipped with a telematics unit. These telematics units can obtain and/or measure a variety of data regarding the conditions and/or location of the vehicle along with receiving and transmitting data to remote server systems. In order to facilitate these communications, the telematics units can include a radio transceiver, such as a cellular modem, which can be utilized to communicate with the remote server systems. However, these radio transceivers require a data plan or other cellular service specifically dedicated to the telematics unit. Additionally, many telematics units are only compatible with one service provider (e.g. cellular service provider), thereby requiring different versions of the telematics unit for different geographic regions and limiting the ability of a particular telematics unit to be utilized in all locations in which a particular vehicle may travel.
• In a variety of embodiments, the operational state of a vehicle is utilized to determine if a vehicle telematics device should transmit and/or receive data. In a number of embodiments, vehicle ignition state (i.e. the operational status of the vehicle) is ascertained by monitoring the vehicle for signs indicative of the vehicle ignition state without directly connecting to the vehicle ignition line. Information indicative of vehicle ignition state (i.e. vehicle status data) can be ascertained by observing characteristics of the vehicle including but not limited to the power supplied by the vehicle, vehicle vibration, communications on an OBD II port (e.g., on-board diagnostics connector) or other vehicle data bus line, and/or vehicle position information. In many embodiments, multiple different types of information are combined to ascertain the vehicle ignition state. Systems and methods for using an asset tracking device added to the vehicle after the manufacture of the vehicle without a direct connection to the vehicle ignition line that can be utilized to determine ignition state information in accordance with embodiments are described in U.S. Pat. No. 8,489,271, titled “Systems and Methods for Virtual Ignition Detection” and issued Jul. 16, 2013, the disclosure of which is hereby incorporated by reference in its entirety.
• Systems and methods for radio access interfaces in accordance with embodiments are further described in more detail herein.
Vehicle Telematics Systems
• Vehicle telematics systems in accordance with embodiments can transmit a variety of data between a remote server system and a vehicle telematics device using a mobile communications device. A conceptual diagram of avehicle telematics system100 in accordance with an embodiment is shown inFIG. 1. Thevehicle telematics system100 includes one or more vehicle telematics devices (110,110′, etc.). Thevehicle telematics device110 can communicate with amobile communications device116, a vehicle data bus112, and/or an input/output (I/O)interface114 as appropriate to the requirements of specific applications of embodiments.
• In a variety of embodiments, themobile communications device116 and/or thevehicle telematics device110 communicates with theremote server system130 via anetwork120. Thevehicle telematics device110′ may include themobile communications device116 to communicate to theremote server system130 over thenetwork120. Otherwise, thevehicle telematics device110 can be coupled in communication with themobile communications device116 in order for thevehicle telematics device110 to communicate with theremote server system130 over thenetwork120.
• In a variety of embodiments, thenetwork120 is the Internet. In many embodiments, thenetwork120 is any wired or wireless network, such as a cellular network, between thevehicle telematics device110′ and/or themobile communications device116 and theremote server system130. In a number of embodiments, theremote server system130 is implemented using a single server system. In several embodiments, theremote server system130 is implemented using multiple server systems.
• In a variety of embodiments, thevehicle telematics device110 is installed in a vehicle having a vehicle data bus112. In several embodiments, thevehicle telematics device110 is connected to a vehicle diagnostic connector that provides access to the vehicle data bus112. Thevehicle telematics device110 can obtain data from any of a variety of vehicle devices connected to the vehicle data bus112 utilizing any of a variety of techniques as appropriate to the requirements of specific applications of embodiments. Vehicle devices can include, but are not limited to, engine sensors, electronic control unit (ECU) devices, alternator sensors, vibration sensors, voltage sensors, oxygen sensors, Global Positioning System (GPS) receivers, ignition devices, weight sensors, wireless network devices, and/or acceleration determination devices. Systems and methods for connecting to a vehicle data bus that can be utilized in accordance with embodiments are described in SAE J1978, titled “OBD II Scan Tool,” first published by SAE International of Troy, Mich. on Mar. 1, 1992 and last updated Apr. 30, 2002. Systems and methods for obtaining data from devices connected to a vehicle data bus are described in SAE J1979, titled “E/E Diagnostic Test Modes,” first published by SAE International on Dec. 1, 1991 and last updated Aug. 11, 2014. The disclosures of SAE J1978 and SAE J1979 are hereby incorporated by reference in their entirety. In a number of embodiments, thevehicle telematics device110 is connected directly, either wired or wirelessly, to one or more sensors within the vehicle and/or does not utilize the vehicle data bus112.
• Thevehicle telematics device110 can include any of a variety of sensors and/or devices, including those described herein with respect to the vehicle data bus and any described in more detail herein, to obtain data regarding the status of the vehicle. Thevehicle telematics device110 can also communicate with any of a variety of sensors and/or devices using the I/O interface114. The I/O interface114 can be any connection, including wired and wireless connections, as appropriate to the requirements of specific applications of embodiments. In several embodiments, thevehicle telematics device110 can execute scripts to read data and/or perform particular processes. These scripts can be pre-loaded on the device and/or obtained from theremote server system130, vehicle data bus112, and/or the I/O interface114 as appropriate to the requirements of specific applications of embodiments. Thevehicle telematics device110 can be self-powered and/or connected into the electrical system of the vehicle in which thevehicle telematics device110 is installed. In a variety of embodiments, the vehicle telematics device is powered via the vehicle data bus112 and/or the I/O interface114. In many embodiments, thevehicle telematics device110 utilizes a Global Positioning System (GPS) receiver in order to determine the location, speed, and/or acceleration of the vehicle. In several embodiments, thevehicle telematics device110 obtains location data from themobile communications device116. However, it should be noted that any location-determining techniques, such as cellular tower triangulation, wireless network geolocation techniques, and dead reckoning techniques, could be utilized as appropriate to the requirements of specific applications of embodiments.
• In a variety of embodiments, thevehicle telematics device110,mobile communication device116, and/orremote server system130 provides a user interface allowing for visualizing and interacting with the data transmitted and/or received between the systems. In several embodiments, thevehicle telematics device110,mobile communications device116, and/orremote server system130 provides an interface, such as an application programming interface (API) or web service that provides some or all of the data to third-party systems for further processing. Access to the interface can be open and/or secured using any of a variety of techniques, such as by using client authorization keys, as appropriate to the requirements of specific applications.
• Although a specific architecture of a vehicle telematics system in accordance with embodiments are discussed with reference toFIG. 1, a variety of architectures, including sensors and other devices and techniques not specifically described herein, can be utilized in accordance with embodiments. Furthermore, the processes described herein can be performed using any combination the vehicle telematics device, mobile communications device, and/or the remote server systems as appropriate to the requirements of specific applications of embodiments.
Vehicle Telematics Devices
• Vehicle telematics devices in accordance with embodiments can transmit and receive data via a mobile communications device. A conceptual illustration of a vehicle telematics device in accordance with an embodiment is shown inFIG. 2A. Thevehicle telematics device110 includes aprocessor210 and asecurity chip215 in communication withmemory230. Thevehicle telematics device110 can also include one ormore communication interfaces220 capable of sending and receiving data. In a number of embodiments, thecommunication interface220 is in communication with theprocessor210, thesecurity chip215, thememory230, and/or the sensor device(s)240. In several embodiments, thememory230 is any form of storage configured to store a variety of data, including, but not limited to, avehicle telematics application232,sensor data234, andtelematics data236. In many embodiments, thevehicle telematics application232,sensor data234, and/ortelematics data236 are stored using an external server system and received by thevehicle telematics device110 using thecommunications interface220.
• Sensor devices240 can include RPM sensors, voltage sensors, GPS receivers, noise sensors, vibration sensors, acceleration sensors, weight sensors, and any other device capable of measuring data regarding a vehicle as appropriate to the requirements of specific applications of embodiments.Sensor devices240 can be included within thevehicle telematics device110 and/or located external to thevehicle telematics device110. Thevehicle telematics device110 can communicate with external sensor devices using thecommunications interface220, such as via a vehicle data bus, I/O interface (including serial interfaces),mobile communications device116, and/or a network connection as appropriate to the requirements of specific applications of embodiments. In a variety of embodiments, thevehicle telematics device110 is connected to a diagnostic connector (e.g., an OBD II port) in a vehicle. Thevehicle telematics device110 can also communicate with theremote server system130 through thecommunications interface220 and amobile communications device116 over thenetwork120.
• FIG. 2B is a conceptual illustration of thevehicle telematics device110′ in accordance with an embodiment. Thevehicle telematics device110′ includes themobile communications device116 coupled to thecommunications interface220 to communicate with theremote server system130 over thenetwork120.
• Thevehicle telematics application232 can direct theprocessor210 and/or thesecurity chip215 to perform a variety of secure communication processes, a number of which that can be performed in accordance with embodiments further described herein.
• Although specific architectures for vehicle telematics devices in accordance with embodiments are conceptually illustrated inFIG. 2A, any of a variety of architectures, including those that store data or applications on disk or some other form of storage and are loaded into memory at runtime, can also be utilized. Additionally, any of the data utilized in the system can be cached and transmitted once a network connection (such as a wireless network connection via the communications interface) becomes available. In a variety of embodiments, a memory includes circuitry such as, but not limited to, memory cells constructed using transistors, that are configured to store instructions. Similarly, a processor can include logic gates formed from transistors (or any other device) that dynamically perform actions based on the instructions stored in the memory. In several embodiments, the instructions are embodied in a configuration of logic gates within the processor to implement and/or perform actions described by the instructions. In this way, the systems and methods described herein can be performed utilizing both general-purpose computing hardware and by single-purpose devices.
Secure Communications
• FIG. 3 is achart300 showingexample threat descriptions305 and correspondingsecurity risk levels310.Example threat descriptions305 having asecurity risk level310 of “critical” include at least the following: Over-the-Air (OTA) updates that are not encrypted or signed, OTA updates that are initiated without authentication, communications security (COMSEC) having no end-to-end encryption, man-in-the-middle (MITM) attack (especially on Global System for Mobile Communications (GSM)), and a Short Message Service (SMS) interface that is not authenticated (e.g., subject to MITM attacks).
• Example threat descriptions305 having asecurity risk level310 of “high” include at least the following: Domain Name System (DNS) spoofing (e.g., communication sent to wrong server) and information disclosure in an Assisted Global Positioning System (A-GPS) component. Thevehicle telematics system100 may undergo other threats not shown inFIG. 3.
• In thevehicle telematics system100 ofFIG. 1, a primary security threat is remote access by an external computing device. For example, an external computing device might attack thevehicle telematic system100 according to one of thethreat descriptions305 listed inFIG. 3. There are at least three levels of security protection to address a primary threat: existing security (e.g., readily available or base level security), Level-1 security (e.g., enhanced access protection), and level-2 security (e.g., full Transport Layer Security (TLS)). A secondary (non-primary) threat is physical access to thevehicle telematics system100.
• FIG. 4 is a conceptual block diagram of avehicle telematics system400 having existing security (e.g., base level security). Thevehicle telematics device110 can communicate with amaintenance server434, acustomer server432, and/or themobile communications device116. The communication by thevehicle telematics device110 with servers or other devices can be performed with various protocols, such as transmission control protocol (TCP)/internet protocol (IP) and/or user datagram protocol (UDP)/internet protocol (IP) for example.
• Thevehicle telematics device110 sends inbound encrypted data to acustomer server432. The inbound encryption provides intercept protection (e.g., protection from an interception attack) on data generated by thevehicle telematics device110. Thevehicle telematics device110 and/or thecustomer server432 stores a cryptographic key (e.g., public encryption key and/or private decryption key) as a configuration parameter.
• Thecustomer server432 sends password authentication to access thevehicle telematics device110. The password authentication provides remote access protection (e.g., protection from a remote access attack). Thevehicle telematics device110 and/or thecustomer server432 stores password authentication as a configuration parameter.
• Themobile communications device116 sends an SMS password to the vehicle telematics device. The SMS password provides remote access protection (e.g., protection from a remote access attack). Thevehicle telematics device110 and/or themobile communications device116 stores SMS password authentication as a configuration parameter.
• The vehicle telematics device can receive an attention (AT) command password from a local device (e.g., local terminal program). The AT command password provides local access protection (e.g., protection from a malicious user). The AT command password is typically the same password as the SMS password.
• FIG. 5 is a conceptual block diagram of avehicle telematics system500 having Level-1 security (e.g., enhanced access protection). Thevehicle telematics device110 can communicate with themaintenance server434, thecustomer server432, and/or themobile communications device116.
• Thevehicle telematics device110 can send an encrypted inbound message to acustomer server432. The encryption provides intercept protection (e.g., protection from an interception attack) on data generated by thevehicle telematics device110. Thevehicle telematics device110 and/or thecustomer server432 stores cryptographic keys and settings as configuration parameters. To the portions of an inbound message, thevehicle telematics device110 can apply the encryption to the payload and vehicle identification number (VIN) in an option header. A cryptographic key is based on a proprietary stream cipher. Thevehicle telematics device110 typically does not apply encryption to the maintenance server interface.
• Thecustomer server432 can send authenticated outbound messages to one or morevehicle telematics devices110. The outbound authentication protects authenticity and integrity of messages that thecustomer server432 sends to thevehicle telematics devices110. To authenticate an outbound message, the sender (e.g., customer server432) calculates a digital signature of the message combined with a secret key. The authentication code or signature is calculated by using the entire message (e.g., options, header, payload, etc.). To authenticate outgoing messages, thecustomer server432 can use, for example, keyed-hash message authentication code Merkle-Damgård hash function 5 (HMAC-MD5), 16-byte digest. The secret authentication keys used in the message authentication are unique to eachvehicle telematics device110 and each interface (e.g., inbound interface, maintenance interface at thevehicle telematics device110, etc.). The sender (e.g., customer server432) sends the signature along with the message. The receiver (e.g., vehicle telematics device110) of the message authenticates the message by verifying the digital signature that is sent with the message matches a signature that the receiver calculates by using the received message combined with the secret key.
• Themaintenance server434 and/or thecustomer support server432 can authenticate files transmitted to one or morevehicle telematics devices110. The file authentication provides file tampering protection by validating authenticity and integrity of files using a digital signature of the file transmitted along with the file. Themaintenance server434 and/or thecustomer support server432 applies file authentication to all files transmitted to thevehicle telematics device110. Themaintenance server434 and/or thecustomer support server432 supports the file authentication protocol. To authenticate files, themaintenance server434 can use, for example, an RSA Security/Secure Hash Algorithm two hundred and fifty-six (RSA/SHA-256) digital signature algorithm. The cryptographic keys used by thevehicle telematics device110 to validate the digital signature of the file can be embedded in the software code of thevehicle telematics device110.
• Themobile communications device116 can authenticate SMS messages for transmission to thevehicle telematics device110. The SMS authentication provides remote access protection (e.g., protection from a remote access attack). Themobile communications device116 and thevehicle telematics device110 can handle the SMS authentication. In one embodiment, SMS authentication is substantially the same as message authentication (e.g., HMAC-MD5), which is discussed with reference toFIGS. 4 and 5. Accordingly, the SMS authentication includes use of a cryptographic key that is similar to a cryptographic key used in message authentication. SMS authentication can complicate SMS access at themobile communications device116 and/or thevehicle telematics device110. Accordingly, a software application to handle SMS authentication may be required to be loaded onto themobile communications device116 and onto thevehicle telematics device110.
• Thecustomer server432 can generate authentication keys from a seed (e.g., some non-secret value) and an electronic serial number (ESN) of thevehicle telematics device110. For example, thecustomer server432 can provide and manage a seed and an authentication key for each for eachvehicle telematics device110. Eachvehicle telematics device110 can generate a seed and an authentication key for each interface at thevehicle telematics device110.
• In one embodiment, protection can be enabled remotely but cannot be disabled remotely. For example, themobile communications device116, thecustomer server432, and/or themaintenance server434 can remotely enable protected communication with thevehicle telematics device110. However, neither themobile communications device116, thecustomer server432, nor themaintenance server434 can remotely disable protected communication with thevehicle telematics device110.
• FIG. 6 is a conceptual block diagram of avehicle telematics system600 having level-2 security (e.g., full TLS). Thevehicle telematics device110 can communicate with themaintenance server434, thecustomer server432, and/or themobile communications device116.
• Thecustomer server432 and/or themaintenance server434 can communicate (e.g., transmit data) with thevehicle telematics device110 via transmission control protocol (TCP)/transport layer security (TLS) session security. For example, the devices of thevehicle telematics system600 can support TLS for TCP and hypertext transfer protocol (HTTP). The devices of thevehicle telematics system600 do not have user datagram protocol (UDP) support. The TCP/TLS session security provides protection via authentication and encryption. Thevehicle telematics system600 applies the TCP/TLS session security to all internet protocol (IP) interfaces (e.g., inbound interface, maintenance interface, etc.). The TCP/TLS session security uses public-key cryptography with public key infrastructure (PKI) certificates.
• Like Level-1 security ofFIG. 4, themaintenance server434 and/or thecustomer support server432 inFIG. 5 can also authenticate files transmitted to one or morevehicle telematics devices110. The file authentication provides file tampering protection by validating authenticity and integrity of files using a digital signature of the file transmitted along with the file. Themaintenance server434 and/or thecustomer support server432 applies file authentication to all files transmitted to thevehicle telematics device110. Themaintenance server434 and/or thecustomer support server432 supports the file authentication protocol. To authenticate files, themaintenance server434 can use a digital signature algorithm, for example, an RSA Security/Secure Hash Algorithm two hundred and fifty-six (RSA/SHA-256) digital signature algorithm. The cryptographic keys used by thevehicle telematics device110 to validate the digital signature of the file can be embedded in the software code of thevehicle telematics device110.
• Like Level-1 security ofFIG. 4, themobile communications device116 inFIG. 5 can also authenticate SMS messages for transmission to thevehicle telematics device110. The SMS authentication provides remote access protection (e.g., protection from a remote access attack). In one embodiment, SMS authentication is substantially the same as message authentication (e.g., HMAC-MD5), which is discussed with reference toFIGS. 4 and 5.
• FIG. 7 is a tree diagram showing a public key infrastructure (PKI)700 for thevehicle telematics system600, which has level-2 security. ThePKI700 shows how thevehicle telematics system600 ofFIG. 6 manages security certificates. A certificate authority or certification authority (CA) is a third-party computing device that issues digital certificates. A digital certificate certifies the ownership of a public encryption key by the named subject of the certificate. This allows other parties to rely upon signatures or on assertions made about the private decryption key that corresponds to the certified public encryption key. A certificate authority acts as a trusted third party that is trusted both by the subject (owner) of the certificate and by the party relying upon the certificate.
• Amain certificate authority705 signs end-point certificate authority certificates for thevehicle telematics system600, including one or moremobile telematics devices110, themaintenance server434, thecustomer server432, and another customer server715. Themain certificate authority705 signs acustomer certificate authority710 for the customer server715. Computing devices in thetelematics system600 exchange certificate authority certificates during TLS session negotiations. Computing devices in thetelematics system600 can install device certificates and/or certificate authority certificates by using, for example, authenticate-then-encrypt (AtE).
• FIG. 8 is a conceptual block diagram of asystem800 for provisioning avehicle telematics system600 having level-2 security. The system includes, without limitation, automatic test equipment (ATE)805, avehicle telematics device110, and amain certificate authority705. Thesystem800 typically performs provisioning in, for example, a factory and offline from thevehicle telematics system600.
• Thevehicle telematics device110 uses thesecurity chip215 to generate a public-private cryptographic key pair. Thevehicle telematics device110 can securely store the private cryptographic key. Thevehicle telematics device110 combines a customer identity provided by the ATE805 with the public cryptographic key to generate a certificate signing request (CSR) for thevehicle telematics device110. The customer identity is optional security that ensures thevehicle telematics device110 will only connect with the correct customer server715. The ATE805 passes the CSR to themain certificate authority705. Themain certificate authority705 signs the authentication certificate. Onto thevehicle telematics device110, thesystem800 loads (1) the signed authentication certificate for thetelematics device110 and (2) a copy of the certificate authority's own certificate or certificates signed by themain certificate authority705. Thevehicle telematics device110 securely stores the signed authentication certificates in thesecurity chip215.
• FIG. 9 is achart900 showingexample mitigation techniques905 forvarious threat descriptions305 and correspondingsecurity risk levels310. Thethreat descriptions305 and correspondingsecurity risk levels310 are discussed with reference toFIG. 3. Thevehicle telematics system100 may undergo other threats not shown inFIG. 9. To mitigate Over-the-Air (OTA) updates that are not encrypted or signed, thevehicle telematics system100 may include file authentication (e.g., level-1 security and level-2 security). To mitigate OTA updates that are initiated without authentication, thevehicle telematics system100 may include direct message authentication (e.g., level-1 security and level-2 security). To mitigate communications security (COMSEC) having no end-to-end encryption, thevehicle telematics system100 may encrypt data at the vehicle telematics device110 (e.g., base level security and level-1 security). Thevehicle telematics system100 may alternatively encrypt data at all end points, including thevehicle telematics device110, thecustomer server432, and the maintenance server434 (e.g., level-2 security). To mitigate man-in-the-middle (MITM) attack (especially on Global System for Mobile Communications (GSM)), thevehicle telematics system100 may include direct message authentication, file authentication, message encryption, and file encryption (e.g., level-1 security and level-2 security). To mitigate Short Message Service (SMS) interface that is not authenticated (e.g., subject to MITM attacks), thevehicle telematics system100 may SMS authentication (e.g., level-1 security and level-2 security). To mitigate Domain Name System (DNS) spoofing (e.g., communication sent to wrong server), thevehicle telematics system100 may include server authentication (e.g., level-2 security). To mitigate information disclosure in an Assisted Global Positioning System (A-GPS) component, thevehicle telematics system100 may randomize the GPS position in an AGPS request associated with thevehicle telematics device110.
Practical Implementation Considerations
• Level-2 TLS requires some important implementation considerations. Operations of a TLS stack require additional and sufficient memory resources (e.g., 30 kilobytes of RAM, 100 kilobytes of flash memory). A security stack is a group of software/firmware programs that work in tandem to produce a result or achieve a common goal (e.g., a goal of configuring a processor to carry out security operations). Sufficient memory for a TLS stack is unavailable in typical commercial products (e.g., typical vehicle telematics devices).
• In one embodiment, a vehicle telematics device requires the addition of hardware, such assecurity chip215 ofFIG. 2A. Thesecurity chip215 may be included on an add-on security processor board and is enabled to support a security stack (e.g., TLS stack). Alternatively, a security stack can be integrated into theprocessor210.
• In one embodiment, theprocessor210 is upgraded to have more RAM and more hardware cryptography support. One convenient solution is for theprocessor210 to be a drop-in replacement for a processor that may presently be on a vehicle telematics device. With sufficient modification to theprocessor210, there may not be a need for theseparate security chip215.
• In one embodiment, thevehicle telematics device110 can use a cellular radio Secure Socket interface (e.g., HTTPS). This embodiment is dependent on which cellular radios and which radio firmware (e.g., which type of mobile communications device116) are deployed in thevehicle telematics device110. This embodiment is limited to cellular-only solutions without a dial-up network (DUN) (e.g., mobile data terminal (MDT) interface).
• In one embodiment, thehardware security chip215 supports cryptographic key generation. Accordingly, private encryption key insertion into thevehicle telematics device110 is not required to take place offline at the factory (e.g., not required to take place online while thevehicle telematic system100 is active). Thesecurity chip215 can support secure storage of cryptographic keys and authentication certificates.
• In one embodiment, thevehicle telematics device110 includes hardware to support Bluetooth Low Energy (BLE) radio. Bluetooth communication capability enables thetelematics device110 to communicate with other devices (e.g., mobile communications device116) via the Bluetooth wireless technology standard.
• In one embodiment, thevehicle telematics device110 includes level-3 physical security to protect against physical attacks. For example, thevehicle telematics device110 may include at least one of the following: read-out protection, secure boot for authentication of a run-time image, adding authentication to the attention command (ATCmd) interface, and/or encrypting data stored on an external memory device (e.g., flash memory coupled to the serial peripheral interface (SPI) bus).
Other Embodiments
• Although the embodiments have been described in certain specific aspects, many additional modifications and variations would be apparent to those skilled in the art. In particular, any of the various processes described herein can be performed in alternative sequences and/or in parallel (on the same or on different computing devices) in order to achieve similar results in a manner that is more appropriate to the requirements of a specific application. It is therefore to be understood that the embodiments can be practiced otherwise than specifically described without departing from the scope and spirit. Thus, the embodiments should be considered in all respects as illustrative and not restrictive. It will be evident to the person skilled in the art to freely combine several or all of the embodiments discussed here as deemed suitable for a specific application. Throughout this disclosure, terms like “advantageous”, “exemplary” or “preferred” indicate elements or dimensions that are particularly suitable (but not essential) to an embodiment, and that may be modified wherever deemed suitable by the skilled person, except where expressly required.
• While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad disclosure, and that the embodiments not be limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art.
• When implemented in software, the elements of the embodiments are essentially the code segments to perform the necessary tasks. The program or code segments can be stored in a processor readable medium or transmitted by a computer data signal embodied in a carrier wave over a transmission medium or communication link. The “processor readable medium” may include any medium that can store or transfer information. Examples of the processor readable medium include an electronic circuit, a semiconductor memory device, a read only memory (ROM), a flash memory, an erasable programmable read only memory (EPROM), a floppy diskette, a CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc. The code segments may be downloaded via computer networks such as the Internet, Intranet, etc.
Conclusion
• While this specification includes many specifics, these should not be construed as limitations on the scope of the disclosure or of what may be claimed, but rather as descriptions of features specific to particular implementations of the disclosure. Certain features that are described in this specification in the context of separate implementations may also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation may also be implemented in multiple implementations, separately or in sub-combination. Moreover, although features may be described herein as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination may in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variations of a sub-combination. While embodiments have been particularly described, they should not be construed as limited by such embodiments, but rather construed according to the claims included herein.

Claims (20)

What is claimed is:

1. A vehicle telematics device, comprising:

a processor;

a memory coupled to the processor and storing a vehicle telematics application; and

a security chip coupled to the processor and the memory, wherein the security chip is configured to support a Transport Layer Security (TLS) stack.

2. The vehicle telematics device ofclaim 1, wherein:

the memory is sufficient to handle operations of the Transport Layer Security (TLS) stack.

3. The vehicle telematics device ofclaim 2, wherein:

the memory includes at least 30 kilobytes of random access memory (RAM) and 100 kilobytes of flash memory.

4. The vehicle telematics device ofclaim 1, wherein:

the security chip can generate and securely store a cryptographic key.

5. The vehicle telematics device ofclaim 1, further comprising:

a communications interface coupled to the processor and to a data bus of a vehicle.

6. The vehicle telematics device ofclaim 5, further comprising:

one or more sensor devices coupled to the data bus, capable of measuring sensor data regarding the vehicle, and configured to store the sensor data in the memory.

7. The vehicle telematics device ofclaim 1, wherein:

the vehicle telematics device can communicate with a customer server; and

the security chip can transmit encrypted data to the customer server via a Transmission Control Protocol (TCP)/Transport Layer Security (TLS) security session.

8. The vehicle telematics device ofclaim 1, wherein:

the vehicle telematics device can communicate with a mobile communications device; and

the security chip can apply Short Message Service (SMS) authentication via challenge-response authentication with the mobile communications device.

9. The vehicle telematics device ofclaim 1, wherein:

the vehicle telematics device can communicate with a maintenance server; and

the security chip can transmit encrypted data to the maintenance server via a Transmission Control Protocol (TCP)/Transport Layer Security (TLS) security session.

10. The vehicle telematics device ofclaim 1, wherein:

the vehicle telematics device can communicate with a certificate authority; and

the security chip is configured to receive a signed certificate authority certificate authority certificate from the certificate authority.

11. A vehicle telematics system, comprising:

a vehicle telematics device, including

a processor,

a memory coupled to the processor and storing a vehicle telematics application, and

a security chip coupled to the processor and the memory, wherein the security chip is configured to support a Transport Layer Security (TLS) stack.

12. The vehicle telematics system ofclaim 11, wherein:

the memory is sufficient to handle operations of the Transport Layer Security (TLS) stack.

13. The vehicle telematics system ofclaim 12, wherein:

the memory includes at least 30 kilobytes of random access memory (RAM) and 100 kilobytes of flash memory.

14. The vehicle telematics system ofclaim 11, wherein:

the security chip can generate and securely store a cryptographic key.

15. The vehicle telematics system ofclaim 11, wherein:

the vehicle telematics device further includes a communications interface coupled to the processor and to a data bus of a vehicle.

16. The vehicle telematics system ofclaim 15, wherein:

the vehicle telematics device further includes one or more sensor devices coupled to the data bus, capable of measuring sensor data regarding the vehicle, and configured to store the sensor data in the memory.

17. The vehicle telematics system ofclaim 11, further comprising:

a customer server in communication with the vehicle telematics device, wherein the security chip can transmit encrypted data to the customer server via a Transmission Control Protocol (TCP)/Transport Layer Security (TLS) security session.

18. The vehicle telematics system ofclaim 11, further comprising:

a mobile communications device in communication with the vehicle telematics device, wherein the security chip can apply Short Message Service (SMS) authentication via challenge-response authentication with the mobile communications device.

19. The vehicle telematics system ofclaim 11, further comprising:

a maintenance server in communication with the vehicle telematics device, wherein the security chip can transmit encrypted data to the maintenance server via a Transmission Control Protocol (TCP)/Transport Layer Security (TLS) security session.

20. The vehicle telematics system ofclaim 11, further comprising:

a certificate authority in communication with the vehicle telematics device, wherein the security chip is configured to receive a signed certificate authority certificate authority certificate from the certificate authority.

Images