Re: code validation? - rom based attacks

From: Ron Crane <voting_at_lastland_dot_net>
Date: Wed Feb 23 2005 - 20:12:52 CST

>>> This would mean forgoing the security benefits of open source
>>> software and falling back upon the second level of security provided
>>> by VVPAT.
>> Not forgoing. We want both.
>> The BIOS attack is significant, but not as overwhelming as Ron seems
>> to think. Stipulate that a nasty BIOS corrupts machines. It's not
>> all that easy to make that happen: the software on CD is quite a bit
>> bigger than normal ROM holds; tampering would have to detect/modify
>> the specific certified code version; the machine modification would
>> need to hide itself from visual and on-screen detection; etc. None
>> of these hacks are in-principle impossible to do, but they're not
>> that simple. Especially once you add chain-of-custody procedures
>> around the physical machines.
> I'm not talking about BIOS attacks. I'm talking about a scenario where
> vendors provide turn-key systems using OVC's software. Since the
> vendor controls how such a system is manufactured, it could include a
> ROM that contains a version of OVC's software identical to the
> publicly-reviewed one except for cheating code. A voting station
> based upon such a ROM would simulate booting from the (approved) CD,
> but would really boot from the cheating ROM.

Other significant worries along these lines involve booting from the
cheating ROM only at certain dates and times, or only when a certain
signal is broadcast via long-distance WIFI (e.g. ) or (worse) via
the power lines (e.g.
). It wouldn't be much of a stretch to then load the cheating program
via WIFI or the power lines, doing away with the need for a large (and
potentially though not easily detectable) ROM.

We would be trusting a vendor not to do this.


OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Feb 27 17:17:12 2005

This archive was generated by hypermail 2.1.8 : Sun Feb 27 2005 - 17:17:13 CST