设万维读者为首页 万维读者网 -- 全球华人的精神家园 广告服务 联系我们 关于万维
 
首  页 新  闻 视  频 博  客 论  坛 分类广告 购  物
搜索>> 发表日志 控制面板 个人相册 给我留言
帮助 退出
回首百年的博客  
专业技术,主要研究收费系统.  
https://blog.creaders.net/u/6964/ > 复制 > 收藏本页
网络日志正文
从市质量监督局公布的一份标准中找寻BUG 2012-11-13 18:57:17

上 中华人民共和国北京市质监局很久前在其官网上公布了由北京市轨道交通建设管理有限公司、北京市轨道交通指挥中心、北京市地铁运营有限公司、北京航空航 天大学起草的北京市地方标准《轨道交通联网收费系统标准》征求意见稿,至今仍未撤除。 

北京市质监局征求意见

标准内容涵盖了北京地铁收费系统的主要技术实现方案。

下载附件内容

其中比较有意思的是其单程票的数据结构与安全算法。

算法描述

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

6  MAC计算

静态区(发行区)MACUIDOTP的序列号(serialNumber)字段的基础上进行计算的。

动态区MAC根据覆盖UIDCSN、静态区数据和动态区数据(AB)计算的CRC生成。

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

MAC上不进行分散。

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

6.1 静态区MAC计算

注:由卡发行商完成。

为静态区MAC生成,从UIDCSN中计算8个输入字节(M0M7),如下所示:

  • 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]),一个12bitMAC生成如下:

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. 


如下图:


<《轨道交通联网收费系统标准》征求意见稿 ——第2部分:卡数据定义>定义的票卡算法与结构


问题解析

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

本标准中令人质疑的是基于CRC的MAC生成算法可能达不到有效强度:

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

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

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

9.3 安全报文传送

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

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

9.3.2.4 MAC的计算

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

实现如下图所示:


 iso/iec7816-4关于MAC算法的图示定义

破解算法

      对于CRC32破解,网络上已经比比皆是,我也设计一个简单算法,请同行斧正。

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

流式计算,从左至右开始:

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

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

  3. 重复步骤2;

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

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

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


严重后果

      事实上,这个标准照搬了工程项目实施的设计文件,因此对于包括卡片数据结构等技术细节均有工程实现级别的定义(北京地铁收费系统的卡片就是照此格式化的),本标准编制的深度是否适宜旁人不好置喙,但和存在明显弱点的加密算法共同收录进同一份技术文献中,对该标准指导下的收费系统将是致命的威胁。该标准编制的非常失败,随着上述资料在互联网上的进一步为人所知,无疑将会发现该标准更多的问题。

      总而言之,该标准文本不仅偏离的标准编制的基本原则,内容规定厂商名称、技术限定产品型号等违规文字;随意创设与国家标准冲突、未经理论证明的新型加密技术,完全没有达到标准的基本业务水平;而且由于该标准脱胎于北京地铁收费系统工程设计文件,因此仅从本文的信息中就可完成对这个含有算法漏洞系统的攻击,故此该文件存在严重泄密的嫌疑(下图为标准中公布的系统票卡的最为重要的格式数据)。

7 票卡具体结构

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




浏览(786) (0) 评论(0)
发表评论
我的名片
回首百年
注册日期: 2012-11-14
访问总量: 7,820 次
点击查看我的个人资料
Calendar
最新发布
· 从市质量监督局公布的一份标准中
分类目录
【留痕】
【灭虫】
· 从市质量监督局公布的一份标准中
存档目录
2012-11-13 - 2012-11-13
 
关于本站 | 广告服务 | 联系我们 | 招聘信息 | 网站导航 | 隐私保护
Copyright (C) 1998-2024. CyberMedia Network /Creaders.NET. All Rights Reserved.