智能卡的文件管理

　　智能卡里的所有文件都存放在EEPROM里。这是智能卡中惟一的－种在没有电源的情况下能够持续保存数据 而在必要时也允许改变数据（当取得适当电源时）的存储器。它也是提供了把信息从一个会话期保存到下一 个会话期的惟一方法，因为在RAM里的内容当智能卡掉电时就会丢失，而ROM里的内容在芯片制好之后就不能 改变了。

　　在早期的智能卡里，文件是采用实际地址直接访问的。实际上，还没有一个按字面意义理解的真正的文件 。相反，整个存储器可从外边线性地寻址，并可以使用读取和写入命令来进行访问。当然，这在现代的操作 系统中是不允许的，原因在于保密和应用的需要。面向对象的文件管理直接把访问条件的信息放在文件里是 目前的标准方式。编制和管理这些文件就是操作系统里文件管理器的任务。

　　采用面向对象的结构，每一个文件都必须带有一个文件描述符，它包含着有关文仵本身的所有信息。在智 能卡技术方面，文件描述符被称之为文件头标，一个文件的数据内容，换句话说就是有用的数据，则放在文 件“体”内。

　　包含在文件头标里的信息在很大程度上取决于文件管理器的特点。然而，文件描述符则必须至少包含有以 下的条目：

　　·文件名                    （例如：FID='0001'）；

　　·文件类型                  （例如：EF）；

　　·文件结构                  （例如：线性定长）；

　　·文件大小                  （例如：3条记录5字节）；

　　·存取条件                  （例如：READ＝PIN代码被输入之后）；

　　·属性                      （例如：WORM）；

　　·链接到文件树              （例如：直接在MF之下）。

　　对于BF或MF来说，文件名是两字节的FID（文件标识符）。在DE里，AID（应用标识符）也成为文件名的一 部分。文件类型可能是MF，DE或EF，也必须注明。

　　取决于文件的类型，在文件头标里可以有一个数据元是描述文件内部结构的（透明，线性定长，线性变长 ，循环或可执行的）。有关透明数据部分的长度或记录的数量与长度等所有信息也都取决于文件的类型。

　　在文件的所有基本性能已说明过之后，操作系统还需要详细的存取条件的规定。这些就是定义在哪个状态 下哪个命令可以访问文件以及可以允许做什么类型的存取处理。存取条件必须针对每一条可能的命令逐一进 行规定。特殊文件属性，诸如修改灵活性，WORM或EDC保护等，如果文件管理器支持的话，也可以指明。

　　所有上述与文件有关的信息都被作为一个单独的数据对象。为了定义文件在文件树里的位置，还需要一个 附加的指针来规定文件在MF或DE里的确切位置。

　　在简单的操作系统中，文件头标都有固定的长度，它取决于文件类型（MP，DF或EF）。这样就减少了内部 文件管理器耗费在计算和管理上的工作量。这样安排的主要缺点就是在扩展时比较起来不怎么灵活。另一个 缺陷就是对任何一个EF，不允许有无限量的不同的存取条件，或甚至是一个非常大量的访问条件。存储器必 须取消在头标中未被绝大多数应用充分使用的大量访问条件的存储。因此，可变长度的文件头标正越来越多 地应用到智能卡的文件管理之中。智能卡操作系统可自由地使这些文件头标的长度适应于各个应用的特殊需 求。一个智能卡文件管理系统的头标的可能的构造和2所示。

　　图1 智能卡文件管理系统中ME，DE以及BF（内部的和工作的）等可能的文件头标构造概要（粗边框表示TLV编码的数据元必须存在，而细线框表示可选数据元。编号只是在文件所位于的目录范围内有效，因而不是对全局所有文件的。这种结构基于Small-OS所规定的简单文件管理系统的需求）

　　图2 在智能卡文件管理系统中的内部和工作BF的可能的文件头标结构简图（所有TLV编码的数据对象都必须予以展现，这种结构是基于蹴Small-OS所规定的简单文件管理系统的需求）

