社内勉強会の資料。

1. 第5回Web技術勉強会
暗号技術編その3
田実 誠

2. • デジタル署名
• 概要、問題点
• MITM
• フィンガープリント（MITMを防ぐ手段の一つ）
• 証明書
• 証明書の仕組み、認証局
• X.509
• 認証プロセス
• 各種証明書エラー
• Diffie-Hellman鍵交換
アジェンダ

3. デジタル署名
• 秘密鍵と公開鍵の2種類の鍵ペアを利用する。
• 秘密鍵で暗号化した暗号文は対の公開鍵でなければ復号化できない、という特性を利用
※公開鍵暗号は「公開鍵で暗号化した暗号文は対の秘密鍵でなければ復号化できない」という特性を利用
• 秘密鍵で署名（暗号化）して、公開鍵で検証（復号化）する
※ただし、誰でも復号化できるので「機密性」を高めるための暗号化ではなく、「鍵を持っている人にしか作り出せない
情報」として利用される
② メッセージ＋デジタル署名を送信
① 秘密鍵を使って、メッセージのハッシュに対する
デジタル署名を作成
③ 公開鍵を使って受信したデジタル署名を復号化
④ メッセージのハッシュと③で復号化したデータが一致すれば認証成功
受信者送信者

4. デジタル署名
• 計算時間短縮のため、メッセージのハッシュ値に対して署名される
• 否認防止
→送信者しか鍵を持っていないので、署名を作成したことを否定出来ない（署名を作成できるのは送信者だけ）
• デジタル署名に使えるアルゴリズムは「RSA」「DSA」「ElGamal」「Rabin」など
• JWT(JWS)、SAML、WS-Security、公開鍵の証明書（サーバ、クライアント）、DNSSec、DomainKeys、
DKIM等で利用される

5. 再びMITM
• 公開鍵の仕組みを使っているため、公開鍵暗号と同様にMan In The Middleによる攻撃が可能
③偽のデータを署名付きで送る
①攻撃者の公開鍵を
「受信者の公開鍵」として渡す
④攻撃者の公開鍵で検証
→OK
攻撃者 送信者受信者
②攻撃者の秘密鍵で署名を作成
• 問題は「送信者の公開鍵」が「攻撃者の公開鍵」にすり替わっている（なりすまし）こと
→このなりすましを防ぐ手段が「デジタル証明書」（＝公開鍵が正しいことを証明する仕組み

6. フィンガープリント
• SSHの話で正しい接続先かを確認する手段としてフィンガープリントがある
• SSHインストール後に、公開鍵のフィンガープリント（ハッシュ値）をメモる
• 接続時にフィンガープリンタが表示されるので正しいかどうかを確認
$ ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub
256 25:63:5c:ba:db:a7:42:54:8d:53:4f:f7:fc:db:55:ed root@twitter-worker (ECDSA)
$ ssh fuga.hogehogehoge.com
The authenticity of host '[fuga.hogehogehoge.com]:22 ([128.199.77.22]:22)' can't be
established.
ECDSA key fingerprint is 25:63:5c:ba:db:a7:42:54:8d:53:4f:f7:fc:db:55:ed.
Are you sure you want to continue connecting (yes/no)?

7. 証明書
• 信頼できる認証局（CA）が公開鍵に対して「デジタル署名」をしたもの
• 信頼している認証局の公開鍵を使って「デジタル署名」の検証を行うことで、公開鍵が正しいことを証明する
• 検証OKであれば、信頼している認証局が「デジタル署名」をしたものなので、その公開鍵が正しい
2-2. 認証局の公開鍵で証明書のデジタル署名
を検証→OKであれば正しい受信者の公開鍵
1-1. 公開鍵＋証明書の情報を認証局に送付
受信者送信者
1-3. 認証局の公開鍵を送付
認証局
2-1. 証明書（公開鍵＋デジタル署名含む）を
送信者に送付
1-2. 認証局の秘密鍵でデジタル署名を行う

8. X.509
• 証明書の標準規格
• 署名前証明書
• アルゴリズム
• デジタル署名本体
$ openssl x509 -text –noout –in xxx.example.com.cer
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:74:33:66:74:ca:09:c8:8f:5c:47:4f:7c:7f:ea:7c:e6:22
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Validity
Not Before: May 18 14:04:00 2016 GMT
Not After : Aug 16 14:04:00 2016 GMT
Subject: CN=worker.freedom-man.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:d8:71:2b:6e:d9:b6:bb…
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
…
Signature Algorithm: sha256WithRSAEncryption
53:eb:8d:27:90:6d:19:b3:cc:19:b2:5a:d1:3c:b0:68:52:…

