Secure Remote Client Authentication - Finnova

IBM Zurich Research Laboratory 

Secure Remote Client Authentication 

Thorsten Kramp 

Thomas Weigold 

Finnova Partner Summit 11/09/2007 ©2007 IBM Corp


Introduction 

• Remote authentication is ubiquitous nowadays 

– Distributed data services and web services 

– Client/server are connected via some potentially insecure network 

• Large ranges of different schemes proposed 

– Ranging from simple passwords to PKI to biometrics 

– Running on desktop PCs to smart cards to mobile phones 

public network 

2 Finnova Partner Summit 11/09/2007 

©2007 IBM Corporation


Authentication Schemes (1): Passwords 

• Shared secret known to client and server 

– Most primitive and oldest method 

– Same static password is used over and over again 

– Changed infrequently every couple of weeks 

– Works only in well-controlled environments 




Authentication Schemes (2): One-Time Codes 

• Scratch Lists 

1. 2937 

2. 9665 

3. 9754 

… 

index (optional) 

one-time code 

1. 2937 

2. 9665 

3. 9754 

… 





• Short-Time Passwords 

time 

secret(s) 

ƒ(x) 

short-time code 

ƒ(x) 

time 

secret(s) 





• Challenge/Response 

challenge 

challenge 

challenge 

secret(s) 

ƒ(x) 

response code 

ƒ(x) 

secret(s) 




Authentication Schemes (3): PKI 

• Public-key infrastructure 

certificate 

private key 

challenge 

sig(Challenge) + certificate 

challenge 

CRL 

CA certificate(s) 




Authentication Schemes (4): Biometrics 

• Authentication based on “being something” instead 

of “knowing something” or “having something” 

– Fingerprints, facial expressions, iris pattern, … 

– Biometric information captured during enrollment 

– Captured again and compared for authentication 

– Probabilistic approach! 

Threshold 

Impostors 

Genuine 

FREQ 

False Reject 

False Accept 

MATCH SCORE 




Security Devices (1): Smart Cards 

• CPU plus memory in a tamper-resistant package 

– Clock and power provided externally 

– Contact-based or contact-less communication 

• Generally accepted as sufficiently secure to… 

– …store sensitive data (e.g., keys) 

– …generate keys (e.g., for PKI) 

• Reader required for access 

– Online (e.g., connected to a PC) 

– Offline w/ display and keyboard of its own 




Security Devices (2): Mobile Phones & PDAs 

• Separate computing platform 

– Keyboard and display of its own 

– May be used offline and online (e.g., via Bluetooth) 

– Mobile phones can use mobile network as secure channel 

• Potential target of attack 

– General computing platform (e.g., w/ Sun’s Java) 

– Requires a security token such as a smart card 

– Second smart card for secure processing communicating via 

NFC (near-field communication) 




Security Devices (3): Smart Memory Sticks 

• Memory stick w/ smart card 

– USB connected, mounts as read-only volume 

– Contains immutable software for remote authentication 

(e.g., hardened web browser) 

– Mutable state as well as sensitive data on smart card only 

– Difficult to update (e.g., security patches) 




Attacks (1): Phishing/Malicious Software 




Countermeasures (1): Phishing/Malicious Software 

• Phishing 

– Short-time codes limit window opportunity 

– Full protection only with challenge/response or PKI 

• Malicious Software 

– Requires separate security token such as a smart card 

– Directly connected with challenge/response scheme or PKI 

– With display and keyboard of its own prevents unsolicited 

usage, especially if combined with transaction signing 

– Stand-alone if challenge/response are easily to transfer or if 

an independent secure channel exists (e.g., mobile network) 




Attacks (2): Man in the Middle 




Countermeasures (2): Man in the Middle 

• PKI-certificate with SSL/TLS connection 

– Users tend to ignore warning messages about invalid or 

untrusted server certificates 

• Full protection requires… 

– Identification of the information channel by client and server 

– Challenge/response or PKI authentication scheme that uses 

the channel identification as additional input 

• Partial protection by transaction signing 

– MITM can “sniff” but not manipulate transactions or take 

over the communication channel 




Attacks Overview and Classification 




Conclusions & Recommendations 

1. Scratch lists are not state-of-the-art anymore as they 

do not withstand phishing and malicious software 

attacks. 

2. Challenge/response one-time codes or PKI-based 

schemes in combination with a secure device should 

be the basis for current authentications solutions. 

3. MITM attacks will become a problem in the near 

future. Therefore, current solutions should be built 

with a clear vision of how they could be extended to 

thwart MITM attacks. 




Contact 

• Thorsten Kramp 


thk@zurich.ibm.com 

• Thomas Weigold 


twe@zurich.ibm.com

Secure Remote Client Authentication - Finnova

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?