W2025-ITS

From
Jump to navigation Jump to search

Organisatorisches und Anmeldung für IT-Security Workshop vom 29. September bis 10. Oktober 2025

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.

Vorträge

Freitag 10.10. 2025, Rudower Chaussee 25, Haus 3, Raum 3'328 (dritte Etage)

09:30-10:15 USB-Pentesting PR pdf
10:15-11:00 WebAuthn/FIDO2 MS pdf
11:00-11:15 Pause: Snack & Schnack
11:15-12:00 Supply Chain Angriff & Paketsignaturen unter Linux AS pdf
12:00-12:45 Mittagspause
12:45-13:30 PQC@TLS-Handshake KS pdf
13:30-14:45 WireGuard@Informatik JH, NN pdf
14:45-15:00 Zusammenfassung & Dank Wolf Müller

Themen

PQC@TLS-Handshake

[KS]

Das "store now and decrypt later"-Szenario ist bereits jetzt eine Bedrohung für die Vertraulichkeit der im Rahmen einer TLS-Verbindung übertragenen Daten. Auch, wenn das in der aktuellen TR02102 noch nicht explizit gefordert wurde, ist es bereits jetzt interessant, sich damit zu beschäftigen, wie eine quantensichere (oder besser hybride) asymmetrische Schlüsselaushandlung gelingen kann. Hier bietet OpenSSL ab der Version 3.5+ bereits drei hybride aus klassischem und quantensicheren (ML-KEM) Verfahren:

openssl list -tls1_3 -tls-groups ... SecP256r1MLKEM768:X25519MLKEM768:SecP384r1MLKEM1024.

Auch GnuTLS, wolfSSL und einige Browser unterstützen schon solche hybriden Verfahren. Doch kann man das auch in der Praxis verwenden? Probieren Sie es aus. Setzen Sie einen Webserver auf, inspizieren Sie mit Wireshark den Handschake, untersuchen Sie Interoperabilität und Performance.

Der nächste Schritt wäre dann auch der Einsatz von PQC-Signaturverfahren für die Authentisierung von Server und ggf. Client. Auch hier sind vielleicht hybride Verfahren sinnvoll. Gibt es schon die Möglichkeit, PQC-Zertifikate und die zugehörigen privaten Schlüssel einzusetzen? Gibt es scvhon CAs die solche Zertifikate ausstellen? Wohin geht die Reise?

Links:

Mentoren: Wolf Müller

PQC@OpenVPN

OpenVPN ist eine weit verbreitete Open-Source-Lösung für sichere, verschlüsselter 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, so ist der Datenkanal auch quantensicher. Hierbei sin 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, dass die Ver- und Entschlüsselung der Datenpakete direkt im Kernel-Space ermöglicht. Von dem DCO-Kernel-Modulfür 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.

Links:

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, an auf welche Stellen man achten müsste, um WPA3-Enterprise quantensicher zu bekommen. Bauen Sie ein en eigenes WPA3-Enterpreise Netzwerk auf und sichern sie es möglichst gut ab 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:

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 RSA-Schlüsseln ≤ 2048-Bit Länge mit einem eigenen Trustanker abgesichert, hier soll erst einmal eine Migration auf elliptische Kurven mit großer Schlüssellänge also Ed448 oder ECDSA mit ≤ 500 Bit erfolgen. Diese Migration soll aber im laufenden Betrieb möglich sein, da sonst für einen gewissen Zeitraum zu viele Systeme den Dienst unterbrechen müssten. Es soll also ein Parallelbetrieb der RSA- und "elliptic curve"-Variante möglich sein. Wenn Sie hierfür eine Lösung gefunden haben können Sie versuchen im nächsten Schritt zu schauen ob auch ein Parallelbetrieb einer "elliptic curve"- mit einer quantensicheren ML-DSA-Variante möglich ist. Herangehen:

  1. Installieren Sie Ubuntu 24.04 LTS (als virtuelle Maschine)
  2. Installieren Sie OpenLDAP@Ubuntu
  3. Erstellen Sie je einen Satz von {RSA,ed448}-basierten CA + Serverzertifikat
  4. 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.
  5. Passen Sie die Konfiguration für slapd.conf an, um den Parallelbetrieb für OpenLDAP zu ermöglichen.
  6. Versuchen Sie für die neue Variante einen möglichst sichern Handshake, TLS 1.3 mit starkem Keyagreement zu konfigurieren. (Ist hier mit der in Ubuntu 24.4 bereitgestellten Version auch schon ein quantensicheres Keyagreement möglich?)

