长期保存中的数字对象不变性研究
吴振新
中国科学院文献情报中心 北京 100190
通讯作者:吴振新:E-mail:wuzx@mail.las.ac.cn
摘要

【目的】研究在长期保存实践中如何应用不变性检查保障数字对象持久不变, 指导可信赖保存系统研发工作。【方法】通过分析保存领域的相关标准规范, 对比相关工具, 总结保存实践, 按照保存生命周期流程进行综合分析。【结果】在长期保存的整个生命周期的关键节点上(摄入、生成AIP、存储、分发), 可根据实际需求采用不同的不变性检查方法和策略实施不变性检查, 同时总结不变性信息的存储方式和不变性功能的构建方式。【结论】有利于帮助保存系统的开发人员了解和掌握不变性检查的方法和策略, 从而在实践中因地制宜地开发不变性检查功能和策略, 有效保障数字对象的持久不变性。

关键词: 不变性检查; 长期保存; 数字对象
中图分类号:G352 G359
Research on Fixity of Digital Object in Digital Preservation
Wu Zhenxin
National Science Library, Chinese Academy of Sciences, Beijing 100190, China
Abstract

[Objective] Research on how to use fixity check to ensure consistent fixity of digital object in preservation practices.[Methods] By reviewing standards and specifications, comparing fixity check tools, make a summary of current preservation projects and systems, and finally give a comprehensive analysis depending on preservation lifecycle.[Results] According to the actual needs, diversified methods and strategies of fixity check can be applied in the key nodes (ingest, AIP creation, storage, delivery) of the entire lifecycle management of digital preservation. And also do some reseach on how to store fixity information and how to build up fixity check.[Conclusions] This study may better help follow-up researchers and developers quickly understand and master the method and strategies of fixity check, help them to develop appropriate tools and strategies according to the actual need, so that preservation system can effectively ensure consistent fixity of digital object.

Keyword: Fixity check; Digital preservation; Digital object
1 引言

数字对象的易损性是其与生俱来而又令人烦恼的一个特性, 确保其持续的真实性和稳定性面临着巨大困难, 即使正常的使用也会造成数字文档损坏, 而存储文档的硬件也会随时间而腐坏, 在传输过程中更有可能会造成数字文档的部分内容丢失。因此数字资源长期保存最基本的目标就是确保存档的数字对象长时间不发生改变— — 保持数字对象的长久不变性。在这个意义上, 不变性, 在长期保存领域意味着数字对象所具有的固定、稳定、持续的特性。

数字信息的持久不变为长期保存带来了许多挑战, 人类难以察觉数字文件的更改, 任何人不可能打开保存的每个文档确认它的不变性。

为了解决这个问题, 长期保存领域一直在不断探讨数字对象的不变性检查。影响数字对象重要属性发生改变的因素有很多, 在数字保存的完整生命周期内, 如何监控和记录这些因素对长期保存数字对象产生的影响, 对于实现长期保存的最终目标至关重要。笔者在《长期保存系统监控服务内容框架研究》[1] 一文中提出长期保存系统监控服务内容框架, 作为后续的研究, 本文将对其中的不变性检查进行深入分析。

2 相关标准规范对于不变性的描述和要求
2.1 OAIS标准中的描述与功能分析

2003年成为ISO正式标准的OAIS参考模型[2], 旨在为基于长期保存目的的信息系统建立一个参考模型和基本概念框架, 以维护数字信息的长期保护和可存取。

在OAIS标准的术语部分, 将不变性信息(Fixity Information)定义为:为了确保内容信息对象不会在没有被记录的情况下而改变所提供的验证信息。例如, 一个文件的循环冗余检验码(CRC)。它认为不变性检查为内容信息提供了一个保护罩, 避免被非法变更。

作为保存描述信息(Preservation Description Information, PDI)中的一个重要组成部分, 不变性信息提供了数据完整性检查/验证的密钥, 用于确保特定内容信息对象在未经记录情况下没有被改动。不变性信息包括特殊的编码和错误检测方案。PDI中的不变性信息可以确保AIP(Archival Information Package)在移动和访问过程中没有被修改, 而PDI也需要类似的保护以维持自身不变性。因此OAIS建议, 可以采用一个标准的机制跟踪和验证保存系统中的所有数据对象的有效性。例如, 可以为每个单独的数据文件维护其CRC信息, 也可以提供更高水平的服务, 如Reed-Solomon编码以支持综合误差检测和校正。

OAIS的不变性信息并不包括OAIS底层服务所提供的完整性保存机制, 也不包括由存储介质和设备驱动程序提供的错误保护机制, 不变性是这些机制的最基本要求。因此可以利用储存设施的程序, 提供利用CRC或者其他错误检查机制随机验证数据对象的不变性。

在OAIS的“ 存档存储” 模块中, 具体涉及不变性检查的功能是错误检查, 该功能负责确保AIP的任何部分在保存系统内部进行存储数据传输过程中没有被损坏。它需要归档过程中所有硬件和软件都能够提供错误通知, 而且这些错误能够被发送到标准的错误日志中供存档人员检查。

2.2 PREMIS数据字典中的定义与描述

PREMIS是支持数字对象长期保存并确保长期可用性的元数据国际标准。

在PREMIS数据字典[3]中, 将不变性信息定义为:用来验证一个对象是否在没有记录或未经授权的方式下被改动的信息。PREMIS认为数字对象的不变性、完整性和真实性是数字对象的核心元素, 缺乏这些特征的数字对象就失去了长期保存的价值。

在PREMIS数据字典中, 不变性信息是由语义单元objectCharacteristics中的一组语义内容描述的, 包括信息摘要算法、信息摘要以及摘要的生成者, 如下:

Entity Semantic Units

  1.5 objectCharacteristics (M, R) [file, bitstream]

      1.5.2 fixity (O, R) [file, bitstream]

          1.5.2.1 messageDigestAlgorithm (M, NR) [file, bitstream]

          1.5.2.2 messageDigest (M, NR) [file, bitstream]

          1.5.2.3 messageDigestOriginator (O, NR) [file, bitstream]

为了执行不变性检查, 需要将一个早期计算的消息摘要与随后计算的信息摘要进行比较, 如果两个摘要是相同的, 则证明该对象在两个时间点之间没有发生改变。PREMIS推荐的做法是使用两个或两个以上不同的算法创建和测试消息摘要。

PREMIS将执行不变性检查的行为和发生的日期作为一个Event事件记录, 检查的结果会被记录为eventOutcome。messageDigestAlgorithm和messageDigest则被记录在objectCharacteristics中用于未来的不变性检查和比较。

PREMIS认为不变性检查可以在两种层面上执行:

(1) 表示层:如果一个表示文档只对应一个单独的文件, 或者一个表示文档只对应一个包文档(即所有文件被组合到一个文件中, 如压缩包), 这样就可以对表示层执行不变性检查。这两种情况的不变性检查实际上是在文件上执行的, 是比较有代表性的表示层不变性检查。

(2) 比特层:这种检查是计算一段比特流的消息摘要, 与常见的针对一个文件的不变性检查不同。例如, JPX格式是一种JPEG2000格式, 它支持计算文件任何范围的字节内容的MD5或SHA-1, 并存储在该文档的内部元数据中。

另外数字签名技术也是PREMIS的重点内容, 它建议在数据对象的提交、分发和存档存储过程中使用数字签名技术确保数字对象的真实性和完整性。Fixity与数字签名的重点有所不同, 数字签名主要用于保证信息传输的完整性、发送者的身份认证, 其中该技术在计算信息完整性所使用的算法和工具与Fixity相同或类似。

2.3 可信赖仓储认证标准的要求与描述

经过近10年的研究发展, 《可信赖数字仓储审核与认证:指标体系与核查表》在2012年发布成为ISO正式标准ISO16363[4], 该标准全面分析了影响长期保存活动可信赖性的内容和行为, 已经成为众多保存系统开发和完善的基本准绳。

标准主要在第4部分“ 对象管理” 和第5部分“ 基础设施及安全风险管理” 涉及了与不变性相关的要求。

按照OAIS的主要功能模块, 标准依次从摄入、存储保存、分发进行了分析。认为从生产者处接收SIP(Submission Information Package)到创建AIP和支持长期保存, 存储库都应记录如何保障AIP的完整性和正确性。在访问管理环节, 标准也要求存储库应遵循一定政策和程序来分发数字对象, 并且能够验证其真实性。标准特别要求在AIP的PDI中应包含Fixity信息。同时建议可以为PDI生成校验和或者数字摘要来保障PDI的持久不变。另外还建议可以利用校验和, 在摄入和长期保存过程中, 在不同的点检查校验和的正确性, 并存储所执行检查的日志, 以及任何一个特殊AIP实例或类所需的特殊检查。

