ツイッター掲載中ないだネットワークです。それらの自律ネットワークは、ＩＰと
いう最低限の通信ルールには従うものの、それぞれ異なる管理ポ
リシーを持っているので、流れてくる情報に悪さをする組織や管
理者がいる可能性があります。
「インターネットはバケツリレー」といわれますが、例えば、
メールのデータなどは、そういう得体のしれないゾーンをリレー
されながら、届けられているのです。このように、何もセキュリ
ティ対策を施さないで大事な情報をメールで送受信することは非
常にリスクがあります。
９月２２日のＥＪで、メールに重要文書を添付し、その文書の
ハッシュ値を付けて相手に送ることを紹介しました。この場合、
メールの受信者が添付の重要文書のハッシュ値を算出し、送られ
てきたハッシュ値と一致すれば、文書の改ざんがないことの証明
になります。
しかし、これはわかりやすく説明するためにそのように書いた
もので、万全の対策ではないのです。なぜなら、何者かが、ハッ
シュ値そのものを改ざんしてしまえば、その目的が果たせなくな
るからです。少なくとも、文書とハッシュ値は同じメールで送る
べきではなく、別なメールで送るべきであります。
『ブロックチェーン』（講談社／ブルーバックス）の著者の岡
嶋裕史氏によると、メールのメッセージに対して、何か悪さをし
てやろうとするパターンには３つあるとしています。メールとそ
のメールのハッシュ値は別便で送ることを前提にしています。
第１のパターンは、「本文のメールだけを首尾良く捕まえ、改
ざんし、本物の送信者に成りすまして再送信できた場合」はどう
なるかです。
このケースでは、本文のメール（添付ファイルを含む）に改ざ
んが行われた場合ですが、メールのハッシュ値は別便で到着して
いるので、到着したメールのハッシュ値を求め、別便のハッシュ
値と照合すれば、メールの改ざんは明らかになります。もちろん
ハッシュ値の方が改ざんされている可能性もあります。
第２のパターンは、「メールのハッシュ値だけを首尾よく捕ま
え、改ざんし、本物の送信者に成りすまして再送信できた場合」
はどうなるかです。
これは、第１のパターンの裏返しです。ハッシュ値も改ざんで
きます。改ざんが行われてもメールの本文はちゃんと届いていま
す。この場合はメールの本文のハッシュ値を求め、送られてきた
ハッシュ値と照合すれば、メールの本文かハッシュ値のいずれか
が改ざんされていることになります。
第３のパターンは、「悪意の第三者が、本文のメールも、ハッ
シュ値のメールも取得し、本物の送信者に成りすまして再送信で
きた場合」はどうなるかです。
これはやっかいです。これは「中間者攻撃」といって、すべて
を改ざんすることができ、しかも、送信者も受信者も改ざんに気
が付かないからです。
これについては、メールのやり取りについての詳しい知識が必
要です。正規のメールのやり取りは、送信者のメールサーバーか
ら、受信者のメールサーバーへと送信されるのですが、その中間
に悪意ある第三者が割り込むことに成功すれば、メールの送受信
を中継することによって、何でもやりたい放題ができることにな
ります。これが「中間者攻撃」です。
どのようにして、メールが相手に届くのかについては、いずれ
ＥＪで取り上げて説明します。この「中間者攻撃」について、岡
嶋裕史氏は、次のように述べています。
─────────────────────────────
これは正規の送信者にとっても、正規の受信者にとっても悪夢
である。そんな都合のいいことができるのかと思うかもしれない
が、たとえば単純な手法として中間者攻撃がある。（中略）
この場合、メールの中継をしている悪意の第三者は、メールの
本文もそこから導かれるハッシュ値も、自分で作ることができる
ため、メールの改ざんが事実上、可能になる。
メールの本文を自分の都合のよいように書き換え、そこから作
った（矛盾しない）ハッシュ値を、本文とともに耳をそろえて受
信者に送ることができるので、受信者が本文からハッシュ値を計
算して、改ざんが行われていないかチェックしようとしても、中
継者である悪意の第三者の改ざんを見破ることができない。
岡嶋裕史著
『ブロックチェーン／相互不信が実現する新しいセキュリティ』
ブルーバックス／講談社刊
─────────────────────────────
これを防ぐ方法がひとつあります。メールの送信者と受信者の
間で２人しか知らない共通鍵を決めておきます。これを「１２３
４５６」とします。「明日１０時ね」というメールを送信するさ
い、別便で「１２３４５６明日１０時ね」のハッシュ値を算出し
て、それを送ります。
一方、受信者は、届いたメールの本文に改ざんがないか調べる
ときに、本文の頭に共通の鍵付けて、「１２３４５６明日１０時
ね」でハッシュ値を算出し、別便で送られてきたハッシュ値と照
合します。この場合、一致するとメールの本文には改ざんがない
ことになります。
中間攻撃者は、この共通鍵の存在を知らないので、仮にメール
の本文を「来年１０時ね」と書き換えて、それを本文として本人
に成りすまして送信します。そして、メールで本文である「来年
１０時ね」のハッシュ値を算出して、それを別便で送ります。こ
の場合、受信者はメールの本文とハッシュ値のいずれも一致しな
いので、改ざんを見破ることができます。
問題はその共通鍵を送信者と受信者がどのようにして持つかに
ついては非常に難しい問題になります。
──［デジタル社会論Ⅲ／０３２］
≪画像および関連情報≫
●共通鍵暗号方式／「日経ＸＴＥＣＨ」
───────────────────────────
暗号化されていないデータのことを平文と言います。そし
て平文に対して，鍵と暗号化のためのアルゴリズムを適用し
て、データを変換したものが暗号文になります。暗号文に鍵
と復号のためのアルゴリズムを適用して変換すると，また元
の平文に戻ります。
ここで，暗号化する時と復号する時に同じ鍵を利用するの
が共通鍵暗号方式です。対称鍵暗号方式と呼ばれる場合もあ
ります。また，それぞれの鍵を秘密に管理する必要があるた
め，秘密鍵暗号方式と呼ばれる場合もあります。
例えば添付ファイルの図で「ＡＢＣ」という文字列が本来
伝えたいデータ（平文）、これをアルファベットの並び順に
３文字ずらしたもの「ＤＥＦ」を伝送経路に送信し，受け取
った側で３文字戻して元のデータ「ＡＢＣ」を読み取るとし
ます。この場合，「３文字」の部分が鍵に相当します。暗号
化のアルゴリズムは「ずらす」，復号のアルゴリズムは「戻
す」です。送信者が本来伝えたい文字列は「ＡＢＣ」ですが
アルファベットの並び順に３文字ずらした状態「ＤＥＦ」が
暗号化された状態になります。万が一，悪意のある第三者が
盗聴に成功したとしても，入手できる文字列は「ＤＥＦ」で
あり，正しい文字列「ＡＢＣ」を得ることができません。し
かし受信した側では，あらかじめ入手しておいた鍵（「３文
字」という情報）を用いて３文字戻すことによって元の文字
列「ＡＢＣ」を得ることができます。
https://bit.ly/3EE4kO3
───────────────────────────
共通鍵暗号方式