Links:

Mentoren: Wolf Müller

Supply Chain Angriff & Paketsignaturen unter Linux

[AS]

Häufig ist es auch verlockend zu den Repositories der Distribution weitere Paketquellen hinzuzufügen. Man kann einerseits direkt ein konkretes Paket installieren oder aber ein zusätzliches Repository und den öffentlichen Schlüssel zur Signaturprüfung hinzufügen. So wird z.B. für die Installation von Eclipse Temurin der folgende Ablauf vorgesehen: 

wget -qO - https://packages.adoptium.net/artifactory/api/gpg/key/public | gpg --dearmor | tee /etc/apt/trusted.gpg.d/adoptium.gpg > /dev/null
echo "deb https://packages.adoptium.net/artifactory/deb $(awk -F= '/^VERSION_CODENAME/{print$2}' /etc/os-release) main" | tee /etc/apt/sources.list.d/adoptium.list

welcher den öffentlichen Signaturschlüssel herunterläd und für apt als vertrauenswürdig hinterlegt und die URL zur Liste der Quellen hinzufügt. Die eigentliche Erstinstallation erfolgt dann mit: 

apt update # update if you haven't already
apt install temurin-25-jdk

Das Vorgehen scheint auch für sicherheitsbewußte NutzerInnen durchaus plausibel, schließlich wird die Paketsignatur vor der Installation geprüft und auch zukünftige Updates werden automatisch gefunden und nach Signaturprüfung installiert, wenn bies mit Boardmitteln angefordert wird: 

apt-get update && apt-get upgrade

Wir gehen hier davon aus, dass das Paket zum Zeitpunkt der Erstinstallation genau das war, was wir wollten und integer war. Doch was bedeutet das für die Zukunft?

  • Natürlich kann wenn ein Ursprungsprojekt durch Angriffe kompromittiert werden, also kann die nächste bereitgestellte Version unsicher oder bösartig sein.
  • Die Paketinstallation erfolgt mit root-Rechten, so können ggf. bei der Installation Systemdateien gelesen, gelöscht oder verändert werden.
  • Können aus der Quelle "A" mit dem zugehörigen Signaturschlüssel auch Updates zu in der (System-)Quelle "B" angebotenen Paketen bereitgestellt werden und werden diese dann ohne Warnung installiert?
  • Kann ein Paket aus Quelle "A" Dateien überschreiben die eigentlich zu einem anderen Paket gehören?
  • Damit ein potenzieller "supply chain attack" nicht gleich auffällt, können natürlich verschiedene Inhalte des Repositories (z.B. je nach Absender-IP) ausgeliefert werden.
  • Was passiert, wenn zusätzliche Dependencies durch ein Paket verlangt werden?
  • ...

Werden Sie kreativ, betreiben Sie ein eigenes Software-Repository, binden Sie es in ihr Testsystem ein und probieren Sie es aus. Vielleicht haben Sie noch weitere Ideen. Gibt es Schutzmechanismen, die hier eine Eindämmung der Wirkkraft des installierten öffentlichen Verifikationsschlüssels begrenzen oder eindämmen?

Links:

Mentoren: Wolf Müller

FIDO2 TLS 1.3 Erweiterung

