電子署名法研究会（平成28年度第2回）‐議事要旨

日時：平成28年12月22日（木曜日）15時00分～17時00分
場所：経済産業省別館1F101-2各省庁共用会議室

電子署名法研究会構成員（敬称略）

手塚構成員、大澤構成員、長尾構成員、永田構成員、松本構成員、松本構成員、宮内構成員、茗原構成員

• 議事次第
• 資料1　構成員名簿
• 資料2　リモート署名検討の全体像について
• 資料3　リモート署名検討モデル概要
• 資料4　リモート署名検討の論点について
• 参考資料1　リモート署名検討の参考資料
• 机上配布資料1　論点整理表

(1)　全体像の説明について

事務局より、資料2を用いて「リモート署名検討の全体像について」の説明が行われた。

(2)　検討モデルの説明 (3)　検討の論点について

事務局より、資料3を用いて「リモート署名検討モデル概要」、資料4を用いて「リモート署名検討の論点」について説明が行われた。これに続いて、下記のような質疑応答があった。

資料3についての質疑応答

• 3．利用者の姿勢からの各種フローについては、「署名鍵の生成」と「クレデンシャルの発行」は独立に考えるのか。クレデンシャルの発行と署名生成の際の利用者認証の関係はどうなっているのか。
• 「署名鍵の生成」と「クレデンシャルの発行」は独立である。初回登録時にクレデンシャルの発行を行い、これを利用して利用者認証を行う関係である。
• 3ページの図において、リモート署名提供者は秘密鍵の生成をどこで行うのか。
• 署名生成モジュールで行うことを想定している。
• 秘密鍵のやりとりをする際にはSAPを通るのか。もし通るのであれば、SAPの要件に鍵の受け渡し機能が必要である。通らないのであれば、受け渡しのための独自の仕組みが必要である。
• 秘密鍵を生成した後に公開鍵リクエスト専用モジュールがあり、適切な通信経路が独立して存在した方が良いと考えている。認証局に対して公開鍵証明書をリクエストする経路を検討する必要がある。
• 昨年度の検討では鍵がSAPを通らずに認証事業者を経由するパターンであった。
• セキュリティに関する機能をSCM自体が持つことになる。
• SCM自体でセキュリティ機能を持つ必要があるのは、秘密鍵を外部から入れる場合であり、秘密鍵を内部生成してリクエストを出す場合は、公開鍵証明書が返されるだけなので、セキュリティ上のリスクはそれほどない。
• 3．利用者の姿勢からの各種フローの(2)署名鍵の発行の部分における「鍵の発行」の意味が曖昧である。通常発行とは鍵の生成と証明書署名要求を分けて考える。鍵を自己が生成する場合と認証局で生成する場合とでプロセスの順番は変わるかもしれないが、必要なモジュールは変わらないはずである。
• 署名鍵とクレデンシャルを誰が受領するのか分かりにくい。
• 誰が受領するかは場合によって異なるため書きづらい。
• 図示する際には、プレイヤ間での役割が明確になっていると分かりやすい。全体像に出ている4者の関係性が見えると良い。
• 既存サービスのクレデンシャルがあったとしても、今回のリモート署名用のクレデンシャルのレベルに達しているのかは重要なポイントである。
• 文書サービスから直接署名アプリケーションに送られてしまうと、ユーザーが正しいファイルに署名できたのか検証できない。意図していない文書に署名してしまう可能性がある。
• 中間者攻撃を受けた場合にはありうるケースである。これを防ぐために、署名者自らが署名検証結果を確認するフローを入れる必要がある。
• システムとして文書が改ざんされていないことを担保する方法もあると考えている。このためにはクライアント側にもセキュリティ評価を受けたソフトウェアが必要である。
• 中間者攻撃を防ぐ検証方法の1つとしてはあり得る。
• 自己責任に帰着させるためには、署名者が本人の意思で行ったことを確認させる必要がある。システムで検証を行うと、システム側が責任を負うことになる。
• 中間者攻撃を想定すると、検討モデルにおける(5)と(8)の経路の両方のセキュリティを担保する必要がある。その上で、署名者が確認するプロセスが必要である。
• 中間者攻撃に対処するための関連サービスとして、セキュアな文書作成ソフトや、署名検証ビューアがあることを指針に記載しても良いかもしれない。
• 通常文書サービスの一部の機能として署名サービスがあることが多いが、この場合、サービスが全権を持っているため、中間者攻撃に対する脆弱性が存在する。
• 最終的には、全体像の図にどのようなリスクがあるのかマッピングができると良い。
• 5．リモート署名のプレイヤの検討は網羅的に記載されているのか。
• 文献調査の結果を記載しており、網羅性は確認していない。
• 網羅性を持たせるなら、利用者が行うべきアクションについても記載するべきである。
• 現時点で網羅的でないにしても、最終的には網羅的に記載することが必要である。
• プレイヤの構成は、理論上は、認証局とクレデンシャル発行者が同一で、リモート署名提供者が別の場合と、認証局とリモート署名提供者が同一で、クレデンシャル発行者が別である場合も存在する。
• 議論の際には5パターンあることを確認し、現実的に検討すべき構成を絞り込んだ方が良い。
• 参考として記載されている「政府のインフラを利用する場合」とは、JPKIを想定するのか。それとも、マイナンバーを利用した別のネットワークを想定するのか。
• 例としてマイナンバーを挙げたが、具体的なインフラは今後検討していく予定である。
• 現実的にはJPKIを想定してくことになるだろう。
• プレイヤの構成としては、銀行と顧客が契約をするパターンのように、利用者とリモート署名提供者が同一である場合がある。現在は電子署名の対象書類ではないが、今後利用する可能性もある。
• 電子署名法は自然人を想定しているため、法人が利用者になることは想定しないのではないか。
• あくまで署名者は商業代理人であり、署名提供者とは異なるのではないか。
• リモート署名でない通常の署名でも同様の問題は起こるはずである。どのように解釈すべきか、法律に照らし合わせて検討して欲しい。
• 6．昨年度検討の鍵の設置事例の設置3において、点線の矢印の意味は何か。
• 実線は依頼を行ったり、鍵自体が移動するものであり、点線はそれ以外のアクション（CSRだけ行う等）である。
• 依頼も生成依頼と証明書署名依頼を分ける必要がある。秘密鍵と公開鍵も区別して記載した方が良い。
• CSRの際に認証局が本人確認をするためにパスポートやJPKIが必要なのか議論することになるのだろう。
• リスクを無くすためにどのような条件が必要なのか議論することになる。
• 外部のリモート署名サービスを利用するクラウドサービス事業者がいた場合、消費者はクラウド事業者を通して、電子証明書の登録等を行うことになるが、この場合、リモート署名提供者はどちらの事業者になるのか。
• ビジネスモデルは様々なパターンが考えられるが、本日検討している全体像に抽象化することができるはずである。現在は基本的な機能の議論をしているが、今後認定の話をする場合には、委任関係や代理関係を整理し、誰が何の責任を持つのか明確にする必要がある。基礎的な議論を徹底的に詰めることと、鳥瞰的な視点を持ちビジネスモデルのスキームに網羅性を持たせることの2点が必要である。

資料4についての質疑応答

• 資料4と机上配布資料1はどのような関係なのか。
• 机上配布資料1は資料4の論点を整理するための資料である。
• 論点(4)としてPINの話が出ているが、資料3には説明がない。なぜPINの議論が必要なのか、次回の研究会で説明して欲しい。
• 論点(1)で電子署名法の要件を満たすレベルというものが仮にあったとすると、それ以外のレベルとは何になるのか。
• 電子契約やリモート署名サービスにおいては、比較的厳密性の低いサービスも実際に提供されている。電子署名法を満たすレベルはかなり厳密性を持たせることになるが、それよりも低いレベルの基準も検討する必要がある。
• 電子署名法を満たすレベルとそうでないレベルを含んだガイダンスを出すことを想定しているのか。
• そこまでは分からないが、少なくとも検討のスコープには入れておき、報告書には記載したい。
• 今回はあくまでも電子署名法の視点からリモート署名の検討を行う。それ以外の領域は検討課題として、余力があれば議論することとする。
• 厳密に議論できなくとも、レベル感が違うことを明示することは重要である。
• 電子署名法の要件を満たすレベルでなくとも、本人の意思が表明できるレベルがある可能性もある。考え方としてはあるかもしれない。
• 論点(2)におけるクラウド環境の議論は何を議論すればよいのか。
• クラウドの利用を認めるべきか、また、認めるのであれば物理環境をどのように定義すべきか議論して欲しい。物理要件は契約で定義する方針も考えられるが、そもそも定義できないかもしれない。
• 総務省や外務省のガイドラインにおいても、一般的にクラウドを利用する際には国内法の影響が及ぶ範囲と規定している。国内法の範囲外であると、例えば、米国パトリオット法の影響を受けてデータが差し押さえられる恐れがある。国内法が及ばない海外サーバで署名システムが作動することを許容するのか議論が必要だろう。
• クラウドの利用を認めるにしても、国内法（電子署名法）が及ぶ範囲で作動することが要件として入ることになるだろう。
• 国内法に準拠しなければならないという要件は物理環境ではないが、リモート署名サービスの選定条件として記載することになるだろう。
• 物理環境として報告書に記載はしないつもりである。基本的には利用する事業者それぞれのリスク判断に任せるべきであると考えているが、親会の方針を確認したい。
• 要件を検討した上で、クラウド利用は認めないという結論になる可能性もある。
• 署名システムの形態は、自営、ハウジング、クラウドの3パターンがあり、それぞれで要件が記載できるか検討するつもりである。
• 海外サーバの利用を制限することは、押印した物理的な紙を海外の倉庫においてはいけないことと同様に考えられないか。
• 制限されるかどうかは各業界の業法に依存する。例えば、医療であれば、書類を医療機関内で保管しなければならないと規定されている。パトリオット法により情報が差し押さえられ、参照できなくなると、診療に影響がでてしまう。このように、保管義務だけでなく、開示義務がある場合に差し押さえられてしまうと問題が生じる。国内法の範囲外であるため、手出しできなくなる。
• Shared HSMを一旦据え置くとはどのような意味か。
• 物理環境の記述が行えないため、今回は検討しない。
• 論点(4)はクレデンシャルの話なのか。
• 連続署名時のPINキャッシュの問題がある。1回目はPINを要求し、それ以降はHSM側のPINキャッシュを利用することが一般的な署名業務では許容されている。これをどう扱うか議論したほうが良い。
• PINを入れて鍵を活性化することは、署名者の意思が反映されたとする意味がある。アプリケーション環境が脆弱であるときに、PINを入れる場合と、システムが行う場合とでは本人意思の確実性に差があると思われる。
• PINを平文で格納するようなケースは存在するのか。そもそもこのようなケースは想定するべきではないのではないか。
• このようなサービスが存在するかは分からないが、可能性はある。検討の範囲内であるため記載しているが、信頼性や本人確認の度合いからすると好ましくないケースであると考えている。
• 1つの組織内のシステムで管理している場合、実装としてありうるかもしれない。現段階ではまだ検討対象として残しておいてもよいだろう。
• 現段階では残しておく方針とする。
• 論点(5)において、設置1と設置2、設置3と設置4では信頼性のレベルが違うのではないか。
• 設置方法が4パターンある中で、鍵の品質をどのように担保するかという議論をする必要がある。

(3)　その他

全体の議論を通して、下記のような質疑応答があった。

• 電子署名法の観点から、本人による署名であると推定される状況であるにも関わらず、署名者が署名していないと主張した場合に、立証責任を負うのは署名者なのかリモート署名提供者なのか。
• 裁判では署名者が署名を否定する必要があるが、この際に必要な情報をリモート署名提供者が提供することは契約等で事前に規定しておく必要があると考えている。
• 問題が起こった場合に具体的にどのように対処するのか、署名者とリモート署名提供者との間で明確にしておく必要がある。このような課題があることを論点として残しておいて欲しい。

以上

• 電子署名法研究会の開催状況

商務情報政策局 サイバーセキュリティ課
電話：03-3501-1253
FAX：03-3580-6239