VVSG Tutorial

VVSG Security Requirements Part 4 [^1]

*\[Slide 1\]*

\[NARRATOR:\] This is Part 4 of the Security Training Modules for the
next Voluntary Voting System Guideline document. This training module is
presented by Dr. Nelson Hastings of NIST's Information Technology
Laboratory. The module is an overview of Chapter 5, General Security
Requirements, for the next VVSG. The presentation includes question and
answer sessions with the Election Assistance Commission's Board of
Advisors and Standards Board.

*\[Slide 2\]*

\[MR. HASTINGS:\] I'll go ahead and start talking about the general
security requirements. There are eight different sections there. We'll
start off with cryptography.

*\[Slide 3\]*

As we've talked about, it's a powerful security control; it provides
information integrity and authentication. Requirements were developed to
reduce the maintenance for this. So we were sensitive about the burden
that this would put on election officials, so we tried to simplify the
key management aspect of it specifically and reduce the burden that that
would put on people. It also uses the strength of existing federal
standards that have been developed in the area of cryptography.

*\[Slide 4\]*

The cryptography requirements are really about the implementation of
cryptography, specifically public key and secret key cryptography, and
not cryptographic voting protocols, sometimes known as end-to-end voting
protocols. And then, like has been said before, many of the sections of
the guidelines leverage the security capabilities that cryptography
provides.

*\[Slide 5\]*

The first requirement on cryptography is that it needs to be done in a
FIPS 140-2 validated cryptographic module. FIPS stands for Federal
Information Processing Standards. FIPS 140-2 refers to requirements for
cryptographic modules, I believe is what it is. In addition, there is a
testing regime to test cryptographic modules to make sure that they
validate to that FIPS 140 standard. So what is really a cryptographic
module? A cryptographic module is a piece of hardware, software, or
firmware that implements cryptographic functions whether that's
encryption, decryption, key generation, digital signature verification,
or digital signature validation. Another requirement is that a minimum
strength of cryptography is specified in the guidelines so that you are
not using inferior cryptography. Over time, cryptography sometimes
becomes weaker, different algorithms become broken, compromised, and
that kind of thing, and fall to technological changes.*\
\[Slide 6\]*

So another requirement is to have this thing called a signature module,
which is a hardware cryptographic module that's validated to FIPS level
2. In the FIPS program, there are four different levels of validation
that you could go through, 1 being the lowest, and 4 being the highest.
So this talks to having a level 2 type of cryptographic module with a
physical security of that module being at level 3. And the signature
module is used to generate digital signatures. It generates and stores
private keys inside of that module and is permanently attached to the
piece of voting equipment. *\[Slide 7\]*

So to kind of bring this home of what we are looking at in terms of a
cryptographic module on a piece of voting equipment, we went out and
looked at what pieces of equipment right now that you could buy
commercially off the shelf that contained such types of devices. There
was concern that we are asking for devices that aren't in equipment
today that you can buy, the reliability of them were questioned. So we
looked to see if there were manufacturers actually putting these modules
on pieces of equipment- computer equipment. And if you look at the
diagram on the board, that little piece of silicon, that computer chip
right there, that is a cryptographic module that does digital signature
generation, digital signature verification, and the commercial name of
that chip is called the Trusted Platform Module. We've actually brought
in the boards themselves, so we are passing those around so you can look
and see what that might look like.

*\[Slide 8\]*

So the signature module has two types of signature keys: a device
signature key which is associated with a device for its complete
lifetime. And what this allows, it allows digital signatures to be
traceable back to a specific piece of equipment. In addition, there is
another signature key called an election signature key that is generated
and used just during one election cycle. I don't know if that's the
correct terminology, but what it is really saying is that you would use
that as you conducted one election. Go ahead.

\[QUESTIONER:\] What if we have multiple elections going simultaneously?

\[MR. HASTINGS:\] This is why I don't know if I have the actual right
terminology. What it is, is when you put it out and deploy that system
for that election or multiple contests or whatever, then it's used for
that one specific deployment essentially. And I guess maybe that's the
better terminology here- is not election cycle but really about the
deployment of that equipment to the polling place. Brit, you had a
question.

