Re: Newt's phone calls
GSM includes A5 encryption here, so basically the whole design is worked out - all you'd have to do is rip out the A5 chip and replace with a decent encryption system. Anyone know how modular the design is, for instance if it would be possible to give a GSM A5 based cell phone a crypto upgrade using published electrical interface standards? (I want one of those - Nokia phone with IDEA + 2048 bit RSA signatures + DH forward secrecy!)
My guess is that this would not work. Does anyone know if when you use a GSM phone to call a landline number the cellphone<-> base station trafic is encrypted??? my guess is that only when you call GSM to GSM is the trafic encrypted and even then I would imagine each phone agrees a key with the base station for the network then the trafic between the base stations is cleartext. The only way, if this were the case, would be to write the code so that the headers and other network information like SIM ID number etc... were cleartext or just A5 to the network as standard and only the actual speech data was encrypted under something stronger. This approach could become troublesome, if I have time I`ll get hold of some GSM specifications and look at it more closely. Datacomms Technologies web authoring and data security Paul Bradley, Paul@fatmans.demon.co.uk Paul@crypto.uk.eu.org, Paul@cryptography.uk.eu.org Http://www.cryptography.home.ml.org/ Email for PGP public key, ID: 5BBFAEB1 "Don`t forget to mount a scratch monkey"
Paul Bradley <paul@fatmans.demon.co.uk> writes:
Adam Back <aba@dcs.ex.ac.uk> writes:
encryption system. Anyone know how modular the design is, for instance if it would be possible to give a GSM A5 based cell phone a crypto upgrade using published electrical interface standards? (I want one of those - Nokia phone with IDEA + 2048 bit RSA signatures + DH forward secrecy!)
My guess is that this would not work.
Does anyone know if when you use a GSM phone to call a landline number the cellphone<-> base station trafic is encrypted???
my guess is that only when you call GSM to GSM is the trafic encrypted and even then I would imagine each phone agrees a key with the base station for the network then the trafic between the base stations is cleartext. The only way, if this were the case, would be to write the code so that the headers and other network information like SIM ID number etc... were cleartext or just A5 to the network as standard and only the actual speech data was encrypted under something stronger. This approach could become troublesome, if I have time I`ll get hold of some GSM specifications and look at it more closely.
All you've got to do is super-encrypt the IDEA encrypted traffic with the standard A5 hardware - the base station won't notice the difference. Schematically, standard GSM hardware: +-------------+ +-----------+ | compress/ | +------------+ <-->| A/D & D/A |<-->| decompress |<------>| A5 enc/dec |<--> +-----------+ +-------------+ +------------+ schematically, adding a super-encryption layer: +-------------+ +-----------+ | compress/ | +------------+ <-->| A/D & D/A |<-->| decompress |<-| |->| A5 enc/dec |<--> +-----------+ +-------------+ | | +------------+ v v +-------------+ | IDEA/RSA/DH | +-------------+ So the question was (addressed to anyone who knows anything about the electrical interfaces used in GSM) about standardisation of electrical interfaces -- for instace if the electrical interface between the voice compression/decompression IC and A5 IC were standardised, you could build a replacement voice codec IC which performed IDEA/RSA/DH as well as standard the voice codec function, and had the same pin out. This IC would allow a wide range of GSM phones to be upgraded with minimal effort on the part of GSM phone manufacturers -- or even desoldered and replaced by end users, or crypto hardware company. However, there are several reasons why it would probably require proper integration into a GSM phone design: - keys tied to phone number memories - display of signature result on screen - PIN for phone's RSA signature keys - face to face key exchange - key revocation - generating new keys Adam -- 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 4:39 AM -0800 1/16/97, Adam Back wrote:
- PIN for phone's RSA signature keys
It is not clear you need signatures in the secure phone case. Eric Blossom's 3DES uses straight DH for key exchange with verbal verification that both ends are using the same key. As long as the man in the middle can't imitate a familiar voice, this procedure is reasonably secure. I agree that signatures of some kind are needed to identify the phone to the cell company to prevent an all too familiar technique of stealing phone service. But this protection would not be a 3rd party cell phone upgrade. ------------------------------------------------------------------------- Bill Frantz | Client in California, POP3 | Periwinkle -- Consulting (408)356-8506 | in Pittsburgh, Packets in | 16345 Englewood Ave. frantz@netcom.com | Pakistan. - me | Los Gatos, CA 95032, USA
Bill Frantz <frantz@netcom.com> writes:
At 4:39 AM -0800 1/16/97, Adam Back wrote:
- PIN for phone's RSA signature keys
It is not clear you need signatures in the secure phone case. Eric Blossom's 3DES uses straight DH for key exchange with verbal verification that both ends are using the same key.
How does Eric's box display the negotiated key to the user? (I don't recall the pair I saw having displays).
As long as the man in the middle can't imitate a familiar voice, this procedure is reasonably secure.
This is the approach taken by PGPfone also. If the value of the conversations was high (>$100,000?) passable voice imitation wouldn't be that hard I suspect. Also I thought it would be kind of cute if there were some way for phones to exchange their signature keys `face to face' as well.
I agree that signatures of some kind are needed to identify the phone to the cell company to prevent an all too familiar technique of stealing phone service. But this protection would not be a 3rd party cell phone upgrade.
It's about time something was done about that problem. Adam -- 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`
participants (3)
-
Adam Back -
Bill Frantz -
paul＠fatmans.demon.co.uk