Trusted Timestamping
Forensic Email Collector can connect to an RFC 3161-compliant Time Stamp Authority (TSA) server and have its acquisition logs automatically timestamped.
Setting Up Trusted Timestamping
In order to activate trusted timestamping, a TSA URL must be entered in FEC's preferences page as shown below:
If your TSA requires authentication (this would typically apply to paid services), you can enter your credentials in the TSA Username and TSA Password fields. Otherwise, these two fields should be left blank.
Once you enter a valid TSA URL, you can validate that timestamping works as expected by using the Validate... hyperlink below the TSA URL textbox.
Example TSA URLs
We have tested FEC's timestamping operation with the following TSA URLs:
Certum — http://time.certum.pl
DigiStamp — https://www.digistamp.com/tsa (paid service; requires a username and password)
You can find a list of TSAs below:
List of free rfc3161 servers. (github.com)
What to Look for in a TSA
For trusted timestamping to be useful, it should be performed by a trusted organization over which the end-user has no control. Some criteria you may want to consider when choosing a TSA are whether or not the TSA is eIDAS qualified and/or on the Adobe Approved Trust List (AATL).
Performing Trusted Timestamping
Once the TSA configuration is complete, you can activate trusted timestamping for each acquisition on FEC's output settings as shown below:
This will cause FEC to compress the contents of the "Logs" folder at the end of each acquisition session and have the resultant ZIP timestamped. Timestamping output would look as follows:
<Acquisition Project Root>
\Items
\Logs
Logs_2021-08-13_12.06.05.790.zip Contents of the Logs folder as of when the corresponding acquisition session ended
Logs_2021-08-13_12.06.05.790.zip.tsq The timestamping query for this ZIP file
Logs_2021-08-13_12.06.05.790.zip.tsr The timestamping response for this ZIP file
Note: If your acquisition contains multiple sessions (i.e., the same project was re-opened and manually resumed multiple times), you would find multiple sets of timestamped logs—one that corresponds to the state of the logs at the end of each acquisition session.
Why Do We Timestamp The Logs?
Trusted timestamping is an expensive operation and is heavily throttled by most TSAs. Therefore, it would not be feasible to have every file that FEC acquires timestamped. We feel that the contents of the "Logs" folder is a great timestamping target for the following reasons:
- The logs are typically not very voluminous—at least when compared to the acquired data—and therefore compressing them can be accomplished very quickly and with little additional disk space.
- The logs contain hashes of each acquired file, including those of output PSTs and Drive attachments / revisions. Timestamping the logs shows that the files had already been acquired and hashed at the time of trusted timestamping.
- FEC's logs also contain additional data points that may benefit from trusted timestamping. For instance, inbox rules / filters, UID gaps observed on IMAP servers, decoded Gmail Message ID and Thread ID timestamps, etc.
What Is Sent to The TSA?
When performing trusted timestamping, FEC sends the SHA-256 hash of the timestamped file to the TSA, not the file itself. In other words, the actual contents of your "Logs" folder are not sent to a third-party.
Verification of Trusted Timestamps
The trusted timestamps that FEC creates can be verified using external tools that support RFC 3161 as well as FEC itself.
Verification Using FEC
1. Open the timestamp verification page in FEC as shown below
2. Drag and drop the files needed for verification. In this case, the following files are needed:
- cacert.pem (CA certificate of the TSA — can be obtained from the TSA)
- Logs_2021-08-12_10.23.29.962.zip (Timestamped file)
- Logs_2021-08-12_10.23.29.962.zip.tsq (Timestamp query)
- Logs_2021-08-12_10.23.29.962.zip.tsr (Timestamp response)
3. FEC validates the trusted timestamp and reports its findings as shown below:
In this case, the "The root certificate in the chain is not trusted on this device, but it matches the supplied CA certificate." message indicates that the certificate authority that freeTSA used is not trusted on the computer where we performed the verification, and verification was only possible because we supplied freeTSA's CA certificate as a trusted certificate. ( see -CAfile option in OpenSSL below).
On the other hand, a timestamp response from a TSA whose CA is trusted on the verifying computer can be verified without a CA certificate. The verification result would look as follows:
The above verification was achieved by dragging and dropping only three files onto FEC: "Logs_2021-08-13_12.06.05.790.zip", "Logs_2021-08-13_12.06.05.790.zip.tsq", and "Logs_2021-08-13_12.06.05.790.zip.tsr". This was possible because the CA used by Globalsign's TSA was already trusted on the computer where we performed the verification.
Important Note: Even if you do not need the CA certificate to perform verification, we recommend that you obtain and retain a copy of the CA certificate for future reference as the trusted timestamp may need to be verified by another party whose devices do not trust the CA certificate.
Verification Using OpenSSL
Timestamps in the above example can be verified using OpenSSL as follows:
Step 1 — View the timestamp and file hash
openssl ts -reply -in "Logs_2021-08-12_10.23.29.962.zip.tsr" -text
Note the value shown next to the " Time stamp:" field as well as the "Message data". Message data is the SHA-256 hash of the file that was timestamped.
Step 2 — Verify that the hashes match
Manually hash the timestamped file ("Logs_2021-08-13_12.06.05.790.zip" in this case), and verify that its hash matches the hash reported by OpenSSL. If the hashes do not match, the trusted timestamp does not belong to the copy of the file you are verifying and verification failed.
Step 3 — Have the timestamp verified
openssl ts -verify -in "Logs_2021-08-12_10.23.29.962.zip.tsr" -queryfile "Logs_2021-08-12_10.23.29.962.zip.tsq" -CAfile cacert.pem
The -CAfile switch allows you to input multiple certificates in PEM format concatenated together. You would typically need the certificate of your TSA's certificate authority (CA). For instance, freeTSA makes this available as "Freetsa CA Certificate". DigiStamp also provides both their current and historical certificates as well as an explanation of the chain of trust below:
Timestamp Public Key Certificates :: DigiStamp
When working with DigiStamp, you would need the file identified as "DigiStamp Root CA Certificate (ECC-NIST)".