Yesterday I posted some thoughts about Purdue University’s decision to destroy a video recording of my keynote address at its Dawn or Doom colloquium. The organizers had gone dark, and a promised public link was not forthcoming. After a couple of weeks of hoping to resolve the matter quietly, I did some digging and decided […]
Building a better CA infrastructure
March 30, 2011 by
As several Tor project authors, Ben Adida and many others have written, our certificate authority infrastructure has the flaw that any one CA, anywhere on the planet, can issue a certificate for any web site, anywhere else on the planet. This was tolerable when the only game in town was VeriSign, but now that’s just untenable. So what solutions are available?
First, some non-solutions: Extended validation certs do nothing useful. Will users be properly trained to look for the extra changes in browser behavior as to scream when they’re absent via a normal cert? Fat chance. Similarly, certificate revocation lists buy you nothing if you can’t actually download them (a notable issue if you’re stuck behind the firewall of somebody who wants to attack you).
A straightforward idea is to track the certs you see over time and generate a prominent warning if you see something anomalous. This is available as a fully-functioning Firefox extension, Certificate Patrol. This should be built into every browser.
In addition to your first-hand personal observations, why not leverage other resources on the network to make their own observations? For example, while Google is crawling the web, it can easily save SSL/TLS certificates when it sees them, and browsers could use a real-time API much like Google SafeBrowsing. A research group at CMU has already built something like this, which they call a network notary. In essence, you can have multiple network services, running from different vantage points in the network, all telling you whether the cryptographic credentials you got match what others are seeing. Of course, if you’re stuck behind an attacker’s firewall, the attacker will similarly filter out all these sites.
UPDATE: Google is now doing almost exactly what I suggested.
There are a variety of other proposals out there, notably trying to leverage DNSSEC to enhance or supplant the need for SSL/TLS certificates. Since DNSSEC provides more control over your DNS records, it also provides more control over who can issue SSL/TLS certificates for your web site. If and when DNSSEC becomes universally supported, this would be a bit harder for attacker firewalls to filter without breaking everything, so I certainly hope this takes off.
Let’s say that future browsers properly use all of these tricks and can unquestionably determine for you, with perfect accuracy, when you’re getting a bogus connection. Your browser will display an impressive error dialog and refuses to load the web site. Is that sufficient? This will certainly break all the hotel WiFi systems that want to redirect you to an internal site where they can charge you to access the network. (Arguably, this sort of functionality belongs elsewhere in the software stack, such as through IEEE 802.21, notably used to connect AT&T iPhones to the WiFi service at Starbucks.) Beyond that, though, should the browser just steadfastly refuse to allow the connection? I’ve been to at least one organization whose internal WiFi network insists that it proxy all of your https sessions and, in fact, issues fabricated certificates that you’re expected to configure your browser to trust. We need to support that sort of thing when it’s required, but again, it would perhaps best be supported by some kind of side-channel protocol extension, not by doing a deliberate MITM attack on the crypto protocol.
Corner cases aside, what if you’re truly in a hostile environment and your browser has genuinely detected a network adversary? Should the browser refuse the connection, or should there be some other option? And if so, what would that be? Should the browser perhaps allow the connection (with much gnashing of teeth and throbbing red borders on the window)? Should previous cookies and saved state be hidden away? Should web sites like Gmail and Facebook allow users to have two separate passwords, one for “genuine” login and a separate one for “Yes, I’m in a hostile location, but I need to send and receive email in a limited but still useful fashion?”
[Editor’s note: you may also be interested in the many prior posts on this topic by Freedom to Tinker contributors: 1, 2, 3, 4, 5, 6, 7, 8 — as well as the “Emerging Threats to Online Trust: The Role of Public Policy and Browser Certificates” event that CITP hosted in DC last year with policymakers, industry, and activists.]
Breathalyzer Source Code Secrecy Endangers Minnesota Drunk Driving Convictions
May 11, 2009 by
The Minnesota Supreme Court ruled recently that defendants accused of drunk driving in the state are entitled to have their experts inspect the source code for the software in the Intoxilyzer breath-testing machines used by police to gauge the defendants’ blood alcohol levels. The defendants argued, successfully, that they were entitled to examine and challenge the evidence against them, including the design and functioning of devices used to generate that evidence.
The ruling puts many of the state’s drunk driving prosecutions on thin ice, because CMI, the Intoxilyzer’s maker, is withholding the source code and the state apparently has no way to force CMI to provide the code.
Eric Rescorla argues, reasonably, that breath testers have many potential failure modes unrelated to software, and that source code analysis can be labor-intensive and might not turn up any clear problems. Both arguments are valid, as far as they go.
I’m not a lawyer, so I won’t try to guess whether the court’s ruling was correct as a matter of law. But the ruling does seem right as a matter of policy. If we are troubled by criminal convictions relying on secret evidence, then we should also be troubled by convictions relying on evidence generated by a secret process. To the extent that the Intoxilyzer functions as a secret process, the state should not be relying on it in criminal prosecutions.
(Though I haven’t thought carefully about the question, I might potentially draw a different policy conclusion in a civil case, where the standard of proof is preponderance of evidence, rather than guilt beyond a reasonable doubt.)
The problem is illustrated nicely by a contradiction in the arguments that CMI and the state are making. On the one hand, they argue that the machine’s source code contains valuable trade secrets — I’ll call them the “secret sauce” — and that CMI’s business would be substantially harmed if its competitors learned about the secret sauce. On the other hand, they argue that there is no need to examine the source code because it operates straightforwardly, just reading values from some sensors and doing simple calculations to derive a blood alcohol estimate.
It’s hard to see how both arguments can be correct. If the software contains secret sauce, then by definition it has aspects that are neither obvious nor straightforward, and those aspects are important for the software’s operation. In other words, the secret sauce — whatever it is — must relevant to the defendants’ claims.
As in electronic voting, where we have seen similar secrecy arguments, one can’t help suspecting that the real “secret” is that the software quality is not what it should be. A previous study of source code from New Jersey breath testers did appear to find some embarrassing errors.
Let’s hope that breath tester companies can do better than e-voting companies. A rigorous, independent evaluation of the breath tester source code would either determine that the code is sound, or it would undercover problems that could then be fixed, to restore confidence in the machines. Either way, the police in Minnesota would end up with a reliable tool for giving drunk drivers the punishment they deserve.
On the future of voting technologies: simplicity vs. sophistication
December 3, 2008 by
Yesterday, I testified before a hearing of Colorado’s Election Reform Commission. I made a small plug, at the end of my testimony, for a future generation of electronic voting machines that would use crypto machinery for end-to-end / software independent verification. Normally, the politicos tend to ignore this and focus on the immediately actionable stuff (e.g., current-generation DREs are unacceptably insecure; optical-scan is the best thing presently on the market). Not this time. I got a bunch of questions asking me to explain how a crypto voting system can be verifiable, how you can prove that the machine is behaving properly, and so forth. Pretty amazing. What I realized, however, is that it’s really hard to explain crypto machinery to non-CS people. I did my best, but it was clear from conversations afterward that a few minutes of Q&A did little to give them any confidence that crypto voting machinery really works.
Another of the speakers, Neil McBurnett, was talking about doing variable sampling-rate audits (as a function of how close the tally is). Afterward, he lamented to me, privately, how hard it is to explain basic concepts like what it means for something to be “statistically significant.”
There’s a clear common theme here. How do we explain to the public the basic scientific theories that underly the problems that voting systems face? My written testimony (reused from an earlier hearing in Texas) includes links to papers, and some people will follow up. Others won’t. My big question is whether we have a research challenge to invent progressively simpler systems that still have the right security properties, or whether we have an education challenge to explain that a certain amount of complexity is worthwhile for the good properties that can be achieved. (Uglier question: is it a desirable goal to weaken the security properties in return for greater simplicity? What security properties would you sacrifice?)
Certainly, with our own VoteBox system, which uses a variation on Benaloh‘s voter-initiated ballot challenge mechanism, one of the big open questions is whether real voters, who just want to cast their votes and don’t care about the security mechanisms, will be tripped up by the extra question at the end that’s fundamental to the mechanism. We’re going to need to run human subject tests against these aspects of the machine design, and if they fail in practice, it’s going to be a trip back to the drawing board.
[Sidebar: I’m co-teaching a class on elections with Bob Stein (a political scientist) and Mike Byrne (a psychologist). The students are a mix of Rice undergrads, most of whom aren’t computer scientists. I experimentally built a lecture that began by teaching just enough number theory to explain how El Gamal cryptography works and how it allows for homomorphic vote tallying. Then I described how VoteBox uses this mechanism, and wrapped up with an explanation of how to do Benaloh-style challenges. I left out a lot of details, like how you generate large prime numbers, or how you construct NIZK proofs, but I seemed to have the class along with me for the lecture. If I can sell the idea of end-to-end cryptographic mechanisms to undergraduate non-science students, then there may yet be some hope.]
Counting Electronic Votes in Secret
October 10, 2008 by
Things are not looking good for open government when it comes to observing poll workers on Election Night. Our state election laws, written for the old lever machines, now apply to Sequoia electronic voting machines. Andrew Appel and I have been asking a straightforward question: Can ordinary members of the public watch the procedures used by poll workers to count the votes?
I submitted a formal request to the Board of Elections of Mercer County (where Princeton University is located), seeking permission to watch the poll workers when they close the polls (on Sequoia AVC Advantage voting computers) and announce the results. They said no!
The Election Board said this election is “too important” to permit extra people in the polling place.
They even went so far as to suggest that my written application was fraudulent. I applied on behalf of five people: two Princeton University students, two professors, and myself. In an abundance of caution, I requested authorization in the form of “challenger badges” which the Board of Elections can issue at its discretion. By phone, I explained our interest in merely watching the poll workers.
Of course we understand that they might not want extra people getting in the way on Election Night — that’s why we took measures to get special authorization. To ensure that we could be lawfully present, we asked for challenger badges as non-partisan proponents and opponents of two Public Questions on the ballot, as permitted by NJSA 19:7-2. My request was entirely in compliance with state law, as all the prospective challengers are registered to vote in Mercer County.
In spite of this, the Board expressed reluctance, based on the identities of the prospective challengers. In particular, they cited Andrew’s status as an expert on Sequoia voting machines as a “concern,” and provided assurances that Sequoia has fixed all the problems he identified in past elections.
Other counties in New Jersey permit members of the public to watch the poll workers “read” the election results. Combined with Judge Feinberg’s decision to suppress Andrew’s report on the security of the Sequoia machines, Mercer County conveys the unfortunate impression it does not welcome scrutiny of its electronic voting process.
