Re: Secure phone

At 09:21 AM 10/2/97 -0700, you wrote:
>At 11:13 PM 10/1/97 -0700, Lucky Green wrote:
>> Bad idea. You don't want people to have to look up keys to use your device.
>> Some people may not want to be listed in the phone book. Not to mention
>> that a PKI adds an additional and unnecessary layer of complexity. Just use
>> DH and have the parties each read half of a hash of the public
>> exponentials. No keys to store, no keys to remember, no keys to compromise.
>
>Trouble is this exposes the system to the man-in-the-middle attack.  Perhaps
>you could take advantage of the real time nature of the system to prevent
>man in the middle, by constructing a protocol such that man in the middle
>will invariably time out during the connection setup, or produce an
>audible lag problem in speech.

The MITM attack is thwarted by Lucky's note:
>> DH and have the parties each read half of a hash of the public
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> exponentials. No keys to store, no keys to remember, no keys to compromise.
   ^^^^^^^^^^^^^

Each party reads off a series of digits displayed on their screen.  Out
loud.  To each other.  Over the secure phone.

The MITM attacker can't duplicate the hash on both ends, because a hash of
the public keys used to make the connection are different between the
MITM's public key and the real public keys.

Here's a secure conversation (assume for the moment that the addition below
represents a strong hash):

Alice <-------------------------------------> Bob
PK=1234                                       PK=5678
1234+5678=6912                                5678+1234=6912
Alice reads 69 over the phone, and Bob reads 12 back to her.
Alice and Bob proceed to have a private conversation.

Now, since Mallory has to create a PK, he cannot just duplicate
Alice's 1234, because he'd also need the private key to decrypt the
conversation.  Likewise, he cannot duplicate Bob's 5678.  He has to
generate his own PKs in an attempt to fool Bob & Alice.

Alice <-----> Mallory <-> Mallory <---------> Bob
PK=1234       PK=1111     PK=2222             PK=5678
1234+1111=2345                                5678+2222=7900
Alice reads "23" over the phone, and Bob reads "00" back.
Since Alice's hash function said she should hear "45" back from
Bob, and Bob's screen said he should have heard "79" from Alice,
Alice and Bob decide to talk about the weather, and how pretty 
the trees are in certain cities.

Mallory could try to thwart this by impersonating Bob's voice to
Alice, saying "45", and Alice's voice to Bob, saying "79"
(Mallory does, of course, know these numbers), but if Bob & Alice
know each other, this probably won't work too well.  Mallory would
have to be able to cut into the conversation real-time, undetected.

Now, of course, Mallory could hire Anna & Barry to pull the whole
impersonation thing off, so that for the entire conversation Alice
talks to Barry and Anna talks to Bob, each thinking that they're
really talking to the other, but that's also fraught with risk.
I'm sure they could pull it off on TV, though  :-)

So, it'd go full circle back to pass phrases again.
"I hear the cherry trees are lovely in Washington D.C."
"I wouldn't know, I've never visited Washington in the spring."
"I agree, the weather is usually too wet."

John
--
J. Deters "Don't think of Windows programs as spaghetti code.  Think
          of them as 'Long sticky pasta objects in OLE sauce'."
+--------------------------------------------------------------------+
| NET:   mailto:jad@dsddhc.com (work)   mailto:jad@pclink.com (home) |
| PSTN:  1 612 375 3116 (work)          1 612 894 8507 (home)        |
| ICBM:  44^58'36"N by 93^16'27"W Elev. ~=290m (work)                |
| For my public key, send mail with the exact subject line of:       |
| Subject: get pgp key                                               |
+--------------------------------------------------------------------+

>The MITM attack is thwarted by Lucky's note:
>>> DH and have the parties each read half of a hash of the public
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> exponentials. No keys to store, no keys to remember, no keys to compromise.
>   ^^^^^^^^^^^^^
>
>Each party reads off a series of digits displayed on their screen.  Out
>loud.  To each other.  Over the secure phone.
>
>The MITM attacker can't duplicate the hash on both ends, because a hash of
>the public keys used to make the connection are different between the
>MITM's public key and the real public keys.

In addition, to keep life even more interesting, prior to exchanging
the public exponentials g^x and g^y, commitments (hashes) to those
values are exchanged...  If the commitments don't match the final
values, the protocol terminates.  See http://www.comsec.com/vp1-protocol.ps 
for all the details.

Eric

Eric Blossom <eb@comsec.com> writes:
> >Each party reads off a series of digits displayed on their screen.  Out
> >loud.  To each other.  Over the secure phone.
> >
> >The MITM attacker can't duplicate the hash on both ends, because a hash of
> >the public keys used to make the connection are different between the
> >MITM's public key and the real public keys.
> 
> In addition, to keep life even more interesting, prior to exchanging
> the public exponentials g^x and g^y, commitments (hashes) to those
> values are exchanged...  If the commitments don't match the final
> values, the protocol terminates.  

I can't see that this prevents MITM either.

Eve, the attacker, just sends commitments to the values she would have
sent in performing the MITM were there no commitments.

Still falls back to a belief that a well resourced attacker can't
splice audio in real time.

Say (for example) if someone smuggled me one of your phones, and I
called up Tim.  The only protection I'd have is recognizing Tim's
voice after hearing him speak breifly years ago.  (American accents
sound similar to me).

On the other hand, using persistent key public key crypto, Tim has
been signing his posts recently, and I have an ancient public key of
his stashed away which his new key is signed with.  If we were able to
construct a protocol to bolt on top of the reading of hashes, we could
have much greater protection against MITM.

