В криптографии прямая секретность ( FS ), также известная как совершенная прямая секретность ( PFS ), является функцией определенных протоколов согласования ключей , которая дает гарантии того, что сеансовые ключи не будут скомпрометированы , даже если долгосрочные секреты, используемые при обмене сеансовыми ключами, будут скомпрометированы, ограничивая ущерб. Для HTTPS долгосрочным секретом обычно является закрытый ключ сервера. Прямая секретность защищает прошлые сеансы от будущих компрометаций ключей или паролей. Благодаря созданию уникального сеансового ключа для каждого сеанса, инициируемого пользователем, компрометация одного сеансового ключа не повлияет ни на какие данные, кроме тех, которыми обмениваются в конкретном сеансе, защищенном этим конкретным ключом. Этого самого по себе недостаточно для прямой секретности, которая дополнительно требует, чтобы компрометация долгосрочного секрета не влияла на безопасность прошлых сеансовых ключей.
Прямая секретность защищает данные на транспортном уровне сети, которая использует общие протоколы безопасности транспортного уровня, включая OpenSSL , [1], когда ее долгосрочные секретные ключи скомпрометированы, как в случае с ошибкой безопасности Heartbleed . Если используется прямая секретность, зашифрованные сообщения и сеансы, записанные в прошлом, не могут быть восстановлены и расшифрованы, если долгосрочные секретные ключи или пароли будут скомпрометированы в будущем, даже если противник активно вмешался, например, с помощью атаки «человек посередине» (MITM) .
Ценность прямой секретности заключается в том, что она защищает прошлые сообщения. Это снижает мотивацию злоумышленников к компрометации ключей. Например, если злоумышленник узнает долгосрочный ключ, но компрометация будет обнаружена, а долгосрочный ключ будет отозван и обновлен, в системе прямой безопасности будет утекать относительно немного информации.
Значение прямой секретности зависит от предполагаемых возможностей противника. Прямая секретность имеет значение, если предполагается, что противник может получить секретные ключи с устройства (доступ для чтения), но либо обнаружен, либо не может изменить способ генерации ключей сеанса на устройстве (полная компрометация). В некоторых случаях противник, который может считывать долгосрочные ключи с устройства, может также иметь возможность изменить работу генератора ключей сеанса, как в бэкдоре Dual Elliptic Curve Deterministic Random Bit Generator . Если противник может сделать генератор случайных чисел предсказуемым, то прошлый трафик будет защищен, но весь будущий трафик будет скомпрометирован.
Значение прямой секретности ограничено не только предположением, что противник будет атаковать сервер, только украв ключи и не изменяя генератор случайных чисел, используемый сервером, но оно также ограничено предположением, что противник будет только пассивно собирать трафик на линии связи и не будет активен, используя атаку «человек посередине». Прямая секретность обычно использует эфемерный обмен ключами Диффи-Хеллмана , чтобы предотвратить чтение прошлого трафика. Эфемерный обмен ключами Диффи-Хеллмана часто подписывается сервером с использованием статического ключа подписи. Если противник может украсть (или получить по решению суда) этот статический (долгосрочный) ключ подписи, он может выдать себя за сервер для клиента и за клиента для сервера и реализовать классическую атаку «человек посередине». [2]
Термин «совершенная прямая секретность» был введен Карлом Гюнтером в 1990 году [3] и далее обсуждался Уитфилдом Диффи , Полом ван Ооршотом и Майклом Джеймсом Винером в 1992 году [4] , где он использовался для описания свойства протокола «станция-станция». [5]
Прямая секретность также использовалась для описания аналогичного свойства протоколов согласования ключей с аутентификацией по паролю , где долгосрочным секретом является (общий) пароль . [6]
В 2000 году IEEE впервые ратифицировал IEEE 1363 , который устанавливает соответствующие односторонние и двухсторонние свойства прямой секретности различных стандартных схем согласования ключей. [7]
Система шифрования обладает свойством прямой секретности, если проверка открытого текста (расшифрованного) обмена данными, которая происходит на этапе согласования ключей при инициировании сеанса, не раскрывает ключ, который использовался для шифрования оставшейся части сеанса.
Ниже приведен гипотетический пример простого протокола обмена мгновенными сообщениями, использующего прямую секретность:
Прямая секретность (достигаемая путем генерации новых сеансовых ключей для каждого сообщения) гарантирует, что прошлые сообщения не могут быть расшифрованы, если один из ключей, сгенерированных в итерации шага 2, скомпрометирован, поскольку такой ключ используется только для шифрования одного сообщения. Прямая секретность также гарантирует, что прошлые сообщения не могут быть расшифрованы, если скомпрометированы долгосрочные закрытые ключи из шага 1. Однако маскировка под Алису или Боба будет возможна в будущем, если это произойдет, что может скомпрометировать все будущие сообщения.
Прямая секретность предназначена для предотвращения компрометации долгосрочного секретного ключа, влияющего на конфиденциальность прошлых разговоров. Однако прямая секретность не может защитить от успешного криптоанализа используемых базовых шифров , поскольку криптоанализ заключается в поиске способа расшифровать зашифрованное сообщение без ключа, а прямая секретность защищает только ключи, а не сами шифры. [8] Терпеливый злоумышленник может перехватить разговор, конфиденциальность которого защищена с помощью криптографии с открытым ключом , и подождать, пока базовый шифр не будет взломан (например, можно создать большие квантовые компьютеры , которые позволят быстро вычислить задачу дискретного логарифма ). Это позволит восстановить старые открытые тексты даже в системе, использующей прямую секретность.
Неинтерактивные протоколы обмена ключами с прямой защитой сталкиваются с дополнительными угрозами, которые не имеют отношения к интерактивным протоколам. При атаке подавления сообщений злоумышленник, контролирующий сеть, может сам хранить сообщения, не давая им достичь предполагаемого получателя; поскольку сообщения никогда не будут получены, соответствующие закрытые ключи не могут быть уничтожены или проколоты, поэтому компрометация закрытого ключа может привести к успешной расшифровке. Проактивное удаление закрытых ключей по расписанию смягчает, но не устраняет эту атаку. При атаке с вредоносным истощением ключей злоумышленник отправляет получателю много сообщений и исчерпывает материал закрытого ключа, заставляя протокол выбирать между отказом в закрытии (и включением атак типа «отказ в обслуживании» ) или отказом в открытии (и отказом от некоторого количества прямой секретности). [9]
Большинство протоколов обмена ключами являются интерактивными , требующими двунаправленной связи между сторонами. Протокол, который позволяет отправителю передавать данные без необходимости получения каких-либо ответов от получателя, можно назвать неинтерактивным , асинхронным или протоколом нулевого кругового обхода (0-RTT). [10] [11]
Интерактивность обременительна для некоторых приложений — например, в защищенной системе обмена сообщениями может быть желательно иметь реализацию с сохранением и пересылкой , а не требовать, чтобы отправитель и получатель были в сети одновременно; ослабление требования двунаправленности также может улучшить производительность, даже если это не является строгим требованием, например, при установлении или возобновлении соединения. Эти варианты использования стимулировали интерес к неинтерактивному обмену ключами и, поскольку прямая безопасность является желательным свойством в протоколе обмена ключами, к неинтерактивной прямой секретности. [12] [13] Эта комбинация была определена как желательная по крайней мере с 1996 года. [14] Однако объединение прямой секретности и неинтерактивности оказалось сложной задачей; [15] предполагалось, что прямая секретность с защитой от атак повторного воспроизведения невозможна неинтерактивно, но было показано, что можно достичь всех трех желаемых условий. [11]
В целом, были изучены два подхода к неинтерактивной прямой секретности: предварительно вычисленные ключи и прокалываемое шифрование . [13]
С предварительно вычисленными ключами создается много пар ключей и общедоступные ключи, а закрытые ключи уничтожаются после получения сообщения с использованием соответствующего открытого ключа. Этот подход был развернут как часть протокола Signal . [16]
В прокалываемом шифровании получатель изменяет свой закрытый ключ после получения сообщения таким образом, что новый закрытый ключ не может прочитать сообщение, но открытый ключ остается неизменным. Росс Дж. Андерсон неформально описал схему прокалываемого шифрования для прямого безопасного обмена ключами в 1997 году [17] , а Грин и Майерс (2015) формально описали такую систему, [18] основываясь на связанной схеме Канетти, Халеви и Каца (2003), которая изменяет закрытый ключ в соответствии с расписанием, так что сообщения, отправленные в предыдущие периоды, не могут быть прочитаны с помощью закрытого ключа из более позднего периода. [15] Грин и Майерс (2015) используют иерархическое шифрование на основе идентичности и шифрование на основе атрибутов , в то время как Гюнтер и др. (2017) используют другую конструкцию, которая может быть основана на любой иерархической схеме на основе идентичности. [19] Даллмейер и др. (2020) экспериментально обнаружили, что модификация QUIC для использования безопасного и устойчивого к повторному воспроизведению обмена ключами с 0-RTT, реализованного с прокалываемым шифрованием, приводит к значительному увеличению использования ресурсов, но не настолько, чтобы сделать практическое использование невозможным. [20]
Слабая совершенная прямая секретность (Wpfs) — это более слабое свойство, при котором при компрометации долгосрочных ключей агентов гарантируется секретность ранее установленных сеансовых ключей, но только для сеансов, в которые противник активно не вмешивался. Это новое понятие и различие между ним и прямой секретностью были введены Хьюго Кравчиком в 2005 году. [21] [22] Это более слабое определение неявно требует, чтобы полная (совершенная) прямая секретность поддерживала секретность ранее установленных сеансовых ключей даже в сеансах, в которые противник активно вмешивался или пытался действовать как человек посередине.
Прямая секретность присутствует в нескольких основных реализациях протоколов, таких как SSH , и как дополнительная функция в IPsec (RFC 2412). Off-the-Record Messaging , протокол криптографии и библиотека для многих клиентов мгновенного обмена сообщениями, а также OMEMO , который предоставляет дополнительные функции, такие как многопользовательская функциональность в таких клиентах, оба обеспечивают прямую секретность, а также отрицаемое шифрование .
В Transport Layer Security (TLS) доступны наборы шифров, основанные на обмене ключами Диффи–Хеллмана (DHE- RSA , DHE- DSA ) и обмене ключами Диффи–Хеллмана на эллиптических кривых (ECDHE- RSA , ECDHE- ECDSA ). Теоретически TLS может выбирать подходящие шифры, начиная с SSLv3, но в повседневной практике многие реализации отказываются предлагать прямую секретность или предоставляют ее только с очень низкой степенью шифрования. [23] Это больше не относится к TLS 1.3, который обеспечивает прямую секретность, оставляя эфемерный Диффи–Хеллмана (варианты конечного поля и эллиптической кривой) в качестве единственного оставшегося механизма обмена ключами. [24]
OpenSSL поддерживает прямую секретность с использованием эллиптической кривой Диффи-Хеллмана, начиная с версии 1.0, [25] с вычислительными затратами приблизительно в 15% для первоначального рукопожатия. [26]
Протокол Signal использует алгоритм Double Ratchet для обеспечения прямой секретности. [27]
С другой стороны, среди популярных протоколов, используемых в настоящее время, WPA Personal не поддерживал прямую секретность до WPA3. [28]
Прямая секретность рассматривается как важная функция безопасности несколькими крупными поставщиками интернет-информации. С конца 2011 года Google по умолчанию предоставила прямую секретность с TLS пользователям своего сервиса Gmail , сервиса Google Docs и зашифрованных поисковых сервисов. [25] С ноября 2013 года Twitter предоставил своим пользователям прямую секретность с TLS. [29] Все вики , размещенные Фондом Wikimedia, предоставили прямую секретность пользователям с июля 2014 года [30] и требуют использования прямой секретности с августа 2018 года.
Facebook сообщил в рамках расследования шифрования электронной почты, что по состоянию на май 2014 года 74% хостов, поддерживающих STARTTLS, также обеспечивают прямую секретность. [31] TLS 1.3, опубликованный в августе 2018 года, прекратил поддержку шифров без прямой секретности. По состоянию на февраль 2019 года [update]96,6% опрошенных веб-серверов поддерживают некоторую форму прямой секретности, а 52,1% будут использовать прямую секретность с большинством браузеров. [32]
На WWDC 2016 Apple объявила, что все приложения iOS должны будут использовать App Transport Security (ATS), функцию, которая обеспечивает использование передачи HTTPS. В частности, ATS требует использования шифра шифрования, который обеспечивает прямую секретность. [33] ATS стал обязательным для приложений с 1 января 2017 года. [34]
Приложение обмена сообщениями Signal использует прямую секретность в своем протоколе, что заметно отличает его от протоколов обмена сообщениями, основанных на PGP . [35]
Прямая секретность поддерживается на 92,6% веб-сайтов в современных браузерах, в то время как 0,3% веб-сайтов вообще не поддерживают прямую секретность по состоянию на май 2024 года. [36]