The introduction of payment related features into cars may make the car a target for malicious hackers.
The creation of the pay-at-pump use case introduces an additional point of failure into the payment chain in the form of the car itself.
A focus of payment technology is to reduce such vulnerabilities; a full security assessment will be a precursor to the development and deployment of such technology. Although penetration testing is prevalent in automotive software, it is by no means mandatory. If this threat is realized, it is likely that penetration testing will become a required part of the development process.
In the same way that automotive sector has safety at the heart of its technology, the financial sector focuses on security. Fraud prevention and data security are crucial to the success of these businesses.
In the context of software development, safety and security bear some similarities. They aim to protect, are subject to standards and regulation; and are implemented using technical and process measures.
This means that industries experienced in the implementation of safety critical software should be able to adapt to the development of secure software (and vice versa).
The main standards deployed for the development of financial software include PCI DSS and EMV. These standards are primarily concerned with specifying how the devices and processes should work, rather than how they are developed. PCI DSS describes information security; EMV describes how payment devices work and ensures compatibility across payment providers.
Other important technologies and techniques in the implementation of financial software include:
Card tokenization. As in all payments, this includes the substitution of sensitive data with non sensitive data, minimizing the handling of secure data.
Single-use keys. This is used for the one-time encryption and decryption of data, minimizing the risk associated with key loss or theft.
Encryption. This helps the conversion of data (in storage and during transmission) between readable and nonreadable formats, preventing the use of fraudulently acquired data.
These techniques are based on the implementation of algorithms; in modern SoC applications, these algorithms are frequently executed on a DSP or GPU rather than the host CPU. Although mobile payment applications may currently host such algorithms on CPUs, it may be advantageous to move these algorithms to a co-processor in an IVI system. The SoC is running many functions, performance enhancements may be achieved by sharing the load between processors in this way.
OS deployments in IVI systems currently include security features associated with the OS itself. Other related features provided by third parties are readily “integratable,” such as the Linux SMACK module or TrustZone-specific device drivers.
As vulnerabilities are identified and corrected, an effective way of deploying software updates to consumer owned vehicles will be required.
Such mechanisms are used on all mobile platforms today, and this provides the mechanism by which mobile payment software is updated. Similar mechanisms are available for IVI systems today, but they lack “immediacy”; updates are typically done by dealerships, not pushed out to users when available. There are no technical issues with the use of such methods in IVI systems: the problem is to be able to guarantee that over-the-air (OTA) updates do not cause issues for users, resulting in costly recalls.
