TLS 1.3はなぜAES-CBCを落としたのですか？
私はTLS 1.3に関するこのビデオを見ていました： " TLS 1.3の導入：素晴らしい、良い点、悪い点（33c3） "
「より少ない、より良い選択肢」
彼らはAES-CBCサポートされているブロック暗号モードとして。
ビデオには、いくつかの攻撃（Lucky13、POODLEなど）がリストされています。これらの攻撃は、訓練を受けていない人には実装の問題のようです。このような実装の問題を助長しないモードを使用する方が良いことは理解していますが、この暗号モード全体を非推奨にするために必要なことはすべてでしたか？
この本はいくらか日付が（2010）ですが、 Cryptography Engineering は、ランダムに生成されたIVを最良のオプションとして使用するAES-CBCを推奨しています。
ここでの問題はCBCではそれほど多くありませんが、数学的なセキュリティを失うことなく、安全に実装することがより簡単な代替手段があります。実際、AES-CBCは正しく実装することが非常に難しいことが判明しています。トランスポート層セキュリティの古い実装には暗号的に安全な初期化ベクトルがないことを思い出します。これはCBCモードに必須です。
最近の攻撃の多くは、オラクル攻撃を埋め込んでいます ブライチェンバッハー攻撃 など。これらは特に、サポートのために保持されている古いモードに依存しています。 POODLEはダウングレードの脆弱性です。 LOGJAMは、TLSを古い、エクスポートグレード（NSAでタグ付けされた読み取り）の暗号スイートにダウングレードしています。
CBCモードでは、Vaudenay攻撃があります。これらの攻撃は、サーバーが明示的に「無効なパディング」と言っているため、各トランザクションで1ビットの情報が漏洩します。エラーメッセージは削除されましたが、タイミングの問題は残りました。 パディングが有効である場合、サーバーは応答するまでにさらに多くの時間を使用しました。
それに応じて、彼らはダミーキーを生成し、それを復号化に使用して実装の別の部分で失敗するという独特の回避策を考え出すことを余儀なくされました。すべての実装で。したがって、仕様でサポートすることにより、開発者にそれを強制することはもうありません。
暗号化は非常に広い分野であり、それ自体が専門です。歴史は不愉快な経験を通して学んでいた、それを完全に行うことは、フィールドの最高のためにさえ、ほとんど保証されることは決してない。たとえば、RSAの共同発明者（および部品名）であるRon Rivestによって作成されたMD5は広く使用されていたが、2013年に壊れた。その衝突抵抗は2 ^ 18時間で回避され、128ビットハッシュのデスクトップコンピュータでは1秒未満でした。
CBCは、正しく実装されていれば暗号化に適したモードです。 1つの短い文で、私はCBCの2つの欠陥を指摘しました。
- CBCは暗号化モードのみです。機密性を提供しますが、信頼性や完全性は提供しません。データを個別に認証する必要があります。もちろんそれは可能であり、それがTLS 1.2より前にそれを行う唯一の方法でした。しかし 正しく理解するのは難しい であるため、 認証された暗号化モード をお勧めします。 TLS 1.3は、CBC + HMACの代わりに [〜＃〜] gcm [〜＃〜] をプッシュします。
- CBCを正しく実装するのは困難です。私がすでに述べたMACとそれを組み合わせる方法の問題があります。別の問題は パディングエラーによる情報のリークではない です。 IVは本当にランダムでなければなりません。敵対者 安全でない の影響を受けており、少なくとも [〜＃〜] beast [〜＃〜] であるIV。
正しく実装するのが非常に難しい場合は、プロトコルで許可しないことをお勧めします。暗号化の設計は、十分に研究された柔軟なプリミティブをいくつか持つことから、十分に研究された堅牢なプリミティブをいくつか持つようにゆっくりと移行しています。名目上は機能しますが、攻撃に陥ります。
基本的に、 Lucky13が発生しました で、結果は非常に悪かったです： Amazon s2nは修正したと思っていましたが、修正していないことがわかりました 。 OpenSSLは、修正しようとしたときにはるかに悪い脆弱性をもたらしました 。 GoogleのAdam Langley、おそらく世界で最高のTLS実装者 Go標準ライブラリのTLS実装に修正を実装しないことを選択し、心配されている場合はCBC暗号スイートをサポートしないことをお勧めします 。
TLS CBC暗号スイートの正しい実装は 非常に難しい です。
完全にパッチが適用され、安全であると考えられる実装は 攻撃のバリエーションが改善されると安全でないことが発見されます 。
人々は、上記の問題よりも多くの問題があることを知っていました。歴史が、悪いTLSの実装者が間違った新しい愚かなことを考えるときはいつでも（ナンスの繰り返しやMACの1バイトのみのチェックなど）、次のように書いているからです。この誤りを大規模にチェックできるスキャナーを使用すると、実際に正しく実行されず、実際にはFortune 500企業の多くで運用環境に展開されている実装が必ず見つかります。
この未発表の論文は、最新のラウンドのいくつかを伝えています： https://github.com/RUB-NDS/TLS-Padding-Oracles
小型のプレーヤー（cavium、citrix、F5、wolfSSL、mbedTLSなど）によるTLSの実装の適格性を知っている人は、それらを信頼して正しく実行できるとは言えません。パフォーマンスが高く、正しく実装するのがはるかに簡単な代替手段が存在するため、正しい方法はサポートを終了することです。
「なぜ」は、推測せずに答えることは常に困難です。暗号化の場合、未来への最良のガイドは過去の攻撃です。この特定のケースでは、欠陥のあるCBC実装が存在するだけでPOODLE攻撃が発生しました。
今では、パディングバイトスキームをテストする必要があることを誰もが知っていると思うかもしれませんが、これは単なる前提です。悲しいことに、余りに副作用がないことを確認せずに、期待した結果が得られたらテストを中止する人が多すぎます。
ここで、TLS 1.3の実装のコストを検討します。コードの記述は簡単です。しかし、開発者はバージョン、アルゴリズム、キー交換などの組み合わせの悪夢をテストする必要があります。また、攻撃者が予期しない斬新な方法で要素を組み合わせることにより、プロトコルを頻繁に悪用していることを知っています。彼らがスイートから捨てることができるものは何でもそれを研究し、それを桁違いにテストすることを簡単にします。
CBCは本当に非難するべきでしたか、それとも単に予期しないミスが脆弱性を生み出した道を導いたのですか？答えは、それが私たちに必要のない経路である場合、おそらくそれを完全に閉じ、攻撃対象を減らすことが最善です。
AES-CBCは今でも良いと思います適切に使用すれば。 TLSはmac-then-encryptを使用するため、複数の脆弱性を許す危険なフィールドです。現在のTLS実装には、（うまくいけば）安全に実装するための複数のハックが含まれています。たとえば、ピアが無効なパディングを検出した場合、MACチェックをしばらく後で中断するために、（おそらくxorを介して）データを破棄するだけです。タイミングで情報を漏らさないようにするために、エラータイプ（不良パディングまたはMACエラー）とエラーの位置に関係なく、プロセス全体で同じ時間がかかる必要があります。
CBCを削除することは、新しいプロトコルバージョン用にCBCを修正する方法の1つです。 encrypt-then-macを使用するのも1つの方法ですが、これはTLSの構造を変更するため、実装が困難になる可能性があります。プロトコル構造を変更すると、複数のTLSバージョンをサポートするコードで苦痛を伴う可能性があります。他にも適切なモードがあるため、プロトコル構造を変更するよりも、モードを切り替える方が簡単です。