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

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

6 Answers 6


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.

  • 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$ Commented Jan 3, 2017 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
    Commented Jan 3, 2017 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
    Commented Jan 3, 2017 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$ Commented Jan 4, 2017 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
    Commented Jan 4, 2017 at 9:29

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.

  • $\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
    Commented Jan 4, 2017 at 6:30
  • 2
    $\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
    Commented Jan 4, 2017 at 11:48

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

  • $\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
    Commented Jan 4, 2017 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
    Commented Jan 4, 2017 at 12:29
  • 1
    $\begingroup$ @fgrieu relay attacks were used to steal BMWs, I can confirm that at least $\endgroup$ Commented Jan 4, 2017 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
    Commented Jan 4, 2017 at 12:36

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.

  • $\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
    Commented Jan 23, 2019 at 21:11

I think that it is because of its make. Not every garage remotes/doors use PDG. It depends on the nature of it.

  • 1
    $\begingroup$ Welcome to crypto-SE. Good answers should introduce the acronyms they use: I could not figure out what you mean with "PDG". Also, the question ask why, and that's left essentially unanswered. Much like, in a question about why humans have a language, stating that's their nature is not an answer. Stating that language gives an advantage over species that do not, and natural selection has gradually crafted genes making that meme (language) possible, is an answer (invoking some divine plan is another). $\endgroup$
    – fgrieu
    Commented Oct 30, 2020 at 7:07

Every mifare card does the cert handshake just fine with minimal effort... the chip has the crypto in it you load the cert and call it a day... but I am also after a commercially available programmable remote that can do the same. Reset remote so remote generates new private key... hold programming key combo push a button on the receiver to program new remote... remote sends public cert and that is it.... nothing else is really required... if you want 2-way handshake then remote receives receiver's public cert so it would not even talk to other receivers but that is not necessary for this to work.... if anyone knows of an opener that does this let me know.

  • $\begingroup$ Did you ever find one? Just fyi, there are systems that utilise the cellular phone network that can be quite secure if done right. You pop a prepaid SIM in the device and you can setup a list of authorised phone numbers. You then call or SMS that phone number and if your phone number is in the list it'll close or open a relay momentarily. Some have additional security that requires a code after connecting or in the SMS (because otherwise you'll be relying on security through obscurity since phone numbers can be spoofed). But this is not a 1:1 replacement for a key fob & relay setup :( $\endgroup$ Commented Apr 7, 2023 at 22:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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