On Fri, Jul 27, 2001 at 02:07:39PM +0300, Peter L. Peres wrote:
> I think that there is a small misunderstanding here. The people who are
> complaining about the program areas left open to read by partial
> protection are those who sell or make field upgradeable firmware. This
> implies that they have to allow the client (who has ICSP) to write and add
> his own code to the free parts of the chip. This is where the current
> security scheme fails.

This isn't exactly what Ron is talking about, beause the proposal on the
table isn't using ICSP for update. We all know that's a well known standard
that essentially requires the data to be passed to the chip in cleartext.
Also once protection is turned on, even partially, ICSP writes are disabled
for the whole chip. It's the reads that are the problem.

Ron wants an encrypted channel to the chip. The can be done with a bootloader.
However internal writes unfortunately have only the same priveledge as
external reads. This means that any location that can be written internally
can also be read externally.

There are a couple of different solutions. Ron is calling for a blind internal
write where reading the location is disallowed. A dangerous proposition for
sure. My proposal was simply having a mode where everything internal is
allowed and everything external is disallowed. Then the bootloader becomes
the only way to update the chip. Then one can encrypt to their hearts
content.

It's a slight oversight. Personally I'm only examining it as an intellectual
excercise. If the code Ron wants to protect is really so important, the best
course of action is to fully protect the chip and simply send new chips
when upgrades are required. If the code is that important, the clients would
have no problem pulling the boards and upgrading.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics