Paul, I noticed you mentioned that you will be using key rings in your cryptophones, so here's an idea I think would be great for cryptophones. This is a simple solution to the key-exchange problem. Cryptophone users would not need to exchange keys beforehand nor need to store other people's public keys on their cryptophone. - Every cryptophone user has a public and private key pair (like in RSA or PGP) - When a person calls another person, the phones automatically exchange their public keys before the voice conversation begins. Obviously the private keys are never transmitted. With this method, all one needs to initiate a secure telephone conversation is the phone number of whoever you're calling, just like using a regular telephone. I am assuming this is how Clipper/Skipjack phones would do this. I hope your cryptophone software does this as well, since I don't want to or need to keep keyrings full of public keys of everyone I might ever have to call. Thug
-----BEGIN PGP SIGNED MESSAGE----- The problem with this is that public-key encryption is slooooow. I never thought of having a fixed key for each user; even the STU-III ignition keys get reloaded every so often. Until I implement DH key exchange, caller & callee must have some way to agree on a key. This is far from ideal, but (based on PGP's RSA implementation on my Mac) I don't think RSA would cut it. One possibility is to use a PGP-style keyring; the caller can encrypt the session key with the callee's pubkey and transmit it. I think that this is less secure than DH, though. More comments are way welcome! Thanks. - -Paul - -- Paul Robichaux, KD4JZG | "Crypto-anarchy means never having to say perobich@ingr.com | you're sorry." - Tim May (tcmay@netcom.com) Intergraph Federal Systems | Be a cryptography user- ask me how. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLGb6kCA78To+806NAQFsUgP/W2eKFBiKLzBg1Aip2VTzg6RJDAU4C/mt pW0RMx4dLK7ZRp8r3frmLHDnS2dcEwtu9weNOnzkFyK/j2056kn52O0icTX9w4gl xDLIm/ay3gNaDrqZDA81c9vYsdHAn3pQaK1dxx3VZoWA6Je62ULvNlrxGIEXrvX5 zEEsV/5dYkQ= =YFQP -----END PGP SIGNATURE-----
I recommend a signed Diffie Hellman key exchange for a secure phone. That is, you generate a session key with Diffie Hellman, and you sign your exchanges with RSA to guard against the meet-in-the-middle attack. I agree that RSA public keys could be exchanged as needed during the call, although this might require a few iterations before a party gets a signature that it can trust. Finding a path through the PGP "web of trust" back to a trusted public key that the other party already has may be tricky. This is one thing that is much easier with a simple tree a la PEM, as you simply give the path back up to a common, shared root. I'm not sure how to do this with PGP. Perhaps the challenger could list the public key(s) it trusts (perhaps just its own) and ask the challenged party to find a (the) route through the web that connect itself with the challenger's trusted key, and to return those keys and signatures. This might be easier than having the challenger remotely "grope" through the paths in the challenged party's key database, one signature/key at a time. Of course, keys and signatures ought to be cached to speed the process the next time around. Or the users could sign each others keys directly once they're satisified with their identities. If you first do Diffie Hellman and then immediately use the session key it generates to conventionally encrypt the rest of the protocol, including any RSA public key exchanges, this has the added benefit of denying passive eavesdroppers any information that would identify the parties to the call. The best an *active* eavesdropper (conducting a man-in-the-middle attack against Diffie Hellman) could do is to trick the parties into revealing their RSA public keys, and thus their identities. But the parties would quickly discover this at the signature step, before the voice conversation actually starts. Again, the *really* nice thing about this protocol is that once the DH session key is destroyed, there's no way to recover it even if the RSA secret keys are later compromised. And nothing (other than the availability of CPU cycles) prevents you from rekeying periodically during a single call. The worst that could then happen if the phone is captured and read out before it could be zeroized would be the compromise of the conversation since the last rekey. Phil
-----BEGIN PGP SIGNED MESSAGE----- I may have a clouded view of the technology available here, because I confess to not understanding all of your post- namely, why the "web of trust" necessarily bears here. It feels like DH would probably be the best mechanism for key exchange. When Alice calls Bob, their two Macs can conduct a DH exchange of randomly generated, valid-for-only-one-call session keys and use those to encrypt both ends of the link. The reason behind my original proposal of a system that could use PGP keyrings is thus: let's say that I want to call you. I tell my cryptophone to call "Phil Karn", so it looks up your public key and uses it to encrypt my side's session key, then signs the encrypted version with my public key. Your cryptophone answers, de-signatures the data block to see who's calling, then decodes the encrypted session key using your secret key. If you decide to accept the call, your cryptophone can send me a key by encrypting it with my private key, then signing it with your pubkey. This protocol is obviously not secure against spoofing attacks. It does support anonymous use, though- if the caller doesn't sign the encrypted session key block, you could still accept the call! The big advantage to this scheme in my mind is that it leverages PGP's infrastructure and key distribution. I'm not sure that the web model would be terribly useful; I tend to think of most calls as being either to "indirectly trusted" keys (i.e. I can call Phil Z to ask about how the developers got permission to use IDEA in PGP) or to directly trusted keys (i.e. I can call someone whose key I've personally signed.) The presence of a hardwired telephone number, of course, adds some trustability. TCP/IP traffic can be falsified in ways that POTS traffic can't, and it's very hard to subvert The Phone Company (tm). Even if I don't completely trust your key, if I call Qualcomm's front desk and ask for your work phone #, I can probably trust that. OTOH, as I read someone post the other day, "Everyone you've ever met is working for the CIA. There's absolutely no way to prove differently." :) - -Paul -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLGfGjSA78To+806NAQEunAP+PIddYdBa57YkVGwd9uXfxwDL59LABXfS fTIC8xv7L6QC0r/9az4ToJCFqIF6c2+C5ZeVdCFlQ18mjQ8MApeJkN11gynRu3aX 5qCZOs5Nmyfg2JzS95eWe75UyCwO5GepSt1LNHAA4wi5cyFtBHTULXv2MKHRvWSj YUePz50FDLg= =IqKL -----END PGP SIGNATURE-----
I agree that RSA public keys could be exchanged as needed during the call, although this might require a few iterations before a party gets a signature that it can trust. Finding a path through the PGP "web of
To me at least this seems unimportant for the application. If all you're doing is exchanging session keys over the phone, it doesn't really matter if you are sure that the public key actually belongs to who it claims it does, only that the person you're talking to (who you presumably already know) actually possesses the corresponding private key. This can be verified with a simple challenge-response system. The identity problem is removed if you use a different key pair for phone conversations than you do for signature purposes... there doesn't need to be any information actually connecting the key with you. -- Jonathan R. Guy | The opinions expressed above are not E-Mail: guy@theporch.raider.net | those of my employer. Nor are Snail: P.O. Box 158325 | they my own. Actually, I copied them Nashville, TN 37215 | from the encyclopedia.
The reason behind my original proposal of a system that could use PGP keyrings is thus: let's say that I want to call you. I tell my cryptophone to call "Phil Karn", so it looks up your public key and uses it to encrypt my side's session key, then signs the encrypted version with my public key.
You're creating an unnecessary vulnerability here. By using RSA to encrypt the session key, all of your past conversations would be compromised if your RSA secret key were ever revealed. True, this is already the case for PGP-encrypted messages which are usually sent over unidirectional mail channels. There you can't really do much better. Voice calls are different, as the availability of a two-way path lets you do things much more securely. If you generate a session key with DH and use PGP/RSA *only to sign the exchanges*, not to encrypt the session key, then even if your RSA secret key is later compromised, it would not compromise those session keys that had already been created, used and destroyed. This is a very powerful feature! Consider the profound effect it would have on the whole topic of "rubber hose cryptanalysis", either in its pure unadulterated form (blackmail, torture, death threats) or in its "legal" form (being compelled to divulge an encryption key that could be used against you, despite the 5th amendment). Session keys could be created, authenticated, used and destroyed without the user ever having to know them, or even having any way to recreate them after the fact despite knowledge of the RSA secret key that was used to authenticate them. Phil
To me at least this seems unimportant for the application. If all you're doing is exchanging session keys over the phone, it doesn't really matter if you are sure that the public key actually belongs to who it claims it does,
Well...yes. *If* you know the person you are talking to, then you can read off your session key (or preferably its hash) to guard against the man in the middle. But let's say you are being referred to someone who you don't already know (or you know them only by email, and have no idea what they sound like). You trust this person, but you can't depend on an oral challenge-response. The existing PGP web should be handy here. Phil
Phil Karn says:
To me at least this seems unimportant for the application. If all you're doing is exchanging session keys over the phone, it doesn't really matter if you are sure that the public key actually belongs to who it claims it does,
Well...yes. *If* you know the person you are talking to, then you can read off your session key (or preferably its hash) to guard against the man in the middle. But let's say you are being referred to someone who you don't already know (or you know them only by email, and have no idea what they sound like). You trust this person, but you can't depend on an oral challenge-response. The existing PGP web should be handy here.
I think that we are too casual about this -- Rich Little or someone similar could easily impersonate your voice over a vocoder well enough that unless I decided to do a "so, tell me about what we had for lunch last week" routine you couldn't tell the difference. I think that even if you DO know the other person verification is valuable -- especially given the distortionary effects of vocoders. Perry
participants (5)
-
guy＠theporch.raider.net -
karn＠qualcomm.com -
paul＠poboy.b17c.ingr.com -
Perry E. Metzger -
thug＠phantom.com