| Hi Jens-
Thanks for the feedback. My particular architecture could work fine with a centralized server handing out identities, but I'd like to wrestle with all options to make sure I understand things...
Let's say I've embedded a custom, self-signed root certificate in my app (just the cert, no private key). Could I create new, unique certificates in each instance of the app, rooted to the custom root, that are then used to secure the communications channels between instances of the app? If so, what would correct property settings be for the CFStreams to validate communication?
My goals are:
1. ... to be sure the other peer is an instance of my app, which would seem to be satisfied by the use of the custom root. 2. ... to avoid allow/deny warnings when connecting to other peers, which could (?) be achieved by registering the custom root (common to all instances) as trusted root at app launch. 3. ... to encrypt communication between peers, which is what the unique, created-in-app certificates would do.
As my emails have made clear, however, I'm not really solid yet on knowing what I'm doing :-)
If the above is possible, it seems I could still configure the CFStream to not allow expired certificates, not allow any root, and validate the certificate chain (finding the trusted custom root at the end). I would still ignore kCFStreamSSLPeerName, as names make no sense in this context. I would have no need to override the TLS chain validation.
This would have the benefit of being less work for the user, particularly if unique identities are required per app instance and a user owns 2 or 3 devices they would like to run the app on.
I appreciate any further insights you can offer!
John
On Dec 12, 2012, at 4:48 PM, Jens Alfke < email@hidden> wrote: On Dec 12, 2012, at 2:30 PM, John Pannell < email@hidden> wrote: Q: What do I embed in the app, and how do I package it? Do I put both the cert and the private key in a .p12 file and keep it in the app bundle?
Never embed a private key in an app. The app bundle is not private; it’s quite easy to poke around inside and extract files, even of iOS apps.
As Quinn said, every instance of the app has to have its own unique key-pair, so it has to be created a runtime.
In addition to the hybrid approach Quinn suggested (which isn’t fully P2P), you can also generate a key-pair in the app itself using the Security framework APIs, probably on the app's first launch. The private key will end up securely stored in the device Keychain where it’s not feasible to extract it. The issue then is establishing identity and trust, since another peer encountering the app’s cert for the first time will have no way to know who it is. (The advantage of Quinn’s approach is that you have a centralized server that the app can put trust in.)
—Jens
|