 Hi everyone and welcome to my talk about trusted platform modules or TPMs for short. My name is Jonas Wittschel, online I also go by the nick of Diabonos on sites like GitHub, Reddit or an IRC. I have been actively involved with the Arch Linux project for about a year now as a trusted user and I am also one of the maintainers of the TPM2 software project on GitHub where I maintain TPM2 TOTP which I'm going to show off today as well. So to get started with the actual talk, the first question I imagine some of you might have is what actually is a trusted platform module and why should I care about it? Well, a trusted platform module is a small chip on your computer and it's totally separate from your main system so it has its own memory and processing capabilities and it can do cryptographic operations like encrypting stuff or signing stuff and the idea is that you can store secrets on the TPM totally separate from your main system and do operations there and you never expose them to your actual system. So why is this important? Well, an example many of you might be familiar with are SSH keys. An SSH key is essentially a small secret you use to authenticate against servers on the internet. And usually these secrets are stored on disks, they might be protected by a password but still if an attacker manages to get a hold of your system they can be able to, well, exfiltrate the file, sniff the password and then they can do anything they like with your SSH keys. And the idea is with a TPM you can store this secret in the TPM and then ask the TPM, okay, I need you to sign this data to authenticate against another server. Still if an attacker gets into your system they are able to talk to the TPM and do stuff with it of course but once you switch up of the computer they can't do anything anymore with it and if you suspect there's something wrong with your system you can just wipe it, reinstall your operating system and continue using your keys because they are always stored there and never exposed to your main system. So the next question you might have is, okay, great, now do I actually own a TPM? Well, the good news is that many devices already come equipped with a TPM especially laptops because I think it's some kind of the Microsoft certification requirement and even if you don't have a separate chip many modern processors do have one implemented in the firmware. So in this case of course the distinction between the TPM and the main system is a bit blurred but still it's way better than just storing your secrets on disk. And unfortunately there are two different incompatible versions of the TPM specification. There's TPM 1.2 which is old and deprecated by now because it uses absolute cryptography like SHA1. So you don't want to use this if you can. The new specification is TPM 2.0 where all cryptographic algorithms are flexible so if one gets obsolete you can just exchange it. Unfortunately these two versions require totally different software stakes so today we're only going to talk about TPM 2.0 devices and to find out whether you have one of these you can just look for the device file DEV TPM RM0 on your system so if you've got that you know that you have a TPM 2.0 device that you can use. Even if you don't have one there are software emulators available so if you want just to get started with the concepts or even if you haven't a TPM to play around with it without fear of losing important data or breaking your TPM somehow you can use one of these. Please don't use them to store actual secrets because they just store everything on disk so it's not more secure than just storing your SSH keys in a file as usual but for playing around it's quite nice. So next question is probably okay I want to use the TPM how do I do that? Well fortunately the TPM specification is open you can just freely download it. There's also a standardized C API and there are multiple open source implementations of this API. The one we are going to use today is called TPM 2.0 TSS and related software so you can just download that from GitHub and start coding. Of course this is great if you want to create new programs if you want to make existing programs aware of a TPM that might be a bit of work to get it into all software in existence fortunately there are other existing standards to access cryptographic tokens like these USB smart cards you might have to store for example SSL certificates one of these standards is called PKCS11 and there is some kind of bridge between this standard and the TPM which is called TPM 2.0 PKCS11 so you can use this for all software that is PKCS11 aware like OpenSSH or also Firefox for example and if you want to protect your SSL certificates you might be interested in an OpenSSL engine that exists which is called TPM 2.0 TSS engine so there are existing compatibility bridges to use the TPM with existing programs that confirm certain standards but if you just want to play around with a TPM just to see what it can do I'd recommend installing TPM 2.0 tools it's a set of command line applications and basically every application just exposes one functionality of the TPM so you can just play around with that read the man page everything is documented quite nicely to see what a TPM can do before you do that you want to add your user to the TSS user group because by default the TPM is just available to root so to get access as a normal user because you don't want to run all these tools as root add yourself to the TSS user group log in, log out, log in again and then you can get started okay now for some practical demonstrations first I want to show you how to protect your SH keys the example I've already talked about using your TPM so we are going to use this PKCS11 bridge I've already talked about and so you need to install the software of course as I said you need to add yourself to the user group and then you can get started with the example which I'm going to show you now so first what we need to do is we need to initialize a store because the TPM itself has only a very limited amount of memory so what you do is instead of storing all your keys in the TPM you are storing them on disk but protected with a key that is only available to the TPM so it's just as secure as storing everything in the TPM because you can't do anything with the on disk files so we need to initialize the store on disk and create this key that is only available in the TPM which is called a primary key and this command does this then once we've got this we need to add a token so this comes from the PKCS11 standard so think of a token as one of these smart cards you can store multiple of these tokens in one TPM so it doesn't make too much sense in the context of your TPM but you can use for example different tokens for different purposes like SSH keys, SSH host keys OpenPGP keys whatever to add this token we need to specify the idea of the primary key we just created so this number is usually one we give it a label so we know what it is for we want to use it for SSH keys and we also need to specify two kinds of passwords the first is some kind of admin password so you can use this one to for example if you forget the user password you can reset it with this one but usually you just use this user password here for everything else so now we've got a token we now can proceed to actually add one of these secret keys to it so we've got TPM to P2 add key we need to specify which token we're going to use so we call that by label then we can give the key a name so for example if you're using different SSH keys for different hosts you will probably put this here to identify which one is which it's just a label that isn't used for anything important then you've got the key algorithm so in this case we're using an elliptic curve algorithm with key strings of 256 bits and again we need to specify the pin we've just created so now we've got the key now everything is set up we just need to make sure now that SSH can actually work with this key so we need to get the public card of the key which we can do using SSH key gen with the DA argument and then you specify the path to this library TPM to pks11 which we are using which is this path here and this outputs the public part of the key so now you can copy this to your system that you want to authenticate against and once you've done this you can now authenticate against the system using SSHI again you need to specify the path to the library and of course the server that you want to authenticate against so if you do this you need to input the password you've just created and as you can see everything worked nicely and you get also some kind of debugging output so these warnings are not important but for example if you manage to mistype your password it will tell you this as well of course if you want to authenticate against multiple system typing in your password every time you do SSH becomes old pretty quickly so what you probably want to do is you want to add this key to your SSH agent which is the standard way to manage multiple SSH keys so you can do that as well using SSH add with the s argument and again you specify the path to the library and then you should get this output if I do SSHA add L you can see that the key has been added to the agent cool so this is probably the easiest way to make your system more secure using ATPM just store your SSH keys there of course remember to do backups so if you're playing around with that you don't want to have this as the only key because something might go wrong but yeah that's quite a nice way of making use of ATPM so the next example open pgp keys I am gonna skip over a bit because I'm afraid I won't have enough time to show the actual example but I have all the instructions on the slides and the slides should be available on the conference page by now so if you want to do that you can look it up there in more detail unfortunately using ATPM to manage your open pgp keys it's a bit more difficult because one of the problems is that newpg does not support kac as 11 tokens it has its own kind of standard but well that's a bit hard to work with there is a branch to work with ATPM natively which someone created a while ago unfortunately it hasn't seen much development I think the last comment was in 2018 so at the moment it's a bit hard but you can do it there is a compatibility layer that connects pkcs11 tokens to newpg which is developed externally the name can be found on the slide the issue with that is that it only exists it only supports existing keys that are already stored on the token so you cannot migrate your keys that you already have to the token but you have to create new ones there so I don't recommend actually generating the whole key on the tpm because if you lose your computer or restart your tpm the keys will be gone and this is not so great for pgp keys of course but what you can do is if you have separate sub keys for every device to do signing then you can store these signing keys on the tpm so I think that's kind of a cool usage but I wouldn't recommend storing the whole key there and the other limitation but somebody would have to put it in the work but that would be doable but it hasn't been done so far is that this compatibility bridge I'm talking about only supports rsa keys so if you want to have more modern elliptic curve cryptography keys that is not possible at the moment so yeah, as you can see on this slide it's a bit annoying I'm not gonna demo it but yeah, this would be the setup and again you can find the slides on the conference page so you can look it up there okay, so this should give you some idea what you can store in a tpm and how you can use it the other thing I want to talk is how can you use a tpm to secure your boot process so the idea is of course now if an attacker gets into your system they won't be able to exfiltrate the actual keys but they will still be able to do something with the tpm wouldn't it be nice if your tpm could just say okay, something is wrong here I don't give access to these keys because I sense that some attacker has compromised the system and a tpm can do this so it can grant access to your secrets only if the system is in a known good state well, what is a known good state? the root of trust in this case is your device's efi firmware to trust your hardware vendor as usual if you don't do that you're already pretty lost and what your efi firmware does it can measure certain configurations or system states into so called platform configuration registers on your tpm so every time a certain kind of event occurs it measures this into your tpm and you can then proceed to seal your secrets against these configurations so only if the configuration matches access to the secret will be granted and well, what kinds of measurements are there available? there are different kind of platform configuration registers for different kind of events I'm not gonna talk about all of these but only about the most important ones or the ones you might be wanna use for your own setup so the most important pcr you always want to include in your measurements is pcr0 because it stores the hash of the efi firmware if you update your firmware or someone changes it somehow that should make everything else invalid so this is important to include and then you've got pcr4 and pcr4 stores a hash of all the efi binaries that have been executed in the boot process so usually this is at least your bootloader and probably also your kernel as well and to be more secure you should look into making a unified efi bundle to store your kernel, the init ramfs and the kernel command line in one single efi application how you can do that you can look up in the ArchWiki because in this case you measure everything in there you can't change the init ramfs anymore for example to put malicious binaries in there so in this case to make use of the tpm in full potential you want to do this and the other interesting pcr you might want to be aware is pcr7 because it stores the secureboot state so secureboot is a way you can sign the binaries that are launched during the boot process and only so the firmware only executes binaries that are signed by your trusted keys and pcr7 measures whether secureboot has been turned on or off so that nobody modifies your BIOS configuration to just turn it off and it also measures the certificates that have been used during boot so if you're using your own keys you will be sure that only your own keys have been used not for example the Microsoft key to load something else if that is already stored in your efi firmware by default so what I'd recommend is if you want to go that route either if you're using secureboot with your own keys you want to use at least pcr0 and 7 and if you're not using secureboot you probably want to use pcr0 and 4 combined with always one of these unified kernel images if you're using pcr0 and 4 it means after every kernel or in-end ramfs update you will need to recalculate everything after an update so you will have to reseal your secrets to the new values so this can become a bit annoying I'd recommend doing secureboot because then you only have to make sure that the signing keys match so you can just use pcr0 and 7 and how do I do that now how do I verify that my system has not been tempered with during boot well the easiest way probably to do this is to use tmtotp which I'm a co-maintainer of as I said as a full disclosure tmtotp allows you to store a time-based one-time password or totp secret in your tpm and it shows it every time you boot your system so totps you might be familiar with from two-factor authentication in the internet so the idea is you store a secret on your phone and a secret on server and you need to then input the secret as the totp you get shown on your phone which changes every 30 seconds because it's derived from the secret store there and the current time you need to input this 6-digit code to authenticate against the server in this case it's the other way around your system shows you this 6-digit code which changes every 30 seconds and you can verify it with your phone to see whether the two match and when you boot you look up the code on your phone if the two match then you can be sure that your system configurations or at least the part you measure as I said this depends on the PCR series has not changed and there are already hooks available for mk in its tpao and draket so this totp should get shown automatically during boot and if you have Plymouth installed it gets a bit more fancy but usually it's just plain text output which works as well of course so how do you do that? yeah of course you need to install the actual software and then I can demo that quickly as well for you let's clear that up you just do tpm2 totp generate and you specify the platform configuration registers you want to seal against I'm using secure boot with my own keys so I will be using 0.17 here and generate a key let's make that a bit smaller now you get a QR code you can scan with your favorite totp applications on your phone and then you can do tpm2 totp calculate which should show you the 6 digit code of course this talk is pre-recorded so by the time you are watching this if you scan this code this will not match anymore which is fine but if you do it yourself on your own system the truth should match now otherwise the time is not correct on either your computer or laptop and on your phone great of course you need if you're using mkinitcpao you need to add tpm2 totp to your hooks so you would then add it at cmkinitcpao.conf and put the tpm2 totp hook in your hooks variable do it before your encrypt hook because otherwise you won't be able to see it in time so do it as early as possible and then during build it will look something like this this is if you've got Plymouth installed to have a nice graphical boot I don't usually do this it's on the AUR so if you're not using Plymouth it will be just a plain text hook it will not look as exciting as this but it will also show the current time and the 6 digit totp secret so this is great if you have interactive access to your system and can actually verify this code if you have a remote server it might not be possible to check this code every time before you input your disk encryption keys so what you would want to do for remote servers is you would want to store the disk encryption key in the TPM and store it against a known good system configuration so if that doesn't match anymore it won't input the key and won't boot your system essentially so you have to come fix that because someone has tempered your system somehow and if everything matches it just basically inputs the key automatically and boots up without your user input so this is basically what BitLocker does in the Windows world because it stores the key in the TPM on Linux that's a bit more annoying at the moment but will hopefully get better quite soon because now there is not a very standard solution that I'm aware of but the one that probably comes close is Clivis, it's also packaged in the official Arch Linux repositories there are Drakeit hooks available for it so if you are using Drakeit you can use it pretty much out of the box for mkinux cpa oh unfortunately there is no such support at the moment but if you want to look into this at the moment I recommend Clivis but fortunately it will get better pretty soon because native support for storing the secret in the TPM is planned for crypto setup 2.4 so that's why I'm not going to show a demo today because hopefully the next version of crypto will have that already set up for you and you can just use it out of the box and I'm very excited for this so hopefully in another year's time we can come back and I can just show you that it's going to be real easy so hopefully I've given you some ideas about how you can use a TPM and why it's nice to store secrets there instead of storing them directly on disk I've also briefly touched the subject how you can verify the integrity of your system using these platform configuration registers as a last word of warning please always do backup of course because you don't want to rely only on the TPM if you manage to clear it by accident or something goes wrong with the software you don't want to lose all your disk encryption keys or your PGP keys so please always backup on some encrypted hard drive somewhere else where you store all your data so if you're interested in this topic of course there's this Q&A session starting now on the conference ISE channel so I welcome any questions there if you want to know how to get started for example contributing to the software yourself or there are also some more tutorials available which software already has TPM support and how you can achieve it you can look at our web page which is shown here there's also if you have any further questions there's a mailing list and a Gitter Chat so ways to get in touch quickly thank you very much for listening to my talk and I welcome any questions you might have now we have some questions for you not about this talk about TPMs and the first question is from Jonatan what's the advantage of using TPM for storing keys as opposed to storing keys on an encrypted disk well if you're storing keys on an encrypted disk the keys are secure as long as the disk is encrypted for sure but as soon as you unlock the system so if an attacker is inside your actual life system then the keys are not protected anymore because the attacker can have access to everything that's stored on disk because it's encrypted then so the idea is even if your system is compromised if you store them in a TPM the attacker can't get to the actual secret they might be able to use the TPM but as soon as you switch off your computer you know nobody's doing any bad stuff with your keys because they are never exposed to your main operating system our guest had a question that was almost the same is it possible to use TPM to store disk encryption keys yeah so that was the last part of the talk I apologize for not going into detail there because it's just because I believe that the native support that cryptocurrencies will hopefully gain pretty soon will be much easier to set up so I didn't want to go into detail you have a couple of options now you can write your own mk in its DPA or or you can use the ones that are pre-built for example the ones from clevis for drake but at the moment that's a bit complicated to set up so hopefully the next version of cryptsetup will make that all very easy then we have a question from J4 and J0 and John it should be pronounced can you do secure boot with TPM also can it be prevented from being rewritten by artisuit on a USB so secure boot and TPM are somewhat complementary so you can use both at the same time and in this case a TPM can for example be used to store your disk encryption keys and only release them if your secure boot setup hasn't changed so what you do is you verify using secure boot that your if I have binaries have not been tampered with then the TPM guarantees that only the secure boot keys that you are using so probably your own keys not the ones for example from your distribution or Microsoft have been used but only your own keys and well if you boot art ISO usually you don't have that one signed with your own keys so it wouldn't boot using secure boot and if you turn off secure boot then the TPM won't return your keys because your configuration has changed so you would have to sign your art ISO with your secure boot keys and in that case I'd assume that's actually what you want to run then we have a question from Hexshain it seems to me that trusted boot overlays with secure boot in some ways does it yeah so secure boot is basically just guaranteeing that your system only executes trusted binaries you can do that with a TPM so trusted boot without using secure boot but it's not so convenient because then every time you for example update your kernel your binaries change that you run during boot and so the system stays these PCRs I was talking about change as well and therefore it's quite nice having this combination of secure boot and a TPM but you don't have to do it you can use secure boot without a TPM of course and you don't necessarily need secure boot while running a TPM to secure your boot up it's just a bit more convenient in my opinion Lars to ask the next question do you not actually need the type of passphrase on boot time if you have set it up with TPM that's something you can configure yourself so personally my setup requires typing a passphrase as well as storing part of the encryption key in the TPM so you have to have both for example if you have a remote server you probably don't want to type in a passphrase and this next version of crypto setup should also make this possible either just to store the disk encryption in full in the TPM or to secure it with an addition of a passphrase so that's basically what you get in the Windows world with BitLocker at the moment already because they can either choose to just unlock the system automatically or require a second pin to be typed in addition to the protection that the TPM offers to the disk encryption key and then RISFerry 111 has the next question how does TOETP actually derive a code from the key and time is it something as simple as hash key plus time yeah basically so it's an HMAC algorithm which is basically just a hash derived from a secret which is stored in the TPM and the current time and the nice thing is that the TPM can actually do this HMAC calculation itself so in the previous version of the specification this was not possible but now you don't actually need to release this key anymore at all to the operating system because just the whole HMAC operation is done in the TPM you just have to fed it the current time that still comes to the operating system so it's potentially untrusted that's maybe some kind of attack vector but the TPM doesn't have real-time clock so this part is not secure but the the secret part of the HMAC is stored in the TPM in a release from Grazulini nice talk Jonas but how do you account for time difference between your phone clock and the TPM to TTP output will take more than 30 seconds to display the right token so the hooks actually display the TTP after 30 seconds has passed so once as fast as it can be done and then every 30 seconds so every after every full 30 seconds has passed of course if your system clock and for example smartphone clock don't match then you're going to have a problem but at least you can detect that pretty easily because if you're not using Plymouth that is but just the plain text version you get the current system time of your laptop computer or whatever so you can at least see where it's going wrong of course again the system time is not something trusted so one possible attack vector is that somebody messes around with your system clock and just pre-generates a lot of the CO2D values so that's something you keep in mind but yeah that's not an attack vector particularly including in a threat model and then the last question we have time for is from Sirac was there any research into the physical security of TPMs were just stealing a TPM means stealing the keys inside yeah so if somebody gains physical access to your TPM I wouldn't be entirely confident that they couldn't extract it so of course that's again not really part of the threat model but yes if you gain physical access to the TPM probably you can with some kind of microscope and everything get out the keys somehow so I think there has been some research I'm not an expert on that at all but yeah I think this is definitely a possibility yeah and that was the questions we had time for next up is the lightning talks after the break