Ah, nice presentation. Indeed, the entire security model is generally completely misunderstood.
And, as he points out, the CAs don't really do a very good job. I still think, given our present situation, it's an important deterrent, but CAs have issued "Microsoft" certs to non-Microsoft people, along with many other such violations -- and those are just the ones that were caught. If a CA does a bad job -- can you reject certs from that CA? No, that would render a good chunk of the internet unavailable to you. But you can be your own CA. That's the alternative to using a self-signed cert -- a cert you signed with your CA cert. Each developer is his own CA. When you sign your app, you do so with a second-level or third-level cert under your CA, with short expiration, and timestamp (so the signature doesn't expire when the cert does). Your identity as a publisher of two apps is established by comparing the root cert. Two apps having shared permissions is established by sharing the same non-root-level cert (the signing cert or its non-CA parent). This establishes basic identity for the security model. Then, we use counter-signatures for two purposes: 1) To replace a cert with a new, unexpired one, the new cert must be signed by the same original CA cert's private key, and countersigned by the private key of the cert being replaced. (I'm only solving expiration here, not loss or compromise of certs). 2) To establish your physical identity, counter-sign your CA cert with the private key for a public signing cert from a trusted CA. (Obviously, this only works as well as trusted CAs work - but I argue it would have prevented most, if not all, of the impersonations we've seen in the Android Market to date). These counter-signatures would be included in the .apk's metadata. Also included would need to be the entire certificate chain -- INCLUDING what root CA was being trusted. (It drives me nuts that Java's idea of a CertPath specifically *excludes* the trust anchor! Yes, I know what to do about it -- search the trust store -- but it's still nuts). And all signatures -- including counter-signatures -- should be timestamped -- otherwise cert validity dates are useless (or evil, depending on whether you choose false negatives or false positives). Perhaps even require the TSA be a specific set of Google-sponsored TSAs. Thanks for clarifying what comparison you use. Binary comparison of the public cert as a binary blob is just as I hoped. (I find code all over the place comparing DNs! Or MD5 hashes of the certs themselves, which, while better, is no more secure than MD5). Comparing just the public key does have the advantage of allowing you to replace a cert with a new cert with different metadata (such as expiration date), but that's not the best way to achieve that. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
