News

iPhone Application Key Hits the Web

Apple's secret key needed to install iPhone applications through iTunes doesn't appear to be so secret any more. Hackers have apparently uncovered the code used to properly sign applications as legit now it is circulating around the Web.

The iPhone application key is available on two sites so far. Zibri's Blog and austinheap.com are both showing the key, although neither is blatantly stating what the code is for.

With the code in hand, any developer should be able to create iPhone applications that iTunes and the iPhone see as Apple approved -- meaning they can, at least in theory, release apps that install without Apple's authorization.

Apple CEO Steve Jobs confirmed that the iPhone and iPod touch software developer kit would ship some time in February, offering coders a way to write native applications instead of only Web-based programs. Since the now publicly available application code will likely be a key part in the application installation process, Apple may change it when the SDK finally ships.

[Thanks to TUAW for the heads up.]

6 comments from the community.

You can post your own below.

+ show options

Your current settings, click to change: Sort Oldest First, Show Guest Posts, Hide Community Stats

DanielDecker said:

member since 15 Apr 2005 with 23 posts, unranked, send him a message or view his profile

WOW, I feel that it is highly irresponsible on the part iPO to link to the sites posting the code. Might as well have posted the code right in the article.

Where is the responsible journalism? I'm extremely disappointed in the TMO family.

Quote this post ↓

daemon said:

member since 17 May 2007 with 305 posts, unranked, send him a message or view his profile

And here I thought Apple was supposed to write secure software. If these work, any piece of code could have it embeded and the iphone would treat it like any other piece of good software. Poor security design Apple, poor design.

Quote this post ↓

jbruni said:

member since 14 Jul 2006 with 73 posts, unranked, send him a message or view his profile

Quote
daemon wrote:
And here I thought Apple was supposed to write secure software. If these work, any piece of code could have it embeded and the iphone would treat it like any other piece of good software. Poor security design Apple, poor design.

How would you have done it differently?

Quote this post ↓

daemon said:

member since 17 May 2007 with 305 posts, unranked, send him a message or view his profile

Quote
jbruni wrote:

How would you have done it differently?

An encrypted hash generated randomly that works only for that specific program that is being digitally signed by Apple, rather than a generic hash that works for all programs.

Quote this post ↓

jbruni said:

member since 14 Jul 2006 with 73 posts, unranked, send him a message or view his profile

Quote
daemon wrote:
Quote
jbruni wrote:

How would you have done it differently?

An encrypted hash generated randomly that works only for that specific program that is being digitally signed by Apple, rather than a generic hash that works for all programs.

Firstly, a hash is never "generated randomly". It is a mathematical output based on the function and the input. The output will always be predictable. If it's random, it's not a hash. Second, the hash need not be encrypted. If it were, then in order to decrypt the hash, the shared secret would need to reside on the iPhone (which is probably the case). The hash can be digitally signed, but the signature must be validated against a trusted object such as a certificate.

Normal code-signing certificates with a root certificate issued by Apple is one possibility. The vulnerability here is should someone install root certificates not issued by Apple, you'd still end up with non-trusted code running on the iPhone.

This chicken-and-egg problem is the same one that Apple must deal with in iTunes. At some point, you must fall back on a shared secret. The best you can do is try to hide that secret.

Quote this post ↓

A guest said: (hide)

No, you definitely want to go with PKI. You want to use public/private keys, not shared keys. daemon might not know the right terminology, but he's on the right track. The shared approach is simply won't scale; it's useful if you have just one software provider, but then what is the point of an SDK? All code signing approaches can be defeated, but PKI is how you allow many distinct entities to sign code for a single open system. If you are going to run a closed system, then shared key is fine, but for an open system, PKI is the way to go.

Quote this post ↓

Post Your Comments

  Remember Me

Not a member? Register now. You can post comments without logging in, but they'll show up as a "guest" post.


Please enter the word exactly as you see it in the image above. Registered users aren't prompted for this. Having trouble reading the image get a new one.