Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm wondering how do they prevent non-NASA entities from sending commands to the rover - are they using some sort of cryptographic signatures when sending the commands?


I'm not sure about Curiosity in particular, but I work in the space industry and can say that commands are normally timestamped and encrypted. The encryption stops someone from commanding the spacecraft, the timestamp stops someone from recording a transmission and resending it later.


So there’s basically a real Goldeneye key. And you could really use a Goldeneye key duplicator before leaving Severneya!


You need access to the big Deep-Space Network of radio dishes.


1. You can hack into the DSN, and try to do it that way.

2. Set up an 80-meter dish in your back yard, with a team of NASA RF experts.

With step (2), the authorities will zero in on you in a second, so the emphasis is definitely on the cyber security of the ground infrastructure and not on SSL-over-space-link-communication.


(2): there are plenty of third world countries or foreign government agencies where placing a 80-meter dish is not a problem.

Although the process seems a bit intimidating - http://deepspace.jpl.nasa.gov/dsn/features/dsnbuilt1.html


Not just assembling the dish - you also have to know the ephemeris schedule, bit coding scheme (it changes based on circumstances), packet formats, software infrastructure... In the great scheme of things, my friend, Cuba or Zimbabwe secretly erecting an 80 meter dish just to f--k with a rover on mars isn't really a concern. Even though ESA or China or Japan might conceivably have the theoretical capability to do this... there are other things to worry about.


They could just DOS it by blasting it with white noise.


This kinda raises question. I for one would not use encryption just to maximize bandwith efficiency. Deep space program are no where close to being a tactical advantage over another country. I wouldn't see why someone would like to screw it up.

On the other side, there's always a moron out there to crash the party. So even if I wouldn't use encryption, I wouldn't be surprised if they use it.


I for one would not use encryption just to maximize bandwith efficiency.

Encryption typically doesn't make messages longer.


We're not talking about your average data. We're talking about optimized data. Of course there's an overhead.

EDIT: removed specific type of data


I'm not sure what you mean by "optimized" data.

Edit: my very rudimentary understanding of information theory tells me that there's no "average" or "optimized" data, only varying amounts of entropy (AKA compressibility). My limited knowledge of radio and electrical transmission says that transmitted data is encoded to make effective use of the transmission medium (e.g. 8b/10b encoding, 8-to-14 modulation, TMDS).

So, if by "optimized" data you mean "high entropy" data, encryption should have no effect on that. Or, if by "optimized" you mean encoded for the transmission channel, you would run your encryption process before the channel encoding process.


I do have a question however. I just read about 8b/10b encoding and I think we can agree that 8b/10b has around 20-25% overhead. This means that for the same throughput (29k/sec) we have 21.75k/sec of data.

Since TMDS is a superset of 8b10b than it's a fair assumption to think it has the around the same overhead.

Now I know we're only talking encoding here, not encryption but still, I wonder:

What kind of encoding are they using, because smaller the encoding is, the weaker the encryption is (Unless I got this wrong...)?

Now if all my assumptions are correct could it be possible that they use an encoding that makes encryption useless?


Encoding != Encryption. Encoding is on a line level, so for example, 8b/10b is used in HDMI to prevent a DC bias on the line. The way it works is by making sure within a certain number of 8 bit inputs (I think 3), the resulting 10b outputs will have an equal number of 1s and 0s, therefor preventing the physical wire from charging itself closer to V+ or V-, which in turn helps prevent bit errors.

8b/10b has exactly 25% overhead, this is the difference between baud per second (what the line is capable of transmitting, which is on the 10b side), and bits per second (which is the decoded 8b data). If you have a 10kilobaud/second line, you'll have an effective data rate of 8kbit/second.

Encryption is done before the encoding stage, the encoding scheme doesn't care and isn't affected by the encryption.


At first, I wouldn't have thought that they would use encoding to maximize efficiency. But now that I think about it, their goal isn't efficiency but rather consistency. So yeah I was wrong.

Maybe I thought this was more primitive than what it really is :/


You seem to be trying to say something, but it's not coming across. What is primitive? How is it primitive? How do you describe the difference between efficiency and consistency in your usage? Is English not your primary language?

My exposure to this stuff is limited to a few exercises in a Matlab class years ago, plus what I read on HN and Wikipedia. Based on what I understand, from a data transmission perspective, there is no difference between efficiency and consistency. There is a theoretical maximum amount of data that can be transmitted using a given medium, bandwidth, and error rate. The only goal is to get as close to that maximum as possible.

Also, there's no shame in admitting you're wrong. In fact, every opportunity to be wrong is an opportunity to learn.


Yeah, english isn't my primary language and I haven't spoken it in a long time so sorry if I can't make my point across :)

I'm not ashamed for being wrong. If that'd be the case I would have been ashamed my whole life heh.

When I said consistency I was referring to low-error rate in the signal. I should have said that but couldn't find the correct word for it.

Efficiency meant efficiency in the bandwidth usage.

So in that sense, there's always a tradeoff between efficiency (use 100% of the bandwidth to transmit real data) and consistency (make sure that 100% of the sent data is error-free)

Now, when I first wrote my comment. I had the feeling that communication was very basic commands. like a 2 bit integer for movement direction (00 up, 01 down, 10 left, 11right). So if you'd use such a scheme to communicate instruction to the rover, there would be an obvious overhead (encoding 2 bit into 4, 10, etc).

But now that I really think about it, instruction sent to the rover are probably very complex, which increase entropy, which in the end, made my first assumption wrong, is this clear? I hope it is ;) If not, I can rephrase !


In low-bandwidth environments, the pipeline is like this:

1) plain data initial stream.

2) compress it.

3) encrypt it or/and sign it.

4) add error-checking or even error-correction information.

The reason you do encryption (3) after compression (2) is because you don't want encryption to affect the compression rate of the initial stream.

If you were to do it in the reverse order (first encryption and then compression) then yes, the resulting message could be bigger.


There isn't. You could easily achieve zero overhead by shipping a rover with a OTP for time-keyed IVs and just not do any padding.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: