Embedded - 286: Twenty Cans of Gas

Episode Date: April 18, 2019

Colin O’Flynn (@colinoflynn) spoke with us about security research, power analysis, and hotdogs. Colin’s company is NewAE and you can see his Introduction to Side-Channel Power Analysis video as an intro to his training course. Or you can buy your own ChipWhisperer and go through his extensive tutorials on the wiki pages. ChipWhisperer on Hackaday ColinOFlynn.com Some FPGA resource mentioned: Fpga4fun.com TinyFpga.com MyHdl.org (Python!)

Hello and welcome to Embedded. I am Elysia White and I'm here with Christopher White. Our guest is Colin O'Flynn who whispers to chips. We'll be asking him if they ever whisper back and talking about security. Real security, like chip security. Like, I don't even know security. Hi, Colin. Welcome.

Hi. Could you tell us a bit about yourself? Yeah. So basically, I sort of came from the embedded design side. I worked at Atmel actually as a consultant for a while doing, you know, what was wireless sensor networks then, which is kind of like IoT when it was even less clear that IoT was going to turn into anything useful. After I left that, I became, that's when I sort of spun into security. So I went back to school for originally a master's and then PhD, which is when I've done a lot of this side channel analysis and fault injection work, which then turned into the open source chip whisperer project, which

sort of was like a fun project coming out of my PhD that sort of transformed into a company, like a kind of reluctant entrepreneur because people were interested in buying stuff. And the problem with open source hardware is, right, they just want to have the final product a lot of the time. Yeah, that's kind of what has led me down this path now to being focused on security the last few years. All right, well, we're going to talk more about security and what chip whisper is and side channel attacks and power differential analysis stuff. But first, we have lightning round, where we ask you short questions. Short answers are desired, but not required. And if we are behaving ourselves, we won't ask you why and how,

and are you sure you've never touched a penguin? No comment. Christopher, do you want to go first? Have you ever touched a penguin? I cannot disclose. Oh, is it a federal crime in Canada too? Could be. I don't know, actually. Let's see. What is the most money you've ever won in a technically oriented contest?

Probably the Hackaday Prize. I believe, right? Should be on cue. But you didn't... No, I didn't win, but I won in it, I think, $10,000 US. Which is three Canadian dinars. Yeah, but it's Canada, right? It's an amazing amount of money. What is the safest computer? Ooh, I don't know, actually. Probably something Linux-ux based of course i was thinking casing concrete and something at the bottom oh yeah okay yeah i was trying to think physically

too right like there's really tough books type computers oh yeah what is the longest you've gone without seeing the sun probably probably a day i thought you lived like wild north canada now we we're not far enough that it it goes away fully so it gets short but it's not that bad yeah it's a great white north not the yeah that the yeah the sunless, trackless woods. I lived in Scotland, actually, for almost two years. And there, I went on a camping trip. I did the opposite problem. I went camping in the summer, which sounds great until you realize at 4 a.m. It's light. It's very light.

If you could only do one, running a business, being a professor or being a graduate student? Probably running a business. Like the uncertainty. Yeah. This is my life is figuring out that, that answer. So that's why you're here on this show. We're going to answer in real questions here. Do the men in black ever follow you around town?

No. Not that I've noticed. Complete one project or start a dozen? I like this one because there's no way I cannot answer start a dozen. Have we ever had anybody answer complete one project? Yes. I remember Robin Sloan was like, you just complete projects. It doesn't matter how badly or how quickly or anything like that.

You just complete them. Well, that's why he's a bestselling author and I'm an obscure podcast co-host. Hacker, freaker, pen tester, or security researcher? As a title or as a thing? As terms you prefer. Okay okay i don't know maybe maker or security researcher okay well let's get into the actual show we could do lightning round all day uh let's see so chip whisperer i saw this in the first hackaday prize when I was a judge, and I was just like, this seems like the end of the world. I'm not really sure this is a good idea. Can you give that same impression to everyone listening? Do you mean what it does or what my thoughts are on the end of the world?

Let's start with what it does or what my thoughts are on the end of the world? Let's start with what it does. Let's start, yeah. Okay. So, Chip Whisperer, basically, like the backstory to this, actually, really why I started it is that I mentioned I, you know, worked at Atmel for a bit doing IoT-ish stuff. And there was one time working on some standardization work. We were talking about security and literally it's like a table, you know, a bunch of engineers sitting around the table and kind of just talking security threats. And someone brought up power analysis, which I'd never heard of before in my life. And they explained it to me really briefly. And I was just like, oh, no way that does not work.

Like, that's crazy. No one would do that attack. That's dumb. You know, that was sort of what I thought about it. And that was about it. So eventually I went back to school, and that's when I spun into seeing how these attacks work. And so basically power analysis lets you recover encryption keys from otherwise perfectly secure algorithms like AES and stuff. While the device is operating. And the crazy thing to me is this was published in 1999, right? So it's like 20 years old now that this has been happening, but people still don't know about it.

