To get such an attestation to TLS, there are really two authentications that must be done (and this is, btw, akin to the model that MS Active Directory takes):
1) The terminal must have its own keypair (in AD, it's a preshared machine password hash) which must be used to authenticate the terminal. 2) The user must have his own keypair (certificate) which must be used to authenticate the user. (In AD, it's a preshared user password hash.) This pair of attestations must be done in such a way that the user isn't prompted for the use of his certificate before the terminal is authenticated, if terminal authentication is required. The concept of platform attestation is flawed at its base (you can make any hardware tamper-resistant, but if someone knows how it's put together the tamper-resistance can ALWAYS be bypassed -- that's why it's called tamper-resistant, and not tamper-proof). Things can be made "tamper-evident", but that relies on the capability of physically inspecting the machine (tamper-evident tape, for example, that looks solid but has 'VOID' unattached to the plastic backing). However, if people insist on such things, a means could be devised right now on machines which do not disable machine identification. Use a hash of the machine identifier as a pre-shared key to begin the TLS session, then have the server turn around and demand a renegotiation with a client certificate. (Perhaps extend the protocol by allowing the server to demand different types of certificates.) A TPM could extend this with a challenge/response mechanism, but even in that case multiple machines (the server and the client) need to be operating from the same algorithm and parameters -- and as soon as the algorithms and parameters are disclosed once outside of the TPM, they become untrustable. (This is why I say that any machine can emulate any protocol, since once the parameters are known they can be reimplemented.) As for Firefox, the only thing which can be used via JavaScript is signtext. If there were a crypto object in the DOM which could support more than just signtext, it would be quite nice -- but there isn't one as far as I've been able to tell. (I have not looked that closely, however.) -Kyle H On 7/20/06, Peter Djalaliev <[EMAIL PROTECTED]> wrote:
> If platform attestations will reach TLS or not is of course an interesting > topic and at this stage we can just guess. It would be interesting to hear some arguments against this happening. I personally don't have any. 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 standalone crypto support (e.g. java) rather than > using the native browser and OS crypto. These solutions are incompatible > with the native TLS client-auth. What are the "plugin" authentication methods you refer to, are they also certificate-based? Also what do you mean by "a signature solution" - do you mean that browsers do not have support for digital signature incorporated in them? I though that Firefox does - isn't this NSS funcitonality exported to other Firefox modules through the PSM or other XPCOM interfaces? Regards, Peter
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
