暗号技術 on M1KE BL0G

HTTPS通信について

Thu, 30 Apr 2026 23:52:18 +0900

背景

HTTPSについて調べていたときのメモを発見したのでこっちにコピーする

基本

共通鍵暗号方式 (DES, AES)

一番ベーシックな暗号方式は共通鍵暗号方式。シーザー暗号もこの一種。

予め共通鍵を共有する
送信者は送るテキストを共通鍵で暗号化
受信者に送信
受信者は暗号化された文を共通鍵で復号

DESとAESとは？

第二次世界大戦で利用されたエニグマなど1976年以前の暗号は共通鍵暗号に分類される。この暗号方式は1977年にアメリカ政府が策定した56ビットの鍵を用いるDES(Data Encryption Standard)として広く用いられてきた。しかし、現在では総当たり攻撃で解読可能なほど安全性が低くなっており、2001年にNISTが公募し規格化したAES(Advanced Encryption Standard)が標準として利用されている。

公開鍵暗号方式とは？

共通鍵暗号方式では、ひとつの鍵（共通鍵）を使用するが、公開鍵暗号方式では対になっている 2つの暗号鍵を用いる。

この 2つの鍵は、それぞれ「公開鍵 (Public Key)」と「プライベート鍵(Private Key)もしくは秘密鍵」と呼び、対となる 2つの鍵の組み合わせを「鍵ペア」と呼ぶ。

メッセージの送信フロー

受信者は予め公開鍵を送信者に送る
送信者はメッセージを公開鍵で暗号化して送信する
受信者は秘密鍵で暗号文を復号する

なぜ公開鍵で暗号化して、秘密鍵で復号化するのか？

基本的には公開鍵で暗号化して、秘密鍵で複合する。なぜ逆はないかというと、秘密鍵で暗号化すると、みんな読めてしまう状態になるから。

ハイブリッド暗号 (公開鍵暗号方式と共通鍵暗号方式を組み合わせ)

実際のメッセージの中身の暗号化では、公開鍵暗号方式と共通鍵暗号化方式を組み合わせる。

なぜ公開鍵暗号方式と共通暗号方式を組み合わせるのか？

公開鍵暗号方式では実は処理が重いから。公開鍵暗号方式は複雑な演算処理を行うため、共通鍵暗号方式の数百倍もの計算が必要になる。そこで実際には、高速な処理を可能にするため、公開鍵暗号方式と共通鍵暗号方式を組み合わせて使用する。

公開鍵暗号方式と共通暗号方式を組み合わせによるメッセージの暗号化

共通鍵 (S) を生成する。（A さん）
生成した共通鍵 (S) を用いて、平文 (T) を暗号化する。（A さん）
各送信相手の公開鍵 (B, C, D) を用いて、共通鍵を暗号化 (SB, SC, SD) する。（A さん）
暗号文 (TS) と暗号化した共通鍵 (SB, SC, SD) を送信する。（A さん）
自分の公開鍵(B)で暗号化された共通鍵 (SB) を選択し、自分のプライベート鍵(B’)を用いて復号(S)する。（B さん、C さん、D さん）
復号した共通鍵 (S) で暗号文 (TS) を復号 (T) する。（B さん、C さん、D さん）

公開鍵暗号方式と共通暗号方式の組み合わせのポイント

共通鍵でメッセージを暗号化するが、共通鍵は公開鍵で暗号化して、秘密鍵で共通鍵を復号化してその復号化した共通鍵でメッセージを復号化するところ。つまり、共通鍵方式で問題だった、共通鍵の安全なやり取りの問題を公開鍵方式で解決しているところ。共通鍵方式では一旦共通鍵がバレルと暗号文は全部ダダ漏れだから。

非公開鍵による変換（デジタル署名）

デジタル署名とは？

メッセージに対するダイジェストを秘密鍵で暗号化することで、メッセージの改ざんを検出することができる。これをデジタル署名 (Digital Signature) と呼ぶ。

公開鍵は誰でも取得できるため、プライベート鍵で暗号化しても守秘性の確保にはならないが、プライベート鍵が特定の個人のみ所有しているので、電子文書の真正性と完全性の保証を実現することができる。

これがデジタル署名 (Digital Signature) と呼ばれる技術。

デジタル署名では、署名と検証の2つのことを行う。

デジタル署名の検証の目的

メッセージが改ざんされていないこと
メッセージは、検証に使用した公開鍵と対になる秘密鍵(鍵ペア)によって署名されたこと

なぜ非公開鍵で暗号化するのか？

基本的に公開鍵方式では、公開鍵で暗号化して、非公開鍵で復号化する。
(なぜなら、その逆だと、公開されている公開鍵でだれても暗号文を解読できてしまうから)
ただし、RSA暗号方式の場合、これとは逆に、プライベート鍵で暗号化(署名)して公開鍵で復号(検証)することもできる。
この仕組みによって、署名を検証することで、改ざんされていないことや鍵ペアが正しいことを検証する。
NOTE: メッセージの中身自体は暗号化されていないので注意。

用途による鍵ペアの名称

メッセージの中身自体を暗号化したい場合は、公開鍵を使って暗号化して、秘密鍵で復号化する。他方、署名(デジタル署名)をしたい場合は、非公開鍵で暗号化して、秘密鍵で検証する。

用途による意味の違い

意味的には、暗号鍵と復号鍵と検証鍵がある。

用途	プライベート鍵 (Private Key)	公開鍵 (Public Key)
守秘	復号鍵	暗号鍵
ディジタル署名(RSA暗号)	署名鍵	検証鍵

RSA暗号について

基本、公開鍵暗号方式では、公開鍵は公開されているので、暗号化用で、非公開鍵は復号化ように使われる。ただし、RSAはちょっと違う。双方向で暗号と復号が可能。その構造上、デジタル署名のアルゴリズムとして使われている。順を追って説明する。

RSA暗号の仕組み

RSAでは公開鍵と秘密鍵の２つの鍵を 素数の掛け算と素因数分解の計算コストの差を利用して実現する。

A: 素数 B: 素数 C = A x B

その計算には次の特徴がある。

