[Cryptography] What do we mean by Secure?

Arnold Reinhold agr at me.com
Tue Feb 10 14:16:07 EST 2015


> On Feb 9, 2015, at 9:16 AM, Kent Borg <kentborg at borg.org> wrote:
> 
> On 02/09/2015 08:02 AM, Arnold Reinhold wrote:
>> Indeed, BMW had all the security components it needed in its remote car unlock system, it just didn’t put them together properly. Sneer all you want at “best practices” documents but they are a proven tool to help change happen in large organizations.
> 
> I am sure BMW made a lot of stupid mistakes, and most of us would know better about many of them. Spotting mistakes among many is easy. But to make a secure, connected car, where all the right people have access and none of the wrong people have access is hard. (Who are all these different people? When is some individual the right person and when does he become the wrong person?) It just takes one teensie, little, gigantic hole and it is broken.
> 
> It really *is* a hard thing to build a secure connected car. No one has done it, and until we can hash out contradictory expectations about what the proper properties of this car are, it will remain impossible. (Does this car have an app? Oh, hell, now the boundaries of the system BMW has to defend probably just exploded. Does the AAA have access? Do the cops have access? Does your mechanic have access? Does the authorized BMW mechanic have access? Does some BMW engineer have access? Does the engine computer port have access? Does the handsfree bluetooth gizmo have access? Do the CAN-connected brakelights have access? Does the finance company have access? What are the security questions to recover access for the owner?)
> 
> Could BMW do better, could avoid a ton of stupid mistakes? Certainly they could. But they have to care about security and hire some people who know and not insist on selling a broken thing just because they can make millions doing so and they can't let Lexus get there first and everyone expects security problems anyway.

> 
> Handing BMW a binder labeled "best practices" would not solve their problems, but like the no-one-got-fired security trio (corporate firewall, current antivirus software, and current service packs) it might make them think they have solved their problems.
> 
> AES-256 and SHA1 are great, and assembling them sensibly into a larger program is tricky but very doable. Assembling that into a product that can remotely unlock your car doors--but only in the right circumstances--is a mess. (Yes, "Soooooo Hard.”)

I don’t think it is as hard as you suggest. The policy questions you rase about who has access are ones that auto makers have dealt with for a century. Cars have never been as secure as technology allowed. Owners who lock their keys inside want solutions other than breaking a window. Finance companies need to be able to repossess cars with minimal damage or they must charge higher interest rates. (I suspect the ability to turn on remote access after the owner disabled it was a feature, not a bug.) And the communications model is one central server to many clients. That makes checking the signature of messages to the cars relatively straightforward.

Remember the threat here, car thieves. Even if the underground hacking community finds an exploit and offers it for sale, there are only so many thieves who can employ it. And BMW apparently has the ability to remotely upgrade car firmware, so a spike in break-ins could be detected and remedied before excessive damage is done. (Even without remote upgrades, it has a well tested dealer recall mechanism that do them.)

The Internet of Things is just getting started. Thousands of programming projects are not doubt already underway, some involving critical infrastructure. Most will be designed and coded by security muggles; there are simply not enough wizards to go around. A binder labeled "best practices" will not solve all the IoT problems, but it can avoid a lot of them. And, of course, among the best practices can be a requirement for expert security design reviews at several stages of each project, including an analysis of unprotected threats, so no one has a false sense of security. But you don’t want those reviews to get bogged down in fixing the most basic mistakes.

Arnold Reinhold




More information about the cryptography mailing list