实现可信计算基结构化扩展的管道安全保障方法与系统 【技术领域】
本申请涉及一种本发明属于信息安全装置领域，具体涉及可信计算基(Trusted Computing Base)结构化扩展的管道安全保障方法与系统。
背景技术
从2007年6月份开始，我国开展了全国范围内的信息系统普遍信息安全等级保护定级工作，到目前为止定级工作已经基本完成，其中被定为三级以上的信息系统多达几万个。三级以上信息系统被统称为重要信息系统，它们所承载的应用系统安全非常重要，一旦其安全遭到破坏，必然对社会秩序、公众利益甚至国家的安全和稳定都会产生重大影响，因此需要重点保护。
强制性国家标准《计算机信息系统安全保护等级划分准则GB17859-1999》明确规定可信计算基(TCB)是保障系统安全的核心，它建立的基本保护环境为用户提供了一个可信计算基系统所要求的附加用户服务。
英特尔公司提出的US2005086509A1号美国专利和US2008141024A1号美国专利公开了一种扩展可信计算基，其生成较低层次的可信计算基(L1 TCB)，其具有包含可信平台模块的一系列硬件组件。通过将高层次TCB添加到低层次TCB的方式，扩展TCB得以形成，其中高层次TCB是基于软件的。较低级别TCB相关的特性通过低级别TCB接口传送到高级别TCB中。US2005138423A1号美国专利则公开了基于可信计算基的硬件可信单元和MAC虚拟监测器。
由于TCB是计算机系统内包括硬件、固件、软件和负责执行安全策略在内的所有保护装置的组合体，因此是以组件的形式分布在信息系统的物理层、操作系统层、应用层及网络层。目前上述现有技术都是对单一层次的TCB组件功能的完善与加强，例如采用安全操作系统加固系统层，用安全数据库管理系统加固应用层的数据库应用软件等，这种只对单一TCB组件进行加固建设、而没有对TCB组件间的连接进行安全保障的做法使得组合体无法彼此信任，其保护效果如同马其诺防线不堪一击，无法真正实现对用户应用的安全支撑，更无法达到GB17859的安全保障要求。
【发明内容】
为了解决上述问题，实现可信计算基组件的无缝连接与可信计算基的结构化扩展，并防止部分隐通道的出现，本发明得以提出。
本申请公开一种连接TCB组件的安全保障系统，该系统包括：应用层TCB组件，其用于实施各可信软件自身设置的安全策略；操作系统层TCB组件，其用于实施信息系统设置的安全策略；以及管道，其在应用层TCB组件与操作系统层TCB组件之间建立，用于实现可信组件与可信组件之间的可信消息传递。
上述应用层TCB组件包括，管道协商模块，与操作系统层的管道协商模块进行协商，获得应用层TCB和操作系统层TCB之间的管道；访问控制模块，用于对请求进行与用户相关的细粒度的控制；管道封装模块，对访问请求信息按照管道的格式进行封装，并通过系统调用传递到操作系统层TCB；消息传递模块，用于将访问请求信息传递到操作系统TCB。
上述应用层TCB组件的管道协商模块中，操作系统层TCB对应用层TCB进行可信认证，认证通过后采用密码协商协议协商出应用层TCB和操作系统层TCB的通信密钥，管道信息采用通信密钥进行加密保护。
[10]上述应用层TCB组件的访问控制模块中，操作系统TCB信任通过认证的应用TCB所做的访问控制。
[11]上述应用层TCB组件的消息传递模块为系统调用模块。或者，上述应用层TCB组件的消息传递模块为系统服务模块。
[12]上述操作系统层TCB组件包括，管道协商模块，用于协商得到应用层和操作系统层消息传递的加密通道；消息分析模块，用于对访问请求消息进行分析，得出进程、访问请求行为信息；管道认证模块，用于对访问请求进行认证，确定该访问请求是否是合法的管道请求并将结果提交到控制决策模块；控制决策模块，用于对访问请求进行裁决；策略管理模块，用于管理操作系统层TCB的相关策略，为管道协商模块、控制决策模块提供策略服务。
[13]上述操作系统层TCB组件的管道协商模块中，应用层和操作系统层消息为资源访问请求。或者，上述操作系统层TCB组件的管道协商模块中，应用层和操作系统层消息为程序调用请求。
[14]上述操作系统层TCB组件的消息分析模块中，访问请求信息采用管道封装的信息。或者，上述操作系统层TCB组件的消息分析模块中，访问请求信息采用传统的非管道请求。
[15]上述操作系统层TCB组件的管道认证模块，用于实现：通过检验该访问请求是否具有表征安全管道的信息，利用管道协商时得到的通信密钥对管道访问请求进行近一步的解析。
[16]上述操作系统层TCB组件的策略管理模块，其所管理的操作系统层TCB的相关策略包括，管理管道认证策略和访问控制策略。
[17]上述管道为一种能将上层的系统调用请求无干扰地传递至下层操作系统进行执行地传输机制。上述管道还用于支撑并实现TCB的结构化扩展。上述管道还用于防止部分隐通道的出现。上述管道可以封装传统的系统调用或者服务请求。
[18]上述管道可以采用通过密码机制实现的一种逻辑管道。上述管道传递的参数是进行管道封装后的信息。上述信息采用管道密钥进行加密。
[19]本申请还公开一种连接TCB组件的安全保障方法，该方法包括：应用层TCB安全保障步骤，其用于实施各可信软件自身设置的安全策略；操作系统层TCB安全保障步骤，其用于实施信息系统设置的安全策略；管道消息传递步骤，其在应用层TCB组件与操作系统层TCB组件之间建立管道，在可信组件与可信组件之间进行可信消息传递。
[20]上述应用层TCB安全保障步骤，进一步包括：管道协商子步骤，与操作系统层的管道协商模块进行协商，获得应用层TCB和操作系统层TCB之间的管道；访问控制子步骤，用于对请求进行与用户相关的细粒度的控制；管道封装子步骤，对访问请求信息按照管道的格式进行封装，并通过系统调用传递到操作系统层TCB；消息传递子步骤，用于将访问请求信息传递到操作系统TCB。
[21]上述应用层TCB安全保障步骤的管道协商子步骤中，操作系统层TCB对应用层TCB进行可信认证，认证通过后采用密码协商协议协商出应用层TCB和操作系统层TCB的通信密钥，管道信息采用通信密钥进行加密保护。
[22]上述应用层TCB安全保障步骤的访问控制子步骤中，操作系统TCB信任通过认证的应用TCB所做的访问控制。
[23]上述应用层TCB安全保障步骤的消息传递子步骤为系统调用操作。或者，上述应用层TCB安全保障步骤的消息传递子步骤为系统服务操作。
[24]上述操作系统层TCB安全保障步骤，进一步包括，管道协商子步骤，用于协商得到应用层和操作系统层消息传递的加密通道；消息分析子步骤，用于对访问请求消息进行分析，得出进程、访问请求行为信息；管道认证子步骤，用于对访问请求进行认证，确定该访问请求是否是合法的管道请求并将结果提交到控制决策模块；控制决策步骤，用于对访问请求进行裁决；策略管理子步骤，用于管理操作系统层TCB的相关策略，为管道协商模块、控制决策模块提供策略服务。
[25]上述操作系统层TCB安全保障步骤的管道协商子步骤中，应用层和操作系统层消息为资源访问请求。或者，上述操作系统层TCB安全保障步骤的管道协商子步骤中，应用层和操作系统层消息为或者程序调用请求。
[26]上述操作系统层TCB安全保障步骤的消息分析子步骤中，访问请求信息采用管道封装的信息。或者，上述操作系统层TCB安全保障步骤的消息分析子步骤中，访问请求信息采用传统的非管道请求。
[27]上述操作系统层TCB安全保障步骤的管道认证子步骤，其通过检验该访问请求是否具有表征安全管道的信息，利用管道协商时得到的通信密钥对管道访问请求进行近一步的解析。
[28]上述操作系统层TCB安全保障步骤的策略管理子步骤，其所管理的操作系统层TCB的相关策略包括，管理管道认证策略和访问控制策略。
[29]上述管道封装子步骤采用一种能将上层的系统调用请求无干扰地传递至下层操作系统进行执行的传输机制。上述管道封装子步骤还用于支撑并实现TCB的结构化扩展。上述管道封装子步骤还用于防止部分隐通道的出现。上述管道封装子步骤可以封装传统的系统调用或者服务请求。
[30]上述管道封装子步骤可以采用通过密码机制实现的一种逻辑管道。上述管道传递的参数是进行管道封装后的信息。上述信息采用管道密钥进行加密。
【附图说明】
[31]从对说明本申请的主旨及其使用的优选实施例和附图的以下描述来看，本申请的以上和其它目的、特点和优点将是显而易见的，在附图中：
[32]图1是作为本申请背景技术的TCB组件结构图；
[33]图2是连接TCB组件的安全保障系统的模块结构图；
[34]图3是应用层TCB组件的模块结构图；
[35]图4是操作系统层TCB组件的模块结构图；
[36]图5是应用层TCB组件和操作系统层TCB组件共同作用的模块结构图；
[37]图6是应用层TCB安全保障步骤的流程图；
[38]图7是操作系统层TCB安全保障步骤的流程图；
[39]图8是应用层TCB组件和操作系统层TCB组件共同作用的流程图；
[40]图9是管道机制的一种实施例的示意图。
【具体实施方式】
[41]下面结合附图介绍本申请的技术方案。
[42]图1是作为本申请背景技术的TCB组件结构图，其中，该扩展可信计算基生成较低层次的可信计算基(L1 TCB)，其具有包含可信平台模块的一系列硬件组件。通过将高层次TCB添加到低层次TCB的方式，扩展TCB得以形成，其中高层次TCB是基于软件的。较低级别TCB相关的特性通过低级别TCB接口传送到高级别TCB中。
[43]图2是连接TCB组件的安全保障系统的模块结构图。如图2所示，连接TCB组件的安全保障系统，该系统包括：应用层TCB组件21，其用于实施各可信软件自身设置的安全策略；操作系统层TCB组件22，其用于实施信息系统设置的安全策略；以及管道23，其在应用层TCB组件与操作系统层TCB组件之间建立，用于实现可信组件与可信组件之间的可信消息传递。应用层TCB组件21、管道23和操作系统层TCB组件22都是TCB的组成部分，均执行系统安全策略下的访问控制机制(包括自主访问控制与强制访问控制)，对主体访问客体的行为进行判别。
[44]其中，操作系统层TCB组件22的主要功能是实施信息系统设置的安全策略。在经应用层软件处理的情况下，操作系统可见的主体粒度多为进程，客体粒度多为文件，此时操作系统层TCB组件22所执行的访问控制机制无法真实的反映安全策略，因此需要在应用层对细粒度的主、客体进行更上一层的访问控制。
[45]应用层TCB组件21的主要功能是实施各可信软件自身设置的安全策略。此时的主体粒度多为用户，客体粒度多为应用对象，经访问控制机制判别后保证用户只能行使可信软件预先设定的功能，即保证了应用层的安全可信。此时，行使用户权限的进程对系统层TCB组件就是可信的。
[46]管道23保证了将应用层的请求判决结果不会受到旁路、篡改等威胁，安全地传递至操作系统层，实现了应用层主、客体到系统层主、客体的安全移交，完成了由一个可信组件到另一个可信组件的可信传递，保障了全程标记的一致性与安全策略的一致性。而非可信程序的调用请求由操作系统层TCB组件22直接完成判断。
[47]图3是应用层TCB组件的模块结构图。如图3所示，应用层TCB组件包括管道协商模块31、访问控制模块32、管道封装模块33和消息传递模块34。管道协商模块31与操作系统层的管道协商模块(附图4中的管道协商模块41)进行协商，协商出应用层TCB和操作系统层TCB之间的管道。一方面是操作系统层TCB对应用TCB进行可信认证，认证通过后采用密码协商协议协商出应用层TCB和操作系统层TCB的通信密钥，管道信息就是采用通信密钥进行加密保护的。
[48]应用系统自身的访问控制模块32，主要是应用系统对请求进行与用户相关的细粒度的控制。操作系统层TCB信任通过认证的应用层TCB所做的访问控制。在此不对应用层TCB的访问控制模块做进一步细分。
[49]在管道封装模块33中，应用层TCB的访问控制模块对用户请求进行控制，对于合法的用户访问请求信息需要传递到操作系统层，因为所有的资源访问都是要通过操作系统的系统调用完成的，比如文件读写，最终都是要通过操作系统对文件进行读写。在管道机制模式下，需要对访问请求信息按照管道的格式进行封装，并通过系统调用传递到操作系统层TCB，如果不进行管道封装的话，操作系统层TCB认为该请求是非管道请求，不允许对重要信息进行访问的。因此，可信的应用系统，在与操作系统层TCB协商出管道后，后续对重要信息的访问都应通过管道进行访问。
[50]在消息传递模块34中，应用系统将访问请求信息传递到操作系统TCB，主要方式有系统调用或者系统服务。
[51]图4是操作系统层TCB组件的模块结构图。如图所示，操作系统层TCB组件主要包括管道协商模块41、消息分析模块42、管道认证模块43、控制决策模块44和策略管理模块45。
[52]就管道协商模块41而言，应用层TCB也有对应的管道协商模块(附图3中的管道协商模块31)，首先通过该模块协商出一个应用层和操作系统层消息(资源访问请求或者程序调用请求)传递的加密通道。传统意义的资源访问或系统调用是明文的，称之为非管道请求。通过管道协商模块41协商出管道(如何通过安全协议进行协商的详细细节不在本专利的讨论范围)，应用系统的资源访问请求和系统调用请求必须按管道的格式进行封装，如果不按管道格式封装，可以认为是非管道请求，只具有最低的权限。
[53]消息分析模块42对访问请求消息进行分析，得出主体(进程)、访问请求行为等信息，访问请求信息有可能是采用管道封装的信息，也有可能是传统的非管道请求。
[54]管道认证模块43通过消息分析模块42得到访问请求信息，该模块对访问请求进行认证，确定该访问请求是否是合法的管道请求，还是非管道访问请求，认证的方式是通过检验该访问请求是否具有表征安全管道的信息，利用管道协商时候得到的通信密钥对管道访问请求进行近一步的解析，因为如果是管道访问请求的话，访问的对象(客体)信息是采用管道通信密钥进行加密的，所以需要解密，以获得客体信息和操作行为(读、写、执行等)。并将结果提交到控制决策模块做下一步控制。
[55]控制决策模块44主要负责对访问请求进行裁决。因为认为管道请求是上层可信应用系统发起的请求，上层应用是通过管道协商模块41可以认为是可信的、安全的，并且在消息传递过程中是采用管道封装进行加密的，相信在传递过程不会被篡改，因此，对于管道的访问请求，在操作系统TCB这层是不做控制的；对于非管道请求，也就是常规的访问请求，通过策略管理模块45进行判定。原则是最低权限原则，保证重要的信息只能通过管道进行访问，管道的主要作用就在于此。
[56]策略管理模块45管理操作系统TCB的相关策略，主要包括管道认证策略和访问控制策略，为管道协商模块41、控制决策模块44提供策略服务。
[57]图5是应用层TCB组件和操作系统层TCB组件共同作用的模块结构图。如图5所示，连接TCB组件的安全保障系统包括：应用层TCB组件，操作系统层TCB组件和管道。应用层TCB组件进一步包括，管道协商模块，与操作系统层的管道协商模块进行协商，获得应用层TCB和操作系统层TCB之间的管道；访问控制模块，用于对请求进行与用户相关的细粒度的控制；管道封装模块，对访问请求信息按照管道的格式进行封装，并通过系统调用传递到操作系统层TCB；和消息传递模块，用于将访问请求信息传递到操作系统TCB。操作系统层TCB组件进一步包括，管道协商模块，用于协商得到应用层和操作系统层消息传递的加密通道；消息分析模块，用于对访问请求消息进行分析，得出进程、访问请求行为信息；管道认证模块，用于对访问请求进行认证，确定该访问请求是否是合法的管道请求并将结果提交到控制决策模块；控制决策模块，用于对访问请求进行裁决；和策略管理模块，用于管理操作系统层TCB的相关策略，为管道协商模块、控制决策模块提供策略服务。
[58]图6是应用层TCB安全保障步骤的流程图。应用层TCB安全保障步骤包括：管道协商子步骤(图中未示出，在访问控制子步骤之前完成)、访问控制子步骤61、管道封装子步骤62和消息传递子步骤63。在管道协商子步骤，与操作系统层的管道协商模块进行协商，获得应用层TCB和操作系统层TCB之间的管道；在访问控制子步骤61，用于对请求进行与用户相关的细粒度的控制；在管道封装子步骤62，对访问请求信息按照管道的格式进行封装，并通过系统调用传递到操作系统层TCB；在消息传递子步骤63，用于将访问请求信息传递到操作系统TCB。
[59]图7是操作系统层TCB安全保障步骤的流程图。操作系统层TCB安全保障步骤包括：管道协商子步骤(图中未示出，在访问控制子步骤之前完成)、消息分析子步骤71、管道认证子步骤72、控制决策步骤73和策略管理子步骤74。其中，管道协商子步骤用于协商得到应用层和操作系统层消息传递的加密通道；消息分析子步骤71用于对访问请求消息进行分析，得出进程、访问请求行为信息；管道认证子步骤72用于对访问请求进行认证，确定该访问请求是否是合法的管道请求并将结果提交到控制决策模块；控制决策步骤73用于对访问请求进行裁决；策略管理子步骤74用于管理操作系统层TCB的相关策略，为管道协商模块、控制决策模块提供策略服务。
[60]图8是应用层TCB组件和操作系统层TCB组件共同作用的流程图。如图8所示的连接TCB组件的安全保障方法包括，应用层TCB安全保障步骤，其用于实施各可信软件自身设置的安全策略；操作系统层TCB安全保障步骤，其用于实施信息系统设置的安全策略；管道消息传递步骤，其在应用层TCB组件与操作系统层TCB组件之间建立管道，在可信组件与可信组件之间进行可信消息传递。
[61]图9是管道机制的一种实施例的示意图。如图9所示，用户对应用对象的访问请求经应用层TCB组件判别后由可信程序附加校验码，该校验码的算法与可信标识由可信程序与操作系统预先协商定义；附加了校验码的系统调用传递至系统层后进行一致性校验，保证了只有经应用层TCB组件判别后的调用才有权在系统层执行。系统层TCB组件在判别校验码正确后进行系统层的判别，最终完成用户的访问请求。管道的具体实现是对传统的系统调用或者服务请求进行封装。比如传统的打开文件的系统调用OpenFile，要打开的文件名作为请求对象直接作为OpenFile的参数，在采用管道的模式下，传递的参数不是文件名，而是进行管道封装后的信息，包括文件名、管道ID等与管道相关的信息，而且是采用管道密钥进行加密的。操作系统TCB的管道认证模块，根据管道的结构以及事先协商好的管道密钥对请求信息进行分析，并做相应的认证，判定该请求是否是管道请求以及该请求是否是合法的等等。在此OpenFile只是为了便于说明，对于其他访问请求可以采用类似的方式实现。
[62]尽管图2-9以及上面的描述公开了本申请的优选实施例，可以设想，本领域的技术人员可在所附权利要求的精神和范围内设计对本申请的各种修改。