暗号 on Feature Branch Tech Blog

変わらないものと変わるもの：暗号技術の20年

Mon, 15 Dec 2025 00:00:00 +0900

変わらないものと変わるもの：暗号技術の20年

概要

以前の記事「公開鍵暗号による文書データ署名入門」で、「秘密鍵はどのように保管するのか」という質問がありました。この質問をきっかけに、20年ほど前にICカードを使ったシステムに関わった時のことを、現在のKMS（Key Management Service）を使うシステムに重ねて思い返してみました。

驚くことに、技術は大きく進化していましたが、「秘密鍵を守る」「本人を証明する」という本質的な原則とその手法は全く変わっていませんでした。この記事では、「入札」という実例をテーマとし「変わらないもの」と「変わるもの」という視点で、暗号技術の20年を振り返ってみたいと思います。

1. 変わらないもの：守るべき原則

1.1 公開鍵暗号の原理は50年不変

公開鍵暗号は1970年代に発明されました。RSA暗号は1977年の発表以来、基本的な原理は変わっていません。

公開鍵暗号の2つの使い方

暗号化: 公開鍵で暗号化→秘密鍵で復号（秘密を守る）
署名: 秘密鍵で署名（暗号化）→公開鍵で検証（復号できることで本人を証明する）

鍵ペア（公開鍵と秘密鍵）を生成し、その組み合わせでのみ機能するという仕組みは、発明当時も今も同じです。

公開鍵と証明書は「公開」するもの

ここでちょっと誤解されがちなのが「証明書」です。証明書は秘密にするものではなく、むしろ公開するためのものです。証明書には公開鍵と所有者情報が含まれており、これを広く配布することで、誰もがその公開鍵の正しさを検証できます。逆に、証明書が失効した場合も公開されるため、相手も自分も不正利用から守られます。秘密にすべきは秘密鍵だけという原則が、この仕組みの要です。

1.2 「封筒」「施錠可能な保管庫」という紙の知恵は今も生きている

デジタル技術が進化しても、「秘密を守る」という人間の営みの本質は変わりません。紙の入札を例に見てみましょう。

紙の入札の流れ

入札書の作成: 入札者は入札金額を記入した入札書を作成します
封筒に封入して提出: 入札書を封入し、提出受付期間内に提出します
提出された封書を受付: 提出された封書を受付し記録します
開札日時まで保管: 施錠可能な保管庫に格納し、開札日時まで厳重に保管します
開札: 開札当日、入札者を含む複数人の立会いのもとで、保管庫から取り出され公の場で開札されます
落札者決定: それぞれの入札の条件などにより、落札者が決定されます

この仕組みで守られているのは次の3つの原則です。

秘密性: 開札までは誰も入札金額を知ることができません
完全性: 封筒が開封された事実があれば、確認可能です（改ざん防止）
公平性: 複数の立ち会い者の前で開札することで透明性を確保します

1.3 「秘密を守る」という人間の営みは変わらない

20年前のICカード時代も、現在のKMS時代も、やっていることの本質は同じです。

入札金額を開札まで秘密にする
入札書が途中で改ざんされていないことを保証する
本人が提出したことを証明する

形は変わっても、「本人だけが開けられる」「途中で改ざんされていない」という要求は不変です。これは技術の問題ではなく、人間社会の信頼を支える根本的な仕組みなのです。

2. 変わるもの：進化する環境

2.1 保管場所の進化：用途による使い分け

秘密鍵の「保管場所」は、用途によって使い分けられてきました。そして、この20年で選択肢が大きく広がりました。

ICカード方式

ICカードの中に秘密鍵を格納し、物理的にその1枚にしか存在しない状態にします。合鍵は作れず、カードを紛失すると秘密鍵も失われます。

特徴: カードの中で暗号化・署名処理が行われるため、秘密鍵がカード外に出ることはありません
守り方: PINコード（暗証番号）で保護します。PINを複数回間違えるとロックされます
具体例: マイナンバーカード、企業の入退室カード、電子入札用のICカード
メリット: 物理的に持ち歩くため、「手元にある」という安心感があります
デメリット: カードリーダーが必要で、紛失・破損のリスクがあります

20年ほど前の本番環境では、ICカードとカードリーダーを持ち歩くのが当たり前でした。秘密鍵はカードの中に閉じ込められ、外部に取り出すことはできません。この「物理的な隔離」が、当時の最も確実な保護方法だったのです。

PKCS#12ファイル方式

秘密鍵と証明書をパスワードで暗号化してファイルに保存する方式です。

公開鍵暗号による文書データ署名入門

Tue, 09 Dec 2025 00:00:00 +0900

公開鍵暗号による文書データ署名入門

概要

オンラインで交わす契約書や報告書は、途中で書き換えられていないこと（完全性）と、確かに本人が作ったこと（真正性）が分かってはじめて価値を持ちます。この資料は、共通鍵暗号と公開鍵暗号の基本を日常の風景になぞらえながら、公開鍵暗号を使った署名と検証の流れを肩の力を抜いて学べるようにまとめたカジュアルなガイドです。家の合鍵や宅配ロッカー、スタンプカードといった身近なイメージを頼りに、暗号の仕組みを堅苦しく感じずにたどれる構成にしています。

