secure phone on a PCI card? (Re: authentication suggestion for secure phone) computationally infeasible jobs for MITMs)

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

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`