And that was the whole point of Chip Whisperer is, you know, I didn't believe that it was possible when I first heard about it. And until you like, you know, hold it in your hand and do the actual attack, it's, yeah, it's difficult to like to understand how easily it works. And so that was really the point of it was to, you know, show people it is possible. So ChipWhisper is this platform that lets you perform the attack, as well as doing something called fault injection. So you can corrupt internal states to cause computers to perform incorrect operations or validate a signature when it shouldn't have validated it. So yeah, fundamentally, it does break a lot of security assumptions, but most of them have been broken for the past 20 years publicly. Okay, so power analysis.

I'm going to explain it and then you're going to explain it correctly. My understanding is that when you are running your algorithm, say AES, some security algorithm, you have your key and your key nobody knows except for the people who are privileged to know it, your secret key. And then you have some data that comes in. And you can inject the data to be whatever you want. It could be all zeros, it could be all ones. But as somebody who is saying, please authenticate my key, you get to choose that. And then you look at the power that it consumes for the decryption algorithm, the AES decryption algorithm. And by looking at the power, little tiny amounts of current, little tiny amounts of voltage shift, you can figure out the secret key inside the chip. Is that what now now you explain yeah no no that's

that's actually basically it you know next question um no but so the the real the way it works um fundamentally is that inside the chip and this is the part that seems crazy is that if you think about like a data bus and a chip you you know, setting, sending FF across that data bus, you're setting, you know, eight data bus lines to a one state, and it takes more power off of a power rail than to set them, you know, to not change the state. Or if you're just measuring the positive power to set them all to zero. So there's kind of this model that the number of ones going across the data bus or the hamming weight is related to the power consumption on like every clock cycle. So you're looking on very, very small instantaneous measurements.

And so as you said, with power analysis, basically the data being fed in, if I know the data being fed in, let's the data being fed in let's assume so i'm sending it some encrypted data that it's going to try to decrypt it might fail because it's garbage but as part of trying to decrypt it it's going to take that data manipulate it with the secret key that i don't know and put it over the data bus and because i'm measuring the power i can know basically how many bits are set high after that operation has occurred. And by knowing how many bits are set high, there's only so many possibilities for each byte of the secret key. And so you can sort of recover the secret key in this iterative process by saying, you know, if I sent in hex AE and I see, you know, zero ones go across the data bus

and the first step it does is it XORs the input with the secret key. Well, the only way that could happen is if that secret key itself was also AE. So there's sort of basically operations like that, that the attack is doing. And I sometimes can barely measure what I'm looking for in my 1.8 voltage signals. But this has to be tiny. I mean, this is A, kind of inside the chip, and B, tiny, tiny amounts of voltage. I mean, this is just one bit. It's doing other stuff. Yeah. So, and that's what always, you know, seems the crazy part. But the nice thing is that

everything that we're measuring that's unrelated to this operation is basically a random, like, white noise. So, we just take a lot of measurements. If it's a simple device and running software AES algorithm, we might only have to take like 20 or 30 power measurements to get enough data to do this. But if it's a hardware device or it's a multi-core processor, it could be 10,000, it could be a million power waveforms that you have to measure this to actually, you know, get enough information out of that really noisy power trace. How long does it take to do one of these power traces? Basically, as long as it takes to run the encryption. So if it's like a little, you know, arm doing some bootloader decrypt, maybe you could capture 100 or 1,000 power traces

over the course of a few minutes. It could be even faster than that. But if it's some really slow device or the process of actually collecting the power trace requires you to reboot the device and that takes a while, it could be a lot slower. So that's sort of where your limitation comes in. Okay, so I have a chip whisperer and I have a device I bought off the shelf at Target.

After I take apart the device that I bought and I power the chip whisperer, what are the intervening steps before I have the key? Yeah, so it's like, how do you draw an owl? It's not just like step one, draw a circle. Step two, draw an owl. Yeah, so there's a lot in between. And this is one of the things. So, you know, these types of attacks are more advanced attacks because, like, we're breaking crypto and doing all this stuff.

But you need to know a fair amount about the device. So, for example, if I was attacking something like that, I would need to know, okay, it's loading from spy flash hanging off the device. It's loading the firmware image on boot. And that firmware image is encrypted. And I'm pretty confident it's AES, you know, in maybe CBC mode or something like that. And that's sort of the level of detail, you know, because what you would have to do in this example is you have the device and let's say we're trying to break the encryption as it's booting. You'd have to be basically

resetting it to cause it to continuously reload that firmware image. And then you're measuring the power consumption as it's actually doing the decryption operation itself. But I can read the spy flash, so I know the bytes it's trying to decrypt. Exactly. And then I can use the chip whisperer to read the power analysis. And then, I mean, there's more software you have. It isn't just reading the power analysis. It's doing that correlation.

