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
On Aug 4, 11:59=A0am, untergangsprophet <filter...@desinformation.de> wrote: > > Is it possible that even though I use AES encrypted bitstream, another > > trojan/bad bitstream that mimiked my design could be loaded into FPGA? > > If your design can be mimiked AES encryption seems not necessary. I don't understand this statement. Every one have access to Xilinx/ Altera tools. Everyone use USB, PCIe, RS232 type interfaces that are standard. I have guts of FPGA that are special but many inteface are generic. This make it easier for attacker to mimik the operation of my FPGA perhaps enough to monitor busses in my design. If USB link in my product then easy for attacker to put USB design in my FPGA that mimik the interface (like phishing website) and user of product enters password or similar. whole design not need mimiked.Article: 142326
On Aug 4, 1:54=A0pm, austin <aus...@xilinx.com> wrote: > Raj, > > With Xilinx FPGA encryption, decryption solutions since Virtex 2, only > one bitstream is allowed to be entered in secure mode. > > That bistream's key must be the one in the battery backed key memory, > or the device will not program. > > Some parts allow subsequent partial reconfiguration, again they must > use the same key (encrypted), so the attacker would have to know your > key in order to do this. =A0If they know your key, well, you are not > secure, are you? > > At any time, you may program the device again with another bitstream, > but that erases the previous (decrypted) bitstream. > > While programmed with a encrypted bitstream, JTAG readback is > disabled, so you can not read the device out. > > But, if you place logic in your encrypted design to perform the > internal configuration readback, and readback and output the values on > a pin (for example), then you have now created your own "back - door." > > We do not protect against doing something this stupid, but we do > protect the bitstream from all other attacks if you follow a few > simple rules (like: =A0do not build a back door into your design). > > SInce Virtex 2, we have issued challenges to university students and > researchers to test our security. =A0In addition to being the only > approved FPGA =A0by the NSA for the crypto-modernization program, we > have had no method of attack succeed to date, Thank you experts. Yes good for protection from decrypt my design. but that is just for big FPGAs. I maybe getting Xilinx and Altera confused. Altera non-volatile key based Stratix accepts unencrypted bit data, I thought Xilinx too. Xilinx has a non-volatile key now? I went to HOST last week and a presenter said that it could be done. My CM load bit data for manufacturing tests so logistics are tricky. prototypes i program key in myself in lab with vendor tools no problem. large volume it is difficult to coordinate with multiple sites the key. CM run tests send back product to me - key programmed in and then ship back product to CM to run functional test with bits loaded. Very costly. RajArticle: 142327
On Aug 4, 2:49=A0pm, Rajesh Gandhi <rgandhi4...@gmail.com> wrote: > On Aug 4, 2:19=A0pm, "a...@nishioka.com" <a...@nishioka.com> wrote: > > > On Aug 4, 10:54=A0am, austin <aus...@xilinx.com> wrote: > > > > With Xilinx FPGA encryption, decryption solutions since Virtex 2, onl= y > > > one bitstream is allowed to be entered in secure mode. > > > > That bistream's key must be the one in the battery backed key memory, > > > or the device will not program. > > > so if you remove the battery, can you program anything you want into > > the fpga? > > (this is what i thought the op was asking) > > Yes, it is related to what i ask. this is one method removing the > battery, if that is not possible, shorting the battery terminals until > it is drained. I was under the impression that you could always load an unencrypted bitstream, battery or no. The point is that encryption protects your bitstream from attempts to copy it. It doesn't prevent the hardware from being used for something else.Article: 142328
On Aug 4, 3:13=A0pm, gabor <ga...@alacron.com> wrote: > On Aug 4, 2:49=A0pm, Rajesh Gandhi <rgandhi4...@gmail.com> wrote: > > > > > > > On Aug 4, 2:19=A0pm, "a...@nishioka.com" <a...@nishioka.com> wrote: > > > > On Aug 4, 10:54=A0am, austin <aus...@xilinx.com> wrote: > > > > > With Xilinx FPGA encryption, decryption solutions since Virtex 2, o= nly > > > > one bitstream is allowed to be entered in secure mode. > > > > > That bistream's key must be the one in the battery backed key memor= y, > > > > or the device will not program. > > > > so if you remove the battery, can you program anything you want into > > > the fpga? > > > (this is what i thought the op was asking) > > > Yes, it is related to what i ask. this is one method removing the > > battery, if that is not possible, shorting the battery terminals until > > it is drained. > > I was under the impression that you could always load an unencrypted > bitstream, battery or no. =A0The point is that encryption protects your > bitstream from attempts to copy it. =A0It doesn't prevent the hardware > from being used for something else.- Hide quoted text - > > - Show quoted text - Thank you for that. I got motivated to look more and V5 FPGA guide page 36. *********************************** Once the device has been programmed with the correct encryption key, the device can be configured with an encrypted bitstream. After configuration with an encrypted bitstream, it is not possible to read the configuration memory through JTAG or SelectMAP readback, regardless of the BitGen security setting. While the device holds an encryption key, ***** a non-encrypted bitstream can be used to configure the device; ******** in this case the key is ignored. After configuring with a nonencrypted bitstream, readback is possible (if allowed by the BitGen security setting). The encryption key still cannot be read out of the device, preventing the use of Trojan Horse bitstreams to defeat the Virtex-5 encryption scheme. ************************************** So you are correct Gabor and Mr. Austin from Xilinx is not, respectfully, exactkt correct (although he gives us good answers other times) It mention Trojan and it not possible to defeat encryption but easily possible for trojan design and JTAG to hack product, snoop other system parts V5 is connected to, erase Flash which create Denial of service, store alternate non-encrypted bit data in multi-boot. I was skeptical of presentation at HOST hardware security conference but I believe it makes more sense now.Article: 142329
> > If your design can be mimiked AES encryption seems not necessary. > I don't understand this statement. If someone can easily mimick the functionality of your FPGA why would they bother trying to de-crypt your bit-stream, they'd just re-write from scratch. NialArticle: 142330
On Aug 5, 11:23=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > > If your design can be mimiked AES encryption seems not necessary. > > I don't understand this statement. > > If someone can easily mimick the functionality of your FPGA why would > they bother trying to de-crypt your bit-stream, they'd just re-write > from scratch. > > Nial sometimes there is need to to protect the PCB and other design elements also so a possibility to download a unencrypted bit file into an FPGA with AES key set is somewhat design risc anttiArticle: 142331
On Wed, 5 Aug 2009 09:23:48 +0100, "Nial Stewart"
<nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote:
>> > If your design can be mimiked AES encryption seems not necessary.
>
>> I don't understand this statement.
>
>If someone can easily mimick the functionality of your FPGA why would
>they bother trying to de-crypt your bit-stream, they'd just re-write
>from scratch.
>
If they can mimic the functionality of the interfaces, they could learn a lot
about the system that connects to the FPGA.
Unless that system interrogates the FPGA appropriately ("encrypt this message
with the private part of your key pair") and refuses to do anything interesting
if it gets the wrong answer.
- Brian
Article: 142332Rajesh Gandhi <rgandhi4086@gmail.com> wrote: >So you are correct Gabor and Mr. Austin from Xilinx is not, >respectfully, exactkt correct (although he gives us good answers other >times) It mention Trojan and it not possible to defeat encryption >but easily possible for trojan design and JTAG to hack product, snoop >other system parts V5 is connected to, erase Flash which create Denial >of service, store alternate non-encrypted bit data in multi-boot. >I was skeptical of presentation at HOST hardware security conference >but I believe it makes more sense now. That's what Mr. Austin said -- the bitstream is secure but the hardware can be used for other things. -- Dave FarranceArticle: 142333
sir i am doing project in segmented digital clock manager fpga based dpwm so i want vhdl code for dcm if u have any code please send it to me .Article: 142334
On Aug 5, 6:37=A0am, Dave Farrance <DaveFarra...@OMiTTHiSyahooANDTHiS.co.uk> wrote: > Rajesh Gandhi <rgandhi4...@gmail.com> wrote: > >So you are correct Gabor and Mr. Austin from Xilinx is not, > >respectfully, exactkt correct (although he gives us good answers other > >times) =A0 It mention Trojan and it not possible to defeat encryption > >but easily possible for trojan design and JTAG to hack product, snoop > >other system parts V5 is connected to, erase Flash which create Denial > >of service, store alternate non-encrypted bit data in multi-boot. > >I was skeptical of presentation at HOST hardware security =A0conference > >but I believe it makes more sense now. > > That's what Mr. Austin said -- the bitstream is secure but the hardware > can be used for other things. > Dear Mr.Dave, The part said by Mr. Austin was misinformation which adds to confusion. >With Xilinx FPGA encryption, decryption solutions since Virtex 2, only >one bitstream is allowed to be entered in secure mode. >That bistream's key must be the one in the battery backed key memory, >or the device will not program. The device will program when there is NO ENCRYPTION. Hence Trojan bitstream is easy to implement. Trojans do not need to decrypt the bitstream, attacker can program a bitstream into V5 or Stratix by programming on- board FLASH with JTAG. All are 'wide-open' for hacking. FPGA can be programmed which will assist in 1) getting passwords from users/admin/embedded 2) getting OTHER keys (not FPGA key) in system 3) snoop system to hack and potentially unlock unpaid-for features (turn low end product into high end product) 4) learn enough about system to build compatible plug-ins (games, software, songs, videos, printer cartridges) which may not be part of economic strategy. "cant prevent hardware from being used for other things" sounds like simple statement but many hardware products are sold at loss or break-even or very low margin in order to make market share. Printers for example. Company makes money on consumables or plug-ins to the platform. Xbox is example - which is really just Intel PC sold at loss to get market to sell games and internet service. Was Hacked to run linux which is embarassment for Microsoft but also a loss of $200 for each xbox purchased to run linux. Cisco low end router can be made into high end router with hack patch - loss of revenue for Cisco. Reader who say 'if simple to mimik then u don't need encryption, engineer will build from scratch' maybe missing the point. They are to build a bit data by scratch that is their intent, to have their design in place to do bad things. steal user password (not fpga key), monitor keyboard input, monitor USB connection, insert 'time bomb' to stop system functioning at critical time of need. if I have embedded powerpc based fpga it maybe quiet easy for attacker to get it to boot linux and have design which monitor keyboard input for admin logins and store or send over internet. The interfaces are all standard so easy to develop. And in end only virtex/stratix are secure, others are not. system security maybe not xilinx/altera problem, just mine, but i have to develop. Am I only one in FPGA area for this concern?Article: 142335
Hi, I have a design that will comprise of 11 FPGA boards: 10 slaves and 1 master and each board is having one cyclone III FPGA. The communication between master and slaves is via a simple SRAM protocol (with addr, data, WR/RD and CS). All boards will be interconnected together on a backplane board, with about 1 inch apart. According to the electrical specifications, the input leakage current of each pin is only 10uA. Therefore, in the case of LVTTL with 4mA drive strength, theoretically one master could drive up to 400 slaves? Is this too good to believe? Also, overshoot voltage could be a problem if signals are not terminated. Altera recommended 33R series resistor on each line. Does anyone have similar experience on this? I also would like to know what is the real benefit of using LVCMOS apart from LVTTL. Any recommendation is much appreciated.Article: 142336
On Aug 5, 8:57=A0am, Rajesh Gandhi <rgandhi4...@gmail.com> wrote: > On Aug 5, 6:37=A0am, Dave Farrance<DaveFarra...@OMiTTHiSyahooANDTHiS.co.u= k> wrote: > > Rajesh Gandhi <rgandhi4...@gmail.com> wrote: > > >So you are correct Gabor and Mr. Austin from Xilinx is not, > > >respectfully, exactkt correct (although he gives us good answers other > > >times) =A0 It mention Trojan and it not possible to defeat encryption > > >but easily possible for trojan design and JTAG to hack product, snoop > > >other system parts V5 is connected to, erase Flash which create Denial > > >of service, store alternate non-encrypted bit data in multi-boot. > > >I was skeptical of presentation at HOST hardware security =A0conferenc= e > > >but I believe it makes more sense now. > > > That's what Mr. Austin said -- the bitstream is secure but the hardware > > can be used for other things. > > Dear Mr.Dave, > The part said by Mr. Austin was misinformation which adds to > confusion. > > >With Xilinx FPGA encryption, decryption solutions since Virtex 2, only > >one bitstream is allowed to be entered in secure mode. > >That bistream's key must be the one in the battery backed key memory, > >or the device will not program. > I think Austin did not lie here, he said only one bitstream is allowed to be entered "in secure mode". There was no representation of the prevention of non-secured bitstreams. > The device will program when there is NO ENCRYPTION. =A0Hence Trojan > bitstream is easy to implement. =A0Trojans do not need to decrypt the > bitstream, > attacker can program a bitstream into V5 or Stratix by programming on- > board FLASH > with JTAG. =A0All are 'wide-open' for hacking. =A0FPGA can be programmed > which will assist in 1) > getting passwords from users/admin/embedded 2) getting OTHER keys (not > FPGA key) in system > 3) snoop system to hack and potentially unlock unpaid-for features > (turn low end product into high end product) > 4) learn enough about system to build compatible plug-ins (games, > software, songs, videos, printer cartridges) which > may not be part of economic strategy. > > "cant prevent hardware from being used for other things" sounds like > simple statement but many hardware products > are sold at loss or break-even or very low margin in order to make > market share. =A0Printers for example. Company > makes money on consumables or plug-ins to the platform. =A0Xbox is > example =A0- which is really just Intel PC sold at loss > to get market to sell games and internet service. =A0Was Hacked to run > linux which is embarassment for Microsoft > but also a loss of $200 for each xbox purchased to run linux. =A0Cisco > low end router can be made into high end router with hack patch - loss > of revenue for Cisco. > > Reader who say 'if simple to mimik then u don't need encryption, > engineer will build from scratch' maybe missing the point. They are to > build a bit data by scratch that is their intent, to have their design > in place to do bad things. steal user password (not fpga key), monitor > keyboard input, monitor USB connection, insert 'time bomb' to stop > system functioning at critical time of need. > if I have embedded powerpc based fpga it maybe quiet easy for attacker > to get it to boot linux and have design which monitor keyboard input > for admin logins and store or send over internet. =A0The interfaces are > all standard so easy to develop. > > And in end only virtex/stratix are secure, others are not. =A0system > security maybe not xilinx/altera problem, just mine, but i have to > develop. > Am I only one in FPGA area for this concern? Your requirements for security are different from many others who simply want their bitstream copy protected. If you have requirements to prevent your system from being used for other purposes, your best bet is to make sure the part you use cannot be re-programmed. I believe Actel has some good solutions for this. Also if your volume is adequate you could consider a part like the eASIC "structured ASIC" which straddles the fence between FPGA and ASIC. Altera also has their hard wired versions of FPGA's if you prefer to start with an SRAM FPGA and then move to a non-reprogrammable version. At the moment Xilinx has no similar products. Regards, GaborArticle: 142337
On Aug 5, 9:18=A0am, "snowball67" <wti...@singnet.com.sg> wrote: > Hi, > > I have a design that will comprise of 11 FPGA boards: 10 slaves and 1 > master and each board is having one cyclone III FPGA. The communication > between master and slaves is via a simple SRAM protocol (with addr, data, > WR/RD and CS). All boards will be interconnected together on a backplane > board, with about 1 inch apart. > > According to the electrical specifications, the input leakage current of > each pin is only 10uA. Therefore, in the case of LVTTL with 4mA drive > strength, theoretically one master could drive up to 400 slaves? Is this > too good to believe? Also, overshoot voltage could be a problem if signal= s > are not terminated. Altera recommended 33R series resistor on each line. > Does anyone have similar experience on this? > > I also would like to know what is the real benefit of using LVCMOS apart > from LVTTL. > > Any recommendation is much appreciated. Since the days of bipolar TTL logic, the DC loading has never been the limiting factor for fanout. With CMOS, your load is essentially a capacitor. 400 10pF loads becomes 4 nF. Think of the rise and fall times your LVTTL or LVCMOS signal can achieve under these conditions! Series termination is a bad idea when driving a backplane. And driving the clocks, or asynchronous command signals if there is no clock, requires incident wave switching. Unless you want to run your "simple" SRAM interface at a fairly low speed, I would suggest re-thinking your interconnect. Perhaps with the same number of wires, but arranged as point-to-point connections in a loop, you could run at many times the data rate while easily achieving good signal integrity. Just my 2 cents, GaborArticle: 142338
On Aug 5, 4:24=A0pm, gabor <ga...@alacron.com> wrote: > On Aug 5, 8:57=A0am, Rajesh Gandhi <rgandhi4...@gmail.com> wrote: > > > > > > > On Aug 5, 6:37=A0am, Dave Farrance<DaveFarra...@OMiTTHiSyahooANDTHiS.co= .uk> wrote: > > > Rajesh Gandhi <rgandhi4...@gmail.com> wrote: > > > >So you are correct Gabor and Mr. Austin from Xilinx is not, > > > >respectfully, exactkt correct (although he gives us good answers oth= er > > > >times) =A0 It mention Trojan and it not possible to defeat encryptio= n > > > >but easily possible for trojan design and JTAG to hack product, snoo= p > > > >other system parts V5 is connected to, erase Flash which create Deni= al > > > >of service, store alternate non-encrypted bit data in multi-boot. > > > >I was skeptical of presentation at HOST hardware security =A0confere= nce > > > >but I believe it makes more sense now. > > > > That's what Mr. Austin said -- the bitstream is secure but the hardwa= re > > > can be used for other things. > > > Dear Mr.Dave, > > The part said by Mr. Austin was misinformation which adds to > > confusion. > > > >With Xilinx FPGA encryption, decryption solutions since Virtex 2, only > > >one bitstream is allowed to be entered in secure mode. > > >That bistream's key must be the one in the battery backed key memory, > > >or the device will not program. > > I think Austin did not lie here, he said only one bitstream is allowed > to be entered "in secure mode". =A0There was no representation of > the prevention of non-secured bitstreams. > > > > > > > The device will program when there is NO ENCRYPTION. =A0Hence Trojan > > bitstream is easy to implement. =A0Trojans do not need to decrypt the > > bitstream, > > attacker can program a bitstream into V5 or Stratix by programming on- > > board FLASH > > with JTAG. =A0All are 'wide-open' for hacking. =A0FPGA can be programme= d > > which will assist in 1) > > getting passwords from users/admin/embedded 2) getting OTHER keys (not > > FPGA key) in system > > 3) snoop system to hack and potentially unlock unpaid-for features > > (turn low end product into high end product) > > 4) learn enough about system to build compatible plug-ins (games, > > software, songs, videos, printer cartridges) which > > may not be part of economic strategy. > > > "cant prevent hardware from being used for other things" sounds like > > simple statement but many hardware products > > are sold at loss or break-even or very low margin in order to make > > market share. =A0Printers for example. Company > > makes money on consumables or plug-ins to the platform. =A0Xbox is > > example =A0- which is really just Intel PC sold at loss > > to get market to sell games and internet service. =A0Was Hacked to run > > linux which is embarassment for Microsoft > > but also a loss of $200 for each xbox purchased to run linux. =A0Cisco > > low end router can be made into high end router with hack patch - loss > > of revenue for Cisco. > > > Reader who say 'if simple to mimik then u don't need encryption, > > engineer will build from scratch' maybe missing the point. They are to > > build a bit data by scratch that is their intent, to have their design > > in place to do bad things. steal user password (not fpga key), monitor > > keyboard input, monitor USB connection, insert 'time bomb' to stop > > system functioning at critical time of need. > > if I have embedded powerpc based fpga it maybe quiet easy for attacker > > to get it to boot linux and have design which monitor keyboard input > > for admin logins and store or send over internet. =A0The interfaces are > > all standard so easy to develop. > > > And in end only virtex/stratix are secure, others are not. =A0system > > security maybe not xilinx/altera problem, just mine, but i have to > > develop. > > Am I only one in FPGA area for this concern? > > Your requirements for security are different from many others > who simply want their bitstream copy protected. =A0If you have > requirements to prevent your system from being used for other > purposes, your best bet is to make sure the part you use cannot > be re-programmed. =A0I believe Actel has some good solutions for > this. =A0Also if your volume is adequate you could consider a > part like the eASIC "structured ASIC" which straddles the > fence between FPGA and ASIC. =A0Altera also has their hard > wired versions of FPGA's if you prefer to start with an SRAM > FPGA and then move to a non-reprogrammable version. =A0At > the moment Xilinx has no similar products. > > Regards, > Gabor- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - actually Austin did make a statemented that can be understood diferently, he said: "That bistream's key must be the one in the battery backed key memory, or the device will not program. " this is true, if the key is WRONG, but if the bitstream has NO KEY then the device will configure ok. and the all other on-board components are wide open for attack... this is different for Actel where AES secure parts can not be accessed without the AES key at all AnttiArticle: 142339
All, Perhaps what Raj is referring to is "one-armed bandit" mode (named because gambling machines must have this feature). This is when once a key is programmed into the part, the part no longer will accept any bitstream, only a bitstream encrypted with that key (which we do not support today for any family). The problem with this is that once programmed with the key, the device will never be able to be sent back for test (how do you test a part when you don't know the key? how do you encrypt 10,000 test bitstream to test such a part? etc.). How do you test it at the CM if you don't want to tell them the key? (Cm's are known for over-building ...) The poly efuse keys have been in V5 since day one, where we have been evaluating the technology and planning what support is required. We use some of the bits for inventory. Spartan 3A has poly efuses blown at the factory for "DeviceDNA." Virtex 6 might be the first product where AES poly efuse key, and "one- arm bandit mode" is supported: but not yet! Supporting all these features requires assurance that they all work, the software works to program them, and the customer has the means to do the programming. Stay tuned: yes; what you hear in conferences may be true, but it will be after we are sure these things deliver as promised. If Raj wants to prevent "improper use by a third party," or "over- build by contract manufacturer," or reverse engineering (cloning), these are different problems, which require different solutions. Encryption/Decryption may be used to solve some, but not all of them. Thanks to those who tried to clarify what I said, I suspect I will need more 'clarification' for this post, too. AustinArticle: 142340
"snowball67" <wtiong@singnet.com.sg> wrote in message news:Vr2dndTtLoMMG-TXnZ2dnUVZ_jGdnZ2d@giganews.com... > Hi, > > I have a design that will comprise of 11 FPGA boards: 10 slaves and 1 > master and each board is having one cyclone III FPGA. The communication > between master and slaves is via a simple SRAM protocol (with addr, data, > WR/RD and CS). All boards will be interconnected together on a backplane > board, with about 1 inch apart. > > According to the electrical specifications, the input leakage current of > each pin is only 10uA. Therefore, in the case of LVTTL with 4mA drive > strength, theoretically one master could drive up to 400 slaves? Is this > too good to believe? Also, overshoot voltage could be a problem if signals > are not terminated. Altera recommended 33R series resistor on each line. > Does anyone have similar experience on this? > > I also would like to know what is the real benefit of using LVCMOS apart > from LVTTL. > > Any recommendation is much appreciated. > > There is more to consider than just the input leakage current of each receiver as it only indicates what is possible for static signals. If all your signals never change state then, yes, each driver can drive 400 receivers. Of course, this isn't the reality of your situation. The input capacitance of each receiver, the rise/fall time of the driver, the characteristic impedance of all the traces, and the termination scheme used will determine whether the setup and hold times for data lines are met, whether the edge requirements for the clock lines are met, and whether the undershoot/overshoot specs for all signals are met. Unless your rise/fall times are very long with respect to all the trace propagation times, you'll need to get someone else involved that can guide you through these "signal integrity" issues. You can, to some degree, control the rise/fall times of FPGA output drivers. However, slower edge rates mean lower data rates (must always meet setup and hold reqs on data lines and dv/dt reqs on clock lines). The main advantage of LVCMOS over LVTTL is that LVCMOS input switching thresholds are farther from their associated outputs' nominal signal level. This allows for more "noise" (signal distortion) at the receiver while still meeting input logic level requirements. Bob -- == All google group posts are automatically deleted due to spam ==Article: 142341
On Aug 5, 6:04=A0pm, austin <aus...@xilinx.com> wrote: > All, > > Perhaps what Raj is referring to is "one-armed bandit" mode (named > because gambling machines must have this feature). > > This is when once a key is programmed into the part, the part no > longer will accept any bitstream, only a bitstream encrypted with that > key (which we do not support today for any family). > > The problem with this is that once programmed with the key, the device > will never be able to be sent back for test (how do you test a part > when you don't know the key? =A0how do you encrypt 10,000 test bitstream > to test such a part? etc.). =A0How do you test it at the CM if you don't > want to tell them the key? (Cm's are known for over-building ...) > > The poly efuse keys have been in V5 since day one, where we have been > evaluating the technology and planning what support is required. =A0We > use some of the bits for inventory. > > Spartan 3A has poly efuses blown at the factory for "DeviceDNA." > > Virtex 6 might be the first product where AES poly efuse key, and "one- > arm bandit mode" is supported: =A0but not yet! > > Supporting all these features requires assurance that they all work, > the software works to program them, and the customer has the means to > do the programming. > > Stay tuned: =A0yes; =A0what you hear in conferences may be true, but it > will be after we are sure these things deliver as promised. > > If Raj wants to prevent "improper use by a third party," or "over- > build by contract manufacturer," or reverse engineering (cloning), > these are different problems, which require different solutions. > Encryption/Decryption may be used to solve some, but not all of them. > > Thanks to those who tried to clarify what I said, =A0I suspect I will > need more 'clarification' for this post, too. > > Austin Austin Actel has Flash based AES key, not one time AES so there is no problem with testing with the efuse its different story of course its about time for Xilinx to get the efuses actually working i have wondering this since the V5 where some early schematic and docu did show the efuse pins but xilinx decided to not release V5 efuses to the customers probably because there are some bugs? ok, time have elapsed so maybe it all fixed in V6 AnttiArticle: 142342
It may not be easy for an organization using Xilinx/Altera, with commitments in the infrastructure of Xilinx/Altera to switch to Actel. One needing SERDES and PCIe etc and other IP may not be able to go to Actel if the IC doesn't support it or the IP is not freely available in the tools. I will continue my investigation. At the moment there doesn't seem to be a solution for bit data (bitstream) authentication and anti-hacking. I read these which maybe of help http://mae.pennnet.com/articles/article_display.cfm?article_id=309174 http://online.wsj.com/article/SB124027491029837401.html Altera announced this but I suspect it is no different than Spartan3AN. http://mae.pennnet.com/whitepapers/wp.cfm?id=1400 Those work great if I do my entire design in Spartan3AN or the Altera, but that is not likely. Perhaps it is perceived as Military problem only, however, I see just as much problem for many products in commercial area too. But maybe the volumes of FPGA based products are not like Xbox, iphone, linksys router or other previous hacked products. Thanks for all your input, I learned a lot. And no offence to Mr. Austin for providing information, perhaps my words were too strict of 'incorrect', perhaps miscommunication on my part. In the end I thnk we are in fair agreement. These are different problems that AES/Encrypt/decrypt does not solve. the perception by the fpga designers, however, I think is that it does solve these problems. >If Raj wants to prevent "improper use by a third party," or "over- >build by contract manufacturer," or reverse engineering (cloning), >these are different problems, which require different solutions. >Encryption/Decryption may be used to solve some, but not all of them. But absolutely in concurrence with Mr. Austin, it does not prevent overbuilding, reverse engineering, cloning. To that I add 'trojan bitstreams' used to compromise software security. The marketing material and articles from Xilinx/Altera (please do not take offense) do use the words protection from overbuilding and cloning with respect to AES encrypted bitstreams however that is only the case when you program the keys yourself or have a trusted third party program them. Practical on small scale of 10 or so but not practical for a 1000. I further agree Mr. Austin that the unencrypted bitstreams are necessary to be loaded for the CM to test my PCB with JTAG and related methods. I Understand why, just pointing out that is the hole in the security which enables trojans and unauthenticated bistreams that a system designer should address in commercial space not just military. Best Wishes, RajArticle: 142343
Antti.Lukats@googlemail.com <Antti.Lukats@googlemail.com> wrote: (snip) > sometimes there is need to to protect the PCB and other design > elements also > so a possibility to download a unencrypted bit file into an FPGA with > AES key set is somewhat design risc If it sells more hardware, even though the use is different, it doesn't seem bad. Assuming that the hardware sale price includes the price for the FPGA design, then it isn't likely that someone will find an affordable use for the hardware. One possibility, though, would be in a design with good economy of scale, someone might find a way to use it for something that didn't have the economy of scale to produce the hardware. If someone copies the PCB, then sue for copyright infringement. -- glenArticle: 142344
Rajesh Gandhi <rgandhi4086@gmail.com> wrote: >But absolutely in concurrence with Mr. Austin, it does not prevent >overbuilding,reverse engineering, cloning. However, the FPGA design that is encapsulated in the encrypted bitstream *is* secure. Expecting it to protect the rest of the system is analogous to expecting that the firmware protection in your PC's disk drive should protect the firmware of your PC's graphics card. If you want to secure your system, then you need system security. -- Dave FarranceArticle: 142345
I would like to understand how to create a concatenated string that
would be accepted for constraints in Verilog.
I have code like this:
genvar g;
generate
for(g = 0; g < 8; g = g + 1) begin : a_gen
(* U_SET = {"a",g} *)
(* RLOC = X0Y0 *)
//dsp 0 inst
(* RLOC = X0Y1 *)
//dsp 1 inst
end
for(g = 0; g < 8; g = g + 1) begin : b_gen
(* U_SET = {"b",g} *)
(* RLOC = X0Y0 *)
//dsp 0 inst
(* RLOC = X0Y1 *)
//dsp 1 inst
end
endgenerate
The issue is that I can't set the U_SET string to a concatenated
string:
(* U_SET = {"a",g} *)
is invalid.
This causes conflicts in my RLOC assignments as I want them
constrained only to a specific U_SET that is either a0, a1 ... to a7,
or b0, b1 ... to b7.
How would I do this? I can't find any information on this at all!!!
And ISE refuses to view this as a string valid for an attribute.
I have also tried
reg [8*32:0] my_name;
//gen code
assign my_name = {{"a"},g};
(* U_SET = my_name *)
which is also not considered valid by ISE.
Thanx
Nachum Kanovsky
Article: 142346Rajesh Gandhi <rgandhi4086@gmail.com> wrote: (snip) < The device will program when there is NO ENCRYPTION. Hence Trojan < bitstream is easy to implement. Trojans do not need to decrypt the < bitstream, attacker can program a bitstream into V5 or Stratix < by programming on-board FLASH with JTAG. All are 'wide-open' < for hacking. FPGA can be programmed which will assist in < 1) getting passwords from users/admin/embedded < 2) getting OTHER keys (not FPGA key) in system < 3) snoop system to hack and potentially unlock unpaid-for features < (turn low end product into high end product) < 4) learn enough about system to build compatible plug-ins (games, < software, songs, videos, printer cartridges) which < may not be part of economic strategy. Maybe, but are these really easier with a new bitstream attack? If one can float the I/O pins and put logic probes on the device, it might be about as easy. Otherwise, they are design failures of some kind. < "cant prevent hardware from being used for other things" sounds < like simple statement but many hardware products are sold at < loss or break-even or very low margin in order to make < market share. Printers for example. Company makes money on < consumables or plug-ins to the platform. I have seen many printers that sell for less than the cost of the ink cartridges included. If someone can find a use for that printer, even not requiring any modifications, it would seem to be a loss to the manufacturer. < Xbox is example - which is really just Intel PC sold at loss < to get market to sell games and internet service. Was Hacked < to run linux which is embarassment for Microsoft < but also a loss of $200 for each xbox purchased to run linux. As far as I know, there hasn't been a rush to buy them as linux systems. It may be $200 loss to MS, but it may still be more than it would cost to buy a similar PC. < Cisco low end router can be made into high end router with < hack patch - loss of revenue for Cisco. The software can check for some feature in the FPGA code. Otherwise, it is a normal software copyright question. Well, there is a story about an IBM computer (I believe System/3) that came in 32K and 64K models, the difference was the position of a switch. People learned about this and turned the switch, but had to remember to turn it back when the machine was being serviced. (They were usually leased, not sold.) In the case of the Cisco router, it would normally require different software (ROM) for the high end router. If someone can get that ROM contents, unencrypted FPGA code isn't likely to help, and it is a copyright violation in any case. < Reader who say 'if simple to mimik then u don't need encryption, < engineer will build from scratch' maybe missing the point. They are to < build a bit data by scratch that is their intent, to have their design < in place to do bad things. steal user password (not fpga key), monitor < keyboard input, monitor USB connection, insert 'time bomb' to stop < system functioning at critical time of need. Possible, but how likely? The encrypted FPGA code stops (for this discussion) reverse engineering of that code. It doesn't stop one from removing the FPGA and splicing into the pads. In the case of password stealing, it doesn't stop one from making a similar looking box that steals passwords but with completely different content. Monitoring keyboard input or USB signals is much easier than writing new code for the FPGA. No-one will pick your expensive door lock if you leave the windows open. < if I have embedded powerpc based fpga it maybe quiet easy for attacker < to get it to boot linux and have design which monitor keyboard input < for admin logins and store or send over internet. The interfaces are < all standard so easy to develop. If you can do that without access to the box, then it is a design failure. If I have access to the box, then there are too many other ways to attack the system. < And in end only virtex/stratix are secure, others are not. system < security maybe not xilinx/altera problem, just mine, but i have to < develop. Am I only one in FPGA area for this concern? -- glenArticle: 142347
austin <austin@xilinx.com> wrote: < Perhaps what Raj is referring to is "one-armed bandit" mode (named < because gambling machines must have this feature). There was an episode of the TV show NUMB3RS involving an electronic card shuffling device, with a designed in back door. (I don't remember the exact details now.) Note that nothing that you do with encryption can stop an attack in the encrypted code by the original designer. This problem may also occur in electronic voting machines. < This is when once a key is programmed into the part, the part no < longer will accept any bitstream, only a bitstream encrypted with that < key (which we do not support today for any family). It seems that in that case, one could always replace the FPGA with an unkeyed one. Yes the machinery for removing/installing BGA devices is specialized, but if the desire is there it will be found. If one has access to the box, there are many things to protect against in addition to replacing the FPGA code. -- glenArticle: 142348
Rajesh Gandhi <rgandhi4086@gmail.com> wrote: (snip) < These are different problems that AES/Encrypt/decrypt < does not solve. the perception by the fpga designers, < however, I think is that it does solve these problems. I believe that these problems are system problems, not FPGA bitstream problems. One has to go through the whole system to be sure that it is secure against attack. If there are easier ways to attack the system, and the FPGA can't protect against those attacks, then there is little reason to worry about the more complicated attack. Only after the rest of the system is protected, and that only happens when there is need for the protection, should one worry about this. Now, if there is an attack involving replacing the bitstream without physical access to the device then it needs fixing. -- glenArticle: 142349
All, http://www.intrinsic-id.com/ Has a solution (for protecting IP and getting paid for it), and it works. They use many levels (both hardware, firmware) and provide a trusted third party so that the CM asks for keys, tests, programs, and these are all kept on a database so that you, and they, know how many were built, and how many got 'enabled.' If this is done with FPGAs, the bitstreams may be encrypted or microprocessors, but preventing someone with physical access from loading their own bitstream or code, and perhaps using the system in a way not intended, is still not protected against. For that (anti-tamper) type of protection, there are other methods, mostly related to preventing physical access. The ATM machine is a good example: physical access is prevented by alarms, steel plates, etc. Austin
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