Lazybit

A new stable beta version of Private Disk 2.10 has been made public, it can be downloaded.

Here are some of the highlights:

• A much more flexible Disk Firewall;
• A more secure Disk Firewall;
• An easier way to change passwords;
• Faster disk creation speeds (when the disk is filled with random data for more security);
• Ability to run as a service;

A lot of changes were made under the hood, being related to how Disk Firewall works. Graphically, the changes are represented by two new checkboxes:

Disk Firewall now includes a training mode, which makes it easier to configure this mechanism. From now on you don't have to manually indicate paths and figure out which programs should be allowed to access your encrypted data, and which ones not. Just enable the training mode and keep using your software as you normally do. Whenever an application attempts to access the drive, something like this shows up:

At this point you can see which program wants to access the disk, and decide whether you want to allow this or reject the attempt. The program's path is shown too, and so is the program's icon - now it's easier to get things figured out without doing any further research.

Another change is the ability to verify the integrity of a trusted program. For example, Explorer.exe was allowed to access the virtual encrypted disk; but what if the program was infected with a virus? Since it is trusted, it will be able to access the data, and there is a chance that data loss will occur. That's not the case anymore. Disk Firewall verifies the integrity of the program when it is added to the white list and "takes its fingerprint". When the program wants to access a protected file, its fingerprint is compared to the original one, and if they don't match:

You're notified about a change in the trusted program. If you're aware of any updates of this program, or if you modified it yourself - you can allow this change. Otherwise you can click Deny and check the program with an antivirus to see if everything is OK with it.

The program's integrity is verified with Dekart's NIST-certified implementation of AES-256.

You might ask why an encryption algorithm is used to verify a program's integrity, rather than a hashing algorithm. The program that accesses the disk is encrypted with AES-256 in CBC mode; at the last step of encryption, a 256-bit long chunk is obtained and memorized. Afterwards when the program tries to access the disk, it is encrypted again and the last 256-bit chunk is compared to the original one.

The encryption key is individual to each encrypted disk, so even if the same program is a trusted one for multiple virtual disks, it will have different 'fingerprints' for each case; while a hashing function would generate the same 'fingerprint'. Now, picture a hypothetical case in which someone manages to find a collision and modify a program's code in a malicious way, without changing its hash - if this were true, the now malicious program would be able to compromise all your encrypted disks, which is very bad, to say the least... Our approach is immune to such attacks.

Other changes will be commented later.