MITコース「コンピューターシステムのセキュリティ」。 講義14：「SSLとHTTPS」、パート1

マサチューセッツ工科大学。 講義コース6.858。 「コンピューターシステムのセキュリティ。」 ニコライ・ゼルドヴィッチ、ジェームズ・ミケンズ。 2014年

コンピューターシステムセキュリティは、安全なコンピューターシステムの開発と実装に関するコースです。 講義では、脅威モデル、セキュリティを危険にさらす攻撃、および最近の科学的研究に基づいたセキュリティ技術を扱います。 トピックには、オペレーティングシステム（OS）セキュリティ、機能、情報フロー管理、言語セキュリティ、ネットワークプロトコル、ハードウェアセキュリティ、およびWebアプリケーションセキュリティが含まれます。



講義1：「はじめに：脅威モデル」 パート1 / パート2 / パート3

講義2：「ハッカー攻撃の制御」 パート1 / パート2 / パート3

講義3：「バッファオーバーフロー：エクスプロイトと保護」 パート1 / パート2 / パート3

講義4：「特権の共有」 パート1 / パート2 / パート3

講義5：「セキュリティシステムはどこから来たのか？」 パート1 / パート2

講義6：「機会」 パート1 / パート2 / パート3

講義7：「ネイティブクライアントサンドボックス」 パート1 / パート2 / パート3

講義8：「ネットワークセキュリティモデル」 パート1 / パート2 / パート3

講義9：「Webアプリケーションのセキュリティ」 パート1 / パート2 / パート3

講義10：「シンボリック実行」 パート1 / パート2 / パート3

講義11：「Ur / Webプログラミング言語」 パート1 / パート2 / パート3

講義12：ネットワークセキュリティパート1 / パート2 / パート3

講義13：「ネットワークプロトコル」 パート1 / パート2 / パート3

講義14：「SSLおよびHTTPS」 パート1 / パート2 / パート3



次に、インターネット上のネットワーク接続を保護するために暗号化プロトコルがどのように使用され、それらが一般的にネットワーク要素とどのように相互作用するかを見ていきます。 詳細を掘り下げる前に、水曜日にテストがありますが、この聴衆ではなく、通常の講義時間中に3階のウォーカーでテストが行​​われることを思い出してください。







そこで、今日は、インターネットが暗号化を使用してネットワーク接続を保護する方法について説明し、密接に関連する2つのトピックを検討します。



1つ目は、前回の講義で説明したKerberosシステムが保護するよりも大規模な暗号化接続を保護する方法です。 2つ目は、ネットワークレベルで提供されるこの暗号化保護をアプリケーション全体に統合する方法と、暗号化プロトコルが提供する保護の使用をWebブラウザが保証する方法です。 これらのトピックは密接に関連しているため、暗号化は常に機能するため、ネットワーク通信の保護は非常に簡単に提供できます。 しかし、それをブラウザに統合することは、暗号化を中心としたシステムを構築することよりもはるかに難しいタスクです。



この議論に入る前に、私たちが使用する暗号の基本的な要素を思い出したいと思います。



Kerberosに関する前回の講義では、対称暗号を使用しました。または、

暗号化と復号化。 その意味は、秘密鍵Kと2つの関数を持っているということです。 したがって、データの一部を取得することができます。これをPと呼びます。これは暗号化機能を適用できるプレーンテキストであり、これはキーKの機能です。このプレーンテキストを暗号化すると、暗号化テキストCが得られます。同じキーKを使用する解読関数Dがあり、その結果、暗号化されたテキストCはプレーンテキストPに変わります。これは、Kerberosが構築されたプリミティブです。







しかし、今日の議論に役立つ、非対称暗号化および復号化と呼ばれる他のプリミティブがあることがわかります。 ここでの考え方は、暗号化と復号化に異なるキーを使用することです。 これがなぜそんなに役立つのか見てみましょう。



ここには関数Eがあり、これは特定の公開鍵pkで特定のメッセージPのセットを暗号化して、結果として暗号化されたテキストCを受信できます。関数Dで暗号化を解除するには、対応する秘密鍵skを指定してソーステキストPを取得するだけです







非対称暗号化の便利さは、インターネット上で公開鍵を公開でき、人々があなたのためにメッセージを暗号化できることですが、メッセージを解読するには秘密鍵が必要です。 今日は、これがプロトコルでどのように使用されるかを見ていきます。 実際には、公開鍵暗号化をわずかに異なる方法で使用することがよくあります。 たとえば、メッセージを暗号化および復号化する代わりに、メッセージの署名または検証が必要になる場合があります。



実装レベルではこれらは関連する操作ですが、APIアプリケーションレベルでは少し異なるように見える場合があります。 たとえば、秘密鍵skでメッセージMに署名し、署名Sを取得できます。次に、対応する公開鍵pkでこのメッセージを検証し、その結果、署名MがメッセージMに対して正しいかどうかを示す論理フラグを取得できます。







