与已知的一般操作系统不同，智能卡操作系统不包括用户接口或访问外部存储介质的可能性。因为，它们为完全不同的功能进行了优化，在程序执行过程中的安全性和数据存取时的保护具有最高的优先级。由于受到可用存储器数量限制的影响，它们只能有非常小量的程序代码，通常在3～20kb的范围之间。下限对应于专门应用，而上限对应于多应用操作系统，平均的存储器需求量大约是16kb。

　　程序模块被写成rom代码，这会对编程的方式产生严重限制。许多典型的用于ram的程序代码（例如自修改的代码）的处理就不适用于rom代码。事实上，一旦微控制器的rom中的程序被编写好并生产出来，是rom中的程序代码根本没办法再修改的原因。要纠正这样的一个错误是非常昂贵的并且要花费10～12周的时间。如果智能卡已经被发行，错误就只能通过大规模的换卡行动来纠正，这就会破坏基于智能卡的系统的声誉。“快餐部”的编程方式显然是行不通的。通常人们花在测试和质量保证上的时间要比花在编程上的时间有意义得多。

　　还有，这些操作系统不仅必须是只有极少的错误，而且还必须是非常可靠的，决不允许其功能以及最重要安全j跬被来自外界的任何命令所损害。在任何情况下都决不允许发生由于错误的命令或eeprom页面的失效而导致的系统崩溃或失控反应。

　　透视操作系统的设计，一个不幸的事实是实现某些特定的机制总是受其所使用的硬件影响。首先，对于操作系统的设计来说，eeprom的安全状态就是一个引人注目的影响。例如，所有重试计数器的最大值都必须被设计为与eeprom的擦除状态相吻合。如果不是这样的话，那就有可能出现计数器复位到初始值的情况。例如，当正在向重试计数器写人新值时，通过故意关闭卡的电源而使计数器复位到初始值是完全可能的。eeproivi必须被擦除之后才能进行特定类型的写访问。如果电源恰恰在擦除eeprom和写入新值之间的时间段内关闭，则被用做重试计数器的那部分eeprom将会处在擦除状态。如果操作系统设计得不正确，就会使重试计数器被复位为初始值。要防止这种攻击，要么对计数器像上面所描述的那样进行正确的编码，要么就把写重试计数器的进程当做一个原子进程。重试计数器的情况和eeprom的安全（最低能量）状态相类似。重试计数器必须被编码为其最大计数与eeprom的安全状态相吻合。如果不是这样的话，就可能会（例如，通过局部加热某些eeprom单元），使重试计数器复位。这些只不过是在智能卡操作系统设计方面与硬件相关的两个例子。基于保密的原因，智能卡操作系统必须与所用微控制器的硬件密切结合，它绝不可能是完全独立于硬件的。

　　安全操作系统的概念还有另一方面，“陷门”（trap door）和供系统程序员使用的其他类型的隐式存取点在大型操作系统里屡见不鲜，它们完全属于正常的特征。然而，它们必须统统被排除在智能卡操作系统之外，绝不允许任何存在的可能性。例如，使某些人能通过某些机制绕过操作系统并获得未经授权的读取文件权限。

　　另一个不应低估的方面就是所要求的处理能力，目前在操作系统里的加密功能必须在非常短的时间里完成。这通常需要耗费几个星期的辛苦努力来优化汇编语言算法的代码。根据所使用的硬件平台和所要求的可靠性水平，操作系统不能胜任多任务也就不难理解了。然而，单一任务的执行限制也同样阻碍了安全处理的使用，这正是操作系统有关进程执行和约束的监视部分。

　　总体来说，一个智能卡操作系统的主要任务如下：

　　·从智能卡传出或传入数据；

　　·控制命令的执行；

　　·管理文件；

　　·管理和执行加密算法。

　　1，命令处理

　　如图1和图2所示，是不支持可下载软件的智能卡操作系统里的命令处理结构。智能卡通过串行i/o接口来接收每一条命令。必要时i/o管理器能够完全独立于其他较高的层面执行错误检测和错误校正。在一条命令被完整而毫无错误地接收之后，安全信息管理器必须对此报文解密或测试它的完整性。如果数据传送不安全，安全信息管理器对命令及其响应两者都是完全透明的。

图1 智能卡操作系统里命令处理过程（其中程序代码解释器是可选的，可以直接被状态机调用，例如使用java的情况那样）

　　在这一处理之后，下一个更高层面是命令解释器，它试图翻译命令。如果翻译不成功，就会调用回送代码管理器，由它产生一个适当的回送代码并通过i/0管理器把代码返回到终端。回送代码管理器可能薷要设计为专用的方式，因为对于所有的应用来说，回送代码都没有必要相同。另一方面，如果命令可以被翻译，逻辑通道管理器就确定所选择的通道，切换到它的状态，并在切换成功后调