Прямая секретность

Функция деривации ключей (KDF) может помочь в достижении прямой секретности. KDF — это односторонняя функция, которая генерирует новый ключ на основе текущего ключа. Утечка ключа не позволяет обнаружить предыдущие ключи.

В криптографии не будут скомпрометированы , прямая секретность ( FS ), также известная как совершенная прямая секретность ( PFS ), представляет собой функцию определенных протоколов согласования ключей , которая дает гарантии того, что ключи сеанса даже если при обмене ключами сеанса используются долгосрочные секреты. скомпрометированы, что ограничивает ущерб. Для HTTPS долгосрочным секретом обычно является закрытый ключ сервера. Прямая секретность защищает прошлые сеансы от будущего взлома ключей или паролей. Генерируя уникальный сеансовый ключ для каждого сеанса, инициируемого пользователем, компрометация одного сеансового ключа не повлияет ни на какие данные, кроме тех, которыми обмениваются в конкретном сеансе, защищенном этим конкретным ключом. Этого самого по себе недостаточно для прямой секретности, которая дополнительно требует, чтобы долгосрочная компрометация секрета не влияла на безопасность ключей прошлых сеансов.

Прямая секретность защищает данные на транспортном уровне сети, которая использует общие протоколы безопасности транспортного уровня, включая OpenSSL . когда его долгосрочные секретные ключи скомпрометированы, как в случае с ошибкой безопасности Heartbleed . Если используется прямая секретность, зашифрованные сообщения и сеансы, записанные в прошлом, не могут быть извлечены и расшифрованы, если долгосрочные секретные ключи или пароли будут скомпрометированы в будущем, даже если злоумышленник активно вмешался, например, через «человека в кадре». средняя (MITM) атака .

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

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

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

История

Термин «совершенная прямая секретность» был введен К.Г. Гюнтером в 1990 году. и далее обсуждалось Уитфилдом Диффи , Полом ван Оршотом и Майклом Джеймсом Винером в 1992 году. где он использовался для описания свойства протокола между станциями.

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

В 2000 году IEEE впервые ратифицировал стандарт IEEE 1363 , который устанавливает соответствующие свойства односторонней и двусторонней секретности для различных стандартных схем соглашения о ключах.

Определение

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

Пример

Ниже приведен гипотетический пример простого протокола обмена мгновенными сообщениями, использующего прямую секретность:

1. Алиса и Боб генерируют по паре долгосрочных асимметричных открытого и закрытого ключей , а затем проверяют отпечатки открытых ключей лично или по уже аутентифицированному каналу. Проверка с уверенностью устанавливает, что заявленный владелец открытого ключа является фактическим владельцем.
2. Алиса и Боб используют алгоритм обмена ключами, такой как Диффи-Хеллман , для безопасного согласования эфемерного сеансового ключа . Они используют ключи из шага 1 только для аутентификации друг друга во время этого процесса.
3. Алиса отправляет Бобу сообщение, шифруя его симметричным шифром с использованием сеансового ключа, согласованного на шаге 2.
4. Боб расшифровывает сообщение Алисы, используя ключ, согласованный на шаге 2.
5. Процесс повторяется для каждого нового отправленного сообщения, начиная с шага 2 (и переключения ролей Алисы и Боба в качестве отправителя/получателя в зависимости от ситуации). Шаг 1 никогда не повторяется.

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

Атаки

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

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

Неинтерактивная прямая секретность

Большинство протоколов обмена ключами являются интерактивными и требуют двунаправленной связи между сторонами. Протокол, который позволяет отправителю передавать данные без необходимости предварительного получения каких-либо ответов от получателя, может называться неинтерактивным , асинхронным или нулевым двусторонним обходом (0-RTT).

