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
-----BEGIN PGP SIGNED MESSAGE----- [ To: cypherpunks, coderpunks, Perry's Crypto List ## Date: 09-Oct-97 ## Subject: Defeating MITM with Eric's Secure Phone ] 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