Zeroing in where security hinges

Leave Verisign out of it!

I keep reading misinterpretations about the previous blog entry and see Verisign buried under a ton of drivel. Just to make things clear:

  • Verisign distributes test certificates for people to try out their service. These certificates are limited to 60 days, delivered without any kind of verification, and clearly labeled as such. People use them mostly to validate that PKI-enabled software like browsers or mail clients can handle them fine.
  • These certificates come with all bells and whistles. If you read the fine print, it is clearly indicated that these are intended for test purposes only.
  • Many other certificate authorities offer the same kind of service for users to test. The same proof-of-concept could have been realized with any other certificate provider offering test tools, as long as they relate to a root CA trusted by iPhones.

You do not have to believe me: browse any certificate provider web site and look for test certificate generation.

The WTF lies in the fact that an iPhone would accept this kind of toy certificate as a token of proof to authenticate a remote configuration received over the air.

Hope that clarifies things a bit.


Written by cryptopath

2010-February-4 at 14:10

Posted in crypto, iphone

Tagged with

2 Responses

Subscribe to comments with RSS.

  1. Perhaps the confusion came from your specific example of a fake “Security Update” issued by “Apple Computer”.

    I’m still wrapping my head around some of the details you’ve provided, but the outline seems to be that anyone can fake a mobileconfig. That certainly enables MitM attacks. That you can present a system security update in this manner, though, is of greater concern to me. So I see two issues:

    1. Solve the core problem of validating “real” certificates
    2. Solve the impersonating-Apple-itself problem

    Is #2 impossible to solve without doing #1?

    At first I thought Apple could short-term fix #2 by only accepting certs issued by “Apple Computer” or “Apple, Inc.” if the IP address/range of the provisioning server matches an internal list of those owned by Apple itself.

    Now, though, I’m thinking any enterprising hacker can just create spelling variations of “Apple Computer” as an issuer name, or even the title of the mobileconfig itself, and fool a large enough percentage of the public.

    Is that on the mark?


    2010-February-4 at 17:12

    • I do not think Apple should be the only entity who has a right to send you over-the-air configuration files. Your IT security will want that functionality too. Working this out in a secure way is definitely not an easy task.

      The trick in the given example is to 1. fool the iPhone into showing green lights for a certificate that should not be trusted and 2. fool the user by showing a familiar name, be it Apple or your company.

      One easy way out is to restrict the list of root CAs in the iPhone to higher-grade certificates that require some sort of verification from the issuers. At least you make it very hard for somebody to present a certificate identified as “Apple” or whoever you are not. Still does not solve it completely: a signed mobileconfig from company A can be applied to your iPhone and set to be non-removable. At least you will know who screwed your config.


      2010-February-4 at 17:40

Comments are closed.

%d bloggers like this: