Chain Of Custody

At AIR, we use SHA-256 to hash all of the files collected by AIR, and then we take this to the next level. We achieve this by further hashing our .ppc collection file and sending that value to a Trusted Timestamp Server to generate a certificate.

This not only proves that the report and all of the data associated with it exist exactly as it did on acquisition, but it did so at the date and time notarized by a Trusted Timestamp Authority (TSA) certificate.

Thanks to RFC3161, you can not only prove that the data content is 100% intact, but also that the date and time of collection are guaranteed.

Trust in RFC 3161

Request for Comments (RFC) is a system that has been adopted as the official documentation of Internet specifications, communications protocols, procedures, and events. Used initially to record unofficial notes related to the ARPANET project in 1969, the system is now considered a standard-setting body for the Internet and its connected systems.

A published RFC will undergo a review and revision process, overseen by several groups, including the Internet Engineering Task Force (IETF), a large, open international community of network designers, operators, vendors, and researchers. As part of their collective role, they review the evolution of everything related to the development of internet architecture and the smooth operation of the internet. A list of RFC 3161-compliant Time Stamping Authorities (TSAs) can be found here. When choosing TSAs, users may want to consider whether their implementation of RFC 3161 has been qualified by organizations such as eIDAS (Electronic Identification and Trust Services).

RFC3161 defines how trusted timestamping leverages public-key cryptography and the Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) sets the required protocols for standardization.

One way to use a TSA allows a requestor to take the hash they’ve generated for the total of their collected data set, send that hash to the TSA, and receive in return a Timestamp Request Token (TST). This TST can be saved and, at any later time, used to verify both the content of the collection and the date and time at which the collection took place.

The RFC 3161 capability is not unique and is available from a whole range of independent third parties. This is important as any in-house time-stamping process could be open to challenge or criticism due to its lack of independence or verified accuracy.

How does this work in AIR?

In the AIR platform, when you send a collection task to an asset's responder, the responder will build the collection on the asset in a directory named ‘Cases’. This collection is in a .zip file, with a filename that starts with the date and time of the collection. If you expand the .zip file, you’ll note that the collected data has been added while maintaining the directory tree structure. This is good news if you want or need to further investigate the collection in other forensic solutions.

At the root of the collection shown above, you can see the Case.ppc file. This is another .zip container, and if you expand this, you can inspect the contents.

The hash values for the collected files are available in the Investigation Hub, from where they can be exported as a .csv file:

With AIR, RFC 3161 timestamping is enabled by default. This means the hash value of your collection. ppc file is sent to the TSA, and their TST response is automatically saved as metadata for that collection in the AIR console. You can download and verify the TST from here at any time you or others need to.

You can also disable the RFC3161 Timestamping functionality at any time via the AIR Settings > Features page.

How to verify the .ppc via the RFC 3161 Timestamp Token

To verify the .ppc via RFC 3161, the first step is to download the TST from the metadata button in the AIR asset details > Task tab (as shown in the screenshot above, labeled "Metadata button reveals RFC 3161 download").

In the example below we have changed the name of the TST to ‘RFC3161 timestamp.tsr’ and saved it to the downloads folder.

We can then open a shell session and change the directory to the downloads folder.

To see the information in the TST Run: openssl ts -reply -in RFC3161\ timestamp.tsr -token_in -token_out -text and in the output, you’ll see the hash of your .ppc and the Timestamp

To verify this TST, we now need to download the root certificate from a TSA: https://cacerts.XXXX.com/XXXXtAssuredIDRootCA.crt.pem.

We will also need the following TSA certificates from the TSA server to build a ‘chain certificate’. In this case, I took the content of each .cer file, in the order shown, and concatenated them into one file that I named ‘CHAIN.pem’.

TSACertificate.cer

XXXXTrustedG4RSA4096SHA256TimeStampingCA.cer

XXXXTrustedRootG4.cer

With all these files remaining in the same directory, I then ran the following command to verify the TST: openssl ts -verify -CAfile XXXXAssuredIDRootCA.crt.pem -untrusted CHAIN.pem -data TASK.ppc -in RFC3161\ timestamp.tsr -token_in

This simple verification ‘ok’ message confirms that the TST is correct, indicating that my data is sound and that it existed at the date and time shown by the timestamp

Conclusion - Robust best practice

Thanks to the RFC 3161 and SHA-256 hashing features of AIR, it’s now possible to prove that not only is your data content 100% intact but that it existed at a particular moment in time. So we can now be sure that we know exactly what was collected and when it was collected. In short, RFC 3161 provides immutable timestamping for an effective chain of custody to maintain forensic integrity.