Encrypting file system(шифрующая файловая система)

От JFFS к F2FS

Одной из первых попыток написать файловую систему, которая бы учитывала принципы организации флеш-памяти, была JFFS — Journaling Flash File System. Изначально эта разработка шведской фирмы Axis Communications была ориентирована на повышение эффективности памяти сетевых устройств, которые Axis выпускала в девяностых. Первая версия JFFS поддерживала только NOR-память, но уже во второй версии подружилась с NAND.

Сейчас JFFS2 имеет ограниченное применение. В основном она все так же используется в дистрибутивах Linux для встраиваемых систем. Ее можно найти в маршрутизаторах, IP-камерах, NAS и прочих завсегдатаях интернета вещей. В общем, везде, где требуется небольшой объем надежной памяти.

Дальнейшей попыткой развития JFFS2 стала LogFS, у которой индексные дескрипторы хранились в отдельном файле. Авторы этой идеи — сотрудник немецкого подразделения IBM Йорн Энгель и преподаватель Оснабрюкского университета Роберт Мертенс. Исходный код LogFS выложен на GitHub. Судя по тому, что последнее изменение в нем было сделано четыре года назад, LogFS так и не обрела популярность.

Зато эти попытки подстегнули появление другой специализированной файловой системы — F2FS. Ее разработали в корпорации Samsung, на долю которой приходится немалая часть производимой в мире флеш-памяти. В Samsung делают чипы NAND Flash для собственных устройств и по заказу других компаний, а также разрабатывают SSD с принципиально новыми интерфейсами вместо унаследованных дисковых. Создание специализированной файловой системы с оптимизацией для флеш-памяти было с точки зрения Samsung давно назревшей необходимостью.

Четыре года назад, в 2012 году, в Samsung создали F2FS (Flash Friendly File System). Ее идея хороша, но реализация оказалась сыроватой. Ключевая задача при создании F2FS была проста: снизить число операций перезаписи ячеек и распределить нагрузку на них максимально равномерно. Для этого требуется выполнять операции с несколькими ячейками в пределах того же блока одновременно, а не насиловать их по одной. Значит, нужна не мгновенная перезапись имеющихся блоков по первому запросу ОС, а кеширование команд и данных, дозапись новых блоков на свободное место и отложенное стирание ячеек.

Сегодня поддержка F2FS уже официально реализована в Linux (а значит, и в Android), но особых преимуществ на практике она пока не дает. Основная особенность этой файловой системы (отложенная перезапись) привела к преждевременным выводам о ее эффективности. Старый трюк с кешированием даже одурачивал ранние версии бенчмарков, где F2FS демонстрировала мнимое преимущество не на несколько процентов (как ожидалось) и даже не в разы, а на порядки. Просто драйвер F2FS рапортовал о выполнении операции, которую контроллер только планировал сделать. Впрочем, если реальный прирост производительности у F2FS и невелик, то износ ячеек определенно будет меньше, чем при использовании той же ext4. Те оптимизации, которые не сможет сделать дешевый контроллер, будут выполнены на уровне самой файловой системы.

Прозрачное шифрование

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

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

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

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

Операция

Работа шифрованной файловой системы

EFS работает путем шифрования файла с симметричный ключ, также известный как ключ шифрования файла или FEK. Он использует симметричный алгоритм шифрования, потому что для шифрования и дешифрования больших объемов данных требуется меньше времени, чем если бы асимметричный ключ используется шифр. Используемый алгоритм симметричного шифрования зависит от версии и конфигурации операционной системы; увидеть ниже. FEK (симметричный ключ, который используется для шифрования файла) затем шифруется с помощью открытый ключ который связан с пользователем, который зашифровал файл, и этот зашифрованный FEK сохраняется в альтернативном потоке данных $ EFS зашифрованного файла. Чтобы расшифровать файл, драйвер компонента EFS использует закрытый ключ, соответствующий цифровому сертификату EFS (используемый для шифрования файла), чтобы расшифровать симметричный ключ, который хранится в потоке $ EFS. Затем драйвер компонента EFS использует симметричный ключ для расшифровки файла. Поскольку операции шифрования и дешифрования выполняются на уровне ниже NTFS, они прозрачны для пользователя и всех его приложений.

Папки, содержимое которых должно быть зашифровано файловой системой, помечаются атрибутом шифрования. Драйвер компонента EFS обрабатывает этот атрибут шифрования аналогично наследованию прав доступа к файлам в NTFS: если папка помечена для шифрования, то по умолчанию все файлы и подпапки, созданные в этой папке, также зашифрованы. Когда зашифрованные файлы перемещаются в том NTFS, файлы остаются зашифрованными. Однако есть ряд случаев, когда файл может быть расшифрован без явного запроса пользователя об этом Windows.

Файлы и папки расшифровываются перед копированием на том, отформатированный в другой файловой системе, например FAT32. Наконец, когда зашифрованные файлы копируются по сети с использованием протокола SMB / CIFS, файлы дешифруются перед отправкой по сети.

Начиная с Виндоус виста, закрытый ключ пользователя может храниться на интеллектуальная карточка; Ключи агента восстановления данных (DRA) также можно хранить на смарт-карте.

Механизм восстановления пароля / данных

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

Механизм восстановления пароля запрос – ответ

Механизм восстановления пароля запрос – ответ позволяет восстановить пароль безопасным способом. Он предлагается ограниченным количеством решений для шифрования дисков.

Некоторые преимущества восстановления пароля на запрос – ответ:

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

Механизм восстановления пароля к файлу с информацией об аварийном восстановлении (ERI)

Файл информации для аварийного восстановления (ERI) предоставляет альтернативу для восстановления, если механизм «запрос-ответ» невозможен из-за затрат на сотрудников службы поддержки для небольших компаний или проблем с внедрением.

Некоторые преимущества восстановления ERI-файлов:

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

Типы атрибутов

NTFS поддерживает большее количество предопределенных типов атрибутов. Тип атрибута определяет его назначение и формат представления тела. Полное описание всех атрибутов заняло бы целую книгу, поэтому кратко перечислю лишь наиболее «ходовые» из них. Так, атрибут стандартной информации
$STANDARD_INFORMATION описывает время создания, изменения и последнего доступа к файлу, права доступа, а также некоторую другую вспомогательную информацию (например, квоты).

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

При каких обстоятельствах атрибуты не умещаются в одной файловой записи? Это может произойти в следующих случаях:

• файл содержит много альтернативных имен или жестких ссылок;
• файл сильно фрагментирован;
• файл содержит очень сложный дескриптор безопасности;
• файл имеет очень много потоков данных (т. е. атрибутов типа
  $DATA).

Атрибут полного имени файла
$FILE_NAME хранит имя файла в соответствующем пространстве имен. Таких атрибутов у файла может быть и несколько. Здесь же хранятся и жесткие ссылки (hard link), если они есть.

Файловые записи

Структурно файловая запись состоит из заголовка (header) и одного или нескольких атрибутов (attributes) произвольной длины, завершаемых маркером конца (end marker) — четырехбайтным шестнадцатеричным значением
FFFFFFFFh. Несмотря на то что количество атрибутов и их длина меняются от одной файловой записи к другой, размер самой структуры
FILE Record строго фиксирован. В большинстве случаев он равен 1 Кбайт (это значение хранится в файле
$boot, причем первый байт файловой записи всегда совпадает с началом сектора).

Если реальная длина атрибутов меньше размеров файловой записи, то ее «хвост» просто не используется. Если же атрибуты не умещаются в отведенное им пространство, создается дополнительная файловая запись (extra FILE Record), ссылающаяся на свою предшественницу. Так выглядит структура файловой записи:

1 2 3 4 5 6 7

FILE Record Header;Заголовок Attribute1;Атрибут1 Attribute2;Атрибут2 …;… AttributeN;АтрибутN EndMarker(FFFFFFFFh);Маркерконца

Первые четыре байта заголовка заняты «магической последовательностью»
FILE, сигнализирующей о том, что мы имеем дело с файловой записью типа
FILE Record. При восстановлении сильно фрагментированного файла
$MFT это обстоятельство играет решающую роль, поскольку позволяет отличить сектора, принадлежащие MFT, от всех остальных секторов.

Следом за сигнатурой идет 16-разрядный указатель, содержащий смещение последовательности обновления (update sequence). Под «указателем» здесь и до конца раздела подразумевается смещение от начала сектора, отсчитываемое от нуля и выраженное в байтах. Последовательность обновления хранится по смещению
002Dh, и поэтому сигнатура приобретает следующий вид:
FILE-\x00.

Размер заголовка варьируется от одной версии операционной системы к другой и в явном виде нигде не хранится. Вместо этого в заголовке присутствует указатель на первый атрибут, содержащий его смещение в байтах относительно начала файловой записи и расположенный по смещению
14h байт от начала сектора.

Смещения последующих атрибутов (если они есть) определяются путем сложения размеров всех предыдущих атрибутов (размер каждого из атрибутов содержится в его заголовке) со смещением первого атрибута. За концом последнего атрибута находится маркер конца — значение
FFFFFFFFh.

Длина файловой записи хранится в двух полях. Тридцатидвухразрядное поле реального размера (real size), находящееся по смещению
18h байт от начала сектора, содержит совокупный размер заголовка, всех его атрибутов и маркера конца, округленный по 8-байтной границе. Тридцатидвухразрядное поле выделенного размера (allocated size), находящееся по смещению
1Сh байт от начала сектора, содержит действительный размер файловой записи в байтах, округленный по размеру сектора. Документация утверждает, что выделенный размер должен быть кратен размеру кластера, но на практике это не так. Например, на моей машине длина поля выделенного размера равна четверти кластера.

16-разрядное поле флагов, находящееся по смещению
16h байт от начала сектора, в подавляющем большинстве случаев принимает одно из следующих трех значений:
00h — данная файловая запись не используется или ассоциированный с ней файл или каталог удален,
01h — файловая запись используется и описывает файл,
02h — файловая запись используется и описывает каталог.

64-разрядное поле, находящееся по смещению
20h байт от начала сектора, содержит индекс базовой файловой записи. Для первой файловой записи это поле всегда равно нулю, а для всех последующих, расширенных записей — индексу первой файловой записи. Расширенные файловые записи могут находиться в любых областях MFT, не обязательно расположенных рядом с основной записью. Следовательно, необходим какой-то механизм, обеспечивающий быстрый поиск расширенных файловых записей, принадлежащих данному файлу (просматривать всю MFT было бы слишком нерационально). Этот механизм существует, и основан он на ведении списков атрибутов (
$ATTRIBUTE_LIST). Список атрибутов представляет собой специальный атрибут, добавляемый к первой файловой записи и содержащий индексы расширенных записей.

Новые функции, доступные в версии Windows

Windows XP

• Шифрование клиентского кэша (Автономные файлы база данных)
• Защита DPAPI Резервное копирование мастер-ключа с использованием общедоменного открытого ключа
• Автоматическая подача сертификатов пользователей (включая сертификаты EFS)
• Многопользовательский (общий) доступ к зашифрованным файлам (для каждого файла) и проверка отзыва сертификатов, используемых при совместном использовании зашифрованных файлов
• Зашифрованные файлы могут отображаться другим цветом (по умолчанию — зеленым)
• Нет требований к обязательному Агент восстановления
• Предупреждение о том, что файлы могут автоматически дешифрироваться при переходе в неподдерживаемую файловую систему
• Диск сброса пароля
• EFS через WebDAV и удаленное шифрование для серверов, делегированных в Active Directory

Windows XP SP1

Поддержка и использование по умолчанию симметричного алгоритма шифрования AES-256 для всех файлов, зашифрованных EFS.

Windows XP SP2 + КБ

Запретить регистрацию самозаверяющих сертификатов EFS

Windows Server 2003

• Служба управления цифровой идентификацией
• Применение параметра RSAKeyLength для обеспечения минимальной длины ключа при регистрации самозаверяющих сертификатов EFS

Виндоус виста и Windows Server 2008

• Индивидуальное шифрование клиентского кэша (автономные файлы)
• Поддержка хранения закрытых ключей RSA (пользовательских или DRA) на смарт-карте ПК / SC
• Мастер смены ключей EFS
• Запросы резервного копирования ключа EFS
• Поддержка получения DPAPI Мастер-ключ со смарт-карты ПК / SC
• Поддержка шифрования pagefile.sys
• Защита секретов EFS с помощью BitLocker (Корпоративная или Максимальная версия Windows Vista)
• Элементы управления групповой политикой для обеспечения соблюдения
  • Шифрование папки документов
  • Шифрование автономных файлов
  • Индексирование зашифрованных файлов
  • Требуется смарт-карта для EFS
  • Создание пользовательского ключа с возможностью кэширования со смарт-карты
  • Отображение уведомления о резервном копировании ключа при создании или изменении пользовательского ключа
  • Указание шаблона сертификата, используемого для автоматической регистрации сертификатов EFS

Windows Server 2008

• Самозаверяющие сертификаты EFS, зарегистрированные на сервере Windows Server 2008, по умолчанию будут иметь длину ключа RSA 2048 бит.
• Все шаблоны EFS (сертификаты пользователя и агента восстановления данных) по умолчанию имеют длину ключа RSA 2048 бит.

Windows 7 и Windows Server 2008 R2

• Криптографические алгоритмы с эллиптической кривой (ECC). Windows 7 поддерживает смешанный режим работы алгоритмов ECC и RSA для обратной совместимости.
• Самозаверяющие сертификаты EFS при использовании ECC по умолчанию будут использовать 256-битный ключ.
• EFS можно настроить на использование ключей 1K / 2k / 4k / 8k / 16k бит при использовании самоподписанных сертификатов RSA или 256/384/521-битных ключей при использовании сертификатов ECC.

Windows 10 версии 1607 и Windows Server 2016

Добавьте поддержку EFS на FAT и exFAT.

NTFS

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

Эта файловая система позволяет создавать информационные файлы с именами длинной в 255 символов.

Если операционка, которая работает с данной файловой системой, дает сбой, то не нужно переживать за сохранность всех файлов. Они остаются в целостности и невредимости, поскольку этот тип файловой системы имеет свойство самовосстанавливаться.

Особенностью ФС NTFS является ее структура, которая представлена в виде определенной таблицы. Первые шестнадцать записей в реестре — это содержание самой файловой системы. Каждая отдельная электронная единица тоже имеет вид таблицы, которая содержит информацию о таблице, зеркальный файл в формате MFT, файл регистрации, используемый при необходимости восстановления информации и последующие данные – это информация о самом файле и его данные, которые были сохранены непосредственно на жестком диске.

Все выполняемые команды с файлами имеют свойство сохраняться, что помогает впоследствии восстанавливаться системе самостоятельно после сбоя операционной системы, с которой она работает.

Полное шифрование диска

Преимущества

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

Почти все, включая пространство подкачки и временные файлы, зашифровано

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

Например, BitLocker Drive Encryption оставляет незашифрованный том до загрузки, в то время как том, содержащий операционную систему, полностью зашифрован.
С полное шифрование диска, решение о том, какие отдельные файлы шифровать, не остается на усмотрение пользователей. Это важно для ситуаций, в которых пользователи могут не захотеть или могут забыть зашифровать конфиденциальные файлы.
Немедленное уничтожение данных, например, простое уничтожение криптографических ключей (крипто-шреддинг ), делает содержащие данные бесполезны. Однако, если безопасность для будущих атак вызывает беспокойство, рекомендуется очистка или физическое уничтожение.

Проблема загрузочного ключа

Одна проблема, которую необходимо решить при полном шифровании диска, заключается в том, что блоки, где Операционная система должна быть расшифрована перед загрузкой ОС, а это означает, что ключ должен быть доступен до того, как появится пользовательский интерфейс для запроса пароля. Большинство решений для полного шифрования диска используют предзагрузочную аутентификацию, загружая небольшую, высокозащищенную операционную систему, которая строго заблокирована и хешируется по сравнению с системными переменными для проверки целостности предзагрузочного ядра. Некоторые реализации, такие как BitLocker Drive Encryption, могут использовать оборудование, такое как Trusted Platform Module, для обеспечения целостности среды загрузки и, таким образом, предотвращения атак, , заменив его модифицированной версией. Это гарантирует, что аутентификация может происходить в контролируемой среде без возможности использования буткита для подрыва предзагрузочной расшифровки.

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

Решения для хранения внешнего ключа включают:

• Имя пользователя / пароль
• Использование смарт-карты в сочетании с PIN-кодом
• Использование метод биометрической аутентификации, такой как отпечаток пальца
• Использование электронного ключа для хранения ключа, при условии, что пользователь не позволит украсть ключ вместе с портативным компьютером или что ключ также зашифрован
• Использование драйвера времени загрузки, который может запрашивать пароль у пользователя
• Использование сетевого обмена для восстановления ключа, например, как часть PXE boot
• Использование TPM для хранения ключа дешифрования, предотвращение несанкционированного доступа к ключу дешифрования или подрыв загрузчика
• Использование комбинации вышеперечисленного

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

Основные функции файловых систем

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

Основными функциями файловой системы являются:

• размещение и упорядочивание на носителе данных в виде файлов;
• определение максимально поддерживаемого объема данных на носителе информации;
• создание, чтение и удаление файлов;
• назначение и изменение атрибутов файлов (размер, время создания и изменения, владелец и создатель файла, доступен только для чтения, скрытый файл, временный файл, архивный, исполняемый, максимальная длина имени файла и т.п.);
• определение структуры файла;
• поиск файлов;
• организация каталогов для логической организации файлов;
• защита файлов при системном сбое;
• защита файлов от несанкционированного доступа и изменения их содержимого. 

Btrfs

Еще один яркий представитель файловых систем на основе B-деревьев называется Btrfs. Эта ФС появилась в 2007 году и изначально создавалась в Oracle с прицелом на работу с SSD и RAID. Например, ее можно динамически масштабировать: создавать новые индексные дескрипторы прямо в работающей системе или разделять том на подтома без выделения им свободного места.

Реализованный в Btrfs механизм копирования при записи и полная интеграция с модулем ядра Device mapper позволяют делать практически мгновенные снапшоты через виртуальные блочные устройства. Предварительное сжатие данных (zlib или lzo) и дедупликация ускоряют основные операции, заодно продлевая время жизни флеш-памяти. Особенно это заметно при работе с базами данных (достигается сжатие в 2–4 раза) и мелкими файлами (они записываются упорядоченно крупными блоками и могут храниться непосредственно в «листьях»).

Также Btrfs поддерживает режим полного журналирования (данных и метаданных), проверку тома без размонтирования и множество других современных фич. Код Btrfs опубликован под лицензией GPL. Эта файловая система поддерживается в Linux как стабильная начиная с версии ядра 4.3.1.

Что такое файловая система

Обычно вся информация записывается, хранится и обрабатывается на различных цифровых носителях в виде файлов. Далее, в зависимости от типа файла, кодируется в виде знакомых расширений – *exe, *doc, *pdf и т.д., происходит их открытие и обработка в соответствующем программном обеспечении. Мало кто задумывается, каким образом происходит хранение и обработка цифрового массива в целом на соответствующем носителе. 

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

Запись файлов большого объема приводит к необходимости фрагментации, когда файлы не сохраняются как целые единицы, а делятся на фрагменты. Каждый фрагмент записывается в отдельные кластеры, состоящие из ячеек (размер ячейки составляет один байт). Информация о всех фрагментах, как части одного файла, хранится в файловой системе.

Файловая система связывает носитель информации (хранилище) с прикладным программным обеспечением, организуя доступ к конкретным файлам при помощи функционала взаимодействия программ API. Программа, при обращении к файлу, располагает данными только о его имени, размере и атрибутах. Всю остальную информацию, касающуюся типа носителя, на котором записан файл, и структуры хранения данных, она получает от драйвера файловой системы.

На физическом уровне драйверы ФС оптимизируют запись и считывание отдельных частей файлов для ускоренной обработки запросов, фрагментации и «склеивания» хранящейся в ячейках информации. Данный алгоритм получил распространение в большинстве популярных файловых систем на концептуальном уровне в виде иерархической структуры представления метаданных (B-trees). Технология снижает количество самых длительных дисковых операций – позиционирования головок при чтении произвольных блоков. Это позволяет не только ускорить обработку запросов, но и продлить срок службы HDD. В случае с твердотельными накопителями, где принцип записи, хранения и считывания информации отличается от применяемого в жестких дисках, ситуация с выбором оптимальной файловой системы имеет свои нюансы.

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Подписаться