SKEME

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

SKEME — криптографический протокол распространения ключей, созданный в 1996 году Хьюго Кравчиком(англ. Hugo Krawczyk). Он позволяет двум сторонам получить общий секретный ключ, используя незащищённый канал связи.

Протокол SKEME послужил основой для протокола IKE [1], определённого в RFC 2409.

Основные свойства протокола

[править | править код]
  • аутентификация собеседников — уверенность в том, кто является собеседником [2];
  • perfect forward secrecy (PFS) — потеря секретных ключей не ведёт к компрометации прошлой переписки [3];
  • возможность отречения — третье лицо не сможет доказать, что сообщения написаны кем-либо другому адресату [4];
  • strong secrecy — злоумышленник не может детектировать изменение секретного ключа [5];
  • гибкость — четыре возможных режима работы позволяют достичь компромисса между производительностью и безопасностью [6].

Режимы и этапы

[править | править код]

Обозначения

[править | править код]

Для описания протокола используются следующие обозначения:

  • — шифрование сообщения с открытым ключом, принадлежащим стороне A;
  • — вычисление криптографической хеш-функции с аргументом ;
  • — псевдослучайная функция с ключом , результат вычисления которой нельзя предсказать без знания ключа;
  • — идентификаторы сторон A и B соответственно;
  • — генератор и модуль соответственно, используемые в протоколе Диффи — Хеллмана.

Базовый режим

[править | править код]

Первый этап

[править | править код]

Во время первого этапа стороны A и B получают эфемерный ключ , зная открытые ключи друг друга [7]. Для этого они обмениваются «половинками ключа», зашифрованными открытыми ключами друг друга, а затем комбинируют «половинки» при помощи хеш-функции.

Значения и должны быть выбраны случайным образом[8]. Если сторона A следует протоколу, то она может быть уверена в том, что эфемерный ключ неизвестен никому, кроме B. Аналогично, сторона B может быть уверена в том, что эфемерный ключ не знает никто, кроме A[9].

Второй этап

[править | править код]

На втором этапе стороны используют протокол Диффи — Хеллмана[10]. Сторона А выбирает случайное число и вычисляет значение . Сторона B выбирает случайное число и вычисляет значение . После этого, стороны обмениваются вычисленными значениями.

Третий этап

[править | править код]

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

Включение в первое сообщение позволяет стороне B убедиться в том, что значение на втором этапе было действительно передано стороной A[11]. Значение в этом же сообщении позволяет B защититься от атаки повторного воспроизведения[12].

Генерация сессионного ключа

[править | править код]

Результатом выполнения протокола является сессионный ключ, вычисляемый как [13].

Режим SKEME без PFS предоставляет возможность обмена ключами без вычислительных затрат, необходимых для обеспечения PFS [14]. Для этого на втором этапе вместо значений и , стороны посылают друг другу случайные числа и .

Третий этап тоже модифицируется. Аргументы функции меняются с и на и соответственно.

Данная модификация второго и третьего этапа позволяет сторонам убедиться в том, что ключ , полученный на первом этапе, известен обеим сторонам. [15].

Результатом выполнения протокола в данном режиме является сессионный ключ, вычисляемый как , где [16].

Pre-shared key и PFS

[править | править код]

В данном режиме предполагается, что сторонам уже известен секретный ключ (например, ключ задан вручную), и они используют этот ключ для того, чтобы получить новый сессионный ключ [17]. В этом режиме первый этап можно пропустить и использовать секретный ключ вместо . В этом режиме обеспечивается perfect forward secrecy [18].

Сессионный ключ в данном режиме вычисляется так же, как в базовом [19].

Fast Re-Key — самый быстрый режим протокола SKEME [20]. Этот режим позволяет часто обновлять ключ без вычислительных затрат на асимметричное шифрование и на использование протокола Диффи — Хеллмана [21].

В этом режиме предполагается, что ключ известен сторонам с предыдущего раунда протокола. Первый этап пропускается, а второй и третий этап, а также вычисление сессионного ключа выполняются так же, как в режиме SKEME без PFS [22].

Примечания

