 Good morning, everyone. Hopefully, you're here for the same reason I am to drink coffee. I mean, talk about random numbers. This is not the first time that a talk about this particular project has happened at DebConf. In fact, two years ago in Portland, Tom Marble gave a talk about the need for having good sources of entropy and why it was that Keith and I had begun a project to build a good, high-quality hardware random number generator. It so often happens in life. We get a little distracted between then and now. But to sort of jump to the very end, we're to the point where we've finally gotten to a design that we really like. We are in the middle of a initial, significantly sized production run of the devices. Unfortunately, best-laid plans and all that, we had hoped to be here with the production units. And I guess at this point, we're still two or three weeks away from actually being through that first production run. So we have a handful of devices we can show people today. Might even try to demo before we're done. But we don't have huge quantities of them to sell yet, which I'm sorry about. It's a little unfortunate, but that's how things have worked out. So I guess the first thing I would say is if you want more sort of theoretical background on sort of the point of random numbers and why they're important in our computing lives, I would recommend you go back and find the video from the talk that Tom Marvel gave at DevCon from 2014. We don't have the time or the inclination to try and repeat all of that today. This is going to be much more about the actual thing that we've designed and built. But I think a little bit of background is probably worthwhile. The sort of fundamental thing here is that cryptographic security really depends on a robust source of entropy. This is because cryptographic security depends on our ability to have keys that people can't trivially guess and various other things. And entropy is sort of the notion of a source of randomness that can then be applied and taken advantage of in the rest of the system. In Linux systems, our source of entropy is usually this pool that's inside the kernel. And where it gets its entropy from varies. But if you don't have some other explicit source of random numbers on your system, it's coming from things like the timing of key strokes or disk operations or things like that, which are reasonably random. But it's just unfortunately the case that most of the computers that we have and use don't have a robust hardware source of randomness. And lots of other people have worked on this before. Some of the devices that I'm sure some of you in this room have stumbled over things like the entropy key. That was a lovely device. I had one, past tense, unfortunately, because like so many things I don't have any more than I used to have. But those were lovely devices. Unfortunately, they're no longer available in the design, it wasn't open. So there's no straightforward way for us to duplicate that. There are other products that are interesting and have various characteristics that we think are really cool. But for one reason or another, just not quite exactly what we were looking for. So the goals we had were, first and most importantly, we wanted a source of truly random bits. And we'll talk a little bit about what that means and show you some measurements to try and prove that we think we've done the right thing there. Keith and I also really wanted this to be automatically usable in Linux systems. One of the things that the entropy key developers did a great job of was ensuring that those in Debian had easy access to package software that was in the distro that you could just install the right package and you had the pieces you needed to make it all work. And that was really cool. But when we started thinking about the things that we wanted to guarantee and didn't feel the need to guarantee and sort of where the trade-off was in our design, the notion of making it so the Linux kernel, sort of the upstream kernel, could just do the right thing when it discovered that one of these devices was present. Seemed like such a simpler deal and something that would make it much more likely that more people would be able to actually take advantage of this. Because we are who we are, it must be a completely open hardware and software design. And in fact, when we get to the end of the talk and you see where to go find things, Schematics, Printed Circuit Board, artwork, build materials, the complete source coach and all that is available on our website right now. In fact, it has been for a while. We want the device to be secure against software hacks, though. What does this mean? Well, what we've built is a, as Keith will show you in a minute, is a physical device that plugs into USB port. And it has a microcontroller in it that has code running it. When we initially produce the device, we flash that with code. If you want to reflash it later, you can do so anytime you want over USB using utility that's already packaged in a devion. But you have to take the plastic cover off the box and you have to short two holes in the board together in order to enable reflashing. So nobody can sort of randomly spoof your device by from some distance reflashing, you know, the break in your system. They can't just reflash your random number generator with some other code. I guess they could reflash something else with your random number generator code, but that's all getting a little wacky. But our device at least can't just be broken through an attack, a remote attack on the software. And we want it to be as inexpensive as possible because, again, this is all part of believing that the world needs more entropy. And we'd like lots of people to be able to afford and use these. So this is one of those devices where on some level, if you get it right, you could sort of charge an arbitrary amount of money because people who want this want it. But from our perspective, it's really important to have these be as widely available as possible. But the one really big decision we made, and it kind of goes into our thoughts on open hardware, is that we were not trying to protect and make this secure against hardware attacks. Fundamentally, if somebody has physical access to your device, then we're not guaranteeing what happens after that. In particular, as I've already mentioned, if they have physical access, they could reflash it at the very minimum, and they could certainly do other things to it as well. That also means we've not done things to try and dramatically, environmentally harden the device. We don't pot it. We don't do all that quantum stuff that people sometimes do when they're trying to make things secure. In terms of the actual hardware device, two, two and a half years ago, I designed a prototype, and I tried to do something really, really clever in the design of the actual noise source. And as often happens when you try to be a little clever, it didn't quite exactly work right the first time. And for a lot of reasons, having to do with where we were in trying to build a house and all of this, I got distracted and just didn't get back to it for a very long time. Keith picked it up, and all of the hardware work on this since then has been pretty much led by Keith with me and other folks chiming in from time to time. So I'm gonna let Keith talk about the hardware. Okay. Spacebar. Spacebar is always cool. So this is the board that we, this is the device that we built. It's a tiny little board about the size, kind of the size of a USB plug connector. And the board actually was, the design of the board was predicated on the box that I found. When you start actually trying to build hardware it turns out that the hardest thing to do is to find a box. And a lot of people try to build, try to think about, okay, I'm gonna build the device, then I'm gonna find somebody to manufacture an enclosure for me. Well, if you build a million of them, that's pretty plausible. And you look at Buddy Huang's articles on his adventures in getting injection molding for laptop prototypes, right? It was like, okay, so in the 99th iteration of the machine, metal, enclosure or mold, we eventually got the things to work right. I was like, well, that cost about a bazillion dollars. So we found this tiny little enclosure and I thought, okay, how can I get something to fit in this tiny little enclosure? Well, the first design that we did after with the new noise source fitted this size enclosure. And the reason for that is the processor was huge. Look at the size of that processor. It's almost a centimeter on a side. And the funny thing is that's very same processor was advertised, of course, in a much more reasonable, plausible size package. So this package is about four millimeters on a side and you can see it, oh. Now we're back. Okay, here you go, we're back. You can see that processor in the upper right-hand corner there, it's about four millimeters squared. So I was actually able to lay out the board to fit in this tiny little box, which was pretty cool. Because the problem with this box is that it's too wide so if you have two USB connectors in your laptop next to each other, you can't use both of them. That was like, well, that's gonna suck. So I managed to get it to fit in this tiny little box. The other interesting part, of course, is that BDale's design had a really fun noise source, was a little Zener diode, a reverse biocider diode. And then, of course, BDale being an actual electrical engineer, unlike me, designed an amplifier with a transistor. And I looked at that and said, oh, transistor, scary. Because, yeah, I really did. Getting a transistor to operate in linear mode, I understand it's theoretically possible. But my training in college with electrical circuits was a single physics lab that involved op-amps. So I know how to do op-amp stuff. So I replaced his awesome transistor amplifier with an op-amp because that's what I'm capable of understanding. Because I'm a wimp. You know, it's the software engineer trying to play it hardware. So there's an op-amp here. It's kind of in between the two holes. That's that thing right there. And then actually in the upper right, in the upper center is the actual noise source, which is a package, a six pin package that actually has two transistors in it up there. And in the lower right corner is actually a 20 volt power supply. So caution, if you open the device up, you could possibly shock yourself with about a milliamp at 20 volts. For prior machine, I think 20 volts Yeah, exactly. So, yeah, it isn't as harmless a device as it looks like. I mean, I wish I could have put like a kilovolt on it to really give you a warning. There we go, physical security can attack you if you're trying to open it. Yeah, and so the box now fits in this tiny little package. The noise generator, we actually lifted from the one RNG, the New Zealand team that's doing a noise source. That was the noise source, I think so, yeah. New Zealand, yeah. Yeah, the New Zealand source. I'm not pretty much a team of those, but it was definitely New Zealand. Yeah, and so the left hand side of the circuit is all just a 20 volt power supply, all those pieces. Yeah, they're back here. And on the right of R3, that's the noise generator. Yeah, it's really just two transistors in the bizarrest circuit you'll ever see. Isn't that awesome? It's actually the left hand transistor that's the noise source, the right hand transistor that's getting a little bit of buffering. So it's really just that connection between the emitter and the base of that transistor. So it's a reverse bias PN junction generating noise and then an emitter follower buffering and amplifying this slightly. And then we run that through a capacitor. So out of that, we get about 10 millivolts of noise and then I run that at an op amp, amplify it and then I run it through an ADC. The awesome part is that when you actually just look at the output of that from the ADC, here's a histogram of values from that. It's like, oh, that's a lovely little, kind of perfect normal distribution of noise bits. And so you can actually see that we're generating fairly nice distribution of values. Of course, this is not what you want if you want a random number, right? If your random numbers are not normally distributed, right? Random numbers are, if you want an evenly distributed random number, you don't want a normal distribution. This is what a plot of about 2,000 points looks like. You just see the, and you can see that it's kind of biased towards the center. However, the good news is that if you just take this data and run it through an FFT, you'll notice that the frequency response is nice and flat or chaotic is the case. Maybe you run chaos through FFT to get chaos out. But it's nice and flat, so we know that we don't have any frequency response problem which we did in the earlier circuit. Yeah, it was the big problem in my original design is that the biasing of the reverse biocener was a little off and as a result, it was very susceptible to low frequency noise. And there was a source of low frequency noise about a millimeter away. So I would have fixed it eventually maybe. I did the cheap thing and applied an awp amp. Yes, and now we have a working product, so it's all good. This is how we work together by the way. We sort of give each other crap until somebody breaks down and spends the time to fix something. Well, the awesome part is that BDAL has been very patient in letting me design hardware. I think this is like the fifth version of the board that I designed. I'm a software guy, right? How do you do software design? You iterate and release early and often. And it's like every iteration takes, instead of 10 minutes, like a software iteration takes two weeks. You have to send it off to the PC board fabrication place and the boards come back and you put parts on and you think, man, that was stupid. Why didn't it hook up that connection backwards? And software, you just go change the software hardware two weeks later and you try again. So I'm slowly learning how to do hardware but I'm still terrible at it. So we built this noise source. We need to make sure it's actually random because if you have something that looks random, you dump it into your computer, it's not actually random and it actually turns out to be predictable, then you kind of lost already. So but there are a bunch of stuff that we've done on this thing. There are some FIP standards which are hilarious. You should read the FIP standards on random numbers. The FIPs 140-2 standard for random numbers literally says, okay, just make sure that the chunk of data that you're sending never repeats. That's the entire standard. That's all that it requires of random numbers is you never reproduce the same value twice. Yeah, don't say four, four, four, four, that's wrong. But four, three, two, one, four, three, two, one, that's perfectly okay. The standard is ridiculous. It's a federal standard. So nobody actually falls to that lowest standard that we're aware of. But the point is that in the standard, there's some discussion about what it means to be random that's not very useful. And there's a bunch of discussion about sort of how do you know that you have a device that's okay to actually use? And some of those bits are sort of useful. Right. In particular, when I first flashed the device during production, they do a bunch of tests on it to make sure that the values are coming out random. I do the FFT tests, I do a bunch of other tests to make sure that the circuit was constructed as we expected. Because one of the big problems with physical hardware is that you don't have perfect replication. And actually the first, I made a bunch of these boards and got a bunch of parts and built them all only to discover that the part supplier did you key. It actually sent me the wrong part for the noise source. I don't know what they sent me, but it wasn't a transistor. Like how? Yeah. It was even the wrong package and I'm still in, I still need to send the wrong thing back to them so that they can close out the final. But it was funny that I built the device, I plugged it in and my production test said, no, that's broken, I'm like, how can it be broken? And I looked at the noise source and I was like, oh, that's not actually generating random numbers at all. So I do a bunch, we do a bunch of production tests which are extensive and make sure the device operates its behavior. When the device powers on, the first time you plug it in we do some testing to make, kind of a little sanity testing. The production test goes on on a source trigger, right? We haven't quite finished it. Yeah. I have some ideas about how it might work. What we do with all of our products though is the turn on and test scripts for them, including the rocket avionics stuff are actually in the source tree. So eventually, once it's all folded in the right place, if you want to- I still have two weeks, right? You still have two weeks. Awesome. Just in time software. Yeah, as with everything else we do, not just the sort of hardware design but how we go about turning them on, what our production test processes and all that is also open. So if people want to look at and provide feedback or comments or suggest something different, we're always welcome to have input. Yeah, I've actually been working with a friend of mine, a professor at Portland State where we had a DEBCON for a couple of years ago. He's got some students off generating some useful tests. There is an interesting random number generator test. I'm trying to remember the name of it. It's a huge, long suite of tests that I've run on this thing and it passes that just fine. It says that there are 7.99, 992 bits of entropy per byte. I don't know why it doesn't think there are eight but I guess getting all the way to eight is hard or something. Random round off there, probably. And then as the device is running it's constantly testing the data that's generating to make sure that it looks pretty random and what we're doing with that is I currently actually do, I just do a make sure that the normal distribution looks like a bell curve. It looks reasonable and it doesn't like spiky or something. I want to do kind of a point FFT to make sure that the frequency it doesn't look like you just have a sine wave which is a common failure mode in the hardware because if the transistor goes Kennywampus then oftentimes you just get, you're just picking up noise from the environment and you get a sine wave out which is not very random. So we do online tests, we do power on tests and then we do production tests. So that's how we're making sure it's random. Can you also mention you're using the CRC generator to whiten or not? Yes, yeah. So as we said with the noise source here the noise right here is normally distributed, right? The values that I'm getting out of the noise source are randomly distributed. What we discovered was that the middle eight bits are completely random and this is as you can see these are 12, about 12 or 13 bits of data coming out so that we get values from zero to 4096 and centered around 2048. So we got how many bits is that? 13 bits, 12 bits, I don't know what it is. 12 bits, yeah. So we have 12 bit values and then distributed around but if you throw away the top bit and you throw it in then the bottom eight bits are really quite flat and we could have just used the bottom eight bits for our noise source and that would have worked very fine. That probably would have worked fine. What I did instead, the chip as with many SOCs has random extra functional units so one of the things that it has is a CRC32 generator in hardware. You dump data in and you pull data out. It's this one instruction and one instruction out. So I take all 16 bits out of the noise value that I read from the ADC and I dump that into the CRC generator and pull eight bits out and because I know that the noise source has at least eight bits of entropy I know that that's a valid thing to do because no matter which eight bits I pull out they're gonna be abandoned. So using that CRC to kind of whiten or flatten the data so that we get truly flat data. This is actually, this of course is a plot from the raw source. And but if you look at the plot from the whiten source it's completely flat and all the values are equally distributed. Randomness which you can get into arguments with people about what's really random but what you seem to really want in the cryptographic world is a uniform distribution of values that are not predictable. So to sort of wrap things up as I already mentioned we have an initial production around of a thousand of these currently underway. It's worth, I've been asked by a couple of people where are we having them built? To explain just briefly the microcontroller chip we chose is one from ST Micros that we've used for some other thing. It has a, it's a tiny little arm, this one's a Cortexon zero, and it has 32K of flash and it has a tiny little inbuilt USB bootloader thingy. So we're actually having these manufactured in Shenzhen in the first run and a lot of folks will go, oh my God, China, you'll let Chinese touch your crypto related stuff. Well the answer is we're not having them flash anything. The board's come to us and we're doing the flash and the production test. So I guess on some level of theoreticalness somebody could be putting different chips in the ones we asked for and spoofing us at a very deep hardware level but I kinda doubt it. And frankly at some point you have to decide where in this sort of chain of importance versus ridiculousness you wanna fall. I certainly don't wanna start with sand and a heat source to make chips. So we think this is a pretty reasonable place because we're not depending on anybody else to put the code in that's in the device when we ship them. And by the way, the reason that we think we meet FIPS level two is that it has to be tamper evident and you have to cut the label to get the box apart and it's almost impossible to cut these labels without just sort of destroying them. So we think it's tamper evident. It's certainly not tamper proof. We do expect to have this production run delivered to us in the next couple of weeks. As I said, we've just kinda missed having them in time to be here. We really had hoped to be here with a big bag of them for sort of anybody that was interested. I would have decided to set the quantity one price at $40 US and then to discount for quantity. If people are interested in real quantities of them, let me know and we can talk about that. I have somewhere in my bag in my notebook a set of proposed quantity discounts. But our goal here is really to make sure that people have access to a high quality source of entropy and we really hope this ends up being something that lots of people are interested in having. We do have a few more of these that are sort of, we had a small run done by our manufacturer to validate their production processes. We have a few more of those if somebody really desperately needs to have one today. But because we only have a few, if you're interested, the right thing to do will be to watch chaoskey.org. We will change the status at the top of that page to indicate when we actually have them for sale and then I'm happy to stick them in envelopes or boxes or whatever and send them out. So with that, I guess we're pretty much done with the content part of this. We'd be happy to take any questions. Don't have that many with us today. Oh, the one thing that I'm trying to do right now is to get the drivers in the stretch kernel but it's not in the stable kernel. So I need to backport the driver to the stable kernel so that we can actually run it in our stable servers so the DSA folks will be happy. It's a completely separate driver. So I can either construct a package that has just the driver that you could load or I could merge the patch into the current stable kernel and just deliver as part of the kernel package. Anybody have any preference? Can you re-use it to RNGD? Hmm? Can you use it to RNGD? It doesn't, we don't need to use RNGD. It's built directly into the kernel. We don't need any external applications. Microphone it, Baba. Okay, I'm the first one to take a microphone but the camera can still see me. So does it work with the backports kernel because I think that might be enough? The driver should just compile. It's just a USB driver. So there's nothing magic in it. But it's not in the kernel yet. What version is the backports kernel? We don't know. It's just basically the same as testing. Oh. Then it's already in the backport kernel. I think that's the answer to that. I think the DSA wanted to have it in the stable kernel, yes? And Keith also mentioned, people have asked us, well, gee, you have your own kernel driver or whatever. Well, yeah, I guess sort of, except he's already accepted a USB PID bid pair from somebody else that wanted to just use that driver with their source of entropy. So if that ends up being sort of a standard approach people take for building more and diverse things. And I guess you recently made a change or working on a change or something so that the kernel will accept and sort of blend data from multiple sources of hardware randomness. In the past, it's sort of been the, pick the most random looking thing and use it. No, the most recently attached thing. The most recently attached, yeah. So we generally believe that another way to sort of help deal with the possible, so somebody walking up and sticking something random into your machine, ha-ha, is, see what I did there, is that if you had a known good source of randomness on the machine already and you were sort of interleaving the bits that you get from all of them, it would just make it exponentially harder for anybody to really spoof your random number generator. And of course, the kernel's been doing its own thing. I don't know on any given day exactly what happens between the entropy pool and the bits that are delivered by random and new random. That's been written about elsewhere. Greg KH, I guess, had an article which was referenced by Tom Marble in his 2014 talk, so. Andy? So hardware RNGs are notorious for temperature stability problems. First of all, are you monitoring temperature to determine whether you're drifting? And secondly, have you tested across different temperature ranges? It's been tested across some amount of temperature range because Keith and I have entirely different and environmental desires, personally, but. He's in a couple layers of jacket, and I'm not. But no, we have not done that. Actually, you know. We probably should. Yeah, it'd be easy. There is at least one temperature sensing point on this device already, isn't there? I don't think so. I don't think the CP has it. I don't know if this one does or not. We'll have to look. It's a good question, Andy. I don't know the answer. Certainly testing it across a broader range is not a terribly hard thing to do. And again, it's completely open hardware design. We would love for all of you to go take a look and tell us what a bunch of idiots we are. Of course, it'd be nice if we'd sold at least a few of the thousand before we found that out. Okay, any other questions? If you compare the entropy key, which has had the EGD or EGD, even whatever that would distribute randomness, that makes it easier to transport randomness to a virtual machine or something like that. A few. So if you have a kernel that has a known, essentially infinitely deep well of entropy, I would assume that you could figure out some way to happily pump those bits to other machines. I mean, using the same demonet, just saying trust the local kernel to have a lot of randomness then. And it's the full, we can keep a full speed USB pipe full, which is not quite a megabyte a second in actual throughput, so yeah, it's like a megabyte a second ish of random bits. Our time is up, so thank you very much. Okay, thank you very much. I appreciate your time and attention.