Does VeraCrypt record an accurate creation date in the file system metadata?

[Bananabread]

When a file system is created, the operating system would normally record the creation date in the metadata/volume information for that file system. Even for Fat32 I believe it can be extracted from the file system serial number. I'm concerned about a scenario where:

1. The date a hard drive was purchased can be determined from the hardware serial number.
2. The outer volume file system shows a creation date the same day the device was purchased.
3. The outer volume file system is pristine indicating it has never been written to.
4. The SMART data for the device shows terabytes of data have been read/written and the power on hours are in the thousands.

Under this scenario it could be strongly inferred that a hidden volume exists. Is this something to be concerned about or does VeraCrypt handle this somehow?

[Mounir IDRASSI]

Good question. This class of concern is real, but it's not a VeraCrypt metadata bug.

VeraCrypt itself doesn't store a creation date in the VeraCrypt volume header. For FAT/FAT32 volumes formatted by VeraCrypt, the volume serial/ID is generated randomly, so it's not derived from the current date/time. For NTFS, exFAT and ReFS, VeraCrypt delegates filesystem creation to the operating system formatter, so any filesystem creation timestamp or similar metadata is whatever Windows writes during formatting.

The "Preserve modification timestamp" option only concerns the host container file timestamp when a file container is used. It doesn't rewrite metadata inside the encrypted filesystem.

The real issue in your scenario is the combination of signals: a pristine outer volume together with external device telemetry showing heavy use. That doesn't prove that a hidden volume exists, but it can raise suspicion. Plausible deniability means that an adversary shouldn't be able to prove the existence of a hidden volume, not that no suspicion can ever be formed.

These concerns are already covered in the documentation, although not with this exact SMART-example wording:

• Hidden Volume: the documentation says that, before creating the hidden volume, the outer volume should contain sensitive-looking files that you don't actually want to hide: https://veracrypt.jp/en/Hidden%20Volume.html

• Security Requirements and Precautions Pertaining to Hidden Volumes: the documentation warns that if a device/filesystem records timers, counters, write/read history, wear information, or similar metadata, hidden volumes shouldn't be stored on such devices/filesystems: https://veracrypt.jp/en/Security%20Requirements%20for%20Hidden%20Volumes.html

• Wear-Leveling: the documentation also states that if plausible deniability is needed, VeraCrypt shouldn't be used on devices or filesystems using wear-leveling mechanisms: https://veracrypt.jp/en/Wear-Leveling.html

• Known Issues and Limitations: the documentation notes that timestamp preservation is not guaranteed because of filesystem journals, file attribute timestamps, and OS behavior: https://veracrypt.jp/en/Issues%20and%20Limitations.html

SMART/NVMe counters, power-on hours, wear indicators, and similar firmware-level data are outside VeraCrypt control. Software cannot reliably hide or reset them.

So the practical answer is: don't leave the outer volume pristine, use realistic decoy content, and after the hidden volume exists, write to the outer volume only with hidden volume protection enabled. For threat models where hardware telemetry is available to an adversary, hidden volumes on such media carry residual risk, and the documentation already advises against using hidden volumes on devices that keep such counters or wear/history information.