智能卡软件的评估

由于智能卡是安全地存储数据，被主要用在对安全性敏感的领域中。然而，智能卡的使用带来的好处不仅 在安全存储数据方面，且对安全执行加密算法也有同样的优点。

特别是，电子金融交易领域是智能卡的一个正在扩展中的市场，大量的金钱将在一个很广泛的分布系统中 流通，应用提供者或卡发行者必须对半导体制造商，操作系统的生产者以及智能卡的个人化者具有极大的信 心。应用提供者必须绝对地确定智能卡执行的金融交易无任何错误，而且该软件没有安全漏洞，更不要说蓄 意引入软件中的“陷门”（trap door）了。

例如，假定有一条秘密命令可送给智能卡去读出PIN和所有的秘密密钥，在GSM或欧陆卡的情况下，攻击者 将能克隆出任意数量的卡并以完全正常工作的情况来销售它们。

然而，对安全性的需求不仅与智能卡的制造有关，而与卡的初始化和个人化也同等有关，因为秘密密钥和 PIN是在这些阶段装入卡中的。关于安全性，卡发行者必须把卡制造商放在可高度信任的位置上。

这些也同样适用于智能卡软件的基本安全性。即使一个“陷门”未能被有意地安插到软件中使得可窥探出 数据来，也仍会出现问题。对软件的错误操作，使用在正常处理中不应使用的命令组合完全能导致从卡中读 出数据或写入数据的可能。虽然，这种巧合的可能性极度之小，不过，众所周知，在目前软件技术的状态下 仍不足以保证在所有的情况下软件都是没有错误的。所以，在未来制作智能卡软件的公司，在尊重法律的明 确表述的基础上，对软件出现的错误将不再能否认所负的责任。

这里仅仅有两种方式使应用提供者可测试一个产品的可信赖性。他可以由自己测试智能卡软件所有可能的 变化，或让他可信任的当事人来测试它。第1种选择经常只具备有限度的可能性，因为提供者通常不具有全 部所需的专门技术和能力；第2种选择是把测试交给另一方，是目前经有关考虑后的可接受的解决方案。

同样的问题对军事应用的软件和系统开发来说已经存在许多年了，在智能卡世界中并不是一件新鲜事。为 了建立对软件产品可信赖性的度量，这需要把它的目标做成可测量的，美国国家计算机安全中心（NCSC）在 1983年颁布了一个评估信息技术系统可信赖性准则的目录。NCSC（National Computer Security Center） 是由美国国防部（DoD）在1981年建立的，接着在1985年出版了“可信赖的计算机系统评估准则（TCSEC）。 这本书有着桔黄色的装订，所以它一般被叫做“桔皮书”。这些准则对NCSC起到了验证信息系统时的指导方 针的作用。

TCSEC（Trusted Computer System Evaluation Criteria）对信息技术部分的所有实际的准则目录已经成 了国际的典范。在欧洲，已经规定了特定的欧洲准则，尽管它们是基于TCSEC的，它们首先在1990年作为“ 信息技术安全评估准则（ITSEC）出版，而修订版则在1991年发行。

通用准则CC（Common Criteria）的建立是为了提供一个统一的测试软件正确性的标准。可以说它代表了 TCSEC和ITSEC的本质部分。通用准则［Common Criteria 98］比TCSEC和ITSEC还更好地组织了对软件的评估 ，虽然通用准则的第1版尽早地出版于1996年，它尚未能取代TCSEC或ITSEC。通用准则也已经作为国际标准 （ISO 15408）被公布了。和ITSEC具有的6级相反，通用准则的可信赖性有7级。从基于TCSEC或ITSEC的评估 过渡到基于通用准则的评估是比较容易的，因为所有这些条目中具有许多共同的特点。然而，由于智能卡领 域的特殊性，ITSEC仍旧作为软件评估的实质的基础在使用，在下面的讨论中我们将仅以此样本作为参考。

不管采用什么样的方法学，评估过程都有四个特点。首先，必须没有偏见，这就是说评估者不管是对被评 估的项目还是它的生产者必须没有任何事先的观念；第2个特点是评估的过程必须是客观的，而且对此过程 的组织应使个人意见的影响降至最小；第3个特点是如果重复评估过程应能得到同样的结果。最后的特点是 评估过程必须是可复演的，这意味着采用不同的测试器或不同的测试机构应当能达到相同的结论，这些特点 在表示在图1中。

在任何评估中的一个最重要之点就是把安全目标规定为评估的目标TOE（Target OfEvaluation），评估的 目标是测试的目的而安全目标则说明了要测试的机制。顺便说说，技巧地选择安全目标有可能使评估大大地 简化，因为可以把对安全是关键的因素排除在外，这恰恰是一种用最快而又花费最少的方式达到很高的评估 水平的一种欺骗手法，当然，其结果只能是使真正的安全性受到损害。

图1 评估过程的四个特点

1．ITSEC

由于ITSEC（Information Technology Security Evaluation Criteria）以对所有可能的信息技术系统都 有效为前提，而文档长仅仅约150页，安全准则就必须以非常摘要的方式来描述。结果非常难于阅读，而且 像法规那样经常需要全面的解释。

1991年版的ITSEC认为对任何系统有三种基本威胁，称之为对数据的非授权访问（破坏机密性），非授权改 变数据（破坏完整性）和非授权损害功能（破坏可用性），安全准则就是基于此三种威胁，如图2所示。

