[DerAlte]

Originally Posted by mayuresh

... It's immaterial whether a mechanic does it or a non-mechanic does. ...

Sure, a non-mechanic can also do what a mechanic does. He will look foolish if he doesn't know what he is doing, which is true for a mechanic too! The point is availability of points at which the mechanic (non-mechanic if you will) can do something to change behaviour. If one knows well enough about cars, one knows about these points. If these points are not accessible, neither a mechanic (for whom these are to be legitimately provided) nor the best of hackers can do anything. The legitimate form is provided for direct local access (mechanical or electronic). Nothing is provided BY DESIGN for remote access.

Originally Posted by mayuresh

... In other words, if you are referring to legitimate ways deliberately left open for mechanics to control the car, they do qualify as vulnerabilities, particularly if they can be exploited.

I hope you are not a Information Security Consultant by profession as is indicated by the language.

Yes there are legitimate ways left open, and no they are not called Vulnerabilities. Those legitimate ways are interfaces to tune the operation of a subsystem, for example
- the simple headlamp beam leveling screw near the headlamp housing, or beam height adjuster provided on the dashboard. Or the modern equivalent provided in the Chassis Electronics ECU
- the mechanical screws on the carburettors to adjust the idling speed, or it's modern equivalent the Map in the ECU accessible via the programming interface of the ECU
- the switches provided around electrically adjustable seats for changing height, etc. Or the Seat Adjustment Preference memory in the Chassis Electronics ECU which sets it back to the preference of the driver

These mechanical or electronic interfaces are called Adjusters or Tuning Points. Again, they are INTERFACES, not "legitimate Vulnerabilities". Like I said earlier, one has to know the systems in a car to differentiate, rather than broad-brushing them with IT terminology and having the Gaulish expectancy that the sky may fall on our heads.

It is legendary that IT designers were rather lax in their approach to security, which ultimately led to the creation of Information Security as a practice. That has never been the failing in automotive design. The difference is very simple: LIABILITY. IT designers were never liable for damages of any kind - just read any software license disclaimers. Automotive Systems designers have that Damocles' Sword of liability hanging over their heads. Automotive Systems have known Object Orientation for the last 100 years (even when the term didn't exist); IT designers are still struggling to come to terms with it. The key to good security practice lies in OO, if one understands what OO is.

[mayuresh]

Originally Posted by DerAlte

Yes there are legitimate ways left open, and no they are not called Vulnerabilities.

In nearly all posts where you quoted me you have ignored parts of the sentence. For the above one I had said "if they can be exploited".

[FlatOut]

Originally Posted by laluks

Yes, Remote diagnostics are possible these days especially in higher end cars. They are often coupled to the telematics systems in such cases.

There are several levels of security access algorithms to gain access, and change configurations.

Thanks for that. I was chatting to someone ages ago who suggested that a car can potentially be tele-investigated by the police, via the manufacturer after an accident. And that there is the potential to shut down an engine in a similar manner. I wonder if this is the case also?

[Sutripta]

Say GMs OnStar system: To my mind the question should be how secure is the server at GMs end?

Regards
Sutripta

[DerAlte]

Originally Posted by mayuresh

In nearly all posts where you quoted me you have ignored parts of the sentence. For the above one I had said "if they can be exploited".

English is not that funny a language that it plays tricks on logic. A vulnerability still stays a vulnerability - "weakness" - whether or not it can be exploited! Exploitation is just an implementation detail if theoretically a Vulnerability exists. Ignoring or reckoning with "if they can be exploited" - will it change the logic?

What you are unable to differentiate is between regular use and intentional misuse. An accessible configuration point, which is intended for regular use for valid purposes, does not ever become a "Vulnerability" due the possibility of wilful intentional misuse. The "regular use" was my reference to a mechanic. The "intentional misuse" is the subject of the "hacking" paranoia.

One doesn't eat off the floor for the fear of thieves stealing the dinner plates, as a saying goes in my mother tongue. There have been innumerable instances of bombs being placed on buses and trains. Should the doors on the buses / trains hence be called "Vulnerabilities"?

OTOH, the "Vulnerabilities" which are legend in IT systems and software, do they follow the same logic? Are the two paradigms comparable? No, they are not.

[mayuresh]

Originally Posted by DerAlte

What you are unable to differentiate is between regular use and intentional misuse. An accessible configuration point, which is intended for regular use for valid purposes, does not ever become a "Vulnerability" due the possibility of wilful intentional misuse.

Well, that's a perspective. I can understand what you are saying.

Fact remains, what matters to a consumer is whether he can be "troubled" in some way due to open interfaces - whatever name you want to give it.

