Clear encryption keys from memory if device is inserted - Issue

[Mikael]

@idrassi I want to report a issue that I think has been reported before either here or on github however I can't find it. I've got this issue on both the latest windows 10 22H2 and windows 11 22H2, it's also possible that other versions of these operative systems are affected. When you enable the erase keys if USB device is inserted the computer will automatically get BSOD after a while without inserting any USB device into the computer. I belive this is a long standing issue that has been around for a while and should be adressed in 1.26 if possible.

[Enigma2Illusion]

@sorrow1

If I remember correctly, you must be using VeraCrypt system encryption and re-enable the option each time you boot your PC.

Is that correct?

You must have all the encrypted devices already connected, otherwise it appears from Mounir's explanation that you will trigger the wipe keys which will cause BSOD.

Possible Cause 1: USB and/.or Drive Sleep Settings

See the thread below to see if you have your USB ports to power down until needed might be triggering the BSOD during a wake event.

https://sourceforge.net/p/veracrypt/discussion/technical/thread/398ad0319d/?limit=25#ab41

Another possibility are some external HDD have internal power sleep mode due to inactivity. I am wondering if the waking-up of the external devices might be triggering VeraCrypt to wipe the system encryption keys which always leads to BSOD.

Possible Cause 2: Virtual Device

Another possibility as noted in an old ticket is a virtual device insertion that is wrongly detected as physical device.

https://github.com/veracrypt/VeraCrypt/issues/684

[Mounir IDRASSI]

This is indeed a long running issue. I do remember reproducing a similar problem once when Windows Update was running the background: possibly Windows Update disconnected a USB device and then reconnecting it again, which triggered the device insertion detection mechanism.

I will try to reproduce it again on my Windows 11 machine and if I find a reliable scenarion, then I will run a modified version of VeraCrypt to only log the insertion event with details without clearing the keys. This will give me some hints about what's going on.

As for the code that handles ths part, it is not very long:

    case SERVICE_CONTROL_DEVICEEVENT:
        if (DBT_DEVICEARRIVAL == dwEventType)
        {
            DEV_BROADCAST_HDR* pHdr = (DEV_BROADCAST_HDR *) lpEventData;
            if (pHdr->dbch_devicetype != DBT_DEVTYP_VOLUME &&  pHdr->dbch_devicetype != DBT_DEVTYP_HANDLE)          
            {
                if (ReadDriverConfigurationFlags() & VC_DRIVER_CONFIG_CLEAR_KEYS_ON_NEW_DEVICE_INSERTION)
                {
                    BOOL bClearKeys = TRUE;
                    SystemFavoritesServiceLogInfo (L"SERVICE_CONTROL_DEVICEEVENT - DBT_DEVICEARRIVAL received");
                    if (pHdr->dbch_devicetype == DBT_DEVTYP_DEVICEINTERFACE)
                    {
                        DEV_BROADCAST_DEVICEINTERFACE* pInf = (DEV_BROADCAST_DEVICEINTERFACE*) pHdr;

                        if (IsEqualGUID (pInf->dbcc_classguid, OCL_GUID_DEVCLASS_SOFTWARECOMPONENT)
                            || IsEqualGUID (pInf->dbcc_classguid, GUID_DEVCLASS_VOLUME)
                            || IsEqualGUID (pInf->dbcc_classguid, GUID_DEVCLASS_VOLUMESNAPSHOT)
                            )
                        {
                            bClearKeys = FALSE;
                        }
                    }

                    if (bClearKeys)
                    {
                        DWORD cbBytesReturned = 0;
                        DeviceIoControl (hDriver, VC_IOCTL_EMERGENCY_CLEAR_ALL_KEYS, NULL, 0, NULL, 0, &cbBytesReturned, NULL);
                    }
                }
            }
        }
        break;

I'm using a GUID mechanism to filter out some harmless device types and maybe I should increase this list of GUIDs.

With all the ongoing tasks, I cannot guarantee when I will be able to solve this.

[Mounir IDRASSI]

I have done a 1 day test on a Windows 11 22H2 laptop where I changed VeraCrypt to only trace insertion event without actually clearing keys and I was able to reproduce the issue several times in the day.

From the information I gathered, the issue is caused by power saving feature of Windows that disconnects several devices during inactivity periods and then connects them back when user resumes working on the machine. In my case, the devices affected were:

• internal audio devices
• fingerprint device
• internal webcam
• touchpad
• some software based virtual devices

based on the observed behavior and the data I gathered, the only solution I see is the following:

• when the user enables "Clear encryption keys from memory if device is inserted", we create a list of all currently inserted devices, identifying each one of them using its "DeviceID".
• We we receive a device insertion notification, we compute the "DeviceID" of the inserted device using the dbcc_name field of the structure DEV_BROADCAST_DEVICEINTERFACE and we look for this DeviceID in the list we created previously:
  • If the device is found, then we ignore this event
  • if the device is not found, then this is an unknown new device and so we trigger clearing of encryption keys.

