Zum Hauptinhalt springen

5. Sicherheitsüberlegungen

5. Sicherheitsüberlegungen​

Dieses Dokument beschreibt eine Methode zur Etablierung von SRTP-Schlüsseln mittels DTLS. Die Sicherheitseigenschaften der endgültigen SRTP-Sitzung werden durch die Kombination von DTLS und SRTP bestimmt.

5.1 Sicherheit des DTLS-Handshakes​

Die Sicherheit des Schlüsselmaterials hängt vollständig von der Sicherheit des DTLS-Handshakes ab. Wenn ein Angreifer den DTLS-Handshake kompromittieren kann (z.B. durch einen Man-in-the-Middle-Angriff), kann er den SRTP-Master-Schlüssel erhalten und den gesamten SRTP-Verkehr authentifizieren und entschlüsseln.

Daher ist es kritisch, dass:

  1. Die DTLS-Implementierung sicher und frei von Schwachstellen ist
  2. Starke Cipher-Suiten verwendet werden
  3. Die Endpunkte die Zertifikate der jeweils anderen ordnungsgemäß authentifizieren
  4. Die Zertifikate ordnungsgemäß validiert werden

5.2 Paketrouting und Multiplexing​

DTLS-SRTP-Implementierungen MÜSSEN eingehende Pakete ordnungsgemäß demultiplexen zwischen:

  • DTLS-Paketen (Handshake- und Alert-Nachrichten)
  • SRTP-Paketen (verschlüsselte Medien)
  • SRTCP-Paketen (verschlüsselte Kontrolle)
  • STUN-Paketen (NAT-Traversierung)

Das Versäumnis, diese Pakettypen ordnungsgemäß zu unterscheiden, könnte zu Sicherheitslücken führen. Der Demultiplexing-Algorithmus basiert auf dem ersten Byte des Pakets und ist so konzipiert, dass er eindeutig ist.

5.3 Replay-Schutz​

SRTP enthält Mechanismen zum Schutz vor Wiederholungsangriffen. DTLS-SRTP-Implementierungen MÜSSEN jedoch sicherstellen, dass DTLS-Datensatz-Sequenznummern nicht über Rekeying-Operationen hinweg wiederverwendet werden, um Replay-Angriffe zu verhindern.

5.4 Vertraulichkeit und Authentifizierung​

DTLS-SRTP bietet sowohl Vertraulichkeit (durch Verschlüsselung) als auch Authentifizierung (durch Nachrichtenauthentifizierungscodes). Beide Eigenschaften sind für sichere Medienübertragung wesentlich. Implementierungen SOLLTEN NICHT SRTP-Schutzprofile verwenden, die nur eine dieser Eigenschaften bieten, es sei denn, es gibt spezifische Anwendungsanforderungen, die dies rechtfertigen.

5.5 Perfect Forward Secrecy​

DTLS kann Perfect Forward Secrecy (PFS) bieten, wenn geeignete Schlüsselaustausch-Algorithmen verwendet werden (z.B. ephemeres Diffie-Hellman). Wenn PFS wichtig ist, SOLLTEN Implementierungen Cipher-Suiten verwenden, die diese Eigenschaft bieten.

5.6 Identitätsbindung​

Die im DTLS-Handshake authentifizierte Identität SOLLTE kryptographisch an die im Signalisierungskanal verwendete Identität gebunden werden, um verschiedene Formen von Identitätsfehlbindungsangriffen zu verhindern.