全国交通一卡通票卡个人化效率优化

邓志 伍卫中 杨育文 李孟杰

（广州羊城通有限公司 广东省广州市 510080）

1 概述

自交通运输部印发《交通运输部关于促进交通一卡通健康发展加快实现互联互通的指导意见》[1]以来，全国各省市在“统筹规划、分步实施、标准先行”的建设原则指导下，运用先进、成熟的计算机技术和IC 卡技术，建设高效、安全的一卡通应用服务平台，将一卡通全面应用于公共汽车、地铁、城际轨道、轮渡、长途客运、公共自行车、停车场、城市小额消费等领域，逐步全面推广交通一卡通，实现跨区（市）域、跨交通方式互联互通。

然而，在一卡通运营企业进行全国交通一卡通票卡发行系统开发过程中，面临如下几个问题：

（1）各个票卡厂商有各自的票卡个人化指令规范[2]，在开发票卡发行系统时需要分别适配，导致开发成本高、时间长；

（2）各个票卡厂商有各自的个人化流程，导致不同厂商的票卡所使用的发行时间不一致，在安排人力资源与硬件资源时容易造成混乱；

（3）在开发票卡发行系统时，不能制定统一的代码结构，需要根据不同的厂家进行针对性开发。

因此，迫切需要一套统一的个人化指令与发行流程的个人化规范方案来指导全国交通一卡通票卡个人化开发。

1.1 解析常规票卡个人化方案分析

CPU 票卡个人化分析。原羊城通省标CPU 卡与捷德、握奇、天喻、复旦等10 多个厂家进行票卡开发合作，每个厂家有各自定义的票卡个人化规范，与每个票卡厂家进行对接开发，都需要按以下流程步骤进行开发：

（1）学习票卡厂家提供的票卡COS 开发手册，熟悉个人化指令，包括文件新建、删除、修改，密钥新建、删除、修改等。

（2）根据票卡卡结构，结合票卡COS 开发手册，开发票卡个人化脚本。

（3）将脚本导入票卡发行数据库。

（4）修改票卡发行后台程序代码，兼容票卡厂家CPU 卡个人化指令。

（5）联合票卡厂家进行票卡发行调试，查找发行过程中出现的错误，修改错误后反复调试。

（6）票卡发行后对票卡进行基础功能测试与终端兼容性测试。票卡发行流程图如图1 所示。

1.2 引入STORE DATA的CPU设计方案，提高一卡通票卡个人化效率

图1：票卡发行流程图

票卡发行的优点主要有两方面，第一方面是，个人化指令通过密文+MAC 的方式传输，保证个人化数据的安全。另外一方面是，每条个人化指令都需要取卡片随机数参与运算，从而有效增强个人化数据破解难度。同时它的缺点也很明显，首先，每个厂家有各自的APDU 指令规范，每次接入新厂家都需要重复修改票卡发行平台，新增该厂家的票卡发行功能。另外个人化指令脚本数量太多，并且无法压缩，造成终端在发行票卡时，需要与后台发送与接收200 多个来回的个人化数据，导致每张票卡的发行时间为30 秒，发卡效率较低。为此通过引入STORE DATA 的CPU 设计方案，实现票卡发行功能的统一，不但可以有效提高票卡发行的开发效率与票卡发行效率，而且还能增加资源的重复利用和减少浪费。既优化了操作人员的票卡发行体验，又降低票卡出货时间。

2 基于STORE DATA的CPU票卡个人化方案设计及关键技术

2.1 NATIVE卡与JAVA卡

“NATIVE”与“JAVA”是针对加载在卡片上的应用的开发环境而言的。NATIVE 卡应用使用与NATIVE 平台同样的语言进行开发，比如C,汇编等;JAVA 卡应用是使用JAVA 语言开发的，而JAVA 平台本身可以认为是一个特殊的NATIVE 应用。

NATIVE平台通过统一卡片操作系统(COS)来实现所有的功能，所有功能接口都基于COS 来实现，并且需前期进行开发，二次开发的难度非常大，并且功能少。而JAVA 平台分为两层结构，底层为按照JAVACARD 规范来实现，向上提供规范定义的接口（API），通常支持GP API。上层为按照应用需求开发的APPLET，相当于NAVTIVE 卡片上的ADF。可以根据不同类型的应用，开发多个APPLET。这些APPLET 相互独立，通过AID 来选择。

