Bypassing encryption by "tricking" host computer

[Erich von Manstein]

Sorry for the strange title but I couldn't think of a better way to explain this. I recently read the following in an article on MSNBC.com:

Encrypted files on the peer-to-peer network could not be decrypted by CopyRouter, but the company claims it can fool the sender's computer into believing that the recipient was requesting an unencrypted and uncompressed file. The slide show calls this "special handling." This is done by changing the underlying protocol settings that establish how the sender and recipient exchange the file. This trickery, unknown to either the sender or recipient, would make it possible for CopyRouter to see the underlying files, calculate a hash value and compare the files to the list of illegal files, Brilliant Digital says.

http://www.msnbc.msn.com/id/27198621/page/2/

Is this possible? And, if it is, how extensive could it be? Virtually all of internet business these days revolves around encryption - credit card numbers, social security numbers, etc. While the article simply mentions encrypted files on P2P networks, it seems to me that it would only be one small step from tricking computers on P2P networks into sending decrypted versions of encrypted files to tricking computers on standard networks into doing the same. Then again, I really have no clear understanding of this "special handling" technique that the article mentions. Does anybody know more about how this works?

[GrnEyedDvl]

Just in theory. Encryption algorithms are not exactly my specialty. Basically if you and I were going to exchange encrypted files, after the machines do their handshake, my machine applies the algorithm and yours applies it in reverse once you receive the file. Basically this tool would step into the middle of that process and prevent the encryption from being applied in the first place.

For this to work, the software has to embed itself somewhere in the Application layer of the TCP/IP protocol stack. I would consider this a severe violation of ethics, such as Sony's rootkit of a few years ago, which also embedded itself into the OS for similar reasons.

The problem is that you are using this software without your knowledge, this company already has a history of this and actually lost a lawsuit on that, so to get around this they are inserting the packets into your stream while they are in transit.

I wouldnt worry about SS and CC numbers as much as the SSL encryption is completely differently than software encryption, its done through sockets which operate differently. But I would worry about any information you send that is encrypted such as email or client information or company files. All of it is potentially at risk, and there isnt a damn thing your network administrator can do about it since it is happening outside the network. Lawsuits will be plentiful.

[Simetrical]

Sorry for the strange title but I couldn't think of a better way to explain this. I recently read the following in an article on MSNBC.com:


http://www.msnbc.msn.com/id/27198621/page/2/

Is this possible? And, if it is, how extensive could it be? Virtually all of internet business these days revolves around encryption - credit card numbers, social security numbers, etc. While the article simply mentions encrypted files on P2P networks, it seems to me that it would only be one small step from tricking computers on P2P networks into sending decrypted versions of encrypted files to tricking computers on standard networks into doing the same. Then again, I really have no clear understanding of this "special handling" technique that the article mentions. Does anybody know more about how this works?

From the summary, I get the impression that it works like this:

1. User A's file-sharing program sends a request for an encrypted file. The request itself is not encrypted.
2. Man in the middle edits the request so that it actually requests an unencrypted file.
3. User B's file-sharing program receives the modified request and sends the file unencrypted, as requested.
4. Man in the middle encrypts the file and passes it back, keeping an unencrypted copy for itself.
5. User A's file-sharing program receives an encrypted file as requested, and decrypts it.

The key is step 4. That step would simply be impossible in HTTPS, because the response must be encrypted with a public key that's certified by a recognized certification authority (CA) as belonging to the domain name that's being requested. So you don't have to worry about this happening in e-commerce: the man in the middle would not be a CA and so would not be able to forge the certificate. (Theoretically the courts could order a CA to forge certificates for them at will, but I can't see that being popular.)

But in peer-to-peer file sharing, you have no central authentication. That's rather the whole point. To authenticate someone without having a previous shared secret, there needs to be some kind of certification framework, either a certification hierarchy or a web of trust. But a hierarchal scheme isn't suitable for P2P the way it is for HTTP (and it has its problems there too . . .), and webs of trust tend to be messy and complicated to deal with, potentially unreliable.

So I'm guessing the protocols in question use the technique often used with SSH, namely "hope that nobody's meddling on the first request, and assume the other guy is legit, and then on later requests make sure they're using the same key as on previous ones". Or the weaker strategy of not even remembering keys. This will stop all passive attacks, but will do nothing against an active attacker who's willing to rewrite your requests appropriately.

Of course, there are still ways around this if users or P2P software developers take an active hand. Your ISP can't do anything if you tunnel to somewhere else first, assuming you tunnel using something more secure that it can't meddle with; but most people don't have useful places to tunnel. More plausibly, you could try to manipulate the session initiation so that it looks like something different, say an HTTP request. The ISP would have a hard time trying to figure out which HTTP requests are real and which are fake.

In general, the grassroots user software can change more rapidly than the software that tries to follow it, so I don't see this as being very effective in the long run. At worst, P2P users can get more sophisticated and get a real web of trust going. Then I'd only download sensitive files from you if your public key is signed by people who are trusted by people who are trusted by people I trust, or something like that (maybe with more links). You'd have to try infiltrating the web of trust to get around that, but that wouldn't be easy if it were designed properly, AFAIK.

I wouldnt worry about SS and CC numbers as much as the SSL encryption is completely differently than software encryption, its done through sockets which operate differently. But I would worry about any information you send that is encrypted such as email or client information or company files. All of it is potentially at risk, and there isnt a damn thing your network administrator can do about it since it is happening outside the network. Lawsuits will be plentiful.

E-mail isn't usually encrypted, but to the extent it is, it uses TLS, and I'm pretty sure it isn't vulnerable to this: AFAIK it relies on CAs. Most stuff that's encrypted over networks either relies on CAs or manually-determined trust (e.g., I can commit to svn.wikimedia.org because I gave the administrator my public key).

[GrnEyedDvl]

The key is step 4. That step would simply be impossible in HTTPS, because the response must be encrypted with a public key that's certified by a recognized certification authority (CA) as belonging to the domain name that's being requested. So you don't have to worry about this happening in e-commerce: the man in the middle would not be a CA and so would not be able to forge the certificate. (Theoretically the courts could order a CA to forge certificates for them at will, but I can't see that being popular.)

Peer to peer applications do not use https, which is why this can be done in the first place. The P2P protocols are more like unsecured FTP.


Certificate Authorities are one way around this with email, but that implies you have a server issuing the certificate. Application layer encryption such as the add-ons for Outlook and Thunderbird would still be vulnerable.

[Simetrical]

Only if the keys aren't transmitted in a secure fashion. PGP relies on webs of trust, people manually managing their keys. Some people add their public key to their e-mail signature: so either someone's been forging the last two years of e-mail you've been getting from them, or it's really their public key. You could rely on the latter. In practice most people don't really use that, though.