Протрите попереднє шифрування, чому?

Мені хотілося знати, чому перед шифруванням та встановленням на диску, Kali:

1. витер цілий диск
2. заповнив накопичувач 0
3. заповнили накопичувач 1с
4. заповнив накопичувач випадковими даними
5. знову витер диск

Я знаю, що Kali не призначений для встановлення, але тут справа не в цьому.

Отже, чим це корисно перед установкою, скажімо, на абсолютно новий жорсткий диск? Я звик бачити, що на видаленні жорсткого диска не встановлюють.

Немає сенсу робити кілька проходів. Раз достатньо.

Наповнення диска, що підлягає шифруванню, випадковими даними в основному має два варіанти використання:

• позбутися старих, незашифрованих даних
• зробити вільний простір невідрізним від зашифрованих даних

Зазвичай, якщо ви шифруєте, ви не хочете, щоб хтось бачив ваші дані. Тож є ймовірність, що якщо на цьому диску ви мали старі незашифровані дані, ви також хочете їх позбутися. SSD може допомогти простіше і швидше blkdiscard. Насправді, Linux mkfsTRIM поширює всі дані, навіть не вимагаючи підтвердження, що робить неможливим відновлення будь-якого типу. У Linux занадто багато TRIM.

Вільний простір - трохи сіра зона. Якщо попередньо не заповнити випадковими даними, на абсолютно новому жорсткому диску, сектори, про які ніколи не було записано, будуть нулями. На SSD, якщо ви дозволите скинути / TRIM, вільний простір також буде нульовим.

Хоча це жодним чином не впливає на ваші дані (вони все ще зашифровані), воно виявляє, скільки вільного простору / фактичних даних у вас є, і де цей вільний простір / дані розміщені. Наприклад hexdump -C, зашифрований, оброблений SSD буде виглядати приблизно так:

# hexdump -C /dev/ssd | grep -C 2 '^\*'
...
--
b3eabff0  dc c9 c7 89 16 ca d3 4f  a3 27 d6 df a0 10 c3 4f  |.......O.'.....O|
b3eac000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
b3f70000  5a 99 44 b5 9c 6b 1e 9c  81 cf 9a 43 b6 23 e9 0f  |Z.D..k.....C.#..|
b3f70010  2c e6 9a 5d 59 9b 46 5f  21 3f 4d 5f 44 5b 0a 6b  |,..]Y.F_!?M_D[.k|
--
b3f70ff0  5f 63 8d e8 c4 10 fd b1  a6 17 b5 7d 4a 57 09 68  |_c.........}JW.h|
b3f71000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
b3f72000  5d 1c 09 dd c9 6b 57 18  db 67 e1 35 81 57 45 8e  |]....kW..g.5.WE.|
b3f72010  0f a8 be 39 ae e5 5f cf  cf e3 8b a7 c1 25 1a a3  |...9.._......%..|
--
...

З цього ви можете сказати , що я є вільні сегменти простору за адресою 0xb3eac000 .. 0xb3f70000, b3f71000 .. b3f72000... і зворотна що із сегментів даних , звичайно , як 0xb3f70000 .. b3f71000.

Що ти можеш з цим зробити? Ну нічого (*).

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

Однак такі міркування є дуже теоретичними і мають дуже низький ризик порівняно з тим, наскільки вразливі найбільш зашифровані установки, зумовлені іншими причинами. У більшості випадків, коли встановлено вікно, швидше / простіше просто підробити initramfs, встановити кейлоггер або використовувати запущену систему, ніж якось отримати доступ до сировини та аналізувати зашифровані дані та сподіватися досягти цього будь-чого.

Перш за все, варто потурбуватися про них, перш ніж потурбуватися про виявлення вільного місця.

З SSD цілком нормально ввімкнути TRIM і, таким чином, відкривати вільний простір постійно. Це також стосується рішень для шифрування, які працюють на файловому шарі, а не на рівні блоку.

Що стосується жорсткого диска, ви в основному робите випадкове стирання навіть на новому диску, тому що можете, і немає причин цього не робити, оскільки це не передбачає витрат (окрім першої установки) та жодних недоліків.