Re: Security with Streams
Re: Security with Streams
- Subject: Re: Security with Streams
- From: Keary Suska <email@hidden>
- Date: Sun, 26 Jun 2016 08:59:59 -0600
> On Jun 25, 2016, at 8:44 PM, Gerriet M. Denkmann <email@hidden> wrote:
>
> Following TN2326 I created a (self signed) Certificate Authority and a Digital Identity called "MyServerId".
>
<snip>
>> We are now falling into the rabbit hole that is peer-to-peer trust & identity. How is your server going to identify it so that a client will know that it’s the server it expects? I don’t know whether you’ve given any thought to this; the answer affects how you’d implement this part of the app.
>
> I have thought about this, but I am not at all sure that my thoughts are correct.
> Currently (as indicated in the code above) my client has a copy of the real server certificate and compares it with the certificate obtained from its inputStream.
> I am not sure whether putting the server certificate into the client is ok or a breach of security.
>
> That is: the client will accept any server which has signed with the server certificate.
Self-signed certificates can only offer encryption, but cannot offer trust because they are not verifiable. You can’t use the server certificate as a key since you pass that key out to anyone who wants it (in your app), and anyone who gets it can impersonate the server.
I am unclear to me whether you are after a client-server (i.e. all servers are under your control) or peer-to-peer (i.e. every client is a server and every server is a client)) model? With the former everything you need other than client verification is inherent in the SSL/TLS protocol (if you use managed and verifiable certificates). With the latter, SSL/TLS will not likely serve you as to do it correctly will likely be cost prohibitive (unless you can pass that cost to the consumer in some way).
That being said, in a peer-to-peer model I would (OTOH) use a public key/private key setup, where public keys are swapped and maintained in a trust database once a “trust” connection has been made. Pairing a bluetooth keyboard is a simple example of how to establish an initial “trust” connection. The benefit here is that by encrypting messages with a user’s public key, only the designated user can decrypt it, so you get both internal and external security. If a customer asks, “how do I know I am talking to whom I think?” You say, “It doesn’t matter, because what they get will not be decipherable unless they are who they say they are.” This can be followed up with the fact that all electronic communications are intercept-able, so the approach is to make the information as undecipherable as possible since there is no way to prevent interception.
HTH,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden