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 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.
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.
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.
The beautiful 250 GT. I think an even more gorgeous Ferrari was the 275 GTS, perhaps. The immediate successor of the 250.
Interesting point about this is that Ferrari and Alfa Romeo engines of those days were already factory tuned to about their limit. Not much one could do aftermarket, to improve on them.
Contrast those with the very common American V-8s of those days, usually married to an anemic 2-barrel carburator and single exhaust. It was not hard to double their horsepower, or even more than double, something that repogramming an ECU these days is hardly likely to achieve. And then, the chassis of that car would be totally outclassed.
Yes there are those "service" companies. On the other hand, you can get such programming devices for only 250 euros over the internet. There was shortly an article about odometer fraud in Germany on the homepage of the Association of German Engineers (VDI). Sorry, it is in German. But there is a picture of a programming device:
I would tend to agree. They don't want to increase effort or add the expense, especially if the perceived threat is in doubt among some. I can imagine some high-end cars adding this type of security, though. But as far as wide adoption, I am afraid it's going to take a crisis. But they really should get out in front of it, because if something like that does happen, they are going to need years to get the security in place.
Every article, interview (and many of the engineer user comments on them) you have done in the last month has me more and more concerned about the direction auto control systems (and for that matter every single control system that is quickly moving to a networked, software primary controlled with some old school electronics stuff to keep those hardware folks quiet) architectures are going.
To your quandary at the end of your article and comment, yes it is shameful and to throw down a gauntlet perhaps criminal that more is not being done to create architectures that will minimize the possibilities of problems all the way up to catastrophes.
What concerns me in this article are two things, first this not unique to this gentleman's opinion of 'if I have not seen it, it is never happened':
"At this moment, no tragic automotive accident caused by external attacks has happened yet, he explained." quote from your article by I believe Martin Klimke.
And second, the believe by hardware security people that installing code execution systems that will only run vetted software will 'solve' the hackability of the macro-system.
I am not an expert in any way on TPM, but what I do know is I have owned computers and notebooks that have contained these TPM modules for as I remember at least 15 years and have patched the BIOS, firmware and Windows OS on what seems like a daily basis to address active exploits that none of which to my memory overrode the TPM security but disabled the functions of the computer or extracted data from the computer. So explain to me what TPM did to solve this? And how these similar modules will better protect vehicle systems with them?
Tom, yeah, I know, US is far far behind on smart cards. But people in the U.S. --not everyone, though -- do use SIM card inside their mobile handsets. Now, that's the same smart card technology I am talking about here in the article.
A great deal of knowledge about security -- how you partition your chip; how to harden the security, etc. -- has been learned by those who designed secure microcontrollers for chip cards. And some of the underlying technologies are now being applied to the automotive industry.
And your comment about automakers have a higher authority to answer to? Well, here, I am not talking about "remote-control cars; i am talking about the potential of a modern car getting remotely manupilated by external hackers. There are no regulators watching that type of automotive security.
Don't knock university reports, if they anticipate issues that can be addressed then lives and money can be saved. The challenge is to articulate the problem in a persuasive enough manner that the car companies become engaged in solving the problem rather than denial. With luck, perhaps the manufacturers could both solve the problem and intercept other failure modes before they occur.
DrQuine: The notion that auto companies would become involved in solving problems seems awfully far-fetched to me on a day when the city of Detroit was forced to declare bankruptcy. Who's to blame for that? Well, if the auto industry had acted far sooner to build better cars, it would have held onto its historic market share. But no. SUVs and trucks had higher profit margins, so that's the way it went. And a once-proud city was brought to its knees.
A July 17th New Scientist article "$25 gadget lets hackers seize control of a car" (http://www.newscientist.com/article/mg21929266.500-25-gadget-lets-hackers-seize-control-of-a-car.html#.UevjztI3t8E) claims that an inexpensive device can be used to remotely seize control of some critical car controls. The device is scheduled to be shown at the Black Hat Security conference in Las Vegas on July 27th. It will be interesting to see what unfolds.
I caught a passing news clip as I passed through the Atlanta airport this evening suggesting that hackers at the Black Hat / Defcon conference in Las Vegas did demonstrate ways to take over critical car controls. Are details forthcoming from EETimes?
Thanks. Yes, I am aware of it, and I am on it. From what I understand, these two "hackers" managed to take over the control of Prius with a laptop and a gamepad. The inspiration of their hacking also comes from the original tech paper -- Univ. of Washington, etc. -- mentioned in this story.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.