The other day I was told something which I suspect is a load of ..it. It was claimed that the data protection protecting the eeprom of a PIC (say
18 series) is easily circumvented by erasing the flash memory program, and putting your own program code in to read the eeprom data and output it as some convenient serial stream.
All the microchip stuff I have seen bulk erases everything if code protect is set, but my quick read of the programming manual suggests that this might be true.
I don't know if this applies but, in some of the PIC's if you put the lock bit on and then can't get into it to change things, you can do High Voltage programming which over rides the lock bits..
Also, you can place your own boot loader in there on some, maybe all.
I believe it is true. You can protect the EEPROM, but the code can still read it out. You can also write the Flash and/or the eeprom. Which means you can load the Flash with code to read the eeprom.
But, you can ISP smaller banks of Flash on the 18F, so put the important stuff in a bank of Flash instead. Its more complicated, but it is more secure.
At first, I thought you were talking about code in the flash memory. But then a closer reading says you are talking about the tiny bit of eeprom that is present on many devices for things like application configuration settings.
formatting link
Page 8, 27.3.1, discusses some details for EEPROM protection. But as you say, it's open to interpretation.
Here's another:
formatting link
It says that a bulk erase operation is the ONLY WAY to reprogram code-protect bits. However, it uses the words like this, too, "Bulk Erase operations will also clear any code-protect settings associated with the memory block being erased." That kind of phrasing makes is sound as though one might be able to erase just the code block, clearing its code protect setting only and leaving the eeprom code-protect bit set. But then they also provide a COMPLETE list of those commands and the list does NOT include a flash-memory-only bulk erase. Instead there are these:
At first glance, it looks like the only way to download code into the flash is to first use 0x3F8F, which will erase the entire chip and, supposedly, the eeprom too. So it looks like what they allow is to program up the code and lock it (which elsewhere in that earlier PDF I mention it says will _also_ program the eeprom code-protect bit, like it or not) and that you can at a later time program up the eeprom only by doing a second erase on it.
On second glance, I see the "Erase Boot Block" command, though. So then I'm back to wondering, again.
So I googled and found a discussion where someone has a device in the field, a customer complaining, a returned unit for examination, and no way they can find to read out the eeprom. They want to, because it will help them figure out what went wrong. But they've tried everything and it always insists on zapping the eeprom. Which is suggestive only, that at least the provided software and tools refuse to do a work-around. But that doesn't mean there isn't one. Perhaps erasing the boot block and downloading code into it would work as you suggest might be possible. But given the above, I don't think you could download code straight into the flash memory. It looks as though you'd have to erase the entire chip to override the code protection there. But just maybe the boot block method?
Hard to be sure. I'd probably call up Microchip or else do a "ticket" and ask them for clarification.
I don't think the EEPROM of a PIC (or many other microcontrollers, for that matter) is protected in order to prevent the data from being _read_, rather it's protected to keep the data from being _written_ inadvertently. Code protection is _code_ protection (typically write, read and maybe table read from another memory protection block), and the EEPROM is _data_ (quite separate in a PIC with its Harvard architecture). There is typically no _data_ read protection.
The ICD2, for example, allows EEPROM to be preserved or not on programming code memory.
If you're concerned about a user being able to read EEPROM data, and the data changes infrequently*-- say some kind of key-- some PICs can write to their own flash. Some of the newer PICs don't have any EEPROM on board at all and you have to do that (or use an external EEPROM). An alternative would be to use a micro designed for secure (for example, smart card) applications.
the write endurance of code flash is pretty limited, however some micros now have limited amounts of (relatively) high-endurance flash.
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
That's exactly the problem. It was intended to allow the user to store there own user key there. It looks like I'll have to make a query to Microchip and depending on that those keys may have to be hard coded into flash or some of the flash used to emulate eeprom. Neither option is wonderful.
On a sunny day (Mon, 15 Aug 2011 16:31:52 +1000) it happened David Eather wrote in :
No, so what? just encrypt those keys before you store those in EEPROM. Use you own algo, as it is in FLASH nobody knows. If that is too complicated or takes too much space, then just xor the keys with some code byte before storage, and on retrieval.
"Use your own algorithm for cryptographic protection" has a rather problematic history. Lots of instances of "Oops, my own secret algorithm was a lot weaker than I had thought."
Much better to use a well-studied-and-tested algorithm, and keep the key secret (e.g. part of the protected, non-readable code space in flash).
--
Dave Platt AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
On a sunny day (Mon, 15 Aug 2011 10:38:30 -0700) it happened snipped-for-privacy@radagast.org (Dave Platt) wrote in :
Your 'own' does not mean self invented, just proprietary, like all the big TV sat providers do.
But I was trying to make some humor here (100 Euro), as the whole thing is flawed. Think about it, this is a classical problem, and I think only Sphero gave the right answer: Use special protected PICs.
Every 'card' I know about has been listed, keys or no keys. And even if you encrypt the keys, if all the FLASH code in the controllers you sell is the same, then you are exactly at the same point: every FLASH will decrypt the keys, so all you need is then to copy the keys to the other EEPROM. The unbreakable system does not exist, but you could make every FLASH different by adding a serial number, doing a hash over the total, and xoring the keys with that for example. But all different FLASH makes programming more cumbersome, but can be scripted quite easily, you need a database for the serial numbers as now you will have to generate different keys for each user. I have done that with DVDs, each a different number, so I could trace back copiers. Somebody asked me about it, I told him each had an unique ID, and no more copy problems since :-) Sky is the limit and an adversary with high tech knowledge and facilities can list the FLASH, there is even a video on youtube of somebody doing just that. The old Murdoch or his son (so much in the news lately for eavesdropping on people), about 12 years ago had the Viaccess crypto system of the completion hacked by an Israeli company, and posted the code on the internet, You do not get big by playing 100% fair. Now a pie in his face and 6 weeks prison for the pie thrower, and Murdoch runs around free, sure the man disturbed the 'magistrate', but justice? Few hundred years ago you were send to Australia if you stole a bread (because you were hungry). I can see the resistance being born... mm getting a bit sidetracked here, down under is not even so bad.. look what they did to the Aboriginals,.. human nature... Law of the strongest, somebody will hack that unbreakable PIC type too if they consider it worth the money. Economics. OK, that was more than 100 Euro worth of story telling or advice if you can see it in here. hehe LOL :-)
It appears that some more recent units (eg. PIC18F2XK20) have EEPROM read "protection" but they specifically say that it only applies to "external" read/write. In which case, I think you should be able to erase the flash read off the data with a program (or even just connect ICSP and read it off, since the config bits that prevent that will then be reset).
18F1320 is a generic as anything. The eeprom protection bit is only reset if the eeprom is erased or the whole chip is "bulk" erased. If the eeprom can be read just by selectively erasing the program flash then that seems like an extraordinary security gaff.
I don't think so. I don't think there is a documented way to erase CONFIG5H CPD without bulk erasing the _flash_. There really isn't that much interaction between the EEPROM peripheral and the rest of the chip.
Not terribly useful for what you seem to want, in any case.
On a sunny day (Tue, 16 Aug 2011 06:36:22 +1000) it happened David Eather wrote in :
Like I did mention in an other reply, on most of the PICs people can read everything if they really want to. The methods vary from pulsing the supply to beyond specs, to dissolving the package and putting probes on the memory cells. Depends on the budget the guys have... hehe :-)
3.1 here refers to something like that, which would imply that the CONFIG5H CPD bit is handled differently.
formatting link
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
Below is a proposed resolution from Microchip Engineering Support Team for your Ticket XXXXXXX
Area : PIC Products Product Group: PIC18FXX20 Product : PIC18F1320
Problem Description: Hello, I need some clarification before I proceed. The documents are not unequivocal and it seems a horrendous security breach.
I need to store private data in the eeprom. The code and data protection bits have been set to prevent access. BUT I have been told that the eeprom can be read by simply bulk erasing the flash memory and programming in software to read the eeprom and spit it out as serial data.
My question is simple Is that true?
(All contact by email please)
TIA
David Eather
Problem Resolution: The procedure you mention is described in "3.2High-Voltage ICSP Bulk Erase" chapter from Programming for PIC18FX220/X320 FLASH MCUs.
If you really want something protected put it in Flash. The difference from EEPROM is that you can TABLE READ protect an area of FLASH. What that does is to DISABLE any READING from another block of FLASH except that BLOCK where the data sits in. You can put a function inside that FLASH block to read and write the sensitive data. That function can be called by your code that is situated in another BLOCK and that is much safer.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.