Configuring Calling Encryption Between Cisco IP Phones

This blog is one of five 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 Calling Encryption Between Cisco IP Phones and Cisco Unity Connection, 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).

Comments are certainly welcome, and we will be happy to update these blogs if need be.

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 it 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.The first job it asks you to do is set the cluster’s security mode to “Mixed”.  This is the only way that Mixed-Mode security can be set.  The other task that’s accomplished by running the CTL client is the creation of a CTL file that will be used by the phones for encryption, but that happens in the background.  When everything has been created, you’ll see a screen that shows the devices that will be affected.  At that point, make sure that all servers running the CallManager service and all servers running the TFTP service show up in the window.  If they don’t you can click a button to add them.  You can also click a button to add more security keys to the pool that will work on your cluster…just in case you messed up on the previous step (ask me how I know).  The next thing the client will ask for is that password for the key.  Enter it, and you’re done.
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 first be 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 in which the download will be manually completed.  If you’re not going to finish all of the downloads until Wednesday, make sure the “Operation Completes By” setting reflects that.  If you try to do the downloads on Thursday, you won’t be able to do so until you reset what’s in those fields. 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 manually entered or automatically 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 from beginning by 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, 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.