🔒PKI 公開鍵基盤

• 公開鍵基盤：Public Key Infrastructure
• PKI ：暗号技術 を「 信頼できる形 」で社会に提供するための仕組み。
• 別々に存在している技術（暗号）（認証）→ 現実インフラとして安全に使えるようにする。
• PKI = 提供・管理・運用する「仕組み」
• ・ 公開鍵とその所有者を対応付けるための基盤
• 信頼のネットワーク：個人、企業、政府、ソフトウェア会社、すべての 合意 と 協力 で成り立つ。
• 💡1つの会社でPKIは 構築 できず、 信用 もされない。
• 🏛️ PKIに必要な 代表的な5つの組織分類：
• ① ユーザー企業：証明書を使う（Webサーバ、メールなど）
• ② 認証局（CA）：証明書を発行・管理
• ③ 登録局（RA）：本人確認（CAの代理）
• ④ ソフトウェア提供者：ブラウザ、OSなどに「 信頼できるCAリスト 」を持ってる
• ⑤ ブラウザ/OSベンダー： ルート証明書 を信頼する（例：Microsoft, Apple, Mozilla）
• 💡PKIにおける工程と役割

🏛️認証局 CA : Certificate Authority

• 🔑公開鍵が正しく本人のものであることは、信頼できる第三者が保証する必要がある。
• 信頼できる第三者機関 = 認証局（CA）
• 認証局：本人情報を確認の上、本人の 公開鍵 に保証を与えた証明書「 デジタル証明書 」を発行
• 利用者：証明書から「認証局が認めた公開鍵」を取得し、安全な通信に利用する

📜デジタル証明書

• X.509 ：ITU-T が定めた証明書の規格
• 🧾 証明書の本体（署名前）

• ✍️ 認証局が上記に署名（メッセージダイジェスト＋秘密鍵で暗号化）
• 📜完成したX.509証明書（署名付き）

• 認証局のデジタル署名が確認できれば、公開鍵は「証明書に記載された本人所有のもの」

📄失効リスト CRL：Certificate Revocation List

• 公開鍵の漏洩や誤発信など、何らかの理由によって有効期限内に証明書が失効したもののリスト。
• ・認証局から定期的に配布される
• 💡署名や有効期限だけでなく、 証明書がCRLに含まれていないかどうか も確かめよう！
• 🧩 CRLの基本構成（X.509 CRL）

• 🧭 CRLの流れ
• ① CAが失効すべき証明書の情報を収集
• ② CRLの本体を作る（失効リスト含む）
• ③ 本体にハッシュをかけて、CAの秘密鍵で署名
• ④ 完成したCRLを公開（証明書検証時に使われる）

🕓OCSP：Online Certificate Status Protocol

• デジタル証明書が有効かどうかを認証局に問い合わせるプロトコル。
• 失効状態を オンライン で リアルタイム に確認する。
• CRL方式に比べ、失効状態を よりタイムリーに確認できる 。
• 必要な証明書だけ確認するから 軽量

💡PKIによる認証＆ 認証局の階層

• 認証局の階層：信頼の連鎖 をつくる仕組み（ルートCA → 中間CA → 利用者証明書）
• 🔗「そのCAを信頼できるのか？」という疑問を解消する仕組み
• ① クライアントが証明書を受け取る。
• ② 証明書の署名（デジタル署名）を検証するために、その署名をしたCAの証明書（公開鍵）を使う。
• ③ でも、「 そのCAが本物か？ 」をさらに検証したい（さらに上位のCAへ…）
• ④最終的にルートCAまでたどり着ければ「信頼の連鎖」が成立。
• 🏛️CAの階層構造 ：最終的に「ルートCAまで信頼の連鎖がつながればOK！」
• ・ ルートCAは、ブラウザやOSが最初から信頼してる
• ・ だから、ルートからの署名の連鎖で「信頼できる証明書だ」と判断できる
• 💡なんでルートCAだけじゃないの？
• ・ ルートCAは「絶対的な信頼の源」：ルートCAの秘密鍵が漏れたり不正利用されたら世界中の信頼関係が崩壊！
• 🛡️ 中間CAを使うメリット

