🔐 【通信と信用 第1部】0.001秒の魔法:あなたのパスワードは通信の途中でなぜ盗まれないのか?

📚 通信と信用シリーズ学習マップ

☕ カフェのWi-Fiはなぜ危険?通信が暗号化されていない恐怖

想像してください。あなたがカフェの無料Wi-Fiに繋ぎ、ショッピングサイトでクレジットカード番号やパスワードを入力して「送信」ボタンを押した瞬間を。

インターネットの通信は、実は「ハガキを郵送する」ようなものです。あなたが入力した文字は、スマホから電波となってカフェの空間を飛び交います。

ハガキの裏にパスワードを書くのと同じ危険性

もし通信に何の保護もかかっていなかった場合、同じWi-Fiに繋いでいる悪意のある人(ハッカー)は、専用のソフトを使うだけでその電波をキャッチし、パスワードを「そのままの文字」で盗み見ることができてしまいます。この「ハガキのように丸見えの通信方式」を、専門用語でHTTP(エイチティーティーピー)と呼びます。

これを防ぐために登場したのが、ハガキを「絶対に透けない鍵付きの箱」に入れて送る技術です。これが、URLの先頭につくHTTPS(最後の「S」はSecure=安全の意味)です。
現在、ほとんどのサイトがHTTPSに対応しており、この「鍵付きの箱を作る技術」のことをTLS(ティーエルエス)と呼びます。

もふねこ

「じゃあ、最初からその『箱の鍵』をかけて送ればいいにゃ!」と思うかもしれないけど、実は『インターネット越しに、見知らぬ相手へ安全に鍵を渡す』って、とんでもなく難しいことなんだよ🐾


1. 暗号化のジレンマ:速度か、安全な鍵渡しか

通信を暗号化するには「鍵」が必要です。しかし、どのような鍵を使うかで、技術者たちは大きなジレンマを抱えていました。

① 速いが弱点がある「共通鍵暗号(AES)」

暗号化と復号に「同じ1本の鍵」を使う方式です。現代の主力はAESで、非常に処理が速いのが特徴です。AES-256ともなれば、世界中のスパコンを使っても解読に宇宙の年齢を超える時間がかかります。
しかし、共通鍵暗号には『鍵配送問題(Key Distribution Problem)』という致命的な弱点があります。ネット上で初めて通信する相手に対して、「通信を暗号化するための最初の鍵を、暗号化されていない通信経路でどうやって安全に渡すのか?」というパラドックスです。

② 鍵渡しを解決するが遅い「公開鍵暗号(RSA)」

そこで登場したのが、数学的に結びついた2本一組のペア(誰にでも見せていい「公開鍵」と、自分だけの「秘密鍵」)を使う公開鍵暗号です。
公開鍵暗号なら、鍵配送問題は解決します。しかし計算が複雑すぎるため、共通鍵(AES)の数百倍も処理速度が遅い(🐢)という欠点がありました。こんなものを動画や画像の暗号化に使えば、インターネットはまともに動きません。

🔬 もっと深く知りたい方へ:各暗号の鍵長と現在の安全性目安

■ 共通鍵暗号の鍵長

アルゴリズム 鍵長 安全性の目安
DES / 3DES 56〜168 bit ❌ 解読済み・廃止(2024年NIST完全廃止)
AES-128 128 bit ✅ 現在安全(一般用途)
AES-256 256 bit ✅ 軍・金融レベル

■ 公開鍵暗号(RSA)の鍵長

RSA鍵長 安全性 相当する共通鍵
512〜1024 bit ❌ 解読可能(非推奨) 共通鍵56〜80bit相当
2048 bit ⚠️ 2030年までの非推奨化予定 共通鍵112bit相当
3072 bit以上 ✅ 現代の標準(長期安全性) 共通鍵128bit以上相当

※米国国立標準技術研究所(NIST)のガイドライン「SP 800-57」により、112bitセキュリティ(RSA-2048)は2030年までに移行・廃止し、128bitセキュリティ(RSA-3072)以上へ移行することが推奨されています。


2. 0.001秒の魔法「TLSハンドシェイク」とは?HTTPS通信の仕組み

「AESは速いが鍵を渡せない」「RSAは鍵を渡せるが遅い」。
この2つを組み合わせたハイブリッド暗号こそが、現在のHTTPSの正体です。

あなたがブラウザでHTTPSのサイトを開いた瞬間、裏側ではわずか数十ミリ秒(0.001秒単位)の間にTLSハンドシェイクと呼ばれる「暗号の取り決め」が行われています。最新のTLS 1.3ではこの通信のやり取りが最適化され、たった1往復(1-RTT:Round Trip Time)で鍵交換を完了する超高速な仕組みになっています。

TLS 1.3 ハンドシェイクフロー(簡略版)
1
ClientHello(ブラウザ → サーバー)
「使える暗号リスト」と同時に、『Key Share拡張』を用いていきなり「DH鍵交換のための公開鍵(ヒント)」を送信することで1-RTT通信を実現!
2
ServerHello + 証明書(サーバー → ブラウザ)
暗号方式を決定し、自分の「セッション鍵のヒント」と「身分証明書」を返送。
3
鍵交換(ECDHE)による共通鍵の完成
双方がヒントから「今回限りの使い捨ての共通鍵」を同時に作り出す。
4
Application Data(以降はAES-GCMまたはChaCha20-Poly1305で高速暗号化)
完成した共通鍵を使って通信!TLS 1.3では暗号化と同時に改ざん検知(MAC)も行う認証付き暗号『AEAD』(AES-GCMやChaCha20-Poly1305等)のみが許可され、安全性が飛躍的に向上しました。

