Slashdot Mirror
Satellite Command Security?
teridon asks: "I work in the satellite control industry, and I've been asked to present mission safety with regards to command security. In other words, how do we ensure that 'unknowns' don't command the satellite. Military and commerical birds often employ encryption on both the uplink and the downlink. However, it seems that none of the science-oriented satellites my company operates do this. We rely on physical security (access to the control center), network security (we use closed networks), technology (most crackers don't have access to a huge radio antenna with which to transmit), and obscurity (each satellite has its own command structure, not publicly documented). Many satellites use CCSDS frames to uplink commands; only the command data is obscured by lack of public info." A common mantra heard from Slashdot is "obscurity is not security", and this is a lesson that teridon wants his company to learn, in addition to other steps they can take to improve the security of their system. What suggestions might you have when it comes to improving security on satellite systems, especially if you have experience from some of the mistakes that you may have seen in production?
"Three major issues concern me (I'm going to assume that our network security works (grin!):
- Can someone effectively execute a DOS attack by uplinking to the satellite with a powerful signal (the frequency would be easy to 'snoop' from our transmitting antenna), thus preventing us from commanding it? In general, how do receivers handle multiple command carriers (would there be too much noise to command)?
- How many of you think that you could decipher the structure of the command (given the motivation)?
- Standards being developed (like SCPS) intend to make satellites 'just another node on the Internet.' Take a look at the security protocol (which is based on IPSEC, et. al) and tell me if you think it is secure, or whether you'd want to crack it.
How many of you think that you could decipher the structure of the command (given the motivation)?
Anything can be hacked given enough motivation. That's why different levels of security are applied to different perceived threats - you guess how much motivation the opposition are likely to muster and decide how much to invest in security accordingly.
...this might sound obvious to some, but maybe if you need to ask this type of question, you shouldn't be in charge of securing a satellite...
Just a thought.
..especially if the hacked science satellite had enough manoevering fuel to be used to crash into a GPS or military satellite.
Satellites are getting larger: if the satellite was sufficiently large to enable large lumps to reenter and you could predict reentry then you could attempt to use it as a missile, but this is obviously a very hit and miss affair.
In the light of September 11I don't think you should assume that civilian targets (or civilian satellites) will be left alone by a terrorist.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
Just to give you an idea, some crackers during the BB era in southern california were stealing credit cards to buy commercial software, then sold cracked versions to the largest BB in southern CA. They were eventually caught and the FBI took away all the computers. All of them were under-aged, so they didn't do any time. All of them were interested in science, so they would definitely be interested in what your satellite is sending. More interesting is getting control of your satellite.
Also, remember that crackers tend to have parents who have technical careers, but no time to watch their kids. Hackers and crackers have a lot of time, brains and energy to burn. With all the articles recently about amatuer and college programs building their own satellites, it will become a bigger concern. As kids get more technically advanced at a younger age, more systems will get compromised. It's a fact of life.
Definitely assume that anybody you really don't want knowing your command structures will know them. Do you keep the documentation (or source code) in a locked vault with genuine security (not just "don't tell anybody where the vault is")? Do you have strong entry/exit security (can you take an 8mm tape home with nobody noticing)? Are your internal machines firewalled completely from the public Internet? Most importantly, how much do you trust the people who know how it works? Are you sure none of them wouldn't sell information for a few tens of thousands of dollars (or sex)?
Complete security is impossible. If someone wants access, they will eventually get it.
d wa re_token.html
The most secure authentication scheme I've seen in a while is talked about in great detail here:
http://www.rsasecurity.com/products/securid/har
The idea is that if you need a physical token, and some knowledge to authenticate, you have added another level of security. These tokens are (from my understanding) REALLY hard to reverse engineer. They generate a number (that looks random, but isn't) every minute. On the other side of the connection, the same pseudo-random number is generated. If they match at authentication time, you get access, if they don't, try again.
The other thing you were wondering about was DOS attacks. Go read this article on GRC:
http://grc.com/dos/intro.htm
It boils down to this: if it's distributed there is little you can do.
On the flip side, since these signals would require massive antenae, you can triangulate the source in a matter of seconds, and send some guys (cops, navy, army, etc) over to shut them down.
Either way it goes, this is an interesting problem. Keep us posted with the results.
Beware TPB
Many years ago HBO's satellite was overtaken for a few hours by someone in the "northwest quadrant" of the continental US. My electronics teacher at the time told me that most satellites would lock into the strongest signal being transmitted to them, and that most control centers used the least amount of power to get a lock-in. So apparently this guy just used a stronger signal than they were using.
As for hacking the command set? You better believe it. Get four engineers and a large blackboard and you might be amazed at how useless "security through obscurity" really is.
"Hello, World", 17 errors, 31 warnings
Military and commerical birds often employ encryption on both the uplink and the downlink. However, it seems that none of the science-oriented satellites my company operates do this.
/.er are ebay bidding on dishes right now....)
Wow, really? (imaging how many
As an undergraduate I worked on a small student-built scientific satellite, and even though the satellite barely had any need of an uplink, I seem to recall we still required strong command authentication, and that we also required the ability to be able to turn off the satellite transmitter and receiver in certain regions of the world, and that these requirements came straight from the DoD. My understanding is that we had to be prepared to respond to certain possible DoD advisories. In fact we probably would have done away with the uplink except for them.
The trasmitter turn-off requirement was apparently so that rogue states could not use the bird for navigation purposes or possible sensing.
Now the advising engineers on this project came from a lab (JHU APL) that does a TON of military birds, so it's very possible they were just imposing good practice on us. Maybe someone in the know could tell us more.
--Braddock Gaskill
I'm not going to analyze the up-link protocol or try to brainstorm motivations for cracking your system, but as a security professional let me try to clarify the issue a bit.
You are on the right track with your questions. You are trying to figure out: a) how badly does somebody want to crack it, and b) how difficult is it for him to do so.
These two factors are precisely what define security risk. If the cost of breaking a system is greater than the reward for doing so, your security is adequate.
The first question cannot be answered by the Slashdot crowd. There are too many variables. Who are your competitors, and how much to they have to gain by sabotaging you? Could the satellite possibly be used for anything other than its intended purpose if control was usurped? How valuable is the satellite to people other than you if it is only being used for its intended purpose?
Perhaps people here could try to figure out the 'cracker bragging-rights' factor, but I suspect that would not be sufficient motivation to go to the lengths required to break your system (any glaring security holes notwithstanding).
From what it sounds like, the second question can't be answered by anybody. The rule of the day is 'provable security', which is why security by obscurity is frowned upon. It's not that it doesn't work, because sufficient obscurity is indeed security, it's that you can never be sure how well it works. This was the problem with the German Enigma machine in WWII, which ultimately provided the greatest incentive to proving lower bounds on security.
Encryption provides easily quantifiable security, demonstrated by mathematical proof (with the minor caveat being most of these proofs rely on P not equalling NP). The techniques you describe do not sound like they lend themselves to provable security. (Although physical security is usually considered pretty sound, provided it is comprehensive; this includes isolated networks and site protection, as you describe)
How difficult is it to gain access to a powerful radio-antenna? That's a key question. If the satellite is owned by a company in an industry with cutthroat competitors who also have satellites, it might not be difficult at all.
I do PKI for a living. Actually, in this case, it might not be the right choice.
Do you really mean PKI or simply Public Key Encryption? Do you actually picture a root certificate authority, subordinate certificate authorities, directories, certificate revocation lists, and authority revocation lists being used to secure a satellite's command & control?
PKI is a great choice when you have lots of parties that need to randomly communicate with each other. It provides a great key distribution. However, PKI seems like overkill when one (or, at most, two) ground stations will be talking to a satelite. In this case, distributing a shared secret really isn't that difficult - probably much easier then building a PKI network and keeping it secure! Of course it does depend on if you trust your internal computer systems to keep the key private. If you don't, then PKI might solve some of your problems.
I would suggest a very lightweight approach. Privacy of data is not required for this application, IMHO. Maybe I'm wrong, in which case, you should investigate other options. This sounds like a good case for a MAC (Message Authentication Code). You don't even need to use encryption - just hashing - to do this.
Basically, each end has a shared secret, "S".
You have a packet containing data, "D".
Each packet has a timestamp (to prevent replay attacks) "T".
All packets consist of: D+T+MD5(D+T+S)
Of course, you can use some sort of hash besides MD5. You can also program the satelite with a few thousand secrets, which expire every so often - if you give it 100 years of secrets at launch, you should be fine.
The satelite receives this packet, does the MD5 of D+T+S, and compares the numbers. It doesn't let you use a packet with an old T (T should be very close to the current time and T should be greater then the most recent T).
This code has the benefit of taking very little memory space compared to a PKI solution. It's also much easier on the uplink/downlink channels.
The most important thing to remember, though, is that this shared secret has to be kept secret. It should not be used by your normal programmers to write control software. Instead, it should be an external module that runs on a secure box (I.E. no remote administration capabilities, only allows connections via a secure interface, and adds on the MAC as the messages pass through it). If you can afford a satellite, you can afford one secure server! I would definately investigate commercial encryption devices which add on a MAC using a shared secret - at least on the ground-station end. They of course may function differently then the method I described above, but the basics remain the same.
Of course all of this has been solved before. ATMs and banks have long needed to authenticate the other end. (ATMs, BTW, do not use public key cryptography, but simply a split key pair - that is, a random string of numbers is one part of the pair and that string XORed with the real key is the other pair - each part is given to a different person who keys it into the ATM seperately from the other person - you might also incorporate this type of system). Since this has been solved before, I recommend that you hire some sort of encryption expert to help you (you are NOT looking for a computer security person - chances are you are not running a default install of W2K on your satellite!).
As for IP, I would think that you would want to ensure there was no way for someone outside the control room to use your equipment to send command and control messages to your satellites! At the very least, this means that the control room should probably have an air-gap between it and the rest of your network. Sure, a little inconvienient, but how much command and control data do you really have to share with people outside that room? Not much most likely - certainly not too much to retype.
Obscurity really is security, if it is true Obscurity. For instance, if you've written a custom server with a set of commands, and you run it on a single computer somewhere on some random port, chances are it's not going to be hacked unless somebody smart and dedicated specifically targets you. Yes, you'd be more secure if you wrote the thing to encrypt its communications and made damn sure that it was robost-- but saying "probably nobody will notice me" has something to it if really nobody likely will notice you.
The problem with companies like Microsoft arguing that obscurity is security is that they don't have real obscurity. Their operating system is absolutely all over the place, both physically and in terms of network connectivity. As such, there is both ample opportunity and ample motive to find out hidden facts about it. While those facts may be hidden, the OS is not, so there's no real obscurity, just a thin veil of obfuscation.
If you're building one new high-tech stealth bomber, and you do it in a hidden valley in some very remote site, and completely underground, chances are it's not going to be seen. On the other hand, if you build several prototypes in downtown parking lots of major cities, and just drape a cloth over them with a sign "no plane here", that's just the illusion of obscurity (and hence the illusion of security). Major OSes that are widely distributed but which hide their source code are much more in the latter category.
As for Satellites-- their obscurity probably is worth something. It's only one link, and the need to have the broadcasting station is a huge barrier. On the other hand, they can be highly visible targets, and I'd suspect that they aren't as obscure as one would really like to be to think it grants you some security. They probably ought to start using, as a matter of course, real secure protocols.
-Rob
This is a problem that has already come to cause others harm. Almost three years ago, hackers seized control of a British military satellite and demanded ransom for it. All that is needed to communicate with these satellites is an antenna, and proper knowledge of the protocols involved. While these things are out of reach to script kiddie types, it's not that much of a stretch for the kind of people you really have to worry about (foreign governments and large/resourceful criminal organizations). So, you should think of these systems as being addressable by anyone. Consequently, I would take any and all lessons you can from the ways that people securely authenticate users on publicly-addressable computer systems.
For your security, this post has been encrypted with ROT-13, twice.
IS THERE A RISK OF DOS?
Yes, absolutely! Ham radio operators have done moonbounce and many of them routinely communicate via satellite (transmitting to a satellite and receiving signals from someone else transmitting to a satellite - "hamsat"). There are also RF amplifier designs that would surely overwhelm (or at least degrade) your signals. Anyone with technical knowledge of RF and some skills at putting a system together could DOS you. Of course, these signals could be traced so that the DOS could not last very long without serious risk to the perpetrator.
IS THERE A RISK OF DECIPHERING COMMAND CODES?
Again, yes. In order to decipher these codes all a one has to do is locate in the vicinity of your physical command center, buy (or build) a receiver capable of detecting the frequencies you use, and put up an antenna (under the guise of amateur radio if necessary). Now they can sniff your uplink and downlink. Once you have access to both of these it's only a matter of time and intelligence before they determine your data structure.
IS PHYSICAL SECURITY ENOUGH?
No. Information within a company can be likened to a conspiracy and no conspiracy is ever safe. Someone, at some time, will see their own self-interest as higher priority than the group's interest. A perfect example of this is CIA's Project Jennifer (the Hughes Glomar Explorer). The newsworthiness of the project overwhelmed some of the participants with a sense of their own self-interest and they told news agencies.
Someone at your facility has probably already told someone else NOT at your facility enough details to allow them to do your system harm, if they wished.
SHOULD THIS INFORMATION BE ENCRYPTED?
Yes, absolutely! What's more, it should be encrypted under a method that will allow the key to be changed on a regular basis.
Given the expense of losing control of a satellite, the costs of security would be a pittance in comparison. Given what you've told us about the signals security at your facility, I imagine that the physical security and network security (does anyone have a modem in their desktop so they can work from home?) is likewise not very good. I would recommend a thorough analysis of all of these.
No one ever had to evacuate a city because the solar panels broke!
Lets look at Iridium as an example:
Motorola controlled the Telemetry Tracking And Control (TTAC) function for Iridium's birds. The satellites were controlled through, of all things, SNMP! Yes, its true. SNMP issued commands controlled the basic functions of the satellite. Commands were issued from TTAC's to the birds as they passed overhead. One can only communicate when the satellite is over the horizon of the transmitting/receiving TTAC, you can't just broadcast a signal from anywhere and hope the satellite gets it. NExt, you can only communicate with a satellite thats listening. Power consumption is a critical issue in satellites (no 120v ac in space.) Therefore, the satellites only listen and transmit when they are overhead of a TTAC. The signal must be coming from or going to the general area of the TTAC (its directional). Because they communicate as they travel overhead, the distance involved, etc, this creates a distorted egg shaped signal "footprint" around the TTAC. When the bird is directly overhead, the footprint is shaped like a circle (for Iridium, approx 20 miles diameter), then back to an egg shape as the bird approaches the far horizen. Any HAM/hacker wanting to snoop or squash the TTAC signal must be in the general vacinity of the TTAC in order to be able to receive or transmit effectively.
Motorola had several issues that are probably prevalent thoughout the commercial sat industry. First, the TTAC stations WERE connected to the rest of the Motorola network, which in turned connected to 3rd party networks, and on an on. Even though Firewalls, ACL's were used, they were based on very general rules, usually restricting to broad networks. Also, dial-in was supported on routers throughout the network for maintenance, so the best way around the Firewalls would simply be Soc. engineering a router password and dial-up the TTAC router/switch.
This could be achieved by: Located the TTACS for the satellite in question, usually public info. Get any phone numbers at that location you can. WAR dial a range of numbers around the TTAC numbers and note any Cisco devices answering. Use the SE'd passwd on the discovered Cisco dialups until you find a winner. Once in, either swipe the control apps for your own transmitter/reviever, or perform a one time attack since you unlikely to get a second chance one they notice.
SIDE NOTE: There is NO chance of anyone ever using a satellite to crash into another bird. It takes motorola several months just to move 1 bird from orbit A into adjacent orbit B. Fuel is extremely limited on these things. Besides, picture the entire earth as a parking lot with 50,100 or even 500 hundred cars continuously driving around on it. What is the likely hood any of them will ever collide, much less run into each other. Now imagine it with each car having 1 gallon of gas to use. The logistics now become very clear.
Can someone effectively execute a DOS attack by uplinking to the satellite with a powerful signal
It's certainly possible, and it's called "jamming". This costs a lot for plain random troublemaking; it takes a steerable dish and a fairly high powered transmitter, with a big electric bill. It seems rather unlikely someone with that budget would spend it just to mess up a science experiment. But unless considerable effort goes into protecting a satellite, jamming it would be small potatoes for a military operation.
There are some substantial (but very secretive) defense contractors making radio and radar jammers for the US military. To jam a satellite using a fixed command frequency, you just point a dish at it and transmit at the same frequency with at least as much power as the actual command center. (I mean power delivered to the satellite antenna -- that's a product of the actual power and the transmitter dish's directionality.) The two signals basically add together, so if the jammer just sends a non-varying signal it's quite likely that the receiver will still be able to pick the commands off the top. But just about anything that varies without too much predictability will do for a jamming signal -- white noise, classical music, Slim Pickens yodeling, Howard Stern...
The most common method of defeating jamming is to change the frequency. Every so often, computers on the ground and in the satellite compute a psuedo-random number, and change to that frequency. It's easy to do that once or more a second, and the jammer is not going to be able to find the new frequency fast enough. (Assuming the number sequence is secure, against both espionage and cryptographic reverse-engineering.) However, if they _really_ want to knock you off the air, it's possible to transmit a very high powered broad-band signal to jam all the channels at once. If there are 1,000 possible channels, the jammer has to be 1,000 times as powerful. Do that to a US military satellite, and I think you will knock it out for a while, but: (1) in a few minutes the satellite orbit will take it out of view from your dish; (2) unless you're a nuclear power, eventually they'll get permission to send a cruise missile into your ground station; (3) That much broadband power will mess up other communications as well, and get other countries mad at you. There are stories that the Soviets used to play a little with our satellites and vice-versa, but nothing serious because both sides had too much to lose...
Another protection against jamming is to use a very directional receiving antenna, so any jammer would have to be on territory you control. This also substantially reduces the required transmitter strength. The problem is keeping that receiver dish pointed at home. In a satellite, you would have to also have an omnidirectional backup antenna, to use to re-gain control if the satellite tumbles. This makes it more complex and expensive than frequency-hopping.