[2766] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: DRUDGE-REPORT-EXCLUSIVE 5/20/98 (fwd)

daemon@ATHENA.MIT.EDU (Dave Emery)
Thu May 28 08:51:52 1998

Date: Wed, 27 May 1998 21:00:20 -0400
From: Dave Emery <die@pig.die.com>
To: "Arnold G. Reinhold" <reinhold@world.std.com>
Cc: cryptography@c2.net
Reply-To: die@die.com
Mail-Followup-To: "Arnold G. Reinhold" <reinhold@world.std.com>,
	cryptography@c2.net
In-Reply-To: <v03130303b19242c619b2@[24.128.118.45]>; from Arnold G. Reinhold on Wed, May 27, 1998 at 06:46:53PM -0400

On Wed, May 27, 1998 at 06:46:53PM -0400, Arnold G. Reinhold wrote:
> 
> 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.

	Actually most spacecraft I am familiar with use on board computer
software uploaded from the ground rather than permanently installed before
launch.   This permits correction of bugs and most importantly allows
satellite controllers to write and upload code which works around 
partially or completely failed hardware - failures which often were
not understood or anticipated at launch.  Such failures run from bad
bits in the computer memory to problems with attitude sensors, thrustors,
on board transponders and so forth.  And having much of the software 
uploaded aviods the problems caused by cosmic ray events that flip
bits in roms - one really wants to keep the rom part of the code very
small.

	Hardware crypto provides protection for the code upload, and 
aviods sending crypto code or keys over a link that could be possibly
be compromised.


-- 
	Dave Emery N1PRE,  die@die.com  DIE Consulting, Weston, Mass. 
PGP fingerprint = 2047/4D7B08D1 DE 6E E1 CC 1F 1D 96 E2  5D 27 BD B0 24 88 C3 18


home help back first fref pref prev next nref lref last post