Security in Tcl Scripts for Cisco IOS
- Introduction to PKI Infrastructure
- Using Digital Signatures to Sign a Tcl Script
- Tcl Script-Failure Scenario
- Scaling Tcl Script Distribution
- Summary
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter covers the following topics:
- Introduction to PKI Infrastructure
- Using Digital Signatures to Sign a Tcl Script
- Tcl Script-Failure Scenario
- Scaling Tcl Script Distribution
From the early days of programming, those with nefarious intent have attempted—and in many cases successfully integrated—additional code into programs that have caused serious consequences to the unsuspecting user. Because a Tcl script is a program running on an IOS-based device, additional code added to the script could potentially send passwords via e-mail, erase the saved configurations or IOS images, cause the device to reload periodically, and so on. The capability to protect scripts against this type of attack is paramount!
Cisco IOS Software Release 12.4(15)T introduced a new feature to improve security for Tcl scripts. The purpose of this security feature is to provide a method for signing a Tcl script that proves the script has not been modified since the time it was signed by the author. It relies on techniques and methods of existing public key cryptography libraries.
Introduction to PKI Infrastructure
Public key infrastructure (PKI) is used to provide a scalable method for certificate/key exchange and is commonly used for secure exchange data (confidentiality), to ensure that the data has not been modified in transit (integrity), to authenticate the origin, and for nonrepudiation.
PKI enables you to send messages with confidentiality and sign messages that are guaranteed to be genuine. Confidentiality allows for conducting secret communication via a public channel; however, it is not needed because the Tcl script is not secret and can be viewed by anyone who has access.
Even though confidentiality is not needed, we do require Tcl scripts to have a digital signature to guarantee they are truly genuine and have not been tampered with. PKI enables you to generate a digital signature that is connected to the Tcl script and guarantees it is genuine.
Because PKI is well established, it can be leveraged to provide the security needed for signing Tcl scripts. Many applications already take advantage of PKI and leverage the security it provides, including SSL/HTTPS, IPsec, and S/MIME. You are probably familiar with purchasing items online, filing tax returns online, and software licensing, all of which use PKI and secure protocols.
Using PKI will provide assurance that a script has not been tampered with and give you the confidence to implement a signed script in a production environment.
PKI Prerequisite
To use PKI, a public/private key pair must first be established. Generally, the longer the key, the higher the level of security provided by that key.
A private key is simply a long string of characters, typically 512. As the name indicates, this key is not to be shared and must always be kept private.
The public key is public and distributed to anyone.
The public/private key pairs are simple to generate and the private key is (nearly) impossible to derive from the public key. Although any security algorithm can be broken given enough time and CPU cycles, longer keys make this task infeasible.
Confidentiality with PKI
When sending messages through a public channel, you can use PKI to encrypt the data so that only the intended recipient can decrypt it. The sender of an encrypted message can encrypt the data but cannot decrypt the data after it has been encrypted. The recipient's public key is used to encrypt the data. The data is sent to the recipient, and once it is received is decrypted with the recipient's private key. This process is unidirectional. For two-way encrypted communication to occur, two key pairs are needed. Each sender encrypts data using the correct public key of the intended recipient. This process is also referred to as asymmetric encryption.
As shown in Figure 7-1, Alice will be sending Bob an encrypted message. The process is as follows:
- Step 1. For Alice to send any encrypted information to Bob, she must have Bob's public key.
- Step 2. Alice uses Bob's public key to encrypt the message she wants to send to Bob.
- Step 3. Even if someone captures the information in transit, it is undecipherable without Bob's private key, or at least a tremendous number of CPU cycles used to break the private key.
- Step 4. When Bob receives the information, he uses his own private key to decrypt the original message that Alice sent.
)
Figure 7-1 PKI Infrastructure
Digital Signatures with PKI
Digital signatures enable you to ensure that information is not altered in transit from sender to recipient. You can do so by creating a hash or signature of the original data.
The entire message must remain intact. Even if 1 bit of the data is changed, the entire message integrity is violated. When you sign a check, for example, you are verifying the authenticity with your unique signature. If the amount of the check is changed from your written and numeric values, this represents an obvious violation.
To provide the integrity check, the entire data being sent is run through a hashing function. In simple terms, the hashing function produces a unique result for any given input data, of a known length. Common hashing functions include message digest 4 (MD4), message digest 5 (MD5), and secure hash algorithm (SHA). The hashed data result can be sent using the PKI confidentiality process described earlier. In this way, the message integrity is preserved from sender to recipient.
Figure 7-2 shows how Alice can send a message with a digital signature:
- Step 1. Alice runs the original message through a hash function, creating a unique value.
- Step 2. Alice encrypts the hash value with her private key, resulting in the digital signature.
- Step 3. The signature is attached to the message.
)
Figure 7-2 Signing Digital Signatures
Figure 7-3 shows how Bob can verify the integrity of a message.
- Step 1. For Bob to verify that Alice is indeed the originator of the message, Bob must have Alice's public key.
- Step 2. Bob will extract the signature from the message.
- Step 3. The message will be hashed using the same process that Alice used, and a result will be generated.
- Step 4. The signature will also be decrypted using Alice's public key, and a hash value will be generated.
- Step 5. Bob will then compare the message hash value to the signature value. If they match, Bob can be reasonably certain that the message is unaltered.
)
Figure 7-3 Verifying Digital Signatures