CN114175034A - 验证信息生成系统、验证信息生成方法以及验证信息生成程序 - Google Patents

Abstract

验证信息生成装置(10)从安装有软件的设备取得该软件的安装目的地的目录，基于在所取得的目录中保存的文件的类型，取得能够取得哈希值的文件的文件路径以及该文件的哈希值。然后，验证信息生成装置(10)生成该软件的验证信息，所述验证信息包含所取得的文件的文件路径以及该文件的哈希值。

Description

验证信息生成系统、验证信息生成方法以及验证信息生成 程序

技术领域

本发明涉及验证信息生成系统、验证信息生成方法以及验证信息生成程序。

背景技术

以往，为了确认安装于各种设备中的软件在安全性上没有问题(完整性)，存在检测与该软件关联的文件的变更、篡改的技术(参照非专利文献1、2)。在此，通过设定变更、安全补丁的应用等来更新软件。因此，系统运用者除了软件的导入时以外，还需要在每天的运用中适当地确认完整性。

现有技术文献

专利文献

专利文献1：日本特开2019-8738号公报

专利文献2：日本特开2019-8377号公报

非专利文献

非专利文献1：Tripwire、[online]、[2019年7月11日检索]、互联网<https://www.tripwire.co.jp/about/>

非专利文献2：日经XTECH、“仮想環境のセキュリティを高めるインテルTXT”、[在线]、[2019年7月11日检索]、互联网<https://tech.nikkeibp.co.jp/it/article/COLUMN/20071114/287197/>

发明内容

发明所要解决的课题

但是，在现有技术中，用于确认上述完整性的对照信息(验证信息)在某个时刻只能确认完整性，因此存在可靠性未必高、不能应对一般的软件的问题。另外，若想要在确保可靠性的同时生成也能应对一般的软件的验证信息，则存在人工的作业变多而花费工夫的问题。

此外，有时在软件包中没有正确地描述与软件包相关的各种设定信息和表示软件包中包含的各种库的依赖关系的信息(元信息)，因此存在在安装之后必需手动设定验证信息的情况。另外，在不使用软件包而安装软件的情况下，由于用户指定安装目的地，因此还存在需要生成反映了安装目的地的验证信息的问题。因此，本发明的课题在于提供一种解决上述问题的验证信息的生成部。

用于解决课题的手段

为了解决上述课题，本发明的特征在于，具备：第1取得部，其在设备中安装验证对象的软件，从所述设备取得所述软件的安装目的地的目录，基于存储在所取得的所述目录中的文件的类型来确定能够取得哈希值的文件，取得所述能够取得哈希值的文件的文件路径和所述文件的哈希值；以及第1验证信息生成部，其生成在所述软件的验证中使用的验证信息，所述验证信息包含由所述第1取得部取得的文件的文件路径和所述文件的哈希值。

发明效果

根据本发明，能够提供验证信息的生成部。

附图说明

图1是示出验证信息生成系统的结构例的图。

图2是示出通过执行zipinfo命令而获得的信息的示例的图。

图3是示出通过执行zipinfo命令而获得的信息的示例的图。

图4是示出验证信息列表的示例的图。

图5是示出带签名验证信息列表的示例的图。

图6是示出第1实施方式的验证信息生成装置的处理过程的示例的流程图。

图7是示出图6的S112的解析处理的示例的流程图。

图8是示出使用验证信息中的哈希(hash)值的验证处理的示例的流程图。

图9是示出使用验证信息的、不需要的文件的追加的验证处理的例子的流程图。

图10是示出使用验证信息的、必需构成的文件的删除的验证处理的例子的流程图。

图11是示出使用验证信息的访问源的验证处理的示例的流程图。

图12是示出第2实施方式的验证信息生成装置的处理过程的示例的流程图。

图13是示出执行验证信息生成程序的计算机的示例的图。

图14是示出对照信息列表的示例的图。

具体实施方式

以下，参照附图对用于实施本发明的方式(实施方式)分为第1实施方式和第2实施方式来进行说明。本发明并不限定于以下说明的实施方式。另外，以下说明的验证信息是作为用于验证是否对与安装于设备中的软件关联的文件进行了变更、篡改的基础的信息，将与实际验证是否进行了文件的变更、篡改的设备相匹配地而进行了修正后的信息定义为对照信息。

[概要]

以下，说明各实施方式的验证信息生成装置(验证信息生成系统)的概要。各实施方式的验证信息生成装置例如为了生成上述的验证信息，在安装有软件的验证装置中使该软件动作。然后，验证信息生成装置对使该软件动作时的文件、目录的实际的行为进行解析，生成验证信息。

