メタCセキュリティ物語～暗号化とデジタル署名編～

この記事は、セキュリティ資格学習のために、AI（Claude）と共同で作成したコンテンツです。 ※間違った解釈がある可能性があります。

この記事の目的 セキュリティの専門用語は、カタカナや略語が多く、初学者にとって非常に取っつきにくいものです。 そこで、専門家じゃなくてもわかるようにストーリー風に構成してみました。

プロローグ：盗まれた秘密のメッセージ

🌐 ダークウェブでの出会い

【3ヶ月前】

結城のアパート。深夜2時。

結城はこんな投稿をした。

件名: メタC社への協力者募集

初めまして。
VRプラットフォームに興味があります。

メタC社の通信を傍受したい。

3日後、返信が来た。

件名: Re:メタC社への協力者募集

Yさん、
私は某VRプラットフォームのセキュリティチームに所属しています。
内部から協力できます。

あなたが必要な情報のタイプを教えてください。
報酬次第では、ネットワークアクセスも提供できます。

結城の心臓が高鳴った。

「これは…チャンスだわ」

💰 取引の成立

【2ヶ月前】

何度かのやり取りの後、結城と田中（仮名）は、暗号化されたビデオ通話で「面談」した。

お互いに顔は見せない。音声も加工されている。

「あなたの目的は？」田中が聞いた。

「個人的な理由です。元カレが新しい女と付き合っていて…二人の会話を見たい」

結城は、一部本当のことを言った。嘘は見抜かれやすい。

「…分かりました。でも、報酬は？」

「100万円。半分は前払い」

田中は数秒沈黙した。

「…いいでしょう。ただし、条件があります」

「何ですか？」

「私の身元は絶対に探らない。取引はダークウェブ経由のみ。暗号通貨で支払い」

「了解です」

🔓 バックドアの設置

【1ヶ月前】

メタCの田中は、メタCのネットワークにバックドアを仕掛けた。

深夜3時、誰もいないオフィス。セキュリティチームのメンバーである田中は、自由にサーバールームに入れた。

田中の作業:

田中は深夜、誰もいないオフィスで密かに作業を進めた。

①VPN用バックドアアカウント作成

• 目立たないユーザー名（ドット始まり）でアカウント作成
• 管理者権限を付与
• 監査ログに残らないよう設定を変更

②ファイアウォールルールの追加

• 結城のIPアドレスからのアクセスのみ許可する穴を開ける
• ルールを永続化（再起動後も有効）

③ネットワークスニファの設置

• パケットキャプチャソフトをインストール
• 内部通信（暗号化されていない部分）を記録する仕組みを構築
• システム起動時に自動で動作するよう設定

④リモートアクセス用の設定

• VPN接続用の認証情報を生成
• 暗号化して結城に送信

作業完了後、田中は暗号化メールを送った。

件名: 準備完了

VPN接続ファイルを送付します（添付）。
これでメタCの内部ネットワークにアクセスできます。

注意事項:
1. 内部通信は一部暗号化されていません（HTTP）
2. パケットキャプチャファイルは /opt/.sniffer/captures/ に保存されます
3. VPN経由でSFTPアクセス可能: .backup_vpn@10.0.1.100

ビットコインアドレス: bc1q...（残り50万円の支払い先）

これで終わりです。二度と連絡しないでください。

結城は、メタCの内部ネットワークに侵入できたことを確認後、すぐに残金を送金した。

📡 通信傍受の開始

【今夜：23時】

結城のアパート。複数のモニターが並んでいた。

モニター1: VPN接続

• 田中から受け取った認証情報を使用
• メタCの内部ネットワークに接続成功

モニター2: パケットキャプチャファイルの取得

• 内部サーバーにアクセス
• 事前に設置されたパケットキャプチャファイルをダウンロード
• 数十MBのデータを取得

モニター3: パケット解析

結城は、ダウンロードしたパケットキャプチャファイルを解析ソフトで開いた。

フィルタをかけると、慎也と里見の通信だけが抽出される。

HTTPボディが平文で見えた。

送信者: shinya_yamamoto
受信者: satomi
メッセージ: "今日は新しいワールド作ったんだ。見てくれる？"
タイムスタンプ: 2024-01-02T23:15:32Z

「ふふ…暗号化もしてないなんて」

結城の目が細くなる。

モニター4: リアルタイム監視

別のウィンドウでは、リアルタイムでパケットを監視している。

VPN経由でメタCの内部ネットワークに直接アクセスし、通信内容を傍受。

平文のHTTP通信なので、すべてのメッセージが丸見えだった。

「二人の会話…全部見えるわ」

🔓 メタCのセキュリティの脆弱性

結城の侵入と傍受を許してしまった原因：

1. 内部犯行対策の不足

• セキュリティチームメンバーの監視不足
• 重要操作の二重承認がない
• 従業員のバックグラウンドチェック不足

