[2765] in cryptography@c2.net mail archive
Re: DRUDGE-REPORT-EXCLUSIVE 5/20/98 (fwd)
daemon@ATHENA.MIT.EDU (Arnold G. Reinhold)
Wed May 27 21:01:08 1998
In-Reply-To: <199805272036.AA14895@world.std.com>
Date: Wed, 27 May 1998 18:46:53 -0400
To: Black Unicorn <unicorn@schloss.li>, William Knowles <erehwon@dis.org>,
cryptography@c2.net
From: "Arnold G. Reinhold" <reinhold@world.std.com>
At 3:27 PM -0500 5/27/98, Black Unicorn wrote:
>At 01:47 PM 5/27/98 , Arnold G. Reinhold wrote:
...
>>shipped from the factory. And if the computer can be tampered with, so can
>>the hardware crypto module. The threats that normally argue for hardware
>>encryption -- physical access, viruses, TEMPEST, multiple users -- do not
>>seem to apply in this case.
>
>Sure they do. The satellite has to sit on the ground in China a good long
>time before it goes up. Using non-hardware/tamper resistant based
>encryption is a rather silly thing to do.
>
>I might add that a recent DoD project involved introducing virii to radar
>systems via EMI. Depending on the state of research in this field and
>given the sensitivity of satellite traffic, the expense invested, and the
>hostile environment, using non-hardened or software based crypto might be a
>very poor idea.
>
If you can introduce a virus into a satellite's main computer, you can
disable it the saqtellite time of war. Even if all communications pass thru
an intact crypto box, you could send a distruct signal, say, by interfering
with routine command signals at certain times. The virus could acknowledge
by commanding a short thruster burst -- just enough to disrupt service for
a while -- at some specified time.
I contend you have to protect the onboard computer anyway, and, if you do,
you may as well let it handle the crypto. Indeed, having crypto integrated
with the code provides more opportunities for anti-tampering measures. You
could incorporate special hidden integrety checks in many places and
transmit the final software from the US to the launch site hours before
launch. The launch country would not have enough time to analyze the final
flight code and design a virus that could be inserted without detection
before launch. Once the bird is up, the software can protect itself.
Look, if you do not have physical control of the satellite at all times,
someone can plant a radio controlled mine on it. Hardware encryption seems
like a fig leaf here.
Arnold Reinhold