hey good morning everybody who's ready to talk about some FPGAs all right hey I'm John den lap I work for company called GDS security Gotham Dillinger science I do lot of security research reverse engineering like to collect bad broken software hardware cheap things break them make them release that magical blue smoke and I'm here to talk to you guys about FPGA is more the level of most people in the consumer sphere haven't really encountered FPGA is what's happening more and more if you're really deeply ingrained in maybe military or highly secretive technologies you might be more familiar with them but FPGAs are kind of creeping more into the consumer space bit by bit and if you're say an embedded pen tester you might not know what kind of bad things look for an FPGA design what kind of things to look for when you're buying and picking FPGAs what kind of security protections are in them what kind of anti Tambor protections are in them and just what the heck is an FPGA keep in mind that probably every slide in this talk could take up its own ninety minute talk so keep keep that in mind if I move it a little fast and if you're an FPGA sort of subject matter expert you're like hey there's some complexity got missed there that's why we got to move fast so yeah this is for people who are a little new to FPGAs

so what RF BGA is they are field

programmable as in you can reprogram basically the hardware itself make your own CPU or state machine or whatever and gate array as in a rate of gates but not really in most most cases what we're

talking about is a set of look-up tables that are transferred from configuration memory so you have something like SRAM or a flash memory that holds the bitstream for a bunch of look-up tables and these approximate the behavior of gates so if you imagine you have like a finite set of inputs getting feedback here a little bit yeah you ever find that two inputs and outputs for the gate design and this can approximate hardware basically there are

lots of hybrid variations on this so you can get FPGA is in a bunch of different flavors and that's relevant to this discussion because they behave differently and have different security ramifications and unfortunately I don't want to make the talk seem like I'm ever advocating for a particular brand or that I'm talking about like what to buy too much but what security you get often depends on what you buy how much you pay what kind of device you're asking for there's different power consumption levels different sizes different storage methods and even Cpl D hybrids with FPGAs you got SRAM NF use prom EEPROM flash and I think for most of you you

know what SRAM would be you would know

what a prom is if you're familiar with embedded devices flash is probably

familiar to all of you you might not

have run into and I've use an anti fuses one of the first topics you might come into when you're looking at tamper poofing and fpga we'll talk a little bit later about how one of the main threat models for fpga is making sure people don't dump the design off the FPGA so if the fpga has this design and some kind of storage like it SRAM and flash it's possible to for people to take your entire hardware design and pull it off and flash it on to another FPGA use it for themselves it's something you don't want and i fused fpga they basically use fuses that are broken to encode the design which in most cases means that there's absolutely no way to just pull it off short of looking at it with like a scanning electron microscope even

though some and a fuse FPGAs actually do have a read back function that reads back the design which is funny like it they naturally wouldn't have it people went out of their way to implement it which is kind of goofy if you're

wondering what FPGAs are used like practically everything you see them

a lot in these self-driving cars

military technology routers big use free especially implementing like stuff like tertiary logic servers now and Intel has

a whole sort of product line of servers coming out with FPGA if you guys are familiar Altera one of the bigger FPGA vendors just got bought by Intel so what used to see is altair it is Intel now and that's mostly for that server integration of course

the crypto mining people love them the in case you didn't know the big value

add for an FPGA is you can basically made your own ASIC right if you want to implement crypto in hardware and have it be more performant than software crypto you can do that with an FPGA or anything really there's more performing hardware and software that's possible so what

kind of threats are we going to look for in FPGAs attacks against the hardware itself tax against HCL implementation sort of environmental problems and attacks against the synthesis pipeline we'll talk about that in just a second

and something to keep in mind when we're talking about FPGA threats FPGA problems is that we're working at this kind of intermediate level where we are actually talking about logic but it's in the context of hardware and that middle level isn't very easy attack if you're not a human being thinking about the HDL implementation you'll see that in a sec so what is HDL it's Hardware definition

language we're talking about stuff like very log VHDL and sort of a way to program Hardware so we can take stuff like wires buses clocks and define them dynamically here's an example of part of

the vera log cpu this is actually in ALU arithmetic logic unit here and you can see you have all the adding X or what not defined by this software but it gets put out into hardware it gets put into actual gates and registers and whatnot this is a different way of thinking about things one thing I always thought

was cool about HDL is that you can do things like actually reason about literal clock cycles so you can say every rising edge we do this or every two rising edges we do this it's pretty freakin cool but also sort of inserts a whole set of problems of like when do we do that when do we not do that are we keeping our timing copacetic if you're

not familiar with synthesis it's basically the compilation if you want to think about where we take our atl design and turn it into something we can throw on to the fpga itself are are here the basic steps of it I'm not gonna go too deep into I could talk about synthesis for like a whole one-hour talk but we have like a register transfer level some optimizations and then mapping onto actual chip that we're going to use and a couple steps that mean that we're going to plan out where on the die stuff is going to go and that has security ramifications where we put our crypto logic on the chip relative to other stuff might affect the viability of things like differential power analysis attacks and that is one like liberating yeah dangerous thing about FPGA design is that we can say spread storage across the chip make it hard to read or we could spread RAM across strip spread crypto stuff in different places but if you don't do that or just let the chip laner do it for you that might cause some issues and the final step here we're going to talk a little bit more is a bit stream generation and if you want think about the final you know you're thinking firmware the image of the stuff that gets put into the FPGA that's our bit stream and so if you want to start talking about reverse engineering FPGAs you want to start talking about bit stream reverse engineering before we get

there it's important that this synthesis

pipeline be secured and there's a lot of thought going into how how you can make sure that all this stuff happens without an insider threat between each steps see

another topic they'll come up when you start reading about fpga security is physically uncountable functions which is an interesting crypto idea if you haven't run into it it's basically the idea is that we're going to get maybe our crypto keys or some kind of authentication logic based off of factors specific to this exact bit of silicon right so things will be different on each version of the device

so we might do that by measuring

propagation delays we might do that by measuring voltages capacitance parity noise there are attacks against these but basic idea is that this stuff will very ship to chip and we could do something like derive a crypto key based on these differences one of the engines being that we don't have to like put it on the device somehow there are machine

learning attacks against these usually look into them and there's also bypasses

against those machine learning attacks

so how do we prevent people from disclosing our IP from the FPGA chip you know one of you like problems as I said before is that when we use FPGA is we kind of have to keep our IP and a format that's usable on on the device you know be SRAM or flash or whatever so how do we protect it or how do we get it off the chip we might look to grab it during configuration of the device right when the device is being flashed as it were a lot of FPGA devices are set up in such a way that the IP is transferred from storage at boot time every time the FPGA is booted up it gets transferred across and we might try to attack that if it's possible or we might try to rip it directly off the storage medium itself so a lot of people call this class of tax bitstream cloning the most easy thing to do for an attacker store the most script Kitty thing is to abuse read-back functionality FPGA and a lot of times if it's not like a highly secured fpga this might just be wide open and you might be able to connect it to Quartus prime or whatever ID you're using to build your fpga software and say read me back the bitstream and it'll do it for you without any kind of authentication something to look into if you're building an FPGA Ladin device usually there's a bit you can set to prevent that but on some of the lower security devices that's not a thing and obviously people are going to tamper that the next level would be trying to middle the bitstream somehow right but encrypted bit streams are a thing and the other thing to watch out for is like sort of integrated device is one way that hardware designers try to prevent bit stream playing attacks is to put the storage and the logic on the same die so you have two decap the chip and do something much harder physically in terms of reverse engineering to get the bit stream here this is from I think

it's from Altera be like perform instructions for performing a read back on one of their chips so on some of the oh no that's Xilinx yeah there we go so it's super easy if it's not disabled there are also ways to activate the read back by a tampering the chip itself but

once you have the bitstream that's not all roses you might have to reverse engineer the bitstream and this is a big problem because every single chip and every single manufacturer has their own bitstream format that is not documented that it's proprietary and there's whole groups of people who who like specialize in trying to reverse engineer these bitstream formats not easy we're talking about like a month of reverse engineering it is security by obscurity

but it tends to work kind of ok another

thing people try to do is bitstream encryption but then you have to deal with like how do you get keys onto the device and the pain of that and protecting device from differential cryptanalysis attacks and bad crypto - there have been many cases of FPGAs that inherently use AES CBC mode which if you're not familiar has a block swapping type attack which you could use to decrypt information sort of selectively it's not definitely not a perfect way to encrypt things and like I said before

you have to worry about how to get the key onto the device most FPGA sort of working environments have something to help you with this but it can be kind of a pain manufacturing process wise of like finding a way to like flash the keys on and keep everything copacetic for instance keys usually put on their VGA tag if you leave the JTAG activated that could cause its own set of problems another thing people try to do security wise with FPGA is implement true random numbers you might get these from

propagation delays oscillator jitter oscillator frequency phase locked loops or a dedicated hardware peripheral that does this big thing and FPGAs is sort of they want to like higher-end things you pay for is little peripherals that do certain kinds of computations for you like you might get a special DAC based multiplication unit for instance something you would pay extra for it so you can get things like that for crypto also minused ability which if you're not

