1Password was born ready for Mountain Lion

Mountain LionAs you may have heard, Apple has a new kitty called Mountain Lion on the way, due out sometime in July. Apple’s site naturally brags about things like “over 200+ new features” and “more, better, faster,” but I’m sure your top question is: “but will 1Password be ready?!”

The short and sweet answer is: like Terry Benedict1Password was born ready. Ok, maybe’s that’s going a bit far. I mean, the first version of 1Password, released over six years ago, was actually born and raised on OS X 10.4 Tiger and missing a vowel. And a consonant.

So let me try this again: as of recent updates to both the Mac App Store and website versions, 1Password is ready for Mountain Lion and even Gatekeeper, a new OS X feature that gives you more control over what apps your Mac can run. If you want to learn more about Gatekeeper, our Chief Defender Against the Dark Arts penned a couple of posts to give you a general overview and more details on this important OS X addition in Mountain Lion.

Of course, your decision to upgrade to a major new OS release probably rests on a number of other apps being ready as well. After all, not every app can be ready on day one, so don’t be afraid to do a little homework before taking the plunge. But as far as AgileBits factors in, you can rest assured that 1Password been ready for Mountain Lion for a while now!

1Password for Mac plays just fine in Apple’s sandbox

You may have heard the news that “Apple’s sandbox deadline has arrived” for the Mac App Store, and that it might cause headaches for some developers and their apps. There’s a lot to talk about in terms of this “sandbox” thing that Apple’s pushing, but I want to skip to the important part for you, our wonderful customers and readers: the Mac App Store version of 1Password has been ready for sandboxing since its debut in September 2011. For bonus points, the latest website and Mac App Store versions are even ready for Mountain Lion, too!

That means you have nothing to worry about as to whether Apple’s sandboxing rules will affect 1Password and its many excellent features. Our valiant developers started doing a ton of work on 1Password a long time ago—as soon as we heard sandboxing was coming to OS X. AgileBits has been humming along just fine since then, dreaming up new features, listening closely to your feedback, staying one step ahead in security, and building new foundation for the future of 1Password.

Now, if you’re interested to learn more about sandboxing and what it means for both developers and users, we’ve discussed it a little bit here on the Agile Blog. In a nutshell: Apple realized that if it added some restrictions to the files and parts of the system that applications can access, OS X can become more secure and resilient to malware or your typical rogue app. I guess you could say Apple gave these rules a test drive in iOS, since that’s how its apps have worked since the original iPhone in 2007.

Generally speaking, most users probably won’t notice any difference in day-to-day use of Mac App Store apps. But Apple’s new sandboxing restrictions for apps in its store can pose challenges for some developers whose apps have had free reign all these years. In some cases, developers might have to change or remove features, but some might have to remove their apps from the Mac App Store entirely. Again, 1Password has fortunately been prepared for these rules for nearly a year.

As for our previous posts on sandboxing and why Apple is doing it, you can check out Jeff’s posts about Gatekeeper, a feature coming to OS X that gives you control over how you install new apps.

A peek behind the Gatekeeper

Mountain Lion1Password 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 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

Security preference pane with GatekeeperGatekeeper 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.


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.

1Password certification information viewed with RB App CheckerIn the red box in the screenshot above, we see “The code and signature validate correctly”. This is telling us that matches the signature. If some crucial part of the had been changed, then the code (the files that make up 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.

1Password codesigning certificate chain

Again, you can explore details of the certificate chain. You will see that the certificate that signed 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 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


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 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 with their own secret key. So the next question is: how does your computer know that the public key it used to verify 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 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.

Apple Root CA

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.

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.]