Digital Lecture Notes

Cryptography & Network Security (BCS703)

VTU Syllabus:

M-4

User Authentication: Remote user authentication principles, Kerberos, Remote user

authentication using asymmetric encryption.

Web security consideration, Transport layer security. Email Threats and comprehensive email
security, S/MIME, Pretty Good Privacy

What is User Authentication?

User authentication is the process of establishing the identity of an individual who wants to
have access to a particular system or service.
It involves a process of ensuring that the user claiming to be a specific personality is substantial
through proving credentials like passwords, biometric data, security tokens, or other
authenticity factors.

Definition (RFC 4949): The process of verifying an identity claimed by or for a system entity.

Objectives: Fundamental building block and primary line of defense in computer security, forming
the basis for access control and user accountability.

An authentication process consists of two steps:

• Identification step: Presenting an identifier to the security system. (Identifiers should be

assigned carefully, because authenticated identities are the basis for other security services,
such as access control service.)

• Verification step: Presenting or generating authentication information that corroborates the

binding between the entity and the identifier.”

In essence, identification is the means by which a user provides a claimed identity to the
system; user authentication is the means of establishing the validity of the claim.

KIT/CSE/ BCS703/M4/BJ Page 1

Note that user authentication is distinct from message authentication.

There are four general means of authenticating a user's identity, which can be used alone
or in combination:

• Something the individual knows: Examples includes a password, a personal identification

number (PIN), or answers to a prearranged set of questions.

• Something the individual possesses: Examples include electronic keycards, smart cards,
and physical keys. This type of authenticator is referred to as a token.

• Something the individual is (static biometrics): Examples include recognition by

fingerprint, retina, and face.

• Something the individual does (dynamic biometrics): Examples include recognition by

voice pattern, handwriting characteristics, and typing rhythm.

Remote user authentication principles:

Remote user authentication principles include confidentiality, integrity, and mutual authentication
to ensure secure communication. This involves an initial identification and verification step,
where the user proves their identity to the system, which in turn proves its identity back to the
user. Principles also focus on protecting against attacks, such as using cryptography to prevent
eavesdropping, ensuring timeliness to prevent replay attacks, and maintaining the confidentiality of
credentials.

Core principles

 Identification:
The user presents an identifier to the system to claim an identity.
 Verification:
The user provides authentication information, such as a password or biometric data, to
prove they are who they claim to be.
 Confidentiality:
Credentials and authentication data must be kept secret during transmission, typically
achieved through encryption like SSL/TLS.
 Integrity:
Authentication data must not be altered in transit. This is protected using cryptographic
checksums or hashing.
 Mutual Authentication:
Both the user and the system verify each other's identities to protect against man-in-the-
middle attacks.

 Replay Attack Resistance:

The system must be able to detect and reject old authentication messages, which can be

KIT/CSE/ BCS703/M4/BJ Page 2

 done using timestamps, sequence numbers, or challenge-response protocols.
 Non-repudiation:
The user should not be able to deny that they performed an action after successful
authentication.

Key techniques and protocols:

 Multi-factor Authentication (MFA):

Combines multiple types of credentials to verify identity (e.g., something you know,
something you have, something you are).

 Kerberos:
A network authentication protocol that provides strong authentication for client/server
applications using symmetric key cryptography and tickets.

 Public Key Cryptography:

Uses a pair of keys, one public and one private, for secure communication, such as RSA.

 Biometric Authentication:
Uses unique biological characteristics, like fingerprints, to verify identity.
 Remote Authentication Dial-in User Service (RADIUS):
A networking protocol that provides centralized Authentication, Authorization, and
Accounting (AAA) management for users connecting to a network.

 Virtual Private Networks (VPNs):

Create an encrypted tunnel over a public network to secure remote access.
 Single Sign-On (SSO):
Allows a user to log in once to access multiple independent software systems.

The NIST Model for Electronic User Authentication (NIST SP 800-63-2):

Definition: Establishing confidence in user identities presented electronically to an information

system.

Purpose: Authenticated identity determines authorization for functions (e.g., database

transactions, resource access).

