Управление ключами шифрования и информационная безопасность сети

Управление ключами

Разбить на страницы
Показывать лекцию целиком

5.1. Распределение с симметричными ключами

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

Если Алиса должна обмениваться конфиденциальными сообщениями с N людьми, она нуждается в N различных ключах. А что, если N людей должно общаться друг с другом? Тогда необходимое общее количество ключей равно N (N - l). Если мы позволяем Алисе и Бобу использовать два одинаковых ключа для двунаправленной связи для обоих направлений, тогда нужно только N (N - 1)/2 ключей. Это означало бы, что если один миллион человек связывается друг с другом, каждый человек имеет почти один миллион различных ключей. Всего необходим почти один триллион ключей. Это называется N -проблемой, потому что число требуемых ключей для N объектов - N2.

Число ключей - не единственная проблема; распределение ключей - другая беда. Алиса и Боб хотят связаться между собой. Им нужен способ обмена ключами засекречивания. Если Алиса хочет связаться с одним миллионом человек, как она может обменяться одним миллионом ключей с одним миллионом человек? Использование Internet - явно не безопасный метод. Очевидно, что мы нуждаемся в эффективном способе поддерживать и распределять ключи засекречивания.

Центр Распределения Ключей: KDC

Практическое решение - привлечение третьего лица, которому доверяют. Оно называется здесь центром распределения ключей (KDC - Key-Distribution Center). Чтобы уменьшать число ключей, каждый человек устанавливает открытый ключ засекречивания с KDC, как показано на рис. 5.1.

(рис 5.1) Центр распределения ключей (KDC)

Ключ засекречивания установлен между KDC и каждым членом сообщества. Алиса имеет ключ засекречивания с KDC, который мы называем KAlice. Боб имеет ключ засекречивания с KDC, который мы называем KBob. Теперь вопрос - то, как Алиса может передать конфиденциальное сообщение Бобу. Процесс следующий:

  • Алиса передает запрос KDC - заявление, что она нуждается в сеансе (временно) и ключе засекречивания между собой и Бобом.
  • KDC сообщает Бобу о запросе Алисы.
  • Если Боб соглашается, между ними создается ключ сеанса.
    •

    Ключ засекречивания между Алисой и Бобом, который установлен с KDC, используется, чтобы подтвердить подлинность Алисы и Боба к KDC и препятствовать Еве исполнять роль любого из них. Мы обсудим позже в этой лекции, как устанавливается ключ сеанса между Алисой и Бобом.

    Когда число людей, использующих KDC ( Центр распределения ключей ), увеличивается, система становится неуправляемой и срабатывает ее узкое место - число ключей может кончиться. Чтобы решить проблему, мы должны иметь много KDC. Мы можем разделить мир на домены. Каждый домен может иметь один или более KDCs (для резервной избыточности в случае отказа). Теперь, если Алиса хочет передать конфиденциальное сообщение Бобу, который принадлежит к другому домену, она входит в контакт со своим KDC, который, в свою очередь, входит в контакт с KDC в домене Боба. Два KDCs могут создать ключ засекречивания между Алисой и Бобом. рис. 5.2 показывает KDCs, где центры - одного уровня. Мы называем такую организацию центров - "плоское (неиерархическое) множество центров (KDC)".

    (рис 5.2) Плоское (неиерархическое) множество KDC

    Иерархическое множество центров распределения ключей

    Понятие плоского множества KDCs может быть расширено на иерархическую систему KDCs, с одним или более KDCs на верхнем уровне иерархии. Например, может существовать местный KDCs, национальный KDCs и международный KDCs. Когда Алиса должна связаться с Бобом, который живет в другой стране, она передает свой запрос местному KDC; местный KDC ретранслирует запрос к национальному KDC; национальный KDC ретранслирует запрос к международному KDC. Запрос затем транслируется полным путем вниз к местному KDC, где живет Боб. рис. 5.3 показывает конфигурацию иерархического множества KDCs.

    (рис 5.3) Иерархическое множество центров распределения ключей

    Ключи сеанса

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

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

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

    Простой протокол, использующий KDC

    Давайте посмотрим, как KDS может создать сеансовый ключ KAB между Алисой и Бобом. рис. 5.4 показывает предпринимаемые шаги.

    (рис 5.4) Первый метод, использующий KDC
  • Алиса передает сообщение исходного текста KDC, чтобы получить симметричный ключ сеанса между собой и Бобом. Сообщение содержит ее зарегистрированный опознавательный код (слово Алиса или рисунок) и опознавательный код Боба (слово Боб или рисунок). Зашифровано ли сообщение или общедоступно - KDC это не беспокоит.
  • KDC получает сообщение и создает то, что называется билетом. Билет зашифрован с помощью ключа Боба ( КB ). Билет содержит идентификаторы Алисы и Боба и ключ сеанса ( KAB ). Билет с копией ключа сеанса передают Алисе. Алиса получает сообщение, расшифровывает его и извлекает ключ сеанса. Она не может расшифровать билет Боба; билет, предназначенный для Боба, недоступен Алисе. Обратите внимание, что сообщение содержит двойное шифрование: зашифрован билет, а также зашифровано полное сообщение. Во втором сообщении Алиса фактически зарегистрирована в KDC, поэтому только Алиса может открыть целое сообщение, используя свой ключ засекречивания с KDC.
  • Алиса передает билет Бобу. Боб открывает билет и знает, что Алиса должна передать ему сообщение, использующее KAB как ключ сеанса. Обратите внимание, что в этом сообщении Боб зарегистрирован в KDC, поэтому только Боб может открыть билет. Поскольку Боб зарегистрирован в KDC, он также зарегистрирован Алисой, которая доверяет KDC. Тем же самым способом Алиса также зарегистрирована Бобом, потому что Боб доверяет KDC, и KDC передал Бобу билет, который включает опознавательный код Алисы.
    •

    К сожалению, этот простой протокол имеет недостаток. Ева может применить атаку ответа, рассмотренную раньше, - то есть она может сохранить сообщение шага 3 и использовать его позже.

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

    Другой подход - изящный протокол Ниидома-Шрёдера (Needham-Schreder), который является основой многих протоколов. Этот протокол использует множество действий вызова-ответа между сторонами, чтобы достигнуть безупречного протокола. Ниидом и Шрёдер применяют два nonce: RА и RB. рис. 5.5 показывает пять шагов, используемых в этом протоколе. Мы кратко представляем каждый шаг.

  • Алиса передает сообщение KDC, в которое включает свой nonce RА, свой опознавательный код и опознавательный код Боба.
  • KDC передает зашифрованное сообщение Алисы, которое включает nonce Алисы, опознавательный код Боба, ключ сеанса и зашифрованный билет для Боба. Все сообщение зашифровано ключом Алисы.
  • Алиса передает билет Боба ему.
  • Боб передает свой запрос Алисе ( RB ), зашифрованный ключом сеанса.
  • Алиса отвечает на запрос Боба. Обратите внимание, что ответ передается RB - 1 вместо RB.
    •  (рис 5.5) Протокол Ниидома-Шрёдера

    Протокол Отвея-Рисса

    Третий подход - протокол Отвея-Рисса (Otway-Rees) - другой, не менее изящный протокол. рис. 5.6 показывает этот протокол с пятью шагами.

    (рис 5.6) Протокол Отвея - Рииса

    Ниже кратко описываются шаги этого протокола.

  • Алиса передает сообщение Бобу, которое включает nonce R, идентификационные признаки Алисы и Боба и билет для KDC - в билет входят once Алисы RA (свидетельство для пользования KDC), копия общего nonce R и идентификаторы Алисы и Боба.
  • Боб создает тот же самый тип билета, но с собственным его, Боба, nonce RB. Оба билета передают KDC.
  • KDC создает сообщение, которое содержит R, общий nonce, билет для Алисы и билет для Боба; сообщение передают Бобу. Билеты содержат соответствующий once RA или RB и ключ сеанса KAB.
  • Боб передает Алисе ее билет.
  • Алиса передает короткое сообщение, зашифрованное ее сеансовым ключом KAB, чтобы показать, что она имеет ключ сеанса.
    •

    5.2. Цербер

    Цербер - протокол установления подлинности и в то же самое время - KDC, который стал очень популярным. Несколько систем, включая Windows 2000, используют протокол Цербер. Он назван в честь трехголовой собаки в греческой мифологии, которая охраняет ворота царства мертвых Аида. Первоначально разработанный в MIT, он прошел несколько версий. Мы обсудим только самую популярную версию 4, и кратко объясним отличия между версией 4 и версией 5 (последней).

    Серверы

    Протокол Цербер включает в себя работу с тремя серверами: опознавательный сервер (AS - Authentication Server), сервер, предоставляющий билет (TGS - Ticket-Granting Server) и реальный сервер (сервер обработки данных), который обеспечивает услуги. В наших примерах и рисунках Боб - реальный сервер, а Алиса - пользователь, запрашивающий сервер. рис. 5.7 показывает отношения между этими тремя серверами.

    (рис 5.7) Серверы протокола Цербер

    Опознавательный сервер (AS)

    Опознавательный сервер (AS) - в протоколе Цербер - KDC. Каждому пользователю, зарегистрированному в AS, предоставляют пользовательский идентификационный код и пароль. AS имеет базу данных с этими идентификационными кодами и соответствующими паролями. AS верифицирует пользователя, выдает ключ сеанса, который используется между Алисой и TGS, и передает билет для TGS.

    Предоставляющий билет сервер (TGS)

    Предоставляющий билет сервер (TGS) вырабатывает билет для реального сервера (Боба). ОН обеспечивает ключ сеанса ( KAB ) между Алисой и Бобом. Протокол Цербер отделяет верификацию пользователя от выдачи билета.

    Этим способом Алиса проверяет свой ID с AS только один раз. В контакт с TGS она может войти много раз, чтобы получить билеты для различных реальных серверов.

    Реальный сервер

    Реальный сервер (Боб) обеспечивает услуги для пользователя (Алиса). Цербер разработан для взаимодействия с программой "клиент-сервер", такой как, например, протокол передачи файлов FTP (File Transfer Protocol), в котором пользователь использует процесс клиента, чтобы обратиться к процессу сервера. Цербер не используется для установления подлинности "человек-человек".

    Работа

    Процесс клиента (Алиса) может обратиться к процессу, функционирующему на реальном сервере (Боб) в шесть шагов, как это показано на рис. 5.8.

    (рис 5.8) Пример работы Цербера
  • Алиса передает свой запрос AS в открытом тексте, используя свой зарегистрированный код идентификации.
  • AS передает сообщение, зашифрованное постоянным симметричным ключом Алисы, KA. AS-сообщение содержит два объекта: ключ сеанса, KA-TGS, который используется Алисой, чтобы войти в контакт с TGS, и билет для TGS, который зашифрован TGS-симметричным ключом (KAS-TGS). Алиса не знает KA-AS, но когда сообщение прибывает, она печатает (сообщает) свой симметричный пароль. Пароль и соответствующий алгоритм вместе создают KA-AS, если пароль правильный. Пароль затем немедленно уничтожают; его не передают по сети, и он не остается в терминале. Он используется только на мгновение, чтобы создать KA-AS. Процесс теперь использует KA-AS для того, чтобы расшифровывать передаваемое сообщение KA-TGS и извлечь билет.
  • Алиса теперь передает три объекта TGS. Первый - билет, полученный от AS. Второй - имя реального сервера (Боб), третий - метку времени, которая зашифрована ключом KA-TGS. Метка времени предотвращает ложный ответ Евы.
  • Теперь TGS передает два билета: каждый содержит ключ сеанса между Алисой и Бобом, KA-B. Билет для Алисы - зашифрованный KA-TGS , билет для Боба - зашифрованный с ключом Боба KTGS-B. Обратите внимание, что Ева не может извлечь KAB, потому что Ева не знает KA-TGS или KTGS-B.

    Она не может ответить на шаг 3, потому что она не может заменить метку времени новой меткой. Она не знает KA-TGS, и даже если она будет действовать очень быстро и передаст на шаге 3 сообщение прежде, чем истечет метка времени, она все равно получит те же самые два билета, которые она не может расшифровать.

  • Алиса передает билет Боба с меткой времени, зашифрованной ключом KA-B.
  • Боб подтверждает, что получил эту информацию, прибавляя 1 к метке времени. Сообщение шифруется ключом KA-B и передается Алисе.
    •

    Использование различных серверов

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

    Версия 5 Цербер

    Незначительные отличия между версией 4 и версией 5 кратко приведены ниже.

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

    Области применения

    Цербер позволяет глобальное распределение AS и TGS с каждой системой, называемой областью. Пользователь может получить билет для местного сервера или удаленного сервера. Во втором случае, например, Алиса может просить, чтобы ее местный TGS создал ей билет, который мог бы быть принят удаленным TGS. Местный TGS может создать этот билет, если удаленный TGS зарегистрирован в местном TGS, тогда Алиса может использовать удаленный TGS, чтобы обратиться к удаленному реальному серверу.

    5.3. Соглашение с симметричными ключами

    Алиса и Боб могут создать ключ сеанса между собой, не используя KDC. Этот метод создания ключа сеанса называется соглашением с симметричными ключами. Хотя есть несколько способов выполнить этот процесс, здесь рассматриваются только два общих метода ключевого соглашения: Диффи-Хеллмана (Diffie-Hellman) и "станция-к-станции".

    Ключевое соглашение

    В протоколе Диффи-Хеллмана две стороны создают симметричный ключ сеанса без KDC. Перед установлением симметричного ключа эти две стороны должны выбрать два числа p и g. Первое число, p, является большим простым числом порядка 300 десятичных цифр (1024 бита). Второе число, g, служит генератором порядка p - 1 в группе <Zp*, x >. Эти два числа (группа и генератор) не должны быть конфиденциальными. Их можно передать через Internet. Они могут быть общедоступны. рис. 5.9 показывает процедуру.

    Шаги перечислены ниже.

  • Алиса выбирает большое случайное число x, такое, что 0 < x < p - 1, и вычисляет R1 = gx mod p.
  • Боб выбирает другое большое случайное число y, такое, что 0 < y < p - 1, и вычисляет R2 = gy mod p.
  • Алиса передает Бобу R1. Обратите внимание, что Алиса не передает значение x ; она передает только R1.
  • Боб передает Алисе R2. Снова обратите внимание, что Боб не передает значение y, он передает только R2.
  • Алиса вычисляет K = (R2)x mod p.
  • Боб также вычисляет K = (R1)y mod p.

    K = (gx mod p)y mod p = (gymod p)x mod p = gxy mod p

    •

    Боб вычисляет K = (R1)y mod p = (gx mod p)y mod p = gxy mod p

    Алиса вычисляет K = (R2)x mod p = (gy mod p)x mod p = gxy mod p

    и получает то же самое значение без Боба, знающего значение x. А Боб получил это значение без Алисы, знающей значение y.

    (рис 5.9) Метод Диффи-ХелманаСимметричный (общедоступный) ключ в методе Диффи-Хеллмана - K = gxy mod p

    Пример 5.1

    Приведем тривиальный пример, чтобы ясно понять процедуру. Наш пример использует маленькие числа, но заметим, что в реальной ситуации применяются очень большие числа. Предположим, что g = 7 и p = 23. Тогда процедура содержит следующие шаги.

  • Алиса выбирает x = 3 и вычисляет R1 = 73 mod 23 = 21.
  • Боб выбирает y = 6 и вычисляет R2 = 76 mod 23 = 4.
  • Алиса передает число 21 Бобу.
  • Боб передает число 4 Алисе.
  • Алиса вычисляет симметричный ключ K = 43 mod 23 = 18.
  • Боб вычисляет симметричный ключ K = 216 mod 23 = 18.
    •

    Значение K одно и то же и для Алисы, и для Боба: gx y mod p = 718 = 18 .

    Пример 5.2

    Давайте возьмем более реальный пример. Мы используем программу, чтобы создать случайное целое число 512 битов (идеально - 1024 бит). Целое число p - число с 159 цифрами. Мы также выбираем g, x и y, как показано ниже:

    p 764624298563493572182493765955030507476338096726949748923573772860925 235666660755423637423309661180033338106194730130950414738700999178043 6548785807987581
    g 2
    x 557
    y 273

    Следующая таблица показывает R1, R2 и K.

    R1 84492028420 665505216172947491035094143433698520012660862863631067673 619959280828586700802131859290945140217500319973312945836083821943065 966020157955354
    R2 435262838709200379470747114895581627636389116262115557975123379218566 31001143571S208390040181876486841753831165342691630263421106721508589 6255201288594143
    K 155638000664522290596225827523270765273218046944423678520320400146406 500887936651204257426776608327911017153038674561252213151610976584200 1204086433617740

    Анализ протокола Диффи-Хеллмана

    Концепция Диффи-Хеллмана, показанная на рис. 5.10, является простой, но изящной. Мы можем представить ключ засекречивания между Алисой и Бобом - он состоит из трех частей: g, x и y. Первая часть общедоступна. Каждый знает 1/3 ключа - g, общедоступное значение. Другие две части нужно узнать у Алисы и Боба. Каждый из них знает одну часть. Алиса добавляет x как вторую часть для Боба; Боб добавляет y как вторую часть для Алисы. Когда Алиса получает 2/3 полного ключа от Боба, она добавляет последнюю часть, ее y, чтобы завершить ключ. Когда Боб получает ключ от Алисы - законченный на 2/3, он добавляет последнюю часть, свое y, чтобы завершить ключ. Обратите внимание, что хотя ключ Алисы состоит из g, y и x и ключ Боба состоит из g, x и y, эти два ключа - одни и те же, потому что gxy = gyx.

    Обратите внимание также, что хотя два ключа те же самые, Алиса не может найти значение y, используемого Бобом, потому что вычисление сделано по модулю p. Алиса получает gy mod p от Боба, но не gy. Для того чтобы знать значения y, Алиса должна использовать дискретный логарифм, который мы обсуждали в предыдущей лекции.

    Безопасность протокола

    Замена ключа Диффи-Хеллмана восприимчива к двум атакам: атаке дискретного логарифма и атаке посредника (man-in middle)

    Атака дискретного логарифма. Безопасность ключевой станции базируется на трудности проблемы дискретного логарифма. Ева может перехватить R1 и R2.

    (рис 5.10) Идея ключа Диффи-Хеллмана

    Из R1 = gx mod p и y из R2 = gy mod p она может затем вычислить симметричный ключ: K = gxy mod p. Ключ засекречивания больше не является секретным. Чтобы cделать метод Диффи-Хеллмана защищенным от атаки дискретного логарифма, рекомендуется следующее.

  • Простое число p должно быть очень большим (более чем 300 десятичных цифр).
  • Простое число p должно быть выбрано так, чтобы p - 1 имел по крайней мере один простой делитель (больше чем 60 десятичных цифр).
  • Генератор должен быть выбран из группы <Zp*, x >.
  • Боб и Алиса должны уничтожить x и y после того, как они вычислили значение симметричного ключа. Значения x и y должны использоваться только единожды.
    •

    Атака "посредника". Этот протокол имеет другую слабость. Еве не надо находить значения x и y, чтобы напасть на протокол. Она может использовать глупость Алисы и Боба, создающих два ключа: один между Бобом и Алисой и другой между Алисой и Бобом. Рис. 5.11 показывает ситуацию. Может случиться следующее:

    (рис 5.11) Атака посредника
  • Алиса выбирает x , вычисляет R 1 = gx mod p и передает R1 Бобу.
  • Ева, злоумышленник, перехватывает R1. Она выбирает z, вычисляет R 2 = gz mod p и передает R 2 Алисе и Бобу.
  • Боб выбирает y, вычисляет R3 = gy mod p, передает R3 Алисе. Ева перехватывает R3, и Алиса никогда не получит это число.
  • Алиса и Ева вычисляют K1 = gxz mod p, который становится открытым ключом между Алисой и Евой. Алиса, однако, думает, что это -открытый ключ между ней и Бобом.
  • Ева и Боб вычисляют K2 = gzymod p, который становится открытым ключом между Евой и Бобом. Однако Боб думает, что это - открытый ключ между ним Алисой.
    •

    Другими словами, создаются два ключа вместо одного: один между Алисой и Евой и один между Евой и Бобом. Когда Алиса посылает данные Бобу, она зашифровывает их ключом K1 (совместный ключ Алисы и Евы). Эти данные могут быть расшифрованы и прочитаны Евой. Ева может передать сообщение Бобу, зашифрованное K2 (совместный ключ между Евой и Бобом); или она может даже изменить сообщение или передать новое сообщение. Боб введен в заблуждение, поскольку уверен, что сообщение пришло от Алисы. Подобный сценарий может случиться и в другом направлении - с Алисой.

    Эта ситуация называется " атака посредника ", поскольку Ева находится между партнерами и перехватывает R1, передаваемый Алисой Бобу, и R3, передаваемый Бобом Алисой. Это - атака передачи по цепочке, потому что напоминает короткую линейку добровольцев на пожаре, передающих друг другу ведра с водой, по цепочке от человека человеку.

    Следующий метод основан на протоколе Диффи-Хеллмана. Он использует методы установления подлинности, чтобы сорвать эту атаку.

    Ключевое соглашение "от станции к станции"

    Протокол "от станции к станции" - метод, основанный на методе Диффи-Хеллмана. Он применяет цифровые подписи с сертификатами открытого ключа (см. следующую секцию). Для установки ключа сеанса между Алисой и Бобом используется последовательность, показанная на рис. 5.12.

    Имеются следующие шаги:

  • После вычисления R1 Алиса передает R1 Бобу (шаги 1 и 2 на рис. 5.12).
  • После вычисления R2 и ключа сеанса Боб конкатенирует ID Алисы, R1 И R2. Затем он подписывает результат своим секретным ключом. Боб теперь передает R2, подпись и собственное свидетельство общедоступного ключа Алисе. Подпись зашифрована ключом сеанса (шаги 3, 4 и 5 на рис. 5.12).
  • После вычисления ключа сеанса, если подпись Боба проверена, Алиса связывает ID Боба, R1 И R2. Затем она подписывает результат своим собственным секретным ключом и передает это Бобу. Подпись зашифрована ключом сеанса (шаги 6, 7 и 8 на рис. 5.12).
  • Если подпись Алисы проверена, Боб сохраняет ключ сеанса (шаг 9 на рис. 5.12).
    •  (рис 5.12) Метод соглашения "от станции - к станции"

    Безопасность протокола "от станции к станции"

    Протокол "от станции к станции" предотвращает атаки "посредника". После R1 Ева не может передать свой собственный R2 Алисе и притворяться, что это идет от Боба, потому что Ева не может подделать секретный ключ Боба и создать подпись - подпись не может быть проверена общедоступным ключом Боба, определенным в свидетельстве. Тем же образом Ева не может подделать секретный ключ Алисы, чтобы подписать третье сообщение, передаваемое Алисой. Сертификату, как мы увидим в следующей секции, можно доверять, потому что он выработан администрацией, которой доверяют.

    K=(R1)y mod p

    5.4. Распределение открытого ключа

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

    В криптографии общедоступного ключа каждый имеет доступ к общедоступному ключу; общедоступные ключи доступны обществу.

    Общедоступные ключи, подобно секретным ключам, должны быть распределены, чтобы быть полезными. Кратко обсудим способ, которым могут быть распределены общедоступные ключи.

    Общедоступное объявление

    Наивный подход состоит в том, чтобы объявить открытые ключи публично. Боб может поместить свой открытый ключ на своем сайте или объявить его в местной или национальной газете. Когда Алиса должна передать конфиденциальное сообщение Бобу, она может получить открытый ключ Боба из его сайта или из газеты или даже передать сообщение, чтобы попросить его об этом. Рис. 5.13 иллюстрирует такую ситуацию.

    (рис 5.13) Объявление открытых общедоступных ключей

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

    Центр доверия

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

    (рис 5.14) Центр доверия

    Управляемый центр доверия

    Более высокий уровень безопасности может быть достигнут, если добавить управление распределением открытого ключа. При объявлении открытого ключа можно включить в ответ метку времени и подпись администрации, чтобы предотвратить перехват и переделку ответа. Если Алиса хочет знать открытый ключ Боба, она может передать запрос центру, включая в запрос имя Боба и метку времени. Центр отвечает открытым ключом Боба, первоначальным запросом и меткой времени, подписанной секретным ключом центра. Алиса использует открытый ключ известного всем центра и проверяет метку времени. Если метка времени правильная, она извлекает общедоступный ключ Боба. рис. 5.15 показывает один из возможных сценариев.

    (рис 5.15) Управляемый Центр доверия

    Центр сертификации

    Предыдущий подход может породить высокую нагрузку на центр, если число запросов будет большим. Альтернатива этому - создание сертификата(удостоверения) общедоступного ключа. Боб имеет два желания: он хочет, чтобы люди знали его открытый ключ, и он хочет, чтобы никто не сформировал фальшивый открытый ключ, такой же как у него. Боб может обратиться в центр сертификации (CA - Certification Authority) либо в федеральную или общегосударственную организацию, которая связывает открытый ключ с объектом и выдает сертификат. Центр сертификации имеет известный общедоступный ключ, который не может быть фальшивым. Центр сертификации проверяет идентификацию Боба, используя картинку, или ID, или другое доказательство подлинности заявителя, затем запрашивает открытый ключ Боба и подписывает сертификат с секретным ключом. Центр сертификации подписывает свидетельство своим секретным ключом. Теперь Боб может загрузить подписанное свидетельство. Любой, кто хочет иметь открытый ключ Боба, загружает подписанное свидетельство и использует общедоступный ключ центра, чтобы извлечь общедоступный ключ Боба. рис. 5.16 показывает эту концепцию.

    (рис 5.16) Администрация сертификации

    X.509

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

    Чтобы обеспечить универсальность, ITU (МСЭ) разработал рекомендацию X.509 , которая была принята в Internet с некоторыми изменениями. X.509 - способ описать сертификат структурированным способом. Он использует известный протокол, называемый ASN.1 (Abstract Syntax Notation 1 - Нотация абстрактного синтаксиса 1), - он определяет поля, которые знакомы программистам, использующим C.

    Сертификат

    Рис. 5.17 показывает формат сертификата.

    (рис 5.17) Формат сертификата X.509

    Сертификат имеет следующие поля:

  • Номер версии. Это поле определяет версию сертификата X.509.
  • Номер версии начинается отсчитываться с 0; текущая версия (третья версия) - 2.
  • Серийный номер. Это поле определяет число, назначаемое каждому сертификату. Значение этого числа является уникальным для каждого выпускаемого свидетельства.
  • Алгоритм подписи ID. Это поле идентифицирует алгоритм, используемый для подписи сертификата. В этом поле определяется любой параметр, который необходим для подписи.
  • Название выдавшего сертификат. Это поле идентифицирует центра сертификации, который выдал свидетельство. Название - обычно иерархия строк, которые определяют страну, штат, организацию, отдел и так далее.
  • Срок действия. Это поле определяет начальное время (не раньше) и последнее время (не позже), когда сертификат считается действительным.
  • Имя пользователя. Это поле определяет объект, которому принадлежит открытый ключ. Это также иерархия строк. Часть поля определяет то, что называется общим именем, которое является фактическим именем обладателя ключа.
  • Имя общедоступного ключа. Это поле определяет открытый ключ владельца. Это - центральная информация сертификата. Поле также определяет соответствующий алгоритм общедоступного ключа (например, RSA) и его параметры.
  • Уникальный идентификатор выдавшего сертификат. Это дополнительное поле позволяет двум организациям, выдавшим ключ, иметь одно то и же значение поля выдавшего, если уникальные идентификаторы выдавшего различны.
  • Уникальный идентификатор пользователя. Это дополнительное поле позволяет двум различным пользователям иметь одно и то же поле пользователя, если уникальные идентификаторы пользователя различны.
  • Дополнительное расширение формата. Это дополнительное поле позволяет выпускающим прикладывать больше частной информации, дополняющей сертификат.
  • Подпись. Это поле состоит из трех секций. Первая секция содержит все другие поля в сертификате. Вторая содержит дайджест первой секции, зашифрованный с общедоступным ключом сертификационного центра (CA). Третья - идентификатор алгоритма, использованного для создания второй секции.
    •

    Возобновление сертификата

    Каждое свидетельство имеет срок действия. Если нет никаких проблем с сертификатом, Центр сертификации выдает новый сертификат прежде, чем истекает старый. Этот процесс подобен возобновлению кредитных карточек компанией, выпускающей кредитные карточки; держатель кредитной карточки обычно получает возобновленную кредитную карточку прежде, чем срок действия старой истекает.

    Аннулирование сертификата

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

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

    В этом случае центр сертификации должен отменить все неистекшие сертификаты.

    Аннулирование происходит путем периодического выпуска списка аннулированных сертификатов (CRL - certificate revocation). Список содержит все отменяемые сертификаты, срок которых не истек в день выпуска CRL. Когда пользователь хочет использовать сертификат, он сначала должен проверить каталог соответствующего сертификационного Центра, просмотрев последний список аннулирования сертификатов. рис. 5.18 показывает список аннулирования сертификатов.

    (рис 5.18) Формат аннулирования сертификата X.509

    Список аннулирования сертификатов имеет следующие поля:

  • Алгоритм подписи ID. Это поле то же самое, как и в сертификате,
  • Название выдавшего сертификат. Это поле то же самое, как и в сертификате.
  • Дата модификации. Это поле определяет, когда список был выпущен.
  • Дата последнего обновления. Это поле определяет следующую дату, когда будет выпущен новый список.
  • Аннулированный сертификат. Это повторяемый список всех аннулированных сертификатов, у которых не истек срок.

    Каждый список содержит две части: пользовательский серийный номер сертификата и дату аннулирования.

  • Подпись. Это поле такое же, как и в списке сертификатов.
    •

    Аннулирование с помощью дельта-списка

    Чтобы сделать аннулирование более эффективным, был предложен дельта- список аннулирования сертификата (дельта-список CRL - certification list). Дельта CRL создается и размещается в директории, если есть изменения в период, который начинается с даты последнего обновления сертификата до следующей модификации, - например, если CRL вырабатываются каждый месяц, но есть аннулирования между этим датами. Центр сертификации может создать дельта-список CRL, когда есть изменение в течение месяца. Однако дельта CRL содержит только изменения, сделанные после последнего CRL.

    Инфраструктура открытых ключей (PKI)

    Инфраструктура открытых ключей (PKI - Public Key Infrastructures) - модель для создания, распределения и аннулирования сертификатов, основанная на рекомендации X.509. Группа инженерной поддержки сети Интернет (IETF - Internet Engineering Task Force) создала Инфраструктуру общедоступного ключа X.509 (TKIX).

    Режимы работы

    Для PKI были определены несколько режимов работы. Самые важные из них показаны на рис. 5.19.

    (рис 5.19) Некоторые режимы PKI
  • Выпуск, возобновление и аннулирование сертификатов. Эти режимы работы были определены в X.509. Поскольку PKIX базируется на X.509, он должен обработать все режимы работы, имеющие отношение к сертификатам.
  • Хранение и модификация ключей. PKI должен быть местом хранения секретных ключей для тех участников, у которых есть необходимость держать свои секретные ключи где-нибудь в сейфе. В дополнение к этому PKI несет ответственность за обновление этих ключей по запросу участников.
  • Обеспечение услуг другим протоколам. Как мы увидим в следующих немногих лекциях, некоторые протоколы безопасности Internet, такие как IPSec и TLS, базируются на услугах PKI.
  • Обеспечение управления доступом. PKI может обеспечить различные уровни доступа к информации, сохраненной в ее базе данных. Например, организация PKI может обеспечить доступ к полной базе данных для высшего исполнительного руководства, но ограниченный доступ - для служащих.
    •

    Модель доверия

    Невозможно иметь только один центр сертификации, выпускающий все сертификаты для всех пользователей в мире. Должно быть много центров сертификации (CA), каждый - ответственный за создание, сохранение, издание и аннулирование ограниченного числа сертификатов. Модель доверия (Trust Model) определяет правила, которые говорят, как пользователь может проверить сертификат, полученный от Центра Сертификации (CA).

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

    (рис 5.20) Иерархическая модель PKI

    Рисунок показывает, что CA (корень) подписывает сертификаты для CA1, CA2 с CA3; CA1 подписывают сертификаты для Польз.1, Польз. 2, Польз. 3 и так далее. PKI использует особую систему обозначений, которая означает: сертификат выдан администрацией X для объекта Y.

    Пример 5.3

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

    Решение

    Пользователь 3 передает сертификат по цепочке CA "CA1" и CA1 "Польз. 3", к Польз. 3.

  • Польз.1 подтверждает CA "CA1", используя общедоступный ключ CA.
  • Польз.1 извлекает общедоступный ключ CA1 от CA "CA1".
  • Польз.1 подтверждаетCA"Польз. 3", используя общедоступный ключ CA1.
  • Польз.1извлекает общедоступный ключ Польз. 3 из CA "Польз. 3".
    •

    Пример 5.4

    Некоторые Web-браузеры, такие как Netscape и Internet Explorer, содержат множество сертификатов, полученных от независимых Центров сертификации (корней) без единственного корня высокого уровня администрации, который мог бы сертифицировать каждый корень. Можно найти список этих корней в Internet Explorer по следующему маршруту: Инструментальные средства / Опции Интернета / Содержание, Сертификат / Корень доверия (используя "раскрывающиеся строки"). Пользователь тогда может выбрать любой корень и ознакомиться с его сертификатом.

    Модель "каждый с каждым".Иерархическая модель может работать для организации или маленькой группы людей. Большие группы, возможно, нуждаются в нескольких иерархических структурах, соединенных вместе. Один из методов состоит в том, чтобы использовать модель "каждый с каждым" для соединения корней вместе. В этой модели каждый корень связан с каждым другим корнем, как это показано на рис. 5.21.

    (рис 5.21) Модель "каждый с каждым"

    Рис.5.21 показывает, что структура "каждый с каждым" соединяет вместе только корни; каждый корень имеет свою собственную иерархическую структуру, изображенную треугольником. Сертификация между корнями - перекрестные сертификаты; каждый корень сертифицирует все другие корни, что означает, что есть N (N - 1) сертификатов. На рис. 5.21 - 4 узла, так что надо 4 x 3 = 12 удостоверений. Обратите внимание, что каждая линия имеет двойную стрелку и представляет два сертификата.

    Пример 5.5

    Алиса имеет дело с администрацией Root 1; Боб имеет дело с администрацией Root 4. Показать, как Алиса может получить верифицированный общедоступный ключ Боба.

    Решение

    Боб передает цепочку сертификатов от Root 4 к Бобу. Алиса смотрит каталог Root 1, чтобы найти Root 1 сертификаты "Root 1" и Root 1 "Root 4". Используя процесс, показанный на рис. 5.21, Алиса может верифицировать общедоступный ключ Боба.

    Сеть доверия. Эта модель, которая используется в PGP (Pretty Good Privacy - очень хорошая конфиденциальность), службе безопасности для электронной почты, рассматривается в лекции 6.

    5.5. Рекомендованная литература

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

    Книги

    Управление симметричными и асимметричными ключами рассматривается в [Sti06], [KPS02], [Sta06], [Rhe03] и [PHS03].

    Сайты

    Нижеследующие сайты дают больше информации о темах, обсужденных в этой лекции.

  • http://en.wikipedia.org/wiki/Needham-Schroeder
  • http://en.wikipedia.org/wiki/Otway-Rees
  • http://en.wikipedia.org/wiki/Kerbero s_%28protocol%29
  • en.wikipedia.org/wiki/Diffie-Hellman
  • www.ietf.org/rfc/rfc2631 .txt
    •

    5.6. Итоги

  • Для работы в криптографии с симметричными ключами необходимы два общедоступных ключа засекречивания (по одному каждой стороне). Если N людей связались друг с другом, необходимы N (N - 1)/2 ключей. Число ключей - не единственная проблема; другая проблема - это распределение ключей.
  • Практическое решение распределения ключей - использование третьего лица, которому доверяют, называемого Центром распределения ключей (KDC). KDC может создать ключ сеанса (временный) между Алисой и Бобом, используя их ключи связи с центром. Ключи Алисы и Боба используются, чтобы подтвердить центру подлинность Алисы и Боба.
  • Были предложены несколько различных подходов для создания ключей сеанса, которые используют идеи, рассмотренные в лекции 4 для установления подлинности объекта. Два из самых изящных - Протокол Ниидома-Шрёдера, который является основой для многих других протоколов, и Протокол Отвея-Рисса.
  • Цербер является и опознавательным протоколом, и KDC. Несколько систем, включая Windows 2000, используют Цербер. В протоколе Цербер участвуют три сервера: опознавательный сервер (AS) , сервер, предоставляющий билет (TGS), и реальный сервер данных.
  • Алиса и Боб могут создать ключ сеанса между собой, не используя KDC. Этот метод создания ключа сеанса называется соглашением с симметричным ключом. Мы рассмотрели два метода: Диффи-Хеллмана и "от станции к станции". Первый чувствителен к атаке "посредника" ; второй - нет.
  • Открытые ключи, подобно секретным ключам, должны быть распределены для использования. Администрация по сертификации (CA) обеспечивает сертификатами как доказательством собственности общедоступного ключа. X.509 - рекомендация, которая определяет структуру сертификата.
  • Инфраструктура открытого ключа (PKI) - модель для создания, распределения и аннулирования удостоверений, основанных на рекомендации X.509. Группа Инженерной Поддержки Интернет (IETF) создала Инфраструктуру Открытого ключа X.509 (PKIX). Режимы работы PKI включают издание сертификатов, хранение секретного ключа, услуги в соответствии с другими протоколам и управление доступом.
  • PKI также определяет модели доверия, отношения между администрациями, выдающими сертификаты. Три модели доверия, рассмотренные в этой лекции, являются иерархическими, "каждый с каждым", и сетью доверия.
    •

    5.7. Набор для практики

    Обзорные вопросы

  • Перечислите режимы работы KDC.
  • Дайте определение ключа сеанса и покажите, как KDC может создать ключ сеанса между Алисой и Бобом.
  • Дайте определение протокола Цербер и назовите его серверы. Кратко объясните режимы работы каждого сервера.
  • Дайте определение протокола Диффи-Хеллмана и его цель.
  • Дайте определение атаки "посредника".
  • Дайте определение протокола "от станции к станции" и объясните его цель.
  • Дайте определение центра сертификации (CA) и расскажите о его отношении к криптографии общедоступного ключа.
  • Дайте определение рекомендации X.509 и разъясните ее цель.
  • Перечислите режимы работы PKI.
  • Дайте определение модели доверия и рассмотрите некоторые варианты этой модели, которые обсуждались в этой лекции.
    •

    Упражнения

  • На рис. 5.4: что случится, если билет для Боба будет зашифрован не на шаге 2 с ключом KB, но зашифрован вместо этого KAB на шаге 3?
  • Почему нужны четыре nonce в протоколе Ниидома-Шрёдера?
  • Как KDC в протоколе Ниидома-Шрёдера аутентифицирует (удостоверяет) Алису? Как KDC аутентифицирует (удостоверяет) Боба? Как Алиса аутентифицирует (удостоверяет) Боба? Как Боб аутентифицирует (удостоверяет) Алису?
  • Объясните, почему в протоколе Ниидома-Шрёдера Алиса - сторона, которая находится в контакте с KDC, а в протоколе Отвея-Рисса Боб-сторона, которая находится в контакте с KDC.
  • В протоколе Ниидома-Шрёдера есть четыре ( RA, RB, R1 и R2 ), а в протоколе Отвея-Рисса - только три nonce (RA, RB и R). Объясните, почему есть потребность в одном дополнительном nonce R2 в первом протоколе.
  • Почему мы нуждаемся только в одной метке времени в протоколе Цербер вместо четырех nonce, как в протоколе Ниидома-Шрёдера, или трех once, как в протоколе Отвея-Рисса?
  • В протоколе Диффи-Хеллмана g = 7, p = 23, x = 3, и y = 5.
  • Какое значение имеет симметричный ключ?
  • Какие значения имеют R1 и R2?
    •
  • Что случится в протоколе Диффи-Хеллмана,если x и y имеют одно и то же значение, то есть Алиса и Боб случайно выбрали одно и то же число? R1 и R2 те же самые? Ключи сеанса, вычисленные Алисой и Бобом, имеют одно и то же значение? Приведите пример, чтобы доказать ваши выводы.
  • При тривиальной (не гарантирующей безопасность) смене ключа Диффи-Хеллмана p = 53. Найдите соответствующее значение для g.
  • В протоколе "от станции к станции" покажите, что если опознавательный код приемника удален из подписи, протокол становится уязвимым к атаке "посредника".
  • Обсудите заслуживающий доверия корень сертификации, применяющий браузеры.
    • Страницы:

    5.1. Распределение с симметричными ключами

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

    Если Алиса должна обмениваться конфиденциальными сообщениями с N людьми, она нуждается в N различных ключах. А что, если N людей должно общаться друг с другом? Тогда необходимое общее количество ключей равно N (N - l). Если мы позволяем Алисе и Бобу использовать два одинаковых ключа для двунаправленной связи для обоих направлений, тогда нужно только N (N - 1)/2 ключей. Это означало бы, что если один миллион человек связывается друг с другом, каждый человек имеет почти один миллион различных ключей. Всего необходим почти один триллион ключей. Это называется N -проблемой, потому что число требуемых ключей для N объектов - N2.

    Число ключей - не единственная проблема; распределение ключей - другая беда. Алиса и Боб хотят связаться между собой. Им нужен способ обмена ключами засекречивания. Если Алиса хочет связаться с одним миллионом человек, как она может обменяться одним миллионом ключей с одним миллионом человек? Использование Internet - явно не безопасный метод. Очевидно, что мы нуждаемся в эффективном способе поддерживать и распределять ключи засекречивания.

    Центр Распределения Ключей: KDC

    Практическое решение - привлечение третьего лица, которому доверяют. Оно называется здесь центром распределения ключей (KDC - Key-Distribution Center). Чтобы уменьшать число ключей, каждый человек устанавливает открытый ключ засекречивания с KDC, как показано на рис. 5.1.

    (рис 5.1) Центр распределения ключей (KDC)

    Ключ засекречивания установлен между KDC и каждым членом сообщества. Алиса имеет ключ засекречивания с KDC, который мы называем KAlice. Боб имеет ключ засекречивания с KDC, который мы называем KBob. Теперь вопрос - то, как Алиса может передать конфиденциальное сообщение Бобу. Процесс следующий:

  • Алиса передает запрос KDC - заявление, что она нуждается в сеансе (временно) и ключе засекречивания между собой и Бобом.
  • KDC сообщает Бобу о запросе Алисы.
  • Если Боб соглашается, между ними создается ключ сеанса.
    •

    Ключ засекречивания между Алисой и Бобом, который установлен с KDC, используется, чтобы подтвердить подлинность Алисы и Боба к KDC и препятствовать Еве исполнять роль любого из них. Мы обсудим позже в этой лекции, как устанавливается ключ сеанса между Алисой и Бобом.

    Когда число людей, использующих KDC ( Центр распределения ключей ), увеличивается, система становится неуправляемой и срабатывает ее узкое место - число ключей может кончиться. Чтобы решить проблему, мы должны иметь много KDC. Мы можем разделить мир на домены. Каждый домен может иметь один или более KDCs (для резервной избыточности в случае отказа). Теперь, если Алиса хочет передать конфиденциальное сообщение Бобу, который принадлежит к другому домену, она входит в контакт со своим KDC, который, в свою очередь, входит в контакт с KDC в домене Боба. Два KDCs могут создать ключ засекречивания между Алисой и Бобом. рис. 5.2 показывает KDCs, где центры - одного уровня. Мы называем такую организацию центров - "плоское (неиерархическое) множество центров (KDC)".

    (рис 5.2) Плоское (неиерархическое) множество KDC

    Иерархическое множество центров распределения ключей

    Понятие плоского множества KDCs может быть расширено на иерархическую систему KDCs, с одним или более KDCs на верхнем уровне иерархии. Например, может существовать местный KDCs, национальный KDCs и международный KDCs. Когда Алиса должна связаться с Бобом, который живет в другой стране, она передает свой запрос местному KDC; местный KDC ретранслирует запрос к национальному KDC; национальный KDC ретранслирует запрос к международному KDC. Запрос затем транслируется полным путем вниз к местному KDC, где живет Боб. рис. 5.3 показывает конфигурацию иерархического множества KDCs.

    (рис 5.3) Иерархическое множество центров распределения ключей

    Ключи сеанса

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

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

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

    Простой протокол, использующий KDC

    Давайте посмотрим, как KDS может создать сеансовый ключ KAB между Алисой и Бобом. рис. 5.4 показывает предпринимаемые шаги.

    (рис 5.4) Первый метод, использующий KDC
  • Алиса передает сообщение исходного текста KDC, чтобы получить симметричный ключ сеанса между собой и Бобом. Сообщение содержит ее зарегистрированный опознавательный код (слово Алиса или рисунок) и опознавательный код Боба (слово Боб или рисунок). Зашифровано ли сообщение или общедоступно - KDC это не беспокоит.
  • KDC получает сообщение и создает то, что называется билетом. Билет зашифрован с помощью ключа Боба ( КB ). Билет содержит идентификаторы Алисы и Боба и ключ сеанса ( KAB ). Билет с копией ключа сеанса передают Алисе. Алиса получает сообщение, расшифровывает его и извлекает ключ сеанса. Она не может расшифровать билет Боба; билет, предназначенный для Боба, недоступен Алисе. Обратите внимание, что сообщение содержит двойное шифрование: зашифрован билет, а также зашифровано полное сообщение. Во втором сообщении Алиса фактически зарегистрирована в KDC, поэтому только Алиса может открыть целое сообщение, используя свой ключ засекречивания с KDC.
  • Алиса передает билет Бобу. Боб открывает билет и знает, что Алиса должна передать ему сообщение, использующее KAB как ключ сеанса. Обратите внимание, что в этом сообщении Боб зарегистрирован в KDC, поэтому только Боб может открыть билет. Поскольку Боб зарегистрирован в KDC, он также зарегистрирован Алисой, которая доверяет KDC. Тем же самым способом Алиса также зарегистрирована Бобом, потому что Боб доверяет KDC, и KDC передал Бобу билет, который включает опознавательный код Алисы.
    •

    К сожалению, этот простой протокол имеет недостаток. Ева может применить атаку ответа, рассмотренную раньше, - то есть она может сохранить сообщение шага 3 и использовать его позже.

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

    Другой подход - изящный протокол Ниидома-Шрёдера (Needham-Schreder), который является основой многих протоколов. Этот протокол использует множество действий вызова-ответа между сторонами, чтобы достигнуть безупречного протокола. Ниидом и Шрёдер применяют два nonce: RА и RB. рис. 5.5 показывает пять шагов, используемых в этом протоколе. Мы кратко представляем каждый шаг.

  • Алиса передает сообщение KDC, в которое включает свой nonce RА, свой опознавательный код и опознавательный код Боба.
  • KDC передает зашифрованное сообщение Алисы, которое включает nonce Алисы, опознавательный код Боба, ключ сеанса и зашифрованный билет для Боба. Все сообщение зашифровано ключом Алисы.
  • Алиса передает билет Боба ему.
  • Боб передает свой запрос Алисе ( RB ), зашифрованный ключом сеанса.
  • Алиса отвечает на запрос Боба. Обратите внимание, что ответ передается RB - 1 вместо RB.
    •  (рис 5.5) Протокол Ниидома-Шрёдера

    Протокол Отвея-Рисса

    Третий подход - протокол Отвея-Рисса (Otway-Rees) - другой, не менее изящный протокол. рис. 5.6 показывает этот протокол с пятью шагами.

    (рис 5.6) Протокол Отвея - Рииса

    Ниже кратко описываются шаги этого протокола.

  • Алиса передает сообщение Бобу, которое включает nonce R, идентификационные признаки Алисы и Боба и билет для KDC - в билет входят once Алисы RA (свидетельство для пользования KDC), копия общего nonce R и идентификаторы Алисы и Боба.
  • Боб создает тот же самый тип билета, но с собственным его, Боба, nonce RB. Оба билета передают KDC.
  • KDC создает сообщение, которое содержит R, общий nonce, билет для Алисы и билет для Боба; сообщение передают Бобу. Билеты содержат соответствующий once RA или RB и ключ сеанса KAB.
  • Боб передает Алисе ее билет.
  • Алиса передает короткое сообщение, зашифрованное ее сеансовым ключом KAB, чтобы показать, что она имеет ключ сеанса.
    •

    5.2. Цербер

    Цербер - протокол установления подлинности и в то же самое время - KDC, который стал очень популярным. Несколько систем, включая Windows 2000, используют протокол Цербер. Он назван в честь трехголовой собаки в греческой мифологии, которая охраняет ворота царства мертвых Аида. Первоначально разработанный в MIT, он прошел несколько версий. Мы обсудим только самую популярную версию 4, и кратко объясним отличия между версией 4 и версией 5 (последней).

    Серверы

    Протокол Цербер включает в себя работу с тремя серверами: опознавательный сервер (AS - Authentication Server), сервер, предоставляющий билет (TGS - Ticket-Granting Server) и реальный сервер (сервер обработки данных), который обеспечивает услуги. В наших примерах и рисунках Боб - реальный сервер, а Алиса - пользователь, запрашивающий сервер. рис. 5.7 показывает отношения между этими тремя серверами.

    (рис 5.7) Серверы протокола Цербер

    Опознавательный сервер (AS)

    Опознавательный сервер (AS) - в протоколе Цербер - KDC. Каждому пользователю, зарегистрированному в AS, предоставляют пользовательский идентификационный код и пароль. AS имеет базу данных с этими идентификационными кодами и соответствующими паролями. AS верифицирует пользователя, выдает ключ сеанса, который используется между Алисой и TGS, и передает билет для TGS.

    Предоставляющий билет сервер (TGS)

    Предоставляющий билет сервер (TGS) вырабатывает билет для реального сервера (Боба). ОН обеспечивает ключ сеанса ( KAB ) между Алисой и Бобом. Протокол Цербер отделяет верификацию пользователя от выдачи билета.

    Этим способом Алиса проверяет свой ID с AS только один раз. В контакт с TGS она может войти много раз, чтобы получить билеты для различных реальных серверов.

    Реальный сервер

    Реальный сервер (Боб) обеспечивает услуги для пользователя (Алиса). Цербер разработан для взаимодействия с программой "клиент-сервер", такой как, например, протокол передачи файлов FTP (File Transfer Protocol), в котором пользователь использует процесс клиента, чтобы обратиться к процессу сервера. Цербер не используется для установления подлинности "человек-человек".

    Работа

    Процесс клиента (Алиса) может обратиться к процессу, функционирующему на реальном сервере (Боб) в шесть шагов, как это показано на рис. 5.8.

    (рис 5.8) Пример работы Цербера
  • Алиса передает свой запрос AS в открытом тексте, используя свой зарегистрированный код идентификации.
  • AS передает сообщение, зашифрованное постоянным симметричным ключом Алисы, KA. AS-сообщение содержит два объекта: ключ сеанса, KA-TGS, который используется Алисой, чтобы войти в контакт с TGS, и билет для TGS, который зашифрован TGS-симметричным ключом (KAS-TGS). Алиса не знает KA-AS, но когда сообщение прибывает, она печатает (сообщает) свой симметричный пароль. Пароль и соответствующий алгоритм вместе создают KA-AS, если пароль правильный. Пароль затем немедленно уничтожают; его не передают по сети, и он не остается в терминале. Он используется только на мгновение, чтобы создать KA-AS. Процесс теперь использует KA-AS для того, чтобы расшифровывать передаваемое сообщение KA-TGS и извлечь билет.
  • Алиса теперь передает три объекта TGS. Первый - билет, полученный от AS. Второй - имя реального сервера (Боб), третий - метку времени, которая зашифрована ключом KA-TGS. Метка времени предотвращает ложный ответ Евы.
  • Теперь TGS передает два билета: каждый содержит ключ сеанса между Алисой и Бобом, KA-B. Билет для Алисы - зашифрованный KA-TGS , билет для Боба - зашифрованный с ключом Боба KTGS-B. Обратите внимание, что Ева не может извлечь KAB, потому что Ева не знает KA-TGS или KTGS-B.

    Она не может ответить на шаг 3, потому что она не может заменить метку времени новой меткой. Она не знает KA-TGS, и даже если она будет действовать очень быстро и передаст на шаге 3 сообщение прежде, чем истечет метка времени, она все равно получит те же самые два билета, которые она не может расшифровать.

  • Алиса передает билет Боба с меткой времени, зашифрованной ключом KA-B.
  • Боб подтверждает, что получил эту информацию, прибавляя 1 к метке времени. Сообщение шифруется ключом KA-B и передается Алисе.
    •

    Использование различных серверов

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

    Версия 5 Цербер

    Незначительные отличия между версией 4 и версией 5 кратко приведены ниже.

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

    Области применения

    Цербер позволяет глобальное распределение AS и TGS с каждой системой, называемой областью. Пользователь может получить билет для местного сервера или удаленного сервера. Во втором случае, например, Алиса может просить, чтобы ее местный TGS создал ей билет, который мог бы быть принят удаленным TGS. Местный TGS может создать этот билет, если удаленный TGS зарегистрирован в местном TGS, тогда Алиса может использовать удаленный TGS, чтобы обратиться к удаленному реальному серверу.

    5.3. Соглашение с симметричными ключами

    Алиса и Боб могут создать ключ сеанса между собой, не используя KDC. Этот метод создания ключа сеанса называется соглашением с симметричными ключами. Хотя есть несколько способов выполнить этот процесс, здесь рассматриваются только два общих метода ключевого соглашения: Диффи-Хеллмана (Diffie-Hellman) и "станция-к-станции".

    Ключевое соглашение

    В протоколе Диффи-Хеллмана две стороны создают симметричный ключ сеанса без KDC. Перед установлением симметричного ключа эти две стороны должны выбрать два числа p и g. Первое число, p, является большим простым числом порядка 300 десятичных цифр (1024 бита). Второе число, g, служит генератором порядка p - 1 в группе <Zp*, x >. Эти два числа (группа и генератор) не должны быть конфиденциальными. Их можно передать через Internet. Они могут быть общедоступны. рис. 5.9 показывает процедуру.

    Шаги перечислены ниже.

  • Алиса выбирает большое случайное число x, такое, что 0 < x < p - 1, и вычисляет R1 = gx mod p.
  • Боб выбирает другое большое случайное число y, такое, что 0 < y < p - 1, и вычисляет R2 = gy mod p.
  • Алиса передает Бобу R1. Обратите внимание, что Алиса не передает значение x ; она передает только R1.
  • Боб передает Алисе R2. Снова обратите внимание, что Боб не передает значение y, он передает только R2.
  • Алиса вычисляет K = (R2)x mod p.
  • Боб также вычисляет K = (R1)y mod p.

    K = (gx mod p)y mod p = (gymod p)x mod p = gxy mod p

    •

    Боб вычисляет K = (R1)y mod p = (gx mod p)y mod p = gxy mod p

    Алиса вычисляет K = (R2)x mod p = (gy mod p)x mod p = gxy mod p

    и получает то же самое значение без Боба, знающего значение x. А Боб получил это значение без Алисы, знающей значение y.

    (рис 5.9) Метод Диффи-ХелманаСимметричный (общедоступный) ключ в методе Диффи-Хеллмана - K = gxy mod p

    Пример 5.1

    Приведем тривиальный пример, чтобы ясно понять процедуру. Наш пример использует маленькие числа, но заметим, что в реальной ситуации применяются очень большие числа. Предположим, что g = 7 и p = 23. Тогда процедура содержит следующие шаги.

  • Алиса выбирает x = 3 и вычисляет R1 = 73 mod 23 = 21.
  • Боб выбирает y = 6 и вычисляет R2 = 76 mod 23 = 4.
  • Алиса передает число 21 Бобу.
  • Боб передает число 4 Алисе.
  • Алиса вычисляет симметричный ключ K = 43 mod 23 = 18.
  • Боб вычисляет симметричный ключ K = 216 mod 23 = 18.
    •

    Значение K одно и то же и для Алисы, и для Боба: gx y mod p = 718 = 18 .

    Пример 5.2

    Давайте возьмем более реальный пример. Мы используем программу, чтобы создать случайное целое число 512 битов (идеально - 1024 бит). Целое число p - число с 159 цифрами. Мы также выбираем g, x и y, как показано ниже:

    p 764624298563493572182493765955030507476338096726949748923573772860925 235666660755423637423309661180033338106194730130950414738700999178043 6548785807987581
    g 2
    x 557
    y 273

    Следующая таблица показывает R1, R2 и K.

    R1 84492028420 665505216172947491035094143433698520012660862863631067673 619959280828586700802131859290945140217500319973312945836083821943065 966020157955354
    R2 435262838709200379470747114895581627636389116262115557975123379218566 31001143571S208390040181876486841753831165342691630263421106721508589 6255201288594143
    K 155638000664522290596225827523270765273218046944423678520320400146406 500887936651204257426776608327911017153038674561252213151610976584200 1204086433617740

    Анализ протокола Диффи-Хеллмана

    Концепция Диффи-Хеллмана, показанная на рис. 5.10, является простой, но изящной. Мы можем представить ключ засекречивания между Алисой и Бобом - он состоит из трех частей: g, x и y. Первая часть общедоступна. Каждый знает 1/3 ключа - g, общедоступное значение. Другие две части нужно узнать у Алисы и Боба. Каждый из них знает одну часть. Алиса добавляет x как вторую часть для Боба; Боб добавляет y как вторую часть для Алисы. Когда Алиса получает 2/3 полного ключа от Боба, она добавляет последнюю часть, ее y, чтобы завершить ключ. Когда Боб получает ключ от Алисы - законченный на 2/3, он добавляет последнюю часть, свое y, чтобы завершить ключ. Обратите внимание, что хотя ключ Алисы состоит из g, y и x и ключ Боба состоит из g, x и y, эти два ключа - одни и те же, потому что gxy = gyx.

    Обратите внимание также, что хотя два ключа те же самые, Алиса не может найти значение y, используемого Бобом, потому что вычисление сделано по модулю p. Алиса получает gy mod p от Боба, но не gy. Для того чтобы знать значения y, Алиса должна использовать дискретный логарифм, который мы обсуждали в предыдущей лекции.

    Безопасность протокола

    Замена ключа Диффи-Хеллмана восприимчива к двум атакам: атаке дискретного логарифма и атаке посредника (man-in middle)

    Атака дискретного логарифма. Безопасность ключевой станции базируется на трудности проблемы дискретного логарифма. Ева может перехватить R1 и R2.

    (рис 5.10) Идея ключа Диффи-Хеллмана

    Из R1 = gx mod p и y из R2 = gy mod p она может затем вычислить симметричный ключ: K = gxy mod p. Ключ засекречивания больше не является секретным. Чтобы cделать метод Диффи-Хеллмана защищенным от атаки дискретного логарифма, рекомендуется следующее.

  • Простое число p должно быть очень большим (более чем 300 десятичных цифр).
  • Простое число p должно быть выбрано так, чтобы p - 1 имел по крайней мере один простой делитель (больше чем 60 десятичных цифр).
  • Генератор должен быть выбран из группы <Zp*, x >.
  • Боб и Алиса должны уничтожить x и y после того, как они вычислили значение симметричного ключа. Значения x и y должны использоваться только единожды.
    •

    Атака "посредника". Этот протокол имеет другую слабость. Еве не надо находить значения x и y, чтобы напасть на протокол. Она может использовать глупость Алисы и Боба, создающих два ключа: один между Бобом и Алисой и другой между Алисой и Бобом. Рис. 5.11 показывает ситуацию. Может случиться следующее:

    (рис 5.11) Атака посредника
  • Алиса выбирает x , вычисляет R 1 = gx mod p и передает R1 Бобу.
  • Ева, злоумышленник, перехватывает R1. Она выбирает z, вычисляет R 2 = gz mod p и передает R 2 Алисе и Бобу.
  • Боб выбирает y, вычисляет R3 = gy mod p, передает R3 Алисе. Ева перехватывает R3, и Алиса никогда не получит это число.
  • Алиса и Ева вычисляют K1 = gxz mod p, который становится открытым ключом между Алисой и Евой. Алиса, однако, думает, что это -открытый ключ между ней и Бобом.
  • Ева и Боб вычисляют K2 = gzymod p, который становится открытым ключом между Евой и Бобом. Однако Боб думает, что это - открытый ключ между ним Алисой.
    •

    Другими словами, создаются два ключа вместо одного: один между Алисой и Евой и один между Евой и Бобом. Когда Алиса посылает данные Бобу, она зашифровывает их ключом K1 (совместный ключ Алисы и Евы). Эти данные могут быть расшифрованы и прочитаны Евой. Ева может передать сообщение Бобу, зашифрованное K2 (совместный ключ между Евой и Бобом); или она может даже изменить сообщение или передать новое сообщение. Боб введен в заблуждение, поскольку уверен, что сообщение пришло от Алисы. Подобный сценарий может случиться и в другом направлении - с Алисой.

    Эта ситуация называется " атака посредника ", поскольку Ева находится между партнерами и перехватывает R1, передаваемый Алисой Бобу, и R3, передаваемый Бобом Алисой. Это - атака передачи по цепочке, потому что напоминает короткую линейку добровольцев на пожаре, передающих друг другу ведра с водой, по цепочке от человека человеку.

    Следующий метод основан на протоколе Диффи-Хеллмана. Он использует методы установления подлинности, чтобы сорвать эту атаку.

    Ключевое соглашение "от станции к станции"

    Протокол "от станции к станции" - метод, основанный на методе Диффи-Хеллмана. Он применяет цифровые подписи с сертификатами открытого ключа (см. следующую секцию). Для установки ключа сеанса между Алисой и Бобом используется последовательность, показанная на рис. 5.12.

    Имеются следующие шаги:

  • После вычисления R1 Алиса передает R1 Бобу (шаги 1 и 2 на рис. 5.12).
  • После вычисления R2 и ключа сеанса Боб конкатенирует ID Алисы, R1 И R2. Затем он подписывает результат своим секретным ключом. Боб теперь передает R2, подпись и собственное свидетельство общедоступного ключа Алисе. Подпись зашифрована ключом сеанса (шаги 3, 4 и 5 на рис. 5.12).
  • После вычисления ключа сеанса, если подпись Боба проверена, Алиса связывает ID Боба, R1 И R2. Затем она подписывает результат своим собственным секретным ключом и передает это Бобу. Подпись зашифрована ключом сеанса (шаги 6, 7 и 8 на рис. 5.12).
  • Если подпись Алисы проверена, Боб сохраняет ключ сеанса (шаг 9 на рис. 5.12).
    •  (рис 5.12) Метод соглашения "от станции - к станции"

    Безопасность протокола "от станции к станции"

    Протокол "от станции к станции" предотвращает атаки "посредника". После R1 Ева не может передать свой собственный R2 Алисе и притворяться, что это идет от Боба, потому что Ева не может подделать секретный ключ Боба и создать подпись - подпись не может быть проверена общедоступным ключом Боба, определенным в свидетельстве. Тем же образом Ева не может подделать секретный ключ Алисы, чтобы подписать третье сообщение, передаваемое Алисой. Сертификату, как мы увидим в следующей секции, можно доверять, потому что он выработан администрацией, которой доверяют.

    K=(R1)y mod p

    5.4. Распределение открытого ключа

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

    В криптографии общедоступного ключа каждый имеет доступ к общедоступному ключу; общедоступные ключи доступны обществу.

    Общедоступные ключи, подобно секретным ключам, должны быть распределены, чтобы быть полезными. Кратко обсудим способ, которым могут быть распределены общедоступные ключи.

    Общедоступное объявление

    Наивный подход состоит в том, чтобы объявить открытые ключи публично. Боб может поместить свой открытый ключ на своем сайте или объявить его в местной или национальной газете. Когда Алиса должна передать конфиденциальное сообщение Бобу, она может получить открытый ключ Боба из его сайта или из газеты или даже передать сообщение, чтобы попросить его об этом. Рис. 5.13 иллюстрирует такую ситуацию.

    (рис 5.13) Объявление открытых общедоступных ключей

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

    Центр доверия

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

    (рис 5.14) Центр доверия

    Управляемый центр доверия

    Более высокий уровень безопасности может быть достигнут, если добавить управление распределением открытого ключа. При объявлении открытого ключа можно включить в ответ метку времени и подпись администрации, чтобы предотвратить перехват и переделку ответа. Если Алиса хочет знать открытый ключ Боба, она может передать запрос центру, включая в запрос имя Боба и метку времени. Центр отвечает открытым ключом Боба, первоначальным запросом и меткой времени, подписанной секретным ключом центра. Алиса использует открытый ключ известного всем центра и проверяет метку времени. Если метка времени правильная, она извлекает общедоступный ключ Боба. рис. 5.15 показывает один из возможных сценариев.

    (рис 5.15) Управляемый Центр доверия

    Центр сертификации

    Предыдущий подход может породить высокую нагрузку на центр, если число запросов будет большим. Альтернатива этому - создание сертификата(удостоверения) общедоступного ключа. Боб имеет два желания: он хочет, чтобы люди знали его открытый ключ, и он хочет, чтобы никто не сформировал фальшивый открытый ключ, такой же как у него. Боб может обратиться в центр сертификации (CA - Certification Authority) либо в федеральную или общегосударственную организацию, которая связывает открытый ключ с объектом и выдает сертификат. Центр сертификации имеет известный общедоступный ключ, который не может быть фальшивым. Центр сертификации проверяет идентификацию Боба, используя картинку, или ID, или другое доказательство подлинности заявителя, затем запрашивает открытый ключ Боба и подписывает сертификат с секретным ключом. Центр сертификации подписывает свидетельство своим секретным ключом. Теперь Боб может загрузить подписанное свидетельство. Любой, кто хочет иметь открытый ключ Боба, загружает подписанное свидетельство и использует общедоступный ключ центра, чтобы извлечь общедоступный ключ Боба. рис. 5.16 показывает эту концепцию.

    (рис 5.16) Администрация сертификации

    X.509

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

    Чтобы обеспечить универсальность, ITU (МСЭ) разработал рекомендацию X.509 , которая была принята в Internet с некоторыми изменениями. X.509 - способ описать сертификат структурированным способом. Он использует известный протокол, называемый ASN.1 (Abstract Syntax Notation 1 - Нотация абстрактного синтаксиса 1), - он определяет поля, которые знакомы программистам, использующим C.

    Сертификат

    Рис. 5.17 показывает формат сертификата.

    (рис 5.17) Формат сертификата X.509

    Сертификат имеет следующие поля:

  • Номер версии. Это поле определяет версию сертификата X.509.
  • Номер версии начинается отсчитываться с 0; текущая версия (третья версия) - 2.
  • Серийный номер. Это поле определяет число, назначаемое каждому сертификату. Значение этого числа является уникальным для каждого выпускаемого свидетельства.
  • Алгоритм подписи ID. Это поле идентифицирует алгоритм, используемый для подписи сертификата. В этом поле определяется любой параметр, который необходим для подписи.
  • Название выдавшего сертификат. Это поле идентифицирует центра сертификации, который выдал свидетельство. Название - обычно иерархия строк, которые определяют страну, штат, организацию, отдел и так далее.
  • Срок действия. Это поле определяет начальное время (не раньше) и последнее время (не позже), когда сертификат считается действительным.
  • Имя пользователя. Это поле определяет объект, которому принадлежит открытый ключ. Это также иерархия строк. Часть поля определяет то, что называется общим именем, которое является фактическим именем обладателя ключа.
  • Имя общедоступного ключа. Это поле определяет открытый ключ владельца. Это - центральная информация сертификата. Поле также определяет соответствующий алгоритм общедоступного ключа (например, RSA) и его параметры.
  • Уникальный идентификатор выдавшего сертификат. Это дополнительное поле позволяет двум организациям, выдавшим ключ, иметь одно то и же значение поля выдавшего, если уникальные идентификаторы выдавшего различны.
  • Уникальный идентификатор пользователя. Это дополнительное поле позволяет двум различным пользователям иметь одно и то же поле пользователя, если уникальные идентификаторы пользователя различны.
  • Дополнительное расширение формата. Это дополнительное поле позволяет выпускающим прикладывать больше частной информации, дополняющей сертификат.
  • Подпись. Это поле состоит из трех секций. Первая секция содержит все другие поля в сертификате. Вторая содержит дайджест первой секции, зашифрованный с общедоступным ключом сертификационного центра (CA). Третья - идентификатор алгоритма, использованного для создания второй секции.
    •

    Возобновление сертификата

    Каждое свидетельство имеет срок действия. Если нет никаких проблем с сертификатом, Центр сертификации выдает новый сертификат прежде, чем истекает старый. Этот процесс подобен возобновлению кредитных карточек компанией, выпускающей кредитные карточки; держатель кредитной карточки обычно получает возобновленную кредитную карточку прежде, чем срок действия старой истекает.

    Аннулирование сертификата

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

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

    В этом случае центр сертификации должен отменить все неистекшие сертификаты.

    Аннулирование происходит путем периодического выпуска списка аннулированных сертификатов (CRL - certificate revocation). Список содержит все отменяемые сертификаты, срок которых не истек в день выпуска CRL. Когда пользователь хочет использовать сертификат, он сначала должен проверить каталог соответствующего сертификационного Центра, просмотрев последний список аннулирования сертификатов. рис. 5.18 показывает список аннулирования сертификатов.

    (рис 5.18) Формат аннулирования сертификата X.509

    Список аннулирования сертификатов имеет следующие поля:

  • Алгоритм подписи ID. Это поле то же самое, как и в сертификате,
  • Название выдавшего сертификат. Это поле то же самое, как и в сертификате.
  • Дата модификации. Это поле определяет, когда список был выпущен.
  • Дата последнего обновления. Это поле определяет следующую дату, когда будет выпущен новый список.
  • Аннулированный сертификат. Это повторяемый список всех аннулированных сертификатов, у которых не истек срок.

    Каждый список содержит две части: пользовательский серийный номер сертификата и дату аннулирования.

  • Подпись. Это поле такое же, как и в списке сертификатов.
    •

    Аннулирование с помощью дельта-списка

    Чтобы сделать аннулирование более эффективным, был предложен дельта- список аннулирования сертификата (дельта-список CRL - certification list). Дельта CRL создается и размещается в директории, если есть изменения в период, который начинается с даты последнего обновления сертификата до следующей модификации, - например, если CRL вырабатываются каждый месяц, но есть аннулирования между этим датами. Центр сертификации может создать дельта-список CRL, когда есть изменение в течение месяца. Однако дельта CRL содержит только изменения, сделанные после последнего CRL.

    Инфраструктура открытых ключей (PKI)

    Инфраструктура открытых ключей (PKI - Public Key Infrastructures) - модель для создания, распределения и аннулирования сертификатов, основанная на рекомендации X.509. Группа инженерной поддержки сети Интернет (IETF - Internet Engineering Task Force) создала Инфраструктуру общедоступного ключа X.509 (TKIX).

    Режимы работы

    Для PKI были определены несколько режимов работы. Самые важные из них показаны на рис. 5.19.

    (рис 5.19) Некоторые режимы PKI
  • Выпуск, возобновление и аннулирование сертификатов. Эти режимы работы были определены в X.509. Поскольку PKIX базируется на X.509, он должен обработать все режимы работы, имеющие отношение к сертификатам.
  • Хранение и модификация ключей. PKI должен быть местом хранения секретных ключей для тех участников, у которых есть необходимость держать свои секретные ключи где-нибудь в сейфе. В дополнение к этому PKI несет ответственность за обновление этих ключей по запросу участников.
  • Обеспечение услуг другим протоколам. Как мы увидим в следующих немногих лекциях, некоторые протоколы безопасности Internet, такие как IPSec и TLS, базируются на услугах PKI.
  • Обеспечение управления доступом. PKI может обеспечить различные уровни доступа к информации, сохраненной в ее базе данных. Например, организация PKI может обеспечить доступ к полной базе данных для высшего исполнительного руководства, но ограниченный доступ - для служащих.
    •

    Модель доверия

    Невозможно иметь только один центр сертификации, выпускающий все сертификаты для всех пользователей в мире. Должно быть много центров сертификации (CA), каждый - ответственный за создание, сохранение, издание и аннулирование ограниченного числа сертификатов. Модель доверия (Trust Model) определяет правила, которые говорят, как пользователь может проверить сертификат, полученный от Центра Сертификации (CA).

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

    (рис 5.20) Иерархическая модель PKI

    Рисунок показывает, что CA (корень) подписывает сертификаты для CA1, CA2 с CA3; CA1 подписывают сертификаты для Польз.1, Польз. 2, Польз. 3 и так далее. PKI использует особую систему обозначений, которая означает: сертификат выдан администрацией X для объекта Y.

    Пример 5.3

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

    Решение

    Пользователь 3 передает сертификат по цепочке CA "CA1" и CA1 "Польз. 3", к Польз. 3.

  • Польз.1 подтверждает CA "CA1", используя общедоступный ключ CA.
  • Польз.1 извлекает общедоступный ключ CA1 от CA "CA1".
  • Польз.1 подтверждаетCA"Польз. 3", используя общедоступный ключ CA1.
  • Польз.1извлекает общедоступный ключ Польз. 3 из CA "Польз. 3".
    •

    Пример 5.4

    Некоторые Web-браузеры, такие как Netscape и Internet Explorer, содержат множество сертификатов, полученных от независимых Центров сертификации (корней) без единственного корня высокого уровня администрации, который мог бы сертифицировать каждый корень. Можно найти список этих корней в Internet Explorer по следующему маршруту: Инструментальные средства / Опции Интернета / Содержание, Сертификат / Корень доверия (используя "раскрывающиеся строки"). Пользователь тогда может выбрать любой корень и ознакомиться с его сертификатом.

    Модель "каждый с каждым".Иерархическая модель может работать для организации или маленькой группы людей. Большие группы, возможно, нуждаются в нескольких иерархических структурах, соединенных вместе. Один из методов состоит в том, чтобы использовать модель "каждый с каждым" для соединения корней вместе. В этой модели каждый корень связан с каждым другим корнем, как это показано на рис. 5.21.

    (рис 5.21) Модель "каждый с каждым"

    Рис.5.21 показывает, что структура "каждый с каждым" соединяет вместе только корни; каждый корень имеет свою собственную иерархическую структуру, изображенную треугольником. Сертификация между корнями - перекрестные сертификаты; каждый корень сертифицирует все другие корни, что означает, что есть N (N - 1) сертификатов. На рис. 5.21 - 4 узла, так что надо 4 x 3 = 12 удостоверений. Обратите внимание, что каждая линия имеет двойную стрелку и представляет два сертификата.

    Пример 5.5

    Алиса имеет дело с администрацией Root 1; Боб имеет дело с администрацией Root 4. Показать, как Алиса может получить верифицированный общедоступный ключ Боба.

    Решение

    Боб передает цепочку сертификатов от Root 4 к Бобу. Алиса смотрит каталог Root 1, чтобы найти Root 1 сертификаты "Root 1" и Root 1 "Root 4". Используя процесс, показанный на рис. 5.21, Алиса может верифицировать общедоступный ключ Боба.

    Сеть доверия. Эта модель, которая используется в PGP (Pretty Good Privacy - очень хорошая конфиденциальность), службе безопасности для электронной почты, рассматривается в лекции 6.

    5.5. Рекомендованная литература

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

    Книги

    Управление симметричными и асимметричными ключами рассматривается в [Sti06], [KPS02], [Sta06], [Rhe03] и [PHS03].

    Сайты

    Нижеследующие сайты дают больше информации о темах, обсужденных в этой лекции.

  • http://en.wikipedia.org/wiki/Needham-Schroeder
  • http://en.wikipedia.org/wiki/Otway-Rees
  • http://en.wikipedia.org/wiki/Kerbero s_%28protocol%29
  • en.wikipedia.org/wiki/Diffie-Hellman
  • www.ietf.org/rfc/rfc2631 .txt
    •

    5.6. Итоги

  • Для работы в криптографии с симметричными ключами необходимы два общедоступных ключа засекречивания (по одному каждой стороне). Если N людей связались друг с другом, необходимы N (N - 1)/2 ключей. Число ключей - не единственная проблема; другая проблема - это распределение ключей.
  • Практическое решение распределения ключей - использование третьего лица, которому доверяют, называемого Центром распределения ключей (KDC). KDC может создать ключ сеанса (временный) между Алисой и Бобом, используя их ключи связи с центром. Ключи Алисы и Боба используются, чтобы подтвердить центру подлинность Алисы и Боба.
  • Были предложены несколько различных подходов для создания ключей сеанса, которые используют идеи, рассмотренные в лекции 4 для установления подлинности объекта. Два из самых изящных - Протокол Ниидома-Шрёдера, который является основой для многих других протоколов, и Протокол Отвея-Рисса.
  • Цербер является и опознавательным протоколом, и KDC. Несколько систем, включая Windows 2000, используют Цербер. В протоколе Цербер участвуют три сервера: опознавательный сервер (AS) , сервер, предоставляющий билет (TGS), и реальный сервер данных.
  • Алиса и Боб могут создать ключ сеанса между собой, не используя KDC. Этот метод создания ключа сеанса называется соглашением с симметричным ключом. Мы рассмотрели два метода: Диффи-Хеллмана и "от станции к станции". Первый чувствителен к атаке "посредника" ; второй - нет.
  • Открытые ключи, подобно секретным ключам, должны быть распределены для использования. Администрация по сертификации (CA) обеспечивает сертификатами как доказательством собственности общедоступного ключа. X.509 - рекомендация, которая определяет структуру сертификата.
  • Инфраструктура открытого ключа (PKI) - модель для создания, распределения и аннулирования удостоверений, основанных на рекомендации X.509. Группа Инженерной Поддержки Интернет (IETF) создала Инфраструктуру Открытого ключа X.509 (PKIX). Режимы работы PKI включают издание сертификатов, хранение секретного ключа, услуги в соответствии с другими протоколам и управление доступом.
  • PKI также определяет модели доверия, отношения между администрациями, выдающими сертификаты. Три модели доверия, рассмотренные в этой лекции, являются иерархическими, "каждый с каждым", и сетью доверия.
    •

    5.7. Набор для практики

    Обзорные вопросы

  • Перечислите режимы работы KDC.
  • Дайте определение ключа сеанса и покажите, как KDC может создать ключ сеанса между Алисой и Бобом.
  • Дайте определение протокола Цербер и назовите его серверы. Кратко объясните режимы работы каждого сервера.
  • Дайте определение протокола Диффи-Хеллмана и его цель.
  • Дайте определение атаки "посредника".
  • Дайте определение протокола "от станции к станции" и объясните его цель.
  • Дайте определение центра сертификации (CA) и расскажите о его отношении к криптографии общедоступного ключа.
  • Дайте определение рекомендации X.509 и разъясните ее цель.
  • Перечислите режимы работы PKI.
  • Дайте определение модели доверия и рассмотрите некоторые варианты этой модели, которые обсуждались в этой лекции.
    •

    Упражнения

  • На рис. 5.4: что случится, если билет для Боба будет зашифрован не на шаге 2 с ключом KB, но зашифрован вместо этого KAB на шаге 3?
  • Почему нужны четыре nonce в протоколе Ниидома-Шрёдера?
  • Как KDC в протоколе Ниидома-Шрёдера аутентифицирует (удостоверяет) Алису? Как KDC аутентифицирует (удостоверяет) Боба? Как Алиса аутентифицирует (удостоверяет) Боба? Как Боб аутентифицирует (удостоверяет) Алису?
  • Объясните, почему в протоколе Ниидома-Шрёдера Алиса - сторона, которая находится в контакте с KDC, а в протоколе Отвея-Рисса Боб-сторона, которая находится в контакте с KDC.
  • В протоколе Ниидома-Шрёдера есть четыре ( RA, RB, R1 и R2 ), а в протоколе Отвея-Рисса - только три nonce (RA, RB и R). Объясните, почему есть потребность в одном дополнительном nonce R2 в первом протоколе.
  • Почему мы нуждаемся только в одной метке времени в протоколе Цербер вместо четырех nonce, как в протоколе Ниидома-Шрёдера, или трех once, как в протоколе Отвея-Рисса?
  • В протоколе Диффи-Хеллмана g = 7, p = 23, x = 3, и y = 5.
  • Какое значение имеет симметричный ключ?
  • Какие значения имеют R1 и R2?
    •
  • Что случится в протоколе Диффи-Хеллмана,если x и y имеют одно и то же значение, то есть Алиса и Боб случайно выбрали одно и то же число? R1 и R2 те же самые? Ключи сеанса, вычисленные Алисой и Бобом, имеют одно и то же значение? Приведите пример, чтобы доказать ваши выводы.
  • При тривиальной (не гарантирующей безопасность) смене ключа Диффи-Хеллмана p = 53. Найдите соответствующее значение для g.
  • В протоколе "от станции к станции" покажите, что если опознавательный код приемника удален из подписи, протокол становится уязвимым к атаке "посредника".
  • Обсудите заслуживающий доверия корень сертификации, применяющий браузеры.
    • Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^