Cryptography: serial-link validation

I'm not even sure of the correct term to use.

I want to build some security into a product that uses a pair of 
controllers communicating by RS-232.  I'd like the "slave" controller to 
require the "master" controller to perform some sort of validation before 
the slave will respond with any but the most basic of keep-alive messages.

This whole thing doesn't need to be perfect: it just needs to discourage 
all but the serious hackers from breaking into the link.

I'm pretty sure that the best way to do this is to have the slave send a 
challenge to the master, and only open up if it gets the correct response.

What's the right place to go to find a good method, or do you have any 
suggestions?

-- 
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

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

Tim Wescott wrote:

> I'm not even sure of the correct term to use.
> 
> I want to build some security into a product that uses a pair of
> controllers communicating by RS-232.  I'd like the "slave" controller to
> require the "master" controller to perform some sort of validation before
> the slave will respond with any but the most basic of keep-alive messages.
> 
> This whole thing doesn't need to be perfect: it just needs to discourage
> all but the serious hackers from breaking into the link.
> 
> I'm pretty sure that the best way to do this is to have the slave send a
> challenge to the master, and only open up if it gets the correct response.
> 
> What's the right place to go to find a good method, or do you have any
> suggestions?

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.

On 09/03/2012 01:14, Tim Wescott wrote:
> I'm not even sure of the correct term to use.
>
> I want to build some security into a product that uses a pair of
> controllers communicating by RS-232.  I'd like the "slave" controller to
> require the "master" controller to perform some sort of validation before
> the slave will respond with any but the most basic of keep-alive messages.
>
> This whole thing doesn't need to be perfect: it just needs to discourage
> all but the serious hackers from breaking into the link.
>
> I'm pretty sure that the best way to do this is to have the slave send a
> challenge to the master, and only open up if it gets the correct response.
>
> What's the right place to go to find a good method, or do you have any
> suggestions?
>

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).

On 03/09/2012 10:04 AM, David Brown wrote:

> 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).

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 
http://en.wikipedia.org/wiki/XXTEA It's very easy to implement, while 
providing a good level of security.

On 09/03/2012 10:50, Arlet Ottens wrote:
> On 03/09/2012 10:04 AM, David Brown wrote:
>
>> 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).
>
> 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..
>

As far as I understood the OP, it's the casual hacker we are dealing 
with here.  You are right of course that CRC is cryptographically weak, 
but it is much simpler and faster to implement and execute than 
cryptographically strong (or "stronger") encryption functions.  If it is 
good enough for the application, then it is good enough.  XXTEA, or 
cryptographic checksums like SHA are obviously much stronger, but are a 
worse solution if they are not needed.

> I'd recommend using XXTEA instead. See
> http://en.wikipedia.org/wiki/XXTEA It's very easy to implement, while
> providing a good level of security.

On Thursday, March 8, 2012 7:14:00 PM UTC-5, Tim Wescott wrote:
> I'm not even sure of the correct term to use.
>=20
> I want to build some security into a product that uses a pair of=20
> controllers communicating by RS-232.  I'd like the "slave" controller to=
=20
> require the "master" controller to perform some sort of validation before=
=20
> the slave will respond with any but the most basic of keep-alive messages=
.
>=20
> This whole thing doesn't need to be perfect: it just needs to discourage=
=20
> all but the serious hackers from breaking into the link.
>=20
> I'm pretty sure that the best way to do this is to have the slave send a=
=20
> challenge to the master, and only open up if it gets the correct response=
.
>=20
> What's the right place to go to find a good method, or do you have any=20
> suggestions?
>=20
> --=20
> 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?
>=20
> Tim Wescott, Communications, Control, Circuits & Software
> http://www.wescottdesign.com

Hello Tim,

I've actually done this with a serial dongle I designed. I implemented RSA =
in a pic. You can verify the dongle is there by sending over some random nu=
mbers encrypted with your half of the key and the dongle decodes with his h=
alf of the key and sends it back to you to verify against the original rand=
om numbers you picked. Likewise the dongle verifies you by a similar action=
 where it picks random numbers and sends them to you encrypted and you have=
 to decrypt them and send them back.=20
The number crunching takes a few seconds, but it is quite secure if you pic=
k large keys.

Clay

On Fri, 09 Mar 2012 10:50:51 +0100, Arlet Ottens wrote:

> On 03/09/2012 10:04 AM, David Brown wrote:
> 
>> 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).
> 
> 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
> http://en.wikipedia.org/wiki/XXTEA 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

Tim Wescott schrieb:
> On Fri, 09 Mar 2012 10:50:51 +0100, Arlet Ottens wrote:
>> On 03/09/2012 10:04 AM, David Brown wrote:
>> 
>>> 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).
>> 
>> 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
>> http://en.wikipedia.org/wiki/XXTEA 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.

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

On 09.03.2012 01:14, Tim Wescott wrote:

> I want to build some security into a product that uses a pair of
> controllers communicating by RS-232.  I'd like the "slave" controller to
> require the "master" controller to perform some sort of validation before
> the slave will respond with any but the most basic of keep-alive messages.

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)