The next subject I want to talk about is Chain of Trust. You'll hear this in security field when you are working on crafting a security solution for your products. This notion comes up, and I want to spend a couple of slides talking about it. So, actually let me walk through the example, and then I'll add additional commentary. So, a Chain of Trust starts with some Root of Trust. Something that you have high confidence in, hasn't been tampered with, hasn't been messed with, hasn't been altered with. If this outer box here represents a chip, Root of Trust could be put into a Mass Programmable Rom on a chip, or it could be in eFuses that can be blown during the manufacturing process or sometime before the product ships to the customer. So, this information could be a key, be a lot of different things. The ROM bootloader also. So, when the CPU comes out of reset, you want to put your bootloader in ROM. This is very relatively difficult for an adversary to modify the ROM or the eFuse on a chip. So, again, security is never ever a 100 percent. It's only good enough, so you decide. "Well, okay, we're not going to try to protect our system against somebody decapping this chip and modifying our Root of Trust." You just accept that. Say, "Okay. We're not going to protect against that, we're not going to worry about that. So, now we have something that we can trust." So, we trust what's in the ROM, we trust the code that's in the ROM, the bootloader. Someplace else, it can be a NAND, it can be a NOR, it can be in EEPROM, it can be on disk, it can be on a Network, volume some place. We've got a Secondary bootloader. So, the ROM bootloader and these keys, let's just say the Root of Trust is a key or a series of keys, this is immutable. We trust it. The ROM code goes out, knows how to find the Secondary bootloader, brings it in. In this case, it has a MAC tag that was calculated on it, could be more involved than this, could be encrypted with a Public/Private Key as well. There's levels to how far you want to go with this in when you implement your systems but in some fairly simple example let's say that there's a tag associated with this. So, this secondary bootloader was fed through some kind of a message authentication code with the key and the key is stored here as well. So, this is called signed. So, the primary bootloader brings this code into memory and before executing it, it runs the same MAC algorithm on it and produces a new tag and it does a comparison and if those tags match then it knows that code can be trusted. If it doesn't match, it's an error and that code doesn't get a chance to execute. But if it is authentic and the tags match then that code can run. So, the Chain of Trust is now extended from the bootloader code that's in the ROM and the keys has been extended to this code. So, this is secure. So, we've extended the Chain of Trust by one level and this thing can repeat. So, the secondary bootloader's job is to go load applications in and assuming those have been signed as well with a MAC, they're brought in and again, the secondary bootloader looks and sees that is it authentic or is it not authentic? If it's not, then that represents an error condition and the code isn't executed. But if it passes the Authentication Test then that code is run and then it can continue and it creates this chain of one thing that's trusted. Is used to validate the next thing in the chain, is used to validate the next thing in the chain. In case of the chips that I've worked on in the storage industry, we decided what went in there and these were large Public Keys. They were 1024 bits or 2048 bits Public Keys where the Private keys were held in the secure server at some place in the facility that would sign all of the software, all the firmware that would get loaded into the drive. But we put information into ROM or eFuses and we validated that the ROM boot code got properly burned at the manufacturing time. So, we trusted this and and that was used to then extend trust to subsequent pieces of code. So, there's a couple more examples I found. Don't get too worried about this here. These are TLS certificates for a web server and I've got a more detailed example coming in, but again it shows how you can start with a Root certificate that is authentic. It can be used to sign an intermediate certificate that points back to the original certificate and then the certificate can be used to sign another, in this case and end entity certificate that references back to the intermediate that references back to the Root of Trust. So, this is another example of a Chain of Trust. This one came from embedded.com and a Linux system. So, down here at the bottom you've got a Hardware Security device. So, an HSM is a Hardware Security Module and a TPM is a Trusted Platform Module. So, this is something that we trust, is a piece of hardware that we trust. That then can be used to validate the SecureBoot code that can then be used to perform integrity checking of basic security parameters. In this case, is a Public Key legit or not? Then validate system images like the kernel and shared library data. So, files in Linux land and so forth. So, you start down here and it builds one layer upon another and as long as the trust is established at each segment, you know you're good to go. That's the theory in it at any rate. So, people are doing this and then our web browsers do this as we see coming up.
