Wouldn't they be more secure if they used the same encryption technology computers use for remote access?
I can think of several issues with using PGP or TLS:
Both PGP and TLS require certificate management (unless password based), it would be tricky to get a PKI going for this;
PGP and TLS are overkill for key fobs / garage doors and would put unnecessary strain on the choice of processor and battery;
PGP and TLS require access to a secure random number generator, which is also pretty expensive to put in a key fob.
The TLS handshake requires two way communication;
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
- open a door and
- uses some kind of transport protocol or message authentication.
I doubt if these two "heavy weight" protocols are used towards the door though.
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.
Most of the more secure key fobs (such as used in new cars) work this way:
- Car sends challenge code.
- Key fob calculates message authentication code from shared secret and the challenge and sends it to car.
- 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:
- 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.
- 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.
- 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
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.
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.