SYSSEC: October 2008 Archives

 

October 13, 2008

Senate Bill 381, signed by Governor Schwarzenegger, on October 1st, provides for online voter registration. Here's the statement from SoS Debra Bowen.
"Californians can pay bills and file their taxes online. Being able to register to vote online is the next logical step in making it easier for Californians to participate fully in their democracy," said Secretary of State Debra Bowen, California's chief elections officer. "This measure prevents fraud by limiting online voter registration to people who confirm their identity in a secure manner."

The online registration system will require registrants to provide their birth dates, the last four digits of their Social Security numbers, and the numbers from either a valid California driver's license or identification card. The Secretary of State may require additional information if it's necessary to establish a registrant's identity.

Registrants will be able to complete voter registration online using their digitized signatures that are already on file with the California Department of Motor Vehicles.

Unsurprisingly, there are some security concerns about a system of this type. I would break the major issues down as follows:

  • Authentication of voter registrations.
  • Corruption of the voter registration database via intrusions.
  • Privacy of voter data.

Let's take these in turn.

Authentication of Voter Registration
The first question to ask is whether the authentication here will be acceptably strong. I.e., will I be able to pretend to be you and reregister you to vote in King City, with the effect that when you go to your usual polling place you can't vote? I'm not talking about compromising the registration site, just lying on the form. Currently in order to register to vote in California you need to know your address, SSN or DL # and your birthday, plus you need to sign the form. The online site requires both the last four digits of your SSN and your DL #, plus the other information, but there's no need for you to sign your form. They just take your digitized signature off your drivers license.

Arguably, then, the online scheme is less secure: in the paper-based scheme, the SoS can compare the signature on your form to whatever signature they have on file for you (assuming they have one) and this presumably presents some barrier to forging registrations. That said, though, I suspect they don't do a very good job of verifying signatures on registration forms (actually, I don't know that they do any; credit card companies don't), and anyone who knows your SSN and DL #, probably has a good enough idea of what your signature looks like and they only need to get close enough for casual inspection.

On the other hand, because the online attacker needs both the DL # and the last four digits of the SSN, it's perhaps more difficult to impersonate a valid registration—though not very much so—than the paper-based system where only one of these is required. So, overall, this doesn't seem like a huge security hit from going to an online system.

Corruption of the Voter Registration Database
No matter what mechanism is used for authenticating users, any online system brings the risk that attackers could remotely compromise the registration site and corrupt the database correctly. Compromise of single voter registrations is already possible by simpler mechanisms (see above), but an attacker who had direct access to the database could do significantly more damage, for instance massively corrupting the database. Obviously, this creates a new opportunity for a major DoS on the election, especially if it went undetected before election day.

There are a number of mechanisms that could in principle be used to mitigate this kind of attack. The simplest is to have an airgap between the website and the database. For instance, you could have the server print out registration forms which are entered into the database in the usual way. Obviously, this removes a bunch of the efficiencies of having an online system, so it's not really attractive from that perspective. Alternatively, you could have some sort of frequent backups coupled with rate limiting of the number of changes allowed per day, but these checks themselves depend on the software doing the checks being uncompromised, which is hard to guarantee (though defense in depth is possible).

Compromise of Voter Privacy
If the voter database is directly connected to the registration site, then an attacker who compromised the site could potentially get a complete copy of the database. If the database contains sensitive information (the last four digits of your SSN qualifies here), then this is a potential vector for information disclosure. Again, this could be mitigated by having an airgap between the site and the database. Other potential mechanisms include encrypting the sensitive mechanisms in the database (this seems to be specified in the CalVote specification). [Technical note: you probably have to use public key cryptography here so that the site can encrypt the sensitive information before storing it in the database but even an attacker who has completely compromised the system can't decrypt the data.]

Bottom Line
The mass compromise issue seems to be the difficult issue here, both because it's so serious and because it's so different from the current situation. Superficially, it's a fairly standard computer security problem and it may be possible to mitigate it via the usual mechanisms, but the scale of elections and the time pressure under which they are conducted make it especially challenging.

 

October 5, 2008

Recently there was an extensive discussion going on on the Cryptography mailing list about how to build cheap hardware based random number generators. For those of you who aren't crypto or comsec specialists, the background goes something like this: most cryptographic protocols require a reliable source of numbers which are unpredictable to your adversary 1. For instance, in SSL/TLS the client (your browser) generates a random cryptographic key and sends it to the server encrypted under the server's public key. If the attacker can predict that random key, then he can decrypt the connection, as was famously shown by Wagner and Goldberg. So, having good randomness is important.

As I mentioned previously, standard procedure in comsec applications is to use a cryptographically secure PRNG which is seeded with data which is unpredictable to the attacker. But this still leaves us with the question of how we're going to seed the PRNG. The most common thing to do is to seed it with system events (network packets, drive timings, etc.). In principle, of course, this isn't entirely unpredictable: if you were on the same network as the target machine you could observer packets; if you knew the layout of the drive, you might be able to predict how long things would take, etc. (and older PRNGs that weren't wired into the OS used fewer sources of randomness). In any case, these sources aren't physically random the way that, say, radioactive decay is. There's a nontrivial contingent of the security community which is extremely interested (some would say obsessed) in physical/hardware random sources of randomness. [This goes back at least to von Neumann's famous statement about those who consider arithmetical methods of producing random numbers being in a state of sin.] The thread I'm pointing to above has a variety of suggestions for cheap external hardware randomness sources.

My general intuition is that while this sort of thing doesn't do any harm, it's not really necessary either. The amount of entropy you actually need to have a secure system is surprisingly small: 80-128 bits is enough in most situations, and most systems gather that kind of entropy in the normal course of business. For instance, in a system with a GUI, just collecting the low order (odd/even) bit of each mouse click coordinate gets you to 128 bits in 64 clicks, which isn't much. Even on unattended systems, there's probably enough timing randomness in hard drive behavior to get you to 128 bits relatively randomly. Even in cases where there aren't any unobservable behaviors and the PRNG is basically broken, the effort to reverse engineer the state of the PRNG becomes near prohibitive very quickly, as is the case with the Debian PRNG and DHE vs. RSA [*]. I'm not aware of any evidence that well-designed OS-based PRNGs like /dev/random are vulnerable because of insufficient entropy gathering.

1. Technical note: not as many as you'd think, though. Many protocols use random numbers in contexts where only unique numbers are required. For instance, in SSL/TLS and IKE it's standard practice to use cryptographically random nonces (called "Random" in TLS). However, the security guarantees of the protocol apply as long as the numbers are unique—you could probably just use a counter. The advantage of using long random numbers is that you don't need to store counter state to ensure uniqueness.