Die Methoden der Softwareentwicklung sind immer im Umbruch, denn die IT-Absatzmärkte ändern sich rapide und erfordern Projekt-Ansätze, die schneller vorzeigbare Ergebnisse zeitigen. Als Folge fordern Software-Entwickler höhere Abstraktionsgrade und hinterfragen Technologiegrenzen. Testroutinen hingegen sind immer integraler Bestandteil eines professionellen Software-Entwicklungsprozesses und ihr steigender Automatisierungsgrad reflektiert den Trend zu kürzeren Entwicklungszyklen1).
Qualitätssicherung in der Softwareentwicklung hat viele Aspekte [siehe ISO/IEC 25000ff] und unabhängig davon, wie man an das Thema herangeht (z.B. mit Fokus auf Prozessqualität oder Vorgehensmodelle) stellt Testen ein wichtiges Element dar [siehe ISO/IEC/IEEE 29119]. Es ist ebenso unverzichtbar wie Lastenhefte [siehe IEEE 29148-2011], Code- und Dokumenten-Repositories2) oder schlichte Ticketsysteme.
Weiterlesen →
Tests für Krypto-Software
Zur Illustration werden aus der Dokumentation für das Sicherheits-Connectivityprodukt HOB RDVPN nachfolgend einige Testfall- und Testablaufspezifikation sowie die Testprotokolle beleuchtet. Während zur vollständigen Testsuite sowohl funktionale- als auch nicht-funktionale3)-Tests gehören, werden hier nur Funktionstests besprochen.
Jeder Test enthält eine detaillierte Beschreibung des Aufbaus und Ablaufs, das erwartete Ergebnis und das tatsächlich erzielte Resultat. Gegebenenfalls kommen ergänzende Kommentare hinzu, die Entwicklung oder Dokumentation unterstützen.
Im Bereich der kryptographischen Software sind funktionale Tests auf verschiedenen Ebenen unverzichtbar:
- Kryptographische Online-Module – diese Tests stellen sicher, dass die Ver- und Entschlüsselungsalgorithmen die gewünschten Ergebnisse liefern
- Unterstützungsfunktionen – diese Software ist nicht in Verbindungen aktiv, liefert aber wesentliche Beiträge zur Sicherheit des Kryptosystems. Dazu gehören Zufallszahlengeneratoren, Formatierungsroutinen, Import/Exportfunktionen und Schlüsselverwaltung
- Protokollmaschine – Auf/Abbau und Kontrolle der Verbindung tragen wesentlich zu ihrer Sicherheit bei
Kunden von Verschlüsselungssoftware erwarten, dass die Produkte nachweislich gegen die häufigsten Angriffstypen schützen bzw. bekannte Schwachstellen abfangen – daher gehören solche Tests ebenfalls in das Prüfprogramm.
Als Referenzen dienen stets öffentlich zugängliche Dokumentationen und Prüfprogramme von Behörden und Organisationen wie dem National Institute of Standards in Technology (NIST) oder dem Bundesamt für Sicherheit in der Informationstechnik (BSI) oder weit verbreitete Implementierungen wie OpenSSL.
Testszenario und Umgebung
Die gezeigten Auszüge beziehen sich auf ein Einsatzszenario, das aus dem betriebssystemabhängig implementierten Hochleistungs-Proxy mit einem Java-basierten Browser-Client besteht. Dazu kommt ein Zertifikats-Verwaltungstool, welches separat betrieben wird. Diese Konfiguration wurde vom BSI nach ISO/IEC 15408 (Common Criteria v3.1) EAL 4+ zertifiziert.
Die Testdokumentation beginnt mit der technischen Definition von Szenarien und Umgebungen. Aufgrund des Produktdesigns wird eine ganze Palette gebräuchlicher Betriebssysteme auf Serverseite geprüft, während auf der Gegenseite zahlreiche Browser mit Java-Environments kombiniert werden.
Tests der kryptographischen Online-Module
Der Begriff "Online-Module" wurde gewählt um zu verdeutlichen, dass diese Routinen aktiv an Verbindungen beteiligt sind. Sie müssen daher nicht nur fehlerfrei arbeiten, sondern auch ressourcen-schonend sein, also speichersparend und schnell.
Die Prüfungen umfassen alle in den Cipher Suites angebotenen Algorithmen, wie z.B. SHA-256 oder RSA. Textbeispiel 2 zeigt einen Auszug aus dem Aufbau des AES-Tests. Deutlich ersichtlich ist die Bezugnahme auf Referenzquellen, hier das NIST.
Textbeispiel 2: Testaufbau AES-Modulprüfung
Tests der Unterstützungsfunktionen
Obwohl sie eine große Sicherheitsrelevanz besitzt wird diese Kategorie von Modulen zuweilen weniger sorgfältig geprüft als angemessen wäre. Besonderes Augenmerk verdient der (Pseudo-) Zufallszahlengenerator und hier speziell die Methode zur Gewinnung seines "möglichst zufälligen" Startparameters ("seed", oft fälschlich mit "Entropie" gleichgesetzt4)).
Speziell wenn auf den Einsatz von Hardware Security Module (HSMs5)) verzichtet werden soll bzw. muss (insbesondere clientseitig) oder Abstraktionslayer wie Java oder Hypervisoren den Durchgriff auf Umweltparameter unterbinden wird dies zur Herausforderung. Eine gebräuchliche Methode ist dann die Auswertung und Kombination verschiedener messbarer Größen wie Zustandswerten, Umweltverhalten (z.B. Paketlaufzeiten, Latenzen) oder Benutzereingaben ("Bewegen Sie die Maus…"). Die sinnvolle Zusammenstellung und Nutzung von Entropie-Quellen zur Erzeugung des "seed" ist alles andere als trivial und HOB verwendet größte Sorgfalt darauf.
Der Prüfung der Qualität von Zufallszahlen erfolgt mit Hilfe eines Referenztools des BSI.
Eine weitere wichtige Hilfsfunktion ist die Zertifikats- (Ketten-) Prüfung, die zahlreiche Fälle wie Ablauf und Ungültigkeit von Zertifikaten oder fehlerhafte Zwischenzertifikate abdeckt.
Textbeispiel 4 zeigt die Beschreibung des Aufbaus:
Textbeispiel 4: Testaufbau Zertifikatskettenprüfung
In den zugehörigen Testablaufspezifikationen wird gefordert, dass speziell fremdgenerierte Zertifikate (und Ketten) geprüft werden und welche Ergebnisse zu erwarten sind. Dieses Vorgehen wurde mit Bedacht gewählt und gehört zu den Interoperabilitätstests, die für Kommunikationssoftware typisch sind.
Prüfungen der Protokollmaschine
Die protokollkonforme Sitzungssteuerung ist für die Sicherheit einer TLS-Kommunikation ebenso wichtig wie die Qualität der Implementierung der Algorithmen. Daher wird auch hier mit großer Sorgfalt die Interoperabilität und Normtreue des Produktes geprüft.
Im Textbeispiel 6 wird der Testaufbau mit zwei weit verbreiteten Gegenstellen aus quelloffener Software beschrieben. Da ein kompletter Verbindungsaufbau erfolgt, checkt dieser Test "als Nebeneffekt" die Zertifikatsprüfung und die in der Cipher Suite definierten Krypto-Module mit.
Textbeispiel 6: Interoperabilitätstest
Schwachstellen- und Angriffstests
Zu den Routinetests bei der Erstellung von kryptographischer Qualitätssoftware gehört die Prüfung auf Resistenz gegen die gängigsten Angriffstypen.
Der Aufbau in Textbeispiel 7 zeigt einen Proxy, der den Datenstrom modifiziert. Diese Software wurde speziell für Testzwecke entwickelt und kann verschiedenste Fehler- und Angriffstypen simulieren. Der grau hinterlegte Textbereich zeigt einen Auszug aus diesen Prüfungen.
Textbeispiel 7: Angriffs- und Fehlersimulation per Proxy
Weiterhin umfassen die Testszenarien Schwachstellentests wie den POODLE-Angriff, der sich eine ungeschickte Reaktion auf fehlerhaften Verbindungsaufbau zunutze macht6).
Fazit
Durchdachte Tests sind ein Kernelement bei der Software-Qualitätssicherung und Voraussetzung für hochwertige Produkte. Dies gilt speziell für Connectivity-Software, wo Protokolltreue unerlässlich ist, mehr noch bei kryptographischen Produkten, die verschiedensten Angriffen ausgesetzt sind.
Deshalb ist es im Interesse jedes Herstellers solcher Produkte, auf seine Tests nicht nur angemessene Sorgfalt zu verwenden, sondern darüber hinaus Einblick in die damit verbundenen Prozesse und Unterlagen zu gewähren – denn ähnlich wie bei den Verschlüsselungsmechanismen liegt die Sicherheit des Produktes nicht in der Geheimhaltung der Testmethoden, sondern in ihrer öffentlichen Prüfung und Anerkennung.
"The principal objective of software testing is to gain confidence in the software."
P. David Coward
Weiterführende Text
- Uwe Hehn / Franz Graser, "Agiles Testen – Hype oder Methode mit echtem Mehrwert?" (22.11.2011)
- Ralf Gronkowski, "Status quo der Versionskontrolle" (15.10.2013)
- Lawrence Chung, Julio Cesar Sampaio do Prado Leite, "On Non-Functional Requirements in Software Engineering", Kapitel 3 (enthält eine Darstellung zur Klassifizierung)
- NIST Special Publication 800-90A Revision 1, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators" (June 2015), Kapitel 8.6.1
- Johan Ivarsson, Andreas Nilsson, "A Review of Hardware Security Modules" (2010), Kapitel 1.2
- US Computer Emergency Readiness Team CERT, "SSL 3.0 Protocol Vulnerability and POODLE Attack" (17.10.2014)
