■ 電子証明書の弱点

おね〜さんと、

ほげたんのっ!!

3 Minutes Networking、

Supplement !!

さてさて、前回の話を要約すると、「ねぇ、その公開鍵って信頼できるの？」という疑問の解決だったわけね。

それはちょっと要約しすぎのような。つまり、電子証明書とCAの登場だね。

それも要約しすぎ。公開鍵のなりすましは公開鍵暗号化システムを破綻させるがスタートね。それを防ぐため、電子証明書とCAが登場したわけでしょ。

うん。公開鍵の所有者を保証する電子証明書とそれを発行するCAだね。

そういうことね。

んでもさ、これでOKなんじゃないの？ 前回は邪悪な……もとい、含み笑いで終わったんだけど？ 「まだ足りない」ってドコが？

んふふ。前回のコレ見てもらおっかな。

？ なりすましを防ぐために、CAの保証がある電子証明書しか受け取らない、でしょ？ 問題ないじゃん？

逆に言うならば、電子証明書ならば受け取る、と考えられるわね。

う…うん、そうとも言える、かな？

でしょう？ んでね、こうなる。

…、ところでさ。このブラックほげたんは、ブラックネットさんに協力を仰いでまで僕になんでなりすましとかしようとするのかな？

恨みでもかってるんじゃない？ 「お前は俺の心をズタズタにした!! 今度は俺がお前をズタズタにしてやるっ!!」とか

あ、あぁ。俺は人殺しがだぁ〜い好きなんだ!!、ってことかな？

まぁ、そんな脳が痛い話は置いておいて。なりすましできたでしょ？

い、いや、これは…。ブラックネットさん、つまり悪いCAが存在して、なりすましの電子証明書を発行するってのはちょっと予想外というかなんというか。

電子証明書ってね、そんなに特別なものじゃないのよ。WindowsサーバOSがあれば、あっという間にできるわね。前に出てきたopensslがあっても結構簡単にできるわよ。

そ、そうなの？

別にブラックネットさん率いる悪いCAに頼まなくても、その気になれば自分でも作れるってことね。つまり、前回の「公開鍵って信用できるの？」の解答が「電子証明書が保証するよ」だったでしょ？

だったね。公開鍵とその所有者を結びつけるのが電子証明書だったから。

それで「電子証明書が保証する」っていうけど、さっきの例みたいに悪いCAが発行したり、自分で作ったりしたら「保証」も何もないでしょ？

そうだね。なりすましするための電子証明書が存在しちゃうわけだから。

つまり、電子証明書の正当性の保証が必要ってこと。悪いCAや自作で電子証明書が作られてない、正当なCAによる発行したってことを証明してよ、って話。

正しいCAが発行した電子証明書じゃなきゃ困るってことだね。

■ トラストアンカ

ここでのポイントは「正当なCAによる発行かどうかをどうやって判断するか」よね。

そうだね、悪いCAが発行したり、自作だったりじゃなくて、「ちゃんとしたCAが発行した電子証明書だ」って識別できないと、なりすまし電子証明書をつかまされる恐れがあるよね。

そのためには、「正当なCA」ってのを、利用者が知っていなければいけないわけよね。つまり、なりすまし電子証明書を発行したりするような悪いCAじゃないCAはコレって知ってなきゃダメってこと。

うん、それはわかる。その前に、「利用者」ってどっち？ 電子証明書を使う方？ もらう方？

あ、あぁ。そうね。その区別はこう。

電子証明書を発行してもらって、渡す側が「所有者」、受け取って検証する側が「利用者」。依拠当事者って？

あ、うん。前に紹介したIPAの文書だと、「利用者（証明書利用者）」なんだけど。CAだと「依拠当事者」って呼んでることが多いのよ。それでね、困ったことに「依拠当事者」って呼ぶ場合は所有者は「利用者」って呼んだりするのよ。

うわ、ややこしい。

なので、ここでは「所有者」と「依拠当事者」って呼ぶことにするわね。

あいあい、了解。

さて、話を戻して。受け取った電子証明書が正当なCAから発行されているかどうか。これは発行元CAが依拠当事者にとって「信頼」できるCAかどうかってことになるわけよ。

ん？ 依拠当事者にとって？

そう。正当なCAからの発行じゃないと困るのは依拠当事者だからね。まぁ、最終的には所有者にも影響があるかもしれないけど、直接的に「なりすまし」「改ざん」「否認」を防ぎたいのは依拠当事者の方でしょ？

まぁ、そうかな。電子証明書をもらって、検証をしっかりして、なりすましやらなにやらがないって保証されたいのはデータをもらう方だよね。

でしょ。で、依拠当事者が「CAを信頼する」ことが必要なの。で、信頼したCAが発行した電子証明書は信頼できるって流れになるわけね。

ちょ、ちょっと待って。整理させて。電子証明書が正当性の保証が必要。それは正当なCAが発行したかどうか、である。…依拠当事者にとって、信頼しているCA＝正当なCAってことでいいのかな？

そういうことね。でね、信頼できるCAかどうかは依拠当事者が決める。ここでのポイントは自己署名証明書よ。

自己署名証明書？ CAが自分の公開鍵の署名前証明書を、自分の秘密鍵で署名した証明書だよね？

それそれ。だってさ、ほげたん？ 自己署名証明書なんてカッコイイ言い方してるけどさ。これって「自分で自分のサインを証明する書類」なのよ？ こんな莫迦なことないじゃない？

まぁ、そうかなぁ。

あれよね、言うならばオレオレ証明書よね。「これが僕の印影です。ホンモノだという証明に、ほら、ここに僕の捺印があるでしょ？」 こんな保証も何もあったもんじゃない書類を使って、電子証明書を検証するのよ？

でも自己署名証明書がなきゃ、検証できないよね。

そう。自己署名証明書をCAから貰わないといけない。それを貰って、検証に使うって、もうCAを信頼してないとできないことよね？

そうだね、その「オレオレ証明書」、保証もないような証明書を信じて使うしかないよね。

つまり、CAの自己署名証明書を持っている＝そのCAを信頼しているとなる、というわけね。

そうなる、のかな？ 持っていること、イコール信頼なの？

まぁ、持っていても信頼しないって事もないわけじゃないけど。基本的に自己署名証明書を貰うってことは、「信頼しているから」じゃないとできないわけだからね。この、自分が自己署名証明書を持っているCAのことを、トラストアンカと呼ぶの。

アンカー？ 船の錨のことだよね。トラスト、信頼の錨？

そう、依拠当事者が信頼するCAをそう呼ぶの。そのCAが依拠当事者にとって、信頼が固定されている場所だからね。ま、あとの「信頼モデル」でなんで「アンカー」って呼ぶかわかるわ。

信頼しているCA＝トラストアンカ。ってことは、トラストアンカが発行した電子証明書は、トラストアンカが「所有者とその鍵の結びつき」を保証しているから、正当な電子証明書である、ってことかな。

その理解でOK。それを踏まえて、電子証明書の検証をおさらい。

前回も話したけど、3回の検証が行われているわね。

(1)の、自己署名証明書の検証。これ、改ざんの確認に行うんだけど。普通、検証っていったら(2)(3)にある通り認証が入るはずなんだけど、ないのはなんで？

え？ え〜っと、自己署名だから？

そう。自己署名だから、なりすましの対策である認証が意味をもたないことになっちゃってるのね。ちなみに、改ざんもやりようによってはできちゃうわ。

ををを。自己署名証明書ってほぼ無検証で受け入れちゃうんだ。

そうね、この場合の「改ざんの検出」ってのは、署名まで改ざんしてない場合の、署名前証明書の改ざんの検出であって。署名まで改ざんされちゃうと手も足もって事ね。

で、いったんそのなりすまされた自己署名証明書を受け取っちゃうと、そのCAをトラストアンカとしちゃうから、そこが作った電子証明書はすべて検証OKになっちゃう、と。怖いね。

でしょう？ よって、トラストアンカにしたいCAの自己署名証明書はなりすましや改ざんがない安全な方法で受け取るのが必要ってことね。

安全な方法？ どんなの？

手渡し、郵送がまず物理的な手法としてあげられるわよね。あとは、証明書を使用するソフトをインストールする際に一緒にインストールしちゃうとか。

