Since this is part of the embedded system engineering program in this course, this is very critical to talk about software and firmware updates for devices in the field. You're going to go work for a company or you'll start your own company, you're going to manufacture devices. You're probably you're going to want a way to update firmware, so printers need to have their firmware updated. All kinds of devices, our phones need to have software updated on them, so all these devices have this need to have software updated. We don't want a rogue software finding its way into the device to be taken over for nefarious purposes, become a bug and start sending spam to who knows where. So, there's two sets of keys in this scheme, this is a way to do it, I'm not saying it's the way to do it. There are many ways to combine encryption and algorithms along with message authentication codes to cook up a scheme that can provide authenticity and integrity checks at the receiving end; this is a way to do it. So, someplace in your company, you have a secure server, physical access to the machine is in the room is controlled by security and door locks and key card access or something. So, we would just assume that it's very difficult for an adversary to get in and access data on the server. But there is a shared secret key and located on this server and a shared secret key that's stored on the device. So, think of this as a single board, printed circuit board with a microprocessor and a connection to the Internet and it controls refrigerator, I don't know, it does something. Then, there's also a public and private key pair as well and the private key is kept on the server. So, when the firmware team is finished implementing bug fixes and adding additional features to the firmware, they create a software binary image represented by this box. The binary image along with the shared private key is fed into a Mac engine to produce a tag. Then, this tag is fed in along with the binary, so you could think about it as these being appended to each other, both of those are fed into an encryption algorithm as the data and the private key of the public private key pair is used to encrypt the whole thing. So, the tag is encrypted and the binary software image is encrypted. That's sent across in a secured channel, it arrives at the device, and before the device will execute it or update its firmware's going to perform these checks here. So, it takes a whole binary image, the public key and decrypts it, and what pops out of that is the binary software image over here, and the tag that was appended to it can be extracted and pulled out of it. Then the shared secret key along with the binary image is fed into a Mac producing a tag and these had better be the same. If they're not, then you know this was rogue software that someone was trying to download to your system or somebody modified the contents of the minor image when it was being transported across in an insecure communication channel. I worked at Seagate and Micron and we had gone to great lengths to make sure that adversaries cannot upload arbitrary code to our drives. When I first got to Seagate and so when was it? 2006, talked to other engineers that told me stories about people up in the world that were using the serial port that was left open and that's how they just hook a, make their own little serial cable over to a terminal emulator on their PC and they could talk to the drive. I don't know if they would type question or help and return and it printed out a list of commands and they were eventually able to figure out how to upload new code to the drives. When I got there, we started working, there was a big effort, not just me but the engineering team, both on the hardware and the firmware side, went to work to plug all those holes because we didn't want people uploading new code to the derives. Then they break the drive and then, well, I break the drive, turned it into a break, it doesn't work anymore, and then they were saying, well, it's still within the warranty period. So, they might try and send it in and you're drive's broken when in fact they actually broke it but anyway. Go through a lot of work to ensure that rogue code is not executing on a device and this is a, like I said a way to do it. So, I'll just drive home the point, firmware should always be authenticated and build this into the system from day one. Again, don't try to add security after the fact, think about what security you want to implement when you're designing a product upfront, do it from day one. As I've shown here, were using asymmetric encryption with other private key, it's a fair design choice so it works. It handles authentication, integrity, and security altogether. So, the binary image and the tag are all encrypted, so eaves out here listening, very difficult to figure out what the contents of that binary file is or that stream data with that represents. Key generation. In order to be effective, the keys used for security should be random numbers so an adversary cannot guess them. Sounds like a good idea? Random numbers? My advice is steer away from pseudo-random number generators because these have a predictable pattern. So, in C, and Python and other languages you can call Perl dollar random, call the C function random. You can see that a joy, if you play around with it you'll see that whatever seed you give it, every time you run your program, it generates the same sequence of random numbers. There's libraries of routines that don't behave that way, there are websites that will generate random numbers as you can go grab and pull in, I don't know what the quality of those random numbers are, I know it's very hard to generate a really good random number. Pseudo-random numbers are like a linear feedback shift register, they follow the same sequence every time. So, therefore they're predictable and are not a good choice for an encryption key. It's very hard to generate true random numbers. I'm going tell you a story about the random number generator, the first one that I worked on. It's a couple of things, it's funny. So, people generate random numbers is common to use a ring oscillator. So, you'll build a buffer chain on your chip, put a whole bunch of buffers, these non-inverting ones, you have one inverter in there. Who at Q? This is D. So, when it gets low like this is a latch, it just sits there and you drive, put a one on this thing and it opens up and so, you get a zero here, the zero goes around, becomes one, the one comes out becomes a zero and then generates waveform. When you design a chip, when you do logic design is very predictable. Logic always does the same thing all the time or when you're generating a random number generator, it doesn't generate the same thing all the time. So, it sits orthogonal to the regular logic design chip building process. Also, from a manufacturing test standpoint, you don't generally want latches in your design, because it causes problems for the automatic test pattern generation process that takes place when your chip is fabbed on a wafer and it's getting ready to get diced up. A probe comes down and test each of the dye on the wafer before the chips are diced up and put into packages. Anyways, latches can cause a problem. So, latches generally in digital logic are a bad thing, but we wanted latches in our inverter rings here. We call them, I give an instance, "I want this latch." There were eight of these so, there was the use of Verilog Syntax here, seven to zero. I wrote up a whole manual about how to use the random number generator for the firmware folks. There was a section in the document I wrote for the physical layout people, that would see this latch and I said, "You know we really want these latches in there." Four or five months later when the chip is getting ready to be made, I get this phone call from one of the physical design engineers, he says, "So, I was looking at your design and you got flip-flops everywhere, but there's these eight latches in there in that code. I want this latch." I started laughing and I said, "Oh, that's because I want this latch." Clearly, he didn't read or pay close enough attention to the document that I wrote. So, I got a real chuckle out of this. Despite my best efforts to communicate to the manufacturers of the chip and the people working on the layout and everyone downstream from me on the way to getting the physical pieces so I can build. Even naming the latches, I want this latch was unsuccessful. So, once he understood that those latches were okay, he left them in there. Second thing that happened is, what do the placement tools tend to do when they're placing all the cells in the design? What's the primary concern when placement tool is taking all the flip-flops, and all of the cells in the combinational logic cloud behind them, in-between the flip-flops? What is the placement tool trying to do? Minimize timing? Place them close together? So, placement tool worked at the output of this flip-flop and noticed that it only goes to one inverter and that inverter only goes ahead one load on it and sorry, buffer and only had one load, one load, one load, one load and one load. So, all the cells were located right next to each other, like this. Even though in the document I wrote I said, "Manually go place these cells and spread them out because we want to pick up noise. We want to pick up substrate noise, we want to pick up switching noise of other logic, we want this stuff spread out as much as possible, we want this logic all dotted all over the place for the eight rings and the latches." We wanted to cover a pretty large area, but it didn't because the tools are designed to minimize timing, minimize capacity of loading, minimize the slew rate, the switching rate. I want to minimize all the capacity on this. So, [inaudible] I'll put a lot of time down together. I'm pretty sure in subsequent chips, we were finally able to get the physical layout tool of drivers of those tools, to spread this out and it improved the amount of entropy per bit that we were getting out of these rings. Each ring had a different number so, there might have been, I don't remember what the exact number was, but one ring might have had 20 buffers and an inverter and then the next one had 40 and the next one had 60, and the next one had 80, and the next one had a 100 or something like that. So, each one oscillated at a different frequency. If memory serves, I think we ended up on this very first one or maybe it was a second one. One of the first batch of chips. We were getting about a half a bit of entropy out of the rings. So, that was better than we had anticipated. That might have been farther down the line and had been subsequent revisions or generations of chips when we finally spread out the logic. So, if you're interested in generating truly random numbers, you can certainly start with rings for instance, but it's really good if you have or better, it's much better, if you can take a measurement of some physical system that is inherently entropic, it's inherently indistinguishable from true random numbers. So, choices include temperature, that one's okay, but temperature tends to not change very quickly. Vibration is a fabulous one if you can put a vibration sensor and something inside of a motor or something in your system is normally looking at that monitoring- remember back to the vibration sensor on the side of the coal polarizers. That signal would have been a fabulous signal to sample periodically, because it's wiggling around very chaotically and you'd sample that with a A to D converter, turn it into digital information and then exaul that in with your sometimes called mixing. Mix that into your random number generation process. So vibrations is a fabulous source, flow rates for measuring flow rate of gas or liquid or something might move around and have some jitter associated with it and then course the rings that I talked about and mix all these sources together. So, you want to mix as many of these sources together as you possibly can, will produce better and better and better random number generators.