同时该标准要求存储库应采取积极措施监测AIP的完整性, 针对大部分存储库是通过校验和(如MD5)在个体信息级别进行不变性检查的情况, 它建议存储库应将不变性信息与AIP分开且被单独存储或者保护, 这样即使AIP被修改, 也能保证不变性信息不会发生改变。同时, 应建立某种机制, 确保即使某人有能力恶意篡改AIP, 也很难改变不变性信息。同时标准要求对AIP所实施的所有操作行为, 应严格按照存储库提供的操作规程执行并予以记录, 以保证任何没有违反规定的活动改变了AIP信息。

标准建议存储库应建立完整性检查的整体方案, 定期进行存储库资料的完整性分析。其中特别强调需要在比特层面提供有效的机制来检测位损坏或丢失, 以确保AIP和元数据未被破坏, 另外对数字对象备份也应通过不变性检查进行可信性管理。

2.4 NDSA的数字资源长期保存级别

美国国家数字监管联盟(NDSA)发布的“ 数字资源长期保存级别” [5](Levels of Digital Preservation, 简称“ 保存级别” ), 是一套分层次的技术实践指南, 旨在为保存数字内容提供清晰的技术基准说明, 同时允许机构对他们保管的特殊资源进行保存级别评估。该指南把数字资源长期保存系统的功能分为5个核心区:存储和地理位置、文件不变性和数据完整性、信息安全、元数据以及文件格式, 并提供了4个渐进的层级, 指导机构逐步实施保存方法确保内容的不变性, 如表1所示:

表1 数字资源长期保存的级别第一版[5](节选)

第一级的要求相对简单, 如果提交者提交的内容附带有不变性信息(如MD5和SHA-1), 则存档者要在摄入阶段进行比较检查, 否则要创建不变性信息。对于长期保存来说有必要验证要保存的内容是他们想要保存的内容, 这意味着保存者在收到内容后, 需要生成新的校验和, 并与在传输之前创建的校验和进行对比。

接下来的每个级别都增加了额外的处理以进一步确保内容的完整性。值得注意的是, 第二级需要检查所有摄入对象的不变性, 在第三级和第四级持续检查数字内容的需求变得越来越强烈。第三级和第四级的需求从对特殊存储媒介的质量和性能的信任转移到通过重复持续检查数字内容来确保保存。这样不但能提供更高级别的保证, 而且更有能力和信心声明所管理的内容的不变性。

由于各种复杂的问题及原因, NDSA的众成员在实践中采取完全不同的方法检查其内容的不变性。

3 不变性检查在长期保存领域的应用现状分析

斯坦福大学的LOCKSS系统[6], 使用Opinion Polls机制, 利用存档相同内容的多个结点定期进行内容文档的比较和监控, 采用约定的算法计算各自指定存档内容的信息摘要并统计投票(Polling), 以此来判断存档内容的正确与否并实现修复。

Fedora Repository[7]是康奈尔大学研究的对数字内容进行存储、管理及获取的开源仓储系统。Fedora使用MD5验证其数字对象的不变性, 它可以为每个存档对象的数据流片段(Datastream)及其每个版本生成并保存MD5, 以便随后实现数字对象的不变性校验。同时Fedora提供了一个特殊的数据流— — “ AUDIT” Datastream, 用来记录该数字对象的所有修改操作, 该数据不能被编辑, 只受系统控制。AUDIT数据流为每个操作创建审核记录, 记录对象变化涉及到的人、时间、修改内容、原因。

