[5735] in cryptography@c2.net mail archive
Re: having source code for your CPU chip -- NOT
daemon@ATHENA.MIT.EDU (Bill Frantz)
Thu Sep 23 14:06:11 1999
Message-Id: <v0311076fb41005bf4693@[207.92.173.117]>
In-Reply-To: <v04210102b40f68d103d7@[63.193.122.223]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 23 Sep 1999 09:38:05 -0700
To: Martin Minow <minow@pobox.com>, Arnold Reinhold <reinhold@world.std.com>,
John Gilmore <gnu@toad.com>,
William Allen Simpson <wsimpson@greendragon.com>
From: Bill Frantz <frantz@netcom.com>
Cc: cryptography@c2.net
At 10:26 PM -0700 9/22/99, Martin Minow wrote:
>At 9:26 AM -0700 9/22/99, Bill Frantz wrote:
>>
>>My own approach would be to audit the generated code. In KeyKOS/370, we
>>"solved" the problem by using an assembler which was written before KeyKOS
>>was designed. (N.B. KeyKOS/370 was written in 370 Assembler H).
>>
>
>Yeah, but 370 Assembler H had a very extensive macro facility and
>you could hide all kinds of wierd stuff in 370 code. Not too many
>folk left around who can read it.
The big advantage of Assembler for detecting compiler Trojans is that the
object code has a simple relation to the source code. It is quite straight
forward to see if the assembler has inserted/deleted code ala Thompson.
It is certainly not impossible to do this for a higher level language such
as C. If the compiler allows you to associate source line numbers with
offsets in the object code it is even easier. You "merely" have to look at
the object code line-for-line and see if it is a reasonable result of the
source code. I have occasionally had to do almost exactly this when
line-by-line stepping of a C program was too course grained for the bug I
was seeking.
-------------------------------------------------------------------------
Bill Frantz | The availability and use of secure encryption may |
Periwinkle | offer an opportunity to reclaim some portion of |
Consulting | the privacy we have lost. - B. FLETCHER, Circuit Judge |
