VVSG Tutorial

VVSG Security Requirements Part 5[^1]\
*\[Slide 1\]*

\[NARRATOR:\] This is Part 5 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 continues 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:\] Setup inspection: these are requirements related to
capabilities to inspect properties of a voting system or voting devices
specifically. The requirements reflect the new focus in light of
software independence.

*\[Slide 3\]*\
These inspections generate system log events which include time and
date, information related to a specific inspection such as the
calibration of a component, the location where software is installed,
the result of the inspection. These are just a few. And right now, I
really should have probably said this before I started, I'm really just
going through the guidelines, kind of in a linear fashion. You should be
able to just follow along in the guideline itself. It will also have the
voting device's unique identifier and the individual or role that
actually performed a given inspection.

*\[Slide 4\]\
* There are two inspections related to software. One is software
identification and verification. Basically that's the ability to query
and inspect the voting device to determine what software is installed on
that system. So does this system have the right files that should be
there, the right executables, the right configuration files, those types
of things?

The second part is a software integrity verification using digital
signatures and hashes. What that's really doing is saying, is answering
a question, has somebody come in and changed the software on my system?
In light of SI, this approach allows for internal verification, meaning
that there does not need to be an external device connected to the
system to do the verification of the software on that system. This is
different than what was in the VVSG2005 because the VVSG2005 didn't have
this notion of software independence. Okay.

\[QUESTIONER:\] You may have this but one of the things we aren't able
to verify is the firmware.

\[MR. HASTINGS:\] The way this is written, it is written in a fashion
that it includes firmware. So a lot of times what you will see is that
this file needs to be on the system. So it has to be a device that you
can query and find is a given file there. The way this is written, it
actually says that you can do it by a file system path name or by memory
address location, which is probably what would happen in the case of a
firmware situation.

\[QUESTIONER:\] Okay, so I have an individual precinct-based optical
scan device. They've verified that the version I have matches the
version that is certified. Will I be able to do that?

\[MR. HASTINGS:\] That is the goal of this requirement, to make sure
that you can tell what software is on that system, wherever it is
stored, whether it's on a storage device that uses a file system, or if
it's on a prom that doesn't have a file system whatsoever.\
*\[Slide 5\]*

The next requirements relate to looking at election information,
specifically election information that changes over time: basically the
number of ballots cast, the totals for a given contest. This is where
there was a generalization done where it was very specific in previous
guidelines that talked in terms of registers and variables which are
very specific to technologies. Usually registers are associated with
hardware devices and variables are associated with software-type
devices.

So this really just says, election information wherever it's stored,
whatever type of technology that's used to store it, you need to be able
to query it and find out what those are. This is where the zero total
inspections could be done.\
*\[Slide 6\]*

There are other properties that the guidelines have that should be able
to be inspected: the backup power supply level is it fully charged, is
it halfway charged? Cabling connectivity indicator: is my cord plugged
into the wall? There should be some kind of external indicator like a
little LED probably on most of your power supplies; communications and
operational status and on/off indicators for communication devices
inside of the voting device.

The consumables remaining indicator: how much ink do I have left? How
much paper do I have left? How much other consumables of the system?
Yes.

\[QUESTIONER:\] Some issues that we experience, and I don't know if it
wasn't thought about in the first set of standards, was the electrical
cords. They were too short, meaning we had a difficult time setting up
equipment in certain places at our polling places. So cords: maybe that
should be an issue that you would address for some of the equipment that
needed to be plugged in. It has really caused a lot of grief.

\[MR. HASTINGS:\] Like minimum length?

\[QUESTIONER:\] At schools and libraries, finding plugs, things like
that.

\[MR. HASTINGS:\] I don't think we've looked at that. Just to probe this
a little bit more. Are you looking at like some minimum length of cords
that are supplied with the equipment, like a 25-foot cord or a 10-foot
cord, kind of thing?

\[QUESTIONER:\] Yes.

\[MR. HASTINGS:\] Okay. I don't believe that's in the requirements but--

\[QUESTIONER:\] We were looking for extension cords and then we had
issues with the equipment. They said it's because you used an extension
cord.

\[MR. HASTINGS:\] Ah, that's--

\[QUESTIONER:\] So now it's just you need to test this equipment using
the power strips. In a lot of these places, you don't have the luxury
of--

\[MR. HASTINGS:\] Interesting, interesting. Can we make a note of that?

\[MS. GUTTMAN:\] I already made a note of it.

\[MR. HASTINGS:\] Okay, because that's something we hadn't--

\[QUESTIONER:\] The small cords that we can only use-

