Можно ли использовать один открытый ключ для шифрования и дешифрования данных во время SSL-рукопожатия?

в криптографии с открытым ключом:

• закрытый ключ используется для подписи и расшифровка/расшифровка.
• открытый ключ используется для проверка подписи и шифрование/шифрование.

посмотреть глоссарий спецификации TLS:

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

вы не можете зашифровать с помощью закрытого ключа или расшифровать с помощью открытого ключа, не по математическим причинам, а потому, что это не имеет смысла w.r.т. определение шифровать:

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

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

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

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

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

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

...открытый ключ в сертификате сервера будет использоваться только для проверьте его (серверную) идентичность.

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

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

есть аналогичная проблема с этой цитатой (опять же, возможно, вырванная из контекста):

...ключевая информация подписывается с помощью открытый ключ, содержащийся в сертификат сервера.

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

Я не уверен, есть ли в книге "(расшифровка)" и "(шифрование) " или ваши дополнения:

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

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

Как это положено в спецификация TLS раздел F. 1.1.2:

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

то, что вы спрашиваете в конце, не совсем имеет смысл:

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

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

EDIT 2:

после редактирования кажется, что вы все еще используете "sign (encrypt)" и " verify (decrypt)", как будто шифрование - это то же самое, что подпись, а проверка-это то же самое, что расшифровка. Я бы еще раз предложил вам прекратить создавать эти ассоциации: это 4 различные операции. Хотя математика может быть одинаковой при использовании RSA, это не работает для DSA, который является только алгоритмом подписи (только для подписи/проверки).

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

клиент не получает никаких зашифрованных данных во время рукопожатия (только подписанные данные).

для лучшего общего понимания, вы должны начать, пытаясь понять, как Диффи-Хеллмана и эфемерный вариант (для наборов шифров DHE) работа. (На практике я бы не слишком фокусировался на не эфемерных DH_RSA/DH_DSS шифров. Честно говоря, я не уверен часто ли они используются. Я не видел никакого примера сертификата с необходимыми атрибутами DH, и эти наборы шифров не находятся в поддерживаемых списках в OpenSSL или Java 7. DHE / EDH гораздо более распространены и не требуют специальных атрибутов в сертификате.)

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

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

относительно других точек:

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

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

1. само рукопожатие, в случае успеха, гарантирует, что вы разговариваете с сервером, который имеет закрытый ключ для сертификата, представленного в сообщении сертификата сервера. Если используется RSA Key exchange, это гарантируется тем, что это единственный, который может расшифровать то, что клиент отправил в сообщение обмена ключами клиента (поскольку оно зашифровано открытым ключом); при использовании обмена ключами EDH это гарантируется, поскольку сервер подписал свои параметры DH в сообщении обмена ключами сервера, проверяемом этим открытым ключом.
2. тот факт, что вы можете проверить сам сертификат. Это довольно независимо от того, как работает TLS, но обычно это делается с помощью PKI: клиент имеет заранее установленный список доверенных сертификатов CA, открытые ключи которых можно использовать чтобы проверить подпись в новых сертификатах, о которых он еще не знает (например, сертификат сервера). Проверка этой подписи позволяет клиенту привязать этот открытый ключ к идентификатору (Subject DN и / или alt. имя.) Это дает вам идентификатор сервера, с которым разговаривает клиент.
3. проверка имени хоста: недостаточно знать, что вы говорите с кем-то, кто представил вам подлинный идентификатор, действительный для них, вам также нужно проверить, что имя соответствует серверу, к которому вы намеревались подключиться.

когда я сказал: "открытый ключ в сертификате сервера не используется для проверки самой идентификации сервера", я имел в виду, что открытый ключ не использовался для проверки точек 2 и 3. Пункт 1 гарантирует, что вы разговариваете с сервером, у которого есть закрытый ключ, соответствующий сертификату, который он представил, но он не говорит вам, кто это. Проверка идентичности сервера is до пункта 2, чтобы иметь возможность привязать идентификатор этого ключа/сертификата.