To answer the other poster who opined that you had no business saying
things to people who's voices you don't recognize: nonsense.

We're saying things all the time to people who's voices we've _never_
heard with PGP.

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`

>> In addition, to keep life even more interesting, prior to exchanging
>> the public exponentials g^x and g^y, commitments (hashes) to those
>> values are exchanged...  If the commitments don't match the final
>> values, the protocol terminates.  
>
>I can't see that this prevents MITM either.
>
>Eve, the attacker, just sends commitments to the values she would have
>sent in performing the MITM were there no commitments.

What the commitment prevents is a birthday attack on the verification
code by Mallet.  Mallet has to be able to come up with a g^x' that
when concatenated with g^y and hashed computes the same verification
code as g^x concatenated with g^y and hashed.

Exchanging commitments to g^x and g^y prior to sending g^x and g^y
severely constrain the the degree of freedom that Mallet has to work
with.  (Another option that works the same way is the "interlock"
protocol, where each side sends half the message (g^x or g^y) and
doesn't send the second half until after receipt of the first half
from the other end).

>Say (for example) if someone smuggled me one of your phones, and I
>called up Tim.  The only protection I'd have is recognizing Tim's
>voice after hearing him speak breifly years ago.  (American accents
>sound similar to me).

None of this is designed to provide authentication of the end point.
It is designed to ensure that you've got a private channel to the end
point. 

>On the other hand, using persistent key public key crypto, Tim has
>been signing his posts recently, and I have an ancient public key of
>his stashed away which his new key is signed with.  If we were able to
>construct a protocol to bolt on top of the reading of hashes, we could
>have much greater protection against MITM.

Agreed.  The primary difficulty is getting the public keys into the
unit.  And agreeing on what kind of certificate to use...  
My preference (for patent reasons) would be to use DSA or ElGamal
signatures.

Eric

Eric Blossom <eb@comsec.com> writes:
> What the commitment prevents is a birthday attack on the verification
> code by Mallet.  Mallet has to be able to come up with a g^x' that
> when concatenated with g^y and hashed computes the same verification
> code as g^x concatenated with g^y and hashed.

Yes.  But that just means that you need commitments to prevent a MITM
brute forcing a key with the same partial hash.

I don't see that commitments on DH parameters do anything to prevent
someone who can impersonate voices, as far as I can see it is all
going to collapse back to whether the attacker can impersonate voices
and splice in without audible noise.

> >On the other hand, using persistent key public key crypto, Tim has
> >been signing his posts recently, and I have an ancient public key of
> >his stashed away which his new key is signed with.  If we were able to
> >construct a protocol to bolt on top of the reading of hashes, we could
> >have much greater protection against MITM.
> 
> Agreed.  The primary difficulty is getting the public keys into the
> unit.  And agreeing on what kind of certificate to use...  
> My preference (for patent reasons) would be to use DSA or ElGamal
> signatures.

How about touch tone keypad (phone).  Bit tedious?  Or temporarily
plug unit into a PC's modem port?

What about... a key server on a phone number.  You call key directory
services, you type in phone number, and your phone downloads
certificates and phone numbers, and uploads it's own certificate.
Also put the keyserver on the internet.

Too much complexity probably, if most of your users won't be using it
as it will add to cost.

But I do think it would be a good idea for you to include
documentation on a good secure way to use a PGP signature to exchange
use-once keys suitable for printing on a sheet of A4 which would keep
a user going for a few hundred calls.  Plus easy to follow description
of how to use.  Your suggestion in another post in this thread was a
challenge response.  Say you printed a matrix of random numbers or
words which were exchanged before hand via PGP.  And then use the
digits of the hash on the LCD screen to do a table lookup.  The
attacker won't be able to do his MITM because he won't know the table,
and so won't know what value he should read.

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`

At 12:05 PM 10/6/97 -0700, Eric Blossom wrote:
>None of this is designed to provide authentication of the end point.
>It is designed to ensure that you've got a private channel to the end
>point. 

Therefore, man-in-the-middle can be more precisely described as an
unauthenticated end-point problem.  Therefore, without authentication,
there is no defense (yet) against MITM attacks.

One of the previous threads got me thinking:  the original thought was
something on the order of "make it so complex it takes so long to compute
that we know there was an MITM."  Obviously, Mallory can be given enough
resources to defeat a computationally bound challenge.  However, could
there be a way to use a trusted third party (Trent) to validate such a scheme?

Lets say that Trent is a trusted third party that operates a Digital
Notary, and will sign and datestamp any packet.  Can we use the old "one
oracle always lies, one oracle always tells the truth" riddle to pass a
request through Bob (or in the MITM case, Mallory) to Trent, who always
tells the truth?

(The riddle works like this:  You enter a room with two doors.  In front of
each sits an oracle.  A sign says that, "One oracle always lies, one always
tells the truth; behind one exit is a hungry tiger, and behind the other is
freedom.  You are allowed to ask the oracles any questions you wish."

The answer is: ask one of the oracles "which door would the OTHER oracle
say contains the tiger?", then you pick the OPPOSITE door to make your
getaway.  The idea is that you use the truth of one to include the lie of
the other to ensure your safety, without attempting to discover the
irrelevant fact of which oracle lies.)

Can we somehow use this to force a MITM to tip his hand?  Can we ask the
other end "make this request of Trent, and send me the response?"  Any
request Alice makes of Bob will instead be made by Mallory on Bob's behalf,
so it has to be for something either non-duplicatable or externally
verifiable.