1. 暗号の基礎：共通鍵暗号と公開鍵暗号の二刀流

この章では、暗号の世界に「みんなで同じ鍵をシェアするやり方」と「鍵をペアで使うやり方」があることを紹介します。

共通鍵暗号

同じ合鍵を共有していないとキャンディーボックスに触れない

公開鍵暗号

店長だけが持つマスターキー（秘密鍵）と、来店者全員に配られるロッカーの一時パス（公開鍵）。誰でもパスで荷物を預けられるけれど、取り出せるのは店長だけ

2. 共通鍵暗号と公開鍵暗号の違いをざっくり比較

ここでは二つの暗号方式を机上の言葉だけでなく、どんな場面に向くのか、鍵をどう配るのか、処理性能はどう違うのかという三つの角度から丁寧に比較します。仕事で「どちらを採用すべき？」と迷ったときに、この章の内容をそのまま判断材料として使えるようにするのが狙いです。

比較表

観点	共通鍵暗号	公開鍵暗号
鍵配布の手間	事前に同じ鍵を安全に共有する必要があり、人数が増えるほど管理が難しい	公開鍵は誰にでも配れるため配布は容易、秘密鍵のみ厳重に保管
処理速度	暗号化・復号とも高速で、大量データ向き	計算が重く処理は遅め。主に鍵配送や署名などポイント利用
典型的な用途	VPNやディスク暗号化など大容量データの暗号化	TLS の鍵交換、電子署名、証明書など真正性・鍵配送が重要な場面
リスク	鍵が一度漏洩すると全員の通信が危険にさらされる。鍵の入れ替えコストも高い	秘密鍵が漏れなければ公開鍵が広まっても安全。ただし秘密鍵への攻撃が一点突破で効く

3. 公開鍵暗号の仕組みをイメージで理解

公開鍵暗号の一連の流れを「鍵を作る→公開鍵を配る→暗号化する→秘密鍵で復号する」という4ステップに分解し、それぞれが身近な動作に置き換えられることを実感してもらいます。数学的な式を前提にせず、ロッカーと封印シールの例でイメージを固めた上で、後の章で署名の仕組みにスムーズにつなげるのが目的です。

鍵を生成して公開鍵を配る

[暗号] 緑色の透明ロッカーに荷物を入れると、中身を取り出せるのは紫色の管理キーを持つ本人だけ

[署名] 管理キーでロッカーに貼った封印シールは、誰でも配布された透明チェックカード（公開鍵）をかざして正規品か確認したうえで取り出せる

4. 署名が必要な理由：完全性と真正性を守る

デジタル文書はコピーも改変も数クリックでできてしまうため、「届いたファイルは途中で誰にも触られていないのか」「本当にあの人が送ってきたものなのか」を確かめる術が欠かせません。この章では、完全性と真正性という二つの観点を押さえることで、なぜ署名が信頼の支えになるのかを段階的に確認します。

完全性（Integrity）

共有フォルダへアップした資料が途中で書き換えられていないかを確かめること。

真正性（Authenticity）

その資料が本当にあの人から届いたと確認できること。

5. 署名と検証の流れを体験

署名プロセスは、文書が作られてから相手に届くまでの間に何が行われているのかを順番に追うと理解しやすくなります。この章では、現場で署名機能を組み込むときにまさに踏むことになる手順を、ハッシュ化・署名付与・検証という3ステップに分けて、どの場面でどの鍵が登場するのかを明確に描きます。動かす順番が分かれば、トラブルが起きた際にどこを疑えばいいかも見えてきます。

文書をハッシュ関数で要約し、短い指紋のような値を作る。
その指紋を秘密鍵で暗号化し、デジタル署名として添付。
受信者は同じハッシュ関数で文書の指紋を再計算し、公開鍵で署名を復号して値を照合。

照合が一致すれば完全性と真正性が満たされた証拠として文書を採用し、不一致の場合は改ざんや送信者違いを疑わなければならない。

おまけ：HTTPSにおける鍵交換の仕組み

ブラウザで「https://」にアクセスすると、裏側では公開鍵暗号と共通鍵暗号がリレーのように働きます。以下は一般的な TLS 1.2/1.3 ハンドシェイクをシンプルに追ったものです。

クライアントHello：ブラウザは「使える暗号スイート」「TLS バージョン」「乱数」などをサーバーに送る。まだ暗号化はされていない。
サーバー証明書の提示：サーバーは公開鍵を含む証明書（例：example.com の証明書）と、自身が選んだ暗号スイート、乱数を返す。証明書は認証局（CA）の署名付きなので、ブラウザは CA の公開鍵で検証して真正性を確認する。
鍵交換（例：ECDHE）：ブラウザとサーバーは一時的な鍵ペアを生成し、それぞれの公開値を交換する。相手の公開値と自分の秘密値を組み合わせ、同じ共有鍵（プレマスターシークレット）を計算する。ここまでが公開鍵暗号の役割。
対称鍵の派生：共有鍵をもとに、送受信それぞれのセッション鍵（共通鍵）を導出する。以降の通信は高速な共通鍵暗号（AES など）で行う。
Finished メッセージ：双方が新しい共通鍵でメッセージを暗号化し、「これからは暗号化済みのデータだけを送る」と宣言する。ここでハンドシェイク完了。