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/446 Thanks!
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
shape 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 Shomer 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
critical 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 decided 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 government 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
replaced 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
generation 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 libraries,
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 problem 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 pickaxes, 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,
even 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 generator, 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 available 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, personally, 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.