校园卡管理系统论文：一卡通安全探讨.doc

一卡通安全探讨 如果没有特别的说明，本文所说的“一卡通”都是北京市政交通一卡通有限公司发行的“市政交通一卡通”。 简单来说，“一卡通”就是符合 ISO14443 Type A 标准的非接触式 IC 卡，在《北京市政交通一卡通卡在轨道交通自动售检票系统中应用的技术规定（暂行）》（下载链接要把 .RAR 修改成为 .rar，此文档为公开文档，本人从互联网下载得到）中说明为： 一卡通卡规格应符合 ISO/IEC14443 TYPE A 标准和DB11/T159.1-2002 标准(《市政交通一卡通技术标准 第1部分：卡片》)。一卡通卡芯片包括 Mifare? 1（S50、S70）、Mifare? Pro、Mifare? DESFire等。 目前在北京市范围内广泛使用的是 Mifare S70 卡。由于在 2008 年麻省理工大学的学生已经成功破解 Mifare 卡，能够完成对 Mifare 卡的读取，并“克隆”Mifare 卡。相关的资料已经在 DEFCON 上公开了。同样，荷兰的地铁电子票也遭破解。从某种渠道获得的消息称，北京“一卡通”也已经遭受类似的攻击。正因为这样的原因，有消息称“公交一卡通明年升级为 CPU 卡”。 不过个人认为这样的升级将非常困难 —— 如果升级后的系统不兼容旧的存在安全问题的“一卡通”，这就必然会要求所有“一卡通”持有者进行卡片的更换，这样的成本由谁支出？“一卡通”持有者必然不愿意，并且会有较大的反对意见，而这样的成本肯定也是“一卡通”的发行公司京市政交通一卡通有限公司无法承担的。如果兼容旧的存在安全问题的“一卡通”，那相当于整个系统中的安全漏洞并没有得到修补。 目前“一卡通”除了能够作为城市交通工具上作为电子票使用以外，还能在一些商铺进行小额的消费。由于“一卡通”中保存有金额等信息，因此如果攻击者能够对数据进行修改或者复制卡片，这将意味着可以使用“一卡通”进行免费乘坐交通工具或者到相关商铺进行免费的消费。除了升级卡片之外，还有什么办法能够降低“一卡通”系统被破解带来的损失呢？我认为可以通过以下几点来实现： 第一：对“一卡通”消费情况进行日结。这里说的“日结”就是每天完成对当天的“一卡通”消费情况进行统计、结算和分析。 第二：对“一卡通”的帐号收支情况进行分析，通过财务分析发现收支异常的“一卡通”帐号。 第三：对“一卡通”的消费记录结合地理信息进行分析。例如，同一张“一卡通”在很短时间内在相聚很远的物理地点进行消费。 第四：调整“一卡通”交易程序，要求所有的交易设备在每天初始化时从“一卡通”发行公司获取异常卡清单，一旦发现异常卡停止交易，并立即进行告警。 第五：限制“一卡通”的消费金额，使其仅限于小额消费。 除此之外，还要说些题外话，在《北京市政交通一卡通卡在轨道交通自动售检票系统中应用的技术规定（暂行）》能够看到“一卡通”系统同时支持记名和非记名卡。目前，我们大家使用的都是非记名的“一卡通”，如果某天推出了记名可挂失的“一卡通”，一定要想清楚自己是不是要申请。如果申请了记名可挂失的“一卡通”，就意味着你把自己的几点坐车到哪的隐私拱手送人 …… Posted in I.T.. 4 comments By sbilly – 2009/02/26 4 Responses Stay in touch with the conversation, subscribe to the RSS feed for comments on this post. kxlzx says 我说一些关于一卡通破解的设想。站在软件工程师的角度，思考每次我们刷卡的流程实现。首先，刷卡只能扣钱，不能加钱，加钱这个接口，要在地铁站实现。公交车上的刷卡机是可以调整数额的，很明显，他不能在金额里面加“负号”。而刷卡是否可以实时更新数据库呢？答案肯定是否定的，很明显，上海的一卡通刷卡的频率太高，我比较怀疑哪些数据库集群和网络通道（延时？）能满足这样恐怖的需求。再考虑到成本问题，我认为他们应该是每天回去后，才找时间更新数据库的，但是具体是什么时候，我就不清楚了。那么为什么我们看到的数额总在变化呢？那是因为卡内也有个“可以修改数额的”值。 如何破解呢？1，卡内金额变动我们可以盗取公交车上的刷卡机，破解，其实不用完全破解，只要在里面加一个“负号”的按钮即可。。。这种情况仅仅允许我们去即时的修改，可能会遇到一些情况，比如在地铁站里刷卡的时候“有可能”会遇到刷卡机已经同步的情况。从实用的角度上讲，我们的使用范围，仅仅是在刷卡设备没有联网的情况下。甚至我们可能会遇到以下情况，去地铁站刷卡，卡机有和“黑名单”系统，报警。即使不报警，当刷卡设备的数据更新了，我们再去刷，会出问题。所以，我比较怀疑破解的卡到底能刷多少次，会不会当场被抓。