Topic: Cryptographic application

Presented by,
Lavanya V
Asst. Prof ,ECE Dept
• In this chapter, we’ll look at how cryptography is used in real life through some
applications.
• The main purpose is not just to see the applications but to understand how choices
were made when applying cryptography.
• And we’ll notice that,
-Not all decisions were perfect, at first mistakes or weaker choices were
sometimes made.
-Many decisions are trade-offs; balancing things like security, cost, speed &
convenience.
• The applications chosen are different from each other so we can see different
kinds of decisions in different environment.
The chosen applications are:-
1. Cryptography on the internet(for securing the internet).
2. Cryptography for wireless local area network.
3. Cryptography for mobile telecommunication.
4. Cryptography for secure payment card transaction.
5. Cryptography for video broadcasting.
6. Cryptography for identity cards.
1. Cryptography on the internet
• Cryptography is widely used on the Internet, and one of the most famous
examples is SSL (Secure Sockets Layer).
• SSL is one of the top three important protocols that help create a secure
connection over a network.
• The Internet works in four layers (called the Internet Protocol Suite).
• SSL works at the Transport Layer (this layer is responsible for end-to-end
communication between devices).
• But secure connections can also be made at other layers:
-Application Layer → using SSH (Secure Shell).
-Internet Layer → using IPsec (Internet Protocol Security).
SSL(Secure Sockets Layer) – Concepts and Issues
• SSL background
• SSL security requirements
• Cryptography used in SSL
• SSL protocols
• SSL key management
• SSL security issues
• SSL design issues
➢ SSL Background

• SSL is a general communication security protocol for protecting data while it is

being transferred between different locations
• Although it has many applications, most users encounter SSL when securing a
web connection between a client machine and a web server.
For example - when making a purchase from an online store.
• SSL requires a reliable underlying transport protocol, hence its suitability for
applications on the Internet running over the Transmission Control Protocol(TCP).
• While securing web sessions, an SSL connection may be indicated when:
-You visit secure websites (like online stores or banking).
-You see https instead of http in a web address.
-A padlock icon appears in your browser.
-A pop-up may ask if you want a “secure connection”.
• These indications provide a degree of assurance to the user that information
exchanged during the session is ‘secure’ & not easily stolen or changed.
• Later, the internet engineering task force(IETF) took over & improved SSL.
• In 1996, they released a new version called TLS(Transport Layer Security).
• Since then, newer versions of TLS have been developed, today people often use
the term SSL to mean both SSL & TLS.
➢ SSL security requirements
• SSL is designed to establish a ‘secure channel’ between two entities & highly
configurable.
• Even though SSL has some common security features, these requirements are
optional and can be turned on or off depending on what's needed.
• The 3 main(optional) security features are:
1. Confidentiality
2. Data origin authentication
3. Entity authentication
➢Confidentiality:

• When data is sent through a secure channel, only the sender & the receiver can
read it.
• Even if a hacker is watching the communication they cannot understand or access
the data.
➢Data origin authentication:

• It ensures the data really comes from the person or system it's supposed to.
• This prevents attackers from sending fake or tampered messages pretending to be
someone else.
➢Entity authentication:

• Before communication begins, both parties (like your browser and the server)
need to prove who they are.
• This helps prevent imposters from joining the connection.

❑Hence, SSL only protects the link between your browser & the web server.

❑If the web server then sends your data to another place, that second transfer also
needs its own security.
➢ Cryptography used in SSL

• SSL is made for situations where two parties don’t know each other beforehand &
haven’t shared any secret keys, they can quickly create a secure connection.
-> Like, when you buy something from a new online store you just found that
even though you’ve never talked to them before, SSL makes sure you can safely
send your payment details.
• SSL uses a mix of different cryptographic techniques (this is called hybrid
encryption) to keep data secure.
Here are the main cryptographic tools used:
• Public-key cryptography – used to safely exchange keys.
• Digital signatures – used to verify identities and sign certificates.
• Symmetric encryption – keeps the actual data private.
• MACs (Message Authentication Codes) – ensure data comes from the right
source and wasn’t changed.
• Hash functions – used in MACs, digital signatures, and for making secure keys.
In SSL, different websites, servers & clients may prefer different security
algorithms. So SSL is flexible – it supports many options
Flexibility in SSL
• Different systems (like browsers or servers) might prefer different algorithms or
key sizes.
• So, SSL supports many types of algorithms, for example:
❑Block Cipher(like AES) (a strong block cipher, often used in CBC mode)

