Download
1 / 26
260 likes | 296 Views
Explore key authentication protocols like Needham-Schroeder, Otway-Rees, Kerberos, and their applications in secure communication. Dive into class and state diagrams, commonalities, and additional requirements. Learn the ins and outs of authentication methods, potential problems, and effective key exchange. Develop a solid understanding of preventing replay attacks and the role of nonces. Discover the trust model behind each protocol and the importance of secure key generation. Enhance your knowledge with practical examples and applications in the field of software engineering.
E N D
AuthenticationAdvanced Software Engineering (CSE870)Instructor: Dr. B. ChengContact info: chengb at cse dot msu dot edu Eduardo Diaz Dan Fiedler Andres Ramirez
Road Map • Introduction to Authentication • Needham-Schroeder, Otway-Rees, Kerberos • Commonalities • Additional Requirements • Class Diagrams • State Diagrams • Conclusions
Authentication • Meet: • Alice (Staff) • Bob (MISys)
Authentication • Purpose • Key exchange. • Allow Alice to secretly communicate with Bob using a shared cryptographic key. • Methods • Private keys, shared keys, public keys… • Potential Problems • Trustworthy? • Safe handling of private keys?
Needham-Schroeder • Alice Cathy: {Alice || Bob || rand1} • Cathy Alice: {Alice || Bob || rand1}Ksess || {Alice || Ksess}kbob}kalice 3. Alice Bob: {Alice || ksess}kbob 4. Bob Alice: {rand2}ksess 5. Alice Bob: {rand2 - 1}ksess
Needham Schroeder • Motive? • Prevent replay attacks • A valid data transmission is retransmitted maliciously. • Nonces • Randomly generated numbers to identify exchanges. • Key idea: Cathy is trusted by Alice and Bob.
Otway-Rees • Alice Bob: num || Alice || Bob || { rand1 || num || Alice|| Bob}kalice 2. Bob Cathy: num || Alice || Bob || {rand1 || num || Alice || Bob}kalice || {rand2 || num || Alice || Bob}kbob 3. Cathy Bob: num || {rand1 || ksess}kalice || {rand2 || ksess}kbob 4. Bob Alice: num || {rand1 || ksess}kalice
Otway-Rees • Motivation • Needham-Schroeder assumes all cryptographic keys are secure… in practice generated pseudorandomly… but it can be predicted. • Num • Verify that num agrees through the exchanges. • Key Idea • Cathy is again the trustworthy element.
Kerberos • Alice Cerberus: Alice || Barnum • Cerberus Alice: {kalice,barnum}kalice || Talice,barnum • Alice Barnum: Guttenberg || Aalice,barnum || Talice,barnum • Barnum Alice: Alice || {kalice,guttenberg}kalicebarnum || Talice,guttenberg • Alice Guttenberg: Aalice,guttenberg || Talice,guttenberg 6. Guttenberg Alice: {t+1}kalice,guttenberg
Kerberos • What is T? • Talice,barnum = Barnum || {Alice || Alice Address || valid time || kalice,barnum}kbarnum • What is A? • {Alice || generation time || kt}kalice,barnum • Kt… not used.
Kerberos • Motivation • Separate authentication of the user to ticket granting server and resource being requested. • 2 Servers • Authenticate first • Obtain ticket second • Key Idea: • Time windows • Separation of trusted parties
Commonalities • Message Passing • Authentication Requests • Encryption / Decryption • Key Passing • … other than that, not much! • Each protocol has slight variants.
Additional Requirements • Same as other groups plus: • Incorporate 2 design patterns • 1 must be a security design pattern • Strategy Design Pattern (encryption algorithms) • Single Access Point (entry and logging) • Instantiate the framework at MISys • At the whitebox level
Conclusions • Questions?
