中国移动TSM平台接入开发指引

多应用开放平台应用接入开发指引

修改历史

目录

1 术语 (5)

2 平台概况 (5)

2.1 平台概述 (5)

3 开发范围 (5)

3.1 应用模式 (5)

3.2 应用客户端 (6)

3.3 NFC-SIM卡应用 (6)

3.4 业务平台 (6)

4 开发流程 (6)

5 流程说明 (7)

5.1 应用流程 (7)

5.1.1 下载 (7)

5.1.2 删除 (9)

5.1.3 应用更新 (10)

6 卡应用开发指南 (11)

6.1 卡应用开发模式 (11)

6.2 卡应用开发要求 (12)

6.3 密钥交换流程 (12)

6.4 卡应用开发 (12)

6.5 卡应用发布更新 (14)

7 客户端开发指南 (15)

7.1 应用客户端开发要求 (15)

7.2 客户端开发准备 (15)

7.3 设置开发环境 (15)

7.4 客户端开发 (19)

7.4.1 创建工程 (19)

7.4.2 编写AndroidManifest.xml文件 (19)

7.4.3 手机客户端开发编码 (19)

7.4.4 代码示例 (20)

3.1 客户端发布更新 (21)

4 业务平台开发指南 (21)

4.1 接口描述 (21)

4.1.1 WebService名字空间 (21)

4.1.2 接口列表 (21)

4.1.3 数据类型说明 (22)

4.1.4 数据域说明 (22)

4.1.5 消息类型描述 (24)

5.5.1. CreateSSDReq (28)

5.5.2. CreateSSDReqResponse (28)

5.5.3. DeleteSSDReq (28)

5.5.4. DeleteSSDReqResponse (28)

5.5.5. UpdateDomainKeyReq (29)

5.5.6. UpdateDomainKeyReqResponse (29)

5.5.7. DownloadApplicationReq (29)

5.5.8. DownloadApplicationReqResponse (30)

5.5.9. ApplicationAPDUReq (30)

5.5.10. ApplicationAPDUReqResponse (30)

5.5.11. DeleteApplicationReq (31)

5.5.12. DeleteApplicationReqResponse (31)

5.5.13. LockApplicationReq (31)

5.5.14. LockApplicationReqResponse (31)

5.5.15. AcquireTokenReq (32)

5.5.16. AcquireTokenReqResponse (32)

5 常见问题 (32)

1术语

2平台概况

2.1平台概述

NFC手机钱包是中国移动向各个应用合作方开放的一套完整的NFC业务端到端的解决方案，可以向应用合作方开放NFC手机终端非接式卡模拟能力、多应用管理平台（TSM）业务接口、NFC-SIM上的安全存储空间、和包客户端集成接口等NFC应用各个环节上所需的资源，帮助各个应用合作方根据自身业务流程开发出支持不同业务的NFC应用，并集成在中国移动NFC手机钱包这个大的业务平台中，统一向所有中国移动的用户进行推广。

本文档是用于对各应用合作方开发各自的NFC应用进行一个基础性的技术指引，明确产品开发的一个基本流程，提供开发过程中可能需要用到的各类技术文档的索引，并对开发过程中可能遇到的技术问题进行解答。

本文档适用于NFC手机钱包应用产品开发技术人员阅读

3开发范围

3.1应用模式

NFC应用包含几下几种模式，每次模式对应的开发范围也是不一样的，几种应用模式开发范围如下：

1、纯客户端模式

应用所有功能均直接由应用客户端实现，应用的相关数据没有安全存储要求，均可随客户端一起直接存储于手机的存储空间中。典型应用有：NFC名片应用。

2、客户端结合卡应用模式

应用的业务功能由应用客户端与NFC-SIM卡应用交互完成，应用中涉及用户敏感数据，需要将其存储在NFC-SIM的安全存储空间中，确保数据安全。典型应用有：简单公交卡应用（不支持空中开卡、空中充值）、旅游卡、电子门票等。

3、客户端、卡应用加业务平台模式

