Exchanging Public Keys

Question

The Apple documentation on certificates and keys says that public keys can be sent to other users. This is of course their whole point. Without going into a sidetrack about man in the middle attacks, I'd like to know how this is supposed to work.

I use base64 encoding to send public keys in email between devices. Upon arrival, they don't work, and the receiving app throws exceptions when I try to use them. The base64 code and the key generation and retrieval code have both been tested exhaustively in another app and they work. Here is the problem in a nutshell:

(1) all the key API use SecKeyRef keys.

(2) a SecKeyRef obviously contains pointers, it comes out with different bits at certain offsets every time I retrieve the keypair from the keychain

(3) if I retrieve the key as a CFDataRef, which is supposed to be "flat," I get a markedly different beast, always with the same values, and a lot of zero padding (capital A in base64).

(4) an imported CFDataRef doesn't work

I don't ask this without doing a lot of research, reading, and testing and I concede I'm stumped, does anyone know how to exchange public keys? I've written Windows apps for years that do this. A certificate chain is a very large hammer for what I need to do here.

Thanks.

Answer 1

This seems like a confused question. Are you asking about how public key exchange works, or about why you can't transfer an in-memory object to another machine without it's pointers breaking.

The answer to the first question is that you just transmit the public key - it's a series of bytes that are usually hex or base64 encoded or wrapped up inside an X509 (ASN1) certificate. The public key itself tells the other user enough information that they can encrypt any bytestream into something that can be decrypted by someone holding the private key. Consequently transmission of a public key can take place in plain-sight.

The only security weakness of public key cryptography is if an attacker can man-in-the-middle the public key transmission and the cipher text. If A wishes to trasmit to B and M can see and modify all traffic between the two, then M can simply pretend to be B, securely connect to A and can then decrypt what A is trying to send to B. By symmetry he can do the same to B, and thus the two-way channel is broken.

SSL defeats this theoretical attack by using chain-of-trust verification, which ensures that M cannot pretend to be B, even if B isn't known to A because B can prove his identity by reliance on some shared third party (the CA). This is the reason why recent attacks on Diginotar and Comodo were so serious. The encryption was secure, but the identity verification was not.

So in short, the answer is you just transmit the keys. Public keys do not need to be securely transmitted for them to work, however if you don't have some kind of pre-shared secret or some kind of chain-of-trust then you're leaving yourself open to man-in-the-middle decryption attacks.