Help Create Join Login. Application Development. IT Management. Project Management. Resources Blog Articles. Menu Help Create Join Login. VeraCrypt Open source disk encryption with strong security for the Paranoid Brought to you by: idrassi.
Get project updates , sponsored content from our select partners, and more. Full Name. Phone Number. Job Title.
Even though you don't have much battery left, you can still have encryption, encrypt keys in RAM. You'd just have to start up your system cold at your destination, no hibernate, no sleep. Who knows what other problems can occur on old hardware like mine. The alternative approach as in the quote below needs a live environment that can run both Veracrypt and a backup tool like Macrium together.
Then it's just a case of I hope following the regular Macrium procedure where you're just copying files between two mounted Veracrypt volumes. As far as I know only Hiren's boot CD can accomplish this or can it. I'm perennially in doubt. The documentation says Another possibility is to change the link in the "menu. Again it assumes the average user knows. Sadly, there are no dummy Rescue ISOs to work with so we can try for ourselves. Google can't always come to our rescue you see.
I've used Macrium Reflect inside Windows and booted off the Macrium reflect rescue media for images making and restoring, and also have used Clonezilla, so I think your fears are unfounded. I have to take the plunge and see for myself I guess. Good to know hiddengod 's workaround does work. A big thanks to him. And just for confirmation, I've read that an image restore from an Veracrypt Encrypted Macrium image is still unencrypted.
Isn't that a security hole because there's nothing preventing someone from restoring my Macrium image as though it was unencrypted to start with. I know I've overlooked something glaringly obvious. Have always been embarrassed to ask this :P. Forget about using Macrium, then. Use Clonezilla. They have recently added support for Veracrypt-encrypted systems. You can use Clonezilla while you're fooling around with Macrium to see what it does. I think you are not really listening to what I'm saying about Macrium.
If someone uses Macrium inside Windows, while Windows is running, after they have entered the Veracrypt password, then yes, it will be an unencrypted image. However, if you use the Macrium rescue disk and boot from that, you won't be entering your Veracrypt password, and then your system will be encrypted. But, maybe I'm wrong, but I don't think so.
Regarding the security hole of the unencrypted Macrium backup, the glaringly obvious something that you overlooked is that before backing up your system to your external HDD, you'll create an encrypted partition or container on that drive to serve as the target storage location for your backups.
So even though your Macrium backup files made with the free version have no internal encryption, storing them on an encrypted medium keeps them no less safe. You can easily make your own once you have the VeraCrypt program installed on your computer. Even though you may not be ready to encrypt your system, pretend that you are and go through the process.
After you've set up your options but before encryption begins , VeraCrypt will make your rescue. Once that is done, you can cancel encryption and play around with the rescue disk all you want, including installing and testing it on your Easy2Boot menu. Just keep in mind that this rescue disk will be invalid and superceded by the next rescue disk when you actually complete the system encryption process. DDD I am listening, trust me. May be the misunderstanding's to do with my nonnative English.
And, yes I am reading up on Clonezilla and will see if I can explore that. Gary Marks I like how you had a dig at me and the irony of it. I'll just laugh aside your condescension. That's helpful and not so obvious to the risk averse. I don't want this to be a Merry go round. But one final attempt at clearing up my predicament with your advice which is exactly what the Veracrypt documentation says.
Or may be it implicitly suggests we use something like Robocopy to do a regular file system copy. The upside to this method is you can do incremental backups which is not the case with Forensic imaging. I merely attempted to say that the security hole you correctly identified with Macrium images because, as you said, "there's nothing preventing someone from restoring my Macrium image as though it was unencrypted to start with" is entirely preventable if you simply back up to an encrypted medium.
That's what I've been doing for years. A backup made by Macrium from within Windows is unencrypted even though the system is encrypted by VeraCrypt.
That backup can then be restored or mounted without restoration by anyone with access to the file, so you simply need to store that file in an encrypted partition or container, closing that security hole. No dig, no condescension, just intended clarity and the solution I use. Sorry I wasn't clearer with my clarity. As for making offline backups after booting from WinPE, I've always considered that a poor choice except when you need a forensic copy of a nonbootable system.
A hot backup is much quicker and smaller, and doesn't require rebooting. But now I really feel like a dunce after hearing you've been saving your backups to an encrypted Veracrypt or any other? Some of us would really appreciate if you could share exactly what tool you use to achieve that perfectly fine if you're not willing to. This is exactly why I'm considering DDD's suggestion booting off a Macrium Rescue ISO as a last resort because it's a sector by sector encrypted copy of the image thus negating the need for the backup destination to be encrypted.
I've never seen any issues where an encrypted drive isn't recognized as a valid backup destination, but I've never attempted to use Windows' own backup utility. I can only see that lack of recognition occurring if the backup is being made under WinPE and the encrypted partition hasn't been mounted by VeraCrypt. That would make sense because it would be seen as a raw partition. I agree that making backups of an encrypted system partition using the Macrium Rescue Disk should be a last resort, only desirable when a hot backup cannot be made because the system is unbootable.
That same rescue disk, however, is the critical means by which to restore your system from a backup, so don't overlook making and testing it. One more thing The Macrium Rescue program gives you two taskbar buttons in the lower left corner of its interface Command Prompt and PE Explorer so you can launch another program while running Macrium Rescue. That's how you launch VeraCrypt to mount the encrypted partition where your backups are located. So, all you do is run Macrium from within Windows, mount the encrypted destination D: drive and perform a regular hot backup by selecting D: drive as destination, which is no different from what I do now, expect the destination is unencrypted.
I find it hard to believe this has been doable all along and I've been scouring for alternatives assuming this simple exercise wasn't possible. I feel like running into a wall for not even trying it out. Having digested what you said about an unbootable system, how would you attempt a restore from a Macrium Rescue Disk seeing that the backup destination D:drive isn't mounted.
Macrium sees it as a raw partition as you said. Can Macrium run Veracrypt in portable mode so you can mount D:drive and do a regular restore. I remember trying to run Veracrypt in a Macrium environment sometime back but failed.
It threw up some error. This issue was raised in Czeskis et al. Threat model and attack vectors on deniable file systems and hidden operating systems. This is due to the fact that examination using differential analysis can reveal that seemingly random bytes on the hard drive will change in a non-random fashion.
This was practically demonstrated by Hargreaves and Chivers [6], and research on detecting the creation of DFSs inside an encrypted container have been presented in Jozwiak [8]. Examples of such a scenario is when an investigator has direct live access to a DFS based hidden OS, or has access to the network environ- ment within which a hidden OS is operating, or has access to cloud applications in which a hidden OS is connected to.
A typically situation will involve an in- vestigator remotely logging into a system containing a hidden OS using live response tools or just using standard remote access software like Team Viewer or VNC. Live response and memory analysis tools have the capabilities of col- lecting information from network connections, open ports and sockets, running processes, terminated processes, loaded DLLs, open files, OS kernel modules, process dumps, strings or user logs [12].
In this section, we present practical attacks on the deniability of hidden Operat- ing Systems OSs. For this, a test environment was created using Oracle Virtual Box version 5. A hard drive image size of 50GB was created. However, since the virtual box operates using the vdi file format with included metadata, its image had to be converted to a binary RAW format before analysis using com- puter forensic tools.
The designed layout of partitions is depicted in table 1. As the hidden OS was contained within the en- crypted hidden volume, which was located inside the encrypted outer volume, plausible deniability necessitates that it should be impossible to prove the exis- tence of this hidden OS. However, in the next section, we show that plausible deniability of the VeraCrypt hidden OS is not met even in the simplest threat model scenario.
Alice reveals the password for the decoy OS and for the outer volume. According to the plausible deniability attribute of the VeraCrypt hidden OS, the police should not be able to prove that Alice has a hidden OS installed on the computer, as it is stored in an encrypted hidden volume inside the encrypted outer volume. A VeraCrypt hidden OS requires a special uncommon disk layout consisting of at least two partitions that are both completely encrypted.
This information, in conjunction with the fact that VeraCrypt is installed on the computer under investigation, can potentially raise the suspicion of the police to the presence of a hidden OS. Nevertheless, this can reasonably be explained by Alice as the need to separate the system and documents into separate partitions.
However, any solid indication that a hidden OS is installed on the computer under investigation is sufficient to defeat plausible deniability. We conducted randomness testing to check for artifacts in the outer volume. The reason for this is because if a hidden OS is running inside a completely encrypted hidden volume that is located within an outer volume, which is also completely encrypted, no pseudo-random anomalies should be found.
However, we were able to ob- serve some unexpected values in specific sectors that were occupied by the outer volume.
In particular, there were two areas which clearly showed significantly lower entropy values of 7. The first of these observed areas was located in sector number , and the second was located bytes later in sector number The hidden volume hosting the hidden OS had a size of sectors. This could infer that the lower entropy areas indicate the beginning and end of the hidden volume hosting the hidden OS.
Presence of these areas violates the plausible deniability of the existence of a VeraCrypt hidden OS. Cross drive analysis showed that the second area correlates to running the hidden OS. Three bytes at offset are altered every time the hidden OS is started.
This is highlighted in fig. A VeraCrypt ciphertext block size is 16 bytes bits , this indicates that this area is not overwritten by the VeraCrypt encryption algorithm.
In summary, an investigator can easily find these areas in a One-Time Ac- cess threat model scenario. The presence of these areas is correlated with the existence of a hidden OS, and thus violates the plausible deniability attribute of a VeraCrypt hidden OS. Furthermore, if an investigator is able to compare this area with binary snapshots taken over an interval of time i.
Multiple Access model , this can provide strong evidence as to the running of a hidden OS on the computer.
This method has previously been used in DFSs for detecting the existence of TrueCrypt hidden volumes on a drive under investigation [6]. Our research adopts this method for detecting the presence of a VeraCrypt hidden OS. First, we split the binary images of the investigated drives into MB blocks.
Then the SHA1 of each block was computed. This was done under the assumption that this will help narrow down the analysis from a 50GB image to smaller parts of the drive where data actually changes, which was true in the case of analyzing TrueCrypt hidden volumes [6].
VeraCrypt statistics estimate that 17, 33, and MBs of data written on an encrypted volume correspond to 1 minute, 2 minute and 5 minute intervals [11]. Analysis of the cryptographic hash function values clearly showed that mismatched blocks in the case of running the decoy OS are placed in the first half of the investigated drive image. This is in contrast to running the hidden OS, which changes only the second half of the drive image. In fig. The first block is on the upper left, while the last block is on the lower right.
The data that changed during the running of the decoy and hidden OSs are depicted as the horizontal gray lines. A visual depiction of changes that were made to the volume while running the decoy OS left and hidden OS right. The experiment started with the creation of the binary images of the inves- tigated drive containing both the installed decoy and hidden OSs. Then, virtual machines were cloned, switched on and immediately turned off for the decoy OS and a second clone for the hidden OS.
While running the decoy OS, only data on the second portion changed. Whereas, running the hidden OS only resulted in changes in the outer volume, located in the third partition. Analyzing the first change sector offset and the last sector allows for an estimation of the hidden OS partition size.
In the case of the experiment, it was estimated as In summary, this demonstrates that cross drive analysis can uncover evidence that a hidden OS is running on an investigated drive based on analysis of changes in the encrypted drive.
In the previous section, we demonstrated that they are vulnerable to Multiple Access attacks. In this section, we discuss attack vectors based on the Live Response Access scenario. Our purpose is to reveal any information that can lead to proving that either a decoy or a hidden OS is running.
Despite information provided in the VeraCrypt documentation that asserts that neither the OS nor any application programs will know that all data is essentially written to and read from the hidden volume [11], we discovered that even non-privilege level applications can reveal some information that can be used to detect a hidden OS.
This is simple proof that the hidden OS is running. Moreover, when comparing the configurations files, there are clear differences. While this by itself cannot be treated as hard evidence, it potentially leaks information. Another indication that a hidden OS is running can be obtained from mounted volume information that the user can retrieve from the VeraCrypt GUI. This is shown in fig. Even a standard user account is able to obtain this information.
If an investiga- tor has administrative rights, it is highly likely that additional information can be obtained by analyzing processes and drives on the kernel. Modern operating systems are enhanced by default in cloud based mech- anisms to make work easier for the user.
An example of this is the Microsoft account that involves signing into one account for all devices. This information and the number of login attempts are recorded and stored on user account in- formation which can easily be accessed. The use of both the decoy and hidden OSs is visible in the account logs and this can be an easy way to prove that another OS is installed on the device by simply observing that two OSs are registered and used concurrently on the same device.
Combining this information with forensic analysis indicating that only one OS is present on the device and that the drive structure is capable of running a DFS hidden OS, can be used to prove the existence of a hidden OS. Similar attacks can be performed by comparing browser fingerprints. These types of web tracking techniques are described in [1, 5].
We conducted a series of tests which confirm that this method can indeed be used to reveal the presence of a hidden OS. Information that can compromise the existence of a hidden OS can also be obtained from monitoring device network traffic. An attacker can use both pas- sive and active OS identification techniques.
0コメント