7
$\begingroup$

Is it possible to leverage a preexisting implementation of AES-GCM to provide the key security benefits essential for full-disk encryption (similar to AES-XTS)?

GCM is a popular encryption mode supported by several libraries and with fast implementations in hardware, and on its own GCM has nice properties including parallelism. Because of GCM's built-in authentication functionality and due to its performance, it is beneficial to consider that as a starting point; a hardware implementation may implement AES-GCM as a self-contained performance routine.

But on the other hand, a critical requirement of GCM (essential to its security) is that it must have unique random IVs, just like CCM. So if the IV that is chosen is derived from the sector or block offset (even if there's an intermediate hash), the very fact that on a disk it's common to write and overwrite data in place (coupled with GCM and CCM behaving nearly like stream ciphers) makes it potentially dangerous to derive the IV in that deterministic way. But just like many encryption modes are based upon compositions of cryptographic primitives, I'm wondering if it's possible to start with GCM (and its AEAD property) and build upon that to also attain the secure capability of writing to disk at sector offsets.

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ "critical requirement of GCM is that it must have unique random IVs" is not correct, they must be unique but do not need to be random. If you want them to appear random to the mode, you can encrypt it with a different key. $\endgroup$
    – Richie Frame
    Commented Feb 19, 2014 at 7:58
  • $\begingroup$ Personally I would not consider GCM to be appropriate for disk encryption due to the fact it is authenticated, and the auth tag must be stored somewhere outside of the file system $\endgroup$
    – Richie Frame
    Commented Feb 19, 2014 at 8:00
  • $\begingroup$ As Richie says, GCM require Unique but not random IVs. Indeed, random makes it much harder to find unique IVs due to the birthday bound. In this sense it is no problem to use a sector identifier $\endgroup$
    – Cryptographeur
    Commented Feb 19, 2014 at 9:41
  • $\begingroup$ Thanks for the comments. As I mention below, I don't mind storing the auth tag or some key material needed to derive the IV, so space isn't an issue. But I do think it's a problem to use a sector identifier, because data ends up getting re-encrypted with the same (key,IV) when it is written to the same place. The only other alternative I'm aware of is to store a derivation of the tweak value so that data is written differently each time - which adds overhead. Given that the extra space is okay, I'd like to explore different ways I could use GCM or its components to achieve XTS properties. $\endgroup$
    – user3325588
    Commented Feb 19, 2014 at 15:14

2 Answers 2

Reset to default
8
$\begingroup$

The ZFS file system uses AES in CCM or GCM modes. This works because in ZFS the data and file system metadata is encrypted but the block pointers are in the clear, the AuthTag (MAC) is stored in the block pointer. ZFS also has a SHA256 based merkle tree based on the block pointers that is used for data integrity for resilvering and navigation purposes.

Note that ZFS is file system (actually object based really) encryption it does not claim to be "full disk encryption".

For more details see here: https://blogs.oracle.com/darren/entry/zfs_encryption_what_is_on

Darren J Moffat (Architect and lead developer for ZFS encryption).

Improve this answer
$\endgroup$
2
6
$\begingroup$

If you don't mind that the ciphertext is longer than the plaintext, GCM is perfectly fine for storage encryption. Every time you write a block to disk, choose a fresh nonce and write the resulting ciphertext to disk. (You can ask for even stronger security properties, but then everything gets more expensive. Basically, build a tree structure for tags. Reads and writes are no longer constant time, but logarithmic in the size of the disk. This is bad for spinning disks when you have significant seek times, but may be ok otherwise.)

If you want non-expanding encryption (ciphertext length is the same as plaintext length), then GCM is not appropriate, because it is very weak when IV's are reused, and there's no space for the authentication tag (GCM without authentication is just a form of counter mode).

If you just have a black-box implementation of GCM, I would expect it to be difficult to use that as a building block for a secure non-expanding scheme in any sensible way.

If you have access to the components used to build GCM (the block cipher, finite field arithmetic, etc.), then they may be useful for building a secure scheme.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thanks for the feedback. I'm wondering if you could elaborate on your answer. I understand the first two paragraphs. I'd also say that I don't mind the expansion that results. But into the third paragraph, I'm not clear on what you mean. I'm interested in knowing whether it's possible or not possible to start with (or use) GCM and achieve additional properties. It's not clear why it wouldn't be possible. I agree it would be different, and would need to be carefully done. But in principle still possible, either through the components or by using the whole GCM step in a different way. $\endgroup$
    – user3325588
    Commented Feb 19, 2014 at 15:09
  • $\begingroup$ Thanks for the update. It seems then the approach to guarantee security with GCM is to write with a new IV each time. Then the effective data unit size that GCM operates on decides its performance, since a new (subset) write within that unit would need to rewrite the whole data under a new IV. What about adding basic fast low-level XOR operations afterward to make GCM behave less like a stream cipher? It would need to be done very carefully. But maybe the aim is to keep an update to a data region local to that "tweak", rather than to a larger "block". $\endgroup$
    – user3325588
    Commented Feb 20, 2014 at 23:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.