带有安全需求的应用程序的构建方法和装置

1、一种带有安全需求的应用程序的构建方法，包括以下步骤：
A、将源程序中嵌入应用逻辑第一安全需求检查点的第一安全需求代码段 转换为所述源程序生成的可执行文件中独立于应用逻辑部分的第一安全需求 部分；
B、在可执行文件的应用逻辑部分中与源程序第一安全需求检查点对应的 入口点，链接安全实现逻辑并向其传递第一安全需求部分在所述可执行文件中 所处位置的信息；
C、所述应用逻辑部分运行到所述对应的入口点时，调用所述安全实现逻 辑根据收到的位置信息找到第一安全需求部分并按其安全需求对运行环境进 行检测。
2、如权利要求1所述的方法，其特征在于步骤A进一步包括：对第一安 全需求代码段进行有效性和一致性检查，通过检查后将第一安全需求代码段转 换成第一安全需求部分。
3、如权利要求1所述的方法，其特征在于采用可扩展置标语言XML定义 的元素来描述下述类型代码段中至少一种代码段：
源程序中嵌入应用逻辑的安全需求代码段；
源程序中安全需求代码段转换后的可执行文件中安全需求部分。
4、如权利要求1所述的方法，其特征在于第一安全需求部分是所述可执 行文件中一个安全数据节所包括的至少一个安全需求段之一。
5、如权利要求4所述的方法，其特征在于第一安全需求部分在所述可执 行文件中所处位置的信息是第一安全需求部分对应的段头在安全数据节的段 头表中的索引号。
6、一种带有安全需求的应用程序的构建装置，包括存储器和至少一个保 存在存储器中的应用程序源代码，其特征在于还包括安全编译器和安全需求解 释器，
所述安全编译器进一步包括：安全需求部分转换模块，用于将源程序中嵌 入应用逻辑第一安全需求检查点的第一安全需求代码段转换为所述源程序生 成的可执行文件中独立于应用逻辑部分的第一安全需求部分；安全需求解释器 链接模块，用于在可执行文件的应用逻辑部分中与源程序第一安全需求检查点 对应的入口点，链接安全需求解释器并向其传递第一安全需求部分在所述可执 行文件中所处位置的信息；
所述安全需求解释器进一步包括：
位置信息接收模块，用于接收安全编译器传递来的位置信息；
安全需求部分查找模块，用于根据位置信息接收模块收到的位置信息在可 执行文件中查找第一安全需求部分；
安全需求部分分析模块，用于对安全需求部分查找模块找到的第一安全需 求部分进行分析；
安全检测模块，用于根据安全需求部分分析模块的分析结果对运行环境进 行检测。
7、如权利要求6所述的装置，其特征在于安全编译器还包括有效性与一 致性检查模块，用于对第一安全需求代码段进行有效性和一致性检查，通过检 查后将第一安全需求代码段传递给安全需求部分转换模块。
8、如权利要求6所述的装置，其特征在于第一安全需求部分是所述可执 行文件中一个安全数据节所包括的至少一个安全需求段之一。
9、如权利要求8所述的装置，其特征在于第一安全需求部分在所述可执 行文件中所处位置的信息是第一安全需求部分对应的段头在安全数据节的段 头表中的索引号。
10、如权利要求6所述的装置，其特征在于采用可扩展置标语言XML定 义的元素来描述下述类型代码段中至少一种代码段：
源程序中嵌入应用逻辑的安全需求代码段；
源程序中安全需求代码段转换后的可执行文件中安全需求部分。