へぇ。ソフトウェアのインストーラに組み込んでおくんだ。

そう。他にもCAのWebサイトで公開して。一緒に改ざん防止のために、自己署名証明書のダイジェストを載せておいて、検証してもらうとかね。たとえば、ベリサインだとこんな感じ。 ▼ link

この「フィンガープリント」ってところだね。ダウンロードした自己署名証明書のダイジェストを自分で作って、これと比較すればいいんだね。…これって安全なの？

すくなくとも、Webサイトを改ざんしないとダメだしね。ともかく、なんらかの手段を用いて安全に自己署名証明書を受け取らないとダメってことね。

なるほど。

でね。トラストアンカでないCAから発行された電子証明書を受け取った場合は、警告がでるのが一般的ね。

「問題があります」。「信頼された証明機関から発行されたものではありません」、だって。

この場合、SSLのサーバを証明する電子証明書を受け取ったんだけど。それがトラストアンカでないCAから発行された電子証明書なわけね。だから、「問題あるよ」という警告がでたわけ。

あー、でも。「このサイトの閲覧を続行する」ってあるよ。推奨されないけど。

あとは自己責任って感じね。それと、さっきの(2)の「送信者の電子証明書の改ざんの確認とCAが発行したという認証」ね。自己署名証明書のCAの公開鍵による電子証明書の検証を行うってこと。

それにより、改ざんの確認と、トラストアンカが発行した電子証明書であることが保証されるわけだね。

そういうことね。電子証明書の署名はCAが行っているから、署名による認証によりCAが発行したかどうかわかるって寸法ね。

それにより、「電子証明書の保証」が行われるわけだね。

■ CAの信頼モデル

さて、トラストアンカの話を前提として次の話。
CAと所有者と依拠当事者がいるでしょ。これって、「CAという信頼」を中心につながっているといえるでしょ？

ん？ いまいち意味がわからないよ。

CAがあって、所有者がCAに発行してもらって、それを依拠当事者に渡す。依拠当事者はCAを信頼してその電子証明書を検証する。こういう関係よね。

そうだね。CAと所有者と依拠当事者の関係はそうだよね。

世界に1つだけCAがあって、世界中の人がそのCAを使ってるんならまだしも。世界にはいっぱいCAがあるの。こっちのCAを使っている人と、そっちのCAを使っている人はどういう関係？

どういうって言われても。特に関係ないんじゃないじゃないかなぁ。

うん。実は全く関係ない。CAの信頼の範囲はあくまでも所有者と依拠当事者にしか及ばないのね。

図のCA1が影響するのは、左のA、Bの二人だけ。CA2が影響するのは右のC,Dの二人だけ、ね。これはこれでいいんだけど、たとえばAがDに署名付きデータを送りたい場合どうするの？

Aが持っている電子証明書はCA1が発行した奴で、DにとってはCA1はトラストアンカじゃないから、「トラストアンカ以外が発行した証明書」扱いになっちゃうから。DがCA1をトラストアンカにするか、受け取らないか、どっちかじゃない？

うんうん、その通り。これが全く関係ないCA同士ならいいけど、例えばA社とA社の人が利用しているCA。B社とB社の人が利用しているCA。A社とB社が提携して、電子文書のやり取りをして、署名が必要になりました。こういう場合はどうしよう？

どうしよう、って。A社の人はB社のCAを、B社の人はA社のCAを、それぞれトラストアンカにすればいいんじゃない？

それはそうね。でも、それだとA社の人がそれぞれB社のCAをトラストアンカに設定して、という面倒な作業が発生しちゃうわね。もうちょっと、こうCAの連係がとれないものかしら？

CAの、連携？

そう、連携。これをCAの信頼モデルっていうんだけど。要はCA同士が信頼しあうことね。

へぇ、そうするとなんかいいことあるの？

それについてはモデルの説明でしていくわ。さてさてっと、このモデル。5種類あるのでそれぞれ説明していくわね。

まず最初が「個別認証モデル」ね。これは一番シンプルな方式で、それぞれトラストアンカを設定するモデルね。

ふむふむ。あれだね、この図の例だと、BさんはAさん、Cさんから電子証明書をもらうから、それぞれCA1、CA2をトラストアンカに設定しておくんだね。

