Bill Stewart <stewarts@ix.netcom.com> writes:
Another game you can play, with the audio, is to have music playing in the background, so Eve not only has to fake Alice's voice, but has to fake Alice reading numbers against a background of an arbitrarily-selected musical piece.
There are two types of MITM attack: i) the eavesdropper lets your voice go through ii) the eavesdropper re-synthesizes your voice, or has two actors one for Bob, one for Alice holding separate conversations Your suggestion of having a CD playing in the back-ground only helps against type i) MITM. James's method of forcing the MITM to commit to delivering packets with sizes which he can't deliver similarly only applies to type i), as does my stego idea. I think we stand a chance against type i). Type ii) seems pretty hard to stop by either manual cleverness (mixing in comments related to the hash digits) or automated methods (such as James's or my earlier stego idea). I mean, heck, the actors could run two completely different conversations, and weave into the conversation earlier topics covered with Alice which they wanted to hear responses to, from Bob, and vice-versa. The MITM could potentially have as long as he wanted to think of something clever to say to sound consistent with a comment made by Alice or Bob relating to their hash digits. Or he could simply choose to omit saying anything related to hash digits. They could play different CDs, or no CDs, or go buy a copy of the CD, or have a nice selection on tap as radio stations do (they seem to be able to play any track with a couple of seconds notice). I think the only real way to stop MITM to a paranoidly high degree of certainty is to use authentication and web of trust. Perhaps you can get a high enough degree of certainty for your application with preventative measures against type i) MITM firm in the belief that type ii) MITM is too difficult, or too expensive to try against you. I'm not sure it's even that expensive or difficult. If I was a drug king pin, or mafia, or military intelligence I wouldn't feel safe with these approaches alone. I'd want separate authentication. Probably another kind of attack would be dangerous too: if the attacker re-routes my phone call or hi-jacks it prior to set up of secure comms. Without authentication I could have a convesation with a spook instead of Bob Gotti and not know it. Alice need never know I called, or may simultaneously, or some time afterwards have a call from another spook with faked ANI. Persistence authentication suggestion: I can see one strong protection feature which isn't currently built in to Eric's phone which could be, should be I think. Shouldn't be that hard to do. You have the situation currently that you call Bob's number to go secure, then have a conversation. Well if you make several calls to Bob with the first call being MITM free, because the MITM hadn't singled you out for investigation yet, no use of this fact is made to reduce the MITM's chance of succeeding next time. (People who know some about SSH protocols may be guessing what's coming next). A way to use the fact that you have had one or more non-MITM'd calls is for the unit to remember the number and exchange a secret with the called unit inside the encryption envelope. The next time you call the same unit (as defined by calling the same phone number), you use the shared secret to authenticate the call. If the other unit can't do this, you get suspicious. You could do better than using the phone number: you could have the units exchange public El Gamal or DSA keys (bearing in mind Eric's understandable avoidance of RSA). When you call up a unit you first send it a nonce to sign with it's EG/DSA key. It signs it and sends you it's public key. If you already have the public key, you check that the signature matches. If you don't have the public key, you save it for next time. You probably want to assign the public key some human meaningful value that can be displayed on the display. If you have no input device, I guess a sequence number would do. (First secured phone you ever call is called user 1, etc). Then the user can write down who he thinks each caller is caller 1. Black Unicorn, 2. Lucky Green. 3. Tim May, etc. You could even slap a sticker on top of the box with a few places to enter this information. In addition this feature means that you can secure one communication with a PGP emailed table of key words to lookup hash digits and speak words. After that secured communication all further communications are also authenticated. If you don't use a PGP secured email, well you still have authenticated that you are at least talking to a persistent MITM. This in itself is useful, because the MITM may make mistakes, or you may arrange to call from different numbers arranged by out of band communications. If you once get a different key, you get suspicious, as the once could be the only time you got through to the real Bob, as opposed to the MITM. Another way to authenticate yourself would be if you met face-to-face with someone you plan to use the phone with in an office with an internal switch board, or with a test rig such as Eric has to demonstrate his phones. (How easy would it be to have the units directly plugable -- plug them together, plug a phone in talk make secured call, remember or write down that user 3 is Tim May. I like this use of persistence authentication. What do you think Eric? Another method, which could be used in addition would be for Eric to install an additional key into the units, and certify that key. If the sale is in person, perhaps you could even personalise them with the users name & dob or something unique (users choice). At least that way Eric gets to profit from the MITM/spooks as they've got to buy a unit to get a certified key :-) Course it makes Eric, or Eric's laptop, a _fat_ target, but would be cheaper than including full web of trust certification capability, and could add some utility. Anyway, I like the persistence authentication idea. And I'd encourage Eric to build it in. 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`