Connecting encrypted TrueCrypt containers using a USB drive

Greetings to all Habrozhiteley! In this article I want to share with you my work on the automatic connection of encrypted containers using any USB drive used as a key file.



According to the specifics of my work, I have to use an encrypted container, for this purpose I have already chosen the well-known tool called TrueCrypt for all of us.



In my case, the encrypted container is connected after selecting the drive letter, the key file and entering the correct password, all this is done through the GUI interface of TrueCrypt itself. I felt the minus of this method literally right away, a lot of time is lost on connecting, every time you leave the workplace, you have to disconnect the container, then, on return, you have to re-do the same routine manipulations. And so several times a day. I put up with it for about a month, and an idea appeared - to connect an automatically encrypted container using an attached USB drive.



Different tokens / rutokens were not taken into account, it was decided to connect the container using an attached USB drive, which would act as a key file.

')

What ultimately had to happen:



1. Of course, software development for all of this.

2. The program should always be in RAM and check USB devices for the presence of a valid USB drive.

3. Valid USB drive is pre-attached to an encrypted container.

4. In the event that the attached USB drive is considered valid, then without further questions, etc. connects an encrypted container.

5. In the case of removing the attached USB drive, the encrypted container is disabled.



To solve this problem, the AutoIT programming language was chosen.



What came out of all this:



It turned out what was intended. Let the points:



1. Configure the configurator to meet our requirements:



$flash = "E:" ; USB ,

$passwd = "Pa$$w0rd" ;

$path = "c:\windows\storage.tc" ;

$mount = "R:" ;

$key = "0x1234Af3d21" ; , . , .



Configurator source code.



#include <md5.au3> ; md5

#include <string.au3> ;



AutoItSetOption ("TrayIconHide", 1 ) ;

AutoItSetOption ("TrayIconDebug", 1 ) ;



$flash = "E:" ;

$passwd = "Pa$$w0rd" ; TrueCrypt

$path = "c:\windows\storage.tc" ;

$mount = "R:" ;

$key = "0x1234Af3d21" ;



;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; RC4

; MD5+RC4



$a = _StringEncrypt(1, md5(DriveGetSerial( $flash )),$key,2)

$b = _StringEncrypt(1, $passwd,$key,2)

$c = _StringEncrypt(1, $mount,$key,2)

$d = _StringEncrypt(1, $flash,$key,2)

$e = _StringEncrypt(1, $path,$key,2)



RegWrite("HKCU\Software\USBToken", "Serial", "REG_SZ", $a)

RegWrite("HKCU\Software\USBToken", "Master", "REG_SZ", $b)

RegWrite("HKCU\Software\USBToken", "Mount", "REG_SZ", $c)

RegWrite("HKCU\Software\USBToken", "Flash", "REG_SZ", $d)

RegWrite("HKCU\Software\USBToken", "Path", "REG_SZ", $e)



;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; C -

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

$file = FileOpen("master.key", 2)

FileWrite ($file, _StringEncrypt(1,$a & $b & $c & $d & $e & @ComputerName & @UserName, $key,2))

FileClose($file)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;



2. We launch this case, the configurator writes the necessary values ​​in encrypted form into the registry branch HKCU \ Software \ USBToken (from prying eyes), based on the entered data, a key file is created in the folder with the configurator. With this key file (master.key) we create a new (or configure the old) container + password, in our case it is the $ passwd parameter that matters (Pa $$ w0rd).











3. As a result, we should get a container that would be connected when entering the password Pa $$ w0rd + specifying the key file that our configurator created. After all the manipulations done, delete the key file. Then we pass the baton to the main program.

4. The main program resides in RAM, every 5 seconds it checks connected USB devices, in case a valid USB drive is connected, the program generates a key file in the user's temporary folder, connects an encrypted container, deletes the key file.

5. Upon removal of a valid USB drive, the encrypted container is disabled.



Configuring the main program:



$key = "0x1234Af3d21" ; , -

$truecrypt = "C:\Program Files\TrueCrypt\TrueCrypt.exe" ; TrueCryp $key = "0x1234Af3d21" ; , -

$truecrypt = "C:\Program Files\TrueCrypt\TrueCrypt.exe" ; TrueCryp t



The source code of the main program.



#include <md5.au3> ; md5

#include <constants.au3>

#include <string.au3>



If WinExists(@ScriptName) Then Exit ;

AutoItWinSetTitle(@ScriptName)



AutoItSetOption ("TrayIconHide", 1 ) ;

AutoItSetOption ("TrayIconDebug", 1 )



$key = "0x1234Af3d21" ; , -

$truecrypt = "C:\Program Files\TrueCrypt\TrueCrypt.exe" ; TrueCrypt



$drive = BinaryToString(_StringEncrypt(0,RegRead("HKCU\Software\USBToken","Flash"),$key,2))

$serial = _StringEncrypt(0,RegRead("HKCU\Software\USBToken","Serial"),$key,2)

