Automotive Cybersecurity Best Practices

This post provides insights on how to ensure the highest possible degree of security in the era of the intelligent connected car.

Introduction

The quickly growing automotive service market is generating new business cases such as car sharing, autonomous cars, digital keys, consumer services with mobile payment, and entertainment. Increased automation, vehicle-to-vehicle, and vehicle-to-infrastructure communications add cybersecurity and data privacy as cornerstones for consumer confidence and vehicle safety.

Delivering design and software solutions to the mobility world, we developed an engineering approach that provides a high degree of back-end and front-end security of connected car products. In this post, we are sharing this experience with the automotive community.

Automotive Cybersecurity Challenges

The main challenge for OEMs and engineering service providers is ensuring sufficient functionality of connected car solutions while maintaining the security of data access and transmission. Both of those goals can be achieved by designing a secure and efficient communication flow between a smart device and a vehicle.

Another challenge in vehicle cybersecurity is that the various electrical components in a car (known as electronic control units, or ECUs) are connected via an internal network. Thus, if hackers manage to gain access to a vulnerable, peripheral ECU — for instance, a car’s Bluetooth or infotainment system — from there they may be able to take control of critical ECUs like its brakes or engine. 

• Hardware security. Hardware security services build on top of hardware security and provide fast cryptographic performance, immutable device identification, message authentication, and execution isolation. 
• Software security. Software security services enhance security capabilities on top of the hardware with network enforcement, whitelists/blacklists, anomaly detection, cryptographic services, biometrics, secure over-the-air updates, and upgrade capabilities, all delivered over the life of the car. 
• Network security. With in-vehicle networks carrying a mix of operational and personally identifiable information—such as location, navigation history, call history, microphone recordings—protecting messages and data is critical for operational security and privacy.
• Cloud security. While embedded vehicle security is essential, some additional security services require real-time intelligence and updates, so the systems need to be able to connect to cloud-based security services in order to detect and correct threats before they get to the car.

In this post, we will go through core aspects of automotive software security in terms of back-end and front-end development. 

Back-end Security Techniques

As the volume of data to be processed and distributed in connected cars increases, software developers must deploy in-depth approaches allowing to protect back-end systems. At Bamboo Apps for each of the problems and goals of backend security design, we use numerous components and techniques.

Secure REST API Communication

HTTPS

REST (or REpresentational State Transfer) is an architectural style which is evolved into the HTTP/1.1 and URI specs and has been proven to be well-suited for developing distributed hypermedia applications. While REST is more widely applicable, it is most commonly used within the context of communicating with services via HTTP. 

Secure REST services must only provide HTTPS endpoints. This protects authentication credentials in transit, for example, passwords, API keys or JSON Web Tokens. Based on our experience, it also allows clients to authenticate the service and guarantee the integrity of the transmitted data.

Architecture

Software architects on our back-end team carefully think out what architecture works best for a specific client’s solution. We start from choosing the appropriate method to protect data when it is being transmitted. For this, we opt for Virtual Private Networks (VPN) or a Transport Layer Security model (TLS model). This technology protects web application data from unauthorized disclosure and modification when it is transmitted between clients and the server. The model can be easily adapted to client’s business needs. For example, a VPN connection may serve as the best solution to provide a mutual access to a shared server over a variety of protocols. Conversely, an Internet-facing enterprise web application would likely be better served by a TLS model.

Transport layer protection is necessary for back-end connections and any other connection where sensitive data is exchanged or where user identity is established. TLS is mainly a defense against man-in-the-middle attacks. TLS protocols are also effective in securing communications with external entities including telematics service providers, consumer smart devices and, in future, other vehicles and ITS infrastructure. 

The server validation component of TLS provides authentication of the server to the client. If configured to require client-side certificates, TLS can also play a role in client authentication to the server. However, in practice, client-side certificates are not often used in lieu of username and password based authentication models for clients. TLS also provides two additional benefits that are commonly overlooked: integrity guarantees and replay prevention. A TLS stream of communication contains built-in controls to prevent tampering with any portion of the encrypted data. In addition, controls are also built-in to prevent a captured stream of TLS data from being replayed at a later time.

