Authentication applications Digital signatures Key management Kerberos X-509.

Authentication applications

• Digital signatures

• Key management

• Kerberos

• X-509

Digital Signatures

Cryptographic technique analogous to hand-written signatures.

• sender (Bob) digitally signs document, establishing he is document owner/creator.

• The signiture is verifiable, nonforgeable: recipient (Alice) can prove to someone that Bob, and no one else (including Alice), must have signed document

Digital Signatures Simple digital signature for message m:• Bob signs m by encrypting with his private key

KB, creating “signed” message, KB(m)--

Dear Alice

Oh, how I have missed you. I think of you all the time! …(blah blah blah)

Bob

Bob’s message, m

Public keyencryptionalgorithm

Bob’s privatekey

K B-

Bob’s message, m, signed

(encrypted) with his private key

K B-(m)

Digital Signatures (more)

• Suppose Alice receives msg m, digital signature KB(m)

• Alice verifies m signed by Bob by applying Bob’s public key KB to KB(m) then checks KB(KB(m) ) = m.

• If KB(KB(m) ) = m, whoever signed m must have used Bob’s

private key.

+ +

-

-

- -

+

Alice thus verifies that: Bob signed m. No one else signed m. Bob signed m and not m’.

Non-repudiation: Alice can take m, and signature KB(m) to court and prove that

Bob signed m. -

Trusted IntermediariesSymmetric key problem:• How do two entities

establish shared secret key over network?

Solution:• trusted key distribution

center (KDC) acting as intermediary between entities

Public key problem:• When Alice obtains

Bob’s public key (from web site, e-mail, diskette), how does she know it is Bob’s public key, not Trudy’s?

Solution:• trusted certification

