UKC

This is nonsense, surely. Surely a car key isn't emitting when it's  not being used, and surely they don't  have any capacity to receive 'instructions ' remotely?

Some contactless keys are read out by the car without you having to do anything to the key.  Thieves can use a range extending device poked through your letterbox to bridge the keys in your house to the car, allowing them to open and start it.  Car won’t turn off without key for safety reasons, so off they drive.  

Slightly dim system when you think about it...

Tell that to our neighbours, who had their newish high end Mercedes nicked.

Neighbours opposite caught the whole event on their cctv.

The thieves took all of 15 seconds from pulling up in their car to driving away in the Merc. 

Used an amplifier to boost the signal from the key in the house apparently. 

Car key works as follows: 

Press button on fob, fob sends a standard wake up call to the car.

The car sends a "what's your PIN?" to the fob.

Fob replies with it's PIN. Car opens doors.

What thieves are doing is to send the wake up call to your car, standing outside your house and receiving the PIN from your fob. 

The Faraday cage wallet stops them.

Yeah, Heddlu were pretty certain this is how my Fiesta was stolen a couple of years ago, along with all my MR kit. Fortunately I had good insurance, but I have a Faraday pouch now.

On our car, the first step can be done by pressing a button in either of the front door handles or by opening the rear boot.  No need to ever touch the key.

Bloody stupid system.  Should use time of flight and deterministic latency in the key fob crypto unit to enforce a maximum distance of 4 m from the vehicle.  Should also have an option to disable “keyless” mode.

Agreed. I hooe that anyone who designs such "security' systems feels a deep sense of shame for their complete failure to do their job. 

https://www.eurocarparts.com/p/stoplock-original-steering-wheel-immobiliser...

I'm not for a moment suggesting this is secure and can't be removed by a half competent thief, but I would suggest that unless you have a fancy car being stolen to order this should be plenty enough so they take your neighbours car and not yours.

"Lock it or lose it" is the expression and since they had the oh so brilliant idea to make cars that don't lock with a key any more, you need an after market lock like this.

IMHO the problem is a lack of basic common sense and competence from the manufacturers. Throwing technology/ complexity at this will just obscure the problem.

They're guaranteed to implement it stupidly making the situation actually worse, then carp on about the technology meanwhile the consumer would pay even more for a system that's even cr*ppier.

Edit: security is my business and I'm often reminding people that the underlying principles are actually simple and have been around since Adam and Eve, we just dress them up in fancier names

Keyless ignition is an idiotic solution to a non existant problem, like so much else about modern cars. Whoever invented it should be flogged.

Of course the best solution would be if people refused to buy such cars, they would soon stop making them.

It's a system designed for low cost and high convenience - the business people want it cheap and the marketing people want it convenient.  Presumably they have been in business long enough and have a good idea of what customers want, in the sense of what influences purchasing decisions, rather than what people say they want when they aren't actually spending money.

From a security perspective there are three basic ways of authenticating someone:

a. something they are (a biometric)

b. something they have (a key)

c. something they know (a password)

For a good level of security you usually want two factor authentication i.e. two out of three of these.

A keyfob which initiates without being pressed has none of these attributes when the attacker has a range extender.   If it needed to be pressed then the car would at least know they potential driver had the key.  If it needed to be pressed and had a fingerprint sensor it would have a and b.   If it had a keypad to enter a password it would have b and c.

I can see that convenience may outweigh two factor authentication but zero factor authentication is a step too far.  They should make you press the button before it does anything.  And they should use standard crypto techniques to stop simple man-in-the-middle attacks capturing and replaying the signal between fob and car.

I disagree.  I think your intuition for protocols is leading you astray.

A man-in-the-middle attack modifies or injects information in to the data stream.

This attack is a relay at the physical layer - layer 1 in the OSI model.  This is well below the layers where crypto lives and crypto can do nothing about it.

The car relies implicitly on the inverse square (RF) or inverse cube (NFC) decay of signal strength to validate the key as being near the car.

The attackers relay the electromagnetic interaction - right down at OSI layer 1.  This modifies the information in the signal strength and the signal latency.  It doesn’t touch the information at the protocol or service layers where crypto lives.  The signal strength information is maliciously modified to overcome the implicit “must be near car” authentication.  The signal latency is unavoidably modified by relativity imposing a finite speed of information travel, and interactions with matter further slowing that.

With signal strength as authenticable information trivially bypassable for “must be near car”, all that’s left is relativity imposed time of flight/latency. 

Crypto defences can do nothing against someone swapping a short cable for a long cable, which is what this attack mounts to.  The only option is to measure the length of the cable and hope the Bad Guys don’t have an Eisenstein Rosen bridge.

Or, you require initiation by a button pressed on the key using bog standard crypto techniques to protect that.  But if you want genuinely hands off, you have to use time of flight to defeat range extenders.

Edit:  the key misunderstanding I think is when you said “replaying” - this is *not* a replay attack.  

I saw a proof of concept of this type of relay attack years ago on some website, so it's nothing new.

What's so annoying and predictable about this whole situation is that the manufacturers know about this flaw, they have a solution in ToF that would not be expensive to implement, and yet they are still selling cars with this crappy system. And I've just bought one. I just hope no one wants a 4 year old Leaf that badly.

Yes.  But the comment at the end of my post was not specifically about how to prevent the attack with the range extender it was a general comment about how they should design key fobs.  The range extender isn't the only possible attack, for example an attacker could grab the signal when a driver unlocks their own car and replay it later.

My suggestion for preventing the attack with the range extender was the key fob should do nothing until a button on the fob is pressed.  That way the person initiating the unlock has to have the keyfob about their person. 

I think the next generation of key fobs are incorporating accelerometers so they go dormant if not moved for a while. 

Time of Flight isn't a cure-all.  The difference in distance between when you might want a car to start flashing its lights and unlocking as you approach and the distance between keys on a peg in some people's hall and a car outside their house isn't that much and light is pretty fast.  So you are talking about time differences in the 10s of nanoseconds and you might need to worry about multipath effects which you wouldn't care about with a brute force system based on signal strength.

Time of flight doesn't get rid of the need for crypto.  If you have an unauthenticated signal an attacker could just capture the waveform from a valid unlock and transmit it near the car.  To solve both the replay attack and the signal relay attack the car would need to measure a round trip from the car to the key and back with the key doing some crypto calculations and sending a different signal back.  It is doable but the keyfob also needs to be small, cheap, completely reliable and run for years off small batteries.   

Probably when the engineers start doing the sums on cost and battery life and the potential for not being able to get in your car at some point the marketing guys say f*ck security, just make it cheap and work all the time.

Possibly using a phone as your car key will become the option of choice for people more concerned about security than convenience.

I keep my car's hand crank by my bedside at night. Useful for tackling the ne'er-do-wells if they break in on the rob

Simple replay attacks have been a solved problem since not long after central locking was invented. https://en.m.wikipedia.org/wiki/Rolling_code

ToF would mostly work for this, until the edge case where someone's bedroom is only *just* far enough away from their parking spot. Light travels a foot per nanosecond. Measuring time differences on that order is also a solved problem (own anything with a GPS receiver or lidar sensor in it?)

Solution I'd propose is an off switch. 

An encrypted one time code using a counter or a nonce validated as new by the receiver can be defeated if the transmitting code is captured and the receiver blocked from getting it, as then it’s not a “replay” but can be used as a “delay”.  I think I recall hearing of this being used - the symptom is a car key not working; you wander off to call for help and someone uses your “delayed” code and unlock it.

To beat this there are two options I can see:

1. A two-way cryptographic session would need to be established with the key rather than sending a one time passcode.
2. The one-time element would need to include the time using a time system shared by the car to allow for validation it’s not delayed.  This would need a power consuming always on RTC in the key, or a GNSS receiver in the key (not impossible).

In reply to Hardinicus:

I like it - that would limit range extender thefts to the middle of an earthquake; simple, effective and good enough.  

Are you thinking of is the jamming attack that hit the press a few years ago? People were hanging out at motorway services and blocking the 'lock' signal from button press key fobs, then raiding the boot of the car while the owner went inside.

The attack you describe is detailed on the Wikipedia page I linked but it's not something I've read about happening in the wild. Maybe it's been solved or just isn't as easy as targeting the touchless systems. Would be an easy fix just to require a response of some form.

A block and delay attack beats the one time password unlocking mechanism, it doesn’t then defeat the separate key interaction that starts the vehicle, so it’s not the most useful attack in the world unless you have some other stuff to get the car started...

I couldn’t knick cars with the RF extender attack. The constant incessant bonging it makes if you drive off without a key would drive me insane in about 60 seconds.

I might well have been thinking of a lock jam attack...

... which would be of very limited use in protecting the vehicles of people who routinely keep their key in a trouser pocket. Would prevent thefts while people are actually sleeping, but that's about it.

That's when this is happening. 

The time it doesn't take to reprogram a blank key is another giant facepalm. As ever, it's seconds with a device you can buy off eBay.

How many cars get nicked when the owner is actively prancing about the immediate vicinity?

Though on second thought, the natural thing to do if someone was trying to steal your car in any other situation probably wouldn't be to stand very still.

No reason you can't have both.  A key isn't inconvenient, I've seen cars that have fobs that you have to put in a slot to start them, if they had contacts that would work.  I can never think where to put it when I get in anyway so a slot would to me be a positive.

I would also not object to 2FA in the form of fob plus 4 digit PIN, say.  Phone a bad idea as if it fails you're locked out of the obvious place to charge it.  Same as using it to unlock your house.  Fingerprint a possibility but not always reliable.

My car will only unlock without a button press if the key is less than 1m from the button. If I'm stood next the the drivers door, the passenger can't unlock their side based on my key being near the car. So ToF doesn't have to be very accurate, just reject anything with a distance of over a metre or two.

+1. Only caveat being a very reliable switch is needed (not that hard tbh)

I'm guessing relatively few, but relying on the key being stationary seems to me like a pretty poor choice when securing a vehicle worth tens of thousands of pounds!

IMO everyone is barking up the wrong tree. What we seem to have with car locking is a security arms race. Unfortunately, the side with the real incentive to win this arms race (or at least stay ahead) are the car thieves.

The manufacturers have an incentive to market (and sell) the latest and greatest gizmo but they don't really care if your car is stolen so they're not incentivised to properly sort this out.

Who actually pays for the thefts - we all do via insurance, but because it's spread across all of us we tend to accept it as a general increase.

If the insurance costs of these thefts were only paid by those whose cars had been stolen, then the "I'm never buying a xxx again" would eventually influence car manufacturers - I'm not suggesting this as a solution btw.

One way forward would be for the costs of any thefts due to inadequate security solutions being paid directly by the car manufacturers (rather than our car insurance). The financial impact would give them the proper focus and incentive to sort this out properly.

They could still bump start it.  I hope you have the distributor arm under your pillow as well.

Aren't we kind of heading that way now that everyone gets their cars on tick? Is there no loss borne by the PCP companies?

I just wish car keys still worked by actually putting them in the lock and turning them. I would then not have one of the back doors on my car permanently locked and would not have just spent £127 getting the rear door to open and shut. One of many unnecessary, unreliable and expensive electronic things that cars are plagued with these days. A few years ago I had to scrap a mechanically perfectly good car because an electronic blip kept shutting down the engine and nobody knew how to fix it (despite paying nearly £2000 for them to try).

I'm astonished by how many people seem to be over complicating the issue diving into technology without stepping back and looking at the simple/basic principles

tom_in_edinburgh is one of the few people to do this by pointing out this is a "cable length" issue. Replay isn't the issue it's extension.

What the manufacturers were attempting in a half assed way was to verify two factors

1) Person has, possession of the key

2) Key is, near and/or inside the car

Neither went that well as signal strength is used as a proxy for both factors. One way to vastly improve factor 1) could be the person has to perform an action such as pressing a button on the key during some part of the process. Maybe pressing a button on the key approaching the vehicle Gasp!!!!! 

I know there are scenarios where someone is carrying an object and getting a key out of pocket is inconvenient but that is such an extreme low % edge use case. In doing so they threw away a hugely valuable step of user having to performing an action with the key

Lots of interesting points in the thread. To address some of the things other people said in no particular order:

Steering wheel lock: It would work but it's annoying to have to put on. People are lazy and busy - they don't want to waste time putting it on and they want to be able to jump in the car and drive away instantly when they get back in. My prediction is that for most it would become a chore they stopped using.

Finger print biometric: Pfft, this is a climber's forum isn't it?? Even when I'm not climbing much and don't have damaged fingerprints (like right now) the fingerprint biometric fails on my computer regularly and on my phone sometimes. Dust, oils, water, etc. all screw it up when your finger/thumb isn't perfectly clean. It's a terrible idea for a car imo.

cunning programming stuff: Today we program an unbreakable system. Next week someone manages to hack it and break it. The week after the problem is patched. Then another weakness is found. etc. etc. This cycle goes on constantly with software and I don't believe that any arrangement of 1s and 0s is going to permanently break the cycle. Is the solution really going to involve the car and key constantly updating from wifi like a phone does? Do we really want to be buying an incredibly expensive item and hoping that the manufacturer will continue to provide updates for the next 10-20 years? That they won't go bust or decide to stop supporting older systems (like Microsoft with older Windows versions)?

A switch: People forget switches if there is no prompt. Go back 10 years and tell me how many people you know left their lights on by accident and flattened the car battery. Probably quite a lot. Any sort of switch to turn your key "off" is going to get forgotten far more often than remembered, not least because there will only ever be one time in the car's life where that switch will do anything at all (i.e. the day it gets stolen).

Button press: I'm pretty happy with my van's system. However. If you sit down on the key in just the wrong way, the van unlocks all the doors and winds down all the windows and when you wake up the next morning the seats are soaked and you are pretty happy you live in a low-crime area... and this has happened more than once.

Interestingly "easy to get into" and "not secure" are, on the face of it, phrases which mean the same thing. Which might be the fundamental problem to which there is no solution - you can't have extreme ease of use _and_ a high level of security at the same time.

I've never seen a car with the pattern-drawing thing with 9 dots that you have on most smart phones. I wonder why that is. Does it just totally screw up in the rain?

Pressing buttons is so 1990. Next year we'll be reading about people stealing cars by standing in the street shouting 'Alexa, start my car'

I once had a car with 2FA - a citroen xantia that had a little numerical keypad on the central console that required a PIN code to deactivate the immobiliser after turning the ignition on.

It's not going to stop a professional car thief, but it added about a second to the process of starting the car which is hardly onerous, and always seemed like a useful precaution against opportunistic theft - if someone had lifted my key from my pocket in the pub or the locker in the gym, they could wander around the car park blipping the remote to locate the vehicle and enter the car, but they still wouldn't be able to start the car without the slightly more specialist knowledge of bypassing immobilisers.

My solution is what I actually do - buy a cheap car that no-one wants to steal. No theft, and I save money on the purchase, job done

Their immortal souls?  

The problem is nobody has programmed in unbreakable stuff.  The car industry has taken a manual of “how not to do cryptographic authentication” and followed it to a T.  They’ve done an inexcusably dumb effort that apparently considered software in isolation of all the aspects of the system.

There are theoretically secure authentication methods, and they’re neither difficult nor novel.   Although they would then force criminals to break in to a house to steal the keys, potentially using violence against residents to discover their location.  

Pressing a button is exactly what the hardware OTP device on my keyring requires.  Like car keys it uses a counter to prevent replay attacks, and so is still vulnerable against a jamming/capture/delay technique.  Which is why I’m keen on an additional measure using a time stamp inside the encrypted packet to guard against that - but that is a bit much for a compact, passive device!

i remember the old joke about how if cars were like computers giving a list of all the things which would go wrong.

Then the auto companies started using computers and decided to use the joke as a target.

Yes, that's my solution too. Adding a few scratches and knocks the bodywork helps as well.

Alternatively they could put a keyhole in the ignition that you put the key in and turn.

You have to put the key somewhere and you have to press a button where the keyhole should be anyway. It adds around two or three seconds to your journey which is less time than it takes to remove and replace your key in a Faraday pouch and prevents anyone stealing your car without the key.

It's also cheaper and can't really go wrong. As I said above, keyless ignition is a pointless solution to a non existant problem. How many people did you ever hear complaining about having to turn a key to make their car start before keyless ignition was invented?

They should fit a knob that says 'choke' on it that you need to pull out to start the engine. That'll stop the scrotes.

these days it would be labelled "Woke"

system.

this is what I came on here to say, if there are completely secure methods, then the criminals will go back to the old fashioned method of breaking in and stealing the keys! 

I had one of those - Citroen xantia estate in my case.  Had completely forgotten about the keypad.

Even better, one that won't stay out and you need a clothes peg to keep the engine running when cold. That's like having a second key, if they don't come armed with a clothes peg and they can't drive off. Those were the days!!

Or if you had to keep the throttle in an incredibly precise position and recite a special incantation that is definitely not family friendly while turning the key. 

I learned how to swear properly on cold winter mornings in the 80s.

Not necessary. I have a crossbow booby trap set up when anyone sits on the driver seat

Its been suggested that carrying electronics in a Faraday cage wallet when you are ski touring prevents the interference that you get between avalanche transceivers and electronics.  I am told (I am completely ignorant about this) that the main problem is screens so turning devices to airplane mode doesn't avoid this interference.  

It's not like mechanical car keys were any good either. There's not enough focus on making stolen cars too hot to handle, you can grind numbers out and clone plates but the myriad factory electronics and their interaction with manufacturer databases should render stolen cars easily found, unclonable and unusable once identified. 

Jk

Motion detection to activate the key would deal with the vast majority of cloning/boosting thefts and it maintains the zero (apparent) owner interaction convenience of keyless entry.

Jk

Is it motion detection or just which way up am I detection? Both would do the job of figuring out whether it's lying flat on the sideboard. One would have a much lower power need.

Neither have any real power requirement. Once every couple of seconds: is acceleration 9.81....? Costs nothing.

Jk

Done right, motion detection can scavenge some power from the motion.

First thing I thought of was a tilt switch that cuts power completely. But of course that's not going to use enough unnecessary MIPS for the IoT age.

Just buy a Vauxhall. Trust me, no one wants to nick it.

It only takes light 3ns to travel a metre.   Time of flight isn't the way I'd implement a 'less than 1m separation' criterion in a low cost battery powered device.

It’s the car that has to validate the round trip latency, not the key.  The only requirement on the key is that the latency of the RF > crypto processor > RF process is constant to within ~ 12 ns.  This doesn’t need a fast clock, just an accurate one, and a crypto algorithm whose cycle count is independent of the data - as all good crypto algorithms should be.