前期羊城通票卡发行项目基于NATIVE 平台实现，期间遇到众多难题，例如二次开发的资源投入率高、票卡发行效率低等。由于JAVA 卡的接口规范多样性以及应用二次开发的方便性，本研究项目基于JAVA 平台实现。

图2：写文件TAG 低2 字节定义

图3：写密钥TAG 低字节定义

2.2 GP技术简介

GlobalPlatform 是一家由支付和通信业的领先厂商、政府相关部门以及供应商社区共同建立的一个组织，并率先提出了一个跨行业的智能卡全局基础架构及其实现，其目标是为了减少隐藏在快速增长的跨行业、多应用的智能卡背后的障碍，使得发卡商在各种各样的卡片、终端和后台系统前，继续享有选择的自由[3]。

对于Java 卡：GP 规范是Java 卡上的一套Java 应用代码管理机制，负责Java 应用的安全管理，通过安全信道、安全域、密钥权限等安全因素实现对Java 应用的加载、安装、删除等动态管理。

安全域：卡片管理器作为GlobalPlatform 架构中的首要组件起到了GlobalPlatform 卡片中心管理者的作用，特定的密钥和安全管理应用被称作安全域，负责确保发卡方和其他安全域提供者之间的密钥的完全隔离。安全域负责提供各类安全服务，包括密钥管理、加密解密、针对其提供者（发卡方、应用提供方、授权管理者）的应用进行数字签名的生成与验证。

2.3 STORE DATA+DGI

STORE DATA 命令是GP 规范定义用于将数据传输至应用程序或者安全域的指令。安全域根据接收到的命令数据来确定该命令是用于自身还是用于应用程序。STORE DATA 命令基于GP 规范制定的安全机制与规则，用于保证数据的完整性与安全性。

DGI：DGI（Data Grouping Identifier）格式是GP 规范定义的在两个字节上进行编码的二进制格式，其后需接长度标识和数据域。

通过自定义票卡结构里文件的DGI 标签，包括电子钱包文件、电子现金文件、普通二进制文件、循环或变长记录文件、密钥文件、扩展应用文件等，并形成自定义规范标准，统一票卡个人化的脚本指令。同时，使用STORE DATA 指令来传输自定义指令，运用密文+CMAC 的方式来保护传输数据的完整性与安全性。

2.4 密文+CMAC

票卡个人化脚本在传输过程中，根据GP 规范定义的方式，对传输的数据使用卡片密钥进行数据加密，得到传输数据密文，并计算数据的CMAC 值。卡片在接收到数据后，使用相应的密钥，用相同的算法对传输数据进行解密，获取传输数据明文，并计划CMAC 值，对比接收的CMAC 值，判断数据是否一致。

表1：NATIVE 卡与JAVA 卡各项细节对

图4：校验密钥TAG 低字节定义

票卡个人化数据从票卡发行系统加密，到票卡进行解密，数据在传输过程中处理加密状态，确保数据在中间传输过程不被破解。

2.5 密钥安全保障机制

票卡从生产到发行，需采用必要的安全机制来保障数据发行安全：

（1）应用预个人化流程，票卡生产厂家需提前获取票卡发行方的基础安全密钥。

（2）票卡生产厂家需安装票卡发行方的基础安全密钥至票卡中，并生成KMC。

（3）票卡发行方在票卡个人化时需对票卡KMC 密钥进行替换。

票卡安全域密钥KMC 的安装与使用，由票卡发行方来定义。KMC 密钥通过母卡的方式提供给票卡生产商。票卡生产商在安装Java 平台时，需对票卡进行预个人化处理，即从母卡中导出初始密钥并安装至票卡中，此时票卡的安全域KMC 被修改为票卡发行方的密钥。

2.6 数据格式与定义

制卡数据类型编码规范：Tag 占2/3 字节，高字节为0x7F（01111111），即bit7-8 采取Application Class。

