[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: [email protected]*Subject*: Re: Defeating MITM with Eric's Secure Phone*From*: Adam Back <[email protected]>*Date*: Thu, 9 Oct 1997 20:08:15 +0100*CC*: [email protected], [email protected]*In-reply-to*: <[email protected]> ([email protected])*Sender*: [email protected]

John Kelsey <[email protected]> writes: > Adam Back <[email protected]> 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`

**Follow-Ups**:**Re: Defeating MITM with Eric's Secure Phone***From:*Bill Frantz <[email protected]>

**Re: Defeating MITM with Eric's Secure Phone***From:*Human Gus-Peter <[email protected]>

**References**:**Defeating MITM with Eric's Secure Phone***From:*"John Kelsey" <[email protected]>

- Prev by Date:
**Re: Internet Via Electric Lines?** - Next by Date:
**Re: EU Rejects GAK** - Prev by thread:
**Defeating MITM with Eric's Secure Phone** - Next by thread:
**Re: Defeating MITM with Eric's Secure Phone** - Index(es):