2. ネットワークセキュリティの欠陥

• 内部通信が暗号化されていない（HTTP）
• VPNアカウントの管理が甘い
• パケットキャプチャの監視なし

3. 通信プロトコルの問題

• TLS/HTTPS未実装（内部APIがHTTP）
• エンドツーエンド暗号化なし
• 平文でのメッセージ送信

4. 監査・モニタリングの不備

• ネットワークトラフィックの異常検知なし
• VPN接続ログの監視不足
• 大量のパケットキャプチャを検知できない

5. アクセス制御の問題

• セグメンテーション不足
• 最小権限の原則が守られていない
• 特権アカウントの野放し

第1章：傍受される恋人たちの会話

🌙 メタCでのデート

「今日は新しいワールド作ったんだ。見てくれる？」

慎也が里見を自作のワールドに案内する。満点の星空が広がる展望台。二人だけの特別な場所。

「わあ、きれい…星座まで再現してあるんだ」

「うん。お砂糖が星が好きだって言ってたから」

里見の頬が少し赤くなる。VRアバターでもその表情の変化が伝わってくる。

「ありがとう、慎也。大切にするね」

「これからも、二人でいろんなワールド巡りたいな」

そんな幸せな会話が、二人の間で交わされていた。

🎭 結城の盗聴

同じ頃、結城のモニターには二人の会話ログが流れていた。

「…ッ！」

拳がデスクを叩く。

「慎也…あの女のどこがいいの…」

しかし、結城はすぐに冷静さを取り戻した。

メタCのサーバーに不正アクセスし、チャットログを取得することに成功したのだ。暗号化されていないメッセージは、すべて丸見えだった。

「二人だけの特別な場所？…ふざけないで」

結城は、盗んだ情報を使って次の計画を立て始める。

「慎也が作ったワールド…壊してやる」

🚨 異変の発見

翌日、慎也が自分のワールドにログインすると、衝撃の光景が広がっていた。

「え…嘘だろ」

満点の星空は消え、代わりに真っ赤な文字で「裏切り者」と書かれていた。大切に配置したオブジェクトは全て削除されている。

「どうして…誰が…」

震える手でメタCのサポートに連絡する。

しかし、さらに衝撃的な事実が判明した。

「山本様、申し訳ございません。ログを確認したところ、山本様ご本人のアカウントから削除操作が行われております」

「そんなはずない！僕はそんなことしてない！」

💬 里見との相談

パニックになった慎也は、すぐに里見に連絡した。

「里見…助けて。誰かが僕のアカウントを乗っ取ってる」

里見は落ち着いた声で答える。

「大丈夫。まずは状況を整理しよう。慎也、最近怪しいメールとか開いてない？」

「メール…あ」

慎也は思い出した。昨日、メタC運営を名乗るメールが来て、「セキュリティアップデートのため、パスワードを再入力してください」というリンクがあった。

「それ、フィッシング詐欺だよ」

里見が優しく、でもしっかりと説明する。

「パスワードが盗まれたんだね。でも、もっと問題なのは…」

「え？」

「慎也、私たちのやり取り、暗号化されていないかもしれない」

慎也の顔が青ざめる。

「それって…」

「二人の会話、全部盗み見られてる可能性がある」

第2章：暗号化の基礎

🔐 共通鍵暗号

「ねえ、里見。暗号化って難しい？」

慎也が不安そうに聞く。

「大丈夫。例え話で説明するね」

里見が優しく微笑む。

「慎也、私たちが手紙のやり取りをする時、他の人に読まれたくないよね？」

「うん」

「じゃあ、手紙を箱に入れて、鍵をかけて送るのを想像して」

「なるほど」

「この時、私たちが同じ鍵を持ってれば、私が箱に鍵をかけて、慎也がその鍵で開けられる」

「それが暗号化？」

「そう。これが共通鍵暗号だよ」

共通鍵暗号（きょうつうかぎあんごう）とは:

一言で言うと: 送る人と受け取る人が同じ鍵を使って暗号化・復号化する方式

例え話:

• ロッカーの鍵を二人で共有
• 慎也が鍵をかける → 里見が同じ鍵で開ける
• 早くて簡単だけど、鍵を相手に渡すのが危険

代表的な方式:

• AES（エーイーエス）: 現在最も使われている（256ビット推奨）
• DES（デス）: 古い方式（もう安全じゃない）
• Camellia（カメリア）: 日本発の暗号（NTTと三菱電機が開発）

🔑 公開鍵暗号

「でも、里見。同じ鍵を二人で持つって、最初にどうやって渡すの？」

慎也が核心をついた質問をする。

「いい質問！それが共通鍵暗号の弱点なんだ」

里見が続ける。

「だから、もう一つの方法がある。公開鍵暗号だよ」

「公開鍵？」

「うん。今度は鍵が2本あるの」

里見が図を描いて説明する。