- for encrypting data

❑HMAC (a secure method using hash functions like SHA-256)

-for checking data integrity

❑RSA/DSA (popular digital signature methods)

-for authentication
• At start of an SSL session, both sides negotiate & agree on which set of algorithms
to use, this chosen set is called a cipher suite.
What is a Cipher Suite?
• When an SSL connection starts, both sides agree on which algorithms to use (like
which type of encryption, signature, etc.).
-> Think of it like two people deciding on a language to talk in before
starting a connection – once agreed, they stick with it.
➢ SSL Protocols
• SSL essentially consists of two cryptographic protocols:
1. Handshake protocol
2. Record protocol
➢Handshake Protocol:

This protocol performs all the tasks that require agreement between the two
entities before they set up the secure SSL channel. In particular, this protocol can be
used to:
• agree on the cryptographic algorithms to be used to establish the securechannel;
• establish entity authentication;
• establish the keys that will be needed to secure the channel.
➢Record Protocol: This protocol implements the secure channel.

-This includes:
• formatting the data (for example, breaking it up into blocks);
• computing MACs on the data;
• encrypting the data.
➢SIMPLE SSL HANDSHAKE PROTOCOL DESCRIPTION

Purpose of this SSL HP is;

To securely establish a connection between Client and Server, where:
• The server is authenticated to the client.
• They agree on cryptographic algorithms and establish encryption keys.
• This is the most common mode of use of the protocol, although we later indicate
how mutual entity authentication can be added.
• The message flow of the simplified SSL Handshake Protocol is indicated in the
following figure:

Fig: Simple SSL Handshake Protocol message flow

➢ Client request:

• This message from the client initiates the communication session and requests the establishment
of an SSL-protected channel.
• As part of this request message, the client sends some data, including:
-Session ID-acts as a unique identifier for the session
-pseudorandom number (rC) - ensures freshness (rC- unencrypted)
-List of supported cipher suites

➢ Server Response:

• The server responds by sending some initialization data,including:

-Same Session ID
-Its own random number (rS)- (rS- unencrypted)
-Chosen cipher suite
-Public-key certificate (used to verify server identity)
➢Pre-master Secret Transfer:

Here, the client:

• Generates a pre-master secret (Kₚ)
• Encrypts Kₚ using server’s public key
• Sends the encrypted Kₚ to the server
Now both client and server can:
• Derive the master secret (Kₘ) using Kₚ, rC, and rS
• Use Kₘ to generate keys for encryption and MACs
From this point on, all messages that are exchanged are cryptographically
‘protected’.
➢Clients finished:

• The client computes a MAC on the hash of all the messages sent so far.
• This MAC is then encrypted and sent to the server.
➢Server Finished:

• The server checks the MAC received from the client.

• The server then computes a MAC on the hash of all the messages that have been
sent so far.
• This MAC is then encrypted and sent to the client.
Finally, the client checks the MAC received from the server.
ANALYSIS OF THE SIMPLE SSL HANDSHAKE PROTOCOL
We now confirm exactly how the simple SSL Handshake Protocol achieves its three
main goals:
1. Agreement on Cryptographic Algorithms
Agreed during the Server Response phase.
2. Authentication of Server
Relies on:
• Server proving it owns the private key (used to decrypt Kₚ)
• Valid certificate verification
• Use of MACs that can only be computed with Kₘ
3. Key Establishment
• Both sides derive the same master secret (Kₘ) securely from:
• Pre-master secret Kₚ
• Random values rC and rS
Note that:
The Client Finished and Server Finished messages also provide retrospective data
origin authentication of the entire message flow.
This provides assurance that none of the messages exchanged during the SSL
Handshake Protocol have been tampered with, which is particularly important since
the opening messages of the protocol have no cryptographic protection.
SSL HANDSHAKE PROTOCOL WITH CLIENT AUTHENTICATION
• The simple SSL Handshake Protocol does not provide mutual entity
authentication, provides only entity authentication of the server.
• This is reasonable because many applications do not require client authentication
at the network layer where SSL is deployed.
• Client Authentication Data message is added after Pre-master Secret Transfer
• Client sends:
-Its public key certificate
-Digital signature on a hash of previous messages (proves identity)
• Server Verifies:
-Signature is valid
-Certificate is valid
• rS (server’s random) is included in the signature hash → ensures freshness
Real-Time Applications of SSL Handshake Protocol:
➢Secure Web Browsing (HTTPS):

