平台安全（Platform Security） 第一部分

平台安全 本讲介绍 信任模型 能力模型 数据保护 安全标识符，商家标识符和唯一标识符

平台安全 平台安全 运行在软件层面上的安全模型 这些操作可能 经常写作 “PlatSec” 由Symbian OS v9.0 引入 是保护手机数据安全和完整性的基础 运行在软件层面上的安全模型 检测和阻止应用程序对硬件、软件、系统或用户数据进行非授权的访问 这些操作可能 锁住电话 危机用户的机密文件 相反的影响其他软件或电话网络

平台安全 平台安全阻止运行在Symbian OS上的软件采取不可接受的动作 这是一个系统范围的概念 有意或者无意的 无论他是编写应用程序、中间件还是设备驱动

安全模型 理解“进程是信任单元”这一格言的含义，以及Symbian OS是如何执行这一格言 的 理解可信计算基础（Trusted Computing Base ）的目标以及为什么重要的原因 了解许多OS APIs 在被使用之前不需要进行安全检查 知道不使用敏感的系统服务的自签名软件是“不可信的”，但可以安装手机上并进 行运行，不过它是被有效得包在”沙箱“中（effectively “sandboxed”）

进程是信任的单元 平台安全中一个最进本的概念是 进程可以 信任单元的定义 Symbian OS 定义进程作为最小的信任单元 进程 (绝大多数情况下即, 应用程序或服务器) 代表用户运行在手机上 进程可以 由生产商构建到手机中 也可以在手机离开工厂以后安装到手机上

进程是信任的单元 平台安全控制一个进程能做什么 没有合适的权利 将它的活动限制在适当的权限中 操作系统不会满足一个服务请求，如果进程不能提供需要的权限 没有合适的权利 进程被认为是不足以信任的

进程是信任的单元 进程被认为是最小的信任单元 手机硬件引发一个处理器错误 Symbian OS 相信 如果对进程进行访问的地址没有在该进程的虚拟地址空间中 Symbian OS 相信 一个进程不能直接访问其他的虚拟地址空间 硬件会阻止这种事情发生!

进程是信任的单元 硬件辅助保护 提供了软件安全模型的基础 内核中转IPC 通过进程间安全的共享数据

进程是信任的单元 对运行在Symbina OS中的进程上，应用有四个对应的信任层 它们是: 范围从安全的可信到安全不可信 可信计算基础（The Trusted Computing Base ,TCB) 可信计算环境（The Trusted Computing Environment ，TCE) 其他信任（签名软件）（Other trusted (signed) software） 平台其他（未签名，因此也不可信）

可信计算基础 (TCB) TCB Symbian OS中最可信任的部分 TCB中的代码 它控制低级的安全机制 它有责任维护系统的完整性

可信计算基础(TCB) 为了能够进行TCB可信性的验证 Symbian OS TCB 已经被仔细的检查过 TCB 被保持得尽可能的小和简单 例如通过逐行的代码审查 以确保其中的代码能够正确运转, 能被认为是可信的

可信计算基础(TCB) TCB 包含了操作系统的内核，后者负责照看每个进程的细节 文件服务器也是TCB的一部分 包括赋予进程的权限集合 因为它被用于将程序代码加载到进程中 代码的权限信息在内核加载进程时建立

可信计算基础(TCB) 对于“封闭的（closed）”的Symbian OS 手机 TCB 包括 它们是不支持本地扩展（add-on）软件安装的 TCB 包括 内核 内核一侧设备驱动器 文件服务器

可信计算基础(TCB) 绝大多数Symbian OS 手机是“开放的（open）” SWInstall 具有重要的角色 因此软件安装器 (SWInstaller) 也构成了TCB的一部分 当安全SIS包中的文件时，安装器T运行 它从安装包中提取文件，包括程序二进制代码 SWInstall 具有重要的角色 将程序二进制要求的权限与安装包的数字签名进行确认

可信计算基础(TCB) 严格的说 绝大多数用户库不包含在TCB中 内存管理单元（MMU）和其他安全相关硬件都是TCB的一部分 它们不会在这里讨论，因为Symbian不提供手机硬件 绝大多数用户库不包含在TCB中 只有需要被文件服务器或者软件安装器使用的极少数属于... ...例如，密码系统库在信任的最高等级

可信计算环境 (TCE) TCE 包括移动电话中的可信软件 TCE 代码被断定为可信的 由Symbian提供的 或者由其他供应商提供的 例如UI平台提供商以及手机生产商 TCE 代码被断定为可信的 但是它不是需要最高权限才能运行 并被赋予较少的特权 因此比运行在TCB中的代码可信度弱一些

可信计算环境(TCE) 在TCE中 通过这样限制服务集合 每个组件只拥有执行明确定义的一组服务所需要的权限 Symbian OS 限制了有服务器代码缺陷所带来的威胁 或者可能的威胁，如由代码破坏引发的危险

可信计算环境(TCE) TCE 代码通常实现 通过要求选定的服务器具有特定的权限 服务器进程中的系统服务 可能对所有服务器限制访问敏感的低层操作 以及防止其他进程的误操作

可信计算环境(TCE) 例如: 考虑TCE的两个组件 窗口服务器(WServ) 电话服务器 (ETEL) 窗口服务器（window server）和电话服务器（telephony server） 窗口服务器(WServ) 被授权访问屏幕硬件 但是不需要访问手机网络 电话服务器 (ETEL) 被授权访问通信设备驱动器 但需要访问屏幕硬件

可信计算环境(TCE) TCE中的服务器提供 例如 对底层服务的间接访问，通过为TCE外的软件提供 它不需要直接和硬件通信 相反，它使用每个服务器提供的API来执行应用程序的操作

可信计算环境(TCE) Symbian OS 服务器 每个服务器都有责任节制（moderate）和保护它所拥有的底层资源的使用 构成了平台安全架构的基础 每个服务器都有责任节制（moderate）和保护它所拥有的底层资源的使用 同时，也为运行在可信度减低的进程中的客户端中转对资源的访问

签名软件（Signed Software） 对一个“开放”的Symbian OS手机安装软件是可能的 绝大多数额外的软件都是位于TCE之外的 但是仍然需要特定的权限来使用TCE提供的服务

签名软件 例如 套接字服务器 (ESOCK) 一个应用程序 需要访问网络服务的软件必须打开一个网络套接字 是TCE的一部分 它处理网络接口的底层操作 一个应用程序 它希望打开网络套接字 请求套接字服务器代表它去这样做

签名软件 套接字服务器 它不会赋予所有希望访问网络套接的代码的访问权限 这一点是非常重要的，任何请求一个服务的应用程序 将首先检查请求是来自一个已经被赋予适当信任等级的程序 它不会赋予所有希望访问网络套接的代码的访问权限 恶意代码可能会供给网路或者其他设备 这一点是非常重要的，任何请求一个服务的应用程序 在请求允许之前被认为是值得信任的 这种信任的一个度量就是软件已经被数字签名了

签名软件 当一个外部作者在决定是否签名一个应用程序 ...该应用程序 这构成了Symbian签名的基础 以允许它执行电话上的某些操作，如打开网络套接字... ...该应用程序 没有项TCB和TCE中的代码那样经过严格的评估 源代码本身通常没有被逐行检查，虽然代码的功能被测试过 开发者的信任状 (身份)也将被检查 这构成了Symbian签名的基础 它在Symbian签名门户网站www.symbiansigned.com上公布了Symbian签名要 求的测试

不可信软件（Untrusted Software） 软件的可信性不能确定 如果它没有被签名或者是”自签名(self-signed” ) 自签名即虽然被签名了，但是不是Symbian信任权威（ Symbian Trusted Authorities ）签署的 这意味着 它必须被Symbian OS认为是不可信任的 但是这并不意味着软件是恶意的或者无价值的 有许多有用的操作 它不需要调用系统服务就能在手机上执行 调用系统服务器就意味着需要一定等级的权限

不可信软件 Symbian OS 这些检查 例如 不可信软件可以安装 只在需要时进行必要的安全检查 大约包含了所有Symbian OS API中的40% 例如 一个单人纸牌游戏不执行任何操作，它们需要访问 敏感的用户数据或者系统关键的数据或服务 不可信软件可以安装 和运行在手机上 但是它是沙箱中的（“sandboxed” ） 它不能执行任何需要安全权限的动作

不可信软件 绝大多数手机生产商要求一个应用程序在安装之前需要签名 TCB、TCE和Symbian OS平台其他部分之间的关系 在后续幻灯片中展示

信任的等级（Tiers of Trust） Kernel, F32, SWInstall WServ Messaging ETEL ESOCK MMF 可信计算基础: 具有修改文件系统的所有能力 包含内核、F32和开放手机上的SWInstall SWInstall是守门员 平台其他部分是不可信的.包含未签名系统软件和应用程序，它们在沙箱中 平台的这部分是较少信任的. 包含其他签名系统软件和应用程序 可信计算环境: 以不同权限运行的大量系统服务器

信任的等级 上图 内核可能通常被认为占据该位置 其次，文件服务器 —— 像其他服务器 软件安装组件 故意没有将TCB显示在环的中心 它们的一些服务对所有进程都是可用的 其次，文件服务器 —— 像其他服务器 既是内核的客户端，也是对所有进程可用的 软件安装组件 被显示成伸展到了周场外 因为它扮演了手机守门员的角色

能力模型（Capabilities Model） 理解能力和TCB的关系 理解用户能力的概念以及它们与TCE的关系 理解TCB/TCE、能力分配、软件安装器（作为守门员）以及应用程序签名的角色之 间的关系 认识能力的不同分组，并能够更广泛的理解被赋予的权限 了解如何在MMP文件中指定平台安全能力 理解能力规则

能力模型 进程是Symbian OS上的信任单元 权限有一个能力（capability）指派 拥有一个能力说明 每个进程被分配一个等级的权限，以指示它能够执行什么安全敏感的操作 权限有一个能力（capability）指派 能力是一个符号，它赋予持有者访问系统服务或资源的权限 拥有一个能力说明 进程被信任不用滥用权限关联的服务或者资源

能力模型 Symbian OS 平台安全 内核 一个进程 的构建是利用能力来表现访问的权限 定义而许多能力，它们分别分配了特定的权限 拥有一个针对每个运行进程的能力列表 一个进程 可以让内核检检查另一个进程的能力，在决定是否代表它执行一个服务之前

能力模型 对于可安装软件 软件安装器扮演了守门员的角色 它验证程序已经被授权使用它构建时所带有能力 拒绝安装没有正确授权的软件 数字签名 (或者 – 对一些能力 – 用户的许可)

能力模型 能力是离散和正交的 相反 这意味着它们没有覆盖 它们不是访问令牌的层次化集合 每个增加一些权限，直到达到TCB的等级 一个特定的受保护资源能被单个能力控制 任何要访问该资源的进程 包括TCB中的进程 必须具有权限才能成功访问 进程不需要具有其他能力

能力模型 不同操作 例如 有三个宽泛的能力类别: 可能要求不同能力 即使那些操作用相同的API实现 访问文件要求不同的能力 这取决于它在文件系统中的位置 有三个宽泛的能力类别: TCB 能力 System 能力 User 能力

用户能力 用户能力 这些能力关系到一些安全概念 例如 是一小组对手机用户意义深远的能力 用户能力理解它们，并对其做出选择 一个用户可以是否安装软件 该软件有能力拨打电话（这将花费用户的钱） 或者能够访问用户的个人数据

用户能力 一个用户不应 对影响到手机正常工作的能力进行决定 例如影响系统服务的能力 系统一级的能力是个单独集合

用户能力 可用的用户能力总结如下表所示: 用户能力 授予的权限 LocalServices 通过短连接(“short-link” ,例如蓝牙，USB或红外)访问系统服务. 这样的服务通常不会引起用户的费用 Location 访问手机的位置数据 NetworkServices 访问远程设备 (例如通过OTA空中下载数据服务或者WiFi网络访问). 这些服务不会引起用户的费用 ReadUserData 读访问用户的私人数据 UserEnvironment 访问用户和他们所在环境的活动数据 WriteUserData 写访问用户私人数据

用户能力 用户能力 典型的赋予那些软件 它们使用有TCE提供的服务 TCE服务 检查和执行用户能力 并执行被请求的服务

用户能力 平台安全被设计成Platform security is designed 该模型允许 可安装软件（它只需要用户可授权能力） 不需要被一个可信任权威签名 该模型允许 用户为软件授予权限 当它被安装时 或者当它运行需要执行某个动作时 该动作需要一个特定的能力

用户能力 虽然用户能力 被设计成用户可理解的 但是它提供很多选择可能并不总是合适的 这决定于手机当前使用的环境 移动手机生产商会判断 用户能力是如何在他们的手机上配置的 即——他们是真正的用户可授权

系统能力 最大一组的能力 授予一个系统能力 系统能力 需要系统能力的可安装软件 是系统能力 允许进程访问敏感的操作 系统能力的误用将威胁手机的完整性 系统能力 对于用户并不是特别有意义 而是被设计成对用户隐藏 需要系统能力的可安装软件 在赋予它们能力之前，需要提交 到测试和认证机构（例如Symbina Signed）

系统能力 下表总结了可用的系统能力: 系统能力 赋予的权限 AllFiles 读访问整个的文件系统，写访问其他进程的私有目录 CommDD 直接访问所有的通信设备驱动器 DiskAdmin 访问文件系统管理操作，它会影响多个文件或目录（或者整个文件系统的完整性，行为等） Drm 访问DRM保护的内容 MultimediaDD 访问关键的多媒体功能，例如直接访问关联的设备驱动器以及优先访问多媒体API NetworkControl 修改或访问网络协议控制的能力

系统能力 系统能力 赋予的权限 PowerMgmt 杀死任何进程、关闭不使用的外设、使手机进入待机状态、唤醒以及完全关机的能力 ProtServ 允许服务器进程以一个受保护名字注册的能力 ReadDeviceData 读访问秘密的网络运营商和手机生产商信息以及设备设置 SurroundingsDD 访问逻辑设备驱动器，它提供手机周围环境的输入信息 SwEvent 迷你按键输入以及从任意程序捕捉这类事件的能力 TrustedUI 创建一个可信UI会话从而能力在安全的UI环境显示对话框的能力 WriteDeviceData 写访问能够控制设备行为的设置

Tcb 能力 Tcb 能力 可信计算基础 只能由TCB的成员拥有 内核The kernel 设备驱动程序 文件系统 软件安装器——在开放的Symbian OS手机上

Tcb 能力 TCB以最大的权限运行 有一种能力 任何TCB中运行的代码都会被赋予 所有的系统和用户能力 因为有些事情只有TCB代码能做 例如加载程序代码Such as loading program code 有一种能力 只赋予TCB 最关键的能力是Tcb

分配能力 当构建可执行代码时 所以能力 为了Symbian OS的平台安全 需要在它的MMP文件中为其赋予一定的能力 使用关键字CAPABILITY 所以能力 被Symbian工具链构建到了EXE或DLL中

分配能力 能力可以在一个包含列表中指定 作为替换 指定CAPABILITY Tcb 指定 CAPABILITY All 例如: 一大组的能力也可以用排除列表指定 指定CAPABILITY Tcb 并不等同于拥有所有能力 指定 CAPABILITY All 并不意味着拥有Tcb 能力 像拥有其他能力一样 CAPABILITY ReadUserData WriteUserData SwEvent CAPABILITY All -Tcb -Drm -DiskAdmin

分配能力 一旦代码以适当的能力构建 是手机生产商 它要么被包含在手机的ROM中 由手机生产商 或者后来安装到手机上 以及为代码分配适当的信任等级 Symbian进行了必要的安全审查 对它所发布的OS二进制代码

分配能力 需要系统能力的可安装二进制代码 只需要用户授予能力的可安装二进制代码 必须由以可信任的权威进行测试和验证 例如Symbian Signed 软件安装“守门员”只允许经过了测试和验证的软件被安装 如果它们附有适当的数字签名 只需要用户授予能力的可安装二进制代码 或者不需要能力的代码 理论上不需要数字签名 因为它们是在沙箱中运行的

分配能力 但是 绝大多数的手持设备生产商配置Symbian OS的平台安全 以要求二进制代码在安装前被签名 只要自签名来识别软件供应商

分配能力 在二进制被构建到ROM 中后 对于一个EXE 对于一个DLL 或者安装到手机上后 Symbian OS 会假定它已经符合的标准 从而认为它所分配的能力是可能的 对于一个EXE 这意味着进程将有权执行一定的特权操作 对于一个DLL 这说明了它被信任的程度 以及它被加载进的进程的可信度

能力规则 1 一个进程的能力在其生命期不会改变

能力规则 1 在运行时 如果一个进程由另一个进程产生 作为TCB一部分的加载器 从文件系统中读入可执行代码创建一个新的进程 并确定需要的能力集合 一旦这个完成，进程的能力就不能更改了 如果一个进程由另一个进程产生 它是独立运行 它没有能力创建一个进程 但是具有在构建它是MMP里指定的能力

一个进程只能加载这样的DLL，它能被信任的 能力至少与该进程一样的能力 能力规则 2 一个进程只能加载这样的DLL，它能被信任的 能力至少与该进程一样的能力

能力规则2 当一个进程加载一个DLL时 正如规则1所说 一个进程能加载一个DLL 这不会扩大或者缩小进程的能力集合 进程的能力在其生命期是不会改变的 一个进程能加载一个DLL 该DLL已经被赋予比进程自身更多的能力 进程不会被更新到那个更可信的集合 而该DLL会降级到进程的能力集合

能力规则 2 一个DLL可以被加载进一个进程 如果一个DLL要求 该进程拥有的权限比DLL构建时的权限更少 所以DLL中的代码不能假设 它将以赋予它的能力运行 如果一个DLL要求 一个特定的能力以满足其目的 这应该在库文档中清楚的指明

能力规则2 一个进程会加载一个DLL失败 如果DLL没有这些能力 一个可信的进程应当不能加载不可信的DLL 这可以阻止不可信的代码被加载到敏感的进程中 一个可信的进程应当不能加载不可信的DLL 例如——一个DLL可能耗尽所有可用的栈或堆 恶意的或者仅仅由于糟糕的编码 从而妨碍了该进程的功能实现

能力规则2 DLL加载器 演示如下 为所有进程提供了这种安全机制 消除了它们识别哪些DLL能够安全加载的负担 其中二进制代码的能力用“Cn”表示

直接加载 DLLs exe C1,C2 dll C1,C2,C3 a exe C1,C2 dll C1 x