$passwd = BinaryToString(_StringEncrypt(0,RegRead("HKCU\Software\USBToken","Master"),$key,2))

$path = BinaryToString(_StringEncrypt(0,RegRead("HKCU\Software\USBToken","Path"),$key,2))

$mount = _StringEncrypt(0,RegRead("HKCU\Software\USBToken","Mount"),$key,2)



While 1



if DriveStatus($drive) <> "READY" OR md5(DriveGetSerial($drive)) <> $serial AND DriveStatus($mount) = "READY" then

Run($truecrypt & ' /f /q /d ' & $mount)

endif



if DriveStatus($drive) = "READY" AND md5(DriveGetSerial($drive)) = $serial AND DriveStatus($mount) <> "READY" then



$file = FileOpen(@TempDir & "\master.key", 2)

FileWrite ($file, _StringEncrypt(1,RegRead("HKCU\Software\USBToken","Serial") & RegRead("HKCU\Software\USBToken","Master") & RegRead("HKCU\Software\USBToken","Mount") & RegRead("HKCU\Software\USBToken","Flash") & RegRead("HKCU\Software\USBToken","Path") & @ComputerName & @UserName, $key,2))

FileClose($file)

Run($truecrypt & ' /a /q /s /b /v ' & $path & " /l " & $mount & " /k " & @TempDir & "\master.key" & " /p " & $passwd)

Sleep(2000)

FileDelete(@TempDir & "\master.key")



else

endif

Sleep(5000)

WEnd



Findings:



1. The validity of the USB drive is checked by the hash of the serial number of the USB drive.

2. All data in the registry is encrypted with your key using the RC4 algorithm.

3. The key file is stored only in the program itself and is generated only after the attached USB drive is connected, and then immediately deleted.

4. When removing a valid USB drive, the encrypted container is disabled with the / force option.

5. No extra windows and questions, everything is transparent.



The method is certainly not innovative, but has the right to life. I didn’t strive for versatility and an installer, solutions of this issue by such radical methods will not by itself be suitable for people who shudder from knocking on the door, but are quite acceptable for the ordinary everyday user. To whom it will come in handy, they themselves will easily be able to configure the program for themselves, adding, if desired, autoload and whatever they like. Performance tested on XP and Win7. All that I wanted to achieve, I achieved.



Where there are pluses, there are also minuses. And this is data storage in the registry (albeit in encrypted form), the key file is generated by the program on the hard disk and then deleted. Facts on the face.



So, on this occasion I want to quote the comment roman_pro

Error 1: RC4 streaming algorithm is used repeatedly with the same key. If someone does not know - brief educational program - RC4 generates a pseudo-random gamma based on the key, which is then superimposed on the encrypted data using XOR. Decryption is similar. If the same key is used twice for different data, then making the XOR operation over the encrypted data, we get a stream in which the data on XOR'en among themselves without any influence of the key. If, for some reason, we are aware of the open data and its encrypted version, then it is easy to calculate the gamma and then use it to decrypt the rest of the data. Predictable data in our case Mount, Flash and Path. And if the Path is longer than the Master (i.e., the password is shorter than the path to the container), then using the gamut extracted from the Path it will be possible to decipher the Master. Conclusion: do not use RC4 with the same key more than 1 time.



Error number 2: Binding to the serial number of the flash drive is actually a binding to the serial number of the volume. This is clearly stated in the documentation for AutoIt and this is a common misconception. The serial number of the device is sewn into it, it does not change when formatting. The serial number of the volume changes during formatting and can be easily forged. Conclusion: you need to get the serial number of the iron, not the volume. Your method is fraught with loss of access to the container if you format a USB flash drive due to a change in the serial number of the volume. But everything is not so bad, see the next paragraph.



Error number 3: There are no bindings to the serial number of the volume, there is a banal md5 comparison from the serial number with the previously saved in the registry, but an incorrect serial number does not hurt to generate the correct key - all data for key generation is taken from the registry. It is enough to patch the comparison and the program will stamp the correct key even without a key flash drive. Conclusion: a serial read from a flash drive should be directly involved in generating the correct key, and not a previously saved copy from the registry.



Error number 4: The key is reset to disk in a temporary folder, then deleted. It is enough to select the deletion right for the% TEMP% folder from the current user and our key. About restoring deleted files - keep quiet. I do not understand the desire to throw off the key on the hard disk when there is a “key flash drive”. Where it is more logical to keep the key on it, and there will be no traces of the key on the computer disk. However, the owner is the master as they say.



Total, summing up - this topic is a beautiful story about how to bury safety on the vine with your own hands, replacing it with the classic obscurity. Why in this case TrueCrypt is not at all clear. Almost all the data for opening the container are in the registry and the running program, the flash drive is nothing more than a beautiful toy for a classic if check (password == "mycoolpassword").

The program was written in the Autoit language, the third-party md5.au3 library was used, which must be placed in the Program Files \ Autoit3 \ Include folder (You can download it here ). Thank you all for your attention! Good luck!