Интерактивность является обременительной для некоторых приложений — например, в системе безопасного обмена сообщениями может быть желательно иметь реализацию с промежуточным хранением , а не требовать, чтобы отправитель и получатель находились в сети одновременно; Ослабление требования к двунаправленности также может повысить производительность, даже если это не является строгим требованием, например при установлении или возобновлении соединения. Эти варианты использования стимулировали интерес к неинтерактивному обмену ключами, а поскольку прямая безопасность является желательным свойством протокола обмена ключами, к неинтерактивной прямой секретности. Эта комбинация считалась желательной по крайней мере с 1996 года. Однако сочетание прямой секретности и неинтерактивности оказалось сложной задачей; подозревалось, что прямая секретность с защитой от атак повторного воспроизведения невозможна в неинтерактивном режиме, но было показано, что можно достичь всех трех целей.

В целом были исследованы два подхода к неинтерактивной прямой секретности: предварительно вычисленные ключи и прокалываемое шифрование .

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

При прокалываемом шифровании получатель изменяет свой закрытый ключ после получения сообщения таким образом, что новый закрытый ключ не может прочитать сообщение, а открытый ключ остается неизменным. Росс Дж. Андерсон неофициально описал прокалываемую схему шифрования для прямого безопасного обмена ключами в 1997 году: и Грин и Майерс (2015) формально описали такую ​​систему: Основываясь на соответствующей схеме Канетти, Халеви и Каца (2003) , которая изменяет закрытый ключ в соответствии с расписанием, так что сообщения, отправленные в предыдущие периоды, не могут быть прочитаны с помощью закрытого ключа из более позднего периода. Green & Miers (2015) используют иерархическое шифрование на основе идентификации и шифрование на основе атрибутов , а Günther et al. (2017) используют другую конструкцию, которая может быть основана на любой иерархической схеме, основанной на идентичности. Даллмайер и др. (2020) экспериментально обнаружили, что модификация QUIC для использования прямого безопасного и устойчивого к повторному обмену ключей 0-RTT, реализованного с помощью прокалываемого шифрования, привела к значительному увеличению использования ресурсов, но не настолько, чтобы сделать практическое использование невозможным.

Слабая совершенная прямая секретность

Слабая совершенная прямая секретность (Wpfs) — это более слабое свойство, согласно которому при компрометации долгосрочных ключей агентов секретность ранее установленных сеансовых ключей гарантируется, но только для сеансов, в которые злоумышленник активно не вмешивался. Это новое понятие и различие между ним и прямой секретностью были введены Хьюго Кравчиком в 2005 году. Это более слабое определение неявно требует, чтобы полная (совершенная) прямая секретность сохраняла секретность ранее установленных сеансовых ключей даже в сеансах, в которых злоумышленник активно вмешивался или пытался действовать как посредник.

Протоколы

Прямая секретность присутствует в нескольких основных реализациях протокола, таких как SSH , а также в качестве дополнительной функции в IPsec (RFC 2412). Сообщения без записи , криптографический протокол и библиотека для многих клиентов обмена мгновенными сообщениями, а также OMEMO , который предоставляет дополнительные функции, такие как многопользовательская функциональность в таких клиентах, обеспечивают как прямую секретность, так и шифрование с возможностью отказа .

В Transport Layer Security наборы шифров, основанные на обмене ключами Диффи-Хеллмана (DHE- RSA , DHE- DSA ) и обмене ключами Диффи-Хеллмана на основе эллиптической кривой (ECDHE- RSA , ECDHE- ECDSA (TLS) доступны ). Теоретически TLS мог выбирать подходящие шифры, начиная с SSLv3, но в повседневной практике многие реализации отказывались обеспечивать прямую секретность или предоставляли ей только очень низкую степень шифрования. Это уже не относится к TLS 1.3, который обеспечивает прямую секретность, оставляя эфемерный механизм Диффи-Хеллмана (варианты с конечным полем и эллиптической кривой) в качестве единственного оставшегося механизма обмена ключами.

OpenSSL поддерживает прямую секретность с использованием эллиптической кривой Диффи-Хеллмана, начиная с версии 1.0. с вычислительными затратами примерно 15% для первоначального установления связи.

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

С другой стороны, среди популярных протоколов, используемых в настоящее время, WPA Personal не поддерживал прямую секретность до WPA3.

Использовать

