Наскільки захищеною є зашифрована файлова система LUKS?

34

Нещодавно я встановив 11.10 на свіжий диск, використовуючи повне шифрування диска. Може хтось скаже мені, наскільки безпечний алгоритм шифрування? Чи були недавні порушення із зазначеним алгоритмом? Я використовую випадкову парольну фразу 36 символів, тому я знаю, що це не слабка ланка. Які шанси зіпсувати дані мого клієнта, якщо жорсткий диск був вкрадений?

encryption luks

— броп
джерело

Вам може бути краще запитати, скільки часу (в середньому) комусь потрібно буде зламати цю фразу. Також може допомогти дізнатися, чи може людина, яка його краде, знає, наприклад, дані кредитної картки. Думаю, ви можете стверджувати, що якщо це не кредитні картки, ніхто не збирається її змусити - грошей на це немає.

— jcollum

11

Захищено від чого? Злом шифрування за допомогою суперкомп'ютера - важко, але не неможливо. Зламати код гайковим ключем на 10 доларів - простіше imgs.xkcd.com/comics/security.png

— Пантера

Ось як побачити, який шифр ви використовуєте в LUKS: Що використовується в шифруванні повного диска 12.10?

— gertvdijk

1

@Panther Чи дійсно потрібен гайковий ключ на 10 доларів? Я впевнений, що є і більш дешеві рішення. Потрібна така дорога перешкода для вступу в криптоаналіз згубна для поля.

— Mateen Ulhaq

31

Так, це безпечно. Ubuntu використовує AES-256 для шифрування обсягу диска та має зворотній зв'язок cypher, щоб захистити його від частотних атак та інших атак, націлених на статично зашифровані дані.

Як алгоритм, AES є безпечним, і це було доведено тестуванням криптовалют. Слабкість насправді полягає в програмі cyfer і програмному забезпеченні для передачі їй ключів. Спеціально лежить у сховищі ключів (який зберігається у заголовку тома), сховище ключів захищене парольною фразою. Паролі фрази, звичайно, відкриті для деяких атак, таких як словник / груба сила (якщо це було б успішним, воно розшифрує зберігання ключів). Використання довгих "складних" несловесних паролів зменшило б шанс цього статися.

Єдина інша можливість розшифрувати це використання пристроїв запису чи соціального проектування для визначення вашої парольної фрази.

Коротше кажучи, ваш комп'ютер досить безпечний, якщо ви не піддаєтесь серйозній організованій кіберзлочинності чи урядовим розслідуванням!

— БраунЕ
джерело

18

Однак ви повинні зауважити, що якщо ваш комп'ютер перебуває під час роботи або в режимі призупинення (сплячий режим добре), існують різні, досить прості методи вилучення пароля з оперативної пам'яті. Тому я радив би бути обережним, у якому стані ви залишаєте свій ноутбук під час подорожі, але в цілому ви повинні бути в безпеці від більшості потенційних сценаріїв втрати даних.

— ternaryОператор

@ternaryOperator насправді не так, це стосується лише ноутбуків. Коли комп'ютер втрачає потужність, дані оперативної пам’яті досить швидко згасають, поки не читаються (саме тому ми не просто використовуємо оперативну пам’ять замість SSD для надшвидкого зберігання. Проблема була не просто швидкістю; різні компанії намагаються знайти Хоча так (меморістори) Якщо ви не прийняли, ви мали на увазі фізичний доступ під час роботи.

— Cestarian

@ Cestarian, так, я маю на увазі, що навіть якщо диск зашифрований, дані є вразливими під час увімкнення машини (навіть коли заблоковано або в режимі призупинення). Так, наприклад, якщо ви залишите комп’ютер увімкнутим або призупинено в режимі ночі, або з якоїсь іншої причини хтось може отримати доступ до вашого комп’ютера, коли він не повністю вимкнений, тоді вони матимуть досить хороші шанси отримати доступ до ваших даних шляхом доступу. вміст оперативної пам’яті (показано, що обприскування оперативної пам’яті розпилювачем охолоджуючої рідини значно уповільнює розпад даних в оперативній пам’яті, що може перезавантажити машину для запуску програмного забезпечення для відновлення).

— ternaryОператор