And in the end, it's going to spit out a key, right? Yeah, that's what you where the research heavy side comes in, is that if they're just doing straight decrypting with AES in some standard mode, then it's pretty easy. And the nice thing is the algorithm gives you a confidence on how likely it is that it found a key that was actually performing that operation. But normally what happens, right, is like they're using a more complicated mode of AES or it's not really clear when the decryption happens, let's say, right? Because maybe they read a whole page at once and decrypt that page after they've already read, you know, the thousand bytes or whatever the page size is. So it's really like where you need to be is you need to be at the point that i know the algorithm or i'm you know confident of which which it is of a

few options i know when it's running and i know either the input or output data to that algorithm you have to know a lot you're not just walking up to something and cracking it. Waving a wand over it. This is not a movie action. When Tom Cruise plays you, he's going to have to do more than just a little typing. Yeah, he'll have to gain some weight first, but then he'll definitely have to... That's the thing, like people think it's going to be this magic, this magic attack. And so we run, you know, I've done training and stuff like that too. And I try to be pretty careful in like the description to make it clear that like, you know, this isn't going to be

connect the thing and hit the button and get the key. It's a lot closer to that than is comfortable for me uh as as an embedded software engineer who has worked on things that really shouldn't be cracked uh how do i make your job harder um yeah so it's the number one thing that i tell people with you know how do you do countermeasures so first there are countermeasures? So first there are countermeasures to this, right? So there's like, there's devices that have countermeasures against side channel attacks and you can do crazy stuff. Like, you know, when I talked about setting a data bit bus high or low, is the voltage going to one or zero? Well, if your data bus was differential,

then all of a sudden this becomes more difficult because when one bit's going high another bit's always going low in practice the issue with that is it costs more right in terms of chip area in practice it's not perfect because it's hard to balance that as well as you need without having any leakage and you can also get glitches where one bit goes high a little bit sooner than the falling side goes low. But there are devices, if you really care, like your credit card, for example, has devices that have these physical layer countermeasures. At the sort of IoT more general level, it's coming. There's been devices that have been starting to do some of that. But the best thing is still just to avoid key reuse, right? Because the number one problem

is that if I, you know, buy that one IoT device from Target and hack it and recover the key, that now lets me see every other, you know, maybe be able to flash firmware on the device and I could flash firmware on any of their other devices, then that's, you know, less good. See, that's the real best way to avoid the problems is to just not have the sensitive information in your system in the first place. What about from the algorithm side? You've mentioned AES, and that's a very common one. Is there any other algorithms that are more resistant? It's difficult.

So, I mean, asymmetric crypto is more difficult often, like especially with ECC, to do these attacks on. They're still very possible, but it's, you know, there's a lot more variables involved, basically, in some of the attacks, especially on, like, a lot of ARM implementations of it. Of course, you want, like,

if you're talking about firmware or something, you typically want fast, so you don't want those slower algorithms. There is, there's been a few things I've seen lately, actually. So NXP's new, I think it's like the LPC55S66 or 69. They have this interesting mode. So what they've done is they've made up their own mode effectively of AES, which always doesn't sound like a good idea.

But they do something, so they call it index code block mode, and there's a separate white paper, and they call it leakage resistant crypto primitives. But the basic idea is that when you're running the AES algorithm, you take your initial key, and from that key, you derive sort of like a random stream of keys and you use different keys for every AES operation effectively with some other stuff worked in the middle of it. But in theory, it makes it a lot more difficult to do these types of attacks because now we have different keys in use because, you you know when I was talking before how we had to average a lot of traces and do various stuff you know that all assumed it was always the same key operating yeah because having multiple keys is hard and even having multiple keys across different devices is a I mean that's a manufacturing

nightmare a lot of people do it because you need it but it makes it so that every device has to have its own key and so you have to remember all the keys you have to make firmware for each device which means you have some little widget out there cranking its little heart out making firmware specific and then yeah this it's hard yeah i mean right it should keep you in business for a while because you now have new problems to solve that's the that's the good thing how much physical access and contact do you need to make this work? Do you have to physically attach to the MCU? Yeah, so the best way, you know, what I'm mostly looking at is where there is total physical access. There's quite a bit of work and demonstrations to doing very close physical access where you use an electromagnetic

probe. So the changing current gives you a changing magnetic field, which you can also pick up and do the same sort of attack. And there has been a little bit of work on remote. So basically, if the device itself has some sensor you can access, like an ADC connected to the internal power supply, or there's been some work on FPGAs where like a ring oscillator or something running on the FPGA actually lets you remotely measure the power on the device. It's theoretically possible to do some of this stuff even remotely. And so measuring the power, I thought we had to plug into the chip's power. But it sounds like I can just plug into the chips power. Can I,

but it sounds like I can just plug into it. It's a wall war. Is that enough? Well, so we really, you do need the chips power for what I'm talking about. So it is, it is that like,

we're still, you know, if we're doing remote, it would be like something else running in a separate process on that exact chip. Okay. Right. So it's like, I mean, the, the, the kind of idea of this, right,

