Az XTS a többihez képest valóban még a legjobban védett bit-flipping ellen, de úgy rémlik itt sem bizonyított, hogy nem lehet legalább valamilyen korlátozottan kontrollált (vagyis nem totál garbage lesz a plaintext) bit-flipping támadást kivitelezni, inkább csak jelenleg nem ismerünk rá módszert (leszámítva a visszajátszást, amit említettél).
De nem ezt akartam mondani az egésszel, hanem azt, hogy a LUKS nem célzott meg integritásvédelmet, ezt külön kell ráraknod egy további DM rétegként vagy checksum-oló filerendszert kell használni. A LUKS csak a dm-crypt target fogja kezelni. Vagyis a hír illetve cím megfogalmazását tartom hibás szenzációhajhásznak. Amint továbbolvasod látod, hogy utána éppen abból a feltételezésből indulok ki, hogy valaki korrektül konfigurálta a rendszert és megpróbált minden eddigi integritásvédelmi best practice-t betartani.
Tisztában vagyok vele, hogy a fizikai hozzáférés szintje többféle lehet. Viszont azt nem értem, hogy egy remote konzol hozzáférési szintnél hogy állhat elő az egész helyzet, amiben ennek a támadásnak egyáltalán értelme van.
1. TPM-ben vagy hasonló hardveres eszközben tárolva van a kulcs -> miért állna a meg az initramfs jelszó prompt-nál, miért nem bootol tovább?
2. Nincs tárolva a kulcs, de normális integritásvédelem van -> hogy jutott el az initramfs jelszó promptig, miért nem a bootloader jelszó promptnál áll?
3. Valaki a bootloader jelszót beírta, de otthagyta a gépet az initramfs jelszó prompttal -> hát igen, ezesetben van egy root shellje az initramfs-hez. De ha ez a helyzet, akkor nem hiszem, hogy lenne TPM-ben tárolt kulcs (miért nem ment tovább). Ráadásul elég valószínűtlen ez a helyzet.
4. Ha létezik olyan használati eset, hogy van trusted boot check, de mégis jelszavas ellenőrzés is be van kapcsolva, de nem a bootloadernél, csak az initramfs-ben -> ez az egyetlen eset ahol valóban van relevanciája a támadásnak
De tapasztalatból mit mondasz, gyakorlatban tényleg előfordul ez a 4. felállás?
---
Régóta vágyok én, az androidok mezonkincsére már!