I may be missing something here, but aren't they saying that the only security flaw is in the initial pairing? iF that's the case, can't careful pairing circumstances/measures solve this? Pairing is a one-time thing.
<<*if* they rely on BLE's built-in security and *if* the attacker is able to observe the user pairing with the phone.>>
I see it in standards all the time. Retro-fitting a feature that was not considered at inception always results in a hack which never quite works and invariably comes back to bite. Retro-fitting something as important as security is not something one should be doing. IMHO of course ...
How far are they planning to take BLE? I'm not real comfortable with the driver/hacker next to me on the freeway being able to tell my car to reboot. Call me old fashion, but sometimes wires are worth the weight and extra cost.
@Rick, it is true. Reliability is a big issue, when it comes to anything wireless.... But when I asked several experts about interference issues of BLE, I got their answers saying that they are little concerned. But security? Yes, they are worried.
Security should of course be a concern, but I think reliability is a far bigger concern.
Having said that, I recently saw an episode of a TV drama in which a murder was committed by a hacker who remotely commanded his victim's airbags to deploy, causing a fatal crash. Food for thought as we march toward wireless connectivity in cars.
@alex_m1, not exactly... legacy Bluetooth hops frequency in every 625usec, but Bluetooth LE use more static "channel selection" per-connection bases. It is still dynamically allocated, but not exactlly FH spectrum spreading.
In short, when you set up an Internet account with your bank, are you having to involve your broadband provider in the process? Answer: no. It's all between your PC and your bank.
The Bluetooth Smart/Dumb interface should not need to become involved, except in cases where Transport Layer Security (TLS) is not feasible or too cumbersome. Same applies, for example, to WiFi. If you can use TLS or IPsec protocols over your WiFi, then the need for WiFi's own security layer is lessened considerably. (Mostly, WiFi's security protocol is used to prevent others from clogging up your broadband link, but not to prevent others from accessing your bank account!)
In this specific case, to lock/unlock the doors and to open windows, the automakers can simply use TLS between your own cellphone and the MCU that controls those functions. If this involves too much delay, the best bet by far is to install a faster MCU!!
I can see very little reason to link functions like adjusting seats, mirrors and such by the use of a smart phone. For some drivers replacing the Remote Keyless Entry fob with a smart phone makes good sense. But for most functions why not use CAN bus or some other simple serial wired bus to do most of these functions. Wireless in neat and cool but replacing a wired serial bus with a wireless bus seems like added complexity with little advantage.
We are witnessing a revolution in the auto industry, and wireless connectivity is at the center of that revolution. As vehicles have become more and more dependent upon electronics, security and reliability concerns have always been raised, ranging from fear of EM pulses being used to disable ECUs to hackers gaining access to the vehicle through a standard Bluetooth connection. Even today many keyless entry systems remain vulnerable to various types of attacks.
Bluetooth Smart technology inside the automobile will offer significant improvements to the user experience in many areas, and will also help manufacturers to produce more efficient vehicles. Outside of the automobile, Bluetooth Smart technology is or will be used in medical applications, mobile payment systems, garage door openers, and residential and commercial locks. Each of these applications has security and reliability as paramount concerns.
TI has been working with our customers for years to help them ensure their wireless applications, including those using Bluetooth Smart, are safe from security attacks. Regardless of any demonstrated vulnerabilities, users can be assured that additional layers of security will be used to ensure these vulnerabilities are not maliciously exploited, resulting in implementations that are highly secure.
Excellent point. If someone breaks into my car & gains access to the CAN buses, maybe he can do some something. But any wireless link should remain completely isolated from those CAN buses, so that even if wireless security is somehow compromised, the worst that can happen is the doors are unlocked, the infotainment system is turned on or the driver's seat is moved.
This is my opinion and technical belief. Again not to trivialize the challenge of security, it will always be at the top of the list of priorities for any of the use cases I mentioned, but I feel strongly that done properly BLE is very secure.
I am a betting man so will put $100 towards claim that @jzolnier works for TI...I don't mind press releases, I ocasionally read them in my business...but I am not happy to see press releases sneaked in as "my own words"...I don't come to EE Times for that...Kris
I am not very familiar with Bluetooth and its initialization processes. But what happens after I replace my car battery? So all electronics have been unpowered and are powered up again? Does Bluetooth also needs a re-initialization in that situation? If so, this could be in not such a secure environment, making it vulnerable for hackers?
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. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.