图2 按照ITSEC的三种基本威胁方面

威胁可用不同的方法从系统的外部来减小。例如，一个不安全的计算机系统若用“安全门”来控制对系统 的实际访问时就能使之明显地安全得多。这些方面表明，在评估中一般的条件也必须都估计在内。最后剩下 来的威胁可使用ITSEC的需求条目来评估。

按照ITSEC评估一系统的基本步骤是估价对于规定基本威胁的树结构用来保持安全的机制，等级的划分方式 类似于在学校的分年级。所用的机制必须是既正确而又有效的。也要从与安全有关的基本功能方面来判断被 称之为通有类别的机制，如表1所示。

表1 按照仃SEC的机制的通有类别

表2列举了评估智能卡软件的需求。所花费的气力并不随每一相继的级别而线性增加，而是接近于二次方的。这就是说，从E2级到E3级所需的努力将是从El级到E2级的两倍之多，这样的结论 当然也可以对从Ed＋级到E6级的评估做出。对一个中等规模的智能卡操作系统在rrsEc E6级的完整评估很容 易占用数年时间并花费数百万美元。

表2 作为汀SEC质量级别的函数的智能卡软件开发需求概要

在评估时，一个基本的区别是在非形式化的，半形式化的和形式化的方法之间得出的。对功能的非形式化 描述完全可以和本书中按照文字的描述相比较。形式化的描述可以进行逻辑测试，并用形式化的符号来生产 （比如谓词逻辑）。

在ITSEC中，把对抗威胁的安全级别按其功能分为数类，这些类中的每一个都是安全功能的一种特殊的组合 ，而它表明了系统具有的对威胁的安全防卫的级别，这里有6个质量级别或评估级别El至E6），El是最低的 级别，而E6则是最高的级别。

在所有的功能类中，在开发过程和开发环境中对形式化需求的利用都是以非常抽象的方法来规定的，这对 于那些包含有关于操作文档和最终操作环境的类信息和规范也是正确的。这一信息以一种可用于软件开发的 所有可能的技术变化的方式来表达。

ITSEC评估中经常包括有一个附录，它与机制的“强度”有关，也就是说它们对抗攻击的坚固性。强度的级 别规定为：低、中和高，“低”表征对随机的，非有意的进入安全环境的保护。“中”意即对具有有限资源 的攻击的保护。“高”的含义为对具有很完善的技术知识与资源的攻击的保护。通常，最高水平的机制强度 用于ITSEC E4级和更高的级别，它原则上也用于对系统安全关心的智能卡。

2．ZKA（德国银行协调委员会）准则

除了国际评估标准如TCSEC，ITSEC和CC外，还有那些专门为大量的智能卡应用而建立的专用的评估标准。 两个例子是安全测试的VISA准则和德国ZKA准则。在德国对有芯片的欧陆卡是强制性的，所有智能卡对这项 应用的操作系统都要按照这些准则由授权的评估单位予以测试。ZKA准则已列举并解释于表3中，按ZKA准则 对智能卡操作系统安全性的技术要求和源代码的考查内容则见于表4中。

表3 评估智能卡系统的ZKA准则（取名Stefan Rothoz［Rothez 9sb]）

进行基于ZKA准则的测试时，所准各的文件以及软件和硬件都要经过审查。这是智能卡专用ZKA准则与一般 的应用于所有类型的软件的TCSEC，ITSEC和CC准则相比的主要好处。

总之，ZKA准则毫无疑问是当今对智能卡具有最好安全性的评估标准，因为它满足了大量金融交易系统最严 格的要求，并且是为基于智能卡的系统的特殊的专业而特别设计的。

表4 基于准则对智能卡操作系统的技术要求与源代码的安全性的考查（取自Stefan Rothes［Rothes 9saJ）

3．简略的摘要

一个实际的智能卡项目进行如下：卡发行者首先和操作系统生产者共同规定操作需求和必须重视的威胁， 接着达成一个必要的评估级别的协议；然后，操作系统按此评估级别与相应的评估处理安装成套，并提供必 要的文档；最后，完成了具备所有部件的操作系统可由一个独立团体按预先协议的级别予以评估，这个独立 团体应当是一家评估机构。

ITSEC评估对卡发行者和应用提供者实实在在的好处，因为他们可以确信许多安全特性的设计与实现都有明 确的定义与效果。然而，这项保证在动态的智能卡市场中也带来了某些不利之处，曲于需要实行评估而显著 地增加了开发时间，即使对于最低功能级别的评估也是如此，需要额外的努力来产生必要的文档也增加了开 发成本，这些最终都反映在负责开发操作系统产品的开发商的价格上。

然而，主要的不利还在于某些完全不同的事物，即使是一个评估了的系统，也不可能保证所有的处理和功能机制准确地与有关文档中所叙述的完全一致，评估并不意味着评估执行方完全测试了产品，而仅仅是检验了被接受的所述产品的文件，也可能有源代码和目标代码。同样重要的是目标硬件所保证的安全水平要和评估的水平一致。如果能用硬件作为“后门”去绕过软件，即使对无差错的安全的软件也毫无帮助。

上述四项有关评估的保留必须记牢并在每个单独的事例中谨慎小心地考虑。

欢迎转载，信息来源ic37网（www.ic37.com）