Per-VM encryption

[qubesuser]

Currently volatile.img is stored unencrypted and includes swap, which means that anyone compromising dom0 or getting past full disk encryption can potentially read things that were in application memory of any VM at any point in past time, if it happened to be swapped out and the sectors were not overwritten.

This can be avoided by mounting volatile.img using DM crypt and a randomly generated key on each bootup that is then naturally destroyed on shutdown.

Likewise, not encrypting private.img means that it is not possible to securely delete a VM in a way that is fully resistant to future compromises since the data may be preserved in unused or reallocated sectors. In this case there is the additional problem of having to encrypt the keys with a master key stored in a way that can be securely deleted/changed (options could be on paper or in the TPM).

There is a performance downside due to having to encrypt the data twice (once for the volatile.img/private.img encryption, once for full disk encryption); this could theoretically be avoided, but it seems that would require major changes.

[marmarek]

Some relevant photos:
https://twitter.com/rootkovska/status/541980196849872896
https://twitter.com/rootkovska/status/650732336330489856

Anyway this is something we consider in "Untrusted Storage Domain" design page 33.

[marmarek]

Some relevant photos:
https://twitter.com/rootkovska/status/541980196849872896
https://twitter.com/rootkovska/status/650732336330489856

Anyway this is something we consider in "Untrusted Storage Domain" design page 33.

[qubesuser]

I think just shredding like in the screenshots is potentially insecure (against someone obtaining the full disk encryption password), since the SSD or hard disk might have reallocated the blocks, and the filesystem might have done that as well (e.g. if using btrfs).

With XTS blocks are encrypted depending on the disk position, but one could in principle try all encryption positions on all raw disk blocks not part of files and then use entropy, compressibility, presence of long ASCII strings, etc. to guess at the correct plaintext.

Anyway this is something we consider in "Untrusted Storage Domain" design page 33.

Yes, that specific design for an untrusted storage domain would solve this issue too (assuming there is a way to securely destroy the per-AppVM keys), although they actually seem orthogonal in general.

One could implement an untrusted storage domain with the same key for all AppVM, as long as the decryption is done in dom0 as opposed to directly connecting the AppVMs to the storage domain and forward secrecy is not a goal.

An untrusted storage domain threat model also has other requirements like the need to defend against active manipulation, which means that something like the LUKS XTS FDE is not enough, and you'd also need to authenticate everything with a Merkle hash tree of all the disk sectors and then authenticate the root using a secret not shared with the untrusted storage domain (otherwise the storage domain can replace sectors with older encrypted versions) and probably generate and store a new random IV for each encryption to prevent leaking data correlation over time to the untrusted storage domain (with XTS or CBC ESSIV if you write A then B then C to the same sector, then the storage domain would know whether A = C or not because the IV/tweak and thus the ciphertext is the same).

[qubesuser]

I think just shredding like in the screenshots is potentially insecure (against someone obtaining the full disk encryption password), since the SSD or hard disk might have reallocated the blocks, and the filesystem might have done that as well (e.g. if using btrfs).

With XTS blocks are encrypted depending on the disk position, but one could in principle try all encryption positions on all raw disk blocks not part of files and then use entropy, compressibility, presence of long ASCII strings, etc. to guess at the correct plaintext.

Anyway this is something we consider in "Untrusted Storage Domain" design page 33.

Yes, that specific design for an untrusted storage domain would solve this issue too (assuming there is a way to securely destroy the per-AppVM keys), although they actually seem orthogonal in general.

One could implement an untrusted storage domain with the same key for all AppVM, as long as the decryption is done in dom0 as opposed to directly connecting the AppVMs to the storage domain and forward secrecy is not a goal.

An untrusted storage domain threat model also has other requirements like the need to defend against active manipulation, which means that something like the LUKS XTS FDE is not enough, and you'd also need to authenticate everything with a Merkle hash tree of all the disk sectors and then authenticate the root using a secret not shared with the untrusted storage domain (otherwise the storage domain can replace sectors with older encrypted versions) and probably generate and store a new random IV for each encryption to prevent leaking data correlation over time to the untrusted storage domain (with XTS or CBC ESSIV if you write A then B then C to the same sector, then the storage domain would know whether A = C or not because the IV/tweak and thus the ciphertext is the same).

[marmarek]

One could implement an untrusted storage domain with the same key for all AppVM, as long as the decryption is done in dom0 as opposed to directly connecting the AppVMs to the storage domain and forward secrecy is not a goal.

The point about Storage Domain is that dom0 would not touch VM data at all.

Regarding data authentication - yes, it is covered in that design. We haven't decided about precise implementation used for that - one candidate is dm-verity, but maybe there are alternatives.

Some subset of above - anti-forensics data handling - is considered for DispVMs - #904 . There is a chance that we'll implement it for R3.1.

[marmarek]

One could implement an untrusted storage domain with the same key for all AppVM, as long as the decryption is done in dom0 as opposed to directly connecting the AppVMs to the storage domain and forward secrecy is not a goal.