「公開鍵と秘密鍵。この二つはペアになってる」

「どう使うの？」

「例えば、慎也が私にメッセージを送りたいとき」

1. 里見の公開鍵（誰でも知ってていい鍵）でメッセージを暗号化
2. 暗号化されたメッセージを送る
3. 里見が自分の秘密鍵（絶対に他人に見せない鍵）で復号化

「公開鍵で暗号化したものは、ペアの秘密鍵でしか開けられない」

「なるほど！じゃあ、公開鍵は盗まれても大丈夫？」

「そう！公開鍵は名前の通り、公開しちゃって問題ないの」

公開鍵暗号（こうかいかぎあんごう）とは:

一言で言うと: 2つの鍵のペアを使う暗号。公開鍵で暗号化、秘密鍵で復号化。

例え話:

• ポスト（公開鍵）と鍵（秘密鍵）
• ポストは誰でも手紙を入れられる（暗号化できる）
• でも取り出せるのは鍵を持ってる人だけ（復号化できる）

代表的な方式:

• RSA（アールエスエー）: 最も有名（2048ビット以上推奨）
• 楕円曲線暗号（だえんきょくせんあんごう）: RSAより短い鍵で同じ強度
• DH（ディフィーヘルマン）: 鍵交換に使う

メリット:

• 鍵を安全に渡す必要がない
• 公開鍵は誰に知られてもOK

デメリット:

• 共通鍵暗号より処理が遅い

🔄 ハイブリッド暗号

「でも、里見。公開鍵暗号って遅いんでしょ？」

「そうなの。だから実際は両方を組み合わせるんだよ」

「え？どうやって？」

「これがハイブリッド暗号」

里見が説明を続ける。

1. 公開鍵暗号で、共通鍵を安全に送る
2. 共通鍵暗号で、実際のメッセージを暗号化

「あ！鍵の受け渡しは公開鍵で、実際のやり取りは共通鍵で！」

「正解！これが実際のHTTPSとかで使われてる方法だよ」

ハイブリッド暗号とは:

一言で言うと: 公開鍵暗号と共通鍵暗号の良いとこ取り

仕組み:

1. 公開鍵暗号で共通鍵を交換（安全だけど遅い）
2. 共通鍵暗号でデータを暗号化（速い）

例え話:

• 最初に装甲車（公開鍵）で金庫の鍵（共通鍵）を届ける
• 普段の荷物は金庫（共通鍵）で送る

使われてる場所:

• HTTPS通信
• メールの暗号化
• VPN接続

第3章：暗号モード

📦 ブロック暗号とは

「ねえ、里見。暗号化するとき、長いメッセージはどうするの？」

「いい質問！長いメッセージはブロックに分けて暗号化するんだ」

「ブロック？」

「そう。例えばAESだと、128ビット（16バイト）ずつ暗号化する」

「じゃあ、『こんにちは、お砂糖。今日も綺麗だね』みたいな長い文は？」

「それを16バイトずつ区切って、順番に暗号化していくの」

「なるほど。でも、どうやって区切るの？」

「それが暗号モードだよ」

🔓 ECBモード（使っちゃダメ！）

「一番シンプルなのはECBモード」

「どんなの？」

「ただ順番に、独立して暗号化するだけ」

元のメッセージ: AAAABBBBCCCCDDDD
↓ 4ブロックに分割
AAAA | BBBB | CCCC | DDDD
↓ 各ブロックを独立して暗号化
XXXX | YYYY | ZZZZ | WWWW

「簡単そうだね！」

「でもね、これは絶対に使っちゃダメ」

「え、なんで？」

「同じ内容のブロックは、同じ暗号文になるから」

里見が具体例を出す。

「例えば、『AAAA AAAA BBBB AAAA』というメッセージを暗号化すると」

元: AAAA | AAAA | BBBB | AAAA
暗号化: XXXX | XXXX | YYYY | XXXX

「あ！同じ『AAAA』が同じ『XXXX』になってる！」

「そう。これだと、暗号文からパターンが分かっちゃう」

ECBモード（Electronic CodeBook Mode）:

一言で言うと: 各ブロックを独立して暗号化（危険！使わない！）

問題点:

• 同じ平文ブロック → 同じ暗号文ブロック
• パターンが見える
• 画像を暗号化すると輪郭が見える

例え話:

• 同じ質問には同じ答えを返す暗号ロボット
• 「りんご」と聞くと必ず「apple」と答える
• 質問のパターンがバレる

使用禁止理由: セキュリティが低すぎる

🔗 CBCモード（推奨）

「じゃあ、どうすればいいの？」

「次に説明するCBCモードが良く使われるよ」

「CBC？」

「Cipher Block Chaining（サイファー ブロック チェイニング）の略。ブロックを鎖のように繋げるんだ」

「鎖？」

「前のブロックの暗号文を、次のブロックの暗号化に使うの」

