Reference11r1:Concept DTLS-SRTP: Difference between revisions

From innovaphone wiki
Jump to navigation Jump to search
(10 intermediate revisions by 3 users not shown)
Line 11: Line 11:
=== SDES ===
=== SDES ===


In order to understand the advantages of DTLS-SRTP let's go one step back and take a look SDES - the standard key exchange method for SRTP. SDES transmits the secret keys as part of the signalling messages. That messages go from one endpoint over several PBXes to the other endpoint, hop-by-hop. As the secret keys have to be proteced from eavesdropping the signalling messages have to be encrypted as well. But the signalling messages are only encrypted hop-by-hop, so each PBX can see or even modify the keys.
In order to understand the advantages of DTLS-SRTP let's go one step back and take a look SDES - the standard key exchange method for SRTP. SDES transmits the secret keys as part of the signalling messages. That messages go from one endpoint over several PBXes to the other endpoint, hop-by-hop. As the secret keys have to be protected from eavesdropping the signalling messages have to be encrypted as well. But the signalling messages are only encrypted hop-by-hop, so each PBX can see or even modify the keys.


[[Image:Srtp key exchange sdes.png]]
[[Image:Srtp key exchange sdes.png]]


It is a design problem of SDES that endpoints have to trust the PBXes. This is a managable risk when all PBXes are under control of the customer. But with internet calls across company boundaries it becomes an actual threat. Possible attacks include corrupted signaling nodes that give away the keys together with the call details to an attacker that is then capable of decrypting captured SRTP calls on a large scale.
It is a design problem of SDES that endpoints have to trust the PBXes. This is a manageable risk when all PBXes are under control of the customer. But with internet calls across company boundaries it becomes an actual threat. Possible attacks include corrupted signalling nodes that give away the keys together with the call details to an attacker that is then capable of decrypting captured SRTP calls on a large scale.


=== DTLS-SRTP ===
=== DTLS-SRTP ===
Line 25: Line 25:
The protocol does not rely on the trustability of the certificates that are used for DTLS. They are just considered as a container format for the public key of the remote endpoint.
The protocol does not rely on the trustability of the certificates that are used for DTLS. They are just considered as a container format for the public key of the remote endpoint.


Instead fingerprints are used to allow users for manually checking if the call is encrypted end-to-end. In this context a fingerprint is a hash value calculated over the certificate. Each endpoint sends the fingerprint of its own certificate to the remote party over the signalling. The VOIP stack checks if the remote fingerprint actually matches the certificate that was used for DTLS. If not the call is disconnected right away. Users that need end-to-end encryption can read the fingerprints that are displayed on the phone and compare them to the fingerprints that are displayed on the other phone. If they match, end-to-end-encryption is running for this call. If the fingerprints do not match, it means the call is decrypted and encrypted again somewhere in the middle. For example this happens with media relay, ISDN legs or when there is an actual man-in-the middle attack.
Instead fingerprints are used to allow users for manually checking if the call is encrypted end-to-end. In this context a fingerprint is a hash value calculated over the certificate. Each endpoint sends the fingerprint of its own certificate to the remote party over the signalling. The VOIP stack checks if the remote fingerprint actually matches the certificate that was used for DTLS. If it is not, the call is disconnected right away. Users that need end-to-end encryption can read the fingerprints that are displayed on the phone and compare them to the fingerprints that are displayed on the other phone. If they match, end-to-end-encryption is running for this call. If the fingerprints do not match, it means the call is decrypted and encrypted again somewhere in the middle. For example this happens with media relay, ISDN legs or when there is an actual man-in-the-middle attack.


=== Pros and cons ===
=== Pros and cons ===
Line 38: Line 38:
* Adds an additional delay at the begin of calls
* Adds an additional delay at the begin of calls
* Causes significantly higher CPU load at the begin of calls
* Causes significantly higher CPU load at the begin of calls
* Less SRTP Cipher available, what means lower encryption level on the Media compared to SDES that could have a SRTP Cipher with AES 256/80.


