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来运行。

Enhanced Security Solution in Android