Cryptography & Network Security — Module 5 Compiled exam-ready answers for 10 questions

(Prepared for Vamshika C)

CITATIONS: - Textbook and module references used throughout: ■filecite■turn2file6■,
■filecite■turn1file6■
-------------------------------------------------------------------------------- 1) Explain how
DomainKeys Identified Mail (DKIM) works.
-------------------------------------------------------------------------------- DomainKeys
Identified Mail (DKIM) is an email authentication mechanism that allows an organization to take
responsibility for a message by attaching a digital signature to it. DKIM uses public-key
cryptography: the sending domain generates a public/private key pair. The private key is used
by an authorized signing module (often the sender's MTA/MSA) to create a digital signature over
selected RFC 5322 headers and the message body. This signature is inserted into the message as
the "DKIM-Signature" header (fields include v=, a=, c=, d=, s=, h=, bh=, b=).
The corresponding public key is published in DNS as a TXT record under the name:
selector._domainkey.signing-domain. A receiving MTA (verifier) extracts the d= (signing domain)
and s= (selector) from the DKIM-Signature, performs the same canonicalization on headers and
body, fetches the public key from DNS, and verifies the signature. If the signature verifies,
the verifier gains assurance of (1) data origin (that the signer had control of the signing
domain's private key) and (2) integrity (that the signed parts were not altered in transit).
DKIM canonicalization (simple or relaxed) allows tolerant handling of common mail
transformations. Limitations and interactions with other mail auth standards (such as SPF and
DMARC) are discussed in the textbook. ■filecite■turn2file6■
-------------------------------------------------------------------------------- 2) Describe
the IPsec framework and its components.
-------------------------------------------------------------------------------- IPsec is a
framework of open standards to secure IP communications at the network layer. It provides
confidentiality, integrity and authentication for IP datagrams and is commonly used for VPNs
and secure host-to-host communications. Major components:
- Authentication Header (AH): Provides data origin authentication, connectionless integrity,
and anti-replay protection; does not provide confidentiality (no encryption). AH covers the IP
payload and selected IP header fields (except mutable fields).
- Encapsulating Security Payload (ESP): Provides confidentiality (encryption) and optionally
provides integrity, authentication, and anti-replay. ESP inserts an ESP header (SPI, sequence
number), encrypts payload + trailer, and optionally appends authentication data (MAC).
- Security Associations (SAs): One-way logical relationships specifying the parameters used to
secure traffic (protocol AH/ESP, algorithms, keys, lifetime, mode). Each SA is uniquely
identified by the tuple (SPI, destination IP, protocol).
- Internet Key Exchange (IKE): Key management protocol used to negotiate SAs and distribute
keys. IKE typically runs in two phases: Phase 1 establishes an IKE SA (secure channel), and
Phase 2 negotiates IPsec SAs for data.
- Modes of operation: Transport mode (protect payload only) and Tunnel mode (protects entire IP
packet and encapsulates it inside a new outer IP header).
Algorithms used: AES/3DES (encryption), HMAC-SHA1/SHA-256 (integrity), Diffie–Hellman (key
exchange). The architecture, services and typical applications are described in detail in the
text. ■filecite■turn2file6■
-------------------------------------------------------------------------------- 3) Explain AH
and ESP packets.
-------------------------------------------------------------------------------- Authentication
Header (AH): - Purpose: connectionless integrity, data origin authentication, anti-replay. -
Function: AH inserts an AH header (SPI, sequence number, authentication data) and computes a
keyed hash over immutable parts of the IP header and the payload. AH does not encrypt data.
Use-cases: authenticating IP packets where confidentiality is not required. AH may not be
recommended in modern deployments because ESP provides combined services.
Encapsulating Security Payload (ESP): - Purpose: confidentiality (encryption) and, optionally,
integrity and authentication. - Structure: [IP header][ESP header (SPI, Seq#)][Encrypted
payload + ESP trailer][ESP authentication (optional)]. - Encrypted payload contains transport-
layer segment and padding; ESP trailer includes pad length and next-header; authentication
field (MAC) protects integrity. - ESP is widely used in VPNs and secure tunnels; supports both
transport and tunnel modes.
Summary: AH authenticates (no encryption) and can protect some header fields; ESP encrypts
payload and optionally authenticates it. ESP is the preferred protocol in most deployments.
■filecite■turn2file6■
-------------------------------------------------------------------------------- 4) Compare
Transport Mode and Tunnel Mode of IPsec.
-------------------------------------------------------------------------------- Transport
Mode: - Protects only the IP payload (upper-layer data). The original IP header remains intact
and visible for intermediate routers. - Use-case: host-to-host communication when both
endpoints are IPsec-aware (e.g., between two servers). - Lower overhead relative to tunnel
mode.
Tunnel Mode: - Protects the entire original IP packet (header + payload). The original packet
is encapsulated inside a new outer IP header. This mode hides internal addresses and routing
information. - Use-case: gateway-to-gateway VPNs, site-to-site tunnels, remote-access VPNs.
Common for routing secure traffic across untrusted networks. - Higher overhead but stronger
privacy and flexibility for subnet-to-subnet protection.
Table (summary): - Transport: encrypt payload only, used end-to-end, less overhead. - Tunnel:
encrypt entire packet, used for VPNs/gateways, hides internal packet details.
■filecite■turn1file6■■filecite■turn2file6■
-------------------------------------------------------------------------------- 5) Explain how
ESP secures an IP packet with sample headers.
-------------------------------------------------------------------------------- ESP secures an
IP packet by inserting an ESP header (SPI and sequence number), encrypting the payload portion
(transport segment and ESP trailer), and optionally adding an authentication field (MAC) at the
end. After ESP processing, the protected packet structure is:
[IP Header][ESP Header (SPI, Seq#)][Encrypted Payload + ESP Trailer (padding, pad length, next
header)][ESP Authentication Data (optional)]
Key fields: - SPI (Security Parameter Index): identifies the SA to the receiver. - Sequence
Number: anti-replay counter incremented per packet. - Encrypted Payload: confidentiality;
includes transport-layer data and padding for block alignment. - ESP Trailer fields (Pad, Pad
Length, Next Header) are encrypted. - Authentication Data (if used): MAC over selected parts;
ensures integrity and authenticity.
Processing steps (outbound): SPD decision → find SA in SAD → apply ESP: compute encryption and
authentication → construct packet with SPI and seq#. Inbound: verifier reads SPI, fetches SA
from SAD, verifies MAC, decrypts payload, checks anti-replay. ESP can operate in transport or
tunnel mode and can be configured to provide encryption only or encryption+authentication.
■filecite■turn2file6■
-------------------------------------------------------------------------------- 6) Apply IKE
Phase 1 and Phase 2 negotiation steps between two devices.
-------------------------------------------------------------------------------- IKE is used to
negotiate and establish Security Associations securely.
Phase 1 (IKE SA establishment): - Purpose: create an authenticated, encrypted channel between
the peers to protect subsequent negotiations. - Steps: peers negotiate cryptographic suite
(encryption, integrity, DH group), authenticate each other (pre-shared key or certificates),
perform Diffie–Hellman exchange to derive shared secret, and establish an IKE SA. - Result: a
secure IKE SA that protects future IKE messages.
Phase 2 (IPsec SA negotiation): - Purpose: negotiate the actual IPsec SAs used by ESP/AH for
data protection. - Steps: inside the secure IKE channel, peers negotiate IPsec protocols
(ESP/AH), algorithms, keying material, mode (transport/tunnel), lifetime, and whether to use
Perfect Forward Secrecy (PFS). Diffie–Hellman may be used again for PFS. - Result: creation of
two unidirectional IPsec SAs (one per direction) which are installed in the SAD and used to
protect traffic.
Overall: Phase 1 creates the protected negotiation channel; Phase 2 creates the operational SAs
used for securing data traffic. ■filecite■turn2file6■
-------------------------------------------------------------------------------- 7) Analyze the
process of forming Security Associations in IPsec.
-------------------------------------------------------------------------------- SA formation
process (overview): 1. SPD decision: Outbound packet matches SPD policy indicating PROTECT. If
no SA exists, SA formation is triggered. 2. IKE negotiation: IKE Phase 1 to establish IKE SA
(authenticated channel), then IKE Phase 2 to negotiate IPsec SA parameters. 3. SA parameters
negotiated: protocol (ESP/AH), algorithms (encryption/integrity), mode (transport/tunnel),
lifetime, SPI values, anti-replay settings, and key material. 4. Install SA in SAD: resulting
SA entries (one per direction) are stored in the SAD with SPI, keys, sequence counters, replay
windows, algorithm identifiers, and lifetime. 5. Packet processing: outbound packets use SAD
info to create ESP/AH headers; inbound packets use SPI to select SAD entry for
verification/decryption.
Important notes: - Each SA is unidirectional; two SAs are needed for bidirectional secure
communications. - SAD entries map SPI and destination address to SA parameters and keys. - SA
lifetime management and rekeying (via IKE) are crucial for maintaining security.
■filecite■turn2file6■
-------------------------------------------------------------------------------- 8) Compare
IPsec Transport mode vs Tunnel mode with use-case examples.
-------------------------------------------------------------------------------- (See Q4 for
the technical comparison. Use-case examples:) - Transport Mode Example: Secure host-to-host
communication between two servers that both support IPsec (e.g., database server connecting to
application server over an encrypted link). - Tunnel Mode Example: Site-to-site VPN between
branch-office firewalls: traffic from the entire branch subnet is tunneled through the Internet
to the corporate firewall, which decapsulates and forwards it to internal hosts. Another
tunnel-mode example: a remote worker connecting to corporate network via VPN client to gateway.
Tunnel mode is typical for VPNs because it encapsulates the original packet and hides internal
addressing details; transport is used when end systems themselves handle IPsec.
■filecite■turn1file6■■filecite■turn2file6■
-------------------------------------------------------------------------------- 9) Analyze the
need for key exchange in IPsec and how IKE supports this.
-------------------------------------------------------------------------------- Need for
secure key exchange: - IPsec requires shared cryptographic keys for encryption and integrity
protection. Transmitting keys in cleartext would enable eavesdroppers or MITM attackers to
learn the keys and defeat security. Secure key exchange must provide confidentiality of keys,
mutual authentication, and protection during negotiations.
How IKE supports key exchange: - IKE uses Diffie–Hellman to derive shared secrets without
sending private keys over the network, and authenticates peers using pre-shared keys or
certificates. - Phase 1: authenticates peers and establishes an IKE SA (protected channel). -
Phase 2: negotiates IPsec SAs and key material (optionally using PFS for extra protection). -
IKE also manages lifetimes and rekeying for SAs.
IKE therefore enables secure negotiation and distribution of keying material necessary for
IPsec operation. ■filecite■turn2file6■
-------------------------------------------------------------------------------- 10) Evaluate
the role of DKIM in preventing email spoofing and its limitations.
-------------------------------------------------------------------------------- Role: - DKIM
allows a signing domain to vouch for an email by placing a cryptographic signature (DKIM-
Signature header) using its private key. The verifier retrieves the public key from DNS and
verifies the signature, ensuring data origin and integrity. DKIM is transparent to end users
and helps mail providers associate messages with sender domains and reputation systems.
■filecite■turn2file6■
Limitations: - DKIM verifies the signing domain (d=) but does NOT guarantee the visible RFC
5322 "From:" header is owned by the signer; this gap allows deceptive "From" values unless
DMARC enforces identifier alignment. - DKIM depends on DNS: if DNS is compromised (cache
poisoning), an attacker could serve a fraudulent public key. - DKIM does not provide
confidentiality (no encryption). - DKIM can break when intermediaries (mailing lists,
remailers) modify messages beyond what canonicalization tolerates. - Attackers can register
look-alike domains and sign their messages legitimately, making DKIM insufficient alone to stop
phishing.
DKIM is effective as part of a suite (SPF + DKIM + DMARC) to reduce spoofing but is not a
standalone silver bullet. ■filecite■turn2file6■
-------------------------------------------------------------------------------- End of
document.