徐锋 冷梦甜

摘 要：目前基于CPU卡的应用系统中存在高交互效率和强主机控制这一对矛盾，文中通过分析CPU卡指令的应用特性，制定了一套服务器和终端解释模型，并将该模型应用于充值和发卡系统中。分析发现，该模型能够在满足各类业务需求的同时滿足高交互效率和强主机控制的要求，为基于CPU卡的应用系统提供了一种高效率、高安全性的控制方法。

关键词：CPU卡;远程控制;终端解释模型;格式化

中图分类号：TP39文献标识码：A文章编号：2095-1302（2019）01-00-04

0 引 言

CPU卡作为一种自带计算和存储能力的安全介质，卡片内含有微处理器、存储器和操作系统，功能相当于一台微型计算机，具有安全、稳定、可控和易携带等优点，被广泛应用于金融、政府行业、公共交通等领域[1]。基于CPU卡的联机应用服务包括CPU卡、终端、应用服务器等，现有的业务实现一般采用两种模式实现应用服务器对CPU卡的远程控制，分别为终端透传模式[2]与终端处理模式[3-4]，这两种模式无法同时满足高交互效率和强主机控制的需求。在一卡通应用系统的终端开发过程中，一卡通应用方对业务比较熟悉，倾向于强主机控制;终端提供方对CPU技术比较熟悉，倾向于高交互效率，双方一般依据基于业务和技术力量的不同选择某一模式，但均有改进空间，因此研究一种满足高交互效率和强主机控制需求的控制方法十分必要。

1 传统远程控制方法存在的问题及解决思路

1.1 终端透传模式存在的问题

终端透传模式是指所有业务逻辑由应用服务器控制，终端只作为通道下发APDU指令到CPU卡，并接收返回信息转发给应用服务器，后续处理逻辑由应用服务器根据返回信息再次组织指令下发，终端在应用服务中的作用在于透传信息，如图1所示。这种模式的业务逻辑由应用服务器控制，虽然可以通过后台软件配置对业务流程进行调整，但会导致终端与应用服务器之间的交互增多，降低应用效率。

1.2 终端处理模式存在的问题

终端处理模式是指应用服务器接收应用所需的必要数据和提供CPU卡操作必须的数据。应用逻辑由终端和应用服务器共同控制，终端进行主要的业务控制，如图2所示。这种模式可以提高系统的应用效率，但业务逻辑由终端控制，需要调整业务流程时需对不同部署区域不同种类的终端进行升级，难于实现业务流程的灵活调整。

1.3 解决思路

对于上述两种传统模式，前者因网络交互太多而影响效率，后者因服务器对CPU卡的控制导致只能通过终端间接控制，而且受终端逻辑影响。为了解决现存的问题，必须引入一种在不增加交互过程的基础上使服务器可直接远程控制CPU卡操作的新模式。

如果想实现最少的交互次数，就需要将大量控制逻辑下放给终端处理，如果为实现最强的主机控制，就需要收回终端的控制逻辑能力，而这是一对矛盾。因此文中分析了CPU卡指令的特性，设计了一套服务器、终端的解释逻辑，由服务器端编辑并下发控制逻辑，终端按规则解释执行逻辑，以实现最少的交互与最强的控制，避免两种传统模式的缺点。

2 CPU卡指令分析

基于业务管理和安全的要求，一般业务系统在设计时会考虑关键业务的控制点。例如，在充值业务中，卡片充值必须有后台服务器才能产生mac1数据，而mac1数据与交易金额、卡号、序列号、时间、充值密钥等数据密切关联，不可伪造、不可修改、不可重发，因此业务系统需以mac1数据的发出作为收款的关键控制点。由于业务系统存在各控制点，使得整个业务流程在CPU卡和后台系统间必须经过一次或多次交互，即设计CPU卡指令的解释逻辑不仅要考虑本次交互的指令顺序和状态控制，也要考虑多次交互时上下文的关系。

因CPU卡的状态千差万别，每次交互的指令组内部也需要定义一定的处理逻辑，前一条指令的返回状态会影响后续指令的执行顺序。例如，在联机消费过程中，读取卡片信息后，需要根据卡片是否在黑名单内而选择正常消费或退出本流程;有时需要根据访问目录的返回情况而选择进入不同的交易流程。

