Help w small system comm security

You've made a creditable attempt at _starting_ to analyze the threat scenario. However you haven't really detailed in your post exactly what threats you're trying to prevent.

If you're merely attempting to prevent message spoofing, playback attacks etc, try protecting the whole message with a rolling-code encryption system. The one with which I'm most familiar is Microchip's Keeloq (download the datasheet for the HCS300 encoder ASIC to see more information). This particular scheme has been cracked so I wouldn't actually use it

The approach here would be to send your message in the clear, or encrypted with a simple algorithm of the type you describe, but then follow it with a rolling-code ciphertext block; if the code doesn't match, your base station should ignore it.

It's already been pointed out that you should define your threat model with more detail.

Your approach with XOR is vulnerable to for example:

- an attacker can flip single bits in the ciphertext that result in flipped bits in the plaintext (at the same position)

- an attacker can remove a message from your channel, bringing sender/ receiver out of sync, and resulting in incorrect plaintext and (hopefully just) denial-of-service.

- if you use a seed value to counter the latter, an attacker can replay messages.

etc.

SNIP

SHIP

Do you have enough cycles for AES considering your power limitations? Every processer cycle is so many nW... If not, go for something like TEA ore self shrinking generators. Much smaller but not as thoroughly verified

I saw an ASK RF protocol that used the property that an attacker can change a 0 into a 1 but not the reverse. I can send you some pointers later

LFSR are not very secure. Adding something non-linear may improve things, but see the A5 breaks that this is difficult An other approach is using a random timeslot, if you can synchronise your clocks properly

Dont even try....

Wim

Yup.

I developed a system recently which used small, very-low-power processors transmitting service meter readings. Some form of encryption was clearly necessary, but I had very limited computing abilities at the transmitting end. The most likely threat scenarios were not dire, but worth some protection none-the-less.

The solution I implemented, which was both easier and considerably more effective than I'd hoped for, was a very low overhead encryption algorithm: TEA (Tiny Encryption Algorithm). The entire code for it (about a dozen lines of C) is easy to find on-line - I just discovered that there's a version (including source) on WikiPedia.

Maybe this would work for you...

-- Mark Moulding

Ditto.

I find TEA (or preferrably XTEA) a great way to get reasonably strong encryption for most applications. If you have the horse power AES is more tested and has wider acceptance as a "strong" scheme, but it costs you cycles and memory. Add some salt to every message and roll the keys every once in a while to get that warm and fuzzy feeling.

That's all good, but what I find more interesting with this problem is the key management. Obviously this goes back to the threat model discussion and will be highly depending on the surrounding circumstances.

The model I'm using for one system goes like this;

Each node receive a unique random key and a serial number in production. A central server stores the key/serial combination and when nodes are commissioned they need to communicate with that server. From there a session key can be established and the system is secure from that point forward. The obvious weakness is that you need the central server and ability to communicate with it (in my case all the nodes have access to Internet so I maintain a couple of registration servers). The good is that even if someone hacks a node, sucking out the production key by delayering the chip or whatever, they can only mess with that single unit's comms. The rest of the system is unaffected - so this thwarts bootleg manufacturers pretty efficiently and limits the damage to the node that was hacked (and was probably destroyed in the process anyway).

Another way would be to trust the installer. If there is a way to "marry" the node with the host in the installation process by entering a password on both sides, or by letting them communicate over a local channel (like a direct serial link), then that could establish a session/system key. Problem is that we expose the key exchange to the installer. If he's the enemy then the system is compromised. Sure, we could obfuscate the key exchange, but it can be hacked.

So are there better models? A PK-scheme would be nice, but that would require much more horse power. The implementations I've found using RSA are pretty heavy - is there a light-weight way? While a PK-scheme would secure the session, it doesn't validate the authenticity of the node. The only way I can think of to do that is to hide a key inside the chip and hope that the attacker can't get it out. So we have to trust the chip maker...

Just my 2c.