UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Adventurer
Adventurer
9,893 Views
Registered: ‎11-09-2010

authentication with DNA

Jump to solution

hi,

I watched some DEMO in xilinx site  about device DNA,I have some question ,

 

1- I should myself provide a encryption algorithm ( like 3DES or... ) hdl file or it is provided by xilinx? I think software emplemention is not safe, because it can be cracked, am I right?

 

2- as I read many times, after DNA passed to algorithm, its result must be compared to a check value, I think that means check value is correct encrypted result of that algorithm , how can I store that check value in FPGA? it is horrible if I must put it in my VHDL file because then I should do a synthesize process for each FPGA ?!

 

thanks

0 Kudos
1 Solution

Accepted Solutions
Scholar austin
Scholar
13,250 Views
Registered: ‎02-27-2008

Re: authentication with DNA

Jump to solution
Think Attack!

OK, so you have the AES efuse key, and every bitstream is the same, and encrypted, with the same key.

To steal it you need the key. Without the key, you can not clone. But, a contract manufacturer may over-build (you trusted them, and they know the key).

Now, imagine someone discovers the key, it doesn't matter how, now the bitstream may be decrypted, and cloning, over-build, etc. is possible.

How does adding DeviceDNA help? It doesn't help the over-build by the contract manufacturer: the problem there is you trsut someone who is untrustworthy. Does DeviceDNA help is someone gets the key? Nope, they can (with a lot of effort) reverse engineer the decrypted bitstream, and discover how the DeviceDNA is used, and rip it out of the design (bypass it).

I can't see any advantage to adding DeviceDNA, orver just using the AES encryption with efuse.

If you need more protection, then you must use the battery backed key RAM instead of efuse.

DeviceDNA is useful when you do not have encryption/decryption, to slow down an attacker, but it fails to a determined attacker.

DeviceDNA is good for keeping track of what you have built, if you maintain a database of values for boards shipped. Over-build and cloning detection becomes easy, as any board without its DNA in the database becomes evidence for the prosecution of a criminal case against the person or persons who have cloned the boards....

There may be a user-writable efuse register in the S6, but that doesn't help, it is just another efuse value (just like the DeviceDNA). Since you won't use battery backed key memory, any register is volatile, and any value written into it is lost when power goes down.

As for ATM's, there is a long history of ATM machines being hacked, and they are not so secure as first appears. I would not use the ATM machine as a good example of security. If anything, they are good examples of anti-tamper technology (steel boxes, alarm systems, etc.).


Obscurity (not knowing) is not security. What is not known (algorithms, code) may become known. It is just work.

Again, what are you afraid of? Sounds like the contract manufacturer running boards at night for his own pocket: as if you do not trust your manufacturer, the problem just got very very very hard to solve.


Austin Lesea
Principal Engineer
Xilinx San Jose

View solution in original post

10 Replies
Scholar austin
Scholar
9,877 Views
Registered: ‎02-27-2008

Re: authentication with DNA

Jump to solution

h,

 

What is it you are trying to do?

 

What attack you trying to prevent?

 

Which device?

 

DeviceDNA provides a unique ID code, a sort of serial number, for each device.  Thus, if it must match something, the bitstream itself must contain the comparison method, and thus, the matching data:  yes, every bitstream is then uniquely matched to a device if this is the model.  Or, there is an external device with the matching data (every bistream is now the same) but the external device must be prgrammed with the match data.  If the external device has the match data, then it can be cloned rather easily, so a hash, or some sort of encryption algorithm may be used to "hide" the match value (the DeviceDNA is passed through a hash, and the matching external token is passed through a hash, and then the two are compared, for example).

 

Encyption is a separate matter, and is distinct (different) from authentication.  Encryption may be used to prevent the hash algorithms from being discovered, or the location of the match data from being discovered, making cloning or over-building more difficult.  Encryption by itself may be used to prevent over-building, as any "new" board requires not only a copy of the bitstream (easy to copy the encrypted bitstream), but also the decryption key (which may be difficult to discover).  Some devices do not have bitstream decryption features, like Spartan 3A, and others, like Spartan 6, do.

 

 

