1. Authentication applications
Digital signatures
Key management
Kerberos
X-509

2. 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

3. Bob’s message, m, signed (encrypted) with his private key
Digital Signatures
Simple digital signature for message m:
Bob signs m by encrypting with his private key KB, creating “signed” message, KB(m) - - K B -
Bob’s message, m
Bob’s private
key K B -
(m)
Dear Alice
Oh, how I have missed you. I think of you all the time! …(blah blah blah)
Bob
Bob’s message, m, signed (encrypted) with his private key
Public key
encryption
algorithm

4. 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. -

5. Trusted Intermediaries
Symmetric 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, , diskette), how does she know it is Bob’s public key, not Trudy’s?
Solution:
trusted certification authority (CA)

6. 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”
digital
signature
(encrypt)
Bob’s
public
key K B + K B + CA
private
key
certificate for Bob’s public key, signed by CA -
Bob’s
identifying information K CA

7. 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
digital
signature
(decrypt) K B +
Bob’s
public
key K B + CA
public
key + K CA

8. 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

9. Key Management Public-Key Certificate Use

10. 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

11. 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.

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

13. 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.

14. Requirements for Kerberos design
Secure
Reliable
Transparent
Scalable

15. 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

16. 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

17. A Simple Authentication Dialogue
C -> AS: IDc || Pc || IDv
AS -> C: Ticket
C -> V: IDc || Ticket
Ticket = EKv[IDc || ADc || IDv]
Problem: transmission of password in the open let an intruder to capture it

18. 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]

19. 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

20. Version 4 Authentication Dialogue
Authentication Service Exhange: To obtain Ticket-Granting Ticket
C -> AS: IDc || IDtgs ||TS1
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]

21. Overview of Kerberos

22. 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.

23. Request for Service in Another Realm

24. Environmental shortcomings of Version 4
Encryption system dependence (DES)
Internet protocol dependence
Message byte ordering
Ticket lifetime
Authentication forwarding
Interrealm authentication

25. 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)

26. Kerberos Encryption Techniques

27. PCBC Mode

28. 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

29. 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 network
and upgrading every host at once before restart
Kerberos V5 is inefficient in some ways compared
to V4 •
Specified in ASN.1 (abstraction good and bad) •
Example: 11 bytes required for 4-byte IP address. 29

30. 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.

31. X.509 Formats

32. Typical Digital Signature Approach

33. 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

34. 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.

35. 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

36. 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>>

37. X.509 CA Hierarchy

38. 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>>

39. 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)

40. 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

41. 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

42. Authentication Procedures

43. Requirements not satisfied by X509 Version 2
Subject field inadequate:
- to convey identity of a key owner for applications using Internet 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

44. 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

45. Key and policy information
Authority key identifier
Subject key identifier
Key usage
Private key usage period
Certificate policies
Policy mapping

46. Certificate Subject and Issuer Attributes
Subject alternative name
Issuer alternative name
Subject directory attributes

47. Certification Path Constraints
Basic constraints
Name constraints
Policy constraints

48. Public Key Infrastructure Model
End entity
Certification authority
Registration authority
CRL issuer
Repository

49. PKIX Management functions
Registration
Initialization
Certification
Key pair recovery
Key pair update
Revocation request
Cross certification