0% found this document useful (0 votes)
17 views32 pages

Module - 4 Authentication Protocols & Digital Signature Schemes

Module 4 covers authentication protocols and digital signature schemes, detailing user and entity authentication methods, including password-based and challenge-response mechanisms. It explains the concept of digital signatures, their properties, and various algorithms like DSA and RSA, along with the importance of secure communication protocols. Additionally, it addresses potential vulnerabilities such as replay attacks and outlines countermeasures to enhance security.

Uploaded by

harshspam29
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views32 pages

Module - 4 Authentication Protocols & Digital Signature Schemes

Module 4 covers authentication protocols and digital signature schemes, detailing user and entity authentication methods, including password-based and challenge-response mechanisms. It explains the concept of digital signatures, their properties, and various algorithms like DSA and RSA, along with the importance of secure communication protocols. Additionally, it addresses potential vulnerabilities such as replay attacks and outlines countermeasures to enhance security.

Uploaded by

harshspam29
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 32

Module - 4

Authentication Protocols & Digital


Signature Schemes
Contents
4.1 User Authentication, Entity Authentication:
Password Base, Challenge Response Based

4.2 Digital Signature, Attacks on Digital Signature,


Digital Signature Scheme: RSA
User and Entity Authentication
Applications providing Authentication:
● Hash & MAC
● Digital Signature
● X.509- Digital Signature
● Kerberos
Feature User Authentication Entity Authentication
Who is being A human user trying to Any entity, which could
authenticated? access a system or be a user, device, or
service. service.
Common Methods Passwords, PINs, Public-key cryptography,
biometrics, security digital certificates, shared
questions. secrets.
Example Logging into a website or Server authenticating a
an application. client using SSL/TLS or
devices authenticating
each other in a network.
Use Case Individual users verifying Systems, devices, and
their identity. services verifying the
identity of each other.
Focus Ensures that the person Ensures that the entity
accessing the system is (user, device, or system)
legitimate. is legitimate.
Examples
User Authentication is used in:
○ Online banking
○ Email login
○ Social media login
Entity Authentication is used in:
○ SSL/TLS Certificates: A server authenticates itself
to a client through an SSL/TLS certificate to ensure
secure communication.
○ Device Authentication: IoT devices authenticate
with each other using certificates or keys to ensure
a trusted communication channel.
○ API calls: A service authenticates a third-party
application through API keys or OAuth tokens.
Password-Based Authentication
Password-based authentication is a method that
requires the user to enter their credentials —
username and password — in order to confirm their
identity. Once credentials are entered, they are
compared against the stored credentials in the
system's database, and the user is only granted
access if the credentials match.
Password-based authentication systems follows:
○ The user creates an account by providing a unique
identifier as email, username, or phone number.
○ The user is prompted to create a password, which
must meet certain complexity requirements.
○ The set of credentials is stored in the system’s
database, usually in an encrypted form.
○ When a user tries to log in, the authentication
system checks their submitted credentials against
those stored in its database.
○ If they match, the user is granted access.
○ If they don’t match, the user will be denied entry
and may be prompted to re enter their information
or reset their password in case they forgot it.
Challenge Response Authentication
Mechanism (CRAM)
○ CRAM is the most often used way to authenticate
actions.
○ They are a group of protocols in which one side
presents a challenge(to be answered) and the other
side must present a correct answer(to be
checked/validated) to the challenge in order to get
authenticated.
The authentication process involves these steps:
○ A user expresses interest in using a protected
network or system.
○ The CRAM presents the user with a challenge,
prompting a response.
○ The user attempts the challenge and enters a
response.
○ The correct response allows entry; an incorrect
response denies it.
Use cases –

○ To differentiate between a computer and a human:


An image is presented and user would be asked to
input by reading characters. The input is then
matched with the actual characters to prevent bots
from entering the system.
○ In training Machine Learning models: An image is
pieced and jumbled up and presented to the user
for some kind of verification that a real human user
can do. The answer is matched with the answer
given by ML model. Eg.Google CAPTCHA
authentication.
○ For login (authentication) purposes: The password
input is matched with the correct password for
matching.
Feature Password-based Challenge-Response-based
Authentication Authentication

Security Less secure (vulnerable to More secure (especially when


attacks if passwords are using encryption)
weak)

Ease of Use Easy and familiar for users May require additional user
interaction or setup

Implementation Cost Low cost and simple to More complex and higher cost
implement due to encryption mechanisms

Susceptibility to High (users may disclose Low (since challenges are


Phishing passwords) dynamic and not fixed)

