We have AES 256 bit key in THIS generation! (---twice the key length of our nearest competitor with similar features)
Oh, and to be compliant with the federal standard for encryption, you are not allowed to use non-volatile key storage (must allow 'zeroization'). Non volatile key storage is trivial to reverse engineer. I asked our F/A lab how long it would take to read the value of EM polyfuses (invented by IBM), and they repplied "less than a hour."
Now, if you had poly fuses AND volatile battery backed RAM, that would be the best possible implementation. Those that have secrets worth less than $10,000 would use the poly fuses (how much it costs to decap the device, and read the fuses), and those with secrets worth more than $10,000 would use the $1 lithium coin cell BBRAM solution.
To remember all of the new neat features is tough.
Note that FIPS compliant 'zeroization' requires actively setting all the bits in the key to zero. Turning the power off and hoping that the bits change isn't the same as zeroization.
This implies the following:
Either Xilinx isn't performing zeroization (and I haven't found anything in the data sheet that indicates that they do perform FIPS compliant zeroization). Hmmm.
Or, Xilinx have added a low voltage detector and a have developed a ram with a 'clear' input, or have developed a ram cell that always goes to a known state as the supply drops.
Or, zeroization is possible, but can only happen when the user overwrites the key with zeros, which is only possible when the power is on (and wouldn't be too hard to circumvent in a real product).
Please note: I'm commenting on Austin's use of the (well defined) term 'zeroization'. I don't mean to imply that I think that there is anything wrong with the security of the Xilinx parts.
Well, you don't expect us to tell all of our secrets, do you?
Seriously, there is no security in obscurity (I am quoting someone here, but I do not know who, so I apologize).
I will find out what mechanism we use to clear the bits for you. We do comply with FIPS on zeroisation (at least from my tests in the lab).
One common trick we used ages ago was to make the memory bits highly asymmetric (2K, 3K, 4K series). This way upon power loss, they have no choice but to return to a known state when power is restored. That would make all of those assumptions about freezing cells, and repowering pretty useless (or detecting gate charge, etc.). The re-powering of the cell has no choice but to return to the known state because it was designed that way on purpose (and we had 14 years of experience doing that, so we got pretty good at it, too). This asymmetric cell power on is what we used to prevent power on current surges. Unfortunately with ultra-deep sub-micron and 20 million or more config bits, we could no longer count on 100% of the cells to power on to a 0 under all possible power supply ramp rates, process corners, voltages, and temperatures on all parts. So we abandoned that method for config.
We are preparing a USB card to demonstrate security concepts. One possible challenge we may issue is to ask people to hack it and tell us: what is the unencrypted bitstream? what is the key? how can you make the application do what you want it to (the app is a true random number generator -- make it do something non-random)? I would love to have determined hackers attack our device, and let us know just how secure it really is. That way, any weakness can be corrected in the next generation.
Email me directly if you are interested. It will probably be sometime in early 2005 that we will go out with this on a large scale (if there is sufficient interest). But in the meantime, we will trial it with a few serious and determined engineers.
It is one thing to talk about it, it is another altogether to actually try to crack it.
We will provide a full set of schematics and a description of what it does, and how it is intended to be used. No obscurity, just security.
I was just contemplating adding a wide/shallow memory to my design and realized I *could* implement a 256 deep, 64bit wide memory in the BlockRAM. The only trouble is it's single-port.
I wrote, in regards to PCI Express implementations not using the distributed reference clock:
This is false. You cannot do this. Such a design would result in clocks off by up to 400 ppm. The Virtex-II Pro transceivers are not guaranteed to lock over that range. In a PCI Express system, you will need to do a 1.25 multply and clean up the reference clock with a PLL.
I apologize for providing incorrect information. Eric
Hi Jim/All, So after discussing it with Austin and Peter, we believe that it might indeed be possible to generate 32 different phases of clock in V4. You will need to use 8 DCM's 4 in the top half of the chip and
4 in the bottom half of the chip. Each DCM can generate 4 phases
0,90,180,360 and can be offset by a delay of 1/32 of the clock from the other DCM's. Routing the same input clock to all 8 DCM's may require using two different IO pins one for each half of the chip. The use of two IOB pins may create some systemic skew between 16 phases and the other 16 phases - but the IOB Idelay should help minimize that.
I am not an expert on a lot of this (IOB/DCM) but I think it is feasible. Jim, perhaps you could try implementing it in V4 - and if you run into any problems - I am sure Austin/Peter could help you. At the very least generating 16 phases should be a cinch.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.