There is more than one use model for the DeviceDNA:  you may use it as shown in the demonstration designs to ensure that only a "right" bitstream can be loaded by a  device, or you may use it as a token to be sent back to a some central point (a website, for example), where the token is compared with valid tokens, and some action is then taken (perhaps a download of a new bitstream with all of the features enabled), and so on.

 

As with any security design, you have to think through what it is you are doing.  What is the attack?  How secure of a system do you require?  It makes no sense to protect a $1000 bicycle with a $10,000 lock, so your solution should be matched to your system.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
Adventurer
Adventurer
9,867 Views
Registered: ‎11-09-2010

Re: authentication with DNA

Jump to solution

Hi, thanks,

I want to make my design secure on Spartan-150 against any possible attack,specially clonning, our product volume is about 100 and they are so expensive.

I want to use both bit-stream AES encryption and DNA. I have no problem with first one.

 

As u told I want to provide match data externally because I want to have a single bit-stream for any device not a bit-steam for each device, because our product volume is not just one or two. But I thought ( maybe I am wrong ) that check-value is not a secret thing, suppose DNA is your encryption algorithm input and check-value is its output, by knowing these two a hacker can not do anything because he does not know algorithm and its key which are buried inside million of bitsteam bits.

Why should check-value be hidden? ( DNA is not hidden obviously )

0 Kudos
Scholar austin
Scholar
9,862 Views
Registered: ‎02-27-2008

Re: authentication with DNA

Jump to solution

h,

 

OK, so I would recommend using the AES encrypted bitstream feature.


You have a choice, to use the AES efuse key, or the battery backed key RAM key.  The AES fuse key is less secure (one can rip a device apart, and with some removal of the layers, get to the efuse bits, and read their state with polarized light -- then you have to guess what bits are what as there are more efuse bits than there are key bits, but a determined attacker could figure it out, after time and money).  The battery backed key is far more secure:  no method of reading these bits is known.

 

Bad news is that you need a lithium coin cell, and if it goes bad, you lose the key.

 

No need for different bitstreams, no need for DeviceDNA:  just use the encrypted bitstream to prevent cloning.  And, each part must get the key programmed into it, either in efuse bits, or in battery backed key RAM bits.

 

The S6 150 supports encrytpion and key storage in efuse, or battery backed key RAM.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
Adventurer
Adventurer
9,857 Views
Registered: ‎11-09-2010

Re: authentication with DNA

Jump to solution

 

Using battery is not possible for me, so I chose eFuse.

But beside using AES bit-stream encryption can I also use DNA? As I understand they are irrelevant to each other.

I have also a 3DES hdl module which I connected it to DNA inside FPGA. but my main problem is how to feed check-value.

 

Because of mass production, I thought something like a user register should be exist in FPGA which can be valued in iMPACT  to feed check-value but it seems not,  you told me it should securely passed externally, I don't understand why check-value is a secret?

 

When I input my PIN in ATM machine, encrypted PIN goes out of ATM pinpad toward ATM computer. By knowing PIN and encrypted PIN ( with sniffing pinpad output ) you can not know the encryption algorithm and its key inside pinpad.

 

thanks,

0 Kudos
Scholar austin
Scholar
13,251 Views
Registered: ‎02-27-2008

Re: authentication with DNA

Jump to solution
Think Attack!

OK, so you have the AES efuse key, and every bitstream is the same, and encrypted, with the same key.

To steal it you need the key. Without the key, you can not clone. But, a contract manufacturer may over-build (you trusted them, and they know the key).

Now, imagine someone discovers the key, it doesn't matter how, now the bitstream may be decrypted, and cloning, over-build, etc. is possible.

How does adding DeviceDNA help? It doesn't help the over-build by the contract manufacturer: the problem there is you trsut someone who is untrustworthy. Does DeviceDNA help is someone gets the key? Nope, they can (with a lot of effort) reverse engineer the decrypted bitstream, and discover how the DeviceDNA is used, and rip it out of the design (bypass it).