familiar is like if you have a one in a zero in a threshold for that metastability is when we have values that live in that middle middle area which in terms of like a viable fpga design is considered to be unacceptable but if you do it on purpose you can use that as a source of randomness because you have this this we're not sure if it will evaluate to 1 or 0 it's basically truly random so if we're

trying to get all this bit stream off the fpga we're gonna run into problems with anti tambour devices pretty quickly stuff like fuses anti-tamper fuses tamper resistant flash memory cells and logic placement designs are meant to frustrate reverse engineering so here's our micro

semi smart fusion device and this is one where we have like an integrated design where it would be very hard to middle a storage and here's going over some of

like micro semies protections that they have one here I thought it would be good to like talk about anti Tambor and show some of the some of the data sheets because I guess the idea of how common it is on FPGA is is actually kind of very responsible thing of the industry but I had something to do with the fact that PJ's are widely used by the military so we have multiple fuses actually have an array of fuses security fuse the program fuse and a profuse all meant to break the device if it finds that reverse engineers have been mucking about and if you're wearing to try and pull that design off the FPGA you have to deal with all of that they actually

have similar things for their flash memory so if you're trying to pull stuff directly off the flash you'll have to deal with that as well

I like this page though are the keys secure I just put that up because I I found it to be funny in their data sheet are the keys secure yes same links is

kind of the kings of this they have this huge scary list of like hardening features you can get in your FPGA thing to keep in mind is like all these features aren't on all FPGAs and if you're trying to make a consumer device with an FPGA and you want protect your bit stream then you might want to read your data sheet and see like what exactly is there is there they have stuff like logic you can put on there that will disable the device if it feels like the JTAG is being tampered so you put your day tag you later on there and try to brute force it and all of a sudden you prick your device it's a good thing to know before going in with these things see anti read back we'll talk

about ICAP in a second thing to keep in mind is while these these features are

really common as you go into the cheaper more consumer oriented devices especially the older models of devices they sort of disappear it's like a recent improvement in some ways or especially for the cheaper devices for instance at home in my personal collection FPGAs I have a cyclone 2 device that I bought off eBay and a cyclone three device bought off eBay cyclone 2 has none of these features cyclin 3 has about half of them so read your data sheets another thing

to watch out for is disabling a

protection if I cap is an internal configuration port so cool thing about FPGAs in case the possibility heading across from I as they can configure themselves so you can have a self reconfiguring design that changes itself mutates and you know there's been various schemes for making a highly secure design based on a self mutating FPGA where like the the locations of things swapped around the timing delays of things swapped around but then you have to worry about is is there a way that attacker can hijack my I cap and

you think listening here there are some I cap protections in the and tamper

lists as well here's another threat is a damaging systems connected to the FPGA there's been some research into this as well so say that your FPGA is secure from midstream attacks well if the attacker just wants to misuse the logic on your FP a FPGA to destroy things so it's not uncommon for FPGA is to be connected to you know be the glue logic for various high power systems and people have come

up with attacks where you caused it to over voltage or something like that and cause a small fire melting things of whatever so this particular paper they called the FPGA virus which i think is kind of funny they proposed an attack they call melt which is like right on

the nose in the main idea with the mell

vulnerability is that they're altering the bit stream which on properly set up synthesis pipeline and fpga shouldn't be possible but altering it in such a way that unacceptable voltage comes out the under the other end of the fpga and causes some serious trouble and while that might be unlikely in a properly configured set up there are situations where you have uh thoroughly defined state machines stuff like that where you might get out an unintended result from the fpga somehow so it's something to look into you know what is your fpga connected to you in our all possible values of output considered what if you

want to just attack the FPGA itself what if we we don't care about dumping the flash maybe we're gonna reverse engineer it physically which is something that FPGA manufactures definitely worry about there's definitely a whole body of research on how to do there's techniques like focused ion beam measurements scanning electron microscopes x-ray analysis is big thing thermal analysis of the running FPGA and you know depending on how much do you want to pay you can get FPGA is there like hardened against these things to some degree or another and we we might also try to tamper the FPGA by placing it in a temperature it's not expecting tampering with the clock tampering the voltage using ionizing radiation I'm serious is a big thing and you want a DISA FIPS document here it goes over some of the hardening you might want to check out

for that we'll get into those attacks a little more specifically in a sec but

you would solve this with a more robust so circuitry essentially redundancy voltage regulation secure cryptographic implementation and it's like a DAC based shut off or in the temperatures wrong in fact I think zillion spec on the other page has like some kind of anti temperature tampering thing and then there's like physical isolation which

