Protecting IP in the Prop?
Skogsgurra
Posts: 231
Wow! What a feeling! I have tried out the Propeller Demo Board for about 24 hours now. OK, got a few hours sleep, but got up early and on it again. It really performs! And none of those "Oh no - must be the hardware" feelings that you often have with new processors·before you have wet your feet and got some know-how. This arcitecture is great and the Spin and Assembler are a breeze to grasp and use.
So, I would like to use this chip in a few embedded applications. I get paid to do the development and my customers want everything to be kept very secret. I can understand that. They have invested in research, development and marketing. And don't want their products being·copied by others.
So, the question is: Is it possible to read out the contents in EEPROM? I would say that it is. The I2C routines and a simple dump through a serial port seems to be one way of doing it.
Which leads to the next question: How do you protect the contents of the EEPROM from being read out?
Is there a standard way of doing it? Or should one apply some sort of pattern fill and checksum routine? Or what?
I assume that this has been discussed before. But I don't have the patience to search all the 80+ pages in the forum. Besides, it may be an interesting question to bring up again.
So, I would like to use this chip in a few embedded applications. I get paid to do the development and my customers want everything to be kept very secret. I can understand that. They have invested in research, development and marketing. And don't want their products being·copied by others.
So, the question is: Is it possible to read out the contents in EEPROM? I would say that it is. The I2C routines and a simple dump through a serial port seems to be one way of doing it.
Which leads to the next question: How do you protect the contents of the EEPROM from being read out?
Is there a standard way of doing it? Or should one apply some sort of pattern fill and checksum routine? Or what?
I assume that this has been discussed before. But I don't have the patience to search all the 80+ pages in the forum. Besides, it may be an interesting question to bring up again.
Comments
Here is the latest round:
http://forums.parallax.com/showthread.php?p=637417
Post Edited (originator) : 3/15/2007 12:05:12 PM GMT
In less than a week, I have grown a deep confidence in the Propeller and the thinking behind it. None of the MS problems and none of their attitude. None of the PIC problems and a lot better arcitecture than intel micros have. The -65 C test that I read about also makes me very happy. So, I want to use it.
BUT - I am not allowed to if there is no code protection method built into it. I can use it for some projects. But not for the 10 000+ units projects like intelligent bath-room ventilators and other consumer goods. Too risky for the customer - after a long development cycle, someone steps in and copies the design.
Still, I love the Propeller. And I will be using it a lot in less commercial projects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Labor, materials, weight, costs, no repairability, time, heat in some rare cases,
If someone knew what the processor was, an Xray or other non-destructive scanning method could quickly reveal the EEPROM and all pins/traces. Put the thing on a CNC machine and mill down to the exact pins no problem, would take a day or two max to get it done.
Potting is only a "layer" of protection for someone determined with resources.
Agreed that it is only a layer of protection - but if some one is determined enough - and has enough resources they will reverse engineer it anyway - no matter how far one is willing to go to protect IP.
I have to say that I love the 'Open Source' approach - I give customers full schematics ,source code etc with my controllers - when you display an open approach - they tend to trust you more - which leads to increased business - from my experience.
Copyright and Patents are ignored completely by certain countries - leading to cheap knock offs - and going the legal route can be quite expensive.
There seems to be a whole 'industry' dedicated to reverse engineering be it software or hardware..
Interesting read ...www.jenkins-ip.com/serv/serv_6.htm
I remember following the case mentioned in the link ....
NEWS DATACOM LTD v. SATELLITE DECODING SYSTEMS [noparse][[/noparse]1995] FSR 201
because it was based in this country ...
So basically - if you do spend lots on encryption, encoding, copyrights and patents etc - How far and how much are you willing to go and to spend·on a legal route without a guarentee that the findings will be in your favour ?
As with the sample cases in the above article ...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Post Edited (QuattroRS4) : 3/15/2007 2:18:42 PM GMT
You do not understand.
My customer gets it all, of course. I couldn't sell him something he can't maintain and modify. But, when he produces 10 000 or 100 000 units to be sold in the open market, he does not want anyone to buy one of these units, open it and read the code that is doing all the work and that he has payed for.
This has nothing to do with open source - which I am much in favour for. Do you really not buy things that you do not get the drawings, electric diagrams, the source-code or VHDL code for?
If that is so, you lead a tough life. You can not, for instance, buy a Propeller chip since the source code for the interpreter is not available to public.
Your actual program is compiled and saved as a binary file on the PC. A PC program encodes the program using the 64 bit unique address of a 1-wire part. This encoded compiled program is included in a small program as data using the FILE directive. This small program's only function is to read the 64 bit address from an attached 1-wire device and startup a small assembly program that decodes the data from the binary file and copies it to the low end of main memory, then starts the Spin interpreter on this now decoded program. You'll have to obscure the markings on the 1-wire part so someone couldn't just read the address off it visually.
This technique prevents the EEPROM from working if it's just copied directly. The thief has to decode your decoding program enough to understand the algorithm used, read out the 1-wire address, decode the binary copy of your main program.
That's a lot of work for the thief for only 10K+ devices. On the other hand, you'll have to change your technique with every new project since, once "busted", this scheme is really easy to "bust" again.
Im afraid its to the contrary - I completely understand - having been involved in a legal debacle costing extortionate amounts of money over IP with a multinational - and it came to a point where I had to withdraw as they could afford to tie me up in a legal wrangle until I was bled dry .... perhaps I understand it quite well..
Quattro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Especially since the concept of the scheme is published!
I think it's pointless to go round and round about open vs closed.
It always starts sounding like pc vs MAC
The option should exist for some degree of protection for those that want to use it.
Post Edited (originator) : 3/16/2007 7:48:05 AM GMT
If the customer gets it all - what is to stop an employee divulging critical info. to the masses - in this scenario perhaps the onus to protect IP should not be entirely your burden ...
You have only had the prop a little over 24 Hrs - I'd say enjoy it for a while longer before getting bogged down with this particular aspect ...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Post Edited (QuattroRS4) : 3/15/2007 2:34:26 PM GMT
But I live in a real world. And I can not - that's the truth - use it for certain applications if the code cannot be protected. That is their stand - not mine.
Companies have their way of dealing with their secrets. And it seems to work. Or has the secret Coca-Cola recipie got out of their hands?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Post Edited (originator) : 3/15/2007 3:15:57 PM GMT
didn't you hear about open cola ?
en.wikipedia.org/wiki/OpenCola
Any protection system can be cracked, even systems with built in PROM, for example by looking at power consuption patterns, using a strong (xray) microscope, or by placing microscopic probes on the chip, many methodes exist. But without built in ROM (with readout protection fuses) it becomes trivial.
The propeller chip could not build in an (EE)PROM because the chip technologies (Propeller and EEPROM) are incompatible.
Without such an internal (EE)PROM any "copy protection" scheme is trivial to hack, just by looking at the signals going to and from the external memory.
Mahjongg.
Don't forget that unless your software is vey complex it will be very simple to reverse engineer anyway. If you have a good idea for a product that should be patented, but protecting software in a micro is a bit like trying to stop someone looking at a bolt.
JMHO that I made up just now. I understand Skogsgurra has specific issues wih clients.
Graham
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Yes. It is always possible to crack almost anything. But there is often a point where it simply costs too much to do it. And if there were a simple technique to set up a solid fence, I think that this part of the problem would be over for my part. Something like the code protection bit in a PIC or a DSP.
But I am perfectly happy with the lesser projects. There are enough of them to keep me happy personally. But I can't help thinking about all those other projects that can't benefit from the Prop - mine or other's.
Perhaps, one day, we will see a Prop with on-board flash and a good protection scheme. From what I have seen so far, it would not surprise me.
I guess the real question is "What will make the customer feel better about IP security?", not "What is a way to produce a product not easily copied?". If the only way to do this is to have an on-chip fuse protected write-only PROM, you're simply not going to be able to use the Propeller. It's very clear (as an outsider listening to the developer's comments) that Parallax is not interested in sacrificing chip capability or performance for this particular aspect of marketability, particularly since what you really get for the resources allocated is a false sense of security and the cost (in chip area and production costs) for including any EEPROM is so high (with or without fused "protection").
Right now we have this:· Propeller <--> EEPROM
What if we had this: Propeller <-->·PIC <--> EEPROM
The PIC could be of the 8-pin/50-cent variety and have a unique cypher pattern programmed into it. It would be operationally transparent. It could also be set to never allow reprogramming of the EEPROM, so that nobody could program test cases and view the result. It could initially load the Propeller with a short/unique cypher routine which would then read in and unscramble (into RAM) the EEPROM data. That way, unprotected data would never travel across wires. Of course, someone could spend the time and crack it, no matter how many levels we make it. We could make an app for the Propeller which would allow you to customize and program these cheap PIC chips for this cypher application.
Here's another idea that needs some investigation: Imagine an external VDD-to-VSS RC circuit whose RC junction ties to maybe three different pins. Because of manufacturing imperfections, each pin has a slightly different logic threshold. The pattern of relative thresholds might form a reliable 'signature' across temperature and voltage extremes for a given chip. This signature could be used to scramble the bulk of the EEPROM data, except for·a loader and descrambler routine. The descrambler would apply the signature to what is your intended application, and then run it. If the signatures didn't match, the program wouldn't run because it would be a bunch of nonsense. This would require at least three I/O pins, a resistor, a cap, and less than 1KB of EEPROM space.
Do any of these schemes seem adequately simple, cheap, and secure? I wish we had something in the Propeller, itself, that we could glean a reliable signature from. That would make this all a matter of declaring a CON variable to enable·some protection.
I understand your customers' desire for some security, even though we all know that anyone with some equipment and know-how or, better yet, a budget, could get anything figured out. I've heard there are shops in Taiwan and China that will retrieve protected code out of popular microcontrollers, and I bet they don't charge more than a few hundred dollars.·Parallax·is·the only official source of SX chips, yet we've been asked to bid against·Taiwanese clones of the SX. So, not even the chip makers·are safe. Stopping the casual hacker·is all we can realistically·hope to do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 3/15/2007 4:19:28 PM GMT
That 50 cent PIC thing would probably satisfy most of the guys I talk to. Their concern is mostly formally legal, not based on facts like "does it work?" or "can it be broken?" or such things. If it can be shown that the protection bit in the PIC also protects code from being read out from the EEPROM, then I would say that they would accept it, simply because they already accept the PIC code protection. They get some kind of declaration that the code is protected. It may be necessary to publish a document on the Parallax home-page saying that this is a good and safe solution, signed by you. Not that it helps, but because they will feel a lot better if a corporate officer has signed it. I think that such an "IP-P-PIC" could be a good product for those applications where the problems exists. And the bang for the buck you get with the Prop makes it (mostly) easy to absorb the extra cost.
I haven't thought it through thoroughly. But it certainly sounds like a good idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Imagine also that the temperature changes...
But the main problem is that this needs to be calibrated for each of a possibly 10.000 units...
That's a lot of time, and time is money for most.
I like the 1-wire approach, though.
The DS2401 'serial number' chip can be bought as SMT 1206-lookalike component, and can easily be mistaken for a resistor. It may be possible to set up something that looks like a voltage divider(after all, the 1-wire bus needs a pull-up resistor).
That and casting everything in epoxy should help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
1) No matter what we do, it can be figured out. We can make it very hard, though.
2) A one-size-fits-all approach is not safe. Once hacked, everybody's code is compromised.
3) Getting between the Propeller and the EEPROM is not optimal:
···· a) It means a boot routine must be used which could be easily captured.
···· b) It compromises the simplicity of the Propeller-EEPROM relationship.
I think that having a cheap/small code-protected microcontroller, such as the $.39 6-pin PIC10F200,·acting as a one-pin serial packet cypher·on P29/SDA would be optimal. The Propeller would generate random 128-bit·packets·and send them·serially to the cypher chip. The cypher chip would use its key, only otherwise known by the Propeller application, to cypher the incoming data packet and return it. The Propeller app would verify that this was done correctly, as often as it wanted to, and stop working if there was an error. Anyone looking at the wire would never see the same thing twice. In order to defeat this protection,·each·application·would have to be reverse-engineered to the point of figuring how and where the cypher communication was occuring, and what was resulting from it. Everybody could code this differently, so no two apps would fall for the same attack. This is how those Parallel Port and USB software dongles on the PC work,·and they are very effective. Where this would differ is that identically-programmed PICs would serve for a production run of a given application. That way, the same code would get downloaded in the Propellers' EEPROMs with the expectation of the same cypher key in the PICs. You would want to make them all the same so that someone couldn't just compare EEPROM data between two units and spot the difference, giving them a shortcut on defeating the system.
If there is any interest in this, I can pursue development. I imagine it would cost a couple hundred bytes of Spin code per application to implement, along with one of these $.39·PIC chips which would need to be programmed. We could make a stand-alone Propeller-based PIC programmer just for this application, so you could get the PIC chips from the cheapest source and pick your own keys. We would make an App Note explaining how to do all this and how to make it unique, or hard to detect.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
I would love to see this developed.
Thanks for taking the time to look into it for us.
Post Edited (originator) : 3/16/2007 7:49:26 AM GMT
1. A symmetric (used for encoding and decoding), secret cipher key K0 is chosen, and is used to encrypt the program.
2. The cipher key, K0, is also stored in the attached PIC.
3. The encrypted program is stored in the EEPROM.
4. Also stored in EEPROM is an unencrypted boot loader.
5. The boot loader is the first program to run after the Propeller resets. The first thing it does, by a means untraceable (using a noise signature, perhaps), is to create an internal, random private key K1. This key will be different each time the bootloader runs.
6. From K1 the bootloader will then create a public key, K'1, which it then sends to the attached PIC.
7. Now begins the bootload process. The PIC fetches data from EEPROM, decoding it using it's own key, K0, then reencodes it using the Propeller's public key K'1, before sending it on to the Propeller.
8. The Propeller then decodes the data using its randomly-generated private key K1 and stores the plaintext firmware in RAM.
This method should be as secure as the code protection for K0 in the PIC, since there are no external signals containg unencrypted data or the means to decrypt it. There are, of course, huge gaps in the implementation details. And as much as such things run counter to my open-source leanings, and as much as I feel like an agent of dark forces for addressing it, it is an interesting problem!
-Phil
Update: Oh Smile! Forget it: the method is insecure. There's nothing to prevent someone from using the same bootloader and their own public/private key combo to grab data from the EEPROM using the PIC.
Post Edited (Phil Pilgrim (PhiPi)) : 3/16/2007 2:54:23 AM GMT
That sounds perfect, but I don't understand how the boot loader can't be intercepted, emulated, allowed to produce some 'random' key and then used to decrypt the whole stream into an unprotected memory. How does it prevent that?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
You thought of the crack seconds before I did! You're right. It's insecure.
-Phil
If I had the forethought to put this in the ROM bootloader, it would have been secure.
So what about my proposal for a cypher PIC? I read in Bruce Schneier's "Applied Cryptography" book that 10 different parallel LFSR's make quite a difficult-to-crack cypher. That's simple on the Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 3/16/2007 3:28:33 AM GMT