We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Swiss Cybervoting PIT(falls)

00:00

Formal Metadata

Title
Swiss Cybervoting PIT(falls)
Title of Series
Number of Parts
254
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The Swiss democracy is one of it's kind. Digitization is starting to affect even our most critical processes, such as voting. When a piece of code suddenly gets responsible for democracy, it's only natural that the voices get loud and many questions get raised: Is our democracy at stake? Do we have to fear for our privacy? Is electronic voting even feasible in Switzerland? Is such a solution secure? As part of a mandatory Public Intrusion Test (PIT), the Swisspost released their e-voting source code to the world and started a heated debate - far beyond the Swiss borders. Not only the codebase revealed several problems during the PIT. Interesting scoping, redefining the term "open source" and unreleased security audits were only some of the issues that security researchers faced and caused controversy. In this talk we will have a look at many technical and non-technical aspects of the e-voting solution and PIT from the view of a participating security researcher.
Keywords
47
72
Thumbnail
1:02:13
82
Thumbnail
1:02:15
99
144
157
162
175
179
187
246
253
Radio-frequency identificationComputer animationJSON
Computer fileCodeReal numberCore dumpBitPatch (Unix)Content (media)Table (information)MereologyCovering spaceComputer fileElektronische WahlVotingComputer programmingLibrary (computing)Formal verificationCuboidServer (computing)Point (geometry)Data managementEndliche ModelltheorieData compressionFunctional (mathematics)Exploit (computer security)Software testingInformation securityReal numberPhysical lawCore dumpTelebankingCoefficient of determinationCodeView (database)InformationRegulator geneMultiplication signObservational studyParameter (computer programming)MathematicsRadio-frequency identificationConnectivity (graph theory)Pairwise comparisonDatabase transactionSoftware developerOnline helpProjective planeFlow separationProcess (computing)Computer architectureEvent horizonFluid staticsPhysical systemVirtual machineSoftwareEmailLine (geometry)System callWebsiteFitness functionSound effectMoment (mathematics)Texture mappingVirtualizationDesign by contractState observerUniverse (mathematics)Open sourceRootCybersexSerial portStreaming mediaRow (database)Bus (computing)Descriptive statisticsLevel (video gaming)String (computer science)Expert systemStaff (military)Traffic reportingScaling (geometry)StatisticsCountingState of matterComputer animationLecture/Conference
Front and back endsRadio-frequency identificationService (economics)AreaInclusion mapData compressionPhysical systemoutputElektronische WahlDependent and independent variablesData managementIP addressFormal verificationInformation securitySoftware developerPower (physics)Library (computing)MereologyProjective planeDivisorSystem administratorMathematical analysisSoftware testingVulnerability (computing)BitVotingHypermediaLimit (category theory)EmailUniverse (mathematics)LoginMultiplication signLeakSound effectPoint (geometry)Operator (mathematics)Server (computing)Instance (computer science)Flow separationExploit (computer security)Scripting languageConnectivity (graph theory)BuildingPublic key certificateInterface (computing)Open sourceCodeFunctional (mathematics)Uniform resource locatorRadio-frequency identificationComputer programmingAreaPerspective (visual)Rational numberPatch (Unix)Order (biology)Repository (publishing)Rule of inferencePlanningState of matterTheoryProcess (computing)Right angleKey (cryptography)DataflowLine (geometry)Design by contractFrequencyFrame problemTwitterTransmissionskoeffizientTwin primeWebsiteLecture/Conference
Computer animation
Transcript: English(auto-generated)
So the Swiss democracy is one of its kind.
No other country lets its citizens have that much of an impact on their rules and regulations. Meanwhile, in a time where everything gets digitized, it's only a natural conclusion that this might also affect voting someday.
So earlier this year, the Swiss Post released their e-voting source code as part of a mandatory public intrusion test, or PIT for short. Yeah, and that's where our story starts. My name is Janis Kirchner. I'm a Swiss cybersecurity researcher and CTF player.
Together with my research team, Setua D0, we analyzed the Swiss e-voting source code. Obviously, my views are my own and not my employer's, grandma's, or dog's. So a little bit of background information. Why should we vote digitally in the first place?
So one of the main arguments was that it's comfortable for expats, for people living abroad, because for them, voting used to be quite a hassle. They have to send the votes per mail and sometimes the mail gets lost or arrive too late. So that's one of the main reasons. Also, it should attract young voters and it should make voting more accessible to the public.
However, e-voting also comes with major downsides. Security risks are on scale. You don't have to bribe a few thousand people.
You have to find the right exploit and maybe you can even do it in the comfort of your home and home. Also, it's very expensive to maintain and the systems must be trusted and it's hard to create that trust because how do you make sure that the software running on these voting machines is actually the software that has been released or tested?
The first thing that comes to mind is a checksum. I mean, checksums are great, right? But how do you make sure the checksum program is right and not just the static string? So that's one of the major problems. I often hear a comparison between electronic voting and electronic banking.
However, I think there are major differences and in my opinion, it's easier to protect electronic banking because there you have transactions between two parties that can easily be identified and corrected. In electronic voting, you have to guarantee absolute anonymity for the voter, which makes it pretty hard.
There are two components. There is the universal verifiability and the individual verifiability that are supposed to make you validate your votes mathematically. These are some core components of electronic voting.
So, yeah, the process is, if you vote offline, you usually have your vote and you put it in a ballot box and then you have a lot of people that count the votes. You have election helpers, you have election observers, etc.
But if you vote online, you just send your request to the server and afterwards you get a checksum back. And that checksum is for your individual verifiability that you can prove mathematically that your vote has been counted correctly. On the other side, for the government, they get the universal verifiability where they can check if all votes have been counted correctly.
Mathematically. So, fast forward a bit, electronic voting is nothing new, per se. Many Kenton's already had electronic voting solutions in place, for example, Basel or Geneva.
However, the new part is that the government wanted to use electronic voting as an official voting channel all over Switzerland. So, there were some problems. Geneva had to stop their e-voting program completely and Basel is on the verge of it.
Because electronic voting is extremely expensive. There were some studies that said for every effective user, a user that used electronic voting over 10 years, the Kenton of Basel would have to pay around 4,000 Swiss francs, which is honestly quite a lot.
Yeah. And Geneva is an interesting example because it developed its own electronic voting solution that has been used by some of the Kentons in Switzerland. So, source code publication.
It was pretty interesting when we could get our hands on this very special code, this very important code. And so, it started to the great news, we went to the website, we wanted to download it and we were greeted with a non-disclosing agreement. This struck me as odd because I thought the code was supposed to be open source.
However, the Swiss Post introduced open code, which is basically release a snapshot of the code under an NDA. So, the code is public but it's not really open source, not at all. So, yeah, nevertheless, we signed up for it because we wanted to test the code.
And the first thing we noticed is how big the code actually was. Like, it was around a quarter million lines of code. It was really big. And it featured a microservice architecture of several components that talk with each other.
It was really, really a big solution. And another thing that was really, really big was the dependencies. They had a lot of dependencies, like really a lot. And history has shown that dependencies can be really dangerous.
One example that I like to come up with is Event Stream, early 2018, where a developer got tired of maintaining his nice little project and transferred ownership to someone who offered help. However, that person was a malicious actor and, yeah, now a few thousand programs featured malware in it.
And also, in the e-voting code, we found some dependencies that third-party libraries that were vulnerable to several exploits. However, the functions weren't exactly used, so the risk wasn't that big. But alone, the fact that these libraries were present shows that, yeah, it's a real threat and that patch management is hard.
So where do you start when you've got such a big software? First point would be documentation. You look at how does it work, what's the threat model, just look how it works.
So, in the Geneva system, they had a lot of documentation. They had like threat models for every component, but in the new Swiss Post system, there were only three high-level documents. Some about the cryptography, a little bit high-level voting workflow, a little bit lower level, but it wasn't that useful.
It also featured some API descriptions, but most of them were internal and weren't of much use. But there was something interesting, there were security audits performed before the public intrusion test.
And these are great because you can see maybe there were invalid patches or just see what are the core parts that are interesting to look at. So we went to the Swiss Post website, we downloaded it and the file sizes seemed oddly small. Now, when you open these PDFs, they only seem to contain the covers in the table of contents.
Honest mistake, of course, everybody published the wrong thing, but after some further investigation, it showed that this was on purpose to protect the IP law of the company that audited it, and they didn't want to give out those reports, which was kind of a bummer.
So, okay, we had to work without any documentation, so next thing you usually do is, yeah, set up the system and check a bit how does it work, how does it interact, how to play with it, however you couldn't build the system.
The system wasn't buildable at all, the system wasn't meant to be built. The system relied on an internal build server at the development company in Spain, and you were only supposed to access the system during the official public intrusion test, where they provided you with a test instance.
So even with some public effort to reconstruct the source code by several parties, it didn't work out, it was just a too limited time frame, and yeah, the system was too big. So all that was left was static analysis over the whole thing. So during our research, the media blew up a bit about the news of some e-voting leak.
This is odd, I thought, because the system was released, right? Were there some components they were hiding or something? No, it turns out some people took the source code and uploaded it to their own GitHub repository,
so others could evade the non-disclosement agreements, and obviously there were DMCA claims filed against it, and so this news could have been avoided if they would have open-sourced the solution. Yeah, so this function is really interesting.
How does it make you feel? How does it make you feel with user input? How does it make you feel with user input that's not validated? Yeah, you know what I want to imply here. The component called a secure data manager didn't seem as secure at all.
However, the post assured us that it's actually very secure because the cantons that run this component would use some air gaps, and the air gaps have proven to be very effective over time, right? So, yeah, very secure and out of scope, but they were happy to tell us that they would
sign-patch it, so it's all great. So this was around the time when the actual public intrusion test started, and you were provided with two URLs that you could test. It was the voting workflow and the administration workflow.
Well, you could only test the voting workflow. The administration workflow required some certificate-based authentication, and, however, they didn't provide these certificates. They didn't provide them on purpose because it wouldn't be realistic to provide them,
right? So you couldn't test the admin interface at all, maybe through post exploitation. So all that was left was the voting workflow, which brings us to the pit scope. To illustrate it, we started out with around a quarter million lines of code, right?
We put it through a public intrusion test, and we get this. This isn't cut off. These are nine resident points. That was the pit scope. Yeah, nine resident points, which were very interesting.
We looked at them. Surely they must be very secure. I mean, security must be tight there. But even with that scope, we still found some stuff. It turns out they used the X-forwarded-for headers, which transmit your IP address, and you can change them client-side. And they relied on these headers for the internal Splunk logs.
So you could just spoof some arbitrary IP addresses into their logs, into their internal logs. This one was also accepted as one of the few vulnerabilities of the system, which is really interesting, even with narrow scope. Yeah, and do you remember the universal verifiability from the beginning?
Yeah, apparently it's been broken as well. Some researchers found that apparently if you had access to the system, and if you could change the votes, then theoretically, under some circumstances, you could also do it undetectable. And so much for the e-voting solution.
Apparently, they weren't allowed to continue with it anymore. What holds the future? Currently, there were discussions about an e-voting moratorium in Switzerland, where they wanted to halt all e-voting projects for five years. And I've also seen developments made by big corporations.
Microsoft recently released an e-voting library written in plain C. Must be interesting to look at. And yeah, it still features a lot of interesting research area. So in conclusion, e-voting is interesting, but with great power comes great responsibility.
And if you want to develop an e-voting system, please put sufficient care into it. Thank you.
Is there any questions? If yes, go to the microphones to the left or the right.
Yeah, to the left. Did you have a chance to take a look at the source code from the Geneva solution as well? Or only the post?
Swiss post system. I didn't audit the Geneva system. However, I looked at it from just from the perspective. Geneva did a lot of things right there. They open sourced it properly. They provided lots of documentation and it just seemed a little bit more fitting. So I just looked at it from a program perspective and they made it easier for researchers.
They had also a buildable system. They provided docker containers. So that's for the Geneva system. But I can't make any assumptions from a code perspective. On the right. So thanks for the talk. Do you know why you couldn't build the source code?
Was it a part of source code missing or something like that? So basically the source code relied on internal build server at Skytel. So if you wanted to build it, you would need to have all the correct components, right? And you will basically need to reconstruct the build process for you.
So since they didn't provide that, it would have been very, very complicated. And some people tried exactly that to figure out which components were used and write your own build scripts. But the problem was that there wasn't enough time to do that. Okay, to the left.
Hello, if there were no vulnerability with this universal verifiability, would then Switzerland had online voting? And can you tell me a bit more about this universal verifiability vulnerability? What access to the systems should have the operator have to use it?
So basically you're saying that what are the effects of the universal verifiability vulnerabilities? If this problem wouldn't have appeared, then Switzerland would have had online voting for the elections in October, right?
Quite possibly, quite possibly. I mean, there were other problems, like especially the one with the source code that wasn't open source and some parts were missing and you couldn't build it. Usually the text from the government said that you should be able to build it.
Maybe this would have caused problems, but it was certainly an important factor that it can be built. Yeah, that it can be employed. Yeah, then a big thanks and a big applause.