企业官网建设流程全解析

简介：这套资料面向金融级CPU卡终端开发人员与嵌入式学习者，围绕复旦FM1208 CPU卡和SmartCOS PSAM卡的双模发卡、圈存、消费与余额查询流程，给出可编译运行的Keil C51工程，并把PSAM安全认证、DES/MAC校验、RC522读卡、12864显示和串口调试整合到同一套代码框架中，便于在公交、校园、门禁等PBOC场景中直接验证与移植。压缩包共362个文件，约12.53MB，主要包括48个C源文件、49个头文件、9个hex固件、9个uvproj工程，以及61个lst/obj等编译中间产物，另有原理图、烧录软件和多种USB转串口驱动。包内按通信、加密、读卡、显示等模块组织工程，源码与工程配置相对完整，可减少从零搭建发卡、认证和联调环境的时间。文档体系覆盖FMCOS 2.0、SmartCOS-PSAM1.3、MF_RC522中文手册与PBOC央行规范系列指南，并包含FM1208发卡/应用、PSAM发卡/管理等实操说明。已有29人学习，适合想打通CPU卡发卡、圈存和终端联调全流程的开发者参考。

1. FM1208 CPU卡＋PSAM双模发卡与圈存系统：这套资料把最难啃的金融卡链路摊开了

做金融卡项目最打击人的不是不会写消费指令，而是发卡发到一半PSAM认证失败，整批卡推倒重来。FM1208 CPU卡+PSAM双模发卡与圈存系统这套资料，就是冲着这个痛点来的：它把卡片侧的SmartCOS源码、终端侧的RC522射频驱动，以及PBOC合规文档放在同一个项目框架里。你拿到这套资料能解决的问题很清楚——在公交、园区一卡通、小额支付这类场景里，自己搭起"发卡→圈存"的完整链路，而不是被各家的SDK牵着走。适合正在做终端固件、发卡工具、测试工装的开发者和集成商，也适合想搞懂PBOC指令流和安全机制的人当解剖样本。

2. 双模架构与PBOC合规基线：先把系统拆成卡片侧和终端侧

2.1 FM1208 与 PSAM 双模：谁在卡片里、谁在终端里

FM1208 是一颗支持接触式与非接触式双界面访问的 CPU 卡芯片，片内跑的是SmartCOS。CPU卡的"CPU"不是说它有通用处理器的性能，而是指它具备独立的操作系统、文件系统和安全存储能力，APDU 指令进来后由 COS 自己分发处理，不在外部主机里跑业务逻辑。PSAM 则是终端侧的安全存取模块，内部也有一颗安全芯片，存放参与交易认证的密钥。圈存交易里最关键的两个动作——计算报文鉴别码（MAC）和校验交易验证码（TAC）——都在 PSAM 内完成，密钥永远不落到终端主控的 RAM 里。

"双模"这个说法在实际项目里有两层含义。第一层是刷卡介质双模：FM1208 同时支持接触式（ISO 7816）和非接触式（ISO 14443A）两种访问方式，一张卡片既能插卡也能挥卡。第二层是系统角色双模：一套系统里同时管理 CPU 卡（持卡人的钱包）和 PSAM（终端的安全模块）。开发时你需要同时操作两个芯片，CPU 卡跑业务应用，PSAM 跑安全计算。我见过不少新人把精力全放在 CPU 卡指令上，结果 PSAM 侧报文格式没对齐，圈存怎么调都过不去。

这张表建议打印出来贴工位。调试时先判断问题出在哪个角色，再决定翻哪份资料。CPU卡侧的指令发错，SW 会直接报 6A86 或 6A88；PSAM 侧的报文拼错，通常表现为 MAC 校验失败，最终在 CPU 卡侧以一个 69 85 收场。

2.2 PBOC 合规文档在开发中的真实用途：对照协议而不是背标准

PBOC 全文很大，直接硬啃容易迷失在几百页的命令矩阵里。这套资料里把合规文档放进来，我认为最大的价值不是给你一本"标准原文"，而是让你开发时能对着协议查三个必须回答的问题：圈存是否强制校验 TAC；密钥分散用的是标准 3DES 还是国密算法；余额更新的时序到底由哪条命令触发。这三个问题在开发过程中一定会碰见：写卡片侧代码要查卡片规范，写终端 PSAM 调用要查终端规范，写发卡工具的密钥管理要查个人化规范。

要注意"合规文档"和"过认证"是两码事。有文档对照能让你在代码层面不出低级错误，但正式商用前仍然要把产品送到检测机构跑例行测试。我的建议是：把文档当成开发的边界条件，不要当成过检测的保证。做完一版之后，拿着测试报告再去翻文档里对应的条款，比一开始逐字啃效率高得多。

PBOC 文档里最容易看漏的是状态机和安全状态字节。指令在哪个安全状态允许执行、执行后安全状态如何迁移，这些在文档里通常分散在多个章节。遇到 SW 错误码时不要只盯着 9000 和 6A86，还要回文档确认当前安全状态是不是够了。比如未完成外部认证就发 PUT KEY，COS 会直接拒绝，这在日志里往往以 6982 出现。

2.3 密钥体系与安全域：PSAM 不出密钥的秘密

金融卡系统的安全核心是分层密钥。顶层是主密钥，通常保存在发卡方的硬件加密机里；向下通过分散算法，按应用序列号或卡号分散出卡片专有密钥和终端工作密钥。分散后，卡和终端拿到的密钥各不相同，即使某张卡被破解，也无法推导出主密钥。这套结构决定了你开发和测试时必须区分三类环境：生产密钥、测试密钥、样本密钥。生产密钥一旦灌入 PSAM，就不能拿来做随意测试，否则审计会对不上账。

圈存链路里的三次关键计算顺序是这样：卡片在初始化圈存时向终端返回一个随机数；终端把随机数交给 PSAM，PSAM 用工作密钥算出 MAC；卡片收到圈存提交指令，验证 MAC，正确后更新余额并返回 TAC，终端再用 PSAM 校 TAC。这个闭环里没有任何一个环节把明文密钥发到总线上，MAC 和 TAC 只是密钥参与计算的结果。你调试时如果发现 MAC 对不上，要先怀疑密钥版本号和分散参数，而不是去 PSAM 里找密钥。

// 伪代码：从主密钥分散出卡片密钥 // MK: 主密钥；cardData: 应用序列号；keyUsage: 用途标识 // 0x01 表示圈存密钥，0x02 表示消费密钥 key_card = DiversifyKey(MK, cardData, keyUsage)

逻辑上，分散参数必须两端一致。发卡工具里写的是卡号加序列号，PSAM 端也必须用同样的拼接顺序。我见过一个项目，发卡端用卡号前 8 位做分散，PSAM 却用后 8 位，结果每张卡圈存都失败。这类问题不看日志根本发现不了，因为单看任何一端都是对的。密钥版本号也容易被忽略：PUT KEY 时写入的版本号与 PSAM 密钥文件里的版本号不一致，MAC 计算用的密钥就是两把不同的钥匙，圈存提交必然被卡片拒绝。

3. 发卡端落地：SmartCOS 源码与最小发卡脚本

3.1 发卡流程拆解与 SmartCOS 源码模块映射

发卡流程基本是六步：复位应答、选择应用、建目录、建文件、写个人化数据、安装密钥并锁定卡片。每一步对应一组 APDU，发卡工具就是把这一串 APDU 按顺序发给 FM1208。SmartCOS 源码虽然是 COS 内部的代码，但你不需要从第一行读到最后一行才能用。我一般会建议从 APDU 分发入口进入，找到每个 CLA/INS 对应的处理分支。比如 SELECT 命令的 INS 是 0xA4，在源码里搜 case 0xA4 就能定位到文件选择逻辑；搜 0xD8 找密钥写入逻辑。剩下的大头是文件系统模块，负责把外部传来的文件结构和权限翻译成内部存储布局。