ブロック1: 平文1 ⊕ IV → 暗号化 → 暗号文1
ブロック2: 平文2 ⊕ 暗号文1 → 暗号化 → 暗号文2
ブロック3: 平文3 ⊕ 暗号文2 → 暗号化 → 暗号文3

「⊕って？」

「XOR（排他的論理和）っていう演算だよ。簡単に言うと『混ぜ合わせる』感じ」

「なるほど。じゃあ、同じ平文でも、前のブロックが違えば違う暗号文になる？」

「正解！だから同じ内容でも暗号文は違うものになるんだ」

CBCモード（Cipher Block Chaining Mode）:

一言で言うと: 前のブロックの暗号文と混ぜ合わせてから暗号化

仕組み:

1. 最初のブロック: 平文 ⊕ IV（初期化ベクトル）を暗号化
2. 次のブロック: 平文 ⊕ 前の暗号文を暗号化
3. 繰り返し

メリット:

• 同じ平文でも違う暗号文になる
• パターンが見えない

デメリット:

• 並列処理できない（順番に処理するしかない）
• エラーが伝播する

例え話:

• 伝言ゲームみたいなもの
• 前の人の答えを聞いてから次の人に伝える
• 同じ質問でも、前の答え次第で変わる

IV（初期化ベクトル）とは:

• 最初のブロック用のランダムな値
• 毎回違う値を使う（使い回し厳禁！）
• 秘密にする必要はない（暗号文と一緒に送ってOK）

🔢 CTRモード（カウンタモード）

「他にも方法あるの？」

「うん。CTRモードも良く使われるよ」

「CTR？」

「Counter（カウンター）の略。カウンタを使うんだ」

「カウンタ？」

「1, 2, 3, 4…って増えていく数字のこと」

カウンタ1 → 暗号化 → ストリーム1 ⊕ 平文1 = 暗号文1
カウンタ2 → 暗号化 → ストリーム2 ⊕ 平文2 = 暗号文2
カウンタ3 → 暗号化 → ストリーム3 ⊕ 平文3 = 暗号文3

「カウンタを暗号化して、それを平文と混ぜるんだね」

「そう！これの良いところは、並列処理ができること」

「並列処理？」

「全部のブロックを同時に暗号化できるの。CBCは順番にしかできなかったよね」

「速いってこと？」

「正解！だから最近はCTRモードも人気だよ」

CTRモード（Counter Mode）:

一言で言うと: カウンタを暗号化して、それを平文と混ぜ合わせる

仕組み:

1. カウンタ（0, 1, 2, 3…）を暗号化
2. 暗号化したカウンタ ⊕ 平文 = 暗号文

メリット:

• 並列処理できる（速い！）
• エラーが伝播しない
• ランダムアクセス可能

デメリット:

• カウンタを使い回すと危険
• 実装が少し複雑

例え話:

• 整理券システム
• 1番、2番、3番…を暗号化して、それを平文と混ぜる
• 全部並行して作業できる

使われてる場所:

• IPsec
• TLS 1.3
• ディスク暗号化

第4章：ハッシュ関数

🔍 改ざんを検出する

「ねえ、お砂糖。暗号化すれば安全？」

「それだけじゃ不十分なんだ」

「え？」

「暗号化は盗み見を防ぐけど、改ざんは防げない」

「改ざん？」

「そう。暗号文を途中で書き換えられても、気づけないの」

「怖い…」

「だからハッシュ関数を使うんだよ」

ハッシュ関数（ハッシュかんすう）とは:

一言で言うと: データから固定長の指紋を作る関数

特徴:

1. どんな長さのデータでも、決まった長さの値（ハッシュ値）になる
2. 同じデータなら同じハッシュ値
3. 少しでも変わると全く違うハッシュ値
4. ハッシュ値から元のデータは復元できない（一方通行）

例え話:

• 顔認証みたいなもの
• 人（データ）を見ると、顔の特徴（ハッシュ値）を記録
• 同じ人なら同じ特徴
• ちょっと変わる（髪型、メガネ）と違う特徴
• 特徴だけ見ても、本人は作れない

🔐 ハッシュ関数の種類

「具体的にどんなハッシュ関数があるの？」

「代表的なのを教えるね」

MD5（エムディーファイブ）:

• 128ビットのハッシュ値
• もう使っちゃダメ！（脆弱性が見つかった）
• 昔はよく使われてた

SHA-1（エスエイチエー ワン）:

• 160ビットのハッシュ値
• これも使っちゃダメ！（2017年に破られた）
• Googleが衝突攻撃に成功

SHA-2（エスエイチエー ツー）:

• SHA-256、SHA-384、SHA-512 など
• 現在推奨！
• 最低でもSHA-256以上を使う

SHA-3（エスエイチエー スリー）:

• 最新のハッシュ関数
• SHA-2と全く違う設計
• より安全

「じゃあ、SHA-256を使えばいいんだね」

