© Jacob G. Oakley 2020

J. G. OakleyCybersecurity for Spacehttps://doi.org/10.1007/978-1-4842-5732-6_1

1. Space Systems

Jacob G. Oakley¹ 

(1)

Owens Cross Roads, AL, USA

Before I get into the specifics of space systems, I just want to make clear that this book is written with cybersecurity professionals in mind and by a cybersecurity professional. That is not to say that those who design and operate space vehicles (SVs) or the generally curious have nothing to gain from reading it. Quite the opposite in fact. This book is written with the intent of priming the cybersecurity community on the intricacies of space systems, their high difficulty and risk during operation, as well as the distinct challenges of security in outer space.

As such, there will be descriptions, illustrations, and scenarios involving space systems and their operation that will be at times simplified and potentially unrealistic. I am trying to educate the security perspective on the difficult task ahead regarding creating and implementing solutions to protect systems in space. Any space topics are covered only to the extent necessary to aid in that understanding. There is plenty of literature regarding designing and operating systems to fly in outer space, and if that topic interests you, as it does openly or secretly all nerds, I encourage you to read up on the fascinating subject. This book is my attempt to address what I feel is a gap in the cybersecurity community’s awareness for the growing presence of computers in outer space and a lack of comprehension for the implications of space operations on cybersecurity.

Tipping Point

We are currently at a precarious position in the evolution and accessibility of space operations to academic, commercial, and government entities. More and more computing platforms are being launched into orbit and beyond. Unfortunately, these systems, as a necessity, have a heavy focus on functionality, and any regard to cybersecurity is oftentimes a byproduct of attempts at safeguarding the space system from failure and not any malicious intent. This means that we are revisiting an era in computing where the operators and any operation passed to the device are trusted; after all, why would I do anything to damage my multimillion-dollar satellite program? Why would someone do that?

The problem is that plenty of people would do that, from hacktivists, cybercriminals, and nation state actors to commercial competitors engaging in industrial espionage. Exacerbating this potential nasty situation is the fact that everything is becoming increasingly connected; after all, why wouldn’t you want to check the status of your SV with a smart phone application? How else are you going to show off your space program to fellow academics or sell the accessibility of your space system to potential customers in the commercial world?

It is not hard to imagine that a large percentage of space operations moving forward will be inherently accessible for one reason or another to some system or systems on the Internet. Even if not, recent history is littered with examples of malicious code that has allowed the spread and infection of cyber attack effects across devices connected not to the Internet or even any other network at all.

Worst of all, the computational resources available to any would-be attacker are immense when compared to the available resources on a space system that could be dedicated in some way to cybersecurity. As we will cover more in depth later, once a malicious actor gains access to the computer on the ground that communicates with a space system, there is almost implicit trust and no further defense in depth for the space system or systems that communicate with that terrestrial computer.

An Introduction to Space Systems

The most basic exampl e of a space system is where there is a device on the ground transmitting to and/or receiving from a device in space that is transmitting and/or receiving. For the purpose of this book, we will refer to the device on the ground that transmits and/or receives as the ground station and will refer to the device in space that transmits or receives as the SV. Often nowadays, the ground station is where the SV is flown from—although it has not always been the case and will not always be the case that the SV is flown. For instance, if we go back to one of the most famous space systems, the Sputnik 1 satellite, it had no way of flying at all. It was shot into orbit and flew around the Earth with no ability for steering. In fact, it did not receive any instructions from a ground station at all, it just broadcast a radio wave signal that could be heard by anyone on Earth with a radio antenna tuned to the correct frequency.

This is a far cry from some of the extremely complex systems of today. Consider the International Space Station (ISS). It regularly makes maneuvers using onboard propulsion to move out of the way of space debris that is on a collision path with it. In the case of the ISS, it can be flown from on board the station itself as well as by individuals at a ground station on Earth. The orbital planes of the Earth are inhabited by SVs spanning the full spectrum of sophistication from derelict or antiquated satellites to complex constellations of multifunctional SVs. The simple example of one SV and one ground station is shown in Figure 1-1.

Figure 1-1

Basic Space System

The Ground Station Design

As you might imagine, ground stations come in varying shapes and sizes and levels of complexity. In the case of the Sputnik 1 space system, any home radio essentially operated as a ground station, receiving the beeping signal as the satellite flew overhead. The SV had no other functionality than to emit this beep, and all a ground station had to do for the mission of Sputnik 1 to be successful was for amateur radio operators on the ground to hear it via their radio ground stations. In the Sputnik 1 example, we would not say that the SV is actually communicating with the ground station, and certainly the ground station has no ability to communicate with Sputnik 1. The SV is simply broadcasting a repetitive radio signal that will never change.

When considering the more complex space systems of today however, the ground station may resemble something like what is shown in Figure 1-2. There is a software defined radio (SDR) responsible for receiving the signals from the SV and turning them into communications via demodulation. At this point, if there is encryption of the communications stream, it will then be decrypted and ultimately passed to a flight control computer running the software that communicates with and controls the SV and keeps track of its flight operation–related data. Potentially on the same computer—but as a different function of the ground station—would be the payload control, which handles the operation of the payload portion of the SV and keeps track of payload data being sent back down to Earth. Certainly, a single suite of software could be developed to handle both functions; however, most often Command and Data Handling (C&DH) and payload control are separated, either as separate functions running on the same computer or separate functions hosted on separate physical devices.

Figure 1-2

Detailed Space System View