I can't see any advantage to adding DeviceDNA, orver just using the AES encryption with efuse.

If you need more protection, then you must use the battery backed key RAM instead of efuse.

DeviceDNA is useful when you do not have encryption/decryption, to slow down an attacker, but it fails to a determined attacker.

DeviceDNA is good for keeping track of what you have built, if you maintain a database of values for boards shipped. Over-build and cloning detection becomes easy, as any board without its DNA in the database becomes evidence for the prosecution of a criminal case against the person or persons who have cloned the boards....

There may be a user-writable efuse register in the S6, but that doesn't help, it is just another efuse value (just like the DeviceDNA). Since you won't use battery backed key memory, any register is volatile, and any value written into it is lost when power goes down.

As for ATM's, there is a long history of ATM machines being hacked, and they are not so secure as first appears. I would not use the ATM machine as a good example of security. If anything, they are good examples of anti-tamper technology (steel boxes, alarm systems, etc.).


Obscurity (not knowing) is not security. What is not known (algorithms, code) may become known. It is just work.

Again, what are you afraid of? Sounds like the contract manufacturer running boards at night for his own pocket: as if you do not trust your manufacturer, the problem just got very very very hard to solve.


Austin Lesea
Principal Engineer
Xilinx San Jose

View solution in original post

Adventurer
Adventurer
9,842 Views
Registered: ‎11-09-2010

Re: authentication with DNA

Jump to solution

Thanks again,

your guidance is so complete,

 

fortunately we ourselves programs the FPGA flash, because our product volume is not high, suppose about 50, so I don't afraid of overbuild. Our product is an expensive product. I just afraid of cloning.

 

As you told, I am using AES encryption, I just thought that using DNA beside AES, as a second security,  is better than not using it.  Any way maybe it bother a determined hacker more!

 

If there is not a very simple way of providing specific check_value of each fpga, I think it is possible to have a data_base of all our products DNA ( volume is not so much big , less than 100) and check them by software or hardware inside design to prevent running on a invalid fpga.

 

 

0 Kudos
Highlighted
Visitor blingerlive
Visitor
9,722 Views
Registered: ‎09-03-2010

Re: authentication with DNA

Jump to solution

I read this thread and found it very informative.  One question, how should we take care of the case where we do not trust our manufacturer?  Can Xilinx pre-deliver key programmed chips to the manufacturer?  We are desigining in North America, but the board is being built overseas.

Tags (1)
0 Kudos
Scholar austin
Scholar
9,708 Views
Registered: ‎02-27-2008

Re: authentication with DNA

Jump to solution

b,

 

Contact you local Xilinx FAE.  We have done this in the past, using a second party, who supplied their IP cores. It is a very difficult problem (as who do you trrust?).

 

The solution requires another security trick:  PUF codes (physically unclonable functions).

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Visitor blingerlive
Visitor
9,705 Views
Registered: ‎09-03-2010

Re: authentication with DNA

Jump to solution

thanks austin. Will do.

 

Just one suggestion as I've developed Security SW in the past; though I have a feeling Xilinx have debated this already. 

 

An asymmetric protocol (public/private key) would solve many of these supply chain/trust issues.  Xilinx could preburn/preprogram a private key into their device during manufacture and stamp it.  Then the public key can be published for each device (kind of like an ID, not that much different from device DNA).   This would solve both cloning/overbuilding and reverse engineering in one shot.  Here, *no one* would know the private key, except Xilinx.

 

I know the US Gov't requires AES symmetric encryption, but for most other commercial clients, I think this would be very helpful, and save Xilinx FAE costs.

 

Maybe the 7-series already takes care of this?  I know they have improved on their security, but I haven't dug into the details since it's not out yet.

 

 

0 Kudos
Scholar austin
Scholar
2,901 Views
Registered: ‎02-27-2008

Re: authentication with DNA

Jump to solution
b,

Doing anything at all to individual devices adds cost and time in the manufacturing process.

Right now, the market for these sorts of requirements is too small to burden everyone with additional costs.
Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos