16.10.2017 16:07
ptsecurity 30 13700 Источник
image

Изображение: crocs.fi.muni.cz

Международная группа исследователей информационной безопасности из Великобритании, Словакии, Чехии и Италии обнаружила критическую уязвимость в популярной библиотеке шифрования RSA Library v1.02.013 от Infineon. Ошибка в алгоритме для генерации простых чисел RSA, делает сгенерированные с помощью библиотеки Infineon ключи шифрования подверженными факторизации — это позволяет злоумышленникам раскрывать секретную часть ключа.

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

В чем проблема


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

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

Первые последствия


Исследователи проверили национальные ID-карты четырех государств, и быстро выяснили, что как минимум карты двух стран — Эстонии и Словакии — используют для обеспечения безопасности уязвимые ключи длиной 2048 бит. Эстонские власти подтвердили наличие уязвимости, заявив о том, что с 2014 года было выпущено около 750 тысяч уязвимых карточек. Один из журналистов издания Ars Technica в 2015 году получил карточку «электронного резидента Эстонии» — эксперимент показал, что использующийся в ней ключ поддается факторизации.

Кроме того, Microsoft, Google и Infineon предупредили о том, что слабость механизма факторизации может серьезно влиять на эффективность встроенных механизмов защиты TPM-продуктов. По иронии, такие крипточипы используются как раз для обеспечения дополнительной безопасности пользователей и организаций, которых часто атакуют хакеры.

Исследователи также проверили 41 модель различных ноутбуков, использующих чипы TPM — в 10 из них используется библиотека от Infineon. Уязвимость оказывается особенно серьезное влияние в случае TPM версии 1.2, поскольку те ключи, что система использует для контроля работы шифровальщика BitLocker от Microsoft подвержены факторизации. Это значит, что любой, кто украдет или завладеет уязвимым компьютером, сможет преодолеть защиту жесткого диска и загрузчика.

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

Среди других находок — 2892 PGP-ключа, использующихся для шифрования email-переписки, 956 из которых оказались факторизуемыми. По словам экспертов, большинство уязвимых PGP-ключей были сгенерированы с помощью USB-продукта Yubikey 4. При этом другие функции USB-ключа, включая U2F-аутентификацию не содержали уязвимости.

В завершение, исследователям удалось найти 15 факторизуемых ключей, использовавшихся для TLS. Большинство из них в строке описания содержали слово SCADA.

Как защититься


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

При этом, исследователи опубликовали инструмент, позволяющий определить, был ли конкретный ключ сгенерирован с использованием уязвимой библиотеки. Подробности представлены в их блог-посте. Кроме того, Infineon выпустила обновление прошивки, которое закрывает уязвимость, производители TPM сейчас работают над собственными патчами.

Также исследователи связались с администрацией GitHub, сервис сейчас оповещает пользователей о необходимости замены ключей для подписи софта. В свою очередь, власти Эстонии закрыли свою базу данных публичных ключей, однако никаких анонсов о возможных заменах уязвимых ID-карт пока не было опубликовано.

