Volume Number: 24
Issue Number: 11
Column Tag: Security

Code Signing - Get Used to It!

Digitally signed applications and you

by Scott Corley

So you're a computer. And you're not happy executing just any old software. No, you want to only run software that has been approved by someone you trust. How can you, the computer, tell the good from the bad?

Deciding what software can be allowed to execute is a need that crops up in many places these days. An operating system might want to grant trusted privileges only to drivers that are known to come from a trusted source. A user might want to verify that software they have downloaded from a vendor has not been modified, or that they are not being tricked into downloading something with a misleading name. Or, a cell phone manufacturer might want to retain the power to pre-approve every application that runs on their device, for security or business reasons.

Code Signing is simply a way for a computer to check out an application, a driver, or other chunk of code to verify that it was "signed" by a particular vendor, and that the code has not been modified since it was signed. Code Signing is applied primarily to security and digital rights management efforts.

Code Signing requires a one-way hash function and a public-key encryption infrastructure. A one-way hash function simply takes a stream of bytes and calculates a small "digest" that uniquely represents the stream of bytes - similar to a "checksum", but much more secure. A digest is typically 32 bytes or less, a nice, small, unique representation of any arbitrarily sized chunk of bytes. A good one-way hash function can create a unique digest for any sequence of bytes, with a very small probability of a "collision", or any two sequences of bytes generating the same digest. By "very small probability", we're speaking in cryptographic terms, where it would take all of the computers on every planet hundreds of thousands of eons to calculate another sequence of bytes that reduces to the same digest (give or take a few hundred thousand eons, depending on the hash function and whether or not it has recently been discovered to be weak).

The second required piece of the code-signing puzzle, public-key encryption, provides a bit of useful magic. I can generate a pair of keys, called my "private" key and my "public" key. My private key, which is always kept secret and accessible only to me, can be used by me to encrypt a chunk of data. Anyone with my public key can then decrypt it. At first, this sounds a bit useless - why would I want to encrypt something that anyone else in the world can decrypt? The great thing is that this data I have encrypted can only be decrypted with MY public key. This is the beauty of digital signing - if I encrypt a 32 byte digest with my private key, you can grab my public key from somewhere and verify whether I did, in fact, "sign" that 32 byte digest with my private key. Nobody else can sign a digest and claim that it was done with my private key.

Digital signatures can be chained together in a very convenient way. In the example above, I have signed a 32 byte digest with my private key, and I am asking you to verify it with my public key. Where do you get my public key? How do you know the entire key pair wasn't created by someone else claiming to be me? In every code signing system, there is a party who holds a "root" private/public key pair. That Certificate Authority is responsible for verifying you are who you say you are. Then, in a bit of digital signature awesomeness, the Certificate Authority uses their root private key to sign YOUR public key along with a brief bit of text explaining who you really are. Thus, anyone who has a trusted copy of the root public key can validate that your public key really belongs to you and that it is "approved" by the Certificate Authority. (In reality, there are also "intermediate" certificates used by the Certificate Authority that can be changed out if needed, for example, in case the intermediate certificate's private key is accidentally disclosed to an unauthorized party).

This public-key infrastructure allows a Certificate Authority to control who can sign code, and it allows end-user's computers to validate a chain of trust. If we combine one-way hash functions with public-key infrastructure used to create digital signatures, we can do a pretty good job of verifying that an application was signed by a party that has obtained a certain level of trust with the central signing authority.

Let's say Alice is writing an application for a cell phone, and she is required to digitally sign the application before it can be distributed. In order for her digital signature to be trusted, she must first have a relationship with the entity that is requiring the digital signature (let's call this entity Blueberry, Inc.) Alice first generates a random public/private key pair, using her personal computer, and also generates a Certificate Signing Request that includes her identifying information, such as her name, her company name, her website address, the address of her office, etc.

Blueberry, Inc. is given the public key and the Certificate Signing Request. Alice gets a phone call to verify that she exists, some checks are made on her other information, and she pays a fee. Blueberry has their own public and private key, and they use the private key to sign Alice's public key and Certificate Signing Request in a way that anybody can then verify that Alice's public key does, in fact, belong to her.

Now, Alice can use her private key to sign an application she makes. Instead of using her private key to encrypt the entire application, she simply uses the one-way hash function to create a digest of the application, and then signs the digest with her private key.

Carl, who has a Blueberry cell phone, would like to download Alice's application. But Blueberry, Inc. has declared that their cell phones will only execute code that has been signed by an authorized certificate.

At this point, Carl doesn't need to do anything to verify that the application came from Alice. He doesn't even have to be online for his phone to verify the validity of the application.

