Mobile Forensics · Reporting & Ethics · Lesson 1 of 5

Hashing & Verification

Learn how a hash proves that a copy of phone evidence hasn't changed.

A fingerprint for data

Before an examiner reads a single message, they need a way to prove later that the evidence hasn't changed. The tool for this is a hash: a short, fixed-length value worked out from data by a math function. Feed in a file of any size and you get back a string of letters and numbers, a bit like a fingerprint for that exact data.

Forensic hashes have three useful properties:

• Same input, same output. Hash the same file tomorrow, or on another computer, and you get the identical value.
• Tiny change, totally different output. Change one letter and the hash doesn't shift by one letter. It looks completely new. This is called the avalanche effect.
• One way. You can't rebuild the file from its hash. The hash identifies the data without revealing it.

The most common forensic hash today is SHA-256 (Secure Hash Algorithm, 256-bit). It's written as 64 hexadecimal characters (the digits 0 to 9 and the letters a to f). Older reports often show MD5, which is 32 characters long.

Here's how it's used. When a tool copies data from a phone, it creates an extraction (often called an image): a file or set of files holding the copied data. Right then, the examiner calculates its hash and records it in their notes and in the chain of custody record (the log of who handled the evidence, and when). Weeks later, before analysis or in court, anyone can hash the same extraction again. If the values match, the data is bit for bit the same as when it was collected. If they don't, something changed, and the examiner has to find out why.

NIST's mobile forensics guide (SP 800-101 Rev. 1) describes this practice: compute a cryptographic hash over the evidence files, then keep checking that it stays the same for their whole lifetime.

On the simulated phone, compare the evidence image's SHA-256 with the value recorded at acquisition. Then press the button that changes one character, and compare again.

Strong hashes, live phones, tested tools

Not all hashes are equally strong. A collision happens when two different inputs produce the same hash. For forensics that's the worst case, because someone could swap in different data with a matching fingerprint. Researchers have been able to create MD5 collisions on purpose since the mid 2000s. In 2011 the IETF, the body that publishes internet standards, said in RFC 6151 that MD5 is no longer acceptable where collision resistance is required. SHA-256 has no known practical collisions.

So why does MD5 still appear? Older tools and older case files used it, and an accidental MD5 match between two different files is still extremely unlikely. Many labs now record SHA-256, or both SHA-256 and MD5 so values can be checked against older records. Lab policy decides. What matters is writing down which algorithm was used.

Phones add a twist. A computer hard drive can be removed and copied through a write blocker, a device that stops anything from changing the drive. A running phone can't be frozen that way. Its clock ticks, logs get written and the system tidies storage in the background. NIST notes that back-to-back acquisitions of the same phone will be slightly different and give different hashes over all the data, although hashes of individual files usually stay the same.

So examiners hash the extraction, not the device. The hash proves the copy hasn't changed since it was made. It doesn't claim the phone itself stood still.

The tools need checking too. Tool validation means testing that a tool really does what it claims, for example on a test phone loaded with known content. NIST's Computer Forensics Tool Testing (CFTT) program writes test methods and publishes test reports, including for mobile acquisition tools, shared with the public through the US Department of Homeland Security. NIST's guide also suggests comparing the output of more than one tool to check that results are consistent.