Cisco IOS Image Security
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Overview
The previous article talked about the different Cisco IOS image types, the image file-naming structure, and the different ways an engineer can update/upgrade the IOS on a Cisco device. This article continues with this subject area and discusses some methods to ensure that the image is complete and has not been modified. The second part of this article discusses the digitally signed software feature that is possible with the newest Cisco 19xx, 29xx, and 39xx platforms (a feature that will most likely be supported on other platforms in the future).
Cisco Image Verification
You can use two different methods to verify the integrity of a Cisco IOS image. The first verifies that a file has been transferred successfully from a server to a device. The image itself may have been altered from the time that it was originally downloaded from Cisco. (It is verifying an embedded message digest 5 [MD5] hash to a computed hash.) The second type of verification uses the MD5 algorithm to calculate a checksum that can be verified directly with Cisco. The only complication (sometimes) that comes with the MD5 method of verification is that it requires an Internet connection to the Cisco website to obtain the original MD5 checksum value. Figure 1 shows how Cisco CCO can be used to find the original MD5 of an image.
)
Figure 1 Cisco CCO Software Page
Table 1 shows the command required to perform these two types of verification.
| 1 | Verify a Cisco IOS image. |
router#verify [/md5 [md5-value] ] filesystem : [file-url] Use the md5 keyword to show only the current MD5 checksum of the specified file. If it is not specified in the original command, it will be prompted for. The md5-value is optional when using the md5 keyword. If supplied, it is used to verify the supplied checksum with the calculated checksum of the specified file. The filesystem: [file-url] is optional and is used to specify the image file location to be verified. If it is not specified, it will be prompted for. |
Figures 2 and 3 show what the beginning and the ending of the “standard” verification looks like. As you can see, it provides both a verification of the embedded checksum and outputs the MD5 checksum of the image that can be verified with Cisco. The CCO hash and the MD5 checksum shown in Figure 1 should match.
)
Figure 2 Beginning of Standard Verification
)
Figure 3 End of Standard Verification
When the engineer is interested in performing only the second part of verification, the md5 keyword can be used when using the MD5 hash comparison with Cisco CCO. Figure 4 shows the output from this version of the command when the md5 keyword is used by itself. Figure 5 shows the output from this version of the command when both the md5 and the md5-value are used.
)
Figure 4 Verifying Using the /md5 Keyword
)
Figure 5 Verifying Using the /md5 Keyword and the md5-value
Digitally Signed Cisco Software
With some of the newer platforms (at the moment, 19xx, 29xx, and 39xx), it is now possible to use images that have been digitally signed by Cisco. This type of facility offers companies yet another chance to ensure that the code that is being put into service on a device has not been altered from its original. This ability is especially important for those who have to comply with the Federal Information Processing Standard (FIP)-140-3draft. With this revision, it will become a requirement for software to be digitally signed and be verified for authenticity and integrity prior to load or execution.
Cisco signed images use different extensions than previous images. The type of software that has been signed and the key version used to sign it are each signified in the extension used. The rules shown in Table 1 can be followed to find out this information.
Table 1 - File Extension Meanings
| File Extension Character | File Extension Letter |
Description |
First |
S |
The first character is always set to S and stands for digitally signed software. |
Second |
P or S |
The second character is set to P when the image is for production. It is set to S when the image is for special, which is Cisco’s way of signifying something in development. |
Third |
A, B, Cā¦ |
The third letter is used to signify the key version that has been used to sign the image. The key version will start at A and go up as key versions change. |
Key Revocation and Replacement
The revocation and replacement of a Cisco signing key is required only if the key is being replaced (or expires) or if the Cisco Public Key Infrastructure (PKI) is somehow compromised. In either event, a process of key revocation and replacement is required. There are two different pieces of the key revocation and replacement process depending on the type of key that is being revoked.
If a production key is being replaced, a revocation and production image are used. A revocation image is a basic version of a normal image and functions to add a new production key into the device’s key storage area.
If a special key is being replaced, a production image is used. The production image is signed by a production key, which is then imported.
Summary
Although it is true that many engineers (including myself) have used images that were not directly verified with Cisco, it is an important tool that you should use to verify the authenticity of the image, especially before using it in a production environment. The process is not all that confusing or hard and does not take a lot of time to perform. The new digitally signed images offer yet another feature that can be used by engineers and organizations to ensure that the images have been delivered without being altered and have been correctly signed by Cisco. At least one of these features should be used for any image destined for production devices. At very least, this offers cheap insurance to ensure that the image was transferred from Cisco to the device without some amount of corruption occurring.