Detecting Spoofed Messages Using Clock Skew

Two researchers are working on a system to detect spoofed messages sent to automobiles by fingerprinting the clock skew of the various computer components within the car, and then detecting when those skews are off. It’s a clever system, with applications outside of automobiles (and isn’t new).

To perform that fingerprinting, they use a weird characteristic of all computers: tiny timing errors known as “clock skew.” Taking advantage of the fact that those errors are different in every computer­—including every computer inside a car­—the researchers were able to assign a fingerprint to each ECU based on its specific clock skew. The CIDS’ device then uses those fingerprints to differentiate between the ECUs, and to spot when one ECU impersonates another, like when a hacker corrupts the vehicle’s radio system to spoof messages that are meant to come from a brake pedal or steering system.

Paper: “Fingerprinting Electronic Control Units for Vehicle Intrusion Detection,” by Kyong-Tak Cho and Kang G. Shin.

Abstract: As more software modules and external interfaces are getting added on vehicles, new attacks and vulnerabilities are emerging. Researchers have demonstrated how to compromise in-vehicle Electronic Control Units (ECUs) and control the vehicle maneuver. To counter these vulnerabilities, various types of defense mechanisms have been proposed, but they have not been able to meet the need of strong protection for safety-critical ECUs against in-vehicle network attacks. To mitigate this deficiency, we propose an anomaly-based intrusion detection system (IDS), called Clock-based IDS (CIDS). It measures and then exploits the intervals of periodic in-vehicle messages for fingerprinting ECUs. The thus-derived fingerprints are then used for constructing a baseline of ECUs’ clock behaviors with the Recursive Least Squares (RLS) algorithm. Based on this baseline, CIDS uses Cumulative Sum (CUSUM) to detect any abnormal shifts in the identification errors—a clear sign of intrusion. This allows quick identification of in-vehicle network intrusions with a low false-positive rate of 0.055%. Unlike state-of-the-art IDSs, if an attack is detected, CIDS’s fingerprinting of ECUs also facilitates a rootcause analysis; identifying which ECU mounted the attack. Our experiments on a CAN bus prototype and on real vehicles have shown CIDS to be able to detect a wide range of in-vehicle network attacks.

Tags: , ,

Posted on July 20, 2016 at 7:26 AM • 33 Comments

Comments

Alex • July 20, 2016 8:09 AM

I must be turning into a Luddite as I age, more and more I question the validity and intelligence of doing the things we do with computers.

OldFish • July 20, 2016 8:26 AM

Would not disabling all wireless connectivity go a long way towards making a vehicle’s control systems secure or am I missing something?

Jared Jennings • July 20, 2016 8:27 AM

Bruce, you have mismatching quotes in your first link: the beginning quote for the a href is a single quote, and the ending quote is a double quote.

The whole first paragraph should read:

Two researchers are working on a system to detect spoofed messages sent to automobiles by fingerprinting the clock skew of the various computer components within the car, and then detecting when those skews are off. It’s a clever system, with applications outside of automobiles (and isn’t new).

Ergo Sum • July 20, 2016 9:00 AM

@OldFish…

Would not disabling all wireless connectivity go a long way towards making a vehicle’s control systems secure or am I missing something?

Security through obscurity doesn’t work. At least that what the experts say…

While I agree with you, it would disable important features…

Disabling wireless would probably disable self-driving feature in Tesla and others. Emergency assistance would also be disabled, together with traffic report for your GPS. So much for alternative route for getting around a blocked road.

Disabling other features with the wireless connectivity are not that important, at least to me, but others may disagree.

Even the important features aren’t as critical, at least for me. I can always use my cellphone to call for help, either for a tow and/or directions. And no, I don’t have a self-driving car. My 18 years old pickup truck still looks and runs good…

Freezing_in_Brazil • July 20, 2016 9:32 AM

