The forum is the best kind of copy protection there is. Keep up the debate and without a P2 there is nothing to copy. See, best kind.
If though I developed a product that could realize huge profits/volume I could then talk $$$$$$ to Parallax about a copy protected version. But I mean huge.
btw, I have reverse engineered product (though not to copy) even when the chip origin is obscured. When you know which pins the crystal and power are connected to then it's a matter of trawling through likely candidates until eventually you find a match.
1. How accurate is the internal ~20MHz RC oscillator? From datasheets I've looked at, 20MHz seems to be the maximum frequency for SPI EEPROMs. Would 20MHz/2 be safer?
The SPI clock is (much) slower than RCFAST, - but most of the intended Flash SPI parts can manage 80~104MHz, so either way, 20MHz is not an issue...
(a) is not a difficult software problem and doesn't need fuses. The boot ROM could support encrypted SPI EEPROMs if that would increase sales, e.g. by using public key encryption. The Parallax private key would not be readable by users and unless it was leaked or the mask ROM was read, the encryption would be secure.
I suggested that many moons ago. The problem is, as others have pointed out, that a single secret, once revealed -- and it will be -- screws it for everyone.
well my take here is that @chip thinks in different ways as usual technical terms provide. Now he needs assurance from us, not criticism.
Sure it's a bad hit with 8 instead of 16 Cogs. That drained a lot out of the fun finishing it finally. But it is like it is. And it's still a wonderful MC. Or will be, hopefully.
A compromise would be to leave the actual fuses there, but not the boot support.
So if anyone REALLY needs protection he could burn pre fabrication some serial numbers with a 1/400 failure rate. pre soldering 5V supply does not matter.
And has some valid/notvalid serial number for the software.
...
..A compromise would be to leave the actual fuses there, but not the boot support...
That's an interesting technical idea, and may be close to what Chip has actually done, given the PAD-Ring layout that contains the fuses, is already completed and is not in Verilog.
ie True total physical fuse removal is not likely.
Commercially, however, that might not work so well, as it risks making the device look half-baked, and it has an associated support cost.
I completely removed the fuses from the Prop2 today. Even if we could have blown them reliably, 1 in 400 are known to fail, anyway. Even using them redundantly doesn't give us the level of reliability we'd need, before our key size would drop to a level that everyone would complain about. In the worst case, these fuses could cripple the chip by some accidental blowing during core brown-out, or some other unlikely, but possible, scenario. It's just too much risk. ... Meanwhile, there's no potential for ugly gotcha's during development and a Prop2 can't get "bricked".
Seems the risks of accidental brownout-blow, and bricking devices are foremost.
If the ROM skips all fuse-gateways, that avoids No-Boot-bricking, but it may still have some risk of the Serial Number being modified "by some accidental blowing during core brown-out, or some other unlikely, but possible, scenario." - maybe that can be mitigated with a 'secure' fuse set of maybe 4, that hardware disables all further fuse flow. (any one of the 4 secure fuses blown, prevents any further change)
That could allow Parallax to offer a Unique Serial number ID.
We need to thing of code protect in terms of verbs and not nouns, like eveything else uses.
So no articles, adjectives, or adverbs? How about verb tenses - is the subjunctive tense not allowed? If there _were_ secure fuses...
Anyways I'm not sure what this post was intended to mean.
I meant "think", but my phone heard "thing".
My point was that there's a prevailing assumption that security must be about a special key (noun), but perhaps some interaction (verb) could be used to achieve security, instead. If you can get cheap "secure" micros with many KB of flash, you may be able to get the secret object code into the Prop without it being practically discoverable.
Standard procedure is to make the code physically inaccessible. But that requires embedding the storage on die.
Aside from the already discussed fab line limitation, such an approach is not very viable when every spare space is already needed. We'd be sacrificing other parts of the Prop2 to fit in a block of Flash say.
The way I see it, that leaves obfuscation or cryptographic keys. Both require the ability to be adaptable to being cracked. Which means the method can't be solely a mask ROM solution.
In the case of a key, it has to be replaceable if discovered.
In the case of obfuscation, the method itself has to be thrown away each time it's cracked.
Modern SPI Flash chips have a factory programmed unique serial number and an area to store user configuration data independently from the normal memory sectors (SFDP, 256 bytes).
From Winbond Datasheet:
"The Read Unique ID Number instruction accesses a factory-set read-only 64-bit number that is unique to each W25Q32FV device. The ID number can be used in conjunction with user software methodes to help prevent copying or cloning of a system."
Such a Flash chip is anyway required for the P2, so there is no additional chip necessary to install some simple protection against cloning.
Good point, Andy. That could be a solution right there.
To prevent cloning, it could be as simple as this:
Before compiling the user's code, the Prop2 tool discovers the unique ID of the flash chip in the target system. That ID value is assigned to a global constant before compiling the user's program. The user's program verifies that value any number of ways within his code at run time. He doesn't operate if he discovers a problem.
Having no experience with code protection to base this on, my first instinct would be to use the cheap micro mentioned before that can be programmed first. Then program the Prop. This is a crude idea:
Prop on boot sends 100 random numbers to the cheap micro.
Cheap micro performs some math on all the numbers and returns the numbers not in the same order, and mixes in some random numbers it generates in positions that will be ignored.
The Prop knows what order the numbers will be returned and what position to look for specific numbers and checks the math that was done from the other side.
There can be for multiple schemes the cheap micro uses to affect the numbers, choosing a scheme based on the checksum, ie if checksum > 0 and < 32 use scheme a, if checksum > 32 and < 64 then use scheme b. So the checksum affects how the cheap micro will operate and the order the values are returned.
I am sure there are better schemes than this but to my thinking this would be some effort for someone to solve.
That ID value is assigned to a global constant before compiling the user's program.
Better to not have the number discoverable in the binary. Use various other numbers in constants that can be calculated by some method on boot to arrive at the ID. If someone analyzed several P2 eeproms they could see the minor variance if there is only one item changing per compile.
write a buggy program... The problem is: if good code is protected, only bad code will be reused and we will end up, where we are now. MAGA is not a question of protection, but of being competitive! Then stocks will go up as they do in Europe.Reused term: Make another good application
TC,
The critical detail there is that's the system developer's ("user" from Chip's perspective) code that is doing this. The Prop2 has nothing in the ROM or hardware design to handle any part of the protection.
It's the obfuscation route. It's what's commonly used in computer games. It's good enough for most situations because it can be redone for every release. Making it a moving target.
Good point, Andy. That could be a solution right there.
To prevent cloning, it could be as simple as this:
Before compiling the user's code, the Prop2 tool discovers the unique ID of the flash chip in the target system. That ID value is assigned to a global constant before compiling the user's program. The user's program verifies that value any number of ways within his code at run time. He doesn't operate if he discovers a problem.
How about die stacking to provide both:
a. boot flash die and
b. a second smaller boot flash die which contains just the serial number and / or private decryption key.
The boot flash dies would have high spi addresses for A1,A2 and A3.
The smaller boot flash die can only be read by the boot ROM, a copy of the key would be kept in special register which can only be accessed by code in boot rom space, or copy thereof (1-400?). A mechanism (instruction) to load overlays by re-invoking a decryption routine in the boot loader code which is still in memory, uses the copy of the key to decrypt once more.
This overlay instruction may only be executed from boot rom code space (copy in ram). If the boot rom code space is overwritten, the overlay instruction execution is disabled (by a ff which is reset on reset) to prevent pilferring of the encryption key. This would require comparing hubexec write addresses 1 through 400 and non-long addresses only? ie ( addr & ff800 == 0 ) & ( ( addr & 3 ) != 0 )
I think this would provide full encryption, and reduce BOM count, though at greater cost. It would still be possible to have external flash or sd card connected as is currently the case, simply program the internal boot flash die to start with 0.
The smaller boot flash is read on hardware reset.
If no connection on serial interface for programming, ie booting an application:
if the first location is zero, no encryption, otherwise use subsequent locations as the private decryption key.
if the first location of the boot flash dies is zero, boot externally else
decrypt the internal boot flash to propeller ram.
If connection on serial interface for programming:
the private encryption / decryption key can be provided via the loader software by the user, and the encryption with the public key can also be performed at that point, or by the propeller ram-resident loader software. The key would be written to smaller flash die, the encypted program to the larger internal boot flash die, or to external flash.
At a future date, if using the same 180nm process, die stacking could be used to create a 16 cog prop, with over 1MB of ram, at greater cost.
Good point, Andy. That could be a solution right there.
Many years ago, I wrote some software, that did something very similar, with a computer hardware ID. I believe it was a Volume ID. As long as you have a unique ID, I believe that is a very good place to start.
I will dig up the old files, and see if anything can be useful, but I may have used the Crypto API in conjunction with that unique ID, which would make it very difficult to reuse. Anyhow, I will check.
Using SPI-Flash serial, you would need to "hide" the match check some cleaver way or encrypt some parts of the firmware with it.
As after a few trial and error someone will just replace the CMP with a NOP in a HEX editor.
That is how unlimited life's was added to 8bit-machine games.
This was the basic problem inherent in the old Apple 2. From a boot standpoint, it was open. Even the disk subsystem was open.
Very effective anti-piracy ended up being a combination of:
1. Hardware dongle (which we could do)
Dongles contained part of the executable code, and other information, like the authentication data, if that method were to be used.
2. Goofy disk encode schemes.
3. Self-modifying and or very clever boot code that was very difficult to trace, and or required access to the secret code contained in a dongle, or that only existed for a moment in time, difficult to capture.
4. Multiple layers of checks, and those being randomized in a few very aggressive cases.
So, we could use the SPI chip register to contain an ID. Build the program, sans the ID, and make it work solid. This is the reference build, used for testing, validation, whatever.
The trick then, is to add the copy protection afterword.
Add the checks in various places, and use different forms for those checks. Add dependent checks that are PAINFUL, like maybe works for a while, then fails hard, or in some way that really hurts and it takes a while for the real hurt to manifest.
(One game, denied an item. People would not even know, until they had invested hours.)
Test these, randomize them, where, when they appear, and test that.
Each distribution gets it's own key, and it also gets it's own set of very aggressive checks. People can do the work, and get their copy clean, but it's gonna take an awful lot to do.
This whole thing is about risk/reward. We can't really improve on the reward side of the equation, but we have a lot of control over the risk and cost side.
Given the streamer, HUBEXEC, how COGS can be loaded, event driven... We can make some very seriously brutal checks. It's going to take a whole lot more than changing a branch if not equal to branch if equal. (the very first crack I ever did, BTW)
How about die stacking to provide both:
.....
The smaller boot flash die can only be read by the boot ROM...
Stacked die has been mentioned before, but this needs bonding planning I think we are past that stage already.
Another issue, is to get that easy-to-say 'The smaller boot flash die can only be read by the boot ROM' you need buried pins, that do not come out of the package.
P2 currently does not offer that.
One problem is that the serial is readable, a 30cent mcu could sniff P2's request and insert it (man in the middle attack)
Or $1 mcu with enough flash could emulate a spi flash, down to the serial number provided.
Using SPI-Flash serial, you would need to "hide" the match check some cleaver way or encrypt some parts of the firmware with it.
As after a few trial and error someone will just replace the CMP with a NOP in a HEX editor....
Of course, someone could just check and compare, but mostly you would expect a more complex encrypt design.
P2 can self modify code, so that opens up many things.
eg user could read code version number, and then morph some small code area based on that plus the ID.
Nett result is the patch changes with code revisions, (this kills the lifetime of any crack) and requires significant reverse dis-asm level skills.
Come on guys, seriously! I hate to say it, but trying to invent code protection schemes here is amateur night at the follies. And that applies to everyone here, myself included. Bruce Schneier would have a field day debunking this entire thread.
Either include NV bits in the P2, or forget about code security. It's that simple.
Jmg has said there are 30-cent micros with 16KB of flash and their own code security. These, unto themselves, are probably 'secure'. We could use them as protected code loaders for the Prop2 by having them deliver random-looking code snippets which the Prop2 must execute very quickly, in order to unravel data, while reporting back continuously to the secure micro. ....
The cheap micro could feed the initial program in serially via P63, and then the loaded code, containing a key, would use the normal flash chip (if even needed) to decrypt much larger code. So, this would add a little to the BOM and even supplant the need for a separate flash chip, in some cases.
I know this doesn't sound "fantastic", but for people who develop applications that they want to secure, they could adopt this mechanism after the fact. It could be there for people who need it. Meanwhile, there's no potential for ugly gotcha's during development and a Prop2 can't get "bricked".
I was curious about the claims/hints around USB loaders, on the newest STC parts, so I downloaded their ISP software, and I see it has a "USB Download" selector tickbox - below is the screen shot of the listed parts and prices. (Yuan -> USD shows those are quite cheap, but the listed USB parts here, is fewer than in their PDF tables - not sure what that means ?)
The ISP menus in the DOCs show 'STC USB Writer (USB1)' in the menus, and a Windows device called 'STC low Speed USB Writer'
I cannot yet find the boot loader source code, or how much space it needs, or what 'caveats' SW-USB brings, and what having a USB Loader in the 4k part means is left for users...
Some parts have a split of Flash and 'EEPROM' and the EEPROM column is that 'spare flash'.
If China-sourcing / China-Docs worries some, SiLabs have a EFM8UB3 40kF HW FS-USB part coming, in QFN20 up, - not quite as cheap, but well documented and able to displace USB-UART Bridge devices.
However, many discussions here are around P2 + other chips, and the overall system security of that system, is no longer that of P2 alone.
Yes, but those discussions still involve communication between those other devices and the P2 that can be probed. That's the hopelessly weak link.
More to the point, though, how do you describe any of the discussed schemes with a learned potential customer without being laughed at? Or how do you keep from getting sued by a less astute customer when the promised security gets compromised? And it will.
Phil is 100% correct here. This is no longer a discussion about anything that is specific to the Prop2. External serial number tricks are a generic obfuscation solution for any MCU.
Comments
If though I developed a product that could realize huge profits/volume I could then talk $$$$$$ to Parallax about a copy protected version. But I mean huge.
btw, I have reverse engineered product (though not to copy) even when the chip origin is obscured. When you know which pins the crystal and power are connected to then it's a matter of trawling through likely candidates until eventually you find a match.
-Phil
Sure it's a bad hit with 8 instead of 16 Cogs. That drained a lot out of the fun finishing it finally. But it is like it is. And it's still a wonderful MC. Or will be, hopefully.
A compromise would be to leave the actual fuses there, but not the boot support.
So if anyone REALLY needs protection he could burn pre fabrication some serial numbers with a 1/400 failure rate. pre soldering 5V supply does not matter.
And has some valid/notvalid serial number for the software.
Anyways,
Mike
-Phil
That's an interesting technical idea, and may be close to what Chip has actually done, given the PAD-Ring layout that contains the fuses, is already completed and is not in Verilog.
ie True total physical fuse removal is not likely.
Commercially, however, that might not work so well, as it risks making the device look half-baked, and it has an associated support cost.
Chip said this in #1 :
Seems the risks of accidental brownout-blow, and bricking devices are foremost.
If the ROM skips all fuse-gateways, that avoids No-Boot-bricking, but it may still have some risk of the Serial Number being modified "by some accidental blowing during core brown-out, or some other unlikely, but possible, scenario." - maybe that can be mitigated with a 'secure' fuse set of maybe 4, that hardware disables all further fuse flow. (any one of the 4 secure fuses blown, prevents any further change)
That could allow Parallax to offer a Unique Serial number ID.
I meant "think", but my phone heard "thing".
My point was that there's a prevailing assumption that security must be about a special key (noun), but perhaps some interaction (verb) could be used to achieve security, instead. If you can get cheap "secure" micros with many KB of flash, you may be able to get the secret object code into the Prop without it being practically discoverable.
Aside from the already discussed fab line limitation, such an approach is not very viable when every spare space is already needed. We'd be sacrificing other parts of the Prop2 to fit in a block of Flash say.
The way I see it, that leaves obfuscation or cryptographic keys. Both require the ability to be adaptable to being cracked. Which means the method can't be solely a mask ROM solution.
In the case of a key, it has to be replaceable if discovered.
In the case of obfuscation, the method itself has to be thrown away each time it's cracked.
From Winbond Datasheet:
"The Read Unique ID Number instruction accesses a factory-set read-only 64-bit number that is unique to each W25Q32FV device. The ID number can be used in conjunction with user software methodes to help prevent copying or cloning of a system."
Such a Flash chip is anyway required for the P2, so there is no additional chip necessary to install some simple protection against cloning.
Andy
To prevent cloning, it could be as simple as this:
Before compiling the user's code, the Prop2 tool discovers the unique ID of the flash chip in the target system. That ID value is assigned to a global constant before compiling the user's program. The user's program verifies that value any number of ways within his code at run time. He doesn't operate if he discovers a problem.
Prop on boot sends 100 random numbers to the cheap micro.
Cheap micro performs some math on all the numbers and returns the numbers not in the same order, and mixes in some random numbers it generates in positions that will be ignored.
The Prop knows what order the numbers will be returned and what position to look for specific numbers and checks the math that was done from the other side.
There can be for multiple schemes the cheap micro uses to affect the numbers, choosing a scheme based on the checksum, ie if checksum > 0 and < 32 use scheme a, if checksum > 32 and < 64 then use scheme b. So the checksum affects how the cheap micro will operate and the order the values are returned.
I am sure there are better schemes than this but to my thinking this would be some effort for someone to solve.
Better to not have the number discoverable in the binary. Use various other numbers in constants that can be calculated by some method on boot to arrive at the ID. If someone analyzed several P2 eeproms they could see the minor variance if there is only one item changing per compile.
The critical detail there is that's the system developer's ("user" from Chip's perspective) code that is doing this. The Prop2 has nothing in the ROM or hardware design to handle any part of the protection.
It's the obfuscation route. It's what's commonly used in computer games. It's good enough for most situations because it can be redone for every release. Making it a moving target.
How about die stacking to provide both:
b. a second smaller boot flash die which contains just the serial number and / or private decryption key.
The smaller boot flash die can only be read by the boot ROM, a copy of the key would be kept in special register which can only be accessed by code in boot rom space, or copy thereof (1-400?). A mechanism (instruction) to load overlays by re-invoking a decryption routine in the boot loader code which is still in memory, uses the copy of the key to decrypt once more.
This overlay instruction may only be executed from boot rom code space (copy in ram). If the boot rom code space is overwritten, the overlay instruction execution is disabled (by a ff which is reset on reset) to prevent pilferring of the encryption key. This would require comparing hubexec write addresses 1 through 400 and non-long addresses only? ie ( addr & ff800 == 0 ) & ( ( addr & 3 ) != 0 )
I think this would provide full encryption, and reduce BOM count, though at greater cost. It would still be possible to have external flash or sd card connected as is currently the case, simply program the internal boot flash die to start with 0.
The smaller boot flash is read on hardware reset.
If no connection on serial interface for programming, ie booting an application:
decrypt the internal boot flash to propeller ram.
At a future date, if using the same 180nm process, die stacking could be used to create a 16 cog prop, with over 1MB of ram, at greater cost.
Many years ago, I wrote some software, that did something very similar, with a computer hardware ID. I believe it was a Volume ID. As long as you have a unique ID, I believe that is a very good place to start.
I will dig up the old files, and see if anything can be useful, but I may have used the Crypto API in conjunction with that unique ID, which would make it very difficult to reuse. Anyhow, I will check.
As after a few trial and error someone will just replace the CMP with a NOP in a HEX editor.
That is how unlimited life's was added to 8bit-machine games.
Very effective anti-piracy ended up being a combination of:
1. Hardware dongle (which we could do)
Dongles contained part of the executable code, and other information, like the authentication data, if that method were to be used.
2. Goofy disk encode schemes.
3. Self-modifying and or very clever boot code that was very difficult to trace, and or required access to the secret code contained in a dongle, or that only existed for a moment in time, difficult to capture.
4. Multiple layers of checks, and those being randomized in a few very aggressive cases.
So, we could use the SPI chip register to contain an ID. Build the program, sans the ID, and make it work solid. This is the reference build, used for testing, validation, whatever.
The trick then, is to add the copy protection afterword.
Add the checks in various places, and use different forms for those checks. Add dependent checks that are PAINFUL, like maybe works for a while, then fails hard, or in some way that really hurts and it takes a while for the real hurt to manifest.
(One game, denied an item. People would not even know, until they had invested hours.)
Test these, randomize them, where, when they appear, and test that.
Each distribution gets it's own key, and it also gets it's own set of very aggressive checks. People can do the work, and get their copy clean, but it's gonna take an awful lot to do.
This whole thing is about risk/reward. We can't really improve on the reward side of the equation, but we have a lot of control over the risk and cost side.
Given the streamer, HUBEXEC, how COGS can be loaded, event driven... We can make some very seriously brutal checks. It's going to take a whole lot more than changing a branch if not equal to branch if equal. (the very first crack I ever did, BTW)
Another issue, is to get that easy-to-say 'The smaller boot flash die can only be read by the boot ROM' you need buried pins, that do not come out of the package.
P2 currently does not offer that.
Or $1 mcu with enough flash could emulate a spi flash, down to the serial number provided.
P2 can self modify code, so that opens up many things.
eg user could read code version number, and then morph some small code area based on that plus the ID.
Nett result is the patch changes with code revisions, (this kills the lifetime of any crack) and requires significant reverse dis-asm level skills.
1wire:
https://www.maximintegrated.com/en/products/digital/memory-products/DS28E10.html
i2c bus:
https://www.maximintegrated.com/en/products/digital/memory-products/DS28C36.html
Either include NV bits in the P2, or forget about code security. It's that simple.
-Phil
I was curious about the claims/hints around USB loaders, on the newest STC parts, so I downloaded their ISP software, and I see it has a "USB Download" selector tickbox - below is the screen shot of the listed parts and prices. (Yuan -> USD shows those are quite cheap, but the listed USB parts here, is fewer than in their PDF tables - not sure what that means ?)
The ISP menus in the DOCs show 'STC USB Writer (USB1)' in the menus, and a Windows device called 'STC low Speed USB Writer'
I cannot yet find the boot loader source code, or how much space it needs, or what 'caveats' SW-USB brings, and what having a USB Loader in the 4k part means is left for users...
Some parts have a split of Flash and 'EEPROM' and the EEPROM column is that 'spare flash'.
If China-sourcing / China-Docs worries some, SiLabs have a EFM8UB3 40kF HW FS-USB part coming, in QFN20 up, - not quite as cheap, but well documented and able to displace USB-UART Bridge devices.
However, many discussions here are around P2 + other chips, and the overall system security of that system, is no longer that of P2 alone.
Yes, but those discussions still involve communication between those other devices and the P2 that can be probed. That's the hopelessly weak link.
More to the point, though, how do you describe any of the discussed schemes with a learned potential customer without being laughed at? Or how do you keep from getting sued by a less astute customer when the promised security gets compromised? And it will.
-Phil