==Configuration==
==Configuration==
=== Priority of SDES and DTLS-SRTP ===
=== Priority of SDES and DTLS-SRTP ===
If nothing is configured, the device offers both SDES and DTLS-SRTP for outgoing calls. For incoming calls it selects SDES if offered. Otherwise it selects DTLS-SRTP or unencrypted RTP, as a fallback. This allows for compatibility with most endpoints.
If nothing is configured, the device offers both SDES and DTLS-SRTP for outgoing calls. For incoming calls it selects SDES if offered. Otherwise it selects DTLS-SRTP or unencrypted RTP, as a fall-back. This allows for compatibility with most endpoints.


The admin can change that behaviour at the configuration of the registration. There the key exchange mechanisms (SDES, DTLS-SRTP) and their priority can be selected. For example on phones this is can be done on page Phone/User/General. Please consult the help pages for details.
The admin can change that behaviour at the configuration of the registration or interface. There the key exchange mechanisms (SDES, DTLS-SRTP) and their priority can be selected. For example on phones this can be done on page Phone/User/General. Please consult the help pages for details.


=== Certificates ===
=== Certificates ===
No special configuration is needed regarding certificates. DTLS-SRTP does not require endpoints to have the certificate of the remote endpoint in the trust list. Also it doen't check the names inside certificates.
No special configuration is needed regarding certificates. DTLS-SRTP does not require endpoints to have the certificate of the remote endpoint in the trust list. Also it doesn't check the names inside certificates.
 
=== Disabling DTLS-SRTP ===
For debugging purposes there are config options at the signalling modules that globally turn DTLS-SRTP off. Normally this should not be needed.
 
  config add H323 /dtls-disabled
  config add SIP /dtls-disabled
  config add TSIP /dtls-disabled
  config add SIPS /dtls-disabled


==Tracing==
==Tracing==
Line 66: Line 59:


=== Reading traces ===
=== Reading traces ===
When creating an offer for a call DTLS-SRTP is initialized for both SRTP and SRTCP. The <code>Initialized</code> lines show the local fingerprints.
  DTLS.SRTP.0: Initialize
  DTLS.SRTP.0: Initialized fingerprint=447af6c5cfe3b66cf0901d9143f6824d4c5d0ba2ee8bd9d0ed9b9f69680277d0
  DTLS.SRTCP.0: Initialize
  DTLS.SRTCP.0: Initialized fingerprint=447af6c5cfe3b66cf0901d9143f6824d4c5d0ba2ee8bd9d0ed9b9f69680277d0
If DTLS is selected as the key exchange mechanism by the signalling protocol, DTLS is connected in the client or server role. A successful connection flow starts with the <code>Connect</code> line that shows the local role and the remote fingerprint. It is followed by a sequence of sent and received messages. When the connection was established successfully, the trace shows a <code>Connected</code> line followed by a <code>Use SRTP</code> line that shows the negotiated cipher suite.
  DTLS.SRTP.0: Connect CLIENT options=4 fingerprint=447af6c5cfe3b66cf0901d9143f6824d4c5d0ba2ee8bd9d0ed9b9f69680277d0
  DTLS.SRTP.0: Add ClientHello extension "use_srtp" (AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32, no MKI)
  DTLS.SRTP.0: Write ClientHello
  DTLS.SRTCP.0: Connect CLIENT options=4 fingerprint=447af6c5cfe3b66cf0901d9143f6824d4c5d0ba2ee8bd9d0ed9b9f69680277d0
  DTLS.SRTP.0: Read HelloVerifyRequest
  DTLS.SRTP.0: Write ClientHello
  DTLS.SRTP.0: Read ServerHello
  DTLS.SRTP.0: Read ServerHello extension "use_srtp"
  DTLS.SRTP.0: Read Certificate
  DTLS.SRTP.0: Read CertificateRequest
  DTLS.SRTP.0: Read ServerHelloDone
  DTLS.SRTP.0: Write Certificate
  DTLS.SRTP.0: Calculate ClientKeyExchange
  DTLS.SRTP.0: Write ClientKeyExchange
  DTLS.SRTP.0: Sign CertificateVerify
  DTLS.SRTP.0: Write CertificateVerify
  DTLS.SRTP.0: Write ChangeCipherSpec
  DTLS.SRTP.0: Write Finished
  DTLS.SRTP.0: Buffer ChangeCipherSpec
  DTLS.SRTP.0: Buffer handshake message of next epoch 1
  DTLS.SRTP.0: Read ChangeCipherSpec
  DTLS.SRTP.0: Read Finished
  DTLS.SRTP.0: Store session e1a6cafeadcae22a79eef9994613114a000fed7400000001
  DTLS.SRTP.0: Connected
  DTLS.SRTCP.0: Unpause
  DTLS.SRTCP.0: Add ClientHello extension "use_srtp" (AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32, no MKI)
  DTLS.SRTCP.0: Try resume session e1a6cafeadcae22a79eef9994613114a000fed7400000001
  DTLS.SRTCP.0: Write ClientHello
  DTLS.SRTP.0: Use SRTP "AES_CM_128_HMAC_SHA1_80"
  DTLS.SRTCP.0: Read HelloVerifyRequest
  DTLS.SRTCP.0: Write ClientHello
  DTLS.SRTCP.0: Buffer ChangeCipherSpec
  DTLS.SRTCP.0: Buffer handshake message of next epoch 1
  DTLS.SRTCP.0: Read ServerHello
  DTLS.SRTCP.0: Read ServerHello extension "use_srtp"
  DTLS.SRTCP.0: Resume session e1a6cafeadcae22a79eef9994613114a000fed7400000001
  DTLS.SRTCP.0: Read ChangeCipherSpec
  DTLS.SRTCP.0: Read Finished
  DTLS.SRTCP.0: Write ChangeCipherSpec
  DTLS.SRTCP.0: Write Finished
  DTLS.SRTCP.0: Connected
  DTLS.SRTCP.0: Use SRTP "AES_CM_128_HMAC_SHA1_80"
There are some trailing <code>Timeout</code> and <code>Ignore record</code> lines. They reflect retransmissions that are done to be robust to packet loss and can be ignored.
  DTLS.SRTCP.0: Timeout
  DTLS.SRTP.0: Ignore record (unexpected epoch 0)
If the connection fails for some reason the trace shows an error followed by a <code>Close</code> line.
  DTLS.SRTP.0: Disconnect (fingerprint mismatch)
  DTLS.SRTP.0: Close error=4


== Specifications ==
== Specifications ==
Line 83: Line 138:


== Known limitations ==
== Known limitations ==
* In v11r1 the phones do not display DTLS fingerprints, yet.


== References ==
== References ==
* [http://tools.ietf.org/html/rfc5764 RFC5764] - Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
* [http://tools.ietf.org/html/rfc5764 RFC5764] - Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)

Revision as of 14:49, 18 February 2016


Applies To

This information applies to

  • all innovaphone devices from v11r1 RC2

Overview

SRTP is a standard for encrypting RTP media streams. Before two endpoints can do that encryption they need to exchange secret keys. DTLS-SRTP is a new method how to do so.

SDES

In order to understand the advantages of DTLS-SRTP let's go one step back and take a look SDES - the standard key exchange method for SRTP. SDES transmits the secret keys as part of the signalling messages. That messages go from one endpoint over several PBXes to the other endpoint, hop-by-hop. As the secret keys have to be protected from eavesdropping the signalling messages have to be encrypted as well. But the signalling messages are only encrypted hop-by-hop, so each PBX can see or even modify the keys.

Srtp key exchange sdes.png

It is a design problem of SDES that endpoints have to trust the PBXes. This is a manageable risk when all PBXes are under control of the customer. But with internet calls across company boundaries it becomes an actual threat. Possible attacks include corrupted signalling nodes that give away the keys together with the call details to an attacker that is then capable of decrypting captured SRTP calls on a large scale.

DTLS-SRTP

DTLS-SRTP was designed to solve that issue. It does not transmit the keys in signalling messages but inband as part of the media stream using end-to-end encryption. Before the media stream starts both endpoints perform a mutual DTLS handshake on the media ports. The shared symmetric key that was established for the resulting DTLS session is then used to derive an SRTP key. Then the encrypted SRTP media stream is started.

Srtp key exchange dtls srtp.png

The protocol does not rely on the trustability of the certificates that are used for DTLS. They are just considered as a container format for the public key of the remote endpoint.

Instead fingerprints are used to allow users for manually checking if the call is encrypted end-to-end. In this context a fingerprint is a hash value calculated over the certificate. Each endpoint sends the fingerprint of its own certificate to the remote party over the signalling. The VOIP stack checks if the remote fingerprint actually matches the certificate that was used for DTLS. If it is not, the call is disconnected right away. Users that need end-to-end encryption can read the fingerprints that are displayed on the phone and compare them to the fingerprints that are displayed on the other phone. If they match, end-to-end-encryption is running for this call. If the fingerprints do not match, it means the call is decrypted and encrypted again somewhere in the middle. For example this happens with media relay, ISDN legs or when there is an actual man-in-the-middle attack.

Pros and cons

At a glance DTLS-SRTP offers the following advantages:

  • End-to-end encryption
  • Detection of man-in-the-middle attacks
  • No need to trust PBXes
  • No need to trust certification authorities

On the other hand there are also some negative aspects:

  • Adds an additional delay at the begin of calls
  • Causes significantly higher CPU load at the begin of calls
  • Less SRTP Cipher available, what means lower encryption level on the Media compared to SDES that could have a SRTP Cipher with AES 256/80.

Configuration

Priority of SDES and DTLS-SRTP

If nothing is configured, the device offers both SDES and DTLS-SRTP for outgoing calls. For incoming calls it selects SDES if offered. Otherwise it selects DTLS-SRTP or unencrypted RTP, as a fall-back. This allows for compatibility with most endpoints.

The admin can change that behaviour at the configuration of the registration or interface. There the key exchange mechanisms (SDES, DTLS-SRTP) and their priority can be selected. For example on phones this can be done on page Phone/User/General. Please consult the help pages for details.

Certificates

No special configuration is needed regarding certificates. DTLS-SRTP does not require endpoints to have the certificate of the remote endpoint in the trust list. Also it doesn't check the names inside certificates.

Tracing

Activation

Traces for debugging DTLS-SRTP can be activated at the signalling module. The trace flags are also available on the debug.xml page.

config add H323 /dtls-trace on
config add SIP /dtls-trace on
config add TSIP /dtls-trace on
config add SIPS /dtls-trace on

Reading traces

When creating an offer for a call DTLS-SRTP is initialized for both SRTP and SRTCP. The Initialized lines show the local fingerprints.

 DTLS.SRTP.0: Initialize
 DTLS.SRTP.0: Initialized fingerprint=447af6c5cfe3b66cf0901d9143f6824d4c5d0ba2ee8bd9d0ed9b9f69680277d0
 DTLS.SRTCP.0: Initialize
 DTLS.SRTCP.0: Initialized fingerprint=447af6c5cfe3b66cf0901d9143f6824d4c5d0ba2ee8bd9d0ed9b9f69680277d0

If DTLS is selected as the key exchange mechanism by the signalling protocol, DTLS is connected in the client or server role. A successful connection flow starts with the Connect line that shows the local role and the remote fingerprint. It is followed by a sequence of sent and received messages. When the connection was established successfully, the trace shows a Connected line followed by a Use SRTP line that shows the negotiated cipher suite.

 DTLS.SRTP.0: Connect CLIENT options=4 fingerprint=447af6c5cfe3b66cf0901d9143f6824d4c5d0ba2ee8bd9d0ed9b9f69680277d0
 DTLS.SRTP.0: Add ClientHello extension "use_srtp" (AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32, no MKI)
 DTLS.SRTP.0: Write ClientHello
 DTLS.SRTCP.0: Connect CLIENT options=4 fingerprint=447af6c5cfe3b66cf0901d9143f6824d4c5d0ba2ee8bd9d0ed9b9f69680277d0
 DTLS.SRTP.0: Read HelloVerifyRequest
 DTLS.SRTP.0: Write ClientHello
 DTLS.SRTP.0: Read ServerHello
 DTLS.SRTP.0: Read ServerHello extension "use_srtp"
 DTLS.SRTP.0: Read Certificate
 DTLS.SRTP.0: Read CertificateRequest
 DTLS.SRTP.0: Read ServerHelloDone
 DTLS.SRTP.0: Write Certificate
 DTLS.SRTP.0: Calculate ClientKeyExchange
 DTLS.SRTP.0: Write ClientKeyExchange
 DTLS.SRTP.0: Sign CertificateVerify
 DTLS.SRTP.0: Write CertificateVerify
 DTLS.SRTP.0: Write ChangeCipherSpec
 DTLS.SRTP.0: Write Finished
 DTLS.SRTP.0: Buffer ChangeCipherSpec
 DTLS.SRTP.0: Buffer handshake message of next epoch 1
 DTLS.SRTP.0: Read ChangeCipherSpec
 DTLS.SRTP.0: Read Finished
 DTLS.SRTP.0: Store session e1a6cafeadcae22a79eef9994613114a000fed7400000001
 DTLS.SRTP.0: Connected
 DTLS.SRTCP.0: Unpause
 DTLS.SRTCP.0: Add ClientHello extension "use_srtp" (AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32, no MKI)
 DTLS.SRTCP.0: Try resume session e1a6cafeadcae22a79eef9994613114a000fed7400000001
 DTLS.SRTCP.0: Write ClientHello
 DTLS.SRTP.0: Use SRTP "AES_CM_128_HMAC_SHA1_80"
 DTLS.SRTCP.0: Read HelloVerifyRequest
 DTLS.SRTCP.0: Write ClientHello
 DTLS.SRTCP.0: Buffer ChangeCipherSpec
 DTLS.SRTCP.0: Buffer handshake message of next epoch 1
 DTLS.SRTCP.0: Read ServerHello
 DTLS.SRTCP.0: Read ServerHello extension "use_srtp"
 DTLS.SRTCP.0: Resume session e1a6cafeadcae22a79eef9994613114a000fed7400000001
 DTLS.SRTCP.0: Read ChangeCipherSpec
 DTLS.SRTCP.0: Read Finished
 DTLS.SRTCP.0: Write ChangeCipherSpec
 DTLS.SRTCP.0: Write Finished
 DTLS.SRTCP.0: Connected
 DTLS.SRTCP.0: Use SRTP "AES_CM_128_HMAC_SHA1_80"

There are some trailing Timeout and Ignore record lines. They reflect retransmissions that are done to be robust to packet loss and can be ignored.

 DTLS.SRTCP.0: Timeout
 DTLS.SRTP.0: Ignore record (unexpected epoch 0)

If the connection fails for some reason the trace shows an error followed by a Close line.

 DTLS.SRTP.0: Disconnect (fingerprint mismatch)
 DTLS.SRTP.0: Close error=4

Specifications

Fingerprints

innovaphone devices create SHA256 fingerprints. But from remote parties innovaphone devices also accept the following fingerprint types:

  • MD5
  • SHA1
  • SHA224
  • SHA256
  • SHA384
  • SHA512

SRTP cipher suites

The following cipher suites are supported with DTLS-SRTP:

  • SRTP_AES128_CM_HMAC_SHA1_80 (preferred)
  • SRTP_AES128_CM_HMAC_SHA1_32

Unencrypted RTP is never negotiated using DTLS-SRTP.

Known limitations

  • In v11r1 the phones do not display DTLS fingerprints, yet.

References

  • RFC5764 - Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)