Security and Design
Google Play In-app Billing の Security and Design の概要を自分の理解のために日本語でまとめてみました。
SSL署名チェックをサーバーでやる
Android in-app-billing のデータが改ざんされていないかの検証
java - How do I verify Android In-app Billing with a server with Ruby? - Stack Overflow
購入されたコンテンツを守る
- コンテンツフィードのような、real-time serviceを使うべき。そうすれば常に最新の状態に保てる。
- サーバーを使って購入されたコンテンツを配信すべき。
上記をやってるなら端末（のメモリやSDカード）に保存してもいいが、保存するなら暗号化すべき
コードを難読化する
Proguardとか使って難読化すべき。
他にも以下のような対処もできる。
- 他のメソッドの中にメソッドを入れる
- StringをConstantsとしてまとめて定義せずにその時々で作成する
- Javaリフレクションでメソッドを実行する（メソッドの文字列実行）
Javaリフレクションメモ(Hishidama's Java Reflection Memo)
Proguardを使ってる場合は、以下の設定を追加しなければならない。
-keep class com.android.vending.billing.**
サンプルコードは全て変更する
サンプルコードまんまだと攻撃者に見破られやすいので変更すべき。（処理の開始地点と終了地点とかね！）
セキュアでランダムなワンタイムトークンを使う
セキュアでランダムなワンタイムトークンを使うことでリプレイ攻撃を防げる。
サーバーでワンタイムトークンの検証をするならサーバーでワンタイムトークンを生成して使うべき。
第3回 悪意のある攻撃から身を守るには？ | Think IT（シンクイット）
developer payloadをセットする
ランダムでユニークなトークンをセットしてリクエストし、レスポンスで返ってきたトークンを検証すべき。またさらに用心するなら、そのトークンをセキュアなサーバーでも検証すべき。
商標や著作権違反に対抗する
Trademark infringement - Android Developer Help
Trademark infringement - Android Developer Help
購入コンテンツの取り消しを実装する
不正購入が判明した場合に購入コンテンツを取り消しできるようにすべき。
Google Play Public Key を守る
悪意のあるユーザーから守るために、PublickKeyを素のままコードに記載すべきではない。
その変わり分割したりXOR暗号化とかして実際のキーを隠すべき。
Javaで文字列の暗号化／複合化（※外部ライブラリを使わずに） - on the center line.
パブリックキー自体は秘匿情報を持ってないが、ハッカーによって簡単に他のキーに置き換えられたりしたら困るでしょ？（悪意のある開発者のパブリックキーに置き換えたアプリを不正に配布して売上をそいつに奪われたりするのを防ぐことができる）