Comments
Description
Transcript
資料5 調査結果（案）
資料５ 調査結果（案） 内容 1. アンケート調査 1. 2. 電子証明書の認証用途のニーズ等調査結果 サーバー署名のニーズ等調査結果 2. インタビュー調査 1. 2. 3. 現状のサーバー署名におけるRA/IAの調査結果 現状のサーバー署名における利用者認証及び鍵保管・管理の調査結果 サーバ署名に利用する署名生成鍵等の生成について 3. 文献調査 1. 2. 3. 4. 5. 6. JIS X 19790 セキュリティ要求概要一覧 米国の規制・サービス事例調査（一部再掲） The Adobe Approved Trust List (AATL) ISO/IEC 15408（EUの動向） 金融機関におけるクラウド利用に関する有識者検討会報告書 SP800-63 -1と-2の差分とHSMの利用について（一部再掲） 2 1.アンケート調査概要 • アンケート調査概要 – 調査期間：2015年11月～2016年2月 – 調査票発送数：18 – 調査票回収数：14（回答辞退1を含む） ※上記アンケート回答者を含む10名にインタビュー調査を実施。 • アンケート調査対象 – 認定認証事業者、民間認証事業者（国内外含む） – 電子証明書利用団体、サーバ署名提供事業者 • アンケート調査概要 – 電子証明書の認証用途のニーズ – サーバ署名のニーズ • • • サーバ署名提供の有無 サーバ署名で参考となる法令・ガイドライン等 サーバ署名の実施内容（サーバ署名を提供していない場合は、想定も含む） 3 1-1.電子証明書の認証用途のニーズ等調査結果 • 電子証明書の認証用途は、認定認証業務やその他の認証業務に関係なく、 ニーズがあるとの回答が多い。（回答総数13票のうち11票） 認定認証業務で利用が見込まれる分野等 1. 2. 3. 4. 5. 6. 7. 地方自治体（電子入札、証明書（住民票、戸籍、申請、印鑑登録）発行申請） 金融機関（銀行、保険会社） 法人向け融資契約 建設業、IT業、鉄道、メーカー等 ＧtoＢ電子調達における契約者認証 法人ポータルの利用時認証（プロファイルに法人番号の追加が必要） その他コメント：電子契約ビジネスへの適用を考えたいが、認定認証業務は価格的に難しい。 その他の認証業務で利用が見込まれる分野等 1. 2. 3. 4. 5. 6. 管理者および資格保持者の認証（及び承認署名） メール本人性確認（電子署名） インターネットバンキング 会員限定の各種オンラインサービス（サポートサービス、パブリッククラウドサービス利用者認証など） 社内システムへのログオン認証（テレワーク対応、 BYOD対策としての端末認証等） 電子調達における独法等の発注者認証 4 1-2①. サーバー署名のニーズ等調査結果 • サーバ署名は、認定認証業務やその他の認証業務に関係なく、ニーズがあるとの 回答が多い。（回答総数13票のうち11票） 認定認証業務で利用が見込まれる分野等 1. 建築確認申請の電子化 2. 電子契約、電子帳簿保管、e-TAX関連サービス（国税関係書類の電子化発行における社名及び代 表者名付き電子署名の付与） 3. 法定調書の電子化に伴う公的資格者による電子署名の付与（特定建築物、防火対象物、給水設 備、排水設備、昇降機、空気調和設備、冷凍機、電気設備等の点検業務） 4. 政府電子調達システムでの利用（将来） 5. 金融機関（銀行、保険会社） 6. レセプトオンライン／電子カルテ／電子処方箋 7. その他コメント； – – 特定の事業分野を問わずニーズがある。 価格的にむずかしく、認定認証業務は利用していない。 その他の認証業務で利用が見込まれる分野等 1. 2. 3. 4. 電子契約、電子証書配信 電子文書の保管業務 金融機関（銀行、保険会社） その他コメント； – – 特定の事業分野を問わずニーズがある。 認定認証業務と同じ。 5 1-2②. サーバー署名のニーズ等調査結果（参考法令等） • サーバ署名に関連する規定・法令（参考にしている国内外の法令・民間ベースの 規則）の有無の回答結果を以下に報告する。 認定認証業務で参考にしている規定や法令等 1. 2. 3. 4. 5. 電子署名法 NISC オンライン手続におけるリスク評価及び電子署名・認証ガイドライン（平成22年） NIST SP800-57 PartI/Part II/PartIII Recommendation for Key Management NIST SP800-63 Electronic Authentication Guideline NIST SP 800-25 Federal Agency Use of Public Key Technology for Digital Signatures and Authentication 6. ない その他の認証業務で参考にしている規定や法令等 1. 2. 3. 4. 電子署名法 Adobe Approved Trust List(AATL) CI-NETにおける電子証明書利用約款及びデータ交換協定書 NIST SP 800-25 Federal Agency Use of Public Key Technology for Digital Signatures and Authentication 5. ない 6 1-2③. サーバー署名のニーズ等調査結果（実施内容） • サーバ署名の実施内容の一部を以下に報告する。 （サーバ署名を提供していない場合は想定も含む） サーバ署名利用者の秘密鍵へのオンライン認証方式 サーバー署名を提供していますか（N=13) （N=13) 自社及びグループ会社が提供している 顧客及びパートナー企業が提供して… 提供を検討している 0 提供していない Yes 3 3 7 9 4 1 5 No 3 5 5 ID、パスワード認証 6 クライアント証明書を併用 6 ハードウェアトークンを併用 2 ワンタイムパスワードを併用 0 7 2 1 3 Yes 6 8 5 無回答 5 8 無回答 No サーバ署名利用者の秘密鍵の管理について（N=13) PKCS＃12でサーバー上に格納している 6 HSMの中に格納している 7 ・Yesの場合、鍵生成はHSMで実施している 3 ソフトウェア的な保護対策を実施している No 無回答 5 2 3 5 5 1 6 ・Yesの場合、証明書（秘密鍵）は利用者がアップロードしている Yes 2 5 7 2 6 7 2-1. 現状のサーバー署名におけるRA/IAの調査結果 • 国内のサーバー署名提供者及び関係者に対して署名用証明書のRA/IAを確認 した結果を以下に報告する。 – RA（登録局）、IA（発行局）は、認証事業者（CA）または、認証事業を行なっていないサ ービス提供者（SP）が実施している。 – なお、電子契約サービスでは、VA（検証局）を設定したサービスは存在しない。 （株式会社日本電子公証機構の提供する電子公証サービスは、電子契約に限定した公証サ ービスを提供していない） No ① RA（登録局） サービス提供者（SP） IA（発行局） サービス提供者（SP） ② サービス提供者（SP） 認証事業者（CA） ③ 認証事業者（CA） 認証事業者（CA） ※サービス提供者がLRAの場合も有 ※認証事業者が下請する RA（Registration Authority：登録局） IA（Issuing Authority：発行局） CA（Certificate Authority：認証局) 8 VA（Validation Authority：検証局) 2-2. 現状のサーバー署名における利用者認証及び 鍵保管・管理の調査結果 • 国内のサーバー署名提供者及び関係者に対して利用者認証及び鍵保管・管理 を確認した結果を以下に報告する。 利用者認証の種類について 1. IDとパスワードで認証する。 2. ICカードで認証する。 3. 上記1と2の両方で認証する。 鍵の保管・管理の種類について 1. HSM（Hardware Security Module）を利用して鍵を保管・管理する。 HSM内の鍵を用いて鍵を暗号化してHSM外に保管する。 2. ソフトウェアを利用して鍵を保管・管理する。 上記1と同様に鍵を暗号化して保管する。 3. ソフトウェアを利用して、鍵をPINを保管・管理する。 鍵とPINを異なる鍵で暗号化し保管する。 9 2-3. サーバー署名に利用する署名生成鍵等の生成について （参考：電子署名法施行規則6条3号の２） • サーバ署名に利用する署名生成鍵等の生成のパターンについてインタビューした結 果を以下に報告する。 1. 署名者が鍵生成を依頼する 1. 認証事業者（CA）に依頼し、 サーバ署名提供者の環境で鍵生成する。 署名者 2. サーバ署名提供者に依頼し、 サーバ署名提供者の環境で鍵生成する。 ※認証事業者とサーバ署名提供を兼業している場合も想定される。 認証事業者 （CA) サーバ署名 提供者 HSM 2. 署名者が鍵ペア等をサーバ署名提供者に送信する 1. 認証事業者（CA）から送信された鍵ペア等をサーバ署名提供者に送信（インポート） する。 2. 署名者の環境で生成した鍵ペア等をサーバ署名提供者に送信（インポート）する。 （署名者は認証事業者に対してCRS（電子証明書発行要求）を行う） ※サーバ署名利用者としての本人確認・登録のタイミングと 署名生成鍵の本人確認・登録のタイミングとの差については要調整。 10 No 3-1. JIS X 19790 セキュリティ要求概要一覧 項目 詳細 レベル１ レベル２ レベル３ レベル４ 1 インタフェース 必須のインタフェース及び選択可能なインタフェース。全てのインタフェースの仕 様及び全ての入出力データパスの仕様。 トラステッドチャネルの設置 2 役割，サービス，及び認証 必須の役割と選択可能な役割の論理的な 分離，及び必須のサービスと選択可能な サービスとの論理的な分離。 役割ベース又はIDベースのオペレータ認 証。 IDベースのオペレータ認証。 3 ソフトウェア・ファームウェア セキュリティ •承認された完全性技術，定義された SFMI，HFMI及びHSMI。 •実行可能コードがあれば良い。 承認されたディジタル署名又は鍵付き メッセージ認証コードに基づく完全性テ スト。 承認されたディジタル署名に基づく完全性テスト。 4 動作環境 •変更不可能な動作環境，限定動作環境又 •変更可能な動作環境。 「動作環境」に対する要求事項は、ソフトウェアモジュールに対する要件であり、 は変更可能な動作環境。 • 役割ベースの，又は任意アクセス制御。 レベル３、レベル４のモジュールでは、あり得ない。 • SSPの制御。 •監査メカニズム。 5 物理セキュリティ （概要） 製品グレードの部品 •タンパー証跡。 •不透明なカバー又は囲い。 •カバー及びドアに対してのタンパー検出 及びタンパー応答。 •EFP又はEFT。 •強固な囲い又はコーティング。直接的な プロービングからの保護。 多要素認証。 •タンパー検出及びタンパー応答が可能な 包被。 •EFP。 •故障注入への対処。 暗号モジュールは，附属書Fで規定されている非侵襲攻撃に対処するよう設計されている。 6 非侵襲セキュリティ 附属書Fで規定されている対処技術の文書化及び有効性。 対処法試験。 ベンダーが提示する方法で効果があるこ とを確認。 対処法試験。 試験機関が試験方法を工夫して効果を確 認。 乱数ビット生成器，SSP生成，確立，入出力，格納及びゼロ化。 7 承認された方法を利用した，自動化されたSSP配送又はSSP共有。 SSP管理 手動で確立されたSSPは，平文の形式で入力又は出力されてもよい。 8 9 自己テスト 手動で確立されたSSPは，暗号化された形式か，トラステッドチャネル経由で知識分 散処理を利用して入力又は出力されてもよい。 動作前自己テスト ソフトウェア・ファームウェア完全性テスト，バイパステスト，又は重要機能テスト。 条件自己テスト 暗号アルゴリズムテスト，鍵ペア整合性テスト，ソフトウェア・ファームウェアのロードテスト，手動入力テスト，条件バイバステスト及び重要機能テスト。 構成管理 暗号モジュール，部品，及び文書用の構成管理システム。 モジュールのライフサイクルを通じて，各々一意に識別及び追跡される。 設計 提供する全てのセキュリティ関連サービスの試験を許すよう設計された暗号モジュールであること。 FSM 暗号モジュールの動作を記述した有限状態モデルを提供すること。 ライフサイク 開発 ル保証 注釈付きソースコード，回路図又はHDL ※HDL：Hardware Description Language。ハードウェア記述言語。 ソフトウェアの高級言語。ハードウェアの上位記述言語。 テスト 機能試験を行い、その試験結果を提供すること。 配布及び運用 初期化手順を提供すること。 ガイダンス 管理者ガイダンス及び非管理者ガイダンス。 10 その他の攻撃への対処 自動化された構成管理システム。 配付手順を提供すること。 試験可能な要求事項は用意されていない攻撃への対処の仕様。 暗号モジュールの構成要素への入力時の 事前条件，及び構成要素が完了した場合 に真であると期待される事後条件を伴う 注釈付き文書。 下位レベル試験（例えば、サブルーチン単位の機能試験）を行い、機能試験を行い、 その試験結果を提供すること。 ベンダから提供された認証情報を用いた オペレータ認証。 試験可能な要求事項を備えた，攻撃への 対処の仕様。 SFMI : software/firmware module interface, HFMI : hybrid firmware module interface, HSMI : hybrid software module interface, SSP : sensitive security parameters, PSP 11 : public security parameter, EFP : environmental failure protection(環境故障保護), EFT : environmental failure testing(環境故障試験),動作前自己テスト（pre-operational self-test）, 条件自己テスト（conditional self-test） 3-2 ①. 米国の規制・サービス調査結果（規制調査結果） 連邦法 – 電子署名に関する主な連邦法は、2000年に法制化され、2001年にかけて順次施 行された、米国の電子署名法「グローバルな商取引と国内商取引における電子署名 法（Electronic Signatures in Global and National Commerce Act： ESIGN） 」である。 – 米国において、電子署名に紙に記入した物理的な署名と同様の法的効力を認めた最 初の法律である。 州法 – 上記ESIGNが連邦議会で審議・可決されていた同時期に、全米の州政府が策定す る電子署名関連の法律に一貫性を持たせる目的で策定されたモデル法がある。「統一 電子取引法（Uniform Electronic Transactions Act：UETA） 」と呼ばれるこ の法律は、各州政府の代表者で構成する非営利組織、National Conference of Commissioners on Uniform State Laws（ULC） が1999年に策定・採択し た。 – 2016年1月現在、ワシントン州、ニューヨーク州、イリノイ州、プエルトリコ自治連邦区を 除く全ての州・領土がUETAを採択している（UETAを採択していない州・領土は類似 の電子取引関連の法律を独自に採択・施行） 。 – 連邦法であるESIGNと同様に、電子記録に紙面の書類と同様に認識し、電子署名 を物理的な署名と同様の法的効力を与えることを目的とする 。 12 3-2 ②. 米国の規制・サービス事例調査（サービス調査結果） 公開文献調査の結果を以下に示す。 対象企業 DocuSign CudaSign ProSales サーバー DocuSignのクラウドサー バー あるいは、 顧客保有のサーバー Barracudaのクラウド サーバー あるいは、 顧客保有のサーバー 不明 セキュリ ティ モジュール SSMあるいはHSMを利 HSMを利用するオプ Software Security Module（SSM）あるいは 用するオプションがある。 ションがある。 Hardware Security Module（HSM）を利用す HSMのメーカーは不明。 HSMのメーカーは不明。 るオプションがある。 HSMのメーカーは不明。 利用者確認* コード（SMS・電子メー パスワードおよび、 SMSなどで送付された ルなどで送付）、 コードを用いる2段階認 電話認証、 秘密の質問、 証 など 第三者発行の電子証明、 SNSへのサインイン情報、 電子メールアドレス、IP 現在地のGPS情報 など アドレス、タイムスタン プなども、記録される。 コード（SMS・電子 メールなどで送付）、 PKI証明書、 Eid2（スウェーデンの 電子ID）、 などを利用した2段階認 証 など 13 3-3. The Adobe Approved Trust List (AATL) 一部のサービス提供者では、AATLの対応が重要であるというアンケート結果があ り、AATLの要求事項で特に鍵管理等について以下に抜粋する。 – Adobe Approved Trust List（AATL）とは、アドビ社認定の信頼できるルート証明書の一 覧であり、アドビ社が提供するサーバーから信頼済のルート証明書をインストールすることで、電子 署名の検証が可能。（日本国政府発行の官職認証局の電子署名にも対応している） • Adobe Approved Trust List Technical Requirements Version 1.4 https://helpx.adobe.com/acrobat/kb/approved-trust-list2.html – 利用者の鍵ペアは、FIPS140-2のレベル3及び同等のHSMで生成・保管することが義務付けら れている。 • 6. The Member must be generating and storing key pair(s) for the Supplied Certificate(s) in a medium that prevents exportation or duplication such as hardware security modules that meet FIPS 140-2 Level 3 or equivalent. – 秘密鍵がHSMで保管され、強力な認証方式を利用する場合（アドビ社の承認が必要）、署名 者がリモートサーバの秘密鍵にアクセスし署名する新しいモデルを可能とする。 • 20. The Member must enforce a traditional public key infrastructure model, wherein the signer is in physical possession and control of a hardware security token or module that contains the private key. Newer models wherein a signer remotely accesses the private key on a server are possible, if the private key resides on an HSM and strong authentication methods are used, but will still need to be approved 14 by Adobe. 3-４. ISO/IEC 15408（EUの動向）① 2008年 2009年 2010年 DCSSI-PP 2008/05 - Electronic Signature Creation Module (CC3.1), version 1.6 (EAL3+ ) DCSSI-PP 2008/06 - Electronic Signature Verification Module (CC3.1), Version 1.6 (EAL3+ ) DCSSI-PP 2008/07 - Timestamping System (CC3.1), Version 1.7 (EAL3+ ) Part 2: Device with Key Generation, Version 1.03 (EAL4+ ) 2011年 2012年 2013年 2014年 Maintenance Report ANSSI-CC-PP 2008/05-M01 (EAL3+ ) 2015年 2016年 Protection profiles for secure signature creation device Maintenance Report ANSSI-CC-PP2008-06-M01 (EAL3+ ) ANSSI-CC-PP 2008/05 - M01 - Electronic Signature Creation Application version 1.7 (EAL3+ ) ANSSI-CC-PP 2008/06 - M01 - Electronic Signature Verification Application (CC3.1), Version 1.7 (EAL3+ ) Part 2: Device with Key Generation Version 2.01 (EAL4+ ) Part 3: Device with key import (EAL4+ ) 次頁 EN 419 241 Security requirements for trustworthy systems supporting server signing (signature generation services) -2 & 3 Protection profiles for Server Signing Part 4: Extension for device with key generation and trusted communication with certificate generation application (EAL4+ ) Protection profiles for secure signature creation device Part 5: Extension for device with key generation and trusted communication with signature creation application (EAL4+ ) Part 6: Extension for device with key import and trusted communication with signature (EAL4+ ) ※EUの規程動向を踏まえ、本調査では、EN 419 241を中心に調査検討を進める。 15 3-４. ISO/IEC 15408（EUの動向）② （Part 2とPart 3のSecurity Objectivesについて） 前頁のPart 2: Device with Key GenerationとPart 3: Device with key importの評価対 象のセキュリティ機能を以下に抜粋する。 Part2 Part3 ○ ○ 識別 概要 OT.Lifecycle_Security （ライフサイクルセキュリティ） TOEは、初期化、パーソナライゼーションおよび使用中の欠陥を検出する。また、TOEは安全にSCDを 破壊するための機能を提供する。 OT.SCD/SVD_Gen （SCD/SVD生成） TOEは、許可されたユーザーのみがSCDとSVDの生成を呼び出すことを確実にするために、セキュリティ 機能を提供する。 ON.SCD Auth_Imp （SCDのインポート） TOEは、許可されたユーザーのみがインポートを呼び出すことができることを確実にするためにセキュリティ 機能を提供提供する。 ○ OT.SCD_Unique （署名作成データの一意性） TOEは、SCD/SVDペアの暗号品質を確保する。 SCDからSVDを再構築することはできない。また、同 等のSCDを生成する確率は無視できる程度である。 ○ OT.SCD_SVD_Corresp （SVDとSCDの対応） TOEは、TOEによって生成されたSVDとSCDとの対応を確実にする。SVDのエクスポートするために、 SCDで生成したデジタル署名とSVD/SCDペアは明確に対応する。 ○ ○ ○ ○ OT.SCD_Secrecy （署名作成データの機密性） SSDの秘密情報は、高い攻撃能力を持つ攻撃に対抗する。 ○ ○ OT.Sig_Secure （デジタル署名の暗号化セキュリティ） TOEは、堅牢な暗号化技術を介して偽造できないデジタル署名を生成する。 SCDは、デジタル署名ま たはTOEからエクスポートされた他のデータを用いて再構成することができない。デジタル署名は、高い攻 撃能力への対抗する。 ○ ○ OT.Sigy_SigF （正当な署名者への制限） TOEは、正当な署名者のデジタル署名の作成機能を提供し、デジタル署名を作成するために、他人の 使用に対してSCDを保護する。 TOEは、高い攻撃能力を持つ攻撃に抵抗する。 ○ ○ OT.DTBS_Integrity_TOE （DTBS/Rの整合性） TOEは、この目的は、TOEが署名作成アルゴリズムを準備するためにDTBS/R上の暗号学的ハッシュ関 数を適用した署名作成プロセスと競合しないDTBS/Rを変更してはなりません。 ○ ○ OT.EMSEC_Design （漏洩電磁波対策の設計） TOEは、漏洩電磁波を制御する設計を施す。 ○ ○ OT.Tamper_ID （タンパー検出） TOEは、そのコンポーネントの物理的改ざんを検出するシステム機能を提供し、セキュリティ侵害を制限す る。 ○ ○ OT.Tamper_Resistance （耐タンパ性） TOEは、防止または指定されたシステムのデバイスおよびコンポーネントの改ざんを物理的に抵抗する。 SCD：Signature-creation data SVD：Signature-verification data SSCD：Secure signature-creation device DTBS/R：Data to be signed or its unique representation 16 3-４. ISO/IEC 15408（EUの動向）③ （PPの記述について） 調査対象のPP • • • ANSSI-CC-PP 2008/05 - M01 - Electronic Signature Creation Application ANSSI-CC-PP 2008/06 - M01 - Electronic Signature Verification Application Device with Key Generation Part 2～6 セキュリティ機能の記述の有無 • • 鍵ペアのバックアップ機能：記述無 ログ生成機能：記述無 17 3-5.金融機関におけるクラウド利用に関する有識者検討会報告書 以下の報告書から鍵管理に関する記述を抜粋する – 金融機関におけるクラウド利用に関する有識者検討会報告書、公益財団法人 金融情報システ ムセンター、平成26年11月 • 暗号鍵の管理主体 – 暗号鍵の管理主体は必ずしも金融機関である必要はないが、『FISC 安全対策基準』【運 43】 に定める管理策24は必要である。クラウド事業者に暗号鍵の管理を委ねる場合には、その管理 策の概要を十分に把握し、同様にリスク管理のポリシーに合致しているかどうか判断する必要があ る。委託元金融機関が暗号鍵を保管し自ら管理をすることを可能にする技術も提供されてきてい る。こうした技術をベースとしたソリューションを利用することもリスク管理の向上には有効である。 • リスク管理策の一覧（例） ※金融期間等のコンピュータシステムの安全対策基準・解説書 第8版、運用管理（運 43）「暗号鍵の利用において運 用管理方法を明確にすること。」が義務付けられ、詳細には、「不正行為を防止するため、暗号鍵の利用において暗号鍵の 生成、配付、使用および保管等に係わる手続きを定めておくこと。また、その管理書類等は役席者が厳重に管理すること。」 18 が示されている。 3-6①. SP800-63 -1と-2の差分について • SP800-63について – NIST（米国国立標準技術研究所）が発行しているSpecial Publication 800-63 – Electronic Authentication Guideline（電子認証に関するガイドライン） • 差分について – 初回SWGでの報告の通り、SP800-63-1（2006年4月公表）と SP800-63-2 （2013年8月公表）は、本検討で参考とする部分については大きな差はない。 – 4つの技術要素 技術要素 定義 トークン 身元を証明するもの（通常は暗号鍵またはパスワード）。 身元識別情報の検証 身元識別情報をトークンに結び付けるクレデンシャルの登録と提供。 リモート認証メカニズム すなわち、認証要求者が実際に加入者本人であることを証明するために用いられる、クレ デンシャル、トークン、および認証プロトコルの組み合わせ。 アサーションメカニズム リモート認証の結果を第三者に伝えるために用いられる。 – 各レベル レベル 定義 レベル 1 身元識別情報の検証は要求事項になっていないが、保護されたトランザクションやデータにアクセスするのが同一の認 証要求者であることに対するなんらかの保証が認証メカニズムによって提供される。 レベル 2 単一要素によるリモートネットワーク認証を提供する。このレベルでは、身元識別情報の検証に関する要求事項が導 入され、識別のための有形物または情報の提示が求められる。 レベル 3 複数要素によるリモートネットワーク認証を提供する。このレベルでは、身元識別情報の検証手順において、識別のた めの物または情報を検証することが求められる。 レベル 4 リモートネットワーク認証について実用上最大限の保証を提供することを目的とする。レベル 4 の認証では、暗号化 プロトコルを通じて鍵の所持を証明することが基本となる。 19 3-6②. HSMの利用について（第一回検討会資料の再掲） • 第一回電子署名法検討会にて報告したセキュリティ要求基準（主にSP800-63 及びFIPS140-2）に基づいたサービス提供の国内利用状況を確認した結果、 現時点ではエンドエンティティ証明書の利用事例はない。 暗号モジュール サービス種類 証明書の種類 従来のHSM サーバー証明書 CP/CPS[1,2,3] CA証明書 Cloud HSM[6] サーバー証明書 左に同じ CA証明書 サーバー署名の サービス事例[7] 不明 ※本調査との関係ではサーバ証明 ※本調査との関係ではサーバ証明 ※エンドエンティティ証明書であるか不 明 鍵の生成 SP800-63[4]と同じ ・FIPS140-2[5] Lev3の暗号モ ジュール 左に同じ 不明 鍵の利用 活性化 SP800-63と同じ ・FIPS140-2 Lev3の暗号モ ジュール 左に同じ 不明 SP800-63と同じ ・FIPS140-2 Lev3の物理 ・FIPS140-2 Lev2の暗号モ ジュール/トークン 左に同じ 不明 （GPKIではCA秘密鍵は、レベル3相 当以上、官職証明書の秘密鍵はレベ ル2相当以上） 鍵の保管 [1] 認証局の証明書ポリシ：Certificate Policy（CP）, 認証局運用規定：Certification Practice Statement , [2] RFC 2527 , Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework ,S. Chokhani,W. Ford, March 1999. [3] RFC 3647 , Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, S. Chokhani,W . Ford,R. Sabett, C. Merrill, S. Wu, November 2003. [4] SP800-63-1 Electronic Authentication Guideline, National Institute of Standards and Technology , [5] FIPS PUB 140-2, Security Requirements for Cryptographic Modules, National Institute of Standards and Technology [6] AWS 公開情報「よくある質問」 等 20 [7] GMOグローバルサインの公開情報 等