Scope: Applies to both remote (e.g., Internet) and local (e.g., LAN) authentication.

KIT/CSE/ BCS703/M4/BJ Page 3

Architectural Model:

Fig5.1.E-Authentication Architecture Model

[Link]: User (Applicant) applies to a Registration Authority (RA).

▪ RA: Trusted entity that establishes and vouches for the applicant's identity to a Credential Service
Provider (CSP).

[Link] Issuance: CSP interacts with the applicant (now a Subscriber) and issues an electronic
credential.

▪ Credential: A data structure binding an identity and attributes to a token possessed by the subscriber

. ▪ Token: Could be an encryption key or encrypted password, issued by CSP, generated by subscriber,
or from a third party. Token/credential used in future authentications.

3. Authentication Process:

▪ Claimant: The party to be authenticated (the Subscriber).

▪ Verifier: The party verifying the identity.

4. Authentication Protocol: Claimant demonstrates possession/control of the token to the Verifier.

▪ Assertion: Verifier, upon successful verification, passes an assertion (identity info, attributes) about
the Subscriber to the Relying Party (RP).
▪ Relying Party (RP): Uses the authenticated information from the Verifier to make access control or
authorization decisions.

Mutual Authentication:

Enables communicating parties to mutually satisfy themselves about each other's identity and
exchange session keys.

KIT/CSE/ BCS703/M4/BJ Page 4

Central Issues:
1. Confidentiality: Essential identification and session-key information must be encrypted to
prevent masquerade and key compromise. Requires prior existence of secret or public keys.

2. Timeliness: Crucial due to the threat of message replays. Replays can compromise session keys,
impersonate parties, or simply disrupt operations.

3. Replay Attack Examples [GONG93]:

o Simple copy and replay.
o Replaying a timestamped message within the valid window (can be logged).
o Replaying a timestamped message within the valid window, but suppressing the original
(difficult to detect).

