Here are some alternative applications for TCPA/Palladium technology which
could actually promote privacy and freedom. A few caveats, though: they
do depend on a somewhat idealized view of the architecture. It may be
that real hardware/software implementations are not sufficiently secure
for some of these purposes, but as systems become better integrated
and more technologically sound, this objection may go away. And these
applications do assume that the architecture is implemented without secret
backdoors or other intentional flaws, which might be guaranteed through
an open design process and manufacturing inspections. Despite these
limitations, hopefully these ideas will show that TCPA and Palladium
actually have many more uses than the heavy-handed and control-oriented
ones which have been discussed so far.
To recap, there are basically two technologies involved. One is secure
attestation. This allows machines to securely receive a hash of the
software which is running remotely. It is used in these examples to
know that a trusted client program is running on the remote machine.
The other is secure storage. This allows programs to encrypt data
in such a way that no other program can decrypt it.
In addition, we assume that programs are able to run unmolested;
that is, that other software and even the user cannot peek into the
program's memory and manipulate it or learn its secrets. Palladium has
a feature called trusted space which is supposed to be some special
memory that is immune from being compromised. We also assume that
all data sent between computers is encrypted using something like SSL,
with the secret keys being held securely by the client software (hence
unavailable to anyone else, including the users).
The effect of these technologies is that a number of computers across
the net, all running the same client software, can form their own
closed virtual world. They can exchange and store data of any form,
and no one can get access to it unless the client software permits it.
That means that the user, eavesdroppers, and authorities are unable to
learn the secrets protected by software which uses these TCPA features.
(Note, in the sequel I will just write TCPA when I mean TCPA/Palladium.)
Now for a simple example of what can be done: a distributed poker game.
Of course there are a number of crypto protocols for playing poker on the
net, but they are quite complicated. Even though they've been around
for almost 20 years, I've never seen game software which uses them.
With TCPA we can do it trivially.
Each person runs the same client software, which fact can be tested
using secure attestation. The dealer's software randomizes a deck and
passes out the cards to each player. The cards are just strings like
ace of spades, or perhaps simple numerical equivalents - nothing fancy.
Of course, the dealer's software learns in this way what cards every
player has. But the dealer himself (i.e. the human player) doesn't
see any of that, he only sees his own hand. The software keeps the
information secret from the user. As each person makes his play, his
software sends simple messages telling what cards he is exposing or
discarding, etc. At the end each person sends messages showing what
his hand is, according to the rules of poker.
This is a trivial program. You could do it in one or two pages of code.
And yet, given the TCPA assumptions, it is just as secure as a complex
cryptographically protected version would be that takes ten times as
much code.
Of course, without TCPA such a program would never work. Someone would
write a cheating client which would tell them what everyone else's cards
were when they were the dealer. There would be no way that people could
trust each other not to do this. But TCPA lets people prove to each
other that they are running the legitimate client.
So this is a simple example of how the secure attestation features of
TCPA/Palladium can allow a kind of software which would never work today,
software where people trust each other. Let's look at another example,
a P2P system with anonymity.
Again, there are many cryptographic systems in the literature for
anonymous communication. But they tend to be complicated and inefficient.
With TCPA we only need to set up a simple flooding broadcast network.
Let each peer connect to a few other peers. To prevent traffic
analysis, keep each node-to-node link at a constant traffic level using
dummy padding. (Recall that each link is encrypted using SSL.)
When someone sends data, it gets sent everywhere via a simple routing
strategy. The software then makes the received message available to the
local user, if he is the recipient. Possibly the source of the message
is carried along with it, to help with routing; but this information is
never leaked outside the secure communications part of the software,
and never shown to any users.
That's all there is to it. Just send messages with flood broadcasts,
but
