jCryptionが危険な理由。
http://www.moongift.jp/2009/08/jcryption/の話。http://takagi-hiromitsu.jp/diary/を検索すれば幾らでも情報は見つかるとは思うけれど、自分のためにも書いておく。
前振り。
このjCryptionはMan-In-the-Middle攻撃に弱いはずだ。どのように攻撃されるかを具体的に書いてみる。登場人物は
- クライアント
- Alice
- サーバ
- Bob
- クラッカー
- Charlie
の三名。
通常の通信。
通常手順での通信は
| クライアント | 通信 | 内容 | サーバ |
|---|---|---|---|
| Alice | ---接続--> | リクエスト | Bob |
| Alice | <--応答--- | Bob公開鍵(平文) | Bob |
| Alice | ---ポスト--> | 暗号文 by Bob公開鍵 | Bob |
というようになっている。
Man-In-the-Middle攻撃。
Man-In-the-Middle攻撃を受けている最中の通信は
| クライアント | 通信 | 内容 | クラッカー | 通信 | 内容 | サーバ |
|---|---|---|---|---|---|---|
| Alice | ---接続--> | リクエスト | Charlie | ---接続--> | リクエスト | Bob |
| Alice | <--応答--- | Charlie公開鍵(平文) | Charlie | <--応答--- | Bob公開鍵(平文) | Bob |
| Alice | ---ポスト--> | 暗号文 by Charlie公開鍵 | Charlie | ---ポスト--> | 暗号文 by Bob公開鍵 | Bob |
というようになる。
AliceがBob公開鍵だと思っているものはCharlie公開鍵だ。Charlieはこの通信の内容をすべて読むことができるだけでなく、書き換えることもできる。
SSLの場合。
普通はOSのインストール時にルート証明書がインストールされているため、正しく認証を受けた公開鍵ならば正当性を検証できるようになっている。SSLの安全性を担保するには、暗号化だけではなく、ルート証明書の正しさも確保しなくてはならない。
〆。
要するに、いわゆる「オレオレ証明書」など、認証を受けていない公開鍵を使うのと同じだ。まったく暗号化になっていない。
