dtls-fuzzer ist ein Java-Tool, das Protokollzustands-Fuzzing von DTLS-Servern durchführt. Konkret unterstützt es die folgenden Funktionen:

1. Gegeben ein Alphabet kann es automatisch ein Modell einer lokalen DTLS-Serverimplementierung generieren;
2. Gegeben einen Test (Eingabensequenz) und ein Alphabet kann es den Test auf einer DTLS-Serverimplementierung ausführen;
3. Es kann eine Batch-Lernaufgabe mit mehreren Lernläufen durchführen.

dtls-fuzzer verwendet [TLS-Attacker][tlsattacker], um DTLS-Nachrichten zu generieren/zu parsen sowie den Zustand zu verwalten. Zu diesem Zweck wurde TLS-Attacker um Unterstützung für DTLS erweitert. dtls-fuzzer verwendet [Version 3.0b][tlsattackerver] von TLS-Attacker, einer Version, die die DTLS-Erweiterung implementiert.

Inhalt des Artefakts

Das Artefakt enthält:

1. eine Beschreibung der Dateistruktur von dtls-fuzzer, einschließlich Quellcode und experimenteller Daten, die mit den im Papier dargestellten übereinstimmen;
2. eine Schritt-für-Schritt-Anleitung zur Evaluierung von dtls-fuzzer auf einer ausgewählten SUT (System Under Test)/DTLS-Serverimplementierung.

Dateistruktur von dtls-fuzzer

Die wichtigsten Ordner im Stammverzeichnis von dtls-fuzzer sind:

1. 'src', Verzeichnis mit dem Java-Quellcode von dtls-fuzzer;
2. 'examples', Verzeichnis mit Beispielen für Alphabete, Tests, Spezifikationen (d.h. Modelle) und Argumentdateien, die dtls-fuzzer zum Starten von Lernversuchen bereitgestellt werden können. Dateien in diesem Verzeichnis werden als Eingaben für Lernversuche verwendet;
3. 'experiments', Verzeichnis mit Daten zu Experimenten. Einige dieser Daten dienen auch als Eingabe für Lernversuche. Die wichtigsten Ordner sind:
   1. 'suts', mit Binärdateien für Java-SUTs. Diese SUTs sind maßgeschneiderte DTLS-Serverprogramme, deren Quellcode öffentlich verfügbar ist;
   2. 'patches', Patches, die auf einige SUTs (insbesondere auf Hilfsprogramme) angewendet wurden, bevor der Quellcode kompiliert wurde. Der Hauptzweck dieser Patches war es, zeitgesteuertes Verhalten während des Lernens zu verhindern, Funktionen in der SUT zu aktivieren/deaktivieren und Parameter wie den vorab geteilten Schlüssel zu konfigurieren;
   3. 'keystore', Schlüsselmaterial (z.B. öffentlich-private Schlüsselpaare, Java-Keystores), das beim Lernen verwendet wird;
   4. 'results', experimentelle Ergebnisse.

Experimentelle Ergebnisse

'experiments/results' enthält experimentelle Ergebnisse, die die Hauptausgabe der Arbeit darstellen. Im Einzelnen

• 'all_ciphers' enthält Ausgabeordner für alle durchgeführten Experimente;
  • 'mapper' enthält experimentelle Ergebnisse, die einige der getroffenen Mapper-Entscheidungen rechtfertigen (siehe Abschnitt 5.2)
• 'included' enthält Ausgabeordner für konvergierende Experimente (Konvergenz bedeutet, dass das Lernen erfolgreich ein Modell generiert).
  • Beachten Sie, dass nicht alle Experimente in 'all_ciphers' erfolgreich waren/mit einem endgültigen Modell abgeschlossen wurden (wir sagen in solchen Fällen, dass das Lernen nicht konvergiert ist).

Ausgabeordner

Ausgabeordner werden basierend auf der Experimentkonfiguration benannt, d.h.:

• die getestete SUT/Implementierung;
• das verwendete Alphabet, bezogen auf die abgedeckten Schlüsselaustauschalgorithmen, wobei 'all' anzeigt, dass alle 4 Schlüsselaustauschalgorithmen verwendet wurden;
• wo zutreffend, ob eine Client-Zertifizierung erforderlich (req), optional (nreq) oder deaktiviert (none) war;
• der Testalgorithmus: Random Walk (rwalk) oder eine Anpassung davon (stests);
  • Experimente mit der Anpassung wurden nicht in das Papier aufgenommen
• optional, ob Wiederholungen in den Ausgaben enthalten sind oder nicht (incl oder excl).
  • Wiederholungen waren standardmäßig enthalten

