簡単なハッキングでiOSのアプリ内購入の仕組みを簡単に回避できるという最近のニュースは、開発者がApp Storeを通じて安全に取引を行えるようAppleが十分な支援を行っているかどうかという疑問を提起している。
アプリ内購入（IAP）とは、アプリがユーザーのiTunesアカウントに課金し、デジタル商品やサービスと引き換える仕組みです。多くのゲームが、コインなどのアプリ内通貨やサービスのサブスクリプションをユーザーに購入させているのは、この仕組みのおかげです。多くのアプリが、初期ダウンロード価格を非常に低く抑え（多くの場合無料）、その後アプリの使用に応じて課金するというビジネスモデルを採用していることを考えると、IAPはアプリ開発者にとって非常に重要なツールとなっています。
IAPの仕組み
技術的な詳細に立ち入ることなく言えば、開発者の視点から見ると、IAPは比較的簡単に利用できます。開発者はAppleにアプリを提出する前に、アプリで販売する商品（例：「1,000コインを0.99ドルで購入」）を登録するだけです。その後、ユーザーのリクエストに応じて、アプリはiOSに購入手続きを完了するよう要求します。デバイスは通常、ユーザーにiTunesログインを要求し、取引を完了させます。完了すると、アプリに取引が完了したことが通知されます。
iOSはバックグラウンドでAppleのサーバーに接続し、2つのタスクを実行します。まず、ユーザー名とパスワードを検証し、次に、開発者がアプリの申請時に登録したIAPの詳細に基づいて、ユーザーのiTunesアカウントへの課金を要求します。ユーザー情報を不正アクセスから保護するため、このプロセスはTLS/SSLを使用した暗号化チャネルを介して実行されます。これは、URLが「https://」で始まるウェブサイトにWebブラウザが接続する際に使用するプロトコルと同じです。
開発者の視点から見ると、このプロセス全体は完全に不透明です。オペレーティングシステムは、IAPリクエストに対して、アプリにトランザクションが失敗したことを通知するか（例えば、ユーザーが気が変わった、または十分な資金がなかったなど）、購入が完了したことを示す「レシート」を返すという形で応答するだけです。その後、購入価格の70%が開発者の銀行口座に入金されます（残りの30%はAppleが手数料として受け取ります）。
Appleのプライバシー保護への取り組みに従い、レシートには購入ユーザーを特定できる情報は一切含まれません。重要なのは、固有の識別子とその他の重要な情報を除き、同じ製品を2回購入しても、レシートは実質的に同一のものになるということです。
IAPは、規模の大小を問わず、開発者にとって大きなメリットとなります。独自の決済システムを構築するよりも導入が簡単で、iTunesを利用することで、ユーザーにとって使い慣れた、安全でスムーズな決済方法を提供します。
ハッキングの仕組み
セキュリティ対策やサードパーティによる検証がなければ、IAPプロセスを不正に操作するのは非常に簡単です。デバイスをAppleの正規サーバー以外のサーバーに接続させ、IAPリクエストに、もっともらしい偽の情報を含むレシートで応答するだけで済みます。
この問題を軽減するため、Appleは業界標準のSSL/TLSプロトコルを使用して通信を保護しています。このプロトコルは、データを暗号化することで第三者による傍受を防止し、デジタル証明書を使用してAppleのサーバーを確実に識別します。デジタル証明書が信頼できるものであれば、デバイスはAppleの実際のサーバーと通信していることを確信できます。
デジタル証明書の有効性は、いわゆる認証局（CA）によって保証されます。認証局とは、企業の身元を検証し、証明書に「副署名」を行う第三者機関です。一部の認証局は通常、オペレーティングシステムにハードコードされていますが、手動で設定できるものもあります。Appleは手動で設定できるプロセスをサポートしており、エンタープライズ展開を含む多くのシナリオで非常に役立ちます。
現在話題となっているアプリ内購入ハッキングは、偽造されたカスタム証明書をインストールし、カスタムDNSサーバーを使用することで、この機能を悪用しています。これにより、通常はAppleのIAPサーバーに送信されるすべてのトラフィックが別のアドレスにリダイレクトされます。偽造証明書によってデバイスはAppleと通信していると信じ込んでいますが、実際にはハッカーの管理下にあるサーバーに通信が送信されています。
この比較的簡単なワンツーパンチで、IAPプロセス全体のセキュリティが破られます。ハッカーが本物そっくりのレシートを作成できれば、内容を見ただけでは本物と見分けることは事実上不可能です。さらに、iOSはiTunesのユーザー名とパスワードを平文で送信しているようで、ハッカーは偽の購入プロセスの一環としてこれらを収集することが可能です。
ああ、とてもシンプル
少し単純すぎるように聞こえるかもしれませんが、実際その通りです。ハッカーは「中間者攻撃」と呼ばれる典型的な攻撃を実行しています。これは、インターネット版の電話盗聴攻撃で、後で2人の発信者のうちの1人になりすます攻撃です。
Appleはこの制限を十分に認識しており、開発者に対し、独自のメカニズムを用いてIAPレシートを検証することを強く推奨しています。通常、これは別のサーバーを設定し、レシートをそのサーバーに送信し、Appleのサーバーと照合して検証するという手順を伴います。サーバーは完全に開発者の管理下にあるため、中間者攻撃の実行ははるかに困難です。
しかし、独自のサーバーをセットアップするコストは別としても、残念ながら、ハッカーが開発者のサーバーに同じ種類の攻撃を仕掛け、まったく同じ方法でアプリの二次検証を阻止することはできないため、アプリを非常に脆弱な状態にする形でこの種の検証を実装するのは簡単です。
より良いアプローチは、2つのパスワードを必要とする非対称暗号化を利用するメカニズムを使用することです。最初のパスワードでデータを暗号化した場合、2番目のパスワードでのみ復号化でき、その逆も同様です。2つのパスワードのうち1つが開発者のサーバーに保存され、両者間で転送されなければ、中間者攻撃の実行は非常に困難になります。特に、各トランザクションが非常に短い期間のみ有効となるように設計されている場合はなおさらです。
これは不可能ではありませんが、個々のアプリごとに実行する必要があるため、非常に困難な作業です。開発者に必要なノウハウがあれば、保護メカニズムの実装は比較的簡単です。
ああ、とても壊れている
表面的には、これは開発者が解決すべき問題のように見えます。結局のところ、Apple は IAP 検証プロセスが信頼できるという保証を一切せず、開発者に対して独自の検証システムを実装するように明示的に警告しています。また、問題のハッキングが成功するのは、基本的にユーザーがデバイスに巨大なセキュリティホールを開けるからにほかなりません。
しかし、私にはそれは少し無理があるように思えます。ハリウッドは、開発者がちゃんと動くアプリを作るために必要なことは、大きな緑のボタン（赤いボタンは緊急時専用）に太った手を叩きつけることだけだと、世界の大多数の人々に思い込ませているように見えますが、プログラミングは高度に専門化された職業です。つまり、美しく魅力的なゲームを作る方法を知っている独立系開発者が、必ずしもデータ暗号化の複雑さを理解するのに十分な経験を持っているとは限りません。
これに、独自のサーバー構築費用も加算されます。多額の費用はかからないかもしれませんが、多くの開発者は少額の収入しか得られません。サーバーのメンテナンスやサーバーサイドのコード作成など、これらはすべて時間と費用のかかる作業です。
さらに、App Storeの根底にあるのは、アプリの配信プロセス全体をAppleに委任し、開発者が本来の得意分野、つまり優れたアプリの開発に集中できるようにすることです。開発者が優れたソフトウェアの開発に加えて、詐欺に遭うことも心配しなければならないとなると、Appleの30%の手数料を正当化するのははるかに難しくなります。
アップルができること
こうした状況を考えると、多くの開発者がIAPの二次検証を怠り、今回のようなハッキングの危険に晒されているのも無理はありません。問題は、これに対して何ができるのかということです。
最初の、そしておそらく最も明白な答えは、AppleがIAPプロセスをより安全にするということです。これは同社にとって比較的容易に実装でき、App Storeの配信モデルにもうまく適合するため、開発者はiOSプラットフォーム向けにさらに優れたアプリを開発することに集中できます。
残念ながら、これにはiOSのアップデートが必要になる可能性が高いため、Appleが提供するソリューションが開発者に提供されるまでにはしばらく時間がかかるでしょう。より早急にすべきことは、クパチーノの開発者は開発者への教育を強化し、IAPの限界を理解し、シンプルかつ安全な検証手順の実装方法を指導することです。iOSの開発者向けドキュメントはこの分野で著しく不足しており、もう少し情報を追加する必要があるのは明らかです。
そして最後に、一般の人々も啓蒙される必要があります。「権力者に反抗する」ために、開発者に一銭も支払わずにIAPを作るのは楽しいように聞こえるかもしれませんが、権力者が反撃してくる可能性は十分にあります。
覚えておいてください、このハッキングは、それを使用するすべての人のiTunes認証情報を公開します。つまり、ハッカーは自分のトリックを使ったすべての人のiTunesアカウントにアクセスできることになります。そして、IAPの回避は本質的に詐欺であるため、いつか法執行機関がそれらの認証情報を入手し、関係者全員に多くの不快な疑問を投げかける可能性も全く考えられません。
それが何を意味するのか
この事件がApp Storeに長期的な影響を及ぼすかどうかは分かりません。しかし、ハッキングの成功率から判断すると、多数のアプリが影響を受けているようです。少なくとも、開発者とAppleの両方にとって警鐘となるはずです。
一方で、開発者はIAP（アプリ内課金）の取り扱いを改善できる（そして改善すべき）はずです。ソフトウェア業界は反対を唱えていますが、著作権侵害と売上の損失を正しく関連付けることは困難です。それでも、開発者にとって、自社のソフトウェアが適切に開発されていることを保証することは最善の利益であり、それには正当な対価が支払われることも含まれます。
一方で、Appleはこの問題をほぼ防ぐことができたはずです。この問題は、不満を抱く開発者を大量にAppleに残すだけでなく、データに与える損害の大きさに比べれば取るに足らない目的でデバイスのセキュリティを侵害しているユーザーに広範囲にわたる影響を及ぼす可能性があります。たとえAppleがこの特定のハッカーをシャットダウンしたとしても、事態はもはや明らかであり、誰かが同様のことを、おそらくより悪質な意図を持って試みるのを阻止することはほとんど不可能です。
それでも、Appleは長年にわたり正しい行いをしてきた歴史があり、Lodsys事件の時のように、過去には開発者のために尽力してきました。今回のケースでは、Appleは複数の解決策を用意しており、その中には既存の開発者向けアウトリーチプログラムに容易に組み込めるものもあります。クパチーノの力を借りれば、IAPは今後もiOSユーザー（そして開発者）のエクスペリエンスにおいて重要な部分であり続ける可能性が非常に高いでしょう。
[ Macworld に頻繁に寄稿している Marco Tabini 氏も開発者です。 ]
