Network Security: Authentication Protocols and Ephemeral Key Setup

Cryptographic Protocols

• A cryptographic protocol is a distributed algorithm among $n$ entities, where $n≥2$, specifying actions to achieve a security goal.
• It defines how to use cryptographic algorithms for objectives like authentication, confidentiality, and integrity.

Authentication Protocols

System vs. Message Authentication

• Message Authentication:
  • Provides proof of origin and integrity protection using Message Authentication Codes (MAC).
  • Offers proof of origin, integrity protection, and non-repudiation through digital signatures.
  • Verification doesn't necessarily need to happen in real-time, especially with digital signatures.
• Entity Authentication:
  • Involves identifying an entity (person/system) involved in a network protocol with proofs.
  • Crucially, identity verification usually needs to occur in real-time.
• The focus is primarily on entity authentication.

Authentication Protocol Requirements

• Basic Requirement: Authentication
  • Goal: To allow entity A to authenticate entity B, verifying B's identity through some form of proof.
  • Mutual authentication occurs when both A and B authenticate each other during the same process.
• Non-Transferability
  • A should not be able to reuse data exchanged with B to impersonate B with a third party, C.
• Robustness Against False Identity
  • The protocol should minimize the possibility of C impersonating B.
  • This should hold true even when:
    • C observes multiple authentication runs between A and B.
    • C executes authentication runs (successful or not) with A, B, or both.
    • Multiple protocol instances run concurrently.

Characterization of Authentication Protocols

• Features Offered: Mutual authentication, path authentication, etc.
• Computational Complexity:
• Network Efficiency: Number and size of messages exchanged.
• Credentials: Type, storage, handling, and maintenance mechanisms.
• Third-Party Needs: Whether a protocol requires Certification Authorities (CAs) to function.

Authentication Factors

• Something B Knows: PIN, password, symmetric key, private key (asymmetric keypair).
• Something B Has: Smart-card, crypto calculator (one-time password).
• Biometric Feature of B:

Classes of Authentication Protocols

• Password-Based Protocols:
  • Can be strong or weak.
• Challenge-Response Protocols:
  • Must be strong (not based on passwords unless in strong form).
• Zero-Knowledge Proof Protocols:
  • The verifier doesn't learn anything that would violate non-transferability.

Weak Password Authentication

• Common due to the convenience of passwords.
• Classified as weak when:
  • Passwords don't change frequently.
  • Susceptible to dictionary attacks (online or offline).
  • Password transmitted/stored in cleartext.

Password Authentication Protocol (PAP)

• Primarily used by PPP (except Tunneled-EAP).
• Requires a secure communication channel (e.g., a telephone line).
• Function: $f()$, a Message Digest Code (MDC) or symmetric encryption algorithm $E_k$, with constant key $K$.
• Problems:
  • Man-in-the-middle attacks.
  • Requires a secure channel.
  • Transferability issues.
  • Dictionary attacks on the password database.
• Salt aims to complicate dictionary attacks by making the hash different even with the same password.
• Recommendation: Avoid PAP unless within an encrypted tunnel.

Challenge Handshake Authentication Protocol (CHAP)

• Used in PPP and MS Windows variants.
• Function: $f()$ = MDC, $MAC_k$, with $k = MDC(pwd)$. CHAP uses $MD5(user|pwd|c)$.
• Problems:
  • Dictionary attack on $r$ (eavesdropping, false identity of the Authentication Server (AS)).
  • Password database in cleartext.
  • Replay attack (if $c$ is not a good random value).
• Recommendation: Avoid CHAP unless within an encrypted tunnel.

