ホーム
情報セキュリティ, 脆弱性対応
脆弱性報道のケーススタディ-報道・JVN関係者コメント・解説など

脆弱性報道のケーススタディ-報道・JVN関係者コメント・解説など

ソニーの非接触ICカード技術「FeliCa」のICチップのうち、2017年以前に出荷された一部のICチップについて、特定の操作により、当該チップにおいてデータの読み取りや改ざんが実行される可能性があることの報道がなされて、その報道のあり方が良かったのか、議論が起きています。

なお、筆者は、「情報セキュリティ早期警戒パートナーシップガイドライン」の議論をしている「情報システム等の脆弱性情報の取扱いに関する研究会」の一員ですが、このブログは、その委員会の議論とは別に、一リサーチャーとしての分析をまとめるものです。 (IPA「情報システム等の脆弱性情報の取扱いに関する調査の報告書などを公開」のリンクは、こちらです)

ということで、この「未公開の脆弱性関連情報の報道による公開の是非を考える」という論点について、考えていきたいと思います。本件事案(以下、Felica事件)の事実関係タイムライン、いままでの参考ブログをまとめて、ケーススタディ、そのうえで、「国内における脆弱性関連情報を取り扱う全ての皆様へ – 情報セキュリティ早期警戒パートナーシップガイドラインに則した対応に関するお願い –」についても読んでみることにします。そのうえで、参考文献、私のブログをまとめます。

1 Felica事件の事実関係

1.1Felicaって何

Felicaというのは、ソニーの開発した非接触型ICカードの技術方式、および登録商標だそうです。ソニーの説明はこちら。技術的な説明については、富士フィルムの説明があります(リンク)。Type-AやType-Bの説明もみましょう。

FeliCaはNFCの規格を基準に改良を加え、1秒に満たない処理速度を実現しました。そのため、日本の公共交通機関における乗車券の代わり（交通系ICカード）として利用されるようになりましたが、(略)スマートフォンにおける日本の独自決済機能が海外では使えない理由はこの点にあります。

ということで、山の手線の混雑を、TYPE A/Bでさばけるのか？というのが、プロジェクト Xになるわけです。(実際になっていたかは不明) クレジットカードのタッチレス決済と公共交通機関の問題については、この点については、この「クレカのタッチ決済が本格普及か!? 世界標準「NFC TypeA/B」規格に各社が対応」の記事があります。(ロンドンとかは、タッチレスでそのまま乗れるので、本当に便利でした)

1.2 報道の前後関係

ということで今回のFelica事件です。タイムラインは、

2025年7月

セキュリティー企業アンノウン・テクノロジーズ（東京）の切敷裕大氏らのグループがフェリカのセキュリティーを管理する暗号鍵を取り出せることを確認し、情報処理推進機構（IPA）を通じて7月にソニーに報告(共同通信の記事より)
ソニーは、7月下旬の連絡以降、脆弱性の検証や関連事業者との協議も進めていたようだ(Impress Watch記事より)

8月28日

共同通信が「【独自】フェリカに重大な脆弱性　交通系IC、データ改ざんの恐れ」という報道(8月28日 20時49分)
ソニーが「2017年以前に出荷された一部のFeliCa ICチップの脆弱性に関する指摘について」というプレスリリース(リンク)
ドコモ「FeliCa脆弱性に関する一部報道について」(プレスリリース)
JR東日本「FeliCa の脆弱性に関する一部報道について」(プレスリリース)
Pasmo 「FeliCa の脆弱性に関する一部報道について」(プレスリリース)

その他のコメントについては

CNET 「ソニーFeliCaに脆弱性報道、Suica・nanaco・楽天Edy・WAON・iDなどが相次ぎ声明」(リンク) (8月29日)

がまとめています

X(ex Twitter)のまとめ

FeliCaに脆弱性が発見されたニュースに様々な反応、その仕組から影響が及ぶ範囲を考える人も「FeliCaの処理速度じゃないと改札の処理が追いつかない」

Felica交換しますという詐欺のリスクがあるんじゃないの？という指摘もあったりします。

Impress Watch記事「FeliCaの“脆弱性”報道はなにが問題なのか」(9月8日)

メディアが報じるには、「事業者が脆弱性を意図的に隠蔽している」「発見者の報告を無視している」「すでに攻撃が広まっている」「結果として利用者が危険にさらされている」「公表することによる被害の低減が急務であり、それを促す」といった条件が必要だろう。

