0
关注
36782
浏览

IC卡的钱是装在卡里还是装在服务器里?

为什么被折叠? 0 个回复被折叠
北极 核心会员 用户来自于: 北京市
2026-01-12 17:11
题主说的钱,我理解为就是余额,所以我认为题主问的就是卡余额是保存在什么地方。 卡余额可能保存在卡里,也可能保存在服务器上,具体情况是两种都有。 1. 余额只保存在卡内 应用范围:磁条银行卡在过去曾经广泛使用,现在几乎没有。 这种方式安全性很差,但出现的最早,因为过去的时候网络实时验证还很不成熟,只好把余额数字放到卡里(小说《白夜行》里有类似的记述,直接克隆卡,修改卡余额就能取钱),这种模式对账周期一般比较长(可能是以月甚至更长时间计算),因为安全性的问题已经基本淘汰。 卡会长期放在用户手里,很难保证不被破解,再强大的算法也无法保证长时间的可靠性,而且由于计算能力的不断提升,任何早期的算法放到今天都是不一定可靠的。尤其是磁性卡片,被破解基本上是时间问题。 虽然目前CPU卡已经十分安全,但也不能保证未来5-10年这种技术仍然是可靠的。而且老卡的淘汰也需要一段时间。 2. 余额只保存在服务器上,卡只作为身份标识 应用范围:几乎全部的银行卡(磁条卡)、电话卡,大部分的校园卡、饭卡。 银行卡里面是没有余额的,甚至连密码都没有保存,很多银行卡里保存的都是卡的信息(其实就是卡号),ATM机或者POS机在刷卡时读取卡号,等待用户密码,然后把这些都打包给服务器去验证。 所以ATM机和POS机都是需要联网的。有人说POS机可以不联网,那是因为POS机里内置了一个SIM卡,通过类似手机上网的功能完成拨号、发送、接受数据的操作。 校园卡、饭卡也是类似的,这些卡的刷卡终端大部分都需要联网,见过很多学校的食堂因为网络故障导致无法刷卡的。 这种方式的好处就是很安全,卡内的信息就算是被破解了也无法修改账户余额,缺点就是无法离线使用,而且要查询余额也很麻烦。 3. 余额同时保存在服务器和卡内 应用范围:大部分公交卡,部分校园卡、饭卡、IC卡电子钱包等。 公交卡里是有余额的,比如题主贴出的北京公交卡,公交卡与其它卡片不同的地方是刷卡的反应速度需要很快,如果公交卡要联网验证,那么速度就太慢了,所以公交卡里必须要有余额以保证快速刷卡。 但这样做安全性就有问题了,所以当公交卡的刷卡终端是有线网络时,实时联网验证,并同步一下余额是否正确,如果刷卡终端是离线的,则把刷卡信息同时保存在卡里和刷卡终端上,刷卡终端每天晚上结算的时候联网统一结算。 所以,对于北京的公交卡来说: 如果是在超市内刷卡结账,这些结算都是实时与服务器验证的,如果发现余额异常,则刷卡会失败。 如果是在公交卡上刷卡,结算是非实时的,换句话说,如果伪造、篡改公交卡里的余额,当天坐公交车是没有问题的,并且由于公交车结算时间是每天晚上收车以后,在结算之前,伪造的余额是不会被发现的,但结算以后可能会被人发现。 刷地铁是否是实时结算还不清楚,可能是实时结算的,其它的应用场景如用IC卡打电话是否是实时计算也不是太清楚,有了解情况的可以来说说。 也就是说显示的余额确实是卡里的,但交易过程如果是联网的,那么会二次验证余额。 有一个方法可以比较简单的验证公交卡是否是实时交易:大部分城市的公交卡都能在网上查询实时余额(至少北京的支持),刷一次公交卡,到网上查询一下,如果记录能对的上,那么交易是实时的,如果记录对不上,交易则不是实时的。 --------------------------------------------------------------------------------------------------------- 当然了,别以为通过服务器验证就是安全的: 服务器漏洞被入侵,卡内被非法充值:奇虎360员工入侵公交一卡通――中新网 把普通公交卡改成员工卡(可以无限制进出地铁站):高管破解北京公交卡非法充值消费400余次被公诉 因为北京目前旧卡(非CPU卡)仍然能使用,所以会有克隆卡:千龙网--北京--售用克隆公交卡 北京一男子涉嫌盗窃被捕
winnie Shao 核心会员 用户来自于: 北京市
2026-01-12 17:41
谢邀。我在20年前做过一个IC卡的项目,那个项目中IC卡是可以读写,因此钱是在IC卡中。但是服务器上有数据库,每天做一次同步,就是和食堂的收款机同步。也就是钱,同时在服务器上有备份。发现有异动,会被查到。 不知道现在有没有改进。 太暴露年龄了。
卜杰Kevince 核心会员 用户来自于: 北京市
2026-01-12 17:05
利益相关:前段时间了解过一些射频安全的知识,也想本校网络中心的老师了解过我们学校校园卡的计费机制。 先说结论:计费方式是服务端和校园卡内部存储双轨计费,以服务端信息为准,想必公交卡计费方式应该也差不多。 我们学校的校园卡使用的是普通的IC卡,也就是MIFARE MF1S503x IC卡, MIFARE datasheet
  • 每张卡分为16个Sector,每个Sector分为4个Block,每个Block 16 Byte
  • 其中Sector 0 Block 0 也就是每张卡储存信息的最开端是只读区,前四个字节储存的是每张卡的唯一标识符,即UID信息,全球唯一(约定要求),第五个字节存储的是UID的CRC验证值,后面十一个字节存储的是生产厂商信息。这就是卡的标识信息。
  • 每个Sector 的Block 3存储是每个Sector的访问密钥,读卡器需要通过正确的密钥来读写相关扇区(Block)的内容,密钥的长度为6 Byte,且每个扇区有两个密钥A和B,密钥的组合方式有(2^48)种可能。而余额等信息就是存储在某个扇区中。
