18
$\begingroup$

Wouldn't they be more secure if they used the same encryption technology computers use for remote access?

$\endgroup$
  • $\begingroup$ Reading your question here, this post totally came to mind. $\endgroup$ – mikeazo Jan 3 '17 at 13:30
  • $\begingroup$ What research have you done? $\endgroup$ – e-sushi Jan 3 '17 at 16:04
  • 5
    $\begingroup$ Remember when asking questions about "more secure" that it helps to say against which attack. $\endgroup$ – Eric Lippert Jan 3 '17 at 21:02
  • $\begingroup$ It's worth noting that rolling codes are vulnerable to replay attacks. See wired.com/2015/08/… (RollJam) $\endgroup$ – Ajedi32 Jan 3 '17 at 21:29
  • $\begingroup$ Note that many door openers do not even use a rolling code :‑[ $\endgroup$ – Maarten Bodewes Nov 25 '18 at 16:48
17
$\begingroup$

I can think of several issues with using PGP or TLS:

  1. Both PGP and TLS require certificate management (unless password based), it would be tricky to get a PKI going for this;

  2. PGP and TLS are overkill for key fobs / garage doors and would put unnecessary strain on the choice of processor and battery;

  3. PGP and TLS require access to a secure random number generator, which is also pretty expensive to put in a key fob.

  4. The TLS handshake requires two way communication;

  5. Both TLS and GPG require intricate implementation of the message protocol (stuff you can do without for a door opener).

Even from a technical standpoint TLS is overkill; you're really just interested in authenticating a command that cannot be replayed. This explains the choice of a rolling code I guess.


Those are the technical reasons. I guess most of the manufacturers aren't that IT savvy either. They might not even know about PGP or TLS. They're more likely to be interested in motor & hinge design and picking the right color for your door.


That said, there's likely some kind of home automation that can

  1. open a door and
  2. uses some kind of transport protocol or message authentication.

I doubt if these two "heavy weight" protocols are used towards the door though.

$\endgroup$
  • 1
    $\begingroup$ Cars can last 10-20 years, what's overkill today may not be so 20 years from now. Regardless, your mention of the processor, battery, and the need for two-way communication are valid issues. Many cars already have 3g & 4g and very soon cell phones will be used as keys. That would eliminate all three concerns. So maybe switching to cell phones as keys and adding 3/4g to cars is the answer. I think Volvo is already working on this. $\endgroup$ – Bernard Igiri Jan 3 '17 at 15:47
  • $\begingroup$ PS removed "authenticated transaction" from the answer; there is no revocation or rollback involved; there is no reason to revoke a transaction such as "open door" - it just won't open :). $\endgroup$ – Maarten Bodewes Jan 3 '17 at 17:09
  • 3
    $\begingroup$ @BernardIgiri "Overkill" in manufacturing terms, is anything that costs a fraction of a cent more than necessary in order to do the job. However, if as you suggest, they can offload the processing to a smartphone you already own, I'm sure they'll be more than happy to peruse that avenue. $\endgroup$ – Xander Jan 3 '17 at 21:08
  • $\begingroup$ Almost all the points of this answers are wrong. 1. No PKI is needed, just storing the fobs' public keys in the device to be opened at the time of manufacture/setup/keying. 2. May be somewhat correct but less so with EC. 3. Also completely wrong; you have three options, a few bits of persistent storage and a csprng, environmental entropy collection. or a hardware-rng in the IC (sorta a variant of option 2). 4 and 5 are correct but irrelevant since you'd just use the public key crypto directly. $\endgroup$ – R.. Jan 4 '17 at 4:51
  • $\begingroup$ Feel free to write your own answer, @R.. I don't mind downvotes either. I don't agree with your reasoning, but at least you have reasoning. $\endgroup$ – Maarten Bodewes Jan 4 '17 at 9:29
11
$\begingroup$

The answer is costs to manufacture/develop and the simple fact 99.8% of criminals couldn't hack a Yahoo password, let alone figure out how to hack RF devices. The 0.2% who can have better things to target than your garage.

I looked into it and bought some devices to do so. It's a big PITA and can be pricey. There are cheap devices that can easily copy cards but good luck figuring out compatibility since the companies have more product names for the same item than a mattress chain.

There is a service for cloning those cards/fobs called clonemykey.com. I'm a field I.T. guy who also works in software development on IoT devices. I bite the bullet and send it to those guys when I - uh - need some extra keys.

Those are the technical reasons. I guess most of the manufacturers aren't that IT savvy either.

They are.....and they just don't care. Their customers can't tell the difference and most building owners aren't expecting Elliot from Mr.Robot to screw up their system.

$\endgroup$
  • $\begingroup$ Besides, it's still vulnerable to the exploit of shoving a system of thin poles and strings under the door, that then expands into a scaffold that lets you poke the button by the inside door. I havn’t tried the Wile E Coyote variation of inflating a helium balloon and using it to grab the manual release cord near the motor on the ceiling track. $\endgroup$ – JDługosz Jan 4 '17 at 6:30
  • 1
    $\begingroup$ Yes I heard this security joke in a conference last night. Basically the 0.2% of people who can are qualified to have real jobs in electronics / security and are thus earning more money then the criminal could. $\endgroup$ – dave.zap Jan 4 '17 at 11:48
6
$\begingroup$

Most of the more secure key fobs (such as used in new cars) work this way:

  1. Car sends challenge code.
  2. Key fob calculates message authentication code from shared secret and the challenge and sends it to car.
  3. Car makes same calculation and checks the code.

There are some less secure older key fobs, but they were less secure only because people thought "this is secure enough".

Now, PGP or SSL would only improve this in one way: they use asymmetric encryption, so it would eliminate the shared secret. But the private key would have to remain in the key fob and the public key would be in the car. So it seems to me that this would only eliminate the ridiculous attack of "steal the car to duplicate the key".

Instead, the real security issues in key fobs would remain, as they require completely different solutions. Biggest current problems are:

  1. Attacker blocks the response from the key fob and re-uses it later to open the car. This can be eliminated by adding a short timeout to the protocol.
  2. Attacker uses directional antennas to form a radio link from distant key to the car. This only affects keys that open by proximity without pressing a button.
  3. Attacker finds vulnerabilities in implementation of the challenge-response protocol (such as timing attacks) and uses them to fake the key. It is still an open problem how to verify the quality of security-critical software.

Further reading: http://www.cs.tufts.edu/comp/116/archive/fall2015/arichardson.pdf

$\endgroup$
  • $\begingroup$ If you have a reference for the widespread use of two-way communication (as necessary for challenge-response) in key fobs for new cars, I'd appreciate it; I missed the transition to this from unidirectional communication, which was standard some years ago. Also, if you have a reference for relay attack (your "biggest current problem" #2) being a quantitatively significant issue.. $\endgroup$ – fgrieu Jan 4 '17 at 12:17
  • 2
    $\begingroup$ @fgrieu I added one good writeup that I happened to know about. But in general manufacturers don't publish their protocols so all you can find is reverse-engineered information. As for the 1) and 2) being significant, they have been publicized widely: wired.com/2016/03/… . Whether they have actually been used to steal any significant number of cars, I do not know. $\endgroup$ – jpa Jan 4 '17 at 12:29
  • 1
    $\begingroup$ @fgrieu relay attacks were used to steal BMWs, I can confirm that at least $\endgroup$ – Richie Frame Jan 4 '17 at 12:35
  • 1
    $\begingroup$ @jpa: thanks for the additional references. The linked Wired article links to Aurélien Francillon, Boris Danev and Srdjan Capkun's Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars which I also find very interesting. $\endgroup$ – fgrieu Jan 4 '17 at 12:36
2
$\begingroup$

The designers of the systems evaluated the cost of the security versus the risk, and settled on a system that would provide them with an acceptable level of security at a reasonable cost.

All the systems you suggest require more powerful processors and more power at each end. This means your keyfob doesn't last as long on a single battery, and your competitor can use that as a selling point for their competing, though slightly less secure, product.

On top of that you have significantly greater customer service and support issues. Generating certificates, passing them between the various devices, or otherwise sharing these secrets to allow one device to control the other either becomes very difficult for the user, or leaves large security holes which would eliminate any benefit these more secure systems might convey.

In the same way most homeowners and insurance companies are fine with a 5 pin tumbler lock for their home valuables, trading some security for ease of use and low cost, most keyfob users are fine with rolling code keyfobs.

$\endgroup$
  • $\begingroup$ I agree with you about the cost/marketability ratio, but I don't believe the support issues would be so great as you believe. Here is how to re-sync a key fob. I see no reason why the same procedure couldn't be used to cause the car to trust a public key sent from the key fob in that same time frame. Just straight asymetric encryption would be fine. $\endgroup$ – Wildcard Jan 23 at 21:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.