From: Eric Blossom <eb@comsec.com>
Date: Sat, 11 Oct 1997 05:25:51 +0800
To: aba@dcs.ex.ac.uk
Subject: Re: secure phone on a PCI card? (Re: authentication suggestion for secure phone) computationally infeasible jobs for MITMs)
In-Reply-To: <199710101622.RAA03364@server.test.net>
Message-ID: <199710102057.NAA02969@comsec.com>
MIME-Version: 1.0
Content-Type: text/plain



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