Уязвимости SSD с аппаратным шифрованием позволяют злоумышленникам легко обходить защитные меры



    Исследователи из университета Радбоуд (Нидерланды) рассказали об уязвимостях в системе защиты некоторых твердотельных накопителях. Они позволяют взломщику обходить функцию шифрования данных диском и получать доступ к информации на диске без необходимости знать пароль доступа.

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

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

    Но и это еще не все, проблема в том, что есть способ получить доступ к данным вообще без пароля — для этого необходимо использовать уязвимость в прошивке SED. Уязвимости такого рода затрагивают спецификации "ATA security" и "TCG Opal".

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

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

    «Отсутствие криптографической связки — это катастрофа. Из-за недоработки пользовательские данные защищены слабо. Данные, которые хранятся на диске, могут быть без труда восстановлены и скопированы», — говорит один из исследователей, обнаруживших проблему. Результаты исследований и свои выводы эксперты опубликовали в виде статьи (скачать можно здесь).

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



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

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

    Дело в том, что исследователи стали углублять свою работу, проводя изучение безопасности пользовательских данных разных систем. Наиболее подвержены опасности пользователи Windows, поскольку в этой ОС некоторые сервисы усугубляют проблему. Так, проблемой можно назвать Windows BitLocker, софтварную систему шифрования данных на диске, работающем в среде Windows OS.

    Как только BitLocker обнаруживает SSD с поддержкой аппаратного шифрования, сервис отключается, и данные не шифруются посредством Windows, ОС «надеется» на аппаратную поддержку. Так что пользователи, которые до настоящего момента работают с SSD Сrucial и Samsung и не обновили прошивку своих накопителей, фактически держат свои данные открытыми для всех.

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

    Зато в этом случае защита является двойной и особых проблем, по сути, нет. По мнению исследователей, обнаруживших проблему, корень ее находится в спецификациях, созданных разработчиками аппаратного шифрования.
    Поделиться публикацией
    Комментарии 33
      –1
      Хм… по-моему это не баг, а фича… очень гуманная фича.
        +2
        BitLocker требует от накопителя не упомянутого в статье Opal, а eDrive, стандарта, продвигаемого Microsoft.

        Например, NVME-накопители Samsung поддерживают Opal, но BitLocker на них использует программное шифрование, поскольку спецификацию eDrive, насколько мне известно, Microsoft не адаптировала к NVME.

        Впрочем, добиться работы накопителей с поддержкой Opal в среде Windows возможно (но BitLocker в этом участия не принимает).
          +6
          Главная проблема в том, что кроме паролей доступа, которые задают владельцы SSD, есть еще и мастер-пароль, который задается на фабрике
          В принципе не понимаю, как можно доверять устройствам, у которых есть какой-то «мастер-пароль, задаваемый на фабрике». Это же абсурд.
            +1
            Вы наверное немного перепутали. Мастер-пароль присутствует в спецификации ATA Security. Раньше (и сейчас) эта фича была не для шифрования диска, а скорее как аналог пароля на биос, так, от любопытных глаз. В спецификации TCG Opal конечно мастер-пароля уже нет.
              –1
              Но что-то там всё-таки можно напортачить, раз в таблице статьи Crucial не прошли проверку TCG Opal (3 колонка).
                –1
                У тех, кто некорректно реализовал Opal, пароль, вводимый пользователем, не связан с ключом шифрования, насколько я понимаю.

                Если сильно упрощённо:

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

                А у Crucial ключ шифрования никак не связан с паролем, который вводит пользователь. Решение о том, правильный ли введён пароль, принимает не бесстрастная «криптография» (как было бы, если бы ключ был сгенерирован на основе пароля), а контроллер. Таким образом, этот этап можно обойти, вскрыв контроллер и «вытащив» из него ничем не защищённый ключ + зашифрованные данные. И спокойно расшифровать их этим ключом.

                Защита получается намного слабее. В первом случае её не сможет вскрыть условное ФБР (если не выбьет из пользователя пароль), а во втором случае — сможет, без всякого взаимодействия с пользователем.
            +5
            Кому лень читать отчёт, рассказываю в двух словах, что сделали пацаны. Подключились через JTAG к контроллеру, поправили в его ОЗУ процедуру, проверяющую пароли, так, чтобы подходил любой пароль. Так как задаваемый пользователем пароль никак не связан с ключом шифрования диска (DEK), то такая модификация процедуры аутентификации делает данные на диске доступными через обычный интерфейс.
              +4
              То, что пароль никак не связан с шифрованием — это баг в голове у тех, кто принял решение реализовать шифрование диска таким способом.
                –2
                Всё просто — пользователь не сможет сменить пароль при таком раскладе. Тут и иллюзия безопасности (шифровано же) и удобство (можно сменить пароль, не перешифровывая диск).
                  +2
                  Сможет, cryptsetup же может. Генерируем мастер-ключ, его шифруем паролем пользователя и храним. Захотелось сменить пароль — просто ввели старый пароль, мастер-ключ расшифровался, ввели новый пароль,… ПРОФИТ.
                  Это просто халтура, сделали по принципу «и так сойдет». Да и то, что на продовой железке не выключен наглухо jtag, тоже лютый баг.
                    –1
                    А теперь представим, что все сделано как надо. Что в таком случае будет, если юзер — та-да-а! — забыл пароль?
                      +1
                      Дается допустим 5 попыток, если все неправильные — генерируется новый мастер-ключ, старые данные по сути перестают быть доступными и стираются.
                        0
                        Вопрос в том, что главней — данные пользователя, или конфиденциальность. В первом случае это неудачное решение.
                          +2
                          По уму шифрование диска — это конфиденциальность. Если пользователю важны данные — нужно делать бекапы, а не возможность их восстановления с «зашифрованного» диска.
                            0
                            Впрочем, да, «простому смертному юзверю» шифрованный диск и не нужен.
                              0
                              Впрочем, да, «простому смертному юзверю» шифрованный диск и не нужен.

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

                              Так что, всё же, шифрование диска имеет смысл и для «простых смертных», или, говоря другими словами — если на компе есть хоть один файл, утечка которого нежелательна (хотя и не смертельна) — то это уже достаточное основание для шифрования.
                                0
                                Может быть. Лично я предпочитаю держать личную инфу на внешних носителях, а пароли — записывать. Ну да, флэшку или блокнот тоже можно украсть, но для этого нужно, чтобы кого-то интересовала именно моя личная информация. Сами по себе эти вещи ценности не имеют.
                            +1
                            Вопрос в том, что главней — данные пользователя, или конфиденциальность

                            Это уже проблема выбора пользователя — пусть в настройках выбирает.
                          +1
                          Я не разработчик, но разве в этом случае пользователь не обязан отказаться от шифрования, если считает свою забывчивость слишком значительной? Мне казалось, что достижение конфиденциальности неотрывно от возникающего риска полной утери данных в случаях амнезии/склероза и т.д.
                            +2

                            Юзер восстановит данные из бекапов. (бекапов, ха-ха-ха)

                              0
                              А в чем проблема? Сделать бэкап сейчас можно одной кнопкой. И восстановить тоже одной кнопкой. Оставаясь юзером.
                                0
                                Дело не в сложности реализации, а в том, что обычно люди (причем и простые юзеры и даже админы иногда) вообще не думают о бэкапах в принципе. Отчасти поэтому облака так популярны — пользователь зачастую вообще не думает, что его данные хранятся где-то вне устройства, и испытывает огромную радость, когда устройство умирает, а данные оказываются целыми. Хотя вроде бы что сложного в том, чтобы вечером подключать телефон, например, к компу и сливать копии данных.
                              0
                              А что будет если юзер — та-да-а и сам удалит свои файлы, или уронит диск или сделает еще какую-нибудь глупость?

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

                              Собственно зачем покупать и пользоваться КОММЕРЧЕСКИМ продуктом для шифрования, если он будет предоставлять всего лишь иллюзию безопасности?
                              0
                              Согласен со способом, JTAG не отключали примерно те же люди, потому не удивительно.
                              0
                              Оно не шифровано. Чтобы было шифровано, сами данные должны быть изменены. И если производитель говорит «шифровано», а на самом деле нет, это наглый обман, и за это должна быть серьёзная ответственность.
                                0
                                По идее да, но что там в договоре «обещаем шифрование, но ничего не гарантиуем, посколько ПО».
                                0
                                Если пользователю нужна лишь иллюзия безопасности, зачем ему вообще шифровать диск? Пусть просто пароль на вход в систему поставит и достаточно.
                              0
                              Там случайно DEK не один для всех дисков серии?
                                0
                                Если к диску можно просто так подключиться по JTAG и править в ОЗУ процедуры, то даже если DEK зависит от пароля, то можно отключить максимальное кол-во попыток и брутфорсом подобрать пароль. Я правильно понимаю? Это же бред какой то получается, защита от дурака.
                                0
                                Никогда такого не было, и вот опять…
                                  0
                                  вот ведь молодцы, независимое от пароля шифрование реализовали, это даже веселее, чем парольные хэши без соли.
                                  xor ещё можно для «шифрования» использовать, эффект примерно тот же.
                                    0
                                    ATA-пароли и не позиционировались как надёжное средство защиты, сама спецификация очень древняя. Другое дело TCG Opal, там при правильной реализации можно на что-то рассчитывать. Но всё равно мы как потребители не можем проверить, есть ли там аппаратные закладки, поэтому самым надёжным будет софтовое шифрование с открытыми исходниками.
                                      0
                                      Подход к реализации опции плавно перетёк с флешек.

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

                                      Самое читаемое