[00:05.790 --> 00:11.370]  Hi, I'm James Pavore. I'm a PhD student at Oxford University, where I research satellite
[00:11.370 --> 00:17.130]  cybersecurity. And today, I want to talk about something called Space Situational Awareness,
[00:17.130 --> 00:23.690]  or SSA. SSA is a type of data that we use to solve a problem, which is that space
[00:23.690 --> 00:29.630]  is getting crowded. Today, there are tens of thousands of satellites and pieces of debris
[00:29.630 --> 00:35.050]  and other objects in orbit that will whiz over your head every hour. And as space gets more
[00:35.050 --> 00:39.050]  congested over the next decade, the number of objects is going to increase dramatically,
[00:39.050 --> 00:44.510]  with the addition of constellations like OneWeb, Blue Origin, and Starlink changing the way we
[00:44.510 --> 00:49.630]  think about low Earth orbit. As we put more satellites up there, the biggest challenge
[00:49.630 --> 00:54.650]  will be dealing with the increasing risk of space debris collisions. Space debris are just like
[00:54.650 --> 01:00.290]  bits of metal or rocket fragments or other things that fall off of the satellite during operations
[01:00.290 --> 01:04.810]  or as part of a space mission. And they move at orbital velocities. So if they collide with
[01:04.810 --> 01:10.270]  the satellite, they can cause it to break or even disintegrate, depending on the size of the collision.
[01:10.570 --> 01:14.910]  And it's the second case that can lead to something that we call a cascade effect, whereby
[01:15.630 --> 01:19.910]  a piece of debris crashes into a satellite, which creates more debris, which crash into more
[01:19.910 --> 01:25.810]  satellites. And the worst case scenario, when space is as crowded as it's going to be in the next decade,
[01:25.930 --> 01:31.690]  a debris cascade can severely constrain our access to either a particular orbit or even the space
[01:31.690 --> 01:37.130]  as a whole. And that debris is not going anywhere. It can remain in orbit as a threat to satellites
[01:37.130 --> 01:43.850]  for decades or centuries, depending on where it is. So to deal with this, we use space situational
[01:43.850 --> 01:48.990]  awareness data. I'll talk about how that works and who gets it. And then I'll talk about why a cyber
[01:48.990 --> 01:54.490]  attacker might target this critical data as a route to cause harm to specific satellites in orbit.
[01:54.490 --> 01:58.590]  We'll run through a scenario where we actually kind of play through one of these attacks in
[01:58.590 --> 02:03.830]  orbital simulations. And then I'll close by discussing mitigations that both industry players
[02:03.830 --> 02:11.370]  and governments can use to protect and bring more trust into the SSA environment. So SSA as a concept
[02:11.370 --> 02:17.970]  is very simple at its core. It's just understanding what's out there, whether that's a satellite or a
[02:17.970 --> 02:22.490]  piece of debris or even a comet or an asteroid, depending on how you define it. It's essentially
[02:22.730 --> 02:28.970]  a catalog of everything in space and where it's going. And we use SSA in every step of a satellite
[02:28.970 --> 02:33.630]  mission, from the moment that we decide which orbit that we're going to launch our satellite
[02:33.630 --> 02:38.670]  into, to the moment we retire our satellite into a graveyard orbit and try to avoid crashing into
[02:38.670 --> 02:44.310]  other satellites when we turn it off. And two particularly important uses of SSA are conjunction
[02:44.310 --> 02:49.790]  analysis and intelligence purposes. You use SSA to figure out when your satellite is going to
[02:49.790 --> 02:54.670]  collide with a piece of debris so that you can steer it around it. And this is not trivial because
[02:54.670 --> 02:59.730]  pieces of debris move. They're affected by friction or collisions with other pieces of debris.
[02:59.730 --> 03:03.950]  So you need to constantly be updating your catalog so you know when you need to steer your satellite
[03:03.950 --> 03:09.870]  and where. Additionally, I mentioned intelligence purposes. SSA is really useful if you want to know
[03:09.870 --> 03:14.730]  if your adversaries are, say, launching a spy satellite that overpasses your territory or
[03:14.730 --> 03:20.470]  testing anti-satellite weapons. So it's perhaps unsurprising that the dominant source of SSA data
[03:20.470 --> 03:27.110]  today is the U.S. military, which operates the Space Surveillance Network, or SSN. The SSN consists
[03:27.110 --> 03:31.550]  of a bunch of ground stations around the world with either radar systems or electro-optical
[03:31.550 --> 03:37.110]  telescopes and even some satellites in orbit that are constantly scanning the sky for space debris.
[03:37.110 --> 03:42.350]  The reason this is distributed across the globe is because to get a good catalog of space situational
[03:42.350 --> 03:46.890]  awareness data, you need multiple observations of an object from multiple different vantage points
[03:46.890 --> 03:52.430]  in different parts of the planet. And the U.S. military gets a huge advantage from this investment.
[03:52.430 --> 03:57.470]  They're likely the only entity in the world who have access to ground-truth information describing
[03:57.470 --> 04:03.530]  debris objects measuring 10 centimeters in diameter or even smaller. However, this edge does not come
[04:03.530 --> 04:08.450]  cheap. We don't know exactly how much the U.S. military spends in the Space Surveillance Network,
[04:08.450 --> 04:13.630]  but we know that the most recent upgrade to the system exceeded six billion dollars. And then in
[04:13.630 --> 04:19.170]  fiscal year 2015 alone, they spent 1.6 billion dollars on procurement. This is all to say that
[04:19.170 --> 04:24.070]  this is not a trivial effort. This is not picking up a telescope at Walmart and looking for pieces
[04:24.070 --> 04:29.610]  of space debris. This is a very complicated technological endeavor that is beyond the means
[04:29.610 --> 04:36.550]  of even most nation-states to pull off. The next most sophisticated SSA capability is probably
[04:36.550 --> 04:41.150]  Russia's through the Russian Space Surveillance System. We don't know quite as much about like
[04:41.150 --> 04:45.890]  what kind of objects they can see or what size, but we do have a sense of the network's capabilities
[04:45.890 --> 04:50.610]  because we know where the ground stations are. And they're primarily in former Soviet territories or
[04:50.610 --> 04:55.670]  countries that were friendly with the USSR prior to its collapse. This makes sense as a lot of the
[04:55.670 --> 05:00.650]  groundwork was kind of laid for the system during the Soviet Union. But in recent years, Russia has
[05:00.650 --> 05:05.550]  expressed skepticism in third-party data from like the U.S. military and has been shoring up their
[05:05.550 --> 05:10.350]  own internal capabilities, including through the launch of satellites like this one, which was
[05:10.350 --> 05:15.630]  widely expected to be a space surveillance system, although the Russian military has not confirmed
[05:15.630 --> 05:19.750]  this. One other thing I just want to note while we're talking about Russian space situational
[05:19.750 --> 05:25.010]  awareness, there is a civilian network that is ostensibly a collaboration between scientists
[05:25.010 --> 05:30.930]  and universities. It's not super active today, and depending on who you ask, it's like deeply tied to
[05:30.930 --> 05:36.430]  the Russian Academy of Sciences and kind of the Russia's civil military apparatus for space power,
[05:36.430 --> 05:40.790]  or it's entirely independent. In either case, it's at least worth noting that there are some
[05:40.790 --> 05:45.110]  civilian efforts to get space situational awareness data, as well as military efforts associated with
[05:45.110 --> 05:51.690]  Russia. The final network I want to talk about is China's. They run a system through their PLA
[05:51.690 --> 05:57.730]  Strategic Support Force unit. Interestingly, the PLA SSF is also responsible for China's offensive
[05:57.730 --> 06:02.830]  cyber operations and a lot of other high-tech things that China does in military contexts.
[06:03.030 --> 06:07.850]  Their network is relatively small. They are not remotely comparable to Russia or the United States
[06:07.850 --> 06:12.830]  in terms of what they can see in space. And this makes sense, because unlike Russia and unlike the
[06:12.830 --> 06:18.490]  United States, China has never really had much opportunity to expand beyond its borders, and so
[06:18.490 --> 06:23.030]  it doesn't have those forward-deployed military bases for putting up telescopes. So what they've
[06:23.030 --> 06:26.690]  been doing is pretty clever. They've been deploying these ships, which are essentially
[06:26.690 --> 06:32.650]  mobile SSA stations. They take up international waters so they can get that global perspective
[06:32.650 --> 06:37.630]  on the skies and compete with these other space powers, despite having significantly less
[06:37.630 --> 06:44.350]  territorial reach. If you're not one of these three countries, you may have your own smaller
[06:44.350 --> 06:48.630]  network. The EU is the next biggest, and then basically any country with a space program has
[06:48.630 --> 06:54.450]  some degree of SSA capability. However, there are also some commercial actors that are starting to
[06:54.450 --> 06:59.390]  sell SSA data. They'll claim that they've made some pretty significant technological breakthroughs
[06:59.390 --> 07:05.110]  to startups. It's unclear how true that is or to what extent they could ever match the US military's
[07:05.110 --> 07:09.710]  capability, but at least there's kind of a shift towards privatization that's starting to emerge
[07:09.710 --> 07:15.990]  in this sector. In reality, though, today, if you run a satellite, chances are you get your SSA data
[07:15.990 --> 07:20.430]  through a website like spacetrek.org or from someone who buys it, who gets it from this
[07:20.430 --> 07:27.150]  website, and then resells it to you. spacetrek.org is a public website that's run by the US military,
[07:27.150 --> 07:31.350]  and anyone with an account can log in and get access to space situational awareness data that's
[07:31.350 --> 07:37.470]  pretty high quality, free of charge. The fundamental idea here is that if you share SSA data with
[07:37.470 --> 07:41.450]  people, you prevent collisions in orbit, and you protect the environment. They're like terms of
[07:41.450 --> 07:45.530]  service here, where you check a box that says, I promise I don't work for the North Korean military
[07:45.530 --> 07:50.670]  or whatever. But fundamentally, the US government doesn't care. While it would be nifty to see a
[07:50.670 --> 07:55.450]  North Korean satellite get destroyed by a piece of space debris, if the resulting cascade from
[07:55.450 --> 08:00.930]  that collision threatens critical US communications missions or navigation missions, it's not worth the
[08:00.930 --> 08:06.590]  collateral damage risk. And so there are strong incentives right now to share high quality SSA,
[08:06.590 --> 08:12.630]  even though it costs an inordinate amount of money to get access to. So right now, the primary
[08:12.630 --> 08:18.550]  format for sharing this data is something called a two-line element set or a TLE. TLEs were designed
[08:18.550 --> 08:24.590]  to fit on 280-column punch cards, and the format has basically not changed since. It's very rare
[08:24.590 --> 08:29.930]  in cybersecurity that you access a system that's backwards compatible with punch cards. So I
[08:29.930 --> 08:34.810]  thought this is a pretty interesting aside. There are some efforts recently to update the format
[08:34.810 --> 08:39.610]  because you actually have only so many objects you can track. There's like an ID field in a
[08:39.610 --> 08:43.310]  two-line element set, and it's starting to fill up the space that's too crowded.
[08:43.570 --> 08:48.590]  However, the core idea is probably always going to be the same. The two-line element set is intended
[08:48.590 --> 08:55.090]  as input to what we call a propagator, which is essentially a model of how things move in orbit.
[08:55.250 --> 08:59.270]  And two-line element sets are not physically meaningful on their own. They're like tied to
[08:59.270 --> 09:02.650]  physical properties, but they're not directly descriptive of them. But instead, they're
[09:02.650 --> 09:07.110]  intended as inputs into the system. And so a two-line element set is meaningless without a
[09:07.110 --> 09:11.550]  propagator, and a propagator is useless without the two-line element set. If you use them together,
[09:11.550 --> 09:15.970]  though, you are able to predict where an object will be in orbit with an accuracy of about a
[09:15.970 --> 09:20.930]  kilometer over 72 hours, which is pretty good. It can get better in some cases and slightly worse
[09:20.930 --> 09:26.190]  in others, but that's a good kind of rule of thumb for how accurate it will be. There are other
[09:26.190 --> 09:31.110]  formats that are available. You can actually get better data from the U.S. military if you sign a
[09:31.110 --> 09:34.950]  special data-sharing agreement with them. This agreement is super palatable if you're like a
[09:34.950 --> 09:39.950]  commercial space operator, but it's less attractive if you're a foreign military. And this kind of
[09:39.950 --> 09:44.990]  starts to hint at the trust problem here, right? So at its core, there are only a few people, a few
[09:44.990 --> 09:49.890]  organizations in the world, who know what these objects are and where they're going. And everyone
[09:49.890 --> 09:56.990]  else has to trust whatever they tell them. So this makes it kind of an intuitive target for a cyber
[09:56.990 --> 10:02.910]  attacker. So why would you target SSA? Well, these databases are highly centralized, right? There are
[10:02.910 --> 10:07.230]  only a few in the world, and if you change a line in one of them, you can affect what thousands of
[10:07.230 --> 10:13.170]  organizations think outer space looks like. And those organizations probably can't catch you. They
[10:13.170 --> 10:17.810]  don't have a capability, they don't have the billions of dollars investment needed to double
[10:17.810 --> 10:22.890]  check where a small piece of debris is at any given point in time. And so they kind of just
[10:22.890 --> 10:27.750]  have to have blind faith that the information in the database is true about what's in space,
[10:27.750 --> 10:32.550]  because they can't see it themselves. So as an attacker, if you want to harm a satellite by, say,
[10:32.550 --> 10:37.590]  hiding a debris collision and causing it to crash, you have essentially bytes on a computer somewhere
[10:37.590 --> 10:43.710]  that you can change to have a very hard physical effect, blowing something up in outer space.
[10:43.730 --> 10:47.350]  If we're thinking about ways to blow up satellites, and you compare deploying a couple of
[10:47.350 --> 10:52.510]  zero days against the database, which isn't trivial, but certainly is feasible, versus building a
[10:52.510 --> 10:56.250]  national space program, developing anti-satellite missiles, dealing with the diplomatic follow-up
[10:56.250 --> 11:01.330]  from that, and deploying them accurately, it's pretty clear why a cyber attack factor might be
[11:01.690 --> 11:06.910]  a more attractive way to target a satellite. So let's talk about a couple of threat models,
[11:06.910 --> 11:10.430]  the sort of people who would engage in these attacks and what they would do and why.
[11:10.510 --> 11:15.090]  So the first, I think, is the most intuitive, and that is the owner of the repository decides to
[11:15.090 --> 11:19.890]  start lying to people. Since they're the only ones with access to a lot of this information,
[11:19.890 --> 11:24.910]  they're the only ones whose sensors pick up these objects, if they start lying, it's very unlikely
[11:24.910 --> 11:29.230]  they'll get caught in the act, and they can deceive whoever they want about the state of orbit.
[11:29.230 --> 11:33.610]  This comes at a cost, right? If they get caught in a lie, their database is no longer trusted,
[11:33.610 --> 11:38.670]  and people maybe are unwilling to rely on it, and they accidentally provide a legitimate degree
[11:38.670 --> 11:42.450]  because they don't believe other conjunction assessments. But at its core, it's something
[11:42.450 --> 11:47.410]  they could do. And a nation-state attacker who doesn't run one of these databases might say,
[11:47.410 --> 11:51.650]  hey, I want to discredit this database. It would be great if the US military spent billions and
[11:51.650 --> 11:57.150]  billions of dollars on an SSA network, and nobody believes what it says. And they could do that by,
[11:57.150 --> 12:00.910]  making the sensors less accurate with malware. It doesn't need to be particularly targeted,
[12:00.910 --> 12:05.970]  it just needs to change the measurements that are coming off of those radar sensors, such that the
[12:05.970 --> 12:10.110]  predictions are inaccurate. Or if they have a space program, they could launch objects that are
[12:10.110 --> 12:15.270]  deliberately designed to do nothing other than be difficult to track with radar or electro-optical
[12:15.270 --> 12:21.090]  telescopes, to kind of discredit the overall utility of one of these databases. Finally,
[12:21.090 --> 12:24.890]  if we're kind of talking about bread and butter cybersecurity, just some rando who wants to hack
[12:24.990 --> 12:30.870]  a database somewhere, fundamentally, this is just aligning a database. Military databases are hard
[12:30.870 --> 12:35.790]  to hack, but they're hardly unhackable. And additionally, this data doesn't just go directly
[12:35.790 --> 12:40.370]  from the military to the satellite. It's often sold to third parties who repackage it and sell
[12:40.370 --> 12:45.750]  it to individual satellite operators to incorporate into their integration processes. And so if you
[12:45.750 --> 12:50.610]  compromise one of those later recipients' databases, you may have a similar effect that's a little bit
[12:50.610 --> 12:56.110]  more targeted and a little bit easier to pull off. So when we talk about messing with this data,
[12:56.110 --> 12:59.850]  what does that look like? What do you have to change to achieve what kind of goals? And what
[12:59.850 --> 13:05.370]  can you achieve? So we're going to run through a very simple attack scenario. Our attacker's goal
[13:05.370 --> 13:10.970]  is to cause harm to a specific satellite in orbit. There are two ways to go about this. The first one,
[13:10.970 --> 13:15.990]  you've probably already guessed. If we see in that database that there's a piece of debris that will
[13:15.990 --> 13:20.330]  collide with the satellite in the future, we can tamper with the contents of that database to make
[13:20.330 --> 13:24.910]  it look like that piece of debris is no longer a threat. The result is a satellite operator moves
[13:24.910 --> 13:29.730]  along blissfully ignorant of impending doom until a satellite collides with a piece of debris that
[13:29.730 --> 13:35.610]  seems to come out of nowhere. From a physics perspective, this is trivial. If you change any
[13:36.090 --> 13:40.950]  component of a two-line element set, there's a really good chance that over a 72-hour forecast
[13:40.950 --> 13:45.530]  window, that debris object is going to be in a radically different place and no longer pose a
[13:45.530 --> 13:49.850]  threat to the satellite. So we want to focus on a slightly more nuanced version of this attack
[13:49.850 --> 13:56.430]  that's a bit more challenging and a bit more pernicious. So the idea here is we create a ghost
[13:56.430 --> 14:02.030]  collision. We take an object that doesn't collide with a satellite and we tamper it just a tiny bit
[14:02.030 --> 14:06.750]  to make it look like it will. The effect is that we call these guys in at 12 in the morning to
[14:06.750 --> 14:12.410]  deal with an emergency and engage in a debris avoidance maneuver. This burns fuel on the
[14:12.410 --> 14:17.460]  satellite, it causes mechanical wear and tear, it increases the cost and decreases the lifespan of
[14:17.460 --> 14:23.220]  their space missions. This is a more credible attack than you might initially think. You might
[14:23.220 --> 14:28.120]  have trouble imagining the U.S. military deciding to say, blow up an Iranian satellite by messing
[14:28.120 --> 14:33.500]  with SSA data. But it's not that hard to believe that someone would just kind of tip the scale a
[14:33.500 --> 14:38.680]  tiny bit. So that Iranian space missions are particularly unlucky with regard to how many
[14:38.680 --> 14:43.960]  debris objects they have to dodge. And over time, this has the kind of slow burn effect that we see
[14:43.960 --> 14:50.200]  space use in other contexts, like Stuxnet, which caused mechanical wear and tear on centrifuges for
[14:50.320 --> 14:55.840]  a nuclear power slash weapons program. And you might imagine a similar thing targeting a space
[14:55.840 --> 15:01.760]  program. So how do we go about doing this? Well, first we're going to start with some assumptions
[15:01.760 --> 15:06.860]  to keep the simulation very simple for today. The first is that we'll assume the database has
[15:06.860 --> 15:11.020]  already been compromised. Either the owner of the database is the one telling the lie, or someone
[15:11.560 --> 15:16.520]  We're not fundamentally interested in how you compromise the database. We're going to target
[15:16.520 --> 15:23.780]  data in the two-line element set format. This is a little bit not real world, in the sense that
[15:23.780 --> 15:28.380]  people tend to use more precise MRIs for their conjunction analysis. But two-line element sets
[15:28.380 --> 15:33.780]  are publicly available, which makes it easier to work with for research purposes. And fundamentally,
[15:33.780 --> 15:38.280]  if you can tell a lie with data, the format that data is in doesn't really matter.
[15:39.400 --> 15:43.300]  We're going to say that people trust the output of their conjunction analysis simulations.
[15:43.460 --> 15:47.340]  In the real world, if you see a collision, you may call up the U.S. military and say,
[15:47.340 --> 15:51.880]  hey, can you double check that this is actually going to happen? We'll assume that either that
[15:51.880 --> 15:56.080]  double checking process has been compromised, you could say the U.S. military is the attacker,
[15:56.080 --> 16:00.800]  or the victim doesn't do that for some reason. And then we're going to define the collision
[16:00.800 --> 16:05.820]  pretty generously as a pass within one kilometer. You can do this much smaller. We've had success
[16:05.820 --> 16:13.000]  with passes as low as 100 meters. But the reality is that a wider zone of collision increases the
[16:13.000 --> 16:17.880]  likelihood of finding a candidate quickly from a computational complexity perspective.
[16:18.080 --> 16:21.300]  And in this case, because two-line element sets are only that accurate anyway,
[16:21.300 --> 16:27.940]  more precise is kind of meaningless. So here's our target. It's an Iridium satellite over the
[16:27.940 --> 16:32.910]  Atlantic Ocean. And it has an orbit that looks something like this. And we're going to try to
[16:32.910 --> 16:38.930]  an element in this debris field of 10,000 objects taken from spacetrack.org to see if we can make
[16:38.930 --> 16:44.030]  one look like it'll collide with the satellite over the next 72 hours. To filter down these
[16:44.030 --> 16:48.570]  objects, because we have a lot, we're going to only measure the time of closest approach for
[16:48.570 --> 16:52.950]  objects that pass within this sphere. So let's go ahead and see what that looks like in the lab.
[16:53.030 --> 16:56.570]  So what we're doing is we're looking for debris objects that pass within that zone,
[16:56.570 --> 17:00.610]  and then we're seeing where they pass closest to the satellite. The intuition here is that
[17:00.610 --> 17:05.330]  an object that already looks like it will pass closely would be easy to tamper with to create
[17:05.330 --> 17:09.330]  one of those phantom collisions that we're trying to generate, because you'd have to only make small
[17:09.330 --> 17:14.950]  changes to move its orbit, say, a couple hundred years in one direction or the other. Now, the size
[17:14.950 --> 17:18.950]  of our debris field here is 10,000 objects. You can do this with a larger debris field. It just
[17:18.950 --> 17:24.130]  takes longer to hunt down candidates, but you're also more likely to find a good candidate that
[17:24.130 --> 17:27.590]  passes closer the bigger the debris field. So there's a bit of a trade-off between how much
[17:27.590 --> 17:31.670]  computing time you want to put into this and how accurate of a collision you want to find.
[17:32.470 --> 17:36.290]  Here I'm propagating for just a couple of days, I think 48 hours or something,
[17:36.290 --> 17:40.490]  and we're going to take our top five candidates for manipulation and try to tamper with them.
[17:40.550 --> 17:45.510]  So if we look at the results here, we see that our best candidate passes within 3.8 kilometers
[17:45.510 --> 17:50.450]  of our target, which is excellent. This means we only have to modify this object's orbit by
[17:50.450 --> 17:55.030]  three kilometers in the correct direction, and it'll look like it's going to collide with the
[17:55.490 --> 17:59.690]  even when it's not. So that's the scale of the violin at this hour.
[17:59.830 --> 18:04.350]  Now this initially sounds easy, right? You just change the bytes. But it's a little harder than
[18:04.350 --> 18:09.230]  you would think, because we need to get this specific object into a new orbit over the next
[18:09.230 --> 18:14.230]  72 hours. We need to change how it's moving through space pretty substantially in the database.
[18:14.350 --> 18:19.310]  We also need to have it appear like it'll be in a specific location, that zone of collision,
[18:19.310 --> 18:23.930]  at a specific time when our target satellite is also there. And we need to do all of this
[18:23.930 --> 18:28.830]  with only making tiny modifications to the line in that database, right? We want it to
[18:28.830 --> 18:32.190]  look like friction might have caused this object to shift. We don't want it to look like someone
[18:32.190 --> 18:37.610]  just deleted their own database and created a completely brand new object. So this is a pretty
[18:37.610 --> 18:42.910]  hard astrophysics problem. I don't think it's unsolvable, but it's definitely beyond me.
[18:42.970 --> 18:47.650]  But what I can do is guess and check. So what I did is input a genetic algorithm,
[18:47.650 --> 18:51.870]  which is essentially a fancy way of saying I threw things at the wall to see what would stick.
[18:51.870 --> 18:58.010]  And we defined our individuals in this genetic algorithm as a set of characteristics that were
[18:58.010 --> 19:03.990]  changes to four fields in the two-line element set. And the idea is that in each generation
[19:03.990 --> 19:08.110]  of this genetic algorithm, we determine the likelihood that one of these changes gets
[19:08.110 --> 19:13.810]  passed on to the children of this individual on the basis of a fitness function, which was
[19:13.810 --> 19:20.410]  defined as the distance between our fake ghost debris object and the target we're trying to
[19:20.410 --> 19:24.970]  collide with at the time of closest approach. Now, we could have added a stealth metric here
[19:24.970 --> 19:29.490]  to minimize the amount we have to change these fields if we were particularly worried about
[19:29.490 --> 19:33.190]  detection, if we were particularly worried that this was being monitored. But for simplicity
[19:33.190 --> 19:38.170]  purposes, we set this as a very high bound and just a hard cap, that we weren't allowed to modify
[19:38.170 --> 19:43.990]  any of these fields by more than 10%. In practice, we modify most of these fields by a fraction of a
[19:43.990 --> 19:49.050]  percent, but eccentricity in particular tends to need to be modified a little bit more because of
[19:49.050 --> 19:54.390]  the precision of the format. Although you can find collisions within much smaller zones, it comes at
[19:54.390 --> 19:59.670]  the cost of more computational time. Once we've kind of run our scenario, we get an output that
[19:59.670 --> 20:05.290]  looks like this. So in this case, we found a collision for our targeted object within three
[20:05.290 --> 20:09.490]  generations that passes within a kilometer of our target. If you look at the malicious two-line
[20:09.490 --> 20:13.850]  element set on the top and the original one on the bottom, you'll see that they're pretty similar.
[20:13.850 --> 20:18.290]  And if someone wasn't actively looking for data tampering impacts, it'd be pretty hard to
[20:18.290 --> 20:24.350]  identify that this object has been hacked to look like it's going somewhere it isn't. Let's see what
[20:24.350 --> 20:28.590]  the result of that is in our simulations. So we'll see the objects kind of move along just like they
[20:28.590 --> 20:32.650]  did before, but over time there's that slight difference such that at the time of closest
[20:32.650 --> 20:37.710]  approach, our malicious debris object passes well within this sphere around the iridium satellite,
[20:37.710 --> 20:43.530]  which is one kilometer across. And so at this point, we have caused a collision to appear like
[20:43.530 --> 20:47.750]  it will happen. The iridium operator will steer their satellite, even though they don't have to,
[20:47.750 --> 20:50.870]  and they'll increase their mission cost and decrease their mission lifespan.
[20:51.490 --> 20:56.010]  So how do we protect against these kinds of attacks? How do we prevent this kind of manipulation?
[20:56.530 --> 21:00.750]  If you're a satellite operator and you're thinking, how do I keep my SSA data secure?
[21:00.750 --> 21:05.250]  There are a couple of things you can do. The first is to get higher quality data where you can to
[21:05.250 --> 21:10.370]  enter into those data sharing agreements. This particular demonstration was made much easier by
[21:10.370 --> 21:14.490]  the fact that our zone of collision was one kilometer. The smaller that zone of collision
[21:14.490 --> 21:19.690]  gets, the more accurate your data is, the more likely an attacker is to have to work hard with
[21:19.690 --> 21:24.470]  like a larger debris field or more genetic algorithm generations or bigger tampering effects
[21:24.470 --> 21:29.250]  to find a collision that will trigger an alert. So you really increase the cost and the complexity
[21:29.250 --> 21:33.770]  for the attacker, even if you don't fully get rid of the risk of someone lying to you.
[21:34.170 --> 21:38.130]  You might also want to see if you can vet your data, right? There aren't any databases that
[21:38.130 --> 21:43.450]  fully match the US militaries, but even something with like 30% coverage at least gives you a second
[21:43.450 --> 21:48.250]  source for truth on those 30% of objects that they do know about. And you might think about
[21:48.250 --> 21:53.890]  also comparing your internal data with the public data from the US government. So you can say, hey,
[21:53.890 --> 21:57.730]  my database says a prediction that the US government doesn't, even though the source
[21:57.730 --> 22:03.570]  data should be the same. That's a pretty good indicator of compromise. If you're a nation-state
[22:03.570 --> 22:07.890]  actor, there are a couple of different ways to think about this. If you run an SSA database,
[22:07.890 --> 22:12.390]  so if you're the US, Russia, or China, you need to understand that those bytes on a computer are
[22:12.390 --> 22:18.030]  critical strategic resource that someone might try to mess with from a cybersecurity perspective.
[22:18.030 --> 22:22.070]  They might do this to discredit your information, to cause harm to one of your own satellites,
[22:22.070 --> 22:26.710]  or someone else's satellite. But fundamentally, as a nation, you have an obligation to recognize
[22:26.710 --> 22:32.330]  the importance of these specific databases as some of the most important space data you hold.
[22:32.510 --> 22:38.590]  Additionally, I think it's important to disavow any funny business in SSA. Right now, the US
[22:38.590 --> 22:43.150]  military has a statement on their website that basically says that the data from spacetrack.org
[22:43.150 --> 22:47.910]  could be manipulated at any time for national security purposes. And I understand the logic
[22:47.910 --> 22:53.090]  behind this, but I think standing by SSA data is an important step towards protecting the space
[22:53.090 --> 22:59.170]  environment in the future. And publicly disavowing and ascribing a diplomatic cost to getting caught
[22:59.170 --> 23:05.370]  concealing or manipulating SSA data, I think is an important step towards credibly building a system
[23:05.370 --> 23:11.530]  where people can trust what space looks like. Finally, if you're a smaller country, you might
[23:11.530 --> 23:15.630]  not have a full space surveillance network, but you may have a couple of telescopes or a couple
[23:15.630 --> 23:21.230]  of radar sensors that you can use to kind of randomly sample and audit specific objects and
[23:21.230 --> 23:25.770]  say there's supposed to be a debris object there today. Is there anything? And use that to kind of
[23:25.770 --> 23:30.430]  catch at least some tampering attacks in these databases and get a sense of their reliability.
[23:30.430 --> 23:36.830]  So to sum things up, SSA is fundamentally about trust. There is someone out there who is the only
[23:36.830 --> 23:41.510]  person who knows the truth about these objects and is telling it to you, and you have no way
[23:41.510 --> 23:46.690]  fundamentally to get that physical reality and ground truth information for yourself.
[23:46.830 --> 23:52.130]  This trust is intuitively abusable. You can change information in an SSA database
[23:52.130 --> 23:57.510]  through some very basic orbital physics operations to make it tell a prophecy that isn't true, to
[23:57.510 --> 24:02.650]  create a phantom collision, or to conceal an impending collision with catastrophic effects.
[24:02.950 --> 24:08.990]  We think that we can fix this by recognizing that SSA is an information target that can be used to
[24:08.990 --> 24:14.670]  cause physical effects in space, and so as a result, building responsibility and verification
[24:14.670 --> 24:20.250]  into the SSA process is a key step towards recognizing that trust is as important as truth
[24:20.250 --> 24:26.570]  in these databases. Thank you so much for listening to my presentation, and I'm happy to answer any
[24:26.570 --> 24:30.210]  questions. Hopefully I've gotten you thinking about kind of interactions between the physics
[24:30.210 --> 24:32.790]  of space and the cybersecurity properties.