■ 電子証明書の失効

おね～さんと、

ほげたんのっ!!

3 Minutes Networking、

Supplement !!

さてさて、まだまだPKIの話が続くんだけど。

うん、おね～さん。前回の最後の「改ざん・なりすまし・否認」を防止するために「まだ大事なことが抜けてる」って言ってたけど、何さ？ もうOKだと僕は思うよ。

んふふ。その前に、ちょっと別の話をさせて。まぁ、その「大事なこと」ともからんだ話なんだけどね。電子証明書のライフサイクルの話。

ライフサイクル？ 生きて死ぬという循環？ 輪廻転生？

いや、そこまで大きな話じゃないんだけど。電子証明書の生き死にを考えてみると。
って、アレよね、発行から有効期限切れまで有効なのはわかるわよね。

電子証明書には有効期限があるもんね。有効期限がある理由って？

どんな強力な暗号でも、長時間使い続けていると鍵が解明される恐れがあるからよ。
それでね、通常は有効期限切れまで使える電子証明書なんだけど、有効期限内でも使えなくなることがあるの。電子証明書の失効があった場合よ。

失効？ 効力を失うの？ つまり、使えなくなるってこと？

使えなくなるという表現は曖昧ね。電子証明書の失効ってどういう意味？ 電子証明書の役割から考えると？

電子証明書は「鍵と所有者の結びつきを保証するもの」だよ。…、「保証がなくなる」って事でいいのかな？

そう。所有者や発行CAの都合により電子証明書の保証をなくすことがあるわけよ。これを「失効」と呼ぶの。

都合により、って。どんな都合？

ん～、いくつかあるけど。

代表的なものはこれぐらい? (1-3)、(2-1)、(2-2)はいいわよね。文字通りの意味だから。
(1-2)は、たとえば、こないだとったベリサインの電子証明書だと。

サブジェクトに「aji-ssz(at)selene.is.dream.jp,Aji Amino」って情報があるかと思うけど。たとえばメールアドレスが変わったとか、結婚して姓が変わったとかね。他にも「役職」が書かれていた場合、役職が変わったとか。

サブジェクトの情報と一致しなくなった、ってことだね。
(1-1)の秘密鍵の漏洩ってのは、かなりインパクトあるね。

秘密鍵の漏洩って、署名でも暗号化でもピンチな事態なわけでしょ。そういう時は「公開鍵・秘密鍵ペアの作り直し」が必要よね。そうなると、電子証明書の公開鍵と新しく作った公開鍵が異なるから、電子証明書を失効する必要があるってこと。

うん。……でもさ、それって「電子証明書の変更」じゃダメなのかな？ わざわざ「失効」、つまりなかったことじゃなくって、変更かければいいじゃん？

それは無理よ、ほげたん。

え？ なんで？

電子証明書は公開されるものだからよ。基本的に、ディジタル署名をつける場合とかは、署名と一緒に電子証明書も送るの。さらに、電子証明書はコピーされてバラまかれても全然問題ないモノでしょ。

そうだね。電子証明書、つまり公開鍵がコピられてもこっちは全然問題ないよね。秘密鍵さえ漏えいしないようにしておけば、なりすましはできないし、改ざんもCAの署名があるからできないし。

でしょ。となると、自分の電子証明書がどこにどれだけあるか把握できないって状態なわけよ。となると、自分の持っている電子証明書が変更されたとしても、出回っているのが変更されないと意味がないじゃない。

う～ん、そうかなぁ。結局電子証明書を使うのは自分なんだから…。

例えば、ほげたんの出回ってる電子証明書を使って、私がほげたんに送るデータを暗号化したらどうするの？ それが秘密鍵が漏えいしてしまって変更した公開鍵の前の公開鍵の証明書だったら？

あ、あぁ。そういう可能性もあるか。でも、それって失効でも同じじゃないかな。

そうね、「出回ってしまった電子証明書」を「失効」する。これって「自分が保持している電子証明書に失効したことを表わすマークをつける」だけじゃダメよね。