掛け算は簡単
- AとBが数百桁あったとしても、かなり短時間で計算できる。
- 23451532523 x 53523532532235 = ??? みたいな
- 単に計算すればOK = ローコスト
素因数分解は難しい
- ??? x ??? = 5057230593780528023
- これは5057230593780528023を素因数分解する必要がある。
- ただし、因数は素数なので大きな素数の掛け算になる。
- 虱潰しに計算しないといけない = ハイコスト

RSA暗号の具体的な例

RSAの公開鍵 (素因数分解)
- この鍵で暗号化したものを平文化するためには、秘密鍵が必要
- A × B = C のうちの C だけが書かれている
- 計算によって、Cから AとB を特定するのは困難(=公開鍵から秘密鍵は作れない)
- 公開鍵から秘密鍵を作ることができないため、「閉めることしかできない鍵」となる
RSAの秘密鍵 (掛け算)
- 公開鍵で暗号化したものを平文化することができる鍵
- A × B = C のうちの AとB が書かれている
- 計算によって、AとB から Cを求めるのは簡単(=秘密鍵から公開鍵を作れる)
- 秘密鍵から公開鍵を作ることができるので、間接的には閉めることもできる

重要なのは、RSAでは、秘密鍵だけ大事に保管しておけば、無くしてしまった公開鍵をあとから生成しなおすことができる

RSAの公開鍵と非公開鍵はどちらでも暗号化と復号化が可能

実は RSAの公開鍵と秘密鍵は同じ構造をしているので、どちらの鍵をつかっても暗号化することができる

あなた		相手
秘密鍵で平文化	<=暗号化=	公開鍵で暗号化
秘密鍵で暗号化	=暗号化=>	公開鍵で平文化

つまり、双方向でできてしまう。ただし、秘密鍵から公開鍵は作成できないので、公開鍵を渡すようにする。

