簽名和許可權的作用

Android簽名中使用到的一些加密技術有:

公/私鑰, SHA1(CERT.SF,MANIFEST.MF), RSA(CERT.RSA), 訊息摘要,

移動平臺中的主流簽名作用:

• Android平臺中是使用自簽名
  自簽名,證書的簽名者和證書擁有者是同一人.

自簽名的完整性認證

自簽名是沒有信任模式的,因為自簽名信息是自己的,對無法知道該資訊是不是安全,我們只能對其的完整性進行認證.

限制安裝和執行

下面是限制應用安裝和執行的流程

• 應用安裝時
  校驗是否含簽名 –> 沒有,禁止安裝
  –> 有,提取證書進行校驗–> 證書是否有效可信任–> 不是禁止安裝.

  基於證書的公鑰對簽名進行校驗–> 簽名是否正確 –> 不正確禁止安裝.

• 應用執行時
  校驗是否包含簽名 –> 沒有,禁止執行
  –> 有,提取證書進行校驗–> 證書是否有效可信任–> 不是禁止執行.(這一步跟安裝流程相似)

  基於證書的公鑰對簽名進行校驗–> 簽名是否正確 –> 不正確禁止執行.(這一步跟安裝流程相似)

許可權的作用(細粒度的特權管理)

• 許可權是一個ID或者一個字串
• 謙虛用來細分權利(類似Capability,分散權利)
• 通常一個許可權與一個類操作繫結
• 許可權首先需要申請(AndroidManifest或者程式碼動態申請)
• 但是申請後是否被批准有平臺策略決定
  

  如:使用者需要讀取SDCard的許可權,這時Android平臺會彈出訪問SDCard的視窗,如果使用者accept了,那這個許可權就被申請.

許可權的安全性保護(通過簽名)

• 許可權的完整性保護(防篡改)
  如發簡訊的方式,不可能沒發一條簡訊都彈dialog來申請許可權,所以這時開發只要在Manifest 中新增 sendSMS permission 就可以.(通過認證並獲得簽名後再加policy許可權)

• 許可權的授權安全策略(防Escalate)
  如普通應用申請Inject Event 許可權(注入)

簽名作用

完整性鑑別

• 自簽名支援完整性鑑別
  Android中使用的是自簽名方式,那就是無法對簽名的信任進行認證,只能通過他的完整性鑑別.

• 不做安裝和執行時的限制(不做信任模式)
  Android不會在安裝的時候進行Signature Permission 的驗證,他僅僅是做Signature(簽名) 這步驟.

Signature Permission 和ShareUID(TODO 講得不錯要做詳細)

• Signature Permission(Signature Permission Level Permission)
  相當於他對一些特權的permission 他用單獨的signature 方式去驗證.

  • 示例程式碼塊:

 <permission android:name="android.permission.HARDWARE_TEST"//許可權名稱,要注意命名規範
    android:permissionGroup="android.permission-group.HARDWARE_CONTROLS"//在顯示時對許可權進行歸類
        android:protectionLevel="signature"// 許可權安全界別
    android:label="@string/permlab_hardware_test"// 在對應語言系統上顯示

  android:description="@string/permdesc_hardware_test" 
  //該許可權的描述與使用
  /> 

上面的protectionLevel="signature" ,因此他並不是給第三方應用去使用的.對於普通的app去使用該許可權的話肯定是會被拒絕的.但是對於如果是系統應用的話只要要.mk 裡的config寫的是security="platefrom" 那麼這個app裡的Signature 就會使用平臺的private key 進行簽名.

• ShareUID(Share Process UID)

  • 示例程式碼塊:
    android:sharedUserid="xxx"

  其實Android中的UID也是在manifest 中寫的,如上面程式碼,那麼Android重為什麼要有UID.
  UID其實是一個特權的概念,不同檔案對一些許可權會做一些限制,如對於 uid="owner" 會用r/w/x 許可權,而對於uid="other" 可能就會連read 的許可權都沒有.這樣就可以使得Android中每一個 project他對於的資源目錄下是屬於一個private 的狀態.
  所以Android很好的引用了Linux自有的一些特性,將每個專案通過群組(UID)的方式分離出來.

  • Process間Share UID的目的是共享資源
    如果a,b,c三個應用他們之間的share UID是同一個,那麼這幾個應用間的資源是開源互相訪問的.

    漏洞: 那麼這樣就會引出一個安全問題,如果360配置的時候將share UID設定成 QQ應用一樣,而且框架允許的情況下,那麼問題就來了,360可以很簡單的就訪問到了qq的資料.

  • Android中兩個Apk Share相同的UID必須其簽名所用的Private Key 一樣.(為什麼?)
    google的解決方法就是,如果多個應用之間真的要設定成Share UID相同,那麼前提條件就是這幾個應用的私鑰也必須是一樣的,是同一個owner ,也就是說廠家是同一家.

身份ID和升級的匹配

