EEPROM security.
webmasterpdx
Posts: 39
Is there any security to stop someone stealing the contents of your propeller EEPROM???
Thanks
-Donald
Thanks
-Donald
Comments
Aside from encasing it in a cubic meter of concrete and burying it underground, no.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheus & Mem+dual Prop SBC w/ 512KB kit $119.95, 2MB memory IO board kit $89.95, both kits $189.95
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
(as if anyone has money these days anyway)
There are secure serial EEPROMs where the data are encrypted. Then when you read it you must decrypt it.
Basically you can do this with any serial EEPROM by just applying an encryption algorithm to the EEPROM and decrypting it yourself in the propeller. You are basically putting your own password to your EEPROM that is encoded in the EEPROM itself. Lets assume that I have a way to do that (put the password/key into the EEPROM without someone figuring it out) for now....I'll deal with that later.
OK, the way this would work would be to have certain boot code to get things booted up initially unencrypted. This might fit in the first 2K of the EEPROM for example and the rest of the EEPROM is encrypted. Then this startup code decrypts the upper 30K of RAM in place. Then it jumps to the real starting point and the application can commence.
So, the objective is to stop the user from reverse engineering the decryption.
The trick is to be able to extract the password without the user determining how you did that. I'll need to think on this problem.
-Donald
Don't rack your brain too much, if anyone WANTS to copy your code, most likely the only ones that would really want to would be hobby/engineers, and would only do it for the challenge.
Code steppers, along with assembly pros would be able to hack your method quickly.
This is why the software industry is beyond frustrated with piracy, too many people have more time than money these days.
THERE IS NOTHING SO REVOLUTIONARY ON THE PROP THAT ITS WORTH THAT MUCH TIME.
Just wait for the prop2, or encase the eeprom and prop in some kind of resin/plastic.
Any method you come up with WILL be broken by minimal effort by anyone thats interested.
Stick with making awesome products, and pushing the envelope of whats possible, and you will have people buying your products even tho the code is unencrypted.
With a scope on the SDA, SCL lines, anyone can see what your trying to hide, combine that with the crazy nuts out there that print out evey line of code only to take it apart to the point that they understand it better than you.
But don't let me discourage you from proving me wrong.
SOO many compaines and individuals spend 24/7 figuring out ways to stop people from copying their products that they forget to make a good product. And in the end their efforts are broken anyway.
They also forget that if you make a great product, people will want V2.0 from the original makers.
Post Edited (Clock Loop) : 8/31/2009 4:22:03 AM GMT
Thats just an example. There are thousands apon thousands of proprietary algorithms that people supply as part of their products.
e.g. I worked at an imageprocessing chip company that makes the chips that drive flat panel monitors, TVs and projectors. It was HUGELY competitive and nobody wanted competitors to get their code. They would place a high emphasis that those developing with their chips had to lock the code to stop taiwanese companies from ripping them off. This was a 100 million dollar a year business that could be ripped off by foreign companies where piracy laws are not well enforced. In firmware, you CAN implement protection and this business is different than the PC software business.
Anyways, I think I have a way figured out for the propeller.....see next post....
I once had to make a design that needed code protection.
We included a PIC that had code protection in it. Our code that ran in the DSP was not protected but we were able to interface to the PIC that let us use the CHEAP PIC CHIP to do the dirty code protection. It was not the best, but it was better than nothing.
Also, that platform had a program for the pc. So we were able to tie the hardware to the software and vice versa. Encryption through misdirection.
Here is the idea from a 1000 foot level...
First of all, the key used to encrypt the data is calculated from a combination of the following....
1. A checksum of some sort on the entire 32K of RAM. Some of the RAM is changed deliberately before doing the calculation to make it different than the EEPROM. This is to disencourage any code being added to the code we are using to try and help rip it off.
2. Certain ROM locations. I'm not familiar enough with the ROM, but if there are a few unmapped locations where the contents aren't in a document, then these would be used in preference to others. Remember the idea is to make it as difficult as possible.
3. Finally, each byte is encrypted based on it's address, so if someone is trying to decrypt it not in place, it will fail.
One more step. The entire code to do this is obfuscated (which is how Java is protected). Obfuscation can be done very well in java. Implement the algorithm in java and obfuscate it and then convert back to spin and assembly by hand.
Lets see how this proposal works.....
1. If someone reads the EEPROM, they can't do much with it.
2. If they bug the I2C lines, they can't do much with it.
3. They have to get by the obfuscation to understand it. This IS possible, but it takes a lot of time...may not be worth their while.
4. Lets assume they get by 3 and figure out how the algorithm works. They can calculate the checksum but can't add code to read it out or they'll change the checksum.
5. Now, I'm assuming there is a propeller simulator. Thats where this fails. They can run the algorithm and it'll run on the simulator and decrypt the data, so I need an algorithm that runs differently on the simulator than on the actual hardware.
If I can solve 5, I've got a really good algorithm that will protect one's code very well. I'll need to think on this some more. Checking a known register value that is automatically incrementing at a known time might result in a different value than might on the simulator.
This whole algorithm hinges on this as they don't even need to get by the obfuscation as the code will decrypt the entire thing before their eyes.
I'm thinking that maybe when a cog is initialized, there is an indeterminate number of cycles from 0 to 7 I think on startup. If that process can be repeated, a few times, you should get different values each time around. It's doubtful that the simulator would do that. It will most likely be repeatable on startup. Anyone know about this?
Also, anyone know of anything that is different on an actual propeller than on the simulator (again, I'm assuming there is a simulator....I'm new
Thanks
-Donald
Thank you....very good idea. I just need to sleep on this now to refine it and post it as neatly and succinctly as possible. GREAT idea....thank you again.
-Donald
You won't get an encrypted channel between the Prop and PIC that can't be simulated/replicated. In the end it's only a matter of time (and probably not a great deal of time) and in the bargain you make your development process a lot harder and your device more expensive.
Remember, whatever man can create, man can undo.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
The Prop-simulator exists, so the Pandora's box is allready open ...
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
1. Use something like PropDOS (in EEPROM) to load additional code from either SDCARD or a larger EEPROM. This provides the extra storage space to perform more complex mechanisms.
2. The SDCARD could contain the needed passkey/phrase - encoded to match the EEPROM at dispatch time
The SDCARD could contain your encrypted program code that gets decoded when read into HUB RAM in order to execute, The secondary (or tertiary) loading process could also prompt for a passkey (if there is any interactive component). Without the SDCARD, your code is unavailable and the Propeller would just sleep (or access some other SDCARD) or be re-programmable.
Using something like this, each "product" could use a unique passkey mechanism tied to the SDCARD supplied with the "product".
Maybe the kind of PUB/PRI key exchange as used with SSH (for example) [noparse][[/noparse]half in EEPROM and half on SDCARD].
As already mentioned in earlier replies; build an impregnable fortress so someone else can prove it isn't
FWIW: the RAM locations identified as the PortB "registers" are available for programmer use however actually using them may not be a good idea - but they are usable in this chip revision.
Cheers,
HarryE.
Because of the prop bootloader your startup eeprom code must be unencrypted so independently how clever your decryption code is every one can spoof it with a propocol analyser on the i2c bus. My way use the "password" stored in the ramtron device's counters. After the first boot you read the counters value and use it as "password" (I use it toghether with the product S/N stored in the same device: many features in this device). The "password" is preset with a stand alone application running temporarily and just once in the prop ram (basically just a i2c driver which scope is to preset the counter value - after that this app is lost and never run again). The protection prevent access to your hardware. If the hausing is opened a switch (can be a photodiode so if light reaches it ...) trigger the counters making them change their count value and thus changing the "password". This can happen also in absence of power since the counters are backed by the same RTC battery. If battery discharge: no problem the password still there (because it is in fram) but the protection is not working (no power to increment counters value)
The only way to break the protection (beside the battery failure and if you know its principle) is to download just to ram your code that read out the fram(eeprom) content and the actual counter value (without opening the housing). You can prevent this easily.
PEDIT: BTW I have described this method already some times now. It is working for me, but I haven't got any feedback/opinion from the forum.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
Post Edited (dMajo) : 8/31/2009 11:13:31 AM GMT
I just want to quickly comment on some of the other statements.
1. I can absolutely create a link that is not decodable between the PIC and the propeller.....using diffie helman key swaps....is how internet security works. No, internet security is not breakable using current compute technology. It depends on how big the key is. You can always use a bigger key that the current compute technology cannot break.
2. Yes, because of the bootloader you do have to have SOME unencrypted code, but it doesn't have to be much. The remainder can remain encrypted.
3. I already had a way to stop someone from running code inside the propeller. Part of the decryption involves a checksum from a sufficiently complex LFSR algorithm. If someone adds code to the non-encrypted part, it'll change the checksum. If that checksum is used in the decryption, by adding such code, they can never get it to decrypt.
4. The startup code should be able to stop any debugger functionality from accessing RAM I would imagine (please correct me if I'm wrong).
5. The simulator doesn't work with the locked PIC. Note the cheapest pic is 41 cents in 1 off quantities and 30 cents in volume.
6. I'll have to figure out if what is said about unlocking PICs is true. I suspect it's a lot more expensive than it's worth. You'd have to physically open the chip and run it while changing the bits with a silicon level probe....not a simple operation for sure. I'll look into that.
Thx
-D
Next, they'd have to use an ion probe and semiconductor laser to cut certain inputs to a particular AND gate.
Then they'd have to put it all together again and get the pic to power up. it will still say it's locked, but it won't be.
So, it is possible to unlock a pic, but it is not inexpensive and is beyond the effort worth trying.
Note also that the companies like Microchip are aware of these factors so don't be surprised if you open the chip and find the internal substrate has changed.....which they do all the time without marking the outside.
For a propeller type application it is not worth the effort for someone to rip it off this way.
Remember, the objective is to make it too difficult to be worth someone's effort to rip it off.
-D
I'm proposing that the password be in a cheap PIC and it runs a diffie helman algorithm with the propeller. The propeller will send a random value read from one of it's counters to the pic and the pic will send a random value from one of it's timers the other direction. Those values combined with some large prime numbers can be used to encrypt the data for transmission, so the "password" can be sent very safely to the propeller.
Note that the random values used to encrypt the password don't affect the password. That data is static and is what was used along with the checksum to encrypt the EEPROM.
The data is read from the EEPROM into memory. The startup code is unencrypted and does the key exchange with the pic and gets the encrypted password back which it can then decrypt and the use this along with the checksum to decrypt the remaining encrypted EEPROM in place.
There is one other thing you'd have to do. Use the checksum to decrypt a little chunk of code that does the diffie hellman exchange and decryption. Otherwise you might be able to run that algorithm from a PC to the I2C interface to the PIC and implement the same algorithm.
I'd probably have to think about this some more, but something along these lines should be doable.
This is an interesting exercise.....
Thx
-D
There was a thread that detailed a couple different methods of code protection. Various methods were discussed, including one that used a small PIC to perform decryption/encryption using a random key generated by the Propeller during boot. Unfortunately that again could be defeated by an emulated Propeller.
The best protection method would probably be some sort of system where your important algorithms / software would run on a code protected microcontroller. It's not an optimal or cost effective system, but it should be enough to persuade management that your system is reasonably well protected. It wouldn't be much different from custom hardware connected to a PC running software that can be easily copied.
http://www.cl.cam.ac.uk/~sps32/mcu_lock.html
It's possible to non-invasively "raid" a chip like a pic or whatever by using power glitching and other fault conditions. Another trick is to carefully monitor the power consumption to be able to observe bits being read. You can also freeze a chip after power off and have a few seconds to read the RAM before it dissapates.
Humans are clever...
Again, though, unless it's a hugely valuable solution, most companies wouldn't do that. I've looked and cannot find commercial enterprises offering to reverse engineer chips. I would imagine that they would be sued in international court pretty quickly.
There are companies that reverse engineer chips, but these are usually hardware chips....not software.....and it tends to be done very secretively. They'd never admit it.
So again it all boils down to making your design "difficult" to break (not impossible). Thats as good as you are ever going to get.
-D
Only way to have code security is to control the hardware, custom
processors and that sort of thing.... it's outside the realm of the possible
for all but large corporations and governments.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Some mornings I wake up cranky.....but usually I just let him sleep -
On a more serious note, I believe that Chip mentioned that they were looking into the possibility of some kind of code protection for the Prop II, but that the protection scheme being considered would just thwart copying, not completely prevent it.· For example, it could still be circumvented using the method that Mike mentioned to see into the silicon.
Thieving idiots will not see enough profit in copying your stuff then.
Same argument can be made to thwart DVD pirates that sell fake titles.
If they sold the DVDs for 3.98 then there would not be much profit in
bootlegging the things....not worth the legal risk at all.
so 4 ways to add some protection that I see.
1-cut prices to the bone and try to make it up on volume. (maybe the best advice)
2-rig up an authentication scheme (too much of a hassle for everyone)
3-custom silicon (too expensive)
4-physically make it difficult to get at the chips insides. (just a speedbump to thieves)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Some mornings I wake up cranky.....but usually I just let him sleep -
Why not? I could connect the required simulated pins to physically existing pins and this way connect the PIC to the simulator.
But then, I don't know how these PICs work exactly. Maybe they are timing-dependent.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Point 2 above is where you lose the game. Your boot code is the keys to the kingdom, easily reverse engineered to reveal your next stage encryption. Don't bother about obfuscation (as you seemed to infer was workable earlier) as security by obscurity is no security at all. Obfuscation is merely a very temporary speed bump in the road.
Even if you *think* you can make a secure link with a Diffie-Hellman key exchange (and I strongly doubt it, see point 2 above) you still lose as you are now vulnerable to a man in the middle attack.
Let me re-emphasize this bit a little.
Man in the Middle attack. Game over.
This is why we rely on a chain of trust with our certificates to ensure that we are talking to who we think we are talking to. The problem you have is any certificate you put in the propeller to let the PIC know it's not talking to a MIM, can be very easily extracted as you put it into the propeller.
Really, there is no sane way to protect your code on the propeller. There is really very little you can do on any processor. Just produce a good product, for a good price and give people customer service and they'll keep coming back.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
The consideration behind that idea was:
1) the prop needs a eeprom so I exchange it with FM31L278 device and I gain some other features that prop lack:
· - (rechargeable) battery backed RTC and counters
· - watchdog, reset circuitry and early power fail comparator (useful to backup some ram data before power is lost)
· - 64 bit programmable serial number with lock
2) I will have same read and write speeds with unlimited writes cycles (useful for data logging)
3) Using the counters my way it will give me the code/equipment-tampering·protection
The forever lost code happens only if you open/break the product's housing: usually there you'll find ever a "warranty void if opened" label/seal, so what's the problem if after someone has opened it it is not working anymore?·He will send it back, to be repaired,·or buy a new one!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
instead of a propeller just because the other one claimed to offer security
by use of a locking mechanism when in the real world all those 'locks'
are a joke.
I hope there is a FAQ somewhere on the Parallax site that explains all this
so that potential customers will know just how lame those locks actually are.
At best they just help keep honest guys honest...the crooks laugh at them.
At the start I also lamented the propellers lack of program security...but I came
to know the whole story.....all controllers lack program security.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Some mornings I wake up cranky.....but usually I just let him sleep -