社内読書会

1. プロフェッショナルSSL/TLS
1, 2章
2017/4/10
光成滋生

2. • 『Bulletproof SSL and TLS』（Ivan Ristic/齋藤孝道訳）
• 1～2 TLSの復習
• 3～4 PKI
• 5～7 各種攻撃
• 8～ 安全なサーバの設定
• 9 パフォーマンス
• 10 TSTS, CSP, 公開鍵pinning
• 11, 12 OpenSSL
• 13 Apache
• 14 Java, Tomcat
• 15 IIS
• 16 Nginx
概要
2 / 27

3. • TLSの目標
• 暗号学的なセキュリティ
• 安全な通信が最優先
• 相互運用性
• 異なるプログラムやライブラリが同じパラメータで通信可能
• 拡張性
• プロトコルを作り直さなくても新しい技術に対応できる
• 効率性
• コストの高い暗号処理を最小限にする
1章 SSL/TLSと暗号技術
3 / 27

4. • OSIモデル
• SSL/TLSはアプリケーション層（HTTP, SMTPなど）とトラン
スポート層（TCP, UDP）の間にある
• TLSを取り除いてもTCPの上でHTTPが動く
• 暗号技術
• confidentiality ; 機密性 ; 秘密が守られること
• authenticity ; 真正性 ; 本人であることを検証できること
• integrity ; 完全性 ; 改竄されることなく転送されること
OSIモデル、暗号技術
4 / 27

5. • 暗号システムは鍵以外の全てが攻撃者に掌握されても
安全でなければならない
• 暗号アルゴリズムは複数人で共有する
• 共有する相手が増えると敵対する相手にアルゴリズムが漏れ
る可能性が高くなる
• 鍵がないと人数が増えたときに多数の人が復号できてしまう
• 優れた暗号アルゴリズムを作るのは難しい
• たくさんの人が精査して初めて安全と思われる
Kerckhoffsの原則
5 / 27

6. • 事前に秘密鍵を共有しておきデータを暗号化する
• 他人は途中経路で眺めても分からない
• 全数探索
• 鍵の種類だけ試すこと
• p.6では全数探索しか暗号を破る方法が無いとき計算量的安全
と読めなくもないが必ずしもそういうわけではない
• 全数探索しなくて破る方法があったとしても、その方法の計
算量が十分大きければ安全
共通鍵暗号
6 / 27

7. • ストリーム暗号
• 鍵ストリーム ; ランダムなデータの無限列（バイト列）
• 暗号化はこれと排他的論理和を求める
• 同じ鍵を使い回さないことが重要
• ブロック暗号
• データの固まりごとに暗号化
• 16バイト単位のものが多い
• 任意の長さのデータを扱うには暗号化モードと併用
• パディングなど
• 暗号モード
• ECB, CBC, CFB, OFB, CTR, GCM
• 最近はGCMを推奨
ストリーム暗号とブロック暗号
7 / 27

8. • データの完全性の検証
• 原像計算困難性（preimage resistance）
• 第2原像計算困難性（second preimage resistance）
• 衝突耐性（collision resistatnce）
• MAC（メッセージ認証コード）
• ハッシュ関数でハッシュ値はデータと一緒に送信できない
• 秘密鍵（MAC鍵ともいう）とデータからハッシュ関数を組み
合わせてハッシュ値（MAC値ともいう）を作る
• MAC鍵は別途秘密に共有しておく
ハッシュ関数とMAC
8 / 27

9. • 公開鍵暗号
• 暗号化する鍵と復号する鍵を別々にした
• 共通鍵暗号はn人のうち二人が秘密に通信し合おうとすると
n(n-1)/2個の秘密鍵が必要
• 同じ鍵を使い回すと第三者に漏れやすい
• 共通鍵暗号より計算時間がかかることが多い
• デジタル署名
• 真正性を検証可能にする技術
• MACはMAC鍵の共有が面倒
• 秘密鍵で署名をつけて公開鍵（検証鍵）で真正性を確認
公開鍵暗号とデジタル署名
9 / 27

10. • 暗号で使う擬似乱数生成器は予測不可能性が大事
乱数生成器
10 / 27

11. • AliceとBobが安全に通信できるにはどうするか
• 機密性のために共通鍵暗号を使う
• 途中で改竄されないためにMACを使う
• リプレイ攻撃を防ぐために番号をつける
• 共通鍵暗号とMAC鍵を交換するために公開鍵暗号を使う
• 本人であることを確認するためにデジタル署名を使う
• このあたりの一連の流れをハンドシェイクという
プロトコル
11 / 27

12. • 現在安全かだけでなく、その情報をどれぐらいの期間
守りたいのかについても考えるべき
暗号強度
12 / 27

13. • 中間者攻撃（man in the middle attack）
• 通信会社と結託して通信機器を乗っ取る
• ARP spoofing
• 任意のIPアドレスをMACアドレスに結びつける
• WPAD hijacking
• HTTPプロキシの設定を取得するプロトコルに対する攻撃
• DNS hijacking
• ドメイン名を乗っ取る
• DNSの設定を変更する
• DNS cache poisoning
• DNSサーバのキャッシュの脆弱性にたいする攻撃
• BGP route hijacking
• ルータが利用する経路制御プロトコルにたいする攻撃
MITM
13 / 27

14. • 受動的攻撃
• 大規模期間による継続的なモニタリング
• FS
• （日和見暗号）
• 能動的な攻撃
• 不正な証明書を利用
受動的攻撃と能動的な攻撃
14 / 27

