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.