Security and Transparency Subcommittee (STS) Teleconference

Tuesday, October 17, 2006

Participants: Alicia Clay, Allan Eustis, Barbara Guttman, Bill Burr, David Flater, David Wagner, Rene Peralta, Helen Purcell, John Kelsey, John Wack, Nelson Hastings, Patrick Gannon, Quin Dang, Ron Rivest, Wendy Havins


1) Administrative Updates

2) Summary of October 7th administrative meeting

3) Discussion of proposal for voting system key management

4) Other Items

5) Next call Tuesday, October 31, 2006 at 10:30AM.

Administrative Updates:

  • Allan: Welcome to David Wagner (STS) who is now officially part of the TGDC, as well as the other three new members: Philip Pearce (CRT), Tricia Mason (HFP), and Paul Miller (CRT). We are setting up an orientation teleconference, hopefully before the  end of October.

  • Allan: Reminder, the next plenary session of the TGDC is December 4 and 5, 2006  here at NIST. A letter will be sent shortly  to Committee members so that travel plans can be made. Also available for anyone who can not attend will be teleconferencing capabilities and webcasting. Schedule (preliminary): Reception on Dec. 3, (7 pm).  9:00 a.m. start on Dec. 4 (finish 5:30 pm), and 8:30-2:00 on Dec. 5.

  • John W: EAC agreed that for the VVSG 07, voting systems should not have wireless capabilities. Using IR to read valid activation token is not a bad idea, since smart cards wear out. There is an ITAA  vendor meeting on Friday, John will question them about e-poll book usage. [Ron questioned whether the e-poll books should be in the scope of the committee.] John wil  write position piece on issues and decisions on e-poll books to vent with other subcommittees and EAC.

Summary of October 7th Meeting

  • Alicia Clay took notes for meeting  minutes. A lot of good work at the meeting. Final notes will be sent to STS.

  • Group came to an agreement on the revised outline for the security related topics for the VVSG 07,it will be circulated for comment. The basic idea is to start with a security and audit architecture overview, talking about threat and securing the systems; then profile specific security and audit functional overviews (testable requirements), broken out into software independent voting systems and software dependent voting systems. The next section is profile independent tactical security requirements (where the bulk of the material from the original outline will go). Last will be a section on end-to-end verifiable voting systems, starting with an overview of principles behind how each system works. The last section will different in that instead of just testable requirements, it will start with submission requirements. An electronic copy of the outline will be available shortly.

  • General comments on the security component.

  • Documentation requirements: Need a decision about what should be in  public test package and what shouldn't; how we could make these test packages support  good procedures. Make sure we get requirements from the labs to get their understanding of how security works to ensure that they look at the details of the system.

  • Decided to require FIPS 140-2, Validated Hardware Crypto models for certain functions - for all digital signatures.

  • Also considering having two kinds of keys for every voting machine - one permanent key and one changed for every election.

  • Received an verview on open-ended vulnerability testing.

  • IDV: General ideas for IDV systems that will be presented in VVSG 07 and coming up with a position paper on why we were not discussing detailed requirements for stand-alone DREs in VVSG 07.

  • Someone needs to update the working outline on the web. The revised outline from the meeting is written at a high level.

Discussion of proposal for voting system key management

Proposal from Bill Burr on key management and crypto models.

The module uses or generates the following data elements:

  • Module serial number - a unique serial number for the module, created by the module manufacturer, and stored in the module. The module serial number can be read from the module.

  • Module key - a signature key pair generated once by the module during module initialization and never changed during the life of the module. This key is used to sign election keys and election closeout records. The device private key is never exported from the module.

  • Module certificate - a public key certificate, issued by the entity that initialized the module, binding the module serial number and the module key.

  • Election key - a signature key pair generated by the module for each election; the election private key is never exported from the module and is zero'd by the process that generates the election closeout certificate; thereafter that election private key no longer exists. {the election key may also be used to sign some kind of initial system configuration record, and other kinds of logged transactions}

  • Election counter - a running count of the number of election keys generated by the module

  • Election signature counter - a count of the number of signature operations performed by the current election key.

  • Election certificate - A public key certificate signed by the module key, that certifies an election key. The election key is generated at the start of the election certificate generation process and the election certificate is exported from the module after it is generated.

  • Election closeout certificate - A certificate signed by the election key that is created at the conclusion of and election. The election closeout process creates this certificate, then increments the election counter and zeroizes election private key before outputting the election closeout certificate.