One other facet of the ground station that I will not cover in great detail at this point is the antenna itself. This is the dish or other type of antennas that allows the SDR to receive the signal wave from the air and/or transmit it back to the SV. The process from the ground station perspective is just the opposite, where a communications stream is crafted using a protocol like, or in actuality, the Internet Protocol (IP) and then encrypted if necessary, then modulated and sent as a radio wave via the SDR and antennas into the air to the SV.

SV Design

SVs have evolved in parallel to ground station as far as complexity and capabilities go. The Sputnik 1 SV was essentially a shell with antennas on the outside and a battery and radio transmitter inside. A design more representative of modern SVs is shown in Figure 1-3. Similar to the ground station, there is a SDR to turn the radio wave signal into a communications stream. Next there is a computing device we will refer to as the command and data handler which receives the communications from the ground station and directs them as necessary to the flight computer or payload computer.

Figure 1-3

Communications Process

The flight computer is responsible for controlling the functions of the SV with regard to flight. What those functions are will be covered in the upcoming section on SV functions. The payload control computer is responsible for manipulating the payload of the SV. A payload is the portion of the SV carrying out the mission it was designed for. As an example of a payload, Figure 1-2 shows a camera. The payload computer would be responsible for telling the camera when to snap pictures, as well as storing those pictures and their metadata for later transmission to the ground.

Ground Station Functionality

Simply stated, the required functionality of the ground station is to communicate with the SV. Doing so requires the performance of several other tasks that we need to understand. Depending on the type of communication needed, the ground station may either have a stationary, nondirectional antenna or a movable directional antenna. With the radio signal from Sputnik 1, the waves were emitted by the SV in all directions, and therefore there were no directional requirements for the receipt of that signal by all the home radio antennas that had been tuned to the correct frequency.

The same can be said for modern-day satellite radio, that the receiving ground station has no need to directionally track the SV it is receiving signals from to do its geosynchronous orbit (more on this later). Using the example of our ground station in Figure 1-2 however, we are using a directional antenna to communicate with the SV which must slew the antenna in line with the passing SV and with more agility required as the orbit altitude of that SV decreases. With directional communications, we are talking to the SV by pointing the ground station transmitter receiver in line with the antenna on the SV which will do the same. This lets us utilize frequencies capable of higher bandwidth to take advantage of each time the satellite comes into view in the sky, also known as a pass (see Figure 1-4). To maintain directionality with the SV during the pass, we will need the ground station antenna to move in lock with the orbiting SV.

Figure 1-4

Diagram of a Pass

Communication with a SV moving relative to the Earth’s surface requires more than an ability for the ground station to move its antenna and take advantage of the full pass for a longer communication window. It also requires that the ground station have a really good idea of where the SV will start its pass so that it can already be facing the correct location on the horizon and not waste time spinning the antenna around. This situation becomes much more complex if you have a single ground station that will communicate with multiple satellites, since instead of simply waiting for one satellite to come over the horizon, it will have to address and deconflict multiple orbits.

Ground stations communicate with SVs in several ways, which we have already partially covered. In newer and complex systems, there is a need for both receiving and transmission of signals and ultimately communications. Depending on the configuration and capabilities of the SV, this may require the ground station to have an ability to not only transmit and receive but potentially do both simultaneously. In some instances, communications windows where a SV is in view of a ground station can be very short. In order to receive communications and thus tasking of the vehicle or downlinking of data from the vehicle to the ground, bidirectional communications make space operations much more efficient, though they do make the SV and ground station more complex.

This gets us into the other complex function of ground stations, tasking. The ground station is the interface between the humans using the SV and the vehicle itself. There are essentially two types of tasking. There are tasks for the SV flight and there are tasks for the SV payload. If we continue the example of a satellite with a camera payload, tasking the payload is pretty straightforward. I use the ground station to communicate tasks to the satellite about when and where to take pictures. As far as tasking the SV itself goes, I might need to task the satellite to alter its orbit slightly to get a better picture of a particular area of interest. I also might need to task the satellite with regard to downloading those pictures from the satellite or perhaps task the satellite with deleting older pictures I haven’t been able to download for one reason or another, as they are no longer relevant and needed.

SV Functionality

The SV in general has several required functions, some of which are similar to those of the ground station, such as having to maintain the ability to communicate allowing it to receive tasking. It also has to be able to carry out its mission as well as maintain communications with users on the ground and stay in the correct attitude, on the correct orbit, and achieve necessary positioning. It is necessary to simultaneously satisfy these constraints to maintain communications needs, maintain SV flight requirements, and enable payload operation. The payload refers to the portion of the SV specific to carrying out its mission such as taking pictures or recording signal data. The part of the spacecraft responsible for housing and controlling everything needed for the SV to fly is known as the bus; an example of this separation is shown in Figure 1-5.

Figure 1-5

Payload and Bus

Maintaining communications is done in much the same manner as is handled by the ground station; the SV needs to make sure its antenna responsible for communications with the ground station is directionally oriented, when necessary, with the ground antenna. It is worth noting that phased array antennas are becoming more common in ground stations and SVs, where antennas are roughly oriented and beam control is employed by the SV to simultaneously point tens of communications beams to ground terminals located on the Earth. However, for our example, during the communications window of a pass, the SV needs to make sure it transmits and receives as necessary to offload payload and flight data as well as take on tasking. In certain instances, SVs may have a payload sensor on one end and a communication antenna on the opposite. This would mean that during passes over ground stations, the satellite would need to rotate its communication antenna toward the Earth and, after its pass, begin orienting the opposite side, with, say, a camera, back toward the Earth to carry out its tasked mission of taking a picture of a particular place