这个"对着指令找代码"的过程本身就是最快的上手路径。COS 源码里最难读的部分不是指令分发，而是安全状态机如何工作：安全状态由当前密钥验证情况决定，比如只有通过外部认证之后，安全状态才允许执行 PUT KEY。这部分逻辑分散在多个头文件里，读的时候把宏定义和状态位抄在一张纸上，比在编辑器里来回跳效率高。

// 简单示意：COS 的 APDU 分发入口关键分支 // 实际 SmartCOS 源码中的分发函数比这个复杂，但结构类似 sw = processAPDU(&apdu); switch (apdu.ins) { case 0xA4: // SELECT：切换当前应用/文件 sw = doSelect(&apdu); break; case 0xE0: // CREATE FILE：建立文件系统结构 sw = doCreateFile(&apdu); break; case 0xD8: // PUT KEY：写入/替换密钥，通常要求已认证 sw = doPutKey(&apdu); break; case 0xDC: // UPDATE RECORD：写交易记录 sw = doUpdateRecord(&apdu); break; default: sw = SW_INS_NOT_SUPPORTED; }

这里的 0xA4、0xE0、0xD8、0xDC 都是智能卡领域最常用的指令字节，有经验的人一眼就能对上。你把资料里的源码编译进模拟器，或者直接用调试器单步，就能看到每个分支的返回值。调试器看不到 COS 内部状态机时，就用 SW 反推：6982 说明没认证，6A86 说明参数不对，6985 说明当前命令不被允许。

3.2 个人化 APDU 序列与参数说明

发卡这个动作本质上就是一串 APDU。生产环境里个人化工具通常由卡片厂商提供，但理解这串 APDU 的先后顺序，是排查发卡问题的基本功。下面这个序列是典型的最小个人化顺序，注意靠前的命令都是为靠后的命令准备存储空间和安全条件。

关于先建文件还是先写密钥这个问题，不同的 COS 有不同定义。SmartCOS 一般是先建文件后灌密钥，因为 PUT KEY 要写在安全域里，而安全域本身先要由 CREATE FILE 建出来。如果反过来做，密钥数据会落进未分配的空间，COS 找不到引用，后续圈存时卡片直接查无此密钥。这个顺序问题是我在实际开发中改得最多的一处，而且它不会以编译错误的形式暴露，只在交易阶段才报错。

参数上，P1P2 是文件类型和访问权限的组合位。以 CREATE FILE 为例，P1 指定创建位置和文件类型，P2 则是权限字节。密钥版本号在 PUT KEY 与后续交易指令里必须完全一致，否则 PSAM 侧算出的 MAC 和卡片侧预期的 MAC 不同——这是发卡后圈存失败的第一大原因。算法标识同理，卡片写入了 3DES 的密钥，PSAM 用 SM4 的密钥算 MAC，两边永远对不上。

3.3 最小可跑通的发卡脚本（Python）

下面这段脚本用 pyscard 直接和读卡器里的 FM1208 通信。生产环境不要用这种裸脚本，但它非常适合用来说明一条发卡主链路上发生了什么。跑之前确认读卡器驱动装好，卡片已经上电并返回了 ATR。

# 最小发卡示例：选择应用 -> 读钱包余额 -> 写初始余额（示意） # 依赖：pyscard；读卡器需支持 ISO 7816 T=0 或 T=1 from smartcard.System import readers from smartcard.util import toBytes # 获取第一个读卡器并建立连接 r = readers()[0] conn = r.createConnection() conn.connect() def cmd(cla, ins, p1, p2, data, le=None): # 手动拼 APDU 字节流：CLA INS P1 P2 Lc DATA Le apdu = [cla, ins, p1, p2, len(data)] + list(data) if le is not None: apdu.append(le) resp, sw1, sw2 = conn.transmit(apdu) return resp, sw1, sw2 # 1. 选择应用，AID 这里用一个通用测试值示意 aid = toBytes("A0 00 00 00 03 00 00 00") resp, sw1, sw2 = cmd(0x00, 0xA4, 0x04, 0x00, aid) print("SELECT:", f"{sw1:02x}{sw2:02x}") # 2. 读钱包余额，PBOC 钱包余额读取一般是 80 5C resp, sw1, sw2 = cmd(0x80, 0x5C, 0x00, 0x00, [], 0x04) print("BALANCE:", bytes(resp).hex(), f"{sw1:02x}{sw2:02x}") # 3. 写初始余额到新发卡片，UPDATE RECORD 的 INS 是 0xDC # 这里演示用，真实个人化通常走现金充值或圈存指令留日志 bal = [0x00, 0x00, 0x00, 0x64] # 初始 0.64 元，低字节在前 resp, sw1, sw2 = cmd(0x00, 0xDC, 0x01, 0x00, bal) print("UPDATE:", f"{sw1:02x}{sw2:02x}")