DAITSS系统[8]通过存储池(Silo Pool)的方式管理存储。每个存储池有一个数据库用来保存本地副本的原始校验码和最新计算的校验码以及一些历史性信息包括初次存储时间、所有的不变性检查、删除时间、包丢失时间等。DAITSS存储服务维护多个存储池, 存档包的多个副本保存在不同的存储池中, 一个存储池中一个包最多有一个副本。DAITSS的保存数据库中保存所有存档数据的保存元数据和操作元数据, 包括所有存档包的不变性信息。DAITSS的不变性检查包括存储端不变性计算和重新评价两个子过程, 分别由对应的脚本应用执行。存储端不变性计算对存储池中的每个副本计算新的校验码(MD5和SHA1), 更新存储池数据库并报告不一致情况, 包括不变性检查失败、丢包、错包等。对于存档的每个包, 重新评价过程比较每个副本的校验码与DAITSS保存库中的校验码是否一致、是否保存了要求的副本数、是否全部丢失或没有副本、更新DAITSS保存数据库中不变性事件记录以反映检查结果、生成检查结果报告。

UC3的 Merritt仓储库[9]在摄入和长期保存期间都使用了不变性检查。在摄入阶段, 该检查被直接内置在摄入模块中, 对提交的数据进行文件层面的校验, 即对每一个文件都进行校验、计算、比较, 所以它要求提交数据的同时, 还要提交包含摘要信息的清单Manifest。Merritt在保管(Curation)周期中以微服务的方式嵌入到系统存储服务中, 在监控(Monitor)环节中提供不变性检查用于验证文件的比特级完整性, 该服务以多种类型的接口方式提供, 并支持各种常用的摘要类型, 包括adler-32、MD5、SHA-1、CRC-32、SHA-256、SHA-384、SHA-512等。通过配置服务, 可以在任意时间实施不变性验证。

明尼苏达州历史协会(MHS)委托Instrumental公司为其提供了一份《数字保存和云服务报告》[10]。对于云中隐形数据腐烂(Silent Data Corruption), 报告认为MHS需要有一个可在MHS云存储内部和外部均能对数据完整性进行验证的框架。除了使用云供应商提供的校验机制保证数据迁移到云端后的完整性之外, MHS必须在数据存入云端前, 为原始版本生成校验和并保存在本地, 以便定期与云中数据对比检查。该报告建议MHS应该对文件进行抽检, 保证每月有1%的文件得到验证。

这个报告还对多个云服务提供商的数据完整性服务进行了统计, 如表2所示:

表2 云服务提供商的数据完整性服务

DuraCloud提供了多种方式供用户进行不变性检验, 用户可以人工运行“ Checkups” 进行Checksum检查, 也提供基于文件获取的自动Checksum服务, 它们还对大于1TB的用户提供健康检查, 利用Amazon Hadoop簇检查任意指定空间里每一个文件的Checksum。

长期保存学术网格SDSC采用开源软件OpenStack作为云管理平台, 默认采用保存三个副本的策略。OpenStack通过内置的对象审计功能提供持久性和数据完整性监测, 在遇到位腐烂(Bit Rot)的情况时, 即一个文件的校验和不再匹配, 系统就会自动隔离此文件并利用其他副本重新复制一个对象。实际上它的网格位腐烂监测和校验都是通过文件校验来实现的。

其他还有很多机构在保存仓储库中采用了不变性检查[11]。耶鲁大学图书馆的救援仓储库(Rescue Repository)在摄入过程中使用SHA1和MD5算法, 这些值被保存在文件中与摄入资源一起存储。哈佛仓储库要求提交的存档对象必须提供MD5, 用来验证在从存缴者系统到Drop Box(中转)以及最终进入仓储库的传输过程中数字对象的完整性, 同时也用于仓储库中长期存档文件的有效性验证。

美国NDIIPP在“ 基础架构和归档摄入及处理测试” 中, 测试了多个机构之间传输数字档案的可行性和效果, 其中即包括摄入前后的MD5不变性验证。

4 基于OAIS的不变性检查框架

基于上述相关标准的分析, 可以把不变性检查分为两大类:

(1) 统计性不变性检查。相对比较简单, 以统计文档数量和文件大小进行对比检查;

(2) 内容不变性检查。多采用不同的算法对文档内容(全部或片段)进行计算、比较, 以确定其是否发生变化。其中内容不变性检查可以从两个层面进行:表示层(针对文件整体, 包括压缩包.zip等); 比特层(一段比特流, 如文件的片段)。

在长期保存的整个生命周期管理中, 几乎每个流程都涉及不变性检查, 为了更简明清楚地展示上述研究结果, 笔者将不变性检查进行归纳, 如图1所示:

图1 基于OAIS的不变性检查框架