Als Beispiel: Der Ordnername 'jsse-12_rsa_cert_none_rwalk_incl' zeigt ein Experiment mit der JSSE 12-Implementierung von DTLS an, wobei ein Alphabet verwendet wird, das Eingaben zur Durchführung von RSA-Handshakes enthält, die Client-Zertifikatsauthentifizierung deaktiviert ist, der Testalgorithmus Random Walk ist und Wiederholungen enthalten sind.

Ein Ausgabeordner enthält:

• 'alphabet.xml', das Eingabealphabet;
• 'command.args', die verwendete Argumentdatei, die verschiedene Experimentparameter enthält, insbesondere:
  • queries, die Grenze für die Anzahl der Random-Walk-Tests, die bestanden werden müssen, damit eine Hypothese als endgültig angesehen wird
  • equivalenceAlgorithms, modellbasierte Testalgorithmen, die eingesetzt werden
  • runWait und timeout, die Start- bzw. Antwort-Timeout (wir werden später darauf eingehen)
• 'sul.config', SUT-abhängige Konfiguration für TLS-Attacker; dieselbe Konfiguration kann verwendet werden, um Workflow-Traces auf der SUT mit TLS-Attacker allein auszuführen;
• 'hyp[0-9]+.dot', Zwischenhypothesen;
• 'statistics.txt', Experimentstatistiken wie die Gesamtzahl der Tests, Lernzeit;
  • Tabelle 4 zeigt diese Daten
• 'nondet.log', Logs von aufgetretenem nicht-deterministischem Verhalten;
• 'learnedModel.dot', falls das Lernen konvergiert ist, das gelernte Modell (d.h. die endgültige Hypothese);
• 'error.msg', eine Fehlermeldung, die generiert wird, falls das Experiment fehlgeschlagen/das Lernen gestoppt wurde und daher nicht zu einem endgültigen Modell konvergiert ist.
  • der Hauptgrund ist zeitbezogener Nichtdeterminismus (gleiche Eingaben führen zu unterschiedlichen Ergebnissen).

Der Evaluator kann (beispielsweise) überprüfen, ob experimentelle Ergebnisse in 'included' mit denen in Tabelle 4 übereinstimmen, oder ob Konfigurationen, die in Tabelle 2 getestet wurden, auch in 'all_ciphers' vorkommen. Beachten Sie, dass Modelle, die im Papier erscheinen, das Ergebnis eines erheblichen Pruning/Trimmens waren, während die Modelle in den Ausgabeordnern unverändert sind.

Evaluierungsschritte für dtls-fuzzer

Zum Zweck der Evaluierung von dtls-fuzzer müssen die folgenden Schritte durchgeführt werden:

1. Sicherstellen, dass die Voraussetzungen erfüllt sind
2. dtls-fuzzer installieren
3. SUT einrichten
4. dtls-fuzzer verwenden, um Modelle für die SUT zu generieren
5. Ergebnisse analysieren

Auf diesen Evaluierungsabschnitt folgt ein Leitfaden zur Verwendung von dtls-fuzzer, der seine Hauptanwendungsfälle vorstellt.

Sicherstellen der Voraussetzungen

dtls-fuzzer wurde auf Ubuntu 18.04 und Debian 9-Distributionen von Linux getestet. Es sollte auf jeder aktuellen Linux-Distribution funktionieren. Unterstützung für andere Plattformen wurde nicht getestet. Diese Anleitung geht von einer Debian-basierten Distribution aus (die 'apt-get' hat).

Eine Java 8 JDK (Java Development Kit) Virtual Machine (VM) wird benötigt. Die Version, die zum Ausführen der Experimente verwendet wurde, ist 1.8.0_222, obwohl spätere Java 8-Versionen ebenfalls funktionieren sollten. Beachten Sie, dass das Tool nicht auf Java 9 oder später gebaut werden kann. Wir verwenden auch Maven (das 'mvn'-Dienstprogramm) für das Abhängigkeitsmanagement/die Bereitstellung.

Wir empfehlen die Verwendung eines ausreichend leistungsfähigen Rechners, da sonst empfindliche Zeitparameter wie die Wartezeit auf Antwort zu niedrig werden könnten, was zu anderen Ausgaben als den im Papier erhaltenen führt. Schlimmer noch, sie können dazu führen, dass Lernversuche fehlschlagen. Die ursprünglichen Experimente wurden auf einem Server mit vielen Kernen durchgeführt, wir erwarten jedoch (obwohl nicht gründlich getestet), dass Lernen auf einem Desktop mit einem i7-Prozessor möglich sein sollte. Lernen ist auch auf schwächeren Systemen möglich, wenn die Zeitparameter entsprechend angepasst werden. Schließlich erfordert das Visualisieren von .dot-Modellen durch Exportieren als .pdf die Installation der [graphviz-Bibliothek][graphviz]. Es wird davon ausgegangen, dass das von graphviz bereitgestellte 'dot'-Dienstprogramm im System-PATH liegt.

Kurz gesagt, die empfohlenen Voraussetzungen sind: