Sorry for the long delay in responding, I was traveling out of "radio range" this week.
At 06:23 PM 1/4/2008 -0500, Leichter, Jerry wrote:
| > | ...Also, I hate to say this, we may need to also require that all | > | encrypted traffic allow inspection of their contents under proper | > | authority (CALEA essentially).... | > Why not just require that the senders of malign packets set the Evil Bit | > in their IP headers? | > | > How can you possibly require that encrypted traffic *generated by the | > attackers* will allow itself to be inspected? | | You misunderstand me. We can for the most part easily identify | encrypted data, either it is using a standard like SSL or it is | non-standard but can be identified by data payload characteristics | (i.e. random bits). If it is a standard (or even a defacto standard | like Skype) we can require access under proper authority. If it is | not (or access under authority is refused), then just simply block or | drop the packets, there's no need to inspect them. Just because it *looks* like SSL doesn't mean that the key it leaks to you is actually valid. And if it *is* actually valid, it doesn't mean that there isn't a second layer of encryption inside the SSL session.
Generally any standard encrypted protocols will probably eventually have to support some sort of CALEA capability. For example, using a Verisign ICA certificate to do MITM of SSL, or possibly requiring Ebay to provide some sort of legal access to Skype private keys. If there is a 2nd layer of encryption then this would require initial key exchanges that may be vulnerable to interception or after-the-fact analysis of the decrypted SSL payloads.
Go back to my example: How will you distinguish between random bits and a compressed video stream? Do you assume that every codec in the world will be registered? How about a big scientific dataset of floating point values? Or some huge, validly formatted, spreadsheet of such values?
Well, in order to be useful, codecs need to be well known. If unknown then they probably follow well known algorithms and thus probably be ameniable to dogged digital forensics.
And that doesn't even consider obvious countermeasures. What happens if you decrypt and see a bunch of ASCII values that follow the first and second order statistics of English text? Sure, encoding my encrypted data like that costs me some overhead - but given the speed of today's networks, who cares?
Sure, but then interoperability goes out the window, and I'm pretty sure that most thieves and attackers are not going to rebuild complex protocol stacks and textual parsers from scratch. This is what software reuse is all about. In the case of botnet control lines then this may be more likely but it seems to me that once you identify the suspicious packet flows (which you are of course looking for on the infected machine), that dedicated forensics analysis can be done successfully. These packets would probably have some sort of anomolous signature compared to more normal packets of the same nature. Also, don't forget, at the very least L4 signature information will never be encrypted, otherwise it would be unroutable. And remember even if you can decrypt the botnet control lines (which still must do key distribution/exchanges over the same comm links as the victim computers so it should be possible to intecept them) you can certainly block them with something like a Cisco guard.
This train left the station a *long* time ago.
So it's not so clear that the train has even left the station. - Alex -- Alex Alten [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
