世界一わかりやすい暗号化の話|共通鍵・公開鍵・SSL・デジタル署名と、中小企業での使い方
まいどおおきに、ASAKURAの朝倉です。
本日も朝から眠たい目を擦りながら執筆です。
本日は、セキュリティ担当者が必ず通る道、暗号化についてです。
暗号化の説明が難しく感じるのは、内容が難しいからではありません。説明の順番が悪いからです。
たいていの解説は「共通鍵暗号は同じ鍵を使い、公開鍵暗号は異なる鍵を使います」から始まります。これは正しいのですが、聞いた側には何ひとつ残りません。なぜ2種類あるのか、どちらが偉いのか、SSLはどっちなのかが分からないままだからです。
この記事では、順番を変えます。
まず「そもそも何を守っているのか」を1つだけ押さえます。次に、共通鍵が抱えた困りごとを見ます。その困りごとを解決するために公開鍵が生まれ、公開鍵の弱点を補うためにSSL/TLSが両方を組み合わせ、さらに「本人確認」の需要からデジタル署名と電子証明書が生まれた、という流れで追いかけます。
困りごとと解決策の順に並べると、暗号化は暗記するものではなくなります。
後半では、この知識を中小企業が実務でどう使うかを整理します。自社サイト、社員のノートPC、メールでのファイル送付、電子契約、ランサムウェア対策。それぞれ「何をすれば効くのか」と「やっても意味が薄いこと」を、はっきり書きます。最後に、覚え方(試験勉強にも、社内説明にも使える整理の型)をまとめます。
この記事で答えること
- 暗号化は結局、何を守っているのか
- 共通鍵暗号と公開鍵暗号は、なぜ2種類あるのか
- ハッシュ関数は暗号化と何が違うのか
- デジタル署名はなぜ「秘密鍵」で行うのか
- 電子証明書と認証局は何のためにあるのか
- SSL(TLS)の中で、これらがどう組み合わさっているのか
- 中小企業は、この知識をどこに使うのか。優先順位はどうつけるのか
- どう覚えると忘れないのか
暗号化の正体:守っているのは「鍵」だけ

最初に、これだけ押さえてください。
暗号化には3つの登場人物がいます。平文(元の文章)、暗号文(変換後の文章)、そして鍵です。変換の手順そのものをアルゴリズムと呼びます。
ここで多くの人が誤解します。「アルゴリズムを秘密にしているから安全なのだろう」と。
違います。現代の暗号は、アルゴリズムを世界中に公開しています。AESもRSAも、計算方法は誰でも読めます。秘密にしているのは鍵だけです。
なぜアルゴリズムを隠さないのか。隠すと検証ができないからです。世界中の研究者に叩かれて生き残った方式だけが標準になります。逆に「独自開発の秘密のアルゴリズム」を売り文句にする製品は、検証されていないという意味で危険です。
この考え方には名前があります。ケルクホフスの原理です。「鍵以外のすべてが敵に知られていても、安全であるべき」。
実務上の意味はひとつです。
守るべきものは鍵の管理です。暗号技術を導入したかどうかではなく、鍵をどう保管し、誰が触れ、なくしたときにどうするかが安全性を決めます。この記事の後半で中小企業の実務を扱いますが、そこで挙げる対策のほとんどは「鍵(パスワード、証明書、端末)の管理」の話になります。
共通鍵暗号:同じ鍵で閉めて、同じ鍵で開ける

