The key for success is: TIME TO MARKET! Propeller gives You the ability to be fast and the first. Your success will protect You. You will be able to make unbeatable prices. Therefore: don't hesitate, just start. It may be ingenious to put all the code snippets together, but all spin and assembler code here is open and therefore valuable.
There are ways to protect IP. If you have a device with a unique ID - eg Dallas 1-Wire device, SD Card(!), Ethernet MAC address. Then you can use that to sign the code. Then if your code detects that the ID is incorrect, then it breaks the code (but just a little bit). As a result, any (EEPROM) copied product will be inferior to the original.
Examples of little breaks:
1) Randomly resets every couple of hours
2) Drops random characters out of comms links - not too many though - just enough to cause issues for the copier.
3) Writes out the occasional bit of corrupted data - if it's in a comms message, then calculate the checksum after corrupting the data!
4) Does occasional inappropraite operations on the connected hardware (eg. toggles a status LED at the worng time).
Be subtle, be creative - protect yourself.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007
I believe, IP can only be protected by success. Even if you file a patent. In the beginning, we disassembled CP/M completely and knew every byte, no to copy it, but to make it better. But this work was even better done by Software2000 with TurboDos. And so on. Implement a good idea, find friends and join. That is imho the idea behind the propeller. Object orientation: create small, encapsulated pieces of code and put them together. Go NOT the way of the "scientists": to create complicated "Objects" and "Methods" and lots of parameters with complicated behavior.
Microsoft showed, that a "brand" is more critical to success than IP.
Put the main routines in the secured PIC and have the Propeller be the fast slave,
transferring possibly encrypted (but requiring PIC handshakes) codes to the propeller
only for doing what only the propeller must do. Perhaps give unused cogs mysterious and
meaningless jobs, especially after they have done what is needed.
Keep all your secret code in the PIC, and have the Propeller beg for only that which it needs,
in encryption code only when it's needed. Let the PIC be the "Cog of Secrets" which the
Propeller never sees. Also, use the PIC to emulate an EEPROM during boot and data transfers.
To clarify, keep the most secret code in the PIC, and even let the PIC execute it,
and any propeller code which needs secret data must ask the PIC for it only as needed.
Anyway, I think that if you are composing secret code by yourself,
rather than with a team of highly specialized experts on something really esoteric beyond all sci-fi imagination,
then I don't think that you have any real mysterious secrets that I haven't already imagined as potential apps!
The Sum of ALL digital human knowledge is only "very close to" 6049999499/49005000000. Seriously, it's a fact.
Somebody said...
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?
Reminds me of Katie Melua's song - '9 million Bicycles' ........ a lot of lines end with 'that's a fact' or 'that's a guess'
and she was taken to task on it !
So Katie being a good sport re-wrote that verse containing the 'facts' ...
I created a sort of protection scheme on my CNC cards using a PIC12F683. I also sprinkled some 16V8 PALs into the circuit to make copying·the card more of a bugger [noparse]:)[/noparse].
The PIC has control of the Propeller reset line and shares the connections to the I2C pins and the serial pins. [noparse]/noparse]Edit - too much info - removed [noparse]:)[/noparse The PIC operates as both a master and a slave on the I2C and can mess with the Propeller if it needs too.
The system·has a couple of advantages in that I can issue secure service updates and it provides limited IP protection.
I used a 12F683 because it's small and incospicuous (just 8 pins - it sits next to the EEPROM memory and would normally be mistaken for another bank) but it has an 8Mhz oscillator that does not need tuning and can support a decent serial rate.
Alex.
Post Edited (Alex Mackinnon) : 12/6/2007 11:53:57 AM GMT
Alex Mackinnon said...
If you can change the silicon to add an 'identity' to the chip (polysilicon fuses?) then, also assuming you can modify the programming and loader code in the Propeller, then IP could be protected by modifying the binary written to the EEPROM based on the chips unique or semi-unique ID. The user does not need to know the fuse/ID settings and, depending on the length, they could be random or serialised (you could keep it secret - depending on the chip ID length the chances of a user getting hold of two Propellers with the same ID would be small and the only way to find two such chips would be trial and error). The user programme would be sent to the chip as usual and it would be down to the chip to encrypt it or decrypt it from the EEPROM.
Because the code sent to the EEPROM would only be executable by the Propeller that wrote it IP would be protected. If someone copied the contents of the EEPROM directly or even intercepted it at boot time it would only be of use to another Propeller with exactly the same fuse/ID setting. The only vulnerability would be someone intercepting the true binary as you sent it to the Propeller when initializing the EEPROM - so anybody doing field updates would have an extra exposure.
Ooh, I forgot to add... because this IP protection would be on the Propeller<->EEPROM interface it would not affect the users experience in any way... so a new 'IP-protected' Propeller could be dropped inplace of an unprotected Propeller.
Alex.
Even though I'm new here, I'd like to add this, while this seems like a good solution, what happens if say a device connected to this propeller burns out an internal output driver within the propeller, that means a field replacement would be needed. If only the same "fuse" identity is required to restart the program, how is one to do that? You'd never know what the fuse sequence is or its semi ID. And most likely the repair tech isn't going to have the source code....with a 100K+ units system like this, how would you repair it when it fails in the field over a few years time???
No, the prop does not need a pic to operate. Just an eeprom to hold your code and a program connection on pins 30,and 31. Even the crystal is not needed if you can deal with the slower clock speed. The pic is suggested here to impliment code protection and/or make hacking of a persons Intellectual Property(ip) harder to retreive.
ErNa said...
I believe, IP can only be protected by success. Even if you file a patent. In the beginning, we disassembled CP/M completely and knew every byte, no to copy it, but to make it better. But this work was even better done by Software2000 with TurboDos. And so on. Implement a good idea, find friends and join. That is imho the idea behind the propeller. Object orientation: create small, encapsulated pieces of code and put them together. Go NOT the way of the "scientists": to create complicated "Objects" and "Methods" and lots of parameters with complicated behavior.
Microsoft showed, that a "brand" is more critical to success than IP.
For this protection to take effect, you must show that you took "reasonable precautions" to protect your IP. I would suggest that if you have unencrypted code on an unpotted EEPROM, you might have no grounds to sue the guy who copies you.
I am excited about the propeller as well. But the issue of intellectual property security is a huge problem. I don't want to spend years on my code just to give it to my competitor for free as soon as we ship product.
These don't really solve the problem. If you use them to decrypt your program memory as you load it, a thief can monitor the lines between the Prop and the CryptoMemory and record the data in the clear as it's transferred to the Propeller. These are very useful when you have a device that receives information over a communications port and you want a key that's reasonably secure when the physical device is not in operation ... in other words, stealing the device won't get you that much and having access to the communications channel won't get you anything, but having both at the same time gets you the real data.
There have been extensive discussions on this subject here in the past. The experience of some has been that it is nearly impossible to prevent theft by a determined and well equipped thief including the ease of "breaking" protected EEPROMs on processor chips.
The Atmel CryptoMemory product brief said...
Each crypto memory chip contains a unique serial number and the user can optionally assign one of four unique 64-bit encryption keys to each zone. The host knows how to generate these keys using the serial number and a special “secret” that it stores [noparse][[/noparse]emphasis mine]. During mutual authentication, the CryptoMemory sends its serial number and encrypted identity to the host. The host then computes a 64-bit number, called a “challenge”, based on a random number and its own encryption key.
Unfortunately, there's no way to store a "secret" in the "host" (i.e. the Propeller) to make this scheme work. Perhaps such a facility will be available in the Prop II.
Atmel's cryptomemory is an interesting product. There are a couple of issues with using it though:
First off is that Atmel requires users to sign a NDA to obtain all the information necessary to use the product. While it might be acceptable if we were producing an end consumer product, it would be very onerous to use it and then be unable to explain to our customers how it's used.
Second, by using the chip we are hitching our wagon to Atmel. If Atmel decides to change how the chip works or discontinue the chips, we are up the proverbial creek.
Comments
Examples of little breaks:
1) Randomly resets every couple of hours
2) Drops random characters out of comms links - not too many though - just enough to cause issues for the copier.
3) Writes out the occasional bit of corrupted data - if it's in a comms message, then calculate the checksum after corrupting the data!
4) Does occasional inappropraite operations on the connected hardware (eg. toggles a status LED at the worng time).
Be subtle, be creative - protect yourself.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007
Microsoft showed, that a "brand" is more critical to success than IP.
Put the main routines in the secured PIC and have the Propeller be the fast slave,
transferring possibly encrypted (but requiring PIC handshakes) codes to the propeller
only for doing what only the propeller must do. Perhaps give unused cogs mysterious and
meaningless jobs, especially after they have done what is needed.
Keep all your secret code in the PIC, and have the Propeller beg for only that which it needs,
in encryption code only when it's needed. Let the PIC be the "Cog of Secrets" which the
Propeller never sees. Also, use the PIC to emulate an EEPROM during boot and data transfers.
To clarify, keep the most secret code in the PIC, and even let the PIC execute it,
and any propeller code which needs secret data must ask the PIC for it only as needed.
Anyway, I think that if you are composing secret code by yourself,
rather than with a team of highly specialized experts on something really esoteric beyond all sci-fi imagination,
then I don't think that you have any real mysterious secrets that I haven't already imagined as potential apps!
The Sum of ALL digital human knowledge is only "very close to" 6049999499/49005000000. Seriously, it's a fact.
Reminds me of Katie Melua's song - '9 million Bicycles' ........ a lot of lines end with 'that's a fact' or 'that's a guess'
and she was taken to task on it !
So Katie being a good sport re-wrote that verse containing the 'facts' ...
enjoy !
check out this link ...
www.youtube.com/watch?v=21iUUe-W8L4
the article ...
http://www.guardian.co.uk/g2/story/0,,1581445,00.html
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Post Edited (QuattroRS4) : 12/5/2007 5:28:43 PM GMT
The PIC has control of the Propeller reset line and shares the connections to the I2C pins and the serial pins. [noparse]/noparse]Edit - too much info - removed [noparse]:)[/noparse The PIC operates as both a master and a slave on the I2C and can mess with the Propeller if it needs too.
The system·has a couple of advantages in that I can issue secure service updates and it provides limited IP protection.
I used a 12F683 because it's small and incospicuous (just 8 pins - it sits next to the EEPROM memory and would normally be mistaken for another bank) but it has an 8Mhz oscillator that does not need tuning and can support a decent serial rate.
Alex.
Post Edited (Alex Mackinnon) : 12/6/2007 11:53:57 AM GMT
Even though I'm new here, I'd like to add this, while this seems like a good solution, what happens if say a device connected to this propeller burns out an internal output driver within the propeller, that means a field replacement would be needed. If only the same "fuse" identity is required to restart the program, how is one to do that? You'd never know what the fuse sequence is or its semi ID. And most likely the repair tech isn't going to have the source code....with a 100K+ units system like this, how would you repair it when it fails in the field over a few years time???
Just a thought from a repair perspective.
All true, but in the United States, you have something called the Economic Espionage Act of 1996 .
For this protection to take effect, you must show that you took "reasonable precautions" to protect your IP. I would suggest that if you have unencrypted code on an unpotted EEPROM, you might have no grounds to sue the guy who copies you.
-TL
Has anyone looked at Atmel's CryptoMemory?
www.atmel.com/dyn/resources/prod_documents/doc5051.pdf
The dcument above mentions using it in embedded devices with an external controller.
Below is a link to the Atmel CryptoMemory category:
www.atmel.com/products/SecureMem/
Bluesky
There have been extensive discussions on this subject here in the past. The experience of some has been that it is nearly impossible to prevent theft by a determined and well equipped thief including the ease of "breaking" protected EEPROMs on processor chips.
-Phil
First off is that Atmel requires users to sign a NDA to obtain all the information necessary to use the product. While it might be acceptable if we were producing an end consumer product, it would be very onerous to use it and then be unable to explain to our customers how it's used.
Second, by using the chip we are hitching our wagon to Atmel. If Atmel decides to change how the chip works or discontinue the chips, we are up the proverbial creek.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 12/14/2007 1:24:06 AM GMT