При отправке SSD обратно, диск зашифрован; как стирается стирается? [дубликат]
На этот вопрос уже есть ответ здесь:
- Каков рекомендуемый способ очистки SSD? 5 ответов
У меня проблема с моим OCZ SSD куда "пропадает" ОС при стрессе или вроде бы при нагреве. Если я сделаю слишком много циклов чтения / записи, диск исчезнет. Я смог остудить его, поставив холодильник и поставив резервную копию. В некоторых больших файлах отсутствуют части; при rsyncing он передаст половину файла, после чего операция остановится. Некоторые папки, в которых должны быть файлы, при открытии ничего не возвращают.
Я возвращаю его в Toshiba по гарантии, но меня слегка беспокоит, что некоторые из моих файлов могут быть доступны, если диск подлежит ремонту. Это могут быть личные файлы, семейные фотографии, связка ключей с моим паролем, исследования и т. Д., и хотя я подозреваю, что сотрудники Toshiba будут действовать профессионально, должная осмотрительность подсказывает мне, что я должен стереть диск.
Я перезаписал первую часть диска, пытаясь проверить, не виноват ли мой привод или мой компьютер. Диск был зашифрован; он перезаписал ключ и, по крайней мере, часть индекса, но мне интересно, есть ли ключ в конце.
Я знаю, что TruCrypt имеет в конце резервный ключ, чтобы вы могли восстановить диск; Ubuntu делает то же самое? Диск зашифрован, поэтому я думаю, что если я сотру ключи, его нельзя будет восстановить.
Кроме того, я знаю, что есть инструменты для переключения битов в окнах, есть ли способ сделать это в Ubuntu?
2 ответа
Заголовок LUKS расположен в начале раздела, по умолчанию это - 2 мебибайт, но может быть проверено с sudo cryptsetup luksDump /dev/your_device. Смещение полезной нагрузки (обычно 4096) времена, которые - 512 байтов то, где зашифрованные данные запускается.
можно перезаписать тех первых 2 мебибайт, с, например,
dd if=/dev/urandom of=/dev/your_device bs=1M count=2.
существует очень маленький шанс, что SSD перераспределил секторы заголовка LUKS где-то в другом месте, но это довольно маловероятно, поскольку заголовок LUKS часто не изменяется (только при изменении пароля).
, Если Вы хотите Вас, может также попытаться использовать SSD внутренний механизм стирания: поскольку детали видят: https://www.thomas-krenn.com/en/wiki/SSD_Secure_Erase, Конечно, встроенное микропрограммное обеспечение SSD является собственным, таким образом, нет никакого пути к надежно теперь, защищает ли это действительно стирание. Но для всех практических целей необходимо быть в безопасности.
При перезаписи ключей зашифрованного тома LVM, данные неисправимы. Однако посмотрите ниже.
существует несколько инструментов, доступных для зеркального отражения битов. Примерами является 'очистка' 'sdelete' и 'средство стирания'. Вы можете склонный - получать очистку установки, или склонный - добираются, безопасная установка - удаляют (или nwipe или очистка наутилуса...)
, параноидальная точка зрения (и также мой) состоит в том, что они не обеспечивают надежное удаление на современных дисках, и возможно особенно на SSD. Причина состоит в том, что диски имеют контроллеры, которые могут кэшировать "интересные" данные в невидимых местоположениях. SSD определенно поворачивают адреса памяти для "износа, выравнивающего" цели, и таким образом возможно, что "зеркально отраженные битом" данные могут иметь копии где-нибудь, который не адресуем - и таким образом не становится зеркально отраженным битом.
даже возможно, что встроенное микропрограммное обеспечение диска может невидимо скопировать ключи шифрования диска. (Что могло меня более "интересный", чем они?)
необходимо будет решить, сколько риска приемлемо, при этом самая экстремальная опция является физическим разрушением диска.
С уважением, Богатый