W2026-ITS

Organisatorisches und Anmeldung für IT-Security Workshop vom 28. September bis 9. Oktober 2026

Wenn Sie die unten genannten Themen interessant finden und in den ersten beiden Oktoberwochen Lust und Zeit haben sich damit auseinanderzusetzen, so finden Sie hier den angestrebten Zeitplan sowie die Möglichkeit sich und (optional) ein spannendes eigenes Thema anzumelden. Exklusiv für die Kommunikation der Teilnehmenden untereinander gibt es einen zugehörigen Moodle-Kurs mit Forum.

Themen (DRAFT)

PQC@OpenVPN

OpenVPN ist eine weit verbreitete Open-Source-Lösung für sichere, verschlüsselte VPNs. OpenVPN ist (anders als WireGuard) hinsichtlich vieler Aspekte konfigurierbar und bietet zahlreiche Optionen. Hier sind also bei der Administration einige Überlegungen nötig, um sichere und auch performante Einstellungen zu wählen. Hinsichtlich der Performance ist OpenVPN im Verbindungsaufbau und oft auch im Transport der eigentlichen Nutzdaten oft langsamer als WireGuard. Der Verbindungsaufbau ist in WireGuard sehr strikt spezifiziert und dadurch effizient. Dies bedeutet aber auch, dass ein Austausch der Kryptoalgorithmen in WireGuard nicht einfach möglich ist. Hier bietet OpenVPN mehr Kryptoagilität, auch wenn dies intrinsisch mit mehr Komplexität somit einer höheren Zahl an Roundtrips zum Verbindungsaufbau bezahlt wird. Häufig wird für den Aufbau des Kontrollkanals TLS verwendet, so dass zur Absicherung gegen Quantencomputer auf die ab OpenSSL >= 3.5 vorhandenen Mechanismen zurückgegriffen werden soll. OpenVPN unterstützt (derzeit bereits oder zukünftig) drei Mechanismen zur Quantensicherheit:

1. "poor man's post-quantum cryptography" in Gestalt von preshared symmetrischen Schlüsseln mit den Optionen tls-crypt, tls-crypt-v2, auf deren Basis dann die TLS-Schlüsselaushandlung ihrerseits verschlüsselt wird (in Version 2 mit nutzerindividuellen Schlüsseln). Dieser Mechanismus ist aber nicht vorwärtssicher unter dem Angreifermodell "Quantencomputer",
2. Die stärkere und wünschenswertere Methode ist die Nutzung eines hybriden Verfahren mit PQC, die dann "Perfect Forward Secrecy" garantiert. Da OpenVPN in der Regel OpenSSL als TLS-Bibliothek verwendet (siehe W2025-ITS#PQC@TLS-Handshake-Thema), sind dann X25519MLKEM768, SecP256r1MLKEM768 und SecP384r1MLKEM1024 denkbare Kandidaten, die dann mit tls-groups X25519MLKEM768 konfigurierbar sein sollen.
3. Auch eine auf PQC-basierende Authentisierung sowohl des Servers als auch der Clients in Gestalt von "Post-quantum signing/certificates" soll zukünftig möglich sein. Da aber in der Gegenwart noch keine Quantencomputer vorhanden sind die die klassischen Signaturen brechen können und eine Authentisierung nicht rückwirkend erfolgt, ist hier eher die Möglichkeit interessant, aber der Handlungsdruck nicht so immens wie bei dem Schutz der Vertraulichkeit.

Der eigentliche Transport der Nutzdaten erfolgt über den "data channel". Dieser nutzt symmetrische Kryptografie zur Verschlüsselung und Authentisierung. Wenn die Schlüsselübereinkunft quantensicher erfolgt und ausreichend starke (>= 256bit) Schlüssel genutzt werden, so ist der Datenkanal auch quantensicher. Hierbei sind sicher die AEAD-Chiffren CHACHA20-POLY1305 und AES-256-GCM eine solide Wahl. Während CHACHA20-POLY1305 in der Regel recht performant in Software umgesetzt werden kann und insbesondere gern auf ARM-Architekturen verwendet wird, kann AES-256-GCM seine Vorteile ausspielen, wenn AES hardwareunterstützt (z.B. durch die CPU) ist. WireGuard verwendet CHACHA20-POLY1305 für die Verschlüsselung der Nutzdaten, ist direkt im Kernel implementiert und bietet hervorragende Performance. Um hier etwas aufzuholen, hat OpenVPN das Konzept "Data Channel Offload (DCO)" an den Start gebracht, ein Kernelmodul bereitgestellt, das die Ver- und Entschlüsselung der Datenpakete direkt im Kernel-Space ermöglicht. Von dem DCO-Kernel-Modul werden CHACHA20-POLY1305 und AES-{128,256}-GCM als Chiffren unterstützt. Versuchen Sie, für Ihren OpenVPN-{Server,Clienten} auch DCO zu verwenden und messen Sie den Performanceunterschied. Untersuchen Sie auch, ob auch mobile "OpenVPN Connect"-Clienten unterstützt werden und wie man eine ggf. nötige starke abwärtskompatible Konfiguration erreichen kann.

Links:

• OpenVPN 2.7.6
• PQC & OpenVPN
• OpenVPN Data Channel Offload (DCO)
• OpenVPN Connect – OpenVPN App

Mentoren: Wolf Müller

PQC@eduroam

Eduroam gestattet Mitarbeitenden an Bildungs- und Forschungseinrichtungen Zugang zu WLAN-Netzen der besuchten Einrichtungen und hat sich als ausgesprochen praktisch erwiesen. Um sich gegenüber dem besuchten Netzwerk als Nutzer zu authentisieren, wird in der Regel der WPA2 oder WPA3-Enterprise Mode verwendet. Insbesondere erfolgt die Authentisierung via EAP-TTLS gegenüber der Heimeinrichtung. Auch für diese Verbindung wäre ein quantensicherer Schlüsselaustausch wünschenswert. Schauen Sie sich an, auf welche Stellen man achten müsste, um WPA3-Enterprise quantensicher zu bekommen. Bauen Sie ein eigenes WPA3-Enterpreise-Netzwerk auf und sichern Sie es möglichst gut gegen Angriffe mit Quantencomputern ab. Orientieren Sie sich dabei an der Architektur von Eduroam an der HU, also nutzen Sie EAP-TTLS mit passwortbasierter Authentifizierung und FreeRADIUS. Inspizieren Sie Ihren Ansatz mit Wireshark.

Links:

• eduroam
• EAP-TTLS@HU
• WPA3 Specification
• Ausblick PQC, WPA4
• FreeRADIUS
• Wireshark
• Wireshark: IEEE 802.11 WLAN Decryption Keys

Mentoren: Wolf Müller

OpenVPN-DCO@{OPNsense,pfSense 2.9.0 CE}

Mit dem gerade frisch veröffentlichten pfSense 2.9.0 CE und OPNsense stehen hier zwei weit verbreitete Kandidaten für frei verfügbare auf FreeBSD-basierende Firewalllösungen mit Webkonfigurationsmöglichkeit zur Auswahl, die auch DHCP, DNS und VPN-Lösungen unterstützen. An unserem Institut fand schon an einigen Stellen pfSense Anwendung. Allerdings bietet hier die CE (also community edition) keine Unterstützung für OpenVPN mit "data channel offload" in den Kernel, so dass die Effizienz nicht so gut ist, wie sie sein könnte. Konkret ist bei pfSense das nötige Kernelmodul /boot/modules/if_ovpn.ko nicht vorhanden. Um hier (ohne zusätzliche Kosten) weiterzukommen sehe ich die folgenden Möglichkeiten:

1. Man versucht zum installierten Kernel FreeBSD 16.0-CURRENT #12 RELENG_2_9_0-n256132-d8e3138ecf52 aus den FreeBSD-Quellen ein passendes Modul selbst zu kompilieren. Allerdings ist nicht gleich offensichtlich, aus welchen Quellen das wie gelingen könnte. (Das installierte OpenVPN: OpenVPN 2.7.5 amd64-portbld-freebsd16.0 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] [DCO] scheint bereits mit DCO-Unterstützung kompiliert zu sein. Auch ist OpenSSL: OpenSSL 3.5.7 9 Jun 2026 (Library: OpenSSL 3.5.7 9 Jun 2026) ausreichend aktuell, um auch einen quantensicheren Handshake zu realisieren.)
2. Man versucht auf die vor geraumer Zeit geforkte OPNsense Variante zu wechseln und dort OpenVPN mit DCO umzusetzen.
3. Man könnte auf WireGuard wechseln, welches in beiden *sense Varianten inzwischen konfigurierbar ist.

Schauen Sie sich die verschiedenen Ansätze an und stellen Sie diese gegenüber. Vielleicht haben Sie auch andere Ideen? Lassen Sie uns an Ihrem gewonnen Wissen teilhaben!

Links:

• pfSense CE 2.9.0
• OPNsense 26.7
• if_ovpn FreeBSD
• example for bulding in pfsense

Mentoren: Wolf Müller

Krypto-Inventarisierung für TLS

Gegenstand vorangegangener Themen war oft eine Konfiguration quantensicherer Verfahren (zumindest für den genutzten vorwärtssicheren Schlüsselaustausch). Bei der Konfiguration von neu aufgesetzten Systemen ist es sicherlich zielführend mit einer engen und starken Konfiguration zu starten. Doch wie verhält es sich mit Diensten die bereits laufen und einer breiten Benutzerbasis angeboten werden? Es wäre also gut zu wissen, welche Dienste durch Server in der eigenen Infrastruktur angeboten werden und welche Kryptoprimitiven in der aktuellen Konfiguration nutzbar sind. Hier ist ein erster Anlaufpunkt, der Webservice ssltest, der jedoch einige Einschränkungen hat. Detailliertere und vertraulichere Analysen können durch die Verwendung von testssl.sh gewonnen werden, welche auch die Analyse von Protokollen wie SMTP, POP3, IMAP, XMPP, IRC, LDAP, PostgreSQL, MySQL, NNTP, FTP... gestatten, welche den StartTLS-Mechanismus verwenden. Noch schwieriger ist es bei Protokollen, wie beispielsweise OpenVPN, wo der TLS-Handshake noch tiefer integriert und vielleicht auch selbst via "TLS-Crypt v2" verschlüsselt ist. Die zweite Seite der Medaille sind die Clienten, die sich auf den Dienst verbinden. Wie kann man hier einen Überblick gewinnen, was diese kryptografisch bereits können, was sie im Handshake anbieten? Einen ersten Startpunkt bietet für den Apache-Webserver für mod_ssl die CustomLog-Variable. Allerdings wäre es interessant, insbesondere die vom Client angebotenen KeyShares zu analysieren, was bislang (meines Wissens) nicht unterstützt wird. Hier bestünde experimentell vielleicht die Möglichkeit, das Apache-Modul mod_ssl KI-assistiert dahingehend zu erweitern und es auf einem Testsystem mal auszuprobieren. Ernsthaft oder gar produktiv sollte das natürlich nicht verwendet werden. Ein erster generischer Ansatz könnte versuchen hier mit der Kommandozeilenversion von Wireshark tshark zu starten:

tshark -i eth0 -f "tcp port 443" \
  -Y "tls.handshake.type == 1 && tls.handshake.extensions_supported_version == 0x0304"
  -T fields -e tls.handshake.extensions_key_share_group \
  -e tls.handshake.extensions_key_share_key_exchange_length

• SSL Server Test (nur öffentlicher Port 443, TLS 1.2 erforderlich)
• Testing TLS/SSL encryption
• CustomLog für mod_ssl
• TShark

Mentoren: Wolf Müller

SMB3@QUIC

(innovativ, herausfordernd)

Das Netzwerkprotokoll QUIC löst (für einige Anwendungsfälle z.B. HTTP/3) klassisches TCP ab, indem es im Userspace über UDP läuft und Verschlüsselung via TLS 1.3 erzwingt. Vorteile sind beschleunigter Verbindungsaufbau (0-RTT), Verhinderung von Head-of-Line-Blocking und damit parallel laufende Streams. Weiterhin bietet QUIC Verbindungs-Migration: Da QUIC Sitzungen über eine eindeutige ID statt über IP-Adressen identifiziert, bleibt eine aktive Verbindung selbst beim Netzwerkwechsel stabil. In Kombination mit SMB3 und Samba sollte QUIC also zu einem performanten Remotedateisystem beitragen. Da "SMB over QUIC" standardmäßig über den "sicheren Web-Port UDP 443" ist eine Passage durch viele Firewalls oft möglich. Für Administratoren bedeutet diese Symbiose, dass sie ihren Nutzern weltweit einen hochsicheren, performanten und nahtlosen Zugriff auf Unternehmensdaten bereitstellen können, der sich so unkompliziert wie eine HTTPS-Webseite verhält. Probieren Sie es aus.

• QUIC: A UDP-Based Multiplexed and Secure Transport
• Using TLS to Secure QUIC
• Samba+
• QUIC in Linux Kernel

Mentoren: Wolf Müller

Umsetzung eines PQC-Verfahrens im Rahmen des CNG Frameworks

(spannend, aber anspruchsvoll)

Post-Quanten-Kryptografie befindet sich derzeit im Prozess der Standardisierung und es werden viele Demo-Anwendungen umgesetzt. Statt jede Anwendung einzeln zu modifizieren und Support für diese neuen Verfahren einzubauen, bietet das MS CNG Framework die Möglichkeit, Module global im Betriebssystem zu ergänzen. Anwendungen, die die entsprechenden System-Routinen verwenden, erhalten werden damit PQC-fähig ohne modifiziert werden zu müssen.

Aufgaben:

• Einarbeitung in das CNG-Framework
• Analyse des Beispielcodes (C++)
• Auswahl eines geeigneten PQC-Verfahrens (z.B. Dilithium https://pq-crystals.org/index.shtml)
• Implementierung von CNG Cryptographic Algorithm Provider sowie Signature/Encryption Provider

Links:

• Understanding Cryptographic Providers
• SDK mit Dokumentation und Beispiel-Code
• 2024 standardisierte PQC: FIPS 203, 204 und 205
• Skizze Microsoft CNG

Mentoren: Wolf Müller, Frank Morgner, Holger Eble

PQC@FIDO2

Auch wenn FIDO2 ein Verfahren zur starken Authentisierung ist und somit nicht durch das "store now, decrypt later"-Szenario bedroht ist, so ist es sicher eine gute Idee auch an dieser Stelle bereits über die Verwendung von quantenresistenten verfahren nachzudenken. So sind ist der Plan ja die FIDO-Sticks eine lange Zeit als hardwaresichere Platform zu nutzen. Konkret wurde mit OpenSK einer in Rust geschriebenen Open-Source-Implementierung ein Prototyp vorgelegt, der die Signaturalgorithmen (klassisch) ECDSA und (PQC) Dilithium zu einer Hybridsignatur kombiniert, wobei die Signaturerstellung in einem akzeptablen Zeitrahmen auf dem FIDO-Stick erfolgt. Versuchen Sie diese Implementierung auf der Plattform Nordic nRF52840-DK zum laufen zu bringen, wie es in dem Abstract des Papers angeregt wird: "We publish an open-source implementation of our scheme at hybrid-pqc so that other researchers can reproduce our results on a nRF52840 development kit." Hierzu sollten Sie vielleicht erst einmal versuchen die klassische OpenSK-Version mit CTAP zu testen, um dann zu verstehen, wie man auf dem Stick das Erzeugen eines Schlüsselpaars anstößt. Erst im nächsten Schritt wird der Testaufbau dann auf die hybride Version erweitert.

Links:

• Golem Artikel
• Paper
• hybrid-pqc Code
• OpenSK
• nRF52840-DK

Mentoren: Wolf Müller

Krypto-Agilität@OpenLDAP

Am Institut für Informatik, wird das ldaps-Protokoll verwendet, um Nutzer zu authentisieren. Die OpenLDAP-Server des Instituts sind redundant und synchronisieren die Nutzeraccounts untereinander. ldaps ist im Grunde ldap über TLS und wird in der Regel auf dem TCP-Port 636 bereitgestellt. Aktuell ist die TLS-Verbindung mit ECDSA-Schlüsseln mit 384-Bit Länge (secp384r1) mit einem eigenen Trustanker serverseitig authentisiert. Für die Etablierung der ephemeren Sitzungsschlüssel werden ebenfalls elliptische Kurven (X25519) verwendet. Das ist prinzipiell aktuell konform zur BSI TR-02102-2. Allerdings wäre es sinnvoll bereits jetzt über den Umstieg auf quantensichere Verfahren (insbesondere im Hybrid gepaart mit einem klassischen Verfahren) nachzudenken. Dabei ist es wünschenswert, dass ein Parallelbetrieb mit älteren Clienten, welche vielleicht eine elliptische Kurve mit großer Bitlänge unterstützen mit schon pqc-fähigen Clienten ermöglichen. Die Nutzung eines hybriden-pqc Verfahren für den Schlüsselaustausch, sollte nun erfolgreich "store now, decypt later" abwehren. Auch wenn das die dringendste Anforderung ist, ist der nächste Schritt, neben der Verwendung klassisch signierter Zertifikate zusätzlich für die Clienten, die diese Signaturen schon verifizieren können, auch hybride quantensichere Zertifikate zur Serverauthentifizierung anzubieten. Das beinhaltet einmal das Problem, wie mit solche Zertifikate erstellt werden können und welche Randbedingungen sich ergeben, wenn die Zertifikate und Signaturen von verschiedenen TLS-Clienten oder -Bibliotheken verifiziert werden sollen. Schauen Sie sich bitte insbesondere die Interoperabilität von openssl und gnutls an. Eine zusätzliche Herausforderung ist, sowohl pqc- als auch nichtpqcfähige Clienten zu unterstützen. Der TLS-Server muss dafür anhand der im "ClientHello" als unterstützt angegebenen Signaturverfahren richtig entscheiden, ob er das klassische ECDSA-Zertifikat oder ein hybrides PQC-Zertifikat für die Authentisierung verwendet.

Herangehen:

1. Installieren Sie Ubuntu 26.04.1 LTS (als virtuelle Maschine)
2. Installieren Sie OpenLDAP@Ubuntu
3. Recherchieren Sie, welche {OpenSSL,GnuTLS}-Versionen welche Kryptoverfahren unterstützen.
4. Erstellen Sie je einen Satz von {secp384r1,hybrid(klassisch+PQC}}-selbst signiertes Serverzertifikat
5. slapd ist unter Ubuntu gegen GnuTLS gelinkt.
   1. Versuchen Sie mit gnutls-serv einen TLS-Server im Parallelbetrieb aufzusetzen.
   2. Versuchen Sie sich auf diesen Server mit gnutls-cli und openssl s_client durch geeignete Wahl der Cipher als Parameter auf die eine als auch auf die andere Variante zu verbinden.
6. Passen Sie die Konfiguration für slapd.conf an, um den Parallelbetrieb für OpenLDAP zu ermöglichen.
7. Versuchen Sie für die neue Variante einen möglichst sichern Handshake, TLS 1.3 mit starkem Key-agreement zu konfigurieren. (Ist hier mit der in Ubuntu 26.04.1 bereitgestellten Version auch schon ein hybrides quantensicheres Key-agreement möglich?)

Links:

• Folien "HTTPS, OpenVPN, TLS? Quantensicheres Key Agreement"
• sslbench.c
• Ubuntu 26.04 LTS
• Install OpenLDAP@Ubuntu
• man 5 slapd.conf
• gnutls-serv
• gnutls-cli
• openssl s_client
• GnuTLS: priority strings
• GnuTLS: ciphersuites
• TR-02102-2
• P521_mldsa87-Zertifikat mit OpenSSL

Mentoren: Wolf Müller