On 26 May 2000, at 9:59, M. Adam Davis wrote:

> I've been thinking about code security lately, and it seems like the
> only way to provide secure code on the 16F8xx chips while allowing
> secure software (flash) upgrades is if Microchip changed the code
> protect mechanism.
>
> Right now code protect is a one or all type of thing, if you code
> protect the chip or portions of it then the chip cannot be read or
> programmed externally or programmed internally without a bulk erase.
> Ideally the code protect would be split into two configurations: Code
> protection for all or parts of the chip from external reads/writes and
> code protection for all or parts of the chip from internal writes.
>
> Under this scheme one could develop a secure flash loader on chip
> which would only write to program memory after authorization (passkey
> or other) and then accept an encrypted file containing the flash
> update.  It would, using its internal private key, decrypt the file
> and program the flash.  This would be accomplished under the external
> code protection, without internal code protection.  It still allows
> others to get you code if they know your passkey (which could be
> encrypted with a know pseudorandom number before sending) and your
> private encrypting keys (ease of discovery depends on encryption
> system used), which makes it about as difficult as breaking the
> physical code protection.
>
> Only an encrypted file needs to be distributed to the customer.
>
> Unfortunately, this is not possible with the current chip.  Even using
> a seperate chip to program the flash while decrypting the file leaves
> data lines open to be probed with the unencrypted code available.
>
> Are there any other solutions to this issue?  The only other way to
> deliver upgrades is to physically deliver a chip to the customer.
>
> I appreciate your thoughts on this issue.
>
> -Adam
>

Sure...this is my thoughts on it. Code protection can never make
everyone happy. Microchip has a real simple scheme that works,
but doesnt do what you need. The only way to implement a code
protect scheme to make everyone happy is to leave it general.  Set
it up where you can protect or unprotect each memory cell
individually to include program and data memory as well as
configuration word and eeprom memory. But, in the interests of
simplicity, also have a single bit to disable code protect and allow
one to use the chip without generating a map of what is protected
or not.  This sort of scheme could definitely be accomplished, but
of course the price of the chip would have to go up.

OTOH, if the code is that precious, why not just supply an upgrade
chip and not worry about it?