Google's self-certified hypocrisy

Google's self-certified hypocrisy

Summary: Google's policies for accepting SSL certificates from web sites in Chrome are getting smarter and more restrictive. Their code signing certificate policies for Android started out lax and stupid and will stay that way.

SHARE:
TOPICS: Security, Android, iOS
12

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? 

Topics: Security, Android, iOS

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

12 comments
Log in or register to join the discussion
  • Slow Day Huh?

    I challenge you to prove that "the only real action in mobile malware is on Android."

    I've yet to hear of even 1 person, not using illicit file downloading sites, having their Android phone infected with any form of virus/malware.

    I constantly hear virus/malware solution vendors beating this drum though and 1 has to wonder why, if it's so much of a problem, no one outside the labs seems to be having problems with their phone.
    cj100570@...
    • And you know this how?

      I'll put aside for the moment that you probably know only a small percentage of Android users. Why should it make a difference if a user visits an illicit file downloading site? Don't iPhone users go to those sites too?
      larry@...
      • "small percentage"

        >>l'l put aside for the moment that you probably know only a small percentage of Android users.

        Larry, with all due respect, my acquaintances using Windows constitute also a very small percentage. However, ... I think, I don't know anyone who ... would NOT have bitten a virus or a trojan at least once for the last few years. This includes even myself long time ago (Win 95, if I remember correctly).
        As far as all this "Android malware menace" is concerned, we usually hear about myriads of malware that are there, available for users to download and install despite all permissions warning. What lacks is the actual number of users that had installed them. Should the latter number be computed as the percentage out of the total Android population, a more realistic estimate of the risk for an average Android user would be revealed. Guess how much lower it will be when compared with an another popular OS (produced in Redmond)?
        eulampius
        • s/bitten a virus/bitten by a virus/

          they might have tried to bite those viruses too :)
          eulampius
      • Um, NO

        iPhone users do NOT go to those sites. Unless they jailbreak their iPhone, the only place to get software for the iPhone (and iPad) is the iTunes Store.

        Android has the ability to turn that off. It is NEVER advisable to do that, but some do anyway. Then it becomes as vulnerable as Windows because who knows if the software you obtain from some website is actually not infected?
        benched42
    • Challenge Accepted

      http://www.tuaw.com/2013/08/26/u-s-government-finds-0-7-of-all-mobile-malware-affects-ios-wh/

      Your anecdotes are meaningless.
      His_Shadow
  • Android was designed by and is maintained by brain dead filth...

    There isn't a single aspect of the "platform" that isn't pathetic.
    jackbond
  • Why ShouId I Need To Provide ID To Publish Code?

    I'm an Android developer. I have a handful of apps on the Play Store. What good does it do the users if I am forced to use a CA-issued certificate instead of a self-signed one? It's not as though the users know who I am anyway.
    ldo17
    • CA v. Self-Signed Certificates

      @ildo17: The difference is that a self-signed cert can be very easily created with any information the creator would like it to convey. A CA signed cert is vetted by the CA. The RA process provides for the background checks and other tests to prove the signed is in fact who they say they are. The whole idea of a CA is just that - we all trust that the CA will go through due diligence prior to fulfilling the certificate request. It's this process that indeed does let the end users "know who you are anyway".
      CraigJ
      • Re: The difference is that a self-signed cert

        I know what the difference is. What I asked was: what good does it do?
        ldo17
  • Why doesn't Google become the Play Store CA?

    If Google wants long term CA signed certificates, it should become a CA and sign these requests itself. As stated, a 25+ year code signing certificate is very expensive, especially for small or one-man development houses. Let Google define its terms, but it should be up to them to verify the source of the code they allow on their app store. They could then control the costs of developing apps for android and chrome.
    CraigJ
    • Re: If Google wants long term CA signed certificates

      It doesn't.
      ldo17