Perhaps Alice and Bob can both ask Trent to do something externally
verifiable.  They could both ask Trent to lock up for a ten-second period
of time.  I know the MITM could use Trent for the conversation with Alice,
and Terrance for the conversation with Bob, but if Trent is somehow agreed
to or implied by the protocol, it might work.  But, of course, nobody would
want to sit around waiting for their 10 seconds of holding.  And if you had
to wait, it would give time for Mallory to spoof the waits.  

What if both sides asked Trent to display a list of all "registered"
conversations that were taking place at a particular point in time?  Trent
could list that between 9:48:01 and 9:48:06 there were 20 conversations
being authenticated.  Among them are:  Alice PK 1234 was talking to Bob PK
1111 and also a Bob PK 5678 was talking to an Alice PK 2222.

Of course, this guarantees externally auditable traffic analysis.  But if
we're trying to assure that an unauthenticated Bob can talk securely to an
unauthenticated Alice, it might be an acceptable tradeoff.

All this assumes that the MITM can't get between Alice and Trent.  If an
authenticated public key is used for Trent, then Alice is OK as long as
Mallory isn't Trent's operator!

Obviously, the easy solution is to use authenticated public keys all
around.  Replace Trent in the above with Trusted Public Key Server, and
authentication is guaranteed.  

John
--
J. Deters "Don't think of Windows programs as spaghetti code.  Think
          of them as 'Long sticky pasta objects in OLE sauce'."
+--------------------------------------------------------------------+
| NET:   mailto:jad@dsddhc.com (work)   mailto:jad@pclink.com (home) |
| PSTN:  1 612 375 3116 (work)          1 612 894 8507 (home)        |
| ICBM:  44^58'36"N by 93^16'27"W Elev. ~=290m (work)                |
| For my public key, send mail with the exact subject line of:       |
| Subject: get pgp key                                               |
+--------------------------------------------------------------------+

At 12:44 PM 10/7/97 -0700, Eric Blossom you wrote:
>I wrote:
>> Therefore, man-in-the-middle can be more precisely described as an
>> unauthenticated end-point problem.  Therefore, without authentication,
>> there is no defense (yet) against MITM attacks.
>
>I concur from the theoretical point of view.

Really, that's the only point I was attacking.  I agree that from a
practical standpoint that you probably would be able to detect a fake voice
today.

However, a weakness is a weakness, and from a practical standpoint, digital
audio technology is not getting worse as time goes on.  The phone phreaker
world has a blue box (available on the net and called bluebox, I think)
that uses the sound card to generate tones to fool phone systems into
giving them free long distance.  It also will use a recorded human voice to
"read" credit card numbers and phone numbers to a telephone operator.
While it's not perfect, it does manage to get inflection and tone properly
across.  The imperfections are ostensibly covered up by the omnipresent
telephone network noise (from which your box does not suffer.)  

It would not take an enormous amount of recorded conversation to have
enough samples to extract the complete set of hex digits from any given
speaker.  But, it would take an enormous amount of chutzpah for a MITM to
try it.

It would be easy enough to "trick" the MITM into exposing their existance
anyway, just by using digits that come up in conversation.  Humans would be
able to come up with unique situations that the MITM would find all but
impossible to predict.  "Hey, Eric, I noticed that the third digit of your
IP address' second octet is the same as the second digit of our exchange.
How's by you?"  A sudden dropout of sound (or "accidental" loss of
connection) while the MITM recognizes the trap and tries to backpedal will
be instantly noticed.  Human protocols are resilient, whereas mathematical
protocols are precise.

Having a working theory behind securing the exchange (whether or not you
implement it) makes for a nice mind exercise, anyway.  Your working boxes
are a far cry above any theory we discuss here.  If I had one of your nifty
boxes, I'm sure I wouldn't lose sleep over the theoretical holes.

John
--
J. Deters "Don't think of Windows programs as spaghetti code.  Think
          of them as 'Long sticky pasta objects in OLE sauce'."
+--------------------------------------------------------------------+
| NET:   mailto:jad@dsddhc.com (work)   mailto:jad@pclink.com (home) |
| PSTN:  1 612 375 3116 (work)          1 612 894 8507 (home)        |
| ICBM:  44^58'36"N by 93^16'27"W Elev. ~=290m (work)                |
| For my public key, send mail with the exact subject line of:       |
| Subject: get pgp key                                               |
+--------------------------------------------------------------------+

>> It would be easy enough to "trick" the MITM into exposing their
>> existance anyway, just by using digits that come up in conversation.
>> Humans would be able to come up with unique situations that the MITM
>> would find all but impossible to predict.  "Hey, Eric, I noticed
>> that the third digit of your IP address' second octet is the same as
>> the second digit of our exchange.  How's by you?"  A sudden dropout

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.

