id: Гость   вход   регистрация
текущее время 14:14 19/04/2024
Автор темы: Гость, тема открыта 11/03/2010 11:57 Печать
Категории: инфобезопасность, защита дисков, уничтожение информации, хард
https://www.pgpru.com/Форум/ТехническиеВопросы/УгрозаВосстановленияПерезаписанныхДанныхСФлешекИSSDЕстьЛиАналогииСМСМДляВинчестеров
создать
просмотр
ссылки

Угроза восстановления перезаписанных данных с флешек и SSD. Есть ли аналогии с МСМ для винчестеров?


Как известно, есть принципиальная возможность восстановить с магнитного носителя (винчестера) первоначальные данные перезаписанные впоследствии произвольными. Для восстановления используются следы от случайных колебаний магнитной головки по бокам от магнитной дорожки. Самый продвинутый(и дорогой) метод для восстановления таких данных – это магнитно-силовая микроскопия (МСМ). Существуют также программные методы надёжного удаления, для противодействия МСМ, состоящие в многократной перезаписи.


Вопрос: Существуют ли функциональные аналоги методов МСМ и, соответственно, многократной перезаписи по отношению к FLASH-накопителям и SSD? Т.е. можно ли восстановить перезаписанные данные с указанных типов носителей? И если можно, то как этому помешать?


 
На страницу: 1, 2 След.
Комментарии
— SATtva (11/03/2010 12:39)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Учитывая современные плотности записи на магнитных носителях (приблежающиеся к атомному порогу) и методы кодирования данных, угроза МСМ едва ли актуальна даже при паре перезаписей.

Looking at this from the other point of view, with the ever-increasing data density on disk platters and a corresponding reduction in feature size and use of exotic techniques to record data on the medium, it's unlikely that anything can be recovered from any recent drive except perhaps a single level via basic error-cancelling techniques. In particular the drives in use at the time that this paper was originally written have mostly fallen out of use, so the methods that applied specifically to the older, lower-density technology don't apply any more. Conversely, with modern high-density drives, even if you've got 10KB of sensitive data on a drive and can't erase it with 100% certainty, the chances of an adversary being able to find the erased traces of that 10KB in 80GB of other erased traces are close to zero.
Peter Gutmann "Secure Deletion of Data from Magnetic and Solid-State Memory"

Касаемо полупроводниковых накопителей, смотрите новую работу Гутмана "Data Remanence in Semiconductor Devices".
— Гость (11/03/2010 13:29)   <#>
====Data Remanence in Semiconductor Devices====

Peter Gutmann

IBM T. J. Watson Research Center

...
7. Conclusion
Although the wide variety of devices and technologies in use, and the continuing introduction of new technologies
not explicitly addressed in this work, make providing specific guidelines impossible, the following general design
rules should help in making it harder to recover data from semiconductor memory and devices:

Don’t store cryptovariables for long time periods in RAM. Move them to new locations from time to time
and zeroise the original storage, or flip the bits if that’s feasible.

Cycle EEPROM/flash cells 10-100 times with random data before writing anything sensitive to them to
eliminate any noticeable effects arising from the use of fresh cells (but see also the point further down
about over-intelligent non-volatile storage systems).
15

Don’t assume that a key held in RAM in a piece of crypto hardware such as an RSA accelerator, which
reuses the same cryptovariable(s) constantly, has been destroyed when the RAM has been cleared. Hot-
carrier and electromigration effects in the crypto circuitry could retain an afterimage of the key long after
the original has leaked away into the substrate.

As a corollary, try and design devices such as RSA accelerators which will reuse a cryptovariable over and
over again in such a way that they avoid repeatedly running the same signals over dedicated data lines.

Remember that some non-volatile memory devices are a little too intelligent, and may leave copies of
sensitive data in mapped-out memory blocks after the active copy has been erased. Devices and/or
filesystems which implement wear-levelling techniques are also problematic since there’s no way to know
where your data is really going unless you can access the device at a very low level.
Finally, however, the best defence against data remanence problems in semiconductor memory is, as with the related
problem of data stored on magnetic media, the fact that ever-shrinking device dimensions (DRAM density is
increasing by 50% per year [74]), and the use of novel techniques such as multilevel storage (which is being used in
flash memory and may eventually make an appearance in DRAM as well [75]) is making it more and more difficult
to recover data from devices. As the 1996 paper suggested for magnetic media, the easiest way to make the task of
recovering data difficult is to use the newest, highest-density (and by extension most exotic) storage devices
available.
...

Спасибо! Таким образом, как я понял, наиболее общей рекомендацией для устройств с EEPROM/flash памятью является предварительная 10-100 кратная перезапись "свежей" памяти случайными данными. Вполследствии даже однократная перезапись должна обеспечить невозможность восстановления
— Гость (11/03/2010 13:30)   <#>
Горячая подборка из последнего о безопасном удалении информации с флэшек:
  1. /comment23780
  2. Поскольку флэш-память (в отличие от магнитных накопителей) не нуждается в многократной перезаписи, достаточно однократно заполнить всё свободное пространство флэшки случайными данными.
    /comment26486
  3. ... контроллер, осуществляя выравнивание частот записи, пишет блоки в разные места. Но и это не обязательно даёт гарантию, поскольку могут быть резервные блоки. Лучше брать новую [флэшку].
    /comment37449
