VVSG Tutorial Narration[^1]

VVSG Overview Part 4

*\[Slide 1\]*

\[NARRATOR:\] The following presentation is the fourth and final part of
the next Voluntary Voting System Guidelines Overview Training Module.
Each of the four parts reviews a different section of the VVSG
guidelines document in layman's language. The overviews include question
and answer sessions with members of the Election Assistance Commission's
Board of Advisors and Standards Board.

\[MR. WACK:\] Okay, actually the word is 'Integratability,' which has a
connotation of interoperability, but not quite. Okay, what I'm talking
about just briefly is a relatively small section in chapter six of part
one, 6.6, Integratability and Data Export.

*\[Slide 2\]*

And the slide I have here basically says it all, in some respects that
we want voting devices that compose a voting system to, as much as
possible, work together using standard mechanisms.

We aren't demanding, we don't have 'shall' requirements in the VVSG that
interfaces and equipment be interoperable, but it should not take a
whole lot of effort for different types of devices to work together,
even if from different vendors, and then the data export issue, voting
devices eventually put out records in common formats just so that things
in the long run will be easier to use. So I'll talk about
integratability first of all.

*\[Slide 3\]*

There is one requirement in that section, a sub-requirement that
basically lays out that the devices have to have common hardware
interfaces, you know, essentially. Obvious example, USB, and I would say
really the goal there is that down the road, we want the capability for-
let's say if a vendor produces an audit device that could be attached to
a particular type of voting system, to make that possible in the area of
accessibility.

There are various devices that are becoming more readily available. It
would be nice if different vendors could produce these sorts of devices
and essentially be able to have them added into systems without running
into a situation in which it's just entirely incompatible and a whole
lot of work needs to be done, in fact so much work that it's
prohibitive. So that is in essence the goal there.

And so we talked about the high-level goal for integratability, the
high-level requirement for integratability this morning as an example of
a goal-oriented requirement, so it's something that's a goal that's not
exactly required right now.

*\[Slide 4\]*

And then in common data export, the goals here essentially are that
voting system records be in a common format and eventually while there
are a variety of reasons why that would be useful, we've actually heard
this from a number of election officials throughout the past couple of
years, that it would be a good thing if records from different types of
devices could be more easily aggregated, and the direction in industry
pretty much is to start using formats that are interoperable or could be
made interoperable such as XML.

You've all probably clicked on the source of a HTML page and seen HTML
which is quite similar to XML, and that if voting device records were in
a common format such as this, they could be more easily analyzed, read,
and people could develop their own software, you know, and not
necessarily rely on the vendor.

*\[Slide 5\]*

It affects all voting devices, therefore we're talking about all voting
devices need to produce records in this sort of format, and it must be a
freely available format. There can't be restrictions on the use.

*\[Slide 6\]*

Vendors shall provide a source code example of how to actually read the
records and manipulate them.

*\[Slide 7\]*

And there are some 'should' requirements in there. In essence, vendors
should use the same format across all their devices, you know, one
particular vendor that produces op scan equipment and VVPAT equipment,
you would generally want them to use the same format with both devices.

And then another 'should' requirement in there basically makes the point
of saying that it would be best if voting vendors in general all used
the same format. Therefore if a state, let's say down the road, would
want to analyze all its election records regardless of device, they
would be in the same general format, and could be analyzed more or less
by the same general software.

*\[Slide 8\]*

Any questions on that? Yes, please.

\[QUESTIONER:\] Why not go ahead and set that standard now so that it is
in place?

\[MR. WACK:\] The question was, why is that a 'should' instead of a
'shall' requirement, and basically there isn't a consensus yet on what
format would be best to use, what particular format. There are two under
development right now, EML, and there's an IEEE working group analyzing
formats, and at this particular point, we didn't think it was ready to
require one of those formats.

I think neither of the formats actually, if I'm right, I don't want to
speak about something I'm not- but if I'm right, I think neither format
has actually been used and tested in the United States at this
particular point, so it's just not ready, but it may be over the course
of the public review. Over the next two years, this requirement could
change from a 'should' to a 'shall.'

*\[Slide 9\]*

So, I am going to go to chapter seven, section 5.1, and that's on voter
credentials and ballot activation. And I'll give you a chance to look
for that if you want to and give myself a chance to track it down too.

And this section, it was basically an expansion on earlier requirements
for ballot activation, and now it contains requirements for electronic
pollbooks.

We were approached by the EAC at one point along the process to see
about adding requirements for e-pollbooks into the VVSG.

As you know, a number of vendors are starting producing them and selling
them. There weren't specific requirements as to their construction, so
on and so forth, and it would be good if, as part of the voting system,
they actually get tested and the meeting of reliability requirements and
things of that sort.

So here is where some of the requirements are.

*\[Slide 10\]*

And ballot activation turned out to be not the best term to talk about
all the things that go on in this general area.

An e-pollbook really doesn't necessarily do ballot activation. It
actually issues, in a sense, credentials. It write credentials to some
sort of a token, and then that token gets placed into a vote capture
device, an VVPAT system or whatever, and that's where ballot activation
occurs, so that's how we laid that out.

Ballot configuration here as opposed to ballot style, we have called
basically the raw set of contests, the groups of voters that are
eligible to vote, that all the democrats- the democrat contest in an
election, is ballot configuration.

Ballot style is actually the concrete presentation of the ballot
configuration plus any other formatting into how the ballot actually
looks as displayed to the voter.

*\[Slide 11\]*

So basically we have very commonsense requirements in there for basic
aspects of ballot activation and credential issuance, and DREs, some of
them can serve right now as activation devices. They can actually be put
into a mode. Before an election, you could take 30 smart cards, for
example, and write ballot activation codes to them and have them ready.

So that is still permitted by the VVSG. Obviously, when you program a
smart card or a token or what have you, you only want to allow at most
casting one ballot.

*\[Slide 12\]*

Now secrecy of the ballot, that became a bigger issue here. An
e-pollbook probably really doesn't implement anything that can't be done
manually, so the problem has been there all along, but once you have
electronic devices that can create electronic records, they can be
around for a lot longer.

And the fact of the matter is, you know, I've worked as a poll worker,
as a check-in judge, and electronic pollbooks seem to have quite a large
amount of information potentially about voters, and if care isn't taken,
you could pretty much identify and link each voters identity with their
cast ballot, so there are a number of requirements in there just
basically governing privacy.

The picture up there shows two people with the same grocery basket and
that's really- you know, you can say the person on the left is a valid
activation device, and the person on the right is a DRE, and their
records can't be combined.

They can't separately create records that, let's say, safeguard voter
privacy, but when you combine the records and aggregate them, you still
cannot violate voter privacy, so basically that sort of situation is
denied.

We've got the problem of provisional voting, though on a DRE where you
in fact do have to be able to link the voters identify to the
provisional ballot, so there has to be an exception made for provisional
voting in that case.

*\[Slide 13\]*

Some requirements are in there on what sorts of things actually get
written to tokens and how tokens ought to be used. I talked a little bit
about that earlier in the day. What I want to illustrate really with my
three red bullets, there is that, what we want is a situation in which
let's say, if a token is put into a DRE, the DRE is then able to verify
that the information on the token hasn't been changed in transit, and
that it actually came from the appropriate authorized ballot activation
device. And there are a variety of different ways of creating this trust
relationship, some fairly simple, some more complicated.

*\[Slide 14\]*

And connection to remote voter registration databases, the TGDC debated
this quite a bit, and I think initially a STS number of people did not
want to permit this, because really what you're doing there at that
particular point, is you're introducing potentially Internet
connectivity to a voting device, and the way we have voting system
defined in the VVSG, it includes the ballot activation device. You're
introducing, you know, a potential Internet connection in that way, and
there are all sorts of threats and risks and complications, and things
of that sort.

Ultimately, though, I think the TGDC decided that it was still a good
idea or more advantageous to actually permit this kind of connectivity
with certain types of restrictions on it.

*\[Slide 15\]*

So therefore there has to be some sort of a firewall.

A couple of other requirements there on making sure that the external
connectivity, if it's enabled, it's visible to the poll worker, it has
to be something that an authorized official can turn on, turn off,
things of that sort.

I don't think the requirements in there really are much different from
the way in which probably many of you implement your home LANS, if you
have a home wireless LAN, for example. A lot of the wireless routers
have a firewall built into them, and we're talking about the same sort
of things.

*\[Slide 16\]*

Any questions that I can answer? Yes, please.

\[QUESTIONER:\] Yes, a clarification, what do you mean by a remote voter
registration database?

