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.
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.
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
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.
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
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 at a particular time. The SV therefore must know when and where it is itself in its orbit around the Earth so that it can accurately accomplish this feat. If the satellite were to lose its timing or location knowledge, it would essentially become lost and be potentially unable to communicate with the ground or carry out payload tasking.
Though not true in all cases, in most situations, to carry out payload tasking, a SV must maintain accurate knowledge of its position, its time, and which way it is facing, otherwise known as its attitude. Additionally, the SV must be able to maintain an attitude and position that allows for it to continue to fly as well as carry out its mission. Lastly and most importantly, a SV must do all of these things while keeping enough power stored on board to continue to do so.
A SV may maintain its timing in several ways. It is important to note that SVs may go through spans of time where all onboard computing functions are shut off in an attempt to recharge batteries with onboard solar panels. This and other circumstances can cause the computers on board to lose timing, which is important for the maintaining of communications, encryption, as well as position over the Earth. It is often not left only to computing devices, and sometimes devices such as atomic clocks can be used to keep track of the passage of time despite the powering off of computational devices.
Position and attitude knowledge can be tracked via devices such as star trackers or sun sensors that pretty much do exactly what they sound like they would. A star tracker is a device that uses knowledge of specific star positions and the reading of stellar lights to identify both where the SV may be in orbit and what its attitude may be. The sun sensor is a less accurate but similar type of device that used the sensing of light from our sun and its strength to make rough determinations of location on orbit as well as general attitude.
Maintaining both attitude and position is done via several methods. On complex or larger SVs, this may be done using actual propulsion. Propulsion is the use of active force to alter the course or attitude of a SV by pushing it one way or another. Another active method for attitude and course correction or adjustment is flywheels which store up energy and use that energy to essentially spin the wheels, generating inertia and altering the movement of the SV. Lastly there are torque rods, which are passive devices that are charged with energy to increase or decrease the SVs’ attraction to the Earth’s electromagnetic fields or gravity, as such slowly altering the position or attitude of the SV.
Maintaining these states of the spacecraft is obviously important for its flight life span as they help determine orbits, avoid potential collisions, and enable communication with ground stations. On the other hand, knowledge and maintenance of position and attitude may also be extremely important for the carrying out of mission tasking by a payload. It doesn’t do anyone any good for a satellite to maintain its orbit and avoid collision if it can’t get accurate attitude during camera shots by its payload. Pictures of stars or the moon aren’t going to be beneficial to a mission intent on ground observation over certain terrestrial areas of interest. Actually, it is easy to imagine certain imaging, position identifying, or signal verifying types of payload missions where knowledge of attitude and position might have to be even more accurate than when the SV is communicating with the ground.
Regardless of whether for communication, payload execution, or SV survival, the knowledge and maintenance of attitude and position as well as the operation of a payload require power. On many space vehicles, power is the most constraining attribute; after all, in space power comes from solar panels and batteries, there is no outlet to plug in to. This might mean that to preserve the operation of the SV in the long term, payload mission windows may have to be sacrificed in the short term to allow the SV to keep its solar panels facing the sun and gathering energy. It means that if a course correction is required to avoid a collision with another satellite and that maneuver drains a significant amount of power from the battery that the payload may have to stay inoperable for days, weeks, or months. It also means that in instances where power may become in issue and a ground station may not be in line of sight, the SV may have to make automated decisions on when to go into power saving or charging positions and forego communications with the ground or payload execution at all until batteries can be recharged to enable such activity.
Payload execution may not seem very power intensive when it is something as simple as snapping a picture, but onboard processing via computer processing units (CPUs), graphical processing units (GPUs), or field-programmable gate arrays (FPGAs) is often very power intensive and can even compete with communication as a top power consumer. On the other hand, a payload may be doing long windows of signal collection for a specific type of signal, which might require large amounts of receiving and writing to payload hard drives. The payload may also be an emitting payload instead of a sensing one. Where a sensing payload may listen for or monitor a signal or snap a picture, an emitting payload may itself be responsible for radiating a signal of its own which would certainly be more power intensive.
Space System Architectures
To accomplish a widening and varying array of mission sets from outer space, space systems come in vastly different architectures, enabling many types of operations. There is obviously the very straightforward one SV one ground station architecture pictured in Figure 1-3 which is essentially the same diagram as shown to illustrate the basic ground station SV concept. Here the one ground station tracks each pass of the one SV. It is important to note that despite potentially orbiting the Earth in a matter of hours, the SV will not always have an orbit that brings it within sight of the ground-based antenna.
Figure 1-8 shows how multiple ground stations at different locations might allow for the satellite to be communicated with on each of three orbits in succession. The ground station locations are represented by the circles.
Conclusion
This chapter has been an introduction to the rudimentary concepts of space systems and their basic components of ground stations and SVs. We covered how both the ground station and SV are actually comprised of multiple systems and that space systems themselves are systems comprised of systems of systems. The various basic architectures of space systems were covered and how multiple ground stations, SVs, or both impact space system operations. These space systems concepts and others that will be explored in the coming chapters will prepare the reader to frame cybersecurity challenges and solutions within the constraints and unique challenges of space operations.