В 1643 году Пьер де Ферма предложил метод факторизации. Этот метод позволяет эффективно раскладывать целые числа на простые множители.

Алгоритм шифрования и подписи RSA основывается на том, что факторизация — это задача с высокой сложностью. Открытый ключ RSA содержит составное число (обычно называемое N), которое является произведение двух простых чисел (обычно p и q).

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

Я применил метод факторизации Ферма к большим наборам открытых ключей RSA. И я смог обнаружить небольшое количество уязвимых ключей, которые принадлежали принтерам Canon и Fujifilm (первоначально выпускавшихся под маркой Fuji Xerox). В этих устройствах используется криптографический модуль от компании Rambus.

Что такое метод факторизации Ферма? 


Идея метода состоит в том, что произведение двух простых чисел можно представить в виде N=(A-B)(A+B), где A — это среднее арифметическое двух простых чисел (A=(p+q)/2), а B — это расстояние от A до искомых простых чисел (B=p-a=a-q).

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

Для каждой итерации мы можем вычислить B^2 = A^2 — N. Если результат является квадратом, то мы угадали A. И теперь можем вычислить p=A+B и q = A-B.

Первоначально Ферма описал этот метод в своём письме, датированным 1643 годом. Текст оригинального письма можно найти в Oeuvres de Fermat, на 256 странице.

Кто пострадавший?


Несколько принтеров серий Fujifilm Apeos, DocuCentre и DocuPrint генерируют самозаверяющие сертификаты TLS с уязвимыми ключами RSA. Информационный бюллетень Fuji содержит список всех затронутых принтеров.

Некоторые принтеры Canon генерируют запрос на подпись сертификаты с помощью уязвимого ключа RSA. Насколько мне известно, это влияет на принтеры серий imageRUNNER и imagePROGRAF. 

Как принтеры Fujifilm, так и принтеры Canon используют криптографический модуль библиотеки Safezone от Rambus. Другие продукты, использующие этот модуль для создания ключей RSA, также могут быть затронуты. Код этой уязвимости — CVE-2022-26320.

Является ли это уязвимостью алгоритма RSA.

Нет, не является. Библиотеки RSA с корректной функцией генерации ключей эта уязвимость не затрагивает.

Как это происходит


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

Однако функции генерации ключей RSA могут реализовывать ошибочный алгоритм, например такой:

  1. Сгенерировать случайное простое число X;
  2. Найти следующее простое число и присвоить его q;
  3. Найти следующее простое число и присвоить его p;

Для стандартных размеров ключей RSA разница p и q — тысячи или меньше. Такой алгоритм является уязвимым для метода факторизации Ферма.

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


При обычных размерах ключей RSA в 2048 бит метод ферма со 100 итерациями надежно факторизует числа, где разница p и q меньше 2^517. Другими словами, простые числа, различающиеся только младшими 64 байтами, будут уязвимы. Можно было бы возразить, что 100 итераций — это слишком много, однако алгоритм настолько быстр, что на практике это не будет иметь большого значения.

Могут ли случайно сгенерированные ключи быть уязвимы?


Да, могут. Но для этого необходимо, чтобы они были идентичны, по меньшей мере, в своих старших 500 битах. Вероятность такого исхода — 1:2^500.

Как ты нашел ключи?


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

  • к которым у меня был доступ;
  • которые были предоставлены другими исследователями;
  • которые были общедоступны.

Я обнаружил уязвимые ключи Fujifilm в недавних сканированиях TLS-сертификатов Rapid7. Ещё некоторое количество сертификатов я обнаружил в логах Certificate Transparency. Связавшись с их владельцами, я узнал о принтерах Canon.

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

Что с SSH?


Скорее всего, уязвимых реализаций SSH, создающих такие ключи, нет. Хотя я и не могу это доказать.

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


Затронуты ли PGP/GnuPG/OpenPGP?


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

Вполне вероятно, что эти ключи были созданы вручную людьми, знающими об атаке и создающими тестовые данные

