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

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

日時:平成28年3月25日(金曜日)13時00分~15時00分
場所:経済産業省本館7階商務情報政策局会議室1

出席者(敬称略)

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

配布資料

  • 資料1 調査報告書(平成28年3月25日版)

議事概要

事務局より、資料について説明が行われ、下記のような質疑応答があった。

利用者認証用途の電子証明書について

  • 利用者認証用途の電子証明書の議論について、昨年度の検討会でも行ったが、今の認定認証業務で使っている認証局の秘密鍵でもって利用者認証用途の電子証明書が発行できないという問題がある。今年度行った属性ガイドラインのように、認証局会議が主導してガイドラインを作成すればいいのではないかという議論もあるが、事業者の認識としては、利用者認証用途の電子証明書がどうあるべきかというガイドラインがないから利活用が進んでいないわけではないと認識している。現時点でも、一般的なガイドラインはあるため、別途、属性ガイドラインのようなガイドラインが必要というわけではないと認識している。
  • 電子署名法には米国の市場モデル型とEUの規制モデル型があり、日本はEUの規制モデル型に近いが折衷案でもあると認識している。規制モデル型は、世の中の技術の進歩に合わせて法律を変えて行く努力がないと、法律自身がイノベーションや新たなビジネスを阻害してしまう可能性がある。また、日本の電子署名法は、EUと異なり官民で法律が異なる。今回、官側の法律は変わったが、民側の法律は何も変わっていなくてよいのかに疑問がある。個人情報保護法も同じ問題があり、例えば自治体ごとに個別の条例が多く存在し、これらの条例が情報連携を阻害している面がある。EUにおいて電子署名の法律が各国バラバラな方向に進むとEUでいうデジタル単一市場におけるボーダーを超える流れを阻害するということもあり、電子署名指令から、より強制力のeIDAS規則へ向かった。昨年度の電子署名法研究会でも議論になったが、何故、JPKIで利用者用証明書が必要になったのかを再度振り返る必要がある。官民の個別の検討で動いているのがよいのかというのを考え直す時期に来ているのではないか。
  • 利用者認証用途の電子証明書をどのように法体系に埋め込むかは大きな問題である。電子署名法に利用者認証用途を付け加える必要があるとは思うが、法改正は必要とされるがなかなか動かせないだろうというのが第一感である。また、ガイドラインの作成については、その意義が重要であり、ガイドラインに沿っていればどういう意味があるのかを考えないと、作成しても作りっぱなしになってしまう可能性がある。ガイドライン作成するのであれば、そのガイドラインは、どういう意味があるのかを考えるのが先決ではないか。
  • 昨年度の属性ガイドラインも法改正まで目指すとかなりの時間がかかるので事業者でガイドラインの作成を目指してはどうかという結論に至った。今回の利用者認証用途の電子証明書も同じで、ガイドラインを目指するというのは、ある種、実を取った進め方であると理解している。属性ガイドラインと同じような建て付けで進めるのだと思うが、そのガイドラインは、どこまで担保されるのかという問題がある。最大の問題は、利用者認証用途の電子証明書を同じ認証局の鍵、同じルートから出せる/出せないという点である。認定認証業務は署名用途以外を出すなという壁があり、同じルートから出せるのかという問題がある。何らかの解釈で出せるようにしたとしても、同じルートから出せないと使いにくいものになる。
  • 法改正は厳しいところもあるところ、属性ガイドラインのような形であれば、検討の余地はあるが、どこまでの効力が担保されるかが不明でありニーズが乏しいということであれば、今年度の議論の成果としては、一定程度のニーズはあるが、現行の法改正を行うほどのニーズはなかったといった形で整理することになるか。
  • 署名法の法改正の範囲の中で、指針や施行規則が色々とあるが、全部を指しているのか。
  • 利用者認証用途の電子証明書については、電子署名法における定義規定に関わる話でもあり、それを変更するとなれば、やはりマイナンバー制度と同様に法改正を行うべきと考えられる。法改正についてはニーズがあれば検討するということになるが、今回行った事業者アンケートでもニーズを認める意見が85%と決して少なくはないが、事業者サイドでも100%がニーズを認めなかったという調査結果でもあり、早急に法改正が必要という結論には至らないと考えられる。
  • 昨年度の研究会でも議論したが、特定認証業務の認定に係る指針10条を改正できないのかという論点もある。同じ認証局の署名鍵から利用者認証用途の電子証明書が出せないという課題は、指針を変えれば解決できるようになるのではないか。
  • そのご意見は、仮に実現しても電子署名法の適用を受けるものではないが、先ほどのガイドラインと大体同じような扱いで同じルート、同じ認証局から出せるようになるに留まるだろうが、それでよろしいのか。
  • 利便性が増すという意味で、望ましいことではないかと考えている。
  • 指針レベルの改正であれば検討の余地はあるのではないか。マイナンバー制度では、認証も行うところ、官民のバランスを考えると、民間側の法律がない状況である。話は変わるが、利用者認証用途の電子署名制度について、別途立法を行うことは可能だろうか。禁止であれば厳しいが、禁止でないとすれば今でもできるのではないか。電子署名制度を取り巻く環境も変化しているところ、そのあり方をもう一度整理した方がよい。
  • 利用者認証用途の電子証明書については、昨年の結論から、まずはそのニーズを把握することになり、本年度アンケートを実施した。来年度はリモート署名の議論を具体化する作業を予定しており、検討に要するボリュームも相当なものになると思われるので、議論の優先度はそちらが上だが、状況を見ながら、検討項目の一つとして引き続き検討をしたい。

リモート署名について

  • バックアップとは、HSMの中の共通鍵のことを言っているのか。
  • HSMの中の利用者署名鍵のバックアップをイメージしている。
  • 利用者の署名鍵はHSMの中に置いていない。共通鍵で暗号化した状態でハードディスクに展開している。HSMの中には自身が持つ共通鍵しか入っていない。バックアップとは自身が持つ共通鍵のバックアップではないのか。
  • EUのTS 419 201においては、システムのセキュリティだけでなく、運用についても述べられている。HSMの鍵に関しては、バックアップをすることは認められている。
  • Sole controlレベル1やレベル2とQualifiedの関係はあるのか。
  • 詳細な記述があり、入手できるのはCEN/TS 419 241しかないと認識しているが、このTS 419 241では、レベル2はQCを用いた証明書をリモートで使うことを想定していると記載されている。
  • レベル2がQualified相当の基準だと理解した。
  • 署名生成ログについては、目的としては、本人以外が使っていないと示すことであろう。署名鍵を使う処理全体について、ログがあった方がよいのではないか。
  • 言葉の定義について資料を読んで考えていたが、レベル2はレベル1を包含していると考えてよいのか。
  • レベル2の要求事項はレベル1を含む。
  • レベル2は、署名の時以外にも鍵生成、鍵廃棄、保管といった要件がある。そういったことであれば、関係性も含めて理解できる。
  • 要するにレベル2が妥当だという意見であるか。
  • 今回の結論としては、レベル1以上といった方が適切ではないか。レベル2とすると厳格すぎる可能性があるので、現時点で安全かつ現実的であるかについて十分に精査したとは言えない。
  • レベル2相当の文書の書き方の問題もあると思う。鍵生成のログことが必須と規定されると困る場合もある。署名鍵をインポートした場合、署名鍵を生成したログは、事業者の外側にあることもあり得る。
  • ご意見のとおり、この部分は、現段階ではレベル1以上とすることが妥当であろう。
  • 資料の整理の仕方だが、EUのモデルと本検討会の検討モデル図をどのように関連付けていくのか。
  • ニーズ調査を行った際に、各事業者にどのような構成でどのような機能を提供しているのかを確認している。また、どのようなプレーヤーがいてリモート署名を実施しているかについても確認した。EUのモデルを参考にしながら、国内の事業者のヒアリング結果を反映させ、検討モデル図を検討した。また、EUのモデルでは、SCDevがハードウェアのように見えるという点にも指摘があったため、ソフトウェアとしても理解できるような構成にしている。
  • 一見したところ、それぞれの図はかなり異なる。何故、このようなモデルに至ったかについては説明すべきである。鍵のライフサイクルと署名検証までを含めた署名のライフサイクルを取り込んだのが検討モデル図になるという理解でよいか。EUのモデルを参考にしつつも、調査の中でそういった全体的なところまで視野に入れて検討することが必要になることが分かったため、この検討モデル図を作成したという流れだと理解している。調査と結び付けてこの検討モデル図が出てきたことを示すことができればよいと思う。
  • 国内で調べたものは全く出せないのか。国内ではデバイスではなくてソフトウェアレベルで実施しているものがあるというのを考慮したと言えるのであればさらなる理由付けになる。
  • ソフトウェアかハードウェアかという点については、システム構成図や営業資料の構成図を見ながらインタビューを実施した。このような資料では、ソフトウェアで実施と書いている事例は少なく、サーバ側で管理しているという記述が大半であった。図で示されたものは少なく、また公開できる資料であるかは、各社に確認する必要もある。一方、米国の調査結果ではソフトウェアで実施しているという例もあり、この結果は報告書に記載している。
  • その結果を再度記載し、ソフトウェアモデルも対象にした記載すればよいと思うが、個々の事業者の具体的な構成を示す必要はないか。この検討モデル図が大事であるため、読者が重要であると理解できるようにすべきである。
  • SCDevは何かといった用語の定義が十分に書かれていないため、丁寧に記載した方がないのではないか。ハードウェアだけではなくソフトウェアも対象となることを理解できる必要がある。
  • 4.1.8の表の中の説明を拡充すればよい。
  • リモート署名とサーバ署名の定義や整理については、資料の冒頭で示してはどうか。
  • 本日の議論を踏まえ、事務局でこれから報告書を修正するが、最終的には調整や時間的な制約から座長一任とさせていただきたい。

自由討議

  • 本年度の研究会においてもトラストリストの議論があったが、今後の進め方等についてご意見はないか。
  • ポイントは、機械可読で自動的にトラストパスが作れるのであれば、トラストリストであろうと、PKIのトラストツリーであろうと良いということである。一点、気になるのは、マイクロソフトのWindowsやAdobeなどの特定のプロダクトやプロジェクトに依存するトラストパスが存在する点である。この点については何かできないか。
  • EUも同じ問題を抱えているだろう。ETSIなどでの標準化の動きがみられるが、日本では動きはない。
  • マイクロソフトやMozillaなど各社の問題とも見ている。マイクロソフトは迅速な処理に変わっている。Mozillaは3年かけてもトラストにCAを入れないという問題もある。働きかけをすることが必要というのはそのとおりであるが、基本的にはルートのオーナーが直接行わなければならないため、ここで日本での対応は難しいというのが現状ではないか。
  • EUは、EUの中で認定のための基準を作っていて、Qualifiedな電子証明書をeIDASの中で定義している。EUとして各プロダクトにEUのトラストリストを入れ込むアプローチするのではないか。
  • ETSIのQualified Certificateについていえば、ウェブ証明書も、自然人に発行する証明書も、法人に発行するe-Sealの証明書もみな同じ認定の枠組みになりつつあり、同じ枠組みでウェブも自然人も法人の証明書発行できる。日本においては、そういった主体ごとに、バラバラに認定を取らなくてはならないという点が異なる。
  • 自国内の認定の見直しであれば自力でできるが、相手がマイクロソフトや日本以外の国に軸足を置く国際的な企業に対して、日本がどうアプローチするかということも検討が必要である。EUで動きがあれば学ぶ価値がある。どのような取り組みを行うと、マイクロソフトや各社に対してどのようなインパクトがあるのかという情報収集も必要であろう。
  • EUはどうなっているのか。
  • eIDASではトラストリストのフォーマットに関する規則が昨年度に定められた。eIDAS以前のドイツの署名法は署名アプリケーションが製品認定の範囲内であった。認定を受けて、ドイツのトラストリストに載っている認証局から発行された証明書を検証できる製品でないと、使ってはいけないということである。eIDASではそこまでは求めてはいないようである。検証サービスというトラストサービスが提供されていて、このサービスを用いて署名を検証することはできるので、検証サービスはトラストリストまで検証をかけるのではないか。
  • これが、なぜeIDASが出てきたかという一つの理由でもある。eIDAS規則以前の電子署名指令は、強制力に乏しく各国バラバラな方向に向かった。これを強制力のある規則・レギュレーションにしたのがeIDAS規則である。この強制力のある規則がない限りはトラストリストの意義も低かった。
  • トラストリストをマイクロソフトやMozillaが入れることがキーポイントだと思っている。EU型でやっているトラストリストも最後にこの段階で止まってしまうのではないかと心配している。
  • EUもいろいろな検討を含め活動している。日本においてもトラストサービスの議論を並行して実施すべきではないか。
  • 気になるのはe-Sealがどのように使われるかという点である。e-Sealの具体的な利用については、EU内においても混乱しているように見えている。これは自然人による署名ではなく、IoT機器等が打つ署名に近い。自然人の署名ではなく、IoT機器が署名し、署名者は法人であるという形で、自然人の厳密な意思の証明という現在の電子署名法とは真逆の形とも言える。
  • 署名をするにあたって、企業側にどういった管理が義務付けられているかということが重要である。
  • 人間が行う署名の世界からIoT機器が署名をしていくという世界に広がっていく。この世界をどうやって吸収していくか。企業が企業印を押すのと同じイメージで、厳密な自然人までの確認はないが企業までの確認を行い署名することにEUは担保し始めている。それがe-Sealという概念で認める動きになっている。
  • A社での管理の度合いとB社の管理の度合いが異なる場合には困ることになる。両社の管理が異なるため、何をもって信じるかというのがわからない。意思表示とは言わないまでも、そのような運用、管理も含めた整理が必要なのでは。どのような管理が必要かというコンセンサスを取ることが重要である。
  • 制度的に整えばボトムラインが見えて、EU域内で共通に使えるようになる。どれだけトラストなサービスをもたらすかという時に、電子署名の技術を活用し、如何に広がりを持たせられるかということになるのではないか。
  • トラストサービスは検証の問題もある。
  • トラストリストは、活用方法に三つの段階があると考えている。最初は、機械でも自動検証できる段階であり、マイクロソフトやAdobeにどのように取り組んでいくかという自動的な利活用の段階。もうひとつはEUで始まった域外連携のような利用。さらに、日本では、現在、信用できる事業者であることは確認できるが、過去にさかのぼって確認するという利用。署名法の認定認証業務で仮にトラストリストが作成されていて一連の制度ができると、署名法の認定制度からは外れるが、e-Sealからの認定基準を作れば、署名法の認定制度の基準は満たさなくてもトラストリストを満たした基準だとわかれば、どのレベルでやっているかが分かるようになる。将来に向けての検討課題や山積みだが、これらの検討は望まれているのではないか。
  • 今後の電子署名の普及については技術論、運用論、制度論を十分に議論する必要がある。特に、EUでは引き続き検討を進めている状況であり、来年度についてもこれらの動向や具体的な検討内容を踏まえ、日本国内においても技術論と運用論をしっかりと検討すべきである。

以上

関連リンク

お問合せ先

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

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