Month: September 2008

Brazilian E-Voting

Posted by – 25/09/2008

DISCLAIMER: Paranoid rant ahead. You’ve been warned.

Every two years, around this time of the year, I feel concerned: it’s voting time in Brazil. For quite some time now, Brazil has had electronic voting, but that doesn’t make me more confortable with it. Yes, having the results within the same day is an enormous advantage, but I am not sure about the security of the whole process. You can call me paranoid (and surely I am a bit), but there are some things that give me the creeps about it.

For a start, let’s look at the operational process. The voting machines are certified and sealed by Electoral Justice officers the week before the voting. They are opened in the electoral section by those officers in the presence of common citizens. Those citizens are called to work in the Electoral process usually for four or five elections in a row, being replaced after that by “newcomers”.

The voting machines are not connected to any network. During the day, voters come with the voting document (voting is mandatory in Brazil), one of those citizens enable the voting machine by typing the document unique number in it, the voter give his vote and go home. Then the voting machine is unable to receive votes if not enabled by entering another document number, and it goes on and on the whole day long (pretty boring work…).

At the end of the day, the “president of the section” (usually the most experienced of those citizens) close the voting machine, prints a “tally sheet”, hand a colored 3½-inch floppy disk to the Electoral Justice officer with the votes and go home. Other officers will pick up the voting machines later on. The first officer then goes to the voting processing central of the Electoral Justice and within hours we will know the result of the election.

As you can see, there are lots of points of failure in the whole process! All this “sealing” of voting machines are just a matter of trust. First point: there’s no way we can know for sure if the machine does what it’s suppose to do. Even if officers say that they “randomly” choose machines to be tested, there’s no way to know how random is that. There’s a report [pt-BR] made by a prestigious university (English summary here), stating that 1/3 of the voting machines in a particular studied state had corrupted log-files (among other important security problems!). This study also showed differences in the countings (sometimes as large as 20-thousand votes!)… Hey! This is supposed to be a deterministic system: if nothing in the conditions changed, counts should always match!

Until recently, closed-source software were used in the voting machines, but that has changed recently. I doubt that it makes any difference, since we’ll never really know what is actually running in the machine. Surely, Electoral Justice officers know (or should know), so we’d have to trust them… So second point: we don’t know how the voting is processed within the machine.

(Also, we don’t know for sure the machine doesn’t have a network connection. It may have a wireless connection we don’t know about and can be passing all the votes to someone else, or even receiving instructions… But since that can be spotted with a scanner, I’ll trust other paranoids have already done that.)

Surely the machine must be enabled before every vote with the voters document number. If it were not, how could we know that no one voted twice, or that a non-voter have voted? But we don’t know how the machine records that! Third point: we cannot know if the voting machine database doesn’t link the voter to the vote. That is a nasty one… it opens up the possibility of “voting by intimidation”.

Also, the “tally sheet” that is printed at the end of the day only brings the total of votes, the total of absent-voters, and the votes each candidate (or party) have received. So, on to the fourth point: there’s no way of knowing for sure that your vote was counted right (or was counted at all!). At least a copy of this tally sheet is glued at the entrance of the voting section, so an independent audit only on the numbers is do-able (although hard to do!).

What happens to the colored disk between the voting section and the voting processing central is not known. It goes with the officer and what he does with it is just a matter of trust. Now for the most insteresting point: the security is based on the color of the disk!. The Electoral Justice checks if the officer handed the right colored disk and puts the data in the system. Surely (?) they might have some way to check data integrity other than that… On the same issue, maybe even worse: even if the disk is not tampered, but just read (or copied) by the officer before being handed, and if the database links the voter to the vote, this information is valuable, and may be sold.

Finally, since we don’t know (and have no way to know for sure) what the machine does, we don’t know if the machine keeps a copy of the voting database in it. So when it is taken back by other officers, we cannot know whether the same thing that may happen to the disk also could happen with the machine.

I am missing a lot of things about the whole Brazilian E-Voting process, and also I surely have missed other points of failure. I heard of fraud in the past, with paper ballots, and those were pretty nasty frauds. But this whole tale of “impossible fraud” in e-voting is nothing but a tale (as fraud is more than possible!). I think we have to begin investigating other systems, surely with cryptography involved. A system like Debian’s, far from perfect (we all have to trust secretary’s word on the secrecy of the voting system key), is much better, for instance. I understand that it’s not simple enough for non-geeks, but there might be a way!

