智能卡操作系统可执行本机代码

　　目前,智能卡微控制器的处理器绝大多数不具备任何种类的存储保护机制或执行任何管理程序的可能。随着程序计数器对此处理器的“外来”机器语言代码的编址，对全部存储器和全部功能的控制就完全取决于这些可执行的程序代码了。没有任何方法能够对可执程序的功能再予以限制，任何处于寻址的存储位置都可绕过存储管理或驱动程序进行读出，而位于EEPROM或RAM中的存储器则可写人。于是，所有的存储内容都可经卡接口轻而易举地传到终端。

　　这正是有关能可执行程序的弱点。如果每一个人都被许可程序，或者有绕过保护机制的可能，则任何密钥或在整个存储区域中的其他秘密信息的安全性都不再有保证。这将是攻击智能卡的理想形式。智能卡对外部世界来说将仍以未受操纵的卡的相同方式行事，但专门的命令可被用来读出整个内存或是向部分存储器写人。

　　虽然有着无懈可击的论点来反对第3方可程序。文件的生产者必须知道所有的入口点（转移地址）和操作系统程序的调用参数以便使用操作系统的重要功能。然而，操作系统制作者宁愿对内部进程和程序代码的地址尽可能少发布些信息，因为他们认为这些是秘密。此外，还必需去核查的代码是否按照要求去做而没有任何差错，也没有隐匿一个特洛伊木马，这只能由一个独立的团体来测试。

　　对这个问题的出色的方案，也是有前途的方案是对智能卡中的实际处理器补充以硬件为基础的存储管理部件（MMU）。这是用一套硬件电路来检查运行程序代码是否保持在其设定的的界限内，只有那些被卡发行商鉴别过不会牺牲卡的安全性的才有可能被准许成为应用运营者的程序。每个这样的应用将被分配给作为其DE的物理上连续的存储区，当在一DF中的程序被调用时，MMU将监视有关的存储边界。如果这些边界被越出，经一中断将使此程序立即被停止，而应用的任何进一步作用都将被挂起于这项能力的规范几乎在所有的情况下都是机密的，而在某些情况下，甚至这项能力的存在也是秘密的。因此，这里我们仅能从一般原理上来叙述这项能力，而与任何真实的操作系统无关。接在基本原理的讨论之后，将详细描述一可能之实现。

　　在智能卡中的程序代码在其能运行之前，首要的问题是必须满足某些基本的前提条件。它们似乎是明显的，但重要的前提条件是必须知道处理器的类型（例如，8051或6805）。特别是在许多不同类型的智能卡微控制器的多机种环境中，满足这一需求经常要占用相当的工作量。随之而来的需求是还必须知道智能卡操作系统和应用编程接口API（ApplicationProgramming Interface），包括所有人口点和由程序送出和回送的参数。

　　的程序代码，它们经常是本机代码（目标处理器的机器代码），或者必须编写成可以重新定位的，或者当它在时必须由智能卡可顺便重新定位的。可重新定位的能力需求，意味着程序可在存储器中移动，其结果是代码所在的存储地址只有智能卡操作系统知道而外部世界是不知道的。使一个程序可重新定位需要在编程阶段进行。具体而言，可重定位意味着，例如，不允许跳转至的实际地址，只能跳转到跳转命令地址的相对地址。

　　如果程序代码满足所有这些需求，原则上它就可装入到智能卡存储器中并在那里运行。当然，程序代码可按需要构造，图3给出了可能的结构，但实际的结构完全可以是不同的，这取决于操作系统。在此例中的第1个数据元是个单独的标记，它告诉智能卡操作系统这是个程序代码。这样的标记通常被称为“幻数”（majic munmber）。例如，对于Java Class文件，这是一个四字节序列形成的字“CAFEBABE”。

　　程序代码接着标记开始。在此例中，它被分成四部分。第1部分含有所有必需的初始化，数据存储等等。接着这个启动程序是拥有对所期望的任务的真正功能的代码程序。它又接以停车程序，后者是启动程序的对应部分。停车程序保证程序的正确结束，而如果需要时它将重新存储任何保留的数据并调整堆栈。

　　程序的第4部分，它接在前三部分之后，是可选的。其中可含有能牢固结合到智能卡软件中去的程序代码，对操作系统错误的修补通常也都位于此处。前面三个程序将修改指针或处理得使本部分的程序性地链接至操作系统的软件。整个过程类似于在DOS时代就已经熟知了的TSR（Terminate and Stay Re⒍哎耐）程序。直到在下次复位之前，这些程序仅被调用＝次以便把它们本身固定在操作系统之中。对于智能卡，这些稳定的程序只要在调用之后，就被安装了，而不仅仅只是对于会话。

　　这里我们假定程序是被CALL命令调用的，并用一条RETURN命令把控制返回给调用程序。原理上，直接跳转到第1条机器代码命令（用一条JUMP命令）也是可以的，但这样有

　　这里有两种不同的方法去实现代码，见图1，而图2则是对下程序代码的调用过程。第1种选择是程序代 码位于一EF中，其结构是“可执行的”。这个文件在它头被选择后，其内容可用EXECIJTE命令来执行。 随应用而定，可能需要预先的鉴别，运行程序的参数在EXECUTE命令中传送给智能卡，由BF所含程序产生的 响应被送回终端。

图1 可执行程序代码得以进人一标准智能卡操作系统的两种方法，作为可执行文件（左）或作为应用专用命 令（右）

图2 在标准智能卡多应用操作系统中，对存在BF中的可执行程序代码或按ASC体制工作的程序的基本调用过 程

