MITコース「コンピューターシステムのセキュリティ」。 講義20：携帯電話のセキュリティ、パート3

マサチューセッツ工科大学。 講義コース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

講義15：「医療ソフトウェア」 パート1 / パート2 / パート3

講義16：「サイドチャネル攻撃」 パート1 / パート2 / パート3

講義17：「ユーザー認証」 パート1 / パート2 / パート3

講義18：「インターネットのプライベートブラウジング」 パート1 / パート2 / パート3

講義19：「匿名ネットワーク」 パート1 / パート2 / パート3

講義20：「携帯電話のセキュリティ」 パート1 / パート2 / パート3



学生：現在、多くのアプリケーションで権限を削除する方法はありません。



教授：はい、Androidの新しいバージョンではそうではなく、単に許可の説明があります。 ただし、Android Permission ManagerまたはAndroid Permission Managerを使用すると、各アプリケーションのすべての権限のリストを表示し、不要と思われる権限を具体的に削除できます。 しかし、私はこのことがユーザーの間でどのように人気があるのか​​わかりません。



学生：ラベルがアプリケーションに必要な許可と一致しない場合、これは重大なエラーにつながるか、すべてが引き続き正常に機能しますか？



教授：アプリケーションが何をしようとしているか、ラベルが何を許可しているかに依存すると思います。 たとえば、アプリケーションがインテントを送信する予定で、このインテントを送信するためにDIALPERMタイプの特定のラベルが必要な場合、最初にリンクモニターが表示されます。「残念ながら、システムにはメッセージを受信できるアプリケーションがありません。」 そして、このアプリケーションに対応して、いくつかの合理的な措置を講じています。







それ以外の場合、たとえば、ネットワークにアクセスするとき。 ネットワークにアクセスできず、ソケットを開くか、IPアドレスに接続するコマンドを送信しようとすると、カーネルはEPERM、「操作は許可されていません」というメッセージを返します。つまり、これを行うことはできません。 この場合、アプリケーションが何をするのか誰が知っていますか？ 何らかの方法でNULLポインター例外をスローしたり、そのようなことをしたりする可能性があります。



これに対する1つの議論は、Androidアプリケーションは、少なくとも最初は、呼び出しの一部が失敗することを期待していなかったということです。アプリケーションをインストールするかどうか。 そのため、アプリケーション開発者はコードを正しく記述しましたが、アクセスが拒否されるとクラッシュするか予期しない動作をします。 おそらく、必要なアクセス許可をアプリケーションから奪うことにより、その操作の失敗を引き起こします。



カメラにアクセスする必要があるアプリケーションがあるとします。 彼のアクセス権を奪うと、スマートフォンの画面に画像テンプレートが表示されるだけで、アプリケーションがクラッシュする可能性があります。 これはあまり良くありません。 おそらく、カメラへのアクセスが奪われた場合に常に黒い画面を表示するだけの、より複雑なシステムを作成することが可能でしょう。 Androidはこれを行いませんが、これが起こる可能性のある別の状況を想像できます。



そこで、Androidアプリケーションのラベルでこれらの行がどこから来たのかを調べました。 しかし、これらの行を定義するのは誰ですか、どこから意味を得るのでしょうか？ マニフェストファイルにはすべての種類の行をリストできますが、どの行が重要で、INTERNETまたはFRIENDVIEW行がどこから来たのかをどのように判断しますか？ システム内で誰が意味を与えますか？







あなたにはアイデアがありません。 これらの線はどれも魔法のようなものやあらかじめ決められたものであってはならないと思います。 これらの行のほとんどすべては、2つのアプリケーション間の基本的な合意です。アプリケーションの1つが特定のLabel行の保護下で何かを提供する準備ができており、他のアプリケーションがこのコンポーネントが提供するアプリケーションと話す許可を要求したい場合です。



したがって、これらのラベルは通常、いくつかのサービスを提供するアプリケーションによって決定されます。 DIALPERM権限がある場合は、アプリケーションで定義する必要があります。これにより、電話番号をダイヤルすることの意味が決まります。 どうやら、あなたの電話で電話をかけるためのアプリケーションは、この回線を定義し、はい、このDIALPERMのものが存在し、私のコンポーネントはそれによって保護されると言っています。 その後、呼び出し元のアプリケーションと対話する他のアプリケーションは、このDIALPERMアクセス許可を自分で要求できます。