能力规则 2 本规则 绝大多使用DLL的数程序 静态链接解析引用Static linking resolves references 会使用静态链接 动态加载主要用于插件框架 静态链接解析引用Static linking resolves references 到链接的DLL中的符号，是在构建时 这样它们在运行时的加载效率更高

能力规则 2 关于能力一个有趣的情况是 考虑下面的图示 当一个DLL静态链接到另一个DLL时 原始的DLL被加载进程中 第二个DLL也被加载

DLLs静态链接 exe ? dll1 C1,C2,C3 dll2 C1 load static link

能力规则 2 DLL1 不能被加载到进程中 事实上 典型的，进程会重用已经加载的DLL 该进程拥有能力C2或者C3 因为DLL1 (C1,C2,C3) 链接到了DLL2 (C1 only) 而DLL2 是没有可信性 足以加载到有C2或C3的环境中的 事实上 不必为DLL1申明C2或C3 因为它永远不会被用到！ 典型的，进程会重用已经加载的DLL 因此这引发了对规则2的优化，如下： ...

加载器只加载静态链接到第二个DLL的DLL，如果第二个DLL以至少与第一个DLL相同 的能力被信任 能力规则 2 加载器只加载静态链接到第二个DLL的DLL，如果第二个DLL以至少与第一个DLL相同 的能力被信任

x a x 间接加载DLLs 例 2 例 3 exe dll2 dll1 C1,C2 C1 C1,C2,C3 例 1 动态 加载 exe 静态 链接 x

Data Caging（数据隔离） 理解data caging是如何工作以保护三个特殊目录(\sys,\resource 和 \private); 下所有类型文件的；特别的，data caging是用于分割文件系统中所有可执行文件，这 样，一旦被信任它们就被保护起来免于修改 理解data caging对于命名可执行代码的影响 认识data caging可用于为应用程序数据提供安全的保存区域 认识到读或者写特定目录或子目录所需要的能力 知道DLL没有私有的隔离的数据（data caged）的区域，而是使用加载它们的进程的 区域，并且这个目录可以被DLL获知，通过调用文件系统方法RFs::PrivatePath()

数据隔离 重要文件的安全性 隔离（caging） 涉及所有的文件类型refers to all types of files 由Symbian OS通过被称为data caging的文件访问控制方法来保护的 隔离（caging） 涉及所有的文件类型refers to all types of files 无论它们的内容是代码还是数据 可能它应该被称为文件锁定（“file caging”）

数据隔离 许多系统文件 系统和用户文件都 对于手机正确的功能和完整性是关键性的 其他的对于用户则是个人的，应该保持秘密 能被data caging保护 它将文件分割到文件系统的安全区域 以防止破坏和不受欢迎的访问

数据隔离 Data caging 不用于保护所有文件 私有区域位于特定的顶层路径上: 这些目录是访问限制的 文件系统存在一些公共区域 其他的则将特定的文件锁定在私有区域里 私有区域位于特定的顶层路径上: \sys \resource \private 这些目录是访问限制的 其子目录也是

数据隔离 当访问其他所有保持公开的路径时 TCB 进程 对其他进程 不需要任何能力来实现读出或写入 对所有的目录具有完全的读写权限 用以读写特定目录的能力 总结如下...

读写需要的能力 所有磁盘的目录及其子目录(z:, c:, 等) 读需要的能力 写需要的能力 \sys AllFiles Tcb \resource 不需要 \private\<ownSID> \private\<otherSID> \other (e.g. c:\games or just c:\)

数据隔离 AllFiles 能力 Tcb 能力 允许读访问整个文件系统 写访问\private的所有子目录 扩展到允许写访问\sys 和 \resource 包括其子目录

数据隔离 文件的访问控制 无论 不需要有访问控制列表（ACLs) 为了限制一个文件的访问.. 有包含的目录所在的位置决定 那个磁盘 以及尝试访问它的进程有什么能力 不需要有访问控制列表（ACLs) 用以每个文件来确定哪个进程可以访问它 为了限制一个文件的访问.. 只要简单的将其移动到受保护的目录

锁定的文件路径: \sys 目录 \sys\bin 构建在移动手机ROM中的可执行程序 安装的软件被写入 是保存所有程序二进制（可行性）代码的地方 构建在移动手机ROM中的可执行程序 从z:\sys\bin运行 安装的软件被写入 C:盘的\sys\bin 目录 或者可移动介质上的对应目录

锁定的文件路径 : \sys 由于二进制程序被安装在可移动介质上 它们潜在的可以从手机的卡上删除 为了检查可执行程序是否被篡改To check for tampering of executables c:\sys\hash 被用于存储二进制代码的安全散列值. 只有TCB中的代码 具有读写\sys 目录及其子目录的权限 具有AllFiles 能力的代码 可以读访问 \sys 这确保了只有可信的代码能够访问可执行程序

锁定的文件路径 : \sys 存储在手机其他地方的二进制代码 一个要求所有的执行程序代码安装在\sys\bin 的后 果 开发者必须确保 是不可执行的 以防止恶意软件的安装 一个要求所有的执行程序代码安装在\sys\bin 的后 果 是潜在的名字冲突 开发者必须确保 他们的二进制程序被赋予唯一的名称 典型的，通过包含SID 或 UID3 它们对于二进制代码是唯一的

锁定的文件路径 : \resource \resource 目录 例如 只有TCB 能写入这个目录 \resource 目录中的文件是 是用于严格自渎的资源文件的 例如 位图，字体，和帮助文件 只有TCB 能写入这个目录 以确保资源数据不会被破坏 从这个目录读数据不需要能力 \resource 目录中的文件是 要么构建到手机的ROM中 要么是后来被软件安装器安装到可写介质上

锁定的文件路径 : \private 每个进程 该子目录 有它们自己锁定的文件系统区域，作为每个磁盘\private下的一个子目录 有EXE的SID标识 只有符合SID或者具有AllFiles 能力的进程 才对该目录具有全部的读写权限

锁定的文件路径 : \private 一个DLL Symbian OS 文件服务器访问类 没有自己的私有目录 它使用加载它的进程的目录 提供了一个方法以发现私有路径的名称 即 RFs::PrivatePath()

注意 一个.pkg安装文件 可被用于指定数据Can be used by other parties to specify data 它们将被放置其他应用程序的\private\<SID>\import子目录下 但是 ... 只有import子目录已经在磁盘上存在时才行

