認証情報登録・要求の現状と課題

ティポリシーを策定し、適切なアカウント管理規定を設けこれを実施していく ことが重要である。

パスワード認証の場合であってもPKIの認証の場合であっても、認証の目的 や、そこに起こるであろう脅威と起こるべく損害を図った上で認証のサービス ポリシーを策定し、サービス基準としてのレベル分けを行い、それぞれのレベ ルに応じた利用者登録、アカウント管理のクライテリアを明確にする必要があ ろう。

2.8.1  パスワード発行、アカウント登録のプロセス

JNSA（NPO 日本ネットワークセキュリティ協会）で策定した「情報セキュ リティポリシー解説書」282ではユーザー認証標準、アカウント管理標準につ いて、以下のようなポリシーを策定すべきとしている。

ユーザー認証標準 1. パスワードポリシー

・パスワードの文字数、記号等の使用、推定しにくいもの

・パスワードの定期的な変更

・パスワードの初期生成と利用者による変更

・パスワードの漏洩を防ぐ 2. パスワード忘れた場合の処置

・利用者のパスワード忘れとシステム管理者への連絡

・管理者による本人確認

・新規発行と利用者への通知

3. ワンタイムパスワードを使う場合

・PIN認証を行う

・時刻同期などで認証を必要としないものを使わない

・PINを推定出来ないようにする 4. 生体認証を使う場合

・適切な方式の選定

・生体情報の厳重な管理 アカウント管理標準 1. 新規アカウントの発行

・申請部署の権限の明確化

・本人確認とシステム管理者への通知 2. アカウントの変更

・権限の変更のルールの明確化

3. アカウントの削除

・不用になったアカウントの速やかな削除

パスワードによる認証を用いる場合でも以上のようなポリシーを設定し明確 な管理を行う必要があるだろう。

2.8.2  PKI利用者登録、証明書発行のプロセス

PKI利用者になろうとする者はCA又はRAに自分の身分を示す書類を提示 し証明書の発行要求の登録を行う。CA又はRAは証明書発行要求者の本人確 認を行った後認証局が証明書発行を行う。すなわち、証明書の発行は２つの手 順で行われる。

(1) 証明書要求者の認証登録 (2) 鍵ペアの生成と証明書発行

証明書要求者の認証登録（本人確認）の後、証明書発行手順は鍵ペアをCA 側で行うか、利用者側で行うかで以下の２つの証明書発行方法がある。

・認証局側で鍵ペア生成：CA又はRAが鍵ペア生成し、証明書の発行要求 を行い、証明書と対応する私有鍵を安全な方法で確実に利用者に渡す。

・利用者側で鍵ペア生成：利用者が鍵ペアを生成し、公開鍵を提示し証明書 発行要求を行い、CAが鍵ペアの対応を確認するPoP（Proof of Possession） をした後、証明書を発行し利用者に渡す。

証明書要求フォーマット及びプロトコル（PKCS#10とPKIX-CMP） PKCS#10は10年以上前のX.509v1の時代にPEMcertのときにRSAによ って導入されたレガシーなものである。これは単純に利用者名義と公開鍵をバ インドして欲しいと言う簡単な要求フォーマットになっている。当然ながら PKCS#10のAttributeは当初X.509v3の拡張領域のAttributeを想定してお らず、属性はRSAの独自仕様のPKCS#6や＃9をベースにしたものであった。

IETFにPKIX-WGが出来たときの最初のミッションはPart 1、2、3、4の RFCを作ることで、この中でPKIX-CMP（Certificate Management Protocol： 証明書管理プロトコル）を策定し、PKCS#10だけではなくX.509v3に基づく 証明書管理の新しいプロトコルを作ろうということになった。そこでCMPは CRMF（Certificate Request Message Format：証明書要求フォーマット）と

組でX.509v3への対応する新しいプロトコルと要求フォーマットが策定される

ことになった。

PKCS#10証明書要求や相互認証証明書の要求はPKCS#10では何の区別も

できない。GPKIではPKCS#10はほとんどオフラインの証明書発行要求のフ ォーマットとして使われている。

GPKIの相互運用性仕様書にはCMPの本体のPKI Body仕様ではなく補助 的な仕様として定められている自己署名証明書を持つCA鍵のUpdate手順だ けが入っている。しかし、古い証明書から新しい証明書にCA鍵を更新するに はエンドエンティティはCAとCMPでやり取りしなければ実際に更新は出来 ないので、OldWithNew、NewWithOldをオフラインで交換し合うしか出来な い仕様で中途半端な仕様のままである。

GPKIで採用しているPKCS#10 は過去との互換性のために残っている時代 遅れ仕様である。

2.8.3  電子署名・認証法

電子署名・認証法で特定認証業務の認定の基準が施行規則や指針として詳し く定められている。ここでは利用者の登録手順が確実に行えるように本人確認 の方法が定められている。本人確認後証明書発行にはセンター発行と利用者発 行要求の2通りの方法がある。しかし署名法の規則では、利用者の証明書の発 行に関して最初はセンター側のCA側での証明書発行しか想定していなかった。

センター側の証明書発行についてはセンター側で生成した利用者の鍵ペアをい かに安全に利用者に渡すかの問題がある。また利用者に渡した後、センタ側に 残る鍵ペアを第3者が利用出来ないように確実に破棄する必要がある。

利用者側で鍵ペアを生成し、利用者側から公開鍵をCAに提示し証明書発行 要求することは鍵ペアが利用者以外に持ち出されること無く安全性の観点から 好ましい特性を持っている。この場合利用者が提示した公開鍵と利用者が持っ ている署名用私有鍵の対応を確実に行なう必要がある。いわゆるPoP（Proof of

Possession）である。改正規則では利用者側での鍵生成手順も加えることにな

った。

2.8.4  GPKIでの登録手順 

・官職証明書発行

官職証明書の発行：CA側で鍵ペア生成しクレデンシャルをICカードに入れ ることになっている。将来の課題として職員の証明書発行を行う場合、利用者 側での鍵ペア生成モデルも考慮する必要がある。

・民間申請者の証明書発行手順

民間の証明書の発行手順は電子署名・認証法で定められた詳しい規則がある。

現在GPKIに接続する民間の認証業務はこの認定を受け、かつGPKIの相互認 証技術基準を満たすことになっている。

今後公的個人認証サービスが行われるようになるが、この場合の利用者の証

明書発行の手順は市役所等の窓口で、申請者を住民基本台帳と照合して本人確 認を行った後、窓口に設置された鍵ペア生成装置で利用者が鍵ペアを生成し、

その後証明書発行を要求することになる。現在、この装置で生成した鍵ペアは ICカードに移されるか、フロッピーなどに格納されて手渡されることになって いる。この場合、ICカードの互換性やフロッピーに格納される鍵ペアの安全性 について明確な基準を設けるべきであろう。また、市役所の窓口に置かれる鍵 ペア生成装置の安全性や物理的な管理の安全性についても明確にしなければな らない。

・証明書発行のセキュリティレベル

GPKIでの証明書発行のレベルが現在かなりレベルの高い基準が1つだけ定 められている。政府への電子申請や届出にはより簡便なレベルを設けるべきで はないかとの意見がある。リアルな世界の届出には3文判でOKであるものが 多くある。これらをすべてレベルの高いものにしておくのはコストや利便性か ら問題があるのではないかとも言われている。