We are being completely involved by consumer goods that we cannot possibly trust. How long until even innocent teddy bears sport cameras, microphones, GPS? This kind of economy is not sustainable in my view. The amount of work required to keep my privacy and security at work/home is simply overwhelming. Now cars.

I can only hope that sensible people in the right position [Bruce Schneier – Resilient, IBM, EFF] actually do something for us lowly mortals, and do it quick.

We are running out of time! The sky is falling! etc…

Archon Luddite • July 20, 2016 10:04 AM

I’m not entirely sure why the entertainment equipment and the brakes are sharing a command channel in the first place, but that’s me.

albert • July 20, 2016 10:07 AM

@Freezing..,

“…How long until even innocent teddy bears sport cameras, microphones, GPS?…”

Did you miss Babbling Barbie?

@Ergo Sum,

I agree with you, and OldFish.

Wireless connectivity is absolutely unnecessary in automobiles. The functions you mentioned can be safely accomplished via cell phones.

@Archon Luddite,

It’s $$$$$.$$

Cheap and dirty is SOP for engineering and production in the auto business.

…………

Adding nightmarishly complex and expensive ‘features’ to a potentially lethal weapon is foolish, especially given the almost total lack of security considerations, and the probability of bugs.

Who assumes liability for ‘accidents’? The driver, the manufacturer, or the hacker? This is yet another example of a -totally preventable- class of auto accidents.

I would suggest that the insurance industry demand special insurance for self-driving cars, and even remotely hackable ones as well. The govt certainly isn’t going to do anything about it.

In the end, as always, it’s about $$$$$$.

. .. . .. — ….

Clive Robinson • July 20, 2016 10:30 AM

The use of Clock Skew or Delta F of the base XTAL is nothing new as I’ve mentioned befor.

The first “academic” use documented as far as I’m aware was at the UKs Cambridge Computing Lab, where the Delta F on TCP time stamps was used to decloak hidden servers. That said however I and several others had been using the Delta F to detect things like computer load and temprature several years before that, and had mentioned it on this blog (apparently upsetting the Camb Labs researcher when I mentioned it).

I also later developed a way to use clock skew to detect “honey pots” by what looked like a “brain dead script kiddy scan” as a proof of concept. Because if you are a Black Hat or IC operative the last thing you want to do is use your brand new zero day etc on a honey pot, nor tip off the honeynet research. Thus knowing what to look for if you are a serious honeypot researcher is important.

The more you think about how to use the clock skew Delta F the more interesting things you can do. Thus it is a rather more powerful tool than it first appears.

CallMeLateForSupper • July 20, 2016 10:49 AM

@Alex
“I must be turning into a Luddite as I age […]”

Doubtful. More likely it’s experience and healthy skepticism. Wisdom. But I get your point.

When business perceives a toe-hold in customer desires, it pushes that for all it is worth (and beyond). It is up to customers to set business right by pushing back. Yeah, some people “need” (translation: can pay for) a vehicle equipped with wifi, a large display for each passenger, and chilled cup holders, but many don’t, so please offer models without that verdammt stuff. Or else!

Seriously. Don’t go the long way ’round the barn – “detect spoofed messages” – when it’s so easy to simply s**t-can the verdammt wifi. Many of us who have successfully navigated highways for decades are unconvinced that pushed firmware, in-built GPS, push-button emergency road service, etc. are worth the expense or the risks.

Not that any of this is terribly important to me, as I literally walked away from the private auto merry-go-round a decade ago.

Ross Snider • July 20, 2016 10:56 AM

Will be trivial to impersonate another car’s clock skew.

Meanwhile we have more vehicle fingerprinting.

Not my cup of tea.

Jordan • July 20, 2016 11:03 AM

This allows quick identification of in-vehicle
network intrusions with a low false-positive rate of 0.055%.

0.055% is about one in 1800. So if I start my car twice a day, and drive it most days, an intrusion will be falsely detected approximately once every two and a half years. If there are 18,000 drivers in my town and they too start their cars twice a day, about twenty of them will see a false detection today.