写文件Tag 由3 字节构成，其低2 字节定义如图2 所示。

写密钥Tag 由2 字节构成，其低字节定义如图3 所示。

校验密钥Tag 由2 字节构成，其低字节定义如图4 所示。

预充值（钱包信用额度）Tag 由2 字节构成，其低字节定义如图5 所示。

NATIVE 卡与JAVA 卡各项细节对比，如表1 所示。

通过定制的JAVA 卡对比NATIVE 卡，具有以下优点：

（1）统一一套票卡个人化脚本指令，每个厂家根据票卡规范进行COS 开发，二次开发难度大大减少。

（2）出厂前预置票卡结构，并做好预个人化。

（3）提前初始化票卡文件内容，设置为普通值0 或F，而关键数据包括文件密钥、卡片信息、证书信息等在个人化时才写入，即保证数据安全，又节省个人化时间。

（4）只需一次获取卡片随机数，后面每条个人化指令都根据上次指令计算卡片随机数参与运算，既减少个人化指令计算次数，又有效增强个人化数据破解难度。

（5）个人化脚本最多只需72 条，最少可以缩减至49 条，大幅提高个人化效率。

（6）个人化指令通过密文+CMAC 的方式传输，保证个人化数据的安全。

（7）在票卡发行过程中，发行终端与发行后台的连接次数，最低可以压缩至17 次，有效减轻了后台压力。

（8）单张交通部二合一卡发行时间为8 秒/张。

（9）定制的个人化指令配合定制的重复写卡机制，可以直接对异常卡进行重新写卡，不再需要进行7 卡步骤。

2.7 新票卡发行的创新和难点分析

新票卡发行的流程图，如图6 所示。

2.7.1 设计与开发过程中所遇问题总结与难点突破

由于此套方案基于不同的技术与不同的平台，因此在设计开发过程中遇到很多问题，现总结如下：

（1）在设计个人化指令时，没有充分考虑各文件之间的关系，导致某些个人化指令出现歧义，一条指令无法定位文件位置，后经测试反复重现问题，并重新设计三字节标签来解决此问题。

（2）在计算票卡指令CMAC 时，由于算法较复杂，相关联的字段较多，出现计算错误的情况，后经厂家指导，顺利完成CMAC计算。

（3）在票卡COS 开发过程中，有的厂家缺少三个应用钱包共享的设计，导致在开发完成后再发现问题并重复修改。后重新与厂家讨论技术细节，并提供相关技术文档，确保厂家按我们的需求完成开发。

（4）由于对电子现金的认识不足，导致开发发行平台的时间延长，在对票卡电子现金进行测试时，缺少部分测试项。后经厂家技术指导后，完成开发与测试。

（5）在票卡测试过程中，没能及时收集全国各地的终端与PSAM 卡类型进行测试，导致少部分票卡的发行参数与部分地区的标志不符，后经修改参数加以解决。

2.7.2 创新点

图5：预充值低字节定义

图6：新票卡发行流程图

在对原票卡发行系统运营管理多年的基础上，发现系统在新票卡开发、票卡发行时间、发行流程、维护成本等环节上问题较多，如何有效优化流程以及如何设计方案成为核心突破点。根据现在流行的JAVA 平台票卡发行思维，结合GP 规范定义的标准接口与API，再运用成熟的DGI 标签格式，设计出一套完善可靠安全的个人化指令标准。此规范标准适用于所有开发厂家，厂家根据我们定义的规范标准开发完成并通过我们测试后，适用于我们的交通部二合一票卡发行。新标准解决了原系统的众多问题，包括新票卡开发时，不再需要重新学习开发脚本与指令；票卡发行时间从30 秒/张缩短至8 秒/张；发行流程简化，不再需要重复洗卡；二次开发更方便快捷。

3 总结

本套方案通过自定义DGI 脚本，规范各种不同类型的个人化指令，实现票卡发行功能的统一，不但可以有效提高票卡发行的开发效率与票卡发行效率，而且还能减少资源的重复利用与浪费。既优化了操作人员的票卡发行体验，又降低票卡出货时间，该方案将成为票卡行业发展的重要手段和未来票卡发行的引路方向。