Now, the effectiveness of the technique may depend on the musical
tastes of the players ("Hey - that's not Toscanini conducting
Beethoven's Fifth - that's the Furtwangler version on Deutsche Gramophon!"/
"Oh, was that Elvis?  I guess so."/ "We're being MITMed - the Terrapin Station 
during the numbers was off the album, where Jerry remembered all the words, 
and now you're playing an audience tape version from Nassau in 89" )
and with some genres of music, it makes it easier to notice if 
there's a gap.
				Thanks!
					Bill
Bill Stewart, stewarts@ix.netcom.com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

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`

At 01:15 PM 10/10/97 +0100, Adam Back you wrote:
>Persistence authentication suggestion:
>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 problems with this solution are twofold:

1.  Eric may have to redesign the unit to have persistent read-write
storage.  And maybe a *lot* of storage, if you use it a lot.  Maybe a lot
of expen$ive $torage at that.  His phone is already priced way out of the
consumer market, let's not add to that.

2.  I had problems with UUCP when my machines got out of sync (way back
when.)  Just think how bad they'll look if they refuse to light up "secure"
because one guy had to change batteries.

I agree with you that external authentication is the only way to fly.  And
if it is simply accepted, lets let Eric's unit survive unmolested and use
PGP out-of-band (as per Monty's suggestion) or use PGP to exchange session
keys (like in Speak Freely.)

I also think the most likely avenue of attack will be a black bag job on
the individual user's phone.  MITM attacks seem too risky and expensive to
pay off.

John
--
J. Deters "Don't think of Windows programs as spaghetti code.  Think
          of them as 'Long sticky pasta objects in OLE sauce'."
+--------------------------------------------------------------------+
| NET:   mailto:jad@dsddhc.com (work)   mailto:jad@pclink.com (home) |
| PSTN:  1 612 375 3116 (work)          1 612 894 8507 (home)        |
| ICBM:  44^58'36"N by 93^16'27"W Elev. ~=290m (work)                |
| For my public key, send mail with the exact subject line of:       |
| Subject: get pgp key                                               |
+--------------------------------------------------------------------+

John Deters <jad@dsddhc.com> writes:
> At 01:15 PM 10/10/97 +0100, Adam Back you wrote:
> >Persistence authentication suggestion:
> 
> The problems with this solution are twofold:
> 
> 1.  Eric may have to redesign the unit to have persistent read-write
> storage.  And maybe a *lot* of storage, if you use it a lot.  Maybe a lot
> of expen$ive $torage at that.  His phone is already priced way out of the
> consumer market, let's not add to that.

If it cost a lot extra, that could be a problem, yes.  I am unclear on
how much extra this would cost.  Apart from an EEPROM, it's a protocol
and software update right?

> 2.  I had problems with UUCP when my machines got out of sync (way back
> when.)  Just think how bad they'll look if they refuse to light up "secure"
> because one guy had to change batteries.

Use an EEPROM?

> I agree with you that external authentication is the only way to
> fly.  And if it is simply accepted, lets let Eric's unit survive
> unmolested and use PGP out-of-band (as per Monty's suggestion) or
> use PGP to exchange session keys (like in Speak Freely.)

> I also think the most likely avenue of attack will be a black bag
> job on the individual user's phone.  MITM attacks seem too risky and
> expensive to pay off.

For individuals perhaps.  For military intelligence or mafia boss type
uses perhaps not.  

Or perhaps not for lower security apps too: buy a small landline phone
to use as a handset, carry your box with you every where you go, never
let it out of your sight, move around a lot, hotel rooms, anywhere
else random you can get a phone jack socket.  I reckon there would be
potential clients who might fit this life-style.


On the cost front, I am interested as to thoughts on how easy it would
be for Eric to put one of his phones on a PCI card, or PCMCIA card.
Presumably you could make some major cost savings in this way, in that
you could potentially use the computers modem, memory, processor.

PGP Inc's pgpfone I think is sort of compatible with Eric's phone.
However pgpfone audio quality _sucks_.  (Admittedly one end was using
a 14.4k modem when I tried it -- but it was _terrible_, even no
encryption was fairly bad).

I think Eric's phone uses a 14.4k modem chip (or lower?) so it's not
the bit rate as such, but more the lack of higher quality audio
compression codecs which are possible in hardware.  (Right?)  

Also the fact that with PGPfone you're using PC speakers, and room
microphone probably makes it seem worse than it could be.

A socket to plug a phone into to act as a speaker/microphone would be
a good start, plus the audio codec part of the Eric's hardware.

Now what do you reckon you could get the price of that down to?


How would that work out with a PCMCIA card... I'm thinking of laptops using
GSM mobile phones data links, what would the audio quality be like over the
9600 bit data rate over a GSM mobile phone? If it could work it would be
neat as you'd have a fully mobile secure phone.  Better than Jim McCoy's
cell phone strapped to his laptop: secure phone PCMCIA card in one PCMCIA
slot, PCMCIA modem in the other slot, mobile phone plugged into PCMCIA
modem, al-cheapo phone handset plugged into secure phone PCMCIA card. 
Tangle of wires, but still neat.  Pity GSM phones don't have audio in, and
mike out jack sockets, which get selected when you plug in the data lead,
or you could use the GSM phone handset.

Course adding the whole lot to a GSM phone would be even neater, but
then that'd get expensive again.  Wonder how much functionality could
be borrowed from components already present for the normal GSM phone
hardware, and how much saving you could get from that.

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`

Adam Back writes:

> John Deters <jad@dsddhc.com> writes:
> > At 01:15 PM 10/10/97 +0100, Adam Back you wrote:
> > >Persistence authentication suggestion:
> > 
> > The problems with this solution are twofold:
> > 
> > 1.  Eric may have to redesign the unit to have persistent read-write
> > storage.  And maybe a *lot* of storage, if you use it a lot.  Maybe a lot
> > of expen$ive $torage at that.  His phone is already priced way out of the
> > consumer market, let's not add to that.

Hey, it's only a factor of two too expensive...  Moore's law is your friend...

> If it cost a lot extra, that could be a problem, yes.  I am unclear on
> how much extra this would cost.  Apart from an EEPROM, it's a protocol
> and software update right?

The units currently have 2K bytes of EEPROM and 256K bytes of FLASH.
A little under half the flash is currently available, though it will
probably be taken advantage of during remote upgrades (coming soon to
a crypto phone near you...)  There's plenty of room for long term
storage of a reasonable set of public keys.  Private or symmetric keys
present a problem, since then you've got a long term secret to store
somewhere.

To forestall a bunch of questions about remote upgrades:  

    (1) there is a jumper on the write line to the FLASH.  If you're
        totally paranoid, leave it in the "Read Only" position.
    (2) upgrades will be digitally signed.
    (3) It'll be a "pull" upgrade.  I.e., you have to request the
        upgrade.  They're not just pushed down your throat.


> On the cost front, I am interested as to thoughts on how easy it would
> be for Eric to put one of his phones on a PCI card, or PCMCIA card.
> Presumably you could make some major cost savings in this way, in that
> you could potentially use the computers modem, memory, processor.

I can pretty much be done all in software on a laptop.  
I've explained the details several times.  Perhaps if folks we're
paying me lots of money for the info, they would listen closer ;-)

The primary thing you lose is the simple integration with the
telephone.  A small (cheap) hardware hack can work around this.  Yes,
I know you'd prefer not to have any non-standard hardware, but on the
other hand, if the system is a pain in the ass to use, nobody is going
to use it.

> I think Eric's phone uses a 14.4k modem chip (or lower?) so it's not
> the bit rate as such, but more the lack of higher quality audio
> compression codecs which are possible in hardware.  (Right?)  

The unit currently runs at 14.4k.  A 4800 b/s fallback mode is
currently under development.

> Also the fact that with PGPfone you're using PC speakers, and room
> microphone probably makes it seem worse than it could be.

Fixable with software and MIPS (you've got those).  Take a look at
those nice USR and Polycom full duplex speaker phones.  There's
nothing magic in them.  Notice the neat little song they play when you
power them up.  It's a training tone used to compute the impulse
response of the room.

> Course adding the whole lot to a GSM phone would be even neater, but
> then that'd get expensive again.  Wonder how much functionality could
> be borrowed from components already present for the normal GSM phone
> hardware, and how much saving you could get from that.

Pretty much everything you need is already there.  It's a question of
integration.

Eric

Eric Blossom <eb@comsec.com> writes:
> > If it cost a lot extra, that could be a problem, yes.  I am unclear on
> > how much extra this would cost.  Apart from an EEPROM, it's a protocol
> > and software update right?
> 
> The units currently have 2K bytes of EEPROM and 256K bytes of FLASH.
> [...]  There's plenty of room for long term storage of a reasonable
> set of public keys.  Private or symmetric keys present a problem,
> since then you've got a long term secret to store somewhere.

What's the difference betwen storing public keys and private keys?
Are you concerned that someone will tamper with the unit and replace
the keys.  (Borrow the phone while you're out, reset the EEPROM, and
make a series of calls to put in MITM keys.)  Could be dangerous.
You could use a pin, but then you need an input device.

However, you could also argue that if someone can borrow your phone
for a while they can give it free "upgrade", and replace the RNG, or
whatever anyway, so it doesn't make any difference?  I don't think it
does.

I kind of liked the persistency authentication idea as a candidate for
your remote upgrade.  You could do it with symmetric keys or with
asymmetric keys.  It's just a trade off which depends on how many keys
you're allowing.  If space is short, you could do something more
clever, say:

- Exchange (and store in a table) a symmetric key with each new phone
- Lookup keys by phone number (or unit serial number if you don't have ANI)
- Authenticate using nonce and stored key.

Overhead: 16 bytes per phone

Allow say 50 callers = 800 bytes.  Perhaps you want a button to push
(hold go secure down for over 5 seconds, say) to store a caller in
this table.  (Prevents attacker flushing your table by making a load
of dud calls).  Or perhaps just wrap around and discard least used
numbers/serial numbers.

> > [phone on PCI/PCMCIA card]
> 
> I can pretty much be done all in software on a laptop.  
> 
> The primary thing you lose is the simple integration with the
> telephone.  A small (cheap) hardware hack can work around this.  Yes,
> I know you'd prefer not to have any non-standard hardware, but on the
> other hand, if the system is a pain in the ass to use, nobody is going
> to use it.

Fancy organising this cheap hardware hack?  I reckon you'd get a few
buyers.  I'll pledge to buy 3 at a reasonable price.  

Do you have the software for PCs/MACs?  Would this cheap hardware hack
work with PGPfone as is?  (PGP Inc don't seem to be doing much work on
PGPfone right now).

btw the hardware hack I presume is impedance matching to allow phone
to plug into 3.5mm jack audio and mic socket?  Any hardware people
care to give soldering instructions?

> > I think Eric's phone uses a 14.4k modem chip (or lower?) so it's not
> > the bit rate as such, but more the lack of higher quality audio
> > compression codecs which are possible in hardware.  (Right?)  
> 
> The unit currently runs at 14.4k.  A 4800 b/s fallback mode is
> currently under development.

GSM laptop secure phone, here we come :-)

> > Also the fact that with PGPfone you're using PC speakers, and room
> > microphone probably makes it seem worse than it could be.
> 
> Fixable with software and MIPS (you've got those).  Take a look at
> those nice USR and Polycom full duplex speaker phones.  There's
> nothing magic in them.  Notice the neat little song they play when you
> power them up.  It's a training tone used to compute the impulse
> response of the room.

I'm not sure what PGPfone's problem is, but when I tried it, it
sounded like an off tune radio station, but worse.  Even turning off
encryption entirely (to preserve the precious cycles for the audio
codec) didn't help much.

Perhaps I should retry it now with 166Mhz K5 pentium in place of
120Mhz AMD 486 at the time.

> > [integrating with GSM phone]
> 
> Pretty much everything you need is already there.  It's a question of
> integration.

It's a damn, damn, shame that no-one is doing this.

We couldn't bribe you to do it next could we?

I was kind of figuring that eventually we'll get there with a bit of
software because cellular phones and laptops functionality will merge,
and the bandwidth and processing power will be there.  Still a laptop
with your hardware hack, would be ok for now.

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`

John Deters wrote:
> 
> At 01:15 PM 10/10/97 +0100, Adam Back you wrote:
> >Persistence authentication suggestion:
> >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.

> I agree with you that external authentication is the only way to fly.  And
> if it is simply accepted, lets let Eric's unit survive unmolested and use
> PGP out-of-band (as per Monty's suggestion) or use PGP to exchange session
> keys (like in Speak Freely.)
> 
> I also think the most likely avenue of attack will be a black bag job on
> the individual user's phone.  MITM attacks seem too risky and expensive to
> pay off.

I'm not a subscriber to the CypherPunks list, but I have been monitoring
the emissions from John's computer screen, and I would just like to say 
that I agree with him, wholeheartedly. I often tell my superiors that 
there are much better ways to be spending taxpayer money.

I am not alone in my agreement with most of what is being said in this
thread.
The spook supplying heroin to Adam Back's lover agrees with most of this
thread, as does the spook peeking through Eric's window (although she
disagrees with the suggestion to "let Eric's unit survive unmolested").
The one exception is the grandson of Patton who is doing surveillance
on Monty. His method is quite simply to beat Monty to the phone.

Spooky 
(isn't it?)

John Deters <jad@dsddhc.com> writes:
> It would be easy enough to "trick" the MITM into exposing their
> existance anyway, just by using digits that come up in conversation.
> Humans would be able to come up with unique situations that the MITM
> would find all but impossible to predict.  "Hey, Eric, I noticed
> that the third digit of your IP address' second octet is the same as
> the second digit of our exchange.  How's by you?"  A sudden dropout
> of sound (or "accidental" loss of connection) while the MITM
> recognizes the trap and tries to backpedal will be instantly
> noticed.  Human protocols are resilient, whereas mathematical
> protocols are precise.

I wonder if we can come up with a way to formalise this technique and
automate it.  I think it was James voiced something similar earlier in
the thread.

Using your example, the MITM faces a couple of problems: he has to
think on his toes, and think real fast.  Perhaps he can't think fast
enough.

Second problem, perhaps if he doesn't speak soon enough, he will have
blown it, because you are speaking continuously, and the second part
of the sentence constructs a problem from information already stated.
The first time the information is stated, the MITM doesn't have enough
information to change it.

Say he changed it to: "Hey eric I noticed the second digit..." (second
instead of third), just in case this would help him.  Well he doesn't
know what the challenge will be so he may just have created an
impossible to spoof problem for himself.  (The second digit probably
won't meet the challenge in the second part of the sentence).  So this
would force the MITM to construct a replacement challenge which does
match.  Given the short notice, and already decided first part, he may
have difficulty constructing a plausible sounding challenge which
meets his criteria.  "Is the ummm... square of your first digit".


How about this for a computerised method to do something similar.  Aim
of the game: to make the MITMs job computationally infeasible.

Say that we leave some noise in the speech channel.  Some of it isn't
really noise but encrypted data.  Say perhaps first stegoed packet is:

	E(k1, nonce) = packet1

and second stegoed packet is:

	E(k2, nonce) = packet2

and finally there is a mask which controls which bits of the noise are
actually encrypted data, and which are parts of the actual message.

Send this last:

	E(k3, mask)

Then send the three keys k1, k2, k3.

Then check that the packets1 and 2 reconsituted according to the mask
both decrypt to the same nonce.

The idea is that because of the mask, the MITM doesn't know which bits
to replace.  So he tries to construct his own challenge meeting that
protocol.  Fair enough he can do this.  But he will degrade the voice
quality because he will replace some more signal with noise.  Can we
tune this protocol so that the recipient can detect the extra noise?

Well, ok, if the recipient can detect the noise, surely the MITM can
too?  Yes but, choosing different bits to reduce the noise isn't free,
and the hope is that you can construct a system with an expensive
noise estimation function which is agreed to as part of the protocol.
So you find out 10 seconds into the conversation that there is a MITM.

The MITM has to compute this noise function in real time, to avoid
introducing lag.

It's not very good, but I'm sending it along anway, so that perhaps
y'all can improve on it,

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`

At 11:48 PM 10/8/97 +0100, Adam Back wrote:
>I wonder if we can come up with a way to formalise this technique and
>automate it.  I think it was James voiced something similar earlier in
>the thread.

I think that's the problem:  once it's formalized and automated, it's
spoofable by a MITM.  The informal, "Hi Adam, my first digit's the third
digit of your phone number today, how's your end?" type of query, perhaps
made before or after the entire "I've got 78F, what's yours?" sequence, is
going to remain secure.  If we assume the MITM can spoof your digits, he
can also spoof a whole query without weird digit splicing in the middle.
It's like the cartoon cat looking the cartoon dog image in the mirror,
waving and trying to trick the image.  You can attempt to outmaneuver a
MITM with trick questions which will almost certainly expose him, but if
the stakes are high enough...where there's a will, there was a dead body.

Without some external reference, be it the knowledge of the public key of
the other participant, or using a trusted arbitrator, keyserver or
whatever, I don't think you *can* mathematically authenticate the other
end.  The MITM with full knowledge will always be able to reconstruct the
proper replies.  Your best defenses will be:
    1) External (out-of-band) authentication, as in a PGP key
       signing party, or even just having Bob's key fingerprint
       from a piece of e-mail posted to cypherpunks a year ago.
    2) Wetware outclevering the MITM.