　　文件系统中对指针和数据的可能安排则示于图3中，每个目录的有效范围都界定的很明确。

　　图3 在智能卡文件管理系统中对指针和数据结构的可能安排简图（它基于

　　Small-OS中规定的简单的文件管理系统的需求，虚线标定了每一目录

　　可用的存储器范围）

　　1．把存储器分割为页面

　　EEPROM的有限写入/擦除循环次数和把存储器分割为页面引发文件管理的一个普遍的问题，它对于文件管理 器的整个设计和内部文件的结构有相当的影响。文件头标和文件体二者都必须适合于存储页面预订的大小， 以防止它们被页面边界所分裂。在存储器中的文件管理信息也必须严格和真实的文件的数据内容相互分开。 如果情况不是这样，不期望的副作用就会在头标中的管理数据和文件体内的有用数据之间发生。它可能会破 坏智能卡操作系统整个的内部安全结构，这一点将在下面的例子中简要说明。

　　假定一个文件的访问条件中含有秘密的、不可读的密钥和另一文件公开的可写入的数据存储在同一存储器 页面上。如果对此文件的写操作被中断了，例如由于把卡取出了终端，这将会影响到存储在同一页面上的访 问条件，在最坏的情况下，完全没有访问条件被保留。于是含有秘密密钥的文件将能被任何人读出。对内部 文件的结构来说，管理的和有用的数据各自在分别的页面上是至关重要的。

　　2．DF分割

　　理解DF的功能的另一个方法是把它看成是能被一特定应用可使用的所有存储器的代表。在此区域内，应用 的拥有者对其应用负全责并基本上可以做或允许做需要的事。应当没有任何可能以任何方式超出自己的区域 去访问另一个应用或去读出与修改在另一个区域中的数据。因此，某些智能卡操作系统具有专门的机制以检 查每次存储访问的实际地址是否位于现行DE的边界之内。如果情况不是这样，则是一严重的内部差错，从而 取消此处理。

　　由于缺少硬件支持，这种地址监督现在已由操作系统中适当的软件程序执行了。这种方案的安全性当然要 比用适当硬件所能达到的要低多了，因为它比较易于绕开。在未来，智能卡微控制器将可能含有存储管理部 件（MMU），就和现代的CPU一样。这将很容易用来在一DE之内达到对存储器的安全控制。不过目前的惟一选 择仍是用适当的操作系统程序去监督DE的地址边界。

　　3，自由存储器管理

　　存储空间的很小容量对智能卡操作系统关于EEPROM的自由存储量的管理给以了主要的限制。只是最近才有 操作系统有可能在卡被个人化之后能建立文件（DE和EF），并且随后可以删除它们。给定智能卡的安全特性，它就当然要以密码学上无懈可击的方式受到保护。理想的方案是在初步的相互鉴别之后，以安全报文模式执行适当的命令。

　　具有给新DE和BF分配存储量的自由存储管理能较容易地集成到操作系统中去。不能低估这些文件在稍后能被删除掉时所需增加的程序量。毕竟，这意味着数据管理器至少要有识别用链接表连接文件头标的基本能力。还必须确信在处理过程中，突然电源失效，例如由于把卡从终端中取出，文件树仍保留为良好的规定状态。如果文件指针突然成了不确定的，智能卡正好是在这种状态则其安全性就会完全崩溃。对此问题，原子进程是一种极其有用的补救。

　　复杂性的第2个方面来自对整个文件区域，或者理想地是对每一DF分别真正自由的存储管理。对此，要达到一种状态，即和我们大家都已从PC中熟悉了的同一状态。文件可以建立和删除，乃至于其他文件的建立，都在存储器中是自动管理的。然而，这只有很大量的软件才有可能，虽然这种能力是普遍都期望的。为此，所必须付出的代价按ROM存储器而言，就目前的ROM大小看来几乎在所有的情况中都是太大了。无论如何，它在技术上是可能的，而某些多应用操作系统支持完全自由的存储管理。