is like there's devices with trust zone and stuff where you have a trusted application alongside untrusted. So can the untrusted application make calls into trust zone where it's running crypto, but at the same time, the untrusted application can be measuring power and stuff like that on the device itself. When you say side channel power analysis and differential power analysis, are these the same things or are these different? Yeah. So the differential power analysis, there's like a whole bunch of names for all this stuff. So side channel power analysis is the general field of it. Within it, it was originally kind of split into differential power analysis,

which was just looking at power consumption related, mostly related to data being manipulated. So this is doing the type of attack I was just describing where you send the input, you correlate it. There was another type of power analysis, simple power analysis, where you were looking at program flow. So for some RSA implementations, it actually did different operations depending if the key bit was one or zero. So simple power analysis is nice because you don't need super high resolution. You're just kind of seeing general program flow. Since then, the problem is that other forms of power analysis have been called other names as well. And people will refer to differential power analysis, DPA, to sometimes mean the very original version published in 1999.

Sometimes they mean the general field of power analysis. So you never fully know is what I've sort of discovered. And so you just call them side tunnel power analysis and it covers everything? Yeah, that's the safest, right? That covers everything. That's tip number one. And we've picked on AES and now you've picked on RSA and I believe DES. Are there any algorithms that work? You mean that don't have this problem? Yeah.

Yeah. So there's some of the newer stream ciphers, and I don't know actually as much about those ones, have been designed, you know, because this has been known. So people are starting to think about designing it into the algorithm itself. Nothing in wide usage is what I would say, though, you know, that you can get a hardware accelerated peripheral for, let's say, on a micro. Okay, so we need the microprocessor hardware to support defending against this attack yeah exactly are there is there anything my software can do yes and there is i mean you know i maybe shouldn't be so pessimistic um there is software counter

measures um and so a popular one is called masking, where what you can do, right, is you could XOR in. So when you send the input data to the algorithm, why don't we XOR random data with that input, and then modify our algorithm slightly such that at the output, I can basically XOR a constant that's been, or that random data has been processed by like a parallel version of the algorithm and it removes the effect of the mask. So when it was doing the secret key operation, it actually wasn't using the input data. So now the attacker can't do their attack. As it turns out though though because this is a linear operation the basic way the attacker works is they then perform a power analysis on two points of time at once and it removes the effect of the mask so you can do the power analysis attack um pretty effectively even against that countermeasure and and there's a lot of like of this, so there's kind of an ongoing game of changes. Spy versus spy, cat versus mouse?

Yeah, exactly. What if I just accepted going really slow, and I do, okay, I'm going to do eight bytes of decoding, and then I'm going to go off for a million cycles and calculate a few digits of pi, and then randomly come back after some number of those and do another few bytes of, I mean, can you, would that defeat it by just being lost in the noise of doing some other operations? Or is that similar to what you're saying with the XOR? It could.

I mean, so the issue with that is that you can see from the power trace when stuff is happening. So if you just put random jitter, like if you you do random jitter that's a common countermeasure it doesn't do a lot because you can figure out where those same operations occurred um people will do dummy rounds often right so if you took aes like you take your 10 rounds if you do 20 rounds or however many and you randomly decide if you're operating on the correct state matrix or not, it's going to improve things. The problem with all of these is like, you know, if you basically average enough of these together, will enough correct operations line up? And when you're talking you're doing them one a second then it would take a long time but if you're doing 10 000 operations in 30 seconds the averages are that's why i'm saying slow way down

well this i mean so all the countermeasures are trade-offs right so if you don't need speed and especially code size um if code size isn't a huge constraint then there are you know things people have done like that so this aes mode i mentioned that the nxp chip decided to support um if you use it i forget how much slower it is but you know it's at least a few times slower if not more um so if you're trying to do some real-time stuff right that could That could be an issue. Isn't this all just obfuscating the core algorithm? I mean, are we just getting security through obfuscation? Because I heard you weren't supposed to do that. Yeah. I mean, so there's kind of two answers, right? Like, definitely it's not a good idea.

But these countermeasures are, you know, they're basically fundamentally trying to prevent the attack from working, even if, or to make it more complicated. The idea is that if I know, for example, I can change my encryption key after 100,000 encryption operations, and I can make the algorithm such that it takes an attacker a million power traces to break one key, then that's pretty good, right? Like if the best case attack still took a million traces, and I only ever need to survive for 100,000 encryptions, because I know after 100,000, the device can be dead or change the key. That's sort of where a lot of this falls, you know, what these levels fall into place as. And so security remains something that you just have to make it harder than people are willing to work.

Yeah, I mean, that's exactly it, right? This is, and this is part of the thing is you could, you know, you could you know you could say we're going to make this super secure against everything um but all of a sudden there's some other easy attack or they're going to do some other you know attack on on the device to recover this information that's the way it goes too right because i remember oh god it was that long ago some time ago i was working on a product an undisclosed amount of time ago i had an 8051 and i had an e-prom uh that you could blow the fuses on and had a key in it and it was for securing uh securing uh consumables against counterfeiting and one of the arguments

