2,036 karma · joined November 15, 2012
j.diezlopez@tu-berlin.de
Two paragraph later:
> Entire will be based on three key components: a git-compatible database [...]
So which one is it?
... and which forces do you think are the core concept of "the American experiment"?
Of course, a hardware switch is always more secure.
What period of human history are you referring to exactly?
Feel free to read the chapter „Linksextremismus“. It talks about various violent Antifa groups and other cases. Keep in mind that the definition of „extreme left“ refers to organizations that want to replace the basic democratic system with communism or anarchy (according to the German constitutional court).
It does not necessarily include „political craziness“ that we may disagree with. The point of these legal descriptions of organizations is not to be used as a political weapon for parties you don’t like. You have to do some significantly malicious stuff to be considered as such.
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
Resets etc. are common, most likely caused by software bugs. This is more or less assumed as a fact of life; software for space applications is often as stateless as possible, and when it’s required you’d implement frequent state checkpoints, redundant data storage, etc. These are all common practices that you’d do anyway, it doesn’t make a huge difference if the software is running on a rad-hard microcontroller or off the shelf Linux processor - although (IMO) there are many benefits to the latter (and some downsides as well.) Assuming a base level of reliability, of course - you don’t want your OBC/PDH to overheat or reboot every 5 minutes.
Any opposing views?
> This will not primarily be for rescue ops.
It's a common meme in dual use tech. When you apply for funding you mention "search and rescue applications" and people know what's up.