- From: Joseph Reagle <reagle@w3.org>
- Date: Thu, 4 Apr 2002 22:34:59 -0500
- To: Aaron Swartz <me@aaronsw.com>, RDF-Interest <www-rdf-interest@w3.org>
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