Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

Cisco IP Phones can be configured to use secure media exchange in a CUCM deployment.
As shown in Figure 16-23, SRTP is used to encrypt the Real-Time Transport Protocol (RTP)
payload and to authenticate the complete RTP packet. The payload contains the actual digital
content of the audio voice. By these means, SRTP provides integrity, authenticity, and
confidentiality of the RTP packet so that the packets cannot be modified while they are in
transit or listened to.
Figure 16-23 Secure Media Exchange Overview
442 Chapter 16: Implementing Security in CUCM
If an attacker modifies, removes, or adds SRTP packets, the receiver detects this manipulation
because of the missing or incorrect authentication data. If an attacker captures SRTP
packets for later or immediate playback, the encrypted payload ensures that the extracted
voice stream will just be noise.
SRTP is standards-based (RFC 3711, The Secure Real-Time Transport Protocol) and is an
application-layer encryption method that performs inside-payload encryption in which the
protocol headers do not change. Because the headers in RTP and SRTP are the same, an
attacker who sniffs the conversation does not know whether the RTP stream has been
encrypted when examining the packet header only. Only further analysis of the sniffed
packets and an attempt to play them back can let the attacker know whether the audio has
been encrypted.
SRTP cannot be used for packet authentication alone. It supports authentication and
encryption only.
SRTP Protection
As previously mentioned, media streams are encrypted by using SRTP CUCM generates
the SRTP session keys for media authentication and media encryption and sends them to
the IP Phones inside signaling messages.
If signaling messages carrying SRTP session keys are not protected, an attacker could
easily learn the SRTP keys just by sniffing the signaling messages. To ensure protection of
the key distribution, CUCM requires authenticated and encrypted signaling to be used with
SRTP. Therefore, SRTP cannot be used with IP Phones that are not configured or that do
not support the use of authenticated and encrypted signaling.
As stated earlier, encrypted packets in CUCM always have to be signed to ensure the
authenticity of the source and the content of the packets.
In fact, CUCM supports only two device security modes (except for the nonsecure device
security mode):
• Authenticated: This mode provides authenticated signaling only (TLS SHA-1).
• Encrypted: This mode provides authenticated and encrypted signaling (TLS SHA-1
and TLS AES) and authenticated and encrypted media transfer (SRTP SHA-1 and
SRTP AES).
Secure Media Transmission Between Cisco IP Phones 443
SRTP Packet Format
As shown in Figure 16-24, the SRTP packet header is nearly identical to the RTP packet
header.
Figure 16-24 SRTP Packet Format
The RTP payload differs only in the sense that it is not cleartext voice but encrypted voice.
In addition to the encrypted payload, a 32-bit SHA-1 authentication tag is added to the
packet, which adds a few bytes to its size. The authentication tag holds the first 32 bits of
the 160-bit SHA-1 hash digest that was computed from the RTP header and the encrypted
voice payload ("truncated fingerprint").
As shown in the figure, the RTP packet header and the RTP payload of encrypted voice are
authenticated. Therefore, RTP encryption is performed before RTP authentication.
NOTE The SRTP Master Key Index (MKI) shown in the figure is optional and is not
used in secure IP telephony.
SRTP Encryption
Figure 16-25 illustrates the process of SRTP encryption.
444 Chapter 16: Implementing Security in CUCM
Figure 16-25 SRTP Encryption
The sender encrypts the RTP payload by using the AES algorithm and the AES key that it
received from CUCM when the call was set up. The receiver then uses the same AES key
also received from CUCM to decrypt the RTP payload.
NOTE If a packet capture of an SRTP audio stream is taken with a protocol analyzer
such as Wireshark, the content can actually be saved as an .avi file and played back in an
audio player such as Windows Media Player. However, the sound plays back as
randomized white noise, completely unrecognizable.
SRTP Authentication
Figure 16-26 illustrates the process of SRTP authentication.
The sender hashes the RTP header and the RTP payload together with the SHA-1 key it
received from CUCM when the call was set up. Then the first 32 bits of the hash digest are
added to the RTP packet, and the packet is then sent to the receiver.
Finally, the receiver uses the same SHA-1 key, also received from CUCM, to verify the hash
digest.
NOTE Cisco IP telephony endpoints always encrypt and authenticate RTP packets.
These two processes of encryption and authentication have been illustrated separately
only for purposes of explanation.
Secure Media Transmission Between Cisco IP Phones 445
Figure 16-26 SRTP Authentication
Secure Call Flow Summary
When encryption is enabled, the following sequence occurs when a call is placed between
two IP Phones creating a secure call flow:
1. The IP Phones and CUCM exchange certificates.
2. The IP Phones and CUCM authenticate each other by requesting some random data to
be signed. When this process is finished, CUCM and the IP Phones know that the other
devices are authentic.
3. Each IP Phone creates TLS session keys. One key will be used for TLS SHA-1
authentication; the other key will be used for TLS AES encryption.
4. Each IP Phone encrypts the generated keys with the public key of CUCM and sends
the encrypted keys to CUCM.
5. Each IP Phone now shares its session keys with CUCM. At this stage, each phone can
exchange signaling messages with CUCM over an authenticated and encrypted TLS
session.
6. When the call is established between the two SCCP IP Phones, CUCM creates SRTP
session keys. One key is used for SRTP SHA-1 authentication, and the other key is
used for SRTP AES encryption. Different keys are used for each direction. In the case
of SIP phones, the phones generate session keys. However, they are again exchanged
via CUCM because no direct signaling connection exists between the phones.
7. CUCM sends the generated SRTP session keys to both IP Phones over the secured TLS
session.
446 Chapter 16: Implementing Security in CUCM
The IP Phones now share the session keys for authenticating and encrypting their RTP
packets. At this stage, the two IP Phones can start secure media exchange.
Configuring IP Phones to Use Secure Signaling and Media Exchange
To configure Cisco IP Phones to support authenticated or encrypted calls, in CUCM choose
Device > Phones and select a phone, as shown in Figure 16-27.
Figure 16-27 Configuring IP Phones to Use Secure Signaling and Media Exchange
After CUCM is configured for mixed mode and the Cisco IP Phones have certificates,
configure the IP Phones to support authenticated or encrypted calls. The device security
mode is used to configure a Cisco IP Phone for one of three security modes:
• Non-secure: The IP Phone does not support authenticated or encrypted calls.
• Authenticated: The IP Phone supports authenticated calls.
• Encrypted: The IP Phone supports encrypted calls.
The default device security mode is configured by using phone security profiles, as shown
in the figure.
CAUTION In several situations, cryptographic services for Cisco IP Phones should not
be used. With some Cisco Unified Contact Center applications, for instance, cleartext
signaling messages or media packets have to be seen by other devices such as attached
PCs. Another example is the use of Network Address Translation (NAT) or Port Address
Translation (PAT). Because the translating device has to see cleartext signaling messages
to be able to dynamically allow the negotiated UDP ports that will be used for RTP,
encryption cannot be used.
Secure Media Transmission to H.323 and MGCP Gateways 447
The Actual Security Mode Depends on the Configuration of Both Phones
The actual security mode that is used for a call depends on the configuration of both IP
Phones participating in the call, as shown in Table 16-1.
As shown in the table, these rules apply:
• If one device is set to Non-secure, an insecure call without authentication and without
encryption is placed. This is the same level of nonsecurity in CUCM without PKI.
• If both devices are set to Encrypted, an encrypted call with both authentication and
encryption is placed.
• In all other situations, if both IP Phones are set to Authenticated or if one is set to
Authenticated and the other is set to Encrypted, an authenticated call with
authentication only is placed.
NOTE If one phone is set to Authenticated and the other is set to Non-secure, the endto-
end call is not considered to be authenticated, because only one phone uses
authenticated signaling to CUCM.