IC卡的錢是裝在卡里還是裝在伺服器里？

01-06

每次坐公交車都要打卡，但我發現了一個有趣的現象：打卡機上顯示公交卡的餘額，但打卡機卻好像沒有和伺服器（如果有的話）連接。這樣的話，錢就只能儲存在卡上了。請問真實情況到底是怎樣呢？錢是裝在卡里還是裝在伺服器里？卡只起到儲存身份信息的作用嗎？校園卡也是如此嗎？其他類型IC卡也是這樣嗎？謝謝解答！

題主說的錢，我理解為就是餘額，所以我認為題主問的就是卡餘額是保存在什麼地方。

卡餘額可能保存在卡里，也可能保存在伺服器上，具體情況是兩種都有。

1. 餘額只保存在卡內

應用範圍：磁條銀行卡在過去曾經廣泛使用，現在幾乎沒有。

這種方式安全性很差，但出現的最早，因為過去的時候網路實時驗證還很不成熟，只好把餘額數字放到卡里（小說《白夜行》里有類似的記述，直接克隆卡，修改卡餘額就能取錢），這種模式對賬周期一般比較長（可能是以月甚至更長時間計算），因為安全性的問題已經基本淘汰。

卡會長期放在用戶手裡，很難保證不被破解，再強大的演算法也無法保證長時間的可靠性，而且由於計算能力的不斷提升，任何早期的演算法放到今天都是不一定可靠的。尤其是磁性卡片，被破解基本上是時間問題。

雖然目前CPU卡已經十分安全，但也不能保證未來5-10年這種技術仍然是可靠的。而且老卡的淘汰也需要一段時間。

2. 餘額只保存在伺服器上，卡只作為身份標識

應用範圍：幾乎全部的銀行卡（磁條卡）、電話卡，大部分的校園卡、飯卡。

銀行卡裡面是沒有餘額的，甚至連密碼都沒有保存，很多銀行卡里保存的都是卡的信息（其實就是卡號），ATM機或者POS機在刷卡時讀取卡號，等待用戶密碼，然後把這些都打包給伺服器去驗證。

所以ATM機和POS機都是需要聯網的。有人說POS機可以不聯網，那是因為POS機里內置了一個SIM卡，通過類似手機上網的功能完成撥號、發送、接受數據的操作。

校園卡、飯卡也是類似的，這些卡的刷卡終端大部分都需要聯網，見過很多學校的食堂因為網路故障導致無法刷卡的。

這種方式的好處就是很安全，卡內的信息就算是被破解了也無法修改賬戶餘額，缺點就是無法離線使用，而且要查詢餘額也很麻煩。

3. 餘額同時保存在伺服器和卡內

應用範圍：大部分公交卡，部分校園卡、飯卡、IC卡電子錢包等。

公交卡里是有餘額的，比如題主貼出的北京公交卡，公交卡與其它卡片不同的地方是刷卡的反應速度需要很快，如果公交卡要聯網驗證，那麼速度就太慢了，所以公交卡里必須要有餘額以保證快速刷卡。

但這樣做安全性就有問題了，所以當公交卡的刷卡終端是有線網路時，實時聯網驗證，並同步一下餘額是否正確，如果刷卡終端是離線的，則把刷卡信息同時保存在卡里和刷卡終端上，刷卡終端每天晚上結算的時候聯網統一結算。

所以，對於北京的公交卡來說：

如果是在超市內刷卡結賬，這些結算都是實時與伺服器驗證的，如果發現餘額異常，則刷卡會失敗。

如果是在公交卡上刷卡，結算是非實時的，換句話說，如果偽造、篡改公交卡里的餘額，當天坐公交車是沒有問題的，並且由於公交車結算時間是每天晚上收車以後，在結算之前，偽造的餘額是不會被發現的，但結算以後可能會被人發現。

刷地鐵是否是實時結算還不清楚，可能是實時結算的，其它的應用場景如用IC卡打電話是否是實時計算也不是太清楚，有了解情況的可以來說說。

也就是說顯示的餘額確實是卡里的，但交易過程如果是聯網的，那麼會二次驗證餘額。

有一個方法可以比較簡單的驗證公交卡是否是實時交易：大部分城市的公交卡都能在網上查詢實時餘額（至少北京的支持），刷一次公交卡，到網上查詢一下，如果記錄能對的上，那麼交易是實時的，如果記錄對不上，交易則不是實時的。

---------------------------------------------------------------------------------------------------------

當然了，別以為通過伺服器驗證就是安全的：

伺服器漏洞被入侵，卡內被非法充值：奇虎360員工入侵公交一卡通――中新網

把普通公交卡改成員工卡（可以無限制進出地鐵站）：高管破解北京公交卡非法充值消費400餘次被公訴

