Secure PIC programming

Hi

We have customers using PICs who sometimes need to re-program them with 
updated firmware.  It's inconvenient to have to ship the equipment back 
to a service centre, and most customers are quite capable of doing it 
themselves.

The problem is that the PIC hex or bin file is easily disassembled, and 
this may give away some proprietary secrets.  If we could supply our 
customers with a USB programmer and PC software which would allow them 
to program a PIC from encrypted files we'd be a lot happier. Obviously, 
a determined person could capture the ICSP data as it's loaded to the 
PIC, but we think the risk is small and is one we'd be prepared to take.

Does anyone make a USB PIC ICSP programmer capable of using encrypted 
files?

Thanks
-- 
Keith Wootten

Keith Wootten wrote:

> We have customers using PICs who sometimes need to re-program them with
> updated firmware.  It's inconvenient to have to ship the equipment back
> to a service centre, and most customers are quite capable of doing it
> themselves.

I have the same issue with one of my clients.  If the customer can
program the PIC, they can replace one.   So, we ship them an updated
PIC and let them put it in the equipment themselves.

Luhan

In message <1143846947.112275.114180@i39g2000cwa.googlegroups.com>, 
Luhan <luhanis@yahoo.com> writes
>Keith Wootten wrote:
>
>> We have customers using PICs who sometimes need to re-program them with
>> updated firmware.  It's inconvenient to have to ship the equipment back
>> to a service centre, and most customers are quite capable of doing it
>> themselves.
>
>I have the same issue with one of my clients.  If the customer can
>program the PIC, they can replace one.   So, we ship them an updated
>PIC and let them put it in the equipment themselves.
>
>Luhan
>
Thanks Luhan,

I'd rather not - it can take a long time for a chip to get to a far 
flung place, and we don't really want customers soldering surface mount 
chips on site, at least not often.  Sockets are out for environmental 
reasons.

Cheers
-- 
Keith Wootten

Keith Wootten wrote:

> I'd rather not - it can take a long time for a chip to get to a far
> flung place, and we don't really want customers soldering surface mount
> chips on site, at least not often.  Sockets are out for environmental
> reasons.

Ok, then how about a 'bootloader' program in a memory protected PIC?
Some PICs can write to their own program space.   Put a decryption
algorythm in the bootloader and send it serial data from a PC com port.
 You ship your customer the encrypted program.

Luhan

Spehro Pefhany wrote:

>
> I guess you don't use a lot of QFN or TQFP-100 parts..

You betcha, I like all my DIP chips in sockets!  Also, all the circuit
boards are hot-swapable from the front of the machine!  There are no
pots, switches, or jumpers and only ordinary common parts are used.
The units (reflow solder machines) work well in Malasia, China, and
places I dont even know about.

Luhan

On 31 Mar 2006 15:15:47 -0800, the renowned "Luhan"
<luhanis@yahoo.com> wrote:

>Keith Wootten wrote:
>
>> We have customers using PICs who sometimes need to re-program them with
>> updated firmware.  It's inconvenient to have to ship the equipment back
>> to a service centre, and most customers are quite capable of doing it
>> themselves.
>
>I have the same issue with one of my clients.  If the customer can
>program the PIC, they can replace one.   So, we ship them an updated
>PIC and let them put it in the equipment themselves.
>
>Luhan

I guess you don't use a lot of QFN or TQFP-100 parts.. 


Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Keith Wootten wrote:
> Hi
>
> We have customers using PICs who sometimes need to re-program them
> with updated firmware.  It's inconvenient to have to ship the
> equipment back to a service centre, and most customers are quite
> capable of doing it themselves.
>
> The problem is that the PIC hex or bin file is easily disassembled,
> and this may give away some proprietary secrets.  If we could supply
> our customers with a USB programmer and PC software which would allow
> them to program a PIC from encrypted files we'd be a lot happier.
> Obviously, a determined person could capture the ICSP data as it's
> loaded to the PIC, but we think the risk is small and is one we'd be
> prepared to take.
>
> Does anyone make a USB PIC ICSP programmer capable of using encrypted
files?

