> ...so how do you keep it secure? > Is hosting a RPi in space different from hosting one on the ground, reachable over the public internet? I assume it is, but tell me more!

It is somewhat different from a security point of view, but the gap between them is getting smaller. The main "obstacle" to hackers taking over your satellite is that it is somewhat difficult to set up a UHF/VHF/S-band ground station with enough transmit power to reach the satellite. And you need knowledge of the command protocol that the satellite uses. But ground stations are getting cheaper every day, IMO you can build a fairly capable transmitting setup for ~1000€. So the remaining protection is a form of security by obscurity: "we invented this command protocol, so nobody knows how it works". But that can obviously be defeated by recording ground station signals and some dedicated reverse engineers.

When those protections fall away, you'll find that a lot of satellite/CubeSat software out there is quite vulnerable (see https://jwillbold.com/paper/willbold2023spaceodyssey.pdf). You often find things like commands that are literally "arbitrary memory read/write". While they are a nightmare from a security point of view, they are extremely useful for operators of experimental satellites, e.g. to patch software in memory to fix bugs or read variables that are not exposed as telemetry. I have written a few of these patches myself, and my friend PistonMiner used them brilliantly to hack in a software update capability and revived a 15 year old CubeSat that was assumed to be dead - see their 38C3 talk: https://www.youtube.com/watch?v=KdTcd94pVlY

If you ask me, the way to keep satellites secure is to basically apply the lessons that we have learned in terrestrial computing to space applications. Things like using encryption/authentication, process isolation backed by a MMU, memory safe languages, etc. That's what we're trying to do with RACCOON OS btw. You can take at the flight software of CyBEEsat, a 1U CubeSat that is launching soon(tm): https://gitlab.com/rccn/missions/cybeesat

▲

ronsor a day ago | parent [-]

> So the remaining protection is a form of security by obscurity: "we invented this command protocol, so nobody knows how it works".

ChaCha20-Poly1305 authenticated encryption is cheap for low-resource systems and trivial to implement. There's no reason not to use some form of encryption, if at least to prevent forged commands. (Preventing replay attacks is left as an exercise to the reader.)

	▲	jdiez17 a day ago \| parent \| next [-]
		There are some reasons. As a satellite operator, the worst thing that can happen is getting locked out of the satellite for any reason. So the risk of implementing a “new” technology that has a high risk of locking you out if you lose the keys for some reason sometimes outweighs the benefit of increased security. So I think there’s some work to do in building generally applicable key management practices and backup ways of reestablishing a command link.
	▲	numpad0 a day ago \| parent \| prev [-]
		Embedded guys don't like command authentications, I think because it's an SPoF with probability attached that are repeatedly tried. They know bits flip and program counter skips, and so they even avoid use of "or equals to" conditions for loops. But they're using signature enforcement in cars nowadays, so that particular fear should be slowly subsidizing.