Android安全三、移动平台安全机制

2020-10-17 本文已影响0人 flynnny

一、签名和授权

1、移动平台中的主流签名作用:自签名的完整性鉴别

自签名：证书的签名者和证书拥有者是同一实体。
自签名作用1：作为信任链的根证书。

1.png

自签名作用2：完整性鉴别。

2、移动平台中的主流签名作用:信任模式

不是自签名证书，采用信任模式。
可信任：由不同runtime平台决定app是否可信任。
如何鉴别可信任：通过签名，签名回溯（过期、颁发者位于系统可信任列表里）。
权利差异：把特权操作给与可信任应用。比如发短信。

3、移动平台中的主流签名作用:限制安装/运行

应用安装时：
是否包含签名？---》没有，矜持安装。
提取证书进行验证---》证书是有效且可信任的吗？----》不是，禁止安装。
基于证书的公钥对签名进行验证---》签名正确吗？---》不正确，禁止安装。

应用运行时：
是否包含签名？---》没有，禁止运行。
提取证书进行验证---》证书是有效且可信任的吗？----》不是，禁止运行。
基于证书的公钥对签名进行验证---》签名正确吗？---》不正确，禁止运行。

4、权限的作用：细粒度的特权管理

权限是一个ID或者一个字符串。
权限用来细分权利（雷瑟Capability）。
通常一个权限与一个操作绑定。
权限首先要申请。
申请后是否批准由平台策略决定。
比如：读写SDCard、Reset手机

5、权限的安全性保护：通过签名

权限的完整性保护：防篡改
例子（通过认证并获得签名后再加policy权限）

权限的授权安全策略：防Escalate
例子（普通应用申请Inject Event权限）需要手机厂家额私钥来签名才有某些特殊权限

二、Android中的签名

1、Android的签名作用：完整性鉴别

支持自签名用于完整性鉴别（无法验证APK是否是可信任的）
不做信任模式
不做安装和运行时的限制

2、Android的签名作用：Signature Permission和ShareUID

Signature Permission Level Permission
用于特权Permission
只有特定签名的Apk才被授权

2.png

Share Process UID
android：shareUserID="xxx（随便起）"
Process间Share UID的目的是共享资源等
Android 中两个Apk Share相同的UID必须其签名所用的Private Key一样。

3、Android的签名作用：身份ID 和升级的匹配

安卓中的自签名只是代表了身份，但不代表身份是否可信任。

Android的应用的Identifier是Package Name：
PAckage Name 不一样，相互不影响，允许同时存在（安装）；
Package Name一样，只能存在一个，允许做升级处理。

升级的安全性考虑：
必须签名的证书一致（防假冒。防侵入隐私）；
如果不一致，则哦用户要么放弃新的应用，要么卸载旧的，再安装新的，但这属于安装，不属于升级；
正常的升级将不擦除应用的工作目录数据，以保证历史数据的持续性。

4、Android APK 之META INF

APK 结构：

3.png

META INF组成：

4.png

签名流程：
java -jar signapk.jar testkey.x509.pem testkey.pk8 update.apk update-signed.apk

MANIFEST.MF

5.png

CERT.SF
对MANIFEST.MF加密

6.png

CERT.RSA

7.png

包含证书信息以及基于私钥的签名信息（CERT.SF）

三、Android中的权限一

1、Android的签名作用：细粒度特权管理

应用需要显示申请权限
用户对权限可知（不可控）
对特权权限单独控制

2、Android的不同权限类别

Normal（默认）、Dangerous（有提醒）、Signature（自己用）、SignatureOrSystem（系统也可以用）

3、Android的权限定义方式

定义在AndroidManifest.xml中：

8.png

4、Android的平台权限定义

在 frameworks/base/core/res/AndroidManifest.xml

9.png

四、Android中的权限二

1、Android 的运行时权限控制方式：通过PM的CheckPermission

Android独有的Service（底层平台Linux不具有）。所以需要在Android本身Framework中控制。
主流的Servide一般都基于Binder IPC或者其他IPC提供服务。
所以在最底层控制（Service所在的Service中）以避免逃逸控制。（绕开Utility Function 直接Invoke Remote Servide）

2、Android 的运行时权限控制方式：映射为OS的特定属性

非Androi特有的Service（底层平台已经提供，如FIle访问，TCPIP数据收发等）有多个访问入口访问：Android API ，JAVA API，NDK C API，Shell，etc。
底层控制准则，汇聚口在底层，所以在底层（OS层面）同一控制。这样可以避免逃逸控制。
所以复用OS的一些安全控制特性，比如GID。
所以需要把Android空间的Permission Mapping到OS的GID。

例子访问SDCard（把权限mapping到os）

10.png

3、Android的permission与UID/GID的mapping

11.png

12.png

五、Android中的组件安全机制

1、Android的4大组件及组件间的通信

Android是基于组件的复用，组件间的边界透明。
组件间基于Intent通信。

2、组件的Public和Private

概念：public 系统里的其他组件都能和我通信；Private对完不可见，只能被当前组件所在的同一个进程访问，或者被Share同一个UID的访问。
由andorid：exported字段控制Public和Private。
Exported的default值：如果没有定义intent-filter则为false。即private。
Override default值：如果定义了intent-filter，也想exported=false也是可以的（相反也是同理可以的）

3、组件的Permission Assignment（组件间也不是随便就能通信的）

Securing Activities:(比如不想让别人启动activity，就定义一个permission）

13.png

必须有START_ACTIVITY1 Permission才能启动。

Securing Service（start or bind）（同理）:

14.png

只能控制start or bind

Securing ContentProvider:

15.png

Securing BroadcastReceiver:

16.png

六、android 中的应用安装（跟安全有关的）

1、应用安装的安全性考虑和调用方式

应用安装是一个高特权/风险操作，所以必须可知/可控。
主流实现方式：客户只能委派而不能直接操作。
调用安装传统模式：返送Intent给系统的Package Install app。
特权安装模式：系统的Package Install App内部会调用PackageManagerService的Install Package,该操作与android.permission.INSTALL_PACKAGES绑定，且该permission的protection level是signature|system

所谓的静默安装方式只存在ROOT手机上，开发者可以选择：基于pm cmd:pm install -r