I was looking forward to Chip's 'solution' using that 39¢, 6-pin PIC solution.
I've been thinking about this, still. Here's the conclusion I've come to:
1) For the current Propeller, the most sensible thing would be a one-pin (asynchronous serial) or two-pin (synchronous serial) dongle that acts like a cypher for validation purposes.
2) For a ROM-rev'd Propeller, we could use the same $.39 PIC as a dual-keyed cypher that would be placed between the Propeller and EEPROM.
#1 requires some alteration to your app, while #2 wouldn't. #1 could take only one pin, be simpler to connect, and not interfere the EEPROM interface. I could develop #1 right now. #2 will cost at least $40k to make happen (poly layer mask change, engineering wafer lot, packaging) and bifurcate the Propeller line. The cool thing about #1 is that there is no single attack that could compromise it.
Chip, for current designs using #1 method (that could add the dongle later when you get it finished, and just get jumpered until then), have you drawn a circuit that includes the pin assignments on the Prop>PIC?
If so, that would be great to know for boards currently in the works.
Is pin multipurpose after boot, or is it sacrificed?
OK, the preaching is over. Now for the coffee that we usually get after sermon (at least here in Sweden). That "Curch-Coffee" used to be where important discussions and decisions took place.
#1 is good enough for me. I presume that, given the flexibility of the Prop, any pin can be used. The loss of one I/O pin could prove fatal in existing designs. But, heck, they are already on the market and those that want to clone have probably already done so.
One possibility would be to use one of the Tx/Rx pins. I guess that they already are free in most cases. Important that normal use doesn't corrupt the dongle.
His idea is to use SDA, then there would be an impossible, or highly unlikely I2C data sequence the pic would listen for. This way no additional IO pins are consumed.
Been reading this thread with interest. Good discusssion everyone.
I'm on the open side of things for a lot of reasons. Posted as such, largely to see where people stood on the matter and why. It's all valid, IMHO.
Frankly, this is a good path. I am currently working hard to grok the prop because I like the design and I think it's significant, given the current direction computing in general is heading. Open, closed, whatever, it's all seriously fun and powerful stuff!
It's in our mutual best interests to see this matter closed with a viable solution. More props in the market means more that we all can leverage toward our goals. It also means more dollars for Parallax and that makes them stronger in the market, thus we will see a great design evolve into an excellent one.
That's it really. Just thought I would put a coupla my earlier posts in context.
One nice thing about this path, is that any prop can still be repurposed at some point in the future. Unless I'm missing something, that is... Many years from now, that's gonna matter for those wanting to tinker as we are today.
It·could connect to any pin, but P29 (EEPROM's SDA) might be optimal to use, since it's free. This device has a flash ROM that must be programmed. We could make a stand-alone Propeller-based programmer that could program the device in-circuit or out-of-circuit. In-circuit programming would require 4 pin·connections. The connector would take a lot more space than the chip, itself. Programming it before assembly would make things wind up tidier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 3/19/2007 3:22:33 AM GMT
I'm realizing there may be some problems with this dongle idea:
1) I cannot get the Propeller to generate a random number on power-up. Even using the internal free-running·~20KHz clock as a 'random' clock-switchover delay,·things are remarkably repeatable. Without the means to generate a random number, the cypher conversation·would be·routine and prone to a record/playback attack. To get around this, the Propeller's attached EEPROM could be used as a non-volatile counter to keep the cypher conversation from repeating, but this would force more complexity, requiring I2C routines. The effects of changing the EEPROM could be easily detected and reset, anyway.
2) Those 6-pin PICs pose some real logistical headaches·when it comes to·inserting·the application and master·key at program time. Either they get programmed before assembly, throwing a wrench into an otherwise-automated assembly process, or they must be·programmed afterwards via some in-circuit programming tool. A $.67 PIC12F629 in an 8-pin·package could be used, instead, which would have some internal data EEPROM, greatly simplifying this process. One dongle app could be written, programmed into the devices·at Microchip's factory, and then key-customized in a two-step Propeller downloading process (first to RAM to run the key-customizer, then to EEPROM for the final application code). This would be much cleaner, logistically, but cost a little more and take more space.
3) The lack of means to generate a random number on the Propeller on power-up is perhaps a fundamental obstacle to·security. The PIC could be employed to use its WDT to halt a software count routine, but the·resulting count·might only vary with temperature changes. Assuming the PIC could generate a random number, it could then convey it to the Propeller. No external pins can be employed in the random number generator (on either chip) because they could be tampered with in order to make the random number a constant. One thing's for sure: the next Propeller is going to have some kind of internal noise generator from which real random numbers could be gleaned.
This is going to require some more consideration. If we could make a random number on power-up on the Propeller, and use a PIC with internal data EEPROM, the system could be fairly elegant, but not nearly as tidy as a 'protect' bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 3/19/2007 9:08:01 AM GMT
If using an external noise source to a pin(s)... the random number could "somehow" be encrptyed and stored. Then, on every boot, if the number was the same, it would continue to reboot, until it saw a different number.
The DIP PIC10F200 would be convenient, use a dedicated programmer board, then move it over. It is twice the cost. Digi has quite a few.
Post Edited (originator) : 3/19/2007 9:19:01 AM GMT
That's a good idea, insuring differences. No one can tell 'when' the pin is being sampled, anyway, which makes it a Smile shoot for the hacker.
Phil Pilgrim had a good idea for using a few resistors and pins in the CTR's ADC mode, and sampling them periodically. He was getting apparently random results.·That's a few more pins, though.
It would just be ideal if this could be done completely inside the chip. There might be some way to do this, like bouncing·a CTR's·PLL around and then sampling its output. Yeah! That's the next thing to look into... the PLL! It's extremely non-digital and probably fertile grounds for 'randomosity'.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 3/19/2007 9:37:22 AM GMT
'Turns out that one 100K resistor between pins and a 220pF to ground works better than two resistors for random number generation. But, yes, two pins get wasted (although in some apps, the same pins could be used for other purposes once a random seed is generated). I like the PLL idea. Anything with an analog component should work.
I wonder if Microchip's KEELOQ rolling code products might find application here, BTW.
In cases where the product required the dongle AND all the pins(but could absorb the cost), an I2C anolog switch could be set on boot to connect the pins to the RC Phil descrribed. After the random number is generated, it can switch the circuit for normal operation. Of course this still requires that the random number be stored on every boot and compared. The below I2C switch is just an idea, I didn't study the IC.
I've been playing around with the CTRA PLL today, tracking the CNT's delta through a·WAITVID instruction. I have it configured so that it doesn't output to any I/O pins, so it is completely internal. By toggling FRQA between two values, you can sweep the PLL's VCO and get lots of randomness out of a WAITVID's duration. It's working well, but I'm trying to distill down the concept so that we get the most randomness·from the least code.
So, the Propeller CAN generate random numbers on power-up, after all, without any external circuitry. And it can do it off the ~12MHz internal oscillator, as well. I should have some code to post tomorrow.
Just a thought for the wiser members here, as I don't know how feisable or doable it is. Chip you might consider one of there dsPics. Load a small program and use the upper 32k with program visibility option for the Props code instead of EEPROM.
Like I said "I don't no if it's worth it, but hay, it's food for thought!
PS.
If placed transparently on the progamming connection after boot up the 2 uart lines and the free I2C lines along with one clk pin you could then have a 4 bit bus capable of useing the dsPIC's Ram. (Up to 16K on some models I think.)
Or optionally make use of their Periphials.
Compared to the current configuration thats a loss of one pin!
If you have code to generate random numbers, and it's loaded from an external eeprom in an unencrypted format then why can't somebody just patch it? Or is this something that would be encrypted in the boot ROM of the next chip? If you're just looking to obfuscate a little, then I guess you could take additional steps like sanding the part numbers off of all of the chips.
If there's a way to partition the implementation, then my inclination would be to make the external (assumed secure) PIC part of the solution. Is there part of the application that you can offload to the PIC?
I checked and found they(microchip) actually have the ram up to 30k.
One big drawback. There program memory slots are only 24 bits wide. What a headache it would be to encode 32bit instructions in 24bit slots.
Sorry I brought it up!
>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.
> 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?
>Uh oh! What if someone made a full-chip Propeller simulator that had live I/O pins?
I am in total agreement here, a emulator could replace the propeller and thus decrypt everything.
>2) For a ROM-rev'd Propeller, we could use the same $.39 PIC as a dual-keyed cypher that would be placed between the Propeller and EEPROM.
That is too complex. All you need is a little code protected EEPROM space for a secret key inside the Propellor that is not observable by the outside world. in general it is assumed that a hacker has both the cipher and decipher and that the decryption is provided only by the secret knowledge of the key.
Frank
Post Edited (transistortoaster) : 3/22/2007 3:46:14 PM GMT
transistortoaster said...
>The cool thing about #1 is that there is no single attack that could compromise it.
I am just having trouble with the external dongle concept and how it is different. Can't you still just use an emulator with the dongle?
Sure, but what it would it tell you? You would see the program running, but you would have to go about extricating all the dongle checks before you could recreate the system without the dongle. This is where the security lies -- in making someone reverse engineer the code, not just figuring out how to replicate it.
>2) For a ROM-rev'd Propeller, we could use the same $.39 PIC as a dual-keyed cypher that would be placed between the Propeller and EEPROM.
That is too complex. All you need is a little code protected EEPROM space for a secret key inside the Propellor that is not observable by the outside world. in general it is assumed that a hacker has both the cipher and decipher and that the decryption is provided only by the secret knowledge of the key.
While we can't do EEPROM in this process technology, we could do polysilicon·fuses, and·blow them during test. This would require some substantial design changes, but is practical.
Chip,
Thanks for your response. You probably noticed that I hit the edit function for my post, but you may or may not know that I did that before reading your response. i did that in the middle of still analyzing how the dongle would work. Ok, so the whole point is to give a hacker an extra obstacle.
--
Frank
I'm considering using the Propeller for a new version of an existing product. It took a year until a Chinese started to copy concepts of my current version. Not bad, considering it is on the marked since 13 months. *)
But re the serial PIC as a "dongle": This is a very low level protection (except I misunderstood something). It only avoids to make simple copies. The problem is, that the data in the Prop's EEPROM is not encryped and easily accessible. How long will it take until a disassembler is available for the Prop? And then, all is "open source" again.
I guess the compiler for SPIN is more just a tokenizer that would make disassembling the EPROM's data even easier.
The only real solution I see is a internal EEPROM and a copy-protection bit in the Prop. With this solution (also on other platforms) most are happy with and it is hard enough to crack. That copy-protection bit also has to disable any boot-up from external devices (loading code into RAM).
Nick
*) Copying the board is very simply. You can Vero-wire it in 1/2 a day. Parts cost less than I charge, because I have to add my development-time to every board. And I'm *not* selling thousands.
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.
Post Edited (Alex Mackinnon) : 4/9/2007 10:28:24 AM GMT
Alex,
That's essentially the spirit of my 3/22/2007 11:15 AM (GMT -4) post: to put a decryption key that only the propeller can read. With the current version of the propeller, I am trying to find some kind of "gooping", originally suggested by Bambino, to cover the serial lines with a hard epoxy glue that would damage all the surface mount ICs if somebody tries to take it off and get the external eeprom contents..
Frank
Frank, I can not find the exact component order sheet. But, I am 99% sure now(as per my last PM)·that it was from a company named MasterBond. With Chips inspiration to put fuseable encryption keys into PropII the security issue looks pretty secure. You will have to weigh what little protection "Gooping or Potting" might add with the extra heat you are going to retain in the Prop. And this may not apply to your product, but consider the revenue on a service call. If it's been gooped their want be any service calls, and could be defeating the purpose if you plan on making your product field upgradable!
Hmm... is the 32K firmware in the Propeller hard-coded in silicon or is part of the initial 'test' that is done on the chip to programme a PROM or EPROM with the top 32K of data?
If the chip is currently programmed rather than hard-wired then surely there is scope for introducing a protection scheme as I have described?
I'll be happy to send a more detailed description of how it could operate with a low overhead (perhaps 2 or 3 extra instructions in the loading/programming loop) and a small key-size (even as low as 6-bits) to give quite a high level of protection. I don't want to post full details here because a scheme with an unknown algorithm would be much stronger than a heavily publicised one! LOL.
That means there's no easy route to IP protection... it would have to involve a change to the process masks to add some 'unique' identity and the necessary changes to the programme and load functions in the ROM [noparse]:([/noparse]
I was hoping the firmware might be fuse-programmed rather than hard-wired.
It is great to have such a response to a question that is of some importance to me. I think that I need to explain why I need to protect the contents of the program memory.
The reason is simply that I have found the Prop ideally suited for a range of little diagnostic instruments for (mostly)·drive systems and rotating machinery in general.·I have a family of seven instruments and, for financial reasons,·I am not able to produce these instruments myself. To be able to attract a partner, I need to have some sort of protection or the risk capital will be tough to find.
I have been thinking about one other way. All instruments use a display. It will show a splash screen that stays as long as no button is pressed. The splash screen will identify the producer/seller of the instrument. Anyone wanting to copy the instrument will probably want to change that information and look for the ascii. A simple way would be to give him that ascii - somewhere - but not the ascii used for the splash. That ascii will be found somewhere else, but scrambled. There will also be a piece of code that checks the plain ascii to see if it is intact and if not, the thing just won't work.
Of course, there will be disassemblers. But without any variable names and without any labels to help, I frankly do not think it is worth the effort.
BTW. What about my new cap? Got the propeller from my son - he is in model aircraft but also very impressed with the Prop (the chip, I mean).
Not sure if this offers you any hope from code being disassembled but I found embedding data in between executable blocks would often make disassembly very difficult and cause valuable code and data segments to be masked unless the entire code was mapped out one line at a time. When the disassembler sees data it tries to turn that into op-codes. That is where things get crazy. If you put that all into one area you make it easy. If you interleave it into the code it gets very difficult, yet from the source code stand-point the code is not difficult to follow at all. Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Chris Savage Parallax Tech Support
Skogsgurra said...
... It is about putting your company's soul on the market. Many companies have worked many years to develop and perfect solutions to certain problems. Take the alignment of a truck and its wheels after a collision as an example. One company I work with has patented the method (rather high-level math involved) and then continued to refine their method to account for second order and third order effects like springing back and settling when put on the road again. That is experience and know-how - not something that can be patented. Years and years of research and experience goes into that. The method works very well and no other company comes close to the result they get from their computerised alignment benches. A company like that does not want anyone to read the code and clone their products. It is very real ...
I'm rather interested in the discussion going on here, It is helping me with my knowledge on the topic, keep it up guys.
As stated above, security of some technology is worth the time spent figuring securing it. I know of similar "frame racks" that use laser measurements and must admit, if someone could reverse engineer their product and ship it oversees to be made "cheaper" that could be very bad for business. I know this from the manufacturers side... I work for a R&D manufacturing company designing and developing new technology/machinery for the mining industry. Some of the technology we have developed over even just the last few years is awesome for the users. As it is hard for us to prevent reverse engineering of some of our products (everything is pretty much out in the open for you to see) we have to strive to keep ahead of those that want to copy us. Always updating and improving our products, and making them better for assembly and field users.
Getting geared up for a product in which I am hoping to be able to use the propeller chip, this subject is one that has been weighing heavy on my mind also, I am excited to see the vast amount of knowledge and ideas thrown at this topic. Good work guys, keep it up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
HOLY *@Microsoft%@! (sorry for the cuss, I've been trying to clean up my language)
Live, Love, Learn!
My web: www.geocities.com/jet_aj
My Car Audio site: www.jdubaudio.com
I've been reading about the Propeller, and I'm very impressed. But code protection is a deal breaker for me. Without it I can simply not use this chip in commercial products that I design.
The dongle ideas here will not work for me because the code is still unprotected. A competitor could read the EEPROM and decompile the code to see exactly what is happening. I need to prevent competitors from making exact copies of my machines, but I also need to keep them from understanding the steps I take in my firmware to make a machine do what it does.
The only viable solution I see, if the Propeller is never going to have internal program EPROM or Flash, is for the next generation part to have 64 or 128 bits of fuse that I can program permanently into it (and that can not be read out), and then the internal bootloader to have an optional mode to use that key to decrypt code it reads from the EEPROM.
That way the program can be stored in the EEPROM encrypted, so no chance of decompiling it, and it can't simply be copied and used in duplicates of the board without them knowing the key that I programmed into the Propeller.
If I make 1,000 copies of the board, each board must be the same, with the same parts, and parts being interchangeable between boards as well as identical spare parts being on the shelf for repairs. It won't work for me if I have to customize each copy of the EEPROM in some way. And it won't work for me if the code is readable in an unencrypted way from the EEPROM. And potting the boards is not a solution in my eyes.
I'll keep checking back from time to time, hoping that a new version of the Propeller comes out with either protected internal Flash, or an internal encryption scheme where I can burn a key into the part.
Comments
1) For the current Propeller, the most sensible thing would be a one-pin (asynchronous serial) or two-pin (synchronous serial) dongle that acts like a cypher for validation purposes.
2) For a ROM-rev'd Propeller, we could use the same $.39 PIC as a dual-keyed cypher that would be placed between the Propeller and EEPROM.
#1 requires some alteration to your app, while #2 wouldn't. #1 could take only one pin, be simpler to connect, and not interfere the EEPROM interface. I could develop #1 right now. #2 will cost at least $40k to make happen (poly layer mask change, engineering wafer lot, packaging) and bifurcate the Propeller line. The cool thing about #1 is that there is no single attack that could compromise it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
If so, that would be great to know for boards currently in the works.
Is pin multipurpose after boot, or is it sacrificed?
OK, the preaching is over. Now for the coffee that we usually get after sermon (at least here in Sweden). That "Curch-Coffee" used to be where important discussions and decisions took place.
#1 is good enough for me. I presume that, given the flexibility of the Prop, any pin can be used. The loss of one I/O pin could prove fatal in existing designs. But, heck, they are already on the market and those that want to clone have probably already done so.
One possibility would be to use one of the Tx/Rx pins. I guess that they already are free in most cases. Important that normal use doesn't corrupt the dongle.
If this could be done, I would be very happy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
I'm on the open side of things for a lot of reasons. Posted as such, largely to see where people stood on the matter and why. It's all valid, IMHO.
Frankly, this is a good path. I am currently working hard to grok the prop because I like the design and I think it's significant, given the current direction computing in general is heading. Open, closed, whatever, it's all seriously fun and powerful stuff!
It's in our mutual best interests to see this matter closed with a viable solution. More props in the market means more that we all can leverage toward our goals. It also means more dollars for Parallax and that makes them stronger in the market, thus we will see a great design evolve into an excellent one.
That's it really. Just thought I would put a coupla my earlier posts in context.
One nice thing about this path, is that any prop can still be repurposed at some point in the future. Unless I'm missing something, that is... Many years from now, that's gonna matter for those wanting to tinker as we are today.
It·could connect to any pin, but P29 (EEPROM's SDA) might be optimal to use, since it's free. This device has a flash ROM that must be programmed. We could make a stand-alone Propeller-based programmer that could program the device in-circuit or out-of-circuit. In-circuit programming would require 4 pin·connections. The connector would take a lot more space than the chip, itself. Programming it before assembly would make things wind up tidier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 3/19/2007 3:22:33 AM GMT
1) I cannot get the Propeller to generate a random number on power-up. Even using the internal free-running·~20KHz clock as a 'random' clock-switchover delay,·things are remarkably repeatable. Without the means to generate a random number, the cypher conversation·would be·routine and prone to a record/playback attack. To get around this, the Propeller's attached EEPROM could be used as a non-volatile counter to keep the cypher conversation from repeating, but this would force more complexity, requiring I2C routines. The effects of changing the EEPROM could be easily detected and reset, anyway.
2) Those 6-pin PICs pose some real logistical headaches·when it comes to·inserting·the application and master·key at program time. Either they get programmed before assembly, throwing a wrench into an otherwise-automated assembly process, or they must be·programmed afterwards via some in-circuit programming tool. A $.67 PIC12F629 in an 8-pin·package could be used, instead, which would have some internal data EEPROM, greatly simplifying this process. One dongle app could be written, programmed into the devices·at Microchip's factory, and then key-customized in a two-step Propeller downloading process (first to RAM to run the key-customizer, then to EEPROM for the final application code). This would be much cleaner, logistically, but cost a little more and take more space.
3) The lack of means to generate a random number on the Propeller on power-up is perhaps a fundamental obstacle to·security. The PIC could be employed to use its WDT to halt a software count routine, but the·resulting count·might only vary with temperature changes. Assuming the PIC could generate a random number, it could then convey it to the Propeller. No external pins can be employed in the random number generator (on either chip) because they could be tampered with in order to make the random number a constant. One thing's for sure: the next Propeller is going to have some kind of internal noise generator from which real random numbers could be gleaned.
This is going to require some more consideration. If we could make a random number on power-up on the Propeller, and use a PIC with internal data EEPROM, the system could be fairly elegant, but not nearly as tidy as a 'protect' bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 3/19/2007 9:08:01 AM GMT
The DIP PIC10F200 would be convenient, use a dedicated programmer board, then move it over. It is twice the cost. Digi has quite a few.
Post Edited (originator) : 3/19/2007 9:19:01 AM GMT
Phil Pilgrim had a good idea for using a few resistors and pins in the CTR's ADC mode, and sampling them periodically. He was getting apparently random results.·That's a few more pins, though.
It would just be ideal if this could be done completely inside the chip. There might be some way to do this, like bouncing·a CTR's·PLL around and then sampling its output. Yeah! That's the next thing to look into... the PLL! It's extremely non-digital and probably fertile grounds for 'randomosity'.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 3/19/2007 9:37:22 AM GMT
Go to bed, dude!
'Turns out that one 100K resistor between pins and a 220pF to ground works better than two resistors for random number generation. But, yes, two pins get wasted (although in some apps, the same pins could be used for other purposes once a random seed is generated). I like the PLL idea. Anything with an analog component should work.
I wonder if Microchip's KEELOQ rolling code products might find application here, BTW.
-Phil
datasheets.maxim-ic.com/en/ds/MAX4562-MAX4563.pdf
So, the Propeller CAN generate random numbers on power-up, after all, without any external circuitry. And it can do it off the ~12MHz internal oscillator, as well. I should have some code to post tomorrow.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Like I said "I don't no if it's worth it, but hay, it's food for thought!
PS.
If placed transparently on the progamming connection after boot up the 2 uart lines and the free I2C lines along with one clk pin you could then have a 4 bit bus capable of useing the dsPIC's Ram. (Up to 16K on some models I think.)
Or optionally make use of their Periphials.
Compared to the current configuration thats a loss of one pin!
Post Edited (bambino) : 3/20/2007 2:17:41 PM GMT
If there's a way to partition the implementation, then my inclination would be to make the external (assumed secure) PIC part of the solution. Is there part of the application that you can offload to the PIC?
One big drawback. There program memory slots are only 24 bits wide. What a headache it would be to encode 32bit instructions in 24bit slots.
Sorry I brought it up!
> a) It means a boot routine must be used which could be easily captured.
> 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?
>Uh oh! What if someone made a full-chip Propeller simulator that had live I/O pins?
I am in total agreement here, a emulator could replace the propeller and thus decrypt everything.
>2) For a ROM-rev'd Propeller, we could use the same $.39 PIC as a dual-keyed cypher that would be placed between the Propeller and EEPROM.
That is too complex. All you need is a little code protected EEPROM space for a secret key inside the Propellor that is not observable by the outside world. in general it is assumed that a hacker has both the cipher and decipher and that the decryption is provided only by the secret knowledge of the key.
Frank
Post Edited (transistortoaster) : 3/22/2007 3:46:14 PM GMT
Chip Gracey
Parallax, Inc.
Thanks for your response. You probably noticed that I hit the edit function for my post, but you may or may not know that I did that before reading your response. i did that in the middle of still analyzing how the dongle would work. Ok, so the whole point is to give a hacker an extra obstacle.
--
Frank
Sorry for dropping in!
I'm considering using the Propeller for a new version of an existing product. It took a year until a Chinese started to copy concepts of my current version. Not bad, considering it is on the marked since 13 months. *)
But re the serial PIC as a "dongle": This is a very low level protection (except I misunderstood something). It only avoids to make simple copies. The problem is, that the data in the Prop's EEPROM is not encryped and easily accessible. How long will it take until a disassembler is available for the Prop? And then, all is "open source" again.
I guess the compiler for SPIN is more just a tokenizer that would make disassembling the EPROM's data even easier.
The only real solution I see is a internal EEPROM and a copy-protection bit in the Prop. With this solution (also on other platforms) most are happy with and it is hard enough to crack. That copy-protection bit also has to disable any boot-up from external devices (loading code into RAM).
Nick
*) Copying the board is very simply. You can Vero-wire it in 1/2 a day. Parts cost less than I charge, because I have to add my development-time to every board. And I'm *not* selling thousands.
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.
Post Edited (Alex Mackinnon) : 4/9/2007 10:28:24 AM GMT
That's essentially the spirit of my 3/22/2007 11:15 AM (GMT -4) post: to put a decryption key that only the propeller can read. With the current version of the propeller, I am trying to find some kind of "gooping", originally suggested by Bambino, to cover the serial lines with a hard epoxy glue that would damage all the surface mount ICs if somebody tries to take it off and get the external eeprom contents..
Frank
If the chip is currently programmed rather than hard-wired then surely there is scope for introducing a protection scheme as I have described?
I'll be happy to send a more detailed description of how it could operate with a low overhead (perhaps 2 or 3 extra instructions in the loading/programming loop) and a small key-size (even as low as 6-bits) to give quite a high level of protection. I don't want to post full details here because a scheme with an unknown algorithm would be much stronger than a heavily publicised one! LOL.
The 32K ROM is just that, a mask programmed ROM, hard-coded in silicon.
That means there's no easy route to IP protection... it would have to involve a change to the process masks to add some 'unique' identity and the necessary changes to the programme and load functions in the ROM [noparse]:([/noparse]
I was hoping the firmware might be fuse-programmed rather than hard-wired.
The reason is simply that I have found the Prop ideally suited for a range of little diagnostic instruments for (mostly)·drive systems and rotating machinery in general.·I have a family of seven instruments and, for financial reasons,·I am not able to produce these instruments myself. To be able to attract a partner, I need to have some sort of protection or the risk capital will be tough to find.
I have been thinking about one other way. All instruments use a display. It will show a splash screen that stays as long as no button is pressed. The splash screen will identify the producer/seller of the instrument. Anyone wanting to copy the instrument will probably want to change that information and look for the ascii. A simple way would be to give him that ascii - somewhere - but not the ascii used for the splash. That ascii will be found somewhere else, but scrambled. There will also be a piece of code that checks the plain ascii to see if it is intact and if not, the thing just won't work.
Of course, there will be disassemblers. But without any variable names and without any labels to help, I frankly do not think it is worth the effort.
BTW. What about my new cap? Got the propeller from my son - he is in model aircraft but also very impressed with the Prop (the chip, I mean).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
I'm rather interested in the discussion going on here, It is helping me with my knowledge on the topic, keep it up guys.
As stated above, security of some technology is worth the time spent figuring securing it. I know of similar "frame racks" that use laser measurements and must admit, if someone could reverse engineer their product and ship it oversees to be made "cheaper" that could be very bad for business. I know this from the manufacturers side... I work for a R&D manufacturing company designing and developing new technology/machinery for the mining industry. Some of the technology we have developed over even just the last few years is awesome for the users. As it is hard for us to prevent reverse engineering of some of our products (everything is pretty much out in the open for you to see) we have to strive to keep ahead of those that want to copy us. Always updating and improving our products, and making them better for assembly and field users.
Getting geared up for a product in which I am hoping to be able to use the propeller chip, this subject is one that has been weighing heavy on my mind also, I am excited to see the vast amount of knowledge and ideas thrown at this topic. Good work guys, keep it up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
HOLY *@Microsoft%@! (sorry for the cuss, I've been trying to clean up my language)
Live, Love, Learn!
My web: www.geocities.com/jet_aj
My Car Audio site: www.jdubaudio.com
The dongle ideas here will not work for me because the code is still unprotected. A competitor could read the EEPROM and decompile the code to see exactly what is happening. I need to prevent competitors from making exact copies of my machines, but I also need to keep them from understanding the steps I take in my firmware to make a machine do what it does.
The only viable solution I see, if the Propeller is never going to have internal program EPROM or Flash, is for the next generation part to have 64 or 128 bits of fuse that I can program permanently into it (and that can not be read out), and then the internal bootloader to have an optional mode to use that key to decrypt code it reads from the EEPROM.
That way the program can be stored in the EEPROM encrypted, so no chance of decompiling it, and it can't simply be copied and used in duplicates of the board without them knowing the key that I programmed into the Propeller.
If I make 1,000 copies of the board, each board must be the same, with the same parts, and parts being interchangeable between boards as well as identical spare parts being on the shelf for repairs. It won't work for me if I have to customize each copy of the EEPROM in some way. And it won't work for me if the code is readable in an unencrypted way from the EEPROM. And potting the boards is not a solution in my eyes.
I'll keep checking back from time to time, hoping that a new version of the Propeller comes out with either protected internal Flash, or an internal encryption scheme where I can burn a key into the part.