同时，不仅前一条指令的返回状态会影响后续指令，前一组和前一条指令的返回数据也会影响后续指令的处理。例如，前一条查询余额指令正常执行，余额太大后续则无法充值，余额太小后续无法消费等。

本文研究设想所有CPU卡业务流程都可能有关键业务控制点，需要通过多次交互实现，每次交互都需要根据指令返回状态和返回数据确定下一步操作内容和后续步骤，同时也可能需要组织数据回送服务器。

3 CPU卡指令解释逻辑设计

本文研究设想所有CPU卡业务流程（如充值业务、在线消费业务、迁移卡业务、测试业务等）都可以通过多个指令组实现，每个指令组表示需要一次CPU卡与应用服务间的交互，当次交互的指令信息和返回要求编入该分组，每个分组由多条指令组成，每条指令定义了操作内容和后续步骤，并定义了需要动态定义的操作内容和返回数据。

3.1 关键字

服务器端和终端进行逻辑解释遇到关键字时，进行特定的解释处理，设计了表1所列的关键字。

3.2 服务器端的指令配置模板

对于所有业务流程都可使用图3所示的模板。

服务器端的指令配置按照统一模板，针对不同的业务进行具体的指令配置，以下是每个字段的配置说明：

（1）指令组ID：唯一标识指令组，由三位数字组成，从001开始（不能为000），一般按数字顺序编号;

（2）指令ID：在同一指令组内唯一标识指令，由三位数字组成，从001开始（不能为000），一般按数字顺序编号;

（3）指令（含数据）：APDU的具体数据，可以含可变参数，以{}标识，如805A000202{onlineSeqNo}08表示指令需要将之前指令获取的onlineSeqNo值填入;

（4）期望值和顺序号：指示该条指令期望的返回值以及对应的下一条指令的ID号，支持多节，每节以“+”分隔，节内返回值与下一条指令以“|”分割，匹配到第一个结果即结束匹配，“*”标识匹配任意值，下一条指令若为000则结束，如9000|002+6A82|006+*|006表示返回以9000结尾的数据下一条执行2号指令，返回以6A82结尾的数据下一条执行6号指令，其他返回值下一条执行6号指令;

（5）结果解释域：指当前指令的执行结果可以解析出来的值，由值名和值位置标识，值名由书写字母和/或数字组成，在一个动作内唯一标识执行结果内容，值位置由开始位置和长度组成，如{logicNo[0|8]}表示从本指令返回值的下标0开始，截取8 B长度，可以解析出logicNo参数的值;

（6）处理类型：由两个数字组成，第一个数字表示服务端处理类型，第二个数字表示终端处理类型。

终端处理类型：0一般处理，只需将指令送往卡片并接收返回即可;1获取终端信息，终端按“结果解释域”指定的关键字要求填写返回数据。

服务端处理类型：0一般处理，或只需将{}符号内的变量填充完成即可;2产生写安全文件的mac值;3产生加密写安全文件的mac值;4验证充值mac1;5计算充值mac2。99为特殊类型表示错误，需终端重新处理。

3.3 服务器解释流程

服务器解释流程如图4所示。

（1）从配置文件中读取本应用对应的指令组（从001组开始处理）。

（2）从指令组中读取指令进行处理，处理内容主要为填充“{}”内的变量。首先判断处理类型是否需要服务器计算相应关键字的值，优先采用临时计算的关键字的值填充相应变量;然后从结果解释域中获得相应变量的结果填充，如无对应的结果解释域变量，则再读取系统配置信息填充，如再无系统配置信息则报错。

（3）将格式化的指令传递给终端并接收终端返回的信息。

（4）对照发出指令组内每条指令的“结果解析域内容”，逐条解析结果，并将结果记录在服务器对应的参数中。

该业务流程如果还有指令组未执行，则取下一组指令重复步骤（1）～（4），直到全部完成。

3.4 终端解释流程

终端解释流程如图5所示。

（1）从服务器获取格式化指令组。

（2）对获取的格式化指令组进行格式审查和解释。

