Скачать презентацию Authentication applications Digital signatures Key management Скачать презентацию Authentication applications Digital signatures Key management

49dccd43002a244543db5fe54f50601c.ppt

  • Количество слайдов: 49

Authentication applications • • Digital signatures Key management Kerberos X-509 Authentication applications • • Digital signatures Key management Kerberos X-509

Digital Signatures Cryptographic technique analogous to handwritten signatures. • sender (Bob) digitally signs document, 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 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) • 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 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. • 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 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, 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 Key Management Public-Key Certificate Use

Security Concerns • key concerns are confidentiality and timeliness • to provide confidentiality must 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 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 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: – 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 Requirements for Kerberos design • • Secure Reliable Transparent Scalable

KERBEROS • Provides a centralized authentication server to authenticate users to servers and servers 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 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 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: 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 – 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 -> 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 Overview of Kerberos

Kerberos realms • Realm - a Kerberos server, a number of clients and a 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 Request for Service in Another Realm

Environmental shortcomings of Version 4 • • • Encryption system dependence (DES) Internet protocol 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 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 Kerberos Encryption Techniques

PCBC Mode PCBC Mode

Kerberos - in practice • • Currently have two Kerberos versions: 4 : restricted 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 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 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 X. 509 Formats

Typical Digital Signature Approach Typical Digital Signature Approach

Obtaining a User’s Certificate • Characteristics of certificates generated by CA: – Any user 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 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

X. 509 CA Hierarchy X. 509 CA Hierarchy

Revocation of Certificates • Reasons for revocation: – The users secret key is assumed 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 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 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 Authentication Procedures

Requirements not satisfied by X 509 Version 2 • Subject field inadequate: - to 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 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 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 • Certificate Subject and Issuer Attributes • Subject alternative name • Issuer alternative name • Subject directory attributes

Certification Path Constraints • Basic constraints • Name constraints • Policy constraints Certification Path Constraints • Basic constraints • Name constraints • Policy constraints

Public Key Infrastructure Model • • • End entity Certification authority Registration authority CRL 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 PKIX Management functions • • Registration Initialization Certification Key pair recovery Key pair update Revocation request Cross certification