4. Backward replay without modification (reply to sender when symmetric encryption is used and
sender can't distinguish).

One-Way Authentication (Email Example):

Email Nature: Store-and-forward, allowing asynchronous communication.

Header/Envelope: Must be in the clear for mail handling protocols (e.g., SMTP, X.400).
Encryption Requirement: Desirable that mail-handling protocol not access plaintext, meaning mail-
handling system should not have the decryption key. Message content should be encrypted such that
only the recipient can decrypt.
Authentication Requirement: Recipient typically wants assurance that the message is from the
alleged sender.

Kerberos:

 Kerberos is an authentication service developed at MIT's Project Athena.

 Kerberos provides a centralized authentication server whose function is to authenticate
users to servers and servers to users.
 In Kerberos Authentication server and database is used for client authentication.
 Kerberos runs as a third-party trusted server known as the Key Distribution Center
(KDC). Each user and service on the network is a principal.

The main components of Kerberos are:

 Authentication Server (AS): The Authentication Server performs the initial authentication and
ticket for Ticket Granting Service.
 Database: The Authentication Server verifies the access rights of users in the database.
 Ticket Granting Server (TGS): The Ticket Granting Server issues the ticket for the Server

KIT/CSE/ BCS703/M4/BJ Page 5

Working of Kerberos:

Fig5.2. Overview of Kerberos

Applications of Kerberos:
 User Authentication: User Authentication is one of the main applications of Kerberos. Users
only have to input their username and password once with Kerberos to gain access to the
network.
 Single Sign-On (SSO): Kerberos offers a Single Sign-On (SSO) solution that enables users to
log in once to access a variety of network resources.

 Mutual Authentication: Before any data is transferred, Kerberos uses a mutual

authentication technique to make sure that both the client and server are authenticated.

 Authorization: Kerberos also offers a system for authorization in addition to authentication.

After being authenticated, a user can submit service tickets for certain network resources.
Users can access just the resources they have been given permission to use thanks to
information about their privileges and permissions contained in the service tickets.

 Network Security: Kerberos offers a central authentication server that can regulate user
credentials and access restrictions, which helps to ensure network security.
KIT/CSE/ BCS703/M4/BJ Page 6
Limitations of Kerberos
 Each network service must be modified individually for use with Kerberos
 It doesn't work well in a timeshare environment
 Secured Kerberos Server
 Requires an always-on Kerberos server
 Stores all passwords are encrypted with a single key
 Assumes workstations are secure
 May result in cascading loss of trust.
 Scalability

Remote user authentication using asymmetric encryption:

It is a mechanism in which the remote server verifies the legitimacy of a user over non-secure
communication channel.
There are two types of remote user authentication:

Fig5.3: Remote User Authentication

[Link] Authentication:

Challenges in Public-Key Based Key Distribution:

The session-key distribution protocol assumes that each party already possesses the current public key
of the other. This assumption may not always be practical.

A. Protocol using Timestamps [DENN81]:

KIT/CSE/ BCS703/M4/BJ Page 7

 o Entities:
▪ A: Initiator
▪ B: Responder
▪ AS: Authentication Server (provides public-key certificates)

o Prior Assumption: Each party has the AS's public key (to verify certificates).
o Steps:

1. A -> AS: ID_A || ID_B (A requests B's public key certificate from AS)

2. AS -> A: E(PR_as, [ID_A || PU_a || T]) || E(PR_as, [ID_B || PU_b || T])

AS sends A's and B's public-key certificates (ID, Public Key, Timestamp) signed with AS's
private key (PR_as).

3.A -> B: E(PR_as, [ID_A || PU_a || T]) || E(PR_as, [ID_B || PU_b || T]) || E(PU_b, E(PR_a, [Ks || T]))

 A sends both certificates to B.

 A generates a session key Ks, encrypts it with its own private key (PR_a) and a timestamp T.
 This entire encrypted block is then encrypted with B's public key (PU_b).

B. Protocol using Nonces [WOO92a] (Original Flawed Version):

o Entities:
▪ A: Initiator
▪ B: Responder
▪ KDC: Key Distribution Center (similar to AS, but specifically for key
distribution and certificates))

o Steps:
1. A -> KDC: ID_A || ID_B (A informs KDC of desire to connect with B)

2. KDC -> A: E(PR_auth, [ID_B || PU_b]) (KDC sends B's public-key certificate to A, signed
with K DC's private key PR_auth)

3. A -> B: E(PU_b, [N_a || ID_A]) (A sends its ID and a nonce N_a to B, encrypted with B's
public key PU_b)

4. B -> KDC: ID_A || ID_B || E(PU_auth, N_a) (B requests A's certificate and a session key,
sending N_a encrypted with KDC's public key PU_auth to bind it to the key)

5. KDC -> B: E(PR_auth, [ID_A || PU_a]) || E(PU_b, E(PR_auth, [N_a || Ks || ID_B]))

▪ KDC sends A's certificate to B.

KIT/CSE/ BCS703/M4/BJ Page 8

 ▪ KDC generates session key Ks. The triple {N_a, Ks, ID_B} is signed by KDC (PR_auth) to
prove origin, and then encrypted with B's public key (PU_b) for confidentiality to B. This binds
Ks to N_a (from A) and ID_B.

6. B -> A: E(PU_a, [E(PR_auth, [(N_a || Ks || ID_B)]) || N_b])

▪ B relays the signed session key information (still signed by KDC) to A.

▪ B also includes its own nonce N_b, and everything is encrypted with A's public key (PU_a).

7. A -> B: E(Ks, N_b)

(A decrypts, recovers Ks, encrypts N_b with Ks, and sends back to B to prove knowledge of Ks)

[Link]-Way Authentication (using Asymmetric Encryption for Email/Messages):

Basic Approaches :
o Confidentiality: A -> B: E(PU_b, M) (Sender needs recipient's public key).
o Authentication: A -> B: M || E(PR_a, H(M)) (Recipient needs sender's public key).
o Both: A -> B: E(PU_b, [M || E(PR_a, H(M))]) (Both public keys needed).
o Efficiency Concern: Applying public-key algorithms directly to long messages (M) is
computationally expensive.

Web security consideration, Transport layer security. Email Threats and comprehensive email
security, S/MIME, Pretty Good Privacy

Web security consideration:

What is Web Security?

 World Wide Web is fundamentally a client/server application running over the Internet and
TCP/IP intranets.

 Web security is about keeping websites, servers, users, and devices safe
from cyberattacks that come through the internet.

 These attacks can include things like viruses, fake emails (phishing), and other harmful
activities that can steal or leak important information.

 To stay protected, web security uses different tools and methods, such as firewalls, systems

KIT/CSE/ BCS703/M4/BJ Page 9

 that block suspicious activity, filters that block dangerous websites, and antivirus
software.
 It also covers the security of Web Apps, APIs, and cloud systems to keep everything
running safely online.

For example- when we are transferring data between client and web server and we have to protect
that data, that security of data is our web security.

Web Security Threats:

Web security threats can be categorized in several ways: Passive vs. Active Attacks:

o Passive Attacks: Involve eavesdropping on network traffic between browser and server, or
gaining unauthorized access to restricted information on a Web site.

o Active Attacks: Include impersonating other users, altering messages during transit between client
and server, or modifying information directly on a Web site.

Various approaches exist for providing Web security, differing in scope and placement within the
TCP/IP protocol stack

Fig5.4:

KIT/CSE/ BCS703/M4/BJ Page 10

IP Security (IPsec) (Figure a):

 Operates at the IP layer.

 Transparent to end users and applications.
 Provides a broad solution for network-layer security.

Security Just Above TCP (Fig b) :

 Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS).
 o Sits between the application layer and the TCP layer.

Application-Specific Security Services (Figure 17.1c):

o Security services are embedded directly within the particular application (e.g., within a Web
server application or a browser plugin).
o Allows the security service to be precisely tailored to the specific needs and functionalities of that
given application.

Transport layer security:

Transport Layer Security (TLS), currently at Version 1.2 (RFC 5246), is an Internet standard that
evolved from the commercial Secure Sockets Layer (SSL) protocol. While SSL implementations
still exist, it has been deprecated by the IETF and is mostly disabled by modern software for security
reasons.
TLS is a general-purpose security service built as a set of protocols that operate over TCP. It can
be implemented in two ways:

1. Transparently: As part of the underlying protocol suite, making it invisible to applications.

2. Embedded: Directly within specific applications, which is more common (e.g., most web
browsers and servers have built-in TLS support).

TLS Architecture
TLS is designed to leverage TCP's reliable end-to-end service to provide a secure communication
channel. It's not a single protocol but rather a two-layered architecture .

KIT/CSE/ BCS703/M4/BJ Page 11

 Fig 5.5. TLS Architecture

TLS Record Protocol:

This lower layer provides fundamental security services—confidentiality (through encryption)

and message integrity (through MACs)—to higher-layer protocols as-

• Confidentiality: Uses a shared secret key (defined by the Handshake Protocol) for conventional
(symmetric) encryption of TLS payloads.

• Message Integrity: Uses another shared secret key (also from Handshake Protocol) to compute a
Message Authentication Code (MAC).

Operation:

Fig 5.6 TLS Record Protocol Operation

1. Fragmentation: Upper-layer messages are broken into blocks of 2^14 bytes (16,384 bytes)
or less
2. Compression (Optional): Lossless compression may be applied
3. MAC Calculation: An HMAC (Hash-based Message Authentication Code) is computed
over the compressed data.
4. [Link]: The compressed message plus the MAC are encrypted using symmetric
encryption .
AES (128, 256-bit), 3DES (168-bit) for block ciphers; RC4-128 (128-bit) for stream
ciphers.
5. Header Prepend: A header is added, containing when Content Type (8 bits) Indicates the
higher-layer protocol (e.g., change_cipher_spec, alert, handshake, application_data).

Higher-Layer TLS Protocols: These protocols manage the TLS exchanges themselves and

KIT/CSE/ BCS703/M4/BJ Page 12

include:

Handshake Protocol:
The Handshake Protocol occurs before any application data is transmitted. The most complex part,
used for authentication and negotiation of security parameters.

This is the most intricate part of TLS. Its main functions are:

 Authentication: Client and server authenticate each other.

 Negotiation: Agree on encryption and MAC algorithms.
 Key Exchange: Establish cryptographic keys to protect application data.

The handshake typically proceeds in four phases (Figure 17.6):

Phase 1: Establish Security Capabilities:

It includes following:
 Client sends a client_hello message
 Server sends a server_hello message with selected parameters
 Key Exchange Methods (within CipherSuite)

KIT/CSE/ BCS703/M4/BJ Page 13

 Fig5.7. Handshake Protocol Action

Phase 2: Server Authentication and Key Exchange:

 Server Certificate (if needed): Server sends its X.509 certificate(s) for authentication
 Server Key Exchange (if needed): Sent if the certificate doesn't contain enough information
for key exchange
 Certificate Request (optional): Non-anonymous servers can request a certificate from the
client,
 Server Done: Server sends server_done to signal the end of its initial messages

Phase 3: Client Authentication and Key Exchange:

 Client Verification: Client verifies the server's certificate (if received) and accepted
server_hello parameters.
 Client Certificate (if requested): Client sends its certificate or a no _certificate alert.
 Client Key Exchange: Client sends message content based on agreed key exchange
RSA, Anonymous Diffie-Hellman

 Certificate Verify (optional): Client sends this message if it provided a certificate with signing
capability

Phase 4: Finish

Client Finished: Client immediately sends a finished message using the new algorithms

Change Cipher Spec Protocol:

 It is Simplest Protocol
 Main purpose is to signal that the pending state parameters (negotiated during the
handshake) should be copied into the current state, effectively switching to the newly
agreed-upon cipher suite and keys for subsequent communication.
 Consists of a single message containing a single byte with value 1 (Figure 17.5a).

Fig 5.8. TLS Record Format

KIT/CSE/ BCS703/M4/BJ Page 14

Alert Protocol :

• Purpose: Used to convey TLS-related warnings or fatal errors to the peer entity.
• Format:
Two bytes (Fig 5.9b):
o First Byte: Severity (warning (1) or fatal (2)).
o Second Byte: Specific alert code.

Fig5.9. TLS Record Protocol Payload

Fatal Alerts: If the level is fatal, the TLS connection is immediately terminated.
Warning Alerts: These do not immediately terminate the connection but indicate issues.

Heartbeat Protocol in TLS/DTLS :

 In computer networks, a heartbeat is a periodic signal indicating normal operation or for
synchronization.
 A heartbeat protocol is typically used to monitor the availability of a protocol entity
 Runs on top of the TLS Record Protocol.
 Consists of two message types: heartbeat_request and heartbeat_response.
 Major purpose:
 Liveness Check
 Firewall Keep-Alive
 Path MTU Discovery (via Padding)
 Packet Loss Handling (for DTLS)

SSL/TLS Attacks

1. Attacks on the Handshake Protocol:

i. These attacks aim to compromise the initial negotiation and authentication
phase.
2. Attacks on the Record and Application Data Protocols: These target the secure data
transmission phase after the handshake which includes-
BEAST (Browser Exploit Against SSL/TLS
CRIME (Compression Ratio Info-leak Made Easy)

KIT/CSE/ BCS703/M4/BJ Page 15

 3. Attacks on the Public Key Infrastructure (PKI): o These focus on compromising the
validity checking of X.509 certificates

4. DoS Attack: This attack overloads a server by sending numerous SSL/TLS handshake
requests or renegotiation requests

Email Threats and comprehensive email security:

For both organizations and individuals, email is both pervasive and especially vulnerable to a wide
range of security threats. In general terms, email security threats can be classified as follows:

 Authenticity-related threats: Could result in unauthorized access to an enterprise’s email

system.
 Integrity-related threats: Could result in unauthorized modification of email content.
 Confidentiality-related threats: Could result in unauthorized disclosure of sensitive
information.
 Availability-related threats: Could prevent end users from being able to send or receive
email.

Email Threats and Mitigations:

KIT/CSE/ BCS703/M4/BJ Page 16

Standardized Protocols for Comprehensive Email Security:

NIST SP 800-177 recommends using a combination of standardized protocols to counter these diverse
email threats. These include:

 STARTTLS:
An SMTP (Simple Mail Transfer Protocol) security extension. It provides authentication,
integrity, non-repudiation (via digital signatures), and confidentiality (via encryption)

 S/MIME (Secure/Multipurpose Internet Mail Extensions): It provides authentication,

integrity, non-repudiation (via digital signatures), and confidentiality (via encryption) of the
message body carried in SMTP messages.

 DNS Security Extensions (DNSSEC): Provides authentication and integrity protection of

DNS data.

 DNS-based Authentication of Named Entities (DANE): Designed to address weaknesses in

the traditional Certificate Authority (CA) system.

 DomainKeys Identified Mail (DKIM): Enables a Mail Transfer Agent (MTA) to digitally
sign selected headers and the body of an email message.

S/MIME:

Secure/Multipurpose Internet Mail Extension (S/MIME) is a security enhancement to the MIME

Internet email format standard based on technology from RSA Data Security.

S/MIME uses the following message content types, which are defined in RFC 5652, Cryptographic
Message Syntax:
 Data: Refers to the inner MIME-encoded message content, which may then be encapsulated
in a SignedData, EnvelopedData, or CompressedData content type.
 Signed Data: Used to apply a digital signature to a message.
 Enveloped Data: This consists of encrypted content of any type and encrypted content
encryption keys for one or more recipients.
 Compressed Data: Used to apply data compression to a message.

Summary of S/MIME Services:

S/MIME provides for four message-related services: authentication, confidential ity, compression, and
email compatibility

KIT/CSE/ BCS703/M4/BJ Page 17

Cryptographic Algorithms used in S/MIME:

 MUST: The definition is an absolute requirement of the specification. An implementation

must include this feature or function to be in conformance with the specification.

 SHOULD: There may exist valid reasons in particular circumstances to ignore this feature
or function, but it is recommended that an implementation include the feature or function.

KIT/CSE/ BCS703/M4/BJ Page 18

Pretty Good Privacy:

An alternative email security protocol is Pretty Good Privacy (PGP), which has essentially the
same functionality as S/MIME. PGP was created by Phil Zimmerman and implemented as a product
first released in 1991. It was made available free of charge and became quite popular for personal
use

Significant Differences between S/MIME and OpenPGP: While both S/MIME and OpenPGP aim to
provide email security, they differ fundamentally in two key areas:

[Link] Certification:

 S/MIME: Relies on X.509 certificates issued by Certificate Authorities (CAs) or local

agencies delegated authority by CAs. Trust in an S/MIME certificate is established through
a valid PKIX (Public Key Infrastructure X.509) chain leading back to a trusted root CA.
This creates a hierarchical trust model.

 OpenPGP: Users generate their own OpenPGP public and private key pairs. Instead of
relying on a central CA, users solicit signatures for their public keys from individuals or
organizations they know and trust. An OpenPGP public key is considered trusted if it has
been signed by another OpenPGP public key that is already trusted by the recipient. This
decentralized trust model is known as the "Web-of Trust."

[Link] Distribution:
 S/MIME: The sender's public key is typically included with each message (within the
X.509 certificate). This simplifies key distribution for the recipient.

 OpenPGP: OpenPGP does not include the sender's public key with each message.
Therefore, recipients must separately obtain the sender's public key to verify messages or
send encrypted replies.

This can be done through:

▪ TLS-protected websites: Many organizations post their OpenPGP keys on secure websites,
requiring manual download and addition to the recipient's OpenPGP client.

▪ OpenPGP public key servers: These servers maintain databases of PGP public keys indexed by
email address. Anyone can post a public key, and that key can contain any email address. It's important
to note that these key servers do not vet the keys, so users must rely on the Web-of-Trust to decide
whether to trust a given public key obtained from these servers.

KIT/CSE/ BCS703/M4/BJ Page 19