Schneier on Security

anonymous • October 4, 2014 10:27 AM

The overall point of my comment was to encourage people to made educated decisions, based on data, rather than making assumptions and committing the straw-man logically fallacy.

We all have preconceived notions, many of them based on getting burned in the (often times not so distant) past. I get that. I started reading this report looking for facts to back up the comments because I assumed they were probably (at least partially) correct. I’ve come to expect people designing new systems to take a very one-sided approach. In this case, I expected them to care more about safety than privacy. Similarity, I expect security folks to care about security and privacy with little regard to performance, easy of use, or functionality. So before I looked at any of the data, I already had an opinion, and that was that this was going to be terrible, and now I’m going to have to look for a loophole on who doesn’t have to comply, or find some exploit so I can illustrate how terrible of an idea this is. What I found after I opened the PDF and got past the initial shock of how bloody long it was, was that they actually do think about privacy and security. They have taken years to analyze this warning system, and have estimates on how many lives it could save. Once they demonstrated the potential benefits, I was at least willing to consider what they had to say.

@name.withheld.for.obvious.reasons

Based on your response, it’s unclear whether or not your concern of forced stopping and issuing of tickets has been addressed. It seems like it has and you are now raising a concern of having people’s location being tracked, although your sarcasm makes it difficult to tell. Since the only information being broadcast is that there’s a car there, and not that YOUR car is there, it seems that this doesn’t aid in tracking. There are far easier ways for government agencies to track your location, as I’m sure you are aware.

@Thoth

Oh, I strongly disagree that proposals always look good on paper. Many proposals completely omit the question of privacy, as they’re concerned with whatever their subject of expertise is (e.g. safety, robotics, production, etc.). As for the devil being in the details of implementation: absolutely. However, if the architecture is broken, then it means that all implementations are also broken. It’s similar to a vulnerability in a specific piece of software, versus a vulnerability in the protocol. In one situation, there might be a vendor which does a decent job.

How would I guarantee what they say? The short answer is that I wouldn’t without first having someone I trust (possible myself) verifying that the implementation matches the specification. However, the goal of this report was not to describe a specification which is to be followed. This is merely providing evidence that this V2V communication concept is technically feasible, that the cost is going to be this many dollars per vehicle, and this will be the estimated benefit. They feel that the benefit outweighs the cost. I suspect that the specification will be open, as it will be difficult for manufacturers to maintain compatibility. They could keep the spec under an NDA, but then they would have to deal with all the people asking questions by themselves. If they release it as an open specification, then people can discuss it in public and help one another.

A side note on verification: I’d argue that we have to verify everything, including open source software and hardware. Making it closed source does make this more challenging, but making it open source doesn’t solve the problem. Also, since I trust certain others, if the EFF or CCC reviewed it, I would probably take what they say at face value without looking over it myself. So when I say that I’d have to verify it, I mean

Unintended consequences & looking for the weakest link: agreed. I don’t see anything here that would be the weakest link. There are almost always unintended consequences which come along with new things, especially technology. To prevent these, we could just never adopt any new technology of any kind. That doesn’t seem like a good plan. On the flip side, there’s also the cost of not adopting new technology. It’s typical for people to be weary of new technology, but when we look back on the days of elevator operators and telephone switch boards, the sentiment is often “wow, I can’t believe people lived like that!”

I think I covered the rest of your comments about being cynical, trust, and verification above. As for the idea of paradise, I think the solution lies in changing the incentives. Trusting that someone won’t act against their own self interest is not very difficult. Trusting someone to “do the right thing” when the “wrong” thing is clearly more advantageous to them, well that’s a little more difficult. If things were set up in a manner so it wasn’t “us vs. them”, but rather in a manner where working together would produce better results for everyone than working separate (or against one another), then the only real problems are natural disasters, and people who do irrational things, which is pretty rare, especially in an environment which cultivates cooperation. Bruce touched on some of these concepts in “Liars and Outliers” and I think he was on the right track. As usual, more investigation needs to take place on the topic. If anyone would like to continue this conversation (changing the incentives), I’d be happy to do so in a more appropriate forum (you choose the place).

@BoppingAround
You are right. It is understandable. But does it get us anywhere?

UPDATE!
So I was just skimming through the document (because I still haven’t read the whole thing) looking for some technical specifications to address the claim that the spec isn’t open. Well, if you take a look at page 90 of the PDF, you’ll find a diagram of the components. Everything looks like what I’d expect there after reading the executive summary EXCEPT the link to the “Vehicle’s internal communications network” which is defined as “Existing network that interconnects components.” The sounds like it’s tapping into the CAN Bus. Reading the previous page for some context:

“NHTSA also foresees the potential for V2V safety systems to be integrated into an
existing electronic control unit(s) during large-scale production of vehicles equipped with these systems. Figure V-1 illustrates the vehicle-based components needed for an integrated V2V system that uses integrated vehicle devices. (A V2V system with ASDs would only differ in its lack of connection to the vehicle’s internal communications network.)”

So it looks a little bit like a bait and switch, and seems to contradict what was said in the executive summary. So here’s the evidence of scope creep that all the naysayers were either unwilling or unable to read and reference. Without any explanation as to why this integration is strictly necessary, I can’t support that. I suspect the answer is something like: “because it’d be easy and there’s a bunch of data there.” So if V2V comes up in the future, I would encourage you to cite the fact that there are some plans to tap into the ECU, which could allow problems (or features) with the V2V system to cause cars to break.

The moral of the story remains the same. Read the documents before complaining about them, and cite some facts in your complaints. Skim through this document and find more examples of risky decisions so they can all be raised concurrently (as I should have done). They’ll carry a lot more weight that way, especially with people who don’t already agree with your conclusion before you start. Also, giving them a path for getting what they want (vehicles to be safer) will be much more effective at getting what you want (vehicles to be secure and concerned with privacy). So saying things like:

Well if they’d remove the connection to the ECU, and other components, come up with specific protocols, compatibility tests, a reference implementation to help ensure that all manufacturers’ devices will look identical, and work out how updates are done, then yeah, I might support a V2V communication system.