[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re:On SKIP and non-interactive key management
Here is the third part of my responses to Hugo's comments.
>From: hugo@watson.ibm.com
>* Replay of Kp. There is nothing in the current proposal to prevent the
>replay of the data key Kp. To be more specific let Kp be a key used by
>node i to authenticate some information transmitted to node j. Assume
>that an adversary A happens to know this Kp. A can then resend the key
>Kp encrypted under Kij in a packet to j and authenticate the new information
>(as coming from i) by using Kp. (Notice that A knows how the encryption
>of Kp under Kij looks just by taking it from the original packet from
>i to j). One could wonder how does A know Kp. We usually hope that this
>does not happen but our role as security designers is to have less hope
>and more safeguards. Indeed, Kp (which is a transient key and then possibly
>less protected or may be even a cryptanalyzable weak key) can be broken
>with time (the above attack does not require the replay to happen shortly
>after the legitimate use of Kp) or could be legitimately known by A.
I am not convinced about the actual danger of this kind of attack.
The attack involves compromise of an authentication key and
doesn't really apply to privacy keys. There is no reason whatsoever
for an authentication key to be weak. No performance reason, and no
export control reason.
For fast ICV computation, one can compute a message-digest and
compute the MAC code over the digest or encrypt that using a
strong cryptosystem. There is no performance penalty here to using
something like multiple encryption DES (say triple DES), since we
are only talking about 8-16 bytes per packet. And of course,
the encryption of Kp doesn't have to weak either, for the same
reasons. Note that the encryption of Kp under Kij overhead is not
per packet but per key-change.
Also, the weak cryptosystem export requirement is only for privacy
algorithms, not authentication algorithms.
So there is no reason *at all* for this key to be weak (and this
is part of the reason why SKIP separates authentication and
privacy keys).
If we are going to be hypothetical about weak keys, just for the sake
of discussion, the key-management keys (the equivalent of Kij in SKIP)
could also be weak (why not?). This would compromise the long-term keys,
and therefore allow attacks from authentication failure as well. This
kind of argument can be made against any conceivable protocol.
If there is a legitimate reason for Kp or the encryption of Kp
to be weak, I would be happy to learn of it.
Because of this, I dont think that there is any reason to
complicate the protocol just for the sake of this issue.
If this is really a hot button, then I can suggest solutions
(not right now, but in a future message) that can prevent this
which don't require synchronized clocks or the need for interactive
key-management with its associated complexity. However, I am
personally not convinced that this is such a big issue.
>To illustrate the later point, consider a scenario where i sends to both
>j and A the same information authenticated with Kp and then transmits
>Kp to each of them encrypted under the respective master keys Kij and
>KiA. In this case, A legitimately learns Kp (and, with some added curiosity,
>also the value of Kij(Kp)).
This, of course, is even less likely, because there is no reason to reuse
keys Kp for different nodes. They are always randomly generated for each
end node. If by chance they happen to be the same for different end nodes,
(near zero probability) the end nodes will never learn of this because
they are encrypted under different master keys.
Peace,
Ashar.