[00:04.920 --> 00:09.380] Hi, my name is Brandon Bailey. I work within the Cybersecurity Subdivision at the Airspace [00:09.380 --> 00:15.300] Corporation and we're excited to be here today in conjunction with the Space ISAC and the [00:15.300 --> 00:19.680] Airspace Village to be discussing the topic on some spacecraft research that we've been [00:19.680 --> 00:26.540] working on specifically related to exploitation of some of the implementations upon the spacecraft. [00:26.540 --> 00:31.880] So we'll jump right into it. I would like to refer people to the paper linked in the front [00:31.880 --> 00:37.800] for more information about how you can apply certain cybersecurity controls for a spacecraft. [00:37.800 --> 00:44.740] So from an introduction perspective, when you look at vulnerabilities in information systems, [00:44.740 --> 00:51.220] particular satellites, they're often overlooked in the wider discussions when you talk about [00:51.220 --> 00:57.380] critical infrastructure, but that's changing quite rapidly currently where there's a lot more [00:57.380 --> 01:02.800] people discussing spacecraft vulnerabilities, ground system vulnerabilities, and how it relates [01:02.800 --> 01:06.900] to our critical infrastructure as a country. So there's been a lot of misunderstanding and [01:06.900 --> 01:13.260] somewhat complacency in this regard because there's been a lack of real-life events that's [01:13.260 --> 01:21.160] known in the public space of attacks against space vehicles. But the space systems are similar to [01:21.160 --> 01:27.560] other systems. One that you would kind of know about is the industrial control systems or [01:27.560 --> 01:33.160] operational technology field. So you see some good parallels that can be drawn between the spacecraft [01:33.160 --> 01:40.680] and the space systems arena with that. So malicious insiders, external threats, [01:40.680 --> 01:46.920] splotching threats, those are all various threat factors that people can get in to affect [01:46.920 --> 01:53.800] spacecraft from the sensors to the data being uplinked or downlinked. So there's a lot of [01:53.800 --> 01:59.660] different areas where you could have impact that could disrupt military, government, [01:59.660 --> 02:07.180] or even commercial activity for our day-to-day activities. So the threats are changing quite [02:07.180 --> 02:14.140] rapidly in this arena. So there's a lot more knowledge about space and things of that nature. [02:14.780 --> 02:20.820] And then when they would have happened, there'd be an absence of warning. So you know there's [02:20.820 --> 02:25.560] not real-time consistent communication between ground and space a lot of times. So [02:25.560 --> 02:31.660] there could be times where you're not aware that there's attacks ongoing. And attribution is [02:31.660 --> 02:36.860] difficult in the IT world and it's even more difficult in the space world. And there definitely [02:36.860 --> 02:40.360] needs to be more research in this area. And that's one of the reasons why we're [02:41.240 --> 02:45.400] presenting this material. And I'm assuming one of the reasons why the Aerospace Village [02:45.960 --> 02:50.080] exists is because there's a lot more collaboration and research that needs to happen [02:50.080 --> 02:56.720] in this arena. And the CubeSat arena is just exploding as we all know. And the barrier to [02:56.720 --> 03:03.500] entry into space is being reduced quite extensively. So the good thing is in recent years there's been [03:03.500 --> 03:10.080] some open source technology that's been put out there that can help people learn more about space, [03:10.080 --> 03:16.620] space protocols, things like that. So Cosmos, which is linked here, NASA's CoreFlight executive [03:16.620 --> 03:23.840] or CoreFlight software, OpenSatKit was put out by NASA to help people get started with CubeSats. [03:24.560 --> 03:30.360] NOS3 was put out by NASA's Independent Verification and Validation Program to help people build [03:30.360 --> 03:35.060] simulators for space. So there's a lot of good open source material out there now. So people [03:35.060 --> 03:40.060] can actually start researching this for themselves, which is great. But I will caveat that with [03:40.060 --> 03:45.680] one thing is please change your default configs if you're pulling the CoreFlight executive or [03:45.680 --> 03:50.640] CoreFlight software from GitHub and running it accordingly. You want to make sure that [03:50.640 --> 03:57.400] you can change those default configs. So let's move on to some basics. So for people who aren't [03:57.400 --> 04:02.660] necessarily living and breathing space communications and commanding and telemetry [04:02.660 --> 04:07.240] and that terminology, here's just an introduction slide to kind of explain what we're talking about. [04:07.240 --> 04:13.940] Command and Data Handling or referred to as CDH is essentially how data is relayed to and from [04:13.940 --> 04:18.340] the spacecraft. So that's where the encoding and decoding happens for the commands and the [04:18.340 --> 04:24.580] telemetry. There's kind of generically four pieces of a space system. You have the user [04:24.580 --> 04:31.020] terminal where you do the commanding and the telemetry and process telemetry that runs [04:31.020 --> 04:35.640] the ground software. There's some sort of front-end processor that does the conversions of the [04:35.640 --> 04:41.880] information from the ground system to get it connected to a modem or an antenna that you can [04:41.880 --> 04:47.820] send the information to the spacecraft and get it back down. So from a cyber perspective, [04:48.660 --> 04:54.720] the attack surface is quite large because there's a lot of standard IT equipment in there. You know, [04:54.720 --> 04:58.480] like with the ground terminals, the front-end processors, there's a lot of operational [04:58.480 --> 05:02.860] technology, industrial control systems that operate within these facilities that run these [05:02.860 --> 05:09.980] systems or control the antennas. And of course the RF link is the obvious one. So something to [05:09.980 --> 05:15.560] note on this diagram is the bulk encryption component is kind of left out for people that are [05:15.560 --> 05:22.960] more accustomed to satellite communication where you have cryptos on each end. So I left that out [05:22.960 --> 05:30.700] just for ease, for simplicity, but sometimes you do have that bulk encryption there in the middle. [05:31.440 --> 05:35.640] And this is just a quick animation of kind of what this looks like where [05:35.640 --> 05:41.660] the user would say turn this heater on and then the software translates that to some, you know, [05:41.660 --> 05:47.180] hex numbers and then it gets converted by the front-end processor to get framed appropriately [05:47.180 --> 05:52.640] and sent to the modem to get modulated up to the bird and back down. So that's just a simple [05:52.640 --> 05:59.440] animation to kind of articulate what we're talking about here. And slide five here is something, a [05:59.440 --> 06:04.800] paper that was put out by NASIC, the National Air and Space Intelligence Center, which is a pretty [06:04.800 --> 06:10.880] good resource if you want to understand the high-level architecture of space systems and [06:11.440 --> 06:17.160] where cyber threats could have an impact and the types of cyber threats there are. So [06:17.730 --> 06:24.150] in this diagram it's basically just outlining that you have the user segment where you have the [06:24.750 --> 06:29.490] the ground software terminals and then the interacts with the ground segment where you [06:29.490 --> 06:35.010] have the antennas at times or in the link segment with the RF and the space segment for space. So [06:35.730 --> 06:39.730] vulnerabilities exist in all these segments and there's cyber threats within all these segments. [06:40.090 --> 06:44.050] Obviously, you know, the user segment is the highest likelihood for a cyber attack given [06:44.630 --> 06:48.990] that it may have some level of internet connection where it's operated by people and [06:48.990 --> 06:55.150] we understand as being a security researchers or pin testers or red teamers that the people [06:55.150 --> 07:01.890] are generally the weakest link in the cyber paradigm. So the user segment is one of the easier [07:01.890 --> 07:06.950] areas to get in. But we're going to focus more on the space segment and the link segment [07:06.950 --> 07:12.590] specifically because that's where there's less research and less publicized information. So we're [07:12.590 --> 07:19.450] going to focus on three types of attacks today with some demonstration screenshots and to discuss [07:19.450 --> 07:24.590] how they work, what they are, and how you can mitigate these things. So we're going to talk [07:24.590 --> 07:32.990] about a replay attack, which is where you record the command signal and replay it to the vehicle [07:32.990 --> 07:39.130] and see if it processes it. So we'll do that and we'll talk about command link intrusion where you [07:39.130 --> 07:44.630] basically simulate modulating your own signal to a satellite and seeing if it processes [07:44.630 --> 07:49.530] those commands. And then we'll do a denial of service where you could do some GPS jamming [07:50.230 --> 07:54.270] to maybe cause the denial of service condition on a satellite depending on the implementation [07:54.270 --> 08:01.970] for the satellite. So we'll jump in to the command replay first and discuss that attack [08:01.970 --> 08:07.430] vector. So in the real world, which is not what we're operating with this demonstration, we're [08:07.430 --> 08:13.650] operating within simulation, but in the real world you have your ground terminals antenna that [08:13.650 --> 08:18.790] sends a RF signal to a satellite. So in the real world, if you were to do a command replay attack, [08:18.790 --> 08:24.530] you would need some sort of sniffing device to sniff the RF signal from the ground antenna [08:24.530 --> 08:29.990] while it's transmitting the uplink to the satellite. Well, in our simulated world, [08:29.990 --> 08:35.710] because we're using some high fidelity simulation capabilities that have been built that we can use [08:35.710 --> 08:40.350] simply UDP gets translated from the antenna to the satellite. So we're not, [08:40.350 --> 08:45.730] you know, sending RF signals from a ground station to a simulated satellite. Although you could do [08:45.730 --> 08:51.650] that, but for our purposes, we're going to use a simulator that just essentially takes the [08:51.650 --> 08:58.230] TCP IP traffic from the front end processor and then it translates it to UDP and then sends it [08:58.230 --> 09:04.050] to a spacecraft simulator that's running. So if we're doing that with UDP, then we can obviously [09:04.050 --> 09:09.370] use something as simple as TCP for our research. So that's, that's, that's kind of how we're set [09:09.370 --> 09:16.250] up. So this is the simulator that we're using, and it's, it's got some real components to it. [09:16.930 --> 09:22.590] That's, you know, runs in operations today for various missions that are flying. So [09:22.590 --> 09:27.530] there's a ground software component, there's a front end processor, there's the ground station [09:27.530 --> 09:33.710] sim that is used to translate the information to UDP, and then that sends it to the spacecraft [09:34.410 --> 09:41.510] that has a dynamic simulator with it. So we're using real ground software in this simulation. [09:41.510 --> 09:45.190] We're using real front end processor software. None of these have been modified. They're using [09:45.190 --> 09:50.290] the same software baselines as operational missions are using. It uses the same communication [09:50.290 --> 09:58.070] protocols, CCSDS, TC and AOS. So you can google those if you want to learn more about it. We'll [09:58.070 --> 10:02.850] get a little bit more into that detail later. But we aren't using any type of encryption, [10:02.850 --> 10:06.530] so there's no point-to-point encryption or bulk encryption anywhere in this. [10:06.810 --> 10:11.110] And we'll explain why, because that's the point of the demonstration is to show when you don't [10:11.110 --> 10:17.610] have encryption what can happen. We have some real flight software that runs on several operational [10:17.610 --> 10:23.910] missions currently, but it's cross-compiled for Linux. So it's not running on an embedded [10:23.910 --> 10:31.050] processor, a power PC, or an arm, or some FPGA. It's running just in Linux for our purposes, [10:31.050 --> 10:38.070] because we're just focused on the software testing at this point and not being too high fidelity. [10:38.070 --> 10:42.350] But there are technologies that exist where you can get super high fidelity, and we've used those [10:42.350 --> 10:51.130] in the past for several things. Things like Simix, or QEMU, or TCM. These are different [10:51.130 --> 10:57.710] technologies that you can use to have higher fidelity simulations to run software compiled [10:57.710 --> 11:02.630] for target. So those can be integrated in these simulators as well. So the ground station sim is [11:02.630 --> 11:07.690] kind of what mimics the RF transmission for us, but for us it just translates to UDP as I said [11:07.690 --> 11:14.430] earlier. So there's a simulation that's out there called 42 that's put out by NASA that helps do the [11:14.430 --> 11:19.870] attitudes, orbit dynamics, and environmental models. So that helps us understand the orbit [11:19.870 --> 11:26.830] and how we're progressing there. So here we go. And you can build your own one of these [11:26.830 --> 11:32.310] with some sources from GitHub. So these are linked here, OpenSATKit and NOS3 have some great [11:33.170 --> 11:36.370] components that you can construct something similar for yourself. [11:37.010 --> 11:42.510] Okay, so for our specific demonstration for command replay, our satellite in this scenario [11:42.510 --> 11:48.370] orbits the earth and is scheduled to uplink, downlink when it's over top of three different [11:48.370 --> 11:54.650] ground sites. One in California, one in Spain, one in Australia. So one would be Australia's in [11:54.650 --> 12:01.950] Canberra, Spain, Madrid, California, out near LA. So the point of our demonstration is we're going to [12:01.950 --> 12:07.090] capture the UDP traffic with TCP dump as it's leaving the ground station during the uplink pass. [12:07.090 --> 12:13.590] So this mimics an RF sniffing capture. And then we're going to replay that with TCP replay. So [12:14.470 --> 12:21.450] we did a quick, you know, Google search on the internet looking for what type of hardware and [12:21.450 --> 12:27.250] technologies needed to reproduce this type of an attack in real life. And basically it's [12:27.250 --> 12:33.550] around $7,000 and you could get some equipment that could record, capture, and transmit signal [12:33.550 --> 12:39.190] to a lower orbit. So it's definitely achievable for, you know, people who have a little bit of [12:39.190 --> 12:43.090] money. But then with the advent of some of these new technologies that are coming out today, like [12:43.090 --> 12:48.150] AWS Ground Station, the barrier could be much lower. So you may not need so much equipment, [12:48.150 --> 12:54.550] you may need sniffing capabilities, but we're a little unsure on what practices are going to be [12:54.550 --> 12:59.490] in place for AWS in the future. So to prevent, you know, these type of things from happening. But [13:00.270 --> 13:06.670] with that being said, it's just trying to articulate that the barrier for doing, you know, [13:06.670 --> 13:14.450] communications to a vehicle is getting less and less. Okay, so setting up the attack. So [13:14.450 --> 13:21.510] in our simulation, the satellite is visible to the ground station over the Madrid ground station. So [13:21.510 --> 13:28.470] it's there. And then in the bottom middle here, you see a signal lock in that window, it says, [13:28.470 --> 13:32.810] okay, it's locked, it's acquired. So it's sending the connect message, and then it's uplinking the [13:32.810 --> 13:37.690] command. So you see several commands being transmitted. You know, that's a bunch of [13:37.690 --> 13:42.690] numbers there. But what that does is you look in the far right, you see the flight software [13:43.390 --> 13:47.990] that's running. That's the, you know, that's kind of like the UART window of a flight software, [13:47.990 --> 13:53.050] where you have the flight software responding. You see it processes these NOOP commands. So [13:53.050 --> 13:59.070] in this example, we just hit some simple NOOP commands, which is kind of like a ping, you know, [13:59.070 --> 14:05.650] in our terminology. So just to see if the application running on board is alive. So [14:05.650 --> 14:09.910] upon receiving that command, the flight software indeed does process that command and downloads [14:09.910 --> 14:14.490] the event messages, and the command counters increment. So you see here in the ground, [14:14.490 --> 14:19.830] you see that the event messages are processed. It says, hey, there was a NOOP command, and it's [14:19.830 --> 14:24.130] downlinked to the ground. And then you see the command counters increment accordingly. So you [14:24.130 --> 14:30.630] see that the CMDPC, which is short for command processed, for each of those applications that [14:30.630 --> 14:37.510] were sent commands processed to increment to one was zero. So it goes to one. Now the satellite [14:37.510 --> 14:43.550] in our scenario is in transit between Madrid and Canberra. And you see in the ground station [14:43.550 --> 14:49.050] simulation that it's lost signal. So it's no longer in view. So now here's where we could actually [14:49.050 --> 14:54.710] do our replay attack. So in a real world scenario, you would need equipment, obviously, in the Madrid [14:54.710 --> 15:01.130] area to capture the RF traffic. And then somewhere over India, in this example, you would need [15:01.130 --> 15:06.650] transmit capability to be able to send transmit the information to the satellite. So in our [15:06.650 --> 15:12.390] scenario, it's a lot easier, obviously, because we're using just the TCP replay. And here's just [15:12.510 --> 15:18.310] a simple command. It replays the PCAP file that was captured. And then you see the flight software [15:18.310 --> 15:25.610] respond accordingly with the same event messages within the UART. But what you don't [15:25.610 --> 15:31.730] see is any event messages on the ground station because you were in between passes at that point. [15:31.730 --> 15:38.130] And the command counters, you notice when you establish the downlink again over Canberra that [15:38.130 --> 15:42.990] the command counters went up. So the flight software is reporting, hey, I received another [15:42.990 --> 15:49.910] command and, you know, in between ground passes, which would be odd. So from a, you know, defensive [15:49.910 --> 15:55.790] cyber operations perspective on the ground or, you know, C&D perspective, if you're not [15:55.790 --> 16:02.430] monitoring certain key telemetry points on your vehicle, you may not be aware that, you know, [16:02.430 --> 16:09.550] someone has tried to make a connection or send commands. So it's very important to understand [16:10.110 --> 16:16.190] what the telemetry values are that you could be monitoring that could provide you insight [16:16.190 --> 16:20.910] into potential attack vectors. So there's a lot of telemetry points out there that could help with [16:20.910 --> 16:28.410] that. So that wraps up the command replay. So essentially what we did was capture the command [16:28.410 --> 16:35.710] link up and then we replayed it and we saw that it processes. So we'll move on to command [16:35.710 --> 16:40.950] link intrusion, which is a little bit different. It's a slight different take on a command [16:42.250 --> 16:48.010] command link attack. So since there's no encryption in our environment, our simulated [16:48.010 --> 16:53.850] environment here, and there's no authentication, theoretically, the thought was, well, [16:53.850 --> 16:59.250] if you just inspect the traffic and understand the packet structure and understand [16:59.770 --> 17:03.590] what information is in there, theoretically, you could craft your own packet that matches that [17:03.590 --> 17:07.390] structure and just send it up and see if it processes the command. So you're not really [17:07.390 --> 17:13.490] replaying anything. You're just constructing your own raw command packet and then uplinking it and [17:13.490 --> 17:20.250] seeing what happens. So let's try that out and see how it works. So once you've inspected the [17:20.250 --> 17:24.670] traffic and understand there's no encryption, you see in one of the telemetry values, and you [17:24.670 --> 17:31.030] can obviously do this with RF as well. You can record the RF on the downlink and record it as [17:31.030 --> 17:36.130] well. But you see, once you have the information and you see here in the middle, you see CFE, [17:36.130 --> 17:46.770] TBL, NOOP, CFE version 6.6.0.0. So you see that information there and that implies that they're [17:46.770 --> 17:52.910] using CoreFlight executive or CoreFlight software. And so then you can say, well, that's available on [17:52.910 --> 17:59.210] GitHub, I believe. So this is where that comment about default configs really comes into play. [17:59.210 --> 18:06.730] So you go look on GitHub and you understand that CFE CFS uses the CCSDS protocol. So then you get [18:06.730 --> 18:13.790] into this research study on command packet structures, which is a fun study. [18:13.790 --> 18:19.090] I would not recommend it for people if they're not really interested in it because [18:19.090 --> 18:25.370] it's a little bit of a read. So we're looking, we start to break down how [18:25.370 --> 18:30.750] these systems work from a protocol perspective. So we have space packets and then we're [18:30.750 --> 18:37.550] gonna get into some really space buzzword bingo here. So I apologize for that. But for the people [18:37.550 --> 18:43.770] who know what this is, you'll get it. But for the people who don't know, forgive me [18:43.770 --> 18:48.390] for kind of speaking in this lingo, but the space packets get wrapped in these transfer frames [18:48.390 --> 18:51.750] and then the transfer frames are wrapped in what's called these command link [18:51.750 --> 18:57.730] transmission units, CLTUs. So that's kind of how this structure works is CLTU, transfer frame [18:57.730 --> 19:04.630] headers, space packet, and then the trailers. So then we start looking in the CCSDS protocol [19:05.470 --> 19:11.130] and we understand, okay, this is the space packet. These are the octets that are there. [19:11.130 --> 19:16.750] And then we start really diving into some of these documents and we say, okay, well, this is [19:16.750 --> 19:21.170] what the primary header is. This is what a transfer frame looks like. This is what the transfer frame [19:21.170 --> 19:25.590] primary header looks like. This is what the CLTU looks like. And then so we're kind of in this [19:25.590 --> 19:32.810] overload of terminology, protocol breakdown, things like that. So it gets a little cumbersome [19:32.810 --> 19:38.610] and confusing, but it's important to understand all these things. And it's also important to [19:38.610 --> 19:43.610] realize that these protocols are open source protocols. So a lot of the, a lot of missions, [19:43.610 --> 19:49.590] spacecraft that are out there today, leverage CCSDS because that is an international standard [19:49.590 --> 19:56.470] that the CCSDS group is a consortium of many space agencies from across the world who get [19:56.470 --> 20:03.710] together and standardize on protocols and things like that. So it's easy. You just kind of, you [20:03.710 --> 20:07.470] can just Google the standards and find them and they'll have these diagrams in there and you can [20:07.470 --> 20:13.650] break down, you know, the bit patterns and things. So from our transmission, since there's no encryption [20:13.650 --> 20:20.750] on that, you just basically have the raw number structure. And to the, to the kind of uninformed, [20:20.750 --> 20:25.970] this looks just like a bunch of gibberish, but what we're going to do is take the knowledge we [20:25.970 --> 20:34.010] gained from reading the hundreds and hundreds of pages of those CCSDS protocols and see what [20:34.010 --> 20:41.130] we can find out. So let's look here. We see the, the fives in our scenario is the acquisition [20:41.130 --> 20:48.210] sequence. And then we've determined where the CLTU is. So we've now, we've got the CLTU. So let's [20:48.210 --> 20:52.770] break that down and see what we can get. So then we take off the headers and trailers in this [20:52.770 --> 21:00.430] example. And then now we have this subset, and then we have this code blocks and these check [21:00.430 --> 21:06.050] bytes, and we take those out. So now we've identified the actual TC transfer frame, which is, [21:06.050 --> 21:12.350] which is where the, the command information is stored on, on the uplink. So now we've got that. [21:12.350 --> 21:17.890] So let's take out the header on that. And now we have the command packet. So this is the one [21:17.890 --> 21:22.770] that we were looking for. So with all those numbers, this is really what we were looking [21:22.770 --> 21:26.690] for. We're looking for this command packet, because it's going to tell us hopefully what [21:26.690 --> 21:32.550] kind of command was sent up on that uplink. So from that, from the telemetry stream, we've kind [21:32.550 --> 21:39.770] of discussed, we see this no op command that came down. So we've, we look on the GitHub repo, and [21:39.770 --> 21:47.230] we've realized that in our example, that the spacecraft that's we're looking at seems to be [21:47.230 --> 21:53.530] using these default command and telemetry IDs. So because if you look at the, the header file for [21:53.530 --> 22:02.010] the message IDs, for the CFE table, command message ID, you see 1804. So that would indicate [22:02.010 --> 22:09.210] like the high likelihood of actually the software's using these default message ID types. [22:09.210 --> 22:13.790] So what that does is allow you to basically transmit information to the, you're going to [22:13.790 --> 22:18.470] try to transmit information using this knowledge you've gained to the simulated spacecraft to see [22:18.470 --> 22:24.470] kind of what will happen. So let's see if we can, we can reconstruct a packet with this knowledge [22:24.470 --> 22:28.990] and see what we can do with it. So with this knowledge, let's play around a little bit and [22:28.990 --> 22:33.590] see what we can do. So we've got our knowledge of the command structure from GitHub, and since we [22:33.590 --> 22:37.650] can't construct a new command, maybe something else to see what happens, just to see if the [22:37.650 --> 22:42.570] command, the spacecraft will actually process it. So you have to do a little digging and understand [22:42.570 --> 22:47.850] the functionality of this software, but luckily all that information is open source. So [22:47.850 --> 22:52.650] once you dig in a little bit, you see, you notice there's this functionality within [22:52.650 --> 23:00.730] the CoreFlight software called ES. It's an ES application where you can potentially, you know, [23:00.730 --> 23:04.730] have control over the applications on board. So we're going to see if we can reconstruct a packet [23:05.290 --> 23:10.790] to do a reboot of a particular application. So in the real world, you know, you would have to [23:10.790 --> 23:16.550] reverse engineer the packet structure of the RF signal. But in our scenario, we're going to [23:16.550 --> 23:21.490] transmit the UDP packet with the following information and see if we can get a reset of [23:21.490 --> 23:29.090] one of the applications. So we use that 1806 because that's the default message ID for the [23:29.090 --> 23:35.570] ES application. So that tells the flight software, hey, this command is meant for the ES application [23:35.570 --> 23:41.570] to process once it gets on the satellite. And then the rest of the numbers is just, [23:41.570 --> 23:47.550] you know, understanding the... translating the command and telemetry database into this format, [23:47.550 --> 23:51.010] which I won't bore you with all the details that had to happen for that to occur, but [23:52.270 --> 23:57.050] you can get there, essentially. It just takes a while to figure out what the structure is and [23:57.050 --> 24:01.910] what numbers need to go where and what those values need to be. So let's send this raw packet [24:01.910 --> 24:09.350] up and see what we can do. So we send that raw packet up to the satellite and look at that. So [24:09.350 --> 24:16.270] we see in the UR of the actual flight software that we have some sort of response. So you see [24:17.010 --> 24:23.570] at the top of the window, you see CFE ES restart app initiated for HK. So it looks like it was [24:23.570 --> 24:29.710] successful. So we essentially have reconstructed our own packet based on information that we've [24:29.710 --> 24:37.230] gained from GitHub and then transmitted it to our spacecraft simulator and it indeed did process it. [24:37.230 --> 24:43.090] So that's an example of, you know, a command-link intrusion where you've basically put your own [24:43.090 --> 24:48.150] command structure and sent it up and got it to process. So that's kind of the response. So [24:48.830 --> 24:54.670] the question is like, okay, why does the replay attack work? Why does this command-link intrusion [24:54.670 --> 25:00.210] attack work? So part of it's the open sourceness of the information out there so you can pull [25:00.210 --> 25:06.390] that data from GitHub and do your own research. But it really gets down to the protocols and some [25:06.390 --> 25:12.770] of the protections. So in this example, there's a communications operational procedure that [25:12.770 --> 25:20.610] typically runs on a satellite, at least ones that operate CCSDS called COP1. And that helps [25:20.610 --> 25:26.170] with sequencing to make sure that the sequence of the commands and the packets received are [25:26.170 --> 25:33.070] proper. On our example, COP1 wasn't turned on by design in our example, but [25:33.070 --> 25:39.850] there's a lot of actual spacecraft who don't leverage COP1 for various reasons. So COP1 would [25:39.850 --> 25:45.710] have provided some level of protection, but that can be fudged and gotten around if you know what [25:45.710 --> 25:53.010] you're doing. So in example, I redid the same example for replay with COP1 enabled, and you see [25:53.010 --> 25:57.370] here that the command is not processed because they were out of sequence. So I could have really [25:57.370 --> 26:04.470] fudged the data around with sequencing and probably got the process, but we didn't [26:04.470 --> 26:08.750] really want to get into that. But the point was just to articulate that there are sequencing [26:08.750 --> 26:16.590] protections that you can put in to help with the replay. But the real control that [26:16.590 --> 26:22.110] you want is encryption and authentication. So you really need to encrypt and authenticate [26:22.650 --> 26:28.370] the command link. So it's not enough to just do encryption because you theoretically [26:28.370 --> 26:35.170] could just replay an encrypted link and it would process accordingly. So you need the authentication [26:35.170 --> 26:39.830] on the command link as well. So that's important. So you need both. So to properly protect [26:39.830 --> 26:45.930] from a replay or an intrusion attack, like here are some just guidelines for [26:47.250 --> 26:51.130] pseudo requirements, sample requirements about cryptography and authentication. So you need to [26:51.130 --> 26:58.350] authenticate and you need to do cryptography to ensure that these attacks won't work. Okay, so now [26:58.350 --> 27:06.230] we're going to jump into denial of service via GPS jamming. So the first two were particularly [27:06.230 --> 27:11.910] to the command link. So those were intrusion and replay. This one's a little bit different [27:11.910 --> 27:15.910] and it's going to use a different simulator, but we won't get into the specifics on the sim, but [27:15.910 --> 27:21.910] it's a high fidelity simulator that has a lot of dynamics and a lot of command and data handling [27:21.910 --> 27:28.130] and GNC capabilities. So what we're going to do is get the vehicle in an operational [27:28.130 --> 27:34.910] state where it's doing a mission operations, and then we're going to simulate the [27:34.910 --> 27:39.890] denial of service with GPS signal, which is basically cut off the GPS, and then we're going to see how the [27:39.890 --> 27:46.930] system responds. So jamming, for those who aren't necessarily aware, is the intentional [27:46.930 --> 27:51.210] or sometimes unintentional interference of the signal that prevents it from being received. So [27:51.210 --> 27:58.670] it's relatively simple to do. It's easy to overpower at close range and jammers can be [27:58.670 --> 28:04.030] on the ground, it could be in the ocean, airspace, jammers can be about anywhere. So in our scenario, [28:04.030 --> 28:09.010] the spacecraft simulator is set up to be in what's called mission science mode or operational mode, [28:09.010 --> 28:14.130] and once it reaches this mode, we're going to simulate the GPS signal by stopping the flow [28:15.010 --> 28:22.110] on the space wire bus, which is where the GPS sends its data to the Singapore computer, [28:22.110 --> 28:29.510] the flight software. So here is just a graphical representation of some of the telemetry and [28:29.510 --> 28:36.210] dynamics data for this particular sim as it's operating. And we are, you know, it shows, [28:36.210 --> 28:43.690] you see the attitude control mode previous to attitude control mode current, which is MSM, [28:43.690 --> 28:47.730] which is the mission science, which is the operations mode. So what we're going to do here [28:48.290 --> 28:53.510] is we're going to block that data from getting to the Singapore computer, the flight software [28:53.510 --> 28:57.650] from the GPS sensors, and we're going to see what happens. So in the middle here, you see [28:57.650 --> 29:04.830] the GPS data packet counts increasing. So you see it go from 920 to 944. So everything's optimal [29:04.830 --> 29:12.310] here. We're operating, we're flying in orbit, GPS signal is being processed, and everything is fine. [29:12.310 --> 29:19.050] So here, now we're going to, in our simulation, we're going to basically leverage a capability [29:19.050 --> 29:25.170] that was built into the simulator to block data across the Spacewire bus based on whichever [29:25.750 --> 29:30.030] values we want. So we can block about anything that's flowing across the Spacewire bus, [29:30.030 --> 29:37.670] or 5053 bus for that matter, and see what happens. So once you initiate this block sequence, [29:37.670 --> 29:43.290] you see the ground telemetry values freeze. So you see, which indicates the gray background there. [29:43.290 --> 29:48.550] So at this, the ground station is reporting, hey, I don't, I'm not receiving GPS data anymore. [29:48.550 --> 29:52.730] For some reason, it's not being downlinked. And that's because it's not being actually [29:52.730 --> 29:59.070] provided to the Singapore computer for downlink. So you see that freeze. So, and you know, [29:59.070 --> 30:07.070] for spacecraft, you know, one thing to understand is, you know, you can't, you can't go up there, [30:07.070 --> 30:11.970] you can't like a, obviously a real computer, go, you know, hit the reset button. There's a lot of [30:11.970 --> 30:14.930] autonomy built in, there's a lot of fault management, and a lot of testing goes around [30:15.150 --> 30:22.630] fault management response. So what you should know is like, typically, when you have a [30:22.630 --> 30:29.450] satellite in orbit, and some anomalous thing happens, the last-ditch effort to save it [30:29.450 --> 30:33.410] basically is to go into what's called a sun pointer safe mode. So it basically takes the [30:33.410 --> 30:38.470] solar arrays and points it to the sun and says, I'm just going to hang out here until I hear [30:38.470 --> 30:44.050] from the people who control me in the ground station. So what we're going to do here is [30:44.050 --> 30:49.850] see what the autonomous flight response is once the GPS signal is blocked. So safe mode [30:49.850 --> 30:55.670] is an operational mode, where a lot of non-essential systems are shut down. It's very similar to [30:56.210 --> 31:01.630] Windows, you know, when Windows goes in safe mode, it shuts off a lot of the features of [31:01.630 --> 31:07.350] Windows from that perspective. So preservation of the spacecraft is the highest priority. So [31:07.860 --> 31:14.890] here you see in the downlink telemetry, the flight software is starting to do its [31:14.890 --> 31:21.570] autonomous fault management. It's running what are called RTSs, so relative time sequences. [31:21.570 --> 31:25.110] So these are things, these are just automated flight responses that are there. [31:25.210 --> 31:30.210] And it's starting to do various things, it's doing movements, it's stopping [31:30.210 --> 31:34.990] antennas, it's transitioning to some point mode from an attitude control perspective. So it's [31:34.990 --> 31:40.330] starting to safe itself. And in the telemetry you see from the attitude control mode perspective, [31:40.330 --> 31:47.170] it's reached its desired some point state at this point. So why would you perform a denial [31:47.170 --> 31:54.170] service, you know, like GPS jamming on something? So, you know, maybe you're just wanting to have [31:54.270 --> 31:58.110] a little fun, maybe you're just trying to disrupt and degrade some sort of mission operations for [31:58.350 --> 32:03.350] a specific time. Maybe you're wanting a mission to not achieve any objectives. But what if you're [32:03.490 --> 32:06.990] a little bit smarter than that? And you understand the autonomous fault response [32:07.450 --> 32:11.130] for satellites, and you understand the design and fault management a little bit more. So [32:12.170 --> 32:17.350] a more strategic, you know, attacker understands that there's a lot of autonomous fault response [32:17.350 --> 32:21.850] for a mission to put itself in a really safe state. So if you just think about the safe mode [32:21.850 --> 32:26.610] for Windows, you know, a lot of the security features get disabled while you're in safe mode. [32:27.270 --> 32:32.710] Similar things do happen for spacecraft. So forcing a spacecraft into safe mode [32:32.710 --> 32:39.110] could potentially open up additional vectors that aren't there. So think about a, you know, maybe [32:39.730 --> 32:45.250] if you've jammed the GPS signal, maybe your fault management response is to save yourself, [32:45.250 --> 32:51.770] turn off cryptography, you know, and open up your command link for any signal that you can process. [32:51.770 --> 32:57.710] Just depends on the fault management response. That's a design decision. But just think about [32:57.710 --> 33:03.210] that as you're doing your design that you may not think through, like, hey, maybe adversaries may [33:03.210 --> 33:08.010] know that I can be more vulnerable, get put in a more vulnerable state. So maybe I need to [33:08.010 --> 33:13.690] design in something, you know, the terminology that we put in the paper that was linked in the [33:13.690 --> 33:20.190] front, defending the spacecraft in the cyber domain paper. We talk about the cyber safe mode. [33:20.190 --> 33:26.750] That's a slight transition from the traditional safe mode terminology. But it's basically [33:28.150 --> 33:34.130] it's a safe mode that's cyber hardened to a degree. And you have a high integrity [33:34.910 --> 33:38.890] mode that you're in, that you know you're in a good state and everything's valid, [33:38.890 --> 33:45.830] and you still have authentication encryption going on. So that's a concept. That's a kind [33:45.830 --> 33:52.550] of newer concept that's being discussed in the space sectors. But it should be there. Because [33:52.550 --> 33:57.430] knowing, you know, more and more people that understand space and understand fault management [33:57.430 --> 34:02.150] response may use that against you. So you may want to think about that a little bit more as [34:02.150 --> 34:08.110] you do your design. So here's some recommendations for just generalized protection. This isn't [34:08.110 --> 34:12.730] specifically GPS jamming because there's a whole there's papers upon papers out there that talk [34:12.730 --> 34:18.350] about how to protect against jamming. But this is more in line with protecting against, you know, [34:18.350 --> 34:22.070] leveraging fault management against you. So you need to really protect that documentation [34:22.650 --> 34:26.430] because that's just basically providing an adversary a pathway to get you in a more [34:26.430 --> 34:33.470] vulnerable state if your design is built that way. And other design considerations about always [34:33.470 --> 34:39.570] encrypting information, especially on the downlink. So some people think that the downlink on the [34:39.570 --> 34:44.410] telemetry side should not necessarily be encrypted because it's not, you know, it's not controlling [34:44.410 --> 34:49.430] the vehicle. But there could be a lot of good information that is ascertained from telemetry. [34:49.430 --> 34:53.450] So it could be you could have adversaries monitoring your telemetry stream looking for [34:53.850 --> 35:01.190] various, you know, indicators that you are in a less secure state. And these are other [35:01.190 --> 35:05.030] some design considerations that are that are here. I won't read them all to you. But basically [35:05.030 --> 35:10.390] getting, you know, the cyber safe mode, getting, you know, only report error messages when needed [35:10.950 --> 35:15.250] and encrypting it accordingly and getting make sure you have ability to recover and reconstitute [35:15.250 --> 35:20.430] to a known state. So these are just some considerations to think about as you're [35:20.430 --> 35:27.230] building your design for a spacecraft. So with that being said, those are just an example of [35:27.230 --> 35:33.570] doing some protection. So let's talk about what it takes to let's transition the discussion a [35:33.570 --> 35:39.450] little bit and talk about what it takes to just protect the overall ground system. So at this [35:39.450 --> 35:47.610] point, we've talked about, you know, the command link intrusion. We've talked about command replay, [35:47.610 --> 35:52.530] some denial of service. But let's talk more generically about space systems in general. So [35:53.150 --> 36:01.010] I like to use defense in depth as a presentation material and discuss and a principle for design [36:01.010 --> 36:05.930] as many people do. I mean, I think anyone in the security community really understands the [36:05.930 --> 36:12.230] fits and depth. But with the fits and depth, I like to illustrate basically using an onion. So [36:12.230 --> 36:18.070] in the typical, you know, IT sense, the onion diagram, you have, you know, the hardened server [36:18.070 --> 36:24.010] configuration wrapped with intrusion prevention firewall type stuff. But in the space domain, [36:24.010 --> 36:28.190] it's a little bit different, but it's somewhat similar. But so here's some graphics that I wanted [36:28.190 --> 36:33.790] to provide that give you a representation of the fits and depth for both ground and space. So [36:34.650 --> 36:40.110] this first graphic here is kind of the ground system. So it starts with the data that runs, [36:40.110 --> 36:47.290] you know, on the endpoints, wrapped by software, supported by endpoints, connected by networks, [36:47.290 --> 36:51.430] protected by intrusion detection and perimeter controls and physical controls. So there's, [36:51.430 --> 36:58.170] you know, this isn't all inclusive, not every subcategory, you know, within each block is listed. [36:58.190 --> 37:04.690] Due to space, but it provides a good list of things that you would expect to be at each [37:04.690 --> 37:10.670] layer of the onion. So from a data perspective, you may have, you know, data at rest encryption, [37:10.670 --> 37:16.010] you may have Tempest that you need to worry about. From a ground software perspective, you know, [37:16.010 --> 37:22.370] SDLC, secure coding, common weakness enumeration prevention, things like that, binary analysis, [37:22.370 --> 37:28.810] dynamic analysis, static code analysis, stuff like that. Your endpoints, your heads, your hips, [37:28.810 --> 37:34.010] your AV malware, DLP, file integrity, things like that. So we won't dive into every one of these, [37:34.010 --> 37:38.370] but it's kind of important to understand that you can pick and choose to apply controls at [37:38.370 --> 37:43.090] each layer. And it's important to apply controls to each layer. So you don't want to just put all [37:43.090 --> 37:48.650] your eggs in the perimeter basket and say, I'm going to stand up a good DLP, a good firewall, [37:49.290 --> 37:55.730] and security zones on the perimeter. And then hope that gets me there because you have insiders, [37:55.730 --> 38:00.150] you have other avenues where you need monitoring capability, you need protections. [38:00.310 --> 38:05.370] So that's pretty common. You know, that's nothing groundbreaking from a ground perspective. But [38:05.370 --> 38:10.130] similarly, you can do the kind of the exact same approach for the vehicle itself. So [38:10.730 --> 38:15.290] this is a onion representation for the vehicle. So you have, you know, [38:15.290 --> 38:20.510] similarly the data that's on board the vehicle, wrapped and processed by some sort of software [38:20.510 --> 38:27.130] on board that has a single board computer or, you know, a processor and a bus, [38:27.130 --> 38:31.970] hopefully protected by some sort of onboard intrusion detection prevention. So that's kind [38:31.970 --> 38:37.550] of a new area. What's being researched today is kind of onboard cyber monitoring and intrusion [38:37.550 --> 38:44.070] detection prevention. That's not typical on a lot of missions right now. What you see currently, [38:44.170 --> 38:49.830] a lot of the focus on protecting space vehicles is really geared around the crypto comms area. [38:49.910 --> 38:58.290] So, you know, the authentication encryption and the comms link, the transect, things like [38:58.290 --> 39:03.450] that. But there are controls that you can apply and there are threat vectors that exist for [39:03.450 --> 39:09.290] basically every one of these blocks on the vehicle as well as on the ground. So [39:09.930 --> 39:14.770] since there's threats and vulnerabilities that can be exploited, that can happen on [39:14.770 --> 39:17.790] kind of each block, it's important to put controls in each block, honestly, [39:17.790 --> 39:24.810] so that you can have a better chance of protecting yourself. So in conclusion, [39:24.810 --> 39:28.670] we've talked, you know, kind of three attack vectors, but those are just three [39:28.670 --> 39:35.470] examples and there's many more that can be discussed. But it's kind of convenient, [39:35.970 --> 39:43.070] to ignore security, honestly, because there's not been this, you know, windfall of [39:44.150 --> 39:49.970] events that have happened that are cyber related on a vehicle. But it's not really an option moving [39:49.970 --> 39:56.250] forward. Satellites are too critical to our everyday life or operations of our nation and [39:56.250 --> 40:01.690] the world, honestly. And it's kind of important to understand that the barrier to entry into space [40:01.690 --> 40:07.630] has been dramatically reduced in the last five, 10, 15 years. I mean, with small sats and launch [40:07.630 --> 40:16.390] services, and AWS ground stations, it's getting real easy to get a lot cheaper to get information. [40:17.050 --> 40:24.310] It's a lot cheaper to get assets into space. So, and defensive depth needs to be a big part [40:24.310 --> 40:28.390] of the solution. So we need to design security at the beginning, which is kind of cliche, but [40:28.390 --> 40:34.350] obvious. And it's going to be more and more important as we, you know, start to deploy all [40:34.350 --> 40:39.850] these small sats in a peripheral-related constellation moving forward. So, you know, [40:39.850 --> 40:44.970] from a defense in depth perspective, and, you know, understanding security, it's important. So [40:44.970 --> 40:49.710] I mean, there's a little bit of a interesting parallel you can draw, you know, with space [40:49.710 --> 40:56.670] systems, and in the industrial control system arena. So it's, you know, for years and years, [40:56.670 --> 41:02.730] you see this at, you know, at the IoT village as well. For years and years, people have kind [41:02.730 --> 41:08.590] of ignored security in the industrial control systems, OT, IoT arena. And it's not just been [41:08.590 --> 41:13.970] the last few years, people have really started understanding that threat factor. And, and [41:13.970 --> 41:19.270] mainly it's due to, there's been documented attacks, and a lot of bad things have happened [41:19.270 --> 41:23.950] as a result of that. So let's try to learn from that lesson and not wait till something really bad [41:23.950 --> 41:28.810] happens to make corrections. Because we know there are vulnerabilities, we know there are [41:28.810 --> 41:35.390] corrections, we know there are things we can do. So we should be doing that. And the small set [41:35.390 --> 41:39.870] marketplace, you know, and the embedded security community is evolving. There's a lot of commercial [41:39.870 --> 41:45.590] things that are being put out, there's some open source solutions that are out there. And we need, [41:45.590 --> 41:50.830] you know, accountability, we need people who are researching this to understand the security [41:50.830 --> 41:57.150] ramifications of these things and, and need to be somewhat agile to get these things verified [41:57.150 --> 42:04.150] and validated and accepted and put out in the community. As opposed to some niche areas, [42:04.150 --> 42:11.430] niche markets, people doing things. So it's important for us to get, you know, leverage the [42:11.430 --> 42:19.270] explosion in this market. But it's also, we need the security researchers and, you know, ethical [42:20.230 --> 42:25.930] hackers and things like that to really, you know, hold people accountable for the things we're [42:25.930 --> 42:32.890] putting out. Because, you know, the path of least resistance is often used. So if no one's looking [42:32.890 --> 42:37.010] at your, looking at your work and understanding the security ramifications of your design and [42:37.010 --> 42:41.770] what you're doing, you know, people kind of get lazy with their implementation at times. So it's [42:41.770 --> 42:46.650] important that we all get out there and research this stuff and look, look into it to understand [42:46.650 --> 42:52.130] the ramifications, some of these design choices that are being made. So we need to really, you [42:52.130 --> 42:57.570] know, the government industry, I think we're coming to a very good, you know, agreement that [42:57.570 --> 43:02.430] cybersecurity is super important for, for space programs. And there's a lot of investment that [43:02.430 --> 43:07.930] needs an education, training and talent development and retention. So I, I feel like there's a huge [43:07.930 --> 43:12.530] step forward this year at DEF CON with the hack-a-sat. I mean, that, that is a fantastic [43:12.530 --> 43:18.590] event that, you know, that's ongoing within the Aerospace Village to, to, you know, hack into [43:18.590 --> 43:24.910] to representative satellite systems. And it, you know, there's these open source technologies that [43:24.910 --> 43:28.830] are put out that you can build your own ground-to-space simulation. You can start learning. [43:29.030 --> 43:35.110] You know, five years ago, there was not that much out there to learn. So the, the activation energy [43:35.110 --> 43:42.290] and the level of access to information was, wasn't there for the security community to get [43:42.290 --> 43:48.850] into it. So I think it behooves us, you know, within the government, within the industry to start [43:48.850 --> 43:52.910] getting this information out there and making this stuff available for the researchers so they can, [43:52.910 --> 43:58.650] you know, we can find some of these vulnerabilities and get them fixed. And technology has evolved [43:58.650 --> 44:05.410] from a simulation perspective so much in the last 10 years with the advent of, you know, digital twin [44:05.410 --> 44:11.030] type technology for space. The embedded arena is getting there, you know, with open source, [44:11.030 --> 44:17.730] things like QEMU, with commercial things like Simics or TCM, you can get really high fidelity [44:17.730 --> 44:24.890] simulators running software. And that's, you know, built for target and running a lot of tests. You [44:24.890 --> 44:30.390] don't have to buy these million dollar space platforms. And there, and also these, you know, [44:30.390 --> 44:34.650] these CubeSats that you can buy, and these embedded processors, you can buy some of these [44:35.310 --> 44:38.330] things kind of commercially off the shelf, start doing your own research if you have some of the [44:38.330 --> 44:44.890] budget. But the last point is, you know, the reason I wanted to do this presentation [44:44.890 --> 44:51.450] and be a part of the Aerospace Village and work with the Space Ice Act is information sharing [44:51.450 --> 44:57.190] is a must. I mean, coming from the government arena, you really get into this compartmentalization [44:57.190 --> 45:03.330] of information and the need to know and things like that. So, but we really need to have [45:03.330 --> 45:07.910] information sharing, we need to do research, we need to have events like this, the Aerospace [45:07.910 --> 45:13.990] Village, we need to come together as a community and start doing this research together. And we're [45:13.990 --> 45:18.570] not trying to point fingers at people and, you know, say that, oh, your implementation is bad. [45:18.570 --> 45:24.730] It's just we need to learn together and make things better and share what we learn and do [45:24.730 --> 45:30.830] presentations like this. So, with that being said, that's about all I have to present. But I do have [45:30.830 --> 45:39.170] here on slide 29 a link to some resources, the Space Ice Act, there for information on it, [45:39.170 --> 45:45.990] the HackASAT link. Something that's going to be really cool is they, the HackASAT was, [45:45.990 --> 45:49.830] you know, they had qualification rounds and they have the finals at DEF CON this year. [45:49.830 --> 45:56.070] And they're going to open source a lot of those CTFs qualifications and things. So keep an eye [45:56.070 --> 46:01.990] on the HackASAT URL to, you know, maybe pull down some of those CTFs once they get published [46:01.990 --> 46:08.710] and give them a try yourself and learn. This is a really exciting exercises that were put together. [46:08.710 --> 46:14.010] If you want to build some of your own simulators, these links are there with for OpenSATKit, [46:14.510 --> 46:21.510] Noscubed, 42, things like that, Open Source Flight Software, CPCFS. And there's some info here on, [46:21.930 --> 46:25.470] you know, jamming if you want to learn a bit more about that. And the paper that [46:25.470 --> 46:33.390] was published in November 2019 is also linked here for your reference. So with that being said, [46:33.390 --> 46:39.130] that is all I have to present. And thank you so much. And I'll take questions [46:39.130 --> 46:41.890] in the offline session. Appreciate it.