自从智能卡开始进入人们的日常生活之后，大家对于智能卡的安全性普遍看好，但是不同公司的智能卡在安全机制的实现方面也存在很多的差异。对于智能卡应用开发和智能卡COS设计人员来说，如果能够更多地了解不同公司的智能卡安全机制，无疑会对自己的开发过程有所帮助。在此将逐步介绍一些流行的智能卡操作系统中各具特色的安全机制，究竟这些安全机制孰优孰劣，其实无关紧要，只要这种安全机制能够满足系统的安全需求就足够了。

首先看看早期的CardOS，CardOS是西门子公司基于自己的44C40/80系列芯片而设计的，该系列芯片RAM大小256字节，程序空间8K/16K，数据空间4K/8K，采用西门子的8051内核。CardOS在1995年推出了1.2版本，主要的APDU命令是符合ISO7816-4的文件读写操作，采用的安全机制非常灵活，初看起来也有点复杂，但是实际原理却是比较简单的。虽然目前国内市场上几乎已经没有什么CardOS产品了，但是了解这个初期的鼻祖级的智能卡安全机制，对于了解目前市场上流行的COS安全机制应该会有些帮助。

CardOS采用半字节作为安全状态，除却0和F之外，还有1到E共计14种状态，每个状态分别对应要达到该状态需要进行的某种安全认证操作以及这些认证的不同组合方式，这些安全认证包括校验PIN或者是C/R （Challenge / Response） 认证（也就是我们现在通常所说的外部认证），而认证的组合方式包括“逻辑与”及“逻辑或”。

对于文件的操作和密钥的使用可以定义不同的安全状态，只有满足定义的安全状态后才能进行相应的文件操作，或者密钥的使用。无论是DF还是EF都有一组3字节的安全状态控制字，每半字节作为一种访问控制的状态标识，分别对应着文件的建立、删除、添加、读取、更新等操作。

这些安全状态及其需要的认证或组合全部保存在一个特殊的内部文件STCF（Security Test Control File）安全认证控制文件中，该文件是一个TLV（Tag Length Value）结构的记录文件，其中第一个字节就是1-E这14个状态中的一个作为TAG，Length根据认证方式的不同而存在差别，Value当中的第一个字节表示认证类型，从中可以看出这个认证是需要PIN认证，还是需要C/R认证，或者是某几个认证状态的“逻辑与”及“逻辑或”组合。对于PIN认证还可以指出应该使用哪个PIN文件中的哪个PIN，同样对于C/R认证也可以指出应该使用哪个密钥文件中的哪个密钥。在CardOS的系统中有一个安全状态bit mask标志，用不同的数据位来记录哪个安全状态经过认证得到了满足。在有些情况下，进行DF选择之后，当前DF的认证状态的bit mask标志将会被清空。

关于“逻辑与”和“逻辑或”其实也很简单。比如“03”的状态表示认证第3个PIN文件中的第2个PIN，“0B”的状态表示需要对第1个密钥文件的第5条密钥进行C/R认证。那么我们可以定义状态“06”表示“03”和“0B”的逻辑或组合，定义状态“07”表示“03”和“0B”的逻辑与组合。我们假设有两个文件EF01和EF02，其中EF01读写的安全状态分别为“03”和“06”，EF02读写的安全状态分别为“0B”和“07”。那么在验证了第3个PIN文件中的第2个PIN后，即可以读EF01也可以写EF01，而对于第一个密钥文件的第5条密钥经过C/R认证后，也可以写EF01。对于EF02的写操作必须同时满足以上两个认证状态，对于EF02的读则只需要C/R认证第1个密钥文件的第5条密钥即可。

除了以上的安全状态控制机制之外，CardOS还定义了所谓的线路保护LINE PROTECTION，在文件的创建过程中会定义LPROTF字段，作为线路保护属性，有两种线路保护模式分别为MAC方式和加密方式，同时还定义了线路保护的方向，即从卡到终端以及从终端到卡。而用来进行线路保护的密钥只能存储在SKF（System Key File）系统密钥文件中。

在CardOS中定义了几个默认的EF文件标识，分别为：0000 = ATR二进制文件，0001 = STCF记录文件，0002 = PIN记录文件，0003 = SKF系统密钥记录文件，0004 = RSF 随机数种子二进制文件。CardOS支持最多6层DF文件结构，可以通过文件名、文件标识、文件路径等方式进行文件的选择。