CSE 543 - Computer Security · Lecture 6 - Applied Cryptography September 13, 2007 URL: ... • Trusted third party for key distribution • Each principal and service has a Kerberos

CSE543 Computer (and Network) Security - Fall 2007 - Professor Jaeger Page

CSE 543 - Computer Security

Lecture 6 - Applied CryptographySeptember 13, 2007URL: http://www.cse.psu.edu/~tjaeger/cse543-f07/

CSE543 Computer (and Network) Security - Fall 2005 - Professor McDanielCSE543 Computer (and Network) Security - Fall 2007 - Professor Jaeger

Project Assignments

• Pretty narrow selection– 23 people picked IM security– Some projects untouched

• 7 project groups defined (26 students)• 9 students not assigned

– Pick again among (by 5pm tonite -- 9/13)– Secure Network Computing– Password Cracking/Keylogging– User-compatible Security

• Students– Murthy, Bala, Borcic, Chen, Gopalrathnam, Srikar,

Shawaran, Tannous, McLaughlin

2


Applied Cryptography

• How do we use these (and other) constructs to achieve security goals?– What are the goals?

3


Meet Alice and Bob ….

• Alice and Bob are the canonical players in the cryptographic world. – They represent the end points of some interaction– Used to illustrate/define a security protocol

• Other players occasionally join …– Trent - trusted third party– Mallory - malicious entity– Eve - eavesdropper– Ivan - an issuer (of some object)

4


Some notation …

• You will generally see protocols defined in terms of exchanges containing some notation like– All players are identified by their first initial

• E.g., Alice=A, Bob=B– d is some data – pwA is the password for A– kAB is a symmetric key known to A and B– KA+,KA- is a public/private key pair for entity A– E(k,d) is encryption of data d with key k– H(d) is the hash of data d

– Sig(KA-,d) is the signature (using A’s private key) of data d– “+” is used to refer to concatenation

5


Some interesting things you want to do …

• … when communicating.– Ensure the authenticity of a user– Ensure the integrity of the data

• Also called data authenticity

– Keep data confidential

– Guarantee non-repudation

6


Basic (User) Authentication

Alice Bob

• Bob wants to authenticate Alice’s identity– (is who she says she is)

[pwA]

1

[Y/N]

2

7


Hash User Authentication

Alice Bob


[h(pwA)]

1

[Y/N]

2

8


Challenge/Response User Authentication

Alice Bob


[h(c+pwA)]2

1

[c]

[Y/N]

3

9


User Authentication vs. Data Integrity

• User authentication proves a property about the communicating parties– E.g., I know a password

• Data integrity ensures that the data transmitted...– Can be verified to be from an authenticated user– Can be verified to determine whether it has been modified

• Now, lets talk about the latter, data integrity

10


Simple Data Integrity?

Alice Bob

• Alice wants to ensure any modification of the data in flight is detectable by Bob (integrity)

[d,h(d)]1

11


HMAC Integrity

Alice Bob


[d,hmac(k,d)]1

12


Signature Integrity

Alice Bob


[d, Sig(KA-, d)]1

13


Data Integrity vs. Non-repudiation

• If the integrity of the data is preserved, is it provably from that source?– Hash integrity says what about non-repudiation?– Signature integrity says what about non-repudiation?

14


Confidentiality

Alice Bob

• Alice wants to ensure that the data is not exposed to anyone except the intended recipient (confidentiality)

[E(kAB,d), hmac(kAB, d)]1

15


Question

• If I already have an authenticated channel (e.g., the remote party’s public key), why don’t I simply make up a key and send it to them?


• Alice wants to ensure that the data is not exposed to anyone except the intended recipient (confidentiality)

• But, Alice and Bob have never met!!!!

• Alice randomly selects key kx to encrypt with

Confidentiality

Alice Bob

[E(kx,d), hmac(kx, d),E(KB+,kx)]1

17


Real Systems Security

• The reality of the security is that 90% of the frequently used protocols use some variant of these constructs.– So, get to know them … they are your friends– We will see them (and a few more) over the semester

• They also apply to systems construction– Protocols need not necessarily be online– Think about how you would use these constructs to secure

files on a disk drive (integrity, authenticity, confidentiality)– We will add some other tools, but these are the basics

18


Kerberos

• History: from UNIX to Networks (late 80s)– Solves: password eavesdropping– Online authentication

• Variant of Needham-Schroeder protocol– Easy application integration API– First single sign-on system (SSO)– Genesis: rsh, rcp

• authentication via assertion

• Most widely used (non-web) centralized password system in existence (and lately only ..)