I come back to this being an attack at the physical layer.  To fix it without changing the method of using the key, the only option is to expand the authentication channel from signal strength to other properties of the physical layer; time of flight is the most obvious.  Anything more complicated is going to be very complicated and I suspect either easily circumventable or not robust enough for normal use.  

How *would* you authenticate the distance without otherwise changing the way the key is used?

Wintertree beat me to it, but I'll say it anyway - how would you do it?

ToF is ideal. It's straightforward and cheap nowadays, and unbreakable. The laws of physics prevent you getting a timely response from a key that is out of range.

It's exactly what I used when I needed to measure a less than 1m separation with a low cost solar powered device

https://www.google.com/search?q=VL6180X

Admittedly that's IR but in principle it's cheap to do.

Didn't used to be the case. Years ago the cavalier Sri was an ideal ram raider's getaway car - enough room for 4 plus big boot, faster than local bobby's patrol car and totally innocuous once round the corner.

A mate of mine once had a car with its own 'special' type of choke. You had to pour half a cup of petrol into the carburettor before trying to start it to get a rich enough mix.

Kids these days in their fancy new cars they don't own, don't know they're born!

That's nothing like the same thing, that is infra red light from VCSEL laser module being reflected off something and back to the module.  Try making that work with a key fob in your pocket.  It is also completely insecure.

The car application needs a radio in the car communicating with a radio in the key fob which can be at an arbitrary angle in somebody's pocket and have various things between transmitter and receiver like metal doors, a human body, clothing, a handbag, glass windows.  Also there are surfaces RF will reflect off giving multipath and the car could be parked near other cars with similar keyfobs so there's a need to make sure the right car is unlocked.

The keyfob needs to receive the signal, extract a packet of information from it, carry out some cryptographic operation on the packet and retransmit.

And it is supposed to do this and tell the difference between 1m distance and two or three metre distance when light travels 1m in about 3ns.

I think it will be fairly tricky, not impossible, but tricky.  Your first problem is you need a fast clock in the keyfob and that's the last thing you want for something that needs to be low power e.g. 100MHz clock is 10ns between clock edges  so you've got quantisation of time measurement to 10ns before you start.

This is why people are using insecure ways of determining distance and why it might be better to just have a button on the keyfob.

I had a motorbike a bit like that.  It was horrendous to start from cold, until I accidentally discovered while trying to bump start it one day that the trick was to lie it down on its left hand side then pick it up again.  It never failed the rest of the time I had it - lie it down, pick it up again and it fired up first go.

In reply to wintertree:

If there's no crypto processing in the keyfob it is completely trivial to make a bogus keyfob that looks like a real one.  Or, even easier, use a keyfob for another car of the same model.

If you separate the crypto processing to authenticate the keyfob from the proximity detector the thief could use a range extender to defeat the crypto processing and a bogus keyfob near the car to defeat the proximity.

I was working for a car company I would recommend putting a button on the keyfob and not having a proximity system.  If they insisted and didn't give me a budget for more hardware and power consumption I'd do it in an insecure way i.e. measure RF power, unauthenticated time of flight on a simple waveform or maybe some kind of near field technology if it was OK to not activate until very close to a car door.

It means there needs to be crypto in the keyfob and it has to be in the loop of the proximity system.   The post I was responding to was pointing at a proximity measurement system with no crypto at all and saying it was easy.   If the fob just retransmits the challenge signal from the car with no processing then anybody's keyfob would trigger anybody else's car.

The car not the fob would be expected to perform the round trip timing which is basically trivial. The difficulty here is fixing the wake time latency for the fob but that's managable with hardware (FPGA probably for low volume devices) wake command detection. You don't have to clock the whole fob at a high rate or constantly, just the IO buffers/and a return trigger counter so the power cost isn't huge. Basically it's very doable and very very hard to spoof. 

Jk

Bugger, deleted my post instead of editing it to fix a typo, sorry.

Sure, we all agree on that.  A contactless key is not a great idea.

Indeed.    Crypto on a small packet is neither difficult nor computationally expensive however.  

As I’ve said several times, the timing measurement is done by the car, not the key, in this scheme.  The key does not need to be GHz fast, it needs to be < 12 ns consistent in timing, which is a different thing.

Yes, but their point was that time of flight is cheap and easy, not that a laser pointer could be used to unlock a car.

You can pre-activate the key with a variable latency wake signal; allocate say 100 ms for that, then it has to be guaranteed-latency for responding to the crypto op.

How do you know your are measuring the delay to the right fob if you don't do the calculation on the cryptographically verified message?   If the authenticated message is separate from the mechanism for determining range the thief could put the fob for their own car next to the car they are trying to steal while using the range extender to defeat the crypto as per the previous scenario.

If the range determining message is to be cryptographically verified it needs to be processed in the key fob.  If you want to use this as part of a time of flight system at a range of a meter then the latency through the processing needs to be very tightly controlled.

With a 100MHz clock you are quantising time at 10ns i.e. data which arrives delta t after the clock edge isn't going to be processed until the next edge 10ns later.   That's going to cause jitter on the round trip time even if the delay through the crypto is always the exact same number of clocks.

I think, like many things, this is harder than it looks and there are reasons why it's being done the way it is being done.