Where?
Browsers like Chrome, Firefox, Safari, etc.
How?
• When you visit [Link] the browser and the website perform an SSL
handshake.
• Ensures that your data (login, payment info, messages) is encrypted.
Real Example: Logging in to your online banking site.
➢Online Shopping / E-Commerce:

Where?
• Sites like Amazon, Flipkart, etc.
How?
• SSL handshake secures payment info when you enter credit card details.
• Ensures the server is authentic (you’re not on a phishing site).
Real Example: Entering credit card info during checkout.
SSL RECORD PROTOCOL
Purpose:
SSL Record Protocol secures communication after the SSL Handshake is complete.
• Here, both client and server derive cryptographic data needed for secure
communication (encryption & MAC keys).
• This includes:
-Symmetric session keys (for encryption/decryption).
-Symmetric MAC keys (for integrity check).
-IVs (Initialization Vectors, if needed).
• These are all generated using a key derivation function to compute a key block.
Key Block Generation:
• A key derivation function is used to generate a key block using:
-Master key-KM
-Random values- rC & rS
• It produces a key block.
• The block is divided into four keys:
-KECS: encryption(client->server)
-KESC: encryption(server->client)
-KMCS: MAC(client->server)
-KMSC: MAC(server->client)
How Messages Are Sent (Client → Server)
1)MAC Creation
Client makes a MAC (Message Authentication Code) on the data using key KMCS.
This ensures integrity (server can later check if data is unchanged).
2) Attach MAC and Pad
The MAC is attached to the original data.
Padding is added(if needed) so the size fits encryption block length.
3)Encrypt
The final data(original message + MAC + padding) is encrypted using key KECS
How Messages Are Received (Server Side)
1)Decrypt
Server decrypts the message using KECS.
2) Verify MAC
Server checks the MAC with key KMCS.
If the MAC matches -> data is correct & unmodified.

❑SSL uses a MAC-then-encrypt approach → first ensures integrity (MAC), then

applies encryption for confidentiality.
➢SSL key management
->Key management system:
SSL essentially relies on two ‘separate’ key management systems:
1. Public-key management
2. Symmetric-key management
➢Public-key management system:

• Used in open networks (like the internet).

• Relies on an external system that manages public-private key pairs.
• Important for authentication:
-All users (if both sides need to prove identity).
-Only servers (if only one side needs to prove identity).
• This system also manages certificates & their validity.
• If this system fails(eg: certificates invalid or hacked),SSL security is broken.
• It manages identity & certificates (outside SSL).
Note: This part is outside the SSL specification itself.
➢Symmetric-key management system:

• Built inside SSL.

• SSL uses symmetric keys for the actual communication (after authentication).
• Session keys are generated, which are:
-Temporary (short-lived)
-Used only for one session.
It manages session keys for data encryption (inside SSL).
➢Relationship Between the Two

