Шифрование с открытым ключом

Это довольно большой вопрос =) ниже приведен обзор высокого уровня HTTPS; кричите, если что-то не ясно, и я заполню более подробную информацию.

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

SSL-подтверждения

на очень высоком уровне протокол выглядит примерно так:

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

2. сервер отвечает своим собственным сообщением "HELLO", другой псевдослучайной строкой битов (давайте назовем это B2), шифр, который он выбрал (обычно самый сильный шифр из списка, который клиент отправил, который поддерживает сервер), и его сертификат, который содержит его открытый ключ (давайте назовем это k).

3. клиент затем использует сертификат для аутентификации сервера (см. ниже) и создает "premaster secret" - другую строку pseduo-случайных битов, которые мы будем называть S.

4. Если клиент доволен результатами аутентификации сервера, он шифрует премастер секрет S с открытым ключом сервера k, и отправляет его на сервер (сам по себе шифруется, но соединения все равно нет).

5. на данный момент сервер и клиент совместно используют три строки битов-B1, B2 и S. B1 и B2 были отправлены в открытом виде-S был зашифрован, и поэтому, предполагая, что закрытый ключ сервера действительно является частным, известен только клиенту и сервер.

6. и клиент, и сервер затем используют эти три битовые строки для построения ключа сеанса - строки, которая известна только им и может использоваться в качестве ключа в ранее выбранном симметричном шифре.

7. клиент и сервер обмениваются сообщениями, которые указывают на изменение протокола, и все последующие сообщения шифруются (симметрично, с ключом, вычисленным выше).

сервер проверка подлинности

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

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

Итак, когда клиент получит приветствие сервера, он выполнит следующие проверки:

• попадает ли сегодняшняя дата в период действия сертификата?
• совпадает ли имя субъекта сертификата с именем сервера, к которому я пытаюсь подключиться?
• имя эмитента сертификата совпадение с любым из ЦС, чьи открытые ключи мне известны?
  • если да, то открытый ключ, который я имею для этого CA, проверяет этот сертификат?

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

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

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

все проще, на самом деле.

открытые ключи являются публичными. Любой может их увидеть, любой может ими воспользоваться...Но это только один путь. Что-то зашифрованное с помощью открытого ключа может быть расшифровано только с помощью закрытого ключа.

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

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

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

Ваш вопрос немного общий. Что именно вы ищете?

• реализации протокола (как открыть зашифрованный пакет)
• математические детали (как сайт шифрует пакет, который предназначен для меня)
• secrurity проблемы (мужик в атаки ближнего')

вы читали обзоры Википедия запись?

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

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

на самом деле, единственная причина, по которой веб-сайт должен иметь открытый ключ на всех, так что вы можете быть уверены, кто вы говорите. Он предотвращает атаки "человек посередине". В целях обеспечения безопасности соединения от подслушивающих устройств это не является строго необходимым. На самом деле, многие веб-сайты используют открытые ключи, которые являются самоподписанными (как против заверенная органом регистрации) для SSL. В этом случае вы не можете быть уверены, что другая сторона действительно та, за кого себя выдает, но вы можете быть уверены, что никакая третья сторона не сможет вас слушать.

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

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

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

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

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

простой ответ: точно так же.

предположим, можете отправить данные надежно до Б, но Б может только отправлять данные небезопасным А. Все, что вам нужно сделать, это составить случайный ключ и отправить его безопасно для Б. Теперь Б может шифровать данные со случайным ключом, отправить его, и это безопасно.

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