代码里的关键点在 SELECT 之后的 AID 必须和 COS 里预置的应用标识一致，否则后续 80 5C 会返回 6A82。80 5C 的 Le 固定是 4 字节，多传或少传都会报参数错。UPDATE RECORD 的 P1 是记录号，P2 是记录类型，0x00 表示定长记录，如果原来文件建的是变长记录，这里就要换成 0x04 这类值。

提示：如果你手上的发卡工具是现成的，个人化顺序通常已经写死，不需要改；真正要盯的是密钥版本、分散参数和算法标识这三个配置项。

这套最小脚本最大的作用不是替代发卡工具，而是帮你验证读卡链路、APDU 封装和 COS 基本响应是否正常。把脚本里的断言加上，比如 SELECT 后强校验 SW，发卡工具调试会清晰很多。

4. 圈存链路：PSAM 安全认证与圈存指令调试

4.1 圈存交易拆解：从余额读到 TAC 校验

圈存本质是一个"钱包充值"动作，但绝不能简单理解成写文件。PBOC 电子钱包的圈存由两条指令组成：初始化圈存（INITIALIZE FOR LOAD）和圈存提交（CREDIT FOR LOAD）。终端先读卡内余额，再发初始化圈存，卡片返回一个伪随机数和密钥相关信息；终端把伪随机数交给 PSAM 计算 MAC；最后发圈存提交指令，携带金额和 MAC，卡片验证后更新余额并返回 TAC。

这个流程里最关键的一点：卡片并不信任终端传过来的金额，它信任的是 MAC。伪造一个终端去充值，因为算不出合法 MAC，卡片会直接拒绝。这就是为什么圈存必须依赖 PSAM——密钥不出现在终端主控里，而是只在 PSAM 内部参与运算。

调试圈存时，我习惯先在草稿纸上把数据流画出来，不急着连设备。从读余额开始，到初始化圈存拿到挑战，再到 PSAM 算 MAC，最后圈存提交，每一步的输入输出都要写在纸面上。这么做看似麻烦，但能拦截大量低级错误，比如金额字节序搞反、挑战长度不对这类问题，在纸上就能发现。

4.2 PSAM 侧 MAC 计算与指令封装

PSAM 也是一张装在读卡器里的 CPU 卡，通常通过终端主控的 ISO 7816 接口访问。向 PSAM 取 MAC 的标准方法是用内部认证指令，把卡片返回的伪随机数连同交易数据作为输入，PSAM 返回计算出的 MAC。

// 圈存时向 PSAM 请求计算 MAC（示意实现） // 依赖：psam_transmit() 由底层驱动提供，与 CPU 卡共用一个 7816 驱动 uint8_t mac_in[8], frame[32], mac_out[8], sw[2]; // 输入拼接：卡片挑战 + 交易金额（低字节在前） // 具体顺序以 PSAM 开发手册定义为准 memcpy(frame + 0, mac_in, sizeof(mac_in)); // 组装 APDU：CLA=0x00, INS=0x88, P1=0x00, P2=0x00 frame[0] = 0x00; // CLA frame[1] = 0x88; // INS: INTERNAL AUTHENTICATE frame[2] = 0x00; // P1，部分 PSAM 用此索引密钥 frame[3] = 0x00; // P2 frame[4] = 0x08; // Lc: 输入 8 字节 // 发送给 PSAM，Le 设为 8，期望 8 字节 MAC uint16_t len = psam_transmit(frame, 5 + 8, mac_out, 8, sw); if (sw[0] == 0x90 && sw[1] == 0x00) { // 拿到 8 字节 MAC，拼进圈存提交指令的 data 字段 build_credit_load_cmd(mac_out); } else { // 记录 SW，大多数情况是密钥版本不匹配或 PSAM 应用未选对 log_sw("PSAM MAC error", sw[0], sw[1]); }

0x88 内部认证的输入和输出长度，不同 PSAM 的 COS 可能要求不同，建议看 PSAM 的开发手册按实际定义调。这里要强调的是 MAC 输入拼接顺序：卡号、金额、伪随机数、交易计数器，少一个字段卡片都会拒收。拼接顺序不对是最隐蔽的问题，因为两端都叫"金额"，但字节序或字段位置不同就全盘皆输。

参数上，P1 在部分 PSAM 里用于指定密钥索引，比如 0x01 表示圈存密钥、0x02 表示消费密钥。如果 0x88 返回 6A86，先看是不是 P1 没设密钥索引。另外，PSAM 在取 MAC 之前一般要先 SELECT 到对应的安全应用，没有这一步，后续指令会被 PSAM 直接拒绝。SELECT 的 AID 在 PSAM 初始化时由灌装方写入，这个值也常见于发卡配置文件里，别写成 CPU 卡的 AID。

4.3 全链路调试命令与日志要点

手工调圈存时，我通常在一个串口终端里把整个过程打出来，留下足够日志。关键日志点有四个：每次指令的完整 APDU 和响应字节；MAC 的前 4 字节，用于后续比对；圈存前后余额快照；9000 之外的 SW 码。日志格式统一成一行一个事务，比一堆散落的 print 好用得多。

# 手工验证圈存最小序列（串口交互示意） # 具体字节以 SmartCOS 资料中的钱包应用定义为准 => 00 A4 04 00 08 A0 00 00 00 03 00 00 00 <= 90 00 => 80 5C 00 00 04 <= 00 00 00 00 90 00 => 80 50 00 00 08 <金额+随机数请求> <= <卡片挑战> 90 00 => 80 54 00 00 0D <金额+MAC> 06 00 <= <TAC> 90 00 => 80 5C 00 00 04 <= <新余额> 90 00

这里的 80 50 的 P1 表示圈存类型、P2 通常为 0，8 字节数据是终端挑战加金额；80 54 的 Le 设为 6 字节，期望卡片返回 TAC。不同 COS 对 P1P2 的定义可能有差异，以你手里的资料为准。排错时有一个血泪经验：如果 80 50 返回 9000、80 54 返回 6985（安全状态不满足），先检查 PSAM 算出的 MAC 长度是不是 8，再检查拼接时金额的字节序。MAC 是黑匣子，肉眼看不出来，只能逐一核对输入。

日志落盘也值得做。调通之后把成功交易的日志保存为基线，后续任何代码改动导致圈存回归，直接 diff 日志就能定位是卡片响应变了还是终端组包变了。这个习惯让团队少走了很多弯路。

5. 避坑与常见问题排查：从发卡到圈存的五个翻车点

5.1 发卡翻车：先装密钥后建文件，整批卡作废

现象：发卡工具跑完 CREATE FILE 和 PUT KEY，圈存时卡返回 6A88，意思是引用数据未找到。

原因：有些发卡模板把 PUT KEY 放在 CREATE FILE 之前，密钥被写进尚未分配的安全域，COS 找不到对应引用。SmartCOS 对安全域的初始化时机敏感，必须先建文件（包括安全域文件）再灌密钥。

解决：把发卡模板里 CREATE FILE 提到 PUT KEY 前面，并且确认每个密钥对应的文件 ID 先创建。另外，同一批次卡片尽量用同一套发卡脚本，不要中途改模板，否则容易出现一批卡顺序不同，排查时根本无法对比。

5.2 玄学科目：同样指令换台读卡器就 69 85

现象：同一个圈存脚本在一台读卡器上通过，换到另一台读卡器上 80 54 返回 6985，安全状态不满足。

原因：两台读卡器和 PSAM 之间的 7816 时序参数不同，MAC 计算时输入的过程字节不同，导致 MAC 校验失败。这类问题表面看是加密问题，实际是物理层问题。

解决：对比两台读卡器的 ATR 和协商参数，把 PSAM 的通信参数固定到一致，再重算 MAC。不要一上来就怀疑密钥，先确认两台设备对 PSAM 的 PPS 协商结果一致。

5.3 PSAM 没插稳，圈存一直报"安全模块不可用"

现象：终端初始化 PSAM 时设备返回错误，后续圈存指令全部失败，日志里只有一句"安全模块不可用"。

原因：PSAM 卡座接触不良是最常见的。另一个容易被忽略的是——PSAM 的 ATR 里带了历史字节，主控解析 ATR 失败后直接放弃整个模块。

解决：加一个启动自检：上电后读取 PSAM ATR，能正确解析再进主流程；解析失败则主动复位并重试两次。这个自检代码值得写，批量上线后能省大量现场排查时间。卡座选型也很重要，锁卡式卡座比抽屉式卡座更适合频繁插拔的终端。

5.4 RC522 读 FM1208 非接触面，卡在 PCD 层

现象：RC522 能读到 MIFARE 卡，但放上 FM1208 CPU 卡后连 ATS 都拿不到，寻卡阶段直接超时。

原因：FM1208 非接触面走 ISO 14443-4 协议，RC522 默认的 MIFARE 兼容模式不会自动进入 ISO 14443-4 会话。很多 RC522 驱动只封装了 MIFARE 的读块写块接口，对 CPU 卡只做了到 Select 就停。

解决：在 RC522 驱动里加 RATS 命令的封装，发送 0xE0 请求 ATS，再根据 ATS 里的参数解析帧格式。做完这一层，CPU 卡才能在非接触面上走 APDU 流程，后面 80 50、80 54 才能到达 COS。

5.5 防碰撞重试导致圈存超时

现象：多张卡同时靠近读卡器，圈存脚本连续重试还是超时，终端直接报错退出。

原因：RC522 的防碰撞循环默认重试次数不足，或每次重试都重新走完整防碰撞流程，耗时太长。圈存流程里 PSAM 会话有时限，防碰撞耗时过长导致 PSAM 侧会话过期，卡片和终端状态就错位了。

解决：把防碰撞重试次数调低到三次以内，重试之间清掉 FIFO 和错误寄存器。同时在圈存进行时临时关闭二次寻卡，防止有其他卡片插入打断当前交易。这个改动在批量终端上效果明显，能显著降低高峰期的失败率。

6. 从最小系统到批量发卡：验证技巧与检查习惯

6.1 用一张测试卡跑通圈存闭环

我的验证习惯是：准备一张专用测试卡，发卡时写入一个可识别的测试标识，然后按"读余额→圈存→再读余额→再圈存一笔"的方式走通闭环。关键是每步都保持日志：把余额、MAC 前 4 字节、SW 一起打出来。如果圈存后余额没变，就回看 MAC 的输入拼接和密钥版本，这是成本最低的排错路径。测试卡上不要放真实余额或重要数据，只当作验证通路。

6.2 批量发卡前的三个检查习惯

批量发卡前，我会先做三个固定检查：第一，确认 PSAM 里灌的密钥版本和发卡工具配置一致；第二，抽样两张卡做完整圈存闭环，而不是只测到发卡成功；第三，留一张"坏卡"专门验证拒绝路径——比如故意算错 MAC，确认卡片真的会拒绝。这样上线后出问题的概率小很多。

最早做这类项目时，我也跳过验证直接上批量，结果用错密钥版本发了一批卡，返工成本很高。后来养成了测试卡专用、日志快照留底的习惯，组里的同事也照这个套路走。希望帮到你。

本文还有配套的精品资源，点击获取