Re: Think Piece: Key Free Trust in the Semantic Web

On Thursday 04 April 2002 20:45, Aaron Swartz wrote:
> PKI and Web-of-Trust networks are designed to foil Man-In-The-Middle
> (MITM) attacks, not who's-key-is-this? problems.

I don't follow. For public keys, they are largely the same problem. My 
scenarios is orientated towards validating a signature on a single 
document. The Man-in-the-Middle scenario is orientated towards the exchange 
of multiple interactive documents. (The person can sit in the middle 
proxying the messages back and forth watching the conversation while 
fooling both sides.) But, they share the same problem of, "This is really 
Andrew's (or Bacon's) key." [a]

> is aimed at simply solving the problem of finding someone's real key in a
> world of confused, but not actively malicious peers, like someone at the
> ISP replacing all fingerprints and public keys with ones they've created.

The nature of the threat might be different, but the problem is to be sure 
one has the right key. Someone  might get access to the usenet archives, 
impersonate someone at a PGP key signing party, "bush" attack SW-Google, 
break a root CA, etc. These are all possible threats. Some more 
likely/costly than others.

> One interesting solution to the Web-Of-Trust key-signing problem that
> I've heard (from Zooko[1] is to simply sign each other's keys now, before
> the enemy gets their AI MITM software working which automatically
> intercepts and converts traffic to their own system of fake keys...which
> assumes that they haven't gotten it working yet ;-)

If I understand: solve the trust key exchange/finding problem before you 
encounter the trusted key exchange/finding problem. ;)



[a] http://www.silicon-trust.com/background/sp_pki.htm
[[
The level of security provided by the Public Key Infrastructure (PKI) is 
often acceptable; however, it is not perfect. One problem is that if a 
hacker has knowledge of your private key information, they can intercept a 
message and replace the public key with one of his or her own. This is 
known as a man-in-the-middle attack. 

Let's say Andrew wishes to send a message to Barbara and encodes it with a 
public key. However, a hacker intercepts the message. To Andrew, the hacker 
pretends to be Barbara. To Barbara, the hacker pretends to be Andrew. The 
hacker deciphers the message, reencodes it with a bogus key and sends it on 
to Barbara. Barbara decodes the message with herprivate key.

The sequence of events is as follows:Andrew <> ( <> Hacker <> ) <> Barbara 
The hacker also intercepts, deciphers and reencodes Barbara's messages to 
Andrew. The messages have been seen by an unauthorized third party; and 
neither Andrew or Barbara realizes the security system has been violated. 
The basic problem here is that keys have been switched.

Thwarting man-in-the-middle attacks 

The task of a Certificate Authority (CA) is to check submitted public keys 
for authenticity. A CA issues certificates which basically state, "This is 
really Andrew's public key". The process works as follows. Andrew sends his 
public key to the CA. The CA returns it to him with a certificate. Andrew 
then sends a message to Barbara, encoded with the public key, and includes 
the certificate. She receives the message. Since Barbara already has 
Andrew's public key, she compares the two keys. If they are the same, the 
message is OK.
]] 


-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Thursday, 4 April 2002 22:35:00 UTC