Re: One-sided authentication for small micros?

From: Matthue Gera (
Date: 10/18/03

Date: Sat, 18 Oct 2003 04:43:33 GMT

Some thoughts on your problem.

What about if you have a unique id in each slave.

The master has a lookup table of all 'known' slave id's.

The master sends out a broadcast every x second asking the slaves to indentify
themselves. Or maybe just at startup time of the master.
This would reset all the slave keys to their lookup values.

Only slaves replying with valid id's (within the master table) are considered
valid. id's are seen and keys are not.

Now you have a situation where anything else on the network can read those response
but they do not know which are considered 'valid' by the master as the master does
not respond to say 'you are ok' etc.

The only problem here is that if a hack slave tried to use any of those id's are
keys to communicate with the master illegally.

You could solve this by having a master lookup table of id's which are used
for broadcasting authentication purposes only. (sent to the master upon the master
broadcasting a request to the slaves for identifcation.

When the master find a valid slave id responding back, it uses a second id as the
encryption key when communicating with that slave.

The slave also has a second id which is used for the key whenever the master
decides that it is a valid slave and starts to communicate with the slave.

To make it more secure you could mix another key with the second key stored in the
masters second lookup table and the slaves second lookup table used for the key.

Whenever the master and slave successfully finish a valid packet request/packet
response the master and slave use another key generator and change the key with
every packet sent and acknowledged.

The security here is based on hackers not being able to find out the lookup id's
and keys of either of the master/slaves. So I assume only the cable which the
communications is used is insecure and the slaves and masters cannot be physically
got at. This solves your lookup insecurity problem. And as long as nobody
gives out those lookup tables, any other types of illegal slaves will be ignored
and they will not be able to look at any data being passed between slaves and masters
because they do not have to keys used for the packet encryption.
And also they do not know how the keys will be generated for future packets.

You could also add a global variable to this key re-generation to further
formulate future keys for master/slave communications but this opens up another
insecurity if the global variable is derived from outside of the security of the
masters and slaves themselves.

The above method should work for you if you do not require encryption that is
too complex, it sounds like you want something which is easy and would take allot
more than normal effort to try to hack/crack.

Passing startup keys between masters and slaves is a bad idea as any other illegal
slave can listen to them being sent and decide to use one if it can decide the
identity of the slave it wants to kidnap.

A id/key lookup method would ultimately be okay for this.

Ultimately just make sure the lookup tables (keys not ids) themselves are not
transmitted to one another in their raw state otherwise as said before they
could be hyjacked by a alien and nasty slave.

In article <nS3jb.563920$cF.241358@rwcrnsc53>, says...
>I have two small (8 or 16 bit) microprocessors--a master and a slave. The
>two communication via a CAN datalink. Different slave modules can be
>swapped in to talk to the master, and I'd like for the master to be able to
>verify that the slave is an 'approved' device. I do have complete control
>over the code in both chips, and I would consider both the source and the
>flashed programming to be fairly secure. The application would be
>considered relatively low risk (as in a breach would cause a minor loss of
>revenue, nothing more), and the frequency of authentication would be very
>low as well (every few minutes would be sufficient).
>This strikes me as pretty simple, even for my meager skills in this area,
>but I wanted to run it by the group. My first stab at an algorithm would
>1. Install the same secure key in the master and any slaves.
>2. Master requests authentication.
>3. Slave creates a random number or string, appends the stored key to it.
>4. Slave sends Master the random string.
>5. Slave computes a hash of [RANDOM+KEY] using a respectable, small,
>lightweight hash suitable for small micros
>6. Slave sends Master the hash value.
>7. Master executes steps 3. and 5., and if the hash values match then the
>Slave is authenticated.
>I'm always surprised at how even very simple algorithms can be
>mischieviously twisted to reveal a weakness, so I'd like some comment from
>group. I'd be the first one to pick up an off-the-shelf solution, but the
>constraints on my chips are very tight, and the second I start monkeying
>with proven code in order to get it to work on my systems, I figure all bets
>are off.