• alex
  • Member
  • Offline
  • Registered: 2013-09-28
  • Posts: 2

Topic: iOS SSL/DTLS questions

Hello!

I'm sorry if those questions seem trivial, couldn't find a direct easy answer.
I'm planning on developing a cryptocommunications tools for iOS, and intend to use your library, as I've had no success using openssl or gnutls, and it looks simpler and easier.

However I'm left wondering about a few things, and I was hoping you may be able to shed some light.

It is my understanding that streaming communications (voice,video) should not use blocking, but non-blocking sockets.
Furthermore, I understand that only DTLS will work with non-blocking sockets (is that correct?).

What I am looking for, is a scenario, where 2 peers (introduced by a mediator/3rd agent) will exchange packets in a non-blocking fashion.
This is the important part for me:

Can client A, connect to client B, using a Client B's public key (for sending), whereas client B will be using his own private key to decrypt packets intended for him?
Vice versa, can client B, reply to client A, using client A's public key, and client A, decrypting using his private key?

I imagine this is a common scenario using RSA keys (gpg,pgp), but is this a scenario possible with DTLS?

Furthermore, can I, using yassl, generate those private & public keys on the actual iOS device, or should I rely on the mediator to generate those certificates?

If the above scenario is not possible, can you recommend any alternatives?

Looking forward for your answer,
Regards A.

Share

  • todd
  • Moderator
  • Offline
  • Registered: 2010-10-21
  • Posts: 98

Re: iOS SSL/DTLS questions

Hi A.,

Our SSL library CyaSSL can use non blocking sockets for for SSL, TLS, and DTLS.  If you're new to non blocking programming I suggest starting with TLS because tcp sockets are generally easier to use than udp which DTLS is run on.  Our examples can be run in non blocking mode with the -N argument, e.g.,

./examples/server/server -N
./examples/client/client -N

SSL/TLS/DTLS connections don't directly use the public/private key pairs for encrypting messages.  Instead, the public/private key pairs are used to create a master secret during the handshake process that is then run through a PRF to create the encryption keys.  If you wan to directly use the public/private key pairs for encryption you may need to build that functionality yourself.  Though it's much harder than it sounds to create a secure system and we always suggest using TLS version 1.2.  There are a million ways to create a less secure system than that and very few to make a better one.

A third party is typically used in TLS as a Certificate Authority (CA), the CA signs certificates which allows for trusted certificates that you've never seen before as long as you trust the CA.

Key generation / certificate generation and signing can be done on a mobile device though you're going to get more security by having a dedicated specialized service doing that for you.

I hope these suggestions help you along,
-Todd

Share

  • alex
  • Member
  • Offline
  • Registered: 2013-09-28
  • Posts: 2

Re: iOS SSL/DTLS questions

Hi Todd,

Thank you very much for your reply, very helpful.

Just to clarify, you suggest I just start with tcp/tls instead of udp/dtls?
Is there a reason, other than ease of use/development?

Regards,

Share

  • todd
  • Moderator
  • Offline
  • Registered: 2010-10-21
  • Posts: 98

Re: iOS SSL/DTLS questions

Hi,

No, ease of use and development are the primary reasons.  If you're new to SSL in general, non-blocking, and udp that may be an insurmountable combination.  Each one has a high learning curve.  I prefer to tackle new things one at a time.  So I'd probably do something like:

1) Get a blocking TCP client and server communicating with each other in "plain text"
2) Add TLS security to 1)
3) Add non-blocking support to 2)

And then, maybe

4) Get a blocking UDP client and server communicating with each other
5) Add DTLS to 4)
6) Add non-blocking support to 5)

But that's just my preference.

Good luck,
-Todd

Share