Cryptography and Network Security 1 Network Security Key Distribution and User Authentication WenZhan Song.

Cryptography and Network Security 1

Network Security

Key Distribution and User Authentication

WenZhan Song


Authentication: ap4.0 (symmetric key)

Goal: avoid playback attack

It assume K is established before, but how?

Nonce: number (R) used only once –in-a-lifetime

ap4.0: to prove Alice “live”, Bob sends Alice nonce, R. Alice

must return R, encrypted with shared secret key“ I am Alice”

R

K (R)A-B

Alice is live, and only Alice knows key to encrypt

nonce, so it must be Alice!

A-B

Key Distribution Center (KDC)

Alice, Bob need shared symmetric key. KDC: server shares different secret key

with each registered user (many users) Alice, Bob know own symmetric keys, KA-KDC

, KB-KDC , for communicating with KDC.

KB-KDC

KX-KDC

KY-KDC

KZ-KDC

KP-KDC

KB-KDC

KA-KDC

KA-KDC

KP-KDC

KDC

Key Distribution Center (KDC)

Aliceknows

R1

Bob knows to use R1 to communicate with Alice

Alice and Bob communicate: using R1 as session key for shared symmetric

encryption

Q: How does KDC allow Bob, Alice to determine shared symmetric secret key to communicate with

each other? KDC generate

s R1

KB-KDC(A,R1)

KA-KDC(A,B)

KA-KDC(R1, KB-KDC(A,R1) )


Authentication: ap5.0 (public key)

ap4.0 requires shared symmetric key can we authenticate using public key techniques?ap5.0: use nonce, public key cryptography

“ I am Alice”

RBob computes

K (R)A-

“ send me your public key”

K A+

(K (R)) = RA

-K A

+

and knows only Alice could have the

private key, that encrypted R such that

(K (R)) = RA-

K A+

It is vulnerable to man-in-middle attack. How to solve?

Certification Authorities

Certification authority (CA): binds public key to particular entity, E.

E (person, router) registers its public key with CA. E provides “proof of identity” to CA. CA creates certificate binding E to its public key. certificate containing E’s public key digitally signed by CA – CA

says “this is E’s public key”Bob’s public

key K B+

Bob’s identifying informatio

n

digitalsignature(encrypt)

CA private

key K CA-

K B+

certificate for Bob’s public

key, signed by CA

Certification Authorities

When Alice wants Bob’s public key: gets Bob’s certificate (Bob or elsewhere). apply CA’s public key to Bob’s certificate, get Bob’s public key

Bob’s public

key K B+

digitalsignature(decrypt)

CA public

key K CA+

K B+


Symmetric Key Distribution using symmetric encryption

Symmetric Key Distribution using symmetric encryption

For symmetric encryption to work, the two parties of an exchange must share the same key, and that key must be protected from access by others

Frequent key changes are usually desirable to limit the amount of data compromised if an attacker learns the key

Key distribution technique The means of delivering a key to two parties that wish

to exchange data, without allowing others to see the key

Key Distribution

For two parties A and B, there are the following options:

Kerberos Kerberos is one KDC implementation Key distribution and user authentication service

developed at MIT Provides a centralized authentication server

whose function is to authenticate users to servers and servers to users

Relies exclusively on symmetric encryption, making no use of public-key encryption

Kerberos version 4

A basic third-party authentication scheme

Authentication Server (AS) Users initially negotiate with AS to identify self AS provides a non-corruptible authentication

credential (ticket granting ticket TGT)

Ticket Granting Server (TGS) Users subsequently request access to other services

from TGS on basis of users TGT

Complex protocol using DES

First try

Problems: User will be prompted to enter password every time for

accessing services; Password is transmitted in plaintext and can be

captured by bad guy.


Second try Address problems in 1st

try by adding TGS and avoiding password transmission

Problems: Replay attack – bad guy

captures ticket and reuses it before expires.

False server – capture user info


Final try – Kerberos V4

Add session key between user and server, e.g., Kc, tgs and Kc,v

Add more timstamps including starttime Add Authenticator which is used once

and has short lifetime for mutual authentication between C and V or tgs.


Table 4.1 Summary of Kerberos Version 4 Message Exchanges

Kerberos Realms

Kerberos realm A set of managed nodes that share

the same Kerberos database The Kerberos database resides on

the Kerberos master computer system, which should be kept in a physically secure room

A read-only copy of the Kerberos database might also reside on other Kerberos computer systems

All changes to the database must be made on the master computer system

Changing or accessing the contents of a Kerberos database requires the Kerberos master password

Kerberos principal

A service or user that is known to the Kerberos system

Each Kerberos principal is identified by its principal name

Principal names consist of three parts

Differences between versions 4 and 5

Environmental shortcomings

Encryption system dependence

Internet protocol dependence

Message byte ordering

Ticket lifetime Authentication

forwarding Interrealm

authentication

Technical deficiencies

Double encryption

PCBC encryption Session keys Password attacks


Distribution of Public-key

Key distribution using asymmetric encryption

One of the major roles of public-key encryption is to address the problem of key distribution

There are two distinct aspects to the use of public-key encryption in this regard: The distribution of public keys The use of public-key encryption to distribute secret keys (will address later)

Public-key certificate Consists of a public key plus a user ID of the key owner, with the whole block

signed by a trusted third party Typically, the third party is a certificate authority (CA) that is trusted by the user

community, such as a government agency or a financial institution A user can present his or her public key to the authority in a secure manner and

obtain a certificate The user can then publish the certificate Anyone needing this user’s public key can obtain the certificate and verify that it

is valid by way of the attached trusted signature


Distribution of Public Keys

can be considered as using one of: Public announcement Publicly available directory Public-key authority Public-key certificates


Public Key Management

Simple one: publish the public key Such as newsgroups, yellow-book, etc. But it is not secure, although it is convenient

Anyone can forge such a announcement Ex: user B pretends to be A, and publish a key for

A Then all messages sent to A, readable by B!

Let trusted authority maintain the keys Need to verify the identity, when register keys User can replace old keys, or void old keys


Possible Attacks

Observe all messages over the channel So assume that all plaintext messages are available to

all

Save messages for reuse later So have to avoid replay attack

Masquerade various users in the network So have to be able to verify the source of the message


Public Announcement

users distribute public keys to recipients or broadcast to community at large eg. append PGP keys to email messages or post to news

groups or email list

major weakness is forgery anyone can create a key claiming to be someone else

and broadcast it until forgery is discovered can masquerade as claimed

user


Publicly Available Directory

can obtain greater security by registering keys with a public directory

directory must be trusted with properties: contains {name,public-key} entries participants register securely with directory participants can replace key at any time directory is periodically published directory can be accessed electronically

still vulnerable to tampering or forgery


Public-Key Authority

improve security by tightening control over distribution of keys from directory

has properties of directory and requires users to know public key

for the directory then users interact with directory to

obtain any desired public key securely does require real-time access to directory when keys

are needed


Public-Key Authority


Cont.

More advanced distribution A sends request-for-key(B) to authority with time-

stamp, that is, Ida|Idb|Time Authority replies with key(B) (encrypted by its private

key), that is EKTta(KUb| Ida|Idb|Time)

A initiates a message to B, including a random number Na, its IDA

B then ask authority to get key(A) B sends A (encrypted by A’s public key) Na and Nb

A then replies B Nb encrypted by B’s public key


Cont.

In above scheme, the authority is bottleneck

New approach: certificate Any user can read certificate, determine name and

public key of the certificate’s owner Any user can verify the authority of certificate Only the authority can create and update certificate Any user can verify the time-stamp of certificate

The certificate is CA=EKRauth[T,IDA, KUA] Time-stamp is to avoid reuse of voided key


Public-Key Certificates

certificates allow key exchange without real-time access to public-key authority

a certificate binds identity to public key usually with other info such as period of validity, rights of use etc

with all contents signed by a trusted Public-Key or Certificate Authority (CA)

can be verified by anyone who knows the public-key authorities

To validate the certificate, we need another certificate, one that matches the Issuer (of CA) in the first certificate. Then we take the RSA public key from the second (CA) certificate, use it to decode the signature on the first certificate to obtain an MD5 hash, which must match an actual MD5 hash computed over the rest of the certificate.


Public-Key Certificates

X.509 Certificates

ITU-T recommendation X.509 is part of the X.500 series of recommendations that define a directory service

Defines a framework for the provision of authentication services by the X.500 directory to its users

The directory may serve as a repository of public-key certificates

Defines alternative authentication protocols based on the use of public-key certificates Was initially issued in 1988 Based on the use of public-key cryptography and digital signatures

The standard does not dictate the use of a specific algorithm but recommends RSA


Sample Certificate Certificate: Data: Version: 1 (0x0) Serial Number: 7829 (0x1e95) Signature Algorithm: md5WithRSAEncryption Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification

Services Division, CN=Thawte Server CA/[email protected] Validity