FIDO2 Security Keys bieten eine starke, datensparsame, standardisierte und zunehmend verbreitete Methode zur Clientauthentifizierung in Webanwendungen. Sie bieten hohe Sicherheit, Phishing-Resistenz, Privatsphäre und gute Benutzbarkeit. Die Authentifikatoren werden in anderen Protokollen, die eine Client-Authentifizierung erfordern, kaum verwendet, da sie ursprünglich für Webumgebungen entwickelt wurden. Das Projekt "FIDO2 TLS1.3 Extension" von Jonas Panizza implementiert TLS-Erweiterung in OpenSSL, die sowohl FIDO-Authentifizierung und -Schlüsselregistrierung direkt in TLS integriert und so für Nicht-HTTP(S)-Anwendungen verfügbar macht. Die Erweiterung wird für OpenSSL als zusätzliche C-Bibliothek bereitgestellt.

Eine eindrucksvolle Demonstration des Potenzials liefert Jonas gleich mit, indem er die Erweiterung in hostapd und wpa-Supplicant integriert, um ein 802.1X EAP-TLS-WLAN-Netzwerk einzurichten, das FIDO-Hardware-Authentifikatoren verwendet und herkömmliche X.509-Client-Zertifikate ersetzt.

Um die im TLS (Version 1.3) Handshake ausgetauschten Nachrichten besser verstehen können und damit langfristig dem Ziel von Interoperabilität zwischen "FIDO2 TLS1.3 Erweiterungen" für verschiedenen TLS-Implementierungen (zusätzlich zu OpenSSL) näher zu kommen, wäre eine Möglichkeit zum Logging/Debugging (vielleicht später sorag in Wireshark) wünschenswert. Da TLS v1.3 bereits große Teile des ServerHello verschlüsselt, sollte hier ein Mechanismus geschaffen werden, der dies, wenn vom Nutzer gewünscht, gestattet, indem Wireshark in einer Datei in standardisierter Weise die Sitzungsschlüssel zur Verfügung gestellt werden. Konkret gibt man mittels der Umgebungsvariablen SSLKEYLOGFILE an, dass dieser Mechanismus aktiv ist und in welche Datei die Schlüssel exportiert werden sollen.

Links:

Mentoren: Wolf Müller

OpenVPN DCO @ {OPNsense,pfSense CE}

Mit pfSense 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 15.0-CURRENT #21 RELENG_2_8_1-n256095-47c932dcc0e9 aus den FreeBSD-Quellen ein passendes Modul selbst zu kompilieren. Allerdings ist nicht gleich offensichtlich, aus welchen Quellen das wie gelingen könnte.
  2. Man versucht auf die vor geraumer Zeit geforkte OPNsense Variante zu wechseln und dort OpenVPN mit DCO (und vielleicht gar mit quantensicherem Keyagreement) 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:

Mentoren: Wolf Müller

WireGuard@Informatik

[JH,NN]

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.

Etwas moderner wäre headscale "An open source, self-hosted implementation of the Tailscale control server".

Links:

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.
  • Im dritten Schritt wäre eine möglichst performante Umsetzung zum Einsatz unter den im Institut gegebenen Rahmenbedingungen wünschenswert. Hier könnte der OpenVPN-Server unter Proxmox mit möglichst Hardwareunterstützung für AES in Kombination mit DCO laufen, der Handshake sollte sicher, schnell und kompakt laufen, die Authentisierung gegen einen LDAP-Server erfolgen.

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:

Mentoren: Wolf Müller

WebAuthn/FIDO2

[MS]

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)?

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:

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:

Mentoren: Wolf Müller

USB-Pentesting

[PR]

USB-Geräte, welche leichtfertig angesteckt werden können ein beachtliches Risiko für die Sicherheit des jeweiligen Rechners darstellen. Was kann man mit solchen Geräten erreichen, welche Abwehrmechanismen gibt es? Probieren Sie es aus, zwei Geräte haben wir für unseren Workshop beschafft:

Links:

Mentoren: Wolf Müller

Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=W2025-ITS&oldid=15235"