It looks like you're having connection troubles. Reconnect now.
01/13/2021 14:26:55
31c3-talk-6213 Latest text of pad 31c3-talk-6213 Saved Jan 13, 2021 |
Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles oder https://rocket.events.ccc.de/channel/subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!
Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles or https://rocket.events.ccc.de/channel/subtitles .
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!
======================================================================
So good morning and thank you, everybody, for showing up at this early hour, so the tabloid title of this talk is The Rise and Fall of Interest Voting in Norway. And I'm going to tell the story about some about the Norwegian trial. Try to do it for the voting rights. So how many of you were at Alex Halderman? Straight talk and Sunday on the voting in Estonia? Quite a few, so, you know, already everything about Internet voting, so there are basically two kinds of voting systems. It's the kind of voting system you use to tell what is the best of Coca-Cola and Pepsi. And it's the kind of voting system you use to decide who would you want to be in government and for the fall for the second kind of voting system. The stakes are a lot higher and this is a fundamental democratic samani. And it's really important that we get it right and we make sure that it stays democratic and secure and fair. And so this talk is going to be in three main parts, I'm going to talk about the Internet voting trial that was held in Norway in 2013, and then I'm going to give the historical background for the trial to try to look at how was it that we did this trial in Norway and what happened afterwards and what what was the story? And then finally, I'm going to talk about my own work auditing the crypto implementation used for the voting system. And so there are really three main points to take away from this, and I think the first point is that even though, in fact, voting is. Scary and something which I think we don't want, uh, the Norwegian trial really tried to do it right. In the sense that they wanted to make it, uh, they wanted to conduct a really open trial and be very honest and upfront about what they were doing. Uh. The second point is that, uh. This kind of event is not only about technology, it's also very much about politics, and you find that even though the hackers are saying, in fact, voting, no, we don't want this. It's a very there are a lot of other forces in play which sh
ape what's actually going on. You might want to ask, why would anyone why would anybody want to do Wynford voting at all? And I think the main arguments, uh, 10 years ago, which was definitely pre Snowden and when we were, I think as a whole, a bit more naive about the threats online was that I can do banking online, I can do my taxes online. Why can't I watch? And so some of the formal goals of the project was to improve accessibility for marginal groups and to make the voting experience better for people who are not voting in their home location, such as students. And at the beginning of the trial, they also wanted to increase turnout, but. Instead, voting in the experiment didn't really seem to have an effect on that. And finally, I think that from a purely technical or scientific point of view, this is kind of an interesting challenge. So. Want to say, we want to learn something about if we try to do this, what what are the actual roadblocks, both technologically and from a Democratic point of view? And so I guess some of you might wonder, who is this tall guy and why why am I here speaking about this? Well, I did my I did it in cryptography quite a few years ago. Uh, I'm working currently the I.T. security consultant at a security company in Oslo, Norway. And this is my sixth time ATCC. Uh, actually, I've been playing with computers since, uh, since forever. I got I got my first Unix account when I was four to play in attack. And I guess I sort of stayed along those lines for quite some time. Uh, my own role as regards to Internet voting in Norway is that I wasn't I've not been a part of the, uh, voting projects, but, uh, I did this crypto audit for them in 2013. And because the project has been so open, everything I'm saying here is based on public information, but some of it is subject to my own interpretation or understanding, based on the fact that I was outside the project itself. So Norway, I guess, uh, not everybody knows a lot about Norway, it's up here
. So northern European country is quite small. Five million people, it's a stable and rich democracy, which has a really tremendous amount of public trust. So so people are trustful, maybe even to a fault of both the neighbors and of the governments. And I think, uh, in this sense, Norway has a lot of preconditions for doing this kind of Internet voting experiments. It's a small country. It's a pretty small trial. It's politically very stable, so if something really went wrong, it wouldn't it would be possible to recover in a stable manner. In fact, there was in 2011, there was a terror attack against the government only a few weeks before the election and before the first Internet voting trial, in fact, and was still able to carry to carry out the election under reasonably ordinary circumstances. And finally, Norway can afford to do it right? So and I think these are really preconditions for a successful experiment. So if anybody is able to do fact voting, it should be us, right? And so the overall concept for Internet voting in Norway, this is not electronic voting machines, it's online voting from your laptop, from your living room. And so. Uh, as a voter, you are able to log on and vote online. As many times as you want. And the Internet voting is only done before Election Day and on Election Day, you can go to a polling place and you can vote physically as well. And the system is integrated in such a way that only the last vote counts, and this is meant as sort of one of the main and tie vote selling anti-corruption techniques in the system. That's even if somebody forces you to vote for whatever, then you can go and you can vote again, either online or at the polling place. Uh, the second the second idea here is that you use a fancy cryptographic protocol on which you try to say something fundamental about to try to get some pretty strong guarantees that the core protocol you are using is actually sound and that's what you want. And the system was designed, at
least in principle, to give advance security, which meant that you were supposed to have no trust. Between between each element in the processing chain of about and you would you would use cryptographic proofs to to link everything together. And similarly, there was quite a bit of separation of duties such that the fact that encryption keys were split in half and given to two different people so that they would both have to collude to to use the key. The final part of the concept is that the voters get some out-of-band feedback about the result of their online votes, which the voter but only the voter can use to verify that their votes. Posted online was was devoted, he intended to to costs. And so and so this sounds pretty reasonable, I guess, but then you get into the technical details and so for for a voting system, you want stronger authentication because you want to know who voted and you want to be able to make sure that. People voting multiple times are much loved correctly, so that's how you count the right votes in the end. So the system needs to be secure. And then at the same time, you want to have anonymous ballots, so you should be able to link the vote over here with the person who cast it on line. And the third requirement is that you want to be able to verify afterwards. The result of the election. And so those those three requirements are actually kind of opposing each other because it means that you need to have some sort of separation between different processing stages in such a way that you can link this together again. And there's really a fourth security requirement, which is not clearly stated here, and that's about verifiability. And what does that really mean? Because in a traditional paper ballot vote, there is a lot of weaknesses, limitations, and there's quite a high cost of running a paper election. But the threat model is pretty well understood and it's got high legitimacy. And you can more or less explain to a five year old that you
are putting ballots in this box here and it's locked. And then people from different parties come and counted together. And so they make sure that there are checks and balances and there are a lot of people involved in in making this happen. And the. Make and realizing that kind of requirement in an electronic tech system using fancy crypto is kind of hard, and that's I think that's really one of the fundamental challenges about electronic voting and Internet voting, is that we need to make it so transparent as we possibly can. And I'm not sure we know how to do that yet. And so there's a fourth security requirements on the list here, which is the ability to detect attacks and one of the main goals of the Internet voting pilot in Norway was that. Even if there is some kind of attack on the system, then at least if it's affecting a lot of votes, there would need to be able to detect it. And we might be able to live with the effects of some kind of small scale abuse in the sense that. Below a certain threshold that might be unavoidable no matter how you implement an election, but. We should be able to detect any kind of large scale fraud attempts and if necessary, just. Or just rerun the election a few weeks later if. If if there's found evidence of some kind of large scale abuse. And so I think already at this point, we realize that if foreign and trade system, we are probably not going to be able to make it hundred percent bulletproof. People are going to have malware, people are going to get get hacked. But at least at some level, it should be possible to detect anything going up. And so there are also quite a few counter arguments against, uh, in red voting in particular, and I guess also electronic voting in general, uh, transparency and verifiability. As we just talked about is, uh. Difficult to solve. The main arguments in the public debate in Norway has been around coercion and the fact that you are voting in an uncontrolled environment rather than in a public
out of public polling place in a close booth. And there's also been a claim in the public debate that Internet voting debases the ceremonial aspect of going to votes. And I don't know if. I don't know. Uh. How widely that applies, but at least, uh. At least for some people, going to the polls is. Is this a Democratic ceremony that. They value quite highly and. Basically, being able to vote from your cell phone is undermining that, and that's. I think also fair, a fair arguments. In the initial, um, risk analysis that were being done, threats like hacking were considered in general, but I think specific threat agents were considered to a lesser degree. Awareness of the nation states kind of threats has probably increased over the last few years. And Norway as a country has had quite poor diplomatic relations with China. We have a border with Russia and you might think that somebody would want to try to influence the outcome of a vote. And that's. Clearly a threat. To an online system. So I mentioned the cryptographic protocol, I'm not going to go very deeply into that because then we could spend an hour just talking about the crypto and that's a lot of fun for a geek like me, but it might be a bit narrow. Uh. From the cryptographic literature, this is a reasonably standard voting protocol. It uses Alkmaar encryption and it uses, uh, actually Helma morphic, the home of morphic property of the ultimate crypto system to make computations on encrypted ballots. So basically, they encrypt that encrypts the voters vote intent with El-Gamal and then they use that do further computations on the encrypted cipher texts and to do some transforms into to mask what's going on. And then between each step in the processing chain, the system uses Schnoor signatures or Schnoor based their analysis process to ensure that everything is is correct. And then there's a mixed network at the end which is used to. Basically a separate. Separate the voter from the ballots. Uh, they also use S
homer secret sharing to split the encryption keys again, to make sure that multiple operators have to collude, that that you don't have a single operator who sits on the key. And the protocol is pretty well described as being analyzed by by Christina Ersten in some public papers. Uh, there's nothing, uh, there's nothing really bad there. It's I think it's a good protocol. And so we come to the election trial in 2013 and the verdict trial happened in 12 municipalities out of four hundred twenty eight, and they're marked in green on the map here. I don't know if you can see it. Uh, which meant that there were about 250000 voters who cast about 70000 ballots over the net and the Web page looked. Well, the starting page looked like this. It's in the region. It says that there's a column on the left which explains a bit about the Internet voting and then there's information about how to vote and how to log in. There's a link to a video and there's some information about, uh. The votes being secret, and you should you should make sure that you are in the private place when you are casting a vote online. And so the authentication for this system is based on the existing public infrastructure using two factor authentication, is that some sort of hardware token? Then there's a there are actually two feedback mechanisms for the router when after casting a vote online, you get you get Nessim code, which is, I think, a four digit number or a six digit number, which you can verify against a list of codes, which is written on, uh, on your, uh, on your voting card, which is a card that you you get in the mail. And so this this link here is actually one of the fundamental security assumptions that this document with the code cannot be linked to the access code, cannot be linked to the person. Uh, you in the Web interface itself, it also gives you a shot, 256 husch of, uh, of your encrypted votes. And the idea was the assigned list of Shata physics hashas would be published to, uh,
to GitHub during counting, which meant that during counting you could actually go online and verify or verify that your hash was in the list if you wanted to. And so this is all a webapp running on Linux, I think it was S.O.S. It's a job application on the back end in 2013. The front end was all its HTML and JavaScript. So there was quite a bit of JavaScript crypto going on there. The project had a few additional safeguards, so I already talked about the feedback mechanism to the voter, which was the return codes and the Balthazar's. They also had election monitors to to shadow the system operator to and to basically follow them around and see what they were doing. I guess a drawback of that approach is that, uh, the election monitors don't necessarily know what the operator is typing into the system on the on the command line. Uh. Because the interface is kind of complicated, um, the source code is all the source code for the election system is public. It's under a proprietary license owned by the government, but at least it's that they publish it online. And they had quite a few Third-Party, uh, contractors to audit the solution. Uh, there was a Web security test of the front end. Uh, there was the external review of the crypto, which was, uh, my job. And there was actually an independent third party implementation of the vote counting module, which meant that on Election Day, there were they had two independent implementations of the counting system which were running in parallel on the same data. And so the idea was that if somebody tried to tamper with one of the counting systems, they hopefully shouldn't be able to to sabotage the other the other one as well. And then the entire electoral system was also monitored using using Splunk, which meant that the local logs were being collected continuously to to a different system in a different security zone. So so they had been thinking quite a bit about this. And then five days before the election, there was a crit
ical bug. And so so the text here says this is from, uh, this is from a Norwegian newspaper and says there's a there's an error in the encryption of the events. And what actually happened was that the encryption, the encrypted ballots that the voter was sending, uh, actually leaked information about the plain text because of a bug and, uh, due to the layered security, uh, I mean, you were voting via SSL and that or and and then the votes were stored on on the secure system. Hopefully, uh, it meant that, uh, this information should not be leaking anyway, but, uh, at least one of the security layers was quite badly broken. And it seems like a combination of luck and preparation made sure that no votes were actually revealed. But it was a very close call. And we will get back to the course of this bug a bit later. And then what happened in 2014? Well, the project was ended and the government decided that the government had an evaluation by, um, by political scientists focusing on the project goals, which were to increase availability and to and to provide solutions tailored to young voters. And they found that voting was popular among the voters and the people. But turnout did not really change. And the online and the online voters were quite similar to the voting population at large. And so the project was ended and the BBC posted a story about this a few days later and looked like this. Uh, and so the press release mainly highlighted the lack of political will, but it also said that most voters didn't have much knowledge about the security mechanisms in the system. And so the BBC framed it like this and the government didn't quite like that angle. It said that BBC misreported. And so it's quite interesting what the Norwegian government says here. It says that Norway has a strong tradition of seeking consensus in all matters regarding electoral policy due to the lack of broad political will to introduce Internet voting, blah, blah, blah, blah, blah. The government dec
ided not to continue expanding public resources on the pilots. And I think that's actually a completely honest statement that in the sense that. Instead, voting was. Kind of controversial among the different parties, but there's also a very important subtext here, which is that after the 2013 elections, there was a change of government. And so in 2014, when the revelations were complete, the main champions of this project were out of power. And so a lack of broad political will, that's completely true. But I think it's also important to note that it's also very politically expedient, like why do I want to spend money on my predecessors, like expensive pet projects? And that has nothing to do with technology and it has not it has nothing to do with the sort of the de facto trial, but it's it's convenient. I mean, you can just throw it and you can just throw it under the bus because you have a nice excuse. You can use the money for something else. And so the next thing I'm going to look at is how did we actually get to this trial in 2013? And so this timeline here is not 100 percent exact, but it's I think it's close enough to to paint a picture of what's going on. So actually, in 2004, the government, the government at the time started doing a feasibility study about electronic voting and online voting, but there wasn't really any, uh, huge enthusiasm, as far as I know, about doing anything more about it at the time. Then in 2005, there was a parliamentary election and there was a new government where. Some of the parties in that was a coalition government of three parties and at least some of the parties were quite keen interest voting. And then the ball started rolling, they got some champions, government, and they got this feasibility study back a year later and so there was a project organization and everything went she went from there. So so I've I've I've been digging a bit in the electoral manifests from from 2005. And at least one of the parties said, quote,
It must be easier to vote. Students and pupils must be able to vote on the place of their studying, and it must be open for electronic voting over the Internet and quote. And so that was that was in their party manifesto in 2005. And apparently they managed to get to get that ball rolling because there were some people who were keen on doing that. So in 2006, they got the result of the feasibility study showing basically the state of the art in 2006. That was a 200 page report in the region. It contained quite a lot of information about experiences from other countries, including Estonia. It also included a high level threat assessment, which apparently didn't consider state actors. But it's it considered packing in general. But again, this was 2004, 2005, 2006. The study, the study was circulated for common sense. In 2008, the ball started rolling. So they got some funding. They got the project organization. They started specifying the use cases in the processes and the documentation that they wanted to implement. In 2009, they got a vendor after a public tender, actually, they got two vendors in 2009 for various systems. The goal at this point was to make a pilot aiming for full Internet voting by 2017. And so the initial the initial version of this implementation was finished in the summer of 2011. So this is kind of funny because it's been a few years, and then suddenly in 2010, people realized that, hey, we are going to have Internet voting next year. This is this is kind of interesting. So so so there finally was a bit of public debate, but at this point, I think. Uh, the forces in motion were such that in any case, there was going to be an experiment in 2011 because it was it was already decided. So there are quite a few skeptical voices, and it's kind of interesting because they didn't really split along political lines. One of the one of the most well-known political scientists in Norway, who Professor Frank Albright, who is a known supporter of the the gov
ernment who was doing this, uh, stated quite flatly that Internet voting violates human rights. And then his argument, again, was about voting under UN control in an uncontrolled environment and under unclear circumstances. In any case, in 2011, we had the local elections, uh, there were there were, of course, us, as there always is in this kind of, uh, in this kind of trial with a with a complicated technical system. There were a few bucks. Uh, some of the main problems were actually connected to this return codes that were supposed to be printed on it, printed and sent by mail. Uh, because there was, uh, there are some misprints. And there was also the fact that this terrorist attack happened six weeks before the elections and actually meant that the servers that were running the trial election were actually closed off as part of the crime scene, which was kind of inconvenient because they need to get to the servers. But in the end, there were twenty seven thousand five hundred people who voted over the nets and it seemed to be an overall success. The studies show that the voters were statistically quite similar to the voting public, except that they. When you are voting in Norway, you have some options to modify the ballots to in various ways and the people who are voting online were actually a bit more active in making those modifications because it might be that it's easier to do it in an online environment than the pen and paper. And there were nine invalid votes, and I'm actually not sure how that happened, but at any rate, it's quite a low number. Usually, I think I think they say that's between between half a percent or two percent of votes or something, uh, maybe maybe spoiled. So it's so actually, it would be even with paper voting that that number is quite high. So after evaluating 2011, they decided to continue the project, this time with a single vendor. They did. They made some technical improvements for randomization. Among other things, they also re
placed the clients, which in 2011 was Java applets. And then they found out the Java applets are not really very cool anymore. So in in 2013, they decided to replace it with a brand new JavaScript implementation because JavaScript script is really cool. And so in in 2013, we're back to where we started. There was a new election, this time in in 12 municipalities, more than 70000 votes cast online, and there was a change of government after after eight years. And so summing up this bit, I think there were some things that weren't quite right in this trial, uh, the system seems to have worked very well, technically, in the sense that it's it was, uh, it didn't have any significant trouble with the performance or down time. Uh, there were a few spoiled invalid or invalid ballots. Uh, there was there was quite a lot of audit log verification which did not show anything going wrong. And the system proved to be quite popular in in the areas that actually used that. So so there were several problems along the way, but at least snowboarded discovered any anything that they really, really hadn't thought about. And. On the other hand, there are also quite a few difficult areas, uh, there is, uh, there is a trade off between security and sort of verify verifiability and testability, like the fact that I was quite hard to, uh, was quite hard to provide runtime monitoring for some of the systems because, uh, because of security concerns, uh, the voting cards and return codes. So the physical artifacts caused a few problems. Uh, Kimelman suppression of duties is always hard. Uh, one of the really important aspects there is the voter understanding of security mechanisms and the ability to verify what's going on. And one one thing which was noted was that quite a few people. Uh, very, very diligent about checking the return codes and even fewer people would actually go to the step of trying to verify the shuttle features X hashas, and that's yeah, that's kind of understandable. Uh,
on the other hand, it's, um, it means that having those mechanisms available doesn't necessarily mean that people will use them. And there was, uh, there was a fishing demonstration in 2011 where as an experiment, as an experiment under under control circumstances, a professor at a local college set up this, uh, fishing patch, which looked like the real patch and try to get information about the return codes from the voting cards from the voters. And that's the key piece of information which links the voter to the, uh, verification. And that was that was no problem because fishing works. Right. So you have these kind of you have these kind of problems. Uh, you also have the entire complex regarding secure software development and also, of course, running an online system and keeping it secure, which we know is hard. And so because of this before the 2013 election, which was decided to run a technical review. So I think a problem here was that even though the source code was public, uh, it didn't really get a lot of public scrutiny and the project didn't really succeed in making the tech community engaged with this. And after the fact, I was reminded a bit of this when the Heartbleed bug showed up earlier this year in the sense that, uh, kind of like open SSL, you have this huge bit of security critical code and it's open. But, uh, the barrier for somebody to actually look at it is kind of high. And there are a few exceptions, there was this fishing experiment that I talked about. There was also a report on cod quality, which actually was quite simple. Well, there were a couple of researchers who just ran some automated tools and saw that they got a lot of logs and did some basic analysis, analysis of those findings. And it gave an indication that the quality of the source code might not be very good. But anyway, the project wanted to get more information. And so I got this assignment to to perform a third party review of the cryptographic primitives in key generati
on implementations. And there are some quite big constraints on this review. Uh, one of those constraints was there was a time frame because this was in the summer of 2013 and the election was in September. And if we were to find something and actually do something about it, uh, there was be quite a limited timeframe to do it. There was also a question of manpower because it was in the middle of summer vacation in Norway. And so I did this analysis by myself. In the limited time span, I would have loved to involve more people and then much more work on it. But basically the resources weren't available. And so I got this assignment. I said, OK, what does this thing look like? Well, there's a subversion repository. So first thing you do, grab the code. Uh, second thing you do try to build the code and discover that it doesn't build. And apparently there were there were also some time availability issues for the repository because this was clearly not a main priority to keep online. It was online. It was nice to have online, but also because of the limited interests that wasn't the main focus and particularly not in the middle of summer. And so, OK, next thing you do, you start to look at the system documentation and you see the deployment diagram. It looks like this. And so it's kind of a problem that for security systems, you want to keep things simple for Internet voting, you need to keep things a little bit complicated because you need to keep everything separate. And so here you have a whole bunch of systems doing different stuff. Uh, several of the service are aircrafts, but this is just a huge amount of complexity right here. And so you look a bit more closely to code. You see there's it's 200000 lines of Java. And that's and that's source lines, that's no no comments, no whitespace, no unit tests, and I think also the modules that are not actually used are excluded. So it's quite big. This is this is code, which is part of the project is not third party librari
es, uh, these are kind of also approximate sizes because when I was looking at the source code, I find out that sometimes quite hard to determine whether a specific Java class was part of the production system or not. Uh, that was actually quite hard to figure out. And I had a recurring problem trying to map the high level description of the system to the source code, because that wasn't really well documented. And so. OK. OK. Next thing you do, you run some automated tools. Somebody had done it before I did it again. And this is only from parts of the code base and I don't think you can read it, but there's several hundreds of several hundred Yellowbird findings from Five Bugs, which says that, OK, this might not be critical, but it's pretty clear that the team is not using automated tools proactively. And so actually the hard part here is that you get so many warnings that it's hard to determine which ones are serious and which ones are. Can be ignored. And so it looks kind of perfect. Um, just just from this high level analysis, you get some kind of idea that, uh, the complexity of the security system is is quite high. So to summarize some of the findings from just going on a safari, uh, there's some trouble with a separation between the security logic and sort of the the business logic, the sort of voting process implementation. Uh, as I said earlier, I had trouble mapping the high level design to the implementation. And also because the project was spraying in the EU's dependency injection, it was quite hard to to read the code and to see what was actually going on, because you had all these dependencies to the configuration and runtime setup. Uh, basically, it's pretty heavy lifting just to get into the code. And my focus was not the code in general, but the crypto. Well, there's a huge amount of crypto here. And so there's a huge amount of low level crypto and it's quite clear that the developers have made the system clearly know a lot about crypto. But the p
roblem is that when you have this sort of copy and paste development and you have code all over the place, it's not consistent and. It's it makes it very hard to to audit and makes it definitely very hard to verify anything, and you get this separation between the system, which is either obviously secure or not obviously insecure. And so so one of the examples was that. Get to that later. I think there was also some kind of this enterprise software syndrome, I've been working on quite a lot of big enterprise software projects, and this looked suspiciously like one of those. And so. Uh, it's difficult to establish and enforce sort of technical quality metrics in this kind of code basis, and it's kind of unclear what what are the appropriate quality and assurance levels for critical code. So looking at some of the bugs, so this was some code in in a method called cipher symmetrically, which was used to to to password encrypt the security token for export to disk. And so the really bad thing here is that there's actually a developer coding this thing. And there are some kind of strange things here, like they're using predictive, too, which is, well, it's more or less what you have available in Java. Uh, so so I guess that's reasonable, even though you might have like something else. OK. Oh, they're using counterfeit back mode with. That's that's kind of interesting, but it's not illegal. Uh, but, uh, they have a PPK, they have two iteration, kind of two, which is kind of bad. Uh, you should do you should use something like ten thousand. So, uh, which means that the passwords would be quite a lot easier to brute force than there should be. Uh, there's also this factor that that we're using a static IV, which meant that, uh, basically the encryption was not, uh, you could see the encryption was really not secure because you really shouldn't be encrypting, which is static vis. And so there's also an inconsistency here and that they are suddenly using attack mode and picka
xes, seven padding, whereas elsewhere they're using CPC mode and because it's five Badeh. So it's. There was not a bag I found which was related to Shamos secret sharing, which is really secure if implemented, right? Actually, it's mathematically you can prove that it's mathematically secure if it's implemented with proper random numbers and you do everything correctly. But they didn't. So the security proof broke. And so this is a sign of the vulnerability that probably can be exploited. But it's it's well, who knows? It would have to analyze it to tell. And then there was a lot of awareness, such as in one place and five to to verify file integrity for some temporary files, and then they were saying that, uh, but integrity for these temporary files is not really important. And I say, well, but you shouldn't be using the five anyway. Uh, there was a really strange custom implementation of data enveloping. So instead of using some sort of standard for that standard encryption envelope to to to encrypt data, there were there were there were some custom code for it. There was a secure audit logger, which was, uh, when I was analyzing the code, I said, aha, the secure audit logger is not secure against attacks. But then in this case, this was a problem which was not being solved by crypto. They were solving it by using Splunk to to gather the logs on the fly so that even if you could truncate log on the server, it would be you would capture it in Splunk and vice versa. So that actually thought about that. But, uh, so on junkie generation, there was some sense of plain text being written to disk, which was kind of silly. Um, and this was on an aggregate server, so it would be hard to get through, but maybe you should try to do disk. Uh, and there's this thing about secure and random not being explicitly initialized. So you need to trust that you're aware that you're always in your Java implementation and set up correctly to to to use something sensible. And then finally
, there was this critical encryption bug, which I mentioned, which actually hit the real election. So this was actually in the JavaScript groups of clients, which was not something I audited. But quite honestly, I wouldn't have found this one even if I did it. But, uh, it's kind of like a Debian run the bug in that in the sense that you got really poor on numbers. And and so what it meant was that about thirty thousand ballots were encrypted with the same randomness instead of unique randomness, which was kind of bad. And it was actually caught by the team who were implementing the redundant ballot counter because they were using the system to generate some test data and then they were finding that this test data looks suspiciously similar to itself. So so wrapping up some thoughts, uh, the stuff I did here was just a pure source code analysis. And so the system is really too complicated to verify that way. So to do a more realistic test, you should really be, uh, interacting with the a running code and trying to trying to figure out which which interfaces you can you you can play with, um. And so I don't actually think anybody, uh, tested this or the resilience of the backend systems to do malware infection or or the kind of intrusion. Uh, there were some so over the project and talked about the fact that if they wanted to run this on the national level, they want to have common criteria certification. But for the pilot, they prepared some documentation, but it didn't go through the certification process. There was also trouble with the late code delivery and lack of a really proper freeze stabilization period, which was also criticized by the OSCE election observers. There's also the question about how to involve the tech community, and I think part of the problem is the common reaction, myself included, that no, I don't want to look at this. I don't want to engage with this kind of project. Uh, but it also means that there's quite a high barrier to entry, uh, eve
n for techies. If you wanted to try to get into this, it's it really takes a lot of time and a lot of work to, uh, to understand what's going on. And that's that's hard to to deal with. So there's a question if if the project in some way could have improved incentives for for people to participate. And there's also, I think, a bit of a cultural language barrier inhibiting foreign interests. So even though even though the source code documentation is in English, a lot of the discourse and context on the analysis is, is in the region. Norway is a small country and people don't necessarily follow what's what's happening in Norway. So I guess it's also slipped under the radar of quite a few places. And so it seems like this is the end of Internet voting in Norway for now and as security experts, electronic voting scares me and at the same time. I have a little bit mixed feelings about this, because this was really, I believe, a good faith attempt at getting it right. And we now have a lot we've not lost the knowledge and expertize and the working organization who are working on this project and actually preparing this talk. I was finding that a lot of the links and a lot of the documentation was getting harder to find because of Glencross. And obviously, technology marches on elsewhere. We have electronic voting rolls in Norway and there's an electronic system for scanning and counting votes. I don't think that's been very heavily analyzed by the security community yet. It probably should be an Internet. And computer voting is on the agenda elsewhere as well. And so that's it for me. I'd like to thank you all for coming. OK, now we have about 10 minutes for question and answers, if your questions, please line up at the microphones. Um, do I have questions from the Internet? Yeah. What do the voters given us receive after casting their vote? Does this change when casting a vote again in the same election? And if so, does does not open up an opportunity for vote selling?
So the question was whether the written code switch were sent by ISIS would change during the election and whether that would open opportunities for vote selling. And I don't actually know. I've actually not I haven't seen these voting cards because they were only given out in in the municipalities where they had the trial. My understanding was that there was a unique random code for each party on the ballots corresponding to that voter, which you would get by Ausmus. And then you can and then you could verify this mess with the paper. And I haven't really spent a lot of time thinking about vote selling scenarios related to that. So I guess the main safeguard is that you could always go and vote on the election day on paper as well. OK, those who are going out, please be quiet so that the question answers can be understood. So question for microphone to did the online world do us vote for different parties compared to offline voters? Because this might explain the cancelation of the project. Uh, the question was whether online voters voted for different parties than the than the offline voters. And as far as I've been able to determine, the answer is no. Statistically, statistically, it was, uh, very similar, both on the national level and then locally in the different municipalities. So it didn't seem to be any differences that weren't explainable by all the statistical factors. OK, question from one. Yeah, I'm just wondering if. Was there any attempt or what was the procedure when the tenants were selected in the process for selecting who should make the system, uh, as to, you know, vetting who was programing and so on? I mean, did the persons involved was there? And is was that a factor in the selection process or because, you know, you could say that, well, this is a pretty sensitive system for handling sensitive data. And, you know, the security services might want to look into who is actually programing because finding that row in the right, a random number ge
nerator, would be easy to sneak in if you you know, you know, what you doing. So so the question was whether there was any vetting of the companies doing the software implementation of the people doing the software implementation? Uh, I don't I don't know. Uh, actually, the main uh, the main company implementing the solution was not, uh, Norwegian. Uh, but I'm not, uh, I'm not going to name names here, but it's it's all public. You can find it online, but I'm not going to name names. Uh, but, uh, whether the whether the national security services did any kind of vetting, I don't know. I know that during the tender process there were five companies, uh, bidding for this, uh, contract. And I'm sure I hope that. I hope that I thought about that angle as well. But I don't I don't know anything beyond that. OK, uh, question from number three. All right. First of all, thanks for the talk. Uh, that has been really interesting. I have one question. You mentioned that there are nine invalid votes. Um, when I get a paper ballot, I can willingly make an invalid vote. Um, the nine votes, were they invalid because of nobody knows, technical bux or invalid because of. No. Someone volunteering made like three crosses instead of one cross. Uh, the question was about those invalid invalid ballots in 2011. That's a very interesting question. I don't I don't know. Um, I also didn't find any numbers for twenty thirteen regarding whether any ballots were invalid. Uh, I, I'm really not sure what's, uh, what happened there. OK, thank you. OK, uh, one question from the Internet. Um, was there any studies of user users or borders voters of the understanding of the security mechanism also? Are there any reports available in English? Uh, so so the question was if there were any user studies regarding the security mechanisms and also if there were reports available in English? Um, I think I think the answer is yes to both of those. Uh, most of the technical documentation about the system is av
ailable in English. And also regarding the political science, I've learned the user studies. I think it might not be available in English. I know that there were several user studies and user testing, um, and then various also user behavior regarding the, um, uh, verification mechanisms. Uh. Which which which is, I think, also the source to the to the fact that a few a few voters are verifying but not, uh, not very many. I think it's also a valid question to ask how many how many percent of the voters should do a manual verification to get some sort of statistical guarantee? I don't know. OK, from number two, are there any countermeasures against an inside attack, especially can the voter verify that they have not been added any additional votes? Uh, I think, uh, the voter would be able to verify as long as he or she would be able to receive, uh, SMS for that number. Uh, as for countermeasures against insider attacks, we we had the election observers and there were also the fact that they used, uh, the secretariat to split key so that you had to have two operators at the same time. And there were, of course, access controls and and so on and so forth, meaning that it was physical security at the sites. OK, from one. So I was wondering if they actually looked at other existing systems and if you looked at other existing systems and and maybe just generally, do you do you think it's a good idea to to try to make a system that doesn't have those failures? Uh, the question is whether I have looked at other systems and whether they had looked at all the systems and whether it was a good idea to do this. Um, the project certainly looked at other systems, both in both in 2006 during the feasibility study and also up front before they started the project. As such, I have not I did not have the opportunity to look at a lot of other systems when I was looking at this because I was in a hurry. Um, but of course, I'm I'm familiar with the voting in Estonia and so on. Uh, person
ally, I don't think this is a good idea, but I think that, um, in order to in order to get that message through, you have to engage both on the technical the technological level, but also on the policy level. OK, uh, since the time is almost out, one last question from to. Yeah. I was wondering if you have any ideas about changes to language or workflow used to result in better quality source code. Uh. I think I think from from my point of view as a cryptographer, an engineer, and my my perspective would be to try to isolate and encapsulate the cryptographic codes as much as possible. Uh, regarding more general software development techniques for for guaranteeing high quality and and so on, so forth, I'm probably not the person to answer.
