Configuring Calling Encryption Between Cisco IP Phones

By Paul Smith

This blog is one of four dealing with the encryption of various Cisco UC devices. This particular piece deals
with setting up encrypted calls between phones on a cluster. The other blogs in this series are Configuring CUCM with Secure LDAP, Configuring Secure Hardware Conferencing, and Configuring a Secure Voice Gateway. The information in the LDAP article stands on its own, but the steps herein must be followed before one can configure any of the items in the last two pieces.

The steps detailed in these blogs may not be the final word on all of the ins and outs of configuring the items. However, we discovered that there are very few, or no, articles dealing with these subjects written by someone who has actually performed the tasks. We, therefore, felt it would be a service to offer information about the steps that worked for us in our specific set of circumstances (particularly since we, apparently, fell into most of the traps).

Again, the following is for phone encryption, but these steps must also be followed first if one plans on configuring secure connections to voice gateways or plans on configuring secure conferencing.

1) Begin by ensuring that the Cisco Certificate Authority Proxy Function service is running on the Publisher, and that the CTL Provider service is running on every node that is also running the CallManager service.

2) Cluster security must be set to “Mixed Mode”. The cluster has 2 security modes, mixed or non-secure. With mixed mode, phones that support encryption, and which are configured for it, will set up encrypted calls between them. Phones that are not set for encryption will work, but will not have encrypted sessions between them. If a phone set for encryption calls a phone not set for encryption, the call will be completed but will not be encrypted.

3) To set the encryption level for the cluster, two “Hardware Security Keys” must first be obtained from Cisco (part number KEY-CCM-ADMIN-K9=). They look like typical USB memory sticks and they always come in pairs.

4) In the Plug-ins area of the CUCM Administration page, download the Cisco CTL Client. Once it’s downloaded, double-click on the file to install it on a PC.

5) Make sure that DNS is configured properly in the cluster and that the DNS name of the servers running the CallManager service are resolvable by the PC running the CTL Client.

6) Run the client. During the process, a prompt will be displayed that states that one of the keys must be plugged into the computer. Once information has been copied to and from the key, a prompt will state that the first key must be removed and the other key must be plugged into the computer. If you have two USB ports on the computer DO NOT insert both keys at the same time. If, at any point, a password is requested for the key, the default is “Cisco123” (case sensitive). Note: If, at any time, another individual set a different password for the keys, do not guess what that password may be. After 15 wrong attempts at guessing the password, the key locks and nothing will unlock it (this is part of the reason the keys come in pairs). If both keys get locked, another pair of keys must be obtained from Cisco.

7) The CTL Client program is easy to run, it’s mostly a “Fill in obvious information, click Next, click Next, click Finish” type of thing. However, one of the tasks that is accomplish by running the program is setting the security mode of the cluster to “Mixed”. This is the only way that Mixed-Mode security can be set. The other task that is accomplished by running the CTL Client is the creation of a CTL file that will be used by the phones for encryption.

8) After the CTL Client program has been run, restart the CallManager service and the TFTP service on every server in the cluster that has the services running.

9) The next thing that must happen is a security profile must be created for each model of phone that will support encrypted conversations. Go to System > Security Profile > Phone Security Profile and click “Add New”.

10) In the “Phone Security Profile Type” drop-down, select the model number of the phone for which a profile needs to be created. Click “Next”.

11) Select the protocol the phone will use (SCCP or SIP) and click “Next”.

12) Give the profile a Name and a Description. The Name will appear on the “Device Security” drop-down when a phone is created. In the “Device Security Mode” drop-down, select “Authenticated” if there is a simple need to authenticate the phone as being a device that’s supposed to attach to the CUCM cluster. Select “Encrypted” if there is a desire to encrypt the RTP and signaling streams to be unrecognizable to anyone who attempts to record and decipher them. We did Encrypted.

13) In the “Authentication Mode” drop-down, the possible selections are “By Authentication String”, “By Null String”, “By Existing Certificate (Precedence to LSC)”, and “By Existing Certificate (Precedence to MIC)”. This dictates how encrypted communication will happen between CUCM and the phone. Using the LSC is the most secure method (realize, however, that the LSC must be first downloaded to the phone using a less secure method which will be detailed below). Set the Authentication Mode and click “Save”.

14) Repeat the above three steps to create a profile for every model phone for which encryption will be configured.

15) The next step is the one that gets the LSC onto the phone. Add a new phone (or go to an existing phone). Initially, the phone will probably be added with no security. But in the area marked “Certificate Authority Proxy Function (CAPF) Information”, hit the drop-down for “Certificate Operation” and select “Install/Upgrade”. In the “Authentication Mode” drop-down, select “By Authentication String”. In the “Authentication String” field, either add a string of numbers, or click the “Generate String” button and allow one to be generated automatically (Note: This step is something that can be done using BAT, but it’s recommended to use the same string throughout). Make sure the “Operation Completes By” setting is for some time in the future. Click Save and Apply.

16) Go to the physical phone itself. Hit the “Settings” button and navigate to the security configuration area (getting to this area on a phone is different from model to model, but the goal is to find the section that mentions the LSC). The status of the LSC should be “uninstalled”. Unlock the phone with a **# and a softkey should appear that reads “Update”. Pressing this softkey will make the phone prompt for an Authorization String. Use the string of numbers that was selected or generated on the phone configuration page. Press the “Submit” softkey.

17) During the LSC download process, the phone should state that it’s updating. Once the download is complete, the phone may reset.  When the procedure is complete, the LSC will be listed as “Installed”.

18) Once installation is accomplished, go back into the phone’s configuration page in CUCM. In the “Protocol Specific Information” area, go to the “Device Security Profile” drop-down and select the secure profile that was configured for that model phone in a previous step. Once this is selected, the “Authentication Mode” (which is grayed out) will change from “By Authentication String” to “By Existing Certificate (Precedence LSC)”. Click Save and Apply. The phone will reset by itself.

19) This is the point where things could get dicey. The phone should come back and register with no problem. However, some phones will be stubborn. It’s sometimes the case that the process needs to be redone beginning with setting the phone’s security profile to non-secure, saving and applying, then setting it back to using the LSC. We haven’t had to delete the LSC and start over, but there are items on Cisco’s NetPro where people claimed they had to do so.

20) If the phone registers it’s probably ready to go. However, to check that the phone has been correctly configured for encryption, make a call between configured phones. If, once the call is answered, a padlock icon shows up next to the caller ID, the call is being encrypted correctly.

21) An important element to remember is the fact that there are some changes that might be made to a cluster which will cause encryption to begin to fail. If encryption has been working on the phones, and the phones suddenly drop their registration after some configuration changes, the suggested first step will be to do a bulk change in the phones to a non-secure profile, just to get them working again. Then, during a maintenance window, rerun the CTL Client. Then set the security profiles back to the ones the phones are supposed to have, set the “Certificate Operation” drop-down to “Install/Upgrade”, make sure the operation has a future date, and Save and Apply.