HTTP トランスポート セキュリティ
トランスポートとして HTTP を使用すると、SSL (Secure Sockets Layer) によりセキュリティが提供されます。 SSL はクライアントに対してサービスの認証を行い、機密性 (暗号化) をチャネルに提供する技術としてインターネットで広く使用されています。 この記事では、SSL のしくみと、これを Windows Communication Foundation (WCF) に実装する方法について説明します。
基本 SSL
SSL の機能について一般的なシナリオを用いて説明します。ここでは、銀行の Web サイトを考えます。 ユーザーはユーザー名とパスワードを使用してサイトにログオンできます。 認証された後、ユーザーは、残高照会、支払い、口座間振り替えなどの各種取引を実行できます。
ユーザーがサイトに最初にアクセスするときに、SSL メカニズムによって、ユーザーのクライアント (この場合は Web ブラウザー) との "ハンドシェイク" と呼ばれる一連のネゴシエーションが開始されます。 SSL は最初にユーザーに対して銀行サイトの認証を行います。 ユーザーを誘導してユーザー名とパスワードを入力させる "なりすまし" サイトではなく、通信先が実際のサイトであることをユーザーが最初に認識する必要があるため、この手順は不可欠です。 SSL は、VeriSign などの信頼された機関から提供される SSL 証明書を使用してこの認証を行います。 論理上は、VeriSign が銀行サイトの識別情報を保証することになります。 これは、ブラウザーでは VeriSign が信頼済みであるため、このサイトも信頼されるという理由からです。 VeriSign に確認する場合は、VeriSign のロゴをクリックします。 有効期限や発行先 (銀行サイト) などの信頼性に関する報告が表示されます。
セキュリティで保護されたセッションを開始するには、クライアントは「もしもし」と同等の情報を暗号アルゴリズムのリストと共にサーバーに送信します。サーバーはこの暗号アルゴリズムのリストを使用して署名、ハッシュの生成、暗号化と複号化を行えます。 これに対して、サイトからは受信確認、およびサイトが選択したアルゴリズム スイートの 1 つが返送されます。 この初期ハンドシェイク中に、両方のパーティは nonce を送受信します。 nonce は、ランダムに生成される使用データの一部で、サイトの公開キーと組み合わせてハッシュの作成に使用します。 "ハッシュ" とは、SHA1 などの標準アルゴリズムに基づいて 2 つの数値から派生した新しい数値です。 (クライアントとサイトは、使用するハッシュ アルゴリズムに同意するためのメッセージも交換します)。ハッシュは一意で、クライアントとサイト間のセッションでメッセージの暗号化および復号化を行うためにのみ使用されます。 クライアントとサービスの両方に、元の nonce と証明書の公開キーがあるので、両者で同じハッシュを生成できます。 したがって、クライアントがサービスから送信されたハッシュを検証するには、(a) 同意したアルゴリズムを使用してデータからハッシュを計算し、(b) サービスから送信されたハッシュと比較します。両方が一致する場合は、クライアントはハッシュが改ざんされていないことを確認できます。 次にクライアントはこのハッシュを、さらに別の新しいハッシュが含まれるメッセージを暗号化するキーとして使用します。 サービスはハッシュを使用してこのメッセージを複号化でき、最後から 2 番目のハッシュを復帰できます。 ここで、累積された情報 (nonce、公開キーなどのデータ) が両者で認識されるので、最後のハッシュ (マスター キー) を作成できます。 最後のキーは、最後から 2 番目のハッシュで暗号化され送信されます。 次に、マスターキーを使用して、セッションの残りの部分のメッセージが暗号化および復号化されます。 クライアントとサービスの両方で同じキーを使用するため、これは "セッション キー" とも呼ばれます。
セッション キーは、対称キーまたは "共有シークレット" としての特性も持っています。対称キーを使用すると、トランザクションの両側で必要となる計算が削減されるため、このキーを持つことは重要です。 すべてのメッセージが新しい nonce とハッシュの交換を要求した場合、パフォーマンスは低下します。 したがって、対称キーを使用して高い安全性と効率を確保しながらメッセージを両側に自由にフローさせることが、SSL の最終的な目標になります。
プロトコルはサイトによってさまざまなので、以上の説明では動作を簡略化しています。 また、データ交換処理をさらに複雑にするため (保護を強化するため) に、ハンドシェイク中にクライアントとサイトの両方でアルゴリズムを組み合わせた nonce を別々に生成することもできます。
証明書および公開キー基盤
ハンドシェイク中に、サービスは SSL 証明書もクライアントに送信します。 証明書には、有効期限、発行元証明機関、サイトの URI (Uniform Resource Identifier) などの情報が含まれます。 クライアントは、この URI と最初にアクセスした URI を比較して一致するかどうかを確認し、また、日付と発行元証明機関をチェックします。
すべての証明書には、秘密キーと公開キーの 2 つのキーが含まれます。この 2 つのキーは、"交換キー ペア" と呼ばれます。 簡単に説明すると、秘密キーは証明書の所有者のみが認識し、公開キーは証明書から読み取ることができます。 どちらのキーもダイジェスト、ハッシュ、その他のキーの暗号化と複号化に使用できますが、逆の操作としての使用に限られます。 たとえば、クライアントで公開キーを使用して暗号化した場合、サイトのみが秘密キーを使用してメッセージを複号化できます。 同様に、サイトで秘密キーを使用して暗号化した場合、クライアントは公開キーを使用して複号化できます。 秘密キーを使用して暗号化されたメッセージのみが公開キーを使用して復号化できるため、クライアントには、秘密キーの所有者のみとメッセージ交換することが保証されます。 サイトには、公開キーを使用して暗号化を行っているクライアントとメッセージを交換していることが保証されます。 この交換は初期ハンドシェイクの場合のみセキュリティで保護されます。このため、実際の対称キーを作成する多くの試みが行われています。 いずれにしても、すべての通信は有効な SSL 証明書を保有するサービスに依存します。
WCF を使用する SSL の実装
HTTP トランスポート セキュリティ (つまり SSL) は、WCF の外部に提供されます。 SSL は、次のいずれかの方法で実装できますが、その方法は、アプリケーションがどのようにホストされるかによって決まります。
WCF のホストとしてインターネット インフォメーション サービス (IIS) を使用する場合、IIS インフラストラクチャを使用して SSL サービスを設定します。
自己ホスト型の WCF アプリケーションを作成する場合は、HttpCfg.exe ツールを使用して SSL 証明書をアドレスにバインドできます。
トランスポート セキュリティのための IIS の使用
IIS 7.0
セキュリティで保護されたホスト (SSL を使用) として IIS 7.0 を設定する場合は、IIS 7.0 での Secure Sockets Layer の構成に関するページを参照してください。
IIS 7.0 用の証明書を構成する場合は、IIS 7.0 でのサーバー証明書の構成に関するページを参照してください。
IIS 6.0
セキュリティで保護されたホスト (SSL を使用) として IIS 6.0 を設定する場合は、「Secure Sockets Layer の構成」を参照してください。
IIS 6.0 用の証明書を構成する場合は、「Certificates_IIS_SP1_Ops」を参照してください。
SSL での HttpCfg の使用
自己ホスト型の WCF アプリケーションを作成する場合は、HttpCfg.exe ツールを使用します。
HttpCfg.exe ツールを使用して x.509 証明書でポートを設定する方法の詳細については、「方法: SSL 証明書を使用してポートを構成する」を参照してください。