予約されたアイテムは署名された静的なレスポンスを返すこともあり、アプリのシグネチャ検証テストが行えます。特別に予約された商品IDでシグネチャ検証のテストを行うには、テストアカウントを取得するか、非公開のドラフトアプリとしてアプリをアップロードする必要があります。
表は静的レスポンスが署名されている状態を示します。
公開済みアプリか | ドラフトアプリか | アプリ実行者 | シグネチャ |
---|---|---|---|
No | No | 誰でも | 未署名 |
No | No | 開発者 | 署名済み |
Yes | No | 誰でも | 未署名 |
Yes | No | 開発者 | 署名済み |
Yes | No | テストアカウント | 署名済み |
Yes | Yes | 誰でも | 署名済み |
予約された商品IDで課金リクエストを作成するためには、単に普通のREQUEST_PURCHASEリクエストを作成しますが、その際、アプリの商品リストから本当の商品IDを使用するのではなく、予約された商品IDの1つを使用してください。
予約された商品IDを使用したアプリをテストするには、まずAndroidがサポートされたデバイスにアプリをインストールします。アプリ内課金のテストにエミュレータは使用できません。開発者はアプリ内課金をテストするためにアプリをデバイスにインストールする必要があります。
次に、開発者アカウントでデバイスにサインインします。予約された商品IDでのみテストを行うのであれば、テストアカウントは必要ありません。
そして、デバイス上で動作しているAndroid MarketアプリまたはMyAppsアプリのバージョンがサポートされているか確認します。最後にアプリを実行し、予約された商品IDを購入します。
静的レスポンステストとアプリ内でのシグネチャ検証が完了した後、実際のアプリ内商品を使用してアプリ内課金の実装をテストできます。
実際のアプリ内購入テストでは、Android Marketからの実際のレスポンスと、実際のアプリでユーザーが行うチェックアウト処理を含む、エンド・トゥ・エンドなアプリ内課金のテストが可能です。
このテストを行うためには、少なくとも1つのテストアカウントが必要です。開発者自身のアカウントでは、アプリ内購入テストを完全には行えません。なぜなら、Googleチェックアウトは自分自身の商品を購入できない仕様だからです。もし開発者がテストアカウントを取得していないなら、「テストアカウントの設定」を参照してください。
テストアカウントを使用して商品を購入するとき、テストアカウントはGoogleチェックアウトから課金され、開発者のGoogleチェックアウトアカウントに購入の払い込みが届きます。テストアカウントからの購入であるため、開発者は、その払い戻しも、アカウントに対しての実際の支払いも確認できます。
実際の購入でアプリ内課金実装テストするためには、まず、アプリを開発者サイトのドラフトアプリとしてアップロードします。アプリは公開する必要はありません。
次に、アプリの商品リストに商品を追加します。商品を公開することを忘れないでください。テストアカウントでは、商品が公開されている場合は、商品リスト内の商品のみ購入ができます。アプリは公開されている必要はなく、商品は公開されている必要があります。商品の公開の詳細は、「課金する商品リストを作成するには」を参照してください。
そして、Androidがサポートされたデバイスにアプリをインストールします。エミュレータでは、テストできません。また、デバイスのプライマリアカウントをテストアカウントの1つにする必要があります。デバイスのプライマリアカウントがテストアカウントではない場合、デバイスを工場出荷時状態にリセットし、テストアカウントでサインインしなければいけません。
最後に、デバイスで動作しているAndroid Marketアプリ、またはMyAppsアプリのバージョンがサポートされているか確認し、アプリでアプリ内購入を行います。
アプリ内課金実装のテストが完了したら、Android Marketでアプリを公開する準備が整っています。通常と同様の準備や署名、アプリの公開を行ってください。
なお、リセットするには、以下の手順で行います。
アプリ内課金実装の設計で、以下で説明されているセキュリティと設計のガイドラインを確認してください。これらガイドラインはAndroid Marketのアプリ内課金サービスを使用する、すべてのアプリに対して推奨される方法です。
開発者はデバイス上ではなくリモートサーバ上でシグネチャ検証を行うことが推奨されます。サーバ上でのシグネチャ検証プロセスの実装は、.apkファイルがリバースエンジニアリングされたとしても、ハッキングを困難にします。もしリモートサーバにセキュリティ処理を移譲するなら、デバイスとサーバ間の通信がセキュアであることを確認してください。
悪意あるユーザーがアンロックされたコンテンツを再配布するのを妨ぐために、.apkファイルにコンテンツをバンドルしないでください。代わりに、以下のいずれかで対応することをお勧めします。
リモートサーバまたはリアルタイムサービスからコンテンツを配信する際に、アンロックされたコンテンツをデバイスのメモリやSDカードなどのストレージに保存できます。SDカードにコンテンツを保存した場合、コンテンツの暗号化や復号にはデバイス固有のキーを使用しましょう。
セキュリティプロトコルと、その他のアプリのコンポーネントをリバースエンジニアリングされることを難しくするために、アプリ内課金コードを難読化しましょう。以下のテクニックをお勧めします。
これらのテクニックを使うことは、アプリに対する攻撃減少補助になり、アプリ内課金実装への攻撃は削減されます。
Proguardを使用する場合、以下の行をProguardの設定ファイルに追加する必要があります。
-keep class com.android.vending.billing.**
アプリ内課金のサンプルアプリは公に配布されており、誰でもダウンロード可能です。つまり、サンプルアプリをそのまま使用することは、リバースエンジニアリングが比較的簡単であることを意味します。サンプルアプリは、例としてのみ使用されるように意図されています。もしサンプルアプリの一部をアプリに組み込む場合、組み込んだ部分を公開、またはリリース前に修正しなければいけません。
特に、クラッカーはアプリのエントリポイントを探すため、サンプルアプリとまったく同じ実装でなくなるように修正することが重要です。
「ナンス」(一度だけ使用されるランダムな数値)は予測されたり再利用されたりしてはいけません。常に暗号上安全でランダムな数字を作成する「SecureRandom」クラスのようなジェネレータを、ナンスを作成する際に使用してください。これは繰り返し攻撃されるのを削減する補助になります。
ナンスの検証をサーバ上で行うなら、ナンスの生成もサーバ上で行うことを検討してください。
アプリのコンテンツがAndroid Marketで再配布されていることを発見した場合、すぐに行動に移してください。商標違反侵害、または著作権違反侵害を申し立てましょう。
コンテンツ配信および管理のためにリモートサーバを使用する場合、ユーザーがコンテンツにアクセスするときに常にアンロックコンテンツの購入状態をサーバに問い合わせてください。これは必要であればコンテンツを取り消し、海賊行為を最小限に抑えます。
公開鍵を悪意あるユーザーとクラッカーから守るには、アプリに公開鍵を文字列リテラルとして組み込まないことです。代わりに、文字列を複数に分割し、ビット演算などにより実行時に結合し、実際の鍵を隠ぺいします。
公開鍵は文字どおり公開される情報ですが、クラッカーや悪意あるユーザーによって公開鍵を他の鍵と取り換えられること自体は容易に行われてはいけません。
アプリ内課金は、サンプルが提供されているため、比較的容易にサンプルをベースにアプリに実装を組み込める半面、金銭を扱うコードであるため、テストとセキュリティには十分に取り組まなければいけません。
特にセキュリティに関しては、注意して注意し過ぎることはないので、開発者の取り得る最大限を尽くしてください。
アプリ内課金の登場により、これまでとは異なるアイデアの優良なアプリがAndroid Marketに今後たくさん登場することが期待され、Android市場がますます活性化していくことでしょう。
Copyright © ITmedia, Inc. All Rights Reserved.