4.1 不变性检查框架概述

(1) 数字对象的接收过程

利用数字对象的不变性信息, 可以检验存档系统收到的数字对象是否是预期要接收的。这个阶段应涵盖统计性检查和表示层不变性检查。

比较理想的方式是内容提供者在提交内容对象的同时提供提交清单(其中包含不变性信息), 接收者可以利用清单对接收的数字对象进行清点检查, 如文件数量和文件的大小等, 更重要的是利用不变性信息对接收的每一个数据包或文档进行不变性校验。

如果没有提供清单类的信息, 特别是不变性信息没有作为传输的一部分而提供, 那么一旦接收者收到提交数据就要进行处理, 生成相关信息(不变性信息)。

(2) AIP生成过程

基本原则是考虑将不变性信息作为PDI信息的一部分与AIP一起保存。在生成AIP时, 可以考虑一个全面的策略, 涵盖表示层和比特层的不变性检查, 例如既可以为每个AIP生成不变性信息, 也可以参考Fedora仓储库的机制, 为AIP中的每个组成部分也生成独立的不变性信息并保存, 以便于日后对每个组成部分的独立校验, 也可在生成AIP之后将其与SIP内容进行对比, 确保AIP内容的来源正确性。ISO16363标准建议:在摄入和长期保存过程中的不同时间点, 可利用校验和检查不变性, 同时要保存不变性检查的日志, 另外为任何一个特殊AIP实例或类提供的特殊检查也需要被记录。

(3) 在长期存档管理过程中

保存系统常见的方式是在存档期间对数字文件和对象的集合进行不变性检查。利用已保存的数字对象(或文件)的不变性信息, 与将来所产生的不变性信息比较, 用以检验一份文档是否已经改变或破坏。

很多系统会定期检查所有对象的不变性值, 例如每月、每季或每年。通过定期检查, 更有可能检测出错误, 如果有副本, 还可以通过这些副本进行错误修复。此时可采用更为全面的检查策略, 涵盖统计性检查、表示层检查和比特层检查。如对AIP的完整性检查, 可以根据AIP结构定义检查AIP中所有组成是否都存在, 重新计算每个组成成分(如一个文档)的不变性值进行对比, 甚至可以对一个文件的一个片段或部分(Segment or Portion)进行不变性检查, 以确定某些重点内容的安全存储。

同时建议上述检查同样适用于存档数字对象的备份, 确保可信副本的存在以及错误修复的可行性。

另外在执行不变性检查过程中还要关注保存事件的影响, 按照OAIS和PREMIS的描述, 是允许在记录或经授权的方式下改动相关信息的, 所以如何判断数字对象是否是在保存系统允许的情况下发生变化的, 主要依据所记录的保存事件。因此不能简单地运用算法即给出判断, 所以保存系统对于相关保存事件的记录也成为不变性检查中非常重要的一部分内容。

(4) 存档数据分发过程

将用户所需的数据以及其不变性信息同时发送给用户, 能够确保提供给用户的信息(副本、片段或部分)的真实性。

不变性信息还有很多用处:修复已破坏或改变的数字对象(文件); 监控硬件退化; 能够证明符合可信赖认证的标准要求或执行最佳实践(例如:ISO16363/ TRAC、NDSA的数字保存水平); 支持对数字对象的生产过程或数字化过程实施监控; 支持文档起源管理和保管链; 在对保存内容的管理周期中, 帮助诊断可能出现的系统或人为错误。

4.2 不变性检查的构建方式

不同保存系统采用不同方式构建不变性检查功能[12]。有些是在整个保存框架中建立独立的模块, 有些是被内置到保存系统中。

大多数使用REST接口的对象系统, 已经将不变性内置在系统中以便定期进行数据检查, 如LOCKSS和DAITSS。Fedora Repository在系统中内置了生成MD5的功能, 没有提供检查比较的功能, 需要使用该仓储的用户自行开发执行检查的模块。

图2所示的Sun-Oracle提供的开放保存框架(Open Archive Framework, OAF)中, 在第三层Preserve层(Storage Preservation Software Layer), 整合OpenSolaris操作系统、ZFS文件系统[13]、SAM(Storage Archive Manager)共同构建了管理控制功能, 有效利用文件系统提供的功能辅助实现不变性检查。与简单的磁盘块校验码不同, ZFS文件系统可通过定期计算块层面的校验和(如SHA256)检测出错位写、误导的读取和写入、DMA(直接存储器读取)校验码错误、驱动程序漏洞、意外的覆盖写入和传统的“ 比特腐烂” 。其他文件系统如HDFS、GPFS、LustreFS、Btrfs也都通过不同方式提供相似功能。

