Надёжное удаление данных с SSD-накопителей
Возможно, некоторые уже успели познакомиться с двумя опубликованными недавно исследованиями о проблемах надёжного удаления и восстановления информации с твердотельных накопителей (solid state drive, SSD). Накануне в Компьютерре вышла статья Киви Берда[link1], подытоживающая обе работы. Резюме:
Если вы хотите восстановить удаленные данные, то сделать этого вы не можете. Если вы хотите их уничтожить, то и этого сделать вы не можете. Это такой Закон Мерфи для хранения данных на SSD.
(Ссылки на сами работы приведены в статье.)
К сожалению не рассмотрен вариант с уничтожением данных не штатными средствами затирания жестких дисков, а простым заполнением всего объема флэш-накопителя данными (вариант двух-трехкратного заполнения сразу после стирания предыдущих). Как-то сомнительно, что со всеми резервными ячейками 75% уничтожаемых данных при этом сохранятся.
Возможно, от этого варианта отказались ввиду его ненадёжности: неизвестно, какие данные в действительности окажутся перезаписаны, а какие нет, оказавшись в резервных областях.
Что как бы символизирует, что ssd целиком не затирался.
Я думаю, что здесь есть проблема подчинения. Есть большая ОС-А, представляющая собой ОС компьютера. И есть маленькая ОС-Б, представляющая собой внутреннюю маленькую ОС флеш-устройства. Этот как в большой организации, где есть генеральный директор, представляющий собой ОС-А, и начальники отделов, представляющие собой ОС-Б. Генеральный директор в данной роли задает стратегию организации но может не знать тактики, выбор которой берут на себя начальники отделов. Особенно критично это становится в том случае, если в роли начальников отделов выступают подрядные организации (производители флеш-накопителей), старающиеся максимально-эффективным способом с наименьшими затратами времени и ресурсов выполнить определенную задачу.
Если говорить о проблеме подчинения, то рано или поздно то же самое моежет начаться и с накопителями на жестких дисках, хотя учитывая их нынешние размеры и отработанность технологий, а так же особенности их работы (перемещение головок) вряд ли это случиться.
И вот вопрос, что подразумевается под резервными областями? Простые свободные ячейки памяти или какие-то более сложные вещи, связанные с технологией устройства накопителей?
Мне кажется, что решение все-таки должно быть, если контроллер носителя не работает на основе какого-либо алгоритма шифрования с вшитым ключом, ведь он успешно извлекает те данные, которые требует операционная система компьютера.
Если обработка bad-блоков поручена контроллеру, то это оно и есть!
...Только в значительно меньших масштабах.
С момента первого публичного упоминания проблемы сбора мусора на SSD-накопителях (с точки зрения восстановления данных) до выхода обсуждаемой статьи прошло 2,5 года. Для компьютерной криминалистики это довольно приличный срок признания проблем и узких мест :)
Удалённые данные на SSD — прямо кот (или уже код?) Шрёдингера какой-то :)
Просто хранить и удалять данные надо, как бы не хотелось иного, учитывая физическую природу носителя. Если файловая система учитывает минимальный физический размер "сектора", тогда при реальной поддержке накопителем стандартов (команды TRIM), обычное удаление файла из файловой системы будет надежней для SSD чем 3-ех кратная перезапись непонятно каких байт в непонятно где.
А если она не совсем реальная? Как проверить то, кроме как ковыряя железку теми же методами, которые предлагают эксперты?
Если в будущем SSD вытеснят традиционные HDD, то возможно разработают для них какие-нибудь режимы шифрования, вместо того, чтобы использовать TRIM[link2].
Например, наивный вопрос — в SSD скорость доступа совсем не зависит от расположения и порядка следования секторов (безразличие к дефрагментации, возможность доступа к случайным адресам за равные промежутки времени)? Тогда можно теоретически разработать режим шифрования, который будет не только шифровать секторы, но и размещать их в криптостойко-псевдослучайном (зависящем также от ключа) порядке по SSD (всему выделенному разделу, виртуальному тому). Они будут размещены случайно в виртуальном представлении и неважно, как их там ещё физически по диску раскидает. При уничтожении ключа (подборе пароля) будет трудно восстановить данные, даже при наличии нескольких копий секторов — непонятно в каком порядке они следуют, какие из них реальные, какие затёртые (но не принадлежат данному разделу), какие остались от прошлых данных.
Возможно, если такого рода алгоритмы удасться разработать и реализовать, то всяким скрытым разделам и отрицаемым томам это даже пойдёт на пользу.
P.S. Похоже не получится из-за особенностей записи: 4 kB на страницу (ещё куда ни шло) и 512 kB блоков (если при записи нужно очищать целиком их — то слишком накладно).
Может кто подскажет точнее?
Вот это врядли. Эти не вытеснят. Тупиковая ветвь развития твердотельных накопителей это.
Ну не эти. Какие-нибудь другие с произвольным доступом.
Ну это же наивняк... восстанавливают файлы со стёртых UNIX-ФС, и вполне успешно.
Это так и есть на большинстве флеш накопителей, см. wear leveling.
Так именно и пришла в голову мысль, чтобы этого не было. Дополнить antiforensic-алгоритм хранения заголовков ключа в LUKS полностью перемешанной картой секторов чтения-записи, от этого ключа и зависящей. Т.е. ещё один слой между шифрованием и FS — слой, перемешивающий секторы.
unknown, после однократной перезаписи, как я понял, логические номера секторов будут затерты. Выживут только некоторые сектора.
Я почему-то думаю, что если такие накопители и будут производится, то база ключей будет сохраняться где-нибудь на секретных задворках фирм-производителей, что бы можно было в случае чего передать нужный ключик каким-либо силовым структурам.
Аппаратное шифрование здесь совершенно не причём. Так ему кто-то и доверится!
В том-то и дело, что это должен быть программный драйвер, просто использующий свойства носителя. А контроллер внутри такого носителя не будет настолько умным, чтобы выцеплять ключи из контейнера на SSD. Это кстати ещё и аргумент в пользу криптоконтейнеров с заголовком, не имеющим сигнатур.
Прошу прощения за возможно смешной для спецов вопрос. А какие именно программы (или какие опции каких программ) создают криптоконтейнеры БЕЗ любых прямых или косвенно-опознаваемых сигнатур?
TrueCrypt и plain mode в cryptsetup [1][link3], cgd и, возможно, vnconfig [2][link4].