one of the technical managers made well you know made, well, you know, this is pretty secure. You know, it costs millions of dollars for somebody to decap chips and be able to look at them and to read out the... It was a while ago. You know, people are doing it on YouTube for fun. So, yeah, things change. Yeah. Well, actually, it's interesting, too. The older stuff reminds me. I had an interesting project where I was trying to recover firmware from some old like 8751 devices.

And the reason that was happening is it was a, yeah, like a government had these devices that they needed spares built up. But all they had were PCB, like all they had were working ones. They didn't have any of the firmware design files for some reason. Jeez. And so, like, right. And it was old stuff for, you know, things that needed to be duplicated. So it's also sort of interesting, like some of the use cases that come up out of this stuff. Yeah, some of the use cases.

That's a very positive use case. But does it worry you that you are making the world less secure? I mean, Chip Whisperer makes it a lot easier to do these attacks, and you have really, truly excellent tutorials for breaking the encryption using side-channel power analysis. Do you ever worry that you're on the wrong side? the encryption using side channel power analysis. Are you, do you ever worry that you're on the wrong side? Are we the baddies? Yeah, are we the baddies? I don't know. So it's an interesting question, right? And the best I can do is that we put a lot of effort into making our use case a lot easier for when people are on the design side so

it's one of the reasons like all of our work is done on our own target boards where it's like a microcontroller with a shunt resistor in it and stuff like that because it's really good if you're designing something and you say i want to run you know you know, this, my own bootloader, I want to see how bad it is against side channel. Um, and the tools are really optimized for that use case. Um, and that's kind of what we do. We also, there's a few things we've never made on purpose. So I get requests sometimes for like a smart card interface type thing, right? And which would be good because there's a lot of research that's done on smart cards. There's even some SIM cards you can get where it's like they're programmed specifically for research. But the issue is, right, you could also, someone could be using that for a credit card fraud. And the way I want things to operate for me is I really want stuff to be open and easily available.

And so those kind of become at opposite ends, right? Because if you have everything open and anyone can buy it, right, on the negative side, anyone can buy it. So there's some stuff that just isn't worth doing. But you've still made it easy enough. I mean, you don't make a smart card target board, but your target boards looked relatively easy to understand. If I wanted to make a smart card target board, it didn't look, I mean, it didn't look taxing, really. Yeah, yeah.

So, I mean, the thing is, right, the flip side, a lot of this design stuff has been out there. Like, the attacks have been known for a while and people have been using them for, especially in government and stuff, I'm sure, but they've been a threat for a while. And it was always going to be, I felt like there was always going to be this awkward phase, right?

Again, I'm going to use positive euphemisms right now. And this awkward phase where the tools become accessible before some of the manufacturers and generic IoT devices have caught up with what should be the real level of security. Well, I think another way to look at it is it's not like you're the only one doing this, right? It's not like you invented the only one doing this, right? It's not like you invented... You made it easier. Yeah, but like he said, it had been talked about since 99. Bad actors have had this. You know, people who want to do bad things,

and it's been hard for people to, as he says, test their own equipment, maybe find countermeasures because it's, it was prohibitive and expensive and only the bad actors had it. I mean, that's one way to look at it, I guess, is if you make it easier for people to buy, you kind of take some of the wind out of the sails of the bad actors who are the only ones who have it. It's the, if everyone had a gun argument in some sense, which isn't necessarily great, but. That was always, if there's ever like a really negative publicity, I always wonder, like, do I go to the gun lobby? Yeah.

Try to use them as, align with them. It's, yeah. Well, I mean, one of the reasons I wanted to talk to Colin about this is because I do trust that he does this for ethical reasons and that he can communicate them. But it's a tough line. I mean, yeah, sure. Having design engineers understand this attack and be able to truly understand it in a way that they have their hands on it and can try it. It's amazing how much more real it becomes when you try it. But I still don't feel like our countermeasures are well in place.

And that makes it tough. And seeing it available and letting other people try it for funsies when they may not stay for funsies, it is a little scary. It's a little scary to support that. Of course, you could say, well, if we teach people to program, they'll be able to do this. And so it never really stops. You can't prevent everything as much as you might want to. And for this, you might not want to. It's a scary road. It's also the, hey, this is real. People might not have paid much attention to it until there was a cheap and easy way to do it. Oh, this is

actually a problem. Maybe I should think about it. Until I saw it on Hackaday, I had no idea. Yeah. I mean, and that's like going back to, you know, what you were talking about earlier about stuff, the decapping rate, for example, people doing it for fun on YouTube now. One of the reasons I really wanted to push it is because when we were doing some of the standardization stuff, you know, with IoT, maybe not consumer IoT is a bad example, but for embedded, right? A lot of this stuff is going to be around in 10 or maybe even 20 years. So, like, what's impossible to unreasonable to do now, is that still going to be the case? And, like, are these devices still going to be connected?

