Wednesday, December 14, 2011

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

檢視這些相當棒的練習來幫助你實作iap機制出來的APP更加的安全,也有更好的設計。

原文連結︰Security and Design
翻譯︰小鰻
翻譯版本號︰v.1.0
如需轉載請註明出處「小鰻的Android學習筆記
讓我參與最直接的討論以及錯誤修正, 謝謝!

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.
當你要開始實作應用程式內部金流(以下簡稱iap)機制時,請確認您已遵照本文件所討論的安全與設計導引。這些導引對每一位想要使用Android市集iap服務的人來説,都是被推薦的相當好的實例。

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:
為了抵禦惡意使用者搞你的未鎖定內容,請勿將它包裏在你的apk中。反之,下列取其一來執行︰
  • 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.
當你透過遠端伺服器或即時服務發容你的內容時,你可以將未上鎖的內容儲存於裝置記憶中,或者存在裝置上的SD卡裡。如果你將內容儲存在SD卡裡,請確定有將內容加密,並且使用裝置上獨特的加密金鑰。

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.
若要運行程式模糊,我這裡稍微提一下,我們建議你遵從下列的技術來對你的iap原始碼做模糊處理︰
  • 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.
使用這些技術來幫助你降低APP的攻擊面,這將使你實作iap機制以及攻擊降至最低的考量得到有效的妥協。

Note: If you use Proguard to obfuscate your code, you must add the following line to your Proguard configuration file:
註︰如果你使用Proguard來模糊你的原始碼,你必須加下列這行加進您Proguard設定檔裡︰
-keep class com.android.vending.billing.**

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.
由於iap範例程式是公開發佈的,而且可以被每一個人下載,如果你完完全全的使用範例程式來使用iap,這就意謂著很容易被黑客使用逆向工程攻擊。這份範例程式目的只是希望拿來示範。假如你使用了範例程式中的任何一部份,你都必須在發佈或釋出程式前修改掉這部份的程式碼。

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.
如果你看到你的應用內容被重新發佈至Android市集,請快速、果斷的發佈出商標侵權通知或版權侵權通知。

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

保護好你的Android市集公鑰

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.
為了您的公開金鑰安全性,不被惡意使用者或黑客攻擊,請不要將公鑰寫成字串格式,嵌入至您的原始碼中。相反的,最好是在執行期間建構字串或使用少許的操控方式(如XOR或其它的字串符)來隱藏您真實的金鑰。金鑰本身雖然不是什麼秘密的資訊,但您應該不會想要那麼輕易的就讓黑客或惡意的使用者將您的金鑰置換成其它的金鑰。

相關文章︰
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(中文翻譯)

6 comments:

Lak said...

Construct strings on the fly instead of defining them as constants

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

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

Note,
當然,Java 不是用 compiler,但我忘了直譯器的英文了,就原諒我吧,我懶的再去查了....
不過大致上的意思應該是沒有錯才對啦...

Unknown said...

Dear Lak,
謝謝你的建議。
安全與設計是7篇iap機制中最難翻譯的一篇(太多技術字和觀念),我一收到你的意見時,就馬上把這段丟給Google團隊做出詢問,現在在等他們的回覆,我會再做出更好且正確的翻譯修改。

J.Work said...

Hello,

Construct strings "on the fly"...

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

FYI. Thanks.

Unknown said...

太厲害啦!!!!

Unknown said...

太厲害啦!

Unknown said...

太厲害啦!!!!