技术领域\n本发明涉及计算机软件技术，尤其涉及一种安全应用程序(PE应用程序) 的构建方法和装置。\n背景技术\n当前，可移植的执行体(PE，Portable Executable)文件格式应用于所有版 本的Windows 32位系统，包括Windows 9x、Windows NT、Windows 2000和 Windows XP等。它是Win32环境中执行体(EXE或DLL)的文件格式。\nPE文件格式如图1所示，包括DOS部首(DOS Head)、PE文件头(PE Header)、节表(section table)、节(Section)和调试信息。\nDOS部首位于PE文件的文件首，包括DOS MZ header和DOS Stub。有 了DOS MZ header，一旦程序在DOS下执行，DOS就能识别出这是有效的执 行体，然后运行紧随MZ Header之后的DOS Stub。\nPE Header紧接着DOS Stub。它是一个IMAGE_NT_HEADERS结构。 其中包含了很多PE文件被载入内存时需要用到的重要域。\nPE Header接下来是数组结构的节表(Section Table)。如果PE文件里有5 个节，那么此Section Table结构数组内就有5个成员，每个成员包含对应节 的属性、文件偏移量、虚拟偏移量等。\n节表(Section Table)之后是PE文件的真正内容，它划分成块，称之为节 (sections)。每节是一块拥有共同属性的数据，比如代码/数据、读/写等。Sections 是以其起始位置来排列，而不是以其字母次序来排列。通过节表提供的信息， 我们可以找到这些节。常见的Sections包括：\n.arch最初的构建信息(Alpha Architecture Information)\n.bss未经初始化的数据\n.CRT C运行期只读数据\n.data已经初始化的数据\n.debug调试信息\n.didata延迟输入文件名表\n.edata导出文件名表\n.idata导入文件名表\n.pdata异常信息(Exception Information)\n.rdata只读的初始化数据\n.reloc重定位表信息\n.rsrc资源\n.text.exe或.dll文件的可执行代码\n.tls线程的本地存储器\n.xdata异常处理表\n其中.text节存储着程序的执行代码，实现着程序逻辑。目前，对于有安全 要求的程序，其安全逻辑也是在此节中实现。安全需求和安全逻辑的实现都嵌 入到应用程序具体实现逻辑中。应用程序的实现依赖于软件的设计和代码的编 写，对于不同的设计人员和不同的编程人员，针对安全需求的考虑和对安全逻 辑的实现会出现不同；同时在应用逻辑中实现复杂的安全逻辑，实现起来也相 对较难，会出现不稳定性和不可测性；PE文件格式中没有能描述应用程序安 全需求和安全逻辑实现的标准的程序框架，不能给安全程序提供较一致的安全 程序构建方法，因此不能缩短开发周期、提高可靠性。\n发明内容\n基于目前PE格式的应用程序，如果对安全方面有要求，相关的安全需求 和安全实现逻辑都会由应用程序设计人员进行设计，由编码人员进行编码，这 制约了安全程序的构建，不规范不可靠，增加设计和开发的工作量，延长开发 周期。为了解决这方面的问题，本发明基于PE文件格式，提供一种具有描述 安全需求、实现安全逻辑的通用架构的安全程序的构建方法和装置。\n一方面，提出一种带有安全需求的应用程序的构建方法。该方法包括步骤： A、将源程序中嵌入应用逻辑第一安全需求检查点的第一安全需求代码段转换 为该源程序生成的可执行文件中独立于应用逻辑部分的第一安全需求部分；B、 在可执行文件的应用逻辑部分中与源程序第一安全需求检查点对应的入口点， 链接安全实现逻辑并向其传递第一安全需求部分在该可执行文件中所处位置 的信息；C、该应用逻辑部分运行到该对应的入口点时，调用该安全实现逻辑 根据收到的位置信息找到第一安全需求部分并按其安全需求对运行环境进行 检测。\n上述步骤A进一步包括：对第一安全需求代码段进行有效性和一致性检 查，通过检查后将第一安全需求代码段转换成第一安全需求部分。\n上述方法中，采用可扩展置标语言XML定义的元素来描述以下类型代码 段中至少一种代码段：\n源程序中嵌入应用逻辑的安全需求代码段；\n源程序中安全需求代码段转换后的可执行文件中安全需求部分。\n上述方法中，第一安全需求部分是该可执行文件中一个安全数据节所包括 的至少一个安全需求段之一。\n上述方法中，第一安全需求部分在所述可执行文件中所处位置的信息是第 一安全需求部分对应的段头在安全数据节的段头表中的索引号。\n另一方面，提出一种带有安全需求的应用程序的构建装置。该装置包括存 储器和至少一个保存在存储器中的应用程序源代码，还包括安全编译器和安全 需求解释器。该安全编译器进一步包括：安全需求部分转换模块，用于将源程 序中嵌入应用逻辑第一安全需求检查点的第一安全需求代码段转换为该源程 序生成的可执行文件中独立于应用逻辑部分的第一安全需求部分；安全需求解 释器链接模块，用于在可执行文件的应用逻辑部分中与源程序第一安全需求检 查点对应的入口点，链接安全需求解释器并向其传递第一安全需求部分在该可 执行文件中所处位置的信息。该安全需求解释器进一步包括：位置信息接收模 块，用于接收安全编译器传递来的位置信息；安全需求部分查找模块，用于根 据位置信息接收模块收到的位置信息在可执行文件中查找第一安全需求部分； 安全需求部分分析模块，用于对安全需求部分查找模块找到的第一安全需求部 分进行分析；安全检测模块，用于根据安全需求部分分析模块的分析结果对运 行环境进行检测。\n上述安全编译器还包括有效性与一致性检查模块，用于对第一安全需求代 码段进行有效性和一致性检查，通过检查后将第一安全需求代码段传递给安全 需求部分转换模块。\n上述第一安全需求部分是该可执行文件中一个安全数据节所包括的至少 一个安全需求段之一。\n上述第一安全需求部分在该可执行文件中所处位置的信息是第一安全需 求部分对应的段头在安全数据节的段头表中的索引号。\n上述装置中，采用可扩展置标语言XML定义的元素来描述以下类型代码 段中至少一种代码段：\n源程序中嵌入应用逻辑的安全需求代码段；\n源程序中安全需求代码段转换后的可执行文件中安全需求部分。\n本发明主要的优点和特点如下：\n具有通用架构的安全程序的构建方法和装置将安全需求和安全逻辑从应 用程序中分离出来，提高到一个通用的层面，由比应用程序更低层的相关软件 层面实现，这些更低的软件层面主要由操作系统(Operating System)供应商、 开发工具供应商等实现，大大规范了安全程序的实现流程，减少了有安全需求 的应用程序的开发工作量，提高软件的可靠性和可移植性。\n附图说明\n图1示出PE文件的框架结构；\n图2示出PE文件增加.secure节那部分架构；\n图3示出安全需求分段；\n图4示出.secure节采用的结构；\n图5示出带安全需求的应用程序源程序；\n图6是应用程序源程序中的安全需求描述转化为安全需求段的过程示意 图；\n图7是安全编译器的处理过程示意图；\n图8是安全需求解释器的处理过程示意图。\n具体实施方式\n在PE格式的文件中，根据数据属性的不同分成很多节(sections)，比如 保存程序代码的.text节、保存资源的.rsrc节等。为了实现将安全需求和安全实 现逻辑从应用程序中分离出来，在PE文件中加入一个.secure节，用来保存应 用程序对运行环境的安全需求，如图2所示。\n应用程序根据应用的安全需要，在程序入口点或某些代码段的入口点进行 安全需求检查。这些检查安全需求的处理点称为“安全需求检查点”。应用程 序的安全需求根据各个“安全需求检查点”的不同，分成“安全需求段”，每 个安全检查点对应于一个“安全需求段”。一个应用程序的安全需求由若干个 “安全需求段”组成，如图3所示。\n根据应用程序“安全需求检查点”的不同分成若干“安全需求段”的安全 需求，都存储于.secure节中。每个“安全需求段”对应于一个“安全需求检查 点”，作为相应代码执行的安全条件。为了方便“安全需求段”的检索，.secure 节采用的结构参见图4。\n.secure节包括“节头”、“安全需求段头表”和“安全需求段表”。\n“节头”保存“安全需求段”的总概信息，如“安全需求段”的段数：\nTypedef struct_IMAGE_SECURE_HEAD{\n    WORD SecureNumber；/**安全需求段的段数**/\n    ……\n   }IMAGE_SECURE_HEAD，*PIMAGE_SECURE_HEAD；\nSecureNumber字段为“安全需求段”的段数。\n“安全需求段头表”中表项的数量与SecureNumber字段的值相一致。每 个表项的结构都相同，存储着相应“安全需求段”的偏移即相对虚拟地址和此 安全需求段的大小。其结构如下：\ntypedef struct_IMAGE_SECURE_SECTION_HEADER{\n    DWORD VirtualAddress；/**相对虚拟地址RVA**/\n    DWORD SizeOfRawData；/**安全需求段的大小**/\n}IMAGE_SECURE_SECTION_HEADER，\n*PIMAGE_SECURE_SECTION_HEADER；\n其中，VirtualAddress为相应安全需求段相对于.secure节基地址的相对虚 拟地址(Relative Virtual Address)；SizeOfRawData为相应安全需求段的大小。 通过安全需求段头表中表项，可以定位相应安全需求段的位置。\n“安全需求段”存储着相应“安全需求检查点”对应的安全需求。各个“安 全需求检查点”的安全需求根据需求会变化较大，为了方便表达各种安全需求 及其组合，“安全需求段”通过可扩展置标语言XML(Extensible Markup language) 来描述，例如：\n\n WINDOWS\n 2000\n SP3\n  MUST\n  MUST\n  MUST\n  \n    BIDIRECTIONAL\n    119.239.112.111\n    …\n  \n  MUST\n\n其中元素SECURE表示一个“安全需求段”的开始和结束。\n元素OS_TYPE表示操作系统的类型，其可取值WINDOWS或LINUX等。\n元素VERSION表示操作系统的版本，其取值与OS_TYPE取值相关，比 如当OS_TYPE为WINDOWS值时，VERSION可取值9x、2000或XP等。\n元素PATCH表示操作系统的补丁版本，其取值与OS_TYPE和VERSION 取值相关，比如当OS_TYPE为WINDOWS值，VERSION为2000时，PATCH 可取值SP1、SP2、SP3或SP4等。\n元素FIREWALL表示是否需要防火墙，其可取值MUST，表示必须需要 防火墙；OPTIONAL表示可以有防火墙；NO表示不需要防火墙。\n元素VIRUS表示是否需要防病毒软件，其可取值MUST，表示必须有防 病毒软件；OPTIONAL表示可以有防病毒软件；NO表示不需要防病毒软件。\n元素IDPS表示是否需要入侵检测和防护系统，其可取值MUST，表示必 须有入侵检测和防护系统；OPTIONAL表示可以有入侵检测和防护系统；NO 表示不需要入侵检测和防护系统。\n元素AUTHENTICATION表示需要进行身份认证。其中还有TYPE、 SERVER、CERTIFICATE等子元素。TYPE表示身份认证的类型：SINGLE表 示单向认证，即只有服务器对客户端的应用程序进行认证；BIDIRECTIONAL 表示双向认证，即除了服务器对客户端的应用程序进行认证外，客户端的应用 程序也对服务器进行认证。SERVER表示服务器的网络IP地址。CERTIFICATE 包含了相关的客户端的证书。\n元素ENCRYPT表示是否需要对通信信息进行加密。其可取值MUST，表 示必须要对通信信息进行加密；NO表示不需要对通信信息进行加密。\n以上“安全需求段”中XML的元素是以常用的安全要求作为安全需求进 行概要介绍，如有扩展需要，可以加入相应新元素，代表新的安全需求。\nPE文件的.secure节存储着应用程序的安全需求。安全需求最初由应用程 序设计和开发者根据应用的安全要求进行确定，然后描述到应用程序源代码 中。带有安全需求的应用程序源代码在编译时，经具有安全需求处理功能的“安 全编译器”处理后，相应的安全需求存储到相应PE文件的.secure节中。\n应用程序的开发者在应用程序源代码中，通过“安全描述语言”描述相应 的安全需求。“安全描述语言”以当前高级编程语言如C语言等为宿主语言。 “安全描述语言”描述的安全需求嵌入到宿主语言编写的程序代码中，如图5 所示。\n嵌入有“安全描述语言”描述的安全需求的应用程序源程序，通过“安全 编译器”进行编译后生成PE文件格式的执行文件体，其中的安全需求描述也 被编译转化为安全需求，并存储于.secure节中。每个“安全需求检查点”对应 的安全需求都存储到.secure节中一个相应的“安全需求段”中，如图6所示。\n“安全描述语言”用来描述应用程序中各个“安全需求检查点”的安全需 求。由于.secure节中各“安全需求段”中的安全需求是通过XML语言进行描 述的，为了方便和简化，“安全描述语言”也采用XML语言嵌入到应用程序源 代码中，以描述安全需求。“安全描述语言”中的元素与“安全需求段”中的 XML元素基本一致。例如：\n…\n\n\n  BIDIRECTINAL\n  210.223.119.110\n  …\n\nMUST\nwithdrawFromAccount()；/**取款--安全需求检查点**/\n…\n“安全编译器”为各种高级编程语言编译器的扩展。“安全编译器”在编 译带有安全需求的应用程序源程序时，对于源程序中每一个“安全需求检查点” 的安全需求都进行如下处理：\n(1)检查安全需求的有效性和一致性。\n主要检查XML元素的合法性和使用的一致性等。\n(2)对于通过有效性和一致性检查的某个“安全需求检查点”的安全需 求，“安全编译器”将其存入PE文件.secure节中，作为一个“安全需求段”， 并记下此“安全需求段”对应的“安全需求段头表表项”在“安全需求段头表” 中的索引号，如索引号为“N”。\n(3)“安全需求检查点”的安全需求转化为对“安全需求解释器”的调用， 参数为“安全需求段”对应的“安全需求段头表表项”在“安全需求段头表” 中的索引号，如“N”。\nCALL SECURE_INTERPRETER(N)；\n进一步地，该安全编译器包括有效性与一致性检查模块，对应用程序源程 序每个安全需求检查点嵌入的安全需求描述进行有效性和一致性检查，将通过 检查的安全需求描述传递给安全需求部分转换模块；安全需求部分转换模块， 将传递来的安全需求描述编译转化为安全需求并存储于.secure节内相应的“安 全需求段”中；安全需求解释器链接模块，在.text节每个安全需求检查点上链 接安全需求解释器，并向其传递相应的安全需求段对应的安全需求段头表表项 在安全需求段头表中的索引号。\n通过“安全编译器”的上述处理后，应用程序中的安全需求最终转化为了 对“安全需求解释器”的调用，而需要“安全需求解释器”处理的安全需求则 存储于PE文件的.secure节中，它们之间通过“索引号”进行关联，如图7所 示。\n当应用程序运行时，PE文件载入器将各节映射到内存中某块地址(Virtual Address)上，其中.text节为应用程序执行代码，.secure节为安全需求。PE文 件被载入内存后，应用程序从程序入口点开始运行。\n当应用程序运行到“安全需求检查点”时，其实就是对“安全需求解释器” 的调用。在调用时，传递相应安全需求对应的“索引号”，比如N。“安全需求 解释器”被调用后，执行的操作如图8所示，操作流程具体如下：\n(1)首先获取传递来的安全需求“索引号”；\n(2)然后根据“索引号”，查找.secure节中的“安全需求段头表”，找到 相应的“安全需求段头表”的表项，并从此“安全需求段头表”的表项中，获得 相应“安全需求段”的起始地址和大小；\n(3)接着对“安全需求段”中描述的安全需求进行分析，并且进行相应 的检测和检验。检测当前运行环境是否能满足应用程序此安全需求段的安全要 求；\n(4)如果当前运行环境能满足应用程序此安全需求段的安全要求，应用 程序从“安全需求检查点”的下一条执行代码开始执行；否则，应用程序返回 上层逻辑，不能执行相应的代码。\n进一步地，安全需求解释器包括位置信息接收模块，用于接收安全编译器 传递来的安全需求段对应的安全需求段头表表项在安全需求段头表中的索引 号；安全需求部分查找模块，用于根据位置信息接收模块收到的索引号在可执 行文件中查找安全需求段；安全需求部分分析模块，用于对安全需求部分查找 模块找到的安全需求段进行分析；安全检测模块，用于根据安全需求部分分析 模块的分析结果对运行环境进行检测。\n“安全需求解释器”负责对安全需求进行分析和安全条件的检测，判断当 前运行环境是否满足当前“安全需求段”的安全要求。“安全需求解释器”首 先具有XML解释器的部分功能，实现对“安全需求段”中描述安全需求的XML 的解释；其次，针对安全需求的每个XML元素，“安全需求解释器”都会有相 应的安全处理机制。\n对于例如元素VIRUS：MUST，处理如下：\n“安全需求解释器”会检测当前系统是否安装了防病毒软件，如果安装了， 应用程序将从“安全需求检查点”继续执行；否则，跳转到上一逻辑，不能执 行相关的代码。\n“安全需求解释器”可以以动态链接库(DLL)的形式出现。常用的安全 要求在通用的“安全需求解释器”中实现，如应用程序需要，也可以进行扩充。\n总而言之，该方案在PE文件格式中加入.secure节，同时引入“安全描述 语言”、“安全编译器”和“安全需求解释器”等概念，将安全需求和安全实现 逻辑从应用程序中分离出来。“安全描述语言”描述分离出来的安全需求，“安 全需求解释器”实现安全需求的安全逻辑。\n首先，定义“安全描述语言”，用来描述应用程序对运行环境的各种安全 需求。“安全描述语言”用“可扩展置标语言(XML，eXtensible Markup Language)”进行描述。定义“安全描述语言”，就是确定描述安全需求的相 关XML元素。每个XML元素代表着一种安全需求，或者一种安全需求的一 部分。\n常用的元素比如：\nSECURE元素：表示“安全需求段”的开始\nOS_TYPE元素：表示操作系统类型\nVERSION元素：表示操作系统的版本\nPATCH元素：表示操作系统补丁版本\nFIREWALL元素：表示是否需要防火墙\nVIRUS元素：表示是否需要安全防病毒软件\nIDPS元素：表示是否需要安装入侵检测和防护系统\nAUTHENTICATION元素：表示需要进行身份认证\nTYPE元素：表示身份认证的类型\nSERVER元素：表示身份认证服务器\nCERTIFICATE元素：客户端证书\nENCRYPT元素：表示是否需要信息加密\n接着，以动态连接库(DLL)的形式构建“安全需求解释器”。针对“安 全描述语言”中的每个XML元素，“安全需求解释器”都要实现相应的安全处 理，检测、校验运行环境是否满足相应的安全要求。“安全需求解释器”由PE 文件载入器在载入应用程序时，载入内存；在应用程序运行到“安全需求检查 点”时调用。对于每个“安全需求段”，只有通过“安全需求解释器”校验， 并证明当前运行环境满足应用程序的安全需求时，应用程序才能往下运行；否 则，转到上一级逻辑。\n然后，扩展高级语言的编译/链接器，增加对由“安全描述语言”描述的安 全需求的编译和链接功能。经编译/链接后，安全需求存入PE文件中的.secure 节中，同时相应的“安全需求检查点”用对“安全需求解释器”的调用来代替。\n利用“安全描述语言”、“安全编译器”和“安全需求解释器”，为安全应 用程序构建提供了一种通用的框架，由于安全需求和安全实现逻辑从应用程序 中分离，这为构建适合各种安全需求的应用程序提供了灵活、快捷的方法。\n显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发 明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及 其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。