• Now: part of Windows 2K, XP network authentication– Windows authentication was a joke.

19


An aside …

• Authentication– Assessing identity of users– By using credentials …

• Authorization– Determining if users have the right to perform requested

action (e.g., write a file, query a database, etc.)• Kerberos authenticates users, but does not perform

any authorization functions …– … beyond identify user as part of Realm– Typically done by application.

• Q: Do you use any “Kerberized” programs?– How do you know?

20


The setup …

• The players– Principal - person being authenticated– Service (verifier) - entity requiring authentication (e.g, AFS)– Key Distribution Center (KDC)

• Trusted third party for key distribution• Each principal and service has a Kerberos password known to

KDC, which is munged to make a password ke, e.g., kA

– Ticket granting server• Server granting transient authentication

• The objectives– Authenticate Alice (Principal) to Bob (Service)– Negotiate a symmetric (secret) session key kAB

21


The protocol

• A two-phase process– User authentication/obtain session key (and ticket granting

ticket) key from Key Distribution Center– Authenticate Service/obtain session key for communication

with service

• Setup– Every user and service get certified and assigns password

22


Ticket (KAB)

“Locked” by KA

A Kerberos Ticket

• A kerberos ticket is a token that …– Alice is the only on that can open it– Contains a session key for Alice/Bob (KAB)– Contains inside it a token that can only be opened by Bob

• Bob’s Ticket contains– Alice’s identity– The session key (KAB)

• Q: What if issuing service is not trusted?

(KAB)Ticket

“Locked” by KB

23


The protocol (obtaining a TGT)

• Timeexp - time of expiration• n - nonce (random, one-use value: e.g., timestamp)

Alice KDC

[A,TGS,Timeexp,n]1

E(kA,[kA,TGS,TGS,Timeexp,n]),E(KTGS,[A, kA,TGS, Timeexp],)2

TGT

24


The protocol (performing authentication)

Alice

Bob

[B,Timeexp,n,E(kA,TGS,[B,Timeexp,n])], E(KTGS,[A,kA,TGS,Timeexp])]

1

E(kA,TGS,[kA,B,B,Timeexp,n]), E(kB,[A,kA,B,Timeexp])]2

TGS

3

E(kA,B,[A,Timeexp,n]),E(kB,[A,kA,B,Timeexp])]

25

Authenticator


In class

• Work in binary numbers• Cipher = XOR

– key=0111000– plaintext =10101111– ciphertext E(k,p) = 01110000 XOR 10101111 = 11011111– plaintext = 11011111 XOR 01110000 = 10101111

• Groups of 4– Alice (principal)– Bob (service)– Key distribution center (KDC)– Ticket granting server (TGS)

26


Protocol (setup and phase 1)

• Each Alice, Bob, and TGS secretly negotiate a 8-bit key with the KDC– Only Alice and KDC know kA,KDC

– Only Bob, KDC, and TGS know kB,KDC

• Note: KDC exposes Bob’s key to TGS– Only TGS and KDC know kKDC,TGS

• Phase 1 (obtaining a ticket-granting ticket)1. A -> KDC : A2. KDC -> A : E(kA,KDC,[kA,TGS]),E(kKDC,TGS,[kA,TGS])

• where kA,TGS is randomly selected by KDC

27


Protocol Phase 2 and communication

• Phase 2 (obtaining a service ticket)1. A -> TGS : B,E(kKDC,TGS,[kA,TGS])2. TGS -> A : E(kA,TGS,[kA,B]), E(kB,KDC,[kA,B])

• where kA,B is randomly selected by TGS– A -> B : E(kB,KDC,[kA,B])

• Communications1. A -> B : E(kA,B, [01011010])2. B -> A : E(kA,B, [10010110])

28


Cross-Realm Kerberos

• Extend philosophy to more servers– Obtain ticket from TGS for foreign Realm

– Supply to TGS of foreign Realm– Rinse and repeat as necessary

• “There is no problem so hard in computer science that it cannot be solved by another layer of indirection.”– David Wheeler, Cambridge University (circa 1950)

Michigan Penn St.Ohio St.

Purdue Pitt

29


Kerberos Reality

• V4 was supposed to be replaced by V5– But wasn’t because interface was ugly, complicated, and

encoding was infuriating• Assumes trusted path between user and Kerberos• Widely used in UNIX domains• Robust and stable implementation

• Problem: trust ain’t transitive, so not so good for large collections of autonomous enterprises

30

Documents

CSE 543 - Computer Security · Lecture 6 - Applied Cryptography September 13, 2007 URL: ... • Trusted third party for key distribution • Each principal and service has a Kerberos