You can get an AES bootloader for the AVR :-)
Download the encrypted application and let the CPU
decrypt and program, based on the key hidden in internal BootROM.

>
> Thanks

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

Luhan wrote:
> Keith Wootten wrote:
>
> > I'd rather not - it can take a long time for a chip to get to a far
> > flung place, and we don't really want customers soldering surface mount
> > chips on site, at least not often.  Sockets are out for environmental
> > reasons.
>
> Ok, then how about a 'bootloader' program in a memory protected PIC?
> Some PICs can write to their own program space.   Put a decryption
> algorythm in the bootloader and send it serial data from a PC com port.
>  You ship your customer the encrypted program.

This is a good idea since even snooping the serial port while
downloading will not give away the raw program code. Blowfish is quite
simple to implement and is easily embeddable. You can get PIC
implementation of DES and SKIPJACK at:

  http://www.brouhaha.com/%7Eeric/crypto/

Personally I think something like DES is overkill for a bootloader. A
common "good enough", weak encryption method is to simply XOR the
plaintext with the secret key. Something like:

  #define KEY_LEN 22
  static char secret[] = "THiS is tHE sECrEt KeY";

  void encrypt_decrypt (char *data,int len)
  {
    for (i=len; i>0; i--)
    {
      data[i] = data[i] ^ secret[i%KEY_LEN];
    }
  }

takes very,very little program memory and can be easily included in a
bootloader.

In message <1143848642.072446.248740@i40g2000cwc.googlegroups.com>, 
Luhan <luhanis@yahoo.com> writes
>Keith Wootten wrote:
>
>> I'd rather not - it can take a long time for a chip to get to a far
>> flung place, and we don't really want customers soldering surface mount
>> chips on site, at least not often.  Sockets are out for environmental
>> reasons.
>
>Ok, then how about a 'bootloader' program in a memory protected PIC?
>Some PICs can write to their own program space.   Put a decryption
>algorythm in the bootloader and send it serial data from a PC com port.
> You ship your customer the encrypted program.
>
>Luhan
>
Another good idea, but this is pre-existing kit, none of it uses 
self-programming PICs.  It tends to be mostly old 16F84 chips and 
similar.

Cheers
-- 
Keith Wootten

> Personally I think something like DES is overkill for a bootloader. A
> common "good enough", weak encryption method is to simply XOR the
> plaintext with the secret key. Something like:
>
>   #define KEY_LEN 22
>   static char secret[] = "THiS is tHE sECrEt KeY";
>
>   void encrypt_decrypt (char *data,int len)
>   {
>     for (i=len; i>0; i--)
>     {
>       data[i] = data[i] ^ secret[i%KEY_LEN    ];
>     }
>   }
>
> takes very,very little program memory and can be easily included in a
> bootloader.


If you really want to break in, it is not so secure.

If it is compiled code, you can
* Make sure you get
* search for combinations normally generated by a compiler

The larger the program is, the higher is the risk that you get a repeated
string

Assume you have the following code in several places:
        pop    r<n>
        pop    r<n>
        ret

and several happen to be located aligned with the "secret"  key.
Then they happen to be at location 44 and 176.
After factoring    44  = 2 * 2 * 11
                           176 = 2 * 2 * 2 * 11
you can probably soon find out the length of the key.
Then you know that the start of the code is (often) the exception vectors.
Search for valid keys generating subroutine call instructions.

Methods like this compbined with cheap CPU power limits the number of keys
very quickly.

Your suggestion is only safe if noone tries or if the value of the code is
small
enough that it costs more to develop the code than to crack it.

You would not, with any success, protect a settop box with your suggestion.
DES/AES cost very little code in the bootloader compared to its value.

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB