FPGA Central

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:
> Peter Alfke wrote:
>> 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,

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:
> Peter Alfke wrote:
>> 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.

Peter Alfke wrote:
> David Brown wrote:
>> As to how secure Altera's solution is - the Altera guys are not idiots,
>> and it is unbecoming of you to them as such.
>
> 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
>

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.

Austin Lesea 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.
>

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 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.
>

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.

> 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.
>

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


> Austin
>
>
> David Brown wrote:
>> Peter Alfke wrote:
>>> 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,

Fair enough.
A good treatise of the subject:
http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf

And today's FPGA Journal:
http://www.fpgajournal.com/articles_..._security2.htm

And,
http://md.hudora.de/presentations/su...areAttacks.pdf

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.

Austin

David Brown wrote:
> Austin Lesea 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.
>>
>
> 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 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.
>>
>
> 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.
>
>> 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.
>>
>
> 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
>
>
>> Austin
>>
>>
>> David Brown wrote:
>>> Peter Alfke wrote:
>>>> 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.

Austin Lesea wrote:
> David,
>
> Fair enough.

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


> A good treatise of the subject:
> http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf
>
> And today's FPGA Journal:
> http://www.fpgajournal.com/articles_..._security2.htm
>
> And,
> http://md.hudora.de/presentations/su...areAttacks.pdf
>
> 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.
>
> Austin
>
> David Brown wrote:
>> Austin Lesea 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.
>>>
>> 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 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.
>>>
>> 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.
>>
>>> 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.
>>>
>> 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
>>
>>
>>> Austin
>>>
>>>
>>> David Brown wrote:
>>>> Peter Alfke wrote:
>>>>> 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,

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.

Austin

David Brown wrote:
> Austin Lesea wrote:
>> David,
>>
>> Fair enough.
>
> 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
>
>
>> A good treatise of the subject:
>> http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf
>>
>> And today's FPGA Journal:
>> http://www.fpgajournal.com/articles_..._security2.htm
>>
>> And,
>> http://md.hudora.de/presentations/su...areAttacks.pdf
>>
>>
>> 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.
>>
>> Austin
>>
>> David Brown wrote:
>>> Austin Lesea 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.
>>>>
>>> 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 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.
>>>>
>>> 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.
>>>
>>>> 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.
>>>>
>>> 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
>>>
>>>
>>>> Austin
>>>>
>>>>
>>>> David Brown wrote:
>>>>> Peter Alfke wrote:
>>>>>> 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.

Austin Lesea 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.
>
[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:

> Austin Lesea 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.
>>
> [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.

Austin Lesea wrote:
> 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
>
[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.)
>
> PS: engine controls? What engine needs the power of a FPGA???
>
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.

David R Brooks wrote:

> Austin Lesea wrote:
>
>> 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
>>
> [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.)
> >
> > PS: engine controls? What engine needs the power of a FPGA???
> >
> 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