W2023-ITS

Organisatorisches und Anmeldung für IT-Security Workshop 2. bis 13. Oktober 2023

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.

Vorträge

Freitag 13.10. 2023, Rudower Chaussee 25, Haus 3, Raum 3'328 (dritte Etage)

12:30-13:15	NTLM Relaying	Lea, Ben	pdf
13:30-14:15	Elektronische Siegel Urkunden	Arturo, Marc	pdf
14:15-14:45	Pause: Snack & Schnack
14:45-15:30	SIKE: Los, Stop, Schade	Jakob, Marvey	pdf
15:45-16:15	Signal Protocol Post Quantum Security	Emily	pdf
16:30-16:40	Zusammenfassung & Dank	Wolf Müller

Themen

JavaCard: Secure Channel

Für viele sicherheitskritische Anwendungen werden SmartCards als Sicherheitskern verwendet. Für viele Anwendungsfälle (E-Mail Signatur, QES, nPA, eGK, SIM...) gibt es bereits komplette Lösungen die die Karte als Plattform und eine fertige Anwendung enthalten. Will man jedoch eine eigene SmartCard-Anwendung schreiben, ist oft die Verwendung einer JavaCard und die Erstellung einer eigenen Applikation ein denkbarer Weg. Doch wie geht das konkret? Finden Sie es heraus und versuchen Sie eine eigene Smartcardanwendung in Java zu entwickeln und diese gemäß des Global Platform Standards auf der hoffentlich dann vorhandenen Javacard zu installieren und dann zu verwenden. JavaCard (erste Schritte)

Um eine sichere Verbindung zwischen der SmartCard und der Anwendungauf dem Rechner zu gewährleisten (was bei Mehrbenutzersystemen (Zugriff via USB oder insbesondere bei kontaktlosen Karten) wird das "Secure Channel Protokoll" verwendet. Unsere Smartcard J3R180 unterstützt SCP in der Version 03. Versuchen Sie ein Beispiel für eine sichere Kommunikation einer Anwendung auf dem Rechner mit einem von Ihnen geschriebenen JavaCardApplet zu erstellen.

Links:

• JavaCard Plugin für Eclipse
• GP Shell
• GlobalPlatformPro
• SCP03Wrapper
• JavaCardBuyersGuide
• JCOP4 J3R180 SCP03
• JavaCard 3.0.5
• JavaCard 3.0.5: API
• Secure Channel Protocol '03'
• Beispiel für SCP02

Mentor: 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
• Skizze Microsoft CNG

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

POC@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

WireGuard@Informatik

WireGuard ist ein auf modernen kryptografischen Algorithmen basierendes, in den Linux-Kernel gut integriertes und sehr performantes VPN. Die Konfiguration für einzelne Peers ist sehr übersichtlich. Jedoch ist es nicht vorgesehen, dynamische IP-Adressen nach etablierter Verbindung zu nutzen, sondern diese werden direkt in der Konfigurationsdatei gesetzt. Das reduziert die Komplexität und erhöht die Geschwindigkeit. Wie könnte aber eine komfortable Konfiguration für sehr viele Nutzer (die potenziell auch noch mehrere Geräte haben) aussehen? Gibt es hier bestehende Ansätze, wie (z.B. über einen Webdienst für authentisierte Institutsmitglieder) Konfigurationsdateien (die vielleicht auch einen QR-Code beinhalten) für die Geräte generiert und an die berechtigten Nutzer ausgeliefert werden, so dass potenziell alle Benutzer all Ihre Geräte konfliktfrei mit dem VPN verbinden können? Auch hierbei ist es sicherlich sinnvoll bereits über eine hohe Sicherheit gegen zukünftige Angreifer mit Quantencomputer nachzudenken man:

"PresharedKey — a base64 preshared key generated by wg genpsk. Optional, and may be omitted. This option adds an additional layer of symmetric-key cryptography to be mixed into the already existing public-key cryptography, for post-quantum resistance."

Ein interessantes Projekt könnte vielleicht wg-dynamic sein. Aber suchen Sie getrost nach besseren Ideen oder Ansätzen.

Links:

• WireGuard
• Protokoll
• wg-dynamic
• wg-dynamic: Idee

Mentor: Wolf Müller

OpenVPN: performant & sicher

OpenVPN ist ein sehr etabliertes und auch historisch gewachsenes VPN, welches viele Konfigurationsmöglichkeiten bietet. Das ist einerseits natürlich fantastisch, andererseits auch eine Herausforderung. Im Vergleich zu WireGuard, welches aufgrund seiner schlanken und "state of the art"-Kryptografie bereits Einzug in den Kernel gefunden hat, ist OpenVPN häufig signifikant langsamer und nicht immer sicher konfiguriert.

Können Sie hier weiterhelfen?

• So wäre es wünschenswert bereits jetzt etwas gegen Angreifer zu unternehmen, die den VPN-Verkehr aufzeichnen und später mit einem Quantencomputer entschlüsseln wollen. Weiterhin ist es wünschenswert, die Sicherheitsreserven zu erhöhen. Da Sie bei einer Authentifizierung mittels TLS-Client-Zertifikaten eine eigene PKI verwenden können, bietet es sich an, hier ECC-Schlüssel mit >400 Bit zu wählen. Weiterhin sind die Optionen --tls-crypt oder besser --tls-crypt-v2 interessant. Versuchen Sie, einen schnellen und sicheren TLS-Handshake zur Authentifizierung und Schlüsselableitung zu etablieren.
• Im zweiten Schritt müssen dann noch die eigentlichen Nutzdaten ver-/entschlüsselt werden. Um dies performant und dennoch sicher umzusetzen, können Sie zum einen versuchen, die Hardwareunterstützung für AES zu aktivieren. Aber selbst wenn Ihnen das gelingt, wird WireGuard wahrscheinlich immer noch weitaus performanter sein. Das Problem ist, dass bislang bei OpenVPN in der Regel zwischen Versenden und Empfang und der Ver-/Entschlüsselung ein aufwendiger Wechsel zwischen User- und Kernelspace erfolgt, der in WireGuard nicht erforderlich ist. Doch auch hier gibt es Hoffnung in Gestalt von "OpenVPN Data Channel Offload", welches unter Linux ein Kernelmodul "openvpn-dco" nutzt um hier die Performance deutlich zu steigern. Konkret werden die AEAD Verschlüsselungen AES-GCM-256, AES-GCM-128 und CHACHA20POLY1305 unterstützt.

Motivation: Bei meinem OpenVPN unter Windows 10 hat sich der Downstream von 48 Mbit/s auf 182 Mbit/s (exemplarisch, nicht repräsentativ) verbessert.

Links:

• OpenVPN DCO
• OpenVPN git für openvpn 2.6.0
• git für ovpn-dco-win
• BSI TR-02102-2

Mentoren: Wolf Müller

SIKE: Los, Stop, Schade!

[Jakob, Marvey]

Lange Zeit war SIKE "Supersingular Isogeny Key Encapsulation" ein heißer Kandidat im NIST-Wettbewerb für quantensichere Kryptoverfahren hier insbesondere für den asymmetrischen Diffie-Hellmann-artigen Schlüsselaustausch. Insbesondere interessant schienen die moderaten Längen der auszutauschenden Nachrichten, welche für Overhead in Protokollen wie TLS wichtig sind. Lange Zeit wurde der optimierte Algorithmus als sicher angesehen und schaffte es bis auf die Kandidatenliste für die vierte Runde. Dann wurde jedoch gezeigt, dass der private Schlüssel recht effizient (auf einem Laptop in einer Stunde) aus der Beobachtung von SIDH wiederhergestellt werden kann.

Versuchen Sie (im Groben) zu verstehen, wie der Algorithmus funktioniert. Versuchen Sie, die Idee des Angriffs nachzuvollziehen. Probieren Sie an einem eigenen Beispiel den Angriff mithilfe von SageMath.

... und jetzt die eigentliche Herausforderung: Versuchen Sie uns das im Vortrag zu erklären ;-).

Links:

• Golem
• SIKE
• NIST:PQC:4. Runde Kandidaten
• An efficient key recovery attack on SIDH
• PoC in Magma
• SIDH Key Recovery Attack in SageMath
• SageMath

Mentor: Wolf Müller

VaultProject

