😱捨てた古いクレジットカード、使えちゃうの？EMV®非接触決済に潜む脆弱性「ゾンビカード」

ハサミを入れ損ねた古いカード、使えちゃうんですって

안녕하신게라！パナソニック コネクト株式会社クラウドソリューション部の加賀です。

財布の奥や引き出しの底に、期限の切れたクレジットカードが1枚くらい眠っていないでしょうか。新しいカードが届いたとき、古いのは「どうせもう使えないし」と放り込んだきりになっているものです。

その「どうせもう使えない」という前提を、誰も保証していなかった！という論文が USENIX Security '26 で発表されました。Zombie Cards Back Online: Reviving Expired Credit Cards for Contactless Payments（期限切れのクレジットカードを非接触決済のために蘇らせる）、マサチューセッツ大学アマースト校の Raja Hasnain Anwar 氏らによるものです。

この論文、何がすごいの？ 3行でまとめ

• 発想がすごい
  暗号を1つも破っていない。レジ端末が見る有効期限を、未来日に差し替えるだけ。
• 手口がすごい
  市販のAndroid端末2台。書き換え対象は僅か3バイト。鍵窃取もPIN推測も不要。
• 結果がすごい
  実験室だけでなく、実在の小売店と食料品店でも決済が成立してしまった。

財布に眠っている自分の古いカードをレジでかざしても、普通は通りません。
この攻撃が成立するのは、そのカードを手にした第三者が中継装置を挟んだときだけです。

ゾンビカードという名付けは大袈裟ですが割と正確に思えます。カードは自分が死んだと思っていません。こいつ…動くぞ！

有効期限は2箇所にあるけど、誰か突き合わせてる？

突き合わせていません。EMV®非接触決済の仕様は、全ての処理方式に一致を義務づけていませんでした。

1つは 5F24（Application Expiration Date）というタグ。もう1つは 57（Track 2 Equivalent Data）という、カード番号と期限をまとめて持つデータの中です。

厄介なのは、この2つを読む相手が違うことです。レジ端末は 5F24 を見て「このカード、期限が切れていないか」を判定します（オフライン決済に対応した端末での条件付き実装です）。一方、オンライン承認のために銀行（イシュア）へ送られるのは 57 のほうです。

封筒に貼った付箋と、中身の書類のようなものです。受付は付箋の日付で受け取りを決め、本社に回るのは中の書類。照合する人がいなければ、付箋だけ貼り替えれば受付は通ります。

有効期限はカードに刻まれた動かせない属性ではなく、関係者がそれぞれの場所で確認する約束事でした。

【コラム】カードの鍵には、期限が書かれていない

カードが決済時に使う暗号鍵そのものには、有効期限という概念がありません。期限を担保しているのは、カードに載っている証明書と端末側の判定ロジックです。

しかも論文が引用するEMVの仕様書（Book 2 §10.2.5.3）は「ICカードの有効期限は、そのカードに載る発行者公開鍵証明書の有効期限より後であってはならない」と定めています（筆者訳）。証明書のほうが先に切れることはない。再発行の端境期をまたげるよう、余裕が持たされています。

結果として、印字された期限が切れたあとも、カードは正規の暗号処理を淡々とこなし続けます。止まる理由が、どこにも実装されていないからです。

攻撃の仕組み、カードはどうやって蘇るのか

Step 1: カードとレジの間に割り込む

研究者が用意したのは、NFC対応のAndroid端末2台です。1台をレジ端末の前に置いて「カードのフリ」をさせ、もう1台を標的のカードに近づけて「レジ端末のフリ」をさせる。2台は無線で繋がっていて、両者のやりとりを素通しします。いわゆるリレー攻撃の構成です。

気になるのは遅延ですが、論文の見積もりでは1往復あたり20〜50ミリ秒の上乗せで、1取引あたりの平均レイテンシは約415ミリ秒。EMVが許す上限は1コマンドあたり500ミリ秒なので、タイムアウトには一度も引っかからなかったとされています。

Step 2: 端末が見る期限だけを未来にする

レジ端末がカードのデータを読みに行くと、カードは平文のタグ群を返します。ここで中継役が 5F24 の値だけを、過去の日付から未来の日付へ書き換えます。

5F24 は YYMMDD をBCDで詰めた3バイト。240831 を 280831 にする、それだけです。

Step 3: 署名も暗号文も、何ひとつ壊れない

普通に考えれば、データを改竄した時点で署名検証に引っかかるはずです。

ところが Kernel 3 と呼ばれる処理方式が使うオフライン認証の高速版（fDDA）は、署名の対象に 5F24 を含めていません。含まれていないものは、書き換えても署名と矛盾しません。

さらに攻撃者は 57（Track 2）には指一本触れません。触れば銀行側の検証で露見するからです。結果として銀行の手元には、本物の期限切れの日付が、正規の暗号文とセットで届きます。

実際には端末と銀行の間にアクワイアラと決済ネットワークが挟まりますが、ここでは省いています。

なぜブランドによって結果が違うのか

ここが個人的に一番の謎でした。同じ改竄を他の方式で試すと、悉く失敗します。