いちばん素朴な方式です。
金庫を思い浮かべてください。鍵で閉めて、同じ鍵で開けます。鍵を持っている人だけが中身を見られます。これが共通鍵暗号(対称鍵暗号)です。代表格はDESとAESで、AISはいま世界中で使われている標準です。
長所は、速いことです。動画のストリーミングも、クラウドに保存された数百GBのファイルも、実際に中身を暗号化しているのは共通鍵暗号です。公開鍵暗号は、この用途では遅すぎて使えません。
では、なぜこれで話が終わらないのか。ひとつの困りごとがあります。
困りごと:鍵をどうやって相手に渡すのか
A社が取引先に、暗号化した見積書を送るとします。ファイルは暗号化されているので、途中で盗み見られても読めません。
問題は鍵です。相手が開けるためには、鍵を渡さなければなりません。メールで送ったら、そのメールを盗み見られたら終わりです。ファイルと鍵を同じ経路で送るのは、荷物と鍵を同じ封筒に入れて送るのと同じです。
これを鍵配送問題と呼びます。
さらに、人数が増えると鍵の本数が爆発します。全員が別々の鍵でやり取りするなら、必要な鍵の数はn人でn(n-1)/2本。
| 人数 | 必要な鍵の本数 |
|---|---|
| 3人 | 3本 |
| 5人 | 10本 |
| 10人 | 45本 |
| 100人 | 4,950本 |
覚え方は「全員が握手する回数と同じ」です。3人が全員と握手すると3回、5人だと10回。同じ計算です。
社内10人ならまだしも、インターネットで見知らぬ相手と安全に通信するには、この方式だけでは無理です。会ったことのない相手に、どうやって最初の鍵を渡すのか。
この行き詰まりを解いたのが、公開鍵暗号です。
公開鍵暗号:開いた南京錠を配ってしまう

