that translates to 344 wires that are just over one quarter of a micron wide. And even then the "core" is nothing but a mass of logic gates. The fuse bits themselves are not in any particular visual order that would correspond to the bit that was blown. So in order to even determine the correct mapping that correlates to the selected bits that were blown, you would need to probe 172 Propeller chips each with only one of their bits blown.
So 250nm wide traces and fuses that are 180nm wide + heat effected zone? (the heat effected zone could be relatively large though) That's too small for an optical (~530nm) microscope to resolve, a UV, X-ray, or electron microscope would be need. So this would be harder than hacking older smart card fuse bits. (I think the http://www.flylogic.net/blog/ gives a good idea what a microchip reverse engineering lab can do) Shuffling the fuse bits on the die should help, but I'd still expect knowing what bits made up the key to dramatically reduce the key search space. Similarly, every bit that gets it's circuit traced would cut the key search space in half. I.e. if a chip gets de-capped and the fuse bits read it's game over no matter what's done with the circuit.
@Circuitsoft: If the eeprom is unencrypted but potted, I could dig down to the eeprom data lines with a dremmel, and solder on my own leads. Using encryption ideally forces the attacker to go looking inside the microchip for the key, significantly raising the cost/complexity of an attack. (or they have to go after the developer for the key or source)
I know a solution: Ship your product with a personal army for its protection. The cost will increase *slightly* but it will be secure, at least, against anyone else without their own personal army.
Some tanks and planes for extra protection will surely discourage hackers.
Thanks Beau. I just wanted to be sure that it was not going to be easy for anyone to look at the chip to discover the fuse settings.
There has to be some presumptions made to make it worthwhile for hacking...
The product has a "huge" markup so the hackers want to build their own cheap version...
They have to buy 172 "expensive" products to hack the key (maybe less with some brute force too), provided they don't destroy some props in the process.
Hackers want to "break" the decryption for the joy of it
Most likely they will hack with brute force.
A competitor wants to "steal" the knowledge/code for their own product...
They have to buy 172 opposition products to hack the key (as above)
And of course, in each of the above cases, they only get one key, so only one product is broken. Unless the algorithm is cracked by a weakness.
Therefore, IMHO, it will come down to the algorithm.
Oh, and if you are a big user with a single product, you can always get Parallax to build you a semi custom chip that just uses a slightly different ROM
I agree that some bright young cracker might want to tackle the Prop II security. Not for any financial gain but just as a challenge. Like some people do crossword puzzles others tackle DVD/CSS and such like. It's a challenge.
However I suspect if they are up against a decent hash/cypher with 128 bit keys brute force is the last approach they would take, they know it's going to take forever. Probably rather be sniffing around for side/covert channel attacks or getting into the dev tools to pull keys out.
What if someone discovers, for example, that blipping the power off at just the right moment for just long enough causes the key reading lock to become undone.
It does not come down to just the algorithm, which we might assume is bullet proof, but to the entire implementation from chip to dev tools.
So in order to even determine the correct mapping that correlates to the selected bits that were blown, you would need to probe 172 Propeller chips each with only one of their bits blown.
Actually I'd bet the correct fuse to bit mapping could be estimated by programming 16 chips with random fuse patterns and applying compressed sensing or other similar techniques to estimate the mapping.
Nope. Compressed sensing applies to linear systems. The SHA hash isn't even remotely linear. Even if you were off on your guess of the key by only one bit, the SHA hash would be completely different, offering no clue. That's what makes it so secure.
They have to buy 172 "expensive" products to hack the key (maybe less with some brute force too), provided they don't destroy some props in the process.
A competitor wants to "steal" the knowledge/code for their own product...
They have to buy 172 opposition products to hack the key (as above)
Not entirely correct.
Assuming that the blown fuses show up in a scan of proper magnification(x-ray, electron microscope, Photon-readers illegaly imported from Beta Aurigae), what is needed is to know which 'crater' maps to which bit. This mapping can be found by buying a lot of cheap Propeller IIs and blowing fuses on them, then scanning them.
That creates the 'map'. Then you just need to sample ONE expensive product from your competitor , scan it and compare it to the map.
Defenses against that would be some sort of randomisation?
Several different layouts used in the production process? How many chips do you get on a single wafer? In theory you could make all of them different. Unfortunately, that's a big danger of 99% screwup, too
Different mask for different production runs? Again, big danger of screwup.
Maybe the logic around the fuses changes depending on whether or not certain key fuses have been blown or not? I'm seeing massive routing problems...
Boy this thread sure contains a lot of effort protecting CODE but not the actual Idea or Concept which makes your product unique. With very few exceptions, albeit exceptions none the less, what makes a product valuable is what it does more so than how the bits are twiddled.
Some methods of programming may be more efficient than others but the micro only has a few op codes so I believe more effort needs to be expended getting congress critters to enhance Patent Laws to actually protect the entire product which by default protects the code. Some how, some way, we have let our various governments protect a song or piece of music or video via copy-write for a longer term than patents.
This entire thread just shows, no matter what you do, there is a way around it. We need to see more perp walks and much more punitive fines for the scum of the earth who have been effectively allowed to steal the work of others. I'd rather spend my time creating a new "do funny" using the Prop than countless hours preventing some scum from stealing it. That is what government is for and maybe the engineering world needs a strong arm group like the recording industry to force government to do its job.
I do wonder if the demand for code protection is mostly so that people can steal other peoples code without them finding out about it...
Maybe it's 1/2 and 1/2...
... They have to buy 172 opposition products to hack the key (as above)...
Ah, no.
The 172 Props is a one off purchase of virgin Propellor chips. This is purely to solve for where each bit value is geo-located by fuse. After that, every programmed key can be viewed exactly on a per chip basis.
Don't forget: there are stiff penalties for burglary, but we still put locks on our doors to discourage the less-determined would-be thieves. Plus, Parallax would not be going to all this trouble if their OEM customers weren't demanding it.
I have the opposite problem - people see my code, feel sorry for me and try to load something good into my Propeller!
From the hobbyist perspective, I can't see a need for code protection but the fuses could prove interesting. From the Parallax perspective, it's something that needs to be done and done effectively to be competitive but that's all been covered here (again and again) by smarter minds than mine.
I see the target spec is getting long in the tooth, from way back in November 2011
When will the final Memory sizes, MHz (modeled), and more complete details on the Counter improvements be documented ?
details like Quadrature/Up/Down/Capture/External Clock modes and speeds ?
The TILE-Gx36 processor features 36 64-bit cores running at 1.0 to 1.5 GHz and five independent mesh networks. In networking applications, a single TILE-Gx36 can deliver more than 40 Gbits/s of L2/L3 packet-forwarding performance, across small and large packet sizes, using less than 25 W.
The 40-nm chip has demonstrated an industry-best CoreMark score of over 165,000 and has 12 Mbytes of cache and two 72-bit DDR3 controllers with ECC. It has two 10-Gbit/s XAUI ports, four 10/100/1000 SGMII ports, IEEE1588v2 timing support, and three Gen2 PCIe controllers. It comes in a 37.5 x 37.5-mm BGA1265 package. ($650 ea/sample available now.)
Or this, for even more (100) cores...["ZMS-40 is part of a family of SoCs based on a "stem cell-like" architecture. The latest chip doubles the performance or halves the power consumption of the earlier ZMS-20. The chip includes 96 StemCell media processing cores together with a 1.5-GHz quad-core ARM Cortex-A9"] http://hexus.net/tech/news/cpu/33381-new-100-core-chinese-ziilabs-zms-40-arm-soc-demoing-ces/
I see the target spec is getting long in the tooth, from way back in November 2011
When will the final Memory sizes, MHz (modeled), and more complete details on the Counter improvements be documented ?
details like Quadrature/Up/Down/Capture/External Clock modes and speeds ?
Yes, I too would like to know if there is any updated specifications.
I see the target spec is getting long in the tooth, from way back in November 2011
When will the final Memory sizes, MHz (modeled), and more complete details on the Counter improvements be documented ?
details like Quadrature/Up/Down/Capture/External Clock modes and speeds ?
@jmg: I don't want to start a thread with non-information. However, when the new specs are actually posted we'll be sure that everybody knows they exist.
But I appreciate your point - you're tempting me with the marketing angel on one shoulder and the engineer over the other.
This isn't about code protection, but i had a question about the planned 32bit SDRAM interface... It says(On the Prop 2 spec sheet) that it supports data only and not program code. First off, does the system have built in commands to handle driving the SDRAM(Refreshing, Chip select, write protect...etc) or will the user have to come up with his own code? Second, when you say data only, will there be any special command to handle data transfer to the SDRAM chip and will speed be affected? And lastly, do you all plan on making a dev board that utilizes this interface? I think it is a good idea and could open up quite a few ideas. Can anybody say Propeller PC?:)
@Ravenkallen: yes, the Propeller 2 evaluation board will include an SDRAM. We've talked already about the board design and we're getting it in the queue well before we have chips in hand. Parallax Semiconductor will produce one full-featured, high-quality evaluation board (perhaps form factor of the PropBOE) and support the key external board builders to succeed with the variations that make us all happy.
I'm pretty sure that Chip will author the core code examples and they'll grow from his work.
One big open question is Prop II Spin. Who will write the specs for it, and who will author the support software (compiler and IDE) for it? No EVM is complete without Spin support, after all!
One big open question is Prop II Spin. Who will write the specs for it, and who will author the support software (compiler and IDE) for it? No EVM is complete without Spin support, after all!
-Phil
Hey Phil - Chip will need to confirm but I'll provide my understanding. Propeller 2 Spin specs will come from Chip and key internal people like Jeff with an extended team of contributors on these forums with whom Chip frequently interacts. You already know all of them. I'm sure Chip will write the compiler, possibly with a C/C++ translation being immediately available with the help of Roy. The IDE is possibly an open issue, to be honest. We're taking a look at some of the multi-platform, open-source alternatives right now to see if they could be adopted for the long term. Though I realize you're happy with our current Delphi version, I am trying to identify a long-term solution that doesn't have us bound to licensed code and Windows. If successful, Propeller 1 and 2 with Spin would reside in the same IDE [open-source, compatible with Windows, Mac and Linux].
The C tools are shaping up nicely already. We'll be using SimpleIDE for the PropGCC beta test (possibly longer) and Eclipse for the professional version. A Spin plug-in for Eclipse is also a possibility. This whole toolchain is open-source and runs on Windows, Mac and Linux.
We'll have the Spin plan resolved as soon as possible. Don't worry, Phil - that's where Chip's heart is.
[QUOTE=Ken Gracey;1076191..Though I realize you're happy with our current Delphi version, I am trying to identify a long-term solution that doesn't have us bound to licensed code and Windows. If successful, Propeller 1 and 2 with Spin would reside in the same IDE [open-source, compatible with Windows, Mac and Linux].
[/QUOTE]
If you have a working Delphi version, have you looked at FreePascal/Lazarus/fpGUI (etc) which should be less effort than a re-write ?
@Ken...The propeller 2 evaluation board sounds cool, but expensive...I hope there are simple proto boards available (early)...I really do not want to solder chips
Comments
So 250nm wide traces and fuses that are 180nm wide + heat effected zone? (the heat effected zone could be relatively large though) That's too small for an optical (~530nm) microscope to resolve, a UV, X-ray, or electron microscope would be need. So this would be harder than hacking older smart card fuse bits. (I think the http://www.flylogic.net/blog/ gives a good idea what a microchip reverse engineering lab can do) Shuffling the fuse bits on the die should help, but I'd still expect knowing what bits made up the key to dramatically reduce the key search space. Similarly, every bit that gets it's circuit traced would cut the key search space in half. I.e. if a chip gets de-capped and the fuse bits read it's game over no matter what's done with the circuit.
@Circuitsoft: If the eeprom is unencrypted but potted, I could dig down to the eeprom data lines with a dremmel, and solder on my own leads. Using encryption ideally forces the attacker to go looking inside the microchip for the key, significantly raising the cost/complexity of an attack. (or they have to go after the developer for the key or source)
Lawson
Some tanks and planes for extra protection will surely discourage hackers.
There has to be some presumptions made to make it worthwhile for hacking...
- The product has a "huge" markup so the hackers want to build their own cheap version...
- They have to buy 172 "expensive" products to hack the key (maybe less with some brute force too), provided they don't destroy some props in the process.
- Hackers want to "break" the decryption for the joy of it
- Most likely they will hack with brute force.
- A competitor wants to "steal" the knowledge/code for their own product...
- They have to buy 172 opposition products to hack the key (as above)
And of course, in each of the above cases, they only get one key, so only one product is broken. Unless the algorithm is cracked by a weakness.Therefore, IMHO, it will come down to the algorithm.
Oh, and if you are a big user with a single product, you can always get Parallax to build you a semi custom chip that just uses a slightly different ROM
I agree that some bright young cracker might want to tackle the Prop II security. Not for any financial gain but just as a challenge. Like some people do crossword puzzles others tackle DVD/CSS and such like. It's a challenge.
However I suspect if they are up against a decent hash/cypher with 128 bit keys brute force is the last approach they would take, they know it's going to take forever. Probably rather be sniffing around for side/covert channel attacks or getting into the dev tools to pull keys out.
What if someone discovers, for example, that blipping the power off at just the right moment for just long enough causes the key reading lock to become undone.
It does not come down to just the algorithm, which we might assume is bullet proof, but to the entire implementation from chip to dev tools.
Actually I'd bet the correct fuse to bit mapping could be estimated by programming 16 chips with random fuse patterns and applying compressed sensing or other similar techniques to estimate the mapping.
Lawson
-Phil
Not entirely correct.
Assuming that the blown fuses show up in a scan of proper magnification(x-ray, electron microscope, Photon-readers illegaly imported from Beta Aurigae), what is needed is to know which 'crater' maps to which bit. This mapping can be found by buying a lot of cheap Propeller IIs and blowing fuses on them, then scanning them.
That creates the 'map'. Then you just need to sample ONE expensive product from your competitor , scan it and compare it to the map.
Defenses against that would be some sort of randomisation?
Several different layouts used in the production process? How many chips do you get on a single wafer? In theory you could make all of them different. Unfortunately, that's a big danger of 99% screwup, too
Different mask for different production runs? Again, big danger of screwup.
Maybe the logic around the fuses changes depending on whether or not certain key fuses have been blown or not? I'm seeing massive routing problems...
Some methods of programming may be more efficient than others but the micro only has a few op codes so I believe more effort needs to be expended getting congress critters to enhance Patent Laws to actually protect the entire product which by default protects the code. Some how, some way, we have let our various governments protect a song or piece of music or video via copy-write for a longer term than patents.
This entire thread just shows, no matter what you do, there is a way around it. We need to see more perp walks and much more punitive fines for the scum of the earth who have been effectively allowed to steal the work of others. I'd rather spend my time creating a new "do funny" using the Prop than countless hours preventing some scum from stealing it. That is what government is for and maybe the engineering world needs a strong arm group like the recording industry to force government to do its job.
Maybe it's 1/2 and 1/2...
Ah, no.
The 172 Props is a one off purchase of virgin Propellor chips. This is purely to solve for where each bit value is geo-located by fuse. After that, every programmed key can be viewed exactly on a per chip basis.
No but it sure helps:)
-Phil
From the hobbyist perspective, I can't see a need for code protection but the fuses could prove interesting. From the Parallax perspective, it's something that needs to be done and done effectively to be competitive but that's all been covered here (again and again) by smarter minds than mine.
I see the target spec is getting long in the tooth, from way back in November 2011
When will the final Memory sizes, MHz (modeled), and more complete details on the Counter improvements be documented ?
details like Quadrature/Up/Down/Capture/External Clock modes and speeds ?
What a 'beast'. Low Power? Not at 25 W. 36 'cogs'? Not less than $100 for sure. And ball-grid!
URL = http://forums.parallax.com/showthread.php?125543-Propeller-II-update-BLOG&p=1076066#post1076066
Low-power 64-bit processors have 36 cores
The TILE-Gx36 processor features 36 64-bit cores running at 1.0 to 1.5 GHz and five independent mesh networks. In networking applications, a single TILE-Gx36 can deliver more than 40 Gbits/s of L2/L3 packet-forwarding performance, across small and large packet sizes, using less than 25 W.
The 40-nm chip has demonstrated an industry-best CoreMark score of over 165,000 and has 12 Mbytes of cache and two 72-bit DDR3 controllers with ECC. It has two 10-Gbit/s XAUI ports, four 10/100/1000 SGMII ports, IEEE1588v2 timing support, and three Gen2 PCIe controllers. It comes in a 37.5 x 37.5-mm BGA1265 package. ($650 ea/sample available now.)
[/OFF-TOPIC]
http://hexus.net/tech/news/cpu/33381-new-100-core-chinese-ziilabs-zms-40-arm-soc-demoing-ces/
and an example of what it can build...
http://asia.cnet.com/creative-targets-chinas-tablet-market-with-its-hanzpad-62213439.htm
Price ?
Cute 'holding devices' pictured for the HanZpad units, huh? ( your second reference) Enough of these distractions from programming....
Yes, I too would like to know if there is any updated specifications.
We will release updated specifications at http://www.parallaxsemiconductor.com/Products/propeller2specs on March 6, 2012.
Ken Gracey
Great - perhaps that firm date could go in its own thread, so it does not get lost in the chatter here ?
But I appreciate your point - you're tempting me with the marketing angel on one shoulder and the engineer over the other.
Ken Gracey
I'm pretty sure that Chip will author the core code examples and they'll grow from his work.
Ken Gracey
One big open question is Prop II Spin. Who will write the specs for it, and who will author the support software (compiler and IDE) for it? No EVM is complete without Spin support, after all!
-Phil
Hey Phil - Chip will need to confirm but I'll provide my understanding. Propeller 2 Spin specs will come from Chip and key internal people like Jeff with an extended team of contributors on these forums with whom Chip frequently interacts. You already know all of them. I'm sure Chip will write the compiler, possibly with a C/C++ translation being immediately available with the help of Roy. The IDE is possibly an open issue, to be honest. We're taking a look at some of the multi-platform, open-source alternatives right now to see if they could be adopted for the long term. Though I realize you're happy with our current Delphi version, I am trying to identify a long-term solution that doesn't have us bound to licensed code and Windows. If successful, Propeller 1 and 2 with Spin would reside in the same IDE [open-source, compatible with Windows, Mac and Linux].
The C tools are shaping up nicely already. We'll be using SimpleIDE for the PropGCC beta test (possibly longer) and Eclipse for the professional version. A Spin plug-in for Eclipse is also a possibility. This whole toolchain is open-source and runs on Windows, Mac and Linux.
We'll have the Spin plan resolved as soon as possible. Don't worry, Phil - that's where Chip's heart is.
Ken Gracey
huasheng, welcome to the forums!
No, the two guys don't have another year for development. We're winding it up soon.
Ken Gracey
[/QUOTE]
If you have a working Delphi version, have you looked at FreePascal/Lazarus/fpGUI (etc) which should be less effort than a re-write ?
Ken,
Could you tell us what hardware might be coming up after the Prop II ?