> But the consequence is that people feel like they are being fleeced when they need another key, because it can cost you hundreds of dollars to pair one.

Because the ARE being fleeced. It's an artificial dependency on the vendor on the one hand versus a blatantly insecure approach on the other.

Secure pairing that can be done by the end user isn't rocket science.

▲

the_mitsuhiko 6 days ago | parent [-]

It is a bit rocket science because cars stand around. The CAN bus can even be externally accessed if you pop open the right part of the car (common fault are adaptive headlights). It is not as trivial as people make it out to be because cars violate one of the most important principles of having good security: no physical access.

▲

fc417fc802 6 days ago | parent | next [-]

That has nothing to do with secure pairing. It's an entirely orthogonal concern. Any sensitive system on a vehicle is going to be subject to the same thing.

I don't think anyone will be surprised if the security is swiss cheese once you pop the hood open or bust a headlight out. Keep in mind that a brick to the window and tearing up the center console will get you physical access to the head unit on most vehicles.

▲

IshKebab 6 days ago | parent | prev [-]

It is trivial:

1. Initiate pairing via the entertainment system interface.

2. Use rolling codes. Don't allow rewinding the codes.

3. Add a tiny tiny bit of non-volatile memory in the keys so that batteries can be changed without breaking the key. This is only necessary if the car can't be entered using the physical key, otherwise the user can just open the car with the physical key, turn on the ignition and re-pair the key.

I could make a secure system to do this and I'm no crypto genius. (Note this would still be vulnerable to rolljam but that's not a very practical attack, and defeating that is a bit difficult.)

To support car hire/share places if they want to prevent users pairing new keys you could allow setting a password on the pairing interface.

▲

the_mitsuhiko 6 days ago | parent [-]

That's more or less already how the rolling code based systems work. The problem of course is that if you have access to one of those keys (or use rolljam to get one or more codes) you have enough to get another key added.

▲

fc417fc802 5 days ago | parent | next [-]

That isn't the problem, at least not the major one that lead to this discussion. It's that the algorithm used is broken. It's example number 9001 of why you should never roll your own crypto for a commercial application. (Amusingly example 9002, TETRA radios, was also on the HN frontpage around the same time).

▲

the_mitsuhiko 5 days ago | parent [-]

First of all they did not roll their own crypto, it's just not the most modern crypto any more. Secondly while this particular permutation of the issue is related to bad crypto, it's cascading a completely different issue which is that it's just fundamentally possible to pair a key with physical access which is easy to get.

▲

fc417fc802 5 days ago | parent [-]

From Wikipedia:

> KeeLoq is a proprietary hardware-dedicated block cipher that uses a non-linear feedback shift register (NLFSR).

Pretty much any proprietary encryption algorithm is going to qualify as "rolling your own".

"Not the most modern" is a gross understatement.

I can forgive the original authors since it dates to the 1980s and AES wasn't standardized until 2001. (Only just barely though given that DES dates to 1977.) I can't forgive vehicle manufacturers that are _still_ using it (or things significantly like it) 25 years later.

I hope that products manufactured post 2005 use strong publicly available cryptography. After 2010 I fully expect it. After 2015 I view any failure in that regard as gross negligence that ought to be legally actionable.

> it's just fundamentally possible to pair a key with physical access which is easy to get.

I don't follow?

▲

the_mitsuhiko 4 days ago | parent [-]

> Pretty much any proprietary encryption algorithm is going to qualify as "rolling your own".

It came out of a university and was acquired.

> I hope that products manufactured post 2005 use strong publicly available cryptography.

A lot of the challenges are related to key pairing and relaying of wireless information in combating with jamming. It’s a tricky thing to secure given the circumstances.

> I don't follow?

Cars stand around 99% of the time and easy to get into. pairing protocols assume that physical access is restricted / not possible. That’s why it’s so much harder to secure car key pairing. What would make it more secure is delegating the security to a remote service which is secured. Eg: what Tesla does with their keys.

▲

fc417fc802 4 days ago | parent [-]

That changes nothing. The idea behind not rolling your own isn't just deliberate expert design but also open review by other unrelated experts.

> It’s a tricky thing to secure given the circumstances.

You are hand waving and you are wrong. If you are going to make claims then be specific and make solid points. The various algorithmic solutions are simple and common knowledge these days. I went into more detail in adjacent comments.

By your own logic the physical entry key isn't secure either. After all the car is just sitting around - anyone could jimmy the lock. Similarly all it takes is a decent photograph or two with a telephoto lens to reproduce your typical physical key that will get you in the door.

But all of that is entirely off topic. The broken and outdated wireless algorithm has nothing to do with the criteria used by the vehicle to decide whether or not someone is authorized to enroll or revoke a key. Tie that to possession of the physical key and problem solved. If you can't drive off with the vehicle then you can't pair a new fob either.

	▲	the_mitsuhiko 3 days ago \| parent [-]
		> The various algorithmic solutions are simple and common knowledge these days. Honestly I'm not really sure what you are trying to get to. If you think this is a solved problem, it's really not. [1] > The broken and outdated wireless algorithm has nothing to do with the criteria used by the vehicle to decide whether or not someone is authorized to enroll or revoke a key. Tie that to possession of the physical key and problem solved. It has something to do with it in the sense that key pairing that just requires physical presence through the key is susceptible to rolljam type attacks. Likewise the NFC attacks against Tesla also involved enrolling a new key on the car via a relay attack to a present NFC key. You're saying this is so easily solvable, yet time and time again it's shown that this is just a really hard problem to solve. [1]: https://arxiv.org/pdf/2505.02713

▲

IshKebab 5 days ago | parent | prev [-]

Yeah exactly - requiring either an existing physical key, or an impractical rolljam attack is much better than what they have apparently implemented.