Also I said it repeatedly that we can't go by today's knowledge of interfaces alone. Things change. New interfaces get added and they bring additional vulnerabilities (or put whatever word you like in place of this).

There was a time people thought of mobile handsets as embedded devices. Nobody imagined anything like security issues with them. More and more functionality necessitated regular operating systems that also brought additional troubles.

I find you making an assumption that cars' interfaces will always remain what majority of them have today and will never use general purpose interfaces, which I don't quite agree with.

Knowing the basic difference in perspective, let's agree to disagree on that. I am stopping responding further on this matter.

[Samurai]

PC, laptops, smartphones are generic devices that can let create, change and view data in various formats. When they have to do action like print or make a phone call, they use dedicated hardware like printer or phone. You can't tell the printer to start climbing the wall or tell the phone to electrocute somebody, they have very narrow command set. That means you can't tell any dedicated device to do something it won't do.

Car is a collection of dedicated devices. Turning those devices into generic devices won't be a smart thing to do. It will be like opening pandora's box.

[mayuresh]

Originally Posted by Samurai

Car is a collection of dedicated devices. Turning those devices into generic devices won't be a smart thing to do. It will be like opening pandora's box.

Precisely. Car _is_ so, just like mobiles _were_ before they turned smartphones.

I agree with the point that turning things into generic devices wouldn't be a smart thing. But whether the industry can hold back the temptation will be a thing to watch.

This does not obviously mean each and every subsystem has to become so (it won't), for that to be a concern.

[DerAlte]

Originally Posted by mayuresh

... we can't go by today's knowledge of interfaces alone. Things change. New interfaces get added ...

Originally Posted by Samurai

... You can't tell the printer to start climbing the wall or tell the phone to electrocute somebody, they have very narrow command set. That means you can't tell any dedicated device to do something it won't do.

Car is a collection of dedicated devices. ...

Absolutely correct, @samurai. Unfortunately, paranoia causes irrational thought.

One wishes that instead of pooh-poohing and discarding "today's knowledge", that such knowledge be known and understood first. No new mechanical interface has appeared in the last 100 years of automobiles, and no new electronic interface has appeared since electronic controls were introduced 35 years back.

The fact that those interfaces support a dedicated limited purpose-related command set is lost on those who are only exposed to generic interfaces of computers and software - which have been around (in standardized form) only for the last 15. Also lost is the fact that technology advancements have always been evolutionary. If there is no reason to discard an old paradigm or interface, it is never discarded. Nor a new one ever added. There has been no reason for discarding the programming and diagnostics interfaces in automotive electronics. Nothing has changed at the logical or physical level.

This is completely unlike how USB superseded the older parallel and serial connectivity in computers for the simple reason that the differentially driven fast serial communications over USB was more economical to implement as compared to synchronous parallel and asynchronous serial methods of yore. Ditto for SATA superseding IDE and SCSI. Rise one level above, and one realizes that at the logical level nothing has changed despite the physical interface changing.

[msdivy]

Any complex system consists of many modules and different components of a module trust & collaborate with each other to make the system work. The key here is trust, which is usually done by authentication.

If the authentication is weak, some rogue module may authenticate itself as genuine module and issue spurious commands to rest of the modules. For instance, car key authenticates itself before issuing the command to the receiver in the car to open the lock. If a 3rd party module performs the same authentication & issues the same command, the car receiver with trust & will unlock the car.

Why the authentication will be weak? Multiple reasons:
1) Due to limitation in hardware capabilities, choices of strong authentication protocol might be limited. Imagine the processing power of a car key compared to a PC or mobile phone - it is very limited.
2) A weakness might be found in the chosen protocol after the cars are sold.
3) Even though the protocol might be strong, the implementor (person who wrote the code) might not have implemented exactly as per protocol (may be due to limitation of the programming language, or he may not have complete understanding of the protocol).

So there are chances that cars might be hacked. Possible hacks are to gain entry to steal the items in the car or the car itself. It highly unlikely that somebody will hack and disable airbags or ABS (but that is possible).

Note: Recently, a Dell engineer listed the possible exploits in Tesla S. Check out: http://programming.oreilly.com/2013/...ion-flaws.html

[DerAlte]

Originally Posted by msdivy

Any complex system consists of many modules and different components of a module trust & collaborate with each other to make the system work. The key here is trust, which is usually done by authentication.

... For instance, car key authenticates itself before issuing the command to the receiver in the car to open the lock. If a 3rd party module performs the same authentication & issues the same command, the car receiver with trust & will unlock the car. ...

Correct.

While what you say is generally plausible, there is a big BUT to it. The Immobilizer system is the only one which uses the conventional 'authentication' mechanism, as understood in the 'computer' world.

