A look at Chang’e 5 telemetry | Hacker News Reader

A look at Chang’e 5 telemetry

destevez.net

154 pointskwk131 comments

Some video that was extracted.

http://www.r00t.cz/Sats/Change5

Pretty awesome. I'm guessing most of those single-frame white streaks are cosmic ray strikes on the camera sensor.

They say that it is dust floating around, rather than cosmic rays. The specks appear to be moving in a way that "looks normal" (not that I have any idea) for dust moving around rather than what I would imagine random noise from cosmic rays would like like.

The blips/noise could be rays, or could be rotating reflective dust specs that happened to reflect light for just a moment.

I'm so paranoid about privacy lately that not knowing what Chang'e was, the first thing I thought was "great ... another thing stealing my data".

Glad to see some actually good telemetry for once.

Right, telemetry used to be a positive or neutral term :) By itself it should not be so bad, either, but we overcorrect and say no to any data collection.

What kind of flight profile did China take?

I assumed it would take 3 days to get to the moon. I think that’s how long Apollo took. But they launched on Monday, and won’t get into lunar orbit until Saturday, which is 5 days.

But being that this is a robotic mission, that expediency wasn’t as important. And to save fuel, they might have circled around the Earth a few times to get a gravitational assist to launch to the moon.

Asking for a friend: A lunar flight planning physicist

hohmann transfer orbit, I read somewhere.

Hohmann transfer is for going between two bodies which are both orbiting a third, central body no?

I believe a Hohmann transfer is just a method of changing between two orbits of a central body. In this case it's just moving from it's intial orbit to the Moon's orbit, which are both around the Earth.

The Hohmann transfer does not include the capture burn that is required to enter a sustained orbit around the Moon.

Disclaimer, I'm just a KSP fan, so feel free to correct any of the above. Had to make an effort to use Moon, not Mun.

This is the kind of fun stuff you can do with a nice SDR setup :-) Love it.

I had not seen the CCSDS coding before, the seems like a bit of overkill for from the moon to here but perhaps they had too much signal fade on Tianwen-1 ?

Would love to see the actual CCSDS data frames, and check whether they are using PUS data packets or some other esoteric format :)

Chang'e unchained!

So the downlink data transmissions were not encrypted?

Which leads me to think that the uplink transmission is not encrypted either.

I wonder what how capable it is for an amateur (hacker) to send a malicious command to their space craft.

That would be a shame, since China might begin to do some serious ground breaking science on the moon, that will eventually bring benefits to mankind.

Unlikely... Since it's an obvious attack vector.

Maybe they didn't encrypt downlink because they may need to work well with 3rd party telemetry partners? Nothing classified for a moon probe as well.

Yeah, the FCC has an explicit carve-out in the amateur radio Part 97 for uplink remote control using encryption(97.211b). I would assume they'd use at least something similar here.

SDRs transmitters/transceivers are cheap. Seems like the primary issue would be making your transmitted signal strong enough to actually reach the moon or nearby spacecraft. I'm sure e.g. SpaceX could do a fair bit of meddling if they were feeling so malicious (or unwittingly compromised) though.

I'd bet it'd be pretty difficult to intercept a command to reverse engineer it unless you have a radio in orbit, in the right place at the right time.

And I would be very surprised if commands were not at least signed/verified. That's one function call with a modern crypto library.

It might be easier to send slightly plausible noise (right frequency/modulation) to jam it.

Why would you assume the uplink isn't authenticated and/or encrypted, given that the downlink data has very little value but interfering with the uplink could disable the probe?

Spacecraft are power and compute limited. It's entirely possible the designers chose not to spend the resources to encrypt a downlink that isn't sending anything that needs to be kept secret. In contrast, it's reasonable to assume that the uplink is at least protected by a HMAC, because the consequences of an adversary exploiting the uplink are so great.

The Chinese are well aware that the US security establishment is petty enough to interfere with a scientific probe purely for its own amusement. They will have taken precautions to deter this.

That last remark was a bit uncalled for, but otherwise, you're spot on: this isn't a web API, there's no reason to assume symmetrical security measures on uplink and downlink. Keeping downlink in the open is actually pretty standard with satellites, but uplinks are almost always protected, because you don't want third parties to send commands to satellites or probes - be it adversaries or bored teenagers with a radio and a dish.

(And particularly in context of a high-profile mission like this, they definitely would want to keep telemetry open for third parties, to ensure their achievement is independently verified and recognized by the international community.)

I don't see it as unjustified to point out that the primary risk actors in China's threat model will be the American armed forces and/or three letter agencies.

