X

Verifying file checksums and application code-signing

<p>Often, files that are distributed over the Internet are provided with a checksum number for security and file validity. While they are not needed, some people may wish to verify their downloads with the provided checksum numbers. In addition to checksu

CNET staff
3 min read

Often, files that are distributed over the Internet are provided with a checksum number for security and file validity. While they are not needed, some people may wish to verify their downloads with the provided checksum numbers. In addition to checksums, there are code signing and encryption algorithms that can be used for verifying distributed files and applications.

Checksums

Checksums are number and character strings generated from running a bit-checking algorithm on any file in the system. There are a variety of algorithms used (including MD5, SHA1), but the general idea is that individual bits, bytes, or other elemental features of a file are summed together to generate the string of characters that should be unique to that file. In essence, it is a fingerprint for the file. Running the same algorithm used to generate the checksum before the downloadshould verify that the received file is legitimate.

In Mac OS X, installers will sometimes run checksums on their components to verify they have not been corrupted and changed, but this cannot be done for files that do not have this kind of built-in checking routine, which includes a large number of shareware utilities, and even document files that are made available for download via the Web.

To run a checksum verification (message digest calculation), you will need to open the Terminal and run the following code:

openssl dgst -TYPE path_to_file

In this code, "TYPE" is the checksum algorithm to use, and is one of the following: md2, md4, md5, mdc2, rmd160, sha, sha1.

For instance, to run the sha1 digest calculation on the "Dock" application (PowerPC installation of Leopard) the following would be run and give the corresponding output:

mymac:~ jsmith$ openssl dgst -sha1 /System/Library/CoreServices/Dock.app/Contents/MacOS/Dock
SHA1(/System/Library/CoreServices/Dock.app/Contents/MacOS/Dock)= d36446252b9aedd3b9dd030d7cb64431aeb0da06
mymac:~ jsmith$ _

Keep in mind that checksums can only be run on individual files, and not on folders. As such, they are usually included with disk images and zipped files, but can also be run on individual components of an application package (such as that done on the Dock in our example).

Code-signing

In addition to checksums, Apple is incorporating other code-verification routines such as code-signing and encryption that can be used to ensure files are not tampered with before running them. Encrypted files cannot be accessed without a password, and distribution is mainly done in disk images that encapsulate and encrypt its contents. For code-signing, the algorithm applies to the application itself, which may not run if it cannot be verified by the code-signing routine.

To run a code-sign check on a packaged application, open the Terminal and type the following command followed by a space:

codesign -v

Then drag the application to the Terminal window (or otherwise complete the file path to the desired code) and press Enter. If the code-signing checks out then no output will appear, but if something has been changed in the application then the output will be the following (using "Mail.app" as an example):

mymac:~ jsmith$ codesign -v /Applications/Mail.app
/Applications/Mail.app: a sealed resource is missing or invalid
mymac:~ jsmith$ _

If the application is not signed (as is the case with many third-party applications), the output will be the following:

mymac:~ jsmith$ codesign -v /Applications/Skype.app
/Applications/Skype.app: code object is not signed
mymac:~ jsmith$ _

In many cases, the warning for signed applications may occur if a small file such as a property list is altered, or another file is placed within the application package. In such instances the program should still run just fine, but if you are unsure of tampering then this is a good way to check programs before running them. Code-signing is done by the developer, so verification ensures the code is as the developer wants it to be. Currently OS X only enforces code-signing for firewalls, parental controls, keychain access by applications, and application identification to the security subsystem, but it is possible that in the future Apple could enable system-wide code-signing as an option to prevent any altered or unsigned applications from running.

Resources

  • More from Late-Breakers