[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: Any Risk ?

> Clearly, the command stations have matters well in hand.  That's all we 
> really need to know.  As a practical matter, I suggest we drop this topic 
> so as not to stimulate interest in hacking.

Being the skeptical, inquisitive person that I am, I don't really know
if the command stations have matters well in hand.

By my definition, "well in hand" means that commands are protected
using cryptographic signatures.  That is, commands contain a digital
signature that enables the satellite to verify that the command was
sent by an authorized command station.  Note that in this situation
there is no need to encrypt the command itself, because the satellite
software is able to authenticate its origin.  (Commands should probably
have a sequence number or some other mechanism to prevent reply of
commands by third parties, or commands should be inherently repeatable.)

Note that the use of digital signatures moots the Part 97 language allowing
encryption of satellite command traffic.  Encryption is only one method
of protecting command traffic; I am arguing that digital signatures
may be a superior method.

Having said that, it is not clear to me that AO-40 uses digital signatures
to protect command traffic.  In fact, I rather suspect, for several reasons,
that it doe not.  First, it is not clear to how much compute power
is available in the IHU-2.  On the other hand, if a ring (the kind you wear
on your finger) can do this, why not a satellite?  (See
http://www.ibutton.com/ and http://www.ibutton.com/store/jringfacts.html.)
To be fair, the iButton and JavaRing have (a little bit of) hardware
support for public key cryptography.  But still...

Second, it appears that the IHU-2 hardware and software were designed
at a time when digital signature and public key cryptographic techniques
weren't widely known, so it shouldn't be too surprising if they aren't
being used.

Third, while digital signatures are a very secure technique, they are
a bit complex in terms of the amount of hardware that needs work
and the number of lines of code that need to execute.  Every designer
of any remote, inaccessible device wants a "heavy hammer" that
will reliably cause the remote system to reboot.  The easiest way
to do this is to have some very simple, isolated piece of hardware
(usually) that detects some unique sequence of data and reaches out
with a "magic finger" and does a hard reset of the system.  It is
difficult to protect this reboot circuitry with something as complex
as digital signatures, because the failure of digital signatures
may be what caused the control stations to loose control of the remote

Fourth, I think I asked this question, but I don't entirely remember
the (obviously incomplete) answer...

However, this topic ought also to provide fodder for the AMSAT
Strategy Committee.  The committee should be ask itself (and us)
such questions as:

o	What role should AMSAT play in the nurturing, mentoring and
	development of the next generation of satellite builders?
	Should AMSAT actively develop new amateur satellite builders
	(e.g., by helping to disseminate information to AMSAT members
	and others), or should the development of AMSAT satellite 
	builders be the task of universities and industry?

o	What role should AMSAT play in developing new technologies
	appropriate for amateur satellites?

Obviously, I would like to believe that the open discussion of these
techniques (which have terrestrial applications as well) is a good
thing, because the security of AO-40 relies on the protection of the
cryptographic keys, not of the content of the command messages, and
because part of AMSAT's mission is to help develop the next generation
of satellite builders through the wide dissemination of technical
information.  But, I could always be wrong...


Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org