keys to the Kingdom

Annoyed Crypto Folks,

The latest announcement of "security" is just more than a little annoying:

http://biz.yahoo.com/prnews/060619/sfm036.html?.v=56

In the FIPS 140-2 Standard:

"4.7.6 Key Zeroization

A cryptographic module shall provide methods to zeroize all plaintext
secret and private cryptographic keys and CSPs within the module.
Zeroization of encrypted cryptographic keys and CSPs or keys otherwise
physically or logically protected within an additional embedded
validated module (meeting the requirements of this standard) is not
required.

Documentation shall specify the key zeroization methods employed by a
cryptographic module."

Efuse keys can be read easily by inspection:

http://ieeexplore.ieee.org/iel5/9994/32106/01493126.pdf?tp=&arnumber=1493126&isnumber=32106
(IEEE library user name and password required)

Not that there is anything wrong with a low cost, simple, and useful
security method (look at how many cheap locks get sold that are easily
picked by the average pre-teen).  But to imply that this is somehow NIST
approved is a complete joke!

In fact, use of poly efuses are great (now that the foundries have them
as a standard feature).

Just don't go advertising them to be more than they really are:  a
convenient way to make it cost at least $5,000 to find the key.

Austin

Hi Austin,
besides everything concerning the security gain of an encrypted 
bitstream I have a different question.

Xilinx offers a similar feature too in its Virtex4 (and 5?) FPGAs.
Now, that some silicon already is used up by the AES algorithm, wouldn't 
it be nice to make it accessible to the custumer? Just the Keyscheduler 
and the round function, not the key memory.

Would be a nice feature for some custumers, but (nearly) no drawback for 
all others.

Best regards
   Eilert

backhus,

That is something that we thought about.  But, really what we talking
about is providing access to the crypto-engine through the general
interconnect, and control of that engine.

It was considered that anything we do in this regard would have to be
completely and thoroughly tested so as not to be a back door, and
compromise security.

It wasn't worth the work to have to prove we did not break something.

Even the JTAG is considered a real threat to security, so we have a
method of disabling it once you have been configured with your encrypted
bitstream (in V4 and V5).

Kevin of FPGA Journal is looking for student interns for some security
fun (in FPGAs).  If anyone is interested, email me directly.

We submitted our V2 Pro to 9 schools and universities (and some
non-existent agencies) three years ago, and no one has broken the
security, or even compromised it.  That is what our security is about:
we gave the students the complete schematics of the PCB, provided series
access for PDA attacks, etc.  All we asked was:  tell us the key, or
make the TRNG deliver non-random numbers (affect operation).  We wqnt to
know every weakness so we can fix it in the next version (and hopefully
not break anything).

Austin

backhus wrote:
> Hi Austin,
> besides everything concerning the security gain of an encrypted
> bitstream I have a different question.
> 
> Xilinx offers a similar feature too in its Virtex4 (and 5?) FPGAs.
> Now, that some silicon already is used up by the AES algorithm, wouldn't
> it be nice to make it accessible to the custumer? Just the Keyscheduler
> and the round function, not the key memory.
> 
> Would be a nice feature for some custumers, but (nearly) no drawback for
> all others.
> 
> Best regards
>   Eilert

Further,

At least no one will tell us they broke into the chip.

It could be that when the students worked at it for awhile, they
realized that since they couldn't break it, there would be no degree, so
they moved on to something easier to break into.  I am sure that certain
non-existent agencies spent more time hacking at it.  But since they
never tell anyone anything, I am just guessing.

Obviously with enough money and enough time ... there is no 'perfect' lock.

But we are in full compliance with FIPS 140-2.  And we also have AES256
which is considered acceptable for the most secure crypto boxes.  AES128
is not considered 'secure' enough.  Don't ask me why, as the details are
secret, and I am not cleared.  I just hear and obey.

I am sure that if AES128 had battery backed key storage, it would be
perfectly good for any commercial crypto application.  After all, today
we use 3DES which is only 2E112 hard, and that is now considered within
the reach of a mid-level attack.  2E128 provides only (only?) a 16 fold
improvement over 2E112....

Austin

Austin Lesea wrote:
> backhus,
> 
> That is something that we thought about.  But, really what we talking
> about is providing access to the crypto-engine through the general
> interconnect, and control of that engine.
> 
> It was considered that anything we do in this regard would have to be
> completely and thoroughly tested so as not to be a back door, and
> compromise security.
> 
> It wasn't worth the work to have to prove we did not break something.
> 
> Even the JTAG is considered a real threat to security, so we have a
> method of disabling it once you have been configured with your encrypted
> bitstream (in V4 and V5).
> 
> Kevin of FPGA Journal is looking for student interns for some security
> fun (in FPGAs).  If anyone is interested, email me directly.
> 
> We submitted our V2 Pro to 9 schools and universities (and some
> non-existent agencies) three years ago, and no one has broken the
> security, or even compromised it.  That is what our security is about:
> we gave the students the complete schematics of the PCB, provided series
> access for PDA attacks, etc.  All we asked was:  tell us the key, or
> make the TRNG deliver non-random numbers (affect operation).  We wqnt to
> know every weakness so we can fix it in the next version (and hopefully
> not break anything).
> 
> Austin
> 
> backhus wrote:
>> Hi Austin,
>> besides everything concerning the security gain of an encrypted
>> bitstream I have a different question.
>>
>> Xilinx offers a similar feature too in its Virtex4 (and 5?) FPGAs.
>> Now, that some silicon already is used up by the AES algorithm, wouldn't
>> it be nice to make it accessible to the custumer? Just the Keyscheduler
>> and the round function, not the key memory.
>>
>> Would be a nice feature for some custumers, but (nearly) no drawback for
>> all others.
>>
>> Best regards
>>   Eilert

One more thing...

The 'solution' for Startix II requires an NDA for how to program the keys.

Now, since there is 'no security through obscurity', this means that
there is something they wish to hide.

A back door?  A flaw?  Whatever it is, it must be a goodie...

Full disclosure, and an open invitation to help us improve our solution.
 That is what Xilinx offers.

Austin

Austin Lesea wrote:
> backhus,
> 
> That is something that we thought about.  But, really what we talking
> about is providing access to the crypto-engine through the general
> interconnect, and control of that engine.
> 
> It was considered that anything we do in this regard would have to be
> completely and thoroughly tested so as not to be a back door, and
> compromise security.
> 
> It wasn't worth the work to have to prove we did not break something.
> 
> Even the JTAG is considered a real threat to security, so we have a
> method of disabling it once you have been configured with your encrypted
> bitstream (in V4 and V5).
> 
> Kevin of FPGA Journal is looking for student interns for some security
> fun (in FPGAs).  If anyone is interested, email me directly.
> 
> We submitted our V2 Pro to 9 schools and universities (and some
> non-existent agencies) three years ago, and no one has broken the
> security, or even compromised it.  That is what our security is about:
> we gave the students the complete schematics of the PCB, provided series
> access for PDA attacks, etc.  All we asked was:  tell us the key, or
> make the TRNG deliver non-random numbers (affect operation).  We wqnt to
> know every weakness so we can fix it in the next version (and hopefully
> not break anything).
> 
> Austin
> 
> backhus wrote:
>> Hi Austin,
>> besides everything concerning the security gain of an encrypted
>> bitstream I have a different question.
>>
>> Xilinx offers a similar feature too in its Virtex4 (and 5?) FPGAs.
>> Now, that some silicon already is used up by the AES algorithm, wouldn't
>> it be nice to make it accessible to the custumer? Just the Keyscheduler
>> and the round function, not the key memory.
>>
>> Would be a nice feature for some custumers, but (nearly) no drawback for
>> all others.
>>
>> Best regards
>>   Eilert

Hi Austin,
that sounds reasonable. Security proofs are expensive.

For the V2 boards you gave away ... what reward did you offer in case of 
success? I suspect there are people out there who would pay good for 
that knowledge as long as you don't have it, so why should they tell 
you? ;-)

Best regards
   Eilert

Austin Lesea schrieb:
> backhus,
> 
> That is something that we thought about.  But, really what we talking
> about is providing access to the crypto-engine through the general
> interconnect, and control of that engine.
> 
> It was considered that anything we do in this regard would have to be
> completely and thoroughly tested so as not to be a back door, and
> compromise security.
> 
> It wasn't worth the work to have to prove we did not break something.

Hi,

Austin Lesea schrieb:

> Just don't go advertising them to be more than they really are:  a
> convenient way to make it cost at least $5,000 to find the key.