It doesn’t need to be a whole new system! I would be happy if, as an example, the tally sheet printed a hash of my vote that I could verify later on… or if the security of the disk is not just color-based… or if the tally sheets had a way of being validated and be available on-line for auditing (and not just glued at the entrance of every voting section). Look! I am not distrusting any officer a priori… I think the message is auditing should be made easy… then I could trust a version of Linus’s Law adapted to E-Voting: “Given enough eyeballs, all frauds can be discovered”.

Silent Blog and JRuby

Posted by – 24/09/2008

I’ve been silent in this blog last few days, but that has an explanation: I’ve been trying to make JRuby 1.1.4 work with one of my scripts.

The problem is that after having done all the tweaks I can imagine, I still can’t get enough performance with Ruby 1.8.7 (latest etch-backports). Our client will not allow Ruby 1.9 in the server (what is really a pity, for the performance boost I had with Ruby 1.9 is awesome!), but it already have Java6… So the only option I have left is trying JRuby beast.

Since our script deals with system stuff, it uses syslog a lot, and that is where the main problem seems to be. Syslog support is new in JRuby, has had some implementation problems, and sure are not something to rely on right now… so I dropped it from the script, and it run! Twice as fast (not as good as Ruby 1.9, though)!

There are some other problems with this script and JRuby, more important ones being (1) at_exit doesn’t work; and (2) errors are not easy to backtrace (when JRuby fails it seems to mess up with the backtrace stack), but not preventing it to work…

So… with the increased performance of JRuby, and after fixing those minor glitches, I was still left with the syslog problem… Until I investigate some final solution (I think I’ll have to use some Java native syslog library – given such a thing exist), I’ve split the script in “performance-boost needing” and “syslog-needing” parts; the first is using JRuby, and the second, Ruby 1.8.7… They communicate using sockets (I know… ugly… I would like to use DRuby, but I would not introduce another point of failure in an already messy situation) and the overall performance was brought to a satisfactory level.

So far, it’s been interesting to study the issue… Mainly because I haven’t used JRuby since it’s early versions, and it has improved a lot. But also because I read a lot about the future of Ruby (bytecode compilation, YARV and so on), and it made me even happier with my primary-do-it-all programming language.

Now I’ll try to compile java bytecode generated by JRuby into a native binary with GCJ :-D. Let’s see if that is do-able…

Updated 2008-09-24 18:03:00: As you can see in the comments, syslog actually works. I figured this out this morning, but JRuby Subversion already had a patch. Anyway, I submitted another bug I found.

Jogo em flash mais viciante!

Posted by – 22/09/2008

Há uma semana que o pessoal do trabalho tem jogado Bloody Day part1, e tem sido realmente uma febre. Por enquanto o highest score (entre nós) é meu, com 4390 pontos, mas tenho certeza que será batido em breve…

Cuidado… é realmente viciante. Você foi prevenido.

As old as good: One Time Passwords

Posted by – 12/09/2008

People frequently ask me what I am doing typing on my Palm right before logging in one of my remote systems. The answer is quite simple: “generating my next password”. People always seem puzzled by that answer… Maybe I am just too old to have had only telnet sessions available to remote connections (that was the time before SSH took over)… or maybe I am just too paranoid regarding the access to my systems… Anyway, I like One Time Passwords, and here is an article I can refer to when I get asked again 😉

One Time Passwords are just that: passwords that are good for one time use. They never repeat and once used you can throw it away securely. They were quite common when the authentication was done in clear text (so that any man-in-the-middle could steal your passwords), back in the r-tools age (rcp, rsh, rlogin, rexec, etc). After the SSH-related tools took over, providing easy tunneling and remote access, MITM attacks were of much concern, so OTPs became less relevant. What a shame, for they even have a couple of standards for those!

But there’s still room for OTPs… Question: Is it easier to deploy a MITM attack or a keylogger? That’s right… We are always connecting to our remote systems in public terminals (well… at least I am – right now typing from the hospital computer), and a keylogger is so easily installed in one of those terminals, even remotely, that no one would ever get close to deploy a refined MITM attack just to steal someone’s password. One would just install a keylogger! All the security SSH provides would just be gone by then. That’s why I use SSH to connect to my remote machines, but use OTPs to authenticate myself.

It’s so easy to deploy it. In Debian you’ll find packages opie-server and libpam-opie and those are the only things you’ll need on the server side (besides SSH, obviously). OPIE means “One-time Passwords In Everything”, and combined with PAM, one can really use it everywhere.

