July 2010 Archives


July 22, 2010

As the Sam Adams commercials used to tell us, the only ingredients permitted under the old German reinheitsgebot (beer purity law) are water, barley, and hops. (Note that this doesn't include yeast, which is a pretty key element, but the mechanics of beer production weren't clear in the 15th century.) Hops serves a number of purposes.

First (and as I remember from the books I read when I used to brew beer, the original purpose), it serves as an antiseptic. To see why, you need to understand how beer works. You start with a mixture of water and malted barley, which has a huge amount of sugars and is thus a really fertile growth medium. You boil the mixture, then introduce yeast into the mixture and it ferments, converting the sugars into alcohols. Like any fermentation process brewing, is a race between growth of the microorganims you want (yeast) and microorganisms you don't want (bacteria). You can't completely eliminate bacteria from your culture, but excessive bacterial growth causes a sour taste and you need to discard the beer (brewers say the beer is infected) . Hops (allegedly) acts to suppress bacterial growth, thus favoring growth by yeast and reducing the chance of infection.

Hops also serves two other purposes: bittering and aroma. Even when the fermentation process is finished, there are still residual sugars in the beer which give it an unpleasant sweet flavor. The bitter taste of hops balances out that flavor. Bittering hops are added during the boiling phase, which removes most of the aromatics. Finally, if you add hops at the very end of the process, either during the end of the boiling phase or even once the mixture has cooled and is fermenting (this is called dry hopping), the floral aroma of the hops transfers to the beer. (see here for a long description of the hopping process.)