例如，在使用软件的源文件或将用于安装的元数据汇总为1个的tar文件在验证装置中安装软件的情况下，用户能够指定安装目的地的目录。在此，安装时用户指定的安装目录等被保存在展开了上述tar文件的源目录内的config.nice或config.status中。因此，验证信息生成装置根据展开tar文件的源目录内的config.nice或config.status，确定软件的安装目录。然后，验证信息生成装置使用存储在指定的安装目录中的各个文件的信息来生成验证信息。

例如，验证信息生成装置基于存储在指定的安装目录中的各个文件的类型来确定各个文件是否是具有实体的文件。然后，验证信息生成装置将有实体的文件确定为能够取得哈希(hash)值的文件。之后，验证信息生成装置针对能够取得哈希值的文件计算哈希值，生成包含该文件的文件路径和计算出的哈希值的验证信息(参照图4)。

由此，验证信息生成装置能够生成与用户指定软件的安装目的地那样的软件包、根据所安装的环境而变更各种设定信息的软件包相关的验证信息。

另外，以下，将验证信息生成装置为了生成软件包的验证信息而在验证装置中安装该软件并对使该软件动作时的文件或目录的实际的行为进行解析的情况适当地称为“动态解析”。

[第1实施方式]

[结构]

接着，使用图1，说明第1实施方式的验证信息生成系统的结构例。验证信息生成系统例如具备：验证信息生成装置10，其生成软件包的验证信息；以及验证装置20，其使用该验证信息进行安装于自身的验证装置20中的软件的验证处理。

验证信息生成装置10具备数据处理部11和数据存储部12。验证信息生成装置10例如经由因特网等网络与使用者终端连接。

数据处理部11具备处理受理部111、动态解析处理部112以及签名赋予部113。数据存储部12具备验证信息列表存储部121、带签名验证信息列表存储部122、动态解析规则存储部123。

另外，存在虚线所示的静态解析处理部115和静态解析规则存储部124装备于验证信息生成装置10中的情况和未装备的情况，关于装备的情况在第2实施方式中叙述。

首先，对构成数据处理部11的各部进行说明。处理受理部111从使用者终端受理软件包的验证信息的生成委托，并返回其结果。

动态解析处理部112对验证信息的生成对象的软件包进行动态解析，生成验证信息。该动态解析处理部112包括第1解析部(第1取得部)1121和第1验证信息生成部1122。

第1解析部1121从动态解析规则存储部123读出用于针对验证信息的生成对象的软件包进行该软件包的动态解析的规则。然后，第1解析部1121根据读取的规则将该软件包安装在验证装置20中，并且从该验证装置20取得该软件包的软件的安装目的地的目录。然后，第1解析部1121基于存储在所取得的目录中的文件的类型来确定能够取得哈希值的文件。然后，第1解析部1121取得能够取得该哈希值的文件的文件路径和该文件的哈希值。

例如，第1解析部1121例如根据tar文件中包含的config.nice或config.status，确定软件的安装目录。然后，第1解析部1121基于存储在所确定的安装目录中的文件的类型来判定该文件是否是存在实体的文件。

然后，第1解析部1121将判定为存在实体的文件确定为能够取得哈希值的文件。然后，第1解析部1121针对能够取得哈希值的文件计算该文件的哈希值，并且取得该文件的文件路径和所计算的该文件的哈希值。

另外，第1解析部1121还从tar文件中取得该软件包的包名、验证信息ID(例如序列号)。

例如，第1解析部1121通过执行以下所示的命令来确定存储在安装目录中的各个文件的类型，并且针对能够获取哈希值的文件计算该文件的哈希值。

[数1]

#file*

anaconda-ks.cfg:ASCII text

nginx-core_1.10.0-0ubuntu0.16.04.4_amd64.deb:Debian二进制包(格式2.0)

og:ASCII text

test.txt:UTF-8Unicode text

#find.-type f-exec md5sum{}\；

f564036eb3c48b65cb535e28d06a01cf./anaconda-ks.cfg

1abdb661aad10d5f6590131afe580a2d./nginx-core_1.10.0-0ubuntu0.16.04.4_amd64.deb

3594b394ced3d9c52870116f2a26b780./og

6fb76fe20ce0cbf06a468104bd816bb8./test.txt

在此，例如，在能够取得上述哈希值的文件是文本文件的情况下，在软件的安装后，有可能由于设定变更等而发生文件的改写。因此，在能够获取哈希值的文件是文本文件的情况下，第1解析部1121在验证装置20中的软件的设定变更之后重新计算该文件的哈希值。然后，第1验证信息生成部1122将验证信息中的与该文件有关的哈希值改写为重新计算出的值。

