Defeating MITM with Eric's Secure Phone

["John Kelsey" <kelsey@plnet.net>]

-----BEGIN PGP SIGNED MESSAGE-----

[ To: cypherpunks, coderpunks, Perry's Crypto List ##
  Date: 09-Oct-97 ##
  Subject: Defeating MITM with Eric's Secure Phone ]

>Date: Wed, 8 Oct 1997 23:48:33 +0100
>From: Adam Back <aba@dcs.ex.ac.uk>
>Subject: computationally infeasible jobs for MITMs (Re: Secure
phone)

>How about this for a computerised method to do something similar. 
Aim
>of the game: to make the MITMs job computationally infeasible.

[Method using stegoed audio noise deleted.]

I prefer to work on the more immediately useful problem:
How can I secure my use of the (very nicely done) Comsec
secure phones using existing infrastructure?  I am concerned
with the MITM voice impersonation attack, since that's the
easiest attack on the system. (Actually, it's probably
easier to physically tap my office, but I can't fix that
right now.)

The simple MITM defenses (like restating your checksum
spontaneously in the middle of the conversation) take care
of lots of this.  Here's another way that may make some
sense, though it's a little hard to use:

1.	Exchange PGP-encrypted e-mail establishing a set of
sixteen different words, labeled for 0..f in each direction.
Thus:

0.	Dilbert
1.	Alpha
2.	Cable
3.	Swordsman
...
f.	Marxist

Now, the checksum reading is very hard to spoof.  Suppose I
get 0x33f. I say ``My checksum is Swordsman Swordsman
Marxist, or 33f.''

An attacker with digits besides 3 and f in his checksum
simply doesn't know how to impersonate me to the other
party.  He lacks the secret information we've shared.

Now, the problem with this is that it's too cumbersome.  I
would like the shared secret information to be usable with
less effort.

If we just want to detect the MITM eventually, then I can
send the other participant a PGP-signed e-mail, in which I
include the whole 6-digit checksum.  That won't prevent the
MITM attack from working once, but it will let us know
after-the-fact if our conversation was exposed.  If we find
evidence that our conversation was intercepted, then we can
start using my one-time word lists, or some other more
paranoid mechanism.

Still another approach, which may be applicable for some
people, is to write a simple calculator-type application
that uses a shared-secret to compute a checksum on the
checksum.  Thus, when I call Alice, I do the following:

1. Type the shared secret between Alice and me into the
calculator app.

2. Make the call to Alice and push the ``secure'' button.

3. Type the six-digit checksum into the calculator app.

4. Read the calculator's first three checksum digits.

5. Listen to her next three digits.

The simplest way to do this seems to be to just exchange a
six-digit hex value as a one-time password for a given
secure phone call.  This is done using PGP or some other
mail encryption package, and can legitimately be used to
exchange a long list of one-time passwords at once. Then,
use Windows' calculator application (with View set to
Scientific, and Mode set to Hex) to add your one-time
password to the checksum.  Thus:

1. I pull up Alice's latest encrypted e-mail, and get
today's phone password.

2. I open the Windows calculator, set it to View/Scientific
and hex mode, and type in the password (a six-digit hex
number) and ``+.''

3. I call Alice, say hello, and push the ``SECURE'' button.

4. I type the six digit hex checksum into my calculator.

5. I read the first three digits of the result to her.  She
reads the next three to me.

All of this (except for maybe re-reading the checksum in the
middle of the conversation) is probably overkill.  Still, it
may be worth something to someone.

Is there a clean way to have the secure phone box take input
from the dialpad on the phone, without sending it out on the
phone line?  If so, then maybe some later version could
include a PIN-secured mode, using EKE or SPEKE or something
similar.  (For a supported mode, the checksum wouldn't need
to be read over the phone anymore.  We would need to protect
the shared PIN from brute-force attack, however.)

>Adam


   --John Kelsey, jmkelsey@plnet.net / kelsey@counterpane.com

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2

mQCNAi5JqlEAAAEEAPCEHMBdDCAJ83/ibNM7ngCaaibv7YkTxcpKPjTO+WcjswFV
SEzMeTqW4MX2wSKdfcMq1HembbgfYs7v2UCnUFkLPZF19s3yUSISGcS7JxlBc3q1
7uj8W5XfBoGpgCYQqYFL2+AB/+3tLu7lU5iiEYCnevY5GQkq0kHx57Ag8goBAAUR
tCdKb2huIE0uIEtlbHNleSBKciA8am1rZWxzZXlAZGVscGhpLmNvbT6JAJUDBRAv
5uh7QfHnsCDyCgEBAQZ2A/9/OMeWK4YC+PnEzBTmgpF4WAOsVXfzRD3zAbzfNWY9
MEGo4gRF8Mr1lPHdK+0JOHp327mj9ZvYqQb1bV5fwc5dJa8/Z34VLPYlVg2rV7vJ
Hd0YnrgkoaIerbRmtP8dmZGeygeFtrk8aDCdcnMm27+tTJACl5hv2yjFO9rxBq+R
MLQpRXhwaXJlcyBmb3IgbmV3IHNpZ3MvbXNncyBvbiBEZWMgMzEsIDE5OTc=
=pOyw
- -----END PGP PUBLIC KEY BLOCK-----


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNDy68UHx57Ag8goBAQGP1QP9H6Z9Infv1z1swBzpEsvn+VZyweMj20to
EQNRFcfLvNFu140kWokWfgIcSXh1CBrsz93/CMoZgIb8l1cpGIU51kFgz/DTXGvj
5XQCFcUzBRAEraxeF7xFnEH+Ss35lcCvzAXaWaVLB6apBvXP5ZkZtFr/vUYLhrtF
Y34E8AAXFrg=
=AlX3
-----END PGP SIGNATURE-----


   --John Kelsey, Counterpane Systems, kelsey@counterpane.com
 PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36