AUTHENTICATION

 

Notes from reviews:

-       Is it decentralized?

o      A: by what standard? Compared to a mainframe with terminals…

 

1. Authentication procedure
1. Identifying a user to the computer
2. Essentials:

                                              i.     What do you know?

1.   Information only correct user would have

2.   A password

3.   Your dog’s name

4.   ISSUES: human’s are limited in what they can remember

                                             ii.     What do you have?

1.   A smart card

2.   A metal key

3.   ISSUES:

a.    Limited size

b.    Users may forget to bring it

                                           iii.     Who are you?

1.   Biometrics

2.   ISSUES:

a.    People who lack that item

b.    Can be copied with silicon gel

c.    How do you get the information to the computer?

3. Issues: must communicate information from user to computer

                                              i.     Channel may not be trust worthy

1.   Cameras on keyboards

2.   Keystroke loggers

3.   Network sniffers

                                             ii.     QUESTION: how impact biometrics?

                                           iii.     SOLUTION:

1.   Encryption. Where do you do it?

a.    On password database (unix): doesn’t help sniffers, but allows accidental release

b.    On terminal (Windows): doesn’t help untrusted workstations

c.    On smart card: user controls a small computer that does the verification

4. Issues: why should user trust computer?

                                              i.     QUESTION: How can we solve this?

                                             ii.     ANSWER: computer must provide information

1.   E.g. Phishing prevention by bank providing information it knows about you

2.   Smart card verifies password of computer

2. PASSWORDS (from paper)
1. QUESTION: what is threat model for passwords?

                                              i.     Physical access to machine?

                                             ii.     Access to access links?

2. Solution 1: Password file, protected by ACLS

                                              i.     QUESTION: why is it a problem?

1.   A: hard to get perfect (depends on unbuggy software, brittle)

2.   A: hard to synchronize public info (name, UID) with private info

3.   EXAMPLES:

a.    Editors confusing temp files

b.    Backup / restore

c.    Boot alternate OS, look at file

                                             ii.     Problems:

1.   Some systems check 1 character at a time (e.g. strcmp)

2.   Could break by placing address at page boundary, seeing whether fault occurred.

3. Solution 2: cryptographically hash file

                                              i.     BENEFITS:

1.   Can make file world-read (can’t use information)

a.    QUESTION: Why can’t you use the pwd information?

                                             ii.     PROBLEMS:

1.   Vulnerable to precomputed brute-force attacks

a.    Try all short strings

b.    Try words in dictionaries, dates, etc.

c.    Can tell when two people have same password

4. Solution 2a: assign random passwords

                                              i.     Problem: need good source of randomness. Clock is not good enough (e.g. 16 bits)

                                             ii.     Netscape SSL implementation had this problem. Used clock to seed random number generator. How many possible values for a key created today? (out of 128 bits in key)

5. Solution 3: slow encryption function + salt

                                              i.     Salt: append public number to pwd before hashing

1.   Login program reads salt, does hash

                                             ii.     BENEFITS:

1.   Blows up size of precomputed dictionary

2.   Prevents seeing if two users have same PWD, or same user on 2 systems has same PWD

6. PROBLEMS:

                                              i.     How can you use unix password file over a network?

7. Microsoft solution:

                                              i.     1-way function + protection

3. Problems statement
1. Basic problem: you want to know who is talking to you over a network

                                              i.     QUESTION: who should know this? Client, server or both?

2. Assumptions: QUESTION: what are they

                                              i.     Need thread model; what you are protecting against.

                                             ii.     Network totally untrustworthy

1.   Can sniff messages

2.   Can inject messages

3.   Can replay messages

4.   Can forge addresses (but harder)

                                           iii.     Trust local hardware to perform correctly

                                           iv.     Trust the people you trust not to divulge secrets

3. Constraints

                                              i.     Large, scalable system à not share passwords with everyone

                                             ii.     Low overhead à cache information as much as possible, few round trips & messages

                                           iii.     Use long-term keys as little as possible

