Re: Security for embedded device
From: Joris Dobbelsteen (none.of_at_your.business)
Date: 06/29/04
- Next message: Scientific Books: "Scientific books: cheap sell-out of the library"
- Previous message: Bryan Olson: "Re: Manual hashing"
- In reply to: Joris Dobbelsteen: "Re: Security for embedded device"
- Next in thread: Francois Grieu: "Re: Security for embedded device"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 29 Jun 2004 23:04:17 +0200
"Joris Dobbelsteen" <none.of@your.business> wrote in message
news:40e144ec$0$829$a344fe98@news.wanadoo.nl...
> I will put up post with goals and proposal here.
I'll do this now.
The device is a sensor to measure the time between an object passing the
sensor. It could also be an analog device that uses the sound card, but its
precision is much lower.
The complete kit consists of software on the PC and the sensor.
(a) Since the kit is aimed at hobbyists, it should not be feasable for them
to design their own sensor.
(b) They should use only my software and sensor. It must not be feasable to
develop your own software.
(c) The sensor should be usuable on a single (or couple) systems. With 3
systems they should preferably buy the sensor three times, but there must be
room to upgrade or change your system.
This is what I'm trying to archieve...
===
Why use a microcontroller (MCU)?
They are cheap and can provide really high accuracy. Next they are easy to
secure, when you do it correctly.
===
Method 1
The microcontrol has a protected interface. You must first unlock the
interface, before you can use it.
A simple method is just sending a plain 'activation key' to the sensor,
which accept or rejects it.
The disadvantage is that a sensor can be designed that accepts any key.
Next software can be used instead of mine, however they have to buy the
sensor. This isn't too bad actually.
===
Method 2
I need some method of replay prevention. A simple way is the sensor to send
a challenge (randomly generated). The challenge must be used with the
'activation key', thus making a MAC.
Again a sensor can be made to accept any activation key.
===
Method 3
Method 2 + Add encryption to the measurement data being send from the sensor
to the PC. The key would obviously be dependent on the data used for the
device activation.
To prevent problems when data is lost, add a sequence number to the data.
This sequence number can also be used for the encryption, so the key varies
each time measurement data is sent.
This would provide real good protection against attempts to interfere with
the device.
The sensor accepting any key would not be unable to deliver the proper data
to the computer.
===
Implementation
The sensor has its ROM protected. The downside is that I cannot use the
Flash ROM, but this is needed to prevent anyone from simply reading it.
The device stores a serial number which is always readable and uniquely
identifies the device.
It also contains a 'security code' which cannot be read and is known by
myself only or a user who has paid for the sensor. The 'security code'
consists of an 'activation number' and 'encryption number'.
Of cause every device (identified with a serial) has a random activation and
random encryption number.
The device sends out a challenge and the PC must activate the device with
the activation code. Here a MAC is needed and I don't know exactly how to
make this work.
A sample consists of a 'sequence number' S and the 'measurement data' D.
The frame F = S & E(D, k+S).
For now E(p, k) is the TEA encryption algorithm, with 16-rounds. This is
sufficient, can be done in close to 1K cycles and takes little RAM. Only the
encryption routine is needed, since P = E( D(P, k), k) = D( E(P, k), k).
D would be about 32-bit number send out typical 3 times a second, so its
very little data.
Since TEA uses a 64-bit block, adding 32-bits of salt can improve
protection.
Hopefully someone can suggest on the MAC (where I was planning to use TEA
for size) ?
Since it is one-time it might have a much larger complexity.
- Joris
- Next message: Scientific Books: "Scientific books: cheap sell-out of the library"
- Previous message: Bryan Olson: "Re: Manual hashing"
- In reply to: Joris Dobbelsteen: "Re: Security for embedded device"
- Next in thread: Francois Grieu: "Re: Security for embedded device"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