[править | править код]
  1. mao2002plausible, 2002, 5 Achieving Complete Deniability, p. 5: «SKEME is a basis for the “Pre-shared-key Mode” in IKE [11].».
  2. krawczyk96, 1996, 3.2 The Basic Protocol and Its Phases, p. 121: «Notice that the key shared in the SHARE phase can be known only to A and B (assuming their private keys are not compromised) and then only these parties could have generated the above authenticated messages.».
  3. krawczyk96, 1996, 4 Summary of the Main Features, p. 124: «Perfect forward secrecy via Diffie-Hellman exchange provided as part of the basic protocol.».
  4. di2006deniable, 2006, 1 Introduction, p. 403: «For SKEME we show the strong form of deniability guaranteed by our definition».
  5. blanchet2004automatic, 2004, 7 Experimental Results, p. 99: «We have also proved strong secrecy results for the protocols of Otway-Rees [38], Yahalom [21], and Skeme [32].».
  6. krawczyk96, 1996, 4 Summary of the Main Features, p. 124: «SKEME is designed to achieve the requirements listed and discussed in Section 2. In particular, to provide support for the different security scenarios and to allow flexible tradeoffs between security and performance…».
  7. bauer2000security, 2000, 5.1 Four examples, p. 49: «SHARE enables two principals A and B to obtain a shared key, assuming that initially each knows the public key of the other…».
  8. krawczyk96, 1996, 3.2 The Basic Protocol and Its Phases, p. 121: «We stress that the values of and need to be chosen as (pseudo-) random values, and fresh for each run of the protocol.».
  9. krawczyk96, 1996, 3.2 The Basic Protocol and Its Phases, p. 121: «If A follows the protocol then she is assured that the shared key is not known to anybody except B».
  10. krawczyk96, 1996, 3.2 The Basic Protocol and Its Phases, p. 121: «The next phase, EXCH, is used to exchange Diffie-Hellman exponents.».
  11. krawczyk96, 1996, 3.2 The Basic Protocol and Its Phases, p. 121: «The inclusion of in the first message serves to authenticate (to B) that came from A».
  12. krawczyk96, 1996, 3.2 The Basic Protocol and Its Phases, p. 121: «the value in the same message is used to prove to B the freshness of this message (assuming was freshly chosen by B)».
  13. krawczyk96, 1996, 3.2 The Basic Protocol and Its Phases, p. 121: «The session key SK, which is the key shared between A and B as the result of this protocol, is computed by the parties as .».
  14. krawczyk96, 1996, 3.3.1 SKEME Without PFS, p. 122: «The mode of SKEME presented in this section is intended to provide the key exchange functionality based on public keys of the parties, but without paying the high performance cost required to achieve PFS.».
  15. krawczyk96, 1996, 3.3.1 SKEME Without PFS, p. 122: «In this way the combination of EXCH and AUTH provides the parties with the assurance that the key they shared through the SHARE phase is known to both of them…».
  16. krawczyk96, 1996, 3.3.1 SKEME Without PFS, p. 122: «…we define to be , where is the value sent in the message from A to B in phase AUTH…».
  17. krawczyk96, 1996, 3.3.2 Pre-shared key and PFS, p. 123: «In this mode, the protocol assumes that the parties already share a secret key, and that they use this key in order to derive a new and fresh key.».
  18. krawczyk96, 1996, 3.3.2 This mode provides also with perfect forward secrecy (PFS), p. 123.
  19. krawczyk96, 1996, 3.3.2 Pre-shared key and PFS, p. 123: «The computation is identical to that of the basic protocol…».
  20. krawczyk96, 1996, 3.3.3 Fast Re-key, p. 123: «This is the fastest mode of SKEME».
  21. krawczyk96, 1996, 3.3.3 Fast Re-key, p. 123: «It is intended to provide for very frequent key refreshment without going through expensive operations like public key or Diffie-Hellman computations.».
  22. krawczyk96, 1996, 3.3.3 Fast Re-key, p. 123: «Computation of is identical to that of Section 3.3.1…».

Литература

[править | править код]
  • Boyd C., Mathuria A. Protocols for authentication and key establishment. — Springer, 2003. — 321 с. — ISBN 3-540-43107-1.