Сегодня мы поговорим о малоизвестных особенностях iOS, связанных с защитой резервных копий, обходом этой защиты и защитой от неё. Система резервного копирования iOS – воистину вне конкуренции. Ничего подобного в плане подробности, универсальности и безопасности локальных резервных копий у конкурентов в стане Android нет. В Android резервные копии создаются исключительно в облаке; локальные же резервные копии в этой системе оставляют желать много лучшего. В рамках этой статьи мы поговорим о локальных резервных копиях и их защите.

Для пользователя резервная копия – удобный и простой способ перенести данные на новое устройство или восстановить уже имеющееся после сброса к заводским настройкам. Для экспертов-криминалистов резервные копии iOS — не менее удобный, универсальный и простой способ извлечь из хорошо защищённого хранилища устройства копию данных. В резервные копии попадает множество важной информации: и данные большинства приложений, и логины с паролями, которые пользователь сохранил в браузере Safari и сторонних приложениях, и пароли к Wi-Fi, и резервные копии часов Apple Watch, и данные об активности пользователя (шаги, сердцебиение в заданный момент времени). Попадают в резервные копии и многие другие вещи, жизненно необходимые для расследования преступлений. В руках злоумышленника резервная копия превращается в опасное оружие. Логины и пароли из Связки ключей позволяют получить доступ к учётным записям, переписке и финансам пользователя. Чтобы этого не произошло, Apple позволяет пользователю установить пароль на резервные копии.

Пароли к резервным копиям iOS

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

Шифрование локальных резервных копий в iOS настолько стойкое, что даже с использованием аппаратного ускорения нам не удалось получить скорость перебора больше нескольких десятков паролей в секунду. Соответственно, лобовая атака бесполезна даже если используется несложный пароль из 7 знаков. Впрочем, даже при наличии стойкого пароля на шифрование из телефона можно извлечь фотографии и медиа-файлы, если его экран можно разблокировать.

До выхода iOS 11 длинный и сложный пароль на резервную копию был абсолютной защитой; никакой возможности удалить или поменять пароль, не введя предварительно старый, в старых версиях системы не существовало. В iOS 11 ситуация изменилась.

Первая рекурсия: сброс пароля на резервную копию

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

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

1. На устройстве iOS выберите «Настройки» > «Основные» > «Сброс».
2. Нажмите «Сбросить все настройки» и введите пароль ОС iOS.
3. Следуйте инструкциям по сбросу настроек. Это не затронет данные или пароли пользователей, но приведёт к сбросу таких настроек, как уровень яркости дисплея, позиции программ на экране «Домой» и обои. Пароль для шифрования резервных копий также будет удалён. (В скобках: на этом этапе устройство потребует ввести код блокировки экрана).
4. Снова подключите устройство к iTunes и создайте новую зашифрованную резервную копию.

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

На устройстве с iOS 10 или более ранней версии сброс пароля невозможен. 

Вторая рекурсия: защита от попыток сброса пароля на резервную копию

Лёгкость, с которой злоумышленник может обойти самый сложный и длинный пароль на резервную копию, всего лишь введя код блокировки экрана, неприятно поражает. Однако от этой угрозы можно уберечься. Механизмом защиты здесь станут Ограничения родительского контроля (iOS 11) или пароль Экранного времени (iOS 12 и более поздние).

Допустим, ваш iPhone попал в руки злоумышленника. Предположим, злоумышленнику удалось подсмотреть ваш код блокировки; теперь он пытается отвязать телефон от облака, а заодно извлечь  копию данных, получив доступ к паролям из Связки ключей. Защититься от такого развития событий можно при помощи пароля Экранного времени. Подробно о возможностях контроля Экранного времени можно почитать в статье Apple Использование родительского контроля на устройствах iPhone, iPad и iPod touch ребенка. Нас же сейчас интересует другая возможность этой системы: защитить телефон от сброса пароля на резервную копию.

Как ни странно, ограничить возможность сброса пароля к локальной резервной копии iOS достаточно просто: всё, что нужно сделать, это установить пароль Экранного времени как таковой. Сложность такого пароля невелика: единственный доступный вариант – это PIN-код из 4 цифр. Тем не менее, такая защита в целом достаточно надёжна. Поскольку этот пароль используется очень редко и отличается от кода блокировки устройства, его невозможно случайно подсмотреть. Этот код понадобится в исключительно редких случаях, когда вы захотите изменить настройки или отключить ограничения. Вы можете установить случайный код, записав его на оставленной дома бумажке – и это будет вполне безопасно.

Что произойдёт, если теперь попытаться сбросить пароль на резервную копию? На первом шаге – никаких отличий: система запросит пароль блокировки устройства. А вот сразу после этого будет запрошен дополнительный 4-значный пароль Экранного времени. Эта мера безопасности вполне способна не только отвадить любопытных, но и защитить iPhone от целенаправленных попыток взлома.

Рекурсия третья: как узнать пароль Экранного времени

Пароль Экранного времени сохраняется на самом устройстве. Подобрать его за разумное время невозможно: невеликое пространство из 10,000 комбинаций защищается системой прогрессирующими задержками между попытками ввода. После нескольких неудачных попыток система ограничит скорость перебора паролей Экранного времени, вводя прогрессивные задержки в 1, 5, 15 и 60 минут. После 10 неудачных попыток каждая следующая попытка может быть предпринята не ранее, чем через час после предыдущей; перезагрузка устройства не поможет ускорить процесс. Таким образом, все 10,000 комбинаций можно перебрать за 416 дней.

Однако есть и более интересные способы. Сразу оговорюсь: первый из них работает только тогда, когда пароль на резервную копию не установлен или известен, а второй – если на iPhone можно установить джейлбрейк (включая аппаратный — checkra1n).

Способ 1: извлечь из резервной копии

В iOS 7-11 этот пароль (там он носит название Restrictions) хранится в виде хэша. Алгоритм относительно стойкий (pbkdf2-hmac-sha1, но количество итераций относительно невелико). С учётом того, что пароль этот состоит всегда и только из 4 цифр, полный перебор хэша на компьютере занимает несколько секунд. Сам хэш хранится в файле com.apple.restrictionspassword.plist, который попадает в бэкап. Соответственно, пароль Restrictions можно вскрыть, если у нас есть (одно из):

• резервная копия iOS без пароля
• резервная копия iOS с паролем, плюс пароль от него

В iOS 12 (здесь это пароль Экранного времени, или Screen Time) хранится в открытом виде. Нет, безопасность от этого хуже не стала: пароль переместили в Связку ключей. Тем не менее, класс защиты паролю Экранного времени назначили минимальный: он не привязан к устройству. Минимальный класс защиты назначен умышленно. Сделано это для того, чтобы при восстановлении нового iPhone из бэкапа пароль Экранного времени устанавливался автоматически (таким образом Apple закрыли потенциальную возможность снять пароль Экранного времени путём создания резервной копии, сброса устройства и последующего восстановления из резервной копии). Записи Связки ключей с более высокими классами защиты не попадают в резервные копии или попадают, но защищаются аппаратным ключом устройства (то есть, могут быть восстановлены только на то же самое устройство).

Чтобы достать пароль Экранного времени, нужно:

• резервная копия iOS с паролем плюс пароль от него

Способ 2: через джейлбрейк

Очевидно, что первый способ сработает лишь тогда, когда пароль на резервную копию не установлен или известен. Если же пароль на резервную копию установлен, но неизвестен, то единственный оставшийся способ узнать пароль Экранного времени – получить доступ к Связке ключей (keychain). Для старых версий iOS нужна копия файловой системы.

Для iOS 7-11 нужно:

• образ файловой системы

Для iOS 12:

• Связка ключей

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

One more thing

Что интересно, пароль Экранного времени хранится также и в облаке iCloud, но только в том случае, если вы включили двухфакторную аутентификацию и активировали опцию Screen Time “Share across devices”. Сам ключ при этом не попадает в Облачную связку ключей, а хранится отдельно (примерно в том же виде, что и ключ восстановления доступа к зашифрованным томам FileVault 2). Извлечь его из iCloud (и просмотреть) можно посредством Elcomsoft Phone Breaker. Для этого вам понадобится всё перечисленное ниже:

• логин и пароль от Apple ID (iCloud) пользователя
• код блокировки экрана устройства
• доступ ко второму фактору аутентификации (им является само устройство, если известен код блокировки; впрочем, достаточно и SIM-карты с доверенным телефонным номером)

А вот сценарий со сбросом устройства и последующим восстановлением его из «облачной» резервной копии мы не проверяли, поэтому я не могу точно сказать, активируется ли пароль Экранного времени, если создать резервную копию в iCloud, сбросить iPhone и восстановиться из облака.

Рекурсия четвёртая, последняя: как защитить доступ к паролю Экранного времени

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

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

Опасаться можно сценария, когда украденное устройство (с известным злоумышленнику кодом блокировки) будет положено на полку в ожидании появления джейлбрейка, либо если для вашего телефона (iPhone 8, 8 Plus, iPhone X или более старое поколение) есть аппаратный джейлбрейк checkra1n. Здесь, однако, может помочь стандартная «Стереть [устройство]», выполненное в портале Find my iPhone. Дело в том, что для установки джейлбрейка требуется сначала подписать IPA-файл, а потом и подтвердить цифровую подпись непосредственно на самом iPhone. Подтверждение цифровой подписи происходит на сервере Apple; то есть, злоумышленнику придётся разрешить украденному у вас iPhone выйти в интернет. В этот момент с большой вероятностью сработает команда на стирание устройства.

Злоумышленники могут решить эту проблему, используя специальные конфигурации роутера, в которых будет запрещён доступ к узлам, ответственным за функционал Find My iPhone. Кроме того, вместо обычного сертификата для подписи джейлбрейка могут использовать сертификат разработчика, который не требует выхода iPhone в сеть для подтверждения цифровой подписи.

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

Шифрованием данных пользуются все, кто взаимодействует с современной электроникой. Будь то BitLocker, FileVault, LUKS, VeraCrypt или встроенная в смартфоны Android и Apple система шифрования, пользователь привык к определённому набору функций. Пароль от зашифрованного раздела всегда можно сменить, и это происходит практически мгновенно, а для очистки зашифрованного накопителя достаточно уничтожить ключи шифрования, после чего данные невозможно расшифровать даже с правильным паролем. Наконец, мы привыкли к тому, что системы защиты подробно документированы, а их стойкость постоянно пробуют на зуб независимые исследователи.

А что, если речь идёт не о персональном компьютере, не о смартфоне или планшете, а о специализированном устройстве, основная и единственная цель которого – надёжное и безопасное хранение больших объёмов данных? Наверное, в таких устройствах шифрование данных реализовано на высшем уровне? Производители сетевых хранилищ не стесняются открытым текстом писать о защищённости, шифровании «как у военных» и прочих приятных уху и глазу вещах. Но если копнуть чуть глубже, выясняются удивительные вещи.

Шифрование в сетевых накопителях (NAS)

Рынок сетевых хранилищ для домашних и офисных пользователей выглядит достаточно интересно. Самыми массовыми являются модели от Western Digital, одного из крупнейших производителей жёстких дисков. NAS от WD подкупают низкой ценой, часто – отрицательной: диск в накопителе обходится дешевле такого же диска отдельно. При этом шифрования данных в массовых моделях WD просто нет.

Особое место занимает компания Synology, домашние сетевые накопители которой отличаются красивым, хорошо оптимизированным софтом, качественной, хоть и не самой производительной, аппаратной платформой и длительным периодом поддержки – за соответствующие деньги. Популярностью пользуются и устройства основного конкурента – компания QNAP. В роли догоняющих выступают такие производители, как ASUS (Asustor), TerraMaster и Netgear. Не выдержав конкуренции, сошли с дистанции Thecus и малоизвестные у нас Drobo и Buffalo, которая может похвастаться вынесенной в начало статьи рекламной картинкой.

В отличие от Western Digital, большинство моделей этих производителей поддерживает шифрование, позволяющее защитить пользовательские данные. Производители поделились на два лагеря: представители одного из них (QNAP, Thecus) используют шифрование дисков на уровне тома, в то время как второй лагерь (Synology, Asustor, TerraMaster) используют шифрование отдельных сетевых папок на уровне файловой системы. У каждого способа есть свои преимущества и недостатки. В рамках данной статьи нас интересуют представители второго лагеря, использующие для шифрования криптографическую файловую систему eCryptFS.

Неоднозначное шифрование

Возможно ли представить ситуацию, в которой на обычном домашнем компьютере окажется невозможно сменить пароль к зашифрованным данным (если, конечно же, использовался именно пароль, а не аппаратный модуль с ключом)? Возможно ли шифрование, которое не позволяет моментально уничтожить информацию, потому что ключи не хранятся в одном месте, а равномерно распределены по всему диску? Или ситуацию, в которой неавторизованному пользователю доступна полная структура файловой системы, количество и размер зашифрованных файлов? Современные схемы шифрования дисков в Windows, macOS и Linux не допускают подобных сценариев.

Однако многие производители специализированных сетевых хранилищ, даже те из них, которые предлагают «безопасное шифрование AES-256» не используют шифрование тома. Вместо этого шифрованию подвергаются отдельные папки, а в них – отдельные файлы с использованием шифрующей файловой системы eCryptFS. Насколько стойким является шифрование eCryptFS в сравнении с шифрованием всего диска, какие у него есть особенности, преимущества и недостатки? Попробуем разобраться.

Шифрование средствами файловой системы: безопасность

Encrypting File System — общее название для класса криптографических файловых систем, которые шифруют данные на уровне отдельных папок и файлов. Криптографические файловые системы предоставляют возможность «прозрачного шифрования» данных. Цель криптографических файловых систем – защита данных от несанкционированного доступа при физическом доступе как к накопителям, извлечённым из компьютера, так и к самому компьютеру (в том числе и от других авторизованных пользователей компьютера, авторизованных в собственных учётных записях).

От каких именно угроз способно, а от каких – не способно защитить шифрование средствами файловой системы?

Стойкость защиты: невысокая. Да, производитель может использовать шифрование AES с 256-битным ключом, но энтропия пароля среднего пользователя (что это такое и как подсчитать) намного ниже 256 бит. При этом отозвать скомпрометированный пароль или изменить его нельзя: потребуется длительная процедура перешифровки метаданных всех файлов или даже самих файлов. В сетевых хранилищах от Synology раз установленный пароль шифрования сменить нельзя: можно лишь сначала расшифровать, а потом заново зашифровать папку. Скорость перебора паролей к eCryptFS относительно VeraCrypt или даже BitLocker высокая (65,537 итераций SHA-512 по умолчанию против 500,000 у VeraCrypt), что также не добавляет ей стойкости.

Если диск извлекут из NAS: стойкость защиты в лучшем случае соответствует стойкости пароля шифрования; в худшем (ключи шифрования хранятся на самом диске) – нулевая. При этом даже в лучшем случае (зашифрованная папка не смонтирована, пароль – неизвестен) неавторизованный пользователь:

• Получит доступ к дереву файловой системы (структуре папок)
• Узнает точное число файлов и объём зашифрованных данных
• Узнает точный размер каждого зашифрованного файла, что позволит произвести профилирование по размеру (поиск совпадений по размерам файлам)
• Сможет произвольно удалить один или несколько файлов и папок
• Сможет скопировать метаданные и произвести атаку на пароль

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

Защита от физического доступа к NAS: низкая. Криптографическая файловая система не защитит файл /etc/shadow от редактирования. Да, для этого может потребоваться извлечь диск из устройства – но при использовании шифрования сетевых папок в качестве единственного эшелона обороны системные файлы никак не защищены.

Удалённые атаки, зловредное ПО, вирусы-шифровальщики: если зашифрованная папка смонтирована, то влияние шифрования папок на реальную безопасность данных нулевое. Если же папка не смонтирована, то степень защиты зависит от того, хранятся ли ключи в самом NAS или же пользователь вводит пароль каждый раз при доступе к зашифрованной папке. К слову, от вирусов-шифровальщиков помогает защититься использование файловой системы BTRFS с регулярным созданием «теневых копий».

Сильные стороны eCryptFS

Во всех исследованных NAS, использующих шифрование сетевых папок, защита реализована средствами стандартной для Linux файловой системы eCryptFS, о которой можно почитать здесь или здесь. Почему такие производители, как Synology и Asustor (а в моделях с процессорами Intel — в качестве доступной опции и QNAP), выбрали шифрование на уровне сетевых папок, а не более распространённый вариант шифрования на уровне тома с использованием LUKS? Дело в том, что при всех своих недостатках eCryptFS обладает и целым рядом достоинств.

1. Уже готовое, проверенное решение: не нужно разрабатывать самостоятельно (обычно качественно реализовать вещи, которые относятся к безопасности, у производителей NAS не получается, поэтому использование готовых компонентов – меньшее зло).
2. Стандартная реализация шифрования позволяет просто скопировать зашифрованную папку целиком на другой накопитель или удалённое сетевое хранилище без расшифровки файлов в процессе копирования. При этом смонтировать и расшифровать такую папку получится стандартными средствами на любом компьютере с Linux. Приятный бонус: зашифрованные файлы можно скопировать и на диск, отформатированный в NTFS или FAT32/exFAT.
3. Бесплатно: не нужно платить за лицензии, снижается себестоимость устройства.
4. Безопасное резервное копирование: для создания и поддержания резервных копий (в том числе – инкрементных) нет необходимости расшифровывать данные и монтировать зашифрованные сетевые папки. Администратору не нужно знать пароли от каждой из зашифрованных папок – данные всё равно будут корректно скопированы или восстановлены. Изменения в незашифрованных файлах отражаются и в зашифрованных. Важный с точки зрения безопасности момент: нет необходимости хранить пароли или ключи шифрования в самом NAS, что делает процесс резервного копирования не только удобным, но и безопасным.
5. Поскольку шифруются отдельные сетевые папки, не имеет значения, на каком из физических или логических накопителей они расположены. Главное, чтобы была поддержка на уровне файловой системы. Впрочем, шифрование сетевых папок на внешних накопителях, которые можно подключить к NAS через USB, не поддерживает ни один производитель NAS независимо от того, какая на внешнем устройстве файловая система. (В накопителях Asustor можно назначить один или несколько встроенных дисков в качестве архивных; для таких дисков шифрование доступно, но на уровне тома, а не средствами eCryptFS).
6. Каждый пользователь может зашифровать свою папку своим собственным паролем. Таким образом, обеспечивается защита данных каждого авторизованного пользователя NAS от других авторизованных пользователей.
7. Шифруются как сами данные, так и имена папок и файлов. Но не структура каталогов, количество и размер файлов.

Слабые стороны eCryptFS

Есть у eCryptFS и ряд недостатков, способных серьёзно повлиять на опыт использования NAS или даже сделать шифрование невозможным.

1. Шифрование папок не является «сквозным шифрованием». Анализ зашифрованной папки позволит узнать следующую информацию:
   1. Структуру папок
   2. Количество и размер зашифрованных файлов
   3. Объём зашифрованных данных
2. Ограничения на длину имени файла. В зашифрованной eCryptFS папке длина имени файла (или папки) не может превышать 143 символа ANSI или 47 символов иероглифической записи (почему так). Это ограничение идёт с давних времён, и связано оно в первую очередь с тем, что криптографические файловые системы – своеобразные «костыли», работающие поверх обычных файловых систем. К примеру, зашифрованное имя файла ~/.bashrc может выглядеть следующим образом:

   dWek2i3.WxXtwxzQdkM23hiYK757lNI7Ydf0xqZ1LpDovrdnruDb1-5l67.EU--

3. (Synology DSMx) Для зашифрованных папок не поддерживается NFS.
4. Ключ шифрования – хэш от пароля. Почему это плохо? Если данные зашифрованы непосредственно паролем или его хэшем, смена пароля приводит к необходимости перешифровки всех файлов. Именно по этой причине в сменить пароль нельзя; можно лишь расшифровать и заново зашифровать папку – развлечение на несколько дней, если речь идёт о большом объёме данных). Как делать правильно? Разделять ключи шифрования данных и ключи шифрования ключей шифрования. Собственно пароль в правильной схеме шифрования должен использоваться исключительно для шифрования ключей, которыми, в свою очередь, будут зашифрованы сами данные (так, к примеру, сделано в реализации EFS в Windows).
5. Потенциально низкая энтропия пароля. Простая логика: если ключ шифрования не сохранять на устройстве (что является эквивалентом отсутствия шифрования), то пароль придётся вводить каждый раз для доступа к зашифрованным данным. В такой ситуации большинство пользователей использует пароль с чрезвычайно низкой энтропией, восстановить который в случае атаки будет довольно просто. И мало того, что пароль может быть с невысокой энтропией, так его ещё и сменить не получится.
6. Метаданные шифрования хранятся в каждом файле. Это приводит к тому, что быстро и надёжно удалить зашифрованную информацию невозможно. Удаление зашифрованной папки не приводит к безвозвратному уничтожению зашифрованных данных (а вот быстрое форматирование тома BitLocker или FileVault 2 – приводит).

Чем может грозить утечка таких данных, как объём зашифрованной информации, количество файлов и размер каждого файла? Как минимум – отказом «правдоподобного отрицания». Соответственно, к зашифрованным папкам применимы такие атаки, как профилирование по размеру файлов, что позволяет узнать содержимое зашифрованной папки, если размер заданного количества файлов совпадает с размером файлов, известных атакующему.

Рекомендации: как обезопасить зашифрованные данные

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

1. Запомните: единожды установленный пароль шифрования сменить не получится без полной расшифровки папки с последующим шифрованием файлов новым паролем. Внимательно отнеситесь к выбору пароля. Установите длинный пароль с высокой энтропией, желательно – набор случайных символов. Имейте в виду, что скорость атаки на eCryptFS высокая, и пароль с низкой энтропией может быть восстановлен очень быстро.
2. Ни в коем случае не сохраняйте ключ шифрования в самом устройстве. Если необходимо автоматически монтировать зашифрованные папки, сохраните ключ на внешнем USB накопителе.
3. Если ключ шифрования сохраняется на USB накопителе (например, в случае офисного NAS), обеспечьте физическую безопасность этого накопителя.
4. Проконтролируйте процесс создания и сохранения резервного ключа (в Synology это файл с расширением .key, который будет сохранён на компьютере автоматически после создания зашифрованной папки). Этот ключ имеет смысл сохранить в зашифрованном виде (в архиве с паролем или на зашифрованном диске).
5. Продумайте стратегию автоматического монтирования зашифрованных папок. Автоматическое монтирование зашифрованных данных при загрузке – эквивалент отсутствия безопасности.

Заключение

Выбор средств защиты – всегда компромисс между удобством и безопасностью. И если Microsoft и Apple удалось разработать безопасные и удобные решения, то у производителей сетевых хранилищ получился выбор между неудобной защитой с неровным уровнем безопасности и удобной – с нулевым уровнем защиты. В то же время даже такое шифрование позволит защитить данные от некоторых видов угроз. Главное – правильно настроить шифрование и чётко понимать, против каких угроз такая защита эффективна, а против каких – бесполезна.

BitLocker — одно из самых распространённых решений шифрования дисков в Windows. BitLocker используется как в организациях, так и для защиты портативных устройств — ноутбуков и устройств-трансформеров под управлением Windows. В то же время BitLocker может заблокировать доступ к зашифрованным данным, если пароль для входа в Windows утерян. Мы предлагаем решение на основе загрузочного USB-накопителя, позволяющее восстановить доступ к учётным записям Windows для систем, защищённых BitLocker. В этой статье нет ни слова о том, как взломать шифрование томов BitLocker. Мы рассказываем о том, как получить доступ к учётным записям пользователей Windows, если загрузочный диск зашифрован, но в вашем распоряжении есть депонированный ключ или один из доступных протекторов — факторов, позволяющих разблокировать том.

Методы защиты BitLocker

В предыдущей статье Механизмы защиты BitLocker: какие диски можно, а какие нельзя взломать мы подробно описали, какие типы протекторов (факторов, позволяющих разблокировать том BitLocker) существуют и какие из них можно взломать. Существуют такие типы протекторов, как TPM, TPM+PIN, TPM+USB, TPM+USB+PIN, USB и «только пароль». Методом перебора можно вскрыть лишь последний из них — «только пароль». Системные (загрузочные) диски таким способом защищают редко, а вот дополнительные разделы и внешние накопители защитить другим способом затруднительно. В результате подавляющее большинство как внешних, так и встроенных дисков в системе, за исключением загрузочного, обычно защищено именно паролем и только им.

А что насчёт остальных типов протекторов? Если отвлечься от мощной, но чрезвычайно технически сложной атаки методом холодной загрузки, то остаётся лишь вариант с использованием депонированного ключа — последовательности из 48 цифр, которая сохраняется по умолчанию либо в учётной записи пользователя Microsoft Account, либо, если речь идёт о корпоративном компьютере, в Active Directory.

И если при помощи пароля можно смонтировать или расшифровать соответствующий том даже если пароль к учётной записи пользователя утрачен (к примеру, сотрудник покинул компанию), то что-либо сделать в такой ситуации с загрузочным диском, для которого есть депонированный ключ, достаточно сложно. Microsoft не предлагает внятного способа для восстановления доступа к учётной записи пользователей Windows, если загрузочный томе зашифрован с помощью BitLocker. Восстановить или сбросить пароль к учётной записи пользователя не получится, даже если в вашем распоряжении есть депонированный ключ. По сути, единственный штатный способ восстановить доступ к системе — загрузиться с диска восстановления Windows и смонтировать зашифрованный том, введя ключ восстановления. Однако потом вам придётся либо переустановить Windows, либо скопировать данные с зашифрованного тома. Просто сбросить пароль от учётной записи вы не сможете.

Мы предлагаем более простой способ. Начиная с версии 7.05, Elcomsoft System Recovery может разблокировать тома, зашифрованные BitLocker, путём загрузки с USB накопителя. Разумеется, просто вскрыть защиту нельзя: вам в любом случае понадобится депонированный ключ или пароль к зашифрованному тому.

Какие протекторы поддерживаются

О тому, какие именно протекторы существуют, подробно рассказано в статье Механизмы защиты BitLocker: какие диски можно, а какие нельзя взломать. Сегодня перед нами не стоит задача взлома соответствующего протектора; всё, что нам требуется осуществить — это получить доступ к учётным записям системы, загрузившись с USB накопителя. В зависимости от типа протектора доступны следующие варианты.

• TPM. Достаточно часто используется для защиты системных накопителей, особенно в портативных компьютерах. Elcomsoft System Recovery поддерживает такие тома, если у вас есть наготове депонированный ключ.
• Только пароль. Второй по популярности тип протектора; чаще всего встречается на внешних дисках и разделах, не являющихся системными. ESR предлагает сразу два способа смонтировать такие тома: паролем тома (если он известен) либо депонированным ключом.
• USB. В компьютерах, не оборудованных модулем TPM или платформой Intel PTT, иногда используют защиту в виде ключа USB. Для этого требуется редактирование групповых политик Windows; зашифрованный том разблокируется автоматически при наличии так называемого Startup Key. ESR может смонтировать такие тома при наличии либо самого ключа Startup Key, либо депонированного ключа.
• TPM+PIN, TPM+USB, TPM+PIN+USB. Данные комбинации потребуют наличия всех без исключения протекторов. В рамках Elcomsoft System Recovery данные типы протекторов поддерживаются только при наличии депонированного ключа.

Для удобства мы свели данные в таблицу. В первой колонке (Supported in ESR 7.05) приводится информация о том, можно ли смонтировать том BitLocker, если в вашем распоряжении есть указанный протектор (к примеру, ключ, пароль или PIN-код). В правой колонке указано, можно ли смонтировать том, если у вас есть доступ к депонированному ключу.

Как смонтировать зашифрованный том

Для загрузки в Elcomsoft System Recovery необходимо создать загрузочный накопитель в ESR 7.05 или новее. Чтобы создать загрузочный USB накопитель, запустите программу на своём (а не на исследуемом) компьютере и следуйте указаниям мастера.

После создания загрузочного накопителя используйте его для загрузки целевого компьютера. После загрузки компьютера будет запущено приложение Elcomsoft System Recovery. Инструмент автоматически просканирует доступные жёсткие диски на предмет зашифрованных томов. Если ESR обнаружит хотя бы один том BitLocker, будет выведено предложение разблокировать диск:

Для продолжения нажмите Yes и Next.

В следующем окне ESR отобразит букву диска и тип протектора. Если будет обнаружен хотя бы один неподдерживаемый протектор, такие протекторы не будут показаны по умолчанию. Чтобы отобразить все протекторы, включая неподдерживаемые, снимите флажок «Show supported disk protectors only».

Как только флажок будет снят, вы увидите неподдерживаемые протекторы. В приведённом ниже примере загрузочный диск был защищён двумя протекторами: TPM+PIN (напрямую не поддерживается в ESR) и депонированным ключом (Recovery Key), который в ESR поддерживается.

Чтобы разблокировать диск, введите ключ восстановления (48 цифр) в поле «Numerical password», затем нажмите «Unprotect». Если ключ восстановления правильный, том будет успешно разблокирован.

Встречаются тома BitLocker, защищённые сразу несколькими протекторами, которые поддерживаются ESR. В приведённом ниже примере том был защищён паролем, а ключ восстановления был создан в качестве дополнительного (резервного) протектора. Собственно, именно так обычно и защищены все диски, кроме загрузочных. В этом случае укажите тот тип протектора, к которому у вас есть доступ. Например, если вы знаете пароль к тому BitLocker, выберите «Password».

BitLocker — одно из наиболее продвинутых и, наверное, самое популярное решение для шифрования дисков. BitLocker подробно документирован и отлично изучен. Время от времени в механизме обнаруживались уязвимости, но область их использования была весьма специфичной, а сами уязвимости исправлялись с очередным обновлением Windows. Тома BitLocker могут быть защищены одним или несколькими предохранителями, такими как аппаратный TPM, пароль пользователя, USB-ключ или их комбинация. Атака на пароль возможна только в одном из этих случаев, в то время как другие средства защиты требуют совсем другого набора атак. В этой статье мы подробно расскажем о механизмах защиты BitLocker и о подходах, которые можно использовать для расшифровки томов.

Как устроено шифрование диска

Для шифрования диска BitLocker последовательно использует несколько разных ключей, каждый из которых служит своей цели.

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

Полный ключ шифрования тома шифруется основным ключом тома и хранится в заголовке зашифрованного диска (так называемые «метаданные шифрования»). Основной ключ тома также хранится на зашифрованном диске; он тоже зашифрован. Для шифрования основного ключа тома используется пароль пользователя (если речь идёт о сменном носителе), двоичный ключ или сертификат либо данные модуля TPM.

Что происходит, если защита BitLocker приостанавливается или пользователь отключает защиту, решив «расшифровать» диск? В этом случае данные физически не расшифровываются и не перезаписываются; однако система сохраняет в незащищённом виде ключ, которым шифруется основной ключ тома.

С точки зрения Microsoft, такая процедура хранения гарантирует, что основной ключ тома никогда не хранится без шифрования и всегда защищён, если не отключено шифрование BitLocker. Для обеспечения избыточности система сохраняет ещё две копии ключей в разных местах на диске.

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

Где хранятся все эти ключи? Полный ключ тома, защищённый основным ключом тома, хранится в заголовке контейнера (и двух дополнительных местах на диске) в зашифрованном виде. Это хранилище мы называем метаданными шифрования, и именно эти данные извлекают продукты Elcomsoft Forensic Disk Decryptor и Elcomsoft System Recovery для последующих атак. Основной ключ тома, зашифрованный паролем или другим протектором, сохраняется в них же. А вот протектор (пароль пользователя, данные модуля TPM, двоичный ключ или сертификат) в составе контейнера не хранятся: именно эти данные будут использованы для расшифровки цепочки ключей и, соответственно, данных на диске.

Методы защиты

Как мы выяснили, основной ключ тома может быть зашифрован различными протекторами. Некоторые из этих протекторов – аппаратные; чтобы разблокировать том и расшифровать данные, вам понадобится компьютер пользователя (и, в зависимости от типа атаки, аутентифицированная сессия Windows); атака на пароль методом перебора будет невозможна. Посмотрим, какие протекторы существуют, как они используются и как действовать в случае, если обнаружен один из них.

Во-первых, определим, есть ли в системе зашифрованные диски в принципе. Рекомендуем воспользоваться нашим бесплатным инструментом Elcomsoft Encrypted Disk Hunter для определения зашифрованных дисков.

Если найден зашифрованный том, то в Windows тип протектора тома можно определить, запустив следующую команду (зашифрованный том должен быть смонтирован):

manage-bde -protectors -get X:

Здесь X: — буква тома.

Если же в вашем распоряжении только диск или его образ, то используйте Elcomsoft Forensic Disk Decryptor для извлечения метаданных шифрования и Elcomsoft Distributed Password Recovery для попытки атаки.

Итак, рассмотрим возможные типы протекторов.

TPM

Аппаратные модули TPM часто используются в портативных компьютерах – ноутбуках, планшетах и устройствах 2-в-1. При использовании защиты TPM Windows загрузится до запроса входа в систему. Основной ключ тома будет расшифрован с помощью корневого ключа хранилища, который хранится в модуле TPM (или Intel PTT). Ключ будет выдан наружу в том и только в том случае, если система проходит проверку безопасной загрузки. Этот вариант совершенно прозрачен для пользователя: многие даже не подозревают, что их ноутбук или планшет зашифрован.

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

1. Ключ восстановления доступа BitLocker. Windows автоматически создаёт ключ восстановления при шифровании BitLocker Device Protection; такие ключи восстановления автоматически загружаются в учётную запись Microsoft Account первого пользователя компьютера, который вошёл в систему с административными привилегиями. Вы можете запросить этот ключ у Microsoft или загрузить его, войдя в учётную запись Microsoft и перейдя по следующей ссылке: https://account.microsoft.com/devices/recoverykey
2. Дополнительные варианты. Ключ восстановления доступа может храниться в других местах – например, в Active Directory: Где найти ключ восстановления BitLocker?
3. Атака методом холодной загрузки. BitLocker в конфигурации по умолчанию использует доверенный платформенный модуль TPM (если таковой установлен), которому для расшифровки диска не требуется ни пин-код, ни внешний ключ. Когда операционная система загружается, BitLocker извлекает ключ из TPM без какого-либо взаимодействия с пользователем. Следовательно, можно просто включить машину, подождать, пока операционная система начнёт загрузку, а затем выполнить атаку методом холодной загрузки для извлечения ключа из оперативной памяти компьютера. Обратите внимание, что эта атака недоступна, если в дополнение к TPM использовался пароль или ключ.Что такое атака методом холодной загрузки? Это технически сложный вид атаки, в процессе которого производится заморозка чипов памяти жидким азотом или сжатым воздухом, после которой питание компьютера отключается, а модули памяти физически извлекаются (или производится загрузка с USB-накопителя) с целью доступа к содержимому оперативной памяти и поиска ключей шифрования. Помимо исключительной технической сложности этого типа атаки, у него есть и ещё один недостаток: он работает только с компьютерами, модули памяти в которых не распаяны (т.е. их физически можно извлечь).
4. Образ оперативной памяти. Если у вас есть доступ к компьютеру пользователя и вы можете войти в систему или получить дамп памяти с помощью атаки через интерфейс FireWire/Thunderbolt, то можно извлечь получить ключи шифрования непосредственно из оперативной памяти компьютера. В состав Elcomsoft Forensic Disk Decryptor входит как утилита для снятия образа оперативной памяти, так и инструмент для его анализа с целью поиска ключей шифрования.

TPM + ПИН

В этом режиме для загрузки Windows потребуется не только модуль TPM, но и дополнительный ключ (ПИН-код или пароль). Модуль TPM выдаст ключ шифрования в том и только в том случае, если на вход будет подан правильный пароль (ПИН). Как правило, длина ПИН-кода не превышает 4 цифр, но после нескольких неудачных попыток модуль TPM заблокирует доступ к ключу шифрования.

Векторы атаки: Режим TPM+ПИН – интерактивный: от пользователя требуется ввести ПИН-код, причём именно на том компьютере, на котором использовался зашифрованный диск. Сам по себе ПИН-код не используется для шифрования; он нужен для того, чтобы аппаратный модуль TPM выдал системе необходимый ключ. Перебор ПИН-кодов опасен: в зависимости от производителя и настроек модуля перебор может привести как к блокировке модуля TPM, так и к уничтожению ключа шифрования.

1. Ключ восстановления доступа BitLocker. Windows автоматически создаёт ключ восстановления при шифровании BitLocker Device Protection; такие ключи восстановления автоматически загружаются в учётную запись Microsoft Account первого пользователя компьютера, который вошёл в систему с административными привилегиями. Вы можете запросить этот ключ у Microsoft или загрузить его, войдя в учётную запись Microsoft и перейдя по следующей ссылке: https://account.microsoft.com/devices/recoverykey
2. Атака методом холодной загрузки сработает лишь в том случае, если вам известен ПИН-код. В противном случае система не загрузится, а ключ шифрования не попадёт в оперативную память.
3. Образ оперативной памяти. Сработает только в том случае, если компьютер уже загружен. Используйте Elcomsoft Forensic Disk Decryptor для снятия образа оперативной памяти и его анализа с целью поиска ключей шифрования.

TPM + USB

Этот вариант для загрузки системы требует присутствия как TPM, так и USB-накопителя (или смарт-карты CCID). Это нестандартная, но возможная конфигурация.

Векторы атаки: Режим TPM+USB требует наличия файла с ключом на USB-накопителе. Соответственно, вам потребуется доступ к этому накопителю (а точнее, к ключу на нём).

1. Ключ восстановления доступа BitLocker. Никаких различий с предыдущим протектором.
2. Атака методом холодной загрузки сработает лишь в том случае, если в наличии есть USB накопитель с ключом. В противном случае система не загрузится, а ключ шифрования не попадёт в оперативную память.
3. Образ оперативной памяти. Сработает только в том случае, если компьютер уже загружен. Используйте Elcomsoft Forensic Disk Decryptor для снятия образа оперативной памяти и его анализа с целью поиска ключей шифрования.

TPM + ПИН + USB

Довольно редкая реализация «параноидальной» защиты, комбинирующая два предыдущих метода. Уже из названия очевидно, что для загрузки системы потребуется и модуль TPM, и ввод ПИН-кода, и наличие USB накопителя с ключом.

Векторы атаки: Режим TPM+USB требует наличия файла с ключом на USB-накопителе и ввода ПИН-кода в дополнение к аппаратному модулю TPM. Соответственно, для доступа к данным вам потребуется всё вышеперечисленное.

1. Ключ восстановления доступа BitLocker. Никаких различий с предыдущим протектором.
2. Атака методом холодной загрузки сработает лишь в том случае, если в наличии есть USB накопитель с ключом, а ПИН-код вам известен. В противном случае система не загрузится, а ключ шифрования не попадёт в оперативную память.
3. Образ оперативной памяти. Сработает только в том случае, если компьютер уже загружен. Используйте Elcomsoft Forensic Disk Decryptor для снятия образа оперативной памяти и его анализа с целью поиска ключей шифрования.

USB

Переходим от сложного – к простому. Вариант с ключом на USB накопителе гораздо проще взломать по сравнению с использованием модулей TPM. Для расшифровки диска вам понадобится только USB накопитель с ключом.

Векторы атаки: Пароля по-прежнему нет; для расшифровки диска нужен накопитель с ключом.

1. Ключ восстановления доступа BitLocker. Никаких различий с предыдущим протектором.
2. Атака методом холодной загрузки в данной ситуации лишена смысла. С одной стороны, атака сработает лишь в том случае, если в наличии есть USB накопитель с ключом. С другой — если в нашем распоряжении есть накопитель с ключом, то смонтировать зашифрованный раздел можно гораздо проще.
3. Образ оперативной памяти. Сработает только в том случае, если компьютер уже загружен. Используйте Elcomsoft Forensic Disk Decryptor для снятия образа оперативной памяти и его анализа с целью поиска ключей шифрования.

Только пароль

Наконец, мы подошли к единственному протектору, который можно взломать методом полного перебора. Протектор «только пароль» защищает ключ исключительно паролем пользователя – который можно подобрать при помощи Elcomsoft Distributed Password Recovery. Более того, атаку можно проводить на другом компьютере как на сам диск, так и на его образ – модуль TPM в данной схеме не участвует, поэтому никаких ограничений на количество попыток или скорость перебора нет.

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

1. Ключ восстановления доступа BitLocker. Никаких различий с предыдущим протектором.
2. Атака методом холодной загрузки так же, как и в предыдущем случае, лишена смысла. С одной стороны, атака сработает лишь в том случае, если вы уже знаете пароль от зашифрованного тома. С другой — если вы знаете пароль, то и атака не нужна.
3. Образ оперативной памяти. Сработает только в том случае, если компьютер уже загружен. Используйте Elcomsoft Forensic Disk Decryptor для снятия образа оперативной памяти и его анализа с целью поиска ключей шифрования.
4. Перебор паролей. Используйте Elcomsoft Forensic Disk Decryptor для извлечения метаданных шифрования из самого диска или его образа. Метаданные шифрования откройте в Elcomsoft Distributed Password Recovery для настройки атаки. Вы также можете использовать Elcomsoft System Recovery для загрузки компьютера пользователя с USB накопителя с целью извлечения метаданных шифрования без разборки компьютера и извлечения самого диска.

Когда пароля нет

Если пароль не установлен или если пароль используется совместно с другим типом протектора, пытаться его подобрать – занятие бессмысленное. Даже если вы извлекли метаданные шифрования и загрузили их в Elcomsoft Distributed Password Recovery, вы не сможете запустить атаку: продукт выдаст сообщение о несовместимом типе протектора. Именно таким образом обычно и развиваются события в случаях, когда в деле фигурирует модуль аппаратной защиты TPM. Запомним: атака на пароль в случае, если том BitLocker зашифрован с протектором типа TPM, бессмысленна; расшифровать такой диск можно либо депонированным ключом (например, извлечённым из хранилища OneDrive в учётной записи пользователя Microsoft Account), либо ключом, который извлекается из оперативной памяти загруженного компьютера пользователя. Об этом – подробнее.

Что произойдёт, если мы имеем дело не с отдельным диском и не с его образом, а с уже загруженным компьютером, на котором смонтирован зашифрованный том BitLocker? В этом случае присутствует ещё один ключ, наличие которого не упоминается в документации. Этот ключ хранится в оперативной памяти компьютера и используется драйвером BitLocker для реализации «прозрачного» потокового шифрования. Подобным образом работают все утилиты шифрования диска, но если в некоторых сторонних решениях (например, VeraCrypt) пользователь может включить обфускацию этого ключа, что затрудняет его извлечение из оперативной памяти, то BitLocker не делает попыток «спрятать» ключ. Соответственно, при помощи специальных инструментов (таких как Elcomsoft Forensic Disk Decryptor) этот ключ можно извлечь из образа оперативной памяти, файла подкачки или файла гибернации (впрочем, если зашифрован системный том, то и эти файлы будут зашифрованы; остаётся лишь образ оперативной памяти). Извлечённый таким образом ключ можно использовать для мгновенного монтирования или расшифровки защищённого тома.

Ваши действия:

• На компьютере пользователя запустите Elcomsoft Forensic Disk Decryptor.
• Создайте образ оперативной памяти.
• Откройте его в Elcomsoft Forensic Disk Decryptor на своём компьютере и осуществите поиск ключей BitLocker.
• Если ключи найдены, создайте образ зашифрованного диска и используйте Elcomsoft Forensic Disk Decryptor для его монтирования или расшифровки.

Практические шаги

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

Шаг 1.1: Извлечение метаданных шифрования BitLocker при помощи Elcomsoft Forensic Disk Decryptor

Используйте Elcomsoft Distributed Password Recovery для сохранения метаданных шифрования в файл.

1. Запустите Elcomsoft Forensic Disk Decryptor.
2. Выберите опцию «Extract/prepare data for further password recovery«.
   
3. Откройте образ диска или сам диск (в примере ниже мы использовали физический жёсткий диск).
   
4.  EFDD отобразит список зашифрованных томов. Выберите один из них.
   
5. Нажмите Next для сохранения метаданных шифрования.

Важно: Подобрать пароль можно в том и только в том случае, если используется протектор «только пароль». Все остальные протекторы (с участием TPM, ключей или сертификатов) такой атаке не поддаются. Чтобы сэкономить ваше время, EFDD предупредит о подобных ситуациях:

Если такое произойдёт, используйте альтернативный вектор атаки.

Шаг 1.2: Извлечение метаданных шифрования BitLocker посредством Elcomsoft System Recovery

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

Elcomsoft System Recovery позволяет сэкономить время, загрузив компьютер с портативного накопителя. Программа автоматически обнаруживает шифрование диска и позволяет извлечь метаданные шифрования, необходимые для подбора исходного пароля.

1. Установите Elcomsoft System Recovery на ваш компьютер (не на компьютер подозреваемого!)
2. Создайте загрузочный накопитель. Обязательно укажите правильную конфигурацию целевой системы (BIOS или UEFI, 32-разрядная или 64-разрядная). Как правило, имеет смысл использовать быстрый USB-накопитель объёмом не менее 32 ГБ. Инструкция по созданию загрузочной флешки находится здесь.
3. Загрузите с созданного накопителя компьютер, с которого нужно извлечь метаданные.
4. Elcomsoft System Recovery запустится автоматически. Выберите пункт Disk tools.
   
5. Выберите пункт Drive encryption keys.
   
6. Elcomsoft System Recovery выведет список найденных разделов.
   
7. Выберите зашифрованный том.
8. Метаданные шифрования сохранятся на USB накопителе. Перенесите созданные файлы в Elcomsoft Distributed Password Recovery для настройки атаки.

Внимание: Подобрать пароль можно в том и только в том случае, если используется протектор «только пароль». Все остальные протекторы (с участием TPM, ключей или сертификатов) такой атаке не поддаются. Чтобы сэкономить ваше время, ESR предупредит о подобных ситуациях:

Шаг 2: восстановление оригинального пароля к тому в Elcomsoft Distributed Password Recovery

Чтобы восстановить пароль к тому, проделайте следующие шаги.

1. Запустите Elcomsoft Distributed Password Recovery
2. Откройте метаданные шифрования, сохранённые на предыдущем шаге.
3. Настройте и запустите атаку.

Хотя эти три шага кажутся простыми, выполнение атаки методом полного перебора — один из наименее эффективных способов взломать шифрование BitLocker. Мы настоятельно рекомендуем настроить интеллектуальную атаку на основе шаблонов, которые можно определить, проанализировав существующие пароли пользователя. Эти пароли можно извлечь из учётной записи пользователя Google, Связки ключей macOS, iOS или iCloud, учётной записи Microsoft или непосредственно с компьютера пользователя. Существующие пароли пользователя подсказывают, какие группы символов могут быть использованы:

Elcomsoft Distributed Password Recovery предлагает ряд опций с использованием самых распространённых вариаций, например, Password1, password1967 или pa$$w0rd:

Если в паролях пользователя есть что-то общее, можно использовать маски:

Наконец, можно использовать методы, при помощи которых варианты паролей можно составлять с использованием до двух словарей и скриптовых правил:

Tally ERP 9 – аналог системы 1С: Предприятие, разработанный и получивший широкое распространение в Индии. Производитель описывает продукт как «программное обеспечение для управления бизнесом нового поколения для бизнеса нового поколения», которое, снова процитирую создателей, «создано для наслаждения». В сегодняшней статье мы ознакомимся с особенностями шифрования данных в Tally ERP 9 и расскажем о том, как разрабатывался способ вскрытия защиты.

О продукте Tally ERP 9

Tally ERP 9 – популярный в Индии программный продукт с более чем двумя миллионами пользователей. С учётом размера целевой аудитории программы, Tally – одно из самых популярных решений такого рода в Индии.

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

Каким образом обычно поступают производители программного обеспечения, в котором нужно обеспечить безопасность данных пользователя? В подавляющем большинстве случаев используется симметричное шифрование. В качестве алгоритма выбирается стандартный AES с ключом длиной 128, 192 или 256 бит. AES – отличный выбор: он проверен временем, а набор процессорных инструкций AES-NI, доступный во всех процессорах Intel, позволяет достичь совершенно избыточных скоростей шифрования.

Для шифрования данных используется ключ Media Encryption Key (MEK). Как правило, этот ключ – совершенно случайная двоичная последовательность, которая создаётся одним из стандартных алгоритмов генерации случайных чисел. Уже этот ключ будет зашифрован ключом шифрования ключа шифрования Key Encryption Key (KEK). KEK, в свою очередь, генерируется на основе комбинации пароля пользователя и соли посредством одной из стандартных хеш-функций (чаще всего это SHA-1, SHA-256 или SHA-512, но нам попадались и другие варианты). Стойкость алгоритма усиливается увеличением числа итераций хеш-функции; нам попадались варианты от 10,000 итераций (это очень быстрый перебор) до миллиона (соответственно, перебор очень медленный) включительно. Таким образом, для того, чтобы добавить поддержку нового формата защиты, нам нужно просто определить, каким именно алгоритмом шифрования воспользовался производитель и восстановить функцию преобразования ключа (определить алгоритм хеширования, число итераций и место в файле, куда сохраняется соль).

Шифрование Tally Vault

В состав Tally ERP 9 входит реализация безопасного хранилища под названием Tally Vault. Шифрование в ERP 9 – опциональное; пароль задавать пользователю не обязательно. Пароль хранилища можно задать как при создании компании, так и в любой момент после этого:

Когда пользователь задаёт пароль, система создаёт новое, защищённое хранилище. Старое, незащищённое, остаётся; впоследствии пользователь может его удалить. Эта схема чрезвычайно удобна для исследования: зашифрованную копию хранилища можно напрямую сравнить с незашифрованной. Так выглядит выбор компании, если есть и зашифрованная, и незашифрованная версия данных:

Данные в последних версиях Tally ERP 9 по умолчанию сохраняются в c:\Users\Public\Tally.ERP9\Data\(1nnnn)

Зашифрованы будут все файлы с расширением .900, размер которых превышает 512 байт. Основной файл хранилища – Company.900. В этом файле сохраняется информация о пользователях, если включена опция “Use security control”. Так выглядит этот файл в hex-редакторе до шифрования:

А так – после:

Формат файла

Файл логически разбит на секторы (страницы) по 512 байт. В начале каждой страницы записаны 4 байта контрольной суммы (CRC). При проверке блока на целостность вычисляется контрольная сумма остальных (512-4) байт и сравнивается с первыми четырьмя байтами.

Ключ шифрования

Ключ шифрования получается из пароля напрямую; никакой соли, а тем более – разделения на Media Encryption Key и Key Encryption Key, здесь нет.

Интересен и выбор алгоритма шифрования. Разработчики Tally Vault решили не полагаться на существующие криптографические преобразования и создали свой собственный вариант, настоящий кошмар криптографа. Все существующие алгоритмы хеширования без исключений гарантируют, что изменение всего одного бита в хешируемой последовательности приведёт к полному изменению всей контрольной суммы. Индийским разработчикам удалось сделать невероятное: они создали хеш-функцию, в которой при небольшом изменении пароля результат тоже меняется очень незначительно. Более того, у нас создалось впечатление, что при определённых условиях этот хеш можно обратить, получив из него оригинальный пароль (разумеется, если энтропия пароля не превышает энтропии его контрольной суммы). Вишенка на торте: преобразование применяется ровно один раз.

К примеру, вот так выглядят ключи шифрования на основе паролей, в которых попарно различается один символ:

Алгоритм шифрования

Страницы шифруются алгоритмом, принцип работы которого сильно напоминает обычный DES. Для шифрования используется 64-битный ключ (который в процессе работы разворачивается в расширенный 128-битный, как и у «настоящего» DES). Шифрование блочное, размер блока – привычные для алгоритма DES 64 бита. Алгоритм используется в режиме CBC с первоначальной инициализацией IV нулями. Напомню, DES (Data Encryption Standard) — алгоритм симметричного шифрования, утверждённый правительством США в 1977 году в качестве официального стандарта. В 2001 от использования DES отказались; ему на смену пришёл привычный нам алгоритм AES. Что заставило индийских разработчиков взять за основу принципы работы именно этого давно устаревшего алгоритма – для нас загадка.

Уже на этом месте можно прекратить исследование и реализовать простейшую атаку на ключ. На современном оборудовании всё пространство ключей можно перебрать за считанные дни. При желании можно осуществить рефакторинг ключей; впрочем, принцип «неуловимого Джо» надёжно защищает Tally от подобных атак.

Проверка пароля

В коде Tally Vault проверка пароля осуществляется путём расшифровки страницы (всех 512-4 байт), вычисления её контрольной суммы (CRC) и её сравнения со значением, записанным в начале страницы. По замыслу разработчиков, для расшифровки всей страницы и полной проверки пароля потребуется расшифровать 64 блока по 8 байт (64 бита). Однако в данном случае дьявол кроется в деталях, и для проверки пароля вычислять контрольную сумму всей страницы совершенно не обязательно.

Вернёмся к первому скриншоту:

В начале каждой страницы есть некая служебная информация, содержимое которой фиксировано или может быть известно заранее. Например, сразу после CRC, по смещению 4, находится 32-битная фиксированная последовательность DWORD 0x00000001. Назначение этой последовательности нам неизвестно; предположительно, это флаг страницы данных. Соответственно, для ускорения проверки правильности пароля в процессе перебора можно прервать расшифровку страницы сразу после первого блока, если содержимое этих 32-бит байтах не 0x00000001. Разумеется, 32 бита данных гарантированно дадут некоторое число коллизий, которые потенциально приведут к ложным срабатываниям. Поэтому в случаях, когда значение расшифрованных очередным ключом 32 бита данных совпало со значением 0x00000001, мы проведём расшифровку блока до конца, вычислим CRC и сравним контрольную сумму со значением, записанным в первых 4 байтах страницы. Однако количество таких коллизий будет порядка 1 к 4 миллиардам, что практически не влияет на скорость перебора паролей.

Кстати, если после прочтения этой статьи разработчики изменят или вовсе уберут фиксированное значение по смещению 4, можно использовать и другие константы. Например, по смещению 12 записывается последовательный номер страницы, если страница – не последняя.

Результат

Вооружившись знанием об использованных алгоритмах хеширования и шифрования, мы разработали две версии плагина для Elcomsoft Distributed Password Recovery. В первой версии плагина реализована «лобовая» атака, в которой правильность пароля проверяется именно так, как задумали индийские разработчики. Во второй – для проверки используется константа в первом зашифрованном блоке. Как и ожидалось, разница в скорости впечатляет.

Сравнение скорости на двух CPU:

11 миллионов паролей в секунду на одном процессоре, без использования GPU – много это или мало? Для сравнения, скорость атаки на CPU для документов в формате .docx, созданных в Microsoft Office 2016, составляет порядка 40 паролей в секунду, OpenOffice — 9000. Скорость атаки на контейнеры VeraCrypt – чуть больше 1 пароля в секунду. Атака на резервные копии iTunes – порядка 1 пароля в 10 секунд. Архивы RAR – порядка 64 паролей в секунду, 7zip – около 25.

Взлом

Для взлома паролей Tally Vault воспользуемся Elcomsoft Distributed Password Recovery с соответствующим плагином. Для проведения атаки откроем файл Company.900:

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

Пароль обнаружился менее, чем за секунду:

Усложнив задачу, запустили полный перебор, чтобы посмотреть скорость атаки, которая стабилизировалась на 11.1 миллионах паролей в секунду.

Как было бы правильно

Как можно было бы реализовать шифрование правильным образом? В данном случае достаточно было бы сделать «как все», а именно:

1. В качестве алгоритма шифрования использовать стандартный AES с длиной ключа 256 бит.
2. Для шифрования данных использовать ключ Media Encryption Key (MEK), созданный криптографически стойким генератором случайных чисел.
3. MEK сохранять в зашифрованном виде. Шифрование этого ключа осуществлять при помощи дополнительного ключа Key Encryption Key (KEK).
4. Key Encryption Key вычислять посредством одной из готовых KDF (Key Derivation Function), использующих многочисленные (порядка сотен тысяч) итерации хеш-функции SHA-256 или SHA-512 на основе пароля пользователя и соли.

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

Заключение

Tally ERP 9 полностью оправдал заявку маркетологов «создано для наслаждения». Мы получили редкое удовольствие, создавая атаку на данные Tally Vault, словно вернувшись на 20 лет назад во времена слабой, зарегулированной экспортными ограничениями защиты.

Что же касается самого Tally Vault, то разработчики совершили все возможные и невозможные ошибки. Мы не смогли найти ни одного аспекта защиты, который был бы реализован на уровне хотя бы школьника-энтузиаста. Беспросветно плохо здесь абсолютно всё. Здесь и прямое преобразование пароля в ключ шифрования, и пренебрежение солью, и единственная итерация доморощенного (и безграмотно реализованного) алгоритма хеширования. Использование алгоритма на основе DES более чем 40-летней давности в комбинации с коротким ключом шифрования делают возможной атаку на ключ (а не на пароль), и только отсутствие спроса защищает продукт от полного рефакторинга. Исправить эти алгоритмы принципиально невозможно, можно лишь сделать заново.

Впрочем, здесь тот случай, когда и «сделать заново», вероятно, не поможет. Фиксированные данные, находящиеся в самом начале страницы данных, позволяют ограничиться расшифровкой единственного 64-битного блока, что более чем в 30 раз ускоряет проверку. Нам же остаётся порадоваться очередному установленному рекорду: более 11 миллионов паролей в секунду на единственном CPU, без использования даже аппаратного ускорения – наш абсолютный рекорд за всё время работы.

Шифрование по стандарту LUKS поддерживается практически во всех сборках Linux для настольных компьютеров. Использование LUKS позволяет как зашифровать диск целиком, так и создать зашифрованный контейнер. В LUKS поддерживаются многочисленные алгоритмы и методы шифрования, а также несколько хэш-функций для преобразования пароля пользователя в ключ шифрования. Если установленный пользователем пароль неизвестен, то для расшифровки защищённого диска необходимо восстановить оригинальный текстовый пароль. Этим мы и займёмся сегодня.

Основы шифрования диска

Утилиты шифрования дисков используют симметричную криптографию для преобразования информации в зашифрованный поток данных. В подавляющем большинстве случаев используется алгоритм шифрования AES, для которого (единственного из множества алгоритмов) в большинстве современных платформ доступно аппаратное ускорение, а в процессорах Intel – специальный набор инструкций процессора AES-NI. Как правило, используется ключ шифрования длиной 256 бит, но и ключи длиной 128 бит используются достаточно часто (в частности, в реализации шифрования Microsoft BitLocker, в котором по умолчанию используются ключи шифрования длиной 128 бит, но можно включить и поддержку 256-разрядных ключей).

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

Не менее, а для целей восстановления доступа – даже более важной особенностью систем шифрования диска является выбор функции преобразования ключа – Key Derivation Function (KDF). Эта функция используется для одностороннего (то есть, несимметричного и принципиально необратимого) преобразования текстового пароля (или другого протектора – например, данных сертификата или содержимого файла) в двоичный ключ заданной длины. Как правило, алгоритм KDF достаточно прост: входные данные (а ими является не только сам пароль, но и дополнительный набор данных – «соль») преобразовываются посредством хэш-функции, причём процедура проводится итеративно с целью замедлить скорость потенциальной атаки. Чем большее количество итераций используется для преобразования пароля, тем ниже будет скорость перебора.

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

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

LUKS

LUKS (от Linux Unified Key Setup) — спецификация формата шифрования дисков, разработанная для использования в ОС на основе ядра Linux. Поддержка LUKS доступна во множестве дистрибутивов Linux как для настольных компьютеров, так и для специализированных устройств. При помощи LUKS могут быть зашифрованы диски, работающие в составе сетевых накопителей QNAP и некоторых других производителей.

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

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

Алгоритмы шифрования в LUKS

В LUKS поддерживаются следующие алгоритмы шифрования:

• AES
• Serpent
• Twofish
• CAST-128
• CAST-256

Чаще всего применяется AES, но в процессе создания зашифрованного диска или контейнера пользователь может указать другой алгоритм. В наших продуктах поддерживаются алгоритмы AES, Serpent и Twofish как наиболее распространённые.

Режимы шифрования

В LUKS можно использовать один из следующих режимов шифрования:

• ECB
• CBC-PLAIN64
• CBC-ESSIV:hash
• XTS-PLAIN64

В различных дистрибутивах Linux могут использоваться различные настройки по умолчанию. К примеру, в Red Hat Linux используется комбинация параметров cbc-essiv:sha256 с шифрованием AES и 256-битным ключом. Эти настройки встречаются чаще всего.

Хэш-функции

Хэш-функции, или функции одностороннего криптографического преобразования, используются для преобразования пароля в двоичный ключ в составе Key Derivation Function (KDF). LUKS поддерживает следующие варианты:

• SHA-1
• SHA-256
• SHA-512
• RIPEMD160
• WHIRLPOOL *

По умолчанию используется SHA-256. При этом Whirlpool – отличный пример хэш-функции, которая не является частью спецификации, но присутствует и используется в реальной жизни. В наших продуктах поддерживаются все перечисленные хэш-функции.

Настройки шифрования по умолчанию

Чаще всего при создании зашифрованного диска используются настройки по умолчанию: aes-cbc-essiv:sha256 с ключом шифрования длиной 256 бит. Ниже приводится расшифровка параметров шифрования:

• AES – алгоритм симметричного шифрования AES (в данном случае с ключом длиной 256 бит)
• CBC – режим шифрования Cipher Block Chaining
• ESSIV – Encrypted Salt-Sector Initialization Vector. Он должен использоваться для шифров в режиме CBC.
• SHA-256 – Secure Hash Algorithm, используется по умолчанию с шифрами в режиме CBC.

Альтернативные настройки шифрования

Как пользователь, так и автор сборки Linux могут указать альтернативные настройки шифрования. При этом не все комбинации алгоритмов и режимов работы совместимы между собой. Впрочем, так или иначе все выбранные настройки шифрования будут прописаны в заголовке LUKS, и для проведения атаки их достаточно будет считать из него. Elcomsoft Distributed Password Recovery автоматически определяет параметры шифрования LUKS.

Слоты ключей

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

При настройке атаки в Elcomsoft Distributed Password Recovery эксперт выбирает слот ключа, на который будет проводиться атака. В списке слотов ключей, которые выводит Distributed Password Recovery, указывается, какие из слотов содержат действительные ключи, а какие – пустуют. Обратите внимание: если пустуют все слоты (такое возможно как при случайном удалении последнего ключа, так и при умышленном уничтожении с целью предотвращения доступа), то восстановить доступ к зашифрованным данным будет невозможно.

Шаг 1: извлечение метаданных шифрования

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

1. Извлечь метаданные шифрования (заголовок LUKS) из состава контейнера или диска утилитой Elcomsoft Forensic Disk Decryptor или Elcomsoft System Recovery. Данные сохраняются в небольшом файле.
2. Открыть файл с метаданными шифрования в Elcomsoft Distributed Password Recovery, выбрать слот ключа, настроить и провести атаку.
3. После того, как пароль будет найден, смонтировать или расшифровать зашифрованный диск.

Для извлечения метаданных шифрования можно воспользоваться одним из двух инструментов. При исследовании непосредственно компьютера подозреваемого его можно загрузить с USB-накопителя, созданного программой Elcomsoft System Recovery. В этом случае метаданные шифрования можно извлечь непосредственно с исследуемого компьютера.

Если же в вашем распоряжении диски или образы дисков, то для извлечения метаданных следует воспользоваться программой Elcomsoft Forensic Disk Decryptor.

Использование Elcomsoft System Recovery

Внимание: используйте Elcomsoft System Recovery версии 7.06 или более новой.

1. Скачайте Elcomsoft System Recovery и запустите программу установки. Создайте загрузочный USB накопитель.
2. Загрузите исследуемый компьютер с созданного на предыдущем шаге USB накопителя. Вы попадёте в среду Windows PE. Утилита Elcomsoft System Recovery запустится автоматически.
3. 
4. Просмотрите список дисков.
5. Выберите диски LUKS и нажмите “Dump” для сохранения метаданных шифрования.
6. Откройте файл с метаданными шифрования в Elcomsoft Distributed Password Recovery для настройки атаки.

Использование Elcomsoft Forensic Disk Decryptor

Внимание: используйте Elcomsoft Forensic Disk Decryptor версии 2.13 или выше.

1. Запустите Elcomsoft Forensic Disk Decryptor.
2. Выберите опцию “Extract/prepare data for further password recovery”.
3. Выберите диск или образ диска LUKS. В примере ниже выбран физический диск.
   
4. EFDD отобразит список зашифрованных томов. Выберите том для извлечения метаданных.
   
5. Нажмите Next для сохранения метаданных шифрования в файл.
   

Шаг 2: восстановление пароля

LUKS обеспечивает стойкую защиту от перебора, но современные инструменты для взлома паролей позволяют значительно ускорить перебор с использованием как аппаратных ускорителей на основе видеокарт, так и многочисленных компьютеров, объединённых в единую вычислительную сеть.

Для настройки атаки выполните следующие действия.

1. Запустите Elcomsoft Distributed Password Recovery.
2. Откройте файл с метаданными LUKS, сохранённый при помощи Elcomsoft Forensic Disk Decryptor либо Elcomsoft System Recovery.
3. Выберите слот ключа.
4. Настройте и запустите атаку.

Скорость перебора – важный, но не основной параметр, влияющий на время восстановления пароля. Использование «умных» атак может существенно сократить времязатраты – особенно в случаях, когда о пароле хоть что-нибудь известно. К примеру, если вам удалось извлечь список других паролей пользователя из облака Google, iCloud или Microsoft Account или из браузера пользователя (например, Chrome, Microsoft Edge, Firefox и др.), возможно, выяснятся некоторые закономерности, согласно которым пользователь составляет пароли. К примеру, могут использоваться определённые наборы символов:

Elcomsoft Distributed Password Recovery предлагает многочисленные варианты атак по шаблонам (например, таким, по которым создаются пароли вида Password1, password1967 или pa$$w0rd):

Можно использовать маски:

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

Насколько быстро это работает?

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

При этом скорость перебора для разных дисков LUKS – величина переменная даже на одном и том же оборудовании. Скорость перебора зависит от множества факторов, основные из которых перечислены ниже.

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

Выбранная хэш-функция. При создании зашифрованного диска пользователь может выбрать хэш-функцию (или использовать хэш по умолчанию). Из доступных вариантов (RIPEMD160, SHA-1, SHA-256, SHA-512, WHIRLPOOL) самым быстрым является RIPEMD160, а самым медленным –WHIRLPOOL. Скорость атаки будет отличаться в зависимости от того, какой алгоритм хэширования выбран.

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

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

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

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

Заключение

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

Джейлбрейк checkra1n — уникальное явление в экосистеме Apple, эксплуатирующее аппаратную уязвимость в загрузчике ряда устройств. К сожалению, процесс установки джейлбрейка checkra1n не так прост и прямолинеен, что часто приводит к ошибкам. В то же время чёткое следование инструкциям позволяет добиться успеха почти в ста процентах случаев. О правилах и особенностях установки checkra1n мы поговорим в этой статье.

Для чего нужен checkra1n

Нужно ли устанавливать джейлбрейк в процессе извлечения данных? Ответ на этот вопрос зависит только от вас. Если известен код блокировки устройства, вам могут быть доступны другие варианты извлечения данных — от логического анализа до скачивания из облака (через сброс пароля к iCloud). В то же время работа через джейлбрейк позволяет извлечь полный образ файловой системы, включая рабочие базы данных различных защищённых программ мгновенного обмена сообщениями, которые практически никогда не попадают в резервные копии.

Даже если вы приняли решение об установке джейлбрейка, вовсе не обязательно пользоваться именно checkra1n. Для ряда устройств и версий iOS доступен альтернативный вариант — джейлбрейк unc0ver; ещё один джейлбрейк (Odyssey) на подходе.  Между этими вариантами есть существенная разница, о которой мы писали в англоязычной части нашего блога в статье checkra1n & unc0ver: How Would You Like to Jailbreak Today. Вкратце, основными преимуществами checkra1n является поддержка самых свежих версий iOS, которые не поддерживаются другими джейлбрейками, и возможность работы с «холодными» устрофствами в режиме BFU (Before First Unlock, или «до первой разблокировки») даже в тех случаях, когда код блокировки устройства неизвестен. Ещё одним немаловажным преимуществом checkra1n является то, что для его установки не нужно подписывать файл-установщик (IPA) через AltStore или с использованием учётной записи Apple для разработчиков.

Совместимость и интерфейс командной строки

checkr1n совместим с моделями iPhone от 5s до iPhone X включительно, многочисленными моделям iPad, а также Apple TV 4 (Apple TV HD) и Apple TV 4K. Поддержка версий iOS заявлена в промежутке от iOS 12.3 до 13.5.

В то же время разработчики предусмотрели возможность установки checkra1n и на тех версиях iOS, которые не поддерживаются официально. Для этого достаточно активировать режим “Allow untested versions”, как показано на скриншоте. Мы успешно опробовали checkra1n на устройствах с iOS 13.5.1 и 13.6. В то же время со старыми версиями iOS (12.3 и ниже) успеха мы не добились.

При установке checkra1n рекомендуем воспользоваться интерфейсом командной строки вместо режима GUI; по нашим наблюдениям, в режиме командной строки установка работает более надёжно. Важно отметить, что при работе с устройствами, которые находятся в режиме BFU с неизвестным кодом блокировки экрана и заблокированным портом USB, режим командной строки — единственный доступный.

Требования к компьютеру

В отличие от подавляющего большинства других джейлбрейков, checkra1n устанавливается только с компьютера под управлением macOS или Linux. Версии для Windows нет, однако существуют различные способы обхода этого ограничения — например, эмуляторы и загрузочные флеш-накопители. Если в вашем распоряжении только компьютер под управлением Windows, воспользуйтесь одним из решений Ra1nUSB, Bootrain или ra1nstorm.

Кроме того, существует вариант установки через Raspberry Pi, однако по информации от разработчиков он работает недостаточно стабильно (в особенности — на устройствах Raspberry Pi Zero и Raspberry Pi 3).

Таким образом, для установки checkra1n имеет смысл воспользоваться именно компьютером под управлением macOS. Мы не проверяли работу установщика на Big Sur, но в macOS Catalina он функционирует без проблем.

Требования к коннектору и кабелю

Основное правило: используйте сертифицированный кабель формата Lightning to USB Cable (с коннектором USB Type-A), но ни в коем случае не кабель с коннектором USB Type-C. О причинах пишут разработчики checkra1n:

Кабели Lightning с разъёмом USB-C проблематичны в использовании. В частности, некоторые из них не могут быть использованы для перехода в режим DFU, и мы ничего не можем с этим поделать. В число неработоспособных входят как собственные кабели USB-C от Apple, так и некоторые сторонние кабели. В то же время ряд сторонних кабелей оказался работоспособным, однако сказать заранее, какой кабель сработает, а какой — нет, не получается. Если конкретный кабель не работает, рекомендуем использовать кабель USB-A, при необходимости — в сочетании с адаптером USB-A-C.

Техническое объяснение:

BootROM перейдёт в режим DFU только в том случае, если обнаружит напряжение на разъёме USB. В свою очередь, определение напряжения на разъёме сводится к проверке того, установлен ли определённый вывод из чипа Tristar. Tristar делает это на основе «идентификатора аксессуара» кабеля. Очевидно, что кабели USB-A и USB-C имеют разные идентификаторы аксессуаров, а некоторые кабели USB-C заставляют Tristar не устанавливать вывод напряжения USB.

Наконец, воздержитесь от использования USB-хабов (вариант с переходником с USB-C на USB-A допустим).

Другие особенности

Одной из неочевидных особенностей при установке checkra1n является уровень заряда аккумулятора телефона. Убедитесь, что устройство не находится в режиме Low Power, а заряд аккумулятора заметно превышает 20%.

Ещё одна рекомендация от разработчиков checkra1n: при попытке установить checkra1n на несколько телефонов подряд, успешной будет только первая попытка. Обойти проблему можно, перезапустив checkra1n после каждой попытки.

Со своей стороны добавим, что, возможно, вам придётся перезапустить компьютер с macOS. Похоже, драйвер USB driver или какой-то другой компонент системы перестаёт нормально работать после попытки установить checkra1n; при этом самый простой способ восстановить работоспособность — перезагрузить компьютер, отключить iPhone, подключить его заново и снова ввести в режим DFU.

Если вам всё ещё не удаётся установить checkra1n, вы можете оформить запрос в checkra1n issue tracker, максимально подробно описав проблему и убедившись, что её решение не опубликовано ранее.

Ближайшее будущее

Заработает ли checkra1n с новыми версиями iOS, включая iOS 14? Для iOS 13.6 ответ положительный. Что же касается iOS 14, мы протестировали работу последней версии checkra1n (0.20.2) с iOS 14 beta 2 на ряде устройств от iPhone 6s до iPhone X, обнаружив, что на данный момент ни одна из протестированных конфигураций не поддерживается. В то же время, одному из наших партнёров удалось успешно установить checkra1n на одно из тестовых устройств.

Вероятно, checkra1n получится адаптировать для работы с будущими версиями iOS, но полной уверенности в этом нет. Apple работает над усилением безопасности экосистемы; по слухам, извлечение в режиме BFU на устройствах iPhone 7, iPhone 8 и iPhone X заметно ограничат или сделают невозможным (iPhone 6s в этот список не входит). В то же время, если код блокировки экрана вам известен, то установить checkra1n вы сможете, но только после того, как код блокировки будет с устройства удалён. Обратите внимание, что снятие кода блокировки приводит к ряду негативных последствий в том, что касается содержимого устройства и доступа к iCloud.

До недавнего времени черепичная запись Shingled Magnetic Recording (SMR) использовалась в недорогих моделях жёстких дисков Seagate, а также во всех моделях компании типоразмера 2.5”. Такие диски заслуженно получили репутацию медленных, с нестабильной скоростью записи и случайного доступа. Второй производитель жёстких дисков, Western Digital, долгое время оставался в стороне, продолжая выпускать накопители, использующие конвенционный способ записи CMR. Многие пользователи основывали свой выбор накопителя, исходя именно из этого критерия.

Недавние событие перевернуло привычные представления: в дисках Western Digital, предназначенных для работы в составе многодисковых сетевых хранилищ, обнаружилась «черепица», что приводило к отказам в работе RAID массивов. В этой статье мы подробно расскажем о том, что такое черепичная запись, в каких сценариях её использование допустимо, в чём состоят отличия между подходами WD и Seagate и к чему привело журналистское расследование.

Скандальная черепица

Не так давно в сети развернулся скандал: в дисках линейки WD Red, предназначенных для работы в составе сетевых хранилищ, обнаружились недокументированная особенность. Хронология событий такова.

2 апреля 2020

Пользователем Кристиан Франке (Christian Franke) было опубликовано исследование, в котором было рассказано об использовании недокументированной технологии SMR (черепичной записи Shingled Magnetic Recording) в некоторых дисках линейки WD Red. Кристиан описал, к каким именно проблемам это приводит в рамках массивов. Известные особенности технологии приводили к деградации массивов RAID в случаях, когда такие диски использовались совместно с «классическими» дисками (CMR, Conventional Magnetic Recording). Более того, восстановление таких массивов оказывалось невозможным из-за постоянных повторных выпаданий диска с SMR.

Задолго до этого пользователи задавались вопросом «не используется ли в данной модели технология SMR?» Представители Western Digital под разными предлогами отказывались разглашать используемую в дисках технологию. «Мы не разглашаем особенности внутреннего функционирования наших дисков конечным потребителям». Вот цитата ответа из техподдержки:

I understand your concern regarding the PMR and SMR specifications of your WD Red drive.

Please be informed that the information about the drive is whether use Perpendicular Magnetic Recording (PMR) or Shingled Magnetic Recording (SMR), is not something that we typically provide to our customers. I am sorry for the inconvenience caused to you.

What I can tell you that the most products shipping today are Conventional Recording (PMR). We began shipping SMR (Shingled Magnetic Recording) at the start of 2017. For more information please refer the link mentioned below.

Вот другой вариант ответа.

We have received your inquiry whether internal WD Red drive WD40EFAX would use SMR technology. I will do my best here to assist and please accept our sincere apologies for the late reply.

Please note that information on which of our drives use PMR or SMR is not public and is not something that we typically provide to our customers. What we can tell you is that most WD products shipping today are Conventional Recording (PMR) — please see additional information below. However, we began shipping SMR (Shingled Magnetic Recording) at the start of 2017.

(Источник)

В переводе: «Большое спасибо за обращение. Обращаем ваше внимание, что информация об использовании PMR и SMR не является публично доступной и не разглашается нашим клиентам. Однако могу сообщить, что большая часть поставляемых WD продуктов использует CMR; ниже – дополнительная информация. Тем не менее, в начале 2017 мы начали отгружать диски с SMR.»

Примерно такой ответ получил Кристиан Франке. Кристиан на этом не остановился, получив в результате такой ответ:

Just a quick note. The only SMR drive that Western Digital will have in production is our 20TB hard enterprise hard drives and even these will not be rolled out into the channel.

All of our current range of hard drives are based on CMR Conventional Magnetic Recording.

With SMR Western Digital would make it very clear as that format of hard drive requires a lot of technological tweaks in customer systems.

With regards

Yemi Elegunde
Enterprise & Channel Sales Manager UK
Western Digital®
WDC UK, a Western Digital company

В ответе утверждается, что единственный диск WD с SMR – это накопитель на 20 ТБ, предназначенный для крупных хранилищ данных. По утверждению представителя WD, все остальные диски компании использовали CMR.

Дальнейшие попытки добиться хоть какой-то внятной информации привели к предложению «обсудить проблему с инженерами и специалистами по жёстким дискам в телеконференции». Телеконференция, впрочем, не состоялась. Пользователи обратились к журналистам.

14 апреля 2020

Итак, Кристиан написал журналистам специализированного издания Blocks & Files. Журналисты разобрались в проблеме и выпустили статью:

Western Digital admits 2TB-6TB WD Red NAS drives use shingled magnetic recording

Как мы знаем, основной конкурент Western Digital – компания Seagate, — использует черепичную запись в накопителях линеек Archive и BarraCuda Compute уже много лет. Почему же именно в данном случае использование SMR стало проблемой?

В статье приводится несколько примеров. В частности, пользователи, которые заменяли вышедшие из строя диски WD Red 6TB WD60EFRX на новые модели WD60EFAX получали атипично длительное время перестроения массивов SHR1 и RAID5 (от 2 до 8 дней). У некоторых пользователей перестроение и вовсе завершалось с ошибкой: новый диск попросту исключался из массива как неисправный. Очевидно, что в ряде сценариев новые диски работают в разы хуже в сравнении с предыдущей моделью, а в некоторых случаях – не выполняют заявленную задачу вовсе. Обман потребителя в полный рост – но представители Western Digital отказывались как-либо комментировать ситуацию или просто признать сам факт использования новой технологии записи.

Именно в этот момент журналистам удалось впервые получить от Western Digital внятный ответ: «Актуальные модели WD Red 2TB-6TB компании Western Digital используют drive-managed SMR (DMSMR). Диски WD Red 8TB-14TB основаны на CMR. […] Вы правы в том, что мы не указываем технологию записи в документации на диски WD Red. […] При тестировании дисков WD Red мы не обнаружили проблем с перестроением RAID из-за технологии SMR».

В своё оправдание WD приводит следующий аргумент: «В типичной среде домашних NAS и NAS для малого бизнеса типичные нагрузки скачкообразны, оставляя достаточное время для сбора мусора и других сервисных операций». Журналисты из Blocks & Files возразили, что далеко не все нагрузки в рамках сетевых хранилищ «типичны» с точки зрения производителя. Скандал продолжал развиваться.

15 апреля 2020

Статья попала в точку: проблема назрела уже у большого количества пользователей. Поднявшаяся в сети волна публикаций и обсуждений побудила Blocks & Files продолжить расследование.

В статье Shingled hard drives have non-shingled zones for caching writes рассказывается о «ленточной» организации черепичного хранилища, как и о том, что у каждого SMR накопителя есть буфер, использующий классическую запись CMR. Здесь прямая аналогия с современными накопителями SSD: есть медленная TLC или даже QLC NAND, но часть её используется для буферизации записей в качестве псевдо-SLC кэша. Так и здесь: в жёстких дисках, использующих черепичную запись SMR, есть области CMR, использующиеся для ускорения записи. Таким образом у пользователя, который тестирует диск популярным пакетом CrystalDiskMark, возникает иллюзия нормальности: диск и читает, и пишет данные без каких-либо сюрпризов.

Неожиданность просиходит тогда, когда объём записанных данных превышает размер области CMR или весь диск был однажды заполнен данными, после чего накопителю приходится на лету «уплотнять» информацию. Такие ситуации в рамках NAS могут наступить как минимум в двух случаях: в случае перестроения массива класса RAID5 и подобных, в которых используются контрольные суммы, и в случае записи большого объёма данных (например, при создании и сохранении на диск обычной резервной копии). В таких сценариях видимая скорость записи падает в разы, а то и на один-два порядка. В моих собственных тестах скорость перезаписи заполненного накопителя периодически проседала до 1-10 МБ/с при записи единственного файла объёмом 1.5 ТБ (резервная копия системы). Я нахожу такую скорость неприемлемой.

В той же статье автор рассказал и о том, что происходит при попытке перестроения массива RAID5/6, если новый диск использует SMR. Огромное количество операций случайного ввода-вывода быстро приводит к переполнению буферной области CMR; контроллер не успевает справиться с нагрузкой, возвращая ошибку отказа в обслуживании. Спустя короткое время (порядка 40 минут) диск полностью уходит в себя, а контроллер RAID исключает его из массива, помечая как неисправный.

Что интересно, ничего подобного не происходит при использовании других типов массивов – RAID0/1, а также при создании нового массива RAID5/6. Создаётся впечатление, что разработчики Western Digital попросту не проверили новые диски в сценарии перестроения массива RAID5/6, ограничившись лишь самыми простейшими сценариями.

15 апреля 2020

В очередной статье Seagate ‘submarines’ SMR into 3 Barracuda drives and a Desktop HDD журналисты продолжили эксплуатировать тему SMR, рассказав, что подобной практикой занимается и компания Seagate.

Seagate давно использует SMR в своих накопителях на 2.5, архивных Archive и десктопных BarraСuda Compute. Об этом было известно давно, компания никогда не скрывала эту информацию. В то же время диски Seagate, предназначенные для работы в NAS (линейки Ironwolf и Ironwolf Pro) SMR не используют, что, собственно, и подтвердила компания в официальном пресс-релизе. Таким образом, скандала не получилось: покупатель, который хотя бы минимально интересуется состоянием дел, всегда имеет возможность понять, какой именно диск он покупает и для чего. Особенности черепичной записи SMR описаны Seagate в технической документации к соответствующим накопителям; о них мы ещё поговорим, пока же вернёмся к хронологии.

16 апреля 2020

На следующий день журналисты выяснили, что и в некоторых дисках Toshiba также используется SMR: Toshiba desktop disk drives have shingles too. Не уверен, что это кому-то интересно с учётом исчезающей доли накопителей Toshiba в типоразмере 3.5”. Впрочем, ознакомиться со списком моделей дисков Toshiba, в которых используется SMR, в любом случае не помешает. На сегодняшний день это 3.5” диски Toshiba P300 Desktop PC и DT02 объёмом 4 и 6 ТБ, а также все без исключения 2.5” модели поколения MQ04.

20 апреля 2020

В Western Digital определённо забеспокоились. В статье SMR in disk drives: PC vendors also need to be transparent опубликован официальный ответ Western Digital, в котором компания уверяет, что никаких проблем у дисков на самом деле нет, если их правильно использовать. Более свежую версию ответа можно прочесть в блоге Western Digital. Из текста можно сделать вывод, что перестроение массивов RAID5/6 для дисков серии WD Red – неправильное использование и нецелевое, а понятия NAS и RAID – понятия хоть и близкие, но не эквивалентные. Если пользователь желает использовать диск для NAS в составе массива RAID5/6, то стоит купить модель подороже – например, из линейки Ultrastar DC, WD Gold или WD Red Pro. Именно так и написано, буквально: «If you are encountering performance that is not what you expected, please consider our products designed for intensive workloads. These may include our WD Red Pro or WD Gold drives, or perhaps an Ultrastar drive.» Не буду цитировать целиком этот шедевр работы департамента Western Digital по связи с общественностью, с ним можно ознакомиться по ссылке выше.

21 апреля 2020

Разумеется, основной конкурент, компания Seagate, не смог не прокомментировать ситуацию. В статье Seagate says Network Attached Storage and SMR don’t mix представитель компании подчёркивает, что Seagate никогда не использовал черепичную запись в дисках Ironwolf и Ironwolf Pro, предназначенных для NAS, и не рекомендует использовать диски с SMR в сетевых хранилищах.

23 апреля 2020

Журналисты не смогли пройти мимо постинга WD. В статье Western Digital implies WD Red NAS SMR drive users are responsible for overuse problems задаются вполне резонные вопросы: а как, собственно, пользователь может – даже в теории! – узнать о потенциальных проблемах, если WD хранила сам факт использования SMR в NAS-накопителях в секрете, отказываясь даже честно ответить на прямо заданный вопрос? И если уж пользователей обвинили в  «нецелевом» использовании дисков, то определите формально «целевые» и «нецелевые» сценарии для каждой модели и линейки моделей. В старом WD60EFRX перестроение RAID5/6 было «целевым» сценарием, а в новой WD60EFAX стало «нецелевым». С этим можно работать, но… Но клиентам об этом сообщить забыли, а на заданные вопросы отвечать отказались. Прямо скажем, игра на грани фола – что и привело впоследствии к подаче коллективного судебного иска.

24 апреля 2020

В Western Digital сдались: компания опубликовала полный список накопителей в форм-факторе 3.5”, в которых используется SMR.

Технология черепичной записи остаётся в накопителях WD Red, предназначенных для NAS, но производитель после беспрецедентного давления общественности нехотя и с оговорками согласился больше не делать из этого секрета. Теперь пользователь может сделать информированный выбор: покупать «старую» модель WD Red без SMR или «новую» — с SMR. Или уйти к конкуренту, который не использует SMR в накопителях для NAS вовсе. Или взять наполненный гелием диск объёмом от 8 ТБ.

23 июня 2020

Не прошло и двух месяцев, как компания «решила проблему», и выходит очередная новость: модельный ряд накопителей WD Red расширен линейкой WD Red Plus, в которой используется конвенционный способ записи CMR. Теперь серия накопителей WD Red включает в себя стандартную версию WD Red (в ней будет использоваться черепичная запись SMR), WD Red Plus (классический способ записи CMR) и оставшуюся без изменений WD Red Pro.

В версию WD Plus вошли жёсткие диски объёмом от 2 до 6 ТБ, в которых, как и до журналистского расследования, будет использоваться классическая запись CMR. В наименованиях новых дисков также появилось отличие — вместо предпоследней буквы «A» (модели WDxxEFAX) теперь ставится «R» (WDxxEFRX), что позволяет отличить диски с CMR от моделей с SMR.

Всё бы неплохо, но «новая» модель WD Red Plus с идентификатором WD60EFRX с точностью до надписей на этикетках совпадает со «старой», снятой с производства моделью WD Red WD60EFRX. Только теперь «новая» модель носит гордое название Plus, а продаётся дороже снятой было с производства «старой». За такой способ решения собственноручно созданной проблемы компания уже подверглась массивной критике.

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

Реализация SMR у Seagate: привычное зло

Проще всего дела обстоят у Seagate. Покупая недорогой диск от Seagate, пользователь, скорее всего, получит модель с черепичной записью. На сегодняшний день дела в стане Seagate обстоят следующим образом.

Линейки Seagate Archive и BarraCuda Compute: как правило, поставляются с SMR. Именно такие диски устанавливаются во внешние накопители линеек Expansion Desktop и Backup Plus Hub ёмкостью до 8 ТБ включительно.

Линейка BarraCuda Pro обходится без SMR. Кстати, все диски Seagate объёмом от 10 ТБ также используют обычный способ записи CMR; это объясняет заметную разницу в цене между моделями внешних накопителей Seagate на 8 и 10 ТБ.

Во всех дисках для NAS линеек IronWolf и IronWolf Pro используется честная перпендикулярная запись (CMR).

Что такое черепичная запись? Подробная иллюстрированная статья выложена на сайте Seagate — очень рекомендую ознакомиться.

При черепичном способе записи дорожки записываются на диск не параллельно, а с перехлёстом, как черепицы на крыше, что позволяет дополнительно уплотнить запись. Использование черепичного способа записи позволяет производителям сэкономить на производстве, сделать диск менее шумным и менее тяжёлым за счёт меньшего количества вращающихся «блинов» и головок чтения-записи.

А что насчёт надёжности дисков с SMR? Когда технология только появилась на рынке, у пользователей были большие сомнения относительно долговременной надёжности таких дисков. На сегодняшний день можно констатировать, что надёжность дисков с SMR при обычном использовании в качестве архивных накопителей не хуже надёжности дисков с CMR аналогичной ёмкости, а в отдельных случаях может даже превышать её за счёт упрощения механической части.

Неприятная особенность реализации SMR у Seagate в том, что диски выдерживают хорошую скорость записи на протяжении лишь первого цикла заполнения диска. Но стоит пользователю заполнить диск целиком и начать перезаписывать данные (сценарий, совершенно типичный для регулярных резервных копий), как скорость перезаписи падает в разы в сравнении с записью на свежий диск. Ситуация чем-то напоминает ту, в которой оказались производители первых твердотельных накопителей SSD: запись в блок происходит быстро, а для перезаписи единственного байта требуется считать целый (и довольно крупный) блок данных, модифицировать нужные данные и сохранить изменённую информацию. Так и здесь: для перезаписи единственной дорожки нужно сначала считать все последующие дорожки, которые входят в объединённый блок (ленту), после чего записать нужную дорожку и восстановить из буфера все последующие.

Вот что имеет на эту тему сказать производитель Seagate:

C технологией SMR связана следующая проблема: если нужно перезаписать либо обновить часть информации, переписать придётся не только требуемый фрагмент, но и данные на последующих дорожках. Поскольку записывающий элемент шире неперекрывающейся области дорожки, он захватывает также данные на граничащих дорожках, а значит, потом придётся перезаписать и их (рис. 3). Таким образом, при изменении данных на нижней дорожке, нужно скорректировать данные на ближайшей наложенной дорожке, потом на следующей, и так далее, пока не будет переписана вся пластина.

Рис. 3. Записывающий элемент перекрывает накладывающиеся дорожки

По этой причине дорожки SMR-диска объединены в небольшие группы, называемые лентами. Накладываются друг на друга, соответственно, только дорожки в пределах одной ленты (рис. 4). Благодаря такому группированию в случае обновления некоторых данных перезаписывать придется не всю пластину, а лишь ограниченное количество дорожек, что существенно упрощает и ускоряет процесс.

Рис. 4. Структура ленты на SMR-диске

(источник)

Такая организация приводит к тому, что скорость перезаписи данных падает с условных 180 МБ/с до 40-50 МБ/с. Обойти проблему можно попытаться, включив для диска кеширование записи и осуществляя запись крупными блоками, размер которых не меньше размера одной ленты. Так, тестовый образец LaCie 2.5″ 4TB демонстрировал скорость записи на чистый накопитель порядка 130 МБ/с. После первого заполнения диска скорость записи данных упала до 20-40 МБ/с; что характерно, не помогло ни форматирование диска, ни переразбивка на разделы. Ещё хуже себя показал вариант ёмкостью 5 ТБ, скорость перезаписи данных которого упала ниже 10 МБ/с. Частично исправить ситуацию помогло включение кеширования записи и запись данных крупными блоками; впрочем, даже так первоначальная высокая скорость записи не восстановилась.

