Isn't Marketing wonderful... Here we are discussing which physical implementation is more secure, and dear Dave tells us that Altera was indeed smart enough to implement the algorithm correctly. I would never have stooped so low to doubt that. Yes, Altera can do logic design. Bravo! Advance to second grade!
The questi> 1. Stratix II FPGAs have been validated as conforming to FIPS-197
Hi Peter,
Isn't FUD wonderful...
At least they are not claiming anything which they haven't really accomplished unlike the statements here:
"If I can get the IP that is a secret for less than $5,000, then I can clone the devices without paying anything at all."
"*Disclaimer: non-volatile poly-efuse EM technology can be read out by a microscope using polarized light for a total investment of less than $5,000 "
and then changing the numbers when confronted if actually done:
"No, I have not cracked the Altera chip."
"My quote of $5,000 is what we pay to have a device ground down on the backside such that we can do analysis on a device.
For another $5,000, one can get up to three or four FIB cuts, and a couple of jumper wires. "
Now we are up to $10K. Then claiming: "The question is not one of can I crack it (I believe I can), but one of a ASSP vendor deciding to place their IP in a component that is not in compliance with FIPS 140-2. Very, very simple."
I think it's put up or shut-up time, don't you think ? If you guys are so sure, why don't you crack it / get it cracked and tell us how much it costs instead of spreading FUD ?
Let's not quibble over the price tag, and whether $10,000 is a meaningful hurdle.
The debate was about key security, and the consensus in the crypto community is that things like efuses can be read out with moderate effort, while battery-backed up SRAM data is either much more secure or even perfectly secure, i.e. has never been cracked.
Some people think batteries are a pain, others think they are just fine and last >15 years.
It's security vs convenience. Xilinx picked security, Altera picked convenience. The choice is yours. Peter Alfke, Xilinx Applications
Any security system must be convenient, or it won't be used. A hefty proportion of windows users have firewall software that came with their machines, but it's turned off - simply because it is too inconvenient. When it's enabled, the firewall keeps asking these daft questions about whether your programs are allowed to do this or that - it's far easier just to turn the stupid thing off. An advanced application level software firewall may theoretically be more secure than a simple "incoming bad, outgoing good" firewall, but it's no help if people don't use it.
The same thing probably applies here. I've no experience with either Altera's or Xilinx's solutions, but I can understand the principle that it's possible to read out efuses but not sram bits. If Altera's solution is more convenient, then perhaps it is more secure in that developers are more likely to use it? After all, all they need to do is choose some options in the software - there is no need to add batteries to the card, and to handle the support costs of dealing with lost keys (users are so imaginative - "I took out the battery to make sure the card got a proper reset").
As to how secure Altera's solution is - the Altera guys are not idiots, and it is unbecoming of you to them as such. Sure, it's possible to read out the efuses in theory, but my guess is you're going to have to do a lot more than just a couple of $5000 rounds. I'm sure there are theoretical methods of breaking Xilinx's security too, such as probing the bit stream out of the decoder. Since you have to get access to the device while power is on, it's going to be difficult - but I'm sure it can be done given enough time and money (and boards to practise on). To be secure, all a method has to do is raise the stakes high enough that alternative methods are cheaper - once it is easer and cheaper to bribe the original engineers for a copy of the code, the device is secure enough.
David, you should be ashamed of yourself for that dumb statement. I did the opposite, I confirmed earlier that they desigend their logic and algorithm correctly, and explained then that they chose a different optimization, convenience over security.
To tell me what is "unbecoming" is a baseless insult. Peter Alfke
David,
Would you email me directly?
I'd like to send you the photomicrograph of a fuse that is a 1, and a 0.
Austin
David Brown wrote:
David,
As to convenience, place a lithium coin cell on the pcb per the app note. Ask the software to generate a random key for you (or pick one yourself), send the key to the JTAG port. Verify the key can be written and read, then write it in secure mode (so it can not be read out again without it being erased immediately). Program eeprom or other memory with encrypted bitstream.
Done.
Not sure about Altera, as they have now told us they keep secrets from even their customers, and you have to sign an NDA. But, in theory, you get a key (does their software generate random 128 bit keys? Let us suppose it does), program the part (How? It is a secret! But let us imagine it is as simple as JTAG), an then place encrypted design in the memory.
Done.
So, we have one more step: make sure their is a lithium coin cell on the pcb connected to the Vbatt pin.
That is the total level of inconvenience we offer.
The benefit is that we offer all four levels of security in FIPS 140-2 compliance, and Altera offers no level of compliance at all with FIPS 140-2.
What is so important about FIPS 140-2? It is the required security standard for the US Federal government, as well as for banks, networks, and others who are serious about security.
Don't need FIPS 140-2? Then go ahead and use efuse keys. But also be aware of the risks.
As for reverse engineering, I can send you presentations of how efuse technology smart cards are reverse engineered (hacked). It is a junior level EE project at most universities now.
Austin
David Brown wrote:
I apologise for being insulting - that was not my intention. I felt your earlier reply to Dave Greenfield, including "Yes, Altera can do logic design. Bravo! Advance to second grade!", was intentionally patronising, and lowering the tone of the thread (which is interesting). Unfortunately, the context of that post was dropped from the thread (by you), so my comment appeared out of the blue - I should have made it in an appropriate branch. And yes, I did read your other comments on the two security solutions - it was the contrast between your normal technical, informative and (reasonably) objective comments and that sarcastic dig at Dave Greenfield and Altera that annoyed me.
Peter Alfke referred to Altera's solution as being more biased towards convenience, while Xilinx's was more biased towards security. Since Peter knows a great deal more than me about both security systems, I assume that the difference in convenience is relevant (unless, of course, he was referring to convenience for Altera rather than for the customer).
At the moment, and for the foreseeable future, I am not using either Altera or Xilinx's bigger devices, and I am not overly concerned about security. And I'm sure that if I did need such a design, then the inconvenience of having a battery would not stop me using Xilinx - other factors are more important.
The risks must be balanced, and it's important to know them (I don't, obviously, but I've never needed to know). What's important is to protect the IP, which means increasing the costs until it is impractical for someone to steal it. You don't need a zero risk solution, you need something with a risk that is known to be low enough. I presume that Altera will give customers more detailed information when necessary - although I think the Xilinx-style openness is better.
I'm following this thread out of interest, and not from a need of detailed knowledge. If you have public links of interest to others here, post them here - others have questioned the accuracy of your numbers and might like to see examples. It would of course be interesting to hear Altera's viewpoint as well.
As for sending anything directly to me - I appreciate the offer, but there is no need, and it would be a waste of your time. Newsgroup posts benefit more people.
mvh.,
David
David,
Fair enough. A good treatise of the subject:
And today's FPGA Journal:
And,
The slides that I would like to send to you do not exist on a public website (that I can find). The photo micro graphs that I have may have been ones that we got. They are in our V4 security presentation that our FAEs pitch.
So, for anyone who really would like to see what an efuse looks like under a microscope, before and after programming, they will still have to email me and request I send it.
Again, I love efuses. They are great. Hope to see them in a device. But, how they are used, and more importantly how they are represented has to be fair and honest.
Aust> Aust>> David,
What fascinating links! I always wondered how lock-picking was done... It was also interesting to see how smart cards are cracked, which is more relevant to real life than FPGA security (for most people, anyway). I'd assume that FPGAs are harder to crack - if nothing else, the size of the devices is on a different scale.
The FPGA article suggests that both Altera's and Xilinx's methods are very secure, without being too specific.
mvh.,
David
David,
All I can say is that FIPS 140-2 requires the key memory can be erased.
Since the NIST requires it, it must be because they feel that a key that can be erased is more secure than one that can not be erased.
I happen to agree with them. Even if I do not know how to read the non-volatile key today, I might figure it out tomorrow. After all, it just sits there, awaiting discovery.
How long the security must work is also a factor. If I am a government, I might require that the security is secure for 20 years or more. If I park my bicycle on the street, I only need security for a short while (until I get back).
If I am a bank, and transacting business and transferring funds, I might need to be secure for a lifetime, maybe more.
Aust> Aust>> David,
[snip] Regrettably, that puts Xilinx out of our new product development project (vehicle engine management). The safety people will not tolerate a battery in the unit: when the power is off, there must be *no* secondary energy source present.
David,
OK. Then you are also unable to comply with FIPS-140-2.
If you need not comply with that standard, then we are right back in with V5.
There are many tricks up our sleeves...remember my ONLY complaint is that an efuse solution is not compliant with NIST standards on secure SYSTEMS.
If you do not need to meet that standard, then, we have ways....
Austin
PS: engine controls? What engine needs the power of a FPGA???
David R Brooks wrote:
[snip] FIPS140 is not an issue for us: we are trying to stop people reverse engineering our design. A well-resourced adversary can hack EPROM bits, but it's felt to be a low enough risk to be tolerable (these aren't my decisions.) >
More ways to skin the cat... Options considered included a relatively simple CPU, with a small FPGA alongside, generating the waveforms; or a larger CPU doing it all. We finally settled for the large CPU route.
The FLASH CPLD/FPGAs from Altera/Lattice/Actel could assist here.
Of course, the 'larger CPU' guys are not standing still either:
I see TI's recent announcement of TMS320F28015 : $3.25/10K, gets you
32 bit DSP, 32KF, 12KR, PWM steps well under 1ns, and 12 bit ADCs well over 1MSPS. - Just the ADC alone is worth $3.25, and the high end PWM is similar, means the FLASH + 32 bit CPU is almost 'for free' :)-jg
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.