Jacob Neplokh - 2020-05-31

Hello everyone,

I am looking for some feedback on a Veracrypt self-destruct script I have been working on which would be incoporated into BusKill. You can find out more at the linked website, but a quick summary is that BusKill is a kill-cord for your laptop, and executes some "trigger" when a USB device is disconnected, such as shutting down the computer to make sure it is encrypted. Therefore, if the laptop is snatched at a coffee shop, it would be shut down, and the data would be encrypted.

In some extreme situations, and indivdual may want to have the data "self-destruct," so:

A) even if the correct passphrase was aquired (legal, coercion, etc.) the encrypted system would simply be corrupt/fail to mount
B) Metadata(/the volume headers) about the encryption would be wiped and provide enough anti-forencsics/plausible deniabilty

Wiping/overwriting all of the data would take too long, especially for a large encrypted system, so instead I designed it to wipe all of the non-data area, using the VeraCrypt Volume Format Specification.

The current version of the code, which can be found here on GitHub, only concerns a single VeraCrypt volume, as I want to make sure the implementation is correct before I move on. Currently, it generates random bytes to overwrite everything until offset byte 131072 (the data area) and then generates another set of random bytes to overwrite everything from S-131072 onwards.

I am aware of the Data Leaks Section but since this would in the end concern system encryption, I do not think it matters as it states system encryption would prevent against them. Someone correct me if I am wrong of course! :)

Another limitation I am aware of/a question is the Unencrypted Data in RAM. Even with the limitations of Microsoft Windows not being able to clear the master keys, if the metadata/volume headers are overwritten, could an attacker still use data stored in the RAM? As some is read into the RAM as descirbed in the Encryption Scheme. Furthermore, would the optional extra protections introduced in version 1.24 combined with the self-destruct script mitigate the attack on retriveing data from the RAM?

The main question, however, is: Does the script's implementation satisfy points A) and B), providing anti-forenciscs/plausible-deniabilty and making the data permanently useless? I already have tested A), and after the script is executed on a volume, it fails to mount and Veracrypt cannot restore it from the backup header, but I want to make sure there is not some other way I missed :) Again, the script currently only targets a single Veracrypt volume, not system encryption, but I do not want to move on right away with serious flaws in the script. The final version will involve system encryption, so if you see a potential flaw there, but not present right now, let me know as well.

Thank you so much for your help with this, it is greatly appreciated!