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`