\[MR. HASTINGS:\] And then finally, some items that need to be
calibrated such as touch screens and things like that: you should be
able to determine a calibration of those things and be able to adjust
those back into calibration.*\
\[Slide 7\]*

The user documentation requirements require that the manufacturers
supply a model setup inspection process that includes minimally the
items that have been mentioned: software inspection, verification,
registers totals information, storage location totals, that kind of
thing. They are also to provide a model inspection checklist of other
properties that they may deem that they want you to be able to inspect
on the system. That's kind of an open-ended requirement that if they do
provide other properties to be inspected on that system outside of the
ones that are enumerated in the guidelines, they need to provide you
documentation of that. Also, in that documentation, the manufacturers
are to provide the risks related to not performing a given inspection.
So what are your risks if you don't check the integrity of the software?
So that you guys can make a decision on whether you want to use the
process that they have modeled out or put something in place so that you
know what the risks are that need to be mitigated by any procedures that
you create.\
*\[Slide 8\]*

Software installation requirements: these requirements relate to
installing software on voting devices. It also covers access and
modification to configuration files. It uses digital signatures to
provide the ability to authenticate and verify the integrity of the
software. It specifically calls out for using signatures generated by
the NSRL or designated repositories that the EAC may see fit to
designate.

\[QUESTIONER:\] Just a point of clarification, maybe in terminology. The
first bullet talks about the installation of the software on voting
devices which, unless I missed something, what about the voting system
versus a voting device? You have your software that runs your whole
system and in that system, you have the individual devices. So I keep
hearing you interchange the terminology voting system, voting device. So
does this apply to any part of your voting system?

\[MR. HASTINGS:\] Yes.

\[QUESTIONER:\] Like your main programming--

\[MR. HASTINGS:\] Right, and actually I believe the "applies to" field
calls that this is to be applied to programmed devices, so any device in
the voting system that is programmed or that uses software.

\[QUESTIONER:\] Maybe if that had been- versus saying voting devices.
Okay, I understand now.*\
\[Slide 9\]*

\[MR. HASTINGS:\] The software installation shall only be done in the
pre-voting state. I got a comment on this, that pre-voting state if very
specific to a vote capture device. In the models part of the VVSG, they
talk about a vote capture device having these states: pre-voting state,
active state, suspended state, post-voting state. That was put in there
to support early voting.

However, it was brought to our attention that that was very specific to
a vote capture device, but what about- say scanners or tally devices
that don't actually capture votes but use a scanner. We are looking into
that to maybe expanding that state requirement for tabulators that are
used during early voting-type situations.

Only individuals with administrator or central election official roles
can install software, and central election official roles are limited to
election-specific software. The administrator and central election
official roles, those roles are defined in the access control. I'll talk
a little bit more about that when we get there, and we'd like your
feedback on those roles, if those roles are appropriate or not. So I'll
talk about that when we get to access control.*\
\[Slide 10\]*

Digital signature verification of the software has to be done before the
software is installed. An external visible alert if software
installation fails, if that installation function fails, there needs to
be an alert. Software should only be able to be installed using the
procedures, the documented procedures. So if there is another way to
install software on the system, that the vendor has some secret
work-around to do that, they better document that.*\
\[Slide 11\]*

Software installation generates system event log entry. Again, time and
date, software, the version of the software that's installed, the
location of the software, where it's installed, the result of the
digital signature verification and whose signature was verified is also
part of that. Go ahead.

\[QUESTIONER:\] If this states- when you are talking about software,
does this apply to initial installation or upgrades, or would this be
the load of the election-specific tables?

\[MR. HASTINGS:\] This is for everything. This is from the ground up.

> \[QUESTIONER:\] So for each election, it would be done?

\[MR. HASTINGS:\] For the pieces of software that you are putting on- So
let's say you have a baseline system and you only change the
configuration files. You probably would just install the configuration
files over the old ones, and you could do the digital signature
verifications on that.

\[QUESTIONER:\] There again, this falls into an area of the election
official's duties that we are putting into the standards, right? Or is
this just what has to go into the manuals they prepare? I guess I- We
are running into the experience again-

\[MR. HASTINGS:\] In the way this specific requirement is stated in the
document, I believe, says something to the effect that software
installation programs have to check the digital signature of software
before it is installed on the system. So it's the application that you
are using to install that software that's going to check the digital
signature.*\
\[Slide 12\]*

Back to what gets logged as a result of software installation: name,
version, location, digital signature. As part of the technical data
package, manufacturers need to supply the list of all software to be put
on the voting system including name and version, type of software, any
associated software documentation that's available with it, contact
information for the manufacturer of that software, the location of where
that software is to be installed on the voting system or voting device,
and the functionality provided by the software, and dependencies and
interactions between the different pieces of software on that voting
device.\
*\[Slide 13\]*

