Network Security

Comprehensive Study Notes

Unit Topics Covered

Conventional & Public Key Cryptography, Hash Functions,

Unit 1
Authentication, Digital Signatures

X.509 Certificates, Remote User Authentication,

Unit 2
Kerberos, PKI, Key Distribution

EAP, IEEE 802.1X, SSL/TLS, Transport Layer Security,

Unit 3
Web Security, IKE, IPSec

Unit 4 Email Security (PGP), DKIM, S/MIME

Firewalls & IDS, Password Management,

Unit 5
Firewall Types, Cloud Security, IoT Security
UNIT 1 — Cryptography Fundamentals
1. Conventional and Public Key Cryptography
1.1 Conventional (Symmetric) Cryptography
Conventional cryptography, also called symmetric-key cryptography, uses the same secret key for
both encryption and decryption. The sender and receiver must share this key securely before
communicating.

Key Characteristics:
• Single shared key for encryption and decryption
• Fast and efficient — suitable for bulk data encryption
• Key distribution problem: securely sharing the key is a major challenge
• Does not provide non-repudiation

Common Algorithms:
• DES (Data Encryption Standard): 56-bit key, 64-bit block cipher. Now considered insecure due
to short key length.
• 3DES (Triple DES): Applies DES three times with different keys (112 or 168-bit effective key),
much more secure than DES.
• AES (Advanced Encryption Standard): Block cipher with 128-bit blocks; key sizes of 128, 192,
or 256 bits. Current standard, very secure and efficient.
• RC4, RC5, Blowfish: Other popular symmetric algorithms used in various applications.

How Symmetric Encryption Works:

Plaintext → [Encryption with Key K] → Ciphertext → [Decryption with Key K] → Plaintext. Both parties
must possess the same secret key K.

1.2 Public Key (Asymmetric) Cryptography

Public key cryptography uses a mathematically related key pair: a public key (shared openly) and a
private key (kept secret). Data encrypted with one key can only be decrypted with the other.

Key Characteristics:
• Two keys: Public Key (shared) + Private Key (secret)
• Solves the key distribution problem of symmetric cryptography
• Slower than symmetric encryption — typically used for key exchange and signatures
• Provides authentication, confidentiality, and non-repudiation

Common Algorithms:
• RSA (Rivest-Shamir-Adleman): Based on difficulty of factoring large integers. Most widely used
public-key algorithm. Key sizes: 1024–4096 bits.
• Diffie-Hellman (DH): Key exchange protocol based on discrete logarithm problem. Allows two
parties to establish a shared secret over an insecure channel.
• ECC (Elliptic Curve Cryptography): Based on elliptic curves over finite fields. Provides
equivalent security with smaller key sizes — efficient for mobile/IoT.
 • ElGamal: Based on DH, used for encryption and digital signatures.

Encryption vs. Digital Signature with Public Keys:

• Encryption: Sender encrypts with receiver's Public Key → Only receiver can decrypt with their
Private Key.
• Digital Signature: Sender signs with their own Private Key → Anyone can verify with sender's
Public Key.

Comparison Table:
Feature Symmetric Asymmetric

Keys Used 1 shared key 2 keys (public + private)

Speed Fast Slow

Key Distribution Difficult Easy (public key is open)

Key Length 128–256 bits 1024–4096 bits (RSA)

Non-repudiation No Yes

Use Case Bulk data encryption Key exchange, signatures

2. Hash Functions and Authentication

2.1 Hash Functions
A cryptographic hash function maps an arbitrary-length input (message) to a fixed-length output
called a hash value, digest, or fingerprint. It is a one-way function — computationally infeasible to
reverse.

Essential Properties of a Cryptographic Hash Function:

• Pre-image resistance: Given hash h, computationally infeasible to find input m such that H(m) =
h.
• Second pre-image resistance: Given m1, infeasible to find m2 ≠ m1 such that H(m1) = H(m2).
• Collision resistance: Infeasible to find any two distinct inputs m1 ≠ m2 that produce the same
hash.
• Deterministic: Same input always produces same output.
• Avalanche effect: A small change in input drastically changes the hash output.
• Fixed output size: Regardless of input size, output is fixed length.

Common Hash Algorithms:

• MD5 (Message Digest 5): 128-bit output. Fast but now considered cryptographically broken —
collisions have been found.
• SHA-1 (Secure Hash Algorithm 1): 160-bit output. Deprecated; collision attacks demonstrated.
• SHA-256 / SHA-512 (SHA-2 family): 256 or 512-bit outputs. Currently secure and widely used
(TLS, Bitcoin, etc.).
• SHA-3 (Keccak): Latest NIST standard, based on sponge construction — different design from
SHA-2.
 • HMAC: Hash-based Message Authentication Code — combines a hash function with a secret
key for message authentication.

Applications of Hash Functions:

• Data integrity verification (file checksums)
• Password storage (storing hash instead of plaintext)
• Digital signatures (sign the hash, not the full message)
• Message Authentication Codes (MACs)
• Proof of Work in cryptocurrencies (Bitcoin)

2.2 Authentication
Authentication is the process of verifying the identity of a user, device, or process. It answers the
question: "Are you who you claim to be?"

Authentication Factors (the three factors):

• Something you know: Password, PIN, passphrase, security question.
• Something you have: Smart card, hardware token, OTP device, smartphone.
• Something you are: Biometrics — fingerprint, iris scan, facial recognition, voice.
Multi-Factor Authentication (MFA) combines two or more of these factors for stronger security.

Authentication Methods:
• Password-based: Simplest form. Vulnerable to guessing, phishing, dictionary attacks.
• Challenge-Response: Verifier sends a random challenge; user proves identity by correctly
responding (e.g., encrypting the challenge with shared secret).
• One-Time Passwords (OTP): Time-based (TOTP) or counter-based (HOTP). Used in 2FA apps
like Google Authenticator.
• Certificate-based: X.509 certificates used to authenticate entities in PKI.
• Biometric: Based on unique physical characteristics. High usability but raises privacy concerns.

Message Authentication:
A Message Authentication Code (MAC) ensures both integrity and authenticity of a message. The
sender computes MAC = MAC_function(Key, Message) and appends it. The receiver recomputes the
MAC and compares — any tampering is detected.

3. Digital Signatures
A digital signature is a cryptographic mechanism that provides authentication, integrity, and
non-repudiation for digital messages or documents.

How Digital Signatures Work:

• Signing: The sender computes a hash of the message, then encrypts (signs) it with their private
key. This produces the digital signature.
• Verification: The receiver decrypts the signature using the sender's public key to recover the
hash. They independently hash the received message and compare. If they match, the signature
is valid.
Properties Provided:
• Authentication: Only the owner of the private key could have created the signature.
• Integrity: Any modification to the message invalidates the signature.
• Non-repudiation: The signer cannot later deny having signed the document.

Digital Signature Algorithms:

• RSA Digital Signature: Uses RSA keys. Sign: S = M^d mod n. Verify: M = S^e mod n.
• DSA (Digital Signature Algorithm): NIST standard based on discrete logarithm.
Signature-only, not used for encryption.
• ECDSA (Elliptic Curve DSA): Uses ECC — smaller keys, same security as DSA. Used in TLS,
Bitcoin.
• EdDSA (Ed25519): Modern, fast, and secure. Used in SSH, modern TLS.

Digital Signature vs. Electronic Signature:

A digital signature uses cryptographic operations and provides strong legal and technical
guarantees. An electronic signature is a broader term that may just be a scanned image of a
handwritten signature — it does NOT provide cryptographic guarantees.

Digital Certificates:
Digital signatures are verified using public keys. To ensure you have the correct public key, digital
certificates (X.509) are used. A trusted Certificate Authority (CA) digitally signs a certificate binding an
entity's identity to their public key.
UNIT 2 — Authentication Systems & PKI
1. X.509 Certificates
X.509 is the ITU-T standard defining the format of public key certificates. These certificates bind an
identity (person, organization, or device) to a public key, digitally signed by a trusted Certificate
Authority (CA).

X.509 Certificate Structure (Key Fields):

• Version: X.509 version (v1, v2, or v3 — v3 is current).
• Serial Number: Unique identifier assigned by the CA.
• Signature Algorithm: Algorithm used by CA to sign the certificate (e.g., SHA256withRSA).
• Issuer: Distinguished Name (DN) of the CA that issued the certificate.
• Validity Period: Not Before and Not After dates — defines when the certificate is valid.
• Subject: Distinguished Name of the entity the certificate belongs to.
• Subject Public Key Info: The public key and algorithm.
• Extensions (v3): Additional fields — Key Usage, Subject Alternative Names, Basic Constraints,
CRL Distribution Points, etc.
• CA's Digital Signature: The CA's signature over all the above fields.

Certificate Trust Hierarchy:

X.509 uses a chain of trust (certificate chain):

• Root CA: Self-signed certificate at the top of the hierarchy — trusted by browsers/OS.
• Intermediate CA: Certified by Root CA — issues end-entity certificates.
• End-Entity Certificate: Issued to servers, users, or devices.

Certificate Revocation:
• CRL (Certificate Revocation List): Periodic list published by CA of revoked certificates.
• OCSP (Online Certificate Status Protocol): Real-time checking of certificate revocation status.

Uses of X.509 Certificates:

• TLS/SSL — securing HTTPS websites
• S/MIME — secure email
• Code signing — verifying software authenticity
• VPN authentication
• Smart card authentication

2. Remote User / Authentication Principles

Remote user authentication verifies the identity of users accessing a system from a distant location
over a network.

Core Authentication Principles:

• Identification: User claims an identity (e.g., username).
 • Authentication: User proves the claimed identity (password, certificate, biometric).
• Authorization: System grants access rights based on verified identity.

Challenges in Remote Authentication:

• Network is untrusted — data can be intercepted (man-in-the-middle attacks).
• Replay attacks — captured authentication tokens replayed later.
• Eavesdropping — passwords sniffed on the network.
• Impersonation — fake server presenting false identity to the client.

Secure Remote Authentication Techniques:

• Nonce-based challenge-response: Server sends a random nonce; client hashes
password+nonce to prove knowledge without revealing password.
• Mutual Authentication: Both client and server authenticate each other (used in TLS).
• OTP (One-Time Password): Password valid for single use — prevents replay attacks.
• Certificate-based authentication: Client presents X.509 certificate; server verifies it.
• RADIUS / DIAMETER: Protocols for centralized remote authentication, authorization, and
accounting (AAA).

3. Kerberos System
Kerberos is a network authentication protocol developed at MIT that uses symmetric key
cryptography and a trusted third party to provide strong authentication in client-server architectures.

Key Components:
• Client: The user/application requesting a service.
• Authentication Server (AS): Verifies client identity and issues Ticket-Granting Ticket (TGT).
• Ticket-Granting Server (TGS): Issues service tickets based on valid TGT.
• Service Server (SS): The actual service the client wants to access.
• Key Distribution Center (KDC): Combines AS + TGS.

Kerberos Authentication Flow:

• Step 1 (AS Exchange): Client sends identity to AS. AS returns an encrypted TGT and a session
key (encrypted with client's password hash).
• Step 2: Client decrypts session key using password and presents TGT to TGS requesting
service ticket.
• Step 3 (TGS Exchange): TGS validates TGT and issues a Service Ticket for the target service.
• Step 4 (Client-Server): Client presents Service Ticket to the Service Server, which grants
access.

Advantages of Kerberos:
• Passwords never transmitted over the network
• Single Sign-On (SSO) capability — one login for multiple services
• Mutual authentication — both client and server are authenticated
• Time-limited tickets prevent replay attacks

Limitations:
 • Single point of failure — if KDC goes down, no authentication is possible
• Requires time synchronization (clock skew < 5 minutes by default)
• Vulnerable to offline dictionary attacks if weak passwords are used

4. Authentication Using Asymmetric Encryption

Asymmetric (public key) cryptography can be used for authentication without transmitting or sharing
secret keys.

Mechanisms:
• Digital Signatures for Authentication: Entity signs a challenge or timestamp with private key
→ verifier checks with public key → proves possession of private key → identity authenticated.
• Public Key Challenge-Response: Server sends random challenge R. Client signs R with
private key. Server verifies using client's public key from certificate.
• TLS Client Certificate Authentication: During TLS handshake, client presents X.509 certificate
and proves possession of corresponding private key.
• SSH Public Key Authentication: Server has user's public key. User proves identity by signing a
challenge with private key. No password ever crosses the network.

Advantages Over Symmetric Authentication:

• No shared secret needed — eliminates key distribution problem
• Private key never leaves the authenticating device
• Strong non-repudiation — cannot deny authentication

5. Public Key Infrastructure (PKI)

PKI is a framework of policies, procedures, hardware, software, and people used to create, manage,
distribute, use, store, and revoke digital certificates. It enables trust in public key cryptography at scale.

PKI Components:
• Certificate Authority (CA): Trusted entity that issues and signs digital certificates.
• Registration Authority (RA): Verifies identity of certificate requestors on behalf of CA.
• Certificate Repository / Directory: Stores issued certificates (e.g., LDAP directory).
• CRL / OCSP: Mechanisms for certificate revocation.
• Certificate Policy (CP) & CPS: Documents describing how PKI is operated.

PKI Trust Models:

• Hierarchical (Single Root): One Root CA at top; most common model.
• Mesh / Cross-Certification: Multiple Root CAs cross-certify each other.
• Web of Trust (PGP model): Users vouch for each other's keys — no central authority.
• Bridge CA: A special CA that cross-certifies multiple hierarchies.

Certificate Lifecycle:
• Key Generation → Certificate Request (CSR) → Verification by RA → Issuance by CA →
Deployment → Renewal/Revocation
6. Symmetric vs. Asymmetric Key Distribution Techniques
Symmetric Key Distribution:
The challenge is securely distributing the shared secret key. Methods:

• Physical delivery: Key delivered in person or via secure courier — impractical at scale.
• Key Distribution Center (KDC): Trusted third party (like in Kerberos) distributes session keys
encrypted with pre-shared keys.
• Diffie-Hellman Key Exchange: Two parties derive a shared secret over a public channel
without prior shared secret — elegant but vulnerable to MITM without authentication.

Asymmetric Key Distribution:

• Public Key directly shared: No confidentiality needed for public keys, but authenticity must be
ensured.
• PKI / X.509 Certificates: CA signs certificates binding identity to public key — most robust and
scalable solution.
• PGP Web of Trust: Community-based vouching for public keys — used in email security.

Hybrid Approach (Most Common in Practice):

Asymmetric cryptography is used to securely exchange a symmetric session key (e.g., TLS
handshake). Then the faster symmetric key encrypts actual data. This combines the best of both
worlds.
UNIT 3 — Network Security Protocols
1. Extensible Authentication Protocol (EAP)
EAP (Extensible Authentication Protocol) is a flexible authentication framework defined in RFC
3748. It is not a specific authentication mechanism but rather a framework that supports multiple
authentication methods.

Key Features:
• Works at the data link layer — does not require IP
• Transport-independent — works over PPP, 802.11 (Wi-Fi), 802.3 (Ethernet)
• Supports multiple authentication methods (EAP methods)
• Enables mutual authentication between client and server

Common EAP Methods:

• EAP-MD5: Challenge-response using MD5 hash. Simple but no mutual auth, no key generation.
• EAP-TLS: Uses X.509 certificates for both client and server. Most secure — requires PKI.
• EAP-TTLS: Server authenticated with certificate; client uses various inner methods (PAP,
CHAP, MS-CHAPv2) inside TLS tunnel.
• PEAP (Protected EAP): Server authenticated with certificate; client uses MS-CHAPv2 inside
TLS tunnel. Most widely deployed in enterprise Wi-Fi.
• EAP-FAST: Cisco proprietary, uses Protected Access Credentials (PAC) instead of certificates.
• EAP-SIM / EAP-AKA: Authentication using SIM cards — used in mobile networks.

EAP Message Types:

• EAP Request, EAP Response, EAP Success, EAP Failure

2. IEEE 802.1X — Port-Based Network Access Control

IEEE 802.1X is a standard for port-based Network Access Control (NAC). It provides an authentication
mechanism for devices wishing to connect to a LAN or WLAN.

Three Components (AAA Architecture):

• Supplicant: The client device requesting network access (PC, phone, etc.).
• Authenticator: Network device (switch or Wi-Fi AP) that controls access — acts as
intermediary.
• Authentication Server: Typically a RADIUS server (e.g., FreeRADIUS, Microsoft NPS) that
actually verifies credentials.

802.1X Operation:
• 1. Supplicant connects to port — port is initially unauthorized (only EAPOL frames allowed).
• 2. Authenticator sends EAP-Request/Identity to supplicant.
• 3. Supplicant responds with EAP-Response/Identity.
• 4. Authenticator forwards to Authentication Server using RADIUS.
• 5. Authentication Server performs authentication (EAP method).
 • 6. On success, Authentication Server sends RADIUS Access-Accept; authenticator opens the
port.
• 7. On failure, RADIUS Access-Reject; port remains blocked.

Applications:
• Enterprise Wi-Fi security (WPA2-Enterprise / WPA3-Enterprise)
• Wired LAN port security in corporate networks
• VPN authentication

3. Secure Socket Layer (SSL)

SSL (Secure Sockets Layer) was developed by Netscape in the 1990s to provide secure
communication over the Internet. SSL 3.0 has been deprecated and replaced by TLS.

SSL Record Protocol:

• Provides confidentiality using symmetric encryption
• Provides integrity using MAC
• Fragments, compresses, encrypts, and transmits data

SSL Handshake Protocol:

Establishes the secure channel before data transfer:

• 1. Client Hello: Supported cipher suites, random number, session ID.

• 2. Server Hello: Chosen cipher suite, random number, session ID.
• 3. Server Certificate: X.509 certificate for authentication.
• 4. Server Hello Done.
• 5. Client Key Exchange: Pre-master secret (encrypted with server's public key).
• 6. Change Cipher Spec + Finished (both sides).
• 7. Secure communication begins.

Why SSL is deprecated:

• SSL 2.0 and 3.0 have critical vulnerabilities (POODLE, DROWN attacks)
• TLS 1.2 and 1.3 are the current secure replacements

4. Transport Layer Security (TLS)

TLS is the successor to SSL and the current standard for securing internet communications. TLS 1.3 is
the latest version (RFC 8446, 2018) and is a major redesign for security and performance.

TLS 1.3 Key Improvements over TLS 1.2:

• 1-RTT handshake (was 2-RTT) — 0-RTT resumption for repeat connections
• Removed support for weak cipher suites (RC4, DES, MD5, SHA-1)
• Forward Secrecy mandatory — uses (EC)DHE for all key exchanges
• Simplified cipher suite: only 5 suites (e.g., TLS_AES_256_GCM_SHA384)
• Encrypted more of the handshake — better privacy

TLS Components:
 • TLS Record Protocol: Provides confidentiality (AES-GCM, ChaCha20) and integrity
(HMAC/AEAD).
• TLS Handshake Protocol: Negotiates parameters, authenticates server (and optionally client),
derives session keys.
• TLS Alert Protocol: Signals errors and closure.
• TLS Change Cipher Spec Protocol: Signals switch to negotiated encryption (legacy — not
used in TLS 1.3).

Key Concepts:
• AEAD (Authenticated Encryption with Associated Data): Combines encryption and integrity
in one operation. Used in TLS 1.3.
• Session Resumption: Session tickets or PSK (Pre-Shared Key) allow fast reconnection without
full handshake.
• SNI (Server Name Indication): TLS extension allowing hosting of multiple certificates on same
IP.
• Certificate Pinning: Client pins expected certificate/public key to prevent MITM with fraudulent
certificates.

5. Web Security
Web security encompasses protecting web applications, servers, and clients from attacks and
unauthorized access.

HTTPS:
HTTP over TLS. Provides confidentiality (encryption), integrity (MAC), and authentication (server
certificate). Port 443 by default. Essential for any website handling sensitive data.

Common Web Attacks and Defenses:

• SQL Injection: Malicious SQL in input fields. Defense: Parameterized queries, input validation.
• XSS (Cross-Site Scripting): Injecting malicious scripts into web pages. Defense: Content
Security Policy (CSP), output encoding.
• CSRF (Cross-Site Request Forgery): Tricks user into making unintended requests. Defense:
CSRF tokens, SameSite cookies.
• Clickjacking: Embedding page in iframe to trick user. Defense: X-Frame-Options header.
• Directory Traversal: Accessing files outside web root via ../. Defense: Input sanitization.

HTTP Security Headers:

• Strict-Transport-Security (HSTS): Forces HTTPS
• Content-Security-Policy (CSP): Controls allowed content sources
• X-Content-Type-Options: Prevents MIME sniffing
• X-Frame-Options: Prevents clickjacking
• Referrer-Policy: Controls referrer information

HTTPS Best Practices:

• TLS 1.2 minimum; TLS 1.3 preferred
• Use strong cipher suites; disable RC4, DES, 3DES
 • Certificate from trusted CA with proper chain
• Implement HSTS with preloading

6. Internet Key Exchange (IKE)

IKE (Internet Key Exchange) is the protocol used to set up Security Associations (SAs) in IPSec. It
handles authentication and key negotiation. IKEv2 (RFC 7296) is the current version.

IKE Phases (IKEv1):

• Phase 1 (IKE SA): Establishes a secure, authenticated channel between peers. Modes: Main
Mode (6 messages, identity protected) or Aggressive Mode (3 messages, faster but less secure).
• Phase 2 (IPSec SA): Uses Phase 1 channel to negotiate IPSec SAs for actual data protection.
Only Quick Mode.

IKEv2 Improvements:
• Simpler — only 4 messages for initial exchange (IKE_SA_INIT + IKE_AUTH)
• Built-in NAT traversal
• Built-in EAP support for user authentication
• MOBIKE extension for mobility (IP address changes)
• More reliable — includes request/response reliability

IKE Authentication Methods:

• Pre-Shared Key (PSK) — simple but requires secure key distribution
• Digital Certificates (X.509) — scalable, used in enterprise VPNs
• EAP — user authentication in remote access VPNs

7. IP Security (IPSec) with Diagram

IPSec is a suite of protocols for securing IP communications by authenticating and/or encrypting each
IP packet. It operates at the Network Layer (Layer 3).

IPSec Modes:
• Transport Mode: Only the IP payload (TCP/UDP) is encrypted/authenticated. Original IP header
is preserved. Used for end-to-end communication between two hosts.
• Tunnel Mode: Entire original IP packet (header + payload) is encrypted/authenticated and
encapsulated in a new IP packet. Used for VPNs (gateway-to-gateway).

IPSec Protocols:
• AH (Authentication Header — Protocol 51): Provides data integrity and origin authentication.
Does NOT provide confidentiality (no encryption). Covers most of the IP header + payload.
• ESP (Encapsulating Security Payload — Protocol 50): Provides confidentiality (encryption),
integrity, and optional authentication. Most commonly used IPSec protocol.

Security Association (SA):

An SA is a one-way relationship between sender and receiver, defined by a Security Parameters Index
(SPI), destination IP, and protocol (AH or ESP). Two SAs are needed for bidirectional communication.
SAs are managed by the SAD (Security Association Database).
IPSec Architecture — Conceptual Diagram:
HOST A ↔ Internet (IPSec Tunnel) ↔ HOST B

IP Payload Encrypted ESP Payload IP Payload

Original IP Hdr → New IP Hdr | ESP Hdr | [Orig IP Hdr + Data] | ESP Trailer | ESP Auth → Original IP Hdr

IPSec Use Cases:

• Site-to-Site VPN: Connecting two office networks over the Internet
• Remote Access VPN: Individual users connecting to corporate network
• Always-On VPN for mobile workers
• Securing routing protocol updates (BGP)
UNIT 4 — Email Security
1. Email Security — PGP (Pretty Good Privacy)
PGP (Pretty Good Privacy) is an encryption program that provides cryptographic privacy and
authentication for email communication. It was created by Phil Zimmermann in 1991. OpenPGP (RFC
4880) is the open standard.

Services Provided by PGP:

• Confidentiality: Message encrypted with a one-time symmetric key (session key), which itself is
encrypted with the recipient's public key.
• Authentication/Digital Signature: Sender's private key signs the message hash.
• Compression: Message is compressed (typically with ZIP) before encryption.
• Radix-64 (Base64) Encoding: Binary encrypted data converted to ASCII for email compatibility.
• Key Management: Web of Trust model — users vouch for each other's keys.

PGP Message Processing (Sending):

• 1. Generate random session key (e.g., AES-256)
• 2. Encrypt message with session key (symmetric encryption)
• 3. Encrypt session key with recipient's public key (RSA/ElGamal)
• 4. Optionally sign message hash with sender's private key (DSA/RSA)
• 5. Compress, then Base64-encode
• 6. Send as email attachment or body

PGP Key Management — Web of Trust:

Unlike PKI which relies on CAs, PGP uses a decentralized Web of Trust. Users sign each other's
public keys to vouch for their authenticity. Keys are distributed via key servers (e.g.,
[Link]).

• Key Ring: Each user maintains a public key ring (others' keys) and a private key ring (own
keys).
• Trust Levels: Unknown, Undefined, Marginal, Full, Ultimate trust.

PGP vs. S/MIME:

• PGP uses Web of Trust; S/MIME uses hierarchical PKI (CA-issued certificates)
• S/MIME is more common in enterprise email; PGP more popular among individuals/developers
• Both provide similar security services

2. Domain Keys Identified Mail (DKIM)

DKIM is an email authentication method that allows the receiving mail server to verify that an email
was actually sent by the claimed domain and that the message content was not altered in transit.

How DKIM Works:

• 1. Key Setup: Domain owner generates a public/private key pair. Public key published in DNS
as a TXT record. Private key stored on the mail server.
 • 2. Signing: Outgoing mail server uses the private key to create a digital signature over selected
email headers and body. Signature added as DKIM-Signature header.
• 3. Verification: Receiving server extracts the DKIM-Signature header, retrieves the public key
from DNS, and verifies the signature. If valid, email is legitimate.

DKIM-Signature Header Key Tags:

• v= Version (always 1)
• a= Signature algorithm (e.g., rsa-sha256)
• d= Domain name (e.g., [Link])
• s= Selector (sub-key identifier, e.g., 'mail')
• h= List of signed headers (From, To, Subject, Date, etc.)
• bh= Hash of message body (Base64-encoded)
• b= The actual signature (Base64-encoded)

What DKIM Protects Against:

• Email spoofing — forging the From domain
• Content tampering during transit
• Replay attacks (with timestamp and expiry fields)

DKIM Limitations:
• Does not encrypt the message — only signs headers and body
• Does not protect against compromised sending server
• Works with SPF and DMARC for complete email authentication framework

Email Security Trio (SPF + DKIM + DMARC):

• SPF (Sender Policy Framework): DNS record listing authorized IP addresses for sending email
for a domain.
• DKIM: Cryptographic signature verifying message authenticity and integrity.
• DMARC: Policy framework using SPF and DKIM results to tell receiving servers what to do with
failing emails (reject, quarantine, or report).

3. S/MIME (Secure/Multipurpose Internet Mail Extensions)

S/MIME is a standard for public key encryption and digital signing of email messages. It is defined in
RFC 5751 and is the most widely used secure email standard in enterprise environments.

Services Provided by S/MIME:

• Digital Signatures: Verifies sender's identity and message integrity using X.509 certificates.
• Encryption: Ensures only intended recipient can read the message.
• Combined: Can sign and encrypt simultaneously.

S/MIME vs. PGP Comparison:

Feature S/MIME PGP/OpenPGP

Trust Model Hierarchical PKI (CA) Web of Trust

Certificate Format X.509 PGP Key / OpenPGP

 Enterprise Adoption Very High Moderate

Individual Use Moderate High

Key Distribution CA-issued certificates Key servers, manual

Email Client Support Built-in (Outlook, Apple Mail) Plugin required (Thunderbird+Enigmail)

Encryption Algorithm AES (typically) AES, 3DES, etc.

S/MIME Content Types:

• multipart/signed: Original message + signature — readable without S/MIME client.
• application/pkcs7-mime (smime-type=signed-data): Message encoded and signed.
• application/pkcs7-mime (smime-type=enveloped-data): Encrypted message.

Certificate Enrollment for S/MIME:

Users must obtain an S/MIME certificate (email certificate) from a trusted CA (e.g., Sectigo, DigiCert,
Let's Encrypt for personal use). The certificate is installed in the email client and automatically used for
signing/encryption.
UNIT 5 — Firewalls, IDS, Cloud & IoT Security
1. Firewalls and Intrusion Detection Systems (IDS)
1.1 Firewalls
A firewall is a network security device (hardware or software) that monitors and controls incoming and
outgoing network traffic based on predetermined security rules. It establishes a barrier between trusted
internal networks and untrusted external networks.

Firewall Characteristics:
• Packet filtering based on IP addresses, ports, and protocols
• Stateful inspection tracking active connections
• Application layer awareness (next-gen firewalls)
• Logging and auditing of traffic
• VPN termination capabilities
• NAT (Network Address Translation)

Firewall Types:
• 1. Packet Filtering Firewall: Inspects each packet independently based on header fields
(src/dst IP, port, protocol). Simple, fast, but no context awareness — cannot detect sophisticated
attacks. Implemented as ACLs on routers.
• 2. Stateful Inspection Firewall: Tracks the state of network connections (TCP state machine).
Allows only packets belonging to established connections. Much more secure than simple packet
filtering.
• 3. Application Gateway (Proxy Firewall): Operates at application layer. Acts as a proxy
between client and server — completely breaks the connection. Deep inspection of
application-level data. Can enforce application-specific policies.
• 4. Circuit-Level Gateway: Works at session layer. Validates TCP handshakes without
inspecting packet content. Creates a circuit between client and server.
• 5. Next-Generation Firewall (NGFW): Combines stateful inspection with deep packet inspection
(DPI), application identification, user identity integration, IPS capabilities, SSL/TLS inspection, and
threat intelligence.

Firewall Basing (Deployment Architectures):

• Screened Host: Packet filtering router + bastion host. External traffic goes through router first,
then bastion host.
• Screened Subnet (DMZ): Two firewalls create a DMZ (Demilitarized Zone). Public servers (web,
mail) in DMZ. Internal network isolated from both Internet and DMZ.
• Dual-Homed Host: Single host with two NICs — one internal, one external. Acts as firewall. IP
forwarding must be disabled.
• Software Firewall: Host-based firewall installed on individual computers. Examples: Windows
Defender Firewall, iptables/nftables on Linux.

1.2 Intrusion Detection Systems (IDS)

An IDS (Intrusion Detection System) monitors network traffic or system activities for malicious
activity or policy violations and alerts administrators. Unlike a firewall, IDS is passive — it detects but
does not block.

IDS Classification by Detection Method:

• Signature-based (Misuse Detection): Compares traffic against database of known attack
signatures. Very accurate for known attacks; cannot detect zero-day attacks. Example: Snort.
• Anomaly-based (Behavioral Detection): Establishes baseline of normal behavior; alerts on
deviations. Can detect zero-days but high false positive rate.
• Hybrid: Combines signature and anomaly detection.

IDS Classification by Deployment:

• NIDS (Network IDS): Monitors traffic on a network segment. Deployed at key points (perimeter,
DMZ). Examples: Snort, Suricata, Zeek (Bro).
• HIDS (Host IDS): Monitors activities on a specific host. Checks file integrity, log files, system
calls. Examples: OSSEC, Tripwire, AIDE.

IDS vs. IPS:

• IDS (Intrusion Detection System): Passive — detects and alerts. Out-of-band deployment —
does not sit in traffic path.
• IPS (Intrusion Prevention System): Active — detects and blocks. Inline deployment — sits in
traffic path and drops malicious packets in real time.

Password Management (related to intrusion prevention):

• Enforce minimum password length (12+ characters)
• Require complexity (uppercase, lowercase, digits, symbols)
• Password history to prevent reuse
• Account lockout after failed attempts
• Privileged Account Management (PAM) for admin accounts
• Multi-factor authentication for sensitive systems
• Password managers for secure storage of complex passwords
• Regular password auditing with tools like John the Ripper or Hashcat

2. Cloud Security
Cloud security encompasses the policies, technologies, controls, and services that protect cloud
computing environments, applications, and data.

Cloud Service Models and Security Responsibility:

• IaaS (Infrastructure as a Service): Provider secures hardware, hypervisor, network. Customer
secures OS, middleware, applications, data. Examples: AWS EC2, Azure VMs, GCP Compute.
• PaaS (Platform as a Service): Provider secures platform and infrastructure. Customer secures
applications and data. Examples: Google App Engine, AWS Elastic Beanstalk.
• SaaS (Software as a Service): Provider secures most of the stack. Customer responsible for
data, user access management. Examples: Gmail, Office 365, Salesforce.

Shared Responsibility Model:

Key concept in cloud security: Both cloud provider and customer share security responsibilities. The
division depends on the service model (IaaS/PaaS/SaaS).

Cloud Security Threats:

• Data Breaches: Unauthorized access to sensitive data stored in cloud.
• Insecure APIs: Vulnerable cloud APIs used for management and access.
• Account Hijacking: Phishing or credential theft targeting cloud accounts.
• Denial of Service (DoS): Overwhelming cloud services — amplified by elasticity.
• Insider Threats: Malicious or negligent cloud provider employees.
• Misconfiguration: Largest cause of cloud breaches — open S3 buckets, overly permissive IAM
roles.
• Data Loss: Accidental deletion, ransomware, provider outages.

Cloud Security Controls:

• Identity and Access Management (IAM): Fine-grained access control, MFA, least privilege
principle.
• Encryption: Data at rest (AES-256), data in transit (TLS), key management (HSMs, KMS).
• Network Security: VPCs (Virtual Private Clouds), security groups, NACLs, WAF.
• Security Monitoring: CloudTrail (AWS), Azure Monitor, Google Cloud Logging — audit trails.
• Vulnerability Management: Regular scanning of cloud workloads.
• Compliance: Ensure compliance with GDPR, HIPAA, PCI-DSS, SOC 2.

Cloud Security Standards & Frameworks:

• CSA (Cloud Security Alliance) — STAR certification, Cloud Controls Matrix (CCM)
• ISO 27017 — Cloud-specific security controls
• NIST SP 800-144 — Cloud computing security guidelines
• CIS Benchmarks for cloud platforms (AWS, Azure, GCP)

3. IoT Security
IoT (Internet of Things) refers to the billions of connected devices (sensors, cameras, smart
appliances, industrial equipment) that collect and exchange data. These devices introduce unique
security challenges due to their resource constraints, scale, and deployment environments.

IoT Security Challenges:

• Resource Constraints: Limited CPU, memory, and battery — cannot run traditional security
software.
• Heterogeneity: Enormous variety of devices, operating systems, and protocols.
• Weak Default Credentials: Many IoT devices ship with default passwords — often never
changed.
• Limited Update Mechanisms: Many devices lack OTA update capability — vulnerabilities
persist for years.
• Physical Exposure: Devices deployed in uncontrolled environments — vulnerable to physical
attacks.
 • Insecure Communications: Many use unencrypted protocols (HTTP, plain MQTT).
• Scale: Millions of devices — massive attack surface and management challenge.

IoT Attack Vectors:

• Botnets (Mirai-type): Compromised IoT devices used for DDoS attacks — scanning for default
credentials.
• Man-in-the-Middle: Intercepting unencrypted IoT communications.
• Firmware Attacks: Extracting/modifying device firmware to implant malware.
• Side-Channel Attacks: Extracting secrets by analyzing power consumption, timing, or EM
emissions.
• Physical Tampering: Accessing JTAG/UART debug ports, extracting flash memory.

IoT Security Best Practices:

• Secure Boot: Verify firmware integrity at boot using cryptographic signatures.
• Device Identity: Unique device certificates (X.509) for authentication.
• Encryption: TLS for communications; AES for data at rest.
• Network Segmentation: Isolate IoT devices on separate VLANs/networks.
• Change Default Credentials: Always change default passwords on deployment.
• Regular Firmware Updates: Implement OTA update mechanism with signature verification.
• Minimal Attack Surface: Disable unused services, ports, and interfaces.
• Anomaly Detection: Monitor IoT device behavior for unusual patterns.

IoT Security Standards & Frameworks:

• NIST IR 8259: Foundational cybersecurity activities for IoT device manufacturers.
• ETSI EN 303 645: Cyber security for consumer IoT — baseline requirements.
• IEC 62443: Industrial automation and control systems (IACS) security standard.
• OWASP IoT Top 10: Top 10 IoT vulnerabilities (weak passwords, insecure network services,
etc.).
• IoT Security Foundation (IoTSF): Best practice guidelines for IoT security.

IoT Communication Protocols and Security:

• MQTT (Message Queuing Telemetry Transport): Lightweight publish-subscribe protocol.
Secure with TLS and client certificate authentication.
• CoAP (Constrained Application Protocol): HTTP-like protocol for constrained devices.
Security via DTLS (Datagram TLS).
• LoRaWAN: Long-range, low-power network. Security via AES-128 session keys.
• Zigbee / Z-Wave: Short-range mesh protocols with AES-128 encryption.
• Bluetooth LE (BLE): Pairing security with LE Secure Connections using ECDH key exchange.

End of Network Security Notes