Rijndael (AES): Sichere Block- und Schlüsselgrößen

Nachdem mir die Frage gestellt wurde, warum ich im BLOG in einigen Beiträgen bestimmte Cipher empfohlen habe, möchte ich in diesem Beitrag auf die Bedeutung

  • der Blockgröße und
  • der Schlüssellänge

unter Berücksichtigung der bisher bekannt gewordenen Angriffsmöglichkeiten am Beispiel von Rijndael näher eingehen.

1 - Was ist die Blockgröße?

Die Blockgröße ist die Anzahl der Bytes, die, durch den Rijndael- Algorithmus, während eines Durchgangs verarbeitet werden können. Der Klartext wird hierbei durch einen Betriebsmodus wie CBC oder GCM in n Bit große Blöcke aufgeteilt und ggf. mit Hilfe von Padding- Verfahren aufgefüllt.

Blocksize bei CBC
Diese Darstellung verdeutlicht die Blocksize des Verschlüsselungsmode Cipher Block Chaining Mode (CBC) [1]

Der Rijndael- Algorithmus unterstützt verschiedene Blockgrößen (128, 160, 192, 224, und 256 Bits), im AES- Standard wird jedoch nur die 128-bit Blockgröße spezifiziert.

1.1 - Je größer die Blockgröße, desto besser?

Kommt drauf an. Für die Sicherheit einiger Betriebsmodi ist es erforderlich, dass keine zwei Cipher-Text Blöcke mit demselben Inhalt generiert werden.

Leicht verdeutlicht werden kann dies mit Hilfe des Code-Book Angriffs:

sei hierbei ein Klartextblock, der vorherige Cipher-Text Block und der Block Cipher.

Rijndael (AES): Sichere Block- und Schlüsselgrößen weiterlesen

Härtung eines OpenVPN Servers

Dieser Beitrag wurde am 23.April 2017 auf die OpenVPN-Version 2.4 aktualisiert, insbesondere Kapitel 4.1 bis 4.3.

OpenVPN ist ein beliebtes Tool, um verschlüsselte Netzwerkverbindungen herstellen zu können. Dieser BLOG Beitrag beschäftigt sich mit der Härtung des OpenVPN Servers und beschreibt alle Konfigurationsoptionen, die Auswirkungen auf die Sicherheit der OpenVPN Verbindung haben.

Das Verständnis dieses Artikels setzt voraus, dass die grundlegende Arbeitsweise von OpenVPN bekannt ist. Einige nachfolgend beschriebenen Optionen setzen mindestens die OpenVPN Version 2.3 voraus, ein Großteil der Konfigurationsoptionen funktioniert bereits ab OpenVPN Version 2.0.x.

Nicht näher beschrieben werden Optionen, die ausschließlich den "Static key mode" betreffen. Der Fokus liegt auf dem gebräuchlicheren, zertifikatebasiertem "TLS-negotiated key mode". Ausgelassen wurden ebenfalls pkcs11/ pkcs12 Optionen.

1 Allgemeine OpenVPN Grundlagen

OpenVPN Server und Client markiert

1.1 Basics: Control- vs. Data-Channel

OpenVPN stellt zwei unabhängige Datenverbindungen her: Einen Kontroll- und einen Datenkanal.

Der Kontroll- und Datenkanal einer OpenVPN Verbindung

Der Kontrollkanal hat unter anderem folgende Aufgaben:

  • den SSL/TLS Handshake (z.B. Session Start, Schlüsselaustausch, Authentifikation, Cipher-Suite Vereinbarung) durchführen,
  • einige Aufräumarbeiten in der finalen Phase der Verbindung zu realisieren und
  • bei der Nutzung von UDP die "Nachteile" der UDP Transport Layer Unzuverlässigkeit durch Einführung von Time-Out, Packet Acknowledgement und Transmission Mechanismen auszugleichen.

Härtung eines OpenVPN Servers weiterlesen

Häufige Schwachstellen in der Verschlüsselung durch Apps

Nachdem kurz nach der WhatsApp Übernahme die Suche nach und Diskussion über einen sicheren Messenger begann, möchte ich im Folgenden kurz auf die häufigsten Fehler aufmerksam machen, die App-Entwickler bei der Implementierung von Verschlüsselung zur Datenübertragung machen.

Schwachstelle 1: Die App nutzt einen gleichbleibenden, symmetrischen Schlüssel

Leider immer noch sehr häufig in Verwendung - gleichbleibendene, symmetrische Schlüssel.

symmetrische Verschlüsselung