I didn't meant the "US armed forces" part, but the "them being that petty" one. Messing with a lunar mission would be risking an open conflict. I'm hoping they know better than to try that.

Hey it's thanksgiving and I'm a little drunk. Apologies for any errors.

Keep in mind that "encryption" bundles together four different concepts: confidentiality, data integrity, authentication, and non-repudiation. To successfully do space science, data integrity is suuuuuuuuper important. Like if you send a command to the spacecraft to fire the engines for (binary) 000000010110010 milliseconds, and a cosmic ray happens and the spacecraft receives a command to fire the engines for 001110010110010 milliseconds, congratulations, your mission is totally fucked. Voyager was launched with Reed Soloman error correction before fundamental cryptography fundamentals like DES, DH or RSA were published.

Confidentiality is kind of a non-issue with spacecraft. If ground control says, "Fire the thrusters for 174 seconds, authentication code 0x8d0a8fc7" or whatever there are no secrets. Non-repudiation is also a non-issue: NASA doesn't need to prove to NASA that it never sent the self destruct command. NASA already knows what commands it sent.

Authentication is the bit that prevents unauthorized commands, and honestly, the authentication tech is not that complicated. We need 128 bit keys (or 256 if you're paranoid) to do confidentiality correctly, but we use 64 bit keys with "known broken" algorithms like MD5 to do authentication, and that's known to be totally safe.

So of the four pillars of encryption, one of them had to be built in from day 1, or you'd never accomplish anything. One of them is kinda of an easy problem actually, even with old technology. The other two aren't part of the attack surface.

Spacecraft also have a HUGE advantage built in: shared secrets. Ground control can program a secret key into the spacecraft before it's launched. After it's flying around you can leverage stuff off of that shared secret to authenticate communications. This totally sidesteps all of the hard parts of TLS, which involve certificate authorities, certificate revocation lists, etc.

Great response! Happy Thanksgiving.

There is some value in confidentiality of uplink, though. If the channel from Earth to probe is encrypted, you do not reveal your command protocol.

And, in all likelihood, there is either a common command protocol or a family of protocols for all Chinese spacecraft. Designing a brand new protocol for each class of spacecraft would be time consuming and add complexity to space operations.

It is easier to have just one command protocol, or just slight variations thereof, and use it for connection with all hardware out there.

On the confidentiality angle, I'll also add: space is very transparent if you have means to look at it. So if ground control says, "Fire the thrusters for 174 seconds", even over undecipherable one-time pad encryption, every nation with any kind of interest in space would see (or otherwise learn about) that particular spacecraft firing its thrusters for 174 seconds at a particular time. That's true even with military payloads where they try to keep things secret; with scientific missions, trajectories are openly shared anyway.

It's a lot harder to detect spacecraft manoeuvres than that. Depending on the type of thruster you might have a chance of detecting it if you have extremely sensitive, very expensive equipment closely monitoring a specific satellite in LEO, but nobody has enough of those to monitor every satellite, or even every military satellite constantly. At the distance of the Moon, forget it. No Earth based telescope can even resolve Chang'e 5 at all at this range, let alone a thrust plume. But even in LEO observing from another orbital sensor it's not easy, if the thruster is on the far side of the satellite, or using cold gas thrusters, or your view of the thruster is sufficiently blocked by a solar panel or antenna, also forget it.

> but we use 64 bit keys [...] to do authentication, and that's known to be totally safe.

I disagree with that. Using 64-bit authentication tags is fine, since they can only be attacked by sending guesses to the target system. 64-bit however are too weak, since they can be attacked using same offline brute-force attacks used against confidentiality. They have the advantage that an attacker needs to break them before they're changed/the project ends, while confidentiality can be important for many decades after that. But even then, I'd say 96 bits is the minimum authentication key size for a high value system, while I'd go with 128 bits.

What about DoS? Surely the resilience of the live system to unauthorised or unintentional load on expected receiving channels is critical here too?

I don't know about a lunar mission, but for the deep space probes, you need a global array of 70m dishes, and the knowledge of exactly where to point them, before you can even have a chance of communicating.

Honestly, I'd be extremely impressed if hackers managed to issue a command to a spacecraft.

Some hobbyists tried to salvage an old NASA probe (with NASA approval): http://spacecollege.org/isee3/ and they were able to fire thrusters once.

I would expect NSA would be already doing what these guys did with regards to receiving data. It’s practice for when they want to do the same with Chinese spy satellites. And, if they want to embarrass China, they could cause a failure by uploading a rogue command. NSA certainly has access to the required dishes.

Reply on news.ycombinator.com