An vielen Stellen werden Credentials für eine Authentisierung oder Ver-/Entschlüsselung benötigt. So können im Institut für Praktika oder Forschung VMs aufgesetzt werden und die jedoch zur Nutzung Passworte oder private SSH-Schlüssel benötigen. Wie können diese vorbereitet und sinnvoll an die berechtigten Nutzer ausgegeben oder verwaltet werden. Wenn ein verschlüsseltes Backup angelegt werden soll, wäre es vielleicht wünschenswert, dass der Nutzer ein Passwort setzt oder Schlüssel generiert. Doch was passiert, wenn der Nutzer dies vergisst? Vielleicht wäre es (zumindest im Sinne der Verfügbarkeit) eine Idee, einen zusätzlichen Weg zur entschlüsselten Wiederherstellung mit vorzusehen? Hier könnte eine Idee eine Wiederherstellung im "virtuellen Mehraugenprinzip für Administratoren" sein, also mehrere Administratoren müssen kooperieren, indem sie Ihre Keyshares zusammenbringen, um in dieser Situation dennoch eine Entschlüsselung des Backups zu ermöglichen. Aus Anwendersicht wünscht man sich natürlich volle Transparenz, also insbesondere im Vorhinein die Information unter welchen Bedingungen eine Entschlüsselung möglich ist. Ein Startpunkt welcher hinsichtlich seiner Möglichkeiten untersucht werden könnte, wäre "Vault". Versuchen Sie in den zwei Wochen sowohl den Möglichkeiten als auch den potenziellen Risiken eines solchen Ansatzes auf den Grund zu gehen.

Links:

• Vault
• Binaries
• Erste Schritte

Mentor: Robert Sombrutzki, Wolf Müller

NTLM Relaying

[Lea, Ben]

NTLM (Windows New Technology LAN Manager) ist ein Authentifizierungsprotokoll von Microsoft, welches in den 90er Jahren eingeführt wurde. NTLM Relaying ist eine Standardklasse von Angriffen, die bei Zugriffen auf das interne Netz möglich ist. Das Grundproblem ist, dass NTLM an sich keinen Schutz vor Relay-Angriffen liefert, daher ist es aus heutiger sicher veraltet und sollte möglichst nicht mehr verwendet werden. Viele ältere Systeme sind jedoch weiterhin auf NTLM angewiesen, so dass NTLM noch immer verwendet wird, um Abwärtskompabilität zu gewährleisten. Daraus lassen sich recht komplexe Angriffsketten bauen (z.B. der PrivExchange Angriff, bei dem das hochprivilegierte Computerkonto des Exchange-Servers weitergeleitet wird), aber auch vergleichsweise einfachere Angriffe sind häufig noch möglich. Angriffe können auf Protokolle wie SMB, HTTP, MSSQL, SMTP, IMAP ausgeführt werden, wobei bspw. via SMB Zugriff auf FileServer gewährt werden kann.

Die NTLM-Authentifizierung (NetNTLMv1) läuft folgendermaßen ab:

1. Negotiate: Der Client sendet eine Anfrage mit Benutzername und Konfigurationsinformationen zum Server
2. Challenge: Der Server generiert eine zufällige Challenge (Zufallszahl) und sendet diese an den Client
3. Authenticate: Der Client verschlüsselt die Challenge mit seinem Passwort → sendet Response. Der Server schickt das Challenge/Response Paar an den Domain Controller zur Validierung

Quelle: https://en.hackndo.com/assets/uploads/2020/03/ntlm_challenge_response.png

Folgende Vorraussetzungen müssen für einen Relay Angriff erfüllt sein:

1. Netzwerkzugriff:
   Angreifer im gleichen Netzwerksegment wie der Client und Server: Man-in-the-middle
2. Aktive Authentifizierung:
   Client muss auf Ressource zugreifen, die NTLM zur Authentifizierung verwendet.
3. Konfiguration des Servers:
   Der Zielserver muss NTLM-Authentifizierung akzeptieren, Signieren darf nicht erforderlich sein

