Security Handshake Pitfalls

Transcription

1 Cryptographic Authentication Security Handshake Pitfalls Ahmet Burak Can Hacettepe University Password authentication is subject to eavesdropping Alternative: Cryptographic challenge-response Symmetric key Public key 1 2 Symmetric Key Challenge-esponse Symmetric Key Challenge-esponse An example protocol: An alternative protocol: I m I m a challenge F(K AB,) K AB {} 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 equires reversible cryptography Subject to dictionary attack, without eavesdropping, if is recognizable Can be used for mutual authentication if is recognizable and has limited lifetime 4 1

2 Symmetric Key Challenge-esponse A one-message protocol: Public Key Challenge-esponse By signature: I m, K AB {timestamp} I m Easy integration into password-sending systems [] A 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 6 Public Key Challenge-esponse By decryption: Mutual Authentication An example protocol: I m I m {} A 1 F(K AB, 1 ) Problem: (or ) can get to sign/decrypt any text he chooses. Solutions: 2 F(K AB, 2 ) Never use the same key for different purposes (e.g., for login and signature) Use formatted challenges 7 8 2

3 Mutual Authentication with Few Messages Number of messages for mutual authentication can be reduced: I m, 2 1, F(K AB, 2 ) F(K AB, 1 ) eflection Attack: Original session: Decoy session: I m, 2 1, F(K AB, 2 ) F(K AB, 1 ) However, this protocol is vulnerable to I m, 1 eflection attack 3, F(K AB, 1 ) Dictionary attack : can do dictionary attack against K AB acting as, without eavesdropping esults from eflection Attack A Modified Mutual Authentication Scheme Solutions: Different keys for and Formatted challenges, different for and Principle: Initiator should be the first to prove its identity Solution against both problems: I m 1 F(K AB, 1 ), 2 F(K AB, 2 ) Dictionary attack is still possible if can impersonate

4 Mutual Authentication with Public Keys Session Key Establishment I m, { 2 } B A session key is needed for integrity protection and encryption in a communication session. It must be 2, { 1 } A 1 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 Problem: How can the public/private keys be remembered by ordinary users? Symmetric encryption Public key encryption Possibly, they can be retrieved from a server with password based authentication & encryption Session Key Establishment with Symmetric Encryption I m Do not use K AB {} or K AB {+1} Take (K AB +1){} as the session key. K AB {} 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 {} A, {} B and use them to derive a session key. { 1 } B I m +1 K AB {+1} K 1 2 { 2 } A = K =

5 Key Establishment and Authentication with A simple protocol: Key Establishment and Authentication with Another simple protocol:, K A {, K AB } K B {, K AB }, K A {, K AB }, ticket B where ticket B = K B {, K AB }, ticket B Problem: Potential delayed key delivery to. (besides others) Problems: No freshness guarantee for K AB & need to authenticate Nonces Needham-Schroeder Protocol Nonce: Something created for one particular occasion Nonce types: N 1,, andom numbers Timestamps K A {N 1,, K AB, ticket B } where ticket B = K B {K AB, } Sequence numbers andom nonces needed for unpredictability Obtaining random nonces from timestamps: encryption with a secret key. ticket B, K AB {N 2 } K AB {N 2-1, N 3 } K AB {N 3-1}

6 Needham-Schroeder Protocol Ticket is double-encrypted. (unnecessary) N 1 : for authenticating & 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). eplaying Tickets Messages should be integrity protected. Otherwise, cutand-paste reflection attacks possible: replay ticket B, K AB {N 2 } K AB {N 2-1, N 3 } K AB {N 3-1} ticket B, K AB {N 3 } K AB {N 3-1, N 4 } Expanded Needham-Schroeder Protocol Protocol Performance Comparison 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 } ticket B, K AB {N 2 } K AB {N 2-1, N 3 } 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 K AB {N 3-1}