Sadly, these devices will still be connected. And what is unreasonable now will be trivial then. Thank you, Mr. Moore. Yeah. I blame him anyway. It's fallen off. Okay, so you were getting a master's degree and and PhD. And then suddenly you were a finalist in the first Hackaday Prize and you were starting a business. How accidental was that?

That's a good question. I mean, really for me, right, the open source project was fun. And that was kind of where it started was like, okay'll just push this out open and what i pretty quickly discovered right is i would sometimes take a few pcbs to conferences people would sort of look at them be like oh that's great but i just want to buy a a finished one like you know it's great it's open and they can modify it but they just wanted to buy it yeah i don't want it's lovely that your board is open yeah i'm not doing it doing it. Just charge me, okay? Money is so much cheaper than time. it was pretty expensive to build but you know physically i built the first like 10 myself um that we sold and then from there it was clear that you know i mean it wasn't clear that there was going to be a huge demand for it but there'd be some demand so that's when the kickstarter

was able to launch um with the chip whisperer light there was sort of enough at that point that it said you know what this this could probably be something we do. And I didn't really expect, like, we've moved pretty slow because I, you know, part of me expected this to just be a one-off type thing and not continue to the extent it did. Yeah, after you finish your graduate project, it's supposed to go get dusty in a library somewhere. You're not supposed to continue it. Yeah, right. That's, I mean, it was fun doing this as the PhD as well was fun because like you get a lot of time and flexibility, right?

So I think it was a lot of luck that many things aligned to push me how it did, right? That I had time, I had good timing, like cybersecurity was becoming more interesting. So I think more people wanted to get involved in this, right? There's like a lot of sort of maker type stuff in the last 10 years that 15 years ago would have been more difficult. Yeah, I really attribute a lot of it to that sort of lucky timing as well. And so, what did you get your PhD in? I can't imagine your dissertation was titled Chip Whisperer, an open source guide to hacking everything. You know, it was actually not that

far off. I can't remember my title right now, but it was basically something along the lines of like uh what's it called a framework for embedded hardware security analysis all right so that's the academic version of what you just said basically okay so was was your dissertation mostly chip whisper and how it works? Because this seems like cheating. It's like turning homework into locations. Yeah, well, so there's a few types of PhDs that different institutions do. One of them is the golden staple version, you call it, which is something like mine,

where you take basically like a few papers that you've written that have been published somewhere and you massage them to make one you know cohesive unit and you put a nice intro and conclusion and references and that's sort of your phd so that's roughly how mine worked um so parts of it are about Chibwhisperer, parts of it are about some specific work I did on new types of attacks. But basically, yes, is the answer to your question. Cool. And now you've taken your fun side project and made a business out of it. Was that a good idea? You know, I'm still finding out maybe if it's a good idea or not but it's i think it's

it's interesting right it definitely uh it's nice to have more time you know to dedicate to it um the most interesting thing for me about doing that though has been meeting you know especially with the open source uh meeting people that have used it and like kind of them saying like, oh, you know, this totally changed how we were structuring some of our security plans, basically, because we could see the attack work. And for me, that's probably what makes it the most, you know, the reason I continue to do it, let's say. You're also a professor, though. Yes. So I also wanted to experiment with more, I don't know if you call it official research, but continuing the academic research side. And there's a lot you can do right under academic research that would be hard to do commercially, even if it's your own company, just in terms of having to pay people and stuff like that. So that's kind of why I also spun back into the academic life,

is to try to keep the real core research side alive. Do you teach too? Yeah. So actually, I just got, to a course in communication networks and another course, uh, kind of computer networking. So two related courses, um, which were a cover for someone else that's on sabbatical. I will be doing a cybersecurity course. Is it going to be more formal than your online tutorial courses? And so this will be an electrical engineering course. The idea is to, you know, get people going through the program, seeing this right in university to cover both, you know, specifically side channel and fault injection, but also to talk about other considerations around embedded security and secure design and whatnot. But Andrea from the Great White North tells me that you have a book coming out in 2020 on breaking embedded system security. Is that true? It should be true. So I'm Jasper co-author and I were actually we're supposed to have a call earlier, but I missed it.

I think it's been coming out for a few years, to be honest. So going back to the start 12 projects or finish one, you know, that's, yeah, 2020 seems realistic. It's mostly done now and we're mostly just editing. Do you hate me? Why are you making my job this much harder? Make it easier. Is he? Is he really? In the long term. Yeah. I mean, you know, it gives you more work. I don't need any more work. Yeah.

You don't plan on retiring soon, right? This is... No, I'm going to retire any minute now. I'm waiting for that 2036 bug to come around. And I'm only going to work for 2036. Yeah. Let's see. Andre also had another question, which i don't understand uh do you know the hot dog vendor down at halifax's farmer's market and are his stories true

