'Function on Demand' Brings Opportunities, Security Challenges

May 30, 2018

Paul Weissler

The motorist is on a vacation in his leased car, a minimally-equipped vehicle for which the low price was an incentive. But now he temporarily would like some of the features that would have increased the lease price over his budget, such as the higher-performance engine and the semi-autonomous adaptive cruise-control system.

Or for a long trip, he may want an insurance policy with higher limits and special coverage.

Instead of that most-expensive term-of-lease (or option list on a new-vehicle purchase at the dealership), he makes a lower-cost, short-term purchase of the features, an approach called “Function on Demand.” And there’s no return to the dealership—software that enables the features is immediately downloaded over the air (OTA) and charged to a credit card.

Function on Demand is an identified way to sell vehicle electronic feature content. Because the delivery of upgrades must be convenient, the method also poses cybersecurity issues. If it’s possible to change powertrain operation for the motorist’s enjoyment, it’s also possible for hackers to create safety issues.

Function on Demand an OEM business

Infotainment purchases (such as a game or a new film) to entertain passengers, premium telematics or a comfort feature such as automatic temperature control, may appear to be minimally invasive software installations. But for after-sale installation, they may raise issues of their own. However, some in the industry, including Audi AG and Infineon Technologies, see Function on Demand as a new business case. Audi electrical engineer Rolf Schneider explained the challenges in a presentation at the 2018 SAE WCX.

He pointed out that there has been an increase in bandwidth and wiring harnesses to support increases in electronic control units and functions (up to 150 ECUs per vehicle with 5,000 functions at present, projected to increase to 250 ECUs and 8,000 functions by 2020). Many new applications will be in X-by-wire, particularly for functions covering enhanced collision avoidance.

Audi and Infineon see three basic rules of cybersecurity: 1) the chain is no stronger than its weakest link; (2) once deployed, the bug is harder for a defender to find than for the attacker to install, as he had unlimited time; (3) an attacker needs to find just one entry point not securely defended.

After-sale delivery of new functions poses obvious cybersecurity challenges in addition to those that are safety-related. Key are ensuring the payments are authentic and the time basis for a function, including configuration data, activation and time limits, all are recorded securely and correctly. Other security factors that require attention include communications between electronic control units that are involved, plus storage of cryptographic data that is applicable. And of course there must be secure communication with the IT backend in the cloud and infrastructure.

Root of Trust in hardware

Attackers have unlimited time to plot and execute an attack, but developers don’t have much time for an effective response, Schneider noted. With so many needs for access to an onboard gateway to install functions, the challenges for the defense are great.

Security keys—passwords—are part of the foundation of a cybersecurity structure. Without password protection for the lifecycle of the function, there is no security, the presenters said, noting that it’s time-consuming and expensive to revoke a password/key that’s been compromised.

Software alone, Audi and Infineon maintain, protects only against “casual” attacks, because it’s easily read and copied, and analyzed using standard tools. Further it has no “root of trust” (ROT) so if compromised, it’s very hard to restore.

Root of trust is a set of embedded functions that the operating system can always trust. So if the ROT-supported security is hardware chip-based, it can be made more resistant to attack by use of non-standard proprietary code.

---