图2 Open Archive Framework[14]

OAF同时还能够利用存储系统自身的功能和管理系统建立不变性检查。大多数存档系统(如HSMs)能够对磁带上每个文件计算校验和, 并能用新的磁带技术对磁带系统每个块的校验和进行校验。

在HathiTrust项目中, 同样也利用Isilon[15]系统保障存储库的数据完整性, 主要是通过提供持续的Checksum校验保障数据的完整性, 检查和修复由于位腐烂或内容受损带来的错误。

UC3的 Merritt系统在摄入阶段是将不变性检查直接内置在摄入模块的代码中, 存档保存过程中则以微服务的方式在监控(Monitor)环节提供不变性检查。微服务的交互方式包括:

(1) 提供各种语言绑定的过程API。

(2) 支持各种操作系统命令Shell的命令行方式的API。

(3) 包括支持不同的浏览器平台的瘦客户端的图形用户界面以及RESTful 服务接口的两种Web APIs。

在长期保存云存储DuraCloud中, 不变性检查被作为基本长期保存服务提供。其所有可提供的服务都以Service Package(服务OSGi Bundles及支持文档)方式存放在服务管理器(Service Manager)中, 根据用户需求将这些服务安装到OSGi Container中运行。不变性检查作为一项服务, 同样被封装成OSGi Bundles以供调用。

长期保存学术网格SDSC利用OpenStack云平台管理软件内置的对象审计功能提供持久性和数据完整性监测。

从上述分析可以看出, 保存系统可以采用不同方式构建不变性检查功能, 并应充分利用底层的基础设施, 如操作系统、文件系统和存储系统管理软件。本文推荐针对不同层级对象的不变性检查, 采用不同的方式构建不变性检验功能, 针对文件集层面的检查可有效利用文件系统的不变性检查, 针对独立文档或独立文档片段的检查常常要在保存系统层面进行, 如果是进行大规模数据的全面的不变性检查, 那么存储系统管理软件的辅助恐怕是一个更经济适合的选择。

4.3 不变性信息的存储与保护

在不同的情况下, 可根据不同目的将不变性的信息存储在不同的地方[12]:

(1) 存储在所属文档里:如果校验和是针对一个文档的片段, 那么在文档中直接存储这些信息更有意义。但是在文件中添加这个信息将导致文件本身作为一个整体的不变性信息发生变化。

(2) 跟内容一起保存:理想情况是将不变性信息与内容本身一起保存。例如, Bag-It规范包含内容本身和被打包内容的哈希值。

(3) 存储在对象的元数据记录:如Fedora仓储, 作为元数据的一部分存储。

(4) 存储在数据库和日志里:如DAITSS系统。

(5) 存储在独立的文件里:如MHS。

(6) 混合存储方式:针对不同的数据采用不同的存储方式, 如中国科学院文献情报中心的数字资源长期保存系统, 其存档对象的MD5是存储在元数据中, 其备份数据的MD5则保存在管理数据库中。

但也有不存储不变性信息的例子, 如LOCKSS系统, 利用存档相同内容的多个结点即时计算比较。

从安全角度考虑, 不变性信息与AIP应被分开存储, 确保AIP和不变性信息不会同时发生改变。同时应建立相应权限机制, 确保不同人群对于AIP和不变性信息有不同的权限, 不能让某人同时具有修改AIP和不变性信息的能力, 这样可为数字对象的不变性提供更多一层的保护。

另外作为一种数字信息, 不变性信息本身也需要与内容同样严格的保护。通过冗余和复制实现的灾难恢复同样适用于不变性信息。理想情况下, 除了被保存在保存系统中, 不变性信息还应该采用其他的长期保存方法进行保存。

4.4 不变性检查算法和工具介绍

目前有多种算法可以供不变性检查采用, 如Adler- 32、CRC-32、MD2、MD5、SHA-1、SHA-256、SHA-384、SHA-512, 也有人对这些常用算法做过比较[12]

由于上述各算法产生的校验和大小不同, 因而安全性不同, 摘要长度越长, 破解难度也就越大, 安全性也就越高。目前常用的CRC、MD5、SHA1都已出现破解技术, SHA256尚处于安全状态。但更高的安全性意味着需要更多的时间和资源用于计算, 因此基于拥有的数据量和资源的多少, 在不同的不变性信息核查工作流中, 每一种工具都有自己的地位和作用。CRC对于快速生成不变性信息简单易用, 然而如果资源允许的话, 最好采用性能更为卓越的MD5、SHA1和SHA256。对于数据不变性检验, MD5或SHA1常常更为有用[16]

就保存领域目前的使用情况而言, 较多采用MD5算法。除了系统中集成这些算法外, 还有一些长期保存的工具也集成了这些算法, 例如Bagger(基于Bag-It规范建立的用于传输数字内容的工具)为每个创建的文档“ 包” 生成一个“ manifest” , 其中即包括MD5校验和。当接收后对包里的文档进行验证时, Bagger能够确认包里的每个文件以及每个文件所包括的不变性信息。PREMIS标准中推荐使用不同的算法生成原始数据的不变性信息进行存储。

目前已经有为长期保存目的专门开发的工具。ACE (Auditing Control Environment)[17]是由马里兰大学ADAPT项目开发的一款用于解决长期存档完整性问题的开源工具。它采用严格的加密技术, 能够根据存档政策连续地审计大量保存对象的内容, 并为独立的第三方审计人员提供验证保存对象完整性的机制。

5 结语

以上对长期保存领域的数字对象不变性及不变性检查做了比较全面深入的分析, 但考虑到实践中的复杂环境和多样化的应用需求, 还有一些需要深入思考的问题[9]

(1) 不变性信息本身的保护。数字资源的真实可信源于不变性信息提供的保障, 如果发生不变性信息不匹配的情况, 那么意味着内容或者不变性信息这两者都有可能发生变化。因此作为一种数字资源, 不变性信息本身也需要与内容同样严格的保护。

(2) 考虑摘要算法的更新机制。随着时间的推移, 用于生成不变性信息的加密算法可能会变得脆弱, 如MD5和SHA1相继公布了被破解的消息, 所以数字保存系统应考虑摘要算法的更新机制。

(3) 关注保存事件对不变性检查结果的影响。保存系统应对相关保存事件予以详细记录, 以帮助判断数字对象是否是在保存系统允许的情况下发生了变化。

(4) 建立分级的不变性检查服务。生成、存储、复制、验证消息摘要需要一定的人员和系统成本, 应考虑为数字资产建立不同级别的不变性检查服务。如区分内容的保护级别, 可以对冗余副本的不变性检查有不同的做法; 区分主从文档, 对于用作长期保存的主文档和派生文档或访问副本, 也可采用不同的做法。

(5) 建立适当的不变性检查策略。综合考虑文件系统或对象系统级别的保护。如果文件或对象系统本身在块级进行频繁的检查, 就不需要特别把位腐烂作为不变性的威胁, 也就不必对文件进行频繁的检查。

(6) 考虑不变性检查对基础设施中其他服务的影响。不变性检查通常会增加媒体以及读取和控制媒体的机械装置的使用, 这些都是影响媒体整体可靠性的因素。同时不变性检查活动会耗费基础设施资源(如带宽、计算能力、空间), 因而会对其他的重要功能产生不利影响, 如用户访问。

(7) 了解第三方的不变性检查服务保证, 如云存储供应商。如果不是自己做检查, 那么会面临如何信任第三方的情况, 既需要了解第三方对不变性检查提供了何种支持, 同时还要了解检查的频率和细致度。

总的来说, 不变性检查对维护数字对象的不变性和完整性发挥着重要作用。目前的实践情况看, 如果能够综合考虑机构各自的基础设施和需求, 通过制定合适的策略, 采用软硬结合的方式, 能够在一定程度上有效保障数字对象的长期不变性。

