2

I have a few questions about Security and Veracrypt and hope you can clarify it for me.

  1. I don't want the VeraCrypt hidden volume I created to be damaged. If I mount the hidden volume and transfer files there'd no damage, and if I enable the option 'Protect hidden volume against damage caused by writing to outer volume ' In the Mount Options dialog window, and write to the outer volume, there is no damage to the hidden volume, is that correct?

  2. if someone has access to a Veracrypt encrypted flash drive, they wouldn't be able to mount or write information to it, and BadUSB, flashing malware into the firmware wouldn't be possible?

  3. The only possibility would be to physically open up the flash drive and insert something into it? How likely is that to happen by someone who isn't the government and how much it would cost?

  4. I assume that it would be different for a PC with an encrypted hard drive as they would be able to flash malware into the firmware if the BIOS isn't password protected, but what if the BIOS is password protected but you can still use the multi device boot option and boot a Linux operating system from a flash drive? (I know that PC does that). Does that mean that they could flash something into the firmware? How do I test if it's possible on that PC?

  5. If four isn't possible, the only possibility would be again to open up the PC and insert something into the hardware, is that correct? How likely is that to happen by someone who isn't the government and how much would it cost?

  6. Is there really no way to check if they inserted something into the firmware or to check if they inserted something into the hardware? How do you keep your information safe if your PC or flash drive could be compromised with no way to check if it has been compromised, aside from getting a new machine?

Please answer as much of it as you can, it's alright if you don't know all of the answers. Thanks

Guest
  • 21
  • 3
  • 2
    Unfortunately in this case, Stack Exchange works best with questions that have a single, authoritative answer, and where any answer given can be judged based on how well it answers the question. You're asking a large number of questions here; I count at least *11* questions. That's just too much for one question and answer; even if you do say that it's all right "if you don't know all the answers", that's not how our format works. I strongly encourage you to split this into multiple questions, each dealing with one aspect of what you're asking about. – user Apr 13 '18 at 17:17

2 Answers2

1

That's quite a lot of questions! Honestly though, I think your biggest issue is that you have not defined a threat model. You need to understand your adversary, their capabilities, the value of your assets, etc. It's far more likely that someone will simply plug in a hardware keylogger than it is that they will physically open your computer and replace your BIOS. Attackers will always choose the simpler attacks over the more sophisticated ones, and your adversaries are no exception.

Encryption cannot protect against an attacker who has unrestricted physical access to the device doing the encryption. This is not a limitation of encryption itself, but a limitation with how it can be used. VeraCrypt and similar encryption utilities can only provide data-at-rest security which means that, when the system is powered off and all an attacker has is the raw encrypted data, they will not be able to decrypt it without the key. Make sure your system is attended and physically secure.

I don't want the VeraCrypt hidden volume I created to be damaged. If I mount the hidden volume and transfer files there'd no damage, and if I enable the option 'Protect hidden volume against damage caused by writing to outer volume ' In the Mount Options dialog window, and write to the outer volume, there is no damage to the hidden volume, is that correct?

That is correct. If you enable "protect hidden volume", then you can write to the outer volume safely. If you are forced to give up your key under duress, you would only provide the outer volume key and not both, which would cause any writes to corrupt the hidden volume. This is unavoidable.

if someone has access to a Veracrypt encrypted flash drive, they wouldn't be able to mount or write information to it, and BadUSB, flashing malware into the firmware wouldn't be possible?

Encryption does not block writing, but it does mean that the data that is written will appear as gibberish when you decrypt it. As for flashing firmware, encryption does not prevent that. Firmware is kept separately on the flash drive and is not and cannot be encrypted by VeraCrypt.

The only possibility would be to physically open up the flash drive and insert something into it? How likely is that to happen by someone who isn't the government and how much it would cost?

It would be far easier to modify the firmware, but if the drive does correctly disable writing to firmware, then it would be possible to physically modify the firmware chip. No one can tell you the likelihood of this happening, but the cost would be extremely low. Note that modifying the flash drive alone is incapable of circumventing encryption.