Рекомендации


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

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

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


  1. OldFisher
    05.04.2022 17:02
    +21

    На портрете Декарт.


    1. saipr
      05.04.2022 19:04

      Но похоже:


      image


    1. Blacklynx
      05.04.2022 19:08
      +3

      Ну это как Кейдж с Траволтой.


      1. domix32
        06.04.2022 11:47

        Тогда уж Билл Мюррей и Джеймс Белуши


    1. nkormakov
      06.04.2022 09:30
      +9

      Произошла коллизия по хэшу портрета


    1. debagger
      06.04.2022 16:50

      Я вообще думал что Боярский


      1. stephanthe
        07.04.2022 05:34

        Нет, тут без шляпы


  1. Maxim_Q
    05.04.2022 20:22

    Если допустим были сгенерированы уязвимые ключи для RSA 2048, то сколько времени потребуется на взлом? А если ключи будут RSA 4096? Стоит ли паниковать?


    1. vesper-bot
      06.04.2022 08:46

      Если уязвимые — плюс-минус столько же, сколько для RSA512. Если нормальные — так не взломать.


    1. saipr
      06.04.2022 09:41
      +2

      Стоит ли паниковать?

      Мне кажется, что речь не о панике, а о знании. Это знание полезно как разработчику, так и пользователю.


      1. Maxim_Q
        06.04.2022 18:47
        +1

        Я просто думал, что если в алгоритме идет генерация уязвимых ключей тогда нужно знать сколько времени займет взлом? Если учесть что уязвимость понижает кючи до 512 бит и уже сейчас не рекомендуют использовать ниже 1024 тогда это очень плохо с точки зрения безопастности и нужно перепроверять все библиотеки что занимаются генерацией этих ключей. В статью надобы добавить библиотеки и их версии что имеют проблемы и что нормально генерируют RSA ключи.


        1. saipr
          06.04.2022 20:54

          В статью надо бы добавить библиотеки и их версии что имеют проблемы и что нормально генерируют RSA ключи.

          Ваше предложение полностью поддерживаю, тем более что аналогичный инцендент уже встречался, правда с российским хэшем ГОСТ Р 34.10-2012.


  1. Vvladt
    06.04.2022 09:43

    Ферма, Декарт, какая разница :D


    1. OldFisher
      06.04.2022 10:21

      "Кто-то из древних"...


  1. paluke
    06.04.2022 10:47
    +3

    Перебор для факторизации Ферма можно ускорить, анализируя остатки по простым модулям. Значение p*q можно представить разностью квадратов ((p+q)/2)^2 — ((p-q)/2)^2.
    Мы хотим представить нечетное N в виде A^2 — B^2. Если N % 4 == 1, то легко убедиться, что A должно быть нечетным, а B — четным. А в случае N % 4 == 3 наоборот: A четное, B нечетное.
    Дальше смотрим на N % 3. Если N % 3 == 1, тогда A не кратно 3, B кратно 3. В случае N % 3 == 2 у нас A кратно 3, B не кратно 3.
    И дальше, перебирая остатки N по простым модулям, можем ограничить возможные значения A, B по каждому модулю, и собрать по китайской теореме об остатках возможные значения по модулю произведения простых.
    Например, по модулю 2*3*5*7 будет меньше 25 возможных значений из 210.
    Но это еще не всё! Мы предполагаем, что N — произведение ровно двух простых N = p*q. Тогда из малой теоремы Ферма следует, что для любого x, не кратного p и q, выполняется x^((p-1)*(q-1)/2) % N == 1. Выберем например x = 2. Небольшое преобразование: 2^((N+1)/2) % N == 2^((p+q)/2) % N. Слева известное значение. Справа — неизвестный показатель, то есть свели к дискретному логарифму. Можно использовать небольшую модификацию алгоритма больших и малых шагов. За большой шаг взять произведение маленьких простых, а возможные значения для малых шагов собрать в хеш-таблицу, размер которой мы уменьшили за счет ограничений на (p+q)/2. С таким подходом кажется реальным за несколько минут перебрать значения до abs(p-q) < sqrt((p+q)/2) * 2^64


    1. dragonnur
      07.04.2022 11:55

      Отличное сокращение, да - с розовыми таблицами надо больше памяти, но если всё так упрощается - даже и "простой одноядерный" шуршать будет как тот электровеник. Спасибо вам большое!


  1. rrrav
    06.04.2022 14:55

    А почему нельзя после генерации p и q просто проверить на эту уязвимость и перегенерировать, если пара уязвимая?


    1. agalakhov
      06.04.2022 15:39
      +1

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


      1. Maxim_Q
        06.04.2022 18:58

        Есть програмка или скрипт для проверки сгенерированного RSA ключа на уязвимость?

        Если нет можно хотябы список проблемных программ?


  1. dragonnur
    07.04.2022 07:58

    "Да, могут. Но для этого необходимо, чтобы они были идентичны, по меньшей мере, в своих старших 500 битах. Вероятность такого исхода — 1:2^500"

    Даже это уже не так и много, примерно 10^20. При расчётной скорости перебора 10^9 за секунду ("довольно шустрым, но совершенно одноядерным" алгоритмом) уйдёт 10^11 секунд, 300 лет, а на ядрах чего-то ГПУ-образного всё может случиться в несколько сот (а то и тысяч) раз быстрее.


  1. Soarerru
    07.04.2022 08:43

    Перед Декартом неудобно...