[2761] in cryptography@c2.net mail archive
Re: DRUDGE-REPORT-EXCLUSIVE 5/20/98 (fwd)
daemon@ATHENA.MIT.EDU (Black Unicorn)
Wed May 27 17:13:12 1998
Date: Wed, 27 May 1998 15:27:50 -0500
To: "Arnold G. Reinhold" <reinhold@world.std.com>,
William Knowles <erehwon@dis.org>, cryptography@c2.net
From: Black Unicorn <unicorn@schloss.li>
In-Reply-To: <v03130304b190802d0d03@[24.128.118.45]>
At 01:47 PM 5/27/98 , Arnold G. Reinhold wrote:
>On 5/21/98, William Knowles reported on a Drudge Report claim that a
>hardware encryption module from a US Satellite launched in China may have
>fallen into Chinese Government hands. Others pointed out that nothing the
>Chinese could have obtained from such a module would enable them to control
>other satellites, which presumably use different keys.
>
>I wonder what is the point of using hardware encryption in a satellite at
>all. A satellite's onboard computer could decrypt and authenticate messages
>as part of its own software using published algorithms. With public key
>technology there is no need to have any secret information in the satellite
>computer whatsoever, not even keys. All that is needed is assurance that
>the computer and software launched is the computer and software that was
>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.
I might add that capturing the hardware is not a non-event in terms of
security. It probably gives away a good deal in terms of likely keysize,
crypto performance (which could later be used as a benchmark for timing
attacks) the current state of the art and R&D capability, key management
procedures, design philosophy and culture, and a host of other collateral
design intelligence that could reduce the load factor of attacks on
satellites using similar systems by several orders of magnitude. Just as
an example, given one such module, even without key data, I could
potentially construct a faux module which, while appearing to be secure,
would leak key information. A quick black bag job on a local satellite
project, even in its earlier stages, and I own a satellite. Captured
software would probably be a lot more damaging.
>Incorporating a separate hardware encryption module adds cost, weight and
>complexity to the satellite. And if the module's presence makes the
>satellite unsuitable for launch on non-US boosters, it is a serious
>commercial liability as well.
I think quite the reverse. Non-hardware crypto and key management would
make the satellite unsuitable for non-local launches.
