What would be the downside of Hyundai just making all the info in this blog post public info? They could start fostering an app ecosystem for their cars. And it would be an extra selling point for their cars (especially if there are apps that won't run in other cars). And it might even turn into a new revenue stream by building an app store.
There are some things you don't want to run apps on, even if they're sandboxed, which isn't the case here - I would count "computer in my car that can talk to the stuff that makes it go" as one of these things.
I hacked my car
11–20 of 142 posts
Re: I hacked my car
#12Earlier quoted context omitted.
There are some things you don't want to run apps on, even if they're sandboxed, which isn't the case here - I would count "computer in my car that can talk to the stuff that makes it go" as one of these things.
And yet most cars run apps. Are you arguing that those not coming from/authorized by the manufacturer are less legitimate, or should not deserve the same treatment?
Re: I hacked my car
#13https://datatracker.ietf.org/doc/draft-gutmann-testkeys/
From the point of view of m.d.s.policy the main idea is to require CAs to reject these keys in certificates for the Web PKI and encourage software to use these keys (rather than their own examples) in sample code. Basically when you build my-cool-website.example and copy paste the private key from an example into your certificate fetching code, the CA should say "Er, no, you need to actually choose your own private key, that's what the word private means" and this should happen when you copy-paste a high-rated Stack Overflow example, the provided sample code from the library you used etc. Ideally these would all be the same keys is the idea.
It would also make sense for tools to care about these example keys e.g. GitHub could flag code that's checked in and has keys which are not these examples since maybe you used real keys by mistake in your GitHub repo, meanwhile your build-for-production CI tools could reject keys which are on the list because that means you forgot to pick actual keys for the real build.
Re: I hacked my car
#14https://snakeoil.cr.yp.to/submissions/Lolcipher%20Submission...
Re: I hacked my car
#15Writing custom software looks like a really promising alternative though, especially if the vehicle's cellular connection can be used. Hell, if the IVI uses the CAN bus, perhaps there's a reverse-engineerable list of PIDs.
[0]: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A...
Re: I hacked my car
#16Don't expect much from a manufacturer who until recently didn't use immobilizers.
In what universe is 20+ years "recently"? Actually the Hyundai I had - with an immobilizer - was made in 1995 so 27 years. Is this American thing?
Re: I hacked my car
#171: https://github.com/impfen/apps-inoeg/blob/main/tests/fixture...
Re: I hacked my car
#18Makes me feel better about my own incompetencies. But also makes me scared for the future of safety in vehicles.
Re: I hacked my car
#19Re: I hacked my car
#20The big question, of course, is: Why haven't we had a security apocalypse? I imagine it must be because most software engineers are honest, and because the bad actors who have the skills and resources to pull it off (e.g., foreign government agencies) have a vested interest in maintaining the status quo.
So, non-technical managers everywhere go on with their lives thinking their software infrastructure has been "secured," without really knowing whether it's true. Consider that no executive or manager at Hyundai was aware until now that their vehicles have been using a previously published private key to update their software.