Potentielle Opfer finden: Server zu finden, die diese Voraussetzungen erfüllen, ist gar nicht so schwer. Es müssen einfach nur Anfragen an Server geschickt werden, bei denen die Flags richtig gesetzt sind und, falls der Server einverstanden ist mit den Verhandlungen (NTLM-Negotiate SUCCESS), wäre der nächste Schritt die NTLM-Authentifizierung. Diese führt der Angreifer nicht aus, sondern merkt sich den Server-Namen. Somit kann er sich eine Liste mit potentiellen Opfern erstellen.

Relay-Angriff: Sind die Vorraussetzung erfüllt so kann ein Angreifer den Datenverkehr auf dem Netzwerk überwachen. Für NTLM-Relaying fängt der Angreifer NTLM-Authentifizierungspakete zwischen einem Client und einem Server ab. Unter anderem durch fehlgeschlagene Suche nach Hostnames kann ein Angreifer in die Man-in-the-Middle Position kommen. Gründe dafür können bspw. Zugriff auf nicht mehr existierende Fileserver, alte Netzwerklaufwerke, Tippfehler im Hostname, inoffizIelle Browser mit Proxy-Autodiscovery oder sonstige fehlerhafte DNS Anfragen sein. Der Router im Netwerk sendet dann eine Anfrage (Broadcast) an alle Netzwerk-Geräte, um zu erfragen ob diese den fehlerhaften Hostname kennen. Das ist der Moment, in dem sich der Angreifer als der angefragte Server ausgeben kann und als dieser antwortet. Der Angreifer authentifiziert sich bei dem Server seiner Wahl und leitet alle Pakete zwischen Server und Client weiter. Der Client denkt, er authentifiziert sich bei seinem Server (Die NTLM-Inhalte müssen dafür nicht angepasst werden). Der Server authentifiziert den Angreifer, als wäre er der ursprüngliche Client und gewährt dem Angreifer schließlich Zugriff auf Ressourcen.

Es existieren zwei Standard-Tools für Relaying Angriffe:

• Responder und MultiRelay
• Impacket und NTLMRelayX

Beispiel: Relay-Angriff mit Responder.py simulieren

Ein beispielhafte Durchführung von NTLM-Relaying kann man mit folgendem Setup realisieren:

• VMWare Workstation 17 Player mit 3 virtuelle Maschinen:
  1. Client: Windows 10
  2. Server: Windows 2012 (mit Domain Controller)
  3. Angreifer: Linux Ubuntu

Der Angreifer fungiert in diesem Aufbau zeitgleich als Router, was mittels IPv4-forwarding realisiert wurde. Alle NTLM-Anfragen zwischen Client und Server müssen also automatisch über den Angreifer geschickt werden (ein sehr großer Luxus) und somit ist er bereits in der Man-in-the-middle Position. Versucht der Client nun auf einen shared-Folder des Servers zuzugreifen, kann der Angreifer mittels Responder.py auf die Server-Anfrage antworten, so dass der Client denkt er kommuniziert mit dem Server und seine Credentials preisgibt. Mittels Multirelay.py kann der Angreifer die Credentials direkt an eine Server weiterleiten, auf den er Zugriff erlangen will. MultiRelayX erlaubt das Filtern von weiterzuleitenden Nutzern mittels des Parameters -u, wodurch nach Nutzern mit besonderen Rechten wie "admin" gefiltert werden kann. In den Funktionen ParseSMBHash und ParseHTTPHash aus ResponderNTLM/tools/Multirelay/RelayMultiCore.py, kann die Variable "UserToRelay" so modifiziert werden, dass ebenfalls Wildcards (z.B. -u adm*) abgefragt werden können.

In der Testumgebung haben wir uns für einen Windows 10 Client und einen Windows Server 2012 entschieden. Um NTLM-Relaying zwischen einem Windows 10 Client und einem Windows Server 2012 simulieren zu können sind einige Grundeinstellungen vorher zu ändern, damit die Voraussetzungen erfüllt sind:

• Client und Server: SMB2 → SMB1
• Client und Server: SMB Signaturen nicht erforderlich
• Server: “Keine Kerberos-Präauthentifizierung erforderlich”
• Server: NTLM-Authentifizierung möglich

Um also NTLM-Relaying Angriffe zu unterbinden, müssen "nur" folgende Vorkehrungen getroffen werden:

- Veraltete, unsichere Systeme weitestgehend deaktivieren

- "Signierung erforderlich" aktivieren