应用的业务功能由应用客户端与NFC-SIM卡应用、业务平台交互完成，客户端本地与NFC-SIM交互，实现应用数据在SIM卡上的安全存储，客户端远端通过移动互联网与业务平台交互，实现相应的业务功能。典型应用有：金融PBOC应用、公交卡应用（支持空中开卡、空中充值）。

3.2应用客户端

应用客户端开发包含应用客户端的界面交互设计、客户端业务处理逻辑以及对NFC-SIM 卡的访问逻辑。

3.3NFC-SIM卡应用

NFC-SIM卡上应用处理逻辑，包括卡应用文件结构定义与实现、卡应用与客户端交互指令的定义与实现、卡应用与非接受理机具交互指令的定义与实现。

3.4业务平台

实现NFC应用业务平台侧的相关处理功能，通过与TSM平台对接，可以由业务平台侧获取到用户手机号状态变更、业务订购关系变化等通知信息，以便进行相应的业务处理。

4开发流程

5流程说明

5.1应用流程

5.1.1下载

正常流程：

1、用户在和包客户端卡应用超市点击应用下载。

2、和包客户端向多应用开放平台发送应用下载请求。

3、多应用开放平台向业务平台发起“预操作请求”（SessionType为1）。

4、业务平台审核用户下载请求，如果审核通过返回0000；否则返回错误码和错误信息，

预处理响应中ProviderSessionID字段不能为空，该值由业务平台生成并保证唯一性。

5、多应用开放平台向和包客户端返回写卡指令。

6、和包客户端和多应用开放平台多次交互完成辅助安全域创建、辅助安全域初始密钥

加载、SE应用下载、安装。

7、多应用开放平台向业务平台发起“SE操作反馈请求”，SessionID与“预操作响应”

的ProviderSessionID一致。

8、业务平台返回结果。

9、下载应用客户端插件。

10、和包客户端主界面显示新下载的应用图片。

11、用户点击卡片图片启动客户端插件。

12、用户在客户端插件中申请卡片。

13、客户端插件向银行后台发送用户申请请求。

14、通知用户申请通过。

15、用户再次进入客户端插件。

16、客户端插件从银行获取个人化数据对应用进行个人化。

17、完成应用下载。

说明：

1、如果辅助安全域在SIM卡上已经存在，不会重复创建辅助安全域

5.1.2删除

1、用户在客户端插件中发起注销卡请求。

2、银行业务平台处理用户注销卡请求，并通过客户端插件处理卡上余额。

3、用户在和包客户端应用管理界面请求删除应用。

4、和包客户端向多应用开放平台发送应用删除请求。

5、多应用开放平台向业务平台发起“预操作请求”（SessionType为2，SessionID为新

生成）。

6、业务平台审核用户下载请求，如果审核通过返回0000；否则返回错误码和错误信息，

预处理响应中ProviderSessionID字段不能为空，该值由业务平台生成并保证唯一性。

7、多应用开放平台向和包客户端返回写卡指令。

8、和包客户端和多应用开放平台多次交互完成SE应用删除。

9、多应用开放平台向业务平台发起“SE操作反馈请求”，SessionID与“预操作响应”

的ProviderSessionID一致。

10、业务平台返回结果

11、和包客户端删除应用的客户端

12、应用删除完成

说明：

1、用户卡片个人化后未进行注销操作，银行业务平台应该在“预操作请求”时返回错

误信息提示用户先进行注销，避免卡上有余额造成用户损失。

2、完成应用删除后如果辅助安全域中没有其他应用，将会删除该辅助安全域。

5.1.3应用更新

1、用户在手机钱包客户端主界面请求更新应用。

2、手机钱包客户端向多应用开放平台发送应用更新请求。

3、多应用开放平台向业务平台发起“预操作请求”（SessionType为3，SessionID为新

生成）。

4、业务平台审核用户下载请求，如果审核通过返回0000；否则返回错误码和错误信息，

预处理响应中ProviderSessionID字段不能为空，该值由业务平台生成并保证唯一性。

5、多应用开放平台向手机钱包客户端返回写卡指令。

6、手机钱包客户端和多应用开放平台多次交互完成SE应用更新。

