[XADM] SSL の仕組みについて

文書翻訳 文書翻訳
文書番号: 245152 - 対象製品
この記事は、以前は次の ID で公開されていました: JP245152
すべて展開する | すべて折りたたむ

目次

概要

この資料では、SSL (Secure Socket Layer) の動作の概要を紹介します。

詳細

公開キー暗号化について

RSA (Rivest-Shamir-Adleman) 公開キー暗号化は、コンピュータ業界において認証および暗号化に広く使用されています。Netscape は RSA Data Security Inc. から RSA 公開キー暗号のライセンスを受けており、Netscape 製品では認証機能に特化して使用されています。

公開キー暗号化とは、非対称な 2 つのキーを組み合わせて暗号化および暗号文の解読を行う技術です。キーのペアは、公開キーと秘密キーで構成されています。公開キーは、広く配布することによって公開されますが、秘密キーは決して配布されず、常に厳重に保管する必要があります。

公開キーを使用して暗号化されたデータは、それに対応する秘密キーを使用しないと解読できません。逆に、秘密キーを使用して暗号化されたデータは、それに対応する公開キーを使用しないと解読できません。公開キー暗号化が実用的なのは、このような非対称な性質があるためです。

公開キー暗号化を認証に使用する

認証とは、あるエンティティが別のエンティティの身元を確認するための、識別情報の確認プロセスのことです。以下の例では、User A および User B は公開キー暗号を使用して User B の識別情報を確認します。以下の表記は、ある項目がキー暗号を使用して暗号化または解読されたことを表すものとします。
{something}key
something は、暗号化または解読された項目の説明です。また、key は項目の暗号化または解読に使用されたキーを表します。

以下の例では、User A が User B を認証しようとしているとします。User B は、公開キーと秘密キーのペアを持っています。User B は公開キーを User A に公開します (これについては「公開キーを渡す」で後述されています)。User A はランダムなメッセージを生成し、以下のように User B に送信します。
A->Brandom_message
User B は、秘密キーを使用してこのランダム メッセージを暗号化し、User A に返します。
B->A{random_message}User_B の秘密キー
User A はこのメッセージを受信し、User B が事前に公開した公開キーを使用してこのメッセージを解読します。User A は、自分が先ほど User B に送信したメッセージと、解読したメッセージとを比較します。メッセージが一致する場合は、後から受信したメッセージが User B から送信されたものであることを User A が確認できます。仮に誰かが User B を詐称している場合、偽者はおそらく User B の秘密キーを持っていないと仮定でき、したがって偽者は User B の秘密キーを使用してランダム メッセージを正しく暗号化して User A に送信することはできないと考えられるためです。

その他の注意点

暗号化するデータの内容を正確に把握していない場合、そのデータをそのまま秘密キーで暗号化して他人に送信することは決して良い考えとは言えません。これは、暗号化した内容について送信者が責任を問われる場合があるためです。このような暗号化を行えるのは、秘密キーを取得した本人のみであることに注意してください。

このため、この例では User A が送信した元のメッセージそのものを暗号化せず、User B はメッセージのダイジェストを作成してこれを暗号化します。元のランダム メッセージから派生したメッセージ ダイジェストには、以下のような有用な性質があります。
  • メッセージのダイジェストから元のメッセージを再現することは困難です。User B の偽者は、ダイジェストから元のメッセージを特定することはまず不可能です。
  • 同一のダイジェスト値を生成する異なるメッセージを作成することは困難です。
User B は、ダイジェストを使用することによって保護されます。User B は、User A が送信したランダム メッセージを元にダイジェストを作成し、それを暗号化します。User B はこの暗号化したダイジェストを User A に送信します。次に User A は、自分が送信したランダム メッセージを基に同じ方法でダイジェストを作成し、User B によって送信されたメッセージを解読してそれと比較することによって User B を認証します。

認証時のデータ生成

「その他の注意点」で説明した技術は、デジタル署名という名前で広く知られています。この技術では、User A が生成したメッセージに対して User B が署名することが要求されます。User A のデータから生成されたランダムな値を User B が暗号化すると、大きな危険を伴います。このため、ここで使用する例では、User B はデータの一部 (またはすべて) を以下のように 生成 し、これによって認証プロトコルのセキュリティをさらに強化する必要があります。
A->B B->A hello, are you User B? User A, This Is User B {digest[User A, This Is User B] }User_B の秘密キー
User B はこのプロトコルを使用することにより、どのようなメッセージが User A に送信されようとしているかを知ることができ、メッセージに安全に署名できるようになります。User B は、暗号化されていないバージョンのメッセージ "User A, This Is User B" を最初に送信します。次に User B は、同じメッセージにダイジェスト化および暗号化を行ったバージョンを送信します。これによって、User B が間違いなく User B であることが User A から容易に確認でき、User B に由来していないデータに対して User B が無用な署名を行う必要がなくなります。

