MITコース「コンピューターシステムのセキュリティ」。 講義1：はじめに：脅威モデル、パート2

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

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



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



政府があなたを迫害していると思う場合、インストールされているプログラムに関係なく、コンピューターに悪意のある物理デバイスが含まれている可能性があるため、セキュリティの問題はさらに深刻になります。 したがって、脅威モデルの作成には慎重にアプローチし、特定の相手に対して最良の方法でバランスを取る必要があります。 NSAに立ち向かうのは費用がかかりすぎると思いますが、Athenaのホームディレクトリを他の学生から保護しようとする場合、あまり心配する必要はありません。 そのため、最適な脅威モデルを作成することは、さまざまなセキュリティ要件のバランスを取るように見えます。



悪い脅威モデルのもう1つの例は、訪問したサイトの証明書をチェックすることによりインターネットセキュリティを提供する方法です。







これらのSSL / TLSプロトコルでは、サイトに接続すると、アドレスバーにHTTPSの値、つまり「安全な接続」が表示されます。 このサイトは、認証局の1つによって署名されたセキュリティ証明書を受け取っており、このキーが実際にAmazon.comによって所有されていることを確認しています。



アーキテクチャの観点から見ると、脅威モデルのエラーは、これらすべてのCA承認センターが信頼できるものであり、間違いを犯さないと想定していることです。 しかし実際には、何百ものCAがあります。インドの郵便局には独自の認証センターがあり、中国政府にはそれがあります。 また、これらのセンターはいずれも、ホストまたはドメインのセキュリティ証明書を作成できます。 そのため、悪意のあるユーザーがGmailの信用を失ったり、サイトをハッキングしたい場合は、これらの認証センターの1つを侵害するだけで済みます。 そして、このためにあなたは常にあまり開発されていない国でCAを見つけることができます。 したがって、すべての認証済みサイトが安全であるという仮定に基づいて脅威モデルを作成することは間違っています。 世界中に散在する300の認証センターすべてが安全であると仮定するのは誤りだからです。



ただし、これにもかかわらず、最新のSSLプロトコルでは、インターネットブラウザのセキュリティメカニズムの基盤としてこの仮定が依然として使用されています。



脅威が予想外の場所から来た場合、この種の例が数多くあります。 80年代の面白い例は、国防総省の高度な研究プロジェクトであるDARPAによって実装されたプロジェクトです。 その後、彼らは本当に不死身のオペレーティングシステムを作りたいと望み、安全なオペレーティングシステムのプロトタイプを開発しなければならなかった多くの大学や研究者を引き付けました。







その後、彼らはこれらの安全なシステムを何らかの方法でクラックすることになっている「悪者」のチームを作りました。 その結果、すべてのOSのソースコードが保存されているサーバーは、完全に保護されていないオフィスのコンピューターに配置されていました。 「悪者」はこのサーバーに簡単にハッキングし、ソースコードを変更し、それに基づいてOSに抜け穴を作りました。 その後、研究者がオペレーティングシステムを構築したとき、これらの偽のハッカーは抜け穴を利用し、それほど困難なくそれらをクラックしました。



だから、あなたのシステムが本当に安全であることを確認するために、あなたのソフトウェアがどこから来たのか、そして男がどれほど悪意を持って侵入できるのかについて、考えられるすべての仮定について本当に考える必要がある。 講義ノートには、この主題に関する多くの例があります。



おそらく最も一般的な問題はセキュリティメカニズムです。 これは、セキュリティを実装するメカニズムが最も難しい部分であるためです。 これは、ソフトウェアとハ​​ードウェアの組み合わせであり、セキュリティポリシーを実装するシステムの他のコンポーネントです。 そして、このメカニズムが壊れる理由は無数にあります。



したがって、講義のほとんどは、セキュリティメカニズム、セキュリティポリシーの適切な適用を保証するメカニズムの作成方法に特化しています。 また、セキュリティポリシーと脅威モデルについても説明します。



特定のシステムの内容に「適合する」必要があるポリシーや脅威モデルに取り組むよりも、メカニズムの開発に関する明確で正確な原則を作成し、メカニズムが機能するかどうかを理解する方がはるかに簡単です。



