JT/T 1059.2-2025 交通一卡通移动支付技术规范 第2部分:安全单元 ,该文件为pdf格式 ,请用户放心下载!
尊敬的用户你们好,你们的支持是我们前进的动力,网站收集的文件并免费分享都是不容易,如果你觉得本站不错的话,可以收藏并分享给你周围的朋友。
如果你觉得网站不错,找不到本网站,可以百度、360搜搜,搜狗, 神马搜索关键词“文档天下”,就可以找到本网站。也可以保存到浏览器书签里。
收费文件即表明收集不易,也是你们支持,信任本网站的理由!真心非常感谢大家一直以来的理解和支持!
目 次
前言………………………………………………………………………………………………………… Ⅱ
引言………………………………………………………………………………………………………… Ⅲ
1 范围……………………………………………………………………………………………………… 1
2 规范性引用文件………………………………………………………………………………………… 1
3 术语和定义……………………………………………………………………………………………… 1
4 缩略语…………………………………………………………………………………………………… 2
5 类型及基本要求………………………………………………………………………………………… 4
6 多应用管理……………………………………………………………………………………………… 9
7 多应用架构…………………………………………………………………………………………… 13
8 支付账户介质识别码………………………………………………………………………………… 17
9 交通一卡通身份认证应用…………………………………………………………………………… 17
10 安全单元基本命令…………………………………………………………………………………… 17
11 密钥要求……………………………………………………………………………………………… 19
12 安全通信……………………………………………………………………………………………… 19
13 应用个人化服务……………………………………………………………………………………… 20
14 安全单元应用选择服务……………………………………………………………………………… 21
15 交通一卡通移动支付应用…………………………………………………………………………… 21
附录A(规范性) 照片信息文件………………………………………………………………………… 56
附录B(规范性) 对称密钥分散规则…………………………………………………………………… 60
附录C(规范性) 电子现金具备的密文版本…………………………………………………………… 61
参考文献…………………………………………………………………………………………………… 63
前 言
本文件按照GB/T 1.1—2020《标准化工作导则 第1部分:标准化文件的结构和起草规则》的规定
起草。
本文件是JT/T 1059《交通一卡通移动支付技术规范》的第2部分。JT/T 1059已经发布了以下部分:
——第1部分:总则;
——第2部分:安全单元;
——第3部分:近场支付;
——第4部分:远程支付;
——第5部分:客户端软件;
——第6部分:可信服务管理系统;
——第7部分:受理终端;
——第8部分:检测项目。
本文件代替JT/T 1059.2—2016《交通一卡通移动支付技术规范 第2 部分:安全单元》,与JT/T
1059.2—2016相比,除结构调整和编辑性改动外,主要技术变化如下:
——删除了“可穿戴设备”的术语和定义(见2016年版的3.5),更改了术语“可执行装载文件”的定
义(见3.6,2016年版的3.6);
——更改了全终端的供电要求(见5.2.6.1,2016年版的5.2.6.1);
——增加了基于云平台的SE的规定(见5.5);
——更改了辅助安全域中安全通道协议的安全要求(见7.2.2.2,2016年版的7.2.2.2),增加了SCP03
支持的密钥(见7.2.2.4);
——增加了身份认证应用的具体文件的规定(见9.2);
——增加了交通一卡通移动支付应用的规定(见第15章);
——增加了照片信息文件的规定(见附录A);
——增加了对称密钥分散规则的规定(见附录B);
——增加了电子现金具备的密文版本的规定(见附录C)。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由交通运输信息通信及导航标准化技术委员会提出并归口。
本文件起草单位:中国交通通信信息中心、北京中交金卡科技有限公司、上海复旦微电子集团股份
有限公司、东信和平科技股份有限公司、北京握奇数据股份有限公司、武汉天喻信息产业股份有限公
司、广州市微云卡系统科技有限公司、广东岭南通股份有限公司、长春市轨道交通集团有限公司、北京
市政交通一卡通有限公司、北京奥奈克斯科技有限公司。
本文件主要起草人:姜丛、张延铭、李岚、唐猛、郑菲、龚立伟、赵娜、郑少欢、赵龙、张淳、赵莹莹、
尹东敏、李金萍、李翠红、罗穗生、徐锋、何建兵、邢钊、许占富、赵立华、曾正喜、郑清来。
本文件及其所代替文件的历次版本发布情况为:
——2016年首次发布为JT/T 1059.2—2016;
——本次为第一次修订。
引 言
推广普及交通一卡通是发展综合运输服务、落实公共交通优先发展战略的重要举措,事关人民群
众切身利益,是重要的民生工程。JT/T 1059《交通一卡通移动支付技术规范》旨在规范交通一卡通移动
支付相关产品和系统的设计、研发和建设,拟由八个部分构成。
——第1部分:总则。目的在于确立交通一卡通移动支付的系统组成及总体技术要求。
——第2部分:安全单元。目的在于规范交通一卡通移动支付安全单元的类型及技术要求。
——第3部分:近场支付。目的在于规范交通一卡通移动支付近场支付的应用模型及交易技术
要求。
——第4部分:远程支付。目的在于规范交通一卡通移动支付远程支付的应用模型及业务处理技
术要求。
——第5部分:客户端软件。目的在于规范交通一卡通移动支付客户端软件的架构及功能、安全
技术要求。
——第6部分:可信服务管理系统。目的在于规范交通一卡通移动支付可信服务管理系统的组成
及安全、管理、接口技术要求。
——第7部分:受理终端。目的在于规范交通一卡通移动支付受理终端的类型及技术要求。
——第8部分:检测。目的在于规范交通一卡通移动支付可信服务管理系统、客户端软件、受理终
端及安全单元的检测要求。
1 范围
本文件规定了交通一卡通移动支付安全单元类型及基本要求、多应用管理、多应用架构、支付账户
介质识别码、交通一卡通身份认证应用、安全单元基本命令、密钥要求、安全通信、应用个人化服务、安
全单元应用选择服务,以及交通一卡通移动支付应用。
本文件适用于交通一卡通移动支付系统涉及的承载安全单元的载体的设计、生产以及相关应用系
统的研发、集成和维护管理。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中,注日期的引用文件,
仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T 16649. 1 识别卡 带触点的集成电路卡 第1部分:物理特性
GB/T 16649. 3 识别卡 带触点的集成电路卡 第3部分:电信号和传输协议
GB/T 16649. 4—2010 识别卡 集成电路卡 第4部分:用于交换的结构、安全和命令
GB/T 32918(所有部分) 信息安全技术 SM2椭圆曲线公钥密码算法
JR/T 0025. 15 中国金融集成电路(IC)卡规范 第15部分:电子现金双币支付应用规范
JT/T 978. 2—2023 城市公共交通IC卡技术规范 第2部分:卡片
JT/T 978. 5 城市公共交通IC卡技术规范 第5部分:非接触接口通信
JT/T 978. 6 城市公共交通IC卡技术规范 第6部分:安全
JT/T 1059. 1 交通一卡通移动支付技术规范 第1部分:总则
JT/T 1059. 3 交通一卡通移动支付技术规范 第3部分:近场支付
JT/T 1059. 7 交通一卡通移动支付技术规范 第7部分:受理终端
JT/T 1179 交通一卡通二维码支付技术规范
ETSI TS 102 613 智能卡 UICC‑非接触前端(CLF)接口 物理层和数据链路层特性[Smart
cards—UICC‑Contactless Front‑end(CLF)interface—Physical and data link layer characteristics]
ETSI TS 102 622 智能卡 UICC‑非接触前端(CLF)接口 主机控制器接口(HCI)[Smart cards—
UICC‑Contactless Front‑end(CLF)interface—Host controller interface(HCI)]
3 术语和定义
JT/T 1059. 1界定的以及下列术语和定义适用于本文件。
3. 1
主安全域 issuer security domain
安全单元中负责对安全单元管理者(通常是安全单元发行方)的管理、安全、通信等功能需求进行
1
JT/T 1059.2—2025
支持的首要实体。
3. 2
辅助安全域 supplementary security domain
除主安全域之外的其他安全域。
3. 3
支付账户介质识别码 payment account media identifier
唯一标识支付账户介质的代码。
3. 4
非接触前端 contactless front‑end
通过近场非接触接口实现通信的控制模块。
3. 5
可执行模块 executable module
可执行装载文件中包含的一个单独应用的可执行代码。
3. 6
可执行装载文件 executable load file
实际存在于卡片上的包含一个或多个可执行模块的容器。
4 缩略语
下列缩略语适用于本文件。
AAC:应用认证密文(Application Authorization Cryptogram)
AC:应用密文(Application Cryptogram)
ADF:应用专用文件(Application Definition File)
AFL:应用文件定位器(Application File Locator)
AID:应用标识符(Application Identifier)
AIP:应用交互特征(Application Interchange Profile)
APDU:应用协议数据单元(Application Protocol Data Unit)
API:应用编程接口(Application Programming Interface)
ARQC:授权请求密文(Authorization Request Cryptogram)
ATC:应用交易计数器(Application Transaction Counter)
BER:基本编码规则(Basic Encoding Rules)
CA:电子商务认证授权机构(Certificate Authority)
CLA:命令报文的类别字节(Class Byte of the Command Message)
CLF:非接触前端(Contactless Front‑end)
COS:片内操作系统(Chip Operating System)
CVR:卡片验证结果(Card Verification Results)
DAP:数据认证模式(Data Authentication Pattern)
DEK:数据加密密钥(Data Encryption Key)
DF:专用文件(Dedicated File)
EF:基本文件(Elementary File)
eID:公民网络电子身份标识(electronic IDentity)
2
JT/T 1059.2—2025
FCI:文件控制信息(File Control Information)
FID:文件标识符(File Identifier)
GP:全球平台(Global Platform)
HTTPS:超文本传输安全协议(Hyper Text Transfer Protool Secure)
ICV:初始链式矢量(Initial Chaining Vector)
ID:身份标识(Identity Document)
INS:命令报文的指令字节(Instruction Byte of Command Message)
ISD:主安全域(Issuer Security Domain)
I2C:内部集成电路(Inter‑Integrated Circuit)
Lc:命令报文数据域的长度(Length of the Command Data Field)
Le:响应报文数据域的最大期望长度(Maximum Length Expected of the Response Data Field)
MAC:报文鉴别码(Message Authentication Code)
MCU:微控制单元(Micro Controller Unit)
NFC:近场通信(Near Field Communication)
OPEN:全球平台环境(Global Platform Environment)
PAMID:支付账户介质识别码(Payment Account Media Identifier)
PDOL:处理选项数据对象列表(Processing Options Data Object List)
PPSE:近距离支付系统环境(Proximity Payment Systems Environment)
P1:参数1(Parameter One)
P2:参数2(Parameter Two)
RFU:预留(Reserved for Future Use)
R‑MAC:响应数据的报文鉴别码(Response Message Authentication Code)
SCP:安全通道协议(Secure Channel Protocol)
SE:安全单元(Secure Element)
SEID:安全单元身份标识(Secure Element IDentity)
SFI:短文件标识符(Short File Identifier)
SM2:SM2椭圆曲线公钥密码算法(Public Key Cryptographic Algorithm SM2 Based on Elliptic Curves)
SPI:步串行外设接口(Serial Peripheral Interface)
SSD:辅助安全域(Supplementary Security Domain)
SWP:单线协议(Single Wire Protocol)
SW1:状态字1(Status Word One)
SW2:状态字2(Status Word Two)
S‑ENC:安全通道命令和响应加密密钥(Secure Channel Encryption Key)
S‑MAC:安全通道消息鉴别码会话密钥(Secure Channel Message Authentication Code Key)
TC:交易证书(Transaction Certificate)
TCSD:交通一卡通认证安全域(Transport Certification Security Domain)
TLV:表示标签、长度以及值的组合(Tag Length Value)
TSD:交通一卡通辅助安全域(Transport Security Domain)
TSM:可信服务管理(Trusted Service Management)
T‑MTPS:交通一卡通公共服务(Transport‑Mobile Trustable Public Service)
3
JT/T 1059.2—2025
(U)SIM:(通用)用户身份识别模块[(Universal)Subscriber Identity Module]
5 类型及基本要求
5. 1 基于SWP 接口的(U)SIM 卡
5. 1. 1 物理特性
(U)SIM卡的物理特性应符合GB/T 16649. 1的规定。
5. 1. 2 接触通道
(U)SIM 卡的接触通道的接口电气特性和传输协议应符合GB/T 16649. 3 和GB/T 16649. 4 的
规定。
5. 1. 3 非接触通道
5. 1. 3. 1 非接触通道的电气特性和传输协议应符合JT/T 978. 5的规定,并应保证SE与读写终端的兼
容性。
5. 1. 3. 2 CLF和(U)SIM 卡之间应采用SWP 连接,SWP 接口的电气特性和链路层传输协议应符合
ETSI TS 102 613 8. 0 及以上版本的规定,其传输层协议应符合 ETSI TS 102 622 8. 0 及以上版本的
规定。
5. 1. 4 SE 逻辑结构
基于SWP接口的(U)SIM卡的SE包括接触通道和非接触通道,接触通道和非接触通道应具有并发
处理能力,且互不影响。基于SWP接口的(U)SIM卡SE逻辑结构应符合图1的规定。
图1 基于SWP 接口的(U)SIM 卡SE 逻辑结构
5. 1. 5 硬件方案结构
基于SWP接口(U)SIM卡移动支付方案的核心硬件包括天线、CLF、(U)SIM等模块,可以在移动支
付终端上实现非接触IC卡卡片功能。基于SWP接口(U)SIM卡移动支付硬件方案结构应符合图2的
规定。
4
JT/T 1059.2—2025
图2 基于SWP 接口的(U)SIM 卡硬件方案结构
5. 1. 6 供电要求
5. 1. 6. 1 当移动支付终端处于开机状态,或处于关机状态但电池仍能通过电源管理系统正常提供电
源能量时,(U)SIM卡可使用移动支付终端的电池作为电源能量;当移动支付终端的电池被取下时,或
电池无法通过电源管理系统正常提供电源能量时,(U)SIM卡可选择使用CLF芯片从受理终端的工作
场中感应得到的电源能量。
5. 1. 6. 2 在(U)SIM卡获得正常工作所需的电源能量时,应能正常运行交通一卡通移动支付应用。
5. 2 全终端
5. 2. 1 物理特性
全终端通过内置SE模块模拟非接触式IC卡,其物理特性、非接触通道的电气特性和传输协议应符
合JT/T 978. 5的要求。
5. 2. 2 接触通道
5. 2. 2. 1 CLF与内置SE模块之间的接口应提供主处理器和外部读写器设备访问SE模块的通路。
5. 2. 2. 2 移动支付终端具备内置SE模块的情况下,CLF和SE模块接口是内部接口。
5. 2. 3 非接触通道
非接触通道的电气特性和传输协议应符合JT/T 978. 5的规定,并应保证SE模块与读写终端的兼
容性。
5. 2. 4 SE 逻辑结构
全终端所用的SE包括接触通道和非接触通道,接触通道和非接触通道应具有并发处理能力,且互
不影响。全终端SE逻辑结构应符合图3的规定。
5. 2. 5 硬件方案结构
全终端移动支付的核心硬件方案结构应至少包含内置SE 模块、CLF 和天线等,应符合图4 的
规定。
5
JT/T 1059.2—2025
图3 全终端SE 逻辑结构
图4 全终端硬件方案结构
5. 2. 6 供电要求
5. 2. 6. 1 当移动支付终端处于开机状态,或处于关机状态但电池仍能通过电源管理系统正常提供电
源能量时,内置SE模块可使用移动支付终端的电池作为电源能量。
5. 2. 6. 2 在内置SE模块获得正常工作所需的电源能量时,应能正常运行交通一卡通移动支付应用。
5. 3 外置式SE
5. 3. 1 接触通道
MCU与SE接口是内部接口,宜采用GB/T 16649. 3、SPI等其他内部接口协议。MCU与SE之间的接
口应提供主处理器访问SE模块的通路。
5. 3. 2 非接触通道
非接触通道的电气特性和传输协议应符合JT/T 978. 5的规定。
5. 3. 3 SE 逻辑结构
外置式SE模块所用的SE包括接触通道和非接触通道,接触通道和非接触通道应具有并发处理能
力,且互不影响。外置式SE逻辑结构应符合图5的规定。
6
JT/T 1059.2—2025
图5 外置式SE 逻辑结构
5. 3. 4 硬件方案结构
5. 3. 4. 1 外置式SE是通过蓝牙等非接触通信方式与移动支付终端相连,能模拟非接触式IC卡,其非
接触通信功能应符合JT/T 978. 5的规定。
5. 3. 4. 2 外置式SE载体(包括可穿戴设备、异型卡等)的内部安装SE芯片和非接触天线,与移动支付
终端连接后,可实现交通一卡通移动支付应用下载、个人化、远程支付、空中充值和余额查询等功能。
5. 3. 4. 3 外置式SE载体硬件方案结构应符合图6的规定。
图6 外置式SE 载体硬件方案结构
5. 3. 5 供电要求
5. 3. 5. 1 外置式SE可使用外置设备的电池作为电源能量。当外置设备的电池电量小于预设阈值时,
应主动关机,预留部分电量供SE和非接触天线部件使用。外置设备关机时,电池应能通过电源管理系
统正常提供电量给SE,直至电量不能维持SE正常工作时,电源管理系统应切断SE的供电。
5. 3. 5. 2 外置式SE也可选择使用非接触天线从受理终端的工作场中感应得到的电源能量。
5. 3. 5. 3 外置式SE可获得正常工作所需的电源能量时,应能正常运行交通一卡通移动支付应用。
5. 4 双界面(U)SIM 卡
5. 4. 1 物理特性
双界面(U)SIM卡的物理特性应符合GB/T 16649. 1的规定。
7
JT/T 1059.2—2025
5. 4. 2 接触通道
双界面(U)SIM卡的接触通道的接口电气特性和传输协议应符合GB/T 16649. 3和GB/T 16649. 4的
规定。
5. 4. 3 非接触通道
非接触通道的电气特性和传输协议应符合JT/T 978. 5的规定。
5. 4. 4 SE 逻辑结构
双界面(U)SIM卡SE包括接触通道和非接触通道,接触通道和非接触通道应具有并发处理能力,
且互不影响。双界面(U)SIM卡SE逻辑结构应符合图7的规定。
图7 双界面(U)SIM 卡SE 逻辑结构
5. 4. 5 硬件方案结构
基于双界面(U)SIM卡实现近场支付功能的通信受理终端的硬件方案结构应至少包含双界面(U)
SIM、天线等模块,双界面(U)SIM卡硬件方案结构应符合图8的规定。
图8 双界面(U)SIM 卡硬件方案结构
5. 4. 6 供电要求
5. 4. 6. 1 当移动支付终端处于开机状态,或处于关机状态但电池仍能通过电源管理系统正常提供电
源能量时,双界面(U)SIM卡可使用移动支付终端的电池作为电源能量;当移动支付终端的电池被取下
8
JT/T 1059.2—2025
时,或电池无法通过电源管理系统正常提供电源能量时,双界面(U)SIM卡可选择使用其通过天线线圈
从受理终端的工作场中感应得到的电源能量。
5. 4. 6. 2 在双界面(U)SIM卡可获得正常工作所需的电源能量的情况下,应能正常运行交通一卡通移
动支付应用。
5. 5 基于云平台的SE
5. 5. 1 非接触通道
基于云平台SE的非接触通道的传输协议应至少符合HTTPS TLS1. 2的规定。
5. 5. 2 方案结构
基于云平台的SE是利用远程服务器来完成SE的应用功能。基于云平台的SE方案结构应至少包
含主处理器、手机NFC模组等模块,应符合图9的规定。
图9 基于云平台的SE 方案结构
5. 5. 3 供电要求
云平台依赖服务器的运行,应采用不间断电源供电。
6 多应用管理
6. 1 一般要求
6. 1. 1 交通一卡通移动支付应用中,SE作为移动支付的安全载体,除应对交易关键数据进行安全存
储和运算,确保进行的敏感交易具有安全认证和不可抵赖性外,还应支持多应用动态管理,并保证其安
全运行。移动支付SE多应用管理应包括以下主要功能:
a) 支持应用动态下载:支持在SE发行后,SE发行者或服务提供者根据业务扩充的需求,在SE上
动态加载新的应用供用户使用;
b) 支持多应用共存:通过将SE上不同的应用关联至相应的安全域,确保不同应用间的独立安全
运行,互不影响;
c) 支持与应用相匹配的安全策略:通过为不同的安全域实现其对应的安全通道,确保不同应用
采取与之匹配的安全策略与SE外部实体进行鉴权及安全会话。
6. 1. 2 SE应实现多应用的平台管理功能。SE多应用平台由安全域、全局服务应用、运行时环境、平台
9
JT/T 1059.2—2025
环境等系列组件构成。SE多应用平台应为SE上的应用和卡外TSM平台提供独立于硬件和厂商的接口。
6. 2 安全域
6. 2. 1 安全域应提供各类安全服务,包括密钥管理、加密解密、针对其所有者(发卡机构、应用提供方、
授权管理者)的应用进行数字签名的生成与验证等。当发卡机构、应用提供方、授权管理者等卡外实体
要将用到的安全服务进行隔离时,应通过安全域实现。
6. 2. 2 根据授权机构不同,SE安全域划分为ISD和SSD两种主要类型。ISD是SE上强制性存在的安
全域,是SE管理者(通常是发行方)在SE内的代表;SSD是SE上可选择存在的SSD,是应用提供方或发
行方以及它们的代理方在SE内的代表。
6. 3 全局服务应用
SE上可存在一个或多个全局服务应用,负责向其他应用提供者(如SE持有者)提供验证方法等的服务。
6. 4 运行时环境
SE多应用平台运行在一个安全的多应用运行时环境之上。运行时环境负责向所有应用提供硬件
中立API,确保各个应用的代码和数据能相互区隔及安全存储,负责执行空间分配机制,并提供服务,用
以完成SE和SE外部实体之间的通信。
6. 5 平台环境
SE平台环境的主要功能包括向应用提供API、命令转发、应用选择、逻辑通道管理及SE内容管理。
SE平台环境应拥有一个内部的全局平台注册表,用作信息资源进行SE的内容管理。全局平台注册表
包含管理SE、可执行装载文件、应用、安全域关联及权限所需信息。
6. 6 平台API
SE可通过平台API向应用提供各种服务(如持卡方验证服务、个人化服务和安全服务等),也可通
过平台API提供SE内容管理服务(如SE锁定或应用生命周期状态更新服务等)。
6. 7 SE 应用管理
6. 7. 1 SE负责管理其内部的安全域和各类应用,各类应用在通过平台命令下载至SE上后,应以可执
行装载文件的形式定义并存在。可执行装载文件保存在下列位置中:
a) SE内不可改变的存储区:可执行装载文件在SE生产过程中被装载到SE且不可被改变(可以
被禁止);
b) SE内可变存储区:可执行装载文件可以在发行前阶段或发行后阶段被装载或删除。
6. 7. 2 已下载并保存至SE的每一个可执行装载文件可包含一个或多个可执行模块。应用的安装过
程为:从一个可执行模块里创建一个应用实例,并连同该应用相关的数据一起放入SE的可变存储区
中,同时应用生命周期状态转化为已安装状态。此后生命周期状态转换见6. 8. 3。
6. 7. 3 已被创建的任何应用的实例及其相关的数据都可以被移除。一个SE应支持多个可执行装载
文件、多个可执行模块及多个应用同时存在。
6. 8 生命周期模型
6. 8. 1 SE 生命周期管理
SE生命周期包含平台就绪、初始化、安全、SE锁定和SE终止五个状态,见图10,图10中各状态符合
10
JT/T 1059.2—2025
下列要求。
a) 平台就绪状态:该状态表明运行时环境应就绪,作为选定应用的ISD应准备好接收、处理、响应
APDU命令。
b) 初始化状态:是一种可管理的卡产品状态,从平台就绪到初始化的切换应为不可逆操作。这
个状态表示一些初始的数据已经安装(比如:发行方安全域的密钥及数据),但是该卡还不能
发给持有者使用。
c) 安全状态:表示SE生命周期处于正式发行后,产品已经发行到最终用户并正式启动、使用已
装载业务。安全状态下,SE安全域和应用可完全贯彻各自的安全策略。从初始化状态到安全
状态的切换应为不可逆操作。
d) SE锁定状态:SE锁定状态下,应禁止对载体上的安全域和应用进行选择。从安全状态到SE
锁定状态的切换应为可逆操作。
e) SE终止状态:SE生命周期完结。SE终止状态应永久性禁止载体的任何功能以及任何内容管
理和生命周期的改变。从任何其他状态都可直接切换到SE终止状态,且状态切换应均为不
可逆操作。
注:此图中实线箭头表示SE安全域策略,虚线箭头表示SE应用策略。
图10 SE 生命周期状态
6. 8. 2 可执行装载文件和可执行模块生命周期管理
6. 8. 2. 1 可执行装载文件生命周期应只有一个状态。所有存放在SE内的可执行装载文件应处于
LOADED状态。
6. 8. 2. 2 可执行模块生命周期应与可执行装载文件的生命周期相匹配。
11
JT/T 1059.2—2025
6. 8. 3 安全域和应用生命周期管理
6. 8. 3. 1 安全域生命周期包含已安装、可选择、已个人化及已锁定四个状态(图11),图11中各状态应
符合以下要求。
a) 已安装状态:表示安全域已完成注册表条目注册。该状态下,安全域没有被选定,不应与可执
行装载文件或应用程序关联,故应用程序不能使用安全域服务。
b) 可选择状态:安全域可被选择,可接收相关个人化命令。此状态未装载应用密钥,安全域不应
和可执行装载文件或应用进行关联。从已安装状态到可选择状态的切换应为不可逆操作。
c) 已个人化状态:安全域已完成运行所需个人化数据与密钥数据的装载。该状态下,安全域与
应用已建立关联。从可选状态到已个人化状态的切换应为不可逆操作。
d) 已锁定状态:OPEN或安全域本身、相关安全域、具有全局锁定权限的应用程序或具有全局锁
定权限的安全域应能将生命周期状态设置为已锁定状态,并能阻止该安全域进一步被选择。
处于锁定状态的安全域应被禁止用于委托管理操作。一旦生命周期状态被锁定,只有安全域
的关联安全域、具有全局锁定权限的应用程序或具有全局锁定权限的安全域才能解锁该安全
域。OPEN保证该安全域生命周期在解锁后恢复至锁定前状态。
注:授权管理安全域也符合图中安全域生命周期管理。
标引序号说明:
1——具有授权管理功能的安全域; 4——具有锁定功能的安全域或应用;
2——具有托管功能的安全域; 5——安全域本身。
3——关联安全域;
图11 安全域生命周期状态
6. 8. 3. 2 SE应用生命周期包含已安装、可选择、已锁定及应用自定义四个状态(图12),图12中各状
态应符合下列规定。
a) 已安装状态:应用安装已完成并在SE注册表条目注册成功。该状态下,应用为不可选。安装
过程是个单独的步骤,不包含个人化操作。
b) 可选择状态:表示应用程序可被成功选择且能够接收相关命令。从已安装状态到可选择状态
的切换为不可逆操作。在设置成可选择状态前,应用已经正确安装且功能正常。迁移到可选
择状态可以同应用的安装一起进行。
12
JT/T 1059.2—2025
c) 已锁定状态:OPEN、应用程序本身、应用程序的相关安全域、具有全局锁定权限的应用程序或
具有全局锁定权限的安全域都能将生命周期状态设置为已锁定状态,并能阻止该应用程序进
一步被选择。一旦处于已锁定状态,只有应用关联的安全域,具备全局锁定权限的应用以及
具备全局锁定权限的安全域,才能够对应用进行解锁。OPEN确保应用生命周期能够恢复到
锁定前的状态。
d) 应用自定义状态:应用自己进行状态定义。
标引序号说明:
1——具有授权管理功能的安全域; 4——具有锁定功能的安全域或应用;
2——具有托管功能的安全域; 5——应用本身。
3——关联安全域;
图12 SE 应用生命周期状态
7 多应用架构
7. 1 一般要求
SE多应用架构包括多应用架构A和多应用架构B两种形式,每种应用架构由一系列的SE多应用
组件构成。支持移动支付的SE多应用组件如图13所示,应包括以下组件:
a) PAMID/SEID:PAMID是SE的唯一身份标识符,参见第8章,SEID是手机NFC模块的序列号,
也是SE的唯一标识。
b) PPSE:用于管理非接触应用列表。
c) 交通安全域:用于支持移动支付的一系列特定安全域,以实现移动支付的SE安全可信和开放
共享服务。
d) 交通一卡通移动支付应用:在SE上安全地提供支付功能的系列应用。
图13 移动支付的SE 多应用组件
13
JT/T 1059.2—2025
7. 2 SE 多应用架构A
7. 2. 1 一般要求
7. 2. 1. 1 SE多应用架构A为必选支持,应包括ISD、TSD、应用提供方SSD、交通一卡通移动支付应用
和身份认证应用,如图14所示。
图14 SE 多应用架构A
7. 2. 1. 2 在架构A中,ISD应由SE发行方持有,提供TSD的生命周期管理和应用管理授权,TSD采用
委托管理模式。交通一卡通移动支付应用关联到应用提供方SSD或TSD,并由ISD管理授权。
7. 2. 1. 3 应用提供方不具备交通一卡通移动支付应用的个人化能力时,应委托T‑MTPS平台进行应
用个人化操作。如图14所示,将交通一卡通移动支付应用A安装在TSD下,由T‑MTPS平台负责完成应
用个人化。
7. 2. 1. 4 应用提供方具备交通一卡通移动支付应用的个人化能力时,应由应用提供方自行完成应用
个人化操作。如图14所示,交通一卡通移动支付应用B下载、安装到TSD后,被迁移到应用提供方SSD
下,由应用提供方负责应用个人化。
7. 2. 2 SSD 安全要求
7. 2. 2. 1 TSD及TSD以下的SSD负责存储其所有方的通信密钥和DAP验证密钥(DAP验证密钥为可
选)。交通一卡通移动支付应用个人化时,应借助其关联安全域的安全通信功能,保护个人化数据的安
全性。
7. 2. 2. 2 安全域在创建时,其安全通道协议应设置为SCP02或SCP03,SCP02采用安全配置参数i=15
或i=55的实现方式,并至少注入一组初始密钥,安全配置参数(i)的配置应符合表1的规定。
表1 安全配置参数(i)的配置
b8
保留
保留
保留
保留
保留
保留
b7
—
—
—
—
—
—
b6
—
—
—
—
—
—
b5
—
—
—
—
—
—
b4
—
—
—
—
—
—
b3
—
—
—
—
10
b2
—
—
10
—
—
b1
10
—
—
—
—
描述
3个安全通道密钥
1个安全通道基本密钥
使用未修改的APDU计算MAC
使用修改后的APDU计算MAC
安全通道显示初始化模式
安全通道隐示初始化模式
14
JT/T 1059.2—2025
表1 安全配置参数(i)的配置(续)
b8
保留
保留
保留
保留
保留
保留
保留
保留
b7
—
—
—
—
—
—
10
b6
—
—
—
—
10
—
—
b5
—
—
10
—
—
—
—
b4
10
—
—
—
—
—
—
b3
—
—
—
—
—
—
—
—
b2
—
—
—
—
—
—
—
—
b1
—
—
—
—
—
—
—
—
描述
计算安全通道会话MAC时,通过AID计算初始ICV
ICV设置为0
MAC会话需要ICV加密
ICV 不加密
支持R‑MAC
不支持R‑MAC
伪随机数算法
真随机数算法
7. 2. 2. 3 SCP02每组密钥应包含S‑ENC、S‑MAC和DEK三种密钥,并应符合表2的规定。
表2 SCP02 密钥信息
类型
S‑ENC
S‑MAC
DEK
标识
0x01
0x02
0x03
用法
安全通道的鉴权和数据加密
安全通道的MAC验证和生成
敏感数据加/解密
长度(Byte)
16
16
16
是否必选
是
是
是
7. 2. 2. 4 SCP03应至少支持AES‑128、AES‑192、AES‑256三种密钥之一。
7. 2. 3 SSD 权限要求
7. 2. 3. 1 TSD应至少具备表3规定的权限。
表3 TSD 权限
序号
123
权限
安全域权限(Security Domain)
委托管理权限(Delegated Management)
可信路径权限(Trusted Path)
要求/说明
拥有此权限的应用是一个安全域
拥有此权限的应用应能对卡片内容进行委托管理
拥有此权限的应用是应用间通信的一条可信路径
7. 2. 3. 2 应用提供方SSD应至少具备表4规定的权限。
表4 应用提供方SSD 权限
序号
12
权限
安全域权限(Security Domain)
可信路径权限(Trusted Path)
描述
拥有此权限的应用是一个安全域
拥有此权限的应用是应用间通信的一条可信路径
7. 2. 4 SSD 功能要求
SSD应具备应用迁移、应用个人化和应用服务的能力。在安装SSD时,安装标签C9支持的参数应
符合表5的规定,其中,82和87标签编码规则应符合表6的规定。
15
JT/T 1059.2—2025
表5 安装标签C9 支持的参数
标签
81
82
84
87
长度值
0x02
0x01或0x02
0x00
0x01或 0x02
描述
用于设置安全通道的id和(i 15或55)
用于设置应用或安装包是否可迁入本SSD
若未出现该项标签,则在个人化结束后默认设置为个人化状态;若出现该项标
签,则在个人化结束后通过set status命令设置成个人化状态
用于设置应用或安装包是否可从本SSD迁出
表6 82 和87 标签编码规则
b8
0
1
1
—
—
1
—
b7
0
0
1
—
—
1
—
b6
0
—
—
1
—
1
—
b5
0
0
0
0
—
1
—
b4
0
—
—
—
1
—
—
b3
—
—
—
—
—
—
x
b2
—
—
—
—
—
—
x
b1
—
—
—
—
—
—
x
描述
SSD不接受迁入、迁出。如果安装参数不带82、
87标签,此为默认设置
SSD 接受从上一级具有授权管理权限的SSD 迁
入、迁出
SSD 接受从同一层次体系的任何具有授权管理
权限的SSD迁入、迁出
接受从ISD迁入、迁出
接受从具有委托管理权限的SSD迁入、迁出
接受从SE 上任何具备授权管理权限的SSD 迁
入、迁出
保留
7. 3 SE 多应用架构B
7. 3. 1 一般要求
7. 3. 1. 1 SE多应用架构B为可选支持,应包括ISD、TSD、TCSD、应用提供方SSD和交通一卡通移动支
付应用,如图15所示。
图15 SE 多应用架构B
7. 3. 1. 2 TCSD主要功能是进行SE及其持有人实名身份的验证和获取,应满足以下要求:
a) 由T‑MTPS平台持有,作为SE内的代表;
b) 具备安全域权限;
c) 提供SCP02或SCP03安全通道;
d) 存储的数据包括SE持有人的私钥和公钥证书、交通一卡通移动支付平台公钥证书及其他私
有数据,且除SE持有人私钥以外的数据均可通过获取数据命令获得。
16
JT/T 1059.2—2025
7. 3. 2 SSD 安全要求
SE多应用架构B的SSD安全要求应符合7. 2. 2的规定。
7. 3. 3 SSD 权限要求
7. 3. 3. 1 TSD 和TCSD 的权限
TSD和TCSD支持的权限应至少包括表7中的内容。
表7 TSD 和TCSD 支持的权限
序号
123
权限
安全域权限(Security Domain)
授权管理权限(Authorized Management)
可信路径权限(Trusted Path)
描述
拥有此权限的应用是一个安全域
拥有此权限的应用应能管理卡片内容
拥有此权限的应用是应用间通信的一条可信路径
7. 3. 3. 2 应用提供方SSD 的权限
应用提供方SSD具备的权限应符合表3规定。
7. 3. 4 SSD 功能要求
SE多应用架构B的SSD功能要求应符合7. 2. 4的规定。
8 支付账户介质识别码
8. 1 支付账户介质识别码(PAMID)应在TSD创建过程中作为其属性写入SE中,且PAMID应一次写入,
之后只能读取不能更改。
8. 2 存储PAMID的标识符(Tag)设置为0x74,用STORE DATA命令写入,用GET DATA命令读取。
8. 3 PAMID 应由T‑MTPS 平台统一管理,其编码结构为:5 Byte 发行方机构代码+1 Byte 介质类型+
10 Byte发行方SE内部编码。其中,介质类型包括:00‑SWP(U)SIM卡;01‑全终端设备;02‑双界面(U)
SIM卡;03‑外置设备。
9 交通一卡通身份认证应用
9. 1 交通一卡通身份认证应用应能提供SE及其持有人实名身份的验证和获取服务,应用内容包括存
储经加密的卡片持有人实名身份信息(或信息的索引)。无特殊权限,应安装在TSD或SSD下,通过
TSD或SSD的安全服务进行个人化,提供私有指令方式验证(或获取)卡片持有人实名身份信息或私有
数据的服务。
9. 2 身份认证应用包括人脸识别和身份信息的识别。其中人脸识别的照片信息文件应符合附录A的
规定,身份信息的识别可以将身份信息存储在eID文件中。
10 安全单元基本命令
安全单元(SE)基本命令应符合表8的规定。
17
JT/T 1059.2—2025
表8 SE 基本命令
命令
DELETE可执行装载
文件
DELETE可执行装载
文件和相关应用
DELETE应用
DELETE密钥
GET DATA
GET STATUS
INSTALL[加载]
INSTALL[安装]
INSTALL[加载、安装
和设为可选]
INSTALL
[安装和设为可选]
INSTALL[设为可选]
INSTALL[迁移]
INSTALL[更新注册表]
INSTALL[个人化]
LOAD
PUT KEY
SELECT
SET STATUS
STORE DATA
注1:√——必备,□——可选,■——禁止。
注2:TCSD及TSD在SE多应用架构B中属于授权管理权限安全域。
注3:TSD在SE多应用架构A中属于委托管理权限安全域。
a 支持委托管理权限安全域/其他安全域PUT Key命令操作。
b 支持委托管理权限安全域/其他安全域锁定、解锁相关应用。
平台就绪
授权
管理
权限
安全
域
□
□
√□√√□□
□
√
□□□□□√√√√
委托
管理
权限
安全
域
□
□
√□√□□□
□
√
□□□□□□√□□
其他
安全
域
■
■
■□√□■■
■
■
■■■□■□√□□
初始化
授权
管理
权限
安全
域
□
□
√□√√□□
□
√
□□□□□√√√√
委托
管理
权限
安全
域
□
□
√□√□□□
□
√
□□□□□□√□□
其他
安全
域
■
■
■□√□■■
■
■
■■■□■□√□□
安全
授权
管理
权限
安全
域
□
□
√□√√□□
□
√
□□□□□√√√√
委托
管理
权限
安全
域
□
□
√□√□□□
□
√
□□□□□√
a
√
√b
□
其他
安全
域
■
■
■□√□■■ ■
■
■■■□■√
a
√
√b
□
锁定
最终
应用
权限
安全
域
■
■
■■√√■■
■
■
■■■■■■√√■
其他
安全
域
■
■
■■■■■■
■
■
■■■■■■■■■
终止
最终
应用
权限
安全
域
■
■
■■√■■■
■
■
■■■■■■■■■
其他
安全
域
■
■
■■
■■■■
■
■
■■■■■■■■■
18
JT/T 1059.2—2025
11 密钥要求
11. 1 密钥种类
11. 1. 1 令牌和收条密钥
若SE支持委托管理,则应具有令牌验证权限和生成收条权限的安全域,该安全域应具有表9所示
的密钥,并满足表9的规定。表中RSA密钥的长度应大于或等于上述最短长度,且是32 bit的倍数。
表9 令牌和收条密钥
密钥
令牌
收条
收条
收条
用途
令牌验证(RSA公钥)
生成收条(DES密钥),可选
生成收条(RSA私钥),可选
生成收条(AES私钥),可选
最短长度(bit)
1024
128
1024
128
说明
仅委托管理
仅委托管理
仅委托管理
仅委托管理
11. 1. 2 DAP 验证密钥
若安全域支持DAP验证,则安全域应当有一个RSA公钥或一个DES密钥来验证加载文件数据块
签名,并应满足表10的规定。表中RSA密钥的长度应大于或等于上述最短长度,且是32 bit的倍数。
表10 DAP 验证密钥
密钥
DAP验证
DAP验证
用途
加载文件数据块签名验证(RSA公钥)
加载文件数据块签名验证(DES密钥)
最短长度(bit)
1024
128
说明
仅DAP验证
仅DAP验证
11. 2 密钥算法
交通一卡通移动支付业务使用的密钥算法应符合JT/T 978. 6的规定。
12 安全通信
SE安全通信采用SCP02或SCP03安全通道协议,在安全状态后,所需的APDU命令的最低安全级
别要求应符合表11的规定。
表11 所需的APDU 命令的最低安全级别
命令
INITIALIZE UPDATE
EXTERNAL AUTHENTICATE
最低安全级别
无
C‑MAC(01)
19
JT/T 1059.2—2025
13 应用个人化服务
13. 1 一般要求
13. 1. 1 应用安装后,应加载其个人化数据,包括密钥、发卡机构应用数据和持卡人数据。该应用通过
安全通信及相关安全域提供的密钥解密服务来管理个人化数据的安全下载。
13. 1. 2 SE应支持以下两种方式之一实现个人化服务:
a) 使用运行时消息流;
b) 使用安全域访问。
13. 2 运行时的消息流
安全域可以为其直接关联的应用提供运行时支持。应用可以通过关联的安全域服务实现安全通
道的建立和数据的安全传递,以实现应用的个人化。运行时消息流实现应用个人化流程应符合图16
的规定。
图16 运行时消息流实现应用个人化流程
13. 3 安全域访问
安全域应有能力接收一个STORE DATA命令并发送给与其相关联的应用。安全域将命令转发给
应用之前,应能根据安全通道的级别对命令进行验证并解包。解包后的命令结构应保持跟封包之前的
格式一致。安全域访问实现应用个人化流程应符合图17的规定。
20
JT/T 1059.2—2025
图17 安全域访问实现应用个人化流程
14 安全单元应用选择服务
安全单位(SE)应用选择服务应包括以下两种:
a) 受理环境选择交通一卡通移动支付应用,非接触途径要求仅提供PPSE选择,符合JT/T 978. 2
中相关PPSE选择流程的要求,通过FCI模板返回应用AID列表;
b) 移动支付终端上的应用管理客户端直接使用SELECT AID方式,选择交通一卡通移动支付应用。
15 交通一卡通移动支付应用
15. 1 电子钱包
15. 1. 1 文件结构
15. 1. 1. 1 一般要求
电子钱包的文件结构应符合图18的规定。
15. 1. 1. 2 二进制文件
公共应用信息文件、持卡人基本信息文件、管理信息文件、交易明细文件、eID标识文件、照片密文
信息文件,应符合JT/T 978. 2—2023中B. 2. 2的规定。其中eID标识文件和照片密文信息文件来源应
符合JT/T 978. 2—2023中6. 4. 7的规定。
21
JT/T 1059.2—2025
图18 电子钱包的文件结构
15. 1. 1. 3 记录文件
15. 1. 1. 3. 1 公共交通过程信息变长记录文件
公共交通过程变长记录文件应符合JT/T 978. 2—2023中B. 2. 4的规定。
15. 1. 1. 3. 2 公共交通过程信息循环记录文件
公共交通过程信息循环记录文件应符合JT/T 978. 2—2023中B. 2. 5的规定。
15. 1. 1. 4 照片信息文件
照片信息文件(SFI=0x1B)应符合附录A的规定,该文件为可选文件。
15. 1. 1. 5 余额文件
15. 1. 1. 5. 1 第一票种余额
卡片应具备电子钱包脱机实际余额计数器1和电子钱包脱机已透支金额计数器2,使用时计数器
上限为0xFFFFFF。第一票种余额由0x9F51识别,包括:可用余额(4 Byte)、透支限额(4 Byte)、已透支金
额(4 Byte)、实际余额(4 Byte)、实际余额上限(4 Byte)。
15. 1. 1. 5. 2 第二票种余额
卡片应具备电子钱包脱机实际余额计数器3和电子钱包脱机已透支金额计数器4,使用时计数器
22
JT/T 1059.2—2025
上限为0xFFFFFF。第二票种余额由0xDF71识别,包括:可用余额(4 Byte)、透支限额(4 Byte)、已透支
金额(4 Byte)、实际余额(4 Byte)、实际余额上限(4 Byte)。
15. 1. 2 命令
15. 1. 2. 1 选择PPSE 命令
选择PPSE(SELECT PPSE)命令应符合JT/T 978. 2—2023中C. 1. 1的规定。
15. 1. 2. 2 选择ADF 命令
15. 1. 2. 2. 1 概述
选择ADF(SELECT ADF)命令属于GB/T 16649. 4—2010规定的指令模式4,通过选择AID来选择
卡片中ADF。成功执行该命令设定ADF的路径。从卡片返回的响应报文包含回送FCI。
15. 1. 2. 2. 2 命令报文编码
SELECT ADF命令报文编码应符合表12的规定。
表12 SELECT ADF 命令报文编码
编码
CLA
INS
P1
P2
Lc
Data
Le
值
0x00
0xA4
0x04
0x00
0x08~0x10
15.1.3要求的AID
0x00
15. 1. 2. 2. 3 命令报文数据域
命令报文数据域应包括DF名、AID。
15. 1. 2. 2. 4 响应报文数据域
SELECT ADF命令响应报文数据应符合表13的规定,发卡机构自定义数据应符合表14的规定。
表13 SELECT ADF 命令响应报文数据
6F FCI模板
84
A5
DF名
FCI数据专用模板
50
87
9F51
应用标签
应用优先指示符
第一票种货币代码
必选
必选
必选
可选
可选
可选
标签值(十六进制) 约束条件
23
JT/T 1059.2—2025
注1:9F51为两字节,DF71为两字节,AID=A000000632101004时,此两字节为必选项,AID=A000000632010105时,
9F51和DF71不存在。
注2:9F08的值为02;9F08为可选项,若无此Tag,则应用版本默认为01。
注3:无DF00标识仅支持国际算法。
注4:DF00用于指示当前卡片支持的算法为一字节(00:国际算法,01:国密算法,02:双算法)。
注5:DF0A为两字节,第一字节bit0为1时表示支持eID标识,其他bit及第二字节为预留。
DF71
9F08
9F12
DF00
DF0A
9F0C
第二票种货币代码
应用版本号
应用优先名称
SM算法具备指示器
eID信息标识
发卡机构自定义数据见表14
可选
可选
可选
必选
必选
必选
表13 SELECT ADF 命令响应报文数据(续)
标签值(十六进制) 约束条件
表14 发卡机构自定义数据
数据字段名称
发卡机构代码
应用类型标识
应用启用标识
应用序列号
应用启用日期
应用有效日期
发卡机构自定义FCI数据
长度(Byte)
811
10
442
15. 1. 2. 2. 5 响应报文状态字
SELECT ADF命令响应报文状态字应符合表15的规定。
表15 SELECT ADF 命令响应报文状态字
状态字
SW1
0x6A
0x62
0x62
SW2
0x82
0x83
0x84
状态
未找到文件
选择文件无效,应用已临时锁定
选择文件无效,应用已永久锁定
15. 1. 2. 3 国密/国际算法操作命令
应符合JT/T 978. 2—2023的C. 3. 22的规定。
24
JT/T 1059.2—2025
15. 1. 2. 4 应用锁定命令
应符合JT/T 978. 2—2023的C. 3. 1的规定。
15. 1. 2. 5 应用解锁命令
应符合JT/T 978. 2—2023的C. 3. 2的规定。
15. 1. 2. 6 外部认证命令
应符合JT/T 978. 2—2023的C. 3. 3的规定。
15. 1. 2. 7 取随机数命令
应符合JT/T 978. 2—2023的C. 3. 4的规定。
15. 1. 2. 8 读二进制文件命令
应符合JT/T 978. 2—2023的C. 3. 6的规定,若卡片为表16中的状态,则应按表16的规定返回相应
的状态字。
表16 READ BINARY 响应报文状态字
状态字
SW1
0x62
0x62
0x69
0x69
0x69
0x6A
0x6A
0x6B
0x62
0x93
0x6C
SW2
0x81
0x82
0x81
0x82
0x86
0x81
0x82
0x00
0x83
0x03
0xXX
状态
部分回送的数据可能有错
文件长度小于Le
命令与文件结构不相容
不满足安全状态
不满足命令执行的条件(非当前EF)
不具备此功能
未找到文件
参数错误(偏移地址超出了EF)
临时锁定
永久锁定
长度错误(Le错误;XX为实际长度)
15. 1. 2. 9 更新二进制文件命令
应符合JT/T 978. 2—2023的C. 3. 7的规定。
15. 1. 2. 10 初始化圈存命令
15. 1. 2. 10. 1 概述
初始化圈存(INITIALIZE FOR LOAD)命令属于GB/T 16649. 4—2010规定的指令模式4,用于初始
化圈存交易。
25
JT/T 1059.2—2025
15. 1. 2. 10. 2 命令报文编码
INITIALIZE FOR LOAD命令报文编码应符合表17的规定。
表17 INITIALIZE FOR LOAD 命令报文编码
编码
CLA
INS
P1
P2
Lc
Data
Le
值
0x80
0x50
0x00:交易第一票种;
0x10:交易第二票种
0x02
0x0B
按表18
0x10
15. 1. 2. 10. 3 命令报文数据域
INITIALIZE FOR LOAD命令报文数据域应符合表18的规定。
表18 INITIALIZE FOR LOAD 命令报文数据域
元素
密钥索引号
交易金额
终端机编号
长度(Byte)
146
15. 1. 2. 10. 4 响应报文数据域
该命令执行成功的响应报文数据域应符合表19的规定;若命令执行不成功,则只在响应报文中回
送SW1和SW2。
表19 INITIALIZE FOR LOAD 响应报文数据域
元素
电子钱包余额(实际余额+透支限额-已透支金额)
联机交易序号
密钥索引(DLK)
算法标识(DLK)
伪随机数(卡片)
MAC1
长度(Byte)
421144
15. 1. 2. 10. 5 响应报文状态字
该命令执行成功的状态字是9000;若卡片为表20中的状态,则应按表20的规定返回相应的状
态字。
26
JT/T 1059.2—2025
表20 INITIALIZE FOR LOAD 响应报文状态字
状态字
SW1
0x65
0x69
0x93
0x6A
0x94
0x94
0x94
SW2
0x81
0x85
0x03
0x81
0x01
0x03
0x02
状态
内存错误
使用条件(状态机)不满足
应用永久锁定
功能不具备
交易金额超限
密钥索引不具备
交易计数器达到最大值
15. 1. 2. 11 圈存命令
15. 1. 2. 11. 1 概述
圈存(CREDIT FOR LOAD)命令属于GB/T 16649. 4—2010规定的指令模式4,用于圈存交易。
15. 1. 2. 11. 2 命令报文编码
CREDIT FOR LOAD命令报文编码应符合表21的规定。
表21 CREDIT FOR LOAD 命令报文编码
编码
CLA
INS
P1
P2
Lc
Data
Le
值
0x80
0x52
0x00:交易第一票种;
0x10:交易第二票种
0x00
0x0B
按表22
0x04
15. 1. 2. 11. 3 命令报文数据域
CREDIT FOR LOAD命令报文数据域应符合表22的规定。
表22 CREDIT FOR LOAD 命令报文数据域
元素
交易日期(主机)
交易时间(主机)
MAC2
长度(Byte)
434
27
JT/T 1059.2—2025
15. 1. 2. 11. 4 响应报文数据域
CREDIT FOR LOAD响应报文数据域应符合表23的规定;若命令执行不成功,则只在响应报文中
回送SW1和SW2。
表23 CREDIT FOR LOAD 响应报文数据域
元素
TAC
长度(Byte)
4
15. 1. 2. 11. 5 响应报文状态字
该命令执行成功的状态字是9000;若卡片为表24中的状态,则应按表24的规定返回相应的状
态字。
表24 CREDIT FOR LOAD 响应报文状态字
状态字
SW1
0x65
0x69
0x69
0x93
0x62
0x93
SW2
0x81
0x01
0x85
0x02
0x83
0x03
状态
内存错误
命令不接受(无效状态机)
使用条件不满足
MAC无效
累计圈存MAC错误200次后临时锁定
应用永久锁定
15. 1. 2. 12 初始化消费命令
15. 1. 2. 12. 1 概述
初始化消费(INITIALIZE FOR PURCHASE)命令属于GB/T 16649. 4—2010规定的指令模式4,用于
初始化消费交易。
15. 1. 2. 12. 2 命令报文编码
INITIALIZE FOR PURCHASE命令报文编码应符合表25的规定。
表25 INITIALIZE FOR PURCHASE 命令报文编码
编码
CLA
INS
P1
P2
Lc
Data
Le
值
0x80
0x50
0x01:交易第一票种;
0x11:交易第二票种
0x02
0x0B
按表26
0x0F
28
JT/T 1059.2—2025
15. 1. 2. 12. 3 命令报文数据域
INITIALIZE FOR PURCHASE命令报文数据域应符合表26的规定。
表26 INITIALIZE FOR PURCHASE 命令报文数据域
元素
密钥索引号
交易金额
终端机编号
长度(Byte)
146
15. 1. 2. 12. 4 响应报文数据域
该命令执行成功的响应报文数据域应符合表27的规定;若命令执行不成功,则只在响应报文中回
送SW1和SW2。
表27 INITIALIZE FOR PURCHASE 响应报文数据域
元素
电子钱包余额(实际余额+透支限额-已透支金额)
脱机交易序号
透支限额
密钥索引
算法标识
伪随机数(卡片)
长度(Byte)
423114
15. 1. 2. 12. 5 响应报文状态字
该命令执行成功的状态字是9000;若卡片为表28中的状态,则应按表28的规定返回相应的状
态字。
表28 INITIALIZE FOR PURCHASE 响应报文状态字
状态字
SW1
0x65
0x69
0x93
0x94
0x94
0x94
SW2
0x81
0x85
0x03
0x01
0x03
0x02
状态
内存错误
使用条件(状态机)不满足
应用永久锁定
交易金额超限
密钥索引不具备
交易计数器达到最大值
15. 1. 2. 13 消费命令
15. 1. 2. 13. 1 概述
消费(DEBIT FOR PURCHASE)命令属于GB/T 16649. 4—2010规定的指令模式4,用于消费交易。
29
JT/T 1059.2—2025
15. 1. 2. 13. 2 命令报文编码
DEBIT FOR PURCHASE命令报文编码应符合表29的规定;执行INITIALIZE FOR PURCHASE后即
选择消费交易。
表29 DEBIT FOR PURCHASE 命令报文编码
编码
CLA
INS
P1
P2
Lc
Data
Le
值
0x80
0x54
0x01:交易第一票种;
0x11:交易第二票种
0x00
0x0F
按表30
0x08
15. 1. 2. 13. 3 命令报文数据域
DEBIT FOR PURCHASE命令报文数据域应符合表30的规定。
表30 DEBIT FOR PURCHASE 命令报文数据域
元素
终端交易序号
交易日期(终端)
交易时间(终端)
MAC1
长度(Byte)
4434
15. 1. 2. 13. 4 响应报文数据域
该命令执行成功的响应报文数据域应符合表31的规定;若命令执行不成功,则只在响应报文中回
送SW1和SW2。
表31 DEBIT FOR PURCHASE 响应报文数据域
元素
TAC
MAC2
长度(Byte)
44
15. 1. 2. 13. 5 响应报文状态字
该命令执行成功的状态字是9000;若卡片为表32中的状态,则应按表32的规定返回相应的状
态字。
30
JT/T 1059.2—2025
表32 DEBIT FOR PURCHASE 响应报文状态字
状态字
SW1
0x65
0x69
0x69
0x93
0x93
0x62
SW2
0x81
0x01
0x85
0x02
0x03
0x83
状态
内存错误
命令不接受(无效状态机)
使用条件不满足
MAC无效
应用永久锁定
累计消费MAC错误次数200次后临时锁定
15. 1. 2. 14 初始化圈提命令
15. 1. 2. 14. 1 概述
初始化圈提(INITIALIZE FOR UNLOAD)命令属于GB/T 16649. 4—2010规定指令模式4,用于初始
化圈提交易。
15. 1. 2. 14. 2 命令报文编码
INITIALIZE FOR UNLOAD命令报文编码应符合表33的规定。
表33 INITIALIZE FOR UNLOAD 命令报文编码
编码
CLA
INS
P1
P2
Lc
Data
Le
值
0x80
0x50
0x05:交易第一票种;
0x15:交易第二票种
0x02
0x0B
应符合表34的规定
0x10
15. 1. 2. 14. 3 命令报文数据域
INITIALIZE FOR UNLOAD命令报文数据域应符合表34的规定。
表34 INITIALIZE FOR UNLOAD 命令报文数据域
元素
密钥索引号
交易金额
终端机编号
长度(Byte)
146
31
JT/T 1059.2—2025
15. 1. 2. 14. 4 响应报文数据域
该命令执行成功的响应报文数据域应符合表35的规定;若命令执行不成功,则只在响应报文中回
送SW1和SW2。
表35 INITIALIZE FOR UNLOAD 响应报文数据域
元素
电子钱包余额(实际余额+透支限额-已透支金额)
联机交易序号
密钥索引(DULK)
算法标识(DULK)
伪随机数(卡片)
MAC1
长度(Byte)
421144
15. 1. 2. 14. 5 响应报文状态字
该命令执行成功的状态字是9000;若卡片为表36中的状态,则应按表36的规定返回相应的状
态字。
表36 INITIALIZE FOR UNLOAD 响应报文状态字
状态字
SW1
0x65
0x69
0x93
0x94
0x94
0x94
SW2
0x81
0x85
0x03
0x01
0x03
0x02
状态
内存错误
使用条件(状态机)不满足
应用永久锁定
交易金额超限
密钥索引不具备
交易计数器达到最大值
15. 1. 2. 15 圈提命令
15. 1. 2. 15. 1 概述
圈提(DEBIT FOR UNLOAD)命令属于GB/T 16649. 4—2010规定的指令模式4,用于圈提交易。该
命令只能在支持圈提业务的终端上使用。
15. 1. 2. 15. 2 命令报文编码
DEBIT FOR UNLOAD命令报文编码应符合表37的规定。
表37 DEBIT FOR UNLOAD 命令报文编码
CLA
INS
0x80
0x54
编码值
32
JT/T 1059.2—2025
P1
P2
Lc
Data
Le
0x03:交易第一票种;
0x13:交易第二票种
0x00
0x0B
按表38
0x04
表37 DEBIT FOR UNLOAD 命令报文编码(续)
编码值
15. 1. 2. 15. 3 命令报文数据域
DEBIT FOR PURCHASE命令报文数据域应符合表38的规定。
表38 DEBIT FOR UNLOAD 命令报文数据域
元素
交易日期(主机)
交易时间(主机)
MAC2
长度(Byte)
434
15. 1. 2. 15. 4 响应报文数据域
该命令执行成功的响应报文数据域应符合表39的规定;若命令执行不成功,则只在响应报文中回
送SW1和SW2。
表39 DEBIT FOR UNLOAD 响应报文数据域
元素
MAC3
长度(Byte)
4
15. 1. 2. 15. 5 响应报文状态字
该命令执行成功的状态字是9000;若卡片为表40中的状态,则应按表40的规定返回相应的状
态字。
表40 DEBIT FOR UNLOAD 错误状态字
状态字
SW1
0x65
0x69
0x93
0x93
0x62
SW2
0x81
0x01
0x02
0x03
0x83
状态
内存错误
命令不接受(无效状态机)
MAC无效
应用永久锁定
连续累计圈提MAC错误次数200次后临时锁定
33
JT/T 1059.2—2025
15. 1. 2. 16 查询余额命令
15. 1. 2. 16. 1 概述
查询余额(GET BALANCE)命令属于GB/T 16649. 4—2010规定的指令模式2,用于读取电子钱包第
一票种或第二票种脱机余额,实现查询余额交易。
15. 1. 2. 16. 2 命令报文编码
GET BALANCE命令报文编码应符合表41的规定。
表41 GET BALANCE 命令报文编码
编码
CLA
INS
P1
P2
Lc
Data
Le
值
0x80
0x5C
0x00/0x01/0x02/0x03/0x04/0x05:第一票种;
0x06/0x07/0x08/0x09/0x0A/0x0B:第二票种
0x02
不存在
不存在
0x04/0x10
15. 1. 2. 16. 3 响应报文数据域
15. 1. 2. 16. 3. 1 响应报文的数据域应符合下列规定:
a) 若P1=0x00/0x06,则响应报文数据域为4 Byte(第一票种/第二票种)电子钱包可用余额(实际
余额+透支限额-已透支金额);
b) 若P1=0x01/0x07,则响应报文数据域为4 Byte(第一票种/第二票种)透支限额;
c) 若P1=0x02/0x08,则响应报文数据域为4 Byte(第一票种/第二票种)已透支金额;
d) 若P1=0x03/0x09,则响应报文数据域为4 Byte(第一票种/第二票种)电子钱包实际余额;
e) 若P1=0x04/0x0A,则响应报文数据域为4 Byte(第一票种/第二票种)实际余额上限;
f ) 若P1=0x05/0x0B,则响应报文数据域为4 Byte(第一票种/第二票种)电子钱包实际余额加
4 Byte(第一票种/第二票种)实际余额上限加4 Byte(第一票种/第二票种)已透支金额加4 Byte
(第一票种/第二票种)透支限额,总共16 Byte。
15. 1. 2. 16. 3. 2 命令执行成功的响应报文数据域应符合表42的规定。若命令执行不成功,则只在响
应报文中回送SW1和SW2。
表42 GET BALANCE 响应报文数据域
元素
电子钱包余额、透支限额、已透支金额或实际余额上限
长度(Byte)
4或16
15. 1. 2. 16. 4 响应报文状态字
该命令执行成功的状态字是9000;若卡片为表43中的状态,则应按表43的规定返回相应的状
态字。
34
JT/T 1059.2—2025
表43 GET BALANCE 错误状态字
状态字
SW1
0x65
0x69
0x69
0x6A
0x6D
0x6E
SW2
0x81
0x85
0x82
0x86
0x00
0x00
状态
内存错误
使用条件不满足
安全条件不满足
P1和P2参数不正确
INS不具备或错误
CLA不具备或错误
15. 1. 2. 17 取交易认证命令
15. 1. 2. 17. 1 概述
取交易认证(GET TRANSACTION PROVE)命令属于GB/T 16649. 4—2010规定的指令模式4,提供
了一种在交易处理过程中卡片离场并重新进场的恢复机制。
15. 1. 2. 17. 2 命令报文编码
GET TRANSACTION PROVE命令报文编码应符合表44的规定。
表44 GET TRANSACTION PROVE 命令报文编码
编码
CLA
INS
P1
P2
Lc
Data
Le
值
0x80
0x5A
0x00
a) 第一票种要取的MAC或/和TAC所对应的交易类型
标识:
1) 0x02:圈存;
2) 0x03:圈提;
3) 0x06:单次交易;
4) 0x07:修改;
5) 0x09:CAPP交易。
b) 第二票种要取的MAC或/和TAC所对应的交易类型
标识:
1) 0x12:圈存;
2) 0x13:圈提;
3) 0x16:单次交易;
4) 0x17:修改;
5) 0x19:CAPP交易
0x02
按表45
0x08
35
JT/T 1059.2—2025
15. 1. 2. 17. 3 命令报文数据域
GET TRANSACTION PROVE命令报文数据域应符合表45的规定。若命令中指定的交易类型标识
和联机或者脱机交易序号对应的MAC或TAC可用,则响应报文数据域应符合表46的规定。
表45 GET TRANSACTION PROVE 命令报文数据域
元素
要取的MAC或/和TAC所对应的联机或者脱机交易序号
长度(Byte)
2
表46 GET TRANSACTION PROVE 响应报文数据域
元素
MAC
TAC
长度(Byte)
44
15. 1. 2. 17. 4 响应报文状态字
该命令执行成功的状态字是9000;若卡片为表47中的状态,则应按表47的规定返回相应的状态字。
表47 GET TRANSACTION PROVE 错误状态字
状态字
SW1
0x65
0x69
0x93
0x94
SW2
0x81
0x85
0x03
0x06
状态
内存错误
使用条件不满足
应用永久锁定
所需MAC不可用
15. 1. 2. 18 初始化修改命令
15. 1. 2. 18. 1 概述
初始化修改(INITIALIZE FOR UPDATE)命令属于GB/T 16649. 4—2010规定的指令模式4,用于初
始化修改透支限额交易。
15. 1. 2. 18. 2 命令报文编码
INITIALIZE FOR UPDATE命令报文编码应符合表48的规定。
表48 INITIALIZE FOR UPDATE 命令报文编码
CLA
INS
P1
P2
0x80
0x50
0x04:交易第一票种;
0x14:交易第二票种
0x01
编码值
36
JT/T 1059.2—2025
Lc
Data
Le
0x07
按表49
0x13
表48 INITIALIZE FOR UPDATE 命令报文编码(续)
编码值
15. 1. 2. 18. 3 命令报文数据域
INITIALIZE FOR UPDATE命令报文数据域应符合表49的规定。
表49 INITIALIZE FOR UPDATE 命令报文数据域
元素
密钥索引号
终端机编号
长度(Byte)
16
15. 1. 2. 18. 4 响应报文数据域
命令执行成功的响应报文数
评论