so the the first answer to that is yes oh my god i thought you just made that up i mean this is halifax right so actually the uh i don't it probably wouldn't have made the news anywhere else but there are some guys from nova scotia and they got stopped at the u.s canadian border because and they had a whole bunch of gasoline cans in their car they had like 20 cans of gas. Um, and they just drove there and stopped in the middle of the road. Um, and there's this big standoff and it turns out they were trying to like sneak into the U S and drive to Mexico for some reason. And they were trying to sneak across and they ended up at like the biggest border crossing around. That's not the usual way things go, but okay.

Yeah. Right. So it's, it's like very trailer park boys in real life. Anyway, back to the hot dog yeah no i know so he actually does security research so the hot dog vendor well he did other stuff before but then he in the summer he just likes running a hot dog stand did i take an allergy pill or was it something else no he just does do what you love type thing so he he likes it likes chatting to people now he's always doing interesting stuff so I'll see him there's a big security conference here

that in next week or the week after and I'm sure I'll see him again there too but yeah so it's not as crazy as a question as you think have you tried a differential power analysis on his hot dog cart yeah

see what he's hiding on his hot dog cart? Yeah. See what he's hiding. Are his hot dogs bugged? Yeah. They're good. I don't know. That's all. As far as I know, they're safe.

That was so much weirder than I expected. But moving along. One of the things with the Chip Whisperer, or with the Chip Whispererer light is that it had an FPGA on it that you could program. Am I recalling that correctly? Yeah. So it, the FPGA basically was, people could program it, but it wasn't designed to be used as part of the testing. Okay. But you do do a lot of FPGA programming. Unfortunately, yes. Because a lot of this analysis that you do, it makes sense to do it in parallel. Yeah.

Not so much on the analysis side. A lot of it is more the generating the right waveforms and triggering and stuff like that. You really need an FPGA for the timing. And you wrote for Circuit Cellar Inc., programmable logic in practice, experimenting with metastability and multiple clocks on FPGAs. Could you summarize? Yeah, so what that article was about, if you see, you know, if you talk about FPGAs, there's always this issue with

clocks and making sure you're meeting timing and stuff like that. And so I basically wanted to see what happens when you don't and what does that really cause. And what I ended up doing is I made a little test where you had like a phase shifted clock and you were basically shifting in data to the flip flops in the FPGA at the wrong time. So like right at the clock edge, right when you shouldn't be changing the data. And it's sort of interesting because you can actually see what happens is it takes quite a while for the output to stabilize. And you can see when you, you know, create these timing errors, it's not just that the wrong data gets loaded or something like that, but it actually like propagates these invalid conditions further into the design. So it's sort of, you know, you'll, you have all these

rules and rules of thumbs that people tell you in engineering. Um, and a lot of the time it's fun to validate them and see what actually happens. Somebody wants to get started with FPGAs. It doesn't sound like this is the place to start, but do you have a good, uh a good path for people that want to learn more about FPGAs? I don't know, because I probably didn't take the best path, which was just a lot of playing around. There's better stuff now, too, right? So there was a good resource, I think fpga4fun.com, that had a bunch of different examples on it I had used. There was a number of good books, but now you have stuff like Tiny FPGA is a pretty interesting project for getting into FPGAs.

There's also some cool high-level design languages. So you can actually program FPGAs in C and Python and some other high-level languages, which actually makes it pretty easy to do some of this work. The only strong caveat... Are you sure? That seems weird. Well, so here's the problem, right? Is that if you know FPGA design and you use these tools, they make a lot of sense because you can do stuff like, let's do fixed point addition. And the tools will actually generate the FPGA code to do the fixed point addition and to handle issues like out of range. Do you overflow? Do you peg to the limit? You can choose all of that automatically. So you can make really fast

algorithms. The problem with all of those tools is that if you just go from a software background and use them, you know, you're not writing software. You're using C to describe what physical logic blocks I'd like this tool to generate for me. So the tools are really good with that strong caveat that I give people that, you know, you should still do quite a bit of low level, let's call it FPGA work to understand what the tools are going to actually output. One of the difficult parts for me as a software engineer with FPGA is I usually write things to happen serially. Even when I am working with multiple processes or multiple chips, multiple threads, whatever,

everything is happening one at a time. FPGAs, that's not how that works. Yeah. It took a while to get used to the FPGA design stuff when I first started as well. But when I run Python on FPGA, is that... Well, I think the syntax... It's just syntax. It all reminds me of System C,

which was a thing I first heard about in the late 90s. It's basically, hey, let's do C and C++ instead of VHDL. But it doesn't look like C and C++. It's got all these blocks that are, okay, this thing and this thing, and they're concurrent. So I'm assuming the Python kind of thing is the same deal, where you've got this and this, and it it's like vhdl or verilog and that it's describing concurrent processes yeah exactly so there's like special decorators so you can make different functions that run at

