 Oh, so good morning everyone and my name is Suho and I'm a master's student at Dong University, South Korea and I am a little bit nervous about like I'm the only student here, I guess, and everyone's like from Google, Intel, IBM, Red Hat and I was expecting like half of these people were going to be here and a bit nervous a lot. So anyway, so I'm today I'm going to talk about talks or trust update on Linux kernel which is a research about maintaining integrity of a system along with the frequent kernel updates. So I'm going to talk about a little bit of related works and attack models and then I'll explain talks and show some prototype experiments and finally and I'll conclude my talk and I'll take questions at the end. To begin with, security vulnerabilities are prevalent and we see thousands of new CVEs every day and for example, recent announcement of the meltdown inspector has been causing a lot of troubles in the Linux society as well and I saw Linux distros have been deploying a lot of security updates to countermeasure or at least mitigate such vulnerabilities. However, in my opinion, there was not much attention given to the changing integrity after those updates and ways to manage the updated integrity information. So there are two concepts. First of all, the maintaining integrity and the other side, the security updates and in my point of view, the maintaining integrity is trying to keep the system as it is and run the system as it is and on the other side, the security updates tries to secure the system by modifying the system and therefore, I guess the after the updates, the integrity information is inevitably changed and there's a need for managing them. And we came up with these two questions. First of all, the can model integrity management solutions distinguish between managed modifications and intended updates and if it does, it's the modified integrity being properly managed. To answer these questions, we have investigated some of the model integrity management technologies. First of all, the Intel TXT which employs grub module, T-boot and the launch control policy aka LCP to measure slash verify boot the latest environment. However, when it comes to the update, the LCP can be a little bit of drag. This is because the LCP can only represent only one state of a specific state of a machine. So therefore, the LCP must be also updated according to the updates. And also TXT does not measure or verify grub commands which can allow an attacker to modify the grub commands to boot into a managed kernel or load a managed grub module. Next of all, the OpenCIT is a remote attestation solution created by Intel also to validate the TPM measurement from the remote server. The OpenCIT server establishes the known values by importing the TPM measurements from the local systems and perform the remote attestation using those values as a root of trust, I guess. However, the problem with OpenCIT is that the local updates are not transparent to the OpenCIT server which means that when the local system is updated, the remote attestation fails until it reestablishes the wireless by importing, re-importing the updated measurements. Finally, the UFI secure boot is an interactive verification function defined the UFI BIOS. It verifies the signature of an executed binary using the public keys stored in the firmware database. We found that the good thing about the UFI secure boot is that it enables simple updates since it only needs to sign the updated binaries and deploy the binaries. And the receivers only need to receive the binaries and install them. Unfortunately, we found it difficult to say that UFI secure boot is suitable for Linux environment since it does not support grub boot loader unless they install a public key of the installer. And on the other side, the UFI secure boot provides a public key stored in the firmwares of the mainboards. Anyways, the other problem of the UFI secure boot was that it does not support grub, so consequently it does not support verifying grub commands which list the same problem of the Intel TXT. Additionally, it does not support TPM measurements. So let's now take a look at how these problems can be troublesome. So first of all, we can subvert the open CIT scam scheme all the way through. This occurs because the local updates are not transparent to the open CIT, so let's assume that the attacker can update the local machine and perform measure boot. So as a first step, the attacker tries to succeed to update the local machine with the measures kernel and boot up the measures measurements. And TPM will measure the measures kernel, creating the measures measurement, and then the open CIT who has no idea about the local updates, it will try to perform the remote attestation and eventually fails. And then as the local system has been updated, it tries to reimport the measurements which is now gone measures and try to create the new wireless. And now the wireless becomes compromised. And after this point, the attacker may run the measures kernel, even though the open CIT confirms that the local system is trusted. Next, we can circumvent verify first scams. First of all, the TXT can be filled with a TXT scan. The TXT scan was introduced in 2016, and I don't know if you guys have fixed it or not, but it can be an example. And also, earlier this year, also at the Black Cat Asia 2018, one of the teams demonstrated how to subvert the TXT scan. And I think it was called I don't want to sleep tonight, I guess. And anyways, with the Black Cat USA 2016, the hypervisor root kit, they executed the root kit, hypervisor root kit that mimics TPM through the growth commands and before they load the T-boot module. And they tried to circumvent TXT and they succeeded by running the measures kernel even though the T-boot verifies that the local machine is trusted. Also, the secure boot does not verify integrity. After the growth boot loader is executed, therefore the attacker can modify growth commands to launch measures kernel or load other growth modules. And we believe that these two attacks are caused because the TXT and secure boot does not verify executed growth commands during the booting. So to provide proper integrity management, along with updates, we stated some goals. First, the remote attestation must transparently manage local updates to distinguish updates, intended updates from the measures modification. Second, the remote attestation must maintain whitelist according to the conducted updates and perform remote attestation using up-to-date whitelist values. And finally, the local machines should perform thorough measures slash verified booting, including the growth. And so we proposed TOX, a trust update on Linux kernel. TOX code is uploaded to my GitHub. There's a link below. And TOX paper will be presented at STM 2018, which will be held next week at Barcelona. And if you guys want to check more information, just check the paper, I guess. And before I explain TOX, I'm going to explain some of the key technologies I used in TOX. First of all, we use the famous TPM 2.0 to measure integrity. It is a tamper-proof device to measure integrity and store the integrity measurements. Now, one thing about the TPM is stores the integrity measurements to the special registers called the PCRs. And some of you might know the PCR values are not just created, the calculated values are stored into the PCRs. It uses a special operation called extend. The extended operation generates new PCR value by first concatenating the hash of the data and old PCR value. And TPM hashes the whole concatenated value again to create the new PCR value, which will eventually create a trust chain for the values measured in that specific PCR number. And next, we use shim and grub boot loader to maximize Linux compatibility with the UFI secure boot. Shim is a first stage boot loader for Linux to support UFI secure boot. And good thing about the shim is that it can be used to verify executed binaries from the grub by using the shimlock verification function. Shimlock protocols are basically a protocol that allows a grub boot loader to communicate with the shim boot loader. And the fun thing about the shimlock verification is that it uses also the firmware database keys stored in the, public keys stored in the firmware database, just like the UFI secure boot. And we use them to verify signatures of our executed binaries. And also we use a modified grub from CoreOS branch since it will support a TPM2 and TPM2 integrity measurements. As a research, there are a few assumptions that we made. And first of all, we assume that the TUC server is the OpenCity server and the maintainer slash administrator of the updates. This makes TUCs transparently manage the local updates. And second of all, we assume that the TUCs only verify the interior to Linux booting process. This is because that we think that the CoreOS should be verified during the booting process, and after the boot, there are plenty of powerful solutions to secure the system. And thirdly, we assume that the TUC server is trusted and safe, so we believe that it is not compromised. And fourthly, we assume that the TUCs owner holds the manifest of a specific booting process of each managed machines. And finally, we assume that all managed machines should hold TUCs owners public key in the firmware database. So, this is the full architecture of TUCs, which consists of three main components. First of all, the integrity manager, which manages the integrity according to the updates, as well as it is in charge of deploying the updated kernels to the local systems. And PCL sign kernel, it is a special kernel for integrity verification. And finally, the TS boot, which provides a robust measure slash verify booting at the local machine. So, first of all, the integrity manager is a component that resides in the OpenCity server. It is in charge of the integrity management and also the kernel updates. And it has three little modules. First, the module is trusted repository, which holds the valid binaries for the updates, which is just a eventually ad get repository for the trusted kernels. And the wireless updater, which generates and updates the known goal values according to the updates. And lastly, the PCL sign kernel generator to generate PCRs and deploy the kernels to the local servers systems. I'll explain more about the PCL sign kernel on the later slides. So, with the integrity manager, the TUC's kernel update and remote attestation procedure will be looking like this. First of all, the local machine's kernel update repository is set to the TUC server, and it will allow TUC server to notify updates to the local machines. And when we get the notified, it will request the update to the TUC server. And if the TUC server gets the update request, it will calculate and update the new wireless values according to the requested updates. And it will also generate PCL sign kernel and deploy the kernel, trusted kernel to the local machines. It will install them and finally the open CIT server will perform remote attestation to check if the update has been properly installed. With the integrity manager, TUC achieved the first two goals, managing local updates transparently since the update administrator is the TUC's itself. And the second goal, the successful remote attestation with the up-to-date wireless value. And on the side, I don't know if you can see properly, there's a comparison between the open CIT and TUC's when there is a kernel update and it tries to perform the remote attestation. The second component of the TUC's is PCL sign kernel. It is basically a trusted kernel with which is used during the TSPOOS interactive verification. And PCL sign kernel is a kernel that is signed with the TPCR value instead of the digest hash. So the idea of the initial idea of the PCL sign kernel was that if the TPM generates hash and most of the digital signatures keep the hash data digest hash inside the kernel, why don't we switch them, use the PCL values as the hash of the binaries that we use. So the TPCR is a calculated known value which is created by the integrity manager inside the open CIT. And by extending the, it is a value that represents the booting process without any broken integrity. This is possible because we assume that the TUC server knows the whole entire booting process of the local machines and they can generate PCL values, the expected PCL values according to those information. And I will explain how the PCL sign kernel is used for the interactive verification in the next section. The last component of TUC is TSBoot, a trusted secure boot. It is a combination of UFI secure boot, modified shim, and modified grub. It is Linux friendly by using the existing Linux boot loaders and it measures every binaries and commands executed during the booting process including the grub commands and the grub modules. And with TSBoot we propose a robust interactive verification scheme called PCI verification. So the PCI verification verifies the entire booting process during the booting. It tries to measure the entire booting process to PCI number 12 and to create a measurement that represents the entire booting process and since we measure everything to the PCI 12 from basically hardware measurements to the kernel booting processor commands, if anything changes regarding the booting it will reflect to the PCI 12 and when the kernel is executed using the Linux EFI function defined in the grub boot loader, it will pass the kernel to the shim and using the shim lock verification function for the verification and shim decrypts the TPCR value inside the kernel signature and compares it with the PCI 12 which must have the same value as the TPCR if it has booted successfully without broken integrity. With PCI verification this gives full control of booting to the tox owner and the local machines must boot in the same order that tox owner defined previously and if anything changes during the booting for the booting it will halt the booting and since the PCI 12 measurement will be changed and this will provide a robust integrity. With the TS boot we achieve the third goal, the first goal was measure slash verified booting including the grub commands. I have shown the comparison between the Intel TXT and tox over there. Intel TXT basically tries to measure each steps of the booting process and go through all those steps to verify the booting and tox tries to verify the system only by comparing the PCI 12 before the execution of tox, the kernel itself. So that's kind of a difference. And as a proof of concept we have performed few experiments. First we experimented if the tox can detect any modification during the booting using the PCI 12. Any modifications I mean hardware modifications, firmware option modifications and software modification used during the booting process. We have four cases to prove them. First the case A with PCI with kernel version 1 and secure boot on, case B PCI with kernel version 2 and secure boot 1 which represents a software change and case C PCI with kernel version 2 and secure boot off which will represent a firmware option change and finally the case D PCI with kernel version 2 secure boot on which will represent the hardware change. And we have confirmed that the PCI 12 on the last line has changed under all circumstances and it shows all that if anything changes it will reflect it to the PCI 12. The other PCI values also have other meanings that the PCI, according to the PCI numbers, PCI 0 to 7 are measured throughout the secure boot process and PCI 8 and 9 will be measured by the trusted grub and PCI 10 and 11 will be measured by shim boot loader for the grub and kernel entirety and of course the PCI 12 will be extended throughout all the process of booting to represent the entire booting process. Second experiment was to check the PCI verification if the chip PCI verification can detect grub commands modification. I have added an extra command that echoes this is to fail PCI verification and eventually when booting the PCI 12 changed and we can successfully detect and halt the booting itself. Finally we have experimented if the OpenCIT can perform thorough remote attestation using the new wireless values when we update them. And here we have only used the PCI 12 value as a white list for simplicity and we saw talk successfully performs thorough remote attestation with upstate wireless value. Here we can see the green check sign on the last picture. And I will show a short demo of talks for the system. Sorry. So initially we initialized counter version 62 and registered to the OpenCIT server so we performed when we performed the remote attestation it will state the machine as trusted showing the grub green check sign. And after that we performed a normal local update without notifying the OpenCIT server. This will cause remote attestation failure because the OpenCIT server has outdated wireless values. And then we restored the machine to counter version 62. After that we tried to update with talks and it will also update the wireless values inside the OpenCIT and the local system will request the updates to the OpenCIT server. And when the update is complete when we perform the remote attestation it will show the green check sign again. And when we check the wireless values inside the OpenCIT database we can see that it is successfully updated and it matches with new measurements from the booting itself. And we also support rollback if the counter version we request is inside a trusted repository we can request. Here I requested counter version 62 again to notify the OpenCIT server. I want to change my counter version to the previous one and now the counter version is updated and the local OpenCIT server is notified with the updated wireless values and it can support proper remote attestation. After this there is a short demo of PCI verification holding the booting when GRUG command is changed during the booting process itself. So when we boot I visit the GRUG commands and I entered fault echo changing the GRUG command, executing GRUG commands and it successfully holds the booting and stops booting itself. In this demo counter rollback is supported if requested counter version still exists in the trusted repository and also TOS can detect rollback attacks since TOS cannot perform wireless updates with the counter that doesn't exist in the trusted repository. So if it is updated counter version the wireless values cannot be updated according to the user. So if it checks the counter version the measurement doesn't match it will state the machine is untrusted and it is somehow modified or compromised. And we believe that both public key and the private key of TOS owners key is safe since we assume that the OpenCIT server which stores the private key is safe. And we believe that TOS may be applicable to other environments who uses UFI secure boot, TPM and shim and grew up boot loader which I believe that it is mostly applicable to other Linux systems including rad ads, Ubuntu and other stuff. And it can be also applicable to small systems other than the IoT devices. And finally after the TXT most people tend to use more DRTM but talk seems like a SRTM however I think that talks dynamically generates the whitelist and PCRSankono according to the growth command so I think talks is in between the SRTM and the DRTM. So to conclude the interactive changes when the DRTM is conducted and TOS it should be properly managed and talks successfully supports interactive management along with the frequent updates by extending the OpenCIT server to transparently manage the local updates and remote attestation with up-to-date whitelist value thirdly the thorough interactive measurement using the TSPOOT and finally it provides robust interactive verification with PCR verification. So that's it and I'll gladly take some questions and feedbacks. I really enjoyed that it's really interesting integrating that with OpenCIT. Two comments first thing is we ended up writing our own secure bootloader because we wanted both SRTM and DRTM and GRUB doesn't support both at the same time because you can either have multi-boot or secure boot through the UAFI. The other thing is you're overwriting PCR10 and by default a lot of distribution kernels already have IMA configured on PCR10 so it would be good if you didn't clobber that by default. Thank you for the comment. Taking the assumption that on OpenCIT there's no authorization required to update the new server for example is that it doesn't automatically update as you're claiming someone's got to be on the back end authorizing the new set of PCR values that are now valid or don't update the PCR values because I don't trust this new one. So basically when we try to use the OpenCIT to verify the TPM measurements from the locals we saw that when the local system is updated the local user must re-import the TPM measurement as a wild list by himself by going to the web and importing the new values to the OpenCIT database. Okay which requires authorization? Which requires authorization from the administrator? Yes, you need to type in ID and password to get into the screen, the website which is provided by the OpenCIT but we're assuming that the attacker may have those passwords and IDs so it can update the wild list itself. Yeah, if the attacker owns the back end if that happens use it in password to all the firewalls all the servers right, I'm not sure I don't think that's a valid assumption based on I think there's a lot of things so I can't speak for Intel anymore but there's a lot of things, I agree there's a lot of things wrong my opinion is go fix the stuff that's there don't create a whole new entirely new framework I see the comments are too long for the time we have Any more questions? I think that's it right