TFTP Encrypted Configuration Files Overview
Warning |
If you have enabled the digest authentication option for SIP phones and disabled the TFTP encrypted configuration option, the digest credentials are sent in the cleartext. |
After TFTP configuration, the TFTP server:
-
Deletes all the cleartext configuration files on disk
-
Generates encrypted versions of the configuration files
If the phone supports encrypted phone configuration files and you have performed the tasks for phone configuration file encryption, the phone requests an encrypted version of the configuration file.
Some phones don't support encrypted phone configuration files. The phone model and protocol determine the method that the system uses to encrypt the configuration file. Supported methods rely on Unified Communications Manager functionality and a firmware load that supports encrypted configuration files. If you downgrade the phone firmware load to a version that doesn't support encrypted configuration files, the TFTP server offers an unencrypted configuration file that provides minimal configuration settings, and the phone may not perform as expected.
Encryption Key DistributionTo ensure that you maintain the privacy of the key information, we recommend that you perform the tasks that are associated with encrypted phone configuration files in a secure environment.
Unified Communications Manager supports the following methods:
-
Manual key distribution
-
Symmetric key encryption with a phone public key
The setup information provided for manual key distribution and symmetric key encryption with a phone public key assume that you have configured mixed mode and enabled the TFTP Encrypted Config option in Cisco Unified CM Administration.
Manual Key Distribution
With manual key distribution, a 128- or 256-bit symmetric key, which is stored in the Unified Communications Manager database, encrypts the phone configuration file after the phone resets. To determine the key size for your phone model.
To encrypt the configuration file, the administrator can either manually enter the key into or prompt Unified Communications Manager to generate the key in the Phone Configuration window. After the key exists in the database, the administrator or user must enter the key into the phone by accessing the user interface on the phone; the phone stores the key in flash as soon as you press the Accept softkey. After the key is entered, the phone requests an encrypted configuration file after it is reset. After the required tasks occur, the symmetric key uses RC4 or AES 128 encryption algorithms to encrypt the configuration file. To determine which phones use the RC4 or AES 128 encryption algorithms, see Phone Models That Support Encryption.
When the phone contains the symmetric key, the phone always requests the encrypted configuration file.Unified Communications Manager downloads the encrypted configuration file to the phone, which the TFTP server signs. Not all phone types validate the signer of the configuration file.
The phone decrypts the file contents by using the symmetric key that is stored in flash. If decryption fails, the configuration file does not get applied to the phone.
Tip |
If the TFTP Encrypted Config setting gets disabled, administrators must remove the symmetric key from the phone GUI, so the phone requests an unencrypted configuration file the next time that it is reset. |
Symmetric Key Encryption with Phone Public Key
If the phone contains a manufacturing-installed certificate (MIC) or a locally significant certificate (LSC), the phone contains a public and private key pair, which are used for PKI encryption.
If you are using this method for the first time, the phone compares the MD5 hash of the phone certificate in the configuration file to the MD5 hash of the LSC or MIC. If the phone does not identify a problem, the phone requests an encrypted configuration file from the TFTP server after the phone resets. If the phone identifies a problem, for example, the hash does not match, the phone does not contain a certificate, or the MD5 value is blank, the phone attempts to initiate a session with CAPF unless the CAPF authentication mode equals By Authentication String (in which case, you must manually enter the string). The Certificate Authority Proxy Function (CAPF) authenticates Cisco IP Phones to Unified Communications Manager and issues phone certificates (LSCs). CAPF extracts the phone public key from the LSC or MIC, generates a MD5 hash, and stores the values for the public key and certificate hash in the Unified Communications Manager database. After the public key gets stored in the database, the phone resets and requests a new configuration file.
After the public key exists in the database and the phone resets, the symmetric key encryption process begins after the database notifies TFTP that the public key exists for the phone. The TFTP server generates a 128-bit symmetric key, which encrypts the configuration file with the Advanced Encryption Standard (AES)128 encryption algorithm. Then, the phone public key encrypts the symmetric key, which it includes in the signed envelope header of the configuration file. The phone validates the file signing, and, if the signature is valid, the phone uses the private key from the LSC or MIC to decrypt the encrypted symmetric key. The symmetric key then decrypts the file contents.
Every time that you update the configuration file, the TFTP server automatically generates a new key to encrypt the file.
Tip |
For phones that support this encryption method, the phone uses the encryption configuration flag in the configuration file to determine whether to request an encrypted or unencrypted file. If the TFTP Encrypted Config setting is disabled, and Cisco IP Phones that support this encryption method request an encrypted file (.enc.sgn file), Unified Communications Manager sends a 'file not found error' to the phone. The phone then requests an unencrypted, signed file (.sgn file). If the TFTP Encrypted Config setting is enabled but the phone requests an unencrypted configuration file for some reason, the TFTP server offers an unencrypted file that contains minimal configuration settings. After the phone receives the minimum configuration, the phone can detect error conditions, such as key mismatch, and may start a session with CAPF to synchronize the phone public key with the Unified Communications Manager database. If the error condition is resolved, the phone requests an encrypted configuration file the next time that it resets. |