Death of antivirus software imminent

[Alex Alten]

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
alex at alten.org



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com