• Android中的自簽名只是代表了身份,但是不代表身份是否可信任
• Android應用的identifier(鑑定者) 是Package Name:
  
  • Package Name不一樣,相互不影響,只允許同時存在(安裝)
  • Package Name一樣,只能存在一個,允許做升級處理.
• 升級的安全性考慮
  
  • 必須簽名的證書一致(市場上假冒app)
  • 如果不一致,則使用者要麼放棄新的應用,要麼先解除安裝舊的,再安裝新的.
  • 正常的升級將不清除應用cache,以保證歷史資料的持續性.

Android APK 之META INF

其實很應用的安裝包,就是一個壓縮包,把apk 字尾修改成.zip 就可以解壓裡面的資料.

• APK的一個結構

  • assets
  • lib
  • META-INF 裡面有3個檔案,相當於是摘要資訊檔案(簽名信息CERT.RSA，CERT.SF，MANIFEST.MF)
  • res
  • AndroidManifest
  • class.ex

• 簽名流程
  java -jar signapk.jar testkey.x509.pem testkey.pk8 update.apk update-signed.apk

Android中的許可權

Android簽名中使用到的一些加密技術有:
簽名(特權許可權)

許可權作用

細粒度特權管理

• 許可權與操作關聯
  每一個許可權都與對應的操作(功能)有關聯.

• 應用需要顯式申請許可權
  如需要在AndroidManifest中去申請需要的許可權.

• 使用者對許可權可知(不可控)
  使用者對該專案使用到的app需要涉及什麼許可權,都是可以檢視到的,但是在安裝app時必須accept所有許可權才可以安裝,否則就無法安裝,這就是不可控,但是在Android6.0後google出現了RuntimePermission,對部分單個許可權是可控的,而且當系統root後,也可以通過一些管家對某個app 的單個許可權進行分配.

• 對特權許可權單獨控制
  Android中對特權許可權單獨控制,這個方式其實就是通過簽名來處理的.比如上面提到的sendSMS 傳送簡訊的許可權.

Android的不同許可權類別

• Normal 預設,一般安裝不會被顯示出來.
• Dangerous 危險,安裝時會有pop提示.
• Signature 簽名,對於一些特權許可權就需要通過簽名來保護,對apk的私鑰邀請與簽名一樣.
• SignatureOrSystem 簽名or系統,對於申請許可權的私鑰跟簽名一樣,或者改app是系統app才可以使用該許可權.
• 自定義許可權注意
  一般一些開發廠商或應用開發商會自定義一些許可權.

注意:
對於自定義許可權很簡單,但是對於要設定他的protectionLevel這個問題還是比較關鍵的.如果level定義太嚴格,那以後拓展起來就比較差,如果定義太寬泛,就很容易出現安全漏洞.建議根據如下方式定義:

• 根據需求應用範圍使用者許可權,按照上面的許可權類別描述來定義需要的許可權.
• 為了避免permission name 重複,命名規範也要注意.
• 如,百度地圖在自定義許可權時,該sdk提供一些api但是如果這些功能只給百度自己公司的app 用,那就可以定義protectionLevel=”SignatureOrSystem”.

Android執行時許可權控制方式

下面是兩種方式的描述

通過PM的CheckPermission

• Android獨有的service(底層平臺不具有)
• 所以需要在Android本身framework中控制
• 主流的service一般都基於binder IPC或者其他IPC提供服務
• Android真正的service都是在底層實現的,所以在最底層控制(service所在的server中)以避免逃逸控制
  
  • 繞開Utility Function 直接 Invoke Remote Service
  • 如:DayDream(屏保)

對映為OS的特定屬性

• 非Android特有的service(底層平臺已經提供,如File訪問,TCPIP資料收發等)
• 多個入口訪問: Android API,Java API, NDK C API, Shell,etc
• 底層控制準則,會聚扣在底層,所以在底層(OS層面)統一控制,這樣可以避免逃逸控制.
• 所以複用OS的一些安全控制特性,比如GID
• 所以需要把Android空間的 Permission Mapping到OS的GID
• 如: 訪問SDCard

因為Android是基於Linux OS的那麼Linux它有的一些安全特性與GID ,Android就可以對他複用,因此在對於多介面的訪問安全問題就可以解決了,可以先看下面程式碼:

讀取SDCard的許可權

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

SDCard許可權的對映關係

<permission name="android.permission.WRITE_EXTERNAL_STORAGE"
    <group gid="sdcard_rw"
/>

Android的permission 與UID/GID 的mapping

• 任何自定義許可權只要符合上面xml 語法的都會在system/etc/permissions 下面的xml檔案,被系統讀取並parse 在UID/GID中進行mapping. 如見system/etc/permissions 目錄下的platform.xml .
• 安全性問題
  
  • 任何應用都可以為自己的permission 分配GID嗎?那不是安全漏洞?
  • 當然不行! 只有ROOT使用者才允許新增或改寫.