Right, Junko, that was the local hacking aspect that I mentioned in my previous post. The example of speed limiting I gave, for instance, could be an issue. If a user disables the speed limiter, and the car gains say 20 mph over its intended maximum speed (which is hardly unusual), then the tires installed by the manufacturer could be woefully inadequate. Tires are speed rated.
But why make a big issue of this, as if somehow electronics has created something previously impossible to do? Messing with the odometer, just like increasing an engine's horsepower, is something that people have been doing from day 1. No reason to become overly alarmed now. Is it easier or more difficult to bolt on a new carburator, intake manifold, or exhaust manifold, in an old car, than it is to reprogram an ECU? Doing those modifications in an old car was most likely far more effective at making a dramatic difference, and it was very easy to do aftermarket.
That's why I would focus a lot more on remote hacking of critical controls, if the intention here is to expose NEW vulnerabilties that people should be aware of.
No doubt, odometer fraud exists and results in extra monetary costs to consumers. However honestly, that's another example of something that has existed forever, and it's not a safety issue at all. Turning back mechanical odometers was practically expected, in used car sales, and a good auto inspector can usually tell whether the odometer reading matches the other cues of use.
There must be worldwide a huge ecomical damage because of odometer fraud. There are estimations that only in Germany each year two million used cars are sold with manipulated odometers. The total damage ist estimated at six billion euros or 3000 euros per used car. I fear, the situation is not better in other countries.
I talked to the gentleman at Infineon on this topic. Here's the skinny:
Yes, Trusted Execution Environment (TEE) is being developed at Global Platform; TEE in that context (approach based on the use of a separate OS) is designed for smart cards such as SIM cards and payment cards. Martin Klimke, principal of technical marketing, Chip Card & Security division at Infineon, describes it as "a big sophisticataed standard."
That said, TEE is a generic term. It is not just tied to Global Platform's standardization work. For example, Intel calls its own Trusted Platform Module (TPM) as TEE.
So while the Global Platform's TEE work for smart cards is well defined and offers a pretty sophisticated standard, it doesn't mean that it will change everything for other industries. When asked if Global Platform's work will directly impact the architecture of secure hardware module used in automotive microcontrollers, Mr. Klimke said, "Up to now, no."
But maybe some years in the future, the automotive industry may see it as a way to go, he added.
I much prefer this type of security discussion to the type that throws out any and all vulnerabilties with no apparent regard to type or severity. Which ends up sounding like an attempt at high drama.
Not sure I understand the jargon used by Infineon. I would separate the types of attack into categories such as infotainment system intrusion, monitoring vehicle functions (e.g. someone remotely accessing the car's location and movements), theft, remotely manipulating controls (brakes, throttle, steering), and local hacking into control algorithms.
The local hacking worries me less than it worries the auto manufacturers, no doubt. It worries me less because there's so much sabotage possible locally, and always has been, that this added vulnerability seems like nothing fundamentally new. An obvious example from the past was to "reprogram" the pollution controls, to get better fuel economy and performance. (Been there, done that.) I'm sure one aspect today, that the auto manufacturers worry over, is to disable the speed-limiting function. Speed limiting is used by manufacturers in order select the tires and brake systems they will install in a car. So an owner messing with speed limiting could result in legal action against the company.
Theft is another aspect that has existed forever. Modern cars help, in that regard, even if there are new attack vectors created.
Clearly the most worrisome would be remotely hacking into the critical controls. And this article shows how such attack vectors can be protected against, even in a fully integrated control environment. In my work, often the isolation between less critical and more critical subsystems is made even more positive, by physically permitting data to travel between systems only in one direction (e.g. to allow monitoring of functions by the less critical system only, and no control signals can possibly flow back to the more critical control system). Obviously, however, with the advent of self-driving cars, this absolute isolation will not always be possible. But surely, everyone is well aware of this. As the saying goes, there's no such thing as a free lunch.
Thanks for your quick response. Much appreciate it. I am going to check this out...but here, what you are saying is that this TEE effort is directly applicable to how one designs a secure hardware module in an automotive microcontroller?
TEE is a joint effort between ARM, Gemalto and Giesecke to secure any mobile device. Architecture is based on the principle of running 2 OS : 1 rich OS like Android and 1 secure OS (provided by Trusted Labs in this case). The system relies on secure OS and dedicated HW (ARM TrustZone) implemented in any Cortex-Ax processor. More can be found on Trustonic web site but I am sure that some ARM experts can bring much detail on the forum.
Regarding GlobalPlatform standardization process, I guess the status can be found on the website.
NASA's Orion Flight Software Production Systems Manager Darrel G. Raines joins Planet Analog Editor Steve Taranovich and Embedded.com Editor Max Maxfield to talk about embedded flight software used in Orion Spacecraft, part of NASA's Mars mission. Live radio show and live chat. Get your questions ready.
Brought to you by