Digital Signature Standard

20 Mar

Digital Signature Standard
Digital Signature Standard (DSS) is defined by the Federal Information Processing Standards Publication 186. Cisco implements DSS, which is used for peer router authentication and to protect data from undetected change. This standard specifies a Digital Signature Algorithm (DSA) for applications that require a digital signature as opposed to a written signature. The DSA signature is a pair of large numbers represented in a computer as strings of binary digits. The digital signature is computed using a set of rules and a set of parameters such that the identity of the signature and integrity of the data can be verified. The DSA provides the capability to generate and verify
signatures. Signature generation makes use of a private key. Signature verification makes use of a public key that corresponds to, but is not the same as, the private key. Each user possesses a private and public key pair. Public keys can be known by anyone and shared with anyone, but private keys are never shared. Anyone can verify the signature of a user by employing that user’s public key. Signature generation can be performed only by the possessor of the user’s private key.

The algorithm relies on the MD5 hash function to verify the authenticity of the data sent. The hash function is equivalent to taking a “fingerprint” of the message. If two fingerprints match, the message has not been altered in transit, and if the two fingerprints do not match, the message has been altered in transit. The hash is run through a function that uses the private key to sign the message and is reversible only if you have the public key. The peer runs the same hash and verifies the signature to determine the identity and content of the message.

Cisco Encryption Technology Overview
Cisco Encryption Technology (CET) is a proprietary Network layer encryption process that encrypts the data payload of an IP packet. Special portions of the IP header, for instance the UDP and TCP portions, are not encrypted. This allows the packet to be successfully routed through the internetwork. Only IP packets can be encrypted. The actual encryption and decryption of IP packets occur only at routers that you configure for CET. Such routers are considered to be peer routers. Intermediate routers do not participate in the encryption or decryption process. CET features include the following:

CET allows for granularity in the specification of which packets are encrypted. Packets needing to be encrypted can be defined with the configuration of an extended access list.

DSS is used to provide authentication.
Diffie−Hellman is used to manage each session’s key.
DES is used to provide confidentiality (encryption).

Peer router authentication occurs during the setup of each encrypted session. Prior to peer router authentication, DSS public and private keys must be generated for each peer and the DSS public keys must be exchanged with each peer. This allows peer routers to authenticate each other at the start of encrypted communication sessions. The generation and exchange of DSS keys occurs only once on a per−peer basis, and afterward, these DSS keys will be used each time an encrypted session occurs. To be successfully exchanged, DSS public keys must be verified via a trusted source at the location of each encryption peer. This usually occurs via a phone call and is called
“voice authentication.” During the exchange process, one peer is configured to be the “passive” and the other peer is configured to be the “active” peer.

Each peer router’s DSS keys are unique: a unique DSS public key and a unique DSS private key. DSS private keys are stored in a private portion of the router’s NVRAM, which cannot be viewed. If you have a router with an Encryption Service Adapter (ESA), DSS keys are stored in the tamper−resistant memory of the ESA. The DSS private key is not shared with any other device. However, the DSS public key is distributed to all other peer routers. You must cooperate with the peer router’s administrator to exchange public keys between the two peer routers, and you and the other administrator must verbally verify to each other the public key of the other router. When an
encrypted session is being established, each router uses the peer’s DSS public key to authenticate the peer.

Prior to a router passing encrypted data to a remote peer, an encrypted session needs to be established. This is determined when the router receives a packet that matches a permit statement, which determines whether or not encryption should take place for this packet. To establish a session, peer encryption routers must exchange connection messages. This allows each router to authenticate each other. Authentication is accomplished by attaching “signatures” to the connection messages: A signature is a character string that is created by each local router using its own DSS private key and verified by the remote router using the local router’s DSS public key. A signature is always unique to the sending router and cannot be forged by any other device. When a signature is verified, the router that sent the signature is authenticated. A temporary session key is also generated during the exchange of connection messages; it is the key that will be used to actually encrypt data during the encrypted session. To generate the session key, Diffie−Hellman numbers must be exchanged in the connection messages. Then, the Diffie−Hellman numbers are used to compute a common DES session key that is shared by both routers.

After both peer routers are authenticated and the session key has been generated, data can be encrypted and transmitted. The DES encryption algorithm is used with the DES key to encrypt and decrypt IP packets during the encrypted session. After the session times out, because no packets match a permit statement within the configured access list, the encrypted session is terminated. When the session terminates, both the DH numbers and the DES key are discarded. When another encrypted session is required, new DH numbers and DES keys will be generated.

The process for configuring Cisco’s proprietary encryption technology on routers consists of four major tasks:

1.Prepare for Cisco Encryption by identifying the peer routers and choosing an encryption policy between both peers. The network topology should also be taken into consideration during this stage. The typical network topology used for encryption is a hub−and−spoke arrangement between an enterprise router and branch routers. Other things to consider during this stage are frequent route changes between pairs of peer encrypting routers and load−balancing, which will cause excessive numbers of connections to be set up and very few data packets to be delivered.

2.Each router involved in the process of encrypting packets between one another must be prepared to perform encryption. This is done through a series of configuration commands that will be discussed later.

3.After preparing each router to perform encryption, you much establish an encrypted session between each peer to pass encrypted packets.

4.The final task is to test and verify the configuration and operation of CET. This is done through the use of certain show and debug commands. These same commands are also used during troubleshooting of CET.

Random Posts

No comments yet

Leave a Reply

You must be logged in to post a comment.