経済産業省
文字サイズ変更

電子署名法研究会(平成27年度第3回)‐議事要旨

日時:平成28年2月22日(月曜日)9時30分~11時30分
場所:経済産業省別館1階104共用会議室

出席者(敬称略)

構成員
手塚委員、大澤委員、小田嶋委員、中村委員、西山委員、松本委員、宮内委員、山岸委員

配布資料

  • 資料1 サーバ署名の機能及び論点
  • 資料2 サーバ署名に求められる機能の一覧
  • 資料3 サーバ署名の構成要素とセキュリティ対策例
  • 資料4 サーバ署名における鍵管理・本人性確認の考え方について
  • 資料5 調査結果(案)
  • 参考資料1 公的個人認証サービスの概要について

議事概要

サーバ署名の機能等について

事務局より、資料1、2を用いたサーバ署名の機能等についての説明が行われ、下記のような質疑応答があった。

  • 資料2には、米国の方が参考になると記載されているが、米国の電子署名法は市場モデルであり認定スキームが無く基準と呼べるものも少ない。一方、欧州はQCに適合した基準を作っているので、日本のスキームは欧州の方に近いのではないか。米国の方でAATL(The Adobe Approved Trust List)の例が掲載しているが、ここに記載されるのは違和感がある。AATL はAdobe自体の活動であり、米国政府等とは関係が薄い。Adobe社自体も電子署名に関しては、米国というよりは欧州で活動しており、欧州の電子署名法令に合わせるためにこのような動きをしているとみている。
  • ご指摘のとおりである。電子署名認証ガイドラインで参照されているものが、認証系の利用目的のため参考になると思っている。一方で、事業者にヒアリングをしたところ、AATL(Adobe)は実際問題として無視できないという意見も聞いているので、そのようなニュアンスが分かるように修正したい。

サーバ署名における鍵生成・管理、本人確認等の在り方について

事務局より、資料3、4を用いたサーバ署名における鍵生成・管理、本人確認等の在り方についての説明が行われ、下記のような質疑応答があった。

  • 以前、ご説明があったとおりHSMで全て処理を行うケースだけではなく、DBに暗号化した鍵を保存するケースもある。このケースについて、どのような整理になっているか。
  • HSM内に唯一存在する鍵によって暗号化された状態でHSM外のDBに保存している場合はHSMと同等と考え、HSMを利用したケースと整理している。
  • 「オンライン手続きにおけるリスク評価及び電子署名・認証ガイドライン」のレベル3、4という観点では、どうなるのか。
  • ガイドラインのレベルを説明すると、認証用途のトークンの定義のレベル4にはHSMが入っている。また、レベル3はソフトウェアトークンになる。一方、ここでいう署名機能としての定義はない。
  • 電子署名法第3条の「符号および物件を適正に管理する」という意味は、署名者が管理するという意味合いである。HSMで管理するのと自分で管理していることが同等とみなせるように作れるかどうかにポイントがあるとみてよいか。その意味では、登録や認証の方法は、本人が管理するのと同等な状態に持ってくるには、何が必要かという議論を行うとみてよいか。これは厳格にやらねばならず、レベル3でよいのかというのは疑問で、厳格にしないと自分が管理しているものと同じとはみなせないのではないか。
  • 現状の利用可能なテクノロジーや実際に利用している技術的な状況として、レベル2とレベル3の間はかなりギャップがあると感じているが、レベル3とレベル4を厳密に見ても大きな違いがないのではないかと認識している。
  • 資料3をみると、レベル3とレベル4の違いを含めて記載されているが、大きく違うのはどこか。
  • 発行の保証レベルや、遠隔を認めるかどうかが異なる。
  • 発行や認証プロセスのあたりや、トークンの部分が異なる。SP800-63と同じシリーズで、ISO化されているドキュメントがあり参考になるだろう。ISO/IEC 29115のEntity authentication assurance frameworkである。このドキュメントでは、認証を“Something You Have”(SYH)、“Something You Know”(SYK)、“Something You Are”(SYA)の3つに分類している。レベル2までは、SYK、SYAのどちらかになる。レベル3になると、SYHが入り、SYK、SYAのどちらかと組み合わせる形になる。SYHは、単に「物」を指しているわけではない。発行時に所有している物を登録するなども含まれる。
  • 今の説明は、世の中の認証プロセスについて、特に民間で広く認識されているレベルや実際のサービスにおいて利用されているレベルもある。このようなレベルを検討する場合にSYHだけでなくSYK、SYAの組み合わせとなっているものをどう捉えるかという問題でもある。レベル3とレベル4に大きな差異がなく、レベル3に相当することを指針等に具体的に規定する場合は、レベル4を記述する必要はなく、レベル3以上を許容しておくべきではないか。
  • ログインの認証トークンをどうするのかというのはしっかり考えるべきことである。例えば、利用者登録方法と利用者認証方法の間でこれを検討することが必要なのではないか。利用者認証方法に含まれているのかもしれないが。
  • 単純に証明書発行の審査のレベルは、サーバ署名であろうと、利用者のICカード署名であろうと、特段の差異はないと認識している。
  • レベル3、レベル4も登録の際は本人確認をしっかり行うということに変わりはない。また以前に議論したとおり、この本人確認にマイナンバーカードを利用することは可能である。

調査結果(案)報告

事務局より、資料5を用いた調査結果(案)報告の説明が行われ、下記の質疑応答があった。

  • 資料5の10頁は鍵生成について記載されているが、その1-1は、CAからサーバ署名提供者に依頼するパターンと考えられる。このパターンで、認定認証業務が、外部に鍵生成を依頼することができるという整理するのであれば、その理由としては、CAはメッセンジャーに過ぎず、署名者がサーバ署名提供者に発行を依頼しているのを伝達しているだけと考えるべきではないか。その場合、サーバ署名提供者が署名者の本人確認までできないと、メッセンジャーとして不十分である。
  • 具体的に考えると、認証業者はRAの役目をしていて、登録すると同時にサーバ署名のRAの登録業務を兼ねて行っている。さらに結果として合わせて鍵の生成を行っていると考えれば、この事例は理解できる。
  • 鍵生成の流れを捉えなければならない。その中で、認証事業者とサーバ署名提供者にどういう組合せパターンがあるのかをマッピングして検討すれば網羅性が出てくる。これは、セットで考えなければならないが、今回は本人確認ができた前提で検討する。
  • 本人確認のやり方の問題ではない。本人確認をサーバ署名提供者が確認しなければならないかということを意味している。鍵が来たときに、サーバ署名提供者は、署名者の代理人として動いている。代理人だということも、CAにとって納得できるものが出てこなければならない。
  • 鍵生成のパターンがいくつあるのかというのと、本人性は誰が責任を持つのかというのを、組み合わせて議論しなければならない。サーバ署名の時は、本人性の確認は誰が責任を持つのか。
  • 認証局として鍵生成を行う場合であるが、欧州では、Sole Controlのレベル1と2に分かれている。レベル2は、トラストサービスプロバイダの中でもQTSP(認証局適格サービスプロバイダ)でなければ提供できないという署名生成サービスである。これとは別に、QTSPを別のトラストサービスとして、証明書を発行するトラストサービスもあり、その証明書を使うケースもある。一つのトラストサービスプロバイダが複数のQTSP(リモート署名サービス、証明書発行サービス等)を行っていると考えれば問題ない。
  • サーバ署名提供者が鍵生成を行う場合はどうか。
  • 調査を行っている範囲では、そのような要求事項は今のところ見当たらない。Sole Control 2の中に鍵生成の要求事項は含まれている。鍵生成はHSMの中で行い、鍵はHSMの中で保管しなければならないというものがSole Control 2である。Sole Control 1であれば、HSMから外に出すことも認められている。ただし、同等以上の暗号アルゴリズムで保護する必要がある。
  • サーバ署名提供者は、サービサーである。それに対して、CAは、鍵と証明書を提供する機能である。アーキテクチャ的に考えると、責任分解点含め、鍵生成するというのは、どのように考えるべきか。最終的にはHSMがあるのは、サーバ署名提供者のためであり、ここに何らかの形で最終的にはものとして入ってこなければならない。(資料5の10頁)1-1であれば認証局からインポートすることになる。
  • 機能としては、(資料5の10頁)2-1の時にサーバ署名提供者は、日本で言う認証事業者も兼ねているということになるか。
  • 要求事項として、レベル2のリモート署名を提供する事業者は、QTSPでなければならない。かつSole Controlのレベル2を満たさなければならない。リモート署名の提供者としての要求事項に証明書を発行することは記載されていない。鍵の生成は記載されており、おそらく一つのトラストサービスプロバイダが認証局も持っているし、リモート署名を提供することを想定されている。
  • 両方の機能を持っているのが(資料5の10頁)2-1で、インポート型は別々の事業者でできる。ビジネスモデルが異なると考えて整理すべき。認証事業者とサーバ署名提供者の分けた構造で、署名者がサーバ署名提供事業者に依頼すると、サーバ署名提供者が認証事業者に鍵生成を依頼し、生成した鍵をサーバ署名提供者にインポートするパターンであろう。これとは別に、署名者自身が既に所持している鍵をサーバ署名に利用したいというケースもあるのではないか。さらに、もう一種類は、認証事業者とサーバ署名事業者が一体になって、鍵生成を依頼するとHSMで生成するパターンもあるだろう。このようなパターンに整理ができないか。良いか悪いかは別として網羅的にパターンを挙げて、許容できるかを検討する必要がある。
  • 署名法上の構造で議論するとサーバ署名提供事業者と認証事業者を一体にするのは考えにくいのではないか。
  • 一番のポイントはインポートをどう考えるかに繋がるのではないか。インポートを認めないとなると両事業者を分離できないのではないか。
  • 私は、インポートを認めなくても分離できると考えている。サーバ署名提供者で鍵を作り、公開鍵はどこにでも出せる。例えば、本人に公開鍵を渡し、公開鍵で証明書を作ってくださいとCAに出すことはできる。署名法上もできると考える。方法はいろいろと考えないといけないが、分離はできると考える。
  • 私もできないとは言っていない。リモート署名という表現で考えると大変わかりやすい。自分のエージェントとして、サーバ署名提供者がいる。離れているけれど、これは私の世界ですと言える。CAから見たら一体となって鍵を生成して、発行すると考えると整理ができる。認証局からすると今までのビジネスモデルと異なる。

以上

関連リンク

お問合せ先

商務情報政策局 情報セキュリティ政策室
電話:03-3501-1253
FAX:03-3580-6073

最終更新日:2016年3月25日
経済産業省 〒100-8901 東京都千代田区霞が関1-3-1 代表電話 03-3501-1511
Copyright Ministry of Economy, Trade and Industry. All Rights Reserved.