22

I want to switch from using LUKS for full disk encryption to TRESOR. TRESOR tries to prevent cold boot attacks by storing the encryption key in the CPU's registers. It uses the kernel's crypto API for things like getting IVs and using a mode like XTS. However, the actual key is requested once the kernel boots and any keys passed to the cipher via the crypto API later on are ignored.

When using the XTS mode, the key is usually split in two halves and one is used as the actual key and the other to generate IVs. But since TRESOR ignores all keys, the kernel ends up using two identical AES keys. From what I can gather from this question and the papers linked there, XTS is vulnerable to a chosen cipher text attack when used like that.

Can this become a problem in practice? And which modes of operation can I use instead? From looking at the code, it seems that cbc-essiv also needs to supply its own key.

twisted_pear
  • 321
  • 1
  • 3
  • 2
    I deleted an early answer which contained an error that proved difficult to fix. But to answer a question you made in a comment there: XTS and XEX are different types of objects. XTS uses a variant of XEX under the hood, just like CBC can use AES (or some other block cipher) under the hood. Although XTS avoids Rogaway's attack by using two keys (and Rogaway avoids it by disallowing certain tweaks), XTS is *not* secure against chosen-ciphertext attacks in general, regardless of which XEX variant it uses. – Seth Oct 13 '14 at 02:16
  • Thanks for clarifying that. I'd still like to know why they are specifically trying to avoid that attack. Is it somehow more significant than others? I've tried to figure out what repercussions Rogaway's attack can have, but I can't wrap my head around the math. My best guess so far is that it would allow for some kind of fingerprinting. – twisted_pear Oct 13 '14 at 17:57
  • 9
    You might have better luck at crypto.stackexchange.com. – Seth Oct 14 '14 at 17:54

1 Answers1

2

This likely will become a problem, if you simply try to use tresor-xts-plain or tresor-xts-plain64. While I haven't tested it extensively, even when I tried TRESOR even with cbc-essiv, it resulted in a non-working system. Only cbc-plain worked, which does use a single key. The way I personally use TRESOR is with tresor-cbc-plain chained with serpent-xts-plain64. I assume that if someone performs a cold boot attack against me and manages to obtain the serpent key will not be able to perform malleability attacks against the cbc-plain, because cold boot attacks are not particularly stealthy. While there are some other weaknesses with cbc, confidentiality is typically still maintained.

However, there may be workarounds. There is a patch to hypervisor BitVisor, called TreVisor which can use TRESOR with XTS keys. I haven't read through the patch extensively. Perhaps looking at the tresor_xts_crypt() function could provide some insight. Its main page is here, in the middle.

There is also RamCrypt, which uses TRESOR to encrypts memory pages of individual processes. It uses the XEX mode of operation, which is similar to XTS (it also uses tweak keys, but the tweak key is the same as the data key). The ramcrypt_page_crypt() function may be a good starting point. Its main page is here.

TreVisor, at least, has a clever workaround for this problem. As XTS mode requires an extra key, the tweak key, TreVisor simply uses a key of half the size (128 bits rather than 256) for encryption, and uses the free 128 bits to store the tweak key. I believe RamCrypt does something similar. See the read_key_0 and read_key_1 macros, and the up argument for the encrypt_block and decrypt_block macros in the TreVisor patch.

forest
  • 64,616
  • 20
  • 206
  • 257