Diese Seite stellt Euch die Spezifikationen und Parameter vor, welche bei den Beispielen rund um das Thema AES und symmetrischer Verschlüsselung zum Einsatz kommen.
Vorneweg möchte ich noch vier Begriffe erklären: „Plaintext“ bezeichnet den Klartext, d.h. die unverschlüsselten Daten. „Ciphertext“ ist das Ergebnis der Verschlüsselung, also die verschlüsselten Daten. Der „Decrypted text“ wird nach der Entschlüsselung ausgegeben, sollte also mit dem Klartext/Plaintext übereinstimmen. Bei der „symmetrischen Verschlüsselung“ wird zum Verschlüsseln und Entschlüsseln der gleiche Schlüssel eingesetzt. Informationen zur Ableitung des Schlüssels von einem Passwort („key derivation“, z.B. PBKDF2) findet Ihr weiter unten.
AES Algorithmus: Dieser Algorithmus ist das derzeit am häufigsten eingesetzte und erforschte Verfahren und kann – bei richtiger Implementierung – als sicher eingestuft werden. Der Schlüssel kann eine Länge von exakt 16 Bytes (AES-128), 24 Bytes (AES-192) oder 32 Bytes (AES-256) haben, meine Beispiele nutzen konsequent die längste (und damit sicherste) Variante von 32 Bytes.
Der Verschlüsselungsalgorithmus AES (Advanced Encryption Standard) kann in 8 verschiedenen Modi betrieben werden (ECB = electronic code book, CBC = cipher block chaining, CFB = cipher feedback, OFB = output feedback, CTR = counter, CCM = counter with cipher block chaining message authentication code, GCM = Galois/counter und EAX = encrypt then authenticate then translate).
In unseren Beispielen werden wir nur die beiden Modi CBC und GCM benutzen:
CBC Modus: Dieser Modus muss zwingend mit einem Initialisierungsvektor („IV“) initialisiert werden; dieser Wert ist exakt 16 Bytes lang und sollte mit einem Zufallswert belegt werden (und dieser sollte kryptographisch sicher erstellt worden sein). Der IV muss nicht geheimgehalten werden, sollte aber den verschlüsselten Text „begleiten“, denn nur mit dem „richtigen“ IV kann der verschlüsselte Text wieder vollständig entschlüsselt werden.
GCM Modus: Bei diesem Modus kommen zwei Parameter zum Einsatz: zum Einen der Nonce („number used only once“ = „Zahl die nur einmal verwendet wird) und zum Anderen der GCM Tag. Wie auch der IV beim CBC Modus sollte auch der Nonce zufällig erzeugt werden und es ist absolut wichtig, das beim gleichen Klartext niemals der gleiche Nonce verwendet wird, ansonsten kann ein Angreifer durch den Vergleich zweier Ciphertext den Schlüssel ermitteln. Die Länge des Nonce kann verschieden sein, die sicherste Variante ist allerdings 12 Byte (= 96 Bit) lang. Der GCM Modus wird als „Authenticated mode“ bezeichnet, was auf Deutsch „Verschlüsselung mit Schutz gegen Veränderung“ bedeutet. Dieser Schutz besteht aus einer Prüfsumme und diese Prüfsumme wird im GCM Tag gespeichert. Für eine erfolgreiche Entschlüsselung ist somit der gleiche Schlüssel, der gleiche Nonce und die berechnete Prüfsumme anzugeben.
Padding: Beim Thema Verschlüsselung werdet Ihr immer wieder über das Padding stolpern, welches soviel wie „auffüllen“ bedeutet. Da das AES-Verfahren mit einer Blocklänge von 16 Bytes arbeitet, wird u.a. beim CBC Modus immer ein kompletter Block von 16 Bytes verschlüsselt. Sollte der Klartext weniger als 16 Stellen (oder nicht exakt = ohne Rest teilbar) lang sein, muss der Klartext aufgefüllt werden, um durch 16 ohne Rest teilbar zu sein. Es gibt mehrere Verfahren hierfür, derzeit ist das PKCS5 bzw. PKCS7 Padding das übliche Padding (aus historischen Gründen hatte Oracle bei Java das Verfahren PKCS5 genannt, die übrigen Firmen nutzten PKCS7).
Welcher Modus ist sicherer ? Der GCM Modus bietet die zusätzliche Sicherheit gegen eine Veränderung des Ciphertextes (z.B. auf dem Transportweg). Allerdings geht die Errichtung der Prüfsumme mit einer deutlich langsameren Verschlüsselung (und Entschlüsselung) einher (der Faktor beträgt hier bis zu 1:10). Zweitens werden in manchen Systemen die gesamten verschlüsselten Daten im Speicher gehalten, was bei kleineren Smartphones und grossen Datenmengen zu einem Speicherüberlauf („out of memory error“) kommen kann.
Schlüssel Ableitung von einem Passwort („key derivation“): In der Vergangenheit wurde z.T. das eingegebene Passwort direkt in einen binären Wert übertragen (d.h. in Bytes decodiert) und für die Verschlüsselung benutzt. Eine andere gebräuchliche Variante errechnet von dem Passwort den MD5 oder SHA-1 Hashwert, aber allen diesen Verfahren ist eines gemeinsam: diese Verfahren sind unsicher.
Heutige Verfahren wie PBKDF2 oder Argon2 nutzen zwar auch einen Hash-Algorithmus, durchlaufen aber viele tausend Schleifen, benutzen viel Speicher und vor Allem sind sie zeitintensiv. Das bedeutet, das ein „Hacker“ beim durchtesten möglicher Passworte (z.B. mittels „bruce force“) sehr viel länger benötigt.
Parameter des PBKDF2 Algorithmus: Der „password based key derivation algorithm 2“ benötigt insgesamt 5 Eingangsparameter:
- passphrase: das eingegebene Passwort
- salt: ein Zufallswert der dafür sorgt, daß der erzeugte Passwort-Hash in jeder Runde unterschiedlich ist. Die Länge des salt sollte der Länge des erzeugten Passwortes entsprechen, in unserem Fall also 32 Byte bzw. 256 Bit lang sein. Auch der salt sollte kryptographisch sicher erzeugt werden.
- Hash Algorithmus: mit diesem Hash Algorithmus rechnet PBKDF2 intern, ich benutze in meinen Beispielen SHA-256.
- Iterations: Die Anzahl der Runden (Durchläufe) wird als Iterationen bezeichnet. Für die Sicherheit ist eine höhere Zahl besser, aber dauert insbesondere auf „schwachen“ Rechnern zu lang – hier hilft nur das Probieren. Ich benutzte 15.000 Iterationen in meinen Beispielen.
- Schlüssel Länge: gibt an, wie lang in Bytes bzw. Bits der erzeugte Schlüssel sein soll – für den Algorithmus AES-256 benötige ich also eine Ausgabe von 32 Bytes bzw. 256 Bit.
Hinweis: damit bei der Entschlüsselung aus dem Passwort der selbe Schlüssel generiert werden kann, ist der zufällig generierte salt zusammen mit dem Ciphertext an den Empfänger zu leiten.
Parameter des Argon2 Algorithmus: werde ich in Kürze nachreichen, sobald eine Beispiel-App diesen Algorithmus nutzt.
Letzte Bearbeitung dieser Seite: 10.12.2021