所以刷卡消费流程如下:
  • 每个读卡器都缓存了有效校园卡的UID和个人学号的对应列表,读卡时首先匹配获得与UID匹配的学生学号,防止有人拿着挂失卡消费。每次同步时更新UID列表
  • 如果读卡器离线:读卡器通过内置密钥读取校园卡相关扇区获取余额,进行扣费等操作,且在本地缓存消费记录,待上线后上传某饭卡消费记录。
  • 如果读卡器在线:根据校园卡UID从缓存列表获取个人学号,以此查询服务器获取服务端饭卡余额,扣费后进行同步。
所以有时候会出现刷卡时卡内余额突然增多或者减少等情况。有人在贴吧发帖控诉学校计费系统黑幕,学校无辜躺枪……其实是因为有些地方的读卡器同步不及时。 另外说个坑爹的Bug,就是校园卡丢失之后,即使即时在圈存机上挂失,旧卡被别有用心的人捡走,在一些没有即时同步的离线读卡器上刷卡也能照样消费,因为同步时是以学生学号作为标识符,之后读卡器同步时这些消费照样计入该学生账户。更坑爹的是学校某个餐厅的读卡器的同步频率特别低…… 再来个彩蛋吧:本校有个十分坑爹的早操制度,大一大二学生每学期需要跑步打卡40次,不满40次这学期体育59分,直到补跑满才恢复原始成绩。对于我这种懒人而言每天六点多起床简直要人命,所以大二两个学期欠下了30+次早操╮(╯▽╰)╭。恰好认识一些比较勤劳爱早起的女同学,以请吃饭为报酬让其帮我打卡。可是校园卡只有一张啊,总不能每天给别人第二天再要回来吧,很麻烦。分析早操打卡机器识别的应该是校园卡的UID号,于是购买了几张UID可写的空白IC卡,在Sector 0 Block 0写入自己校园卡的UID,这样这张白卡只能用来刷早操,由于没有特定扇区的密码所以不能用来打饭等消费,既安全又方便(*^__^*) 嘻嘻…… 9月7号本学期第一次早操打卡,到时候验证一下猜想。
王mj 核心会员 用户来自于: 北京市
2026-01-12 16:50
都没说到本质问题上。 国内公交卡,包括北京公交一卡通,采用的是金融IC卡PBOC2.0电子钱包标准。电子钱包是一种用于脱机离线交易环境的IC卡标准,所用的POS机具和闸机机具是离线的,刷卡时不需要连接到服务器后台。因此,公交卡的余额是保存在卡片上的,只有卡片上有准确的余额信息。POS机具每天会有日结批上送,就是每天会把当日所有交易信息上传到服务器,由后台进行对账结算。 关于卡片制式,包括北京在内的主要大城市公交卡,已经不再采用MIFARE卡了,原因是太不安全已经被破解。现在多数已经采用CPU芯片卡,部分甚至已经是JAVA CARD了。 关于电子现金,电子现金可以看作是电子钱包的升级版,电子现金的交易是可以实时连接到后台的,取决于交易策略。目前国内公交除了一小部分城市直接采用银行电子现金卡外,其余都还是电子钱包卡。
牧山青 核心会员 用户来自于: 北京市
2026-01-12 16:37
第一的答案跟实际情况还是有些出入的,当然大部分是没问题的。 公共交通卡/银行IC卡(仅电子现金)余额在服务器端和卡片端都会记录,但都以服务器端为准。 公共交通卡这类的消费都是脱机消费,即使在可以终端联网的情况下也不会联机,如果是圈存的话是需要联机的。 银行IC卡,如果你开通了闪付的话,卡片端和服务器端还会额外增加一个电子现金余额(类似于公交卡),通过闪付消费一般都是脱机的,如果风险检查没有通过的话会联机交易。 消费会产生交易日志等等,如果每笔交易都要实时上传,服务器是吃不消的,这里服务器要做的事情很多,比如验证余额,交易日志,交易凭证等等,而不仅仅是同步数据。其解决办法就是日终的时候批量上传日志等文件/数据。 校园卡等不了解。
匿名用户用户来自于: 北京市
2026-01-12 17:45
行业相关 城市一卡通平台,公交卡充值,校园卡充值都做过。 文字逻辑不太好,能表达到哪种程度要看你们的理解能力了~_~ 先明确一下,题主所说的公交IC卡的钱是存在卡里的,但是一般来说公交后台也会有一个余额作为辅助参考。你们日常乘坐公交、地铁刷卡时都是脱机消费,不需要和公交后台进行交互,脱机消费所产生的交易信息会存在刷卡时的POS机中,这些会定期从POS机采集出来送到公交后台进行清算,清算之后会对公交后台存储的余额进行更新。 公交后台存储余额的意义:例如你的卡里现在有200元,如果卡坏了要换卡或者退卡, 那么读不了卡怎么知道要给你退多少呢, 这时候就需要公交后台存储的这个余额了,但是这个余额是不准确的,有可能后台现在余额是200元,但是你最近几天产生的消费还在POS机里,你的实际余额实际是少于200元的,不过要知道公交公司是不可能会吃亏的,当你的卡坏了去做换卡或者退卡的时候,公交公司会先帮你做个申请,然后通知你几天以后再来,这几天时间就是用来等最近的消费记录送到后台清算,清算完之后发现你的余额已经少于200了,几天过后你来的时候公交公司就会按最新的余额给你换卡移资或者退钱。 -------------- 先占个位,以后慢慢补充吧。 有什么问题可以在评论里说,我会尽量解答。 正好让我自己写我也不知道怎么写合适。
匿名用户用户来自于: 北京市
2026-01-12 16:51
我对这些的了解尚且不够多,不过从简单的观察就能得到结论……… 在服务器里。 如果说有什么需要的知识的话,就是公交卡是NFC,近场通讯技术,作用距离最大应该几厘米到十几厘米…… 手机版没法编辑网址啥的……具体的请自行wiki…… 以下是观察结论: 地铁系统和公交系统通用 //地铁站充值的卡可在公交上消费 地铁有时会刷不进站,且此时到客服中心解决一下即可 乘坐地铁若在一台闸机刷卡而不进站,从另一台闸机刷卡仍可正常进站 于是分析得到这样的结论… 地铁刷不进站是由于(卡或系统)内记录的进出站信息不对应 卡或系统之一必然存储着进出站信息 进出站信息是在闸机检测人是否通过后写入的 /* 本人住在天津,天津的地铁闸机目前我看到的都是红外线+挡板,上海好像有这种和转轴,别的地方不太清楚…… */ 由于人进入闸机时的动作是先把卡从读卡区取下再经过闸机,而此时卡距离读卡区距离远大于NFC能作用的最大距离,因此闸机无法在卡上留下记录,因此信息存储在服务器上……… 至于公交车上是如何连接服务器的…… 因为我没开过公交车,也没资磁……咨询过公交司机这类问题,所以并不知道。
kevinou 核心会员 用户来自于: 北京市
2026-01-12 17:08
钱当然是在银行账户里啦。 读卡器不联网的话,卡里只是一个余额数字,刷卡时读卡器会扣除费用后把新的余额数字回写到卡上。同时读卡器会记录下卡号和余额、费用,回到车站后把数据导入服务器,服务器再更新数据。显然这种方式存在安全隐患,读卡器并不向服务器验证卡里的余额,如果你能破译读卡器的加密算法,就能往卡里任意充值啦。 现在读卡器可以联网了,其实就是加上个无线通信模块,可以与服务器实时通讯。这种情况下,卡里只需存身份信息,余额实时在服务器上更新,安全性更高。
张海强 核心会员 用户来自于: 北京市
2026-01-12 17:33
刚好我毕业设计做的就是这个东西,事实上呢,楼上说的很好了,我做一点补充。 以前的刷卡一般都是要和服务器联网的,怕的就是不安全。但是随着技术的发展,把你所谓题目里的钱放在卡上的越来越多了。电子现金,意思就是电子形式的现金,你丢了是没法管的,而且由于电子现金账户有上限,银行也不怕你修改这里面的金额,有哪个本事破解了公钥密码,还干这个干啥。现在成都坐地铁就可以刷蓉城卡了,也挺方便的,希望以后越来越方便吧~
lammer ren 核心会员 用户来自于: 北京市
2026-01-12 17:04
钱既不在IC卡里也不在服务器里,两个里面都只有数字! 所谓的IC卡充值,就是把钱兑换成IC卡里面的数字。 不管是IC卡还是刷卡机,仅仅是完成一个计数的功能。 对于消费者,每一次刷卡就是减去一定的数字,每一次充值就是加上一定的数字。 对于公交车或者商家,每一次刷卡就是自己的设备上计数增加,然后再拿着自己的设备到IC卡的发行方那里把数字兑换成钱。既然仅仅是完成计数的功能,又不必实时结算,商家的设备没有必要连接服务器。 IC卡里面可以存数字,也就是说可以存储信息。 更加准确地说法:IC卡可以存储信息,所谓的余额不过是信息的一种

关于作者

问题动态

发布时间
2026-01-12 18:19
更新时间
2026-01-12 18:19
关注人数
0 人关注

推荐内容

光模块是通过什么接口于机房的服务器相连呢?如果是走PCIE通道怎么能达到100G甚至400G的速度?
想考网络工程师,希望能给出一些建议?
壁挂式新风系统有什么用?
两个路由器同时接到交换机上会发生什么?
三级以上无线路由器如何串联,要求每个路由器都有路由+无线AP功能?
求技术帝现身:家里断网之后 弱电井重启又能恢复上网,是什么原因?
弱电集成入门最重要的是什么?
买曲面电视,还是买投影仪?
一名网络工程师尴尬的现状?
思科10G光模块为什么用XFP不用SFP+?
All Rights Reserved Powered BY WeCenter V4.1.0 © 2026 粤ICP备20025096号-2
  

粤公网安备 44190002007303号