作为第1解析部1121的解析对象的软件包可以是压缩文件。

压缩文件例如是zip文件或war文件。zip文件是将多个文件汇总为1个文件来处理的存档格式。war文件是Java(注册商标)Platform Enterprise Edition(Java EE)应用的包，以zip形式被压缩。

zip文件和war文件都可以通过zipinfo命令来确认存储在该压缩文件中的文件的文件格式(t：文本文件，b：二进制文件)(参见图2和图3)。

因此，例如，如果通过zipinfo命令获得的文件的文件格式是文本文件，则该文件可能被重写，因此第1解析部1121在验证装置20中的软件的设定变更之后重新计算该文件的哈希值。

第1验证信息生成部1122基于通过第1解析部1121对软件包的解析而获取的信息来生成该软件包的验证信息。

例如，第1验证信息生成部1122使用通过第1解析部1121对软件包的解析而获取的该软件包的包名、验证信息ID(例如，序列号)、验证对象的文件的文件路径或目录、该文件的哈希值等，生成验证信息(参见图4)。之后，第1验证信息生成部1122将生成的验证信息保存到验证信息列表存储部121，将验证信息的生成完成的情况返回给使用者终端。

此外，在处理受理部111经由使用者终端受理了验证信息的读出指示的情况下，处理受理部111从验证信息列表存储部121读出读出指示对象的验证信息，并发送到使用者终端。之后，当处理受理部111从使用者终端受理了该验证信息的修正时，将反映了修正的验证信息保存在验证信息列表存储部121中。

例如，当处理受理部111从使用者终端受理了在验证信息中追加在该验证信息中的访问源许可列表(参照图4)中许可的访问源(被许可访问的程序的执行文件路径)的指示时，基于该指示将修正后的验证信息保存到验证信息列表存储部121中。

此外，处理受理部111也可以将从外部装置(例如，使用者终端)发送的验证信息保存到验证信息列表存储部121。

签名赋予部113将用户签名的公钥证书赋予到验证信息。例如，当签名赋予部113从使用者终端受理了对验证信息赋予签名的委托时，处理受理部111从验证信息列表存储部121选择相应的验证信息，将验证信息交给签名赋予部113。然后，签名赋予部113将该验证信息中的如下的验证信息存储在带签名验证信息列表存储部122中：其中该验证信息是针对将验证信息ID置换为包ID(包名+验证信息ID+存储有验证信息的装置的识别信息)(参见图5)的信息赋予了存储验证信息的设备的用户签名和用户签名的公钥证书的验证信息。

然后，签名赋予部113将安装软件包的验证装置20的用户签名和用户签名的公钥证书赋予给该验证信息(参见图5)，并且存储在带签名验证信息列表存储部122中。

接着，说明数据存储部12的各部。数据存储部12的验证信息列表存储部121存储验证信息的列表(验证信息列表)。例如，如图4所示，验证信息包括软件包的包名、验证信息ID、验证对象文件的文件路径或目录路径信息、该文件的hash值(哈希值)、存在必需属性等。另外，如图4所示，验证信息也可以包含构成确认对象属性、访问源许可列表等。

存在必需属性是指示验证信息的文件路径/目录路径信息中所示的文件是否是安装该软件包的设备中必需的文件的属性信息。

此外，构成确认对象属性是表示验证信息的文件路径/目录路径信息中所示的文件是否是构成确认对象的属性信息。

此外，访问源许可列表是表示被允许针对验证信息的文件路径/目录路径信息所示的文件进行访问的程序的执行文件路径的信息。

上述的存在必需属性、构成确认对象属性、访问源许可列表的信息例如是从使用者终端输入的信息。

带签名验证信息列表存储部122保存带签名验证信息的列表(参照图5)。该带签名验证信息的列表是赋予了安装软件包的设备的用户签名和用户签名的公钥证书的验证信息的列表。例如，带签名验证信息的列表(参照图5)是通过针对图4所示的每个验证信息进行如下处理而得到的信息：将验证信息ID替换为包括包名+验证信息ID+存储验证信息的验证装置20的识别信息而得到的包ID，并对替换后的信息赋予存储验证信息的设备的用户签名和用户签名的公钥证书。

动态解析规则存储部123按每个软件包，存储表示在该软件包的验证信息的生成中使用的动态解析的方法的信息(动态解析规则)。

动态解析规则例如如下。即，在第1解析部1121对tar文件进行动态解析时，首先，针对tar文件，根据该tar文件中包含的config.nice或config.status，确定软件的安装目录。接下来，第1解析部1121基于存储在所确定的安装目录中的各个文件的类型来确定各个文件是否是存在实体的文件。然后，第1解析部1121将被判定为具有实体的文件确定为能够获取哈希值的文件，并且获取该文件的文件路径和该文件的哈希值。

