NETWORK & SECURITY

暗号通信シミュレーター.

通信経路に潜入して、
秘密を守る仕組みを解き明かそう。

ROUND 1

共通鍵暗号方式

    Ⅱ 通信を一時停止中アリス → ボブ

    Alice

    CharlieYOU

    Bob

    Charlieの中継機
    データの識別番号を見る
    ナレーション

    Aliceは、Bobに秘密のメッセージを送ろうとしている。

    共通鍵未取得
    本文未解読
    次に届けるデータ

    詳しい説明

    LOOK BACK

    何を、何で守る?

    01

    機密性

    第三者に秘密を読ませない。暗号化と、鍵を安全に届ける仕組みが必要。

    02

    完全性

    内容が変わっていないと確かめる。第4ラウンドでは、認証タグが本文の変更を検出する。

    03

    認証

    誰の鍵・誰からの通信かを確かめる。CAで公開鍵の持ち主を確認し、Aliceの署名で共通鍵の配送を認証する。

    この教育用モデルについて

    Charlieが通信経路の中継機を操作できる状況を仮定しています。中継機を通るデータは自動で記録されます。Charlieは、AliceやBobの秘密鍵を盗めません。

    暗号計算を省き、正しい鍵でのみ開けられる不透明な封筒として表現します。実用の暗号化ツールではありません。ビット操作による攻撃・長さの漏えいは扱いません。公開鍵暗号は共通鍵の配送に使い、本文は共通鍵で暗号化します。第1〜3ラウンドでは本文の送信者を確かめる仕組みを設けていません。

    第3ラウンドでは、認証局の証明書とブラウザ内のCA公開鍵でAlice・Bobの鍵を確認します。Aliceの共通鍵は漏れなくなりますが、Charlieが自作の共通鍵と本文を送るなりすましは残ります。第4ラウンドでは、Aliceが暗号化した共通鍵とAlice・Bobの名前・通信IDに署名し、BobがCAで確認したAliceの公開鍵で検証します。本文はその共通鍵による認証付き暗号(AEAD)で保護します。署名は鍵配送を認証し、認証タグは本文の変更を検出します。

    実際のTLSでは、共通鍵をそのまま署名して配送するのではなく、鍵交換を含む通信履歴を認証して鍵を共有します。このゲームは鍵配送の署名と本文の認証タグに役割を分けた教育用モデルです。通信IDや本文の番号も検証に含めますが、実用システムの全手順は再現していません。過去の正しいデータの再送を防ぐには、順序や重複の確認も必要です。実験データはこの画面のメモリー内だけに保持します。