<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Howard Weiss wrote:
<blockquote cite="mid431F1157.40904@sparta.com" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<font size="-1"><font face="Helvetica, Arial, sans-serif">I took a
look
at this paper and I agree, its certainly unusual. But I mean "unusual"
in the sense that its very naive and written from a perspective of
"lets take Internet attacks and see how they can be applied to space."
Sure, some apply - in a manner of sorts. But others don't.<br>
<br>
Right off the bat, the author thinks that the only barrier to keeping
someone out of a commercial satellite link is the high cost of a
transmitter. Yep, that's one. But what about the high cost of a
dish? Not to mention that a Big Ugly Disk (BUD) is something that
neighbors notice and complain about - at least in my neighborhood (not
to mention the TVI resulting from any sort of high powered transmitter
- ever live near someone with an illegal linear amp on a CB radio?). <br>
<br>
It goes on to discuss source code theft - sure thats a problem but not
just for space systems. And the goal is to assume that systems are not
cloaked under a false sense of security by keeping source code
"secret." Look what happened to the GSM A3 COMP128 algorithm that
relied on remaining secret but was broken as soon as its detailed were
made public. Not terribly robust! Linux, FreeBSD, OpenBSD, and even
Solaris all provide source code yet remain relatively secure. The
paper talks about buffer overflows as the latest exploitation craze -
but they are nothing new and have been around for a long, long time (I
ran into my first one 30 years ago). <br>
<br>
Then there is a survey of news reports of stolen codes, denial of
service against military birds, reports of Falun Gong jamming, takeover
of control centers, etc. And then there is a section talking about
video streams being sent over RTP port 160000? What's this all
about? Is anyone using RTP over satellites? And given the
description, this wouldn't matter if it was a terrestrial network or a
network with a space segment. The space segment just replaces a
land-line and the description is of a typical man-in-the-middle attack
(w/o calling it that).<br>
<br>
Finally, this paper talks about CCSDS as if it were a single
communications "entity" rather than as an organization that recommends
standards. A quote is "Satellites use the CCSDS C&DH, CFDP, and
telemetry services to communicate with ground stations and other
satellites." Hmmm, CFDP was just used for the first time on a
spacecraft in the past month.</font></font></blockquote>
Actually CFDP has been in use for a surprisingly long time now. The
first use was on AlSat-1 (Surrey Space Systems) starting at the end of
2002, but that didn't get a lot of press. The MESSENGER mission to
Mercury (APL) began using CFDP in flight shortly after launch, in
August of 2004. Deep Impact used CFDP throughout the mission, starting
in January of 2005.<br>
<blockquote cite="mid431F1157.40904@sparta.com" type="cite"><font
size="-1"><font face="Helvetica, Arial, sans-serif">Don't know of any
CCSDS-compatible
spacecraft with cross links. Don't know what a "CCSDS C&DH" means
- is this a data handler that speaks using the CCSDS telecommand and
CCSDS telemetry standards?</font></font></blockquote>
I think when he says "C&DH" he means "command" (or "telecommand"),
as on the sixth line of page 16.<br>
<blockquote cite="mid431F1157.40904@sparta.com" type="cite"><font
size="-1"><font face="Helvetica, Arial, sans-serif">The paper then
goes on to talk about how
one goes about analyzing and trying to break any system - boundary
checking, field validation, null processing. All good things to stress
- but this is not a issue with CCSDS standards as much as it is with
implementers of CCSDS standards. Just like there are good
implementations of protocol stacks and are bad implementations (FreeBSD
vs. Win95 for example).</font></font></blockquote>
Right.<br>
<blockquote cite="mid431F1157.40904@sparta.com" type="cite"><font
size="-1"><font face="Helvetica, Arial, sans-serif"> "Traditional
space communication design sees security design as an
afterthought." I don't know what "traditional" means in this context.
If it means civil science - yep that's right. It it means deep-space
(e.g., MER) - right but who's got a 70m dish to talk to it? If it
means geo comsat birds - no, not true. If it means manned space -
again not true. If it means military space - definitely not true. If
it means navigation (e.g.,GPS) - nope not true. <br>
<br>
While I'm not saying that the space segment is in great shape
security-wise or that no more work needs to be done (farthest from the
truth), this paper doesn't portray any semblance of message because it
appears to be making acusations against CCSDS protocols without full
knowlege or understanding and it could be talking about any other set
of protocols (e.g., TCP/IP). <br>
<br>
IP-in-Space would suffer from the same sorts of threats as the author
postulates for what is called "CCSDS." IPSEC provides protection
against upper layer attacks (above TCP) but IP is still vulnerable to
DoS attacks, buffer overflows, bogus packet fields, etc. And after
all, IP is so well known that script kiddies can take it apart easily
(not that I'm advocating that the relative obscurity of space-only
protocols is a means of achieving security). And IP has to ride over a
link layer protcol whether that means Ethernet in a LAN, 802.11 in
wireless applications, GSM or CDMA in cellular nets, or just about
anything else that handles bits to/from the transmission media (e.g.
RF, copper, fiber, laser, IR, tin cans & string). Not sure why the
paper plugs Cisco NBAR and CBAC - what's that got to do with anything
being discussed? Likewise with mentioning authentication for NTP (and
contrary to what is said, the NTP RFC did include shared-key
authentication).<br>
<br>
Yep, it sure is an "unusual" paper.<br>
</font></font></blockquote>
Mainly it's just not very well organized. He does have a short list of
specific recommendations, buried in the next-to-last paragraph on page
16:<br>
<br>
1. Use frequency hopping, even though it's more expensive. I
suspect this is a non-starter for civil science space missions.<br>
<br>
2. Encrypt traffic that's sent to the spacecraft. Not a bad idea,
though more specifically I think what's needed is authentication
supporting access control, rather than encryption; the confidentiality
of uplink traffic to a spacecraft typically isn't a very great concern.<br>
<br>
3. Use Cisco AAA. Seems reasonable if you're flying a Cisco router.<br>
<br>
4. Use access control. Sure.<br>
<br>
5. Do traffic authentication on a per-hop basis. Absolutely; this is
one of the cornerstones of security in the DTN architecture.<br>
<br>
6. Use firewalls. Certainly this seems reasonable if you're flying
COTS IP; it's unclear to me what this would mean for a network in deep
space that isn't built using commercial IP stacks.<br>
<br>
7. Do special stuff to detect and respond to anomalous conditions on
the spacecraft. Yep, we do this all the time, and we could do even
more.<br>
<br>
But in sixteen pages he doesn't really say anything very specific about
the CCSDS link-layer protocols being in any way uniquely vulnerable to
attack. He describes a variety of methods of attack, but I would guess
that those methods would be equally applicable to any other standard
R/F-based link-layer protocols.<br>
<br>
And it's certainly true that civil space science missions have been
really weak on security at the network layer, but that's largely
because there historically hasn't been *anything at all* -- not even a
network protocol, much less a network security protocol -- at the
network layer for these missions. That's not ideal, and it's something
that I think we're all trying to make progress on, but it's an
architectural deficiency rather than a deficiency in CCSDS link-layer
protocol design.<br>
<br>
So I don't think there's a lot of startling news here.<br>
<br>
Scott<br>
<blockquote cite="mid431F1157.40904@sparta.com" type="cite"><font
size="-1"><font face="Helvetica, Arial, sans-serif"></font></font>Lloyd
Wood wrote:
<blockquote
cite="midPine.GSO.4.50.0509011843100.10887-100000@argos.ee.surrey.ac.uk"
type="cite">
<pre wrap="">I stumbled across:
<a class="moz-txt-link-freetext"
href="http://www.infosecwriters.com/texts.php?op=display&id=310">http://www.infosecwriters.com/texts.php?op=display&id=310</a>
Secure Communication in Space by Alain Charles Brainos II, East
Carolina University, on 05/08/05
This is a strange document, apparently written for some online
competition -- but it attempts a security evaluation of parts of
CCSDS (pages 11 and 12).
Quite odd, and not something you see every day.
L.
<a class="moz-txt-link-rfc2396E"
href="http://www.ee.surrey.ac.uk/Personal/L.Wood/"><http://www.ee.surrey.ac.uk/Personal/L.Wood/></a><a
class="moz-txt-link-rfc2396E" href="mailto:L.Wood@eim.surrey.ac.uk"><L.Wood@eim.surrey.ac.uk></a>
_______________________________________________
Sis-CSI mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Sis-CSI@mailman.ccsds.org">Sis-CSI@mailman.ccsds.org</a>
<a class="moz-txt-link-freetext"
href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201 || 410.872.8079 (fax)
Mike Nichols: "Cheer up, life isn't everything!"</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Sis-CSI mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Sis-CSI@mailman.ccsds.org">Sis-CSI@mailman.ccsds.org</a>
<a class="moz-txt-link-freetext" href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</a>
</pre>
</blockquote>
<br>
</body>
</html>