Re: Security for embedded device

From: Guy Macon (http://www.guymacon.com)
Date: 06/29/04 

Date: Tue, 29 Jun 2004 10:05:05 -0700

Joris Dobbelsteen <none.of@your.business> says...
>
>"Guy Macon" <http://www.guymacon.com> wrote...
>>
>>What is your threat model?
>
>Very low, protecting usage of the device by others. Its not intended for
>protecting sensitive data, but merely preventing others to use their own
>equipment with this device.
>Most part of the protection will obviously be obscurity (wow he!)
>
>> Is insuring that both ends have the same key a problem in your
>application?
>
>No, I don't see the advantage of both having a different key (async cipher).
>You would need one to communicate with the device, so this one is used on
>the computer. I does not matter having the same in the device itself, as its
>not readable because of the protection mechanisms in the chip itself...

I understand. Given your tight budget of cycles and RAM and your loose
security requirements, I don't think that any of the strong ciphers will
fit your requirements, and you want to avoid all simple and well-known
RNGs because that's the first thing a reverse engineer would look for.

Unless you want the chip to start using the same encryption sequence
after every power-up, you will need some sort of random data. This
can often be had through a free-running timer and an external event
with unpredictable timing, or from an ADC input. Then you have to
figure out how to get the other end to have the same random data,
and you would like to not make it to easy for your attacker know
what it is. More on that below.

Hmmm...

How about a 4-bit RC4? With your key in ROM and your random data
used to fill the state array with initial data you would need 16
nybbles (8 bytes) of RAM plus a few registers for counters. Set
up a loop that encrypts a nybble every 13th ( or 7th or any other
prime number) time through the cipher and it will be quite difficult
for a reverse engineer to figure out what you are doing inside the
chip, and it should run fast enough for you.
    
This gives you a way to move that random data. Fill the state array
from fixed ROM precomputed random data, generate your random data,
encrypt it, send it, and then have both ends decrypt it and reload
the array with the random data as a starting point for the real
ciphering work.

If 8 bytes of RAM is too much, a 3-bit RC4 uses 8 3-bit values,
which is only 3 bytes of RAM. Of course it will take three times
through the cypher to encrypt a byte instead of two, and it will
be a lot easier to reverse engineer.
   

-- 
Guy Macon, Electronics Engineer & Project Manager for hire. 
Remember Doc Brown from the _Back to the Future_ movies? Do you 
have an "impossible" engineering project that only someone like 
Doc Brown can solve?  My resume is at http://www.guymacon.com/