re: Secure voice software issues

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-----

>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

> 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.

>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