On Fri, Apr 8, 2016 at 8:28 AM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
