Elections: Authentication and Authorization

I jumped into a tweet discussion by @s7ephen on using a PKI-esque way of strengthening the election process.

@s7ephen mentions this in the "thread":

@cykyc hrm yea, I guess I am more thinking it solves a small part of "authentication" but mostly overtrust of polling locations and machines

I have been an elections judge (currently a Chair Judge) for the City of Minneapolis since 2004. Minneapolis breaks down polling areas into wards (high level) and precincts (low levels). The magic happens at the precinct.

The first task is to authorize the voter. That is, is the voter in the right precinct to vote? It is against the law in MN to vote in the wrong precinct, so this is a good thing :-) The authorization process usually starts out by seeing if the voter knows if she is in the right location. If the voter thinks so, a roster book is consulted. The election judge then asks the voter her name and address. If there is a match, that voter is authorized to vote in that precinct. If not, see Same Day Registration process (not documented here :-)

The voter then signs the roster, which attests an oath, that the voter is not up to any shenanigans and such.

Note: the voter did not authenticate herself at any time.

Deterrents, trust, and possible knowledge by election judges are the mitigating controls in lieu of authentication for MN.

So, sadly, we don't authenticate in the first place, unless the name is not on the roster. For my precinct, that means that 90% of the individuals would not be served by having a strong auth solution in place, such as PKI.

Changing Infosec Problems

I saw falconsview 's blog update today on changing the problem. It's a good read. I would have posted my comments to it in his blog, but it required authentication and it's easier for me to post my reply here than manage another credential elsewhere :-)

I concur with his thoughts on transforming cloud security into a different problem, such as encryption:

Here's what I don't understand: why are we not talking at length about data encryption? Do you want to eliminate or transform a key set of concerns about putting data out in "the cloud" (whatever the heck that is)? Encrypt the data. Encrypt it as close to the source as possible, and only decrypt it temporarily at the point closest to the instance that requires the clear data for use. Never have cleartext data in storage, ever, ever, ever.

While encryption has its own issues, it moves the problem from a discretionary access control issue (i.e. the code controls who accesses what) to a more mandatory access control issue (i.e. only those with secret knowledge can access the data). This isn't foolproof by any means, since securing private secrets by humans sucks. At Hursk, we thought about this during the design of a password cracking service. PGP encrypt the output of the file using an escrow key and also the user's key. Even if the user had an XSS problem in their browser, the attacker would still have to get the passphrase for either the escrow key, the passphrase for the user's private key, or system access to the service running john or whatever on the cleartext password file.

But, utilizing encryption this way still has basically a PKI-esque problem to deal with. So, yeah, the problem is transformed, but in no means have it been solved.

Maybe all of these problems are NP-hard. We're finding out that yeah, we can transform them to a different problem, but in the end, all the problems we transform them into really are difficult to solve :-)

But, please, don't do encryption in the browser.