7

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.

Cryptographeur
  • 4,357
  • 2
  • 29
  • 40
user3325588
  • 111
  • 1
  • 7

2 Answers2

8

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).

Darren J Moffat
  • 89
  • 1
  • 1
6

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.

K.G.
  • 4,947
  • 19
  • 34