As much as I whinge about Cisco, I do rather like their Unified Communications Manager product: it’s mature, reasonably stable – I’ve only really known one instance where it corrupted its own database and ate everything, so I’m sure you’ll be fine – and has an excellent feature set. Generally, if during a migration to CUCM you discover an executive assistant requires 74 speed dial buttons with line status indication, broadcast intercom to each building on the corporate campus individually, the ability to listen to the boss’ calls except when it’s the general manager – along with the Simpsons theme as their ringtone, you can do it with CUCM. Plus the licensing drives their own sales reps slowly insane (along with everyone else involved) which brings out a wonderful feeling of schadenfreude if you’re not involved. This is why Cisco is one of the largest enterprise VOIP providers in the world (well, not the sales rep thing, but you get the idea).
Unified Communications Manager is also fantastic because it has top-notch encryption capabilities built in. It’s secure: the NSA and US government uses it, and I’ve had a rep tell me that they have an internal photo of Vladimir Putin using their ruggedised TelePresence VX Tactical video endpoint. It’s easy to set up and manage, and costs all of $500 for the USB tokens you need to set it up (for those that don’t do Cisco VOIP: a deployment for a small/medium enterprise with ~500 staff won’t leave you much change from $300,000, so $500 is nothing).
So: why does no one bother enabling encryption on their shiny new Cisco VOIP system? I’ve never seen anyone do it – I didn’t even know the featureset existed until I stumbled across it about 18 months ago. Why do I care? Well, this is why:
tl;dr version: tapping unencrypted VOIP calls passing over your local network is trivially easy. As in, this easy:
- Open Wireshark
- Capture some RTP packets using ARP spoofing or whatever to grab packets passing over your local switch on the voice VLAN helpfully trunked to your local switchport by your friendly network administrator
- Use your mouse to select the “Telephony” menu and the various options within
- See called numbers and listen to people talking to each other
- Be shocked
Basically, if you work for a large organisation, someone is most likely doing this right now. If you work for an educational institution and you don’t have encryption enabled on your VOIP network, you’re already screwed and you just don’t know it yet. Ah, schadenfreude.
So, you want to turn on encryption. That’s great! It’s really easy. Unfortunately, Cisco tries its best to make it as difficult as possible by writing several hundred pages of complex documentation on the topic; it’s good reference documentation (as in it’s not wrong, out of date, or written by a teenager like many other wonderful Cisco references), but it’s nigh-on impossible to understand if you’re starting out.
So, here’s a quick guide to the basics. I’m going to put a disclaimer in front of this: there are implications to performing the procedure below on a production cluster, and if you’re responsible you should really read the documentation I mention below and understand the concepts and any implications for your setup. That said, it didn’t break anything when I went ahead and deployed the below on my non-production cluster. Note also the procedure below will only enable the infrastructure required to support encryption; to actually enable call encryption across your organisation you must change the security profile on each phone individually (or by using the BAT). Non-secure phones can continue to call secure phones without any change to the user experience, so you can stage the rollout within your organisation if required.
The other issue is that not all phones are compatible with secure calls, and the best Cisco will give you is to check the datasheet for each phone model you have. You’re looking for something like “secure signaling and secure media with AES-128” (from the 7945G datasheet); I believe the 791*G, 793*G, 794*G, 796*G, 797*G models all support security, and obviously the newer 8900 and 9900 series do too.
The other method for determining whether a given model supports security is to navigate to System -> Security -> Device Security Profile in CUCM and find the non-secure profile for the device; if next to “Device Security Mode” you have an option for “Encrypted” then you’re good to go.
Again, if you have handsets that don’t support security, that’s ok – they will still be able to register to the cluster (ie. there will be no change to the user experience), but calls to and from unsupported handsets will drop back to unencrypted mode. Users on handsets that support encryption will get an indication of whether a given call is encrypted via a small padlock that appears in the call info box on the display, and you can configure the system to play a tone when the call begins to alert users if it’s not encrypted.
Anyway, on to the good stuff. This guide was written with CUCM 8.6 as a reference, so things may have changed slightly in other versions.
On your publisher, first verify that your cluster actually is unencrypted: navigate to Cisco Unified CM Administration -> System -> Enterprise Parameters. Your “Cluster Security Mode” parameter should be 0, meaning encryption is not supported. If is set to 1 “mixed-mode”, someone has already enabled encryption on your cluster. Find that person and congratulate them for being awesome.
Get yourself two (or better, three) Cisco Security Administrator Security Tokens (SAST, because yay acronyms!) part no. KEY-CCM-ADMIN-K9= and about $200 each. You will need a minimum of two tokens for the encryption setup, and you’ll need at least one of these to ever make changes to your system-wide encryption configuration in the future. This is why three is advisable: one for your desk drawer, one for the datacentre safe, one to go out with all your passwords in the monthly backup box (you send your password list off-site, right?). The tokens look like this, they’re basically a certificate signed by Cisco’s root certificate authority on a secure device:
Tokens expire after 10 years, so complain to your distributor if like me you receive one that has been sitting in a warehouse for eight years (!) Check the serial number to determine the date of manufacture.
On the cluster Publisher, activate the Certificate Authority Proxy Function (CAPF) service. This handles certificate requests from phones, system-wide security configuration changes and the like: Navigate to Cisco Unified Servicability -> Tools -> Service Activation. Select the Publisher and click Go. Tick Cisco Certificate Authority Proxy Function and click Save.
Navigate to Application -> Plugins. Download and install the Cisco CTL Client for your workstation’s operating system. Admire the modern logos and user interface design. All this application really does is edit the “CTL file”, a signed configuration file stored in TFTP that lists the authorised security tokens, CUCM servers, TFTP servers and a couple of other things in your cluster. Phones download this to ensure the server they’re talking to is legit.
It can’t be forged because of the Magic of Public Key Infrastructure (ie. the phones have a certificate installed at the factory signed by the Cisco Root CA; so do the tokens. When you initialise the certificates on each phone in step #9 below you create a “local” certificate signed by your cluster Publisher, temporarily using the chain of trust from the Cisco Root CA, meaning the phone will only work with your cluster unless it gets reset to factory defaults – so you don’t even have to trust Cisco, much. Because of the chain of trust, only phones out of the Cisco factory will be so authorised). Public Key Infrastructure is cool – when anyone bothers to deploy it properly ;)
Fire up the CTL client and connect it to your CUCM Publisher with an admin username and password when prompted. Hit next. When prompted, you want to place your CUCM cluster into “Mixed mode”. This means it can support both secure and non-secure endpoints simultaneously.
You will be asked to insert your first token. Do so, acknowledge the dialog, then click Add to add the token to the CTL file. You will then see the client go off and query your cluster for subscribers and TFTP servers; when it’s finished it will give you a nice list of the proposed CTL File contents as below. Before you continue, however, you want to add your other tokens. Click – you guessed it – “Add tokens” and do so. When you’re done, click Finish, re-insert token #1 and enter the password when prompted (token passwords are Cisco123. I would advise you do not change this in the interests of future sanity; instead just keep the tokens locked away). The CTL file will then be uploaded to all cluster members.
Restart the Cisco Callmanager and Cisco TFTP services on all cluster members (this will cause an outage, so do it out of hours).
On your publisher: Navigate to Cisco Unified CM Administration -> System -> Enterprise Parameters. Your “Cluster Security Mode” paramter should now be 1 “Mixed-mode”! Give yourself a pat on the back.
Your phones will not however take advantage of the new secure environment until you give them an appropriate security profile. Navigate to System -> Security -> Phone Security Profiles. If you have 7945 phones in your organisation, locate “Cisco 7945 – Standard SCCP Non-Secure Profile” and click Copy (otherwise, find the default profile for a phone you have to hand). Configure the dialog as follows:
- Name: Cisco 7945 – SCCP Secure Profile
- Description: Cisco 7945 – SCCP Secure Profile
- Device Security Mode: Encrypted
- TFTP Encrypted Config: Yes
- Authentication mode: By Existing Certificate (precedence to LSC) – this will use the MIC/Manufacturer Installed Certificate for initial Locally Significant Certificate installation and the LSC for all future authentication/encryption.
- Key size (bits): 2048
- Hit Save
Next, navigate to Device -> Phone and locate yourself a test phone. Under “Certification Authority Proxy Function (CAPF) Information” set the following. Save and reset the phone. The phone will become pretty sluggish – what it’s doing is generating itself a secure certificate (a “Locally Significant Certificate” or LSC in Cisco terms) from the information sent to it by the CAPF service on the cluster Publisher. After about 5-10 minutes, refreshing the page should show the “Certificate Operation Status” is “Upgrade Success” and Certificate Operation has returned to “No pending Operation”. This means your test phone now has a certificate installed that is signed by your CUCM cluster.
Finally, set the device security profile to the “Cisco 7945 – SCCP Secure Profile” you created earlier. This tells the phone to actually use the certificate you asked it to generate for encryption of calls, metadata and configuration. Save the config and restart the phone. When the phone re-registers verify on the device itself Settings -> Security Configuration -> Security Mode is now showing “Encrypted”. Both the MIC (“Manufacturer Installed Certificate”) and the LSC (“Locally Significant Certificate”) should be show to “Installed”.
That’s it! You now have a cluster than supports encryption, and one phone connected to it in a secure fashion. Repeat for one more phone and enjoy the wonder (wonder!) of an encrypted phone call.
To go beyond this (eg. to enable encryption on your gateways, which you absolutely need to do), you really need to brush up on the relevant docs. Here’s your bedtime reading for the next couple of weeks:
- Cisco Unified Communications Manager Security Guide 9.1(1): Encryption Setup for Gateways and Trunks
- Cisco Unified Communications Manager Security Guide 7.0(1): Configuration Tips for Phone Security Profiles
- Cisco Unified Communications Manager Security Guide 7.0(1): Configuring the Cisco CTL Client
- Cisco Unified Communications Manager Security Guide 7.0(1): Using the Certificate Authority Proxy Function
- Cisco Unified Communications Manager Security Guide 7.0(1): Configuring Encrypted Phone Configuration Files
- The relevant Cisco Unity Connection integration documentation on securing connections to CUCM. Note as at late-2012 a bug existed when encryption is deployed with IPv6 for CUCM/Unity Connection 8.6; CUCM uses a link-local source address instead of the globally-routable address when sending packets to the default gateway, which causes delays in call setup.
The rest of the Security Guide is not super relevant, at least for my setup, but YMMV as always. Basic background knowledge of the components of a Public Key Infrastructure will also assist in understanding the Cisco docs.
The moral here is that security here is so easy and cheap that it shouldn’t be optional for any CUCM deployment. Go ahead and test it in your lab and prove me wrong, but it’s so mature at this stage that you should have very few issues. The main problem I can see is the lack of any easy documentation from Cisco on the topic.
In any case, enjoy your new secure cluster!