公開鍵暗号－その４－

引き続き、公開鍵暗号についての一般的な話を紹介します。
以下、2人の会話をご覧ください。

せんぱ～い (^ー^)

おっ。
頭の中、整理できた？

大丈夫ですよん。
むしろ、今のうちに全部聞いちゃったほうがいいかもしれません。(・ω・)b

それもそうだネ。
じゃあ、さっさと終わらせてIPsecの話に移ろう。

本来の目的、すっかり忘れてました。ヾ（´▽｀;ゝ
今度こそ、今度こそなんて言って、なかなか進みませんでしたから。

はは。。。(^o^;;
まぁ、進んでないんじゃなくて、もっとやることがあったのを忘れてただけなんだけど。

でも、そのおかげで頭の中が切り替わったというか、、、
良い意味で、理屈っぽく考えることが出来るようになった気がします。

おぉ、それはよかった。(*´ω｀*)
でも、そういう頭の切り替えはセキュリティの話をするときだけにしてね。

えっ、何でですか～？ (￣△￣；

理屈っぽいヤツは嫌われるからネ。
日常会話には適さないかと。(-ω-｀ )

あ、それ分かります。
イメージ的には、メガネの端をクイッと上げながら話すカンジ？

うーん、まぁそんなカンジ。

でも、そういう人は意外に恋愛話とか苦手だったりして、、、
恋の掛け算は苦手、みたいな？ヽ(´▽｀)

いや、そこまでは知らないけど、、、（￣◇￣；
っていうか、恋の計算は掛け算で出来るのか？ヽ(^_^;)

さ、さぁ、、、？
なんとなく、語呂で言ってみただけです（;´▽`）ノ

掛け算で出来たら、誰も苦労しないよなぁ。。。
恋の計算の難しさに比べたら、公開鍵基盤なんてチョロいもんです。d(>_< )

せんぱい、、、(;ﾟдﾟ)
なんか、過去に苦労した経験でもあるんですか？

い、いや、、、
別に、そういうワケじゃないけど（￣◇￣；

ホントですかぁ～？(￣△￣)
なんか、とっても気持ちがこもった言い方でしたよ？

むっ、ヤケに食い下がるなぁ。
あいにく、お年頃の女子が喜ぶような話は持ってないッス。（;´ー｀）

あらら、残念。
面白い話が聞けると思ったのに。(-ω☆)

コラッ(ﾟДﾟ;)
他人の恋愛話をオモチャにしちゃいけません！

は～い。(ＴεＴ;）

まぁ、世の中ギブアンドテイクということで、、、
何か話してくれたら、こっちから話してもいいけど？

いや、後々までネタとして利用されそうで、、、
リスク高そうなので、やめときます。ε=(´∇｀;)

あらら、残念。
面白い話が聞けると思ったのに。(-ω☆)

あっ、私と同じセリフ。∑(￣口￣*)
なぜか、負けた気がして悔しい。。。

わっはっは。ヾ(￣▽￣ )
スッキリしたところで、本題に入ろうかな。

むぅーーーっo(;-_-;)o

えと、、、
どこまで話したんだろう？

公開鍵基盤での認証局の立ち位置と、基本的な役割が分かったところです。
秘密鍵の管理と、証明書を発行するユーザの状態確認が必要なんですよね？

そっか。
あまり深いことをやるつもりないので、あとは実際の手順とかの話が出来れば終わりだよ。

なんか、手順って面倒くさそうですネ。
いっぱい書類を書かなきゃいけないとか？

実際の運用では書類が必要だろうけど、まず先に技術的な話をしよう。
まず、ユーザが鍵ペアを作る、もしくは既に作ってある。

みんなに使ってもらいたい公開鍵のペアですね。

で、自分の識別情報を公開鍵に付けて、証明書のモトになるデータを作る。
このデータを、証明書発行要求という。

証明書を発行する要求、そのまんまですね。（＾-＾）

認証局がこのデータを受け取って、その他の必要な属性を付加して署名し、証明書が完成。
この証明書をユーザに返して、発行処理は終了だよ。

あれれ、意外とアッサリ終わりましたね。（・・
もっと複雑な仕組みを想像してたんですが。

いや、細かい手続きを気にしなければ、ホントにこれだけだよ。

アレッ？
ユーザの状態を確認する作業は、どこに行っちゃったんですか？

あぁ、証明書を発行する手前のところだね。
書類が必要になるとしたら、この部分だよ。

なるほど。
証明書発行要求と書類を認証局が受け取って、証明書を発行していい相手かどうかを確認してから発行するわけですか。(´・ω・`)ｂ

確認したい内容によって書類の中身も変わるだろうから、手続きが複雑になるのかどうかは、ここで決まるんだね。

社員に発行するという条件だったら、ユーザの名前とか社員番号ぐらいでよさそうですね。

うん。
あとは、あっても上司の承認ぐらいじゃないかな？

あ～、なんとなく現実とリンクしてきました。
証明書発行要求とやらを作るのは、素人でも簡単に出来るんですか？

いや～、どうだろうな。（￣～￣;
手順書があれば出来るかもしれないけど、よく分からない作業は基本的にやってくれないんじゃないか？

普通の人は、何やってるか分からないんじゃないですかねぇ？

まぁ、分かんないだろうね。
そういう場合は、認証局でユーザの鍵ペアまで作ってしまい、証明書と秘密鍵をセットにしてユーザに渡す、という方法もあるよ。

ん、それってアリなんですか（？＿？）
なんか、違和感がありますけど。。。

おっ、鋭いね。
どの辺に違和感？

単純に、秘密鍵はユーザ自身が持ってなきゃいけないような気がする、っていうだけなんですが、、、
認証局もユーザの秘密鍵を知っているというのは、問題ないんですか？

まったく問題ないとは言わないけど、みんなが信頼している相手なので、そこはよしとする。
それよりも、秘密鍵を安全な方法でユーザに渡さなきゃいけないことが問題だ。(´・ω・`)ｂ

あ～、ソレですよ！(*・o・)
手元で作った秘密鍵は外部に晒されることがないけど、認証局で作ったらユーザに渡すところで一時的に晒されちゃいますから、あまり良くないですよね？

そそ。
いちおう、パスフレーズを付けて暗号化できるようになってるけどね。

でも、それだと、、、
ユーザに渡ったあとは証明書認証の運用に入りますけど、その直前まではパスフレーズ認証に頼っていることになりませんか？

むぅ、鋭いツッコミにグーの音も出ない。。。
と言いたいところだけど、そこを運用でカバーする。

運用でカバー？＿？
もしかして、ここで何か新しい手法が登場するとか？

いや、登場しないよ。
以前に、鍵配送問題とハイブリッド暗号っていうのがあったでしょ？

あ、覚えてますよ。
鍵を安全に渡せる経路があるなら、最初からその経路でデータを送ればいいじゃん、でしたよね。(・ω・)b

そう、それ。
いま問題になっているのは認証局からユーザに鍵を渡す部分の話なので、鍵配送問題に該当しないように安全な経路で鍵を渡せたら、セキュリティのレベルは落ちないと考える。

うーん、理屈は分かります。
でも、鍵配送問題の話のときはハイブリッド暗号の話も出てきたし、余計に複雑な仕組みになってしまいませんか？（￣～￣;

いや、もっと単純に考えればいいんだよ。
もしユーザが本当に社員だったら、本人に証明書のような小さいデータを渡す方法なんていくらでもあるデショ？

？＿？

本人にメディアで手渡しとか、遠い場所の人でも社内便とか。
仕組みによっては、社内サイトなどから取得してもらってもいいかもしれない。

！＿！

要するに、社員でなければ成立しない渡し方にしちゃえばいいんだよ。ｄ(*￣o￣)
もともと社員にしか渡したくないんだから条件としてもピッタリだし、むしろ受け取れるということが社員であることの確認にもなるから、まさに一石二鳥だよね。

。。。
ポロッ

んっ？
何か落ちたよ？

目から、、、
ウロコが、キレイに落ちました。。。

そ、そうか。。。（・・；）

もっと、広い視野でモノを見なければいけないと思いました。。。

そんな、大げさな。。。（;´▽`）
でも、確かに我々は「システム」と聞けばハードとかソフトとか、機械的または電子的に解決することを重視しがちかもしれないね。

今、まさにその状態でした。ε=(´∇｀;)
常識的に考えたら、本人に直接渡すのが一番安全に決まってますよね、、、

今の話の場合は相手が同じ組織内にいるわけだから、なおのこと。
結局、パスフレーズによる秘密鍵の暗号化はオマケみたいな位置付けで、仕組みとしては大して頼ってないわけ。

そうですね。
さっき、鬼の首を取ったように反論していた自分が恥ずかしい、、、＞＜；

でも、社内だから安全だと言い切れないような環境だったら、確かにパスフレーズへの依存度が高まるよね。
それに、どんなに安全な経路を使って渡したとしても、渡さなくてすむことのほうが安全なのは間違いないよ。

はい。

さらに言うと、受け取ったユーザが鍵をズサンに扱って、社外に漏れるケースも考えられる。
そうなったら、もうパスフレーズだけが頼りだね。

パスフレーズは、どっちかというと保険みたいなものなんですネ。(-ω-｀ )

そうだね。
でも、実際の運用では渡し方を考えるのが面倒臭くて外部や内部を問わずメールで送っちゃうこともあるし、パスフレーズ認証ありきの仕組みで動かしてることもあるよ。

漏れる可能性があるのはユーザに渡すまでの短い間だから、許されちゃってるんですね。(´･ω･`)

まだ世の中的に、認証に関して今のところはパスフレーズのような「合言葉」を使った仕組みで充分、という認識があるからね。
認証全般に対する認識のボーダーラインが上がってくれば、そのラインからこぼれた部分が自然と見直されていくんじゃないかな。(-^ー^-)

そういえば、現実社会の認証は合言葉がほとんどですね。
少し前までは、銀行口座の認証が4桁の数字だけだったくらいですから。（ｰ'`ｰ;）

確かに、本人からカードを盗む必要があるとは言っても、4桁の数字が合えば使えるっていうのは厳しいな。。。（;￣ー￣）
でも最近は、ICチップとかバイオメトリクスを組み合わせるようになったね。

ICの中身も、やっぱり証明書なんでしょうか？

さぁ、そもそも仕組みが公開されてるのかどうか。。。
でも、たぶんそれに近いものだと思うけどね。

そういう場合だとユーザに証明書発行要求なんか作ってもらえるワケがないから、やっぱり証明書を認証局から振り出す仕組みは必要なんですね～(・ω・)

デバイスがカードになっている時点で、ユーザに何か頼むのはムリだろう。
そもそも、デバイスを読んだり書いたりする手段がない。

そっか、、、
でも今の話で、証明書を認証局からユーザに発行せざるをえない場合もある、っていうことは理解できましたよ。(・ω・)b

そりゃよかった。
結局、ここで言う「運用でカバー」とは、認証局からユーザに鍵を「充分に安全と考えられる手段で」渡す方法を採用することで、渡さない場合と同等またはそれに近いレベルに持っていくことを指していたわけ。

なるほど～。
セキュリティのレベルをあまり落とさずに、サービスの質を向上させたわけですね。

あと残っている話は、、、
証明書の失効ぐらいかな。。。

失効っていうことは、発行した証明書を使えなくするっていうことですか？

そう。
たとえばユーザが会社を辞めたりして、権利を失ったときとか。

あ～、確かに必要ですね。
でも、いったん配っちゃったものをどうやって失効させるんですか？

何か物理的なモノだったら回収すればいいけど、証明書はデータだから、当然それはムリ。ヽ(´▽｀)
そうなると、生きている証明書を何らかの方法で無効化するしかないね。

え～っ、そんなこと出来るんですか？＿？

簡単に言うと、失効させた証明書の一覧を作るんだよ。
いわゆる、ブラックリストみたいなものだね。

提示された証明書を受け取った人は、まず証明書の正当性を確認したうえで、失効されていないかどうか確認しなきゃいけないんですね。
普段使ってるWebブラウザとかも、そんなことやってるのかな～？＿？

設定次第だけど、やってるはずだよ。
証明書を渡してきた相手を疑っているわけだから、チェックは自分でやるしかないデショ？

うーん、ごもっともです（;´ー｀）
そのリストには、具体的に何が書いてあるんですか？

証明書の中には一意なシリアル番号があるので、それがズラズラ書いてあるだけ。
そこに書いてあるシリアル番号を持っている証明書は、失効されていると判断できる。

へぇ、、、
意外とシンプルなんですね。

そそ。
でも、これで証明書の発行と失効が出来て、理論上はきちんと公開鍵基盤の仕組みが出来上がる。

認証局は、認証に関する全責任を負わされますね。
コケたら、大変なことになりそう。。。（￣◇￣；

はぅあ！
全責任と聞いて、思い出した。。。（￣◇￣；

むっ。
まだ何か残ってましたか？

認証局は単一とは限らなくて、ツリー構造になっている場合もある。
最後に、この話だけさせてくれ。

うーむ、やっぱりPKIは奥が深いですネ。(`･ω･´)
恋の計算のほうが簡単だったりして、、、(=ﾟωﾟ)ノ

はは、、、（;￣ー￣）
答えが存在しない時点で、恋の計算は他のどんな計算より難しいんじゃないかな？

おっ。
せんぱい、なかなかオツなことを言いますね～(-ω☆)

答えが存在しないからこそ、みんな夢中になるんだよ。（*´v｀*）

あら～、恥ずかしいセリフが出ちゃった、、、（＾－＾；；；；；

以下、「PKIと認証局－その１－」につづく。。。

ネットワークセキュリティ関係者の部屋 > ネットワークセキュリティ実践劇場 > 公開鍵暗号

お品書き

公開鍵暗号－その４－