Secure and ubiquitous: Vehicle computers bring new security challenges

3Proprietary vehicle system platforms are giving way to affordable hardware and software from standards-based embedded systems, many of which derive their heritage from mobile computers and wireless networks. A computing device on a vehicle can tap into the same wireless networks as any other mobile computer, allowing an enterprise to extend its own network into the mobile fleet of vehicles. The technical challenge has shifted to the need for secure computing and communication after the divergence from using proprietary networks.

For decades, vehicle-based computing has been a siren call to embedded system developers who are lured by the enticing notion that after-market embedded computers are needed for billions of cars, trucks, trains, buses, forklifts, road equipment, farm vehicles, and virtually anything else that moves. Most expeditions into these vehicle-based computing markets have ended up on the rocks; specialized services companies, however, are an exception that found safe passage through market niches that required custom hardware and proprietary networks. While inherently more secure than open platforms, proprietary solutions created a barrier to the growth of vehicle computing. New standards-based approaches to small form factor computing and wireless networking have brought cost and complexity down enough to open up broader markets that span from GPS-based anti-theft devices to entertainment systems, from inventory management consoles to card-readers, from cars to forklifts, and so on for hundreds of evolving product categories. These applications bring new requirements for secure computing, and embedded system designers should turn to hardware-based cryptography over software methods to meet the power constraints for vehicle-based SFF devices.

Security now a high priority for portable systems

While modern, vehicle-based computers share many technical features with portable Internet devices, designers face challenging constraints that require a rugged, fanless design with a broad range of connectivity options (Figure 1). Vehicle computing can adapt standards-based mobile technology to create cost-effective SFF systems, but the security issues may be even more severe for a vehicle computer than for a portable device. Vehicle computers differ from portable systems in a fundamental way that impacts security: While a laptop or tablet is expected to be physically secured and disabled if lost or stolen, the computer system in a vehicle may require a secure design to resist tampering that might compromise the communications network or vehicle systems. For instance, consider the security concerns for a mobile kiosk in the back seat of a taxi. In the past, a kiosk designer might have minimized the security features, anticipating that the product would operate in a public location. Instead, the kiosk can now be portable and perhaps subject to physical tampering. The owner of the corporate network cannot always guarantee physical security for the vehicle computer, so the system needs robust cryptography that also resists tampering by malicious software that can infect the device.

21
An embedded mobile computing device for vehicle computing often has requirements such as a rugged fanless design with many connectivity options (VIA -5450 In-Vehicle Embedded Computer with external GPS antenna).
(Click graphic to zoom by 1.9x)

Cryptography validated for the U.S. government

First of all, designers of vehicle computers can take advantage of security standards that have been developed by the National Institute of Standards and Technology (NIST) as part of Federal Information Processing Standards (FIPS) 140-2 cryptography. All FIPS 140-2 systems require the use of certified cryptographic algorithms, which must be validated by independent testing labs. Even if a vehicle system designer doesn’t need full FIPS 140-2 certification, these U.S. government standards provide excellent guidelines for building secure systems.

These standards also specify varying levels of physical security that can be used to protect the embedded computing system in a vehicle computer. For example, FIPS 140-2 Security Level 2 requires that a system shows evidence of tampering and authenticates the role of the user, but the system doesn’t necessarily have to defend against physical attack. Level 3 requires identity-based authentication and some physical defense against tampering. Level 4 is reserved for the most-secure systems and requires an “envelope of protection” that seals the system from all attacks. For embedded system designers, complying with Levels 3 and (especially) 4 can be a thermal design challenge because the systems are sealed with little airflow. This thermal restriction becomes problematic for designs that require a high-performance processor to run software-based encryption.

Better security with hardware-based cryptography

With the transition away from proprietary wireless networks, vehicle computers must create an encrypted tunnel through less-secure mobile Internet connections. Secure systems might use software methods such as Internet Protocol Security (IPsec) to encrypt packets, or the vehicle computer designer could implement a higher layer protocol, such as Transport Layer Security (TSL) or Secure Sockets Layer (SSL), to encrypt records of encapsulated packets. Each of these protocols requires a secure cipher for the actual encryption of data. Most secure systems handling financial transactions (as well as the U.S. government) now require an encryption cipher that is based on the Advanced Encryption Standard (AES), but the processing overhead for AES encryption can dramatically limit the data rate. Hardware-based security implementations accelerate AES and are inherently more efficient, delivering better security within the SFF design constraints of a vehicle computer.

Software cryptography data rates limited by CPU power consumption

