Would flash/antifuse-based vendors be more likely to disclose bitstream formats?

Of course this is purely hypothetical since -- right now -- none of
them do.

But it occurred to me that vendors like Actel could disclose their
bitstream format without scaring their customers and admitting that
the emperor has no clothes when it comes to bitstream
security-as-obscurity.

Getting the bitstream out of a flash/antifuse device that isn't
designed to emit it is probably harder than reverse engineering
Xilinx/Altera's bitstream formats.  And if you already know how to
disassemble chips and get a mask image out of them, well, the
so-called bitstream "encryption-but-you're-shipping-the-decryption-key
to-all-your-customers-in-this-little-black-package" is worthless
anyways.

Supposing somebody was able to present one of these vendors with a
tangible justification (ie way they would make more money) for
publicizing their bitstream format, does anybody think they would
publish it?

  - a

In article <x1wtyxmyde.fsf@nowhere.com>, Adam Megacz  <adam@megacz.com> wrote:
>
>Of course this is purely hypothetical since -- right now -- none of
>them do.
>
>But it occurred to me that vendors like Actel could disclose their
>bitstream format without scaring their customers and admitting that
>the emperor has no clothes when it comes to bitstream
>security-as-obscurity.

Thus you have the encrypted bitfile loading on the Virtex lines.
Personally, I think the V4 version is easily good enough for
protecting a $10,000 secret, and I could probably be OK comfort wise
protecting a $100,000 secret.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Hey Nick, 441 Soda Hall just isn't the same without you.... =(

> Thus you have the encrypted bitfile loading on the Virtex lines.

Well, IMHO it doesn't qualify as encryption when the chip itself --
which you're giving to your customers -- contains the decryption key.

> Personally, I think the V4 version is easily good enough for
> protecting a $10,000 secret, and I could probably be OK comfort wise
> protecting a $100,000 secret.

$10k (loaded cost) will buy you about half a month of a mediocre
hardware engineer's time.  I doubt many of Xilinx's customers' designs
are that simple.  Even <$100k designs probably constitutes an
unimportant fraction of their market.

But I agree with your estimate.  I could envision the task of
extracting the decryption key from a Xilinx part as being a feasible
project with around $300k of funding and the right team to pull it
off.

So, basically, I wouldn't trust the security of any serious commercial
design to Xilinx's obfuscation.  Now lawyers, on the other hand... =)

  - a

>But I agree with your estimate.  I could envision the task of
>extracting the decryption key from a Xilinx part as being a feasible
>project with around $300k of funding and the right team to pull it
>off.

How many boards would you need?

For a non high volume board, would that be enough so the vendor
would notice?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Adam,

And how do you propose to read out the bits from the key memory?

Austin

Adam Megacz wrote:

> Hey Nick, 441 Soda Hall just isn't the same without you.... =(
> 
> 
>>Thus you have the encrypted bitfile loading on the Virtex lines.
> 
> 
> Well, IMHO it doesn't qualify as encryption when the chip itself --
> which you're giving to your customers -- contains the decryption key.
> 
> 
>>Personally, I think the V4 version is easily good enough for
>>protecting a $10,000 secret, and I could probably be OK comfort wise
>>protecting a $100,000 secret.
> 
> 
> $10k (loaded cost) will buy you about half a month of a mediocre
> hardware engineer's time.  I doubt many of Xilinx's customers' designs
> are that simple.  Even <$100k designs probably constitutes an
> unimportant fraction of their market.
> 
> But I agree with your estimate.  I could envision the task of
> extracting the decryption key from a Xilinx part as being a feasible
> project with around $300k of funding and the right team to pull it
> off.
> 
> So, basically, I wouldn't trust the security of any serious commercial
> design to Xilinx's obfuscation.  Now lawyers, on the other hand... =)
> 
>   - a

Physical means.  There are quite a few companies in Taiwan that
specialize in this.  There might also be noninvasive imaging
techniques similar to those used for MRI or perhaps even Van Eck
phenomena.  Dallas Semiconductor is pretty familiar with these attacks
since they specialize in designing NVRAM devices that clear themselves
in such scenarios.

Actually, I would sincerely hope that the key isn't held in any sort
of "memory"; even ROM.  If I were designing such a system I would make
sure that the "key" was an emergent property of some structure with
lower spatial complexity than the key itself (for example, a
sequential circuit computing the collatz sequence).

I suppose an even better protection technique would be to base the key
on some analog, physical property of the chip itself combined with a
per-chip "offset" value.  For example, a function of the ratio of
oscillation frequencies of two pairs of inverters, plus some offset
value "X" which is computed during the testing process and then
flashed onto the chip (ie each chip has a different oscillatior value
due to process variations as well as a different X -- but they all sum
up to the same universal decryption key).

I hadn't thought of this before; this would actually be pretty hard to
extract.  But at the same time I doubt that Xilinx is hiding any NVRAM
in their chips; if their process allowed for that they would probably
offer some of it to their customers -- even a few bytes would still be
handy.

