Hacker News Reader

Comment by donohoe | Hacker News Reader

I worry about encryption of sensitive data.

I don't doubt it can be done, but can their "twenty-cent" chip handle it without messing up its lightweight low-power nature?

View on HN

Modern microcontrollers can be had in the sub-$5 range that support hardware implemented encrypting algorithms. Mostly it's a worthless feature but we aren't far out from it being more or less standard even in the $0.20 guys.

The bigger issue is that the entire point of this system is to remove cost of deployment and maintenance for cheap highly distributed lo-fi systems. The cost of keying all those devices for encryption would defeat the purpose. Also the added data overhead of the encryption would possibly exceed the amount of actual data you are trying to get out of the system. Also, why do you even want to encrypt it in the first place?

The Economist article for the same subject suggested using this in medical devices.

One-time keying may not be as expensive as you think, a simple matter of IC fuses, but you're right that key management and "enrolment" generally for these tiny things will be a pain.

Medical is just an example of the economist not understanding the product vs the buzzline. It is a terrible tech implementation for medical, but I agree that you generally want medical encrypted. However, if you are talking medical, the cost of the sensor device is tiny compared to other costs even for very expensive sensors.

Fuse based programming would have a whole host of issues. You either need a destructive fill device or load at the factory. If you load at the factory you have to trust them to not retain copies, keeping in mind that it will probably me manufactured in China. If you use a fill device you open up for destructive programming (IC fuses) you open up a bunch of liability for accidental damage to the device plus the cost of a technician plus training can quickly swamp out the cost of your low cost sensor network.

Finally, these sorts of networks work best with asynchronous uni-diretional communication applications. This makes good crypto-practices very difficult. If you chose full crypto and handshake protocols, the amount of data you spend just exchanging keys and handshakes will exceed the data the sensors collect.

> Also, why do you even want to encrypt it in the first place?

I want to encrypt and authenticate any and all wireless gadget data because I've been paying attention to the last 5 years of defcon talks.

I.e. you want to make the world less fun for the type of people who present the DEFCON talks. :(.

HN ate my reply, apparently I was posting too fast, but as a TLDR you can avoid the overhead of encryption and authentication by revisiting the trust framework in the design of your network and simply assuming that you don't trust your sensors. This moves the overhead from the sensors and the network which are heavily constrained to the processing of the central authority where you have a lot more lee-way and moore's law to help. If you are interested in learning more about this sort of system, it is a topic of research in control theory often lumped under robust systems.

Since backscatter systems depend on on an RF source, I wonder if work has been done on encrypting the source signal (pseudorandom bit pattern for example), then modulating the random stream at the device and decoding the backscattered signal at the receiver - essentially a streaming XOR cypher.

In this system the RF source you are sending is effectively the IF component for the sensor's Tx chain. Because it is so high power and such a clean pilot tone, the sensor can eliminate it's IF generating oscillator and output amplifier by just mixing the data onto the receive pilot tone and retransmitting it. This is how the sensor is made so cheap and low power. If the pilot tone was cyphered, it wouldn't mean the data was. That is, you could recover the unencrypted data if you recorded a copy of the pilot by mixing. There is also the issue that, because the pilot tone provides the power to the sensor's carrier, any spreading of it's spectrum, which is what random xor encoding does, makes it harder to recover and use as the IF component for the sensor's radio chain. The last issue here is that the CSS standard does not allow this sort of non-linear modulation.

All that said, it's not a fundamentally bad idea. Pseudo-random xor encoding of signals is a technique used all the time to increase orthoganality between signals for a variety of encoding schemes.

>>> That is, you could recover the unencrypted data if you recorded a copy of the pilot by mixing.

Yes, thanks for the response!

Reply on news.ycombinator.com