CN100507934C - 针对代码签名服务来注册实体的系统和方法 - Google Patents

Abstract

一种针对代码签名服务来注册实体的系统和方法。实体可以是软件应用程序开发者或希望具有应用程序被数字地签名的其他个体或实体。可以要求签名应用程序，以便当在计算设备上执行应用程序时，使应用程序能够访问计算设备的敏感API以及相关资源。在一个实施例中，针对代码签名服务来注册实体的方法包括步骤：使用带外通信系统，将至少一些账户数据发送到注册个人或实体。这提供了附加的安全性，使得针对代码签名服务进行注册的个人或实体是想要注册的个人或实体。

Description

针对代码签名服务来注册实体的系统和方法

本专利文件公开的一部分包含受版权保护的材料。版权所有者不反对任何人复制该专利文件或专利公开，就像在专利和商标局的专利文件或记录中所显示的那样，然而无论如何保留所有的版权。

技术领域

这里描述的系统和方法的实施例大体上涉及针对软件应用程序的安全协议领域，更具体地，涉及一种系统和方法，用于向希望使软件应用程序被数字地签名以便可以在计算设备上(例如移动设备)执行该应用程序的个人或实体提供代码签名服务。

背景技术

含有软件代码签名方案的安全协议典型地被用于确保从因特网或其他来源下载以用于在计算设备上执行的软件应用程序的可靠性。例如，计算设备可以是移动设备。

可以在计算设备上实施代码签名系统，以便控制软件应用程序访问计算设备上的某些资源。在一个示例系统中，在计算设备中提供了应用平台、一个或多个应用程序编程接口(API)、以及虚拟机。配置API以使软件应用程序与应用平台相链接，以及更具体地，允许软件应用程序对资源做出功能调用，或者与计算设备上的软件应用程序通常可访问的资源进行交互。

然而，可以由希望限制对API的访问或对与这些API有关的特定资源的访问的实体，将一些API分类为“敏感的”。在示例系统中，在准予访问敏感API之前，虚拟机适于验证附加到要求访问敏感API的应用程序上的数字签名的真实性。因此，为了准许应用程序访问敏感API，适当的签名中心(signing authority)必须首先数字地签名应用程序。

发明内容

在一个方面，优选地提出了一种针对代码签名服务来注册实体的方法，包括步骤：从请求针对代码签名服务来注册的实体接收注册请求，其中注册请求包括与实体的身份相关的数据；通过验证注册请求中的数据的至少子集，来认证实体的身份；产生针对实体的账户记录，其中账户记录包括与实体相关的至少第一和第二标识符；经由第一通信信道向实体发送第一标识符和第二标识符中的一个，以及经由不同的第二通信信道向实体发送第一标识符和第二标识符中的另一个；从实体接收注册文件；在接受注册请求之前，确认注册文件至少包括第一和第二标识符两者。

附图说明

为了更好地理解这里描述的系统和方法的实施例，以及为了更加清楚地示出如何使他们产生效果，现在将参考附图为例，其中：

图1是在一个示例实施方式中的移动设备的方框图；

图2是图1的移动设备的通信子系统组件的方框图；

图3是无线网络节点的方框图；

图4是示出了示例代码签名协议的示意图，在该协议中，代码签名中心向软件应用程序开发者提供代码签名服务；

图5是示出了在移动设备中的示例代码签名系统的组件的示意图；

图6是示出了处理在图5中图示的移动设备上执行的已签名软件应用程序的示例方法的步骤的流程图；

图7A是示出了在一个实施例中提供代码签名服务的方法的步骤的流程图；

图7B是示出了在示例网络配置中的用于提供代码签名服务的系统的原理图；

图8A是示出了在一个实施例中创建用于代码签名的密钥对的方法的步骤的流程图；

图8B和图8C是由代码签名中心应用程序提供的用户界面中的示例对话框；

图9是示出了在一个实施例中用于针对代码签名服务来注册实体的方法的步骤的流程图；以及

图10是示出了账户记录的详情的示例表格。

具体实施方式

创建要求访问计算设备上敏感API的应用程序的软件应用程序开发者可能需要使他们的应用程序由适当签名中心数字地签名，使得应用程序在计算设备上正确地执行。期望限制访问某些敏感API(以及相关资源)(例如实体自己写出的专有API)的实体可能希望充当关于这些API的签名中心，并且向要求访问这些API的软件应用程序开发者提供代码签名服务。例如，通过代码签名服务的提供，实体能够控制谁应该或谁不应该被准许访问其写出和/或被分类为敏感的特定API、跟踪谁请求了此种访问、以及如果需要对提供此类访问收费。

这里描述的实施例大体上涉及一种用于向软件应用程序开发者或希望应用程序被数字地签名的其他个人或实体提供代码签名服务的系统和方法。当在计算设备上执行应用程序时，也许要求签名应用程序以使应用程序能够访问计算设备的敏感API以及相关资源。

向软件应用开发者或其他个人或实体提供代码签名服务的代码签名中心可以要求这些参与方针对代码签名服务来注册。在注册时，这些个体或实体可以提供在与代码签名中心安全地通信中使用的公钥。可被用来验证被提供的公钥是否属于相关的注册方的成本效率且及时的技术是值得期待的。

在一方面，这里提出了一种针对代码签名服务来注册实体的方法，该方法包括步骤：从请求针对代码签名服务来注册的实体接收注册请求，其中注册请求包括与实体的身份相关的数据；通过验证注册请求中的数据的至少子集，来认证实体的身份；产生针对实体的账户记录，其中账户记录包括与实体相关的至少第一和第二标识符；经由第一通信信道向实体发送第一标识符和第二标识符中的一个，以及经由不同的第二通信信道向实体发送第一标识符和第二标识符中的另一个；从实体接收注册文件；以及在接受注册请求之前，确认注册文件至少包括第一和第二标识符两者。

例如，已签名的应用程序所执行在的计算设备可以是移动站。然而，本领域普通技术人员应该理解，这里描述的至少一些实施例可以关于要在除移动站之外的计算设备上执行的应用程序来实现。

移动站是一种带有先进数据通信能力的双向通信设备，具有与其他计算机系统通信的能力，并且这里提到的一般指移动设备。移动设备也可以包括用于语音通信的能力。取决于由移动设备提供的功能，可以称其为数据消息设备、双向寻呼机、带有数据消息能力的蜂窝电话、无线因特网装置、或数据通信设备(带有或不带有电话能力)。移动设备通过收发站的网络与其他设备通信。为有助于读者理解移动设备的结构以及其如何与其他设备通信，首先参考图1至图3。

参考图1，在一个示例实施方式中的移动设备的方框图大致如100所示。移动设备100包括多个组件，其中控制组件是微处理器102。微处理器102控制移动设备100的所有操作。通过通信子系统104来执行包括数据和语音通信的通信功能。通信子系统104从无线通信网络200接收消息并向其发送消息。在移动设备100的该示例实施方式中，根据全球移动通信系统(GSM)和通用分组无线业务(GPRS)标准来配置通信子系统104。GSM/GPRS无线网络在世界范围内广泛使用，并且可以预料的是这些标准最终将由增强数据GSM环境(EDGE)和通用移动通信服务(UMTS)所取代。新的标准正在制定中，但是可以相信的是他们具有与这里描述的网络行为相类似的网络行为，本领域的技术人员也应该理解，可以使用将来开发的其他合适的标准。使无线通信子系统104与网络200相连接的无线链路代表一个或多个不同的射频(RF)信道，根据针对GSM/GPRS通信规定的已定义协议来运行。随着更新的网络协议，这些信道能够支持电路交换语音通信和分组交换数据通信这两者。

尽管在移动设备100的一个示例实施方式中，与移动设备100相关联的无线网络是GSM/GPRS无线网络，在不同的实施方式中也可以使其他无线网络与移动设备100相关联。例如，可使用的不同类型的无线网络包括：数据核心无线网络、语音核心无线网络、以及通过同一物理基站能够支持语音和数据通信的双模网络。组合的双模网络包括但不限于：码分多址(CDMA)或CDMA2000网络、GSM/GPRS网络(如上面提到的)、以及例如EDGE和UMTS的未来第三代(3G)网络。数据核心网络的一些较早的示例包括：Mobitex^TM无线电网络以及DataTAC^TM无线电网络。较早的语音核心数据网络的示例包括象GSM以及时分多址(TDMA)系统的个人通信系统(PCS)网络。

微处理器102还与附加子系统进行交互，所述附加子系统例如随机存取存储器(RAM)106、闪速存储器108、显示器110、辅助输入/输出(I/O)子系统112、串行端口114、键盘116、扬声器118、麦克风120、短程通信子系统122、以及其他设备124。

移动设备100的一些子系统执行通信相关功能，而其他子系统可以提供“常驻”或设备上(on-device)功能。作为示例，显示器110和键盘116可以被用于通信相关功能，例如键入用于通过网络200发送的文本消息，以及用于诸如计算器或任务列表的常驻设备功能。由微处理器102使用的操作系统软件典型地被存储在例如闪速存储器108的永久存储器中，可选地，存储器可以是只读存储器(ROM)或类似存储单元(未示出)。本领域的技术人员应该理解的是，可以将操作系统、特定设备应用程序或其一部分临时地加载到诸如RAM 106的易失存储器中。

在已经完成所要求的网络注册或激活程序之后，移动设备100可以通过网络200发送和接收通信信号。网络访问与移动设备100的订户或操作者有关。为了识别订户，移动设备100要求将用户身份模块或“SIM”卡126插入到SIM接口128以便与网络通信。其中，SIM 126是用于识别移动设备100的订户以及使移动设备100个人化的一种传统类型的“智能卡”。如果没有SIM 126，移动设备100不能完全操作以与网络200通信。通过将SIM 126插入到SIM接口128，订户能够访问所有订阅的服务。服务可以包括：网页浏览和诸如电子邮件、语音邮件、短消息服务(SMS)、以及多媒体信息传递服务(MMS)的消息传递。更高级的服务可以包括：销售点、现场服务和销售人员自动化。SIM 126包括处理器和用于存储信息的存储器。一旦将SIM126插入到SIM接口128，它就与微处理器102相连。为了识别订户，SIM 126包含一些诸如国际移动用户身份(IMSI)的参数。使用SIM 126的优点是用户不必受限于任何个别的物理移动设备。SIM 126同样地可以存储移动设备的附加订户信息，包括日期簿(或日历)信息以及近期通话信息。

移动设备100是电池供电的设备，并且包括用于容纳一个或多个可充电电池130的电池接口132。电池接口132连接到稳压器(未示出)，稳压器辅助电池130向移动设备100提供V+的电能。尽管当前的技术使用电池，诸如微燃料电池的未来技术也可以向移动设备100提供电能。

除了其操作系统的功能之外，微处理器102能够在移动设备100上执行软件应用程序。通常在制造期间就将控制包括数据和语音通信应用程序的基本设备操作的一组应用程序安装到移动设备100上。可以被加载到移动设备100上的其它应用程序是个人信息管理器(PIM)。PIM具有组织和管理订户感兴趣的数据项目的功能，所述数据项目例如但是不限于：电子邮件、日历事件、语音邮件、约会、以及任务项目。PIM应用程序具有经由无线网络200发送和接收数据项目的能力。可以经由无线网络200将PIM数据项目无缝地与主机计算机系统存储的和/或与主机计算机系统有关的移动设备订户的相应的数据项目集成、同步、以及更新。该功能在移动设备上创建了关于这些项目的镜像主机计算机。这在主机计算机系统是移动设备订户的办公计算机系统时是特别有利的。

也可以通过网络200、辅助I/O子系统112、串行端口114、短程通信子系统122或任何其他合适的子系统124，将附加的应用程序加载到移动设备100。应用程序安装中的这种灵活性增加了移动设备100的功能性，并且可以提供增强的“设备上”功能、通信相关功能或这两个功能。例如，安全通信应用程序使得能够使用移动设备100来执行电子商务功能和其他此类金融交易。

串行端口114使用户能够通过外部设备或软件应用程序来设置优选项，并且通过不通过无线通信网络来给移动设备100提供信息或软件下载，扩展了移动设备100的性能。例如，可以通过直接的并且因而可靠且可信的连接，使用可选的下载路径将加密密钥加载到移动设备100上，以便提供安全的设备通信。

在不使用网络200时，短程通信子系统122提供在移动设备100和不同的系统或设备之间的通信。例如，子系统122可以包括红外设备以及用于短程通信的相关电路和组件。短程通信的示例包括由红外数据协会(IrDA)所发展的标准、蓝牙、以及IEEE发展的802.11标准族。

在使用中，由通信子系统104处理诸如文本消息、电子邮件消息、或下载网页之类的接收信号，并将其输入到微处理器102。然后微处理器102处理接收的信号，将其输出到显示器110或可选地输出到辅助I/O子系统112。订户也可以例如结合显示器100以及可能的辅助IO子系统一起来使用键盘116，编撰诸如电子邮件消息的数据项目。辅助子系统112可以包括以下设备，例如：触摸屏、鼠标、轨迹球、红外指纹检测器、或带有动态钮按压能力的滚轮。键盘116是字母数字键盘和/或电话型小键盘。可以通过通信子系统104在网络200上发送编撰的项目。

对于语音通信，除了接收信号被输出到扬声器118，以及由麦克风120产生用于发送的信号之外，移动设备100的所有操作基本上都是类似的。也可以在移动设备100上实现可选的语音或音频I/O子系统，例如语音消息记录子系统。尽管主要通过扬声器118实现语音或音频信号输出，也可以使用显示器110来提供附加信息，例如主叫方的身份、语音呼叫的持续时间、或其他的语音呼叫相关信息。

现在参考图2，示出了图1的通信子系统组件104的方框图。通信子系统104包括接收机150、发射机152、一个或多个嵌入的或内部的天线元件154、156、本地振荡器(L0)158、以及诸如数字信号处理器(DSP)160的处理模块。

通信子系统104的特定设计取决于移动设备100意欲操作于的网络200，因此应该理解的是，图2中图示的设计仅用作一个示例。由天线154通过网络200接收到的信号被输入到接收机150，接收机150可以执行诸如信号放大、频率下转换、滤波、信道选择以及模数(A/D)转换的普通接收机功能。接收信号的A/D转换允许在DSP160中执行诸如解调和解码的更复杂的通信功能。以类似的方式，由DSP160处理将被发射的信号，所述处理包括调制和编码。这些已被DSP处理的信号被输入到发射机152，用于数模(D/A)转换、频率上转换、滤波、放大、以及经由天线156在网络200上发射。DSP160不但处理通信信号，而且提供接收机和发射机的控制。例如，可以通过在DSP160中实施的自动增益控制算法自适应地控制在接收机150和发射机152中施加到通信信号的增益。

在移动设备100和网络200之间的无线链路可以包含一个或多个不同的信道(典型地为不同的RF信道)、以及在移动设备100和网络200之间使用的相关协议。RF信道是必须节约使用的有限资源，典型地是由于整体带宽以及由移动设备100的有限电池电能的限制所限制。

当移动设备100完全运转时，典型地仅当向网络200发送时才打开发射机152，否则关闭以便节约资源。类似地，定期地关闭接收机150以便节约资源，直到在指定的时间段期间需要接收信号或信息(如果有的话)才打开。

现在参考图3，无线网络节点的方框图如202所示。实际上，网络200包括一个或多个节点202。移动设备100与无线网络200内的节点202通信。在图3的示例实施方式中，根据通用分组无线服务(GRRS)以及全球移动通信系统(GSM)技术来配置节点202。节点202包括：具有相关塔站206的基站控制器(BSC)204、被添加以用于在GSM中支持GPRS的分组控制单元(PCU)208、移动交换中心(MSC)210、归属位置寄存器(HLR)212、访问位置寄存器(VLR)214、服务GRPS支持节点(SGSN)216、网关GPRS支持节点(GGSN)218、以及动态主机配置协议(DHCP)220。组件的列表并不意味着是GSM/GPRS网络内的每个节点202的组件的详尽列表，而是在通过网络200的通信中普遍使用的组件的列表。

在GSM网络中，MSC210与BSC202以及例如公共交换电话网络(PSTN)222的地面网络相连，以便满足电路交换的需求。通过PCU 208、SGSN 216以及GGSN 218与公共或专用网络(因特网)224(这里也统称为共享网络基础结构)的连接代表了针对有GRPS能力的移动设备的数据通道。在扩展具有GRPS性能的GSM网络中，BSC 204还包含与SGSN 216相连的分组控制单元(PCU)208，以便控制分段、无线信道分配、以及满足分组交换的需求。为了针对电路交换和分组交换管理来追踪移动设备的位置和可用性，在MSC 210和SGSN 216之间共享HLR 212。由MSC 210控制对VLR 214的访问。

站点206是固定收发站点。站点206和BSC 204一起形成固定收发设备。固定收发设备向通常称作“小区”的特定覆盖区域提供无线网络覆盖。固定收发设备经由站点206向在其小区内的移动设备发射通信信号以及从在其小区内的移动设备接收通信信号。固定收发设备在其控制器的控制下，根据特定的、通常是预定的通信协议和参数，通常执行这样一些功能，例如对将要被发射到移动设备的信号的调制以及可能地编码和/或加密。如有必要，固定收发设备类似地解调和可能地解码和/或解密从在其小区内的移动设备100接收到的任意通信信号。不同节点之间的通信协议和参数可以不同。例如，一个节点可以使用与其他节点不同的调制方案并且在与其他节点不同的频率处运行。

对于向特定的网络注册的所有移动设备100，将诸如操作者简介的永久配置数据存储在HLR 212中。HLR 212还包含针对每个已注册的移动设备的位置信息，并且能够被查询以确定移动设备的当前位置。MSC 210负责一组位置区域，并且将当前处于负责区域内的移动设备的数据存储在VLR 214中。VLR 214还包括关于访问其他网络的移动设备的信息。VLR 214中的信息包括从HLR 212向VLR214发射的、用于更快访问的永久移动设备数据的一部分。通过将附加的信息从远程HLR212节点移动到VLR214，可以减少在这些节点之间的通信量，使得以更快的响应时间来提供语音和数据服务并同时需要较少地使用计算资源。

SGSN 216和GGSN 128是针对GPRS(即在GSM内的分组交换数据支持)支持而增加的元件。通过追踪每个移动设备100的位置，SGSN 216和MSC 210在无线网络200内具有类似的职责。SGSN 216还执行安全功能和网络200上数据业务的访问控制。GGSN 218提供与外部分组交换网的因特网连接，并且经由在网络200内运行的因特网协议(IP)骨干网与一个或多个SGSN 216相连。在正常的操作期间，给定的移动设备100必须执行“GPRS附加(attach)”以便取得IP地址并且访问数据服务。在电路交换语音信道中并不存在该请求，因为综合业务数字网(ISDN)地址被用于路由入和出的呼叫。现在，所有具有GPRS功能的网络使用专有的、动态分配的IP地址，因此需要与GGSN 218相连的DHCP服务器220。存在多种用于动态IP分配的机构，包括使用远程验证用户拨入业务服务器(RADIUS)以及DHCP服务器。一旦完成了GPRS附加，就建立了从移动设备100、通过PCU 208以及SGSN 216、到GGSN 218内部的访问点节点(APN)的逻辑连接。APN代表能够直接访问因特网兼容服务或专用网络连接的IP隧道的逻辑端。APN还代表针对网络200的安全机制，因为必须将每个移动设备100分配给一个或多个APN，以及如果没有首先对已被授权使用的APN执行GRPS附加，则移动设备100不能交换数据。

一旦完成GRPS附加，就创建了隧道，并且在使用IP分组中可支持的任意协议在标准IP分组内交换所有通信量。这包括隧道方法，例如在与虚拟专用网络(VPN)一起使用的IP安全(IPsec)连接的情况下的IP over IP。这些隧道也被称为分组数据协议(PDP)环境(context)，并且在网络200中存在有限数目的可用隧道。为了最大化使用PDP环境，网络200针对每个PDP环境来运行空闲计时器以便确定是否不活动。当移动设备100未使用其PDP环境时，能够释放PDP环境，并且IP地址回到由DHCP服务器220管理的IP地址池。

为了更好的理解在涉及提供代码签名服务的本说明书中所描述的系统和方法的各个实施例，将参考图4至图6，首先描述示例代码签名协议和从移动设备方面看的示例代码签名系统的特征。如先前所述的，尽管通常参考移动设备来描述多个下面的示例，这里描述的实施例对于除移动设备之外的设备也是适用的。

参考图4，示出了示例代码签名协议的示意图大体上如300所示，其中代码签名中心向软件应用程序开发者提供代码签名服务。

软件应用程序开发者302创建针对移动设备100的软件应用程序304，要求访问移动设备100上的一个或多个敏感API。应该理解的是，软件应用程序包括最终可以在移动设备或其他计算设备上执行的软件代码。因此，在这里术语“代码签名”和“应用程序签名”可以互换地使用。

例如，软件应用程序304可以是在安装在移动设备100上的Java虚拟机(JVM)上运行的Java应用程序。API使软件应用程序能够与移动设备或其他计算设备上的应用程序平台相接口。例如，应用程序平台可以包括：诸如设备硬件的资源、操作系统和核心软件、以及数据模型。因此为对这种设备资源做出功能调用或与这种设备资源进行交互，软件应用程序304通常需要访问移动设备100上的一个或多个API。API在软件应用程序304和设备资源之间有效地“桥接(bridge)”。

在该说明书和所附权利要求中，查阅API访问应该被解释为包括以这样一种方式访问API，以使软件应用程序与一个或多个相应设备资源进行交互。因此，提供对任意API的访问使得软件应用程序与相关的设备资源进行交互，而拒绝对API的访问防止软件应用程序与相关资源进行交互。例如，数据库API可以与设备文件或数据存储系统进行通信，并且对数据库API的访问将提供软件应用程序和文件或数据存储系统之间的交互。用户接口(UI)API将与诸如屏幕、键盘、以及给移动设备的操作者提供输出或者从其接收输入的任意其它设备组件的控制器和/或控制软件进行通信。在移动设备中，例如，也可以提供无线API作为例如发射机和接收机的无线通信资源的接口。可以提供加密的API以便与加密模块进行交互，所述加密模块在设备上实现加密算法。这些仅是可以在移动设备和可能的其他计算设备上提供的API的演示性示例。这种设备可以包括这些示例API中的一些或全部、或不同的API，来取代上述API，或添加到上述那些API中。

通常，可以由移动设备制造商、或可能由API作者、无线网络操作者、移动设备所有者或操作者、或也许会受针对设备的软件应用程序中的病毒或恶意代码所影响的一些其他实体，将任意给定的API分类为敏感的。例如，移动设备制造商可以将与加密例程、无线通信功能、或诸如地址簿或日历条目的专用数据模型相接口的一些API分类为敏感的。为保护以避免对这些敏感API的未授权访问，需要软件应用程序开发者302从移动设备制造商或将API分类为敏感的其他实体、或从代表制造商或致力于保护对敏感设备API的访问的其他实体的代码签名中心306，获得一个或多个数字签名，以及如下面进一步所描述的，向软件应用程序304添加签名。

可以针对每个敏感API或包括软件应用程序要求访问的敏感API的库，获得数字签名。在某些的实施方式中，想要获得多重签名。例如，这将允许服务提供商、公司或网络运营商限制加载或更新到特定一组移动设备上的一些或全部软件应用程序。在一个多重签名的场景中，限制并锁定设备上的所有API，直到验证了用于软件应用程序的“全局”签名。例如，公司也许希望在首先从企业信息技术(IT)或计算机服务部门获得许可之前，防止其雇员在他们的设备上执行任何软件应用程序。则可以配置所有这种企业移动设备以在能够执行软件应用程序之前需要验证至少全局签名。因此能进一步限制访问敏感的设备API和库(如果有的话)，使之取决于各自的对应数字签名的验证。

软件应用程序304的二进制可执行表示可以与移动设备的特定类型或移动设备的型号无关。例如，软件应用程序304可以是一次写成随处运行的二进制格式，例如典型地Java软件应用程序的情况。然而，也许想要持有例如针对每个类型或型号的移动设备、或可选地针对每个移动设备平台或制造商的数字签名。因此，如果软件应用程序304以多个类型或型号的移动设备作为目标，则可能需要将软件应用程序304提交给多个代码签名中心。

在图4中所示的示例中，当软件应用程序开发者302要求签名软件应用程序304时，软件应用程序304被从软件应用程序开发者302发送到代码签名中心306。代码签名中心306可以代表移动设备制造商、任意敏感API的作者、或可能具有软件应用程序304需要访问的敏感API的操作知识的其他人。

虽然在一些情况下在图4中没有明确地示出，应该理解的是，软件应用程序可以被提交给多于一个代码签名中心。例如，每个代码签名中心可以对针对特定的敏感API的、或针对在支持软件应用程序所需要的敏感API的特定型号的移动设备或一组移动设备上的API的签名软件应用程序负责。因而，例如制造商、移动通信网络运营商、服务提供商、或企业客户可以针对他们的特定移动设备型号，或针对运行在特定网络上的、订阅了一个或多个特定服务的、或分配给企业雇员的移动设备，具有针对敏感API使用的签名中心。因此，已签名的软件应用程序可以包括软件应用程序和来自每个签名中心的至少一个附加数字签名。在此示例中，尽管这些签名中心将产生针对相同软件应用程序的数字签名，不同的签名和签名验证方案可以与不同的签名中心相关。

从代码签名中心306方面看，代码签名中心306接收软件应用程序304，并且自行地签名软件应用程序304，以允许访问移动设备上的一个或多个敏感API。在代码签名中心306签名软件应用程序304之前，在确定是否应该签名软件应用程序304中，代码签名中心306可以考虑应用程序开发者302的身份。代码签名中心306在签名之前还可以重新检查软件应用程序304；可选地，代码签名中心306依靠其识别软件应用程序开发者302的身份的能力，可以选择不执行这种重新检查，所述能力依赖于例如发现软件应用程序304被感染病毒或含有恶意代码。

如果代码签名中心306确定软件应用程序304可以访问敏感API，并且因此应该被签名，则由代码签名中心306产生数字签名(未明确地示出)并且将其附加到软件应用程序304，以便产生将要被返回给软件应用程序开发者302的已签名的软件应用程序308。另一方面，如果代码签名中心306拒绝签名软件应用程序304，可以将适当的响应(未示出)返回给软件应用程序开发者302。

典型地，数字签名是使用仅由代码签名中心306持有的签名私钥310产生的标记。例如，根据一个签名方案，可以使用诸如安全散列算法SHA1的散列算法，由代码签名中心306产生软件应用程序304的散列，然后用签名私钥310进行编码以便创建数字签名。尽管在此示例中，使用签名私钥310，对要签名的信息散列进行编码，例如可以从软件应用程序304中推导出，然而在不同的方案中，可以以其他的方式使用签名私钥310，从要签名的信息或信息的变换版本中产生数字签名。

然后可以将已签名的软件应用程序308通过例如无线网络200发送到移动设备100，或加载到移动设备100上。例如，可以将已签名的软件应用程序308经由计算机网络下载到个人计算机，并通过串行链路加载到移动设备100，或者可以以另外的方式从软件应用程序开发者302获得并加载到移动设备100上。一旦将已签名的软件应用程序308加载到移动设备100上，则在准予软件应用程序304访问敏感API之前，典型地要利用签名公钥312来验证已签名的软件应用程序308的至少一个数字签名。

尽管已签名的软件应用程序308已被加载到移动设备100上，本领域的技术人员应该理解的是，最终可以在移动设备100上执行的软件是软件应用程序304。如上所述，已签名的软件应用程序308典型地包括软件应用程序304和一个或多个附加的数字签名(未示出)。当成功验证了(例如由移动设备100的虚拟机)正确的数字签名时，可以在移动设备100上执行软件应用程序304，并且准许软件应用程序304访问对应签名已被验证的任意API。

包括软件代码签名方案的安全协议典型地依赖加密公钥和私钥，来提供授权以访问敏感API，以及确保已签名的应用程序的完整性。根据已知的公钥的加密技术，使用私钥/公钥对的私钥加密的数据仅能够使用密钥对中对应的公钥来解密，并且反之亦然。

在此示例中，代码签名中心通过产生数字签名来签名软件应用程序。数字签名是软件应用程序摘要(例如散列)，或可能是从软件应用程序推导出的一些数据，使用代码签名中心的私钥对其进行编码。然后可以将数字签名附加到软件应用程序。

为在移动设备或其他计算设备中验证数字签名，以类似的方式(例如使用相同的标准散列算法)从在设备处接收到的软件应用程序(将要附加数字签名的程序)中获得摘要。典型地与敏感API一起存储的代码签名中心的公钥被用于解码附加的数字签名，以便获得应该是接收到的软件应用程序的匹配摘要的摘要。如果摘要不匹配，这意味着要么在设备处接收到的软件应用程序不是由代码签名中心所签名的同一应用程序，要么软件应用程序没有使用正确的私钥或不是由正确的代码签名中心进行签名的。以这样的方式来设计数字签名算法，使得只有具有代码签名中心的私钥的知识的人能够对数字签名进行编码，所述数字签名可以使用与一个或多个敏感API相关联的代码签名中心的公钥来正确地解码(例如由在设备处的虚拟机)。因此，通过以这种方式验证数字签名，可以保持对敏感API的授权和访问控制以及已签名应用程序的完整性。

因此，签名公钥312与由代码签名中心306持有的签名私钥相对应，并且典型地随同一个或多个敏感API一起被设置在移动设备100上。可选地，可以使用移动设备100或可能地个人计算机系统，从公钥库(未示出)中获得签名公钥312，并且按照需要设置在移动设备100上。移动设备100使用与代码签名中心306相同的散列算法，计算已签名的软件应用程序308中的软件应用程序304的散列，并且使用数字签名以及签名公钥312，来恢复最初由代码签名中心306编码的散列。然后比较作为本地计算结果的散列和从数字签名中恢复的散列，并且如果散列相同则验证了签名。如果对软件应用程序304进行了多次签名，可以以相同的方式验证每个数字签名。然后软件应用程序304能够在移动设备100上执行，并且访问对应签名已被验证的任意敏感API。提供该示例签名方案仅仅是为了示例，并且在不同的实施方式中也可以使用包括其他公钥签名方案的其他签名方案。

参考图5，示出了移动设备上的示例代码签名系统的组件的示意图大体上如320所示。

关于移动设备100，示例代码签名系统320包括虚拟机322(例如JVM)、多个软件应用程序324a至324c、多个API库326a至326d、以及应用程序平台328。应用程序平台328一般包括：设备100上的可以由软件应用程序324a至324c访问的所有资源。例如，应用程序平台328可以包括：设备硬件330、移动设备的操作系统332、以及核心软件和数据模型334。每个API库326a至326d包括：与在应用程序平台328中可用的资源相接口的一个或多个API。例如，一个API库可以包括与日历程序以及日历条目数据模型相接口的所有API。另一个API库可以包括与移动设备100的传输电路和功能相接口的所有API。又一个API库可以包括能够与由移动设备的操作系统332所执行的低层服务相接口的所有API。

一些API库326a至326d可以使例如接口的敏感API暴露于密码功能或模块(例如326a、326c)，而其他的库可以在不暴露敏感API下就可以被访问(例如326b、326d)。类似地，一些软件应用程序324a至324c是要求访问一个或多个敏感API的已签名软件应用程序(例如324a、324c)，其他的软件应用程序是未被签名的(例如324b)。虚拟机322可以是诸如Sun公司的J2ME^TM(Java 2平台，Micro版本)的面向对象运行时间环境，用于管理在移动设备100上运行的软件应用程序324a至324c的执行，并且使软件应用程序324a至324c与不同的API库326a至326d相链接。

在图5中标注为应用程序Y的软件应用程序324a是已签名的软件应用程序的示例(例如图4的已签名的应用程序308)。在该示例中，已签名的软件应用程序324a包括：包含例如可在应用程序平台328上执行的软件代码的软件应用程序(例如图4的应用程序304)；一个或多个签名标识符336a；以及与数字签名标识符336a相关的一个或多个数字签名338a。软件应用程序324c以及其他已签名的软件应用程序通常包括类似的组件。然而，下面将参考软件应用程序324a作为示例，详细地描述已签名的软件应用程序的组件。

在已签名的软件应用程序324中的每个数字签名338a以及相关的签名标识符336a可以对应于API库326a、326c，所述326a和326c暴露了软件应用程序324a要求访问的至少一个敏感API。在某些实施方式中，已签名的软件应用程序324a可以包括针对特定API库326a、326c内的每个敏感API的数字签名338a。签名标识符336a可以是能够使特定的数字签名338a与特定的API库、API、应用程序平台、或移动设备的型号相关联的唯一整数或一些其他标识符。

在图5中标注为API库A的API库326a是暴露敏感API的API库的示例。在该示例中，API库326a包括描述字符串340、签名公钥312、以及签名标识符342。API库326c以及暴露一个或多个敏感API的其他API库通常包括类似的组件。然而，下面将参考软件应用程序326a作为示例，详细地描述此种API库的组件。

API库326a的签名标识符342可以对应于在已签名的软件应用程序(例如324a)中的签名标识符(例如336a)。这些签名标识符使虚拟机322能够快速地将数字签名(例如338a)与API库(例如326a)匹配。签名公钥312对应于由代码签名中心持有的签名私钥(例如图4的310)，并且被用于验证附加到已签名的应用程序324a的数字签名338a的真实性。例如，当已签名的软件应用程序314a被加载或试图访问API库326a的敏感API时，描述字符串340可以是在移动设备100上显示的文本消息。

可操作地，当将要求访问特定敏感API(例如在API库中的API)的已签名软件应用程序加载到移动设备100上时，虚拟机322搜索与该API相关的附加数字签名的已签名软件应用程序。在该示例中，这包括将与数字签名相关的特定签名标识符与对应API库的签名标识符(例如342)相匹配。如果已签名的软件应用程序包括适当的数字签名，则虚拟机322使用与该API库有关的签名公钥312来验证其真实性。然后在成功验证数字签名时，准予已签名的软件应用程序访问敏感API。如果已签名的软件应用程序不包括适当的数字签名，则拒绝访问敏感API。

可选地，即使成功地验证了适当的数字签名，也可以提示移动设备操作者提供可以由软件应用程序访问敏感API的确认。在这种情况下，在执行软件应用程序和访问敏感API之前，可以在移动设备100的显示器上显示基于描述字符串340的消息。例如，可以显示表示“应用程序Y试图访问API库A”的消息，并且可以赋予移动设备操作者控制权以便最终准予或拒绝访问敏感API。

本领域技术人员要理解的是，任意给出的已签名软件应用程序可以具有多重设备专用、库专用、或API专用的签名、或附加在其上的此类签名的组合。类似地，可以针对不同的设备来配置不同的签名验证要求。例如，可以向已签名的软件应用程序提供数字签名，准予访问一个移动设备型号上的给定敏感API、而不准予访问不同的移动设备型号上的相同敏感API。这也许导致已签名的软件应用程序被准予访问一种类型的移动设备上的敏感API，而不被准予访问另一种类型的移动设备上的敏感API。作为另一示例，一个移动设备也许需要对全局签名和附加签名进行验证，所述附加签名是针对软件应用程序要求访问以便执行软件应用程序的任意敏感API的。另一移动设备可以要求单独的全局签名的验证，而另一个不同的移动设备可以要求仅针对其敏感API的签名的验证。

本领域的技术人员要理解的是，在不同的实施方式中，能够接收附加了数字签名的软件应用程序的某些设备可以适于没有任何签名验证就准予执行软件应用程序，所述设备包括例如其中没有实现数字签名、或数字签名是可选的设备。

参考图6，示出了处理在图5中图示的移动设备上执行的签名软件应用程序的示例方法中的步骤的流程图大体上如350所示。

在步骤352中，将软件应用程序(例如图5的应用程序324a)加载到移动设备(例如图5的移动设备100)。一旦加载了软件应用程序，在步骤354中，例如使用虚拟机(例如图5的虚拟机322)，设备确定软件应用程序是否要求访问暴露了敏感API的任意API库。如果软件应用程序确实要求访问敏感API，则如下面参考步骤356至366所述的，虚拟机验证软件应用程序是否包括与所要求访问的敏感API相关的(或与API库相关的)有效数字签名。如果没有要求，在步骤368中将软件应用程序与所有其要求的API库相链接，并执行。

在该示例中，在步骤356中，虚拟机检索针对相应的API库的签名公钥(例如图5的公钥312)以及签名标识符(例如图5的签名标识符342)。然后在步骤358中，由虚拟机使用API库的签名标志符，来确定软件应用程序是否具有带有对应签名标识符(例如图5的签名标识符336a)的附加数字签名(例如图5的签名标识符338a)。如果没有，则适当的代码签名中心不批准软件应用程序访问敏感API，并且在步骤360中防止执行软件应用程序，或者可选地(在图6中没有明确地示出)，可以从移动设备中清除软件应用程序，或者在可以不访问敏感API的程度内执行软件应用程序。在采取这些行动之前可以提醒用户进行输入，以便提供对要执行的特定动作的用户控制(未示出)。

如果对应于敏感API的数字签名已被附加到软件应用程序并且由虚拟机定位，则在步骤362中，虚拟机使用公钥来验证数字签名的真实性。例如，可以通过使用参考图4描述的签名验证方案、或其他可选的签名方案，来执行该步骤。如果数字签名没有成功地验证，则如上参考步骤360所述的，不执行、清除、或限制软件应用程序访问敏感API。然而如果成功地验证了数字签名，则可选地，在步骤364中，向移动设备的操作者显示基于与敏感API或对应API库相关联的描述字符串(例如图5的描述字符串340)的消息，警告软件应用程序要求访问敏感API，并且在步骤366中，可选地提示操作者授权以执行软件应用程序。如果对执行进行了授权，则在步骤368中可以执行软件应用程序并且将其链接到敏感API，否则如上参考步骤360所述的，不执行、清除、或限制软件应用程序访问敏感API。

当对于给定的软件应用程序，要验证多于一个数字签名时，则在执行应用程序之前，可以针对每个数字签名，重复步骤354至366。

这里描述的实施例大体上涉及一种用于提供代码签名服务的系统和方法。如之前所述的，可以由代码签名中心(例如图4的代码签名中心306)给软件应用程序开发者或希望具有已数字地签名的软件应用程序的其他个人或实体提供代码签名服务，使得当在计算设备(例如图4的移动设备100)上执行应用程序时应用程序可以访问敏感API。可以充当代码签名中心的实体的示例可以包括：移动设备制造商、API作者、无线网络运营商、设备拥有者或操作者、可能受计算设备的软件应用程序中的病毒或恶意代码影响的任意其他实体、或者希望控制访问敏感API的任意其他实体、以及任意上述实体的代表。

从代码签名中心方面看，任意给定的软件应用程序开发者(或希望使其应用程序被签名的其他个人或实体)最初都是不被信任的客户。在软件应用程序开发者和代码签名中心之间建立信任关系之前，代码签名中心通常拒绝向从软件应用程序开发者接收到的软件应用程序进行签名使得可以访问敏感API。只有在与软件应用程序建立了信任的关系之后，代码签名中心才可能愿意签名软件应用程序，代码签名中心然后能够追踪哪些API被准予访问了，以及已经准予了哪些软件应用程序开发者。

因此，在一个实施例中，一种提供代码签名服务的方法包括至少一些涉及注册实体的步骤，所述实体要求访问由代码签名中心控制的敏感API。执行这些步骤，以便与那些实体建立信任的关系。提供代码签名服务的方法可以包括涉及接收和处理来自这些实体的代码签名请求的附加步骤。

关于代码签名中心做出的实体注册，如果由于当软件应用程序在计算设备上执行时所展示的行为，而可以在软件应用程序中发现并怀疑任意破坏性的或有问题的代码，则可以中止或撤销对应软件应用程序开发者(或其它注册的个人或实体)对代码签名中心的注册权限。这是可能的，因为由代码签名中心附加到应用程序的数字签名提供了跟踪记录，通过其可以识别有问题的软件应用程序开发者。

例如，可以通过被配置用于定期下载撤销列表，将这种注册的撤销通知计算设备。如果已经撤销的对应数字签名的软件应用程序正运行在特定的计算设备上，则该设备可以暂停任意此类软件应用程序的执行，并且可能从其本地存储器中清除软件应用程序。例如，也可以将设备配置成定期地或当下载了新的撤销列表时，重新执行数字签名验证。

在某些实施例中，代码签名中心可以不提供撤销列表等。代码签名中心可以追踪在任意给定的时间软件应用程序开发者(或者其它注册的个人或实体)可以或不可以使其应用程序被签名，并且自行处理废除开发者的签名权限。在一个示例实施方式中，一旦代码签名中心已经签名了应用程序，即使相关开发者的签名权限随后被废除，应用程序也将保持有效性。然而在已经废除了开发者的签名权限之后由该开发者做出的签名应用程序的随后请求将被拒绝。

参考图7A，示出了在一个实施例中提供代码签名服务的方法的步骤的流程图大体上如400所示。

尽管作为示例参考移动设备大体上描述了该实施例，不同的实施例对于其他计算设备也是适用的。此外，尽管参考在代码签名中心和软件应用程序开发者之间信息交换，大体上描述了该实施例，但是在代码签名中心和不同于软件应用程序开发者的个人或实体之间交换信息的情况下，上述实施例也是适用的。

参考如由代码签名中心所执行的方法400的步骤，在典型的实施方式中由软件应用程序执行该步骤，所述软件应用程序已经被编程序来执行方法400的步骤，除非另有说明。在该说明书以及所附权利要求中，将编程用于执行方法400的步骤的软件应用程序称为代码签名中心应用程序。

代码签名中心应用程序是用于提供在由代码签名中心(例如图4的代码签名中心306)所持有的计算设备上执行的代码签名服务的系统的一个组件。在一个实施例中，图7B的示例网络配置450示出了用于提供代码签名服务的系统。在该示例中，在计算设备454上执行代码签名中心应用程序452，所述计算设备454在示例网络450中是网络服务器。例如，代码签名中心应用程序452通过经由因特网458可访问的网络接口456，与网络450中的客户进行交互。

代码签名中心应用程序452可以与之进行交互的客户可以包括：例如在远程计算设备上执行的签名工具应用程序460以及API著作工具应用程序462。可以由需要由代码签名中心签名应用程序的软件应用程序开发者(例如图4的软件应用程序开发者302)将签名工具应用程序460用于向代码签名中心应用程序452通信数据和应用程序。可以由需要从代码签名中心获得一个或多个签名公钥的敏感API的作者使用API著作工具应用程序462来保护API。

应该理解的是，在一些实施例中，敏感API的作者也可以担当代码签名中心。

代码签名中心应用程序452还可以访问至少一个客户信息数据库464以及至少一个签名私钥存储器466。客户信息数据库464以及签名私钥存储器466中的数据可以被存储在相同的存储设备上，或者被分发到不一定物理地常驻在计算设备454上的多个存储设备。

本领域的技术人员应该理解的是，仅作为示例提供图7B中所示的组件，并且在不同的实施方式中，除在图7B中所示的那些之外，计算设备454一般还包括其他组件，并且可以包括不同的组件。

再参考图7A，在从软件应用程序开发者接收到代码签名注册请求和代码签名请求之前(这将参考方法400的其它步骤详细地进行描述)，首先需要产生私钥/公钥对，使得可以将公钥附加到通过将其分类为敏感而要进行保护的API(例如类)。可以由代码签名中心本地地存储私钥(例如在图7B的私钥存储器466中)，以便随后使用。因此，在涉及代码签名的任意步骤之前执行的步骤410中，代码签名中心应用程序创建了针对代码签名中心想要控制访问的API的私钥/公钥对。例如，可以针对要保护的各个敏感API，产生密钥对，或将相同的密钥对应用于多个API。作为另外的示例，可以针对不同设备上的API或相同类型设备的不同型号上的API，产生不同的密钥对。下面参考图8A至图8C，详细地描述关于示例实施例的步骤410。

参考图8A，在一个实施例中，提出了一种用于确定和显示由计算设备上的随机数据服务所产生的随机数的随机性质量的装置。应该理解的是，例如当将公钥密码系统用于产生密钥对时，需要用于密钥产生的良好来源的随机数。一般地，数字越随机，所产生的密钥将越强大。随机数的良好来源产生对于潜在敌人来说未知的并且不可预知的数字。原则上，从物理过程中推导出的随机数可能是最好的，因为许多物理过程呈现出真正的随机性。

在该实施例中，提供随机数据服务，使其可访问用于产生公钥/私钥对的代码签名中心应用程序。随机数据服务可以收集从几个不同来源推导出的随机数据，所述来源包括例如：串行端口、窗口密码API、键盘和鼠标事件、以及硬件标志。随机数据服务适于提供三种基本功能：收集随机数据、向请求随机数据的应用程序提供随机数据、以及提供已收集的随机数据的随机性质量的测量。

在步骤411中，确定由随机数据服务提供的数据的随机性质量。在该实施例中，可以由随机数据服务连续地收集在请求时能提供的随机数据。例如，在随机数据服务执行的同时，可以连续地产生预定义大小块(例如20000字节的块)的随机数据。在该步骤中，评价已产生的随机数据(例如频繁地、通过以某个间隔(例如每次0.5s)查询随机数据)，并且可以将统计的随机性测试应用于随机数据块的序列。已知各种随机性测试(例如联邦信息处理标准(FIPS)测试、FIPS 140-2)，并且可以应用一个或多个此种测试，以便于确定产生的随机数据的质量。

取决于所使用的随机性测试以及该随机性测试提供结果的方式，可以将每个结果与随机性质量的多个预定义定性测量之一建立映射。例如，随机数据服务可以应用预定义的映射，以便在任意给定时间以满足下面状态之一来指示随机性质量：未知的、不可接受的、差的、可接受的、好的、优秀的、错误的。在步骤412中，可以向代码签名中心应用程序的用户(例如代码签名中心的管理员)显示随机性质量的指示。

尽管可以使用上述状态之一的名称来显示随机性质量的指示，但是也可以使用不同的标识符。在不同的实施例中，也可以将这些状态进一步地映射到更少数目的集合状态，每个状态由描述性标识符标识。

例如，在一个实施例中，由交通灯图标的颜色表示随机性质量，其在步骤412中能够被显示在用户接口中。这种表示随机性质量的方式是直观的而且对于用户来说是易于理解的。绝大多数用户对交通灯图标是熟悉的，并且该图像能够被用于描述将要被用于创建针对代码签名应用程序的密钥对的数的随机性的当前质量。

交通灯图标被用于阐明随机性质量的当前水平，并且能够基于当前水平来显示三种颜色之一(例如红色、黄色、绿色)。红色代表因为随机性质量非常差、或因为随机性质量不能被验证为好的而不应该创建密钥的状态。黄色代表质量是差的、并且在特别注意安全的应用程序中不推荐产生密钥的状态。绿色代表随机性质量是好的、并且告知用户创建密钥是相对安全的状态。

上述七种初始状态与交通灯图标颜色的一个可能的映射可以如下所示：

红色：{未知的、不可接受的、错误的}

黄色：{差的}

绿色：{可接受的、好的、优秀的}

本领域的技术人员应该理解的是，可以在不同的实施例中定义其他初始状态设置和其它的映射状态设置，并且如何对其进行预定义可以取决于所使用的特定的随机性测试。

在图8B中示出了显示交通灯图标的用户界面的示例对话框。也可以与所示出的交通灯图标一起，显示描述性标识符(例如基于七种初始步骤之一，或与被显示的灯的颜色相应的不同标识符)。也可以以其他方式向用户呈现交通灯图标的颜色。例如，可以在工具栏的缩微图中显示显示颜色或仅仅着色圆圈的交通灯图标。

在步骤412中显示了随机性质量的指示符之后，代码签名中心应用程序的用户可以命令应用程序创建用于签名的密钥对(例如通过点击在图8B中所示的对话框的“创建密钥对”按钮)。在这种情况下，从用户接收指令以便创建密钥对。在一个实施例中，用户可以选择创建密钥对，无论交通灯图标所示的状态如何。然而，在不同的实施例中，当示出“红色灯”和/或“黄色灯”时，可以禁用显示给用户的用于创建密钥的选项。此外，在不同的实施例中，尽管示出“红色灯”和/或“黄色灯”，如果接收到创建密钥的指令，可以询问用户以确定其选择。

在步骤414中，以已知的方式(例如使用RSA算法)创建私钥和对应公钥。在步骤415中，由代码签名中心存储私钥(例如在图7B的私钥存储器466中)，以便将来使用，并且配置公钥。可以将公钥附加到代码签名中心希望保护的敏感API，或可以将公钥存储在库中，当要求签名验证时所述库对于在计算设备上执行的代码签名系统组件是可用的。在图8C中，示出了示例对话框，其中代码签名中心应用程序的用户可以向API作者发送已创建的公钥(例如经由图7B的API著作工具462)，以便将其嵌入到API中，来保护这些API。

本领域的技术人员应该理解的是，可以在适于使用随机数产生除了用于代码签名的密钥对之外的对象的其他应用程序中，实现在图8A的描述中提到的例如包括可显示交通灯图标的特征。例如，可以在产生个人身份号码(PIN)的应用程序或在产生会话密钥(例如用于根据对称加密算法来加密数据)的应用程序中使用这些特征。

再次参考图7A，在步骤410中已经创建与敏感API相关联的一个或多个公钥之后，当软件应用程序开发者开发需要访问已经被分类为敏感的API的应用程序时，执行方法400的后继步骤。在步骤420中，由代码签名中心应用程序从希望访问敏感API的软件应用程序开发者接收到注册请求。然后处理该注册请求，以及确定是否应该接收注册请求。参考图9，关于示例实施例来详细地描述步骤420。

在图9中，根据一个实施例提出了一种针对代码签名服务来注册实体的方法。在参考图7A至图9描述的示例中，该实体是软件应用程序开发者，尽管其也可以是一些其他个人或实体。使用已知手段(例如通过因特网网站)，可以使软件应用程序开发者获得对于软件应用程序开发者的关于如何向代码签名中心注册的指导。

在步骤421中，由代码签名中心应用程序从软件应用程序开发者(“API客户”)接收注册请求。注册请求包括可以由代码签名中心用以验证软件应用程序开发者身份的信息。该信息可以包括典型的身份信息(例如联系信息)，并且还可以包括能够由代码签名中心所验证的信用卡信息。例如，可以通过多个不同通信频带中的任意一个来接收该信息。例如，可以经由例如安全套接层(SSL)网络形式来交换数据。

在步骤422中，验证从软件应用程序开发者接收到的信息。例如，可以联系信用卡公司(例如用电子方法或另外的方法)来验证已接收的信用卡信息。

如果验证是不成功的，返回错误消息(步骤428)。另一方面，如果成功地验证了信息(例如，如果成功地验证了所提供的信用卡信息)，在步骤423中，由代码签名中心应用程序产生了唯一的客户ID和PIN。可以创建用于保存客户ID、PIN、以及与特定的软件应用程序开发者相关的其他信息的账户记录，以存储在由代码签名中心持有以及代码签名中心应用程序可访问的客户信息数据库(例如图7B的客户信息数据库464)中。

在不同的实施例中，在步骤423中，可以由软件应用程序开发者而不是代码签名中心来产生PIN和/或客户ID，并且与代码签名中心共享以存储。

在创建与软件应用程序开发者有关的账户记录时，例如，也可以向账户记录填充可以用于管理软件应用程序开发者的账户的其他信息，以便追踪账户的活动，以及当发生账户活动时向特定一方提供指示。在一个实施例中，当针对给定的软件应用程序开发者创建了账户记录时，可以向代码签名中心应用程序的用户(例如代码签名中心的管理员)提供使各种详情和限制与软件应用程序开发者的账户相关联的表格(例如经由如图7B中所示的用户接口468)。在图10中示出了账户记录中可以由代码签名中心应用程序的用户更新的详情的示例表格。账户记录的一些详情可以自动地用预定义的缺省值来填充。

例如，可以被保存在与软件应用程序开发者相关的账户记录中的详情包括需要向特定的电子邮件地址(例如“到达”地址、“抄送”地址、“转发”地址等)发送电子邮件通知的数据。当尝试进行注册时、当做出代码签名请求时、当在处理注册尝试或代码签名请求时发生错误时、和/或当检测到发生任意非法(irregular)行为(象可以在代码签名中心应用程序中定义的那样)时，也可以设置标记以便向特定的地址发送电子邮件通知。当一些其他预定义的事件发生时，也可以设置标记以便发送电子邮件通知。电子邮件通知使软件应用程序开发者、管理员、或其他人员来监测账户(它们自己的账户或其它账户)，以及尤其是观察在账户下是否做出未授权的代码签名请求或注册尝试。

可以保存在账户记录中的其他详情可以包括：指示出有效期限与账户相关的标记、以及相关的有效期限的设置。例如，可以由代码签名中心的管理员设置这些详情。

可以被保存在账户记录中的其他详情可以包括：指示出账户仅被准予特定数目的容许代码签名请求以及容许代码签名请求的相关数目的设置。例如，可以由代码签名中心的管理员设置这些详情。这可以便于由代码签名中心提供“按使用收费(pay-per-use)”的代码签名服务。因此，在一个示例实施方式中，仅仅只要软件应用程序开发者的账户没有过期并且还有容许代码签名请求(例如信用卡)，软件应用程序开发者就能够使应用程序被签名。

在步骤424中，将客户ID和PIN、以及可能的其他注册数据发送到软件应用程序开发者。尽管步骤421中通过第一通信频带(例如SSL连接)接收到注册请求中的信息，并且在步骤424中可以通过相同的通信频带将客户ID和其他注册数据(除PIN之外)发送回软件应用程序开发者，然而，在一个实施例中，可以使用带外通信装置(例如通过电话、通过传真等)来将PIN传送到软件应用程序开发者。该带外通信装置与在步骤424中用来向软件应用程序开发者发送客户ID和其他注册数据的通信频带不同。

在之前提到的各种实施例中，其中由软件应用程序开发者而不是代码签名中心产生PIN和/或客户ID，则在步骤424中可以确认或拒绝该外部产生的PIN和/或客户ID的使用。如果拒绝了该特殊的PIN和/或客户ID的使用，可以向软件应用程序开发者返回错误消息(流程前进到步骤428，未示出)。

在步骤425中，由代码签名中心应用程序从软件应用程序开发者接收注册文件，这构成了软件应用程序开发者做出的实际注册尝试。注册文件包括在步骤424中发送给软件应用程序开发者的客户ID和PIN、与仅仅软件应用程序开发者期待拥有的私钥对应的公钥、以及可能的其他数据。在一个实施例中，经由SSL连接接收注册文件。

为更加清楚起见，在步骤425中提到的公钥/私钥对与如关于图4所描述的产生以用于签名和验证软件应用程序的公钥/私钥对是不相干的。而是，在步骤425中从软件应用程序开发者接收的公钥是用于在软件应用程序开发者和第三方之间交换编码消息以利于安全通信的私钥/公钥对(例如已经由认证中心发出的密钥对)的一部分。在上下文中，代码签名中心应用程序随后能够使用用于安全通信的公钥来验证消息，例如从软件应用程序开发者接收的代码签名请求。事实上，可以使用安全通信的软件应用程序开发者的私钥数字地签名在步骤425中所接收的注册文件本身。

在步骤425中接收的注册文件不仅包含在步骤424中通过第一通信频带发送到软件应用程序开发者的客户ID，而且包含根据示例实施例通过第二(带外)通信装置传送到软件应用程序开发者的PIN。通过使用不同的通信信道来向软件应用程序开发者发送注册详情，存在较低的使第三方可以知道客户ID和与该客户ID有关的正确PIN的风险。

当在步骤425中接收了客户ID以及与该客户ID有关的正确PIN、并且在步骤426中由代码签名中心成功地验证了客户ID以及与该客户ID有关的正确PIN(即在注册文件中的客户ID和PIN与存储在客户信息数据库的适当账户记录中的软件应用程序开发者的客户ID以及相关PIN相匹配)时，则可以安全地设想：伴随着接收到的注册文件的用于安全通信的公钥事实上确实与由软件应用程序开发者所拥有的安全通信的私钥相对应。代码签名中心随后能够使用公钥来验证声称来源于软件应用程序开发者的消息，并且因此使用公钥密码术来编码此种消息在通信中提供了增强的安全性。特别地，这里存在较低的使第三方通过使用所截取的客户ID和PIN以及其自己的公钥能够完成错误注册的风险。

在各种实施例中，可以将除PIN之外的不同信息通过优选为“带外”通信装置的第二通信装置发送到软件应用程序开发者。然而，在这些不同的实施例中，由代码签名中心所验证的信息应该还包括通过一个通信装置被发送到软件应用程序开发者的一些详情，以及通过一些其他通信装置被发送到软件应用程序开发者的一些详情，使得可以实现至少一些上述优点。

在一个实施例中，作为更进一步的安全措施，代码签名中心应用程序适于跟踪不利于(against)任意给定软件应用程序开发者账户的注册尝试的数目。在不利于账户的不成功的注册尝试的数目达到预定义的数目之后，可以禁用该账户。这是为了避免对代码签名中心应用程序和软件应用程序开发者之间共享的PIN的暴力破解(brute forceattack)。

如之前所述的，在步骤426中代码签名中心尝试对注册文件的验证(例如通过将已接收的客户ID和PIN与保存在对应账户记录中的那些相匹配)，并且如果验证是成功的则做出确定。倘若如此，则在步骤427中更新与软件应用程序开发者相关的账户记录以便反映成功的注册；否则，在步骤428中将错误消息返回到软件应用程序开发者。特别地，在步骤427中，例如，可以利用在步骤425中接收到的公钥来更新账户记录。该公钥被存储在客户信息数据库中的软件应用程序开发者的账户记录中，并且可以被用于在未来验证包括代码签名请求的通信，可以由代码签名中心应用程序从软件应用程序开发者接收所述代码签名请求。

再参考图7A，在步骤420中成功地注册软件应用程序开发者之后，然后通常由软件应用程序开发者提交软件应用程序，用于向代码签名中心签名。

在步骤430中，从请求者接收到代码签名请求，在该示例中所述请求者是软件应用程序开发者。例如，代码签名请求可以包括与软件应用程序开发者的账户以及要签名的应用程序相关的客户ID。在一个实施例中，软件应用程序开发者的数字签名伴随着代码签名请求，其中已经使用软件应用程序开发者的私钥签名了所述代码签名请求。这利于软件应用程序开发者的身份的认证。

在步骤440中，代码签名中心应用程序验证在步骤430中所接收的代码签名请求是已注册的软件应用程序开发者所做出的有效请求。例如，该步骤可以包括：获得与已接收的客户ID有关的公钥，以及验证附加到代码签名请求的数字签名；确认客户ID所标识的账户还没有到期；以及确认存在指示出对于该账户仍然有容许代码请求的足够的信用。

如果确定是做出了有效的请求，则在步骤470中，更新与由客户ID所标识的账户相关的账户记录。例如，这可以包括减少剩下的容许代码签名请求的数目。在一些实施例中，也可以将涉及请求的信息保存在日志中，可以将所述日志存储在客户信息数据库(例如图7B的464)或一些其他的存储设备上。

在步骤472，可以根据账户记录中的设置，将通知电子邮件发送到在账户记录中所标识的地址。

在步骤474中，代码签名中心使用针对代码签名而创建的签名私钥(例如如在步骤410中创建的并且存储在图7B的私钥数据库466中的)来签名应用程序。在步骤474中还将数字签名返回到软件应用程序开发者，使得可以将数字签名附加到应用程序中，所述应用程序已经被编程以访问利用对应的签名公钥所保护的敏感API。在该步骤中，也可以配置代码签名中心应用程序以用于向其他方转发包含数字签名的文件。

在代码签名中心可以控制访问由不同的签名公钥所保护的不同API的实施例中，可以在代码签名请求中包括需要产生的数字签名的指示，并且可以在步骤474中将适当的签名私钥相应地用于签名应用程序。

如果在步骤440中确定没有做出有效的请求，则在步骤480中返回错误消息。在该步骤中，取决于账户设置，可以发送通知电子邮件。

应该理解的是，由代码签名中心应用程序的用户(例如管理员)采取的行动，例如包括账户记录的修改或代码签名密钥对创建的发起，可以是以用户密码的成功验证、或一些其他访问控制机制的提供为条件的。

应该理解的是，在从相同的软件应用程序开发者接收到多个代码签名请求的情况下，可以重复步骤430至480，以及在向多个软件应用程序开发者提供代码签名服务的情况下，可以重复步骤420至480。

尽管在这里描述的至少一些实施例中，由代码签名中心产生的数字签名取决于软件应用程序开发者的认证以及对软件应用程序开发者已经被正确地注册的确认，应该理解的是，数字签名是从应用程序的散列或其它变换版本中产生的，因而是应用程序专用的。这与一些已知的代码签名方案形成对比，已知方案中，准予从可信任的软件应用程序开发者或作者接收到的所有软件应用程序进行API访问，而不考虑正要被签名的特定应用程序。在这里所描述的系统和方法的实施例中，根据不同应用程序来准予对API的访问，并且因此更严格地控制和管理对API的访问。

在这里描述的至少一些实施例中，代码签名中心从软件应用程序开发者接收软件应用程序，用于利用代码签名请求来签名。一旦认证了代码签名请求者的身份并且已经验证了请求者某些的账户信息，则由代码签名中心签名应用程序。应用程序的签名典型地包括由代码签名中心产生散列(或软件应用程序的其它变换版本)，以及随后使用适当的签名私钥对散列进行编码。

然而，在另一个实施例中，并没有作为代码签名请求的一部分而接收要由代码签名中心签名的应用程序。而是和代码签名请求一起接收到散列(或软件应用程序的其它变换版本)，其中散列是由不同于代码签名中心的个人或实体，例如软件应用程序开发者本身，使用如果由代码签名中心接收到实际要签名的应用程序则代码签名中心本来会使用的散列算法相同的散列算法，而产生的。然后由代码签名中心使用适当的私钥对散列进行编码(经过账户验证)。因为在该实施例中原始的应用程序从不会由代码签名中心接收到，软件应用程序开发者不需要担心泄漏机密的算法或数据。此外，因为将与应用开发程序相关的任意风险留给了软件应用程序开发者来处理，代码签名中心可以从中受益。例如，代码签名中心典型地不必检查或验证代码的完整性，或确保遵守了保密规则，因为其从不接收要签名的实际应用程序。该技术也减少了当处理代码签名请求时代码签名中心应用程序需要处理的数据量。

可以将这里描述的一个或多个方法的步骤提供为存储在计算机可读媒质上的可执行软件指令，所述计算机可读媒质可以包括传输型媒质。

尽管已关于多个实施例描述了本发明，本领域的技术人员可以理解，在不脱离如在所附权利要求所限定的本发明范围的情况下，可以对这些实施例进行其他改变和改进。

Claims (16)

1.一种提供代码签名服务的方法，所述方法包括步骤：

创建公钥和私钥，其中公钥和私钥与敏感应用程序接口相关联，所述敏感应用程序接口是被分类为敏感的应用程序接口；

配置公钥并存储私钥；

针对代码签名服务来注册实体；

从请求者接收对软件应用程序或其散列进行签名的代码签名请求，该软件应用程序在计算机上运行时访问所述敏感应用程序接口，所述请求者是注册步骤所注册的实体，其中代码签名请求包括请求者请求用所述私钥来签名的软件应用程序或其散列；

对该软件应用程序或其散列进行数字签名，其中数字签名是使用所述私钥所产生的；

将所述数字签名发送到所述请求者；

其中注册步骤包括：

从请求针对代码签名服务来注册的实体接收注册请求，其中所述注册请求包括与所述实体的身份相关的数据；

通过验证所述注册请求中的所述数据的至少子集，来认证实体的身份；

产生针对实体的账户记录，其中所述账户记录包括与所述实体相关的至少第一和第二标识符；

经由第一通信信道向所述实体发送第一标识符和第二标识符中的一个，以及经由不同的第二通信信道向所述实体发送第一标识符和第二标识符中的另一个；

从所述实体接收注册文件；以及

在接收所述注册请求之前，确认所述注册文件至少包括第一和第二标识符两者；

其中，在接收代码签名请求之前执行所述注册步骤。

2.如权利要求1所述的方法，其中，第一标识符是客户ID，以及第二标识符是PIN。

3.如权利要求2所述的方法，还包括产生客户ID以及PIN的步骤。

4.如权利要求2所述的方法，其中，客户ID以及PIN中的至少一个是由实体产生的，并且被包括在注册请求中。

5.如前述权利要求中任意之一所述的方法，其中，与实体的身份相关的数据包括与实体相关的信用卡信息，以及认证实体身份的步骤包括验证所述信用卡信息。

6.如权利要求1-4中任意之一所述的方法，其中，第一通信信道是SSL连接。

7.如权利要求1-4中任意之一所述的方法，其中，第二通信信道是电话和传真之一。

8.如权利要求1-4中任意之一所述的方法，其中，注册文件包括与实体相关的公钥，以及所述方法还包括步骤：存储公钥，以用于将来使用，其中公钥被用于验证从实体接收到的数字签名。

9.一种提供代码签名服务的系统，包括：

用于创建公钥和私钥的装置，其中公钥和私钥与敏感应用程序接口相关联，所述敏感应用程序接口是被分类为敏感的应用程序接口；

用于配置公钥的装置和用于存储私钥的装置；

用于针对代码签名服务来注册实体的装置；

用于从请求者接收对软件应用程序或其散列进行签名的代码签名请求的装置，该软件应用程序在计算机上运行时访问所述敏感应用程序接口，所述请求者是所注册的实体，其中代码签名请求包括请求者请求用私钥来签名的软件应用程序或其散列；

用于对该软件应用程序或其散列进行数字签名的装置，其中数字签名是使用所述私钥所产生的；

用于将所述数字签名发送到所述请求者的装置；

其中，用于注册的装置包括：

用于从请求针对代码签名服务来注册的实体接收注册请求的装置，其中所述注册请求包括与所述实体的身份相关的数据；

用于通过验证所述注册请求中的所述数据的至少子集，来认证实体的身份的装置；

用于产生针对实体的账户记录的装置，其中所述账户记录包括与所述实体相关的至少第一和第二标识符；

用于经由第一通信信道向所述实体发送第一标识符和第二标识符中的一个，以及经由不同的第二通信信道向所述实体发送第一标识符和第二标识符中的另一个的装置；

用于从所述实体接收注册文件的装置；以及

用于在接收所述注册请求之前，确认所述注册文件至少包括第一和第二标识符两者的装置；

其中，在接收代码签名请求之前针对代码签名服务来注册所述实体。

10.如权利要求9所述的系统，其中，第一标识符是客户ID，以及第二标识符是PIN。

11.如权利要求10所述的系统，还包括产生客户ID以及PIN的装置。

12.如权利要求10所述的系统，其中，客户ID以及PIN中的至少一个是由实体产生的，并且被包括在注册请求中。

13.如前述权利要求中任意之一所述的系统，其中，与实体的身份相关的数据包括与实体相关的信用卡信息，以及认证实体身份的装置包括验证所述信用卡信息的装置。

14.如权利要求9-12中任意之一所述的系统，其中，第一通信信道是SSL连接。

15.如权利要求9-12中任意之一所述的系统，其中，第二通信信道是电话和传真之一。

16.如权利要求9-12中任意之一所述的系统，其中，注册文件包括与实体相关的公钥，以及所述系统还包括：存储公钥以用于将来使用的装置，其中公钥被用于验证从实体接收到的数字签名。

Images