Perfect forward secrecy

Совершенная прямая секретность (англ. Perfect forward secrecy, PFS^[1]) — свойство некоторых протоколов согласования^[англ.] ключа, которое гарантирует, что сессионные ключи, полученные при помощи набора ключей долговременного пользования, не будут скомпрометированы при компрометации одного из долговременных ключей.

Термин Forward secrecy часто используется как синоним к perfect forward secrecy^[2], но иногда^[3] между ними делается различие.

Совершенная прямая секретность (PFS) означает, что сеансовый ключ, генерируемый с использованием долговременных ключей, не будет скомпрометирован, если один или несколько из этих долговременных ключей будут скомпрометированы в будущем. Для сохранения совершенной прямой секретности ключ, используемый для шифрования передаваемых данных, не должен использоваться для получения каких-либо дополнительных ключей. Также, если ключ, используемый для шифрования передаваемых данных, был получен (derived) на базе какого-то ещё ключевого материала, этот материал не должен использоваться для получения каких-либо других ключей.^[4]

История

Свойство PFS было предложено^[5] Диффи, van Oorschot и Wiener и относилось к протоколу STS, в котором ключами долговременного пользования являются закрытые ключи. PFS требует использования асимметричной криптографии и не может быть реализован исключительно при помощи симметричных криптоалгоритмов.

Термин PFS также применялся^[6] при описании аналогичного свойства в протоколах согласования ключей с аутентификацией по паролю^[англ.], в которых ключом долговременного пользования является пароль, известный обеим сторонам.

Приложение Annex D.5.1 стандарта IEEE 1363—2000 описывает связанные свойства one-party forward secrecy и two-party forward secrecy различных стандартных схем согласования ключа.

Протоколы

PFS является опцией в протоколе IPsec (RFC 2412).
SSH.
Off-the-Record Messaging.
TLS имеет поддержку подобных протоколов начиная с версии SSL 3.0^[7]^[8]. На июнь 2016 года около 52 % веб-сайтов, доступных по протоколу HTTPS, использует PFS в случае, если протоколы поддерживаются браузерами^[9]).

Проблемы

При использовании PFS в TLS могут применяться TLS session tickets (RFC 5077) для возобновления зашифрованной сессии без повторного согласования ключей и без сохранения ключевой информации на сервере. При открытии первого соединения и создания ключей, сервер шифрует состояние соединения и передает его клиенту (в виде session ticket). Соответственно, при возобновлении соединения клиент посылает session ticket, содержащий в том числе сессионный ключ, обратно серверу. Сам ticket шифруется временным ключом (session ticket key), который хранится на сервере и должен распределяться по всем frontend-серверам, обрабатывающим SSL в кластеризованных решениях.^[10]. Таким образом, введение session ticket может нарушать PFS в случае компрометации временных серверных ключей, например, при их длительном хранении (OpenSSL, nginx, Apache по умолчанию хранят их в течение всего времени работы программы; популярные сайты используют ключ в течение нескольких часов, вплоть до суток). Сходная проблема существует и в TOR как минимум для одного слоя шифрования^[11]^[12].

Некоторые реализации протоколов согласования ключей (DH) выбирают слишком слабые параметры группы на серверной стороне. Например, иногда используются поля вычетов по модулю с длиной 256 бит (отвергаются некоторыми веб-браузерами) или 512 бит (легко взламываются)^[13]

См. также

Примечания