安全标识符, 厂商标识符，及唯一标识符 解释什么是安全标识符(Secure Identifier ,SID), 它是哪里定义的以及它的用处 是什么 理解SID，VID（厂商标识符）和二进制文件唯一性标识符(UID)之间的异同 知道根据SID，VID和UID来标识一个应用程序的规则 知道SID和VID可以分配给DLL，但是没有特别的关系 了解如何在MMP文件中指定VID和SID 了解UIDs现在被分为两组（保护的和非保护的），它们的区别是分别用于商用代 码和测试代码

安全标识符, 厂商标识符及唯一标识符 与每个可执行二进制文件关联的标识符有很多: SID（安全标识符） VID （厂商标识符） 以及一些UIDs 它们都是32位数

唯一标识符（Unique Identifier ,UID) UIDs可用于 当二进制文件在Symbian OS上执行时，对其进行唯一性标识 对任意一个可执行程序，都有三个UIDs 它们被构建到所有的Symbian OS文件的前12个字节中，以对其进行标识

唯一标识符(UID) 第一个UID (UID1) 第二个 (UID2) 第三个UID (UID3) 有Symbian OS构建工具自动产生 根据MMP文件中声明的目录类型 targettype 例如DLL 或 EXE 第二个 (UID2) 对特定的目标类型进行指定，进一步对其进行细分 例如，对于DLL，有不同的UID2的值 针对多态接口DLL的UID2值和针对共享库DLL的UID2值 第三个UID (UID3) 用于唯一性的标识二进制文件 所有的商用代码将有Symbian负责分配UID

安全标识符(SID) 需要SID SID与UID3有些相似 典型的 对手机上每个EXE都是存在的和唯一的 用以标识进程可以访问的私有目录 以及在进行进程间调用时唯一性的标识应用程序 SID与UID3有些相似 SID的缺省值就是UID3 SID 可以用MMP文件中SECUREID关键字予以指定. 典型的 推荐不指定SID 简单的让它等于UID3的值

安全标识符(SID) 为了保持SID是全球唯一 可能的32位值已经被分成两个范围: Symbian 通过一个中心数据库管理UID3的分配 该中心数据库由Symbian 签名权威（Signed authority）管理 可能的32位值已经被分成两个范围: 受保护范围 0x00000000–0x7FFFFFFF 和非保护范围 0x80000000–0xFFFFFFFF

安全标识符(SID) 当一个二进制文件拥有保护范围内的SID时 认证权威 软件安装器只是允许它安装 如果它已经被一个认证程序予以签名 例如Symbian Signed 认证权威 检查提交签名的二进制程序的UIDs 是否真的属于代码的作者 以及该作者之前没有提交了另一个使用同样值的程序

安全标识符(SID) 很重要的是 检查SIDs的唯一性 组织有意或无意的重复使用另一个应用程序的SID 也能防止一个软件作者愚弄其他人的程序（spoofing the binaries of another）

安全标识符(SID) 一些未受保护的ID 范围 测试范围的UID可以安全的用于测试 测试范围的UID不应使用 不会进行唯一性控制 可以用于未签名应用程序以及测试代码 测试范围的UID可以安全的用于测试 因为它不是有Symbian Signed分配的 测试代码不会与合法应用程序冲突 测试范围的UID不应使用 当发布自签名的代码时 而是应该使用0xA0000000–0xAFFFFFFF 范围的UID

安全标识符(SID) 下表显示了UID的范围 UID Range Intended Use Status 带阴影部分由Symbian Signed根据请求进行分配 UID Range Intended Use Status 0x00000000 KNullUID 保护 0x00000001-0x0FFFFFFF 保留 0x10000000-0x1FFFFFFF 遗留分配范围, 不是V9的 0x20000000-0x2FFFFFFF UID3/SID 范围 0x30000000-0x6FFFFFFF

安全标识符(SID) UID Range Intended Use Status 0x70000000-0x7FFFFFFF Vendor IDs 保护 0x80000000-0x9FFFFFFF 保留 未保护 0xA0000000-0xAFFFFFFF UID3/SID 范围 0xB00000000-0xE0FFFFFF 0xE10000000-0xEFFFFFFF 开发及测试范围 0xF00000000-0xFFFFFFFF 遗留 UID 兼容范围

厂商标识符(VID) 厂商标识符 (VID) 其用意是The intention is that multiple executables 不需要对每个二进制文件都是唯一的 其用意是The intention is that multiple executables 统一来源的多个可执行程序应该共享一个VID 以标识它们来自某个软件开发商 例如 Nokia软件的VID是0x101FB657

厂商标识符(VID) 为了防止任何厂商To prevent any vendor DLL的VID VID可以在MMP文件中指定 使用VENDORID 关键字 如果没有指定，就假定是0 VIDs在应用程序构建完成之后是不能修改的

注意 SID 和 VID的值对DLL是无关的 因为它们运行在一个进程中 (EXE) 它们使用进程的SID和VID

平台安全 : 第一部分 信任模型 能力模型 数据锁定（Data Caging） 安全标识符、厂商标识符和唯一标识符

平台安全 第二部分

平台安全 本讲介绍 基于安全平台的应用程序设计 在Symbian OS v9上发布一个安全应用程序 本地的软件安装器

基于安全平台的应用程序设计 了解编写安全应用程序时的关键考虑，包括应用程序安全相关的部分、典型攻击、 反制措施以及安全应用程序设计和各种反制措施的代价

基于安全平台的应用程序设计 “一个安全的应用程序是用户可以信任它而不会失望. 相反,一个不安全 的应用程序要么是它的用户不信任的，或者会让信任它的用户失望.” [Heath 2006 Chapter 4]

基于安全平台的应用程序设计 编写安全的应用程序是需要着重考虑的 安全应用程序设计有两点需要坚持: 它提升了最终用户对产品的信任度 一个不安全的应用可以导致很差的销售业绩 并损坏开发者的信誉 安全应用程序设计有两点需要坚持: 分析潜在的威胁和它们的影响 分析和部署适当的反制措施

威胁分析 有几种类型的人 应用程序开发者 相似的Likewise 对应用程序的安全感兴趣 商业开发者对反盗版信息的安全保护干兴趣，例如注册信息 因为如果该信息被破坏的话，将产生重要的财务影响 相似的Likewise 知识产权必须被安全保护 尤其是如果从一个提供商获取授权的，而授权协议要求内容受到保护

