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
Hi Jamil,
[...]
> Is it an important warining that I should take care of,
> or is it going to vanish on the real hardware (CPLD)
[...]
Maybe you can ignore it, but you should know, what you are going to
ignore :-)
Vital supports four modes of signal sheduling:
- VitalInertial -> same as VHDL Inertial delay (NO GLITCH MODE)
- VitalTransport -> same as VHDL Transport delay (NO GLITCH MODE)
- OnEvent -> special Mode for Glitch Handling
- OnDetect -> special Mode for Glitch Handling
The Modes for glitch handling are producing a glitch warning message
AND 'X' values (when an how long depends on the Sheduling Mode which
is used).
-> take a look into section 7 of the LRM for more details.
->>>>> http://www.vhdl.org/vi/vital/Dev/doc/lrm.tar.gz
The warning messages are normal :-). If these glitches are detected
internally (between two FF), then you can ignore them (in case
of a real problem at this point, the FF after the glitch producing
logic gets an 'X' with the next cycle and your system will not
work anymore).
If you have logic AFTER a FF which CAN produce glitches to the
chip boundaries you maybe have to take care about and not ignore
these messages :-) -> maybe you can write an 'X' detection around
your Chip IOs (Testbench). Then you will detect these problems,
even you switch off the 'Vital glitch Message Mode' in the simulator.
With QuickHDL/ModelSim you can switch off these warnings by the
'+no_glitch_msg' option.
Good Luck
--
Oliver
e-mail: Oliver.W@gmx.ch
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 22301In article <39118F77.B79F009@free-ip.com>, David Kessner <davidk@free-ip.com> 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 (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). 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. 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". -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 22302
RF SYSTEM DESIGN ENGINEER
Newport Beach, Ca
Conexant Systems, Inc. is a top-ten North American semiconductor
supplier, and the world's largest independent company focused
exclusively on providing semiconductor system solutions for
communications electronics. With revenues of approximately $1.5 billion,
Conexant has aligned its business to target the fastest-growing markets
of the worldwide communications marketplace. We have an exceptional
opportunity for a RF Systems Engineer at our Newport Beach, CA
headquarters.
We have exceptional opportunities for RF Systems Engineers to provide
support in
specification, design, and simulation of complex
digital cellular and cordless
communication systems. You will perform trade-off
studies to provide specification
subsystems.
Requires BSEE or equivalent and 3 years hands-on experience. Experience
with receivers, transmitters, or synthesizer. Also, experience with
mixers, LNA's, and PA's. Must be able to apply system work toward
implementation of RF ASIC devices. Strong background in communication
theory and knowledge of system simulation using state-of-the-art CAD
tools helpful. System development or hardware design in one of the
following areas a plus: GSM, CDMA, TDMA, cordless or GPS platforms.
Multiple openings from junior to very senior.
We offer highly competitive salaries and a comprehensive benefits
package including stock options. Please call (949)483-9349 or email
resumes to: george.davis@conexant.com. Website: www.conexant.com.
We are an equal opportunity employer supporting diversity in the
workplace.
--
George Davis
Conexant Systems, Inc.
949-483-9349
george.davis@conexant.com
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 22303"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. 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). Until FPGA's have crypto hardware built in then this type of attack will always exist for all copy protection schemes. > 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.comArticle: 22304
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 I read your app note and I think it covers all of the bases. I realize that the Dallas serial number chips do not provide the kind of security that is really needed if someone is willing to copy the hardware and change the Dallas chip to a CPLD or a micro. But I would like to point out (again) that I think a small micro would be a better candidate than a CPLD as the security device. From some of the pointers that showed up in this thread, I have found some 8 bit micros that come in 8 pin packages and will do the job quite nicely. A CPLD will be at least 16 pins (I don't even know if they come that small, likely they are 20 pins or more) and may well cost more than a micro. There is one thing that is not clear to me. I would expect the securtity device to be set to a known starting state which is picked randomly by the FPGA. Then the resulting bitstream is tested to verify operation. This has some problems which I won't go into. But your method seems not 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. This also means that the protection could be attacked by copying the bitstream if the device is not one that needs to be kept running uninterrupted for very long periods of time. If the product being protected can be reset periodically then only the first M bits of the bitstream would need to be copied. For example, if it is reset once a day and clocked at 1 MHz, you would need to record 10**6 * 3600 * 24 bits or about 10**11 bits. This is about the same as the example LFSR length or 2**36 bits which is 2**33 bytes or 8 GB. So this is still the upper bound. 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. Anyone else have a comment? -- 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: 22305
PRODUCT APPLICATIONS ENGINEER Newport Beach California Conexant Systems, Inc., formerly Rockwell Semiconductor Systems, is the world's largest semiconductor company totally dedicated to communications technologies. We are a driving force in 60% of all Internet connections, 70% of the world's fax machines, and 80% of CDMA cell phones. For decades, our mixed signal computing solutions have been inside faxes, computer modems, cellular and cordless phones, PC multimedia peripherals, digital infotainment appliances and network access equipment. We currently have exceptional opportunities for Product Application Engineers in our Wireless Communications Division at our Newport Beach headquarters. Engineer will be liaison between customers, field personnel and design team to accelerate customer design-in of wireless communications products for cordless and cellular phones; create and present seminars; write application notes, articles and other technical marketing documents. Positions available in the following areas of technical expertise: RF circuits for GSM handsets; Real-time embedded software in C for GSM handsets and GPS products; and real-time embedded software in Assembly for DSS products. Requires engineering; strong background in RF circuit or MMI software design; strong technical communication, presentation and customer interface skills; wireless systems analysis and problem solving; use of standard lab equipment. Domestic and international travel required. We offer highly competitive salaries and a comprehensive benefits package including stock options. Please call (949)483-9349 or email resumes to: george.davis@conexant.com. Website: www.conexant.com. We are an equal opportunity employer supporting diversity in the workplace. -- George Davis Conexant Systems, Inc. 949-483-9349 george.davis@conexant.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 22306
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: 22307
Rickman wrote: > David Kessner wrote: > > 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 read your app note and I think it covers all of the bases. I realize > that the Dallas serial number chips do not provide the kind of security > that is really needed if someone is willing to copy the hardware and > change the Dallas chip to a CPLD or a micro. > > But I would like to point out (again) that I think a small micro would > be a better candidate than a CPLD as the security device. From some of > the pointers that showed up in this thread, I have found some 8 bit > micros that come in 8 pin packages and will do the job quite nicely. A > CPLD will be at least 16 pins (I don't even know if they come that > small, likely they are 20 pins or more) and may well cost more than a > micro. In the case of my app note, a uC would not be a good choice. The reason for this is that the PRBS is clocked into the FPGA using the main system clock. For a uC to do that, a slower clock would need to be used. The nice thing about using the system clock is that it isn't something that can be easily tampered with. You absolutely wouldn't want to use a dedicated PRBS clock because a would-be pirate could just tie it low and disable the whole thing. As long as you resolved this clock issue then there is nothing wrong with using a uC rather than a CPLD. I can think of some solutions to the clock issue, but you have to be careful that you don't increase the size of the logic in the FPGA. If you do that then the total cost needs to be adjusted. There are some 36 macrocell CPLD's for under US$2 in 100's, and approaching $1 in larger lots. This is similar to many uC's that I know of. > There is one thing that is not clear to me. I would expect the securtity > device to be set to a known starting state which is picked randomly by > the FPGA. Then the resulting bitstream is tested to verify operation. > This has some problems which I won't go into. But your method seems not > 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, the bitstream runs continuously. And, yes, this will cause some power consumption. You might be able to use a low power CPLD with a slower clock-- but this would add cost. Everything is a tradeoff. The bitstream must run continuously because it is the same every time. That is, the first 100+ bits are always the same every time the system is reset. If the bitstream was not continuous then there would be only a relatively small number of bits to capture and copy. Since it does run continuously there are so many bits to copy that this type of attack is not practical. An alternative (mentioned by others) is more of a query/response system where the FPGA queries the CPLD/uC with some random data and checks for a proper response. This would be as secure (but not more secure) than my approach, but the amount of logic required would be much more than the 10 slices needed in a Spartan-2. > This also means that the protection could be attacked by copying the > bitstream if the device is not one that needs to be kept running > uninterrupted for very long periods of time. If the product being > protected can be reset periodically then only the first M bits of the > bitstream would need to be copied. For example, if it is reset once a > day and clocked at 1 MHz, you would need to record 10**6 * 3600 * 24 > bits or about 10**11 bits. This is about the same as the example LFSR > length or 2**36 bits which is 2**33 bytes or 8 GB. So this is still the > upper bound. > > 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. > > Anyone else have a comment? I didn't think of a frequent reset attack. It is something to consider. While many devices wouldn't work properly with frequent resets, I'm sure that there are devices out there that would be just fine with that. For low power applications where frequent resets are "doable" then one solution would be to use a low power CPLD (Xilinx/Phillips Coolrunner) and a faster clock. If this isn't low power enough then this approach wouldn't work. Of the top of my head, I don't know how low power the Coolrunner is in this type of application. David Kessner davidk@free-ip.comArticle: 22308
DESIGN ENGINEER/ASIC/MIXED SIGNAL Newport Beach, CA Conexant has an immediate need for Analog/Mixed Signal Design Engineers at our Newport Beach Corporate Headquarters. This engineer will be part of the Wireless ASIC team developing highly integrated systems on a chip solutions for wireless communications applications. Responsible for the design of embedded mixed signal components in these devices from initial specification developed in conjunction with systems and hardware groups through design verification, integration, and test. As not all mixed signal blocks will be designed internally, working with external design teams is a must and good communications skills are essential. Required skills: 5 + years experience a minimum. Experience with Mixed Signal Block Specification Development and Analog design(ADC/DAC/PLL/OSC/low-power). Experience with Analog Block Level Layout , Analog BIST support, and Analog Modeling. We offer highly competitive salaries and a comprehensive benefits package including stock options. Please call (949)483-9349 or email resumes to: george.davis@conexant.com. Website: www.conexant.com. We are an equal opportunity employer supporting diversity in the workplace. -- George Davis Conexant Systems, Inc. 949-483-9349 george.davis@conexant.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 22309
In article <3911C031.D9CD4F0F@free-ip.com>, David Kessner <davidk@free-ip.com> wrote: >In the case of my app note, a uC would not be a good choice. The >reason for this is that the PRBS is clocked into the FPGA using >the main system clock. For a uC to do that, a slower clock would >need to be used. The nice thing about using the system clock is >that it isn't something that can be easily tampered with. You >absolutely wouldn't want to use a dedicated PRBS clock because a >would-be pirate could just tie it low and disable the whole thing. > >As long as you resolved this clock issue then there is nothing wrong >with using a uC rather than a CPLD. You have the FPGA derive the uC's clock. Thus, you don't have to worry about a separate clock being attacked, and you can suspend and slow down the uC after a given period of time. This adds VERY little cost, as a clock divider by 2^N only requires N luts. This also allows stopping/suspending and resuming the checking circuit. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 22310
"Nicholas C. Weaver" wrote: > >As long as you resolved this clock issue then there is nothing wrong > >with using a uC rather than a CPLD. > > You have the FPGA derive the uC's clock. Thus, you don't have > to worry about a separate clock being attacked, and you can suspend > and slow down the uC after a given period of time. This adds VERY > little cost, as a clock divider by 2^N only requires N luts. > > This also allows stopping/suspending and resuming the checking circuit. Nice solution! David Kessner davidk@free-ip.comArticle: 22311
Hi, INIT must be low for JTAG configuration. Catalin e97bjli@thn.htu.se wrote: > Hi. > > I have a problem with my FPGA device (Spartan XCS10 PC84) > > When I download my program to the device via JTAG (Parallel cable III), > The programming tool write "programming successfully". > > But when I connect my oscilloscop to the pins of the device, all pins > except ground are high ( '1' ). > > I dont know what to do. > > ALL Vcc are connected to ground via 0.1 uF capacitor. > > INIT is connected to Vcc via 4700 ohm resistor. > > ...Article: 22312
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). evanArticle: 22313
One final note, an LFSR is a VERY bad choice for E. According to David Wagner, finding the initial state of an N bit LFSR only takes a sequence of N bits if you know the taps, N^2 if you don't. Which means using a CPLD would probably not work out well, instead an at least slightly more robust encryption implemented in a uC. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 22314
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.comArticle: 22315
"Sebastien Favard (Gordh)" <Sebastien.Favard@utc.fr> writes: > Hi, > > When I use the BitGen program with argument StartupClk (on > XC4000/Spartan) or the similar OscClk (on XC5200) an error appeared: > > "ERROR:x4kbs:35 - There must be a STARTUP component with a signal on the > CLK pin > when StartupClk is UserClk." > > Why I have this error when I must create a bitstream for a slave serial > mode ? > 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. 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. Otherwise you have to do, for example, this: -g StartUpClk:CCLK -g DoneActive:C1 -g OutputsActive:C2 -g GSRInactive:C3 You have to search the dialogs for the appropriate checkboxes, if you use the GUI. chm. -- cmautner@ - Christian Mautner utanet.at - Vienna/Austria/EuropeArticle: 22316
In article <3910C989.39F4F092@ids.net>, Ray Andraka <randraka@ids.net> writes >Heavy Sigh! This subject comes up about once every 6-9 months. Has anyone used the Clear Logic parts ? Prototype using altera 10K parts and then ask Clear Logic to produce some clones for you from your bitstream. Goodbye external configuration stream, goodbye 99 % of the security issue. Also goodbye in-field reprogramability, but you cannot have everything. I have not had any contact with Clear Logic, I've just read the press releases. -- Steve DeweyArticle: 22317
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/EuropeArticle: 22318
"Nicholas C. Weaver" wrote: > > One final note, an LFSR is a VERY bad choice for E. According > to David Wagner, finding the initial state of an N bit LFSR only takes > a sequence of N bits if you know the taps, N^2 if you don't. > > Which means using a CPLD would probably not work out well, > instead an at least slightly more robust encryption implemented in a > uC. > -- > Nicholas C. Weaver nweaver@cs.berkeley.edu How many bits does it take if you don't know the value of N? I would guess that it takes the full 2^(N-1), but I don't know for sure. I am surprized that it only takes N^2 bits to determine the intial state and tap arrangement of a LFSR. I know that not all possible combinations of taps produce a non-repeating pattern of maximal length, but if you have N bits in your LFSR, you should have up to 2^(N-1) possible LFSR tap combinations. I am surprized that even if you know N, you would only need N^2 bits to distinguish between 2^(N-1) combinations. I assume that if you use logic other than XOR functions in the feedback loop, then it is not a LFSR by definition? -- 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: 22319
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: 22320
In article <3911EC2C.5CFAD988@yahoo.com>, Rickman <spamgoeshere4@yahoo.com> wrote: >"Nicholas C. Weaver" wrote: > >How many bits does it take if you don't know the value of N? I would >guess that it takes the full 2^(N-1), but I don't know for sure. Probably not, you would have to ask a cryptographer to be sure, but you could probably take a sample, apply the algorithm for LFSR size 1-k, and see which ones give you results which match for a longer string. >I am surprized that it only takes N^2 bits to determine the intial state >and tap arrangement of a LFSR. I know that not all possible combinations >of taps produce a non-repeating pattern of maximal length, but if you >have N bits in your LFSR, you should have up to 2^(N-1) possible LFSR >tap combinations. I am surprized that even if you know N, you would only >need N^2 bits to distinguish between 2^(N-1) combinations. > >I assume that if you use logic other than XOR functions in the feedback >loop, then it is not a LFSR by definition? Probably, but it may be equally weak. You really should be willing to spend more area and do something known to be robust, such as DES for K < 54, or AES for a keysize of 128-192-256 -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 22321
"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. Doesn't Xilinx have a temperature sensor in their FPGA's? Could either it, or some version of the various simulated A/D circuits be used to get a real random number. > >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: 22322
"Nicholas C. Weaver" wrote: > > In article <3911EC2C.5CFAD988@yahoo.com>, > Rickman <spamgoeshere4@yahoo.com> wrote: > >"Nicholas C. Weaver" wrote: > > > >How many bits does it take if you don't know the value of N? I would > >guess that it takes the full 2^(N-1), but I don't know for sure. > > Probably not, you would have to ask a cryptographer to be > sure, but you could probably take a sample, apply the algorithm for > LFSR size 1-k, and see which ones give you results which match for a > longer string. > > >I am surprized that it only takes N^2 bits to determine the intial state > >and tap arrangement of a LFSR. I know that not all possible combinations > >of taps produce a non-repeating pattern of maximal length, but if you > >have N bits in your LFSR, you should have up to 2^(N-1) possible LFSR > >tap combinations. I am surprized that even if you know N, you would only > >need N^2 bits to distinguish between 2^(N-1) combinations. > > > >I assume that if you use logic other than XOR functions in the feedback > >loop, then it is not a LFSR by definition? > > Probably, but it may be equally weak. You really should be > willing to spend more area and do something known to be robust, such > as DES for K < 54, or AES for a keysize of 128-192-256 > > -- > Nicholas C. Weaver nweaver@cs.berkeley.edu That sounds nice in theory, but that would be bigger than some of the FPGAs that I use. This type of protection does not need to be of cryptographic quality. It only needs to be "good enough" so that it will withstand an economical attack. If it takes more than a week of time, it is likely to deter all but the most determined. I doubt that many designers even have the skills to decrypt a LFSR. If the length is increased to say 48 bits, then I would bet that it would be enough of a deterrence to ward off most companies. But surely there must be some FSM that would not be so easily decoded and yet would be straight forward to construct. There are 2^(2^N) possible functions of N inputs. This number gets incredibly large very quickly. There may be a definable subset at least as large as 2^N which can not be decoded in N^2 samples and yet can be constructed with a small number of gates. Anyone know of any? -- 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: 22323
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! :)
--
("`-''-/").___..--''"`-._ UNIX *is* user-friendly, he is just very
`6_ 6 ) `-. ( ).`-.__.`) picky about who his friends are...
(_Y_.)' ._ ) `._ `. ``-..-' Paul Bunyk, Research Scientist
_..`--'_..-_/ /--'_.' ,'art by (and part-time UN*X sysadm)
(il),-'' (li),' ((!.-' F. Lee http://pbunyk.physics.sunysb.edu/~paul
Article: 22324a@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. 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... 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.nz
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