公開キーを渡す

公開キーを安全に相手に渡すにはどうすればよいでしょうか。以下は、User B の認証プロトコルの例です。
A->B B->A A->B B->A
hello Hi, I'm User B,User_B の公開キーprove it User A, This Is
User B {digest[User A, This Is User B] }User_B の秘密キー
このようなプロトコルを使用すると、誰でも User B になりすます (偽装する) ことができます。User B を偽装するには、公開キーと秘密キーがあれば十分です。User B の公開キーの代わりに偽者が持っている公開キーを渡すことによって、偽者は User A をだまし、User B になりすますことができます。その後、偽者が自分の秘密キーで何らかのデータを暗号化することによって、自分が User B であるということを証明してしまうと、User B が実際には偽者であることを User A から識別することはできなくなります。

この問題を解決するために、標準化コミュニティでは "証明書" と呼ばれるオブジェクトを考案しました。証明書には、以下の情報が含まれます。
  • 証明書の発行者名
  • 証明書の発行先 ( サブジェクト とも呼ばれます)
  • サブジェクトの公開キー
  • タイム スタンプ
証明書は、証明書の発行者の秘密キーを使用して署名されています。証明書の発行者の公開キーは誰でも入手できるようになっています (つまり発行者自身も証明書を発行しています)。証明書は、名前と公開キーを結びつけるための標準的な手法です。

証明書技術を使用することにより、User B の証明書が改ざんされていないかどうかを誰でも検査できるようになります。User B が秘密キーを厳重に保管しており、かつ証明書を正式に取得している限り、証明書技術のセキュリティは保たれます。これに従ってプロトコルを修正すると、以下のようになります。
A->B B->A A->B B->Ahello Hi, I'm User B,User_B の証明書prove
it User A, This Is User B {digest[User A, This Is User B] }User_B の秘密キー
User B が最初に送信したメッセージが User A によって受信されると、User A は証明書を検査し、署名をチェックします。署名のチェックは、上記の例で説明されているダイジェストおよび公開キーの解読と同じ要領で行います。次にサブジェクト (つまり User B の名前) をチェックし、User B の名前になっているかどうかを確認します。このようにして、User A はこの公開キーが User B の公開キーであるということを信頼できるようになり、User B の身元の証明を要求できるようになります。

User B も上記と同じ手順を踏み、メッセージ ダイジェストを生成してから暗号化して User A に返信します。User A は、証明書から取り出した公開キーを使用して User B のメッセージ ダイジェストを確認します。

セキュリティで保護された通信に誰かが割り込んだ場合 (これを User C とします)、User C は次のような操作を行おうとする可能性があります。
A->C C->A A->C C->A hello Hi, I'm User B,User_B の証明書 prove
it ????
しかし、User C は User B の秘密キーを持っていないため、最終的に User A を信頼させるようなメッセージを作成できません。第三者である User C は、User B から発信されたということを User A に信じ込ませるようなメッセージをねつ造することはできません。

秘密情報の交換

User A が User B を認証した後、User A は User B のみが解読可能なメッセージを、以下のように User B に送信できるようになります。
A->B{secret}User_B の公開キー
secret の内容を知る唯一の方法は、User B が所有する秘密キーを使用して解読することです。公開キー暗号化の強力な使用法の一つに、秘密情報の交換があります。たとえ User A と User B との通信が傍受されている場合であっても、第三者が秘密情報の内容を特定することはできません。

交換する秘密情報として、DES (Data Encryption Standard)、RC4、IDEA などの対称型暗号化アルゴリズムのキーを使用することにより、インターネット上のセキュリティをさらに強化することができます。User A はこの秘密情報を発信する側であるため、User B に秘密情報を発信する前にその内容を把握しています。User B は秘密キーを持っていて User A のメッセージを解読することができるため、秘密情報の内容を知ることができます。このようにして、User A と User B が秘密情報を共有できるようになったため、ここからは対称型暗号化アルゴリズムを使用して暗号化した情報を互いに送信できるようになります。この技術を使用することにより、プロトコルは次のように修正されます。
A->B B->A A->B B->A A->B B->A hello Hi, I'm User B,User_B の証明書
prove it User A, This Is User B {digest[User A, This Is User B] }User_B の秘密キー
ok User B, here is a secret {secret}User_B の公開キー {some_message}secret_key
secret_key を計算するのに使用される手法は、定義されるプロトコルによって異なりますが、secret_key は秘密情報の単なるコピーでも構いません。

セキュリティへの干渉

これまで説明した技術をすべて使用したとしても、セキュリティで保護された通信に干渉しようとする User C のようなユーザーを完全に排除できるとは限りません。User A と User B が共有している秘密情報を User C が発見できないとしても、秘密情報を組み替える、または改ざんすることによって干渉することができる場合があります。たとえば、User A と User B との間の通信経路に User C がいるとします。このとき、User C は受け取った情報の特定のメッセージを改ざんし、それ以外の情報はそのままにして反対側の相手に渡すことができる場合があります。User A と User B が通信に使用しているプロトコルを User C が知っている場合、これは容易に実行できます。
A->C C->B B->C C->A A->C C->B B->C C->A A->C C->B B->C C->A
hello hello Hi, I'm User B,User_B の証明書 Hi, I'm User B,
User_B の証明書 prove it prove it User A, This Is User B {digest[User A,
This Is User B] }User_B の秘密キー User A, This Is User B {digest[User A, This Is
User B] }User_B の秘密キーok User B, here is a secret {secret}User_B の公開キー
ok User B, here is a secret {secret}User_B の公開キー {some_message}secret_key
Garble[ {some_message}secret_key]
User C は、User A と User B が秘密情報を共有するまでは、データを改ざんしないようにします。秘密情報が共有された直後から、User B が発信したメッセージを改ざんして User A に送信します。この時点では、User A は User B を信頼しているため、User A は改ざんされた情報を使用して何らかの操作を実行しようとします。ここで重要なのは、User C は秘密情報の内容を知らなくても干渉可能である点ですが、User C は、秘密キーで暗号化されたデータ部分を破損させる以外には何もできません。ほとんどの場合、User C が正当なメッセージを作成することはできませんが、使用するプロトコルの種類によっては偶然正当なメッセージを生成できる可能性があります。

このような攻撃を防ぐには、User A と User B がメッセージ認証コード (Message Authentication Code : MAC) をプロトコルに追加するという方法があります。メッセージ認証コードとは、送信された何らかの秘密情報を使用して算出されたデータの一部です。上記で説明されているダイジェスト アルゴリズムは、メッセージ認証コードを生成する関数を作成するのに必要な性質を備えており、これを使用して User C に対抗することができます。
message_authentication_code:=digest[some_message,secret]
User C は秘密情報の内容を知らないため、User C はダイジェストの正しい値を算出することはできません。ダイジェスト データが十分大きい場合、User C がメッセージをランダムに改ざんしても成功する確率はきわめて低くなります。たとえば、MD5 (RSA が開発した高品質な暗号化ダイジェスト アルゴリズム) を使用することによって、User A および User B は 128 ビットのメッセージ認証コード値をメッセージに含めることができます。メッセージに対応するメッセージ認証コード値を User C が正しく推測できる可能性は、およそ 18,446,744,073,709,551,616 分の 1 となり、事実上 User C はメッセージ認証コード値を推測することはできません。

この技術を使用してプロトコルを修正すると、以下のようになります。
A->B B->A A->B B->Ahello Hi, I'm User B,User_B の証明書 prove
it User A, This Is User B {digest[User A, This Is User B] }User_B の秘密キー ok
User B, here is a secret {secret}User_B の公開キー {some_message,message_authentication_code}secret_key
User C がメッセージを改ざんしようとしても、User A は、メッセージ認証コードを計算することによって、そのメッセージが User B から送信されたものではないことを確認できます。これにより、メッセージ認証コード値が正しくないことが User A と User B によって発見され、両者は通信を停止します。User C は User B になりすますことはできません。

関連情報

この資料は米国 Microsoft Corporation から提供されている Knowledge Base の Article ID 245152 (最終更新日 2002-08-06) をもとに作成したものです。

プロパティ

文書番号: 245152 - 最終更新日: 2004年5月5日 - リビジョン: 4.0
この資料は以下の製品について記述したものです。
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
キーワード:?
exc4 exc55 kbinfo KB245152
"Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。"
サポート期間が終了した「サポート技術情報」資料に関する免責事項
この資料は、マイクロソフトでサポートされていない製品について記述したものです。そのため、この資料は現状ベースで提供されており、今後更新されることはありません。

フィードバック

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com