Comments 43
При безопасном удалении (то есть с гарантией невосстановимости данных) основная цель — не просто удаление данных, но получение неопровержимых доказательств невосстановимости. Одним из неопровержимых доказательств невосстановимости можно считать размер оставшихся данных. Я считаю, что 2мм — достаточно маленький размер оставшихся данных, чтобы считать их невосстановимыми.
А все софтовые методы — это «верьте нам, люди, в нашей фирмваре нет багов».
А все софтовые методы — это «верьте нам, люди, в нашей фирмваре нет багов».
Отечественный ГОСТ P50739-95 рекомендует стирать информацию путем полной перезаписи секторов. При этом, не оговаривается сколько раз требуется это сделать и, как мы уже говорили, что данный метод не совсем эффективен, ибо данные можно восстановить специальным оборудованием.
Опять эти сказки про остаточную намагниченность.
Вообще, на современных носителях, есть вероятность, что после перезаписи довольно много данных можно будет восстановить, если читать ячейки минуя прошивку. (Речь про SSD, конечно).
Восстановить после _перезаписи_?
PBA > LBA, поэтому перезаписать весь объём надо два раза.
Конечно. Когда вы пишите в «сектор» с номером 42, прошивка делает lookup в ftl (Flash translation layer) и решает куда именно присунуть ваш сектор. Допустим, в этот раз оно пошло в чип номер 2 блок 3. В следующий раз при записи в сектор 42 его присунули (к другим данным) в чип номер 19 блок 22. И так почти неограниченное количество раз. С учётом, что SSD underprovisioned для того, чтобы было место для реаллокаций и GC, надеяться, что вы «перезапишите всё» перезаписав тот объём, который видно наружу, мягко говоря, наивно.
С учётом, что SSD underprovisioned
на десктопных (да и на серверных) накопителях объём резервной области не так уж велик, так что двукратная перезапись объёма носителя выглядит разумным компромиссом.
В соответствующем исследовании было показано, что даже на дескптопных всё равно часть информации сохраняется в ячейках, даже после многократной перезаписи.
а можно пруф? любопытно почитать
Если напомните в понедельник, я в рабочих заметках посмотрю ссылку на исследование. Там люди снимали чипы с платы и ковырялись в памяти мимо контроллера - и находили куски, проходящие по чексуммам с записанными данными, после множества перезаписей.
напоминаю, хоть сегодня и не понедельник.
после множества перезаписей
тут важно после множества перезаписей какого-то файла/области или после множества перезаписей всего объёма накопителя.
если первое, то это нормально. второе же, на мой взгляд, всё-таки маловероятно.
Спасибо за напоминание. Вот ссылка https://www.usenix.org/legacy/events/fast11/tech/full_papers/Wei.pdf
A >20 N/A∗N/A∗N/A∗
Для образца A нужно больше 20 полных перезаписей, чтобы уничтожить все следы данных на уровне чипов памяти.
Алсо, я эту статью нашёл, когда работал над изучением secure-erase, и, сюрприз, у меня в коллекции есть драйв, который после blkdiscard полностью сохраняет всё содержимое, прям монтировать можно.
спасибо, да, интересная статья
Для большинства хватило двух полных перезаписей и с тех пор больше моделей обзавелись внутренним шифрованием (вопрос к его реализации).
В итоге для быстрого и гарантированого уничтожения данных надо брать SED с внешними ключами либо WD Ultrastar с ISE, который точно работает.
Как много программ и картинок. Добавлю еще одну.
Каким таком образом, программы, перечисленные в конце статьи и ВЫБОРОЧНО удаляющие папки и файлы могут что-либо гарантировать на SSD?
Спасибо за статью!
Сложил в копилку — буду применять при необходимости и возможности.
Сложил в копилку — буду применять при необходимости и возможности.
Думаю shred /dev/sdX достаточно надежно удалит информацию. Конечно, firmware в SDD всегда может что-то спрятать в резервных блоках, но вероятность того, что оно спрячет критически важные секторы — крайне мала, да и резервных блоков не так уж и много.
Думаю shred /dev/sdX достаточно надежно удалит информацию.
Еще надежнее будет, если после shred /dev/sdX запустить команду blkdiscard /dev/sdX
Что-то я не понимаю, почему нельзя просто:
1. Удалить все файлы
2. Записать мусорных данных под завязку
3. Флашнуть буфера
4. Удалить записанный мусор
5. Отправить команду TRIM и подождать минутку?
Проблема только в резервных блоках?
1. Удалить все файлы
2. Записать мусорных данных под завязку
3. Флашнуть буфера
4. Удалить записанный мусор
5. Отправить команду TRIM и подождать минутку?
Проблема только в резервных блоках?
Хороший подход для FAT32. На современных FS проблема в том, что ntfs MFT (и аналоги для ext) этим не перезапишется и как минимум, останется информация о названиях файлов, которые мы удалили. А это может быть критичной утечкой. Ещё современные FS сохраняют в MFT Record мелкие файлы, как и директории, чтобы не тратить на 10-байтный файл целый кластер. Этим способом их сложно гарантированно перезаписать.
Тогда вместо первого пункта сделать быстрое форматирование. Этим ведь должна создаться новая таблица (и копия).
Не уверен, что вся таблица будет полностью перезаписана. Зачем это, когда достаточно обнулить поле, которое показывает её занятый размер.
Например затем, чтобы разместить таблицу и её копию.
Копия MFT размещается, как я помню, посередине раздела (для надёжности), а не две подряд в начале раздела (как это было с FAT).
То есть, чтобы очистить MFT и её копию, достаточно перезаписать один сектор в начале раздела и один сектор в середине.
То есть, чтобы очистить MFT и её копию, достаточно перезаписать один сектор в начале раздела и один сектор в середине.
Итого два сектора? Нет, MFT занимает гораздо больше пространства (строго говоря, один сегмент файловой записи MFT – это 1024 байта или 4096 байтов, а таких сегментов много, по одному на каждый файл как минимум).
Долго спорите. Полное форматирование в exFAT, затем быстрое форматирование в NTFS, включаем EFS/Bitlocker на весь том и забиваем файлами под завязку попутно включив сжатие. Особые извращенцы могут делать это на серверной системе включив на томе еще и дедупликацию.
После этого никто ничего уже не достанет кроме рэндомных байтов.
После этого никто ничего уже не достанет кроме рэндомных байтов.
Тогда в приведенном алгоритме надо первый пункт
1. Удалить все файлызаменить на
1. Отформатировать удаляемый раздел в FAT32
TRIM ничего не обязан делать. Многие накопители делают TRIM в фоном режиме «когда-нибудь».
К примеру, некоторые модели плат не обладают подобной возможностьюК счастью, благодаря тому, что с UEFI-прошивкой работать гораздо проще, чем с BIOS, вытащить нужный модуль из одной прошивки и воткнуть его в другую должно быть несложно. Например, есть успешный опыт по замене скриншотера (который на асусах вызывается по F12) на EFI Shell.
Другое дело, что отключать и подключать питание к диску физически — процесс не самый удобный. Быстрее будет загрузиться c какого-нибудь Parted Magic, который позволяет подготовить диск к Secure Erase без необходимости залезать внутрь ПК.
Общеизвестный CCleaner тоже имеет функцию безопасного стирания дисков. Также хорошая программа для этих целей – PrivaZer.
Столько разных скринов, а самое главное забыли:
sudo hdparm --user-master u --security-set-pass password /dev/sdX
sudo hdparm --user-master u --security-erase-enhanced password
А ещё про Host Protected Area
https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm
Вставлю свои три копейки.
Загружаемся в Knoppix 8.2 открываем терминал
Получаем права администратора запустив su
# su
проверяем не заблокирован ли диск(SSD) (далее предполагается что диск у нас про именован как sda, в ином случае обязательно меняйте имя диска на то что прописала система)
# hdparm -I /dev/sda | grep frozen
Если выходит frozen
разблокируем диск командой
# echo mem > /sys/power/state
Как уснет компьютер будим его любой клавишей
Проверяем еще раз, что диск не заблокирован «not frozen»
# hdparm -I /dev/sda | grep frozen
Если все успешно выполняем
# hdparm --user-master u --security-set-pass PasSWorD /dev/sda
security_password=«PasSWorD»
Должно выйти
и затем
# hdparm --user-master u --security-erase PasSWorD /dev/sda
security_password=«PasSWorD»
вывод команды
Загружаемся в Knoppix 8.2 открываем терминал
Получаем права администратора запустив su
# su
проверяем не заблокирован ли диск(SSD) (далее предполагается что диск у нас про именован как sda, в ином случае обязательно меняйте имя диска на то что прописала система)
# hdparm -I /dev/sda | grep frozen
Если выходит frozen
разблокируем диск командой
# echo mem > /sys/power/state
Как уснет компьютер будим его любой клавишей
Проверяем еще раз, что диск не заблокирован «not frozen»
# hdparm -I /dev/sda | grep frozen
Если все успешно выполняем
# hdparm --user-master u --security-set-pass PasSWorD /dev/sda
security_password=«PasSWorD»
Должно выйти
/dev/sda:
Issuing SECURITY_SET_PASS command, password=«PasSWorD», user=user, mode=high
и затем
# hdparm --user-master u --security-erase PasSWorD /dev/sda
security_password=«PasSWorD»
вывод команды
/dev/sda:
Issuing SECURITY_ERASE command, password=«PasSWorD», user=user
Получается на ссд и флешках глупо вайпать отдельный файл?
Верно, насколько я понимаю. Если надо вайпать не весь диск — скорее всего потребуется 1) удалить файл, 2) вайпать свободное место N раз. N зависит от объёма диска, объёма свободного места и т.п.
Вайпать имеет смысл, чтобы исключить «простой» доступ — через чтение секторов, где находился файл. Это не спасёт от взлома контроллера или прямого чтения чипов памяти, но такое мало кому доступно.
Kingston SVP200S37A/120g фирменная тулза через USB dock вообще не находит диск, хотя Windows 10 его спокойно определяет.
Для тех, кто так же как я зашел в этот пост чтобы найти как очистить NVMe подскажу команду:
nvme format -s1 /dev/nvme0n1
Кусок `man nvme-format`
-s <ses>, --ses=<ses>
Secure Erase Settings: This field specifies whether a secure erase should be performed as part of the format and the type of the secure erase operation. The erase applies to all user data, regardless of location (e.g., within an exposed
LBA, within a cache, within deallocated LBAs, etc). Defaults to 0.
┌──────┬──────────────────────────────────────────────────────────────────────────────────┐
│Value │ Definition │
├──────┼──────────────────────────────────────────────────────────────────────────────────┤
│0 │ No secure erase operation requested │
├──────┼──────────────────────────────────────────────────────────────────────────────────┤
│1 │ User Data Erase: All user data shall be erased, contents of the user data after │
│ │ the erase is indeterminate (e.g., the user data may be zero filled, one filled, │
│ │ etc). The controller may perform a cryptographic erase when a User Data Erase is │
│ │ requested if all user data is encrypted. │
├──────┼──────────────────────────────────────────────────────────────────────────────────┤
│2 │ Cryptographic Erase: All user data shall be erased cryptographically. This is │
│ │ accomplished by deleting the encryption key. │
├──────┼──────────────────────────────────────────────────────────────────────────────────┤
│3–7 │ Reserved │
└──────┴──────────────────────────────────────────────────────────────────────────────────┘Sign up to leave a comment.
Видишь данные? Нет. Вот и я не вижу, а они есть. Уничтожаем данные на SSD-накопителях, да ещё и скорость восстанавливаем