• 証明書を発行したCAを信頼していないとき、自分が信頼するCAまで認証チェーンを遡る。
• ルート証明書：認証局が自身の正当性を証明するために、自ら署名したもの。

🧱ルート証明書

• PKIにおける最上位の証明書：
• 一番上にいる「ルート認証局（Root CA）」が自ら発行し、自ら署名している（＝ 自己署名証明書 ）
• このルート証明書が信頼の起点（ トラストアンカー ） となる。
• すべての証明書の信頼は、最終的にルート証明書までたどって確認する。
• ルート証明書が信頼されているからこそ、その下位（中間CAや利用者証明書）も信頼できると判断される。
• 🔁「自分で自分を証明」ってどういうこと？
• 😎 「私はルートCAです（自分で名乗る）」
• 😎 「その証明は…私がしました（自己署名）」
• 他人の証明に頼らない唯一の証明書
• なぜ信頼できるの？：OSやブラウザが「信頼してもいい」と決めてる から！
• PCやスマホの中には「このルート証明書は信頼してOK！」というリストが入ってる。
• ルート証明書は「誰かに証明されているわけじゃないのに、みんなが“この人は信用できる”と前提にしてる先生みたいな存在」
• 🔒信頼の構造（ITと現実の対比）※AI出力

• AppleやMicrosoftが“民間の国”として「この人たちは本物です」と言ってるような構図
• 信頼を管理するための基準：
• ・ Apple, Microsoft, Mozillaなどには「ルートプログラム」という参加基準がある（運営実績・セキュリティ対策・監査レポート提出など）
• ・ 国が発行する電子証明書（JPKIなど）も、一部ルート証明書として使われる
• ・ アメリカやEUでは、ある種の「準公的な認証局（Federal PKI）」も存在する

🔗 誰が誰を保証してるの？

• インターネットのTLS証明書

• 信頼の起点は、「OSやブラウザに内蔵されてるルート証明書」
• → 中央集権的な「信頼モデル」（TLS, CA）
• 🌐分散型で「信頼できるルールで全員が合意形成してる」のが、ブロックチェーン
• ✅ TLS（ルート証明書）：中央集権的な「信頼モデル」
• ・ 信頼の出発点は「OSやブラウザが内蔵してるルート証明書」
• ・ 誰か（AppleやMicrosoftなど）が「これは信頼できるよ」とお墨付きを出している。
• ・証明書は 階層的（ピラミッド構造） になっていて、信頼の連鎖がある。
• ✅ ブロックチェーン：分散型の「信頼モデル」
• ・ 誰も「この人が正しい」と決めない。
• ・ 改ざんが起きにくく、全体の合意が信頼のベース。
• どちらも「証明」がカギ

• 「誰が誰を信頼するか／しないか」「中央 vs 分散」「権威 vs 合意」ITの世界でずっと問われてる哲学🤔

🌎 信頼のしくみ：中央集権 vs 分散

• ルート証明書から広がる「信頼と権力の構造」
• ・一番上（ルート）の証明書は「 自己署名（自分で自分を保証）」している。
• ・OSやブラウザに「この人は信頼していいよ」とあらかじめ登録されている。
• → 「公的機関がこの先生を信頼してるから私たちも従う」状態。
• 🔗 2000年代、Winny登場、スノーデンの告発で揺れ動く信頼の仕組み

