ここでの情報は、本やインターネットで調べたものです。
　　内容が間違っていないように注意したつもりですが、
　私が勘違いをしている可能性も多分に有ります。

　　もし、間違いに気付かれた場合はexcelsior@tokutoku.or.jpへのメールか、
　または掲示板でお聞かせください。

　　インターネットは不特定多数の人が参加できる、巨大なシステムといえます
　そのため、クレジットカードの番号など、秘密にしたい情報を送信する場合に
　関係のない第三者に知られず、安全に送信を行う必要があります。

　　そのために、情報を暗号化してから送信し、受信してから元に戻す手法が
　考えられました。これが以下に示すような暗号化技術です。

　　送信者と受信者が同じ鍵(共通鍵)を持つ手法です。
　　
　　AliceさんとBillyさんが通信を行ったとします。

　　A：自分の送りたい情報を共通鍵で暗号化する
　　A：暗号化した情報を送信する
　　B：受信した情報を共通鍵で復号化する

　　ポイントは以下です。
　　　・送受信者の両方が同じ鍵を使用する。
　　　・誰にも知られないよう、安全に共通鍵を送る方法が必要
　　　　　(共通鍵が盗まれれば、話になりません...)
　　　・暗号化/復号化の処理は高速
　　　・鍵の寿命は短い

　　送信者と受信者が一対の鍵(公開鍵/秘密鍵)を持つ手法です。
　　
　　AliceさんとBillyさんが通信を行ったとします。

　　A：自分の送りたい情報をBさんの公開鍵で暗号化する
　　A：暗号化した情報を送信する
　　B：受信した情報をBさんの秘密鍵で復号化する

　　つまり、公開鍵はAさんに送る時に漏洩する可能性があります。
　　しかし、公開鍵を盗んだところで、Aさんの送った情報を復号化すること
　はできません。できるのは、暗号化することだけだからです。
　　ですから復号化できるのは秘密鍵をもっているBさんだけなのです。