Re:  your noise introduction protocol.  Cute idea, but what if Mallory
simply audio-couples his two phones together along with a noise compander
circuit a la Dolby?  That kind of noise is precisely what the simple
electronic filters can remove, and the digital portion is passed via the
coupling computer system (the one that spoofs the voices.)

"Hey, Bob, I think we've got a MITM!  This connection is too clear!"  :-)

I think the hardest to defeat will be the case where Mallory hires Alicia
and Bobby to impersonate Alice and Bob to each other.  
Alice <---------------------------> Bob  (what they think is happening)
Alice <---> Bobby______Alicia <---> Bob  (what actually is happening)
           /                 \
          under Mallory's control

where Bobby and Alicia have the translator's gift of speaking while
listening.  They could fill in the cracks with idle chatter, have their own
personalities, and basically run both shows.  They could even run offline
from each other, being intelligent humans.  As long as Alice and Bob only
communicate through Mallory's intermediaries (i.e. never meet in real life,
out-of-band), Mallory owns the show.  (Tell me you've never seen something
like that on a rerun of _Mission_Impossible_!  :-)

Would you know if you were talking to the REAL John Deters?  All I could
assume about you is that if my phone rang and a voice claimed to be Adam
Back, I'd expect to hear it in a British accent, and with just a bit of
time delay so I'd know it was coming across the Atlantic.  About 50 million
people could pass themselves off as you today, and I'd never know the
difference.  I can't even tell a Liverpool accent from a London accent!
And if I had a voice recognition system, well, then I'd hope if I was
taking a voice sample from you that I'd be smart enough to exchange public
keys so we could do our authentication the right way.