This approach is not as strict as the original one but this is the only way to avoid false positive detections. From security point of view, the only risk is that an attacker will remove an existing device from the machine and then insert a similar one with modification to allow dumping RAM or runing code by lavereging some unknown vulnerability in an existing Windows driver: this looks difficult to achieve but I cannot say it is impossible.

I will work on implementing this new approach and I will add an option to allow selecting between strict mode that we have today and a stable mode based on this new approach.

[Enigma2Illusion]

Hi @idrassi

when the user enables "Clear encryption keys from memory if device is inserted", we create a list of all currently inserted devices, identifying each one of them using its "DeviceID".

Is it a requirement that the VeraCrypt user enable this setting immediately after PC boot-up, reboot or resume sleep mode in order to get all the connected devices?

If yes, should a message box be displayed stating this requirement to the user in order to prevent false positive device detections?

[Mounir IDRASSI]

@enigma2illusion : No need to enable it immediately after boot. Once this option is enabled, VeraCrypt will create a liste of currently connected devices. Any device not connected when the option is enable will be considered unknow if it is plugged in afterwards and so it will trigger clearing of encryption keys.

[hiddengod]

you can trace event id of new hardware being inserted, there are 2-3 event ids that are logged only when a new device is connected, this should avoid easily bsod in existing devices.

[Mounir IDRASSI]

@hiddengod : Thank you for your suggestion. However, VeraCrypt operates at a lower level in the operating system than the Event Viewer logs. Our implementation needs to be directly tied to hardware events and the actual device notification system provided by the OS. Moreover, there are a few issues with relying on Event Viewer logs:

• The logs you're referring to provide human-readable interpretations of the activities occurring at the hardware level. They're not direct representations of the hardware events themselves, which are critical for our use case.
• Parsing Event Viewer logs could introduce a degree of unreliability, especially since there is no official, documented correlation between the number of events and whether a device has been recognized before.
• Monitoring Event Viewer logs could potentially induce unnecessary system overhead.

The solution that I proposed, utilizing the DeviceID, offers a more direct, efficient, and reliable approach. The DeviceID is a documented part of the Windows Device Model, and it is meant to uniquely identify a device in the system. You can find more about this in the Microsoft documentation. Notably, a DeviceID is persistent across system restarts.

This provides a robust mechanism to accurately track devices that are currently connected to the system when the option to clear encryption keys is enabled. With this information, we can distinguish between devices that were already present (and thus should not trigger a key clearing) and truly new devices that could potentially pose a risk.

[Mounir IDRASSI]

Just to mention that I have implemented the new DeviceID approach and my tests show that it works properly: https://sourceforge.net/p/veracrypt/code/ci/c73654b18e9f8dc7c553dea36f157360d3e52735/

I will not add the option to switch to the old way of doing things because it causes false positive detection in most cases and so it is not usable anymore.

I'm planning to publish a new beta in the coming days so that it can be tested by others.

[hiddengod]

An optional checkbox to make the option persistent on reboot would be great.
But as a fail safe it should get disabled when a new device is inserted, just before the bsod.
When all good and no trigger, should be able to stay turned on.

[Mounir IDRASSI]

I understand the reasoning behind the persistence feature, but its practical implementation poses challenges. One of the primary concerns, as you already know, is the issue of false positive detections. Given that VeraCrypt doesn't have control over the timing of internal device insertions by Windows, persistent monitoring without proper safeguards could lead to frequent and disruptive BSODs.

This is where your proposed failsafe mechanism based on an "all is good" status comes into play. However, pinpointing when "all is good" is challenging. How do we program VeraCrypt to accurately judge the right duration or set the criteria to ascertain system stability? Setting a predefined duration runs the risk of being arbitrary and may not be a one-size-fits-all solution for diverse user scenarios.

To be honnest, the safeguards you propose closely resemble the workings of an AI system—one that learns the usage patterns of a machine and autonomously determines criteria to detect suspicious device insertion. Incorporating such a sophisticated mechanism within VeraCrypt goes beyond its design goals. Personally, I prioritize giving users direct control over the feature's activation rather than automating responses based on assumed patterns.

[Mounir IDRASSI]

@sorrow1 : I have uploaded to Nightly Builds folder the installers for 1.26.5 version that includes the new mechanism for device detection. If possible, give it a try and let me know your feedback.

[Mikael]

@idrassi Thank you so much for your hard work Mounir! I will try it for sure and report back! The old implementation was more or less unusable due to constant BSOD. I want to ask you why this functionality is not available on Linux/Mac?

@enigma2illusion Thanks for finding the old report about this issue on github it was actually me who reported it long time back but forgot about it.

[Mikael]

@idrassi I've used it for most of the day and it works flawlessly. I will let you know if I encounter any issues but so far so good! Once again thank you for all of your hard work Mounir.

[Mounir IDRASSI]

Thank you @sorrow1 for taking the time to test the new implementation and sharing your feedback. I'm glad to hear that it's working smoothly! Your input is invaluable to the continued improvement of VeraCrypt.