因為北京目前舊卡（非CPU卡）仍然能使用，所以會有克隆卡：千龍網--北京--售用克隆公交卡北京一男子涉嫌盜竊被捕

利益相關：前段時間了解過一些射頻安全的知識，也想本校網路中心的老師了解過我們學校校園卡的計費機制。

先說結論：計費方式是服務端和校園卡內部存儲雙軌計費，以服務端信息為準，想必公交卡計費方式應該也差不多。

我們學校的校園卡使用的是普通的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號本學期第一次早操打卡，到時候驗證一下猜想。

謝邀。我在20年前做過一個IC卡的項目，那個項目中IC卡是可以讀寫，因此錢是在IC卡中。但是伺服器上有資料庫，每天做一次同步，就是和食堂的收款機同步。也就是錢，同時在伺服器上有備份。發現有異動，會被查到。

不知道現在有沒有改進。

太暴露年齡了。

錢當然是在銀行賬戶里啦。

讀卡器不聯網的話，卡里只是一個餘額數字，刷卡時讀卡器會扣除費用後把新的餘額數字回寫到卡上。同時讀卡器會記錄下卡號和餘額、費用，回到車站後把數據導入伺服器，伺服器再更新數據。顯然這種方式存在安全隱患，讀卡器並不向伺服器驗證卡里的餘額，如果你能破譯讀卡器的加密演算法，就能往卡里任意充值啦。

現在讀卡器可以聯網了，其實就是加上個無線通信模塊，可以與伺服器實時通訊。這種情況下，卡里只需存身份信息，餘額實時在伺服器上更新，安全性更高。

都沒說到本質問題上。

國內公交卡，包括北京公交一卡通，採用的是金融IC卡PBOC2.0電子錢包標準。電子錢包是一種用於離線離線交易環境的IC卡標準，所用的POS機具和閘機機具是離線的，刷卡時不需要連接到伺服器後台。因此，公交卡的餘額是保存在卡片上的，只有卡片上有準確的餘額信息。POS機具每天會有日結批上送，就是每天會把當日所有交易信息上傳到伺服器，由後台進行對賬結算。

關於卡片制式，包括北京在內的主要大城市公交卡，已經不再採用MIFARE卡了，原因是太不安全已經被破解。現在多數已經採用CPU晶元卡，部分甚至已經是JAVA CARD了。

關於電子現金，電子現金可以看作是電子錢包的升級版，電子現金的交易是可以實時連接到後台的，取決於交易策略。目前國內公交除了一小部分城市直接採用銀行電子現金卡外，其餘都還是電子錢包卡。

這種涉及到錢，而且還是大規模用戶的卡，我覺得是有個伺服器的，畢竟現在的學校卡和校園水卡都做了伺服器。這種卡有幾種吧，有接觸式非接觸式有IC 和ID卡之分，線圈的和晶元的，數據的真實變動其實都是"會同步到伺服器終端的，要不公交卡丟了就不能補辦了，另外別人非法盜刷也容易了，卡只是和公交終端通信過程過，讓公交終端識別卡以及驗證卡是否是合法的卡，再把數據同步到伺服器吧

不用聯網，不用輸密碼，查詢餘額和消費記錄就是這麼簡單

行業相關

城市一卡通平台，公交卡充值，校園卡充值都做過。

文字邏輯不太好，能表達到哪種程度要看你們的理解能力了~_~

先明確一下，題主所說的公交IC卡的錢是存在卡里的，但是一般來說公交後台也會有一個餘額作為輔助參考。你們日常乘坐公交、地鐵刷卡時都是離線消費，不需要和公交後台進行交互，離線消費所產生的交易信息會存在刷卡時的POS機中，這些會定期從POS機採集出來送到公交後台進行清算，清算之後會對公交後台存儲的餘額進行更新。

公交後台存儲餘額的意義：例如你的卡里現在有200元，如果卡壞了要換卡或者退卡，那麼讀不了卡怎麼知道要給你退多少呢，這時候就需要公交後台存儲的這個餘額了，但是這個餘額是不準確的，有可能後台現在餘額是200元，但是你最近幾天產生的消費還在POS機里，你的實際餘額實際是少於200元的，不過要知道公交公司是不可能會吃虧的，當你的卡壞了去做換卡或者退卡的時候，公交公司會先幫你做個申請，然後通知你幾天以後再來，這幾天時間就是用來等最近的消費記錄送到後台清算，清算完之後發現你的餘額已經少於200了，幾天過後你來的時候公交公司就會按最新的餘額給你換卡移資或者退錢。

--------------

先佔個位，以後慢慢補充吧。

有什麼問題可以在評論里說，我會盡量解答。

正好讓我自己寫我也不知道怎麼寫合適。

