试论《轨道交通联网收费系统标准》中特有安全算法的弱点

一、资料来源

1 北京市质监局公示过的《轨道交通联网收费系统标准》

从政府网站 北京市质监局可以下载到包含该文件的压缩包。

解压后，会得到12个文件，对应该标准对应的十二个章节。

2 《CJ/T166 建设事业IC卡应用技术》

从商业网站豆丁网处在线可看到。

二、签名算法

“系统内单程票卡的数据结构”完整定义了单程类票卡的系统实现，第六节详细定义了MAC算法，引用如下:

6  MAC计算

静态区（发行区）MAC在UID和OTP的序列号（serialNumber）字段的基础上进行计算的。

动态区MAC根据覆盖UID、CSN、静态区数据和动态区数据（A或B）计算的CRC生成。

静态区和动态区MAC使用不同的密钥。

MAC上不进行分散。

80FC指令将被用来认证静态区MAC，同时生成动态区MAC，这是在SAM中用一条指令实现的。

6.1 静态区MAC计算

注：由卡发行商完成。

为静态区MAC生成，从UID和CSN中计算8个输入字节（M0到M7），如下所示：

• M1[0] = UID[0] ^ UID[6]

• M1[1] = UID[1] ^ UID[5]

• M1[2] = UID[2] ^ UID[4]

• M1[3] = UID[3]

• M1[4] = CSN[0]

• M1[5] = CSN[1]

• M1[6] = CSN[2]

• M1[7] = CSN[3]

• 使用这些作为MAC生成函数使用的输入，将返回一个MAC。

6.2 动态区MAC计算

动态区MAC计算方法如下：

首先，先利用CRC-32算法计算一个校验和。该校验和将覆盖UID，CSN，静态区和本MAC所在的动态区。因此，如果静态区进行更新，动态区A和B都必须重新计算他们的MAC。这只会发生在卡发行或者重新发行时，不是在闸机商，所以不会对闸机的速度产生影响。

MAC校验函数的输入为：

• M1[0] = UID[0] ^ UID[6]

• M1[1] = UID[1] ^ UID[5]

• M1[2] = UID[2] ^ UID[4]

• M1[3] = UID[3]

• M1[4] = CSN[0]

• M1[5] = CSN[1]

• M1[6] = CSN[2]

• M1[7] = CSN[3]

• M1 [8]  = StaticAreaMAC>>24

• M1 [9] = StaticAreaMAC>>16

• M1 [10] = StaticAreaMAC>>8

• M1 [11] = StaticAreaMAC

• M1 [12] = crc>>24

• M1 [13] = crc>>16

• M1 [14] = crc>>8

• M1 [15] =  crc

• M1 [16] = M1[12] ^ M1[13] ^ M1[14] ^ M1[15]

M1数据作为80FC命令的一部分送往SAM。如果静态区MAC有效，这可以同时生成5个ID（每个6字节）。

使用这30个字节作为一个240bit的数组（m[0]到m[239]），一个12bit的MAC生成如下：

Where:

A[x] and B holds 12 bit values.

 

A[0]=m[0]|m[1].....m[11] that is 12bits.

A[1]=m[12]|m[13].....m[23] that is 12bits

.........

A[20]=m[227]|m[228]....m[239] that is 12bits

 

so B=A[0]^A[1]...A[20]; that is 12bits.

 

B is the resultant 12 bit MAC. 

如下图：

6.3 CRC-32算法

CRC-32是一个算法，其中使用一个多项式来计算一个CRC值，使用该值来发现进来的位流的错误。

算法的输出是32位长度。

算法的输入（消息）是一系列8位字符。

CRC-32算法使用的生成多项式是：

Polynomial = x32 + x26 + x23 +x22 + x16 + x12 + x11 + x10 +

                             x8+ x7 + x5 + x4 + x2 + x1 + x0

Polynomial = 0xEDB88320

开始值是0xFFFFFFFF。

三、违反标准

CRC32的算法是采用了ITU-T G.706-1991标准算法没有任何问题；

本标准中令人质疑的是其MAC生成算法：

先利用CRC-32算法计算一个校验和。该校验和将覆盖UID，CSN，静态区和本MAC所在的动态区。再校验和经处理后送入SAM卡，最终得到MAC值。或如下述简单表述：

原始数据->CRC32值->DES运算->MAC值。

事实上，《CJ/T166 建设事业IC卡应用技术》等国内外标准明确规定了MAC算法。原文如下：

9.3 安全报文传送

      安全报文传送的目的是保证数据的可靠性、完整性和对发送方的认证。数据完整性和对发送方的认证通过使用MAC来实现...........

............

9.3.2.4 MAC的计算

............

实现如下图所示：

可见北京市的《轨道交通联网收费系统标准》与既有包括《CJ/T166 建设事业IC卡应用技术》等国内外标准是冲突的，而且可以简单看出，其算法完全依赖于CRC的复杂（安全）程度，如果CRC可以被简单破解，则该算法的安全性也就不存在了。

四、算法分析

      对于CRC的逆算法，网络上已经比比皆是，我也设计一个简单算法，请同行斧正。

目标：待破解串为原始字串，破解串为篡改的字串。原始位串与篡改串长度一致，有若干位不一致，且均不位于队尾最后4字节，通过修改破解串最后4字节的值，使两串的CRC32值一致；

流式计算，从左至右开始：

1. 计算指针指向篡改串最左位；

2. 比较指向位与原始串的对应位，如相同，则指针后移1位；如不同，则需对篡改串从该位起异或CRC32特征字串（异或减）后，指针后移1位；

3. 重复步骤2；

4. 当指针指向篡改串倒数第32位时停止处理过程。

上述处理的结果，可以得到预期篡改串的倒数4节值，即可使破解串的CRC值等于原始串值。对于CRC8、CRC16等等，可以推出，破解串的倒数1、2字节等等进行同样过程的修改即可。　

上述算法简单扩展，破解串目标可以为篡改串中任何位置的连续4字节。

五、严重后果

      2010年7月公示的《轨道交通联网收费系统标准》，包含着大量的伪代码，作为地方标准是否过于琐碎旁人不好置喙，但其不厌其烦地精确定义了一个收费应用系统的卡片数据结构、数据字典、安全算法等技术的细节，达到工程详细设计的深度是毫无疑义的，结合本标准适用范围，很容易让人联想到这就是当初收费系统的设计文件。由于标准定义的安全算法已经被本文证明并非安全技术，这就意味着现在的运营系统存在着严重的安全隐患！该标准的公示，已经造成了泄密的事实，势必给既有的收费系统的运营带来极大的麻烦！

例如：下表为该标准对应用系统票卡的数据定义，加之标准前文描述的加密算法已经沦陷，这些内容加在一起，弱不禁风的该系统就充分曝光到了技术人员的面前。这些内容如果被恶意利用，该系统只有停用一条路了.....

7 票卡具体结构

      表10 定义了票卡具体结构，包括按位计算的每个数据字段的偏移量和长度..........

      事实上，2010年4月份，北京地铁收费系统已经被证实存在严重的安全漏洞，业主公司承认算法存在漏洞的同时，又声称只有参与工程建设的专业技术人员才有攻 击本系统的可能性，现有人员签有保密协议？（泄密将被追究法律责任）。因此漏洞危害性不大，不打算修改系统漏洞算法，继续维持运营下去。但是向上级部门保证未来将采用管理手段，确保系统运营安全——未来将加强技术保密手段，防止缺陷算法为外人所知：集成商将得不到北京地铁（漏洞）算法细节，只能采购内置该算法的读卡器安装于设备内实现票卡读写，而这种读卡器，由业主开发，因此算法不会外泄；至此系统漏洞将被堵住，系统运营也就安全了。至今，三年的宝贵时间就这样白白浪费掉了。为什么仅过了三个月，加密算法与票卡详细数据结构等“绝密”资料竟然堂而皇之地作为地方标准公布了呢？本技术标准的公布不啻引狼入室，业主公司化解算法危机的诸多努力化为乌有，政府主管部门及地铁运营商应该追究这起荒诞的泄密事故的人为责任。

六、难解之谜

      该标准中基于CRC32的签名算法“北京地铁算法”，甫一出场就打破工程规范，先工程应用，再成为地方标准，却从来没有进行过安全论证；而完全不同于国家标准的设计和近乎搞笑的防伪性能，更令内行大跌眼镜。“UL票卡的安全设计经过各方专家论证，综合考虑UL票卡的业务范围、读写器等硬件设备技术条件，对票卡读写时间要求等因素，为减少票卡处理时间提高乘客通行速度”的说辞只会遭致专家与同行业的不齿。探究其根本原因，林林总总都指向北京地铁联网收费系统工程管理方对承担系统集成的外国公司的设计资质与工程经验存在的监管盲点。

　　但是，标准的第六部分《用量数据定义》却又专业性十足：

10.3 MAC算法

     通过如下方式计算MAC：

1. 计算计算对帐XML文件全部内容的SHA－1散列。

2. 从上面第一步运用ISO/IEC 9797-1并通过DEA锁定密码, 填充方法1, MAC运算法则3及32 字节长MAC计算MAC。

MAC密钥将不被发散。

     通篇使用的均是专业/通行的主流安全技术：SHA-1是被国际认可的安全散列算法(可用于数字签名)；国内标准《CJ/T166 建设事业IC卡应用技术》指定的MAC算法更是直接引自ISO/IEC9797-1。一如该标准的其它章节，该章节也应是从设计方的工程文件中摘抄得来，能写出这份专业性极强的涉密技术标准的公司，肯定具备丰富的安全应用工程经验。但是，为什么在北京地铁联网收费工程中，同是一家外国公司，在单程票MAC算法的算法设计不简单使用上述其中一种加密技术，而是画蛇添足，重新设计一套算法呢？

     由此让人对《轨道交通联网收费系统标准》中单程票的MAC算法产生了认知回归——难道真是为“综合考虑读写器等硬件设备技术条件”，迁就北京地铁的过于老旧设备处理能力，设计方不得不采取的保障速度牺牲安全的无奈之举？那就让我们看看北京地铁的设备性能吧！北京系统零八年才开通，根本不存在太过老旧的可能，而在标准的第十二部分：《读写器硬件规定》中，找到了相关设备的性能描述，同时也将算法强度悬疑彻底推向了高潮：

7.3  微处理器指标

1. 32位ARM 9微处理器，工作频率不低于180MHz。

2. 数据总线至少支持16位、32位。

3. ...........................

     北京地铁联网收费工程采用了全国独一无二的TPU技术路线，设备与读卡装置分离，读卡装置由业主指定采购，采用TPU的设备已经占到系统总量的90%以上。从上述标准条目中可以简单看出：前端读卡装置中内置了计算能力强大的微处理器（超过2亿条整数指令/秒），即使全世界范围，未来数年时间恐怕都会是AFC系统装备最高性能的读卡装置处理器了。装备了最尖端水平硬件的北京联网收费系统，仍要“考虑读写器等硬件技术条件”，拒不采用国家标准的签名算法，这样的托辞太狗血了吧？反过来说，如此高端的处理器性能要求，却只用来处理如此简单的智能卡逻辑，诸多的性能浪费，这样的设备采购未免过于坑爹了吧？

      鉴于该算法为某外国公司绕过中华人民共和国国家标准，有意为之的设计；难不成是敌对势力为北京项目中设计的“棱镜算法”吧？