Open Radar

 
The below has been slightly edited from my private Apple report.

Secret Transmission to iOS apps.

As you know, all modern secure communications depend upon secrets in one form or another. I would like to bundle a secret with my iOS binary application to secure my app <-> server communication. (While I believe the keychain is the natural vehicle for this secret, I'm sure there are many solutions to this problem.)

Motivating requirements.

OAuth:

In OAuth, there are two tokens and two shared secrets involved with every REST message. In the xAuth variant used by Twitter for client apps, such as those that run on iOS devices, one of those tokens and its secret must be bundled with the app. This is the consumer token and secret pair. Every xAuth client app must apply for this unique pair from Twitter. These requirements are documented at: <http://dev.twitter.com/pages/auth>.

Currently, I persistently store all user credentials in the iOS keychain. I cannot do so with the OAuth consumer secret. It currently is compiled into my app as a static string. (While I've shredded the string into binary constants which I sprinkle throughout my code, we all know that  "security through obscurity" is a relatively ineffective security strategy. There is plenty of evidence that iOS apps are broken and made available on pirate software web sites. IOW, I cannot keep this secret from being visible to casual static analysis. I believe precluding this behavior and weakness is Apple's responsibility.)

TLS/SSL:

While I am far from a security expert, I am told by folks in the financial iOS app development community that TLS/SSL is susceptible to man-in-middle attacks and that they see these attacks. In particular, the attacks are frequently enabled at governmental boundaries/firewalls. There is a simple, I am told, defense. Which is to use a custom certificate on both ends of the TLS/SSL negotiation. This is a shared secret that must be transmitted with the app. 

One solution to this problem is to go retrieve the secret from a well-known URL. I believe this is the current Apple recommendation. Since the attack originates from governmental firewalls, it does not protect my app when it is launched from the other side of the firewall. This solution just requires one extra level of man-in-the-middle attacks.

A Proposed Good Solution for an App Developer:

As iOS 4 now supports a form of keychain mobility, I am hoping that this infrastructure can be used to somehow enable a developer's ability to transmit a custom keychain item based on an app's provisioning profile. I am sure there are other solutions. Because I currently store sensitive login credentials from from my user in the keychain, it would be a natural solution for my app to retrieve the transmitted secret credentials from the keychain.

Summary:

I believe this is a real problem. The levels of fraud experienced, I am told, by the financial services industry is real.



24-Jun-2010 08:06 AM Andrew Donoho:
Another use for secret transmission to an iPhone:

For Push notifications, Urban Airship, a push notification hosting service, says at this link: <http://urbanairship.com/docs/push_index.html#concepts>.

"Allow Push From Device

For security reasons, we strongly recommend not including the Master Secret in your application. However, it can be useful to send push notifcations from the device - for instance, to schedule notifications in the future for that particular user. In the administrative interface for your application, there is an option to allow push from the device. If this is enabled, we will allow push messages to be sent using the application key and secret. "