Chain Of Custody in AIR

At Binalyze we use SHA-256 to hash all of the files collected by Binalyze AIR and then we take this to the next level. We do this by further hashing our .ppc collection file and having that value sent 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.

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

Trust in RFC 3161

Requests For Comment (RFC) is a system that has been adopted as the official documentation of Internet specifications, communications protocols, procedures, and events. Originally used to record the unofficial notes concerned with 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 have to go through a review and revision process, overseen by several groups such as the Internet Engineering Task Force (IETF), which is a large open international community of network designers, operators, vendors, and researchers. As part of their collective role, they review the evolution of everything concerned with the evolution of internet architecture and the smooth operation of the internet. A list of RFC3161 compliant TSAs can be found here. When choosing TSAs users may want to consider if 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 be used to verify both the content of the collection along with the date and time that 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 Binalyze AIR?

In the AIR platform, when you send a collection task to an endpoint agent, the agent will build the collection on the endpoint 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. Here, you'll also note the presence of the Hashes.csv which records all of the hashes of the collected files.

So when AIR hashes the .ppc file it is of course hashing all of the hash values collected as part of that Hashes.csv file. This means that changing any of the content or the .ppc file would result in a mismatched hash.

With Binalyze AIR, RFC3161 timestamping is on 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 anytime 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 thing you need to do is to download the TST from the metadata button in the AIR endpoint details > Task tab (as shown in the screenshot above labeled: Metadata button reveals RFC 3161 download).

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

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

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.