1996-04-25 - trusting the processor chip

Header Data

From: us028272@interramp.com (Jeffrey C. Flynn)
To: cypherpunks@toad.com
Message Hash: 3dc1491d8d0cf596f280b94837cea1994407af668faad383bdf9be620a3aa4b8
Message ID: <v01530502630b72c54a12@[38.12.221.41]>
Reply To: N/A
UTC Datetime: 1996-04-25 17:54:34 UTC
Raw Date: Thu, 25 Apr 1996 10:54:34 -0700 (PDT)

Raw message

From: us028272@interramp.com (Jeffrey C. Flynn)
Date: Thu, 25 Apr 1996 10:54:34 -0700 (PDT)
To: cypherpunks@toad.com
Subject: trusting the processor chip
Message-ID: <v01530502630b72c54a12@[38.12.221.41]>
MIME-Version: 1.0
Content-Type: text/plain


On Fri, 29 Mar 1996, JEFF C FLYNN wrote:

> Does anyone know of articles regarding the possibility of subverting
> processor chips?  Is this a realistic threat?  Is it possible to hack vhdl
> compilers to embed intentional security flaws in silicon?  Known cases?
> Attempts?
> TIA,
> Jeff

I received several responses to this question.  My favorite was as follows...

>This is probably science fiction, particularly at the VHDL level.
>Maybe someone could make a crime of opportunity out of a microcode
>flaw, but there's a risk of it being found out during testing.
>
>To do it right would require collusion of the design and test teams.
>They need to ensure the back door stays closed, isn't tickled by
>"normal" testing and only opens when really requested. So a lot of
>people are in on the secret even before it gets exploited for
>nefarious purposes.
>
>And what nefarious purposes would pay for the risks and costs of this?
>If the secret got out, the design team, product line, and company
>would be dead in the marketplace and probably spend the rest of their
>lives responding to lawsuits. What could you use this for that is
>worth the risk?
>
>Trying to do it to the compiler (like Thompson inserting a back door
>in login using the Unix C compiler) is, again, theoretically possible.
>But the only reason to hack the compiler would be to do the deed
>without involving the processor development team. Risky in terms of
>building a reliable back door and the risk of detection. It might not
>work and the changes might be detected. To do it right would probably
>involve as many technical people as the processor development itself.
>Even "high grade threats" have finite resources -- there aren't that
>many processor design gurus in the world to start with.
>
>At best, this might make a good plot element for Tom Clancy.>
>
>Rick.
>smith@sctc.com         secure computing corporation

Still, I'm left feeling a little uneasy.
My reasons for this are

1) Trusting the processor means trusting something I don't fully understand.
2) Processors these days are extremely complex.
3) On April 3rd, at Interop, Peter Neumann (in his keynote presentation)
disclosed that a random number generator chip used in slot machines had
been compromised.  This lead to a huge bogus jackpot, and an investigation
that revealed the scheme.

It looks like I may have no other option than to give some processor some
degree of trust. Which processor I should choose, and why that one?

TIA,
Jeff

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

             Specializing in the Design and Implementation of
                             SECURE NETWORKS



                        JEFF FLYNN & ASSOCIATES
                      NETWORK SECURITY CONSULTING



19 PERRYVILLE
IRVINE, CALIF.    92720                                        JEFF FLYNN
TELEPHONE (714)551-6398                                         PRINCIPAL

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/







Thread