Прямая секретность рассматривается несколькими крупными поставщиками информации в Интернете как важная функция безопасности. С конца 2011 года Google по умолчанию обеспечивает прямую секретность с помощью TLS для пользователей своей службы Gmail , службы Google Docs и служб зашифрованного поиска. С ноября 2013 года Twitter обеспечил своим пользователям прямую секретность с помощью TLS. Все вики , размещенные Фондом Викимедиа, с июля 2014 года обеспечивают пользователям конфиденциальность. и требуют использования прямой секретности с августа 2018 года.

Facebook сообщил в рамках расследования шифрования электронной почты, что по состоянию на май 2014 года 74% хостов, поддерживающих STARTTLS, также обеспечивают прямую секретность. В TLS 1.3, опубликованном в августе 2018 года, прекращена поддержка шифров без прямой секретности. По состоянию на февраль 2019 г. 96,6% опрошенных веб-серверов поддерживают ту или иную форму прямой секретности, а 52,1% будут использовать прямую секретность в большинстве браузеров.

На WWDC 2016 Apple объявила, что все приложения iOS должны будут использовать App Transport Security (ATS) — функцию, которая обеспечивает использование передачи HTTPS. В частности, ATS требует использования шифра шифрования, обеспечивающего прямую секретность. ATS стал обязательным для приложений с 1 января 2017 года.

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

По состоянию на май 2024 года прямая секретность поддерживается на 92,6% веб-сайтов в современных браузерах, а 0,3% веб-сайтов вообще не поддерживают прямую секретность.

См. также

• Переадресация анонимности
• Обмен ключами Диффи-Хеллмана
• Эллиптическая кривая Диффи – Хеллмана
• Соберите сейчас, расшифруйте позже

Библиография

• Андерсон, Росс (2002). «Два замечания о криптологии с открытым ключом» (PDF) .
• Канетти, Ран ; Халеви, Шай ; Кац, Джонатан (2003). «Схема прямого шифрования с открытым ключом». Достижения в криптологии — EUROCRYPT 2003 . Конспекты лекций по информатике. Том. 2656. стр. 255–271. дои : 10.1007/3-540-39200-9_16 . ISBN  978-3-540-14039-9 .
• Грин, Мэтью Д .; Майерс, Ян (2015). «Пересылка безопасных асинхронных сообщений с помощью прокалываемого шифрования». Симпозиум IEEE 2015 по безопасности и конфиденциальности . стр. 305–320. дои : 10.1109/СП.2015.26 . ISBN  978-1-4673-6949-7 . S2CID   9171925 .
• Гюнтер, Феликс; Хейл, Бритта; Ягер, Тибор; Лауэр, Себастьян (2017). «Обмен ключами 0-RTT с полной прямой секретностью» (PDF) .
• Назад, Адам (6 сентября 1996 г.). «неинтерактивная прямая секретность» . Шифропанки (список рассылки).
• Бойд, Колин; Геллерт, Кай (24 августа 2020 г.). «Современный взгляд на передовую безопасность» . Компьютерный журнал . 64 (4) (опубликовано в апреле 2021 г.): 639–652. дои : 10.1093/comjnl/bxaa104 . HDL : 11250/2730309 . Архивировано из оригинала 7 июня 2021 года . Проверено 8 июня 2021 г.
• Даллмайер, Финн; Дрес, Ян П.; Геллерт, Кай; Хэндрик, Тобиас; Ягер, Тибор; Клауке, Йонас; Нахтигаль, Саймон; Ренцельманн, Тимоти; Вольф, Руди (2020). «Внедрение технологии Forward-Secure 0-RTT: внедрение и анализ производительности в QUIC» (PDF) .

Внешние ссылки

• RFC 2412 IETF, Х. Орман. Протокол определения ключей OAKLEY
• Perfect Forward Secrecy может блокировать доступ АНБ к защищенным веб-страницам, но никто ею не пользуется Computerworld 21 июня 2013 г.
• SSL: сегодня перехвачено, завтра расшифровано Netcraft, 25 июня 2013 г.
• Развертывание лаборатории прямой секретности SSL 25 июня 2013 г.
• Тест SSL Labs для веб-браузеров
• Тест SSL Labs для веб-серверов