The point about Storage Domain is that dom0 would not touch VM data at all.

Regarding data authentication - yes, it is covered in that design. We haven't decided about precise implementation used for that - one candidate is dm-verity, but maybe there are alternatives.

Some subset of above - anti-forensics data handling - is considered for DispVMs - #904 . There is a chance that we'll implement it for R3.1.

[qubesuser]

The problem of dm-verity is that it seems to currently have no write support, which means it would obviously not work for defending mutable AppVM storage against a malicious storage domain.

Not sure if there is any alternative, it's possible that there is no easier way to do this than doing custom development on dm-verity (which is not so trivial because it needs to be crash-proof).

BTW, directly attaching AppVMs to an untrusted storage domain can be problematic, because a malicious or misconfigured AppVM could leak all its data by simply not encrypting anything (and viceversa the untrusted storage domain could send arbitrary plaintext), creating a very high-bandwidth covert channel that can be accessed even by someone that can only read/write a snapshot of the storage.

[qubesuser]

The problem of dm-verity is that it seems to currently have no write support, which means it would obviously not work for defending mutable AppVM storage against a malicious storage domain.

Not sure if there is any alternative, it's possible that there is no easier way to do this than doing custom development on dm-verity (which is not so trivial because it needs to be crash-proof).

BTW, directly attaching AppVMs to an untrusted storage domain can be problematic, because a malicious or misconfigured AppVM could leak all its data by simply not encrypting anything (and viceversa the untrusted storage domain could send arbitrary plaintext), creating a very high-bandwidth covert channel that can be accessed even by someone that can only read/write a snapshot of the storage.

[marmarek]

On Thu, Oct 08, 2015 at 01:11:27PM -0700, qubesuser wrote:

BTW, directly attaching AppVMs to an untrusted storage domain can be problematic, because a malicious or misconfigured AppVM could leak all its data by simply not encrypting anything (and viceversa the untrusted storage domain could send arbitrary plaintext), creating a very high-bandwidth covert channel that can be accessed even by someone that can only read/write a snapshot of the storage.

When the AppVM is compromised, it means that the data there is no
longer safe. The whole point about isolation is that only one
particular VM would be affected. In case of cooperating compromised
domains, x86 architecture provide sufficiently enough covert channels.
Yes, some of them have lower bandwidth, some higher, but still -
currently it's hard to solve, at least on on x86. I guess, in most
cases, the most precious data is quite small anyway (keys, etc).

Regarding storage domain sending arbitrary plaintext - it shouldn't be a
problem as long as AppVM properly verify the data. And when not, it's
already game over for that VM.

And generally the whole idea about Untrusted Storage Domain is to take
some more pieces out of TCB. Currently we need to trust disk controller
firmware (because it can effectively own dom0 using DMA) and assume
block backends are bug-free. We want to take those parts out of TCB.
Yes, some details needs to be sorted out, but in current design shape,
it will not be worse than the current approach (where the physical
storage handling is basically ultimately trusted).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Thu, Oct 08, 2015 at 01:11:27PM -0700, qubesuser wrote:

BTW, directly attaching AppVMs to an untrusted storage domain can be problematic, because a malicious or misconfigured AppVM could leak all its data by simply not encrypting anything (and viceversa the untrusted storage domain could send arbitrary plaintext), creating a very high-bandwidth covert channel that can be accessed even by someone that can only read/write a snapshot of the storage.

When the AppVM is compromised, it means that the data there is no
longer safe. The whole point about isolation is that only one
particular VM would be affected. In case of cooperating compromised
domains, x86 architecture provide sufficiently enough covert channels.
Yes, some of them have lower bandwidth, some higher, but still -
currently it's hard to solve, at least on on x86. I guess, in most
cases, the most precious data is quite small anyway (keys, etc).

Regarding storage domain sending arbitrary plaintext - it shouldn't be a
problem as long as AppVM properly verify the data. And when not, it's
already game over for that VM.

And generally the whole idea about Untrusted Storage Domain is to take
some more pieces out of TCB. Currently we need to trust disk controller
firmware (because it can effectively own dom0 using DMA) and assume
block backends are bug-free. We want to take those parts out of TCB.
Yes, some details needs to be sorted out, but in current design shape,
it will not be worse than the current approach (where the physical
storage handling is basically ultimately trusted).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

I'm closing this one as a duplicate of #904.
For "Untrusted Storage Domain" there will be a separate ticket.

[marmarek]

I'm closing this one as a duplicate of #904.
For "Untrusted Storage Domain" there will be a separate ticket.

[andrewdavidwong]

@marmarek: I can't find an existing issue that tracks per-VM encryption. This is the closest one. Should we re-open this issue to continue to track that, or open a new one?

[andrewdavidwong]

@marmarek: I can't find an existing issue that tracks per-VM encryption. This is the closest one. Should we re-open this issue to continue to track that, or open a new one?