After installing it, you’ll have to generate the password file for your account:

spectra@home:~$ opiepasswd -c
Adding spectra:
Only use this method from the console; NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase:
Again new secret pass phrase:
ID spectra OTP key is 499 ho6484

The pass phrase will be used to generate the passwords in a step before your login. Please, try not to forget it (specially if you’re following this article and playing with some remote system at the same time). Now you can edit /etc/pam.d/ssh file (or its equivalent in non-Debian systems) to require that kind of authentication. Mine just looks like this:

# /etc/pam.d/ssh
auth       required
auth       required envfile=/etc/default/locale
auth       required

First two lines are unrelated and just load the environment variables. Last line is where the fun is. Please, note two things: (1) I removed references to, which is what would ask for my “real” password, that I want to disable (no login is allowed with that password). And (2), I declared it as required, meaning that failing it will keep one out of the system.

We are not ready yet! SSH will work by now, but will not present you the OTP challenge. Probably you could still login, but you’d have to remember which is the current password (Trust me, you would not!). To get the challenge you’ll need to enable it – in /etc/ssh/sshd_config change the following line:

ChallengeResponseAuthentication yes

That’s it. Now to login to your remote machine, that’s what will usually happen:

spectra@hospital:~$ ssh home
otp-md5 498 ho6484 ext, Response:

Voilà! It asks for password #498. By default, it starts with 500 passwords and goes down from that. Password #498 were asked, so the next will be #497. After that, #498 is not useable anymore, and #496 is not useable yet. You can generate a list of those passwords (let’s say 10), print it and keep it in your pocket. This is the command you’d use for that:

spectra@home:~$ opiekey -n 10 498 ho6484
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Sorry, but you don't seem to be on the console or a secure terminal.
Warning: Continuing could disclose your secret pass phrase to an attacker!
Enter secret pass phrase:

That is not so secure, since you can loose the paper and be doomed… Luckily there are lots of small softwares that does this generation for you. Some you can use from your Palm or from some J2ME-enabled phone (such as N95). Some your can use from another (trusted) computer. Some are even online, written in javascript!

There are at least one other side-benefit of using OPIE as above: You can give away your user password (even root password – OK, probably not a Good ThingTM), that the system would still be secure, since it only allows SSH authentications via OPIE! If the session is started with a username whose opiepasswd was not activated (first step… scroll back to the beginning of the article), SSH will greet you with a bogus challenge… only “opie-activated users” will be allowed to login with the above configuration.

Easy enough, isn’t it? Now, next time you see me typing on my Palm before opening an SSH connection you’ll know what I am doing… 😉

Bem-Vindo LHC

Posted by – 10/09/2008

Eles finalmente ligaram o LHC! A BBC está noticiando que o primeiro “raio” de hadrons completou o circuito às 5:30 BRT (8:30 UTC). Eu, com certeza, espero que eles não terminem por criar um Buraco Negro que cresça indefinidamente com ele 😉 (embora, criar um desses em Brasília não pareça uma má idéia).

Under-the-hood Candidates

Posted by – 09/09/2008

I am still laughing of IdolHands comparison between Obama and McCain. Watching how people can make tech-fun out of absolutely anything is amazing… Maybe I can put a similar comparison of Porto Alegre mayor election in the pt-BR section…

Challenge-oriented intelligence

Posted by – 08/09/2008

I told you I was re-reading Paul Graham’s Hackers and Painters essay in order to update one of my lectures. I feel I like Ruby for I too have the same coding style as Paul’s:

I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.

Ruby sort of frees me of figuring out everything beforehand. Of course, Ruby is not the only language with that in it… It’s just the one I like the most… Anyway… This is not a language-versus-language rant… Rather this is about another article I just read by Carol S. Dweck…

The article focus on teaching kids that challenges can be taken as opportunities to improve. Failure at a challenge, in this sense, has less to do with intelligence than with effort. And I just mentioned Paul’s essay because I think what Carol is really talking about is that “hacking can be taught”… or rather that we should teach kids to be hackers. Here I mean “hacker” in the broad sense of the word, as in Paul’s essay, or in the Jargon File.

7. One who enjoys the intellectual challenge of creatively overcoming or circumventing limitations.

Maybe if knowledge researchers, teachers and psychologists “embrace and extend” what we already understand as hacking, and begin applying it at schools, we can all improve as a society. Who knows… Hacker-society might very well be our future society! 😉

What do you think about it?