15. • TLS1.2についての解説 RFC5246参照
• TLS record = ヘッダ | メッセージデータ
• ヘッダ = contenttype | version | レコード長
• シーケンス番号
• 64ビット
• 送受信データには含まれない
• 通信の双方で保持
• リプレイ攻撃に対する防除
2章プロトコル
struct {
uint8 major;
uint8 minor;
} ProtocolVersion;
enum {
change_cipher_spec (20),
alert (21),
handshake (22),
application_data (23)
} ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length; / * 最長 2^14 （ 16,384 ） バイト * /
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
15 / 27

16. • ハンドシェイクの種類
• サーバ認証を行うフルハンドシェイク
• セッション再開のためのハンドシェイク
• クライアントとサーバの認証を伴うハンドシェイク
• フルハンドシェイク
• 接続で使いたいパラメータを双方が提示して合意する
• 鍵確立
• 提示された証明書の認証
• マスターシークレットの共有
• ハンドシェイクが書き換えられていないことの検証
handshakeプロトコル
16 / 27

17. • クライアントの認証はしない一般的なケース
p.27図2.2
サーバ認証を伴うフルハンドェイク
client server
ClientHello
ServerHello
Certificate
ServerHelloDone
ServerKeyExchange
ClientKeyExchange
[ChangeCipherSpec]
Finished
[ChangeCipherSpec]
Finished
17 / 27

18. • Certificate
• サーバの証明書を送信する
• ServerKeyExchange/ClientKeyExchange
• マスターシークレットの生成に必要な情報を送る
• ChangeCipherSpec
• 接続に必要な情報を全て手に入れて暗号鍵を生成したことを
相手に伝えるメッセージ
• 完全性検証の対象外
• 実装が難しいためOpenSSLでCCS injectio攻撃を受けた
• Finished
• ハンドシェイクのMACを送る（verify_data）
18 / 27

19. • p.32 図2.3
クライアント認証時のフルハンドシェイク
client server
ClientHello
ServerHello
Certificate
ServerHelloDone
ServerKeyExchange
ClientKeyExchange
[ChangeCipherSpec]
Finished
[ChangeCipherSpec]
Finished
CertificateRequest
Certificate
CertificateVerify
19 / 27

20. • CertificateRequest
• クライアントに対する認証の要求と許容できる証明書の種類
• CertificateVerify
• クライアント証明書に含まれる公開鍵に対応する署名
追加部分
20 / 27

21. • フルハンドシェイクは重たい処理
• 認証などを省略したい
• session resumption
• session IDを用いてセッションを再開する仕組み
• プロトコル
• クライアントがClientHelloにsession IDを含めて送信
• サーバは同じsession IDをServerHelloに含めて送信
• 以前共有したマスターシークレットを使って新しい鍵を生成
• ECDHE_ECDSA
• FSの実現のために利用
• 詳細は今まで解説したので省略
セッションリザンプション
21 / 27

22. • 以前Lucky13攻撃で紹介した図
• MAC(Seq|Header|data)計算してpaddingをつける
• IVを作ってEnc
• MAC-then-encrypt（MACしてから暗号化）
• pading oracleの攻撃（勉強会1, 2回目）
• Encrypt-then-MACという拡張（2014）
• AEAD（認証つき暗号）
• 64ビットのnonceを付与して暗号化（GCM/ChaCha20）
ブロック暗号を使った場合
Seq data
MAC(Seq|Header|data) padding
Enc(data|MAC|padding)
Header
ヘッダ IV
22 / 27

23. • 新しい接続のセキュリティパラメータの合意をえる
• クライアント証明書
• サイトの全接続に対してクライアント証明書を要求すると
• 証明書を持っていないと何も見えない
• エラーも分からない
• サイトのトップページはクライアント証明書なしを許可
• そこからクライアント証明書での接続に誘導
• このときに再ネゴシエーションを使う
• 情報の隠蔽
• 2回目のハンドシェイクが暗号化されるのでクライアント証明
書が覗かれない
• 暗号の強度変更
再ネゴシエーション
23 / 27

24. • 片方が通信を閉じたらclose_notifyを送信
• 相手は書き込み中の内容を破棄してclose_notifyを送信
• 強制切断攻撃（truncation attack）を防ぐ
• 攻撃者がやりとりを途中で横取りしてブロック
• 正しく実装する必要あり
Finished
24 / 27

25. • PRF（pseudorandom function）
• secret, seed, labelを入力としてHMACを使って構成する
• PRF(secret, label, seed) = P_hash(secret, label + seed)
• P_hash(secret, seed)
= H(secret, A(1) + seed) + H(secret, A(2) + seed) + ...
where A(1) = H(secret, seed), A(i) = H(secret, A(i – 1))
• マスターシークレット（Ms : master secret）
• Ms = PRF(pre_Ms, “master secret”, client_rand + server_rand)
• key_block = PRF(Ms, “key expansion”, server_rand +
client_rand)
• 鍵ブロックkey_blockを分割してMAC鍵や暗号鍵にする
• セッション再開時はMsは同じでclient_rand, server_randは新
しく取得する
擬似乱数生成器と鍵生成
25 / 27

26. • 暗号処理の方法を決めるパラメータの集まり
• TLS_鍵交換_認証_アルゴリズム_長さ_モード_MAC/PRF
• 例）TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• 2章残りの節
• ALPN ; application-layer protocol negotiation
• CT ; certificate transparency
• Heartbeat
• NPN ; nextprotocol negotiation
• 標準化にはならずALPNに移行
• OCSPステープル
• サーバからクライアントに証明書の失効情報を送る
暗号スイート
26 / 27

27. • TCPデータは暗号化されるがメタデータや下位のレイ
ヤは平文のまま
• 送信元と宛て先のIPアドレスは分かる
• 最初のハンドシェイクは平文
• ブラウザの各種情報を袖手する
• ホストの証明書を調査する
• クライアント証明書を使う場合のユーザ識別情報を収集
• メッセージの長さ
プロトコルの限界
27 / 27