It should be noted that TLS provides the above guarantees to data during transmission. TLS does not offer any of these security benefits to data that is at rest. Therefore appropriate security controls must be added to protect data while at rest within the application or within data stores.

The basic requirements for using TLS are: access to a Public Key Infrastructure (PKI) in order to obtain certificates, access to a directory or an Online Certificate Status Protocol (OCSP) responder in order to check certificate revocation status, and agreement/ability to support a minimum configuration of protocol versions and protocol options for each version.

Server Certificate

Establishing a certificate authority and managing certificates for servers allows each entity within the infrastructure to validate the other members’ identity and encrypt their traffic. To prevent man-in-the-middle attacks Bamboo Apps abides by the following Server Certificate Rules:

• We use strong keys & protect them;
• We use a certificate that supports required domain names;
• We use fully qualified names in certificates;
• We do not use wildcard certificates;
• We do not use RFC 1918 Addresses in Certificates;
• We use an appropriate certification authority for the application’s user base;
• We always provide all needed certificates;
• We are aware of and have a plan for the SHA-1 deprecation plan.

Server Protocol and Cipher Configuration

Bamboo Apps sticks to the following Server Protocol and Cipher Configuration rules.

Rule – Only Support Strong Protocols

SSL/TLS is a collection of protocols. The best practice for transport layer protection is to only provide support for the TLS protocols – TLS 1.0, TLS 1.1 and TLS 1.2. This configuration will provide maximum protection against skilled and determined attackers and is appropriate for applications handling sensitive data or performing critical operations.

Rule – Prefer Ephemeral Key Exchanges

When working with automotive companies on connected car projects we use Ephemeral key exchanges that are based on Diffie-Hellman and use per-session, temporary keys during the initial SSL/TLS handshake. They provide perfect forward secrecy (PFS), which means a compromise of the server’s long-term signing key does not compromise the confidentiality of past session. When the server uses an ephemeral key, the server signs the temporary key with its long-term key (the long-term key is the customary key available in its certificate).

Rule – Only to support strong Cryptographic Ciphers

Each protocol (TLSv1.0, TLSv1.1, TLSv1.2, etc) provides cipher suites. The strength of the encryption used within a TLS session is determined by the encryption cipher negotiated between the server and the browser. In order to ensure that only strong cryptographic ciphers are selected the server must be modified to disable the use of weak ciphers and to configure the ciphers in an adequate order. It is recommended to configure the server to only support strong ciphers and to use sufficiently large key sizes. In general, the following are observed by our team when selecting cipher suites:

• Use the very latest recommendations, they may be volatile these days;
• Setup policy to get a whitelist for recommended ciphers;
• Verify a cipher string;
• Inform yourself how to securely configure the settings for your used services or hardware;
• Check new software and hardware versions for new security settings.

Rule – Support TLS-PSK and TLS-SRP for Mutual Authentication

When using a shared secret or password offer TLS-PSK (Pre-Shared Key) or TLS-SRP (Secure Remote Password), which are known as Password Authenticated Key Exchange (PAKEs). TLS-PSK and TLS-SRP properly bind the channel, which refers to the cryptographic binding between the outer tunnel and the inner authentication protocol. Basic authentication places the user’s password on the wire in the plain text after a server authenticates itself. Basic authentication only provides unilateral authentication. In contrast, both TLS-PSK and TLS-SRP provide mutual authentication, meaning each party proves it knows the password without placing the password on the wire in the plain text. Using a PAKE removes the need to trust an outside party, such as a Certification Authority (CA).

Rule – Only Support Secure Renegotiations

A design weakness in TLS, identified as CVE-2009-3555, allows an attacker to inject a plaintext of his choice into a TLS session of a victim. In the HTTPS context, the attacker might be able to inject his own HTTP requests on behalf of the victim. The issue can be mitigated either by disabling support for TLS renegotiations or by supporting only renegotiations compliant with RFC 5746. All modern browsers have been updated to comply with this RFC.

Rule – Disable Compression

Compression Ratio Info-leak Made Easy (CRIME) is an exploit against the data compression scheme used by the TLS and SPDY protocols. The exploit allows an adversary to recover user authentication cookies from HTTPS. The recovered cookie can be subsequently used for session hijacking attacks.

Rule – Update Crypto Libraries

