■ 改ざんの検出

おね〜さんと、

ほげたんのっ!!

3 Minutes Networking、

Supplement !!

さてさて〜っと。暗号化、共通鍵暗号と公開鍵暗号を説明したわけね。
これは「盗聴」という「脅威」の防御策として有効だ、っていう話なわけで。

でしたよ。暗号化することにより、復号できる「鍵」を持つ人以外読み取れなくなるからね。

じゃ、次行きましょう。「改ざんの検出」ね。

なんだっけ、第14回でいってたよね、「データのダイジェストの送付」だったっけ？

ん、んん〜。それは結論だから、順番に行きましょう。えっと、まず。
「データを受信した側はそれが改ざんされているかわからない」わよね。

え？ そうなの？ 見ればわかるんじゃないの？

はいはい、じゃ、前に出てきたコレみてね。

私はどうやったら、「ほげたんの元の発注量は10個で、改ざんされて100個になっちゃった」ってことを知ることができるのかしら？

どうやったら、って。僕が10個で発注したことを知ってれば…。

それは、送信される前の状態を知らなきゃダメよね。送信される前の状況を知るには？

送ったのと同じデータを、また送ってもらう…かな？

まぁ、2度も送ってもらうのは面倒だから、一緒に送ってもらうといいわよね。つまり、送信データと、その改ざん検出用の同じデータを送信するわけね。

確かにこの方法だと、改ざんが検出されるけどさ、おね〜さん。

はいはい、言いたいことはわかるわよ。ニセモノのブラックほげたんだって莫迦じゃない、って言いたいんでしょ？

そうそう。2つ送られてるなら、2つとも改ざんしちゃえばいいんだよ。

まぁ、そうよね。改ざん検出用のデータまで改ざんされたら意味がない。
じゃあ、改ざん検出用のデータは改ざんされない形式にすればいいと思わない？

そりゃそうできるなら、そうした方がいいよね。でも、そんな方法あるの？

あるわよ。改ざん検出用のデータを暗号化してしまえばいい。暗号化されたデータは改ざんされてもわかるから。

え？ そうなの？

暗号化したデータを改ざんすると、復号しても正常には戻せないから。そこでわかるってわけね。

え？ ええ？ なんで？

ちょっと考えてみましょっか。暗号文を改ざんするってことは、復号した時に平文がこちらが望む結果に書き変わっているってことよね。それって言うならば、暗号文そのものを作り出せるってことなのよ。

そう、なるかな？ う…ん、そうだね。復号した結果が望む平文である＝望む平文を暗号化した暗号文であるってことだから…。

暗号文を「鍵なしで生成した」ってことになるわけ。それは無理、でしょ？

それができちゃったら、暗号化破られたも同然だよね。

でしょ。というわけで、「暗号文は改ざんできない」。もし、復号結果はともかく闇雲に改ざんしたとすると、復号の際にエラーになったり、元の平文と異なるデータになっちゃうわけよ。

「元の平文と異なるデータになっちゃう」なら、元のデータと見比べれば、改ざんがあったかどうかわかるよね。

と、いうこと。さて、この改ざん検出用に送るデータを暗号化する方法だけど、公開鍵暗号化方式使った方が便利なのはわかる？

あれだね、鍵を秘密に交換する必要がないからだね。
じゃあ、宛先の公開鍵をもらって…。

ああ、そっちじゃなくて。送信者の秘密鍵で暗号化するわけ。
で、送信データ、改ざん検出用データ、送信者の公開鍵をまとめて送るの。

え？ そうなの？ でも、送信者の秘密鍵で暗号化したら、送信者の公開鍵で復号、だよね。
公開鍵は誰でも入手できちゃうから、誰でも復号できちゃうよ？

改ざん検出用データを暗号化するのは内容の秘匿が目的じゃないから、別に誰でも復号できて問題ないのよ。
それに、こっちの方式なら、事前に宛先の公開鍵を貰う必要もないし。

あ、そっか。

特に多くの宛先へ改ざんされていないことを証明しつつデータを送るには公開鍵を送る方が都合がいいのよ。

そだね、多くの宛先からわざわざ公開鍵を貰って、それで送る宛先に合わせて暗号化して…って面倒だしね。自分の秘密鍵で暗号化して、公開鍵をつけて送れば、復号できるしね。

そゆこと。別に内容の秘匿のためじゃないからね。
まぁ、まず動きを見てもらいましょ。

さて、これが公開鍵暗号を使った改ざんの検出なんだけど。要点はさっきと同じ、「データと検出用データが一致するか」ね。ただ、検出用データを改ざんされないように暗号化して送ったわけね。

うん。もしデータを改ざんしたとしても、それに合わせた検出用データを作らなきゃだめで。検出用データは送信者の秘密鍵で暗号化されているから、それが無理だって話だよね。

うんうん。さっきの「暗号文を鍵なしで生成」しなきゃダメだから、無理よね。
さてさて、ここで逆の発想で考えてみると。つまり「改ざんが検出されるのはどのような時か」というのを考えてみましょう。

(1)と(2)はいいわよね。問題は(3)、特に(3-1)(3-2)がポイントね。

「受信した公開鍵が、暗号化した秘密鍵とペアではない」から、復号がうまくいかなくなって変なデータになっちゃって。本データと一致しないって状況だね。

じゃあ、(3-1)(3-2)を踏まえた上で、改ざんが検出されなかった、ということは？

ん？ 秘密鍵と公開鍵が正しいペアであるってことでしょ？

そう、受信した検出用データは、受信した公開鍵とペアの秘密鍵で暗号化されているってこと。
これはつまり公開鍵の持ち主が作成したデータであるってことを示すわけでしょ？ これって何？

え？ えっと……。公開鍵とペアの秘密鍵は、公開鍵の持ち主しか持っていない。
だから、暗号化したのは公開鍵の持ち主だってわかる。持ち主がわかる？ そうか、認証だ!!

うん、そうよね。公開鍵の持ち主に「なりすまし」をしたとしても、復号はうまくいかない。だから、データの作成者の正しさを証明することができるってわけ。つまり、公開鍵暗号化を使うことにより、改ざんの検出と認証ができるってことなわけよ。

なるほどなるほど。送信者の秘密鍵で暗号化、送信者の公開鍵で復号の使い道はコレなんだね、おねーさん。

■ ハッシュ関数

そうね、前回の最後でいっていた「送信元は自身の秘密鍵で暗号化」「受信した宛先は送信元の公開鍵で復号」っていう、公開鍵暗号化の説明2はコレのことね。

暗号化にも使えて、改ざん検出と認証にも使えるなんて、すごい技術だね公開鍵暗号化。

すごい技術なんだけど、前回の公開鍵暗号化の特徴を思い出しながら、ココを見て。

わかる？ ココがこの改ざんの検出方法の問題点なのよ。

秘密鍵で暗号化？ 公開鍵暗号化の特徴？ 「鍵の受け渡し問題がない」「不特定多数との通信に向いてる」「鍵の役割の入れ替えができる」「暗号化/復号処理のスピードが遅い」………あ…。

そう、この方法だと、秘密鍵による暗号化と公開鍵による復号処理に時間がかかりすぎるってのが問題点なのね。あと、純粋に送信するデータ量が2倍になるってのもちょっと問題よね。

そっかぁ。データ量が倍になるうえ、遅くて遅くどうしようって感じの公開鍵暗号化で暗号/復号が必要になっちゃうのか。それは問題だね。

でしょ、理解してもらってうれしいわ。でも、この「改ざん検出と認証」という2つの役割を持つ方法を捨てるには惜しい。ってことで、ここで登場するのが一方向ハッシュ関数ね。

ハッシュ関数？ ハッシュ関数ってアレだっけ、ビット列から別のビット列を作り出す関数だったっけ。

そう、それ。パパの3Minutes Networkingでも登場したわね。

うんうん。これがどう関連するの？

一方向ハッシュ関数と一方向ハッシュ関数から作られたビット列（ダイジェスト）は、次のような特徴を持っているわね。

まず、(3)を考えてみると。2つが同じモノであるか比較するという点ではデータとダイジェストは等価であると言えるわね。

え？ え？ どういうこと？

2つが同じモノであるか比較するのに、データ同士を比較するのと、ダイジェスト同士を比較するのは一緒、ってことよ。
もし2つのダイジェストが等しいならば、その元の2つのデータは等しいって言える。

そう、なるのかな？ 1ビットでも違うデータからは、違うダイジェストが生成される。逆に、データが同じなら同じダイジェストが生成される…。

そゆこと。

あ、わかった。検出用データとしてダイジェストを使うってこと？

んふふ。その通り。データ同士を比較するのも、データから生成されたダイジェスト同士を比較するのも等価。さらに、(1)と、さっきの改ざんの検出法の問題点を合わせて考えると？

ダイジェストは固定長の100〜200ビット程度のビット列。公開鍵暗号化でもそんなに時間はかからないし、送信するデータ量としても多くない。

はい、ほげたん、正解。

うんうん。ダイジェストの特徴から考えると、確かにコレでもいいよね。っていうか、こっちの方が「暗号化/復号にかかる時間が短い」「データ量が少ない」からいいよね。

でしょ。さて、実際に使われている一方向ハッシュ関数としては、MD5やSHAが有名ね。