セキュリティメカニズムを作成する際のエラーの例を見てみましょう。 数日前に後者のケースについて聞いたことがあります-それはAppleのiCloudクラウドサービスのセキュリティメカニズムの問題に関するものです。 iPhoneを持っている人は誰でもiCloudサービスを使用できます。 このサービスはクラウドベースのファイルストレージであり、iPhoneを紛失してもファイルは引き続きこのクラウドに保存され、紛失した場合に携帯電話を見つけるのに役立ち、さらに多くの便利な機能が含まれています。 このiCloudは、数年前に同じスキームに従って作成されたme.comサービスの「相対的な」ものだと思います。

iCloudで発見された問題は、作成者がすべてのインターフェイスに同じセキュリティメカニズムを使用していなかったことです。 このサービスの外観を検討してください。







ファイルストレージ、写真アーカイブ、電話検索など、さまざまなサービスがiCloudサービスに接続されています。 これらのサービスはすべて、あなたが正しいユーザーであること、正しい認証に合格したことを確認します。 おそらく、さまざまなアーティストがこの複雑なサービスの開発に関与し、含まれるサービス用にさまざまなセキュリティインターフェイスを作成しました。 たとえば、Find My iPhoneサービスは、システムにログインしようとした行の数を追跡しませんでした。 この機能は非常に重要です。先ほど述べたように、人々は本当に強力なパスワードを作成する必要はありません。

実際、パスワードを使用してユーザーを認証するシステムは非常に「難しい」ものです。これについては後で説明します。 しかし、1つの優れた戦略があります。選択された100万のパスワードの中から、間違いなくあなたのアカウントに合ったものがあります。 したがって、このアカウントに対して100万のパスワードオプションを作成できる場合、複雑なパスワードを作成する必要がないので、おそらくそれを使用できます。



したがって、パスワードの推測を防ぐ方法の1つは、システムが連続して何度もログインを無制限に試行することを許可しないことです。 3回または10回失敗すると、システムはタイムアウトをアクティブにし、10分後、または1時間後でもパスワードの再入力を求めるプロンプトを表示することがあります。 これにより、ハッカーは1日に数百万回ではなくパスワードの推測を数回試みることができるため、ハッカーの速度が大幅に低下します。 また、パスワードがそれほど難しくない場合でも、時間の損失が大きいため、攻撃者がパスワードを取得することは困難です。



しかし、Find My iPhoneインターフェースにはそのような機能はありません。 「悪者」は、パスワードで1日に100万パケットを送信し、このサービスをハッキングし、iCloudの機密データを盗むことができます。



これは、適切なセキュリティポリシーが設定されている例です。正しいユーザーと正しいパスワードのみがファイルにアクセスできます。 悪者がパスワードを推測しようとするというセキュリティ脅威の正しいモデルさえ持っていたので、入力試行回数を制限することでこれを止める必要があります。 ただし、そのセキュリティメカニズムにエラーが含まれていたため、サービスの開発者は単に台無しになりました。 彼は、1つのインターフェイスに適切なポリシーと適切なメカニズムを適用するのを忘れていました。



そして、これはさまざまなシステムで繰り返し発生し、一度ミスをしただけであり、システム全体のセキュリティに影響を与えました。 開発者が一般的にアクセス制御を確認するのを忘れた場合など、この種のエラーが多数あります。



たとえば、City Bankには、クレジットカード情報を表示できるWebサイトがあります。 つまり、この銀行のカードを持っている場合は、サイトにアクセスすると次のことがわかります。



「はい、あなたはこのクレジットカードを持っています、ここにあなたの取引があります」など。 数年前、作業手順は、あるサイトにアクセスし、ユーザー名とパスワードを入力すると、たとえばciti.com/account?id=1234などのアドレスを持つサイトにリダイレクトされます。 これらの番号を変更するだけで、他の人のアカウントに自由にログインできると推測する人がいることがわかりました。 それで、そのようなシステムの開発者についてどう考えるかが明確ではありませんか？







おそらくこれらの人は正しく考えていましたが、アカウントページでセキュリティ機能がどのように機能するかを確認するのを忘れていました。つまり、正しいID番号を取得できるだけでなく、ログインしたばかりの人のID番号も取得できます。 これは重要なテストですが、彼らはそれを忘れていました。



