[2779] in cryptography@c2.net mail archive
Re: Satellite processing (was DRUDGE-REPORT-EXCLUSIVE pablum)
daemon@ATHENA.MIT.EDU (Dan Veeneman)
Thu May 28 16:31:16 1998
To: cryptography@c2.net
From: Dan Veeneman <dan@decode.com>
Date: Thu, 28 May 98 15:35:30 EDT
At 10:41 AM -0400 5/28/98 Cerberus Systems, Inc. wrote:
At 09:28 AM 5/28/98 -0400, Arnold Reinhold wrote:
>At 9:00 PM -0400 5/27/98, Dave Emery wrote:
>
>>... 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.
You want it small so that it's maintainable and understandable, not
to avoid cosmic rays.
[...]
>I am surprised that there aren't any radiation reliable ROMs built using
>error correcting codes, but if one cannot rely on ROM to hold a loader big
>enough to check a public key signature, then I have to concede. Hardware
>encryption would be the only way to go. Thanks for the explanation.
[...]
> When we asked about megaRAD hardened integrated circuit requirements, we
> were told that "other techniques" were deemed sufficient to permit use of
> commercial microprocessors.
One such method currently in use is a dedicated ASIC that spends all
it's time reading memory, correcting any errors, and writing it back out.
Heavy error correction codes are employed primarily for radiation
effects, but through the continuous error correction process much
less expensive memory components can be used.
> Apparently the influence of DoD's shift towards "COTS" (Commercial
> Off-The-Shelf) is spreading to the commercial part of the space world, if
> not the DoD part.
Keep in mind that that historically the greatest risk to the satellite
is from the ground controllers, not a hijacker. Encryption and
authentication won't help you here.
Also, DoD attitudes are changing, mostly because of budgetary cutbacks.
No longer are procurements automatically MIL-Spec, custom for the military,
etc, but if a program calls for something other than COTS the acqusition
officer must justify why commercial equivalents are _not_ suitable.
Dan
--
dan@decode.com (Dan Veeneman)
Cryptography, Security, Privacy BBS +1 410 730 6734 Data/FAX