@ternaryOperator, однак, це дальний постріл, щоб отримати доступ до нього, коли він залишився, вони повинні або: A: Увійти на мій сервер NAS (для чого потрібен злом одного з двох можливих символів 10+, і це не в дуже зручному місці для цього .. . (невелика сховище) здогадуються, що вони можуть спробувати використовувати ssh tho) B: Сподіваюся, вони можуть викрасти ключі шифрування з моєї оперативної пам’яті (хіба не шифрувальні ключі видалено з оперативної пам’яті, як тільки вони були використані? Це в основному не буде t відбудеться тоді.), який є більш правдоподібним підходом, але вимагає більше досвіду. Як звичайний звичайний чувак, я так не вартий клопоту.

— Cestarian

1

@Cestarian Це працює за допомогою опції B, доступ до ключів шифрування з оперативної пам’яті. Ключ шифрування кешується десь у оперативній пам’яті, оскільки операційна система потребує цього кожного разу, коли він читає / записує дані на зашифрованому диску. Я погоджуюся з тим, що більшість людей потребує такого рівня паранойя щодо шифрування диска, і я зацікавлений в основному академічним, однак це один з найбільш практичних сценаріїв атаки на шифрування диска з гідним паролем і не потребує спеціального обладнання. Деталі цих атак висвітлюються в цій статті Вікіпедії: en.wikipedia.org/wiki/Cold_boot_attack .

— ternaryОператор

7

Ось два ресурси про атаки на цей тип файлової системи, які здаються цікавими: http://dx.eng.uiowa.edu/dave/luks.php http://www.jakoblell.com/blog/2013/12 / 22 / практично-ковкість-атака-проти-cbc-зашифрована-luks-розділи /

Коротше кажучи, в останньому документі описано, що можна ввести віддалене виконання коду заднім кутом в налаштування LUKS, створене інсталятором Ubuntu 12.04. Ця атака потребує доступу лише до зашифрованого жорсткого диска (вона не покладається на маніпулювання незашифрованим /bootрозділом або BIOS).

Хоча атака є досить поганою, вона не стосується сучасних установок LUCS. Атака може бути застосована лише в тому випадку, коли режим блоку є CBC, наприклад, якщо використовується шифр aes-cbc-essiv. Сучасні установки використовують інші режими блоку, наприклад, шифр aes-xts-plain64(див. Цю статтю на вікі ArchLinux ).

Щоб перевірити, який шифр використовується вашим налаштуванням, запустіть:

sudo cryptsetup status [device]

де [device]ваше картографування, як /dev/mapper/sda3_crypt.

— Датська
джерело

1

Ласкаво просимо до Ask Ubuntu! Хоча це теоретично може відповісти на питання, бажано було б сюди включити істотні частини відповіді та надати посилання для довідки.

— guntbert

Я дуже переживаю за практичну атаку ковкості, наприклад, є рядок, який легко можна знайти на будь-якому розділі ext4 (загублений + знайдений) кількість можливих рядків значно збільшується, якщо це системний розділ, але є більш незрозумілим, якщо вміст з приводів невідомо. Не потрібно турбуватися про відновлення парольної фрази з оперативної пам’яті, якщо ваш комп’ютер потрапляє в онлайн-стан, швидше за все, ваші диски вже в розшифрованому стані. Тож вам слід просто переконатися, що ваша система може бути відключена натисканням кнопки в момент, коли ви відчуєте загрозу.

— Cestarian

ЛУКС, а не ЛУКС.

— Cees Timmerman

1

Я створив програму Windows, яка буде виконувати атаку словника на томи Luks. http://code.google.com/p/luks-volume-cracker/

Її повільно по дизайну, пробуючи 3 клавіші в секунду. Інші словникові атаки будуть аналогічно повільними, тому, якщо ви не обрали легку фразу, слабкість не буде алгоритмом.

Однак пам’ятайте про крадіжку ключів з пам'яті та кешування файлів.

— Крис
джерело

1

Це не відповідає на питання, наскільки це безпечно . Це відповідь на питання про те, як здійснити атаку словника на моєму пристрої LUKS? .

— gertvdijk

2

@gertvdijk Я думаю, це може відповісти на питання. "якщо ви не вибрали просту фразу, слабкість не буде алгоритмом." Решта можна вважати демонстрацією цього принципу. Останнє речення теж тематичне.