もちろん、インターネットの使用許可、カメラなど、いくつかの組み込みのものがあります。 ただし、これらをAndroidランタイムのソースアプリケーションとして認識できます。Androidランタイムは、このリソースへのアクセスを提供し、このリソースを保護する行を決定します。



これはどういう意味ですか？ 許可を要求する必要があるときにアプリケーションによって使用されるという事実以外に、Androidのラベルには他に何が関係していますか？ ラベルに関連付けられているものがいくつかあることがわかります。 文字列に加えて、ラベルにはいくつかの興味深いプロパティがあります。 特に、Androidには3種類のタグがあります。 1つ目は通常の許可、2つ目は安全でない許可、3つ目は署名付きの許可です。







この許可を最初に決定するアプリケーションは、ラベルのタイプと他のすべてのフィールドを選択する機会を得ます。これについては後で説明します。 それでは、これらのタグタイプは何ですか？ Androidラベルにタイプが必要なのはなぜですか？



学生：ユーザーへの警告として機能しますか？



教授：まさに。 次に、すべてのタグを安全でないタイプにしないのはなぜですか？ これらのタイプのセマンティクスは何ですか？ 簡単に言えば、「危険な」ラベルを使用して、アプリケーションを破壊する可能性があります。 アプリケーションが安全でない許可へのアクセスを要求する場合、アプリケーションをインストールするときにユーザーに警告します。 同時に、ユーザーはこのメッセージを見て、「はい、この新しいアプリケーションに安全でない許可を与える準備ができています。」と言う必要があります。 アプリケーションが通常のタイプのラベルを要求した場合、ユーザーはこのアクションの許可を与える必要があるというメッセージを受け取りません。 すべてのアプリケーションがそれらを受け取る場合、通常の許可の意味は何ですか？ 通常のタイプラベルを使用する理由はありますか？



Androidの典型的な解像度の一例は、画面の壁紙を設定することです。 壁紙をインストールするアプリケーションがある場合、アプリケーションの開発者として、マニフェストで壁紙を設定したいことを示すことができます。 また、インストールをクリックすると、このアプリケーションにアクセス許可を与える必要がないため、何も面白いことは起こりません。



学生：しかし、これらの許可には通常、あなたからの確認が必要ですよね？ アプリケーションがデスクトップの壁紙を変更する場合、システムは壁紙を変更するかどうかを尋ねます。



教授：いいえ。



学生：いや？



教授：いいえ、API呼び出しにアクセスするだけなので、壁紙を変更するだけです。 この許可があれば、API呼び出しを行うだけです。



学生：アプリケーション開発者は、ユーザーが誤ってこれを行わないようにしたいのでしょうか？



教授：はい、これがこれらの許可が必要な理由の1つであると思います。これは、開発者が間違いを避けるのを助けたいという願望だからです。 アプリケーションが誤って何か間違ったことをしたり、使用できるエラーがあるかもしれないと心配している場合は、受け取るかもしれないか、受け取らないかもしれないパーミッションのセットが存在することで、アプリケーションの悪用の可能性が減ります。 そのため、壁紙をインストールする必要のない無害なアプリケーションがある場合、許可を求める必要はありません。携帯電話をインストールしているユーザーの方が良いからです。 ある程度、これは一種の特権です。



もう1つのことは、通常のタイプのラベルが存在することで、開発者とユーザーの両方から何らかの監査を実行できることです。 お使いの携帯電話が画面上の壁紙を毎秒変更する場合、どのアプリケーションがこの許可を持っているかを確認できます。 そのような許可の付与を承認しなかった場合でも、どのアプリケーションが現在壁紙の変更に関与しているかを確認することができます。



したがって、これらの一般的なアクセス許可は、適切なセキュリティ対策であると思われます。または、より広い範囲で、アプリケーションアクティビティを監査する良い機会であると思われます。 通常、このタイプのラベルは、データの操作や費用のかかるサービスへのアクセスなど、本当に重要なことには使用されません。



ラベルの3番目のタイプは、署名許可です。 Androidの興味深い特性は、アクセス権が宣言されているアプリケーションと同じデジタル署名で署名されたアプリケーションにのみアクセスを提供する機能です。 講義の記事では、FRIENDVIEWを使用した例を説明しています。 友だちの表示でこのタイプのタグで許可が定義されている場合、同じ開発者キーで署名されたアプリケーションは同じ許可を取得できます。 このことのポイントは何ですか？ なぜそれらを安全でないフラグを立てないのですか？ なぜ第3のタイプのラベルが必要なのですか？



学生：開発者がアプリケーションを管理しやすくなりますか？



教授：はい。 この開発者は、サードパーティプログラムの影響から隔離したいが、同時に生産的な対話のために自分のアプリケーションをバンドルしたい内部APIを持っている可能性があります。 仮に、Facebookの作成者はいくつかのアプリケーションを作成できます。 Facebookサーバーからコンテンツをプリロードする1つのアプリケーションがあり、別のアプリケーションがこのコンテンツを混合し、3番目がユーザーの位置を追跡し、これらすべてのコンポーネントが相互作用します。 そのような場合、署名された許可証を使用できます。



このアプリケーションを安全でないと指定したくない理由の1つは次のとおりです。 誰がこの許可を取得できるかを本当に知っている場合、ユーザーが介入することは望ましくありません。 悪意のあるアプリケーションに許可を与えることで、ユーザーは常にだまされる可能性があるため、一部のアプリケーションへの内部特権の提供をまったく邪魔しない方が良いでしょう。 そのため、この意味では署名付きのアクセス許可を使用する方が適切です。



ラベルには、ユーザー権限の説明もあります。 これは、この許可に伴う内容の説明です。 この説明は、新しいアプリケーションをインストールするように求められたときに表示されます。







したがって、Androidランタイムは、インストールするアプリケーションのマニフェスト内のすべてのラベル行を確認し、これらのすべてのマークされた行の説明をユーザーに表示します。たとえば、「このアプリケーションにダイヤルの権限を付与するか、SMSの送信を許可します」など。



興味深い質問：悪意のあるアプリケーションが他のアプリケーションのラベルを変更するとどうなりますか？ 結局のところ、これらのマークは単なる自由形式の文字列です。 悪意のあるアプリケーションで、「ああ、この新しい大きな解像度があります！ DIALPERMと呼ばれます。」 安全でないラベルはなく、その説明には何もありません。 これは危険ですか？



学生：おそらく、アプリケーションのドメイン名の構造に影響を与えることはできないでしょう。



教授：はい、これは期待できますが、残念ながらこれは必須ではありません。 通常、すべての許可文字列にはJavaスタイルのドメイン名が必要ですが、アプリケーションが定義するラベルとJavaスタイルのアプリケーション自体の名前との間に厳密な関係はありません。 Javaスタイルのアプリケーション名を強制的に何かに結び付けることはないため、特定のアプリケーションに署名する開発者公開キーがcom.google.somethingまたはeduの何かに一致するかどうかを確認する方法はありません。 mit.something。



Androidには1つの欠点があります。少なくとも最近この質問を掘り下げたときに存在していました。 したがって、ラベルを定義するときは、「誰が最初に来たのか」という原則が守られます。 つまり、アプリケーションをインストールすると、特定のラベルが定義され、ラベルのタイプとその説明を決定できます。 システム権限の場合、これはおそらく大きな問題ではありません。これは、システム権限またはダイヤラーなどの組み込みアプリケーションが最初に定義されるためです。 ただし、後でインストールされるアプリケーションは、フレームワークによるものであるため、アクセス許可をオーバーライドできません。



問題は、最初に悪意のあるアプリケーションをインストールし、次にいくつかの重要なアプリケーションをインストールすると、悪意のあるアプリケーションが後で意図的なアプリケーションによって使用されるラベルを歪める可能性があることです。 講義の記事では、攻撃者がユーザーにFRIENDVIEWアプリケーションのラベルタイプを通常のタイプに変更する悪意のあるアプリケーションをインストールするように強制する場合について説明します。 後で、FRIENDVIEWアプレットをインストールすると、このラベルは既に定義されているため、このラベルを上書きできなくなり、ユーザーは他のアプリケーションが友人の表示許可を使用することを防ぐことができなくなります。