• These two systems are not totally separate – they overlap in the key management
lifecycle.
• Public keys help to exchange or agree on symmetric keys.
• Then symmetric keys handle fast, secure data transfer.
->Key generation:
Two types of keys are used in SSL:
• Asymmetric keys → Generated using public-key systems (e.g., RSA). Not defined
by SSL itself.
• Symmetric keys → Created inside SSL, these are the session keys derived from a
master secret.
Key Derivation (how session keys are made from master secret):
• Lightweight method → does not need heavy computation.
• From one master secret, many different session keys can be generated.
• Saves cost → Public-key cryptography is expensive, so one master secret can be
reused to derive multiple keys efficiently.
Master Secret Generation:
• Depends on the client to generate a pre-master secret (random number).
• If the client fails to generate it securely, all session keys can be compromised.
Key Lengths:
• The size of the keys (e.g., 128-bit, 256-bit) is negotiable.
• Final key agreement is done during the SSL Handshake Protocol.
->Key establishment:
• The main goal is to establish a pre-master secret using the SSL Handshake
Protocol.
• Usually done with RSA public-key encryption.
• SSL also supports Diffie–Hellman for key establishment.
->Key storage:
Both client and server must securely store private keys.
• These are the most critical since they are used across many sessions.
Session keys (symmetric keys) from the SSL Handshake are temporary.
• Used only for one session.
• If compromised, only that session is affected.
->Key usage:
SSL follows the idea of key separation:
• Different keys are derived from the master secret for encryption and MAC
(Message Authentication Code).
• This ensures better security for the communication channel.
SSL improves security further by:
• Using different keys for each communication direction (client → server and
server → client).
• Prevents reflection attacks.
Trade-off in SSL:
• For convenience, the master secret (Km) is used for two purposes:
-As a key derivation key.
-As a MAC key.
• This slightly breaks the rule of full key separation but is considered practical.
➢SSL security issues
• SSL is a popular communication protocol and is generally regarded as
cryptographically ‘strong’ if used with respected cryptographic algorithms.
• Most security problems experienced using recent versions of SSL have arisen from
aspects that are beyond the scope of the protocol specification.
These include:
1. Process failures.
2. Implementation failures
3. Key management failures.
4. Usage failures.
➢Process Failures

• SSL relies on checking the server's public key to ensure it’s trustworthy.
• Often users ignore browser warnings about unverified certificates.
• Hackers can exploit this by using fake certificates pretending to be real websites.
• Even if the certificate is verified, if it's for the wrong server, users might still trust it
• This is a phishing risk, where attackers trick users into thinking the site is
legitimate.
Important Note: This is not a flaw in SSL itself, but a failure in how it’s used.
➢Implementation Failures

• SSL is flexible and used in many different systems, leading to poor

implementations.
• Even with correct SSL usage, if supporting components are weak, security can fail.
-Example: Using weak methods to generate keys makes it easier for attackers to
guess the keys.
• So, the way SSL is implemented matters a lot for its security.
➢Key Management Failures

• SSL security depends heavily on proper handling of keys.

• If private keys are stolen or mismanaged:
-Attackers can impersonate the server.
-They can decrypt sensitive data or access secure sessions.
• Key protection is critical.
➢Usage Failures

• SSL can be used wrongly or over-trusted.

• Common mistake: Thinking SSL guarantees complete security.
-Example: Online stores claim to be “completely secure” just because they use SSL.
• SSL only secures data in transit, not what happens after it reaches the server.
• Hackers usually go for the database, not the communication line, because SSL
protects that part well.
SSL is strong when used correctly, but many problems happen because:
• Users ignore warnings,
• Developers implement it poorly,
• Keys are not well protected,
• Or people trust it too much, thinking it’s enough on its own.
➢SSL design issues
After explaining how SSL uses cryptography (like encryption and keys), this section
wraps up by looking at a few important design decisions that affected how SSL's
cryptography was chosen and implemented.
This includes:
1. Support for a Range of Publicly Known Cryptographic Algorithms
2. Flexibility.
3. Minimal use of public-key operations.
4. Unbalanced computational requirements.
➢Support for a Range of Publicly Known Cryptographic Algorithms

• SSL/TLS is designed for wide public use.

• It supports many well-known encryption algorithms, not just a few.
• This makes it easier to use on different systems and platforms.
• People are more likely to trust it because it uses transparent, public encryption
methods.
➢Flexibility

• SSL is flexible in how it is used and how it's built into systems.
• It can support:
-One-way authentication (server only)
-Two-way authentication (server and client).
• This flexibility helps it fit many different applications and environments.
➢Minimal Use of Public-Key Operations

• SSL uses a mix of public-key and symmetric encryption.

• Public-key operations are slow and expensive, so SSL uses them only when
needed.
• Once a secure channel is established, it switches to faster symmetric encryption.
• SSL is designed to reuse the secure connection without repeating the expensive
setup.
➢Unbalanced Computational Requirements

• In SSL, the client does more work than the server during setup.
• Example:
-The client encrypts a key (using public key encryption).
-The server decrypts it (using private key decryption).
• Some algorithms (like RSA) are harder to decrypt than encrypt.
• Some algorithms (like RSA) are harder to decrypt than encrypt.
SSL was carefully designed to:
• Be widely usable and trusted,
• Work in many environments,
• Use public-key cryptography only when needed,
• And shift more work to clients to reduce server load.
2) Cryptography for wireless local area networks

