Re: Reflections on trusting trust

From: Douglas W. Jones <jones_at_cs_dot_uiowa_dot_edu>
Date: Fri Aug 15 2003 - 16:31:04 CDT

On Friday, August 15, 2003, at 02:43 PM, David Mertz wrote:

> "Douglas W. Jones" <jones@cs.uiowa.edu> wrote:
> |If there's no dynamic linkage, no interpretation and no
> |self-modification, you can examine the object code and know you've got
> |the whole ball of wax. If there are any of those additional
> mechanisms,
> |you've got to broaden your search, looking at every gateway into the
> |system through which code subject to linkage or interpretation could be
> |inserted.
>
> True, but it is not enough merely to examine the object code for the EVM
> application. You also need to examine the object code for everything
> that can affect the runtime environment of the EVM application.

Yup. That's why Sequoya and ES&S have opted, in their DRE systems,
to avoid use of third-party off-the-shelf components such as operating
systems. True, the FEC/NASED source code audit process is seriously
flawed, so the oversight that we (the public) have over DRE systems is
poor, but at least, with these systems, we don't have to ask if
how they've dealt with the loopholes we know to be present in many
versions of Linux and all versions of Windows.

> This includes the OS kernel, device drivers, and any daemon or other
> process with sufficient permissions (or with hacks) to peak into the
> memory space of the EVM object code.

Exactly. I'd argue that we should provide an ironclad guarantee that
every single bit of executable code in the voting system is all
derived from specific source code, and furthermore, I'd argue that
significant auditing of the object code ought to be done to protect
against Ken Thompson's attack model.

This can be done if we use Linux or FreeBSD as our foundation, but
it absolutely rules out Windows and other proprietary operating
systems, and it absolutely rules out any proprietary programming
language implementations.

It does require that we aim for an absolutely minimal system, where
the operating system and middleware have been stripped of all services
not required for the voting application, and where the application
itself has been designed to have a minimum footprint (defined in terms
of the size of the set of system or middleware interfaces it uses).

> At the very least, such inspectibility rules out proprietary
> software from the entire tool chain.

Yes.

The biggest problem area we're faced with if we follow this
conservative route is the BIOS. If we use commodity PC systems,
you're stuck with something in ROM, and the most you can do is
try to guarantee that it is completely out of the loop after
the system boots up.

> In practice, an application using an interpreted language like Python
> can be more secure than a compiled system, because checking the SHA/MD5
> hash of the runtime system itself (against a known, audited version)
> gets you the same level of security as you get by inspection of the
> machine code of a compiled application.

I have long speculated that use of interpreters can defend an
application against an untrusted runtime platform, but I don't
believe that this is the case for statically defined interpreted
languages with static code for the interpreter. If, on the other
hand, the interpreter itself is wildly dynamic, and therefore,
unrecognizable as an interpreter to the underlying platform,
and if the bytecodes being interpreted are not fixed, but rather,
re-assigned with each use, then the platform should be unable to
recognize the presence of a particular interpreter or a particular
interpreted application, and therefore, a malicious platform would
be unable to interfere with the semantics of the application.

But, I don't think Python, or Java, or any of the other popular
interpreted languages offer this security. If I wanted to write
a version of Windows that attacked a particular Python application,
knowing the MD5 (or any other hash) of the authorized Python
interpreter, I think I'd have a fairly easy time of it, and I'll
lay odds that the code involved would be smaller than the code in
the flight simulator that was tacked onto Excel.

                                Doug Jones
                                jones@cs.uiowa.edu
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Sun Aug 31 23:17:10 2003

This archive was generated by hypermail 2.1.8 : Sun Aug 31 2003 - 23:17:18 CDT