From: Adam Back <aba@dcs.ex.ac.uk>
Date: Fri, 10 Oct 1997 04:04:30 +0800
To: kelsey@plnet.net
Subject: Re: Defeating MITM with Eric's Secure Phone
In-Reply-To: <199710091653.LAA14615@email.plnet.net>
Message-ID: <199710091908.UAA00790@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




John Kelsey <kelsey@plnet.net> writes:
> Adam Back <aba@dcs.ex.ac.uk> writes:
> [computationally infeasible jobs for MITMs]
> 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.

We were discussing this problem before turning to talking about
automated methods.  I think Eric Blossom suggested this earlier on:

> 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.''

It seems like a good solution.  An interesting question might be how
many times can you use the same table without starting to leak values.
Perhaps it doesn't matter that much because the MITM can't exactly use
brute force on the problem otherwise you will know he's there.  He has
to act non-passively to extract information.  (Presuming the protocol
exchanges part of the information hashed for the challenge is
encrypted with the negotiated key).

> Now, the problem with this is that it's too cumbersome.

What would be nice would be able to have information on one sheet of
paper which you could continue to use for lots of communications,
without need for calculator, or computer, or more emailed tables.

> 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 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.

I considered this approach (XOR and + function) earlier in this
thread.  I don't think it works because the functions are commutative.
(Unless I'm missing some aspect of the system, perhaps the
interlock... it's a while since I've read the protocols.)

Here's why I think it doesn't work: We have Alice, Mallet and Bob.

Alice & Bob exchange via email password 123456.  The displayed digits
of the hash of Alice/Mallet's DH parameters are: 222222.  The
displayed digits of Mallet/Bob's DH parameters are: 333333.

Alice computes 123456 + 222222 = 345678; Alice says to Mallet: "345"
Bob computes 123546 + 333333 = 456789; Bob says to Mallet: "789"

Mallet recovers the first 3 digits of the passphrase from what Alice
said:	345 - 222 = 123

Mallet recovers the last 3 digits of the passphrase from what Bob
said:	789 - 333 = 456

Mallet has recovered the passphrase and can now spoof Alice to Bob and
Bob to Alice, he says: 456+222 = 678 to Alice, and 456+333 = 789 to
Bob.

Same story with XOR, only it's harder to compute.

I think you need an encryption function.  It depends on how many times
you wanted to re-use the passphrase.  The "encryption" function could
be very weak for one use.  For lots of uses you'd need a real
encryption function.  Problem is encryption functions aren't typically
very easy to perform as mental arithmetic exercises; and
non-programmable calculators don't help much.

The table solution gets around this problem nicely, because it is a
secure way of using a one time password.  Possibly a relatively secure
way of re-using that password even, if mallet has to become active to
obtain information, and gets detected on occasions when he doesn't
yet have sufficient information.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`