Die lange Reise von RFC 4357 zu RFC 8645 oder die Verwaltung von Verschlüsselungsschlüsseln

Bild

Wie Sie wissen, ist die Schlüsselverwaltung eine der schwierigsten Aufgaben in der Kryptografie. Erst neulich wurde das Dokument „Re-Keying Mechanisms for Symmetric Keys“ als RFC 8645 veröffentlicht . Es ist das Ergebnis von zweieinhalb Jahren Arbeit der CFRG-Forschungsgruppe, die die Entwicklung und Verwendung der Kryptographie in der IETF bestimmt, und basiert auf langjähriger Forschung und der Erfahrung russischer Spezialisten. Als nächstes erklären wir kurz, was das Wesentliche dieses RFC ist und warum es sich als genau das herausstellte.

Ein bisschen Angst ...


2016 veröffentlichten zwei französische Forscher vom Inria-Institut eine Beschreibung des Sweet32- Angriffs. Die Idee, die sie verwendeten, ist obszön einfach und basiert auf dem sogenannten "Geburtstagsproblem" : Wenn wir die Werte einer zufälligen Zuordnung berechnen f:Vn rightarrowVndann in ungefähr 2n/2Tests in der resultierenden Reihenfolge stimmen mindestens zwei Werte überein. Aus kryptografischer Sicht bedeutet dies, dass eine Blockverschlüsselung mit einer Blocklänge vorliegt nBit kann nicht mehr auf einem Schlüssel verschlüsselt werden 2n/2Klartextblöcke.



Dieser Angriff auf Habré wurde bereits ausführlich betrachtet. Hier stellen wir nur fest, dass die Autoren die Tatsache ausgenutzt haben, dass einige weit verbreitete kryptografische Bibliotheken den Sitzungsschlüssel nicht rechtzeitig geändert haben. Dies ermöglichte es uns, viele Daten zu akkumulieren und einfach die angegebene Wahrscheinlichkeitseigenschaft zu verwenden, wenn die Verbindung eine Blockverschlüsselung mit einer Blocklänge von 64 Bit verwendete. Dies führte sofort zu einer ernsthaften Hysterie in der nahezu kryptografischen Umgebung hinsichtlich der Notwendigkeit einer dringenden Ablehnung solcher Chiffren.



Aber ist die Länge des Blocks?


Lohnt es sich, eine Chiffre zu verbannen, nur weil sie eine kurze Blocklänge hat: Was ist, wenn Sie den Schlüssel regelmäßig ändern? Dies kann mit der sogenannten Key Derivation Function ( KDF ) erfolgen. Mit solchen Funktionen können Sie neue Schlüssel basierend auf alten erhalten, während die Zufälligkeitseigenschaft von Schlüsseln erhalten bleibt (siehe z. B. diesen Artikel ). Solche Funktionen werden beispielsweise durch die russischen Normungsempfehlungen P 1323565.1.022-2018 und P 50.1.113-2016 bestimmt . Es gibt jedoch ein „Aber“: Dies sind recht komplexe und nicht sehr schnelle Konvertierungen, die auf Hash-Funktionen basieren und die Verschlüsselungsgeschwindigkeit erheblich verlangsamen.

Ist es möglich, etwas schneller zu machen?


Ein solcher Versuch wurde 2006 in RFC 4357 unternommen, wo der CryptoPro Key Meshing-Mechanismus vorgeschlagen wurde, der einen abgeleiteten Schlüssel erzeugt, indem eine feste Konstante mit einer Blockverschlüsselung in einem einfachen Ersetzungsmodus verschlüsselt wird.



Es war ein sehr schneller Algorithmus, der praktisch keinen Einfluss auf die Verschlüsselungsgeschwindigkeit hatte und vor so lächerlichen Situationen wie in Sweet32 und beispielsweise vor Angriffen auf Seitenkanäle schützte. Auf der Ruscrypto-Konferenz 2015 wurde jedoch gezeigt, dass eine solche Transformation die Leistung des Schlüsselsatzes verringert, d. H. Mit jedem neuen Schlüsselwechsel verringert sich die Anzahl der möglichen Schlüsselauswahloptionen. Der Autor stellte fest, dass dies keine wesentlichen Auswirkungen auf die Sicherheit hatte, es jedoch interessant wurde, ob dies noch besser gemacht werden könnte.



Es stellte sich nicht so einfach heraus


Leider gibt es keine Wunder, und es ist nicht möglich, einen schnellen Mechanismus anzubieten, der mit herkömmlichen KDFs vergleichbar ist. Wir können jedoch die Sicherheit mehrerer modifizierter Schemata wie des angegebenen Key Meshing für jeden spezifischen Verschlüsselungsmodus nachweisen. Es sind diese Mechanismen, die für den weit verbreiteten CTR-Gammamodus (CTR-ACPKM, Advance Cryptographic Prolongation of Key Material) und die Entwicklung eines OMAC-Simulationseinsatzes (OMAC-ACPKM) aus dem inländischen Standard GOST R 34.13-2015 vorgeschlagen und begründet wurden.

Sicherheitsbewertungen für diese Modi werden unter Verwendung der sogenannten Vorrichtung erhalten "Nachweisbare Haltbarkeit . "

Diese Modi wurden in Russland als Empfehlungen für die Standardisierung von R 1323565.1.017-2018 übernommen .

Diese Art der Arbeit mit Schlüsseln ermöglicht es Krypto-Tools, die die russischen TLS 1.2-Kryptosätze (definiert in den Standardisierungsempfehlungen R 1323565.1.020-2018 ) implementieren , die russischen kryptografischen Schutzanforderungen für hohe Klassen zu erfüllen.

Arbeit bei der IETF


Die entwickelten Mechanismen eignen sich perfekt als Antwort auf die am Anfang des Artikels erwähnte Diskussion darüber, ob es Chiffren mit einer kurzen Blocklänge geben sollte oder nicht.

Die Entwicklung des entsprechenden Dokuments, das später zu RFC 8645 wurde, wurde von den CFRG-Vorsitzenden Kenny Paterson und Alexei Melnikov von einer internationalen Expertengruppe unter der Leitung von Stanislav Smyshlyaev in Auftrag gegeben. Einen Beitrag zur Entwicklung des endgültigen Dokuments leisteten Evgeny Alekseev, Ekaterina Smyshlyaeva und Lilia Akhmetzyanova (CryptoPro), Shay Gueron (Universität Haifa), Daniel Fox Franke (Akamai Technologies) sowie der frühere Leiter der IETF, Russ House (Vigil Security); In verschiedenen Phasen schlossen sich so bedeutende Spezialisten wie Mihir Bellare (Universität von Kalifornien), Scott Fleurer (Cisco), Yoav Nir (Checkpoint), Dmitry Belyavsky (Cryptocom) und Paul Hoffman (ICANN) der Arbeit an.

Im Vergleich zu den russischen Empfehlungen wurden diesem RFC ACPKM-Mechanismen für Modi wie CBC, CFB und GCM hinzugefügt, für die, wie Sie wahrscheinlich bereits verstanden haben, separate Nachweise erforderlich waren .

Zusammenfassung


Wie bereits erwähnt, belohnen wir trotz der Tatsache, dass der vorgeschlagene Ansatz in gewisser Weise nicht universell ist und separate Sicherheitsbegründungen für jeden einzelnen Modus erfordert, hohe Geschwindigkeit, Sicherheit vor Angriffen wie Sweet32 und nicht zuletzt Angriffe von Seitenkanäle.

Source: https://habr.com/ru/post/de465527/


All Articles