Cryptography Basics for CCNA

Cryptography is the practice of securing communication by converting plaintext into ciphertext (encryption) and back (decryption). In networking, it ensures: - Confidentiality: Only authorized parties can read the data. - Integrity: Data hasn't been altered in transit. - Authentication: The sender is who they claim to be. - Non-repudiation: The sender cannot deny sending the message.

For CCNA 200-301, you need to understand how these principles apply to protocols like SSH, IPsec, and TLS. Cisco devices use cryptography for secure remote access (SSH), VPNs (IPsec), and management plane protection.

Symmetric Encryption uses a single shared key for both encryption and decryption. It's fast and efficient for bulk data but has a key distribution problem: how do you securely share the key? Common algorithms include:

Asymmetric Encryption uses a pair of keys: a public key (shared openly) and a private key (kept secret). Data encrypted with one key can only be decrypted with the other. It solves key distribution but is computationally expensive. Common algorithms:

Hashing is a one-way function that produces a fixed-size output (hash) from any input. It's used for integrity verification and password storage. Common algorithms:

Digital Signatures combine hashing with asymmetric encryption. The sender hashes the message and encrypts the hash with their private key. The recipient decrypts the hash with the sender's public key and compares it to a freshly computed hash. If they match, the message is authentic and unaltered.

HMAC uses a shared secret key combined with a hash function to provide integrity and authenticity. Unlike digital signatures, HMAC is symmetric—both sides know the key. It's used in IPsec and TLS. Common HMAC variants: HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256.

Diffie-Hellman (DH) allows two parties to securely agree on a shared symmetric key over an insecure channel. It uses modular exponentiation. The process: 1. Both parties agree on a large prime p and a generator g (public values). 2. Each chooses a private random number (a and b). 3. They compute public values: A = g^a mod p, B = g^b mod p. 4. They exchange A and B. 5. Each computes the shared secret: s = B^a mod p = A^b mod p.

An eavesdropper sees p, g, A, B but cannot compute s without solving the discrete logarithm problem.

PFS ensures that if a long-term private key is compromised, past session keys are not exposed. It's achieved by using ephemeral Diffie-Hellman (DHE or ECDHE) where the DH keys are generated per session and discarded. IPsec with PFS adds an additional DH exchange during rekeying.

To generate an RSA key pair for SSH:

Router(config)# crypto key generate rsa general-keys modulus 2048

To verify:

Router# show crypto key mypubkey rsa

To configure SSH:

Router(config)# ip domain-name example.com
Router(config)# crypto key generate rsa
Router(config)# line vty 0 15
Router(config-line)# transport input ssh
Router(config-line)# login local

To view SSH status:

Router# show ip ssh

For IPsec, you configure ISAKMP (IKE) and IPsec transform sets. Example IKE policy:

Router(config)# crypto isakmp policy 10
Router(config-isakmp)# encryption aes 256
Router(config-isakmp)# hash sha256
Router(config-isakmp)# authentication pre-share
Router(config-isakmp)# group 14
Router(config-isakmp)# lifetime 86400

A large enterprise with hundreds of routers and switches needs to replace Telnet with SSH for remote CLI access. The network engineer configures AAA (TACACS+ or RADIUS) for centralized authentication, but SSH requires RSA keys on each device. On older hardware, generating 2048-bit keys may take minutes; for thousands of devices, automation scripts (e.g., Ansible) push configurations. The engineer sets ip ssh version 2 and disables Telnet on VTY lines. Common mistake: forgetting to configure a domain name before key generation—the command fails silently. Performance is not an issue because SSH uses minimal CPU after session establishment. If a device runs out of RSA key storage (rare), the engineer must delete old keys: crypto key zeroize rsa.

A company has a main office and 50 branch offices connected via VPN over the internet. The engineer configures IKE policies with AES-256, SHA-256, DH Group 14, and pre-shared keys. For scalability, they use a dynamic crypto map for branches with dynamic IPs, but static maps for main office. They enable Dead Peer Detection (DPD) to detect tunnel failures: crypto isakmp keepalive 10 3 periodic. Without DPD, a tunnel may appear up but actually be dead. They also configure PFS (group 14) in the transform set: set pfs group14. If a branch has a NAT device, they need to enable NAT-T: crypto isakmp nat-traversal 20. Misconfiguration example: mismatch in DH group causes IKE to fail—debug crypto isakmp shows 'no acceptable policy'.

A financial institution requires stronger authentication than pre-shared keys. They deploy a PKI with a private CA. On Cisco routers, the engineer enrolls certificates: crypto pki trustpoint CA then enrollment url http://ca-server. After enrollment, they configure ISAKMP with authentication rsa-sig. The router uses its certificate to authenticate. Common pitfall: clock not synchronized—certificates are time-sensitive. NTP must be configured. Also, CRL (Certificate Revocation List) checking can cause delays; engineers often disable CRL for performance in lab environments but not in production.