↑ Elsevier’s Dictionary of Information Security By G. Manoilov, B. Radichkova стр 364, # 3759
↑ IEEE 1363—2000: IEEE Standard Specifications For Public Key Cryptography. Institute of Electrical and Electronics Engineers, 2000. Архивированная копия (неопр.). Дата обращения: 25 ноября 2017. Архивировано 1 декабря 2014 года.
↑ Telecom Glossary 2000, T1 523—2001, Alliance for Telecommunications Industry Solutions (ATIS) Committee T1A1. http://www.atis.org/tg2k/_perfect_forward_secrecy.html Архивная копия от 11 декабря 2007 на Wayback Machine
↑ Интернет: протоколы безопасности. Учебный курс. // Блек У. — Питер, 2001. ISBN 5-318-00002-9, стр 63, «Совершенная прямая секретность (Perfect forward secrecy — PFS)»
↑ Diffie, Whitfield; van Oorschot, Paul C.; Wiener, Michael J. Authentication and Authenticated Key Exchanges (неопр.) // Designs, Codes and Cryptography. — 1992. — June (т. 2, № 2). — С. 107. — doi:10.1007/BF00124891. Архивировано 13 марта 2008 года.
↑ Jablon, David P. Strong Password-Only Authenticated Key Exchange (неопр.) // ACM Computer Communication Review. — 1996. — October (т. 26, № 5). — С. 5—26. — doi:10.1145/242896.242897. Архивировано 10 мая 2008 года.
↑ Discussion on the TLS mailing list in October 2007 (неопр.). Дата обращения: 23 ноября 2011. Архивировано из оригинала 22 сентября 2013 года.
↑ SSL Labs: Deploying Forward Secrecy Архивная копия от 26 июня 2013 на Wayback Machine // Ivan Ristic, Jun 25, 2013; Security Labs
↑ SSL Pulse: Survey of the SSL Implementation of the Most Popular Web Sites (неопр.). Дата обращения: 17 июня 2016. Архивировано из оригинала 15 мая 2017 года.
↑ Forward secrecy for Google HTTPS (22 Nov 2011) Архивная копия от 26 января 2014 на Wayback Machine // ImperialViolet — Session Tickets
↑ Florent Daigni. TLS "secrets" What everyone forgot to tell you... (англ.). Blackhat USA (июль 2013). Дата обращения: 20 декабря 2013. Архивировано из оригинала 5 августа 2013 года.
↑ SSL Labs: Deploying Forward Secrecy Архивная копия от 26 июня 2013 на Wayback Machine // Ivan Ristic, Jun 25, 2013; Security Labs — Alternative attack vectors: «there is an alternative session management mechanism called session tickets, which uses separate encryption keys that are infrequently rotated (possibly never in extreme cases). .. this feature is best disabled to ensure it does not compromise forward secrecy.»
↑ How to botch TLS forward secrecy (27 Jun 2013) Архивная копия от 8 августа 2013 на Wayback Machine // ImperialViolet

Ссылки

H. Orman. The OAKLEY Key Determination Protocol. IETF RFC 2412.
Forward secure survey Архивная копия от 27 сентября 2011 на Wayback Machine
Ivan Ristic, SSL Labs: Deploying Forward Secrecy, Jun 25, 2013

[1] Elsevier’s Dictionary of Information Security By G. Manoilov, B. Radichkova стр 364, # 3759

[2] IEEE 1363—2000: IEEE Standard Specifications For Public Key Cryptography. Institute of Electrical and Electronics Engineers, 2000. Архивированная копия (неопр.). Дата обращения: 25 ноября 2017. Архивировано 1 декабря 2014 года.

[3] Telecom Glossary 2000, T1 523—2001, Alliance for Telecommunications Industry Solutions (ATIS) Committee T1A1. http://www.atis.org/tg2k/_perfect_forward_secrecy.html Архивная копия от 11 декабря 2007 на Wayback Machine

[4] Интернет: протоколы безопасности. Учебный курс. // Блек У. — Питер, 2001. ISBN 5-318-00002-9, стр 63, «Совершенная прямая секретность (Perfect forward secrecy — PFS)»

[5] Diffie, Whitfield; van Oorschot, Paul C.; Wiener, Michael J. Authentication and Authenticated Key Exchanges (неопр.) // Designs, Codes and Cryptography. — 1992. — June (т. 2, № 2). — С. 107. — doi:10.1007/BF00124891. Архивировано 13 марта 2008 года.

[6] Jablon, David P. Strong Password-Only Authenticated Key Exchange (неопр.) // ACM Computer Communication Review. — 1996. — October (т. 26, № 5). — С. 5—26. — doi:10.1145/242896.242897. Архивировано 10 мая 2008 года.

[7] Discussion on the TLS mailing list in October 2007 (неопр.). Дата обращения: 23 ноября 2011. Архивировано из оригинала 22 сентября 2013 года.

[8] SSL Labs: Deploying Forward Secrecy Архивная копия от 26 июня 2013 на Wayback Machine // Ivan Ristic, Jun 25, 2013; Security Labs

[9] SSL Pulse: Survey of the SSL Implementation of the Most Popular Web Sites (неопр.). Дата обращения: 17 июня 2016. Архивировано из оригинала 15 мая 2017 года.

[10] Forward secrecy for Google HTTPS (22 Nov 2011) Архивная копия от 26 января 2014 на Wayback Machine // ImperialViolet — Session Tickets

[11] Florent Daigni. TLS "secrets" What everyone forgot to tell you... (англ.). Blackhat USA (июль 2013). Дата обращения: 20 декабря 2013. Архивировано из оригинала 5 августа 2013 года.

[12] SSL Labs: Deploying Forward Secrecy Архивная копия от 26 июня 2013 на Wayback Machine // Ivan Ristic, Jun 25, 2013; Security Labs — Alternative attack vectors: «there is an alternative session management mechanism called session tickets, which uses separate encryption keys that are infrequently rotated (possibly never in extreme cases). .. this feature is best disabled to ensure it does not compromise forward secrecy.»

[13] How to botch TLS forward secrecy (27 Jun 2013) Архивная копия от 8 августа 2013 на Wayback Machine // ImperialViolet

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]