データ通信時の4つの問題
インターネット上でのデータ通信時に起こりうる代表的な問題として下記の４種類がある。
| 項目 | 説明 | 対策 |
|---|---|---|
| 盗聴 | 伝送路上でメッセージが盗み見される | 暗号化 |
| なりすまし | 通信相手になりすまし、 データを盗まれる |
メッセージ認証コード or デジタル署名 |
| 改ざん | メッセージを書き換えて伝達する （通信障害によるデータ破損も含む） |
メッセージ認証コード or デジタル署名 |
| 事後否認 | 『自分が実行したものでない』と否認する | デジタル署名 |
具体的なイメージは次のような感じ。
暗号化
通信データを盗み見されても困らないようにするために、メッセージを暗号化してしまえばよい。
データを暗号化する方法は、主に次の2つに分類される。
| 方式名 | 概要 | 暗号方式 | 課題 |
|---|---|---|---|
| 共通鍵暗号方式 | 暗号化と複合で同じ鍵を使う | シーザー暗号、AES*、 DES、ワンタイムパッド |
鍵配送 |
| 公開鍵暗号方式 | 暗号化と複合で別々の鍵を使う | RSA暗号*、楕円曲線暗号 | 公開鍵の信頼性 暗号化・復号の処理が重い |
*付きが現在の主流。
いずれも課題があり、共通鍵の場合は『どうやってインターネット上で鍵を交換するか？』、公開鍵の場合は『信頼性をどう確認するか？処理が重い』などがある。下の公開鍵の例では、鍵交換時に公開鍵をすり替えられてしまうと、中間者によって盗み取られてしまう。また盗み取った情報を本当の通信相手に対しては、通信相手の公開鍵で暗号化してから送信することで、データが盗まれていることも判断できない。(man-in-the-middle攻撃)
ハイブリット暗号方式
上記の課題のうち、まずは処理時間について対策を打つ。共通鍵の方が公開鍵を用いる方法よりも、暗号化・復号の処理速度が早いため、なんとか共通鍵で暗号通信したい。共通鍵の課題は『どうやって安全に鍵を交換するか』という鍵配送問題であった。
結論としては、『公開鍵を利用して共通鍵を配送』してあげれば良い。イメージは次の通り。
その他の鍵交換の方法として、『ディフィ-ヘルマン鍵交換法』というものもある。これは、公開されても良い情報を２者間で交換するだけで、両者の鍵を交換できる方法。実際には、鍵を交換しているのでなく、公開されても良い情報を用いて通信用の鍵を合成し生成している。
メッセージ認証コード
上記の鍵交換方式によって、共通鍵で安全に通信できるようになったが、まだ『認証』と『改ざんの検出』の機能を実現しないと、安全な通信を実現できない。
そこで利用するのが『メッセージ認証コード』。これは暗号文からMAC（Message Authetication Code：メッセージ認証コード）を計算し、MACによって認証と改ざんがないことを確認する方法。イメージは次の通り。
上記の通り、MACにより通信の認証と改ざんは防ぐことができるが、通信者の両者がメッセージの暗号化、MACの計算ができる状態になっている。つまり、元のメッセージをどちらが作成したかを証明できない状態ということであり、事後否認できるということ。そこを防ぐ仕組みとして『デジタル署名』がある。
ちなみに、暗号文から生成されるMACは、共通鍵と暗号文を組み合わせた文字列のハッシュ値のようなもので、ハッシュの生成には、HMAC、OMAC、CMACなどがあるが、HMACが主流らしい。
補足としてハッシュは、ハッシュ関数から生成される値で次の特徴を持つ。
- 出力するデータ長が変わらない
- 同じ入力なら出力も必ず同じ
- 似たようなデータを入力しても、出力は大きく異なる
- 全く別のデータでも、同じハッシュ値になることが低確率で起こる（ハッシュ値の衝突）
- ハッシュ値から元のデータを逆算することは事実上不可能
ハッシュ関数のアルゴリズムもいくつか存在し、MD5、SHA-1、SHA-2などがあるがSHA-2を用いるのが主流で、逆にMD5やSHA-1は安全性に問題があると言われており、利用は推奨されていない。 ハッシュ関数は、パスワードをサーバに保存するような場合にも利用され、仮にサーバ上のハッシュ値を盗まれたとしても、元のパスワードは逆算できないため、不正ログインを防げる。
デジタル署名
共通鍵を用いる方法では、送信者と受信者が共通鍵を使用してメッセージ認証コードを作成することで、送信者と受信者が本当に送受信したものかがわからないという問題があった。
そこで『デジタル署名』の仕組みでは、送信者にしか作成できない『デジタル署名』というデータを使用して、メッセージ送信者を特定する。イメージは次の通り。
送信者の秘密鍵を用いることで、送信者にしか作成できないメッセージ認証コード（デジタル署名）を作成し、送信者を特定する。受信者は送信者の公開鍵を用いてデジタル署名を検証し、認証および改ざんの有無を判断する。
補足として、デジタル署名では公開鍵を用いるため暗号化・復号に時間がかかってしまう。そこで、メッセージのハッシュを計算し、そのハッシュ値を暗号化して、デジタル署名として利用している。
ただ、デジタル署名にもまだ課題があり、送信者の公開鍵が本人のものであるかを判断できない。その原因は、公開鍵に作成者の情報がないという点。そこをカバーするのが、『デジタル証明書』。
デジタル証明書
デジタル署名の課題として、公開鍵が本当の通信相手かどうかが保証されないというものがあった。悪意あるものが公開鍵をすり替えてたとしてもそれに気づくことができない状態。そこで登場するのが、『デジタル証明書』。
デジタル証明書は、認証局（CA:Certification Authority）に対して、『この公開鍵は自分のものである』という証明書発行を依頼し、認証局にデジタル証明書を発行してもらい公開鍵の正当性を保証するというもの。
認証局はデジタル証明書を管理する組織であり、原理的には誰でも認証局になることができる（自分自身で認証して証明書発行もでき、オレオレ証明書と呼ばれてたりする。また、Let's Encryptは無料のオープン認証局で、誰でも簡単にデジタル証明書を発行できる。）が、政府や監査を受けた大企業などの信頼できる組織を利用するのが安全。
デジタル証明書の発行の流れは次の通り。
まず、デジタル証明書を発行したい人は、自身の公開鍵と自身の情報から証明書署名要求（CSR：Certificate Signing Request）を生成し、認証局に送信する。
認証局は受け取ったCSRを審査し問題がなければ、受け取ったCSRに認証局の秘密鍵でデジタル署名をする。そして、デジタル証明書（CRT:CeRTificate）を依頼者に返す。
次にデジタル証明書による認証の流れを示す。
デジタル証明書では、公開鍵の代わりにデジタル証明書を相手に送る。デジタル証明書を受け取った側は、以下の確認を行う。
- 通信相手本人の情報が記載されているか
- 認証局の公開鍵からデジタル署名を検証し問題がないか
上記の確認が取れれば、本人でありかつ第三者により正当性が保証されたものであると判断し、デジタル証明書内の公開鍵を用いて通信を行う。
ここで認証局自体もなりすましの可能性があるが、認証局は木構造になっており、最上位の認証局（ルート認証局：Root CA）が中間認証局の正当性を担保している。
ルート認証局は自身で正当性を証明することになっているため、組織が信頼されているものである必要があり、大企業や政府関連組織などである場合が多い。
