3 Minutes NetWorking Supplement
No.17

3Minutes NetWorking Supplement

補講第17回PKI(4) ダイジェストとディジタル署名

■ 改ざんの検出

おねーさん

おね〜さんと、

ほげたん

ほげたんのっ!!

おねーさん

3 Minutes Networking、

ほげたん

Supplement !!

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

[FigureSP14-02:脅威:改ざん]

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

[FigureSP17-01:改ざんの検出]

ほげたん

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

おねーさん

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

[FigureSP17-02:改ざんの検出・2]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

え? そうなの?

おねーさん

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

ほげたん

え? ええ? なんで?

おねーさん

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

ほげたん

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

おねーさん

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

暗号文の改ざん

[FigureSP17-03:暗号文の改ざん]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

あ、そっか。

おねーさん

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

ほげたん

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

おねーさん

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

[FigureSP17-04:改ざんの検出と公開鍵暗号]

おねーさん

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

ほげたん

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

おねーさん

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

  1. 本データが改ざんされて、検出用データと一致しない
  2. 検出用データが改ざんされて、本データと一致しない
  3. 復号がうまくいかず、復号した検出用データと本データが一致しない
    1. 受信した公開鍵が、暗号化した秘密鍵とペアではない
    2. 暗号化した秘密鍵が、受信した公開鍵とペアではない
    3. 受信した公開鍵が改ざんされた
おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

■ ハッシュ関数

おねーさん

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

ほげたん

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

おねーさん

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

改ざんの検出法の問題点

[FigureSP17-05:改ざんの検出法の問題点]

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

[Figure77-09:一方向関数・ハッシュ関数]

ほげたん

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

おねーさん

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

  1. どんなデータからも固定長のダイジェスト(100〜200ビット程度)を作る
  2. ダイジェストから元のデータは生成・類推できない
  3. 1ビットでも異なるデータからは、異なるダイジェストが生成される
おねーさん

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

ほげたん

え? え? どういうこと?

おねーさん

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

  • データAから作られたダイジェストA
  • データBから作られたダイジェストB
  • ダイジェストA=ダイジェストBならば、データA=データB
ほげたん

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

おねーさん

そゆこと。

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

はい、ほげたん、正解。

[FigureSP17-06:改ざんの検出と認証・改良版]

ほげたん

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

おねーさん

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

関数名ダイジェスト長
MD5128
SHA-1160
SHA-224224
SHA-256256
SHA-384384
SHA-512512

[TableSP17-01:一方向ハッシュ関数]

おねーさん

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

ほげたん

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

おねーさん

何?

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

うん。理解したよ。

■ ディジタル署名

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

署名処理と署名データ

[FigureSP17-07:署名処理と署名データ]

おねーさん

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

検証

[FigureSP17-08:検証]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

公開鍵暗号化方式の処理速度

[FigureSP16-06:公開鍵暗号化方式の処理速度]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

??? どういうこと?

おねーさん

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

ほげたん

環境…?

おねーさん

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

ほげたん

ほげたんのっ!!

おねーさん

3分間ネットワーク、

ほげたん

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

ダイジェスト
[Digest]
他にも「ハッシュ値」「フィンガープリント」などとも呼ばれる。
MD5
[Message Digest 5]
一般的なハッシュ関数で使われている技術も多い。
SHA
[Secure Hashing Algorithm]
MD5よりも強固なハッシュ関数。現在ではMD5に代わり頻繁に使われている。読みは「しゃー」
ディジタル署名
[Digital Signature]
「公開鍵を使った電子署名技術のこと。電子署名[Electronic Signature]は「電子文書に署名する」ことで、ディジタル署名は電子署名に使われる技術の1つ。
ほげたんほげたんの今日のポイント
  • 改ざんの防止(検出)のため、検出用データを付加して送信する。
  • 検出用データは公開鍵暗号化方式を使って暗号化する。
  • 検出用データは一方向ハッシュ関数を使って生成する。
  • これらの処理をディジタル署名と呼ぶ。
  • ディジタル署名により、改ざん・なりすまし・否認は技術的には防止できる

3 Minutes NetWorking Supplement No.17

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