移动通信网正在以IP为核心实施承载网的技术变迁，业务网将依托在以IP为技术基础的承载网之上已没有太多的悬念。然而，现有IP承载网不能保证相应的安全性和可信任性，且加密技术滥用和失控，给信息安全造成了一些威胁。作为一种移动增值业务平台，BREW所提供的安全性是独一无二的。
4.3.4.1 系统安全
由于安全性涵盖面很广，即使OSI网络分层模型也存在不同的安全层面，上层的安全只有在下层的安全得到保障后才有意义，具有一定的传递性。所以当一个应用系统宣称自己是安全的系统之前，必须在不同层都拥有足够的安全性。按粒度从粗到细的排序是：系统级安全、程序资源访问控制安全、功能性安全、数据域安全。不同系统的系统级安全关注点往往差异很大，有很大部分的业务系统甚至不涉及系统级安全问题。
1)系统级安全：BREW的系统级安全是由所承载的无线网络决定的。以CDMA网络为例，能够实现访问IP段的限制，登录时间段的限制，连接数的限制，特定时间段内登录次数的限制等，是应用系统第一道防护大门。
2)资源访问控制安全 ：在BREW的客户端上，为应用程序提供了与其权限相关的设定，仅其权限相符功能才能被执行。
3)功能性安全：功能性安全会对BREW应用流程产生影响，为了保证BREW应用的安全性，所有的BREW商业应用都是经过严格测试的，也就是说，通过第三方独立测试（TRUE BREW TEST）来保证增值业务功能的安全性。
4)数据域安全：BREW中数据域的首要控制是数字签名控制的执行，不正确登陆的程序将不可能被执行，BREW执行环境启动/强制执行所有的其它控制和防御。数字签名是安全领域的有力武器，根密钥在VeriSign vault里，VeriSign 另有附加口令探测密钥的安全机制。
除此之外，基于BREW的移动增值业务分发渠道是单向的。应用程序一旦获得商用数字签名，将永远不可被修改，应用程序始终被数码签名保护。开发商的应用程序在BDS的下载服务器里，除了OTA以及运营商授权的预安装之外，他人一般没有获得或篡改该应用程序的渠道。在手机上任何修改,即使是一个字节, 都将被探测到并禁止执行。从而，病毒没有繁殖传播的可能性。也就是说，应用程序的发布不是对等流程, 也就没有传统的高速传播路径供病毒繁殖传播。资源访问控制的安全性使得一个程序不能改变或侵蚀另外一个程序，这种几乎不传播的可能性将促使病毒爱好者几乎望洋兴叹。
4.3.4.2 终端安全
BREW中使用一种名为 AEESafeMode 的机制来防止有问题的 BREW 应用程序导致的设备崩溃。手机设备首次崩溃后，此机制将在重新启动时将设备置于监察模式并启动一个计时器。计时器的持续时间由手机厂商配置。
如果计时器超时，此机制将运行级别转回正常模式。如果设备在计时器超时前再次崩溃，设备重新启动时将再次进入安全模式并启动计时器。在设备返回正常模式前禁止所有 BREW 应用程序创建活动。通过重新调用或升级有问题的应用程序可以恢复到正常模式。以下的图表显示了正常、监察和安全模式之间的转换关系。
图 4-9： BREW中的AEESafeMode机制
4.3.4.3 内容安全
对于应用内容而言，BREW提供了完备的应用认证与管理（图4-10），能够确保一个用户下载的应用程序只能为该客户所使用，从而有效地防止应用软件的非法复制与盗版现象，保证运营商和开发商以及用户的合法权益不受到侵害。
|
BDS |
|
ADS采用私钥License签名 |
|
BREW App数字签名 |
|
客户端信息 |
|
使用规则 |
|
+ |
|
ADS采用公钥解密 |
|
BREW App数字签名 |
|
客户端信息 |
|
客户端 License 验证 |
|
ADS 响应客户端的认证请求 |
|
签名操作 |
|
签名验证 |
|
依赖于终端信息来验证客户端信息 |
图 4-10： BREW应用的认证管理及数字签名
手机是一种必须重视安全性能的设备，用户在手机上使用的应用程序也必须能保证安全，能够在实现信赖性时发挥作用的是数字签名。所有应用程序如果没有开发人员或者运营商的电子签名，在BREW中将无法运行。对于那些数字签名有可能被更换的应用程序，则被判断成为有可能感染了病毒，从而在BREW环境下无法运行。 BREW要进行两次电子签名确认。第一次是在下载应用程序时，第二次是当运行下载的应用程序时还需要进行确认，这是为了避免下载后的应用程序被篡改成其他程序。
