Encrypted bootloader clarification

[wirelessage]

I have read some forums about encrypted bootloader. I see some of the suggestions..

The one basic question I have is that the "ccsload" program offered by CCS has a "read from chip" option which reads the hex file as written on to the PIC.

Anyone can download ccsload and click on 'read from chip' and the entire program is available.

how do we get around that?


Thanks!

[dbotkin]

[Ttelmah]

This is all down to how you write your bootloader.

The chip normally has settings to enable an external programmer to R/W the memory.
These obviously need to be off.
Then there is an option to allow 'code' (i.e. the bootloader), to R/W. If the chip is to be verified, then the bootloader must be able to read the code.
Then there is an option to fully protect the bottom area of the ROM, where the bootloader resides.

Now, if your bootloader accepts commands to 'read' the chip, over it's connection (whatever this may be), then (obviously) the chip can be read. However write the bootloader, so it can only accept commands to 'write', or 'verify', and the chip can't then be read via the bootloader. Now you could then get round the protection, and read the chip, by overwriting just the bootloader, with one that did allow reading. This is where the option to fully protect the bootloader itself comes in.
Then you could even be more complex than this. You could (for instance), write the code to allow a small part of the top of ROM to be read, but nowhere else. If this is used to hold configuration data, it allows this to be read and saved, without letting your code be accessed.

Several layers:
1) The chip's protection needs to be set so only code running in the chip can access the ROM - prevents using a programmer to read the chip.
2) The area containing the bootloader itself needs to be fully protected.
3) The bootloader needs to implement both the decryption, and the tests to verify that it is being talked to by a 'legitimate' source.
4) If the bootloader implements 'read back', then this must only be for areas that you want to allow to be read.

The CCS example code, and CCSload, are just that. Examples, and useful tools. You would not use CCSLoad to talk to an encrypted loader, and it is completely down to the design of the loader so that it would not respond to a 'read' command from this source.

Best Wishes

[wirelessage]

Thanks for the inputs.

I took a little time to understand and figure what Tlehmah was saying. I think I have gotten many of it.

Environment:
ccs compiler: v4.141
ccsload: v4.047

So, here is what I got done so far:

- I was able to keep the same fuses on both the bootloader and application so that we do not allow table reads AND Enable code protection. By doing so, I tested to ensure that CCSLOAD can read the hex file, but shows up as a bunch of zeros.

- Also, what I observed is that the fuses in the bootloader and the application have to match, else the application won't load up in my case. I think that is good because the bootloader fuses dictate the application fuses. I am not sure on this, but this is my observation so far.

- Obviously, the next step is to add encryption in the client app, to encrypt and send data to the bootloader which could decrypt and write to program memory.

Anything else I am missing from an encrypted bootloader standpoint?