If they say that their focus is AT THE FUSE, you could bet your most beloved pair of socks, that they will grab a pebble from the Moon, to attain the intended objective.
That does give a current profile, which could be a great help in setting up capture equipment.
Looks like they use 6V and need 90mA peak, for a 350nm x 1.5um fuse, & it seems to have two weakening zones.
I believe that whith such an increase in geometry, the molten remains fluid for a longer time.
Enough for the action of surface tension forces, aglutinating the center region, like a strip of low temp solder does, when melt over glass by a hot iron.
While security will not effect me, it is becoming a more prevalent thing in micros these days to be able to lock down a design. It was a prime objective for the P2 design (ask Ken), so to abandon it just because you haven't found the right person to ask in OnSemi seems like a major flaw, at least in my mind.
I've actually recommended to Chip that we forgo code protect at this stage. The reason is diminishing returns, protracted inability to complete the product, extended costs and schedule and general unknowns. While the market certainly wants code protect, I'm very aware of the overall implications even this very small addition poses to the total effort. While you may not agree, at this stage it is most imperative for Chip to simply hold a course of his choice and finish the project.
The desired outcome would be small iterations to the product, over time. We will never have any traction if we can't get to the starting line.
I guess I am missing something here. Fuses can be used in a variety of ways. The basic uses would be to prevent theft and/or prevent corruption of the code by outside intervention.
If someone wants something bad enough, they will get it. There is no perfect form of security. Everything is vulnerable to someone. Fortunately most people would never steal anything and they would prefer to do business with honest people.
At the corporate level, theft would occur before the fuses get set. The security has to be multi-level and isn't helped one iota by fuses.
Hacking.
The highest uses for the P2 will probably involve a computer that is hooked up to the WWW. It seems to me that creating programming tools that have security options built into them is a pretty good way to protect the P2 from budding hackers. The PropTool is pretty secure and could easily be made more so. Make it easier to hide. Allow a user chosen serial number, pad the binary in a clever way, make the tools sensitive to their own padding.
At the same time, we are going to want some level of script-ability built into the tools to facilitate all kinds of uses. Scripting complicates tools-based security arrangements.
At some level, security and usability get traded against each other.
At the end of the day, security should be optional: something that a user can migrate to, not something that keeps them from getting started in the first place.
I really don't worry about theft... being hacked is another kettle of fish.
...without sacrificing security. ARTIK 053 has a built-in security module that keeps its factory-installed certificates and keys safe.
...PUF Physical Unclonable Function.
...Firmware Integrity Secure boot and JTAG protection
Cluso99 wrote: »
While security will not effect me, it is becoming a more prevalent thing in micros these days to be able to lock down a design.
Whilst I do appreciate the motivation here. This kind of post bugs me. It basically says "I don't need feature X but I suspect some mythical prospective big customer Y might."
It might be better to just speak of our needs and desires rather than speculate about those of others.
I suspect building a secure device requires a lot more thought and development than time allows here. Never mind binary code security, what about security as an IoT, web, connected device?
Parallax is familiar with DEFCON. Those guys do their best to break everything. Might be an idea to talk to them first.
As such Ken, I'm with rjo__, "Thanks Jesus", let's get this chip out the door.
I'm expecting a test device to play with for Xmas (Chipmas)
I wonder if it would be practical to deploy a system without boot media and rely on a battery backup to keep the code in RAM at all times...
I have robots with this type of functionality. I've also encountered one industrial control with same. Ended up making a big, fat, like good for 5 years battery backup. External, wired in parallel with the smallish (like they want the damn thing to fail, because service calls) one supplied. The robots actually do contain software on those funky PCMCIA flash cards, and have a flash storage, but the battery backs up encryption and global provisioning data. The entitlements aren't recoverable without a service call, but one can go through and manually provision again, axis defaults, etc... The industrial control was RAM. Lose it, and it's a brick. I watched the service tech arrive, call the mothership, get a one time distribution, load it and leave.
People do it. And it works, but it's somewhat scary for the end user.
If I had to judge when doing that could be indicated, I would have to say high value, low to mid volume specialized products would be a prime target.
As for encryption, we have another path available to us. DALLAS makes chips for this purpose, they are battery backed, can contain keys, and are used in systems that have boot media. A booter loads, brings system to service state, reads the DALLAS chip, gets a key, then decrypts the target environment. It's a dongle, essentially.
Honestly, I like these, because they are often socketed, or removable enough to be portable. Get a replacement machine, move the chip, boot, and go. I did this a number of times on SGI hardware running some seriously expensive software long past it's "best used by" date. Had them go shopping on e-bay, then I carefully cloned it all, moved the DALLAS chips, and could bring it all up on a new box. That kind of thing costs a bit more in the BOM, but it also leaves people some options, if they work for it, without also opening the door to more users than were agreed. FWIW.
I remember discussing this battery backed 'secure cog' approach with Cluso and Hanno in Sydney some years back. The reset pin ends up tied high. One of the pcbs on the Smorgasboard had it implemented, I think.
I think Chip replied to one of your threads and thought it would work, Rayman
The idea as I remember it was to completely disable hardware reset, but emulate reset through another GPIO pin. So the (software emulated in secure cog) reset would stop all cogs other than the secure cog, and run the booter
edit: oops I see what you're saying. This approach uses cog ram rather than hub ram, not sure whether its possible to read cog ram after a reloaded or paired cog. Worth checking out
While security will not effect me, it is becoming a more prevalent thing in micros these days to be able to lock down a design. It was a prime objective for the P2 design (ask Ken), so to abandon it just because you haven't found the right person to ask in OnSemi seems like a major flaw, at least in my mind.
I've actually recommended to Chip that we forgo code protect at this stage. The reason is diminishing returns, protracted inability to complete the product, extended costs and schedule and general unknowns. While the market certainly wants code protect, I'm very aware of the overall implications even this very small addition poses to the total effort. While you may not agree, at this stage it is most imperative for Chip to simply hold a course of his choice and finish the project.
The desired outcome would be small iterations to the product, over time. We will never have any traction if we can't get to the starting line.
Ken Gracey
Makes sense Ken. Just wanted your input in case it was imperitive to be there for your volume users.
However, I am really disapointed this (and Flash/EEPROM/OTP) wasn't followed thru a loooong time ago. The solution is within OnSemi. Just need to get to the right person.
I did not realize that the fuses where bound to the pins. That would mean the security features, would not work on smaller P2-Family-Members.
Delaying the P2 again, is simply a nono. It does not matter, that some people NEEDING security would not buy it, if NOBODY is able to buy it, since it is not for sale at all.
And, if the P2 is used in connection with the internet, one can easy prevent theft/cloning by interlocking P2 and inet-server-software.
what could help would be a serial-number burned in at production time of the chip, but even that seems to be to expensive.
How about a poll, either here in the forum or Parallax asking their existing volume customers about the NEED to have this, not just "aah, fuses, nice to have, sometimes, for something".
But as time goes on, the market for a P2 is shrinking, a lot of forumistas went on to other processors or even died of age.
I am aware that my opinion is quite biased, since I personally have no need for code-security. The only P1 product I ever sold got sold 1 (one) time by propellerpowered.com and even that sale was not really successful, since Propellerpowered never paid me for it and never returned the other 49 Kits.
So skip the security and get the wonderful chip out.
Cluso99, the biggest NV offerings OnSemi has for the ONC18 process is 1K bits of EE-type or 128 bits of fuses, per instance. I'm still waiting to hear from them if we can shave those fuses down to 120nm widths. That could make our current circuit work as planned, so that there would be code protection.
I did not realize that the fuses where bound to the pins. That would mean the security features, would not work on smaller P2-Family-Members.
Delaying the P2 again, is simply a nono. It does not matter, that some people NEEDING security would not buy it, if NOBODY is able to buy it, since it is not for sale at all.
And, if the P2 is used in connection with the internet, one can easy prevent theft/cloning by interlocking P2 and inet-server-software.
what could help would be a serial-number burned in at production time of the chip, but even that seems to be to expensive.
How about a poll, either here in the forum or Parallax asking their existing volume customers about the NEED to have this, not just "aah, fuses, nice to have, sometimes, for something".
But as time goes on, the market for a P2 is shrinking, a lot of forumistas went on to other processors or even died of age.
I am aware that my opinion is quite biased, since I personally have no need for code-security. The only P1 product I ever sold got sold 1 (one) time by propellerpowered.com and even that sale was not really successful, since Propellerpowered never paid me for it and never returned the other 49 Kits.
So skip the security and get the wonderful chip out.
Mike
We could remove the fuses from the pins and put them into their own block for future variants of the chip. That is no problem. We won't be needing 64 I/O pins to get 256 fuses. It's just the current layout.
aah, thanks. I was thinking that there was a hw-reason to have them next to the pins.
You are doing a fantastic work here, and I follow the P2 threads with great interest. Since a decade now, I read the Parallax Forums almost daily. I will have to buy a P2-bord, or I have no clue what to do with all the time freed up by not following the P2-Saga like other people watching Dr.Who or Mash.
I love to program in PASM, so I will not need much SPIN or C, but how is the state there, at the software front? Are the opcodes now final? How is SPIN2 coming along and have the C-guys everything they need to work on it?
Cluso99, the biggest NV offerings OnSemi has for the ONC18 process is 1K bits of EE-type or 128 bits of fuses, per instance. I'm still waiting to hear from them if we can shave those fuses down to 120nm widths. That could make our current circuit work as planned, so that there would be code protection.
Then the question may be "What process do you use to make Flash and EEPROM I2C and SPI memory chips?" and "Do you make micros with embedded Flash and/or EEPROM for customers, and if so, what process?"
Say it is in their 360nm process. Then possibly you could put a 360nm sized block in the ONC18 process (i.e. don't scale it) ???
I agree you need to move on, but in the background you should really perservere in asking these questions. There are answers, you just haven't asked the right questions or asked the right person. Maybe the "FUSE" question is confusing them.
Cluso99, the biggest NV offerings OnSemi has for the ONC18 process is 1K bits of EE-type or 128 bits of fuses, per instance. I'm still waiting to hear from them if we can shave those fuses down to 120nm widths. That could make our current circuit work as planned, so that there would be code protection.
Then the question may be "What process do you use to make Flash and EEPROM I2C and SPI memory chips?" and "Do you make micros with embedded Flash and/or EEPROM for customers, and if so, what process?"
Say it is in their 360nm process. Then possibly you could put a 360nm sized block in the ONC18 process (i.e. don't scale it) ???
I agree you need to move on, but in the background you should really perservere in asking these questions. There are answers, you just haven't asked the right questions or asked the right person. Maybe the "FUSE" question is confusing them.
The guy I was talking to yesterday at OnSemi said that it was difficult to get the answers I need, since we are assigned to the GDS-handoff business unit at OnSemi. If we could get connected with another unit, like the RTL-handoff group, it would be easier to get answers.
aah, thanks. I was thinking that there was a hw-reason to have them next to the pins.
You are doing a fantastic work here, and I follow the P2 threads with great interest. Since a decade now, I read the Parallax Forums almost daily. I will have to buy a P2-bord, or I have no clue what to do with all the time freed up by not following the P2-Saga like other people watching Dr.Who or Mash.
I love to program in PASM, so I will not need much SPIN or C, but how is the state there, at the software front? Are the opcodes now final? How is SPIN2 coming along and have the C-guys everything they need to work on it?
just curious,
Mike
We are waiting for OnSemi to begin the synthesis work. They should have some word early next week on how to proceed. So, yes, the opcodes are pretty much nailed down. OnSemi knows that we would like this done by the end of the year. Then, a two-month shuttle wait and maybe we'll have something for real.
So where does this leave things? If the schematic isn't changing presumably there are still bespoke fuses in the pin pads, but I gather the mask rom code will ignore their state
Cluso99, the biggest NV offerings OnSemi has for the ONC18 process is 1K bits of EE-type or 128 bits of fuses, per instance..
What voltage does the OnSemi Fuse need ?
What is the status of 1k of EE-type - I thought OnSemi needed some reference, and probing ?
What is the probing for, and what yield result with simpler post assembly test ?
What reference is needed, and can the 1.8V Vcc regulator not do that ?
It is nice to be able to scale Vcc, right down to RAM retention voltages. but if EE READ is only possible over a lesser range, that's ok.
It's also ok, if EE WRITE is over an even narrower Vcc range.
The guy I was talking to yesterday at OnSemi said that it was difficult to get the answers I need, since we are assigned to the GDS-handoff business unit at OnSemi. If we could get connected with another unit, like the RTL-handoff group, it would be easier to get answers.
That's why I think you need a face-to-face at OnSemi, to nail down the EE side of things.
So where does this leave things? If the schematic isn't changing presumably there are still bespoke fuses in the pin pads, but I gather the mask rom code will ignore their state
I am not sure about the fate of the fuses. I want to hear if the foundry will let us narrow them to 120nm. That would be quite the unusual sign-off.
If the schematic isn't changing presumably there are still bespoke fuses in the pin pads, but I gather the mask rom code will ignore their state
The test chip due in a few days has a full set of fuses, so it can be used to get a real fuse curve histogram of Vcc/blow %.
If the tests show the fuses work fine ( good yields ), but need some special Vcc that is outside easy field use, they can still be usefully use to factory store a Serial Number, and oscillator measured-values.
We are waiting for OnSemi to begin the synthesis work. They should have some word early next week on how to proceed. So, yes, the opcodes are pretty much nailed down. OnSemi knows that we would like this done by the end of the year. Then, a two-month shuttle wait and maybe we'll have something for real.
So that means a P2 chip in March 2018? And maybe it could be demonstrated at an expo in April? That would be fantastic if it all came together by then!
jmg, I must have missed the update about the test chip. From my count, it should be due in about 6 weeks.
I was working on this from Chip 'The test chip shuttle is scheduled for September 15th."
- but you may be right, as I now see that does not say packaged and delivered to Parallax
Comments
There are no vias at all in these samples.
If you look at figure 4 you will notice the footprints of (believe it or not!!!) PRESSURE MICRO CONTACTS!!!!
Sponsored by Big Blue, for sure.
Henrique
If they say that their focus is AT THE FUSE, you could bet your most beloved pair of socks, that they will grab a pebble from the Moon, to attain the intended objective.
I believe that whith such an increase in geometry, the molten remains fluid for a longer time.
Enough for the action of surface tension forces, aglutinating the center region, like a strip of low temp solder does, when melt over glass by a hot iron.
I've actually recommended to Chip that we forgo code protect at this stage. The reason is diminishing returns, protracted inability to complete the product, extended costs and schedule and general unknowns. While the market certainly wants code protect, I'm very aware of the overall implications even this very small addition poses to the total effort. While you may not agree, at this stage it is most imperative for Chip to simply hold a course of his choice and finish the project.
The desired outcome would be small iterations to the product, over time. We will never have any traction if we can't get to the starting line.
Ken Gracey
Proceed with production.
The testing on those becomes largely free. If they work, the state machine can be revealed. If not, it remains a secret.
Do not tell us this is happening.
Problem solved.
I guess I am missing something here. Fuses can be used in a variety of ways. The basic uses would be to prevent theft and/or prevent corruption of the code by outside intervention.
If someone wants something bad enough, they will get it. There is no perfect form of security. Everything is vulnerable to someone. Fortunately most people would never steal anything and they would prefer to do business with honest people.
At the corporate level, theft would occur before the fuses get set. The security has to be multi-level and isn't helped one iota by fuses.
Hacking.
The highest uses for the P2 will probably involve a computer that is hooked up to the WWW. It seems to me that creating programming tools that have security options built into them is a pretty good way to protect the P2 from budding hackers. The PropTool is pretty secure and could easily be made more so. Make it easier to hide. Allow a user chosen serial number, pad the binary in a clever way, make the tools sensitive to their own padding.
At the same time, we are going to want some level of script-ability built into the tools to facilitate all kinds of uses. Scripting complicates tools-based security arrangements.
At some level, security and usability get traded against each other.
At the end of the day, security should be optional: something that a user can migrate to, not something that keeps them from getting started in the first place.
I really don't worry about theft... being hacked is another kettle of fish.
...PUF Physical Unclonable Function.
...Firmware Integrity Secure boot and JTAG protection
These are in the new Samsung $6.90 wifi module.
http://www.mouser.com/pdfdocs/ARTIK_053_Product_Brief.pdf
Whilst I do appreciate the motivation here. This kind of post bugs me. It basically says "I don't need feature X but I suspect some mythical prospective big customer Y might."
It might be better to just speak of our needs and desires rather than speculate about those of others.
I suspect building a secure device requires a lot more thought and development than time allows here. Never mind binary code security, what about security as an IoT, web, connected device?
Parallax is familiar with DEFCON. Those guys do their best to break everything. Might be an idea to talk to them first.
As such Ken, I'm with rjo__, "Thanks Jesus", let's get this chip out the door.
I'm expecting a test device to play with for Xmas (Chipmas)
I have robots with this type of functionality. I've also encountered one industrial control with same. Ended up making a big, fat, like good for 5 years battery backup. External, wired in parallel with the smallish (like they want the damn thing to fail, because service calls) one supplied. The robots actually do contain software on those funky PCMCIA flash cards, and have a flash storage, but the battery backs up encryption and global provisioning data. The entitlements aren't recoverable without a service call, but one can go through and manually provision again, axis defaults, etc... The industrial control was RAM. Lose it, and it's a brick. I watched the service tech arrive, call the mothership, get a one time distribution, load it and leave.
People do it. And it works, but it's somewhat scary for the end user.
If I had to judge when doing that could be indicated, I would have to say high value, low to mid volume specialized products would be a prime target.
As for encryption, we have another path available to us. DALLAS makes chips for this purpose, they are battery backed, can contain keys, and are used in systems that have boot media. A booter loads, brings system to service state, reads the DALLAS chip, gets a key, then decrypts the target environment. It's a dongle, essentially.
Honestly, I like these, because they are often socketed, or removable enough to be portable. Get a replacement machine, move the chip, boot, and go. I did this a number of times on SGI hardware running some seriously expensive software long past it's "best used by" date. Had them go shopping on e-bay, then I carefully cloned it all, moved the DALLAS chips, and could bring it all up on a new box. That kind of thing costs a bit more in the BOM, but it also leaves people some options, if they work for it, without also opening the door to more users than were agreed. FWIW.
I think Chip replied to one of your threads and thought it would work, Rayman
http://forums.parallax.com/discussion/131742/possible-that-prop-can-be-more-code-secure-than-other-mcus
P2 doesn't clear RAM on reset though, right?
Is that a problem?
edit: oops I see what you're saying. This approach uses cog ram rather than hub ram, not sure whether its possible to read cog ram after a reloaded or paired cog. Worth checking out
However, I am really disapointed this (and Flash/EEPROM/OTP) wasn't followed thru a loooong time ago. The solution is within OnSemi. Just need to get to the right person.
Delaying the P2 again, is simply a nono. It does not matter, that some people NEEDING security would not buy it, if NOBODY is able to buy it, since it is not for sale at all.
And, if the P2 is used in connection with the internet, one can easy prevent theft/cloning by interlocking P2 and inet-server-software.
what could help would be a serial-number burned in at production time of the chip, but even that seems to be to expensive.
How about a poll, either here in the forum or Parallax asking their existing volume customers about the NEED to have this, not just "aah, fuses, nice to have, sometimes, for something".
But as time goes on, the market for a P2 is shrinking, a lot of forumistas went on to other processors or even died of age.
I am aware that my opinion is quite biased, since I personally have no need for code-security. The only P1 product I ever sold got sold 1 (one) time by propellerpowered.com and even that sale was not really successful, since Propellerpowered never paid me for it and never returned the other 49 Kits.
So skip the security and get the wonderful chip out.
Mike
We could remove the fuses from the pins and put them into their own block for future variants of the chip. That is no problem. We won't be needing 64 I/O pins to get 256 fuses. It's just the current layout.
You are doing a fantastic work here, and I follow the P2 threads with great interest. Since a decade now, I read the Parallax Forums almost daily. I will have to buy a P2-bord, or I have no clue what to do with all the time freed up by not following the P2-Saga like other people watching Dr.Who or Mash.
I love to program in PASM, so I will not need much SPIN or C, but how is the state there, at the software front? Are the opcodes now final? How is SPIN2 coming along and have the C-guys everything they need to work on it?
just curious,
Mike
Say it is in their 360nm process. Then possibly you could put a 360nm sized block in the ONC18 process (i.e. don't scale it) ???
I agree you need to move on, but in the background you should really perservere in asking these questions. There are answers, you just haven't asked the right questions or asked the right person. Maybe the "FUSE" question is confusing them.
The guy I was talking to yesterday at OnSemi said that it was difficult to get the answers I need, since we are assigned to the GDS-handoff business unit at OnSemi. If we could get connected with another unit, like the RTL-handoff group, it would be easier to get answers.
We are waiting for OnSemi to begin the synthesis work. They should have some word early next week on how to proceed. So, yes, the opcodes are pretty much nailed down. OnSemi knows that we would like this done by the end of the year. Then, a two-month shuttle wait and maybe we'll have something for real.
So where does this leave things? If the schematic isn't changing presumably there are still bespoke fuses in the pin pads, but I gather the mask rom code will ignore their state
What voltage does the OnSemi Fuse need ?
What is the status of 1k of EE-type - I thought OnSemi needed some reference, and probing ?
What is the probing for, and what yield result with simpler post assembly test ?
What reference is needed, and can the 1.8V Vcc regulator not do that ?
It is nice to be able to scale Vcc, right down to RAM retention voltages. but if EE READ is only possible over a lesser range, that's ok.
It's also ok, if EE WRITE is over an even narrower Vcc range.
That's why I think you need a face-to-face at OnSemi, to nail down the EE side of things.
I am not sure about the fate of the fuses. I want to hear if the foundry will let us narrow them to 120nm. That would be quite the unusual sign-off.
The test chip due in a few days has a full set of fuses, so it can be used to get a real fuse curve histogram of Vcc/blow %.
If the tests show the fuses work fine ( good yields ), but need some special Vcc that is outside easy field use, they can still be usefully use to factory store a Serial Number, and oscillator measured-values.
- but you may be right, as I now see that does not say packaged and delivered to Parallax