专注于安全的人的种类 最终用户: 例如 用户的关心是很明显的 关心是否保持他们个人和敏感数据的私有性 通过确保数据不被破坏和删除，以保持数据的可访问 组织应用程序引发未经授权的财务支出 例如 不经过用户同意就发送消息或者拨打电话

专注于安全的人的种类 手机上其他内容的拥有者: 签名权威: 即使应用程序不会与它们的数据交互 没有应用程序能够访问另一个应用程序的私有数据 可信的认证权威，例如Symbian Signed 将要求应用程序证明是安全的 在签署应用程序是可信的之前

专注于安全的人的种类 应用程序零售商: 零售商将希望应用程序能够保护自己免于盗版 他们不希望卖那些会导致最终用户抱怨数据损坏的产品 网络运营商也希望避免发布会引起计费争议（因为未授权的电话或消息）的应用程序 或者其他会破坏电话网络的应用程序

安全设计考虑 必须考虑一下几个方面 确定哪些数据不被透露 确定哪些数据不被透露的 确定哪些数据需要保护以防止修改 当设计应用程序的安全性时 ... 确定哪些数据不被透露 到应用程序之外 例如——注册妈，DRM密钥等 确定哪些数据不被透露的 除了给用户或者其他可信软件 例如——用户联系信息或者游戏的美工 确定哪些数据需要保护以防止修改 例如标识银行的证书 用户可能会发送帐号和密码给银行

安全设计考虑 理解哪些正常行为 例如 可能被非正常使用 一个图像渲染器被信任用于输出DRM保护的内容 它应当不能与一个可以输出到文件的模块交互 因为这样的组合可能被用于获取未受保护数据的电子副本

潜在攻击 潜在的攻击可以分为一下几类： 尝试导致用户使用上的不便 要么通过阻止预期的行为或者引发意外的行为 例如，拨打昂贵的电话，或者让手机软件崩溃 尝试扫描手机以获取敏感的用户或应用程序数据 直接或间接使用一个应用程序来提升攻击者的能力的攻击

采取措施 已经进行了安全分析 绝大多数的措施 例如 一个开发者可以采取许多措施来保护应用程序免于攻击 应当在应用程序设计时考虑 应用程序应当典型的模块化 这样内部组件的交互就是可预测和可控的 例如通过限制每个模块的能力 将其限制到特定功能所需要的能力集合

采取措施 在设计阶段 有几种方法可用于分析需要的能力... 有必要确定一个应用程序可能需要哪些能力 因为对应用程序而言，可能需要一个可信权威的认证 例如Symbian Signed 有几种方法可用于分析需要的能力...

能力分析 应用程序执行的一般操作 例如 每个要使用的API被审查 应当被考虑，并联系Symbian OS的能力集合 这相对容易，因为能力的划分很粗 只有相对很少的能力可供选择 例如 一个即时通信应用程序可能需要NetworkServices 以访问internet 需要ReadUserData 以便从用户的地址簿中读取数据 每个要使用的API被审查 以记录它所需要的能力 如其文档中所描述的

能力分析 在代码的开发中反复实验 但这种办法一般情况下是不鼓励的 如果需要就添加能力 这可以通过Windows模拟器的平台安全设置确定 To write any failed capability checks to the debug log file 但这种办法一般情况下是不鼓励的 因为它可能导致被赋予多于它需要的能力 这反过来过使得程序有更大的被攻击的风险 从而减弱了一般安全模型 以及可能造成应用程序要求不必要的签名 这意味着费用和时间上的耗费

能力分析 绝大多数的平台安全能力 一个应用程序 与安全风险关联 要么是单独的，要么是组合的 应当被设计成不为其能力所累 它绝不应当被赋予比要真正需要更多的能力

能力分析 一个应用程序也应当确保 具有\private\<SID>\import目录的应用程序 其数据文件保持私有 通过使用其隔离的私有目录 该目录被数据锁定（data-caged ）不让所有其他进程访问 除非它们具有Tcb 或 AllFiles 能力的被信任进程 具有\private\<SID>\import目录的应用程序 该目录允许其他程序向其中安装数据 可能需要自己自己的验证机制 以决定导入的文件是否可信

数据共享 偶尔的，应用程序数据 在这种情况下 或者采用一个简单的办法 需要在进程之间共享 对数据来说，要被多个不同的进程共享是不寻常的 典型的，它只是对一个明确定义的组可访问的 在这种情况下 将文件保存在私有目录下是明智的 并且实现一个服务器来提供和管理数据 或者采用一个简单的办法 即，服务器将文件句柄传递给其他进程 这些进程具有足够的信任等级来访问文件

可移动介质上的数据 如果介质是可以从手机上移除的 这样 一些手机 数据的访问可以不通过系统的保护机制 如果一个应用程序将数据放在MMC中的私有目录下 没有办法组织用户将存储卡取下 然后在电脑上访问它 一些手机 支持密码保护的存储卡 但不要假定所有存储卡都有这种保护

可移动介质上的数据 敏感数据 例如 应只存储在内部磁盘上 或者应该加密存储 通过设计一个安全存储的应用程序模块 该模块在内部磁盘创建和存储一个加密密钥 使用密钥来保证数据是安全的 无论数据存储在那个磁盘

可移动介质上的数据 另一个与可移动介质使用相关联的问题 任何必须免于篡改的信息 是用户可以在PC上修改存储卡上的内容 然后重新把它插回到手机 这可能破坏数据 任何必须免于篡改的信息 必须被保护要么通过 将它保存在手机的内部磁盘 或者通过使用数据的密码学中的散列值来进行篡改检测

可移动介质上的数据 Symbian OS 使用密码学散列值技术 Symbian OS 检查二进制文件的散列值 当程序二进制文件被安装到可移动介质的\sys\bin 目录时 以确保二进制文件不被修改 当存储卡被移出手机时 Symbian OS 检查二进制文件的散列值 在每次它被加载时，以保证它没有被篡改

可移动介质上的数据 强制将二进制或数据文件 但是 它甚至可能阻止用户安装应用程序 安装到内部磁盘是可能的 通过在.pkg文件的目录路径中指定磁盘 而不是允许用户在安装时指定磁盘 但是 这种方法应该尽量少用 因为它阻止用户进行选择 以尽量使用可移动介质上的存储空间 它甚至可能阻止用户安装应用程序 如果在内部磁盘上没有足够空间的话