（3）进行卡片操作，终端优先按处理类型指示进行终端处理，然后终端对卡片执行指令（若指令为空则返回缺省值），获取返回值和状态值，按当前指令的“期望值和顺序号”字段要求执行下一条指令，直到本组指令全部执行完成。终端对卡片执行指令前，首先与卡片完成寻卡、反冲突、选卡等操作，与卡片建立稳定的APDU通道，后续的操作逻辑和返回數据组织完全按服务器下发的格式化指令进行。

（4）组织本组指令的结果解析域返回给服务器。

终端持续请求、检查、执行指令组并返回信息，直到收到组号为99的指令组。

3.5 解释流程示例

3.5.1 服务器端指令模板

3.5.2 服务器解释

服务器首先读取模板信息，然后用系统变量替换“{}”内的变量，再格式化各指令，指令间以英文“;”分割，最后一条指令以“.”结束;每条指令包含指令组ID，指令ID，指令，期望值，解释域和处理类型共6个字段，字段间以“，”分割，字段可以为空;期望值和顺序号字段由期望值和指令ID对组成，用“|”连接，一个字段可以由多组期望值和指令ID对组成，组之间由“&”连接。系统最后形成如下字符串下发终端：“001，001，07，00a4000002ddf1，9000|002&*|000，0;001，002，05，c4fe000000，9000|003&*|000，phyNo[0|8]，0;001，003，05，00b0950808，9000|004&*|000，logicNo[0|8]，0;001，004，07，00a4000002adf1，6a81|005&*|000，0;001，005，07，00a4000002adf3，*|000，0.”。

3.5.3 终端解释

4 CPU卡具体业务设计

本节以CPU卡应用领域比较常见的两个业务场景—空中充值、空中发卡为例，设计了一套服务器配置模板、服务器解释说明和终端解释说明，用于说明基于终端逻辑解释的设计在实际具体业务上的实现情况。

4.1 空中充值

一卡通行业的CPU卡充值一般遵循PBOC电子钱包规范，图6所示为一套基于PBOC电子钱包充值的模板配置，共配置有3组操作指令和一组结束指令。

4.2 卡片发行

一卡通和银行领域的卡片发行一般都遵循GlobalPlatform规范要求，在完成安全域初始化后进入具体的SSD安全域，替换SSD密钥后，将卡片的密钥和文件信息通过密文的方式写入卡内。图7所示是对已完成安全域初始化后的卡片发行的模板，共含3组指令组。

5 结 语

本文就CPU卡指令特征进行了分析，以高主机控制低交互次数为目标，设计了一套包括配置模板、服务端解释流程、终端解释流程的可行的解释逻辑，并已应用到一卡通行业的空中充值和卡片发行中。同时，CPU卡还被应用于联机消费、客服处理、身份验证等领域，该解释逻辑可以通过扩展关键字和解释逻辑很好地适应新应用的要求。不足之处在于，应用的多样性和不可预测性导致很难设计一套可以兼容所有应用的解释逻辑，在增加新应用时只需修改配置模板即可，无需修改服务器和终端解释流程。

参 考 文 献

[1]周宏华，李树国，周润德.高安全性的智能卡芯片结构与设计[J].清华大学学报（自然科学版），2003（4）：569-572.

[2]苏浩伟，邹大毕，温晓丽.基于安卓NFC接口的交通一卡通手机充值系统研究[J].信息化建设，2016（7）：58-61.

[3]邓均.城市一卡通系统设计与实现[D].广州：华南理工大学，2016.

[4]薛峰.智能公交充值服务系统的设计与实现[D].天津：天津大学，2017.

[5]唐柳，黄樟钦，张会兵.基于指令流混合比与功能单元匹配的软错误脆弱性控制方法[J].计算机应用研究，2017，34（1）：98-101.

[6]童新，姚莉，倪波.基于物联网的Cortex-A53智能云镜系统的设计与实现[J].物联网技术，2018，8（5）48-50.

[7]邓超国，谷大武，李卷孺，等.一种基于全系统仿真和指令流分析的二进制代码分析方法[J].计算机应用研究，2011，28（4）：1437-1441.

[8]李功丽，戴紫彬，徐进辉，等.基于流体系架构的分组密码处理器设计[J].计算机研究与发展，2016，54（12）：2833-2842.