This one's been bugging me for a while now, and concerns dual key encryption systems as implemented in web browsers for the purposes of secure transactions, as well as people exchanging public keys before encrypting their own mail.
First off, the basic principles of encryption as I understand them - Alice wants to exchange messages with Bob by email but doesn't want her ex-boyfriend Chris to be able to intercept them. Chris unfortunately is in an ideal position to intercept them as he works at Alice's ISP running largely unchecked with root privileges, and is highly motivated. Any internet communications coming from or too Alice's machine he can access invisibly. Hence the need for encryption.
Alice and Bob had previously tried exchanging messages using a single key encryption system - one where a single key both locks and unlocks the document. This relied on both of them knowing the key, so in order to prevent Chris from getting access to it, they had to find another way to communicate it. In the end, Alison decided on a key and mailed it to Bob. She has no idea if Chris intercepted it along the way by way of his twin brother who works at the post office.
Then they discover dual key encryption. The principle works by both Alice and Bob having their own unique private key and their own unique public key. A document locked by a particular public key can only be unlocked by the corresponding private key, so they can freely exchange these public keys by mail safe in the knowledge that Chris cannot use them to unlock their communications. The process would look like this:
Step 1: Alice mails Bob her public key.
Step 2: Bob mails Alice his public key.
Step 3: Alice writes a mail to Bob and encrypts it with Bob's public key.
Step 4: Bob opens the mail using his private key, which only he has.
Step 5: He replies, encrypting the response with Alice's public key, etc. etc. etc.
Meantime Chris intercepts all communications, but only having the public keys, can do nothing about them. A system so perfect that secure transactions via regular browsers invisibly follow a similar routine.
So the part I don't understand... As Chris is in a position to intercept and interfere with all incoming and outgoing communications from Alice, what is to stop him replacing both Alice's public key in step 1 and Bob's public key in step 2 with his OWN public key? Then at step 3.5, the mail gets as far as Chris, encrypted with what Alice assumes is Bob's public key but is actually Chris's. Chris decrypts the mail, then re-encrypts it with Bob's real public key, and allows it to continue. Likewise at Step 5.5, Chris intercepts the mail from Bob just before it gets to Alice. Again, Bob assumes it's Alice's public key but it's really Chris's, who then decrypts it, and re-encrypts it with Alice's real public key. The whole set-up is automated, so there's no time lag, and neither Alice nor Bob are any the wiser.
Put this into a secure web transaction scenario and it starts to look even more feasible, as the key exchange would not be done via cleartext mail but via an easily identifiable, fully automated protocol based exchange. And given that most likely credit card information is being exchanged, the motivation factor is also there. What is it that stops a malicious ISP employee, or a zombie ISP server from being able to use this to harvest its users' credit card details?
Answers anticipated and appreciated!