• Wireless networks need strong security → Because they send data over radio
waves, anyone nearby can try to intercept or attack them. This makes them more
vulnerable than wired networks.
• Design mistakes happened → When creating some wireless security standards,
errors were made in how cryptography (the math used to protect data) was
applied.
• Result -> these mistakes made wireless networks weaker than expected and open
to attacks
• WLAN background
• WLAN security requirements
• WEP(Wired Equivalent Privacy)
• Attacks on WEP
• WPA and WPA2 (Wi-Fi Protected Access)
• WLAN security issues
• WLAN design issues
1) WLAN background
• Wireless networks send data through the air → anyone nearby can listen or attack
without needing physical access.
• Benefits of Wireless Communication
• Main advantage: Convenience – no messy wiring needed.
• Can set up networks easily in homes, offices, and public places (cafes, stations, etc)
• Devices can connect without physical restrictions.
Weakness of Wireless Networks
• Without built-in security, wireless data can be intercepted and modified.
• Unlike wired, attackers don’t need to enter the building – they just need to be
within range.
Wireless Local Area Network (WLAN)
• WLAN is a type of wireless network typically used at home/office
• Governed by IEEE 802.11 standards (commonly called Wi-Fi).
• Devices certified to meet these standards are labeled as Wi-Fi.
Simple WLAN Architecture
• A wireless access point (AP): connects wireless devices to the wired network (e.g.,
internet).
• Devices: laptops, PCs, PDAs, or any gadget with a wireless network card.
• Multiple devices can connect to one access point, or multiple access points can be
used.

Fig: A Simple WLAN Architecture

Security Mechanisms
WEP (Wired Equivalent Privacy)
• First security method (in 802.11 standard).
• Designed to make wireless as secure as wired.
• Worked at the data link layer.
• But had serious flaws in its cryptographic design.
WPA (Wi-Fi Protected Access) –
• Introduced in 2002.
• Temporary fix to improve on WEP.
• Designed to work on older (legacy) hardware.
WPA2 (2004)
• Complete redesign of wireless cryptography.
• Stronger and more secure, part of IEEE 802.11i standard.

Wireless security evolved step by step (WEP → WPA → WPA2).

These issues are not just about practice but also teach important lessons in how
cryptographic design errors can weaken real systems.
2) WLAN security requirements
The scope of the security requirements for a WLAN are defined by the notion that;
• WLANs should be as secure as wired networks.
• This is tricky because wireless and wired networks are very different.
• Still, this idea is used as a security target to guide design.

And it is not meant to stop denial-of-service(DoS) attacks (e g:jamming signals)

Because, even wired networks are not fully protected from DoS (e g:cutting a
cable)
Key Security Requirements for WLANs
Confidentiality:

• Data sent over WLAN should remain private.

• Just like tapping a wired network is hard, wireless should also protect against easy
eavesdropping.
Mutual Entity Authentication:

• Devices should be able to recognize each other when connecting.

• In wired systems, physical wires give weak “authentication,” but in wireless, strong
authentication is essential.
Data Origin Authentication:

• The receiver should know that the data really came from the right sender.
• Prevents attackers from modifying or injecting fake data after the connection
starts.
• Problem: The old WEP standard only gave weak integrity protection, which was not
secure enough.

WLANs should protect data privacy, confirm the identity of devices, and ensure
that data really comes from the right source.
Early standards like WEP failed at these requirements, making networks vulnerable.
3)WEP
There are three cryptographic design decisions that are common to all of the WLAN
security mechanisms that we discuss:
1) Compatibility across devices
• WLANs use devices from many manufacturers → the cryptography must be widely
available.
• Proprietary algorithms would not be practical.
2) Simplicity(unlike SSL)
• WLANs don’t need the full complexity of SSL.
• Instead of negotiating algorithms each time (like SSL Handshake), WLANs use fixed
algorithms to keep things simple.
3) Speed & Efficiency
• WLANs need to work fast → symmetric cryptography (same key for encryption and
decryption) is better than slower public-key cryptography.
-> However, the cryptographic details of each of the proposed mechanisms vary
considerably.
Hence, the original proposal of WEP, which uses are;
WEP (Wired Equivalent Privacy) used 3 main techniques:
1) Encryption – RC4 stream cipher
• Used to keep data private
• At that time, RC4 was popular(also used in SSL).
• But later, RC4 was found to be weak and not good enough for modern security
2) Integrity – CRC checksum
• Used to check that data was not changed during transmission.
• Problem: CRC is weak → attackers can change the data and then recalculate CRC
easily.
• So it cannot reliably protect data integrity.
3) Authentication – Challenge–response protocol
A simple method to verify identity of devices.
• Provided only basic authentication(not very strong)
CONFIDENTIALITY AND INTEGRITY MECHANISMS IN WEP