That doesn’t seem like a “low” false-positive rate.

But is it the whole story? Presumably detection is not on a per-start basis; presumably it’s a continuous process. Is that false-positive rate per vehicle-day? Per vehicle-hour? Per message? Is that rate for the vehicle as a whole, or is it for any particular ECU (of which a typical car has dozens)?

The false positive rate must be compared against the intrusion rate and must be appropriately low, lest the result be the fable of the boy who cried “wolf”.

Joshua Bowman • July 20, 2016 3:48 PM

@albert
“Cheap and dirty is SOP for engineering and production in the auto business.”

Cheap and dirty might be SOP, but linking the drive CAN with the entertainment bus (which is more often firewire or another alternative to CAN) is not. Cars have multiple buses that don’t interlink, or have one-way links, already. Engineers may cut corners, but they’re pretty stodgy too, not Web 2.0 visionaries who’ve never thought of separation or security.

Andrew • July 20, 2016 4:04 PM

And what would a false or true positive result in? Warning to the driver (so he/she can ignore it)? Shutting the car down (denying service)?

Tony H. • July 20, 2016 4:27 PM

So if this CIDS (thinks it) detects the audio system sending a message to the brakes, does it just log the event for future analysis? Or does it prevent/disrupt it in real time? If the former, then there’ll be pressure to “do something” once the first widespread cases of malware start to kill people. If the latter, then false positives carry a much bigger problem: that may actually have been the brake pedal or the collision avoidance radar sending the message to the brakes. Sort of like when your desktop AV product deletes your perfectly good Word document because of a false positive, but with higher stakes.

Arclight • July 20, 2016 4:39 PM

This seems like an awful lot of trouble to go through to achieve a 10-14 bits of authentication between modules. It seems like there are a lot of better ways to do this, such as:

  1. Simple segregation of critical channels (ECU, modules required for drive-by-wire) and, well everything else.

Is there a reason the entertainment system needs anything more than a 1-way serial byte stream to know the car’s speed and systems status?

  1. Plenty of hardware and software-based devices already have all of the needed capabilities to cryptographically protect messages or periodically authenticate the network.

Why do we need an exotic, low-strength solution when even MCUs costing US$3 have AES128 and other primitives built in?

I’m not sure if the threat model involves a need to check if a rogue message was inserted, or an unexpected node is on the network, but we have been solving problems like this for a long time. This is a relatively small network that doesn’t push large amounts of traffic.

Lastly, it seems we’ve turned a corner where “smart vehicle technology” implies always-on connectivity to some third party.

Is this actually necessary? I’m thinking it has more to do with the default business practices of tech startups.

Arclight

John Gonder • July 20, 2016 9:25 PM

Second the Luddite position – As a CEH instructor, I want my brake pedal and steering wheel analog all the way. 100 ECUs, wifi, cellular, radar and a BT admin PW of 0000 all on the CAN buss is insane in the membrane. Can’t wait to hear reports from Brian Krebs about Tesla, and Uber zero days for sale on the dark net. Of course, sonar/laser/radar DOS attacks for the obstruction recognition auto-braking systems is going to be LOTS of fun – the electronic equivalent of dropping bowling balls from the freeway overpasses.

separate • July 20, 2016 9:29 PM

As someone else mentioned, why aren’t critical control systems on a separate physical bus? Non-critical systems could still have read-only, non-control access to the information, but any control commands or data contributing to control decisions would be ignored.

The only external access point providing control functions should be the OBDII port. Even then, that information shouldn’t be persisted unless it’s signed by the manufacturer somehow. For the tuner crowd, the only additional burden would be they would have to keep the device they used plugged in. Some kind of simple yes/no dash interaction to accept the new data would add a user alert that something out of the ordinary was going on.

These are problems that have been solved in IT and software for 10+ years. So either the people writing automotive software are criminally incompetent, or they’re constrained by something or someone.

AS • July 21, 2016 1:51 AM

