Chapter 7: Computer Image Verification and Authentication

 < Day Day Up > 

Chapter 7: Computer Image Verification and Authentication


As law enforcement and other computer forensics investigators become more familiar with handling evidential computer material, it is apparent that a number of more or less formalized procedures have evolved to maintain both the continuity and integrity of the material to be investigated. Although these procedures are extremely effective under the current rules of evidence, it is expected that alternative procedures will develop as technology advances. The current procedures, in use by both law enforcement and computer forensics investigators, work something like this:

At least two copies are taken of the evidential computer. One of these is sealed in the presence of the computer owner and then placed in secure storage. This is the master copy and it will only be opened for examination under instruction from the Court in the event of a challenge to the evidence presented after forensic analysis on the second copy. If the computer itself has been seized and held in secure storage by law enforcement, this will constitute best evidence. If the computer has not been seized, then the master copy becomes best evidence. In either case, the assumption is that while in secure storage, there can be no possibility of tampering with the evidence. This does not protect the computer owner from the possibility that secured evidence may be tampered with.

A growing practical problem with this method of evidential copying occurs not due to the security aspect or appearance of the situation, but because of the increasing sizes of fixed disks found in computers. A size of 2 Gigabytes is no longer unusual and it is common to find more than one fixed disk within a single machine. The cost of the media is decreasing slowly, but this is still significant when considering the quantity of information to be copied and stored (even though the system does allow for media re-use). There is also the problem of the length of time individual copies may take to complete. A sizable saving in both time and expense might, therefore, be achieved if an alternative method of evidential security could be arranged.

 < Day Day Up > 

 < Day Day Up > 


There’s a wealth of mathematical algorithms dealing with secure encryption, verification, and authentication of computer-based material. These display varying degrees of security and complexity, but all of them rely on a second channel of information, whereby certain elements of the encryption/decryption/authentication processes are kept secret. This is characterized most plainly in the systems of public and private key encryption, but is also apparent in other protocols.

Consider the investigative process where computers are concerned: During an investigation, it is decided that evidence may reside on a computer system. It may be possible to seize or impound the computer system, but this risks violating the basic principle of innocent until proven guilty, by depriving an innocent party of the use of his or her system. It should be perfectly possible to copy all the information from the computer system in a manner that leaves the original system untouched and yet makes all contents available for forensic analysis.

When this is done, the courts may rightly insist that the copied evidence is protected from either accidental or deliberate modification, and that the investigating authority should prove that this has been done. Thus, it is not the content that needs protection, but its integrity.

This protection takes two forms: A secure method of determining that the data has not been altered by even a single bit since the copy was taken, and a secure method of determining that the copy is genuinely the one taken at the time and on the computer in question. For the purpose of this chapter, these elements are collectively referred to here as the Digital IMAGE Verification and Authentication protocol.[i]

It is argued that when considering forensic copies of computer contents, encryption of data is not the point at issue. Neither are the provisions of the many digital signature protocols appropriate to the requirements of evidential authentication (see sidebar, “Digital IDs and Authentication Technology”).

start sidebar
Digital Ids And Authentication Technology

When customers buy software in a store, the source of that software is obvious. Customers can tell who published the software, and they can see whether the package has been opened. These factors enable customers to make decisions about what software to purchase and how much to “trust” those products.

When customers download software from the Internet, the most they see is a message warning them about the dangers of using the software. The Internet lacks the subtle information provided by packaging, shelf space, shrink wrap, and the like. Without an assurance of the software’s integrity, and without knowing who published the software, it’s difficult for customers to know how much to trust software. It’s difficult to make the choice of downloading the software from the Internet.

For example (when using Microsoft Authenticode coupled with Digital IDs ™ from VeriSign), through the use of digital signatures, software developers are able to include information about themselves and their code with their programs. When customers download software signed with Authenticode and verified by VeriSign, they should be assured of: content source, where the software really comes from the publisher who signed it; and content Integrity, where the software has not been altered or corrupted since it was signed.


The author and publisher do not endorse any specific computer forensics software over another. Authenticode from Microsoft and Digital IDs from VeriSign are mentioned here for illustration purposes only.

Users benefit from this software accountability because they know who published the software and that the code hasn’t been tampered with. In the extreme case that software performs unacceptable or malicious activity on their computers, users can also pursue recourse against the publisher. This accountability and potential recourse serve as a strong deterrent to the distribution of harmful code.

Developers and Webmasters should benefit from Authenticode, because it puts trust in their name and makes their products harder to falsify. By signing code, developers build a trusted relationship with users, who then learn to confidently download signed software from that software publisher or Web site provider. With Authenticode, users can make educated decisions about what software to download, knowing who published the software and that it hasn’t been tampered with.

Who Needs a Software Publisher ID?

Any publisher who plans to distribute code or content over the Internet or over corporate extranets, risks impersonation and tampering. For example, Authenticode is currently used to sign 32-bit .exe files (PE files), .cab files, .ocx files, and .class files. In particular, if you are distributing active content (such as ActiveX controls) for use with such Microsoft end user applications as Internet Explorer, Exchange, Outlook, or Outlook Express, you will want to sign code using Authenticode.

VeriSign offers a Class 3 Digital ID designed for commercial software publishers. These are companies and other organizations that publish software. This class of Digital IDs provides the identity of a publishing organization and is designed to represent the level of assurance provided today by retail channels for software.


Microsoft client applications, such as Internet Explorer, Exchange, Outlook, and Outlook Express, come with security features that incorporate Authenticode. These applications are often used to obtain other pieces of software. In a component model such as ActiveX™ or Java™, this happens frequently, often without the end user being aware of it. For example, when a user visits a Web page that uses executable files to provide animation or sound, code is often downloaded to the end user’s machine to achieve the effects. Although this may provide substantial value, users risk downloading viruses or code from a disreputable publisher.

If an end user of one of these applications encounters an unsigned component distributed via the Internet, the following will occur: If the application’s security settings are set on “High,” the client application will not permit the unsigned code to load; if the application’s security settings are set on “Medium,” the client application will display a warning similar to the screen shown in Figure 7.1 on page 169.[ii]

click to expand
Figure 7.1: Security warning screen. (©Copyright 2002. VeriSign. All rights reserved).

By contrast, if a user encounters a signed applet or other code, the client application will display a screen similar to the one shown in Figure 7.2 on page 170.[iii] Through Authenticode, the user is informed:

click to expand
Figure 7.2: Client application security warning. (©Copyright 2002. VeriSign. All rights reserved).

  1. Of the true identity of the publisher

  2. Of a place to find out more about the control

  3. The authenticity of the preceding information

Users can choose to trust all subsequent downloads of software from the same publisher. They can also choose to trust all software published by commercial publishers (see preceding information) that has been certified by VeriSign. Simply by clicking the “More Info” button, users can inspect the certificate and verify its validity, as shown in Figure 7.3 on page 170.[iv]

click to expand
Figure 7.3: Inspect the certificate and verify its validity. (©Copyright 2002. VeriSign. All rights reserved).

Technical Overview

A Digital ID (also known as a digital certificate) is a form of electronic credentials for the Internet. Similar to a driver’s license, employee ID card, or business license, a Digital ID is issued by a trusted third party to establish the identity of the ID holder. The third party who issues certificates is known as a Certification Authority (CA).

Digital ID technology is based on the theory of public key cryptography. In public key cryptography systems, every entity has two complementary keys (a public key and private key) that function only when they are held together. Public keys are widely distributed to users, whereas private keys are kept safe and only used by their owner. Any code digitally signed with the publisher’s private key can only be successfully verified using the complementary public key. Another way to look at this is that code successfully verified using the publisher’s public key (which is sent along with the digital signature), could only have been digitally signed using the publisher’s private key (thus authenticating the source of the code), and has not been tampered with.

The purpose of a Digital ID is to reliably link a public/private key pair with its owner. When a CA such as VeriSign issues Digital IDs, it verifies that the owner is not claiming a false identity. Just as when a government issues you a passport, it is officially vouching for the fact that you are who you say you are. So, when a CA issues you a digital certificate, it is putting its name behind the statement that you are the rightful owner of your public/private key pair.

