(Fwd) Additional comments on Boulder County RFP #4717-06 for election system

[Neal McBurnett <neal@xxxxxxxxxxxxxxxxx>]

FYI

----- Forwarded message from Neal McBurnett <neal@xxxxxxxxxxxxxxxxx> -----

From: Neal McBurnett <neal@xxxxxxxxxxxxxxxxx>
To: Josh Liss <jliss@xxxxxxxxxxxxxxxx>,
	Linda Salas <lsalas@xxxxxxxxxxxxxxxx>
Cc: Boulder County Commissioners <commissioners@xxxxxxxxxxxxxxxx>
Subject: Additional comments on Boulder County RFP #4717-06 for election system

I submitted comments at
 http://www.co.boulder.co.us/clerk/elections/RFP/471706.htm 
 
but that form is badly designed and completely destroyed all 
formatting.  Please accept this form of my input instead.
 
These comments are in addition to my comments submitted
2005-12-28.

Thank you for the opportunity to comment,

Neal McBurnett                 http://bcn.boulder.co.us/~neal/

page 9, section 3.18: VVPAT for use only in recount or redundant check

Use the language from Colorado law, the required "Random audit", not
"redundant check".  The audits required under CO law aren't
redundant!!  And the CO SoS rules need to be updated to comply with
the law.

> 3.22 Equipment. Vendor shall provide pricing for a minimum of one
> (1) DRE and one (1) optical or digital scanner, together with
> software and equipment, at each of the 235 polling places.

The Clerk should ask for and give preference to bids on ballot markers
and manual voting and other alternatives to DREs.

page 9, section 3.18: VVPAT for use only in recount or redundant check

Use the language from Colorado law, the required "Random audit", not
"redundant check".  The audits required under CO law aren't
redundant!!  And the CO SoS rules need to be updated to comply with
the law.

> 4.6.4(c) The vendor's responses to this question should be included
> in a completely separate section of the proposal labeled "SYSTEM
> SECURITY INFORMATION: CONFIDENTIAL." To the extent permitted under
> Colorado State Law and consistent with sound information system
> security practices, Boulder County shall refrain from releasing the
> responses to this requirement as public information.

This requirement covers much too broad a set of responses.  Surely
the public should know what the vendor promisses in regards to
security.  E.g. this information is to be withheld:

> The specific training and certification of members of the vendor's
> proposed team in the areas of information system security and
> business continuity planning.

The Clerk is endorsing the misguided notion of "Security through
Obscurity". I.e. some people think the systems should be designed in
secret, and hidden from as many people as possible. But decades of
cryptography research has led to state-of-the-art systems in which the
design and code can be public and only the keys need to be kept a
secret.

Learn from the success of the most widely-used and most secure
software systems, which not only have an open design, but open source
code as well, like the Apache web server and the OPENSSL cryptography
library.

Allowing vendors to hide their dirty laundry from the public and the
best experts, and only share bits of it with inexperienced customers
one-by-one, is a recipe for insecurity.

Rather than relying on bureaucratic software development methodologies,
require the vendor to provide independent tiger team reports in which
experts with inside information attempt to break into the system.
Remember that among the greatest security risks are attacks from
the inside - from the vendor and from election officials

In addition the Clerk should retain independent security experts to
audit the elections, not rely on the vendors or elections staff.

> The proposals shall provide a statement whether any election
> jurisdiction has used the digitally signed software versions to
> compare against versions installed in the election jurisdiction for
> production use.

What is necessary is a completely independent build of the software,
using independently-installed software compilers, etc.

> Vendors' proposals shall contain a list of all election
> jurisdictions that have conducted security risk assessments,
> security management assessments, or source code security reviews of
> the vendors' proposed voting systems or their components. The list
> shall include reviews conducted by election jurisdictions, whether
> by internal election staff or by independent third-party agents.

This should not be limited to assessments from election jurisdictions.
Some of the best input to date has come from independent experts.

> 5.1. Consolidated Election testing. Any proposal submitted must
> contain a provision for providing the Clerk with sufficient
> equipment, software and other components to allow the Clerk to
> utilize the equipment in any elections that occur prior to delivery
> of equipment.

How would the clerk utilize the equipment in elections before the
delivery of equipment?

Page 31 "3. Describe your company's policy relating to source code"

The clerk should instead establish a preference for fully disclosed
software, as discussed at

 http://bcn.boulder.co.us/~neal/elections/disclosure.html

Also, include a question like this:

 If Rep. Holt's bill HR 550 was passed, would your company have the
 necessary rights to all the software used by the system (including
 any required third-party software) to disclose the necessary source
 code, or do you rely on code that you can't disclose or audit
 yourselves?

> Does the machine encrypt votes, both internally and on the removable
> media? What

Describe procedures to ensure the security of the encryption and
authentication keys, including key generation and key management
procedures and random number generation procedures.

page 8, section 3.12
> Any proposed system must address the issue of wireless transmission
> of voting results from the individual polling places to the Clerk s
> central location.

We should require that any hardware capable of doing this sort of
thing be clearly physically removed or disabled, so that rogue
software can't leak votes or other sensitive information.

> Additionally, any proposed system must be capable of a wire- based
> transmission of results from the polling places to the central
> location.

As noted in NIST presentations to the EAC's TGDC, since public
telecommunications networks use wireless links all the time, this is
essentially impossible.  Results should be hand-delivered to
the counting machines.

> page 8, section 3.9 and page 11, 4.4: new system expected to be
> compatible with existing system used in November 2004

Hart has not released enough information to allow others to be
compliant with their ballots.  This puts ballot-marking devices at a
severe disadvantage.  But they are what we want.  So until Hart
publishes adequate and practical specs, the clerk will need another
way to count them.

> 7.1.2. ... The vendor shall provide all
> training necessary to make the election office staff 100%
> independent of the vendor for election setup, acceptance testing of
> equipment, logic and accuracy testing, and routine systems
> diagnostics, as well as Election Day field support.

Include training for audits of every election and recounts when
necessary.

> 10. Proposal format.

The RFP must require that the vendor responses be in an
easily-accessible, open, searchable format suitable for public posting
on the county web site, copy-and-paste, etc.

Acceptance testing:
> "set out what personnel are responsible for conducting the
> [acceptance] testing,"

Checks and balances and independent verification are critical to
security and confidence and good government, as recognized even by
the "separation of powers" part of our constitution.

So it is troubling to see the Clerk asking the vendor to define not
only how the accuracy and security of the system should be assessed,
but to even define how to determine if the clerk should accept the
system as delivered.

----

----- End forwarded message -----