Folgendes Problem: Teure Geräte, die nur alle 10-20 Jahre erneuert werden, werden nur ungern vor ihrem "Lebensende" abgesteckt. Damit diese Systeme weiterhin genutzt werden können, muss also eine Abwärtskompatibilität gewährleistet werden... Eine Signierung mal kurz zu ergänzen ist auch nicht so einfach... Und selbst wenn die Systeme erneuert werden und neuere Protokolle unterstützen, wird das gleiche Spiel nur wieder widerholt. Von NTLM könnte z.B. auf Kerberos upgegraded werden, jedoch existieren für Kerberos bereits ebenfalls Relaying Angriffe. Somit müssten Unternehmen alle ihre Systeme auf dem neuesten Stand halten und Alt-Systeme rechtzeitig ersetzen. Da dies viel Zeit und Geld kostet, wird es in der Realität nicht immer praktiziert. Trotzdem zu gewährleisten, dass das System sicher ist, ist eine schwierige Aufgabe und nicht Teil dieses Projekts.

Was tun mit den Hashes nach einem erfolgreichen NTLM-Relay Angriff?

1. crack-the-hash Wenn die NTLM-Hashes komprimittiert wurden, kann der Angreifer versuchen, die Passwörter zu erraten. Hierfür kann z.B. Hashcat verwendet werden, um einen Dictionary-Angriff auszuführen. Die Voraussetzung ist natürlich, dass das gewählte Passwort des Clients (oder Admins) schwach genug ist, um über einen Dictionary-Angriff erfolg zu haben. Um einfach nur an das Passwort eines Clients zu kommen, könnte der Angreifer auch die NTLM-Authentifizierung selber durchführen und die NTLM-Challenge ("Zufallszahl") an den Client senden und danach eine Regenbogen-Tabelle verwenden, um das Passwort des Clients zu erfahren. Auch dieser Angriff ist nur möglich, wenn das Passwort in unserer Regenbogen-Tabelle enthalten ist. Der Angreifer könnte also leer ausgehen.

2. pass-the-hash Wenn z.B. der Dictionary-Angriff nicht funktioniert hat (oder man sich gar nicht für die Passwörter interessiert, da NTLM-Hashes bei der Authentifizierung gleichwertig sind), kann man auch einfach die NTLM-Hashes verwenden, um sich bei weiteren Servern anzumelden. Ein Client mit Admin-Rechten auf Server A, kann ebenfalls Admin-Rechte auf Server B haben. Und da die Authentifizierung mit dem gleichen NTLM-Hash stattfindet, kann der Angreifer sich bei Server B authentifizieren (ohne je das Passwort gewusst zu haben) und weitere Systeme komprimittieren.

Quelle: https://en.hackndo.com/assets/uploads/2019/11/pass-the-hash-schema.png

Es existieren noch weitere Angriffe, die nach dem NTLM-Relay Angriff möglich sind, jedoch sind die Grundzüge in crack-the-hash und pass-the-hash enthalten. Je komplexer das anzugreifende System (unterschiedliche Hierarchien unter den Servern, etc.), desto ausgefallener werden auch die weiteren Angriffe. Dies könnte man sich in späteren Projekten genauer anschauen (jedoch würde dafür unsere Testumgebung zuerst angepasst werden müssen). Ein weiterer Schritt in die gleiche Richtung wäre, Kerberos-Relaying auszuprobieren.

Anbei unsere Folien: File:NTLM-Relaying-Vortrag.pdf

Mentoren: Wolf Müller

WebAuthn / FIDO2

WebAuthn ist ein browserübergreifender Standard zur Authentisierung im Web. Die meisten modernen Browser Firefox, Chrome, Safari, Opera unterstützen die Verwendung von Sicherheitstoken zur Authentisierung gegenüber von besuchten Webdiensten ohne die Installation von weiterer Software oder Treibern. Während auch in WebAuthn aufgenommenen Standard FIDO-U2F ursprünglich dazu verwendet wurde, um eine Nutzername/Passwort-basierte Authentisierung durch die Nutzung eines universellen zweiten Faktors gegen automatisierte Angriffe entfernter Angreifer zu härten, ist es mit FIDO2 möglich, sich ganz ohne die Verwendung von Passwörtern zu authentisieren.