备份与恢复 另一个数据离开手机的途径 备份和恢复 它导致了一个潜在的安全威胁 是通过备份到PC 或者备份到可移动介质 是用户防止重要数据丢失的重要工具 它导致了一个潜在的安全威胁 因为一旦数据从手机中移出 它就可以被查看和/或篡改

备份和恢复 对于一个应用程序 可能存在一些数据是不需要备份的 因为它们很容易重建或者是瞬时性的 如，在恢复发生前可能会变化 例如 语音电话的持续时间 或者用于脱机数据的临时文件 其他数据仅仅是不应该备份Other data simply should not be backed up 例如银行帐号的PIN码 最好让用户重新输入它

备份和恢复 一些数据 如果数据必须向用户保护If the data must be protected from the user 可以在它被备份之前被加密——以保护它 如果数据必须向用户保护If the data must be protected from the user 例如——DRM密钥 它必须使用一个应用程序私有的密钥对其进行加密 密钥保存在手机上并永不备份 后者用户可能提取密钥并用它来解密内容 经过加密的备份数据 绝不能恢复到任何其他手机上 除非上面有解密密钥

备份和恢复 其他数据不需要保护 这种数据一个很好的例子 用户被要求输入密码 但是仍然应该加密备份 以保护用户数据免于被他人通过PC访问 可能是通信簿和电话记录等 用户被要求输入密码 才能访问备份的数据

备份和恢复 一些应用程序数据不需要保护 但是记得下面几天是很重要的 因为它对于应用程序和用户都不是保密的 数据可能潜在被篡改，当它们不在手机上时 要么恢复操作时必须检查数据的完整性 要么应用程序必须准备处理… 备份数据的异常修改

在Symbian OS v9上发布安全的应用程序

在Symbian OS v9上发布安全的应用程序 本节描述一些要求的步骤 一旦二进制文件代码准备就绪 用于在Symbian Os v9模拟器上测试一个安全的应用程序 并把它部署在手机硬件上 以便进一步的测试和发布

平台安全配置 Symbian OS的平台安全设置 例如 配置选项包括... 是可配置的 通过在模拟器的出刷文件中添加语句 \epoc32\data\epoc.ini 配置选项包括...

平台安全配置 PlatSecEnforcement 当打开时 如果平台安全执行被关闭 用于打开/关闭平台安全的执行 如果平台安全检查失败，将采取一定的行动 典型的，会产生一个KErrPermissionDenied 错误或者异常退出 如果平台安全执行被关闭 系统就会想所有安全检查都通过了那样运行

平台安全配置 PlatSecDisabledCaps 该设置指示加载器 例如 用于关闭对该关键字之后指定的能力的检查 授予系统中所有进程该语句中所给出的能力 例如 epoc.ini 中语句PlatSecDisabledCaps SwEvent 将关闭对 SwEvent 能力的检查

平台安全配置 PlatSecDiagnostics PlatSecEnforceSysBin 用于开启/关闭平台安全诊断消息的日志记录 记录到调试日志文件 epocwind.out 当平台安全检查失败或者产生了警告 PlatSecEnforceSysBin 强制模拟器只从\sys\bin 目录中加载二进制代码 模拟手机硬件

平台安全配置 它对于开发的早期阶段是很有用的 Windows模拟器缺省的设置 用于暂停平台安全的执行 并打开平台安全消息的诊断日志 以确定一个应用程序是否拥有它所需要的全部能力 Windows模拟器缺省的设置 是平台安全完全启动和执行 也就是手机硬件的真实模拟

MakeSIS, Makekeys, SignSIS 和 CreateSIS 不同于Windows 模拟器 其中二进制文件只是简单拷贝用以测试 在手机硬件上，安全和测试代码的唯一合法途径 是由软件安装器从一个安装包读入二进制代码 安装包就是SIS 文件

MakeSIS, Makekeys, SignSIS 和 CreateSIS Symbian OS 开发者使用一个Symbian OS 打包文件 (.pkg) 来向SIS文件创建工具（MakeSIS）指定 应用程序关联的文件和元数据 打包文件包含 文件 规则 应用程序需要的选项和依赖

MakeSIS MakeSIS是一个基于PC的 工具 一旦SIS文件被创建 它可以.. 它从.pkg 打包文件中读入数据，然后产生一个SIS安装文件 SIS安装文件包含了安装一个应用程序到手机上的所有必要信息 除了数字签名 一旦SIS文件被创建 在它的内容能够被安装到手机上之前，它必须进行签名 它可以..

MakeSIS, Makekeys, SignSIS 和 CreateSIS 自签名（Self-signed） 如果不需要能力 或者需要的是那些手机生产商认为是用户可授予的能力 这意味着代码是不可信的 由一个测试和认证程序签名 它需要的能力是不能由用户授予的 或者对于一个开发者他希望提升用户对程序的信心 通过让程序经过认证权威的测试和签名 为了移除警告 即，SIS文件来自一个“不可信的来源”

Makekeys 为了自签名SIS文件 但是 开发者可以使用基于PC的MakeKeys工具 以创建数字证书和私钥 该工具也能用于产生一个PKCS#10 证书请求 它可以被发送到一个可信权威以便进行签名 但是 绝大多数开发者不会用Makekeys来产生证书 而是想Symbian Signed申请一个开发者证书 该证书可以用于对测试用的安装文件进行签名

SignSIS 和 CreateSIS 一个SIS 安装文件可以使用SignSIS工具进行签名 以及一个证书和私钥 但是Symbian也提供称为CreateSIS的工具 它是Makekeys, MakeSIS 和 SignSIS 工具的整合 封装了SIS文件的创建和签名 开发者可以提供 一个密钥/证书对来对文件进行签名 否这 该工具会产生一个自签名的证书及其匹配的密钥

开发者证书 使用可信任权威 软件安装器 以签名SIS安装文件和为程序代码赋予能力 表现出一个有趣的 “第二十二条军规”的处境 只安装要求系统能力的二进制文件 如果它们被测试和认证权威签名 所以开发者必须想权威结构提交它们已经予以验证

