智能卡操作系统的设计和实现原则

　　众所周知，早能表现出的设计错误出现在实现阶段。与那些较好的，较少受错误支配的设计相比，它们将导致数倍以上的花费。然而，这却是生活中软件开发项目的现实状况。为了避免这些错误，建议在智能卡操作系统的设计和实现中对一些原则应多加注意。

　　由于它本身功能所规定，智能卡操作系统是一个安全的操作系统，它必须能管理信息并且首要的是保障信息机密。另外，通常情况下，在操作中根本不可能对其本身的软件做任何修改。由这些条件可直接得出第1条原则，智能卡操作系统必须是极度可靠的，这意味着它只能含有极其少量的错误，完全消除错误是事实上永远做不到的。因为，即使是的智能卡操作系统，它们的内部处理也存在着太多的可能性以至于不可能被完全测试到。

　　然而，严格的模块化设计，为发现和排除在实现阶段有可能出现的错误做出了决定性的贡献。模块化使操作系统的可靠性大大加强，同时又不需要大量增加程序代码。模块化带来的又一好处是可能的系统崩溃对系统安全性的影响，并不像大量优化过且使用很少内存的程序代码那样强烈。它意味着由可能出现的错误导致的结果被限制在局部范围内，而操作系统作为一个整体则更坚固和更稳定。

　　由于软件常常必须用汇编语言来编写，使得它比较容易存在错误。采用独立的完全可测试的模块化设计，对及时发现编程错误做出了强有力的贡献，由于使用了规定的接口也限制了差错的影响范围。图5．1所示的层次化操作系统设计是这种模块化手段的结果，所增加的计划编制和编程工作量，至少在财务上，从测试和验证显著变得容易这一事实得到了补偿。其结果是，今天几乎所有的操作系统具有相同或非常相似于此处所描述的操作系统的结构。

　　通常设计系统的方法是用模块－接口的概念。在设计过程中，操作系统和应用任务都尽可能地分解为各项功能，然后把这些功能集成到模块中去。一旦这些模块的接口被严格地规定后，各个模块就可由几个人分别编程。在理想情况下第1版是和平台无关的，这就是说它不依赖于所涉及的微控制器的特性。在被完整地测试后，再着手适应于微控制器的必要改编。

　　由于智能卡操作系统的程序代码量比较少，可采用非常实用主义的方法而没有任何重大问题。它的主要好处是所需的编制计划的工作量较少，并且有可能把编程任务分配给几个人，以及程序代码的可重用性等成果。用这种方法带来的缺点是难以论证系统的正确性以及对系统的改变在某些情况下将会影响许多模块的事实，必须予以权衡。

　　智能卡操作系统软件已经从完全用汇编语言编程大大地向前发展了，许多近的项目从一开头就用比较接近于硬件的语言C来进行。然而，操作系统的真正仍旧建立在依赖于硬件的汇编语言之上。而一些高层模块，诸如文件管理器，状态机和命令解释器则用C语言编程。这样就大大缩短了开发时间，并使程序较易移植和可重新利用。尤其是使用语言，引人注目地改进了软件的可测试性，由语言提供的改进了的和较易理解的程序结构导致了差错率的显著降低。图1为在C和汇编语言开发环境中对智能卡微控制器仿真的示例，而表则是操作系统用汇编语言编写时各个功能部分占用内存的典型概况。

　　遗憾地是用C编译器产生的代码，即使是高度优化的，也比同样功能的用汇编语言的等效代码在ROM中要多占⒛％～硐％的空间。此外，用C语言实现的运行速度也比汇编编程的略低。然而，这只对加密算法和数据传输协议才是关键，因为智能卡操作系统软件的其他部分通常不含有任何苛求时间的处理。

　　C语言编程的问题不是在ROM中需要额外存储空间，也不是较低的执行速度，而是所用的RAM量。RAM存储器的资源在智能卡中是极其有限的，而它的缺点是在芯片上要占用远远大得多的空间，这就是为什么编程语言迟迟不用于智能卡操作系统编程的原因。

　　自从智能卡投入应用领域以来，其安全性就是一个重要的考虑，卡发行者和应用开发商对操作系统生产商的正直诚实要有足够的信任。后者，可以有各种机会在整个系统中故意引入安全漏洞以取得不正当的利益。例如，可以考虑一个在智能卡中的电子钱包，其装入命令，已经受到了操纵，使得在某些情况下，钱包可以不经授权而重新装入。这种局面就是迄今为止为什么只有少数的操作系统供应商得到公众认可的理由。如果一个表面上看来安全的操作系统是来自小的、不的供应商，其中含有特洛伊木马的风险要远大于来自此领域的众所周知的公司的风险。

图1 在典型的C和汇编语言开发环境中对智能卡微控制器仿真的示例（源代码窗口在左上方，而不同的处理器寄存器则显示在右上方，BAM的存储映象在右面底部，
用于控制仿真器的命令行在左面底部。仿真器使得软件开发时可以监视微控制器的所有功能并干预程序执行的每1环节）

　　表 某些智能卡操作系统功能用汇编语言实现时典型的内存占用情况

　　无论如何，在近已经努力去按照信息技术安全评估准则ITSEC或其后继者——通用准则去评估智能卡操作系统，以便在上述有关的情况中能达到较高水平的可理解性与安全性。这方面的进行无论是出于生产者的自愿行为，或是对应用供应商的要求的回应。这些评估的目的是说明程序代码中没有明显的差错，而增加信任水平。评估或许只能在有限的程度上发现故意引入的特洛伊木马，因为实际上的可能性是无边无际的。

　　到目前为止，通常对智能卡操作系统的评估水平为ITSEC E3或E4，有时甚至也已经提供了E6级的要求，但必须考虑到的是智能卡操作系统在弘级上的完整评估费用约为￡170000。在对程序代码做了修改之后，有义务接着再评估，虽然再评估比初始的评估要便宜些。这就是为什么只有比较少的智能卡操作系统，可以为有ITSEC评估而自夸。比较通用的做法是由测试机构执行评估而不参照Ⅲ弼C，测试限于详尽地检查设计准则，源代码和文档。例如，这些是对于德国的欧陆卡所用的操作系统的基本评估方法。

　　欢迎转载，信息来源维库电子市场网（www.dzsc.com）