[处理步骤]

接着，使用图6对验证信息生成装置10的处理步骤的例子进行说明。例如，当验证信息生成装置10从使用者终端等受理了用于生成软件包的验证信息的输入时，执行以下处理。

首先，验证信息生成装置10的第1解析部1121将验证信息的生成对象的软件包安装在设备中(S111)，并且基于该软件包的动态解析规则来执行该软件包的动态解析(S112)。然后，第1验证信息生成部1122基于第1解析部1121对该软件包的解析结果来生成该软件包的验证信息(S113)。然后，第1验证信息生成部1122将在S113中生成的验证信息存储在验证信息列表存储部121中。

之后，处理受理部111在从使用者终端等受理了验证信息的修正输入的情况下(S114中“是”)，修正验证信息(S115)，再次执行从S111开始的以后的处理。另一方面，在处理受理部111没有受理验证信息的修正输入的情况下(S114中“否”)，签名赋予部113对验证信息列表存储部121中保存的验证信息赋予用户签名和用户签名的公钥证书，并保存到带签名验证信息列表存储部122中(S116：验证信息的签名赋予)。

使用图7，详细说明S112的解析处理。首先，第1解析部1121基于该软件包的动态解析规则来确定该软件包的软件的安装目的地的目录(S121)。然后，第1解析部1121确定该目录中的各个文件的类型(S122)。这里，第1解析部1121基于该目录中的各个文件的类型，对于判定为存在实体(S123中“是”)的文件，第1解析部1121从该软件包的软件的安装目的地的设备获取包名、验证信息ID、该文件的文件路径和该文件的哈希值(S124：获取包名、验证信息ID、文件路径和哈希值)。另一方面，第1解析部1121基于该目录内的各文件的类型，对于被判定为不是存在实体(S123：否)的文件不进行S124的处理。

由此，验证信息生成装置10能够通过软件包的动态解析来生成该软件包的验证信息。此外，上述的验证信息的生成处理例如既可以在验证信息生成装置10从使用者终端等受理了软件包的验证信息的生成指示的情况下执行，也可以在受理了对已有的验证信息进行了修正的意思的输入的情况下执行。

[验证处理的例子]

接下来，将描述使用由验证信息生成装置10生成的验证信息的验证处理的示例。例如，图1所示的验证装置20从验证信息生成装置10取得自身的验证装置20的验证信息，执行图8～图11所示的验证处理。首先，使用图8，对使用了验证信息中的哈希(hash)值的验证处理的例子进行说明。由验证信息生成装置10生成的验证信息被存储在验证装置20中。验证装置20基于用户签名或用户签名公钥证书确认接收到的验证信息未被篡改。在验证装置20中，将安装于该验证装置20中的软件与验证信息进行比较，将与该验证装置20一致的信息作为对照信息进行存储。这被用于文件的变更、篡改的检查。例如，在图5所示的带签名验证信息列表中，将tomcat-9.0.4和clamav-0.100的软件包的存在必需属性描述为“不是必需”。在此，如果在验证装置20中安装了tomcat-9.0.4，但没有安装clamv-0.100，则作为对照信息保存图14所记载的内容。即，验证装置20将从带签名验证信息列表中删除了实际上未安装于该验证装置20中的软件的文件的验证信息而得到的信息作为对照信息进行保存。

[使用哈希(hash)值的验证处理]

首先，当验证装置20检测到对该验证装置20内的文件的访问时，判定检测到访问的文件的路径是否与对照信息中登记的路径一致(S11)。在此，验证装置20判定为检测到访问的文件的路径与在对照信息中登记的路径一致(在S11中为“是”)，并且在该对照信息的相应路径中存在哈希值的情况下(在S12中为“是”)，判定检测到访问的文件的哈希值是否与对照信息的相应路径的哈希值一致(S13)。

在S13中，在验证装置20判定为检测到访问的文件的哈希值与对照信息的相应路径的哈希值不一致的情况下(S13：否)，由于该文件被篡改，所以完整性的判定结果是判定为NG(S14)。然后，验证装置20将该判定的结果输出到日志(S17)。

另一方面，在验证装置20判定为检测到访问的文件的哈希值与对照信息的相应路径的哈希值一致的情况下(S13：是)，判定为该文件的完整性的判定结果为OK(未被篡改)(S15)。然后，验证装置20将该判定的结果输出到日志(S17)。

此外，在S11中验证装置20判定为检测到访问的文件的路径与在对照信息中登记的路径不一致的情况下(S11：否)，判定为该文件不是保护对象(S16)，将该判定的结果输出到日志(S17)。另外，在验证装置20判定为在该对照信息的相应路径中不存在哈希值的情况下(S12：否)，也判定为该文件不是保护对象(S16)，将该判定的结果输出到日志(S17)。

[不需要的文件的追加的验证处理]

接着，使用图9，对不需要的文件的追加的验证处理的例子进行说明。首先，当验证装置20检测到对设备内的文件的访问时，判定检测到访问的文件在对照信息中是否为构成确认对象的文件(S21)。在此，验证装置20在判定为检测到访问的文件在对照信息中是构成确认对象的文件的情况下(S21：是)，判定检测到访问的文件的路径是否存在于在对照信息中登记的目录的下属(S22)。

在S22中验证装置20判定为检测到访问的文件的路径存在于在对照信息中登记的目录的下属的情况下(S22：是)，进入S23。

在S23中，在验证装置20判定为检测到访问的文件的路径与对照信息的目录的直接下属的文件名或目录名不一致的情况下(S23：否)，由于追加了不希望的文件，所以验证装置20将完整性的判定结果判定为NG(S24)。然后，验证装置20将该判定的结果输出到日志(S27)。

另一方面，在验证装置20判定为检测到访问的文件的路径与对照信息的构成确认对象目录的直接下属的文件名或目录名一致的情况下(S23：是)，判定为该文件的完整性的判定结果为OK(未追加不需要的文件)(S25)。然后，验证装置20将该判定的结果输出到日志(S27)。

此外，在S21中检测到访问的文件在对照信息中不是构成确认对象的文件的情况下(S21：否)，验证装置20判定为该文件不是保护对象(S26)，将该判定的结果输出到日志(S27)。

另外，在S22中判定为检测到访问的文件的路径不存在于在对照信息中登记的构成确认对象目录的下属的情况下(S22：否)，验证装置20也判定为该文件不是保护对象(S26)，将该判定的结果输出到日志(S27)。

[必需构成的文件的删除的验证处理]

接下来，使用图10，对必需构成的文件的删除的验证处理的例子进行说明。首先，验证装置20检测对设备内的文件的访问，在检测到访问的文件在对照信息中是构成确认对象的文件的情况下(S31：是)，判定检测到访问的文件是否存在于在对照信息中登记的目录的下属(S32)。

在S32中验证装置20判定为检测到访问的文件存在于在对照信息中登记的目录的下属的情况下(S32：是)，将该文件的完整性的判定结果判定为OK(文件未被删除)(S34)。然后，验证装置20将该判定的结果输出到日志(S36)。

另一方面，在验证装置20判定为检测到访问的文件不存在于在对照信息中登记的目录的下属的情况下(S32：否)，由于该文件被删除，所以将完整性的判定结果判定为NG(S33)。然后，验证装置20将该判定的结果输出到日志(S36)。

此外，在S31中验证装置20检测到访问的文件的路径不是构成确认对象的文件的情况下(S31：否)，也判定为该文件不是保护对象(S35)，将该判定的结果输出到日志(S36)。

[访问源的验证处理]

接着，使用图11说明访问源的验证处理的例子。首先，验证装置20检测对设备内的文件的访问，在检测到访问的文件的路径与在对照信息中登记的路径一致的情况下(S41：是)，判定在对照信息的相应路径中是否设定有访问源许可列表(S42)。

在S42中验证装置20判定为检测到访问的文件在对照信息的相应路径中设定了访问源许可列表的情况下(S42：是)，判定检测到访问的文件的访问源进程路径是否与在对照信息的相应路径的访问源许可列表中记载的路径一致(S43)。

在S43中验证装置20判定为检测到访问的文件的访问源进程路径与在对照信息的相应路径的访问源许可列表中记载的路径不一致的情况下(S43：否)，由于该访问源不被许可，所以完整性的判定结果是判定为NG(S47)。然后，验证装置20将该判定的结果输出到日志(S49)。

另一方面，在S43中验证装置20判定为检测到访问的文件的访问源进程路径与在对照信息的相应路径的访问源许可列表中记载的路径一致的情况下(S43：是)，进行检测到访问的文件的访问源进程的哈希值的确认(S44)。然后，如果检测到访问的文件的访问源进程的哈希值的确认结果不是OK(S44中“否”)，则由于该文件被篡改，所以验证装置20将完整性的判定结果判定为NG(S45)。然后，验证装置20将该判定的结果输出到日志(S49)。

另一方面，在S44中，如果检测到访问的文件的访问源进程的哈希值的确认结果为OK(S44中“是”)，则验证装置20将该文件的完整性的判定结果判定为OK(S46)。然后，验证装置20将该判定的结果输出到日志(S49)。

此外，在S41中检测到访问的文件与在对照信息中登记的路径不一致的情况下(S41：否)，验证装置20判定为该文件不是保护对象(S48)，将该判定的结果输出到日志(S49)。

另外，在S42中验证装置20判定为检测到访问的文件在对照信息的相应路径中未设定访问源许可列表的情况下(S42：否)，也判定为该文件不是保护对象(S48)，将该判定的结果输出到日志(S49)。

由此，验证装置20能够基于由验证信息生成装置10生成的验证信息，使用与安装于该验证装置20中的软件的文件相匹配地修正后的对照信息来进行各种验证处理。

此外，上述的验证处理例如也可以由验证信息生成装置10进行。

[第2实施方式]

在软件包中，存在预先指定软件的安装目的地的目录的软件包。例如，在Linux(注册商标)的rpm包、deb包中预先指定了安装目的地的目录。因此，验证信息生成装置10即使不将上述的rpm包、deb包等安装到设备中，也能够通过解析软件包自身来确定软件的安装目的地。以下，将上述那样的软件包的解析称为静态解析。

需要说明的是，rpm包是指用于管理redhat公司开发的软件包的系统。deb包是Debian或Ubuntu等Linux(注册商标)中使用的二进制包。

例如，在rpm包的情况下，在处理完成到设定之后，如以下所示，通过执行rpm命令，能够取得各种信息。

[数2]

即，验证信息生成装置10通过执行rpm命令，能够从rpm包取得包名、封装在包中的文件名、文件模式、文件类型(d：目录/c：字符设备/s：套接字/-：文件)、许可(r：文件或目录可读出/w：文件或目录可写入/x：文件可执行)、是否是文档、或配置文件和带标志文件、哈希值(MD5)、针对各个文件的验证标志的数值等。

验证信息生成装置10例如通过对rpm包执行上述的rpm命令，能够取得上述的各信息。

在此，将在包中包含的文件中的、在文件的验证时进行哈希确认的文件视为不发生文件的改写的二进制文件。因此，验证信息生成装置将上述的％{fileverifyflags：hex}的值(0x********)与0x00000001的逻辑积的值为1的文件作为用作验证信息的文件。

另外，将在包中包含的文件中的配置文件且不可写入的文件视为一旦设定就不会发生变更。因此，验证信息生成装置参照％{fileflags}的值，将配置文件且不可写入的文件也设为用作验证信息的文件。

验证信息生成装置10通过进行上述处理，生成例如图4所示的验证信息。即，验证信息生成装置10生成例如图4所示的验证信息，该验证信息包含验证信息的生成对象的软件包的包名、验证信息ID、该设备中的验证对象的文件的文件路径或目录路径信息、该文件的哈希值、存在必需属性等。

在deb包的情况下，可以通过以下命令取得在安装之后在各个包中包含的文件的文件路径和哈希值(MD5)。因此，验证信息生成装置将其作为通过以下的命令取得的验证信息来使用即可。

#dlocate--md5sum包名

因此，如果验证信息的生成对象的软件包是能够通过静态解析生成验证信息的软件包，则验证信息生成装置10也可以通过静态解析生成验证信息，如果是无法通过静态解析生成验证信息的软件包，则通过动态解析生成验证信息。将上述验证信息生成装置10作为第2实施方式的验证信息生成装置10进行说明。对与第1实施方式相同的结构标注相同的附图标号并省略说明。

第2实施方式中的验证信息生成装置10还具备图1的虚线所示的判定部114、静态解析处理部115、静态解析规则存储部124。

判定部114判定作为验证信息的生成对象的软件包是否是作为静态解析对象的软件包。例如，如果违验证信息的生成对象的软件包是rpm包或deb包，则判定部114将该软件包判定为是作为静态解析的对象的软件包。另一方面，如果作为验证信息的生成对象的软件包既不是rpm包也不是deb包，则判定部114将该软件包判定为是作为动态解析的对象的软件包。

静态解析处理部115对软件包执行静态解析，并且使用其解析结果生成验证信息。该静态解析处理部115包括第2解析部(第2取得部)1151和第2验证信息生成部1152。

第2解析部1151从静态解析规则存储部124读出用于针对验证信息的生成对象的软件包对该软件包进行静态解析的规则。然后，第2解析部1151按照读出的规则，从该软件包所包含的文件中，取得在每天的运用中变更的可能性低的文件的信息。

例如，第2解析部1151通过执行规定的命令，取得软件所包含的文件中的、在验证时进行使用了哈希值的确认的文件(例如，二进制文件)的文件路径以及该文件的哈希值、不可改写的配置文件的文件路径。第2解析部1151还获取该软件包的包名和验证信息ID(例如，序列号)。

第2验证信息生成部1152基于通过第2解析部1151对软件包的解析而获取的信息来生成该软件包的验证信息。例如，第2验证信息生成部1152基于通过第2解析部1151对软件包的静态解析获取的信息来生成表示该软件包的包名、验证信息ID、验证对象文件的文件路径或目录路径信息、该文件的哈希值、存在必需属性等的验证信息(参见图4)。之后，第2验证信息生成部1152将生成的验证信息保存在验证信息列表存储部121中，将验证信息的生成完成的情况返回给使用者终端。

静态解析规则存储部124按每个软件包存储表示对该软件包进行静态解析的方法的信息(静态解析规则)。例如，静态解析规则是如下获得的：针对rpm包执行rpm命令，取得在文件的验证时进行哈希确认的二进制文件的信息，取得作为配置文件且不可写入的文件的信息。

[处理步骤]

接着，使用图12说明第2实施方式的验证信息生成装置10的处理步骤的例子。例如，当验证信息生成装置10从使用者终端等接收到用于生成软件包的验证信息的输入时，执行以下处理。

首先，验证信息生成装置10的判定部114判定验证信息的生成对象的软件包是否是静态解析对象的软件包(S130)。在此，在判定部114判定为验证信息的生成对象的软件包是静态解析对象的软件包的情况下(S130：是)，验证信息生成装置10取得软件包(S131)。然后，第2解析部1151基于该软件包的静态解析规则，执行该软件包的解析(S132)。

然后，第2验证信息生成部1152基于第2解析部1151对该软件包的解析结果来生成该软件包的验证信息(S133)。然后，第2验证信息生成部1152将在S133中生成的验证信息存储在验证信息列表存储部121中。之后，在处理受理部111受理了验证信息的修正输入的情况下(S144：是)，将验证信息修正为适当的内容(S145)，进入S141。

另一方面，在S144中，在处理受理部111未受理验证信息的修正输入的情况下(S144：“否”)，签名赋予部113赋予验证信息列表存储部121中保存的验证信息的用户签名和用户签名的公钥证书，并保存到带签名验证信息列表存储部122中(S146：验证信息的签名赋予)。

另外，在S130中，在判定部114判定为验证信息的生成对象的软件包不是静态解析对象的软件包的情况下(S130：否)，验证信息生成装置10将验证信息的生成对象的软件包安装到设备中(S141)。然后，第1解析部1121基于该软件包的动态解析规则来执行该软件包的动态解析(S142)。然后，第1验证信息生成部1122基于第1解析部1121对该软件包的解析结果来生成该软件包的验证信息(S143)。然后，处理进入步骤S144。

由此，验证信息生成装置10对于能够通过静态解析生成验证信息的软件包，能够通过静态解析生成验证信息。

之后，例如，验证装置20使用上述验证信息，与第1实施方式同样地进行软件包的验证处理。

[程序]

另外，能够通过将实现在上述的实施方式中叙述的验证信息生成装置10的功能的程序安装到期望的信息处理装置(计算机)中来安装。例如，通过使信息处理装置执行作为软件包或在线软件提供的上述程序，能够使信息处理装置作为验证信息生成装置10发挥功能。在此所说的信息处理装置包括台式或笔记本型的个人计算机、机架搭载型的服务器计算机等。另外，除此之外，在信息处理装置中，智能手机、移动电话机或PHS(PersonalHandyphone System：个人手持电话系统)等移动体通信终端、以及PDA(Personal DigitalAssistants：个人数字助理)等也包含在其范畴内。另外，也可以将验证信息生成装置10安装于云服务器。

使用图13，对执行上述程序(验证信息生成程序)的计算机的一例进行说明。如图13所示，计算机1000包括例如存储器1010、CPU1020、硬盘驱动器接口1030、盘驱动器接口1040、串行端口接口1050、视频适配器1060和网络接口1070。这些各部分通过总线1080连接。

存储器1010包括ROM(只读存储器)1011和RAM(随机存取存储器)1012。ROM1011例如存储BIOS(Basic Input Output System：基本输入输出系统)等引导程序。硬盘驱动器接口1030与硬盘驱动器1090连接。盘驱动器接口1040连接到盘驱动器1100。在盘驱动器1100中，例如插入磁盘、光盘等可装卸的存储介质。例如，鼠标1110和键盘1120连接到串行端口接口1050。视频适配器1060例如与显示器1130连接。

在此，如图13所示，硬盘驱动器1090例如存储OS1091、应用程序1092、程序模块1093以及程序数据1094。上述实施方式中说明的数据存储部例如装备在硬盘驱动器1090或存储器1010中。

