Upgrade to Pro — share decks privately, control downloads, hide ads and more …

TLS 1.3 で学ぶ暗号技術

TLS 1.3 で学ぶ暗号技術

2023/3/11 情報科学若手の会春の陣2023

松本直樹

March 11, 2023
Tweet

More Decks by 松本直樹

Other Decks in Technology

Transcript

  1. TLS 1.3 で学ぶ暗号技術
    2023/3/11 情報科学若手の会春の陣2023
    松本直樹(京都大学 情報学研究科)
    1

    View full-size slide

  2. 本発表のスコープ
    「研究発表」と言うより、「知見共有」な発表です
    • ICT に関連する研究やプログラムを開発する人
    • 通信の安全性が担保される仕組みを知りたい人
    • 暗号技術に興味はあるが、あまり詳しくない人
    「専門家向けではない、ゆるめ」の発表を目指しています
    2

    View full-size slide

  3. 前回までのあらすじ
    第 55 回情報科学若手の会(2022年9月) の LT より
    3

    View full-size slide

  4. ちなみに
    Zig の std に TLS 1.3 実装が生えました
    4

    View full-size slide

  5. TLS (Transport Layer Security)
    TLS (Transport Layer Security)
    • 通信における認証及び暗号化を提供するプロトコル
    → なりすましや、第三者が盗み見できない
    • HTTPS や QUIC において利用されている
    • TLS 1.3 (RFC 8446) が最新
    • TLS 1.2 はまだ使える
    • TLS 1.1 以前は脆弱性が存在するため利用してはならない
    5

    View full-size slide

  6. TLS 1.3 における通信の大まかな流れ
    お互いに鍵を交換→認証→ハンドシェイク完了→データ交換
    クライアント サーバー
    通信しましょう
    パラメータこんな感じで
    承知しました
    パラメータと
    正しいサーバーであること
    の証明を共に送ります
    正しいサーバーだね
    パラメタから鍵の生成した
    OKです!
    じゃ、通信開始で!
    暗号化したデータです
    (データを復号し)
    なるほど
    (データを復号し)
    へー
    暗号化したデータです
    6

    View full-size slide

  7. TLS 1.3 の詳細な特徴
    • ハンドシェイクの整理・機能追加
    • 通常ハンドシェイクにおけるメッセージ往復回数の削減
    TLS 1.2 まで → 2往復、 TLS 1.3 → 1.5 往復
    • セッション再開ハンドシェイクの整理
    • 0-RTT ハンドシェイクの追加
    • 利用できる暗号スキーマの整理
    • 危殆化した暗号スキーマの廃止(RC4, MD5等)
    • 楕円曲線暗号や認証付き暗号(AES-GCM 等)の利用が標準となる
    • 前方秘匿性(PFS) を担保する鍵交換のみサポート
    ※PFS: ある時点で鍵交換における秘密鍵の情報の漏洩が生じても、それ以前の暗号化されたデータは復号できない
    こと
    • 安全性自体が形式的に検証された有名なプロトコルとしては初めて
    7

    View full-size slide

  8. つまり?
    TLS 1.3 の直接的な嬉しさ
    • ハンドシェイクに必要なメッセージ往復回数の削減
    → TLS のハンドシェイクに要する時間が短くなる = UX の改善
    • 利用されるアルゴリズムの整理
    → 危殆化したアルゴリズムは含まれないため、より安全に
    • PFS のサポート
    → 秘密鍵漏洩時の被害を最小限にできるため、より安全に
    8

    View full-size slide

  9. 利用される暗号技術
    • 鍵交換アルゴリズム
    • TLSセッションで利用される鍵の交換に利用するアルゴリズム
    • TLS 1.3 ではDiffie-Hellmanを利用する(=PFSを実現)
    • 署名アルゴリズム(デジタル署名)
    • メッセージの真正性を検証するためのアルゴリズム
    • TLS 1.3 では楕円曲線やRSA暗号による署名を用いる
    • 暗号化アルゴリズム
    • アプリケーションのデータを暗号化するアルゴリズム
    • TLS1.3 では改ざんを検出できる認証付き暗号(AEAD)を利用
    9

    View full-size slide

  10. 前方秘匿性(Perfect Forward Secrecy)
    前方秘匿性:暗号化鍵の共有に使われている秘密鍵が漏えいしたとしても、
    過去に暗号化された通信データは解読されないことを指す
    → 漏洩前までのデータは将来にわたって機密性が守られる
    セッション
    #1
    セッション
    #2
    セッション
    #N
    セッション
    #N+1
    ・・・
    セッション
    #N+2
    漏洩!
    漏洩した情報ではデータを復号できない 漏洩した通信は影響を受ける
    10

    View full-size slide

  11. 鍵交換アルゴリズム
    暗号化に利用する共通鍵を交換するアルゴリズム
    → 第三者にはバレないように2者間で共通鍵を共有する
    TLS 1.3 では Diffie-Hellman 鍵共有アルゴリズムを用いる
    クライアント サーバー
    暗号化に共通鍵が必要
    暗号化されたデータ
    暗号化されたデータ

    何かしらの方法で鍵を
    共有する必要がある
    11

    View full-size slide

  12. Diffie-Hellman(DH) による鍵の交換
    Diffie-Hellman: 2者間で鍵自体を共有することなく鍵を共有する手法
    • 𝑔𝑎 𝑚𝑜𝑑 𝑝から 𝑎 を求めることは困難である(離散対数問題)
    • 中間者攻撃には脆弱であり、認証を行う仕組みが必要
    12
    Alice Bob
    公開パラメータ: g, p(素数) を共有
    秘密鍵: a 秘密鍵: b
    𝑔𝑎 𝑚𝑜𝑑 𝑝
    𝑔𝑏 𝑚𝑜𝑑 𝑝
    𝑔𝑎𝑏 𝑚𝑜𝑑 𝑝 𝑔𝑎𝑏 𝑚𝑜𝑑 𝑝
    𝑔𝑎𝑏 𝑚𝑜𝑑 𝑝が共有される

    View full-size slide

  13. DH だと何が嬉しい?
    • 別の秘密鍵を利用することなく鍵を共有できる
    • 盗聴する第三者は共有された鍵を得ることが困難である
    → PFS を担保できる
    • 中間者攻撃に対しては脆弱 → 正しい相手であるか検証する必要がある
    Alice Bob
    秘密鍵: a 秘密鍵: b
    𝑔𝑎 𝑚𝑜𝑑 𝑝
    𝑔𝑒 𝑚𝑜𝑑 𝑝
    𝑔𝑎𝑒 𝑚𝑜𝑑 𝑝 𝑔𝑏𝑒 𝑚𝑜𝑑 𝑝
    𝑔𝑎𝑒 𝑚𝑜𝑑 𝑝が共有される
    Mallory
    𝑔𝑏 𝑚𝑜𝑑 𝑝
    𝑔𝑒 𝑚𝑜𝑑 𝑝
    𝑔𝑏𝑒 𝑚𝑜𝑑 𝑝が共有される
    e で書き換え
    13

    View full-size slide

  14. 署名アルゴリズム(デジタル署名)
    送信されたメッセージが確かに本人によるものであることを保証する
    → なりすましや第三者による改ざんを検知できる
    DH と組み合わせて、共有された鍵が本人によるものであることを確認する
    Alice Bob
    メッセージ + 署名
    自分の秘密鍵で
    メッセージを署名
    Bob の公開鍵で検証
    検証 OK ! 改ざんされたメッセージ + 署名
    Mallory
    Bob の公開鍵で検証
    検証 失敗
    → Bobじゃないな?
    14

    View full-size slide

  15. RSA暗号による署名(RFC 8017)
    公開鍵暗号である RSA暗号を用いたデジタル署名が有名 (注: 署名 ≠ 暗号化)
    • 署名手法にはいくつかあり、RSASSA-PKCS1-v1_5 を取り上げる
    メッセージ
    暗号学的
    ハッシュ関数
    エンコード 𝑥: 入力, 𝑦: 出力
    𝑦 = 𝑥𝑑 𝑚𝑜𝑑 𝑛
    𝑑: 秘密鍵, 𝑒: 公開鍵, 𝑛: 法 (𝑒 と 𝑛 は公開) とする
    署名
    署名
    EMSA-PKCS1-V1_5-ENCODE RSASP1
    検証
    𝑥: 入力, 𝑦: 出力
    𝑦 = 𝑥𝑒 𝑚𝑜𝑑 𝑛
    RSAVP1
    メッセージ
    暗号学的
    ハッシュ関数
    エンコード
    EMSA-PKCS1-V1_5-ENCODE
    署名
    一致すれば
    検証成功
    15

    View full-size slide

  16. 公開鍵基盤(PKI)
    署名の検証には相手の公開鍵(と n)が必要
    → 本人の正しい公開鍵を手に入れるにはどうすればよいのか?
    公開鍵基盤(Public Key Infrastructure): 正しい公開鍵であることを担保する基盤
    • 署名の検証に必要な情報一式を「証明書」として配布
    • 「認証局(CA)」が証明書に署名する
    • CA の証明書はさらに上位のCAにより署名される(最上位のCAはルートCAと呼ばれる)
    サーバー証明書
    認証局
    発行
    自分の秘密鍵で
    証明書を署名 16

    View full-size slide

  17. 公開鍵基盤(PKI)
    認証局の正しさはどうやって検証するのか?
    → さらに上位の認証局が認証局の証明書を署名する
    最上位の認証局(ルートCA)の証明書を
    各クライアントに配布する
    署名して発行
    署名して発行
    自分で署名(自己署名)
    各クライアントに配布
    中間CA
    ルートCA
    証明書
    17

    View full-size slide

  18. 暗号化アルゴリズム
    データを暗号化し、機密性を担保するアルゴリズム
    • AES 等のいわゆる共通鍵暗号
    TLS 1.3 では復号結果の正しさを保証する認証付き暗号を用いる
    クライアント サーバー
    この部分
    暗号化されたデータ
    暗号化されたデータ
    DHによる鍵交換
    デジタル署名を用いた認証
    18

    View full-size slide

  19. 認証付き暗号(AEAD)
    Authenticated Encryption with Associated Data(AEAD)
    • データの機密性と完全性(正しさ)を担保する
    • 普通の共通鍵暗号では、復号結果が正しいか判断できない
    • 復号時に認証を行い、失敗すると復号失敗とする
    cipher, tag = AEAD_Enc(plain, ad, key, nonce)
    tag: 認証用のタグ, ad: 暗号化はされないが認証はされるデータ
    plain = AEAD_Dec(cipher, tag, ad, key, nonce)
    • TLS 1.3 では AES-GCM と Chacha20-Poly1305 が主に利用される
    19

    View full-size slide

  20. まとめ
    TLS 1.3 には以下の暗号技術が用いられている
    • 鍵交換アルゴリズム: 鍵の安全な共有
    • 署名アルゴリズム: データの真正性の担保
    • 暗号化アルゴリズム: データの機密性の担保
    複数の暗号技術を組み合わせることで安全性を担保
    それぞれの「何を保証できるのか/できないのか」の理解が重要
    20

    View full-size slide