IoT VILLAGE - FPGA’s: a new attack surface for embedded adversaries
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 322 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/39908 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Information securitySoftwareInformation securityField programmable gate arrayBitSpacetimeControl flowHecke operatorComplex (psychology)Slide ruleGoodness of fitExpert systemQuicksortSphereLevel (video gaming)Right angleSoftware testingReverse engineeringSoftwareComputer hardwareComputer animation
01:33
BefehlsprozessorRead-only memoryField (computer science)Computer programLogic gateField (computer science)Computer hardwareBit rateCASE <Informatik>Logic gateFinite-state machineBefehlsprozessorTable (information)BitoutputConfiguration spaceFinite setFlash memorySemiconductor memorySet (mathematics)FeedbackStreaming mediaHybrid computerApproximationComputer animation
02:22
Type theoryHybrid computerVariety (linguistics)Data storage deviceInformation securityField programmable gate arrayLevel (video gaming)Information securityDifferent (Kate Ryan album)RamificationHybrid computerData storage deviceProgrammable read-only memoryField programmable gate arrayBounded variationFlash memoryStatic random-access memoryComputer animation
03:12
Fluid staticsEEPROMFlash memoryField programmable gate arrayStatic random-access memoryProgrammable read-only memoryFlash memoryData storage deviceEntire functionField programmable gate arrayEndliche ModelltheorieCASE <Informatik>Reflektor <Informatik>SpeichermodellMultilaterationReading (process)Proof theoryComputer animation
04:07
Execution unitDevice driverReading (process)Field programmable gate arrayFunctional (mathematics)Computer animation
04:29
Router (computing)Server (computing)Router (computing)Server (computing)LogicProduct (business)QuicksortINTEGRALLine (geometry)Field programmable gate arrayCryptographyComputer animation
04:55
Data miningData modelHardware description languageImplementationCASE <Informatik>Data miningCryptographyComputer hardwareImplementationField programmable gate arraySoftwareRight angleIntegrated development environmentQuicksortLogic synthesisComputer animation
05:33
Computer hardwareInformation securityGUI widgetField programmable gate arrayNP-hardBinary fileUniformer RaumComputer hardwareHardware description languageLogicImplementationContext awarenessLevel (video gaming)2 (number)Computer animation
05:58
CodeComputer hardwareFormal languageBefehlsprozessorHardware description languageMereologyLoginComputer hardwareComputer programQuicksortFormal languageBefehlsprozessorSoftwareLogic gateArithmetic logic unitExclusive orHardware description languageComputer animation
06:39
Cycle (graph theory)QuicksortInsertion lossMultiplication signSet (mathematics)Computer animation
07:02
Logic synthesisReverse engineeringStreaming mediaData storage deviceDifferential (mechanical device)BitInformation securityPower (physics)RamificationMedical imagingField programmable gate arrayCryptographyHeat transferMathematical analysisCompilation albumDifferent (Kate Ryan album)Hardware description languageElectric generatorLogicFirmwareOpen sourceLogic synthesisMathematical optimizationLevel (video gaming)Computer animation
08:32
Maxima and minimaHill differential equationDrum memoryEncryptionFunction (mathematics)Logic synthesisLogicBitInformation securityCryptographyKey (cryptography)Right angleDivisorFunctional (mathematics)Field programmable gate arrayAuthenticationRevision controlComputer animation
09:15
IcosahedronControl flowFunction (mathematics)PhysicsProcess (computing)Bounded variationDivisorNoiseParity (mathematics)ImplementationFaktorenanalysePropagatorDerivation (linguistics)Different (Kate Ryan album)Key (cryptography)Virtual machineNoise (electronics)CryptographyParity (mathematics)Computer animation
09:45
Data miningThumbnailPhysicsMalwareMaxima and minimaVirtual machineGamma functionExecution unitConvex hullElectronic mailing listWhiteboardBootingConfiguration spaceData storage deviceField programmable gate arrayStreaming mediaDrum memoryCloningExistenceDisintegrationVirtual machineFunctional (mathematics)Static random-access memoryTerm (mathematics)File formatMultiplication signEncryptionSpeichermodellLevel (video gaming)LogicScripting languageFlash memoryData storage deviceStreaming mediaField programmable gate arraySocial classInformation securitySoftwareBootingBitRight angleINTEGRALReverse engineeringAuthenticationQuicksortConfiguration spaceCloningComputer animation
11:57
Proper mapFile formatReading (process)File formatReverse engineeringGroup actionInformation securityComputer animation
12:43
Field programmable gate arrayInformation securityFeasibility studyReverse engineeringEncryptionInformation securityMathematical analysisCryptographyField programmable gate arrayQuicksortCASE <Informatik>Block (periodic table)Key (cryptography)InformationDifferential (mechanical device)Selectivity (electronic)Asynchronous Transfer ModeEncryptionType theoryCryptanalysisComputer animation
13:22
SoftwareLogic synthesisEncryptionStreaming mediaRandom numberNumberKey (cryptography)QuicksortRandom number generationInformation securityProcess (computing)Field programmable gate arrayIntegrated development environmentInstance (computer science)Set (mathematics)Computer animation
13:57
Similarity (geometry)MetastabilitätField programmable gate arrayOpen sourceEntropie <Informationstheorie>Phase transitionDenial-of-service attackComputerQuicksortCryptographyFrequencyPhase transitionPeripheralPropagatorProgrammschleifeInstance (computer science)Field programmable gate arrayOscillationExecution unitMultiplicationMetastabilitätComputer animation
14:30
RandomizationAreaOpen sourceField programmable gate arrayThresholding (image processing)MetastabilitätComputer animation
14:53
LogicLatent heatCellular automatonLogicReverse engineeringStreaming mediaFlash memoryBitCellular automatonReflektor <Informatik>Field programmable gate arrayPlastikkarteData storage deviceComputer animation
15:23
First-person shooterGamma functionMathematicsReverse engineeringComputer programInformation securityField programmable gate array
15:59
Information securityType theoryExecution unitKey (cryptography)Data miningFlash memoryLink (knot theory)Key (cryptography)Web pageLogicForcing (mathematics)BitStreaming mediaComputer animation
16:53
Field programmable gate arrayEndliche ModelltheorieField programmable gate arrayInstance (computer science)Computer animation
17:31
Configuration spaceNumbering schemeField programmable gate arrayMathematicsUniform resource locatorCASE <Informatik>Multiplication signComputer animation
18:05
Maxima and minimaField programmable gate arraySystem programmingPhysical systemConnected spacePhysicsElectronic mailing listLogicPhysical systemPower (physics)Field programmable gate arrayComputer animation
18:36
Schmelze <Betrieb>Level (video gaming)Computer virusRight angleVulnerability (computing)Computer animation
19:01
System programmingPersonal digital assistantField programmable gate arrayPeripheralConfiguration spaceFunction (mathematics)Function (mathematics)Logic synthesisStreaming mediaField programmable gate arrayBitVulnerability (computing)Finite-state machineFraction (mathematics)ResultantState of matterComputer animation
19:41
MeasurementQuantum stateField programmable gate arrayComputer hardwareIntegrated development environmentField programmable gate arrayComputerReverse engineeringDegree (graph theory)Mathematical analysisFlash memoryThermal radiationMeasurementComputer animation
20:37
Data storage deviceField programmable gate arrayIntegrated development environmentDatabase normalizationImplementationWeb pagePhysicalismInformation securityCryptographyComputer animation
21:04
DataflowDigital object identifierSingle-precision floating-point formatEvent horizonSystem callDataflowInformation securityFunctional (mathematics)Integrated development environmentField programmable gate arraySingle-precision floating-point formatThermal radiationBitSemiconductor memoryContext awarenessEvent horizonComputer animation
21:53
SpacetimeThermal radiationField programmable gate arrayIntegrated development environmentInfinite conjugacy class propertyError messageComputer iconAlpha (investment)Codierung <Programmierung>Thermal radiationIntegrated development environmentComputer animation
22:19
Thermal radiationSoftware testingEntire functionComplex (psychology)BefehlsprozessorBlock (periodic table)Hardware description languageThermal radiationSoftware testingEntire functionField programmable gate arrayBlock (periodic table)BefehlsprozessorPrime idealLibrary (computing)Right angleComputer animation
22:57
Finite-state machineDrop (liquid)BefehlsprozessorMenu (computing)Block (periodic table)Functional (mathematics)CuboidField programmable gate arrayVulnerability (computing)Computer animation
23:19
CryptographyAreaMathematical analysisBefehlsprozessorElectronic mailing listLogical constantThermal radiationInjektivitätPower (physics)Side channel attackPhysicalismPhysical systemMultiplication signCategory of beingMathematical analysisField programmable gate arrayInjektivitätComputer animation
23:53
Information securityField programmable gate arraySoftwareFluid staticsMathematical analysisTheoremLipschitz-StetigkeitInformation securityField programmable gate arrayMathematical analysisHardware description languagePropagatorFormal grammarMeasurementBit rateCategory of beingProof theoryError messageMultiplication signBoolean satisfiability problemFluid staticsDifferent (Kate Ryan album)Computer animation
24:55
Fluid staticsMathematical analysisSuite (music)Term (mathematics)Element (mathematics)Component-based software engineeringOperations researchSign (mathematics)Read-only memoryLogicLevel (video gaming)CryptographyMaizeRight angleSuite (music)LogicMultiplication signLevel (video gaming)Information securityMathematical analysisFluid staticsError messageType theorySoftware bugSemiconductor memoryDataflowInstance (computer science)Computer animation
25:31
Read-only memoryCryptographyLevel (video gaming)Mathematical analysisExecution unitDataflowInformationInformation securityMultiplication signMathematical analysisLevel (video gaming)BitExtension (kinesiology)InformationAreaTime zoneFormal languageLoginFluid staticsComputer animation
26:21
AliasingInformation securityRead-only memoryInformationDataflowGroup actionSynchronizationCondition numberState of matterAreaAsynchronous Transfer ModeSensitivity analysisMathematical analysisOperator (mathematics)DataflowAliasingMultiplication signStack (abstract data type)Computer animation
26:54
QuicksortThermal radiationCompilerNumberGoodness of fitNumbering schemeBitProcess (computing)Form (programming)Machine codeField programmable gate arraySoftware testingLevel (video gaming)Right angleMultiplication signDisk read-and-write headComputer animation
Transcript: English(auto-generated)
00:00
Hey, good morning, everybody. Who's ready to talk about some FPGAs? All right. Hey, I'm John Dunlap. I work for a company called GDS security. I do a lot of security research, reverse engineering, like to collect bad, broken software, hardware, cheap things, break
00:23
them, make them release that magical blue smoke. And I'm here to talk to you guys about FPGAs. More on the level of most people in the consumer sphere haven't really encountered FPGAs, but it's happening more and more. If you're really deeply ingrained in maybe military
00:44
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 to look for in FPGA design, what kind of things to look for when you're buying and picking FPGAs, what kind of
01:02
security protections are in them, what kind of anti-tamper 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 90-minute talk. So keep that in mind. If I move a little fast and if you're an FPGA sort of subject matter expert and you're like, hey,
01:24
there's some complexity got missed there, that's why, we've got to move fast. So yeah, this is for people who are a little new to FPGAs. So what are FPGAs? They are field programmable, as in you can reprogram basically the hardware itself,
01:44
make your own CPU or state machine or whatever, and gate array as in a rate of gates, but not really. In most cases what we're talking about is a set of lookup tables that are transferred from configuration memory. So you have
02:00
something like SRAM or a flash memory that holds the bit stream for a bunch of lookup tables, and these approximate the behavior of gates. So if you imagine you have like a finite set of inputs, oops, I'm getting feedback here, a little bit, yeah, you have a finite set of inputs and outputs for the gate design, and this can approximate hardware basically. There are lots of hybrid
02:28
variations on this. So you can get FPGAs 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
02:40
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
03:00
methods, and even CPLD hybrids with FPGAs. You got SRAM, NFUs, PROM, EPROM, FLASH, and I think for most of you, you know what SRAM would be, you would know what an EPROM is, if you're familiar with embedded devices, FLASH is probably familiar
03:22
to all of you. You might not have run into NFUs, and NFUs is one of the first topics you might come into when you're looking at tamper proofing in 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
03:40
design and some kind of storage like an SRAM or FLASH, it's possible for people to take your entire hardware design and pull it off and flash it onto another FPGA, use it for themselves. It's something you don't want. NFUs, FPGA, they basically use fuses that are broken to encode the design, which in most cases means that
04:01
there's absolutely no way to just pull it off short of looking at it with like a scanning electron microscope. Even though some NFUs FPGAs actually do have a read back function that reads back the design, which is funny, like they naturally wouldn't have it. People went out of their way to implement it, which is kind of goofy. If
04:24
you're wondering what FPGAs are used for, like practically everything, you see them a lot in the self-driving cars, military technology, routers, big use, especially implementing stuff like tertiary logic servers now. Intel has a whole sort of product
04:42
line of servers coming out with FPGAs. If you guys aren't familiar, Altera, one of the bigger FPGA vendors, just got bought by Intel. So what you used to see is Altera is Intel now and it's mostly for that server integration. Of course, the crypto mining people love them. In case you didn't know, the big value add for an FPGA is
05:04
you can basically make 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 that is more performant in hardware than software. That's possible. So what kind of threats are we going to look for in FPGAs? Attacks against the
05:21
hardware itself, attacks against the HDL 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
05:44
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 second. So what is HDL? It's
06:03
language. We're talking about stuff like Verilog, VHDL, and sort of a way to program up hardware. So we can take stuff like wires, buses, clocks, and define them dynamically. Here's an example of part of the Verilog CPU. This is actually an ALU, arithmetic logic unit here.
06:23
And you can see you have all the adding XOR defined by the 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
06:43
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, which is pretty freaking cool. But it 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?
07:03
If you're not familiar with synthesis, it's basically the compilation if you want to think about where we take our HDL design and turn it into something we can throw on to the FPGA itself.
07:22
Here are the basic steps of it. I'm not going to go too deep into it. 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 the 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
07:42
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 there's one like liberating yet dangerous thing about FPGA design is that we can say spread storage across the chip, make it hard to read, or we could spread
08:02
RAM across the chip, spread crypto stuff in different places. But if you don't do that or just let the chip player do it for you, that might cause some issues. And the final step here we're going to talk a little bit more is bit stream generation. And if you want to think about the final,
08:21
you know, you think of 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
08:41
how you can make sure that all this stuff happens without an insider threat between each steps. Let's see, another topic that will come up when you start reading about FPGA security is physically unclonable functions. Which is an interesting crypto idea if you haven't run into it. It's basically the idea is that we're going
09:03
to get maybe our crypto keys or some kind of authentication logic based off of factors specific to this exact bit of silicon. So things will be different on each version of the device. So we might do that by measuring propagation delays.
09:22
We might do that by measuring voltages, capacitance, parity, noise. There are attacks against these, but basic idea is that this stuff will vary chip to chip and we could do something like derive a crypto key based on these differences. One of the
09:42
advantages being that we don't have to like put it on the device somehow. There are machine learning attacks against these, you should 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?
10:03
You know one of the problems as I said before is that when we use FPGAs we kind of have to keep our IP in a format that's usable on the device, be it SRAM or flash or whatever. So how do we protect it? How do we get it off the chip? We might look to grab it during configuration
10:23
of the device 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.
10:43
Or we might try to rip it directly off the storage medium itself. So a lot of people call this class of attacks bitstream cloning. The most easy thing to do for an attacker, sort of the most script kitty thing is to abuse read back functionality of the FPGA. And a lot of times if it's not like a highly secured FPGA
11:05
this might just be wide open. You might be able to connect it to cordis prime or whatever ID you're using to build your FPGA software and say read me back to bitstream and it will do it for you without any kind of authentication. Something to look into if you're building an FPGA laden device.
11:21
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 bitstreams are a thing. And the other thing to watch out for is like sort of integrated devices. One way that hardware designers try to prevent bitstream playing attacks is to
11:44
put the storage and the logic on the same die so you have to decap the chip and do something much harder physically in terms of reverse engineering to get the bitstream. This is from, I think it's from Altera via like
12:04
instructions for performing a read back on one of their chips. So on some of the, oh no that's Zilinx, yeah there we go. So it's super easy if it's not disabled. There are also ways to activate the read back by tampering the chip itself. But once you have the bitstream it's not all roses.
12:24
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 is proprietary. And there's whole groups of people who like specialize in trying to reverse engineer these bitstream formats. It's not easy. We're talking about like a month of reverse engineering.
12:45
It's security by obscurity but it tends to work kind of okay. 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 crypto analysis attacks.
13:05
And bad crypto too. 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 definitely not a perfect way to encrypt things.
13:24
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 finding a way to flash the keys on and keep everything copacetic. For instance
13:44
keys usually put on there via JTAG. If you leave the JTAG activated that could cause its own set of problems. Another thing people try to do security wise with FPGAs is implement true random numbers. You might get these from
14:00
propagation delays, oscillator jitter, oscillator frequency, phase lock loops or a dedicated hardware peripheral that does this. Big thing in FPGAs is sort of the one of the like higher end things you pay for is little peripherals that do certain kinds of computations for you like you might get a special
14:22
DAC based multiplication unit for instance something you would pay extra for. So you can get things like that for crypto. Also metastability which if you're not familiar is like if you have a one and a zero and a threshold for that metastability is when we have values that live in that middle area which in terms of like a viable FPGA design is considered to be unacceptable
14:44
but if you do it on purpose you can use that as a source of randomness because you have this we're not sure if it'll evaluate to one or zero. It's basically truly random. So if we're trying to get all this bit stream off the FPGA we're going to run into problems with anti-tamper devices pretty quickly. Stuff like
15:03
fuses, anti-tamper fuses, tamper resistant flash memory cells and logic placement designs are meant to frustrate the reverse engineer. So here's a micro semi smart fusion device and this is one where we have like an integrated design where it would be very hard to middle storage.
15:24
And here's going over some micro semis protections that they have on here. I thought it would be good to like talk about anti-tamper and show some of the data sheets because it gives you an idea of how common it is on FPGAs. It's actually kind of very responsible thing of the industry. Probably has something to do with the fact that FPGAs are widely used
15:43
by the military. So we have multiple fuses actually. We have an array fuse, a security fuse, a program fuse and a probe fuse all meant to break the device if it finds that reverse engineers have been mucking about. And if you're going to try and pull that design off the FPGA you have to deal with all of that. They actually have a similar things for their
16:03
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 found it to be funny in their data sheet. Are the keys secure? Yes. Xilinx is kind of the kings of this. They have this huge scary list of like
16:23
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 on it and you want to protect your bit stream then you might want to read your data sheet and see like what exactly 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
16:43
tampered. So you put your JTAGulator on there and try to brute force it and all of a sudden you break your device. It's a good thing to know before going in with these things. Anti-readback. We'll talk about ICAP in a second. Thing to keep in mind is while these features are really common,
17:04
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 of FPGAs I have a
17:20
Cyclone 2 device that I bought off of eBay and a Cyclone 3 device that I bought off eBay. Cyclone 2 has none of these features. Cyclone 3 has about half of them. So read your data sheets. Another thing to watch out for is disabling your protection of ICAP as an internal configuration port. So the cool thing about FPGAs
17:41
in case a possibility hadn't crossed your mind is they can configure themselves. So you can have a self-reconfiguring design that changes itself and mutates. There's been various schemes for making a highly secure design based on a self-mutating FPGA where like the locations of things swapped around, the timing delays of things swapped around. But then you
18:01
have to worry about is there a way that attacker can hijack my ICAP? Listing here there is some ICAP protections in the anti-tamper list as well. Here's another threat is damaging systems connected to the FPGA. There's been some research into this as well. So say that your FPGA is secure for midstream attacks,
18:21
what if the attacker just wants to misuse the logic on your FPGA to destroy things? So it's not uncommon for FPGAs to be connected to, you know, be the glue logic for various high power systems. And people have come up with attacks where you cause it to overvoltage or something like that
18:42
and cause a small fire melting things, whatever. So this particular paper, they call it the FPGA virus, which I think is kind of funny. They propose an attack they call melt, which is like right on the nose.
19:01
And the main idea with the melt vulnerability is that they're altering the bitstream, which on a properly set up synthesis pipeline and FPGA shouldn't be possible. But altering in such a way that unacceptable voltage comes out the other end of the FPGA and causes some serious trouble. And while that might be unlikely in a properly
19:21
configured setup, there are situations where you have unthoroughly 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. What is your FPGA connected to and are all possible values of output considered?
19:42
What if you want to just attack the FPGA itself? What if we don't care about dumping the flash? Maybe we're going to reverse engineer it physically, which is something that FPGA manufacturers definitely worry about and there is definitely a whole body of research on how to do. There's techniques like focused ion beam
20:01
measurements, scanning electron microscopes, x-ray analysis is a big thing, thermal analysis of the running FPGA. And depending on how much you want to pay, you can get FPGAs that are hardened against these things to some degree or another. And we might also try to tamper the FPGA by placing
20:21
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 to, this FIPS document here goes over some of the hardening you might want to check out for that. We'll get into those attacks
20:41
a little more specifically in a sec, but you would solve this with more robust circuitry, essentially redundancy, voltage regulation, secure cryptographic implementation, and it's like a DAC based shutoff wherein the temperature is wrong. In fact, I think Zilinx back on the other page has like some kind of anti temperature tampering
21:01
thing. And then there's like physical isolation, which is the idea that if you have some kind of secure 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.
21:26
And then idea that comes up a lot is the single event upset. And 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 get a chip to glitch, essentially. But FPGAs are especially
21:45
vulnerable to this situation where some ionizing radiation causes a bit to flip or some memory to change. NASA has a document on this. There's a whole bunch of suggestions for how to
22:02
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 if you're in a high intensity threat environment, you might want to think about radiation proofing your FPGA. Well, here's a guy at BIE doing
22:22
radiation testing, which I think is freaking cool. So FPGAs also have something like a library, right? And these are usually called IP blocks. And they're ACL designs provided by third parties. And they're usually provided by your device manufacturer, your ID, whatever you're using, like
22:41
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. Here's just a drive at home. Here's the
23:01
Altera IP blocks menu. And you can put in all these functions. They're just drag and drop. Stuff is complex to CPUs, RAM, state machine. And it's an overlooked thing that if you have a design with FPGAs, you might want to get your IP box checked for vulnerabilities as well. What about
23:21
cryptographic attacks? The same kinds of DFA attacks that people worry about for other kinds of embedded systems are a big deal for FPGAs 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 stuff other than
23:43
you might take advantage of the routing and physical placement properties of the FPGA to try and counteract that. We talked about glitch injection before. And getting towards the end here, talk a little about security tools for FPGAs and what some more
24:02
HDL oriented analysis might entail. You know, one thing to keep in mind on FPGAs is actually some of the stuff if you're familiar with like SAT solvers or formal methods or proof-based security measures, this is
24:20
very mature on FPGAs, but for different purposes than 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 meta-stability we talked about, making sure that the clock can run at a stable rate without causing
24:41
propagation delay based errors. It's not so much for security, but it could help you with security. You know, usually static timing analysis tools can do things like detect unconstrained paths. That might be a security problem, it might not be. But that will come with your design suite, right?
25:00
But there are problems at the intermediate level with finding bugs in this. It's not going to find logical bugs and it's not going to know unless you help it along about security errors with data flow, right? The static timing analysis can't tell, for instance, where your data is going and
25:20
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 in the purview of that type of analysis. So this is really good static analysis, but it doesn't fulfill the needs of what a security engineer would be looking for necessarily all the time. I think one
25:41
of the coolest in getting along to the same idea everyone's having about how to do security, static analysis on FPGA is this tool from Cornell called SecVerilog. And the basic idea is like one of the biggest problems on FPGA design security is like where that security information is flowing. And so SecVerilog is
26:01
basically an extension to the Verilog language where we are able to imitate which bits of our data are secure and it will trace that by injecting Verilog at various levels and areas and give us an idea of what's going on. And you see a lot of like transpiler
26:21
ideas in the zone. They give you an idea of the kind of ideas like a human would find that the stack 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
26:40
incorrectly, race conditions, places where you're assuming you're in a synchronous mode of operation but it's actually asynchronous or the opposite. A-listing issues. And that's basically it. I don't know how we're doing on time. Let's see.
27:01
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 like, oh, this was too high level for me. OK, I got you.
27:25
It's OK. All right. Well, I'm out then. Well, a question. Yeah. So, no, I haven't seen that.
27:44
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 GNU VHDL compiler that basically turns VHDL designs into native code for Linux.
28:02
I don't think that would be hard to instrument in the same way. Oh, OK. Yeah.
28:22
Most of the literature is in the form of like alpha particles. I don't know 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.
28:41
There's sort of an annealing process that can go on when you when you slam the chip with like lots of radiation as opposed to 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 of literature on like how unreliable the industrial testing can be on on that if you're not careful.
29:12
Have a good day, guys.