Do you know where your software comes from? Gatekeeper will help

Mountain LionYou trust us to provide you tools that keeps some of your very valuable secrets safe. Part of that trust means that, when you install or update 1Password or Knox, you know the app you are getting comes from us. After all, if a bad guy produces a modified version of 1Password, it could do bad things. So far there have been no such modified versions “out there” and we want to keep it that way. In addition to all of the things that we do to ensure that you get the genuine article, Apple is working to make it even easier to keep your Mac free of malicious software.

Apple has just announced that Mountain Lion (to be released in the summer of 2012) will include something called Gatekeeper. This is a core OS X feature that I and others have been anticipating for a while. (surprisingly, almost all of its components are actually built into the latest version of Lion). Roughly speaking, Gatekeeper will allow you to control which apps to run depending on where the software comes from.

The question then is: how does your Mac know where your software comes from?

The Magic of Digital Signatures

I would love nothing more than to explain the mathematics behind digital signatures. But for today’s purposes, let’s just say it is magic (even when you know the math, it feels like magic). When you connect over HTTPS to a secure website, that website proves who it is because it knows a particular secret (called a “private key” or “secret key”). The corresponding “public key” is not kept secret.

The magic is that the website doesn’t have to reveal the secret to prove that it knows it.


Evilgrade Interface

Instead your computer system can use the non-secret public key to construct a mathematical puzzle that only someone who knows the secret key can solve; anyone with the public key can check that the solution to the puzzle is correct, but they can’t figure out what the secret key is. This can prevent someone hijacking the download process with a tool like evilgrade.

In the same way that a secure website can prove who it is without revealing any secrets, a digital signature on a file (or a group of files) can prove who made it. If someone makes even the smallest change to the signed file, the signature won’t verify.

Three Kinds of Apps

Applications that you install through the Mac App Store (MAS) are all digitally signed this way. But for years, Apple has been encouraging developers to digitally sign applications even if they aren’t sold through the MAS. So on your Mac today there are probably three kinds of applications:

  1. Those that came from the MAS
  2. Signed applications that did not come through the MAS
  3. Applications that aren’t signed

Gatekeeper will allow you to decide which of these categories of applications may run on your machine.

If you are running 1Password 3.9, then that came signed through the MAS. But if you are running 1Password 3.8 or Knox 2 from our website, they are still signed by us and will fall into the second category.

Verifying a signature today

When you install an application from the Mac App Store, the installation process checks the signature. It won’t install the app if it isn’t signed or if the signature doesn’t verify (which is more likely to happen through a damaged download than through a malicious attack, but both can happen). When you update the non-MAS version of 1Password, our updater runs a code signing signature verification as one of the three checks we use to ensure that you are getting the genuine 1Password from us. For those who are curious, our other two verification mechanisms are (1) fetching from a secure web server and verifying the server signature, and (2) checking a cryptographic checksum for the download which we fetch from a separate secure server.

But suppose you wanted to check the version of 1Password that you currently are running. All of those behind-the-scenes checks on the download and installation processes won’t help you do that. Well, the way to check now is hard, which involves running a complicated command in a Terminal window. Here it is for the non-MAS version of 1Password

codesign -vvv -R="identifier ws.agile and anchor trusted" \

The output should be something like

/Applications/ valid on disk
/Applications/ satisfies its Designated Requirement
/Applications/ explicit requirement satisfied

Clearly we don’t expect users to run these sorts of commands.

codesign in Terminal

We have been using Apple’s code signing mechanism for years because we wanted to be able to direct concerned users to this kind of command if they specifically ask. We’ve also been using it for additional security in our own updater. But another reason that we’ve been doing this for a while is because we’ve been anticipating either Gatekeeper or something similar.

Verifying a signature tomorrow

Gatekeeper will perform the codesign verification when an application is launched. This adds a great level of additional security beyond verifying the download source when the application is downloaded and installed.

A mathematically valid signature is the easy part

Apple Developer IDThe mathematics (the magic) makes all of the above simple. The hard part of Gatekeeper is the trustworthiness of the signatures. I can sit at a my computer and create a public/private key pair that says that it belongs to Alan Turing. Since Turing has been dead for more than half a century, few people would think that it actually belongs to that great mathematician and codebreaker. But what if I picked the name of a trusted person or institution that is around today?

