4

暗号化にCTRモードでAES128暗号を使用し、さまざまなクライアント（Android/JavaおよびiOS/ObjC）に実装しています。パケットの暗号化に使用される16バイトのIVは、次のようにフォーマットされます。

<11 byte nonce> | <4 byte packet counter> | 0

パケットカウンタ（送信されたパケットに含まれる）は、送信されるパケットごとに1つずつ増加します。最後のバイトはブロックカウンターとして使用されるため、256ブロック未満のパケットは常に一意のカウンター値を取得します。CTRモードでは、ブロックごとにカウンターを1ずつ増やし、最後の8バイトをビッグエンディアンの方法でカウンターとして使用するように指定されているか、少なくともこれがデファクトスタンダードであると想定していました。これは、Sun暗号化の実装にも当てはまるようです。

対応するiOS実装（CommonCryptor、iOS 5.1を使用）がパケットをデコードするときの最初のブロックを除いてすべてのブロックをデコードできなかったとき、私は少し驚いた。CommonCryptorは他の方法でカウンターを定義しているようです。CommonCryptorは、ビッグエンディアンモードとリトルエンディアンモードの両方で作成できますが、CommonCryptorコードのあいまいなコメントは、これが完全にはサポートされていない（または少なくともサポートされていない）ことを示しています。

http://www.opensource.apple.com/source/CommonCrypto/CommonCrypto-60026/Source/API/CommonCryptor.c

/* corecrypto only implements CTR_BE.  No use of CTR_LE was found so we're marking
   this as unimplemented for now.  Also in Lion this was defined in reverse order.
   See <rdar://problem/10306112> */

ブロックごとにデコードすることにより、上記のようにIVを設定するたびに、うまく機能します。

私の質問：一度に複数のブロックをデコードするときにCTR / IVモードを実装する「正しい」方法はありますか、それとも異なる暗号ライブラリを使用するときに相互運用性の問題になると予想できますか？CommonCryptoはこの点でバグがありますか、それともCTRモードを別の方法で実装するだけの問題ですか？

4

2 に答える 2

4

カウンターの定義は、NIST勧告sp800-38a付録Bで（大まかに）指定されています。NISTは、セキュリティに関してCTRモードの使用方法のみを指定していることに注意してください。カウンタの1つの標準アルゴリズムを定義していません。

質問に直接答えるには、何をするにしても、カウンターが毎回1ずつ増えることを期待する必要があります。カウンタは、NIST仕様に従って128ビットのビッグエンディアン整数を表す必要があります。最下位（右端）のビットのみがインクリメントされる可能性がありますが、2^32-1または2^64-1の値を渡さない限り、通常は違いはありません。

互換性のために、最初の（左端の）12バイトをランダムナンスとして使用し、後者をゼロのままにしてから、CTRの実装に増分を実行させることができます。その場合、最初に96ビット/ 12バイトのランダムを使用するだけです。その場合、パケットカウンターは必要ありません。

ただし、カウンタが使用可能なすべてのビットを使い果たすまで、2 ^ 32*16バイトのプレーンテキストに制限されます。カウンターがゼロに戻る場合、またはナンス自体がカウンターに含まれる場合は実装固有であるため、68,719,476,736 =〜68 GBのメッセージに制限することをお勧めします（はい、10進数で、ギガは1,000,000,000を意味します）。

  • 誕生日の問題のため、ナンス（各ブロックではなく、各メッセージに必要）の衝突を作成する可能性が2 ^ 48（48 = 96/2 ）あるため、メッセージの量を制限する必要があります。
  • 攻撃者があなたをだまして同じナンスの2^32パケットを復号化すると、カウンターが不足します。

これがまだ互換性がない場合（テスト！）、最初の8バイトをナンスとして使用します。残念ながら、それは誕生日の問題のためにメッセージの数を制限する必要があることを意味します。

于 2012-09-21T14:16:59.270 に答える
3

さらなる調査により、CommonCryptoの問題にいくつかの光が当てられます。

iOS 6.0.1では、リトルエンディアンオプションが実装されていません。また、CCCryptorResetメソッドが実際にはIVを変更せず、代わりに既存のIVを使用するという点で、CommonCryptoにバグがあることを確認しました。6.0.1の動作は5.xとは異なります。

CommonCryptoをヌルのIVで初期化し、暗号化の直前に実際のIVにリセットすると、これは潜在的にセキュリティ上のリスクになります。これにより、すべてのデータが同じ（ヌルの）IVで暗号化され、複数のストリーム（おそらく、異なるIVを持つ必要がありますが、同じキーを使用します）は、対応するctrを持つパケットの単純なXORを介してデータをリークします。

于 2012-11-12T08:59:11.257 に答える