モバイル端末の重要性と危険性 白書 2016 年 7 月 目次 概要 ................................................................................................................................................................................................. 2 はじめに ...................................................................................................................................................................................... 5 モバイル端末の重要性と危険性 ......................................................................................................................... 5 アンドロイドの普及 ..................................................................................................................................................... 6 安全なモバイルアプリケーションを開発する最善の方法 .................................................................. 8 セキュリティーが後付け機能であることが許されない理由 ...................................................... 8 安全なモバイルアプリケーションに一般的なプログラムのアーキテクチャ ................. 9 完全に静的な言語の推奨 (C や C++) ............................................................................................................ 10 コードの整合性とプロテクション ................................................................................................................. 11 耐タンパ性 ................................................................................................................................................................... 11 コードの難読化 ....................................................................................................................................................... 12 WhiteBox の暗号システム .................................................................................................................................... 13 データの保存 ................................................................................................................................................................... 15 アンドロイドのアプリケーションにおけるセキュリティーの課題 ........................................ 16 アンドロイドアプリケーションのセキュリティーアーキテクチャ ................................... 16 セキュリティーの対策 ............................................................................................................................................ 17 Java によるプログラミングが避けられるべき理由 ......................................................................... 18 耐タンパ機能における課題 ............................................................................................................................ 18 ハッキングのツールキットの脅威 ........................................................................................................... 19 メソッドのリダイレクト攻撃 ....................................................................................................................... 20 おわりに ................................................................................................................................................................................... 21 概要 重要なオンラインサービスへのモバイル端末からのアクセスが、近年急激に増加していま す。これにより必然的に、スマートフォンに重要な個人情報を保存することが多くなりまし た。犯罪者達はすでにこのデータの価値に目を付けており、結果として様々な産業や業界に 影響を及ぼしています。これらの犯罪者達は知能に優れ、技能も高く、モバイル端末のプラ ットフォーム、オペレーティングシステムやアプリケーションの脆弱性を狙って、攻撃を仕 掛けることが出来ます。 半数以上のモバイル端末利用者は、その危険性に気付いていながらも、自ら端末を守る対 策を何も立てていないことが、リサーチにより明らかにされています。そして俗に呼ばれる オペレーティングシステムの防御機能は、いとも簡単に崩壊されています。モバイルアプリ ケーションの開発者は、アプリケーションが利用される端末が既にハッキングされている、 あるいは、これからそうなる可能性があることを念頭に置く必要があります。それはすなわ ちアプリケーションが犯罪行為に利用されることを防ぐために、開発者自身が責任を持って、 アプリケーションを保護しなければならないことを意味します。 アプリケーションを保護する上で、マルウェアやルートキットの検出といったような後付 け式の対策は無意味です。これには以下に 2 つの理由が挙げられます。 まず初めに、そのような検出方法はブラックリスト方式に基づくものであるため、 あらかじめ知られている問題しか検出することが出来ません。これはまさに永遠 に続くマラソンのような状態で、ハッカー達は我々の先を走っています。 次に、スマートフォンの使用に制限をかけるようなアプリケーションに対し、そ の利用者が示す反応は、あまり好ましいものではありません。スマートフォンの 「ルート権限」の取得を要請したり、ウィルス対策ソフトの強制的インストール を拒絶したりすることがその例に挙げられます。このような問題は、開発初期段 階にセキュリティー対策が練られていれば、回避出来ることです。 アプリケーションの開発者が、自らの提供するサービスやその利用者を、機密データの漏 洩の危険性から守るためには、以下の技術をアプリに組み込む必要があります。 コードの整合性チェック：アプリへの不正な改ざんを阻止します。 コードの難読化：アプリ内における、重要で機密な領域を隠します。 WhiteBox の暗号システム：安全なデータの暗号化と保存を、いかなるプラット フォーム上でも実現します。 プロセッサのネイティブコード：プロテクションを何層にも築き上げるための、 揺るぎない基盤を提供します。 インサイドセキュア社の MatrixSSE は、これらの技術を組み合わせた統合的なセキュリテ ィーソフトウエアパッケージで、金融、娯楽、ゲーム等のサービスを提供する 4 億本以上も のモバイルアプリケーションに実装されてきました。そしてこれらのアプリケーションは、 外部の研究所による広範囲にわたるセキュリティーテストを見事に通過しています。 はじめに モバイル端末の重要性と危険性 重要なオンラインサービスへのモバイル端末からのアクセスが、近年急激に増加していま す。これにより必然的に、スマートフォンに重要な個人情報を保存することが多くなりまし た。この時代の変化は金融産業において、モバイル端末を通じた銀行取引の利用が 5 年前は ほんの数パーセントだったところが、今や主な利用手段となっていることに裏付けられてい ます（図１）。 図 1 - 英国における銀行サービスの利用手段 1 そして犯罪者達は早速このデータの価値に目を付けています。金融関連のみならず、広範 囲にわたる産業や業界におけるデータも狙っています。これらの犯罪者達は知能に優れ、技 能も高く、モバイル端末のオペレーティングシステムやアプリケーションのセキュリティー の脆弱性を狙って攻撃を仕掛けることが出来ます。 1 https://www.bba.org.uk/news/press-releases/mobile-phone-apps-become-the-uks-number-one-way-to-bank 狙われているのはモバイルアプリケーション内のデータだけではありません。モバイルア プリケーションは IT システムの境界防御をくぐり抜ける手段として利用されてしまう恐れ があります。これはすなわち無防備なモバイルアプリケーションは、IT セキュリティーシス テムにおける弱点となることを意味します。ハッカーがモバイルアプリケーションをコント ロールすることが出来れば、それを支える IT システムからの正規の要求を偽造することも 可能となります。モバイルアプリケーションのみならず、IT システム全体をも巻き込んでし まうことになるのです。 半数以上のモバイル端末利用者は、その危険性に気付いていながらも、自ら端末を守る対 策を何も立てていないことが、リサーチにより明らかにされています2。そして俗に呼ばれ るオペレーティングシステムの防御機能は、いとも簡単に崩壊されています。モバイルアプ リケーションの開発者は、アプリケーションが利用される端末がすでにハッキングされてい る、あるいは、これからそうなる可能性があることを念頭に置く必要があります。アプリケ ーションが犯罪行為に利用されることを防ぐために、責任を持ってアプリケーションを保護 するかどうかは、開発者次第であると言えるでしょう。 この文書は、開発者、プロダクトマネジャーやセキュリティー関係者が、モバイルアプリ ケーションを保護するための手法を説明いたします。 アンドロイドの普及 2009 年から 2015 年にかけて、モバイル端末のオペレーティングシステムは、爆発的な速 度で成長しました（図２参照）。６年の間にアンドロイドは、わずか 10％の市場シェアか ら 80％へと急成長を遂げ、今や世界中で最もよく利用されているオペレーティングシステ ムの座を誇っています。 2 http://www.kaspersky.com/about/news/virus/2015/Quarter-of-Users-Do-Not-Understand-the-Risks-ofMobile-Cyberthreats 図２-アンドロイドの市場シェア3 この間、アンドロイドの主な競合相手であるアップル社の iOS は、比較的継続的に約 15％の市場シェアを保ってきました。価格が主な判断材料となる新興成長市場におけるアン ドロイドの採用率の高さが、その普及を加速する原動力となっているのは確かであるものの、 これほどの成長を達成するには、他にも理由があります。ウィンドウズ、シンビアン、ブラ ックベリーが市場シェアを急激に失っていることから判断して、それは明らかです。今やア ンドロイドは、一番優勢なオペレーティングシステムとなり、世界レベルで市場を独占して います。 全てのソフトウェアプラットフォームは、セキュリティーにおいてそれぞれ問題を抱えて います。そしてアンドロイドの場合、アプリケーションの主な開発言語が Java であること が、その例に挙げられます。Java には、開発のスピードと柔軟性という観点から見ると、多 くの利点がある一方、先天的に安全ではない言語です。Java で開発されたアプリケーション を保護することは、頭を悩ませる深刻な問題です。 3 Gartner, February 2016 安全なモバイルアプリケーションを開発する最善の方法 セキュリティーが後付け機能であることが許されない理由 ハッカーや、不正利用者、マルウェア、内部関係者による裏切り行為、そしてさらにハー ドウェアのエラーから守るためにも、モバイルアプリケーションに自己防衛機能を付ける必 要があります。これを実現するには、アプリケーションの開発の最終段階ではなく、開始段 階からセキュリティーの対策を練らなければなりません。 ポネモン・インスティテュートによる近年のリサーチによると、77％もの機関が「リリー スを先急ぐ」プレッシャーが、脆弱性のあるコードを含むアプリケーションを生み出す一番 の理由となっていると言及していることが、明らかにされています。このアプローチの問題 は、セキュリティーが開発の最終段階で組み込もうとされてしまっている点にあります。機 密データがどのように守られるかは、プログラムの構造と大いに関係しているため、セキュ リティー機能は、リリース直前に上手く実装出来るようなものではありません。 マルウェアやルートキットの検出といったような、後付け式の対応策は役に立ちません。 これには以下に２つの理由が挙げられます。まず初めに、そのような検出方法はブラックリ スト方式に基づくものであるため、あらかじめ知られている問題しか検出することが出来ま せん。これはまさに永遠に続くマラソンのような状態で、ハッカー達は我々の先を走ってい ます。次に、スマートフォンの使用に制限をかけるようなアプリケーションに対し、その利 用者が示す反応は、あまり好ましいものではありません。スマートフォンの「ルート権限」 の取得を要請したり、ウィルス対策ソフトの強制的インストールを拒絶したりすることがそ の例に挙げられます。 これらの問題は、開発初期段階にセキュリティー対策が練られていれば、回避出来ること です。 安全なモバイルアプリケーションに一般的なプログラムのアーキテクチャ モバイルアプリケーションは、複数にわたるコンポーネントにより構築されています。 （一般的にライブラリと呼ばれています）。アプリケーションのアーキテクチャをデザイン するにあたり、これらのコンポーネントの中で、どれが「安全」で、どれが「脆弱」である かを見極めることが重要です。そしてまた、機密データにおいて、安全なコンポーネントを 暗号化されていない状態のままで放っておくことは許されません。 通常、安全なコンポーネントは、偶然に保護されているだけで必ずしも機密ではないコー ドとデータを含みます。むしろ、ユーザーインターフェース等の大部分のビジネスロジック を、安全なコンポーネントの中に組み込むことは極めて重要です。これにより、ハッカーが コンポーネントを自らのコードにすり替えて、そのセキュリティー機能を回避する手口に対 抗することが出来ます。 図３ - 安全なモバイルアプリケーションのアーキテクチャ 完全に静的な言語の推奨（C や C++） 静的な言語（プロセッサのネイティブコードにコンパイルされるもの）は、ランタイム時 にコードが変化することのない、強力なプログラムを作り出します。この基盤を築くことに より、その性質の延長線上として、耐タンパ性を持つようになります。部分的、あるいは、 完全に動的な言語は、通常の言語機能を通じてアプリケーションに変更を加えることが許さ れるため、不正行為と正規のランタイムの動作との見分けがつけにくく、耐タンパ性に乏し い、脆弱な基盤を持つようになります。 よく使われる言語や環境の中から耐タンパ性の強い順より、以下に例を挙げます。 • C や C++は、完全に静的で、優れた耐タンパ性を持ちます。 • Objective-C は、C と同じ静的性質を持つものの、Objective-C のメソッドやその類 ならどのようなものであっても、外部のコンポーネントにより、正規のルートでプ ログラムに変更が加えられてしまう恐れがあるため、その安全性は保障されません。 インサイドセキュア社はこのような行為を検出する技術を持っていますが、その検 出法は、優れた耐タンパ性、すなわち Objective-C の静的な部分を基盤にせざるを 得ません。 • Swift は iOS で使われており、通常そのコードはビットコードと呼ばれる、中間コー ドにコンパイルされるため、その安全性は保障されません。ビットコードはその後、 アップル社のアプリストアのネイティブマシンコードに変換されます。これはつま り Java のように、開発の段階では最終の実行コードがどのようなものになるのかが 分かり辛いことを意味します。 • C# は一般として、.NET 環境で実行されるソフトウェアの開発に使われるため、その 安全性は保障されないと考えられています。 • Java や.NET 環境は、耐タンパ性をほぼ持ち合わせていません。これらの言語に静的 な形式はなく、コンテンツの構成要素を参照する機能もありません。このような環 境で実行されるアプリケーションは、特別に開発され、難読化されたランタイム （これは実質、クライエントの仮想マシンの代わりをする形になります）を用意で もしないかぎり、高い信頼性のある難読化や、セキュリティーを実現出来ません。 • HTML5 やそれに関連した技術（例：JavaScript）を保護することは不可能です。完 成されたコードは、ほぼ平文同様であるため、中身を簡単に読み込んで変更するこ とが出来ます。コードを暗号化することは可能であるものの、実行前に復号化され る必要があるため、容易に妨害することが出来ます。 現存するプラットフォームの中には（例：アンドロイド）、特定の機能において Java を 利用するしか、ほぼ選択の余地がない場合があります。特にユーザーインターフェースや、 その他のオペレーティングシステムのサービスが例に挙げられます。そしてこれらの領域が、 機密データを扱う領域から綿密に区別されているのを確認することは、極めて重要です。 Java のコンポーネントが機密データを扱わなければならない場合は、暗号化されている機密 データのみを扱うようにしなければなりません。そしてこれは、隠密に行われることが絶対 条件です。 このような状況におけるほとんどの場合、Java は機密データの運び屋としての役割を果た すだけで、その内容自体に触れることはありません。そしてアプリケーションのアーキテク チャにおけるこの「法則」が見破られた時に、これが必然的に恰好の攻撃対象となるのです。 コードの整合性とプロテクション 耐タンパ性 耐タンパ性を身に着けることにより、プログラムに無制限のアクセス権を持つハッカー達 から、アプリケーションは自らを守ることが出来ます。無制限のアクセス権を手に入れるこ とは、ハッカーにとってそれほど難しいことではありません。それは、ハッキングされたデ バイスからアプリケーションをハイジャックすれば済むだけの話だからです。一度ハッカー がアプリケーションへの無制限のアクセス権を手にすれば、その機能や弱点を解析するため の、ありとあらゆる攻撃を仕掛けることが出来ます。ただそれだけであれば、これらの攻撃 による被害は限られているものの、もしこれが、同じアプリケーションをインストールして いる利用者の全体に向けられた、大規模な攻撃につながるきっかけとなるのであれば、その 危険性は計り知れません。 最大限のプロテクションを実現する一方、パフォーマンスに及ぼす影響を最小限に留める ためには、静的にも、（動作時の状況を観察することにより）動的にも、耐タンパ機能がコ ードの解析を効率良く行い、最適化された一連の「チェック」をソースに自動的に組み込み、 コンパイルし、ビルドされることが望ましいと言えます。この一連のチェックは、ソフトウ ェア中に神経を張り巡らせ、不正行為を敏感に察知します。開発者がこのシステムと直接関 わる必要性は全くありません。なぜなら、ビルドプロセスの一部として、この機能を自動的 に組み込むことが出来るからです。 効率的な分析と最適化により、コードの隅々まで、何百何千ものチェックを組み込み、プ ログラム同士が互いを見張り合うことを可能にする一方、通常パフォーマンスに及ぼす影響 は、ほぼありません。これらのチェックは、検出や自動化された除去技術に耐性を持ちます。 もし実行ファイルに何らかの変更が加えられた場合は、複数にわたるチェックがその異変を 察知し、適切な処理を行います。 耐タンパ技術は、不正行為の検出を、関数の粒度に対して行います。あまり多くの関数を 持たないことは、セキュリティーの強度が低くしてしまうことを意味します。これらの関数 がセキュリティーに関係しているかどうかは重要ではなく、それらが活発的に使われている かどうかが成功のカギを握ります。活用されているコードであればあるほど、この技術はよ り効果を示します。 コードの難読化 難読化自体は、アプリケーションのプロテクションではありません。しかしながら、それ は守備範囲を広げる上で有効な防御層を構築します。このことから、アプリケーションの開 発者は、ソフトウェアの機密データを隠し、機密コードを難読化する必要があると言えるで しょう。 ウェブアプリケーションから、モバイル端末のアプリケーションへと進化するにあたり、 莫大な量の機密ロジックや知的財産が、ファイアーウォールで守られたバックエンドサーバ ーから、何百台ものモバイル端末へと移行しました。それと同時に、そのような端末に実装 された新機能の多くは、企業機密のアルゴリズムや、指紋認証等に代表される端末や利用者 の認証システムといったような、重要な個人情報やセキュリティーに深く関連するものが含 まれています。 アプリケーション内のこのような類の機能は、無料で入手出来る様々なデバッガやハッキ ングツールによって自動的に解析することが出来るため、これによりハッキングや IP の盗 用の危険性が非常に高まりました。 強力な難読化は、アプリケーションの機密機能のリバースエンジニアリングの難易度を劇 的に上昇させ、その動作の静的分析と動的分析の両方を妨害することにより、現実的に実行 不可能なものへと化します。その結果、ほとんどの有能なハッカーやエリートハッカーは、 このようなアプリケーションの解析に時間や労力をかけるのは無駄だと考え、これよりも簡 単に攻略できるアプリケーションに標的を変えるようになります。 難読化の技術は、アプリケーションのパフォーマンスとコードサイズの基準を満たす一方、 その効果を最大限に引き延ばすために、特定の関数に焦点を絞る機能や、その複雑性を調節 する機能を持つべきだと考えられます。難読化の技術は、制御フローやシンボル名の隠 、 ループの平坦化、コードの変形、おとりコード、おとり関数、そして文字のすり替え等を含 みます。述語や式を不透明化することで、その機能を解明するには、コードが常に動的に分 析されるしか他に方法がないように仕向けることが出来ます。 難読化は、コードブロック、関数、主要データへ、コンパイル前に実装されるべきだと言 えます。これにより少なくともハッキングに対し、複数にわたる防御層を持つことになりま す。 WhiteBox の暗号システム 重要な機密データの処理には、機密データをコードと融合させ、アルゴリズムを不透明化 させる、WhiteBox の技術を採用することは、セキュリティー上非常に有効です。 図 4 - WhiteBox の仕組み WhiteBox のソリューションには、２つのモデルがあります。一つは、プロバイダーが WhiteBox を提供するもので、もう一つは、開発者自身が独自の WhiteBox を作るためのツー ルのみを提供するものです。前者はプロバイダーが WhiteBox を作るため、開発者側はその 手間が省けるという利点があります。後者はかなりの柔軟性と自由度が得られ、どのような アルゴリズムも（プロバイダーが提供する暗号システムのサポートだけではなく）WhiteBox により保護し、すべてのアルゴリズムが連結して、その動作のセキュリティーを高めること が出来ます。 一方、WhiteBox を作る技術者が、復号化に使われる暗号鍵を管理することになる点は、 注意しておく必要があります。アプリケーションの開発者自身が WhiteBox を作るのであれ ば、これらの鍵は開発者のみが持つことになります。そして、外部サービスプロバイダーが WhiteBox を作るのであれば、彼らがこれらの鍵を持つことになります。 難読化と同様、WhiteBox の技術は、セキュリティーにおける、一つの防御層に過ぎず、 その真の力を発揮するには、強力な耐タンパ機能が合わせて実装される必要があります。最 大のプロテクションは、WhiteBox を含むアプリケーションのすべての領域と、耐タンパ機 能が完全に融合されることにより実現されます。WhiteBox を安全なコンポーネントと定着 させる為には、WhiteBox のソースコードをそのようなコンポーネントと共にコンパイルす ることが重要です。 WhiteBox を Java（もしくはその他の安全性が保障されないコンポーネント）の環境で実 装することは可能ですが、これは残念ながら全くお勧め出来ることではありません。 WhiteBox は、機密データがその内部に入る際には復号化され、その外部に出る際にそれら が暗号化されるようにすることが出来ますが、WhiteBox が脆弱なコンポーネントからの直 接の呼び出しを受ける際、WhiteBox が「ハイジャック」され、（アプリケーションに対す る）不正な操作に悪用されてしまう危険性は、極めて高いと言えます。WhiteBox のセキュ リティーの強度は、耐タンパ性を持つ安全なコンポーネントと「定着」されているかどうか に左右されます。そしてこの事実は、１つのアプリケーションに多種類の言語が使われてい る場合、ソフトウェアの機密データの処理を行うアプリケーションをデザインする上で、熟 考されるべき極めて重要な課題であると言えます。 データの保存 機密情報は、その実行中、休止中、その移動中のどの状態においても守られるべきです。 「実行中」におけるプロテクション技術は、上記で説明されましたが、「移動中」における プロテクションには、安全なコミュニケーションプロトコルが必要で、モバイル端末におけ るエンドポイントは、安全なコンポーネントであると言えます。 「休止中」の状態では、重要なデータ（例：パスワード）が端末上に直接保存されること がないようなアプリケーションのデータ保存法を設計する必要があります。もしやむを得ず 重要なデータを端末上に保存しなければならない場合は、安全に保存される必要があります。 それらは、内部アプリデータのディレクトリ内における暗号化された領域に保存された上、 クラウドサービスにバックアップされないようにしっかりと定義しておく必要があります。 アンドロイドのアプリケーションにおけるセキュリティ ーの課題 アンドロイドアプリケーションのセキュリティーアーキテクチャ 近年のリサーチによると、97％以上の有料のアンドロイドアプリケーションは、セキュリ ティーにおける複数の問題を抱えています。これらの問題は、アプリケーションの開発言語 として推奨されている Java の環境と、そのセキュリティーにおける対策が十分練られてい ないことの両方に起因しています。 本文ですでに紹介された、安全なモバイルアプリケーションの一般的なアーキテクチャは、 アンドロイドにも当てはまることです（図５）。脆弱なコンポーネントを Java で開発する ことは許容範囲ではあるものの、安全なコンポーネントは、強力な耐タンパ機能をを実装す るために、C や C++で開発されることが必要不可欠です。アプリケーションの安全なコンポ ーネントの「比重」が増せば増すほど安全性が高まることを、忘れてはなりません。 図 5 - 安全なアンドロイドアプリケーションのアーキテクチャ セキュリティーの対策 セキュリティーや、アプリケーションのプロテクションの対策が立てられておらず、アン ドロイドのアプリケーションにおけるバイナリプロテクションが欠如している場合、技術的 にもビジネス的にも多様な危険性を招きます。 セキュリティーを十分に考慮するためには、バイナリプロテクションの欠如が生み出す脆 弱性を理解することが重要です。主な弱点は以下の 3 つに挙げられます。 安全の保障されていない環境にインストールされたアプリケーションソフトは多く の場合、ハッカー達によるリバースエンジニアリング、改ざん、分析、悪用等の被 害対象となります。 容易にアクセスすることのできるアプリケーションソフトは、ハッカー達がアプリ ケーションのバイナリにアクセスし、その整合性や技術を壊滅することで、いとも 簡単にハッキングすることが出来るようになります。 バイナリのハッキングにより簡単に改ざん出来てしまうアプリケーションソフトは、 アプリケーション自身と、そのプロバイダー、そしてその利用者に、様々な悪影響 を及ぼします。 バイナリのプロテクションの欠如は、アプリケーションの開発者にとって非常に危険な状 況をもたらし、アプリケーションの全てのインスタンスに対する大規模な攻撃が仕掛けられ る危険性を大いに高めます。このことから、開発者は自ら責任を持ち、アプリケーションの セキュリティー対策を立てるべきであると言えるでしょう。 推奨される対策： 実装されるべきである一方、それのみに頼ってはならないもの： o オペレーティングのシステムの防御機能が有効であるかどうかを判断する為に、 ルートキットを検出するもの。 o 何者かにアプリが監視されているかどうかを確かめるために、デバッガを検出 するもの。注意：ルートキットやデバッガの検出といったような旧式の技術は、 簡単に出し抜くことが出来るため、ただの目安としてのみ利用されるべきです。 o ハッキングにより容易にすり替えが可能なオペレーティングシステムのサービ スを補う、独自のセキュリティーサービス（例：SSL クライエント）。 o 安全にコミュニケーションを取るための、相互認証技術。 悪用を目的としたリバースエンジニアリングに対するプロテクション。 アプリケーションの機密領域における不正なコードの改ざんに対する防御機能。 ランタイム時におけるコードの改ざんを検出し、適切な処理を行う機能。 Java によるプログラミングが避けられるべき理由 アンドロイドが主流の現在、モバイルアプリケーションのほとんどが Java でプログラム されています。問題なのは、Java やその他の管理されたコード言語が、安全なアプリケーシ ョンの開発に用いられることが極めて一般的であることです。 耐タンパ機能における課題 アプリケーションのセキュリティーにおいて、防御層を幾重にも重ねることが、その成功 のカギを握ります。そしてアプリケーションコードが耐タンパ性を持つことにより、他の防 御層を構築する上で、最も有効な基盤を築くことが出来ます。 耐タンパ機能が担う重要な役割は、コードの整合性のチェックです。これにより、ハッカ ーによって改ざんされたものではない、正規のアプリケーションコードが実行されているこ とを確認します。これは、C や C++のような言語を採用することにより実現されます。なぜ なら、実行コードが元のコンパイルされたコードと全く同じだからです。 これは Java のような「ランタイム時にコンパイルされる」言語では、最終のコードがバ イトコードの形式をとるため、実現の難しいものです。このバイトコードは、アプリの起動 時に直接実行されません。アプリが起動したときに、この言語のランタイムがバイトコード をマシンコードにコンパイルし、それが実行されるのです。この意図したコードの変化と、 不正な改ざん行為との区別をつける方法がないため、Java コードに対する強力なランタイム 時の耐タンパ性を実現することは、事実上不可能なのです。 Java のような言語に対して 最低限出来ることは、バイトコ ードの整合性のチェックくらい であると言えます。そしてこれ は、ランタイムが実際に実行す る、コンパイルされたコードに おける異変の検出には全く役に は立ちません。ハッカーは、バ イトコードの検証を無視して、 「整合性のチェックにより、WhiteBox のネ イティブライブラリコードを改ざんすること は困難になりますが、Java のバイトコード のパッチや、JNI 呼び出しのハイジャック、 ルートキットの検出を回避すること等は、比 較的簡単です。」 コンパイルされたコードをハイ ジャックすればいいだけの話だ からです。 大手セキュリティー研究所より そしてまた言語のランタイム を改ざんし、バイトコードの検 証を事実上無効にすることも可能です。しかしながら、ランタイム時にコンパイルされるコ ードを改ざんする方が簡単なため、これはあまり一般的ではありません。 要するに Java をベースにしたアプリは、どうあがいてもハッカー達により容易に改ざん されてしまうということです。そしてコードの改ざんが可能であるということは、そのアプ リの安全性が長くは保障されないことを意味します。 ハッキングのツールキットの脅威 耐タンパ機能を回避するのに加え、ハッカーは、言語のランタイムを改ざんすることによ り、Java で組まれたアプリケーションのコードのすべてを命令レベルで覆してしまうことが 出来ます。これらの改ざん行為は、以下のようなものが例に挙げれるように、様々な目的の ために行われます： • アプリケーションの動作を大幅に変化させる。 • コードの隅々にまで、ランタイム分析機能を挿入する。 • アプリケーションへ機能を加える。 ハッカーはこのように、バイトコードからコンパイルされたマシンコードに至るまで、あ りとあらゆるものを改造することが出来ます。バイトコードの改ざんはとても単純な手口で はあるものの、ほとんどの目的を果たすのには十分に強力です（そしてハッカーの書き加え たものは、親切にもランタイムにより最適化されます）。さらにマシンコードの改ざんによ り、ハッカーはほぼ何でも出来るようになります。 セキュリティーの観点から見る問題の根底は、これにより非常に効率的なエミュレーショ ンレベルの分析ツールを組み込むことを可能とし、アプリケーションに含まれるセキュリテ ィー機能に対して不利な状況を作り出すことです。セキュリティー機能にその効果を持続さ せるには、開発者はそのレベルを格段に押し上げる必要があります。上記のような攻撃から、 守る側はどこにも逃げ隠れることは出来ません。 メソッドのリダイレクト攻撃 Objective-C におけるメソッドのリダイレクト攻撃は、Objective-C の動的なタイピングを 利用して、メソッドの呼び出しをハイジャックします。これによりハッカーはアプリの動作 をメソッドレベルでコントロールすることが出来ます。このアプローチには明らかな限界が ありますが、それでもハッカーたちはこの手口を様々な目的のために使っています。中でも よく知られているのは、iOS のアプリに実装された、脱獄行為の検出機能を無効にするもの です。 Java は静的にタイピングされるものの、その言語におけるバイトコードと、実際に実行さ れるコードとのつながりの緩さが、Objective-C のメソッドのリダイレクト攻撃といった類 の攻撃や、それよりもさらに強力な攻撃を仕掛ける隙を与えます。アンドロイドにおいて、 これを可能とするフレームワークが少なくとも 2 つあり、中でも一番人気なのは Xposed と 呼ばれるフレームワークです。 この類の攻撃における問題は、あまりのスキルのないハッカーですら、ほんの少しの努力 でアプリケーションの動作に多大な影響を与えることが出来ることです。（アンドロイドに 向けての）よくありがちな攻撃は、ルートキットの検出機能を無効にするものです。検出コ ードそのものはネイティブコードであるものの、それが Java コードから呼び出される場合 は、ハッキングの基礎スキルのみでその呼び出しを無効にすることが出来ます。 おわりに モバイルアプリは、既に多くの人々にとって、なくてはならないものとなっています。銀 行サービスや、ヘルスケア、娯楽における、主な窓口となっているのはもちろんのこと、サ ービス料金の支払いなどに使われることも非常に多くなりつつあります。その結果、機密デ ータや機能は、盗用やハッキングのターゲットになりやすくなっています。前述のポネモ ン・インスティテュートのリサーチでも、「リリースを先急ぐ」ことが、利用者と消費者の 機密データを攻撃の危険にさらすことが明らかにされています。モバイルアプリケーション のセキュリティーは、データセンターと同様、むしろそれ以上に重要な扱いを受けるよう、 方針を改めるべきなのです。 経営者や利用者を、機密データの漏洩から守るために、モバイルアプリケーションの開発 者は、以下の技術をアプリケーションに実装する必要があります。 コードの整合性チェック：モバイルアプリに対する、不正な改ざん行為を防止しま す。 コードの難読化：モバイルアプリの重要で機密な領域を隠します。 WhiteBox の暗号システム：安全なデータの暗号化と保存を、いかなるプラットフォ ーム上でも実現します。 プロセッサのネイティブコード：防御層の構築における、揺るぎない基盤を築きま す。 インサイドセキュア社の MatrixSSE は、これらの技術を組み合わせた、統合的なソフトウ エアパッケージで、金融、娯楽、ゲーム等のサービスを提供する、4 億本以上ものモバイル アプリケーションに実装されてきました。そしてこれらのアプリケーションは、外部の研究 所において、広範囲にわたるセキュリティーテストを通過しています。 MatrixSSE は、危険に満ち れているモバイル環境においてアプリケーションが、機密デ ータを安全に処理し、保存することを可能にします。モバイルアプリケーションへのセキュ リティーの実装を簡潔化し、悪意ある攻撃からそれらが自らを守るようにします。MatrixSSE のセキュリティーソリューションは、金融、販売、ヘルスケア、娯楽等のありとあらゆる業 界において、アプリケーションプロバイダーの強い味方となるでしょう。 MatrixSSE のさらなる詳細につきましては、ウェブサイトをご覧下さい： http://www.insidesecure.com/Markets-solutions/Payment-and-Mobile-Banking/MatrixSSE2 （注：リンク先は英文です。） インサイドセキュア社について インサイドセキュア社は、統合的なセキュリティーソリューションを提案します。世界を 代表する企業が、端末、コンテンツ、サービス、個人情報、取引等を含む、重要な財産を守 るために、弊社がお届けするモバイルセキュリティーと安全な取引技術を採用しています。 IP、半導体、ソフトウェア等の分野における、セキュリティーのエキスパートとして、他の 追随を許しません。最新鋭のソリューションとより優れたプロテクションを、お客様にお届 けします。さらなる詳細につきましては、ウェブサイトをご覧下さい： www.insidesecure.com（注：リンク先は英文です。）
© Copyright 2024 Paperzz