然后，CPU1020根据需要将存储在硬盘驱动器1090中的程序模块1093、程序数据1094读出到RAM1012中，执行上述的各步骤。

另外，上述验证信息生成程序所涉及的程序模块1093、程序数据1094不限于存储在硬盘驱动器1090中的情况，例如，也可以存储在可装卸的存储介质中，经由盘驱动器1100等由CPU1020读出。或者，上述的程序所涉及的程序模块1093、程序数据1094也可以存储于经由LAN、WAN(Wide Area Network：广域网)等网络连接的其他计算机中，经由网络接口1070由CPU1020读出。

标号说明

10 验证信息生成装置

20 验证装置

11 数据处理部

12 数据存储部

111 处理受理部

112 动态解析处理部

113 签名赋予部

114 判定部

115 静态解析处理部

121 验证信息列表存储部

122 带签名验证信息列表存储部

123 动态解析规则存储部

124 静态解析规则存储部

1121 第1解析部

1122 第1验证信息生成部

1151 第2解析部

1152 第2验证信息生成部

Claims (8)

1.一种验证信息生成系统，其特征在于，所述验证信息生成系统具备：

第1取得部，其在设备中安装验证对象的软件，从所述设备取得所述软件的安装目的地的目录，基于存储在所取得的所述目录中的文件的类型来确定能够取得哈希值的文件，取得所述能够取得哈希值的文件的文件路径和所述文件的哈希值；以及

第1验证信息生成部，其生成在所述软件的验证中使用的验证信息，所述验证信息包含由所述第1取得部取得的文件的文件路径和所述文件的哈希值。

2.根据权利要求1所述的验证信息生成系统，其特征在于，

在所述能够取得哈希值的文件是文本文件的情况下，所述第1取得部在所述设备中实施所述软件的设定变更之后取得所述文本文件的哈希值。

3.根据权利要求1所述的验证信息生成系统，其特征在于，

在所述软件是通过tar文件安装的软件的情况下，所述第1取得部从config.nice或config.status取得所述软件的安装目的地的目录，其中所述config.nice或config.status保存于在所述设备中展开所述tar文件的目录中。

4.根据权利要求1所述的验证信息生成系统，其特征在于，所述验证信息生成系统还具备：

判定部，其判定所述验证对象的软件是否为rpm包或deb包的软件；

第2取得部，在判定为所述验证对象的软件是rpm包或deb包的软件的情况下，所述第2取得部通过对所述软件的软件包执行规定的命令，取得所述软件包中包含的文件中的如下文件的文件路径和所述文件的哈希值：所述文件在进行该文件的验证时使用哈希值来进行确认；以及

第2验证信息生成部，其生成所述软件包的验证信息，其中所述软件包的验证信息包含由所述第2取得部取得的文件路径和所述文件的哈希值。

5.根据权利要求1至4中的任意一项所述的验证信息生成系统，其特征在于，

在生成所述验证信息之后变更了所述验证信息的情况下，所述第1取得部再次在设备中安装所述软件，取得所述能够取得哈希值的文件的文件路径和所述文件的哈希值，

所述第1验证信息生成部生成所述软件的验证信息，其中所述软件的验证信息包含由所述第1取得部取得的文件的文件路径和所述文件的哈希值。

6.根据权利要求1所述的验证信息生成系统，其特征在于，

所述验证信息生成系统还具备签名赋予部，所述签名赋予部对所述验证信息赋予安装了所述软件的设备的用户的用户签名和所述用户的公钥证书。

7.一种验证信息生成方法，所述验证信息生成方法由验证信息生成系统执行，其特征在于，所述验证信息生成方法包括如下过程：

在设备中安装验证对象的软件，从所述设备取得所述软件的安装目的地的目录，根据在所取得的所述目录中存储的文件的类型，确定能够取得哈希值的文件，取得所述能够取得哈希值的文件的文件路径以及所述文件的哈希值；以及

生成在所述软件的验证中使用的验证信息，其中所述验证信息包含所取得的所述文件的文件路径以及所述文件的哈希值。

8.一种验证信息生成程序，其特征在于，所述验证信息生成程序使计算机执行如下步骤：

在设备中安装验证对象的软件，从所述设备取得所述软件的安装目的地的目录，根据在所取得的所述目录中存储的文件的类型，确定能够取得哈希值的文件，取得所述能够取得哈希值的文件的文件路径以及所述文件的哈希值；以及

生成在所述软件的验证中使用的验证信息，其中所述验证信息包含所取得的所述文件的文件路径以及所述文件的哈希值。

Images