Re: TPMs, measured boot and remote attestation in Fedora
On Sat, Apr 23, 2016 at 02:57:55PM +0200, Kevin Kofler wrote: > Matthew Garrett wrote: > > Measured boot is a process whereby each component in the boot chain > > "measures" the next component. In the TPM 1.x world (which is where most > > of us still are), that measurement is in the form of a SHA1 hash of the > > next component. So, on a BIOS system, the firmware measures itself, the > > firmware measures its configuration, the firmware measures any option > > ROMs on plugin cards, the firmware measures the MBR of the disk, the MBR > > measures the grub stage 1, the grub stage 1 measures the grub stage 2, > > the grub stage 2 measures the kernel and so on. > > Yet another Treacherous Computing "feature" that nobody needs! I need to know if somebody has modified my firmware. > > Remote attestation is a mechanism by which a remote machine can request > > (but not compel) another machine to provide evidence of the PCR state. > > The TPM provides a signed bundle of information including the PCR values > > and the event log, and the remote machine verifies that the signature > > corresponds to the key it expected to see. > > How does the remote machine know that what is answering is a physical TPM > and not a software emulation? Does it need to have the individual TPM's > public key in advance? Three ways: 1) If you only care that it's *a* TPM, you validate the certificate chain from the endorsement key and ensure that it chains back to an intermediate certificate corresponding to a TPM vendor 2) If you care that it's a specific TPM, yes, you need to know the public key in advance 3) If you fall into (1) but it's socially unacceptable for you to demand a specific TPM key because that's a uniquely identifiable piece of data about the machine, you use a trusted privacy CA that validates (1) and then issues a new certificate In the general case, (1) is unacceptable for privacy reasons. (3) is impractical because nobody has actually built the privacy CA infrastructure. As a result, remote attestation is only practical in constrained corporate environments, not those where there's a risk to individual freedom. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Sat, Apr 23, 2016 at 8:57 AM, Kevin Kofler wrote: > Matthew Garrett wrote: >> Measured boot is a process whereby each component in the boot chain >> "measures" the next component. In the TPM 1.x world (which is where most >> of us still are), that measurement is in the form of a SHA1 hash of the >> next component. So, on a BIOS system, the firmware measures itself, the >> firmware measures its configuration, the firmware measures any option >> ROMs on plugin cards, the firmware measures the MBR of the disk, the MBR >> measures the grub stage 1, the grub stage 1 measures the grub stage 2, >> the grub stage 2 measures the kernel and so on. > > Yet another Treacherous Computing "feature" that nobody needs! If you are trying to ensure the provenance of the hardware and software combination at every stage, you really need to check it at every level and every stage of loading. "Trusted Computing" used to be called "Palladium", and I caught an early presentation on it by Peter LaMacchia, one of the authors. He did not realize Richard M. Stallman was going to be in the audience, and I could see his look of horror when Richard got up and tore the whole project a new one for trying to take away users' access to and control over their own data on their own systems. >> Remote attestation is a mechanism by which a remote machine can request >> (but not compel) another machine to provide evidence of the PCR state. >> The TPM provides a signed bundle of information including the PCR values >> and the event log, and the remote machine verifies that the signature >> corresponds to the key it expected to see. > > How does the remote machine know that what is answering is a physical TPM > and not a software emulation? Does it need to have the individual TPM's > public key in advance? > > Kevin Kofler It cannot detect whether the Trusted Computing enabled host is a VM. This is one of the big reasons Trusted Computing hasn't been more rigorously pursued or enforced. It's proven too easy to defeat by running the tools in a VM, one in which the hypervisor can access the unlocked or unencrypted data streams inside the VM. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Sun, Apr 24, 2016 at 01:15:15AM +0200, Lars Seipel wrote: > On Sat, Apr 23, 2016 at 02:57:55PM +0200, Kevin Kofler wrote: > > Matthew Garrett wrote: > > > Remote attestation is a mechanism by which […] > > > > How does the remote machine know that what is answering is a physical TPM > > and not a software emulation? Does it need to have the individual TPM's > > public key in advance? > > If I understood it correctly, the TPM keys can be chained back to a > manufacturer key and likely some kind of CA. So while software emulation > is unfeasible without the ability to extract private keys from either > TPMs or their vendors, you should be able to buy any TPM, feed it with > exactly the values you want, and get yourself a signed attestation of > TPM state that has no relationship to what is actually running on your > computer. That works as long as the other side only verifies against > some generic vendor public key. Yes, but this isn't a one-time thing because the protocol includes nonces to check for freshness: https://seclab.stanford.edu/pcl/cs259/projects/cs259_final_lavina_jayesh/CS259_report_lavina_jayesh.pdf > If you precisely know the key the signature should've been made with > (e.g. because you did the initial machine setup and then left it with > some colocation facility) you can verify it against the expected public > key directly. Used this way, remote attestation might actually be > useful. Also, it would appear each TPM is intended to get its own key pair and a certificate signed by a CA, so it's the cert and trusted CA you'd want to replace. That way if you think a TPM was compromised, you can revoke the TPM's cert & thus blacklist the TPM (vs. having one key pair shared by all TPMs). smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Sat, Apr 23, 2016 at 02:57:55PM +0200, Kevin Kofler wrote: > Matthew Garrett wrote: > > Remote attestation is a mechanism by which […] > > How does the remote machine know that what is answering is a physical TPM > and not a software emulation? Does it need to have the individual TPM's > public key in advance? If I understood it correctly, the TPM keys can be chained back to a manufacturer key and likely some kind of CA. So while software emulation is unfeasible without the ability to extract private keys from either TPMs or their vendors, you should be able to buy any TPM, feed it with exactly the values you want, and get yourself a signed attestation of TPM state that has no relationship to what is actually running on your computer. That works as long as the other side only verifies against some generic vendor public key. If you precisely know the key the signature should've been made with (e.g. because you did the initial machine setup and then left it with some colocation facility) you can verify it against the expected public key directly. Used this way, remote attestation might actually be useful. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
Kevin Kofler wrote: > Matthew Garrett wrote: > > Measured boot is a process whereby each component in the boot chain > > "measures" the next component. In the TPM 1.x world (which is where > > most of us still are), that measurement is in the form of a SHA1 > > hash of the next component. So, on a BIOS system, the firmware > > measures itself, the firmware measures its configuration, the > > firmware measures any option ROMs on plugin cards, the firmware > > measures the MBR of the disk, the MBR measures the grub stage 1, > > the grub stage 1 measures the grub stage 2, the grub stage 2 > > measures the kernel and so on. > > Yet another Treacherous Computing "feature" that nobody needs! That depends entirely on who controls the keys. It's treacherous only if the sysadmin doesn't have the secret key. Björn Persson pgpFx0jOg1EnF.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
Matthew Garrett wrote: > Measured boot is a process whereby each component in the boot chain > "measures" the next component. In the TPM 1.x world (which is where most > of us still are), that measurement is in the form of a SHA1 hash of the > next component. So, on a BIOS system, the firmware measures itself, the > firmware measures its configuration, the firmware measures any option > ROMs on plugin cards, the firmware measures the MBR of the disk, the MBR > measures the grub stage 1, the grub stage 1 measures the grub stage 2, > the grub stage 2 measures the kernel and so on. Yet another Treacherous Computing "feature" that nobody needs! > Remote attestation is a mechanism by which a remote machine can request > (but not compel) another machine to provide evidence of the PCR state. > The TPM provides a signed bundle of information including the PCR values > and the event log, and the remote machine verifies that the signature > corresponds to the key it expected to see. How does the remote machine know that what is answering is a physical TPM and not a software emulation? Does it need to have the individual TPM's public key in advance? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Fri, Apr 22, 2016 at 9:48 AM, Chris Murphy wrote: > On Fri, Apr 22, 2016 at 7:31 AM, Josh Boyer wrote: >> On Fri, Apr 22, 2016 at 2:35 AM, Matthew Garrett wrote: >>> On Thu, Apr 21, 2016 at 02:35:21PM +0200, Harald Hoyer wrote: On 08.04.2016 18:56, Matthew Garrett wrote: > initrd is certainly a more difficult one. One thing we can do is work on > making dracut builds reproducible - that way they should be consistent > across identical machines in a cluster. > dracut already supports reproducible builds: $ man dracut […] --reproducible Create reproducible images. needs cpio with "--reproducible" support though >>> >>> Oh, wonderful! Is there a reason that isn't default in Fedora? >> >> I'm guessing because it changes the default away from HostOnly mode, >> which is something we consciously switched to several releases ago. > > --hostonly initramfs on F23, 30M > --reproducible initramfs on F24, 50M > --no hostonly initramfs on F24, 50M > > So this might mean boot partitions need to get bigger, which is > actually currently being discussed on anaconda-devel@ > > I'm finding that by default right now F23 initramfs is 30M, F24 > initramfs is 50M, so something's changed for Fedora 24. Sorry, I've got the F23 initramfs size wrong, it's 21M. kernel+initramfs+map is where I got 30M. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Fri, Apr 22, 2016 at 7:31 AM, Josh Boyer wrote: > On Fri, Apr 22, 2016 at 2:35 AM, Matthew Garrett wrote: >> On Thu, Apr 21, 2016 at 02:35:21PM +0200, Harald Hoyer wrote: >>> On 08.04.2016 18:56, Matthew Garrett wrote: >>> > initrd is certainly a more difficult one. One thing we can do is work on >>> > making dracut builds reproducible - that way they should be consistent >>> > across identical machines in a cluster. >>> > >>> >>> dracut already supports reproducible builds: >>> $ man dracut >>> […] >>>--reproducible >>>Create reproducible images. >>> >>> needs cpio with "--reproducible" support though >> >> Oh, wonderful! Is there a reason that isn't default in Fedora? > > I'm guessing because it changes the default away from HostOnly mode, > which is something we consciously switched to several releases ago. --hostonly initramfs on F23, 30M --reproducible initramfs on F24, 50M --no hostonly initramfs on F24, 50M So this might mean boot partitions need to get bigger, which is actually currently being discussed on anaconda-devel@ I'm finding that by default right now F23 initramfs is 30M, F24 initramfs is 50M, so something's changed for Fedora 24. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Fri, Apr 22, 2016 at 2:35 AM, Matthew Garrett wrote: > On Thu, Apr 21, 2016 at 02:35:21PM +0200, Harald Hoyer wrote: >> On 08.04.2016 18:56, Matthew Garrett wrote: >> > initrd is certainly a more difficult one. One thing we can do is work on >> > making dracut builds reproducible - that way they should be consistent >> > across identical machines in a cluster. >> > >> >> dracut already supports reproducible builds: >> $ man dracut >> […] >>--reproducible >>Create reproducible images. >> >> needs cpio with "--reproducible" support though > > Oh, wonderful! Is there a reason that isn't default in Fedora? I'm guessing because it changes the default away from HostOnly mode, which is something we consciously switched to several releases ago. josh -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Thu, Apr 21, 2016 at 02:35:21PM +0200, Harald Hoyer wrote: > On 08.04.2016 18:56, Matthew Garrett wrote: > > initrd is certainly a more difficult one. One thing we can do is work on > > making dracut builds reproducible - that way they should be consistent > > across identical machines in a cluster. > > > > dracut already supports reproducible builds: > $ man dracut > […] >--reproducible >Create reproducible images. > > needs cpio with "--reproducible" support though Oh, wonderful! Is there a reason that isn't default in Fedora? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On 08.04.2016 18:56, Matthew Garrett wrote: > On Fri, Apr 08, 2016 at 09:23:07AM +, Petr Pisar wrote: > >> I'm curious how you would predict hash of initramfs because it is >> generated on the host and depends on dracut configuration and presence >> of various optionally installed packages. > > initrd is certainly a more difficult one. One thing we can do is work on > making dracut builds reproducible - that way they should be consistent > across identical machines in a cluster. > dracut already supports reproducible builds: $ man dracut […] --reproducible Create reproducible images. needs cpio with "--reproducible" support though -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Fri, Apr 08, 2016 at 11:36:33AM +0200, Florian Weimer wrote: > On 04/08/2016 10:28 AM, Matthew Garrett wrote: > > With what we now know about malicious actors targeting the system boot > > chain (even down to the firmware), this kind of TPM-based work is a > > vital part of helping keep our users secure. > > On the other hand, it can easily be abused to restrict user freedom. > For example, video streaming sites might not be willing to serve content > to users who cannot cryptographically prove they are running an approved > operating system with an approved browser. The practical issues around enforcing this kind of remote attestation have proven to be sufficiently intractable that literally nobody has ever ended up doing it (I thought Netflix had for ChromeOS devices - it turned out I was wrong). > Remote attestation only works with a trusted counterpart who rejects > access once a breach is detected. Who do you expect to be the > counterpart for Fedora users? Is there anyone who offers such a service > without also requiring to use their own operating system? Openstack has some support for this, although I wouldn't recommend using it. The setup I'm envisaging is for server deployments within a single administrative domain - this way it's entirely under the control of whoever controls the machines anyway. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Fri, Apr 08, 2016 at 09:23:07AM +, Petr Pisar wrote: > I'm curious how you would predict hash of initramfs because it is > generated on the host and depends on dracut configuration and presence > of various optionally installed packages. initrd is certainly a more difficult one. One thing we can do is work on making dracut builds reproducible - that way they should be consistent across identical machines in a cluster. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Fri, Apr 08, 2016 at 09:09:23AM +, Gregory Maxwell wrote: > The TPM style of remote attest is quite unfriendly to free software. > It puts basically the entire operating system in the trusted domain, > and you cannot change even a bit of it without "breaking the seal". > So if you want any use of remote attest at all, there is a huge swath > of your system which are are "compelled" under threat of loss of > access to whatever functionality remote-attest was providing to make > no modification-- or even, potentially, no upgrade to a very new or > less common version. Remote attestation is primarily useful within a single administrative domain. Outside that case it's far too easy to subvert (easiest approach: simply add a second TPM to your system and program whatever PCRs you want), and the privacy concerns remain sufficiently problematic that I don't see anybody pushing for it in the near future. > I think any time invested to make remote attest of any kind work would > better be spent on support for Intel SGX, which creates limited > remote-attestable sandboxes which (assuming Intel made no mistakes :) > ) have strong security and confidentiality regardless of what else is > running on the system. These sandboxes also have no outside access > except via limited channels, so (again assuming no mistakes/backdoors > on Intel's part); and the published security model is stronger (e.g. > encrypted ram) and more suitable for user-friendly uses (for example, > it would be straight-forward to use SGX to implement a bitcoin wallet > that could enforce user specified transfer limits, even against a > total security compromise of the host-- and if the RA part is as > usuable as it could be, even prove to third party auditors that your > keys have these security properties (the RA functionality for SGX is > not yet documented in public, AFAIK)). SGX has some interesting properties, but it's unhelpful in the rather more common case of "I'm running a bunch of servers and I want to know that they're trustworthy before I give them access to resources". Rearchitecting a large number of apps into a more SGXy world is a far from trivial task. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Fri, Apr 8, 2016, at 05:36 AM, Florian Weimer wrote: > Remote attestation only works with a trusted counterpart who rejects > access once a breach is detected. Who do you expect to be the > counterpart for Fedora users? Is there anyone who offers such a service > without also requiring to use their own operating system? A use case for this is having Kubernetes cluster masters request attestation, and worker nodes provide it. One could s/Kubernetes/any other clustering system/, but it's a modern example. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Fri, Apr 8, 2016, at 05:23 AM, Petr Pisar wrote: > I'm curious how you would predict hash of initramfs because it is > generated on the host and depends on dracut configuration and presence > of various optionally installed packages. That's true for a system managed by yum/dnf, but rpm-ostree (as used by Fedora Atomic Host), always uses host-independent initramfs images. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On 04/08/2016 10:28 AM, Matthew Garrett wrote: > With what we now know about malicious actors targeting the system boot > chain (even down to the firmware), this kind of TPM-based work is a > vital part of helping keep our users secure. On the other hand, it can easily be abused to restrict user freedom. For example, video streaming sites might not be willing to serve content to users who cannot cryptographically prove they are running an approved operating system with an approved browser. Remote attestation only works with a trusted counterpart who rejects access once a breach is detected. Who do you expect to be the counterpart for Fedora users? Is there anyone who offers such a service without also requiring to use their own operating system? Florian -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On 2016-04-08, Matthew Garrett wrote: > Doing this well involves knowing what the expected values are to begin > with. Some of these values come from the firmware, and so we can't do > much about them without the assistance of the system vendors. But these > values don't tend to change over the course of a system's lifetime > (unless you update the firmware), so it's much easier to do something > about that. Other components *do* change over time as we update grub or > the kernel, and it's immensely helpful to be able to identify these > ahead of time. > > In CoreOS we've started shipping bundles of the expected PCR values with > each release. I'd like to start exploring how to do the same in Fedora. > Things are much easier in CoreOS since we don't ship individual OS > components, and so the values are very much tied to OS releases - in > Fedora they'd mostly be associated with individual packages. It'd be > easy to bundle the values in with the packages themselves, but that's > harder for admins to extract. A central location to publish this kind of > metadata would be ideal. > I'm curious how you would predict hash of initramfs because it is generated on the host and depends on dracut configuration and presence of various optionally installed packages. -- Petr -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TPMs, measured boot and remote attestation in Fedora
On Fri, Apr 8, 2016 at 8:28 AM, Matthew Garrett wrote: [snip] > Remote attestation is a mechanism by which a remote machine can request > (but not compel) another machine to provide evidence of the PCR state. > The TPM provides a signed bundle of information including the PCR values > and the event log, and the remote machine verifies that the signature > corresponds to the key it expected to see. The remote machine can then > examine the log, ensure that it matches the PCR values and analyse each > individual log entry to ensure that it matches an expected value. In a > data centre, this means that it can then flag whether a machine is > running in an expected state or not - if someone has tampered with the > boot process, the information will not match the policy. > > Doing this well involves knowing what the expected values are to begin > with. Some of these values come from the firmware, and so we can't do > much about them without the assistance of the system vendors. But these > values don't tend to change over the course of a system's lifetime > (unless you update the firmware), so it's much easier to do something > about that. Other components *do* change over time as we update grub or > the kernel, and it's immensely helpful to be able to identify these > ahead of time. The TPM style of remote attest is quite unfriendly to free software. It puts basically the entire operating system in the trusted domain, and you cannot change even a bit of it without "breaking the seal". So if you want any use of remote attest at all, there is a huge swath of your system which are are "compelled" under threat of loss of access to whatever functionality remote-attest was providing to make no modification-- or even, potentially, no upgrade to a very new or less common version. Even if it is not overtly used in user-hostile ways, many applications of this would make opaque proprietary operating systems on a much more even playing field with Free Software. I think any time invested to make remote attest of any kind work would better be spent on support for Intel SGX, which creates limited remote-attestable sandboxes which (assuming Intel made no mistakes :) ) have strong security and confidentiality regardless of what else is running on the system. These sandboxes also have no outside access except via limited channels, so (again assuming no mistakes/backdoors on Intel's part); and the published security model is stronger (e.g. encrypted ram) and more suitable for user-friendly uses (for example, it would be straight-forward to use SGX to implement a bitcoin wallet that could enforce user specified transfer limits, even against a total security compromise of the host-- and if the RA part is as usuable as it could be, even prove to third party auditors that your keys have these security properties (the RA functionality for SGX is not yet documented in public, AFAIK)). -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
TPMs, measured boot and remote attestation in Fedora
Some people who installed the Fedora 24 Alpha from scratch on bare-metal BIOS-based systems may have found that their system didn't boot. Sorry about that - it's my fault, and it's fixed now. But it happened as a result of some new code in grub that gives us some really exciting functionality. Trusted Platform Modules (or TPMs) are small devices that sit on many system motherboards. They're usually attached over the LPC bus, which means two things: 1) Communicating with them isn't very fast 2) There's no support for device-initiated DMA, which means there's no way they can directly read system state Measured boot is a process whereby each component in the boot chain "measures" the next component. In the TPM 1.x world (which is where most of us still are), that measurement is in the form of a SHA1 hash of the next component. So, on a BIOS system, the firmware measures itself, the firmware measures its configuration, the firmware measures any option ROMs on plugin cards, the firmware measures the MBR of the disk, the MBR measures the grub stage 1, the grub stage 1 measures the grub stage 2, the grub stage 2 measures the kernel and so on. Each of these measurements is written into a register on the TPM called a Platform Configuration Register, or PCR. Attempting to write to a PCR doesn't directly replace the old contents with the new value. Instead, the TPM concatenates the two values and stores the SHA1 of that concatenated value. Unless you've comprehensively broken SHA1, there's no way for you to set a PCR to a specific value unless you perform exactly the same set of writes. Each of these writes is logged. The log includes the hash that was written to the TPM, an event type and a description of the event. TPMs initialise their PCRs in a known state, so by emulating the behaviour of the TPM and replaying the entries in the log, you can verify that the TPM reached the state it's in by performing the actions recorded in the log. TPMs can be configured to encrypt data or keys in such a way that they will only decrypt or use them if the PCRs are set to specific values. With grub measuring the boot process, this means that you can encrypt a secret in such a way that the TPM will only decrypt it when the values match. An example of using this for boot security is TPMTOTP (https://github.com/mjg59/tpmtotp) which provides a direct mechanism for a user to verify that their boot process (including firmware) has not been tampered with. Remote attestation is a mechanism by which a remote machine can request (but not compel) another machine to provide evidence of the PCR state. The TPM provides a signed bundle of information including the PCR values and the event log, and the remote machine verifies that the signature corresponds to the key it expected to see. The remote machine can then examine the log, ensure that it matches the PCR values and analyse each individual log entry to ensure that it matches an expected value. In a data centre, this means that it can then flag whether a machine is running in an expected state or not - if someone has tampered with the boot process, the information will not match the policy. Doing this well involves knowing what the expected values are to begin with. Some of these values come from the firmware, and so we can't do much about them without the assistance of the system vendors. But these values don't tend to change over the course of a system's lifetime (unless you update the firmware), so it's much easier to do something about that. Other components *do* change over time as we update grub or the kernel, and it's immensely helpful to be able to identify these ahead of time. In CoreOS we've started shipping bundles of the expected PCR values with each release. I'd like to start exploring how to do the same in Fedora. Things are much easier in CoreOS since we don't ship individual OS components, and so the values are very much tied to OS releases - in Fedora they'd mostly be associated with individual packages. It'd be easy to bundle the values in with the packages themselves, but that's harder for admins to extract. A central location to publish this kind of metadata would be ideal. With what we now know about malicious actors targeting the system boot chain (even down to the firmware), this kind of TPM-based work is a vital part of helping keep our users secure. The remote attestation features also make it easier for admins to keep their data centres secure. We have an opportunity here to make Fedora the first general-purpose operating system to provide resistance to this kind of attack out of the box, and I think it's worth taking it. There's still some additional work to do, such as making it possible to assign local policy to which things get logged into which PCR. But I think we're in a great position to start developing well-integrated features that take advantage of this kind of hardware-level secur