学生：おそらくシステムは解像度を変更する試みを警告することができますか？



教授：原則として、フレームワークはこれを実行できますが、これを行おうとしたときにメッセージは発行されませんでした。 すでに定義されているラベルを定義するアプリケーションをインストールする場合、システムは何もせず、新しいラベル定義を単に無視し、古いものを使用します。 おそらくこれが問題であり、そのためにすべてがうまくいかない可能性があります。 少なくとも、システムは「既存のラベル定義があるため、このアプリケーションのインストールを拒否します」と言わなければなりません。



学生： ...そして別のアプリケーションに属します。



教授：はい、そして別のキーに属することさえあります。 その後、少なくとも潜在的にすべてを修正する機会があります。 私はこの問題を追跡しませんでした。おそらくすでに修正されています。 いずれにせよ、これは興味深い問題です。本当にこれらの名前を追跡し、この名前の所有者を見つけ、そのようなアクションをコミットする権利を取得する必要がある場合、非常に重要です。



もう1つの興味深いAndroidの問題は、ブロードキャストレシーバーまたはブロードキャストレシーバーに関連しています。 他のアプリケーションからのメッセージを受信して​​応答する機能を作成し、アプリケーション間でメッセージを送信するようなものを実装します。 最初に、これらのメッセージが受信者とどのように相互作用するかを説明する必要があります。 ブロードキャストレシーバーは、システム内の他のアプリケーションの一部のイベントをアナウンスできる1つのアプリケーションに使用されます。







私たちが知っているように、意図は通常、たとえばJPEG画像ビューアなどの特定のコンポーネントに向けられています。 しかし、システムの読み込みや「近くにいる友人」などのイベントについては、それに関係するすべてのアプリケーションに通知できます。 これがブロードキャストレシーバーの目的です。



あなたに関係する2つのことがあります。 まず、メッセージのソースの認証。つまり、このメッセージを送信したユーザーと、信頼できるかどうかを知りたい。 次に、このメッセージの宛先と受信者を制御する必要があります。



Android開発者はこれらのことを正しく実装していなかったようです。 いずれにせよ、Androidの初期バージョンでは、システムの他のすべてのコンポーネントにブロードキャストメッセージを送信すると、これらのアプリケーションはこのメッセージをサポートする場合とサポートしない場合があります。 したがって、Friends Viewerアプリケーションがある場合は、そのIntent IntentフィルターでActionやDate / MIMEなどの適切なコンポーネントを使用することにより、これらのメッセージをサポートします。 ただし、ほとんどのアプリケーションは、システム内のすべてのブロードキャストイベントを常にサポートでき、電話で発生するすべてのもの、またはブロードキャストされるすべてのものを確認できます。



したがって、Androidフレームワークは、ブロードキャストメッセージを表示できるユーザーを示すための追加の引数をアプリケーションに追加しました。







したがって、ブロードキャストメッセージを送信すると、引数が提供されます。このメッセージには、だれがこのメッセージを受信できるかを示す追加ラベルが付けられます。 つまり、システム内の全員にブロードキャストする代わりに、メッセージを受信する権限を持つアプリケーションのみがメッセージを受信できるように指定できます。



, , , , , , . Android, , , , .



, ? , « » , . , ? ?



: ? ?



: , . App 1 RM, , , App 2, , . , App 1 , ? Android ?



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



: , , ?

: . , — . , , « ».







Broadcast receiver, , , . , , , Label.



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



RPC , RPC-, , . , .



: ?



: , , .



: , …



: , . – . . : « ».



: ?



: .



: , ?



: , , . . , , , . , — . , : « , », , , Dangerous Description.







, : „ , ». , , , , . , Android , .



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







, , . , , , , , . , Java. , , , , .



Android . - , , , , . «» , RPC . , .



, , . , Android , 5 6 . , , , - «». , , .



, Android , , Apple . , Apple iPhone , .



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



, Android .





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



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



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



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