「公開鍵の技術で安全に鍵を渡し、共通鍵の技術で高速に通信する」。これが、私たちのネット生活を裏で支えている魔法の正体です。

🔒 さらなる進化:過去の秘密を守る「使い捨ての鍵」

かつては、この鍵渡しに「RSA(公開鍵暗号)」という技術が直接使われていました。しかしこれには、「もし未来のいつか、大元のマスターキーがハッカーに盗まれてしまった場合、過去に記録されていた通信までさかのぼって全て解読されてしまう」という恐ろしい弱点がありました。

そこで現在の通信(TLS 1.3)では、通信をするたびに毎回、その場限りの「使い捨ての鍵」を作り出す仕組みが標準になっています。これが「ディフィー・ヘルマン(DH)鍵交換」と呼ばれる技術です。

これのおかげで、もし万が一「今回の使い捨て鍵」が盗まれても、被害に遭うのはその1回の通信だけ。過去の通信が芋づる式に解読されることはありません。この安全な性質のことを、専門用語で「前方秘匿性(Forward Secrecy)」と呼びますが、初心者のうちは「毎回鍵が新しくなるから、過去の秘密は絶対に守られる!」とだけ覚えておけば完璧です。

🔬 ここから先はマニア向け!DH鍵交換の数学的トリック(読まなくても進めるにゃ🐾)

DH鍵交換は「掛け算の余り(べき乗剰余)を計算するのは簡単だが、その答えから元の累乗数を逆算することは困難である」という『離散対数問題(DLP)』の非対称性を利用した数学的トリックです。現在主流のECDHEではこれを楕円曲線上で行う『楕円曲線離散対数問題(ECDLP)』を用いることで、非常に短い鍵長でRSA-3072を凌駕する強固な安全性を実現しています。

① 共通の素数 p=23, 底 g=5 を公開
② アリスは秘密値 a=6 を選び、A = (5^6 mod 23) = 8 を公開
③ ボブは秘密値 b=15 を選び、B = (5^15 mod 23) = 19 を公開
④ アリスは届いたBを使って (19^6 mod 23) = 2 を計算
⑤ ボブは届いたAを使って (8^15 mod 23) = 2 を計算
🎉 通信経路上には「8」と「19」しか流れていないのに、双方が同じ秘密鍵「2」を共有できた!

3. 鍵マーク(HTTPS)の罠:証明書だけで安全と信じてはいけない理由

TLSハンドシェイクによって、通信の暗号化は完璧になりました。カフェのWi-Fiからパスワードを盗み見られることはもうありません。

しかし、ブラウザのアドレスバーに「🔒(鍵マーク)」が出ているからといって「このサイトは絶対に安全だ」と信じ込むのは非常に危険です。

⚠️ フィッシングサイトもHTTPSに対応している
鍵マークは「あなたとサーバー間の通信が暗号化されている」ことを示すだけで、「そのサーバーが善人である」ことは証明しません。悪意のあるハッカーが作った偽物のAmazonサイト(フィッシングサイト)でも、無料で証明書を取得して鍵マークをつけることができるのです。

実は、サーバーが提出する「身分証明書(SSL証明書)」は、『認証局(CA:Certificate Authority)』という第三者機関によって暗号学的な署名付きで発行されています。私たちのブラウザやOSには最初から安全な「ルート認証局」のリストが組み込まれており、そこから枝分かれする『信頼のチェーン(Chain of Trust)』をたどって身元を確認します。この審査レベルには3つの段階が存在します。

DV(ドメイン認証)

ドメインの所有権だけを確認。無料で即時発行できるため、個人ブログからフィッシングサイトまで広く使われる。

OV(組織認証)

運営組織の法的実在を審査して発行される。企業サイトなど向け。

EV(拡張認証)

最も厳しい審査。組織の法的地位・物理的所在・電話確認まで行う。銀行や証券会社など、高い信頼性が求められるサイト向け。

本当に信頼できる企業サイト(OVやEV)か、誰でも作れるサイト(DV)かを見分けるには、鍵マークをクリックして証明書の詳細を確認する必要があります。

💡 試しに今、確認してみましょう!

今開いているこのページのURL欄にある「🔒マーク(または設定アイコン)」をクリックしてみてください。暗号カフェのドメイン名と、接続が安全であることが表示されるはずです。これが「証明書を確認する」という行動です。

もふねこ

「これで通信中は安全にゃ!でも…無事に届いた先のサーバーがハッキングされたらどうなるにゃ!?💦」

🔍 次のステージへ

これで、あなたが入力したパスワードは「通信の途中」では絶対に誰にも読まれないことが確定しました。
しかし、無事にAmazonやX(旧Twitter)のサーバーに届いたパスワードは、その後どうなるのでしょうか?もし、その会社のデータベース自体がハッカーに盗まれてしまったら?
次は、通信の「到着地点」であるサーバー側で、パスワードがどのように安全に保管されているのかを見ていきましょう!

👉 第2部:パスワードの真実(盗まれても大丈夫な理由) を読む

実践的な仮想通貨・ブロックチェーンの知識を学ぶなら

☕ 姉妹サイト『暗号資産カフェ』へ