American craft beers tend to be relatively heavy on both kinds of hops. British beers, by contrast, tend to be very lightly hopped, and many Americans, myself amongst them, find them to be distastefully sweet. Until fairly recently, "India Pale Ales" such as Sierra Nevada Pale Ale (which is reportedly dry hopped) or Full Sail Pale Ale1 were about the most heavily hopped American beers you would typically see in terms of aroma, though some of the American bitters were more bitter. [Note that there is an absolute chemical scale for bitterness, but in my experience it doesn't track that well with perceived bitterness.] About a year ago, though, someone bought me a Racer 5 India Pale Ale, which blew me away by how hoppy it was; Racer 5 is fairly bitter but has a huge hops aroma.

I've bought Racer 5 a few times since, but it's not really that mainstream a brand. Lately, though, two of the major craft breweries (Sierra Nevada and New Belgium, the people behind Fat Tire), have started rolling out their own super hoppy beers: Sierra Nevada Torpedo Ale and New Belgium Ranger India Pale Ale. Both are excellent: to my taste Torpedo Ale tastes more bitter whereas Ranger IPA has a much stronger hop aroma. My preference is for the heavier hop aromas, so I prefer Ranger IPA and Racer 5, but I'm just glad to see that the majors are starting to cater to hopheads like myself.

Afterword: I'm a huge fan of St. Stans Amber, but I thought St. Stans had gone under. I just recently noticed that they're still in business, but you can't seem to buy it in stores. Any reader who knows where you can pick it up in the Palo Alto area, please let me know.

1.Full Sail also makes an IPA, but for some reason I've always really noticed the hops aroma from the Pale Ale more than the IPA.


July 16, 2010

On my way through Oslo Airport (OSL) on Sunday I found an interesting design flaw. The gate area I was supposed to depart from is shown schematically below.

The way things work here is that you disembark in some semi-controlled international zone but then some flights require you to go through passport control again. (I'm not actually sure why; an FA told me that it had something to do with Schengen versus non-Schengen but since I came in from Germany, which is in the Schengen area, it's not clear to me if one would be going through passport control to enter or leave some jurisdiction.) However, what's unusual is that the gate area is used for both European and International departures. If you're on an International flight, you enter through Door A; on a European flight you enter through Door B.

When I showed up, however, I didn't have a boarding pass, and there wasn't any obvious place to get one. I asked one of the not-so-helpful floating information people who told me to ask passport control. When I asked the woman staffing passport control she told me that I didn't go through passport control and I should just wait for the gate area to open. Now, I'd already tried and found it locked, but when I went back, another passenger was opening the door so I just walked in through door A. I asked the gate agent where I should go and she sent me over through some tunnel to gate 49, where I picked up a boarding pass and had a seat. When I looked over, though, the other set of doors (door B) were also open, allowing me—if I chose—to totally bypass passport control. At some point an FA came over and closed door B but they were simultaneously open for maybe 20 minutes.

Obviously, this isn't that great a design: The doors aren't interlocked in any way so it's easy to make a mistake and have them both open at once. People are moving back and forth between the two gate areas all the time, so it's really hard to keep control of the situation; even if you were able to guarantee that the doors were never open at once you still wouldn't be able to prevent unauthorized transit between the zones without also making sure everyone left the area in between having each door open.


July 10, 2010

As with last year, EVT/WOTE will be having a Rump Session:
For the second year in a row, this year's EVT/WOTE includes a Rump Session, scheduled at the all-new and more convenient time of 5:00 p.m. on Monday, August 9.
This session will no doubt include results more important--and simultaneously more hilarious--than any to be presented at the main workshop. If we're lucky, Mark Lindeman will sing again. However, this can only happen if you (yes, this means you!) submit.

Acceptable topics include:

Work in progress
Work that you haven't had time to start
Work that you will do if you ever get some free time
Work that should not be started at all
Each presenter will have between 4 and 7 minutes, depending on the number of submissions and an as-yet-undetermined and most likely arbitrary evaluation formula.

Submissions should be directed to the Rump Session Chair, Eric Rescorla, at evtwote10rump@usenix.org. Please provide a talk title, the presenter's name and affiliation, and an estimate of how much time you would like.
Main CFP here.

July 8, 2010

As I mentioned earlier, the DC BOEE Internet ballot return project is just the latest in a series of pilots and attempted Internet voting pilots. Superficially, this sounds like a good idea: there's debate about whether Internet voting is a good idea, so let's only natural that we'd try it out and see how it works.

Unfortunately, this isn't likely to tell us anything very useful; while we have extremely strong theoretical reasons for believing that Internet voting is insecure, those reasons don't indicate that every single election is going to fail. [technical note: by Internet voting, I mean here online ballot return without the use of end-to-end cryptographic voting techniques. Those at least potentially would allow for secure elections, but that's not on the table in this case.] People routinely do unsafe stuff (skydiving, not wearing their seatbelt, texting while driving, etc.) and get away with them, but that doesn't mean that they weren't unsafe, it just means you got lucky. So, when we run a single trial and it doesn't end in disaster, that doesn't really tell us much. The situation is even more complicated here because the failure mode we're most concerned about isn't random but rather adversarial. By their nature pilots have relatively low stakes (a small number of voters, not particularly important election), which is what makes them seem "safe", but this also makes them much less attractive attack targets, so we shouldn't be surprised if they're not attacked, no matter how vulnerable they are.

This isn't to say that we won't learn anything: This sort of pilot is just fine for testing whether the software is functioning correctly in the ordinary non-security sense. That kind of testing is of course important for any widely deployed service, but we know in principle we can build a site like the one DC BOEE is apparently building, it's just a matter of routine software engineering. Indeed, that's part of what makes Internet voting so superficially attractive to people without a security background; it just looks like a less fancy version of online banking and we know we know how to do that (actually, we don't know how to do that securely against a dedicated attacker, but most people don't know that.)

No matter what the outcome, then, this kind of pilot doesn't tell us anything that useful about Internet voting. If it's attacked in some serious way, well, we already knew that was possible. If it's not attacked, that doesn't tell us it was secure, just that nobody bothered to attack it. If it fails for some non-security reason, that just means there were some development mistakes and the system wasn't tested enough before being rolled out. The only thing we're likely to learn, if everything goes smoothly, is that we this particular software functions correctly in some real-world non-adversarial conditions (which is about the most you can ever say for a piece of real-world software), but we already knew it was possible to build this kind of service and of course that doesn't tell us anything useful about Internet voting in general, since someone else's implementation might be disastrously bad.

At this point I've hopefully convinced you that this sort of pilot isn't very useful. However, I think the situation is worse than that. The problem is that while we don't learn very much from it we appear to. If, as is reasonably likely, all goes smoothly, then many people will take this as evidence that Internet voting is in fact safe. I'm speculating here, but since we used to and to some extent still do hear exactly this about paperless DRE machines, I think I'm on relatively safe ground. In other words, rather than just being useless, this kind of pilot has the potential to leave society as a whole less well informed than before the pilot, since it provides a form of unwarranted confidence in these techniques.

Since I'm using the DC pilot as a jumping off point for this discussion, I should mention that the OSDV guys appear to think of this not as an opportunity to test the Internet part of the system, but rather to field test their optical scan system, with the Internet just being used as an alternative way of getting the ballots into the system (see Greg Miller's post). As I said above, that's a kind of system functionality testing that is valuable, but that doesn't necessarily mean that it's best to do that testing in the context of an otherwise misleading pilot project.


July 2, 2010

Greg Miller corrected an error in my previous post on the DC Internet voting pilot:
One clarification, Eric, to an otherwise fair assessment pending more details except one small thing: the qualified overseas military voters who choose to participate in this assessment Pilot can still choose to return their ballots the usual way: paper by surface mails. Your last point suggested no paper return. Incorrect.

I followed up with John Sebes from OSDV and got some clarification on the situation. Voters have three ballot return options.

  • Print the ballot out, fill it in on paper, then scan and return via the Internet.
  • Fill out the ballot on your computer and return via the Internet.
  • Print the ballot out, fill it in, and then mail it back.

So, you can return the ballot either via the Internet or via mail but not both.

I've already written about the first two cases, but not the third; hence this post. Clearly, paper mail return is more secure than Internet return, since we don't have to worry about tampering of the user's completed ballot either by his computer or by the board of election server. However, we still have to worry about tampering with the blank ballot, which can happen in either location.

The simplest attack is just to swap the descriptions for candidates. As I understand the situation, optical scanners only look at which opscan targets is filled in, but ignore marks outside of those regions. So, if I swap the names Jefferson and Burr, then when the voter thinks he's voting for Jefferson this turns into a vote for Burr. Since the voter has no real way of knowing what order candidates appear on the ballot it's unlikely the voter would detect this attack. The attack is trivially detectable at election central by examining the ballots (and possibly mechnically), provided you know the order of candidates on the ballot. (I don't know if any jurisdictions send out multiple ballots with rotated names, but if so, this detection becomes an accounting problem.)

Not only is the simple attack detectable, it's presumably recoverable: since the voter doesn't know what the ballot order is supposed to be, they're voting on the basis of the names on the ballot, so voter intent is clear and you can just process the ballots based on the names. OCR would probably work here, but in the worst case you could just process the ballots manually. However, we can imagine situations in which an attacker could damage the ballot in ways that wouldn't be plausibly recoverable. This is easiest with propositions: remember that voters don't know the exact wording of the propositions and may not remember the proposition numbers. So if, for instance you not only switch the targets but also swap proposition numbers or reword the propositions, then voter intent becomes a lot less clear. This is of course harder with candidates rather than propositions, but you could, for instance, swap political parties. It's important to remember that all an attacker has to do to affect the election is to preferentially remove the votes of voters who are likely to vote in a given way. Changing them is better, but just invalidating them is still powerful.

So while electronic ballot distribution is more secure than electronic ballot return, there still seem to be a number of potential attacks that would be more difficult to mount en masse with conventional paper-based ballot delivery.


July 1, 2010

Last week, the DC Board of Elections and Ethics and the Open Source Digital Voting foundation announced that they were going to do a pilot Internet Voting project for overseas and military voters [*]. (In the US, this sort of voting often gets called UOCAVA, after the Uniformed and Overseas Citizens Absentee Voting Act, which covers this case). UOCAVA voters are often in remote locations with poor mail access, so traditional Vote By Mail doesn't work very well, making it an apparently attractive use case for technological fixes. That's why there have been (at least) two previous efforts to apply Internet voting technology to UOCAVA voters: SERVE and Operation Bravo. That said, there have also been significant technical concerns about this kind of technology (SERVE report, more positive report on Operation Bravo).

Details about the DC pilot are pretty thin on the ground, but I've managed to get an overview of what's public from John Sebes from OSDV. The basic idea is like this:

  • DC BOEE operates a Web site where you can download blank ballots in PDF form.
  • You either fill in the ballot with local PDF tools or print it, fill out, and scan.
  • You upload the filled-in ballot to the DC BOEE site.
  • The filled-in ballots are printed out and fed into an optical scanner just like vote-by-mail ballots.
  • There is no offline return of paper ballots.
Now, obviously you'd want to do HTTPS (HTTP over TLS) for this, but there are still a large number of potential security vulnerabilities here. The rest of this discussion is based on the assumption that the system is as constructed as above.

Attacks on the Server
The attacks that typically come to mind first are attacks on the ballot distribution and acceptance site. In this design, that site is open to the Internet and by definition pretty much anyne can talk to it, so that leaves it open to a variety of attacks. The two main attacks we need to be concerned about are compromise of the site and denial of service attacks.

In the design I just described, an attacker who manages to compromise the site can effectively replace any ballot with a ballot of his choosing. Within the limits of having the number of ballots roughly match the number of registered voters, they can also remove and and insert ballots, etc. In addition, they can track how everyone has voted. In effect, they have complete control of the election. Needless to say, this is bad.

Obviously, you can imagine hardening the site in some number of ways (firewalls, IDS, aggressive logging to offline storage, audits, etc.), but that just reduces the risk rather than eliminating it completely. Moreover, this doesn't do anything about insider attack: the election officials have complete control over this machine and we don't have any good way to verify what they have done with it (this is basically an intractable problem). This attack can be mounted by a single person, so this sort of system is significantly more vulnerable to a single point attack either by an insider or an outsider than is a traditional paper-based absentee system.

Another issue we need to be concerned about is Denial of Service attacks on the Web server. An attack like this has the potential to disenfranchise large numbers of voters. And since the demographics of UOCAVA voters differ from those of other voters, a DoS attack has the potential for differential disenfranchisement.

Software Attacks on the End-User Client
Because voters are voting on their own computers, there is of course a risk from compromise of those machines. The average user's computer isn't very well maintained and though estimates for the fraction of machines which are malware infected vary, it's clear that the numbers are large. It wouldn't be particularly hard to develop a piece of malware whose payload changed people's votes. There are several potential attack vectors here:

  • Modify the ballots on download (before the user fills them out)
  • Do a "presentation attack" on the ballot marking mode of the PDF viewer, where the voter attempts to vote for Hamilton but the viewer records Burr (this doesn't work on hand-marked ballots).
  • Modify the scanned ballots before submission.
  • Send a copy of the ballots to some third party.
  • Selectively create failures for voters who are voting the "wrong way".

In essence, every attack people have proposed on DREs is suddenly an attack on this system as well. Some of these attacks may be detectable but in general one can't recover from them. And the available evidence suggests that users are pretty oblivious to even fairly blatant attacks. [*].

Attacks on the End-User
Finally, there are attacks which don't require machine compromise. Voters connect to the election site via the Web, so a network attacker who intercepts that connection can steal ballots, modify ballots, etc. Of course, we would expect the connection to be secure, but at least some unsophisticated users are likely to override whatever warnings the browsers pop up; the available data on user interaction is that people do this quite often [*].

I should note that like any vote from home system, there is also a significant risk of compromise of voter privacy, since an attacker can look over your shoulder as you vote.

Bottom Line
As far as I can tell, a system of this type offers significantly worse security properties than in-person voting (whether opscan or DRE), since it has all the security flaws of both plus a much larger attack surface area. [Note that the intermediate opscan step offers only marginal security benefit because it's based on electronic records which are untrustworthy.] It also offers inferior security properties to traditional vote by mail. The primary benefit is reducing voter latency, but clearly that comes at substantial risk.