I assume that it would be different for a PC with an encrypted hard drive as they would be able to flash malware into the firmware if the BIOS isn't password protected, but what if the BIOS is password protected but you can still use the multi device boot option and boot a Linux operating system from a flash drive? (I know that PC does that). Does that mean that they could flash something into the firmware? How do I test if it's possible on that PC?

The BIOS password does not protect against firmware modification. See this answer.

If four isn't possible, the only possibility would be again to open up the PC and insert something into the hardware, is that correct? How likely is that to happen by someone who isn't the government and how much would it cost?

It would be easier to modify a PC because it is larger and has more components. It would be very cheap, but again, no one can tell you how likely that scenario is for your particular threat model.

Is there really no way to check if they inserted something into the firmware or to check if they inserted something into the hardware? How do you keep your information safe if your PC or flash drive could be compromised with no way to check if it has been compromised, aside from getting a new machine?

It is possible to verify firmware, but it can be complicated to set up. I explained how this can be done on an answer to another question. At the bottom of the answer are a list of further resources.

Glorfindel
  • 2,235
  • 6
  • 18
  • 30
forest
  • 64,616
  • 20
  • 206
  • 257
  • How do I test if a flash drive correctly disable writing to firmware? If it does, is there a way to check if the firmware chip has been physically modified? – Guest Apr 14 '18 at 14:30
  • @Guest Unfortunately, there is no way to check for that. You would have to open the drive to look at the actual chip, and try to find and read the technical datasheet (which may or may not be in Chinese) to know if writing to firmware even _can_ be disabled. – forest Apr 15 '18 at 05:40
  • If I open the drive to look at the actual chip, the technical datasheet is on the physical card or what software do I have to use to read it and disable writing to firmware if it can be disabled? Thanks – Guest Apr 15 '18 at 14:21
  • @Guest The datasheet is a document. You would look at the chip's model and then search online for the datasheet for it. – forest Apr 16 '18 at 09:47
0

I see your questions as “if I use veracrypt on all hdds and flash drives, how can I be compromised?”.

If you use the old (non uefi) boot chain, I can just put a TSR keylogger on your boot sector, then chain to veracrypt. Once you enter your password, I store it clear on HDD. Or I could modify veracrypt to store the password. I would need access to your machine twice, once before, and once after you use your computer, but it would cost no money and no modification to your computer.

There is probably a way to do it in uefi too(set my cert trusted in bios setup), but i have no experience with it.

manduca
  • 1,111
  • 7
  • 10
  • TSR? Isn't that for, like, ancient MS-DOS systems? – forest Apr 14 '18 at 05:49
  • @forest Yes, you remember :-) But you don‘t need MSDOS, you can hook BIOS interrupts. Without special measures on your side („bootkit“ style) your code will be powerless once the OS is loaded and talks directly to the hardware, but by then you already have the password stored away. – manduca Apr 14 '18 at 07:04
  • But modern computers never enter real mode anymore after the BIOS loads the MBR and the MBR does its magic, so the IVT in theory should never be touched after the system boots up. I've tested this before on at least one system in CSM mode and wrote over the IVT, and the system was fine. – forest Apr 15 '18 at 05:39
  • Actually both Linux and Windows boot code switches back and forth between real mode & protected mode like crazy. If you hook e.g. HDD interrupts, you get a lot of calls. The boot logic is very soon in protected mode, but the boot code thunks back to 16 bit precisely because it wants to use the real mode BIOS interrupts to interact with HDD etc. Much later comes the final switch where the kernel boots and they use their own drivers and never look back [Of course I only talk about non-UEFI jump-to-0000:7C00-like-it´s-1990. My knowledge is from 2014 on Win7 and centos] – manduca Apr 15 '18 at 06:58
  • Ah you're right. I was thinking of a bootloader like GRUB which prefers to jump quickly into protected mode (after stage1). I assume this also applies to CSM (though honestly I don't know how similar CSM is to a real BIOS, but I suspect virtually identical for most implementations). – forest Apr 15 '18 at 07:06