Semi-Weak: One-Time Passwords (Lamport's Hash)

• Published by Leslie Lamport in 1981.
• Function: $f^n() = MDC(MDC(…(MDC())))$ (n-times).
• Setup: Alice provides the AS with $h_y$, where $y$ is the number of available authentication runs before a reset.
• Salt is added to counter offline dictionary attacks.
• Properties:
  • Limited non-transferability.
  • Even if Trudy poses as AS, she can't use gained information to authenticate as Alice for more than one run.
• Problems:
  • Man-in-the-middle (small n).
  • Non-mutual authentication.

Strong Password Authentication

Encrypted Key Exchange (EKE)

• Developed by Bellovin and Merritt.
• Basic Idea: Authenticate a Diffie-Hellman (DH) exchange with passwords.
• Function: $f() = MDC$.
• Properties:
  • Mutual authentication.
  • Resistance to offline dictionary attacks.
  • Online dictionary attack possible (Trudy poses as Bob), but only one chance is available and Alice would detect it.
  • Ephemeral key setup.
• Problems: If Bob is an AS, cleartext password database.

Strong Authentication: Challenge-Response Protocols

• Main Idea: B asks A to transform a challenge together with a secret $s$.
• Main Property: Verifying A's identity is done through a secret $s$ which A does not need to disclose (during the protocol run).
• Usually, $s$ is not a password to resist dictionary attacks.
• The secret might be a cryptographically secure shared key, or a private key (NO PASSWORDS!).
• Challenge and responses must be time-variant to resist replay attacks.

What is a Challenge?

• Nonce: A number used only once between A and B (usually implemented with pseudo-random number generators).
• Sequence Number: A monotonically increasing counter (requires state at A and/or B).
• Timestamp: A form of implicit challenge (requires synchronized clocks).

Strong Authentication with Symmetric Algorithms

• $s$ := cryptographically secure secret shared among A and B.
• Variant: $s$ := cryptographically secure secret shared among {A, Z}, {B, Z}, …, where Z is an authentication server.
• Can be based on symmetric ciphers or MAC functions.
• Main Problems:
  • Generation, setup, and management of secrets.
  • Non-transferability is tough to achieve.

Challenge-Response Authentication with Symmetric Algorithms: Examples from ISO/IEC 9798-2/4

• Timestamp Based (t): One-way authentication, maximum network efficiency.
• One-Time Challenges (c1, c2): Mutual authentication, prevents chosen-text attacks.
• Variant Based on MACs

Challenge-Response: Where Do We Keep $s$?

• The secret $s$ is often hard to memorize.
• Writing it down or saving it to a USB drive is unsafe.
• Commercial implementations use ad-hoc devices like cryptographic calculators and SecurID.
• Banks are abandoning SecurID due to MITM (Man-in-the-Middle) and MITB (Man-in-the-Browser) attacks.
• Solution: Use another online terminal/device.

Strong Authentication with Asymmetric Algorithms

• $s$ := keypair <$K<em>{pub}$, $K</em>{priv}$> (two keypairs for mutual authentication).
• Variant: $s$ := certificates generated by Z for {A, B, …}, where Z is a Certification Authority (CA).
• Can be based on asymmetric algorithms (digital signatures or encryption).
• Main Problems:
  • Authentication of public keys.
  • Computationally complex.

Challenge-Response Authentication with Asymmetric Algorithms: Example

• Based on deciphering.
• One way authentication.
• Uses Message Digest Code (MDC) to counter chosen-text attacks.
• Recommendation: Always use different keys for different purposes, or ensure your encryption library conforms to a secure standard like PKCS.

Challenge-Response Authentication with Asymmetric Algorithms: Examples from ISO/IEC 9798-3

• Based on Digital Signatures
  • Timestamp (t): One-way authentication, network efficiency.
  • Random challenges (nonces: c1, c2): Mutual authentication.
  • Including c2: Challenge from A to B, prevents chosen-text attacks.

Strong Authentication: Zero-Knowledge Proof Protocols

• Ideally, these protocols allow B to verify that A knows something without revealing anything to B that he already knew.
• B gains zero-knowledge on A’s secret after a protocol run.
• Challenge-response protocols based on asymmetric ciphers are close to this property.
• Introduce probabilistic authentication: B becomes more certain on A’s identity at each step.
• A good ZK protocol makes the probability of authentication close to 1, even after a few steps.

Attacks on Authentication Protocols

Snooping and Database Reading

• Snooping: Observing multiple protocol runs to derive credentials or mount replay attacks.
• Weak password authentication protocols are vulnerable.
• Countermeasures: Use time-variant and identity-variant quantities.
• Database Reading: Reading the credentials database.

False Identity (Chosen-Text)

• Posing as Bob and asking Alice to transform specific data (challenges).
• Challenge-response protocols are vulnerable.
• Countermeasures:
  • Use time-variant quantities, chosen by each participant.
  • Link the quantities used by each participant.
  • Include random data when transforming challenges.
  • Use different keys for different goals.

Reflection Attack

• Initiating multiple parallel runs, posing as Alice.
• Countermeasures:
  • Use different keys in the two directions.
  • Don't let Alice (the user) initiate the protocol.
  • Avoid symmetries in messages.

Interleaving Attack

• Initiating multiple parallel runs, one posing as Bob to Alice, and one posing as Alice to Bob.
• Lesson: Be careful with nonces (not too many).
• Sequentially link the challenges in a run.

Multi-Factor Authentication (MFA)

Why We Need Better Authentication

• Increasing cyber-attacks and data breaches (phishing, keylogging).
• Weaknesses of single-factor (password-only) authentication.
• Need for additional layers of security.
• Two-factor authentication (2FA) if two layers are present; otherwise, it's MFA.

How 2FA Works in Practice

• User enters username and password.
• System prompts for a second factor.
• User provides token, biometric scan, or one-time code.
• Access granted upon successful verification.

Types of Authentication Factors

• Combining factors from different categories increases security.
  • Knowledge Factor: Passwords, PINs.
  • Possession Factor: Hardware tokens, SMS codes, mobile apps.
  • Inherence Factor: Fingerprints, facial recognition.

Protocols and Examples

• One-Time passwords: Time-based (TOTP) and Counter-based (HOTP) (less replay attacks).
• Challenge-Response or use of Certificates.
• Software Tokens: Google Authenticator.
• Hardware Tokens: RSA SecurID.
• Biometric Systems (fingerprint scanner, e.g., on phones).
• Custom Apps running on phones.

Authentication and Ephemeral Key Setup

Setup of Ephemeral Keys

• Problem: Deriving or generating ephemeral session keys ($K_t$).
• Ephemeral keys must be explicitly authenticated (objective guarantees that only the active and authenticated parties know it).
• There's a strong link between entity authentication and ephemeral key authentication.
• Ephemeral keys are derived, generated, or transported during authentication protocol execution.
• Ephemeral keys are opposed to master keys, which last longer than a single session.

Why Use Ephemeral (Session) Keys

• Frequently changing a (session) key limits the amount of ciphertext for analysis.
• If an ephemeral key is discovered, only data protected by it is compromised.
• Alice can derive different session keys for simultaneous sessions with the same person/different people, even with the same master key.

Ideal Property: Perfect Forward Secrecy (PFS)

• A protocol offers PFS if compromising the master key at time $t$ doesn't allow deriving session keys generated up to $t-1$.
• Compromising the master key after a session doesn't compromise that session's security.
• Typical Scenario: Trudy records data from $t_0$ to $t-1$, discovers the master key at time $t$, but can't recover plaintexts protected by ephemeral keys from past sessions.

Ideal Property: Perfect Forward Secrecy (PFS)/2

• Examples
  • EKE offers PFS if A and B erase $S<em>a, S</em>b, K$ after the session.
  • No mechanism transporting the ephemeral key encrypted with the master key can offer PFS.
• Even if a protocol offers PFS, future sessions are compromised once the master key is discovered.
• A protocol offers forward secrecy if compromising a session’s ephemeral keys doesn't compromise future or past session keys.

Ideal Properties: Resistance to Known-Key Attacks

• If Trudy compromises past session keys, she must not be able to compromise future keys, the master key, or impersonate entities.
• Analogy to known-plaintext attacks on encryption algorithms.
• Immunity to these attacks is important because:
  • Ephemeral keys are often seen as less critical than master keys, increasing their compromise probability.
  • Ephemeral keys can be used to encrypt significant amounts of data.

Ephemeral Key Setup: Classes of Protocols

• Key Transported:
  • A, B, or Z generates $K_t$.
  • $K_t$ protected by the master key.
  • Pros: Network efficiency, simplicity.
  • Cons: No PFS, tough to protect from replay attacks.
• Key Derived:
  • A and B exchange quantities to calculate $K_t$.
  • Each participant contributes to $K_t$ generation.
  • Pros: PFS can be possible, replay attacks are easier to deal with.
  • Cons: More complex/inefficient.

2-Party Ephemeral Key Setup: $K_t$ Is Transported

• $K_t$ can be simply transported (encrypted).
• Recipient identity inclusion prevents replay attacks towards A.
• Problems: replay attack (towards B), no PFS.
• $E<em>k$ must ensure integrity+privacy (e.g., $E</em>k(m | MDC(m))$).
• Adding nonces/counters counters replay attacks.
• Digital signatures allow strong authentication of the key source.
• Timestamps, counters, or nonces can prevent replay attacks.

2-Party Ephemeral Key Setup: $K_t$ Is Derived

• Key factor: Both participants contribute to $K_t$ generation.
• Nonces prevent replay attacks, while random numbers $r<em>a, r</em>b$ generate $K<em>t$ ($K</em>t = MDC(r<em>a|r</em>b)$).
• $E<em>k$ must provide both confidentiality AND integrity protection (e.g., $E</em>k(m | MDC(m))$). This protocol does not provide PFS.
• Station To Station (STS) Protocol: Authenticated Diffie-Hellman variant.
  • Public/private keypairs (possibly certificates) authenticate base DH.
• $K<em>t = g^{S</em>aS_b} \, mod \, p$ PFS.
  • The exchange of signatures encrypted with $K<em>t$ confirms that both parties possess the correct $K</em>t$ and that the party who co-generated $K_t$ is the same as the one who created the signature.
  • Cons: Computational complexity (DH + digital signatures).

Attacks

• Attacks on these protocols are usually extensions of attacks on authentication protocols.
• Be careful with nonces: not too few, not too many.