since calls like isolation design flow and its idea that if you have some kind

of sure function that you think is really important you don't want tampered you can put it somewhere else on the ship and have it live in its own land which is an interesting good idea it's not automated in most FPGA programming environments and then idea that comes up

a lot is the single event upset when we're talking about radiation this is a big deal so usually it's in the context of people in a high radiation environment but something an attacker could try to use to give that a chip to glitch essentially but FPGAs are especially vulnerable to this situation where some ionizing radiation calls it causes a bit to flip or some memory to change nASA has a document on

this there's a whole bunch of

suggestions of how to just secure the FPGA against it when we talk about soft IP in a second there's a bunch of companies that offer soft IP that's supposed to secure against it but you know if you're in a like high-intensity threat environment you might you might want to think about radiation proofing your FPGA well here's a guy BAE doing

radiation testing which i think is freaking cool so FPGA is also like

something like a library right and these are usually called IP blocks and they're HCL designs bred by third parties and they're usually provided by your device manufacturer your ID whatever you're using like Quartus prime or whatever will usually come with a bunch of these that you can license from Intel or Xilinx or whoever it may be and it can be really ornate stuff like entire CPUs that you can customize to your needs you

know here's just a drive at home here's the Altera IP blocks menu and you can put in all these all these functions are just dragging drop you know stuff is complex of CPUs ram state machine and

you know it's an overlooked thing that if you have a design with FPGA is you might want to get your IP box checked for vulnerabilities as well what about

cryptographic attacks the same kinds of DFA attacks that people worry about for other kinds of embedded systems are a big deal for FPGA as well so you know timing based attacks side channel attacks power analysis glitch attacks not much to say here that's different than other other stuff other than you might you might take advantage of the routing and physical placement properties of the FPGA to try and counteract that we talked about glitch

ejection before and getting towards the end here talk a little about security tools for

FPGAs and what you know some more HDL oriented analysis might entail you know

one thing to keep in mind with FPGA is it's really cool it's stack analysis works really well on FPGA is actually some of the stuff if you're familiar with like sat solvers or formal methods or proof based security measures this is very mature on FPGA is but for different purposes then maybe security people are used to it's oriented more towards defining correctly the electrical properties of FPGA making sure that we don't have things like that medicine we talked about making sure that the clock can run at a stable rate without causing propagation delay based errors it's not so much for security but it could help you with security you know usually that timing analysis tools can do things like detect unconstraint paths that might be a security problem it might not be but

they'll come with your design suite right but there are problems at the

intermediate level with finding bugs in this it's not gonna find logical bugs and it's not going to know unless you've helped it along about security errors with data flow right the sag timing analysis can't tell for instance where your data is going and which of it's supposed to be secure can't answer questions like can the user write to arbitrary memory none of this stuff is even like in the purview of that type of analysis so this is really good

stack analysis but it it doesn't fulfill the needs of like what a security engineer would be looking for necessarily all the time I think one of

the coolest in giving along to like the same idea everyone's having about how to do security SEC analysis on FPGA is this tool from Cornell I called SEC ver log and the basic idea is like one of the like biggest problems on FPGA design security is like where that secured information is flowing and so psyche very log is basically an extension to the very log language where we are able to imitate which bits of our data are secure and it will trace that by injecting verlag at various levels in areas and give us an idea of what's going on and you see a lot of like transpiler ideas in the zone they give

you an idea the kind of ideas like a human would find that the sac analysis tool won't we're looking for like bad state transitions data flow to unintended areas timing sensitive problems places where people should or should not be checking the clock or doing so incorrectly race conditions places where you're assuming you're in a synchronous mode of operation but it's actually asynchronous or the opposite aliasing issues and that's basically I

don't know how we're doing on time let's see oh pretty good so since we're good on time do we have any questions from the audience dead silence how many of you guys have worked with FPGAs before oh cool so you guys are all Ohio this was still a little high level for me okay I got you it's okay all right well I'm out then well a question yeah so no I haven't seen that although I don't think it would be hard to put together some of the schemes I've seen proposed are taking something like I know that there's a canoe of HCl compiler that basically turns VHDL designs into native code for Linux I don't think that would be hard to instrument in the same way oh okay yeah most of the literature is in the form of like alpha particles we I don't know that the number off the top of my head but there's an interesting it might be the opposite of what you think like less is more there's sort of an annealing process that can go on when you when you slam the chip with like lots of radiation as it boasts a little bit intermittently where the chip will be more reliable more reliable with more radiation than less and that's when the problem if you look into there's a whole lot literature and like how unreliable the industrial testing can be on on that if you're not careful all right have a good day guys