The other systems in the car don't use 'authentication' at all - just simple 'identification' so that the message conveyed in the communication protocol can be correctly interpreted from the *pre-defined* set of expected messages.
- No message outside this pre-defined set is acted upon, which prevents spurious messages from causing unwanted behavior (statistically possible)
- The message contents can only make the recipient take an action limited to it's set of valid actions. These actions are decided at design time, and cannot be changed at run time (you are in fact alluding to the same in a way).

This prevents the possibility of the sub-system doing something that is catastrophic (as precluded at design time). For example, it will not be possible to command the power assist (steering) to change the direction of assist to Right, if the steering is moving Left. But the Transmission ECU can tell the Engine ECU "Please reduce RPM, I want to shift gears", and the Engine ECU will do so. At the end of the shift, the Txn ECU tells Engine ECU "I am done", and the Engine ECU goes back to whatever driver demand was expecting. It will not act on a message that says "Hey, go to redline RPM" - it will act only to keep up when the driver presses the Acc pedal to maximum.

To correctly interpret the possibilities of external influence on a car's electronics, one has to understand that automotive systems are designed with the principles of Control Systems (a la Joseph Marie Jacquard), and not that of Computers (a la Charles Babbage). To the uninitiated, and to whoever has grown up only on Computers, the difference is not apparent - since both Computers and Controllers use microprocessors and software!

However, the rules of design and engagement are very different. Control Systems rely on sub-system autonomy (including overruling inputs that are out of range or implausible). Computers, on the other hand, are designed for general purpose usage where the usage is decided by the end user, even if that means the user can bring it to a complete grinding halt by a wrong action.

Control Systems implementations have far more severe restrictions that don't give any headway for malicious manipulation. When implemented, even automotive Ethernet-based networking will obey severe design restrictions in protocol implementations. One won't be given the facility to http/https to the Engine ECU and be presented a Configuration page like home ADSL routers do. Hollywood movies lead everyone to believe that such things are a plausible reality - it is as much fiction as the rest of the movie story is.

[Hulk]

Tesla Motors has promised to fix any “legitimate vulnerability” after Chinese hackers reportedly discovered a flaw which allowed them to honk the horn, unlock the doors and flash the headlights of its Model S electric cars, even while they were moving.
The news emerged from the SyScan360 conference (motto: “I hack, therefore I am”), which is intended to be a “platform for the international security community to interact with the Chinese security community”. A post on the social network Weibo said that the IT department from Chinese company Qihoo 360 Technology Co had been able to take control of the car’s door locks, horn, headlights and sunroof.
No details of the hack have been disclosed, but the functions which claim to have been attacked closely match those which are made available through the Tesla smartphone app. Drivers can download an app which connects to their car via Bluetooth and allows the doors to be locked and unlocked, the headlights to be flashed, the horn honked and the sunroof opened.
The app also allows the air conditioning to be controlled, offers GPS tracking and allows the owner to monitor the progress of charging. This means that a user can park at a charging spot and run errands until it reaches 100 per cent charge.
If hackers had been able to hack this app, or some layer of communication between it and the car, then all of these functions would be available to them – just as the Chinese group is claiming.

You may read the entire article at :

http://www.telegraph.co.uk/technolog...ctric-car.html

This certainly is a very very scary situation for the person driving the car!

[DerAlte]

Originally Posted by Hulk

... If hackers had been able to hack this app, ...

If Tesla has provided a legitimate API and hardware interfaces, this can hardly be called 'hacking' - it is only using the same API and interfaces. If Tesla has provided a BT interface, they will also provide a method to disable it. Also, it is only in movies that one sees someone taking control of an unknown entity by using an App on a tab. In reality, there are simple security interfaces even at the hardware level (despite the possibility that the car owner forgets to change the BT default passcode from '0000' to something else).

Anyhow, the functionality controlled externally is part of Chassis Electronics, and not main 'engine' / drive-train functionality. One wouldn't worry about the car's main functionality being hijacked because of these stunts.

Sensationalism of this kind detracts from actually securing the interfaces from external manipulation with malicious intent. It only serves to draw attention to attention seekers.

[Cowardly Lion]

Being a sci-if aficionado I have often read and then wondered about a time when Car hacking will be a concern. If you will read the article it is shouting "we are there". Imagine the mess one can create if you can control multiple missiles of 300 kg+ on a road.....

Will this lead to a niche market for purely mechanical (read unpack able) cars...? I'm sure it will. What do you guys think...?

http://www.wired.com/2015/07/hackers...social_twitter

[DRC]

Interesting perspective.
There had been purely mechanical cars in the past. They were stolen too. some times along with their owners.. It was then known as carjacking.

If this needs attention, we may debate this topic on shifting gears section.
Mods may please do the needful.