Repository navigation
Option to prevent disabling "Clear encryption keys from memory if a new device is inserted" until next reboot #1982
Description
Currently, the setting "Clear encryption keys from memory if a new device is inserted" (VC_DRIVER_CONFIG_CLEAR_KEYS_ON_NEW_DEVICE_INSERTION) can be disabled on the fly via Settings -> System Encryption... without requiring a system reboot or master password entry.
If an adversary seizes an unlocked machine (live forensics scenario) and is aware of this VeraCrypt feature, they can simply open VeraCrypt System Settings, uncheck "Clear encryption keys from memory if a new device is inserted", click OK, and then safely plug in a forensic USB drive to dump RAM without triggering VC_IOCTL_EMERGENCY_CLEAR_ALL_KEYS. If RAM key encryption is disabled, this possibility is more dangerous, but in my opinion this possibility is unsafe in any case.
Desired behavior
Add a sub-option (or make it default behavior): "Lock this setting until next reboot" (One-way latch in veracrypt.sys).
Once enabled in the current session, the driver should reject any IOCTL calls attempting to clear the VC_DRIVER_CONFIG_CLEAR_KEYS_ON_NEW_DEVICE_INSERTION flag in memory until the system is rebooted (or require the VeraCrypt system master password to disarm it).
Activity
Windows: allow keeping key clearing on device insertion enabled until…
Unix: unmount all volumes when a new USB or Thunderbolt device is con…
amdigyira commentedon Nov 2, 2026
Thank you @flatstik for implementing this so quickly in #1983!
Regarding the limitation noted in the documentation and prompt:
Could we close this gap as well by making the locked state fail-closed if the service process is unexpectedly terminated?
Proposed mechanism (Dead Man's Switch on Service Handle):
Currently,
VeraCryptSystemFavoritesignoresSERVICE_CONTROL_STOPwhen locked and only stops onSERVICE_CONTROL_PRESHUTDOWN. However, an admin on an unlocked machine can still kill the user-mode service viaTerminateProcess(taskkill /F), silently disarming device arrival monitoring.To prevent this without moving PnP monitoring entirely into kernel mode:
VC_IOCTL_LOCK_CLEAR_KEYS_ON_NEW_DEVICE_INSERTIONis called,VeraCryptSystemFavoriteskeeps itshDriverhandle open (or opens a dedicated watchdog handle toveracrypt.sys) for the lifetime of the service.SERVICE_CONTROL_PRESHUTDOWN, it sends a clean disarm/shutdown notification IOCTL toveracrypt.sysbefore exiting.TerminateProcess), the Windows kernel automatically closes all handles owned by the process, triggeringIRP_MJ_CLEANUP/IRP_MJ_CLOSEinveracrypt.sys.veracrypt.sysreceivesIRP_MJ_CLEANUPon that watchdog handle whileIsClearKeysOnNewDeviceInsertionLockedis active (and without a priorPRESHUTDOWNnotification), the driver treats the unexpected termination of the service as tampering and immediately callsVC_IOCTL_EMERGENCY_CLEAR_ALL_KEYS.Alternatively,
veracrypt.syscould register a kernel-mode PnP notification directly viaIoRegisterPlugPlayNotificationwhen the lock is engaged, removing the reliance on the user-mode service staying alive.What do you think? This would make the lock completely tamper-proof even in an unlocked admin session.
flatstik commentedon Nov 2, 2026
I'd rather wait @idrassi's opinions and comments before pushing any more further :)
Windows: allow keeping key clearing on device insertion enabled until…
Unix: unmount all volumes when a new USB or Thunderbolt device is con…
amdigyira commentedon Nov 2, 2026
I hope you don't mind that I partially conveyed my thoughts through AI, as my English isn't perfect. I also hope everything was clear. I often think about security like a paranoid person and try to think of all sorts of loopholes in feautures what I use personally. I could also translate this and some other commits (which I understand) into Russian for better localization. And also thank you @flatstik thank you for your contribution. It's so nice when ideas are implemented so quickly. <3
Windows: allow keeping key clearing on device insertion enabled until…
Unix: unmount all volumes when a new USB or Thunderbolt device is con…