　　ポイントは以下です。
　　　・送受信者の両方が一対の鍵を使用する。
　　　　　(公開鍵：相手に手渡す。
　　　　　　秘密鍵：手元に置いておく(秘密鍵は決して人に渡さない！)
　　　・公開鍵で暗号化した内容は秘密鍵でしか復号化できない
　　　　　(公開鍵で暗号化して、公開鍵で復号化はできない)
　　　・暗号化/復号化の処理は低速(共通鍵に比べて)
　　　・鍵の寿命は長い

　　公開鍵方式の応用です。

　　"認証"とは、「確かにAさんが送信しました」という印です。
　　これは、暗号鍵で暗号化したデータは、対となる公開鍵でしか復号化
　できないことを利用します。
　　
　　AliceさんとBillyさんが通信を行ったとします。

　　A：自分の送りたい情報をAさんの秘密鍵で暗号化する
　　A：暗号化した情報を送信する
　　B：受信した情報をAさんの公開鍵で復号化する

　　つまり、公開鍵はBさんに送る時に漏洩する可能性があります。
　　しかし、公開鍵を盗んだところで、Aさんが送ったように見せかけて
　ウソの情報を暗号化してBさんに送ることはできません。
　　できるのは、復号化することだけだからです。
　　ですから、BさんはAさんの公開鍵で正しく復号化できた時点で、
　その情報がAさんからのものであることを確信できるのです。

　　ポイントは以下です。
　　　・送受信者の両方が一対の鍵を使用する。
　　　・暗号鍵で暗号化した内容は公開鍵でしか復号化できない
　　　　　(公開鍵で暗号化して、公開鍵で復号化はできない)

　　しかし、前提条件があります。
　　それは、間違いなくAさんの公開鍵である保証がいるということです
　　もし、手元の公開鍵が偽物なら、その偽物の鍵の対となる秘密鍵で暗号化した
　情報を復号化することになります。
　　つまり、偽物がAさんにすりかわってしまうのです。

　　このために、「認証局」という機関があります。
　　ここに、「××が本物の公開鍵です」という登録を行っておき、
　標準化された形式(x.509)の証明書を利用するのです。

　　これらの証明機関は、InternetExplorer(IE)であれば以下の手順で確認できます。
　　　１．IEの「ツール」から「インターネットオプション」を開く。
　　　２．「コンテンツ」タブの「証明書」ボタンをクリックする。
　　　３．「信頼されたルート証明機関」タブをクリックすると一覧が表示されます。

　　Netscape Communicator(ネスケ)では以下の手順です。
　　　１．ネスケの「ツール」から「セキュリティ情報」を見ます。
　　　２．「証明書」の「証明者」をクリックすると一覧が表示されます。

　　公開鍵方式の問題点は、処理に時間がかかることでした。　　
　　そのため送信したい内容全てを暗号化するのは大変です。

　　ですから、送信内容を第三者に読まれても構わないが、内容を
　変えられる(改竄される)のは困るという場合に、"署名"を行う手法があります。

　　まず、送信したい内容(元データ)からハッシュ関数によって
　ダイジェストを作ります。
　　ハッシュ関数とは、元データから固定長のデータを作る関数で、
　作られた固定長データから元のデータを復元することはできません。
　　そして作られた固定長データは、元データよりサイズはグンと小さくなります。
　　もちろん、元のデータの内容が変れば、ハッシュ関数によって求められる
　値も変ることになります。

　　そして、送信したい内容(元データ)はそのままの状態で、
　ハッシュ関数によるダイジェストは暗号化して送信します。

　　その情報を受信した人は、受信した内容(元データ)からハッシュ関数を
　つかってダイジェストを作成します。
　　そして、受信した暗号化されたダイジェストと比較をおこないます。
　　もし、自分の作ったダイジェストと、受け取ったダイジェストの内容が
　同じであれば、改竄は行われていないということです。

　_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

　　例として、またAliceさんとBillyさんが通信を行ったとします。
　　送りたいのは以下のような4桁の数字とします。

　　　Aさんの送りたいデータ：1357
　
　　では、各々の桁を足した値をダイジェストとしてみましょう。

　　　Aさんのダイジェスト：16 (= 1 + 3 + 5 + 7)

　　作ったダイジェスト"16"から、元のデータ"1357"を求めることはできません。
　"1933"や"4570"など何パターンも考えられるからです。

　　そして、送りたい値"1357"とダイジェスト"16"を送信します。
　ただし、ダイジェストは暗号化して"16"であることをわからなくしておきます。

　　が、関係のないChrisさんが間に割り込んでデータを一部書き換えてしまいました。
　最後の数字を"8"に変えてしまったのです。

　　　Cさんの改竄データ：1358

　　しかし、Aさんのダイジェストは暗号化されているので改変できません。
　　仮にダイジェストの求め方を知っていても、正しく暗号化することはできません。

　　そうして、Bさんには改竄データとダイジェストが届きました。
　受け取ったデータから、Bさんはダイジェストを作成します。

　　Bさんの受け取ったデータ：1358

　　Bさんのダイジェスト：17 (= 1 + 3 + 5 + 8)

　　Aさんのダイジェスト：16 (≠ 17)

　　Bさんは、自分の求めたダイジェストと、Aさんの送ってきたダイジェストが　　
　異なることから、途中で改竄が行われたことを知ることができます

　　もちろん、このようなダイジェストの作成方法は簡単すぎます。
　まぐれでダイジェストが"16"になる改竄であれば発見できません。

　　一般的に知られているハッシュ関数として「MD4」や「MD5」や「SHA」といった
　アルゴリズムがあります。
　　これらは公開されているものなので、誰でも使用できます。
　　また、同じハッシュ値を持つ違うデータを作るのも難しくなっています。

"セキュリティ"のページに戻る

トップページに戻る

左側にフレームのINDEXが表示されていなければクリック！