一番有名なのは、MD5だけど。脆弱性が見つかったので、あまり使用が推奨されていないわ。SHA-1か、より出力するダイジェスト長の長い、SHAを使うのがいいわね。日本政府だと、SHA-256以上を推奨、だったかしら。SHA-1でもよかったけど、できればだったかな？

ふむふむー。SHA-1以上ってことだね。………おね〜さん、ちょっと思ったんだけどさ？

何？

「暗号化されると改ざんできない」だったよね。だったら、データそのものを暗号化して送ればいいんじゃないかな。わざわざこんな方法とらなくても。

ん。まぁ、そう考える気持ちはわかるわ。でもでも、もうちょっと考えてみましょ。
まず、「盗聴の防止」と「改ざんの検出」は別々の技術としてあった方がいい、これはいい？

なんで？ 両方できると便利じゃん。

便利だけどね。例えば、公的な文書があるとするわよ。これは読む人は限定したくない。でもその一方で、改ざんされたり、なりすましされるのは困る。暗号化する必要がない、するまでもないけど、改ざんとなりすましは防ぎたいわけね。

みんなに見てもらいたい文書だけど、改ざんとなりすましは防ぎたい。うん、それは確かに、一般公開する文書とかはそうだね。

次に、改ざん・なりすまし防止で使うには共通鍵暗号化は使いづらい。鍵の受け渡しと数の問題ね。
さっきも話したけど、複数人に改ざん・なりすまし防止した文書を渡したい、または一般公開したい時では共通鍵暗号化は使用に問題があるからね。

そうだね。となると、公開鍵暗号化ってことになるね。
でも、「宛先の公開鍵で暗号化」「宛先の秘密鍵で復号」の方式も、「宛先の公開鍵」を個別で受け取らなきゃだから、同じだね。

でしょ。そうなると、「送信元の秘密鍵で暗号化」「送信元の公開鍵で復号」が最適よね。
でも、送信したいデータを暗号化するのは、公開鍵暗号化では？

処理速度が遅すぎる…。
そこで、ダイジェストを暗号化したものを、検出用としてくっつける…。

ほら、やっぱりこのダイジェストを使った方式がベストでしょ？

うん。理解したよ。

■ ディジタル署名

この「公開鍵暗号化を使った改ざん検出・認証」の仕組みを、「ディジタル署名」と呼ぶの。

でぃじたるしぐねちゃ。ディジタルなサイン？

そう。改ざん防止、なりすまし防止には文書にサインする、日本では捺印、が紙媒体ではよくおこなわれるでしょ。

サイン・捺印された文書を偽造・改ざんしたり、なりすますためにはサイン、印鑑を偽造しなきゃいけないから、その防止として使われてるね。

でしょ。このサイン・捺印と同じ機能を果たすのが、このディジタル署名。
これは、2つのステップから成り立ってるのはわかるわよね。「署名」と「検証」ね。

えっと、ダイジェストを生成して自身の秘密鍵で暗号化するのが署名？

そうそう。そして、この署名で作成された秘密鍵で暗号化されたダイジェストを署名データと呼ぶのね。

受信者が公開鍵で署名データを復号し、送信データからハッシュ関数によって生成したダイジェストと比較するのが検証ね。

ふむふむ。署名と検証、なるほど。

この検証の結果、がOKかNGか。OKならば改ざん・なりすましはないし、NGなら改ざんかなりすましが行われていたってこと。

うんうん。さっきあったよね。改ざんがあったりすると比較が一致しない。認証が、つまり鍵と暗号文が一致しないと復号失敗したり、変な復号文になってやっぱり比較が一致しない。

そう、さっき話したわよね。ちなみにこの役割から、秘密鍵を「署名鍵」、公開鍵を「検証鍵」と呼んだりしたり。

ははぁ…。あ、そうか。前回の公開鍵暗号化の処理スピードの画像。

これの「sign」が秘密鍵、「verify」が公開鍵による処理スピードって、この「署名鍵」と「検証鍵」から来てるんだ。

そゆことね。さて、ディジタル署名の技術はわかったかな？

OKだよ、おね〜さん。ディジタル書名により、改ざんとなりすましの防止、でもって改ざんもなりすましも防止されることにより、否認も防止されたわけだよね。

ん〜〜〜、それはどうかしら？

えぇぇ!! だって、ほら、ディジタル署名を使えば検証されて大丈夫じゃない？ 何か問題が？

確かに、ディジタル署名は改ざん・なりすまし・否認を防止する「技術」だわ。だけど、この「技術」だけでは完全に防止できないのよ。

じゃ、じゃあ。別の技術が…。

いえ、もう「技術」的にはこれでOK。

？？？ どういうこと？

んふふ。やっとPKIの話をできるわね、つまり「環境」の話。

環境…？

それが次回の話。じゃ、まった次回。
おね〜さんと、

ほげたんのっ!!

3分間ネットワーク、

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