The answer is that some trusted third party digitally signs my public key after verifying it belongs to who it says it belongs to. I’ve discussed how this system works (and how it can break down) when it comes to web server certificates, so I won’t repeat that here; the concepts are all the same. In the case of codesigning certificates for Mac developers, Apple does that checking and signing.

We changed our name a while back, so at some point before Gatekeeper is in common use, we will have to update our codesigning certificate identifier from “ws.agile” to “com.agilebits”. But for the time being, when you see “ws.agile” as the entity behind the digital signature on 1Password and Knox, you should know that that is us.

Other than getting a new certificate with our new name, we have been ready and waiting for years to get on board with the new security provided by Gatekeeper.

[Update: As of 1Password 3.8.19 Beta 1, 1Password is now signed with our new Apple Developer ID, AgileBits Inc.]

Other posts in this series

  1. Guess why we're moving to 256-bit AES keys (March 9, 2013)
  2. Authenticated Encryption and how not to get caught chasing a coyote (January 18, 2013)
  3. Doing the two-step until the end of time (December 20, 2012)
  4. Alan Turing's contribution can't be computed (December 8, 2012)
  5. Hashing fast and slow: GPUs and 1Password (December 5, 2012)
  6. Credit card numbers, checksums, and hashes. The story of a robocall scam (October 18, 2012)
  7. Flames and collisions (June 7, 2012)
  8. A salt-free diet is bad for your security (June 6, 2012)
  9. Cipher of Advanced Encryption Substitution And Rotation (April 1, 2012)
  10. Do you know where your software comes from? Gatekeeper will help (March 1, 2012)
  11. AES Encryption isn't Cracked (August 18, 2011)
5 replies
    • Jeff
      Jeff says:

      That is a great post you linked to! I would definitely encourage people to read that.

      Certainly publishing a hash of the certificate is useful, but note that in the codesign example I used one of the requirements was “anchor trusted”. That is, our current, ws.agile, certificate is signed by a Thawte codesigning Certificate Authority, which in turn is signed by Thawte’s server CA. That Certificate Authority is trusted by the system. IF someone created their own “ws.agile” certificate at signed something with it, it would not pass the test.

      Once we start getting our Apple Developer IDs, those will be signed by Apple, whose certificate will be trusted by the system. But you are absolutely correct that without having the code signing certificates anchored, these provide little authentication.



  1. Rainer Brockerhoff
    Rainer Brockerhoff says:

    Right, I forgot to consider the “anchor trusted” part, which wouldn’t work with a self-signed certificate (as I was using).

    I didn’t really look into how this would work with authorities like Thawte. What if someone buys a “ws.agile” certificate from some other trusted authority? That, also, would pass your test.

    • Jeff
      Jeff says:


      If the “trusted” certificate authorities are doing their jobs properly then no one other than us should be able to get an anchored certificate for “ws.agile”.

      Of course with so many CAs out there, it only takes a compromise of one of them for damage to occur. The DigiNotar case was a good reminder of that. And that also brought to light a bug in OS X’s handling of chains of trust. (Now fixed in 10.7.3) That was a great deal of discussion of these issues in the comments to this post:

      So I do see the value of your suggestion, publishing the hash of the certificate. The MD5 fingerprint of our Thawte signed codesigning certificate is CA 02 F6 3A CE 29 CF D0 C5 28 7F 13 57 5D 5A 55. But we will be getting a new Apple Developer ID “any day now.” I’m not entirely sure how users can tease that out of the codesign command.

      As we both explain in our blog posts, this kind of verification, given the current tools (the codesign command line) is not anything that anyone can expect from users. It’s part of an infrastructure for something meaningful for users. You correctly point out that all of the pieces are pretty much all there in 10.7.3, and it just needs to get turned on.



  2. Rainer Brockerhoff
    Rainer Brockerhoff says:

    So they do cross-check names, I didn’t know that… but it sounds fragile. I agree that we need better verification and I’m about to release a free utility to help with displaying code signatures and trust chains – email me privately if you guys would like to see a beta.

    I also encourage developers to actively check for the expected signatures in their application code – on the Mac App Store, you already have to check receipts, anyway.

Comments are closed.