Комментарии (30)


  1. flatscode
    16.10.2017 19:16
    #10476176

    Слабость механизма факторизации

    А можете пояснить, в чем заключается слабость? Недостаточная длина, плохой генератор случайных чисел или что-то другое?


    1. badfiles
      16.10.2017 20:33
      #10476290

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


      1. flatscode
        16.10.2017 20:49
        #10476304

        Ни-че-го не понимаю… :-)


        1. badfiles
          17.10.2017 17:13
          #10477916

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


    1. gonzazoid
      16.10.2017 21:24
      #10476372

      >используют для обеспечения безопасности уязвимые ключи длиной 2048 бит.

      С длиной все в порядке, очевидно использовались слабые пары. Например такие что дают N-1 состоящий из маленьких множителей. Или еще что похитрее.


    1. flatscode
      16.10.2017 22:07
      #10476432

      Ясно, пока технических деталей нет, есть обрывки:

      ...In the context of a responsible disclosure process, the team informed Infineon upfront that also “Fast Prime” could be exposed to an exploit using one of the newly developed analysis methods under a specific combination of preconditions: First, the application software must utilize the “Fast Prime” algorithm instead of the non-accelerated version, both of which are selectable. Second, the RSA key pairs have to be generated on a card or token which uses this algorithm. If these preconditions are met, then RSA key lengths of up to 2048 bits are considered to be significantly weakened in cryptographic strength...

      www.infineon.com/cms/en/product/promopages/rsa-update/rsa-background


    1. yleo
      17.10.2017 01:27
      #10476680

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

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

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

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


      1. mayorovp
        17.10.2017 09:15
        #10476854

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


        Недостаток энтропии обычно проявляется в другом — сгенерированные ключи оказываются одинаковыми у разных пользователей.


        1. yleo
          17.10.2017 11:21
          #10477108

          Ну так в библиотеке ошибки только алгоритмические, а одинаковые ключи из-за отсутствия энтропии — это скорее ошибка применения.

          Насколько я сейчас понимаю проблема происходит от primesieve.org, точнее в последствиях en.wikipedia.org/wiki/Wheel_factorization


      1. terrier
        17.10.2017 11:54
        #10477204
        -1

        Так вот, суть проблемы в том, что внутри библиотечки необходимая «случайность» либо плохо собиралась, либо плохо использовалась, либо и то и другое — собственно не важно.

        Нет.
        The vulnerability does NOT depend on a weak or a faulty random number generator — all RSA keys generated by a vulnerable chip are impacted.

        Уязвимость алгоритмическая


        1. yleo
          17.10.2017 12:29
          #10477266
          -1

          Да, чуть выше уже уточнил про wheel factorization.

          С другой стороны, по-сути собранная случайность плохо использовалась.


      1. Frankenstine
        18.10.2017 09:06
        #10478722
        -1

        Но на практике, как правило, нет хорошего доступного источника настоящей случайности.

        Чушь, вы отстали примерно на пару десятилетий. Уже давно в процессорах аппаратные генераторы случайных чисел на тепловых шумах.
        habrahabr.ru/post/128666


        1. yleo
          18.10.2017 09:50
          #10478760

          Чушь, вы отстали примерно на пару десятилетий. Уже давно в процессорах аппаратные генераторы случайных чисел на тепловых шумах.

          На всякий — в эксплуатации находятся достаточно процессоров без RDRAND или аналогов этой инструкции. При этом собранную "случайность" всё равно нужно правильно использовать...


          1. Frankenstine
            18.10.2017 15:10
            #10479488

            Этим занимаются части операционной системы, отвечающие за функцию CryptGenRandom в Windows и псевдоустройство /dev/random в Linux. Я возражал именно против «на практике, как правило, нет хорошего доступного источника настоящей случайности», потому как это дела минувших дней. По крайней мере даже в процессорах AMD двухлетней давности эту инструкцию реализовали, а в самых новых ещё более надёжная RDSEED есть. Так что, по сути, не имеют надёжного источника случайных чисел только либо морально старые процессоры, либо процессоры не для серверного/десктопного применения — всякие там энергоэффективные (и неспешные) miprs/arm/etc.


            1. yleo
              18.10.2017 16:04
              #10479622

              Этим занимаются части операционной системы, отвечающие за функцию CryptGenRandom в Windows и псевдоустройство /dev/random в Linux.

              Ну всё правильно, только это не имеет непосредственного отношения к инфинеоновскому контроллеру, его прошивке и сопутствующих библиотекам. Более того, я соглашусь что моё многословие по теме в том комментарии было лишним. Особенно в ключе того, что дело там в «сите» (генераторе) простых чисел, а не где-то ещё.

              Тем не менее, с генераторами «случайности» не всё очевидно и упомянутая позиция Линуса совершенно оправдана (т.е. мышиные телодвижения таки попадают в /dev/random даже при наличии RDRAND у CPU). Как говорится «Добрым словом и револьвером можно добиться большего, чем одним добрым словом» (Аль Капоне).


        1. flatscode
          18.10.2017 11:21
          #10478950

          Есть интересные комментарии в википедии по поводу RDRAND:

          ...I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction. To quote from the article below: 'By this year, the Sigint Enabling Project had found ways inside some of the encryption chips that scramble information for businesses and governments, either by working with chipmakers to insert back doors....' Relying solely on the hardware random number generator which is using an implementation sealed inside a chip which is impossible to audit is a BAD idea…

          Linus Torvalds dismissed concerns about the use of RdRand in the Linux kernel, and pointed out that it is not used as the only source of entropy for /dev/random, but rather used to improve the entropy by combining the values received from RdRand with other sources of randomness. However, Taylor Hornby of Defuse Security demonstrated that the Linux random number generator could become insecure if a backdoor is introduced into the RdRand instruction that specifically targets the code using it. Taylor's proof-of-concept implementation works on an unmodified Linux kernel prior to version 3.13...

          en.wikipedia.org/wiki/RdRand


    1. a5b
      17.10.2017 02:45
      #10476704

      Пишут, что это вариация на тему https://en.wikipedia.org/wiki/Coppersmith%27s_attack — в большом наборе ключей обнаружили закономерность в структуре "генерируемых" чипом простых чисел при использовании ускоренного метода проверки на простоту “Fast Prime”. Полное описание атаки будет доступно 2 ноября.
      https://keychest.net/roca "… The ROCA vulnerability has been discovered by researchers at Masaryk University (Brno, Czech Republic).… ROCA vulnerability, which is caused by an error in RSA key generation in Infineon security chips."
      Technical details: The Return of Coppersmith's Attack: Practical Factorization of Widely Used RSA Moduli (ROCA) — ACM CCS conference on 2nd November 2017 — https://acmccs.github.io/session-H1/
      https://crocs.fi.muni.cz/public/papers/rsa_ccs17 ROCA: Vulnerable RSA generation (CVE-2017-15361)


      The vulnerability is present in NIST FIPS 140-2 and CC EAL 5+ certified devices since at least the year 2012.… The algorithmic vulnerability is characterized by a specific structure of the generated RSA primes, which makes factorization of commonly used key lengths including 1024 and 2048 bits practically possible.… The worst-case price of the factorization on an Amazon AWS c4 computation instance is $76 for the 1024-bit key and about $40,000 for the 2048-bit key.…
      The vulnerability was found by a close inspection of a large number of RSA keys generated and exported from the manufacturer smartcards by researchers at CRoCS laboratory, Masaryk University, Enigma Bridge and Ca' Foscari University. The full results will be presented at an academic ACM Conference on Computer and Communications Security (ACM CCS '17) starting from October 30th.

      Предложен оффлайн тест для обнаружения слабых ключей — https://github.com/crocs-muni/roca
      Код проверяет, попадают ли остатки от деления N на ряд малых простых в определенные наборы https://github.com/crocs-muni/roca/blob/master/roca/detect.py#L597


              self.primes = [3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167]
        self.prints =....
        for i in range(0, len(self.primes)):
            if (1 << (modulus % self.primes[i])) & self.prints[i] == 0:
                return False

      https://crypto.stackexchange.com/questions/52292/what-is-fast-prime "N mod 97 ? {1,35,36,61,62,96}"


      1. bopoh13
        17.10.2017 15:21
        #10477686

        Также исследователи связались с администрацией GitHub, сервис сейчас оповещает пользователей о необходимости замены ключей для подписи софта.
        В репозитории указан уязвимый ключ с длиной до 4096 бит, созданный GnuPG v2. Я создавал ключ по инструкции длиной 4096 бит (GnuPG v1.4.21). Результаты теста открытого ключа — безопасный.
        Зачем выкладывают закрытые ключи в репозитории?


        1. navion
          17.10.2017 15:28
          #10477710

          Выкладывают публичные, а уязвимости подвержены ключи, сгенерированные внутри смарт-карт.


  1. dreka5
    16.10.2017 21:16
    #10476360

    немного не про то, но
    интересно, а если пользователь будет всегда использовать персональный закрытый ключ, насколько это сможет повысить степень защиты.
    скажем пользователю выдаются ( например по электронной почте ) набор случайных слов — ромб, вектор, плазмотрон, мятный, есть… и так ~64 буков. пользователь вводит их приложение, браузер. там оно склеивается и фиксится. теперь всё шифруется с помощью этого ключа.
    такое в теории сломать проблематично, и если будет сломано, то только для 1го случая.
    что тут принципиально не айс, ну кроме применения третьих почтовых программ?


    1. Nokta_strigo
      17.10.2017 00:07
      #10476620

      Принципиально не айс тут схема распределения ключей, когда ключами надо обмениваться по защищённому каналу связи. Если абонентов много и отсутствует единый доверенный центр распределения ключей — это превращается в ад.
      Плюс если кто-то утащит этот ваш ключ, то сможет расшифровать все предыдущие сообщения. Некоторые современные протоколы защищают от этого (TLS можно настроить, OpenVPN в режиме TLS всегда), см. Perfect Forward Secrecy и протокол Диффи-Хэллмана

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


      1. dreka5
        17.10.2017 00:47
        #10476652

        вот это интерересно, данкешн


      1. Dreyk
        17.10.2017 10:36
        #10476990

        ключами надо обмениваться по другому каналу (на сходке фидошников, например :D)


    1. badfiles
      17.10.2017 17:21
      #10477930

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


  1. firk
    17.10.2017 14:04
    #10477498

    Я уж подумал очередная дыра в OpenSSL


    1. badfiles
      17.10.2017 17:16
      #10477924

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


  1. Germanets
    17.10.2017 15:10
    #10477666

    А найденные уязвимости и атаки на них были известны в момент, когда данные чипы и библиотеки создавались, или нет? </параноик_мод>


  1. navion
    17.10.2017 15:39
    #10477738

    У кого-нибудь есть TPM-модуль от ASUS? Обновление от Dell ставится на него или там проверка модели?


    1. navion
      17.10.2017 15:52
      #10477766

      Или от Lenovo.


  1. OverQuantum
    17.10.2017 18:05
    #10477986

    Примерчик уязвимого ключа со смарт-карты (RSA-1024, hex)

    92AAE726C9F3CEA8AACE8B74726387093137B33B1A2985FF2DA10EEB034AA4467029B7C90282D9B131B20E098C27224851082125501A48F14417AE1FE849F276103046F9A4D429B4B394FA89D56D7E30C696482D63637A195A0F7546E88A29ECAFABB53BF049E75CCC71FB43F896F7059FCCBF0EEA194EF3F7A1D40800E44CD1