パスワードを忘れた? アカウント作成
13479416 journal
日記

dodaの日記: SSH での AES-GCM の利用 2

日記 by doda

一つ前の日記で、SSH 接続での AES-GCM の利用を勧めましたが、一部では AES-GCM は危険だと誤解している人がいるみたいなので、
少なくとも SSH での AES-GCM の利用は安全だという事を書いてみようと思います。

AES-GCM が危険だという誤解は、どうも『本当は怖いAES-GCMの話』というページの影響を受けているように思います。
この『本当は怖いAES-GCMの話』に書かれている内容自体には問題は有りません。
# タイトルが AES-GCM 全般が危険なように思わせる物になっているのは気に入りませんが
しかし、『本当は怖いAES-GCMの話』は殆どが TLS 1.2 での AES-GCM の利用について書かれており、
AES-GCM 全般、特に SSH での AES-GCM にはそのまま当て嵌められません。

数学的に安全が保証されているGCMですが、それはGCMが使うIV(初期ベクトル)が再利用されないこと、
すなわちIVがNonce(Number used once)であることが大前提となっています。この前提が崩れると
AES-GCMの安全性は大きく損なわれます。

この部分は GCM 全般について書かれています。GCM で IV (Nonce) が再利用された場合は安全性が大きく崩れるのは事実です。
しかし、これは GCM に限った話ではなく、他の (IV を使う) 暗号方式でも IV を再利用した場合は同様に安全性が損なわれます。
その為、GCM の利用時に限らず IV (Nonce) は再利用する事が無いように決める必要があります。

今回の調査で、幸いこの脆弱性の影響を受けるのは一部実装に限られており、(素のままの)OpenSSLは問題ありません。

この AES-GCM の IV 再利用の問題は、一部の実装の問題であり、正しく AES-GCM を使えば問題は無いという事ですね。
ただ、実装によっては AES-GCM で IV が再利用するがあるというのは、そのような状況が起こりえるようになっている
TLS 1.2 のプロトコルの問題とも言えます。SSH での状況については後述します。

TLSで暗号化されたデータの頭に明示的に8バイト分のIVが付与されています。当然この部分は暗号化されていないので攻撃者
からはHTTPSサーバがどのようなIVを使っているのか丸見えです。

IV 自体は(正しく運用されていれば)外部に見えても問題は有りません。しかし、IV が再利用された場合にそれを外部から
簡単に検出出来る事になるので、IV が外部に見えるという事が攻撃を行い易くしたというのは有ると思います。
SSH では通信内容には IV は含まれません。

さらなる調査結果から、7万以上のサーバが乱数を使って初期ベクトルを毎回生成しているのがわかりました。
この方式では、大量のデータの通信を行うと過去使った乱数値と同じ乱数を生成してしまう確率が格段に上昇します。

これは TLS 1.2 の AES-GCM では IV の生成方法が決まっていなかった為、大量の通信が行われる状況では問題が
発生する方法を取った実装があったという事ですね。
SSH では IV の生成方法が決まっており、実装によって問題が発生するような決め方をする事は出来ません。

乱数でNonceを生成するには時代的にもう合わなくなってきました。そのため他の実装では、通常IVにカウンター値を利用します
(Nonceは再利用されなければ予測可能であっても構わない)。この場合、IVは2^64まで一意に生成できるのでまぁ大丈夫でしょう。
OpenSSLでは一番最初の値を乱数で決め、それ以降はカウンターとしてインクリメントしていく実装になっています。

SSH での IV の生成方法は、この OpenSSL での方法に近いです。
初期値は鍵交換の結果から計算で生成され、それ以降はカウンターとしてインクリメントしていきます。
プロトコルとしてこのように決まっている為、他の方法が使えない(使おうとすると通信が行えない)ようになっています。
またカウンターが一周するはるか前に鍵の再交換によって別の鍵での通信になる為、一周して同じ値になっても問題は発生しません。
# 実際には鍵の再交換によって新しい IV の初期値が使われるようになるので、IV が一周する事は無いでしょう

このように、SSH の AES-GCM では IV が再利用される事がないような方法を使う事がプロトコルで決められているので、
特定の実装の問題を気にする事もなく安心して AES-GCM を利用する事が出来ます。

  • by Anonymous Coward on 2017年12月14日 9時57分 (#3329472)

    なにやら「AES-GCMは危険だと誤解している人がいる」とミスリードさせたがっているようだが
    AES-GCMは危険が危ないからどうたら、という話ではなく
    登場早々、なにやら早速ケチがつき始めているようなので、aes256-gcm@openssh.comすっ飛ばして
    一気にchacha20-poly1305@openssh.com行こうずって人が多いだけの話だろ
    TeraTermがChaCha20未対応で、未だ有志パッチすら存在しないからといって
    いくらAES-GCMの安全性を叫んで布教に励んだところで、問題の本質はそこではないのでその流れも変わらない

    ここに返信
    • > AES-GCMは危険が危ないからどうたら、という話ではなく

      このIVの再利用の話を挙げてSSHで使用する暗号方式からAES-GCMを外している人が居たので、実際に危険だと誤解している人はいるようですよ。

      > 登場早々、なにやら早速ケチがつき始めているようなので、

      これが誤解だという話をしています。
      問題の本質は「TLS 1.2の特定の実装でIVを再利用する場合がある」という事で、
      AES-GCMの安全性に問題が見つかったという話ではないので。

      > 一気にchacha20-poly1305@openssh.com行こうずって人が多いだけの話だろ

      chacha20-poly1305はこの話には関係ないのですが。
      AES-GCMよりchacha20-poly1305を優先して使おうというのならば特に問題はありませんが、
      誤解が元でAES-GCMを使わないように設定して、その結果、より劣る方式を使ってしまうのは
      本末転倒なので避けた方がいいよという事で書いています。
      # EtMなMACが使えるのならば AES-CTR + EtM MAC というのもいい選択肢だとは思います

      > TeraTermがChaCha20未対応で、未だ有志パッチすら存在しないからといって

      Tera Termでは次のバージョンでchacha20-poly1305をサポートする予定ですが、
      たとえ現時点でサポートしていてもこの話は書いていました。
      せっかく安定した複数の方式があるのに、誤解が原因で選択肢を狭めるのは問題だと思いますので。

typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

読み込み中...