• Use solely versions of crypto libraries that are still supported;
• Watch out for vulnerabilities and update your crypto libraries on a regular base.

Access Control

Explicitly permit communications and messages only between pre-approved systems and sensors, block unapproved and inappropriate messages, and alert security systems about any invalid attempts. Manufacturers, maintenance organizations, owners, drivers, and even police and insurance companies will have different access rights to the car’s information systems that need to be authorized and controlled. 

In Bamboo Apps’ software development practice, access control is performed by REST services at each API endpoint. Web services in monolithic applications implement this by means of user authentication, authorisation logic and session management. This has several drawbacks for modern architectures which compose multiple microservices following the RESTful style.

• In order to minimize latency and reduce coupling between services, the access control decision should be taken locally by REST endpoints;
• User authentication should be centralized in an Identity Provider (IdP), which issues access tokens.

API Keys

API key is a code passed in by computer programs calling an application programming interface (API) to identify the calling program, its developer, or its user to the Web site. API keys are used to track and control how the API is being used, for example, to prevent malicious use or abuse of the API.

API keys will also reduce the impact of denial-of-service attacks. However, when they are issued to third-party clients, they are relatively easy to compromise. Our main duties when using API keys are the following:

• API keys for every request to the protected endpoint will be required;
• 429 “Too Many Requests” HTTP response code will be returned if requests are coming in too quickly;
• API key will be revoked if the client violates the usage agreement;
• We do not rely exclusively on API keys to protect sensitive, critical or high-value resources.

Secure HTTPS Headers

Our main recommendations for HTTP headers modifications:

• Set the Content-Security-Policy header to help prevent cross-site scripting attacks and other cross-site injections;
• Remove the X-Powered-By header;
• Add Public Key Pinning headers to prevent man-in-the-middle attacks with forged certificates;
• Set Strict-Transport-Security header that enforces secure (HTTP over SSL/TLS) connections to the server;
• Set Cache-Control and Pragma headers to disable client-side caching;
• Set X-Content-Type-Options to prevent browsers from MIME-sniffing a response away from the declared content-type;
• Set the X-Frame-Options header to provide clickjacking protection;
• Set X-XSS-Protection to enable the Cross-site scripting (XSS) filter in most recent web browsers.

SafetyNet Attestation API

The SafetyNet Attestation API helps assess the security and compatibility of the mobile environment in which an app runs. We use this API to analyze devices that have installed an app.

SafetyNet examines software and hardware information on the device where an app is installed to create a profile of that device. The service then attempts to find this same profile within a list of device models that have passed Android compatibility testing. The API also uses this software and hardware information to help assess the basic integrity of the device, as well as the APK information. This attestation helps to determine whether or not the particular device has been tampered with or otherwise modified. It also provides information about the app that is using this API so that you can assess whether the calling app is legitimate.

This API is to provide us with confidence about the integrity of a device running an app. We use the SafetyNet Attestation API as an additional in-depth defense signal as part of an anti-abuse system, not as the sole anti-abuse signal for your app.

Custom Authentication Scheme

Based on our experience in working with authentication services, we are convinced of the effectiveness of using an additional authentication server. This server provides a complete cost-effective multi-factor authentication, password replacement, and single sign-on authentication solution for traditional desktops, over the phone, in the browser or from any device.

Other Security Practices

Also, Bamboo Apps uses the following common security practices:

• File extension checking;
• Session tokens, credentials are only delivered over HTTPS;
• Check password quality;
• Check good and wrong attempts;
• Multi-factor authentication;
• Out-of-channel notification of account lockouts and successful password changes;
• Brute force protection;
• Secure cookie session;
• Restrict Injection: SQL, HTML, NoSQL etc;
• Restrict Cross-Site Scripting;
• Client-side and server-side validation rules;
• Sanitize filenames;
• Both server and client-generated keychain-pair for authentication device.

Configuration Management 

As a key part of Software Configuration Management, we developed a critical checklist of tasks to be performed during black box security testing of a web application. Our actions checklist:

• Check for commonly used application and administrative URLs;
• Check for old, backup, and unreferenced files;
• Check HTTP methods supported and Cross Site Tracing (XST);
• Test file extensions handling;
• Test RIA cross-domain policy;
• Test for security HTTP headers (e.g. CSP, X-Frame-Options, HSTS);
• Test for policies (e.g. Flash, Silverlight, robots);
• Check for sensitive data in client-side code (e.g. API keys, credentials).

Front-end Security Techniques

As auto manufacturers increasingly rely on software to evolve the connected and autonomous vehicle landscape, they cannot afford to be complacent when it comes to front-end security. With the approaches of effective back-end vehicle security defined above, the next step is to ensure trustworthy mechanisms and techniques, we implement for front-end security.

Up-to-date Cryptographic Algorithms

Cryptography plays an especially important role in securing the user’s data – even more so in a mobile environment, where attackers having physical access to the user’s device is a likely scenario. When assessing a mobile app, it’s necessary to make sure that it does not use cryptographic algorithms and protocols that have significant known weaknesses or are otherwise insufficient for modern security requirements. 

Algorithms that were considered secure in the past may become insecure over time; therefore, it’s still important to periodically check current best practices and adjust configurations accordingly.

For this reason, Bamboo Apps recommends using the following algorithms:

• Confidentiality algorithms: AES-GCM-256 or ChaCha20-Poly1305; 
• Integrity algorithms: SHA-256, SHA-384, SHA-512, Blake2; 
• Digital signature algorithms: RSA (3072 bits and higher), ECDSA with NIST P-384; 
• Key establishment algorithms: RSA (3072 bits and higher), DH (3072 bits or higher), ECDH with NIST P-384.

Strong Key Generation Functions

Cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size. For example, AES uses a key of exactly 16 bytes. A native implementation might use the user-supplied password directly as an input key. Bamboo Apps’ experience of using symmetric encryption with hard-coded cryptographic keys shows that a user-supplied password can be fraught with the following implications: 

• If the password is smaller than the key, the full key space isn’t used. The remaining space is padded (spaces are sometimes used for padding);
• A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.

With this in mind, when using password derivation functions, we propose to opt for an appropriate iteration count  (for example, NIST recommends and an iteration count of at least 10,000 for PBKDF2).

Strong Random Number Generators

Pseudo-random number generators (RNG) produce a stream of pseudo-random numbers – a stream of numbers that appear as if they were randomly generated. The quality of the generated numbers varies with the type of algorithm used. Cryptographically secure RNGs generate random numbers that pass statistical randomness tests and are resilient against prediction attacks.

Password Strength

Password strength is a key concern when passwords are used for authentication. The password policy defines requirements to which end users should adhere. A password policy typically specifies password length, password complexity, and password topologies. A “strong” password policy makes manual or automated password cracking difficult or impossible.

In an effort to secure strong password policy, we comply with the following requirements for password length:

• Minimum password length (10 characters) should be enforced;
• Maximum password length should not be too short because it will prevent users from creating passphrases. The typical maximum length is 128 characters.

According to requirements for password complexity passwords we use meet three out of the following four rules:

• At least one uppercase character (A-Z);
• At least one lowercase character;
• At least one digit (0-9);
• At least one special character.

Login Throttling

On the development stage of any automotive project, a source code needs to be checked for a throttling procedure: a counter for logins attempted in a short period of time with a given username and a method to prevent login attempts after the maximum number of attempts has been reached. After an authorized login attempt, the error counter should be reset.

When implementing brute force mitigation techniques, Bamboo Apps’ has identified four proven practices preventing logging attacks:

• After a few unsuccessful login attempts, targeted accounts we lock targets (temporarily or permanently), and additional login attempts should be rejected.
• We also use a five-minute account lock for temporary account locking.
• To prevent client-side controls from being easily bypassed, we implement additional controls on the server.
• Unauthorized login attempts will tally with respect to the targeted account, not a particular session.

Data Encryption on the Network

Bamboo Apps is aware that one of the core mobile app functions is sending/receiving data over untrusted networks like the Internet. This is why it is essential to rely on HTTP for communication with the backend. HTTPS wraps HTTP in an encrypted connection (the acronym HTTPS originally referred to HTTP over Secure Socket Layer (SSL); SSL is the deprecated predecessor of TLS). TLS allows authentication of the backend service and ensures confidentiality and integrity of the network data.

Ensuring proper TLS configuration on the server side is also important. Therefore, we consider TLS v1.2 and v1.3 to be secure. To ensure the highest possible security level for the server’s communication, the networking stack of an app should be tuned.