第一的答案跟實際情況還是有些出入的，當然大部分是沒問題的。

公共交通卡/銀行IC卡（僅電子現金）餘額在伺服器端和卡片端都會記錄，但都以伺服器端為準。

公共交通卡這類的消費都是離線消費，即使在可以終端聯網的情況下也不會聯機，如果是圈存的話是需要聯機的。

銀行IC卡，如果你開通了閃付的話，卡片端和伺服器端還會額外增加一個電子現金餘額（類似於公交卡），通過閃付消費一般都是離線的，如果風險檢查沒有通過的話會聯機交易。

消費會產生交易日誌等等，如果每筆交易都要實時上傳，伺服器是吃不消的，這裡伺服器要做的事情很多，比如驗證餘額，交易日誌，交易憑證等等，而不僅僅是同步數據。其解決辦法就是日終的時候批量上傳日誌等文件/數據。

校園卡等不了解。

剛好我畢業設計做的就是這個東西，事實上呢，樓上說的很好了，我做一點補充。

以前的刷卡一般都是要和伺服器聯網的，怕的就是不安全。但是隨著技術的發展，把你所謂題目里的錢放在卡上的越來越多了。電子現金，意思就是電子形式的現金，你丟了是沒法管的，而且由於電子現金賬戶有上限，銀行也不怕你修改這裡面的金額，有哪個本事破解了公鑰密碼，還干這個幹啥。現在成都坐地鐵就可以刷蓉城卡了，也挺方便的，希望以後越來越方便吧～

從今年開始，北京的公交扣費機逐步更新換代，新的扣費機都是實現聯網扣費了，扣費數據是會逐條實時回傳到中心伺服器上的。

IC卡里的錢是寫在卡里的，但每次交易都會生成交易記錄會上傳後台比對

校園卡不是實時結算，而是每天下午5點做結算(我們學校)

但校園卡充值是實時結算，消費卻沒有。這應該算一個bug。

曾經某同學早上充了100，請大家喝飲料基本花完了，然後就跑去註銷卡，當場補辦回來，卡里還有100。

不知道學校每天有沒有審核這個消費記錄...雖然有被處分的風險，但還是好多同學這樣做...

告訴你個事實！八達通實時扣費，深圳通也是實時扣費！

如果餘額在卡里卡丟了怎麼補卡啊

刷公交卡，校園卡，地鐵卡，都是RFID(射頻識別）技術的具體應用。卡本身大多是無源的，所以刷卡的時候要離得很近，通過電磁波給卡提供工作電壓，然後卡和讀卡器（也就是安裝在公交或者地鐵上的刷卡儀器）才能進行通信，現在基本都是把卡信息（餘額）存在系統的伺服器里，讀卡器與伺服器的通信可以用專網通信（小型的通信解決方案），公網通信（3G或者4G）。

擼過廣州的羊城通的飄過。。。

廣州羊城通用的是M1卡

公交的結算是非實時的，刷便利店什麼的好像是實時檢驗卡上的餘額，地鐵好像不是實時檢驗的，首先卡上是有存放餘額的數據的，卡上的數據是16進位的，卡上有刷卡記錄的數據，充值記錄的數據，然後餘額那幾個數據位還用一種啥方式加密過的（太久了，忘記了），充值數據有充值的終端號、充值金額等數據，嗯，要改餘額要對應改上充值數據、餘額、金額變化等數據。。。

然後卡內的這些數據肯定在服務中心存著的，公交上的刷卡機要把數據同步到數據中心那邊的（多久不知道），數據中心上面會把各種的數據彙集在一起，包括各家公交公司、地鐵的數據，各個充值終端的數據，如果數據中心那邊發現有些數據對不上，就會把這些卡禁用掉，公交上的刷卡機當然會同步這類數據，我當時就試過刷我的羊城通，刷機卡大聲地報著：黑名單卡！！！

最後，擼羊城通是我多年前為了滿足我的好奇心做的，這幾年來我的羊城通都是自己充的錢，所以，別來查水表！！！！！！！！！！！

和銀行卡的道理是一樣的，只是沒有密碼而已。ps .我們的高中數學老師說過盜刷這種卡的犯罪程度是和銀行卡詐騙是一樣的

每張射頻卡內都有全球唯一的身份識別id，不過有設備是可以改寫的，然後就是有帶密碼保護的可擦寫的存儲區塊。

實際應用中由於物理空間的限制很難做到卡和伺服器可靠的實時同步數據，一般採用非同步通信。

但是基於安全考慮，需要有多種身份識別校驗，比如動態密碼，可疑情況立刻連接伺服器校驗甚至拒絕交易等等。。。

具體就看設計人員怎麼想的了

卡裡面有沒有不重要,伺服器上一定要有.不然怎麼交互呢.