A peek behind the Gatekeeper
1Password 3.8.19 for Mac is now available and it contains a number of improvements, and I’d like to provide a brief run down of those before getting into the meat of this article.
- When making its backups, 1Password now performs some extra sanity checks on the data before backing up. This way, if your data is damaged, you won’t end up with lots of backups that are also damaged.
- The same improvements that went into 1Password 3.9.5 (the version from the Mac App Store) are in 3.8.19 and will keep 1Password ahead of the curve as new browser versions are released.
- Delaying when our Updater runs its check so that it doesn’t get in your way when you first launch 1Password.
- A number of bug fixes, mostly improving the Conflict Resolver.
- And the topic of this article, 1Password 3.8.19 fully qualifies as from an “identified developer” for the purposes of working with Gatekeeper in the forthcoming version of OS X, Mountain Lion.
Let me remind you that 1Password 3.8.X is the version from our own store that you can download from our website, and 1Password 3.9.X is the version from the Mac App Store. We are actively developing both, but the releases of updates to each of these may not always happen at the same time.
Mountain Lion ready
With 1Password 3.8.19, we have completed the final step in making 1Password for Mac completely ready for Apple’s upcoming version of OS X, Mountain Lion (1Password 3.9, from the Mac App Store, has been ready for a while). This involved codesigning 1Password.app with our new Apple Developer ID so that it will be treated as a signed application by Gatekeeper, one of Mountain Lion’s key new security features. We’ve mentioned this before in an earlier post: Do you know where your software comes from? Gatekeeper will help, but I thought it would be fun to provide more detail now that this is ready in 1Password 3.8.19 for our website customers.
What does Gatekeeper do
Gatekeeper gives you more control over what software runs on your Mac. With Gatekeeper, Apple is now drawing lines between three different kinds of software, depending on where it comes from. There are apps that you install from the Mac App Store, apps that comes from “identified Mac Developers”, and then there’s everything else.
Gatekeeper gives you the power to disallow apps from sources other than the Mac App Store. You may restrict your Mac to run only apps from the Mac App Store, or you can also include software that comes from identified developers. You can also stick with the way things have always worked and allow apps to be installed from “Anywhere.” Apple’s goal with Gatekeeper is to offer a layer of protection, built into the core of the operating system, that helps you make sure the software you are running hasn’t been tampered with, and that it comes from trusted sources.
1Password 3.9 already comes from the Mac App Store, so it will run even under the most restrictive Gatekeeper setting. As of 1Password 3.8.19 released yesterday, 1Password 3.8 verifies as coming from an “identified developer,” Gatekeeper’s second option.
“How does my Mac know where my software comes from?”
The remainder of this article is about answering the question “so how does my Mac really know that an app comes from a trusted developer?” I find the answer to that question fascinating, but it isn’t simple. There is no shame in just accepting that it is all part of the magic of cryptography. But if you’d like to know a bit more about that magic, read on.
Exploration
Before I actually explain how the system works, you may wish to poke around at what is involved. Until recently, examining the developer ID for an application involved working through obscure combinations of the codesign command in a Terminal window while also hunting down files inside of bundles. Fortunately, Rainer Brockerhoff has developed a nice free utility, RB App Checker Lite, which makes it much easier to see what certificates and certificate authorities are involved in the signing of your apps. Let’s see what happens when you ask it to take a look at 1Password 3.8.19.
In the red box in the screenshot above, we see “The code and signature validate correctly”. This is telling us that 1Password.app matches the signature. If some crucial part of the 1Password.app had been changed, then the code (the files that make up 1Password.app) and the digital signature would not match.
The part in the green box is what tells you that it really is Agilebits Inc. (that’s us) who created the signature. You can click on the white arrows to see details of each certificate involved, but most useful is to click on the arrow in the blue box. That will show the certificate chain.
Again, you can explore details of the certificate chain. You will see that the certificate that signed 1Password.app says that it belongs to Agilebits. The AgileBits certificate was certified by Apple’s Developer ID Certificate Authority, which in turn was certified by Apple’s Root Certificate Authority. That Apple Root CA is trusted by your operating system.
Secrets and Files
I’ve been tossing around terms like “digital signature”, “codesigning”, “certificate”, and “certificate authority”. Now I’ll get around to explaining what those mean. All of these technical terms are so intertwined with each other that there is no good place to start, but I’ll start with the notion of a digital signature.
Let’s say you have a garden variety, everyday computer file. It’s possible to create a digital signature for it. To do that, you need (among other things) a secret key. The digital signature will be some special cryptographic output that depends on both the contents of the file and your secret key. What makes digital signatures work is that there is another key, called your public key, which is mathematically related to your secret key. Someone trying to verify the digital signature can do so by checking your public key along with the file that you’ve signed. If the signature verifies, it means that the signature could only have been created by someone who knows the secret key.
Because the signature also depends on the contents of the file, we know that the signed file must be identical in every bit to what was originally signed. If the file has been modified, the signature won’t verify. And only someone who knows the secret key can create a signature.
Codesigning is just the specific way of producing a digital signature for a software bundle. An application like 1Password.app is not a single file, but actually a collection of many files. Apple’s codesigning mechanism allows for a single digital signature to work as a signature for a collection of files. The signature itself may include some additional requirements that the developer wants to have checked when the signature is verified, and there are other things that are part of a code signature. But for what follows, you may just think of it as a way of signing all the crucial portions of the application, even if they are spread out among several files.
About the math
As I said there is a special mathematical relationship between the secret key and the public key that allows this to happen. One requirement of the system is that someone who has access to a public key, a signature, and the signed data cannot figure out what the secret key is.
The most widely used system, RSA, depends on prime numbers. Prime numbers are numbers that can only be evenly divided by 1 and itself. For example, 51 is not a prime number because it can be factored into 3 and 17. 41, on the other hand, is prime. While some families have special celebrations for birthdays and anniversaries that are multiples of 10, in my family we reserve these for the prime numbers. It’s particularly appealing because prime numbers are fewer and further between as we get to the bigger numbers.
The secret key includes two very very large prime numbers, the public key includes what you get when you multiply those two prime numbers together, which gets you an even bigger number (those of you who know that the public key is not quite that should just let me get away with this simplification). When we use big enough prime numbers, there is no feasible way of going from the product of the two prime numbers back to the prime numbers themselves.
But the mathematical relationship between the secret and public key means that it is possible to use the public key to construct mathematical puzzles that can only be solved with knowledge of the secret key. This, deep down, forms the basis of what is called public key cryptography.
Here is a 617 digit (2048 bit) number that is the product of two 1024 bit prime numbers.
27219047959652654722414170131901754810882037173366387499643752583360
53674248472885748311121894086236015825177742540974215589410617055811
41056251871687611322203645648061852827702887407867981735879821807359
50224524930259181407685867849596786096790404160010876158425560398851
41008831976697149422479797818743514039235769485328395195614137252841
88464854991690851521459279495154864183891934329195018204208468538473
68871936474843479723548096187507192106674753171257734855506742032089
84432415517977675338784314535588802117418628093418022096614839091351
52559954997038551099013710643874352212670179579776988148618882559168
53533
That number would be part of the public key, when the corresponding secret key would contain the two 512 bit prime numbers this big number factors to.
There are systems based on other mathematical relations, including Discrete Logarithms and Elliptical Curves. All have the same property in that, while there is no feasible way to get from the signatures and public keys to the corresponding secret keys, anyone with the public key can verify that only someone who knows the corresponding secret could have created the signature.
A certificate, under any other name, would not verify the same
The 1Password.app is digitally signed using our secret key. Only those who can get at that secret could create a signature that anyone can then verify using our public key. As you can imagine, our secret key is protected by a very strong password.
But anyone could create a digital signature of modified versions of 1Password.app with their own secret key. So the next question is: how does your computer know that the public key it used to verify 1Password.app really and truly belongs to us? This is where a certification authority (CA) comes into play.
The file containing our public key contains much more than just the mathematical public key itself. It contains information about the mathematical public key (like what sort of system is used) and it also contains our name and other identifying material. This is our certificate. There is a whole lot of stuff in a certificate, but let’s focus now on information about us (the owners of the certificate) and the numbers needed for the public key.
Our public key and our name in our certificate is, ultimately, just data stored on a computer; and just like any data stored in a file, it can be digitally signed. If someone tinkers with the name in a certificate, then the signature used to sign the certificate previously will not verify correctly. So just as our signing of 1Password.app means that if it is tampered with, the signature won’t verify; if someone tampers with a signed certificate, then the signature on the certificate won’t verify.
So, crucially, our certificate has a third kind of information. We’ve already talked about (1) our name and other identity information; and (2) our public key and other technical information that goes along with that. The third type of information is a signature (from someone else) who has signed the first two types of information in the certificate.
Who signs the signers?
As I said in the previous section, our certificate is in fact signed by someone else’s secret key. Whose? The answer is that it is signed by a key belonging to Apple. Apple is issuing and signing certificates, which makes Apple act as a certification authority. Someone who has access to the private key used for signing Apple developer certificates has determined that we meet the criteria needed to call ourselves AgileBits Inc.
The public key that is used to sign the AgileBits certificate is part of a certificate that belongs to “Developer ID Certification Authority”. The next question is: what authority signed the Developer ID Certification Authority’s certificate? And the answer will be another certification authority belonging to Apple. It is called “Apple Root CA”.
Who signed the Apple Root CA’s certificate? In practical terms, nobody did—though, technically, it is a self-signed certificate. A self-signed certificate says, “I am who I say I am because I say so.” Normally when you encounter self-signed certificates you should be cautious.
Unless you have some other reason to trust a self-signed certificate, you should be suspicious of it. Fortunately, Apple gives us a very good reason to trust this certificate authority. They have included the Apple Root CA certificate in every copy of OS X and marked it as “trusted” by the system.
You can check to see what root certificate the operating system trusts by launching the Keychain Access application (in the Utilities folder in Applications). With that you can inspect the System Roots keychain which contains, among other things, a variety of certificates from various certification authorities.
All of this checking of certificates and signatures is performed by the system. With Mountain Lion, Apple is bringing more of this technology to protect what applications are, or are not, allowed to run on your Mac.
Jeffrey Goldberg
Principal Security Architect
Tweet about this post