Authentication applications Digital signatures Key management Kerberos X509
Authentication applications • • Digital signatures Key management Kerberos X-509
Digital Signatures Cryptographic technique analogous to handwritten 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) Bob’s message, m Dear Alice Oh, how I have missed you. I think of you all the time! …(blah) Bob K B Bob’s private key Public key encryption algorithm K B(m) Bob’s message, m, signed (encrypted) with his private key
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 Intermediaries Symmetric key problem: Public key problem: • When Alice obtains • How do two entities Bob’s public key (from establish shared secret key web site, e-mail, over network? diskette), how does she Solution: know it is Bob’s public key, not Trudy’s? • trusted key distribution Solution: center (KDC) acting as intermediary between • trusted certification authority (CA) entities
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 Bob’s identifying information + KB digital signature (encrypt) CA private key K- CA + KB 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 + KB digital signature (decrypt) CA public key + K CA Bob’s public + key KB
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 Management Public-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: (2) AS -> C: (3) C -> V: IDc || Pc || IDv Ticket IDc || 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||TS 1||Lifetime 1] Ticketv = EKv[IDc || ADc || Idv||TS 2||Lifetime 2]
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 Dialogue Authentication Service Exhange: To obtain Ticket-Granting Ticket (1) C -> AS: IDc || IDtgs ||TS 1 (2) AS -> C: EKc [Kc, tgs|| IDtgs || TS 2 || Lifetime 2 || Tickettgs] Ticket-Granting Service Echange: To obtain Service-Granting Ticket (3) C -> TGS: IDv ||Tickettgs ||Authenticatorc (4) EKc [Kc, ¨v|| IDv || TS 4 || Ticketv] TGS -> C: Client/Server Authentication Exhange: To Obtain Service (5) C -> V: (6) V -> C: Ticketv || Authenticatorc EKc, v[TS 5 +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 V 5) PCBC encryption (standard CBC in V 5) Session keys (subsession keys in V 5) Password attacks (preauthentication in V 5 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 v 5 is an Internet standard specified in RFC 1510, 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 v 4 (Why doesn't everyone switch to v 5) Kerberos V 4 is working well in many systems Switching to V 5 requires stopping the network and upgrading every host at once before restart Kerberos V 5 is inefficient in some ways compared to V 4 • 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 Digital Signature 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 X 1, while B has certificate from X 2. • A obtain from directory the certificate of X 2, signed by X 1. A can obtain X 2’s public key from its certificate and verify it by means of X 1’s signature on the certificate. • A then goes back to the directory and obtains the certificate of B signed by X 2. A can verify the signature and securely obtain B’s public key
Notation • A is certified by X 1, B is certified by X 2 • A obtains B’s public key: X 1<<X 2>> X 2<<B>> • B obtains A’s public key: X 2<<X 1>>X 1<<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 X 509 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
- Slides: 49