Again, my position is:
  o  internal authentication is *not* information-theoretically possible; 
  o  out-of-band authentication *can be* theoretically secure;
  o  MITM attacks are *almost* infeasible, and *always* expensive; and
  o  if you still suspect a MITM after trying to outwit one, you're just
     being paranoid.  Stop it.

John

P.S.  Even if I exchanged PGP keys with you face-to-face, compared picture
ID's, checked your fingerprints, read a signed letter from your Mom (moms
don't lie,) and *knowing* that you are indeed Adam Back, I still won't know
if you work for MI-5 or not!  Nothing's perfect, so lets take what we can
get.
--
J. Deters "Don't think of Windows programs as spaghetti code.  Think
          of them as 'Long sticky pasta objects in OLE sauce'."
+--------------------------------------------------------------------+
| NET:   mailto:jad@dsddhc.com (work)   mailto:jad@pclink.com (home) |
| PSTN:  1 612 375 3116 (work)          1 612 894 8507 (home)        |
| ICBM:  44^58'36"N by 93^16'27"W Elev. ~=290m (work)                |
| For my public key, send mail with the exact subject line of:       |
| Subject: get pgp key                                               |
+--------------------------------------------------------------------+

Eric,

	I think you can make a stronger statement.

	With your phone, once you exchange the hash you have good assurance
that you have a private conversation with the person whose voice you hear.

	How you determine that that is the person you think it is/should be
is a different problem.

	As for proving lack of an eavesdropper, you would also need to
establish that the person's earpiece wasn't bugged, the person didn't
record the conversation to hand to someone else, ....

	For my purposes, the authentication is secure enough that I'm very
pleased.  The voice quality is good enough that I can recognize friends --
and if I'm calling a stranger, then the MITM is a moot point.  That is, if
I'm calling a stranger named Bob, there is no way for me to tell the
difference between:

	Carl -- Eve -- Bob
and
	Carl -- Bob -- Eve

since both Bob and Eve are strangers to me and I don't know Bob well enough
to rule out case 2.

 - Carl


+------------------------------------------------------------------------+
|Carl M. Ellison   cme@acm.org     http://www.clark.net/pub/cme          |
|PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2|
|  "Officer, officer, arrest that man!  He's whistling a dirty song."    |
+-------------------------------------------- Jean Ellison (aka Mother) -+

> At 12:05 PM 10/6/97 -0700, Eric Blossom wrote:
> >None of this is designed to provide authentication of the end point.
> >It is designed to ensure that you've got a private channel to the end
> >point. 
> 
> Therefore, man-in-the-middle can be more precisely described as an
> unauthenticated end-point problem.  Therefore, without authentication,
> there is no defense (yet) against MITM attacks.

I concur from the theoretical point of view.

In a practical sense I guess it all boils down to what our working
definition of authentication is.  If I'm using one of my phones and
talking to somebody that I know (recognize voice, speech patterns,
shared history, ...) and the verification codes check out, I'm highly
confident that there is no man-in-the-middle.  I'm free to have
whatever conversation I like, modulo bugs in the room, laser window
bounce listeners, etc.


On the "beat the verification codes by spoofing the voice" thread:

I don't think that this is a practical threat.  You've got the
computational challenge (described in the previous posts) and the
human part.  The complications come from the fact that you've got two
live people having a conversation with each other.  At least in the
conversations I have, we don't read these things back and forth like
robots to each other.  

