 Good morning, everybody. The next 35 minutes are going to be devoted to Chrome OS hardware backed security and verified boot. To remind you a little bit what was touched in the previous presentation, there are some principles on which Chrome was built. And security is definitely one of them. The same applies to Chrome OS. There is no such definitive source as there is for Chrome, like Go Chrome. But there are a couple of those. And I look at both. And in both cases, we also have three to four principles that Chrome OS is built on. And for some reason, we've dropped stability from what Chrome does. We added smartness, but security is there. So apparently, security is still an important feature of Chrome OS. And basically, in this talk, we're going to dive a little bit deeper into how it is achieved. So a few disclaimers before we start. First, it will mostly be focused on the traditional security aspects, such as using cryptography for protecting user data and such. Not on other features, which also contribute greatly to security, such as the ability to auto-update Chrome OS reboot quickly, which, as you might guess, is very important for keeping users up to date and fixing all the exploits quickly. But we're not talking about that. We're talking about mostly cryptography. And more than that, we're talking about how we use hardware to ensure the right level of security. And again, even though it is about cryptography, it is not the Crypto 101. It is not information security 101. It is not the trusted platform ID 101. So if you knew that, there are better experts and those are separate talks, which require much more than 30, 45 minutes. And since we have this limited time span, this talk will be oversimplified. I will try to be conceptually correct, but I will kind of skim over some details because going into too much details will just overcomplicate things. Also, there will be more talks today, which will also touch on things like biometrics, which is also ways how hardware is used to provide security and do user authentication on Chrome OS. So if you're interested in that, please listen to those talks as well. What Chrome OS needs to do to provide another level of security for its users? First off, it needs to make sure that whatever is booted on the device is a verified trusted image. Verified boot, which we'll touch on later, is the ability of Chrome OS devices to check that it only boots properly signed Chrome OS images, that it prevents running old images with known vulnerabilities, for example, and with all that, that it provides recovery in the cases where those preconditions are not met. Next thing, policy enforcements. So as it was just touched in the previous talk, Chromebooks are very popular in the educational space and among enterprises. So enforcing policies, such as, for example, preventing users going into a special development mode where they can run whatever on their devices, is an important feature of Chrome OS. So policy enforcement is there, and we need to somehow deal with that. Well, the next one is obvious is user authentication. So whenever a user touches a Chromebook, we need to understand who they are and only give them access to their data. Also, we need to authenticate the user through various means, because currently, the users are using Chromebooks on tablets, which we're entering passwords is not very convenient. So we allow pins, we allow secure cards, we allow other methods of authentication, and all that should be handled by Chrome OS. System and user data protection. So obviously, even if you lose your Chromebooks, you should be reasonably sure that your data cannot be stolen by whoever finds this device. So even when a user is not there, the data should be protected and the Chrome OS should prevent attackers from stealing your data if they somehow get access to your hard drive for your device. Next thing is, well, besides the operating system itself with all those user authentication and authorization requirements, there are also applications which run on top, and they have their own security needs. So they need to have some place where they can put, for example, their cryptography keys that they use to sign communications with their servers or encrypt communications with their servers. And they need to have a secure place to put all those keys in on the device. And, again, Chrome OS provides this to them. And the last, probably not least of the features that I want to touch here is remote authentication. The ability of Chrome OS to prove to remote servers what they're actually talking to a Chrome OS device in a modern app, a Chrome OS device of a specific identity, like a specific Chrome OS device, if it's important for them, Chrome OS for a specific type if it's important for them, and Chrome OS in a specific state, such as, for example, running a signed verified image if it is important for those services. So all this is remote authentication. And that's the last feature that we're going to touch here. So how Chrome OS does it? We're all here at Google. We know how Google does it, right? No. In our case, it's not machine learning. It's the hardware root of trust. And the hardware root of trust is basically a separate hardware component sitting on the device which is separate from the main CPU, separate from the main memory, disk and flash available to the main CPU, which can encapsulate secrets. It provides a novel-tell storage for those secrets which can perform crypt operations in a way which is tied to this device, so they can only perform on this device on this module, and which can prove its identity to the rest of the system or to other servers out there. And there is another specification that defines that type of devices as the trusted platform module devices defined by trusted computing group. And for many years, Chromebooks contained TPMs, trusted platform modules, I guess, in them to perform to provide this hardware root of trust, capability, and to root all the secrets that Chrome OS uses inside them. Recently, we've started doing even better. So about two, maybe a little bit more years ago, yeah, two and a half years ago. More in Chromebooks started using Google-specific chips for this purpose, which are currently known under the Titan name. They used to be known under H1 name. This is a special security chip built by Google, which also provides the hardware root of trust functionality. But compared to third-party TPMs, we have certain advantages that we can use for Chrome OS purposes. And they're obvious, because it's the Google design and Google-provided chip. It has full control over the firmware that runs on those chips. It's actually open-sourced, at least 99% of it is open-sourced. So we know what goes in there. We can quickly, well, we can prevent any third-party exploits to go into there. When we find bugs, we can make sure that the fixes are made quickly and efficiently, so that the same way, if issues are found in Chrome OS in the next update to get them fixed, the same way, if issues are found in this root of trust firmware on the next update, we'll get them fixed. And it also allows for extensibility. So even though for legacy reasons, those chips started with providing a subset of trusted platform module commands, which can be sent by Chrome OS, nowadays they do more than that. So they also serve as a second-party authentication devices with a separate set of commands that they provide. They also provide special capabilities for users who need to log in with pins. And at the same time, you need to make sure that nobody can just guess through all the combinations of a five-digit pin and log in there very quickly. So all those things were added on top of a limited subset of TPM commands that Chrome OS uses. So I haven't said that. So I've said that Chrome OS root of trust is rooted in this hardware module, which is true for many cases, but not for all of them. And you may see a couple of cases in the next of this presentation. I will not be able to talk about all the features that I listed before, but I will touch a few of them. I will start with verified boot. And this is the one to remind, again, when we want to boot only properly signed Chrome OS images and we want to prevent rollback to images with no vulnerabilities. So it actually, from the hardware root of trust point of view, it uses a couple of interesting features provided by this hardware root of trust. One of them is so-called platform configuration registers. And platform configuration registers is actually a register, like you all know what the register is, which stores data. But instead of, and it allows you to read this data, but instead of a write operation, it provides a special extend operation into there, which actually relies on using hashes like SHA-256, SHA-512, if you know, cryptography basics, which are the important thing about them is they are like one-way functions. So if you know the original data, it's very easy to calculate the result of applying this function of applying the SHA hash to this data. But going back is, let's say, impossible. What you can do with those platform configuration registers is to extend it, which means you provide some value and what it does, it takes the previous value stored in this register, takes the value that you provided, combine them, and then calculates the hash of them and stores them back into this register. This way, if you know what extend operations were performed or you think you know what extend operations were performed, you can always verify that. You can, by hand, outside of the hardware root of trust, you can recalculate all those hashes. That's a simple operation. You can always do that. And then read the PCR register and compare what you calculated with what's stored there. This way, you will know that the list of operations that you think were performed is actually the list of operations that this hardware root of trust, the hardware security model saw. This platform configuration register feature will be used by verified boot and by other features used by Chrome OS. Anyways, I think I will continue. The second feature is Nononotel RAM, provided by TPMs or security chips. So as I said, the hardware root of trust provides us a way to store data on a separate hardware module in a way that can only authorize access to this data. So what that means is those chips provide region of memory, nonvolatile memory, that somebody can serve data in. And those who serve data, they define special region spaces called there. And they provide special attributes for those spaces, which tell that only somebody who provides a certain password can read from this data. Or only if the device in a specific state, such as one of the PCR registers, contains a certain value, you can read the data from there or write data from there. And more and more and more and more. Only once after reboot or only before you call a certain lock function and all that. So those RAM spaces allow us to provide and authorize access to the data stored on the TPM or security module chip. So now let's see what a verified boot actually does. So at the high level, it's a pretty simple thing. There are several parts of the software and firmware that run on the Chrome OS device. We'll start with the read-only firmware, which sits in a read-only space and protected by a special write protection flag, which you can only get access, either if you get the physical access to the device or through a hardware route of trust or through a security chip. This read-only firmware then verifies the read-write firmware, the read-write part of the firmware. And it gets its image, it verifies its signature, it checks that the signature matches the key that it has, and only if it matches, then it boots it. Read-write part of the firmware does the same with kernel. Kernel does the same with the root file system that it uses. So in this chain, every previous stage verifies the next stage, and only if all stages are verified, we boot all the weights of the kernel and we run the separation system. Digging a little bit deeper. Again, we don't have much time. So there is a special block in Flash that stores the root key, which is used to verify the read-write firmware. And it is write protected. So nobody can override it without special access to the device. The RO firmware gets this flag, then it decides on which of the two versions. And we need to be able to update the read-write part of the firmware in the field. Like with every auto update we should get for your Chrome OS, you may get an auto update for your read-write part of the firmware as well. It has two slots where those RW parts are stored. It picks the one with the highest version, and it also checks if the version is not lower than the minimal version it accepts. It verifies the signature. It boots it. Same with the OS image and kernel. There are two kernel partitions, kernel A and kernel B. Read-write firmware checks which one is newer. Again, verifies that the image version is higher than the known good threshold that is provided somewhere for this RW firmware, gets the root file system for the same kernel, and boots that, and so on and so forth. What it allows us to do is to have several modes in which Chrome OS boots. And the one where Chrome OS devices are most typically booted in is the verified normal mode, where all those stages are performed, and all those checks are performed. And if something doesn't check out, if, for example, the read-only firmware is not able to find the signed read-write firmware on the disk, it will not be able to boot it, and it will go into recovery mode, which will allow you to recover the device from this unportioned state. Same thing will happen if there are some hardware issues during the boot process. Now, in addition to that, we allow the users of Chromebooks to get a better access to their device. If they want to experiment, if they need to run something special, if they want to run a different operating system on this device, after all, it's their device if it is their device. They can enter a special developer mode. It can allow you to boot a different image. Then set special flags in Flash that allow you to boot from USB in addition to that. How you do that, well, you go to recovery mode. If you remember, if there is an error, if we are not able to boot a properly signed image, we go into recovery mode. You could also trigger go into recovery mode manually if you want to, if you need to recover, or if you need to switch to boot in developer mode. And in this case, it's the read-only part of the firmware that recognizes this request to go into recovery, which will not boot a read-write part of the firmware, but instead will boot the specially signed recovery kernel images only. And those recovery images will be able to update the operating system image running on your device. Why do we need a special mode for that? Because normally, if you remember what I told about the use of the secure module, we have PCR registers, and we have envirom spaces. And envirom spaces are used to store those minimal threshold versions of firmware and the Chrome OS kernel, which are allowed to boot on those devices. These are those entire old back features that we have. So if we know that versions up to a certain one has an issue, it has some non-vulnerability. The key was vulnerable or something like that. We can set this threshold and will not be able to boot this version. And those versions are stored in TPM or secure chip envirom. And before booting the read-write, like when RO boots read-write part of the firmware, it locks this envirom from overriding by any subsequent software that runs on this device. Same thing when read-write part of the firmware boots the kernel, it locks first the envirom space, which defines the kernel version from being updated until the device is rebooted. So in recovery mode, we don't lock those spaces. We'll let the recovery image, especially signed recovery image, to overwrite them if needed. We let the recovery image do other things on the device. We don't lock the device from this image. And that allows you to do certain things and allows you to restore it to good state. So this is how it worked. In addition to that, as a part of this whole process, the firmware sets the state in which it booted. Was it the recovery mode? Was it the development mode? Was it the normal mode? Into one of the PCR registers that we talked about. And this way, the software that runs after that will be able to verify in which mode this device was booted. And this way, the software that runs after that will be able to protect their data from which they use, again, a hardware root of trust to store from being read in the wrong mode. For example, if they have a key which they want to use to, say, decrypt the user data, only one device is booted in normal mode, they can create this key on the TPM side and tie it to a specific value of this PCR0 register. And only if when they're verified in the normal mode, this key will work and will allow to decrypt user data. If we boot in the developer mode, no. This key will not work. You will not be able to decrypt. So that's very quickly what the verified boot is. Now, the core of Chromo Security user authentication, data protection. And again, it's pretty simple in terms of what it needs to do. It needs to check user passwords or other forms of authentication and then provide access to the user data only if the right authentication was provided. How does it do it? So it encrypts user data and encrypts it with user-specific keys. And I'll describe how exactly it does it in a moment. It also encrypts certain system data. For example, all the system logs are stored on a specially encrypted partition encrypted with a system-level key because those logs may include some of your PI data just by chance. It may include some IP addresses that you accessed. It may include some other information that can be used to determine what you were doing on this device or what this device is. This way, we protect those system-level data as well in case somebody grabs your Chromebook and that gets access to the disk. But user data is also protected with user keys. And for that, we use hardware-bound keys. Basically, those are the keys which are stored inside the TPM, inside the security chip. Does anybody here know what cryptographic keys are and how they're used? Do we need any refreshers? Do we need any refreshers? Or can I? I expect we can continue. So basically, a crypto key is something that allows you, that has two parts, private and public part, if we are talking about asymmetric keys. And that's what I'm talking about here. And only a certain entity knows the private part and everybody else knows the public part. And that allows you to do two things, depending on if you're talking about signing keys or decryption keys. Like anybody with decryption keys, anybody using the public key can encrypt the data, but only the party that knows the private key that can decrypt this data. With signing, it's the opposite. Anybody who only the party that knows the private key can sign this data, meaning that it can attach a signature to the data that it sends. And the users of this data will be able to, anybody who has the public key, will be able to verify the validity, the authenticity of this data by checking the signature and verifying that it matches what they can see with the public key. So with hardware rule of trust, we can put those keys into the separate hardware components in the secure module. So basically, we can ask the secure module to generate a new keeper consisting of private public parts. And at this point, it's stored only on this secure module. Nobody else can see it. It just generated it and provided some handle to use it. Then we can ask it to sign with this key, for example. And again, this private key never leaves the hardware chip. You provide the data, you get back the signature. Or you can ask to decrypt it with this private part. Or you can ask it to get back the public part to you so you can provide it to other users who need to validate your signatures or who need to encrypt the data so you can decrypt it. So that's, in essence, what those keys are. And again, as with NVRAM spaces in TPMs and secure chips, those keys have attributes assigned to them, which allow you to provide certain requirements for who can use those keys. Only those who know the password, only in a specific device state, as I already mentioned above. Many more other authentication policies are available up there. But again, we're not going into too many details here. So how do we use those keys? For example, for user data, every home directory for user on Chrome OS is stored in an encrypted file on the file system. When a user logs in, this file is mounted as a partition, as a home directory for this user. The key which is used to decrypt this file when mounting it is a software key. It's self-stored on disk in an encrypted format. The key to encrypt this key is provided by the firmware and by the user password. So let me go into a little bit more details. It will be more clear from this point on. So let's say we have this encrypted user directory. When the user first logs in, it has an empty directory and we create a random key which encrypts it. It's completely random. It's not tied to any TPM. It's not tied to anything. Then we use this key to encrypt the user data. Now we have the encrypted user file, which we will be able to decrypt with this key. On this slide, you will see the vault key set is what we use to encrypt and decrypt the user home directory. And we use the vault key set key, VKK, in the second part, in the lower part of the slide, to encrypt or decrypt this encrypted vault key set, this vault key set, and store it in encrypted form on disk. So we have this random key that encrypts user data. Now we generate yet another key, another random key, which encrypts that key in turn. And then we send this key through a couple of operations. First, we send it through, we encrypt it with a TPM key. So this hardware back key, we encrypt that key with it, and we get a new blob of data basically out of it. And then, again, we encrypt it with a user password. There actually is something derived from user passwords. So when the user types in their password, we, again, through a number of hashes and key derivation functions, generate the key in a deterministic way so that every time the user types this password, the same key will be generated out of that. And we use this key as a second stage to now encrypt the blob, which came out of the TPM, and then store this file on disk, this blob on disk. So when the user logs in, they provide their password, this key is generated, we read the file, the encrypted vault key set, key file from disk, we apply this key to it, we get the value. We then send this blob to a security chip, decrypt with it, get another key, and then we apply that key to a file on disk where the vault key set is stored, and this vault key set and then applied to the user home directory. So that's a rough idea how encrypting user data here works. What it allows us to do. First it allows us to tie encrypting user data to this device. So only when they have access to this TPM, you will be able to decrypt the blob which came from the encrypt vault key set key. And it also allows you to tie it to user passwords. So only somebody who knows the user password will be able to send this key for this whole sequence and get the mounted partition at the end. So this way, if somebody steals your device, they will not be able to do it, or if somebody copies your data to a different computer and then throws like machine power in order to cycle for all the possible passwords, they will not be able to do that because they will actually, it's not the password that they need to crack. They also need to crack the key which is stored in the TPM which is a much harder thing to do. So this is what we do. Of course in reality, it is much more complex. And I will scheme over those things I guess since we're running out of time. So these are the three schemes which are used in Chrome OS in reality. And they're more complicated because you need to worry about multiple things including what if your TPM has a backdoor, including many other things. So we need to balance protection from the TPM and with the TPM. And just, but basically it's the same idea and I will not go through this list at the moment. So why this complicated scheme? Why we have like those two levels? Like the second level is more or less clear. So we need to protect both with the security chip and with the user password. But why do we need to generate the intermediate key and then encrypt it with another key? The reason is because we can have multiple authorizations for the same user. It can be a password, it can be a pin and it can be something else. This way we generate a single key that encrypts a user directory but we can have a multiple secondary keys which encrypt that key. And one of them can go through a password, one of them can go through some other form of authorization like a pin that the user provides. And again, those things that we should have described here those are just for password. For pins, a different workflow is used for smart cards a different workflow is used. But eventually they get to the same key which is then applied to the user directory and allows to mount.