I suppose that this is my core point: as long as every Xilinx chip of
a given type is exactly the same with respect to the part of it that
performs decryption, I'm highly suspicious of any design security
claims.  

And if you're going to go so far as adding nonvolatile storage to a
chip, well, you might as well go the Actel route and save your
customers the hassle of putting an extra chip on board just to serve
up the configuration data.  This also means that a breach of one
particular device's security doesn't compromise the IP of every single
customer at the same time because of a shared secret: Xilinx is
putting all of their customers in the same high-profile basket.

  - a



Austin Lesea <austin@xilinx.com> writes:
> Adam,
>
> And how do you propose to read out the bits from the key memory?
>
> Austin
>
> Adam Megacz wrote:
>
>> Hey Nick, 441 Soda Hall just isn't the same without you.... =(
>>
>>>Thus you have the encrypted bitfile loading on the Virtex lines.
>> Well, IMHO it doesn't qualify as encryption when the chip itself --
>> which you're giving to your customers -- contains the decryption key.
>>
>>>Personally, I think the V4 version is easily good enough for
>>>protecting a $10,000 secret, and I could probably be OK comfort wise
>>>protecting a $100,000 secret.
>> $10k (loaded cost) will buy you about half a month of a mediocre
>> hardware engineer's time.  I doubt many of Xilinx's customers' designs
>> are that simple.  Even <$100k designs probably constitutes an
>> unimportant fraction of their market.
>> But I agree with your estimate.  I could envision the task of
>> extracting the decryption key from a Xilinx part as being a feasible
>> project with around $300k of funding and the right team to pull it
>> off.
>> So, basically, I wouldn't trust the security of any serious
>> commercial
>> design to Xilinx's obfuscation.  Now lawyers, on the other hand... =)
>>   - a

-- 

Adam,

See my other posting today.

And, you are correct, we have no NVRAM in our FPGA devices right now. 
If we did, we would first use it for more useful things (like serial 
numbers, lot code, etc).

NVRAM as I described is not secure, so using it for security means the 
secret you wish to keep is not worth very much.  But, hey, there are 
lots of folks that have inexpensive secrets.  I just do not know any 
that are seriously considering basing their entire product line's 
secrets on NVRAM solutions.....

And, we have "been there, done that" on having some kind of structure 
that is inherent in the device, but which provides a unique ID or key. 
Never succeeded in making any of the methods work.  We make just too 
many chips.  And will it change over time?  Well, Vts, Idsats, and just 
about everything else now changes over time (the transistors themselves 
change as they age in these ultra-deep sub-microm technologies).

Austin

Adam Megacz wrote:

> Physical means.  There are quite a few companies in Taiwan that
> specialize in this.  There might also be noninvasive imaging
> techniques similar to those used for MRI or perhaps even Van Eck
> phenomena.  Dallas Semiconductor is pretty familiar with these attacks
> since they specialize in designing NVRAM devices that clear themselves
> in such scenarios.
> 
> Actually, I would sincerely hope that the key isn't held in any sort
> of "memory"; even ROM.  If I were designing such a system I would make
> sure that the "key" was an emergent property of some structure with
> lower spatial complexity than the key itself (for example, a
> sequential circuit computing the collatz sequence).
> 
> I suppose an even better protection technique would be to base the key
> on some analog, physical property of the chip itself combined with a
> per-chip "offset" value.  For example, a function of the ratio of
> oscillation frequencies of two pairs of inverters, plus some offset
> value "X" which is computed during the testing process and then
> flashed onto the chip (ie each chip has a different oscillatior value
> due to process variations as well as a different X -- but they all sum
> up to the same universal decryption key).
> 
> I hadn't thought of this before; this would actually be pretty hard to
> extract.  But at the same time I doubt that Xilinx is hiding any NVRAM
> in their chips; if their process allowed for that they would probably
> offer some of it to their customers -- even a few bytes would still be
> handy.
> 
> I suppose that this is my core point: as long as every Xilinx chip of
> a given type is exactly the same with respect to the part of it that
> performs decryption, I'm highly suspicious of any design security
> claims.  
> 
> And if you're going to go so far as adding nonvolatile storage to a
> chip, well, you might as well go the Actel route and save your
> customers the hassle of putting an extra chip on board just to serve
> up the configuration data.  This also means that a breach of one
> particular device's security doesn't compromise the IP of every single
> customer at the same time because of a shared secret: Xilinx is
> putting all of their customers in the same high-profile basket.
> 
>   - a
> 
> 
> 
> Austin Lesea <austin@xilinx.com> writes:
> 
>>Adam,
>>
>>And how do you propose to read out the bits from the key memory?
>>
>>Austin
>>
>>Adam Megacz wrote:
>>
>>
>>>Hey Nick, 441 Soda Hall just isn't the same without you.... =(
>>>
>>>
>>>>Thus you have the encrypted bitfile loading on the Virtex lines.
>>>
>>>Well, IMHO it doesn't qualify as encryption when the chip itself --
>>>which you're giving to your customers -- contains the decryption key.
>>>
>>>
>>>>Personally, I think the V4 version is easily good enough for
>>>>protecting a $10,000 secret, and I could probably be OK comfort wise
>>>>protecting a $100,000 secret.
>>>
>>>$10k (loaded cost) will buy you about half a month of a mediocre
>>>hardware engineer's time.  I doubt many of Xilinx's customers' designs
>>>are that simple.  Even <$100k designs probably constitutes an
>>>unimportant fraction of their market.
>>>But I agree with your estimate.  I could envision the task of
>>>extracting the decryption key from a Xilinx part as being a feasible
>>>project with around $300k of funding and the right team to pull it
>>>off.
>>>So, basically, I wouldn't trust the security of any serious
>>>commercial
>>>design to Xilinx's obfuscation.  Now lawyers, on the other hand... =)
>>>  - a
> 
> 