ここが山場です。ただし、比喩をひとつ受け入れれば一気に通ります。
南京錠を想像してください。カチッと閉めるのは鍵なしでできます。開けるには鍵が要ります。
あなたがやることは、開いた状態の南京錠を大量に作って、誰にでも配ることです。名刺と一緒に渡してもいい。ホームページに載せてもいい。誰が持って行っても構いません。
誰かがあなたに秘密の書類を送りたくなったら、箱に入れて、あなたの南京錠で閉めます。閉めるだけなら誰でもできます。
そして、その箱を開けられるのは、鍵を持っているあなただけです。閉めた本人も開けられません。
この「配ってよい南京錠」が公開鍵で、「手元に1本だけ持っている鍵」が秘密鍵です。
| 公開鍵 | 秘密鍵 | |
|---|---|---|
| 何本あるか | 何本でも配る | 1本だけ。絶対に渡さない |
| 誰が持つか | 全世界 | 本人のみ |
| できること | 閉める(暗号化) | 開ける(復号) |
| 例え | 開いた南京錠、投函口 | その南京錠の鍵、玄関の鍵 |
これで鍵配送問題が解けました。公開鍵は盗まれても平気なので、堂々と送れます。人数が増えても、鍵は1人あたり2本(公開鍵と秘密鍵)で済みます。100人でも200本です。共通鍵の4,950本と比べてください。
なぜ「閉められるが開けられない」が成立するのか
数学の話ですが、感覚だけ掴んでおくと納得感が違います。
やっているのは、「片方向は簡単だが、逆方向は現実的な時間では無理」という計算を使うことです。
たとえば、大きな素数を2つ掛け算するのは簡単です。電卓で一瞬です。ところが、掛け算の結果だけを見せられて「元の2つの素数は何ですか」と聞かれると、桁数が大きいと現代のコンピュータでも天文学的な時間がかかります。これがRSAという方式の土台です。
同じ「戻すのが難しい」性質を別の数学で実現したものが楕円曲線暗号(ECC)で、短い鍵で同じ強度が出るため、スマートフォンなどで広く使われています。
公開鍵暗号の弱点
万能ではありません。遅いのです。
複雑な計算をしているので、共通鍵暗号に比べて処理が重くなります。数百MBのファイルを公開鍵暗号だけで暗号化しようとすると、実用にならない時間がかかります。
つまり、
- 共通鍵:速いが、鍵を渡せない
- 公開鍵:鍵を渡せるが、遅い
長所と短所がきれいに裏返しになっています。
こうなれば、やることは決まります。組み合わせるのです。これがSSL/TLSで、第7章で扱います。
先に、もう2つ道具を用意します。ハッシュ関数とデジタル署名です。
4. ハッシュ関数:戻せない要約をつくる
暗号化と混同されやすいのですが、まったく別のものです。決定的な違いは、戻せないことです。
イメージはスムージーです。
いちご、バナナ、牛乳をミキサーにかけると、コップ1杯のスムージーになります。同じ材料を同じ分量で入れれば、いつでも同じ味になります。しかし、できたスムージーからいちごとバナナを取り出すことはできません。
ハッシュ関数は、どんな長さのデータからでも、決まった長さの短い文字列(ハッシュ値)を作ります。代表的なSHA-256なら、1文字でも1GBのファイルでも、出てくるのは常に同じ長さです。
性質は3つです。
| 性質 | 意味 | どう役に立つか |
|---|---|---|
| 一方向性 | ハッシュ値から元のデータは復元できない | パスワードをそのまま保存しなくて済む |
| 同じ入力なら同じ出力 | 何度計算しても同じ値になる | 照合に使える |
| 雪崩効果 | 1文字変えると、値が全く別物になる | 改ざんの検知ができる |
3番目が実務で効きます。契約書の「1,000万円」を「10,000万円」に書き換えられたとき、見た目では気づけないかもしれませんが、ハッシュ値は原型をとどめないほど変わります。
用途は主に2つです。
改ざん検知。ソフトウェアのダウンロードページに長い英数字が載っていることがあります。あれはハッシュ値です。手元のファイルのハッシュ値を計算して一致すれば、途中で書き換えられていないと分かります。
パスワードの保存。まともなサービスは、パスワードを平文で保存しません。ハッシュ値だけを保存します。ログイン時は、入力されたパスワードのハッシュ値を計算して、保存された値と比べます。これなら、万一データベースが流出しても、パスワードそのものは漏れません。
補足しておくと、MD5とSHA-1という古い方式は「別のデータから同じハッシュ値を作れる」ことが実証されており、もはや安全とみなされていません。もし社内システムやベンダーの提案書にこれらが出てきたら、その一点で設計の古さを疑う材料になります。
デジタル署名:鍵の使い方を、わざと逆にする
送信側:署名をつくる
秘密鍵を持っている本人にしかできない
文書を用意する
中身は隠しません。読まれても構わない前提です。
契約書.pdfハッシュ値を計算する
文書全体を、短い固定長の要約に変換します。1文字変えれば別物になります。
a3f9c1…自分の秘密鍵で署名する
文書そのものではなく、ハッシュ値に署名します。だから速く終わります。
署名データを送る
受信側:署名を確かめる
公開鍵があれば誰でも検証できる
届いた文書からハッシュ値を計算する
送信側と同じ手順で、自分の手で計算し直します。
a3f9c1…署名を送信者の公開鍵で開く
開けたということ自体が、送信者の秘密鍵で作られた証拠になります。
a3f9c1…2つのハッシュ値を照合する
自分で計算した値と、署名から取り出した値を突き合わせます。
一致した
本人が作り、かつ途中で書き換えられていない。あとから「送っていない」とも言えなくなる。
一致しない
別人が作ったか、途中で書き換えられている。どちらであっても、その文書は信用できない。
ここまでで「隠す」道具は揃いました。しかし、実務ではもうひとつ別の心配があります。
A社の社長のところに、取引先からメールで請求書が届きました。中身は読めます。隠す必要はありません。心配なのは別のことです。
これは本当に取引先が送ったものか。途中で金額を書き換えられていないか。あとで「そんな請求はしていない」と言われないか。
守りたいのは機密性ではなく、本人が作ったこと(真正性)と、途中で変わっていないこと(完全性)です。
ここでデジタル署名が出てきます。仕組みは意外なほど単純で、公開鍵暗号の鍵の使い方を逆にするだけです。
- 秘密にしたいとき:相手の公開鍵で閉める。開けるのは相手の秘密鍵
- 本人だと示したいとき:自分の秘密鍵で処理する。確認するのは、誰でも手に入る自分の公開鍵
自分の秘密鍵で作った印は、秘密鍵を持っている本人しか作れません。しかし、誰でも公開鍵を使って「確かにこの人の秘密鍵で作られた印だ」と確かめられます。
封蝋(シーリングワックス)に近いイメージです。その印章を持っているのは本人だけ。押された印は誰でも見て照合できる。しかも、押した後に中身をいじると印が合わなくなる。
実際には、文書そのものではなくハッシュ値に署名する
細かいですが、理由が分かると全体が繋がります。
公開鍵暗号は遅い、という話をしました。10MBの契約書に直接署名すると重すぎます。そこで、
- 文書からハッシュ値(短い固定長)を計算する
- そのハッシュ値を自分の秘密鍵で処理する。これが署名
- 受け取った側は、文書から自分でハッシュ値を計算する
- 送られてきた署名を送信者の公開鍵で開いて、中のハッシュ値と比べる
- 一致すれば、本人が作り、かつ改ざんされていない
ハッシュ関数と公開鍵暗号を組み合わせることで、速く、かつ改ざんも検知できる仕組みになります。第4章のハッシュがここで働きます。
署名で守れるもの、守れないもの
| 守れる | 守れない |
|---|---|
| 誰が作ったか(真正性) | 中身の秘密(署名しても内容は見える) |
| 改ざんされていないこと(完全性) | 書いてある内容が正しいこと |
| 「送っていない」と言えなくなること(否認防止) | 相手が信用できる人かどうか |
よくある誤解を1つ潰しておきます。デジタル署名は暗号化ではありません。署名された文書の中身は、誰でも読めます。隠したいなら、署名とは別に暗号化が必要です。
電子証明書と認証局:公開鍵の「印鑑証明」
まだ穴があります。しかも、かなり大きな穴です。
公開鍵は誰でも配れます。ということは、悪意のある人が「これが株式会社ASAKURAの公開鍵です」と嘘の鍵を配ることもできます。それを信じて暗号化した秘密の書類は、その悪意のある人にだけ読めることになります。
つまり、公開鍵そのものは「この鍵が誰のものか」を証明できません。
解決策は、日常の印鑑と同じです。
実印を使うとき、印影だけでは本人のものだと証明できません。だから役所が発行する印鑑証明書を添えます。第三者が「この印影はこの人のものです」と保証する仕組みです。
電子の世界では、この役所の役割を認証局(CA:Certification Authority)が担います。認証局が「この公開鍵は、確かにこの組織のものです」と保証する電子データを発行します。これが電子証明書(サーバー証明書、SSL証明書と呼ばれるもの)です。
証明書の中身は、おおむね次のものです。
- 誰の証明書か(ドメイン名、組織名)
- その公開鍵
- 有効期限
- 発行した認証局の名前
- 認証局のデジタル署名
最後の行が重要です。証明書自体に、認証局が第5章のデジタル署名を付けています。だから証明書は偽造できません。
信頼の連鎖
では、その認証局は誰が保証するのか。
上位の認証局が保証します。その上位はさらに上位が保証し、最上位のルート認証局にたどり着きます。ルート認証局の証明書は、WindowsやmacOS、ブラウザに最初から組み込まれています。
つまり、私たちがブラウザで安全に通信できているのは、「OSとブラウザに最初から入っている数十の組織を信頼する」という前提に立っているからです。この構造をトラストチェーン(信頼の連鎖)と呼びます。
ここまでを整理します。
| 道具 | 解決した困りごと |
|---|---|
| 共通鍵暗号 | 中身を速く隠す |
| 公開鍵暗号 | 会ったことのない相手に鍵を渡せない問題 |
| ハッシュ関数 | 改ざんされたか分からない問題 |
| デジタル署名 | 本人か分からない、あとで否認される問題 |
| 電子証明書と認証局 | 公開鍵が本当に本人のものか分からない問題 |
道具が5つ揃いました。これを全部つなぐと、SSL/TLSになります。
SSL(TLS):全部を組み合わせた仕組み
ブラウザのアドレスバーが https で始まっているとき、裏では以下が起きています。
最初に用語を整理します。SSLは古い規格の名前で、現在使われているのは後継のTLSです。SSLは脆弱性が見つかり、すでに使ってはいけない規格です。ただし世の中の呼び方が「SSL証明書」「SSL化」で定着しているため、本記事でもその呼び方を併記します。技術的な正確さで言えばTLSです。
動きの流れ
- ブラウザがサーバーに接続する
- サーバーが電子証明書を送ってくる
- ブラウザが証明書を検証する。認証局の署名は正しいか、有効期限内か、アクセスしたドメイン名と一致しているか
- 検証を通ったら、これから使う共通鍵を、盗み見られない方法で双方が用意する
- 以降の通信は、その共通鍵で暗号化してやり取りする
第2章と第3章の話が、ここで合流します。
公開鍵暗号は、最初の「鍵を安全に用意する」場面だけで使います。実際のデータのやり取りには、速い共通鍵暗号を使います。この組み合わせをハイブリッド暗号方式と呼びます。
覚え方は「玄関で鍵を受け渡して、部屋に入ってから会話する」です。玄関でのやり取りが公開鍵暗号、部屋での会話が共通鍵暗号です。
もう一歩踏み込むと、現在のTLS 1.3では「共通鍵を公開鍵で暗号化して送る」のではなく、ディフィー・ヘルマン鍵交換という方式で、双方が別々に計算して同じ鍵にたどり着く手順を使っています。鍵そのものが通信路を流れないので、より安全です。この性質のおかげで、仮に将来サーバーの秘密鍵が漏れても、過去の通信は復号できません(前方秘匿性)。
「公開鍵で共通鍵を送る」という説明は、理解のための簡略版です。試験対策としてはその理解で足りますが、実務でベンダーの説明を聞くときは、TLS 1.2以下と1.3で仕組みが違うことを知っておくと話が早くなります。
SSL/TLSが守るもの、守らないもの
ここを誤解すると、対策の方向がずれます。
| 守る | 守らない |
|---|---|
| 通信の途中で盗み見られること | サーバーに保存された後のデータ |
| 通信の途中で書き換えられること | サイト運営者が信用できるかどうか |
| 接続先が証明書どおりのドメインであること | フォームに入力した情報の使われ方 |
| 偽サイトへの接続(ドメイン名の不一致を検知) | 悪意ある人が自分のドメインで取った証明書 |
右の列の最後が重要です。詐欺サイトも、自分のドメインで証明書を取れます。無料で取れるので、実際にそうしています。
つまり、鍵マークがついているから安全なサイト、という判断は成立しません。鍵マークが意味するのは「この通信は暗号化されている」「接続先はアドレスバーに表示されているドメインである」だけです。そのドメインの運営者が善人かどうかは、何も保証していません。
社内のセキュリティ教育で、ここは必ず伝えるべきポイントです。
中小企業は、この知識をどこに使うのか
ここから実務です。順番は、費用対効果の高い順に並べています。
1. 社員の端末を暗号化する(最優先)
いちばん効きます。そして、いちばんやられていません。
情報漏えいの原因として毎年上位に来るのは、暗号の突破ではなく、ノートPCやUSBメモリの紛失・置き忘れです。営業車の中、電車の網棚、訪問先。
端末のディスク全体を暗号化しておけば、拾われても中身は読めません。WindowsならBitLocker、macOSならFileVault。追加費用はかかりません(BitLockerはWindows Proが必要)。
A社の場合、現場に持ち出しているノートPCが該当します。図面と顧客情報が入っているので、紛失は取引先への報告事案になります。設定は数十分で終わります。
注意点は1つ。回復キー(鍵)の保管です。第1章に戻りますが、暗号化の本体は鍵の管理です。回復キーを紛失すると、自分でも開けられなくなります。会社として保管場所を決めてください。
2. パスワードと多要素認証を整える(最優先)
暗号技術の話をしていて拍子抜けするかもしれませんが、実際の侵入経路として最も多いのは、パスワードの使い回しと推測です。どんなに強い暗号を使っていても、正しい鍵で入られたら意味がありません。
やることは3つです。
- パスワードの使い回しをやめる。管理はパスワード管理ツールに任せる(人間の記憶に頼る運用は破綻します)
- 多要素認証(MFA)を有効にする。メール、クラウド会計、業務システム、SNSの管理アカウント
- 退職者のアカウントを確実に止める。手順を文書化する
多要素認証は、パスワードが漏れても侵入を止められる、費用ゼロで最も効果の高い対策です。優先度でいえば、暗号化の細かい設定より先です。
3. 自社サイトを常時HTTPSにする
ここでSSL/TLSの知識が直接効きます。
チェック項目は4つです。
| 項目 | 確認方法 | 放置するとどうなるか |
|---|---|---|
| 全ページがhttpsか | httpでアクセスしてhttpsに転送されるか | 一部だけhttpだと警告が出る |
| 混在コンテンツがないか | ブラウザの開発者ツールで警告を見る | 鍵マークが崩れ、画像が表示されないことも |
| 証明書の期限管理 | 期限日と自動更新の設定 | 期限切れで全ページに警告画面。信用を大きく損ねる |
| 古いプロトコルの無効化 | サーバー設定でTLS 1.0/1.1を無効に | 脆弱性が残る |
証明書の期限切れは、中小企業のサイトで実際によく起きる事故です。大きな警告画面が出て、訪問者は入れません。無料のLet’s Encryptは有効期限が90日と短いぶん、自動更新が前提です。自動更新が動いているかを、一度は確認してください。
4. 証明書のグレードは、たいていDVで十分
営業を受けることがあるので、はっきり書きます。
証明書には3種類あります。
| 種類 | 認証局が確認すること | 費用感 | 中小企業での判断 |
|---|---|---|---|
| DV(ドメイン認証) | そのドメインを管理しているか | 無料〜低額 | 通常はこれで足りる |
| OV(組織認証) | 法人が実在するか | 中程度 | 取引先の要請があれば |
| EV(拡張認証) | より厳格な法人審査 | 高額 | ほとんどの場合、不要 |
重要なのは、暗号の強度はどれも同じだということです。違うのは「運営者の実在をどこまで審査したか」だけです。
かつてEV証明書はアドレスバーに企業名を緑色で表示しましたが、主要ブラウザはその表示をやめました。表示されないものに費用を払う理由は、ほぼありません。金融機関のように、社会的な要請がある業種は別です。
5. パスワード付きZIPをメールで送るのをやめる
いわゆるPPAP(ファイルを添付して、パスワードを別メールで送る運用)です。
なぜ意味が薄いのか。第2章の鍵配送問題そのものです。
- 同じ経路(メール)で鍵を送っている。1通目を盗み見られる相手には、2通目も見られる
- 誤送信対策としても弱い。宛先を間違えたら、パスワードも同じ間違った宛先に送ることになる
- ウイルス対策ソフトが暗号化ZIPの中身を検査できないため、マルウェアの侵入経路として使われる
政府もこの運用の廃止方針を示しており、大企業では受け取り拒否も増えています。
代替は次のとおりです。
- クラウドストレージの共有リンク(有効期限つき、アクセス権を指定)
- ファイル転送サービス(ダウンロード期限とパスワードを別経路で通知)
- 定常的な取引先とは、共有フォルダを用意してそこに置く
A社が取引先に図面を送る場面なら、共有リンク方式に切り替えるのが素直です。ついでに「誰がいつダウンロードしたか」の記録も残ります。
6. 通信経路を整える
- Wi-Fi:暗号方式をWPA2以上(できればWPA3)に。古い機器でWEPが残っていたら即交換です。WEPは実質的に暗号化されていないのと同じです
- 来客用Wi-Fiを社内ネットワークから分離する。ゲストネットワーク機能で十分です
- 公衆Wi-Fiでの業務:httpsなら通信自体は守られますが、社外から社内システムに入るならVPNを使う
- 事務所のルーターの管理パスワードが初期値のままになっていないか確認する
最後の項目は、驚くほど多く残っています。
7. 電子契約と書類の保存
ここでデジタル署名の知識が効きます。
電子契約サービスが使っているのは、第5章のデジタル署名と、時刻を証明するタイムスタンプです。日本では電子署名法により、一定の要件を満たす電子署名は手書きの署名や押印と同等に扱われます。
実務上の注意点を挙げます。
- 電子署名には、本人が認証局から発行を受けて署名する方式(当事者型)と、サービス事業者が署名する方式(立会人型)があります。多くのクラウド電子契約は後者で、簡便ですが証拠力の考え方が異なります。重要な契約では相手方と事前に方式を確認してください
- 電子帳簿保存法では、電子取引データの保存に「真実性の確保」が求められます。タイムスタンプを付す方法と、訂正削除の履歴を残す事務処理規程を整備する方法があります
- 契約書のPDFを単にメールで送るだけでは、改ざん検知の仕組みはありません。ハッシュも署名も付いていないためです
8. ランサムウェア対策:攻撃側が暗号を使ってくる
暗号化は守る技術ですが、攻撃にも使われます。ランサムウェアは、社内のファイルを勝手に暗号化して、鍵と引き換えに金銭を要求します。
ここで効くのは暗号技術ではありません。バックアップです。
- 3-2-1の原則:3つのコピーを、2種類の媒体に、1つは別の場所に
- 常時接続されていないバックアップを1つ持つ。ネットワークに繋がっているバックアップは、まとめて暗号化されます
- 復旧できるかを実際に試す。取ったことしかないバックアップは、バックアップではありません
支払いによる解決は推奨されません。鍵が渡される保証がなく、渡されても完全に戻る保証もありません。
覚え方:忘れない整理の型
試験勉強でも、社内説明でも使える整理をまとめます。
型1:迷ったら「誰の鍵か」の1枚表に戻る
公開鍵暗号でつまずく原因は、ほぼ100%が「どっちの鍵を使うのか」の混乱です。この表だけ覚えれば済みます。
| やりたいこと | 操作 | 使う鍵 |
|---|---|---|
| 中身を隠して送る | 暗号化 | 相手の公開鍵 |
| 届いたものを開ける | 復号 | 自分の秘密鍵 |
| 自分が作ったと示す | 署名 | 自分の秘密鍵 |
| 本人か確かめる | 検証 | 相手の公開鍵 |
言葉にすると、こうなります。
包むのは相手の鍵、押すのは自分の鍵。
さらに縮めると、自分の秘密鍵を使う場面は2つだけです。受け取るときと、名乗るときです。
型2:比喩を固定する
比喩を毎回変えると混乱します。1セットに決めて使い回してください。
| 用語 | 比喩 |
|---|---|
| 共通鍵暗号 | 金庫。同じ鍵で閉めて開ける |
| 公開鍵 | 開いた南京錠。誰にでも配る |
| 秘密鍵 | その南京錠の鍵。1本だけ |
| ハッシュ関数 | 指紋、またはスムージー。戻せない |
| デジタル署名 | 封蝋。本人しか押せず、誰でも照合できる |
| 電子証明書 | 印鑑証明書 |
| 認証局 | 役所 |
| SSL/TLS | 玄関で鍵を渡し、部屋で会話する |
社内説明のときは、この8個をそのまま使えば伝わります。
型3:情報セキュリティの3要素に紐づける
技術と目的を対応させると、記憶が構造化されます。機密性・完全性・可用性の3つ(CIA)が基本で、真正性と否認防止を加えることもあります。
| 守りたいもの | 意味 | 使う技術 |
|---|---|---|
| 機密性 | 見られたくない | 暗号化(共通鍵・公開鍵) |
| 完全性 | 書き換えられたくない | ハッシュ関数、デジタル署名 |
| 可用性 | 使えなくなりたくない | バックアップ、冗長化 |
| 真正性 | 本人だと示したい | デジタル署名、電子証明書 |
| 否認防止 | 後で「知らない」と言わせない | デジタル署名、タイムスタンプ |
「暗号化はどれを守るか」と聞かれたら機密性、「ハッシュは」と聞かれたら完全性。この対応が言えれば、大枠は押さえたことになります。
型4:数字を3つだけ覚える
- 共通鍵の必要本数はn(n-1)/2。握手の回数と同じ
- 公開鍵は1人2本。人数×2
- 鍵の長さは長いほど強い。ただし公開鍵暗号と共通鍵暗号で数字の意味が違う(AES 256ビットとRSA 2048ビットは、単純に大小比較できない)
よくある取り違え5つ
自分の理解を試すのに使えます。すべて誤りです。
- 公開鍵で暗号化したものは、公開鍵で戻せる。→ 戻せません。戻せるのは秘密鍵だけです
- デジタル署名をすれば中身が隠れる。→ 隠れません。署名と暗号化は別の目的です
- httpsのサイトは安全なサイトである。→ 通信が守られているだけです。詐欺サイトもhttpsです
- 高いSSL証明書のほうが暗号が強い。→ 強度は同じです。違うのは審査の厳しさだけです
- 暗号化してあるから漏れない。→ 鍵の管理が甘ければ漏れます。暗号化は鍵の問題に置き換える技術です
5番目が、この記事全体の結論でもあります。
まとめ
要点を再掲します。
- 暗号のアルゴリズムは公開されている。秘密なのは鍵だけ。だから鍵の管理が本体
- 共通鍵暗号は速いが、鍵を安全に渡せない(鍵配送問題)
- 公開鍵暗号は「開いた南京錠を配る」仕組みで、鍵配送問題を解いた。ただし遅い
- ハッシュ関数は戻せない要約。改ざん検知とパスワード保存に使う
- デジタル署名は、鍵の使い方を逆にして本人性と改ざん検知を実現する
- 電子証明書と認証局は、公開鍵の印鑑証明にあたる
- SSL/TLSは、これら全部の組み合わせ。玄関で鍵を渡し、部屋で会話する
- 高い証明書を買っても暗号は強くならない。PPAPは鍵配送問題を解いていない
- ランサムウェアに効くのは暗号ではなくバックアップ
暗号技術は、突破されて事故になることはほとんどありません。事故になるのは、鍵が管理されていないとき、設定が古いまま放置されているとき、そして「暗号化してあるから大丈夫」と思い込んでいるときです。
技術を理解する価値は、製品を選べるようになることではなく、この思い込みを持たなくなることにあります。
ご相談について
株式会社ASAKURAでは、三重県を中心に、中小企業のITコンサルティング・DX支援を行っています。セキュリティについても、製品の販売ではなく、いまの設定と運用のどこに穴があるかを整理し、費用のかからない対策から順に進めるご支援をしています。
「何から手をつければいいか分からない」という段階でのご相談を歓迎しています。
お問い合わせは、お問い合わせフォームまたはメールにて承っております。