または、開発者は、あなた以外は誰もこのURLを使用できないと考えていたのでしょうか？ たぶん、彼らは悪い脅威モデルを持っていたのでしょうか？ このアドレスをリンクとして印刷しないと、だれも「クリック」できないと思ったのでしょうか。 これは、悪い脅威モデルの例です。 そうかもしれませんが、いずれにしても、そのような製品をリリースするときに彼らが何によって導かれたかを言うのは難しいです。 このようなエラーは頻繁に発生し、セキュリティメカニズムのわずかな目立たないスリップでさえ、悲しい結果につながる可能性があります。



識別エラーがそれほど多くないもう1つの例は、数か月前にAndroidスマートフォンで識別された問題です。 この問題はビットコインに関連していた、あなたはそれらについて聞いたことがあると確信しています-これは最近非常に人気のある電子通貨です。 ビットコインシステムの動作方法は非常に高度であり、バランスは秘密キーの使用に関連付けられています。 したがって、他の誰かの個人キーを持っている場合、そのビットコインを使うことができます。 ビットコインのセキュリティは、誰もあなたの鍵を知らないという仮定に基づいています。 パスワードを使用するようなものです。重要なのは、人々があなたの鍵を解こうと何度も試みることができるからです。 ただし、キーをチェックするための実サーバーはありません。 これは単なる暗号化です。 したがって、どのコンピューターでもキーの復号化を試みることができ、成功した場合は、ビットコインを他の誰かに転送できます。 したがって、誰も解決できない信頼性の高い複雑なキーを生成することが非常に重要です。



Androidを実行しているスマートフォンからビットコインを使用する人がいます。 ビットコインのランダムキー値を生成するSecureRandomと呼ばれるJava APIモバイルアプリケーションがあります。 しかし、実際には、これらはまったく乱数ではないことがわかりました。 このアプリケーションには、疑似乱数ジェネレーター（PRNG）が含まれています。 SecureRandomは、PRNGが任意の数のランダムビットに「ストレッチ」できるランダムな数百ビットの初期配列を設定します。 つまり、最初に一種の「シード」である元の配列を使用し、次にそこから任意のビット数を生成します。つまり、キーのクロップを増やします。







さまざまな暗号化の原則のおかげで、私はそれらには触れません;それは本当に機能します。 最初にこのPRNGに数百の真にランダムなビットを提供する場合、どの擬似乱数が生成されるかを推測することは非常に困難です。 しかし問題は、このJavaライブラリーに小さなエラーがあったことです。 特定の状況下で、彼女はPRNGに初期値を提供するのを忘れ、配列はゼロで構成されていました。 これは、PRNGがキーに対して生成した乱数をだれでも見つけられることを意味していました。 それらがゼロで始まる場合、それらは同じ値を生成し、クラッカーはあなたと同じ個人キーを簡単に取得します。 つまり、単にキーを生成し、ビットコインを破棄します。

これは、セキュリティメカニズムにおける一見小さなエラーが悲惨な結果につながる可能性がある別の例です。 多くの人々はこのためにビットコインを失いました。 もちろん、このようなエラーはあるレベルで修正されます; SecureRandomアプリケーションのJava実装を変更して、PRNGを常にソースビットのランダムな配列で埋めるようにすることができます。 しかし、いずれにせよ、これはセキュリティメカニズムの誤動作の別の例です。



聴衆からの質問：



-これがDSAデジタル署名作成アルゴリズムに対する攻撃と異なるかどうかを説明してください



答えは：



-実際、問題はあなたが示唆しているものよりもはるかに複雑です。 問題は、Androidデバイスで最初にキーを生成しなかった場合でも、特定のBitcoin署名スキームは、このキーを使用して新しい署名を生成するたびに、1回限りのフレッシュまたは「nonce」 »そのような世代のソース。 また、1つのソースに基づいて2つの署名を生成した場合、誰かがキーを繰り返すことができます。



これらのケースは似ていますが、詳細が異なります。 Android以外の場所でキーを生成でき、本当に信頼できるキーである場合、同じナンスまたはランダムな値から2つの署名を生成しようとするたびに、誰かが複雑な数学的計算を使用してあなたのものを計算できますそれらから公開鍵に署名して抽出します。 または、より重要なのは、個人キーです。



コンピューターセキュリティの詳細が重要であることを再度指摘しておきます。 たとえば、何かをチェックするのを忘れたり、ソースデータのランダム配列を初期化するのを忘れるなど、一見取るに足りない間違いを犯すと、システム全体に深刻な結果をもたらす可能性があります。