Austin Lesea <austin@xilinx.com> writes:
> See my other posting today.

Okay, so, it appears that my argument became invalid about a week ago
when the Virtex4 shipped.  My apologies for this.

But at the same time, so did the argument "we can't document the
bitstream because it will compromise customer design security".... So,
what is the current reason for not publishing the bitstream format?

> And, you are correct, we have no NVRAM in our FPGA devices right

I was probably a bit too specific there; I meant any sort of
customer-writable memory that doesn't get cleared when you take away
the main power supply to the device.  The battery-backed memory for
storing a customer-specific decryption key is close enough -- in fact,
this is what Dallas Semico uses (rather than flash or some other
zero-current storage).

I'm quite happy to see this; unlike previous schemes, this is
something I would actually trust.  A customer-specific (or
design-specific) key is definately the only way to go for any sort of
real security.

  - a

I admit I'm puzzled.  Within a given 'package' form-factor,
the Virtex-4 and Virtex2P parts are going to have
nearly identical circuitry (since they come off the same
lithographic manufacturing process.)

If you developed a field-process to extract the config-bitstream
of 1 loaded/configured FPGA, presumably you could do it to any
other FPGA based on the same die.

So does it really matter whether the 'secret key' was unique to each
customer's bitstream?

Adam Megacz wrote:
> Austin Lesea <austin@xilinx.com> writes:
> 
>>See my other posting today.
> 
> 
> Okay, so, it appears that my argument became invalid about a week ago
> when the Virtex4 shipped.  My apologies for this.
> 
> But at the same time, so did the argument "we can't document the
> bitstream because it will compromise customer design security".... So,
> what is the current reason for not publishing the bitstream format?
> 
> 
>>And, you are correct, we have no NVRAM in our FPGA devices right
> 
> 
> I was probably a bit too specific there; I meant any sort of
> customer-writable memory that doesn't get cleared when you take away
> the main power supply to the device.  The battery-backed memory for
> storing a customer-specific decryption key is close enough -- in fact,
> this is what Dallas Semico uses (rather than flash or some other
> zero-current storage).
> 
> I'm quite happy to see this; unlike previous schemes, this is
> something I would actually trust.  A customer-specific (or
> design-specific) key is definately the only way to go for any sort of
> real security.
> 
>   - a

actela,

???

V4 is 90nm and V2P is 130 nm.
V4 is columnar architecture, V2P is tradional center and perimeter IO.
V4 has 1 more metal layer than V2P.

'nearly identical'?  not even close

???

Austin

actela wrote:
> I admit I'm puzzled.  Within a given 'package' form-factor,
> the Virtex-4 and Virtex2P parts are going to have
> nearly identical circuitry (since they come off the same
> lithographic manufacturing process.)
> 
> If you developed a field-process to extract the config-bitstream
> of 1 loaded/configured FPGA, presumably you could do it to any
> other FPGA based on the same die.
> 
> So does it really matter whether the 'secret key' was unique to each
> customer's bitstream?
> 
> Adam Megacz wrote:
> 
>> Austin Lesea <austin@xilinx.com> writes:
>>
>>> See my other posting today.
>>
>>
>>
>> Okay, so, it appears that my argument became invalid about a week ago
>> when the Virtex4 shipped.  My apologies for this.
>>
>> But at the same time, so did the argument "we can't document the
>> bitstream because it will compromise customer design security".... So,
>> what is the current reason for not publishing the bitstream format?
>>
>>
>>> And, you are correct, we have no NVRAM in our FPGA devices right
>>
>>
>>
>> I was probably a bit too specific there; I meant any sort of
>> customer-writable memory that doesn't get cleared when you take away
>> the main power supply to the device.  The battery-backed memory for
>> storing a customer-specific decryption key is close enough -- in fact,
>> this is what Dallas Semico uses (rather than flash or some other
>> zero-current storage).
>>
>> I'm quite happy to see this; unlike previous schemes, this is
>> something I would actually trust.  A customer-specific (or
>> design-specific) key is definately the only way to go for any sort of
>> real security.
>>
>>   - a
> 
>