WEBVTT

0:00:09.300000 --> 0:00:15.360000
 When we talk about validating evidence,
 we're talking about the steps

0:00:15.360000 --> 0:00:19.740000
 and exercises we go through to ensure
 that the integrity of the evidence

0:00:19.740000 --> 0:00:23.680000
 is performed. And regardless of the
 type of case, it's always going to

0:00:23.680000 --> 0:00:27.300000
 be important that we demonstrate that
 the data we analyzed was always

0:00:27.300000 --> 0:00:28.980000
 in the original shape.

0:00:28.980000 --> 0:00:30.200000
 And how do we do that?

0:00:30.200000 --> 0:00:33.020000
 We're going to do
 that with a hash.

0:00:33.020000 --> 0:00:35.160000
 What is a hash though?

0:00:35.160000 --> 0:00:38.520000
 A hash is a one-way cryptographic
 function.

0:00:38.520000 --> 0:00:44.300000
 They take a variable length of input and
 they produce a fixed-length string,

0:00:44.300000 --> 0:00:45.980000
 which is the hash.

0:00:45.980000 --> 0:00:52.260000
 But any change to that original data,
 no matter how big or how small that

0:00:52.260000 --> 0:00:58.300000
 change was, it's going to result in
 a significantly different hash.

0:00:58.300000 --> 0:01:01.200000
 What types of hash algorithms
 do we use?

0:01:01.200000 --> 0:01:04.520000
 Primarily, you're going
 to see MD5 and SHA-1.

0:01:04.520000 --> 0:01:09.680000
 You might see some SHA-256, a lot of,
 sometimes, software supporting that.

0:01:09.680000 --> 0:01:14.940000
 Just keep in mind, we're not necessarily
 concerned about whether or not

0:01:14.940000 --> 0:01:17.220000
 the MD5 or the SHA-1.

0:01:17.220000 --> 0:01:20.240000
 Hashing algorithm has been broken because
 we're doing it as a one-way

0:01:20.240000 --> 0:01:24.460000
 cryptographic function just to generate
 a hash and ensure that the integrity

0:01:24.460000 --> 0:01:29.620000
 is sealed. We're not encrypting it
 or like that or any type of stuff.

0:01:29.620000 --> 0:01:31.540000
 We're not encrypting that at all.

0:01:31.540000 --> 0:01:35.680000
 What I like to do and what I think should
 always be done is to do an MD5

0:01:35.680000 --> 0:01:39.320000
 sum hash and a SHA-1 hash.

0:01:39.320000 --> 0:01:46.100000
 With those two hashes, the chances of us
 having what's called a hash collision,

0:01:46.100000 --> 0:01:52.360000
 which is one file with, I'm sorry,
 what I call a hash collision, which

0:01:52.360000 --> 0:01:56.520000
 is a situation that you can come up
 with where you have two different

0:01:56.520000 --> 0:01:58.700000
 files that have the
 exact same hash.

0:01:58.700000 --> 0:02:03.840000
 It's extremely unlikely that you're
 going to have a hash collision with

0:02:03.840000 --> 0:02:09.880000
 a file that's been done with an
 MD5 or a SHA-1 on their own.

0:02:09.880000 --> 0:02:14.180000
 But if you do an MD5 and a SHA-1 together,
 the chances of that hash collision

0:02:14.180000 --> 0:02:16.920000
 is going to be astronomical.

0:02:16.920000 --> 0:02:21.140000
 To me, that's just how you're going
 to best prove that it's going to do.

0:02:21.140000 --> 0:02:25.640000
 To me, that's how you're going to best
 prove that the evidence is still

0:02:25.640000 --> 0:02:27.800000
 the original evidence that
 you're looking at.

0:02:27.800000 --> 0:02:31.480000
 You're going to want to run that hash
 check every time, at least every

0:02:31.480000 --> 0:02:34.220000
 day that you're performing
 analysis of the software.

0:02:34.220000 --> 0:02:37.960000
 Just a quick double check, most of your
 software tools automatically log

0:02:37.960000 --> 0:02:41.020000
 that you did it or in your forensic
 notes, every time you sit down and

0:02:41.020000 --> 0:02:49.980000
 start the investigation, you can
 and then you're good to go.

0:02:49.980000 --> 0:02:53.420000
 Then just remember again that the
 proof is always in that hash.

0:02:53.420000 --> 0:02:57.300000
 Hashstrings are always going to be used
 as the evidentiary image that's

0:02:57.300000 --> 0:02:59.220000
 identical to the original source.

0:02:59.220000 --> 0:03:03.220000
 Sometimes you're going to get some differences
 and it's very, very rare

0:03:03.220000 --> 0:03:07.200000
 that the image from the collection is
 going to differ from the analysis

0:03:07.200000 --> 0:03:10.640000
 software. It doesn't necessarily mean
 that you're going to have to go

0:03:10.640000 --> 0:03:14.820000
 back and re-image the hard drive
 or that your evidence is out.

0:03:14.820000 --> 0:03:16.180000
 It isn't admissible.

0:03:16.180000 --> 0:03:18.800000
 What it means is that you might need
 to go back and do a few checks.

0:03:18.800000 --> 0:03:22.740000
 You might need to explain why it is
 that that hash might have changed.

0:03:22.740000 --> 0:03:24.880000
 Maybe you imaged it
 on a live system.

0:03:24.880000 --> 0:03:29.100000
 Even a physical image on a live system,
 the hash could change from today

0:03:29.100000 --> 0:03:31.820000
 to tomorrow when you
 talk about it.

0:03:31.820000 --> 0:03:33.380000
 Just think about it.

0:03:33.380000 --> 0:03:36.700000
 Then again, look at and trust your
 forensic acquisition tools.

0:03:36.700000 --> 0:03:40.640000
 They perform these hash checks and verifications,
 sometimes automatically,

0:03:40.640000 --> 0:03:45.080000
 without you even seeing it and include
 your hash checks in your reports

0:03:45.080000 --> 0:03:46.400000
 and in your note taking.