4

I need to establish a HTTPS 2-way SSL connection from my iPhone application to the customer's server. However I don't see any secure way to deliver the client side certificates to the application (it's an e-banking app, so security is really an issue). From what I have found so far the only way that the app would be able to access the certificate is to provide it pre-bundeled with the application itself, or expose an URL from which it could be fetched (IPhone app with SSL client certs).

The thing is that neither of this two ways prevent some third party to get the certificate, which if accepted as a risk eliminates the need for 2-way SSL (since anyone can have the client certificate).

The whole security protocol should look like this:
- HTTPS 2-way SSL to authenticate the application
- OTP (token) based user registration (client side key pair generated at this step)
- SOAP / WSS XML-Signature (requests signed by the keys generated earlier)

Any idea on how to establish the first layer of security (HTTPS) ?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
pmilosev
  • 932
  • 8
  • 20
  • Are you being asked to do 2-factor authentication or 2-way SSL :p Two different things. 2-way SSL is nice in theory, but a mess to setup the certificate stores on both sides and exchange certs. – Keith Adler May 05 '10 at 19:12
  • Don't forget that if your app is actually useful to your customers, the certs will expire at some point. So don't think that initial setup is the end of this problem. You may have to add CSR generation to your app and have your IT guys provision these things (would hand inspect the thumprint on the CSR and on the original cert in the app UI before issuing the response be Good Enough for your purposes?). – Jason May 05 '10 at 20:40
  • I guess it is 2way SSL. What I need is to establish HTTPS connection to the server by confirming (via a certificate) that the client is really my application. What we plan is to have one certificate for all users, so there is no need of certificate per user management as this is done on a higher level then http. At the moment we are considering of bundling an encrypted certificate with the application and having the decryption key somewhere in the byte code. This is not a top level security but should be enough for this layer. Any idea on how to better protect the decryption key ? – pmilosev May 06 '10 at 14:37
  • The issue with building the first key into your application is that it's 'easy' to break your system. Bruce Schneier is a good starting point for better methods of initial security. – KevinDTimm May 06 '10 at 15:47
  • i'm going to blow the dust off this question. How did you get with this solution ? – Mike Jun 22 '16 at 08:43

2 Answers2

2

Ok, so to answer my own question...

It turned out that the security has no fixed scale of measurement. The security requirements are satisfied as long as the price for braking the system is significantly above the prize that one would get for doing so.

In my situation we are talking about e-banking system, but with somewhat low monthly limits (couple of thousands USD). As I mentioned in my question there would be another layer of security above the HTTPS which will feature WSS XML-Signatures. The process of registering the user and accepting the his public key is also done in several steps. In the first step the user sends his telephone number together with a cod retrieved somehow from my client. Then an SMS is sent to the user with a confirmation code. The user enters the confirmation code into a OTP calculator that would produce OTP code which will identify the user. Then the public key is sent to the server together with the OTP code. From here on every request would be signed by the private counterpart of the public key sent to the server earlier.

So the biggest weakness for the whole process is that of someone reverse engineers the application and retrieves the client certificate used for the SLL. The only problem arising from this is that someone might observe users' transactions. However in order for someone to make a transaction he would need the user's private key, which is generated, encrypted and stored into the keychain. And the price for braking this security level is VERY HIGH.

We will additionally think on how to protect the users' data on a higher level (e.g. using WSS Encryption), but for the start I thing we are good with the current solution.

any opinion ?

regards

pmilosev
  • 932
  • 8
  • 20
-2

https doesn't really work this way. In a nutshell, you attach to a secure server where the certificates are signed by a well known authority.

If you use Apples (iPhone) classes for this, they will only accept 'good' certificates. By good, I mean what Apple deems as acceptable. If you don't use them (there are alternatives in the SDK), you won't be able to connect (except, maybe, in the case where you have an 'Enterprise' developers license - but I can't say that with 100% certainty as I haven't looked enough at this license to be sure)

To continue, use your https connection to your correctly signed website and then institute some sort of login with a built in username/password, or challenge/response based upon the unique ID of the iPhone (for example) and exchange keys using that connection.

Note that this means that your application will have to query for new certificates at (each connection/every X connections/every month/application specified intervals) to keep them up to date. You can then use these certificates to connect to the more secure server.

[edit]

Check this post - may have more information about what you're asking to do

[/edit]

[edit2]

Please note that the request is iphone, not OSX - app store approval is an issue

[/edit2]

Community
  • 1
  • 1
KevinDTimm
  • 14,226
  • 3
  • 42
  • 60
  • I think you're missing a concept from your toolbox: Mutual Authentication. That's what the OP is asking about. – Jason May 05 '10 at 20:41
  • @Jason he doesn't believe client auth its possible with ssl, that's why I gave him a -1 – rook May 05 '10 at 20:46
  • So there's "Can't do client auth" and then there's "Can't do client auth *with this library*". I can't speak to the iPhone library, since I'm a total noob, but there ARE libraries my teammates have had to swap out because they couldn't get client auth to work or there just weren't enough configuration parameters to make it non-braindead. – Jason May 05 '10 at 20:52
  • In my usage of the library, the library requires that the cert be 'good'. Apple 'good'. So, a cert that you prepare and then share between the client and server will not be allowed. The only way to do this is to use classes that are specifically disallowed by Apple - classes that will stop your application from getting approval. – KevinDTimm May 06 '10 at 02:01
  • @Rook - client auth isn't possible with iphone, at least, not in the way that you would like him to do it. – KevinDTimm May 06 '10 at 02:04
  • "https doesn't really work this way. " is a misnomer and that is probably why you have a -2. – rook May 06 '10 at 02:16
  • gotcha. you're absolutely right, I skimmed that each time I read the post and didn't see the failure. Thank you. – KevinDTimm May 06 '10 at 11:36
  • Just to cut off the fight :D We have still not discussed this with my client but I am almost sure the CERT would be a valid one signed by a well known authority. I was only interested on how to deliver this certificate securely to the app. – pmilosev May 06 '10 at 14:47
  • Not a fight, I learn more being wrong more than I like being right ;) That said, if you use the challenge/response that I mention in my 4th edit, I think you'll be fine (note too that I would suggest checking for new certificates every time - time based stuff always fails) – KevinDTimm May 06 '10 at 15:44