\[MR. WACK:\] A statewide voter registration database, and I'm talking
about a situation in which a polling site would have electronic
pollbooks actually linked up live to the database, as opposed to having
a complete copy of the database loaded on each electronic pollbook.

In Maryland, for example, where I come from, we all had copies of the
statewide voter registration database on each pollbook. My understanding
is that a number of states are moving towards perhaps doing that as a
backup mechanism but actually have a live connection out to the
statewide voter registration database.

\[QUESTIONER:\] It's not the database that is remote, it's the
connection that is remote.

\[MR. WACK:\] Well, yeah, a connection to a database that is remote from
the polling site.

\[QUESTIONER:\] Now for early voting, we need to be connected up to that
database.

\[MR. WACK:\] A comment that for early voting- they actually need to be
connected up to that statewide voter registration database.

\[QUESTIONER:\] I completely agree with Larry, but you can have access
to that database without using a ballot activation device to gain that
access.

\[MR. WACK:\] Okay, the comment is she agrees with Larry on that issue,
but you don't necessarily have to have a ballot activation device as the
device that is hooked. It could potentially be another device.

\[QUESTIONER:\] Either way, you still have to get that set of data into
the alternative polling place.

\[MR. WACK:\] Yeah, I think actually this was something that the TGDC
discussed initially. When some people were against actually enabling the
remote connectivity, there was a possibility of let's say some sort of
electronic pollbook having the connectivity, and then you could note
basically what sort of ballot the voter ought to have and have someone
with perhaps like a handheld smart card encoder typing that in.

But then a number of people commented that that would be a major
bottleneck and would significantly slow things down, and it would just
be a lot easier if the activation device would also program the token.

\[QUESTIONER:\] It's more than just the speed. The whole reason we went
to the database and activating the card was to eliminate that person
having to type it in.

\[MR. WACK:\] Yeah, Larry makes another good point too, that- and that
was brought up by the TGDC, that in manually programming the tokens,
people make errors so having the equipment could reduce that.

One other question?

\[QUESTIONER:\] In the bigger picture, a comment I guess, and maybe this
is better directed toward the EAC. I am struggling a little bit with the
concept of including these requirements in the VVSG in the first place,
because the VVSG is really about tally systems, and this is not about
tallying votes. This is a separate process that is separate from the
tallying of the votes. If we are going to get into writing standards for
these (pollbooks), then in the future are we going to have standards for
our statewide databases as well down the line in the VVSG?

\[MR. WACK:\] So the comment, I believe, is not understanding why these
requirements need to be in the VVSG. The VVSG ought to be for tallying
systems, and I guess both capture systems, and there's some concern that
this will lead eventually to the VVSG having requirements for a
statewide voter registration databases.

\[QUESTIONER:\] Some of them do have vote records from the voter
registration database to the vote capture device. So we really are using
them.

\[MR. WACK:\] Paul Miller?

\[QUESTIONER:\] We were having some of this discussion on the TGDC, and
one of the points mentioned was that we were only going to focus just on
those issues where it related to a vulnerability that could be
introduced into the tabulation process. The sole purpose of having these
requirements was to ensure that we were not introducing vulnerabilities
into the tabulation process.

\[MR. WACK:\] Do I need to repeat that? Did everyone hear that comment?

Okay, well, basically Paul made the comment that the TGDC introduced
this basically for the sole reason of addressing threats that could be
introduced into the tallying process. Doug.

\[QUESTIONER:\] We learned our lesson. We started out trying to apply a
post-election management system first, and we discovered that they were
taking correctly tallied votes but reporting them incorrectly. It became
apparent then that we had to include this in election management. This
is just another one of those things that if it can be impacted, it
probably needs to be in here somewhere.

\[MR. WACK:\] Wendy.

\[QUESTIONER:\] I just wanted to get some clarification. There is one
voting system where the same device is used to open the polls, to
activate a ballot for the voter in conjunction with the judge, and to
close the polls and collect the votes for reporting purposes. As I read
that, it would no longer be possible under this.

\[MR. WACK:\] Well, I believe I know the device you're talking about,
and I think the question might be if you have a ballot activation device
that is already networked to your DRE, your VVPATs, your vote capture
devices, do we allow that ballot activation device to also be connected
remotely? The answer is no because at that particular point, then you do
have the possibility of the Internet being connected up through the
ballot activation device to the vote capture device, and there are some
other-