うん、出回っちゃってるんだもん。失効を表わすマークがつく前の電子証明書を持ってる人だっているよね。

そうよね、そういう紙媒体みたいな方式じゃダメ。かといって、前の電子証明書を探し出して廃棄させるとかそういうのも現実的じゃない。よって、2つの方式が考え出されてるの。

CRLとOCSP？ 何それ。

まず、CRLね。要は発行CAが失効している電子証明書のリストを公開する方式ね。▼ link

失効リスト？ それを公開して、「ここに書かれている電子証明書は使えませんよ」ってCAが宣言するってこと？

そういうこと。ちなみに、こんなフォーマット。

このCRLのフォーマットもX.509で規定されてるの。でね。途中のCRLエントリってあるでしょ？ ここが失効した証明書の数だけ記述されてるわけ。

へぇ…。載ってるのは電子証明書のシリアル番号だけなんだね。

そうそう。電子証明書のフォーマットに「シリアル番号」ってあったアレね。

なるほど。あと、CRLにもCAの署名が付くんだね。

署名は「改ざんとなりすましの防止」のためね。考えてみて。悪意のある第三者、ブラックほげたんが、発行CAに偽装して、「ほげたんの証明書が失効されている」というCRLを配布したら？

本来はつかえるはずの僕の電子証明書が使えなくなっちゃうね。

でしょう？ それを防ぐために、CAの署名が付くのよ。
ん～、実際のCRLを見てもらいましょうか。

この図だと、3枚だけど、電子証明書が失効されてるのがわかるでしょ。

ずいぶんと発行日時が古いCRLだね。

う～ん。たまたま、パパのPCに入っていたCRLがこれしかなかったのよ。ともかく、これがCRLモデルね。「CAが失効リストを公開する」。

じゃ、もう1個のOCSPは？

その前にCRLの話をもうちょっと。CRLはCAが定期的に発行するの。これはCRLに「次回更新日時」が入ってるからわかると思うけど。

うん、それはわかるよ。

じゃ、これの欠点もわかるわよね。つまり、リアルタイム性に欠けるってこと。CRLの発行から次の発行まで、その間に失効された電子証明書の情報は入ってこない。

そうなるね。となると、失効からCRLの発行の間は「ホントは失効されているのに、それがわからない」状態になるね。なんか悪用できそうだよ？

ってことで、OCSPの登場ってわけ。 ▼ link

オンライン証明書状態確認プロトコル？ 文字通り、「オンライン」で「証明書の状態」を「確認」するプロトコルってことでいいのかな？

そう。名前の通りね。

レスポンダとリクエスタって珍しい言い方だよね。サーバとクライアントでよさそうだけど。

それは言われても困るわね。ともかく、証明書の状態がクリティカルに影響するアプリケーションなどではOCSPを使うといいわね。リアルタイムで確認ができるから。

クリティカルに影響するって、たとえば？

オンラインバンキングやトレードとか、失効した電子証明書使われてたら即ピンチなところね。でも、必ずオンラインじゃなきゃ使えないし、CAがOCSPレスポンダを用意してくれないとダメだし、こっちもリクエスタを用意しないと。

レスポンダってないの？

それはCAによるから、ある場合とない場合あるってことね。一方、CRL方式はCRLファイルを取り込むから、オフラインでも使用できる。SSL/TLS、S/MIMEなどWebがらみはどちらかというとこっちを使ってるわね。

なるほど。

失効の話はこれぐらい。あと、ライフサイクルで話しておくことといえば…。
電子証明書に有効期限があるのはいいんだけど、有効期限を過ぎても電子証明書が必要な場合はどうするの？

どうするの、って。普通、再発行してもらわない？

うん、そうよね。再発行よね。ただ、「再発行」という言葉だと、さっき話に出てきた「電子証明書の有効期限の変更」ってイメージにならない？

そうだね、今使ってる電子証明書の有効期限の延長、ってことだよね。

でも、さっき話したけど、電子証明書を変更することはできない。よって、再発行といっても新規に電子証明書を作成しなおすってこと。鍵ペアを作り直して、新しく電子証明書を作ってもらうってことね。

そっか。「電子証明書は出回ってる」から、修正はできないんだっけ。だから、新規発行扱いになるんだね。

そういうこと。ライフサイクルについてはこれぐらいかなー。ほげたん、OK？

失効と、再発行だね。OKだよ。

■ トラストアンカの信頼

さて、お待ちかね。「まだ大事なことが抜けてる」の大事なコト、の話。
まず、復習からいきましょう。公開鍵のなりすましは公開鍵暗号化システムを瓦解させるがスタートだったわね。

「瓦解」だったっけ？ 前は「破綻」って言ってたような。
まぁ、どっちでもいいけど、それは電子証明書が公開鍵を保証する、だったよね。

そう。「その公開鍵って信頼できるの？」の答えが「電子証明書が保証するよ」だったわよね。
で？ 電子証明書のなりすましの可能性もあったわね。

自作の電子証明書とかだよね。だから、トラストアンカへ信頼のチェーンができている電子証明書だけを信頼する、だったよね。

うん。「その電子証明書って信頼できるの？」の答えが「トラストアンカが保証するよ」という答えだったのが前回。
じゃあ、当然この質問がきてもおかしくないわよね、そのトラストアンカは信頼できるの？

え？ えぇぇぇぇ!? いや、あの、「信頼できるCAがトラストアンカ」じゃないの？

まぁ、普通は信頼できないCAをトラストアンカにはしないかな？

だよね。じゃあ、「そのトラストアンカは信頼できるの？」の答えは「トラストアンカはもとから信頼できるCAだよ」でいいんじゃない？

どこで判断するの？

え？

依拠当事者は、「信頼できるCAをトラストアンカとする」。それはいいけど、CAを信頼する理由は？ 闇雲に信頼するわけないでしょ？ じゃないと、たとえばこんなことが起きちゃうかも。

うぇ!? 申請を審査せずに発行しちゃう!?

これでなりすましが無事成功しちゃったわけね。あらあら、前回までの話はなんだったのかしら？

……さすがネットさん…。「読まずに食べた」黒ヤギさんよりいいかげんだよ。ちゃんと仕事しようよ…。

ほかにも、こういうのはどうかな？

うぇ!? 失効情報を公開してくれない!?

これでなりすましが無事成功しちゃったわけね。あらあら、前回までの話はなんだったのかしら？

……うぅぅ、ネットさん～…。そりゃ秘密鍵盗まれた僕も悪いけど、失効依頼したんだからさ、ちゃんと仕事しようよ…。

もいっこ、こういうのは？

うぇ!? CAが秘密鍵を盗まれる!?

これでなりすましが無事成功しちゃったわけね。あらあら、前回までの話はなんだったのかしら？

こ、これは……、さっきの2つと比べられないくらい一大事なんじゃないかな…。

うん。実はそう。もしCAの秘密鍵が漏えいしちゃったら、「そのCAが発行した電子証明書」をいくらでも作れちゃうからね。

だ、だよね。電子証明書が改ざんされない、CAが発行されたものだと認証されるのは、「CAの署名」があるからだよね。CAの署名って、要は秘密鍵による暗号化なんだし。

そうよね。電子証明書が「所有者と公開鍵の結びつきを保証」するもので、「トラストアンカがそれを保証」しているってのは、結局のところ「CAの署名」の存在があるからだから。

つまり、「CAのホンモノの署名」が偽造……、偽造じゃないけど、CAの手以外で作成できるってことは、「トラストアンカによる保証」が意味をなさないんじゃないかな。

そういうこと。つまりCAの秘密鍵こそが電子証明書の保証の源だったりするわけよ。
さて、ほげたん？ 3パターンほど、トラストアンカの信頼について説明したけど、これって結局どういうこと？

