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!
Your described attack on secured communication between your browser and a server can be detected by use of certificates.
ReplyDeleteThis means you don't have to trust your ISP, but you still have to trust the certificate authority that issued the certificate for the domain of the server.
You also have to make sure the certificate keys built into your browser have not been compromised. You can view the authorities in Firefox Prefs under Advaced/Encryption. There's also an option to verify the installed certificates.
I see how that works. Thanks for the quick response!
ReplyDeleteYour scenario would fall apart on the first day, because both of your original participants would not be able to read each others messages once they were encoded using the sneaky IT guy's public key.
ReplyDeleteThey'd both realise something was afoot straight away.
Not true. Bob would not indeed be able to read the original message that Alice had sent because it's encoded with Chris's public key, but before it gets to Bob, Chris has already decoded it for himself, and then re-encoded it with Bob's actual public key. As Chris has automated this process, there's no time lag and neither would be any the wiser. Bob wouldn't know that the message he was receiving wasn't the one that Alice sent, and nor would Alice.
ReplyDeletehttp://www.simonsingh.com/The_Code_Book.html
ReplyDeleteRead this book for a well explained an fascinating understanding.
The core problem here is that encryption equates identity with the key. If you don't have some way of proving that the key is associated with the identity (and this can't be done through encryption directly), then Mallory (the usual culprit in this sort of drama) can interpose himself in front of anything and everything. The problem of key distribution is often more difficult than the actual math involved in an encryption system.
ReplyDelete