サーバー購入モデルについては、Appleの図をご覧ください。
ステップ9で、サーバーは、購入の資格があるiPhoneと実際に通信していること、およびイブが不正に取得したレシートでリプレイを実行していないことをどのように知ることができますか？
領収書は有効である可能性がありますが、それは送信者が資格のある当事者であることを証明するものではありません。
領収書に署名するために使用できるiPhoneのデバイス証明書の概念はありますか？
レシートをデバイスにバインドする方法、またはレシートをiTunesアカウントとデバイスの両方にバインドして、サーバーが検証できるようにする方法はありますか？
Appleが提供する脆弱なアプローチ
サーバーは、次のようにして購入を認証できます。
iPhoneアプリケーションはtransactionReceipt購入後に受け取ります。iPhoneのbase64でエンコードして（ NSDataへのこのオープンソースの追加を使用できます）、サーバーに送信します。（そのまま送信して、検証前にサーバーbase64にエンコードさせることもできます。）
サーバーに、HTTPPOSTを 使用するようにreceipt-dataエンコードされたbase64の単一キーを使用してJSONリクエストを送信してもらいます。（さまざまなサーバー側言語でこれを行う方法については、このサイトを参照してください）transactionReceipthttps://buy.itunes.apple.com/verifyReceipt
サーバーは、2つのキーを持つJSONオブジェクトで応答します。statusこれは整数でreceiptあり、受信が繰り返されます。
ステータスがゼロの場合、レシートは有効です。ゼロ以外の値は、レシートが無効であることを意味します。
Appleのアプローチへの安全な追加
ただし、セキュリティにはいくつかの影響があります。デバイスがレシートに関連付けられていないため、ユーザーは別のユーザーのレシートを使用できます。または、サーバーがレシートの製品IDを確認しないため、ユーザーは別の製品のレシートを使用できます。これが起こらないようにするには、次のことも行う必要があります。
アプリケーションで最初に領収書を受け取ったら、HTTPSやSSLソケットなどの安全なチャネルを介して、デバイスのUUIDと一緒にすぐにサーバーに送信します。どこにも保存せず、メモリに残しておきます。
サーバーで、UUIDとレシートのペアをデータベースに保存します。
デバイスがUUIDとレシートのペアを送信するときは、レシートがまだ使用されていないことをデータベースで確認し、レシートの製品IDを確認して、レシートが実際に製品のものであることを確認します。レシートは単なるJSONオブジェクトであるため、サーバーはbase64からレシートをデコードすることでコンテンツを読み取ることができます。
安全なチャネルを介してデバイスに応答を返し、購入が次のとおりであるかどうかを通知します。
レシートはデバイスのメモリにのみ存在し、アプリケーションはデバイスのUUIDを使用し（ジェイルブレイクされたデバイスによってスプーフィングされる可能性があります。コメントを参照）、製品のすべての購入はサーバー上のデバイスのUUIDに安全に記録されます。 ; ユーザーは、他のユーザーの領収書を使用して購入を確認したり、他の製品の領収書を使用したりすることはできません。これを確認するためです。
トランザクションの他の詳細を確認する場合は、領収書から他のフィールドを検証することもできます。たとえば、製品がサブスクリプションである場合は、トランザクションの日付も確認する必要があります。
また、ユーザーはSSL証明書を持っていないため、同じ名前のホストを持つプライベートネットワーク上にデバイスを置いてサーバーのふりをすることはできません。
障害に関する考慮事項
ユーザーのデバイスがレシートを受け取ってからサーバーで確認するまでの間に障害が発生する可能性があるため（たとえば、ユーザーが接続を失った場合、またはサーバーがメンテナンスのためにダウンした場合）、ユーザーに「再承認」を許可する必要があります。再承認は、 （復元されたトランザクションを使用して）ストアからレシートを取得し、これが新規購入であるかのようにサーバーに再送信する必要があります。これを使用する必要はめったにありませんが、ネットワーク障害が発生した場合にユーザーが製品を再購入する手間を省くために利用できる必要があります。
複数のデバイスに関する考慮事項
つまり、ユーザーが複数のデバイスでアプリケーションを使用する場合は、製品を複数回購入する必要があります。これは望ましい効果かもしれませんが、ユーザーがアカウントに関連付けたデバイス間でコンテンツを使用できることを期待している可能性があるため、購入する前にユーザーに通知する必要があります。
レシートにiTunesアカウント情報も含まれている場合、認証ではそれを使用して、ユーザーがすべてのデバイス間でコンテンツを共有できるようにすることができます（ただし、友達は共有できません）。
領収書をデバイスにバインドできるとは思いません。
私の理解では、追加費用なしで複数のデバイスにアプリケーションをインストールすることが許可されています。それをデバイスにバインドすると、たとえば電話をアップグレード/変更した場合、すべてのアプリを再度購入する必要があります。
Beniot の回答は素晴らしいですが、Joe D'Andrea が述べたように、UDID は非推奨であり、最後に試したとき、呼び出しを使用して UDID を取得するアプリは、iTunes へのアップロード中に検証に合格しませんでした。
hloupyhonza の回答に追加するには、特定のレシートの「ダウンロード リクエスト」カウンターを用意するだけでなく、レシートの有効期間を時間で制限することもできます。12 時間から 24 時間の間が妥当であることがわかりました。
この方法では、購入者は、同じ Apple ID で App Store にログインしている限り、所有する他のデバイスで購入したものを使用することもできます。注: 購入の復元が完了するたびに、Apple は完全に新しい領収書 (元の領収書の詳細が含まれています) を返します。これにより、特定の領収書に設定された期限を過ぎても購入を復元できます。
典型的な「Googled」ハッキング ソリューションを防ぐために (私のデータは、これがほとんどすべての IAP ハッキング試行を構成していることを示しています)、次の連結のチェックサムを使用します (お気に入りのアルゴリズムを選択してください。
アプリは、検証サーバーから返されたチェックサムを検証します。ただし、ハッカーがアプリのバイナリから共有キーを取得する可能性があるため、これは完全ではありません。しかし、これまでのところすべての「市販の」ハッキングを防止しており、私の使用には十分です。
ユーザーの Apple ID を読み取ることができない場合、著作権侵害に対する唯一の保護は、transaction_id ごとのダウンロード要求の数を (もちろんサーバー側で) 追跡し、それらが特定の値を超えた場合にそれらを制限することだと思います。
したがって、50 に制限すると、ユーザーがアプリを展開し、そのコンテンツを複数のデバイスに展開して数回復元するための妥当なマージンが得られますが、無制限の有効な領収書を使用して海賊版を配布したい人にとっては困難になります。復元します。もちろん、彼らはあなたのすべてのコンテンツを含むバージョンを配布することはできますが、それについてあなたができることは何もありませんし、少なくともサーバーに負担をかけることはありません.