 Okay, this is the TPM subsystem update, and I'll discuss about things that have happened since the kernel summit 2017, so this is kind of a yearly update for TPM. TPM in a nutshell is a secure, it's an embedded co-processor that provides different tools for anchoring the privacy of the system, and it's implemented either as a software module running in some trusted environment like trust zone or SCX or management engine. Or as an external chip that is connected through some common bus like LPC or I2C, and essentially it provides key storage and platform measurement functionality and ways to sign this measurement and attest the validity of the system. Platform measurement is based on these registers called platform configuration registers. They only support extend and read operations, so you can have a new data to them, but you cannot set them all clear while the system is running. And they can be used to measure every stage of the boot in a way that the previous stage measures the image of the next stage before letting it run. And of course the first stage must be stored in a very protected memory so that it cannot be tampered. The TPM is passive by itself, but either the software that gets invalid measurement from the next stage image can perform some actions, like terminate the boot, or the encryption key inside the TPM can be sealed to specific PCR values so that it can run. But if you get invalid measurement you cannot unseal the disk encryption key. Remote attestation is essentially a procedure where the TPM signs these measurements using a known certificate that is known to the other party, and a remote party can then verify these measurements using the public key from the certificate. And that way the remote party can know whether the system is valid or invalid state. Well here's a quick recap of the TPM development history. It began in the 90s and the TPM one standard reached its final point in 2009. It had some limits like only fixed encryption algorithm and it did not support for example symmetric key encryption. So these features were added into TPM 2.0 that is not backwards compatible with the TPM one. And these days TPM 2 is becoming like the de facto standard. TPM 1.0 devices are quickly disappearing. Here are the highlights of the recent development within one year. We have added validation code for TPM header mainly for the underruns and overruns of the received data compared to the header. And we have added event log support for UEFI support a year ago. There was only support for device tree based systems. And then there's been some performance update to the TPM TIS driver that is commonly used with the discrete TPMs and self-test. For TIS we have kind of increased the resolution of the timing when we pulled the TPM. And in self-test we run it now like a synchronously so we put it to run but do not wait that it completes but instant continue the system initialization. Okay, so the event log is essentially a log maintained by or written by the reboot software like BIOS. And it contains entries for every PCR extension and it can be used to debug the system if PCRs have invalid values. So where did it go wrong and so forth. Or in some application requires you can combine it with the final PCR values that you can get signed from the TPM in order to get the trusted measurement log. Because the log given by the BIOS itself is untrusted but if you know the final, if you have signed quote of the final values by combining these those two you can have like fully trusted log. And the way we implement the event log in UEFI environment is by copying the log from one EFI table before calling exit boot services. In TPM 1.2 there used to be a CPI table that could be used to get the log but that doesn't exist on TPM 2.0 so we have to use a different strategy. Okay, so there was also like a huge vulnerability that was discovered by Jeremy Boone of NCC this year and the basic idea is that while the chip makers have done lots of research and development on making chip itself tamper resistant. Usually you can spoof, you can spy and tamper the bus where it's connected and in many cases not all but at least in some cases the TPM is actually a doter board that you can attach to the motherboard. So it's relatively quick operation to add an interposer device between the TPM and the bus. So it's a physical attack. And Jeremy wrote a white paper and created a prototype device and associated software that can be found from GitHub. And it can be used to spy, spoof and corrupt the traffic between host and TPM. So we started to take some steps to protect against TPM Gini. We already have these validations for buffer overruns and underruns that is protection against corruption. And then there's a patch set that is currently under review by James Potomly and the basic idea in that patch set is that both TPM and the host side create a public key pair. And then use encrypted salt to derive the session key and establish an authenticated and encrypted channel between the TPM and host by using HMAC session and that encrypted salt. But yeah, these patches are currently under review but I think they will be eventually merged. As Dave suffered pointed me in the hallway correctly, this is only in a way a partial solution because it only protects the bus between the TPM and host but potentially a physical attacker could have abilities with some more advanced interposer device to also spy the main memory which would endanger the host side but maybe in future we could use technosics like truss zone or SCX to solve that. But this is right step forward anyway. Questions? Please questions? First, thank you. You just spoke about physical attacks against TPM. What I wanted to check if there any support on the hardware level to clear the memory or to clear the content of those chips if the box is physically opened. You mean the TPM or? Yeah, the TPM for instance. I think it depends on the chip but generally I think there should have ways to clear them. Okay, so if... But I'm not expert on that area so... Okay, thank you. I guess I'm not entirely clear about the question. Are you concerned about the contents of the TPM if somebody opens the box? Is that the question? Yeah, I'm asking the question. Well, the TPM is self-contained. So if you open the box, the chip, all the keys are inside the chip itself or inside an integrated TPM or truss zone, you open the box. Supposedly they have tamper protection like most of the discrete TPMs, you decap them and they clear the memory. Okay, sorry, I misunderstood the question last time. Yeah, even if you open the box you cannot really read anything out of the TPM. These are exposed to memory, they're all protected by the TPM itself. The chips have like extensive measures for tamper protection. But was it in black or deaf for some of the chips, these protections have been broken out but they are constantly developing... The manufacturers are constantly developing better methods for tamper protection. So one thing I forgot to mention is please if horror asks questions, introduce yourself. I think it will help networking and things that people know where to find you after if you want to discuss more. Please next question. Yeah, this has been from Intel and I'm working on virtualization for actually one of tasks for TPM virtualization. So my question is do you know if there is an TPM compliance test suite so that for people who can write a software TPM, firmware based TPM or virtualized TPM then they can use a kind of test suite to make sure our implementation comply with TPM 2.0 specification. As far as I know TCC has one but maybe... Yes, I haven't used it myself but I know that one exists. You can get it from TCC. From what? Trust computing. Yeah, they provide a test suite too. Yes. Okay. I'm not aware of that. My name is Angel Stilanov. I'm working at SiteGrammed hosting. We are a hosting company which pays a lot of attention on our customer security. So we are using TPMs. My specific question is why you keep all the source codes and all the tools and everything about TPMs closed. It seems more like security obscurity rather than making the software running inside the TPMs table and reviewed by the community. Why? So can you... Why don't you share the source code with the community and to running inside the TPM and to... We don't know. Nobody knows. All right, you mean the TPM implementation itself? Yeah. That's a question that I really cannot answer because I just... I work on a different side. I develop support for TPMs in Linux. I don't really have answers to the question. Yeah. Okay, is somewhere available the source code of trust zone running inside the TPM? Mark Rowland, Linux security, whatever. There are a ton of TPM implementations out there. So it's really going to depend on your system vendor and you have to speak to them to try and poke whoever provided them with their TPM, whether that's firmware or hardware, and then get for the hardware implementations the source code for that. Yeah, it's a standard. There are many implementations out there. Even on the trust zone side, there are tons of potential implementations of TPM that might be using different TEs. They might be custom built for particular socks. You really need to talk to the system vendor to try and get that rather than the architecture vendors. So it's best to look in the TPM implementation that Microsoft posted in public for the expect. Okay, but they have specification. They don't have specific implementation. And actually there are so many versions and revisions of the TPM software running out there in the fields that actually nobody knows what has exactly inside his TPM. And nobody knows, has anybody from the community reviewed this code actually? I guess that's probably indeed a question to a vendor. Hi, Luke Hines from Red Hat. I'm relatively new to TPM, so this might be a rudimentary question. But I've been trying to learn more about the event log. And specifically, is this something that's generated in the kernel? Or is it like a vendor specific implementation? So they populate these PCR entries and then create the event log. I'm not able to track down, it seems a bit elusive, this event log, how I can maybe generate one or obtain one to be able to look at the measured boot. Yeah, well it's generated by the firmware or BIOS. I see, I see. And it's of course completely untrustworthy, but since you can get the final measurements from the TPM and you can get them assigned, you can then kind of replay it and check if they match the final values and then you know whether it's tampered or not. Understood, yeah. And so do the BIOS manufacturers, do they work with various other vendors to know the good signatures for a particular object? Or is it like a root of trust, you have your initial measurement and then the others are? This might be simple TPM stuff, perhaps I need to read the manual, but I'm finding it quite hard to get the information. I don't think there's any publication of good measurements. Understood, okay. I think if I remember right, Matthew Garrett was proposing something like this, but I think, was it for the OS images, I don't remember. So I'll get running from here. So hi, Karl Daniel Haifinger. One question, you mentioned the TPM Gini coming out last year I think, or one year ago roughly. The talks about attacking the bus to external TPMs and publications about that have been existing since more than three years ago. So what took you so long to address this? It's been three years and only when somebody starts releasing hardware, people start to care about the attack. Doesn't really sound secure to me. So I'm not sure if I completely understood the question. So do you think that the measures that we are taking do not solve the problem or? No I think they are two years too late, because well the counter measures only started being implemented after release of the TPM Gini. That the attack itself, attacking the bus has been public more than three years ago. So what happened in the two years between somebody published a possible attacks and somebody released the TPM Gini. So apparently nobody cared. There were some mailing lists carrying this, I don't know if that was a scientific publication, but the mailing list carried this. Well the corruption protections were landed like before the conference where TPM Gini was represented. The spoofing side, well it's a non-trivial problem. It just has taken this time to find a solution that all the parties can agree with. So it just has been slow. I'm Monty Wiseman by the way from General Electric. I'll answer the question about the event log. NIST has a draft out there, 800-155, which is going to, it's a draft right now. TCG is currently working with NIST, TCG the organization that defines the TPM as working on revising and making that draft final. And producing a requirement for the OEMs to publish the expected event logs for the firmware. So that's expected at the end of this year, maybe beginning of next year. No questions? So the thing about this attack against the TPM chip was that Linux is currently, Linux default installations from distributions don't use TPM for anything. So attacking the TPM chip against the attacker nothing because it's just easier to attack the PC or bus or whatever other buses they are in the Linux system. And what I like to have noise when the vendors will start actually using the TPM for something useful like providing encryption keys for hard drives or validation system installation other than just the kernel and modulus because the current Linux secure boot system is just useless. It gains you nothing, it gains you no security. Well, it's being used, but not that much in general purpose PC computing. It's widely used in data centers. Well, it's using Chrome OS, but yeah, that's true that the uses are more like application specific at the moment. So it's more used in industrial level than in consumer level. Windows Bitlocker uses the TPM by default if it's there. That's the default configuration of the TPMs there. Just to seal the full disk encryption and Bitlocker inside the TPM. And that was the original use case. No more questions? There are no more questions. I guess we'll have to first thank Yarko for the tool.