Probieren Sie es aus! Wo kann man sich mit FIDO2 authentisieren? (Interessante Webdienste). Versuchen Sie, einen Web-Service mit FIDO2-Authentisierung aufzusetzen! Obwohl WebAuthn/FIDO2 primär zur Nutzung mit Webdiensten entworfen wurde, sind ggf. auch andere Nutzungen (lokales Login, Windows Hello, Linux PAM, SSH, SCP, ...) denkbar. Was geht (schon)?

• WebAuthn
• Video
• FIDO2
• Security Key
• WireShark-dissector

Mentor: Wolf Müller

Elektronische Siegel Urkunden

[Arturo, Marc]

Es wäre schön, zum Abschluss eine elektronisch gesiegelte oder unterschriebene Urkunde in den Händen zu halten. Aber wie kann das gehen? Entwickeln Sie erste Ideen und probieren Sie Dinge aus ...

Startpunkte/Ideen:

• Acrobat bietet das Unterschreiben an, das geht auch mit eigener Infrastruktur, wenn zuvor ein vertrauenswürdiges Zertifikat importiert ist.
• eIDAS sieht die Verwendung von elektronischen Siegeln vor.
• Können die gesiegelten Informationen auch in einer leicht verifizierbaren Form auf dem Papierdokument aufgebracht werden? ((PDF-Signatur, QR-Code, OCR-Text, Hash-Wert in HEX, URI, Blockchain oder PGP-Signatur)
• Kann ein separates Gerät (z.B. Raspberry Pi, offline) zum Siegeln mit 2-Faktor-Authentisierung für ein Prüfungsbüro bereitgestellt werden?

Links:

• BSI Elektronische Signaturen, Siegel und Zeitstempel [1]

Mentor: Wolf Müller

CSP: Umwandlung von Inline / Internal CSS, JS und DATA in externe Ressourcen

Unser Institutswebserver verwendet aus Sicherheitsgründen Content Security Policies, um Angriffe wie CrosssiteScripting oder Ähnliches zu erschweren. Daher ist "unsafe-inline" dort verboten. In Praxis wird zwar die HTML-Seite mit dem potenziell unsicheren Inhalt ausgeliefert, jedoch wird der Client über die CSP-Wünsche des Servers im HTTP-Header informiert.

curl --head https://www2.informatik.hu-berlin.de/~wolfm/InternalInline.html
Content-Security-Policy: frame-ancestors 'self' https://www.informatik.hu-berlin.de;
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'; 

Nach dieser Information ignoriert der Browser die entsprechenden potenziell unsicheren Anteile. Wenn Sie also die das Beispiel in Ihrem Browser aufrufen, sieht es recht schlicht aus und der JavaScript-Code wird nicht interpretiert. Wenn Sie die Seite aber lokal herunterladen und dann über file:./InternalInline.html öffnen, so sind die CSP-Header nicht mehr aktiv und die Seite zeigt ein Bild und hat Farben.

Aus Sicherheitssicht gibt es gute Gründe gegen eingebettete Styles, Javascript und die Nutzung von DATA. Jedoch erzeugen viele Programme (z.B. MS Office Word) beim HTML-Export HTML, was die Separierung der Anteile nicht konsequent umsetzt. Damit sehen solche Dokumente über den Webserver ausgeliefert eher unerwartet (schlecht) aus.

Schreiben oder finden Sie ein oder mehrere Skripte, die eine für den Anwender komfortable möglichst Konvertierung ermöglichen, also alle Style-Informationen in CSS-Dateien, alles JavaScript in JS-Dateien und möglichst alle CDATA ggf. expandiert (so sie base64-kodiert sind) und diese in separate Dateien ausgliedert, die CSP-kompatibel in die konvertierte Datei dann regulär eingebunden werden. Optional können die CSS- und JS-Dateien noch kompakter dargestellt werden.

Links:

• Beispiel
• CSP
• Tidy
• CSS, JS Minifier

Mentoren: Wolf Müller

Absicherung KNXD

Der Zugriff auf KNX-Komponenten im Heimnetzwerk (KNX-Bus) kann mithilfe der Open Source Software knxd vom Netzwerk erfolgen. Sinnvollerweise wird der Dienst so konfiguriert, dass er nur im Heimnetzwerk (also in der Regel in einem privaten Netzwerk) verfügbar ist. Dennoch eröffnet sich damit die Möglichkeit, ohne eine weitere Authentisierung auf KNX-Komponenten zuzugreifen. So könnte ein bösartiges Gerät (Fernseher, Staubsauger, Smarter Lautsprecher) die mit meinem Heim-IP-Netzwerk verbunden sind, diese Möglichkeit ausnutzen, um Zugriff auf beispielsweise die Heizungssteuerung oder Türschlösser zu erlangen. Wünschenswert wäre hier eine stärkere Authentisierung. Ideen/Priobleme:

• TLS mit Clientzertifikaten statt TCP-Socket?
• Geht da was mit Wireguard?
• TLS könnte in den Code von knxd integriert werden.
• ETS 5 kann nicht modifiziert werden, geht da was mit stunnel?
• Alternativ könnte man auch versuchen, eine Authentisierung gemäß KNX-IP-Secure Standard umzusetzen, was aber eher für eine Masterarbeit geeignet ist.

Links:

• KNXD (git)
• ETS (KNX Konfigurationssoftware
• KNXD_Tutorial
• OpenHAB_Tutorial

Mentoren: Wolf Müller

Sicherer und schneller SSL/TLS-Handshake

[Ridvan]

Nach den Enthüllungen von Edward Snowden haben wir verstanden, warum authentische und vertrauliche Kommunikation wichtig ist. Naiv betrachtet, könnte man denken, es ist ausreichend "s"-Protokolle wie https, imaps, pops ... zu verwenden und alles ist gut. Es ist in Praxis jedoch wesentlich komplexer eine unter dem gegenwärtigen Angreifermodell hinreichend starke SSL/TLS-Verbindung zu erzwingen.

In der Vergangenheit wurden zahlreiche teils sehr originelle Angriffe auf SSL/TLS entwickelt, die Seitenkanäle oder auch Probleme im Protokollentwurf oder der Implementierung adressieren. Weiterhin ist es wünschenswert, "forward secureness" zu nutzen, da auch nicht für jeden Server der private Schlüssel immer privat bleiben muss.

Versuchen Sie für einen aktuellen SSL/TLS-Server (z.B. Apache oder NGINX) eine möglichst sichere Konfiguration zu erstellen. Eine gute Orientierung bietet die Technische Richtlinie "BSI TR-02102-2" Behalten Sie dabei auch die Performance für den Handshake im Auge:

• Könnte die Nutzung von ECC hier weiter helfen?
• DH oder ECDH?
• Was muss ein sorgsamer Client alles prüfen, wie kann ihn der Server dabei unterstützen?
  • Kann man die gesamte Zertifikatskette auch ECC-signiert bekommen?
  • Was ist OCSP-stapling
  • Was bringen die einzelnen Maßnahmen?
• Kann Kernel-Level-TLS helfen?
• Wie kann eventuell die Hardwareunterstützung für AES (oder gar ChaCha20) aktiviert werden?

Links:

• BSI TR-02102-2
• Angriffe auf SSL/TLS
• (Web-)Server Test
• HOWTO OCSP stampling
• Kernel TLS

Mentor: Wolf Müller

Signal Protocol Post Quantum Security

[Emily]

Das Signal Protocol ist eines der beliebtesten E2EE-Messaging Protokolle und bietet bemerkenswerte Eigenschaften wie Forward und Future Secrecy. Zwar gab es schon einige Forschung zu den Möglichkeiten, das Protokoll PQS zu machen jedoch beruhten viele Überlegungen auf den nun obsoleten SIKE/SIDH Algorithmus. Vor kurzem hat Signal nun ein Whitepaper zum PQX3DH Protokoll veröffentlich, was den Handshake zwischen zwei Clients quantensicher macht.

Interessant ist es nun sich diese Protokoll anzuschauen und mit der bisherigen Implementation zu vergleichen. Gibt es auch Möglichkeiten den Double Ratchet Mechanismus gegenüber Quantencomputern zu sichern?

Links:

• Whitepaper zu PQX3DH
• Hybrid Signal protocol for post-quantum email encryption