They had at least two fuses per bit for redundancy due to them not being reliable, and then error detection/correction was applied. Maybe something to think about?
Good God, if it's that unpredictable please don't think about it at all. At least not past deciding to omit fuses from the design.
Can the code security still work even if some of the fuses don't blow?
Whilst I think it can still technically work, in the widest sense of the word, it could result in differing codes in every chip, which means a rebuild for the chip-dictated fuse-result, which becomes rather unworkable to manage in a production flow.
Chip,
Please please please ask OnSemi / Treehouse about OTP/Flash/EEPROM. You likely will find a simple and reliable solution which can also be used for the ROM too.
Here is one example of OTP IP, which mentions 180nm
" Sidense's SiFuse and SiPROM products with the 1T-Fuse architecture target highly secure applications, including encryption key storage and secure boot code, offering bit counts up to several megabits. Read access times are very fast, under 10 ns, and retention rates exceed 20 years. A built-in charge pump lets a customer program the macrocell in the field without the need for a separate programming power supply. An security lock is available to disable the programming voltage to segments and/or the entire macrocell, providing additional key storage security."
Sounds like it does need a Charge Pump, but the base cell is very compact.
If a fused and fuseless Prop were available tomorrow I'd be ordering the fuseless one.
Fuses make me uneasy, too. Personally, I'd rather not have them. People have been asking for code protection since Prop1, though.
@cgracey
aren't some of the fuses used also for other reasons (configuration?) beside the code protection?
Anyway, could you solve it differently? Eg by having a GUID somewhere in the ROM, which can be read if ONE fuse is not blown. In this way the code will always be protected but the protection key will always be allowed to be read unless disallowed by blown fuse. In this way you simply read the key from the silicon and then use it to crypt your code. If you want you can then blow this fuse. In this case at worst you will not be able to hide your key. And this could be tested. But in no case the key can change by itself due to issues with fuses.
Chip,
Please please please ask OnSemi / Treehouse about OTP/Flash/EEPROM. You likely will find a simple and reliable solution which can also be used for the ROM too.
FWIW, there have been many saying security is a prime requirement for P2. BTW it's not a requirement for me although I don't have any commercial P2 products planned.
However, if the ROM was OTP and you could test the P2 without programming any of the P2, then this could be used instead of fuses for security. It would be much simpler, and you could sell programmed OTP without security as the default.
I sent our contacts at OnSemi an email this morning about our fuse issues. I asked for any data they might have about blow voltages/currents and reliability.
Fuses seem like the safest way to implement security, as they are quite permanent. I would hate to see a key fade after 20 years and cause something to stop working.
...And I sure wouldn't be comfortable if the P2's success depended on anyone's prayers (or lack thereof)...
Prayer helps. I had all kinds of promptings during Prop1 development to go back and look at something, and then doing so and realizing there was a latent problem that needed addressing. Prop2 has been a very long project, but inspiration is still coming for it, so I think God must have some plan. That you guys are all here and have contributed so much confirms that. We're almost there, now.
Chip - for what it's worth I worked at a large company which implemented fuses in most chips. They had at least two fuses per bit for redundancy due to them not being reliable, and then error detection/correction was applied. Maybe something to think about?
I don't have experience because I never worked with them since they weren't a good fit for our designs due to some requirements that they imposed. But the default was for every chip to have them. Manufacturing liked it for RMAs because they would know the history of each serialized chip. (Which tester was used, which test program,...)
That's telling. If they were deemed not reliable, we could implement redundancy, too. It's just a matter of the ROM software treating things differently.
We have 256 fuses. The idea has been that 128 of them will provide a SHA-256/HMAC key and the other 128 will be for the user. We could change the ROM firmware so that something like this is done:
The first 128 fuses are OR'd with the second 128 fuses to form a 128-bit code.
If the first byte equals some special constant (say, $A5), security is ON and the entire 128-bit code is the key.
If the first byte doesn't equal the special constant, security is OFF.
The fuse that never blows takes 80mA for as long as the blow signal is applied. Maybe it did not blow cleanly and is now in some kind of crashed state.
Here is the schematic of the fuse blower and reader:
When the fuse blows, it should be in the megohms. It's only being compared to ~860 ohms. The 'rnpolys' resistor is an N+ silicided poly resistor, which is very low-impedance, so that it fries.
What is the P-FET RDs and the Fuse R ? (is it 55.54 ohms nominal as labeled ?)
80mA maps to values like this ( % Loss assumed across PFET)
10% -> 37.125 ohms
20% -> 33 ohms
30% -> 28.875
40% -> 16.5
so maybe this N+ silicided poly resistor has a fuse-physics that includes dropping in Resistance as it cooks, before it finally opens ?
Captured current curves may show that effect ?
What can the P-FET drive into a short ?
Three is a quite small sample size, can you do 2+ more chips, to get > 10 +?
700us & 10us seems a pretty large variation.
Thought about this some more, and I think more measurements are needed. 70:1 is a big change.
Measurement Suggestions:
* Measure the initial Resistance of the Fuse and PFet, which should be possible in that circuit.
* Take 10 or even 20 chips, and test 50% at Vcc min and 50% at Vcc max
* Capture the Current-time curve for every fuse, and look for column correlations.
On that one test chip where I couldn't get the fuse to blow, I upped the VIO from 3.3V to 3.6V and it finally blew!
I just simulated the fuse circuit and that big PMOS is delivering 51mA into the fuse at 2.83V. That means the fuse is initially dissipating 145mW. Being only 180nm x 1440nm, that's a power density of 56MW/cm2, with a capital M. You'd think that would certainly be enough to nuke it.
The reason for the PMOS blow transistor, as opposed to an NMOS, is to enable GND-based sensing of the fuse state from the 1.8V core circuitry.
What if you make it so that when you initially send the command to burn the fuses, the response will specify which ones actually blew? Then, you can try to burn some fuses, see which ones actually blew, and then use that for the key. Obviously, this can only be done once, i.e. if no fuses were blown on boot.
The only disadvantage of this would be that every unit might need a different key.
I think by using 2:1 redundancy, we can safely overcome the uncertainty problems.
How much area do these Fuses/readers need as a portion of die ? ie x2 minimal ?
Each I/O pin has four fuse instances. They each take about 25x30 um. By hiding them in the I/O pins, they don't take exceptional space. Beau had the idea of putting them into the pins. When we make smaller devices with fewer I/O's, we'll have to make up for lost fuses by putting them into the die corners.
Prop2 has been a very long project, but inspiration is still coming for it, so I think God must have some plan. That you guys are all here and have contributed so much confirms that. We're almost there, now.
When all of the Monster Corp. "SpyOS"es become completely hacked to oblivion and the mere idea of running a system that won't get hosed as soon as it's connected to the Internet is laughable (we are already there!!), the only thing that we will be able to fall back on are simple systems that an individual can understand from A to Z.
A P2 running Forth or a simple, from the ground up, community OS (NOT Linux) is literally what will keep digital communication running. NOTHING else will be trustworthy or securable.
I STRONGLY encourage this community to think of ways to use the P2 to create a "Nano Computing" environment. That includes trustworthy personal computing devices and networking equipment.
Yes, I think there is a plan. Its a backup plan for the eventual failure of all Monster Corp systems.
If this sounds outlandish to some... then it's time to start reading the news. The state of electronic security is in shambles and, I think, the best way to address it is to radically simplify everything.
I say, Bring on the P2!!
The world could really use it!
Chip - for what it's worth I worked at a large company which implemented fuses in most chips. They had at least two fuses per bit for redundancy due to them not being reliable, and then error detection/correction was applied. Maybe something to think about?
I don't have experience because I never worked with them since they weren't a good fit for our designs due to some requirements that they imposed. But the default was for every chip to have them. Manufacturing liked it for RMAs because they would know the history of each serialized chip. (Which tester was used, which test program,...)
That's telling. If they were deemed not reliable, we could implement redundancy, too. It's just a matter of the ROM software treating things differently.
I don't think that is quite what KeithE was meaning.
If you have some significant yield issue on a fuse, it is hard to patch that higher - you really need two fuses that you OR when reading, and if EITHER is blown, that is locally read as blown.
This takes a 5% failure, and pushes to 0.25%
A 3-way OR, drops a 5% per-fuse rate to 0.0125%
Of course, multiply that by an average of 64 fuses you expect valid for SHA, and the numbers are still depressing...
There may be some programming rules, that can influence yield, which is why more measurements are needed.
The 80mA stable you quoted is especially a concern, as that indicates a current path might not be through the resistor. I wonder if the melting has gone down to substrate - a decrease in resistance below some thermal-threshold could give such a failure mode.
The images I posted above, I think show metal-layer fuses, which may have less risk of wrong-way failure.
We have 256 fuses. The idea has been that 128 of them will provide a SHA-256/HMAC key and the other 128 will be for the user. We could change the ROM firmware so that something like this is done:
The first 128 fuses are OR'd with the second 128 fuses to form a 128-bit code.
If the first byte equals some special constant (say, $A5), security is ON and the entire 128-bit code is the key.
If the first byte doesn't equal the special constant, security is OFF.
That would make it hard to brick a chip.
Yes and no.
If you are in production, you are less interested in if you 'might still use that chip for something else' - a 'failure to secure', is a production brick.
When all of the Monster Corp. "SpyOS"es become completely hacked to oblivion and the mere idea of running a system that won't get hosed as soon as it's connected to the Internet is laughable (we are already there!!), the only thing that we will be able to fall back on are simple systems that an individual can understand from A to Z.
I know what you are driving at.
Problem is, maybe I can understand a smaller, simpler system from top to bottom. But that in no way makes it secure. Not if it's networked to the world anyway.
A P2 running Forth or a simple, from the ground up, community OS (NOT Linux) is literally what will keep digital communication running. NOTHING else will be trustworthy or securable.
I'm doomed then. I will not live long enough to understand Forth
Prop2 has been a very long project, but inspiration is still coming for it, so I think God must have some plan. That you guys are all here and have contributed so much confirms that. We're almost there, now.
When all of the Monster Corp. "SpyOS"es become completely hacked to oblivion and the mere idea of running a system that won't get hosed as soon as it's connected to the Internet is laughable (we are already there!!), the only thing that we will be able to fall back on are simple systems that an individual can understand from A to Z.
A P2 running Forth or a simple, from the ground up, community OS (NOT Linux) is literally what will keep digital communication running. NOTHING else will be trustworthy or securable.
I STRONGLY encourage this community to think of ways to use the P2 to create a "Nano Computing" environment. That includes trustworthy personal computing devices and networking equipment.
Yes, I think there is a plan. Its a backup plan for the eventual failure of all Monster Corp systems.
If this sounds outlandish to some... then it's time to start reading the news. The state of electronic security is in shambles and, I think, the best way to address it is to radically simplify everything.
I say, Bring on the P2!!
The world could really use it!
I imagine the same kinds of things possibly happening.
The 80mA stable you quoted is especially a concern, as that indicates a current path might not be through the resistor. I wonder if the melting has gone down to substrate - a decrease in resistance below some thermal-threshold could give such a failure mode.
I ran the simulation again with the fuse completely shorted to GIO (same as GND). That big PMOS conducts 128mA.
On that one test chip where I couldn't get the fuse to blow, I upped the VIO from 3.3V to 3.6V and it finally blew!
That's certainly good news, as it seems to exclude unexpected fuse current paths.
Did you happen to capture the fuse current/time when that reluctant one blew ?
This still represents some very large, hard to explain, variations in fusing time ?
(These are all with new stable regulators on 3v3 and 1.8V ?)
I just simulated the fuse circuit and that big PMOS is delivering 51mA into the fuse at 2.83V. That means the fuse is initially dissipating 145mW. Being only 180nm x 1440nm, that's a power density of 56MW/cm2, with a capital M. You'd think that would certainly be enough to nuke it.
One puzzle: With 51mA thru a (cold?) fusing resistor, where exactly does the 80mA you reported come from ?
Given those power densities, the 'time to 1000'C' fuse metric, should be short and predictable.
What is the PMOS area, for its ~24mW starting power ?
I ran the simulation again with the fuse completely shorted to GIO (same as GND). That big PMOS conducts 128mA.
Is that 3.3 or 3.6V sim ? - What PMOS temperature ? (that 128mA at 3v3, is a large 422mW, which would be a very hot PMOS)
If you did measure 80mA, that indicates what could be either a partial substrate short or some unexpected lowering in Rvalue, that seemed to be stable.
Suppose the fuse-resistor fails/lowers, what are the possible secondary fuse paths ?
Is the layout such that a Metal Migrate fuse would be present, that could blow at 3.6V ?
All these simulations have been done at 'typical'.
The most logical explanation to me is that we did get an initial fuse melt, but it shorted to substrate, becoming more of a booger than a line, and the mass subsequently took a lot more current to blow open. It's probably messy, with the 'open' edging into the contact area of the poly.
Here's the fuse block layout, from contact layer on down. The block is actually 42x45 um:
Problem is, maybe I can understand a smaller, simpler system from top to bottom. But that in no way makes it secure. Not if it's networked to the world anyway.
Yeah, my post came out more "ranty" than I wanted :-(
I just see the P2 opening the door to vast opportunities which include simpler systems.
The reason for the PMOS blow transistor, as opposed to an NMOS, is to enable GND-based sensing of the fuse state from the 1.8V core circuitry.
Just looking at that Fuse-Sense amp, is it OK to use 1.8V FETS there, when it can have 3v3 during Fuse-blow ?
Being a large-L device, it can't conduct that much. So, even though voltage will be out of spec for 1ms, at some point, there won't be enough current to cause any problems.
The 3.3V ADC uses some thin-oxide 180nm NMOS transistors to switch currents, since they provide a sharper on/off with lower capacitance than 3.3V devices. Those transistors see ~1.65V on both their drains and sources, while their gates switch between 0V and 3.3V. If the ADC is off, they will leak enough to neutralize charges within the ADC. They improved the ADC performance quite a bit.
I sent our contacts at OnSemi an email this morning about our fuse issues. I asked for any data they might have about blow voltages/currents and reliability.
Fuses seem like the safest way to implement security, as they are quite permanent. I would hate to see a key fade after 20 years and cause something to stop working.
"Traditional eFuses as shown in Figure 2 are made of polysilicon or metals and are
programmed by rupturing the conductor links. In addition to strict requirements for
surrounding passivation and metals, these Fuses had unacceptable reliability because debris
and shards can cause healing over time. "
Looks like that "quite permanent" is more hope than reality ?
They do mention a move to electromigration :
["Modern eFuse is built on polysilicon with Cobalt or Nickel silicide on top. The fuse is
programmed by a well-known reliability mechanism called electromigration in which
electron momentum pushes the silicide atoms out of the conductor link. "]
No mention of the current densities needed for that, but OnSemi might know ?
Perhaps there is more of an electro-migration intent with OnSemi giving design rules for fuses. There is some kind of metal silicide on the poly. I haven't heard back from them, yet.
I have zero knowledge about electrical things at this scale but I was wondering how you were conducting the test. If you're slowly increasing the voltage to see when the fuse blows then there's the possibility that it just goes molten and doesn't blow. A quick voltage rise would create thermal stresses inside the material which might give you a better result.
I have zero knowledge about electrical things at this scale but I was wondering how you were conducting the test. If you're slowly increasing the voltage to see when the fuse blows then there's the possibility that it just goes molten and doesn't blow. A quick voltage rise would create thermal stresses inside the material which might give you a better result.
I can only give a 'blow' signal from outside the chip, which fully turns on a big PMOS FET that dumps lots of current into the fuse. The only variability would be in lowering or raising the 3.3V supply.
Doesn't sound quite as secure as these internal fuse bits though...
Looking at something like the Atmel ATSHA204A, I can see how this would have all sorts of potential uses! However, in order to securely boot, wouldn't this required the boot ROM to know about this (or any other specific) chip? In other words, wouldn't you end up with the P2 being married to a specific third-party chip?
Comments
I like KeithE's multiple fuses per bit suggestion...
Yes, that seems a simple extension.
How much area do these Fuses/readers need as a portion of die ? ie x2 minimal ?
Here is one example of OTP IP, which mentions 180nm
http://www.design-reuse.com/articles/16054/otp-for-dcp-key-storage.html
" Sidense's SiFuse and SiPROM products with the 1T-Fuse architecture target highly secure applications, including encryption key storage and secure boot code, offering bit counts up to several megabits. Read access times are very fast, under 10 ns, and retention rates exceed 20 years. A built-in charge pump lets a customer program the macrocell in the field without the need for a separate programming power supply. An security lock is available to disable the programming voltage to segments and/or the entire macrocell, providing additional key storage security."
Sounds like it does need a Charge Pump, but the base cell is very compact.
Addit : Here is an eFuse paper
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.819.6746&rep=rep1&type=pdf
Programs with 5V in 200us, on 180nm
This uses Electro-Migration, but they do not give the drive current, or resistance but there is nice a SEM image.
@cgracey
aren't some of the fuses used also for other reasons (configuration?) beside the code protection?
Anyway, could you solve it differently? Eg by having a GUID somewhere in the ROM, which can be read if ONE fuse is not blown. In this way the code will always be protected but the protection key will always be allowed to be read unless disallowed by blown fuse. In this way you simply read the key from the silicon and then use it to crypt your code. If you want you can then blow this fuse. In this case at worst you will not be able to hide your key. And this could be tested. But in no case the key can change by itself due to issues with fuses.
Of course the other solution is OTP.
It's the only means available through the design rules.
I sent our contacts at OnSemi an email this morning about our fuse issues. I asked for any data they might have about blow voltages/currents and reliability.
Fuses seem like the safest way to implement security, as they are quite permanent. I would hate to see a key fade after 20 years and cause something to stop working.
Prayer helps. I had all kinds of promptings during Prop1 development to go back and look at something, and then doing so and realizing there was a latent problem that needed addressing. Prop2 has been a very long project, but inspiration is still coming for it, so I think God must have some plan. That you guys are all here and have contributed so much confirms that. We're almost there, now.
That's telling. If they were deemed not reliable, we could implement redundancy, too. It's just a matter of the ROM software treating things differently.
We have 256 fuses. The idea has been that 128 of them will provide a SHA-256/HMAC key and the other 128 will be for the user. We could change the ROM firmware so that something like this is done:
If the first byte equals some special constant (say, $A5), security is ON and the entire 128-bit code is the key.
If the first byte doesn't equal the special constant, security is OFF.
That would make it hard to brick a chip.
On that one test chip where I couldn't get the fuse to blow, I upped the VIO from 3.3V to 3.6V and it finally blew!
I just simulated the fuse circuit and that big PMOS is delivering 51mA into the fuse at 2.83V. That means the fuse is initially dissipating 145mW. Being only 180nm x 1440nm, that's a power density of 56MW/cm2, with a capital M. You'd think that would certainly be enough to nuke it.
The reason for the PMOS blow transistor, as opposed to an NMOS, is to enable GND-based sensing of the fuse state from the 1.8V core circuitry.
I think by using 2:1 redundancy, we can safely overcome the uncertainty problems.
Each I/O pin has four fuse instances. They each take about 25x30 um. By hiding them in the I/O pins, they don't take exceptional space. Beau had the idea of putting them into the pins. When we make smaller devices with fewer I/O's, we'll have to make up for lost fuses by putting them into the die corners.
When all of the Monster Corp. "SpyOS"es become completely hacked to oblivion and the mere idea of running a system that won't get hosed as soon as it's connected to the Internet is laughable (we are already there!!), the only thing that we will be able to fall back on are simple systems that an individual can understand from A to Z.
A P2 running Forth or a simple, from the ground up, community OS (NOT Linux) is literally what will keep digital communication running. NOTHING else will be trustworthy or securable.
I STRONGLY encourage this community to think of ways to use the P2 to create a "Nano Computing" environment. That includes trustworthy personal computing devices and networking equipment.
Yes, I think there is a plan. Its a backup plan for the eventual failure of all Monster Corp systems.
If this sounds outlandish to some... then it's time to start reading the news. The state of electronic security is in shambles and, I think, the best way to address it is to radically simplify everything.
I say, Bring on the P2!!
The world could really use it!
I don't think that is quite what KeithE was meaning.
If you have some significant yield issue on a fuse, it is hard to patch that higher - you really need two fuses that you OR when reading, and if EITHER is blown, that is locally read as blown.
This takes a 5% failure, and pushes to 0.25%
A 3-way OR, drops a 5% per-fuse rate to 0.0125%
Of course, multiply that by an average of 64 fuses you expect valid for SHA, and the numbers are still depressing...
There may be some programming rules, that can influence yield, which is why more measurements are needed.
The 80mA stable you quoted is especially a concern, as that indicates a current path might not be through the resistor. I wonder if the melting has gone down to substrate - a decrease in resistance below some thermal-threshold could give such a failure mode.
The images I posted above, I think show metal-layer fuses, which may have less risk of wrong-way failure.
Yes and no.
If you are in production, you are less interested in if you 'might still use that chip for something else' - a 'failure to secure', is a production brick.
Problem is, maybe I can understand a smaller, simpler system from top to bottom. But that in no way makes it secure. Not if it's networked to the world anyway.
I'm doomed then. I will not live long enough to understand Forth
I imagine the same kinds of things possibly happening.
I ran the simulation again with the fuse completely shorted to GIO (same as GND). That big PMOS conducts 128mA.
That's certainly good news, as it seems to exclude unexpected fuse current paths.
Did you happen to capture the fuse current/time when that reluctant one blew ?
This still represents some very large, hard to explain, variations in fusing time ?
(These are all with new stable regulators on 3v3 and 1.8V ?)
One puzzle: With 51mA thru a (cold?) fusing resistor, where exactly does the 80mA you reported come from ?
Given those power densities, the 'time to 1000'C' fuse metric, should be short and predictable.
What is the PMOS area, for its ~24mW starting power ?
If you did measure 80mA, that indicates what could be either a partial substrate short or some unexpected lowering in Rvalue, that seemed to be stable.
Suppose the fuse-resistor fails/lowers, what are the possible secondary fuse paths ?
Is the layout such that a Metal Migrate fuse would be present, that could blow at 3.6V ?
All these simulations have been done at 'typical'.
The most logical explanation to me is that we did get an initial fuse melt, but it shorted to substrate, becoming more of a booger than a line, and the mass subsequently took a lot more current to blow open. It's probably messy, with the 'open' edging into the contact area of the poly.
Here's the fuse block layout, from contact layer on down. The block is actually 42x45 um:
Yeah, my post came out more "ranty" than I wanted :-(
I just see the P2 opening the door to vast opportunities which include simpler systems.
Being a large-L device, it can't conduct that much. So, even though voltage will be out of spec for 1ms, at some point, there won't be enough current to cause any problems.
The 3.3V ADC uses some thin-oxide 180nm NMOS transistors to switch currents, since they provide a sharper on/off with lower capacitance than 3.3V devices. Those transistors see ~1.65V on both their drains and sources, while their gates switch between 0V and 3.3V. If the ADC is off, they will leak enough to neutralize charges within the ADC. They improved the ADC performance quite a bit.
I find this paper that mentions eFuse
http://www.kilopass.com/wp-content/uploads/2010/04/comparison_of_embedded_nvm.pdf
"Traditional eFuses as shown in Figure 2 are made of polysilicon or metals and are
programmed by rupturing the conductor links. In addition to strict requirements for
surrounding passivation and metals, these Fuses had unacceptable reliability because debris
and shards can cause healing over time. "
Looks like that "quite permanent" is more hope than reality ?
They do mention a move to electromigration :
["Modern eFuse is built on polysilicon with Cobalt or Nickel silicide on top. The fuse is
programmed by a well-known reliability mechanism called electromigration in which
electron momentum pushes the silicide atoms out of the conductor link. "]
No mention of the current densities needed for that, but OnSemi might know ?
This paper comes at it from another angle, and uses 1e6A/cm2 for accelerated failures
http://web.stanford.edu/class/ee311/NOTES/Interconnect_Al.pdf
Perhaps there is more of an electro-migration intent with OnSemi giving design rules for fuses. There is some kind of metal silicide on the poly. I haven't heard back from them, yet.
I can only give a 'blow' signal from outside the chip, which fully turns on a big PMOS FET that dumps lots of current into the fuse. The only variability would be in lowering or raising the 3.3V supply.
http://embedded-computing.com/articles/protect-control-software-stored-flash-memory/#
Doesn't sound quite as secure as these internal fuse bits though...
Looking at something like the Atmel ATSHA204A, I can see how this would have all sorts of potential uses! However, in order to securely boot, wouldn't this required the boot ROM to know about this (or any other specific) chip? In other words, wouldn't you end up with the P2 being married to a specific third-party chip?