Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I've gotten lots of private e-mails on this one since it started last week. So far, the PDL approach (not on the bit stream, but sitting beside the FPGA) with some sort of LFSR looks best. It's crackable, but it would take some work to do it. All in all, I'll stand on what I said before. FPGAs are not secure, if you have algorithms you don't want copies, don't put them in FPGAs. This is why there are some "cheap" places you can go to get ASICs done. Chip Express, or some sort of "hot wire" FPGA comes to mind. What the industry needs for FPGAs to take off is some sort of DES like encription which can be OPTIONALLY used on the bit stream. You'll need to make the part 1 time programmable with a key, and you will also need to put that key in the software so that it can encode the stream. This can still be brute force cracked, but it would take awhile. -- NAME: David W. Bishop INTERNET: dbishop@vhdl.org ( \ ) US MAIL: Hilton NY 14468-9101 A Long time ago, \__\/ PHYSICAL: 43:17:17N 77:47:37W 281' In a Galaxy far, far away... | | For Supernova info: http://www.ggw.org/asras/snimages | | For VHDL/Synthesis info: http://www.vhdl.org/siwg _/___\_ All standard disclaimers apply. [_______]Article: 22326
On 04 May 2000 18:54:46 -0400, Paul Bunyk <paul@pbunyk.physics.sunysb.edu> wrote: | |Hello, everyone! | |I'm developing a new (at least pretty much unheard of) supercondicting |logic family (RSFQ) and I'd like to make a demo chip implementing some |kind of regular programmable logic function similar to FPGAs/CPLDs. | |I wonder if someone can point me to the information about the earliest |and simplest FPGA structures which I can try to implement. At this |point gate density is really low, I can fit something like couple K |gates on a chip, but speed is tremendous (several tens of GHz) with |negligible power consumption (and yes, it requires liquid He |refrigeration! :) ). | |Why am I doing it? We need to demonstrate a working chip fast, all |design is pretty much hand-built now (thus I want to make this demo as |regular as possible) and, since there is no way to talk to room |temperature electronics at 20 GHz speed, I want to make this |demonstration by (slowly) programming the chip from room temperature, |then running it for something like 1 microsecond and slowly |reading-out the results (showing that it actually had performed like |20000 steps in that one usec :) ). Thus I can not make just a simple |PLA, it has to keep enough state on-chip to be busy for couple |thousands cycles crunching on it. | |Another limitation is that the structure should have relatively short |connections on the chip, preferably arranged in systolic array-like |pattern (it takes time comparable to the 50 ps clock cycle to pass a |signal across the chip just due to the finite speed of light in |on-chip microstrips). | |And, of course, we should be able to claim that it is an |"interesting" digital system, showing some "useful" algorithms |implemented in that. | |Any suggestions? | |Sincerely, | |Paul Bunyk | |P.S. A cc: of your replys to my mailbox would be very much |appreciated! :) Wouldn't some simpler logic circuits prove the technology? And, uh, when you show this to potential investors, you might consider spelling 'superconducting' properly. JohnArticle: 22327
David Kessner wrote: > "Nicholas C. Weaver" wrote: > > (Note, this is equivelent to the other solution except that > > since N always increments, you don't need to send N from the FPGA to > > CPLD). The actual PRNG or encryption can be whatever is desired). > > Yes, there were several solutions mentioned that were "similar but not > identical". It's not rocket science, so just about everyone would > arrive at the same solution especially if people are actually talking > about it and working it though. I'm actually wondering why it took > so long to come to this solution, since we had all the pieces many > years ago. > > > The problem is the attacks outside the protocol, extracting > > the key from the FPGA bitfile, etc, etc, etc. I don't think this > > would stop a not very determined copier, since he is already going > > through considerable effort. Attacking the bitfile with jbits and > > working backwards would undoubtedly occur, to get the key, and this > > would not be a significant hurdle for the attacker. > > Remember that Jbits only works with the Virtex. There are other > SRAM based FPGA's out there that are not at as easily reverse > engineered. Xilinx Spartan's, Altera Apex, and Cypress Delta39K > just to name a few. There is Jbits for 4K/spartan too. > > > One of the primary goals that I had was to use off the shelf > technology. A consequence of this is that it does leave the door > wide open to reverse engineering the FPGA bitstream. Reverse > engineering a bitstream is a non-trivial task, about as easy as > breaking the LFSR itself (assuming the LFSR is <40 bits). LFSRs are really pretty easy to break. If all you have is the output stream, it only takes N^2 consecutive samples to determine the taps and the initial state for an N bit LFSR. You'll probably want a more robust encryption. > > > Until FPGA's have crypto hardware built in then this type of > attack will always exist for all copy protection schemes. The FPGA would also have to have a unique key in it, and herein lies the problem. Even if you did put flash in it with a security bit, it might be possible to read the key back out by playing with program voltages etc or by de-lidding and inspection. > > > > I think the only effective solution apart from > > battery-backup/always on, or convincing the vendors to build in a > > cryptographic module onto the silicon, is to write good contracts and > > just make little tweaks which make the lawyers lives easier. > > > > Embedding a small amount of hidden information in the > > configuration of each serial EPROM burned gives a tracking number > > which, unless the attacker knows about it and can scrub it out, can be > > used to state that "I sold you device #xxxyy. Device #xxxyy was > > copied. You violated my copyright, and you violated our contract. > > You will be hearing from the firm of Dewey, Cheatam, and Howe. Have a > > nice day". > > Copy protection schemes that rely on contracts and legal hooks will > not succeed. Well, it might succeed if you are selling only a few > units to well a couple of well defined customers. But it doesn't > work if you're selling thousands of units into the mass market where > you have almost no control over who gets your products. > > The truth is that many pirates work in countries where people like > you and I have almost no legal rights. I once had a board of mine > copied. The pirate was operating out of Taiwan. We knew who he was, > his name, and even the street address of his store front. We had > lots of evidence that he was selling an illegal copy. After many long > discussions with the various lawyers, it was determined that we could > spend millions of dollars in court and probably still loose. It's > not right, fair, or ethical, but that's the way Taiwan is. Americans > rarely win a lawsuit in Taiwan, period. > > So good contracts, embedded serial numbers, patents, etc. will not > protect our design from foreign pirates. > > The LFSR scheme isn't perfect, but it is the most effective I've > seen to date given the cost, size, and manufacturability limitations. > And I believe that it is an effective barrier (but not impenetrable > barrier) against most pirates. > > David Kessner > davidk@free-ip.com -- P.S. Please note the new email address and website url -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 22328
Hi Evan,
Thanks for your help. Below is my code for your examination. You are
right to say that it is slightly diff. at the initial state. Thereafter,
it should be the same after the 1st clock. I tested the code with
Synopsys DC and FPGA express. Both give me the same warning for code
(1). Are you suggesting that I should revert to code (2) style to pass
the synthesis test. If that is the case, why there is a couple of
textbook still used code (1) as a synthesizable reference code which is
quite misleading!
I am one of the victim which I hope not.
Look forward to your reply.
architecture arcCounter of ntyCounter is
type typCounterState is (s0, s1, s2, s3);
signal sNextState : typCounterState;
signal sCurrState : typCounterState;
begin -- arcCounter
lblUpdState: process(pClk) --> code (2) style
-- lblUpdState: process --> code (1) style
begin
-- wait until rising_edge(pClk); --> code (1) style
if rising_edge(pClk) then --> code (2) style
if pRst_b = '0' then
sCurrState <= s0;
else
sCurrState <= sNextState;
end if;
end if; --> code (2) style
end process lblUpdState;
end arcCounter;
Yeo Wee Kwong, Sky (Mr)
Research Scholar
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
School of Applied Science
Center For High Performance Embedded Systems (ChiPES)
Nanyang Technological University
Blk N4-B3-06b Nanyang Avenue
Singapore 639798
* (65) 790-6967 *Fax (65) 792-6559 * yeosky@singnet.com.sg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Words Of Wisdom:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Let it be the way you want to be!. Amen!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----Original Message-----
From: eml@riverside-machines.com.NOSPAM
[mailto:eml@riverside-machines.com.NOSPAM]
Posted At: Friday, May 05, 2000 4:03 AM
Posted To: comp.arch.fpga
Conversation: Wait until statement problem in
synthesis
Subject: Re: Wait until statement problem in
synthesis
On Wed, 3 May 2000 18:34:59 +0800 , #YEO WEE KWONG#
<P7102672H@ntu.edu.sg> wrote:
>Hi,
>
>I wonder why wait until statement when used in a
process can generate a
>warning of :
>
>Warning: Clock signal is not in the sensitivity list.
"pClk"
> in routine ntyCounter line 18 in file
>'/home/yeowk/vhdl.dir/MyProj.dir/Vhdl.dir/arcCounter.vhd' (HDL-400)
you can't have a wait and a sensitivity list in the same
process. can
you post your code?
>I thought that code (1) is the same as code (2)
functionally:
>
>process -- Code(1)
>begin
> wait until rising_edge(clk);
> :
> :
> :
>end process;
>
>process(Clk) - Code(2)
>begin
> if rising_edge(Clk) then
> :
> :
> :
> end if;
>end process
the two aren't quite equivalent. the sensitivity list
version is
equivalent to a process with a wait as the *last*
statement, not the
first statement. they'll behave differently at
initialisation.
>I check the Solvit in Synopsys but cannot find any
workaround. Can
>someone enlightened why the above statement is not
accepted in synthesis
>engine(particular Synopsys).
you'll have to ask synopsys. i do remember that some
cheaper synthesis
tools would only allow wait statements as the last
statement in a
process - you could try this as a workaround.
>By the way, code(2) pass the synthesis without warning!
Can you explain?
this is a standard mechanism for specifying a clocked
process to a
synthesiser - it'll work with any synthesiser (even FPGA
express).
evan
Article: 22329I said you need 2*N not 2^N output bits. If N is 36, the first 72 bits output by the CPLD are all that is required to completely reverse engineer it (both tap positions and reset state). An LFSR is really a very bad choice in this case, no matter what the size and clock rate are. Now let us say you use an XC9572 (not much more expensive than the XC9536) and you build a number of LFSRs (with different cycle lengths, mutually prime if possible) and output the exclusive-or of their outputs. The period is now really big, even if you overclock the CPLD. This might be a little harder to break but I am not sure it is much harder. Catalin Rickman wrote: > a@z.com wrote: > > > > Hi David, > > > > I do not think your idea will work because reverse engineering the CPLD > > is realy easy. All you need to do is capture a sequence of 2*n bits, > > where n is the size of your LFSR. The first n bits will be shifted into > > your LFSR and the next n will give you the LFSR response starting from > > this known state. From this the position of your taps and the initial > > key can be easily extracted. It's like solving a system of n equations > > with n unknowns (the taps) in a finite binary field. Even if n is not > > known there is only a limited number of lentghs you have to try (not > > more than the number of macrocells in your EPLD). This scheme can be > > broken in less than one hour using just a memory oscilloscope or a logic > > analyzer. > > > > Catalin > > > > David Kessner wrote: > > > > > Ray Andraka wrote: > > > > Heavy Sigh! This subject comes up about once every 6-9 months. > > > > > > Exactly, and so why have we not come up with a reasonable > > > solution before? I don't know... > > > > > > I have written an app note on this subject, and propose a simple > > > solution using off the shelf technology. It can be read at The > > > Free-IP Project web site: http://www.free-ip.com > > > > > > I welcome any comments on it, but my news server is flaky to say > > > the least. So please follow up via email. > > > > > > David Kessner > > > davidk@free-ip.com > > If the CPLD is designed to not let you "overclock it" it takes longer > than that to get the 2^N bits out of it at the sizes of N we are talking > about. At 1 MHz you would half to clock it for a day to get 2^36 bits > out. Then how exactly would you process that much data, 8 GB? > > However, one of the other posts indicates that you only need 36^2 bits > to find both the taps and the initial state of a 36 bit LFSR. So this is > not a workable solution after all. > > -- > > Rick Collins > > rick.collins@XYarius.com > > remove the XY to email me. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.comArticle: 22330
It appears that 9.6 has the same dongle bug. I did not try 9.4, but know
that 9.3 does not have this problem. There is no printers or for that
matter any other devices plugged into the printer ports, just the dongle.
Printing is done via TCP-IP. I have check this on three different PCs from
my dual PIII 500 to a single Pentium 200, all with the same results. Small
projects seem to build fine, but larger ones that take hours to build will
fail the dongle checks at random. Some times when the timing extractor
runs, other times when the fitter is running. All PCs are running Windows
NT 4.0 SP5 or 6. Altera now tells me that it is a known problem, but they
do not have a fix in place. I asked them why they continue to master new
updates when the basic dongle interface has bugs. No responce. They were
supposed to send a temp license today, but I never recieved it. The temp
license would have a time out anyway so I could not use the version to do
real work because I need to be able to reproduce the results from the tools
I use for some time. So it's back to 9.32.
On the flip side the 9.6 version seems to have fixed my fitter problems
when using the Quartus features.
Subject:
Re: MaxPlus9.5 License and Fitter problems
Date:
04/21/2000
Author:
Jim Hamblen <hamblen@ece.gatech.edu>
I also have some designs that crash with internal errors unless I turn off
the Quartus fitter. They run OK when I
turn it off.
As for the dongle problem, in the past I have seen them conflict with
other dongles or a printer (if you have
any of those connected). I had one system with three dongles and it only
worked when they were stacked in
one order - that I found by trial and error.
Tim wrote:
> On Thu, 30 Mar 2000 02:14:26 GMT, "M R Wheeler"
> <intell-a-sys@iquest.net> wrote:
>
> >I am evaluating MaxPlus 9.5 and am finding that often the software can
not
> >seem to locate the dongle during the build process on larger designs.
The
> >software give me a license error message. Also, when selecting the
Quartus
> >fitter, I am getting internal errors (contact Altera, who never has a
> >clue). Both problems occur on two different computers. Just wonder if
> >anyone else is using this version yet.
> >
>
> I haven't had any problems using our floating network license. I also
> haven't had any crashes yet. Still, each new version fixes a thousand
> bugs and adds a thousand more so we'll see.
>
> Oh, I did have to turn off the Quartus fitter to make the timing
> requirement in a design that easily makes the timing requirements in
> 9.3.
>
> Up to 25xs faster compile....the gods of marketing are feeling playful
> today.
>
> Tim.
Article: 22331Hi Jim, Jim Granville wrote: > a@z.com wrote: > > > > Hi David, > > > > I do not think your idea will work because reverse engineering the CPLD > > is realy easy. All you need to do is capture a sequence of 2*n bits, > > where n is the size of your LFSR. > > True, but who says you have to code a LFSR in the CPLD, and use > obvious LD.CLK.DATA pins. Well, David Kessner does. He proposed at http://www.free-ip.com/copyprotection.html a CPLD key based on a 36-bit LFSR and asked for comments. > That's why I mentioned the ATF750, ( 24 pin CPLD ) with either > edge clock, on any cell, you can create something that defies > modeling - mixing PROM and Sequential state logic also makes > stream analysis very hard. > Then add cross coupled clock enables, and async clocks... David also makes the point - and I think he is right - that the protection should be strong enough by design so that its internal structure can be made public without compromising the key. A secret design is a weak design is a basic cryptography concept which applies in this case too. Nothing that is made with digital logic defies modeling - no matter how clever your design is (clock enables, async clocks, etc.) it is still a finite state machine and can be modeled as such. What matters is observabilty of the hidden state and controllability (if you have inputs). Adding inputs (clocks, enables, data in) might be a bad idea because you make the system more controllable - using these inputs I can bring your system to a large number of known states and explore the state space from each point. What you think is your strong point might turn out to be your Achilles' heel. From a controllability point of view, the ideal system would have no inputs at all, as David proposed, an uncontrollable system. The problem with his idea is that his state machine (a 36-bit LFSR) is completely and easily observable - all you need is 72 consecutive output bits to find out the complete state space map (the LFSR taps) and the initial state. With 72 macrocells there must be a lot of finite state machines with no inputs that produce an output sequence such that you need to acquire too many bits to completely observe the system state, even if you know the structure of the state machine and the only unknown is the initial state. No need for fancy hidden tricks, just use the right design and make it big enough. Then make it _public_ and challenge everyone to break it. If a lot of people try and nobody succeeds then _maybe_ you have a winner. Catalin > Connect spare pins to the FPGA, and the combinations explode. > > -jg > -- > ======= 80x51 Tools & IP Specialists ========= > = Want to work smarter than C ? > = http://www.DesignTools.co.nz/modbench.htm > = http://www.DesignTools.co.nzArticle: 22332
Hi all, A "true" random number generator is easy to do in an FPGA. Just use your system clock and either the FPGA internal oscillator or a ring oscillator that you create by programming a LUT as an inverter and connecting its input to its output. Then connect these two independent clocks to the D and CLK pins of a flip-flop and metastability will work for you this time. Pass the Q of the flip-flop trough an LFSR and you have a true random number generator. Another problem mentioned here is reseting the system to keep the CPLD sequence to be emulated short. This too can be solved in the FPGA: since CLB RAM is not reset by the GSR it can be used to implement a watchdog counter and detect this kind of attack. Catalin "Nicholas C. Weaver" wrote: > In article <3911B800.B34AE07B@yahoo.com>, > Rickman <spamgoeshere4@yahoo.com> wrote: > > >to do that. Am I correct in assuming that the bitstream from the > >security device will run continuously? This would mean that it will > >consume power indefinately. I guess this would not be a problem as long > >as the power level is kept very low. You might want to add low power to > >your list of requirements in addition to low cost. > > Yes, it would and it has to, unless you can get a good real > random number generator in the FPGA. > > >If a shorter reset period could be used, say 1 minute, then the memory > >required is only 60 Mb which can be put on one chip. Using a slower > >bitstream clock to save power would also increase the feasibility of > >attack by frequent reset. > > Yeup, that is one of the potential attacks. The only way to > counter it is a true random number generator in the FPGA to initialize > the state. > -- > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 22333
In article <39122443.DD973388@fpga-guru.com>, Ray Andraka <ray@fpga-guru.com> wrote: >> Until FPGA's have crypto hardware built in then this type of >> attack will always exist for all copy protection schemes. > >The FPGA would also have to have a unique key in it, and herein lies the >problem. Even if you did put flash in it with a security bit, it might be >possible to read the key back out by playing with program voltages etc or by >de-lidding and inspection. However, the barrier for extracting the key from the internal rom is considerably higher, close to what reverse engineering an ASIC or antifuse or similar part but a little less than continual battery backuped SRAM device. The other schemes mentioned here are really not very high barriers, not all that much more then just reverse engineering a board which was dipped in concrete. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 22334
Catalin Baetoniu wrote: > > Hi all, > > A "true" random number generator is easy to do in an FPGA. Just use your > system clock and either the FPGA internal oscillator or a ring oscillator that > you create by programming a LUT as an inverter and connecting its input to its > output. Then connect these two independent clocks to the D and CLK pins of a > flip-flop and metastability will work for you this time. Pass the Q of the > flip-flop trough an LFSR and you have a true random number generator. The metastability RNG might work ok. This is a good idea. Interestingly enough, a PRNG or a RNG is really not what is needed in this case. Most of the properites of these devices are not required. For example, you don't need for the output to be evenly distributed or unbiased. You only need for it to be run through the full range in a sequence that is not 100% predictable. Personally, I think a free running oscillator RNG is the solution with the most potential. > Another problem mentioned here is reseting the system to keep the CPLD > sequence to be emulated short. This too can be solved in the FPGA: since CLB > RAM is not reset by the GSR it can be used to implement a watchdog counter and > detect this kind of attack. > > Catalin The issue with CLB RAM is not whether it is cleared on reset. The issue is whether it is cleared on configuration. It only takes a millisecond or so to reload most FPGAs. Many systems would not notice this small amount of time that the FPGA was down. In fact, some systems use a full reset and reconfiguration to keep things working correctly. Just ask rk. He is testing this concept to use on a space mission to make Xilinx parts fully resistant to radiation! -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22335
Catalin Baetoniu wrote: > > I said you need 2*N not 2^N output bits. If N is 36, the first 72 bits output > by the CPLD are all that is required to completely reverse engineer it (both > tap positions and reset state). An LFSR is really a very bad choice in this > case, no matter what the size and clock rate are. > > Now let us say you use an XC9572 (not much more expensive than the XC9536) and > you build a number of LFSRs (with different cycle lengths, mutually prime if > possible) and output the exclusive-or of their outputs. The period is now > really big, even if you overclock the CPLD. This might be a little harder to > break but I am not sure it is much harder. > > Catalin Sorry, one of the other posts indicated that N^2 was needed for the case of not knowing the taps. I misread your post. What is the process for reverse engineering a LFSR from the N*2 samples? Surely it would not be a matter of trial and error. Is there some way to calculate the taps and starting number? I agree that with an N bit LFSR, two different machines must give different results within 2*N bits. If they don't they MUST be the same machine. But that is not the same as saying you can deduce the starting number and taps without trying all possible machines and starting positions. That would be like saying DES is breakable by trying all possible keys. I think it is interesting that no one has posted an algorithm other than a full blown DES that will meet our needs. Is it possible that there are no solutions that even come close to what we need without the full robustness of DES? -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22336
Catalin Baetoniu wrote: > David also makes the point - and I think he is right - that the protection > should be strong enough by design so that its internal structure can be made > public without compromising the key. A secret design is a weak design is a > basic cryptography concept which applies in this case too. > > Nothing that is made with digital logic defies modeling - no matter how > clever your design is (clock enables, async clocks, etc.) it is still a > finite state machine and can be modeled as such. What matters is observabilty > of the hidden state and controllability (if you have inputs). Adding inputs > (clocks, enables, data in) might be a bad idea because you make the system > more controllable - using these inputs I can bring your system to a large > number of known states and explore the state space from each point. What you > think is your strong point might turn out to be your Achilles' heel. From a > controllability point of view, the ideal system would have no inputs at all, > as David proposed, an uncontrollable system. The problem with his idea is > that his state machine (a 36-bit LFSR) is completely and easily observable - > all you need is 72 consecutive output bits to find out the complete state > space map (the LFSR taps) and the initial state. With 72 macrocells there > must be a lot of finite state machines with no inputs that produce an output > sequence such that you need to acquire too many bits to completely observe > the system state, even if you know the structure of the state machine and the > only unknown is the initial state. No need for fancy hidden tricks, just use > the right design and make it big enough. Then make it _public_ and challenge > everyone to break it. If a lot of people try and nobody succeeds then _maybe_ > you have a winner. > > Catalin Yes, this is exactly what we are looking for. An algorithm that will not be analyzable from examining the outputs. But stating the problem in only half the solution and the easy half at that. I am wondering if there is a solution that is trivial to implement in a CPLD or even a very small micro. Something as complex as DES would be too expensive to build into the FPGA. Or maybe the cryptographers already know the solution, but they aren't telling!!!??? -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22337
In article <3912497B.7F608289@yahoo.com>, Rickman <spamgoeshere4@yahoo.com> wrote: >Or maybe the cryptographers already know the solution, but they aren't >telling!!!??? They do, it's a pretty easy application of a good cypher. Just E(N,K) for a good E and a random K, gives a pseudo random number, just increment N. However, the algorithms you would want to use will NOT fit comfortably in a $1 cpld. DES, which is pretty small, is still larger then you want. I HAVE seen a couple of really small & cute algorithms, but they are still signifcantly larger than you want. And, as discussed, the problem quickly becomes one of attacking the system. An LFSR is too weak, but much more quickly becomes overkill when compared with jbitsing the bitfile. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 22338
Ok... Here's my summary, to date, of this LFSR method: Using a cryptographically strong LFSR, there is no reasonable way to break the LFSR by analyzing the random bit stream. This might take more than 64 macrocells and more than 20 slices/CLB's. Some might debate this, but it's a moot point because... Ray Andraka <ray@fpga-guru.com> wrote: > There is Jbits for 4K/spartan too. Damn! So we can basically write off this method, and just about any other method, that uses current Xilinx chips. (Hey, you killed Kenny! You bastard!) While this method is still applicable to Altera and other FPGA's, there are other problems... Ray also said (paraphrased): > With Flash EEPROM or a Flash based CPLD, it might be > possible to read the key back out by playing with program voltages etc or by > de-lidding and inspection. I think that this would be ad-hoc at best, and trial and error at worst. But none the less, I conceed that this is a potential way to attack and it might even be successful. Here's what I currently think the LFSR method is good for: A simple encryption quality LFSR when implemented in a CPLD and Non-Xilinx SRAM based FPGA is sufficent to deter most casual pirates. But any professional pirate willing to devote some time and money at it will probably be able to break this method in a reasonable time frame using one of the previously mentioned approaches. In short, I conceed defeat on this one. Unfortunately, what this shows is that more sophisticated encryption would not increase the security given the existance of JBits for all Xilinx parts of interest and given the vulnerability of Flash based CPLD's (and probably uC's as well). Oh well. It was a nice try... :( And another thing... Someone mentioned using a free-running oscilator (made from an inverter fed back into itself) as a source for random numbers. Unfortunately this doesn't work. It works in the simulators, but not in real devices. If you put two of these oscilators on the same FPGA (and nothing else) they tend to lock to eachother and will eventually will be in sync and remain in sync. With just one of these oscilators on a full FPGA, the osc will tend to lock to some other source of noise in the system which will make the random numbers highly correlated to what's going on in the FPGA-- not random at all. Using the on board temperature sensor doesn't work either-- at least not for security uses. That's because the temp sensor requires that the signals be ran outside the chip. If they are outside the chip then they are vulerable to attack. For instance, someone could just ground those signals and force the random number generator to always output zero (or one, or whatever). David Kessner davidk@free-ip.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 22339
Philip Freidin wrote: > >I have do a small design with a Xilinx FPGA (XC5200 but it's normaly the > >same thing on Spartan and 4000) on Slave Serial mode. When I program it, > >after N bits sended, it pull down the init/ line. I don't understand why > >I have a CRC error because each bit sended (on the pin DIN) is at each > >time compared with the DOUT pin after. > > If you really have ALL the input bits appearing onthe DOUT, this is > definitely not good. The data on the DOUT pin will be a delayed by 1 > cycle version of the data on the DIN pin, but ONLY for the duration of > the header (40 bits). After the header, the DOUT pin should be high for > the duration of the bitstream, and then reverts to echoing the DIN data > to load down stream parts. In a single chip situation, there is no > downstream devices, so the device will complete and then go DONE. > Yes I have read all data after the write cycle... But the DOUT pin hold the bit ! In fact if you see the databook XC5200 p7-114 you could see the chronogram with all data bit reported after the write cycle on the DOUT pin %-( I have never read that is only for the header sequence... But if you're sure, perhaps the header is not correctly read byt the FPGA and all bits are reported on the DOUT pin :( > Is the config clock running before the configuration starts, > and loads junk before the header? > No, I'm sure that the CCLK pin is correctly drive because when I use the ISA bus to drive a control logic that generate the CCLK signal for the FPGA. > Is the config clock clean, both rising and falling edges, check > with at least a 300MHz scope. hum.... I must check it with a oscilloscope but this signal has already test my board with others latchs (just for tests) so... > Are you changing DIN data when the CCLK clock edge rises, You > shouldn't > Year... DIN is at least 60ns set before the CCLK rising edge (20ns is the minimal setup time) > >Have you already find the same problem ? I think perhaps it's due at a > >power problem, because the ouputs pin HDC and LDC/ are at 5V and 1.1 > >V (and no near 0V) respectivly. > > > > An unloaded HDC could be at 5V, but LDC should be near ground. What do you > have connected to it? > Just a volt-tester :( It's really strange to see 1.1V on the LDC/ line ! > >But if the FPGA is not correctly powered, why it accepts bit during > >configuration process and put DOUT correctly ?? %-( > > As I said above, this is not correct. DOUT only follows DIN during the > header, and after the device is configured, not while configuring. Are > the two pins shorted? > No of course, the two pins aren't shorted. How it's possible to read all bit sended on the DIN pin, on the DOUT pin ? Thanks for your help,Article: 22340
I am spending way too much time reading these messages, but I find this very interesting. So let me play devil's advocate on this. david_kessner@my-deja.com wrote: > > Ok... Here's my summary, to date, of this LFSR method: > > Using a cryptographically strong LFSR, there is no reasonable way to break > the LFSR by analyzing the random bit stream. This might take more than 64 > macrocells and more than 20 slices/CLB's. Some might debate this, but it's a > moot point because... Can you define, or better yet give an example of a "cryptographically strong LFSR"? I do believe it when people have stated that if you know the structure of a LFSR of length N, it will only take N samples to determin the initial state. I will also submit to the statement that if the structure is not known, then it may be possible to determin the initial state as well as the taps with 2N samples, although I am not certain you can do this without trying all possiblities which would be way too expensive for any but the most well funded efforts. But it certainly makes sense that a LFSR is not truly robust against an analysis. So how do you design a LFSR that can not be easily analyzed? > Ray Andraka <ray@fpga-guru.com> wrote: > > There is Jbits for 4K/spartan too. > > Damn! So we can basically write off this method, and just about any other > method, that uses current Xilinx chips. (Hey, you killed Kenny! You > bastard!) > > While this method is still applicable to Altera and other FPGA's, there are > other problems... This is a case of ignorance being bliss. I am not aware that Jbits allows you to reverse engineer a Xilinx bitstream. Is this true or is it just that Jbits makes it easier to reverse engineer the Xilinx parts in general and you would still have a major effort in doing so? If you have to use Jbits to twiddle a bit then you load it into an FPGA and see what you just changed, then I don't consider this to be an easy way to reverse engineer a Xilinx configuration bitstream. > Ray also said (paraphrased): > > With Flash EEPROM or a Flash based CPLD, it might be > > possible to read the key back out by playing with program voltages etc or by > > de-lidding and inspection. > > I think that this would be ad-hoc at best, and trial and error at worst. But > none the less, I conceed that this is a potential way to attack and it > might even be successful. Certainly you could conceivably delid a device and examine it with an electron microscope to analyze it while it is on. I have seen electron micrographs of circuits in real time. But again I don't consider this to be in the realm of "easy". I doubt that I would spend as much time and money on designing the circuit as they would reverse engineering it this way. > Here's what I currently think the LFSR method is good for: > > A simple encryption quality LFSR when implemented in a CPLD > and Non-Xilinx SRAM based FPGA is sufficent to deter most > casual pirates. But any professional pirate willing to devote some > time and money at it will probably be able to break this method in > a reasonable time frame using one of the previously mentioned > approaches. In short, I conceed defeat on this one. > > Unfortunately, what this shows is that more sophisticated > encryption would not increase the security given the existance > of JBits for all Xilinx parts of interest and given the vulnerability > of Flash based CPLD's (and probably uC's as well). > > Oh well. It was a nice try... :( Others have indicated that the LFSR is less robust and I feel that the Xilinx design and the CPLD (or micro in my case) are more robust than my requirements. So depending on just how hard it is to attack the LFSR initial state, we may need a more robust algorithm. > And another thing... Someone mentioned using a free-running > oscilator (made from an inverter fed back into itself) as a source > for random numbers. Unfortunately this doesn't work. It works > in the simulators, but not in real devices. If you put two of these > oscilators on the same FPGA (and nothing else) they tend to > lock to eachother and will eventually will be in sync and remain > in sync. With just one of these oscilators on a full FPGA, the > osc will tend to lock to some other source of noise in the system > which will make the random numbers highly correlated to what's > going on in the FPGA-- not random at all. I am not convinced that this is really a problem. If the two oscillators lock to some ratio on a given board, that will not say that they will allways lock at that ratio on every board. The random numbers only have to produce a pattern of numbers that is not repeatable on powerup. Even if the two oscillators are locked, that will not guarantee that they will produce the same result every time like a computer program would. Remember that the non-crystal oscillator will be voltage, temperature and process dependant as well. > Using the on board temperature sensor doesn't work either-- > at least not for security uses. That's because the temp > sensor requires that the signals be ran outside the chip. > If they are outside the chip then they are vulerable to attack. > For instance, someone could just ground those signals and > force the random number generator to always output zero > (or one, or whatever). > > David Kessner > davidk@free-ip.com > > Sent via Deja.com http://www.deja.com/ > Before you buy. I would be willing to bet that a form of stimulus, response approach would be the most resistant to attack. The FPGA uses the non-repeated (as opposed to PRNG) generator from the free running oscillator to stimulate the Key Chip (since it may be a micro rather than a CPLD). The Key Chip then returns a result based on some processing with the LFSR. This can be duplicated in the FPGA with different initial conditions for different designs/customers as you choose. The FPGA would only stimulate the Key Chip say a hundred times a second. If the Key Chip is stimulated more often, it shuts down until power is removed. This would be resistant to copying the key bitstream since the stimulus will be different for different boards. Analysis would not work since the data can only be dragged out of the Key Chip at a very low data rate. Since the direct output of the LFSR is not observed, the LFSR initial state can not be analyzed. Does this cover all the bases? -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22341
> You should post your bitgen.ut file, then it would be easier for us to
> help you. Even if you use the GUI, there is a bitget.ut file created.
>
I don't known the ucf format :( I use Leonardo Spectrum on Unix to create a
edif or xnf... netlist. After I use Alliance on UNIX to translate the netlist
in ncf format and eventually generate a bitstream.
How format can I post ? Or perhaps the VHDL design ? It's just a VERY small
design to test the configuration process on the FPGA so...
> The point is, if you use the user clock as your startup clock, ...
> -g StartUpClk:USERCLK
> -g DoneActive:U2
> -g OutputsActive:U3
> -g GSRInactive:U4
>
> .. then you must instantiate a STARTUP component and connect its CLK
> input to some external clock source.
Incredible> Why I must instantiate a StartUp component on my design VHDL ? I
think really that you have right but it's not really logical. In fact, the
design FPGA represents only (for me !) the description of comportment
AFTER the configuration process. So why I must specify the configuration
process "component" in the design ?
Very strange technique, no ? So, here my VHDL "design"... Perhaps I have not
understand the objectif of the StartUp Component...
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
LIBRARY exemplar;
USE exemplar.exemplar_1164.ALL;
ENTITY FPGA IS
PORT (
Clock_i : IN STD_LOGIC;
Reset_ib : IN STD_LOGIC;
CCLK_i : IN STD_LOGIC;
CS_ib : IN STD_LOGIC;
RdWr_i : IN STD_LOGIC;
Data_io : INOUT STD_LOGIC_VECTOR(7 downto 0)
);
-- Pin Location --
------------------
ATTRIBUTE PIN_NUMBER : STRING;
ATTRIBUTE PIN_NUMBER OF Clock_i : SIGNAL IS "P35";
ATTRIBUTE PIN_NUMBER OF CCLK_i : SIGNAL IS "P73";
ATTRIBUTE PIN_NUMBER OF Reset_ib : SIGNAL IS "P84";
ATTRIBUTE PIN_NUMBER OF CS_ib : SIGNAL IS "P13";
ATTRIBUTE PIN_NUMBER OF RdWr_i : SIGNAL IS "P47";
ATTRIBUTE ARRAY_PIN_NUMBER OF Data_io : SIGNAL IS
("P56","P58","P59","P61","P65","P67","P69","P71");
-- Global CLK --
----------------
ATTRIBUTE BUFFER_SIG OF Clock_i : SIGNAL IS "BUFG";
ATTRIBUTE BUFFER_SIG OF CS_ib : SIGNAL IS "BUFG";
-- CLOCK definition --
----------------------
ATTRIBUTE CLOCK_CYCLE OF Clock_i : SIGNAL IS 83ns; -- 12 MHz (8 MHz =>
125ns)
--ATTRIBUTE CLOCK_OFFSET OF Clock_i : SIGNAL IS ns;
--ATTRIBUTE PULSE_WIDTH OF Clock_i : SIGNAL IS ns;
--ATTRIBUTE ARRIVAL_TIME OF Clock_i : SIGNAL IS ns;
END FPGA;
ARCHITECTURE XC5200 OF FPGA IS
SIGNAL Dummy1,Dummy2,Dummy3,Dummy4 : STD_LOGIC;
SIGNAL Reset : STD_LOGIC;
SIGNAL RegTmp: STD_LOGIC;
COMPONENT STARTBUF
PORT (GSRin, GTSin, CLKin : IN STD_LOGIC;
GSRout, GTSout, DONEinout, Q1Q4out, Q2out, Q3out : OUT STD_LOGIC);
END COMPONENT;
BEGIN
StartComponent:STARTBUF port map (GSRin => Reset_ib,
GTSin => '0',
CLKin => CCLK_i,
GSRout => Reset,
DONEinout => Dummy4,
Q1Q4out => Dummy1,
Q2out => Dummy2,
Q3out => Dummy3);
PROCESS (Clock_i)
BEGIN
IF Rising_Edge(Clock_i) THEN
IF (CS_ib = '0') THEN
IF (Reset = '0') THEN
RegTmp <= '0';
ELSE
IF (RdWr_i = '1') THEN
Data_io <= "0101010" & RegTmp;
ELSE
Data_io <= (others => 'Z');
END IF;
END IF;
END IF;
END IF;
END PROCESS;
END XC5200;
Thanks,
Sebastien
Article: 22342> What the industry needs for FPGAs to take off is some sort of DES like > encription which can be OPTIONALLY used on the bit stream. Do you have any data to verify that "take off" claim? Do you really think the volume of parts shipped would double if they had a solid anti-theft story? I'll toss in my two cents worth. All of the FPGAs I've worked on didn't have any security issues. They were used in complicated systems that were low volume. (If you could make them significiantly cheaper we would buy them from you rather than build them ourselves.) -- These are my opinions, not necessarily my employers.Article: 22343
Christian Mautner wrote: > just installed FPGA express 3.4 today, and had to accept that now the > step from XNF to EDIF has been taken. So I guess I'll have to dump my > xnf-parsing perl scripts. > > I tried to port the scripts to parse edif, but this is not very easy, > since the lispy file format is not very Perl-friendly, since Perl is > line-by-line and regexp based. I tried the perl-lisp package, but this > is not practical with several-MB-edif-files. > > So, did anyone succeed in writing edif parsing scripts? At the moment > I am looking into gcl (GNU common lisp) and clicc (common lisp to C > compiler), but it seems to be a rather long way to go. > > Is there any edif-netlist-reading-frontend for anything (like Perl, > python, tcl, or C) out there? (free and open source, of course) > > chm. > > -- > cmautner@ - Christian Mautner > utanet.at - Vienna/Austria/Europe EDIF and Tcl are stack-oriented programming languages, so I think a LISP interface might help you. A text processing LISP script must be very much compact code than conventional procedural languages. I think you can catch Tcl code around which would be in my opinion the best. AFAIK EDIF and Tcl are LISP variants. Utku -- I feel better than James Brown.Article: 22344
Hi frioend, has anybody worked with Arexsys tools? What do you think about SDL as system level description language? You experiences with Arexsys tools and about quality of partitioning, generated HDL and C And other your thinks about this point are greatly appreciated! Regards, Bonio My email is: Bonio.lopez@gmx.ch_Remove_this Sent via Deja.com http://www.deja.com/ Before you buy.Article: 22345
This is a periodic posting to let readers of these newsgroups know
about several online resources that may be relevant:
[1] Embedded Systems Glossary
http://www.netrino.com/Publications/Glossary/
[2] Embedded Systems Bibliography
http://www.netrino.com/Publications/Bibliography/
These are online versions of the Glossary and Bibliography from my
book, "Programming Embedded Systems in C and C++" (O'Reilly and
Associates, ISBN 1-56592-354-5).
It is my intention to make occasional changes and updates to these
online versions. I would very much like to hear your constructive
feedback. Please send your suggestions to <webmaster@netrino.com>.
I have put a lot of work into writing the book and creating and
maintaining these online resources. I hope that they will be a
valuable contribution to the community of embedded systems hard-
ware and software designers.
Sincerely,
Michael Barr
Article: 22346
I think what is being said is that you must have mistakenly selected the
USERCLK for the Startupclk in the GUI. There in normally not a strong
reason for changing the default from CCLK to USERCLK. If you do have a
reason for this change, then you need to provide a USERCLK to the
StartUp component in your design. Otherwise just change it back to CCLK!
"Sebastien Favard (Gordh)" wrote:
>
> > You should post your bitgen.ut file, then it would be easier for us to
> > help you. Even if you use the GUI, there is a bitget.ut file created.
> >
>
> I don't known the ucf format :( I use Leonardo Spectrum on Unix to create a
> edif or xnf... netlist. After I use Alliance on UNIX to translate the netlist
> in ncf format and eventually generate a bitstream.
> How format can I post ? Or perhaps the VHDL design ? It's just a VERY small
> design to test the configuration process on the FPGA so...
>
> > The point is, if you use the user clock as your startup clock, ...
> > -g StartUpClk:USERCLK
> > -g DoneActive:U2
> > -g OutputsActive:U3
> > -g GSRInactive:U4
> >
> > .. then you must instantiate a STARTUP component and connect its CLK
> > input to some external clock source.
>
> Incredible> Why I must instantiate a StartUp component on my design VHDL ? I
> think really that you have right but it's not really logical. In fact, the
> design FPGA represents only (for me !) the description of comportment
> AFTER the configuration process. So why I must specify the configuration
> process "component" in the design ?
>
> Very strange technique, no ? So, here my VHDL "design"... Perhaps I have not
> understand the objectif of the StartUp Component...
>
> LIBRARY IEEE;
> USE IEEE.STD_LOGIC_1164.ALL;
> LIBRARY exemplar;
> USE exemplar.exemplar_1164.ALL;
>
> ENTITY FPGA IS
> PORT (
> Clock_i : IN STD_LOGIC;
> Reset_ib : IN STD_LOGIC;
> CCLK_i : IN STD_LOGIC;
>
> CS_ib : IN STD_LOGIC;
> RdWr_i : IN STD_LOGIC;
> Data_io : INOUT STD_LOGIC_VECTOR(7 downto 0)
>
> );
>
> -- Pin Location --
> ------------------
>
> ATTRIBUTE PIN_NUMBER : STRING;
> ATTRIBUTE PIN_NUMBER OF Clock_i : SIGNAL IS "P35";
> ATTRIBUTE PIN_NUMBER OF CCLK_i : SIGNAL IS "P73";
>
> ATTRIBUTE PIN_NUMBER OF Reset_ib : SIGNAL IS "P84";
>
> ATTRIBUTE PIN_NUMBER OF CS_ib : SIGNAL IS "P13";
> ATTRIBUTE PIN_NUMBER OF RdWr_i : SIGNAL IS "P47";
> ATTRIBUTE ARRAY_PIN_NUMBER OF Data_io : SIGNAL IS
> ("P56","P58","P59","P61","P65","P67","P69","P71");
>
> -- Global CLK --
> ----------------
>
> ATTRIBUTE BUFFER_SIG OF Clock_i : SIGNAL IS "BUFG";
> ATTRIBUTE BUFFER_SIG OF CS_ib : SIGNAL IS "BUFG";
>
> -- CLOCK definition --
> ----------------------
> ATTRIBUTE CLOCK_CYCLE OF Clock_i : SIGNAL IS 83ns; -- 12 MHz (8 MHz =>
> 125ns)
> --ATTRIBUTE CLOCK_OFFSET OF Clock_i : SIGNAL IS ns;
> --ATTRIBUTE PULSE_WIDTH OF Clock_i : SIGNAL IS ns;
> --ATTRIBUTE ARRIVAL_TIME OF Clock_i : SIGNAL IS ns;
>
> END FPGA;
>
> ARCHITECTURE XC5200 OF FPGA IS
> SIGNAL Dummy1,Dummy2,Dummy3,Dummy4 : STD_LOGIC;
>
> SIGNAL Reset : STD_LOGIC;
>
> SIGNAL RegTmp: STD_LOGIC;
>
> COMPONENT STARTBUF
> PORT (GSRin, GTSin, CLKin : IN STD_LOGIC;
> GSRout, GTSout, DONEinout, Q1Q4out, Q2out, Q3out : OUT STD_LOGIC);
> END COMPONENT;
>
> BEGIN
>
> StartComponent:STARTBUF port map (GSRin => Reset_ib,
> GTSin => '0',
> CLKin => CCLK_i,
> GSRout => Reset,
> DONEinout => Dummy4,
> Q1Q4out => Dummy1,
> Q2out => Dummy2,
> Q3out => Dummy3);
>
> PROCESS (Clock_i)
> BEGIN
> IF Rising_Edge(Clock_i) THEN
> IF (CS_ib = '0') THEN
> IF (Reset = '0') THEN
> RegTmp <= '0';
> ELSE
> IF (RdWr_i = '1') THEN
> Data_io <= "0101010" & RegTmp;
> ELSE
> Data_io <= (others => 'Z');
> END IF;
> END IF;
> END IF;
> END IF;
> END PROCESS;
>
> END XC5200;
>
> Thanks,
>
> Sebastien
--
Rick Collins
rick.collins@XYarius.com
remove the XY to email me.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design
Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
Internet URL http://www.arius.com
Article: 22347Michael, I have had a look at the Glossary and have the following comments:- 1. You list Binary Semaphore and the even less known term mutex yet omit the simplest term which is a flag or flag bit. 2. Emulator may not necessarily refer to an In Circuit Emulator, as stated. There are other types of emulator used in this field. Emulators are not necessarily processor substitutes either. Remember, not all embedded systems necessarily use a microprocessor. ASIC's, FPGA's, etc all come under the embedded umbrella. 3. Although apparently out of vogue, though used more than ever, Fuzzy logic, and fifo seem to be a major omissions. 4. Interrupt priority is a common subject on the NG. 5. Pipeline is a common feature Just my opinion. Al Michael Barr wrote: > > This is a periodic posting to let readers of these newsgroups know > about several online resources that may be relevant: > > [1] Embedded Systems Glossary > > http://www.netrino.com/Publications/Glossary/ > > [2] Embedded Systems Bibliography > > http://www.netrino.com/Publications/Bibliography/ > > These are online versions of the Glossary and Bibliography from my > book, "Programming Embedded Systems in C and C++" (O'Reilly and > Associates, ISBN 1-56592-354-5). > > It is my intention to make occasional changes and updates to these > online versions. I would very much like to hear your constructive > feedback. Please send your suggestions to <webmaster@netrino.com>. > > I have put a lot of work into writing the book and creating and > maintaining these online resources. I hope that they will be a > valuable contribution to the community of embedded systems hard- > ware and software designers. > > Sincerely, > Michael BarrArticle: 22348
Rickman wrote: > davidk@free-ip.com wrote: > > Using a cryptographically strong LFSR, there is no reasonable way to break > > the LFSR by analyzing the random bit stream. This might take more than 64 > > macrocells and more than 20 slices/CLB's. Some might debate this, but it's a > > moot point because... > > Can you define, or better yet give an example of a "cryptographically > strong LFSR"? I do believe it when people have stated that if you know > the structure of a LFSR of length N, it will only take N samples to > determin the initial state. I will also submit to the statement that if > the structure is not known, then it may be possible to determin the > initial state as well as the taps with 2N samples, although I am not > certain you can do this without trying all possiblities which would be > way too expensive for any but the most well funded efforts. But it > certainly makes sense that a LFSR is not truly robust against an > analysis. > > So how do you design a LFSR that can not be easily analyzed? I posted a message describing some better LFSRs, but in my news server mess (I switched ISP's, and had to use Deja between) I think it got lost... The book "Applied Crypto, 2nd edition" by Bruce Schneier shows several PRBS generators based on LFSR's that are much better. The book also nicely describes several that are not at all secure. One type that is reasonably secure is called a "Bilateral Stop-and-Go Generator". This generator uses two LFSRs of the same length. The output is the XOR of each LFSR outputs. If the output of LFSR #1 at T-1 is 0 and the output at time T-2 is 1 then LFSR #2 does not clock at time T. Conversely, if the output of LFSR #2 at time T-1 is 0 and 1 at T-2 then LFSR #1 doesn't clock at time T. This is just one example, the book describes several that would be suitable. > > Ray Andraka <ray@fpga-guru.com> wrote: > > > There is Jbits for 4K/spartan too. > > > > Damn! So we can basically write off this method, and just about any other > > method, that uses current Xilinx chips. (Hey, you killed Kenny! You > > bastard!) > > > > While this method is still applicable to Altera and other FPGA's, there are > > other problems... > > This is a case of ignorance being bliss. I am not aware that Jbits > allows you to reverse engineer a Xilinx bitstream. Is this true or is it > just that Jbits makes it easier to reverse engineer the Xilinx parts in > general and you would still have a major effort in doing so? Check out the Xilinx web site and search for JBits. While I wouldn't call it easy to use, it does allow someone to analyze and FPGA and essentially extract a netlist that LUT contents. After that, the rest is just an excersize for the reader... :( > If you have > to use Jbits to twiddle a bit then you load it into an FPGA and see what > you just changed, then I don't consider this to be an easy way to > reverse engineer a Xilinx configuration bitstream. With Jbits you can do rather high level things in a very predictable way. It isn't just flipping bits and seeing what happens. You can reroute traces, change LUT's, etc. without having to resort to trial and error. > > Here's what I currently think the LFSR method is good for: > > > > A simple encryption quality LFSR when implemented in a CPLD > > and Non-Xilinx SRAM based FPGA is sufficent to deter most > > casual pirates. But any professional pirate willing to devote some > > time and money at it will probably be able to break this method in > > a reasonable time frame using one of the previously mentioned > > approaches. In short, I conceed defeat on this one. > > > > Unfortunately, what this shows is that more sophisticated > > encryption would not increase the security given the existance > > of JBits for all Xilinx parts of interest and given the vulnerability > > of Flash based CPLD's (and probably uC's as well). > > > > Oh well. It was a nice try... :( > > Others have indicated that the LFSR is less robust and I feel that the > Xilinx design and the CPLD (or micro in my case) are more robust than my > requirements. So depending on just how hard it is to attack the LFSR > initial state, we may need a more robust algorithm. But a more robust algorithm isn't going to help as long as we can reverse engineer CPLD's and Jbits exists. > > And another thing... Someone mentioned using a free-running > > oscilator (made from an inverter fed back into itself) as a source > > for random numbers. Unfortunately this doesn't work. It works > > in the simulators, but not in real devices. If you put two of these > > oscilators on the same FPGA (and nothing else) they tend to > > lock to eachother and will eventually will be in sync and remain > > in sync. With just one of these oscilators on a full FPGA, the > > osc will tend to lock to some other source of noise in the system > > which will make the random numbers highly correlated to what's > > going on in the FPGA-- not random at all. > > I am not convinced that this is really a problem. If the two oscillators > lock to some ratio on a given board, that will not say that they will > allways lock at that ratio on every board. The random numbers only have > to produce a pattern of numbers that is not repeatable on powerup. Even > if the two oscillators are locked, that will not guarantee that they > will produce the same result every time like a computer program would. > Remember that the non-crystal oscillator will be voltage, temperature > and process dependant as well. The point is that the oscillators will tend to lock to other things happening in the FPGA. The original posted suggested that a single inverting feedback oscillator be used in conjunction with a more stable crystal oscillator. The crystal clock is ran to the clock input on a flip flop and the D input is fed from this inverting feedback clock. In the most simplistic sense, this oscillator will tend to lock to a harmonic of the crystal clock-- causing the flip flop to capture more 0's (or 1's) than the other. This is hardly random and would reduce the effective "key size" (since we would know that 80% of the key bits are 0). How reproducible the results are is really something that only experimentation can provide. It wouldn't surprise me at all if it was very repeatable given the same temp and voltage. I'm fairly sure that if you let the board warm up then reset it 10 times in a row you would probably get at least 2 or 3 "random number matches". > I would be willing to bet that a form of stimulus, response approach > would be the most resistant to attack. Not as long as Jbits is around. That alone would kill it. This type of attack is independent of the algorithm used. Just find the signal that disables some important internal state machine and force that signal inactive. Since you can read the netlist from the FPGA this is a relatively simple thing to do. Then there is the question of being able to "disable" the security bit in Flash CPLD's and uC's. I think that this is difficult, but possible. Given the above two attacks, a reasonably design LFSR is just as secure as a stimulus/response type of algorithm and a lot easier and smaller to implement. I'm not saying that an LFSR approach is totally secure, just that it is no less secure than a stimulus/response method given these likely methods of attack. David Kessner davidk@free-ip.comArticle: 22349
Hi all, I have been using a board with Xilinx xc40150xv devices, and would like to evaluate the possibility of porting my design to a virtex board with xcv300 device. The problem is my design needs to use some logiblox and coregen symbols such as multiplier, square root, and accumulator etc. Is this possible? Regards, LC
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z