Das Risiko liegt klar auf der Hand. Der Schlüssel muss im Client zu irgendeiner Zeit im Klartext vorliegen und kann ausgelesen werden. Ab diesem Punkt ist jede Verschlüsselung hinfällig - die Kommunikation jedes Clients kann entschlüsselt werden.

Häufige Schwachstellen in der Verschlüsselung durch Apps weiterlesen

Verschlüsselungsmodus im Detail / Empfehlung

Der heutige Beitrag ist eine Fortsetzung des Beitrags "Grundlagen der Verschlüsselung", es geht etwas mehr in die technischen Details: Der Verschlüsselungsmodus. Der letzte Beitrag dieses Blogs ist etwas länger her, leider habe ich momentan relativ wenig Zeit. Aktuell schreibe ich parallel einen Beitrag über die Absicherung des ngnix Webservers, beim Verfassen des Beitrags habe ich jedoch bemerkt, dass vielen die Relevanz der Auswahl des Verschlüsselungsmodus nicht bewusst ist.

Wird beispielsweise der im folgenden erklärte Electronic Codeblock Mode gemeinsam mit der Verschlüsselung AES in bestimmten Anwendungssituationen genutzt, kann die Verschlüsselung trotz sehr gutem Passwort vollkommen unsicher und leicht zu "knacken" sein.

Die symmetrische Verschlüsselung kann in zwei Grundtypen eingeteilt werden:

  • Blockchiffrierungen, hierbei wird der Klar- und der Chiffretext (das verschlüsselte Gegenstück zum Klartext) blockweise verarbeitet. Ein Block hat eine typische Größe von 64, 128, 192 oder auch 256 bit.
  • Stromchiffrierungen, hierbei wird der Text bitweise (manchmal auch byteweise) verarbeitet.

Der kryptographische Modus ist eine Art Erweiterung der Grundchiffrierung (AES, Serpent, Blowfish, ...) mit einer Rückkopplung und einigen einfachen mathematischen Operationen.

In vielen Anwendungen kann der Modus konfiguriert werden, im Artikel "TLS (SSL) Verschlüsselung und Schwachstellen im Detail" habe ich beispielsweise gezeigt, dass zu Beginn einer verschlüsselten Sitzung eine Cipher Suite ausgehandelt werden muss. Innerhalb der Suite wird auch die Verschlüsselung, die Blockgröße und der Modus festgelegt, z.B.:

  • AES_128_GCM (= Grundverschlüsselung AES, Keysize 128 bit und Modus GCM), oder
  • AES_128_CBC.

Auch in vielen Verschlüsselungs-Anwendungen wie OpenVPN oder OpenSSL basierten Programmen kann der Nutzer einen Algorithmus frei wählen. Zur Wahl des am Besten passenden ist jedoch einiges an Hintergrundwissen notwendig, welches ich im Folgenden vermitteln möchte.

Verschlüsselungsmodus im Detail / Empfehlung weiterlesen

Trusted Path Execution des Grsecurity Kernel Patches

Bevor wir uns im nächsten Beitrag mit der Installation, sicheren Konfiguration und Härtung eines Nginx-Servers befassen, möchte ich im Folgenden noch etwas Grundlagenarbeit erörtern: Die Funktionsweise der Trusted Path Execution unter Linux.

Die Trusted Path Execution sind als Teil des Grsecurity Patches während der Konfiguration optional aktivierbar.

Linux Menuconfig Security > Grsecurity > Executable Protections / Trusted Path Execution ausgewählt
Security Options -> Grsecurity -> Executable Protections

Funktionsweise der Trusted Path Execution

Die Ausführung von schädlichem Code auf einem Linux System, entweder durch einen externen Angreifer oder (un)gewollt durch einen lokalen Nutzer, ist eine der größten IT-Sicherheitsbedrohungen der heutigen Tage. Um diese Gefahr zu vermindern, ist Trusted Path Execution (TPE) ein weiterer Sicherheits-Layer, der die Ausführbarkeit von Dateien unter bestimmten Umständen einschränkt.

Die Nutzung von TPE erschwert beispielsweise den Versuch einer Privilege Escalation deutlich - wenn der Account mithilfe von TPE geschützt wird, ist es einem Angreifer nicht möglich, benutzerdefinierte Dateien auszuführen, die nicht in einem vertrauenswürdigem Pfad liegen. Im Rahmen vieler Angriffe versuchen Angreifer oftmals, nach dem Einbruch in das System Code nachzuladen und auszuführen, beispielsweise um eine lokale Sicherheitslücke auszunutzen.

Trusted Path Execution des Grsecurity Kernel Patches weiterlesen

Martin Witkowski zu Themen aus IT, Datenschutz & Sicherheit.