As an example in this regard we can mention the popular Android networking library OkHttp that uses the following preferred set of cipher suites (available only on Android versions 7.0 and later):

Similarly, the iOS ATS (App Transport Security) configuration requires one of the following ciphers:

Certificate Pinning

Protocols that rely on certificate chain verification, such as SSL/TLS, are vulnerable to a number of dangerous attacks, including man-in-the-middle attacks, which occur when an unauthorized party is able to view and modify all traffic passing between the mobile device and the back-end systems.

On Android side from version 7.0, we use the Network Security Configuration feature, to customize their network security settings in a safe, declarative configuration file without modifying app code.

Network Security Configuration (NSC) feature is also used by our team to perform declarative certificate pinning on specific domains. 

Testing for Sensitive Functionality Exposure through IPC Overview

During the process of development of a mobile application, Bamboo Apps applies traditional techniques for IPC, in particular, the use of shared files or network sockets. As mobile application platforms implement their own system functionality for IPC, these mechanisms should be applied as we consider them much more mature than traditional techniques. As shown by our experience, using IPC mechanisms with security in mind can cause the application to leak or expose sensitive data.

The list below shows Android IPC Mechanisms that may expose sensitive data:

• Binders; 
• Services; 
• Bound; 
• Services; 
• AIDL; 
• Intents;
• Content Providers.

The vulnerabilities can be identified in three ways:

• At the stage of security review (source code inspection);
• Static analysis;
• Dynamic analysis.

Protect to Store Sensitive Data in the Keyboard Cash

In order to simplify keyboard input, Bamboo Apps offers several options, like providing autocorrection or spell checking. Most of the keyboard input is cached by default. The application must ensure that data typed into text fields which contain sensitive information are not cached, it is achieved by disabling the feature programmatically.

Sensitive Data in Backups

iOS and Android offer auto-backup features that create copies of the data on the device. On iOS, backups should be made either through iTunes, or the cloud using the iCloud backup feature. In both cases, the backup includes nearly all data stored on the device, except for some highly sensitive things (like Apple Pay, Google Pay information and Touch ID settings).

Since an application backs up installed apps and their data, an obvious concern is whether sensitive user data stored by the app might unintentionally leak through the backup.

Sensitive Information on Screenshots

Manufacturers want to provide device users an aesthetically pleasing effect when an application is entered or exited, hence they introduced the concept of saving a screenshot when the application goes into the background. This feature could potentially pose a security risk for an application, as the screenshot containing sensitive information (e.g. a screenshot of an email or corporate documents) is written to local storage, where it can be recovered either by a rogue application on a jailbroken device or by someone who steals the device. For this very reason, Bamboo Apps uses a default screenshot that is cached whenever the application enters the background.

Network Communication for Car Unlock Operation

Communication starts after the secure HTTPS connection is established and certificate pinning process is finished. There are two phases of the communication: an initial login operation to authenticate a client and starting the Unlock service itself.

Developed by Bamboo Apps engineers, the scheme below illustrates an example of network communications for car unlock operation.

Conclusion

Modern vehicles are a point of growing concern among drivers, acting as mobile access points to sensitive personal data and entrusted with the physical security of the passengers within them. 

The automotive cybersecurity requires an in-depth approach that brings together multi-layer solutions, components, and techniques that should be considered early in both the back-end and front-end development phases. At Bamboo Apps, we are continually working on standardization and improvement of security measures to mitigate the security risk to a vehicle.

In pursuing this goal, we apply a range of practices that can help improve security at the back-end stage of development. PKI-based authentication mechanisms assist in securing internal communications, whereas transport layer security (TLS) can be effective in securing communications with external entities. The authenticity is verified by using digital certificates and confidentiality is maintained by encrypting all communication.

Providing front-end security requires the array of approaches commonly used in a mobile environment. When assessing a mobile app, up-to-date cryptographic algorithms are employed to secure the user’s data. A strong password policy, used for authentication, makes manual or automated password cracking difficult or impossible. Utilizing multiple tools, such as login throttling, certificate pinning, protecting sensitive data and information on screenshots are recommended to limit the extent of the threat and avoid cyber attacks.