1) WEP Key is Shared and Fixed

• All devices in a WLAN use the same shared key (K).
• This key is symmetric, meaning it is used for both encryption and decryption.
• If one device is compromised, the entire network is at risk.
2) WEP Uses RC4 Stream Cipher
• Stream ciphers like RC4 need synchronization.
• WEP encrypts each packet individually, so losing one packet doesn’t affect others.
• But this creates a problem: key reuse could lead to security issues.
3) Solution: Add Initialization Vector (IV)
WEP uses a 24-bit Initialization Vector (IV).
Each packet has a different IV to ensure different encryption.
IV is combined with the shared key to form a "per-packet key":
K′= IV∣∣K
• The encryption process for each packet of data to be sent is depicted in the
following figure,

Figure:WEP encryption process

WEP Encryption Process:
Alice (Sender):
1) Generates a random 24-bit IV.
2) Forms encryption key:
K′=IV∣∣K
3) Computes a CRC checksum (Integrated check value-ICV) of the data (32-bit).
4) Encrypts:
EK′(data∣∣ICV)
5) Sends the IV (in plain) + ciphertext to Bob.
Bob (Receiver):
1) Uses received IV and known K to get:
K′=IV∣∣K
2) Decrypts the ciphertext using K’.
3) Checks if ICV matches.
4) If the verification of ICV is successful then Bob accepts the data packet.

• IV is only 24 bits → limited combinations, easy to reuse.

• IV is sent in clear, allowing attackers to analyze and reuse keys.
• Shared key for all users → if one user is compromised, all are.
 ENTITY AUTHENTICATION IN WEP

Purpose:
• The whole process works because only someone with the correct WEP key K can
encrypt the nonce properly.
• If Alice doesn’t have the key, she can’t respond correctly, so Bob won’t authenticate
her.
• Bob tests Alice by sending a random puzzle. Alice solves it using the secret WEP
key. If Bob verifies the solution, Alice is authenticated.
1) Alice asks to connect
• Alice (the device) sends a request to Bob (the wireless access point) asking to
authenticate.
2) Bob sends a challenge
• Bob sends a random number (called a nonce 𝑟𝐵 )to Alice.
• This is like a puzzle that only someone with the secret key can solve.
3) Alice encrypts the challenge
• Alice uses the WEP key (K) to encrypt the nonce.
• During this process, she also generates an Initialization Vector (IV) which helps in
encryption.
4) Alice sends back encrypted data
• Alice sends Bob both the IV and the encrypted challenge (ciphertext).
5) Bob checks the answer
• Bob uses the same WEP key (K) to decrypt the ciphertext.
• If the decrypted value matches the original nonce 𝑟𝐵 , Bob confirms Alice is genuine.
4) Attacks on WEP(Key Management Weaknesses)
Main Idea:

WEP fails because it uses a weak, shared, and exposed key. Once attackers capture
enough data, they can break the encryption and access the entire wireless network.
• There are several serious problems with WEP key management:
1) Use of a shared fixed key(Single Point of Failure)
2) Exposure of the WEP key
3) No key separation
4) Key length.
1)Use of a shared fixed key.(Single Point of Failure)
• WEP uses one common key 𝐾for the whole Wi-Fi network.
• If the key is leaked from just one device, the entire network security is broken.
2)Exposure of the WEP key
• The WEP key is directly used in encryption.
• Every time authentication happens, parts of the key are exposed.
• This makes it easier for attackers to capture and figure out the key.
3)No key separation
• The same WEP key is used for multiple purposes (authentication, encryption, etc.).
• Good security requires different keys for different tasks, but WEP ignores this.
4) Key length
• The smallest WEP key is only 40 bits, which is too short and can be cracked quickly
with modern computing.
• Even when longer keys are allowed, many WEP systems generate them from user
passwords, which can be weak.
• This reduces the actual security level and makes brute-force attacks easier.
WEP ENTITY AUTHENTICATION WEAKNESSES
1) Rogue Wireless Access Point
• WEP only authenticates from Alice (user/device) to Bob (access point), not the
other way around.
• This is unilateral authentication.
• An attacker can set up a fake access point.
• Alice might connect and authenticate to this rogue access point, thinking it’s
legitimate.
2) Lack of Session Key
• WEP does not generate a new session key during authentication.
• The same key is reused, so authentication is only valid at that moment in time.
• This means an attacker could later hijack the communication session.
3) Keystream Replay Attack
How it works

