Wednesday, December 14, 2011

[Android in-app billing第3篇]Security and Design安全與設計(中文翻譯)


原文連結︰Security and Design
讓我參與最直接的討論以及錯誤修正, 謝謝!

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 Android Market's in-app billing service.

Security Best Practices有關安全的優良實例

Perform signature verification tasks on a server在伺服端執行數位簽章的認証工作

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.
實際上,你應該在自行架設的遠端伺服器做數位簽章驗証的工作,而非在裝置上完成。在伺服器上實作驗証流程將會使黑客透過逆向工程破壞你apk檔的數位簽章流程更加困難。假設你將安全流程下放置遠端伺服器上運行時,也請確定伺服器裝置的握手過程(handshake,譯者註︰詳情請查關鍵字SSL handshake)是安全的。

Protect your unlocked content保護你的未鎖定內容

To prevent malicious users from redistributing your unlocked content, do not bundle it in your .apk file. Instead, do one of the following:
  • 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.
  • 請使用即時服務來傳遞你的內容,像是內容預載(content feed)。透過即時伺服器來傳送內容會讓你的內容永遠是最新的。
  • Use a remote server to deliver your content.
  • 使用遠端伺服器來傳遞你的內容。
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.

Obfuscate your code模糊你的原始碼

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 Proguard on your code.
你應該模糊您的APP iap金流機制原始碼,唯有如此,攻擊者若要逆向工程處理你APP的安全協議和應用程式元件時,也會比較困難。 最起碼,我們建議你至少在你的原始碼上做類似Proguard(程式碼模糊)的處理。
In addition to running an obfuscation program, we recommend that you use the following techniques to obfuscate your in-app billing code.
  • Inline methods into other methods.
  • 使用行內函式到其它的函式裡。
  • Construct strings on the fly instead of defining them as constants.
  • strings放在雲端,而非定義在實體裡(譯者註︰不太確定)。
  • Use Java reflection to call methods.
  • 使用Java反射機制來呼叫您的函式 。
Using these techniques can help reduce the attack surface of your application and help minimize attacks that can compromise your in-app billing implementation.

Note: If you use Proguard to obfuscate your code, you must add the following line to your Proguard configuration file:
-keep class**

Modify all sample application code修改全部的範例程式

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.

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.

Use secure random nonces使用安全隨機數

Nonces must not be predictable or reused. Always use a cryptographically secure random number generator (like SecureRandom) when you generate nonces. This can help reduce replay attacks.
隨機數必須無法被預料和可重覆使用。當你在產生隨機數時,通常都會使用機密性的安全隨機數生成器(像是SecureRandom) 。
Also, if you are performing nonce verification on a server, make sure that you generate the nonces on the server.

Take action against trademark and copyright infringement


If you see your content being redistributed on Android Market, act quickly and decisively. File a trademark notice of infringement or a copyright notice of infringement.

Implement a revocability scheme for unlocked content


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.
假設您今天使用遠端伺服器來傳遞您受管理的資料內容, 無論使用者是否有存取資料內容,您都必須要求您的APP去驗証未鎖定的內容的購買狀態。

Protect your Android Market public key


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.

1.[Android in-app billing前言]In-app Billing應用程式內部付費機制(中文翻譯)
2.[Android in-app billing第1篇]In-app Billing Overview應用程式內部付費機制概述(中文翻譯)
3.[Android in-app billing第2篇]Implementing In-app Billing實作應用程式內部金流機制(中文翻譯)
4.[Android in-app billing第3篇]Security and Design安全與設計(中文翻譯)
5.[Android in-app billing第4篇]Testing In-app Billing測試應用程式內金流機制(中文翻譯)
6.[Android in-app billing第5篇]Administering In-app Billing應用程式內金流機制的管理(中文翻譯)
7.[Android in-app billing第6篇(末)]In-app Billing Reference應用程式金流的相關API(中文翻譯)


Lak said...

Construct strings on the fly instead of defining them as constants

我個人認為這行的意思應該是指不要將你的 String 參數(當然是指重要的)設為 final static。

我如果沒記錯,compiler time 時,它們會被放到靜態的變數區,就變的很容易被反組譯。

當然,Java 不是用 compiler,但我忘了直譯器的英文了,就原諒我吧,我懶的再去查了....

小鰻 said...

Dear Lak,

Jerry Hsu said...


Construct strings "on the fly"...

應該是指 string 是執行的時候即時產生, 而不是直接定義在 Code 裡面.

FYI. Thanks.

illy Yi said...


illy Yi said...


illy Yi said...