そうそう。CAは自己署名証明書を作成し、依拠当事者はその自己署名証明書を入手して、CAごとにトラストアンカとして設定する。ま、いままでの説明通りのものね。

だね。っていうか、これ以外というのが思いつかないんだけど。

ま、それは説明してくから。これはシンプルなモデルだけど、使われるCAをすべて個別に信頼しなくちゃいけないって点でちょっと面倒なわけね。

う〜ん。そう言われればそうかな。

次が「階層型モデル」。これは親子関係にあるCAで、親CAをトラストアンカに設定するモデル。

親子関係？ CAが？

そう。親会社と子会社とか。グループとそのグループ参加企業とか、そういうイメージね。この階層モデルでは親CAが子CAを信頼し、証明書を発行するのね。

え、ええ？ ま、まず。親CAが子CAの公開鍵を保証する電子証明書を発行する？

そう。そして、子CAが発行した電子証明書はその親CAの署名が入った子CAの電子証明書で検証する。それにより、「自己署名証明書により親CAを保証」→「親CAが子CAを保証」→「子CAが所有者を保証」という信頼のつながりが形成されるわけね。

トラストアンカが発行した電子証明書はトラストアンカが「公開鍵と所有者の結びつき」を保証しているよね。でも、今回のはトラストアンカが発行してないけど？

確かにそうね。でも、今話した「信頼のつながり」がそれと同等の意味を持つのよ。

これを信頼のチェーンもしくは証明（認証）パスと呼ぶの。たとえトラストアンカが発行していなくても、このトラストアンカへのチェーンができていれば電子証明書は保証されていると考えるの。

へぇ、保証が連鎖していって、「トラストアンカが保証した」ことになるんだね。

そうね、だからチェーンと呼ばれるわけね。チェーン（鎖）の先には錨（アンカー）があるわけ。

チェーンとアンカー。なるほどね、だから「信頼の錨（トラストアンカ）」か。

そういうこと。この時、親CAを「ルートCA」と呼ぶの。ここから、階層構造であってもなくてもトラストアンカをルートCAと呼ぶのね。

階層型（ツリー）の根（ルート）にあるから、ルートCAだね。

この階層構造の利点はわかるわよね、ルートCAさえトラストアンカとしていれば、すべての子CAが発行する電子証明書は保証される。つまり、個別にCAを信頼しなくて済む、わけね。

そうだね。親会社さえ信頼していれば、すべての子会社も信頼されるって感じでいけるわけだね。

そうそう。だけど弱点もあって。親CAが信頼できないCAになっちゃうと、すべての子CAがダメになるし。逆に子CAが信頼できないCAであっても、親CAを信頼しちゃうとすべて信頼されてしまう。信頼関係がしっかりしてないとダメってことね。

CAが信頼できないようになることってあるの？

あるわよ。それは次回の話にしましょう。次のモデルの説明ね。「Webモデル」。これは現在インターネットで一般的に使われている信頼モデルのこと。主にSSLのサーバ証明とメールでブラウザ・メーラが使用するモデルね。

ブラウザが？ SSLってアレだよね。HTTPで主に使われている暗号・認証プロトコル。

そう。Webモデルは個別認証と階層型の両方が使われているモデルね。ポイントはインターネットで信頼のおけるCAが事前にトラストアンカとしてブラウザに登録されているってこと。

ブラウザに登録されている？

そうよ。つまり、ブラウザのベンダ、Microsoftであったり、Mozilla Foundationだったり、Appleだったり、そこが事前にトラストアンカとしていくつかのCAを登録してくれているのね。例えば、IEだったらこんな感じ。

ははぁ。ってことは、SSLやメール暗号化につかう電子証明書のCAとして、わざわざ自己署名証明書を入手しなくてもいいわけなんだね。

逆にいえば、ここに載っているCA以外から、電子証明書を発行してもらった場合、依拠当事者にそのCAの自己署名証明書を登録してもらわなきゃダメってこと。なので、普通ココに載っているCAを使うのよ。簡単だし、登録してもらう必要もないから。

そういえば、さっき、「個別認証と階層型の両方」っていってたけど？