4. Question: can you prove a protocol secure?

                                              i.     Unlike proving a protocol correct – you have to enumerate all the threats & beliefs

                                             ii.     Many people have come up with frameworks, hard to use

 

1. Encryption overview
1. Symmetric Key / Shared Key – fast (us)

                                              i.     both sides know the key

                                             ii.     Use same key for encrypt / decrypt

                                           iii.     You have an account with a key, and you see a message (M)ka. Who could have signed it?

1.   A: user A or password database server

2. Public key / asymmetric key – slow (ms)

                                              i.     Two different keys. If one encrypts, other can decrypt

                                             ii.     ((M)PK)SK) = M

                                           iii.     ((M)PKA = secret for A, only A can decrypt but anybody can generate

                                           iv.     ((M)SKA = signed by A – only A can generate but anybody can decrypt

                                            v.     ((M)SKA)PKB = message signed by A that only B can decrypt

3. Hash functions – one way functions

                                              i.     Easy to generate, impossible to invert or find a collision

                                             ii.     Used to avoid expensive operations on whole message

                                           iii.     M,(H(M))SKA = M signed by SKA

                                           iv.     Used for keyed hash: HMAC = H(M . PWD)

4. Issues:

                                              i.     Speed: hash < secret < public (factor of 10)

 

4. Basic protocol for shared secrets
1. Challenge response

                                              i.     Client requests challenge

                                             ii.     Server sends challenge

                                           iii.     Client encrypts with pwd, sends to server

                                           iv.     Server verifies

2. Idea: client proves it knows something without exposing what it is.
3. Idea: based on shared knowledge of client and server
4. Problems    

                                              i.     Man in the middle

1.   If you can make client connect to you, you can forward messages to server

                                             ii.     Requires server & client to have a shared secret

1.   Used in Windows up to NT 4

2.    

5. How do you think about protocols: beliefs
1. What does the client believe at each point

                                              i.     E.g. nonce/challenge is fresh

                                             ii.     Things that are encrypted imply other side knows the key

6. Scaling protocol: what if have star-formation, a server knows all the keys
1. Needham & Schroeder

                                              i.     Protocol:

1.   A à AS: A,B, Nonce-a

2.   AS à A: (Nonce-a, B, CK, (CK,A)KB)KA

3.   A à B: (CK,A)KB

4.   B à A: (Nonce-B)CK

5.   A à B: (Nonce-B – 1) CK

                                             ii.     points:

1.   Essence: server performs a ticket protocol as compared to a list protocol, AS does a list protocol.

2.   Nonce: preserves freshness – can tie response to request

3.   When things sent in clear, response sends back same value encrypted (or decremented) to indicate it got through (e.g. message 2)

4.   When ambiguous who a message came from, must include name (e.g. message 3)

5.   (Nonce-B)CK is an authenticator – it demonstrates that B can decrypt CK, and is used to verify that A knows CK as well

6.   Using CK has benefits – can now be used to encrypt additional data between A and B

                                           iii.     QUESTION: What do you learn at the end?

1.   Is the user allowed to access the service?

2.   What the name of the user is?

                                           iv.     Problems

1.   A must enter password each time it talks to a new server

2.   No limit on how long message 3 is good for – if can break in and steal CK

2. Needham & Schroeder public key

                                              i.     Public key overview

1.   Authentication server only stores public keys

2.   Akin to a phone book, directory assistance

                                             ii.     Protocol

1.   A à AS: B

2.   AS à A: (PKB, B) skas

a.    This is a certificate – signed by AS

3.   A à B (Nonce-a, A)pkb

a.    Send a nonce and name encrypted with pkb

b.    B can decrypt this directly, but can’t reply yet

4.   B à AS: A

5.   AS à B: (PKA, A) skas

a.    Again, a certificate

6.   B à A: (Nonce-A, Nonce-B) pka

7.   A à B: (nonce-B)

                                           iii.     Bugs:

1.   Messages 2 and 5 could be replayed – no freshness here

2.   Can do man-in-the-middle:

a.    A à I: (Na,A)pki

b.    I à B : (Na,A)pkb

                                                                                                    i.     Can be generated because knows ski, pkb

c.    B à I (Na, Nb)pka

                                                                                                    i.     B sends back wrong value

d.    I à A (Na, Nb)pka

                                                                                                    i.     I forwards it along

e.    A à I (Nb)pki

                                                                                                    i.     A decrypts Nb on I’s behalf

f.     I à B (Nb)pkb

                                                                                                    i.     B now trusts I

                                                                                                   ii.     I knows Na, Nb – what was considered a shared secret

3.   Solution: include names when encrypting

a.    Change message 6 from

                                                                                                    i.     B à A: (Nonce-A, Nonce-B)pka to:

                                                                                                   ii.     B à A: (Nonce-A, Nonce-B, B)pka

                                           iv.     Compared to private key protocol

1.   AS does less work: no encryption, just database lookup

2.   AS must have strong integrity: can’t let database be corrupted

                                            v.     Reality: public key encryption slow

1.   Encrypting with 1024 bit key takes ~ 1ms (1 million cycles)

2.   AES – 200 cycles

3.   People only encrypt secret keys with public keys

7. One-way communication
1. Motivation:

                                              i.     Secure email.

                                             ii.     Want privacy: message can’t be seen

                                           iii.     Want integrity: nobody else could have written message

                                           iv.     Want replay protection: can’t send message twice

2. Conventional algorithm:

                                              i.     A à B: (CK, A)kb , (message)ck

1.   Need timestamps to avoid replay

3. Public key

                                              i.     A à B: (A, I, (B)ska)pkb, message+I

1.   Notes: nobody can see I, so can’t be replaced

                                             ii.     Problems

1.   I doesn’t tightly bind message to crypto, could replace message and leave I

2.   Solution: use I as a crypto key: (message)i

3.   Remember I so can’t be reused

8. Digital Signatures
1. Motivation: provide evidence to a third party that the sender did something
2. Conventional

                                              i.     A à AS: A, (hash)ka

                                             ii.     AS à A: (A, hash) kas

1.   AS encrypts hash and A’s name –binding them together

                                           iii.     B à AS: B, (A,hash)kas

                                           iv.     AS à B : (A, hash)kb

3. Public key

                                              i.     A à B: ((text)ska)pkb

1.   Encrypt with pkb: only pkb can read it

2.   Encrypt with ska: only ska could write it

3.   Reality: text ((hash)ska)pkb for speed

9. Public key infrastructure
1. Certificate servers

                                              i.     Produce signed sertificates

1.   (A, pka)scs

                                             ii.     Maintain revocation lists

1.   If A loses her secret key

                                           iii.     Can produce certificate for other certificate servers

10. Decision: how do you choose what to use?
1. Storing keys on client:

                                              i.     Secret key / hash: can use passwords

                                             ii.     Public key: must store private key somewhere

2. Storing keys on server:

                                              i.     Secret key / hash: data must be kept super-secret

                                             ii.     Public key: data is not secret, but must not be modified

                                           iii.     Server can be offline (not needed synchronously except for revocation)

3. Key lifetime:

                                              i.     Secret key: fairly short (minutes, months)

                                             ii.     Public key: fairly long (need not be remembered)

4. Verification:

                                              i.     Secret key / hash: authentication server generally can get involved in verification (because it has to write the tickets)

                                             ii.     Public key: end node does verification (because auth server doesn’t generate anything)

5. Direction:

                                              i.     Secret key fine if you can establish keys

                                             ii.     Public key good if you can’t; you can bootstrap from one “trusted” value using PKI

                                           iii.     Public key good for authenticating servers; users don’t need their own key