Furthermore, I bet that FLASH is also AVAILABLE on the ONC18 line too!
I'd expect that OnSemi can do 0.18u Flash, the smarter question is does the ASIC group Chip is dealing with, have Flash under their umbrella as compilable memory arrays ?
I have seen OTP mentioned, with specific sizes given.
Yep, Chip has indicated OTP and EEPROM are possible. But it takes extra testing and design iterations to fit them in with the custom features of the Prop2.
So since this is solely for the purpose of copy protection they're aren't all that useful to the Propeller.
As of two weeks ago, the only NV memory offered to us by OnSemi was either a 128-bit fuse block requiring an external 5V pin to program, or a 1k bit array of EE memory requiring lots of test pads. I can't explain the press releases and all those other claims. They seem to not exist. Even their ROM offerings only get a little bigger than our 16KB instance.
I really don't like the idea of trying to integrate, at this stage, some new type of NV memory, and then make the chip's functionailty rely on it, as a code-protect scheme must do. It feels too risky. What we'll have, instead, is a modeless chip, unstoppable by any screwy misconfiguration.
I'm sad about not having code protection, but also relieved to not have to support all the complexities that it would have necessitated. Most of what people are going to be doing is downloading code and debugging. Without the added variable of code protection, that process is going to be simpler, faster, and more carefree.
The CEO of my company calls products or features that have been announced, but don’t exist, “slideware”. As in, they have PowerPoint slides talking about the feature...but that’s it.
Perhaps the feature is in development and they announce it when they hear a competitor is doing something similar, to make sure they are not perceived as falling behind.
As of two weeks ago, the only NV memory offered to us by OnSemi was either a 128-bit fuse block requiring an external 5V pin to program, or a 1k bit array of EE memory requiring lots of test pads. I can't explain the press releases and all those other claims. They seem to not exist. Even their ROM offerings only get a little bigger than our 16KB instance.
which says March 31, 2011 – Sidense Corp., a leading developer of Logic Non-Volatile Memory (LNVM) one-time programmable (OTP) memory IP cores, and ON Semiconductor, a premier supplier of high performance silicon solutions for energy efficient electronics, have announced that Sidense has ported its 180 nanometer (nm) OTP memory SLP product line to ONC18, ON Semiconductor’s 180 nm digital and mixed-signal technology platform. ... Single SLP macro densities ranging up to 256 kilobits (Kbits) will be available.
You could ask how many OnSemi 0.18u customers actually used that memory in their designs ? - over 6+ years, you would expect some experience ?
I also see this very topical side note, on that web page :
"Update (Oct. 17, 2017): Synopsys Expands DesignWare IP Portfolio with Acquisition of Sidense Corporation"
That may make the IP easier to select and integrate, if they use Synopsys tool chains ?
It's typical for a large company like OnSemi to only use lower level people to interface to small companies (like Parallax). The trick is to get beyond those people to the engineers that are actually in tune with the ONC18 process. The problem is that the questions were not asked of OnSemi years ago, when I first raised them. Now it's deemed too late to press the issue. We all lose, including Parallax!
Don't be fooled, OnSemi couldn't survive the micro asic customers on their ONC18 process without some forms of ROM, OTP and NOVRAM IP being available. They have been making 1.8V-5V EEPROMs on their ONC18 line, and I have been using them, for years. Their info above proves this. To think this is not available for asic designs would be unthinkable.
Anyway, I don't care much anymore. To me the P2 has become a fiasco.
It's just plain amateurish for these problems to be uncovered at this final stage of production. These questions should have been asked years ago.
It's typical for a large company like OnSemi to only use lower level people to interface to small companies (like Parallax). The trick is to get beyond those people to the engineers that are actually in tune with the ONC18 process. The problem is that the questions were not asked of OnSemi years ago, when I first raised them. Now it's deemed too late to press the issue. We all lose, including Parallax!
Don't be fooled, OnSemi couldn't survive the micro asic customers on their ONC18 process without some forms of ROM, OTP and NOVRAM IP being available. They have been making 1.8V-5V EEPROMs on their ONC18 line, and I have been using them, for years. Their info above proves this. To think this is not available for asic designs would be unthinkable.
Anyway, I don't care much anymore. To me the P2 has become a fiasco.
It's just plain amateurish for these problems to be uncovered at this final stage of production. These questions should have been asked years ago.
It's not a battle I'm up to fighting right now.
Too much is in motion with OnSemi to go back to the drawing board and insert some new type of NV memory which everything must pivot on.
After hearing the discussion about a battery and a cog, it made me wonder about an alternate being a dedicated register(s) with a pin that could connect to a battery. The register is set first then the code loaded second. Once loaded. There is no further code required like a cog. But the main program reads the register on boot up for the key. If no key the program locks up. Someone could steal the binary from the eeprom but it won’t run. Probably too late to consider any alternatives I was just curious why this wouldn’t work if a cog does work with a battery.
After hearing the discussion about a battery and a cog, it made me wonder about an alternate being a dedicated register(s) with a pin that could connect to a battery. The register is set first then the code loaded second. Once loaded. There is no further code required like a cog. But the main program reads the register on boot up for the key. If no key the program locks up. Someone could steal the binary from the eeprom but it won’t run. Probably too late to consider any alternatives I was just curious why this wouldn’t work if a cog does work with a battery.
You'd have to power up the whole Propeller core with 1.8V and it will leak about 1mA, continuously. It's not the kind of thing that a battery would sustain for very long.
The CEO of my company calls products or features that have been announced, but don’t exist, “slideware”. As in, they have PowerPoint slides talking about the feature...but that’s it.
Perhaps the feature is in development and they announce it when they hear a competitor is doing something similar, to make sure they are not perceived as falling behind.
Also to see if there’s any customer interest. Anyone who has worked in the industry has seen this from the inside.
Edited to add: There are plenty of failed Kickstarter campaigns that demonstrate this concept.
You'd have to power up the whole Propeller core with 1.8V and it will leak about 1mA, continuously. It's not the kind of thing that a battery would sustain for very long.
In that thread the P8x32A is still running down around 1 volt with about 1uA supply ( ie 1uWatt kind of levels).
Good point, in the past, that spec was called the RAM retention voltage. Many SRAMs still specify a retention voltage.
This needs All Clocks stopped, (can P2 do that ?), then voltage lowered, then on exit, the reverse.
Voltage raised, then clocks started. (or reset generated)
Alternative is deep-doze, with only SlowRC running, and supplies lowered to kHz clock levels.
How useful this is, depends on Icc of SlowRC.
We should end whining here on what the P2 can not do. Other prominents in gol is doing enough into this direction. We should accept: if grows follows an exponential curve, the most important is, to begin as early as possible, not to grow as fast as possible too late. With the P2's features and our genius combined the P2 will be a huge success, however hardware and software will be combined. Stop distracting Chip from shipping the chip! Please. Keep hearing about "tiny" amount of money spent on Propeller ads. What about the billions of dollars of main stream processors ads?
Always try to recycle the bad to create something good!
I'm saddened that "IC lobotomy" seems "ok" when it comes to mentally justifying progress. If I bought a car with that way of thinking, I might only get 1 out of 4 seats a majority of the time since the chances of occupying all 4 seats at any given time would never be 100% and many car consumers may never use the other 3 seats.
@msrobots - "use it for hidden art. draw something nobody will ever see! Finally a place for the propeller hat. Now everything is fine"
... There was something already in one of the corner pads. Not sure if it is still there or not, but I placed a logo about 4 or more years ago.
Speaking for myself only. I don't need SHA256 encryption or anything like that. I just would like something that a customer cannot just copy the EEPROM contents and duplicate the hardware.
Right now, I would use a 1-Wire "unique serial number" only device and have the code check for that serial number. It works, but it is a pain. And requires the code to talk to a 1-wire device.
I'm not worried about the customer getting the code, because it wouldn't be worth their time to learn about the propeller, then look for the code that checks the serial number, etc, etc. They would just buy another board instead of going thru all that work.
Basically just keeping the honest people honest. Any protection scheme can be cracked if someone is willing to do the work.
At one time I thought of using a scheme where I would damage one of the I/O pins (maybe by shorting it to ground when it is HIGH) then connecting it to another pin in some way, so that it would act different from a normal propeller chip. But I never tried it.
I'm saddened that "IC lobotomy" seems "ok" when it comes to mentally justifying progress. If I bought a car with that way of thinking, I might only get 1 out of 4 seats a majority of the time since the chances of occupying all 4 seats at any given time would never be 100% and many car consumers may never use the other 3 seats.
@msrobots - "use it for hidden art. draw something nobody will ever see! Finally a place for the propeller hat. Now everything is fine"
... There was something already in one of the corner pads. Not sure if it is still there or not, but I placed a logo about 4 or more years ago.
Beau, you're one of most clever people I know. If you used your brain on this, you could probably come up with half a dozen different schemes to achieve code protection, given what we've got. You are good at thinking outside the box and not being stifled by convention.
If Parallax can supply P2's with no markings like they did with P1we can laser our own numbers/symbols on there.
Unrecognizable part numbers is another "decoy" security technique to throw potential hacks off course.
Besides it also looks cool to see your product with your logo/numbers on the chips.
You'd have to power up the whole Propeller core with 1.8V and it will leak about 1mA, continuously. It's not the kind of thing that a battery would sustain for very long.
In that thread the P8x32A is still running down around 1 volt with about 1uA supply ( ie 1uWatt kind of levels).
Chip, will we still be able to disable the brownout detection in the P2?
There is no brown out detector in the P2. That involved a band gap which required non-volatile trimming to be accurate. I just didn't do it on this chip, since the NV thing was so difficult.
Lowering the core voltage and slowing down the clock is a really neat idea to keep memory alive.
At one time I thought of using a scheme where I would damage one of the I/O pins (maybe by shorting it to ground when it is HIGH) then connecting it to another pin in some way, so that it would act different from a normal propeller chip. But I never tried it.
Hehe, interesting idea.
I doubt the part could self-damage quickly enough, as the limited current is quite modest.
You might be able to stress/fail the clamp diode, by driving the pin negative on an unpowered device, - watching the IV curve might even let you know "when it's done cookin' "
Speaking for myself only. I don't need SHA256 encryption or anything like that. I just would like something that a customer cannot just copy the EEPROM contents and duplicate the hardware.
Right now, I would use a 1-Wire "unique serial number" only device and have the code check for that serial number. It works, but it is a pain. And requires the code to talk to a 1-wire device.
I'm not worried about the customer getting the code, because it wouldn't be worth their time to learn about the propeller, then look for the code that checks the serial number, etc, etc. They would just buy another board instead of going thru all that work.
Many have similar levels of 'secure'.
You could use a small MCU for that ? Still needs software work, but only done once...
Looks like 16-18k Flash are sub 30c, and 60k Flash look to be sub 40c (qfn32 or tqfp32)
These STC8 series ones, even claim to have a USB loader (SW,LS-USB) even in the very low cost models.
I've seen some diagrams drawn with 24MHz crystals, and some without that. It might be the faster STC8 series can do a loader without crystal ?
That loader may be able to be modified to pass code onto a Prop, instead of self-programming.
Maybe there’s an approach where Parallax embeds a secret on the chip. A customer requests a key. Parallax provides them with a number (entropy?) that’s used to derive a key from the secret key, and the resulting key. They encrypt their file with the resulting key. The loader format includes the magic number up front. Maybe someone really motivated could research key derivation functions and see if there’s a secure way to pull this off. Maybe Parallax could include multiple secrets on the die where the fuses used to be.
Maybe there’s an approach where Parallax embeds a secret on the chip. A customer requests a key. Parallax provides them with a number (entropy?) that’s used to derive a key from the secret key, and the resulting key. They encrypt their file with the resulting key. The loader format includes the magic number up front. Maybe someone really motivated could research key derivation functions and see if there’s a secure way to pull this off. Maybe Parallax could include multiple secrets on the die where the fuses used to be.
Maybe, but that has quite limited usefulness.
* It fails Bean's simple test above "I just would like something that a customer cannot just copy the EEPROM contents and duplicate the hardware"
* It does obfuscate the Code, but such code can be simply replaced with non-secured code, (or their own-key code), and appear to run the same. So it fails an attack test.
* It does delay disasm, but the boot loader will read some specific location for the key, and anyone who requests a key will know that location.
If Parallax can supply P2's with no markings like they did with P1we can laser our own numbers/symbols on there.
Unrecognizable part numbers is another "decoy" security technique to throw potential hacks off course.
Besides it also looks cool to see your product with your logo/numbers on the chips.
as usual @ozprpdev has the right solution. KISS.
there is something with the prop user from down under, I like the way they think.
Maybe there’s an approach where Parallax embeds a secret on the chip. A customer requests a key. Parallax provides them with a number (entropy?) that’s used to derive a key from the secret key, and the resulting key. They encrypt their file with the resulting key. The loader format includes the magic number up front. Maybe someone really motivated could research key derivation functions and see if there’s a secure way to pull this off. Maybe Parallax could include multiple secrets on the die where the fuses used to be.
Maybe, but that has quite limited usefulness.
* It fails Bean's simple test above "I just would like something that a customer cannot just copy the EEPROM contents and duplicate the hardware"
* It does obfuscate the Code, but such code can be simply replaced with non-secured code, (or their own-key code), and appear to run the same. So it fails an attack test.
* It does delay disasm, but the boot loader will read some specific location for the key, and anyone who requests a key will know that location.
Yes - assuming that one could solve the problem of encrypting the code, then perhaps a challenge response with an external part could be used for the real "dongle" protection. The secret used to derive keys can't be readable by anything outside of the boot loader. Maybe easier said than done - if there's some crypto hardware in the chip then you could wall off the COGs themselves from direct access to the secret. Anyways there are a lot of details to think about, just thought that I might be able to inspire someone who cares enough to think it through.
Basically think about a way to use some external parts for protection in a way that things can't be easily copied. Some examples of parts (simply copied from a Sparkfun page):
What kind of code protection is wanted? Is it (a) encrypting the code so that it could never be disassembled, or (b) ensuring code only runs on particular P2's, or (a) and (b)?
(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. If the first long is zero for no encryption that's all most people need to know.
A few questions:
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?
2. Would anything be gained by loading 512 longs, ie. a full cog's worth of RAM? Twice as much data at half the speed still wouldn't take long to load.
3. How does OnSemi treat chip security? Is the ROM code a black box to them? Could the mask ROM be protected from being read optically if the chip is decapped?
Comments
I'd expect that OnSemi can do 0.18u Flash, the smarter question is does the ASIC group Chip is dealing with, have Flash under their umbrella as compilable memory arrays ?
I have seen OTP mentioned, with specific sizes given.
So since this is solely for the purpose of copy protection they're aren't all that useful to the Propeller.
I really don't like the idea of trying to integrate, at this stage, some new type of NV memory, and then make the chip's functionailty rely on it, as a code-protect scheme must do. It feels too risky. What we'll have, instead, is a modeless chip, unstoppable by any screwy misconfiguration.
I'm sad about not having code protection, but also relieved to not have to support all the complexities that it would have necessitated. Most of what people are going to be doing is downloading code and debugging. Without the added variable of code protection, that process is going to be simpler, faster, and more carefree.
Perhaps the feature is in development and they announce it when they hear a competitor is doing something similar, to make sure they are not perceived as falling behind.
Puzzling indeed, as Google finds this
https://www.design-reuse.com/news/26031/sidense-1t-otp-memory-on-semiconductor-180-nm.html
which says
March 31, 2011 – Sidense Corp., a leading developer of Logic Non-Volatile Memory (LNVM) one-time programmable (OTP) memory IP cores, and ON Semiconductor, a premier supplier of high performance silicon solutions for energy efficient electronics, have announced that Sidense has ported its 180 nanometer (nm) OTP memory SLP product line to ONC18, ON Semiconductor’s 180 nm digital and mixed-signal technology platform. ... Single SLP macro densities ranging up to 256 kilobits (Kbits) will be available.
You could ask how many OnSemi 0.18u customers actually used that memory in their designs ? - over 6+ years, you would expect some experience ?
I also see this very topical side note, on that web page :
"Update (Oct. 17, 2017): Synopsys Expands DesignWare IP Portfolio with Acquisition of Sidense Corporation"
That may make the IP easier to select and integrate, if they use Synopsys tool chains ?
Don't be fooled, OnSemi couldn't survive the micro asic customers on their ONC18 process without some forms of ROM, OTP and NOVRAM IP being available. They have been making 1.8V-5V EEPROMs on their ONC18 line, and I have been using them, for years. Their info above proves this. To think this is not available for asic designs would be unthinkable.
Anyway, I don't care much anymore. To me the P2 has become a fiasco.
It's just plain amateurish for these problems to be uncovered at this final stage of production. These questions should have been asked years ago.
It's not a battle I'm up to fighting right now.
Too much is in motion with OnSemi to go back to the drawing board and insert some new type of NV memory which everything must pivot on.
I agree that it sucks, but that's the way it is.
You'd have to power up the whole Propeller core with 1.8V and it will leak about 1mA, continuously. It's not the kind of thing that a battery would sustain for very long.
Also to see if there’s any customer interest. Anyone who has worked in the industry has seen this from the inside.
Edited to add: There are plenty of failed Kickstarter campaigns that demonstrate this concept.
It should be lower than that, when pushed. We need to repeat tests from this thread
[url="http://"]http://forums.parallax.com/discussion/129731/prop-limbo-how-low-power-voltage-can-it-go[/url]
In that thread the P8x32A is still running down around 1 volt with about 1uA supply ( ie 1uWatt kind of levels).
Chip, will we still be able to disable the brownout detection in the P2?
Good point, in the past, that spec was called the RAM retention voltage. Many SRAMs still specify a retention voltage.
This needs All Clocks stopped, (can P2 do that ?), then voltage lowered, then on exit, the reverse.
Voltage raised, then clocks started. (or reset generated)
Alternative is deep-doze, with only SlowRC running, and supplies lowered to kHz clock levels.
How useful this is, depends on Icc of SlowRC.
Always try to recycle the bad to create something good!
And code protection on the chip is not possible at all, except maybe forth. All we and anybody else can get is binary-protection anyways.
since the fuses where somehow in that outer ring, removal will not bring more space, @Chip use it for hidden art. draw something nobody will ever see!
Finally a place for the propeller hat. Now everything is fine.
Mike
@msrobots - "use it for hidden art. draw something nobody will ever see! Finally a place for the propeller hat. Now everything is fine"
... There was something already in one of the corner pads. Not sure if it is still there or not, but I placed a logo about 4 or more years ago.
Buy older ones! My MB SL500 from 1993 is now changing colors by itself! From glossy to flat black..
Mike
Right now, I would use a 1-Wire "unique serial number" only device and have the code check for that serial number. It works, but it is a pain. And requires the code to talk to a 1-wire device.
I'm not worried about the customer getting the code, because it wouldn't be worth their time to learn about the propeller, then look for the code that checks the serial number, etc, etc. They would just buy another board instead of going thru all that work.
Basically just keeping the honest people honest. Any protection scheme can be cracked if someone is willing to do the work.
At one time I thought of using a scheme where I would damage one of the I/O pins (maybe by shorting it to ground when it is HIGH) then connecting it to another pin in some way, so that it would act different from a normal propeller chip. But I never tried it.
Bean
Beau, you're one of most clever people I know. If you used your brain on this, you could probably come up with half a dozen different schemes to achieve code protection, given what we've got. You are good at thinking outside the box and not being stifled by convention.
Unrecognizable part numbers is another "decoy" security technique to throw potential hacks off course.
Besides it also looks cool to see your product with your logo/numbers on the chips.
There is no brown out detector in the P2. That involved a band gap which required non-volatile trimming to be accurate. I just didn't do it on this chip, since the NV thing was so difficult.
Lowering the core voltage and slowing down the clock is a really neat idea to keep memory alive.
I doubt the part could self-damage quickly enough, as the limited current is quite modest.
You might be able to stress/fail the clamp diode, by driving the pin negative on an unpowered device, - watching the IV curve might even let you know "when it's done cookin' "
Many have similar levels of 'secure'.
You could use a small MCU for that ? Still needs software work, but only done once...
Looks like 16-18k Flash are sub 30c, and 60k Flash look to be sub 40c (qfn32 or tqfp32)
These STC8 series ones, even claim to have a USB loader (SW,LS-USB) even in the very low cost models.
I've seen some diagrams drawn with 24MHz crystals, and some without that. It might be the faster STC8 series can do a loader without crystal ?
That loader may be able to be modified to pass code onto a Prop, instead of self-programming.
Maybe, but that has quite limited usefulness.
* It fails Bean's simple test above "I just would like something that a customer cannot just copy the EEPROM contents and duplicate the hardware"
* It does obfuscate the Code, but such code can be simply replaced with non-secured code, (or their own-key code), and appear to run the same. So it fails an attack test.
* It does delay disasm, but the boot loader will read some specific location for the key, and anyone who requests a key will know that location.
as usual @ozprpdev has the right solution. KISS.
there is something with the prop user from down under, I like the way they think.
no need for laser, a blank chip is also fine...
Enjoy!
Mike
Yes - assuming that one could solve the problem of encrypting the code, then perhaps a challenge response with an external part could be used for the real "dongle" protection. The secret used to derive keys can't be readable by anything outside of the boot loader. Maybe easier said than done - if there's some crypto hardware in the chip then you could wall off the COGs themselves from direct access to the secret. Anyways there are a lot of details to think about, just thought that I might be able to inspire someone who cares enough to think it through.
Basically think about a way to use some external parts for protection in a way that things can't be easily copied. Some examples of parts (simply copied from a Sparkfun page):
CAT24C256 (Cape EEPROM)
ATAES132 (AES-128)
AT97SC3204T (TPM)
ATSHA204 (SHA-256)
ATECC108 (ECC)
as in "forget it for now"
we like to throw things (eg sausages) on the bbq... lets cook
(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. If the first long is zero for no encryption that's all most people need to know.
A few questions:
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?
2. Would anything be gained by loading 512 longs, ie. a full cog's worth of RAM? Twice as much data at half the speed still wouldn't take long to load.
3. How does OnSemi treat chip security? Is the ROM code a black box to them? Could the mask ROM be protected from being read optically if the chip is decapped?
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.