Току-що завърших един 3-дневен експеримент, който ми промени някои схващания, донякъде съм доволен че се оказах прав, донякъде съм силно разочарован че стана толкова лесно.
Мисля да лягам да спя, така че няма да изпадам в много детайли. В общи линии нещата се свеждат до следното: с помощта на хардуер за общо под 20 лева и в рамките на около 30 минути (с доста неоптимизиран код, мисля да го преправя), стига да имаш физически достъп до машината, full disk encryption-а се обезсмисля в голяма част от случаите. Тестовете ми бяха с dmcrypt/LUKS, но това е приложимо за абсолютно всеки opensource full-disk encryption софтуер (и за затворения също, просто ще е малко по-сложно)
Сложността на паролата и дали се използва въобще парола или keyfile е тотално ирелевантна - и най-сложната парола да бъде избрана, резултатът е потрошена криптография и то за същото време. Т.е атаката не включва bruteforce или каквато и да била подобна грубост върху паролата или ключа за декриптиране на блоковете.
Също така, това не е въобще нещо революционно и ново. Състои се от две части, като първата част е описана още преди 4-5 години (и вероятно е известна още по-отдавна), втората част теоретично е загатната на доста места, а за уиндоуските FDE решения има (поне) един продукт, който фирмата, която разработва (Passware) продава на разни law enforcement агенции. Това което направих е просто да приложа същите неща по отношение на най-масово използваното FDE решение в линукс - което е част от ядрото. Това което ме потресе е колко лесно става всичко - с малко железария и общо няколкостотин реда C код.
Трябва да го демонстрирам това, много хора ще го видят като нещо забавно
Като цяло за всеки, който има машина, за която е вероятно да стане обект на физическо посегателство (лаптоп в честия случай) и има криптирани дялове, към момента мога да кажа следното:
* В никакъв случай не оставяйте машината включена някъде без надзор (примерно хотелска стая) без значение дали е lock-ната или не.
* В никакъв случай не оставяйте машината "приспана" (suspend-to-ram)
* Освен ако не криптирате swap дяла, в никакъв случай не я хибернирайте (suspend-to-disk)
* Blacklist-вайте firewire_sbp2 kernel модула, така че да не се зарежда
Единственото, което би могло да бъде частичен проблем е че нещата зависят от kernel версията до известна степен. Това не е огромен проблем обаче. Която и да е kernel версия до момента няма да го спре, единствената разлика е че кода може да се налага малко да се преправи (също и спрямо 32-битова/64-битова машина). Вярвам, че може да се направи по далеч по-reliable начин ако се отдели малко повече време.
Като цяло всичкото това не е нещо ново или различно, обаче лекотата с която може да се направи е просто плашеща.