\[QUESTIONER:\] No, I'm not talking about that. What I'm talking about,
it's the same little device that opens the polls, activates the voters,
closes the polls, collects the votes on that device, and is brought in
for reporting purposes.

Now the activation process is a little different than the one you are
familiar with. It's certainly in here that you have a prohibition. You
say the vote activation device can only be used for that. And that's
what I'm saying. I realize a lot of this activation stuff came to be
written with the electronic pollbook in mind, but again, this may be one
of those situations where it's written with the electronic pollbook in
mind but applies to other situations.

*\[Slide 17\]*

\[MR. WACK:\] Could you read out loud the requirement in question, what
number that is?

\[QUESTIONER:\] It's talking about activation device and token limited
in capacity. The token should have the capacity to contain only the
information sufficient to activate the ballot. Now this particular
device on one of the systems has the information to load all of the
ballots in the morning. Everything is done in this particular device.
The requirement is 7.5.1.3 and A.1.

\[MR. WACK:\] It's the 'should' requirement, the token or the smart card
should have the capacity to contain only the information-

\[QUESTIONER:\] The sole purpose and use of the ballot activation
credentials and token shall be for the purpose of activating the ballot.
And again, I highlighted these when I was not sure if they were
'shoulds' or 'shalls.'

\[MR. WACK:\] Well, the 'should' requirement was included basically to
reduce the bandwidth so to speak, viruses, what have you, that could be
transmitted from, let's say, an activation device to a vote capture
device.

In other words, and I mentioned this, this morning, that a smart card
that's potentially a gigabyte- well smart cards don't go up to that, but
a smart card with a lot of space isn't necessarily needed for ballot
activation. The amount of information on the smart card is relatively
small. For security purposes, it's best to use devices that are
specifically suited to what needs to be done but it's a 'should'
requirement though.

\[QUESTIONER:\] No, but the parent requirement is a 'shall.' The sole
use and purpose of the ballot activation credentials and tokens shall be
for the purposes of activating the ballot.

\[MR. WACK:\] So the smart card itself-

\[QUESTIONER:\] They call it a PEB. It opens the polls; it activates the
ballot for a voter; it closes the polls; it collects the data; it's
brought in.

\[MR. WACK:\] Oh, I understand. I think the intent of that requirement
basically was to avoid a situation in which you might have a smart card
being used for ballot activation and also being used for other purposes,
could possibly contain authentication data to be used for access to
administrative capabilities or things of that sort, and a PEB-

\[QUESTIONER:\] You can use that same device. I can get on and zero the
totals with that same little cartridge.

\[MR. WACK:\] Okay, this is something that bears more looking into. Yes.

\[QUESTIONER:\] I use that same system. PEB is another acronym for
personal electronic ballot. You use a master PEB to open polls and print
off a zero results tape showing that there are no votes in the machine.
It's like looking at a ballot box with no ballots in there. You use the
master PEB to open polls on each machine and print off that zero tape. I
then give the poll workers two other PEBs to activate the machine, two
separate PEBs called supervisor PEBs. They are the same as the master
PEB, but the master PEB stays in the security bag during the day. Then
that night after seven o'clock, the poll worker gets the master out of
the bag, closes the polls, prints off a results tape that is wrapped
around the master. All the supervisor PEBs and the master are brought
back to my office.

\[MR. WACK:\] So the PEB used for activating the ballot is not the same
PEB used for...

\[QUESTIONER:\] It's not the same PEB used to open polls because if you
try to use that Supervisor's PEB to open and close the polls, it's going
to say this wasn't used to open the polls, do you want to go ahead and
proceed? So I use that master, and yes, they are the same, but I use
that master to start off with, and it's marked that way, and I use it to
close the polls at the end of the day.

\[QUESTIONER:\] Isn't that the way you also close the voting stations?

\[QUESTIONER:\] Yes, exactly. Put in the flash card modem and that
particular PEB master and supervisor has got that one or two or five
ballots. It doesn't make any difference what that polling place may
have. It may have five individual ballots on it.

\[QUESTIONER:\] With any one of those PEBs, you can get into the
terminal functions whether it is a master or not.

\[QUESTIONER:\] But to keep track of them though, I put master on one
PEB and supervisor on two of them, just for the fact that if the poll
workers get busy, they have two supervisor PEBs working during the day.

\[MR. WACK:\] Okay, that's useful information.

\[QUESTIONER:\] We've done that with four elections now, and it's worked
great.

*\[Slide 18\]*

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