— Гость (11/03/2010 13:43)   <#>
В общем, новую флешку раз 10-20 перезаписать всю полностью. Или лучше перезаписать с переформатированием. Кто нибудь предложит unattended последовательность консольных команд для этого? Можно ли это сделать стандартными средствами Windows? Если нельзя из консоли, то можно ли реализовать это vbs-скриптом?
— Гость (11/03/2010 20:44)   <#>
Лучше из новой флэшки с помощью TrueCrypt или DiskCryptor сразу устроить шифрованный диск.
— Гость (11/03/2010 22:46)   <#>
могут быть резервные блоки.
Дисковые накопители тоже помечают bad-блоки. Но ведь они не настолько bad, чтобы их нельзя было прочитать совсем?
— Гость (12/03/2010 09:56)   <#>
Лучше из новой флэшки с помощью TrueCrypt или DiskCryptor сразу устроить шифрованный диск.

Нет, не всегда лучше. Не везде откроется, нужно помнить пароль и т.п. Давайте не будем отвлекаться. В этом топике рассматривается просто надёжное удаление данных с флешки. Примем такие условия задачи. :)

В общем, новую флешку раз 10-20 перезаписать всю полностью. Или лучше перезаписать с переформатированием. Кто нибудь предложит unattended последовательность консольных команд для этого? Можно ли это сделать стандартными средствами Windows? Если нельзя из консоли, то можно ли реализовать это vbs-скриптом?


Давайте назовём это безопасной инициализацией флешки. Аргументы скрипта: логический том, количество циклов (форматирование носителя-создание файла со случайными данными на всё свободное пространство). По окончании циклов – стирание файла.

В крайнем случае принимаются скрипты на скриптовых языках позволяющих создание exe. Например, AutoIt или Perl. Но лучше конечно bat/cmd или vbs.
— Гость (12/03/2010 19:44)   <#>
DiskCryptor имеет опцию перед шифрованием 35 раз пройтись перезаписью по методу Гуттмана.
— Гость (13/03/2010 02:21)   <#>
Или лучше перезаписать с переформатированием.
Само форматирование не удаляет почти никаких данных, а всего-лишь прописывает заголовки и разметку. Его цель сама по себе может быть только в том, чтобы запутать противника.
— Гость (18/03/2010 13:30)   <#>
новую флешку раз 10-20 перезаписать всю полностью

Только не следует забывать при этом, что у flash-памяти кол-во циклов перезаписи где-то около 1 000 000, а для многоуровневой MLS и того меньше – около 10 000.
— Гость (18/03/2010 15:35)   <#>
новую флешку раз 10-20 перезаписать всю полностью

Только не следует забывать при этом, что у flash-памяти кол-во циклов перезаписи где-то около 1 000 000, а для многоуровневой MLS и того меньше – около 10 000.

Спасибо, не будем забывать. Но, согласитесь, сделать даже 100 перезаписей при ресурсе 10 000 – это достаточно приемлемо. Всего лишь 1% от ресурса в самом худшем случае... Притом, думается, что 10-ти перезаписей вполне достаточно.

Кто нибудь предложит unattended последовательность консольных команд для этого? Можно ли это сделать стандартными средствами Windows? Если нельзя из консоли, то можно ли реализовать это vbs-скриптом?

А как насчёт скрипта? Вроде бы просто...
— Гость (18/03/2010 16:44)   <#>
В этом топике рассматривается просто надёжное удаление данных с флешки. Примем такие условия задачи. :)
Уже писали, что чисто программным способом надёжно удалить данные не получится по причиине наличия резервных блоков.
Правда их и прочитать программно скорее всего не получится.
— Гость (18/03/2010 17:26)   <#>
Уже писали, что чисто программным способом надёжно удалить данные не получится по причиине наличия резервных блоков.
Правда их и прочитать программно скорее всего не получится.

Почти все основные производители flash-памяти используют свои собственные методы резервирования и коррекции ошибок, поэтому надо смотреть по каждому отдельно. Чисто теоретически, при наличии такой информации можно "перенасытить" резевирование определённым кол-вом полной перезаписи номинального объёма флешки :)
— Гость (18/03/2010 18:08)   <#>
определённым кол-вом
Ну да,
где-то около 1 000 000, а для многоуровневой MLS и того меньше – около 10 000.
:)
— Гость (18/03/2010 22:51)   <#>
Современные SSD поддерживают ATA команду TRIM, которая позволяет очистить ячейки памяти (контроллер немедленно инициирует стирание ячеек, чтобы увеличить скорость записи в них). Поддержка этой команды и другие оптимизации для SSD запланированы в DiskCryptor 1.0.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3