参考文献
[1] 吴振新, 付鸿鹄, 马海收, . 长期保存系统监控服务内容框架研究[J]. 图书情报工作, 2014, 58(3): 51-57, 94.
Wu Zhenxin, Fu Honghu, Ma Haishou, et al. Study on Monitoring Service Frameworks of Digital Preservation Systems[J]. Library and Information Service, 2014, 58(3): 51-57, 94. [本文引用:1] [CJCR: 1.193]
[2] Reference Model for an Open Archival Information System [EB/OL]. [2014-04-24]. http://public.ccsds.org/publications/archive/650x0m2.pdf. [本文引用:1]
[3] PREMIS Data Dictionary for Preservation Metadata [EB/OL]. [2014-04-24]. http://www.loc.gov/standards/premis/v2/premis-2-2.pdf. [本文引用:1]
[4] Space Data and Information Transfer Systems —— Audit and Certification of Trustworthy Digital Repositories [EB/OL]. [2014-04-24]. http://www.iso.org/iso/catalogue_detail.htm?csnumber=56510. [本文引用:1]
[5] Phillips M, Bailey J, Goethals A, et al. The NDSA Levels of Digital Preservation: An Explanation and Uses [EB/OL]. [2014-04-24]. http://digitalpreservation.gov/ndsa/working_groups/documents/NDSA_Levels_Archiving_2013.pdf?loclr=blogsig. [本文引用:1]
[6] Rosenthal D S H, Reich V. Permanent Web Publishing [EB/OL]. (2000-01-18). [2014-04-24]. http://static.usenix.org/events/usenix2000/freenix/full_papers/rosenthal/rosenthal.pdf. [本文引用:1]
[7] Fedora Digital Object Model [EB/OL]. [2014-04-24]. https://wiki.duraspace.org/display/FEDORA37/Fedora+Digital+Object+Model. [本文引用:1]
[8] Chapter 8: Fixity [EB/OL]. [2014-04-24]. https://share.fcla.edu/FDAPublic/DAITSS/Chapter_8_Fixity.pdf. [本文引用:1]
[9] University of California Curation Center. Merritt Ingest Service [EB/OL]. (2011-11-30). [2014-07-02]. https://confluence.ucop.edu/download/attachments/16744573/Merritt-ingest-service-latest.pdf?version=18&modificationDate=1322700627000. [本文引用:2]
[10] Toussaint M G, Round S. Report on Digital Preservation and Cloud Services[R/OL]. (2011-11-30). [2014-07-02]. http://www.mnhs.org/preserve/records/docs_pdfs/Instrumental_MHSReportFinal_Public_v2.pdf. [本文引用:1]
[11] Novak A. Fixity Checks: Checksums, Message Digests and Digital Signatures[EB/OL]. [2014-04-24]. http://www.library.yale.edu/iac/DPC/AN_DPC_FixityChecksFinal11.pdf. [本文引用:1]
[12] Checking Your Digital Content: How, What and When to Check Fixity? [EB/OL]. [2014-04-24]. http://blogs.loc.gov/digitalpreservation/files/2014/02/NDSA-Checking-your-digital-content-Draft-2-5-14.pdf?loclr=blogsig. [本文引用:3]
[13] 分析: SUN文件系统ZFS流行的十大理由[EB/OL]. (2009- 11-27). [2014-05-20]. http: //digi. tech. qq. com/a/20091127/001007. htm.
Analysis: Ten Reasons of the Popularity of SUN File System ZFS [EB/OL]. (2009-11-27). [2014-05-20]. http://digi.tech.qq.com/a/20091127/001007.htm. [本文引用:1]
[14] Sun Open Archive Framework and Fedora Repository Solutions [EB/OL] . (2009-06). [2014-07-02]. http://www.library.umass.edu/wikis/dlgr/lib/exe/fetch.php?media=fedora_repository_solutions.pdf. [本文引用:1]
[15] Isilon System [EB/OL]. [2014-07-02]. http://www.emc.com/domains/isilon/index.htm. [本文引用:1]
[16] CRC32、MD5、SHA1算法校验介绍[EB/OL]. (2013-02-18). [2014-04-24]. http: //www. siqiboke. com/post/121. html.
Introduction to CRC32, MD5 and SHA1 [EB/OL]. (2013-02-18) [2014- 04-24]. http://www.siqiboke.com/post/121.html. [本文引用:1]
[17] ACE (Auditing Control Environment)[EB/OL]. [2014-07-02]. https://wiki.umiacs.umd.edu/adapt/index.php/ACE [本文引用:1]