Hi, I'm James Pavore. I'm a PhD student at Oxford University, where I research satellite
cybersecurity. And today, I want to talk about something called Space Situational Awareness,
or SSA. SSA is a type of data that we use to solve a problem, which is that space
is getting crowded. Today, there are tens of thousands of satellites and pieces of debris
and other objects in orbit that will whiz over your head every hour. And as space gets more
congested over the next decade, the number of objects is going to increase dramatically,
with the addition of constellations like OneWeb, Blue Origin, and Starlink changing the way we
think about low Earth orbit. As we put more satellites up there, the biggest challenge
will be dealing with the increasing risk of space debris collisions. Space debris are just like
bits of metal or rocket fragments or other things that fall off of the satellite during operations
or as part of a space mission. And they move at orbital velocities. So if they collide with
the satellite, they can cause it to break or even disintegrate, depending on the size of the collision.
And it's the second case that can lead to something that we call a cascade effect, whereby
a piece of debris crashes into a satellite, which creates more debris, which crash into more
satellites. And the worst case scenario, when space is as crowded as it's going to be in the next decade,
a debris cascade can severely constrain our access to either a particular orbit or even the space
as a whole. And that debris is not going anywhere. It can remain in orbit as a threat to satellites
for decades or centuries, depending on where it is. So to deal with this, we use space situational
awareness data. I'll talk about how that works and who gets it. And then I'll talk about why a cyber
attacker might target this critical data as a route to cause harm to specific satellites in orbit.
We'll run through a scenario where we actually kind of play through one of these attacks in
orbital simulations. And then I'll close by discussing mitigations that both industry players
and governments can use to protect and bring more trust into the SSA environment. So SSA as a concept
is very simple at its core. It's just understanding what's out there, whether that's a satellite or a
piece of debris or even a comet or an asteroid, depending on how you define it. It's essentially
a catalog of everything in space and where it's going. And we use SSA in every step of a satellite
mission, from the moment that we decide which orbit that we're going to launch our satellite
into, to the moment we retire our satellite into a graveyard orbit and try to avoid crashing into
other satellites when we turn it off. And two particularly important uses of SSA are conjunction
analysis and intelligence purposes. You use SSA to figure out when your satellite is going to
collide with a piece of debris so that you can steer it around it. And this is not trivial because
pieces of debris move. They're affected by friction or collisions with other pieces of debris.
So you need to constantly be updating your catalog so you know when you need to steer your satellite
and where. Additionally, I mentioned intelligence purposes. SSA is really useful if you want to know
if your adversaries are, say, launching a spy satellite that overpasses your territory or
testing anti-satellite weapons. So it's perhaps unsurprising that the dominant source of SSA data
today is the U.S. military, which operates the Space Surveillance Network, or SSN. The SSN consists
of a bunch of ground stations around the world with either radar systems or electro-optical
telescopes and even some satellites in orbit that are constantly scanning the sky for space debris.
The reason this is distributed across the globe is because to get a good catalog of space situational
awareness data, you need multiple observations of an object from multiple different vantage points
in different parts of the planet. And the U.S. military gets a huge advantage from this investment.
They're likely the only entity in the world who have access to ground-truth information describing
debris objects measuring 10 centimeters in diameter or even smaller. However, this edge does not come
cheap. We don't know exactly how much the U.S. military spends in the Space Surveillance Network,
but we know that the most recent upgrade to the system exceeded six billion dollars. And then in
fiscal year 2015 alone, they spent 1.6 billion dollars on procurement. This is all to say that
this is not a trivial effort. This is not picking up a telescope at Walmart and looking for pieces
of space debris. This is a very complicated technological endeavor that is beyond the means
of even most nation-states to pull off. The next most sophisticated SSA capability is probably
Russia's through the Russian Space Surveillance System. We don't know quite as much about like
what kind of objects they can see or what size, but we do have a sense of the network's capabilities
because we know where the ground stations are. And they're primarily in former Soviet territories or
countries that were friendly with the USSR prior to its collapse. This makes sense as a lot of the
groundwork was kind of laid for the system during the Soviet Union. But in recent years, Russia has
expressed skepticism in third-party data from like the U.S. military and has been shoring up their
own internal capabilities, including through the launch of satellites like this one, which was
widely expected to be a space surveillance system, although the Russian military has not confirmed
this. One other thing I just want to note while we're talking about Russian space situational
awareness, there is a civilian network that is ostensibly a collaboration between scientists
and universities. It's not super active today, and depending on who you ask, it's like deeply tied to
the Russian Academy of Sciences and kind of the Russia's civil military apparatus for space power,
or it's entirely independent. In either case, it's at least worth noting that there are some
civilian efforts to get space situational awareness data, as well as military efforts associated with
Russia. The final network I want to talk about is China's. They run a system through their PLA
Strategic Support Force unit. Interestingly, the PLA SSF is also responsible for China's offensive
cyber operations and a lot of other high-tech things that China does in military contexts.
Their network is relatively small. They are not remotely comparable to Russia or the United States
in terms of what they can see in space. And this makes sense, because unlike Russia and unlike the
United States, China has never really had much opportunity to expand beyond its borders, and so
it doesn't have those forward-deployed military bases for putting up telescopes. So what they've
been doing is pretty clever. They've been deploying these ships, which are essentially
mobile SSA stations. They take up international waters so they can get that global perspective
on the skies and compete with these other space powers, despite having significantly less
territorial reach. If you're not one of these three countries, you may have your own smaller
network. The EU is the next biggest, and then basically any country with a space program has
some degree of SSA capability. However, there are also some commercial actors that are starting to
sell SSA data. They'll claim that they've made some pretty significant technological breakthroughs
to startups. It's unclear how true that is or to what extent they could ever match the US military's
capability, but at least there's kind of a shift towards privatization that's starting to emerge
in this sector. In reality, though, today, if you run a satellite, chances are you get your SSA data
through a website like spacetrek.org or from someone who buys it, who gets it from this
website, and then resells it to you. spacetrek.org is a public website that's run by the US military,
and anyone with an account can log in and get access to space situational awareness data that's
pretty high quality, free of charge. The fundamental idea here is that if you share SSA data with
people, you prevent collisions in orbit, and you protect the environment. They're like terms of
service here, where you check a box that says, I promise I don't work for the North Korean military
or whatever. But fundamentally, the US government doesn't care. While it would be nifty to see a
North Korean satellite get destroyed by a piece of space debris, if the resulting cascade from
that collision threatens critical US communications missions or navigation missions, it's not worth the
collateral damage risk. And so there are strong incentives right now to share high quality SSA,
even though it costs an inordinate amount of money to get access to. So right now, the primary
format for sharing this data is something called a two-line element set or a TLE. TLEs were designed
to fit on 280-column punch cards, and the format has basically not changed since. It's very rare
in cybersecurity that you access a system that's backwards compatible with punch cards. So I
thought this is a pretty interesting aside. There are some efforts recently to update the format
because you actually have only so many objects you can track. There's like an ID field in a
two-line element set, and it's starting to fill up the space that's too crowded.
However, the core idea is probably always going to be the same. The two-line element set is intended
as input to what we call a propagator, which is essentially a model of how things move in orbit.
And two-line element sets are not physically meaningful on their own. They're like tied to
physical properties, but they're not directly descriptive of them. But instead, they're
intended as inputs into the system. And so a two-line element set is meaningless without a
propagator, and a propagator is useless without the two-line element set. If you use them together,
though, you are able to predict where an object will be in orbit with an accuracy of about a
kilometer over 72 hours, which is pretty good. It can get better in some cases and slightly worse
in others, but that's a good kind of rule of thumb for how accurate it will be. There are other
formats that are available. You can actually get better data from the U.S. military if you sign a
special data-sharing agreement with them. This agreement is super palatable if you're like a
commercial space operator, but it's less attractive if you're a foreign military. And this kind of
starts to hint at the trust problem here, right? So at its core, there are only a few people, a few
organizations in the world, who know what these objects are and where they're going. And everyone
else has to trust whatever they tell them. So this makes it kind of an intuitive target for a cyber
attacker. So why would you target SSA? Well, these databases are highly centralized, right? There are
only a few in the world, and if you change a line in one of them, you can affect what thousands of
organizations think outer space looks like. And those organizations probably can't catch you. They
don't have a capability, they don't have the billions of dollars investment needed to double
check where a small piece of debris is at any given point in time. And so they kind of just
have to have blind faith that the information in the database is true about what's in space,
because they can't see it themselves. So as an attacker, if you want to harm a satellite by, say,
hiding a debris collision and causing it to crash, you have essentially bytes on a computer somewhere
that you can change to have a very hard physical effect, blowing something up in outer space.
If we're thinking about ways to blow up satellites, and you compare deploying a couple of
zero days against the database, which isn't trivial, but certainly is feasible, versus building a
national space program, developing anti-satellite missiles, dealing with the diplomatic follow-up
from that, and deploying them accurately, it's pretty clear why a cyber attack factor might be
a more attractive way to target a satellite. So let's talk about a couple of threat models,
the sort of people who would engage in these attacks and what they would do and why.
So the first, I think, is the most intuitive, and that is the owner of the repository decides to
start lying to people. Since they're the only ones with access to a lot of this information,
they're the only ones whose sensors pick up these objects, if they start lying, it's very unlikely
they'll get caught in the act, and they can deceive whoever they want about the state of orbit.
This comes at a cost, right? If they get caught in a lie, their database is no longer trusted,
and people maybe are unwilling to rely on it, and they accidentally provide a legitimate degree
because they don't believe other conjunction assessments. But at its core, it's something
they could do. And a nation-state attacker who doesn't run one of these databases might say,
hey, I want to discredit this database. It would be great if the US military spent billions and
billions of dollars on an SSA network, and nobody believes what it says. And they could do that by,
making the sensors less accurate with malware. It doesn't need to be particularly targeted,
it just needs to change the measurements that are coming off of those radar sensors, such that the
predictions are inaccurate. Or if they have a space program, they could launch objects that are
deliberately designed to do nothing other than be difficult to track with radar or electro-optical
telescopes, to kind of discredit the overall utility of one of these databases. Finally,
if we're kind of talking about bread and butter cybersecurity, just some rando who wants to hack
a database somewhere, fundamentally, this is just aligning a database. Military databases are hard
to hack, but they're hardly unhackable. And additionally, this data doesn't just go directly
from the military to the satellite. It's often sold to third parties who repackage it and sell
it to individual satellite operators to incorporate into their integration processes. And so if you
compromise one of those later recipients' databases, you may have a similar effect that's a little bit
more targeted and a little bit easier to pull off. So when we talk about messing with this data,
what does that look like? What do you have to change to achieve what kind of goals? And what
can you achieve? So we're going to run through a very simple attack scenario. Our attacker's goal
is to cause harm to a specific satellite in orbit. There are two ways to go about this. The first one,
you've probably already guessed. If we see in that database that there's a piece of debris that will
collide with the satellite in the future, we can tamper with the contents of that database to make
it look like that piece of debris is no longer a threat. The result is a satellite operator moves
along blissfully ignorant of impending doom until a satellite collides with a piece of debris that
seems to come out of nowhere. From a physics perspective, this is trivial. If you change any
component of a two-line element set, there's a really good chance that over a 72-hour forecast
window, that debris object is going to be in a radically different place and no longer pose a
threat to the satellite. So we want to focus on a slightly more nuanced version of this attack
that's a bit more challenging and a bit more pernicious. So the idea here is we create a ghost
collision. We take an object that doesn't collide with a satellite and we tamper it just a tiny bit
to make it look like it will. The effect is that we call these guys in at 12 in the morning to
deal with an emergency and engage in a debris avoidance maneuver. This burns fuel on the
satellite, it causes mechanical wear and tear, it increases the cost and decreases the lifespan of
their space missions. This is a more credible attack than you might initially think. You might
have trouble imagining the U.S. military deciding to say, blow up an Iranian satellite by messing
with SSA data. But it's not that hard to believe that someone would just kind of tip the scale a
tiny bit. So that Iranian space missions are particularly unlucky with regard to how many
debris objects they have to dodge. And over time, this has the kind of slow burn effect that we see
space use in other contexts, like Stuxnet, which caused mechanical wear and tear on centrifuges for
a nuclear power slash weapons program. And you might imagine a similar thing targeting a space
program. So how do we go about doing this? Well, first we're going to start with some assumptions
to keep the simulation very simple for today. The first is that we'll assume the database has
already been compromised. Either the owner of the database is the one telling the lie, or someone
We're not fundamentally interested in how you compromise the database. We're going to target
data in the two-line element set format. This is a little bit not real world, in the sense that
people tend to use more precise MRIs for their conjunction analysis. But two-line element sets
are publicly available, which makes it easier to work with for research purposes. And fundamentally,
if you can tell a lie with data, the format that data is in doesn't really matter.
We're going to say that people trust the output of their conjunction analysis simulations.
In the real world, if you see a collision, you may call up the U.S. military and say,
hey, can you double check that this is actually going to happen? We'll assume that either that
double checking process has been compromised, you could say the U.S. military is the attacker,
or the victim doesn't do that for some reason. And then we're going to define the collision
pretty generously as a pass within one kilometer. You can do this much smaller. We've had success
with passes as low as 100 meters. But the reality is that a wider zone of collision increases the
likelihood of finding a candidate quickly from a computational complexity perspective.
And in this case, because two-line element sets are only that accurate anyway,
more precise is kind of meaningless. So here's our target. It's an Iridium satellite over the
Atlantic Ocean. And it has an orbit that looks something like this. And we're going to try to
an element in this debris field of 10,000 objects taken from spacetrack.org to see if we can make
one look like it'll collide with the satellite over the next 72 hours. To filter down these
objects, because we have a lot, we're going to only measure the time of closest approach for
objects that pass within this sphere. So let's go ahead and see what that looks like in the lab.
So what we're doing is we're looking for debris objects that pass within that zone,
and then we're seeing where they pass closest to the satellite. The intuition here is that
an object that already looks like it will pass closely would be easy to tamper with to create
one of those phantom collisions that we're trying to generate, because you'd have to only make small
changes to move its orbit, say, a couple hundred years in one direction or the other. Now, the size
of our debris field here is 10,000 objects. You can do this with a larger debris field. It just
takes longer to hunt down candidates, but you're also more likely to find a good candidate that
passes closer the bigger the debris field. So there's a bit of a trade-off between how much
computing time you want to put into this and how accurate of a collision you want to find.
Here I'm propagating for just a couple of days, I think 48 hours or something,
and we're going to take our top five candidates for manipulation and try to tamper with them.
So if we look at the results here, we see that our best candidate passes within 3.8 kilometers
of our target, which is excellent. This means we only have to modify this object's orbit by
three kilometers in the correct direction, and it'll look like it's going to collide with the
even when it's not. So that's the scale of the violin at this hour.
Now this initially sounds easy, right? You just change the bytes. But it's a little harder than
you would think, because we need to get this specific object into a new orbit over the next
72 hours. We need to change how it's moving through space pretty substantially in the database.
We also need to have it appear like it'll be in a specific location, that zone of collision,
at a specific time when our target satellite is also there. And we need to do all of this
with only making tiny modifications to the line in that database, right? We want it to
look like friction might have caused this object to shift. We don't want it to look like someone
just deleted their own database and created a completely brand new object. So this is a pretty
hard astrophysics problem. I don't think it's unsolvable, but it's definitely beyond me.
But what I can do is guess and check. So what I did is input a genetic algorithm,
which is essentially a fancy way of saying I threw things at the wall to see what would stick.
And we defined our individuals in this genetic algorithm as a set of characteristics that were
changes to four fields in the two-line element set. And the idea is that in each generation
of this genetic algorithm, we determine the likelihood that one of these changes gets
passed on to the children of this individual on the basis of a fitness function, which was
defined as the distance between our fake ghost debris object and the target we're trying to
collide with at the time of closest approach. Now, we could have added a stealth metric here
to minimize the amount we have to change these fields if we were particularly worried about
detection, if we were particularly worried that this was being monitored. But for simplicity
purposes, we set this as a very high bound and just a hard cap, that we weren't allowed to modify
any of these fields by more than 10%. In practice, we modify most of these fields by a fraction of a
percent, but eccentricity in particular tends to need to be modified a little bit more because of
the precision of the format. Although you can find collisions within much smaller zones, it comes at
the cost of more computational time. Once we've kind of run our scenario, we get an output that
looks like this. So in this case, we found a collision for our targeted object within three
generations that passes within a kilometer of our target. If you look at the malicious two-line
element set on the top and the original one on the bottom, you'll see that they're pretty similar.
And if someone wasn't actively looking for data tampering impacts, it'd be pretty hard to
identify that this object has been hacked to look like it's going somewhere it isn't. Let's see what
the result of that is in our simulations. So we'll see the objects kind of move along just like they
did before, but over time there's that slight difference such that at the time of closest
approach, our malicious debris object passes well within this sphere around the iridium satellite,
which is one kilometer across. And so at this point, we have caused a collision to appear like
it will happen. The iridium operator will steer their satellite, even though they don't have to,
and they'll increase their mission cost and decrease their mission lifespan.
So how do we protect against these kinds of attacks? How do we prevent this kind of manipulation?
If you're a satellite operator and you're thinking, how do I keep my SSA data secure?
There are a couple of things you can do. The first is to get higher quality data where you can to
enter into those data sharing agreements. This particular demonstration was made much easier by
the fact that our zone of collision was one kilometer. The smaller that zone of collision
gets, the more accurate your data is, the more likely an attacker is to have to work hard with
like a larger debris field or more genetic algorithm generations or bigger tampering effects
to find a collision that will trigger an alert. So you really increase the cost and the complexity
for the attacker, even if you don't fully get rid of the risk of someone lying to you.
You might also want to see if you can vet your data, right? There aren't any databases that
fully match the US militaries, but even something with like 30% coverage at least gives you a second
source for truth on those 30% of objects that they do know about. And you might think about
also comparing your internal data with the public data from the US government. So you can say, hey,
my database says a prediction that the US government doesn't, even though the source
data should be the same. That's a pretty good indicator of compromise. If you're a nation-state
actor, there are a couple of different ways to think about this. If you run an SSA database,
so if you're the US, Russia, or China, you need to understand that those bytes on a computer are
critical strategic resource that someone might try to mess with from a cybersecurity perspective.
They might do this to discredit your information, to cause harm to one of your own satellites,
or someone else's satellite. But fundamentally, as a nation, you have an obligation to recognize
the importance of these specific databases as some of the most important space data you hold.
Additionally, I think it's important to disavow any funny business in SSA. Right now, the US
military has a statement on their website that basically says that the data from spacetrack.org
could be manipulated at any time for national security purposes. And I understand the logic
behind this, but I think standing by SSA data is an important step towards protecting the space
environment in the future. And publicly disavowing and ascribing a diplomatic cost to getting caught
concealing or manipulating SSA data, I think is an important step towards credibly building a system
where people can trust what space looks like. Finally, if you're a smaller country, you might
not have a full space surveillance network, but you may have a couple of telescopes or a couple
of radar sensors that you can use to kind of randomly sample and audit specific objects and
say there's supposed to be a debris object there today. Is there anything? And use that to kind of
catch at least some tampering attacks in these databases and get a sense of their reliability.
So to sum things up, SSA is fundamentally about trust. There is someone out there who is the only
person who knows the truth about these objects and is telling it to you, and you have no way
fundamentally to get that physical reality and ground truth information for yourself.
This trust is intuitively abusable. You can change information in an SSA database
through some very basic orbital physics operations to make it tell a prophecy that isn't true, to
create a phantom collision, or to conceal an impending collision with catastrophic effects.
We think that we can fix this by recognizing that SSA is an information target that can be used to
cause physical effects in space, and so as a result, building responsibility and verification
into the SSA process is a key step towards recognizing that trust is as important as truth
in these databases. Thank you so much for listening to my presentation, and I'm happy to answer any
questions. Hopefully I've gotten you thinking about kind of interactions between the physics
of space and the cybersecurity properties.