authentication suggestion for secure phone (Re: computationally infeasible jobs for MITMs)

[Adam Back <aba@dcs.ex.ac.uk>]

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`