Как работает perfect forward secrecy (PFS)
Я в классе infosec, и я наткнулся на эту концепцию в интернете, и это заинтриговало меня. Я также просмотрел несколько веб-сайтов и Википедию, которые объясняют концепцию, а также несколько сообщений о stackoverflow, но я все еще запутываюсь. Насколько я понимаю, в типичном обмене открытыми ключами HTTPS браузер и сервер объединяются с ключами для создания ключа сеанса...если кто-то когда-либо получал закрытый ключ, который производил ключ сеанса, они могли видеть все данные, которые были отправлены между этой связью, даже в прошлом.
Я понимаю, что с PFS "ключ сеанса" никогда не отправляется , даже в зашифрованном виде. Он хранится в секрете, так что даже если кто-то нашел секретный ключ, он не сможет получить доступ к зашифрованным записанной информации из прошлого. Правильно ли это?
Мне также было интересно, если я участвую в обмене PFS, позвоните мне "A", с сервером "B", PFS должен работать с тем фактом, что если мой ключ будет скомпрометирован, A и разговор B не будет скомпрометирован, потому что они не знают ключ сеанса. Но как "B" аутентифицирует меня как "A", если мой ключ фактически скомпрометирован...например, как он узнает разницу между мной (A) или другим пользователем (C), используя мой ключ, пытающийся получить доступ к данным.
2 ответов
в сеансе, отличном от PFS, браузер решает ключ сеанса (или, скорее, секрет, из которого он получен) и шифрует его с помощью RSA, с открытым ключом RSA, полученным из сертификата, который принадлежит серверу. Сертификат также используется для проверки подлинности сервера. Затем сервер использует свой закрытый ключ (который вы называете мастер-ключом) для расшифровки ключа сеанса. Все соединения с сервером используют разные ключи сеанса, но если у вас есть главный ключ, вы можете понять их все, способ сервер. В PFS вы используете алгоритмы, такие как Diffie-Hellman, где мастер-ключ не используется. В связи с этим мастер-ключ используется для аутентификации параметров алгоритма. После согласования параметров происходит обмен ключами с использованием этих параметров и секретом обеих сторон. Параметров не секрет, а тайны сторон используются discarder после ключа сеанса (эфемерные). Таким образом, если вы обнаружите мастер-ключ, который вы не можете откройте ключ сеанса. Однако вы можете выдать себя за сервер, если получите ключ, и сертификат не будет признан недействительным. Чтобы узнать подробнее о Диффи-Хеллмана.
Мне очень нравится ответ на Quora, данный Робертом Лав:http://www.quora.com/What-is-perfect-forward-secrecy-PFS-as-used-in-SSL
давайте посмотрим, как работает обмен ключами в общем не эфемерном случае. Вместо того чтобы приводить практический пример, используя, скажем, Диффи-Хеллмана, я приведем обобщенный пример, где математика проста:
Alice (client) хочет поговорить с Bob (server).
У Боба есть закрытый ключ X и a открытый ключ Y. X является секретным, Y является открытым.
Алиса генерирует большое случайное целое число M.
Алиса шифрует M с помощью Y и отправляет Y(M) Бобу.
Боб расшифровывает Y (M) с помощью X, давая M.
и Алиса, и Боб теперь имеют M и используют его как ключ к любому шифру, который они согласились использовать для сеанса SSL-например, AES.
довольно просто, не так ли? Проблема, конечно, в том, что если кто-нибудь когда-нибудь узнает X, каждый связь скомпрометирована: X позволяет злоумышленнику расшифровать Y( M), давая M. давайте посмотрим на версию PFS этого сценария:
Alice (client) хочет поговорить с Bob (server).
Боб генерирует новый набор открытых и закрытых ключей, Y 'и X'.
Боб посылает тебя к Алисе.
Алиса генерирует большое случайное целое число M.
Алиса шифрует M с помощью Y 'и отправляет Y' (M) Бобу.
Боб расшифровывает Y'(M) с помощью X', уступая M.
и Алиса, и Боб теперь имеют M и используют его как ключ к любому шифру, который они согласились использовать для сеанса SSL-например, AES.
(X и Y все еще используются для проверки идентичности; я опускаю это.)
во втором примере X не используется для создания общего секрета, поэтому, даже если X будет скомпрометирован, M не будет обнаружен. Но вы только что передвинули проблему на X', можно сказать. Что делать, если X' станет известно? Но это гениально, говорю я. Предполагая, что X 'никогда не используется повторно и никогда не хранится, единственный способ получить X' - это если противник имеет доступ к памяти хоста во время связи. Если ваш противник имеет такой физический доступ, то шифрование любого рода не принесет вам никакой пользы. Более того, даже если бы X был каким-то образом скомпрометирован, он бы только показал это конкретное сообщение.
Это PFS.