システムの機能、特性、システムの機能、および隅々にどんな驚きが潜んでいるかを明確に把握しておく必要があります。 この意味で、システムをハッキングする方法、あらゆる側面からシステムをテストする方法について考えるのは良いことです。たとえば、あまりにも多くの無料アクセスを与えるとどうなりますか。 あらゆる種類のギャップを埋めるために、どのようなデータをシステムに配置する必要がありますか？



このあいまいさの良い例の1つは、証明書自体の名前を暗号化するSSL証明書です。 この問題は、CAの信頼とは異なります。 SSL証明書は、Webサーバーから送信される一連のバイトです。 この証明書の中には、接続先のリソースの名前があります（例：Amazon.com）。 これらのバイトを単に書き込むことはできないことを知っています。 何らかの方法でそれらを暗号化し、Amazon.comであることを示し、行の最後に配置する必要があります。



そのため、SSL証明書は、Amazon.comが記録する特定の暗号化スキームを使用し、最初に文字列のバイト数を書き留めます。



まず、それらを書き留める必要があります。 Amazon.comという10バイトの文字列があり、実際には10バイトで構成されているとします。 いいね 名前とドットの文字である10バイトがあり、文字列のこれらの10バイトの前後には、他の文字が存在する場合があります。



次に、Cで記述されたブラウザがこれらのバイトを処理に取り込みます。 この言語は、文字列の終わりを示す0で文字列を表します。 したがって、Cには行長カウンターはありません。 代わりに、すべてのバイトを考慮し、その行の終わりは単なるヌルバイトです。 C行の最後にバックスラッシュを付けて書き込みます-「\」、つまり、amazon.com \ 0のようになります。







これらはすべてブラウザのメモリにあります。 彼の記憶のどこかに、11バイトの文字列があり、最後にゼロがあります。 ブラウザはこの行を解釈すると、行の終わりにゼロマーカーが表示されるまで続けます。



聴衆からの質問：



-行の途中に0がありますか？



答えは：



-はい、そうです。 この意味で、ブラウザが文字列をどのように解釈するかを理解することには一定のギャップがあります。



foo.comドメインを所有しているとします。 「what- please foo.com」で証明書を取得できます。 したがって、amazon.com \ 0x.foo.comという名前の証明書を要求することもできます。 ブラウザの観点から見ると、これは完全に正しい行です。 これは、20バイトで構成される20バイトの名前です。



以前は、CA承認センターにアクセスして、「おい、foo.comを所有しているので、このことの証明書をくれ！」と言うことができました。 そして、amazon.com0xはfoo.comのサブドメインであり、完全にあなたのものであるため、彼らはこれを行うために完全に準備されます。



しかし、その後、ブラウザがこの行を取得してメモリにロードすると、先ほど説明したのと同じことを行います-行をコピーします。 amazon.com0x.foo.comを追加し、この行の末尾に別のゼロを追加します-amazon.com \ 0x.foo.com \ 0



, , , 0 , : «, !» , . Amazon.com.



, SSL . (Moxie Marlinspike), .



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







, , . 6.033. , . , , , -.



, , -. - – , , , , , , , - . URL - , , - . , , , - .



, . ?



, . , , . - , . , - , , , .



, , -, , , . , , , , , . . , . , .



, , - , - . , , . , , - - .







, , -, . – , , , , , , . -, .



, , . , ( , , ), , . SSL-, . .

, .







, , . , . , . , , . , , . .







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







, , . 1234 = 1234, 28 ( = 2147483647) 10 . , .



19 = 0. , . . , , , 3 ? !



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



: MIT « ». 1: «: », 3





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



ご滞在いただきありがとうございます。 私たちの記事が好きですか？ より興味深い資料を見たいですか？ 注文するか、友人に推奨することで、私たちをサポートします。Habrユーザーが独自に発明したエントリーレベルサーバーのユニークな類似品で30％割引： VPS（KVM）E5-2650 v4（6コア）10GB DDR4 240GB SSD 1Gbps 20ドルまたはサーバーを分割する方法？ （オプションはRAID1およびRAID10、最大24コア、最大40GB DDR4で利用可能です）。



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サーバーを使用していますか？