\[QUESTIONER:\] This subject is something that the election officials
can control?

\[MR. HASTINGS:\] Yes, it would be.

\[QUESTIONER 1:\] So basically if she wants it to apply to the election
and all the associated runoffs--

\[QUESTIONER 2:\] I've got a February, March, April election. So I've
got different names but the same pieces of equipment for--

\[MR. HASTINGS:\] I guess my question to that is how many times do you
configure that piece of equipment for those different elections? Because
the idea here is that that key would be generated each time you
configure it for a different election essentially or a different
deployment. So the effect that we are trying to get here on this
election key is that you can tie the digital signatures on the
electronic records to that given election that were generated by that
given election; the cast vote records, the system logs, and all that
information can be tied to that deployment or that cycle of use.*\
\[Slide 9\]*

Now the device signature key is generated using a random number
generator, the "nondeterministic" is a very mathematical term. The
requirements for it are that it can be exported from the- the public key
can be exported from the module in a public key certificate, either as a
self-signed certificate or it could be exported and then signed by a
certificate authority.

The other requirement is that a unique identifier on the surface, like a
placard or a serial number on the outside of voting equipment, that
number needs to be one of the objects or pieces of information in the
digital certificate that contains that public key for the digital
signature or the device signature key. The device signature key is used
only to sign election signature keys, election key closeout records, and
if it does a self-sign certificate, it can do a device signature key
certificate signature.*\
\[Slide 10\]*

Jim?

\[QUESTIONER:\] I have a broader question.

\[MR. HASTINGS:\] Okay. What's the question?

\[QUESTIONER:\] My question is what is the cost of this kind of
encryption requirement going to do to the cost of DREs?

\[MR. HASTINGS:\] I can give you some generalities on this. The question
was what is the cost of this encryption technology being integrated into
voting devices? I can only give-- specifically into DREs. The only thing
that I can give you is something that I saw in terms of the cost of
placing a trusted platform module on a motherboard. It cost them \$5.00.
It raised the price of their motherboards by \$5.00. That being said,
you have to understand the scales of economies, right. Intel produces a
lot of motherboards, so the cost is really laying out the board and
putting that chip in the board to do that. They do that once and they
sell millions of motherboards. So, that's the best I can give you on
that.

\[QUESTIONER:\] But isn't there also- it's not just cost for the
storage. Isn't there a cost for the software that's going to generate
the keys and the hashes and the signatures and all that?

\[MR. HASTINGS:\] There would be a cost in addition to integrating that
onto a DRE's motherboard; there would be a cost to modifying the code in
order to access the capabilities supplied by that chip or by that
cryptographic module. Barbara.

\[MS. GUTTMAN:\] Let me give a sort of general answer to that which is
that crypto- the hardware- has become, as Nelson pointed out, dirt
cheap. The software has become very readily available. Lots of people
make software that vendors can incorporate into their products. It's
pretty standard kinds of applications here. So the cost is likely to be
not terribly high. There is some cost to making sure you are doing it
right, but there are commercial pieces that can be purchased to add into
these. So generally, cryptography is your best return on investment in
security these days. That's my humble opinion.*\
\[Slide 11\]*

\[MR. HASTINGS:\] The next key is the election signature key. It's
generated in the same fashion as the device signature key. And its main
purpose is to digitally sign the electronic records generated by a
deployment. I'm going to use the term deployment instead of election
cycle. It's destroyed as part of the election closeout process. And it's
envisioned that this would be done- it would be created as part of the
setup process, just another command that you would do, and then as part
of the election closeout process, it would destroy that private key
that's in the module. There are a couple of other things that are
associated with the election signature key: counters to keep track of
the number of election signature keys that were generated by that voting
device as well as a counter that counts how many signatures were
generated by a specific election signature key. So one of these counters
is monotonically increasing over time, and one of these gets reset to
zero at the end of each election.*\
\[Slide 12\]*

This figure is really to show that the election signature key
certificates are signed by the device signature key. The election
signature key's public key would be in the certificate, and it would be
signed by the device signature key.

