Google's self-certified hypocrisy

You have to admire Google sometimes. Sometimes they do the right thing. Sometimes.

Consider the company's recent decision to tighten up internal requirements for SSL/TLS certificates to conform with the Baseline Requirements of the CA/Browser Forum. SSL/TLS certificates are a crucial tool for making the Internet trustworthy.

The problem which led to this decision was the discovery that an unnamed certificate authority (OK, it's GoDaddy) was issuing certificates with a lifespan in excess of the maximum 60 months allowed by the Baseline Requirements. Why should certificates have a maximum life span? Excessive life spans allow certificates with policies which should have expired long time ago to continue functioning.

Cryptographic methods have a shelf life. After a time, security research and Moore's Law have a way of finding vulnerability in algorithms which were precious unbreakable. Perhaps the biggest such problem we have these days is the MD5 hash algorithm, although there are many ciphers as well which have lost trustworthiness over time.  This is why it's good that certificates have relatively brief lives, so that they can be assured access to the latest security tech.

So if these are valid concerns for SSL/TLS, why does Google laugh them off for Android code signing?

Google's policies for code signing of Android apps for distribution in the Google Play store mandates that the certificates for the signatures have very, very long validity periods:

If you plan to publish your application(s) on Google Play, the key you use to sign the application(s) must have a validity period ending after 22 October 2033. Google Play enforces this requirement to ensure that users can seamlessly upgrade applications when new versions are available.

At the time this policy was promulgated, I believe the date was 25 years in the future.

Google's stated security model for Android is that the code signature is used merely so that the company can tell which apps were written by the same developer. They are not designed to identify the issuer of the code, except to the degree that he is also the issuer of other code signed with the same keys. Google then goes on to add this little bit of disingenuousness:

The certificate does not need to be signed by a certificate authority: it is perfectly allowable, and typical, for Android applications to use self-signed certificates.

The implication in this statement that you can use a trusted certificate authority, but it's not necessary. Of course, if you get a certificate from a trusted CA, it will have to have a 20+ year term. Who's going to buy that? The really deep-discount CA's (Comodo, for example) have gotten a 5 year certificate down to several hundred dollars, meaning a 20 year cert would have to cost in the thousands. But the very idea of asserting a trust statement for an organization with a 20 year life is somewhat absurd, so no reputable CA would offer it.

I would argue that the identity features of code signing are worthwhile, and Google is mistaken, not just to make them optional, but impossible. Remember, that Google's effective insistence on self-signing facilitates impersonation, a potentially useful tool for those trying to induce users to install malicious apps.

But even if you accept that identity is overrated, you are still left with the reasons, stated above, for why SSL/TLS certificates with long validity periods are unwise: They lock in security policies which may, over time, become antiquated. Code signing is a high-value attack target to begin with.

The origin of this Google policy lies not in security, but in market imperatives. At the time Google created Android and opened it up to the world, the iPhone was firmly established and had major traction with app developers. Google needed to attract those developers and induce them to develop for the then-speculative Android. The number of apps available for the iPhone (then probably just in the tens of thousands) was a key marketing point. So, in order to make it as cheap and easy as possible to code for Android, Google eliminated the whole certificate management part of it. There is still a $25 registration fee for the developer program, so if you blow your reputation with Google you may need to pony up another $25 to start distributing malware again.

Google got their wish; developers have flocked to Android, even if many of them are not the right kind of people. And as a result, everyone knows that they only real action in mobile malware is on Android.

Apple, Microsoft and BlackBerry all use real code signing for their app stores. Why are up-to-date certificates, issued by trusted authorities which verify the identity of the customer, good enough for them, and for SSL/TLS sites, but not good enough for Android developers?