On Fri, Apr 08, 2016 at 09:09:23AM +0000, 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