• 💡キーワード「ピア（peer）＝対等な相手」
• 🌐 クライアント・サーバー 方式（中央集権型）
• 例：YouTube
• → YouTubeのサーバーに動画がある
• → 視聴者はそこにアクセスして見るだけ
• 🔁 ピア・ツー・ピア （P2P・分散型）
• 例：Napster、Winny、BitTorrent
• → ユーザー同士が 自分の持ってるファイルの一部 を出し合う
• → 誰か1人がサーバーってわけじゃない
• → みんなが「ピア（＝仲間・対等な相手）」として動いてる
• 💡インターネットの最初の設計思想は分散型！
• ① 初期構想（ARPANET）は、核攻撃などで 一部が破壊されても機能し続けるための分散型ネットワークとして設計されていた。
• ② Webの商業化とともに、 大規模サーバー を持つプラットフォームが主流（Yahoo!、Googleなど）
• ③ P2Pの概念が一般に広まり、分散型への回帰の兆し（ナップスターなど）
• ④ クラウドコンピューティング の台頭で再び中央集権的なモデルへ（Google, Apple, Facebook, Amazonが「GAFA」と呼ばれ象徴的になった）
• ⑤ ブロックチェーン 技術の台頭で再び分散型への関心

🌎 影響のあった出来事 / Napster vs Metallica

• メタリカの未発表曲「I Disappear」 が Napster で流出＆拡散
• → Napsterを訴える！（2000年4月）
• ⚖️ 訴訟のポイント：
• ・Napster ：中央サーバーでは保存してない、ユーザー同士のやりとり を主張
• ・メタリカ：「著作権侵害を助けてる」と猛反発
• ・ナップスター上で流通した音楽データの多くは著作権を無視した市販のCDなどからの違法コピー
• ・2001年7月に、メタリカとナップスターが双方歩み寄る形で決着（詳細は公表されず）
• 🔄 Napster → Spotify の系譜

• 💡 ナップスターを共同創設したショーン・パーカー（Sean Parker）はのちにFacebookの初期投資家となり、同社の初代社長に就任。
• 🎧 Spotify は分散型？

• 🔄 仕組みは分散じゃなくても「自由な発信・共有」の思想はSpotifyやYouTubeで実現された。
• ✅ Spotify、初期はP2Pとのハイブリッドだった。

🌎 影響のあった出来事 / Winny（ウィニー）

• Winny：2002年に金子勇氏によって開発・公開されたファイル共有ソフト。
• 特徴：P2P型、匿名性が高く、中央サーバを介さない設計（分散型）。
• 🕓 時系列

• Winnyの何がすごかったのか？
• ・P2P技術を、当時の日本で高性能に実装。
• ・サーバーを介さずに、匿名性を高く保った設計。（←今でいう分散型の思想）
• ・それまでの他の分散型は「サーバーを減らすこと」が目的だった。
• プログラムとしての難しさ
• ・ネットワーク・暗号・分散処理の知識が全部必要。
• ・C++での実装で、低レイヤーの工夫が凝らされていた。
• Winny開発の動機
• → 「ファイル交換ソフトは海外にもいろいろあるけど、日本発で新しいものができないか、技術的興味から取り組んだ」
• 情報処理学会が彼の功績を顕彰した際に使った言葉：
• → 「新たなP2Pネットワークの可能性を切り拓いた先駆的功績は、今なお情報技術の進歩に大きな示唆を与える」
• 🔗 Point
• P2P通信 ：ピア（利用者）同士が直接データをやりとりする通信方式。中央サーバを介さない。
• 分散処理 ：処理を複数ノードで分担。Winnyはその一例。
• 匿名性 ：ノードの身元を秘匿する。Winnyの特徴でもあり、問題視もされた。
• 情報漏洩 対策：Winny経由で機密情報流出が多発し、セキュリティ教育・対策の必要性が顕在化。
• 組織の セキュリティポリシー ：ファイル共有ソフトの利用制限など、内部規定の重要性が再認識された。
• 著作権法 とIT：技術提供者が違法利用者を幇助したとされ逮捕された例。技術と法の関係の事例として重要。
• 幇助罪 ：他人の違法行為を手助けしたとされる場合の刑事責任。
• 技術の中立性：技術そのものは中立であり、使い方の問題という観点。
• 技術者倫理：開発者がどこまで利用者の行動に責任を持つべきか。