[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
analysis thus far
Warning -- wide (about 160 columns) message follows...
I decided to make a chart of the different attacks and different defenses.
There are four different attack scenarios listed: CBC cut-and-paste
and replay, for both host-based and router-based cryptography. What
jumps out from the chart is that no single defense proposed thus far
is a complete solution, though a combination of sequence numbers with
integrity checks comes closest. (It can fail against an active attack:
the enemy can delete the last few packets, create a new socket using
that port, and reinject the packets, so long as they arrive before the
sequence window has expired.)
It's also apparent that router-based crypto is very hard to defend
against any of these attacks, especially the replay. I'm tentatively
inclined to stop hardening our mechanisms against that case, and instead
decree that router-based crypto is useful if and only if (a) everyone on
the inside is trustable (but see below), or (b) it's being used as
firewall crypto to superencrypt already-protected traffic when using
the public Internet as a link in a virtual private net.
The remaining case that troubles me is the host-to-router case, where
I, on my host, am doing the right things, but I'm talking to you on
your account on bletch.com (foo.com and foobar.com are real!). Can
you read my traffic? Probably, given the stuff we've been discussing.
But that's also the case if you're doing any of myriad other things
wrong, or if you've been hacked, so it's probably not worth worrying
about here. It might, though, be worth including a flag in the certificate
indicating the granularity of protection.
The chart is below; I'm quite willing to add new rows or columns, or to
change entries as needed, or to reformat it to use tbl or LaTeX tables...
-----
Host-based Host-based Router-based Router-based
CBC cut-and-paste Replay CBC cut-and-paste Replay
----------------- ----------------- ----------------- -----------------
User-pair keying safe safe hard to implement hard to implement
Connection keying safe safe hard to implement hard to implement
Per-packet rekey safe no defense safe no defense
(SKIP-style)
Sequence numbers no protection against some protection against no protection against some protection against
w/host-pair keying active attack unless active attack; late packets active attack unless active attack; late packets
integrity used also; may be decipherable integrity used also; may be decipherable
safe if integrity used safe if integrity used
Integrity checks safe no protection safe no protection
Notes:
``safe'' means that the mechanism appears to defeat the attack.
``no protection'' means that the attack still works.
``hard to implement'' means that there are conceptual problems or that
other necessary pieces have not yet been defined, such as host-to-router
messages.