开发者证书 为了让应用程序 但是开发者怎么测试它呢 解决方案 但是限制它的安装 通过需要的认证测试 它必须首先由开发者在硬件上充分的测试 如果它没有权威签名而不能安装到手机上? 解决方案 就是提供一个过渡的认证过程 使得开发者能够签名一个SIS安装文件以用于硬件测试 但是限制它的安装 这也SIS文件就不能广泛发布

开发者证书 发放的过渡证书 开发者证书 在GSM手机上 就是开发者证书 由Symbian Signed或者其他可信权威发放给个人或结构 例如手机制造商或网络运营商. 开发者证书 是有时间限制的 (6个月) 限定到一个特定手机上 或者一组有限的手机上 在GSM手机上 这是通过将证书锁定到手机的IMEI号来完成的

开发者证书 这种证书被限制于一个很小的能力集合 典型的，开发者需要从手机生产商请求特殊的授权 在接收到开发者证书之前 这允许它们能够签名要求最敏感能力的二进制文件 Drm, AllFiles, CommDD, DiskAdmin, MultimediaDD, Network Control 和 Tcb

开发者证书 开发者证书 也只能在有限的时间内有效 现在是从发放开始起共六个月 这些限制防止开发者 使用这种证书发布商用软件

Symbian Signed 要求能力的应用程序An application which requires capabilities 而这些能力不能由用户授予 则不能被安装到受平台安全保护的手机上 除非它经过了验证 验证由一个可信的认证权威进行，例如Symbian Signed Symbian Signed 于2004年3月启动，已经得到了广泛的商业认可

Symbian Signed 签名过程使用 使用了两种证书，分别用于 标准的公开密钥基础设施 (PKI) 以提供安全与认证 开发者认证 应用程序授权

Symbian Signed 第一种证书使用的 它被用于认证开发者的身份 是认证内容签名(Authenticated Content Signing ,ACS) Publisher ID, (现在就称为 “Publisher ID”) 它有一个直到公共根证书(public root certificate)的信任链 它被用于认证开发者的身份 开发者将被要求提供他/她自己的信息 以及审查者的详细联系方式,审查者将核对开发者所提供的信息

Symbian Signed 第二个使用的证书是内容ID (Content ID) 它被用于提供程序的授权 应用程序被认证为可信的 它具有到达根证书的信任链，该信任链构建在Symbian OS v9手机的ROM中 它被用于提供程序的授权 通过为应用程序授予能力 能力是Symbian Signed验证过的 应用程序被认证为可信的 只限于它所需要的并已经被验证过的能力 验证由独立的测试机构针对一组业界一致的标准进行

Symbian Signed Symbian Signed 测试标准 第一个部分是一般性测试 所以开发者可以首先自己测试应用程序以确保它符合要求 在提交给测试结构之前 测试包括两个部分 第一个部分是一般性测试 它会对所有提交的应用程序进行 以确认它们的稳定性以及对所需进程的忠实度 例如正确的使用UIDs, 高效的内存使用以及卸载时清除

Symbian Signed 第二个要素包括测试和声明书 一个应用程序要求的能力越多 这也是另一个原因 主要针对应用程序要求的特殊能力 它就需要越多的针对性测试 这意味着更加昂贵的测试周期 这也是另一个原因 为什么开发者应该限制应用程序所要求的能力 到应用程序真正需要的最小集合

Symbian Signed Summary 开发和内部测试，使用开发者证书对代码进行签名，在被安装到手机之 前 使用Publisher ID进行开发者认证 Symbian Signed 利用业界标准进行测试 用Content ID 证书进行签名，确认可信

注意 开发者证书和Symbian Signed 开发者可以测试和发布 一些开发者 是不需要的，如果是安装或发布不要求任何能力的二进制文件的话 或者只使用用户可授权的能力 开发者可以测试和发布 他们不可信的运行于沙箱中的应用程序，通过自签名 一些开发者 还是可以提交他们的二进制代码给Symbian Signed 这意味着他们的代码被认定为“可信的”，可以没有警告的安装 这样可以提高用户对应用程序的信心

本地软件安装器 知道Symbian OS v9中本地软件安装器的关键功能，包括Symbian OS v9和以 前版本在SIS文件格式上的不兼容

本地软件安装器 软件安装器 软件安装器引擎由Symbian提供 是扩展软件包正确安装到Symbian OS v9 手机上的 一个关节点 (“pinch point” ) 软件安装器引擎由Symbian提供 用户接口层由移动移动手机生产商自己加入 所以控件的外观感觉就会不同，即S60手机和UIQ手机

本地软件安装器 安装器通常被称为 软件安装器的关键责任是: 本地软件安装器 以指示它安装的软件直接运行在Symbian OS上 而不是像Java MIDlets 那样运行在Java虚拟机中 软件安装器的关键责任是: 验证和安装本地软件包 (即SIS 文件) 验证以预装形式发布在介质卡上的软件 以处理升级和删除的问题，并为平台的其他部分提供包管理服务

本地软件安装器 安装器在安装之前执行一系列的检查 如果通过了检查 这就是为什么安装器被称为“守门员”的原因 以检验SIS文件没有篡改 以及应用程序的二进制文件的能力没有超出允许的范围 检查是基于SIS包中的签名进行的 如果通过了检查 安装器将文件放置到手机上数据锁定（data-caged)正确目录 这就是为什么安装器被称为“守门员”的原因 构成了TCB的一部分

本地软件安装器 Symbian OS v9平台安全的引入 Symbian 抓住这个机会 这意味着v9以前的SIS文件 对软件安装器增加了一些很新的要求 SIS 安装包也增加了新的要求 Symbian 抓住这个机会 重新设计了SIS文件的基本结构 改变了以前发布版本的内部格式 这意味着v9以前的SIS文件 与Symbian OS v9 的软件安装器是不兼容的

本地软件安装器 这可能显示出一个很大的兼容性间断 v9 的软件安装器 例如 但是旧的SIS文件中的二进制文件 与Symbian OS v9所要求的本来就是不兼容的 因为新版本OS所造成的二进制间断 v9 的软件安装器 检查二进制代码，如果遇到旧的（v9以前的）不兼容文件，就退出安装 或者遇到了为其他硬件目标构建的软件也退出安装 例如 为运行在模拟器上构建的二进制软件 在一个准备安装到硬件上的安装包中，或者相反

平台安全: 第二部分 基于安全平台的应用程序设计 在Symbian OS v9上发布一个安全的应用程序 本地软件安装器