Problem (was: Re: need help with tool requirement)

[bmcculley at rcn.com]

Here's the real problem description.

Electronic voting machines are feared to be vulnerable to
hidden malicious code ("Easter eggs") that could subvert voter
intentions and deliver votes to the wrong candidates.  One
proposed solution is to require paper ballots be produced by
electronic voting machines, but this creates other problems. 
There is also a practical constraint that retrofitting
existing systems for paper output will not be feasible in the
timeframe required for the upcoming election, for a variety of
reasons (simple installed base logistics among them).  Thus
there is a strong desire and motivation to be able to validate
the software for systems that are already in the field (it is
an acceptable constraint to require updating deployed systems
to a new validated software version).

It seems that the ideal solution would allow retrospective as
well as prospective validation (i.e. validate copies of
software obtained from deployed systems as well as validating
pre-release software).  For one thing this could be a strong
anti-fraud deterrent.  This is not an absolute requirement
however.

As an alternative, assume that source code is available for
review and compilation.  Since the code is proprietary it will
 need to be handled according to NDAs, which seems not a
serious restriction.  

What approach would provide sufficient assurance that the code
does not contain any "Easter eggs" or trap doors to allow
future egg-laying?

THANKS!

-lbm