*\[Slide 13\]*

As part of the election key closeout record, this is an electronic
record that's generated by the system. It would include the public key
of the election signature key so it could just be the digital
certificate itself. It could be placed into the record. The number of
signatures generated by that key is recorded, and the election signature
key number for that device is recorded. And all that electronic
information is again digitally signed using the device signature key.\
*\[Slide 14\]*

Yes, Sandy?

\[QUESTIONER:\] After all of this information, what does it tell me?

\[MR. HASTINGS:\] It's the foundation for the integrity of your
electronic information.

\[QUESTIONER:\] So will it tell me if somebody has accessed my system
without my permission or will it tell me how many people voted or how
many people- ?

\[MR. HASTINGS:\] So the question is-- Sandy's question is a good one.
What does this buy me? This is a piece of the puzzle. This is the first
piece of the puzzle.

You asked is this going to tell me who accessed my system? This
cryptography is used to digitally sign system event logs. One of the
things that's logged is access to the system. So, yeah, it does but like
we have said before, these are kind of building blocks on each other.
You have to view them all together. Does that answer your question a
little bit?

\[QUESTIONER:\] I'm not sure. Let me ask one more question and then
maybe it will help. So if every time something is done to the voting
system, there is a little signature marking that event? Does it have a
date and time stamp so that I know that somebody was playing with it at
4:30 in the morning and it wasn't me?

\[MR. HASTINGS:\] A lot of the question that you are asking is about the
types of information that's logged as part of the system event log and
specifically the types of events that are associated with access
control.

And so the short answer to your question, I believe, is yes. But it's in
several different places in the document. So you have your access
control that says this type- Barbara, go ahead.

\[MS. GUTTMAN:\] It's the entire foundation of knowing the integrity of
your system. What records your system has, you can know are correct or
unchanged and where the records came from in case you have to move
records between- and it's going to do the same thing for your software,
which Nelson hasn't got to yet, because you are going to sign your
software too. So the entire foundation for the integrity of your system
is going to rest on this.

\[QUESTIONER:\] So why do I need to do that?

\[MS. GUTTMAN:\] Because it tells you that your system is entirely right
as it came to you, not that it was right before it was shipped to you.*\
\[Slide 15\]*

\[MR. HASTINGS:\] Okay, so some documentation requirements that you will
find in the TDP that are associated with cryptography really are the
fields or objects or information in the device signature key certificate
as well as the election signature key certificate. The specific
cryptographic algorithms used by the device and the closeout record
format.

*\[Slide 16\]*

Jim, go ahead.

\[QUESTIONER:\] Yes. I just want to rephrase Sandy's question. We do all
of this encryption and the system will still need a VVPAT? Yes or no?

\[MR. HASTINGS:\] The way the guidelines are right now, I believe the
answer is yes.

So the question is because we are doing all this cryptography and this
is the foundation of assurance that we are getting, why do we need
VVPAT? My answer to that is basically going back to the idea that you
can't prove that software is operating correctly, that's why you have
the VVPAT. This structure here tells you the software that you load on
your system hasn't been altered. It doesn't say anything about the
correctness, if you will, of the operation of that software. John
Cugini.

\[MR. CUGINI:\] With this method, in the North Carolina example, that
software could have been signed, sealed as authentic, unaltered, and yet
it still lost well over 7,000 votes.

\[QUESTIONER:\] My understanding was the poll workers ignored several
thousand errors.

\[MR. CUGINI:\] Oh, okay.

\[QUESTIONER 1:\] The North Carolina error would not have happened if it
was a modern accessible device because the screen would have said, this
machine will accept no more votes.

\[QUESTIONER 2:\] It had its warning disabled that if a situation like
that occurs, it shuts down the system.

\[QUESTIONER 3:\] That wasn't a machine problem to the extent that poll
workers knew there was something wrong-

\[QUESTIONER 4:\] After all this talk of cryptography, it's- that we are
saying- that we are saying that you've got to verify it's working with a
VVPAT, a piece of paper that is probably the most single unreliable
piece of equipment ever used in elections. I've got pictures right here
on my laptop if you really want to see a VVPAT audit out of Cuyahoga
County a year ago. These things are a disaster. It is almost laughable
and in the face of what you are presenting here, that we are talking
about verifying it with a VVPAT.

