「預金取扱金融機関の耐量子計算機暗号への対応に関する検討会」（第２回）議事要旨

１．日時：令和６年９月20日（金曜日）16時30分～18時00分

２．会場：中央合同庁舎第７号館　13階 共用第１特別会議室

４．議事：

（１）開会
（２）日本アイ・ビー・エム株式会社からの説明
（３）株式会社ＮＴＴデータからの説明
（４）作業部会からの説明
（５）意見交換・質疑応答
（６）閉会

５．議事内容：

議事（１）開会

• 寺井座長より挨拶。 

議事（２）日本アイ・ビー・エム株式会社からの説明、（３）株式会社ＮＴＴデータからの説明

• 日本アイ・ビー・エム株式会社より資料１について説明。
• 株式会社ＮＴＴデータより資料２について説明。
• 金融機関においては、各社のパッケージを利用していることがある。PQC対応のパッケージに関する各社の対応について、教えていただきたい。
• 米国では、Post-Quantum Cryptography Allianceというオープンソースのプロジェクトを立ち上げている。通信系のプロトコルやIETFの標準などを取り込みながら、PQC対応のライブラリ等の構築・標準化に取り組んでおり、当該ライブラリ等をベースに、各ベンダー企業が提供されるソフトウェア群に、当該企業の製品ロードマップに従って、PQC対応の機能が埋め込まれていくことになる。
• PQC対応ライブラリは、基本的には、SaaS型クラウド、通信系のソフトウェア、OSのモジュールなどの製品に紐づいて実装されていく。金融機関自身が暗号化ライブラリを使ってソースコードを書いている場合は別だが、基本的には、商用製品を使っている場合は、その製品を提供しているベンダーが、いつ頃PQC対応の製品を提供するのかを注視しながら移行計画を判断するとよいのではないか。
• 顧客ごとに要件定義をして、サービスを設計・開発する中で、様々なパッケージを活用する場合や、求めるパッケージがなければ、OSS（オープンソースソフトウェア）から自ら開発する場合が考えられる。商用の暗号化ライブラリの状況については、米国NISTのNCCoE（National Cybersecurity Center of Excellence）といった、PQC普及のためのコミュニティに入っている企業と定期的に意見交換を行い、PQC対応パッケージのリリース時期や機能を把握することが考えられる。アプリケーション開発において、各種製品の中で使われている暗号については、そのソフトウェアのライブラリでどのようなものが使われているかを把握するために、SBOM（Software Bill of Materials）取得と同時にCBOM（Cryptography Bill of Materials）も取得し管理するという方法があり得るのではないか。
• ベンダー各社の提供製品・サービスのPQC対応の計画の有無や公表時期はどうか。
• 商用製品・サービスのPQC対応に係るロードマップを定期的に更新し、公表している。例えば、メインフレームについては、既に、ハードウェア・ソフトウェアのPQC対応は済んでおり、それ以外のクラウド、ストレージなどについても2024年以降、順次対応していく。当社が商用で提供している製品・サービスは、基本的にすべてPQC対応を進めていく方針。
• ハードウェアの開発は行わず、市場の様々なソフトウェア、ハードウェアを組み合わせて付加価値を創造する形で事業を行っている。その中で、例えば、当社が金融機関向けに提供している共同プラットフォームにおいて、PQCに対応するクライアント証明書を参加企業に対して発行できるように、今後、技術検証に着手する予定。
• これから金融機関が検討する中で、PQC対応のロードマップを作成していく必要がある。それを考えるうえで、いつから、あるいはどういった条件が整えば、製品のユーザー企業たる金融機関側でシステム改修に対応できるようになるのか。
• いつから開始しうるのか、という点について、各金融機関において、リスクの影響度が大きい部分にどのベンダーの製品をどのように使っているかに関係してくる。様々なベンダー企業がシステムを金融機関に提供しているという前提を踏まえれば、各金融機関のロードマップの中で必要な情報を取得の上、システム移行の開始タイミングを判断していくことになると考えられる。
• 金融機関において、APIエコシステムなど対外的な接続がある部分や、インターネットバンキングなど顧客と接点がある部分について、仮に一番最初に危殆化するのがRSA署名だとすると、非常に影響が大きい。今すぐにPQC対応に着手するのであれば、各金融機関の重要なシステムについて、暗号アルゴリズムがどのように使われているか、例えば、危殆化された時の影響を整理するのがよいのではないか。製品の置き換えは今後見定めていくことになるのだとしても、ロードマップの作成はすぐに着手するのがよいのではないか。
• 本年8月に米国国立標準技術局（NIST）から、FIPSの203、204、205（事務局注：NISTが2024年8月に公表したPQCアルゴリズムの標準）が公表されたので、これからベンダーがこれらの標準に準拠した製品を出すと考えられる。

議事（４）作業部会からの説明、（５）意見交換・質疑応答

• 今回の検討会での議論は、金融業界を挙げて対応してきた。金融分野以外も含め、重要インフラ全体で考えるべき話と認識している。息の長い話であり、今後、金融業界のみならず政府全体の問題として捉え、本検討会の成果物が活用されるような形としていくべき。
• 各重要インフラ分野で今回の検討会のような議論を個別に行うのは非効率。国全体の対応のロードマップを作り、それを各重要インフラ分野が特性に応じてカスタマイズするのがよい。金融分野でもロードマップを作り、それを各金融機関がカスタマイズして計画を立案する形が効率的。米国はそのように進めている。かかる点を、今回の成果物に課題、提言として盛り込んでほしい。
• ステークホルダーに働きかけていく際には、金融業界での対応のロードマップを作成し、課題を明確にすることがまず必要。課題に基づく働きかけの意義が明確でないと、ステークホルダーに対する説得力がない。今回の成果物は、金融機関の経営層に課題を認識してもらうという位置づけ。ロードマップ作りのための体制を別途整える必要がある点も、本検討会の成果物に盛り込んではどうか。
• 移行期限の設定については米国政府の動向が鍵となる。2035 年までに連邦政府機関システムにPQC 導入を予定しており欧米の金融機関はこれに追随するであろう。日本の金融機関がこれに間に合わないと、グローバルな金融システムに接続できなくなるリスクがあり、2035年が目途とするのが妥当。論点整理（資料３）では、「2030年代前半から半ばを目安にPQCのアルゴリズムを利用可能な状態にすることが妥当」としており、これも成果物に盛り込んではどうか。
• （事務局）インターネットバンキングなどのシステム上顧客との接点が相当程度ある点や、国際送金システムへの接続がある点などの他分野との違いを踏まえると、金融分野は他分野と比べてリスクが高い部分がある可能性があり、金融業界として、先陣を切るつもりでいる必要があるのではないか。
• （NISC）政府として重要インフラ全体への導入が決まっているものではないと認識しているが、他方で、重要インフラの取組みを進める際、全体を見ているNISCの役割を認識している。業界ごとの特性も踏まえる必要。CRYPTREC暗号リストとの関係といった論点もある。関係者と連携していきたい。
• 国際的なネットワークの点を含め、影響の大きさでは金融が先行するという点は事実としてある。一方で、ITベンダーや通信の事業者が、妥当な形で金融業界にサービスを提供するうえで、金融分野だけでは難しいし、様々な省庁が関係してくるはずであり、司令塔となるところはどこなのかを議論しないと、これだけの大きな話は進まないという認識を共有したい。
• 欧州委員会から「PQC移行協調実施ロードマップ」の作成を促す勧告が出ている。欧州では公開鍵暗号技術を使ったマルチステークホルダーによるプロジェクトが多数存在するが、この際、さまざまな産業分野の協調が重要になり、そこにはPQC移行においても協調した取組みが必要になる。公開鍵暗号が今後どのように使われていくかという点が重要。2035年には、公開鍵暗号が今と全く違う使い方をされている可能性があり、そのためにも協調してPQCへの移行を進める必要がある。単にPQC移行ということではなくて、今後作っていく社会のビジョンに従って、公開鍵暗号技術を利用し協調していろいろなものを動かしていき、そこにPQCも含まれていくという姿が望ましいのではないか。今後、協調しないといけない領域がさらに増えていくだろうということを、本検討会の成果物において強調していきたい。
• PQC対応は個別金融機関への負担が大きい。不確定要素が多い中で対応を進めていかなければならない。業界で足並みがそろわないと、金融インフラの安定性に影響を与えるので、ロードマップを皆で共有して進めていくことが重要。各社の事情だと、予算の取り方などいろいろなことが関わってくるので、共通の枠組みが必要。論点整理（資料３）に記載のコンティンジェンシープランの点は非常に重要だが、現実的には各企業でPQC対応に関するコンティンジェンシープランを作るのは困難を伴うこともある。後ろ向きな形でコンティンジェンシープランを作らないといけなくなったときに、私企業に任せるという形では統制がとれなくなる。したがって、皆で一つの方向に向かって取り組む仕組みが必要。
• PQC対応は、ソフトウェアを取り換えるということにとどまらないことに留意が必要。米国NSAの早期に対応するべき要件（事務局注：Commercial National Security Algorithm。国家安全保障上の情報資産を保護する暗号に関する要件）の中に、ファームウェアの署名という点がある。いったん出荷したデバイスは、公開鍵暗号がハードウェアに組み込まれているので、交換できない。金融分野だとキャッシュカードなどが該当する。現在の暗号技術は、ハードウェアに組み込まれていることが多い。今後、民需製品でもこうした要件が要求される可能性がある。
• 国際的な送金システムへの接続の点について、SWIFTについては、Customer Security Controls Frameworkのセキュリティ要件があり、暗号については、一般的に受け入れられている暗号方式が求められている。今後、こうしたフレームワークにおいても暗号要件が変更されるというステップがあると考えられるので、検討会の成果物には、その点も補足した方が分かりやすいのではないか。
• 金融機関だけでは対応できないというのがポイントの一つ。金融業界の中でも、金融業界全体のロードマップの共有が重要である。本検討会の成果物の目的は、金融機関の経営層のアウェアネス向上が第一目的であるが、これで終わりではなく、業界として、継続的に考えていくことが重要である。その中でNISCや金融庁とも議論しながら進めていくべきである。

議事（６）閉会

• 成果物のドラフトを9月末に検討会参加者に共有し、必要に応じてオンラインで意見交換等もさせていただきたい。それも踏まえて、10月18日に第3回検討会で議論することとしたい。成果物は、第3回検討会までに完成させるのは難しいので、第3回検討会以降もご意見をいただくこととし、公表は11月となることも想定したい。

――　了　――

お問い合わせ先

金融庁　Tel　03-3506-6000（代表）

総合政策局リスク分析総括課ITサイバー・経済安全保障監理官室（内線2217、3850）