Ответ 1

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

Для дезинфекции целых дисков,... методы программного обеспечения работают больше всего, но не Все время. Мы обнаружили, что ни одно из доступных программ методы дезинфекции отдельных файлов были эффективными. [выделено мной]

NIST 800-88 также имеет хороший обзор технологических тенденций, способствующих этой проблеме, наряду с некоторыми минимальными рекомендациями (приложение A) для Android-устройства. Однако они имеют тенденцию быть либо стиранием всего диска (factory reset), либо полагаться на криптографическое стирание (CE), а не на общие методы стирания файлов.

Но все не потеряно. Даже если вы не можете дезинфицировать отдельные файлы, вы можете надеяться стереть все нераспределенное пространство после удаления файлов. В статье "Безопасное удаление" в файловых системах с журнальной структурой (Reardon и др.) Описывается довольно многообещающий способ сделать это в программном обеспечении пользовательского режима. Внутренняя память Android использует (всегда?) Файловую систему с лог-структурой.

Этот метод "очистки" не требует доступа на уровне ядра и, похоже, не требует какого-либо собственного кода на Android. (Обратите внимание, что термин "чистка" используется немного иначе в таких документах, как NIST 800-88.) Основная идея состоит в том, чтобы удалить все конфиденциальные данные, а затем заполнить оставшееся пространство на диске файлом данных мусора и, наконец, удалите файл мусорных файлов.

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

Предостережение и дальнейшие меры

Основная оговорка для меня - об условиях, упомянутых Reardon et al. в приведенной выше статье:

Очистка будет работать для любой файловой системы с журнальной структурой, обеспечивающей как дисковая квота пользователей неограничена, и файловая система всегда выполняет сбор мусора для восстановления даже одного фрагмента памяти до заявив, что диск неприемлем. [акцент мой]

Второе условие, похоже, скорее всего будет выполнено, но я не знаю о первом. Поддерживает ли Android (или некоторые версии этого производителя) квоты на дисковое пространство, используемое приложениями? Я не нашел информации о квотах пользователей, но есть квоты для других ниш, таких как постоянное хранилище браузера. Поддерживает ли Android некоторое пространство для использования системы или, например, для каждого кэширования приложений, которое нельзя использовать для других целей? Если это так, он должен помочь (хотя и без каких-либо гарантий), если мы начнем очищать сразу после удаления конфиденциальных файлов, поэтому мало времени для другой активности файловой системы, чтобы претендовать на недавно освобожденное пространство.

Возможно, мы могли бы уменьшить эти риски за счет циклической очистки:

• Определите оставшееся свободное пространство (назовите его S) в соответствующем разделе, например. используя File.getUsableSpace()
• Записать в раздел ряд файлов; каждый из них, скажем, составляет 20% от начального S (при условии ограничения размера файла).
• Когда у нас заканчивается пространство, удалите первую пару файлов, которые мы создали, а затем напишем другой файл или два, как позволяет пространство.
• Повторите этот последний шаг несколько раз, пока вы не достигли порога, которым вы удовлетворены. Может быть, до того момента, когда вы написали 2 * S файлов наполнителя; настройте это число, чтобы сбалансировать скорость с тщательностью. Насколько вам на самом деле нужно это делать, это была бы область для большего количества исследований.
• Удалить оставшиеся файлы-заполнители.

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

Я использую этот метод в тестовом приложении и опубликую его, когда он работает.

А как насчет карт формата microSD в формате FAT?

Будут ли такие же методы работать на внешних накопителях или картах microSD? FAT является блочно-структурированным, и применим ли метод очистки к SD-картам формата FAT?

На большинстве современных флэш-памяти, таких как CompactFlash и Защищенные цифровые карты, методы [износа] реализуются в аппаратного обеспечения с помощью встроенного микроконтроллера. На таких устройствах выравнивание износа является прозрачным, и на них можно использовать большинство обычных файловых систем как есть. (https://en.wikipedia.org/wiki/Wear_leveling)

... который подсказывает мне, что даже на SD-карте формата FAT износ выравнивания означает, что традиционные методы Gutmann не будут работать (см. его " Even More Epilogue" ) и что нужен метод, подобный "очистке".

Достаточно ли очистки, зависит от ваших параметров безопасности. Понижение износа, по-видимому, означает, что блок может быть "удален" в любое время, и в этом случае нет возможности стереть его без обхода уровня износа микроконтроллера. AFAIK это не может быть сделано в программном обеспечении, даже если у вас есть привилегии ядра; вам придется разрабатывать специальное оборудование.

Однако "выбытие" плохого блока должно быть довольно редким событием относительно жизни СМИ, поэтому для многих сценариев метод очистки будет достаточно безопасным.

Стирание трасс

Обратите внимание, что метод Гутмана имеет важную силу, а именно: стереть возможные следы старых данных на носителе, который может остаться даже после блок перезаписывается новыми данными. Эти следы теоретически могут быть прочитаны определенным злоумышленником с большим количеством ресурсов. Поистине тщательный подход к безопасному удалению увеличил бы метод, подобный Gutmann, с очисткой, а не заменяя его.

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

Используют ли существующие приложения эти методы?

У меня нет внутренней информации о приложениях в магазине приложений, но, глядя на обзоры приложений, таких как iShredder, в лучшем случае они используют такие методы, как "очистка" Рирддона. Например, они могут занять несколько часов, чтобы выполнить однократное протирание 32 ГБ свободного места.

Также обратите внимание на ограничения: обзоры некоторых приложений безопасного удаления говорят, что в некоторых случаях "удаленные" файлы по-прежнему доступны после запуска операции "безопасного удаления". Конечно, мы берем эти обзоры с зерном соли - есть вероятность ошибки пользователя. Тем не менее, я бы не предполагал, что эти приложения эффективны, без хорошего тестирования.

iShredder 4 Enterprise помогает использовать некоторые из алгоритмов, которые они используют, в описании своего приложения:

В зависимости от выпуска, пакет iShredder ™ поставляется с удалением алгоритмы, такие как DoD 5220.22-M E, ВВС США (AFSSI-5020), Армия США AR380-19, DoD 5220.22-M ECE, BSI/VS-ITR TL-03423 Стандарт, BSI-VS-2011, Стандарт НАТО, Gutmann, HMG InfoSec No.5, DoD 5220.22 SSD и другие.

Этот впечатляющий список дает нам несколько указаний на дальнейшие исследования. Неясно, как эти методы используются - по отдельности или в сочетании - и, в частности, представляется ли кто-либо из них эффективным как самостоятельно. Мы знаем, что метода Гутмана не было бы. Аналогичным образом, DoD 5220.22-M, AFSSI-5020, AR380-19 и Infosec № 5 указывают процедуры, аналогичные Gutmann для перезаписи секторов на жестких дисках, что неэффективно для флэш-носителей. Фактически, " Министерство обороны США больше не ссылается на DoD 5220.22-M как способ безопасного стирания жестких дисков ", не говоря уже о флеш-основе медиа, поэтому эта ссылка вводит в заблуждение для неосведомленных. (Предполагается, что DoD ссылается на NIST 800-88.) "DoD 5220.22 SSD" звучит многообещающе, но я не могу найти никаких информационных ссылок для этого. Я не преследовал остальных перечисленных алгоритмов, но результаты пока не обнадеживают.

Ответ 2

Когда вы удаляете файл со стандартными методами, например file.delete() или runtime.exec("rm -f my_file"), единственное задание, которое делает ядро, - это удаление информации о файле из структур вспомогательной файловой системы. Но секторы хранения, содержащие фактические данные, остаются нетронутыми. И из-за этого восстановление возможно.

Это дает представление о том, как мы можем полностью удалить файл - мы должны каким-то образом стереть все сектора. Самый простой способ - переписать все содержимое файла со случайными данными несколько раз. После каждого прохода мы должны очищать буферы файлов, чтобы гарантировать, что новый контент будет записан на хранение. Все существующие методы безопасного удаления файлов вращаются вокруг принципа выше. Например этот. Обратите внимание: универсальный метод не работает во всех типах хранения и файловых системах. Я думаю, вы должны поэкспериментировать самостоятельно и попытаться реализовать некоторые из существующих подходов или разработать свои собственные. Например. вы можете начать со следующего:

• Перезаписать и снять файл 10 раз со случайными данными (используйте методы FileOutputStream). Заметка!!! Не используйте нули или другие данные с низкой энтропией. Некоторые файловые системы могут оптимизировать такие разреженные файлы и оставить некоторые сектора с исходным контентом. Вы можете использовать /dev/urandom файл как источник случайных данных (это виртуальный файл, и он бесконечен). Это дает лучшие результаты и работает быстрее, чем известный класс Random.
• Переименуйте и переместите файл 10 раз. Немедленно выберите новые имена файлов.
• Затем обрезаем файл с помощью FileChannel.truncate().
• И, наконец, удалите файл с помощью file.delete().

Конечно, вы можете написать всю логику в собственном коде, это может быть даже несколько проще, чем в Java. Описанный алгоритм является просто примером. Попробуйте сделать так.

Ответ 3

Стандартный API файловой системы не даст вам простой вызов функции для этого.

Вам нужно будет использовать встроенный API-интерфейс для FileIO. Хотя я никогда не использовал его, theres библиотека для этого:

https://github.com/johanneslumpe/react-native-fs

Ответ 4

На этот вопрос есть два ответа.

Во-первых, чтобы ответить на прямой вопрос о том, как некоторые из этих приложений могут выполнять безопасное удаление одного файла: то, что вы делаете, фактически открывает файл и многократно заменяет содержимое нулями. Метод звучит глупо, но в прошлом я работал с шифрованием на уровне файловой системы на Android, и я обнаружил, что вышеуказанное верно для многих безопасных решений для удаления файлов. Для кажущейся совместимой системы безопасности вы можете повторять записи нулей 7 раз (или независимо от того, какие стандарты NIST указаны для вашего типа оборудования).

Charset charset = StandardCharsets.UTF_8;
String content = new String(Files.readAllBytes(path), charset);
content = content.replaceAll("*", "0");
Files.write(path, content.getBytes(charset));

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

Единственный безопасный способ удаления конфиденциального содержимого с диска - обнулить весь диск несколько раз, прежде чем отбрасывать диск.

@LarsH ответ об очистке всего нераспределенного пространства после удаления файлов является убедительным, но, возможно, непрактичным. Если вы просто хотите защитить файлы удаленных файлов, чтобы никто не мог сканировать диск для его восстановления, лучшим решением будет шифрование с полным диском. На самом деле это было всего лишь обращение к шифрованию с полным диском. Вот почему Apple прекратила поддержку безопасного удаления файлов в своих Mac OSX и iOS и по умолчанию на всех iPhone'ах перешла на полное шифрование диска. Сегодня телефоны Android также имеют шифрование с полным диском.

EDIT:

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

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