これらの機能を提供する比較的直感的な保証がいくつかあります。 たとえば、この署名を受け取って正しく検証された場合、正しい秘密鍵を持つ誰かが生成する必要があったことを意味します。 それは明らかですか？



次に、Kerberosよりも大規模にネットワーク接続を保護する方法を考えてみましょう。 Kerberosでは、かなり単純なモデルがあり、すべてのユーザーとサーバーが、ユーザー、サービス、およびキーのこの巨大なテーブルを持つKDCオブジェクトと何らかの接続を使用していました。 ユーザーがサーバーと通信したいときはいつでも、この巨大なテーブルに基づいて必要なチケットを作成するようにKDCに要求する必要があります。







したがって、これはかなり単純なモデルのように見えます。 では、なぜ他の何かが必要なのでしょうか？ なぜサイトでの作業にはKerberosが十分ではないのですか？ インターネットがすべての接続を保護するためにKerberosを排他的に使用しないのはなぜですか？



あなたは正しく答えました-唯一のKDCが全員を信頼するべきであり、これは悪いからです。 特定のマシンが完全に安全であると考えると、問題が発生する可能性があります。



おそらくMITの人々は、KDCが管理するローカルネットワーク上の誰かを信頼するつもりはありますが、インターネット上の全員ではありません。



2番目の生徒の答えも正しいです。このような膨大な数のキーを管理することは非常に困難です。 実際、世界中のすべての人のために10億個または100億個のキーを管理できる単一のKDCを構築することは非常に困難です。 インターネット全体でKerberosを使用するもう1つの問題は、すべてのユーザーがキーを持っているか、KDCが知っている必要があることです。 Kerberosデータベースにアカウントがない場合、研究所でKerberosを使用して一部のサーバーに接続することもできません。 インターネット全体では、コンピューターにアクセスしたときに自分が誰であるかをまったく知らないことを期待するのは非常に合理的ですが、暗号化によって保護されているAmazon Webサイトにアクセスできます。







え？



暗号化プロトコルに期待するものが他にもいくつかあります。それらがSSLでどのように表示されるかを見ていきます。 しかし、重要な考え方は、このソリューションはKerberosとSSLまたはTLSで同じであるということです。 講義資料で読んだ元のKerberosプロトコルはかなり前に開発されたと言ったのは正しいことです。 そして、それらを現代のインターネットに使用したい場合、彼らは何かを変更する必要があります。 他にどんな考えがありますか、なぜKerberosを使用しないのですか？



そうです、アクセスを復元するとき、およびおそらく新しいユーザーを登録するときにスケーリングの問題があります。なぜなら、個人的にいくつかのアカウントオフィスに行ってそこにアカウントを取得する必要があるからです。 他に何？



学生： Kerberosサーバーは常にオンラインである必要があります。



教授：はい、これは別の問題です。 何らかの管理上の問題をリストしましたが、プロトコルレベルでは、KDCは常にオンラインである必要があります。実際には、サービスとのやり取りの仲介役として機能するからです。 つまり、新しいWebサイトにアクセスするたびに、KDCと話す必要があります。 まず、パフォーマンスの点でボトルネックになります。 別のタイプのスケーラビリティと同様に、この原則はパフォーマンスのスケーラビリティにつながりますが、上記の原則は管理のスケーラビリティにつながります。







では、これらの原則を使用してこの問題をどのように解決できますか？ アイデアは、キー暗号化を使用してKDCの使用を停止することです。



相手側の公開鍵の一部を知っているだけで、安全な接続を確立できるかどうかをまず確認しましょう。 そして、KDC公開キーバージョンをこのプロトコルの関係者の認証に接続する方法を確認します。 KDCを使用しない場合は、公開キー暗号化を使用して次の操作を実行できます。接続の反対側でパートナーの公開キーを何らかの方法で確認します。 したがって、Kerberosでは、ファイルサーバーに接続する場合、どこからでもファイルサーバーの公開キーを知っているだけです。 新入生として、ファイルサーバーの公開キーがそのようなものであるという印刷物を受け取り、それを使用して接続できます。



接続するファイルサーバーの公開キーのメッセージを単純に暗号化できます。 しかし、実際には、これらの公開キーを使用したこれらの操作は非常に遅いことがわかりました。 対称暗号化キーよりも数桁遅いです。 そのため、実際には、通常、パブリック暗号化の使用を常に放棄する必要があります。



したがって、典型的なプロトコルは次のようになります。 AとBがいて、彼らは通信を望んでおり、Aは公開鍵Bを知っています。同時に、Aは何らかの乱数を選択してセッションキーSを生成します。 その後、AはSセッションキーBを送信しようとしているため、Kerberosのように見えます。 BのセッションキーSを暗号化します。



