Сертификаты, шифрование и аутентификация

Question

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

1. Как сертификат X509 можно использовать в качестве токена аутентификации? Разве сертификаты ssl обычно не делаются публично доступными? Разве это не сделает невозможным их использование в целях аутентификации? Если нет, то существуют ли какие-либо протоколы, которые обычно используются для этой цели?
2. При шифровании сообщений с помощью WCF используются сертификаты, которые были выданы только клиенту, только серверу или обоим? Если используются сертификаты от клиента и сервера, мне немного непонятно, почему. Это в основном связано с моим пониманием https, и в этом случае для установления зашифрованного соединения и проверки подлинности сервера потребуется только сертификат, выданный серверу (и связанный с некоторым сертификатом, выданным корневым центром сертификации).

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

Заранее спасибо!

Answer 1

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

Как работает аутентификация с сертификатом?

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

Как это связано с HTTPS?

WCF обеспечивает безопасность транспорта и сообщений. Разница между ними описана здесь . Транспортная безопасность в случае HTTP - HTTPS, где только сервер нуждается в выданном сертификате, и клиент должен доверять этому сертификату. Этот сертификат используется как для аутентификации сервера на клиенте, так и для установления безопасного канала (который использует симметричное шифрование).

HTTPS также предлагает вариант, называемый Mutual HTTPS, где клиент должен также выдать сертификат, а клиент использует сертификат для аутентификации на сервере.

Как работает защита сообщений и какова цель двух сертификатов в этом сценарии?

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

Привязка безопасности является частью утверждений WS-SecurityPolicy и описывает, как сообщение защищено. У нас есть три привязки:

• Симметричное связывание безопасности - симметричное шифрование
• Асимметричное связывание безопасности - асимметричное шифрование
• Привязка безопасности транспорта - утверждение о том, что сообщение должно быть отправлено по протоколу HTTPS или другому защищенному транспорту

Профиль токена X.509 определяет, как переносить сертификаты (открытые ключи) в сообщениях и как их использовать.

Теперь, если у вас симметричная привязка безопасности, вам нужен только сертификат сервера, потому что

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

Это симметричное шифрование, которое намного быстрее асимметричного шифрования, но получение ключа не должно быть доступно в WS-Security 1.0. Он доступен в WS-Security 1.1. HTTPS внутренне работает аналогичным образом, но ключ остается неизменным на протяжении всего срока службы соединения.

Если у вас асимметричная привязка безопасности, вам нужны два сертификата:

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

Это означает, что следующий алгоритм

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

Порядок подписи и шифрования можно изменить - есть еще одно утверждение WS-SecurityPolicy, в котором говорится, что нужно сделать в первую очередь.

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

Answer 2

Сертификат имеет только открытый ключ из пары открытый / закрытый ключ. У него нет закрытого ключа - он отделен от самого сертификата. Когда вы подключаетесь к HTTPS-серверу, вы можете верить, что сервер является владельцем этого сертификата, потому что сервер должен хранить закрытый ключ (и, надеюсь, никто другой не имеет его), потому что в противном случае соединение SSL невозможно . Если на сервере не было закрытого ключа, который связан с открытым ключом его сертификата, он не сможет предоставить вам действительное соединение SSL.

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

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

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