From what I read in the PDF, the analysis is very debatable (with The Register putting forward mostly the nonsensical allegations).
Disclosure: I work on satellite design and in the recent years on a program that is part of the NewSpace. I have an intimate knowledge of how what I help design works but a limited knowledge of what others may be doing.
A couple of insights:
* I started working on satellites in a large industrial group where, while not being handled by world class cybersecurity experts, secure communications with the satellites rely on a sane use of proven encryption protocols
* I am not sure when this level of security became standard and what was done to secure the satellites before hardware-level encryption with modern algorithms became available
* I was astounded when I discovered the level of casualness for everything related to security on scientific satellite projects, with even recent projects led by major agencies considering that always encrypting command and monitoring is overkill
And my main grip is that the study relies on asking universities that have the lowest bar in terms of caring about security (they already struggle enough to build a working thing) and then extrapolating from a specious argument that it must be worse on commercial spacecrafts.
> One surprising result was that the larger the satellite, the more vulnerable it was. Larger machinery typically used more commercial off-the-shelf components and was thus more vulnerable since the code base was public, whereas smaller CubeSats tended to use custom code.
Also
> a satellite should be designed so that TCs do not compromise the satellite’s stability without further validation
Says who ? What validation ? If an operator had the right to have a telecommand sent to the satellite, who or what aboard the satellite should decide if this telecommand was legitimate.
From experience, there is a myriad of things that you think are usually not a good idea to make your satellite do and then, when you need it as a workaround or mitigation for an unexpected condition, you are happy you have not implemented a list of authorized actions that is too constrained.
PS: It reminds me of the guy that was able to capture the GPS coordinates of an airplane broadcasted to the In-Flight Entertainment systems and got a lot of press coverage by extrapolating that it meant he could also take control of the aircraft from his seat in the cabin.
Agreed. Generalizing the security of modern spacecraft by what university CubeSat teams get up to is like generalizing all of modern cybersecurity based on an anecdote about a one man company that left an SSH server open with the root password set to "12345."
Don't get me wrong, I have the utmost respect for what academic CubeSat teams can pull off with miniscule budgets and resources, but this doesn't reflect what actually happens outside the university context. Modern commercial spacecraft are well-secured, particularly on telecommand. For a look at what the professionals actually do, I suggest people take a look at the CCSDS 350.x series Green Book publications: https://public.ccsds.org/publications/GreenBooks.aspx
As someone who has worked on private in-flight entertainment systems I haven't heard of the story you mentioned about the GPS coordinates but I can confirm that controlling the plane would take a lot more than just getting on the RS-232 or RS-485 read-only busses the FMS sends data on.
I think it was this one [1]. The story is older than I remember (2015) but at the time I was working on aircraft system design and knew people well-versed in ARINC 664 and everything related to aircraft data network segregation between domains.
And a lot of the noise was coming from Boeing requesting Special Conditions [2] for the certification of recent airliners where segregation is less absolute than when systems had a floppy reader to install updates.
> Hacker Chris Roberts claimed he was able to break into the in-flight entertainment system up to 20 times on separate flights and that on one flight he was able to make the plane “climb” and “move sideways” by accessing flight control systems from a laptop in his seat.
The remote satellite/robot shouldn't decide what is a valid command (beyond verifying it comes from a valid authority), because we have multiple situations where NASA has recovered a space probe/robot by sending commands never dreamed of when the vessel was launched.
It really depends on the definition of a "valid command". What do you do when you receive a command that you don't recognize or the parameters are in the wrong format? You would just ignore it and increment the invalid command counter. You wouldn't want to just block a command that would be valid at any other time just because the receiver isn't expecting it. Although you may want to block a command that could cause harm to the system in it's current state (don't allow the command to blow the fairing bolts while the rocket is still on the ground). I don't think I'd want to allow accepting commands that don't conform to the correct format because even though you could potentially solve some problem with something like a register overflow, you'd be leaving yourself vulnerable to that same exploit causing harm, accidentally or maliciously.
If you have a command called SET_MODE and it only has the options 1, 2, or 3, it would be ridiculous for the system to accept mode 4 since it doesn't exist. The system should refuse the command. If the SET_MODE command actually just sets a bunch of toggles for you in the background, it would be a good idea to retain control of those toggles so you can customize the configuration and effectively make your own "mode 4" for any emergencies.
Disclosure: I work on satellite design and in the recent years on a program that is part of the NewSpace. I have an intimate knowledge of how what I help design works but a limited knowledge of what others may be doing.
A couple of insights:
* I started working on satellites in a large industrial group where, while not being handled by world class cybersecurity experts, secure communications with the satellites rely on a sane use of proven encryption protocols
* I am not sure when this level of security became standard and what was done to secure the satellites before hardware-level encryption with modern algorithms became available
* I was astounded when I discovered the level of casualness for everything related to security on scientific satellite projects, with even recent projects led by major agencies considering that always encrypting command and monitoring is overkill
And my main grip is that the study relies on asking universities that have the lowest bar in terms of caring about security (they already struggle enough to build a working thing) and then extrapolating from a specious argument that it must be worse on commercial spacecrafts.
> One surprising result was that the larger the satellite, the more vulnerable it was. Larger machinery typically used more commercial off-the-shelf components and was thus more vulnerable since the code base was public, whereas smaller CubeSats tended to use custom code.
Also
> a satellite should be designed so that TCs do not compromise the satellite’s stability without further validation
Says who ? What validation ? If an operator had the right to have a telecommand sent to the satellite, who or what aboard the satellite should decide if this telecommand was legitimate.
From experience, there is a myriad of things that you think are usually not a good idea to make your satellite do and then, when you need it as a workaround or mitigation for an unexpected condition, you are happy you have not implemented a list of authorized actions that is too constrained.
PS: It reminds me of the guy that was able to capture the GPS coordinates of an airplane broadcasted to the In-Flight Entertainment systems and got a lot of press coverage by extrapolating that it meant he could also take control of the aircraft from his seat in the cabin.