1996-05-13 - tamper proofed cpus & police states (was Re: found nym-differentiation!…)

Header Data

From: A.Back@exeter.ac.uk
To: perry@piermont.com
Message Hash: e029ca56572b85839dfd9d392045f87176144fb49235b077adc4061bfaaeb896
Message ID: <523.199605131151@olib>
Reply To: <199605130232.WAA10281@jekyll.piermont.com>
UTC Datetime: 1996-05-13 17:29:36 UTC
Raw Date: Tue, 14 May 1996 01:29:36 +0800

Raw message

From: A.Back@exeter.ac.uk
Date: Tue, 14 May 1996 01:29:36 +0800
To: perry@piermont.com
Subject: tamper proofed cpus & police states (was Re: found nym-differentiation!...)
In-Reply-To: <199605130232.WAA10281@jekyll.piermont.com>
Message-ID: <523.199605131151@olib>
MIME-Version: 1.0
Content-Type: text/plain



On tamper proofing cpus as a tool of a police state...

A cpu which was tamper proofed and had public key crypto for key
receipt (so that it could receive software which it's owner could not
decrypt), and could decrypt instructions on the fly using a symmetric
key stream cipher to execute them would be a start.

Of course this assumes that tamper proofing is ultimately possible...
but perhaps as fabrication technology progresses this might be
possible due to quantum effects (if you even look at one particle in
the internals of the cpu, it self destructs -- gross speculation as I
know next to nothing about cpu fab, but perhaps someone who does know
about chip fab would care to comment on whether the job of tamper
proofing is headed in the favour the breaker or the other way around).

Such a tamper proof cpu would also be excellent for the copyright
warriors, you would buy your copy of microsoft word, microsoft would
encrypt it for your cpus public key and send it to you.  The software
would be useless on any cpu but your own, and without breaking the
tamper proofing, or cryptanlysing the keys you wouldn't be able to
copy the software.

Still what about using software from the FSF?  Or that you wrote your
self?  Or that PRZ wrote?  How would a police state disable this?
They could make the system so that it would only run software signed
by the NSA software authorisation service :-) Any software to be
vetted and only runable on once authorised.  Development machines
would need to be strictly licensed.

But even then you could probably write PGP in microsoft word basic if
you really had to (?)  Checking for non-approved crypto in
communication beween machines would ultimately fail though because
even if a rabid police state required only standard formats you could
super encrypt or use steganography and then superencrypt in your word
basic implementation of PGP.

The legal requirement for standardised communications encodings, and
the NSA software authorisation aren't going to happen any time soon
IMO.  

Tamper resistant CPUs with public key and on the fly decryption of
memory accesses feasible I suppose for software copyright, might even
have some positive uses like providing a framework in which to embed
chaum's observers for off-line anonymous ecash.  If the option was
selectable per thread so that you could run both encrypted and normal
code on it, and when in encrypted mode it would not allow any debug
modes it would seem feasible enough for copyright purposes.

All pretty negative aspects IMO though.

Adam
--
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)   # <- export violation





Thread