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

Agenda:

Administrative Updates:

Summary of October 7^th Meeting

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:

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.