1page.title=Security and Design 2parent.title=In-app Billing 3parent.link=index.html 4@jd:body 5 6<div id="qv-wrapper"> 7<div id="qv"> 8 <h2>In this document</h2> 9 <ol> 10 <li><a href="#billing-security">Security Best Practices</a> 11 <ol> 12 <li><a href="#unlocked">Protect Unlocked Content</a></li> 13 <li><a href="#obfuscate">Obfuscate Your Code</a></li> 14 <li><a href="#sample">Modify Sample Code</a></li> 15 <li><a href="#nonce">Use Secure Random Nonces</a></li> 16 <li><a href="#payload">Set the Developer Payload String</a></li> 17 <li><a href="#trademark">Report Trademark and Copyright Infringement</a></li> 18 <li><a href="#revocable">Implement a Revocability scheme</a></li> 19 <li><a href="#key">Protect Your Public Key</a></li> 20 </ol> 21 </li> 22 </ol> 23 <h2>See also</h2> 24 <ol> 25 <li><a href="{@docRoot}google/play/billing/billing_overview.html">Overview of In-app 26 Billing</a></li> 27 </ol> 28</div> 29</div> 30 31<p>As you design your In-app Billing implementation, be sure to follow the security and design 32guidelines that are discussed in this document. These guidelines are recommended best practices for 33anyone who is using Google Play's In-app Billing service.</p> 34 35<h2>Security Best Practices</h2> 36 37<h3 id="sign">Perform signature verification tasks on a server</h3> 38<p>If practical, you should perform signature verification on a remote server and not on a device. 39Implementing the verification process on a server makes it difficult for attackers to break the 40verification process by reverse engineering your .apk file. If you do offload security processing to 41a remote server, be sure that the device-server handshake is secure.</p> 42 43<h3 id="unlocked">Protect your unlocked content</h3> 44<p>To prevent malicious users from redistributing your unlocked content, do not bundle it in your 45.apk file. Instead, do one of the following:</p> 46 <ul> 47 <li>Use a real-time service to deliver your content, such as a content feed. Delivering content 48 through a real-time service allows you to keep your content fresh.</li> 49 <li>Use a remote server to deliver your content.</li> 50 </ul> 51<p>When you deliver content from a remote server or a real-time service, you can store the unlocked 52content in device memory or store it on the device's SD card. If you store content on an SD card, be 53sure to encrypt the content and use a device-specific encryption key.</p> 54 55<h3 id="obfuscate">Obfuscate your code</h3> 56<p>You should obfuscate your In-app Billing code so it is difficult for an attacker to reverse 57engineer security protocols and other application components. At a minimum, we recommend that you 58run an obfuscation tool like <a 59href="{@docRoot}tools/help/proguard.html">Proguard</a> on your 60code.</p> 61<p>In addition to running an obfuscation program, we recommend that you use the following techniques 62to obfuscate your In-app Billing code.</p> 63<ul> 64 <li>Inline methods into other methods.</li> 65 <li>Construct strings on the fly instead of defining them as constants.</li> 66 <li>Use Java reflection to call methods.</li> 67</ul> 68<p>Using these techniques can help reduce the attack surface of your application and help minimize 69attacks that can compromise your In-app Billing implementation.</p> 70<div class="note"> 71 <p><strong>Note:</strong> If you use Proguard to obfuscate your code, you must add the following 72 line to your Proguard configuration file:</p> 73 <p><code>-keep class com.android.vending.billing.**</code></p> 74</div> 75 76<h3 id="sample">Modify all sample application code</h3> 77<p>The In-app Billing sample application is publicly distributed and can be downloaded by anyone, 78which means it is relatively easy for an attacker to reverse engineer your application if you use 79the sample code exactly as it is published. The sample application is intended to be used only as an 80example. If you use any part of the sample application, you must modify it before you publish it or 81release it as part of a production application.</p> 82<p>In particular, attackers look for known entry points and exit points in an application, so it is 83important that you modify these parts of your code that are identical to the sample application.</p> 84 85<h3 id="nonce">Use secure random nonces</h3> 86<p>Nonces must not be predictable or reused. Always use a cryptographically secure random number 87generator (like {@link java.security.SecureRandom}) when you generate nonces. This can help reduce 88replay attacks.</p> 89<p>Also, if you are performing nonce verification on a server, make sure that you generate the 90nonces on the server.</p> 91 92<h3 id="payload">Set the developer payload string when making purchase requests</h3> 93<p>With the In-app Billing Version 3 API, you can include a 'developer payload' 94string token when sending your purchase request to Google Play. Typically, this 95is used to pass in a string token that uniquely identifies this purchase request. 96If you specify a string value, Google Play returns this string along with the 97purchase response. Subsequently, when you make queries about this purchase, 98Google Play returns this string together with the purchase details.</p> 99<p>You should pass in a string token that helps your application to identify the user who 100made the purchase, so that you can later verify that this is a legitimate purchase by 101that user. For consumable items, you can use a randomly generated string, but for non- 102consumable items you should use a string that uniquely identifies the user.</p> 103 104<p class="note"> 105 <strong>Note:</strong> Do not use the user's 106 email address in the payload string, since that address may change. 107</p> 108 109<p>When you get back the response from Google Play, make sure to verify that the 110developer payload string matches the token that you sent previously with the purchase 111request. As a further security precaution, you should perform the verification on your 112own secure server.</p> 113 114 115<h3 id="trademark">Take action against trademark and copyright infringement</h3> 116<p>If you see your content being redistributed on Google Play, act quickly and decisively. File a 117<a href="http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=141511"> 118trademark notice of infringement</a> or a <a href="http://www.google.com/android_dmca.html"> 119copyright notice of infringement</a>.</p> 120 121<h3 id="revocable">Implement a revocability scheme for unlocked content</h3> 122<p>If you are using a remote server to deliver or manage content, have your application verify the 123purchase state of the unlocked content whenever a user accesses the content. This allows you to 124revoke use when necessary and minimize piracy.</p> 125 126<h3 id="key">Protect your Google Play public key</h3> 127<p>To keep your public key safe from malicious users and hackers, do not embed it in any code as a 128literal string. Instead, construct the string at runtime from pieces or use bit manipulation (for 129example, XOR with some other string) to hide the actual key. The key itself is not secret 130information, but you do not want to make it easy for a hacker or malicious user to replace the 131public key with another key.</p> 132