　　虽然，经常会在两个极端之间做出折中，其间在一DE内删除BF是许可的，但是这样释放出的存储量仅可作为一个单独的字组用来建立一新的EF，不发生文件的重新定位。如果在一BF删除后新的BF被建立，最佳的装配算法是去寻找一自由存储器的字组正好可以把新的EF装进去。之后，BF就建立在这样的空间位置中。这种情形的一个重要的方面就是凡是在新EF建立的字组中剩余的存储量，文件管理器就永远地把它丢失了。就其区域而言，删去的和新建的BF不会总有相同的大小，文件存储所能利用的存储量随着每一文件的删除和建立的过程而减少。对于许多当前的应用，这是一个关于功能性，所需程序代码的大小和应用的可靠性之间的可以接受的折中。

　　4，数据完整性

　　另一个要点是保证数据的完整性，文件管理器应当总是能够去测试在存储器中的数据有无偶然改变。例如，由于老化就有可能发生。为了减少为此功能的管理开支，数据冗余的水平与／或监督保护的功能深度应当和数据的重要性相匹配。于是，作为一个理所当然的原则，没有必要对所有的数据用校验和来保护。几项数据元可作为一组来保护，而一个完整的文件头标，或者特别重要的数据元则可单独保护。这主要取决于这些数据元在EEPROM中的修改有多么频繁，以及操作系统的设计者愿意为数据完整性贡献出多大的存储空间。

　　要保证数据完整性，关键数据要特别保护，例如数据访问特权和文件头标中的文件体指针，都应当用差错检测码保护。基于CRC的校验和经常用于此目的，因为它们能比较快地计算而又不需要太多的程序代码。然而，Reed－Solomon代码也经常用来提供较好的保护以防范典型的EEPROM单元的失效模式。当整个EEPROM页面被改变时会发生成簇错误，比起CRC校验和来，它们显然要优越得多。

　　5，交叉应用访问

　　某些智能卡功能仅在持卡人输人PIN之后才能被激活。由于一般人的记忆都受到必然的限制，即使在此卡中同时有数个应用，在一张智能卡中也只使用一个PIN已变得很平常了。在卡中的每一个应用都使用这个共享的PIN，它可对每一应用在一内部的BF中存储一次，但这将使得对每一个被存储的PIN都要有它自己的重试计数据器。例如，如果其中有五项应用而每项允许3次重试，则总共将允许有15次对PIN的猜测。在许多情况下，这是关于应用的设计和安全所不允许的。因而，某些操作系统允许对PIN和密钥的交叉应用访问。

　　这种对共享资源的利用使用了PC操作系统中通常使用的替换名机制相同的原理来实现。主要差别是智能卡操作系统中，所有的基准都必须从高层的DF引用，而MF则是最高层的实体，因而不可能去访问位于任意的DF中的PIN，只有位于文件层次中较高层的那个才可以，例如MF。

　　在上述单个PIN和重试计数器被几项应用共享的情况下，其实现将如下所述。PIN存储在一个直接位于MF之下的内部BF之中。在一项位于MF之下的DE的应用的内部FF中，存储着此PIN存储位置的索引。对PIN的比较成功与不成功的结果状态当然存储在DF的PIN记录中，因为一次只能对一项应用做出申请。如果现在启动了PIN比较，VERIFY命令首先访问现行DF中的PIN记录，从而断定PIN和其相关的重试计数器处在不同的层面上。然而，它用本地的PIN记录来引用PIN以进行比较。根据比较的结果，DE的状态被存在当前选择的DF的一个内部BF之中。

　　今天，这样的过程以大量不同的形式已用于众多的智能卡操作系统之中。特别是在两项或多项应用共享对数据的利用的情况下，它表现为在密码学上无懈可击的方案。除了此机制用于PIN和密钥跨越数项应用之外，某些操作系统还提供了对BF的等效机制。这样就有可能立即访问直接在ME之下的EF中的全局数据，而不必先对现行DE取消选定。