Software-based cryptography can be more than a hundred times slower than the equivalent algorithm running in hardware, a comparison documented by Michael Ludvig in 2005[1] after testing with OpenSSL (AES-128 EBC mode on 8K blocks). While a desktop computer may have enough performance to implement software cryptography, an embedded system is power-constrained and may not be able to process high data rates in a fanless design. To quantify the power constraints, system designers can reference vendor testing with OpenSSL (AES-256-CBC with 8K blocks), while normalizing the data for CPU Thermal Design Power (TDP). Using standard OpenSSL tests, a high-end workstation CPU was not able to exceed 4 MBps/W (TDP) using software-based encryption. However, an with hardware acceleration can deliver 90 MBps/W (TDP) of AES-encrypted data[2]. While a vehicle computer may not need high data rates for a wireless Internet communication channel, some systems communicate with other devices in the vehicle and require a secure, high-speed connection. Some vehicle computers may include non-volatile local data storage, requiring the system to encrypt the file system in and avoid the security risks of systems that are not physically secured.

Software cryptography’s less random number entropy

Good security starts with good random numbers, and hardware-based random number generation is faster with better entropy (randomness). Software-generated random numbers are calculated from samples of multiple, independent system events to create pseudo-random numbers. A hardware random number generator uses a specialized circuit to measure a statistically random hardware event, such as thermal noise on a diode or by XORing multiple, free-running oscillators. While a hardware implementation can produce more than 10 Mbps of random numbers with high entropy, the speed of software will depend on the number of events that are monitored to improve randomness. Using fewer events can increase the security risk that an attacker might predict a random number by manipulating the events the software is measuring. Additionally, a software-based random number generator operates on values in memory, which could be compromised with physical access.

Hardware cryptography requires a trade-off between cost and security

Higher levels of security require a dedicated, tamper-resistant cryptoprocessor with trusted key storage and network authentication. However, the extra hardware adds cost to the system – especially for vehicle computers that need AES encryption with high data rates. Most cryptoprocessors are low-performance microcontrollers that are used for securing transactions, though enormous volumes have been shipped with smart cards. The most cost-effective approach to securing high-speed data on a vehicle computer would use the existing host CPU and transparently accelerate cryptographic algorithms. With CPU acceleration, most cryptographic operations can run at the full speed of the memory, effectively removing cryptography as a performance bottleneck. The system architecture could also use a physically secured cryptoprocessor in conjunction with a CPU that accelerates the high-speed cryptography, while creating a trusted computing environment for software. Some high-end Intel processors now support Advanced Encryption Standard New Instructions (AES-NI) cryptographic acceleration. All VIA Technologies processors, including the VIA Nano CPU used in its vehicle computers, integrate hardware cryptography through its PadLock implementation of AES (FIPS 197) and Secure Hash (FIPS 180-2), which have both received NIST validation.

Networking options still available in a secure system

As vehicle computing continues to expand to more applications, hopefully system designers will recognize the need for secure computing in all devices that have some risk of compromised data. With modular systems, a wide variety of wireless interfaces can be customized onto a secure computing platform. Figure 2 shows an open view of the ART-5450, which includes an Em- form factor board, from VIA Technologies; it allows the system designer to tailor the triple-antenna system to optionally support GPS modules and Wireless Local Area Network (WLAN) technologies like Bluetooth and 802.11x, while also offering options for Wireless Wide Area Networking (WWAN) modules to match the chosen service provider.

22
An Interior view of an in-vehicle PC shows a modular approach to wireless connectivity for secure vehicle computing (VIA -5450 In-Vehicle Embedded Computer with GPS, WLAN, and WWAN).
(Click graphic to zoom)

Security standards will help grow vehicle computing

The siren song of vehicle computing is as loud as ever, but many of the hidden dangers have been overcome as component suppliers have continued to integrate functionality – first into , and now into subsystem products that are thermally, mechanically, and electrically optimized for vehicle computing. With more CPU vendors enabling cryptographic acceleration as a standard feature, the system designers won’t have to trade off security to meet other design goals for vehicle computing. The system developers can build on a secure platform while creating entirely new classes of products for the rapidly growing vehicle computing markets.

References

  1. “VIA PadLock – Wicked Fast Encryption” http://www.logix.cz/michal/doc/article.xp/padlock-en
  2. “VIA PadLock™ Security Engine is Certified by the US National Institute of Standards and Technology” White Paper, December 2009. Contact VIA Technologies for full text.

J. Scott Gardner is President and Principal Analyst at LLC. He is an engineer and consultant who began his career 25 years ago designing microprocessor-based systems. He has served in various marketing and management roles in the semiconductor industry, most notably during 10 years at IDT. He has held executive staff or board positions at several startups and continues to consult part-time. Scott received a BS in Electrical Engineering from the University of Kansas and an MBA from Santa Clara University.

Advantage Engineering gardner@advantage-engineer.com www.linkedin.com/in/jscottgardner www.advantage-engineer.com

VIA Technologies www.via.com.tw