Showing results for 
Search instead for 
Did you mean: 

USB eTokens really required to implement security in CUCM?

Hi all,

any chance somebody can clarify to me why do we really need USB eTokens? Let's say I want to configure encrypted signaling (and maybe media) between my IP phones inside local network. I know from Microsoft world that you can create all this without buying some "secret" gadgets. I'm the network admin and therefore the supreme authority for that same network. Shouldn't be normal that I can use my CUCM and generate self-signed certificate and then create CTL file and LSC etc without using USB eTokens? Every document I was able to find on CCO is telling me that those USB sticks are required. Is this really the case?




Yes they really are required and you must have at least two of them. There is nothing secret about them; they are hardware-based cryptography tokens that hold the private key and sign the CTL file "inside" the crypto chip.


Does it mean I can't implement encrypted calls without eTokens? Seems to me huge limitation for the solution if compared with other vendors...


Yes that's what it means. Just order the part (quantity two of KEY-CCM-ADMIN-K9=); they are only $300 USD list price so this isn't a big deal.

Regardless, don't go galavanting into encrypted calls without carefully reading the security guide and other related documentation. Enabling mixed mode is a fair amount of work to maintain, takes a sizeable performance hit on things like DSPs, and doesn't solve all security problems by itself.


The new SKU is KEY-UCM-ADMIN2-K9=, and as Jonathan says must order two of them.



Thank you for your help. Is there any data sheet or document for further information?




CTL file can be created only with the aid of usb tokens and you need atleast two of them. The same token we can use for multiple clusters as well.


By default CUCM 8.5 has ITL file only.



Afsal Abdul Gafoor


It is now possible to generate a software-only eToken and enable mixed mode through the CLI. This was done for the Department of Defense because Aladdin, now SafeNet, moved manufacturing of the hardware token overseas which isn't allowed for certain high security uses.

Having said that, my recommendation is to continue using the hardware tokens because it results in tighter control over the root certificate private keys. Keeping the root certificate (i.e. the token in this case) offline and inaccessible is considered a best practice with certificate authorities. Even Microsoft recommends this when building out a PKI. The software token places the private key as a file on the OS filesystem. The private key is effectively a game of capture-the-flag: get to it and it's game over.


PS- If your instinctive response is to roll your eyes at this then you shouldn't bother enabling mixed mode. If you don't take private key protection seriously then adding this overhead isn't worth it.