In secure mode there are 6 hex digits displayed on each unit.  On one
unit, the first three digits are underlined.  On the other unit, the
last three digits are underlined.  By convention, you say the three
that are underlined, and listen for the other three.  This seems to
work out pretty well in practice.  There is generally a "Hi, I'm
looking at 1FC", "4D9, good.  What's up?" type of interaction.

<Blatant_Commercial_Pitch>

I'm running a "Privacy Extremist" special on the GSP's.
$795 for one, or two for $1500.  Cash/Check/MO/MC/VISA/AMEX.
Add $16 shipping for one, $20 for two.  CA residents add sales tax.
US and Canada only.  30 day money back.  1 year warranty.

	Communication Security Corp.
	1275 Fourth St., Suite 194
	Santa Rosa, CA 95404
	v: 707-577-0409
	f: 707-577-0413
	eb@comsec.com
	http://www.comsec.com

</Blatant_Commercial_Pitch>

Eric

At 6:25 PM -0700 10/5/97, Adam Back wrote:
>On the other hand, using persistent key public key crypto, Tim has
>been signing his posts recently, and I have an ancient public key of
>his stashed away which his new key is signed with.  If we were able to
>construct a protocol to bolt on top of the reading of hashes, we could
>have much greater protection against MITM.

Of course if you can use PGP as well as the secure phone, you can use PGP
to exchange a pad of one-time passwords.

>
>To answer the other poster who opined that you had no business saying
>things to people who's voices you don't recognize: nonsense.
>
>We're saying things all the time to people who's voices we've _never_
>heard with PGP.

Are you really willing to discuss with Tim that suitcase you're planning on
bringing to the states.  :-)


-------------------------------------------------------------------------
Bill Frantz       | Internal surveillance      | Periwinkle -- Consulting
(408)356-8506     | helped make the USSR the   | 16345 Englewood Ave.
frantz@netcom.com | nation it is today.        | Los Gatos, CA 95032, USA

Bill Frantz <frantz@netcom.com> writes:
> At 6:25 PM -0700 10/5/97, Adam Back wrote:
> >On the other hand, using persistent key public key crypto, Tim has
> >been signing his posts recently, and I have an ancient public key of
> >his stashed away which his new key is signed with.  If we were able to
> >construct a protocol to bolt on top of the reading of hashes, we could
> >have much greater protection against MITM.
> 
> Of course if you can use PGP as well as the secure phone, you can use PGP
> to exchange a pad of one-time passwords.

The passwords alone don't do you any good: if you read them out over
the phone, Eve can just repeat them.

You need to combine the password with the part of the D-H parameter
hash displayed on the dinky little secure phone display in such a way
that Eve can't fake it without knowledge of your password.  It would
be nice if you didn't need a computer to perform this operation, but I
guess you could live with needing a computer.  It would also be nice
if the number of digits you had to read was relatively short.

XOR doesn't work, because Eve can undo that; XOR isn't very easy to do
mentally anyway.

Encrypting the display value with a symmetric cipher and a key formed
from the password and reading out a selection of digits from the
ciphertext would do.  But most/all symmetric ciphers worth speaking of
are beyond doing in your head, or with a piece of paper in a
reasonable amount of time.

How many digits are on the display of one of those phones?  It seems
that you should be able to concoct something which is easy to compute,
and offers as much surety as the few digits on the display.

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`

> Bill Frantz <frantz@netcom.com> writes:
> > At 6:25 PM -0700 10/5/97, Adam Back wrote:
> > >On the other hand, using persistent key public key crypto, Tim has
> > >been signing his posts recently, and I have an ancient public key of
> > >his stashed away which his new key is signed with.  If we were able to
> > >construct a protocol to bolt on top of the reading of hashes, we could
> > >have much greater protection against MITM.
> > 
> > Of course if you can use PGP as well as the secure phone, you can use PGP
> > to exchange a pad of one-time passwords.
> 
> The passwords alone don't do you any good: if you read them out over
> the phone, Eve can just repeat them.

There's no reason you couldn't use the passwords in a bidirectional
challenge/response scenario.  The units can pass (optionally
encrypted) control messages back and forth while in secure voice mode.

Eric

> How many digits are on the display of one of those phones?  It seems
> that you should be able to concoct something which is easy to compute,
> and offers as much surety as the few digits on the display.

You get 6 big characters that you can see from a couple of feet away,
or three lines of 16 characters that you have to squint at ;-)

(It's a 100 x 32 pixel graphic display).

Eric

At 10:57 AM -0700 10/6/97, Adam Back wrote:
>Bill Frantz <frantz@netcom.com> writes:
>> At 6:25 PM -0700 10/5/97, Adam Back wrote:
>> >On the other hand, using persistent key public key crypto, Tim has
>> >been signing his posts recently, and I have an ancient public key of
>> >his stashed away which his new key is signed with.  If we were able to
>> >construct a protocol to bolt on top of the reading of hashes, we could
>> >have much greater protection against MITM.
>>
>> Of course if you can use PGP as well as the secure phone, you can use PGP
>> to exchange a pad of one-time passwords.
>
>The passwords alone don't do you any good: if you read them out over
>the phone, Eve can just repeat them.

One simple possibility is to send out ten word groups.  Use each group only
once.  Use the words to encode the key hash display.


-------------------------------------------------------------------------
Bill Frantz       | Internal surveillance      | Periwinkle -- Consulting
(408)356-8506     | helped make the USSR the   | 16345 Englewood Ave.
frantz@netcom.com | nation it is today.        | Los Gatos, CA 95032, USA