「そう！でも、ハッシュ関数だけだと、まだ問題があるんだ」

🍚 ソルト

「問題って？」

「レインボーテーブル攻撃って知ってる？」

「知らない…」

「例えば、パスワード『password』のハッシュ値は？」

「え、計算するの？」

「ううん。攻撃者は事前に計算してある」

パスワード | SHA-256ハッシュ値
---------|------------------
password | 5e884898da28047151d0e56f8dc6292773...
12345678 | ef797c8118f02dfb649607dd5d3f8c7623...
qwerty   | 65e84be33532fb784c48129675f9eff3a6...

「あ！辞書みたいに調べられちゃう！」

「そう。だからソルトを使うんだ」

「ソルト？塩？」

「うん。料理に塩を加えると味が変わるよね。同じように、ハッシュ化する前にランダムな値を混ぜるの」

ユーザーA: password + ランダム値ABC → ハッシュ化
ユーザーB: password + ランダム値XYZ → ハッシュ化

「同じパスワードでも、違うハッシュ値になる！」

「正解！これでレインボーテーブル攻撃を防げるんだよ」

ソルト（Salt）とは:

一言で言うと: ハッシュ化する前に加えるランダムな値

仕組み:

1. ユーザーごとにランダムなソルトを生成
2. パスワード + ソルト をハッシュ化
3. ソルトとハッシュ値を両方保存

メリット:

• 同じパスワードでも違うハッシュ値
• レインボーテーブル攻撃を防げる
• 辞書攻撃を難しくする

例え話:

• カレーに隠し味を入れる
• 同じレシピでも、隠し味次第で違う味
• レシピだけ盗んでも、同じ味は作れない

注意点:

• ソルトは秘密にする必要はない（ハッシュ値と一緒に保存してOK）
• ユーザーごとに違うソルトを使う（使い回し厳禁）

🔐 HMAC

「ねえ、里見。ハッシュだけだと、まだ問題ない？」

「鋭いね。実は、攻撃者がハッシュ値ごと書き換える可能性があるんだ」

「え！」

「だからHMACを使うんだよ」

「HMAC？」

「Hash-based Message Authentication Code（ハッシュベースド メッセージ オーセンティケーション コード）の略」

「長い…」

「簡単に言うと、秘密の鍵を使ったハッシュだよ」

HMAC = ハッシュ関数(秘密鍵 + メッセージ)

「秘密鍵を知ってる人しか、正しいHMACを作れないんだ」

「なるほど！じゃあ、攻撃者は正しいHMACを作れない！」

「正解！」

HMAC（エイチマック）とは:

一言で言うと: 秘密鍵を使ったハッシュ（改ざん検出＋認証）

仕組み:

1. 秘密鍵とメッセージを組み合わせる
2. ハッシュ関数で計算
3. HMAC値を送る
4. 受信側も同じ秘密鍵(共通鍵)で計算して比較

メリット:

• 改ざん検出
• 送信者の認証（秘密鍵を持ってる人だけが作れる）
• パスワードなしでチャレンジレスポンス認証に使える

例え話:

• 合言葉付きの暗号
• メッセージ + 合言葉 → 指紋
• 合言葉を知ってる人しか正しい指紋を作れない

使われてる場所:

• API認証
• Cookie の改ざん防止
• IPsec
• TLS

第5章：デジタル署名

✍️ 本人確認の証明

「ねえ、里見。ハッシュとHMACで改ざんは防げたね」

「うん」

「じゃあ、これで完璧？」

「まだ一つ問題があるんだ」

「え、まだあるの？」

「否認の問題だよ」

「否認？」

「例えば、慎也が私にメッセージを送ったとする。でも後で『僕は送ってない』って言ったら？」

「え…そんなこと言わないよ！」

「もちろん信じてるよ。でも、システム的には証明できないんだ」

「どうすればいいの？」

「デジタル署名を使うんだよ」

デジタル署名（デジタルしょめい）とは:

一言で言うと: 本人が作ったことと改ざんされてないことを証明する仕組み

仕組み:

1. メッセージのハッシュ値を計算
2. ハッシュ値を秘密鍵で暗号化（これが署名）
3. メッセージと署名を送る
4. 受信者は公開鍵で署名を復号化
5. 計算したハッシュ値と比較

なぜ本人証明になる？:

• 秘密鍵は本人しか持ってない
• 秘密鍵で作った署名は、ペアの公開鍵でしか検証できない

例え話:

• 印鑑（ハンコ）みたいなもの
• 本人しか持ってない印鑑で押す
• 印影（署名）を見れば、本人が押したと分かる
• 印鑑（秘密鍵）は他人に渡さない

🔏 デジタル署名の流れ

里見が図を描いて説明する。

【送信側：慎也】

1. メッセージ: "お砂糖、好きだよ"
   ↓
2. ハッシュ値を計算: SHA-256("お砂糖、好きだよ") = ABC123...
   ↓