Resistance to Replay Low (password can be High (challenges are typically


Attacks reused) unique and one-time)
Digital Signatures
Message authentication protects two parties who
exchange messages from any third party.
● However, it does not protect the two parties against
each other.
Digital signatures provide the ability to:
● verify author, date & time of signature
● authenticate message contents
● be verified by third parties to resolve disputes
hence include authentication function with additional
capabilities
Definition - Digital Signature
A digital signature is a hash value that has
been encrypted with the sender’s private
key. The act of signing means encrypting
the message’s hash value with a private key
(since no one else knows the sender’s
private key).
Digital Signature Properties
must depend on the message signed
must use information unique to sender
● to prevent both forgery and denial
must be relatively easy to produce
must be relatively easy to recognize & verify
be computationally infeasible to forge
● with new message for existing digital signature
● with fraudulent digital signature for given message
be practical save digital signature in storage
Direct Digital Signatures
involve only sender & receiver
assumed receiver has sender’s public-key
digital signature made by sender signing entire message
or hash with private-key
can encrypt using receiver's public-key
important that sign first then encrypt message &
signature
security depends on sender’s private-key
Arbitrated Digital Signatures
involves use of arbiter A
● validates any signed message
● then dated and sent to recipient
requires suitable level of trust in arbiter
can be implemented with either private or public-key
algorithms
arbiter may or may not see message
Authentication Protocols
used to convince parties of each others identity and to
exchange session keys
may be one-way or mutual
key issues are
● confidentiality – to protect session keys
● timeliness – to prevent replay attacks
published protocols are often found to have flaws and
need to be modified
Replay Attacks
where a valid signed message is copied and
later resent
● simple replay
● repetition that can be logged
● repetition that cannot be detected
● backward replay without modification
countermeasures include
● use of sequence numbers (generally impractical)
● timestamps (needs synchronized clocks)
● challenge/response (using unique nonce)
Using Symmetric Encryption
as discussed previously can use a two-level hierarchy of
keys
usually with a trusted Key Distribution Center (KDC)
● each party shares own master key with KDC
● KDC generates session keys used for connections
between parties
● master keys used to distribute these to them
Needham-Schroeder Protocol
original third-party key distribution protocol
for session between A B mediated by KDC
protocol overview is:
1. A->KDC: IDA || IDB || N1
2. KDC -> A: EKa[Ks || IDB || N1 || EKb[Ks||IDA] ]
3. A -> B: EKb[Ks||IDA]
4. B -> A: EKs[N2]
5. A -> B: EKs[f(N2)]
Needham-Schroeder Protocol
used to securely distribute a new session key for
communications between A & B
but is vulnerable to a replay attack if an old session key
has been compromised
● then message 3 can be resent convincing B that is
communicating with A
modifications to address this require:
● timestamps (Denning 81)
● using an extra nonce (Neuman 93)
Using Public-Key Encryption
have a range of approaches based on the use of
public-key encryption
need to ensure have correct public keys for other parties
using a central Authentication Server (AS)
various protocols exist using timestamps or nonces
Denning AS Protocol
Denning 81 presented the following:
1. A -> AS: IDA || IDB
2. AS -> A: EPRas[IDA||PUa||T] || EPRas[IDB||PUb||T]
3. A -> B: EPRas[IDA||PUa||T] || EPRas[IDB||PUb||T] ||
EPUb[EPRas[Ks||T]]
note session key is chosen by A, hence AS need not be
trusted to protect it
timestamps prevent replay but require synchronized
clocks
One-Way Authentication
required when sender & receiver are not in
communications at same time (eg. email)
have header in clear so can be delivered by email
system
may want contents of body protected & sender
authenticated
Using Symmetric Encryption
can refine use of KDC but can’t have final exchange of
nonces, vis:
1. A->KDC: IDA || IDB || N1
2. KDC -> A: EKa[Ks || IDB || N1 || EKb[Ks||IDA] ]
3. A -> B: EKb[Ks||IDA] || EKs[M]
does not protect against replays
● could rely on timestamp in message, though email
delays make this problematic
Public-Key Approaches
have seen some public-key approaches
if confidentiality is major concern, can use:
A->B: EPUb[Ks] || EKs[M]
● has encrypted session key, encrypted message

if authentication needed use a digital


signature with a digital certificate:
A->B: M || EPRa[H(M)] || EPRas[T||IDA||PUa]
● with message, signature, certificate
Digital Signature Standard
(DSS)
US Govt approved signature scheme
designed by NIST & NSA in early 90's
published as FIPS-186 in 1991
revised in 1993, 1996 & then 2000
uses the SHA hash algorithm
DSS is the standard, DSA is the algorithm
FIPS 186-2 (2000) includes alternative RSA & elliptic
curve signature variants
Digital Signature Algorithm
(DSA)
creates a 320 bit signature
with 512-1024 bit security
smaller and faster than RSA
a digital signature scheme only
security depends on difficulty of computing discrete
logarithms
variant of ElGamal & Schnorr schemes
Digital Signature Algorithm
(DSA)
DSA Key Generation
have shared global public key values (p,q,g):
● choose q, a 160 bit
● choose a large prime p = 2L
• where L= 512 to 1024 bits and is a multiple of 64
• and q is a prime factor of (p-1)
● choose g = h(p-1)/q
• where h<p-1, h(p-1)/q (mod p) > 1
users choose private & compute public key:
● choose x<q
● compute y = gx (mod p)
DSA Signature Creation
to sign a message M the sender:
● generates a random signature key k, k<q
● nb. k must be random, be destroyed after use, and
never be reused
then computes signature pair:
r = (gk(mod p))(mod q)
s = (k-1.H(M)+ x.r)(mod q)
sends signature (r,s) with message M
DSA Signature Verification
having received M & signature (r,s)
to verify a signature, recipient computes:
w = s-1(mod q)
u1= (H(M).w)(mod q)
u2= (r.w)(mod q)
v = (gu1.yu2(mod p)) (mod q)
if v=r then signature is verified
see book web site for details of proof why

You might also like