Is it that cheap today to open the die and observe the fuses?
I have no idea, if (and how) Altera protected the key fuses against
optical inspection of die  cuts. But If your right, it would be very
cheap to reengineer most Asics.

BTW Am I right, that if I use a Xilinx with security inside a
equipment, the chip could be highjacked (Chipmodded) by just removing
the power supply of the keys and applieing a new bitstream?
Which means the bitstream itself may be protected, but not the chip?
Why did nobody combine software and fuse based technologies? It would
be sufficient to have 128 bit (with secure algorithms) in SW and 128 in
fuses. 

bye Thomas

backhus,

No reward but the satisfaction that you were able to outsmart a room
full of very smart people.  Such an accomplishment would definitely
qualify the person for a job offer here at Xilinx.

The part was the 2VP4.

Austin

backhus wrote:
> Hi Austin,
> that sounds reasonable. Security proofs are expensive.
> 
> For the V2 boards you gave away ... what reward did you offer in case of
> success? I suspect there are people out there who would pay good for
> that knowledge as long as you don't have it, so why should they tell
> you? ;-)
> 
> Best regards
>   Eilert
> 
> Austin Lesea schrieb:
>> backhus,
>>
>> That is something that we thought about.  But, really what we talking
>> about is providing access to the crypto-engine through the general
>> interconnect, and control of that engine.
>>
>> It was considered that anything we do in this regard would have to be
>> completely and thoroughly tested so as not to be a back door, and
>> compromise security.
>>
>> It wasn't worth the work to have to prove we did not break something.

Thomas,

Yes, it is that cheap (and easy) to find and read efuses.  If they had
used Actel's via fuse technology, it would be much, much harder, but
still do-able for a small number of vias.  Of course, you would have to
know where to look.  The poly efuse is huge, and is almost big enough to
see with the eye.  An array of 128, or 256 has a big sign on it:  "efuse
array right here!"

If you use the battery backed ram to store the key, the bitstream is
protected, not the device.  Any regular unencrypted bitstream can be
loaded (or else how could you test your boards?).

The use of efuses to make it such that only a particular device is able
to load a particular bitsream is a requirement typical of the gaming
industry (slot machines).  This is a feature that we are looking at
introducing in the future (if it does not compromise the higher level of
security).

As I said, I love efuses.  They can be used for:  serial numbers, lot
and process information, feature selection and control, device
identification, etc.  You can even put a key in it, but make sure that
the key in a non-volatile memory is clearly stated as not being NIST
FIPS 140-2 compliant.  There are customers for whom a low level of
security is just fine.

But for an IP company, placing my IP in such a low security device
invites every crypto student looking for a job, or a degree, to hack it.

Austin


Thomas Stanka wrote:
> Hi,
> 
> Austin Lesea schrieb:
> 
>> Just don't go advertising them to be more than they really are:  a
>> convenient way to make it cost at least $5,000 to find the key.
> 
> Is it that cheap today to open the die and observe the fuses?
> I have no idea, if (and how) Altera protected the key fuses against
> optical inspection of die  cuts. But If your right, it would be very
> cheap to reengineer most Asics.
> 
> BTW Am I right, that if I use a Xilinx with security inside a
> equipment, the chip could be highjacked (Chipmodded) by just removing
> the power supply of the keys and applieing a new bitstream?
> Which means the bitstream itself may be protected, but not the chip?
> Why did nobody combine software and fuse based technologies? It would
> be sufficient to have 128 bit (with secure algorithms) in SW and 128 in
> fuses. 
> 
> bye Thomas
> 

>Yes, it is that cheap (and easy) to find and read efuses.  If they had
>used Actel's via fuse technology, it would be much, much harder, but
>still do-able for a small number of vias.  Of course, you would have to
>know where to look.  The poly efuse is huge, and is almost big enough to
>see with the eye.  An array of 128, or 256 has a big sign on it:  "efuse
>array right here!"

Whenever I get involved with a discussion like this, I point people
at these papers:
  http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf
  http://www.cl.cam.ac.uk/~mgk25/sc99-tamper-slides.pdf

That's from 1999.  Still a great read.

The details have changed, but I doubt if the general idea is out of
date.  People who build chips have to debug them.  They will keep the
technology up to date.

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