 Our next talk is going to be by James Bottomley about enhancing Linux security with a TVM. Thank you. Okay, well, hi everybody. Thank you very much. My company communications department told me to always put the email address, and apparently they insist on a Twitter account as well now. My email address I'm responsive on, my Twitter account is pretty much right only, so please don't use it. I'm originally a container evangelist. I've been doing open source for a very long time. I've actually worked a bit in converting business models to open source, and I'm also a kernel developer. The only thing you should probably notice from this impressive CV is that security isn't on it anywhere. The talk I'm going to give you about the TVM is talk about something that actually just annoyed me personally in Linux and I determined to fix in the tradition of open source. So TVM is not actually one of the things that was my natural area of expertise until one day I got really annoyed with the USB key dongle. So to begin, let's talk about security and trust. Everybody needs help protecting secrets. That's why whenever you have a private key, it always comes with a password, because there's always situations where somebody else who's malicious can get in and run off with your private keys and then impersonate you on the internet, steal your credit card data, empty your bank account, or do all sorts of other things to you. And usually on the internet or in all electronic commerce we use some form of asymmetric private key, public private key system like RSA or ECC to represent our identity. So pretty much these keys represent who we are on the web. If you lose them, you lose your identity. And obviously if they get lost or stolen, you can be impersonated on the internet. The current state of the art for protecting your keys, if you're not one of these people who just uses a key store on your laptop and is happy with unlocking it with a password, is a key dongle. I did actually have one, but I lost it so I can't show you what they look like, but they're usually little USB keys that you plug into your laptop that store one private key. And this is a big problem because many of them only store one private key. But unfortunately if you're like me, I have about 12 keys on my laptop representing my VPN. I've got about five SSH keys. I've got about four PGP keys. I've actually got several CA security keys for a few things. So all of these keys mount up. And if I have to have one dongle per key, I end up with this huge key ring of dongles and I can never remember which one is which when I need to plug it in for my private key. So using a TPM instead of these dongles to protect your keys actually scales to thousands of keys. The TPM has no limitation as to the amount of keys it can actually manage, which makes it a really useful entity for actually doing this. And the other thing about the TPM which is really useful is it's fully ubiquitous. Everybody who has a laptop in this room today has a TPM sitting inside that laptop. Now not everybody has TPM 2.0. The reason we're getting TPM 2.0 is because it's a Microsoft mandate for Windows 10. But all modern laptops now ship with TPM 2.0, which is what I'm going to talk about. My Dell Skylake XPS actually shipped with the TPM 1.2, but it was software-upgradable to TPM 2.0. So that's basically what I did for this. So the TPM itself sitting in your laptop is a separated security module. So it's a little chip that actually sits outside the main CPU and it has its own access to shield and memory. That means anything you put into it can't be extracted by the CPU of the system, which is useful. And they've been ubiquitous in your laptops for a while now at the 1.2 level. The main problem with the TPM is they actually have a horrifically bad programming experience. I mean, really, really awful. And I speak as one who's actually tried to use it in the 1.2 incarnation. They have a body of people who look after them called the Trusted Computing Group. And they mandate this thing called the Trusted Security Stack, the TSS and shorthand jargon. And it is really appalling. You don't need to see this. All you need to see is that the TPM, the actual thing sits down here. The rest of this crap is the Trusted Security Stack that you have to use to get the damn thing to work. Now, in Linux, we had a 1.2 TSS implementation called Trousers. Almost nobody will have that installed on their laptop. Most distributions do still package it. It had a few problems with the conversion of open SSL 1.0 to 1.1 and various other things. Its implementation of that huge model is actually three-tiered. So it has your application that you link with the Trousers library. It has this thing called the Trusted Demon that actually has to run in your system, started by SystemD. This Trusted Demon communicates with the kernel TPM driver which communicates with the TPM. It looks simple. The problem is that in order for the application to understand how to use Trousers, it actually has to understand all the library interfaces. So it has to understand the Trousers API. It's fine. Then you have to understand how the TCSD actually interacts with the kernel TPM. And finally, you actually need to understand how the TPM works. And the problem here is that there is no encapsulation between any of the layers. So understanding leaks all the way up and down this stack. And that means that if you just understand the TPM, you can't program Trousers. If you just understand the TPM and TCSD, you still can't program Trousers. You need to understand all of these three components. The amount of information you need to understand is three times more than is actually necessary. And this has proved to be an almost insurmountable burden for application programmers. With the net result, the Trousers API is almost never used, unfortunately. The API is actually quite useful. The idea is that the Trousers library itself does all the HMAC authentication, which means the TCSD doesn't really have too many secrets in it. There are ways when secrets actually flow that way and that way, the TCSD could intercept them. So it does represent a security problem in your system. But by and large, the design is reasonably good. It's just the programming API is awful. So what we plan for TPM 2.0 is to try and do much better. And the problem here is that the Trusted Security Group thought that their model wasn't complex enough for 1.2, so they made it even worse for 2.0. So the actual functions that a TPM can do are shielded key handling, measurement, which is, if you've heard about Trusted Boot, this is usually the measurement functions, data sealing, that means you can actually put private data into a TPM and not get it out again unless you satisfy certain policy conditions, and attestation. The only one I'll actually be talking about today is shielded key handling, because that's the one that's most interesting to me. So with shielded key handling, keys in the TPM are stored in hierarchies with a well-known key at the top. And I use stored and inverted commas because everybody thinks that the TPM is a place to put keys, but it's not actually true. When a TPM manages your keys, the keys are actually stored in your file system outside the TPM. I'll get onto that in a bit. But the only thing you need to know is that as far as a TPM sees it, keys are always stored in hierarchies with a well-known root at the top. The root is a key that's actually embedded in the TPM. And asymmetric encryption keys, which is what we use for identity, are stored in something called the storage hierarchy. So the TPM itself has four hierarchies. I'll only be talking about one, which is the storage hierarchy. The great thing about TPM 2.0 as opposed to 1.2 is it features algorithm agility. So it can actually do many hashes, it can do many key lengths for RSA, and it can do many elliptic curves, and actually any other different cryptography that came along, it could probably do it. Post-quantum, not sure about, hasn't come along yet, but eventually when it does, there would probably be a TPM 2.0 specification for it. TPM 1.2 was restricted to SHA1 and RSA 2048, and since SHA1 is now a suspect hashing algorithm, it makes TPM 1.2 not very useful for most of the identity stuff we're doing because everybody is now mandating SHA256. So the days of actually using TPM 1.2 for security are numbered. The way TPM 2.0 works with its agile key handling is that instead of generating a key that sits at the top of these hierarchies, it generates what's called a seed. A seed is just basically a random number that can be used to derive a key. So the TPM 2.0 goes from seed to key via something called a key derivation function. These are sort of complex cryptographic things you don't need to understand. All you need to know is I place a long random number in, and the output I get is a public-private key pair for any algorithm. And obviously if I put the same number in, I get the same key pair out. That's the essential thing of a key derivation function. So the TPM doesn't really need to know the public-private key pair for any of its crypto agile systems. It just uses the seed to derive it. And that means that if any additional crypto was added, it could still use the same seed to derive the same key pair. The problem with these key derivation things is that for RSA, the key derivation function involves finding prime numbers. And the TPM itself is a very small, very slow mathematical engine. It takes a long time to find prime numbers. This means that if I actually... TSS-CreatePrimary is the command you use to tell it to go from the seed to an incarnation of the public-private key pair. So I've actually told it to generate an RSA key from the storage hierarchy. And if you look at the timings you see it took... This is on my actual laptops. This is one of the more modern Nuviton 6X TPMs. It took it 43 seconds to generate the public-private key pair using the prime generation functions. So this is not something you want to do with every cryptographic operation. Obviously elliptic curve keys can be generated much faster because of the way elliptic curve works, but RSA keys take an age to generate. The storage seed changes if the TPM is ever reinitialized. So this means that if your security is compromised, you can just reinitialize the TPM and every key you put into it is wiped because they can no longer be understood by the TPM itself. Keys to be inserted into the TPM are encrypted based on a known public key. That known public key is the root of the storage hierarchy, the storage seed, or the key you derive from the storage seed. And that means that only the TPM itself can decrypt them when you put them in. So this is what the security of the system relies on. And once a key is actually translated to TPM form, it cannot be translated back. So once you have the TPM form of a private key, you cannot go back to the non-TPM form. So it's a one-way function. You don't get the key back ever. This means it can never be extracted, which is useful for security. So if I tell you about TPM 2.0, like 1.2, as I said, the trusted computing group is writing a trusted security stack for it. And it looks like this. So it's got their usual levels of complexity. In fact, it's got a few more levels of complexity. New things have appeared like a resource manager for various reasons. And the API, instead of there only being one API at the top, there are now technically four, because TIC-T itself is also an API. So we've got about four times the complexity we had in 1.2, which most people agree was an unusable API. And the problem is that it's still not complete. If you actually look at this, as far as writing all of this, the resource manager spec isn't quite finished, but it's about there. System API exists. ESAPI is not standardized, and the feature API is still going through some weird iterations that I didn't really understand. And in theory, a resource manager is now required for TPM 2.0, because it has space for only three transient objects. Every key you insert into a TPM is effectively a transient object. That is why the TPM itself doesn't store your keys. What it stores is an offline representation that you load into the TPM when you want to do an operation, and then unload again. And the reason you have to have a resource manager is because if I have many operations trying to do this, they're actually going to overflow the three-object key space. So if on my laptop I'm running a VPN, and I'm running my GPG, and I'm running my SSH, if they all try and do a signature at once, the TPM is going to run out of space. And the resource manager actually ensures that the TPM doesn't run out of space because it manages the transient object layouts. And as of the Linux 4.12 kernel, the TPM 2.0 resource manager is actually present inside the kernel. So you can just rely on the kernel to do this. You don't need anything else, fortunately. Intel is actually building a trusted security stack to this TCG specifications. It's up there on GitHub, under the Intel GitHub account, TPM 2.0 TSS. I'm currently, unfortunately, unusable for my crypto applications because I need secure key handling going in and out of the TPM, and I need secure authentication handling. And it just so happens, those are features of the thing called the ESAPI API, which currently isn't standardized. So the Intel TSS does not currently have ESAPI. As of today, I think two days ago, they posted a message to the mailing list saying they were actually working on ESAPI and would get it based on the beta version of the spec. So perhaps they will, at one day, have it, but right at the moment, they don't. IBM has actually built a fully functional trusted secure stack, and it's fully complete. It's sitting on SourceForge at IBM TSS 2.0, but it's based on the TPM 2.0 commands. It's not actually based on any of that complicated TCG stuff. So if you understand the TPM commands, you can actually use this IBM stack, which is actually very useful for me because it means that I only need to understand a very small piece of the trusted secure stack actually to get everything working. And the great thing about the IBM TSS is that it does all the necessary crypto for HMAC and command parameter decryption and response encryption in the background, so I don't need to worry about that. So it's as functional as ESAPI would be from the security point of view, but it's just based on the TPM commands, which I find very easy to use. And the other really great thing about it is it makes a direct connection to the internal resource manager itself so it doesn't rely on a demon. And the reason this is a great thing is because some of the demos I'll show you, before I did this for TPM 2.0, I did it for TPM 1.2, and I actually have a TPM 1.2 laptop sitting at home that I used to use, and the user experience was frightful because every time the demon crashed, all of my keys were lost and I had to re-initialize all of the crypto system. So this meant that the demon would just crash and I wouldn't notice. My VPNs would all collapse. My SSH commands suddenly wouldn't be able to re-authenticate. So I'd have to restart the demon, shut down my VPNs, stop my SSH sessions, do everything else, and then restart it all again. The user experience of the trousers demon is terrible. Now, I do believe that we do understand how to code demons essential to system function that don't crash. So it should be possible to fix trousers. It's just that nobody understands it well enough, and nobody can be bothered actually to go in there and do this, which is why it's still a horrific experience for everybody concerned. So I regard having no demons in the IBM TSS 2.0 stack as an enormous plus point because the IBM 2.0 TSS has just worked for me from day one on my laptop, which I think is very useful for a security system. And without ESAPI, that also means that the IBM stack is the only current choice for becoming security-related functions. Security-related function is anything where you need to secure the communication between your application and the TPM because you're using it to pass secrets. So that's anything that requires authentication, anything that requires the passing in of private keys. You require security on that channel because the TSS does not mandate any. The TPM can actually be connected over the Internet to your application, and the packets, the command packets that it sends over the Internet are just effectively the ones that you placed into it. And if you don't use the security functions of the TPM, it'll be sending your private keys over the Internet in clear form, which you definitely don't want. So to build a secure cryptosystem, you actually need to understand only five TPM commands, which is useful. There are a couple of hundred TPM commands, but I can actually build a secure cryptosystem only understanding five of them, which means that the amount of the, even the command API I need to understand is fairly small. It's still rather complicated, but it is fairly small. So there's this command called TPM to create. This creates a public-private key pair on the TPM. You use this if you want a public-private key pair that's actually tied to your laptop because that key can never be removed from the TPM. That means that if you change laptop, you lose the key. It has this thing called a parent handle where the parent and the hierarchy is. You usually use the storage root key for that. It has an authority parameter, which is basically a passphrase you put into the key. So obviously, when you're creating the key, you have to secure this. And then it has the public key parameters, which tell it what you want, like, you know, I want an RSA key, I want it to be 2048 bits and so on. There's an import command, which you use to import external private keys. This is mostly what I use for programming cryptosystems because my private keys mostly exist. So for instance, when I use it with GPG, I want to take my certification GPG key and just place it into the TPM. I don't want to have to regenerate a new GPG key and spend two years getting everybody else to sign it. The import actually takes the parent handle, the public parameters, and the actual private key itself. And the TPM will then spit back its form of it. So both commands actually do nothing to this TPM or volatile memory. All they do is they spit back two structures, a public key, which also has all the visible parameters, and a private key blob, which is only readable by the TPM. This is actually encoded usually with an AES 256 key, that is, was regenerated by the TPM when it generated the storage seed. So the point is that this is strongly encrypted and can only be decrypted by the TPM itself. But the public key is bound to the private key, sorry about the spelling mistake, by a hash. That means that even though the public key is in the clear and therefore you could alter the parameters, if you alter any parameters in it maliciously, the TPM will detect that and reject your key. One of the checks it actually does, not only does it check parameters, but it actually also checks the public key matches the private portion whenever you use it. But whenever you want to use the TPM for a shielded key operation, you have to present it with both this public and private blob before you can start that shielded operation. This means that you, the user, are responsible for managing all of this data. There's a command called TPM to load, which is actually used to load this public and private blob, and you tell it what the parent key is. This requires no security at all because the private blob is already encrypted and you don't care if anybody sees your public key. So this is actually rather a nice command. And then after you've loaded the key, you can use signing, which just works, or you can use decryption, which is what you use to decrypt messages encrypted to your public key. This is slightly cheating. I told you there were five commands, but if you notice I've got two commands, one on top of each other. This is because the way decryption works with RSA is not the same as the way it works with elliptic keys, and it can't be made to look the same. So signatures just look the same, whether you have an elliptic key, an elliptic curve private key, or an RSA private key, it just works. Unfortunately, you actually have to understand the difference between RSA decryption and for elliptic curve private keys, you don't actually have a private key decryption function. What you have to do is use an elliptic curve Diffie-Hellman with a temporary public key to actually give you a key agreement that you then use to decrypt the message. So the mode of using it is actually rather complicated, which is why you have two separate commands. But they basically both take the key handle of the loaded key, they take the ciphertext and the padding scheme, and then they will do the decryption for you. As I said, TPM20 keys are demand-loaded, meaning they're not resident in the TPM, unlike USB keys. And this is very important because it means that the TPM gives you back key blobs that you have to keep in a file somewhere. If you lose this file, you've lost your keys. You're responsible for the management, not the TPM. So it's unlike USB keys where the key is actually inside the USB key, as long as you physically have the USB key and don't lose it, you have access to your key. And like I said, the user is responsible for managing these. And TPM20 can only load three keys at once, so you are required to have a resource manager. Now, don't despair, if you have a kernel before 1.12, this, what I'm showing you, can actually work without a resource manager. The problem is that if you use it with too many keys, you're prone to getting an out-of-memory error from the TPM. That's the only real difference. So essentially, if you want to use it with many keys at once, you have to use it with a resource manager. So a little aside on TPM security, lots of sensitive information in the parameters to these commands. Things like the authorization passphrase, the private key and everything. These, you cannot be assured of a secure channel between your application and the TPM. So these must always be secured by the application. There are no ifs, ands, and buts here. One of the useful things about TPM 1.2 is that you couldn't get an insecure channel to the TPM. Whenever you're pressing private parameters, the commands themselves required that you set up a secure channel, which was very easy. TPM20 has what's called the easy button, where you can actually send commands in the clear to it because you pretend you're talking to it over the secure channel. But you should never ever, as an application, assume that you have a secure channel to the TPM and you should always use these encryption functions. So you should never use this TPM-RS-PW easy button. You should always use the proper parameter encryption. And you must secure all data in transit to assure that it's not intercepted by an eavesdropper who would then run off with this key you're desperately trying to shield. And obviously, all of this will be done by the missing ESAPI API when it magically appears. But in the meantime, it is all done by the IBM TSS, which is why I use it. So in order to use security with the TPM, you actually need an additional TPM command called start authentication session. This is a command that actually begins security in the TPM. This is actually a lot better than it was in TPM 1.2. With TPM 1.2, the parameters used for security were fairly fixed and could actually be guessed if the attacker was clever enough. TPM 2.0 uses nonces. So you send a nonce in and it sends a nonce back, and you use these two random numbers, one of which you produced and one of which the TPM produced, to derive the session key that you're going to use to communicate with it. You also have something called assault key which you use to secure secrets, and you can have a binding key, which you also use for a shared authority to secure secrets. Both of these parameters can be blank, but you do require some form of shared secret with the TPM to securely derive a session key that can be used to communicate with it. So if you're communicating with an authorized object, the TPM knows the authorization. You know the authorization. You use that to derive a secure key for the HMAC session, which means you don't need any of these sold keys or binding keys. However, if I don't have any authorization, so for instance, I'm trying to place a private key on the TPM that is actually going to run off the root of the storage hierarchy. The authorization of the storage hierarchy is usually known by everybody. It's a blank authorization. So I cannot use that for deriving any shared secrets. So I actually tend to use a salt key which is used to encrypt a secure parameter to the public part of that key. The salt key usually uses the parent key of the hierarchy. So like I said, each session can either be HMAC, which is used both to authenticate because you've got the authentication key in there, and also to check the parameters and the response. So it's like HMAC on the Internet. It's a key hash that runs over both the command you send in and the response you get back. So you know it cannot have been altered during transmission, so it ensures the integrity of the command you actually sent in. Then you have this thing called parameter decryption. The reason it's called parameter decryption is because all of the TPM specifications are written from the point of view of the TPM. So as far as the TPM itself is concerned, it has to decrypt the parameters. You have to encrypt them, but the TPM has to decrypt them. So this is called parameter decryption, and it's also responsible for response encryption, which means the TPM encrypts the response that sends back to you, and you can then decrypt it. If you want to use HMAC for integrity and parameter decryption and response encryption, you need three sessions to your TPM command. So you have to set up three separate sessions to get all of this. Obviously, then they all use separate nonces, and they're all reasonably well-secured, and everything works in a reasonably nice manner. And like I said, therefore, each command may have up to three sessions to ensure that you can do this. And parameter and response encryption require this thing called an encrypted salt. So they require that you know the public part of the key that exists in the TPM. This wouldn't be a problem except that I did say that you must have a known public key to get there, and the TPM itself only comes with these seeds, which means that somehow you have to take a seed and get a key from it. And like I said, doing that for RSA keys takes 45 seconds. You don't want to wait that long. So one of the problems with the TPM is that the TCG is still coming out with all of these guides. So in March of 2017, they published a provisioning guide which said that an RSA storage seed key derivation key must now be present at the permanent NVRAM index at 81001 in hex. So that means that if I have a really, really recent TPM, it will actually come with the RSA version of the storage key that I can then use for public parameter encryption salting. So I don't need to run this key derivation function every time that I use the TPM. This is a great time saver. Fortunately, on all TPMs that ship before November, there is still a way of setting up this key. The only thing you really didn't know is what NVRAM index it should be at. Now we have a well-known NVRAM index. Every time you install the IBM TSS, it goes and looks in this index and says, is the RSA storage key there? If not, I will generate one and place it there. So now we actually have a guaranteed storage key we can encrypt to. Second problem of TPMs is that when you send a command in, only the first parameter of that command is encrypted. And remember, each of the commands I showed you had quite a few parameters. By the way, first parameter does not include the parent keys or any of the keys. So anything with the at sign is not included in this encryption. It's the first parameter. And there's a problem here because if you look at TPM import, it has a parent key handle, which is not the first parameter, but its first parameter are the public key parameters. You honestly don't care about encrypting those. So if I use parameter decryption with TPM import, my private key is not protected. This is a bit of a cock up on behalf of the TCG. I don't know why they did this. The solution in my mind would have been to reverse those two parameters. But remember, these are the people who came up with the TSS we're talking about. So their solution was not to reverse these two parameters. It was to add an extra parameter called an encryption key, which would then be encrypted, and then you use this encryption key to encrypt the private key. God knows why. I suspect all they really wanted to do was make my life in constructing a crypto system much harder. So thank you very much. There it is. There are several other commands that use the IBM TSS. Unfortunately, you do have to be aware of cock ups and the specification like this. But you can cope with them. And all of the stuff that I'm going to show you does cope with them. The key point about this is that all of this is incredibly complicated. The average user does not want to have to understand what I just spent the last 25 minutes telling you. So they want all of this complexity just to be hidden from them. They want the TPM in their laptop just to work for shielding private keys. So the question that I mostly was interested in, I had to learn all of this to work out how to use the TPM. But the one I'm mostly interested in is how do I enable all of you to use the TPM very simply. And the answer to that is that we actually use TPM enabling all of the crypto systems that we use today. So almost everybody understands how to use open SSL. It's complex but they pretty much understand it. Most people understand how to use GPG. Most people understand how to create a key for open VPN. So there's this sort of unfortunate complex knowledge that we all use but which can be used if I just TPM enable these crypto systems quality to use a TPM for the key handling and signature and encryption under the covers if I get it right. So that is the goal that I'm going to do. And existing crypto systems mostly use password protected key files. So mostly you have a private key file that has all of the private elements that are AES encrypted to some password that you type in when you actually use this private key. So it's actually very easy to see that these key files could contain TPM keys with the public blob and the private blob and if we use the password as the key authority we have exactly the same workflow that we had with the ordinary keys. And then as long as the crypto system recognizes the TPM key everything would actually just work. It would see a TPM key, it would ask if your password, you type your password the crypto operation would go through the TPM but everything would just work. The only thing that you've got is enhanced security because now someone runs off with your private key file unless they have access to your TPM they cannot use it. The only additional requirement in this workflow is conversion of the actual encrypted private key into its TPM form which involves a round trip through the TPM with TPM2 import. That's the only additional thing you should need to do. And obviously you need discipline around key backup. So you can convert a key to its TPM format and obviously you need to destroy the private key but you need to have kept a backup of that because once it's converted to a long lived key, a key that might outlive the TPM on your laptop you need an offline backup copy of it somewhere and this means you need better discipline around key handling. I suppose I should ask how many people in the room have the only copy of their GPG key on their laptop but I won't embarrass you by asking the question. So the advantages of all of this are now we only actually need to trust the TPM. Depending on who you believe that is actually an easy thing to do. TPMs themselves are actually manufactured by an international consortium. They are in use by a lot of the public security agencies of a lot of companies so the Russia, FSB, the Chinese security agency and the NSA will use these TPMs so they clearly trust them and as far as the manufacturers can tell there are no backdoors inserted into them so there's no real reason why you shouldn't trust them as well. In fact one of the great things about TPM 2.0 is that IBM has produced a software emulation of the TPM that you can actually run and verify that it works and if you don't trust it you can actually take the code apart and see what it's doing and see that there are actually no backdoors. Microsoft has now just released their TPM emulator as well and if you actually build one of my open SSL system when you type make test one of the things it will actually do is fire up the TPM emulator and run a load of checks against it just to make sure that what you built works. The point about this is that the key can never be stolen all it can happen is someone could snoop your password authority and if they have access to your laptop so while the laptop is switched on they could use the key to generate signatures because they then have your authority but if they just steal your key file without your TPM it's useless so this gives you the something you have and something you know security that is the hallmark of two factor authentication so by moving keys into the TPM you get two factor authentication which seems to have been pretty much the holy grail of security for a long time and apart from key conversion there should be no changes to your workflow at all these are great advantages the disadvantages are the key is tied to a single physical TPM which is part of your laptop lose your laptop or upgrade to a different laptop all the keys are useless this is unfortunate that means that you have to have a TPM backup handling and the keys have therefore to be reconverted to TPM form every time you change laptops you have more than one laptop you have to convert to TPM form on both of those laptops and TPM 2.0 does require the internal resource manager if you have a lot of keys you'll just run out of TPM memory if you try and use it with a huge number of keys without the resource manager the final thing is the TPM is slow it takes 55 seconds to do a KDF to generate RSA primes my actual laptop could have done that calculation in about 100 milliseconds so the TPM itself is a really slow processing engine so it can't process hundreds of key operations per second it's fine for sort of signatures that we only use rarely so for VPNs you know you use them once every five minutes for SSH sessions I think reauthentication rarely occurs so it doesn't really matter for GPG you only use them for signatures these are not high density operations you're not doing them hundreds of times a second but this also means that you're not going to be using a TPM for symmetric encryption of your disk unless you want your data to be available on a time span of weeks instead of seconds so the current status is that I've written and published an engine for open SSL engines of the way you actually add different key handling systems to open SSL the URL I think was also part of the stuff I submitted to FOSDAM it comes with this utility called create TPM2 key that actually converts from an open SSL key private key to a TPM private key and this utility can also be used to create a TPM private key that's actually embedded in the TPM and can never be extracted there is an issue with elliptic curves so I did say that crypto agility was one of the hallmarks of the TPM and that allowed you to use elliptic curve cryptography the problem is that TPM enabling of this all works fine but the TPMs themselves do not have generic elliptic curve key handling I've yelled at various people at the TCG to try and find out why this is and the best excuse I get back is because it's export regulations if we do generic elliptic curves we have a problem exporting the TPM to various countries you want to mandate what curves can be used and want to ban all the other curves from being used so the problem is that the TPM therefore only has a known set of curves that it can be it can be used with and right at the moment it's only two mandated curves and by mandated curves it means that the TPM must handle these there are lots of other optional curves that the TCG has parameterized but manufacturers being manufacturers you'll find that every TPM2O you have basically only supports the mandated curves and no others so you have a choice of two curves and they are the Burrito Nairing 256 which nobody uses or the NIST P256 curve which is the one the NSA has come up with and is not trusted by any other country Instantly if we were in China I'd be saying you have the Burrito Nairing 256 curve and you have the SM 256 curve which the Chinese came up with and which nobody else trusts that they can't decrypt but the point is that you have to use the mandated curves otherwise you're not transferring your private keys into the TPM and this is a bit unfortunate for a lot of us because the Bernstein curve 25519 is actually the most popular curve in open source and that's not even parameterized by the TCG so it's not even on the TCG radar but if you can live with all of these issues the only remaining problem with open SSL is that open SSL uses a different API for every key format it has so if you have a PEM key it has a PEM API for a DER key it has a DER API and for an engine key it has an engine API chances are the crypto system you're using didn't bother to actually add the engine load private key so even if I enable the use of engine private keys in open SSL often there's still a couple of lines to the open source program to get it to load the engine private key if it can't find any of the other private keys however it's easy to own a couple of lines I actually did it to open VPM and I'm just trying to get the patches up now it looks fairly simple I also did it to open SSH which is actually based in open SSL the patch to use engine keys is fairly simple the problem is that when you use the open SSH agent the way it's used to handling keys is it passes the private keys to the agent via their primes and if it's a TPM key you cannot do that because you do not know the primes so there had to be an additional patch to open SSH that actually allows the agent to work with engine keys but I have all those patches and I produce them for open SSH GnpG was not even based on open SSL so I had to look through Gcrypt and various other things to get it to work and I therefore wrote a new TPM module for it and it does key conversion via edit key with a new GpG command called key to TPM so let's demo all of this so you can actually see what I'm doing in the final five minutes I hope okay is that roughly visible to everybody yep I think so okay so I have a brand new GpG system I'm going to use so let's do a so this is just me generating a rubbish so now it's just generating for me it's going to ask me for a passphrase I'm going to type test as the passphrase which it doesn't like because it's too short you should never use test as your key passphrase apart from you doing demos by the way I should give you that warning and you can see it's created for me two RSA keys can everybody see this I know there's a bit of obscurity from the console if you can see this and in true GpG if you look in the GpG private directory let's look at the 099 key that's actually stored as an S expression for a protected private key it's an RSA key it's got the modulus and the exponent the public key and it's protected via this encryption algorithm which is the standard way that it does all of this but what I can do if I do the so this is one I've altered earlier sorry I need to tell it what name I gave it's tests wasn't it so these are my keys I've got my primary key it's used for signing and certification my encryption sub key both the RSA and both are currently just sort of sitting in encrypted form in my GpG directory so now I'm going to convert let's actually see what the grips are so the 37 key is actually my primary key what I'm going to do I'm going to put my primary key into the TPM key to TPM and it's going to ask me if I want to move the primary key I now have to give it my decryption passphrase which is test to decrypt the key and and now it's going to give me a TPM passphrase which I'm going to use as TPM which you should never use anyway either and now it will actually convert my private key I actually when I inserted this into GpG I just basically used the card API diversions so it comes back as a special card serial number saying TPM protected this now means that this RSA key which was a grip 37 is now protected and there's a slight trick to this you notice that whenever you do a key operation and quit GpG it usually asks you for confirmation didn't this time because as soon as you do key to TPM the conversion is instantaneous but if I actually look at the protected key it's the wrong one because that was my sub key but I had a 50-50 chance of getting that wrong you see the format of the key is now a shadowed private key which is the same format as you use for card keys but the shadow information actually has a TPM designation here and what's stored in the shadow information is the parent the public key blob and the private key blob so the shadowed private key is now actually storing all of the TPM information so you can still do a denial of service attack on my TPM protected GpG key by destroying this file but now you cannot steal this file from my laptop and everything is secure and I suppose one of the things I should show you is actually adding a key to this so let's say I want to actually add an encryption sub key let's do a signing sub key so let's do an elliptic curve signing sub key now it gives me a lot of choices for curves but as you know this is the only curve choice I can actually use so I will choose curve 3 because it's Hobson's choice for me and I'll give it no expiry it will ask me if this is correct yes I want to really create it yes and I need a passphrase to protect the key so I'll use test again and I also need the certification key passphrase to attach this and remember now it asked me for a TPM key passphrase because this key isn't my TPM that's the clue to the user that your key is actually TPM protected and now what you can see is I actually have a non-TPM protected secondary key that's actually used for signing and I can actually save this key but now what I can do is I can select this sub key number 2 and I can just convert this to TPM form as well so I need to give it the test passphrase to give it the TPM passphrase and now if you look I have not only a protected certification key but I also have a TPM protected signing key and I suppose and notice when I quit it doesn't ask me to confirm because that conversion is already done and if I want to sign a little text file which I did earlier but we'll overwrite it anyway it's now asking me to sign with my TPM passphrase so I type my TPM passphrase the TPM itself constructed the signature of that file and if I actually verify this you can see the verification is done using an ECDSA key that I just created and that signature was actually done through the TPM encryption operations if I TPM protect the encryption key would be done in exactly the same way I was going to demonstrate how all this works with open SSL but I think I'll do the courtesy of allowing you to ask questions before you run out of time so in the last three minutes there's any well I did have a conclusion but I won't bother does anybody have any questions about this yep so the question was when can we get the GPG patches the answer is they're already posted to the list I believe in the URLs I did for FOSDEM I might have referred to the patch but if not the GPG list is very low traffic and they were posted within the last month you can just find them there I know in the URLs for the FOSDEM session I actually pointed to my OpenSUSA build service that's actually building this version of GPG for Debian 9 OpenSUSA and Fedora 26 I think and Fedora Rawhide okay question up here what is the reconversion process if you want to transfer your key to your keys to a different GPM so what was the question what's the conversion process for transferring your keys from one GPM to another so there is no conversion process for transferring keys from one TPM to another the TPM allows for something called key duplication but for all the keys that I create the duplication policy is empty which means they can never be extracted from the TPM the problem with duplicatable keys is they can be extracted from the TPM so that means a clever attacker can cause the extraction and you've effectively lost the property of TPM protection so for your own safety I believe the best use of the TPM is actually one way conversion of the keys which means that nobody, not even you can ever get them out of TPM format okay here's the question if I run this on ARM with the trust zone feature in the CPU is it also compatible with TPM 2.0? So the question is trust zone compatible with TPM 2.0 and the answer is they're two different things so the TPM is a discrete processing module trust zone is sort of the ARM enclave technology a bit like SGX so you can use trust zone to implement a software based TPM and as long as you're willing to trust that software based TPM and you have effectively you've put the TPM emulator into the enclave something in trust zone like the TPM but by and large just if vanilla trust zone has no TPM capabilities so you require a discrete TPM to get this to function Intel actually has an interesting thing called the Intel PTT that I always forget what it means but essentially it means a TPM that runs in a ring equivalent to the management engine on the CPU which is obviously after discovering the management engine is running MINIX something you'd all trust in this room so you do have to be careful of base TPMs even in things like trust zone okay no more questions okay one more question so the question is does the kernel key ring have integration with the TPM and the answer is yes but it's not what you expect so the kernel has this concept of TPM trusted keys but it doesn't mean that it will use the TPM to do the signature operations and the encryption operations what TPM trusted keys means is that the data that forms the key is sealed to the TPM so when you use a TPM trusted key unlock it actually brings the key back in the clear from the TPM so it's not using the TPM to shield key operations in the same way that I am but it's using a TPM function to protect the keys and for instance this is used for asymmetric encryption keys so if you use LUX with TPM protection you would actually use this type of trusted sealed key and the reason you'd use it is because I can't do asymmetric encryption operations fast enough for you to actually be able to decrypt a disk so you need to get the key back then you just need to load it up into software that does the symmetric decryption so that's the way the trusted key functionality in the kernel actually works it's possible to actually develop a new trusted key functionality that would actually do the signing and decryption operations through the TPM but that doesn't currently exist in the kernel today okay and I think one more question given that we don't really know what goes on inside the TPM silicon that the spec is kind of insane and its API seems to only grow in complexity how do we trust this to keep anything safe so the question is basically how do we trust the TPM if the spec is so complicated the implementation is so complicated and the great answer to that is that the implementation is all available in open source if you trust the open source you can actually trust that your TPM is working like that the problem is how do you trust that the manufacturer of your TPM actually implemented what you see in open source and the answer is you have absolutely no guarantee of that and as you saw recently with the infineon cock up over generating primes they don't actually necessarily use the open source version that was produced so the only real security I can give you is that the TPM is just one thing and there's a lot of bounty going for discovering key bugs and security bugs and so this means that there are a lot of really clever people attempting to prove that the TPM was manufactured wrongly and will actually give up its secrets so as long as none of them has published a bug bounty you can be reasonably certain that your TPM wasn't compromised but that's about the only security you have and with that I think I better say thank you very much for the next speaker time to set up