Протоколы распространения ключей на симметричных шифрах

    Данный текст будет являться одной из переписанных глав для учебного пособия по защите информации кафедры радиотехники и систем управления МФТИ (ГУ). Полностью учебник доступен на github (см. также draft releases). На хабре я же планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.

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

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

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


    Варианты сетей без выделенного доверенного центра и с выделенным доверенным центром T

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

    Симметричные протоколы


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

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

    • Alice, Bob — легальные абоненты сети, для которых формируется общий сеансовый ключ. Алиса является инициатором.
    • Trent — доверенный центр сети.
    • $A$, $B$ — некоторые идентификаторы легальных абонентов Алисы и Боба соответственно.
    • $E_A$, $E_B$ — результат шифрования некоторого блока данных с использованием секретных ключей легальных абонентов сети Алисы и Боба соответственно. Такое шифрование могу осуществить либо сами легальные абоненты, либо доверенный центр, которому известны все секретные ключи.
    • $R_A$, $R_B$, $R_T$ — случайные числа, генерируемые Алисой, Бобом и Трентом соответственно.
    • $T_A$, $T_B$, $T_T$ — метки времени, генерируемые Алисой, Бобом и Трентом соответственно.
    • $K$ — секретный сеансовый ключ, получение которого и является одной из целью протоколов.

    Протокол Wide-Mouth Frog


    Протокол Wide-Mouth Frog является, возможно, самым простым протоколом с доверенным центром. Его автором считается Майкл Бэрроуз (1989 год, англ. Michael Burrows). Протокол состоит из следующих шагов.

    1. Алиса генерирует новый сеансовый ключ $K$ и отправляет его вместе с меткой времени, идентификатором Боба и своим незашифрованным идентификатором доверенному центру:

      $ Alice \rightarrow \{ A, E_A \left( T_A, B, K \right) \} \rightarrow Trent $

    2. Доверенный центр, используя полученный незашифрованный идентификатор $A$, находит у себя в базе данных легальных абонентов секретный ключ Алисы и расшифровывает им пакет данных. Проверяет метку времени (что пакет не очень старый). Далее он отправляет похожий пакет данных Бобу, зашифрованный его секретным ключом:

      $ Trent \rightarrow \{ E_B \left( T_T, A, K \right) \} \rightarrow Bob $


      Боб, кроме расшифрования пакета, также проверяет метку времени доверенного центра.


    Схема взаимодействия абонентов и довереного центра в протоколе Wide-Mouth Frog

    По окончании протокола у Алисы и Боба есть общий сеансовый ключ $K$.

    У данного протокола множество недостатков.

    • Генератором ключа является инициирующий абонент. Если предположить, что Боб — это сервер, предоставляющий некоторый сервис, а Алиса — это тонкий клиент, запрашивающий данный сервис, получается, что задача генерации надёжного сессионного ключа взваливается на плечи абонента с наименьшими мощностями.
    • В протоколе общение с вызываемым абонентом происходит через доверенный центр. Как следствие, второй абонент может стать мишенью для DDOS-атаки с отражением (англ. distributed denial-of-service attack), когда злоумышленник будет посылать пакеты на доверенный центр, а тот формировать новые пакеты и посылать их абоненту. Если абонент подключён к нескольким сетям (с несколькими доверенными центрами), это позволит злоумышленнику вывести абонента из строя. Хотя защититься от подобной атаки достаточно просто, настроив соответствующим образом доверенный центр.

    Однако самой серьёзной проблемой протокола является возможность применения следующих атак.

    В 1995 году Рос Андерсон и Роджер Нидхем (англ. Ross Anderson, Roger Needham) предложили вариант атаки на протокол, при котором злоумышленник (Ева) может бесконечно продлевать срок действия конкретного сеансового ключа. Идея атаки в том, что после окончания протокола злоумышленник будет посылать доверенному центру назад его же пакеты, дополняя их идентификаторами якобы инициирующего абонента.

    1. $ Alice \rightarrow \{ A, E_A \left( T_A, B, K \right) \} \rightarrow Trent $
    2. $ Trent \rightarrow \{ E_B \left( T_T, A, K \right) \} \rightarrow Bob $
    3. $ Eva \rightarrow \{ B, E_B \left( T_A, A, K \right) \} \rightarrow Trent $
    4. $ Trent \rightarrow \{ E_A \left( T'_T, B, K \right) \} \rightarrow Alice $
    5. $ Eva \rightarrow \{ A, E_A \left( T'_T, B, K \right) \} \rightarrow Trent $
    6. $ Trent \rightarrow \{ E_B \left( T''_T, A, K \right) \} \rightarrow Bob $
    7. Повторять шаги 3 и 5, пока не пройдёт время, нужное для расшифровки $K$.


    С точки зрения доверенного центра шаги 1, 3 и 5 являются корректными пакетами, инициирующие общение абонентов между собой. Метки времени в них корректны (если Ева будет успевать вовремя эти пакеты посылать). С точки зрения легальных абонентов каждый из пакетов является приглашением другого абонента начать общение. В результате произойдёт две вещи:

    • Каждый из абонентов будет уверен, что закончился протокол создания нового сеансового ключа, что второй абонент успешно аутентифицировал себя перед доверенным центром. И что для установления следующего сеанса связи будет использоваться новый (на самом деле — старый) ключ $K$.
    • После того, как пройдёт время, нужное злоумышленнику Еве для взлома сеансового ключа $K$, Ева сможет и читать всю переписку, проходящую между абонентами, и успешно выдавать себя за обоих из абонентов.

    Вторая атака 1997 года Гэвина Лоу (англ. Gavin Lowe) проще в реализации. В результате этой атаки Боб уверен, что Алиса аутентифицировала себя перед доверенным центром и хочет начать второй сеанс общения. Что, конечно, не является правдой, так как второй сеанс инициирован злоумышленником.

    1. $ Alice \rightarrow \{ A, E_A \left( T_A, B, K \right) \} \rightarrow Trent $
    2. $ Trent \rightarrow \{ E_B \left( T_T, A, K \right) \} \rightarrow Bob $
    3. $ Eva \rightarrow \{ E_B \left( T_T, A, K \right) \} \rightarrow Bob $

    В той же работе Лоу предложил модификацию протокола, вводящую явную взаимную аутентификацию абонентов с помощью случайной метки $R_B$ и проверки, что Алиса может расшифровать пакет с меткой, зашифрованной общим сеансовым ключом абонентов $K$. Однако данная модификация приводит к тому, что протокол теряет своё самое главное преимущество перед другими протоколами — простоту.

    1. $ Alice \rightarrow \{ A, E_A \left( T_A, B, K \right) \} \rightarrow Trent $
    2. $ Trent \rightarrow \{ E_B \left( T_T, A, K \right) \} \rightarrow Bob $
    3. $ Bob \rightarrow \{ E_K \left( R_B \right) \} \rightarrow Alice $
    4. $ Alice \rightarrow \{ E_K \left( R_B + 1 \right) \} \rightarrow Bob $

    Протокол Нидхема—Шрёдера


    Протокол Нидхема—Шрёдера (англ. Roger Needham, Michael Shroeder, 1979 год) похож на модифицированный протокол Wide-Mouth Frog, но отличается тем, что доверенный центр (Трент) во время работы основной части протокола не общается со вторым абонентом. Первый абонент получает от доверенного центра специальный пакет, который он без всякой модификации отправляет второму абоненту.

    1. $ Alice \rightarrow \{ A, B, R_A \} \rightarrow Trent $
    2. $ Trent \rightarrow \{ E_A \left( R_A, B, K, E_B \left( K, A \right) \right) \} \rightarrow Alice $
    3. $ Alice \rightarrow \{ E_B \left( K, A \right) \} \rightarrow Bob $
    4. $ Bob \rightarrow \{ E_K \left( R_B \right) \} \rightarrow Alice $
    5. $ Alice \rightarrow \{ E_K \left( R_B - 1 \right) \} \rightarrow Bob $


    Схема взаимодействия абонентов и довереного центра в протоколе Нидхема—Шрёдера


    Протокол обеспечивает и двустороннюю аутентификацию сторон, и, казалось бы, защиту от атак с повторной передачей (англ. replay attack). Последнее делается с помощью введения уже известных по модифицированному протоколу Wide-Mouth From случайных меток $R_A$ и $R_B$. Действительно, без знания ключа злоумышленник не сможет выдать себя за Алису перед Бобом (так как не сможет расшифровать пакет с зашифрованной меткой $R_B$). Однако, как мы договорились ранее во введении к этой главе, сам сессионный ключ не может считаться надёжным длительное время. Если злоумышленник сумеет в какой-то момент времени получить ранее использованный сессионный ключ $K$, он сможет убедить Боба, что он является Алисой, и что это новый сессионный ключ. Для этого ему понадобится переданный ранее по открытому каналу пакет из пункта 3 протокола.

    1. $ Eva \rightarrow \{ A, B, R_A \} \rightarrow Trent $
    2. $ Trent \rightarrow \{ E_A \left( R_A, B, K, E_B \left( K, A \right) \right) \} \rightarrow Alice $
    3. $ Alice \rightarrow \{ E_B \left( K, A \right) \} \rightarrow Bob $
    4. $ Bob \rightarrow \{ E_K \left( R_B \right) \} \rightarrow Alice $
    5. $ Alice \rightarrow \{ E_K \left( R_B - 1 \right) \} \rightarrow Bob $

      … по прошествии некоторого времени...
    6. $ Eva~(Alice) \rightarrow \{ E_B \left( K, A \right) \} \rightarrow Bob $
    7. $ Bob \rightarrow \{ E_K \left( R_B \right) \} \rightarrow Eva~(Alice) $
    8. $ Eva (Alice) \rightarrow \{ E_K \left( R_B - 1 \right) \} \rightarrow Bob $

    Относительно мелкий недостаток протокола состоит ещё и в том, что во втором пакете доверенный центр в зашифрованном виде передаёт то, что в третьем шаге пересылается по открытому каналу ($E_B \left( K, A \right)$).

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

    Протокол «Kerberos»


    В данном разделе будет описан протокол аутентификации сторон с единственным доверенным центром. Сетевой протокол «Kerberos» использует эти идеи при объединении нескольких доверенных центров в единую сеть для обеспечения надёжности и отказоустойчивости. Подробнее о сетевом протоколе «Kerberos» смотрите в разделе 12.1. «Система Kerberos для локальной сети».

    Как и в протоколе Нидхема—Шрёдера, инициирующий абонент (Алиса) общается только с выделенным доверенным центром, получая от него два пакета с зашифрованным сессионным ключом — один для себя, а второй — для вызываемого абонента (Боба). Однако в отличие от Нидхема—Шрёдера в рассматриваемом протоколе зашифрованные пакеты содержат также метку времени $T_T$ и срок действия сессионного ключа $L$ (от англ. lifetime — срок жизни). Что позволяет, во-первых, защититься от рассмотренной в предыдущем разделе атаки повтором. А, во-вторых, позволяет доверенному центру в некотором смысле управлять абонентами, заставляя их получать новые сессионные ключи по истечению заранее заданного времени $L$.

    1. $ Alice \rightarrow \{ A, B \} \rightarrow Trent $
    2. $ Trent \rightarrow \{ E_A \left( T_T, L, K, B \right), E_B \left( T_T, L, K, A \right) \} \rightarrow Alice $
    3. $ Alice \rightarrow \{ E_B \left( T_T, L, K, A \right), E_K \left( A, T_A \right) \} \rightarrow Bob $
    4. $ Bob \rightarrow \{ E_K \left( T_T + 1 \right) \} \rightarrow Alice $


    Схема взаимодействия абонентов и довереного центра в протоколе «Kerberos»


    Обратите внимание, что третий шаг, за счёт использования метки времени от доверенного центра $T_T$ вместо случайной метки от Боба $R_B$ позволяет сократить протокол на один шаг по сравнению с протоколом Нидхема—Шрёдера. Также наличие метки времени делает ненужным и предварительную генерацию случайной метки Алисой и её передачу на первом шаге.

    Интересно отметить, что пакеты $E_A \left( T_T, L, K, B \right)$ и $E_B \left( T_T, L, K, A \right)$ одинаковы по своему формату. В некотором смысле их можно назвать сертификатами сессионного ключа для Алисы и Боба. Причём все подобные пары пакетов можно сгенерировать заранее (например, в начале дня), выложить на общедоступный ресурс, предоставить в свободное использование и выключить доверенный центр (он своё дело уже сделал — сгенерировав эти пакеты). И до момента времени $T_T + L$ этими «сертификатами» можно пользоваться. Но только если вы являетесь одной из допустимых пар абонентов. Конечно, эта идея непрактична — ведь количество таких пар растёт как квадрат от числа абонентов. Однако интересен тот факт, что подобные пакеты можно сгенерировать заранее. Эта идея нам пригодится при рассмотрении инфраструктуры открытых ключей (public key infrastructure, PKI)).

    (далее идёт рассмотрение протоколов с использованием асимметричного шифрования)

    Послесловие для тех, кто читал Шнайера и Википедию. Данный раздел основан в основном на третьей главе книги «Прикладная криптография» (издание 2002 года), информация из которой была оформлена в виде лекции, которая была прочитана студентам, которые оформили по итогам презентации (и книги, и других источников) статьи в русском разделе Википедии. Информация из статей (например, об атаках) была далее использована в лекциях и в пособии. Интересно, что Шнайер не стал прослеживать связь между отдельными протоколами, хотя с методической точки зрения всегда интересно проследить эволюцию от простого решения (Wide-Mouth Frog) к сложному (Kerberos). С этой же целью из рассмотрения исключен проколол Yaholom. Он хороший — просто не вписывается в «эволюционную» цепочку. А давать его студентам просто ради «ещё один протокол», как мне кажется, неправильно.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 12
    • +2

      В примере атаки написано, что Ева пересылает


      E_B(T_A, A, K)


      В то время как центр пересылает сообщение со своей меткой времени. Либо Ева пересылает сообщение с меткой времени центра, либо Центр пересылает сообщение с меткой времени Алисы.
      
      ПС. Не упомянуты схемы разделения ключей:
      Центр генерирует набор ключей, каждому клиенту предоставляется своя часть набора.
      Информация о правилах определения части является открытой.
      Клиенты генерируют общий ключ, используя знание об общей части набора.
      Например:
      Центр генерирует 9 ключей:
      У Алисы - 1,2,3,4,5,6 ключи.
      У Боба - 1,3,4,6,7,9 ключи.
      Для генерации ключа они используют 1,3,4,6 ключи.
      При этом схема гарантирует, что никто больше не знает сразу все эти 4 ключа.
      • 0
        E_B(T_A, A, K)

        Спасибо, поправил!

        Не упомянуты схемы разделения ключей

        Не могли бы вы описать, как эта схема работает в случае роста числа участников (как Трент выбирает, кому что посылать), или как называется? Есть подозрение, что в этой схеме размер пересылаемых данных должен будет расти с увеличением общего числа абонентов. Следовательно нарушится одно из требований к протоколам.
        • 0

          В схеме количество участников определяется заранее.
          В самом простом случае рекурсивного построения схемы:
          На каждом шаге количество ключей утраивается, а количество участников возводится в квадрат.
          Ключи — Участники
          3 — 3
          9 — 9
          27 — 81
          81 — 6561
          243 — 43 046 721
          729 — 1 853 020 188 851 841
          В последнем примере Центр генерирует 729 2048-битных ключа. Участник получает свой номер и примерно 500 ключей (1МБ). Больше Центр не нужен.

      • 0
        Ужасный перевод, с ошибками, меняющими или искажающими смысл. Не представляю как студенты, ещё не знающие криптографию, будут понимать о чём тут речь.
        Например: Но только если вы являетесь одной из допустимых пар абонентов.
        Ясно же, что не «одной», а единственной. И таких ошибок там ещё несколько.
        • +1
          А можно перечислить? Это не перевод, а оригинальная статья, в ней действительно может быть много стилистических ошибок. Ну не гуманитарии мы :-)
          • 0
            В данном случае все верно — пар допустимых абонентов много. Все легальные абоненты образуют пару — и каждая из этих пар может исопользовать одну соответствующую пару «сертификатов».
          • –4
            Так бестолоково написать о несимметричном кодирование может наверное только программист. )) Не зря же в жизни их называют инопланетянами.

            Помимо того что ты сам разобрался, надо ещё объяснить себе, длЯ чего всё это, и можешь ли ты и умеешь ли ты объяснять другим.

            Судя по этой статье — нет, не умеешь. Хуже того, запутываешь ещё больше… Человек который сам не разобрался ЗАПУТЫВАЕТ остальных.
            Чтобы объяснять сложный материал, надо иметь ОПЫТ работы с материалом и ОПЫТ ОБЪЯСНЕНИЯ сложного материала — от простого к сложному, иногда что-то упуская намеренно, а иногда что-то умышленно искажая (до поры до времени).

            Но для этого надо иметь недюжинный моск, которым автор статьи явно не обладает. Скорее наоборот. Типичный моск программиста.

            Однобокость, типизация, линейность и скудоумие. Отсутствие шуток, непонимание сарказма и юмора в комплекте разумеется ))
            • +3
              Где же Вы здесь увидели «несимметричном кодирование»?
              • +3
                Зря вы переходите на личности и позволяете себе такой тон общения.
                Про ассиметричную криптографию в статье ничего нет и это прямо следует из заголовка статьи.
                Лично мне статья очень понравилась. По-моему, именно так и надо преподавать криптографию. Жду от автора цикла статей.
              • 0
                «Интересно, что Шнайер не стал прослеживать связь между отдельными протоколами».
                Это просто неверно
                • 0
                  Единственное место, где Шнайер пытается исторически или методически связать разные протоколы — это последний абзац в описании протокола Нидхема-Шрёдера (стр. 80), да замечание о том, что базовый протокол Керберос — это вариант протокола Н.-Ш. (стр. 81). Описание остальных протоколов содержит общие слова о плюсах или способах использования, но не сравнение с другими протоколами.
                  • 0
                    Хорошо, он не стал делать детализированное сравнение, но указал на причины разницы в протоколах и к чему она приводит

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