Ist diese Streaming-Kombination aus Verschlüsselung und MAC sicher?

  • Ich möchte Verschlüsselung und MAC kombinieren.

    Für die Verschlüsselung verwende ich AES-256 mit CBC und PKCS5Padding. Für MAC verwende ich HmacSHA512

    Ich verwende den Encrypt-Then-Mac-Ansatz (MAC über den Chiffretext berechnen und mit dem Chiffretext übermitteln)

    The Der Algorithmus sollte in der Lage sein, gestreamte Daten zu verarbeiten, und wenn ich den MAC einmal über den gesamten Chiffretext berechne, gibt es zwei Möglichkeiten:

    • mac zum Geheimtext:

      Dies ist eine sehr schlechte Idee, da der Verschlüsselungsteil den gesamten Text verschlüsseln muss, bevor er den Mac ausgeben kann. Daher ist es nicht streambar. Bei der Entschlüsselung müssen wir den gesamten Geheimtext verarbeiten, bevor wir wissen, ob er gefährdet ist (auch nicht vollständig streamfähig).

    • Hängen Sie den Mac an den Geheimtext:

      Bessere Idee, aber der Entschlüsselungsteil kann den MAC am Ende nur überprüfen. Zuvor gab es viele Bytes aus, die von einem Angreifer geändert worden sein könnten, oder es muss warten, bis der MAC angezeigt wird (nicht wieder streamfähig).

    Ich brauche also eine Lösung, die den Geheimtext in Teile unterteilt und dann für jedes Teil eine MAC berechnet. Da der Chiffretext nicht viel größer als der Klartext sein sollte, wähle ich eine MAC-Blockgröße, die größer als die Verschlüsselungsblockgröße ist (beispielsweise 4 KB).

    möchte ich Verwenden Sie ein Muster wie (mit $ c_X $ = Teil X des Chiffretextes, $ m_i $ = Teil X des MAC):

    $$ m_1 || IV || c_1 || m_2 || c_2 || m_3 || c_3 || \ dots $$

    Die Berechnung der ersten MAC ist eindeutig ($ k $ ist der MAC-Schlüssel):

    $$ m_1 = MAC (k, IV || c_1) $$

    Aber dann stoßen wir auf Probleme. Wenn wir einfach

    $$ m_X = MAC (k, c_X), $$

    verwenden, wäre dies nicht sicher. Ein Angreifer kann die Blöcke der Reihe nach ändern, er kann ganze Blöcke duplizieren oder entfernen usw.

    Ich habe mir also eine Idee überlegt, die dem CBC-Modus in der Verschlüsselung ähnelt:

    $$ m_X = MAC (k, m_ {X-1} || c_X) $$

    Ist th

    02 June 2012
    cmcculloh
1 answer
  • Es sieht so aus, als wäre Ihr Protokoll aus Integritätsgründen sicher, dh der Empfänger akzeptiert einen Stream nur, wenn er mit dem vom Sender gesendeten übereinstimmt (vorausgesetzt, der MAC ist nicht defekt).

    Wenn Ihre möglichen Angriffsszenarien jedoch einen (teilweise) gewählten Klartextangriff enthalten, ist der Einsatz von CBC schwach gegen den BEAST-ähnlichen Angriff auf den Geheimhaltungsabschnitt, der im Kommentar von CodeInChaos erwähnt wird.

    Damit CBC vor Angriffen im BEAST-Style durch gewählte Klartexte geschützt ist, ist es wichtig, dass der "effektive Initialisierungsvektor" jedes Blocks (dh der vorherige Block oder die IV des ersten Blocks) ist Block) wird nicht früher gesendet, als der Inhalt des Blocks festgelegt ist. Wenn Sie Ihren Stream in MAC-Block-Stücken senden (dh $ m_i || c_i $) und Sie ein solches vollständiges Stück senden, bevor der (Klartext) des ersten Blocks des nächsten Stücks bekannt ist, kann ein Angreifer beide den Chiffretext beobachten Wenn Sie diesen Klartextblock ausgewählt haben, können Sie hiermit Vermutungen über andere Teile des Chiffretextes überprüfen.

    In Ihrem Kontext der Dateiverschlüsselung ist die vollständige Datei wahrscheinlich beim Start bereits festgelegt verschlüsseln, daher ist dieser Angriff nicht möglich. Stellen Sie jedoch sicher, dass Sie diese Einschränkung beim Erstellen Ihres Programms dokumentieren. Verwenden Sie alternativ andere Modi wie die CTR anstelle von CBC, die gegenüber ausgewählten Klartextangriffen nicht schwach sind.

    02 June 2012
    cmcculloh