こんにちは、情報処理安全確保支援士の勉強をしているねこです😸
最近、日本で「FeliCa（フェリカ）」という非接触 IC 技術に関して、改ざん可能となる脆弱性が報じられ、交通系 IC カードや電子マネー、iD サービスなど多くの人に関係する話題となりました。
これに関して、脆弱性そのものというよりも、発見者の開示方法や、それを受けた報道機関のリリースの仕方が問題になって、セキュリティ界隈ではかなり燃えていますね…。
私は現在支援士を勉強中なんですが、このインシデントについて自分自身の知見を整理する意味でも記事にしておきたいと思います。
脆弱性の概要
-
対象
2017年以前に出荷された一部の FeliCa IC チップ。
Suica / PASMO などの交通系ICカードや電子マネー（iDなど）の一部に影響する可能性あり。
モバイルFeliCa（おサイフケータイ）や2017年以降の新チップは対象外。 -
脆弱性の内容
暗号鍵を取り出すことが可能となり、カード内のデータの読み取り・改ざんができる可能性。
理論的には残高偽造や利用履歴の改ざんなどが考えられる。 -
現実的な攻撃難易度
物理的アクセスや特殊装置が必要とされ、一般的な利用環境で即座に被害が出るものではない。
また、システム全体では不正検知や照合システムがあるため、単純に残高を書き換えてもサービス利用は難しい可能性が高い。 -
被害状況
報道時点では悪用の実例や被害報告は確認されていない。
私もこのFeliCaの脆弱性報道があってからモバイルICOCAを立ち上げたときに、「お使いのICOCAは大丈夫ですよ～」みたいな文章がポップアップで出てきました。
今回の技術的な問題点は、以下のようにまとめられそうです。
| 論点 | 内容 |
|---|---|
| 対象の世代・範囲 | 2017年以前に出荷された一部の FeliCa IC チップ。新しいチップ・モバイル FeliCa／おサイフケータイは対象外との情報。 (ドコモ) |
| 脆弱性の種類 | 報道では「データ読み取り・改ざん可能性」「暗号鍵を取り出せる」という記述がある。暗号アルゴリズムそのものではなく、チップの実装または鍵管理における問題、または暗号鍵が複数のカード等で共有されていたという点が指摘されている。 (ダイヤモンド・オンライン) |
| 被害の有無と難易度 | 現時点では悪用の実例（被害）は確認されていない。攻撃を成功させるには物理的／技術的な要件が厳しい可能性が高い。たとえば、カードに直接アクセスできること、暗号鍵を取り出すための特殊な装置や技術が必要であることなど。報道では残高偽造を「数分で」といった表現もあるが、具体的にどこまで再現されていたか詳細が不明な点が多い。 (ダイヤモンド・オンライン) |
| システムの防御構造 | 単にカードが持つセキュリティだけでなく、カードとサーバー間の照合・不正検知・異常監視など、システム全体での防御策を持っている事業者が多いこと。カードの残高のみを操作できたとしてもシステム側で異常と判断する可能性がある。 (ダイヤモンド・オンライン) |
発見者の行動に関する問題点
本件で特に議論になったのは「脆弱性の発見者が報道機関に直接伝えたこと」です。
-
本来の流れ（IPA脆弱性届出制度）
脆弱性を発見したら、IPA（情報処理推進機構）に届け出 → JPCERT/CC やメーカーと調整 → 公開タイミングを決定 → 必要な回避策とセットで一般公開、というプロセスが推奨されています。
これは「攻撃者に悪用される前にベンダー側が対応できる時間を確保する」ための制度。要するに、ゼロデイ攻撃を防ぐためです。 -
問題点（今回の行動）
1. 報道が先行：メーカー側で調査や修正方針が整う前に「脆弱性あり」と広まった。
2. 利用者への不安拡大：具体的に「自分のカードが対象か」「どう対策すればいいか」が示されていない状態で不安だけが拡散。
3. 悪用リスクの増大：攻撃手法や鍵抽出の可能性が広まることで、攻撃者にヒントを与えた可能性。
4. 制度を無視した先例：正規の脆弱性届出制度を経由せず報道に渡ったことで、今後も「発見したらメディアに持ち込めばいい」という誤った認識を助長する恐れがある。
この点に関しては、情報処理安全確保支援士(登録セキスペ)で、試験の解説本なども出版している村山先生のXでの経緯説明がわかりやすかったように思います。
【（3/3）続き】
・発見者は「情報処理安全確保支援士」という，それなりに責任ある立場でもありました。
・某報道機関はFeliCaの会社にも取材を敢行。会社側は困惑。
・9月9日，ルールは守ってねというお願い（実質，おこ）が経済産業省とIPA（（独）情報処理推進機構）から出ました。
【ここまで】— 村山直紀 (@MurayamaNaoki) September 9, 2025
脆弱性対応の制度・プロセス
この事件から（なんとなく）学べた、脆弱性対応制度・ルールのポイントは以下の通りです。
-
情報セキュリティ早期警戒パートナーシップ制度
発見者が脆弱性を IPA に届け出て、JPCERT/CC や関係機関と調整して、どのタイミングで一般公開するかなどをガイドラインに基づき決めるプロセスがあります。 - ガイドラインの内容
・発見者は正当な理由がない限り第三者に未公開の脆弱性情報を開示しないこと。
・メーカー／開発者には、脆弱性の影響調査・対策を行うこと、公表時期を調整すること、公開後は対策状況等を明示すること。 -
今回の報道と制度のギャップ
共同通信が報道した時点では、このガイドラインによる「公表準備中の段階」と推定されており、発見者／ソニー等／JPCERT との間での調整が完全に終わっていなかった可能性が高い。報道が先行することにより、必要な回避策や影響範囲の詳細が十分に整っていない段階で一般に「危険」を伝える形になった、という批判があります。
この中で何よりも私は、「発見者は正当な理由がない限り第三者に未公開の脆弱性情報を開示しないこと」というのが重要なのではないかと思いました。
セキュリティの勉強をちょっとでもしたことがある人はみんな分かると思うのですが、ゼロデイ攻撃の可能性がありますよね。
発見者の方にどのような理由があったのかはわからないのですが、今回IPAに届け出るというプロセスがなされる前に報道機関にお話が持っていかれたとのことなので、それはちょっと良くなかったですよね…。
発見者からの情報提供を受けた報道側の問題
で、報道機関の人がちょっとでも「あれ？」って思って止まってくれたらよかったんですけど、そうはならなかったんですよね。
報道側にも下記のような問題があったと思います。
-
不安を煽る表現と情報の精度
「改ざん可能」「数分で偽造」などの語句が使われた報道もあり、読者にとっては漠然とした恐怖を感じさせる内容。具体的な攻撃成功の再現性や条件が明確でないときにこうした表現を使うことはミスリードにつながる可能性があります。
特にSNSとかでは記事タイトルだけや一部の切り抜きが誇張されて拡散されていたように見受けました。セキュリティに詳しくない方が必要以上に怯えて混乱するのも当たり前です。 -
利害関係者の発表内容のばらつき
例えば交通系 IC を発行する各社が「私たちが使っているカードは対象外」「モバイルタイプは影響なし」などと、利用者が混乱しないよう補足する発表をしているのに、それらが報道に十分反映されていないケースがあります。 -
公表タイミングの問題
制度上は「調査・対処準備 → 関係者間での調整 → 公表」という流れがありますが、今回これが守られておらず、公表が先に来てしまってました。
まとめ
今回の FeliCa 脆弱性報道は、技術的な危険性そのものよりも、むしろ 「発見者がどう行動すべきか」 を考えさせられる出来事だったと感じます。
脆弱性は発見自体も重要ですが、その後の扱い方次第で、社会に与える影響が大きく変わります。
本来なら、IPA への届け出やベンダーとの調整を経て、公表の時期や内容を慎重に判断すべきところを、報道が先行したことで「利用者の不安」や「攻撃者へのヒント提供」といった副作用が生じました。この点は、セキュリティを勉強している人間として強く意識しておくべき教訓だと感じました。
情報処理安全確保支援士は「技術的知識」だけでなく、「社会的影響を考えながら行動できること」が求められる資格です。
資格を取得した後も、今回のような事例を思い出しつつ、発見や指摘が正しく受け止められ、社会にプラスとなるような伝え方を心がけていきたいと思います！
