Hi,
On 15. 01. 22 5:06, Christoph Anton Mitterer wrote:
On Fri, 2022-01-14 at 12:18 +0100, Ondrej Kozina wrote:
1) Wouldn't that then cause complete decryption? I.e. cryptsetup
sees
that re-encrypt (to plain text) was allegedly aborted at block
XYZ...
and then re-encrypts (to plain text) from there on the whole
device?
Not without user manual intervention. Currently, the reencryption
operation can not be resumed unless user directly issue "cryptsetup
reencrypt" command (applies to both fixed and vulnerable
cryptsetups).
Then I don't understand the attack... cause if t would be only resumed
if one enters a command manually, the attacked user would notice?
Sure, I can explain better. Let's stick to two different terms:
I. individual reencryption step (reencryption of one of many hotzones)
II. device reencryption (aka iteration of I. steps)
The reencryption hotzone stored in LUKS2 metadata describes following
(let's make it decryption attack example):
"the data starting at offset X, Y length, describes block in transition
from ciphertext to plaintext that was not finished yet".
If libcryptsetup see such metadata stored in LUKS2 header, it performs
auto-recovery during device activation.
During auto-recovery triggered by e.g. cryptsetup luksOpen command,
libcryptsetup does not perform whole decryption of device (II., it only
checks last hotzone (I.) is correcly decrypted. If not it finishes the
single hotzone so that it is in correct new state (plaintext) as
described in LUKS2 metadata. Afterwards, the device gets activated
usually as two segment DM device. Following example is device activated
when decryption recovers after crash somewhere in the middle of the data
device:
[LUKS2 on-disk header][data: plaintext][data: ciphertext]
To finish the decryption process (II.), user would have to manually
issue "cryptsetup reencrypt" command again.
If you want to understand the reencryption as whole better, please see
my slides for the LUKS2 reencryption extension here:
https://okozina.fedorapeople.org/online-disk-reencryption-with-luks2-compact.pdf,
on slide 8 and later is the process described step-by-step (also, the
talk recording: https://youtu.be/54vyOO8mWGg).
So the attack primarily targets recovery, the single hotzone crash
recovery process in activation code.
To resume/finish the reencryption process (and complete all steps in
II.) user would have to issue cryptsetup reencrypt command manually again.
On the other hand, the vulnerability primarily targets LUKS2
reencryption auto-recovery feature. Auto-recovery takes place in two
scenarios:
...
b) LUKS2 device activation e.g. during system boot.
Okay that's the situation I've had meant before.
As described above, this would perform single hotzone segment decryption
only (in crash recovery code path).
So the recovery from
reencryption crash is seamless provided user knows passphrase.
And that's the point where I'd have expected the full decryption, i.e.:
- an attacker messes with the headers while the device is offline
- the user opens it (e.g. on next boot), doesn't notice anything
- cryptsetup "continues" silently, but actually decrypts
No, we do not silently auto-resumes LUKS2 reencryption automatically.
In corner case, when device is small enough to fit limits disclosed
in
the vulnerability report (and LUKS2 spare metadata space allows it)
the
auto-recovery may actually finish the decryption process (in one
step).
I think I don't understand how the spare header space affects this?
I thought you'd just use that as kind of a journal? And to keep a copy
of the region that is currently re-encrypted, and once that one has
finished it would move on?
Yes, In case of 'journal' resilience mode the spare space is 1:1 with
hotzone segment size.
But if 'checksums' resilience is in-use, the hotzone size can be larger.
It stores single digest per encryption sector size block in reencryption
hotzone.
or because an attack started only e.g. at
half o the blocks, but then one half is encrypted and the other
not?
Nope, in this case device would activate just fine, part of the
device
encrypted and part plaintext (multi segment device-mapper device).
Otherwise we would be unable to activate partially decrypted devices
due
to interruption. Same applies to devices in encryption or
reencryption.
So you keep book (in a secured way?) on which regions have been re-
encrypted already and which not?
I assumed it would be just some "pointer" that shows at one position
from start to end, where the system currently was.
Two possibilities:
a) LUKS2 metadata with crashed reencryption: It stores offset and length
of the last hotzone.
b) LUKS2 metadata after crash recovery: The pointer where to resume the
operation when user issues cryptsetup reencrypt command again.
Ransomware attack is not possible provided attacker does not know
valid
passphrase or VK, if that's what you're asking:
That was less about ransomware attack... cause when an attacker would
have access to the offline device, he'd either compromised the system
already, or has physical access... and in both cases he could also just
do the attack (or simply steal the physical device).
I was rather just wondering, whether during encrypting the new key is
ever written to disk in an insecure way (which they keyslot, where it
is encrypted, wouldn't be)
Absolutely not! Keys are always stored in regular LUKS2 keyslots on-disk.
That would not be possible with LUKS2 format, or better say with
current
version of API of libcryptsetup. If the whole header was to be
protected
by MAC it would require complete rework of API which would not be
backward compatible. It would probably be LUKS3 format/library.
Well... could save us from troubles some day ;-)
Also, just for LUKS2 reencryption, it would completely kill the
performance of the operation. During LUKS2 reencryption the json
metadata area gets updated quite often (twice per single reencryption
step which is typically ~100MiBs of data reencrypteed with checksum
resilience mode). If we calculated authentication digest (time
expensive
operation) in each step twice it would not go fast.
FYI, LUKS2 json metadata are stored usually twice per single hotzone
reencryption (I. above)
That refers to the information on which regions have already been re-
encrypted right?
yes
I assume, unless re-"encryption" to plain text is performed,... the
clear-text never goes on disk during a "normal" re-encryption?!
Exactly. It's always either "old" cipher text or "new" ciphertext.
Eventually digest(s) of "old" ciphertext depending on what reencryption
resilience mode was in-use.
Regards
O.
_______________________________________________
dm-crypt mailing list -- dm-crypt@xxxxxxxx
To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
