Re: Platform Attestation. was:To SSL-client-auth or nottoSSL-client-auth, that is the question(?)
Anders Rundgren
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" <peter.d...@gmail.com>
To: <dev-tec...@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-tec...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Peter Djalaliev
Thanks for your reply.
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 :)
>
I completely agree with you here. Especially since the TPM-enablied
technologies haven't been widely implemented yet into operating systems and
applications. How exactly they will/should be implemented is unclear. For
example, the TPM functionality should not be accessible by any user
application. Also, one widely-circulated issue is tat each TPM has an ID,
which in theory can be used to disallow privacy on the web. However, if the
implementation does not allow the ID to leave the host platform, then this
wouldn't be an issue. When I read about TPM technologies and the TCPA
online, it sometimes sadly reminds me of the Salem witch hunt...
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
Kyle Hamilton
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
Peter Djalaliev
> 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.
In this example, are you referring to platform authentication or to an
attestation of the software stack loaded on the platform? What I mean by
"platform attestation" is that a host can attestate the software components
loaded on it to a remote host during a network connection. If the remote
host deems the loaded software components as untrusted (e.g. a crypto
library with a known bug in it), it can refuse or otherwise restrict the
connection. I hope ther was no misunderstanding.
We are not really authenicating the platform due to privacy reasons.
Instead, the user is issued a attestation identity key and certificate from
a privacy CA. The client sends the AIK certificate with the attestation
quote, and the server uses tht certificate to verify the quote signature.
The user can even have multiple attestation identities and choose which one
to use. Since privacy CAs can bind an AIK certificate to a TPM-enabled
platform, they could compromise the client's privacy. Hence,the TPM
1.2standard uses zero-knowledge proofs instead of AIK cetificates.
Correct me if I am wrong, but it seems like we are talking about different
things. I am personally not familiar with the MS Active Directory.
> 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).
You have a point here. Right now IBM Thinkpads have the TPM chips on the
methorboard. I'm sure we will see improvements here if TPMs become more
widespread. IMHO, having the tamper-resistant TPM chip and its
functionality still gives us more than we had before.
> 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.)
I'm surprised. Are there any plans to export more of the functionality
through the PSM module or in any other way?
Regards,
Peter
Anders Rundgren
>> 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.)
Peter D wrote:
>I'm surprised. Are there any plans to export more of the functionality
>through the PSM module or in any other way?
Actually the problem is [quite] a bit trickier than exporting APIs.
A browser can be regarded as a Virtual Machine (VM), typically
running *untrusted* application code (e.g. downloaded HTML pages),
in a sandbox mode.
Cryptographic libraries are OTOH programmatic interfaces
supposed to be called by *trusted* applications. AFAIK, neither
the concept of an interactive user or a display is a part of such.
That is, what is missing is not really an API, but a secure "bridge"
between the user, GUI, browser and the crypto libraries. "signText ()"
is a minimal version of such a bridge.
Missing US Government requirements
The reason why this is not happening is that there are no requirements
from the US government for signature support in browsers. The
disparate governments in the EU and Asia (who have such requirements),
are unable to run this as a united effort. This is hardly surprising because
such missions are outside of the scope of most governments. That the
US government is a crucial player in this space is due to the dominance
of the US SW industry, as well as their use of English :-)
PKI is [still] a "research" topic
In addition, there is a lot of confusion in this space when you start to
design systems which makes it hard to come up with a specification.
http://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-1.pdf
http://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-2.pdf
If you (all) have a solution to these questions that use true E2ES
(End-To-End-Security), I would like to hear about this! So far
nobody have dared to *publish* how such a system would work.
That this has implications is because it affects "what to sign"; the
actual transaction, or just a locally stored "assertion" associated
with the out-going transaction. To sign the actual transaction
would require the browser to handle any number of protocols
and formats, as well as doing message encryption. IMO, such
a thing will never fly. Therefore I have in my related WASP
work, made signining transactions directly, as out of scope.
That this [in the eyes of some people] violates the core of PKI is
something I consider of little importance since the assertion method
is the de-facto standard in practically all existing pre-PKI transaction
schemes.
Anders R