（转载需注明http://blog.csdn.net/phixcoco，作者：phixcoco）

after reading Chapter 5: Smart Card Operating System

Operating System是直接与硬件相关的系统软件，了解它可以从系统软件的角度理解Smart Card的硬件功能与需求。

·第一节回顾了Smart Card OS的历史，对于最初的智能卡来说，有限的存储容量使得在其上开发OS成为一种奢望，智能卡硬件之上运行的都是specific的程序，对硬件直接进行操作；当存储器容量扩大、应用程序的总类和规模增大之后，人们就有了将一些general-purpose的routines同一的做法，于是就有了原始的OS；这些routines不断完善，使得Application能够建筑与这些routines之上，并有一系列统一的interface（API）供Application开发之用。

目前，Card OS离PC上的OS那样“统一（uniform）”还有不少距离，但目标十分诱人。

·第二节是COS的Fundamentals介绍，control and monitor program execution是OS的主要职责，Smart Card上的OS由于目前没有人机交互的需求、无需管理外部存储单元(external memory)等等，其最重要的指责就是secure program execution以及protected access to data。智能卡上的核心就是数据，而保证数据的安全操作是Smart Card OS的首要职责。而且Smart Card OS要有很好的稳定性，在任何情况下都不至crash或者对错误命令做出unpredicted response。系统的安全性目前由Common Criteria（前身是ITSEC）来认证。

COS的主要功能包括：
1、transferring data to and from the smart card
2、controlling the execution of commands
3、managing files
4、managing and executing cryptographic algorithms
5、managing and executing program code

智能卡OS的工作流程的特殊性在于，智能卡系统只在与终端连接时才工作（因为智能卡目前全靠终端供电），而智能卡和终端的交互通过命令完成。P239 Figure5.2 给出了命令交互的工作流程：
硬件层I/O得到Command，I/O manager运行error detection和correction；然后传给上层的secure messaging manager解密decrypt（一般会采用加密的传输方式）消息并验证完整性integrity；再上层是Command interpreter来解析命令；然后Logic channel manager检查error，并将信息传送给选择的channel，并启动状态机工作；状态机检查命令和参数，看当前的状态下是否允许运行Command。过程中如果出现无法运行命令就像会产生return code并向终端发送。
如果命令需要访问文件，上层的应用程序会调用下层的file manager，file manager将逻辑地址转换为物理地址并完成对存储器访问的安全检查并进行访问，而这些实质上是通过底层的memory manager，以及更底层的MMU来实现的。
如果命令需要进行基本运算和密码运算，就通过执行处理器的算术指令或者通过cryptographic library让密码运算协处理器来运行。

硬件之上运行的指令分两类：native code和需要翻译执行的code（以Java Byte Code为例）。Native code就是CPU core能直接运行的机器指令，而如Java Byte Code需要翻译执行（可以将Java Byte Code送到专门的Java处理执行，也可以通过Library将其用native code模拟执行，只要达到了运行效果就是可取的做法）。

而程序（无论是系统软件程序还是应用软件程序）是最终以native code的形式还是Java Byte Code的形式存储于卡上，很大程度上出于速度和开发效率的考虑。系统软件一般以native code的形式存储与卡中运行；一些time-critical的应用层，如数据传输和密码运算等，通常底层routines也以native code存储于卡上运行。在Java Card框架中，应用程序都用Java并尽量调用API来编写，他们主程序以Java Byte Code的形式存储于卡上，但调用的API的底层既可以是Java Byte Code的程序也可以是native code形式的程序。P244 Table 5.4 给出了some examples of typical memory usage of some OS functions implement in assembler。

中间几节关于智能卡内存组织和管理，文件结构和管理等没有细看。

现在的OS需要能支持下载并管理下载程序，事实上，loading和managing Java-based applications是由Open Platform（OP）标准定义的。OP的作用就是提供下载和管理第三方应用程序的安全的机制。P291 Figure 5.38给出了Basic Architecture and Components of OP。P292 Figure 5.39给出了possible state of application in OP spec。P293 Table 5.21给出了OP spec中定义的命令。

有两种方式运行下载的程序代码：
1、下载的程序代码以native code的形式存在，处于安全的考虑，程序实际运行的存储器分配应该由OS来完成。这种方式能使得代码高效运行，但是在没有MMU的Microcontroller中很可能导致对存储器不安全的访问。
2、下载的程序代码以Java Bytecode的形式存在，由于这类需要interpret的代码的执行机制，使得能够保证代码的安全执行，但是执行效率相比较低。

事实上Java Card标准就是采用了后一种执行方式，并且由于实现interpreter的存储器消耗，还将其分成了oncard和offcard两个部分，并通过加密手段（数字签名）将offcard的数据传给oncard部分，防止数据被人为窜改。P295 Figure 5.41给出了classification of the methods for downloading and running executive code in Smart Card。

Open Platform中主要看了Java Card一节。The Java Virtual Machine（JVM） is a simulation of the Java processor on an arbitrary target system. The target processor in turn naturally uses native code. The main advantage of this arrangement is that only the JVM, which is programmed in native code, has to be ported to a particular target processor. Once this has been done, the Java Bytecode will run on the new system。Java Card Virtual Machine同样是如此。P306 Figure 5.49给出了Top-level dataflow diagram of possible procedure of converting java source code to executive machine code。

P310 Figure 5.50给出了Java Card Virtual Machine的基本组成。P311 Listing 5.1给出了Java Bytecode interpreter的基本工作循环。P314 Figure 5.53是Schematic representation of the basic architecture of a Java Card system。Software Development for Java in Smart Card中论述了智能卡上Java程序开发的内容(P314起)，对设计安全高效的软件系统是必要的说明。P316 Figure 5.29列出了Java Card中一些重要的类库。P317 Figure 5.54给出了Java Card中从Java代码到目标机器码的设计流程。P317 Figure 5.55则给出了Java Card中处理APDU的data flow。

发表于 @ 2006年07月22日 15:37:00|评论(loading...)|编辑