EMVの非接触決済には「カーネル」と呼ばれる処理方式が複数あり、国際ブランドごとに番号が振られています。論文が比較したのは次の4つです。

カーネル	5F24 改竄結果	そうなる理由
Kernel 2 （Mastercard）	失敗	端末が 5F24 と Track 2 の期限の一致を確認している
Kernel 3 （Visa）	成立	オフライン認証の高速版（fDDA）の署名対象に 5F24 が入っていない
Kernel 4 （American Express）	失敗	5F24 が発行者署名の対象データに含まれている
Kernel 6 （Discover）	失敗	CDAという方式で、カードが返したタグ群がハッシュに束縛される

なお論文がテストしたのは米国の5行が発行したカードで、JCBとChina UnionPayのカーネルは比較対象に入っていません。

EMVの仕様を管理するEMVCoは、国際ブランド6社が共同で所有する組織です。共同でやっているのに、なぜ強度が揃っていないのか。答えはEMVCo自身の公式FAQにありました。

Each global payment system has its own specification for a contactless kernel. EMVCo publishes these individual specifications on the EMVCo website as Book C-X Specifications.

（筆者訳: 各決済システムは、非接触カーネルについて独自の仕様を持っている。EMVCoはこれら個別の仕様を Book C-X として公開している）

カーネル仕様に関して、EMVCoは各社の仕様を束ねて公開している立場でした。共通化されているのは「どの端末でもどのブランドのカードが読める」という相互運用性のほうで、セキュリティ設計の細部は各社の裁量に残っています。同じFAQには、EMVCoから直接ライセンスを受けられる Book C-8 の記載もありますが、乱立が収束するかは今後の普及次第です。

では Kernel 3 はなぜ 5F24 を署名の外に置いているのか。論文自身が、この設計は取引の継続性と後方互換性を優先した結果だと説明しています。出回っている大量のカードと設置済みの端末を壊さず、正常な取引を誤って拒否しないこと。そちらを重く見れば、端から端まで厳密に束縛する設計は後回しになります。速度と承認率を取るか、データの整合性を取るか。同じEMVの枠内で、真逆の判断が並んで実装されているわけです。

実店舗でも通った、もう一枚の壁は機能したのか

では Kernel 3 のカードなら何でも通るのかというと、そうでもありませんでした。論文は実験対象の銀行を Bank A から Bank E という記号で匿名化しています。

同じカーネル、同じ改竄、同じ端末で試したところ、Bank A では決済が成立し、Bank B では銀行側が拒否しました。Bank B は「新しいカードをお使いください」という通知まで出しています。改竄なしなら想定通り拒否されることを確かめたうえで、Bank A のカードは1ドル、100ドル、500ドルのいずれでも通り、大学構内の小売店で2.79ドル、食料品店で3.19ドルの買い物まで成立しました。金額も業種もレジ端末のメーカも、論文が試した範囲ではそれ単独で成否を分けていません。

分かれ目は、銀行が何を見て承認を判断しているかでした。カード番号が実在して口座が生きていることだけを確認するのか、そのカード個体が現役かどうかまで見るのか。前者だと、届いている期限切れの日付は読まれないまま承認が返ります。

もう1つ、Kernel 3 には銀行にとって不利な仕様があります。端末は各種チェックの結果をTVR（Terminal Verification Results）という5バイトの領域に記録するのですが、Kernel 3 は銀行へ転送するTVRを全ビットゼロにすると定めています（Kernel 3 仕様 §B.1.1）。端末が「期限切れを検知した」と記録しても、その事実は銀行まで届きません。銀行が二枚目の壁を立てようにも、肝心の材料が端末側で止まっています。

そして、これが特定のカーネルに限った話ではないことを示す結果も出ています。Kernel 6（Discover）のカードは改竄をきっちり弾いたにもかかわらず、期限前に銀行が自動で再発行した旧カードが、何の細工もなしにそのまま決済できてしまいました。新しいカードと同じ口座に、です。カーネルが堅牢でも、「このカードは差し替え済み」という状態が承認経路に反映されていなければ、古いカードは生き続けます。

対照的に、Apple PayやGoogle Payのようなウォレットは、決済トークンの有効性を発行元側から更新できるぶん古い情報が残りにくい、と著者らは考察で述べています。ただしウォレットも改竄の実験対象で、5F24 を過去・未来どちらに書き換えても結果は変わっていません。カードが処理方針を伝えるCTQ（Card Transaction Qualifiers）に「期限切れならオンラインへ」が立っていて、判断がまるごと銀行に回るからです。安全だと確かめられたわけではありません。

結局これは、誰か1者の判断だけで決まる話ではありませんでした。処理方式が期限のデータをどこまで守り、銀行がそれをどこまで見直すか。その一次防御と二次防御の両方を抜けたときにだけ、お金が動く。責任をどう分け合うかの設計問題だった、というのが論文の結論です。

【コラム】研究倫理のお約束

使ったのは全て著者自身のカードで、攻撃者役も被害者役も研究者が兼ねています。実店舗での検証は事前に店舗へ説明したうえで1店舗あたり2回までとし、商品はきちんと購入。発生した請求は一切異議申し立てせず全額支払った、と明記されています。

また著者らは、リレー用アプリのソースコードを公開しないと決めています。緩和策が広く行き渡る前に悪用可能なツールを出すのは無責任だ、という判断で、代わりに手順と加工済みの通信ログだけを公開しています¹。この記事でも再現手順には踏み込みません。

著者らは2025年5月に該当ブランドと銀行へ報告し、2025年12月に再度連絡を取っています。報告は初期トリアージを通過し、レッドチームによる再現検証が進められている段階です。論文採択の時点で、緩和策の内容や時期についての回答は公表されていません。CVE番号も、論文公開時点では採番されていないと著者ら自身が明言しています。特定のソフトウェア製品の不具合ではないから、というのがその説明です。

日本で同じことを試す場合、自分名義のカードであっても、決済端末へ偽の有効期限を送る行為は法に触れうる領域です。

攻撃の前提になる3つの条件

どれか1つでも欠ければ、攻撃は成立しません。

• 標的のカードが物理的に攻撃者の手の届く範囲にあること
  論文も、米国で重要書類をめったに裁断しない人が34%、一度も裁断したことがない人が12%、という2018年公表の調査と、なりすまし被害の約17%が捨てられた資料に由来するという2022年の調査を引用しています。
• 再発行時にカード番号が据え置かれていること
  手元の更新カードを何枚か確かめた限りでは16桁は据え置きで、変わっていたのは有効期限とセキュリティコードだけでした（発行元ごとの運用なので一概には言えませんが）。
• カードと端末の少なくとも一方がRRPを実装して「ない」こと
  RRP（Relay Resistance Protocol）は、端末が時間を区切った問い合わせを投げ、応答が遅ければ取引を打ち切る仕組みです。
  中継を挟めば必ず遅延が乗るので理屈のうえでは検出できるのですが、任意実装のため、論文のテストに使われたカードと端末は1つも実装していませんでした。対策は最初から用意されていて、使われていないだけです。

裏を返せば、現役のカードは期限を書き換える必要がそもそもないので、この話はタッチ決済そのものを封印する理由にはなりません。

この研究が示す教訓

カード表面に印字された期限は、人間に向けた表示であって、システムが守ると約束したものではありませんでした。同じ値が2箇所にあり、読む相手が違い、照合が義務でないなら、そこは必ず狙われます。

もう1つの教訓が、検査結果を次工程に渡さない設計です。TVRを全ゼロで送る仕様は、端末が何を見つけたかを銀行へ一切伝えません。後ろの砦に判断材料が届かないので、二段構えは最初から一段でした。

身も蓋もない言い方をすると、責任の分担が曖昧な境界線には、だいたい穴が空いているということです。インフラをやっていると何度も踏む話で、EMVほど枯れた世界でも同じでした。このプロトコル自体も過去に何度か破られていますが、壊れたのはたいてい暗号ではなく、その周りの取り決めでした。

仕組み側の対策としては、端末が見る期限を署名の対象に含めること、5F24 と Track 2 の一致を端末が確認すること、銀行がカード番号と有効期限の組で承認を判断すること、再発行時に旧カードを明確な失効状態へ落とすこと、そして端末の検査結果を銀行まで届けること。いずれも論文が提案している内容です。

私たちにできること

論文が挙げる対策の筆頭は、拍子抜けするほど地味です。

古いカードは、ICチップと磁気ストライプの両方にハサミを入れてから捨てる。もしくは、発行元が案内している返却方法に従う。

NFCだの署名の束縛範囲だのと散々やってきて、結論がハサミ。ですが、この攻撃は標的のカードが物理的に手に入ることが大前提なので、物理的に潰すのが一番確実です。チップ本体に切れ込みを入れるのがポイントで、真ん中あたりで折るだけだと接点が残ることがあります。

「使えないはずのもの」が使えてしまう話は、これまでにも何度も出てきました。削除したはずのデータ、無効化したはずのトークン、退職者のアカウント。今回のカードもその系譜で、失効とは放っておいて成立する状態ではなく、誰かが能動的に維持し続ける仕組みなのだと、改めて突きつけられた気がします。

俺、この記事を書き終えたら引き出しに溜まってるゾンビカードを探すんだ。なぁに、このハサミがあれば大丈夫さ。（このあと滅茶苦茶部屋掃除した）

---

お断り
記事内容は個人の見解であり、所属組織の立場や戦略・意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。
本記事で取り上げた実験結果は論文著者らが米国内の特定環境で得たものであり、個別の金融機関・国際ブランド・決済事業者・POS端末ベンダの現在のセキュリティ水準を評価するものではありません。論文中の金融機関名は著者らによって匿名化されています。
EMV® は米国およびその他の国における登録商標、それ以外の地域では未登録商標であり、EMVCo, LLC が保有しています。文中のその他の社名・ブランド名は各社の商標または登録商標です。

1. 論文本体は PDFで全文公開されています。加工済みの取引ログは Zenodo に置かれています。著者らによるデモ動画と概要は EMV Expired Card Attack にまとまっています。 ↩