7、多应用开放平台向业务平台发起“SE操作反馈请求”，SessionID与“预操作响应”

的ProviderSessionID一致。

8、业务平台返回结果，如果需要进行个人化，响应报文中含个人化数据

9、如果业务平台响应报文中不含个人化数据，跳到15，否则。

10、多应用开放平台向手机钱包客户端返回个人化指令。

11、手机钱包客户端依次向SE发送个人化APDU指令，直到所有APDU执行完毕，

或卡片返回错误（SW不为9000）。

12、手机钱包客户端向多应用开放平台返回最后一条APDU执行结果。

13、多应用开放平台向业务平台发起“SE操作反馈请求”，SessionID与“预操作请求”

时一直，通过CardPOR发送最后一条APDU执行结果。

14、重复9到13步直到个人化过程完成。

15、多应用开放平台向手机钱包客户端返回结果。

16、应用更新完成。

异常处理

1、第4步时，业务平台对本次更新请求审核不通过，向用户提示业务平台返回的错误

信息，流程结束。

2、第5-6步过程中出现异常，用户可以在手机钱包主界面重新请求更新应用，重新更

新应用时会再次向业务平台发起“预操作请求”。

3、卡片执行个人化指令时，指令执行的结果通过“SE操作反馈请求”发送给业务平台，

由业务平台判断当指令执行状态字（SW）不为9000时是否继续执行。

4、第7-14步过程中发生错误，用户可以在手机钱包主界面对该应用进行删除操作，或

在应用超市界面重新下载该应用。用户在应用超市重新下载改应用时，多应用平台

会重新发起预处理请求，然后删除实例并重新创建，再重新执行7-14步的流程。6卡应用开发指南

6.1卡应用开发模式

●移植模式

如果卡应用之前已经在IC卡上实现，那么只需要将原卡应用的文件结构，指令定义提交给NFC-SIM卡的卡商，便可由卡商协助完成卡应用的移植工作。

●委托开发模式

如果卡应用需全新开发，可以将卡应用的需求描述清楚，委托NFC-SIM卡的卡商进行开

发。因为卡应用开发需要对卡片有一定了解，具有较强的专业性，建议采用委托卡商开发的模式来完成卡应用开发。现阶段，各家卡商为了推广卡片，提升市场占有率，一般会比较积极的接收开发需求。

6.2卡应用开发要求

1、空间要求：

金融类卡应用对RAM空间占用不超过1.5K，其他卡应用对RAM空间占用不超0.5K。

2、卡应用返回码要求：

除61xx - 6Fxx & 9xxx外的返回码都是非法的状态字，可能会对卡片产生影响，卡应用需严格控制。

6.3密钥交换流程

如果卡应用有申请独立的辅助安全域，则需要对辅助安全域的初始密钥者约定，密钥约定有两种操作模式，一种是由应用合作方提供初始密钥，将密钥码单通过密码信封提供给电子商务基地，另一种是电子商务基地生成初始密钥，并将密钥码单通过密码信封提供给应用合作方。

6.4卡应用开发

一个典型的Java Card设备有一个8或16位的运行在3.7MHz的中央处理器，带有1K 的RAM和多于16K的非易失性存储器(可编程只读存储器或者闪存）。高性能的智能卡带有单独的处理器和加密芯片，以及用于加密的内存，并且有一些还带有32位的中央处理器。

Java Card技术规范目前是2.2版，由三部分组成：

1.Java Card虚拟机规范，定义了用于智能卡的Java程序语言的一个子集和虚拟

机。

2.Java Card运行时环境规范，进一步定义了用于基于Java的智能卡的运行期行

为。

3.Java Card应用编程接口规范，定义了用于智能卡应用程序核心框架和扩展Java

程序包和类。

6.4.1JavaCard开发教程之程序元素

完整的Java Card应用程序由一个后端应用程序和系统、一个主机（卡外）应用程序、一个接口设备（读卡器）和卡上小应用程序、用户证书和支持软件组成。所有的这些元素共同组成一个安全的端到端应用程序：