Re: Transparent Tabulator (take 2)

From: Bob Donner <donner3_at_attglobal_dot_net>
Date: Tue Dec 12 2006 - 22:38:19 CST

Hi Charlie and Ronald,

Thank you for taking the time to review the outline and give me your
feedback,

I agree the topic is best covered in a meeting (or Webex) so a
discussion can take place.

Here are some more details about the idea.

_Processor:_ It is my understanding that the response time of a
tabulator is limited by the mechanical transport of the ballot through
the machine and consequently a low performance/speed processor similar
to a Z80 class processor can be used at a slow clock rate. This will
reduce the data rate significantly to a point such that the data can be
transmitted. Iíll give up speed for transparency.

_Monitoring:_ I am talking about a central tabulator (open source & open
hardware = open system) that processes ballots that are collected from
satellite voting precincts and consequently the ballots are not
associated with an individual. (I am in the group that thinks it is OK
to see ballots as long as the ballot is not associated with an
individual. We can discus this issue also if desired.) I am only
addressing fraud or errors after the ballot are delivered to the central
tabulator. I spent a significant amount of my career designing
microprocessors and monitoring the microprocessor was done during
development/debugging. This is the type of monitoring (sampling the
address, data, control, and status signals once per instruction cycle)
Iím referring to. Yes ďdata diodesĒ are used for isolating the monitor
from the tabulator function. Monitoring/tracing the processor (ex. Z80
type) exposes a wealth of information. An open system will enable a
person to analyze the trace and extract the ballot image data (and
tabulate independently), the instruction sequence (and compare to
expected instruction sequence), monitor actual count totals (via use of
memory map), etc. All of the data in the instruction stream will be
tightly coupled and will be interrelated. The image data will trigger a
predictable instruction response and a predicable increment in vote
totals. This type of analysis was standard practice for me when
developing & verifying microprocessors. If this discussion doesnít
address your concerns about knowing what the processor is doing let me
know and Iíll add more. I donít consider this to be a major SW effort
since I had to write code on the fly to do this kind of analysis during
my development days.

_Receiving data_: Yes, there is a need to have receiving software
process the received trace data. The complexity of the software will
range from a simple program that uses a memory map to track vote totals,
a program to interpret the ballot image data, or a program that uses an
off-the-self simulator to verify the microprocessor is operating the
proper software. Since the tabulator is an open system anyone can
develop software for analyzing the transmitted data. A tiny fraction of
the population will need to be the ones that write and sell the analysis
software. The data can be compressed if desired. The transmitted data
will be saved by individuals, organizations, and the appropriate
government institution. The appropriate government institution will also
post the data on the web for comparison. By the way, selling
license/decryption keys/software for a nominal fee is an additional
revenue stream for a voting machine company.

_Verification:_ How do we verify that the tabulation was done correctly?
Any ballot that was processed by the tabulator will have a unique number
(not associated with an individual) on it. The unique number enables one
to associate that ballot with the instruction segment in the data base
that processed the ballot. You can now verify that the information on
the ballot was processed correctly. The local government can determine
the sampling size of random ballots used for comparison. Yes, this
requires a program to search the data base. The correlation of the
ballots to the data base verifies the tabulation, the monitor, the
transmitter and the receiver.

_Transmission:_ I am envisioning a data distribution software package
similar to the one offered by Real Time Innovation. Wireless security is
not one of my areas of expertise so I cannot attest to the veracity of
their security claims. Iíll need input from experts. I mention this SW
as an example of the distribution method.

_Complexity:_ Yes, Iíve added complexity. As an engineer Iím trying to
change the problem that cannot be solved to one that can be solved. Iím
adding complexity in return for transparency. The processor tabulating
the votes is as simple and low performance as possible (Z80 class). The
monitor function is essentially a memory with minimal logic to capture
and store the data. The transmitter is where the complexity is. There
are off-the-shelf components for this function.

_Printer_: The Monitor and transmit functions are isolated from the
basic tabulator via data diodes. This will prevent someone from swimming
upstream to hack the tabulator and/or printer.

If I did not address any issue or if you think I am hand-waving do let
me know so I can add more explanation.

Once again I want to thank both of you for giving me your feedback!

Best Regards,

Bob

charlie strauss wrote:
> Yikes! do you really want to put WiFi capability in this?
>
> Even if you did do something that scarey and were careful to keep the monitor inputs one-way (data diodes) you don't say how you would anominze the signal reporting so that it does not reveal the voter's ballot. You also don't discuss the signal condition needed to assure that the summary the mointor reports is also what the other elements on the buss responded to. Without that kind of conditioning the sampling rate of the monitor needs to be VASTLY far in excess of the buss bandwidth otherwise covert communication delays between subunits by edge delays on the buss or even gnarly ideas like Tempest are not actually being monitored.
>
> On the face of it, judging from the slides without the benefit of a dialogue, my imperssion is it seems like it's guarding against a few assumed attack vectors, ignoring others, and introducing so much complexity it might very well create new attack vectors.
>
> Lastly, who is watching the watcher? The level of complexity of the watcher would seem to make it's operation obscure and thus untrusted woudl it not?
>
>
>
>
> -----Original Message-----
>
>> From: Bob Donner <donner3@attglobal.net>
>> Sent: Dec 12, 2006 5:47 PM
>> To: ovc-discuss@listman.sonic.net
>> Subject: [OVC-discuss] Transparent Tabulator (take 2)
>>
>> Hi All,
>>
>> I have generated a brief (7 slides) PDF outlining the basic concepts of
>> the Transparent Tabulator I am proposing for use as a central tabulator.
>> I appreciate people taking the time to read the proposal and giving me
>> any feedback, comments or questions.
>>
>> Best Regards,
>>
>> Bob Donner
>>
>> Link to Transparent Tabulator Outline:
>>
>> http://bob.donner.com/transparent%20tabulator.pdf
>>
>> _______________________________________________
>> OVC-discuss mailing list
>> OVC-discuss@listman.sonic.net
>> http://lists.sonic.net/mailman/listinfo/ovc-discuss
>>
>
> _______________________________________________
> OVC-discuss mailing list
> OVC-discuss@listman.sonic.net
> http://lists.sonic.net/mailman/listinfo/ovc-discuss
>
>
_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Sun Dec 31 23:17:11 2006

This archive was generated by hypermail 2.1.8 : Sun Dec 31 2006 - 23:17:16 CST