悠遊卡是不是有漏洞？有，但先別急著丟卡、我們聊聊整體的設計脈絡。

所謂的資安，在現代意義上並不是只會使用一層防護就結束了，通常我們會去談縱深防禦 (Defence in depth)，按照需要防護的資訊資產的機密性、完整性以及可用性去作探討。 悠遊卡上面的金額可以被修改，這牽涉到資料的完整性。而之所以會這樣設計，是因為整個悠遊卡系統本質上就是一個超大型的分散式資料庫。 那只要是分散式資料庫，就一定會受到CAP理論所限制，所謂的CAP理論是指資料一致性 (Consistent)，可用性(Availability)以及中斷容忍性(Partition Tolerance)在設計上無法同時滿足三者。而悠遊卡作為交通票證被發明，它必須要容忍在鄉間沒有網路的場景，因此在 CAP 中它犧牲掉資料一致性去換取可用性以及中斷容忍性。就像你去鄉下搭公車沒網路時也能刷卡，回到市區站再同步資料，這就是所謂『資料最後會一致』(最終一致性) 的設計。 舉另外一個例子，像是簡訊實聯制，設計上就是犧牲掉中斷容忍性，所以如果是鄉間沒有手機訊號的偏遠地區就沒辦法使用了。

💳💳💳

換句話說，悠遊卡的設計可以讓戰爭網路暫時中斷的狀況也能繼續被使用。 回過頭來，這樣說的話有漏洞的部分是什麼部分呢？其實早在 2010 年，資安研究社群就已經發現悠遊卡存在漏洞，能夠修改卡片上面的資料。 接下來就是常見的迷思了：是不是只要「有漏洞」，就一定得全面換掉？ 實際上，我們日常使用的房租契約、勞動契約、本票甚至支票，目前還有許多都是紙本的。技術上這些東西也都可能被塗改或偽造，因此法律上也有對應的處理機制，例如偽造有價證券罪（刑法第 201 至 205 條）。所以，縱使有技術上的漏洞，風險若能透過制度管理到合理範圍內，就不一定非得全面淘汰。這樣的比喻不是為了淡化悠遊卡的問題，而是讓大家理解：「有風險 ≠ 一定要淘汰」，而是要看風險是否可控、可補償。 因此不是說可以被修改就一定得被換掉，只要風險能下降到利害關係人能夠接受的範圍內，那麼補償性 (Compensating) 措施仍然是可以考慮的作法。 比如某個軟體有漏洞，開發廠商倒了，也沒人能重寫或維護，那這時怎麼辦？ 常見的補償性作法，就是加強備份機制、限制這套軟體執行環境的對外存取，來降低實際風險。

🩹🩹🩹

如果皮丘只寫到這樣，大概就只是讓大家看了一篇一般資安研究員都寫得出來的文章而已，實際上來說在機密上的考量上，我仍然認為數發部應該還是要和悠遊卡公司商討 MIFARE Classic 的退場機制，以及後續對於卡片密碼學缺陷導致的資安風險和對應成本。 悠遊卡最大的問題是可以在不經過使用者授權的情況下，使用射頻取得卡片的識別碼，同時這個識別碼基本上是固定且唯一的。也就是說，每個攜帶悠遊卡的人，就像是背後掛了個看不見的牌子，別人靠近你一點、用手機掃一下就能知道你是誰、去哪裡。 唯一的好消息在於悠遊卡購買時並不需要雙證件之類的措施，因此未授權的個資使用者只能分析出某張卡號的移動或是消費行為。（個資法第二條之社會活動）

📄📄📄

對於這樣的個人資料盜用，在現有的悠遊卡機制中，使用者不會察覺。但其實仍然有辦法偵測，舉例來說我經常用的悠遊卡是台新的黑狗卡，除了卡面很可愛以外，如果周遭有不正常的電子訊號導致卡片線圈充電時，Richart 的領結就會亮燈閃爍，所以同時也可以做為某區域是否有不正常的 RFID 讀取器的警示。 另外一種檢測方式可以透過 android 手機的 RFID 讀取器，如果是符合規範的護照，在讀取時不會出現固定 ID 的現象，但悠遊卡就會。 如果說悠遊卡在當年是全部有被登記到身分證字號或至少是行動電話的話，那麼當年的簡訊實聯制有在 g0v 被提出時就可能改成「悠遊卡實聯制」，使用者只要在超商結帳時使用悠遊卡付款就不需要另外登記，同時只需要一台普通的 android 手機就能夠掃描使用者的悠遊卡，再加上將卡片 UID 和處所代碼上傳衛生局就能夠完成功能了。

• 這只是一種技術上假設性的場景，並不是說當年政府真的這樣做。

只是這些事情就是回到上面幾段所講的，這樣的措施在疫情結束後我們沒辦法把權力從政府或是企業手上拿回來，那這樣會是利害關係人（國民）們想要的結果嗎？