Good luck with that. Problem with old cheap cars is that they're easy to knick. I once had a clapped out cavalier that I'd paid £100 for knicked from my drive (I, too, had made the assumption it wasn't worth knicking). 

As for those that propose going back to old fashioned keys - I'm thinking that either you weren't around in the 80s or didn't own a car during that period.  If you were around in the 80's and owned a car, there's a good chance you didn't own it for long.  Which is why we don't just rely on keys and manual chokes to prevent car theft anymore.

You've missed the point of my last post; the ToF bit is easy. That IR sensor measures ~1cm accuracy by timing light pulses, and it costs a tenner. So you can stop thinking that ToF is difficult. Sure, won't be as accurate with GHz signals but it's in no way the hard part.

And this doesn't need to be low power; it's done by the car, not the fob.

The rest of the problems are the same ones you need to solve to build a reliable and secure RFID tag. Last I checked they're not that expensive.

Still, though, my approach (if pushing a button is off the table) would probably be more like that. Just established RFID tag technology with a tilt switch so it doesn't work lying down flat. Then there's no battery to worry about and your key would be washable. They're used to protect things more important than my car, so at that point it's not about outrunning the bear...

The car does the timing calculation, not the fob.

The key fob needs consistent timing.

The clock speed on the key fob does not matter.  10 MHz or 10 GHz is irrelevant.  

The consistency of the time taken by the key fob to RX > crypto > TX matters.  It needs to be consistent to < 12 ns.  There are ways of achieving this without an accurate clock even.  

The problem is the clock in the car and the clock in the key are not synchronised, they have an arbitrary phase relationship.  With a 100MHz clock you can have up to 10ns time difference between the clock edge in the car and the clock edge in the key.  That uncertainty is additional uncertainty on your time of flight calculation when the signal you are using to calculate time of flight is sampled by the key clock to pass through crypto circuity on the key and then again when the signal transmitted by the key is sampled by the car clock.

Possibly there are ways the car could quantify this or a scheme where the unknown delay at the fob cancels out with the one at the car.   It would be neat to find a cheap and secure way of doing time of flight and authentication with the same signal.

The accuracy of the clock isn't the problem it's the quantisation caused by the period of the clock.

I am not missing the point.

You need a known time delay between the times of the incoming RF packet and the outgoing RF packet.  This is the phase relationship that matters, not that of the digital clocks.

The fob can spin a PLL up to sync to the phase of the incoming carrier wave and maintain that timebase; this can maintain a phase relationship to far higher precision than 1/the clock frequency for the brief time needed to do the crypto op.  This can all be spun up before the brief message from the car that needs to go through crypto.  You don’t have to synchronise the crypto processor to this recovered phase relationship, just the outgoing message transmission.  The carrier wave ceases a cycle or so before the received message is due to be transmitted.  

Synchronising clocks to way higher precision than their frequency is old hat stuff.  The carrier wave can start before the crypto session to allow lock.

*Insecure* time of flight is easy.  But it doesn't solve the problem.

A tenner is a lot of money in electronics.

Again, unless the fob does crypto processing on the signal before sending it back there is no way of knowing you are detecting the right fob.

The fob does the crypto.  The car does the ToF.  The fob uses RF carrier recovery in the low frequency carrier signal to transmit at a known cycle number and phase relationship (to higher resolution than the RF clock, 50 ppm typical for PLLs) from the receipt of the packet it encrypts and transmits.  Only the RF part of the fob needs precision timing, achieving using PLL carrier recovery,  async fifos cross domains to the crypto processor which just needs to do the processing in time for the transmission.  The car analyses the received data burst to measure the round trip latency.  The car can spin up a fancy pants high speed CPU to do this, and it can have a high precision Rf front end.

Edit:  all of which is why it’s simpler and cheaper to need a button press on the fob or have an “am I moving” detector on it; but I think it is possible to do it with the car doing ToF analysis and using decades old techniques on the fob.

what about phase difference on arrival?

So now we have clock recovery circuits and we are basically building a full blown digital radio with extra features to ensure constant time.

I don't think simple schemes with a carrier wave are going to work.  What happens if several of these cars are near each other in a car park.   How do you stop the key locking on to the signal from the wrong car.

The whole scheme needs to be robust to multiple simultaneous transmissions from several of these keys and it needs to operate on already crowded ISM bands.  That's going to drag you into the sort of things the WiFi/Bluetooth people do.

You can buy Bluetooth chips with time of flight ranging but they're more for social distancing and I don't know that the ranging function is designed to be secure against a malicious person trying to spoof it or that Bluetooth is going to give you the ultra-low power to run for years off a coin cell.

The solution with a button on the key just seems preferable.

something not requiring electrical power to open the door has my vote - I can live without central locking at all.

Yes, pretty old hat stuff really when you look at what CSR have been doing and as you say where some of that stuff is today.  

Same as old fashioned coaxial Ethernet; collision followed by backing off an random time to retransmit.  Or the person gets their car key out and presses the button.  Although, as it’s intended to be a very local effect I think you’ve been over blowing this one; how many times do you end up standing back-to-back next to someone in a carpark using their fob?  Contactless is only for use when right next to a car door, with a range no more than an arms length.  For drivers at two adjacent cars parked side by side, the proximal fob is ~25 cm from the door (pocket within arms length) and the distal fob is ~250 cm from the door (a car parking space over), so the signal is 100x less from R^-2 and there’s a car in the way.  Remember this isn’t for remote unlocking from a distance, it’s about detecting that the key is on the person touching the door handle or door handle recessed unlock button.  It may even be near field so R^-3.

I think we’ve all agreed on that for some time... 

Which I don't recall being that big a problem.

https://www.independent.co.uk/money/spend-save/don-t-leave-car-keys-hall-ta...

It was the case not so long ago (may still be now) that you could actually get a lower insurance premium if your car was kept on the street rather than on your drive (all other things being equal: location*, desirableness of the vehicle etc etc).  The reason being that if the car is on the drive then the thieves know which house to break in to to get the keys.

Police forces were (and maybe still are) always advising people not to just leave their car keys on the hall table.  Example from 3 years ago: https://twitter.com/lanarkshire_pol/status/984761762607239169

Some folks have even had problems claiming for theft of their vehicle because they hadn't kept the keys in a safe place at home.

One approach to burglary was (and may still be) to nick the car keys along with the other valuables, and use the householder's car to make off with the loot.  Even if the thieves didn't actually want the car (so they'd end up dumping and torching it), it meant that they didn't have to drive to the property, with the risk of their own vehicle being recorded on ANPR and CCTV.

All the above would apply to a contactless key in a faraday pouch as well, of course.

* In which context it's worth bearing in mind that modern residential developments often don't provide much on-street parking, if any - and yet the properties' internal accommodation is often such that people end up using their garage for storage and leave their car[s] on the drive.  So the location may actually constrain residents' behaviour in this respect.

Years ago, I remember Jeremy Clarkson reviewing a new car, possibly a Mercedes, that had a key range of ~40m and lamenting the fact he'd have to keep the key at the bottom of the back garden to put it far enough away that someone couldn't just open the door and drive off!

We've got such a car and my wife keeps her key in her handbag beside her bed - which is all of about 2m and a wall away from the car. Makes it a bit pointless me keeping mine in a stainless steel container, but at least I can blame her if it gets stolen...

I guess it depends what you’re driving? I know several people who had their houses broken into solely to take car keys, including one with a tracker nicely showing it disappearing into a container in Hull.

our car is so old and grotty I could imagine the thieves coming into the house in the middle of the night and asking us to pay to take it away

I'm not quite sure which bit you're struggling with so it's hard to know where to focus.

Let's imagine for example you have a car that periodically, at a precisely logged moments sends out a challenge, this can be at a relatively low baud rate: CAR_ID plus a challenge sequence to be responded to and returned. That arrives in the fob's input buffer, this is clocked at a high rate so each message bit occupys multiple bits of the input buffer. The correct CAR_ID token can be detected trivially in hardware, its arrival time accurately logged: upon this event a precision timer with period T1 is started and the detector wakes the crypto processor, the response is generated from the challenge at leisure but in less time than T1 takes to roll over. The response token is pushed back into the output buffer when it's ready and when T1 rolls over it's pushed back to the car. The fob goes back to sleep. Time of flight plus T1 is now known to significant precision by the car and the fob has expended little energy. The fob's credentials can be verified by the car. T1 is known by the system designer and therefore the car. C is known so 2*s may also be determined give or take the uncertainty caused by small quantisation error in the high rate IO buffer/T1_timer. Plus or minus 1m would easily suffice to prevent a repeater/booster attack so there's no ridiculous clock hardware needed.

The high speed buffer/detector in the fob has very few gates so consumes little power despite the high-ish clock rate. It also needn't run continuously assuming the car re-transmits its challenge frequently it can be run periodically to sniff for a car as we approach our vehicles slowly, authentication can take seconds with no inconvenience.

Only the challenge arrival to response transmission latency needs to be known, the encryption can take its time so long as it fits inside that window.

It's not being done because these attacks either weren't considered or were considered too sophisticated to be of concern. I doubt insurers now see it that way. It really isn't very difficult to do even with the low power constraint in the fob.

I'm sure there are obvious refinements to that workable plan particularly around the noddy 'cryptography' of which I know nothing except how you'd hack that bit of my plan. It doesn't matter, the crypto bit is bracketed by the range measuring system. I'm thinking back 20 odd years here to my spread-spectrum comms lectures for a steer on how you could do this simply and cheaply in hardware (likely an FPGA rather than custom IC), it's not what I do day to day.

jk

If you're making toys. Not if you're securing a £50k asset.

jk

I pretty much agree with that.  

Improving it by phase locking to the RF signal to reference the latency precisely is not challenging in terms of what was being done a couple of decades ago and miniaturised over a decade ago, at the frequencies involved.  The bogeyman of competing signals is death with by how extremely short range these are meant to be.  

I'm not sure I'd use a clock for the encryption; a cypher like AES or ChaCha20 can I think have both key and data arms unrolled quite effectively; this lets you make an asynchronous circuit where you have no clock but just a fixed duration timer that changes state some time after the output becomes valid.  There's beauty in asynchronous circuits, and it's lower power.  The cost of custom silicone will be pennies on the car across the lifetime of the system for a major auto consortium.  My preference is to phase lock the timer to the low frequency RF signal, but failing that there are more techniques for building a small, compact ultra-precise timer than there are for ultra-stable clocks.  Especially as the timer has to be precise but not accurate - the jitter on the timer and its synchronisation to the RF is what matters, not the absolute value.  Assuming each key includes a unique ID in its return packet along with the bounced code from the car, the expected latency of that key is just part of the data coded in to the car.    The key could even measure its temperature and send that to the car, for use with a temperature dependant model of the drift; plenty of space in an AES block for that.

Still I can't go agreeing all the way with another poster, what would people think?

I fundamentally disagree.

IMO, the purpose of a shitty, half arsed job in a contactless car key is the same as the purpose of the shitty, half arsed job done over chip and pin.  It's to provide just enough plausible deniability that the involved parties (banks, car manufacturers, insurance companies) can hand the liability off to the customers without risking their bottom lines.  Some would argue that auto manufacturers in particular might benefit from the status quo.  Those executive cars leaving in containers aren't displacing sales in the destination market, and are generating new ones in the home market.

Winner, winner chicken dinner.

I'm trying to remember how and when I became so cynical.

I pretty much agree with that.  

Improving it by phase locking to the RF signal to reference the latency precisely is not challenging in terms of what was being done a couple of decades ago and miniaturised over a decade ago, at the frequencies involved.  The bogeyman of competing signals is IMO dealt with by how extremely short range these are meant to be.  

I'm not sure I'd use a clock for the encryption; a cypher like AES or ChaCha20 can I think have both key and data arms unrolled quite effectively; this lets you make an asynchronous circuit where you have no clock but just a fixed duration timer that changes state some time after the output becomes valid.  There's beauty in asynchronous circuits, and it's lower power.  The cost of custom silicon will be pennies on the car across the lifetime of the system for a major auto consortium.  My preference is to phase lock the timer to the low frequency RF signal, but failing that there are more techniques for building a small, compact ultra-precise timer than there are for ultra-stable clocks.  Especially as the timer has to be precise but not accurate - the jitter on the timer and its synchronisation to the RF is what matters, not the absolute value.  Assuming each key includes a unique ID in its return packet along with the bounced code from the car, the expected latency of that key is just part of the data coded in to the car.    The key could even measure its temperature and send that to the car, for use with a temperature dependant model of the drift; plenty of space in an AES block for that.

I suspect the market for cryptographic keys authenticated as proximal by time of flight is wider than cars.

Still I can't go agreeing all the way with another poster, what would people think?

I fundamentally disagree.

IMO, the purpose of a shitty, half arsed job in a contactless car key is the same as the purpose of the shitty, half arsed job done over chip and pin.  It's to give marketing brownie points whilst providing just enough plausible deniability that the involved parties (banks, car manufacturers, insurance companies) can hand the liability off to the customers without risking their bottom lines.  Some would argue that auto manufacturers in particular might benefit from the status quo.  Those executive cars leaving in containers aren't displacing sales in the destination market, and are generating new ones in the home market.

Winner, winner chicken dinner.

I'm trying to remember how and when I became so cynical.

You could also get the car/key to look for changes by getting the key to respond to the regular polls in a simple fashion - if the range changes impossibly fast (measured by ToF) bad things are happening. If the key environment changes impossibly fast bad things are happening. You could also give the key a 'base station' in the house which responds to a poll from the car - if the base station hasn't told the car the key's left it before the other conditions change, something bad's happening.

In reply to various posters: How does looking for a button press on the key make things secure? With a relay attack (making the car think the real key is within proximity) the signal from the car is simply relayed to the key along with any return signal (including keypress) from the key.

Surely in the case of a hacker pretending to be the key and a system using a rolling key signal being generated, the car must know what signal the key is going to send next time it's pressed, and thus any hacker can replicate that?

That’s a tenner for a 1-off, retail from adafruit or whatever, and integrated on a dev board.

If you buy it on reel the part doing the work is sub £2, and that £2 has to cover a laser, sensor, a bit of profit for ST micro, the package, everything needed to talk I2C as well as the bit of silicon that does the ToF workings-out. So to me that says working out ToF is not a high-dollar problem.

If you're worried about the time taken by the fob to do crypto stuff you get it to respond instantly in a non-crypto fashion, then again with the crypto. The instant response gives the car the info it requires to do ToF calcs, and the crypto response gives it the security stuff.  The crypto response time is going to be virtually the same every time and well in excess of the signal round trip time thus easy to deal with.  You could even get the key and car to negotiate a bespoke crypto time at setup thus preventing a hacker from using a standard crypto time if trying to pretend to be the fob.

I don't think so. Manufacturers are doing keyless for the same reason modern cars don't have a radio with knobs on anymore - things that move break, and using the brain of the car for doing multiple things in software is cheaper. No doubt the RF gubbins for detecting keys is done by the same antenna that the radio uses. By doing away with the ignition barrel you do away with having to make handed steering columns and all the wiring associated with the ignition barrel which is costly to install and prone to faults in addition to those the RF side has.

The rolling signal derives from a counter maintained in the key.  The car keeps a note of the last seen counter value, and only a newer value will be accepted to prevent the replay of a past message being accepted - it will be decrypted and the counter value will be too low.

The actual value itself is part of the encrypted message sent from the key to the car, and can't (far in exceptionalities of all practical senses) be determined by the Bad Buys from RF traffic.  The encryption will use a pre-shared digital key stored in the car and in the physical key, and will also encode a unique ID number for the key (used to validate the key, and to determine which counter value to compare it with).  To measure time of flight it also needs to encode data sent from the car to validate the timings.  The core secrets protected by the the encryption key and the unique ID, the counter is included in the encrypted packet to defeat a replay attack

The hacker can never get the counter value, they can just trigger the key to do its thing and facilitate the encrypted message reaching the car.  They have no visibility in to the encrypted message.

The vulnerability arises from having the car be able to initiate the key.  If a physical button has to be pressed to allow the key to work, the hackers can't do that without touching the button.

Sergeant Zim explains it better than me -  youtube.com/watch?v=B203twyaMfM&

The YubiKey OTP is an example of this sort of system - source code for it here - https://github.com/openbsd/src/tree/master/libexec/login_yubikey

Not such a bad idea, having had issues with what turned out to be a worn out ignition barrel on one of my cars.

Used to have a minibus at the Scouts that got to the point where the ignition barrel had fallen apart and it could be started with anything - I used to use my front door key, but even a screwdriver would do it!

Fingerprint sensing would also stop me jumping in my Dad's car unless he was with me, or lending my car to my mate, unless I lent him my finger at the same time!

I hide my fob on the car when I run, which means that although it is locked any door can be opened just because the fob is in close proximity (within 3 feet)..

I wished I could get a car with the Ford-like door code but like to run without holding my key. I only still do this if I'm running in areas I'm pretty confident are safe and have nothing in the car.

Excellent work. 10/10. Haven’t had a good one of these for a while 

Seems like a wheel clamp could be the thing for keeping modern cars safe.

I think porsche had something like a removable hard drive with the engine management system on it. I believe it was coded to the vehicle.

Removal made the car immobile. I'm sure manufacturers could do something similar., but knowing how they count every fraction of a penny, I doubt they'll bother. 

Sounds like you need a Faraday pouch!

It shouldn't be but it is.  These guys are tight AF.

Sure, but the instant response is not secure and could be faked.   So e.g. an attacker could tape their own key near your car and then do the same attack as before to extend the range of the crypto signal from your key hanging in your house.   The key near the car tells the car it is nearby and the range extended key hanging in the house tells the car the authentication is OK.

The laser system is totally irrelevant.  The key is in your pocket and you are at an unknown distance and bearing from the car and moving.   Radio is omnidirectional and penetrates clothing or a handbag.

Ha ha CSR that's a blast from the past.  I did some work for them years ago.

The kind of Bluetooth radio chips CSR/Qualcomm make could be extended to do this.  But Bluetooth isn't that low power, whether its a solution for something that needs to run a couple of years off a coin cell is doubtful.   Building these ASIC radio chips has substantial up front cost.

I once did a sales visit to Siemens in Munich for a chip manufacturer.  The entire car park was full of 3 series BMWs and it wasn't a small car park.  I remember this because the sales guy I was helping also had a 3 series BMW and we had to find it again after the meeting.

If you had a contactless key system which wasn't strongly tied to a specific vehicle there are places where you could be seriously inconvenienced and people expect their car keys to be totally reliable.

Yes, making it near field and using one of the near field chips that are in credit card readers and phones might be a good solution.    Whether anyone would bother adding time of flight to a near field system I don't know.  If it is near field its going to be hard to access a key hanging inside somebody's house to do the range extension attack.  The downside is the key won't trigger the car until you are much closer than with current systems.

Yes. That's what I'm saying. It's not about lasers, point of me showing you that module is to demonstrate the time of fight bit to centimetre accuracy costs buttons. Thought I was pretty clear that I'm not saying you would use a laser.

Yes, but the fact that an IR laser costs buttons tells me nothing about how much a radio plus security circuits capable of solving the actual problem would cost or whether it could run off a coin cell for a couple of years.

Of course it doesn't. That's not the point it was meant to address. On Sunday morning the issue was whether ns timing differences were hard to measure. Answer: no.

It was never about whether ns timing differences could be measured by the part of the system in the car which has plenty of power.

It was about whether the measured times at the car correlated closely to range in an authenticated system incorporating a keyfob where the keyfob receives, cryptographically processes and retransmits data sent by the car.

Bluetooth low energy really is that low power.

All it needs to do is issue a secure response with a known latency from the time of arrival of the car's challenge. There are various low power options I can think of to deal with the timing/clock recovery and the response push timer none of them remotely radical. Even the ultra low power requirement ignores the possibility of occasionally charging the fob.

It isn't done because nobody is effectively demanding better security, the manufacturer, insurer, owner loop isn't closed and governments don't seem to care. Security is only ever as good as the weakest link anyway, fix this flaw and cars will still be driven off without consent one way or another. In the communications era and given the complexity of the vehicle's electrical systems preclude cost effective replacement after theft the best solution is probably to render stolen vehicles worthless. Either kill the electronics from HQ or flag up the ID of every part in the vehicle, make it unmaintainable through channels with any interest in ongoing legitimate business. Batteries, inverters, even engines with their myriad embedded sensors, they'e all valuable but every sensor, every processor, every memory within them is identifiable and networked, even the wheels through their pressure sensors will have unique electronic IDs. Want to stop car theft? Flag up stolen parts and vehicles whenever they come into contact with the legitimate trade and wreck the market for stolen cars.

jk

...and fob charging could be done by making it a requirement to plug it into somewhere to start the engine.

The attacker would need to know your key ID though.....

No they wouldn't.  That's the point - if you separate the time of flight to ensure the key is near the car from the path through the authentication to make implementing it simpler, then the time of flight isn't secure, so another key could spoof it.

Sure, it isn't an insoluble problem but it might take an RF ASIC to do it with low power.

Probably some variant of Bluetooth would be best because new cars will all have Bluetooth for other reasons.

I wouldn't be surprised to see car key become an app on iWatches and using a standard like Bluetooth might help enable phones and watches to be used as keys.

I'm not sure people will accept a car key that needs to be charged regularly.   If you went away for two weeks holiday you might not be able to drive your car until you charged the key.  There would need to be some backup way of using the vehicle - like an actual metal key!

At least some electronic keys also include an emergency physical key (Land Rover and Jaguar, at least, I think Audi too).

That would get you into the car, although I'm not sure about the immobiliser if the ley was completely dead - never had to try it!

One of our cars has a key that is wirelessly charged when you put it into the dashboard slot that enables the engine.  This is great as you never have to change the battery in the key.  It's never been a problem that it runs out of charge - even after 8 weeks laid in during the recent lockdown.  Nevertheless, there is a physical key inside the fob that can be used to unlock the drivers door, e.g. in case of a dead car battery.  It's concealed in the main key.

Our other car has keys that have a traditional "unlock button" and also a contactless mode.  The buttons depend on expendable batteries.  If the batteries die, the key can still be interrogated by a near field reader in the door handle to unlock the car, and is then authenticated to start the car by holding it against the start button, which contains another near field reader that works despite a dead fob battery.

TiE seems a bit behind the times on how these actually work, with all these things already being out there - their suggestions of using Bluetooth and phones as keys are already out there in the wild as well - for example Tesla vehicles can be paired with a mobile phone as a key, and by default they use a credit card sized NFC key with a reader in the pillar behind the drivers door.

The older cars I had that had an immobiliser and a physical key would interrogate the key through a wireless system powered by a coil in the ring of the ignition barrel.

The auto industry has always apparently thought through all the failure modes of the keys quite clearly, which makes it seem likely to me (not to an evidenced standard, mind) that they were always fully aware of the gaping security hole in contactless keys, but were happy to shift the liability to the occasional unlucky customer in return for marketing brownie points.  I think the technology needed to make a securely encrypted key has moved on in spades since contactless keys first came out; a custom RF + crypto circuit for the fob doesn't seem that demanding - especially if you can think past the issue of synchronous logic in to async logic and an analogue calibrated time delay circuit - and the "civilian" level kit available for software defined radio that the car could use to authenticate the timing as well as the crypto has stormed on.

Or we could demand a button press...  As contactless has to be used basically next to the door, multi factor authentication with face recognition is probably a much cheaper and more sensible solution...

do these cars let you get in if the car battery is dead?  Not hard to imagine a winter emergency where someone leaves the car, finds they need to get back in for shelter against high winds, blizzard.  Easy to imagine at 2000ft asl in Cumbria/Durham

could the wrong choice of car in these circumstances kill you?

This is already a thing. I once helped a friend regain access to his car by getting underneath and attaching a charger to the starter lead, because there was no way to open any of the doors without power. Even with the physical key.

the designers should be made to carry out survival tests like this personally, in winter, in the arctic.

Half an hour from shelter

Even the new one still has a physical key hidden in the fob and one mechanical lock.  

I think the loch mechanism might be prone to ceasing as it might go for a decade without a single use; certainly some people report problems.  I should probably exercise it occasionally.

Plenty of rocks handy here to put a window out with on the leeward side if needs must, and then use floor mats etc to seal it as best as possible.  

Which is why I mentioned Bluetooth might be a good base technology to extend to include the authenticated time of flight that was being discussed.   

I had completely forgotten I once had one of those - and I have remembered the PIN as well!  Dead simple, always worked.  My current car is keyless, and raises all the issues discussed here.  Yes, I use a Faraday bag, and yes I did test it - it works.

Once had a van on which the previous owner had put a switch into the electric fuel pump wire, brought inside the van and hidden. Worked. Cost zilch. 

I’ve done this on a couple of cars years ago. Most secure though was a Ford Anglia van on which you had to clean the rotor (on the tyre), dry off the condensation and spray with damp start.

Things that don't move also break and when they do it's much harder (and more expensive to the car owner) to diagnose and fix them.

Keyless ignition introduces a serious security flaw whilst offering no benefit to the user whatsover so even if the security issue could be fixed it's still pointless.

On the subject of knobless radios, and for that matter heater controls, these so called improvements force the user to take their eyes off the road to find which of the numerous flush buttons to press or icons to tap on a screen because you can't just reach and feel them and thus distract the driver from what they should be concentrating on. It's bad enough for people who can see them but for those who need reading glasses (but not glasses to actually drive in) trying to decipher which symbol is which is even more distracting.

Most car design happens because techy nerds enjoy designing it, not because it serves any useful purpose, add run flat tyres and space saver spares wheels to the list of pointless crap on modern cars along with rain sensing wipers which are guaranteed to always wipe at the wrong speed.

I had this on a Citroen Dispatch van. Unfortunately it was a gen 1 and the key pad folded down to access it, great idea until 4 years in when the opening and closing 8 to 10 times a day caused the wires to snap and me sanding a couple of hours with no phone signal in North Yorkshire soldering the wires back together again.