Certification Authorities

Certification Authorities, such as VeriSign, are organizations that issue digital certificates to applicants whose identity they are willing to vouch for. Each certificate is linked to the certificate of the CA that signed it. As the Internet’s leading Certification Authority, VeriSign has the following responsibilities:

  1. Publishing the criteria for granting, revoking, and managing certificates

  2. Granting certificates to applicants who meet the published criteria

  3. Managing certificates (e.g., enrolling, renewing, and revoking them)

  4. Storing VeriSign’s root keys in an exceptionally secure manner

  5. Verifying evidence submitted by applicants

  6. Providing tools for enrollment

  7. Accepting the liability associated with these responsibilities

  8. Time-stamping digital signatures

How Authenticode Works with VeriSign® Digital IDs

Authenticode relies on industry-standard cryptography techniques such as X.509 v3 certificates and PKCS #7 and #10 signature standards. These are well-proven cryptography protocols, which ensure a robust implementation of code-signing technology. Developers can use the WinVerifyTrust API, on which Authenticode is based, to verify signed code in their own Win32 applications.

Authenticode uses digital signature technology to assure users of the origin and integrity of software. In digital signatures, the private key generates the signature, and the corresponding public key validates it. To save time, the Authenticode protocols use a cryptographic digest, which is a one-way hash of the document. The process is outlined below and shown in Figure 7.4 on page 171.[v]

click to expand
Figure 7.4: Authenticode—VeriSign® Digital IDs Process. (©Copyright 2002. VeriSign. All rights reserved).

  1. Publisher obtains a Software Developer Digital ID from VeriSign

  2. Publisher creates code

  3. Using the SIGNCODE.EXE utility, the publisher:

    Creates a hash of the code, using an algorithm such as MD5 or SHA

    Encrypts the hash using his/her private key

    Creates a package containing the code, the encrypted hash, and the publisher’s certificate

  4. The end user encounters the package.

  5. The end user’s browser examines the publisher’s Digital ID. Using the VeriSign® root Public Key, which is already embedded in Authenticode-enabled applications, the end user browser verifies the authenticity of the Software Developer Digital ID (which is itself signed by the VeriSign® root Private Key).

  6. Using the publisher’s public key contained within the publisher’s Digital ID, the end user browser decrypts the signed hash.

  7. The end user browser runs the code through the same hashing algorithm as the publisher, creating a new hash.

  8. The end user browser compares the two hashes. If they are identical, the browser messages that the content has been verified by VeriSign, and the end user has confidence that the code was signed by the publisher identified in the Digital ID, and that the code hasn’t been altered since it was signed.


The entire process is seamless and transparent to end users, who see only a message that the content was signed by its publisher and verified by VeriSign.


Because key pairs are based on mathematical relationships that can theoretically be “cracked” with a great deal of time and effort, it is a well-established security principle that digital certificates should expire. Your VeriSign® Digital ID will expire one year after it is issued. However, most software is intended to have a lifetime of longer than one year. To avoid having to resign software every time your certificate expires, a timestamping service is now available. Now, when you sign code, a hash of your code will be sent to VeriSign to be timestamped. As a result, when your code is downloaded, clients will be able to distinguish between code signed with an expired certificate, which should not be trusted, and code signed with a certificate that was valid at the time the code was signed, but which has subsequently expired. This code should be trusted.[vi]

end sidebar

[i]“DIVA Computer Evidence—Digital Image Verification And Authentication,” Computer Forensics UK Ltd, Third Floor, 9 North Street, Rugby, Warwickshire, CV21 2AB, UK, 2002.

[ii]“Software Publisher Digital IDs For Microsoft Authenticode Technology,” VeriSign Worldwide Headquarters, 487 East Middlefield Road, Mountain View, CA 94043 (VeriSign, and other trademarks, service marks and logos are registered or unregistered trademarks of VeriSign and its subsidiaries in the United States and in foreign countries.), (©Copyright 2002. VeriSign. All rights reserved), 2002.





 < Day Day Up >