Cryptography: serial-link validation

Hello Tim,

if it is possible to store a secret key in both controllers, it could be done like this:

- the master sends a command to the slave

- the slave stores the command, generates a random number, encrypts it and sends the result to the master

- the master decrypts the the random number and sends it back

- if the random number matches, the slave executes the command

As encryption algorithm you could use AES. Downsides:

- needs bandwidth (2 x 16 bytes)

- the communication (command and the response to it) is not secure But the slave would only execute commands from the master.

HTH

bye. Mike

Of course, the first fundamental question is how many resources (code space, time, etc.) you are willing to dedicate to security.

A relatively simplistic suggestion:

send 4 numbers, the first 3 being coefficiants to plug into a polynomial equation and the fourth being the value: slave: master:

That should be relatively simple to code and quick to compute, yet require a reasonably large sample before a man-in-the-middle attack would find enough examples to figure it out.

This leads to the second fundamental question - is the value of diverting the information (your scenario doesn't envision encrypting the data, so any m-i-t-m could view it as it passes by) greater than the cost of obtaining the algorithm to an attacker? If so, then you are probably better off with a public key system (rip off GPG's). Each slave would encode a number (or some other validation string) with the master's public key and send it. The mast would decrypt the number and re-encrypt it using the slave's public key and send it back.

hope that helps

Joe

Schneier's _Applied Cryptography_, once you've allowed for the errata. Off the top of my head, if the command protocol called for adding random salt, and/or a checksum and encrypting, then you might count on valid commands coming only from the real master.

Mel.

You really need some form of rotating key algorithm to avoid serial being replayed several times to work out what goes on.

AES may be overkill, does the unit need all comms encrypted or only handshake.

Especially as RS232 is easy to monitor and record...

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

I forgot to bound the problem: it's really there to deter moderately casual hijacking of the parts of the system. So the security necessary is roughly equivalent to the lock on a hotel door: it's not something that you expect to keep everyone out, just something to keep every Tom, Dick and Harry from traipsing through.

And yes, the rest of the communications will still be in the clear, and that's OK.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

It depends upon where you draw the line between the "serious hackers" and the rest.

If the link is authenticated once but all subsequent communication is unencrypted and unauthenticated, it's trivial to perform a man-in-the-middle attack using any computer with 2 serial ports, i.e. have the computer pass through the authentication data then analyse and/or modify the subsequent communication as desired.

If you consider that to be the work of a "serious hacker", then the task is simple, but you're setting the bar rather low.

If you want to protect against such a scenario, you really need to either authenticate all data (if you're only trying to prevent modification), or encrypt it (if you're trying to prevent monitoring), or both.

I assume that the master and slave can share some sort of pre-defined key.

The slave picks a random number, and sends it to the master. The master applies an encryption function, then sends the encrypted version back. The slave does the same encryption itself, and compares.

For the encryption function, I'd recommend a CRC. You probably already have a CRC in the code somewhere anyway, they are easy to code, and they are very good at "messing up" numbers, so that it is practically impossible to predict the patterns. Your encryption function is just a CRC of the random number, the shared key, and some salt (a fixed value shared by all your systems).

If you want to encrypt the actual communication, I'd recommend starting with this same process. Then you take the encrypted code (which both sides know) and use that as the seed for a pseudo-random number generator (there are lots of algorithms for these, it doesn't need to be particularly good or random). These pseudo-random numbers are used to make an xor-mask that you apply to the actual data telegrams. Depending on your paranoia, you can pick different lengths of masks, and pick how often you change it (every telegram, every hour, whatever).

A CRC is cryptographically very weak, because CRC(A XOR B) = CRC(A) XOR CRC(B). It's probably good enough for the casual hacker, but it won't stop anybody serious..

I'd recommend using XXTEA instead. See

It's very easy to implement, while providing a good level of security.

I had considered CRC, and it's probably good enough -- but if I can implement something better easily, I will.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Basically, you are searching for a MAC (message authentication code). You can build a weak one using CRC or you can replace CRC by a cryptographic hash function like MD5 or SHA. SHA-256 can be implemented straight forward from the NIST paper in less than 100 lines of C code. If you don't have enough space for the whole MAC in your protocol, you can truncate it (while losing a bit of security).

Markus

I don't think that makes sense. What's the point of "protecting" the connection if the only thing an attacker would need is to sniff into the link _after_ it's been authenticated?

Just about the bare minimum level of security worth having would require

1) some half-decent crypto and robust (P)RNG to authenticate endpoints 2) based on 1), generate and exchange random keys for the main data transfer 3) using the keys from 2), encrypt _all_ sensitive data using a cypher focussed on throughput (a "stream cypher") 4) for long-running connections, go back to 2) or even 1) every once in a while

Serious choices would be RSA or DH for 1), DES or AES for 3)

If you want to keep it simple, MD5 for 1), XOR for 3)

The point isn't to prevent unauthorized knowledge of the messages being passed: the point is to prevent unauthorized use of parts of the system that are not connected to the whole.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

The XXTEA site linked has example code, which isn't very complicated, so that might help.

This is a huge field of study, so there are all kinds of approaches depending on the desired complexity and level of security. Some searches on "cryptographic authentication protocols" or "nonce authentication" might give you a reasonable survey of what's out there.

Like Clay mentioned, you can use some pretty powerful stuff without too massive of a development effort. There is open source code for some of the more common powerful methods. It's often just a complexity tradeoff.

Eric Jacobsen Anchor Hill Communications

Hi Tim,

If the two modules are allowed to have a shared "secret", then the easiest method is to use this secret with a cryptographic hash.

Module A sends a random message to Module B.

Module B calculates the cryptographic hash of the random message with the secret prepended or appended (or both).

Module B sends the hash to Module A.

Module A verifies that the hash is what it would have calculated, knowing the secret. If it is, Module B has the secret, so Module B is authentic.

As other posters pointed out, source code for SHA-1 is all over the Internet.

As far as security, I use a very scientific notion of security ...

There are perhaps 10^80 atoms in the observable universe.

80 * ln(10)/ln(2) = 266, therefore 266 bits is enough for the hash size.

DTA

IEC 62351

Unfortunately, IEC standards are not free.

--
Saludos.
Ignacio G.T.

One-time authentication is A Bad Thing. If you *expect* to encounter adversaries, then any non-moronic adversary will wait for you to authenticate (either by knowing, open-loop, when the authentication takes place *or* by sniffing the link) then, unplug the one device and plug in his *own* device -- knowing that you will now consider *it* to be authenticated.

[I did this exploit in front of a potential customer to demonstrate how easily their system "security" could be bypassed -- having never seen the system 5 minutes earlier!]

Build authentication into the ongoing protocol so *each* transaction reinforces the identity of *both* parties. (the code is no more complex than one-time auth4entication... arguably even *easier*!)