Hello, I'm Pam Melroy and I'm delighted to be here today for Aerospace Village to talk about
cybersecurity lessons learned from human spaceflight. So I'll start out by introducing
myself. I am a retired Air Force test pilot and a NASA astronaut. I flew three times in space
on the space shuttle to the International Space Station. My first two missions I was the pilot
in the right seat. And on my final mission, I was the mission commander of the space shuttle.
Now, all of my missions were to the International Space Station. And this is a picture of what it
looks like now in space orbiting above us at about 400 kilometers. It's an international
laboratory. Now, there's lots of very interesting science that you can do in microgravity
as you're whizzing around in low Earth orbit, experiencing a balancing of all the forces. So
it feels like there's no gravity. You don't feel the effects of gravity, even though they're there.
We discovered we could do a lot of really interesting science on the space shuttle,
like fluid mechanics, combustion, and even studying the human body and biology. But
flying on the shuttle, we only flew about six or seven times a year for about 10 days to two
weeks at a time. And so the United States joined with our partners, Russia, Japan, Canada,
and Europe to build the International Space Station so that we could do science 24-7,
365 days a year. And now, of course, if you look at the space station, you realize it's far too big
to put on the top of a rocket and launch it. We had to bring it up a piece at a time
and build it as we went along. If you look in the upper left-hand corner, you can see Atlantis
from my second flight with part of the truss segment that the solar arrays sit on, filling
up the entire payload bay. So we carried up an element at a time and then using the robotic arm
of the space shuttle and the space station, maneuvered it into position and then bolted
it down. And then we sent spacewalkers outside to make the power, cooling, and data connections.
And then inside the space station, we would activate the element. Now, most of the time,
we actually had to upgrade the software each time that we did that on the ISS because we had new
mass properties, new capabilities. And so it wasn't just activating a new element, it was actually
constantly evolving the International Space Station command and data handling system.
Now, after I left NASA, I went on to a variety of opportunities in industry and government,
including spending a couple of years with the FAA's Office of Commercial Space Transportation,
learning all about space policy and the new emerging commercial space industry.
And I spent four years at DARPA as a deputy of the Tactical Technology Office overseeing the air
and space research portfolio. Space is incredibly important in our daily lives.
The GPS navigation that we have on our phone is just the beginning. Think of all the apps
that use GPS, agriculture, most importantly, financial transactions. When you use an ATM,
the timing signal is set by GPS. We also use space for national security communications
throughout the world. Think about remote sensing of our Earth to study the weather,
be able to predict it, and have other indicators of the health of the Earth.
We've had a very complacent attitude about our satellites because physical access was basically
impossible once the satellite was launched. But now we know that our key infrastructure is at
threat on the ground, and it is in space as well from both physical and cyber threats.
Space systems have always focused on safety and mission assurance because you can't access them,
you can't repair them, and it's expensive to launch things. So we've spent a lot of time
focusing on redundancy and testing and mission assurance. Now we have the commercial world coming
into play, doing things faster and cheaper. And we have the potential for lunar exploration.
And we also have nation-states competing for achievements and resources in space.
So the threat is evolving. We need to understand the implications and prepare for the challenges
ahead. I'm going to talk a little bit about the lessons learned from the software approach to
human spaceflight for both a space shuttle and a space station. But first I'd like to actually
address, so what is the real threat? What could a hacker actually do to a satellite?
Well, the simplest hack, of course, is a denial of service. Pretty straightforward. And it's
actually happening today. Jamming of signal. Sometimes it's inadvertent, just having a
transmitter tuned too loudly so it's drowning other transmitters out. And sometimes it's
completely intentional. You could intercept commands and data. So you could understand what
things the satellite is pointing at, what it's taking pictures of, see that data stream for
yourself, and also intercept communications. There's also the potential for the man-in-the-middle
type of attacks. That's quite a bit harder, actually, with most space systems now, because
you would have to really understand the data stream in order to alter it.
Now, could you do something crazy like send it over to hit another satellite? So if you think
about a self-driving car and hacking that, you could drive it off the road. Well, not really.
Most satellites don't actually carry enough propellant to maneuver over to another satellite.
But what you could do is run the satellite out of fuel. You could shut down a critical system
like cooling or pointing the solar arrays at the sun. Now, there are roughly 5,000 active
satellites in space, but only the International Space Station has humans on board permanently.
So even back in the 70s, when the shuttle was being designed, there was a recognition
that it was going to be different. Lives were going to be at stake. So a much higher level
of attention needed to be paid to software errors that could have catastrophic consequences.
So I'd like to talk about some of the lessons that we can learn from the shuttle and from ISS.
Now, it's kind of easy to make fun of the space shuttle. Yes, this is a picture from my first
flight. And you can see that we interfaced with the shuttle computers using a cathode ray tube
screen. And that's a blow-up of what it looks like. It's black with green letters on it.
Absolutely no graphics processing units or, you know, any kind of artistry at all. It's anything
that you could make with numbers and lines. And that was pretty much it. We also were very limited
in the way that we could communicate. We didn't have a full keyboard the way most computers do.
We had a small hexadecimal keyboard. Now, this actually wasn't that bad. One of the
very clever things that was done with shuttle software was the extensive use of
bundled commands, what I would, in my simplistic mind, think of as a macro.
So there were many, many things that needed to have multiple tasks done, say to configure the
entire vehicle for a different phase of flight or to prepare for another activity. So rather than
throwing switches, which were limited space, or pressing in a number or an action for every
single one, you had the capability to hit item and a number and then execute on a given page,
and it would set off a whole string of bundled commands. So it actually wasn't as bad to
interface with as you might think. Now, here's one of the areas that I really didn't like.
The fault summary. So if something went wrong, this is the page that you went to. And it had
a maximum of 15 faults displayed, which most of the time was pretty okay. But worse, it doesn't
have any scrolling capability. So on my first flight, we had a malfunction. We had an electrical
bus short on a payload bus that provided about one-third of the power to the payload and the
systems aboard the space shuttle. Now, you can imagine when that happened, every bell and whistle
went off inside the space shuttle. And when I went back to look at this fault sum, I didn't have
very many choices. I had to either write everything down, because when I hit reset, it was gone and I
could never see it again. And the messages would stack up and get lost behind each other. So
definitely, you can see some real weaknesses in the interface area. I think that was a real
challenge, I think, but probably very reflective of the capabilities of the 70s.
The Shuttle General Purpose Computer, or GPC, was a marvel. Really, incredibly rugged. So carrying
a whole whopping megabyte of RAM, but very, very rugged. It had to be rugged. It had to withstand
the intense vibration and g's of launch. It also had to be very radiation tolerant, compared to
the laptops that we carried that I'll talk about in a little bit, which had constant cosmic ray
hits and corruption of data, requiring you to reboot them typically once a day. That was not
the case with the GPC. It was very, very rugged, and it was meant to be radiation tolerant. It was
also highly efficient. Only 400,000 lines of code to operate the entire space shuttle. Pretty
amazing, actually, that we could do that. Part of the reason for that is that code in space has
weight implications. That's right. If you're doing more computations, you need more power and more
cooling, which is more mass and more volume. And so efficiency in software is incredibly important
in space, and the space shuttle definitely reflected that. One of the cool things about the
space shuttle software was it had a very, very low error rate. So I'm showing here a table from
a great paper that's got the link at the bottom, reflective of the space shuttle
software history. If you look back to the right-hand side there, the total error rate per
case lock in 1981 was about eight to nine. That's pretty darn good. And within seven years,
it was consistently down around one, which is an order of magnitude better than commercial
software. Some would say two orders of magnitude, depending on the software. And you can see that
by the time we got close to the end of the space shuttle, flying the space shuttle, we had gotten
the error rates in our new updates down to zero. Now, how in the world did we do this? Well, we kind
of had to brute force it, right? It was a lot of verification and testing. So each space shuttle
mission had unique software on it. Now, there was the core software, which was the same, but it was
actually a unique software load because you had a different payload. You had different mass
properties. Maybe you were going to the space station, or maybe you were going to a different
inclination. So for each shuttle mission, months were spent on that unique software load doing
verification in SAIL, the Shuttle Avionics Integration Laboratory. And the idea behind
that is you would have crews and engineers who would run through tons and tons of scenarios,
lots of procedures, to verify that there were no unwanted changes to the software.
This is pretty amazing, considering that there were no auto debugging capabilities at that time.
So it was very manual intensive, but it does show that it is possible to get very, very low error
rates. One of the other interesting things about the shuttle software program was that
not only was verification very intense, but if a bug or an error was found,
the program would go back and take a look at what process escape allowed that bug to slip through.
So in addition to just checking the software, they were also looking at the entire coding process
to go back and see if they could trap any other bugs that were from the same process escape,
and plug that process escape so that future bugs would not be introduced to the system.
Another aspect of the Space Shuttle that was really interesting and added to the resiliency of
the system was the flexible redundancy in the software systems put into the general purpose
computers. So we carried five GPCs aboard the Space Shuttle. Four of them were loaded with
the primary avionics software system, known as PASS, and one computer was loaded with backup
flight software, or BFS. That software was developed completely independently. It was a
separate company, a separate group of people, there was no interaction or interfacing between them.
That backup flight software was there to protect in case there was a flaw in the primary avionics
software system that affected the four primary computers that were used. Now, backup flight
software didn't have all the same capability as PASS. It had basically what you needed to
complete an ascent and get to orbit safely, or if you had a problem occur on entry, to get down to
the ground. So on ascent and entry, we flew with four computers running in parallel with each other
and the backup ready to go. And if there were any failures that you lost confidence in either the
software or the GPCs, the crew could press a red button on the stick and instantly jump over to the
backup flight software and then get into a safe place with that software. Any computer could take
any of that software. If you got on orbit and realized that the BFS computer that had BFS
loaded into it had a hardware problem, that was fine. You could load BFS for entry into any one of
the other GPCs. The mass memory unit on board had several copies of both sets of software.
So if you found an error in the software, maybe there was a coding problem or a corruption,
in one of the GPCs you could reload the software from the mass memory unit and you had actually
several copies to select from in case again somewhere on the mass memory unit
there was a corruption or a failure. Incredibly flexible, incredibly redundant.
The other key aspect that I think had a very positive impact on resiliency but also on security
is a distributed architecture and the space shuttle was one of the first vehicles
to use this capability. So the idea is that you separate critical functions
and then you're very careful and limit what information is allowed to pass between them
and there are checks to make sure that you protect that. So on orbit we would
shut down three of the GPCs into basically into a warm mode and so that we could restart them
if we needed to. We had one actually was warm as a warm backup and the other two were shut down
completely. And then in one computer we had guidance, navigation, and control. Very critical
software controlling the vehicle, knowing where its navigation state was, knowing where you were
pointed, all very very critical aspects of operating the vehicle. And then in another
computer we loaded systems management software or SM software and that had critical functions
having to do with the systems but the communications between these were very tightly structured.
Well we found pretty quickly that three CRTs was not enough information for the crew especially as
our missions began to get more complex on in the shuttle program. And so we added a third tier
to the distributed architecture, a payload general support computer or PGSC. And that's a picture of
the IBM ThinkPad that I flew on my missions as a PGSC. Each crew would carry somewhere between
five and seven PGSCs. They performed functions like a world map so that you could just glance
at the map and know exactly where over the earth you were. You could see critical things like if
there was a loss of communications coming up, a comm outage, or something like that. But we used
them heavily for mission support. In the bottom left picture is me and my friend Koichi Wakata
had just completed a very complex robotics operation using the two PGSCs mounted behind us.
Of course in microgravity it was pretty easy to mount those anywhere that you wanted to. They just
would stick with a little bit of velcro on a platform. And those PGSCs would take data from
the GNC and the SM computers but could not send anything back. So it was a one-way flow of data
from the GNC computer or the SM computer to the PGSC. Now in the bottom right hand corner you see
a picture of the Rendezvous and Proximity Operations Program, or RPOP, which is an app that we used
to visualize the orbital mechanics between the shuttle and the station. And that picture was
taken shortly after I docked to the space station showing my approach, my line of approach.
Now we also used these laptops for email, but the email wasn't directly connected. In fact,
what would happen is the ground would sync up our mail three times a day. So you know,
three times a day we'd get a message from the ground, basically mail call, and you know,
everybody would scramble for a computer to check their email. We could do that because we were
only in space about 10 days to two weeks at a time. We also used it for file sharing and other
things like that. The PGSCs were absolutely essential, but they were also very isolated
and very protected. Now this is a pretty happy story about the overall security of the shuttle
software system and how we approached it, but that doesn't mean that we didn't have unanticipated
issues, almost all of them resulting from complexity. So we used for many, many years
on the space shuttle, inertial navigation units were the primary form of maintaining the navigation
state, you know, where are you in space? And the ground could uplink information from a radar pass
or something that gave us more precise information. But when the opportunity came to integrate a GPS
receiver, when they started to become lightweight enough and ubiquitous enough, that was a great
opportunity because we were doing highly precise navigation maneuvers like rendezvousing with the
space station. Now the first time we tested it was on STS-91 and of course we were smart enough
not to make the GPS receiver be the only generation of the nav state. In fact, we disconnected
the GPS receiver from the primary nav state of the GNC computer. So we didn't want to influence or
upset that, but we wanted to monitor it. So there was an aiding state, basically a secondary state
that the GPS receiver would periodically update. And that way we could sort of measure and see what
the nav state would look like if the GPS receiver was updating it. Well, we had a little hiccup.
The GPS receiver had a software anomaly and basically went into a control-alt-delete type
reboot situation. And unfortunately, at exactly the same time, the GNC computer sent a message
to the GPS receiver asking for an update to the aiding state. Well, the GPS receiver never saw it.
When it came back up on board, it was not a flag that was set. And so as far as the GPS
receiver was concerned, it had never been asked for the information and never provided it.
So the GNC computer at that point said, uh-oh, GPS receiver is down. So stopped asking for updates
from the GPS receiver. Now that aiding state began to degrade, right? You're propagating a navigation
state without putting any corrections in. And sooner or later, the numbers started to go pretty
funky and math errors began to be generated. No problem, right? No problem. I told you already,
very limited information flows between the GNC computer and the systems management computer.
Everything should be just fine. Well, there are two very important things that are communicated
between the GNC computer and SM. The first one is the nav state. So the systems management
computer knows where to point the antenna to talk to the ground. Unfortunately, when those math
errors started to generate, the other type of information came into play, which is error codes.
Of course, the systems management computer wants to know if there's a problem on the GNC computer.
Well, the intercomputer communication bus got flooded with these math errors, which essentially
choked out passing the nav state. So the systems management computer did not receive any updated
shuttle state vectors. And eventually, this antenna lost lock with the satellite that linked
it to the ground. And one of the most serious problems that can happen in space is a loss of
communications. And it happened while the crew was asleep. Well, MCC to the rescue, mission control
was able to actually get in and figure out how to manually... they eventually got a lock
over a ground station. They sent a command to manually point the antenna at the TDRS satellite
and then were able to fix the problem. But it just points out that
it was really incredibly resilient and they thought through as many
errors as they could. But in a complex system like this, you can still have problems.
Now, we learned a lot for the International Space Station. I'd like to say we really upped our game.
We learned a lot about security, starting all the way with the ground system.
Even back in the Apollo days, there was not the capability to talk straight from Houston up to
the spacecraft. But instead, a large set of antennas in White Sands, New Mexico, talking
to the tracking and data relay satellite, which then communicates low data rate S-band audio
information and high data rate KU-band video and payload data. This entire network is completely
owned by NASA. So this is not going through open internet. There's no cloud. This is completely
controlled to NASA. And of course, it's been updated. So just another aspect of the security.
Another interesting issue was around mission control commanding.
Now, people weren't really thinking about hacking, but what they were thinking about
is making mistakes. So an innocent mistake could send a bad command. Now, that was true for the
space shuttle, too. But we had fewer controllers for the space shuttle, all hands on deck,
the six times a year or seven times a year that the shuttle was flying. So a high level of
proficiency in a very small pool of people. Well, with the International Space Station
operating 365 days a year and 24-7, we needed a lot more controllers. So there's a very rigorous
certification process required for controllers in the International Space Station Mission Control
Center to allow them to send commands to the space station. In addition, there are screening
protocols, both before it ever leaves MCC, going up to the ISS, and once it's on board ISS,
to check and make sure that that command will not inadvertently do some damage to the station.
And so, again, really all of these characteristics were really there for safety,
but they have the added capability of adding to the cybersecurity as well.
Now, distributed architecture. This is at a whole new level on the space station.
So starting with the command and control computers, multiplexer, demultiplexer, or MDMs, there's three
command and control MDMs that control the station. And just like the GNC and the SM computers on the
shuttle, in this case, there are multiple separate payload and ISS element MDMs to control the
system. So highly distributed in that regard. And again, with very strict rules about bus traffic
between them. Now, the crew on board the space station does not have cathode ray tubes, I'm very
happy to report. Instead, they use a laptop called the portable computer system. I apologize for all
the acronyms. This is what NASA does, though. Anyway, the PCS is used for the crew to send
commands to the ISS MDMs. It's essentially a remote terminal. It plugs in. They are not networked to
each other. They are plugged directly into the station and can send commands. Now, they have the
same issues that we did on the space shuttle, wanting more screens, more apps, more capability.
And so there is an ops LAN. It is a local area network using station support computers.
These computers are used for procedures, email, and everything else. Including Twitter. Now, you
may be wondering, because I told you on the space shuttle, we didn't have real-time access to the
internet. Well, that's a real hardship on the space station, if you stop and think about that for a
moment. Because there are people living up there for six months. And, I mean, just even really
simple things. Like, if you were up there for six months, and maybe you wanted to go on the
internet and buy your husband a birthday present. And lots and lots of other things. So, and of
course, the onset of Twitter, which astronauts have embraced completely. So, it took a fair
amount of work to set up the cyber security. Because that was already a consideration even by
then. So, there's a computer inside the firewall at the Johnson Space Center that is the proxy
computer. So, the space station support computers talk to the proxy computer, which then goes out
onto the internet. Now, of course, just like any computer, it's still subject, potentially,
to malware. But the most important thing is the station support computers, in no way, shape,
or form, are networked to the actual commanding of the station. They're completely separate systems,
and they don't talk to each other. And so, a hacker might be able to get at, with great
difficulty, but might be able to get at somebody's email on board the space station. But they
couldn't take over controlling the station. Sort of the ultimate in a distributed architecture.
So, the use of computers is so important on the International Space Station. I just want to show
an example, actually, of how they're used operationally. And this is a picture from
my third flight in space, where we had a lot of important robotics operations. So, in the center
of the screen, you will see three videos. And then, underneath the one on the left, and on the right,
are two hand controllers. They control the robotic arm of the space station. So, that's how you move
the arms with those hand controllers. Now, I talked about the PCS, which does command, and it actually
can send commands to the big arm. Turn it on, turn it off, switch power sources, and so forth. And so,
the PCS on the right was set up for ISS commands. And then, there's a backup PCS set up in the
middle. It enables you to quickly, if there's a hardware or software failure on the primary PCS,
you could go to the backup PCS very quickly. And in addition, it allows you to monitor other
critical systems that interact with the robotic arm. And then, the other three computers, the two
above and the one to the left, are part of the OPSLAN. They're station support computers. They
provide extra camera views, procedures, file sharing, etc., etc.
Now, areas of concern in space systems for me. I'd like to shift gears a little bit and say,
this is what I see out there that is worrying me. First of all, uplink and downlink to most
satellites is encrypted, but the data on the bus itself is not. So, of course, it's easy to say,
well, there's no way to access it. It's just out there. It's in space. But in fact, I think it is
an area of concern. It's something that we should be thinking about encrypting onboard traffic as
well. Ground system vulnerabilities is probably the one place that if you're talking to a space
person, they will acknowledge there is a cyber risk. Our ground systems are very vulnerable.
They're just as vulnerable as any enterprise computer, as part of any enterprise IT system.
Something interesting, particularly in DoD, is that all of the constellations and all of the
satellites, most of them have completely unique ground systems. Now, DoD is moving away from that.
They're having a common ground system going forward. But what that means is that they're all different.
Now, the good news is, well, if you figured out an exploit in one, it wouldn't necessarily work
on another one. But the flip side to that, from an enterprise IT management standpoint, is
configuration management, patching, and so forth, is a nightmare. So, that is a real concern.
And fortunately, it's being addressed in DoD. Edge computing. Well, the challenge
there is, you know, I had talked a little earlier about how man-in-the-middle attacks are kind of
hard on satellites, because real-time, you have to see the data stream and then figure out what
you want to inject into it. Well, edge computing is becoming increasingly important. Now, I mentioned
the fact that in the past, it's been minimized to do computations on board. There was really
just enough code and just enough hardware to run the satellite, run its payload, and then
communicate all the data to the ground. And that's, as I said, because it had weight implications.
Well, with the advent of Moore's Law, satellites are becoming smaller and more efficient because
their electronics are more efficient. So, one of the challenges in low-Earth orbit is, as you whiz
around the Earth every 90 minutes, you really can only downlink your information when you happen to
be within sight of a ground station. And any one ground station, you're only in sight of between
5 and 10 minutes. So, you could take a picture, but you might actually end up waiting a half an
hour before you can downlink it. Well, that's actually a challenge if you've got very short
periods of time to get a lot of data down. And so, increasingly, we're moving into a place where
there's more and more computation moving on board and really getting high-quality edge computing so
that you can do all the data management, and that minimizes the amount of information that you have
to downlink. I'm just going to send you a notification that something has occurred, or I'll send you a
highly processed picture of what you're most interested in instead of a giant data stream.
Well, that is also going to make it a lot easier for man-in-the-middle attacks.
Finally, the most serious problem I think we have in aerospace is complacency. As I said,
many people in space think that their systems are not vulnerable to cyber. We have an attitude in
aerospace. It's part of our culture and our values to think about safety. Safety is integral from
design to test and verification and operations. We just think that way. We are going to have to
figure out how to insert cybersecurity and an awareness of that into the values and the culture
of aerospace, all the way from the beginning in design and all the way through to operations.
I really think we are going to need to do that. Now, fortunately, there's some exciting work being
done on cyber-physical systems. One of my favorite demonstrations was in the Information Innovation
Office, or I2O, at DARPA when I was there. It's the DARPA High Assurance Cyber Military Systems
Program, or HACMS. So the picture you see there is an optionally crewed helicopter called Little
Bird, built by Boeing. Now, the HACMS program gave a group of hackers access to the flight data
recorder. And within 30 minutes, they had hacked their way into critical systems on the Little
Bird, which really surprised everyone. So the HACMS program funded several performers to develop
security capability and a secure kernel. So I'm not a software person, but to me, a secure kernel
is very much like the distributed architecture that I talked about for the shuttle and station.
You have a separation of critical functions, and then you have a high level of restrictions about
what information and checks that go on for information that flows in and out of that
critical area. This secure kernel was loaded into Little Bird. Those same hackers were given
access in the same way, and all they could do was shut down the flight data recorder,
not very important, and point the camera. So it is possible to develop secure cyber physical
systems. Now, the HACMS program is over, but the System Security Integrated Through Hardware and
Firmware program, or SIF, is still active. And those of you who were at DEF CON last year
may remember that DARPA, through the SIF program, brought a voting box, a voting computer,
to DEF CON to work on the vulnerabilities and challenges of how to protect that hardware system
from software exploits. So I have high hopes. There's a lot of really good work going on.
I would like to see these best practices and these technologies proliferate into space.
So a lot of interesting trends in space that are going to have an impact on this.
Some of you may be familiar with some of these proliferated low-earth orbit, or PLEO, constellations
like Starlink or OneWeb. Now, I talked about low-earth orbit and having to wait until you
came over a ground station. Well, the idea here is to have enough satellites which are also
connected through cross-links, through a mesh network, such that if one satellite takes a
picture, it can send the information through the mesh network to another satellite that's over a
ground station. And so this would greatly increase the persistence and, in fact, make
data ubiquitous at any time. Now, there's some real challenges with mesh networking.
So the Space Defense Agency is working on that right now. I think you're going to see a lot
more of these cross-links and these mesh networks, which, of course, will increase the attack vectors
as well. NASA's working on going to the Moon and on to Mars. Their Moon-to-Mars program
is a program that, just like the Space Station, they've reached out to international partners. So
far, Europe, Japan, Canada, and Australia have all expressed interest in joining in going to the Moon
to prepare and develop the technologies that will allow us to go on to Mars. And there will be an
orbiting logistics platform called Gateway in lunar orbit. And then, not too different from
the International Space Station, a Moon village made up of different elements that different
countries have doing whatever science they're most interested in, but having shared infrastructure.
As we push out into the solar system, we're going to need a lot more logistics hubs.
So the most efficient way to get from point A to point B in space is through careful transfers
of orbits. Low Earth orbit to geosynchronous orbit. Geosynchronous orbit to lunar orbit.
Geosynchronous orbit to Mars orbit. And you're going to see these logistics hubs that allow us
to refuel or even build new satellites, store and supply logistics, and transfer not just
data, but also goods and supplies out into the solar system.
NASA's already thinking about solar system internet, but there's a big challenge with that.
Communications is done through RF. And what that means is it's prone to blockouts and fading. Now,
the way internet protocol works today is a packet that cannot show that it has connection all the
way to its destination never gets sent. Well, you can't have that in space because you're going to
have these blockages, this fading of signal periodically. So NASA has been working on
delay-tolerant networking that allows data to be cached as it pushes out. And so that way,
if there is a loss of signal, that's fine. It can tolerate microseconds up to seconds
and then pass along the information once the network is re-established. Interestingly,
this has implications as well. DARPA has also been working on it for disruption-tolerant
networking, and that's more for emergencies, disasters, humanitarian disasters, and things
like that where there's not a consistent capability for the internet. And so
delay or disruption-tolerant networking is going to be incredibly important as we develop
a solar system internet. So I just want to say how wonderful it is to be here,
and thanks for inviting me to participate at the Aerospace Village. I'm very excited about
HACCASAT. I think it's a really great idea. It's a way to get insight into what the actual
vulnerabilities are, just like we did the demonstration for HACCAMS. But it's important
to remember that the implications for space cybersecurity are huge. Even today, I talked
about how much of our economy depends on GPS, weather, and so many other pieces of data that
we get from space. But there are bigger implications as we build out a solar system internet.
We're really going to have the opportunity to completely think this through again and go on to
internet 2.0 technologies, like delay-tolerant networking, and build in security from the
beginning, which is something that we didn't do with internet 1.0. So I'm hopeful that someone
out there that's listening today will have some ideas about how to build a more secure
internet for the solar system. And I'm just going to ask you to get cracking on that. Thank you.