Authentication (Distributed computing)

Authentication Protocols Paul Krzyzanowski [email_address] [email_address] Distributed Systems Except as otherwise noted, the content of this presentation is licensed under the Creative Commons Attribution 2.5 License.

Authentication Establish and verify identity allow access to resources

Authentication Three factors: something you have key, card can be stolen something you know passwords can be guessed, shared, stolen something you are biometrics costly, can be copied (sometimes)

Authentication factors may be combined ATM machine: 2-factor authentication ATM card something you have PIN something you know

Reusable passwords Keep a database of username:password mappings Prompt for a user name & password Look up the corresponding password in a database (file) to authenticate if (supplied_password == retrieved_password) user is authenticated This is also known as the Password Authentication Protocol (PAP)

Reusable passwords One problem: what if the password file isn’t sufficiently protected and an intruder gets hold of it, he gets all the passwords! Enhancement: Store a hash of the password in a file given a file, you don’t get the passwords have to resort to a dictionary or brute-force attack

Reusable passwords Passwords can be stolen by observing a user’s session over the network: snoop on telnet, ftp, rlogin, rsh sessions Trojan horse social engineering brute-force or dictionary attacks

One-time password Different password used each time generate a list of passwords or: use an authentication card

Skey authentication One-time password scheme Produces a limited number of authentication sessions relies on one-way functions

Skey authentication Authenticate Alice for 100 logins pick random number, R using a one-way function, f(x): x 1 = f(R) x 2 = f(x 1 ) = f(f(R)) x 3 = f(x 2 ) = f(f(f(R))) … … x 100 = f(x 99 ) = f(…f(f(f(R)))…) then compute: x 101 = f(x 100 ) = f(…f(f(f(R)))…) give this list to Alice

Skey authentication Authenticate Alice for 100 logins store x 101 in a password file or database record associated with Alice alice: x 101

Skey authentication Alice presents the last number on her list: Alice to host: { “alice”, x 100 } Host computes f(x 100 ) and compares it with the value in the database if (x 100 provided by alice) = passwd(“alice”) replace x 101 in db with x 100 provided by alice return success else fail next time: Alice presents x 99 if someone sees x 100 there is no way to generate x 99 .

Two-factor authentication with an authenticator card Challenge/response authentication user provided with a challenge number from host enter challenge number to challenge/response unit enter PIN get response: f(PIN, challenge) transcribe response back to host host maintains PIN computes the same function compares data rely on one-way function

Challenge-Response authentication “ alice” Alice network host look up alice’s key, K generate random challenge number C R ’ = f( K , C ) R = f( K , C ) R = R ’ ? “ alice” C R ’ “ welcome” an eavesdropper does not see K

SecurID card Username: paul Password: 1234 032848 PIN passcode from card + Something you know Something you have Enter PIN Press ◊ Card computes password Read off password Password: 354982 Passcode changes every 60 seconds

SecurID card from RSA, SASL mechanism: RFC 2808 Compute: AES-hash on: 128-bit token-specific seed 64-bit ISO representation of time of day (Y:M:D:H:M:S) 32-bit serial number of token 32-bits of padding Server computes three hashes with different clock values to account for drift.

SecurID Vulnerable to man-in-the-middle attacks attacker acts as application server user does not have a chance to authenticate server

SKID2/SKID3 authentication uses symmetric cryptography shared secret key generate a random token nonce give it to the other party, which encrypts it returns encrypted result verify that the other party knows the secret key

SKID2/SKID3 authentication Alice chooses a random number (nonce) R A and sends it to Bob R A Bob

SKID2/SKID3 authentication R A Bob R B , H K (R A , R B ,”bob”) Alice Bob chooses a random number (nonce): R B. He computes H K (R A , R B ,”bob”) and sends it to Alice with R B Bob shows that he can encrypt Alice’s nonce

SKID2/SKID3 authentication R A Bob R B , H K (R A , R B ,”bob”) Alice Alice receives R B and has R A . Computes: H K (R A , R B ,”bob”) compares result to verify that Bob was able to encrypt data with key K . Authentication is complete as far as Alice is concerned (Bob knows the key).

SKID2/SKID3 authentication R A Bob R B , H K (R A , R B ,”bob”) Alice Now Alice has to convince Bob ( mutual authentication ) H K (R B , “alice”) Bob Alice demonstrates that she can encrypt Bob’s nonce

SKID2/SKID3 authentication R A Bob R B , H K (R A , R B ,”bob”) Alice Bob computes H K (R B , “alice”) and compares Alice’s message. If they match, he trusts Alice’s identity Key point : Each party permutes data generated by the other. Challenge the other party with data that will be different each time. H K (R B , “alice”) Bob

Combined authentication and key exchange

Wide-mouth frog arbitrated protocol – Trent (3 rd party) has all the keys symmetric encryption for transmitting a session key “ alice” , E A (T A ,”bob”, K) Alice Trent session key destination time stamp – prevent replay attacks sender

Wide-mouth frog looks up key corresponding to sender (“alice”) decrypts remainder of message using Alice’s key validates timestamp (this is a new message) extracts destination (“bob”) looks up Bob’s key “ alice” , E A (T A ,”bob”, K) Alice Trent session key destination time stamp – prevent replay attacks sender Trent:

Wide-mouth frog creates a new message new timestamp identify source of the session key encrypt the message for Bob send to Bob “ alice” , E A (T A ,”bob”, K) Alice Trent session key source time stamp – prevent replay attacks Trent: E B (T T ,”alice”, K) Bob

Wide-mouth frog decrypts message validates timestamp extracts sender (“alice”) extracts session key, K “ alice” , E A (T A ,”bob”, K) Alice Trent session key source time stamp – prevent replay attacks Bob: E B (T T ,”alice”, K) Bob

Wide-mouth frog Since Bob and Alice have the session key, they can communicate securely using the key Alice E K (M) Bob

Kerberos authentication service developed by MIT project Athena 1983-1988 trusted third party symmetric cryptography passwords not sent in clear text assumes only the network can be compromised

Kerberos Users and services authenticate themselves to each other To access a service: user presents a ticket issued by the Kerberos authentication server service examines the ticket to verify the identity of the user

Kerberos user Alice wants to communicate with a service Bob both Alice and Bob have keys Step 1: Alice authenticates with Kerberos server Gets session key and sealed envelope Step 2: Alice gives Bob a session key (securely) Convinces Bob that she also got the session key from Kerberos

Authenticate, get permission “ I want to talk to Bob” Alice decrypts this: gets ID of “Bob’s server” gets session key knows message came from AS eh? (Alice can’t read this!) if Alice is allowed to talk to Bob, generate session key, S {“Bob’s server”, S} A Alice Authentication Server (AS) {“Alice”, S} B TICKET sealed envelope

Send key Alice encrypts a timestamp with session key Bob decrypts envelope: envelope was created by Kerberos on request from Alice gets session key Decrypts time stamp validates time window Prevent replay attacks {“Alice”, S} B , T S Alice Bob sealed envelope

Authenticate recipient Alice validates timestamp Encrypt Alice’s timestamp in return message Alice Bob {“Bob’s Server”, T} S

Kerberos key usage Every time a user wants to access a service User’s password (key) must be used each time (in decoding message from Kerberos) Possible solution: Cache the password (key) Not a good idea Another solution: Split Kerberos server into Authentication Server + Ticket Granting Server

Ticket Granting Service (TGS) TGS + AS = KDC (Kerberos Key Distribution Center) Before accessing any service, user requests a ticket to contact the TGS Anytime a user wants a service Request a ticket from TGS Reply is encrypted with session key from AS for use with TGS TGS works like a temporary ID

Using Kerberos $ kinit Password: enter password ask AS for permission (session key) to access TGS Alice gets: Compute key (A) from password to decrypt session key S and get TGS ID. You now have a ticket to access the Ticket Granting Service {“TGS”, S} A {“Alice”, S} TGS

Using Kerberos $ rlogin somehost rlogin uses TGS Ticket to request a ticket for the rlogin service on somehost Alice sends session key, S, to TGS Alice receives session key for rlogin service & ticket to pass to rlogin service {“rlogin@somehost”, S’} S {“Alice”, S’} R {“Alice”, S} TGS ,T S rlogin TGS session key for rlogin ticket for rlogin server on somehost

Public key authentication Alice wants to authenticate herself to Bob: Bob : generates nonce, S presents it to Alice Alice : encrypts S with her private key (sign it) and send to Bob Like SKID, demonstrate we can encrypt or decrypt a nonce:

Public key authentication Bob : look up “alice” in a database of public keys decrypt the message from Alice using Alice’s public key If the result is S , then it was Alice! Bob is convinced. For mutual authentication, Alice has to present Bob with a nonce that Bob will encrypt with his private key and return

