 So let's make sure this is plugged in I don't do that for anything. Yeah, but the problem is it creates a resonant sound on the stream Okay, it's not connected. It's like oh, well, I see you It's like you're doing to a spear All right Time to roll All right, let's do this I'm restoting. I'm And the well be you product management Talking about hardware ridder's trust today Presentation that we're going to be going through is jointly developed by myself and half your maintenance canilas engineer working who actually wrote the system that we're going to be talking about today Unfortunately, he's not able to join us. So you get me for the entire session Not just the exciting bits so what we'd like to do today is talk about the concept of trust and what that means and Delving some different aspects of it. So, okay, what do we mean by trust? We're really Talking about the system is what it claims to be So that you know who you're dealing with who the system is you know things about the system We know that the the system and that the data that is on the system have not been modified or corrupted in either way Incidentally the only real difference between modification and corruption is corruption is accidental cosmic radiation and so forth and Modification may be authorized or may be malicious, but the net results can be the same A key element is that people who are authorized to have access to the system have to be able to get access to the system Otherwise the system is useless the counterpoint of that is that unauthorized access has to be presented and The reason for worrying about all this stuff is that the results that you get are what they should be so the I mean really powerful approach to this is to use cryptography to Address a lot of these concerns Now when you start dealing with crypto one of the things people tend to worry about is the crypto algorithms is this algorithm secure So this would be compromised is what about? okay mainstream crypto algorithms are solid and are well understood and today the weaknesses are Not in the algorithms themselves the mathematics is sound the mathematics is strong Yes, there are changes over time all this stuff does evolve But when you're looking at crypto the absolute last thing that you should be worried about is the algorithm Unless of course you're doing it yourself rule number one of crypto do not do crypto yourself rule number two of crypto see rule one if you're using the Crypto shipped with the system the algorithms are solid Next thing that gets a lot of publicity key length. Yes key length is important key length is a trade-off between execution time and Resistance to attack so it's a balance that changes over time You've seen the things where we've gone from our RSK's keys of 128 bits to 256 to 512 to 2048 and a lot of the focus today Is on 2048 and 4096 which look like they're going to be solid for at least the next several years So pick a recommended key length and don't worry about it move on What else? implementation Yeah, now we're getting into some real concerns One of the biggest weaknesses today is at the implementation we've seen that anyone heard of something called open SSH and You may have seen some Information about that over the last couple of years The algorithms the current algorithm the old stuff has been compromised, but the current algorithms inside open SSH Are pretty solid? So we've discovered a number of issues with the implementation of those now the thing is that there are teams of people addressed in both breaking and fixing the implementation so a lot of progress has been made there, but Implementation is a concern sideband attacks Spectre note down This one is a very real concern There have been a whole series of sideband attacks through the history of crypto Ranging from power attack power monitoring to timing analysis to The latest hardware based attacks So sideband attacks are a very real concern and something that you need to keep track of now Part of crypto is running the crypto. That's the stuff we've been talking about so far The other part is feeding the crypto with the keys so key management and Key security is a huge factor There are multiple ways that keys can be exposed now the first challenge is keys have to be Visible to be used so if you're going to be using crypto you have to have the crypto key to encrypt or decrypt So you've got opportunities for key disclosure on disk If you have The key in a text file Okay, that's probably not the most secure thing you could ever consider doing Keys that they have to be in memory to be used they're going to be transmitted some way to get on the computer in use and my favorite vulnerability people so And in this cure environment Your passwords are written down on a yellow sticky and stuck on the monitor and a secure environment Your keys are written down on a yellow sticky and stuck on the bottom of the keyboard In a very secure environment your key passwords are written on a yellow sticky and put in a desk drawer and then an ultra secure environment The desk drawer is locked So when you're dealing with crypto The Realistically the biggest exposure to focus on is the people Well having a breakfast discussion with some of my colleagues and they were Informing me of the strengths of some of the approaches that were being discussed and To reply to them Very pointedly Mathematics are strong people are idiots So in looking for all this stuff consider What you need to be worried about? and The system has decided to cooperate with me and The system has decided to completely lock up. That's Yes, it is The only secure system the only truly secure computer system is one that is disconnected from the network powered down Ground up into small pieces melted into slag cast into a block of concrete and Dumped into the deepest part of the Mariana's trench and even then I'm still not convinced. It's absolutely secure So yes, that's the thing so One of the tools that we have for addressing this is to use a hardware grid of trust Software is inherently vulnerable Hardware, it's not perfect. There's still a tax that can be made on all this stuff But a hardware road of trust is more secure than a software So starting with the hardware would have trust and learning the software pieces on top of it is a stronger approach So what is the hardware road of trust? It's a dedicated security processor a specially designed limited function special purpose hardened isolated Piece of hardware and related software designed to do a specific set of things So it's not general-purpose computer. It's not something that you're going to run web server on But it provides some foundational pieces for building the rest of it. So what are some examples of it? credit card chipped credit cards the chip on a credit card is actually a hardware security module Very limited very fixed function Very slow But it's doing a pretty good job of protecting the financial system Not perfect, but it's a lot better than we what we had before Yubi keys God bless them. It's the only thing that makes the Network tolerable today high-end hardware security modules such as These systems which are used in banking and other systems that provide both security and high transaction rates and The one we're going to be spending some time on today the TPM or trusted platform module All right TPM couple of versions out there TPM 1.2 which sucks and TPM 2.0 which sucks less TPM one dot yes someone was going to suck slightly less Fair enough, but it does make a difference. So TPM has been around for about 12 years now and TPM 1.2 the way I describe it is billions installed hundreds used So we got an interesting little situation here in that we've got a Real security problem We've got a tool which can address critical bits of that security problem and No one is using it So what's what's going on here? Our people idiots well number one we've already established that But there are some technical and some business reasons behind that TPM one TPM 1.2 is Simply a nightmare to work with To the point that there is one production use of TPM 1.2 chips out there, and that is Microsoft bit locker new version TPM 2.0 Better capabilities much better capabilities much more flexible a lot easier to work with at multiple levels and TPM 2.0 is the foundation of what we're going to be talking about today Okay, I Just asserted that there are Billions probably tens of billions of TPM chips Installed today, and they're not being used. This is largely our fault and By us I'm speaking to the IT industry because we haven't Built useful capabilities on top of TPM. We've enabled it We've given people the ability to build stuff, but we've not delivered Directly useful capabilities that end users can use to generate business value Okay so if we won't TPM 2.0 to actually matter We need to do a couple of things one we need to implement the infrastructure to support it and In many cases we ourselves in the back and go job done next No, no, no, no The fact that something is possible is a starting point not a finish point We need to do something useful with it for people to actually care Let's see a number of laptops out here People on the laptops is your system disk encrypted. Thank you I'm really glad to hear that You're using you're using servers you're using cloud systems are Those encrypted and if not Why not? So what do we care about this? One specific example is this turned up about a year ago. So What external mailing list? Was down Yes, I know if the site's back end is hosted on the machine at home, which is waiting for someone to Enter a lux passphrase to boot the system after a power failure Lux is a solid disk encryption system It works. It's got low overhead the mathematics behind it or solid It's pretty good for data volumes But outside of the laptop and desktop use case. It's a pain because you have to Manually enter that bloody lux password Every time you boot the system Now I'm not going to ask for a show of hands except for myself but How many people have? Good lux passwords, you know that thing that you type in every time you boot your system Is it long enough? Is it a good password? So If you're supposed to raise your hand if you've got a solid lux password on your laptop I'll admit it. I'm a bad person. I've got a lux password that is easy to remember and easy to type It's still reasonably secure. It's a lot better than not having one but I'm a bad person here so What can we do? So we've got some new capabilities that let's say that we've got a Server let's say that we've got a virtual machine and Well, let's actually get the correct one here which side of the System is it on? So we're booting a system. We're waiting for the lux passphrase. So let's don't type anything in. Oh Someone just escapes and we're watching the system boot. So just a minute. We've got a lux encrypted system and It's booting without anyone entering the password So is your initial response that there's a bug here and that someone has done a very poor job with security? That's one explanation Another explanation is that we have started using network bound disk inscription in BDE We have the ability to have the root I have the lux password for the written volume provided by an external source in Addition to the manual input and then we can be using this either with the classic MBD implementation of a tang server or now we have the root password stored in a TPM to chip and Being automatically made available as part of the boot process so just saw a system with automatic boot into the Lux encrypted system volume going up through a running rel7 system with a user login Okay So let's see if I can escape out of here Because we still have a Hitting the I'm hitting the wrong one because we still have the lux password No It's because I can't see on this screen. So I have to try to find it on that screen We have a lux password in fact since it's not being manually entered We've actually got a nice long secure lux password that is stored in either It is accessed through either a tang server or a TPM to chip so there is a lux password it is secured there and This disk will not boot Anyplace else I take the disk out of the laptop I take the disk out of the server I take it anyplace else and it won't boot. It's a fully encrypted disk. So we've got Lux protection We have a long password and we have Automatic boot, but the disk is useless if it's removed from the server or in the case of MBD Network if it's removed from the data center, thank Nathaniel Yep, so we still have authentication just a slightly different style of it Okay, so what does a TPM do for you random number generation hardware-based random number generator? So it's got good entropy and you can get good random numbers out of it If you've got random numbers, you can get good key generation and the key generation is entirely inside the TPM Keys are secured inside the TPM Keys are not visible outside of the TPM So one of the key things to use in this approach is that the keys the actual keys are never visible outside of The hardware security module Yes So the question was does that mean that we the user never know what it is There's kind of a yes and no for that We know we have to know what the Lux key is, but there is a key encrypting key inside of the TPM and we never know what the key encrypting key is so we take the Lux Passphrase the encrypted version of that we pass it in to the TPM and we get the actual Lux password back out There are some other ways of approaching this you can do key exchange with the TPM, but Because the way Lux works. We're just doing a straight. We have a wrapped Lux passphrase that is decrypted and returned back Nathaniel So some other things here encryption and decryption slow, but secure it can be used for machine identification It can be used integrity measurement and system health attestation Alright, so what's in a TPM? You've got a set of things we discussed you have crypto encryption and decryption engine. You've also got non-volatile and volatile memory and The volatile memory is well, okay keys. We were discussing the keys so the TPM particularly TPM 2.0 is designed to support an Unlimited number of keys it does this through a couple of approaches One is that there is a key hierarchy Hierarchy where keys are generated from the seed value and can be regenerated on demand. So basically if you have the seed which is never available outside of the TPM and a index into the hierarchy you can get the keys out and ordinary keys which you can think of it as having a encrypted key Stored outside the TPM the encrypted key is passed into the TPM and then the plain text key is returned so key point here is that You not only have the ability to Generate and store keys inside the TPM But you have key hierarchies and you have the ability particularly with TPM to to have a Unlimited number of keys. So this is reducing one of the major limitations of TPM 1.2 Okay, another interesting thing about TPM Carry over from TPM 1 improved in 2 is you have something called the PCRs platform configuration registers these are interesting because They don't just hold value the way they work is You write a value and the value is hashed and then you cannot update or modify The register directly you essentially append new information to it, which you take the previous value of the PCR you Concatenate the new value with it and then you hash the result Now the result of this is that you can store a series of measurements in fact a Unlimited series of measurements into a single PCR and be able to essentially replay that tree and validate that The one you get from looking at the individual measurements matches the one in the TPM We can spend some extra time on that, but let me just Jump to the end with this is a very powerful capability for Measuring and examining the system because it gives you the ability to look at a lot of different measurement points and store the measurement points in a very small value and You can then Check a test verify that nothing has been modified by checking this single final value so in Some ways it's kind of similar to a hash table where you can have a very complex Value that is abstracted in the hash and you do the search of manipulation against the hash a lot of power and capabilities Here, but it takes some quality time to figure out what this means and how it works big improvement in TPM to is that the user space for Working with it is much better so You got your TPM device driver, and that's more or less where we stopped with TPM 1.2 a huge issue with TPM 1.2 is that it was a single instance and Everyone that wanted to use it was responsible for managing their entire interaction with it The result of this is that TPM 1.2 systems were extremely difficult to share Between applications, so if you had two three four applications that wanted to actually use the TPM they were each responsible for Everything about that and it was just a nightmare This is one of the big things that's addressed in TPM 2.2 2.0 you've got a resource manager and an access broker which is basically a Mechanism for abstract in the TPM you have serialized access, so you have Ability to control who accesses it and in what order and You have some abstraction mechanisms such that the context or the state of each user is carried by that user So that you can have multiple applications interacting with the TPM Each appearing to effectively have sole access to the TPM This as much as anything else is what makes TPM 2.0 actually usable now there's a number of things there are higher level interfaces that Provide higher level functions and make it a more civilized environment I would actually argue it's not so much that it sucks less as that it sucks much less than 1.2 so there have been huge improvements in both the functional capabilities and the usability with TPM 2 Okay Would anyone be terribly shocked here that there's more than one TPM 2 software stack There's actually a couple that we're Shipping there is a one originally developed by IBM Which was the first available and then Intel has actually been implemented one The Intel version is a implementation of the trusted computing group TCG TPM 2.0 specification so the argument is that the Intel version is standards compliant and They've only recently released final versions of some of the top layers of the stack the reason for mentioning this is that we are focusing on the Intel stack, which is the TCG compliant stack. So we're supporting the TCG standards both at the low-level TPM module itself as well as the full software stack driver resource manager up through higher level application interfaces Now the magic For the demonstration we saw Is network-bound disk encryption which uses Clevis and Tang Tang is a network server and Clevis is a module that is added to the boot path added to the NetRAM which Will interact with several different services today We have Let me see you go through here The key thing about it is that I've got four minutes. So I need to talk even faster the key thing about this is that Clevis handles Providing the luxe password Clevis can use multiple inputs to available today are Network through the Tang server and TPM to there are plans to add additional Sources in the future. So this started out as something pretty simple and it's remaining pretty simple, but it is showing some very interesting capabilities in Crypt and decrypt from the pins. It uses the Jose Interface for the crypto pieces and has anyone here had any experience with a PKI public key system Was it a pleasant and fun-filled experience did it give you relaxing days and no problems Dreams or nightmares so What's happening is that rather than having a full PKI implementation the actual luxe passphrase is encrypted and stored in the luxe metadata and We have access to a variety of tools for Decrypting that it's still managed, but we need to manage the key environment But we don't have to actually provide full public key management of the individual keys It's a little bit subtle. It's something that causes people concerned the first time they run into it but it actually has a high level of protection and It completely sidesteps the nightmare that is PKI So how does it work? Clevis basically takes pin configuration and data does the encryption ends up in a key store on the decryption side it goes to the key store does its magic and Provides the key using Clevis for Luxe We've got the Luxe binding coming down it can be and stored in either a TPM module or on the network server and I just lied to you one of the things that's interesting about Clevis is that it supports policies and today you can have either TPM or Tang or both So this gives you some very interesting capabilities Implementation we started working with TPM in rel 7 TPM 2.0 and rel 7 3 based implementation driver user space and tech preview user space in production and The TPM 2.0 support in Fedora We delivered the TPM to capabilities in Fedora 27 Fedora 28 has this and I would encourage you to use it Okay, what's next we're looking for other places where Hardware road of trust can be used to provide direct customer benefits We've got some really powerful technology here now. Let's do something bloody useful with it for a change Yeah, yeah, and We'd like to invite you to help us with that looking at some change Possibly using PQCS 11 as a standard interface to all the various crypto and Hardware road of trust We're looking at addressing the system management and usability pieces We've got a lot of things that we think can be Usefully addressed using these capabilities and of TPM other hardware road of trust and network and other system capabilities and I'd like to do something novel by letting you follow up on this Directly if you have any interest in this there is a excellent book on the subject a practical guide to 2 p.m That is so well-written Even a product manager can understand it not easily but with enough work Now this is interesting because it is available as a hard copy. There is also available as a ebook for free so Do a search for a practical guide to TPM free ebook download it and read it Trust a computing group is behind all of this information on the two TSS packages and information on Clevis and I think I've probably used absolutely all of my time, but we've got a few moments for questions So we do have some time so so I will be happy to Address any questions you might have because for once I'm not running over on someone else So very naive question, but how do you check that the API is who you thought you believe you're talking to? Okay, so it's it's one thing to have hardware root of trust with software root of trust with the API How do I check that? that is actually one of the key capabilities that can benefit from a hardware root of trust the basic idea is that You perform a key exchange with your hardware root of trust the hardware root of trust Will generate a public key private key pair The private key is never visible outside of the TPM so if you have the public key you can do a key exchange with the TPM using the TPM public key and Verify that you are in fact talking to that specific TPM. I Think they gave us the longest room in the entire building. Yeah, I sat in the back of the room Yesterday, and it was impossible to read the slides. So this is much better So since now you're placing all your trust in the TPM module It to my understanding those are still All closed firmwares, do you know if there's any work on free software implementation of TPM? there is that actually touches on something that I Didn't mention because it was going down a little bit of a rat hole, but there are three implementations of TPM now TPM is a specification and It can be implemented in different ways The ways of implementing it are hardware TPM, which is the hardware module that gets plugged into the server Infineon, Jamalto a few other people are doing those I can set up these this the most secure implementation also the slowest TPM can be implemented in system firmware, and that has been done by Intel for example in recent generations of their processor and chipset that they have a Firmware TPM so there is no external hardware You can also implement a software TPM, which is widely used well Becoming it is becoming more available, and we hope it will be widely actually used in Hypervisors where you have a software TPM as part of the hypervisor environment typically as part of QEMU or the equivalent and I believe there are Plans to Provide TPM 2.0 implementation in future versions of QEMU and this is a software Implementation which you can examine the whole thing It does not have the hardening that you get from a hardware implementation But it is a implementation of TPM that you can examine now I'm not sure what the the underlying concerns are whether you're concerned about Secret leakage or you're concerned about correct operation if you're Concerned about correct operation you can do things like do operations against a hardware TPM firmware TPM and the known Software TPM and see if they give you the same results, which okay, that can be useful Not trusting the hardware vendor for secret leakage. Yeah, that's a concern Yeah, I mean my concern was more specifically about the TPM being embedded device in your system that you know You don't really know what it's doing and if you can't audit the firmware on it then you know How do you actually really trust it? It is a leap of faith Yeah, thank you now in this case. I would argue that it is a Justifiable least leap of faith because you have people that are building their business on Building and shipping these chips these chips are being attacked day in day out and if there are weaknesses either Accidental or deliberate it impacts their business and this is a small constrained environment I'm actually much more concerned about the host CPU, but I acknowledge. Yes valid concern Thank you Microphone So it's actually not true that you have to put all of your trust in the TPM Clevis does all have policies for doing crypto and the way that you combine the various different pins is with a pin called Shamir's secret sharing which actually allows you to fragment the key Using a polynomial and so the degree of the polynomial is the threshold for how they're combined The unique feature of this algorithm of course is that if there is a compromise to one of the fragments You learn nothing about the actual root key that's been divided, right? So if you were to combine TPM with some other policy and your TPM is completely lying to you or completely Compromised in some way then there's actually no nothing gained from that So so Clevis does give you some protections for that Yeah, I'm really glad you mentioned that just quick follow-up on that on the TPM secret sharing thing We're working with a researcher in Brno Petters Fenda if anybody's here from Brno, you probably know him Who has done secret sharing across? Large numbers of smart cards. So for example, you can take a hundred smart cards and secret share a key across all of them And the likelihood of being able to break that key goes down with you with every additional smart card you add So there's lots of interesting things you can do with multi-party computing and and TPMs to make them easier to trust absolutely and note incidentally that Clevis has a Policy engine and is pluggable and as mentioned supports the Shamir's shared secrets which means that this is actually a surprisingly simple starting point which has a lot of characteristics that aren't immediately obvious We're gonna have fun the next few years and I we're going to be doing some things that actually make a difference for our users and our customers All right. So right now. We have a coffee break downstairs in the lounge. So if you have any other questions or want to talk to the speaker You can probably find him down there So thank you to the speaker. Thank you And also there is a party tonight. It's gonna be the most fun party ever according to the fun committee And so I think if you don't have tickets you can get them at registration So quote me on that and if they don't have it then come back to me Yeah, thank you I