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

On Thu, 08 Mar 2012 18:14:00 -0600 in comp.arch.embedded, Tim Wescott
<tim@seemywebsite.com> 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?

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: <VAL a b c x>
master: <RES (a*x)^2 + (b*x)^4 + (c*x)^8>

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

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.

In article <9rt2eoFb9hU1@mid.individual.net>, m.km@gmx.de says...
> 
> 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

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
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

On Thu, 08 Mar 2012 17:00:30 -0800, Joseph Power wrote:

> On Thu, 08 Mar 2012 18:14:00 -0600 in comp.arch.embedded, Tim Wescott
> <tim@seemywebsite.com> 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?
> 
> 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: <VAL a b c x>
> master: <RES (a*x)^2 + (b*x)^4 + (c*x)^8>
> 
> 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.

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

On Thu, 08 Mar 2012 18:14:00 -0600, 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.
> 
> 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?

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.

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.