Public key authentication Public key authentication relies on binding identity to a public key One option: get keys from a trusted source Problem: requires always going to the source cannot pass keys around Another option: sign the public key digital certificate

X.509 Certificates ISO introduced a set of authentication protocols: X.509 Structure for public key certificates : Trusted Certification Authority issues a signed certificate version serial # algorithm, params issuer validity time distinguished name public key (alg, params, key) signature of CA

X.509 certificates When you get a certificate Verify signature hash contents of certificate data Decrypt CA’s signature with CA’s public key Obtain CA’s public key (certificate) from trusted source Certification authorities are organized in a hierarchy A CA certificate may be signed by a CA above it certificate chaining Certificates prevent someone from using a phony public key to masquerade as another person

Agencia Catalana de Certificacio ANCERT AOL Arge Daten AS Sertifitseerimiskeskuse Asociacion Nacional del Notariado Mexicano A-Trust Austria Telekom-Control Commission Autoridad Certificadora Raiz de la Secretaria de Economia Autoridad de Certificacion Firmaprofesional Autoridade Certificadora Raiz Brasileira Belgacom E-Trust CAMERFIRMA Example: Root Certificates in IE As of January 2007 http://support.microsoft.com/kb/931125

CC Signet Certic á m ara S.A. Certipost s.a./n.v. Certisign CertPlus Colegio de Registradores Comodo Group ComSign Correo Cybertrust Deutsche Telekom DigiCert DigiNotar B.V. Direcci ó n General de la Polic í a – Ministerio del Interior – Espa ñ a. DST Example: Root Certificates in IE As of January 2007 http://support.microsoft.com/kb/931125

Echoworx Entrust eSign EUnet International First Data Digital Certificates FNMT Gatekeeper Root CA GeoTrust GlobalSign GoDaddy Government of France Government of Japan Ministry of Internal Affairs and Communications Government of Tunisia National Digital Certification Agency Hongkong Post IPS SERVIDORES Example: Root Certificates in IE As of January 2007 http://support.microsoft.com/kb/931125

IZENPE KMD Korea Information Security Agency Microsec Ltd. NetLock Network Solutions Post.Trust PTT Post Quovadis RSA Saunalahden Serveri SECOM Trust.net SecureNet SecureSign SecureTrust Corporation Example: Root Certificates in IE As of January 2007 http://support.microsoft.com/kb/931125

Serasa SIA Sonera Spanish Property & Commerce Registry Swisscom Solutions AG SwissSign AG S-TRUST TC TrustCenter TDC Thawte Trustis Limited TurkTrust TW Government Root Certification Authority U.S. Government Federal PKI Example: Root Certificates in IE As of January 2007 http://support.microsoft.com/kb/931125

Unizeto Certum UserTRUST ValiCert VeriSign Visa Wells Fargo WISeKey XRamp Example: Root Certificates in IE As of January 2007 http://support.microsoft.com/kb/931125

Transport Layer Security (TLS) aka Secure Socket Layer (SSL) Sits on top of TCP/IP Goal: provide an encrypted and possibly authenticated communication channel Provides authentication via RSA and X.509 certificates Encryption of communication session via a symmetric cipher Enables TCP services to engage in secure, authenticated transfers http, telnet, ntp, ftp, smtp, …

Secure Sockets Layer (SSL) client server Establish protocol, version, cipher suite, compression mechanism, exchange certificates (or send public key) hello(version, protocol) hello(version, protocol) certificate (or public key) hello done certificate (or none)

Secure Sockets Layer (SSL) client server Authenticate (unidirectional or mutual) [optional] client authenticates server server authenticates client encrypt with server’s private key client nonce E(nonce) client decrypts nonce with server’s public key server nonce E(nonce) server decrypts with client’s public key encrypt with client’s private key

Secure Sockets Layer (SSL) client server 3. Establish session key (for symmetric cryptography) encrypt with server’s public key server decrypts with server’s public key pick a session key E(session key) set cipher mode [optional]

Secure Sockets Layer (SSL) client server E S (data) 4. Exchange data (symmetric encryption) encrypt and decrypt with session key and symmetric algorithm (e.g. RC4)

Authentication (Distributed computing)

More Related Content

What's hot (20)

Similar to Authentication (Distributed computing) (20)

More from Sri Prasanna (20)

Recently uploaded (20)

Authentication (Distributed computing)