また、公開鍵で暗号化してもあまり意味がない。なぜなら、公開鍵は公開されているので、誰でも暗号化できるため。 Githubみたいに(https://github.com/mgoldchild.keys)、公開鍵として公開されている。

非公開鍵で暗号化できるメリット

それは暗号文を自分で暗号化したことを証明できる。

明日送金します。by Mike

というメッセージが平文で(暗号化されずに)送られてきた時に、そのままではこのメッセージを書いたのが本当にMikeなのか、それとも第三者が捏造したものなのかを区別することができない。

それを区別できるようにするのが電子署名。

RSAの電子署名は、秘密鍵による暗号文を作り出すことで実現する。上記文章をMikeの秘密鍵で暗号化すると、受け取った人はMikeの公開鍵を使って平文化できる。

Mikeさんの公開鍵は公開されているので誰でも読めるが公開鍵で平文化できる暗号文を作れたということは、 Aさんの秘密鍵を持っているということ、

つまり本人が書いた文章だということがわかる。これが電子署名。

つまり、メッセージを暗号化する共通鍵方式や普通の公開鍵暗号方式とは違い、 RSA暗号ではメッセージではなく、送信者を保証することを目的とする。

コマンドの具体例

コマンドでは一旦メッセージを計算コストの低くなるdigitにsha1などで変換してから、非公開鍵で暗号化する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


echo -n "明日送金します。by Mike" | openssl dgst -sha1 -sign private-key.pem | hexdump
0000000 c2 1f 73 6d 4f b5 fa 5a 9d 9d 02 e0 a3 fe 70 0c
0000010 93 ef f5 f1 3c 34 ec 5f e0 8d 21 58 6a 27 3a e1
0000020 b0 49 81 a8 15 d2 92 39 cc fe ce 2d 3f 9f 91 3d
0000030 68 cf 99 ce 91 04 2e 72 e7 e5 c5 71 55 29 87 7d
0000040 f5 e9 f0 c3 f5 6b af f4 be 8f f9 c4 34 bb 52 1c
0000050 51 8d cf c7 64 e0 84 d2 33 ed bb 80 4f 9a 3f 42
0000060 84 2e ef 41 e4 fc b4 04 51 5e 55 11 86 63 31 fc
0000070 a1 b7 6b 93 f7 e0 67 31 04 69 e4 2e 97 e6 5f a2
0000080

まとめ

インターネットで身元を確認して挨拶するのは大変という話。

Mike> Hi John. John> Good morning Mike.

顔が見えないインターネットでは次のような疑問が浮かぶ。

人
- 本当にMikeなのか？
- 本当にJohnなのか？
メッセージ
- 途中で誰かにメッセージを盗聴されていないか？
- 途中で誰かにメッセージを改ざんされていないか

そういう背景があって暗号化が必要になる。

比較

アルゴ	目的	処理	メリット	問題
共通鍵暗号方式	メッセージをの暗号化	共通の鍵でメッセージを暗号化	メッセージを双方向に暗号化可能	共通鍵を渡すときに、共通鍵が流出すると問題
公開鍵暗号方式	メッセージをの暗号化	公開鍵を渡して暗号化してもらう	公開鍵を持っている人から他人が盗聴できないメッセージを非公開鍵を持っている人に送れる	計算コストが高い。また、双方向ではメッセージを暗号化できない。
ハイブリッド暗号方式	共通鍵を安全に送信する	公開鍵で共通鍵を暗号化して非公開鍵でそれを復号化してもらう	計算コストが低い。また、双方向でメッセージを暗号化可能。	公開鍵を渡しても、公開鍵自体が改ざんされている可能性がある。
DH鍵交換	共通鍵を安全に送信する	通信内容がバレても問題ない数字を双方向にパラメータとして決めて、秘密な共通鍵（秘密鍵でもある）を生成する	共通鍵自体をハイブリッド方式のように送信しないので共有鍵交換中に	中間者攻撃を受ける可能性がある
デジタル署名（サーバー証明書）	公開鍵を安全に送信する	公開鍵をメッセージとして、非公開鍵でそれに署名をつけて、公開鍵でそれを検証する	公開鍵を非公開鍵を持っている人が送信したことを確認できる	公開鍵を渡してきた人が本当にその人本人なのかが分からない。例えばMikeから送られた。では本当にMikeなのか？
デジタル署名（中間証明書）	サーバー証明書を証明する	信頼できる第三者機関（Trusted Third Party）に送信者の公開鍵をメッセージとして、第三者機関の非公開鍵でそれに署名をつけて、第三者機関の公開鍵でそれを検証する	公開鍵を渡してきた人の信憑性が権威のある信頼できる第三者機関によって保証される。中間者攻撃を防ぐ。	ただし、その信頼できる第三者機関自体が改ざんされていたら
デジタル署名（ルート証明書）	中間証明書を証明する	さらに信頼できる第三者機関からその元々の第三者機関を証明してもらう(ルート証明書)。	さらに信頼のある第三者から中間証明者を保証してもらう。中間者攻撃を防ぐ。	最終的には自己署名の問題に回帰するが、多段に検証している分安全なので、問題なし
MAC(メッセージ認証コード)	メッセージの改竄を防ぐ	通信データに改ざん検知用の確認データ(メッセージ認証コード)を付与する機能	メッセージにDigitをつけてメッセージ自体が改ざんされていないかを保証する	なし

公開鍵暗号方式の種類

種別	目的
DH(Diffie-Hellman)	鍵交換	W. Diffie と M. Hellman が 1976年に発表した、共通鍵を安全に交換するための鍵配送アルゴリズムである。
RSA(Rivest-Shamir-Adleman)	暗号化署名鍵交換	Rivest, Shamir, Adleman の 3名が 1978年に発明したアルゴリズムである。同じ鍵ペアを暗号化と署名の両方に利用できることが特徴である。大きな整数の素因数分解が困難であるという仮定に基づいている。
DSA(Digital Signature Algorithm)	署名	NIST が 1991年に提唱した、デジタル署名のためのアルゴリズムである。離散対数問題を解くことが難しいという仮定に基づいている。デジタル署名専用のアルゴリズムであり、暗号化の機能はない。
楕円曲線暗号(ECC: Elliptic Curve cryptosystem)	暗号化署名鍵交換	Neal Koblitz と Miller が 1985年に別々に考案した方式である。特定のアルゴリズムを指すのではなく、離散対数問題に楕円曲線を適用させて、強度を保ちつつ鍵長を小さくするために用いられる [15]。主な適用例として、DSA に適用したECDSA が有名である。

DH鍵共有

DH 離散対数問題とフェルマーの小定理

素数と離散対数問題 (Discrete Logarithm Problem)

2^x mod n = xを次の表で示す。例えば、2の2(x)乗=4を3(n)でmodすると、答えは1。つまり、あまりは1。すると、nが素数のとき (7, 17, 23, 31 を除いて)、計算結果に 1 から n-1 までの全ての整数が登場する。

例えば n=37 のとき、1 から 36 が 1 回ずつ登場する。

また、そのようにならなかった n=7, 17, 31 についても、3^x mod n を計算すると同様に 1 から n-1 までの全ての整数が登場する。

このように、n が素数で、基数 g (前述の 2 とか 3 の部分) を適切な値に選ぶと、g^x mod n (1 ≦ x ≦ n-1) は 1 から n-1 までの整数が 1 回ずつ登場する。

このようなとき、g^x mod n = K の計算で、K 以外の 3 つのパラメータが与えられていて K を計算するのは比較的簡単であるのに対し、x 以外の 3 つのパラメータが与えられて x を計算するのは難しい、という性質がある。

この x を求める難しい問題のことをDiscrete Logarithm Problem (DLP: 離散対数問題) と呼ぶ。

以降、mod n の n (法の n) が素数のとき、mod p と記述する。素数を英語で prime と呼ぶからである。

DH 鍵共有アルゴリズムでは、g (基数) と n 改め p (適切な大きな素数) を公開パラメータ、x (1 ≦ x ≦ p-1) を各個人の秘密鍵、K (g^x mod p) を各個人の公開鍵として使う。

鍵のタイプ	数字
秘密鍵	g(基数)
秘密鍵	p(素数)
公開鍵	K(あまり)

フェルマーの小定理

先程の表で、n が素数のとき、n-1 の計算結果が必ず 1 になっていることに着目する。これはフェルマーの小定理と呼ばれるものである。

DH法の問題点は中間者攻撃

中間者攻撃とは、通信を行う２者の間に第三者が介入し、２者に気づかれないように情報を盗み見る方法。

下地図のように中間攻撃者がいると、共通鍵がバレてしまうので、メッセージの内容を復号化して中身を読めてしまう。

DH鍵共有とは

共通鍵暗号方式のために使われる共通暗号を共有する仕組み。具体的には、$a$, $b$を非公開鍵、$g$, $p$をパラメータとし、$g^a \mod p$や$g^b \mod p$を公開鍵とし、認識を合わせた上で、共有鍵を作る方式。

DH鍵共有の具体的な計算

DH鍵共有を使うプロトコル

IP ネットワーク通信において、暗号化による機密性と認証による通信相手の正当性を担保する技術として「IPsec」や「SSL/TLS」、「SSH」等がある。この 3 つのプロトコルは用途によって使い分けられるが、いずれも共通鍵暗号方式での通信暗号化のための「共通鍵の共有」を、【Diffie-Hellman 鍵共有 (DH 鍵共有)】というアルゴリズムによって実現している。

dh鍵交換の簡単な計算例

50 / 7 = 4あまり1を次のように表現する。

$$ \begin{align} 50 \mod 7 = 1 \\ 324 \mod 7 = 2 \end{align} $$

この剰余演算は普通の計算と同じような、以下の性質がある。

$$ \begin{align} (a \mod n) + (b \mod n) = (a+b) \mod n \\ (a \mod n) - (b \mod n) = (a-b) \mod n \\ (a \mod n) × (b \mod n) = ab \mod n \\ (a \mod n)^b = a^b \mod n \\ \end{align} $$

割り算も条件付きで定義可能だが、ここでは省略する。

$$ \begin{align} (50 \mod 7) + (324 \mod 7) = 374 \mod 7 = 3 \\ (50 \mod 7) - (324 \mod 7) = -274 \mod 7 = 6 \\ (50 \mod 7) × (324 \mod 7) = 16200 \mod 7 = 2 \\ \end{align} $$

SSL証明書

SSL証明書とは

HTTP通信を暗号化するには次のファイルが必要となる。

サーバーの公開鍵(CSR)と秘密鍵(Key)
認証局(CA)が電子署名したSSL証明書(CRT)と中間CA証明書 SSL証明書はサーバについての情報と、サーバの公開鍵、証明書を発行した認証局の情報が署名されているファイルである。

サーバの公開鍵はクライアントとの通信を「暗号化」する際に使用し、署名は「なりすまし」を防ぐために使う。

署名は、証明書を発行するCAと呼ばれる第三者機関が、CSRの情報を元に行う。

中間CA証明書は、SSL証明書を発行する認証局またはその配下にある別の認証局によって署名されたファイルである。必須ではありませんが、セキュリティレベルの向上を理由に、中間CAを1つい上用いる階層構造とる認証が現在は主流となっている。

SSLの用語と設定の違い

事前に用意するモノ

KEY:
- SSLの為のサーバー用の秘密鍵のこと。
CSR (Certificate Signing Request):
- SSLの為のサーバー用の公開鍵のこと。
- CSR には「公開鍵」とその所有者情報、及び申請者が対応する秘密鍵を持っていることを示すために申請者の署名が記載されている
- サーバの公開鍵はクライアントとの通信を「暗号化」する際に使用するリクエスト用

CSRの例

CA(認証局)によって発行されるSSL証明書

CRT:
- サーバー証明書
INCRT
- 中間CA証明書
ROOTCRT
- ルート証明書

CRTの例

SSL証明書の中身

SSL証明書 or SSLサーバー証明書 or サーバー証明書
- CRTとINCRTとROOTCRTの中身
- サーバについての情報と、サーバの公開鍵、証明書を発行した認証局の情報が電子署名されているファイル
- 階層構造になっている
- トラストチェーンでサーバー証明書を証明する中間CA証明書を証明するルート証明書という感じになっている
- ルート証明書はPCに直接保存されている

1
2
3


Example CA Root X1
 └Example CA intermediate G2
 └example.jp

SSL証明書発行と設定の流れ

SSL証明書の発行には、次のような手順が踏む。

自分のサーバーでCSRとKEYを作成
CSRをCAへ送信して証明書の発行を申請
CAから電子署名されたCRTと中間CA証明書を受け取る
受け取った証明書類をWebサーバーへ設置する

ディスティングイッシュネームとは？

ディスティングイッシュネームとは、CSRを作成する際に登録をする、ウェブサイトの所有者情報のことである。

項目名	項目の内容	入力例
Common Name	ウェブサイトのFQDN(Fully Qualified Domain Name)を登録する。サイトURLが「https://www.securecore.co.jp/」の場合だと、 Common Nameは「www.securecore.co.jp」と指定する必要がある。※CoreSSLワイルドカードの場合はサブドメインにも対応しているので、「*(アスタリスク).ドメイン名」で登録する。※FQDNとはドメイン名・サブドメイン名・ホスト名を省略せず記載した形式のことを指す。	www.securecore.co.jp
Organizational Name(※1)	ウェブサイト運営組織の法律上の正式英文名称を登録する。法人格(Co Ltd Inc K.K.等)は入力必須である。	SecureCore,Inc.
Organizational Unit(※1)	ウェブサイト運営組織の部署名を登録する。	Sales
City or Locality(※1)	ウェブサイト運営組織の市区町村名を登録する。	Osaka-Shi
State or Province(※1)	ウェブサイト運営組織の都道府県名を登録する。	Osaka
Country	国を示す２文字のISO略語である。大文字で登録する。	JP

電子証明書

CSR (証明書発行要求) とは

CSR とは証明書発行要求 (Certificate Signing Request) と呼ばれるもので、これを生成する際に、秘密鍵と公開鍵も作られる。

CSR には公開鍵が含まれており、この CSR を中間認証局に送り、中間認証局の秘密鍵で生成した電子署名 (CSR をハッシュ化したものを秘密鍵で暗号化) を CSR の末尾に付け加えることでデジタル証明書が出来上がる。

CSR = 公開鍵を含む情報
電子証明 = 認証局の秘密鍵で生成
デジタル証明書 = 電子証明 + CSR

デジタル署名とは？

電子文章をハッシュ化して非公開鍵を使って電子署名を作成。それに対して、公開鍵で検証する仕組み。

RSA署名の作成

RSA署名の検証

電子証明書が正しいかどうかは、認証局の公開鍵を用いて署名検証鍵（署名の対象となる電子文章）を復号化して、それをハッシュ関数に渡してハッシュ値が一致するかを確認する。

大前提として、非公開鍵で暗号化された文章は複合が可能。

電子証明書は印鑑登録書と同じ仕組み

SSL（電子証明書）の仕組みは、単純に言えば、印鑑登録証(印鑑証明)と同じ仕組み。

デジタル証明書を発行する中間認証局が、その中間認証局の秘密鍵でデジタル証明書にデジタル署名する。これにより、デジタル証明書に書かれたホスト名の機器は、中間認証局がお墨付きをくれた状態になる。(印鑑証明で言う地方役所)

じゃあ中間認証局の身元は誰が保証するの？というと、更に上位の認証局。

このプロセスを最上位であるルート認証局まで繰り返すが、ルート認証局の身元は誰が保証するの？というと、自分自身でサインする。これは自己署名証明書と呼ばれる (俗に言うオレオレ証明書)。(印鑑証明で言う日本国)

=> なのでルート証明書は必ず自己署名証明書 (オレオレ証明書) になる。

その他

実際のフロー

Webサーバーの事前準備

Webサーバーは予めCSRと秘密鍵を発行する
そのCSRを認証局に送る
認証局はCSRを認証局が持つ秘密鍵で暗号化する=デジタル証明書の作成
認証局はその暗号化したCSR(デジタル証明書)をWebサーバーに返す
Webサーバーはデジタル証明書と秘密鍵を設置する

Userからのアクセス

Userはデジタル証明書をWebサーバーに要求する
Userはデジタル証明書を認証局の公開鍵を使って検証
- 相手が認証局に証明されているデジタル証明書を使っているかを確認
- この時点で認証局に証明されたWebサーバーの公開鍵が入っているがまだ使わない
WebサーバーはDH公開鍵(SV)を作成
Webサーバーは秘密鍵でDH公開鍵(SV)を署名する = デジタル証明書(2)
Webサーバーはその新たなデジタル証明書(2)をUserに送る
Userはデジタル証明書の公開鍵でデジタル証明書(2)を検証
- 送られたデジタル証明書(2)は間違いなく認証局に認証されたWebサーバーから署名されたモノ
- つまり、中間攻撃者がいないことを認証局を使って確認した
Userは自分のDH公開鍵(CL)を送る
DH公開鍵(CL/SV)により、UserとWebサーバーは共通鍵を生成
それを利用してメッセージを暗号化する

NOTE:

CL = Client
SV = Server

TSL SNIとは？

つのサーバーで1つしか使えなかったSSLサーバー証明書が、ドメイン名（URL）単位で利用できるようになる技術。

仕組みとしてはSSL通信時にドメイン名を通知することで、サーバー側がどのSSLサーバー証明書を利用すべきか判別する。

これによって、1台のサーバーでもドメイン名の数だけSSLサーバー証明書の利用が可能になり、URLが途中で変わってしまう心配や、SSLサーバー証明書ごとに別々のサーバーを用意するといった手間やコストの負担が軽減された。

暗号スイートとは

SSLは4種類の機能を組み合わせたハイブリット暗号技術。英語で Cipher Suites と言い、TLSの暗号通信のためのプロトコルで複数の暗号化アルゴリズムの組み合わせのことを指す。

	目的	アルゴ
Kx(鍵交換方式)	鍵交換に使われる暗号化アルゴリズム	DHE (ディフィー・ヘルマン鍵共有)
Au(鍵認証方式)	鍵が正しいかの認証に使われる暗号化アルゴリズム	RSA認証
Enc(メッセージ暗号方式)	暗号化したい通信データ自体の暗号化。アプリケーション層の暗号化に使われるアルゴリズム	AES
Mac(メッセージ署名方式)	暗号化した通信データの改ざんチェック。メッセージの検証に使われるアルゴリズム	SHA1

例

opensslで使われる暗号化スイートの一覧。

1
2
3
4
5
6
7


$ openssl ciphers -v
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD

一番上を抜粋すると、

1
2


1 2 3 4 5 6
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD

番号で読み解くと次の意味

1
2
3
4
5
6
7
8


1.暗号化スイートの名前
 - ECDHE-RSA-AES256-GCM-SHA384 の箇所
1. SSLのバージョン
3. ECDHE : 鍵交換方式(Kx)を意味する
4. RSA : 鍵認証方式(Au)を意味する
5. AES256 : メッセージ暗号方式(Enc)を意味する
5. GCM : ブロック処理を意味する
5.6. SHA384 : メッセージ署名方式(Mac)を意味する

参考文献

ハッシュ・MAC・デジタル署名・証明書・鍵交換の関係

Thu, 30 Apr 2026 22:08:46 +0900

背景

昔、仕事で暗号技術を理解して実装する必要があった。

そのときに調べていたメモが見つかったため、消すのももったいないので、ここに整理して残しておく。今は細かいところを忘れているし、また必要になる時が来る気がする。

この記事では、暗号技術のうち、特に混乱しやすい以下の関係を整理する。

ハッシュ
MAC / HMAC
デジタル署名
デジタル証明書
PKI
共通鍵暗号
公開鍵暗号
Diffie-Hellman鍵交換
ゼロ知識証明

この記事の結論

暗号技術は、それぞれ守る対象が違う。

技術	主な目的	守れるもの	守れないもの
共通鍵暗号	暗号化	機密性	鍵配送、送信者の証明
ハッシュ	要約値の生成	変更検知の材料	機密性、真正性
MAC / HMAC	メッセージ認証	完全性、共有鍵ベースの真正性	否認防止
デジタル署名	署名・検証	完全性、公開鍵ベースの真正性、否認防止	機密性
デジタル証明書	公開鍵の身元確認	公開鍵と主体者の対応関係	メッセージ本文の暗号化
DH / ECDH鍵交換	鍵合意	通信路に共有鍵を流さずに鍵材料を作ること	相手認証単体

ざっくり言うと、こういう関係になる。

メッセージを隠したいなら、AESなどの共通鍵暗号で暗号化する。
メッセージが変わっていないか確認したいなら、ハッシュを使う。ただし、ハッシュだけでは攻撃者による改ざんには弱い。
メッセージの改ざんと、共有鍵を知っている相手から来たことを確認したいなら、MACを使う。
第三者にも「この人が署名した」と示したいなら、デジタル署名を使う。
その公開鍵が本当に本人のものか確認したいなら、デジタル証明書とPKIを使う。
通信のたびに安全な共通鍵を作りたいなら、DH / ECDH鍵交換を使う。

情報セキュリティ

情報セキュリティの三要素

情報セキュリティでは、よく次の3要素が使われる。

要素	英語	意味
機密性	Confidentiality	許可された者だけが情報にアクセスできる状態
完全性	Integrity	情報が正確で、改ざん・破壊されていない状態
可用性	Availability	許可された者が、必要なときに情報へアクセスできる状態

暗号技術は、このうち主に機密性・完全性・真正性を支えるために使われる。

ISMS

ISMSは Information Security Management System の略で、日本語では「情報セキュリティマネジメントシステム」と呼ばれる。

組織が情報の機密性・完全性・可用性を維持し、継続的に改善するための管理の仕組みである。

ZKP

ZKPとは

ZKPは Zero-Knowledge Proof の略で、日本語ではゼロ知識証明と呼ばれる。

ゼロ知識証明とは、証明者が「ある秘密を知っている」という主張を、秘密そのものを明かさずに検証者へ納得させるためのプロトコルである。

ポイントは次の通り。

証明者は秘密を知っている
検証者は秘密そのものを知らない
検証者は「証明者が秘密を知っている」という事実だけを確認する
秘密に関する余計な情報は漏れない

アリババの洞窟

前提

洞窟にはAとBの2つの通路がある
奥には鍵で開く扉があり、AとBは奥でつながっている
Victorは鍵を知らない
Peggyは鍵を知っている
Victorは、Peggyが本当に鍵を持っているか確認したい
Peggyは、Victorに鍵そのものを教えたくない

ここで妥協点として、Peggyは「扉を開ける能力がある」という事実だけを示す。鍵そのものは教えない。

アルゴリズム

初期状態では、Peggyは分岐点にいる。Victorは洞窟の入口にいる。

次のラウンドを必要な回数だけ繰り返す。

Peggyは、分岐点からPath AまたはPath Bのどちらかを選んで進む。この時点でVictorはPeggyがどちらを選んだか見えない。
Victorは、Peggyに「Aから戻ってきて」または「Bから戻ってきて」と指示する。
Peggyは、Victorの指示通りのPathから分岐点に戻る。
- Peggyが最初に選んだPathとVictorの要求Pathが同じなら、そのまま戻ればよい。
- Peggyが最初に選んだPathとVictorの要求Pathが違うなら、扉の鍵を使って反対側へ移動し、要求されたPathから戻る。
Victorは、Peggyが要求通りのPathから戻ってきたか確認する。
- 要求通りなら検証OK。
- 要求通りでなければ検証NG。「Peggyは鍵を持っていない」と判断する。
Victorは入口に戻る。

Peggyが鍵を知らない場合、1回のラウンドを偶然突破できる確率は1/2である。ラウンド数を増やすほど、偶然すべて成功する確率は小さくなる。

注意点

重要なのは、PeggyがVictorの指示より前にPathを選択する点である。

Victorが先にPathを指定してしまうと、PeggyはそのPathに進めばよいだけになる。これでは、Peggyが鍵を持っていることの証明にならない。

また、VictorがPeggyの進んだPathを最初から見てしまうのもよくない。Victorに見られたという事実がPeggyへのヒントになり、プロトコルの性質が変わる。

OAuthとの違い

OAuthは、パスワードを第三者サービスに渡さずに権限を委譲する仕組みである。この点だけを見ると、「秘密を直接渡さない」という意味でゼロ知識証明と似て見える。

ただし、OAuthはゼロ知識証明ではない。OAuthは認可のためのフレームワークであり、第三者アプリケーションに限定的なアクセス権を与えるための仕組みである。

暗号の種類

共通鍵暗号と公開鍵暗号

暗号方式は、大きく次の2つに分けられる。

種類	別名	鍵の使い方	代表例
共通鍵暗号	対称鍵暗号、秘密鍵暗号	暗号化と復号に同じ鍵を使う	AES、ChaCha20
公開鍵暗号	非対称鍵暗号	公開鍵と秘密鍵のペアを使う	RSA、ElGamal、楕円曲線暗号

共通鍵暗号

共通鍵暗号は、暗号化と復号に同じ鍵を使う方式である。

たとえばAESでは、送信者と受信者が同じ秘密鍵を共有し、その鍵でデータを暗号化・復号する。

共通鍵暗号の特徴は次の通り。

処理が速い
大量データの暗号化に向いている
送信者と受信者が同じ鍵を持つ必要がある
鍵をどう安全に共有するか、という鍵配送問題がある

代表的な共通鍵暗号には、AESやChaCha20がある。RC4、DES、3DESは歴史的には重要だが、現在の新規設計では避けるべきレガシーな方式として扱う方がよい。

公開鍵暗号

公開鍵暗号は、ペアとなる2つの鍵を使う方式である。

公開鍵は他人に渡してよい
秘密鍵は本人だけが持つ
公開鍵で暗号化したデータは、対応する秘密鍵で復号する
秘密鍵で作った署名は、対応する公開鍵で検証する

公開鍵暗号を使うと、共通鍵暗号のように「同じ鍵を事前に安全な経路で渡す」必要は減る。

ただし、公開鍵暗号にも別の問題がある。受け取った公開鍵が本当に相手本人のものか分からなければ、中間者攻撃を受ける可能性がある。そのため、公開鍵の真正性を確認する仕組みとして、デジタル証明書やPKIが必要になる。

Diffie-Hellman鍵交換

Diffie-Hellman鍵交換は、安全でない通信路上で、共通鍵の材料となる共有秘密を作るための鍵合意方式である。

注意点として、DH鍵交換は「共通鍵を安全に送る方式」ではない。共通鍵そのものは通信路に流さない。双方が公開情報を交換し、それぞれの秘密情報と組み合わせて同じ共有秘密を計算する。

その共有秘密から、KDF（Key Derivation Function）を使って実際の暗号鍵を導出する。

DH鍵交換の特徴は次の通り。

共通鍵そのものを通信路に流さない
データ本文の暗号化方式ではない
鍵交換・鍵合意のための方式である
認証なしのDHは中間者攻撃に弱い
実際のプロトコルでは、証明書や署名などと組み合わせて相手認証を行う

楕円曲線を使う方式はECDHと呼ばれる。現在のTLSでは、ECDHEのような一時鍵を使う方式がよく使われる。

ハッシュ

ハッシュ化とは

ハッシュ化とは、元データからハッシュ関数を使って固定長の値を生成する処理である。この固定長の値を、ハッシュ値、ダイジェスト、メッセージダイジェストなどと呼ぶ。

暗号学的ハッシュ関数には、主に次の性質が求められる。

性質	意味
原像計算困難性	ハッシュ値から元データを求めるのが困難であること
第二原像計算困難性	あるデータと同じハッシュ値になる別データを作るのが困難であること
衝突困難性	同じハッシュ値になる2つの異なるデータを見つけるのが困難であること

ハッシュは暗号化ではない。ハッシュ値から元データを復元することを目的としない。

ハッシュで確認できること

ハッシュは、データが変化していないか確認する材料として使える。

たとえば、ソフトウェアの配布元がハッシュ値を公開している場合、ダウンロードしたファイルのハッシュ値を自分で計算し、公開値と一致するか確認できる。

ただし、ハッシュだけで改ざんを防げるわけではない。攻撃者がファイル本体とハッシュ値の両方を差し替えられる場合、ハッシュ値も一緒に作り直されてしまう。

つまり、ハッシュ単体では次のことは保証できない。

誰が作ったデータか
攻撃者が本文とハッシュ値を両方差し替えていないか
データが秘匿されているか

これらを確認するには、MACやデジタル署名が必要になる。

代表的なハッシュ関数

代表的な暗号学的ハッシュ関数には、次のようなものがある。

SHA-256
SHA-384
SHA-512
SHA-3

MD5やSHA-1も歴史的にはよく使われたが、現在の新規設計では使うべきではない。MD5やSHA-1は衝突攻撃に対して弱く、現代のセキュリティ用途ではレガシーな方式として扱う。

CRC、チェックサム、パリティチェックとの違い

CRC、チェックサム、パリティチェックも、データの誤り検出に使われる。

ただし、これらは主に偶発的なエラー検出のための仕組みであり、攻撃者による意図的な改ざんに耐えることを目的としていない。

方式	主な用途	暗号学的な改ざん耐性
パリティチェック	単純なビット誤り検出	ない
チェックサム	簡易な誤り検出	ない
CRC	通信・保存時の誤り検出	ない
暗号学的ハッシュ	改ざん検出の材料	ある

パスワードのハッシュ化

通常のハッシュとの違い

パスワード保存では、単純にSHA-256などでハッシュ化するだけでは不十分である。

理由は、パスワードは人間が覚えるため、入力の候補が偏りやすいからである。攻撃者はよく使われるパスワードを大量に試すことで、ハッシュ値から元のパスワードを推測できる。

そのため、パスワード保存では専用のパスワードハッシュ方式を使う。

代表例は次の通り。

Argon2id
bcrypt
scrypt
PBKDF2

ソルト

ソルトは、パスワードごとに付与するランダムな値である。

パスワードとソルトを組み合わせてハッシュ化し、ソルトとハッシュ値をデータベースに保存する。

ソルトの目的は、同じパスワードでもユーザーごとに異なるハッシュ値にすること。これにより、レインボーテーブル攻撃や、同じパスワードを使っているユーザーの一括特定を難しくできる。

ソルトは秘密にする必要はない。ハッシュ値と一緒に保存してOK。

ストレッチング

ストレッチングは、ハッシュ計算を意図的に重くする考え方である。

攻撃者が1つの候補パスワードを試すたびに高い計算コストがかかるようにし、総当たり攻撃や辞書攻撃を遅くする。

現在は「数千〜数万回ハッシュ化する」とだけ考えるより、Argon2id、bcrypt、scrypt、PBKDF2などのパスワード保存用アルゴリズムを使い、ワークファクターやメモリコストを適切に設定する方がよい。

認証・真正性・完全性

用語の整理

用語	意味
完全性	データが改ざん・破壊されていないこと
真正性	主張された主体・データ・記録が本物であること
認証	相手やデータが主張通りであることを確認すること
否認防止	後から「自分はやっていない」と否認しにくくすること

メッセージ認証とは、受信したメッセージが改ざんされておらず、期待した相手から来たものだと確認する技術である。

MAC / HMAC

MACとは

MACは Message Authentication Code の略で、日本語ではメッセージ認証コードと呼ばれる。

MACは、共有鍵とメッセージから短い認証コードを生成する仕組みである。

送信側は、メッセージと共有鍵からMAC値を計算し、メッセージと一緒に送る。受信側も同じ共有鍵と受信メッセージからMAC値を計算し、送られてきたMAC値と比較する。

一致すれば、次のことを確認できる。

メッセージが改ざんされていないこと
同じ共有鍵を知っている相手がMAC値を作ったこと

HMACとは

HMACは、ハッシュ関数を使ってMACを構成する方式である。

たとえば、HMAC-SHA-256、HMAC-SHA-512などがある。

HMACは単なる hash(key + message) ではない。鍵とメッセージを安全に組み合わせるための決まった構造を持つ。

MACの限界

MACは、共有鍵を持つ者同士のメッセージ認証には向いている。

ただし、共有鍵を使うため、第三者に対する証明には向かない。AとBが同じ鍵を持っている場合、あるMAC値を作ったのがAなのかBなのかを第三者に証明できない。

そのため、MACには否認防止性がない。

AEAD

実際の通信では、「暗号化」と「MAC」を別々に組み合わせるより、AEADを使うことが多い。

AEADは Authenticated Encryption with Associated Data の略で、暗号化と認証をまとめて扱う方式である。

代表例は次の通り。

AES-GCM
ChaCha20-Poly1305

AEADを使うと、次の性質を同時に得られる。

メッセージの機密性
メッセージの完全性
メッセージの真正性
追加認証データの保護

TLSなどの現代的なプロトコルでは、AEADが重要な役割を持つ。

デジタル署名

デジタル署名とは

デジタル署名は、秘密鍵で署名を生成し、公開鍵で署名を検証する仕組みである。

基本的な流れは次の通り。

送信者はメッセージを作成する。
送信者はメッセージからハッシュ値を計算する。
送信者は秘密鍵を使って署名値を生成する。
送信者はメッセージと署名値を受信者に送る。
受信者はメッセージからハッシュ値を計算する。
受信者は送信者の公開鍵を使って署名を検証する。
検証に成功すれば、メッセージの完全性と、秘密鍵を持つ主体による署名であることを確認できる。

ここで重要なのは、「秘密鍵で暗号化して公開鍵で復号する」と雑に理解しないこと。

RSA署名ではそのように説明されることもあるが、ECDSAやEdDSAではその説明は成り立たない。一般化して言うなら、秘密鍵で署名を生成し、公開鍵で署名を検証する、という理解がよい。

デジタル署名で分かること

デジタル署名によって、次のことを確認できる。

メッセージが改ざんされていないこと
対応する秘密鍵を持つ主体が署名したこと
署名者が後から否認しにくいこと

ただし、デジタル署名は暗号化ではない。署名付きメッセージは、暗号化されていなければ中身を読める。

機密性が必要なら、署名とは別に暗号化が必要である。

デジタル署名の代表例

代表的なデジタル署名方式には、次のものがある。

RSA署名
DSA
ECDSA
EdDSA

新規設計では、利用環境や標準に応じて、ECDSAやEdDSAなどの楕円曲線ベースの署名方式が使われることが多い。

MACとデジタル署名の違い

MACとデジタル署名は、どちらもメッセージの完全性と真正性に関係する。ただし、使う鍵と性質が違う。

比較項目	MAC	デジタル署名
鍵	共通鍵	秘密鍵・公開鍵ペア
検証者	同じ共通鍵を持つ者	公開鍵を持つ者
完全性	確認できる	確認できる
真正性	共有鍵を知る相手として確認できる	秘密鍵を持つ署名者として確認できる
否認防止	できない	できる
処理速度	速い	MACより重いことが多い
代表例	HMAC-SHA-256、AES-CMAC	RSA署名、ECDSA、EdDSA

MACは「内輪での確認」に強い。デジタル署名は「第三者にも示せる証明」に強い。

PKIとデジタル証明書

PKIとは

PKIは Public Key Infrastructure の略で、日本語では公開鍵基盤と呼ばれる。

PKIの目的は、公開鍵と主体者の対応関係を信頼できる形で扱うこと。

公開鍵暗号やデジタル署名では、公開鍵を使って暗号化や検証を行う。しかし、そもそもその公開鍵が本当に相手本人のものか分からなければ意味がない。

そこで、CA（認証局）が「この公開鍵はこの主体者のものだ」と証明する。

デジタル証明書とは

デジタル証明書は、公開鍵と主体者情報を結びつけ、それにCAが署名したデータである。

より正確には、一般に使われるX.509証明書には、次のような情報が含まれる。

主体者名
主体者の公開鍵
発行者名
有効期間
鍵用途
拡張領域
CAによる署名

つまり、デジタル証明書は「公開鍵そのもの」ではない。「公開鍵が誰のものか」を証明するためのデータである。

デジタル署名とデジタル証明書の違い

用語	たとえ	役割
デジタル署名	ハンコ	データに対して、秘密鍵で署名する
デジタル証明書	身分証・印鑑証明	公開鍵が誰のものかをCAが証明する

デジタル署名は、メッセージやファイルなどのデータに対する署名である。

デジタル証明書は、公開鍵と主体者の対応関係に対する証明である。

ざっくり言うと、次の関係になる。

1
2


デジタル署名 = データに対して秘密鍵で作る署名
デジタル証明書 = 公開鍵と主体者情報に対してCAが署名したもの

証明書だけでは中身は隠れない

証明書は、公開鍵が誰のものかを確認するためのものだ。メッセージ本文を暗号化するものではない。

そのため、通信では次のように複数の技術を組み合わせる。

証明書で相手の公開鍵を確認する。
署名や証明書チェーンで相手を認証する。
DH / ECDHで共有秘密を作る。
KDFで共通鍵を導出する。
AES-GCMやChaCha20-Poly1305などのAEADで通信内容を保護する。

属性証明書

通常のX.509公開鍵証明書は、公開鍵と主体者の対応関係を証明する。

一方、属性証明書は、主体者の権限や役割などの属性情報を証明するための証明書である。

たとえば、「この利用者は管理者権限を持つ」「この主体は特定のロールに所属する」といった情報を、公開鍵証明書とは別に扱う考え方である。

公開鍵証明書が「この公開鍵は誰のものか」を扱うのに対して、属性証明書は「その主体がどの属性を持つか」を扱う。

否認防止

デジタル署名には否認防止の効果がある。

たとえば、A社がB社へ発注書を送る場面を考える。A社が発注書にデジタル署名し、B社がA社の公開鍵で署名を検証できたとする。

このとき、B社は次のことを主張しやすくなる。

発注書は改ざんされていない
A社の秘密鍵で署名された
A社は後から「送っていない」と否認しにくい

ただし、現実の否認防止は署名アルゴリズムだけでは完結しない。秘密鍵の管理、証明書の有効性、失効確認、タイムスタンプ、運用ルールなども関係する。

全体の流れ

ここまでの話を、実際の通信に近い流れでまとめる。

暗号化で機密性を守る
- メッセージを第三者に見られたくない場合、AESなどの共通鍵暗号で暗号化する。
- ただし、暗号化だけでは「改ざんされていないか」「誰が送ったのか」までは十分に確認できない。
ハッシュで変更検知の材料を作る
- ハッシュを使うと、データから固定長の値を作れる。
- ハッシュ値を信頼できる経路で受け取れるなら、データが変化していないか確認できる。
- ただし、攻撃者が本文とハッシュ値を両方差し替えられる場合、ハッシュだけでは不十分である。
MACでメッセージ認証する
- 共有鍵を使ってMACを計算すれば、メッセージの完全性と、共有鍵を知っている相手から来たことを確認できる。
- ただし、MACは共有鍵方式であるため、第三者に対する否認防止には使いにくい。
デジタル署名で第三者にも示せる署名を作る
- デジタル署名を使えば、秘密鍵で署名を生成し、公開鍵で検証できる。
- これにより、完全性、公開鍵ベースの真正性、否認防止を実現できる。
- ただし、デジタル署名だけでは本文は隠れない。
証明書で公開鍵を信頼する
- デジタル署名を検証するには公開鍵が必要である。
- しかし、その公開鍵が本当に本人のものか分からなければ、検証結果は信用できない。
- そこで、CAが署名したデジタル証明書を使い、公開鍵と主体者の対応関係を確認する。
鍵交換で通信ごとの共通鍵を作る

共通鍵暗号は高速だが、共通鍵をどう共有するかという問題がある。
DH / ECDH鍵交換を使うと、共通鍵そのものを通信路に流さずに、双方で共有秘密を作れる。
実際の通信では、公開鍵証明書で相手を認証し、ECDHEなどで共有秘密を作り、そこから導出した共通鍵でAEAD暗号化する、というハイブリッド方式がよく使われる。

まとめ

暗号技術は、ひとつだけで全てを守るものではない。

機密性を守るなら、共通鍵暗号やAEADを使う
完全性の確認材料を作るなら、ハッシュを使う
共有鍵ベースで真正性も確認するなら、MACを使う
第三者にも示せる署名が必要なら、デジタル署名を使う
公開鍵の持ち主を確認するなら、デジタル証明書とPKIを使う
通信ごとの鍵を安全に作るなら、DH / ECDH鍵交換を使う

ハッシュ、MAC、デジタル署名、証明書は似た場所に出てくるため混乱しやすい。

しかし、見るべき軸はシンプル。

観点	使う技術
中身を隠したい	暗号化、AEAD
変わっていないか見たい	ハッシュ、MAC、署名
共有鍵を知る相手か見たい	MAC
秘密鍵を持つ署名者か見たい	デジタル署名
公開鍵が本人のものか見たい	デジタル証明書、PKI
共通鍵を通信ごとに作りたい	DH / ECDH鍵交換

この対応関係を押さえると、暗号技術の全体像がかなり見えやすくなる。

そのうち、エンドツーエンドの暗号化やmTSLや秘密分散なども残す。