セキュリティフレームワークAPIを使用してクライアントまたはサーバーの証明書を検証する例をたくさん見てきましたが、これIdentificationはセキュリティ機能の問題のみを解決しますがConfidentiality、データについてはどうでしょうか。クライアントとサーバー間で秘密鍵と公開鍵を交換するにはどうすればよいですか？、、、または攻撃はどうですかInterception？誰かがクライアントの期待どおりに正しい証明書を装って送信した場合はどうなりますか？ModificationsFabrication
質問する
645 次
1 に答える
1
識別は、メモしたとおりに証明書を確認することによって提供されます。機密性は暗号化によって提供されます。認証は、データに署名することによって提供されます。これらは一緒になって、ネットワーク接続を介してTLSを介して実装されることがよくあります。
つまり、HTTPSを適切に実装およびデプロイし、証明書を検証すると、説明しているすべてのものを取得できます。NSURLConnection「https」URLを使用するだけの場合、デフォルトでこれのほとんどすべてが実行されます。
サーバーに証明書を展開し、その秘密鍵を保護する場合、攻撃者がその証明書を持っているふりをすることは現実的ではありません。サーバーのみがサーバーの秘密鍵を持っています（秘密鍵をコピーや盗難から保護するのはあなた次第です）。
一般的なアプローチは、商用証明書を使用することです。この証明書では、Verisignなどの認証局（CA）が、特定のホスト（CNまたは一般名）の所有者に秘密鍵が発行されたことを証明します。これは使いやすいアプローチであり、一般的に費用対効果が高くなります。有名なCAの1つに行き、証明書を購入します。
ただし、独自の公開/秘密サーバーキーペアを作成し、秘密キーを保護し、クライアントで公開キーを配布することもできます。次に、その1つの証明書のみを受け入れ、他の証明書を受け入れないようにクライアントを構成できます。これは実際には商用証明書よりも安全です。この例については、SelfCertを参照してください。これは私のCocoaConf-RTP-2012トークからです。CocoaConf-DC-2013でも同様の講演を行います。また、 iOS：PTLの第15章でも詳しく説明されています。
クライアント証明書はあまり一般的ではありません。これらは、サーバーではなく、クライアントを認証するために使用されます。クライアント証明書が正しく機能するには、各クライアントが独自の証明書を持っている必要があります。バンドルの一部として秘密鍵を出荷することはできません。そうした場合、誰でもその秘密鍵を使用してクライアントになりすますことができます。（逆に、サーバーの公開鍵をバンドルに入れることはまったく問題ありません。公開鍵です。誰がそれを見るかは関係ありません。）
を使用すると、接続後、を使用してをフェッチCFNetworkする必要があります。次に、返されたオブジェクトを評価できます。とはいえ、使用できるのであれば、このコードをお勧めします。低レベルのアクセスが必要な場合でも、を使用できます。Jeff LamarcheがNSStreamでこれについて説明しています：TCPとSSL。ただし、TCP + SSLを低レベルで制御する必要がある場合は、代わりにAFNetworkingやCocoaAsyncSocketなどのツールをお勧めします。CFReadStreamCopyPropertykCFStreamPropertySSLPeerTrustSecTrustNSURLConnectionNSStream
于 2013-02-28T01:29:58.213 に答える