Interesting to see that Infineon has defined its own vision of Trusted Execution Environment. It seems to be much different from what is under standardization at Global Platform. Result may be confusion in people's mind.
Thanks for your comment, ip2design. Could you please educate me how exactly GlobalPlatform's standard for trusted execution environment is different from what's described above in this story I wrote based on the interview with Infineon? I would appreciate your explanation.
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.
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?
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.
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.
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.
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.