id: Гость   вход   регистрация
текущее время 17:01 21/11/2017
Автор темы: Гость, тема открыта 08/03/2014 16:58 Печать
Категории: инфобезопасность, защита дисков
http://www.pgpru.com/Форум/UnixLike/ПодготовкаКРаботеБуSsd
создать
просмотр
ссылки

Подготовка к работе б/у ssd


minisata ssd должен быть использован для установки на него debian 7 x64 с encrypted lvm. lvm будет настроен с использованием стандартных функций установщика.
Дело в том, что данный ssd уже использовался в качестве системного с той же ОС, но без lvm и без dm-crypt, т.е. был самым простым стандартным образом рамечен установщиком.
Вопрос состоит в том, как правильно приготовить данный ssd к использованию в качестве системного с encrypted lvm, с учетом следующего таких особенностей ssd, как чувствительность к многократной перезаписи, особенностям хранения данных.
Достаточно ли будет просто направить на устройство поток нулей, либо urandom.
Должна ли команда

быть модифицирована в случае с SSD?
Скажем, достаточно ли пройтись по диску командой:

Избыточна ли одна такая команда, либо наоборот недостаточна? А может, будет достаточно только нулей?
Спасибо.


 
Комментарии
— Гость (09/03/2014 02:39)   <#>
Большинство ответов на ваши вопросы содержатся в старых топиках, рекомендую их все прочитать:
  1. Угроза восстановления перезаписанных данных с флешек и SSD. Есть ли аналогии с МСМ для винчестеров?
  2. Надёжное удаление данных с SSD-накопителей
  3. Использование SSD при шифровании
  4. Полное дисковое шифрование SSD
  5. Так все же SSD диск криптовать полностью или нет?
  6. Посоветуйте надежные microSD!
  7. /comment39601
  8. /comment72188 (HPA)
  9. SSD не дружит с отрицаниемым шифрованием, если что.


Чтобы очистить основную область — да. Это не гарантирует зачистки так называемых резервных блоков / HPA. В общем случае, ничего не гарантирует их зачистку, поэтому 100% гарантии вам никто не даст, если только вы сами с паяльником и спецаппаратурой туда не залезете и не проверите, как работает ваш проприетарный насквозь микроконтроллер. Считаете ли вы для себя этот риск (незачищенные резервные блоки) приемлемым — решать вам.

В качестве полумеры можно записать всюду нули, а потом сделать sync. Поидее, это должно затереть дисковое пространство, за исключением, разве что, того небольшого объёма данных, которое попадёт в резервные блоки / HPA. Если это не устраивает, покупайте новый носитель. Вообще говоря, намного проще сразу всё шифровать, что пишется на диск, чем потом морочить себе голову зачисткой старых данных.

Кстати, этот топик тоже рекомендую прочитать.
— unknown (09/03/2014 16:51)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Если записывать нули непосредственно на носитель, то есть вероятность, что в SSD используется аппаратное архивирование и нули очень хорошо пожмутся, заполнив крайне мало от физически находящегося там полного размера. При этом, контроллер может показать, что всё занулено до отказа, а оставшуюся недоступную для прямого чтения часть использовать под резервные блоки.

Поскольку любой носитель всё равно лучше затирать (псевдо)рэндомом (шифрованные нули — это тоже псевдорэндом), то лучше заполнить носитель полностью рэндомом, затем сделать sync, а затем ещё раз пройтись рэндомом и сделать sync. Это с некоторой веротностью позволит обойти сохранение контроллером флэш-носителя резервных блоков. Хотя, не все алгоритмы выделения блоков для резервирования могут быть преодолены таким способом.

Так что, задача мало отличается от недавно обсуждаемой темы, разве что использованием двух проходов, чередуемых sync.
— Гость (10/03/2014 04:52)   <#>

А оно действительно существует, или это всего-лишь предположение? И есть ли такое аппаратное архивирование также в флэшках, SD-картах?


А три прохода не будет лучше, чем два? Вдруг 2 прохода не повлияют на какие-то резервные блоки, а три повлияют. Такое может быть?
— Гость (10/03/2014 06:09)   <#>

Я как-то давно встречал случай, когда карта CompactFlash не писала нули, т.е., нули как-то отмечались, но пропускались, за счет чего карта работала быстрее. И в первых SSD, не поддерживающих TRIM, использовалось обнаружение нулевых секторов для очистки ячеек флеша. Однако, именно про сжатие не слышал.

Насколько я знаю, когда TRIM стал поддерживаться, детектить и сжимать нули (это касалось CompactFlash-карточкек и первого поколения SSD, очень древних; SD-карточек это не касается) стало бессмысленно. Сейчас все полагаются на TRIM, а на поддержку неTRIM'овых девайсов операционные системы забили. И именно поэтому сейчас без TRIM'а ресурс мизерный.
— Гость (10/03/2014 07:25)   <#>
На SSD, насколько я знаю, для стирания данных вообще не нужна перезапись: операция erase для флеша — это отдельная, третья операция. Её можно инициировать либо TRIM'ом (частичное стирание, узнать о завершении нельзя), либо командой SECURE ERASE (полное стирание, синхронное); перезапись же блока может как вызывать стирание, так и не вызывать, поскольку у контроллера сложные алгоритмы оптимизации износа: он может записать в новый свободный блок, а старый поставить в очередь.


Да, согласен, встречал такое. Если перезаписывать, то только рандомом.


Это минимально достаточное количество, чтобы заставить контроллер стереть резервные блоки. Если перезаписать только 1 раз, данные могут остаться в HPA в резервных блоках, которых бывает до 20-30% от емкости накопителя. Нужно перезаписать два раза — это дает надежду, что резервные блоки перезапишутся, так как 100% резерва не имеет ни один накопитель. Можно сделать SECURE ERASE, если накопитель его поддерживает (а я где-то слышал что есть накопители, которые игнорируют эту команду и ничего не стирают).

Как сделать гарантированное частичное старание данных с SSD — вообще не знаю. По-моему — никак: либо полное, либо полагаться на TRIM.
— Гость (02/03/2015 20:58)   <#>

Это как?

И у меня такой чайниковский вопрос. Если я создаю на ЧАСТИ SSD винта раздел (дальше его шифрую или записываю файлы, а затем удаляю и собираюсь ПОВЕРХ них записать другие и т.п.), то создаваться/удаляться этот логический раздел будет физически "на одном и том же месте" (в тех же кластерах памяти) или нет? Я понимаю, что для надежности нужно не пользоваться SSD для секретов, а на крайний случай затирать ВЕСЬ диск, но все-таки диск большой, а критических данных на 1% и мне важно знать "размажутся" эти 1% по диску или нет и можно ли будет их как-нибудь целиком прибить?
(у меня тот случай, что я не могу создать файловый криптоконтейнер на открытой ФС)
— unknown (02/03/2015 21:13)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Вот именно, что нет — все ячейки SSD пишутся по кругу. Кроме того, там ничего не удаляется, если не используется TRIM и то не факт, что там происходит внутри, какие коды избыточности используются.
— Гость (03/03/2015 06:50)   <#>

Если TRIM выключен, отрицаемость будет, но ценой быстрого износа диска, появления bad-блоков и т.д. Если TRIM включён, износ уменьшится, но пропадёт отрицаемость.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3