\[MR. WACK:\] This is John Wack. I'm trying to respond. I think some of
the issues that perhaps you are responding to, for example, the problems
in Cuyahoga County, were the result of poorly engineered VVPAT systems,
and that's somewhat been taken care of in the new requirements. With
those improvements, I don't think it would be the case that audits would
be as bloody or murderous as they seemed to be in that county. So I feel
in some respects that the VVPAT and paper gets maligned unfairly because
the truth of the matter is, a number of these systems were poorly
implemented. They were implemented before requirements were in any of
the voting systems standards. The usability for election officials and
for auditing paper rolls was not there at all. I think vast improvements
have been made upon them in the requirements we have. I felt it
necessary to just point that out.

\[QUESTIONER 4:\] Let me just add this to that. My background prior to
the election business was twenty years of commercial print. So I've been
putting a lot of paper through a lot of machines, and I could show you
what goes through a machine particularly if it's running reel to reel. I
just find it totally fascinating that after all of the presentation of
this, that we are still talking about verifying with a \$150.00, maybe
\$200.00, printer.

\[MR. SKALL:\] This is really an interesting discussion but I think we
are getting off topic. So the purpose was just to get everyone familiar,
and we will obviously have this debate. So Nelson, why don't you move on
now?\
*\[Slide 17\]*

\[MR. HASTINGS:\] And again to emphasize that we were thinking of
reducing election management and key management here- that the device
signature key would be automatically generated when it's initialized-
when the system is first used and installed. And election signature keys
will automatically be generated and destroyed as part of the election
setup process and closeout process, and this allows us to get some very
strong security in a reasonable amount of ease of administration.*\
\[Slide 18\]*

Yes, Wendy?

\[QUESTIONER:\] On the discussion of ESK, at what point does that
prevent, for example, if you have a recount, you either have to
regenerate a new ESK for a recount or do you reuse the ESK? Where is the
ESK and how broad is it?

\[MR. HASTINGS:\] Okay. The question is if you need to do a recount of
some kind- with an ESK and kind of try to get a feel for how the ESK
would be used, I think. Once the ESK is destroyed, records for that
election have frozen. The electronic records for that election have
frozen. You still have the public key to verify those electronic
records, okay, and you should have those electronic records around
still. It doesn't destroy the electronic records associated with that
election, but you can't create new records or information or log entries
that would be tied to that election.

\[QUESTIONER:\] So in order to do a recount, then you regenerate a new
election signature key?

\[MR. HASTINGS:\] No, because- Paul.

\[QUESTIONER:\] I think you have two questions here with the very same
answer, a question we don't know the answer to. We can't know the answer
to it because it depends on how the vendor implements it and how the
election management process has occurred. What you are simply saying is
that, at some point, there is a need to destroy the key so that no new
transactions for that election can be created. Is that a fair statement?

\[MR. HASTINGS:\] That's correct.

\[QUESTIONER:\] And what would be needed to be done in the event of a
recount depends upon the management processes that occur, not on the-

\[MR. HASTINGS:\] Yeah, I think you are right on that. Paul's response
was he thinks that we are trying to answer a question that is highly
dependent on election management, and that the destruction of the
election signature key basically just makes it so that you can't create
new records after it's been destroyed. And how one resolves, say, a
recount in using those electronic records is an election management
question. It's dependent on how the vendor implements their equipment.\
*\[Slide 19\]*

\[NARRATOR:\] Additional explanatory presentations on the Voluntary
Voting System Guidelines can be accessed from the Web site:
vote.nist.gov.

[^1]: ^\*^ Certain commercial entities, equipment, or materials may be
    identified in this presentation in order to describe an experimental
    procedure or concept adequately. Such identification is not intended
    to imply recommendation or endorsement by the National Institute of
    Standards and Technology, nor is it intended to imply that the
    entities, materials, or equipment are necessarily the best available
    for the purpose.