そうだね、ネットさんのCAなんかを信頼したおねーさんがバカってことなんじゃないかな？

………。例え話の中の事だとわかってても、ムッときたわ。

はわわわわわ、お、おね～さん？ 例え話、例え話。ふぉーえぐざんぽーな話ですよ？

……ちっ。ま、まぁ。私がバカってのもあながち間違いじゃないから許してあげる。もちろん、例え話の中での事よ。結局、信頼できないCAをトラストアンカにしたってのが問題ってことね。

そうだよね。審査をしっかりしない、失効情報を公開しない、秘密鍵が漏えいする、なんてどれもダメダメなCAだよね。こんなCAが発行する電子証明書なんて信じられないよ。

■ CAの構成とCPS

そうよね。じゃあ、CAとはどのようなものか、どうやって「信頼」してもらうのか、という話をしましょう。まず、CAとはどのようなものか、の話。CAの基本的な仕組みというか、構成は次のようになってるの。

登録局と、発行局と、リポジトリと、アーカイブ？ わかるようなわからないような。

それぞれの役割はこうね。

(1)から順番に。まずRA、登録局ね。ま、名前の通り、申請を受けて審査を行うところ。

さっきの、[FigureSP20-04:信頼できないトラストアンカ・1]ではココがいいかげんって話なんだ。

そう。RAは、「実在性・本人性の確認」「秘密鍵所有の有無」「申請書の情報の正確さ」などを審査し、電子証明書の発行の許否を決定するわけね。

「秘密鍵所有の有無」「申請書の情報の正確さ」はわかるけど、「実在性・本人性の確認」って何？ どう違うの？

「実在性」は申請の所有者が存在するかどうか、の確認。架空の人物や存在しないメールアドレスの証明書は発行できないからね。確認はパスポート、住民票、住基カードなんかで行えるわ。

ふむふむ。本人性も似たようなものなんじゃないの？

「実在」した人物になりすまされたら困るじゃない。なので、申請者が所有者もしくは代理人であるかどうか、確認しないと。例えばブラックほげたんが勝手にほげたんの電子証明書を申請したとかないようにするためよ。写真付き証明書で確認できるわよね。

あ、あぁ。そうか。なりすまし電子証明書を申請されたら困るよね。
あと、秘密鍵の所有の有無ってどうやって確認するの？

申請書、まぁデータなんだけど、これに署名データをつければいいのよ。申請書には電子証明書に載せるための公開鍵がついてるから、これで検証すればOK。

なるほどなるほど。

で、次が(2)IA、発行局。秘密鍵を管理し電子証明書の発行を行う。さっきも説明したけど、CAにとって秘密鍵こそ発行する電子証明書の保証の源。CAの中でも最重要にあたる部分ね。

そうだよね。CAの秘密鍵が盗まれると、そのCAの署名の付いた電子証明書を発行されちゃうもんね。[FigureSP20-06:信頼できないトラストアンカ・3]の話だね。

でしょ。だからIAは別名、「認証局（CA）」とも呼ばれてるの。つまり、CAの中のCA、CAそのものとも言われてるわけ。ともかく、IAの最重要業務は「鍵管理」。つまり秘密鍵を安全に管理することね。

ふむふむ。で、リポジトリは？

(3)のリポジトリはCAにとって重要な情報を公開する役割ね。トラストアンカになるための自己署名証明書。CRL/OCSPでの失効情報。それとCP/CPS。

[FigureSP20-05:信頼できないトラストアンカ・2]の話だ。で、CP/CPSって何？

それは(4)を説明してから話すわ。(4)のアーカイブ。証明書の保存、秘密鍵のバックアップを行うの。他の3つに比べると裏方さんよね。つまり、CAは4つの局が正しく機能していないといけないってことね。

審査を行うRA、鍵管理をするIA、情報を公開するリポジトリ、バックアップを行うアーカイブ。たしかにどれも大事かなぁ。っていってもさ、おね～さん。CAのそれぞれの局が正しく機能しているかなんてどうやってわかるの？

それはもっともな疑問ね。そこで登場するのが、CPとCPSよ。

「証明書ポリシー」と「認証業務実施規定」？

まず、CP。CPはCA・電子証明書の目的・適用範囲を決め、運用に関する方針を定義するための文書ね。まさしく、「CAのポリシー」よ。CAが何のために存在し、どのような方針で運営されるか決めるわけね。

ふ～ん。なんかアレだね、憲法とかそういうのっぽいね。

ポリシーだからね。なんていうの？ 所信表明演説というか、そういうの。「このCAは当社の電子文書の利用者認証に用いられる」「申請の審査は厳密に行う」「鍵は安全な管理をする」とかそういうお題目を決めるのね。

まさしく「方針（ポリシー）」だね。

そういうこと。そして、そのポリシーを元に、実際の詳細な項目を決めたCPSがあるわけね。実際、RFCでCPとCPSのガイドラインがあるの。そこからCPSに必要な項目を書き出すと。▼ link

このCPSにより、さっきの4つの局、それぞれの実際の運用などが決まっていくわけね。例えば、「リポジトリによるCRLの発行頻度」「申請に必要な本人性確認の手順」「鍵が管理されてる場所への物理的アクセス」とかね。

それはわかったけど。でも、CPとCPSの関係がいまいちわからないというか。

ガイドラインにはこうあるわね。

CP は、様々な論点を考慮して、当該 PKI によって提起される要件および標準を規定します。換言すれば、CP の目的は、「何を関係者がしなければならないか」を確立することにあります。CPS は、対照的に、「CA および他の関係者が、一定のドメインにおいて、CP において言明されている要件に適合させるために、どのように手順やコントロールを実装するか」を言明します。換言すれば、CPS の目的は、「どのように関係者が各々の役割を果たし、コントロールを実施するか」を開示することです。

…、難しい。

簡単に言えば、CPは「CAがするべきこと（条件）」で、CPSは「CPを満たすためにすべきこと（実践）」ね。「申請には公的な書類を持って行うこと（CP）」で、「申請にはパスポート、運転免許証、住基カード（写真つき）を必要とする（CPS）」とか。

ははぁ、さっきおね～さんが「お題目」って言ってたのはそういう意味か。「こうすべきだ」と「だからこのように実行しましょう」ってこと？

ま、そんな感じね。これはもちろん、CAを運用するためのルールでもあるんだけど、他にも役割があるわけね。まず1つは、目的と責任の明確化。責任分界点を決めるわけ……。責任分界点って通信用語だっけ。

確か。ともかく、言いたいことはわかるよ。あれだね、訴えられないように免責事項があるってことだね。「電子レンジでは動物を乾かしていけません」ってやつだ。

その猫電子レンジ自体は都市伝説らしいけど、まぁ、言いたいことはわかるわ。
それと、信頼性の確保。「ウチのCAはこんなポリシーで、こんな風に運用してますよ、安全ですよ」って言いたいわけね。

あ、そうか。CPSはリポジトリで公開されるんだっけ。

そういうこと。つまり、信頼されるCAの判断は？

公開されているCPSから判断しろってこと？

基本的にはそう。あとは社会的信用とか、運用実績とか、そういうところから判断するわけね。でも、少なくとも適当なCPSのところは適当な運用しかしてないから、信頼するに値しないのはわかるわよね。

それはそうだね。

あぁ、あと。CPSがらみで話しておくことがもう1つ。所有者と依拠当事者はCAのCPSに同意しなければいけないってことかな？ CPSはさっきの話でもでてきたけど、免責事項なども入っているからね。

そうなの？

実際は、CPSから必要事項を抜粋した、利用規約と依拠当事者規約に同意するんだけどね。どっちにしろ、この2つの規約の中には「CPS読め」って書いてあるから一緒よね。

利用規約はわかるよ。あれでしょ、発行申請する際に「同意する」のボタンを押させるわけでしょ。でも、依拠当事者規約？ 同意したっけ？

依拠当事者規約は通常、電子証明書に記載されてるの。

拡張領域のところに「証明書ポリシー」ってURLがあるでしょ。ここが依拠当事者規約のあるところ。

う～ん。でも、あくまでも「場所」があるだけで、これで同意したと言えるのかな？

言える、らしいわよ。「明記してあるのに読まない」と判断されるらしいのね。そこらへんは法律の問題だから、おねーさんの手にあまっちゃうな。

■ PKI

さてさて。大体話したいことは終わったんだけど。で、ほげたん、PKIって何？

…公開鍵暗号化による暗号・署名を正しく使える基盤だよね。

うん。なんで、「基盤」なのかわかった？ おねーさん、PKIの第1回目に「「技術・製品」を表す「総称」じゃない」って、よくある用語解説にツッコんだわよね、理由はわかる？

一気にまとめて言えないから、順番に言っていい？

どうぞ。

電子商取引に存在するなりすまし・改ざんなどの脅威に対抗するため、公開鍵暗号化による署名・暗号化技術が存在する。

うん。そうね。

だけど、公開鍵暗号化は単独では脅威に対抗できない。簡単にいえば、「公開鍵のなりすまし」自体を公開鍵暗号化だけでは防げないんだよね。だから、公開鍵暗号化を正しく使える環境でないと公開鍵暗号化は使えない。

いいわね、続けて。

そのためには、「信頼できるCA（トラストアンカ）」「CAが発行した電子証明書」と「電子証明書を検証するためのシステム」などが必要。

そういうことね。まだあるわよね？

うん。検証システムには「CAが発行する失効情報」「トラストアンカへの信頼のチェーン」「自己署名証明書」「自己署名証明書を安全に配布するシステム」などがないとダメ。

うんうん。いいね、ほげたん。結局のところ、PKIって何？

結局、最初におね～さんが言ってた「公開鍵暗号化による暗号・署名を正しく使える基盤」ってのに落ち着くんだよね。

ま、そうよね。もうちょっと言うと、「公開鍵暗号化による暗号・署名を正しく使うための電子証明書とCAによる信頼システム」かな。

信頼システム？ … 、そうだね、トラストアンカ、信頼のチェーン、電子証明書。すべて「信頼」「保証」を作り出すためのシステムだよね。

そうでしょ。いかに「公開鍵暗号化を正しく使うか」のために、信頼と保証を積み上げていくか、って話でしょ。公開鍵を信頼するために電子証明書が。電子証明書を信頼するためにトラストアンカが。

トラストアンカを信頼するためにCP/CPSや運用実績が。まさしく「信頼を積み上げる」って感じだね。

だから、「技術」「製品」の総称じゃないの。だって、それだけじゃどうにもならないから、こんな「信頼システム」が出来上がってるのよ。
だってねぇ、電子証明書の申請の審査なんて、どうやって技術的に行うのよって感じかな。

そう言われればそうかな。そこらへんは、あくまでも「運用」面が必要だよね。

なので、それらをぜ～んぶひっくるめた「信頼システム」がPKI。
例えば、「今後、当社で発行する電子文書には署名を必要としたい。そのため、PKIを構築する」なんて言われた場合のこと考えると？

考えると？

考えなさいよ、もう。つまり、CP/CPSから始まるCAの構築、失効情報を配信する運用などなど全部行うってことね。新たな「信頼システム」を作り出すってこと。もちろん、既存のPKIに参加するってのもありかな。

なるほど。PKIっていう「基盤・環境」を作る、もしくはそこに入れてもらうんだね。

そういうこと。ん～、細かい話はまだあるけど、大体PKIの基礎はこれぐらいかなぁ。

うん。了解だよ。

んふふ。じゃ、また次回。
おね～さんと、

ほげたんのっ!!

3分間ネットワーク、

サプリメントでした～～～っ!!