As far as user documentation: again, a list of all software to be
installed on the voting system including software files or configuration
files specific to elections and the hardware and software required to
install the software.\
*\[Slide 14\]*

In addition, the manufacturer needs to provide procedures to perform
software installation, and as a result of those procedures, no compiler
should be installed on the voting system. It should talk about how the
COTS can be procured through other mechanisms on the open market, not
just through the voting system vendor itself; how to create a baseline
binary image in order to do replication across the voting systems;
preparation of erasable media; how software on unalterable media such as
CDs is used to do software installation; and the types of information
that should be recorded as a result of the installation process.
*\[Slide 15\]*

So the next set of requirements relates to access control and, like I
said, these really relate to the management of three basic elements: the
management of identification, authentication, and authorization on the
voting system. Access control supports the ability to have users be
accountable for their actions as well as to allow for limitations on
uses of resources. And these access controls apply not only to
individuals but also to applications and processes on a system. So on
this computer, this is not a single process computer. There are probably
at least twenty applications going on at the same time. So that's why we
talk about applications and processes. You want to control their ability
to do certain things.\
*\[Slide 16\]*

So management of identification information: you want to be able to
create and disable identities or roles that are created. The guidelines
require that after a certain number of failed attempts, which is a
configurable number, a lockout for that account would occur. In
addition, there is a requirement for the length of lockout. It could be
indefinite. It could be a lockout for ten minutes. So those are two
configurable aspects of locking out given identities or roles.*\
\[Slide 17\]*

Role identification is required for voting devices as well as election
management systems. And the roles specified in the access control
section include the voter, election judge, poll worker, central election
official, and administrator. When we talk about administrator here, we
are talking about an administrator of the voting device- the
administrator of the device and not administrator in terms of
administering of an election-type situation.

Role identification is required by a voting device in election
management systems and individual identification; identifying that
Nelson Hastings is on this system is required by election management
systems.

Notice- one is for both voting devices and election management systems,
and one is only for election management systems. The reason identity-
individual identification, only applies to election management systems
is acknowledgment that some voting devices may not have the capability
to support identity-based authentication or identification.\
*\[Slide 18\]*

Authentication information management: setting and changing
authentication information, protecting the authentication data by the
system, and password management. So password management includes reuse
of passwords, the expiration of passwords after a given amount of time,
and the strength of the passwords. You know, you don't want to use a
dictionary word or that kind of thing.*\
\[Slide 19\]*

Authentication requirements by roles: so this part of the guidelines
talks about the minimum required authentication that's required for a
specific role. Voters are actually handled in Section 7.5.1 where the
issuance of voting credential and ballot activation is. John talked
about that previously.

Poll workers, there is no minimum in the guidelines at this point.
Basically we couldn't figure out what type of action that the poll
worker would be doing to the voting system that would require them to be
logged onto the system. Election judge and central election officials do
authentication by something you know such as a user name or password.
Administrators need to do multi-factor authentication. An example I gave
was smart card and biometric. It could be smart card and pin number or
pass phrase as well. And applications or processes need to use
cryptographic techniques because they are in the digital world in the
form of digital signatures.*\
\[Slide 20\]*

Authorization management: you can limit authorization based on the
voting state, like in pre-voting, the time interval, or a specific time
action can take place. The requirements also require support for being
able to have two-person control- require two people to authenticate
before a given action is done. Being able to separate duties- you don't
want to have only one role that does everything on that voting system;
limitation of resources based on function and type of data; and to
explicitly indicate that a person or process is allowed or disallowed to
do an action or access a given piece of data.*\
\[Slide 21\]*

The technical data package requirements are descriptions and
specifications of the access control mechanisms used by the voting
device, descriptions and specifications of what voting system mechanisms
rely on those access controls. So the first one is what kind of access
control mechanism am I using? Am I using user name and password? Am I
using smart card?

The next requirement basically says: so, given that I'm using these
types of access control mechanisms, where are those applied to perform
voting functions?

And then mapping of voting system operations to default roles with the
permissions to perform those: so there should be some- a way to set it
up so that it's not everybody automatically gets all access to
everything just because their account is created or their identity is
created on the system.*\
\[Slide 22\]*

The user documentation for access control includes instructions for
implementing, configuring, and managing the access control mechanisms
that are supported by the voting device. Model access control policies:
the manufacturer should supply how he envisions his voting system access
control mechanisms to be used on the system and templates or
instructions for how to customize the access control policies on that
system, and disclosure of all default privileged roles.\
*\[Slide 23\]*

\[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.