Обмен криптографическими ключами между клиентом и сервером

Question

Я видел много examples при проверке сертификатов клиентов или серверов с использованием API фреймворка безопасности, но это решит только проблему с функциями безопасности Identification, но как насчет Confidentiality данных? Как обменять частные и открытые ключи между клиентом и сервером? Как насчет Interception, Modifications, или Fabrication атак? Что делать, если кто-то притворяется и отправляет правильный сертификат, как ожидается клиентом?

Answer 1

Идентификация предоставляется путем проверки сертификата в качестве примечания. Конфиденциальность обеспечивается посредством шифрования. Аутентификация обеспечивается путем подписания данных. Вместе они часто реализуются через TLS через сетевое соединение.

Короче говоря, если вы правильно реализуете и развертываете HTTPS и проверяете свои сертификаты, то вы получите все, что вы описываете. NSURLConnection выполнит почти все это для вас по умолчанию, если вы просто используете URL-адрес «https».

---

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

Типичный подход заключается в использовании коммерческого сертификата, в котором орган сертификации (CA), такой как Verisign, подтверждает, что частный ключ был выдан владельцу данного хоста (известного как CN или общее имя). Это простой в использовании подход и, как правило, экономически эффективный. Перейдите в один из известных центров сертификации и купите сертификат.

Тем не менее, вы также можете создать свой собственный ключ-ключ для общественного/частного сервера, защитить секретный ключ и распространить открытый ключ на своем клиенте. Затем вы можете настроить своего клиента только для принятия этого сертификата и других. Это на самом деле более безопасно, чем коммерческий сертификат. Пример этого см. В разделе SelfCert. Это от моего CocoaConf-RTP-2012 talk. Я буду вести аналогичный разговор в CocoaConf-DC-2013. Он также подробно обсуждается в главе 15 от iOS:PTL.

Клиентские сертификаты встречаются реже. Они используются для аутентификации клиента, а не сервера. Чтобы клиентский сертификат работал правильно, каждый клиент должен иметь свой собственный сертификат. Вы не можете отправить закрытый ключ как часть своего пакета. Если вы это сделаете, любой может использовать этот закрытый ключ для олицетворения клиента. (С другой стороны, это вполне нормально, чтобы положить открытый ключ сервера в связке Это общественности;.. Не все равно, кто его видит)

С CFNetwork, после подключения, вам нужно будет использовать CFReadStreamCopyProperty для извлечения kCFStreamPropertySSLPeerTrust , Затем вы можете оценить возвращаемый объект SecTrust. Тем не менее, я рекомендую код NSURLConnection, если вы можете его использовать. Если вам нужен доступ на более низком уровне, вы все равно можете использовать NSStream. Джефф Ламарче обсуждает это в NSStream: TCP and SSL. Но я бы рекомендовал использовать такой инструмент, как AFNetworking или CocoaAsyncSocket, если вам нужен более низкий уровень контроля над TCP + SSL.