[Sis-csi] noting unusual CCSDS security critique

Wed Oct 5 12:40:20 EDT 2005

Howard Weiss wrote:

> 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.
>
> 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?). 
>
> 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).
>
> 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).
>
> 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.

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.

> 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?

I think when he says "C&DH" he means "command" (or "telecommand"), as on 
the sixth line of page 16.

> 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).

Right.

> "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. 
>
> 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). 
>
> 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).
>
> Yep, it sure is an "unusual" paper.

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:

1.    Use frequency hopping, even though it's more expensive.  I suspect 
this is a non-starter for civil science space missions.

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.

3.   Use Cisco AAA.  Seems reasonable if you're flying a Cisco router.

4.   Use access control.  Sure.

5.   Do traffic authentication on a per-hop basis.  Absolutely; this is 
one of the cornerstones of security in the DTN architecture.

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.

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.

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.

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.

So I don't think there's a lot of startling news here.

Scott

> Lloyd Wood wrote:
>
>>I stumbled across:
>>
>>http://www.infosecwriters.com/texts.php?op=display&id=310
>>
>>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.
>>
>><http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood at eim.surrey.ac.uk>
>>
>>_______________________________________________
>>Sis-CSI mailing list
>>Sis-CSI at mailman.ccsds.org
>>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
>>  
>>
>
>-- 
>
>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!"
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Sis-CSI mailing list
>Sis-CSI at mailman.ccsds.org
>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20051005/5587f25d/attachment.html