First step into Secure Embedded system

Implementing a non-volatile counter as you described appears straight-forward. You haven't mentioned the essence of your problem. I could make guesses, but it would be easier if you tell us.

--
Thad

Hi, Thanks for your reply. Basically what I want to do is :

- I have a Main program running on a PIC18(can be any MC)

- Apart from that I have another PIC16(can be any MC) with some amount of non-volatile memory.

- a variable "Counter" is stored on the non-volatile memory ie PIC16 side

Now when the Main program starts up(on PIC18) ,during program bootup,it must read the "Counter" value present on non-volatile memory (This part I can manage with some I2c or Uart).

Now depending on the "Counter" value read , the program must either continue or halt. Also a copy of "Counter" must be stored in PIC18(the main MC)

Now my question is on:How to implement this mechanism efficiently and what kind of encryption i should use at PIC16 and PIC18 side. Hope this is clear.

Regards Aj

Why can't you keep the counter on the main MCU ?

not really. Where, why and to do waht do you want to use encryption/decryption?

Bye Jack

So what are you Securing against?

Secure Embedded can mean many different things from design security to secure against all types of direct and indirect snooping or attack.

So you have a link that could be monitored, cracked or simulated.

Inside the PIC or on yet another component?

Depends on so many factors as you still have given no idea what you are securing against.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

In message , ajaybgr writes

Not at all.... why do you need encryption between the two MCU's?

The level of the threat determines the level of encryption required.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

----->>

Well Thanks for all the above replies. My use of "secure" embedded term is wrong in this context, I guess. Our actual requirement is like controlling/licensing our Devices which are already on the field. For example lets say,one of our device is running at our customer side. The customer has complete control over that device and uses it more times than he has paid us.(Note that Customer hasn't paid us completely for full usage)

Now I want to change this model into something like:

-A new small device with EEPROM(any pic12/16 will do) is created which contains our License, how long can customer use our product and other proprietary details. I don't want to store these details on our main device due to some other reasons.(more like marketing and distribution reasons)

-This new device can be connected to our existing device through uart/ usb etc. (You may say this link can be spoofed-But actually I have taken care of such things and lets assume the link is not traceable nor can be cracked)

-When customer pays us full money - we program the smaller device for unlimited usage.

((Well this all sounds more like shareware/trial software,right?! But the problem is our devices are already on the field and hardware cannot be changed drastically-so whatever I can do is through an extra small device and firmware only))

Hope this is clear. So the question arises as below:

1)whats the best way to implement this model on PIC18 like devices 2)Is there anything wrong with my approach - Assume, We are NOT targetting for complete foolproof solution but just to make cracking our device more difficult. 3)Is there any better way to achieve what I am trying to do?

Any other thoughts and references/pointers are appreciated.

Regards Aj

I don't know what you mean by traceable. I assume by your statement that you are encrypting traffic and have a link protocol preventing playback attack, which is probably your main concern. With such a protocol you should be able to send a command to the license processor to read the counter and receive a response with the counter value, all protected by your protocol. Now, since you have a secure communication link, what's the problem?

--
Thad

t

Yeah the communication between main device and License_key device is OK. Note:License_key device =3D> extra small device to be attached to my existing main device containing some proprietary data.

Now my concern is what kind of protection I must ensure so that the data in the EEPROM of License_key device is secure. I don't have much experience with these kind of devices so forgive, if my questions are trivial.

For example if some one gets hold of my License_key device ,what can I implement to make cracking/modifying the License data more difficult? At the same time it should be easy for ME to modify that data in future.

Any good implementation where authentication of License_key device is done by the main device before reading the license key? What I mean is that , License_key of one customer should not be used by another customer.(currently am reading/testing XTEA by Microchip to see whether it fits my need..so if you have any tips on similar lines are welcome)

Also I may have to store my License data on my main device sometimes. So is there a way to protect this data from being cracked(just more difficult) either at the Main device or License_key device?

Thanks Aj

unt

6 h /

on

Hi Aj,

do you mean that you plan to add a kind of dongle in your device in order to fully enable your device functionality?

Regards, Ivan

mount

C16

ich

er

rt/

t r l

tion

Yes..(Kind of) . The dongle not only controls device functionality but also contains licensing details. Is my approach good? what kind of problems I could face through this approach? Are there any better way to achieve my intentions??

Regards Aj

I assume that the EEPROM is in the microprocessor. Once the processor is programmed and code and EEPROM protection set, someone cannot read or program the EEPROM without erasing the microprocessor code or invasively reading the code with acid, microprobes, etc., which is beyond the ability of simple potential cheaters. Unless you are protecting a very high value or are a lure to hackers, this level of attack is not a significant threat.

You can always reprogram the dongle or you can establish a secure connection between the dongle and your dongle programmer (using mutual authentication based on a shared secret key), then change your license details.

This simplest thing is have the dongle send the serial number of the unit being authorized, using your secure link, which the controller verifies before being operation. You might establish a unique secret key for each dongle/controller pair. This would prevent a hacker from invasively reading out your dongle or controller code and keys and applying that to a different controller, since the other controller would be using a different key.

--
Thad

Well thanks Thad,for clarifying this.

This sums up most of my doubts.. Thanks a lot Thad and everybody else ..

Regards Ajay