ISP programming and code prrotection

Hi,

I know that many products support ROM upgrade or in system programming
(ISP). However, from my brain that logically to enable this feature the
mcu should not be locked.

So I have a question that whether the above thinking is right ro not.
Or if it is right, is it possible to make ISP possible and
simultaneously protect our firmware code from being read during
verification?

Thanks!

> So I have a question that whether the above thinking is right ro not.
> Or if it is right, is it possible to make ISP possible and
> simultaneously protect our firmware code from being read during
> verification?
>

Depends on the micro. Often, ISP is locked out once you enable the
protection bits. Sometimes the verification process works by sending
the new data to the micro twice; first time to burn, second time to
verify. Sometimes you simply can't verify after setting the protection
bits, in which case the procedure is to erase the device, program code
memory, verify code memory, then program security bits.

By definition, anyone who has the power to ISP-burn your micros has
enough information to copy them.

Most firmware is encrypted and us e a bootloader with the right key. Look at 
the avr site and search for DES application.

SFC


"eeh" <eehobbyist@yahoo.com.hk> schreef in bericht 
news:1110527595.935544.315770@o13g2000cwo.googlegroups.com...
> Hi,
>
> I know that many products support ROM upgrade or in system programming
> (ISP). However, from my brain that logically to enable this feature the
> mcu should not be locked.
>
> So I have a question that whether the above thinking is right ro not.
> Or if it is right, is it possible to make ISP possible and
> simultaneously protect our firmware code from being read during
> verification?
>
> Thanks!
> 

eeh wrote:
> Hi,
>
> I know that many products support ROM upgrade or in system
programming
> (ISP). However, from my brain that logically to enable this feature
the
> mcu should not be locked.
>
> So I have a question that whether the above thinking is right ro not.
> Or if it is right, is it possible to make ISP possible and
> simultaneously protect our firmware code from being read during
> verification?
>
> Thanks!

Well you can't verify code if you can't read it!! What happens is you
verify and then you set the code lock fuses, the code cannot be read
then. To upgrade you have first to bulk erase the chip. The code is
protected against all but the most determined attackers, some chips are
better than others, in practice there are only a few instances where
it's not easier to do your own. You need to take precautions when using
chips with a self programming ability to make sure they don't modify
themselves during powerup, brown outs, glitches, noise spikes ect.

On 10 Mar 2005 23:53:15 -0800, "eeh" <eehobbyist@yahoo.com.hk> wrote:

>Hi,
>
>I know that many products support ROM upgrade or in system programming
>(ISP). However, from my brain that logically to enable this feature the
>mcu should not be locked.
>
>So I have a question that whether the above thinking is right ro not.
>Or if it is right, is it possible to make ISP possible and
>simultaneously protect our firmware code from being read during
>verification?
>
>Thanks!

For those chips that have self-programming capability, it would be possible to program using an
encrypted comms protocol implemented in the bootloader. The bootloader would contain the decryption
key. 
Some chips have limitations on the code protection possibilities when self-programming is enabled,
but these can be worked around, e.g. by the main code making calls to routines 'hidden' in the
protected bootloader area, and the bootloader validating the main code before allowing execution. 
 
 

In article <d0ro58$6h7$1@reader08.wxs.nl>, sf-cillari@hetnet.nl says...
> Most firmware is encrypted and us e a bootloader with the right key. Look at 
> the avr site and search for DES application.

On what do you base that assertion?  It certainly runs counter to my 
(limited) experience and none of the micros's I've worked with support 
this.

The closest I've seen is a few chips that have an unlock key to enable 
reading of the OTP/EPROM on board but the firmware certainly wasn't 
encrypted.

Robert

Maybe he's thinking of this...

http://www.atmel.com/products/SecureAVR/Default.asp

--
MT 

> Depends on the micro. Often, ISP is locked out once you enable the
> protection bits. Sometimes the verification process works by sending
> the new data to the micro twice; first time to burn, second time to
> verify. Sometimes you simply can't verify after setting the protection
> bits, in which case the procedure is to erase the device, program code
> memory, verify code memory, then program security bits.
>
> By definition, anyone who has the power to ISP-burn your micros has
> enough information to copy them.
>
You can put an AVR in a state where you cannot read out and verify but you
can still erase it.
Protection AND reprogrammability.
You can also have a selfprogramming application where you send down a
3DES encrypted file which is decrupted and programmed into the flash.
There is an application note available on that subject.


-- 
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

In article <z6KdnUEOHo4VTazfRVn-pA@golden.net>, marycoy4@execyulinky.comy 
says...
> Maybe he's thinking of this...
> 
> http://www.atmel.com/products/SecureAVR/Default.asp

Beg pardon?  Context man, context.  Who's thinking of it in respect to 
what?

Robert

Hi,

Alot of the new Motorola ( freescale ) parts have code protection based
around the interrupt vector table in flash... so to unlock the CPU for
reading/writing you need to have the hex file of the previously loaded
firmware in that device. When the device programmer wants to unlock the CPU
it starts the programming cycle by sending the vector table down, if it
matches the table on the device, the device is unlocked.

Renesas CPUs allow you to set a 10 byte code when your ISP programming the
device, then the next time you want to access the device ( to read / write
flash ) you are required to send the 10byte code, much like the Motorola
method above.

Most of the ISP programmers I've seen do this for you automatically, in the
first case they ask for the previous hex file and in the second case it can
load the 10 byte unlock code manually or from a file.




"eeh" <eehobbyist@yahoo.com.hk> wrote in message
news:1110527595.935544.315770@o13g2000cwo.googlegroups.com...
> Hi,
>
> I know that many products support ROM upgrade or in system programming
> (ISP). However, from my brain that logically to enable this feature the
> mcu should not be locked.
>
> So I have a question that whether the above thinking is right ro not.
> Or if it is right, is it possible to make ISP possible and
> simultaneously protect our firmware code from being read during
> verification?
>
> Thanks!
>