Извлечение аппаратного ключа полнодисковой защиты в телефонах Android на процессорах Qualcomm

    Эксплоит опубликован на Github




    Компания Google начала внедрять полное шифрование диска (Full Disk Encryption, FDE) по умолчанию с версии Android 5.0 Lollipop. В первое время, когда шифрование реализовали в устройствах Nexus 6, многие пользователи жаловались на снижение производительности при чтении и записи данных на накопитель, но с версии Android 6.0 эту проблему вроде бы решили.

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

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

    На устройствах iOS 9 этот ключ является производной функцией от пользовательского пароля и уникального 256-битного аппаратного ключа, зашитого в смартфон на заводе. Взломать шифрование такого уровня с помощью брутфорса не может даже ФБР, как известно из недавней истории со смартфоном стрелка из Сан-Бернардино, из-за которого ФБР и Apple дошли до суда. В итоге ФБР всё-таки сумело взломать телефон с помощью неизвестной 0day-уязвимости. Как можно понять из слов главы госструктуры, за обход защиты ФБР пришлось заплатить хакерам более миллиона долларов.


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

    Таким образом, брутфорс FDE возможен только с использованием конкретного аппаратного устройства. Это значительно затрудняет проведение атаки. В обычном случае можно было бы создать миллион копий и распараллелить брутфорс в облачном сервисе, что позволяет очень быстро подобрать 99% реальных паролей. Но в данном случае приходится ограничиваться единственным устройством, на котором Apple добавляет ещё и дополнительные помехи — задержки между попытками ввода пароля, ограничение на максимальное количество попыток и т.д. Вот почему для спецслужб исключительно важно найти способ извлечения аппаратного UID, тогда брутфорс пароля становится банальной технической задачей.

    Полное шифрование диска в Android 5.0+ реализовано несколько иначе, чем в iOS 9, и подробно описано в блоге Николая Еленкова и в официальной документации Android.

    Здесь ключ шифрования тоже является производной функцией от обычно слабого пользовательского пароля, но также от случайным образом сгенерированного 128-битного мастер-ключа (Device Encryption Key — DEK) и случайно сгенерированной 128-битной соли. Поле генерации DEK защищается с помощью тщательно продуманной схемы, в которой используются введённые пользователем значения — пинкод/пароль/паттерн (графический ключ) для входа. Затем зашифрованный DEK помещается в специальное зашифрованное хранилище под названием crypto footer. Все эти уровни шифрования нужно преодолеть, прежде чем расшифровать DEK, а затем любую информацию, записанную на накопителе.



    Как и в случае с iOS 9, в операционной системе Android реализована привязка схемы шифрования к конкретному аппаратному обеспечению, чтобы не допустить брутфорса на копиях операционной системы. Функцию аппаратной привязки выполняет специальное аппаратное хранилище — KeyMaster, которое работает в особом окружении Trusted Execution Environment (TEE), полностью независимом от операционной системы Android. Защищённость ключей в окружении KeyMaster имеет важнейшее значение. Только это защищает систему полного шифрования диска от проведения эффективного брутфорса в параллельных потоках на копиях ОС.

    В устройствах Android изолированное окружение никогда не выдаёт свой собственный ключ наружу в «небезопасную» среду. Наоборот, модуль KeyMaster получает из небезопасной среды «блоб ключа» (key blob), расшифровывает хранящийся там ключ — и отдаёт его обратно. Другими словами, работа системы шифрования возможна только непосредственно на аппаратном устройстве, но не в виртуальной среде на другом компьютере.

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



    Защиту окружения KeyMaster и выполнение команд на выделенном безопасном процессоре обеспечивает защищённая среда, предоставленная производителем оборудования. В Случае с Qualcomm это среда QSEE (Qualcomm Secure Execution Environment). Она допускает к исполнению на выделенном процессоре только отдельные маленькие приложения, которые называются «трастлеты» (trustlets). Один из таких трастлетов — KeyMaster. В исходном коде Android есть инструкции для обращения к приложению KeyMaster. На самом деле трастлет поддерживает всего четыре инструкции:

     * Commands supported
     */
    enum  keymaster_cmd_t {
        /*
         * List the commands supportedin by the hardware.
         */
        KEYMASTER_GENERATE_KEYPAIR = 0x00000001,
        KEYMASTER_IMPORT_KEYPAIR = 0x00000002,
        KEYMASTER_SIGN_DATA = 0x00000003,
        KEYMASTER_VERIFY_DATA = 0x00000004,
    };

    KeyMaster работает в точности как описано выше: он получает блоб ключа, вычисляет подпись и помещает её в буфер.

    И вот теперь мы подошли именно к тому этапу, на котором действует новый эксплоит, который появился в открытом доступе 30 июня (репозиторий на Github). Эксплоит использует недавно найденные уязвимости CVE-2015-6639 и CVE-2016-2431.

    Автор эксплоита, специалист по безопасности Гал Беньямини (Gal Beniamini) написал поддельную версию приложения QSEE и с помощью вышеупомянутых уязвимостей сумел загрузить её в защищённое окружение, тем самым осуществив повышение полномочий и взломав защиту окружения QSEE, которое участвует в процессе генерации ключа для шифрования диска.

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

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

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

    Есть интересный момент. Защищённую среду на мобильных устройствах устанавливает не сама компания Qualcomm, а OEM-производители. Они могут сотрудничать с правоохранительными органами той страны, в юрисдикции которой находятся, и выполнять требования судебных запросов. Соответственно, если подобная криптографическая схема будет реализована российским производителем, то информация на смартфоне будет рассекречена по запросу российского суда.

    И ещё один интересный момент. Несмотря на то, что Гал Беньямини несколько месяцев обсуждал данные уязвимости с Qualcomm и Google, исправить их не так просто — здесь недостаточно программного апгрейда (для двух уязвимостей патчи для Android вышли в январе и мае), а может понадобиться аппаратный апгрейд. Дело в том, что если злоумышленник получит устройство, то теоретически может откатить программный апгрейд, вернуть аппарат на уязвимую версию и провести атаку.

    Как уже говорилось выше, код эксплоита опубликован на Github. Вот схема его работы.



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

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

    Будем надеется, что такую схему реализуют на новом поколении Android-устройств.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 25

      0
      Как в этой стратегии планируется подобрать графический ключ? Его часто используют вместо пина
        +1

        А что в этом сложного? Кодируется элементарно — начальная точка список с направлениями движения, их и брутфорсить.

          0
          Пин это обычно четыре цифры, а в графическом ключе точнее может быть гораздо больше
            +2
            Точек может быть больше, но возможных связей меньше, чем кажется.

            Пароль 1236
            Начальная точка на еденице — доступно 2_5_4… уходим на двойку — доступно 3_6_5_4… уходим на тройку — доступно 5_6… уходим на шестёрку — доступно 5_8_9 и так далее с пересечением траекторий между точками 6_7 4_9… с каждым ходом возможных комбинаций становиться меньше, дважды одну и туже точку использовать нельзя.
            Сейчас мне не сподручно посчитать количество возможных комбинаций от 4-х до 9-и точек.
              0

              6 и 8 также доступны в качестве второй точки:


              image

                0
                У меня можно изобразить почти любую кракозябру: пример
                  +1
                  Если точка ранее пройдена, новая линия может через нее проходить. То есть возможен вариант 2-1-3
                • UFO just landed and posted this here
                  +1
                  Не пойму, с чего вдруг это убогонькую защиту стали называть «графическим» ключом… Это я также про «любую кракозябру» в вашем ответе выше. Любая — это любая, а не по 9 точкам, что есть всего 9 цифр.
                +1
                Я думаю, в случае использования графического ключа ничего подбирать не надо будет. По следам на экране восстановят.
                0
                Закончится всё запретом к ввозу ещё одного девайся на нашу территорию.
                  +5
                  Не «взлом шифрования», а извлечение аппаратного ключа полнодисковой защиты, что, в общем-то, нехорошо, но не смертельно, и точно не может называться «взломом шифрования».
                    0
                    Ализар же
                      –2
                      Для FDE это и есть взлом шифрования, тут же не написали про взлом алгоритмов которые она использует.
                        +2
                        Нет, это не взлом шифрования. Это всего лишь позволяет брутфорсить пароль, если вы украдёте девайс и считаете носитель, а до этого выполните на этом девайсе эксплоит.
                        –1
                        По ссылке после чтения половины статьи начинают вымогать деньги за продолжение
                          0
                          Воспользуйтесь торрент-трекерами, именно для этого я указал месяц, год и название журнала.
                            –1
                            Номер нужен апрельский. Скачал майский, там статьи нет. Выход на сайте не совпадает с выходом на бумаге.
                          +1
                          Господа, понимаю ваше негодование, но скопируй я сюда весь текст статьи целиком, это было бы явным нарушением авторских прав (журнал долгие годы продавался в бумажном виде, а теперь продаётся в цифровом). Я полагаю, что аудитория GT достаточно продвинута для того, чтобы суметь найти указанный выпуск журнала в Интернете. Судя по реакции, вы предпочтёте не получить сведения о существовании статьи вовсе, чем получить ссылку на пусть и урезанную версию с оф. сайта, но с намёком на то, где скачать полную?
                            –1
                            Лучше не давать гиперлинк на неполную статью, достаточно выходных данных.
                            Тогда все желающие нашли бы сами и скачали.
                            А тут такая подстава, как удар дубиной по голове ))
                              +2
                              Пожалуй, вы правы. Стоило, значит, дать хотя бы предупреждение, что там урезанная версия. Сам я, просто, уже привык, что материалы из свежих номеров там всегда неполные.
                            0
                            http://www.docme.ru/doc/1140659/hkr042016 правда усилия надо приложить и найти конкретную статью
                            0
                            > Кстати говоря, для того редкого случая, когда пользователь установил для шифрования по-настоящему сложный пароль с высокой энтропией

                            Какого он низкого мнения об Android пользователях однако.
                              0
                              Зачем вообще тут описан последний вариант с подменой телефона? Или смартфоны Apple как-то застрахованы от такого?

                              Only users with full accounts can post comments. Log in, please.