| page.title=Security and Design |
| parent.title=In-app Billing |
| parent.link=index.html |
| @jd:body |
| |
| <div id="qv-wrapper"> |
| <div id="qv"> |
| <h2>In this document</h2> |
| <ol> |
| <li><a href="#billing-security">Security Best Practices</a> |
| <ol> |
| <li><a href="#unlocked">Protect Unlocked Content</a></li> |
| <li><a href="#obfuscate">Obfuscate Your Code</a></li> |
| <li><a href="#sample">Modify Sample Code</a></li> |
| <li><a href="#nonce">Use Secure Random Nonces</a></li> |
| <li><a href="#payload">Set the Developer Payload String</a></li> |
| <li><a href="#trademark">Report Trademark and Copyright Infringement</a></li> |
| <li><a href="#revocable">Implement a Revocability scheme</a></li> |
| <li><a href="#key">Protect Your Public Key</a></li> |
| </ol> |
| </li> |
| </ol> |
| <h2>See also</h2> |
| <ol> |
| <li><a href="{@docRoot}google/play/billing/billing_overview.html">Overview of In-app |
| Billing</a></li> |
| </ol> |
| </div> |
| </div> |
| |
| <p>As you design your In-app Billing implementation, be sure to follow the security and design |
| guidelines that are discussed in this document. These guidelines are recommended best practices for |
| anyone who is using Google Play's In-app Billing service.</p> |
| |
| <h2>Security Best Practices</h2> |
| |
| <h3 id="sign">Perform signature verification tasks on a server</h3> |
| <p>If practical, you should perform signature verification on a remote server and not on a device. |
| Implementing the verification process on a server makes it difficult for attackers to break the |
| verification process by reverse engineering your .apk file. If you do offload security processing to |
| a remote server, be sure that the device-server handshake is secure.</p> |
| |
| <h3 id="unlocked">Protect your unlocked content</h3> |
| <p>To prevent malicious users from redistributing your unlocked content, do not bundle it in your |
| .apk file. Instead, do one of the following:</p> |
| <ul> |
| <li>Use a real-time service to deliver your content, such as a content feed. Delivering content |
| through a real-time service allows you to keep your content fresh.</li> |
| <li>Use a remote server to deliver your content.</li> |
| </ul> |
| <p>When you deliver content from a remote server or a real-time service, you can store the unlocked |
| content in device memory or store it on the device's SD card. If you store content on an SD card, be |
| sure to encrypt the content and use a device-specific encryption key.</p> |
| |
| <h3 id="obfuscate">Obfuscate your code</h3> |
| <p>You should obfuscate your In-app Billing code so it is difficult for an attacker to reverse |
| engineer security protocols and other application components. At a minimum, we recommend that you |
| run an obfuscation tool like <a |
| href="{@docRoot}tools/help/proguard.html">Proguard</a> on your |
| code.</p> |
| <p>In addition to running an obfuscation program, we recommend that you use the following techniques |
| to obfuscate your In-app Billing code.</p> |
| <ul> |
| <li>Inline methods into other methods.</li> |
| <li>Construct strings on the fly instead of defining them as constants.</li> |
| <li>Use Java reflection to call methods.</li> |
| </ul> |
| <p>Using these techniques can help reduce the attack surface of your application and help minimize |
| attacks that can compromise your In-app Billing implementation.</p> |
| <div class="note"> |
| <p><strong>Note:</strong> If you use Proguard to obfuscate your code, you must add the following |
| line to your Proguard configuration file:</p> |
| <p><code>-keep class com.android.vending.billing.**</code></p> |
| </div> |
| |
| <h3 id="sample">Modify all sample application code</h3> |
| <p>The In-app Billing sample application is publicly distributed and can be downloaded by anyone, |
| which means it is relatively easy for an attacker to reverse engineer your application if you use |
| the sample code exactly as it is published. The sample application is intended to be used only as an |
| example. If you use any part of the sample application, you must modify it before you publish it or |
| release it as part of a production application.</p> |
| <p>In particular, attackers look for known entry points and exit points in an application, so it is |
| important that you modify these parts of your code that are identical to the sample application.</p> |
| |
| <h3 id="nonce">Use secure random nonces</h3> |
| <p>Nonces must not be predictable or reused. Always use a cryptographically secure random number |
| generator (like {@link java.security.SecureRandom}) when you generate nonces. This can help reduce |
| replay attacks.</p> |
| <p>Also, if you are performing nonce verification on a server, make sure that you generate the |
| nonces on the server.</p> |
| |
| <h3 id="payload">Set the developer payload string when making purchase requests</h3> |
| <p>With the In-app Billing Version 3 API, you can include a 'developer payload' string token when sending your purchase request to Google Play. Typically, this is used to pass in a string token that uniquely identifies this purchase request. If you specify a string value, Google Play returns this string along with the purchase response. Subsequently, when you make queries about this purchase, Google Play returns this string together with the purchase details.</p> |
| <p>You should pass in a string token that helps your application to identify the user who made the purchase, so that you can later verify that this is a legitimate purchase by that user. For consumable items, you can use a randomly generated string, but for non-consumable items you should use a string that uniquely identifies the user.</p> |
| <p>When you get back the response from Google Play, make sure to verify that the developer payload string matches the token that you sent previously with the purchase request. As a further security precaution, you should perform the verification on your own secure server.</p> |
| |
| |
| <h3 id="trademark">Take action against trademark and copyright infringement</h3> |
| <p>If you see your content being redistributed on Google Play, act quickly and decisively. File a |
| <a href="http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=141511">trademark notice |
| of infringement</a> or a <a href="http://www.google.com/android_dmca.html">copyright notice of |
| infringement</a>.</p> |
| |
| <h3 id="revocable">Implement a revocability scheme for unlocked content</h3> |
| <p>If you are using a remote server to deliver or manage content, have your application verify the |
| purchase state of the unlocked content whenever a user accesses the content. This allows you to |
| revoke use when necessary and minimize piracy.</p> |
| |
| <h3 id="key">Protect your Google Play public key</h3> |
| <p>To keep your public key safe from malicious users and hackers, do not embed it in any code as a |
| literal string. Instead, construct the string at runtime from pieces or use bit manipulation (for |
| example, XOR with some other string) to hide the actual key. The key itself is not secret |
| information, but you do not want to make it easy for a hacker or malicious user to replace the |
| public key with another key.</p> |
| |