3. 慎也の秘密鍵で暗号化（署名）: 署名 = RSA(ABC123..., 慎也の秘密鍵)
   ↓
4. メッセージ + 署名 を送信

【受信側:里見】

1. メッセージと署名を受信
   ↓
2. メッセージのハッシュ値を計算: SHA-256("お砂糖、好きだよ") = ABC123...
   ↓
3. 慎也の公開鍵で署名を復号化: RSA(署名, 慎也の公開鍵) = ABC123...
   ↓
4. 計算したハッシュ値と、署名から取り出したハッシュ値を比較
   ↓
5. 一致すれば、本人が送った＆改ざんされてない！

「なるほど！秘密鍵を持ってる人（本人）しか作れない署名だから、本人証明になるんだ」

「正解！」

🔐 デジタル署名のアルゴリズム

「デジタル署名にもいろんな方式があるの？」

「うん。代表的なのを教えるね」

RSA（アールエスエー）:

• 最も有名
• 公開鍵暗号と同じRSAアルゴリズム
• 2048ビット以上推奨

DSA（ディーエスエー）:

• Digital Signature Algorithm
• 署名専用（暗号化には使えない）
• アメリカ政府の標準

ECDSA（イーシーディーエスエー）:

• Elliptic Curve DSA（楕円曲線DSA）
• 短い鍵長で同じ安全性
• ビットコインなどで使用

「じゃあ、どれを使えばいいの？」

「最近はECDSAが人気だよ。効率が良いから」

第6章：PKI（公開鍵基盤）

🏛️ 証明書の必要性

「ねえ、里見。デジタル署名で本人確認できるのは分かった」

「うん」

「でも、一つ問題がない？」

「どんな？」

「公開鍵って、本当に本人のものか、どうやって確認するの？」

「鋭い！それがまさに重要な問題なんだ」

慎也が具体例を出す。

「例えば、結城が『私が里見です』って嘘をついて、偽の公開鍵を配ったら？」

「その通り。だからPKIが必要なんだよ」

PKI（ピーケーアイ）とは:

正式名称: Public Key Infrastructure（公開鍵基盤）

一言で言うと: 公開鍵が本物かどうかを証明する仕組み

役割:

• デジタル証明書の発行
• 証明書の管理
• 失効した証明書の管理

例え話:

• 運転免許証のシステムみたいなもの
• 警察（CA）が免許証（証明書）を発行
• 免許証を見れば、本人確認できる
• 失効リスト（CRL）で、無効な免許証を管理

🏢 CA（認証局）

「PKIの中心はCAだよ」

「CA？」

「Certificate Authority（サーティフィケート オーソリティ）の略。証明書を発行する機関のことだよ」

「具体的には？」

「例えば、会社がWebサイトを作るとき」

1. 会社がCAに申請（「うちのサイトの証明書ください」）
2. CAが本人確認（登記簿謄本とか確認）
3. OKなら、証明書を発行
4. 証明書には、CAのデジタル署名がある

「CAの署名があるから、信頼できるんだ」

「正解！」

CA（シーエー）とは:

正式名称: Certificate Authority（認証局）

一言で言うと: デジタル証明書を発行する信頼された機関

有名なCA:

• DigiCert
• Let’s Encrypt（無料）
• GlobalSign
• Cybertrust

CAの役割:

1. 証明書の発行
2. 本人確認（実在性の確認）
3. 証明書へのデジタル署名
4. 失効管理

証明書の中身:

• サイト名
• 公開鍵
• 有効期限
• CAのデジタル署名

例え話:

• 運転免許センター（CA）
• 免許証（証明書）を発行
• 公印（CA の署名）を押す

📝 RA（登録局）

「CAが全部やるの？」

「実は、RAという役割もあるんだ」

「RA？」

「Registration Authority（レジストレーション オーソリティ）。日本語で登録局」

「何するの？」

「CAの前段階の作業だよ」

RAの役割:

1. 申請受付
2. 本人確認（書類チェック）
3. CAに申請を転送

「CAは証明書の発行だけに専念できるんだ」

RA（アールエー）とは:

正式名称: Registration Authority（登録局）

一言で言うと: CAの受付窓口

役割分担:

• RA: 申請受付、本人確認
• CA: 証明書の発行、署名

例え話:

• 区役所の窓口（RA）と、印鑑を押す責任者（CA）
• 窓口で書類を確認
• OKなら責任者が印鑑を押す

🗂️ CRL（証明書失効リスト）

「証明書の有効期限前に無効にしたい時は？」

「CRLを使うんだよ」

「シーアールエル？」

「Certificate Revocation List（サーティフィケート リボケーション リスト）。証明書失効リストだよ」

「失効って、どんな時？」

証明書を失効させる理由:

1. 秘密鍵が盗まれた
2. 社員が退職した
3. 会社が倒産した
4. 証明書の情報が間違ってた

