jbits
GaLaKtIkUs™
Can somebody give me some advices about jbits.
I want to use it in reconfigurable computing. What are its limits. Is
it useful?
Some one already told me "Jbits is dead" but didn't explain why !
Mehdi
Adam Megacz
> Some one already told me "Jbits is dead" but didn't explain why !
Because http://www.megacz.com/research/bitstream.secrecy.xt
- a
--
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380
Austin Lesea
It was pointed out to me the other day, that Neocad reverse engineered
bitgen. They never reverse engineered the bitstream (had no idea what
controlled what).
Folks are ofthen fond of saying "there is no security in obscurity" but
then they do not have to search for a needle in a haystack.
Keeping the bitstream secret is still a powerful means of preventing
reverse engineering.
Lately I asked a well know reverse engineering firm to do their job, and
tell me what the design was given only the bitstream.
They no bid the job "as we felt it would take to long, and cost too
much." That definitely surprised me, as to refuse business for
something that is understandably long and arduous (read $$$) was a surprise.
But from their point of view, they would much rather go after something
that was easier (cut, section, etc.) and had immediate payback.
Now it is said that governments would not be so limited (they would
reverse engineeer a bitstream).
Very few of our customers are worried about a governement stealing their
designs and intellectual property. For those that are (other
governments), we are happy to assure them that the bitstream still
remains a secret (for what that is worth, which may in fact be a lot).
So far the 'Logic Vault' cards I have sent out to academia have not been
able to be cracked by DPA (a commonly held belief is that differential
power attack (DPA) is able to 'crack' 3DES or AES easily). Seems that
finding the keys in a smart card may be a junior EE class exercise, but
going after something a bit more challenging (like the keys held in out
battery backed RAM) is no easy task.
I'd like to think that it has to do with brilliant engineering, but it
is more likely that one can not discern the information from the noise
of all those pesky support transistors that clutter up a FPGA.
Austin
Adam Megacz
Austin Lesea <aus...@xilinx.com> writes:
> It was pointed out to me the other day, that Neocad reverse engineered
> bitgen. They never reverse engineered the bitstream (had no idea what
> controlled what).
Austin, please cite a source for this.
Xilinx would have sued them halfway to the moon if their product
required "bitgen.dll" (or equivalent) from the Xilinx ISE in order to
function. That would be clear infringement on Xilinx's copyrights and
any judge would have been more than happy to hand down an injunction
putting them out of business.
- a
Austin Lesea
The things you learn after you buy a company.
Personally, I think it was for the best that we purchased Neocad...
Austin
Simon Peacock
project... is to pay off one of the designers and just get him to send you
the source.
Of course you might get caught.. but then it comes down to who has the
biggest check book for lawyers.
Back in the 80's I was given a book on the costliest computer hacks... the
first was a disgruntled employee with a fire-axe ... (there's a moral here)
Simon
"Austin Lesea" <aus...@xilinx.com> wrote in message
news:dh92it$sk...@xco-news.xilinx.com...
GaLaKtIkUs™
So: the jbits is just an illusion and reverse engineering the bitstream
is too complex.
What about accessing the internal configuration data? what is the
degree of complexity and the limits of this approach?
Another (which may solve definatly the problem :) ) would create from
scratch an open source FPGA :)
GaLaKtIkUs™
it would be very easy for FPGA vendors to make FPGAs which offer two
modes of functionning: a secured mode which uses encrypted bitstreams
(for ultra-secret applications :) ) and a "non-secure" mode for use in
cases where the protection of the low level infos is not important.