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

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

日時:平成28年1月25日(月曜日)10時00分~12時15分
場所:経済産業省別館1階103共用会議室

出席者(敬称略)

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

配布資料

  • 資料1 サーバ署名の機能及び論点
  • 資料2 国内サーバ署名事例
  • 資料3 想定する署名機能
  • 参考資料1 オンライン手続におけるリスク評価及び電子署名・認証ガイドライン
  • 参考資料2 上記ガイドラインの概要
  • 参考資料3 上記ガイドラインの抜粋
  • 参考資料4 サーバ署名に関する規格・事例調査文献等調査状況(途中報告)

議事概要

サーバ署名の機能及び論点整理

事務局より、資料1、参考資料1~3を用いたサーバ署名の機能及び論点整理の説明が行われた。これに続いて、下記のような質疑応答があった。

  • 資料1「利用者認証機能」というのが、識別であるか認証であるかがわからない。IdentificationであってAuthenticationではないと認識しているが正確にはどちらになるのか。個人番号カードであればAuthenticationであるかもしれない。
  • IdentificationとAuthenticationの両方が入っている。本来は別の機能であるが、この図では一枚に集約したかったため、両方を合わせて記載している。
  • 初期の確認の手続きとその後のログインの手続きは異なるので別にしたほうが良いのではないか。

電子署名・認証関連ガイドラインの概要について

事務局より、参考資料2及び3を用いた電子署名・認証関連ガイドラインの概要の説明が行われた。これに続いて、下記のような質疑応答があった。

  • 参考資料2の「電子署名・認証ガイドライン」については、元々NISCが作成する以前に日本PKIフォーラム(PKI-J)で策定していたガイドラインがあった。このガイドラインは認証のみの扱いであり電子署名は扱っていなかった。このPKI-Jのガイドラインは、民間に適応するために作成されたが、その後に電子政府に適応するため、電子署名を付け加えることになった。認証に関してはSP800-63-1が雛形としてあったが、電子署名も包括したものは米国にはなかった。一方、欧州に近いものはあった。そのため、欧州の構想を参考にし、レベル4は欧州の電子署名法におけるQualified signature(適格署名)を念頭に置き、レベル3はAdvanced signatureを想定していた。本日の話題ではないが、参考資料2の4頁に署名プロセスとして、「電子署名用の証明書の用途は電子署名限定」と記載しているが、これは、電子署名用の証明書を認証用途に流用してはいけないという考えであり、欧州の考え方や事例を参考にしている。韓国では、韓国の電子署名法に基づいた署名用のソフトウェア証明書が使われているが、この署名用証明書が認証に使われている事例が多い。現在、これでよいかというのは微妙なところであるが、当時はこのような考えで記載した。この当時、サーバ署名は考慮していない。

国内サーバ署名事例について及び(4)想定する署名機能について

事務局より机上配布資料1、資料2を用いて、国内サーバ署名事例の説明が行われた。これに続いて、下記のような質疑応答があった。

  • SSA(Server Signing Application)Authenticationは何を想定しているのか。
  • サーバ署名のアプリケーションで、SignerをAuthenticationしている。この認証結果が認証デバイスであるSCDev(Signature Creation Device)に通知される。
  • 資料2の4頁の構成(3)でSSA-1とSSA-2を分離しなければならない理由は何か。Signerを分離しなくてはならない理由は何か。
  • アプリケーションの都合でこのような記載になっているかと想定している。構成(3)の左右は分離しているというわけではないと思うが。このような構成図を描く必要はないと考えられる。構成(3)にDTBS(Data to be Signed)を入力としているが、ここにハッシュを入力するように書けばよいのではないか。モデルの書き方がアプリケーションを中心に考えている結果、このような書き方になっているが、抽象度を上げていくと、資料2の3頁の構成(2)のモデルと等価なモデルとして説明できるのではないか。
  • 左右のサーバのセキュリティレベルが同じではないと設計されている可能性もあるのではないか。
  • VPNと記載されているので拠点が異なる想定では。
  • 論理的に説明をすると、ここにVPNがあるのでセキュリティレベルを同じにつないでいる。これを縮めると構成(2)と同じになり、SCDevにはデータではなくハッシュ値を送るという構成になる。
  • この二つの事業者が何者かというのを共通認識としてした方が良いのではないか。事例として把握している範囲であれば、左の電子契約作成は当事者であり、銀行であれば銀行、右側はASP事業者であり第三者であるという区分けである。署名者は銀行の口座を持っている法人の代表者。これが一つのパターンであるが、それ以外もあれば説明いただきたい。
  • 今、ご説明いただいた事例が多く、構成例もご説明の通りである。その他の事例としては、SSA-1の上部は金融機関が提供しているサービスであり、下部は金融機関の一部分業務を受託している事業者が実質的に右側のSSA-2とセットで提供しているケースがあった。
  • 認証が何処で、どのように行われているかということではないか。SSA-1とSSA-2が存在する事例では、SSA-1のサービスで認証した結果をSSA-2が信頼しているモデルであろう。
  • ビジネスモデル的にはありえるモデルである。
  • 最後は契約で縛ることになるだろう。
  • VPNで接続されている両側の事業者主体が別であれば、両方に登録する必要がある。ひとつは銀行であり、もうひとつは自分が信用して鍵を預けるところに登録する。利用者側は自分の鍵は別のところに預けられているということを認識しておく必要があるのではないか。
  • フロント側の業務からすると単にアウトソースしているだけであり、利用者は意識しない場合も存在するだろう。
  • モデルイメージを何パターンか出てきたので、機能分解を明確にしていかなければならない。最終的に一番プリミティブなところはどこかという議論をきっちりしなければならない。まず、保証のレベル感についてどう思うか。登録レベルはどうか。
  • 保証レベルを考えるときには、署名対象の文書やどういう業務で用いるのかというのに依存する。サーバ署名のモデルでは、サーバ署名で請求書を送りたいという事業者もある。一方、法人向けの融資契約をサーバ署名で行うときは、請求書送付に比べ重要度が高い。同じ契約といってもリース契約もあり、その契約の内容の重さによって保証レベルが異なる可能性もある。ある程度幅を持たせて議論をした方が良いのではないか。保証レベル3、4なのか、2でもあるのではないかといった形で議論したほうが良いのではないか。
  • 今のご意見に賛成で、相手に何かを送る場合でも、法律上の意思表示と単なる通知がある。契約書や注文書を含めて意思表示であるが、請求書は意思表示とは普通は見なされない。レベルの違いを踏まえておく必要がある。
  • トークンのレベルでいうと、レベル3と4の区別はつく。レジストレーションのレベル3はかなり近いが、参考資料3の8頁によるとレベル4は遠隔に対応しないことになっている。今回の検討では、オンラインの登録に対応すべきではないのではないか。個人番号カードだけが対象になるという考えも問題があるように思える。レジストレーションはレベル3~4の括りでよく、トークンは分離可能で、発行管理は議論が必要ではないか。
  • 参考資料3の6頁について補足説明する。元々SP800-63を参考に検討していた時点では、レベル3までは一般利用を想定していたイメージがあった。一方、レベル4は一般利用ではなく、政府機関等の限定した利用を想定していたイメージであったと認識している。
  • 当時、レベル4は士業等のプロはマストだと認識していた。これは、医師や建築士等、改ざんが公になる世界である。EUのレジストレーションの事例を見ると、登録者の登録書類の保存期間という規程もある。電子署名の文書の保存期間が10年、30年が基準となっていた。登録に用いた登録書類の保存期間まで考えなければならない。30年間も保存していると費用は掛かる。一方、一般的に認証用途の場合は長期間の保存まで要求していない。当時のもう一つの議論はサービスのリスクアセスメントである。当時、電子政府の認証の使いづらさは批判を受けていた。どうしてもカードリーダーがいるのか等。しかし、そのために電子政府のサービスをリスクアセスメントすると、サービス提供の当事者は高い保証レベルが必要だと考え、セキュリティレベルも高めにシフトしてしまったところがある。時代が変わっているのでこれでよいのかという意見もあり、今後も議論や検討が必要だろう。
  • 先ほどのご発言にもあったが、認証ガイドラインをベースに作成していたので、署名は後づけで、レベル3~4は署名を前提とした必要な条件が記載されている。レベル2と3の違いは、署名までできるレベルなのかという分けがある。
  • 署名用の証明書や鍵の生成も同じように登録、発行管理、トークンはそのままのレベル感でという認識である。今の時代にマッチングしているかは別として、参考資料1の44頁の最後の行に、署名についても同じレベルで記載されている。
  • HSMへの特殊な処理は、不足しているかもしれないが、共通な部分はあるということが分かった。
  • 参考資料3の9頁を見ると、失効を扱うのはレベル3以上になっている。失効しない電子証明書はないので検討が必要である。
  • デジタル署名を前提とすればおっしゃる通りだが、Electric signatureが失効情報までを必ずしもマストにはしていないところがある。
  • プロトコル上の失効情報の確認というのは否定しない。また、参考資料3の10頁をみるとレベル3は複数要素認証が必要となる。
  • ガイドラインを参考にするのは良いが、現状の利用を想定すると矛盾している箇所もあるかもしれない。たとえば、レベル4で「規制医薬品の調剤」と記載されているが、現在進めているヘルスケアPKIはレベル4を満たしていない。このガイドラインと完全にマッチングするのは難しく、補間していく必要がある。
  • 参考資料3の11頁で、中間者攻撃がレベル4は◎(二重丸)となっているが、今回はSSAや他のASPも想定されるため、注意しておいた方が良いのではないか。
  • 参考資料3の8頁の登録の時の認証はレベル3か4か。
  • 実務に照らし合わせるとレベル3になる。
  • 署名に限定しない民間の認証用途の場合では、レベル2でも許可されている場合がある。
  • この点についても現実の利用とは異なると思われる。住民票よりも在籍証明書の方がよほど重要なシーンがある。本人の認証レベルは運転免許証等でよいが、サーバ署名のサービスを考えた場合、住民票必須のというのはあり得ないのではないか。住民票よりは、むしろ、企業の代表取締役であることが証明される登記事項証明書を必須として在籍証明書を出す形式や利用シーンが多いだろう。
  • 今回の議論では、レベル3はどういうものか、公的な書類が必要かどうかといったレベルで考えたいので、「認証と登録」の登録は、レベル3以上が妥当であろう。「発行管理」はどうか。
  • レベル4は直接手渡しもしくは本人限定受取郵便といった物理的なもの。レベル3はネットワークやシステム的なものが使える。
  • オンラインでの利用を想定し、レベル3が妥当であろう。続いて、「トークン」はどうか。
  • トークンの保証レベル2は、パスワードのみでも許容している。サーバ署名の利用を想定するとレベル3以上が妥当と考えられる。
  • レベル3とする。残りは「認証プロセス」と「署名プロセス」になるがどうか。今回はあくまでサーバ署名ができるという前提で考えてほしい。セットで考えた方が良い。
  • 認証というのはSSAが認証することを言っているのか、SCDevが認証することを言っているのか曖昧なようだ。
  • それは両方行う。認証プロセスで署名者からSSAに入力する部分はどうか。レベル3と4が同じ書き方になっているので、レベル3とすればよいか。中間者攻撃はガイドラインを参考に詳細を記載するしかない。SSAとSCDevの間はどうか。
  • SCDevから見て、Signerをどう認証しているかという議論になる。
  • 認証プロセスを見れば同じということであればレベル3となるだろう。署名等のプロセスはどうか。SCDevの中での処理について関係するため詳細な検討が必要である。
  • SCDevは、HSMに限定しなくてよいが、少なくとも第三者認証を受けた暗号モジュールを利用すべきであろう。CC(Common Criteria、ISO/IEC15408)では、セキュリティレベル1~5が参考になる。ソフトウェアのモジュールを想定した場合には、ソフトウェアの改ざん耐性を持たせるか否かがポイントになり、FIPS140-2を基にしたISO/IEC19790のレベル1でも、実行時の直前にソフトウェアが正しいかの自己テストを定めており、その自己テストを試験している。ソフトウェアの改ざん耐性については、CCでもFIPS140-2でも要求している。これらの評価を導入することでソフトウェアの安全性を一定に保つことが可能である。
  • むしろたくさんの鍵束を預かるサーバ署名で確実に管理すべきである。この「電子署名・認証ガイドライン」に定めている内容はエンドユーザーのトークンである。
  • 「電子署名・認証ガイドライン」のレベル1~4で表せるのか。第三者認証のレベルでは議論できないのではないか。
  • 現状、署名生成・検証の機能が纏められ、参照可能な第三者認証の基準では、FIPS140-2で整理しなくてはならない。その考えでは、「電子署名・認証ガイドライン」のレベル3以上になる。
  • 参考資料3の14頁によるとレベル3がソフト、レベル4がハードと記載されている。レベル3以上はソフトウェアの安全性を第三者が評価しているかどうかということになる。
  • 外から見たらSSAを含めて署名等プロセスに見える。ソフトウェアの認定はSSAを含めた形になるか。
  • SSAのソフトウェア認定や評価は、今はない。今まさに欧州で作成している段階である。
  • 認証局を立ち上げたときに「FIPS140-2のレベル3相当」という言葉を利用していたが、基準やセキュリティ要求事項は作成していくほかない。
  • 第三者評価の説明はもっともであるが、先に説明があった通り、FIPS140-2のレベル3相当という規定で対応しているため、認証事業者のすべてがFIPS140-2の認定取得モジュールを使用しているかわからない。この点についても議論が必要ではないか。
  • サーバ署名は利用者の鍵ペアが多く保管されているため、確実に攻撃対象になる。そのためセキュリティ要求事項を高くする必要があるだろう。
  • 認定制度をどうかするという話ではなく、このような検討を通じて、CCのPP(Preference Profiles)を皆で策定するということではないか。
  • 製品依存を認めるかどうかは今後議論するとして、どうあるべきかの議論をしたい。そもそもサーバ署名を行うことはこうあるべきではないかということが本検討会の中心的な議論であり検討すべき内容である。我が国としてサーバ署名を行うときはどのレベルが必要かという議論が必要。そういった意味で、SCDevはどうか。
  • 先に説明した通り、ISO/IEC19790のセキュリティレベル1が必要であろう。最低、実装している暗号処理や鍵ペアの扱いを第三者が確認している。SCDevについては、例えばPOSから発行する請求書を考えた時に、すべてのPOSにHSMの実装や、同等のセキュリティレベルを要求すべきではない。そのため、最低限ISO/IEC19790のセキュリティレベルの1を担保すべきであろう。
  • ここは現在提供されているHSMについてどう考えるべきかという点も含めて、時間をかけて議論が必要である。本日はこれで一区切りとする。

以上

関連リンク

お問合せ先

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

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