As someone who works in automotive security, I think this solution is mostly unworkable.

The most important problem is reliability. Does this method work under all automotive circumstances, i.e. during very low and high temperatures? Varying voltages? I’d assume no.
A 0.055% false positive rate is absolutely unacceptable and will get laughed out by any decent automotive engineer. Even if you are a small-sized OEM with 100000 cars a year, if you have around 5 ECUs inside a car which are monitored by this, it’s a nightmare. As a comparison, automotive safety measures failure rates in parts per million. If the security measures can’t keep up with the safety measures, then the security measures have failed.

IDS for cars is a dead end and completely unnecessary. Do proper separation between online domains and not-online domains [1]. Use proper cryptography to secure critical in-vehicle communications if necessary. The OEM has complete control over all communicating parties during the car’s production, so key distribution is not really that hard.

There are way too many companies hawking IDS as some kind of cure-all for car security but in reality it’s not even a band-aid fix. Uninformed people (and the press) get wowed by supposed “just plug in this additional thing” solutions which are completely bunk. Making automakers look clueless regarding security is en vogue right now and small start-ups get all the laurels for being on top of the game. But really, those start-ups usually know nothing about automotive engineering at all, and their “solutions” show it.

[1] There are many OEMs which have been doing this for years, but most of them are European. American and Asian OEMs tend to have one or two buses with no proper separation at all, which is why deep hacks (Jeep Hack 2015, Kosher et all 2011) are way more prominent there. To someone who works in the industry this discussion is highly annoying because everyone assumes that just because some OEMs have horrible architectures all of them do.

blake • July 21, 2016 6:36 AM

@OldFish

Would not disabling all wireless connectivity go a long way towards making a vehicle’s control systems secure

@Ergo Sum

Security through obscurity doesn’t work

There’s an important difference between security through obscurity and reduction of threat surface. Removing an entire communication system doesn’t make the communication obscure, it removes the threat surface.

Foo • July 21, 2016 8:26 AM

@AS

“To someone who works in the industry this discussion is highly annoying because everyone assumes that just because some OEMs have horrible architectures all of them do.”

As someone who knows, your contribution is highly appreciated. But the rest of us peons just can’t tell which OEMs are doing what, that’s the main reason why the press and our feelings go such ways… As long as we can’t tell the difference, we will ALWAYS lump everything together, it’s only simple logic. Differentiate, and we will notice (at least, some of us, who are paying attention and care about such things).

Slime Mold with Mustard • July 21, 2016 8:32 AM

I had to disconnect my own vehicles after purchasing the electronics service manual.

Hope we all know we need to physically disconnect. If GM did it five years ago, everyone’s doing it now. Except Volkswagen diesel, which is tracked by hydrocarbon sensors;)

Peter A. • July 21, 2016 9:30 AM

@Slime Mold with Mustard

I just wonder if removing the antenna and putting on a 120dB attenuator for good measure would fix it permanently or would the ECU just refuse to start your car when there’s no connectivity? If it is not the case right now, what about future car models?

Mooltipass • July 21, 2016 9:33 AM

@ Slime Mold with Mustard
Re: Hope we all know we need to physically disconnect.

“Now a real killer, when he picked up the ZF-1, would’ve immediately asked about the little red button on the bottom of the gun.” — Zorg

Ted • July 21, 2016 9:58 AM

Semantic Scholar [BETA]
https://www.semanticscholar.org
“Our current corpus is limited to research publications related to Computer Science. We plan to expand to new academic domains this year. To receive email updates about improvements to Semantic Scholar, sign up to receive our newsletter.”

Semantic scholar hosts author’s pages.

‘Authors who most influenced Kyong-Tak Cho</a href>. Authors most influenced by Kyong-Tak Cho.’

‘Also for Kang G. Shin</a href>.’

Trending on the SSB site was also the topic of ‘Deep Learning.’