仕組み上、メディアは関係者ではない->「脆弱性関連情報を取得した者」に該当するので「お願い」の対象者だと思います。

「国内における脆弱性関連情報を取り扱う全ての皆様へ – 情報セキュリティ早期警戒パートナーシップガイドラインに則した対応に関するお願い –」(9月9日)

経済産業省、独立行政法人情報処理推進機構（IPA）、一般社団法人JPCERTコーディネーションセンター（JPCERT/CC）及び国家サイバー統括室

1.3 リスクとしてどうなの？

Felicaの主な適用領域のひとつである交通系ICカード利用の仕組みとかについては、私は、専門的に勉強していないので、何とも言えないのですが、この脆弱性によって引き起こされる実際の社会的インパクトというのが、何なのか、というのは、チェックしておく必要があります。

「2017年以前に出荷された一部のFeliCaの脆弱性、公開鍵暗号ではなく全カードで共通の共通鍵暗号を使ってきたことがことが原因」(まとめ)

というのが、この脆弱性に関する報道です。なかなか具体的なところは、想像もできないところではあります。

交通系ICカードの利用局面であるいわゆる電子マネーは、そのデータ自体が「支払手段」となるといっているのですが、カード上の残額と、サービス事業者側の徴収履歴との関係は、どうなるのか、ということになります。結局、その仕組み上、システム上のデータが、それ自体として取引されるというこ整理でいいのだろうとは思います。

結局、カード上の残額と、サービス事業者側の徴収履歴かとが相違するだけなので、今回のリスクについては、現実的ではないという分析もあるようです。

2 ケーススタディ

脆弱性情報と報道が関係した案件については、今回のFelica事件以外に2件をあげることができます。

2.1 セブンペイの事件

この事案は、2019年７月１１日午後４時に、新聞社が脆弱性が修正される前だったにもかかわらず、「（セブンペイが）外部ＩＤからのログインを遮断へ、不正利用巡り」という記事を明らかにしたという事案です。時系列的なまとめとしてpiyokango「7payの不正利用についてまとめてみた」（https://piyolog.hatenadiary.jp/entry/2019/07/04/065925）ほか、が代表的と思います。この点についてのコメントとしては、JNSA セキュリティしんだんの記事「（28）公表前の脆弱性の報道を考える（2019年9月17日）」があります(リンク)。

2.2 ワクチン予約システムの案件

これの報道は、「大規模接種ウェブ予約　架空の数字で登録可　券番号も、年齢も」(リンク) です。

新型コロナウイルスワクチンの高齢者向け大規模集団接種のウェブ予約で、実際の接種券に記載されていない架空の数字を入力しても予約ができること

が報道されたという案件です(2021年5月)。

これについてまとめたブログは、「脆弱性の開示の枠組を深く勉強したい人に-ワクチンの予約システムの報道に関して」です。

2.3 その他

誤導報道-サイバー弱点通報窓口、日本整備遅れ　LINEなど一部のみ(2022年11月11日リンク) なとも早期警戒パートナーシップガイドラインに対する無理解を示した報道ともいえます。

あと、この制度を検討していたときに生じた事件として「脆弱性に警鐘？」という報道がされた事件(2003年-報道は、2004年) もありました。

3 「国内における脆弱性関連情報を取り扱う全ての皆様へ – 情報セキュリティ早期警戒パートナーシップガイドラインに則した対応に関するお願い –」(9月9日)を読む

昨今の国内における報道等での脆弱性関連情報の取扱いを踏まえて、今般、経済産業省、独立行政法人情報処理推進機構（IPA）、一般社団法人JPCERTコーディネーションセンター（JPCERT/CC）及び国家サイバー統括室から、国内の脆弱性関連情報を取り扱う全ての皆様（脆弱性関連情報の発見者、製品開発者やウェブサイト運営者、報道機関その他産業界の皆様等）に向けて、「情報セキュリティ早期警戒パートナーシップガイドライン」に則した対応に関するお願いについてお伝えします。

という文言に引き続いて、お願いの文章があります。具体的な文言については、お願い本文をみてもらうことにして、項目としては

「ソフトウエア製品等の脆弱性関連情報に関する取扱規程」（平成29年経済産業省告示第19号）を制定していること
「情報セキュリティ早期警戒パートナーシップガイドライン」を策定して関係者に推奨する行為がとりまとめられていること
脆弱性関連情報の保有者は、その情報を第三者に開示せず、正当な理由により開示が必要である場合も事前にIPAに相談いただくようお願いいしていること

などがふれられ

報道機関その他産業界の皆様におかれても、同ガイドラインの趣旨を理解いただき、公表前の脆弱性関連情報は慎重な取扱いが必要であることをご認識のうえ、報道やSNSでの発信等を通じてむやみに第三者に開示することは控えていただくようお願いします。

とされています。

ちなみに、今後の予定として

昨今の国内における報道等での脆弱性関連情報の取扱いも踏まえて、「情報システム等の脆弱性情報の取扱いに関する研究会」において議論をいくとされていること
サイバー対処能力強化法の施行以降、内閣総理大臣及び電子計算機等供給事業所管大臣の下、脆弱性対応の強化が図られるのに対応して、脆弱性関連情報取扱いの仕組みについても同研究会での議論を通じて必要な見直しの検討を行っていく予定であること

があげられています。1は、いいとして2については、「重要電子計算機に対する不正な行為による被害の防止に関する法律案」等を読む(通信情報の利用等)というブログの2.2.3 脆弱性対応の強化でふれています。
同法の「電子計算機等供給者に対する情報提供等」(42条)で

電子計算機等供給事業所管大臣は、「総合整理分析情報その他の情報」により

脆弱性を認知したときは

「脆弱性に関する周知等用総合整理分析情報その他の情報」を提供するとともに、
当該情報又は当該脆弱性への対応方法について、公表その他の適切な方法により周知することができる
とされています(42条1項)。

脆弱性を認知したときは、となっていて、具体的にどのようにして認知するのか、という点については、特にふれられていないという整理でいいかと思います。現在の早期警戒パートナーシップについては、政府機関にたいして、情報を共有するという仕組みにはなっていませんし、そのようなものではないので安心して調整を依頼してくれませんかという枠組になっていると思います。なので、サイバー対処能力強化法の仕組みと早期警戒パートナーシップの仕組みをどのように位置づけるかというのは、なかなか難しい問題なのたろうと思います。

4 参考文献のまとめ

4.1 基本的な文献

まずは、基本的な文献です

ということで、法律面の調査報告書ももう6年経っていますので、そろそろ改訂の準備をしてもいいかもしれませんね。よろしくお願いします>関係者様

4.2 私のブログ

日本の制度についてふれたもの

IPA「脆弱性届出制度に関する説明会」について(2017/10/21)

このブログですが、脆弱性については、むしろ、開発者が、第一義的に、なくしていく義務を負うのですよ、という点を強調しているものです。

あと、上ででていますが、

「脆弱性の開示の枠組を深く勉強したい人に-ワクチンの予約システムの報道に関して」

もあげておきます。

ENISAの報告書を紹介するもの

米国の協調された脆弱性開示

米国における「脆弱性の協調された開示」(CVD) の歴史と現在

米国においては、Felton v. RIAA事件（2000年）、US v. Sklyarov事件（2001年）などの実例もあるわけです。

「コンピュータ犯罪事項の立件および起訴ポリシー（Intake and Charging Policy for Computer Crime Matters）」(2014年)
DoJサイバーセキュリティ部門「オンラインシステムの脆弱性開示プログラムのためのフレームワーク」(2017)

オランダ

ちなみにOV-ChipkaartというRFIDを利用した交通カードの脆弱性が、2008年に、アムステル大学の学生によって明らかにされたという事件があったのがきっかけというのは、おもしろいです。

4.3 脆弱性の強調された開示についての資料

国際的な組織等におけるガイドライン等

4.3.1 ISO/IEC

ISO/IEC 29147:2018 -.脆弱性となりうる情報を外部の人・組織から受領した場合における一般の業務のプロセス及び影響を受けるユーザに対する情報の伝達

ISO/IEC 30111 報告に対しての処理及び解決の方法に対するガイドラインを記載

ISO/IEC 29147 が、ベンダーと脆弱性の発見者のインターフェイスであるのに対して、ISO/IEC 30111は、脆弱性の調査、トリアージ、解決を取り扱う