WebモデルのルートCAとして、1つのCAでやってる場合もあるし、ベリサインみたいに大きなところはベリサインCA群で階層構造になってるわけ。例えば前回取得した電子証明書だと、こんな感じ。

前回発行してもらった電子証明書の発行元は「VeriSign Class 1 Individual Subscriber CA」。で、これの親CAが「VeriSign Class 1 Primary CA」。ブラウザはこの「VeriSign Class 1 Primary CA」をトラストアンカとしてるの。

へぇー。信頼のチェーンってこんな風に表示されるんだね。

Webモデルについては、また話すわ。で、次のモデル、「相互認証モデル」。さっきの階層型だと、「親子関係のCA」だったわね。でも、別々の独立したCAが提携した場合とかだと、「親子」にならないでしょ？ あくまでも「提携」なんだから。

そうだね。たぶん、どっちが「親」になるかで揉めそうだね。

そういう時に使われるのが、相互認証モデル。独立したCA同士が信頼しあう形ね。それぞれが相手のCAに対し電子証明書を発行するの。

相互認証証明書？ さっきの親CAが子CAの公開鍵を保証する電子証明書に似てるね。

というか、基本的には役割は同じね、相手のCAの公開鍵を保証する電子証明書よ。これにより信頼のチェーンを形成するわけね。

さっきの階層型が水平になった感じだね。

そうね。これで、自分のトラストアンカが相互認証しているCAが発行した電子証明書は検証できるようになるってことね。さっきの階層型同様、いちいち個別にCAを信頼しなくていいわけ。

うんうん。自社のCAだけトラストアンカとしておけば、提携企業グループ内だったら検証が可能になるってことだね。

でもね、ほげたん。例だとCAが2つだけだからいいけど、10社とかあったらどうなる？ とある会社のCAは他9社と相互認証しなきゃいけない。つまりフルメッシュ型になるのよ？

10個のCAがそれぞれ他のCAと相互認証するとなると、相互認証が複雑になるよね。

そうよね。図だと5つのCAだけど、相互認証の数も多いし、依拠当事者BがトラストアンカとしているCA3から、所有者Aまでのチェーンが通るパスもいくつもできてしまって、複雑になり、どのパスを使っていいかわからなくなってしまう。

ルーティングみたいだね。

そこで、最後の1つ。「ブリッジCAモデル」。ブリッジCAという中継点を使って相互認証を行う方式ね。

ははぁ、間にBCAをはさんで、相互認証をする方式なんだ。

そう、それぞれのCAはBCAとのみ相互認証を行うことにより、BCAを挟んだ相互認証の形を作るってことね。信頼のチェーンもBCAを間にはさんで作られるわけ。

このBCAを使うと、CAの数が多い場合でも相互認証の数も減るし、信頼のチェーンも１つのパスしか作られなくなるわけ。

うん、ずいぶんとシンプルになったよね。

実際、大規模な相互認証モデルはこのBCAを使うのが普通ね。さて、と。なんか今回は長かったわ。とりあえずまとめると、「電子証明書の保証をトラストアンカが行う」ってこと。

…なんか、今回の説明はその一言で要約された気になってきたよ。

そうねぇ、かなりの量で説明したけど、結局はそんだけのような気がしないでもないわ。
信頼モデルの話も、「トラストアンカが『所有者と公開鍵の結びつき』を保証する範囲を広げる」だけだしね。

トラストアンカと、親子だったり相互認証だったりするけど、信頼関係を結んだCAが発行した電子証明書は「トラストアンカが保証した」ってことになるわけだね。

そういうことね。

だよね。でもこれで、電子証明書も保証されて、もうなりすましも改ざんも否認も起きなくなったわけでしょ。よかったよかった。で、おね〜さん次回は？

ん〜〜〜〜。

ま、またその邪悪な、じゃなくって、含み笑い？ 何？ まだダメなの？ 足りないの？

足りないっていうか。まだ大事なことが抜けてるの。

……さっぱり想像つかないよ。もうOKだと思うんだけどなぁ…。

んふふ。それは次回のおたのしみ、ね。
おね〜さんと、

ほげたんのっ!!

3分間ネットワーク、

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