Enhanced Security Solution in Android

1 背景知識：Android/BMP/J2ME中應用的權限和簽名

1.1 J2ME中的簽名和權限

J2ME的應用默認須要簽名，是否簽名以及使用什麼證書籤名的目的並不是限制僅特定應用運行，而是獲知應用的開發商以及對應用申請的權限的仲裁。J2ME中的權限分紅不一樣的Domain，而不一樣Domain中的權限申請是否經過仲裁取決於不一樣Domain對應的證書籤名。這是一種分級權限管理。好比，咱們假設全部的權限分紅Developer Domain和OEM Domain， 那些常見的低風險的權限，都屬於Developer Domain。 另一些較少的，可是高風險的權限，屬於OEM Domain。對於Developer Domain權限的仲裁，可能默認直接經過，而對OEM Domain的權限，則必須由OEM廠商簽名的應用才能獲取。

1.2 BMP中的簽名和權限

BMP中的應用必須簽名，這裏的簽名是限制應用是否能夠運行。一般OEM廠商預置部分根證書，好比Qualcomm BMP的根證書，OEM自身的根證書。只有預置的證書廠商簽名的BMP應用，才能被容許運行。BMP中的應用申請的權限，則直接受簽名保護。只要簽名驗證經過了，那麼全部申請的權限將所有被批准。

1.3 Android中的簽名和權限

Android中的應用簽名並不是是限制應用的運行，僅僅是標識應用的開發者以及仲裁某些特定的高風險權限。Android的應用容許簡單的自簽名，而不須要使用信任的CP廠商的證書籤名。Android中應用申請的權限分爲兩類，一類是開放型的，申請後，只要安裝時用戶接受，就能夠成功獲取。另外一類是仲裁型的，通常是高風險的，申請後，只有應用的簽名證書符合特定證書時，才能獲取，好比Platform證書，這一類的權限仲裁方式，其實和J2ME的Domain的概念相似。

2 以分級（Tier）方式擴展Android的權限

2.1 現狀

默認的Android App的權限管理粒度太粗，基本上大部分的權限屬於開放型，小部分的權限與某個證書籤名關聯，好比Platform，可是沒有再細分粒度。

2.2 擴展

爲了開發和開放更多的功能同時能按級限制，能夠把Android的權限按Tier進行多層劃分。Tier0，Tier1，Tier2，Tier3等。 這裏Tier0是最低等級，Tier3是最高等級。高等級默認直接受權容許擁有低等級的全部權限，在此基礎上再加額外的權限許可。舉個例子：

Tier0針對全部的開放型權限，即只須要申請，用戶批准便可擁有的。

Tier1： 包含3組， Media， Phone， File。 分別對應中風險的Media相關操做，中風險的Phone相關操做，中風險的File相關操做。 與3個預置的證書關聯。對於Tier1的任何權限，必須App申請，同時App的簽名證書與該權限關聯的預置證書相同，才被受權。

Tier2： 假設與一張證書關聯，任何Tier2或者Tier3中的權限申請，只要App的簽名是Tier2的簽名，則被受權。

2.3 模式

App須要申請；

受權是按分組，分級進行的。

3 與ISV的合做

3.1 功能開放

爲ISV開放/開發的任何新功能，默認頂層以Framework擴展API或者類的方式提供。爲了不源碼泄露以及與ISV的緊耦合以及ISV多套代碼的維護，不建議直接提供更新的Jar環境給ISV（這同時也是一個維護問題）。而是僅僅提供簡單的User Interface文檔，說明咱們新增長的功能與使用方式。ISV在通用的代碼中利用Java的反射機制來動態查詢和使用這些功能，若是運行時存在，則使用之，若是沒有，就不使用。這樣可使得ISV不依賴於咱們的Framework，而能以同一套代碼運行於通用的Android手機上。

3.2 驗證模式

開放的功能中，部分涉及到高風險操做，對於這部分的API操做，須要進行受權，即，只有受權的ISV應用，才能使用之，或言之才能正常使用之。

這裏，咱們能夠基於Tier的權限擴展模式。具體以下：

1.       針對新開放的安全相關的功能，定義一組或者多組新的權限

2.       使用一個或者多個證書關聯/認證這組新的權限，好比，預置 ISV_TIER_ROOT_CERTIFICATE

3.       APP必須在Manifest中顯式的申請這些權限並使用ISV_TIER_ROOT_CERTIFICATE證書籤名才能在安裝時被許可擁有這些新的權限。

4.       擴展的新功能中，須要安全認證時，Check是否當前Client擁有這些新的權限，若是沒有，則直接Reject。

3.3 測試模式

1.       實現test enable功能（利用Property記錄，default關閉）。當打開test enable後，ISV權限的申請退化爲Tier0的方式，即不須要簽名關聯。

2.       ISV廠商自身測試時，使用自簽名，並打開test enbale測試

3.       ISV認證中心驗證測試時，打開test enbale測試。

3.4 發佈模式

1.       Delivery 接口文檔和權限文檔給ISV

2.       Delivery test handset給ISV（ISV不須要測試，則不須要這一步）

3.       ISV開發

4.       ISV打開test enable並自測試（ISV不須要測試，則不須要這一步）

5.       ISV Delivery應用至ISV認證中心

6.       ISV認證中心打開test enable並測試應用

7.       測試經過，則使用ISV專用證書對ISV App從新簽名打包。獲得通過ISV認證的APK。

8.       上架，分發。

4 OEM廠商Android自身安全定製

4.1 更加嚴厲的限制私密數據的訪問

4.1.1 現狀

Android的電話本，短信，SD卡的任何內容，網絡使用等操做默認狀況下都是開放型的，即只須要應用申請了，安裝時，用戶接受就被許可了。但是，用戶爲了要安裝應用，又有誰真的去好好看過這些權限那，普通用戶都是簡單的accept！

問題來了！！你的電話本記錄被偷偷的在掃描。你的照片，視頻被偷偷的掃描並上傳到網絡……… 很恐怖！

4.1.2 保守型方案

將電話本，短信，SD卡的任何內容的訪問權限，歸入到>Tier0， 並基於簽名來受權。受權的粒度能夠由OEM本身決定，好比，只容許System自帶的Contact等App訪問（Platform證書）以及受權的ISV app訪問（ISV證書籤名）

4.2 有選擇性的開放最高權限給系統級應用

在默認的Android中，任何APK是沒法以Root權限運行的。若是OEM廠商有須要，但願一個自帶的系統級別的應用能以Root運行從而實現一些比較Creative的功能，那麼比較簡單的一種方案，就是新擴展一種ROOT_PERMISSION，與Platform證書關聯。任何使用Platform證書籤名的APK，若是申請ROOT_PERMISSION那麼安裝的時候，將其UID設置爲0.這樣App運行時，Zygote Fork出新的進程後，將仍然以UID = 0 來重置UID，那麼，該APP將以ROOT來運行。