• WEP uses the stream cipher RC4.

• Encryption works by XORing plaintext with a keystream.
• If the same keystream is reused, attackers can replay old messages.
Attack Steps

Figure: Keystream replay attack on WEP authentication

• Attacker requests authentication with Bob.
• Bob sends a random challenge nonce 𝑟𝐵′
• The attacker reuses a keystream observed from Alice’s past authentication.
• Using that keystream, the attacker forges a valid encrypted response without
knowing the secret key.
• Bob decrypts it and mistakenly accepts the attacker as authenticated.
It works in this way because;
• WEP allows reusing the same IV (Initialization Vector) with the same key.
• This makes the same keystream appear again, enabling replay.

Limitations for the Attacker

• The attacker can authenticate to Bob (access point).

• But since they don’t know the full WEP key, they cannot perform full
encryption/decryption of all traffic.
• Still, the authentication mechanism itself is broken.
WEP CONFIDENTIALITY AND INTEGRITY WEAKNESSES
• WEP has weaknesses in confidentiality (keeping data secret) and integrity (making
sure data isn’t changed).
• Because of these weaknesses, attackers can launch special attacks.
• Some of these attacks are so strong that they can actually reveal the secret WEP
key, which protects the entire network.
1. CRC Manipulation Attack
2. Birthday Attack on Ivs
3. Key Recovery Attack
1) CRC Manipulation Attack
• WEP uses CRC (Integrity Check Value) to check if data is correct.
• But CRC is a linear function, meaning changes in data create predictable changes in
CRC.
• Attackers can modify encrypted data and adjust the CRC to match.
• The receiver will accept it as valid, allowing attackers to alter data packets without
knowing the WEP key.
2) Birthday Attack on IVs
• WEP’s IV (Initialization Vector) is only 24 bits long.
• This means only about 16 million different IVs exist.
• With enough packets (~4000), it’s very likely two packets reuse the same IV
(birthday paradox).
• When IVs repeat, the same keystream is reused → attackers can compare packets
and learn information.
• Over time, attackers can collect many packets encrypted with the same key →
easier to break.
3) Key Recovery Attack
• WEP uses RC4 with IVs to generate keystreams.
• Weakness in how IVs are used makes it possible to recover the WEP key through
statistical analysis.
• By 2010, tools existed that could crack WEP with fewer than 10,000 packets (very
fast).
• Since the WEP key is fixed (not changing often), once it’s cracked → all
communication is exposed.
WEP DESIGN FLAWS
• The designers of WEP set out with an admiral goal to provide enough security, but
not excessive security, in order to keep WLANs secure but efficient.
• Here they sacrificed too much security in the name of efficiency, they faced some
of the problems with the WEP cryptographic design appear to arise not from
knowledgeable tradeoffs, but from fundamental misunderstandings.
-> These include:
1. Poor key management.
2. Failure to appreciate the effective key length
3. Lack of a proper cryptographic data origin authentication mechanism
4. Non-standard use of a cryptographic algorithm.
5. Weak entity authentication mechanism
Poor key management
• WEP uses a single fixed key for everyone.
• If attackers capture enough data, they can figure out the key.
• Since the same key is reused, once cracked, all communication is exposed.
Wrong understanding of key length
• WEP uses RC4 encryption but does not use keys properly.
• Even if the key looks long, only part of it changes each time (24 bits).
• This makes it easier for attackers (e.g., birthday attacks) to break.
Weak authentication method
• WEP uses simple CRC checks for verifying data integrity.
• CRC is not secure—it can be changed without being noticed.
• A stronger method like a Message Authentication Code (MAC) should have been
used.
Improper use of cryptographic algorithm
• WEP did not follow the correct way of using RC4.
• They combined keys in a weak, non-standard way.
• This mistake allowed powerful attacks (like key recovery attacks).
Weak entity authentication
• WEP’s method of checking who is connecting is very weak.
• It can be fooled easily and does not protect the network properly.