9. ルート証明書と中間証明書
• ルート認証局（ルートCA）
• 中間認証局（中間CA）
• ルートCAから認証を受けた認証局
1-1. 中間CAの公開鍵を、ルートCAの秘密鍵で
「デジタル署名」をして、証明書を発行
ルートCA
送信者
中間CA受信者
1-2. 受信者の公開鍵を、中間CAの秘密鍵で
「デジタル署名」をして、証明書を発行
1-3. ルートCAの公開鍵を送付
2-2. 中間CAの証明書（デジタル署名）をルートCAの公開鍵で検証
→検証OKであれば中間CAの公開鍵は正しいことが証明される
2-3. 受信者の証明書（デジタル署名）を中間CAの公開鍵で検証
2-1. 受信者の証明書（公開鍵＋デジタル署名）＋
中間CAの証明書（公開鍵＋デジタル署名）を送信者に送付

10. 認証局の認証プロセス
• 認証局がデジタル署名をするときの公開鍵は本当にその人の公開鍵？
→認証局に証明書を作成してもらうプロセスの中で「認証」の仕組みが無いと、攻撃者が受信者になりすまし、
公開鍵を認証局に渡して証明書を作れてしまう
→証明書作成のプロセスには「認証」の仕組みがある
• ドメイン認証（メール、Webサーバ）
• 正しいドメイン所有者であることを認証条件とする
• 組織名や組織の所在地情報は含まれない
• Let’s Encryptはこのタイプのみ
• 企業認証
• 正しいドメイン所有者であること＋証明書に記載される組織が法的に存在することを認証条件とする
• 組織名や組織委の所在地情報が含まれる
• EV（Extended Validation）
• 正しいドメイン所有者であること＋証明書に記載される組織が法的、物理的に存在することを認証条件とする
• 世界標準の認証ガイドラインがあり、サーバ証明書の中で最も厳格な審査が行われる
• Chromeだとアドレスバーにグリーンバーが表示される

11. ドメイン認証と企業認証/EV認証
ドメイン認証（Let’s Encrypt)
EV認証
企業認証

12. 証明書に関する問題点
• 仕組み上、認証局の秘密鍵が漏洩するとアウト
• あるいは正しい認証局になりすまされるとアウト
• 逆に、信頼できる公開鍵が入手できるのなら、認証局や証明書の仕組みは不要
• そもそも認証局（ルートCA）はどうやって信頼する？
→メーラやWebブラウザにはデフォルトで有名な認証局の証明書が登録されている

13. 証明書関連のエラー
証明書のドメインとアクセス先が異なる場合
不正な認証局
有効期限切れ

14. Diffie-Hellman鍵交換
• 共通の値をもとに、非公開値と公開値をそれぞれのクライアントで生成し、公開値をお互いに交換
→それぞれのクライアントで鍵の値を計算し、お互いに同じ値になる
→これが共通鍵となる
② 非公開値xを生成
④ セッション鍵=(Y^x)%p
①g, p（素数）を選択して、双方で共有
② 非公開値yを生成
④ セッション鍵=(X^y)%p
③ 公開値X=(g^x)%p を渡す
③ 公開値Y=(g^y)%p を渡す

15. 暗号化は圧縮技術
• 平文→暗号文：機密性の圧縮
• 長い平文を全て守るのは難しいので、短い鍵を守る方が容易
• ハッシュ化：正真性の圧縮
• メッセージ全文を確認するのは難しいので、短いハッシュ値を確認する方が容易
• メッセージ認証、デジタル署名：認証の圧縮
• メッセージ全文を認証に使うのは難しいので、短い認証子を調べる
• KEK(Key Encryption Key)
• 複数の暗号鍵を守るよりも１つの暗号鍵を守る方が容易
• SSO(Single Sign On)
• 複数の箇所でクレデンシャル、認証管理をするよりも、１つの箇所でクレデンシャル、認証管理する方が容易
• ルートCA／中間CA
• 中間CAをルートCAが認証することで、ルートCAを強固にすれば良い

16. • デジタル署名を使うことで「認証」だけでなく、「否認不可性」を高めることができる
• 証明書は「公開鍵が正しい」ことを証明し、なりすましを防ぐ技術
• 証明書は認証局によって「正しい」ことを証明される
• Diffie-Hellman鍵交換を使って安全に共通鍵を共有することができる
まとめ