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

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

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

Квитирование SSL

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

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

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

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

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

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

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

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

Аутентификация сервера

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

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

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

• Сегодняшняя дата находится в пределах срока действия сертификата?
• Подчиненное название соответствия сертификата тот из сервера, с которым я пытаюсь соединиться?
• Выпускающий называет на сертификате соответствии любой АВАРИИ, об открытых ключах которой я знаю?
  • Раз так открытый ключ я имею для этого CA, проверяют этот сертификат?

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

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

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

Это более просто, чем это на самом деле.

Открытые ключи общедоступны. Любой видит их, любой может использовать их... Но они - только один путь. Что-то зашифрованное с Вашим открытым ключом может только быть Дешифровано с ВАШИМ закрытым ключом.

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

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

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

Ваш вопрос немного универсален. Что точно Вы ищете?

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

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

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

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

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

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

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

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

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

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