The chip's transistors couldn't handle that kind of voltage. Even 4V would be pushing it. As it is, 3.3V should blow the fuses.
For high-voltage programming, wouldn't you have a small section of the circuit designed to take the high voltage, and have the rest of the chip sealed off? I'm thinking of ancient EEPROM-based PICs and AVRs that take 12V on the reset pin in order to program the chip.
Could "fuses" be made with small mosfets with a barrier that takes voltage to breakdown and charge the gate of the fet? Isn't that how old EPROMs worked?
A question about the fuses: Once a subset of them has been blown, can more of them be blown? If so, it would not only be easy for a customer to override the protection by blowing all the fuses; but also, with 128 identically-secured chips, it would be easy to discover the key.
For high-voltage programming, wouldn't you have a small section of the circuit designed to take the high voltage, and have the rest of the chip sealed off? I'm thinking of ancient EEPROM-based PICs and AVRs that take 12V on the reset pin in order to program the chip.
Could "fuses" be made with small mosfets with a barrier that takes voltage to breakdown and charge the gate of the fet? Isn't that how old EPROMs worked?
You could probably build structures that could handle higher voltages. I imagine you could cascade PMOS's with hot NWELLs, up to the NWELL breakdown voltage, but we wanted things to work at 3.3V.
(E)EPROM circuits use floating gates to store a charge. This logic process we are using doesn't have that circuit possibility. So, we built fuses from silicided poly strands that we can blow with 3.3V. One side connects to GND and the other to 3.3V via a big PMOS with a channel width of 300um.
Yes, there is a master fuse which logically inhibits further fuse programming. If we were to have 256 fuses (128 for SHA, 128 for AES) we would still need one more for the master fuse.
A question about the fuses: Once a subset of them has been blown, can more of them be blown? If so, it would not only be easy for a customer to override the protection by blowing all the fuses; but also, with 128 identically-secured chips, it would be easy to discover the key.
-Phil
Right. That's why there must be a master fuse to inhibit further programming. At this point, it seems that when someone sets the fuses, they need to do it all at once, including blowing the master fuse. Then, things are set for that chip.
(E)EPROM circuits use floating gates to store a charge. This logic process we are using doesn't have that circuit possibility.
This is probably a huge, off-topic question, but why? The company I work for has a partnership with Microchip, and I remember their reps once saying that they put flash memory in LDOs, using flash cells to select the resistor dividers on a chip-by-chip basis so they can have a single mask for all their regulators, and they just program them from the factory to the voltage they are sold at. Since that's the cheapest way for them to do that, I figure flash can't be too expensive of a process.
Does flash preclude other process features that you are using?
You'd need a second poly layer with some thin oxide on one side, so that you could tunnel electrons into it. EEPROM/FLASH processes have that structure possibility. Bulk CMOS logic processes don't. We're using a more-or-less standard 180nm logic process.
This may sound like a stupid question, but when you talk about "blowing" fuses, I envision a conductor being vaporized. If that's what happens -- and it seems like an extreme event on a micro-scale -- how do you prevent collateral damage to nearby structures?
More accurately, like breaking a rope, make the rope thin enough to not break anything else around when it goes. The fuses don't actually vaporize, but they melt just enough to get an open circuit. That way, there's no worry about metal vapors depositing on nearby circuits and shorting them.
Also, I just found this: Breaking copy protection in microcontrollers. It seems to mostly cover things that have already been said, but it's a reasonably comprehensive source in one place.
Have a google for "electron microscope ESD chip damage" or such. Should turn up some nice images. Fuses would just be bigger I guess. My friend was making images of blown chips like that in the 1980s. There is no defence against this attack.
This may sound like a stupid question, but when you talk about "blowing" fuses, I envision a conductor being vaporized. If that's what happens -- and it seems like an extreme event on a micro-scale -- how do you prevent collateral damage to nearby structures?
-Phil
It IS like you imagine. I calculated the power density this morning, but it seemed surreal: a fuse of .18um x 1.8um is 324 square femtometers. It has an initial resistance of 80 ohms, since the sheet resistance of silicided P+ poly is 8 ohms per square and the aspect ratio is 10x1. So, the the power density (Watts/area) is (E^2)/R / area, or (3.3^2)/80 / 324fm2, which comes to 0.136W / 342fm2, or 398GW/m2, or 39MW/cm2!
Some people at Tanner, who make our IC tools, had sent me some pdf's on the subject and we followed the aggregate guidelines. Now, we just hope they work.
The fuses don't actually vaporize, but they melt just enough to get an open circuit. That way, there's no worry about metal vapors depositing on nearby circuits and shorting them.
Have a google for "electron microscope ESD chip damage" or such. Should turn up some nice images. Fuses would just be bigger I guess. My friend was making images of blown chips like that in the 1980s. There is no defence against this attack.
As most electron microscopes require the layer of interest to be exposed and metalized, it doesn't matter if an electron microscope can see the damage as the attacker can already physically probe the fuses. (well, except for extremely high energy transmission microscopes that can just blast electrons through the whole mess. I.e. >$$$$$$$$) Phill's question vs X-rays is far more relevant, as X-rays readily penetrate objects. (though getting a <100um resolution could get expensive? at least $$$$$$ I hope?) Medical X-ray machines are unlikely to have the resolution to look at the fuses, but I'm less sure about industrial X-ray machines used for inspection of BGA solder joints, and other small items.
One problem with the authentication-only idea is customers would expect (nay, require) Parallax to provide a reference implementation of the encryption function. So going that route doesn't relieve Parallax from any effort or risk. Having the encryption routine offchip also increases the BoM to the additional storage space and increases the boot time. One other advantage of putting the encryption in ROM is it might be possible to expose it to customer code as a kind of library function which customers could then use to encrypt code & data beyond the initial load.
The Prop2 has 126K of RAM because 2K of RAM is turned into ROM. This is the same amount of space required for the bootloader and signature. The first 2K of the EEPROM is bootloader and signature, the remaining 126K is the memory image. You only need a 128K EEPROM for the whole shebang.
Except now you introduce three problems:
1. Your customer now has to have a different signed binary per revision of ic.
2. The cost involved in changing the die per run.
3. You actually reduced the entropy of the system by making a proportion of the keyspace predictable.
The customer determines the key, they may want to produce a "lite" and "premium" version of a product and distinguish that with the fuse bits.
No die change, fuse bits.
Only the customer knows the bits, and since all devices in a family have the same key, the situation is the same for an attacker. The attacker has no way of knowing there are reserved bits.
128 bits or 256 bits for fuses is splitting hairs. 128 bits is sufficient for 20 year data security, 256 is good for 50 years. Adding more bits only further intensifies the attacks on developers directly.
Whether it's "kosher" for the 128 bit key to be used for signing and encryption, intuitively I would think yes, however this is crossing the line of practical and theoretical, I would ask that question to Bruce Schneier.
160 bits is pretty cool, since that's 128 bit key, family codes, serials, etc.
The resources required for a brute-force attack grow exponentially with increasing key size, not linearly. As a result, doubling the key size for an algorithm does not simply double the required number of operations, but rather squares them. Although US export regulations historically restricted key lengths to 56-bit symmetric keys (e.g. Data Encryption Standard), these restrictions are no longer in place, so modern symmetric algorithms typically use computationally stronger 128- to 256-bit keys. The table below illustrates how much more complex a 128-bit key is than a 56-bit key. If a device existed that could brute-force a 56-bit encryption key in one second, it would take that device 149.7 trillion years to brute-force a 128-bit encryption key.
Correct. What I meant was that both keys can be 128 bits, but key1 could use bits 0 .. 127, and key2 could use bits 32 .. 159, for example, if you didn't want the keys to be identical.
Correct. What I meant was that both keys can be 128 bits, but key1 could use bits 0 .. 127, and key2 could use bits 32 .. 159, for example, if you didn't want the keys to be identical.
-Phil
That's an interesting notion, certainly a question to ask a crypto expert.
You still would only have 160 bits of total encryption no matter how you sliced it... the overlap just adds a 32 bit layer on top of the 128 bit encryption method used.
Comments
Could "fuses" be made with small mosfets with a barrier that takes voltage to breakdown and charge the gate of the fet? Isn't that how old EPROMs worked?
A question about the fuses: Once a subset of them has been blown, can more of them be blown? If so, it would not only be easy for a customer to override the protection by blowing all the fuses; but also, with 128 identically-secured chips, it would be easy to discover the key.
-Phil
You could probably build structures that could handle higher voltages. I imagine you could cascade PMOS's with hot NWELLs, up to the NWELL breakdown voltage, but we wanted things to work at 3.3V.
(E)EPROM circuits use floating gates to store a charge. This logic process we are using doesn't have that circuit possibility. So, we built fuses from silicided poly strands that we can blow with 3.3V. One side connects to GND and the other to 3.3V via a big PMOS with a channel width of 300um.
Right. That's why there must be a master fuse to inhibit further programming. At this point, it seems that when someone sets the fuses, they need to do it all at once, including blowing the master fuse. Then, things are set for that chip.
Does flash preclude other process features that you are using?
You'd need a second poly layer with some thin oxide on one side, so that you could tunnel electrons into it. EEPROM/FLASH processes have that structure possibility. Bulk CMOS logic processes don't. We're using a more-or-less standard 180nm logic process.
This may sound like a stupid question, but when you talk about "blowing" fuses, I envision a conductor being vaporized. If that's what happens -- and it seems like an extreme event on a micro-scale -- how do you prevent collateral damage to nearby structures?
-Phil
Same idea as blowing up buildings and leaving the street standing. Use "just enough" dynamite!
Also, I just found this: Breaking copy protection in microcontrollers. It seems to mostly cover things that have already been said, but it's a reasonably comprehensive source in one place.
-Phil
It IS like you imagine. I calculated the power density this morning, but it seemed surreal: a fuse of .18um x 1.8um is 324 square femtometers. It has an initial resistance of 80 ohms, since the sheet resistance of silicided P+ poly is 8 ohms per square and the aspect ratio is 10x1. So, the the power density (Watts/area) is (E^2)/R / area, or (3.3^2)/80 / 324fm2, which comes to 0.136W / 342fm2, or 398GW/m2, or 39MW/cm2!
Here is a paper on the matter: http://www.maths-in-industry.org/miis/201/1/analog-1.pdf
Some people at Tanner, who make our IC tools, had sent me some pdf's on the subject and we followed the aggregate guidelines. Now, we just hope they work.
Well, those processes are more specialized, have less frequent shuttle runs, and cost more.
That's the idea!
As most electron microscopes require the layer of interest to be exposed and metalized, it doesn't matter if an electron microscope can see the damage as the attacker can already physically probe the fuses. (well, except for extremely high energy transmission microscopes that can just blast electrons through the whole mess. I.e. >$$$$$$$$) Phill's question vs X-rays is far more relevant, as X-rays readily penetrate objects. (though getting a <100um resolution could get expensive? at least $$$$$$ I hope?) Medical X-ray machines are unlikely to have the resolution to look at the fuses, but I'm less sure about industrial X-ray machines used for inspection of BGA solder joints, and other small items.
Lawson
The Prop2 has 126K of RAM because 2K of RAM is turned into ROM. This is the same amount of space required for the bootloader and signature. The first 2K of the EEPROM is bootloader and signature, the remaining 126K is the memory image. You only need a 128K EEPROM for the whole shebang.
The customer determines the key, they may want to produce a "lite" and "premium" version of a product and distinguish that with the fuse bits.
No die change, fuse bits.
Only the customer knows the bits, and since all devices in a family have the same key, the situation is the same for an attacker. The attacker has no way of knowing there are reserved bits.
Whether it's "kosher" for the 128 bit key to be used for signing and encryption, intuitively I would think yes, however this is crossing the line of practical and theoretical, I would ask that question to Bruce Schneier.
160 bits is pretty cool, since that's 128 bit key, family codes, serials, etc.
-Phil
If you use a 128 bit key for encryption and only 32 bits for signing, then the encryption key is only as secure as the 32 bit signing key.
http://en.wikipedia.org/wiki/Brute-force_attack
-Phil
That's an interesting notion, certainly a question to ask a crypto expert.
You still would only have 160 bits of total encryption no matter how you sliced it... the overlap just adds a 32 bit layer on top of the 128 bit encryption method used.
-Phil
Hehe, yes, I can see those sort of numbers, and 'fuse' do go together !!