Kerberosでこれを行うには、AがBのキーを知らなかったか、またはBだけが知ることができる秘密であるため、彼がそれを知ることを許可されなかったため、KDCが必要でした。すぐに、このBspk公開キーで秘密を暗号化し、メッセージBを送信します。これで、Bはこのメッセージを解読し、次のように言うことができます。 これで、すべてのメッセージがこの秘密鍵Sで単純に暗号化される通信チャネルができました。







したがって、このプロトコルにはいくつかの便利な機能があります。 まず、KDCをオンラインにしてセッションキーを生成する必要性を取り除きました。 接続の当事者の1人がそれを生成し、KDCを使用せずに相手側のために暗号化する場合、送信された情報の機密性を確保することができます。



もう1つの良い点は、Bだけがこのメッセージを解読できるため、BだけがAからBに送信されたメッセージを読むことができるという自信です。 したがって、Bには対応する秘密キーSが必要です。



学生：ユーザーまたはサーバー-このキーを誰が与えるかは重要ですか？



教授：多分。 このプロトコルに必要なプロパティに依存すると思います。 したがって、Aがミスをした場合、または間違ったランダム性を使用した場合、データを送信するサーバーは、「ああ、これがAに表示される唯一のデータです」と考えます。 これは完全に正しいとは限りませんので、考えてみてください。 このプロトコルには他にもいくつかの問題があります。



学生：攻撃者はキーを使用して繰り返しメッセージを送信できますか？



教授：はい、問題は、これらのメッセージをもう一度送信できるだけで、AがメッセージBを再度送信するように見えることなどです。



したがって、通常、この問題の解決策は、接続の両側がSの生成に関与することであり、これにより、使用するキーが「新鮮」になります。 ここで、図では、実際にはBは何も生成しないため、これらのプロトコルメッセージは毎回同じに見えるためです。



通常、一方がSなどの乱数を選択し、次に他方のBが通常ナンスと呼ばれる乱数も選択することがあります。 2つの数字と、実際には片側だけで選択されるのではないキーがあります。これは、両側が共同の相互作用のために選択したハッシュです。 ハッシュに加えて、Diffie-Hellmanプロトコルを使用できます。Diffie-Hellmanプロトコルは、前回の講義で検討しましたが、そのおかげでプライバシーが最初に得られます。 これは、これら2つの側面を選択した2つの乱数を単にハッシュするよりも複雑な数学です。 ただし、元の共有秘密キーなどの優れたプロパティが取得されるため、暗号化されたデータを送信するときに復号化キーを転送する必要がなくなります。



したがって、次のように繰り返し攻撃を回避できます。 Bはナンスを生成してから、実際の秘密鍵S 'を設定します。これは、このナンスで秘密鍵Sをハッシュするために使用されます。 そしてもちろん、BがAにノンスを返送して、両者がキーに同意したときに何が起こるかを調べる必要があります。







もう1つの問題は、実際の認証Aがないことです。AはBが誰であるかを知っているか、少なくとも誰がデータを解読できるかを知っています。 しかし、Bが他の誰かになりすましている敵であるか、他の誰かに見せかけているのか、Bには相手が誰なのかわかりません。 これを公開鍵の世界でどのように修正できますか？



これを行うにはいくつかの方法があります。 1つの可能性は、この良い署名の原則があるため、最初にこのメッセージに署名することです。 したがって、おそらく秘密鍵でこれに署名できます。 この署名は単に署名を提供しますが、おそらくあなたはそれを割り当て、このメッセージも提供します。



次に、Bは、署名を検証するためにAが公開鍵であることを知っている必要があります。 しかし、BがAが公開鍵であることを知っている場合、BはAがこのメッセージを送信した人であることをかなり確信します。







もう1つできることは、暗号化に対する信頼です。 したがって、おそらくBはAに提供された公開鍵で暗号化してノンスをAに送り返すことができます。そして、Aのみがノンスを解読し、最終セッションキーS 'を生成できます。 だからあなたができるいくつかのトリックがあります。 これが、今日のインターネットブラウザでのクライアント証明書の機能です。



したがって、Aは秘密鍵を持っているため、個人のMIT証明書を受け取ると、ブラウザーは長命の秘密鍵を作成し、その証明書を受け取ります。 Webサーバーに要求を送信するたびに、ユーザー証明書の秘密キーを知っていることを証明し、接続の残りの部分に秘密キーSを設定します。



これらは、プロトコルレベルで簡単に修正できる問題です。 ただし、上記のすべての根拠は、すべての関係者が互いの公開鍵を知っていることです。 誰かの公開鍵を見つけるにはどうすればいいですか？ Webサイトに接続したい、接続したいURL、またはホスト名があり、どの公開キーがそれに一致するかを調べるにはどうすればよいですか？



