This project has moved and is read-only. For the latest updates, please go here.

Safety against over-the-shoulder (OTS) and software screen recording attacks: what could be made better with little effort

Topics: Feature Requests, Users Discussion
Mar 16, 2015 at 10:06 AM
Edited Mar 16, 2015 at 10:11 AM
Hi, I was thinking what elements of this system are less safe at workplace or academia, when you would want to avoid anybody gathering ADDITIONAL information, that could make easier future break-in to the system.
  1. First of all, after mounting, the main VeraCrypt dialog box should not display a choice of Encryption Algorithm, partition length and Type (TC, hidden or veracrypt).
    This would also break plausible deniability: your worst 'enemies' - co-workers - may well know you are using encryption software, but how often and using which encryption options - this should not be displayed every time you open VeraCrypt dialog box which you do quite often.
    If we don't do this, then entire point of having A CHOICE of cascades is futile as the probable adversary would know in advance which cascade is being used.
    Another advanced option is to let the user choose algorithm at random from pre-determined list (say Serpent/Twofish/AES+Twofish/AES+Serpent with either SHA512 or Whirlpool which are almost equally fast on benchmark provided that AES is hardware accelerated) and never display him which is being used - not because he cannot measure it but because he might want to not know the exact choice when questioned - this is the whole point of having a selection of algorithms. This of course makes sense only for containers or remote bootloaders, as in case of system partiion the bootloader contains specific code that tells everything. Let's remember VeraCrypt is often used for several containers/partitions and hence the interest of having a mix of algorithms used. Or eventually we can drop most options and stick to 4 options AES/Twofish/Serpent/triple cascade and assume that the adversary will know the exact choice anyway.
  2. Volume Creation Wizard: Volume Format dialog box:
    For the same reason when creating an archive and gathering entropy, salt should no longer be shown after Next has been clicked, when formatting of the new archive already takes place (it could take hours to complete while significant part of salt is still shown).
    Showing any part of random pool should be DISABLED by default.
    Also, in no case Master key should be shown even for 1ms (actually it is just after formatting finishes), unless the user requestes it.
  3. The login process itself is a vulnerable part: you type a password, then wait for 30s while the system is unresponsive and then... voila! a window with new container pops up. You cannot stop that or react for that long timne precisely because of insanely high number iterations, that is not tailored to such working environments not to mention when using several volumes at once. At the same time the system is rather unresponsive to clicking power shutdown. Therefore during every login (and this could take 4 minutes for 8 containers/partitions) you are highly vulnerable.
  4. Length of the password during typing should be obfuscated by default (not visually recognizeable, instead of showing just stars). We are partially defending agains camera/screen grabbing at this point.
Here we return to the basic rule of cyptography: the security is normally based on time ratio between accessing the data knowing the password and not knowing it, not on the duration of entire process.
Suppose it takes 10^8 years to decrypt an obsolete system and 1s to access the data. If we suspect that decryption scheme is breakable, and today it might be needed only 10^2 years to guess the password with 100% chance, it is pontless to multiply processing time by 30 on both ends, obtaining 1sx30=30s login time and 10^2x30=3x10^3 years of cracking time.
The whole point of encryption is that it doesn't really matter if it takes 10^3, 4 5 or 10^ 128 years to crack the password with 100% chance unsing entire energy of the sun, the system remains as secure as energetic balance of our galaxy permits.
At the same time long login time is a vulnerability to OTS 'attacks' which are already hard to mitigate in certain environments, and even dangerous in case of computer being left behing in that process.
Mar 18, 2015 at 8:14 AM
Edited Mar 18, 2015 at 8:15 AM

Thank you very much for this comprehensive post. I'll definitely take into account many of the ideas presented.
One of the planned modification is the creation of a new GUI for VeraCrypt where many current aspects will be removed and simplified, and in this context, removing unnecessary information from the display.

Your security estimation model is also interesting and it is partially compatible with the planned modification to introduce a dynamic mode which uses 2-dimensional model (password, iteration) instead of the 1-dimentional one based solely on iterations (first time introduced here, also discussed here). Thanks to this, users with long password can dramatically reduce mounting times but it will remain the responsibility of the user to choose real strong and long passwords and not simple patterns to "fool" VeraCrypt.

I'll keep this post updated with the modifications done to address the issues your raise.
Mar 18, 2015 at 8:34 PM
> Showing any part of random pool should be DISABLED by default.
Also, in no case Master key should be shown even for 1ms (actually it is just after formatting finishes), unless the user requestes it.
Totally agree !.
Mar 19, 2015 at 2:51 PM
Edited Mar 19, 2015 at 11:37 PM
I think this MAY be useful for some people BUT it should be OPTIONAL to hide all this info. I like to choose the exact encryption algorithm and hashing algorithm and like to be informed on what's going on 'behind' (like the random salt etc.). Not everybody is using this software at workspace. Without the PW the info of the used algorithms are useless. And with the PW a unknowingness of the used algorithms isn't a protection.
Mar 20, 2015 at 6:14 AM
Edited Mar 20, 2015 at 6:29 AM
We are not talking only about real workplace here, but rather about equivalent environment which is: 'is my PC already infested with a screen grabber that my firewalls will be defending against tomorrow'. Another point about security by obscurity: if we assume that we are not using the fact of having multiple encryption cascades available as additional security measure (doing so would require keeping cascade selection confidential by default), why do we have options like serpent/twofish/aes and aes/twofish/serpent which add nothing one vs each other except that one of them might one day be broken in the same style as heartbleed SSL bug, and due to overly extensive code the community will not notice until too late. Take a look at Diskryptor where only a subsed of Truecrypt cascades is left, but the routines are optimized.
Please remember that besides theoretical principles, the reality is, that:
-most of wannabe bruteforcing codes for TC support only non-cascading algo
-apparently almost all of them do not support keyfiles
(this is based on a simple search across forums, one day only)
This simple observation shows part of the bigger image, that is, even when really powerful opponent attacks an archive, he may or may not be able to upload and try all possible scenarios of VC repositories to his most recent and most powerful cloud just because it is too expensive to cover all implementation cases. From this point of view all those tricks that force the enemy to explore all implementation paths are worth considering - but then, some measures shoudl be taken to not reveal those selection paths taken by the user.