Thus WEP has provided us with a wide range of valuable cryptographic design
lessons, many of which have wider implications.
5) WPA and WPA2
MUTUAL ENTITY AUTHENTICATION AND KEY ESTABLISHMENT
• WPA/WPA2 use a pairwise master key (PMK) → provides stronger and dynamic
security.

How PMK is Established:

• Option 1 (Large networks):
Device authenticates with a central server using EAP (Extensible Authentication
Protocol).
→ Server helps generate PMK.
• Option 2 (Small/home networks):
Use a pre-shared key (PSK) (basically a password).
→ From this password, PMK is derived.
• Even if a device is authenticated with the server, it must still prove itself to the
wireless access point (AP).
• PMK is used to create session keys for secure communication.
 Figure: WPA authentication and key establishment protocol
Alice (device) → Bob (AP):

• Alice generates a random number (nonce rA) and sends it to Bob.

Bob (AP):

• Bob generates his own random number (nonce rB).

• Using rA, rB, and PMK, Bob derives four keys:
EK → Encryption key
MK → MAC key
DEK → Data encryption key
DMK → Data MAC key
Bob → Alice:

• Bob sends rB + a MAC (message authentication code) on rB (using MK) to Alice.

Alice:

• Alice uses rA, rB, and PMK to derive the same four keys (EK, MK, DEK, DMK).
• She checks Bob’s MAC to confirm Bob knows PMK.
Alice → Bob:

• Alice sends a “Ready to start encryption” message.

• She also adds a MAC using MK.
Bob:

• Bob verifies Alice’s MAC.

• Sends an acknowledgement back.
The final outcome:
Both sides prove they know PMK → mutual authentication.
They generate the same four keys → used for secure communication.
6) WLAN Security Issues
Main Cause of Problems
• Most WLAN security issues are not because the cryptography itself is broken.
• Problems come from design errors, implementation mistakes, or key management
(how keys are set up and used).
Strength of WPA/WPA2
• So far, no major attacks have broken the cryptography of WPA/WPA2 directly.
• They fixed most of the weaknesses found in WEP.
Weak Spot in WPA2
• The biggest risk is in small/home networks that use a pre-shared key (PSK)
(basically a Wi-Fi password).
• If the password is weak, the PMK(Pairwise Master Key)derived from it is also weak.
• Since all session keys depend on PMK, this makes the whole system vulnerable.
Password-related Problems
• If users set weak Wi-Fi passwords, attackers can try to guess them (dictionary or
brute-force attacks).
• If default passwords (shipped with routers) are not changed, attackers can easily
exploit them.
Hence, WPA2 is secure cryptographically, but its real-world security depends on
strong passwords/passphrases chosen by users.
7) WLAN Design Issues
The main cryptographic design issues concerning WLAN security are as follows:
1. Use of symmetric cryptography.
2. Use of recognized cryptographic mechanisms
3. Flexibility, but only when appropriate
4. The potential need to cater for migration.
1) Use of Symmetric Cryptography
• WLANs send a lot of data → need fast encryption.
• Symmetric cryptography is used because it’s quicker than public-key cryptography.
• Larger networks may still use public-key for authentication, but the main WPA2
protocol (CCMP) only uses symmetric keys.
2) Use of Recognized Cryptographic Mechanisms
• WEP failed because it used weak, non-standard cryptography.
• Lesson: don’t invent your own cryptography → use proven, standard methods.
• WPA2 fixed this by using well-tested cryptographic techniques.
3) Flexibility, but Only Where Needed
• WLANs are used in many environments but don’t need the same flexibility as, say,
SSL.
• WPA2 locks down cryptographic methods (for confidentiality + authentication).
• Still allows flexibility for authentication methods (like EAP with servers), since
networks may differ.
4) Need for Clear Migration Path
• When WEP flaws were discovered, upgrading everyone was hard.
• A “quick fix” was needed → WPA (based on RC4) for temporary security.
• A “full redesign” came later → WPA2 (based on AES) for strong, long-term security.