同様に、成績を確認するためにMITサーバーに接続する場合、サーバーは他のMIT学生の公開鍵と区別するために公開鍵がどうあるべきかをどのように知るのですか？



これは、KDCが対処した主な問題です。 実際、KDCは2つの問題を解決しました。 まず、メッセージ（Ebspk（S））を生成し、セッションキーを作成して、サーバー用に暗号化しました。 現在、公開鍵暗号を作成することでこれを修正しています。 ただし、メインの文字列名を、以前に提供されたKerberos暗号化キーにマップする必要もありました。



HTTPSの世界には、そのようなもののためのTLCプロトコルがあります。 その意味は、プロセス参加者の名前を暗号化キーにマッピングするこれらの巨大なテーブルをサポートするプロセスの特定の側面に依存し続けることです。 計画では、認証局と呼ばれるものを用意します。これは、ネットワークセキュリティに関するあらゆる種類の文献でCAという文字で示されています。 また、このCAは論理的にテーブルをサポートします。テーブルの一部にはすべての参加者の名前が表示され、もう一方には対応する公開キーが表示されます。 このセンターとKerberosの主な違いは、このCAがすべてのトランザクションでオンラインである必要がないことです。

Kerberosでは、誰かと接続したり、誰かのキーを見つけたりするために、KDCと話す必要があります。 代わりに、CAの世界がこれを行います。







ここに何らかの名前の名前があり、テーブルの別の部分に対応するキーキーがある場合、認証局はこのテーブルに特定の行が存在するというメッセージに単純に署名します。 したがって、認証局は独自の秘密鍵と公開鍵をここで保持する必要があります。 彼は秘密鍵を使用して、信頼できるシステム上の他のユーザーへのメッセージを見つけます。



したがって、CAデータベースに「名前+キー」レコードがある場合、CAは、この名前がこの公開鍵と一致するというメッセージを作成し、CA秘密鍵でこのメッセージに署名します。







これにより、Kerberosの機能と非常によく似たことが可能になりますが、同時にすべてのトランザクションについてCAをオンラインで検索する必要がなくなります。 そして、実際にははるかにスケーラブルになります。 これはまさに証明書と呼ばれるものです。 クライアントまたはこのシステムを使用する他の人にとって、あるソースから提供された証明書が他のソースからの証明書より劣っていないという事実により、スケーラビリティが確保されます。 証明機関の秘密キーによって署名されます。 したがって、実際に認証局やここにリストされている他の関係者に連絡することなく、その真正性を検証できます。



そのように動作します。 通信するサーバーには、最初に証明機関から受け取った証明書が格納されます。 そして、あなたがそれに接続するたびに、サーバーはあなたに言う：「OK、ここに私の証明書があります。 このCAによって署名されました。 署名を検証し、それが私の公開鍵であり、それが私の名前であることを確認するだけです。



一方、クライアント証明書でも同じことが起こります。 ユーザーがWebサーバーに接続すると、クライアント証明書は、公開キーがブラウザーで最初に生成された秘密キーと一致することを示します。 , , , MIT, , . , , , , Athena.



: , ?



: , , – , ? - , , , , . - , . . , VeriSign. US Postal Service CA, , . , CA , KDC.



, , Kerberos. , , KDC. , KDC, , . , , . CA , KDS.



: ?



: , . , , KDC, . , . , , . , , , . Kerberos, . Kerberos , . , , . , , . , .



, . , , CA - , . , amazon.com, amazon.com. CA, . , , , .







. , CA , , , , - , . , , . - , amazon.com, , - .



, -, , , , . , . «» , , .



, . -, CRL, ertificate Revocation List. . , - , . , , , : «, , , - . , ».



, , , CRL, , web-, CRL. , - , , . , , , , , .



, . , . , . , . , CRL, - .



, ? , . , CRL .



, , , Kerberos, KDC. CA , . , « SSL », OCSP. CA KDC. , , , , , , - . , OCSP, : «, . , »? , CRL . , , . , , .



26:30



MITコース「コンピューターシステムのセキュリティ」。 14: «SSL HTTPS», 2





コースの完全版はこちらから入手できます 。



ご滞在いただきありがとうございます。 ? より興味深い資料を見たいですか？ , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? （オプションはRAID1およびRAID10、最大24コア、最大40GB DDR4で利用可能です）。



VPS（KVM）E5-2650 v4（6コア）10GB DDR4 240GB SSD 1Gbpsまで 6か月の期間を支払う場合は12月まで無料で 、 ここで注文できます 。



Dell R730xdは2倍安いですか？ オランダと米国で249ドルからIntel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TVを2台持っているだけです！ インフラストラクチャの構築方法について読む クラスRは、1米ドルで9,000ユーロのDell R730xd E5-2650 v4サーバーを使用していますか？