Hi Peter, Thanks for sharing this information with us. As you say TPMs may be used in a bad way. It is really up to the "market" to decide what to use TPMs for. This includes us as well :)
If platform attestations will reach TLS or not is of course an interesting topic and at this stage we can just guess. The reason why I'm a bit skeptical is really due to the deployment state of TLS client-auth compared to various "plugin" methods. The latter has become a necessity due to the browser vendors' neglectance of a signature solution, which has forced the development of stand-alone crypto support (e.g. java) rather than using the native browser and OS crypto. These solutions are incompatible with the native TLS client-auth. >Platform attestation has already been applied for network access (preventing >workers from bringing virus-infected laptops within the firewall parameter >of a company) and for web services (recently, in 2005). Yes, indeed. >I haven't hard >about its application in webmail applications. I don't quite see why >platform attestation would be needed there. Anders, can you explain? I believe that some organizations would like to restrict certain features when accessed in an unknown computing environment. Typical restrictions would be uploading or downloading of attachments. >Also, I agree with Julien that a big advantage of webmail apps is that any >Internet-connected computer anywhere running any platform can be used to >access them. Absolutely!. I use this extensively myself. But corporate web-mail and other on-lineweb apps may need some restrictions but I'm not a policy maker. I just want to provide the tools :-) regards Anders ----- Original Message ----- From: "Peter Djalaliev" <[EMAIL PROTECTED]> To: <dev-tech-crypto@lists.mozilla.org> Sent: Thursday, July 20, 2006 15:19 Subject: Re: Platform Attestation. was:To SSL-client-auth or nottoSSL-client-auth, that is the question(?) Hello all, I believe that TPM-generated platform attestation is a powerful mechanism that can be used to augment user authentication, but it has its issues, some of which were mentioned above: - TPM attestation is based on attestation quotes which are digitally signed attestation logs. Attestation logs are simply lists of names and SHA hasesh of components loaded on the a machine. The binary nature of this attestation makes it hard to make a decision whether a platform attestation is acceptable: we need to consider different application versions, as well as patches or updates. Also, we need to measure all software components, which could compromise an application in the Trusted Computing Base: executables, shared objects and eve configuration files. There have been some proposed solutions, but none of them IMHO are good enough for deployment. - Pravicy issues - according to some people, the issues here are huge. According to me, the lack of implementation of this technology in real-time OS and apps makes it unclear about how exactly it will be implemented, raising many speculations and privacy concerns. The TPM-enabled technolofy is very powerful, but could also be abused in ways to harm users. It can be argued about whether or not TPMs would allow us to build "trusted systems", but there is one thing which IMHO is hard to argue about - the platform attestation and the sealing features provided by TPM chips bring to regular desktop machines two security primitives which we really couldn't rely upon before. Also, TPM-enabled platform attestation and sealing have been issued as a standard bu the TCPA. They definitely seems a step further towards having a trusted platform. Again, these features are really powerful, but could potentially be used against users. However, I find that the potential benefits from them are potentially huge. To me the transport layer seems А logical place for platform attestation () because it can enhance the certificate-based user authentication mechanism in TLS. Platform attestation could be implemented into a new version of the TLS protocol, utilizing the TLS extensions standard. Within the TLS handshake, two-way attestation will incur a latency overhead of a single RTT, but will cause some additional processing on the server side (to be measured). The additional data exchanged for one-way attestation is an attestation identity certificate (a slightly modified X509 certificate), an attestation quote (588 bytes) and the attestation log with the list of loaded components and their hashes (~ 5-10 Kb maybe). Such a TLS implementation can use the new TLS extensions proposed by RFC3546 and thus be backwards-compatible with old implementations. In general, platform attestation can be integrated in any authentication mechanism, at least all the ones I know about so far. So, Anders might turn out right when he says that TLS might go bust because it doesn't support platform attestation. However, I don't think integrating it into TLS would be so hard to do, given that this gets included in the TLS standard. Platform attestation has already been applied for network access (preventing workers from bringing virus-infected laptops within the firewall parameter of a company) and for web services (recently, in 2005). I haven't hard about its application in webmail applications. I don't quite see why platform attestation would be needed there. Anders, can you explain? Also, I agree with Julien that a big advantage of webmail apps is that any Internet-connected computer anywhere running any platform can be used to access them. Regards, Peter -------------------------------------------------------------------------------- _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