「こういう時、CAがCRLに追加するんだ」

「じゃあ、証明書を確認する時、CRLもチェックするんだ」

「正解！でも、CRLには問題があって…」

「問題？」

「リストが巨大になるし、更新が遅いんだ」

CRL（シーアールエル）とは:

正式名称: Certificate Revocation List（証明書失効リスト）

一言で言うと: 無効になった証明書のリスト

問題点:

1. リストが巨大（数万件）
2. 更新頻度が低い（毎日〜週1回）
3. ダウンロードに時間がかかる

例え話:

• ブラックリスト
• 無効なクレジットカード番号の一覧
• 分厚い電話帳みたいな大きさ

🔍 OCSP（オンライン証明書状態プロトコル）

「CRLの代わりは？」

「OCSPだよ」

「オーシーエスピー？」

「Online Certificate Status Protocol（オンライン サーティフィケート ステータス プロトコル）」

「何が違うの？」

「CRLはリスト全体をダウンロード。OCSPは1枚ずつ問い合わせ」

【CRL方式】
サイト: 「証明書確認したい」
  ↓
CRLをダウンロード（数MB）
  ↓
リストから検索

【OCSP方式】
サイト: 「証明書No.12345は有効？」
  ↓
OCSPレスポンダ: 「有効です」or「失効してます」

「OCSPの方が速い！」

「正解！だから最近はOCSPが主流だよ」

OCSP（オーシーエスピー）とは:

正式名称: Online Certificate Status Protocol

一言で言うと: 証明書の状態をリアルタイムで問い合わせ

メリット:

• 速い（1枚ずつ確認）
• リアルタイム
• データ量が少ない

仕組み:

1. ブラウザ: 「この証明書、有効？」
2. OCSPレスポンダ: 「有効」「失効」「不明」

例え話:

• 警察の照会システム
• 「この免許証、有効ですか？」と聞く
• その場で「有効です」と答えが返る
• 分厚い名簿を調べる必要なし

🏢 プライベートCA

「CAって、誰でもなれるの？」

「実は、プライベートCAといって、社内用のCAを作ることもできるんだ」

「社内用？」

「うん。例えば、社内システム用の証明書を、わざわざ外部のCAに申請するのは面倒だよね」

「確かに」

「だから、自社でCAを立てて、社内用の証明書を発行するの」

プライベートCAの用途:

• 社内Webサイト
• 社員のメール暗号化
• VPN接続
• 社内デバイスの認証

「ただし、プライベートCAの証明書は外部には信頼されないから注意」

プライベートCA（Private CA）とは:

一言で言うと: 組織内で独自に運用する非公開のCA

メリット:

• コストが安い（無料）
• 社内で自由に発行できる
• 管理が柔軟

デメリット:

• 外部のブラウザからは信頼されない
• 自分で管理する必要がある

例え話:

• 社内の身分証明書
• 社内では有効
• でも外の会社では使えない

使い分け:

• パブリックCA: 外部公開サイト
• プライベートCA: 社内システム

📜 証明書の種類

「証明書にも種類があるの？」

「うん。確認レベルによって3種類あるよ」

DV証明書（ドメイン認証）:

• Domain Validation
• ドメインの所有者確認だけ
• 一番安い（無料もある）
• Let’s Encrypt など

OV証明書（組織認証）:

• Organization Validation
• 会社の実在確認もする
• 登記簿謄本などで確認
• 中程度の価格

EV証明書（拡張認証）:

• Extended Validation
• 最も厳しい審査
• ブラウザのアドレスバーが緑色（昔）
• 高価

「銀行とか重要なサイトはEV証明書が多いよ」

第7章：XMLデジタル署名

📄 XML署名とは

「ねえ、お砂糖。デジタル署名って、ファイル全体に署名するの？」

「いい質問！実は、部分的に署名することもできるんだよ」

「部分的？」

「うん。特にXMLというデータ形式では、柔軟な署名ができるんだ」

XML（エックスエムエル）とは:

正式名称: eXtensible Markup Language

一言で言うと: タグで構造を表すデータ形式

例.xml

<message>
  <from>慎也</from>
  <to>里見</to>
  <text>好きだよ</text>
</message>

「HTMLみたいだね」

「そう！XMLはHTMLの親戚みたいなものだよ」

✍️ XMLデジタル署名の3種類

「XMLデジタル署名には3つの種類があるんだ」

①エンベロープ署名（Enveloped Signature）:

• 署名が署名対象の中にある
• 一番よく使われる

<document>
  <content>本文</content>
  <signature>署名データ</signature> ← 中に入ってる
</document>

②エンベローピング署名（Enveloping Signature）:

• 署名が署名対象を包む
• 署名の中にデータが入る

<signature>
  <data>本文</data> ← 署名の中
  署名データ
</signature>

③デタッチ署名（Detached Signature）:

• 署名が別ファイル
• データと署名が独立

document.xml  ← 本文
signature.xml ← 署名（別ファイル）

「デタッチ署名は、大きなファイルの時に便利だよ」

XMLデジタル署名とは:

一言で言うと: XML文書に対する柔軟なデジタル署名

3つの種類:

1. エンベロープ: 署名が中にある（最も一般的）
2. エンベローピング: 署名が外を包む
3. デタッチ: 署名が別ファイル

メリット:

• 文書の一部だけに署名できる
• 複数の署名を追加できる
• 複数人の署名も可能

例え話:

• 契約書の署名欄（エンベロープ）
• 封筒に入れて署名（エンベローピング）
• 別紙で署名（デタッチ）

使われてる場所:

• 電子申請
• SAML（後述）
• Webサービス

第8章：結城の最後の攻撃

🎭 暗号化を破る試み

その夜、結城は必死にキーボードを叩いていた。

「二人の会話が暗号化された…」

モニターには、意味不明な文字列が流れている。

5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8

「でも、諦めない…」

結城はブルートフォース攻撃（総当たり攻撃）を試みる。

しかし、AES-256の鍵長は256ビット。組み合わせは2^256通り。

「計算してみると…」

2^256 = 約 1.15 × 10^77 通り

スーパーコンピュータで毎秒1兆回試しても
約 3.67 × 10^60 年 かかる
（宇宙の年齢の 約10^50倍）

「無理…」

🔓 辞書攻撃を試みる

「じゃあ、パスワードを推測する」

結城は、よく使われるパスワードのリストを用意した。一般的なパスワード、慎也や里見に関連する単語などを試みる。

しかし、慎也と里見は強力なパスワードを設定していた。

大文字・小文字・数字・記号を含む24文字以上の複雑なパスワード。

「これも無理…」

🎯 中間者攻撃

「なら、公開鍵を偽装する」

結城は**中間者攻撃（Man-in-the-Middle Attack）**を試みた。

通信の間に入って、慎也には「自分が里見のサーバーだ」と偽装し、里見には「自分が慎也だ」と偽装する。これで両方の通信を盗聴できるはずだった。

しかし、メタCは証明書のピン留め（Certificate Pinning）を実装していた。

アプリが「証明書が違う！」と警告を出し、通信を遮断。

「くそっ！」

🏛️ 証明書の偽造

「じゃあ、証明書を偽造する」

結城は偽のCA証明書を作ろうとした。

しかし、信頼されたCAになるには、ブラウザやOSのルート証明書ストアに登録される必要がある。これは不可能だった。

「これも無理…」

💾 メタCのセキュリティ

結城のあらゆる攻撃は、メタCのセキュリティによって阻まれていた。

メタCの実装:

• TLS 1.3（最新）
• 証明書ピン留め
• HSTS（HTTP Strict Transport Security）
• Perfect Forward Secrecy
• CAA（Certification Authority Authorization）レコード

「完璧すぎる…」

結城は、初めて自分の無力さを感じた。

第9章：守られた二人

💑 安全な会話

「お砂糖、ありがとう」

「え？」

「セキュリティのこと、いろいろ教えてくれて」

慎也が照れながら言う。

「おかげで、二人の会話を守れてる」

「ふふ、どういたしまして」

里見が微笑む。

「でも、これからも油断しないでね」

「うん。暗号化、ハッシュ、デジタル署名…全部大事なんだね」

「そう。どれか一つでも欠けると、危険なの」

📊 セキュリティの多層防御

里見が図を描く。

【セキュリティの層】

第1層: 暗号化（盗聴防止）
  - AES-256
  - RSA-2048

第2層: ハッシュ（改ざん検出）
  - SHA-256
  - HMAC

第3層: デジタル署名（本人証明・否認防止）
  - ECDSA

第4層: PKI（公開鍵の信頼性）
  - CA証明書
  - OCSP

第5層: 通信プロトコル
  - TLS 1.3
  - Perfect Forward Secrecy

「全部組み合わせて、初めて安全なんだ」

「一つでも破られたら、他の層で守る」

「これが多層防御（Defense in Depth）だよ」

🎓 慎也の成長

「ねえ、里見」

「なあに？」

「僕、もっとセキュリティ勉強したい」

「本当？」

「うん。大切な人を守るために」

里見の目が潤む。

「慎也…」

「それに、仕事でも役立つし」

二人はしっかりと手を握り合った。

🎓 用語まとめ

暗号方式

暗号モード

ハッシュ関数

デジタル署名

PKI

XML署名

その他

📚 次のステップ

この物語で、暗号化とデジタル署名の基礎を学びました。

次は「認証とシングルサインオン編」で、以下を学びます：

• SAML（アイデンティティ連携）
• OAuth 2.0（認可プロトコル）
• OpenID Connect
• FIDO（パスワードレス認証）
• SSO（シングルサインオン）

お楽しみに！