David Wagner points out that we haven't dealt accurately with the threats that this is intended to meet. That's because Bill thought the overall threat discussion belonged a level above this proposal.

How much overall responsibility is the crypto module and how much is the machine that houses it and the overall structure? The write-up was written to apply to a whole family of voting machines.

Suggestion from David Wagner: Append a nonce  to each signature. That implies that the whole record to be signed into the crypto module and let it generate the hash with the random number and sign the whole quantity. This would encapsulate more of the security protections in the crypto module.

David Wagner's comments, which were shared among the STS subcommittee were discussed.

David W: This is a good idea. A lot of our machines depend on use procedures and physical security handling procedures to ensure chain of custody and this would help reduce the amount of dependence on that.

On the spectrum between specifying requirements and specifying a particular design this may reduce flexibility if we standardize on this one particular scheme.  [Ron feels that for crypto, we may want to be more specific on the performance requirements than the design requirements, although it's very hard to get the crypto designs right.]  While performance requirements are better, they are harder to write and much harder to test. While we're building, we should use design requirements.

Hopes that exact formal specifications for the bits that the crypto module generates should be standardized.

Threat models - missing a clear statement to what the threat model you're trying to defend against and what are the security goals that you are trying to guarantee.  There's a broad level of ambition, it needs to be thought through clearly.  This scheme will defend against some, not other, so we need to know what we're trying to defend against.  Once we have electronic records and electronic signatures, this should be an easily solved problem.  No matter what else we do, we need to solve threats one and two, to make sure the records are safe from the time they leave the voting machine til they’re reported in the final total.  This would get us closer to a requirement oriented spec, the requirement being that the mechanism needs to defeat all those threats.  [Ron noted that the draft did not say anything about verifying signatures -- that needs to be clarified.]  [John K to send out a paper which covers this topic.]

These threats s should be in a suitable format for web posting should laws and other considerations allow it; trying to push for a publication in general is outside our mandate.

Question about requirement to export electronic cast vote records in some form of interoperable format, we've talked about EML; if they're signed, is there any way to do that and preserve the validity of the signature?  Yes.  Should we standardize, it would be simpler?

The format of all the data signed should be disclosed by the vendor.  We could say that vendors had to use a defined interoperable format.  Or the specs could be published in specific detail so that someone could re-implement something to parse those records to understand what they mean, and one way is to have the vendor provide a translator from their internal format to EML.

John Kelsey is to send questions to Patrick Gannon in regards to what specifically we can do with EML.  Patrick will forward and to elections committee that worked on EML and get back to John.

In addition for the cast vote records, format for audit log information plus zero tape and summary tape contents should be signed.  All information coming out of the voting machine to produce an audit should be in a public format – you should not have to use vendor software to audit vendor software.

A certificate chain  (of custody) needs to be incorporated and checkable because the machine will be signing off on the election key and the election key is signing off on the records.

Question to David about whether all the information in the proposal is good, but maybe it need to be a "should" requirement.  One argument for this being a "should" is that this isn't necessary for the security of the machine - it would improve it by reducing the dependence on the chain of custody and physical security.

Our goal in VVSG 07 is to have a set of minimum requirements -- and those should be “shalls”.

All we can say is how the equipment shall be built – we can not tell election officials how to run their elections.

Signatures provide a security measure when used on both paper and electronic because there is s a check factor between the two.  Digital signatures are a low cost added security feature.  [Ron want to push for digital signature and signature verification.]

Should be push for signatures to be a “should” in hardware?  Protection should be on the signing key.  Without putting the hardware security there, it would be too easy for them to be compromised.  We have a patches issues, any software that's put on the machines should be signed as well.

This should be discussed further via email and then debate again about shoulds and shalls.

Should we append a random number to each signature?  It should be provided at the hardware level. 

Next meeting Tuesday, October 24, 2006 at 10:30 a.m.

Teleconferences from 2004, 2005, 2006 and upcoming in 2006.


Link to NIST HAVA Page

Last updated: July 25, 2007
Point of Contact

Privacy policy / security notice / accessibility statement
Disclaimer / FOIA
NIST is an agency of the U.S. Commerce Department