6. Security Considerations (Sicherheitsüberlegungen)
6. Security Considerations (Sicherheitsüberlegungen)
Die Übertragung von rohen öffentlichen Schlüsseln, wie in diesem Dokument beschrieben, bietet Vorteile durch Verringerung des Overheads bei der drahtlosen Übertragung, da rohe öffentliche Schlüssel von Natur aus kleiner sind als ein ganzes Zertifikat. Es gibt auch Vorteile aus Sicht der Codegröße für das Parsen und Verarbeiten dieser Schlüssel. Die kryptografischen Verfahren zur Verknüpfung des öffentlichen Schlüssels mit dem Besitz eines privaten Schlüssels folgen ebenfalls Standardverfahren.
Die wichtigste Sicherheitsherausforderung besteht jedoch darin, den öffentlichen Schlüssel einer bestimmten Entität zuzuordnen. Ohne eine sichere Bindung zwischen Identifikator und Schlüssel ist das Protokoll anfällig für Man-in-the-Middle-Angriffe. Dieses Dokument geht davon aus, dass eine solche Bindung Out-of-Band (außerband) erfolgen kann, und wir führen einige Beispiele in Section 1 auf. DANE [RFC6698] bietet einen solchen Ansatz. Um diese Schwachstellen zu beheben, müssen Spezifikationen, die die Erweiterung verwenden, angeben, wie der Identifikator und der öffentliche Schlüssel gebunden sind. Zusätzlich zur Sicherstellung, dass die Bindung Out-of-Band erfolgt, muss eine Implementierung auch den Status dieser Bindung überprüfen.
Wenn öffentliche Schlüssel unter Verwendung von DANE erhalten werden, werden diese öffentlichen Schlüssel über DNSSEC authentifiziert. Die Verwendung vorkonfigurierter Schlüssel ist eine weitere Out-of-Band-Methode zur Authentifizierung roher öffentlicher Schlüssel. Während vorkonfigurierte Schlüssel nicht für eine generische webbasierte E-Commerce-Umgebung geeignet sind, sind solche Schlüssel ein vernünftiger Ansatz für viele Bereitstellungen intelligenter Objekte, bei denen eine enge Beziehung zwischen der auf dem Gerät ausgeführten Software und dem serverseitigen Kommunikationsendpunkt besteht. Unabhängig vom gewählten Mechanismus für die Out-of-Band-Validierung öffentlicher Schlüssel muss vor Beginn einer Bereitstellung eine Bewertung des geeignetsten Ansatzes vorgenommen werden, um die Sicherheit des Systems zu gewährleisten.
Ein Angreifer könnte versuchen, den Handshake-Austausch zu beeinflussen, damit die Parteien andere Zertifikatstypen auswählen, als sie normalerweise wählen würden.
Für diesen Angriff muss ein Angreifer aktiv eine oder mehrere Handshake-Nachrichten ändern. Wenn dies geschieht, berechnen Client und Server unterschiedliche Werte für die Handshake-Nachrichten-Hashes. Als Ergebnis werden die Parteien die Finished-Nachrichten des anderen nicht akzeptieren. Ohne das master_secret kann der Angreifer die Finished-Nachrichten nicht reparieren, sodass der Angriff entdeckt wird.