Deep Learning in Neural Networks: An Overview</a href>
Jürgen Schmidhuber | 2015
“In recent years, deep artificial neural networks (including recurrent ones) have won numerous contests in pattern recognition and machine learning. This historical survey compactly summarises relevant work, much of it from the previous millennium. Shallow and deep learners are distinguished by the depth of their credit assignment paths, which are chains of possibly learnable, causal links between actions and effects… “

K15 • July 21, 2016 2:40 PM

Are these wifi features genuinely selling points, or are the manufacturers being strongarmed into providing them?

David Leppik • July 21, 2016 3:27 PM

@Jordan

This could be reasonable rate if the car additionally requires some other handshake for certain components if they don’t pass the timing test. The big problem, I suspect, is that the standard bus for car components assumes all components are trustworthy, and changing the standard is considered too onerous. Thus a backwards-compatible solution might be considered more palatable.

That said, it would probably be better to simply have certain components (e.g. brakes) on a different bus, or be required to use cryptographically authenticated messages.

Freakflagfly • July 21, 2016 10:33 PM

https://www.youtube.com/watch?v=OobLb1McxnI

Def Con 23 video. “Remote exploitation of an unaltered passenger vehicle”

these guys actually make their talk really entertaining. They demonstrate how they obtained full control over the vehicle via their laptop, driving it from the back seat amongst other things

SPOILER ALERT
One funny moment was explaining how in the process of hacking, they bricked the firmware and took it back to the dealer (under warranty) to get them to fix it ” it’s just not working any more”

at the end they explain how this wasn’t about having fun, nor about ‘merely’ demonstrating security and safety flaws – they made real change by forcing congress to effect change virtually over night. Their findings actually caused the stock price of the company to crash
END SPOILERS

And thus encouraged everyone to contribute their skills to making the world a better place – it’s a genuine, optimistic sentiment.
Stupid shit is going on so, unearth the flaws make them public and force dipshit executives to take responsiblity

Nick P • July 21, 2016 11:26 PM

@ John Gonder

I’m with you. I keep feeling like I’m going to exclusively buy “new” cars that are pretty old and well-maintained. There’s also potential to market a new car that uses minimal electronics, keeps them safety-oriented, and provably has no surveillance gear. That might actually sell if it otherwise looks, feels, and drives alright.

infosec • July 24, 2016 6:48 PM

“OldFish • July 20, 2016 8:26 AM

Would not disabling all wireless connectivity go a long way towards making a vehicle’s control systems secure or am I missing something?”

Absolutely. Security, and privacy and by proxy human rights are affected here. Users should be able to disable all RF emanating from their vehicle at their will. V2V is a nightmare – just watch this video from 32c3 (especially the questions and bad responses) https://www.youtube.com/watch?v=uAFjyBcRcGc.

Non-US auto manufacturers (US has had it for years now) have now also started collecting GPS data, web and radio history, and most new vehicles have WiFi, Cellular, Bluetooth, TPMS, RFID (keyless entry), etc switched on and locked in that position until the vehicle is switched off and for some radios only if the battery is disconnected. Just try reading Tesla, but also many other manufacturers’ privacy policies. MAC address/ID spoofing and randomization is necessary for all radios where possible.

GPS requires no Tx, only Rx – downloading maps periodically (configurable to ask for user permission each time it does) (region-based downloads would be best to avoid profiling users) – there is no need to give your location to a third party as Google, Apple try to make people think – again, receiving traffic information should be configurable – off, TMC-only (Rx-only), or full internet-based information (if cellular radio separately enabled).

TPMS can implement metadata/ID randomization (after 1st time authentication done in a user-approved, safe location), encrypt the message contents (with the possibility of switching off Tx or changing the update frequency).

Similarly for RFID (vehicle and keys where appropriate), the following should be set up: ID randomization, open source encryption, a physical hardware switch inside the vehicle to disable Tx from the vehicle radios, a physical hardware switch on the key disabling key Tx completely and a system that by default automatically stops vehicle/key Tx after a user-configurable interval, e.g. 15-30s. A low-sensitivity IR, or similar sensor on doors could allow owners to brush against a door to start Tx for a key-vehicle handshake (vehicle-initiated) and allowing unlocking to proceed when hands are full.

For added security, users should by default be required to place keys in a slot, allowing for vehicle-key authentication without RF Tx. Of course, if users would prefer a more convenient system allowing them to keep their keys in a pocket, this should be configurable, while keeping the key-vehicle communications metadata randomization in place. In this mode, as before, Tx (key and vehicle) should cease once the key is no longer in the vicinity of the vehicle.

Once the vehicle has stopped, the engine switched off and vehicle locked, required Tx should cease within a few seconds. This should also be user-configurable.

Cellular, wifi and bluetooth (with mac address randomization) (anonymity-preserving, secure 802.11 authentication standard is sorely needed) connections should be able to be completely disabled (physical hardware switch) at the owners’ will. Live and historical cellular traffic should be able to be fully visualized, auditable and this history clearable by users. Vehicles should be able to be ordered without a cellular modem, especially given widespread government and corporate modem and SIM tracking. Modems should in fact be user-interchangeable parts and auto manufacturers should not create records (internal or external governmental/corporate) linking vehicle owners to the SIM card, modem identifiers, etc.

Internet data should be able to be configured to be sent via anonymity networks such as tor.

Then, each system should be physically isolated, beyond simply separating entertainment systems from the low-level CAN networks, with monitoring equipment for display on driver screens being the only connection (as possible). Internet-linked systems should be completely separate, and screens should link to different subsystems separately. Physical switches, as described earlier should also help avoid security issues.

Vehicle systems’ firmware must also be able to be updated by users in an open manner.

Someone really has to push these issues – governments may, with the push for “driverless cars”, V2V, no user control, etc force vehicles to have wireless identifiers to add extra real ID authentication beyond license plates. Europe has already forced all manufacturers to place cellular modems in new vehicles to facilitate the eCall system which is a gross violation of security, privacy and raises serious human rights issues. This kind of legislation creates potential loopholes for manufacturers to push their tracking on users – collecting user data for ad sales – this gets even worse with Google getting into the business – and also forcing drivers to have a permanent RF footprint allowing for tracking that may be used to violate human rights and/or privacy. Just consider how the Chinese and other dictatorships (let alone Western intelligence and law enforcement agencies) worldwide will love manufacturers placing this equipment in their vehicles to comply with road and “national security” laws. More power to the already omnipresent, omnipotent, omniscient, to large companies and yet less power for the individual all veiled in the name of “convenience”, “‘smart’ progress”, “safety”, “security”, etc.

targetdrone • July 28, 2016 12:04 AM

To the people who want manual-only brakes in their vehicles, and no CAN bus, are you truly lowering your overall risk by giving up ABS and traction control? By giving up side curtain air bags and seat belt pre-tensioners? Is your risk of mortality or avoiding an accident by having improved braking under most conditions more or less important than the likelihood of a hacker doing ‘something’ to your car?

And yes, lots of people claim that they are a most gifted driving instructor; that they have special training, skills, experiences, or talents that enable them to out-react and out-perform an automated system. I’m not asking anyone to convince me that they drive better than a NASCAR driver, you have to convince yourself that you may not always be the perfect special snowflake you believe yourself to be. This needs to be an honest self-evaluation of human skills against automated systems that have 100% uptime; monitors that never get sleepy, distracted, or otherwise impaired. With that comparison as the starting point, factor in the likelihood of your vehicle getting hacked and your safety systems being disabled. Which choice keeps you and your passengers safer?

As Bruce has written several times, we humans are pretty much terrible at evaluating risk. We maximize the scary improbable tales, and deemphasize the mundane everyday threats. But here, we have actual traffic and accident statistics that can help us make a better decision, if we can get past our egos to evaluate ourselves honestly.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.