　　第2种选择，采取略微不同的形式，因为它是基于面向对象的原理设计的。这一选择在EN 726－3标准（以 及其他）中被描述为应用专用命令ASC（Application Specific Command）。根据这一标准，整个应用，包 括其所有文件和应用专用命令都包含在一个DE之中。程序代码可被到由操作系统管理的在此DE内的一个 存储区域中。这项操作的进行使用了一条专门命令来把所有必需的信息发送给智能卡，如果所提到的DE是已 被选择了的，则一条命令被送到卡中来，操作系统将检查此命令是否属于的命令。如果是，操作系统立 即调用在DE中的程序代码。另一方面，如果选择了另外的DE，则不存在有效的命令。

　　本机程序代码可卞载至一EF之例

　　有几项大型的智能卡应用其操作系统允许在卡被个人化之后可执行代码。然而，关一个缺点就是调用程序不知道调用的是哪个程序。

　　为了防止意外的改变，整个字组采用了差错检测码（EDC）来保护。作为选择，当然可以用数字签名来提供 额外的保护。这样智能卡将有一个公开密钥，而程序代码的生产者将持有相关的秘密密钥，提供具有约束力 的担保，程序代码的鉴别可在智能卡上运行。

图3   到EF并由其运行的本机程序代码的一种结构

　　的程序代码可以或是储存在一EF中或是储存在从外部看不到的一DE的程序存储区中。下面将比较详细 地叙述第1种选择，因为在实际的实践中显然会比较经常遇到它。

　　透明结构的EF对存储程序代码而言是理想的，因为使用有区距值的UPDATE BINARY命令可以有效地写成几部 分。而且，即使对于广泛的程序，其长度超过了65KB也是更合适的。这些FF具有“可执行”的特性，这 就是说，在它们之中所存储的程序代码可以直接用EXECUTE命令调用。

　　某些操作系统，已经从透明结构导出了取代的文件结构，被称之为“执行”。对于外部世界来说，这并不 特别重要，尤其是两种类型通常都能用UPDATE BINARY和EXECUTE命令访问，EF可用其FID或短FID来选择， 读访问条件总是被置成“决不”（never）。写入数据通常在预先鉴别后才被允许并要使用安全电文。

　　图4和图5所示提供了如何以安全的方式把程序代码装入智能卡的某个BF中的概况。如果没有准备好可用的 合适的EF，则首先必须建立它。第2个进程图解表明首先必须选择EF，接着必须用EXECUTE命令来启动程序代 码。在命令体内允许有一个可选的数据传输。在响应中也有类似的可能性，必要时可以把数据送回终端。当 然，被调用的程序必须从接收缓存器读出它们以回收任何已传送之数据，准各其响应并将其响应写人发送缓 存器。

图4 在某个已有的具有“执行”结构的Ⅲ中装人可执行程序代码的可能的过程（UPDATE BINARY的访问条件规定了智能卡和终端的相互鉴别以及用安全电文传输数据）

图5启动可执行程序代码的一种可能的方法（在此例中它已存储在一“执行”BF中）

　　按照对微控制器、操作系统和内部的软件接口，以及和系统管理相关的那些毫不含糊的严格识别要求，通常程序只能发生在与后台系统在线连接之时。位于后台系统中的数据库或是按照惟一的芯片编号掌握了所有必需的数据，或是它们经端到端的直接连接从智能卡接收这些信息。根据这些信息，从那些在系统里可用的软件中选出具有所期望的功能的程序并用规定的安全机制传送给智能卡。除了用一个安全模块外，为此的秘密密钥通常由后台系统管理和使用。常用处理的整个过程如图6所示。

图6从后台系统联机上载本机程序代码到智能卡EF中去所用的过程
（这一过程可用来传送不同的程序代码给智能卡，取决于智能卡操作系统和微控制器硬件。例如，所述过程已在GSM应用很好地实现了）

　　上述把本机代码引人智能卡的方法有着某些吸引人的实际好处。过程简单而可靠，在智能卡操作系统中用少量的程序代码就可以实现。所运行的程序代码不是解释性的，因此可由处理器直接执行，可以达到高速处理，从而可以用此方法复杂的算法（诸如DES，IDE⒋或类似的）。

　　由于处理速度较慢，在可以预见的未来以解释为基础的系统不可能运用于这方面。只要没有以硬件为基础的存储管理去限制对存储器的自由访问，这种方法就提供了一种在卡已发行之后纠正智能卡软件差错的极好的方法。如果一个差错确实被知道了，惟一能达到这种方法所提供的独特“后门”的就是这种类型的软件。其他的技术，诸如智能卡Java，执行了严格和无条件的存储器分区并因此无法修改操作系统的代码，如果有了MMU，仍有可能启用一种管理模式使存储管理暂时停用。

　　这给我们带来一些不利之处，可执行本机代码要求对智能卡硬件与／或操作系统有很高的知识水平。有可能需要对每种使用中的智能卡版本在手头都要有一个单独的程序，虽然所有这些程序都具有相同的功能。这个方法的第2个主要的缺点是，为了安全起见，程序必须由卡发行商开发（或经卡发行商授权）。必须严格禁止把外面的或未知的程序装人智能卡中，因为假定的程序一旦在启动后控制了微控制器就不可能以任何方式予以管制。例如，就有可能读出存在卡中的其他应用的秘密密钥并把它们经I/0接口送至终端。

　　由卡发行商对程序代码的评估，对这类攻击仅能提供微弱的保护，在这种情况下可以得到的较好的保护是以硬件为基础的存储管理，它使得仅EEPROM和RAM中的某些区域可为程序所使用，而如果试图超出这些界就会立即关闭程序。这使得在卡中的应用可以完全相互隔离。目前，由于缺乏合适的MMU，惟一可取的权宜之计就是小心地检验要的程序。

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