Carl's phone will use the same one-way hash function that Alice used to create a digest of the application. It will then look at the signed digest that Alice included with her application. Carl's phone will have a master copy of Blueberry, Inc.'s public key that Blueberry put on the phone when it was made. The phone can check to see if Alice's public key is valid (it was signed by Blueberry's private key, so it will check out ok). The phone can then check to see if the digest that Alice signed matches the digest that the phone computed. If the digests match, then it is reasonable to conclude that the application has not been modified, that it has come from Alice, and that Blueberry has verified that Alice is trusted enough to be signing applications.

An additional step can be added by Blueberry, Inc, if they want to approve each of Alice's applications individually. Blueberry can require that the application signature added by the developer be signed one final time by Blueberry. This way, Alice can't publish a new application on Blueberry's system without Blueberry's final approval.

Mac development tools are generally based on BSD command-line tools with nice friendly GUIs on top. XCode, for example, is a really nifty, easy to use GUI that relies on the GCC compiler toolchain.

For code signing, there is a command line tool called "codesign". When you set up code signing in XCode (in the "Code Signing" section of the Build settings), you are really just specifying the information that XCode needs to execute codesign. In fact, if you look at the build transcript in the Build Results window after building an app with code signing set up, you'll see the exact command that XCode used to do the code signing.

codesign can also be used to get information about the validity of a signed app. The "—verify" option of codesign will check to see if a signature exists, and whether or not it is valid. If everything checks out ok, codesign —verify will say nothing (or, if you provide a "—verbose" option, it will report "valid on disk"). If there is no signature, it will report "code object is not signed" (or possibly some other error), which basically means it can't find a signature to verify. If there is a signature but something has been modified, codesign will report "a sealed resource is missing or invalid", meaning the hash of what you have does not match the hash of what was originally signed.

If you would like to know some information about who signed an application, you can use the "—details" option of codesign. The —details option can be used with varying levels of verbosity, and will show you who signed the app, along with some details of the application bundle. Look for the lines that start with the word "Authority:" to see what certificates were involved in the signing of the app.

Let's try out codesign with an app signed by Apple:

All of Apple's applications shipped with Mac OS X are signed by Apple. You can verify a digital signature using the codesign command.

% cd /Applications
% codesign —verify —verbose Mail.app
Mail.app: valid on disk
%

Now let's get some details about a signed app:

You can get details about who signed an app using codesign. The lines beginning with "Authority" show the chain of certificates that was used to sign the app. This particular app was signed with a certificate called "Software Signing". That certificate has been signed by an intermediate certificate called "Apple Code Signing Certification Authority", and in turn, that intermediate certificate has been signed by "Apple Root CA", the certificate that is at the root of Apple's internal trust chain.

The —details option will not show very much information unless you tell it to be verbose. Here, we have added "-vvv" to kick up the verbosity to get all of the details.

% codesign —details -vvv Mail.app
Executable=/Applications/Mail.app/Contents/MacOS/Mail
Identifier=com.apple.mail
Format=bundle with Mach-O universal (i386 ppc7400)
CodeDirectory v=20001 size=14679 flags=0x0(none) hashes=728+3 location=embedded
CDHash=49a4001b87af17822b4839dfb6274f79f3b62f76
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist entries=27
Sealed Resources rules=9 files=525
Internal requirements count=0 size=12
%

Now let's try it with a 3rd party app that is unsigned:

(replace "kdiff3.app" with something you have installed)

Apps on Mac OS X do not require a digital signature, and most 3rd party applications will not have one. If you try to verify a digital signature on an unsigned app, codesign will simply tell you that there isn't a signature.

% codesign —verify kdiff3.app
kdiff3.app: code object is not signed
%

It is also worth mentioning another command line tool, "openssl". We have already discussed "Keychain Access", the very easy-to-use GUI tool included to help create and manage digital signing certificates. If you've ever had to get an SSL certificate or really anything else involving certificates, you've probably run across openssl.

If you ever take a step outside the World of Apple, and need to work with digital certificates, openssl is your friend. It can convert certificates from one format to another, it can create certificate signing requests, and much much more. It does so much, in fact, that I'd recommend not worrying too much about how it works until you need it. If someone needs you to do something with openssl, they'll likely have a step-by-step walkthrough of what you need to do ready to go, and if not, it's usually easy to google up what you need. For example, if you are purchasing a a code signing certificate from a Certificate Authority, they'll have instructions how to use openssl to generate everything they need from you.

And, in super Mac OS X command-line goodness style, openssl is already on your mac. If you want to dig in, just type "man openssl" and read away.

If you want to digitally sign your Mac apps, you'll need to purchase a code signing certificate from a Certificate Authority. They will verify that you are who you say you are and issue you a certificate that is signed by them. This puts you in the "trust chain" that can be verified by the root certificates included in Mac OS X.

Certificate Authorities charge a few hundred dollars per year for code signing certificates. They can hit you up each year because your certificate is issued to you with an expiration date. If you sign code after that expiration date, the signature will not be considered valid. Code that you signed before the expiration date will still be considered validly signed after the expiration date, but you just won't be able to sign anything new until you fork over the renewal fee for your signing certificate.

Mac OS X supports code signing certificates issued from a number of well known Certificate Authorities. Other platforms may require code signing certificates from a single source - for example, you can't purchase an iPhone code signing certificate from anyone but Apple.

If we lived back in the glory days where it seemed every programmer could be trusted not to do anything malicious, code signing wouldn't be as widespread as it is now. These days, it is handy to have some way to figure out who wrote the code that is running on your computer, and whether or not that code has been modified.

Operating systems can use code signing to validate its own subsystems. A secure operating system can use signed code to grant special privileges - for example, a signed video driver can be given access directly to a video card, while all other software would not have that access. The ease of validating signed code via the signer's public key makes this approach very appealing, and it is used in Mac OS X as well as other major operating systems to ensure that nobody can distribute fake or altered system software updates.

Code signing, however, can also be used to prevent users from executing software that they would otherwise choose to execute. Most operating systems allow users to choose to execute unsigned code, but on some platforms, particularly cell phones and video game consoles, code signing is enforced. If an application is not signed by an approved developer, it will not be allowed to run. In the case of cell phones, this enforcement is usually done in the name of security, but in some cases, for example video game consoles like Nintendo's Wii, and Apple's App Store for the iPhone, it is also done for business reasons. We haven't seen this type of enforcement on desktop machines, but we'll see plenty more of it on future cell phones and other systems.

The reality of code signing is that it is one tool in a toolbox, and it is not invincible. Often, unsigned code can be given full access to a computer with the click of a "run it anyway" button that end-users are all too willing to click, or via the entry of a root password that users are all to comfortable entering when asked. Code signatures at a system level are validated by the system itself, so if the system was previously compromised, it could tell itself to allow any code, or code signed by a rogue party, and the end user would never know. And systems that strive to prevent end users from running unsigned code, like cell phones and video game consoles, are constant targets of hackers who go to increasingly astounding lengths to take those restrictions away.

Also, it is important to note that signed code says nothing about what the code actually does. A code signature only assures that the code was signed by a particular chain of certificates. The code itself could still be malicious in some way. If the central signing authority has tens of thousands of "trusted" entities who can sign code, odds are there are going to be varying levels of trust there. It is even possible for a rogue employee to sneak malicious code into an application without their employer's knowledge, then the employer signs the code, and the malicious code makes it out the door with a genuine signature. Because of these situations, code can still be run in a "sandbox" that prevents access to sensitive parts of the operating system and file system. Code that is signed for security reasons, like drivers or system updates, must go through a few layers of trusted internal audit before it gets the final digital signature.

Code signing is here to stay. For end users, it usually works behind the scenes, and they'll never even know it's there unless something goes wrong. For developers, however, code signing adds another thing that has to be made to work right, and it has business implications that need to be understood.

The actual code signing is done by tools, and those tools are typically integrated into the developer tool chain, automatically generating the digest and signing it after the build process is complete. But in this type of environment, it is likely that multiple certificates will be involved, depending on whether the application is being built for the developer's device, for beta testers, or for final deployment. Keeping all of these things straight, and verifying that everything is in its right place, can be daunting.

You Can Use Keychain Access Application (in Applications->Utilities) to create a Certificate Signing Request

A Certificate Signing Request asks for information about who will be associated with the signing certificate. Typically, the "Common Name" will be a company name, or an individual's real name.

The Key Size and Algorithm used to generate a key pair must match the standard defined by the code signing authority. 2048-bit RSA keys are common, and the default setting in the Keychain Access program's Certificate Assistant.

Code signing keys can also have business implications. Valid code signing key costs money, so there is added cost which can be significant, particularly if your app is very inexpensive or free. The biggest business implication of code signing, though, is the possibility of not being allowed to have a code signing certificate. Clearly, code signing is as much about allowing trusted entities to sign code as it is about preventing others from signing code. If you think you have a business opportunity on a platform that requires code signing, but for one reason or another you are unable to acquire the appropriate code signing certificate, then you simply won't be able to publish your application on that platform (and perhaps it's time to seek out a partner who can).

Code signing can provide a chain of trust, it can verify the original source of software obtained from untrusted sources, and it can give businesses control over who is allowed to publish software for their systems. For all of these reasons, code signing is here to stay. I hope this has made clear its main uses, how it affects software developers and end users, and how it will become a common part of software development in the future.

Scott has been a Mac software developer since he got his first Powerbook in 1991. Scott has written many applications for many platforms, primarily in the video game industry. He currently holds the title of Director at Wideload Games in Chicago, and has developed and published AcidSolitaire Collection for iPhone via his own company, Red Mercury, LLC.