07-11-2011 04:29 AM - edited 07-11-2011 04:31 AM
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 ?!
07-12-2011 07:26 AM
07-11-2011 08:46 AM
What is it you are trying to do?
What attack you trying to prevent?
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.
07-11-2011 11:18 AM - edited 07-11-2011 11:20 AM
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 )
07-11-2011 01:30 PM
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.
07-11-2011 09:05 PM
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.
07-12-2011 07:26 AM
07-12-2011 07:49 AM
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.
11-13-2011 12:41 PM
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.
11-14-2011 07:21 AM
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).
11-14-2011 08:00 AM
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.
11-14-2011 08:32 AM