3 Minutes NetWorking Supplement
No.20

3Minutes NetWorking Supplement

補講第20回PKI(7) PKI

■ 電子証明書の失効

おねーさん

おね〜さんと、

ほげたん

ほげたんのっ!!

おねーさん

3 Minutes Networking、

ほげたん

Supplement !!

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

  1. 所有者の都合
    1. 所有者の秘密鍵が漏えいした
    2. 所有者の情報が変更になり、電子証明書の所有者情報と一致しなくなった
    3. 電子証明書が必要なくなった
  2. 発行CAの都合
    1. CAがサービスを停止した
    2. 電子証明書の所有者が規約から外れた不正な利用をした
おねーさん

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

電子証明書・詳細

[FigureSP18-05:電子証明書・詳細]

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

え? なんで?

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

  1. CRLモデル
  2. OCSPモデル
ほげたん

CRLとOCSP? 何それ。

おねーさん

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

ほげたん

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

おねーさん

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

フィールド説明








バージョンCRLのフォーマットバージョン。現行はバージョン2
アルゴリズム識別子発行CAが使用した署名(ハッシュと公開鍵暗号)の種類
発行CA名発行CAの名前
更新日時このCRLの発行日時
次回更新日時次にCRLを発行する予定日時
C
R
L



シリアル番号失効している証明書のシリアル番号
失効日時証明書が失効した日時
拡張領域CRLエントリの拡張領域
拡張領域CRLの拡張領域
署名アルゴリズム発行CAが署名する際に使用したハッシュの種類
発行CA署名発行CAによる署名

[TableSP20-01:CRL]

おねーさん

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

ほげたん

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

おねーさん

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

フィールド説明





バージョン証明書のフォーマットバージョン。現行はバージョン3
シリアル番号発行CAが決定するユニークなシリアル番号
アルゴリズム識別子発行CAが使用した署名(ハッシュと公開鍵暗号)の種類
発行CA名発行CAの名前
有効期間GMTで表記された有効期限の開始日時と終了日時
サブジェクト公開鍵の所有者名
公開鍵所有者が保持する公開鍵とその種類
発行CAユニークID発行CAやサブジェクトを再利用する際に使用する。使用しないことが推奨
サブジェクトユニークID
拡張領域追加情報など
署名アルゴリズム発行CAが署名する際に使用したハッシュの種類
発行CA署名発行CAによる署名

[TableSP18-01:X.509電子証明書]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

CRL・1

[FigureSP20-01:CRL・1]

CRL・2

[FigureSP20-02:CRL・2]

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

じゃ、もう1個のOCSPは?

おねーさん

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

ほげたん

うん、それはわかるよ。

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

そう。名前の通りね。

[FigureSP20-03:OCSP]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

レスポンダってないの?

おねーさん

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

ほげたん

なるほど。

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

■ トラストアンカの信頼

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

どこで判断するの?

ほげたん

え?

おねーさん

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

[FigureSP20-04:信頼できないトラストアンカ・1]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

[FigureSP20-05:信頼できないトラストアンカ・2]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

[FigureSP20-06:信頼できないトラストアンカ・3]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

■ CAの構成とCPS

おねーさん

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

CAの構成

[FigureSP20-07:CAの構成]

ほげたん

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

おねーさん

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

  1. 登録局(Registration Authority)
    • 電子証明書の申請を受けて、申請者の審査を行う
    • 失効依頼を受ける
  2. 発行局(Issuing Authority)
    • 秘密鍵を管理する
    • RAからの依頼を受け、電子証明書を作成し、発行する
    • RAからの依頼を受け、CRLを作成し、リポジトリにて公開する
  3. リポジトリ(Repository)
    • 自己署名証明書、電子証明書、CRL、CP/CPSを公開する
  4. アーカイブ(Archive)
    • 秘密鍵のバックアップ、電子証明書、CRLの長期保存を行う
おねーさん

(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のそれぞれの局が正しく機能しているかなんてどうやってわかるの?

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

まさしく「方針(ポリシー)」だね。

おねーさん

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

  1. はじめに
  2. 発行とリポジトリ
  3. I&A(身元確認と認証)
  4. 証明書のライフサイクル運用的要件
  5. 設備、管理および運用的コントロール
  6. 技術的セキュリティコントロール
  7. 証明書、CRL および OCSP のプロファイル
  8. 準拠性監査
  9. 他の案件と法的事項
おねーさん

この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読め」って書いてあるから一緒よね。

利用規約と依拠当事者規約

[FigureSP20-08:利用規約と依拠当事者規約]

ほげたん

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

おねーさん

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

依拠当事者規約

[FigureSP20-09:依拠当事者規約]

おねーさん

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

ほげたん

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

おねーさん

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

■ PKI

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

どうぞ。

ほげたん

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

おねーさん

うん。そうね。

ほげたん

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

おねーさん

いいわね、続けて。

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

PKI

[FigureSP20-10:PKI]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

考えると?

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

うん。了解だよ。

おねーさん

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

ほげたん

ほげたんのっ!!

おねーさん

3分間ネットワーク、

ほげたん

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

CRL
[Certificate Revocation List]
「証明書失効リスト」と訳される。失効リストのフォーマットは電子証明書と同様、X.509で規定されている。RFCならRFC3280。
OCSP
[Online Certificate Status Protocol]
「オンライン証明書状態確認プロトコル」と訳される。これもX.509で規定されている。RFCではRFC2560で規定。
CP
[Certificate Policy]
「証明書ポリシー」と訳される。
CPS
[Certification Practice Statement]
「認証業務実施規定」と訳される。
ガイドライン
RFC3467「Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework」のこと。参考リンクはRFC3647と、IPAによる日本語訳。
ほげたんほげたんの今日のポイント
  • 電子証明書は発行から有効期限まで有効である。
    • 有効期限内に無効にすることを失効と呼ぶ。
    • CAは失効の情報をCRL/OCSPで配布する。
    • 有効期限が切れた場合、再発行(新規作成)を行う。
  • トラストアンカを信頼する必要がある
    • CAにはIA、RA、リポジトリ、アーカイブからなる。
    • CAはCP/CPSにより、その方針、運用ルールが定められている。
  • PKIは「公開鍵暗号化による暗号化・署名を行うための、CAと電子証明書による信頼システム」である。

3 Minutes NetWorking Supplement No.20

管理人:aji-ssz(at)selene.is.dream.jp