Re: Any feedback would be appreciated...
- From: "bah26" <smythe70@xxxxxxxxxxx>
- Date: 31 Mar 2006 11:29:10 -0800
Revised version
Trusted computing provides a platform which is able to remotely attest
to its current state. This allows the precise hardware and software
configuration to be learnt. Once in possession of such information the
third party can make an educated decision as to whether they trust the
platform. A platform may be untrusted if it is running a modified
version of a program for example. At the core of the architecture is a
hardware device called a Trusted Platform Module (TPM). This chip
provides the cryptographic guarantee that the reported data is indeed
correct. Applications for trusted computing include Grid Computing,
corporate Digital Rights Management (DRM) and electronic voting. Grid
Computing uses the resources of a large number of systems to tackle
computationally expensive problems. For example the \emph{M4 Message
Breaking Project} has recently deciphered two of the three unsolved
German ciphers used during World War II. However, such systems are open
to abuse. Clients may modify software or simply return fictitious
values. Trusted computing resolves this problem by providing a
guarantee that the client is running the legitimate program in the
correct manner. Organisations can be assured that corporate machines
are running only authorised software which is capable of enforcing
strict policies for the control of documents and email. Restrictions
may prevent printing, or even the leaking of sensitive corporate data
to external sources. The heavily condemned Diebold electronic voting
system can be compromised by a lone programmer. Trusted computing would
again resolve such an attack. Although the astute reader is reminded
that the TPM itself must be trustworthy.
The aforementioned Grid Computing example relies upon the ability of a
trusted platform to provide a remote attestation. In a similar scenario
one could consider a situation where the user demands that her identity
be protected. The third party must therefore only learn that a platform
is trusted and not which particular one. This problem arose in the
context of the Trusted Computing Group (TCG). The TCG are a non-profit
organisation that aims to establish open industrial standards for the
development of trusted computing systems which ensure a sufficient
degree of security whilst preserving privacy and individual rights. The
problem has been addressed by the Direct Anonymous Attestation (DAA)
protocol~\cite{DAA} developed in collaboration between Intel, IBM and
Hewlett Packard. Subsequently it has been adopted by the
TCG~\cite{TCG05} as the method for remote authentication of a trusted
platform whilst preserving the privacy of the system's user.
The concept of privacy has been widely debated and several taxonomies
have been formally proposed~\cite{Pfitzmann01, Pfitzmann05, Reiter98}.
For the purposes of this document a privacy preserving protocol is one
that satisfies anonymity and unlinkability. The definitions of which
have been adopted from Pfitzmann \& K\"{o}hntopp~\cite{Pfitzmann05}.
\emph{Anonymity} is the state of not being identifiable within a set of
agents with the same attributes. The set of agents consists of all
those who might cause an action and anonymity becomes stronger as the
size of the set increases. Reiter \& Rubin liken the notion to
\emph{``blending into a crowd."} In the presence of a large crowd, each
member of which is equally likely to have performed an action, it is
impossible to establish from whom the action originated.
\emph{Unlinkability}\footnotemark specifies that given two or more
items originating from the same agent it is not possible to link them.
As a counterexample two documents bearing the handwritten signature of
an individual allow the items to be linked. Unlinkability only has
meaning once anonymity has been achieved, since actions can always be
linked if the identity of the agent is known.
\footnotetext{Unlinkability may also be called \emph{relationship
anonymity}. This term is avoided to prevent confusion with anonymity}.
The remainder of this dissertation is structured as follows.
Section~\ref{secBack} introduces the mathematical and cryptographic
primitives used in this work. The DAA protocol is explained in
Section~\ref{secDes}. In Section~\ref{secSecurity} a formal analysis of
the protocol is conducted to gain reassurance that the required privacy
properties have been satisfied. As a result of the analysis several
vulnerabilities are discovered and subsequently corrected. A Java API
for the protocol is developed to support future application
development, and one such example application is created
(Section~\ref{secImpl}). The development process is subject to
validated \& verified in Section~\ref{secTesting} and the management of
the project is documented (Section~\ref{secProjman}). Finally an
appraisal of the work is presented (Section~\ref{secAppraisal}), future
direction considered (Section~\ref{secFurther}) and conclusions are
drawn (Section~\ref{secConc}). %need to change last sentence when I
know what's in last three sections...
.
- References:
- Any feedback would be appreciated...
- From: bah26
- Any feedback would be appreciated...
- Prev by Date: Re: Any feedback would be appreciated...
- Next by Date: Re: From the "This is True" mailing list
- Previous by thread: Re: Any feedback would be appreciated...
- Next by thread: Books for Sale
- Index(es):
Relevant Pages
|
|