authority (CA)

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 (from 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+

A certificate contains:

• Serial number (unique to issuer)• info about certificate owner, including algorithm

and key value itself (not shown) • info about certificate issuer

• valid dates• digital signature by issuer

Key ManagementPublic-Key Certificate Use

Security Concerns

• key concerns are confidentiality and timeliness • to provide confidentiality must encrypt

identification and session key info • which requires the use of previously shared

private or public keys • need timeliness to prevent replay attacks • provided by using sequence numbers or

timestamps or challenge/response

Approaches to distributed security

• Rely on each client WS (workstation) to assure identity of its user and rely on each server to enforce a security policy based on user ID.

• Require that client systems authenticate to servers, but trust the clients concerning identity of its user.

• Require the user to prove identity for each service invoked and each server to prove its identity to clients.

KERBEROS

In Greek mythology, a many headed dog, the guardian of the entrance of Hades

KERBEROS

• Users wish to access services on servers.

• Three threats exist:– User pretend to be another user.– User alter the network address of a workstation.– User eavesdrop on exchanges and use a replay

attack.

Requirements for Kerberos design

• Secure

• Reliable

• Transparent

• Scalable

KERBEROS

• Provides a centralized authentication server to authenticate users to servers and servers to users.

• Relies on conventional encryption, making no use of public-key encryption

• Two versions: version 4 and 5

• Version 4 makes use of DES

Kerberos Version 4

• Terms:– C = Client– AS = authentication server– V = server– IDc = identifier of user on C– IDv = identifier of V– Pc = password of user on C– ADc = network address of C– Kv = secret encryption key shared by AS an V– TS = timestamp– || = concatenation

A Simple Authentication Dialogue

(1) C -> AS: IDc || Pc || IDv

(2) AS -> C: Ticket

(3) C -> V: IDc || Ticket

Ticket = EKv[IDc || ADc || IDv]

Problem: transmission of password in the open let an intruder to capture it

A Better Authentication Dialogue

• Once per logon session:• (1) C -> AS: IDc || IDtgs• (2)AS -> C: Ekc[Tickettgs]• Once per type of service:• (3)C->TGS: Idc|| Idv||Tickettgs• (4) TGS -> C: Ticketv• Once per service session:• (5) C-> V: IDc || Ticketv

Tickettgs = EKtgs[IDc || ADc || Idtgs||TS1||Lifetime1]

Ticketv = EKv[IDc || ADc || Idv||TS2||Lifetime2]

Version 4 Authentication Dialogue

• Problems:– Lifetime associated with the ticket-granting ticket– If too short repeatedly asked for password– If too long greater opportunity to replay

• The threat is that an opponent will steal the ticket and use it before it expires

• The servers may have to authenticate themselves to the users

Version 4 Authentication DialogueAuthentication Service Exhange: To obtain Ticket-Granting Ticket

(1) C -> AS: IDc || IDtgs ||TS1

(2) AS -> C: EKc [Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs]

Ticket-Granting Service Echange: To obtain Service-Granting Ticket

(3) C -> TGS: IDv ||Tickettgs ||Authenticatorc

(4) TGS -> C: EKc [Kc,¨v|| IDv || TS4 || Ticketv]

Client/Server Authentication Exhange: To Obtain Service

(5) C -> V: Ticketv || Authenticatorc

(6) V -> C: EKc,v[TS5 +1]

Overview of Kerberos

Kerberos realms

• Realm - a Kerberos server, a number of clients and a number of application servers

• Kerberos server must have user ID and hashed password of all participating users in its database

• Kerberos server must share a secret key with each server. All servers are registered with the Kerberos server.

• Kerberos servers in each interoperating realm shares a secret key with the server in the other realm. The two Kerberos servers are registered with each other.

Request for Service in Another Realm

Environmental shortcomings of Version 4

• Encryption system dependence (DES)

• Internet protocol dependence

• Message byte ordering

• Ticket lifetime

• Authentication forwarding

• Interrealm authentication

Technical deficiences of Version 4

• Double encryption (removed in V5)

• PCBC encryption (standard CBC in V5)

• Session keys (subsession keys in V5)

• Password attacks (preauthentication in V5 to make attack more difficult)

Kerberos Encryption Techniques

PCBC Mode

Kerberos - in practice • Currently have two Kerberos versions:

• 4 : restricted to a single realm • 5 : allows inter-realm authentication, in beta test • Kerberos v5 is an Internet standard • specified in RFC1510, and used by many utilities • To use Kerberos: • need to have a KDC on your network • need to have Kerberised applications running on all participating systems • major problem - US export restrictions • Kerberos cannot be directly distributed outside the US in source format (&

binary versions must obscure crypto routine entry points and have no encryption)

• else crypto libraries must be reimplemented locally

Why Study Kerberos v4

(Why doesn't everyone switch to v5)

Kerberos V4 is working well in many systems

Switching to V5 requires stopping the networkand upgrading every host at once before restart

Kerberos V5 is inefficient in some ways comparedto V4

• Specified in ASN.1 (abstraction good and bad)

• Example: 11 bytes required for 4-byte IP address.

29

X.509 Authentication Service

• Distributed set of servers that maintains a database about users.

• Based on public key cryptography and digital signiture• Each certificate contains the public key of a user and is

signed with the private key of a CA.• Is used in S/MIME, IP Security, SSL/TLS and SET.• RSA is recommended to use.• Unspecified hash algorithm.

X.509 Formats

Typical Typical Digital Digital Signature ApproachSignature Approach

Certificate notation

• CA<<A>> = CA{V,SN, AI, CA, Ta, A, Ap}• Y<<X>> = certificate of user X issued by

certificate authority Y• Y{I} = the signing of I by Y. It consists of I with

an encrypted hash code appended

Obtaining a User’s Certificate

• Characteristics of certificates generated by CA:– Any user with access to the public key of the

CA can recover the user public key that was certified.

– No part other than the CA can modify the certificate without this being detected.

Different CAs

• Let A has certificate from X1, while B has certificate from X2.

• A obtain from directory the certificate of X2, signed by X1.A can obtain X2’s public key from its certificate and verify it by means of X1’s signature on the certificate.

• A then goes back to the directory and obtains the certificate of B signed by X2. A can verify the signature and securely obtain B’s public key

Notation

• A is certified by X1, B is certified by X2• A obtains B’s public key:

X1<<X2>> X2<<B>>• B obtains A’s public key:

X2<<X1>>X1<<A>>

X.509 CA Hierarchy

Chain of certificates

• From A to B

• X<<W>> W<<V>> V<<Y>> Y<<Z>> Z<<B>>

• From B to A

• Z<<Y>> Y<<V>> V<<W>> W<<X>> X<<A>>

Revocation of Certificates

• Reasons for revocation:

– The users secret key is assumed to be compromised.

– The user is no longer certified by this CA.

– The CA’s certificate is assumed to be compromised.

– Each CA must maintain Certificate Revocation List (CRL)

Authentication Procedures

• Make use of public-key signatures

• One way:

• establishes the identity of A and that the message was generated by A

• That the message is intended for B

• The integrity and originality of the message

Authentication Procedures

• Two-way: in addition• establishes the identity of B and that the message

was generated by B• That the message is intended for A• The integrity and originality of the message• Three-way: in addition • a final message from A to B is included, which

contains a signed copy of the nonce rb. The intent is that timestamps need not to be checked

Authentication Procedures

Requirements not satisfied by X509 Version 2

• Subject field inadequate:

- to convey identity of a key owner - for applications using Internet email address etc,

• Need to indicate security policy information

• Need to limit damage from a faulty or malicious CA

• Ability to identify different keys used by the same owner

X.509 Version 3

• Approach - optional extensions which may be added to Version 2

• Extensions categories: - key and policy information, - subject and issuer attributes, - certification path constraints

Key and policy information

• Authority key identifier

• Subject key identifier

• Key usage

• Private key usage period

• Certificate policies

• Policy mapping

Certificate Subject and Issuer Attributes

• Subject alternative name

• Issuer alternative name

• Subject directory attributes

Certification Path Constraints

• Basic constraints

• Name constraints

• Policy constraints

Public Key Infrastructure Model

• End entity

• Certification authority

• Registration authority

• CRL issuer

• Repository

PKIX Management functions

• Registration

• Initialization

• Certification

• Key pair recovery

• Key pair update

• Revocation request

• Cross certification