在传统的软件交付模式中,购买者通过检查包装来确定应用程序的来源及完整性。然而,在移动网络下载的软件存在风险,因为发行商的身份更难以确定。不慎在无线网络环境中引入恶意软件,不仅会给终端用户的智能手机带来风险,还会影响整个设备网络,使所有用户遭受攻击,并导致服务中断,严重损害网络提供商的声誉和财务业绩。
为保护智能手机用户,应用程序软件商店(如Windows Marketplace)现在要求应用代码签名技术,用数字签名对移动软件代码进行“签名”。创建一个“数字压缩包”,不仅能够验证软件代码的来源,还能确保代码并未被修改。
代码签名基于公共密钥加密法技术。开发者或软件发行商使用“私有”密钥,在软件代码中加设一个数字签名。例如,Windows Mobile 7移动平台,在移动应用程序下载过程中,使用“公共”密钥验证签名,将应用程序签名中的散列码与所下载程序中的散列码进行对比。
数字签名中的散列码用以确认文件内容,检验文件在签名后代码是否被更改或损坏。用户能够验证文件内容及软件的完整性,同时,发行商应该有能力及时有效召回损坏的证书。
在传统代码签名证书中,开发者使用相同的数字签名签署所有代码。但移动应用具有独特挑战,因为它要求独特的部署和管理方法。开发者和发行商必须有能力迅速召回有漏洞、有错误及有泄露的代码,但不影响合法开发者所发布的其它版本及应用程序。
理想情况下,移动代码签名的实现有两个数字认证——一个用来识别发行商,另一个用来识别内容。在这种情况下,发行商使用发行商身份标识号来签名代码,然后上传,再通过安全接口,由应用认证中心所提供的代码签名服务进行验证。一旦签名生效,它便会生成唯一的内容身份识别号,其中包括发行商身份和应用程序信息。接下来,认证中心可以使用内容身份识别号对内容重新进行签名,随后,它就可以被确定为可信的并允许发布的代码了。如果应用程序中有潜在而敏感的应用程序编程接口(API),那么在签发内容身份标识号前,便要求有第三方评估(如微软Privileged Access for Marketplace)。
重新签名过程技术对最终用户设备是透明的,因为在客户端设备层面只会执行一项检验。但对于开发商和网络提供商来说,分配具体的证书有利于简便地识别并召回有问题的代码,而并不影响应用程序的其余部分。这些方案和功能为网络运营商提供了更多的操控力和更好的网络保障,不会影响创新或最终用户体验。
大多情况下,来自受信源的签名代码可以被自动接收。安全警报也会提示终端用户查看签名信息,确定这一代码的可信度。某些网络提供商只接受已签名的应用程序,以便最大限度地降低网络风险;有些网络提供商则要求代码签名,以便应用程序能够访问潜在敏感的应用程序编程接口(API)。如果移动平台(如Windows Mobile 7)没能将应用程序的签名识别为有效签名,那么该平台将完全不会运行这一程序。