web-dev-qa-db-ja.com

ECBおよびCBCの動作モードは一般的に安全ではありませんか？

Javaコードで、 Cipher.getInstance（...） メソッドに渡された次の暗号化アルゴリズムを偶然見つけました：

  • AES/CBC/PKCS5パディング
  • DESede/ECB/PKCS5Padding
  • RSA/ECB/PKCS1パディング

注：Java=モデルでは、最初のサブストリングは暗号、2番目は操作モード、3番目はパディング方式を表します。

プレーンテキストの構造を保持する であるため、ECBは一般に（使用される暗号化/パディングスキームとは無関係に）安全ではないと思います。

さらに、実装によってはCBCが安全でない可能性があることも読みました。より正確には、特定の暗号文が正しく埋め込まれたかどうかが明らかになるように実装が記述されている場合、 これは暗号化されたメッセージを復号化するために悪用される可能性があります 。 Javaの場合、問題は異なるプラットフォーム/ Java実装/暗号化プロバイダーが利用可能であるため、全般について動作モードとしてのCBCは問題ありません。

そのため、上記の3つのアルゴリズムはすべて安全でない可能性があると思います。しかし、おそらく私はECB/CBCの問題を過大評価しており、それらは安全な方法で使用できますか？

したがって、質問：上記のアルゴリズムを安全であると見なすことができるかどうか、またその理由は何ですか？

更新：さらにコンテキストを提供するために、私が参照しているコードは OWASPベンチマーク です。このベンチマークは何千ものテストケースで構成され、その一部は意図的に実際の脆弱性を含み、他は意図的に「偽の」脆弱性を含みます（つまり、脆弱であるように見えても実際には脆弱ではないコード）。 「偽の脆弱性」と分類されたテストケースの一部は、上記の3つのアルゴリズムのいずれかを使用してテキストを暗号化します。 OWASPはこれらを「偽の脆弱性」と見なしているため、OWASPがこれらのアルゴリズムを安全であると見なしていることを意味し、驚いた。これらのアルゴリズムを安全であると見なすのにOWASPが正しいのか、それともOWASPベンチマークのこれらのテストケースが「偽の脆弱性」ではなく「実際の脆弱性」としてラベル付けされるべきなのかと思います。

OWASPベンチマークでのこのような「偽の脆弱性」テストケースの例は テストケース54 で、AES/CBC/PKCS5Paddingを使用して一部のデータを暗号化しますが、 not 脆弱性がある to CWE 327：破損または危険な暗号化アルゴリズムの使用 。

encryptionaesjavarsacbc
3
Malte Skoruppa
  • DESede/ECB/PKCS5Padding
  • [〜＃〜] des [〜＃〜]はすでに壊れており、TDESが作成されて、新しい暗号が開発されるまで使用されます。
  • DESのブロックサイズまたはTDESは64ビットであり、これは安全ではありません。 Sweet32 を参照してください。

  • ECBモードブロック暗号の場合、それを忘れる。それも操作モードではありません。データのパターンを明らかにします。ウィキペディアのペンギンをご覧ください。 DBの等式クエリのように必要になる場合もありますが、それでも情報が漏洩する可能性があります。 周波数分析を最新の暗号に適用するにはどうすればよいですか？ を参照してください。

  • PKCS5Padding次のセクションを参照してください。

  • AES/CBC/PKCS5パディング

  • [〜＃〜] aes [〜＃〜]はブロック暗号であり、疑似ランダム置換と見なされます。 AESと組み合わせて適切な動作モードを使用することにより、AESを使用してIND-CPAまたはIND-CCAまたは認証された暗号化を実現できます。 20年以上経った今でも 安全

  • [〜＃〜] cbc [〜＃〜]モードにはIVが必要であり、IVは一意であるだけでなく npredictable でなければなりません

  • PKCS5Paddingは パディングOracle攻撃 に対して脆弱です。実際 Encrypt -than-MAC はこの問題を解決できます。

  • RSA/ECB/PKCS1パディング
  • [〜＃〜] rsa [〜＃〜]は暗号化を意味するものではありません。 PSSパディングを使用した署名、またはデータカプセル化メカニズムを備えたRSA-KEMのようなキーカプセル化メカニズムに使用できます。 KEMとDEMの構成により、IND-CCA2/NM-CCA2の標準が提供されます。AES-GCM、ChaCha20-Poly1305、またはcrypto_secretbox_xsalsa20poly1305
  • [〜＃〜] ecb [〜＃〜]はここでは意味がありません。 ECBを実装していません。ここではNoneの方が適しています。

  • ここでPKCS1Paddingは、RSAが暗号化のためにPKCS＃1 v1.5パディングを使用していることを示します。少なくとも8バイトあるため、このパディングは確率的になります。つまり、同じテキストを暗号化すると、異なる暗号文が得られます。

    RSA PKCS＃1 v1.5暗号化を安全に使用することは難しく、慣れてはいけません。 PKCS＃1 v1.5パディングには ブライチェンバッハーの攻撃 とその バリアント があります。また、セキュリティの証明はありませんが、ランダムOracleモデルでは 最適な非対称暗号化パディング （OAEP）が 証明済み 安全でした。暗号化する場合は、OAEPを使用する必要がありますが、使用しない方がよいでしょう。ハイブリッド暗号化を優先します。

短い結論

上記のモードのいずれも、今日は推奨されていません。 TLS 1.3では、認証された暗号化モードのみが使用できるようになりました。

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_AES_128_CCM_8_SHA256
  • TLS_AES_128_CCM_SHA256

CBC、gone 、TDESは不要、すべての静的RSAおよびDiffie-Hellmanスイートは 削除 です。

推奨事項に従ってください。現代の暗号化では、

  • IND-CCA2/NM-CCA2：適応選択暗号文攻撃下での暗号文の区別不可能性と非展性

したがって、認証された暗号化モードが必要です。

2
kelalaka

つまり、多くの場合、ECBモードは非常に安全ではなく、CBCモードだけでも多くの場合は補足できます（MAC）ため、安全になります。

ECBモードについて：平文はブロック単位で暗号化されるため、ブロックは互いに独立しています。その結果、同一の平文ブロックは同一の暗号文ブロックになります。したがって、同じブロックが存在する暗号文だけで識別できます。この弱点は、画像の暗号化で特にわかりやすいです（これを参照 例 ）。

CBCモードについて：サーバーアーキテクチャでは、プレーンテキストは、いわゆるパディングOracle攻撃を使用して正常に復号化できることがよくあります。これは実装によって異なります。 （参照： Wikipedia ）。
プレーンテキストについて想定している場合、別の攻撃（サーバーシナリオではない）は、暗号化されたテキストの標的を絞った操作です。たとえば、平文を「Pay Beloumi 100 $」とすると、関係者に操作を認識されなくても「Pay Beloumi 999 $」に変更できます。この弱点はMACを追加することで解消できますが、EAXやCCMなどの認証された暗号化モードをすぐに使用する方が簡単で、エラーが発生しにくくなります。

0
BeloumiX