Unit 6: Network Security - Subjective Questions

Application-layer security protects data and services at the level where users and applications interact. It is required because lower-layer security alone may not protect application-specific data, identities, or transactions.

Major threats include:

• Eavesdropping: Unauthorized users intercept application data.
• Message modification: Attackers alter messages during transmission.
• Impersonation: An attacker pretends to be a legitimate user or server.
• Replay attacks: Previously captured valid messages are retransmitted.
• Malware and injection attacks: Malicious code or commands are inserted into application requests.
• Denial-of-service attacks: Application resources are exhausted.

Common protection mechanisms are:

• User authentication and authorization.
• Encryption of sensitive data.
• Digital signatures and message authentication codes.
• Secure session management and replay protection.
• Input validation and access control.
• Security protocols such as PGP, SSL/TLS, and secure application gateways.

Application-layer security is important because it can provide protection tailored to the requirements of a particular application, such as secure email, online banking, or web services.

A secure email system should provide the following services:

• Confidentiality: Only the intended recipient should be able to read the message. This is achieved by encrypting the message using the recipient's public key or a shared secret key.
• Authentication: The recipient should be able to verify the identity of the sender. Digital signatures provide sender authentication.
• Integrity: The recipient must detect any unauthorized modification. A cryptographic hash is calculated over the message and protected using a digital signature or message authentication code.
• Non-repudiation: The sender should not be able to deny sending the message. A digital signature generated using the sender's private key provides evidence of message origin.
• Access control: Only authorized users should be able to access mailboxes.
• Availability: Mail services should remain accessible to legitimate users.

A typical secure email process uses a hash function, a digital signature, encryption of the message or session key, and public-key certificates for key management.

Pretty Good Privacy (PGP) is an application-layer security system widely used to protect email and files. It combines symmetric-key cryptography, public-key cryptography, hashing, and digital signatures.

PGP message creation generally involves these steps:

1. The sender creates a message digest using a cryptographic hash function.
2. The digest is encrypted with the sender's private key to create a digital signature.
3. The message and signature are compressed to reduce size and improve security.
4. A random symmetric session key is generated.
5. The compressed data is encrypted using the session key.
6. The session key is encrypted using the recipient's public key.
7. The encrypted session key and encrypted message are transmitted to the recipient.

At the recipient's side:

• The recipient uses their private key to recover the session key.
• The session key decrypts the message.
• The sender's public key verifies the digital signature.
• A new digest is calculated and compared with the recovered digest.

Thus, PGP provides confidentiality through encryption, authentication and non-repudiation through digital signatures, and integrity through message digests.

PGP public-key management commonly uses a decentralized trust model, whereas certificate-based systems generally depend on a hierarchical certificate authority structure.

In PGP, a user assigns a level of trust to another user's identity and may sign that user's public key. Several trusted signatures can establish confidence in a key. This is called a web of trust.

A PGP user must verify that a public key belongs to the claimed person. This can be done by checking the fingerprint through a trusted channel or relying on signatures from known users. The trust model is flexible, but its effectiveness depends on users correctly validating and managing keys.

Transport-layer security protects data exchanged between two communicating endpoints, usually without requiring each application to implement its own cryptographic functions.

Security services include:

• Server authentication: The client verifies the identity of the server using a digital certificate.
• Optional client authentication: The server verifies the identity of the client.
• Confidentiality: Data is encrypted during transmission.
• Integrity: Any modification of transmitted data is detected using a message authentication code or authenticated encryption.
• Replay and sequence protection: Record numbers and integrity checks help detect reordered or duplicated records.
• Secure session establishment: Cryptographic algorithms and keys are negotiated before application data is exchanged.

Transport-layer security is useful because it can protect several applications over a single secure connection. It reduces the need for each application to design its own security system and can secure protocols such as web browsing, email submission, and file transfer. However, it generally protects data only while it travels between endpoints; it does not automatically protect data after it reaches the application or while it is stored.

SSL is designed to provide secure communication between an application and a transport protocol such as TCP. It is positioned above TCP and below application protocols.

SSL architecture consists of:

• SSL Record Protocol: This is the basic data-transfer protocol. It fragments application data, optionally compresses it, adds integrity protection, encrypts the result, and transmits it as records.
• Handshake Protocol: Establishes the version, negotiates cryptographic algorithms, authenticates the server and optionally the client, and generates session keys.
• Change Cipher Spec Protocol: Signals that subsequent messages will use the newly negotiated security parameters.
• Alert Protocol: Communicates warnings, errors, and connection termination notifications.

The SSL Record Protocol provides the common security framework used by the other SSL protocols. The handshake establishes the secure context, the Change Cipher Spec activates that context, and the Alert Protocol reports exceptional conditions. This layered structure separates session establishment from protected data transfer.

The four principal SSL protocols are as follows:

1. SSL Handshake Protocol

   • Negotiates the SSL version and cipher suite.
   • Establishes a master secret and session keys.
   • Authenticates the server and optionally the client.
   • Allows both parties to verify that the negotiation was not modified.

2. SSL Record Protocol

   • Divides data into manageable fragments.
   • Optionally compresses the fragments.
   • Adds a message authentication code or equivalent integrity protection.
   • Encrypts and transmits the resulting records.

3. Change Cipher Spec Protocol

   • Contains a short control message indicating that the negotiated security parameters will now be used.
   • Causes subsequent records to be protected with the selected algorithms and keys.

4. Alert Protocol

   • Sends warnings and fatal-error notifications.
   • Indicates reasons for connection termination, such as an invalid certificate or a failed integrity check.

Together, these protocols provide negotiation, authentication, secure data transfer, cryptographic state activation, and error reporting.

The SSL handshake creates the security parameters required for protected communication.

A typical handshake includes:

1. ClientHello: The client sends the supported protocol versions, a random value, supported cipher suites, and compression methods.
2. ServerHello: The server selects the protocol version, cipher suite, compression method, and sends its random value.
3. Server Certificate: The server sends a certificate containing its public key. The client validates the certificate and its trust chain.
4. ServerKeyExchange: The server sends additional key-exchange information when required, such as parameters for Diffie-Hellman exchange.
5. CertificateRequest: The server may request a certificate from the client.
6. ServerHelloDone: The server indicates that its initial negotiation messages are complete.
7. Client Certificate: The client sends its certificate if requested.
8. ClientKeyExchange: The client sends key-exchange data, allowing both parties to derive a shared secret.
9. CertificateVerify: The client proves possession of the private key corresponding to its certificate.
10. ChangeCipherSpec and Finished: Both parties activate the negotiated keys and verify the integrity of the handshake transcript.

After successful verification, application data is transmitted through the SSL Record Protocol.

Transport Layer Security (TLS) is a standardized successor to SSL that provides secure communication over an unreliable or untrusted network.

Similarities:

• Both operate above TCP and below application protocols.
• Both support server authentication and optional client authentication.
• Both provide confidentiality, integrity, and secure key establishment.
• Both use a record protocol and a handshake procedure.

Differences and improvements in TLS include:

• TLS uses a more carefully specified key derivation process.
• TLS defines stronger and more flexible pseudorandom functions for generating keys.
• TLS uses HMAC-based integrity protection in traditional versions.
• TLS provides clearer alert codes and improved error handling.
• TLS removes or discourages weak and obsolete algorithms.
• Modern TLS versions support authenticated encryption modes such as AES-GCM and ChaCha20-Poly1305.
• TLS 1.3 reduces the number of handshake messages and removes many insecure legacy options.

SSL is now considered obsolete because of known weaknesses. In modern systems, the term TLS should be used, although applications and users sometimes continue to say SSL informally.

IPSec is a collection of protocols and algorithms used to protect IP packets at the network layer. It can secure communication between hosts, between gateways, or between a host and a gateway.

IPSec provides:

• Data origin authentication.
• Connectionless integrity.
• Confidentiality through encryption.
• Limited traffic-flow confidentiality.
• Replay protection.
• Access control based on security policies.

Its main components are:

• Authentication Header (AH): Provides integrity, data-origin authentication, and replay protection, but does not encrypt the payload.
• Encapsulating Security Payload (ESP): Provides confidentiality and can also provide integrity, authentication, and replay protection.
• Internet Key Exchange (IKE): Negotiates security associations and establishes cryptographic keys.
• Security Policy Database (SPD): Specifies how different traffic should be handled.
• Security Association Database (SAD): Stores the parameters of active security associations.

Because IPSec operates at the IP layer, applications usually do not need to be modified. It can protect many upper-layer protocols simultaneously.

Transport mode and tunnel mode are the two operating modes of IPSec.

In transport mode, an AH or ESP header is inserted between the IP header and the upper-layer protocol data. The original IP header is retained.

In tunnel mode, the complete original IP packet, including its original IP header, is treated as the payload of a new packet. A new outer IP header is added for routing between IPSec endpoints.

Tunnel mode provides greater protection for internal addressing and is commonly used in virtual private networks. Transport mode is more efficient and is suitable when the communicating endpoints themselves implement IPSec.

Authentication Header (AH) provides authentication and integrity protection for IP packets. It does not provide confidentiality because it does not encrypt the payload.

Important AH fields include:

• Next Header: Identifies the protocol that follows AH.
• Payload Length: Specifies the length of the AH header.
• Security Parameters Index (SPI): Identifies the security association used for processing the packet.
• Sequence Number: Helps detect replayed packets.
• Authentication Data: Contains the integrity check value calculated over the protected packet.

AH provides:

• Data origin authentication: Confirms that the packet came from the claimed sender.
• Connectionless integrity: Detects unauthorized modification.
• Anti-replay protection: Uses sequence numbers and a replay window.

The integrity calculation covers the payload and fields of the IP header that do not change during routing. Mutable fields, such as some header checksums or routing-related values, are excluded or treated specially. AH is incompatible with network address translation in many common configurations because changes to the IP header can invalidate the authentication value.

Encapsulating Security Payload (ESP) is an IPSec protocol that protects IP data using encryption and can also provide authentication and integrity.

An ESP packet generally contains:

• SPI: Identifies the security association.
• Sequence Number: Provides anti-replay protection.
• Payload Data: Contains the protected upper-layer data or an encapsulated original IP packet.
• Padding: Provides block-alignment and may help hide the actual payload length.
• Pad Length: Indicates the number of padding bytes.
• Next Header: Identifies the type of data carried in the payload.
• Authentication Data: An integrity check value when authentication is enabled.

ESP provides:

• Confidentiality by encrypting the payload.
• Data-origin authentication when authentication is enabled.
• Connectionless integrity for the protected fields.
• Anti-replay protection through sequence numbers.
• Limited traffic-flow confidentiality, especially in tunnel mode, by hiding the original packet contents and internal addresses.

In modern deployments, authenticated encryption algorithms such as AES-GCM are commonly used with ESP to provide confidentiality and integrity together.

ESP is preferred when the contents of the communication must remain confidential. It is also preferred for most VPN deployments because it supports encryption and works more naturally with network address translation techniques. AH may be selected when encryption is unnecessary and authentication of selected IP packet fields is specifically required.

In practice, ESP with authenticated encryption is usually preferred because it supplies confidentiality and integrity in a single modern cryptographic construction.

A Security Association (SA) is a logical relationship that defines how IPSec protects traffic flowing in one direction between two endpoints.

An SA is identified by the combination of:

• Security Parameters Index (SPI).
• Destination IP address.
• Security protocol, such as AH or ESP.

Important SA parameters include:

• The IPSec protocol in use.
• Transport or tunnel mode.
• Encryption algorithm and encryption key.
• Integrity or authentication algorithm and key.
• Lifetime measured in time or amount of data.
• Sequence-number counter.
• Anti-replay window.
• Traffic selectors and tunnel endpoint information.

An SA is unidirectional because the security parameters and keys used for outbound traffic may differ from those used for inbound traffic. Therefore, a two-way protected conversation normally requires two SAs: one for each direction. The Security Association Database (SAD) stores the active SA parameters.

The Security Policy Database (SPD) contains rules that determine how IP traffic should be handled. Each rule is selected using traffic selectors such as source address, destination address, protocol, and port numbers.

An SPD rule normally specifies one of three actions:

• DISCARD: Drop the packet.
• BYPASS: Send the packet without IPSec protection.
• PROTECT: Apply AH or ESP according to a specified security policy.

Outbound processing generally follows these steps:

1. The system examines the packet's selectors.
2. It searches the SPD for the highest-priority matching rule.
3. If the action is DISCARD, the packet is dropped.
4. If the action is BYPASS, the packet is transmitted normally.
5. If the action is PROTECT, the system identifies an appropriate SA in the SAD.
6. If no suitable SA exists, IKE negotiates or creates one.
7. The packet is processed using the selected SA and transmitted.

For inbound packets, the system uses the SPI and protocol to locate the SA in the SAD, verifies the packet, applies anti-replay checks, and then checks that the traffic conforms to the SPD.

IPSec key management establishes, distributes, refreshes, and removes the keys used by AH and ESP. Manual key configuration is possible for small networks, but automated management is normally used in production systems.

IKE performs the following functions:

• Negotiates cryptographic algorithms and authentication methods.
• Authenticates the communicating peers using pre-shared keys, digital certificates, or another approved method.
• Establishes a secure control channel.
• Performs a Diffie-Hellman exchange or another approved key agreement method.
• Derives keys for protecting IPSec traffic.
• Creates and maintains the required security associations.
• Renews or deletes SAs when their lifetimes expire.

A simplified IKE exchange establishes an authenticated and confidential negotiation channel first. The peers then agree on the parameters for one or more child SAs used by ESP or AH. Key refresh limits the amount of data protected by a single key and reduces the impact of a possible key compromise.

Consider two gateways connecting private networks through an untrusted public network.

Tunnel establishment and use involve:

1. The gateways identify traffic that requires protection by consulting their SPD entries.
2. They authenticate each other using pre-shared keys, digital certificates, or another authentication method.
3. IKE negotiates algorithms, lifetimes, authentication methods, and key-exchange parameters.
4. The gateways derive shared secret keys and create inbound and outbound child SAs.
5. A packet from the first private network is selected for protection.
6. In tunnel mode, the complete original IP packet is encrypted and optionally authenticated as the ESP payload.
7. A new outer IP header containing the gateway addresses is added.
8. The receiving gateway uses the outer header to route the packet, locates the SA using the SPI, verifies integrity and replay status, decrypts the payload, and removes the outer header.
9. The original packet is forwarded into the destination private network.

The public network can see the gateway addresses and some packet metadata, but it cannot normally read the original payload or the internal source and destination addresses. Tunnel mode therefore provides secure virtual private network communication.

A replay attack occurs when an attacker captures a valid message and retransmits it later to produce an unauthorized effect. The attacker may not need to decrypt or modify the message.

Protection in SSL/TLS:

• Records contain sequence numbers maintained as part of the connection state.
• Integrity protection covers the record sequence number and content.
• A repeated or reordered record causes an integrity or sequence validation failure.
• Fresh random values and newly negotiated session keys reduce the usefulness of captured handshake messages.
• Session identifiers and secure renegotiation mechanisms help prevent unauthorized reuse of sessions.

Protection in IPSec:

• Every AH or ESP packet contains a monotonically increasing sequence number.
• The receiver maintains an anti-replay window.
• Packets below the accepted window or packets already received are rejected.
• Packets that are too far ahead may advance the window after successful authentication.
• The sequence number is included in integrity protection, preventing an attacker from changing it without detection.

Replay protection is effective only when integrity authentication is also correctly implemented and sequence numbers are managed without unsafe reuse.

The SSL/TLS Record Protocol converts application data into protected records.

Typical processing steps are:

1. Fragmentation: Application data is divided into records of an acceptable size.
2. Optional compression: In older protocol designs, the fragment may be compressed. Modern deployments generally disable compression because of information-leakage risks.
3. Integrity protection: A message authentication code is calculated over the sequence number, record type, protocol version, length, and fragment. Modern TLS commonly uses authenticated encryption instead.
4. Encryption: The fragment and its integrity data are encrypted using the negotiated session key and cipher.
5. Transmission: The protected record is sent over the TCP connection.

At the receiver, the record is checked for valid sequence and integrity, decrypted, decompressed if necessary, and reassembled for the application.

Confidentiality is provided by encryption, while integrity and authentication are provided by the MAC or authenticated-encryption tag. The keys and algorithms are selected during the handshake.