— Елія Каган

1

@EliahKagan Я не згоден. Питання явно стосується самого алгоритму . По моїй думці, лише те, що "слабкість не буде алгоритмом", це не відповідь на це. Не зрозумійте мене неправильно - це все ще має вагомі та цінні моменти, але не щодо цього питання.

— gertvdijk

1

@gertvdijk Ця відповідь також визначає, скільки часу потрібно, щоб зламати алгоритм, посилаючись на демонстрацію. Я не кажу, що це найкраща відповідь, але я думаю, що це відповідає стороні відповіді (на це питання). Крім того, наскільки безпечний алгоритм , насправді лише одна з кількох частин питання.

— Елія Каган

1

Я думаю, що це певним чином демонструє рівень можливої атаки проти ЛУКС. 3 спроби секунди зі словника ніколи не збираються зламати напівпристойну парольну фразу.

— Олі

-2

Метод шифрування LUKS потенційно небезпечний, принаймні, таким чином, як він обробляє процес шифрування. Давайте надамо перевагу сумніву, що алгоритми безпечні, і ми можемо порівняти їх з кодом алгоритму, який був перевірений. Відклавши це, як користувача, вам не дозволяється створювати ключ, який шифрує ваші дані. Це як сказати комусь, ей, я складу пароль, який шифрує ваш банківський рахунок, а не ви. Але я буду так приємно дозволити вам скласти пароль, який шифрує мій пароль. У LUKS є слабкість безпеки, як я це бачу.

LUKS використовує головний ключ або те, що вони називають Уніфікований ключ. Цей ключ генерується за допомогою програм «випадкова» та «урадома», встановлених у системі Linux. Якщо ці програми якимось чином порушені, ваш Master Key стає слабким. Незалежно від того, наскільки міцний ваш пароль, метод створення основного ключа створює вразливість.

Порівняйте це з TrueCrypt, який загадково відключив під час найбільших витоків проти американського шпигунства. Томи TrueCrypt, які були правильно зашифровані відповідно до документації TrueCrypts, не були розбиті. Уряд кинув усі гроші платників податків на обсяги TrueCrypt і не зміг їх порушити. Це юридичний облік. https://en.wikipedia.org/wiki/TrueCrypt#Legal_cases (TrueCrypt четверта поправка затверджена)

TrueCrypt дозволяє користувачеві створити головний ключ. Під час створення обсягу TrueCrypt дозволяє користувачеві переміщати мишу в інтерфейсі TrueCrypt протягом тих часових, наскільки їм подобається, що випадковим чином маніпулює значенням створеного головного ключа. Це передає силу хаосу в руку користувачів, куди йому належить. LUKS не дозволяє цю легку програмну функцію.

— Джеван
джерело

4

ПОПЕРЕДЖЕННЯ: Використання TrueCrypt не є безпечним, оскільки може містити нефіксовані проблеми безпеки. Тепер, окрім цього, LUKS підтримує визначені користувачем <= 512 прохідні фрази та <= 8MiB ключові файли довільних бінарних даних. По-друге, випадкові пристрої Linux можуть бути поставлені під загрозу, якщо система (тобто кореневий обліковий запис) порушена. TrueCrypt не має магічного щита для цього сценарію. Нарешті, ядро Linux автоматично збирає свою ентропію для (u) випадкових випадків з багатьох пристроїв, включаючи мишку. Підсумок - TrueCrypt покинутий і його не слід використовувати. Використовуйте LUKS.

— Адріан Гюнтер

1

Ви не розумієте, як працює генерація ключів. TrueCrypt (як і його наступники) використовує той самий процес, що і LUKS, щоб генерувати головний ключ: збирайте ентропію різними способами, включаючи рухи миші, подайте її в генератор псевдовипадкових чисел і використовуйте висновок зазначеного PRNG як головний ключ. Різниця полягає в тому, що TrueCrypt використовує власний алгоритм для генерації ключа замість системного RNG. Алгоритм TrueCrypt може бути помилковим, як і RNG, що надається ОС. Ця відповідь є FUD та небезпечна для необізнаних користувачів. LUKS захищено.

— Ельзо