k-tokitoh

SSHとかSSL/TLSとか

2024-05-06

だいぶややこしいな？と以前思って放置してたのを調べ直したのでざっくりした理解をメモする。比較的正確そうな情報を参考にしたが、仕様の確認や動作の検証などの裏とりはしておらず、不正確な恐れがある。

なお、以下はスコープ外とする。

  • 通信の詳細
  • 暗号化方式の種類と詳細
  • バージョンによる差異

何を実現するための技術か？

セキュリティの 3 要素は機密性/完全性/可用性。

SSH や SSL/TLS はこのうちの機密性/完全性に加えて、通信者の一方または双方の正当性の確認を行うための技術。

SSH

機密性/完全性

  • server/client それぞれで一時的なキーペアを発行する
  • それぞれ公開鍵を相手に渡す
  • 「A の公開鍵と B の秘密鍵」と「A の秘密鍵と B の公開鍵」から同一の情報が算出されるという数学的な性質によって、秘密情報が共有される(DH 法)
  • その秘密情報を共通鍵として以下を行う
    • 暗号化による機密性の確保
    • MAC(message authentication code)の付与による完全性の確保
  • 上記 2 点は AEAD(authenticated encryption with associated data)により同時に行われる

なぜ一時的なキーペアを利用するの？

一時的なキーペアを利用することで、AEAD に用いる共通鍵を一時的なものとして、漏洩時のリスクを抑えるため。

公開鍵の通信に介入した第三者が公開鍵を差し替えることで傍聴/改ざんされるリスクがあるのでは？

後述のユーザー認証において公開鍵の差し替えがバレる。

  • 本物の client が、「本物の client の秘密鍵」と「server の公開鍵」から導出されたセッション ID に対して署名を行う
  • 第三者はその署名つきデータを改ざんすることができない
  • server は「偽物の client の公開鍵」と「server の秘密鍵」から導出されたセッション ID を保持している
  • server は自身が保持するセッション ID と client から受信したセッション ID を比較し、両者が異なることに気づける

通信者の正当性

client の正当性 : ユーザー認証

パスワード認証方式や公開鍵認証方式などがある。以下では公開鍵認証方式について述べる。

  • client は予めキーペア X を発行し、公開鍵を server に登録する
  • client は鍵交換により共有した秘密情報から導出されたセッション ID に対して X の秘密鍵による署名を付与して server に送信する
  • server は登録された X の公開鍵により署名を検証して、client の正当性を確認する
  • server は client から受信したセッション ID が server の保持するそれと一致することを確認する

公開鍵による認証はパスワードによる認証よりも安全なの？

以下の点で yes.

client の正当性を担保するための機密情報に関して、

  • パスワード方式ではパスワードが client/server 双方から漏洩するリスクがある
  • 公開鍵方式では秘密鍵が client から漏洩するリスクしかない

なぜセッション ID に対して署名するの？

セッション ID 限りの署名とすることにより、署名が不正に流用されるリスクを抑えるため。

server の正当性 : ホスト認証

  • server は予めキーペア Y を発行する
  • server は Y の公開鍵と、Y の秘密鍵による署名を client に送信する
  • client は公開鍵により署名を検証する
  • 接続が初回の場合
    • server を信頼するか問われ、信頼する場合には公開鍵の fingerprint が client に登録される
    • (openSSH では~/.ssh/known_hostsに保存される)
  • 接続が 2 回目以降の場合
    • 受信した公開鍵と、client に登録された公開鍵が一致することを確認する
  • これにより、server が前回以前の接続時と同一の秘密鍵を保有していることが担保される
  • 実際の通信においては鍵交換と一体的に行われる

SSL/TLS

実現したいこととその方法は概ね SSH と同様。

ただし通信者の正当性については、SSH が「server を保護するための client の正当性確認に重点を置く」のに対して、SSL/TLS では「client を保護するための server の正当性確認のみ」である点が異なる。

client の正当性

SSL/TLS では対応しない。多くの場合アプリケーションのレイヤで実現される。

server の正当性

  • server の公開鍵を client が受け取って署名を検証する点は同じ
  • ただし公開鍵が正当な server により発行されたものであることを担保するために、第三者による証明を利用する
  • この第三者による証明には、CA(cerification authority)と呼ばれる機関がそれ自身の公開鍵によって署名した証明書を利用する
  • この証明書は X.509 という仕様に従う
  • 複数の CA が X.509 証明書を連鎖的に発行することで server の正当性を担保する仕組み全体を PKI(public key infrastructure)と呼ぶ

参考