[523] in cryptography@c2.net mail archive
chosen protocol attack
daemon@ATHENA.MIT.EDU (John Kelsey)
Sun Apr 13 11:24:03 1997
To: "Perry's Crypto List" <cryptography@c2.net>
Reply-To: kelsey@email.plnet.net
From: John Kelsey <kelsey@email.plnet.net>
Date: Sun, 13 Apr 97 02:15:45 CDT
-----BEGIN PGP SIGNED MESSAGE-----
[ To: sci.crypt, alt.cypherpunks, cryptology list ##
Date: 10-Apr-97 ##
Subject: Protocol Interference and the Chosen Protocol Attack ]
At this year's protocols workshop, I presented a paper involving
a very fun attack. (This paper was joint work with Bruce
Schneier and David Wagner, but I gave the talk.)
Anytime you have two or more cryptographic protocols that share
some key material, it becomes possible for one protocol to
*interfere* with the other. That is, some message in protocol Q
may make it possible to break some security requirement of
protocol P. Although I had a hard time finding one, there have
apparently been several of these. (The workshop participants
gave me a lot of useful examples and citations for the final
paper, which we have to submit Real Soon Now.)
The next part of the paper was the (as far as I know) original
part--the ``chosen protocol'' attack. We start with a target
protocol P, and devise a protocol Q such that Q interferes with
P. We then convince our targets to use this protocol with the
same keys as the target protocol. This can be done in many
cases, since public key pairs, especially properly certified
and/or escrowed ones, are fairly expensive to come by. There
are three parts to our results:
1. It's always possible to build a chosen protocol to break a
target protocol.
2. It is often possible to build a chosen protocol that looks
plausibly like a legitimate protocol.
3. We can recommend a set of guidelines (mostly things people
have been recommending for the last several years anyway, with
some small extensions) that, if used for all protocols with the
same underlying key material, appear to make the chosen protocol
attack impossible. (We're still trying to find a proof for
this, though I got some ideas from another presentation at the
conference on how I might be able to do this.) Essentially, the
guidelines are things like ``uniquely identify all your protocol
messages in the same way and the same plave for each message.''
Protocol messages must be unique per version, application,
protocol, and step that may ever be used with the same key
material.
I think this is often a practical attack. Imagine an
application with two parts that use cryptography--an electronic
payment system whose protocol have been very carefully reviewed,
and a high-score-verification mechanism that was more-or-less
thrown together at the last minute by a single programmer. The
high-score verification mechanism just isn't all that critical,
so who cares if its protocol has a few quirks? Of course, it
*does* happen to use the same key material. This lets a single
programmer break the heavily reviewed protocol, even though he
was never even trusted to work on that protocol.
Things can get even worse. A user often will have a single
certified public key. If we need certificates for some
protocol, the most obvious way to do this is to just reuse the
certified public key in many different protocols by different
authors. Thus, the user loads a new application onto his
system, OKs its request for access to his keypair, and has thus
allowed a whole new class of attacks on all other systems that
use his keypair.
Of course, the right way to do this is probably to have CAs
issue users certificates authorizing them to certify temporary
public keys for different applications. The one way I am sure
will resist the chosen protocol attack is to make each different
function (read email, sign outgoing mail, open the garage door)
use a different key, and then internally review the protocols to
carry out each individual function.
Comments? I probably didn't explain this as well as I would
have liked.
--John Kelsey, Counterpane Systems, kelsey@counterpane.com
PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBM1CGVEHx57Ag8goBAQHeswP+JQ2kgqMVdQL3ZVi85Rt8f1/DBelO7exM
QRvYbkAVKtQQPv90pu+0+Qo9A2tMAXAu2gGDjInocDNgSS2Q8LTVBPw6v6St74+X
l2kd6WEtBwPl8TUffGdzm8JyLBVtMVoPdkzWJdbUSKO9zJFDtHKSf1ju3ZVWLyoF
YZwMO0rjfTg=
=SfjY
-----END PGP SIGNATURE-----
--John Kelsey, kelsey@email.plnet.net / kelsey@counterpane.com
PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36