Проиллюстрирую работу SMR в момент перезаписи данных. Увидеть подобные цифры получится лишь после того, как весь объём диска был заполнен хотя бы единожды, а объём записываемых в течение одной сессии данных превышает размер буфера CMR (при этом очистка или переформатирование диска никак не повлияют на производительность). На первом скриншоте — запись с отключённым кэшированием записи. Скорость записи периодически проседает от 1 до 10 МБ/с. Эта скорость обнажает внутреннюю суть процесса. В процессе записи контроллер считывает ленту (блок черепичных дорожек) в буфер; модифицирует одну дорожку; записывает всю ленту из буфера на диск. Следующая дорожка — повторение цикла. В результате имеем процесс, который на Reddit описали так: «Многие говорят, что SMR — это медленно, но мало кто представляет, насколько медленно это на самом деле. Представьте, что вам нужно пропихнуть слона через замочную скважину. Представили? А теперь представьте, что с другой стороны активно сопротивляются. Вот это и будет запись SMR.»

Скорость перезаписи с отключённым кэшем на запись.

На втором скриншоте — то же самое, но с включённым кэшированием записи. Теперь в буфер накопителя попадает не дорожка, а вся лента целиком (точнее, может попадать — фактического размера ленты и того, как он соотносится с размером буфера накопителя, мы не знаем). Если бы контроллер накопителя был чуточку умнее (или хотя бы поддерживал инструкцию trim, как в WD), то он понял бы, что нужно перезаписать всю ленту целиком — и сделал бы именно это. Но — нет; контроллер раз за разом считывает ленту в буфер, модифицирует данные и записывает их обратно. Скорость записи в результате варьируется от нулевой до максимальной (около 100 МБ/с в этой части диска).

Скорость перезаписи с включённым кэшем на запись.

На скриншотах хорошо видна одна из проблем накопителей с SMR: чрезвычайно медленная перезапись больших массивов данных. Учитывая, что такие диски (на скриншоте – модель Seagate Backup Plus 5TB) часто продаются для хранения резервных копий, размер которых может достигать от сотен гигабайт до нескольких терабайт, такая производительность на основной (и, по сути, единственной) задаче устройства – совершенно неприемлема.

А что насчёт скорости чтения? Хорошо известная проблема SMR – низкая скорость позиционирования головок, связанная с высокой плотностью расположения дорожек. Соответственно, случайный доступ к данным, в отличие от последовательного, при прочих равных условиях в моделях с SMR будет ниже, чем в дисках без «черепицы». Но на этом проблемы не заканчиваются. В дисках с SMR без trim так же, как и в накопителях SSD, используется механизм трансляции адресов. Диск старается записать новую порцию данных сначала в CMR буфер, а когда он заполнен — в первую свободную ленту. Соответственно, происходит трансляция логических адресов в физические; при этом возникает внутренняя фрагментация данных. И если для SSD внутренняя фрагментация не играет никакой роли, то в случае с механическими дисками мы получаем двойной удар: файлы «размазываются» по незанятым лентам, и при этом скорость случайного доступа низкая из-за увеличенных требований к точности позиционирования головки. В результате при неудачном стечении обстоятельств мы получаем диск, чтение данных с которого превращается в пресловутое проталкивание слона через замочную скважину.

Впрочем, модель модели рознь. В упомянутом выше внешнем накопителе используется диск Seagate BarraCuda 5TB (ST5000LM000), которая была одной из первых 2.5” моделей с SMR. Реализация черепичной записи в нём сырая, чем-то напоминает поведение самых первых SSD, которые теряли в скорости записи сразу после первого заполнения. Моё мнение: в таком виде накопитель нельзя было выпускать на рынок.

А в каком – можно? Можно ли сделать так, чтобы дисками с SMR можно было пользоваться, не испытывая заметных неудобств? Оказывается, даже в рамках технологии SMR можно создавать вполне неплохие диски (разумеется, со своими ограничениями и узким спектром сценариев использования), если правильно сделать программную часть – прошивку контроллера. И получилось это сделать впервые не у Seagate, пионера технологии, а у основного конкурента – компании Western Digital, героя этой статьи.

Реализация SMR от WD: команда trim, как в SSD

На сегодняшний день между реализацией SMR от Seagate и Western Digital есть одно, но очень важное отличие: поддержка накопителями WD команды trim. Использование этой команды меняет если не всё, то многое. Но позволяет ли поддержка trim говорить о том, что накопители с SMR можно использовать в рамках RAID массивов? Разберёмся детально.

Первые опыты Western Digital в отношении SMR были сугубо секретными: компания до сих пор не призналась, использовалась ли эта технология в модели WD My Passport объёмом 4 ТБ. Большинство пользователей склоняется к тому, что использовалась: невысокая скорость случайной записи и низкая надёжность модели привели к закономерным подозрениям. Впрочем, уверенности в этом до сих пор нет ни у кого, даже у технически подкованных специалистов. Об использовании SMR в этой модели упоминается вскользь как о вероятности. Что интересно, в этой модели параметры S.M.A.R.T. декларируют поддержку функции trim, но фактически её активировать не удаётся. А вот в новой модели WD My Passport 5TB (а также WD_Black 5TB) функция trim и декларируется, и поддерживается фактически.

Благодаря поддержке trim последовательная запись большого массива данных всегда осуществляется так, как будто данные сохраняются на свежий накопитель. Вот как выглядит график производительности диска WD My Passport 5TB (с поддержкой trim):

Источник

А вот так – график производительности аналогичного диска Seagate (поддержки trim нет):

Как видим, у диска Seagate первые 10 минут идёт запись в буфер CMR, после чего начинается бесконечный цикл уплотнения-перезаписи, из-за которого скорость записи то падает до 10 МБ/с, то восстанавливается до максимальной, то снова падает. Накопитель от Western Digital подобного поведения не демонстрировал.

Как проверить, поддерживает ли данный конкретный диск команду trim? С одной стороны, можно посмотреть показания S.M.A.R.T. С другой – у меня есть несколько дисков, в параметрах которых поддержка trim заявлена, но по факту отсутствует (вероятно, это особенности использованных производителем USB контроллеров). Проверить же можно, запустив PowerShell с административными привилегиями и выполнив команду

Optimize-Volume -DriveLetter X: -Retrim

Если процесс оптимизации успешно начнётся, то система выполняет тримминг накопителя. Если же выдаст ошибку – значит, функция trim не поддерживается (кстати, она не поддерживается при использовании любой файловой системы, кроме NTFS).

Казалось бы, при чём здесь trim – команда, традиционно использующаяся в твердотельных накопителей для упрощения сборки мусора?

В статье TRIM Command Support for WD External Drives даётся подробный ответ. Согласно этой статье, функция trim используется для оптимизации сборки мусора на дисках WD, использующих черепичный способ записи.

TRIM / UNMAP поддерживается для внешних (и внутренних тоже – ОА) жестких дисков с технологией записи SMR (Shingled Magnetic Recording) для управления таблиц соответствия адресов и повышения производительности SMR с течением времени. Одним из преимуществ (там так и написано – ОА) черепичной записи является то, что все физические сектора записываются последовательно в радиальном направлении и перезаписываются только после циклического переноса. Перезапись ранее записанного LBA (адресация логического блока) приведет к тому, что предыдущая запись будет помечена как недействительная, и LBA будет записана в следующий последовательный физический сектор. TRIM/UNMAP позволяет ОС информировать накопитель о том, какие блоки более не используются и могут быть вновь использованы жестким диском для выполнения последующих операций записи на полной скорости.

Что это означает на практике? Если использовать такой диск в Windows 10 (и диск отформатирован в NTFS), то скорость записи больших массивов данных будет оставаться высокой независимо от числа перезаписей. Система автоматически сообщит контроллеру об освобождении адресов, которые более не используются. Соответственно, скорость записи будет восстанавливаться автоматически после удаления файла или форматирования диска – это то, чего катастрофически не хватает накопителям от Seagate.

Если речь идёт о диске формата 3.5”, то некоторые NAS (например, производства Synology) также определят его как накопитель, поддерживающий trim. Работу trim можно настроить по расписанию.

Пусть вас не введёт в заблуждение название пункта “SSD trim”: в накопителе установлен механический жёсткий диск на 6 ТБ – как раз из новой серии WD с черепичной записью. Впрочем, у этого метода есть и ряд ограничений; в частности, trim не работает в массивах RAID5/6. Аналогичные ограничения есть и у других NAS.

Что приводит нас к очевидному выводу: даже поддержка накопителями команды trim не делает новые диски Western Digital с черепичной записью SMR пригодными для использования в составе массивов RAID 5 и RAID 6 (а также, по опыту пользователей, в составе ZFS и массивов SHR 1 и, возможно, SHR 2). В составе таких массивов непрерывная череда мелкоблочных операций записи быстро (в течение 40 минут) перенасытит контроллер и переполнит ограниченный буфер CMR.

Нельзя и использовать диск с SMR совместно с классическими в рамках одного массива: в зависимости от нагрузки, диск с SMR может замедлить работу всего массива и даже привести к его деградации, если контроллеру покажется, что диск слишком долго не отвечает.

С другой стороны, новые диски WD с черепичной записью вполне допустимо использовать в однодисковых NAS, а также в составе массивов уровней JBOD, RAID 1 или RAID 0 в многодисковых сетевых накопителях, причём последние два (RAID1/0) при условии, что все диски в составе массива используют одинаковую технологию записи (только CMR или только SMR).

И, разумеется, диски WD с черепичной записью отлично работают в качестве архивных. Правда, до тех пор, пока их используют совместно с Windows, а сам накопитель отформатирован в NTFS. Использование таких дисков в macOS способно преподнести неприятные сюрпризы в силу особенностей реализации trim в ОС от Apple.

При этом использование диска SMR с поддержкой команды trim предпочтительнее аналогичного диска без поддержки trim – обширный список, в который входят практически все «домашние» накопители Seagate.

Стоит ли покупать диски с SMR

Разница в цене между наполненным гелием накопителем WD My Book или WD Elements Desktop 8TB, использующими классическую запись CMR, и черепичными Seagate Backup Plus Hub или Seagate Expansion Desktop 8TB на сегодня порядка 10-15 евро. Разница в цене между WD Red 6TB с PMR (модель WD60EFRX) и SMR (WD60EFAX) – исторически те же 10 евро, но на фоне последних публикаций ценник на классическую модель резко и необоснованно взлетел, догнав ценник на 8-гигабайтный накопитель.

Стоит ли переплатить за отсутствие SMR и всегда ли это возможно? В некоторых компактных (2.5”) накопителях ёмкостью от 2 ТБ используют SMR для того, чтобы получить более тонкий корпус. В компактных дисках ёмкостью в 5 ТБ запись SMR используют просто для того, чтобы сделать такую ёмкость возможной. А вот десктопные диски ёмкостью 2, 4, 6 и 8 ТБ вполне можно выпустить и без SMR. Использование черепичной записи позволяет производителю сэкономить; часть этой экономии достаётся на долю покупателя, но большую часть денег производитель кладёт в собственный карман.

Решение о покупке того или иного диска принимать в любом случае пользователю. Есть сценарии использования, в которых использование SMR недопустимо в принципе – это массивы RAID 5 и 6 уровней. Использовать SMR в составе массивов RAID 0 и RAID 1 принципиально допустимо, но при соблюдении простого правила – использовать в рамках массива только диски без или только с SMR. В однодисковом NAS, который умеет использовать trim, пользователь не заметит большой разницы между диском с PMR и диском SMR, поддерживающим команду trim. Наконец, диски с SMR и trim вполне допустимо использовать в качестве архивных.

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

Заключение

В этой статье мы подробно рассмотрели как саму черепичную технологию записи SMR, так и особенности её реализации двумя крупнейшими представителями индустрии – компаниями Seagate и Western Digital. Является ли SMR абсолютным злом? Нет, не является – если покупатель понимает, какие проблемы и ограничения он приобретает за свои деньги, и получает за это достаточную скидку. Но делать это нужно с открытыми глазами, а сознательно скрывать информацию – совершенно недопустимо.

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

Synology

Компания Synology выпускает самые популярные сетевые хранилища, которые можно купить в виде отдельного устройства. Последнее – важное дополнение, так как абсолютным лидером по числу проданных «домашних» NAS является компания Western Digital со своими однодисковыми и двухдисковыми моделями WD My Cloud, My Cloud Mirror, My Cloud Home и My Cloud Home Duo. Такой популярности Western Digital удалось добиться за счёт чрезвычайно низкой цены: NAS с диском WD зачастую стоит дешевле, чем диск отдельно.

Synology не может себе позволить такой щедрости; сетевые хранилища этого производителя продаются за ощутимые деньги – пользуясь при этом неизменной популярностью. Но и у Synology не обошлось без ложки дёгтя.

Бесполезная агрегация

Двумя и более сетевыми портами оборудуются лишь самые продвинутые (и достаточно дорогие) модели NAS от Synology. Однако использовать лишний порт для того, чтобы удвоить полосу пропускания, у обычного пользователя не получится. Для того, чтобы разобраться в причинах, нужно немного рассказать о том, как работает агрегация сетевых линков в принципе.

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

Единственное исключение из этого правила – агрегация на программном уровне по алгоритму Round Robin. При использовании этого алгоритма достигается именно тот эффект, которого ожидает обычный домашний пользователь: скорость передачи данных между NAS и любым другим устройством (разумеется, также использующим скоростной линк) будет складываться из суммарной пропускной способности всех агрегированных линков. Таким образом, включение второго порта Ethernet большинством производителей – это способ удвоить видимую пользователю скорость работы NAS, вплотную приблизив скорость обмена данными по сети к скорости самих дисков.

Почему я назвал агрегацию линков в Synology «бесполезной»? По какой-то причине разработчики компании удалили возможность использования алгоритма Round Robin. Все другие алгоритмы, которые поддерживаются в DSM, не позволяют удвоить скорость передачи данных между NAS и единственным клиентом. К сожалению, подавляющее большинство пользователей не знает (форум) об этой особенности – пока не попробует воспользоваться режимом агрегации.

Со списком поддерживаемых DSM алгоритмов агрегации можно ознакомиться на скриншоте.

Для сравнения, большинство даже недорогих моделей (начиная с середины линейки) Asustor и Qnap оснащаются двумя сетевыми интерфейсами, которые можно объединить методом Round Robin и получить удвоенную полосу пропускания.

Вот как выглядит настройка агрегации линков в NAS Asustor:

Результат налицо: скорость чтения-записи практически сравнялась со скоростью доступа к самим дискам.

Недорогие модели чрезмерно ограничены

Программисты Synology славятся способностью заставить мощный и красивый графический интерфейс работать быстро и исключительно отзывчиво даже на самом слабом железе. Тем не менее, использование двухъядерных процессоров архитектуры Cortex A7 (приблизительно уровень дешёвых смартфонов 2012 года) в моделях начального уровня оправдать получается с трудом.

В бюджетных двухдисковых моделях (линейка DS216j, DS218j и недавно выпущенная DS220j) применяется разборный пластиковый корпус без полноценного металлического каркаса. Данная конструкция не способна обеспечить звукоизоляцию дисков. Особенно плохо обстоят дела с дисками на 7200 оборотов в минуту, а это – все модели WD Red начиная с 8ТБ и выше. (В скобках: производитель указывает класс производительности этих моделей как “5400 RPM Class”, что не эквивалентно скорости в “5400 RPM”. Замеренная скорость вращения шпинделя в WD Red 8TB и выше – 7200 RPM, хоть в параметрах S.M.A.R.T. и указано другое). Так, попытка собрать бесшумное домашнее сетевое хранилище с двумя дисками WD Red 8TB окончилась провалом: корпус NAS резонировал, усиливая вибрацию дисков, создавая мерный неприятный гул. Диски пришлось переставить в стоявший рядом Asustor AS5202T, в котором те же самые диски вдруг оказались совершенно бесшумными.

Сравнивая модели NAS от Synology с конкурентами аналогичной ценовой категории, основанными на тех же процессорах, можно заметить, что в моделях Synology меньше количество и разнообразие портов (как правило, отсутствует выход HDMI, один сетевой интерфейс вместо двух, нет портов Type-C). При этом благодаря прекрасно оптимизированной прошивке DSM работают модели Synology ничуть не хуже конкурентов, часто обгоняя даже более мощные решения.

Отсутствие ключевых возможностей

Какие именно возможности являются ключевыми – каждый пользователь решает для себя сам. Для кого-то это поддержка Plex, кто-то собирается использовать NAS в качестве видеоплеера – ему нужен Kodi и поддержка инфракрасного пульта ДУ; для кого-то важнее тишина и низкое энергопотребление. Прошивка DSM, под управлением которой работают NAS от Synology, предлагает простое и беспроблемное решение – но в достаточно узких рамках.

QNAP

Сетевые хранилища QNAP – на втором месте по популярности после Synology. Как правило, за сравнимую стоимость покупателю предлагается чуть более мощное железо с большим количеством интерфейсов и таких элементов, как съёмные лотки для дисков. В то же время программное обеспечение QNAP является одним из самых сырых, тяжёлых и плохо оптимизированных среди исследуемой троицы производителей. И если к аппаратной части NAS от QNAP претензии возникают нечасто, то о прошивках можно и нужно поговорить.

Ненадёжные модули с прошивкой

В устройствах Synology операционная система хранится непосредственно на жёстких дисках (нужно отметить – всех инициализированных жёстких дисках, что позволяет устройству корректно работать, даже если останется работоспособным единственный – любой – накопитель). В моделях QNAP операционная система QTS хранится в интегрированном твердотельном хранилище – модуле DOM. Такой способ хранения операционной системы имеет как свои преимущества, так и недостатки, основным из которых является отказ системы в случае повреждения DOM. Обозреватели не успевают столкнуться с этой проблемой, но стоит запустить поиск в Google – и всё становится на свои места: замена бракованных модулей и перепрошивка повреждённых занимают несколько страниц выдачи по запросу QNAP DOM. Ничего подобного у других производителей не наблюдается.

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

Лично мне не довелось столкнуться с отказом модуля DOM, но перепрошить его однажды пришлось: обновления QTS отказывались устанавливаться из-за несовпадения контрольных сумм, причём произошло это прямо при настройке устройства «из коробки».

Медленная загрузка

Операционная система в QNAP хранится в виде образа в распаянном твердотельном хранилище DOM. В процессе загрузки система считывает этот образ в оперативную память, распаковывает его и загружает операционную систему. К сожалению, процесс загрузки не оптимизирован настолько, что младшие модели могут загружаться 5-6 минут, а старшие – 3-4 минуты.

Для сравнения, аналогичные модели Synology и Asustor (который, кстати, тоже хранит прошивку в твердотельном хранилище) загружаются за полторы минуты, а собранный мной NAS под управлением Debian с Openmediavault на обычном четырёхъядерном процессоре с архитектурой ARMv8 загружается за 30 секунд, 14 из которых уходит на включение и раскрутку пластин жёсткого диска.

Режим сна S3 sleep mode: был и не стало

С медленной загрузкой можно было бы смириться, если бы в устройстве можно было активировать режим глубокого сна S3 sleep mode. К сожалению, в новых устройствах QNAP разработчики убрали эту возможность, а в тех, в которых она была, её отключают в новых версиях прошивки. Причина? «Проблемы с безопасностью». Какие именно? «Оно работает нестабильно». Почему нестабильно? Потому что программисты компании не обладают достаточной квалификацией, чтобы обеспечить стабильный режим глубокого сна в собственной ОС на собственном железе.

В чём выражается эта нестабильность? Я протестировал работу этой функции на двух устройствах: QNAP TS-131P и QNAP TS-453BE. В обоих случаях режим глубокого сна активируется командой:

echo mem > /sys/power/state

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

Для сравнения, аналогичная функция в устройствах Asustor поддерживается официально и работает весьма стабильно. А вот в NAS от Synology режим глубокого сна присутствует лишь в считанных (очень старых) моделях.

Нет расписания задач

Возможность выполнять задачи по расписанию – одна из ключевых особенностей сетевых хранилищ. В Synology по расписанию можно создавать резервные копии, выполнять сборку мусора (trim) твердотельных накопителей и дисков с SMR, да и вообще – создавать любые мыслимые задачи, которые будут запускаться хоть по расписанию, хоть сразу после запуска. Это выглядит так:

Synology: запуск пользовательского скрипта сразу после загрузки.

В QTS нет ничего подобного. Это не означает, что пользователь не может создавать резервные копии по расписанию – может, если этот режим поддерживает само приложение. Но, к примеру, разбудить сетевое устройство командой WOL, после чего создать на нём резервную копию и отключить его скриптом SSH – не получится без использования терминала и умения настроить cron. А в Synology – получится. Похоже, разработчикам было настолько лень делать диспетчер задач, что они создали подробную статью о том, как пользователю самому настроить crontab через командную строку.

Неотключаемые звуковые сигналы

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

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

Разработчики QNAP не смогли преодолеть сорочий инстинкт, запретив отключение звукового сигнала в процессе загрузки. Автоматическое пробуждение хранилища ночью разбудит и пользователя.

Навязчивый пользовательский интерфейс

Операционная система QTS предлагает развитый, многооконный пользовательский интерфейс – который, однако, не оставляет пользователя в покое. В магазине приложений присутствует анимированная реклама, но больше всего раздражают другие мелочи. Так, каждый раз при открытии списка уведомлений Event Notifications пользователю будут настойчиво предлагать включить… расширенные уведомления в Notification Center: отправкой SMS, письма или push-уведомления на мобильное устройство. Но даже если вы согласитесь с системой и активируете расширенные уведомления, просто чтобы избавиться от назойливого предложения, блок с предложением настроить Notification Center никуда не денется.

Мелочь? Недовольных пользователей множество (форум), реакция представителей компании – «это для вашего же блага».

Сомнительные приложения

Из той же оперы – приложение SSD Profiler, которым также многие недовольны. Разработчики QNAP решили собрать статистику надёжности SSD и то, как на неё влияют показания мониторинга S.M.A.R.T. Проблема с этим приложением в том, что оно устанавливается в систему по умолчанию; удалить его нельзя (по крайней мере, такова была ситуация на тот момент, когда я тестировал NAS от QNAP). Приложение отправляет производителю телеметрию независимо от того, хочет того пользователь или нет. Лишь спустя год в момент, случайно совпавший с принятием в Европе закона о защите персональной информации GDPR, разработчики QNAP изменили политику: теперь пользователям предлагается поделиться телеметрией добровольно, взамен обещается несколько месяцев подписки на сервис предсказания надёжности накопителей, который появится когда-нибудь в будущем. Предложение хоть и сомнительное, но честное – почему бы не сделать так с самого начала?

Сомнительная безопасность прошивки

У всех производителей находят уязвимости. Уязвимости находили в сетевых хранилищах Western Digital, Synology, Asustor и QNAP. Однако лишь в случаях с Western Digital и QNAP проблема получила характер массовой эпидемии – в основном благодаря тому, что эти производители не торопились с выпуском патча безопасности.

Не останавливается вентилятор

Выбирая домашнее сетевое хранилище, пользователи редко обращают внимание на то, как именно оно будет функционировать 99% времени – находясь в простое. Не акцентируют на этом внимание и производители. Тем не менее, в ряде моделей Synology предусмотрен режим Low power mode, в котором вентилятор будет останавливаться, когда останавливаются диски. NAS без движущихся частей – очень тихий NAS, идеальный для домашнего использования. К сожалению, QNAP не выпускает ни одной модели хранилищ, вентилятор которых останавливался бы при комнатной температуре даже во время гибернации жёстких дисков.

Другие проблемы

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

Asustor

Устройства Asustor и Nimbustor, выпускаемые подразделением компании ASUS, как правило, снабжены лучшей по сравнению с устройствами Synology аналогичной стоимости аппаратной базой. К примеру, в большинстве двухдисковых моделей Synology присутствует лишь один сетевой порт RJ45; большинство же моделей Asustor аналогичного класса оснащаются двумя сетевыми портами, что позволяет удвоить скорость обмена данными с компьютером и другими устройствами. Тем не менее, у устройств Asustor и операционной системы ADM есть свои особенности, от некоторых из которых впору схватиться за голову.

Контроль температуры, скорость вращения вентилятора и уровень шума

Одна из самых известных и, можно сказать, любимых проблем ADM – странный подход к регулированию скорости вентилятора. Вот, например, как это сделано в Synology DSM (правильный подход):

А вот – в Asustor ADM:

В целом похоже? Да, но нет. В Synology пользователь выбирает не скорость вращения вентилятора, а алгоритм, регулирующий его скорость в зависимости от внутренней температуры устройства. За счёт того, что даже в двухдисковых устройствах инженеры Synology сумели встроить вентилятор размером 92мм, диски всегда остаются холодными, а уровень шума – низким.

В двухдисковых моделях Asustor (как и прочие производители) устанавливает небольшие высокооборотистые вентиляторы размером 70мм.

При выборе автоматической регулировки скорости вращения вентилятора обороты последнего фиксируются на 750 RPM и держатся на этом уровне, пока диски не разогреются до +53С. 53 градуса – это очень высокая температура, длительная работа при которой негативно сказывается на надёжности накопителей.

Казалось бы, можно выбрать другой алгоритм, и вентилятор будет вращаться чуть быстрее? Нет. Выбрать можно между автоматической регулировкой, режимом Low (обороты фиксируются на 750 RPM), Medium (обороты фиксируются на 2600 RPM) и High (полная скорость, 4300 RPM).

И если на низких оборотах вентилятор не слышно уже на расстоянии метра, но режим Medium – это очень, очень громко: шум прекрасно слышно из соседней комнаты через закрытую дверь. Про режим High говорить не буду, шум вентилятора в нём сравним со звуком взлетающего самолёта. Работа же автоматического режима не просто неудовлетворительна; она просто опасна для дисков:

Это – одна из тех вещей, исправить которые для разработчиков не составляет никакого труда. Тем не менее, проблема известна как минимум с 2014 года, и в течение многих лет всё, что делают представители компании – это объясняют, что «так задумано». Каким-либо логическим образом объяснить эту, выразимся прямо, узколобость мышления тайваньских программистов у меня не получается.

Справедливости ради, в четырёхдисковых моделях Asustor устанавливаются значительно менее шумные вентиляторы размером 120мм. Впрочем, алгоритмы управления ими не отличаются от таковых в двухдисковых моделях.

Ещё о шуме вентилятора

Большинство моделей Asustor может переходить в режим глубокого сна – S3 sleep mode. В этом режиме минимизируется энергопотребление устройства, останавливаются диски, выключается вентилятор, останавливаются все процессы и исчезает вероятность того, что случайный процесс неожиданно разбудит устройство и приведёт к раскрутке дисков. Режим практически идеальный для домашнего использования, но смущает мелочь: в некоторых моделях (например, AS6302T) при выходе из глубокого сна устройство раскручивает вентилятор на полную скорость (это шумно); лишь спустя несколько десятков секунд шум затихает. Если вы хотели настроить NAS на автоматическое пробуждение ночью (например, с целью создания резервных копий или репликации сетевых папок), то шум вентилятора может заставить вас передумать.

Нет расписания задач

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

Другие проблемы

Наверняка у других пользователей найдутся свои претензии к аппаратной и программной части сетевых хранилищ Asustor. В частности, встречаются жалобы на отсутствие в магазине приложения видеоплеера Kodi; странно и не всегда логично работает подключаемое к основному NAS устройство расширения с дополнительными лотками для дисков AS6004U, вентилятор которого принципиально не любит останавливаться, а яркость светодиодов – регулироваться программными настройками. Впрочем, если вы не пользуетесь устройством в качестве видеопроигрывателя и не планируете расширять его ёмкость добавлением специального устройства, вас эти проблемы обойдут стороной.

Заключение

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

Telegram – один из самых популярных сервисов для обмена мгновенными сообщениями, которым пользуются более 500 миллионов человек. Хотя Telegram не считается самым безопасным сервисом для обмена мгновенными сообщениями (этот титул по праву принадлежит Signal), история переписки в приложении Telegram для iOS не попадает ни в резервные копии iTunes, ни в iCloud. Более того, секретные чаты Telegram не хранятся даже на серверах Telegram. В результате секретные чаты Telegram можно извлечь исключительно из того устройства, которое участвовало в переписке. О том, как это сделать, мы расскажем в данной статье.

Методы, которые не работают: облако Telegram

Так же, как и Skype, Telegram относится к приложениям, которые хранят историю переписки пользователей на сервере – за единственным исключением. В Telegram есть возможность организовать защищённую переписку, в терминах Telegram — «секретный чат».

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

Обратите внимание: секретные чаты Telegram не попадают в облако. Обычные чаты хранятся на серверах компании и могут быть получены по запросу от правоохранительных органов (в зависимости от юрисдикции).

iTunes и резервные копии в iCloud

Многие приложения для обмена мгновенными сообщениями сохраняют резервные копии переписки в локальных резервных копиях iTunes или резервных копиях в iCloud. Другие (например, собственное приложение Apple iMessage) могут и синхронизировать сообщения через iCloud (впрочем, в случае с iMessage всё не так просто: если сообщения синхронизируются, то они не попадают в «облачные» резервные копии; в локальные же резервные копии они сохраняются всегда). Telegram относится к классу приложений, которые не сохраняют историю переписки ни в локальных, ни в облачных резервных копиях iCloud. Не используется и встроенный в iCloud механизм синхронизации. Этот подход означает, что ни логический, ни облачный анализ в случае с Telegram не сработают даже для обычных чатов, не говоря о секретных.

Обратите внимание: приложение Telegram для iOS не позволяет данным о переписке попасть ни в локальные, ни в облачные резервные копии.

Анализ образа файловой системы – единственный работоспособный метод

С учётом того, что Telegram для iOS не синхронизирует данные с облаком, не создаёт локальные или облачные резервные копии, единственным способом получить доступ к данным как секретных, так и обычных чатов Telegram является извлечение из iPhone образа файловой системы. Извлечь образ файловой системы можно при помощи Elcomsoft iOS Forensic Toolkit.

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

Извлечение и анализ переписки и секретных чатов Telegram

Для просмотра истории переписки и секретных чатов Telegram используйте Elcomsoft Phone Viewer 5.0 или более новую версию.

Для анализа переписки в приложении Telegram для iOS проделайте следующие шаги:

1. Извлеките образ файловой системы iPhone в формате TAR (используйте приложение Elcomsoft iOS Forensic Toolkit).
2. Запустите Elcomsoft Phone Viewer и откройте полученный образ.
3. После того, как обработка будет завершена, кликните на иконке Telegram.
4. Данные доступны для просмотра и анализа, включая секретные чаты.

Заключение

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