the same time and stuff like that um you know and all it's doing is synthesizing it to verilog or vhdl code that then you feed in onward. Because the idea is if you think about it, you could describe a block as a Python function. And the one I've used the most actually is Xilinx's Vivido has a C to whatever Verilog generator in it, let's call it. And it just defines a standard port structure. So when you return the function, there's like, you know, the whatever, say you had an 8-bit register output, and there's a flag that said data is now valid. So you could sort of like chain together a whole bunch of these functions to accomplish

something pretty complicated pretty quickly. And the really cool thing is that both of them, so like the Python one and also the C, you can compile and run the code as well. And because it's object-oriented, so it has special classes that sort of simulate how the FPGA will implement stuff, now your design cycles are so much faster because you're just doing it with a compiler and not having to use like an FPGA simulator.

That sounds really cool. I feel like we could have a whole show about that. But we are almost out of time for this show. And we have a couple more things to talk about. First, you have a company, as we mentioned, despite your assistant professorship and multiple things you do, you are CTO of New AE Technology, and they are hiring. What are you hiring for? Yeah, so actually we're sort of always looking, especially if people are in Canada, you know, especially if they're in Halifax, I don't know how many listeners are going to be in Halifax for here, hopefully a few.

We're sort of always looking for someone with strong embedded skill set. And, you know, we have this very generic job description that sounds like 10 different people are needed for one job it really did i mean electrical engineering and web programming those are not always found with the same person no and that's the thing so it's you know because we're small we um we have a lot of different projects on the go from new hardware designs we're working on, from, you know, trying to support customers. So one of the things we've had a lot of issues with is just having enough resources to support customers, you know, so that if they have questions or stuff like that, to make sure we can answer them. And that's where it kind of comes across this broad, you know, cross section. It's hard for us. We couldn't really just hire one person full time to do that. But if we had someone with quite a few different skills, you know, so embedded C is always needed. Hardware design is good. If someone is really good with embedded C but also knows some Python or web stuff too, then great. That could be one position.

So you need a jack of all trades, but you're willing to choose. Exactly. If the person's good. Cool. That's what it is. And that's why we have this generic one. So if someone's interested in this area, this embedded security, and has some of these skills, then definitely get in touch. If somebody has some of these skills and wants to become an expert in security.

Yeah, ideally willing to, I don't know, if they're willing to move to Halifax. We've done a bit of remote, but it's been harder to manage that, I've found. So we would prefer local, I think, is what it comes down to. All right. All right. So if you are in Halifax, you should contact Colin. And there was a contact sheet on your website, and that will be in the show notes. All right. And let's see, there was one more thing.

For people who have made it this far and are still excited about Chip Whisperer. You're going to let me give one away? Chip Whisperer Lite? We can give two away. We can up the stakes. Okay. Let's see. Do you want to do guess a number or guess an animal?

Let's do guess a number. seems like more definite yeah because then if you choose the pangolin nobody except they all know me and they they probably would choose it all right um yeah because then what's closest with the animal right that's my question is it like weight is it attributes no we would use proper linnaean taxonomy taxonomy all right taxonomy i'm sorry i asked i didn't realize that would be so easy actually it wouldn't be okay okay uh do you have any hints about your numbers are they rational are they irrational are they named Are they less than 4 billion? Yeah, let's do 16-bit numbers. Let's say that. Okay.

How about that? Signed or unsigned? Hex. Hex. All right..fm. And I will, will have, have the results for you by May 1st. So send those numbers in real soon. And then we will,

we will give Colin your email address and you can sort out how to get your chip whisperer light. Sound okay? Yeah. Great. Thanks. Do you have any, well, thank you. I'm how to get your chip whisperer light. Sound okay? Yeah, great. Thanks. Do you have any, well, thank you. I'm excited to give away things. Do you have any thoughts you'd like to leave us with? Yeah, so, I mean, really, you know,

hopefully the crux of the question around ethics and all this stuff, to me, the interesting thing I've been thinking about a lot is that, you know, as engineers designing stuff, safety has always been really important. And what I think is going to be big, or if not already big, is also thinking about security in a similar vein. And this is where it's nice to see a lot of push towards security and embedded systems. But anyone designing stuff really should understand, you know, what are the relevance of these attacks. And I think that's, to me, the most important part of anyone doing design that, you know, requires secure systems. As G.I. Joe says, knowing is half the battle.

A much more memorable way of saying that, right? Our guest has been Colin O'Flynn, CTO of New AE Technology and Assistant Professor at Dalhousie University. If you want to know more about this side channel power analysis, he's got a great video on his website. There will be linked to that video, his website, the jobs, whatever, all the stuff's on our website, which is embedded.fm. Thank you for being with us, Colin. No, thanks very much for having me on. And thanks to everyone for listening to me ramble for the past hour.

It was a group effort. You made it. Thank you also to Christopher for producing and co-hosting. And you can always contact us at show at embedded.fm or hit the contact link on the embedded.fm website. Now a quote to leave you with, this one from Bob Ross. We put some dark in, only so our light will show. You have to have dark in order to show light.

Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. If there are advertisements in the show, we did not put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.