Not Before: Jul 9 16:04:02 1998 GMT Not After : Jul 9 16:04:02 1999 GMT

Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft, CN=www.freesoft.org/[email protected]

Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:

33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1: 66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66: 70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17: 16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b: c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77: 8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3: d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8: e8:35:1c:9e:27:52:7e:41:8f

Exponent: 65537 (0x10001) Signature Algorithm: md5WithRSAEncryption

93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d: 92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92: ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67: d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72: 0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1: 5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7: 8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22: 68:9f

Obtaining a user’s certificate

User certificates generated by a CA have the following characteristics: Any user with access to the public key of the CA can

verify the user public key that was certified No party other than the certification authority can

modify the certificate without this being detected

Because certificates are unforgeable, they can be placed in a directory without the need for the directory to make special efforts to protect them

A acquires the certificate of B: X<<W>> W<<V>> V<<Y>> Y<<Z>> Z<<B>>B acquires the certificate of A: Z<<Y>> Y<<V>> V<<W>> W<<X>> X<<A>>

Revocation of certificates

Each certificate includes a period of validity

Typically a new certificate is issued just before the expiration of the old one

It may be desirable on occasion to revoke a certificate before it expires for one of the following reasons:

The user’s private key is assumed to be compromised

The user is no longer certified by this CA; reasons for this include subject’s name has changed, the certificate is superseded, or the certificate was not issued in conformance with the CA’s policies

The CA’s certificate is assumed to be compromised

X.509 Version 3

Key and policy information

These extensions convey additional information about the subject and issuer keys, plus indicators of certificate policy

A certificate policy is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements

Certificate subject and issuer attributes These extensions support alternative names,

in alternative formats, for a certificate subject or certificate issuer and can convey additional information about the certificate subject to increase a certificate user’s confidence that the certificate subject is a particular person or entity

Certification path constraints

These extensions allow constraint specifications to be included in certificates issued for CAs by other CAs

The constraints may restrict the types of certificates that can be issued by the subject CA or that may occur subsequently in a certification chain

PKIX Management functions

Functions that potentially need to be supported by management protocols: Registration Initialization Certification Key pair recovery Key pair update Revocation request Cross certification

Alternative management protocols: Certificate management protocols (CMP)

Designed to be a flexible protocol able to accommodate a variety of technical, operational, and business models

Certificate management messages over CMS (CMC) Is built on earlier work and is intended to leverage existing

implementations

Identity Management

A centralized, automated approach to provide enterprise wide access to resources by employees and other authorized individuals Focus is defining an identity for each user (human or process), associating

attributes with the identity, and enforcing a means by which a user can verify identity

Central concept is the use of single sign-on (SSO) which enables a user to access all network resources after a single authentication

Principal elements of an identity management system: Authentication Authorization Accounting Provisioning Workflow automation Delegated administration Password synchronization Self-service password reset Federation

Standards


Public-key distribution of secret keys


Public-Key Distribution of Secret Keys

use previous methods to obtain public-key

can use for secrecy or authentication but public-key algorithms are slow so usually want to use private-key

encryption to protect message contents hence need a session key have several alternatives for negotiating

a suitable session


Key Exchange

Public key systems are much slower than private key system Public key system is then often for short data

Signature, key distribution

Key distribution One party chooses the key and transmits it to other user

Key agreement Protocol such two parties jointly establish secret key

over public communication channel Key is the function of inputs of two users


Simple Secret Key Distribution

proposed by Merkle in 1979 A generates a new temporary public key pair A sends B the public key and their identity B generates a session key K sends it to A encrypted

using the supplied public key A decrypts the session key and both use

problem is that an opponent can intercept and impersonate both halves of protocol


Secret key Distribution

Simple secret key distribution A generates KUA and KRA, sends KUA to B

B generates a secret key ks

B sends ks to A using A’s public key KUA

A decrypts the message to get the secret key ks

To get more security, the public/private keys can be regenerated when needed

But vulnerable to the active attack! Attacker E can compromise the communication

between A and B as follows


Cont.

Attacking A generates KUA and KRA, sends IDA, KUA to B

E intercepts the message, transmits IDA, KUE to B

B generates a secret key ks

B sends ks to A using A’s “public key” KUE

E intercepts the message, decrypt it and get ks

E sends A the message Ks, encrypted by KUA

A decrypts the message to get the secret key ks

Now E knows Ks, but A, B are unaware of it


Secret Key Distribution

So need confidentiality and authentication A and B need to use a secure method to exchange their

public keys

Schemes A initiates a message to B, EKUB(Na,IDa)

B replies it with EKUA(Na,Nb)

A then replies it with EKUB(Nb)

A sends B the message EKUB (EKRA(Ks))

Security The first 3 steps are used to assure that A is A, B is B


Public-Key Distribution of Secret Keys

if have securely exchanged public-keys:


Key Predistribution

Trusted Authority (TA) generates keys for all pair of users and transmits to them Large overhead (for TA and user)

Blom Scheme Keys are chosen from a finite field Zp

P is public prime number TA transmits k+1 elements of Zp to each user over

secure channel Secure condition: any set of at most k users (not U,V)

can not determine any information about Ku,v


Blom Scheme

Scheme (when k=1) Each user u has distinct element ru from Zp

TA choose a,b,c and defines f(x,y)=a+b(x+y)+cxy mod p

For each u, TA computes gu(x)=f(x, ru) mod p

TA transmits gu(x) to user u

Two users u and v compute the common key f(ru, rv)= a+b(ru + rv)+c ru rv mod p

Here f(ru, rv)= gv(ru)= gu(rv)


Security of Blom Scheme

Less than k users can not determine keys

However, more than k users can compute any keys Solving equations to get a,b,c for k=1

Generally Function f(x,y)=Sum ai,jxiyj mod p

Here ai,j=aj,i


Diffie-Hellman Key Predist.

Computationally secure if discrete logarithm is intractable

Scheme Assume prime number p public and an integer c public Each user u has secret component au

User u computes bu=c au mod p

TA certifies it by computing (ID(u), bu, sigTA(ID(u), bu))

The common key of two users u and v is K=c

au av mod p


Diffie Hellman

Around September 1974, Diffie (Graduate student) had been traveling USA with his wife, Mary, discussing cryptography with anyone who was available. At the time, there was very little published

material about modern methods and much was classified. Very few people were interested in the topic and Marty Hellman even says that many of his colleagues felt that it was "born classified," like secrets about the atomic bomb, because it was so important to national security.

John Gill gave the idea of exponential


Diffie-Hellman Problem

Diffie-Hellman problem definition Given bu=gau mod p, bv=gav mod p, how to compute

gavau mod p? Here g is a primitive element of mod p The problem is not harder than the discrete log-

arithmetic problem, because the later one can always be used to solve it

It can be proved that it has the same difficulty as the ElGamal encryption system


Diffie-Hellman Key Exchange

Computationally secure if discrete logarithm is intractable

Scheme Assume prime number p public and an integer c public Each user u chooses a secret component au (new!)

User u computes bu=c au mod p

User v computes bv=c av mod p


au av mod p


Middle Attack

Intruder w intercept the communications Intruder w communications with u Intruder w communications with v The key computed by u is

K=c au av’ mod p

u w vc

au c au’

c av’ c

av


Authenticated Key Agreement

Introducing the identification scheme before key exchange does not help The attacker remains inactive until identification done

Simplified station to station protocol Key agreement protocol itself authenticates the user’s

identity at the same time the key being defined


Station-to-station Protocol

Scheme Each user has a certificate

C(v)=(Idv,verv,sigTA(Idv,verv)) User u selects au and computes bu=c

au mod p User v selects av and computes

Value bv=c av mod p

Key K=c au av mod p

Signature yv=sigv(bu,bv) User v sends (C(V), bv, yv) to U User u computes K=c

au av mod p, verifies yv, and C(V) User u computes yu=sigu(bu,bv), sends (C(u),yu) to V User v verifies yu, and C(u)


MTI Agreement Protocol

Scheme Assume prime number p public and an integer c public Each user has certificate c(u)=(Idu,bu, sigTA(Idu,bu))

Here bu= c au mod p

Each user u chooses a secret component ru (new!)

User u computes su=c ru mod p, sends (c(u),su)

User v computes sv=c rv mod p, sends (c(v),sv)


rvau+ ru av mod p= sv aubv ru mod p= su

avbu rv mod p

Summary

Symmetric key distribution using symmetric encryption

Kerberos Version 4 Version 5

Key distribution using asymmetric encryption Public-key certificates Public-key distribution

of secret keys

X.509 certificates Certificates X.509 Version 3

Public-key infrastructure PKIX management

functions PKIX management

protocols Federated

identity management Identity management Identity federation

Cryptography and Network Security 1 Network Security Key Distribution and User Authentication WenZhan Song.

Documents

shared symmetric key

network security cryptography

public key cryptographyi

cas public key

public key techniques

session key

private key

ca cryptography