Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/1373 Thanks!
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 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's young executional.
I'm a Swiss cybersecurity researcher
and CTF player.
Together with my research team set up
this year, we analyzed the Swiss E-voting
Source Code.
Obviously, my views are my own
and not my employer's dramas or dogs.
So 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 experts,
for people living abroad because
for them, voting used to be quite a
hassle. They have to center votes
per mail and sometimes the mail
gets lost and 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, with the
e-voting also comes with some major
downsides.
Security risks are in 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 a
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
checksum. I mean, checksums are great,
right? But how do you make sure
the checks and 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 university 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 um,
if you if you vote line,
you usually have your vote
and you put it in the 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 sent
your request to the server and
afterwards you get a check them back
and check some.
It's 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 countries 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
channel.
As an official voting channel all
over Switzerland.
So there were some problems.
Geneva had to stop their e-voting
program completely in Basel
is on the verge of it because electronic
voting is extremely expensive.
There were some studies that said for
every effective user user
that used electronic voting over
10 years, the counting of Basel
would have to pay around 4000 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 contents in
Switzerland.
So SARS-CoV 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-disclosure 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
released a snapshot of the code under
an NDA. So the code is public.
But it's 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. It was really big,
and it featured a
microservices architecture of
several components that talked 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.
And 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.
He found some dependencies
that third party libraries that were
vulnerable to several exploits,
however, did function burned exactly
you? So the risk wasn't that
big, but alone that the fact that
these 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 got such a big
software?
And 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 news, a Swiss 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 as some
API descriptions,
but most of them were internal and
weren't of much use.
But there 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
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 after
a company that audited it,
and they didn't want to give out those
reports, which was kind of a bummer.
So, OK, 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 you 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 built
server at the development company in
Spain, and
you were only supposed to access the
systems during the official public
intrusion tests already provided you with
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 true limited timeframe.
And yeah, it 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 to
some components they were hiding or
something.
No, it. Turns out, some people took
the source code and uploaded to their
own GitHub repository, so others could
evade the non-disclosure and agreements.
And obviously this was their
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
inputs?
How does it make you feel with user input
that's not validated yet?
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 contents that run this component
would use some air gaps and Eric apps
have proven to be very effective over
time, right?
So, yeah,
um, very secure
and out of scope, but there we're happy
to tell us that they would sign and 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 to yourself
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 of ventilation,
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 could you couldn't test the admin
interface at all, you 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 Reston points.
That was the pit scope.
Yeah, nine nine Reston
points, which were
very interesting.
We looked at them. Surely they must be
very secure. I mean, security must
be tight there.
So but
even with that scope, we still found some
stuff.
Um?
Turns out they used the exfoliators
forages, which transmit your IP address.
You can change some client sites, and
they relied on these headers for their
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 do you remember the
University of 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.
And what holds the future?
Um, currently there were discussions
about 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 E-voting
Library written Plan 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?
I look at
is there any questions, if yes,
go to the microphones, to the left
or the right.
Do doing.
Yeah. To the left,
do it.
Did you have a chance to
take a look at the source code from the
Geneva solution as well?
Only the post?
So this post system,
I didn't audit the Geneva system,
however, I looked at it from
a trust. 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. From it, they made it
easier for researchers.
They had also 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.
Yes.
So thanks a lot.
And 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 SkyTruth. So if you wanted to build
it, you would need to have all the
correct components, right?
And you would basically need to
reconstruct the build process
for you. So and 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.
OK. To the left.
Hello. Um, if, um,
if there were no vulnerability with
this universal verifiability,
wouldn't would.
Then Switzerland had online
voting. And can you tell me about
the bit more about this universal
verifiability vulnerability?
What access to the systems
should have the operator operator
have to use it?
So basically,
you're saying that
what are the effects of the universal
verifiability vulnerabilities?
If, if, if this problem
wouldn't have appeared, then Switzerland
would have had online voting for
for the elections in October, right?
Quite possibly.
Quite possibly. I mean, there were a lot
of other problems like especially
the one with the source code that
wasn't open source and some parts
were missing. You couldn't build it.
Usually, the
texts from the government said that you
should be able to build it, and
maybe this would have
cost problems, but it was certainly
an important factor that it can
be built.
Yeah, that it can be employed
and.
Yeah, then a big thanks, the big
applause,
so.