[Person Man]

Introduction

As people know (or are learning), Leopard marks the start of code signing, which is a security measure designed to help keep programs from being modified on disk or in memory without our knowledge. It will also allow one to verify that a program came from who it says it came from. (i.e. that copy of Photoshop on your hard drive really came from Adobe, or that copy of Office really came from Microsoft, assuming the developer has gotten a code signing certificate from an issuer that verifies their identity). It is also possible for smaller developers (i.e. freeware and shareware) to "self-sign" their code which allows for full benefits of code signing as far as the system is concerned, but there would be no way to independently verify who the program came from. (Independently verified code signing certificates ain't cheap-- $299-$699, depending on who you get them from).

During the transition period, Leopard is very lenient towards unsigned code, but it is less lenient towards signed code with broken or invalid signatures. As it stands, code needs to be signed to work properly with the new firewall and with the Parental Controls feature. If a program is not signed, the system will sign it with an "ad-hoc" signature when one configures the firewall or Parental Controls to allow or deny access to that program. As time goes one, more and more system facilities will begin to require code to be signed (presumably this will happen with point-releases or security updates of the operating system). A program with a broken or invalid signature (i.e. one that has been modified) will not have automatic access to the keychain, for example, and one will be prompted for keychain access each time the program runs.

All of the applications that come with Leopard have been signed by Apple. This means that if the signature is valid, the application has not been modified, and you can verify that the program actually came from Apple. What does this mean for tinkerers, the people who like to modify programs to change icons or edit menus, plist files? It means that making any modifications will invalidate the signature, and the programs will not behave properly under certain circumstances. For example, if Mail's signature is invalidated, you will be prompted for your password every time it wants to access your keychain. There will be no way to tell it to always allow access. Later on, as Leopard gets less lenient about signed code, the system may prompt you each time you execute a program with an invalid signature. (Imagine having to answer a dialog box like, "This application has an invalid signature. Do you wish to run this application anyway?" each and every time you run a program, with no way to turn it off).

So, if you like to tinker with your applications, how do you avoid the scenarios described above? You either don't modify the apps, or you re-sign the modified app with a new signature. The modified application won't identify itself as coming from Apple any more, but it regains full status as a signed application with a valid signature. This assumes, of course, that the program doesn't check to see if the signature has changed. To my knowledge, Apple hasn't done this with any of their apps, but some third party developers have done this.

When an application is signed, the system uses the certificate to apply a cryptographic signature to the binary executable file (usually in the MacOS folder inside the application's bundle). Each type of code in a universal binary (PPC 32-bit, PPC 64-bit, Intel 32-bit, Intel 64-bit) is signed separately. Each of the resources in the Resources folder is checksummed and the Resources folder is "sealed," such that any changes to the files inside will be detected. Sub-bundles (i.e. "helper applications," plug-ins, etc). contained within an application's bundle are not signed with the application, but must be signed separately. This is important to know when modifying things like iTunes and Mail, for example.

The following posts will describe how to verify an application's signature, how to obtain a code signing certificate, and how to replace Apple's signature with your own if you make your own modifications to Apple's applications. Note that it is not necessary to have the Developer Tools (XCode) installed to do any of this, but it is recommended that they be there (you'll probably already have them installed if you're a tinkerer).

[Person Man]

Verifying an Application's Signature

Leopard includes a command line tool, "codesign" that allows you to verify signatures, sign applications that are unsigned, or re-sign applications. From the command line, type "man codesign" for complete instructions.

Verifying an application's signature is simple. From the command line, type:

codesign -v /path/to/application

The easiest way to do this is to type the "codesign -v " (without the quotes), press space, and then drag the application file to the Terminal window, which will automatically enter the path to the application for you.

If the signature is valid, the program will exit without printing anything. If the code has been modified (or if a .plist file has been changed), it will say:

code or signature modified.

If a sealed resource has been changed, it will say:

a sealed resource is missing or invalid.

You can examine the signature information by doing the following:

codesign -dvvvv /path/to/application

The system will display the following (for example, Safari)

Executable=/Applications/Safari.app/Contents/MacOS/Safari
Identifier=com.apple.Safari
Format=bundle with Mach-O universal (i386 ppc7400)
CodeDirectory v=20001 size=7521 flags=0x0(none) hashes=370+3 location=embedded
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist entries=23
Sealed Resources rules=9 files=283
Internal requirements count=0 size=12

[Person Man]

Obtaining a Code Signing Certificate

In order to sign applications, you need to have a code signing certificate in your keychain. You can purchase one from one of the certificate authorities, such as Verisign, Thawte, or RSA, but they're fairly expensive that way.

If you're doing it just to modify applications for your own use (or you're a freeware or shareware developer who doesn't want the independent verification), you can generate your own certificate to use. This is done using the Keychain Access application, in the Utilities folder. Here's how:

1. Open Keychain Access.
2. Go to the Keychain Access menu, and under Certificate Assistant, choose Create a Certificate
3. Name your Certificate. (I recommend using something other than your first and last names)
4. For Type, choose Self Signed Root.
5. Make sure Let me override defaults is checked and click Continue.
6. Under Serial Number, use a random number. Just make sure there is no other certificate on your system with the same name and serial number
7. Give yourself a sufficiently long validity period. For a little over 5 years, use 2000 days. For almost 11 years, choose 4000 days.
8. Under Certificate Type, choose Code Signing, and click Continue.
9. Enter your personal information on the next screen. Have fun with Organization and Organizational Unit. After all, this is for your own personal use. Don't use "Apple." I myself used something like "Orange Computer" for Organization and "Hacking Department" for Organizational Unit. Click Continue when all has been filled out.
10. For Key Pair Information, accept the defaults and click Continue.
11. For Key Usage Extension, accept the defaults and click Continue.
12. For Extended Key Usage Extension, accept the defaults and click Continue.
13. For Basic Constraints Extension, accept the defaults and click Continue.
14. For Subject Alternate Name Extension, accept the defaults and click Continue.
15. Use your "login" keychain to store the certificate and click Continue.
16. Now you have to set your certificate to be "trusted."
17. Go to your keychain, and right click (control click) on the new certificate you made and choose Get Info.
18. Open the triangle next to Trust.
19. Go down to Code Signing, and choose Always Trust.
20. Close the box. The system will ask for your admin password. Enter it and click OK.

You're done, and you have a certificate you can use for signing your own code, or re-signing someone else's code that you've modified or tinkered with.

[Person Man]

Re-Signing a Modified Apple Application

Before you re-sign an application that you've modified, make sure you're done with the modifications, because otherwise you'll have to sign it again. Once you've re-signed the application, it will look to the system like a different application than the one Apple provided. For this reason, make sure you do this on a copy of the Apple-supplied application. Besides, you've got to make sure that an update from Apple doesn't screw up your modifications, or vice versa.

Re-signing the application is quite simple.

1. Open Terminal.
2. Type "codesign -f -s (name of certificate) /path/to/application

(name of certificate) is the name you gave your certificate in the creating a certificate section. Remember that you'll have to escape any spaces or other nonstandard characters that appear. For example, if your certificate were called "Harry Potter's Certificate," you would use "Harry\ Potter\'s\ Certificate." As an alternative, you can use a portion (substring) of the certificate's name as long as that portion does not appear anywhere else in your keychain. So you could type "Potter" instead of the full string with escaped characters.

Once again, you can type "codesign -f -s (name of certificate) " and drag the application to be resigned from the Finder to the Terminal window to enter the path name if you don't want to type it out yourself.

When you're done, you can use "codesign -dvvvv /path/to/application" to verify that the signature has changed.


References

1. Manpage for codesign. (Type "man codesign" in Terminal).
2. Code Signing Release Notes: Code Signing Release Notes for Mac OS X v10.5
3. Code Signing Guide

[goMac]

Resigning an application won't reopen it's access to it's old keychain. I guess this is useful for getting altered applications to be compatible with parental controls again, but I'm not really sure what this solves because the application will still be treated like an entirely different app (especially since you've signed it as an entirely different app), and it won't get it's same access back. It's not just a matter of the system getting upset when the signature is invalid. It's a matter of the system getting upset when the signature is invalid or the signature has changed.

This also does not account for when a dev decides to check to make sure their signature is intact.

[Person Man]

Originally Posted by goMac 

Resigning an application won't reopen it's access to it's old keychain. I guess this is useful for getting altered applications to be compatible with parental controls again, but I'm not really sure what this solves because the application will still be treated like an entirely different app (especially since you've signed it as an entirely different app), and it won't get it's same access back. It's not just a matter of the system getting upset when the signature is invalid. It's a matter of the system getting upset when the signature is invalid or the signature has changed.

This also does not account for when a dev decides to check to make sure their signature is intact.

This is all covered in the Introduction I wrote.

This will also allow a self-modified application to access the keychain without having to constantly enter your password each and every time the application needs to access the keychain.

Of course it's going to act like a different app to the system. After someone has tinkered with the resources of an application, it BECOMES a different app. But at least it gains full system privileges again, rather than being relegated to the status of an "application with an invalid signature."

That's the point of this. It's to allow people to modify their applications without running afoul of the signature check.