Security Handshake Pitfalls Ahmet Burak Can Hacettepe University abc@hacettepe.edu.tr 1
Cryptographic Authentication Password authentication is subject to eavesdropping Alternative: Cryptographic challenge-response Symmetric key Public key 2
Symmetric Key Challenge-Response An example protocol: I m a challenge R F(K AB,R) Authentication not mutual (login only) Subject to connection hijacking (login only) Subject to off-line password guessing (if K is derived from password) s database has keys in the clear 3
Symmetric Key Challenge-Response An alternative protocol: I m K AB {R} R Requires reversible cryptography Subject to dictionary attack, without eavesdropping, if R is recognizable Can be used for mutual authentication if R is recognizable and has limited lifetime 4
Symmetric Key Challenge-Response A one-message protocol: I m, K AB {timestamp} Easy integration into password-sending systems More efficient: Single message, stateless Care needed against replays: timeout needed Care needed if key is common across servers Clock has to be protected as well Alternatively, with a hash function, send, I m, timestamp, H(K AB,timestamp) 5
Public Key Challenge-Response By signature: I m R [R] A 6
Public Key Challenge-Response By decryption: I m {R} A R Problem: (or Trudy) can get to sign/decrypt any text he chooses. Solutions: Never use the same key for different purposes (e.g., for login and signature) Use formatted challenges 7
Mutual Authentication An example protocol: I m R 1 F(K AB,R 1 ) R 2 F(K AB,R 2 ) 8
Mutual Authentication with Few Messages Number of messages for mutual authentication can be reduced: I m, R 2 R 1, F(K AB,R 2 ) F(K AB,R 1 ) However, this protocol is vulnerable to Reflection attack Dictionary attack :Trudy can do dictionary attack against K AB acting as, without eavesdropping. 9
Reflection Attack: Original session: I m, R 2 Trudy R 1, F(K AB,R 2 ) F(K AB,R 1 ) Decoy session: I m, R 1 Trudy R 3, F(K AB,R 1 ) 10
Results from Reflection Attack Solutions: Different keys for and Formatted challenges, different for and Principle: Initiator should be the first to prove its identity 11
A Modified Mutual Authentication Scheme Solution against both problems: I m R 1 F(K AB,R 1 ), R 2 F(K AB,R 2 ) Dictionary attack is still possible if Trudy can impersonate. 12
Mutual Authentication with Public Keys I m, {R 2 } B R 2, {R 1 } A R 1 Problem: How can the public/private keys be remembered by ordinary users? Possibly, they can be retrieved from a server with password based authentication & encryption. 13
Session Key Establishment A session key is needed for integrity protection and encryption in a communication session. It must be different for each session unguessable by an eavesdropper not K AB {x} for some x predictable/extractable by an attacker Session keys can be established by using Symmetric encryption Public key encryption 14
Session Key Establishment with Symmetric Encryption I m R K AB {R} Do not use K AB {R} or K AB {R+1} Take (K AB +1){R} as the session key. I m R+1 K AB {R+1} 15
Session Key Establishment with Public Key Cryptosystem An alternative is to use Diffie-Helman key exchange algorithm. Another alternative with PKC, send additional random nonces {R} A, {R} B and use them to derive a session key. {R 1 } B {R 2 } A K R 1 R 2 = K = R 1 R2 16
Key Establishment and Authentication with KDC A simple protocol:, K A {, K AB } KDC K B {, K AB } Problem: Potential delayed key delivery to. (besides others) 17
Key Establishment and Authentication with KDC Another simple protocol:, K A {, K AB }, ticket B where ticket B = K B {, K AB } KDC, ticket B Problems: No freshness guarantee for K AB & need to authenticate 18
Nonces Nonce: Something created for one particular occasion Nonce types: Random numbers Timestamps Sequence numbers Random nonces needed for unpredictability Obtaining random nonces from timestamps: encryption with a secret key. 19
Needham-Schroeder Protocol N 1,, K A {N 1,, K AB, ticket B } where ticket B = K B {K AB, } KDC ticket B, K AB {N 2 } K AB {N 2-1, N 3 } K AB {N 3-1} 20
Needham-Schroeder Protocol Ticket is double-encrypted. (unnecessary) N 1 : for authenticating KDC & freshness of K AB. N 2, N 3 : for key confirmation, mutual authentication Why are the challenges N 2, N 3 encrypted? Problem: doesn t have freshness guarantee for K AB (i.e., can t detect replays). 21
Replaying Tickets Messages should be integrity protected. Otherwise, cutand-paste reflection attacks possible: replay ticket B, K AB {N 2 } Trudy K AB {N 2-1, N 3 } K AB {N 3-1} ticket B, K AB {N 3 } Trudy K AB {N 3-1, N 4 } 22
Expanded Needham-Schroeder Protocol hello K B {N B } N 1,,, K B {N B } K A {N 1,, K AB, ticket B } where ticket B = K B {K AB,, N B } KDC ticket B, K AB {N 2 } K AB {N 2-1, N 3 } K AB {N 3-1} 23
Protocol Performance Comparison Computational Complexity: (to minimize CPU time, power consumption) Number of private-key operations public-key bytes encrypted with secret key bytes hashed Communication Complexity: Number of message rounds Bandwidth consumption 24