[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: secure phone on a PCI card? (Re: authentication suggestion for secure phone) computationally infeasible jobs for MITMs)
Adam Back writes:
> John Deters <[email protected]> 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